クラウド戦略の回復性に関する考慮事項
回復性は、中断や障害にもかかわらず機能と可用性を維持するインフラストラクチャの機能です。 これは、成功したクラウド導入戦略の基礎となります。 中断の影響を最小限に抑えるために、回復性を念頭に置いてクラウド インフラストラクチャを設計します。 これを行うと、ビジネス運用の継続性と信頼性を維持するのに役立ちます。
ビジネスがテクノロジと緊密に統合されているほど、そのテクノロジの回復性がより重要であると考えてください。
システムが重要なプロセスをサポートしている場合、または業務に不可欠な場合、ダウンタイムが発生すると、大幅な財務損失、リソースの消費、またはビジネス アクティビティの完全な停止につながる可能性があります。
予期しない問題を計画する
ダウンタイムが著しい財務上の損失や評判の低下につながる可能性がある現代の状況では、多くの組織にとって回復性が必要です。 自然災害、サイバー攻撃、システム障害のいずれが原因であっても、中断はいつでも予期せず発生する可能性があります。
回復性とは、クラウド インフラストラクチャとアプリケーションが、これらの課題に対処し、ダウンタイムを最小限に抑え、サービスとデータの整合性を維持するのに十分な堅牢性を確保することです。
通常、ビジネスのすべてのシステムで同じレベルの回復性が必要なわけではありません。 最も重要な回復性投資に集中できるように、ビジネス内の回復性レベルの柔軟性を許可することを検討できます。
回復性により、予期しない状況が発生しても重要なアプリケーションとサービスを確実に利用できるようにすることで、組織はビジネス継続性を維持し、規制要件を満たし、顧客の信頼を高めることができます。
共有責任モデルを理解する
回復性は、クラウド プロバイダーとその顧客の共同責任です。
共有責任モデルでは、責任の分割を定義し、コア クラウド インフラストラクチャなど、プロバイダーが管理する内容と、アプリケーションとデータのセキュリティと構成など、顧客が何を担当するかの境界を確立します。
クラウド導入戦略では、セキュリティ、コンプライアンス、信頼性を維持する際の自分の役割を確実に理解できるため、共有責任の文書化と理解が重要です。 共有責任モデルを戦略に組み込むことで、潜在的なリスクに積極的に対処し、適切なガバナンスを確保し、組織の目標と規制要件に合ったより堅牢なクラウド環境を構築できます。
Azure でのシステムの信頼性の確保は、お客様とクラウド プロバイダーの間で共有される責任です。 Microsoft は、クラウド プラットフォーム の信頼性を管理します。一方、顧客とパートナーは、クラウド アプリケーションとインフラストラクチャのデプロイ の信頼性を担当。
クラウド導入戦略を強化する
回復性をクラウド導入戦略に統合することで、競争力として品質管理が実現します。 回復性を備えたアーキテクチャを設計することで、ハードウェアやネットワークの問題、データセンターやクラウド リージョン全体の損失など、さまざまな状況でアプリケーションやビジネスが確実に動作することを確認できます。 この戦略的な焦点により、より効果的なリソース割り当て、運用効率の向上、リスク管理の向上が可能になります。
また、堅牢なセキュリティとコンプライアンス体制を維持しながら、組織が市場の需要に迅速に適応できるようにすることで、サービスのアジャイル展開を容易にすることもできます。
最終的に、回復性は、品質とイノベーションを促進し、長期的なビジネス目標をサポートするため、クラウド導入戦略の不可欠な要素です。
回復性シナリオの例
特定の種類のリスク シナリオにマップされた、クラウド導入戦略における回復性の重要性のいくつかの例を次に示します。
| リスク シナリオ | リスクへの影響 | 回復性の軽減策の例 |
|---|---|---|
| サイバー攻撃 | ランサムウェア、分散型サービス拒否 (DDoS)、または未承認のアクセス。 | 影響を軽減するには、導入戦略と計画に、適切なバックアップと復旧プロセスを含む堅牢なセキュリティ対策を含めます。 |
| システム障害 | ハードウェアまたはソフトウェアの誤動作。 | 迅速な回復とデータ整合性の復元のための設計。 アプリケーションの一時的な障害を処理し、自動フェールオーバーを使用する複数のレプリカなど、インフラストラクチャで冗長性を提供します。 |
| 構成の問題 | デプロイ エラーまたは構成ミス。 | コードとしてのインフラストラクチャ (IaC) を使用して、構成の変更をコードの変更として扱います。 継続的インテグレーション/継続的デプロイ (CI/CD) パイプライン、カナリア デプロイ、ロールバック メカニズムを使用して、障害のある更新プログラムやデプロイの影響を最小限に抑えます。 |
| 需要の急増または過負荷 | ピーク時のパフォーマンスの低下またはトラフィックの急増。 | 柔軟なスケーラビリティを使用して、サービスを中断することなく需要の増加に対応するようにシステムを自動的にスケーリングします。 |
| コンプライアンス不備 | 規制基準の違反。 | Microsoft Purview などのコンプライアンス ツールを採用し、Azure Policy を使用してコンプライアンス要件を適用します。 |
| 自然災害 | 地震、洪水、または嵐によるデータセンターの停止。 | 可用性ゾーン、複数のリージョン、さらにはマルチクラウド アプローチを使用して、フェールオーバー、高可用性、ディザスター リカバリーを計画します。 |
推奨 事項
これらの推奨事項に従って、回復性に関する考慮事項をクラウド導入戦略に通知します。
ビジネス影響分析 (BIA)を実行する: リソースと復旧作業の優先順位付けに役立つさまざまなシステムとアプリケーションの重要度を定義します。 クラウド導入全体でこの分析を繰り返し実行します。
リスク評価を実行する: クラウド インフラストラクチャに影響を与える可能性がある潜在的な脅威と脆弱性を特定し、それらを使用して軽減戦略を構築し、回復性と信頼性の計画を通知します。
コストメリット分析のを完了する: クラウド導入への投資がビジネス継続性の要件と SLA とどのように整合しているかを把握します。
共有責任を理解する: 戦略チームに、信頼性への影響など、クラウド内の共有責任モデルに関する詳細が含まれていることを確認します。 詳細については、信頼性要件を参照してください。
Azure の信頼性のを理解する: Azure の信頼性に関するドキュメント を使用して、Azure での信頼性と回復性の仕組みについて理解を深めます。
Azure サービスの信頼性機能について理解する: Azure サービスの信頼性ガイド を確認して、特定の Azure サービスの信頼性機能に関する導入戦略を通知します。
復旧目標を理解する: システムのダウンタイムとデータ損失の制限を理解するためのクラウド導入戦略の一環として、復旧時間目標 (RTO) と復旧ポイント目標 (RPO) について説明します。
現実的な信頼性の目標を定義する: 信頼性に関する現実的な期待を社内の利害関係者に設定し、契約契約を使用してそれらの期待を顧客に伝えます。 信頼性ターゲットを定義するための Azure Well-Architected Framework Recommendationsを参照してください。