edit-icon download-icon

ストレステストの実施

最終更新日: Mar 14, 2018

ストレステストの概要

レイヤ 4 Server Load Balancer (SLB) は、オープンソースソフトウェアの Linux Virtual Server(LVS) と Keepalived を使用してロードバランシングを実現します。レイヤ 7 SLB は Tengine を使用してロードバランシングを実現します。レイヤ 4 SLB の場合、 LVS を経由した後でバックエンドサーバに直接要求が送信されます。レイヤ 7 SLB では、 LVS を経て Tengine を経てバックエンドサーバーに到達します。着信要求を転送する場合、レイヤー 7 SLB にはレイヤー 4 SLB よりももう 1 つの手順があります。この追加の手順のため、レイヤー 7 SLB のパフォーマンスは、レイヤー 4 SLB のパフォーマンスほど効率的ではありません。

レイヤ 7 SLB インスタンスでストレステストを実行すると、パフォーマンスが予想よりも大幅に低下することがあります。また、 2 つのバックエンド ECS インスタンスが同じ仕様の 1 つのバックエンド ECS インスタンスに対して遅い場合は、 SLB インスタンスのパフォーマンスが低下する可能性があります。追加で考えられる原因は次のとおりです。

  • 原因:クライアントポートが不足しています。

    クライアントポートが不足すると、特にストレステスト中に接続エラーが発生する可能性があります。 SLB はデフォルトで TCP 接続のタイムスタンプ属性を消去し、 Linux プロトコルスタックの tw_reuse 機能( reuse time_wait 接続)は有効になりません。その結果、 time_wait 接続が重なり、クライアントポートが不十分になります。

    解決策:クライアント上で短時間の接続の代わりに永続的な接続を使用してください。切断する(ソケットの SO_LINGER 属性を設定する)には、 FIN パケットを送信する代わりに RST メッセージを使用します。

  • 原因:バックエンドサーバーの受け入れキューがいっぱいです。

    バックエンドサーバーの受け入れキューがいっぱいになっているため、バックエンドサーバーは syn_ack パケットを返さず、クライアントはタイムアウトします。

    解決策: net.core.somaxconn のデフォルト値は 128 です。 sysctl -w net.core.somaxconn=1024 を実行して値を変更し、バックエンドサーバ上でアプリケーションを再起動します。

  • 原因:バックエンドサーバーへの接続が多すぎます。

    永続的な接続は、アーキテクチャー設計のためにレイヤー 7 SLB を使用する場合、 Tengine を通過した後に短時間接続に変わります。したがって、多数の接続がバックエンドサーバーに送信され、ストレステスト中のパフォーマンスが低下します。

  • 原因:アプリケーションのパフォーマンスが低下しています。

    SLB がバックエンドサーバーに要求を転送すると、バックエンドサーバーの負荷は正常ですが、バックエンドサーバーに展開されたアプリケーションはデータベースなどの他のアプリケーションに依存するため、パフォーマンスが期待通りにはなりません。データベースがパフォーマンスのボトルネックに達すると、パフォーマンスが低下する可能性があります。

  • 原因:バックエンドサーバのヘルスチェックステータスが異常です。

    ストレステストを行うときにバックエンドサーバーのヘルスチェックステータスを無視するのは簡単です。バックエンドサーバーの健全性チェックの失敗または頻繁なヘルスチェックのステータスの変更(頻繁な変更は正常から正常でない、または正常でないから正常に変化する)は、パフォーマンスが低下します。

ストレステストの提案

ストレステストでは、次の点に注意してください。

  • SLB の転送機能をテストするために短時間接続を使用してください。

    セッションの永続性とバランシングテストのテストに加えて、ストレステストの主な目的は、 SLB の転送機能をテストすることです。 SLB およびバックエンドサーバーの処理機能をテストするには、短時間接続を使用することをお勧めします。短期間の接続を使用してストレステストを行う場合、クライアントポートの問題が不十分であることに注意してください。

  • SLB のスループットをテストするために固定接続を使用します。持続的な接続は、帯域幅の制限または特別なサービスをテストするために使用されます。

    ストレステストツールのタイムアウト値( 5 秒)を短く設定することをお勧めします。タイムアウト値が大きすぎると、テスト結果の平均 RT が増加し、 SLB のスループット限界に達したかどうかを判断することが困難になります。タイムアウト値が小さい場合、テスト結果に成功率が表示され、 SLB のスループット限界を迅速に判断することが容易になります。

  • ストレステストに静的な Web ページを使用して、アプリケーションのロジックコストを抑えます。

  • ストレステストには、以下のリスナー構成を使用してください。

  • セッション永続性を有効にしないでください。これにより、特定のバックエンドサーバーに負荷が集中する可能性があります。

  • リスナーのヘルスチェックを無効にして、バックエンドサーバーへのヘルスチェック要求を減らします。

  • 実際のオンライン状況をシミュレートするために、ソース IP アドレスが分散された複数の( 5 つ以上の)クライアントでストレステストを実行します。

  • Apache ab をストレステストツールとして使用しないでください。

    並行性の高いシナリオでは、 Apache ab は 3 秒、 6 秒、 9 秒の段階的な中断を経験することがあります。 Apache ab は、コンテンツの長さに基づいて要求が成功したかどうかを判断します。複数のバックエンドサーバーが SLB に追加された場合、返されるコンテンツの長さに一貫性がなくなり、結果が悪影響を受けます。