Application Load Balancer (ALB) は、アプリケーション層で大量のトラフィックを処理できる高度にスケーラブルなサービスです。 このトピックでは、ALBインスタンスでストレステストを実行する方法について説明します。
ストレステストのフレームワーク
次の図に基づいて、テスト環境を設計できます。
ストレステスト方法
ストレステスト指標
ALBは、新しい接続数、同時接続数、データ処理能力 (要求と応答を含む) 、および1秒あたりの要求数の4つのメトリックに基づいてテストされます。 各メトリックには異なるストレステスト方法が必要です。
NLBインスタンスとそのバックエンドサーバー間で維持できる新しい接続数をテストするには、短期間の接続を使用することを推奨します。
高帯域幅の消費を防ぐために、単純なメカニズムに依存するハートビートサービスを使用することを推奨します。 ストレステストで短期間の接続を使用する場合は、NLBインスタンスにクライアントに接続するための十分なフロントエンドポートがあることを確認してください。
NLBインスタンスとそのバックエンドサーバー間で維持できる同時接続数をテストするには、永続接続を使用することを推奨します。
各永続接続は、セッションの永続性を維持するための単純なメカニズムに依存するハートビートサービスを使用することをお勧めします。 ストレステストで永続接続を使用する場合は、NLBインスタンスにクライアントに接続するための十分なフロントエンドポートがあることを確認してください。
永続接続を使用して、NLBインスタンスの転送容量をテストすることを推奨します。 永続接続は、帯域幅制限または特定のサービスのテストに適しています。
ストレステストツールのタイムアウト時間を5秒などの適切な値に設定します。 タイムアウト期間を大きな値に設定すると、ストレステストの平均応答時間が長くなり、NLBインスタンスが負荷に耐えられるかどうかを判断することが困難になります。 タイムアウト期間を小さな値に設定すると、テスト結果に示されているリクエスト成功率に基づいて、NLBインスタンスが負荷に耐えられるかどうかを判断できます。
ALBインスタンスとバックエンドサーバー間で維持できる1秒あたりのリクエスト数をテストするには、短期間のHTTP接続、永続的なHTTP接続、短期間のHTTPS接続、または永続的なHTTPS接続を使用することを推奨します。
サーバーグループの構成に関する提案
バックエンドサーバーに送信されるリクエストの数を減らすために、ヘルスチェックを無効にすることを推奨します。
ストレステストツール
Apache abを使用してストレステストを実行しないことを推奨します。 同時実行性の高いシナリオでは、Apache abの待機時間は3秒単位 (3秒、6秒、9秒など) で増加します。 Apache abは、指定されたコンテンツ長に基づいてリクエストが成功したかどうかを判断します。 ベンチマークするNLBインスタンスが複数のバックエンドサーバーに関連付けられている場合、これらのバックエンドサーバーから返される応答コンテンツの実際の長さは、指定されたコンテンツの長さと異なる場合があります。 これは、ストレス試験結果を不正確にする。
ストレステストのスコアが低い原因
ストレステストの低得点の考えられる原因:
不十分なクライアントポート
ストレステスト中、NLBインスタンスに十分なフロントエンドポートがない場合、クライアントはNLBインスタンスとの接続を確立できません。 NLBインスタンスは、デフォルトでTCP接続のtimestampプロパティを削除します。 その結果、Linuxスタックのtw_reuseフラグは無効になります。 tw_reuseフラグは、time_wait状態にある接続を再利用するために使用されます。 したがって、このフラグが無効になると、time_wait状態の接続が蓄積され、NLBインスタンスのフロントエンドポートを占有します。
解決策: クライアントでは短期間の接続ではなく、永続的な接続を使用します。 さらに、リセット (RST) パケットを使用して、SO_LINGERソケットオプションを設定して接続を閉じます。
バックエンドサーバーの完全な受け入れキュー
バックエンドサーバーの受け入れキューがいっぱいになると、バックエンドサーバーはsyn_ackパケットを返すことができなくなります。 その結果、クライアントはタイムアウトします。
解決策:
sysctl -w net.core.somaxconn=1024コマンドを実行して、net.core.somaxconnの値を変更し、バックエンドサーバーでアプリケーションを再起動します。 net.core.somaxconn のデフォルト値は 128 です。アプリケーションのバックエンドサーバーへの依存関係がパフォーマンスのボトルネックになります
バックエンドサーバーのトラフィック負荷がバックエンドサーバーのパフォーマンス制限を下回っています。 しかしながら、バックエンドサーバ上のアプリケーションは、データベースなどの別のアプリケーションに依存し得る。 したがって、依存性は、ストレステストにおけるNLBインスタンスのパフォーマンスを制限する可能性もあります。
解決策: バックエンドサーバーで使用されなくなったアプリケーションをクリアします。
異常なバックエンドサーバー
バックエンドサーバーが異常であると宣言された場合、またはバックエンドサーバーのヘルスステータスが頻繁に変化した場合、ストレステストでのNLBインスタンスのパフォーマンスが低下する可能性があります。
解決策: ヘルスチェックを無効にして、バックエンドサーバーに送信されるリクエストの数を減らします。