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

このような大規模なクラウド障害は避けられない。以下の4つの方法で您的会社は被害を軽減できる。
数多くの生産性の低下、数百万人のユーザーに影響を及ぼした金融システム、および数百億ドル規模の損失、この週のAWS障害は確実に世界のITチームにとって最悪の日となった。もちろん、これは前回のクラウド障害以来、最悪のクラウド災害であった…そして次のものまで。
AWS、GCP、Azure、またはその他のプラットフォームにいるかどうかは関係なく、クラウド障害はクラウドコンピューティングの現実である。そこで、您的会社はクラウド障害の影響を軽減するために何ができるか。以下に、您的チームがすぐに実行できる4つのステップを紹介する。
懐疑心を持って準備し、調査を実施する。
多くの場合、チームはクラウドの契約に際して、主要なクラウド企業は本質的に信頼できるものであると考え、災難を招く。確かに、最も信頼できる企業はその評判を得る理由がある。同時に、すべてのクラウドとハイパースケーラーは、幅広いインフラストラクチャオプションを提供している。たとえば、AWS North America aloneには31のアベイラビリティーゾーンと31のエッジネットワークロケーションがある。しかしそれらのオプションの中には、他よりもはるかに信頼性が高いものがある。
実際、AWSのUS-EAST-1リージョンは、この週の障害の原因となり、2020年、2021年、2023年に大きな混乱を引き起こしたことが知られていた。さらに、あるIT関係者の中では、最も信頼性が低いリージョンとして知られていた。多くの企業は状況を理解していたかもしれないが、リージョンの低コストと豊富な提供により、計算されたリスクを負った。しかしながら、障害の規模を考えると、多くの企業が完全に驚かされたこと、およびもっと信頼性の高いリージョンを選択したであろうことは否定できない。私はUS-EAST-1での過去の悪い経験の後、他のAWSリージョンに移行したITリーダーに会ったことがある。
ここでの教訓は、クラウドインフラストラクチャオプションについて、どのクラウドを使用しているかに関係なく、十分な調査を実施することである。調査を開始するための場所として、cloudprice、Cloudping、およびハイパースケーラー提供のクラウドサービスヘルスツールからの歴史的なインシデントビューが利用できる。
クラウドネイティブではなく、ポータブルなオプションを選択する。
クラウド構成を設計する際、最も簡単な方法はクラウドネイティブを選択することである。しかしながら、クラウドプロバイダーによって事前に構築されたアプリケーションを選択することは便利であるが、クラウドがダウンした場合にさらなるクラウド依存を招く。
その追加のクラウド依存を避けるために、可能な限り独立した、またはオープンソースの製品を選択する。以下はその例である。
|
カテゴリ |
ネイティブオファリングの例 |
オープンソースの代替オプション |
|
認証およびアイデンティティ |
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つのクラウドでのインフラストラクチャの構築は、強力で、多くの場合実行可能な開始点である。ここで重要なのは、各クラウドの専門家を擁したチームを配置することである。
確かに、どの方法でも、企業をこのような大規模なクラウド障害の影響から完全に守ることはできない。しかしながら、十分な調査、クラウドポータブルなアプローチ、障害を想定した設計、そして「デュアルクラウド」を真のマルチクラウドへのステップストーンとして使用することで、企業は次の(そして不幸にも避けられない)大規模なクラウド障害の際に、より迅速に対応できる。












