Azure HDInsight のレプリケーション メカニズムは、高可用性ソリューション アーキテクチャに統合できます。 この記事では、Contoso Retail の架空のケース スタディを使用して、高可用性ディザスター リカバリーアプローチ、コストに関する考慮事項、および対応する設計について説明します。
高可用性ディザスター リカバリーの推奨事項には、多くの順列と組み合わせがあります。 これらのソリューションは、各オプションの長所と短所を熟考した後に到着する必要があります。 この記事では、考えられる解決策を 1 つだけ説明します。
顧客アーキテクチャ
次の図は、Contoso Retail のプライマリ アーキテクチャを示しています。 このアーキテクチャは、ストリーミング ワークロード、バッチ ワークロード、サービス レイヤー、従量課金レイヤー、ストレージ 層、バージョン管理で構成されます。
ストリーミング ワークロード
デバイスとセンサーは、メッセージング フレームワークを構成する HDInsight Kafka にデータを生成します。 HDInsight Spark コンシューマーは、Kafka テーマからデータを読み取ります。 Spark は受信メッセージを変換し、サービス レイヤー上の HDInsight HBase クラスターに書き込みます。
バッチ作業負荷
Hive と MapReduce を実行する HDInsight Hadoop クラスターは、オンプレミスのトランザクション システムからデータを取り込みます。 Hive と MapReduce によって変換された生データは、Azure Data Lake Storage Gen2 によってバックアップされたデータ レイクの論理パーティション上の Hive テーブルに格納されます。 Hive テーブルに格納されたデータは Spark SQL でも使用できます。Spark SQL では、提供のためにキュレーションされたデータを HBase に格納する前にバッチ変換が行われます。
サービング レイヤー
Apache Phoenix を使用した HDInsight HBase クラスターは、Web アプリケーションと視覚化ダッシュボードにデータを提供するために使用されます。 HDInsight LLAP クラスターは、内部レポートの要件を満たすために使用されます。
消費レイヤー
Azure API Apps と API Management レイヤーは、公開された Web ページを支えています。 内部レポートの要件は、Power BI によって満たされます。
ストレージ レイヤー
論理的にパーティション分割された Azure Data Lake Storage Gen2 は、エンタープライズ データ レイクとして使用されます。 HDInsight メタストアは、Azure SQL DB によってサポートされています。
バージョン管理システム
Azure Pipelines に統合され、Azure の外部でホストされるバージョン管理システム。
顧客のビジネス継続性の要件
障害が発生した場合に必要な最小限のビジネス機能を決定することが重要です。
Contoso Retail のビジネス継続性の要件
- 地域の障害やサービスの異常から保護する必要があります。
- 顧客に 404 エラーが表示されないようにする必要があります。 パブリック コンテンツは常に提供する必要があります。 (RTO = 0)
- 1 年のほとんどの場合、5 時間古いパブリック コンテンツを表示できます。 (RPO = 5 時間)
- ホリデーシーズン中は、公開コンテンツを常に最新の状態にする必要があります。 (RPO = 0)
- 内部レポートの要件は、ビジネス継続性にとって重要とは見なされません。
- ビジネス継続性コストを最適化します。
提案されたソリューション
次の図は、Contoso Retail の高可用性ディザスター リカバリー アーキテクチャを示しています。
Kafka では 、アクティブ - パッシブ レプリケーションを使用して、プライマリ リージョンからセカンダリ リージョンに Kafka トピックをミラーリングします。 Kafka レプリケーションの代わりに、両方のリージョンで Kafka に対して生成することもできます。
Hive と Spark では、 通常の時間帯 にアクティブ プライマリ - オンデマンド セカンダリ レプリケーション モデルが使用されます。 Hive レプリケーション プロセスは定期的に実行され、Hive Azure SQL メタストアと Hive ストレージ アカウントのレプリケーションに伴います。 Spark ストレージ アカウントは、ADF DistCP を使用して定期的にレプリケートされます。 これらのクラスターの一時的な性質は、コストの最適化に役立ちます。 レプリケーションは、5 時間の要件を十分に満たしている RPO に到着するように 4 時間ごとにスケジュールされます。
HBase レプリケーションでは、通常の時間帯に Leader – Follower モデルを使用して、リージョンに関係なくデータが常に提供され、RPO が非常に低いことが保証されます。
プライマリ リージョンでリージョンの障害が発生した場合、Web ページとバックエンド コンテンツはセカンダリ リージョンから 5 時間、ある程度の制約を伴って提供されます。 Azure サービス正常性ダッシュボードで 5 時間のウィンドウに復旧 ETA が示されていない場合、Contoso Retail はセカンダリ リージョンに Hive および Spark 変換レイヤーを作成し、すべてのアップストリーム データ ソースをセカンダリ リージョンにポイントします。 セカンダリ リージョンを書き込み可能にすると、プライマリへのレプリケーションを伴うフェールバック プロセスが発生します。
ショッピング シーズンのピーク時には、セカンダリ パイプライン全体が常にアクティブになり、実行されます。 Kafka プロデューサーによって、両方のリージョンに対する生成が行われ、HBase レプリケーションはリーダー/フォロワーからリーダー/リーダーに変更され、パブリックに公開されているコンテンツが常に最新の状態になります。
フェールオーバー ソリューションは、ビジネス継続性にとって重要ではないため、内部レポート用に設計する必要はありません。
次のステップ
この記事で説明した項目の詳細については、次を参照してください。