Server Load Balancer:ALB のよくある質問

ALB には特定のインスタンス仕様がありますか？

ALB のインスタンス仕様を選択する必要はありません。アップグレードされた ALB インスタンスは、VIP 自動スケーリング機能を使用することで、単一インスタンスで 100 万 QPS のパフォーマンスを達成できます。ALB インスタンスのパフォーマンスの詳細については、「インスタンスのパフォーマンスメトリクス」をご参照ください。

ALB インスタンスを IPv4 からデュアルスタックに、またはデュアルスタックから IPv4 に切り替えることはできますか？

いいえ。

IPv4 インスタンスまたはデュアルスタックインスタンスのみを作成できます。

ALB インスタンスの VIP への ping を無効にできますか？

• アップグレードされた ALB インスタンスの場合、セキュリティグループを使用してアクセス トラフィックを管理できます。インスタンスのセキュリティグループにインバウンドルールを追加して、ICMP リクエストを拒否します。

• アップグレードされていない ALB インスタンスの場合、関連付けられた EIP を Cloud Firewall に追加し、インバウンドポリシーを設定して ICMP リクエストを拒否できます。

ALB インスタンスのインターネット帯域幅を増やすにはどうすればよいですか？

2 つのアベイラビリティーゾーンにデプロイされた ALB インスタンスが Internet Shared Bandwidth インスタンスに追加されていない場合、そのデフォルトの最大インターネット帯域幅は 400 Mbps です。

データ転送プランによるインターネット料金の相殺

• ALB インスタンスが EIP を介してインターネット向け機能を提供する場合、EIP によって生成されたインターネット向けトラフィックは、汎用トラフィックパッケージを使用して相殺できます。

• ALB インスタンスが Anycast EIP を介してインターネット向け機能を提供する場合、Anycast EIP によって生成されたパブリックネットワークトラフィックは、汎用トラフィックプランを使用して相殺することはできません。

ALB でサポートされる EIP タイプ

内部向け ALB への EIP の関連付け

はい。

内部向け ALB に EIP を関連付ける必要がある場合は、インスタンスのネットワークタイプを変更して、内部向け ALB をインターネット向け ALB に変換できます。詳細については、「ALB インスタンスのネットワークタイプの変更」をご参照ください。

ネットワークタイプを内部向けからインターネット向けに変更すると、システムはインスタンスに EIP を関連付け、インターネット経由のデータ転送に対して課金されます。詳細については、「EIP の課金」をご参照ください。

EIP の BGP (マルチ ISP) Pro への変更

ALB インスタンスのネットワークタイプを変更するには、次の手順に従います：

1. ALB インスタンスのネットワークタイプをインターネット向けから内部向けに変更します。これにより、現在の EIP とインスタンスの関連付けが解除されます。

2. ALB インスタンスのネットワークタイプを内部向けからインターネット向けに戻します。このプロセス中に、既存の 2 つの BGP (マルチ ISP) Pro EIP を選択します。

EIP 間のトラフィック分散の不均衡

これにはいくつかの原因が考えられます：

• ドメイン名が ALB インスタンスの DNS 名ではなく、単一の EIP に解決されている。

• Web Application Firewall (WAF) や Anti-DDoS Pro などのレイヤー 7 プロキシが ALB インスタンスの前にデプロイされている場合、そのオリジン選択アルゴリズム (IP ハッシュなど) が EIP 間のトラフィックの均等な分散を妨げている。

• 一部のクライアントが以前の DNS クエリの A レコードをキャッシュしているため、大量のリクエストが継続的に同じ EIP に送信される。

ALB の DNS レコードの削除

アップグレードされた ALB インスタンスは、デフォルトで DNS レコードの削除と復元をサポートしています。

アベイラビリティーゾーンの DNS レコードが削除されると、そのゾーンの VIP に対する可用性プローブが停止します。そのアベイラビリティーゾーンの VIP または EIP (IPv4 と IPv6 の両方のアドレスを含む) も ALB ドメイン名の名前解決から削除されます。IPv4 または IPv6 の VIP アドレスのみを削除することはできません。

