LoadView

AWS ロードテスト – ロードバランシングとベストプラクティス

7月 26, 2021 | パフォーマンステスト, 技術のヒント

この記事の目的は、AWS 環境とその機能について説明し、AWS で作業する際のベストプラクティス、特に AWS のロードテストと自動スケールについて説明することです。 また、AWS ロードテストと LoadView の動作を比較し、現在市場の他のツールやソリューションよりもはるかに使いやすくなります。
ロードビューによるJMeterロードテスト

完全に管理されたクラウド ネットワークから大規模なロード テストを実行する

JMeter負荷試験

AWS での分散ロードテスト

1 つのエンドポイントに対する数千の同時接続をシミュレートするソリューションである AWS での分散ロードテストについて説明します。 これは、アプリケーションの開発とパフォーマンスを繰り返す人にとって非常に便利なツールです。

正確にテストされているのは何ですか?

開発者であり、世界で最も偉大なアプリケーションを構築したとします (または、これまで構築した中で最も偉大なアプリケーションかもしれません)。 開発者は、単体テストと機能テストを行った後で正常に動作することを確信しています。 次に知っておくべきことは、これはプロダクションで実行され、大規模に実行される予定ですか? スケーラビリティは非常に重要です。 ロード テスト アプリケーションは、機能テストと同じと考えることができますが、アプリケーションに負荷を適用して、何が起こるかを観察するだけです。 1人のユーザーのテストと1000人のテストには違いがあります。

このソリューションでは 、Elastic Container Services を使用して、数百の接続をエンド ポイントに作成するコンテナーをスピンアップし、それらのコンテナーを数百個スピンアップすることで、負荷の下でアプリケーションをテストできるフレームワークを構築します。 AWS の Distributed ロードテストの ランディングページを以下に示します。

AWS での分散ロードテスト

図からわかるように、数回のクリックでユーザーのアカウントでソリューションをスピンアップする CloudFormation テンプレートへのリンクがあります。 「デプロイガイドの表示」は、Aws で Amazon ウェブサービス (AWS) クラウドに分散ロードテストをデプロイするためのアーキテクチャ上の考慮事項と設定手順に関する手順を説明する詳細なガイドです。 ソースコードは、ユーザーが自分のニーズや要件に合わせてそれを取り、カスタマイズしたい場合は、GitHub で利用できます。 アーキテクチャ図は、フロントエンドとバックエンドで構成されるソリューションの全体的なインフラストラクチャを表します。

AWS フロントエンド

フロントエンドを考慮する場合: ウェブ コンソールと、ユーザーがソリューションと対話するために使用できる UI があります。 また、テストの作成、テストの状態の表示、テストの再実行、およびテスト操作の削除を行う API もあります。 UI はクラウドフォーメーション テンプレートから取得されます。 ここで、ユーザーは実際にテスト自体の構成を開始します。

AWS バックエンド

バックエンドは、Docker パイプラインと実際のテスト エンジン自体の 2 つの要素で構成されます。 Docker パイプラインのどこから来るソリューションは、Taurus と呼ばれるオープンソースソフトウェアを使用しています。 ユーザーが使用できる Docker Hub で使用できる Docker イメージがあります。 これにより、ユーザーはエンドポイントへの数百の同時接続を生成できます。 また、他のテストツールであるJMeterとガトリングもサポートしています。 これはイメージの実際のテスト部分であり、これはテストを行うアプリケーションであり、Docker イメージの形式で提供されます。 バックエンドパイプラインは、そのイメージパッケージを私たちのために取り上げ、顧客のアカウントのS3にプッシュアウトするつもりです。 そして、そのイメージを構築し、エラスティック コンテナー サービスに登録するために、CodePipeline と CodeBuild が使用されています。

