表面的には、クラウド コンピューティングは、クラウド リソースの幅広さと堅牢な機能により、「設定したら忘れる」というコンセプトで災害復旧を目的として作られたように思えます。
しかし、その概念は単純ではありません。冗長性とデータ保護は、稼働時間の維持と災害からの復旧の中核となる要素ですが、クラウド運用における最良の結果を得るには、森の中の個々の木に焦点を当てることが重要です。
Workspot の共同創設者兼 CEO である Amitabh Sinha 氏、Mitiga の共同創設者兼最高技術責任者である Ofer Maor 氏、および Mitiga のクラウド セキュリティ リサーチ チーム リーダーである Or Aspir 氏が、クラウド障害復旧のベスト プラクティスに関するアドバイスを TechRepublic に提供しました。
ジャンプ先:
- 最大の課題: クラウド環境での稼働時間の維持
- クラウドの課題を軽減
- 災害復旧の要素
最大の課題: クラウド環境での稼働時間の維持
アミタブ・シンハ：最大の課題は、クラウドが提供する可用性のレベルです。現在、主要なパブリッククラウド（AWS、Google、Azure）は99.9%の可用性を提供していますが、これは年間8時間以上のダウンタイムを意味します。これは、ほとんどのミッションクリティカルなワークロードの運用に大きな支障をきたし、組織に数百万ドルもの生産性損失をもたらす可能性があります。
2つ目の大きな課題は、クラウドのキャパシティに関するものです。組織は、使用していない仮想マシンの一部をシャットダウンすることでクラウドコストを最適化しようとするかもしれませんが、それらを再起動する必要がある場合、どうなるでしょうか？クラウドが利用可能であっても、そのクラウドリージョンまたはクラウドには、それらのマシンを再び再起動するためのキャパシティが不足している可能性があり、これも生産性を低下させる要因となります。
災害復旧のシナリオでは、業務を再開するために必要な容量を確保できない場合、容量の制約はさらに大きなリスクとなります。
参照:災害復旧と事業継続計画
Ofer Maor:クラウドとその責任共有モデルの概念は、環境の保守と可用性の責任はクラウドベンダーにあるというものです。しかし、現実はもっと複雑です。
クラウド ベンダーは 100% の可用性を保証するのではなく、それに近い可用性のみを保証しています。ほとんどの時間、環境は稼働していますが、過去 2 年間でさまざまなクラウド ベンダーで複数回の停止が発生しています。
さらに、可用性の他の側面は、特定のアプリケーションとリソースの使用率に関係しており、これらはクラウド ベンダーではなくユーザーの責任となっています。
最後に、攻撃がクラウドに移行するにつれて、セキュリティ侵害は、DoS 攻撃からリソースの悪用、ランサムウェア攻撃まで、さまざまな手段を通じてサービスの中断につながる可能性が高くなります。
あるいは、Aspir：クラウドへの移行には、組織が新たなスキルを習得し、既存のプロセスを適応させ、クラウドインフラとサービスの複雑さに慣れる必要があります。こうした学習曲線によって、導入、構成、トラブルシューティングのプロセスが遅延し、チームがクラウドテクノロジーの複雑さを乗り越える過程で稼働時間に影響を与える可能性があります。
クラウドプロバイダーが提供するマルチゾーンまたはマルチリージョンの冗長性にもかかわらず、多くの企業はコンプライアンスとコストを考慮して、集中型のリージョン／ゾーンを選択しています。しかし、この集中型のアプローチは、特定のゾーン内での停電、ネットワークの中断、物理的な損傷の影響を受けやすく、アップタイムとサービスの可用性にリスクをもたらします。
クラウドの課題を軽減
アミタブ・シンハ：特にエンドユーザーコンピューティング（EUC）においては、マルチクラウド・マルチリージョンのアプローチが不可欠です。EUCワークロードを複数のクラウドリージョンや主要クラウドにまたがって実行することで、企業が経験するダウンタイムを大幅に削減できます。
ITリーダーは、例えばプライマリ仮想デスクトップからセカンダリデスクトップへの自動フェイルオーバー（セカンダリデスクトップが別のクラウドリージョンにあるか代替クラウドにあるかは関係ありません）を、エンドユーザーにとって完全に透過的に実行できる機能を期待すべきです。この常時利用可能な仮想デスクトップは今や現実のものとなりました。仮想デスクトップの展開は、稼働時間を確保するために、複数のリージョンとクラウドに分散させる必要があります。
またはAspir：効果的な監視とインシデント対応メカニズムは、問題を迅速に特定し対処するために不可欠です。プロアクティブな計画を活用して、企業の目標復旧時間（RTO）と目標復旧時点（RPO）を把握しましょう。
稼働時間を確保し、効果的な災害復旧戦略を実装するためのクラウドプロバイダーのサービスを検討してください。AWSの災害復旧に関するブログ記事は良い例です。
災害復旧の要素
アミタブ・シンハ： RTOは、DRの文脈において誰もが考慮する指標です。障害発生後、ビジネスを復旧させるまでにどれくらいの時間がかかりますか？従来のオンプレミス型データセンターの世界では、RTOは通常数日単位で測定され、ビジネスに壊滅的な影響を与える可能性がありました。
先ほどお話しした2つの側面、クラウドの可用性とクラウドのキャパシティについてです。DRの観点だけでなく、日常の運用においても、組織はクラウドの停止、気象現象、ランサムウェア攻撃など、ビジネスの中断から数分で回復できる俊敏性を備えていなければなりません。数日単位のRTOはもはや受け入れられません。マルチクラウドアプローチは、クラウドの可用性とキャパシティの制約を予測し、プロアクティブに解決します。
Ofer Maor:災害復旧は、この課題において極めて重要な要素です。稼働時間の問題は、CSPリージョンの停止など、時間的な制約のあるイベントによって発生する場合もあります（この場合、DRはそれほど必要ありません。自然に復旧します）。しかし、クラウド環境の破壊や、より深刻なケースではデータ自体の破壊など、災害復旧対策が必要となるケースもあります。
当然のことながら、バックアップはクラウド（およびSaaS）顧客が自ら行うべき重要なピースです。なぜなら、クラウドベンダーにバックアップを依存することはできないからです（少なくともほとんどの共有責任モデルでは）。多くの組織が依然として遅れをとっている分野の一つがSaaSのバックアップとリカバリですが、組織が侵害され、SharePointやGDrive全体が攻撃者に人質に取られた場合、ベンダーは対応できない可能性があります。
クラウド災害復旧とオンプレミス災害復旧の比較
アミタブ・シンハ：オンプレミスでは、復旧までに数日から数週間かかる場合があり、コストがかかり、チームにとって非常に時間のかかる作業です。クラウドDRシナリオでは、適切なソリューションを選択すれば、企業は数分で復旧できます。
気象現象がどのように影響するかと関連する推奨事項
またはAspir：ハリケーン、洪水、暴風雨などの悪天候は、クラウド内の特定のアベイラビリティゾーン内のデータセンターに混乱をもたらす可能性があります。これらの混乱は、停電、ネットワークの中断、物理的な損傷を引き起こし、サービスの中断につながり、そのゾーン内のクラウドリソースの可用性に影響を与える可能性があります。このような事例の一例として、2023年4月25日にヨーロッパで発生した複数のGoogle Cloudサービスの障害が挙げられます。この障害は、洪水と火災の複合的な発生により発生しました。
厳しい気象条件に対する耐性を確保するために、クラウド サービスの可用性ゾーンの冗長性を検証することをお勧めします。
エンドユーザーをもっと監視することで、停止によるコストのかかるダウンタイムをどのように短縮できるでしょうか?
アミタブ・シンハ：エンドユーザーのリアルタイムの可視性は、ダウンタイムを最小限に抑えるために不可欠です。エンドユーザーの可観測性により、ITチームはユーザーが抱えている問題を把握できます。このデータを活用することで、チームは問題のレベルを把握できます。例えば、単一のデスクトップやアプリへのアクセスに問題がある場合から、それらのリソースのパフォーマンスに至るまで、多岐にわたります。
特定の地域における傾向など、より重大な問題があるかどうか、また、一部のエンドユーザーのみに影響が及んでいるのか、あるいは広範囲に及ぶ可能性があるのかを判断できます。ネットワークの問題なのか、それともクラウドの可用性とアクセスに関して生産性に影響を与える可能性のあるパターンが現れているのかを判断し、リアルタイムで問題解決のための対策を講じることができます。
データセンター環境では、ITチームはデータセンター内部の制御と可視性しか持ちません。これらのレガシーシステムは、クラウド環境のようなエンドユーザーへの可視性を備えていません。クラウドのエンドユーザー監視ツールを実行することで、ITチームはリアルタイムで対応し、既存の問題を迅速に特定して解決することができます。
IT プロフェッショナルがここで重点を置くことを他にお勧めしますか?
Amitabh Sinha:すべてのエンド ユーザー アプリケーションに対して、製品内で直接エンド ユーザー フィードバック メカニズムを作成します (例: Teams または Zoom セッションの終了時のアンケート)。
サーバー ワークロード用の DataDog、エンド ユーザー コンピューティング ワークロード用の Workspot や ControlUp など、ワークロード固有のクラウド ネイティブの観測ツールを活用します。
問題が迅速に解決されるように、観測可能性ツールから得られた洞察に基づいて行動する人材とプロセスを定義します。
Or Aspir：セキュリティインシデントが災害復旧に及ぼす潜在的な影響に対処するには、自然災害や故障だけにとどまらず、その範囲を広げることが不可欠です。共有責任モデルにおいては、顧客は自社のクラウドまたはSaaSインスタンスの利用におけるセキュリティに責任を負い、設定ミスやユーザーの不正アクセスに起因する侵害も顧客の責任となり、したがって、そのような事象の影響への対応も顧客が責任を負うことを理解することが重要です。
これには、侵害されたIDが本番システムだけでなくバックアップシステムにも権限を持っているシナリオも含まれます。このようなセキュリティ関連の災害を認識し、備えることで、組織は全体的な災害復旧戦略を強化し、不正アクセスや侵害されたIDに関連するリスクを軽減することができます。
サードパーティの組織との連携を含む強力なインシデント対応計画があれば、セキュリティ インシデントが発生した場合の災害復旧への対応に大きく役立ちます。
次に読む:組織に地域的な災害復旧が必要: Kubernetes 上で構築する方法
