グローバルトラフィックマネージャー
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 に名前解決され、それらの間でディザスタリカバリが必要な場合。
サービスドメイン test.example.com も 1.1.XX.XX と 2.2.XX.XX に名前解決され、これら 2 つの 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 に名前解決され、これら 2 つの IP アドレス間でディザスタリカバリが必要な場合。
サービスドメイン test.example.com が 1.1.XX.XX と 3.3.XX.XX に名前解決され、これら 2 つの 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 秒、TTL が 1 秒、連続障害が 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: はい。GTM の前面に CDN を配置できます。詳細については、「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を実行します。オペレーティングシステムに適したコマンドを使用してローカル DNS キャッシュをクリアします (Windows の場合は
ipconfig /flushdnsなど)。
ヘルスチェックの失敗
A: ヘルスチェックが常に失敗するが、サービスが実行されていることを確認した場合は、次のトラブルシューティング手順に従ってください。
ファイアウォールが GTM プローブ IP アドレス範囲からのトラフィックを許可していることを確認します。
ヘルスチェックパスをテストします：
curl -H "Host: domain" http://ip:port/pathを実行します。サーバーの負荷と応答時間を確認します。
A レコードタイプのアクセスドメイン：CNAME クエリの失敗
「アドレスプールの設定」の制約によると、タイプ A の [アクセスドメイン] は、タイプ A および ドメイン名 のアドレスプールをサポートします。ただし、A レコードのクエリにのみ応答します。CNAME クエリに応答するには、[アクセスドメイン] のアクセスタイプを CNAME に変更する必要があります。
課金
共有アドレスの課金
A: インスタンスは個別に課金されます。サブスクリプションインスタンスの場合、課金はアクセスドメインによって生成されるプローブタスクの数に基づいています。従量課金インスタンスの場合、課金はアクセスドメインによって生成されるヘルスチェックプローブの数に基づいています。
意図しない GTM の課金
A: この問題の原因と解決策は次のとおりです。
原因：意図せずに Global Traffic Manager (GTM) またはヘルスチェックを有効にしたため、従量課金インスタンスの料金が発生した可能性があります。GTM 従量課金インスタンスは、DNS クエリ量、ヘルスチェックプローブ、およびアクセスドメインの数に対して課金されます。従量課金モデルでは、これらの機能を使用すると料金が発生します。
解決策：
GTM コンソールにログインし、不要な GTM インスタンスがないか確認します。
サービスが依存していないことを確認した後、GTM インスタンスを削除して、今後の課金を停止します。
注：この操作により、GTM インスタンスが削除されますが、DNS レコードは削除されません。GTM インスタンスが削除されると、GTM アクセスドメインを指す DNS レコード (CNAME レコードなど) は無効になり、サービスドメインにアクセスできなくなる可能性があります。インスタンスを削除する前に、サービスへの影響を評価してください。必要に応じて、まず DNS レコードをバックエンドサービスの IP アドレスを指すように更新してください。
Alibaba Cloud DNS のエディションと GTM のバインド制限
A:
GTM に Free Edition はありません。Global Traffic Manager (GTM) は、サブスクリプションまたは従量課金で利用できるプレミアム機能です。
Alibaba Cloud DNS の Free Edition で GTM を使用する：Alibaba Cloud DNS の Free Edition を使用する場合、複数のサービスドメインから同じ GTM アクセスドメインに CNAME レコードをポイントできます。バインドできるサービスドメインの数に制限はありません。
制限：Free Edition の最小 TTL は 600 秒です。これにより、分単位のフェイルオーバーができなくなり、有料エディションよりもフェイルオーバー時間が長くなります。
GTM と有料 DNS を使用した場合の大量クエリ
A: はい。Global Traffic Manager (GTM) と Alibaba Cloud DNS の有料エディションは別個の製品です。GTM はヘルスチェックとフェイルオーバーを提供し、有料 DNS エディションはより高い DNS クエリクォータを提供します。1 日あたりの DNS クエリ数が 100,000 件 (Free Edition の制限) を超える場合は、Alibaba Cloud DNS の有料エディションを購入してクエリクォータを増やすことを推奨します。
誤って発生した GTM 料金の払い戻し
A: 一般的に、意図せずに GTM を有効にしたことで発生した料金は払い戻しできません。ただし、カスタマーサポートの判断により、補償としてクーポンが適用される場合があります。現金での払い戻しを希望する場合は、チケットを送信して、担当マネージャーによるケースのレビューを受ける必要があります。
スケジュールされた自動リリース
A: いいえ。GTM インスタンスは、スケジュールされた自動リリースをサポートしていません。課金を停止するには、GTM インスタンスとそれに関連するプローブテンプレートを手動で削除する必要があります。請求明細への反映には、通常 1 日程度の遅延が生じる場合があります。インスタンスが削除されると、課金は停止します。
アラート
アラート通知の未受信
A: 予想されるアラート通知を受信しない場合は、次を確認してください。
アラートルールを確認する：アラートルールが作成され、有効になっていることを確認します。
連絡先のステータスを確認する：アラート連絡先管理ページで、受信者の電話番号またはメールアドレスが検証済みであることを確認します。
スパムまたはブロックされたメッセージを確認する：メールのスパムフォルダーまたは電話の SMS ブロックリストを確認して、通知が誤ってフィルタリングされていないことを確認します。
ヘルスチェックログを確認する：アラートオブジェクト (アドレスまたはアドレスプール) のステータス変更がアラートルールをトリガーしたことを確認します。
アラートルールのトリガー
A: アラートルールは、主にヘルスチェックステータスの変更によってトリガーされます。一般的なトリガーイベントには次のものがあります。
アドレスが利用不可：アドレスが指定された回数の連続したヘルスチェックに失敗したときにトリガーされます。
アドレスが復旧：以前に利用不可だったアドレスが再び利用可能になったときにトリガーされます。
アドレスプールが利用不可：アドレスプール内のすべてのアドレスが利用不可になったときにトリガーされます。
アドレスプールが復旧：利用不可だったアドレスプール内の少なくとも 1 つのアドレスが再び利用可能になったときにトリガーされます。