ALB はトラフィックミラーリングをサポートしていますか？

はい。詳細については、「ALB トラフィックミラーリングを使用した本番トラフィックのシミュレーション」をご参照ください。

QPS 上限に到達しない

• 仕組み：負荷分散システムは、サーバーのクラスターを介してサービスを提供します。システムは、すべての着信リクエストをこれらのサーバーに均等に分散して転送します。したがって、転送ルールで設定した QPS 上限は、複数のシステムサーバーに均等に分散されます。

  単一のシステムサーバーの QPS 上限は次のように計算されます：システムサーバーあたりの QPS 上限 = 設定された合計 QPS / (N-1)。ここで、N は転送グループ内のシステムサーバーの数です。たとえば、コンソールで転送ルールの QPS 上限を 1,000 QPS に設定し、システムサーバーが 8 台ある場合、単一のシステムサーバーの最大 QPS は 1000/(8-1) = 142 QPS となります。

• 原因：少数の長時間接続を使用するシナリオでは、これらの接続が転送グループ内のすべてのシステムサーバーに分散されない可能性があり、その結果 ALB インスタンスがピーク QPS 上限に到達できなくなります。

• 推奨事項：負荷分散の仕組みに基づき、ビジネス要件に応じて転送ルールに適切な QPS 上限を設定することを推奨します。これにより、サービスが影響を受けたり制限されたりすることがなくなります。転送ルールで QPS 上限を設定する方法の詳細については、「転送ルールの追加」をご参照ください。

リクエスト長の制限

ALB 処理時間の内訳

はい、ALB の処理時間には、クライアントデータの受信とレスポンスデータの送信に費やされた時間が含まれます。

持続的接続あたりのリクエスト制限

単一の持続的接続は、最大 100 件の連続したリクエストを処理できます。この制限に達すると、ALB は自動的に接続を閉じます。

HTTP/2.0 が有効な HTTPS リスナーを使用する場合、単一の持続的接続のリクエスト制限は 1,000 に増やすことができます。

QUIC リスナーの Client Hello サイズ制限

QUIC リスナーを使用する場合、ALB はクライアントの Client Hello パケットに最小サイズ制限を課します。パケットサイズは少なくとも 1,024 バイトである必要があります。そうでない場合、ALB は「client hello too small」というメッセージを返し、接続を閉じます。Client Hello パケットにヌル文字を埋め込んで 1,024 バイトの要件を満たし、チェックをパスすることができます。

ALB Ingress の使用上の注意

一般的に、ALB Ingress によって作成された ALB インスタンスはコンソールで手動で変更するべきではありません。ALB インスタンスの設定は、主に AlbConfig リソースから同期されます。ALB Ingress の詳細については、「ALB Ingress の管理」および「ALB Ingress の操作」をご参照ください。

AlbConfig リソースを更新せずにコンソールで手動で設定を変更すると、AlbConfig リソースが変更を上書きします。これにより、アクセスログが無効になったり、転送ルールが削除されたりするなどの問題が発生する可能性があります。

ALB CORS のよくある質問

元のヘッダー値の参照

キー は追加したいヘッダーの名前を指定します。値 は参照方法と、値を参照したい元のヘッダーの名前を指定します。たとえば、元のヘッダー abc の値を参照する abc-abc という名前のヘッダーを追加できます。転送ルールは、元のヘッダー abc の値を抽出し、新しく追加されたヘッダー abc-abc に割り当てます。

クライアント

サーバー

ALB は相互認証をサポートしていますか？

基本 ALB インスタンスは相互認証をサポートしていません。標準および WAF 有効化 ALB インスタンスは、HTTPS リスナーを追加する際に相互認証をサポートします。基本 ALB インスタンスで相互認証機能を使用する必要がある場合は、インスタンスエディションをアップグレードしてください。

ワイルドカード証明書のルール

ALB への証明書のアップロード

いいえ、できません。

