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

電子商取引のリーダーにとって、ホリデー・シーズンには2つの確実性があります。大量のショッパーが訪れることと、クラウド・プロバイダー・アウトエージのリスクが高まることです。主要なクラウドの障害は、より頻繁に発生し、より深刻な影響を及ぼすようになっています。たとえば、AWS US-East-1 リージョンには、ホリデー・シーズンの大規模な障害の歴史があります。同様に、毎年1月ごろ、Microsoft Azure は、特定のリージョンでのリリースまたはテスト・プランにより、ネットワークの遅延やネットワーク・アウトエージが発生する傾向があります。また、先月の6月には、大規模な Google Cloud のアウトエージ が多数のアプリケーションに影響を及ぼしたことを思い出せば、単一のプロバイダーは誰もが免疫ではないことを思い知らされることになります。

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

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

あなたの組織が AWS、Azure、GCP の料金を支払っている場合、実際には 3 つのクラウドを利用できることになります。しかし、1 層目に深く掘り下げてみると、重要な点があります。AWS、Azure、または GCP に特化したアプリケーションを持っている場合、クラウド・プロバイダーの 1 つがダウンしたときに、迅速に別のクラウドに切り替えることができますか?

あなたのアプリケーションは、どのクラウド上でも完璧に動作する必要があります。那が真正なマルチクラウド・セットアップです。如果あなたがクラウド・アグノスティックであることを望む場合、単にマルチクラウドを支払うのではなく、あなたのアプリケーションもマルチクラウドであることを確認する必要があります。

さらに、単一のプロバイダーに依存することで、コンピュート・キャパシティ、API レート制限、およびリージョンごとの可用性に関する固有の制約が生じます。真正なマルチクラウド・アーキテクチャは、集約されたコンピュート・パワーを増加させ、これらの制約に対する耐性を提供します。単一のプロバイダーの制限を超えて、需要に応じてスケールアップし、地理的に容量を迅速に拡大し、ピークのショッピング・デー中に一貫したパフォーマンスを確保する能力が解放されます。しかし、ポータブルでクラウド・アグノスティックなアプリケーションを持つことは、最初のステップにすぎません。次のステップは、それを真正に耐性のあるアーキテクチャでデプロイすることです。

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

これには、DevOps による重大な準備が必要です。100% の正確な ビジネス・コンティニュイティ・ディザスター・リカバリー (BCDR) 戦略を持つことは、非常に困難です。なぜなら、実際の運用において、多数の障害点があるからです。BCDR 戦略をアウトエージでテストしたくないので、可能なシナリオを予測し、準備することだけができるかもしれません。

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

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

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

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

セカンダリ・クラウドを実行するコストは、軽視できないものですが、主要なアウトエージのビジネスへの影響と比較すると、些細なものです。顧客に信頼性の失敗について謝罪し、再発しないことを約束し、競合他社に顧客を失わないように説得すること。さらに、失われた売上による収益の損失を忘れてはいけません。FluidCloud で私はこのシナリオを何度も見てきました。企業は単一のプロバイダーに多大な投資を行い、しかしアウトエージの間で即座の救済策がないまま、逆境に立たされることになります。

ただし、単一のクラウド・プロバイダーを使用していても、コストを制御することは困難です。クラウド・コストは、ほぼ指数関数的なグラフのようになります。如果マルチクラウドを採用する場合、その指数関数的なグラフはさらに急激になるでしょう。

プライマリ・クラウドからインフラストラクチャを複製するとき、コストが倍増することは避けたいものです。したがって、競合するパフォーマンスを提供する低コストのクラウドに焦点を当てることをお勧めします。如果セカンダリが低コストのクラウドで実行されている場合、依然として完全なアクティブ・アクティブな冗長性を維持できますが、コストは低くなります。これは、双方にメリットがあります。

最終的な考察

マルチクラウド・プロバイダー全体でアクティブ・アクティブなアプリケーションを実行することは、単にバックアップを作成することを意味しません。実時間の耐性を構築し、ビジネスに単一の障害点がないことを保証し、トラフィックの急増期间でも一貫した速度を提供することを意味します。

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