Server Load Balancer:NLB のストレステスト方法

ストレステストのフレームワーク

このセクションでは、標準ストレステストフレームワークと単一仮想 IP アドレス (VIP) ストレステストフレームワークについて説明します。ほとんどのシナリオでは、標準ストレステストフレームワークが使用されます。単一 VIP ストレステストフレームワークは、一部のシナリオでのみ使用できます。詳細については、「ストレステスト方法」および「ストレステストのスコアが低い場合に考えられる原因」をご参照ください。

• 標準ストレステストフレームワーク

• 単一 VIP ストレステストフレームワーク

ストレステスト方法

ストレステストのメトリック

NLB は、新規接続数、同時接続数、データ転送能力 (リクエストとレスポンスの両方を含む) の 3 つのメトリックに基づいてテストされます。各メトリックには、異なるストレステスト方法が必要です。

• 短時間接続を使用して、NLB インスタンスとそのバックエンドサーバー間で維持できる新規接続数をテストすることを推奨します。

  高い帯域幅を消費しないように、シンプルなメカニズムに依存するハートビートサービスを使用することを推奨します。ストレステストで短時間接続を使用する場合は、NLB インスタンスにクライアントと接続するための十分なフロントエンドポートがあることを確認してください。

• 持続的接続を使用して、NLB インスタンスとそのバックエンドサーバー間で維持できる同時接続数をテストすることを推奨します。

  各持続的接続では、セッション維持のためにシンプルなメカニズムに依存するハートビートサービスを使用することを推奨します。ストレステストで持続的接続を使用する場合は、NLB インスタンスにクライアントと接続するための十分なフロントエンドポートがあることを確認してください。

• 持続的接続を使用して、NLB インスタンスの転送能力をテストすることを推奨します。持続的接続は、帯域幅制限や特定のサービスのテストに適しています。

  ストレステストツールのタイムアウト期間を 5 秒などの適切な値に設定します。タイムアウト期間を大きな値に設定すると、ストレステストの平均応答時間が増加し、NLB インスタンスが負荷に耐えられるかどうかを判断するのが難しくなります。タイムアウト期間を小さな値に設定すると、テスト結果に表示されるリクエスト成功率に基づいて、NLB インスタンスが負荷に耐えられるかどうかを判断できます。

リスナー設定に関する推奨事項

以下のリスナー設定を使用することを推奨します。

サーバーグループ設定に関する推奨事項

以下のサーバーグループ設定を使用することを推奨します。

• 送信元アドレスに基づく一貫性ハッシュを使用しないことを推奨します。使用した場合、リクエストが特定のバックエンドサーバーに転送されます。セッション維持を有効にする場合は、4 タプルハッシュ (送信元 IP アドレス、宛先 IP アドレス、送信元ポート、宛先ポート) を使用して、ハッシュ値の範囲を広げることを推奨します。スケジューリングアルゴリズムの詳細については、「SLB のスケジューリングアルゴリズム」をご参照ください。

• ヘルスチェックを無効にして、バックエンドサーバーに送信されるリクエストの数を減らすことを推奨します。

• クライアント IP の維持機能を有効にする場合は、単一 VIP ストレステストフレームワークを使用することを推奨します。標準ストレステストフレームワークを使用する場合、ストレステストで使用されるクライアントの数が少ないか、送信元 IP アドレスに基づく一貫性ハッシュが使用されていると、バックエンドサーバー間でセッション競合が発生する可能性が高くなります。

• クライアント IP の維持機能を無効にすると、NLB インスタンスは自身の IP アドレスを使用してバックエンドサーバーとの接続を確立します。これは、システムが各 NLB インスタンスに割り当てる送信元 IP アドレスの数が限られているためです。同時接続を維持するには、システムはストレステスト用に十分な数のバックエンドサーバーを確保する必要があります。

ストレステストツール

Apache ab を使用してストレステストを実行することは推奨しません。高い同時実行性のシナリオでは、Apache ab の待機時間は 3 秒、6 秒、9 秒のように 3 秒単位で増加します。Apache ab は、指定された content length に基づいてリクエストが成功したかどうかを判断します。ベンチマーク対象の NLB インスタンスが複数のバックエンドサーバーに関連付けられている場合、これらのバックエンドサーバーから返されるレスポンスコンテンツの実際の長さが、指定された content length と異なる可能性があります。これにより、ストレステストの結果が不正確になります。

ストレステストのスコアが低い場合に考えられる原因

ストレステストのスコアが低い場合に考えられる原因は次のとおりです：

• クライアントポートの不足

  ストレステスト中に、NLB インスタンスに十分なフロントエンドポートがない場合、クライアントは NLB インスタンスとの接続を確立できません。NLB インスタンスは、デフォルトで TCP 接続のタイムスタンププロパティを削除します。その結果、Linux スタックの `tw_reuse` フラグが無効になります。`tw_reuse` フラグは、`time_wait` 状態の接続を再利用するために使用されます。したがって、このフラグが無効になると、`time_wait` 状態の接続が蓄積され、NLB インスタンスのフロントエンドポートを占有します。

  ソリューション：クライアントで短時間接続の代わりに持続的接続を使用します。さらに、`SO_LINGER` ソケットオプションを設定して、リセット (RST) パケットを使用して接続を閉じます。

• バックエンドサーバーの accept キューが満杯

  バックエンドサーバーの accept キューが満杯の場合、バックエンドサーバーは SYN-ACK パケットを返せなくなります。その結果、クライアントはタイムアウトします。

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

• バックエンドサーバーの不足

  クライアント IP の維持機能を無効にすると、NLB インスタンスは自身の IP アドレスを使用してバックエンドサーバーとの接続を確立します。デフォルトでは、各バックエンドサーバーは最大 120,000 の同時接続をサポートします。バックエンドサーバーの数が少ない場合、同時接続数は制限されます。

  ソリューション：NLB インスタンスが TCP または UDP リスナーを使用する場合、クライアント IP の維持機能を有効にすることを推奨します。NLB インスタンスが SSL over TCP を使用するリスナーを使用する場合、NLB インスタンスにバックエンドサーバーを追加するか、自動スケーリングを有効にすることを推奨します。

• バックエンドサーバー上のアプリケーションの依存関係がパフォーマンスボトルネックになる

  バックエンドサーバーのトラフィック負荷は、バックエンドサーバーのパフォーマンス上限を下回っています。しかし、バックエンドサーバー上のアプリケーションは、データベースなどの別のアプリケーションに依存している場合があります。したがって、その依存関係がストレステストにおける NLB インスタンスのパフォーマンスを制限することもあります。

  ソリューション：バックエンドサーバー上で使用されなくなったアプリケーションをクリアします。

• バックエンドサーバーが異常

  バックエンドサーバーが異常と判断されたり、バックエンドサーバーのヘルスステータスが頻繁に変化したりすると、ストレステストにおける NLB インスタンスのパフォーマンスが低下する可能性があります。

  ソリューション：ヘルスチェックを無効にして、バックエンドサーバーに送信されるリクエストの数を減らします。

• バックエンドサーバーでのセッション競合

  標準ストレステストフレームワークを使用する場合、ストレステストで使用されるクライアントの数が少ないか、送信元 IP アドレスに基づく一貫性ハッシュが使用されていると、バックエンドサーバー間でセッション競合が発生する可能性が高くなります。その結果、次の図に示すように、バックエンドサーバーは頻繁に RST パケットを送信して接続を閉じます。

  

  ソリューション：単一 VIP ストレステストフレームワークを使用します。詳細については、「ストレステストのフレームワーク」をご参照ください。