ALB は Alibaba Cloud Certificate Management Service の証明書を使用します。証明書は Certificate Management Service コンソールにアップロードする必要があります。したがって、ALB コンソールから証明書をアップロードすることはできません。詳細については、「SSL 証明書のアップロード」をご参照ください。

証明書の有効期限が更新されない

これは通常、ALB が透過型プロキシモードで WAF 2.0 と統合されており、WAF 側の証明書が更新されていない場合に発生します。WAF は ALB の証明書を定期的に同期します。即時同期を強制するには、WAF でトラフィック迂回を無効にしてから再度有効にすることで、証明書の状態を更新できます。この操作により、サービスが 1〜2 秒間中断されることに注意してください。

ヘルスチェック設定の変更

1. Application Load Balancer (ALB) コンソールにログインします。

2. 左側のナビゲーションウィンドウで、ALB > サーバーグループ を選択します。

3. サーバーグループ ページで、管理したいサーバーグループを見つけ、その ID をクリックします。

4. 詳細 タブの [ヘルスチェック] セクションで、ヘルスチェックの変更 をクリックします。

5. ヘルスチェックの変更 ダイアログボックスで、ヘルスチェックの設定 の右側にある 編集 をクリックし、必要に応じてヘルスチェック設定を変更してから、保存 をクリックします。

   詳細については、「ALB のヘルスチェック」をご参照ください。

ヘルスチェックが正常なのに 502 エラーが発生する

これは通常、ALB インスタンスのバックエンドサーバーの負荷が高すぎるためです。ALB インスタンスのバックエンドサーバーの負荷が高すぎると、ヘルスチェックの結果がアクセスリクエストの結果と一致しない場合があります。バックエンドサーバーの負荷を確認する方法については、「Linux インスタンスの高負荷問題のトラブルシューティングと対処」をご参照ください。

すべてのバックエンドが異常な状態での転送

ALB は、サービスへの影響を最小限に抑えるために、スケジューリングアルゴリズムに基づいてリクエストを転送しようと試みます。リクエストが期待どおりに処理されない場合は、バックエンドサーバーのエラーログを確認するか、ヘルスチェック設定に問題がないかを確認してください。詳細については、「ALB のヘルスチェック失敗のトラブルシューティング」をご参照ください。

サービスアクセス障害のトラブルシューティング

以下のトラブルシューティング手順に従ってください：

1. CNAME レコードの確認：新しい ALB インスタンスには、その DNS 名を使用して直接アクセスすることはできません。カスタムドメイン名を ALB インスタンスの DNS 名にマッピングするために、CNAME レコードを追加する必要があります。nslookup または dig コマンドを使用して、名前解決の結果を確認できます。詳細については、「ALB インスタンスの DNS 名」をご参照ください。

2. インスタンスのネットワークタイプの確認：内部向け ALB インスタンスは、その VPC 内からのみアクセスでき、インターネットから直接アクセスすることはできません。パブリックアクセスには、インスタンスのネットワークタイプをインターネット向けに変更し、EIP を関連付けます。詳細については、「ALB インスタンスのネットワークタイプの変更」をご参照ください。

3. リスナーと転送ルールの確認：ALB コンソールで、リスナーが作成されているか、リスナーのポートとプロトコルが正しく設定されているか、転送ルールがリクエストのドメインとパスに一致しているかを確認します。

4. ヘルスチェックステータスの確認：ALB コンソールで、バックエンドサーバーのヘルスチェックステータスを確認します。バックエンドサーバーがヘルスチェックに失敗した場合、ALB はリクエストを正しく転送できない可能性があります。

5. バックエンドサービスが正常に動作しているかの確認：バックエンドサーバーに直接ログインし、curl -I http://<バックエンドサーバーのプライベート IP アドレス>:<ポート> コマンドを実行して、バックエンドサービス自体が正常に応答していることを確認します。

6. アクセス制御とファイアウォール設定の確認：ALB インスタンスのアクセス制御リスト (ACL) またはセキュリティグループがクライアントのソース IP アドレス範囲をブロックしていないことを確認します。バックエンド ECS インスタンスの iptables またはサードパーティのセキュリティソフトウェアが ALB のローカル IP CIDR ブロックをブロックしていないことを確認します。

