Server Load Balancer(SLB)のよくあるQ&A

皆さん、こんにちは。エンジニアのryuです。今回はみんなさんよく知っている製品SLBのお話です。中国のコミュニティで良くまとまっている記事があったのでご紹介させて頂きます。

Server Load Balancer(以下、SLB)を利用することで、単一のECSのサービスへの影響が軽減され、可用性が向上します。同時に、バックエンドサーバーを動的に調整することにより、ビジネス開発にも動的に対応することができるようになります。

この記事では、SLBのよくあるQ&Aや一般的な落とし穴についてご紹介します。

SLB のよくあるQ&A

過去の事例から、SLBを利用する時に良くある質問があります。以下より説明します。

質問:SLBバックエンドサーバーに1台のECSを追加するだけで、リンクを確実に継続できますか?

ユーザーはSLBバックエンドサーバーを追加するだけでリンクを実行でき、クライアントはSLBを経由したアクセス状態になります。しかし、バックエンドサーバーが1台の状態では、冗長化ができるSLBの基本能力が活かされていません。 例えばこの1台のECSに異常が発生した場合、アクセスを継続することができなくなる可能性があります。

推奨事項:少なくとも2台のECSをSLBバックエンドサーバーに追加してください。2台構成であれば1台のサーバー異常が発生しても、通常のアクセスを継続できます。

質問:バックエンドサーバーには正常にアクセスできますが、SLBにはアクセスできません。SLBに異常が発生していますか?

ユーザーは、SLBを介してサービスにアクセスして異常を検出します。ただし、ホストにバインドされたバックエンドサーバーのパブリックIPにもアクセスできます。これに基づいて、ユーザーはバックエンドサービスが正常である、つまりSLB側に異常が発生していると判断されているようです。

実際は、ロードバランシングのためにデータ転送とヘルスチェックはイントラネットを介して実行されます。SLBではバックエンドサーバーとのパブリックネットワークIPは比較できず、実際のアクセス状態を反映していません。

推奨事項:異常が発生した場合は、バックエンドのサーバーのイントラネットIPで、お互いの比較アクセステストを行うことをおすすめします。

質問: SLB VIPにPingが通れば設定は正常ですか?

SLBのVIPアドレスにPingすることにより、SLBサービスの有効性は判断できます。

しかし、このテストだけではシステムの正常性は判断できません。Ping応答はSLBサーバーによって直接実行されるため、バックエンドサーバーとは何の関係もありません。したがって、通常の状況では

リスナーが設定されている限り、対応するリスナーが異常な状態であってもSLB VIP pingは正常に応答します。

逆にSLBがリスナーを設定していない場合、VIPはPingできません。推奨事項:レイヤ4サービスの場合は、Telnetでポートをリスナーすることでユーザビリティテストを実施することができます。レイヤ7サービスの場合は、システムからユーザビリティテストを実施してください。

質問:ヘルスチェック間隔を調整しましたが、アクセスタイムアウトが発生します。

ユーザーからの要望によりヘルスチェック間隔を増やしても、クライアント側はアクセスタイムアウトを表す504エラーを受信してしまう現象です。

ヘルスチェックとサービス転送はSLBサーバー上の同じサーバーによって実行されますが、処理ロジックの次元はまったく異なります。504エラーはSLB がクライアントからの要求をバックエンドサーバーに転送することができますが、バックエンド ECS インスタンスは要求を処理できないことを示しています。

しかし、SLBサーバはチェック間隔の設定に従って、バックエンドECSへのヘルスチェックを継続します。このヘルスチェックとサービス処理タイムアウトは連携されていません。ただし、逆にSLBがヘルスチェックに失敗すると、バックエンドECSにデータは転送されません。

推奨事項:クライアントアクセスタイムアウトとサービスおよびSLBのデフォルトタイムアウト比較分析、ヘルスチェックアウト時、ヘルスチェックとサービスタイムアウトの比較分析の組み合わせを再考してください。

質問:バックエンドECSサーバーのログと、ヘルスチェックと監視設定の間隔が矛盾しています。

お客様からのご質問より、SLBバックエンドECSビジネスログ統計分析と、高頻度のヘルスチェック間隔と比べた時に、矛盾していることが判明しました。

この問題は、ドキュメント SLBヘルスチェック概要 に記述されています。クラスタ内のノード・サーバーは、ヘルス・チェック構成に従って、独立してバックエンドECSの定期的なヘルスチェックを実行します。各LVSノードのチェック時間は同期していないため、バックエンドの1つのECSから個別の統計を作成すると、ロードバランシングによるヘルスチェック要求の間隔は一致しません。

推奨事項:ヘルスチェックの頻度が高すぎる場合、サービスに影響を与える可能性があります。ヘルスチェックの頻度を減らしたり、ヘルスチェック間隔を長くしたり、HTTP ヘルスチェックをTCP ヘルスチェックに変更することで、影響を減らすことができます。サービスの可用性を確保するため、ヘルスチェックを停止することはお勧めしません。

