自分の ALB に対して別の DNS 名を使用できますか。

アプリケーション・ロード・バランサーに自動的に割り当てられる DNS 名はカスタマイズできません。 ただし、使用したい DNS 名を、自動的に割り当てられたロード・バランサー DNS 名に差し向ける CNAME (Canonical Name) レコードを追加できます。 例えば、us-south のロード・バランサーの ID が dd754295-e9e0-4c9d-bf6c-58fbc59e5727 である場合、自動的に割り当てられるロード・バランサーの DNS 名は dd754295-us-south.lb.appdomain.cloud です。 優先的に www.myapp.com という DNS 名を使用したいとします。 その場合は、(myapp.com の管理に使用している DNS プロバイダーで) www.myapp.com をロード・バランサーの DNS 名 dd754295-us-south.lb.appdomain.cloud に差し向ける CNAME レコードを追加します。

アプリケーション・ロード・バランサーで定義できるフロントエンド・リスナーの最大数はいくつですか?

10 は、ALB で定義できるフロントエンド・リスナーの最大数です。

バックエンド・プールに接続できる仮想サーバー・インスタンスの最大数はいくつですか?

50 は、1 つのバックエンド・プールに接続できる仮想サーバー・インスタンスの最大数です。

アプリケーション・ロード・バランサーに接続できるサブネットの最大数はいくつですか?

ALB を使用して定義できるサブネットの最大数は 15 です。

ロード・バランサーは水平方向にスケーラブルですか?

はい。 Application Load Balancer for VPCは負荷に応じてその容量を自動的に調整します。 水平スケーリングが行われると、アプリケーション・ロード・バランサーの DNS に関連付けられている IP アドレスの数が変わります。

アプリケーション・ロード・バランサーのデプロイに使用したサブネットで ACL を使用する場合は、何をする必要がありますか?

必ず、構成したリスナー・ポートの着信トラフィックを許可する適切な ACL ルールを設定してください。 アプリケーション・ロード・バランサーとバックエンド・インスタンスの間のトラフィックも許可する必要があります。

アプリケーション・ロード・バランサーが maintenance_pending 状態になるのはなぜですか?

アプリケーション・ロード・バランサーは、次のようなさまざまなメンテナンス・アクティビティーの実施中に maintenance_pending 状態になります。

• 水平スケーリング・アクティビティー
• リカバリー・アクティビティー
• 脆弱性に対処してセキュリティー・パッチを適用するためのローリング・アップグレード

プロビジョン中に複数のサブネットを選択する必要があるのはなぜですか?

Application Load Balancer for VPC (ALB) は、マルチゾーン・リージョン (MZR) に対応しています。 ロード・バランサー・アプライアンスは、選択したサブネットにデプロイされます。 より高い可用性と冗長性を実現するには、複数の異なるゾーンのサブネットにアプリケーション・ロード・バランサーをデプロイしてください。

アプリケーション・ロード・バランサーの操作のために、サブネット内の追加の IP が必要ですか?

水平スケーリングと保守操作に対応できるように、MZR ごとに追加の IP を 8 つ割り当てることをお勧めします。 1 つのサブネットを使用してアプリケーション・ロード・バランサーをプロビジョンする場合は、16 個の追加 IP を割り振ってください。

ヘルス・チェック・パラメーターのデフォルト設定と許可される値を教えてください。

• ヘルス・チェックの間隔 - デフォルトは 5 秒。2 秒から 60 秒までの範囲。
• ヘルス・チェックの応答タイムアウト - デフォルトは 2 秒。1 秒から 59 秒までの範囲。
• 最大再試行回数 - デフォルトは 2 回の再試行。1 回から 10 回までの範囲。

ヘルス・チェックの応答タイムアウトの値は、ヘルス・チェックの間隔の値よりも小さくなければなりません。

ALB IP アドレスは固定ですか?

