SLBのよくあるQ&A

作成日:2018-04-12

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バックエンドサーバーに１台のECSを追加するだけで、リンクを確実に継続できますか？

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

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

質問：バックエンドサーバーには正常にアクセスできますが、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のネットワーク負荷は非常に低くなります。

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

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

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

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

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

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

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

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

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

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

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

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

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