Azure Communications Gateway の信頼性

  • [アーティクル]

Azure Communications Gateway は、Azure 冗長メカニズムと SIP 固有の再試行動作を使用することによりサービスの信頼性を確保します。 サービスの可用性を確保するには、ネットワークが特定の要件を満たしている必要があります。

Azure Communications Gateway の冗長性モデル

Azure Communications Gateway の運用デプロイ (標準デプロイとも呼ばれます) は、3 つの別個のリージョン (1 つの "管理リージョン" と 2 つの "サービス リージョン") で構成されます。 ラボのデプロイは、1 つの管理リージョンと 1 つのサービス リージョンで構成されます。

この記事では、これら 2 つの異なるリージョンの種類とその個別の冗長性モデルについて説明します。 可用性ゾーンによるリージョンの回復性と、ディザスター リカバリーによるリージョン間の回復性の両方について扱います。 Azure における信頼性の詳細については、Azure の信頼性に関するページを参照してください。

2 つのサービス リージョン、1 つの管理リージョン、2 つのオペレーター サイトの図。

サービス リージョン

サービス リージョンには、ネットワークと選択した通信サービスの間のトラフィックを処理するための音声および API インフラストラクチャが含まれています。

Azure Communications Gateway の運用デプロイには 2 つのサービス リージョンがあり、これらはアクティブ/アクティブ モード (Operator Connect および Teams Phone Mobile プログラムで必要) でデプロイされます。 サービス リージョン間の高速フェールオーバーは、インフラストラクチャ/IP レベルとアプリケーション (SIP/RTP/HTTP) レベルで提供されています。

サービス リージョンには、Azure Communications Gateway の プロビジョニング API も含まれています。

ヒント

選択したサービス リージョンの 1 つが、リージョンが 1 つだけの Azure 地域 (カタールなど) にある場合でも、運用デプロイには常に 2 つのサービス リージョンが必要です。 単一リージョンの Azure 地域を選択する場合は、別の Azure 地域に 2 つ目の Azure リージョンを選択します。

これらのサービス リージョンは動作面では同一であり、ゾーンとリージョンの両方の障害に対する回復性を提供します。 各サービス リージョンは、Azure Communications Gateway インスタンスを使用してトラフィックの 100% を伝送できます。 そのため、エンド ユーザーは、ゾーンまたは地域のダウンタイム中でも通話を正常に発信および受信できるはずです。

ラボのデプロイのサービス リージョンは 1 つです。

通話ルーティングの要件

Azure Communications Gateway には、"成功した再ダイヤル" 冗長性モデルが用意されています。障害が発生したピアが処理している通話は終了しますが、新しい通話は正常なピアにルーティングされます。 このモデルは、Microsoft Teams によって提供される冗長性モデルを反映しています。

運用デプロイの場合、ネットワークには 2 つの地理的に冗長なサイトが必要です。 各サイトは、Azure Communications Gateway リージョンとペアになっている必要があります。 この冗長性モデルは、ネットワークと Azure Communications Gateway サービス リージョン間のクロス接続に依存します。

2 つのオペレーター サイトと 2 つのサービス リージョンの図。両方のサービス リージョンは、プライマリ ルートとセカンダリ ルートを使用して両方のサイトに接続します。

ラボのデプロイは、ネットワーク内の 1 つのサイトに接続する必要があります。

各 Azure Communications Gateway サービス リージョンは、SRV レコードを提供します。 このレコードには、リージョン内の SBC 機能 (通信サービスへの通話ルーティング用) を提供するすべての SIP ピアが含まれています。 この SRV レコードは、オンボード チームによって提供される /28 IP 範囲の任意の IP アドレスを指すことができます。

Azure Communications Gateway にモバイル コントロール ポイント (MCP) が含まれている場合、各サービス リージョンは MCP 用に追加の SRV レコードを提供します。 それぞれのリージョン別 MCP レコードには、最も優先度の高いリージョン内の MCP と、優先順位の低い他のリージョンの MCP が含まれます。

ネットワーク内の各サイトは、次の手順を実行する必要があります。

  • 既定では、ローカルの Azure Communications Gateway サービス リージョンにトラフィックを送信します。
  • RFC 3263 で概説されているように、DNS SRV を使用してリージョン内の Azure Communications Gateway ピアを見つけます。
    • _sip._tls.<regional-FQDN-from-portal> を使用して、サービス リージョンのネットワークへの接続のドメイン名に対して DNS SRV 参照を行います。 Azure portal で、<regional-FQDN-from-portal> をリソースの [概要] ページの [ホスト名] フィールドのリージョンごとの FQDN に置き換えます。 たとえば、デプロイで commsgw.azure.com ドメイン名が使用されている場合は、最初のリージョン向けに _sip._tls.pstn-region1.<deployment-id>.commsgw.azure.com を検索します。
    • SRV 参照で複数のターゲットが返される場合は、各ターゲットの重みと優先度を使用して 1 つのターゲットを選択します。
  • 使用可能な Azure Communications Gateway ピアに新しい通話を送信します。
  • Azure Communications Gateway に関連付けられている各 IP 範囲の任意の IP アドレスからトラフィックを受信できる。

