auの通信障害に思うこと
au通信障害の影響度は大きかった
2022年7月2日未明、auの通信障害が発生し、auケータイを使用しているユーザーだけでなく、交通機関やアメダスにも多大な影響をもたらしました。
全面復旧したのは発生から86時間後、およそ3日半も断続的な通信障害が続いていたことにあります。
筆者はスマートフォンをデュアル運用しており、メイン回線はNTT docomo回線を使用するMVNO（仮想移動体通信事業者、いわゆる格安SIM事業者）、サブ回線でauのpovo2.0を使用しており、メイン回線がノーダメージだったので今回の通信障害においては直接の被害はありませんでした。
しかし、ちょうど通信障害が発生した1時30分過ぎ、仕事で夜間作業をしていたところ、他社の方と連絡を取らなくてはならなくなり、連絡したところ繋がらず。別の関係者と話をしたところauケータイが繋がらないということが判明、他の手段にて連絡を取り合い、予定時間よりも多少遅れはあったものの、一応作業を終えることができました。
そしてその日の夜は数名の友人たちとの食事会だったのですが、初めて訪問する店で、地図アプリを使用して目的の店にたどり着きました。他の参加者の何名かはauケータイを使用しており、筆者同様、地図アプリを使用してくる予定であったようですが使えないので家を出る前にPCで地図を表示して写真撮影してきた人もいれば、地図を印刷してきた人もいました。
また、電子決済アプリもネットワークを介して行われるため、auネットワークを利用していた場合は現金、またはクレジットカードでの支払いをしたかと思います。
しかし本障害は、先にも書いた通り公共施設等への影響もあり、KDDIの記者会見での発表では
物流関係：宅配便の配送状況更新不可、配達ドライバーへの連絡不可
自動車関連：「つながるクルマ」向けのサービス一部利用不可
気象関連：観測点の一部でデータ収集不可
銀行関連：店舗外の一部ATMが利用不可
交通関連：一部空港でのスタッフ用無線機が使用不可
と、私たちに身近なサービスなどが利用できない状況であったことが明らかになりました。
携帯電話ネットワークは、私たちの重要インフラであることを再認識する事態となりました。
システムを構築する立場として思うこと
私はシステムを構築することを生業としています。その立場においてまず思ったことは「ネットワークの二重化はしていなかったのか？」でした。
私たちがお客様にシステムを構築する際は、お客様のご要望とご予算を伺って、できること、できないことを双方で取捨選択して、双方合意の上で最終要件を決定して、開発に入ります。
その際に双方で悩むことの1つに「冗長化（二重化、多重化）」があります。何か障害が発生した場合、事前に用意したバックアップでシステムを運用することです。冗長化はシステム全体で行なってもいいのですが、切り離せる部分毎に主系副系で冗長化し、主系が動いているときは副系は最小限の動きにとどめる、いわゆるコールドスタンバイにしておくことで費用を抑制します。（障害時に主副の切り替えに時間をかけることができないシステムの場合は常に両方稼働させる、いわゆるホットスタンバイを提案します）
今回、回線業者であるKDDIがシステム構築するうえで基本的な冗長化していなかったのでしょうか？これも記者会見を見た限りはネットワークの冗長化はしていたように思われます。
なぜ、冗長化が機能しなかった？
ではなぜ今回のネットワーク障害で冗長化が機能しなかったのか？それは「副系に切り替わるような障害が発生したわけではなく、長時間の通信規制（流量制限）が発生した」からだと思われます。通信規制は行っているものの、主系が使える状態なので切り替わらず、ずっと主系で頑張っていたようです。
今回の障害の最初の原因はネットワークの交通整理をする「ルーター」の交換のようです。ルータはハードウェアなので、一定期間の時間経過を以って新しい機器に交換する必要があります（EOS／EOL対応）が、この新しいルーターに不具合があったようです。
この新しいルーターの不具合を起因に、その先の通信機器からアラートが発生、15分間の一部通話不可事象が発生したため、古いルータに戻す「切り戻し」を行ないます。切り戻し後に、15分間溜まっていた通信が一気に流れ込み、ルーターの先の通信機器にアクセス集中する「輻輳」という状態になります。この輻輳状態を解消するために流量制限がされてしまうことになったようです。
さらに二次的障害として、加入者情報を管理するデータベースにデータ不一致が発生してしまい、この不一致を解消する作業に時間がかかったようです。
システムを運用する立場として思うこと
弊社ではシステムを開発した後の運用も担当しています。その立場としてもいろいろと思うことがあります。それは「機器交換の時の様々な不具合を想定していなかったのか？」ということです。時間と費用があれば、定期的に行なっている機器交換であってもリハーサルを実施するべきでしょう。リハーサルを実施したからと言って本番で１００％成功するという保証はありませんが、リスクを低減することができます。仮に今回の交換機器を使ってリハーサルをしていたらルーターの故障が検知できていたかもしれません。
また不具合を想定した「切り戻し」のリハーサルも実施していたら、もしかしたらですが、輻輳を未然に防げたかもしれない、また輻輳の解消をもう少しスピーディに進められたかもしれません。
いずれにしても、機器交換を実施する際の計画の甘さというものが、今回の事象を招いたといっても過言ではないと思います。しかも同じような障害をNTTdocomoが2021年10月21日に起こしており、総務省から「重大事故」認定されていたにも関わらず、それを他山の石としてしていたのではないか？と思わざるをえません。
障害は起こるものとして考える
作業というものは人間が実施するものなので、どうしてもミスをゼロにすることはできません。その前提で前述した作業リハーサルを実施する、何かしらの不具合が発生することを前提として冗長化する、ということは常に考えておくべきコトです。
ただこれはシステムを構築したり運用する企業だけでなく、我々システム利用者側も考えておくべきだと思います。冒頭で書いた通り、筆者は主系回線と副系回線を別キャリアにして二重化しています。友人はキャリアごとのスマホを保有していると言っていました。
もちろん滅多に発生しないであろう障害に備えて、お金を払って保険をかけておくことに抵抗があるかと思います。しかしお金をかけなくても、「こういうことが発生したらどうすればいいか」を考えて、シミュレーションしておくことで、万が一の際の対応の早さは全く違います。
ちなみに筆者は、街中でdocomo、auの両方で通信障害が発生した場合を考え、オフラインでも利用できるWiFiマップをインストールしてみました。
最後にPR
冗長化やリハーサルという「万が一の不具合発生のための保険」を考えたらキリがありません。先に記述した通り、弊社でシステムを提案させていただく際は、予算とスケジュールをヒアリングさせていただき、できること、できないことを双方で取捨選択して、双方合意の上で最終要件を決定して、開発に入ります。開発後の運用においても、システムの運用状況を踏まえたり、時代に合わせたシステムの最適化を提案させていただくこともあります。
対障害性の高いシステムを構築、運用を心掛けている弊社にご興味が湧きましたら幸いです。もしご用命、相談等がございましたらfusl_info@sios.comにご連絡ください。
また、当社ではシステムの障害を監視し、稼動系に障害が生じた場合に待機系に自動的に切り替えを行うことでシステムダウンタイムを短縮し、ビジネス損失を最小限にするHAクラスターソフトウェア「LifeKeeper」、稼働中のサーバーのデータを待機系サーバーへリアルタイムにレプリケーション（複製）するソフトウェア「DataKeeper」もございますので、ご興味がございましたらご連絡ください。