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

作成日:2018/04/12この記事は最終更新日から4年以上が経過しています。

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

本記事では、Alibaba Cloud Server Load Balancer(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サーバーにされ均等に分割され、転送されます。同じようにリスナーで設定された帯域幅のピーク値も、均等に分割され各サーバに設定されます。シングル接続ダウンロードトラフィック上限公式は以下のとおりです。

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

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

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

最後に

お客様から寄せられる「Q&A」についてまとめてある記事を紹介致しました。こちら参考に頂ければ幸いです。

Close

Alibaba Cloudを始めてみましょう

ソフトバンクは、Alibaba Cloudのアカウント開設から、サービス展開までをお手伝いします。
Hatena
このページは参考になりましたか?