質問:多数のヘルスチェックを構成した場合、DDoS攻撃のようになり、サーバーのパフォーマンスが低下するのではないですか?。

SLBサーバがヘルスチェックに数百台のマシンを使用し、多数のヘルスチェック要求がDDoS攻撃のようになり、バックエンドのECSパフォーマンスが低下するのではないかどうかとのご質問です。

実際、どのようなモードのヘルスチェックであっても、DDoS攻撃に似た規模に達するには十分な大きさではありません。SLBクラスタは複数のマシンを使用します(M、1桁のレベルを想定)、バックエンドECS(Nとする)上の各サービスリスニングポートについて、設定されたヘルスチェック間隔(0秒と仮定、最低2秒が一般的に推奨されます)でヘルスチェックを実行します。TCPプロトコルヘルスチェックを例にとると、1秒あたりのヘルスチェックによって確立されるTCP接続の数は、M*N/O です。

この式から、MとNは両方とも固定であり、小さな値を有することが分かります。ヘルスチェックが最終的に発生する1秒あたりのTCP並行要求の数は、作成されるリスニングポートの数によって大きく異なります。リスニングポートが大きい場合を除いて、ヘルスチェックによって生成された接続要求はSYNフラッド攻撃レベルにまったく到達できず、バックエンドECSのネットワーク負荷は非常に低くなります。

推奨事項:ヘルスチェックの頻度が高すぎる場合、サービスに影響を与える可能性があります。ヘルスチェックの頻度を減らしたり、ヘルスチェック間隔を長くしたり、HTTP ヘルスチェックをTCP ヘルスチェックに変更することで、影響を減らすことができます。サービスの可用性を確保するため、ヘルスチェックを停止することはお勧めしません。

質問:ヘルスチェックの影響を軽減するために、ヘルスチェック間隔を長く設定しても良いですか?

ヘルスチェックがビジネスに及ぼす影響を軽減するために、お客様はチェック間隔を非常に長く設定します。

この構成では、バックエンドECSが使用できないことを検出し、負荷分散するのに時間がかかります。特に、バックエンドECSが断続的に利用できない場合、検査間隔が不十分なため異常なECSを検出できない場合があります。

推奨事項:ヘルスチェックの頻度が高すぎる場合、サービスに影響を与える可能性があります。ヘルスチェックの頻度を減らしたり、ヘルスチェック間隔を長くしたり、HTTP ヘルスチェックをTCP ヘルスチェックに変更することで、影響を減らすことができます。サービスの可用性を確保するため、ヘルスチェックを停止することはお勧めしません。

質問:サーバーを削除するのと重みをゼロにすることは同じですか?

お客様はビジネス調整を行う場合、サーバーをSLBバックエンドから直接削除することと、重みをゼロに設定することは同じだと考えているようです。

実際は両者の間には大きな違いがあり、関連する業務のビジネスへの影響も違います。サーバーの削除:確立された接続は中断され、新しい接続もECSに転送されません。

重みゼロに設定:確立された接続は、タイムアウトするか、アクティブに切断されるまで中断されません。新しい接続はECSに転送されません。推奨事項:サービスの調整またはサーバーのメンテナンス中は、接続がゼロになるまで、対応するサーバーの重みをゼロに設定してください。操作が完了後、重み設定を戻せばビジネスへの影響を減らせます。

質問:リスニング構成の帯域幅のピークまで使用できないのですが。

リスナー作成時のSLB帯域幅のピークを指定することができます。しかし、とあるお客様が1台のクライアントでテストされたとき、ピークに達したことはありませんでした。

SLBはクラスタの展開とサービスに基づいています。すべてのフロントエンドリクエストは、クラスタ内の異なるSLBサーバーにされ均等に分割され、転送されます。同じようにリスナーで設定された帯域幅のピーク値も、均等に分割され各サーバに設定されます。シングル接続ダウンロードトラフィック上限公式は以下のとおりです。

シングル接続ダウンロードのピーク=設定されたロードバランシングの合計帯域幅/(N1)
*注記:N はトラフィック転送パケットの数です。現在デフォルトは 4

例:コンソールに設定されたピーク帯域幅が10Mbであると仮定すると、単一のクライアントのダウンロード可能な最大トラフィックは次のようになります。 10/(4-1)≈3.33Mb

推奨事項:シングルリスナーの帯域幅を設定する場合は、実際のビジネス状況に応じて、上記の方法と組み合わせると、より合理的な値を設定することができます。

最後に

お客様から寄せられる「Q&A」についてまとめてある記事を紹介致しました。意外と意識していない部分もあったのではないかと思います。次回はSLBのベストプラクティスとトラブルシューティングについてご紹介する予定です。ご期待ください。

参照コミュニティサイト

https://yq.aliyun.com/articles/272277

 

この記事をシェアする