実際のテストは AWS Fargate で行われています。 これは、ネットワークや下線インフラストラクチャを気にすることなく、Elastic Container サービスでコンテナーを実行できるマネージド サービスです。 それは文字通りタスクをスピンアップし、他のすべてを世話したいコンテナの数を実行するだけです。 さらに、API からのリクエストを受け取る Lambda 関数があり、それが実際にテストを実行しているものです。 S3 にテスト テンプレートを保存します。 収集しているすべての情報が Dynamo に保存され、SQS を使用して AWS Fargate でタスクをキューに入れてコンテナーのスピンを開始できるようにします。

AWS テストの設定

以下に、テストの構成方法に関するフロントエンドに関するプレゼンテーションを示します。

AWS 設定テスト

  1. ユーザーが [テストの作成] ボタンをクリックする
  2. ユーザーは、 名前、説明、タスク数 (実行するコンテナの数)、 同時実行 (各コンテナーの番号です。作成する同時接続の数) ランプアップ (その数の同時接続まで取得するために最初から取得する期間) ホールド( そのテストをいつまで保持するつもりですか?
  3. シナリオ: テスト対象の HTTP エンドポイント (現在 AWS はシングル エンド ポイントをサポートしています )、HTTP メソッド (AWS は GET、PUT、POST、削除オペレーションをサポートしています)、HTTP ヘッダー、ボディペイロード (ヘッダーおよびペイロードは解析できます)。

以下に、 現在実行中のテスト のスクリーンショットが提供されています。

AWS ロードテストの詳細

テストの詳細が提供されました。 この特定の例では、20個のコンテナが尋ねられ、20個のコンテナが実行されています。 バックエンドで完了すると、各コンテナーがテストを実行し、結果を取得し、バックエンド Lambda 関数の S3 に XML ファイルの形式で保存します。 すべてのコンテナが完了したら、その情報を取得して集約し、その情報をすべて Dynamo に渡します。

以下は、テストの 結果 を表すページの 3 つのスクリーン ショットです。

AWS ロードテストの詳細 HTTP テスト

AWS テスト結果

AWS 結果履歴

完了したテストをユーザーが確認すると、サマリーが表示されます。平均応答時間、待機時間、CloudWatch メトリクスであるテスト結果により、パフォーマンス、他の多くのデータポイント、結果履歴を確認できます。

これを一度実行し、API のエンド ポイントで微調整を行い、再度テストを再実行して、応答時間を改善して、開発者がアプリケーションの改善を繰り返し、その結果を確認できるようにするとします。 最も重要なことは、パフォーマンスが大規模に見える点です。

これは、AWS での分散ロード テストについて深く説明しました。 このソリューションは、アプリケーションを大規模にテストするための負荷生成の複雑さを排除します。

AWS オートスケーリング

自動スケールはクラウド コンピューティングで使用される方法で、サーバー ファーム内の多数の計算リソース (通常はアクティブ なサーバーの数で測定) によって、ファームの負荷に基づいて自動的にスケーリングされます。 AWS の自動スケールは、アプリケーションの水平方向のスケーラビリティを実現するのに役立ちます。 高可用性を実現し、EC2容量を拡張し、所望の容量を維持し、需要に基づいて容量をシームレスに増減し、コストの最適化につながります。 これは、ELPとクラウドウォッチで動作します。

エラスティック ロード バランサーの作成

次の図は、基本を理解するのに役立つ一般的な構造を示しています。

弾性ロードバランサー

弾性ロード バランサーの作成

起動設定と自動スケールを作成して設定する前に、AWS のサービスプロバイダーである Elastic Load Balancer (ELB) を作成して、その制御下にある正常な EC2 インスタンス全体に着信トラフィックを均等に分散する必要があります。 ここでは、健康なキーワードです。 エラスティック ロード バランサーは、定期的に構成可能なヘルス チェックを実行し、トラフィックの送信先を決定します。 以下のスクリーンショットは、EC2 ダッシュボードへの見出しです。

EC2 ダッシュボード

ここでの目的は、クラウド内のEC2仮想サーバーを目指す。 以下に示すように、[ ネットワークとセキュリティ] の下にある [ ロード バランサー] を選択します。

EC2 Dashboard_Networkとセキュリティ

その後、ユーザーはロード バランサーの 作成 ボタンをクリックします。

ロード バランサーの作成

ユーザーが名前を指定します。 この特定の例では、[ 内部ロード バランサーの作成 ] をオフのままにします。 これにより、DNS 名がパブリック IP アドレスにリダイレクトされます。 チェックすると、DNS 名は代わりにプライベート IP を指します。 詳細な VPC 設定を有効 にするがチェックされ、後のステップでサブネットを ELB に割り当てることができます。 リスナー設定により、受信 ELB トラフィックを EC2 インスタンスポートにマッピングできます。 デフォルトのポート80マッピングは、アプリケーションに役立ちます。

ヘルスチェックの設定

次に示す手順は、 ヘルスチェックの設定です。

ヘルスチェックの設定

ヘルスチェックの構成: オプション

ここでは、標準の HTTP、TCP、HTTPS、および SSL のオプションを示します。 この例では、HTTP に固執し、ロボット.txtファイルに向けます。 ウェブ サーバーが静的要求に対応できない場合、インスタンスに何か問題があると考え、正常になるまでそれ以上のトラフィックを送信する必要はありません。 現在の設定の詳細設定では、EC2 インスタンスは 30 秒ごとにチェックされます。 要求に応答するのに 5 秒かかります。 割り当てられた時間内に応答しなかった場合、インスタンスが異常である可能性があります。 2 つの連続した異常チェックにより、EC2 インスタンスはサービス状態から外れます。 再び健康になること。 トラフィックの受信を開始する前に、10 個の連続したヘルスチェックに合格する必要があります。 これらのしきい値は、アプリケーションで許容されます。

サブネット/ゾーンの選択

次に示す[サブネット]オプションから選択します。

サブネットの選択

ウェブ サーバー用に作成した各サブネットを追加します。 可用性ゾーンごとに 1 つのサブネットしか追加できないことに注意してください。

セキュリティグループの割り当て

以下は、セキュリティグループの割り当てのスクリーンショットです。

セキュリティグループの割り当て

ELB のセキュリティ グループを選択する必要があるため、この例では、事前構成済みの ELB セキュリティ グループを選択します。

EC2 インスタンスの追加

以下は、EC2 インスタンスを追加する方法を示すスクリーンショットです。

ロード バランサーへのインスタンスの追加

このステップでは、クロスゾーンの負荷分散を有効にするがチェックされていることを確認する必要があります。 それがなければ、当社の高可用性設計は役に立ちません。 [接続ドレインを有効にする] をオンにして、インスタンスの登録解除時または異常が宣言されている場合にトラフィックがどのように処理されるかを決定する必要があります。

ロード バランサーの作成のレビュー ページ

レビューページは以下の通りです。 ここから、選択内容を確認し、必要に応じて追加の変更を加えることができます。

ロード バランサーの作成のレビュー ページ

これで、ELB が作成されます。 完了したら、起動設定を自動スケール ポリシーとして作成する準備が整いました。 自動スケール ポリシーの作成も簡単なので、ユーザーはプロセスを自分で実行できます。

ロードビュー対コンペティション: ロードビューが際立つ理由

このセクションでは、他の一般的なロード テスト ツールとソリューションと LoadView の間の高レベルの比較を提供します。 すべてのロード テスト ツールが同じに作成されているわけではありません。 オープンソースツールは通常、コストや投資を必要としませんが、使いやすいオプションになる可能性がありますが 、LoadView を他のツールよりも使いやすくするものを理解するのが最善です。

アパッチJメーター

オープンソースソフトウェアであるApache JMeterは、機能動作の負荷テストとウェブアプリケーションのパフォーマンス測定用です。 次に、JMeterの長所と短所を強調します。

アパッチJMeterの利点

  • プラットフォームに依存しない. JMeterは、Mac、Windows、Linuxなどのオペレーティングシステムで実行できます。
  • オープンソース. このツールはオープンソースで、無料で使用できます。 また、ソフトウェア開発者は、変更を加えて要件に合わせて構成することも可能で、柔軟性が高くなります。 開発者はJMeterをカスタマイズし、JMeterにオートメーションテストを適用することができます。
  • 機能: JMeterを使用すると、ロードテスト、ストレステスト、機能テスト、分散テストなど、ユーザーは必要なあらゆる種類のテストを行うことができます。
  • レポート. JMeterは、チャート、グラフ、ツリービューなど、数多くのレポートやチャートを提供しています。 さらに、レポート用の HTML、JSON、および XML 形式もサポートされています。
  • 多くのプロトコルのサポート: JMeter は、FTP、HTTP、LDAP、SOAP、JDBC、および JMS をサポートします。
  • 負荷生成能力: ソフトウェアは無制限の負荷生成容量を有する。
  • 実行: 実行するのは簡単です。 ユーザーは、Javaをインストールし、JMeterをダウンロードし、JMeterスクリプトファイルをアップロードする必要があります。
    分析レポート。 経験の浅いエンジニアやユーザーにとって、結果は理解しやすく、テスターの詳細な分析も可能です。

アパッチJMeterのデメリット

  • ユーザーフレンドリーではないです。 たくさんのスクリプトを書かなければならないので、他のツールと同じくらい使いやすいものではない。 混乱を招く可能性があります。 テストを実行できるようにするには、ユーザーが難しく、混乱する可能性のあるスクリプトを書く必要があり、ソフトウェアがユーザーフレンドリーでないことを導きます。
  • デスクトップ アプリケーションのサポートの欠如: JMeterはウェブ アプリケーションのテストに最適ですが、デスクトップアプリケーションのテストには適していません。
  • メモリ消費: JMeterは、大量の負荷をシミュレートし、大量のメモリを吸収するテストレポートを視覚化することができ、メモリが大きな負荷の下にあるリードしています。
  • Java スクリプトのサポートはありません。 JMeterはブラウザではないので、実際のブラウザを動作またはシミュレートするだけです。 AJAX と JavaScript はサポートされないので、テストの効率に影響します。 クライアント側のパフォーマンスを適切に測定することはできません(JMeterの長所と短所の詳細については 、JMeterによる究極のガイドパフォーマンステストをチェックしてください)

ロード忍者

LoadNinja はクラウドのロード テスト プラットフォームであり、スクリプトを使用せずに ウェブ サイトや ウェブ アプリケーションのパフォーマンスを確実に判断できます。 LoadNinja は、従来のプロトコル ベースのロード テスト ツールが直面する課題を、メディアに対して一から構築および設計しました。 LoadNinja のハイライトと制限について説明します。

ロード忍者の利点

  • 実際のブラウザを使用する
  • 分析機能とレポート機能を備えたブラウザー ベースのメトリック。
  • VU デバッガ. 開発者はテスト中にエラーを検出して切り分けできます。
  • VUインスペクター. テストの実行中に仮想ユーザーが ウェブ ページやアプリケーションをどのように操作するかをユーザーに知ることができます。
  • 記録ツール. 以下で詳しく説明する EveryStep Web レコーダーと同様に、ポイントとクリックのスクリプトを使用できます。

ロード忍者のデメリット

  • AJAX に依存します。 JavaScript が無効になっているか、サポートされていない場合は機能しません。
  • 動的コンテンツ: 動的コンテンツは、AJAX ベースのアプリケーションでは表示されません。
  • 潜在。 AJAX の非同期動作に基づいて、待機時間の問題が大きくなる可能性があります。
  • コスト. 市場や機能に含まれる他のツールと比較して、高価なことができます。

ロードランナー

マイクロフォーカスのソフトウェアテストツールです。 アプリケーションのテスト、システムの動作の測定、負荷の高いパフォーマンスの測定に使用されます。 アプリケーションソフトウェアを使用して、数千人のユーザーを同時にシミュレートできます。 LoadRunner の人気の理由と、ソリューションの欠点をいくつか簡単に見てみましょう。

ロードランナーの利点

  • 再生と記録機能 (自動相関に加えて)
  • リモートデスクトップ、Citrix、メインフレームなどの独自のプロトコルに加えて、さまざまなプロトコルがサポートされています。
  • ソフトウェアは、ボトルネックの自動分析を実行しようとすることができます。
  • HP ALM、QTPなどのインフラストラクチャとの統合。

ソフトウェアは、リソースの可用性(RAM、CPUなど)の観点から、自分自身とテスト中のアプリケーションを監視することができます。

ロードランナーのデメリット

  • LoadRunner は高価なソフトウェア テスト ツールです。 最近無料試用版をリリースしたが、単にダウンロードして使用することはできません。
  • LoadRunner は、限られた負荷生成容量を持っています。 ユーザーまたはスレッドが多すぎる LoadRunner ツールをオーバーロードすることはできません。 (ユーザーが、大量のテストを実行するパフォーマンス テスト ツールを探している場合、また、ユーザーとスレッド グループが多すぎる場合、LoadRunner は最適な選択ではありません)。
  • 実行は複雑です。 ユーザーごとに 1 つのスレッドを作成します。
  • 分析レポートの観点から、様々なグラフを生成するためにHP分析によって解析される未加工の形式の情報。

ビューを読み込む

ソフトウェアは、ウェブ ページ、ウェブ アプリ、API、さらにはストリーミングメディアのためのクラウドベースのストレスと負荷テストツールです。 LoadView はクラウドベースであるため、エンジニアとテスターは、負荷要件に応じて、ロード テストを迅速にスピンアップおよびスケールアップできます。 ユーザーは、要求された数のトラフィックを生成できます。 このプロセスでは、ユーザーが自分のマシンからテストを実行する必要があり、LoadViewが提供するレベルに拡張できないJMeterのようなオープンソースツールよりも大きな利点である追加のインフラストラクチャを処理する必要はありません。

ビューの利点をロード

  • 長期的な価格設定義務はなく、従量課金制の価格設定モデルが付属しているため、顧客は必要なときにいつでもテストをロードできます。
  • Java、HTML5、フラッシュ、Vue、角度、反応、PHP、シルバーライト、Ruby(その他多くの間)などのダイナミックおよびリッチインターネットアプリケーション(RIA)のユーザーシナリオの記録をサポートしています。 ユーザーのブラウザーでレンダリングできる場合、EveryStep Web レコーダーは、それをサポートします。
  • ユーザーは、さまざまなグローバル地理的な場所にあるサーバーを利用して、予想されるユーザー ベースを模倣できます。
  • コード行に触れることなくロード テスト スクリプトを作成する。
  • 実際のブラウザーでのクラウドベースのロード テスト。
  • 40台以上のデスクトップ/モバイルデバイスとブラウザで互換性をテストします。
  • 20以上の世界的なロードインジェクターのジオロケーション。
  • ボトルネックを診断し、スケーラビリティを確保し、全体的なパフォーマンスを決定します。
  • パフォーマンス レポート、容量計画の指標、パフォーマンス ダッシュボードなど。

このセクションを要約すると、LoadViewは、我々がカバーした他の残りのツールよりも使いやすく、より効率的であることを示しています。

ラッピング: AWS ロードテスト – ロードバランシングとベストプラクティス

この記事では、AWS で分散ロードテストを実行する方法を取り上げ、アプリケーションを大規模にテストするための負荷生成の複雑さを解消しました。 AWS ロードテストは、数のトランザクションを達成する数の接続ユーザーを構築し、再現するためにユーザーを支援するために使用されます。 また、AWS 内の自動スケーリング機能についても取り上げ、オートスケーリングの定義、設定を起動するためのエラスティックロードバランサーの作成方法、自動スケーリングの設定などについて説明しました。 また、市場で人気のあるロード テスト ツールの一部と、LoadView が他のツールよりもはるかに使いやすい理由についても説明しました。

今日の市場で他の負荷テストツールやソリューションと比較してLoadViewの詳細については、包括的なサイドバイサイド比較と情報については、 代替 ページをご覧ください。

今すぐビューを読み始めましょう! 無料試用版にサインアップ し、開始時にロードテストクレジットで$ 20を取得します。