KDDI障害の教訓。サーバーインフラの「真の冗長化」とは何か

普段何気なく使っているスマートフォンが、突然繋がらなくなったら。想像するだけで少しゾッとしますよね。僕自身、過去に通信障害に巻き込まれたとき、連絡手段はおろか、地図アプリも電子決済も使えなくなって、街中で途方に暮れた経験があります。現代社会において、通信インフラは電気や水道と同じくらい、いや、それ以上に重要なライフラインになっていると痛感させられます。

特に記憶に新しいのが、2022年7月に発生したKDDIの大規模通信障害です。あの時、日本中で何が起きていたのか、そしてそこから僕たちが学べることは何なのか。サーバーインフラという、普段はあまり意識しないけれど社会を支えている土台について、少し掘り下げて調べてみました。

なぜ「繋がらない」がこれほど大きな社会問題になるのか

ひと昔前なら、携帯電話が繋がらないといっても「電話とメールが少しの間できない」程度の影響で済んでいたかもしれません。でも今は違いますよね。スマートフォンは単なる連絡手段を超えて、社会インフラそのものになっています。

例えば、キャッシュレス決済が使えなくなれば買い物ができませんし、物流システムの通信が途絶えれば荷物が届かなくなります。さらに深刻なのは、110番や119番といった緊急通報ができなくなることです。他にも、気象庁のアメダス（地域気象観測システム）のデータ送信や、コネクテッドカーの通信など、IoT機器のインフラとしても深く浸透しています。つまり、通信障害は経済活動を停滞させるだけでなく、人命に関わるリスクすら引き起こす可能性があるわけです。

2022年KDDI大規模障害の衝撃と原因

では、あの歴史的とも言えるKDDIの障害は、具体的にどのようなものだったのでしょうか。改めて振り返ってみると、その規模の大きさに驚かされます。

86時間に及んだ混乱の記録

2022年7月2日未明に発生した障害は、全面復旧が宣言される7月5日夕方まで、実に約86時間にも及びました。影響を受けた回線数は最大で約3,915万回線。日本国民の3人に1人以上が影響を受けた計算になります。KDDIはこの障害に対し、契約者への返金などで総額約73億円の対応を行ったそうです。数字を見るだけでも、事態の深刻さが伝わってきますね。

原因は「設備の故障」ではなかった

僕がこの件を調べていて一番驚いたのは、障害のきっかけが機器の故障ではなく、メンテナンス作業時の「作業手順ミス」だったという点です。

報道などによると、コアネットワークと呼ばれる通信網の中枢部分でルーターの交換作業を行っていた際、設定ミスが発生。その影響で、音声通話を制御する「VoLTE交換機」という設備にアクセスが集中（これを「輻輳（ふくそう）」と呼ぶそうです）してしまったのが発端でした。

さらに事態を悪化させたのが「輻輳の連鎖」です。混雑を解消するために通信の流量規制を行ったところ、今度はスマートフォン側が接続を再試行（リトライ）する嵐が発生し、別のネットワーク機器に負荷がかかってしまいました。加えて、加入者情報を管理するデータベース（HLR/HSS）で位置情報の不整合まで生じてしまい、復旧作業が極めて複雑化・長期化してしまったのです。

「二重化していれば安心」という誤解

ここで重要なのは、KDDIのような巨大な通信キャリアが、重要な設備を二重化（冗長化）していなかったはずがない、ということです。当然、機器は冗長構成になっていたはずです。それなのに、なぜこれほどの大規模障害に繋がってしまったのでしょうか。

運用ミスという最大の脆弱性

どんなに高価で高性能なハードウェアを揃えて二重化したとしても、それを操作するのは最終的には「人間」です。人間は必ずミスをします。今回のケースは、まさにその運用プロセスにおける脆弱性が露呈した形と言えるでしょう。

インフラの信頼性を高めるためには、ハードウェアの冗長化だけでなく、作業手順書の整備、ダブルチェック体制の徹底、そして可能な限り人手を介さない自動化（IaC: Infrastructure as Codeなど）を進めることで、「運用」そのものを冗長化・安全化する視点が不可欠なんだと感じました。

切り替わらない冗長構成

もう一つの課題は、「いざという時に予備システムが正しく動くか」という点です。過去の様々なシステム障害の事例を見ても、「メイン機が壊れたのに、予備機への切り替え（フェイルオーバー）が上手くいかなかった」「想定以上のアクセス集中で予備機も一緒にダウンした」というケースは後を絶ちません。

