復旧のための設計
 ワークロードは、ユーザー エクスペリエンスと事業目標の中断を最小限に抑えながら、あらゆる規模の障害のほとんどを予測し、そこから復旧できなければなりません。 |
|---|
回復性の高いシステムでも、アーキテクチャ設計とワークロード操作の両方で災害に備えるアプローチが求められます。 データ層には、破損が発生した場合にワークロードの状態を修復できる戦略が必要です。
サンプル シナリオ
現在オンプレミスの SQL Server データベースで大量のデータをホストしている Contoso は、最近 Azure サービスを使用して、データの分析ソリューションをモダン化しました。
新しい分析ソリューションでは、Azure Analysis Services、Azure Data Factory、Azure Synapse Analytics、Power BI、Azure Virtual Machines が利用されています。 そのソリューションのユーザーはすべて、内部ユーザーです。 ソリューションの可用性の要件を検討した後、チームはそのソリューションを 1 つのリージョンで実装することにしました。
データは Azure Data Factory を使用して取り込まれた後、Analysis Services ストレージに保存される前に処理されます。 プロセスの一部では、クラウド内の VM にデプロイされた従来の Windows プロセスが必要です。
災害に備える
ネゴシエートされた復旧ターゲットと一致する復旧計画を構造化、テスト、文書化しました。 計画では、システム全体に加えて、すべてのコンポーネントをカバーする必要があります。
明確に定義されたプロセスにより迅速な復旧が可能になり、事業の財務と評判への悪影響を防ぐことができます。 復旧訓練を定期的に実施することで、システム コンポーネント、データ、フェールオーバとフェールバックの手順を復旧するプロセスがテストされ、時間とデータ整合性が成功の重要な指標である場合に混乱を回避できます。
Contoso の課題
- ソリューションは内部でのみ使用され、ミッション クリティカルとは見なされていません。 そのため、ワークロード チームとビジネス関係者は、ソリューションがデプロイされている Azure リージョンが万一失われたり、何らかの理由でソリューション全体が使用できなくなったりした場合は、セカンダリ リージョンでソリューションをリビルドすることが復旧モデルとして十分であることに同意しています。
- ワークロード チームは、DR プランの中で別のリージョンでソリューションを構築する方法について説明していますが、完全な DR 訓練を実施する機会はまだありません。
アプローチの適用と結果
- リージョン停止の発生後、DR 対応チームは DR プランの指示に従って、分析ソリューションを別のリージョンに再デプロイできます。
- チームは、ソリューションのデプロイに必要な操作の一部について欠落している部分が DR プランにあることを発見します。そして、のプランは、今後の復旧効率を高めるために更新されます。
- ワークロード チームと関係者は、更新されたプランによって復旧効率が確実に高められることを確認するために、計画された DR テストを迅速化することに同意します。
ステートフル データに対処する
復旧ターゲット内のすべてのステートフル コンポーネントのデータを修復できることを確認します。
信頼できる復旧ポイント (前回の正常起動時の状態など) を使用してシステムを稼働状態に戻すにはバックアップが不可欠です。
トランザクションに一貫性がある不変バックアップにより、データが変更できないこと、および復元されたデータが破損しないことが保証されます。
Contoso の課題
- ワークロード チームは、分析処理時間を短縮するために SQL データベースを Azure に移動することにしました。 データベースの 1 つが VM による分析プロセス中に頻繁に使用されるため、チームはそのデータベースの状態を、可能な限り低い RPO で復旧できるようにする必要があります。
アプローチの適用と結果
- データベースはそれぞれ 4 TB (テラバイト) を超えるため、Azure SQL Database への移行を短期間で行うことはできません。 そこで、チームは SQL Server 2022 が実行されている Azure VM に移行します。
- チームは、クリティカルなデータベースを含むすべてのデータベースに対して、その VM で使用されているデータベースと同じように、自動 Backup 機能を使用することにします。
- クリティカルなデータベースについては、チームは自動 Backup 機能と共に Managed Instance リンク関数を使用して、データベースを Azure SQL Managed Instance にアクティブにレプリケートする予定です。
設計に自己復旧機能を実装する
自己復旧機能は、ワークロードのコンポーネントが問題を自動的に解決できるようにするメカニズムで、影響を受けたコンポーネンがこの機能により復旧し、必要に応じて冗長インフラストラクチャにフェールオーバーします。 設計パターンを使用して、自己復旧メカニズムを介してワークロードに回復性を追加します。
自己復旧の自動化は、ユーザーの介入などの外部要因からのリスクを軽減し、障害対応サイクルを短縮するのに役立ちます。
Contoso の課題
- データの取り込み時に Azure Data Factory から呼び出される Windows プロセスは、可用性を高めるために当初は複数の VM にデプロイされていました。
- レガシ Windows プロセスがクラッシュし、VM の再起動が必要になるケースが何回か発生しました。 全体的な処理時間への影響は最小限に抑えられていますが (冗長性のレベルのため)、チームは障害の検出と復旧を自動化するソリューションを実装したいと考えています。
アプローチの適用と結果
- チームは、Azure Virtual Machine Scale Set ソリューションを実装することにしました。このソリューションは、VM プロセスの正常性を継続的に監視するために、アプリケーション正常性拡張機能をデプロイするように構成されています。
- 自動インスタンス修復が有効の場合、スケール セットによって、VM が再起動されるか、同じイメージに基づいて新しいインスタンスを作成され、コンポーネントを修復できるようになりました。