ネットワークが SBC 機能のために Azure Communications Gateway の SIP ピアに通話をルーティングする場合、次の手順を実行する必要があります。

  • SIP OPTIONS (または OPTIONS と SIP トラフィックの組み合わせ) を使用して、Azure Communications Gateway SIP ピアの可用性を監視します。
  • 408 応答、503 応答、または 504 応答を受信した、または応答を受信しなかった INVITE を、ローカル サイト内の他の使用可能なピアに再ルーティングすることで再試行します。 ローカル サービス リージョン内のすべてのピアで障害が発生した場合にのみ、他のサービス リージョン (他のリージョンの SRV レコードで定義されるもの) を使用します。
  • 408、503、504 以外のエラー応答を受信した呼び出しは再試行しないでください。

Azure Communications Gateway のデプロイに統合されたモバイル コントロール ポイント (MCP) が含まれている場合、ネットワークは MCP に対して以下を行う必要があります。

  • リージョン内の MCP が使用不可の場合を検出し、そのリージョンの SRV レコードのターゲットを使用不可としてマークし、定期的に再試行してリージョンが再び使用可能かどうかを判断します。 MCP は SIP OPTIONS に応答しません。
  • MCP からの 5xx 応答は組織のポリシーに従って処理します。 たとえば、要求を再試行する、または Azure Communications Gateway と Microsoft Phone System を経由せずに通話を続行することを許可することも可能です。

このルーティング動作の詳細は、ネットワーク固有です。 これらについては、統合プロジェクト中にオンボード チームと同意する必要があります。

管理リージョン

管理リージョンには、Azure Communications Gateway の順序付け、監視、課金に使用されるインフラストラクチャが含まれています。 これらのリージョン内のすべてのインフラストラクチャは、ゾーン冗長な方法でデプロイされます。つまり、すべてのデータがリージョン内の各可用性ゾーンに自動的にレプリケートされます。 すべての重要な構成データは、Azure リージョンでの障害発生時にサービスが適切に機能するように、各サービス リージョンにもレプリケートされます。

可用性ゾーンのサポート

Azure 可用性ゾーンとは、各 Azure リージョン内にある、3 つ以上に物理的に分離されたデータセンターのグループです。 各ゾーン内のデータセンターには、独立した電源、冷却手段、ネットワーク インフラストラクチャが備わっています。 ローカル ゾーンの障害が発生した場合、可用性ゾーンは、1 つのゾーンが影響を受けたときに、リージョンのサービス、容量、高可用性が残りの 2 つのゾーンによってサポートされるように設計されています。

障害の範囲は、ソフトウェアやハードウェアの障害から、地震、水害、火災などの事象に至る可能性があります。 Azure サービスの冗長と論理的な分離により、障害に対するトレランスが実現されます。 Azure の可用性ゾーンの詳細については、リージョンと可用性ゾーンに関する記事を参照してください。

Azure の可用性ゾーン対応サービスは、適切なレベルの信頼性と柔軟性を提供するように設計されています。 それらは 2 つの方法で構成できます。 それらは、ゾーン間の自動レプリケーションによるゾーン冗長、またはインスタンスを特定のゾーンにピン留めするゾーンベースのいずれかになります。 これらのアプローチを組み合わせることもできます。 ゾーン ベースとゾーン冗長のアーキテクチャを比較した詳細については、「可用性ゾーンとリージョンの使用に関する推奨事項」を参照してください。

サービス リージョンのゾーン ダウン エクスペリエンス

ゾーン全体の停止中、影響を受けるゾーンによって処理された通話は終了され、サービスの自己復旧によって基になるリソースが正常なゾーンに再調整されるまで、リージョン内の容量が短時間失われます。 この自己復旧はゾーンの復元には依存しません。Microsoft が管理するサービスの自己修復状態により、他のゾーンの容量を使用して失われたゾーンが補填されることが期待されます。 トラフィックを運ぶリソースはゾーン冗長方式でデプロイされますが、最も小規模な場合では、トラフィックは単一のリソースによって処理される可能性があります。 この場合、この記事で説明されているフェールオーバー メカニズムは、トラフィックを運ぶリソースが正常なゾーンに再デプロイされる間は、すべてのトラフィックを他のサービス リージョンへと再調整します。

管理リージョンのゾーンダウン エクスペリエンス

ゾーン全体の停止中、ゾーンの復旧中に必要なアクションはありません。 管理リージョンは、正常なゾーンを自動的に利用して自己修復と再調整を行います。

ディザスター リカバリー: 他のリージョンへのフォールバック

ディザスター リカバリー (DR) とは、自然災害やデプロイの失敗など、ダウンタイムやデータ損失につながる影響の大きいイベントから復旧することです。 原因に関係なく、災害に対する最善の解決策は、明確に定義されテストされた DR プランと、DR を積極的にサポートするアプリケーション設計です。 ディザスター リカバリー計画の作成を検討する前に、「ディザスター リカバリー戦略の設計に関する推奨事項」を参照してください。

