新しく公開された Distributed Load Testing on AWS (DLT) ワークショップを試した - kakakakakku blog
負荷テストを実行したいけど，ラップトップや Amazon EC2 インスタンス1台から実行すると負荷テストを実行する側がボトルネックになってしまって，期待した負荷テストにならないという悩みはよくあると思う🔥 そこで負荷テスト専用の SaaS などを活用して負荷テストを実現する案もあるけど，AWS では「AWS ソリューションライブラリ（サービスではない）」として負荷テストを実行・管理する「Distributed Load Testing on AWS (DLT)」が提供されている❗️ aws.amazon.com 僕自身は2年ほど前に Distributed Load Testing on AWS (DLT) を検証したことがあるけど，最近 Distributed Load Testing on AWS (DLT) を体験するワークショップ（日本語🇯🇵）が公開されたらしく，復習も兼ね
概要 この記事では、負荷テストツールLocustで分散負荷テスト環境を構築するに当たって私が使っている方法をまとめます。 構築はAWS Fargateを使って、設定をできるだけ少なくしました。 AWSの操作にはTerraformを使って、構築・破棄を繰り返しできるようにしています。 背景 これまでやっていた負荷テスト 負荷テストはどのようにして実行しているでしょうか？ 私はこれまで簡単なものはApacheBenchで行い、 ログインを含むシナリオが必要なものはシェルスクリプトでコードを書いて実行していました。 しかし、ApacheBenchは静的なWebサイトなどで使うには良いのですが、Webアプリのテストとなると機能が足りないと感じていました。 シェルスクリプトを使えば何でもできる反面、テストの作成に時間がかかりがちで、メンテナンスもしずらくなっていました。 Locustを使った負荷テス
負荷制限を使用して過負荷を回避する
私は、数年間 Amazon のサービスフレームワークチームで働いた経験があります。私たちのチームは、Amazon Route 53 や Elastic Load Balancing などの AWS のサービスの所有者がより迅速にサービスを構築するのに役立つツールを作成し、サービスクライアントはそれらのサービスをより簡単に呼び出せるようになりました。他の Amazon チームは、測定、認証、モニタリング、クライアントライブラリ生成、ドキュメント生成などの機能をサービス所有者に提供しました。各サービスチームがそれらの機能をサービスに手動で統合する代わりに、サービスフレームワークチームは 1 回統合を行い、設定を通じて各サービスに機能を公開しました。 私たちが直面した課題の 1 つは、特にパフォーマンスまたは可用性に関連する機能に対して、適切なデフォルトを提供する方法を決めることでした。たとえば
負荷試験＃基本リンク集 | 外道父の匠
前の記事は実は前フリで、最近、負荷試験について深く潜り込んだので、自分なりに考えたことを細かく分けて書いていこうと思います。負荷試験シリーズのはじまり:-) 後半はほとんど自分で考えて色々実装しましたが、序盤は先人の知恵をかき集めてイィトコ取りしたので、メモっておいたリンク集を置いておきます。 はじめに 負荷試験ってツールを選んで大量リクエストを発生させるんでしょ。ってイメージがあるかもですが、より効率的により正確にって仕上げていくと、独自に実装したい仕組みが結構でてきます。 アプリケーションは当然モノによって仕組みや構成は異なるし、プロトコルが異なる場合もあります。千差万別は言いすぎかもだけど試験には色んな選択や工夫があり、これが正解っていう単純なものではないのは間違いないです。 とはいえ、シンプルな実行と結果でも、複雑な取り組みをしたとしても、求められる成果に対して十分で正しい結果を示
図を書いて気分転換したくなったので、アーキテクチャについて軽く触れます。 細かくは省いて、負荷試験の大雑把なサーバー構成にはどのような選択肢があるのか、の事例を出していきます。 登場人物 超ざっくり分けると３つに分類されます。 基本AWS内での利用を想定していますが、User と Server は別にどこの環境でも大丈夫なようにしています。Client は ECS Fargate で使い捨て。 私の場合、実際にどのような構成で試験できるようにしたのか、を紹介していきますが、これだけ見ると至って普通な内容かもしれません。 １：１ ダイレクト型 まずは最もシンプルな構成で、主に動作テスト用です。 これだと普通にLocustを動かすのと変わらない構成です。実行命令と負荷リクエストを出すサーバーが同じで、任意の１ホストへリクエストを送信します。 Server は Host を指定するだけなので、経
負荷テストは、インフラ環境をサイジングするうえでの具体的なデータを与えてくれます。この記事では、インフラ事業者視点で負荷テストについての目的、種類、実施方法について考えてみます。 ※面倒な準備は無しで、簡単に負荷テストを実施したい人向けに、WEBインタフェースから負荷テストがおこなえるシステムを作成中です。 インフラ事業者から見た、負荷テストの目的 サイジングの妥当性を証明できる インフラ事業者から見た場合、負荷テストの最大のメリットはサイジングの妥当性を証明できることです。 当社も提案の際に、サイジングに必要な情報を確認していきます。月間の（想定）アクセス数、ピーク時の（想定）アクセス数、平均ページサイズ、リプレイスであれば各サーバのCPUやメモリ、ディスクなどのリソース情報などです。しかしながら、具体的な情報がでてくることは多くありません。そのため、想定しているアクセス数やシステムの内
![[技術ブログvol.21] インフラ視点で、負荷テストについて考えてみる - DENET 技術ブログ](https://cdn-ak-scissors.b.st-hatena.com/image/square/33184e9b1ec8b646021561cd25873e5232aa45f2/height=288;version=1;width=512/https%3A%2F%2Fblog.denet.co.jp%2F2014%2F12%2Faz2_test.jpg)
こんにちは。ゲームソリューション部の出村です。 負荷試験でLocustを扱う機会がありました。これまでJMeterやgatlingの利用経験はありましたがLocustは初体験となります。 他の負荷試験ツールとの違いに触れつつLocastのセットアップ方法や機能について解説します。 Locastとは ざっくりいえばJMeterなどと同じく負荷試験ツールのことです。 他の負荷試験ツールと異なる点は次のことが挙げられます。 Pythonで動く サーバ、スレーブ構成が可能 シナリオがPythonで書ける Python3で動く 動作環境で必要なのがPython 3です。Python3.10以上がインストールされている環境であれば動作しますし、インストールもpipコマンドだけで終わります。 シナリオがPythonで書ける シナリオのスクリプトもPythonで書けます。Pythonであれば書き慣れている
負荷試験＃ツール選択 | 外道父の匠
負荷試験シリーズの実質初弾としては、ツールの選択について考えていきます。 基本的な基準を捉えつつ、私自身の要望を整理し、何に決定していったのか、という流れで参ります。 選定基準 前記事にも記載しましたが、このページは非常に参考になるので、まずは雰囲気だけでもサラリと読んでみるとよいです。 Open source load testing tool review 2020 Open Source Load Testing Tools: Which One Should You Use? | BlazeMeter ツールは必要？ そもそも負荷試験ツールを使う必要があるのか、についてからですが、「必要はあります」で言い切って良いと思います。 選択しない場合、自身で何かしらコーディングすることになるわけですが、実装内容によってはできなくもない話とはいえ、より複雑になるほどオレオレ度合いが高まってコ
Pythonで始める負荷試験
PyCon JP 2020 Online 2020年8月28日(火) https://pycon.jp/2020/
負荷試験＃実行条件と傾向観察 | 外道父の匠
負荷試験シリーズ、今回は実行時の条件と結果の読み取りについて考えていきます。 どのようなな調整で負荷試験を進めていけば、より効率的に正確な成果を得られるのか。これはただのパワーゲームではありません。 誤った考え方 アプリケーションが多様ゆえに、負荷試験にも完全な正解はないかもしれませんが、限りなく正着といえる手法はあります。 負荷試験を始めましょう、となった時にヤラカシがちなのが、いきなり本番想定のサーバー量で試験を始めることです。このサービスの想定DAUがいくらで、ピークタイムのRPSがいくらになりそうだから、サーバーはこのくらいだろう。と用意してそれに負荷をかけ、大丈夫だの足りないだのやりだすことの、なんと意味の薄いことか。 もしそれがオンプレミスならありえます。なぜなら、サービスが完成するだいぶ前には物理サーバーの準備ができている必要があり、そこから増減を考える意味がないからです。今
負荷試験ツールHedgehog
負荷テストを行うにあたって必ず決める必要がのある数値が「同時リクエスト数」です。 「同時アクセス数」「多重度」「秒間リクエスト数」「最大同時接続数」など、様々な紛らわしい用語が使われており、用語とHTTP通信の基本的な仕組みを理解していないと正しい負荷テストを行うことも結果を正しく判定することもできません。 今回は、「同時リクエスト数」とは何か、またどのように決めるべきかについて説明します。 負荷テストを正しく行うために理解したい「HTTP通信の仕組み」 ブラウザの開発者モードを使うとWebページを表示する時の通信はすべて確認、解析することができます。 以下はHedgehogの公式サイトを表示する場合にChromeの開発者ツールで表示したサーバーとの通信ログです。 ページを構成するファイルが順番にリクエストされ、それぞれのレスポンスタイムが確認できます。 HTTP通信の基本的な仕組みは以下
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Locustの分散負荷テスト環境をAWS Fargateを使って簡単に用意してやる - Qiita
負荷試験＃サーバーアーキテクチャ事例 | 外道父の匠
[技術ブログvol.21] インフラ視点で、負荷テストについて考えてみる - DENET 技術ブログ
最速でlocustを体験してみた | DevelopersIO