高レイテンシーのトラブルシューティング

ALB はアプリケーション層で動作し、リクエストは ALB を介してバックエンドサーバーに転送されます。バックエンドに直接アクセスする場合と比較して、レイテンシーがわずかに増加するのは正常です。

レイテンシーが著しく高い場合は、以下の手順でトラブルシューティングを行ってください：

1. アクセスログの有効化と分析：ALB アクセスログを有効にし、以下のフィールドに注目します：

   • request_time：ロードバランサーが最初のリクエストパケットを受信してからレスポンスを返すまでの時間間隔 (秒単位)。

   • upstream_response_time：ロードバランサーがバックエンドサーバーへの接続を確立し始めてから、データの受信を完了して接続を閉じるまでの時間 (秒単位)。

2. レイテンシーの原因の特定：

   • upstream_response_time が高い場合、レイテンシーの原因は通常、バックエンドサーバーの処理が遅いことです。バックエンドアプリケーションのパフォーマンス、データベースクエリの効率、CPU やメモリなどのリソース使用量を調査するか、バックエンドサーバーを追加して負荷を分散することを推奨します。

   • request_time が upstream_response_time よりもはるかに大きい場合、レイテンシーはクライアントから ALB へのネットワークリンク上にある可能性があります。クライアントから ALB サービスアドレスへの ping テストや MTR ルートトレースを継続的に実行して、ネットワークリンクの問題をトラブルシューティングすることを推奨します。

3. クロスリージョンアクセスのシナリオ：クライアントと ALB インスタンスが異なるリージョンにある場合、物理的な距離によるネットワーク遅延は避けられません。Global Accelerator (GA) を使用して、クロスリージョンアクセスのエクスペリエンスを最適化することを推奨します。

ドメイン名でサービスにアクセスできない

新しい ALB インスタンスには、その DNS 名で直接アクセスすることはできません。CNAME レコードを使用して、カスタムドメイン名を ALB インスタンスの DNS 名にマッピングする必要があります。CNAME レコードを正しく設定してもサービスにアクセスできない場合 (たとえば、403 エラーが返されたり、接続がリセットされたりする場合)、最も一般的な原因は、ドメイン名が ICP 登録を完了していないことです。

以下の手順でトラブルシューティングを行うことを推奨します：

1. CNAME 名前解決設定の確認：nslookup または dig コマンドを使用して、ドメイン名が ALB インスタンスの DNS 名に正しく解決されていることを確認します。「CNAME 名前解決の設定」をご参照ください。

2. ドメインの ICP 登録状況の確認：関連規制によると、ドメイン名を中国本土でのパブリックアクセスに使用する場合、ICP 登録を完了している必要があります。そうでない場合、アクセスはブロックされます。Alibaba Cloud ICP 登録システムにログインして、ドメイン名の登録状況を確認してください。登録されていない場合は、まず ICP 登録を完了してください。詳細については、「ICP 登録プロセス」をご参照ください。

3. アクセス登録が必要かどうかの確認：ドメイン名が他のクラウドサービスプロバイダーで ICP 登録を完了しているが、Alibaba Cloud で初めて使用する場合は、Alibaba Cloud に登録情報を登録するためにアクセス登録を完了する必要もあります。アクセス登録を完了しないと、アクセスがブロックされる可能性もあります。

500 (Internal Server Error)

バックエンドサーバーの内部エラーが発生し、リクエストを実行できません。

• バックエンドが直接 500 ステータスコードを返す：アクセスログを確認します。upstream_status が 500 の場合、ALB がバックエンドのステータスコードをそのまま渡している可能性が高いです。バックエンドサービスをトラブルシューティングしてください。

• バックエンドサーバーが予期せず接続を閉じた：バックエンドサーバーが完全なレスポンスを送信する前に予期せず接続を閉じました。バックエンドサーバーでパケットキャプチャを行い、接続が閉じられた原因を調査してください。

502 (Bad Gateway)

