企業がミッションクリティカルなシステムをクラウドへ移行し続ける中、24時間365日の信頼性は必ずしも保証されないことが明らかになっている。わずかな停止でも販売の中断、社内ワークフローの遅延、顧客信頼の低下を招き、実際の損失につながる可能性がある。クラウドプラットフォームは印象的な柔軟性と拡張性を提供する一方で、意図的な計画を必要とする新たな複雑さも生み出している。
以下では、Forbes Technology Councilのメンバーが、組織がクラウドの回復力を強化し、予期せぬ事態に備える方法について見解を共有している。彼らの洞察は、クラウドサービスに障害が発生した際に企業が迅速に回復するのに役立つ考え方の転換と戦略的基盤を強調している。
コアビジネスジャーニーを特定する
システムの稼働時間だけでなく、ワークフローの回復力に焦点を当てる。ログイン、注文処理、請求など、継続しなければならないコアビジネスプロセスを特定し、クラウド依存関係に障害が発生した場合のフォールバックパスを確保する。これには、キャッシュアクセスの使用、トランザクションのキューイング、一時的な読み取り専用モードへの切り替えなどが含まれる場合がある。目標はゼロ停止ではなく、ビジネスの麻痺をゼロにすることだ。- アルン・ゴヤル氏, Octal IT Solution LLP
災害復旧を継続的パイプラインにする
災害復旧を継続的パイプラインにする—あらゆる変更がコードから回復可能な環境を構築し、直近1時間の匿名化されたトラフィックを再生し、不変バックアップから復元し、合成残高やチェックサムでデータの整合性を検証する。いずれかのステップが失敗した場合は、リリースをブロックする。時間の経過とともに、信頼性は四半期に一度練習する後付けではなく、デリバリーの副産物となり、監査人はその追跡可能性を高く評価する。- ジャガディッシュ・ゴカバラプ氏, Wissen Infotech
強力な計測でシステムの限界をテストする
鍵となるのは、アプリケーションとインフラストラクチャの関係を再考することだ。データセンターでは、チームはオーバープロビジョニングとリスク回避に対して報酬を得ていた。クラウドの信頼性には、好奇心と実験を称賛することが必要だ。計測を伴って境界をテストする権限をチームに与える。真の回復力は、動的なスケーリングと迅速な回復のためのアーキテクチャを設計する権限をチームに与えることから生まれる。- ニク・サテ氏, Blackhawk Network
マルチクラウドまたはハイブリッドアプローチを採用する
データベースのレプリケーションとクラスタリングにマルチクラウドまたはハイブリッド（クラウドとオンプレミス）アプローチを採用することで、単一プロバイダーへの依存を排除し、回復力を高める。適切に設計されたこのアーキテクチャは、総所有コストの削減、継続的な運用の確保、高可用性と災害復旧の両方のためのシームレスなフェイルオーバーの提供など、主要なビジネス目標に沿ったものとなる。- エーロ・テーリコルピ氏, Continuent
アーキテクチャの回復力を確保する
クラウドの信頼性はアーキテクチャの回復力から始まる。マルチリージョン冗長性、自動フェイルオーバー、リアルタイム監視を使用して、問題を迅速に検出し分離する。これをAI駆動の障害シナリオシミュレーションと組み合わせることで、障害が発生する前に災害復旧を強化する。- ロリ・シェーファー氏, Digital Wave Technology
リージョン間でライブ顧客データをミラーリングする
クラウドサービスの中断は、ビジネスクリティカルなサービスの中断を意味し、顧客に大きな混乱をもたらし、修正には数時間を要することが多い。サービスを2つ以上のクラウドリージョンにわたって複製するだけでは不十分だ。今日のビジネスでは、障害発生時にシームレスなフェイルオーバーを確保する高速なインメモリデータストレージを使用して、リージョン間でライブ顧客データを即座にミラーリングする必要もある。- ウィリアム・ベイン氏, ScaleOut Software, Inc.
初日から障害を想定した設計を行う
クラウドの信頼性と災害復旧を向上させるための重要な戦略は、初日から障害を想定して設計することだ。冗長性、分離、自動回復を核としたシステムを構築する。考え方の転換が重要だ：物事は壊れると想定し、完璧さではなく優雅な劣化のためのアーキテクチャを設計する。紙の上の災害復旧計画を持つだけでは不十分だ。- ニック・ダムラキス氏, Orases
継続的に起動可能な復旧ツインを実行する
復旧ツイン—別のリージョンやプロバイダーで、本番環境の先行書き込みログを再生する継続的に起動可能なクローンを実行する。すべてのマージはCIでツインカットオーバー（コールドからホットへ）に合格する必要がある。毎週レッドスイッチ訓練を行い、キャッシュ復元時間を測定する。ツインがドリフトした場合はデプロイをブロックする。セルとキューは影響範囲を制限するのに役立つ。- マルガリータ・シモノバ氏, ILoveMyQA
オンプレミスとクラウドシステムの両方の強みを活用する
重要なワークロードがクラウドに移行する中、稼働時間を確保するためには、オンプレミスとクラウドシステムの強みを組み合わせたハイブリッド冗長アーキテクチャが不可欠だ。柔軟性と信頼性のバランスを取ることで、ビジネス継続性を保護しながらイノベーションを可能にする。アジャイルで回復力のあるシステムは、混乱を成長に変える。- ルイス・ドミンゴス氏, Mitel
IaC、RPOとRTOの目標、明確な責任所在を組み合わせる
障害を回避するのではなく、障害に備えた設計を行う。冗長性を構築し、回復を自動化し、定期的にフェイルオーバーシナリオをテストして、計画が実際の条件で機能することを確認する。Infrastructure as Code、明確な目標復旧時点（RPO）と目標復旧時間（RTO）、明確な責任所在を組み合わせることで、災害復旧をバックアッププランからコアの回復力戦略に変える。- ディワカル・ドゥイベディ氏, Circular Edge
クラウドの分離とセキュリティを最大化する
クラウド環境の分離とセキュリティを最大化するソリューションを求める。信頼性はすべての障害を防ぐことではなく、信頼を失うことなく迅速に回復することだ。多くのチームは、Active Directoryのバックアップが失敗するまで、それが堅固だと思い込んでいる。定期的に回復方法をテストし、クリーンなスタンバイを維持し、チームがプロセスを理解していることを確認する。ツールは重要だが、効果的な回復の鍵は人だ。- ロバート・ボーベル氏, Cayosoft
クラウド顧客としての責任を理解する
クラウドの信頼性は印象的だ—障害が発生するまでは。クラウドが失敗した場合、自社のビジネス継続性を確保する責任は最終的にエンドカスタマーにある。より頻繁に発生するのは、クラウドベースのソフトウェアサプライヤーまたはエンドユーザーによる変更関連の問題だ。解決策は常に、特にミッションクリティカルなサービスについては、更新を本番環境に導入する前に十分なシステムテストを行うことから始まる。- マーティン・テイラー氏, Content Guru
深い可視性と自動アラート、オンコールワークフローを組み合わせる
見えないものからは回復できない。オブザーバビリティは不可欠だが、それは全体像の一部に過ぎない。クラウドの信頼性は、深い可視性と信頼性の高い自動アラート、オンコールワークフローを組み合わせることで実現する。これにより、重要なシグナルが即座に適切なアクションをトリガーし、ダウンタイムによる影響の拡大を防ぐ。- ジュディット・シャロン氏, OnPage Corporation
ベンダーSLAのみに依存することを避ける
ベンダーのサービスレベル契約（SLA）のみに依存するのではなく、マルチリージョン、自動フェイルオーバーアーキテクチャを構築することで、初日から障害に備えた設計を行う。Infrastructure as Codeテンプレート、カオステスト、リアルタイムオブザーバビリティを使用して回復力をコードとして扱い、回復準備状況を継続的に検証する。- ゴータム・チラカパティ氏, humana.com
オンプレミスインフラの価値を再発見する
ダウンタイムを許容できないユースケースでは、クラウドに対するより現代的なアプローチが必要だ。何十年もの間、新卒者は「クラウドファースト」または「クラウドオンリー」の考え方を教えられてきた。しかし、テクノロジーは大きく進歩している。オンプレミスインフラは強力でシンプル、そして信頼性が高い。オンプレミスとクラウドシステムをブレンドしたよりバランスの取れたアーキテクチャは、ダウンタイムを回避する上で大きな違いをもたらす可能性がある。- ブルース・コーンフェルド氏, StorMagic
エンドツーエンドの回復自動化に投資する
冗長性だけでなく、回復自動化に投資する。最速の検出も、回復に3つのチームにまたがる20の手動ステップが必要であれば意味がない。ロールバック、データ検証、顧客コミュニケーションを含むすべてをスクリプト化する。災害復旧ランブックは1つのコマンドであるべきだ。危機の際の人間の判断は価値があるが、パニック状態で定型作業を行う人間の手は危険だ。- マーク・フィッシャー氏, Dogtown Media LLC
プロバイダー間で実行できるワークロードを設計する
信頼性はすべての障害を防ぐことではなく、優雅に失敗することだ。回復力と災害復旧を後付けとして扱わないこと。プロバイダー間で同時に実行できるようにワークロードを設計する。一方が失敗すると、トラフィックは自動的に別のプロバイダーにルーティングされる。真のクラウドの信頼性は、ベンダーの保証ではなく、継続的なテスト、自動化、チーム間の準備から生まれる。- パビトラ・サイキア氏, Truist Bank
AI駆動のオブザーバビリティと自己修復アーキテクチャを融合する
クラウド信頼性の次のフロンティアは自律的な回復力だ。企業はAI駆動のオブザーバビリティと、異常を検出し、トラフィックを再ルーティングし、ワークロードをリアルタイムで自動回復する自己修復アーキテクチャを融合させるべきだ。データをバックアップするだけでなく、システムに適応を教える。目標はゼロダウンタイムではなく、インテリジェントで継続的に練習された回復によるゼロ中断だ。- パワン・アナンド氏, Persistent Systems
四半期ごとにクロスファンクショナルなフェイルオーバー訓練を実施する
信頼性をITの消火訓練のように扱うのをやめ、ドレスリハーサルのように扱おう。テクノロジー、運用、コミュニケーションチームを含む四半期ごとのフェイルオーバー訓練で「カオスの自信」を構築する。システムがダウンした場合（そしてそれは起こる）、最速の回復は即興ではなく、練習されたものだ。回復力はコードだけでなく、筋肉の記憶にも構築される。- アンドリュー・シーマー氏, Inventive
クラウドはいつでも障害が発生する可能性があると想定する
信頼性と災害復旧戦略は、クラウドがいつでも障害を起こす可能性があることを前提に設計・構築すべきだ。クラウド中心の戦略は、完全に管理されたマルチリージョン、グローバルに分散したサービスを活用すべきだ。単一のクラウドプロバイダーへの過度の依存を避けるため、ハイブリッド、マルチクラウド、マルチベンダー戦略を採用する。頻繁かつ意図的な災害復旧・回復力訓練と「適切に設計されたレビュー」を実施する。- ムルティウンジャイ・モハパトラ氏, Alysian