設計図の上で冗長化されていることと、実際の障害発生時にそれが機能することは別問題です。定期的な切り替えテストを行ったり、本番に近い環境で負荷試験を実施したりして、「正常な切り替え」を保証し続ける努力が必要なんですね。

これからのインフラ担当者が考えるべきこと

KDDIの事例は対岸の火事ではありません。NTTドコモでも2021年に工事に伴うサーバー能力不足で大規模な障害が起きていますし、AWSやAzureといった世界的なクラウドサービスでも、数年に一度はリージョン全体がダウンするような障害が発生しています。

カオスエンジニアリングで「壊して試す」

こうした状況下で注目されているのが、「SRE（Site Reliability Engineering）」という考え方や、「カオスエンジニアリング」という手法です。

カオスエンジニアリングは、稼働中のシステムに対して意図的にサーバーを停止させたり、ネットワーク遅延を発生させたりして、システムがそれに耐えられるかをテストする手法です。Netflixなどが積極的に導入していることで知られています。「いつか壊れるかもしれない」ではなく、「システムは必ず壊れる」という前提に立ち、日常的に壊して回復力を高めておくというアプローチは、これからのインフラ管理において非常に重要になってくるでしょう。

クラウド時代の新たなリスク分散

また、クラウドサービスを利用する場合でも、特定のデータセンター（リージョン）や、特定のクラウドベンダーだけに依存するリスクを認識する必要があります。本当に重要なシステムであれば、地理的に離れた複数のリージョンで冗長化したり、異なるクラウドベンダーを組み合わせる「マルチクラウド構成」を検討したりするなど、より高度なリスク分散が求められる時代になっているようです。

この先どうなる？将来展望

サーバーインフラの世界は、今後どのように進化していくのでしょうか。AI技術の発展と絡めて考えてみます。

将来的には、インフラの運用管理がさらに自律化していくと考えられます。AIがネットワークのトラフィック状況やサーバーの負荷をリアルタイムで監視し、障害の予兆を検知したら、人間が介入する前に自動でトラフィックを迂回させたり、予備のリソースを追加したりする。そんな「自己修復するインフラ」が当たり前になるかもしれません。

ビジネス運営側にとっては、運用コストの削減や人的ミスの排除といったメリットがありますが、一方でAIの判断プロセスがブラックボックス化するリスクも孕んでいます。「なぜその対応をしたのか」を人間が理解できるようにする技術も同時に必要になるでしょう。

僕たちユーザー側にとっては、通信障害という言葉自体が過去のものになり、いつでもどこでも繋がることが空気のように当たり前になる。そんな未来が理想ですね。ただ、その裏側では、今よりも遥かに複雑で高度な技術が動いていることを、頭の片隅に置いておく必要がありそうです。

他分野への応用アイデア

今回のサーバーインフラの話は、他の分野でも応用できる考え方がたくさんあります。ここではmogucaのカテゴリに合わせて2つアイデアを出してみます。

応用アイデア1：Web制作における「負荷対策の冗長化」

Webサイト制作、特にアクセス集中が予想されるキャンペーンサイトやECサイトの構築において、インフラの考え方はそのまま使えます。単に高性能なサーバーを借りるだけでなく、CDN（コンテンツデリバリネットワーク）を使ってアクセスを地理的に分散させたり、動的な処理が不要なページは静的サイトジェネレータで構築してサーバー負荷を極限まで下げたりする。これらはWeb制作における「冗長化」や「リスク分散」の具体的なアプローチと言えます。

応用アイデア2：ライブ配信における「配信トラブル回避」

絶対に失敗できない重要なライブ配信の現場でも、冗長化の思想は不可欠です。例えば、メインの配信エンコーダー（映像を変換する機材）がフリーズした時に備えて、全く同じ設定のサブ機を常にスタンバイさせておく。さらに、インターネット回線自体も、有線LANと合わせて、異なるキャリアのモバイル回線をバックアップとして用意しておく。こうした「多重の備え」が、安定した配信を実現するための鍵になります。まさに現場レベルでのインフラリスク管理ですね。

まとめ

大規模通信障害の事例から、サーバーインフラの冗長化とリスク管理について見てきました。重要なのは、高価な機材を並べて満足するのではなく、「運用プロセスまで含めて冗長化すること」、そして「想定外の事態を想定してテストし続けること」だと改めて感じました。

完璧なシステムを作ることは不可能かもしれませんが、過去の教訓から学び、備えることはできます。僕自身、ブログを運営する身として、サーバーのバックアップ体制やセキュリティ対策など、自分事として捉え直す良い機会になりました。皆さんも、身近なシステムの「もしも」について、一度考えてみてはいかがでしょうか。