Incident Tech

お問い合わせ
           
お問い合わせ
ブログ

中国のシステム障害対応事例まとめ（第二回）

2026/04/06
Kota Kagami

はじめに

第一回では中国のインターネット基盤の二層構造（国内完結設計と国際接続依存）を押さえたうえで、Alipay（支付宝）の誤表示障害、中国ユニコム（中国联通）のローカルDNS異常、そしてGreat Firewall によるTCP/443遮断という3つの事例を取り上げました。

第二回となる今回は、中国のパブリッククラウド最大手であるAlibaba Cloud（アリババクラウド）が2024年に経験した2つの障害を取り上げます。一方はネットワーク設定に起因する短時間の障害、もう一方はデータセンターの火災という物理的なリスクが発端の長期障害です。どちらも「クラウドを使っているから大丈夫」という思い込みを揺さぶる事例です。

事例1　Alibaba Cloud 上海AZ-N障害（2024年7月2日）

詳細

2024年7月2日午前10〜11時頃、Alibaba Cloud（アリババクラウド）の上海リージョン アベイラビリティゾーンN（以下AZ-N）でネットワークアクセス異常が発生し、同ゾーンに主要サービスを展開していたBilibili（中国最大の動画プラットフォーム）とRedNote（小红书Xiaohongshu、中国の画像・レビューSNS）で大規模な障害が連鎖発生しました。Bilibiliではコンテンツ更新の失敗、コメント欄の異常、コメント投稿の不能に加え、個人ページやメッセージ機能が全面的に利用不可能となりました。RedNoteでも同様の全面的なサービス停止が確認されています。

Alibaba Cloudのステータスページに残る記録では、発生から解決まで38分とされており障害自体は比較的短時間で収束しています。

対応のポイント

Alibaba Cloudのエンジニアチームは障害検知後、AZ-Nへの通信トラフィックを迂回させるネットワーク切り替えを実施し、段階的にサービスを復旧させました。注目すべきは、この迂回設計があらかじめ用意されていたことで38分という短い復旧時間の技術的根拠になっています。

一方で、BilibiliとXiaohongshuのいずれも上海リージョンの単一ゾーンに主要サービスを集中展開していたことが、障害波及の速さを決定づけました。「本社が上海にあり地理的に最適」という判断は確かに合理的ですが、ゾーン単位の障害で全面停止につながる構成はクラウドアーキテクチャ設計上の典型的な落とし穴といえます。

原因

正式な根本原因の公開はありませんが、ネットワーク機器の異常またはネットワーク設定の問題によるパケットロスと推定されています。Alibaba Cloudは技術的な詳細の公開について保守的な傾向があり、この事例でも詳細な事後分析報告書（ポストモーテム）は公表されていません。

学び

・単一ゾーン集中は「高可用性の錯覚」を生む　

同一リージョン内でも複数のアベイラビリティゾーンにサービスを分散し、ゾーン障害を想定した自動フェイルオーバー設計を行う。Alibaba Cloud自身もマルチゾーン展開を公式に推奨しており、コスト増はともなうが障害時の影響を最小限化するために必須の原則です。

・クラウド側の迂回設計の有無を事前に確認する　

今回の短時間復旧はAlibaba Cloud側の迂回設計が機能したからこそです。自分たちのサービスがどのクラウド機能を利用していて障害時にどこまで自動復旧できるのかを、障害シナリオ単位で把握しておく必要があります。

・「ダウンタイム38分」でも後処理は数時間かかる　

短時間の障害でもキャッシュ整合性の破損、ログの欠損、不完全なセッション状態の修復など、復旧後の後処理作業が相当量発生します。復旧手順書には「障害対応」と「後処理」を別フェーズとして明示的に含めておく。

事例2　Alibaba Cloud シンガポールAZ-C データセンター火災（2024年9月10日〜16日）

詳細

2024年9月10日午前10時20分（北京時間）、Alibaba Cloudのシンガポールリージョン アベイラビリティゾーンC（以下AZ-C）でネットワークアクセス異常が検知されました。原因は、Alibaba Cloudが利用していたDigital Realty SIN11データセンター内で発生した火災でした。消防設備が作動したことで作業員がデータセンターへ入館できなくなり、高温環境下でネットワーク機器が次々と異常をきたしました。

Alibaba Cloudは状況報告の中で「建物内への立入ができず温度上昇を止める手段がない」「AZ-C全体が完全なネットワーク断絶に至る可能性がある」と異例の警告を発し、AZ-Cにサービスを展開しているユーザーに対して即時の移行を促しました。この事故はByteDance（TikTokの親会社）傘下のサービスにも障害を引き起こし、9月16日時点でもハードウェアと機器の復旧作業が継続していたことが記録されています。

対応のポイント

Alibaba Cloudの対応で評価できる点は、「最悪のシナリオへの移行」を先読みした早期の警告発信です。「完全断絶の可能性がある」という段階でユーザーに移行を促す判断は、事後に影響が拡大した場合の信頼低下を避けるうえで大変重要でした。

一方で厳しい評価が避けられないのは、管理基盤（コントロールプレーン）がAZ-Cのみに配置されていた構造的問題です。2022年の香港データセンター障害でも繰り返し指摘されてきた問題であり、単一ゾーンに管理基盤が集中しているとゾーン障害が管理基盤全体の喪失を招き、復旧操作そのものができなくなるリスクが残ります。

原因

データセンターの物理的な火災です。重要なのは、火災そのものよりも「火災後に設備を管理できなくなる」構造が被害を拡大させた点です。入館不能時のリモート制御手段や、消防設備が作動した際のサーバー保護措置がデータセンター選定基準に含まれていなかったことに疑問が問われる事例です。

学び

・物理リスクはクラウドのSLAには含まれない　

火災・浸水・停電など物理的なリスクは、クラウドのSLA（サービス品質保証）の保証範囲外です。特に海外リージョンを利用する場合、利用先データセンターの耐火・耐水設計や入退館管理体制を、サービス選定の段階で確認する必要があります。

・管理基盤のマルチゾーン化は最優先課題　

自社のオンプレミス設備においても、管理基盤（監視・認証・ジョブ実行基盤）を本番と同じゾーンに置かない設計原則を徹底する。ゾーンが落ちたときに管理手段まで失うと、復旧できない状態に陥ります。

・「即時移行してください」に即応できる準備を平時から整える　

今回のような緊急移行指示を受けた際に動けるかどうかは、平時の準備次第です。移行先の選択肢、DNSのTTL設定、データのポータビリティを、事前にシナリオとして設計しておく。

2つの事例に共通すること

今回の2事例はどちらもAlibaba Cloudが絡んでいますが、障害の性質はまったく異なります。事例1はネットワーク設定に起因する単一ゾーンの障害で、38分という短時間で収束しました。事例2はデータセンターの火災という物理的なリスクが発端で、復旧に1週間近くを要しています。

共通するのは「単一ゾーンへの依存が被害を拡大させた」という構図です。事例1ではユーザー企業側が単一ゾーンに集中展開していたことが問題で、事例2ではAlibaba Cloud自身の管理基盤が単一ゾーンに集中していたことが問題でした。どちらも「可用性の設計」を誰が、どの層で、どこまで責任を持つかという問いを突きつけています。

クラウドを使うことでインフラの管理負担は大幅に減りますが、「クラウドを使っているから可用性は確保されている」という思い込みは危険です。ゾーンやリージョンをまたいだ設計、平時からの切り替え訓練、そして物理層のリスク把握まで、設計の責任はユーザー側にも残ります。

参考情報

記事一覧を見る