この記事は、2026/1/26に公開された「2025 Was the Year the Cloud Reminded Us Who's Really in Control」の翻訳です。
障害が頻繁に発生する理由とその対策
2025年は、単一のクラウドベンダーに頼っていた企業にとって厳しい1年となりました。Snowflake の利用者は12月、スキーマの更新が複数のリージョンに波及し、13時間にわたってクエリがブロックされるのをなすすべもなく見ていました。また、Databricks のユーザーも数日間にわたって AI サービスの低下に対処する羽目になりました。
10月には Amazon Web Services（AWS）の US-East-1 リージョンが15時間にわたってダウンし、DynamoDB に影響を与える DNS エラーにより 1,000 社以上の企業がダウンしました。さらに6月には、Google Cloud の Service Control バイナリにおける null pointer 例外により、Cloud Storage、Compute Engine、BigQuery など、複数のシステムが数時間にわたり無効化され、Spotify、Discord、OpenAI にも波及効果が及びました。
どのインシデントにおいてもパターンは同じでした。利用者はステータスページを更新し、他の誰かが問題を解決するのを待っていたのです。ベンダーは障害が発生するかどうかではなく、障害が起きたときにどのような選択肢があるかで選ぶ必要があります。
繰り返されるパターン：グローバルリーチを持つ単一の障害点
Snowflake の12月のインシデントは、下位互換性のないデータベーススキーマの更新によって引き起こされました。バージョンの不一致エラーにより、AWS、Microsoft Azure、および Google Cloud Platoform (GCP) の複数のリージョンで操作が失敗したり、無期限にハングしたりしました。Snowflake の発表によると、影響を受けていないリージョンへのレプリケーションを事前に設定していた利用者を除いて、回避策はないとのことでした。その他全員がただ解決を待っていたのです。
Databricks の12月の障害（複数日にわたる）には、Unity Catalog の問題、複数のリージョンにおける計算能力の低下、数日にわたる Mosaic AI の障害が含まれていました。ステータス更新では、「潜在的な緩和策についてクラウドプロバイダーと連携している」と繰り返し報告されていました。このフレーズが依存チェーンのすべてを物語っています。Azure に何かあれば、Azure リージョンの Databricks 利用者にも悪影響があるということなのです。
Google Cloud の6月のインシデントでも同様の脆弱性が明らかになりました。このインシデントでは、空白フィールドの誤ったポリシーがグローバル設定テーブルに挿入され、数秒で世界中に複製されました。破損したデータによりクラッシュループが発生し、コアサービスが7.5時間停止したのですが、Google独自のステータスダッシュボードが当初利用できず、SRE チームは災害の範囲を確認することさえできなかったのです。
障害が物理的なものではなく論理的なものである場合、地域的な冗長性は役に立ちません。プラットフォームがグローバルに調整されたメタデータまたは共有構成に依存している場合、1つの不適切な更新があらゆる場所に伝播し、障害は地域を超えて広がります。
さらに、これらのシナリオでは、インフラストラクチャは分散されていますが、コントロールは一元化されたままです。Snowflake のコントロールプレーンが故障した場合、その下にある AWS、Azure、Google Cloud で実行されていることは関係ありません。Databricks が Azure の修正を待っている場合、マルチクラウドマーケティングは役に立ちません。単一障害点が最上位の独自のレイヤーだからです。
アナリストの声
Gartner®の2025年のクラウド導入動向分析によると、50％以上の組織でマルチクラウド導入時に期待された成果を2029年までに得られないと推定されています。ここでの根本的な問題は、環境間の相互運用性の欠如です。
調査会社 Forrester は「2026年の予測：クラウド障害、プライベートクラウド上のプライベート AI、およびネオクラウドの台頭」の中で、2026年に少なくとも2回、複数日に及ぶ大規模なクラウド障害が発生すると予測しています。ハイパースケーラーが AI ネイティブなデータセンターの構築を競う中、クラウド業界では大規模なインフラストラクチャの移行が進行しています。この投資には代償が伴います。従来の x86 および ARM 環境の優先順位は下げられ、複雑性が増す中で老朽化したインフラストラクチャが機能不全に陥ることになります。
同記事では、2026年に少なくとも15%の企業がプライベートクラウド上に構築されたプライベート AI の展開に移行すると予測しています。その要因は、AI コストの上昇、データロックインへの懸念、他者の優先事項に合わせて最適化されるインフラストラクチャに依存することによる運用上のリスクです。2025年の障害は、ワークロードがプロバイダーの最優先事項でない場合に、何が起こるかを予告する機会となったのです。
回復力を考慮した設計にCloudera を活用
ほとんどの企業は、意図的なアーキテクチャ計画ではなく、買収やシャドー IT、またはベストオブブリードのツールの選択に基づいて「偶発的なマルチクラウド」アーキテクチャを採用しています。ワークロードは複数のプロバイダーに分散されていますが、問題が発生したときにデータやワークロードを移動する能力がありません。
回復力を考慮した設計には、データとAIプラットフォームの移植性を確保し、フェイルオーバーの単一障害点を排除することが含まれます。
Cloudera プラットフォームはポータビリティを考慮して設計されており、環境間でのフェイルオーバーが可能で運用を維持できます。ワークロードやデータは AWS、Azure、Google Cloud、オンプレミス環境間で書き換えや摩擦、ベンダーのロックインなしに移動が可能。更新における変更も、グローバルであることや、下位互換性があることを強制しません。
避けられない障害が発生した場合も、別のクラウドにフェイルオーバーするか、ワークロードをデータセンターに戻すかを選択でき、ステータスページを見ながら待つ必要がありません。データの保存場所に関係なく、データをコントロールしながら、一貫した操作とコンプライアンスを維持できます。
Cloudera で回復力を考慮した設計を行う方法について詳しくは、弊社ブログ「データ回復力を考慮した設計：Cloudera で事業継続性を確保する方法」をご覧ください。
今後の展望
AI の構築はインフラストラクチャに負担をかけており、調査・分析専門企業は今後さらなる混乱（Forrester は数日間にわたる障害、Gartner は防衛的なマルチクラウドの導入）を予測しています。2026年も好調をキープする企業は、回復力をコンプライアンスのためのチェック項目の一つとして扱うのではなく、アーキテクチャの原則として扱う企業でしょう。
追加設定なしで使える、プッシュボタン式のクロスクラウドフェイルオーバー機能は、Cloudera を含め、どこにもありません。しかし、Cloudera は、その設計により、独自のプラットフォームでは実現できない方法で、回復力をサポートできる立場を確立しました。
2025年に起こった障害に不安を感じたのであれば、ぜひご相談ください。クラウドは他人のパソコンと変わりません。そのパソコンの調子が悪ければ、他のパソコンを使えばいいのです。
回復力を考慮した設計に Cloudera を活用する方法について詳しくは、プロフェッショナルサービスチームにお問い合わせいただくか、製品デモをご覧いただくか、5日間の無料トライアルにご登録ください。
