事業継続とディザスター リカバリーの概要
Azure Data Explorer における事業継続とディザスター リカバリーにより、中断が発生しても業務を継続できます。 この記事では、可用性 (リージョン内) とディザスター リカバリーについて説明します。 回復性がある Azure Data Explorer のデプロイのためのネイティブな機能とアーキテクチャに関する考慮事項について説明します。 人的エラーからの復旧、高可用性、およびディザスター リカバリーの複数の構成について詳しく説明します。 これらの構成は、目標復旧時点 (RPO) と目標復旧時間 (RTO)、必要な労力、コストなど、回復性の要件によって異なります。
破壊的イベントを軽減する
人的エラー
人的エラーを避けることはできません。 ユーザーは、クラスター、データベース、またはテーブルを誤って削除することがあります。
クラスターまたはデータベースの誤った削除
クラスターまたはデータベースの誤った削除は復旧不可能な操作です。 Azure Data Explorer リソースの所有者は、Azure リソース レベルで利用可能な削除ロック機能を有効にすることで、データの損失を防ぐことができます。
テーブルの誤った削除
テーブル管理者以上のアクセス許可を持つユーザーは、テーブルを削除することができます。 そのようなユーザーの 1 人が誤ってテーブルを削除した場合は、.undo drop table コマンドを使用してそのテーブルを復旧できます。 このコマンドを正常に実行するには、最初にアイテム保持ポリシーの "回復性" プロパティを有効にする必要があります。
外部テーブルの誤った削除
外部テーブルは、データベースの外部に格納されているデータを参照する Kusto スキーマ エンティティです。 外部テーブルを削除すると、テーブルのメタデータのみが削除されます。 テーブル作成コマンドを再実行することにより、それを復旧できます。 ユーザーが構成した時間だけ、ファイルまたは BLOB の誤った削除または上書きを防ぐには、論理的な削除機能を使用します。
Azure Data Explorer の高可用性
高可用性とは、Azure Data Explorer、そのコンポーネント、および Azure リージョン内の基になる依存関係のフォールト トレランスのことです。 このフォールト トレランスにより、実装における単一障害点 (SPOF) が回避されます。 Azure Data Explorer の高可用性には、永続レイヤー、コンピューティング レイヤー、リーダー フォロワー構成が含まれます。
永続レイヤー
Azure Data Explorer では、Azure Storage が持続的な永続レイヤーとして利用されます。 Azure Storage では、データ センター内でのローカル冗長ストレージ (LRS) を実現する既定の設定により、フォールト トレランスが自動的に提供されます。 3 つのレプリカが保持されます。 使用中に 1 つのレプリカが失われた場合は、中断なく別のものがデプロイされます。 追加コストはかかりますが、最大限のフォールト トレランスのために Azure リージョンの可用性ゾーンにレプリカがインテリジェントに配置されるゾーン冗長ストレージ (ZRS) を使用することで、回復性がさらに向上します。 Azure Data Explorer クラスターが Availability Zones にデプロイされると、ZRS 対応ストレージが自動的に構成されます。
コンピューティング レイヤー
Azure Data Explorer は分散コンピューティング プラットフォームであり、スケールとノード ロールの種類に応じて、2 つ以上のノードを持つことができます。 プロビジョニング時に、複数の可用性ゾーンを選択し、リージョン内の回復性が最大になるようにゾーン間にノードのデプロイを分散させます。 可用性ゾーンで障害が発生すると、完全に停止するのではなく、ゾーンが復旧するまでパフォーマンスが低下します。
リーダー フォロワー クラスター構成
Azure Data Explorer には、リーダーのデータとメタデータに対する読み取り専用アクセスのために、リーダー クラスターが他のフォロワー クラスターによってフォローされる、オプションのフォロワー機能が用意されています。 リーダーでの変更 (create、append、drop など) は、フォロワーに自動的に同期されます。 リーダーは複数の Azure リージョンにまたがることができますが、フォロワー クラスターはリーダーと同じリージョンでホストされている必要があります。 リーダー クラスターがダウンした場合、またはデータベースやテーブルが誤って削除された場合は、リーダーでアクセスが復旧されるまで、フォロワー クラスターはアクセスできなくなります。
Azure 可用性ゾーンの停止
Azure 可用性ゾーンは、同じ Azure リージョン内の一意の物理的な場所です。 部分的なリージョンの障害から Azure Data Explorer クラスターのコンピューティングとデータを保護できます。 ゾーンの障害は、リージョン内であるため可用性のシナリオです。
Azure Data Explorer クラスターを、接続されている他の Azure リソースと同じゾーンにピン留めします。 可用性ゾーンの有効化の詳細については、「クラスターの作成」を参照してください。
Note
可用性ゾーンへのデプロイは、クラスターの作成時に可能です。また、 後で移行することもできます。
Azure データセンターの停止
Azure 可用性ゾーンにはコストがかかります。また、一部のお客様は、ゾーン冗長を使用せずにデプロイすることを選択します。 そのような Azure Data Explorer のデプロイでは、Azure データセンターが停止するとクラスターが停止します。 そのため、Azure データセンターの停止を処理することは、Azure リージョンの停止を処理することと同じです。
Azure リージョンの停止
Azure Data Explorer では、Azure リージョン全体の停止に対する自動保護は提供されていません。 そのような障害が発生した場合の事業への影響を最小限に抑えるため、複数の Azure Data Explorer クラスターが Azure のペアになっているリージョンにまたがっています。 目標復旧時間 (RTO)、目標復旧時点 (RPO) (RPO)、労力とコストに関する考慮事項に基づいて、複数のディザスター リカバリー構成があります。 コストとパフォーマンスの最適化は、Azure Advisor の推奨事項と自動スケーリングの構成で実現できます。
ディザスター リカバリーの構成
このセクションでは、回復性の要件 (RPO と RTO)、必要な作業、コストに応じた、複数のディザスター リカバリー構成について詳しく説明します。
目標復旧時間 (RTO) とは、中断から復旧するまでの時間を指します。 たとえば、RTO が 2 時間の場合は、中断から 2 時間以内にアプリケーションを稼働させる必要があることを意味します。 目標復旧時点 (RPO) とは、その間に失われるデータ量が許容されるしきい値以下である中断時間の長さのことです。 たとえば、RPO が 24 時間で、アプリケーションに 15 年前からのデータが含まれている場合は、合意された RPO のパラメーター内にまだ収まっています。
ディザスター リカバリーを計画するときは、インジェスト、処理、キュレーションを事前に入念に設計する必要があります。 インジェストとは、さまざまなソースから Azure Data Explorer に統合されたデータを指します。処理とは、変換および同様のアクティビティを指します。キュレーションとは、具体化されたビュー、データ レイクへのエクスポートなどのことです。
次に示すのは一般的なディザスター リカバリー構成であり、それぞれについて以下で詳しく説明します。
アクティブ/アクティブ/アクティブ構成
この構成は "Always On" とも呼ばれます。 停止が許容されない重要なアプリケーションのデプロイでは、Azure のペアになったリージョンの間で複数の Azure Data Explorer クラスターを使用する必要があります。 すべてのクラスターに対して並列に、インジェスト、処理、キュレーションを設定します。 クラスター SKU は、リージョン間で同じである必要があります。 Azure により、Azure のペアになったリージョン間で更新プログラムが確実にロールアウトされ、時間をずらして調整されます。 1 つの Azure リージョンが停止しても、アプリケーションが停止することはありません。 若干の遅延またはパフォーマンスの低下が発生する可能性があります。
| 構成 | RPO | RTO | 作業 | コスト |
|---|---|---|---|---|
| アクティブ/アクティブ/アクティブ/n | 0 時間 | 0 時間 | 低 | 最高 |
アクティブ/アクティブ構成
この構成はアクティブ/アクティブ/アクティブ構成と同じですが、Azure のペアになった 2 つのリージョンだけが関係します。 デュアル インジェスト、処理、およびキュレーションを構成します。 ユーザーは最も近いリージョンにルーティングされます。 クラスター SKU は、リージョン間で同じである必要があります。
| 構成 | RPO | RTO | 作業 | コスト |
|---|---|---|---|---|
| アクティブ/アクティブ | 0 時間 | 0 時間 | 低 | 高 |
アクティブ/ホット スタンバイ構成
アクティブ/ホット構成は、デュアル インジェスト、処理、キュレーションのアクティブ/アクティブ構成に似ています。 スタンバイ クラスターはインジェスト、プロセス、キュレーションのためにオンラインですが、クエリを実行することはできません。 スタンバイ クラスターは、プライマリ クラスターと同じ SKU 内にある必要はありません。 SKU とスケールが小さくなり、パフォーマンスが低下する可能性があります。 ディザスター シナリオでは、ユーザーはスタンバイ クラスターにリダイレクトされ、必要に応じてスケールアップしてパフォーマンスを向上させることができます。
| 構成 | RPO | RTO | 作業 | コスト |
|---|---|---|---|---|
| アクティブ/ホット スタンバイ | 0 時間 | 低 | Medium | Medium |
オンデマンド データ復旧構成
このソリューションでは、最低限の回復性 (最も高い RPO と RTO) が提供され、コストが最も低く、労力が最も高くなります。 この構成では、データ復旧クラスターはありません。 GRS (geo 冗長ストレージ) が構成されているストレージ アカウントへのキュレートされたデータの連続エクスポートを構成します (生データと中間データも必要な場合を除く)。 ディザスター リカバリー シナリオがある場合は、データ復旧クラスターがスピンアップされます。 その時点で、DDL、構成、ポリシー、プロセスが適用されます。 データはインジェスト プロパティ kustoCreationTime を使用してストレージから取り込まれ、既定でシステム時刻に設定されているインジェスト時間がオーバーライドされます。
| 構成 | RPO | RTO | 作業 | コスト |
|---|---|---|---|---|
| オンデマンド データ復旧クラスター | 最高 | 最高 | 最高 | 最低 |
ディザスター リカバリー構成オプションの概要
| 構成 | 回復性 | RPO | RTO | 作業 | コスト |
|---|---|---|---|---|---|
| アクティブ/アクティブ/アクティブ/n | 最高 | 0 時間 | 0 時間 | 低 | 最高 |
| アクティブ/アクティブ | 高 | 0 時間 | 0 時間 | 低 | 高 |
| アクティブ/ホット スタンバイ | 中間 | 0 時間 | 低 | Medium | Medium |
| オンデマンド データ復旧クラスター | 最低 | 最高 | 最高 | 最高 | 最低 |
ベスト プラクティス
選択されたディザスター リカバリー構成にかかわらず、次のベスト プラクティスに従ってください。
- すべてのデータベース オブジェクト、ポリシー、構成をソース管理に保持して、リリース自動化ツールからクラスターにリリースできるようにする必要があります。 詳細については、Azure Data Explorer Flow に対する Azure DevOps のサポートに関する記事を参照してください。
- 検証ルーチンを設計、開発、実装し、すべてのクラスターがデータの観点から確実に同期されるようにします。 Azure Data Explorer では、クロス クラスター結合がサポートされています。 テーブル全体の単純なカウントまたは行は、検証に役立ちます。
- リリース手順には、クラスターのミラーリングを保証するガバナンスのチェックとバランスを含める必要があります。
- 最初からクラスターを構築するために必要なものを完全に理解します。
- デプロイ ユニットのチェックリストを作成します。 リストはニーズに固有ですが、デプロイ スクリプト、インジェスト接続、BI ツール、その他の重要な構成が含まれている必要があります。
次のステップ
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示