DR に関しては、Microsoft は共有責任モデルを使用します。 共有責任モデルでは、ベースライン インフラストラクチャとプラットフォーム サービスの可用性が Microsoft によって保証されます。 同時に、多くの Azure サービスでは、データのレプリケート、または障害が発生したリージョンから別の有効なリージョンにクロスレプリケートするフォールバックは、自動的には行われません。 それらのサービスについては、お客様がワークロードに適したディザスター リカバリー計画を設定する必要があります。 Azure PaaS (サービスとしてのプラットフォーム) オファリング上で実行されるほとんどのサービスには、DR をサポートするための機能とガイダンスが用意されており、お客様はサービス固有の機能を使って迅速な復旧をサポートでき、DR 計画の開発に役立ちます。

このセクションでは、リージョン全体の停止時における Azure Communications Gateway の動作について説明します。

ディザスター リカバリー: サービス リージョンのリージョン間フェールオーバー

リージョン全体の停止時には、この記事で説明されているフェールオーバー メカニズム (OPTIONS ポーリングと障害時の SIP 再試行) により、すべての通話トラフィックが他のサービス リージョンへと再調整され、可用性が維持されます。 リージョン冗長の復元を開始します。 長時間のダウンタイム中にリージョン冗長を復元するには、他の Azure リージョンを使用することが必要な場合があります。 障害が発生したリージョンを別のリージョンに移行する必要がある場合は、Microsoft は一切の移行を開始する前にお客様に相談します。

Azure Communications Gateway の SBC 機能では、ネットワークがピアの可用性を判断できるように OPTIONS ポーリングが提供されています。 MCP の場合、ネットワークは MCP が使用不可の場合を検出し、定期的に再試行して MCP が再び使用可能になったかどうかを判断できる必要があります。 MCP は SIP OPTIONS に応答しません。

プロビジョニング API クライアントでは、デプロイのベース ドメイン名を使用して Azure Communications Gateway に接続します。 このドメインの DNS レコードの有効期間 (TTL) は 60 秒です。 リージョンに障害が発生すると、Azure では、別のリージョンを参照するように DNS レコードが更新されます。そのため、新しい DNS 参照を行うクライアントは新しいリージョンの詳細を受信します。 クライアントで新しい DNS 参照を行い、タイムアウトまたは 5xx 応答の 60 秒後に要求を再試行できるようにすることをお勧めします。

ヒント

ラボのデプロイでは、リージョン間フェールオーバーは提供されません (サービス リージョンが 1 つしかないためです)。

ディザスター リカバリー: 管理リージョンのリージョン間フェールオーバー

番号管理ポータルを介した音声トラフィックとプロビジョニングでは、対応する Azure リソースはサービス リージョンでホストされているため、管理リージョンでの障害の影響を受けません。 番号管理ポータルのユーザーは、再度のサインインが必要となる場合があります。

監視サービスは、サービスが復元されるまで一時的に使用できない場合があります。 管理リージョンで長時間のダウンタイムが発生した場合は、影響を受けるリソースは別の利用可能なリージョンに移行されます。

管理リージョンとサービス リージョンの選択

Azure Communications Gateway の単一のデプロイは、地理的領域内でトラフィックを処理するように設計されています。 運用デプロイの両方のサービス リージョンを同じ地理的領域 (北米など) 内にデプロイします。 このモデルにより、音声通話の待機時間が、Operator Connect および Teams Phone Mobile プログラムで要求される制限内に留まります。

サービス リージョンの場所を選択するときは、次の点を考慮してください。

  • 使用可能な Azure リージョンの一覧から選択します。 サービス リージョンとして選択できる Azure リージョンは、[リージョン別の製品] ページで確認できます。
  • 通話の待ち時間を短縮するために、独自のオンプレミスと、ネットワークと Microsoft の間のピアリングの場所に近いリージョンを選択します。
  • 複数リージョンの停止が発生した場合の復旧時間を最小限に抑えるには、リージョン ペアを使用します。

次の一覧から管理リージョンを選択します。

  • 米国東部
  • 米国中西部
  • 西ヨーロッパ
  • 英国南部
  • インド中部
  • カナダ中部
  • オーストラリア東部

管理リージョンは、サービス リージョンと併置できます。 サービス リージョンに最も近い管理リージョンを選択することをお勧めします。

Note

Azure Operator 通話保護プレビューを有効にしている場合、選択したサービス リージョンは、サポート リソースがデプロイされている Azure リージョンではない可能性があります。 現在サポートされている Azure Operator 通話保護サービスのリージョンの一覧については、「リージョン別の Azure 製品」を参照してください。また、オンボード チームにどのリージョンが選択されているか確認してください。

サービス レベル アグリーメント

このドキュメントで説明する信頼性設計は Microsoft によって実装されており、構成できません。 Azure Communications Gateway サービス レベル アグリーメント (SLA) の詳細については、Azure Communications Gateway の SLA を参照してください。

次のステップ