Azure Data Explorerでのビジネス継続性とディザスター リカバリーにより、中断が発生した場合でもビジネスを継続できます。 この記事では、回復性の要件 (RPO と RTO)、必要な作業、コストに応じて、複数のディザスター リカバリー構成について詳しく説明します。
可用性ゾーンのサポート、バックアップ、一部の種類のヒューマン エラーに対する保護など、Azure Data Explorerで使用できる信頼性オプションの詳細については、「reliability in Azure Data Explorer」を参照してください。
ディザスター リカバリーの構成
目標復旧時間 (RTO) とは、中断から復旧するまでの時間を指します。 たとえば、RTO が 2 時間の場合は、中断から 2 時間以内にアプリケーションを稼働させる必要があることを意味します。 目標復旧時点 (RPO) とは、その間に失われるデータ量が許容されるしきい値以下である中断時間の長さのことです。 たとえば、RPO が 24 時間で、アプリケーションに 15 年前からのデータが含まれている場合は、合意された RPO のパラメーター内にまだ収まっています。
ディザスター リカバリーを計画するときは、インジェスト、処理、キュレーションを事前に入念に設計する必要があります。 インジェストとは、さまざまなソースからAzure Data Explorerに統合されたデータを指します。処理とは、変換と同様のアクティビティを指します。キュレーションとは、具体化されたビュー、データ レイクへのエクスポートなどを指します。
一般的なディザスター リカバリー構成を次に示します。
アクティブ-アクティブ-アクティブ構成
この構成は、 常時オンとも呼ばれます。 障害に対する許容度のない重要なアプリケーションデプロイの場合は、ペアになっているリージョン間で複数のAzure Data Explorer クラスター Azure使用する必要があります。 すべてのクラスターに対して並列に、インジェスト、処理、キュレーションを設定します。 クラスター SKU は、リージョン間で同じである必要があります。 Azureにより、更新プログラムが Azure のペアリージョン間でロールアウトされ、順次配布されます。 Azure リージョンの停止は、アプリケーションの停止を引き起こしません。 待機時間やパフォーマンスの低下が発生する可能性があります。
| Configuration | RPO | RTO | 努力 | 原価 |
|---|---|---|---|---|
| アクティブ/アクティブ/アクティブ/n | 0 時間 | 0 時間 | 下げる | 最高 |
アクティブ/アクティブ構成
この構成は、active-active-active 構成と同じですが、2 つのAzureペアのリージョンのみが含まれます。 二重インジェスト、処理、およびキュレーションを設定します。 ユーザーは最も近いリージョンにルーティングされます。 クラスター SKU は、リージョン間で同じである必要があります。
| Configuration | RPO | RTO | 努力 | 原価 |
|---|---|---|---|---|
| アクティブ-アクティブ | 0 時間 | 0 時間 | 下げる | 高 |
アクティブ/ホット スタンバイ構成
アクティブ/ホット構成は、デュアル インジェスト、処理、キュレーションのアクティブ/アクティブ構成に似ています。 スタンバイ クラスターはインジェスト、プロセス、キュレーションのためにオンラインですが、クエリを実行することはできません。 スタンバイ クラスターは、プライマリ クラスターと同じ SKU に存在する必要はありません。 SKU とスケールが小さくなり、パフォーマンスが低下する可能性があります。 障害シナリオでは、ユーザーはスタンバイ クラスターにリダイレクトされ、必要に応じてスケールアップしてパフォーマンスを向上させることができます。
| Configuration | RPO | RTO | 努力 | 原価 |
|---|---|---|---|---|
| アクティブホットスタンバイ | 0 時間 | 低 | 中 | 中 |
オンデマンド データ復旧構成
このソリューションでは、最も回復性が低く (RPO と RTO が最も高い)、コストが最も低く、労力が最も高くなります。 この構成では、データ復旧クラスターはありません。 GRS (geo 冗長ストレージ) が構成されているストレージ アカウントへのキュレートされたデータの連続エクスポートを構成します (生データと中間データも必要な場合を除く)。 ディザスター リカバリー シナリオがある場合、データ復旧クラスターはスピンアップされます。 その時点で、DDL、構成、ポリシー、プロセスが適用されます。 データは、インジェスト プロパティ kustoCreationTime を使用してストレージから取り込み、既定でシステム時刻に設定されているインジェスト時間をオーバーライドします。
| Configuration | RPO | RTO | 努力 | 原価 |
|---|---|---|---|---|
| オンデマンド データ復旧クラスター | 最高 | 最高 | 最高 | 最低 |
ディザスター リカバリー構成オプションの概要
| Configuration | 回復 | RPO | RTO | 努力 | 原価 |
|---|---|---|---|---|---|
| アクティブ/アクティブ/アクティブ/n | 最高 | 0 時間 | 0 時間 | 下げる | 最高 |
| アクティブ-アクティブ | 高 | 0 時間 | 0 時間 | 下げる | 高 |
| アクティブホットスタンバイ | 中 | 0 時間 | 低 | 中 | 中 |
| オンデマンド データ復旧クラスター | 最低 | 最高 | 最高 | 最高 | 最低 |
ベスト プラクティス
選択されたディザスター リカバリー構成にかかわらず、次のベスト プラクティスに従ってください。
- すべてのデータベース オブジェクト、ポリシー、構成をソース管理に保持して、リリース自動化ツールからクラスターにリリースできるようにする必要があります。 詳細については、
Azure DevOps Azure Data Explorer を参照してください。 - 検証ルーチンを設計、開発、実装し、すべてのクラスターがデータの観点から確実に同期されるようにします。 Azure Data Explorerでは、クロス クラスター結合がサポートされます。 テーブル全体の単純なカウントまたは行は、検証に役立ちます。
- リリース手順には、クラスターのミラーリングを保証するガバナンスのチェックとバランスを含める必要があります。
- 最初からクラスターを構築するために必要なものを完全に理解します。
- デプロイ ユニットのチェックリストを作成します。 リストはニーズに固有ですが、デプロイ スクリプト、インジェスト接続、BI ツール、その他の重要な構成を含める必要があります。