クラウド・レジリエンス向上のための9原則

• クラウド上のIaaS (サービスとしてのインフラストラクチャ) およびPaaS (サービスとしてのプラットフォーム) ソリューションは、基本的に安定性が高い。しかし、非IT部門の従業員はレジリエンスを「あり」か「なし」の二択のものと捉えがちで、クラウド・サービスをデフォルト構成で利用すればレジリエンスが得られると誤解していることが多い。
• アプリケーションのレジリエンスに対するニーズは新しいものではなく、クラウドやDevOpsの概念に固有のものでもない。使用するアプローチ、パターン、プラクティスの多くは、そのままオンプレミスにも適用できる場合が多い。しかし、顧客に広範な影響を及ぼすクラウド障害の原因がデータセンター上の問題にあることはまれであり、むしろ、ソフトウェアのバグが原因で1つ以上のクラウド・サービスに障害が発生するケースが多い。
• クラウド上の機能停止は、広範な影響を及ぼす世界規模の壊滅的な機能停止ではなく、特定のロケーションでいくつかのサービスに部分的な障害が発生することが一般的である。クラウド上の機能停止は、従来のディザスタ・リカバリ (DR) 作業を実施するほど長くは続かないことが多い。

ITレジリエンスの向上に責任を担うインフラストラクチャ／オペレーション (I&O) のリーダーは、以下を行う。

• 「クラウドには低コストのツールやコンポーネントが備わっているが、構築すべきレジリエンスのレベルは、ビジネス要件と予算に応じて判断すべき」という点を非IT部門従業員に周知することで、ビジネス側のステークホルダーとの連携を図る。まずはビジネス・インパクト分析 (BIA) を利用して、目標復旧時間 (RTO)、目標復旧時点 (RPO)、可用性の各要件の枠組みを作る。
• 依存関係をマッピングし、クラウドの障害状況に基づくリスク・ベースのアプローチを取ることで、壊滅的障害のみを想定したシナリオや、インフラストラクチャ障害のみに特化したレジリエンス対策に見当違いの過度な重点を置かないようにする。
• クラウド・アーキテクチャ、ソフトウェア・エンジニアリング、クラウド・センター・オブ・エクセレンス (COE) の各チームと協議し、標準やポリシーを確立・施行することで、アプリケーションに対して「レジリエント・バイ・デザイン」のアプローチを取る。アプリケーションのライフサイクル全体を通して、アーキテクチャの設計・実装・運用品質を総合的に確保すべきである。
• BIAを用いて、主要なビジネス機能に対する最小限の事業継続目標 (MBCO) を判断する。本番環境と同等のDRターゲットに「フェールオーバー」する従来のアプローチと比較して、MBCOを達成すべく軽量の代替アプリケーションを「立ち上げる」などの選択肢を評価する。