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秒単位 (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 です。

• 不十分なバックエンドサーバー

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

  解決策: NLBインスタンスがTCPまたはUDPリスナーを使用している場合は、クライアントIP保存機能を有効にすることを推奨します。 NLBインスタンスがSSL over TCPを使用するリスナーを使用する場合は、NLBインスタンスにバックエンドサーバーを追加するか、自動スケーリングを有効にすることを推奨します。

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

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

  解決策: バックエンドサーバーで使用されなくなったアプリケーションをクリアします。

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

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

  解決策: ヘルスチェックを無効にして、バックエンドサーバーに送信されるリクエストの数を減らします。

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

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

  

  解決策: シングルVIPストレステストフレームワークを使用します。 詳細については、「Stress testing framework」をご参照ください。