製品アップデート情報
製品に関するお知らせ
CLB設定関連
コンセプトに関するご質問
ヘルスチェックに関するご質問
アクセスに関するご質問
レイヤー4のロードバランシングとレイヤー7のロードバランシングにはどのような違いがありますか。
レイヤー4のバランシング機能はIP+ポートベースのロードバランシングです。
レイヤー7のものはアプリケーション層の情報（HTTPヘッダー、URLなど）をベースにしたロードバランシングです。
レイヤー4からレイヤー7のロードバランシングでは、バックエンドサーバーのロードバランシングを行う際に、レイヤー4の情報またはレイヤー7の情報に基づいてトラフィックの転送方法を決定します。
例えば、レイヤー4のロードバランシングでは、レイヤー3のIPアドレス（VIP）を指定し、その後レイヤー4のポート番号を追加することで、どのトラフィックにロードバランシングが必要かが決定されます。処理が必要なトラフィックに対しNAT処理を行い、バックエンドサーバーに転送し、このTCPまたはUDPのトラフィックがどのサーバーによって処理されたかを記録します。その後、この接続のすべてのトラフィックが同一のサーバーに転送されて処理されるようになります。
レイヤー7のロードバランシングは、レイヤー4をベースにした上で、アプリケーション層の特徴を考慮に入れたものです。
例えば、同一のWebサーバーのロードバランシングでは、処理が必要なトラフィックかどうかをVIPおよび80番ポートで識別するだけでなく、レイヤー7のURL、ブラウザの種類、言語によってもロードバランシングの要否を決定することができます。
レイヤー7のロードバランシングは「コンテンツスイッチング」とも呼ばれ、主にメッセージ内の意味のあるアプリケーション層コンテンツに基づいた上で、さらにロードバランサが設定するサーバー選択メソッドによって、最終的に選択する内部サーバーを決定するものでもあります。
レイヤー7のロードバランシングでは真のアプリケーション層コンテンツに基づいてサーバーを選択する必要があり、先にプロキシとして最終的なサーバーとクライアント間の接続を確立（3ウェイハンドシェイク）してからでなければ、クライアントから送信される真のアプリケーション層コンテンツメッセージを受信できません。その後、このメッセージ内の特定のフィールド、およびロードバランサが設定するサーバー選択メソッドによって、最終的に選択する内部サーバーが決定されます。ロードバランサとフロントエンドのクライアントならびにバックエンドのサーバー間にはそれぞれTCP接続が確立されます。
UDPプロトコルとTCPプロトコルにはどのような違いがありますか。
TCPはコネクション型のプロトコルであり、実際にデータの送受信を行う前に、相手との間で信頼できる接続を確立する必要があります。UDPはコネクションレス型のプロトコルであり、 データ送信前に相手と3ウェイハンドシェイクを行うことなく、直接データパケットを送信します。UDPプロトコルは主に、リアルタイム性が重視され、信頼性は相対的に重視されないシーン（ビデオチャット、金融マーケット情報のリアルタイムプッシュ、DNS、IoTなど）に適しています。
CLBのCookiesベースのセッション維持方式の原理はどのようなものですか。
Cookie挿入ベース方式では、Cookieの挿入はCLBが行い、バックエンドサーバーは何の変更も行いません。クライアントが最初のリクエストを行うと、クライアントのHTTPリクエスト（Cookieを含まない）がCLBに入り、CLBはロードバランシングアルゴリズムポリシーに基づいてバックエンドのサーバーを選択し、そのサーバーにリクエストを転送します。バックエンドサーバーはHTTPレスポンス（Cookieを含まない）をCLBに返します。CLBはCookieを挿入し、HTTPレスポンス（Cookieを含む）をクライアントに返します。
クライアントリクエストが再度発生すると、クライアントのHTTPリクエスト（前回CLBが挿入したCookieを含む）がCLBに入り、CLBはCookie内のセッション維持数値を読み取り、HTTPリクエスト（上記と同様のCookieを含む）を指定のサーバーに送信します。バックエンドサーバーはリクエスト応答を行いますが、サーバーはCookieの書き込みを行わないため、HTTPレスポンスにはCookieが含まれません。レスポンストラフィックが再度CLBに入った際に、CLBが更新後のセッション維持Cookieを再度書き込みます。
バックエンドサーバーの重みとは何ですか。
ユーザーはバックエンドサーバープール内の各CVMの転送の重みを指定することができます。重みの比率が高いほど、CVMにより多くのアクセスリクエストが分配されます。ユーザーはバックエンドCVMの対外サービス機能および状況に応じてそれぞれ設定することができます。
セッション維持機能を同時に有効化している場合、バックエンドアプリケーションサーバーへのアクセスが完全に同一にならない可能性があります。その場合はセッション維持機能を一時的に無効にし、その状態が継続するかどうかを観察してください。
重みを0に設定することとRSのバインド解除にはどのような違いがありますか。
重みを0に設定：TCPリスナーの既存の接続は転送を継続し、UDPリスナーは同一の5つ組による転送を継続し、 HTTP/HTTPSリスナーの既存の接続は転送を継続します。
RSのバインド解除：TCP/UDPリスナーの既存の接続は転送を停止し、HTTP/HTTPSリスナーの既存の接続は転送を継続します。
ヘルスチェックで異常が示された場合はどう対処すればよいですか。
次の手順でトラブルシューティングを実施してください。
バックエンドサーバーを介して直接アプリケーションサービスにアクセスしていることを確認します。
バックエンドサーバーが対応するポートを有効にしていることを確認します。
バックエンドサーバー内部にファイアウォールのようなセキュリティソフトウェアがないかをチェックします。これによってCLBシステムがバックエンドサーバーと通信できなくなっている可能性があります。
CLBのチェックパラメータの設定が正しいかどうかをチェックします。
ヘルスチェックは静的ページを使用して行うことをお勧めします。
バックエンドのCVMに、高負荷による外部への応答遅延が起こっていないかをチェックします。
CVMのサブマシンにiptablesの制限がないことを確認します。
ヘルスチェックのチェック頻度が高すぎるのはなぜですか。
ヘルスチェックのチェック用パケットの頻度が高すぎ、コンソールでチェック用パケットの受信を5秒に1回に設定しているのに、実際にバックエンドサーバーでは1秒に1回もしくはそれ以上のヘルスチェックリクエストを受信している場合、次のような原因が考えられます。
現在、ヘルスチェックの頻度が高すぎる問題は、主にCLBのバックエンドヘルスチェックの実現メカニズムに関連しています。例えば100万のclientリクエストを4台のCLBバックエンド物理マシンに分散させ、バックエンドサーバーに転送するとします。 ヘルスチェックはCLBのバックエンド物理マシン上でそれぞれ行われます。このため、CLBインスタンスで5秒に1回のチェックリクエストを設定すると、実際のCLBバックエンドの各物理マシンがすべて5秒に1回のチェックを送信します。このためバックエンドサーバーでは複数回のチェックリクエストを受信することになります。CLBインスタンスが存在するクラスターに8台の物理マシンがあるとすると、各マシンが5秒に1回リクエストを送信するため、バックエンドホストは5秒間に8回のチェックを受信する可能性があります。
この実現スキームのメリットは、高効率でチェックの正確性が高く、誤削除を防止できる点にあります。例えば、CLBインスタンスクラスターの8台の物理マシンのうち、1台が失敗と判断されても、その1台がトラフィックを転送しなくなるだけで、残りの7台のトラフィックは正常です。
このため、バックエンドサーバーのチェック頻度が高すぎる場合は、チェック間隔を長く設定することで解決できます（例えば15秒に1回のチェックに設定するなど）。
負荷転送中のHTTPリダイレクトの問題
ブラウザがウェブサイト
http://example.comにアクセスした場合、サーバーはリダイレクトを1回行い、ルートディレクトリへの遷移が必要と判断します。一方、ブラウザがウェブサイトhttp://example.com/にアクセスした場合、サーバーはウェブサイトに設定されたルートディレクトリのデフォルトページを直接返します。同様に、http://cloud.tencent.com/movieがURLリライトによってhttp://cloud.tencent.com/movie/にリダイレクトされる場合、http://cloud.tencent.com/movieを入力すると、URLリライトのプロセスが1回多くなり、パフォーマンスと時間にわずかなロスが生じますが、結果はあまり変わりません。http://cloud.tencent.com/productがURLリライトによってhttp://cloud.tencent.com/product/と異なるページにリダイレクトする場合は、セカンドページの後に/を追加することを検討する必要があります。Tencent Cloud CLBでは、フロントエンドとバックエンドのポート番号が一致しない場合、HTTPリダイレクト後にポート番号が変更されることを防ぐため、セカンドページへのアクセスの際に
/を追加し、ページへの正常なアクセスを保証する必要があります。レイヤー7の転送において、CLBインスタンスが80番ポートをリスニングし、バックエンドサーバーが8081番ポートをリスニングしているとします。この場合、クライアントが
http://www.example.com/movieにアクセスし、CLBによってバックエンドサーバーに転送され、サーバーがhttp://www.example.com/movieあてのリクエストを受信してhttp://www.example.com:8081/movie/ （リスニングポートは8081）にリダイレクトした場合、クライアントからのアクセスは失敗します（ポートエラー）。このため、ユーザーのアクセスリクエストを
http://www.example.com/movie/ のような、/付きのセカンドページに書き換えることをお勧めします。こうすることでHTTPリダイレクトを避け、不必要な判断を1回減らし、不必要な負荷を低減することができます。HTTPリダイレクトを使用する必要がある場合は、CLBのリスニングポートとバックエンドサーバーのリスニングポートを必ず同一にしてください。
どのTCPポートでロードバランシングを実行できますか。
ロードバランシングを実行できるTCPポートは、21（FTP）、25（SMTP）、80（HTTP）、443（HTTPS）、1024～65535などのポートです。
843のpolicyリクエスト（flash serverリクエスト）を送信した際、ポリシーファイルが返されず、接続がそのまま切断されましたが、どのように対処すればよいですか。
CLBは843のpolicyリクエストを受信すると、汎用crossdomainポリシー設定ファイルを自動的に返します。ポリシーファイルが返されず、接続がそのまま切断される状況が発生した場合は、flash serverリクエストが正しくなかった可能性があります。
正確なflash serverのリクエストを送信していることを確認してください：\\0 。
ご注意：
ここでは\\0を末尾にした、合計23バイトとする必要があります。\\0はASCIIコードの0を表す記号であり、1バイトとして数えられます。
正常な843からは下図のような結果が返されます。
CLBはClient IPを直接取得できますか。
IPv6 NAT64CLBではClient IPの取得をサポートしていません。
パブリックネットワークのレイヤー7 IPv4およびIPv6 CLBはX-Forwarded-Forによってアクセス元のリアルIPを取得します。CLB側ではデフォルトで有効化されていますが、Client IPを取得するにはバックエンドサービスで必要な設定を行う必要があります。詳細については、クライアントリアルIPの取得方法をご参照ください。
パブリックネットワークのレイヤー4 IPv4およびIPv6 CLB（TCPプロトコル）サービスは、バックエンドCVM上でアクセス元のリアルIPアドレスを直接取得することができ、追加の設定は必要ありません。プライベートネットワークのレイヤー4 CLBは、2016年10月24日以降の新規インスタンス購入分からSNAT処理を実施せず、サーバー側で直接client IPを取得できるようになっています。こちらも追加の設定は必要ありません。
CVMにプライベートネットワークCLBを設定し、トラフィックをポートAから同じサーバーの別のポートに転送することはできますか。
できません。サーバー （10.66.*.101）のポートaに対するアクセスはプライベートネットワークCLBを介してリクエストをサーバーB（10.66.*.102）のポートbに転送します。しかし、トラフィックを同一のサーバーA（10.66.*.101）の別のポートbに転送することはできません。
バックエンドCVMにはパブリックネットワーク帯域幅が必要ですか。それがCLBのサービスに影響することはありますか。
標準アカウントタイプのCLBにバインドしたバックエンドCVMにはパブリックネットワーク帯域幅を設定する必要はありません。
従来型アカウントタイプのCLBではトラフィックまたは帯域幅料金は発生しません。CLBサービスによって発生するパブリックネットワークトラフィック料金は、バインドしたバックエンドCVMで課金されます。バックエンドCVMの購入の際に、パブリックネットワーク帯域幅はトラフィック課金を選択し、適正な帯域幅ピーク値の上限を設定しておくと、CLBの出口の合計トラフィックが上下する心配をせずに済むため、お勧めします。インターネットWeb業務ではトラフィックの増減幅が大きく、正確に予測することができません。帯域幅課金にした場合、購入する帯域幅が大きすぎると採算が取れず、小さすぎると業務のピーク時にパケットロスが発生してしまいます。
クライアントとサーバーのHTTPバージョンが異なる場合の互換バージョンについての説明
転送の互換性
フロントエンド（client側）では現在HTTP1.0/1.1をサポートしており、後方互換性を有します。
バックエンド（server側）では現在Tencent CloudはHTTP1.0プロトコルを使用しており、HTTP1.0/1.1をサポートしています。後方互換性を有します。
ご注意：
HTTP/2はHTTPSでのみサポートされ、かつclientとserverは後方互換性を有します。現在HTTPプロトコルはサポートしていません。
Gzipの互換性サポート
フロントエンド（client側）では現在HTTP1.0/1.1をサポートしており、後方互換性を有します。（ユーザーによる設定は必要ありません。主なブラウザはすべてGzipをサポートしています）
バックエンド（server側）については、CVMでは、Tencent Cloud内部の全ネットワークでHTTP/1.1プロトコルをサポートしているため、ユーザーは設定の必要なく、Nginxのデフォルト設定（HTTP/1.1）を使用して互換が可能です。
ご注意：
HTTP/2はHTTPSでのみサポートされますが、GzipはTencent Cloudのサポートする任意のHTTPバージョンで使用できます。
CLBバックエンドサーバーのセキュリティグループはどのように設定すればよいですか。アクセスブラックリストはどのように設定しますか。
CLBセキュリティグループの設定
バックエンドサーバーにセキュリティグループルールを設定している場合、CLBインスタンスがサーバーと通信できない状況が発生する可能性があります。このため、レイヤー4転送およびレイヤー7転送においては、バックエンドサーバーのセキュリティグループを「すべて許可」に設定することをお勧めします。セキュリティグループを有効化し、すべてのプロトコルの全ipセグメントのアドレスからのアクセスをデフォルトで許可する場合は、すべてのクライアントIPをローカルマシンIPのセキュリティグループルールに設定する必要があります。
悪意あるIPについては、悪意あるIPをセキュリティグループの上位に配置するルールを設定し、それらがバックエンドサーバーにアクセスできないようにすることができます。さらにすべてのIP（0.0.0.0）にローカルサービスポートへのアクセスを許可することで、正常なクライアントがアクセスできるようにします。（セキュリティグループルールには順序があり、上から下の順でマッチングします）
VPC内のレイヤー7負荷転送にヘルスチェックを設定している場合は、CLB VIPをバックエンドサーバーのセキュリティグループ許可ルールに必ず追加する必要があり、これを行わなければヘルスチェックが無効になる可能性があります。
アクセスブラックリストの設定
ユーザーがいくつかのClient IPをブラックリストに設定し、そのアクセスを拒否したい場合は、クラウドサービスに関連付けたセキュリティグループによって実現することができます。セキュリティグループのルールは次の手順に従って設定する必要があります。
ご注意：
下記の設定手順には順序要件があります。順序を逆にすると、ブラックリストの設定が無効になります。
アクセスを拒否したいclient IP + ポートをセキュリティグループに追加し、ポリシー欄でこのIPからのアクセス拒否を選択します。
設定完了後、セキュリティグループルールを1つ追加し、このポートを全IPからのアクセスにデフォルトで開放します。
設定完了後、セキュリティグループルールは次のようになります。
clientA ip+port dropclientB ip+port drop0.0.0.0/0+port accept
CLBとバックエンドサーバーの間の通信はプライベートネットワークとパブリックネットワークのどちらで行われますか。
CLBとバックエンドサーバーとの通信は常にプライベートネットワークによって行われます。バインドしたCVMにパブリックIPがある場合も同様です。
CLB VIPのPingに関する説明
CLBのVIPに対するPingへの応答はCLBクラスターによって行われ、バックエンドのサーバーには転送されません。
パブリックネットワークCLBのVIPはPingをサポートしています。
プライベートネットワークCLBのVIPは、そのVPCのクライアントからのPingのみサポートします。その他のVPC、ローカルIDCのクライアントのPingは応答であり、実際のリンクを反映できないため、Pingの送信を保障できません。（CCN、Peering Connectionなどを使用してVPCに接続している場合は、Telnet を使用したチェックをお勧めします）。
CLBリスニングポートのTelnetに関する説明
レイヤー4（TCP、UDP、TCP SSL）リスナーを作成後、バックエンドサーバーをバインドしていない場合は、Telnetによるリスニングポートへの接続はできません。バックエンドサーバーをバインドすると、Telnetによってリスニングポートに接続できるようになります。
レイヤー7（HTTP、HTTPS）リスナーを作成後は、バックエンドサーバーをバインドしていなくても、Telnetによってリスニングポートに接続でき、応答はCLBが代わりに行います。
プライベートネットワークのループバック問題に関する説明
プライベートネットワークCLBでは同一のCVMをクライアントとサーバーの両方として使用することはできません。この場合、Client IPとServer IPが同一であるとCLBが判断するため、アクセスができなくなります。
クライアントとサーバーを同じにする必要がある場合は、少なくとも2台のバックエンドサーバーをバインドしてください。CLBにはループバック自動防止ポリシーがあり、Client AがCLBにアクセスした際、CLBはClient A以外のバックエンドサーバー上に自動的にスケジューリングします。
同一のクライアントが異なる中間ノードを介して同一のバックエンドサーバーの同一ポートにアクセスする際のストリーミングの問題に関する説明
問題の現象
同一のクライアントが同じ時刻に、異なる中間ノードを介して同一のバックエンドサーバーの同一ポートにアクセスすると、ストリーミング現象が発生します。具体的なシナリオは次のとおりです。
同一のクライアントが、同時に同一のCLBのレイヤー4、レイヤー7リスナーを介して、同一のバックエンドサーバーの同一ポートにアクセスする場合。
同一のクライアントが、同時に異なるCLBの異なるリスナーを介して、同一のバックエンドサーバーの同一ポートにアクセスする場合。
プライベートネットワークCLBのクライアントが比較的集中していて、かつバックエンドサービスが同一の場合に、比較的高確率でストリーミングが発生します。（パブリックネットワークCLBにアクセスするクライアントはアクセス元が幅広いため、ストリーミングが発生しにくくなっています。）
問題の原因
現在、CLBはクライアントIPをバックエンドサーバーにパススルーするため、
client_ip:client_port -> vip:vport -> rs_ip:rs_portが最終的にclient_ip:client_port --> rs_ip:rs_portに変わります。ソリューション
クライアントの分散：複数のクライアントを使用してアクセスを開始します。
CLBの集約：業務上の機能および障害復旧のニーズを満たすことを前提として、CLBのインスタンス、リスナーの個数を減らします。
バックエンドサービスポートの分散：複数のポートを使用してバックエンドサービスを提供することで、バックエンドポートの集中を防止します。
デプロイの分散：例えばCLB1に1組のCVMを、CLB2にもう1組のCVMをそれぞれバインドするなど、CLBごとに異なるバックエンドサービスポートをバインドし、2つのCLBで同時にアクセスを提供します。
バックエンドCVMのセキュリティグループへのパブリックネットワークからのアクセスを禁止し、CLBからのアクセスのみを許可しましたが、有効にならないのはなぜですか。
CLBを介してバックエンドCVMにアクセスしたい場合、バックエンドCVMとCLBの2つのセキュリティグループがどちらもパブリックネットワークからのアクセスを許可している必要があります。先にバックエンドCVMのセキュリティグループに、CLBのVIPパブリックネットワークからのアクセスのみを許可し、CLBのセキュリティグループは必要に応じてパブリックネットワークのアクセスIPを許可することをお勧めします。
CLBにリスナーを設定し、バックエンドCVMとのバインドを行いました。ドメイン名をバックエンドCVMのIPに解決してドメイン名にアクセスしても、CLBに具体的な情報がモニタリングされないのはなぜですか。
具体的なモニタリング情報を得るには、CLBを介してアクセスする必要があります。ドメイン名をCLBのIPに解決してドメイン名にアクセスすると、CLBのモニタリングによって具体的な情報を確認することができます。
843 ポートの説明
843 ポートはデフォルトで閉じられています。
CLBのアクセスログ内に記録された9/11ネットワークセグメントのアドレスはTencent Cloudプライベートネットワークのネットワークセグメントですか。
はい。Tencent CloudのCLB製品は9/11ネットワークセグメントのアドレスをプライベートネットワークのネットワークセグメントアドレスとして使用します。
フィードバック