アプリケーション・ロード・バランサーの IP アドレスは固定であるとは限りません。 システムのメンテナンスや水平スケーリングの実行中に、ロード・バランサーの FQDN に関連付けられている使用可能な IP が変化します。

キャッシュされた IP アドレスではなく、FQDN を使用してください。

ロード・バランサーはレイヤー 7 のスイッチングをサポートしますか?

はい、ロード・バランサーはレイヤー 7 のスイッチングをサポートしています。

HTTPS リスナーの作成や更新の際に、証明書が無効であると示されるのはなぜですか?

以下の可能性を検討してください。

• 指定した証明書の CRN が無効である可能性があります。
• Secrets Manager 内の証明書インスタンスに秘密鍵が関連付けられていない可能性があります。

アプリケーション・ロード・バランサーのフロントエンド・リスナーの役割は何ですか?

ロード・バランサーのフロントエンド・リスナーは、アプリケーションのリスニング・ポートです。 これらは、バックエンド・プールのプロキシーとして機能します。

IP が 3 つではなく 2 つしかないのはなぜですか?

Application Load Balancer for VPC (ALB) は、アクティブ-アクティブのモード (ロード・バランサーを高可用性にする構成) で動作します。 負荷が増えた場合は、水平スケーリングでアプライアンスを追加することができます。 ロード・バランサーが MZR をサポートするように、複数の異なるゾーンのサブネットを選択しなければなりません。 そうすると、あるゾーンが負の影響を受けた場合に、新しいロード・バランサーが別のゾーンにプロビジョンされます。

プールがインスタンス・グループに接続されている場合、プール内のバックエンド・メンバーの最大数はいくつですか?

プール内のバックエンド・メンバーの最大許可数は 50 です。 したがって、インスタンス・グループがプールに接続されている場合、グループ内のインスタンスの数がこの制限を超えてスケール・アップされることはありません。

リスナーでトラフィックが受信されないのはなぜですか?

ロード・バランサーに関連付けられているセキュリティー・グループ・ルールで、リスナーのポートでの着信トラフィックと発信トラフィックが許可されていることを確認してください。 ロード・バランサーに関連付けられているセキュリティー・グループは、ロード・バランサーの概要ページで確認できます。 ロード・バランサーの概要からAttached security groupsタブを見つけて、表示するセキュリティー・グループを選択し、そのルールを変更します。

IBM はデータ・プレーン LBaaS アプライアンスの四半期ごとの ASV スキャンを実行しますか?

承認済みのスキャン・ベンダー (ASV) による四半期ごとのスキャンは、Payment Card Industry (PCI) Security Standards Council の要件です。 LBaaS データ・プレーン・アプライアンスの ASV スキャンは、もっぱらお客様の責任において行ってください。 IBM は、ASV を使用したデータ・プレーン・アプライアンスのスキャンを行いません。これらのスキャンは、カスタマー・ワークロードの機能とパフォーマンスに悪影響を及ぼす可能性があるためです。

ロード・バランサーのスケールダウン時にアクティブな接続はどのように処理されますか?

水平スケーリングまたは保守のためにロード・バランサー・アプライアンスでスケール・ダウンが発生すると、サービスはアクティブな接続が閉じられるのを待機して、トラフィックが他のアプライアンスに移動できるようにします。 24 時間後、サービスはスケールダウン・イベントを完了します。これにより、スケールダウンされたアプライアンス上のアクティブな接続が終了する可能性があります。

ロード・バランサー・アカウントの無効化ポリシーはどのように機能しますか?

ロードバランサーが一時停止されたという通知を受け取った場合、お客様のアカウント上のすべてのロードバランサーが削除されます。 アカウントのサスペンドが解除された場合、以前のロード・バランサーは、前提条件リソース (VPC、サブネット、セキュリティー・グループなど) がまだアクティブである場合にのみ復元されます。 これらのリソースが利用できなくなった場合は、新しいロードバランサーをプロビジョニングする必要があります。