クラウド障害に備える6つのステップ

企業は、多くのアプリケーション タイプに柔軟性、迅速な拡張性、信頼性を提供するパブリック クラウドに注目することがよくありますが、パブリック クラウドは完璧ではありません。すべての主要なクラウド プロバイダーは、ネットワーク接続などの外部リソースだけでなく、内部システムやストレージの停止も経験しています。ビジネスの中断はどのビジネスにとっても壊滅的な打撃であり、クラウド コンピューティングの停止は何百人ものユーザーのビジネスに影響を及ぼす可能性があります。

これらすべては、パブリック クラウド コンピューティングの普遍的な現実を浮き彫りにしています。つまり、オンプレミスのデータ センターの場合と同様に、ユーザーは災害復旧計画を採用する必要があるということです。クラウドが停止した場合の対処方法を事前に計画しておくことで、ビジネスへの影響を軽減したり、悪化させたりすることができます。パブリック クラウドの停止に対処するために考慮すべき 6 つの重要な手順を以下に示します。

[[278370]]

ステップ1: 災害復旧戦略を策定する

クラウドの停止に備える最初のステップは、災害が発生するずっと前に災害復旧 (DR) 計画を作成して実装し、実施することです。クラウド コンピューティング プロバイダーは多数のサービスとリソースを提供していますが、ユーザーはワークロードごとにこれらのサービスとリソースを作成、展開、構成、監視する必要があります。

実際の災害復旧戦略は、ワークロードのニーズとビジネスにおけるその重要性に応じて大きく異なります。日常的なアプリケーションは、別のプロバイダー リージョン、別のクラウド プロバイダー、またはローカル ストレージ リソースなどのセカンダリ ロケーションへの定期的なデータ バックアップと VM スナップショットに適している場合があります。

高度な災害復旧計画では、別のリージョンにデプロイされているがアイドル状態であり、プライマリ インスタンスがダウンした場合に引き継ぐ準備ができているスタンバイ インスタンスを使用できます。さらに包括的な災害復旧戦略には、複数のクラウド リージョンまたは可用性ゾーンでワークロードの重複インスタンスを実行する分散クラスターを含めることができます。たとえば、このような戦略には、ロード バランサーを使用してトラフィックを複数のインスタンスに分散し、そのリージョンでクラウドの停止が発生した場合にトラフィックをリダイレクトすることが含まれます。

これらのレプリケーション作業の極端なバリエーションは、マルチクラウド災害復旧戦略です。この戦略では、ワークロードが 2 つ以上のクラウド (AWS と Microsoft Azure、または Azure と Google Cloud など) にわたって冗長的に運用され、クラウド停止の可能性から保護されます。

ステップ2: コミュニケーションを図り、クラウドコンピューティングの透明性を実現する

状況が変わったときは、クラウドで何が起こっているかを理解する必要があります。クラウド プロバイダーは従来、サービス停止について透明性を欠いていましたが、企業がより価値の高いワークロードをパブリック クラウドに委託するにつれて、状況は変わりつつあります。企業はクラウドの透明性の向上を要求しており、プロバイダーもユーザーとのコミュニケーションを改善し、障害の性質と現在の状態に関するよりタイムリーな洞察を提供しています。

たとえば、AWS ではすべてのサービスの現在のステータスを表示するサービス ヘルス ダッシュボードが提供されており、Microsoft Azure では同様の「Azure ステータス」ページが提供されています。災害復旧の決定は、企業の災害とその重大性に関する理解、およびプロバイダーの災害期間の見積もりによって左右されますが、これらはすべて、クラウドの透明性を高めることで改善できます。

しかし、そこで止まらないでください。ビジネスとユーザー ベースは影響を受けるワークロードに依存するため、停止の詳細を社内ユーザーや顧客に伝えることも同様に重要です。停止、ワークロードへの影響、停止を解決するために実行した手順を通知します。

ステップ3: 災害復旧計画のビジネス価値を判断する

災害復旧計画を実行するために何を行う必要があるかを決定します。一部のプランは自動です。たとえば、重要なワークロードは、ノード (またはインスタンス) に障害が発生した場合でも動作を継続する必要がある何らかのタイプのクラスタリングによって保護されることがよくあります。ただし、セカンダリ ワークロードの災害復旧戦略では、スナップショットの復元と再起動、バックアップ インスタンスへの切り替えなど、人による介入や個別の手順が必要になる場合があります。

人的介入が必要な場合は、回復プロセスにかかる作業と費用を考慮し、回復を開始するビジネス価値を判断します。クラウド プロバイダーが停止を解決するのを待つだけの場合よりも、ワークロードの復元に時間がかかり、コストも高くなるかどうかを尋ねます。クラウド コンピューティング プロバイダーからの通信は、この決定に大きな影響を与えます。

ステップ4: 災害復旧計画を実施する

多くの場合、ミッションクリティカルな災害復旧計画は完全に自動化されており、管理者による意図的なアクションを必要としない場合があります。たとえば、AWS クラウドの可用性ゾーンまたは Azure クラウドのリージョンにまたがるクラスターは、クラウドの停止中に 1 つのノードが使用できなくなった場合でも、機能し続ける可能性があります。

ただし、重要度の低いワークロードでは計画的なアクションが必要になる場合があります。準備されたスクリプト、テンプレート、またはその他のリソースを使用して、適切な災害復旧対応を調整します。企業が人的介入を必要とする災害復旧計画を開始することを決定した場合、管理者は直ちに行動する必要があります。これには、スナップショットからの再起動や、クラウド停止中のスタンバイ インスタンスへのトラフィックのリダイレクトが含まれる場合があります。

災害復旧計画には定期的なテストが必要です。ワークロードの回復を容易にするために適切な手順とリソースが確保されていることを確認するために、テスト演習を実行します。このテストでは、IP アドレスや関連ドライバー、依存関係などの関連リソースの構成も検証します。定期的なテストでリカバリが適切に機能する場合、実際の災害復旧状況でも適切に機能する可能性が高くなります。

ステップ5: 災害復旧戦略を監視する

災害復旧戦略の実装に必要な労力や自動化の量に関係なく、復旧されたワークロードが適切に機能していることを確認することが重要です。管理者は、災害復旧状態で実行されているワークロードのパフォーマンスを、通常の状態で実行されている同じワークロードのパフォーマンスと比較する必要があります。

Amazon CloudWatch や Google Stackdriver などのアプリケーション監視ツールは、ワークロードの健全性を監視します。これらのツールは、回復されたワークロードに関する運用データを中継するために、ログ、メトリック、イベントも収集します。さらに、クラウド停止中もワークロードのパフォーマンスと可用性を継続的に監視します。

ステップ6: クラウド障害の事後評価

クラウドの停止は企業にとって痛手となりますが、永久に続くわけではありません。クラウド プロバイダーが停止を解決し、通常のワークロード操作を再開すると、組織はインシデントの事後評価を実施し、災害復旧対応を評価する必要があります。

企業は災害復旧計画がどれだけ効果的であるかを考慮し、必要に応じて調整する必要もあります。これには、アプリケーションに割り当てられた災害復旧保護レベルの変更、災害復旧手順の実装に使用されるプロセスの微調整、または将来のクラウド停止の影響を軽減できるその他の変更が含まれる可能性があります。