事業継続とディザスター リカバリーの概要

Azure Data Explorer における事業継続とディザスター リカバリーにより、中断が発生しても業務を継続できます。 この記事では、可用性 (リージョン内) とディザスター リカバリーについて説明します。 回復性がある Azure Data Explorer のデプロイのためのネイティブな機能とアーキテクチャに関する考慮事項について説明します。 人的エラーからの復旧、高可用性、およびディザスター リカバリーの複数の構成について詳しく説明します。 これらの構成は、目標復旧時点 (RPO) と目標復旧時間 (RTO)、必要な労力、コストなど、回復性の要件によって異なります。

破壊的イベントを軽減する

• 人的エラー
• Azure Data Explorer の高可用性
• Azure 可用性ゾーンの停止
• Azure データセンターの停止
• Azure リージョンの停止

人的エラー

人的エラーを避けることはできません。 ユーザーは、クラスター、データベース、またはテーブルを誤って削除することがあります。

クラスターまたはデータベースの誤った削除

クラスターまたはデータベースの誤った削除は復旧不可能な操作です。 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 リソースと同じゾーンにピン留めします。 可用性ゾーンの有効化の詳細については、「クラスターの作成」を参照してください。

Azure データセンターの停止

Azure 可用性ゾーンにはコストがかかります。また、一部のお客様は、ゾーン冗長を使用せずにデプロイすることを選択します。 このような Azure Data Explorer のデプロイでは、Azure データセンターが停止すると、クラスターが停止します。 そのため、Azure データセンターの停止を処理することは、Azure リージョンの停止を処理することと同じです。

Azure リージョンの停止

Azure Data Explorer では、Azure リージョン全体の停止に対する自動保護は提供されていません。 このような障害が発生した場合のビジネスへの影響を最小限に抑えるために、 Azure のペアになっているリージョン間で複数の Azure Data Explorer クラスターを使用します。 目標復旧時間 (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 のペアになっているリージョン間で更新プログラムがロールアウトされ、分散されます。 Azure リージョンの停止では、アプリケーションの停止は発生しません。 待機時間やパフォーマンスの低下が発生する可能性があります。

アクティブ/アクティブ構成

この構成はアクティブ/アクティブ/アクティブ構成と同じですが、Azure のペアになった 2 つのリージョンだけが関係します。 デュアル インジェスト、処理、およびキュレーションを構成します。 ユーザーは最も近いリージョンにルーティングされます。 クラスター SKU は、リージョン間で同じである必要があります。

アクティブ/ホット スタンバイ構成

アクティブ/ホット構成は、デュアル インジェスト、処理、キュレーションのアクティブ/アクティブ構成に似ています。 スタンバイ クラスターはインジェスト、プロセス、キュレーションのためにオンラインですが、クエリを実行することはできません。 スタンバイ クラスターは、プライマリ クラスターと同じ SKU に存在する必要はありません。 SKU とスケールが小さくなり、パフォーマンスが低下する可能性があります。 障害シナリオでは、ユーザーはスタンバイ クラスターにリダイレクトされ、必要に応じてスケールアップしてパフォーマンスを向上させることができます。

オンデマンド データ復旧構成

このソリューションでは、最低限の回復性 (最も高い RPO と RTO) が提供され、コストが最も低く、労力が最も高くなります。 この構成では、データ復旧クラスターはありません。 GRS (geo 冗長ストレージ) が構成されているストレージ アカウントへのキュレートされたデータの連続エクスポートを構成します (生データと中間データも必要な場合を除く)。 ディザスター リカバリー シナリオがある場合、データ復旧クラスターはスピンアップされます。 その時点で、DDL、構成、ポリシー、プロセスが適用されます。 データは、インジェスト プロパティ kustoCreationTime を使用してストレージから取り込み、既定でシステム時刻に設定されているインジェスト時間をオーバーライドします。

ディザスター リカバリー構成オプションの概要

ベスト プラクティス

選択されたディザスター リカバリー構成にかかわらず、次のベスト プラクティスに従ってください。

• すべてのデータベース オブジェクト、ポリシー、構成をソース管理に保持して、リリース自動化ツールからクラスターにリリースできるようにする必要があります。 詳細については、Azure Data Explorer Flow に対する Azure DevOps のサポートに関する記事を参照してください。
• 検証ルーチンを設計、開発、実装し、すべてのクラスターがデータの観点から確実に同期されるようにします。 Azure Data Explorer では、クロス クラスター結合がサポートされています。 テーブル全体の単純なカウントまたは行は、検証に役立ちます。
• リリース手順には、クラスターのミラーリングを保証するガバナンスのチェックとバランスを含める必要があります。
• 最初からクラスターを構築するために必要なものを完全に理解します。
• デプロイ ユニットのチェックリストを作成します。 リストはニーズに固有ですが、デプロイ スクリプト、インジェスト接続、BI ツール、その他の重要な構成を含める必要があります。

次のステップ