内部ネットワーク通信、ステージング環境、または開発環境向けの HTTP サービスを開発していて、HTTP サービスで暗号化が不要な場合は、Classic Load Balancer (CLB) インスタンスに HTTP リスナーを追加して HTTP リクエストを転送できます。
前提条件
CLB インスタンスが作成されていること。詳細については、「CLB インスタンスの作成と管理」をご参照ください。
手順
ステップ 1: リスナーの作成
CLB コンソール にログインします。
CLB インスタンスがデプロイされているリージョンを選択します。
次のいずれかの方法でリスナー構成ウィザードを開きます。
[インスタンス] ページで、管理する CLB インスタンスを見つけ、[アクション] 列の [リスナーの構成] をクリックします。
[インスタンス] ページで、管理する CLB インスタンスの ID をクリックします。[リスナー] タブで、[リスナーの追加] をクリックします。
[プロトコルとリスナー] ステップで、次の表を参照してパラメーターを設定し、[次へ] をクリックします。
パラメーター
説明
リスナープロトコル
リスナープロトコルを選択します。
この例では、HTTP が選択されています。
バックエンドプロトコル
この例では、HTTP リスナーが作成されます。バックエンドプロトコル は HTTP に設定されています。
リスナーポート
バックエンドサーバーにリクエストを受信して転送するために使用されるリスナーポートを指定します。有効値:1 ~ 65535。
デフォルトでは、HTTP はポート 80 を使用します。
タグ
タグキー と タグ値 を選択または入力します。
詳細設定
[変更] をクリックして詳細設定を行います。
スケジューリングアルゴリズム
スケジューリングアルゴリズムを選択します。デフォルトでは、ラウンドロビン (RR) が選択されています。
加重ラウンドロビン (WRR): 重みの大きいバックエンドサーバーは、重みの小さいバックエンドサーバーよりも多くのリクエストを受信します。
ラウンドロビン (RR): リクエストはバックエンドサーバーに順番に配信されます。
スケジューリングアルゴリズムの詳細については、「SLB スケジューリングアルゴリズム」をご参照ください。
リスナーによるリダイレクト
HTTP リスナーからのトラフィックを HTTPS リスナーにリダイレクトするかどうかを指定します。トラフィックリダイレクトを有効にするには、HTTPS リスナーも選択する必要があります。
説明この機能を無効にした場合、リスナーの作成後にこの機能を有効にすることはできません。この機能を使用するには、別のリスナーを作成する必要があります。
トラフィックリダイレクトを有効にする前に、HTTPS リスナーが作成されていることを確認してください。詳細については、「CLB を使用して HTTP から HTTPS にリクエストをリダイレクトする」をご参照ください。
セッション維持
セッション維持はデフォルトで無効になっています。
セッション維持機能が有効になると、CLB インスタンスは同じクライアントからのリクエストを同じバックエンドサーバーに配信します。CLB は Cookie に基づいて HTTP セッションの永続化を有効にします。
Cookie オプション:
Cookie の挿入: このオプションを選択した場合は、Cookie のタイムアウト期間のみを指定する必要があります。
CLB は、クライアントに送信される最初の HTTP または HTTPS レスポンスに Cookie (SERVERID) を挿入します。クライアントからの次のリクエストには Cookie が含まれており、リスナーは記録されたバックエンドサーバーにリクエストを転送します。
永続的タイムアウト: Cookie の挿入 を選択した場合は、セッション維持のタイムアウト期間を指定します。
Cookie の書き換え: このオプションを選択した場合は、HTTP または HTTPS レスポンスに挿入する Cookie を指定する必要があります。この場合、バックエンドサーバーで Cookie のタイムアウト期間と有効期間を指定する必要があります。
Cookie を指定すると、CLB は元の Cookie を指定された Cookie で上書きします。次回 CLB が指定された Cookie を含むクライアントリクエストを受信すると、リスナーは記録されたバックエンドサーバーにリクエストを配信します。
Cookie 名: Cookie の書き換え を選択した場合は、Cookie の名前を指定する必要があります。
アクセスの制御
アクセスの制御はデフォルトで無効になっています。
アクセスの制御を有効にした後、アクセスの制御方法を選択します。次に、アクセス制御リスト (ACL) をリスナーのホワイトリストまたはブラックリストとして選択します。
ホワイトリスト:指定した IP アドレスからの SLB インスタンスへのアクセスを許可する。ネットワーク ACL で指定された IP アドレスまたは CIDR ブロックからのリクエストのみが転送されます。ホワイトリストは、特定の IP アドレスからのアクセスのみを許可する場合に適用されます。ホワイトリストが正しく構成されていないと、サービスに悪影響を与える可能性があります。ホワイトリストが構成されると、ホワイトリストに追加された IP アドレスからのリクエストのみがリスナーによって転送されます。
ホワイトリストが構成されていても、ホワイトリストに IP アドレスが追加されていない場合、リスナーはすべてのリクエストを転送します。
ブラックリスト:指定した IP アドレスからの SLB インスタンスへのアクセスを禁止する。ネットワーク ACL で指定された IP アドレスまたは CIDR ブロックからのリクエストは拒否されます。ブラックリストは、特定の IP アドレスからのアクセスを拒否する場合に適用されます。
ブラックリストが構成されていても、ブラックリストに IP アドレスが追加されていない場合、リスナーはすべてのリクエストを転送します。
ホワイトリスト: ネットワーク ACL で指定された IP アドレスまたは CIDR ブロックからのリクエストのみが転送されます。ホワイトリストは、特定の IP アドレスからのアクセスのみを許可する場合に適用されます。ホワイトリストが正しく構成されていないと、サービスに悪影響を与える可能性があります。ホワイトリストが構成されると、ホワイトリストに追加された IP アドレスからのリクエストのみがリスナーによって転送されます。
ホワイトリストが構成されていても、ホワイトリストに IP アドレスが追加されていない場合、リスナーはすべてのリクエストを転送します。
ブラックリスト: ネットワーク ACL で指定された IP アドレスまたは CIDR ブロックからのリクエストは拒否されます。ブラックリストは、特定の IP アドレスからのアクセスを拒否する場合に適用されます。
ブラックリストが構成されていても、ブラックリストに IP アドレスが追加されていない場合、リスナーはすべてのリクエストを転送します。
説明IPv6 インスタンスは IPv6 ACL にのみ関連付けることができます。IPv4 インスタンスは IPv4 ACL にのみ関連付けることができます。詳細については、「ACL の作成」をご参照ください。
ピーク帯域幅制限の有効化
帯域幅課金 CLB インスタンスを使用している場合、各リスナーの最大帯域幅を設定して、リスナーによって転送されるネットワークトラフィックの量を制限できます。CLB インスタンスに追加されるすべてのリスナーの最大帯域幅の合計は、CLB インスタンスの最大帯域幅を超えることはできません。デフォルトでは、この機能は無効になっており、「すべてのリスナーが CLB インスタンスの帯域幅を共有する」ようになっています。
重要たとえば、インターネット向け CLB インスタンスの最大帯域幅が 5 Mbit/s で、2 つのリスナーを構成するとします。リスナー A に 5 Mbit/s の帯域幅を割り当て、リスナー B には帯域幅を割り当てません。この場合、リスナー B にはアクセスできません。帯域幅を割り当てる際には注意してください。
内部向け CLB インスタンスに 3 つのリスナーが構成されていて、リスナー A とリスナー B に割り当てられた合計帯域幅が 5,120 Mbit/s の場合、リスナー C にはアクセスできません。帯域幅を割り当てる際には注意してください。
トラフィック課金 CLB インスタンスを使用している場合、リスナーの帯域幅はデフォルトで無制限です。
アイドル接続タイムアウト期間
CLB とクライアント間の TCP 接続でデータが転送されていないときに接続を開いたままにできる最長時間を指定します。
指定されたタイムアウト期間内にリクエストが受信されない場合、CLB は接続を閉じます。リクエストが受信されると、CLB は新しい接続を確立します。
説明このタイムアウト期間は、リスナーに関連付けられているすべてのサーバーグループに適用されます。特定のバックエンドサーバーに別のタイムアウト期間を指定する場合は、このバックエンドサーバー用に別のリスナーを作成し、必要なタイムアウト期間を設定します。
接続リクエストタイムアウト
指定されたタイムアウト期間内にバックエンドサーバーから応答が受信されない場合、CLB はクライアントに HTTP 504 状態コードを返します。このパラメーターの有効値の範囲は 1 ~ 180(秒)です。
GZIP 圧縮
GZIP 圧縮を有効にすると、特定の種類のファイルが圧縮されます。GZIP 圧縮を無効にすると、ファイルは圧縮されません。この機能はデフォルトで有効になっています。
GZIP は、次のファイルタイプをサポートしています:
text/xml
、text/plain
、text/css
、application/javascript
、application/x-javascript
、application/rss+xml
、application/atom+xml
、application/xml
。カスタム HTTP ヘッダー
追加する HTTP ヘッダーを選択します。有効値:
X-Forwarded-For: Retrieve Client IP
: クライアント IP アドレスを取得します。説明デフォルトでは、CLB のレイヤー 7 リスナーは X-Forwarded-For ヘッダーを使用してクライアント IP アドレスを保持します。ヘッダーを無効にすることはできません。複数の IP アドレスが保持されている場合、最初の IP アドレスがクライアント IP アドレスです。詳細な構成については、「レイヤー 7 リスナーがクライアント IP アドレスを保持してバックエンドサーバーに渡すことを有効にする」をご参照ください。
SLB-ID: Retrieve SLB ID
: CLB インスタンスの ID を取得します。SLB-IP: Retrieve SLB IP
: CLB インスタンスの IP アドレスを取得します。X-Forwarded-Proto: Retrieve Listener Protocol
: リスナープロトコルを取得します。
クライアント IP アドレスの保持
この機能はクライアントの IP アドレスを取得し、デフォルトで有効になっています。
リスナーの自動有効化
リスナーの作成後すぐにリスナーを有効にするかどうかを指定します。デフォルトでは、リスナーは作成後に有効になります。
ステップ 2: バックエンドサーバーの追加
リスナーを作成したら、クライアントリクエストを処理するためにバックエンドサーバーを追加する必要があります。CLB インスタンスに構成されているデフォルトサーバーグループを使用できます。 vServer グループを作成することもできます。詳細については、「CLB サーバーグループ」をご参照ください。
この例では、バックエンドサーバーはデフォルトサーバーグループに追加されます。
HTTP リスナーはプライマリ/セカンダリサーバーグループをサポートしていません。
[バックエンドサーバー] ステップで、[デフォルトサーバーグループ] を選択し、[さらに追加] をクリックします。
[サーバー] ステップで、追加するバックエンドサーバーを選択し、[次へ] をクリックします。
[ポート/重み] ステップで、バックエンドサーバーの重みを構成します。
説明デフォルトの重みは 100 です。重みの大きいバックエンドサーバーは、より多くのリクエストを受信します。
バックエンドサーバーの重みが 0 に設定されている場合、リクエストはバックエンドサーバーに配信されません。
[追加] をクリックします。バックエンドサーバーがリクエストを受信するために使用するポートを指定します。有効値:1 ~ 65535。
同じ CLB インスタンスに追加されるバックエンドサーバーに同じポートを指定できます。
ステップ 3: ヘルスチェックの構成
CLB は、ヘルスチェックを実行することでバックエンドサーバーの可用性をチェックします。ヘルスチェック機能は、全体的なサービスの可用性を向上させ、バックエンドサーバーの障害の影響を軽減します。
オプション: [ヘルスチェック] ステップで、[変更] をクリックしてヘルスチェック構成を変更し、[次へ] をクリックします。詳細については、「CLB ヘルスチェックの構成と管理」をご参照ください。
[確認] ステップで、リスナーの構成を確認します。[変更] をクリックして構成を変更できます。
構成を確認し、[送信] をクリックします。[構成に成功しました] メッセージで、[OK] をクリックします。
リスナーを構成すると、[リスナー] タブでリスナーを表示できます。
よくある質問
レイヤー 7 CLB によって転送されるバックエンドサーバーから返されるレスポンスから、一部の HTTP ヘッダーが削除されるのはなぜですか?
セッション維持を実装するために、CLB はクライアントに転送する前に、バックエンドサーバーから受信したレスポンスの Date、Server、X-Pad、X-Accel-Redirect などの HTTP ヘッダーを変更します。
解決策:
CLB によるヘッダー処理をバイパスするために、バックエンドサーバーで構成するカスタム HTTP ヘッダーにプレフィックス(xl-server や xl-date など)を追加します。
レイヤー 4 リスナーを使用します。
CLB が HTTP リクエストに Transfer-Encoding: chunked ヘッダーを追加するのはなぜですか?
問題:
カスタムドメイン名をレイヤー 7 CLB インスタンスの IP アドレスに解決した後、ローカル PC からカスタムドメイン名にアクセスすると、HTTP リクエストに Transfer-Encoding: chunked
ヘッダーが追加されます。ローカル PC からバックエンドサーバーに直接アクセスすると、このヘッダーは存在しません。
原因:
レイヤー 7 CLB インスタンスは、Tengine リバースプロキシに基づいて負荷分散を実装します。Transfer-Encoding ヘッダーは、Web サーバーがレスポンスメッセージ本文をどのようにエンコードするかを示します。たとえば、Transfer-Encoding: chunked
は、チャンク転送エンコーディングが使用されていることを示します。
このヘッダーは、レイヤー 4 リスナーによって転送されるリクエストには追加されません。レイヤー 4 リスナーはトラフィックを配信するだけだからです。
WebSocket をサポートするように CLB リスナーを構成するにはどうすればよいですか?
デフォルトでは、CLB HTTP リスナーは WebSocket をサポートしています。詳細については、「WebSocket を使用してリアルタイムメッセージングを有効にする」をご参照ください。