ホリデーシーズンにアクティブ・アクティブのマルチクラウドアプローチが必要な理由

電子商取引のリーダーにとって、ホリデーシーズンは2つの確実性をもたらします：大量の買い物客とクラウドプロバイダーの停止のリスクの増大。主要なクラウドの障害は、より頻繁に発生し、より深刻なものになっているようです。たとえば、AWS US-East-1 リージョンには、ホリデーシーズン中に重大な障害が発生する歴史があります。同様に、毎年1月に、Microsoft Azureは、特定のリージョンでのリリースまたはテスト計画により、ネットワークの遅延やネットワークの停止を起こすことがあります。また、先月6月には、大規模なGoogle Cloudの停止が、幅広いアプリケーションに影響を与えました。これは、単一のプロバイダーが免疫を持っていないことを思い出させるものです。

電子商取引の運営を担当している場合、最も重要な時期に何らかの問題が発生してしまった場合、すべてを正常に設定していても、動作しないことがわかるのは避けたいためです。これらのクラウドプロバイダーの停止や問題の傾向は、あなたのレーダー上にないかもしれませんが、実際にはそうであるべきではありません。サイトの信頼性エンジニアである場合、クラウドプラットフォームの停止があなたのアプリケーションに影響を与えることを心配する必要はありません。また、問題が発生したときにインフラストラクチャを即座に調整する必要もありません。代わりに、多クラウドについて再検討する必要があります。

マルチクラウドアプリケーション

組織がAWS、Azure、GCPの料金を支払っている場合、実際には3つのクラウドを利用できることになります。しかし、1層深く調べると、クラウドプロバイダーが停止した場合や、すぐに別のプロバイダーに切り替える必要がある場合、どのようなことが起こるかを確認する必要があります。アプリケーションは、どのクラウド上でも完璧に動作する必要があります。これが真のマルチクラウド設定です。クラウドに依存しないようにしたい場合、単にマルチクラウドを支払うのではなく、アプリケーションもマルチクラウドであることを確認する必要があります。

さらに、単一のプロバイダーに依存すると、計算能力、APIのレート制限、地域の利用可能性に関する制限が生じます。真のマルチクラウドアーキテクチャは、集約された計算能力を増やし、これらの制限に対する耐性を提供します。単一のプロバイダーの制限を超えて、需要に応じて拡大し、ピークのショッピング日には一貫したパフォーマンスを保証する能力を解放します。しかし、クラウドに依存しないアプリケーションを持ち出すことは、最初のステップにすぎません。次のステップは、それを真に耐性のあるアーキテクチャに配置することです。

また、単一のプロバイダーに依存すると、計算能力、APIのレート制限、地域の利用可能性に関する制限が生じます。真のマルチクラウドアーキテクチャは、集約された計算能力を増やし、これらの制限に対する耐性を提供します。単一のプロバイダーの制限を超えて、需要に応じて拡大し、ピークのショッピング日には一貫したパフォーマンスを保証する能力を解放します。しかし、クラウドに依存しないアプリケーションを持ち出すことは、最初のステップにすぎません。次のステップは、それを真に耐性のあるアーキテクチャに配置することです。

アクティブ・アクティブへのスケーリング

これには、DevOpsによる重大な準備が必要です。100%の正確性を持つビジネス継続性と災害復旧戦略を持つことは非常に難しいです。実際の運用で、複数の障害点があります。障害時にBCDR戦略をテストしたくないので、可能なシナリオを予測し、準備する以外に何もできないかもしれません。

サイトの信頼性エンジニアへの私のアドバイスは、デフォルトで障害を想定するアーキテクチャを設計することです。これは、セカンダリまたはテリアリのクラウドをアクティブ状態で実行することを意味します。単一のプロバイダーに限定されたBCDR戦略は、単一の障害点です。プロバイダーのコントロールプレーンまたはネットワークバックボーンが故障した場合、全体の復旧計画は無効になります。

ホリデーシーズン中、訪問者の数が突然増加し、プラットフォームまたはアプリケーションが低容量で動作し始めることがあります。動作中のアプリケーションのコピー、セカンダリを作成した場合、ロードバランシングを実行して、一部の要求をアプリケーションの別のインスタンスに誘導できます。

このアクティブ・アクティブアプローチでは、完全な製品を複製し、別の場所で実行します。プライマリクラウドプロバイダーが重大な低下または停止を経験した場合、DNSまたはグローバルロードバランサを介して100%のトラフィックをセカンダリプロバイダーにシームレスに切り替えることができ、顧客への中断はありません。

マルチクラウドに移行しないことの本当のコスト

セカンダリクラウドを実行するコストは軽くないですが、主要な停止のビジネスへの影響に比べれば、些細なものです。顧客に信頼性の故障の後、謝罪し、再発しないことを約束し、競合他社に移るのを止めるために努力すること。失われた売上からの収益も忘れてはいけません。FluidCloudでは、このシナリオが何度も繰り返されています。企業は単一のプロバイダーに多大な投資を行い、停止の逆境に直面し、すぐに救済策を見つけることができないのです。

ただし、単一のクラウドプロバイダーを使用していても、コストを制御することは十分に難しいです。クラウドコストは、指数関数的なグラフのように見えるでしょう。複数のクラウドを採用すると、その指数関数的なグラフはさらに急激になるでしょう。

プライマリクラウドからインフラストラクチャを複製するとき、コストが倍増することは避けたいと思います。したがって、競合するパフォーマンスを提供するのに対して、より安価なクラウドに焦点を当てることをお勧めします。安価なクラウドでセカンダリを実行すると、依然としてアクティブ・アクティブの冗長性を持ちながら、コストを削減できます。双方の利益です。

最終的な考え

複数のクラウドプロバイダーにわたってアクティブ・アクティブでアプリケーションを実行することは、単にバックアップを作成することを意味しません。リアルタイムの回復力を持つことを意味します。ビジネスに単一の障害点がないことを意味します。クラウドプロバイダーまたはリージョンが故障した場合でも、一貫したスピードを提供できることを意味します。

このホリデーシーズン、信頼性を希望するのではなく、構築しましょう。システムを一貫して動作させるように設計しましょう。クラウドプロバイダーまたはリージョンが故障した場合でも、真のアクティブ・アクティブ、マルチクラウドアーキテクチャを採用して、顧客に完璧な体験を提供しましょう。