Global Traffic Manager
Global Traffic Manager の概念
GTM と SLB
A:Global Traffic Manager (GTM) は、DNS を用いてドメイン名を複数の IP アドレスに解決し、ユーザーを異なる IP アドレスに誘導することで、アプリケーションのトラフィックを分散します。また、ヘルスチェックを使用して DNS 応答に含まれる IP アドレスのリストを動的に更新し、障害分離とフェールオーバーを実現します。エンドユーザーのトラフィックはサービスの IP アドレスに直接接続し、GTM を経由しません。対照的に、Server Load Balancer (SLB) はプロキシとして機能し、ユーザーリクエストをリアルタイムで異なるバックエンドサーバーに分散します。すべてのユーザートラフィックは SLB インスタンスを通過する必要があります。
一般的に、単一リージョン内の負荷分散には SLB を使用します。異なるリージョンに複数の SLB エンドポイントがある場合は、GTM を使用してそれらの間で負荷分散を行うことができます。
次の表は、GTM と SLB を比較したものです。
機能 | ネットワーク層 | バックエンドアドレス | 加重ラウンドロビン | リージョン間の複雑さ | フェールオーバー時間 | セッション維持 |
Global Traffic Manager | レイヤー 3 | ドメイン名、IP | サポート | シンプル | 分単位 | 非対応 |
Server Load Balancer | レイヤー 4、レイヤー 7 | IP | サポート | 複雑 | 秒単位 | サポート |
GTM と Alibaba Cloud DNS
A:Alibaba Cloud DNS は、ドメイン名を IP アドレスに変換し、複数タイプの解決レコードをサポートする名前解決サービスを提供します。GTM は、Alibaba Cloud DNS のインテリジェント DNS 解決機能を拡張し、ヘルスチェックとフェールオーバーを追加します。ユーザーを地理的な場所に基づいて最寄りのエンドポイントに誘導し、サービスの状態をリアルタイムで監視します。
アクセスドメイン
GTM インスタンスごとの複数ドメイン
A:場合によります。
複数のサービスドメインが同じ IP アドレス群に解決される場合、CNAME レコードを使用してそれらを同じ GTM アクセスドメインに向けることができます。それ以外の場合は、各サービスドメインに個別の GTM インスタンスが必要です。
1. 単一の GTM インスタンスのシナリオ
サービスドメイン www.example.com は 1.1.XX.XX と 2.2.XX.XX に解決され、これらの IP アドレス間でディザスタリカバリが必要です。
サービスドメイン test.example.com も 1.1.XX.XX と 2.2.XX.XX に解決され、これらの IP アドレス間でディザスタリカバリが必要です。
このシナリオでは、両方のサービスドメインが同じ IP アドレス群に解決されるため、必要な GTM インスタンスは 1 つだけです。その後、www.example.com と test.example.com の両方に CNAME レコードを作成し、それらを GTM のアクセスドメインに向けます。詳細については、「アクセスドメインの設定」をご参照ください。
2. 複数の GTM インスタンスのシナリオ
サービスドメイン www.example.com は 1.1.XX.XX と 2.2.XX.XX に解決され、これらの IP アドレス間でディザスタリカバリが必要です。
サービスドメイン test.example.com は 1.1.XX.XX と 3.3.XX.XX に解決され、これらの IP アドレス間でディザスタリカバリが必要です。
このシナリオでは、サービスドメインは異なる IP アドレス群に解決されます。サービスドメインごとに個別の GTM インスタンスを購入する必要があります。
GTM CNAME ドメインへのアクセス
A:はい。GTM アクセスドメインは直接アクセス可能な URL です。また、他の顧客向けサービスドメインの CNAME レコードの値として使用することもできます。
GTM の障害検出
A:GTM は世界中の複数のノードからアプリケーションサービスを監視します。監視ノードの組み合わせを使用してアラートをトリガーし、サービスの全体的な健全性を判断できます。Ping、TCP、または HTTP(S) ヘルスチェックから選択して、アプリケーションサービスを監視し、障害を検出できます。
Ping ヘルスチェック:パケット損失率と応答時間に基づいてサービスの障害を判断します。
TCP ヘルスチェック:ポートの応答時間に基づいてサービスの障害を判断します。
HTTP/HTTPS ヘルスチェック:応答時間と応答ステータスコードに基づいてサービスの障害を判断します。
GTM のフェールオーバー時間
A:広範なテストに基づき、GTM Ultimate Edition は約 1 分で障害を正確に検出し、フェールオーバーを開始できます。総復旧時間は、障害検出時間とネットワーク伝播時間の合計です。
Standard Edition は約 3 分で障害を検出し、フェールオーバーを開始できます:
ヘルスチェック間隔が 60 秒、TTL が 60 秒、連続障害回数が 2 回の場合、GTM は約 3 分で障害を正確に検出し、フェールオーバーを開始できます。
ネットワーク全体の伝播時間:GTM は特定のネットワーク全体の伝播時間を保証できません。これは、さまざまなインターネットサービスプロバイダー (ISP) の TTL キャッシュ設定とネットワーク状態によって異なります。
Ultimate Edition は約 1 分で障害を検出し、フェールオーバーを開始できます:
15 秒のヘルスチェック間隔、1 秒の TTL、3 回の連続障害の場合、GTM は約 1 分でフェールオーバーを開始します。
ネットワーク全体の伝播時間:GTM は特定のネットワーク全体の伝播時間を保証できません。これは、さまざまな ISP の TTL キャッシュ設定とネットワーク状態によって異なります。
アドレスプール内のドメイン名
A:はい。GTM のアドレスプールには IP アドレスまたはドメイン名を含めることができますが、同じアドレスプール内で両方を混在させることはできません。アドレスプールに複数のドメイン名が含まれている場合、GTM はデフォルトでラウンドロビン解決を実行します。
GTM とインテリジェント DNS
A:はい。GTM はインテリジェント DNS 解決を統合しています。GTM を使用して、中国のさまざまな ISP、7 つのリージョン、6 つの海外大陸、および特定の国からのユーザーに対してインテリジェント DNS 解決を実行できます。これにより、ユーザーは最寄りのアプリケーションエンドポイントに接続され、アクセス速度が向上します。
GTM とセッション維持
A:いいえ。GTM は DNS レベルの管理システムです。DNS 応答を使用してクライアントを適切なアプリケーションサービスアドレスにルーティングします。クライアントは GTM を経由せず、アプリケーションの IP アドレスに直接接続します。したがって、GTM はクライアントとサーバー間の HTTP トラフィックを認識しないため、セッション維持はサポートしていません。
GTM と CDN の使用
A:はい。CDN を GTM の前段に配置することができます。詳細については、「CDN と GTM を統合してアクセスセキュリティとサービス可用性を向上させる」をご参照ください。
GTM アドレスプール内の CDN CNAME
A:可能ですが、推奨されません。CDN は膨大な数のノードを持っていますが、GTM のヘルスチェックノードは限られています。この不一致は、不正確な監視につながり、ヘルスチェックとフェールオーバーの信頼性に影響を与える可能性があります。
DNS 解決の問題 (古い IP または NXDOMAIN)
A: Global Traffic Manager の DNS レコードが反映されるまでには時間がかかります。しばらくお待ちください。長時間経過してもレコードが反映されない場合は、以下の点を確認してください。
TTL の有効期限が切れているか確認します:
dig www.example.comを実行して TTL のカウントダウンを表示します。CNAME の設定を確認します:
dig +trace www.example.comを実行します。お使いのオペレーティングシステムに適したコマンド (例:Windows の場合は
ipconfig /flushdns) を使用して、ローカル DNS キャッシュをクリアします。
ヘルスチェックの失敗
A:ヘルスチェックが一貫して失敗するものの、サービスが稼働していることを確認した場合は、以下のトラブルシューティング手順に従ってください:
ファイアウォールが GTM プローブ IP アドレス範囲からのトラフィックを許可していることを確認してください。
ヘルスチェックパスをテストします:
curl -H "Host: domain" http://ip:port/pathを実行します。サーバーの負荷と応答時間を確認してください。
A レコードのアクセスドメインに対する CNAME クエリの失敗
「アドレスプールの設定」の制約によると、タイプが A の[アクセスドメイン]は、タイプがA とドメイン名のアドレスプールをサポートします。ただし、A レコードクエリにのみ応答します。CNAME クエリに応答するには、[アクセスドメイン]のアクセスタイプを CNAME に変更する必要があります。
課金
共有アドレスの課金
A:インスタンスは独立して課金されます。サブスクリプションインスタンスの場合、課金はアクセスドメインによって生成されたプローブタスクの数に基づき課金されます。従量課金インスタンスの場合、課金はアクセスドメインによって生成されたヘルスチェックプローブの数に基づき課金されます。
意図しない GTM の請求
A:この問題の原因と解決策は次のとおりです:
原因: Alibaba Cloud DNS の DNS レコードに対して [ヘルスチェック] 機能を有効にすると、システムは自動的に GTM の従量課金インスタンスを作成してレコードのフェールオーバーを実装し、これにより料金が発生します。GTM の従量課金インスタンスは、DNS クエリ量、ヘルスチェックプローブ、およびアクセスドメインの数に対して課金されます。従量課金モデルでこれらの機能を使用すると、料金が発生します。
解決策:
GTM コンソールにログインし、不要な GTM インスタンスがないか確認します。
サービスが依存していないことを確認した後、GTM インスタンスを削除して、以降の課金を停止できます。
課金サイクル: GTM は日次で課金されます。本日インスタンスを削除した場合、最終使用日の最終請求は翌日に生成されます。その翌日以降は請求は生成されません。
注意:
業務で使用している GTM インスタンスを誤って削除しないように、他のビジネス目的で GTM 設定に追加の変更 (解決ラインやアドレスプールの追加など) を加えていないか確認してください。
この操作は GTM インスタンスを削除するものであり、DNS レコードは削除されません。GTM インスタンスが削除されると、GTM アクセスドメインを指す DNS レコード (CNAME レコードなど) は無効になり、サービスドメインにアクセスできなくなる可能性があります。インスタンスを削除する前に、サービスへの影響を評価してください。必要に応じて、まず DNS レコードを更新してバックエンドサービスの IP アドレスを指すように更新してください。
Alibaba Cloud DNS のエディションと GTM のバインド制限
A:
GTM には無料版はありません。Global Traffic Manager は、サブスクリプションまたは従量課金制で利用できる有料機能です。
Alibaba Cloud DNS の無料版で GTM を使用する: Alibaba Cloud DNS の無料版を使用する場合、複数のサービスドメインからの CNAME レコードを同じ GTM アクセスドメインに向けることができます。バインドできるサービスドメインの数に制限はありません。
制限事項: 無料版の最小 TTL は 600 秒です。このため、分単位のフェールオーバーはできず、有料版よりもフェールオーバー時間が長くなります。
GTM と有料 DNS でのクエリ量が多い場合
A:はい。Global Traffic Manager と Alibaba Cloud DNS の有料版は別々の製品です。GTM はヘルスチェックとフェールオーバーを提供し、有料 DNS エディションはより高い DNS クエリクォータを提供します。1 日の DNS クエリ数が 100,000 (無料版の制限) を超える場合は、Alibaba Cloud DNS のいずれかの有料版を購入してクエリクォータを増やすことを推奨します。
誤って発生した GTM 料金の返金
A:一般的に、意図せず GTM を有効にしたことで発生した料金は返金対象外です。ただし、例外的な対応として、カスタマーサポートの判断により、補償としてクーポンを適用できる場合があります。現金での返金を要求する必要がある場合は、チケットを送信して、担当責任者によるケースレビューを依頼する必要があります。
スケジュールされた自動リリース
A:いいえ。GTM インスタンスはスケジュールによる自動リリースに対応していません。課金を停止するには、GTM インスタンスと関連するプローブテンプレートを手動で削除する必要があります。請求書の発行が遅れることがあります (通常は 1 日)。インスタンスが削除されると、課金は停止します。
アラート
アラート通知の未受信
A:アラート通知が届かない場合は、以下を確認してください:
アラートルールを確認する: アラートルールが作成され、有効になっていることを確認します。
連絡先のステータスを確認する: アラート連絡先管理ページで、受信者の電話番号またはメールアドレスが認証済みであることを確認します。
迷惑メールやブロックされたメッセージを確認する: メールの迷惑メールフォルダーや携帯電話の SMS ブロックリストを確認し、通知が誤ってフィルタリングされていないことを確認します。
ヘルスチェックログを確認する: アラートオブジェクト (アドレスまたはアドレスプール) のステータス変更がアラートルールをトリガーしたことを確認します。
アラートルールのトリガー
A:アラートルールは主にヘルスチェックステータスの変更によってトリガーされます。一般的なトリガーイベントは次のとおりです:
アドレスが利用不可: アドレスが指定された回数、連続してヘルスチェックに失敗したときにトリガーされます。
アドレスが回復: 以前利用不可だったアドレスが再び利用可能になったときにトリガーされます。
アドレスプールが利用不可: アドレスプール内のすべてのアドレスが利用不可になったときにトリガーされます。
アドレスプールが回復: 利用不可のアドレスプール内の少なくとも 1 つのアドレスが再び利用可能になったときにトリガーされます。