このトピックでは、Application Load Balancer (ALB) に関するよくある質問 (FAQ) に対する回答を提供します。
ALBインスタンスによって転送できるリクエストの最大サイズはどれくらいですか。 許容最大サイズを増やすことはできますか?
同じバックエンドサーバー内のすべてのバックエンドサーバーが正常でない場合、ALBインスタンスはどのようにリクエストを転送できますか?
Alibaba Cloudは異なる仕様のALBインスタンスを提供していますか。
Alibaba Cloudは、ALBインスタンスの異なる仕様を提供していません。 ALBインスタンスのパフォーマンスは、ALBインスタンスで使用されるIPアドレスの種類によって異なります。
静的IP: ALBインスタンスには、各ゾーンで1つの静的IPアドレスのみが割り当てられます。 このモードでは、1つのALBインスタンスが1秒あたり最大100,000クエリ (QPS) をサポートします。
動的IP: ALBインスタンスには、各ゾーンで1つ以上のIPアドレスが割り当てられます。 ALBインスタンスが使用するIPアドレスの数は、ワークロードとともに自動的に増加します。 このモードでは、単一のALBインスタンスが最大1,000,000 QPSをサポートします。
ALBインスタンスのパフォーマンスの詳細については、「ALBとは」トピックのパフォーマンスメトリクスセクションをご参照ください。
ALBインスタンスの最大インターネット帯域幅を増やすにはどうすればよいですか。
ALBインスタンスが2つのゾーンにデプロイされ、インターネット共有帯域幅インスタンスに関連付けられていない場合、ALBインスタンスのデフォルトの最大インターネット帯域幅は400 Mbit/sです。
より多くの帯域幅が必要な場合は、インターネット共有帯域幅インスタンスを購入し、ALBインスタンスのelastic IPアドレス (EIP) をインターネット共有帯域幅インスタンスに関連付けることができます。
インターネット共有帯域幅インスタンスの購入方法の詳細については、「インターネット共有帯域幅の作成」をご参照ください。
EIPをインターネット共有帯域幅インスタンスに関連付ける方法の詳細については、「ALBインスタンスの作成」および「最大帯域幅の変更」をご参照ください。
リスナーのヘルスチェック設定を変更するにはどうすればよいですか?
ヘルスチェック中に例外が検出されない場合、502ステータスコードが返されるのはなぜですか。
これは、ALBインスタンスのバックエンドサーバーが過負荷になっているためです。 ALBインスタンスのバックエンドサーバーが過負荷になっている場合、ヘルスチェックの結果が正常であっても、アクセスリクエストに応答できない場合があります。 詳細については、「Linuxインスタンスの高負荷の問題のトラブルシューティングと解決」をご参照ください。
データ転送プランを使用して、ALBのインターネットデータ転送料金を相殺することはできますか?
ALBインスタンスがEIPを使用してインターネット経由でサービスを提供する場合、データ転送プランを使用してパブリック帯域幅料金を相殺できます。
ALBインスタンスがAnycast EIPを使用してインターネット経由でサービスを提供する場合、データ転送プランを使用してインターネットデータ転送料金を相殺することはできません。
ALBは相互認証をサポートしていますか?
Basic ALBインスタンスは相互認証をサポートしていません。 標準またはWeb Application Firewall (WAF) 対応のALBインスタンスのHTTPSリスナーに対して相互認証を有効にできます。 相互認証を設定する前に、基本ALBインスタンスをアップグレードする必要があります。 詳細については、「ALBインスタンスの設定の変更」および「HTTPSリスナーの追加」をご参照ください。
相互認証を設定するには、Alibaba Cloud certificate Management Serviceから認証局 (CA) 証明書を選択するか、CA証明書を購入します。 詳細については、「プライベートCAの購入と有効化」をご参照ください。
ワイルドカードリスナー証明書に必要な要件
HTTPSリスナーにワイルドカード証明書を設定する場合は、次の制限事項に注意してください。
ワイルドカード証明書を選択すると、ALBはワイルドカード (
*) を1つだけ含む証明書を識別できます。ワイルドカードはドメイン名の左端にある必要があります。 たとえば、ALBは* .example.comと* test.example.comを識別できますが、tes t*.example.comは識別できません。ワイルドカード証明書の要件:
ワイルドカードドメイン名のレベル: ワイルドカードドメイン名は、ワイルドカードドメイン名と同じレベルの特定のドメイン名と一致します。 たとえば、
* .example.comはtest.example.comに一致できますが、ワイルドカードドメイン名より1レベル低いtest.test.example.comには一致できません。国際化ドメイン名 (IDNA):
ワイルドカード文字が唯一のワイルドカード文字で、ワイルドカードドメイン名の左端にある場合、IDNAはワイルドカードドメイン名と一致します。 たとえば、
xn--fsqu00a.example.comは* .example.comに一致します。ワイルドカード文字がワイルドカードドメイン名の左端にない場合、IDNAはワイルドカードドメイン名と一致しません。 たとえば、
* test.example.comをxn--fsqu00atest.example.comできません。
一致範囲: ワイルドカード文字 (
*) は、数字、文字、およびハイフン (-) と一致できます。 たとえば、* .example.comはtest.example.comに一致できますが、test_test.example.comには一致できません。
ALBインスタンスに関連付けることができるEIPの種類を教えてください。
ALBは、従量課金EIPのみをサポートします。 次の表に、ALBインスタンスに関連付けることができるEIPのタイプを示します。
課金方法 | インターネット計測方法 | 回線タイプ | セキュリティ保護 |
従量課金制 | データ転送課金 | BGP (マルチISP) | デフォルト |
データ転送量課金 | BGP (マルチ ISP) Pro | デフォルト | |
データ転送量課金 | BGP (マルチISP) | Anti-DDoS Pro /プレミアム |
EIPをALBインスタンスに関連付けるときは、次の制限事項に注意してください。
同じALBインスタンスの異なるゾーンに割り当てられるEIPは、同じタイプである必要があります。
ALBインスタンスに関連付けるEIPをEIP帯域幅プランに関連付けることはできません。 EIPをALBインスタンスに関連付けた後、ALBコンソールでインターネット共有帯域幅インスタンスをALBインスタンスに関連付けることができます。 インターネット共有帯域幅インスタンスは、EIPと同じ回線タイプを使用する必要があります。 サブスクリプションのインターネット共有帯域幅インスタンスと従量課金のインターネット共有帯域幅インスタンスがサポートされています。 インターネット共有帯域幅インスタンスをALBインスタンスに関連付ける方法の詳細については、「最大帯域幅の変更」をご参照ください。
帯域幅課金方式を使用するサブスクリプションEIPまたは従量課金EIPをALBインスタンスに関連付けることはできません。
EIPをALBインスタンスに割り当てるときに、[EIPの購入] または [EIPの自動割り当て] を選択した場合、データ転送課金方式を使用する従量課金EIPが作成されます。 EIPはBGP (マルチISP) 回線を使用し、Anti-DDoS Origin Basicによって保護されています。
EIPを内部対応のALBインスタンスに関連付けることはできますか?
はい。ALBインスタンスのネットワークタイプをインターネット接続に切り替えた後、EIPを内部接続ALBインスタンスに関連付けることができます。
EIPを内部対応のALBインスタンスに関連付けるには、インスタンスのネットワークタイプを変更します。 内部対応のALBインスタンスをインターネット対応のALBインスタンスに変更できます。 詳細については、「ALBインスタンスのネットワークタイプの変更」をご参照ください。
ネットワークタイプをインターネット接続に切り替えた後、ALBインスタンスはEIPを使用してインターネット経由でサービスを提供します。 インターネット経由のデータ転送に対して課金されます。 詳細については、「従量課金」をご参照ください。
ALBコンソールで証明書をアップロードできますか?
いいえ、ALBコンソールで証明書をアップロードできません。
ALBは、Alibaba Cloud Certificate Management Serviceの証明書を使用します。 ALBコンソールではなく、Certificate Management Serviceコンソールで証明書をアップロードする必要があります。 詳細については、「SSL証明書のアップロード」をご参照ください。
ALBはトラフィックミラーリングをサポートしていますか?
はい、ALBはトラフィックのミラーリングをサポートします。 詳細については、「運用トラフィックをステージング環境にミラーリングする」をご参照ください。
ALBインスタンスをIPv4からデュアルスタックに、またはデュアルスタックからIPv4に切り替えることはできますか?
いいえ、ALBインスタンスのIPモードを切り替えることはできません。
IPv4またはデュアルスタックALBインスタンスを使用する必要がある場合は、インスタンスを作成します。
DNSレコードを削除するときに注意する必要がありますか?
DNSレコードを削除できるのは、静的IPアドレスを使用するALBインスタンスのみです。 動的に割り当てられたIPアドレスを使用するALBインスタンスでは、DNSレコードを削除できません。
ゾーンからDNSレコードを削除すると、ゾーンの仮想IPアドレス (VIP) のプロービングも停止します。 一方、IPv4アドレスとIPv6アドレスを含むEIPとVIPはゾーンから削除されます。 IPv4またはIPv6アドレスのみの削除はサポートされていません。
WAF 2.0の透過プロキシモードとWAF 3.0のサービス統合モードの違いは何ですか?
次のセクションでは、WAF 2.0の透過プロキシモードとWAF 3.0のサービス統合モードの違いについて説明します。
WAF 2.0の透過プロキシモード: リクエストは、リクエストがALBまたはCLBに転送される前にWAFによってフィルタリングされます。 透過プロキシモードでは、リクエストは2つのゲートウェイを通過します。 WAFおよびServer Load Balancer (SLB) のタイムアウト期間と証明書を設定する必要があります。
WAF 3.0のサービス統合モード: WAFはバイパスモードでデプロイされ、リクエストはALBに直接転送されます。 リクエストがバックエンドサーバーに転送される前に、ALBはリクエストコンテンツを抽出してフィルタリングのためにWAFに送信します。 サービス統合モードでは、リクエストは1つのゲートウェイを通過します。 これにより、ゲートウェイ間で証明書と設定を同期する必要がなくなり、同期の問題を防ぎます。
詳細については、「WAF 3.0とWAF 2.0の比較」をご参照ください。
WAFをALBと統合するにはどうすればよいですか?
ALBはWAF 3.0と統合されています。 ALBインスタンスをWAFで保護する場合は、WAF対応のALBインスタンスを購入してください。 WAF対応のALBインスタンスを購入するときは、次の情報に注意してください。
Alibaba CloudアカウントにWAF 2.0インスタンスがない場合、またはWAFが有効化されていない場合: WAF対応ALBインスタンスを購入することで、インターネットおよび内部ALBインスタンスのWAF 3.0を有効にできます。 このように、ALBはサービスレベルでWAFとインターフェイスされます。 詳細については、「WAF対応ALBインスタンスの有効化と管理」をご参照ください。
WAF対応のALBインスタンスをサポートするリージョン (ALBがWAF 3.0と統合されているリージョン)
地域
リージョン
中国
中国 (成都) 、中国 (青島) 、中国 (北京) 、中国 (広州) 、中国 (杭州) 、中国 (ウランカブ) 、中国 (上海) 、中国 (深セン) 、中国 (張家口) 、中国 (香港)
アジア太平洋
フィリピン (マニラ) 、インドネシア (ジャカルタ) 、日本 (東京) 、マレーシア (クアラルンプール) 、オーストラリア (シドニー) 、シンガポール、インド (ムンバイ) 、タイ (バンコク)
ヨーロッパおよびアメリカ
ドイツ (フランクフルト) 、米国 (シリコンバレー) 、米国 (バージニア)
中東
サウジアラビア (リヤド - パートナーリージョン)
Alibaba Cloudアカウントに既にWAF 2.0インスタンスがある場合: 透過プロキシモードの基本的なインターネット向けALBインスタンスおよび標準のインターネット向けALBインスタンスに対してWAF 2.0を有効にできます。 内部対応のALBインスタンスはWAF 2.0をサポートしていません。
透過プロキシモードでWAF 2.0とインターフェイスできるのは、中国 (杭州) 、中国 (上海) 、中国 (深セン) 、中国 (成都) 、中国 (北京) 、中国 (張家口) のリージョンのALBインスタンスのみです。
説明ALBインスタンスのWAF 3.0を有効にする場合は、最初にWAF 2.0インスタンスをリリースするか、WAF 3.0に移行します。
WAF 2.0インスタンスをリリースすると、デフォルトでALBに対してX-Forwarded-Protoヘッダーが無効になっているため、サービスエラーが発生する可能性があります。 エラーを防ぐには、ALBインスタンスのリスナーのX-Forwarded-Protoヘッダーを有効にする必要があります。 詳細については、「リスナーの管理」をご参照ください。
WAF 2.0インスタンスをリリースする方法の詳細については、「WAFサービスの終了」をご参照ください。
WAF 3.0への移行方法の詳細については、「WAF 2.0インスタンスのWAF 3.0への移行」をご参照ください。
CLBとALBはWAF 2.0とWAF 3.0をサポートしていますか?
サービス | WAF 2.0 (透過プロキシモード) | WAF 3.0 (サービス統合モード) |
CLB | サポートされています。 透過プロキシモードでWAF 2.0をCLBに接続する方法の詳細については、以下のトピックを参照してください。 | サポートされていません。 |
ALB |
| サポートされています。 サポートされているリージョンと関連する操作の詳細については、「WAF対応ALBインスタンスのアクティブ化と管理」をご参照ください。 |
WAF 2.0をALBまたはCLBと統合した後、タイムアウト期間と証明書が同期されないのはなぜですか。
WAF 2.0をALBまたはCLBと統合すると、クライアント要求はALBまたはCLBに転送される前にWAFによってフィルタリングされます。 リクエストは2つのゲートウェイを通過し、WAFとALBまたはCLBの間で設定を同期する必要があります。 タイムアウト期間または証明書を変更すると、遅延が原因で同期の問題が発生する可能性があります。
証明書が更新されない場合、またはタイムアウト期間の変更が有効にならない場合は、DingTalkグループ21715946に参加して相談してください。
ALBインスタンスがリスナーの転送ルールで設定されている最大QPSに達しないのはなぜですか。
仕組み: ALBは、ネットワークトラフィックをバックエンドサーバーのグループに均等に分散することにより、負荷分散サービスを提供します。 転送ルールで設定した最大QPSは、各バックエンドサーバーに均等に割り当てられます。
各バックエンドサーバーの最大QPSは、次の式を使用して計算されます。
各バックエンドサーバーの最大QPS=合計QPS/(N-1)。 Nは、サーバーグループ内のバックエンドサーバーの数を指定します。 たとえば、転送ルールで最大QPSを1,000に設定します。 バックエンドサーバーの数が8の場合、各バックエンドサーバーの最大QPSは、1000/(8-1) = 142の式を使用して計算されます。原因: 少数の永続接続が使用されるシナリオでは、サーバーグループ内のすべてのバックエンドサーバーに永続接続が割り当てられるわけではありません。 その結果、ALBインスタンスは最大QPSに達することができません。
提案: サービスの中断を防ぐために、転送ルールの最大QPSをビジネス要件に基づいて適切な値に設定することを推奨します。 転送ルールで最大QPSを設定する方法の詳細については、「リスナーの転送ルールの管理」トピックの転送ルールの作成セクションをご参照ください。
ALBインスタンスによって転送できるリクエストの最大サイズはどれくらいですか。 許容最大サイズを増やすことはできますか?
クライアント要求のURIまたはHTTPヘッダーの最大サイズは32 KBです。 許容最大サイズを増やすことはできません。 アクセスログに記録できるカスタムヘッダーのデフォルトの最大サイズは1 KBで、4 KBに増やすことができます。 増額をリクエストするには、アカウントマネージャーに連絡してください。
クライアント要求のURIまたはHTTPヘッダーのサイズが最大サイズを超える場合、HTTP 400または414ステータスコードが返される場合があります。 詳細は、「ALBステータスコード」をご参照ください。
大量のデータを送信する場合は、POSTメソッドを使用してデータを送信することを推奨します。 ALBへのPOSTリクエストの本体のサイズは最大50 GBです。
同じバックエンドサーバー内のすべてのバックエンドサーバーが正常でない場合、ALBインスタンスはどのようにリクエストを転送できますか?
ALBは、サービスの可用性を維持するためにスケジューリングアルゴリズムに基づいて要求を配信します。 この問題に対処するには、ログを確認してバックエンドサーバーにエラーが発生したかどうかを判断するか、ヘルスチェックの設定を確認します。 詳細については、「ヘルスチェックエラーのトラブルシューティング方法?」をご参照ください。
HTTP 500、502、503、および504ステータスコードが返されるのはなぜですか。
500 (内部サーバーエラー)
バックエンドサーバーで内部エラーが発生しました。 リクエストはバックエンドサーバーで処理できません。
考えられる原因：
バックエンドサーバーはHTTP 500ステータスコードを返し、ALBはバックエンドステータスコードをクライアントに渡します。 バックエンドサーバーがHTTP 500のステータスコードを返す理由を確認します。
バックエンドサーバーは、応答を送信する前に接続を閉じます。 原因を特定し、トラブルシューティングするために、バックエンドサーバーでパケットをキャプチャすることを推奨します。
502 (悪いゲートウェイ)
ALBのHTTPまたはHTTPSリスナーがバックエンドサーバーにリクエストを送信できなかったか、バックエンドサーバーからレスポンスが返されませんでした。 その結果、HTTP 502のステータスコードがクライアントに返されました。
考えられる原因：
バックエンドサーバーはHTTP 502ステータスコードを返し、ALBはバックエンドステータスコードをクライアントに渡します。 バックエンドサーバーがHTTP 502のステータスコードを返す理由を確認します。
ALBバックエンドサーバーは別のHTTPステータスコード (504や444など) を返しますが、ALBはHTTP 502ステータスコードを返します。 アクセスログまたはキャプチャパケットのupstream_statusフィールドとstatusフィールドをチェックして、バックエンドサーバーにエラーがないかどうかを確認することを推奨します。
TCPを介したALBとバックエンドサーバー間の通信にエラーが含まれています。 バックエンドサーバーが正常かどうか、サービスポートがリスナーによってリッスンされているかどうか、またはTCPハンドシェイクが成功したかどうかを確認します。
バックエンドサーバーのバックログがいっぱいになると、パケットがドロップされます。 バックエンドサーバーのネットワーク統計がドロップされたパケットの数を示すかどうかを確認するには、netstatを使用することを推奨します。 たとえば、
netstat -s | grep -i listenコマンドを実行できます。クライアントから送信されたパケットの長さが、バックエンドサーバーの最大送信単位 (MTU) を超えています。 この場合、ヘルスチェックが成功するか、短いパケットが期待どおりに送信されます。 しかしながら、より長いパケットは期待通りに送信されない。 バックエンドサーバーでパケットをキャプチャして、パケット長が要件を満たしているかどうかを分析することを推奨します。
バックエンドサーバーから返されたパケットは、無効な形式であるか、無効なHTTPヘッダーが含まれています。 バックエンドサーバーでパケットをキャプチャして、HTTP応答の形式が無効かどうかを確認することを推奨します。
ALBのバックエンドサーバーがリクエストの処理を完了していません。 バックエンドサーバーのログデータを確認します。 また、CPUとメモリの使用量を確認してください。
503 (一時的に使用できないサービス)
サービスは利用できません。 これは、トラフィックが制限を超えているか、バックエンドサーバーが利用できないためです。
考えられる原因：
バックエンドサーバーはHTTP 503ステータスコードを返し、ALBはバックエンドステータスコードをクライアントに渡します。 バックエンドサーバーがHTTP 503のステータスコードを返す理由を確認します。
クライアントからのネットワークトラフィックがALBスロットリングをトリガーします。 次のいずれかの方法を使用して、問題をトラブルシューティングできます。
CloudMonitorコンソールで1秒あたりのリクエスト数を表示します。 詳細については、「ALBモニタリングメトリクス」および「ALBインスタンスに関するモニタリング情報の表示」をご参照ください。
CloudMonitorは、モニタリングデータを分レベルで表示します。 アクセスログを使用して、1秒あたりのリクエスト数を表示できます。 アクセスログのupstream_statusフィールドを表示します。 コンテンツが「-」の場合、リクエストはバックエンドサーバーに送信されません。
レスポンスヘッダーにALB-QPS-Limited:Limitedフィールドが含まれているかどうかを確認します。 そうである場合、要求がALBスロットリングをトリガしたことを示す。
クライアントは、ALBにアクセスするときにドメイン名を使用する代わりにALBインスタンスのIPアドレスにアクセスします。または、クライアントがドメイン名を使用してALBにアクセスするときにDNS解決結果を更新しません。 その結果、リクエストを複数のALB IPアドレスに分散することはできず、HTTP 503エラーコードが返されます。 クライアントは、IPアドレスではなくALBのドメイン名にアクセスすることを推奨します。 さらに、クライアントがALBにアクセスするためにDNSによって返された異なるIPアドレスを使用することを確認します。
バックエンドサーバーがALBリスナーに関連付けられていないか、バックエンドサーバーの重みが0に設定されています。
504 (ゲートウェイのタイムアウト)
バックエンドサーバーの応答がタイムアウトしました。
考えられる原因：
バックエンドサーバーから504ステータスコードが返された場合は、バックエンドサーバーがオーバーロードされているかどうかを確認します。
ALBからバックエンドサーバーへの接続がタイムアウトしました。 タイムアウト時間はデフォルトで5秒に設定されています。 アクセスログのupstream_connect_timeフィールドが5秒または約5秒に設定されているかどうかを確認できます。 レスポンスタイムアウトの原因を特定するために、パケットをキャプチャすることを推奨します。
バックエンドサーバーのワークロードは重く、応答を返すのに必要な時間は、指定されたタイムアウト期間よりも長くなります。 たとえば、リクエストタイムアウト時間は60秒に設定されます。 応答時間が60.001秒の場合、ALBはHTTP 504ステータスコードを返します。 CloudMonitorコンソールまたはアクセスログで、問題が発生した期間中のネットワーク待ち時間を表示できます。 ネットワーク遅延を表示するには、CloudMonitorのupstream_rtフィールド、またはアクセスログのupstream_response_timeフィールドを確認します。
ALB Ingressを使用するときに注意する必要がありますか?
ALB Ingressコントローラーは、AlbConfigオブジェクトを使用してALBインスタンスを設定します。 ALBコンソールでALB Ingressコントローラーを使用して作成されたALBインスタンスの設定を手動で変更しないことを推奨します。 ALB Ingressの詳細については、「ALB Ingressの概要」および「ALB Ingress機能」をご参照ください。
ALBコンソールでALB Ingressコントローラーを使用して作成されたALBインスタンスの設定を手動で変更すると、手動で変更された設定はAlbConfigオブジェクトによって上書きされます。 これにより、アクセスログ機能の無効化やルーティングルールの削除などの例外が発生する可能性があります。
よくある質問ALBのCORS機能
クロスオリジンリソース共有 (CORS) の設定が有効にならず、ブラウザがプリフライト要求エラーをスローするのはなぜですか?
[Allowed Request Headers] パラメーターにアスタリスク (*) の代わりに特定のヘッダー名が指定されている場合、テスト用に [Allowed Request Headers] をアスタリスク (*) に設定できます。 問題が解決した場合は、Access-Control-Request-Headersのheader_name属性が設定に含まれているかどうかを確認してください。 そうでない場合、header_name属性がないことが失敗の原因です。
プリフライト要求と実際の要求が異なる転送ルールを採用するのはなぜですか?
ALBは、転送ルールに対して複数のマッチング方法をサポートします。 ただし、CORSのプリフライト要求のヘッダーとメソッドは特殊で、実際の要求のヘッダーとメソッドは異なります。 CORSを使用する場合は、ドメイン名を使用して転送ルールを設定することを推奨します。 これにより、プリフライト要求と実際の要求が、CORSルールで設定されていない転送ルールと一致しないようになります。