ソートリーダー
次のクラウド障害に向けて今すぐ準備を始めましょう

この週のAWSのようなメジャークラウド障害は避けられない。これらの4つの方法により、貴社は続行することができます。
数多くの生産性の低下、金融システムが数百万のユーザーにわたって混乱、および数百億ドルの損失が発生する可能性がある、この週のAWS障害は、世界のITチームにとって間違いなく最悪の日となりました。もちろん、これは、前回の出来事以来、最も深刻なクラウド災害であり、そして次の出来事まで続くでしょう。
AWS、GCP、Azure、またはその他のプラットフォーム上にいても、メジャーな障害はクラウドコンピューティングの現実の当たり前です。そこで、貴社はクラウド障害の影響を和らげるために何をすることができますか。以下に、貴社のチームがすぐに取り組むことができる4つのステップを示します。
懐疑心を持ち、調査をします。
多くの場合、チームはクラウド企業が本来信頼できるという前提でクラウド契約に臨み、災難を招きます。確かに、最も信頼できる企業はその評判を得る理由があるのです。しかし、すべてのクラウドとハイパースケーラーには、さまざまなインフラストラクチャオプションが提供されています。たとえば、AWS North America aloneには、31のアベイラビリティーゾーンと31のエッジネットワークロケーションがあります。しかしそのうちのいくつかは他のよりもはるかに信頼性が高いです。
実際、US-EAST-1リージョンは、この週の障害の原因となり、2020年、2021年、2023年に大規模な障害を引き起こしました。また、一部のIT関係者の中では、最も信頼性の低いリージョンとして知られていました。多くの企業は、リージョンの低コストと豊富な提供サービスを考慮して、リスクを負ってUS-EAST-1を選択したのでしょう。しかし、障害の規模からすると、どのくらいの企業が完全に驚かされたのか、またどのくらいの企業がもっと信頼性の高いリージョンを選択したかは、想像に難くありません。私はUS-EAST-1での悪い経験の後、他のAWSリージョンに移行したITリーダーと出会ったことがあります。
ここでの教訓は、どのクラウドを使用しているかに関係なく、クラウドインフラストラクチャオプションについて十分な調査をすることです。調査を開始するための場所として、cloudprice、Cloudping、およびハイパースケーラー提供のCloud Service Healthツールからの歴史的インシデントビューなどの無料ツールがあります。
クラウドネイティブではなく、ポータブルを選択します。
クラウド構成を設計する際、最も簡単な方法はクラウドネイティブを選択することです。しかし、クラウドプロバイダーによって事前に構築されたアプリケーションを選択することは便利ですが、クラウドがダウンした場合にさらなるクラウド依存につながります。
その追加のクラウド依存を避けるために、可能な限り独立したおよび/またはオープンソース製品を選択します。以下は、代替製品の例です:
|
カテゴリ |
ネイティブオファリングの例 |
オープンソースの代替製品 |
|
認証とアイデンティティ |
AWS Cognito |
Keycloak |
|
検索 |
Azure Monitor |
Elasticsearch |
|
関係データベース |
Google Cloud SQL |
PostgreSQL |
|
NoSQLデータベース |
AWS DynamoDB |
MongoDB |
|
コンテナオーケストレーション |
Azure Kubernetes Service (AKS) |
Kubernetes |
|
モニタリングと観測可能性 |
Google Cloud Monitoring |
Prometheus + Grafana |
|
メッセージキュー |
AWS SQS/SNS |
Apache Kafka |
|
オブジェクトストレージ |
Azure Blob Storage |
MinIO |
|
APIゲートウェイ |
Google Cloud API Gateway |
Kong |
確かに、クラウドスタックの構築はより多くの作業を伴います。しかし、私の経験上、インフラストラクチャが稼働し始めると、自社で構築したインフラストラクチャとクラウドネイティブのインフラストラクチャの間にはほとんど差がありません。さらに、回復力とクラウドロックインの軽減という点で、独立したオプションは非常に有益です。
障害を想定して設計します。
クラウド障害が発生することは避けられないため、クラウド障害を考慮して製品を設計する必要があります。例として、Datadogを参照できます。2023年の出来事で、同社は突然、Kubernetesノードの半分以上を失い、災害対応を全面的に見直しました。変更には、システム全体に波及する部分的な障害を防ぐために、構造的なボトルネックを除去し、技術的負債に対処し、障害時のデータ可用性を向上させるためのデータの取り込みと保存の改善、自動回復システムの構築が含まれました。開始するための優れた場所は、Datadogの「エンドユーザーにとって重要なものから始める」という勧告に従い、最も重要なものを保護するためのセーフティネットを構築することです。
少なくとも2つのクラウドで実行します。
クラウド障害に左右されないための最良の方法は、マルチクラウドの冗長性です。真のマルチクラウドの流動性を達成することは、多くの企業にとって大きな取り組みです。なぜなら、クラウド間のインフラストラクチャの移行は非常に難しいからです。しかし、2つのクラウド上でインフラストラクチャを構築することは、強力で、多くの場合、実行可能な開始点です。マルチクラウドを効果的に実行するには、クラウドの専門家をチームに配置することが重要です。
確かに、巨大な障害の影響から企業を完全に守ることはできません。しかし、十分な調査、クラウドポータブルなアプローチ、障害を想定した設計、そして「デュアルクラウド」を真のマルチクラウドへのステップストーンとして使用することで、企業は次の(そして残念ながら避けられない)大規模なクラウド障害が発生したときに、より機敏に対応できるようになります。










