アプリケーション・ロード・バランサーについて
IBM Cloud® Application Load Balancer for VPC (ALB) のアプリケーション・ロード・バランサーを使用して、VPC の同一リージョン内の複数のサーバー・インスタンス間にトラフィックを分散させることができます。
パブリック・ワークロードとプライベート・ワークロード、およびレイヤー 7 トラフィックがある場合は、アプリケーション・ロード・バランサーを使用します。
アプリケーション・ロード・バランサーのタイプ
VPC のロード・バランサーの概要 で説明されているように、パブリック ALB またはプライベート ALB を作成できます。
この表は、パブリックとプライベートの特徴を比較したものである。
| 特長 | パブリック・ロード・バランサー | プライベート・ロード・バランサー |
|---|---|---|
| インターネットでアクセス可能ですか? | はい。完全修飾ドメイン・ネーム (FQDN) を使用してアクセス可能です | いいえ。同一のリージョンと VPC 上の内部クライアントのみアクセス可能です |
| すべてのトラフィックを受け入れますか? | ある | はい (RFC-1918 アドレス・スペースからのトラフィックのみを受け入れる制限は解除されました) |
| ドメイン・ネームの登録方法 | パブリック IP アドレス | プライベート IP アドレス |
パブリック・アプリケーション・ロード・バランサー
公開アプリケーションのロードバランサーインスタンスには一般にアクセス可能な完全修飾ドメイン名(FQDN)が割り当てられ、ロードバランサーの後ろでホストされているアプリケーションにアクセスするために使わなければなりません。 このドメイン・ネームには、1 つ以上のパブリック IP アドレスを登録できます。
時が経つと、このようなパブリック IP アドレスの数と値は、メンテナンス・アクティビティーやスケーリング・アクティビティーのために変更されることがあります。 アプリケーションをホストするバックエンドの仮想サーバー・インスタンスは、同じ VPC の同じリージョンで実行する必要があります。
割り当てられた FQDN を使用してトラフィックをパブリック・アプリケーション・ロード・バランサーに送信することで、システムのメンテナンス・アクティビティーやスケールダウン・アクティビティー中にアプリケーションで接続の問題が発生するのを防止できます。
プライベート・アプリケーション・ロード・バランサー
プライベート・アプリケーション・ロード・バランサーには、ロード・バランサーを作成するように構成したプライベート・サブネットを介してアクセスできます。
パブリックアプリケーションロードバランサーと同様に、プライベートアプリケーションロードバランサーのインスタンスにも FQDN が割り当てられます。 ただし、このドメイン・ネームには 1 つ以上のプライベート IP アドレスが登録されます。
割り当てられたプライベート IP アドレスの数と値は、IBM Cloud の運用により、時が経つと、メンテナンス・アクティビティーやスケーリング・アクティビティーのために変更されることがあります。 アプリケーションをホストするバックエンドの仮想サーバー・インスタンスは、同じ VPC の同じリージョンで実行する必要があります。
割り当てられた FQDN を使用してトラフィックをプライベート・アプリケーション・ロード・バランサーに送信することで、システムのメンテナンス・アクティビティーやスケールダウン・アクティビティー中にアプリケーションで接続の問題が発生するのを防止できます。
ロード・バランシング方式
バックエンド・アプリケーション・サーバー間でトラフィックを分散させるために、以下の 3 つのロード・バランシング方式を使用できます。
ラウンドロビン
ラウンドロビンがデフォルトのロード・バランシング方式です。 この方式では、アプリケーション・ロード・バランサーは、着信クライアント接続をラウンドロビン形式でバックエンド・サーバーに転送します。 その結果として、すべてのバックエンド・サーバーは、ほぼ同数のクライアント接続を受信します。
重み付きラウンドロビン
この方式では、アプリケーション・ロード・バランサーは、バックエンド・サーバーに割り当てられた重みに比例して、着信クライアント接続をバックエンド・サーバーに転送します。 各サーバーには、デフォルトの重み 50 が割り当てられます。この重みは、0 から 100 までの範囲の任意の値にカスタマイズできます。
例えば、アプリケーション・サーバー A、B、および C の重みが 60、60、および 30 の場合、サーバー A と B は等しい数の接続を受信し、サーバー C はその半数の接続を受信します。
サーバーに重み 0 を設定することは、そのサーバーに新規接続が転送されなくなることを意味します。ただし、既存のトラフィックのフローは継続されます。 重み 0 は、サーバーを正常に終了させ、サービス・ローテーションからそのサーバーを除外したい場合に使用すると役に立ちます。
サーバーの重みの値は、「重み付きラウンドロビン」方式を使用する場合にのみ適用されます。 ラウンドロビンおよび最小接続のロード・バランシング方式では、これらの値は無視されます。
最小接続
この方式では、特定の時間に処理している接続数が最も少ないバックエンド・サーバー・インスタンスが、次のクライアント接続を受信します。
フロントエンド・リスナーおよびバックエンド・プール
フロントエンド・リスナーは、着信要求を受信するためのロード・バランサー・アプリケーション・ポートであるのに対し、バックエンド・プールは、ロード・バランサーの背後にあるアプリケーション・サーバーです。
リスナーの使用に関するガイドライン
フロントエンド・リスナーについては、以下のガイドラインを確認してください。
- 最大10個のフロントエンド・リスナーを定義し、バックエンド・アプリケーション・サーバー上のバックエンド・プールにマッピングすることができる。
- ロード・バランサーに割り当てられた FQDN とフロントエンド・リスナーのポートは、パブリック・インターネットに公開されます。 着信ユーザー要求はこれらのポートで受信されます。
- サポートされているフロントエンド・リスナーとバックエンド・プールのプロトコルは、HTTP、HTTPS、および TCP です。
- HTTP/HTTPS フロントエンド・リスナーには、HTTP/HTTPS バックエンド・プールを構成できます。
- HTTP/2 はリスナーでのみサポートされます。
- HTTP と HTTPS のリスナーおよびプールは、交換可能です。
- TCP フロントエンド・リスナーには、TCP バックエンド・プールのみを構成できます。
- バックエンド・プールには最大 50 台の仮想サーバー・インスタンスを接続できます。 トラフィックは、指定されたデータ・ポートの各インスタンスに送信されます。 このデータ・ポートは、フロントエンド・リスナー・ポートと同じである必要はありません。
- Secrets Manager の "Private only "エンドポイントは、 HTTPS リスナーではサポートされていません。 ALB で HTTPS リスナーを構成するには、TLS 証明書を「パブリックおよびプライベート」エンドポイントにアップロードする必要があります。
HTTPS リダイレクト・リスナー
HTTPS リダイレクト・リスナーは、トラフィックを HTTP リスナーから HTTPS リスナーにリダイレクトします。 このアクションは、リスナーにルールを適用する必要はない。
例えば、サービスが HTTPS を使用してポート 443 で listen し、ユーザーが HTTP を使用してポート 80 でサービスにアクセスしようとすると、要求は HTTPS を使用してポート 443 に自動的にリダイレクトされます。
HTTPS リダイレクト・リスナーにポリシーが存在する場合は、最初にポリシーが評価されます。 ポリシーにマッチするものがない場合、リクエストは設定された HTTPS リスナーにリダイレクトされる。
HTTPS リダイレクト・リスナーのプロパティー
| プロパティー | 説明 |
|---|---|
| リスナー | 要求がリダイレクトされる HTTPS リスナー。 |
| HTTP 状況コード | アプリケーション・ロード・バランサーから返される応答の状況コード。 許容値は 301、302、303, 307、または 308 です。 |
| URI | 要求がリダイレクトされる相対 URI。 これはオプションのプロパティーです。 |
弾力性
アプリケーション・ロード・バランサーは、負荷が増えるとコンピュート・リソースを追加してスケールアウトします。
SSL オフロードおよび必要な許可
セキュア・ソケット・レイヤー（SSL）オフロードにより、アプリケーション・ロードバランサーはすべての着信 HTTPS 接続を終了することができます。
HTTPS リスナーに HTTP プールを構成した場合は、HTTPS 要求がフロントエンドで終端処理されるので、ロード・バランサーはバックエンド・サーバー・インスタンスとの間にプレーン・テキストによる HTTP 通信を確立します。 この手法により、バックエンド・サーバー・インスタンスが、CPU 負荷の高い SSL のハンドシェークおよび暗号化/復号タスクから解放され、すべての CPU サイクルをアプリケーション・トラフィックの処理に使用できるようになります。
SSL オフロードを使用するには、アプリケーション・ロード・バランサーで SSL オフロード・タスクを実行するための SSL 証明書を用意する必要があります。 IBM Cloud Secrets Manager を使用して SSL 証明書を管理できます。
IAM Authorizations を使って権限を作成できます。 必ず選択してください VPC インフラストラクチャ サービスソースサービスとして特定のリソース。 クリック属性を選択選択してリソースタイプリストから。 リソースの種類として「 Load Balancer for VPC 」を選択し、「 Next 」をクリックします。 対象サービスで Secrets Manager. ターゲット・サービス・インスタンス・アクセスを「 すべてのインスタンス 」または特定の IBM Cloud Secrets Manager インスタンスに設定します。 「ライター」 のサービス・アクセス役割を割り当てます。 詳しくは、サービス間のアクセスの認可を参照してください。
エラーを回避するには、ロード・バランサーと IBM Cloud Secrets Manager の間で必要な許可を設定する必要があります。 また、 Secrets Manager 内の証明書を更新しても、ALB は自動的に更新されません。 ロード・バランサーが証明書の変更を反映するようにするには、小さな更新 (ヘルス・チェック間隔やタイムアウト値の変更など) を行ってリフレッシュを行います。 このアクションにより、ロード・バランサー上の証明書が Secrets Manager内の証明書と一致するように更新されます。 その後、行った変更を元の値に戻すことができます。
Transport Layer Security (TLS) 1.2 および 1.3 がサポートされます。 ただし、1.2 を使用するようにクライアント・サイドを明確に構成しない限り、TLS 1.3 がデフォルトで使用されます。 アプリケーション・ロード・バランサーは、クライアント・サイド要求によって送信される、サポートされるすべての TLS 1.3 暗号を受け入れます。
以下に、サポートされている暗号をリストします (優先順)。
TLS_AES_256_GCM_SHA384TLS_CHACHA20_POLY1305_SHA256TLS_AES_128_GCM_SHA256TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
証明書の CRN を見つける
コンソールでプロビジョニング中にアプリケーションロードバランサーの認証を設定する場合、 Secrets Manager と SSL 証明書、または証明書の CRN を指定することができます。 ドロップダウンメニューで Secrets Manager を表示できない場合、つまり Secrets Manager インスタンスにアクセスできない場合に、この操作を行うとよいでしょう。 APIを使用してALBを作成する場合は、CRNを入力する必要があることに留意してください。
CRNを取得するには、 Secrets Manager インスタンスへのアクセス権限が必要です。
証明書の CRN を見つけるには、以下の手順を実行します。
- IBM Cloud コンソールで、 「ナビゲーション・メニュー」アイコン
>「リソース・リスト」 に移動します。 - Service and softwareをクリックして展開し、CRNを見つけたい Secrets Manager。
- 証明書のテーブル行の任意の場所を選択して、「証明書の詳細」サイド・パネルを開きます。 証明書の CRN がリストされます。
エンドツーエンドの SSL 暗号化
HTTPS リスナーに HTTPS プールを構成すると、エンドツーエンドの SSL 暗号化が可能になります。 ALBはフロントエンドリスナーで着信 HTTPS リクエストを終了し、バックエンドインスタンスとの HTTPS 接続を確立する。 エンドツーエンドの暗号化を使用すると、ロード・バランサー経由でバックエンド・メンバーに送信されるすべてのトラフィックが、HTTPS を使用して暗号化されます。
エンドツーエンドの SSL 暗号化を構成するには、以下のようにします。
- SSL オフロードを構成する場合と同じように、HTTPS フロントエンド・リスナーに SSL 証明書を構成します。
- HTTPS バックエンド・プールを構成します。
- バックエンド・メンバーのインスタンスを HTTPS バックエンド・プールに追加します。 バックエンド・メンバーのインスタンスが HTTPS トラフィックを処理するように構成されていることを確認します。
- バックエンド・メンバーに対して暗号化ヘルス・チェックを実行するために、タイプ HTTPS を指定してヘルス・チェックを構成します。
アプリケーション・ロード・バランサーは、バックエンド・メンバー・インスタンスの SSL 証明書を検証しません。
水平スケーリング
アプリケーション・ロード・バランサーは、負荷に応じて自動的にその容量を調整します。 このような調整が行われた場合は、ロード・バランサーの DNS 名に関連付けられている IP アドレスの数に変化が見られることがあります。
MZR のサポート
IBM Cloud Application Load Balancer for VPC では、マルチゾーン・リージョン (MZR) がサポートされています。 高可用性と冗長性は、異なるゾーンのサブネットを使用してアプリケーション・ロード・バランサーをデプロイすることによって実現できます。 複数のゾーンのサブネットを使用してアプリケーション・ロード・バランサーをプロビジョンすると、ロード・バランサー・アプライアンスは複数のゾーンにデプロイされます。
インスタンス・グループとの統合
IBM Cloud Application Load Balancer for VPC をインスタンス・グループと統合すると、バックエンドのメンバーをauto scaleすることができます。 プールのメンバーが、使用状況および要件に基づいて動的に追加/削除されます。
データ・パス・ログの転送
データパスのログを有効にすると、ロードバランサのログは IBM Log Analysis サービスに転送され、そこでデータパスのログを見ることができます。
HTTP2 サポート
アプリケーションロードバランサーは、エンドツーエンドの HTTP2 トラフィックをサポートしており、 HTTPS またはTCPとして設定されたリスナープロトコルと連動します。
WebSocket サポート
WebSocket は、単一の TCP 接続を介した全二重通信チャネルを提供します。 アプリケーションロードバランサーは、あらゆる種類のリスナープロトコル（ HTTP / HTTPS /TCP）で WebSocket をサポートしています。
アーキテクチャー
図 1 は、ALB のデプロイメント・アーキテクチャーを示しています。
この図で、「クライアント・リソース」は、クライアント・エコシステムに属するリソース (例えば、VPC やサブネット) を表します。
高可用性とアプリケーションロードバランサー
HA（高可用性）をALBで確実に動作させるには、異なるゾーンからALBに3つのサブネットをアタッチし、これらのゾーン全体にアプライアンスを展開します。 これを行うには、まずALB作成プロセス中にサブネットを選択します。 異なるゾーンのサブネットを2つ選択できます（例えば、 us-south-1 と us-south-2 ）。 そうすることで、ALB の IP（アプライアンス IP など）が 2 つの異なるサブネットに作成される。
すでにあるALBを使うこともできる。 ロードバランサの詳細ページの Attached Resources セクションに行く。 **サブネット］**セクションで［**サブネットの編集］**をクリックします。 次に、追加のサブネットを追加します。 ALBは「移行中」の状態になります。 移行が完了すると、先ほどアタッチしたサブネットからアプライアンス用の新しいIPが割り当てられます。 これで、異なるゾーンの異なるサブネットから2つのIPアドレスが取得できました。