このエラーは、HTTP または HTTPS リスナーがクライアントリクエストを受信したものの、ALB がそれをバックエンドサーバーに転送できなかったり、バックエンドサーバーからレスポンスを受信できなかったりした場合に発生します。

トラブルシューティングのアプローチ：アクセスログの upstream_status フィールドの値を確認します。このフィールドの値によって、その後のトラブルシューティングの方向が決まります。

• upstream_status = 502 の場合：ALB はバックエンドサービスから 502 ステータスコードをそのまま渡しています。問題はバックエンドサービス自体にあります。バックエンドサービスをトラブルシューティングしてください。たとえば、バックエンドの Nginx やゲートウェイ層が到達不能なアップストリームにリバースプロキシしているかどうかを確認します。

• upstream_status が他の値の場合 (例：504、444、または 500)：ALB がアクセスログで返す status が upstream_status と異なります。これは、ALB がステータスコードを変換したことを示します。バックエンドの Nginx、ゲートウェイ、またはアプリケーションのログを確認して、バックエンドサービスがこのステータスコードを返した理由を調査してください。

• upstream_status が - または空の場合：ALB はバックエンドサーバーから何のレスポンスも受信していません。これは、リクエストがバックエンドサーバーに到達しなかったか、バックエンドサーバーがレスポンスを送信する前に予期せず切断されたことを意味します。以下の項目を順に確認してください：

  • ALB とバックエンドサーバー間の TCP 通信エラー。バックエンドサービスが実行中であること、サービスポートがリッスンしていること、バックエンド ECS インスタンスの iptables ルールやサードパーティのセキュリティソフトウェアが ALB インスタンスの vSwitch の CIDR ブロックをブロックしていないことを確認します。ALB は、vSwitch から割り当てられた Local IP アドレスを使用してバックエンドサーバーと通信します。パケットキャプチャを行って、TCP ハンドシェイクが正常に完了するかどうかを確認できます。

  • バックエンドサーバーのバックログがいっぱいになっている。これにより、新しい接続リクエストが拒否またはドロップされます。バックエンドサーバーで netstat -s | grep -i listen を実行して、drop カウントがあるかどうかを確認できます。

  • バックエンドサーバーがリクエストを時間内に処理できなかった。バックエンドサーバーのログを確認し、CPU やメモリ使用率などのメトリクスを見直して、パフォーマンスのボトルネックを特定します。

  • クライアントから送信されたパケットのサイズがバックエンドサーバーの MTU を超えている。この問題の症状として、ヘルスチェックなどの小さなパケットのリクエストは正常に処理されるが、より大きなパケットを含むリクエストは失敗することがあります。バックエンドサーバーでパケットキャプチャを行い、パケットサイズが MTU 制限内であるか分析します。

  • バックエンドサーバーからのレスポンスパケットの形式が無効であるか、無効な HTTP ヘッダーが含まれている。バックエンドサーバーでパケットキャプチャを行い、レスポンスパケットの形式を分析します。

503 (Service Temporarily Unavailable)

サーバーが一時的に利用できません。通常、トラフィックが制限を超えたか、バックエンドサービスがダウンしていることが原因です。

• バックエンドが 503 エラーを返す：アクセスログを確認します。upstream_status が 503 の場合、ALB がバックエンドのステータスコードをそのまま渡している可能性が高いです。バックエンドサービスをトラブルシューティングしてください。

• クライアントリクエストが ALB のスロットリングをトリガーした：

  • CloudMonitor で 秒間リクエスト数 メトリックを表示できます。

  • CloudMonitor は分単位のデータを表示するため、秒単位で制限を超えた場合を反映しないことがあります。アクセスログを確認できます。upstream_status フィールドの値が - の場合、リクエストはバックエンドサーバーに配信されませんでした。

  • レスポンスヘッダーを確認します。ヘッダーに ALB-QPS-Limited:Limited フィールドが含まれている場合、リクエストは ALB のスロットリングをトリガーしました。

