この記事では、Azure Data Explorerリソース、管理、インジェストをさまざまなAzure リージョンにレプリケートして、Azureリージョンの停止に備える方法について説明します。 この記事には、Azure Event Hubsを使用したデータ インジェストの例が含まれています。 また、さまざまなアーキテクチャ構成のコスト最適化についても説明します。 アーキテクチャに関する考慮事項とリカバリー ソリューションの詳細については、事業継続の概要に関するページを参照してください。
データを保護するために Azure リージョンの停止に備える
Azure Data Explorer では、Azure リージョン全体の停止に対する自動保護はサポートされていません。 この停止は、地震などの自然災害時に発生する可能性があります。 ディザスター リカバリー ソリューションが必要な場合は、次の手順に従ってビジネス継続性を確保します。 これらの手順では、クラスター、管理アクティビティ、データ インジェストを 2 つのAzureペアリージョンにレプリケートします。
- ペアになっている Azure リージョンに複数の独立したクラスターを作成します。
- 新しいテーブルの作成や各クラスターでのユーザー ロールの管理など、すべての管理アクティビティをレプリケートします。
- 各クラスターにデータを並列で取り込みます。
複数の独立したクラスターを作成する
複数のリージョンに Azure Data Explorer クラスターを複数作成します。 これらのクラスターのうち少なくとも 2 つをAzure のペアリージョンに作成します。
次の図は、3 つの異なるリージョンにある 3 つのレプリカ クラスターを示しています。
管理アクティビティをレプリケートする
すべてのレプリカが同じクラスター構成になるように、管理アクティビティをレプリケートします。
各レプリカに同じリソースを作成します。
- データベース: Azure ポータルまたは SDK のいずれかを使用して、新しいデータベースを作成します。
- テーブル
- マッピング
- ポリシー
各レプリカの 認証と承認を管理します。
Event Hubs インジェストを使用したディザスター リカバリー ソリューション
データを保護するためにリージョンAzure停止の準備を完了すると、Azure Data Explorerは複数のリージョンにわたってデータと管理を格納します。 1 つのリージョンで障害が発生した場合、Azure Data Explorerは他のレプリカを使用できます。
Event Hubs を使用してインジェストを設定する
Azure Event Hubs から各リージョンの Azure Data Explorer クラスターにデータを取り込むには、まず、各リージョンに Azure Event Hubs のセットアップをレプリケートします。 次に、各リージョンの Azure Data Explorer レプリカを構成して、対応する Event Hubs からデータを取り込みます。
注
Azure Event Hubs、IoT Hub、またはストレージを使用したインジェストは堅牢です。 クラスターが時間の間使用できない場合は、後でキャッチアップし、保留中のメッセージまたは BLOB を挿入します。 このプロセスは、チェックポイント処理に依存します。
この図は、データ ソースがすべてのリージョンの Event Hubs にイベントを生成し、各Azure Data Explorer レプリカがそれらのイベントを使用することを示しています。 Power BI、Grafana、SDK を利用した Web アプリなどのデータ視覚化コンポーネントは、1 つのレプリカに対してクエリを実行できます。
コストを最適化する
これで、次のいくつかの方法を使用してレプリカを最適化する準備ができました。
オンデマンド データ復旧構成を作成する
Azure Data Explorerセットアップをレプリケートして更新すると、レプリカの数が増えるにつれてコストが線形的に増加します。 コストを最適化するには、時間、フェールオーバー、コストのバランスを取るアーキテクチャバリアントを実装します。 オンデマンド データ復旧構成では、パッシブ Azure Data Explorer レプリカを使用してコストを最適化します。 これらのレプリカは、プライマリ リージョン (たとえば、リージョン A) で災害が発生した場合にのみ有効になります。 リージョン B と C のレプリカを 24 時間 365 日アクティブにする必要はありません。これにより、コストが大幅に削減されます。 ただし、ほとんどの場合、これらのレプリカは実行せず、プライマリ クラスターも実行されません。 詳細については、「オンデマンド データ復旧の構成」を参照してください。
次の図では、Event Hubs からデータを取り込むクラスターは 1 つだけです。 リージョン A のプライマリ クラスターによって、ストレージ アカウントへのすべてのデータの継続的データ エクスポートが行われます。 セカンダリ レプリカは 、外部テーブルを使用してデータにアクセスします。
レプリカを起動および停止する
次のいずれかの方法を使用して、セカンダリ レプリカを開始および停止します。
Azure portal の [概要] タブにある [停止] ボタン。 詳細については、「クラスターを停止して再起動する」を参照してください。
Azure CLI:
az kusto cluster stop --name=<clusterName> --resource-group=<rgName> --subscription=<subscriptionId>
高可用性アプリケーション サービスを実装する
Azure App Service BCDR クライアントを作成する
このセクションでは、1 つのプライマリと複数のセカンダリ Azure Data Explorer クラスターへの接続をサポートする Azure App Service を作成する方法を示します。 下図は、Azure App Service の設定を示しています。
ヒント
同じサービス内のレプリカ間に複数の接続を確立すると、可用性が向上します。 この設定は、リージョン障害が発生した場合だけでなく、それ以外の場合にも役立ちます。
App Service ではこの定型コードを使用します。 マルチクラスター クライアントを実装するには、 AdxBcdrClient クラスを使用します。 このクライアントが実行する各クエリは、 最初にプライマリ クラスターに送信されます。 エラーが発生した場合、クエリはセカンダリ レプリカに送信されます。
カスタム アプリケーション分析情報メトリックを使用してパフォーマンスを測定し、プライマリ クラスターとセカンダリ クラスターへの分散を要求します。
Azure App Service BCDR クライアントをテストする
次のテストでは、複数のAzure Data Explorer レプリカを使用します。 プライマリ クラスターとセカンダリ クラスターのシミュレートされた停止後、App Service BCDR クライアントは意図したとおりに動作します。
Azure Data Explorer クラスターは、西ヨーロッパ (2xD14v2 プライマリ)、東南アジア、および米国東部 (2xD11v2) に分散されています。
注
応答時間が長くなるのは、SKU が異なり、クエリが世界にまたがって実行されるためです。
動的または静的ルーティングを実行する
動的または静的な要求ルーティングには、Azure Traffic Managerルーティング方法を使用します。 Azure Traffic Managerは、App Service トラフィックの分散に使用できる DNS ベースのトラフィック ロード バランサーです。 このトラフィックは世界中の Azure リージョンにまたがるサービスに対して最適化され、同時に高可用性と応答性が提供されます。
Azure Front Door ベースのルーティングを使用することもできます。 これら 2 つの方法の比較については、「Azure のアプリケーション配信スイートでの負荷分散」を参照してください。
アクティブ/アクティブ構成でコストを最適化する
ディザスター リカバリーにアクティブ/アクティブ構成を使用すると、コストが直線的に増加します。 コストには、ノード、ストレージ、マークアップ、および帯域幅の追加のネットワーク コストが含まれます。
最適化された自動スケーリングを使用してコストを最適化する
最適化された自動スケーリング機能を使用して、セカンダリ クラスターの水平スケーリングを構成します。 インジェストの負荷を処理するセカンダリ クラスターのサイズを設定します。 プライマリ クラスターに到達できない場合、セカンダリ クラスターは構成に従ってトラフィックとスケールを増やします。
この例では、最適化された自動スケールにより、すべてのレプリカで同じ水平スケールと垂直スケールを使用する場合と比較して、コストが約 50% 節約されます。