Azure パブリック マルチアクセス エッジ コンピューティング (MEC) は、エッジでアプリケーションをホストするための優れたプラットフォームであり、アプリケーションの応答性を向上させることができますが、現在は高可用性機能をサポートしていません。 この記事では、高可用性とディザスター リカバリーを実現するために、ワークロードをアクティブ/スタンバイ モードでデプロイする方法について説明します。
Apache®、Apache Ignite、Ignite、および炎のロゴは、Apache Software Foundation の米国およびその他の国における登録商標です。 これらのマークを使用することが、Apache Software Foundation による保証を意味するものではありません。
アーキテクチャ
このアーキテクチャの Visio ファイルをダウンロードします。
ワークフロー
Azure Traffic Manager。 優先順位によるルーティングを使うように Traffic Manager を構成します。 Azure パブリック MEC (プライマリ) のロード バランサーの IP アドレスを 優先度 1 に設定します。 セカンダリ リージョンでは 優先度 2 に設定します。 この構成では、フェールオーバーしない場合のすべてのトラフィックを Azure パブリック MEC に送信します。
注意
Azure パブリック MEC の Traffic Manager では、現在、パフォーマンスによるルーティングがサポートされていません。これにより、エンドポイントに対する最短の待機時間に基づいて、前述のルーティングを動的に判別できます。
このアーキテクチャでは、仮想マシン (VM) や標準ロード バランサーがオンラインに戻ると、フェールバックが自動的に実行されます。 Traffic Manager は、ワークロードが稼働していることを判別し、プライマリ Azure パブリック MEC リージョンへのトラフィックを再ルーティングします。
パブリック ロード バランサー。 このロード バランサーは、アプリケーション層に面し、仮想マシン スケール セット内の VM のプールへのトラフィックを分散します。
内部ロード バランサー。 このロード バランサーは、データベース層へのアクセスに使用されます。 アプリケーションに使用するデータベースの種類によっては、他の PaaS (サービスとしてのプラットフォーム) サービスに独自のロード バランサーがあることを前提とすると、ここではロード バランサーが必要ない場合があります。
Azure 仮想マシン スケール セット。 ほとんどの運用環境のデプロイでは、仮想マシン スケール セットを使用して、トラフィックの負荷に基づいてワークロードを動的にスケーリングします。 Azure パブリック MEC は、クラウドネイティブ アプリケーションとコンテナーベースのアプリケーションに対して Azure Kubernetes Service もサポートします。
データベース層。 Azure パブリック MEC は、現在、Azure Virtual Machines における SQL Server や Azure SQL Managed Instance などの SQL データベース PaaS サービスをサポートしていません。 また、Azure Cosmos DB や Azure Managed Instance for Apache Cassandra などの NoSQL PaaS サービスも現在サポートしていません。 地理的に分散されたクラスター全体で SQL または NoSQL のサービスやデータのレプリケーションをサポートするサードパーティ ソリューションをデプロイできます。
コンポーネント
- Azure パブリック MEC は、Microsoft コンピューティング、ネットワーク、アプリケーション サービスを 1 つのポートフォリオにまとめてクラウドから管理できるようにするエッジ コンピューティング ソリューションです。
- Azure Traffic Manager は、DNS ベースのトラフィック ロード バランサーです。 これを使用すると、選択したルーティング方法に基づいて受信 DNS 要求を送信できます。
- Azure Load Balancer は、アプリの高可用性と高パフォーマンスを提供します。
- Azure Virtual Machine Scale Sets を使用すると、数千の VM を管理し、スケールアップすることができます。
代替
Azure Site Recovery とバックアップ機能を提供する、Azure のバックアップとディザスター リカバリー。
- VM を Azure パブリック MEC から親リージョンにアクティブにレプリケートし、障害が発生した場合にフェールオーバーとフェールバックが可能になります。
- VM をバックアップして、データの破損や損失を防ぎます。
この方法は、アイドル状態のリソースがないため、前述のものよりもコストが小さくなります。 この代替方法は、より高い RTO を可能にするアプリケーションにのみ適しています。
注意
Azure パブリック MEC 用の Azure バックアップとディザスター リカバリーでは現在、仮想マシンのみがサポートされます。
シナリオの詳細
考えられるユース ケース
高可用性とディザスター リカバリーを実現するためにワークロードをアクティブ/スタンバイ モードでデプロイする必要がある場合、このアーキテクチャを使用します。 このシナリオは、電気通信業界に最適です。
考慮事項
以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。
SLA
Microsoft は、Azure や Azure リージョンなどの大規模なインフラストラクチャに対してサービス レベル アグリーメント (SLA) をサポートしています。 Azure パブリック MEC では、Azure の占有領域拡張機能が小さいため、SLA はサポートされません。
パフォーマンス
Azure パブリック MEC は、待機時間が重要なアプリケーションをホストするように設計されています。 セカンダリ リージョンへのフェールオーバーによってワークロードの待機時間が長くなるため、同じレベルのパフォーマンスが得られない場合があります。 アプリケーションと、この待機時間の増加に対するアプリケーションの感度に応じて、どのサービスがリージョンにフェールオーバーするかを決定する必要があります。
データベース
データベースのフェールオーバーに依存する場合は、データのレプリケーションとバックアップが重要です。 ほとんどの Azure PaaS サービスには、geo レプリケーションと、リージョンと地域間での読み取りレプリカの作成に対するサポートが組み込まれています。
注意
Azure パブリック MEC は現在、SQL Managed Instance、Azure Virtual Machines における SQL Server、Azure Database for MySQL、Azure Database for PostgreSQL のような PaaS サービスをサポートしていません。 Couchbase、MongoDB、Apache Cassandra などのサードパーティ製品は、geo レプリケーションをサポートする IaaS (サービスとしてのインフラストラクチャ) サービスを提供できます。
Traffic Manager
フェールオーバーのオプション
Traffic Manager では、パフォーマンス、地理的、優先順位など、複数のルーティング方法がサポートされています。 低待機時間アプリケーションを最適にサポートするには、ユーザーに最も近いリージョン/Azure パブリック MEC にデータを動的に送信します。 現時点では、パフォーマンスによるルーティングは Azure パブリック MEC ではサポートされていません。 次に最適なオプションは、アプリケーションの最適な場所に静的に優先順位を付けることです。
複数の Azure パブリック MEC とリージョン全体にワークロードが分散されているグローバル分散型のアプリケーションの場合、入れ子になったルーティング方法を使用します。 地理的なルーティングを使用してトラフィックを適切なリージョンに分割してから、優先順位によるルーティングを使用してトラフィックをさらに分割します。
フェールバック
Azure パブリック MEC のワークロードがバックアップされた後、Traffic Manager のプローブは、要求を取得し、トラフィックを Azure パブリック MEC に自動的に再ルーティングできることを検出します。
コストの最適化
コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。
Azure パブリック MEC は主に、低待機時間とリアルタイム計算のシナリオに使用されます。 データは、Azure パブリック MEC で実行されるコンピューティング インスタンスによって処理されます。 このアーキテクチャでは、ホット スタンバイでアクティブ/スタンバイを使用します。 つまり、フェールオーバーが発生しない限り、セカンダリ リージョンのワークロードは使用されません。
ワークロードが使用されていない場合でも、スタンバイとしてワークロードをデプロイするこの方法では、Azure のデプロイ コストが発生します。
価格の詳細については、次のようにしてください。
- 「Azure の価格」を参照してください。
- このソリューションの実装コストを見積もるには、Azure 料金計算ツールを使用します。
コスト効果の高いワークロードの作成については、Azure Well-Architected Framework のドキュメントの「コストの最適化の柱の概要」を参照してください。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパル作成者:
- Adhip Gupta | シニア プログラム マネージャー