アプリケーション・ロード・バランサーについて
IBM Cloud® Application Load Balancer for VPC (ALB) のアプリケーション・ロード・バランサーを使用して、VPC の同一リージョン内の複数のサーバー・インスタンス間にトラフィックを分散させることができます。
パブリック・ワークロードとプライベート・ワークロード、およびレイヤー 7 トラフィックがある場合は、アプリケーション・ロード・バランサーを使用します。
アプリケーション・ロード・バランサーのタイプ
VPC のロード・バランサーの概要 で説明されているように、パブリック ALB またはプライベート ALB を作成できます。
この表は、パブリック機能とプライベート機能の比較を示しています。
| 特長 | パブリック・ロード・バランサー | プライベート・ロード・バランサー |
|---|---|---|
| インターネット上でアクセス可能ですか？ | はい。完全修飾ドメイン・ネーム (FQDN) を使用してアクセス可能です | いいえ。同一のリージョンと VPC 上の内部クライアントのみアクセス可能です |
| すべてのトラフィックを受け入れますか? | ある | はい （ RFC-1918 のアドレス空間からのトラフィックのみを受け入れるという制限が解除されました。） |
| ドメイン名はどのように登録されるのですか？ | パブリック IP アドレス | プライベート IP アドレス |
パブリック・アプリケーション・ロード・バランサー
パブリックアプリケーションロードバランサーインスタンスには、外部からアクセス可能な完全修飾ドメイン名（FQDN）が割り当てられます。ロードバランサーの背後でホストされているアプリケーションにアクセスするには、この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 の「プライベート専用」エンドポイントは、 HTTPS のリスナーではサポートされていません。 ALB で HTTPS リスナーを構成するには、TLS 証明書を「パブリックおよびプライベート」エンドポイントにアップロードする必要があります。
HTTPS リダイレクト・リスナー
HTTPS リダイレクト・リスナーは、トラフィックを HTTP リスナーから HTTPS リスナーにリダイレクトします。 このアクションでは、リスナーに対してルールを適用する必要はありません。
たとえば、あるサービスが HTTPS でポート 443 をリッスンしており、ユーザーが HTTP を使用してポート 80 からそのサービスにアクセスしようとすると、そのリクエストは自動的に HTTPS としてポート 443 にリダイレクトされます。
HTTPS リダイレクト・リスナーにポリシーが存在する場合は、最初にポリシーが評価されます。 一致するポリシーがない場合、リクエストは設定済みの HTTPS リスナーにリダイレクトされます。
HTTPS リダイレクト・リスナーのプロパティー
| プロパティー (Property) | 説明 |
|---|---|
| リスナー | 要求がリダイレクトされる HTTPS リスナー。 |
| HTTP 状況コード | アプリケーション・ロードバランサーから返されたレスポンスのステータスコード。 許容値は 301、302、303, 307、または 308 です。 |
| URI | 要求がリダイレクトされる相対 URI。 このプロパティーはオプションです。 |
バックエンドプールのフェイルセーフポリシー
ロードバランサーのバックエンドプールを編集するとき、以下のフェイルセーフポリシーアクションの1つを指定できます：
- フォワード： ロードバランサはリクエストを指定されたバックアッププールに転送します。 これにより、別のアプリケーション・サーバー・セットへのクリーンなフェイルオーバー経路が提供される。 既存のバックアッププールが設定され、トラフィックを受信できる状態になっている必要があります。
- Drop: ロードバランサは全てのリクエストを受け取り拒否し、クライアントは応答を受け取りません。
- 失敗： ロードバランサは HTTP 503 ("Service Unavailable") ステータスコードでリクエストを拒否し、サービスが一時的にダウンしていることをクライアントに知らせます。
適用可能なバックアッププールのリストからフェイルセーフターゲットを選択できます。
フェイルセーフ・ターゲット・プールの要件（アクションがフォワードの場合）：
- は同じロードバランサに属していなければならない
- プロトコルが同じか互換性がなければならない（ TCP は TCP とのみ互換性があるが、 HTTP と HTTPS の組み合わせは互換性がある）
単一のリスナーに複数のプールを関連付けることができるのは、アプリケーション・ロード・バランサーだけです。 ロードバランサに既に存在するプールが少なくとも1つあることを確認してください。
ロードバランサーの設定では、リスナーは親リソースとみなされます。 プールを直接または間接的に参照することで、2つの方法でそのリスナーに関連付けることができる。 直接関連付けるには、プールをリスナーの default_pool として設定する。 間接的な関連付けの場合、 failsafe_policy.target の関係を通して、他のプールからプールを参照し、他のプールがすでにリスナーにリンクされていることを確認する。
弾力性
アプリケーション・ロード・バランサーは、負荷が増えるとコンピュート・リソースを追加してスケールアウトします。
SSL オフロードおよび必要な許可
Secure Sockets Layer（ SSL ）のオフロードにより、アプリケーション・ロードバランサーは、すべての着信 HTTPS 接続をターミネートすることができます。
HTTPS リスナーに HTTP プールを構成した場合は、HTTPS 要求がフロントエンドで終端処理されるので、ロード・バランサーはバックエンド・サーバー・インスタンスとの間にプレーン・テキストによる HTTP 通信を確立します。 この手法により、バックエンド・サーバー・インスタンスが、CPU 負荷の高い SSL のハンドシェークおよび暗号化/復号タスクから解放され、すべての CPU サイクルをアプリケーション・トラフィックの処理に使用できるようになります。
SSL オフロードを使用するには、アプリケーション・ロード・バランサーで SSL オフロード・タスクを実行するための SSL 証明書を用意する必要があります。 IBM Cloud Secrets Manager を使用して SSL 証明書を管理できます。
IAMの「権限 」機能を使用して、権限を作成できます。 必ず選択してください VPC インフラストラクチャ サービスソースサービスとして特定のリソース。 クリック属性を選択選択してリソースタイプリストから。 リソースタイプとして「 VPC 用ロードバランサー 」を選択し、「 次へ 」をクリックします。 「Target」サービスについては、 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 コンソールで、 ナビゲーションメニューアイコン
> リソース一覧 に移動します。 - 「セキュリティ」 をクリックして展開し、CRNを確認したい「 Secrets Manager 」を選択してください。
- 証明書のテーブル行の任意の場所を選択して、「証明書の詳細」サイド・パネルを開きます。 証明書のCRNが記載されています。
エンドツーエンドの SSL 暗号化
HTTPS リスナーに HTTPS プールを構成すると、エンドツーエンドの SSL 暗号化が可能になります。 ALBは、受信した HTTPS リクエストをフロントエンドリスナーで終了させ、バックエンドインスタンスとの HTTPS 接続を確立します。 エンドツーエンド暗号化により、ロードバランサーを経由してバックエンドノードへ送信されるすべてのトラフィックが、 HTTPS 上で暗号化されます。
エンドツーエンドの SSL 暗号化を構成するには、以下のようにします。
- SSL のオフロード設定を行う場合と同様に、 SSL の証明書を使用して、 HTTPS のフロントエンドリスナーを設定します。
- 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 Cloud Logs サービスに転送され、そこでデータパスログを確認できます。
HTTP2 サポート
アプリケーション・ロードバランサーは、エンド・ツー・エンド HTTP2 のトラフィックをサポートし、リスナー・プロトコルを HTTPS または TCP のいずれかに設定して動作する。
WebSocket サポート
WebSocket は、単一の TCP 接続で全二重通信チャネルを提供する。 アプリケーションロードバランサーは、リスナープロトコルのすべてのタイプ（ HTTP / HTTPS / TCP ）で WebSocket。
高可用性とアプリケーションロードバランサー
ALBで高可用性（HA）が確実に機能するようにするには、異なるゾーンから3つのサブネットをALBにアタッチし、これらのゾーンにまたがってアプライアンスを展開してください。 これを行うには、まずALB作成プロセス中にサブネットを選択します。 異なるゾーンにある2つのサブネット（例： us-south-1 と us-south-2）を選択できます。 これにより、ALBのIPアドレス（アプライアンスIPなど）が2つの異なるサブネットに作成されます。
すでにあるALBを使うこともできる。 ロードバランサの詳細ページの Attached Resources セクションに行く。 **サブネット］**セクションで［**サブネットの編集］**をクリックします。 次に、さらにサブネットを追加します。 ALBは「移行中」の状態になります。 移行が完了すると、先ほどアタッチしたサブネットからアプライアンス用の新しいIPが割り当てられます。 現在、異なるゾーンにある異なるサブネットから2つのIPアドレスを取得しています。