• ALB IP への直接クライアントアクセスまたは異常な DNS 名前解決：これにより、トラフィックが少数の IP アドレスに集中し、スロットリングがトリガーされる可能性があります。ドメイン名で ALB にアクセスし (「ALB インスタンスの CNAME 名前解決の設定」をご参照ください)、CNAME 名前解決が正しく機能していることを確認してください。

• リスナーにバックエンドサーバーが設定されていない、または設定されたバックエンドサーバーの重みが0である。

504 (Gateway Timeout)

バックエンドサーバーがタイムアウト期間内に応答しませんでした。

• バックエンドサービスが直接 504 エラーを返す：アクセスログを確認します。upstream_status フィールドが 504 の場合、ALB がバックエンドのステータスコードをそのまま渡した可能性が高いです。バックエンドサービスをトラブルシューティングしてください。

• ALB からバックエンドサーバーへの接続タイムアウト: タイムアウト期間はデフォルトで 5 秒で、変更できません。バックエンドサーバーの応答タイムアウトの原因を特定するには、パケットキャプチャを実行することをお勧めします。

• バックエンドサーバーの応答タイムアウト：接続リクエストのタイムアウトはデフォルトで 60 秒です。CloudMonitor の UpstreamResponseTime とアクセスログの upstream_response_time を確認して、バックエンドサーバーがタイムアウトしたかどうかを判断できます。

WAF 2.0 と WAF 3.0 の統合の比較

詳細については、「WAF 3.0 と WAF 2.0 の比較」をご参照ください。

ALB と WAF の統合

• サービス統合を通じて、つまり WAF 有効化 ALB インスタンスを使用して、ALB インスタンスの WAF 3.0 保護を有効にすることを推奨します。

  • サポートされているリージョン：

    エリア	リージョン
    中国	中国 (成都)、中国 (青島)、中国 (北京)、中国 (広州)、中国 (杭州)、中国 (ウランチャブ)、中国 (上海)、中国 (深セン)、中国 (張家口)、中国 (香港)、中国 (河源)
    アジア太平洋	フィリピン (マニラ)、インドネシア (ジャカルタ)、日本 (東京)、マレーシア (クアラルンプール)、シンガポール、タイ (バンコク)、韓国 (ソウル)
    ヨーロッパ & アメリカ	ドイツ (フランクフルト)、米国 (シリコンバレー)、米国 (バージニア)、メキシコ
    中東	サウジアラビア (リヤド - パートナー運営)、UAE (ドバイ)

  • WAF 有効化 ALB インスタンスは、WAF 3.0 SDK 統合モデルを使用します。アカウントに WAF 2.0 インスタンスがある場合は、まず WAF 2.0 インスタンスをリリースするか、WAF 3.0 に移行する必要があります。

    デフォルトでは、ALB はリクエストに X-Forwarded-Proto ヘッダーを追加しません。WAF 2.0 インスタンスをリリースした後、ALB インスタンスに直接アクセスすると、バックエンドサーバーが元のプロトコル (HTTP または HTTPS) を識別できないため、無限リダイレクトなどのサービス問題が発生する可能性があります。この問題を回避するには、ALB リスナー設定で X-Forwarded-Proto リクエストヘッダーを手動で有効にする必要があります。

  • WAF 有効化 ALB インスタンスは、WAF のデータ漏えい防止機能をサポートしていません。

• アカウントに既存の WAF 2.0 インスタンスを使用する必要がある場合、インターネット向けの基本および標準 ALB インスタンスは、中国 (杭州)、中国 (上海)、中国 (深セン)、中国 (成都)、中国 (北京)、および中国 (張家口) のリージョンで WAF 2.0 保護のための透過型プロキシモードをサポートしています。内部向け ALB インスタンスは WAF 2.0 保護をサポートしていません。

WAF 統合サポートマトリックス

WAF 2.0 設定の同期問題

WAF 2.0 が透過型アクセスモードの場合、クライアントリクエストはまず WAF によって検査された後、ALB または CLB に転送されます。リクエストは 2 つのゲートウェイを通過するため、WAF とロードバランサーの両方で複数の設定を同期する必要があります。タイムアウト設定と証明書の変更は、特に同期遅延を引き起こしやすいです。