■活かされなかったNTTドコモの大規模障害
はじめに、今回の通信障害および復旧状況についての詳細を以下の記事よりご確認ください。

【関連記事】au通信障害が完全復旧と7月5日15時36分に発表！発生時間は61時間25分、問い合わせは9万6723件。au・UQ mobile公式Webストアも再開

今回の通信障害のポイントは、大きく4つあると考えられます。

・2021年10月にNTTドコモが起こした大規模通信障害と似た状況で発生した。

・NTTドコモの事象を受けて対策を強化していたにも関わらず状況を悪化させてしまった。

・通信のアクセス集中による輻輳が発生する中、統合データベース（DB）とVoLTE交換機との間でDB情報の不一致が起こり、データ確認のための過剰アクセスが起こって統合DBが機能不全に陥った。

・状況が改善したのち、ユーザーが所有するスマートフォン（スマホ）の再起動などが必要な場合があったにも関わらず、KDDIやメディアによる周知徹底がなされなかった。

2021年のNTTドコモの大規模通信障害では、

(1) IoT機器向けの通信設備を交換する際、IoT機器の位置情報の登録作業に問題が発生。

(2) 状況改善のために一旦元の設備へと戻そうとした際、IoT機器が一斉に位置情報の再登録のための通信を行ったことで重度の輻輳が発生。

(3) その後、多数の一般ユーザーにも影響のある大規模障害へと発展。

このような経緯で障害が発生しました。

今回のKDDIの大規模障害の初期段階では、

(1) メンテナンスの一環としてトラフィックルートの変更作業を実施中にVoLTE交換機にて不具合発生。

(2) 一部音声トラフィックが不通となっていることが判明し、当該音声トラフィックの切り戻しを実施。

(3) 切り戻し作業によって音声通話のアクセスが集中して輻輳が発生。

このような状況となっていました。

当然ながら、KDDIとしてはNTTドコモの前例から音声通話の輻輳を避けるべく、VoLTE交換機の負荷軽減策や加入者DBの負荷軽減策などを行います。

恐らく、ここまでの手順は危機管理マニュアルの通りに順調に進んでいたと思われます。



ところが、ここから想定外の事態が発生します（厳密にはすでに発生していた）。音声通話のトラフィックを制限したにも関わらず、統合DBにおいて高負荷のアクセス集中が止まらず機能不全状態が続いたのです。

ここまでの流れは問題発生から2時間程度であったにも関わらず、その後統合DBの機能不全が加入者DBからのアクセス集中と、VoLTE交換機からの異常な過剰信号が統合DBの機能不全の原因と判明し、加入者DBからの負荷軽減策やアクセス問題のあるVoLTE交換機の切り離し作業を開始するまでに、実に約12時間を要しています。

今回の事象が如何に「まったくの想定外」であり、原因を突き止めるまでに多くの時間を要したのかが分かります。



その後、さまざまな対策を取りつつ最終的にDBの不一致を起こしていたVoLTE交換機の切り離しが完了したのは、事象発生から実に60時間後のことでした。

その後、約1時間ほどでトラフィック状況が改善して無線規制の解除が行われたことを考えると、「DB不一致による応答要求の過剰送信が原因」という可能性が早々に出されていれば、かなり早い段階での対処が可能だったのではないかと考えるところです。



■通信機器の爆発的増大が障害からの復旧作業を困難にしている
今回のDB不一致からの応答要求の繰り返しという事態は、実は十分に想定可能だったものです。

NTTドコモの事例を見れば、機器交換によって位置情報（つまりはDB情報）登録に不具合が起こり、再登録のための応答要求が繰り返されたことが大きな原因でした。

通信機器や通信インフラはそれぞれの「個」を判別するため、位置情報に限らずさまざまな個別情報をDBで管理することで統制されています。

しかも、その通信機器の数は指数関数的に膨れ上がり続けています。私たちが使っているスマホや携帯電話はもちろん、IoT機器などもすべてそのように管理されています。

そしてそれらの機器の個体情報の発信は、基本的に自動で行われます。一定時間通信が行われなかった場合や通信のメンテナンス後などに自動で送信される仕組みは、通常であれば非常に効率的で便利ですが、いざ大規模な通信途絶などが起こった場合、通信の回復後に一斉送信が始まりトラフィックの輻輳を起こしてしまうのです。

トラフィックの輻輳状態が続けば続くほどにDB情報にも異常が発生する可能性は増加します。

KDDIによればVoLTE交換機によるDB不一致からの過剰送信が、輻輳によって発生したのかそれとも以前から異常があったことで輻輳が発生したのかは判明していませんが、どちらにしても通信機器の自動管理機能が状況を悪化させたという点では変わりないでしょう。



今回の事象を受けて、KDDIはDBおよび各種通信サービスの正常性確認や事象発生時において該当機器の切り離し作業を行う手順を加えると発表しています。

本来であればNTTドコモの事象の段階で想定し、対策をマニュアル化しておくべきところでした。



■蔑ろにされたユーザー対応
そしてもう1つ、早急にマニュアル化し周知徹底して欲しいと考える危機管理があります。それは「障害発生時および障害復旧時のユーザー側の対応手順」です。

今回、ユーザーを最も混乱させたのは長期間の通信障害そのものではなく、その障害発生中にユーザーとしてどうすべきなのかを知る手段が非常に少なかったことです。

例えばテレビメディアを始めとした大手マスメディアは障害の規模や影響範囲ばかり報道していましたが、ユーザーが取るべき行動や障害復旧時に行うべき行動について丁寧に解説していたところがあったでしょうか。

例えば今回のような大規模通信障害の後は、往々にしてスマホに応答セッションが残った状態となっており、それが原因で通信トラフィックは復活しているのにスマホからは通信ができないといった状況が生まれます。



実際、この状況に遭遇して通信トラフィックの復旧後にも「スマホで通信ができない」、「復旧したとか嘘つくんじゃない」と憤慨しているユーザーをSNSなどで散見しました。

状況を解消するには単にスマホを再起動すれば良いだけなのですが、それに気が付かない人は数多くいます。もしテレビニュースなどで「通信復旧後はスマートフォンを再起動してください」と復旧以前から繰り返し注意を促していれば、無用な混乱とクレームは避けられたはずです。

KDDIはこの点について「公式サイト上では案内していた」と釈明していましたが、そもそも通信障害発生時に公式サイトを見に行くという考えに至らない人や、公式サイトを見る手段のない人、膨大な情報が掲載されている公式サイト上から障害復旧時の対応方法などを正確に見つけ出せる人がどれだけいるでしょうか。

KDDIに限らず、大企業には非常に綿密な危機管理マニュアルが存在し、非常事態において迅速に行動できるよう訓練も行われていますが、ユーザー側の対応方法や対処マニュアルは蔑ろにされ続けていると言っても過言ではありません。

テレビメディアやラジオ、新聞媒体などと連携し、障害の規模や状況ばかりではなく、障害に対してユーザーあるいは一般消費者全体がどのような行動を取るべきなのか、事象の詳細や規模の実況よりも優先して伝えるべきではないかと考えるところです。



■モバイル通信が社会を形成する時代の危機管理を
通信は今や社会経済の基盤です。かつてはそれでも有線通信が主軸でしたが、モバイル通信が3Gから4Gそして5Gへと進化していく中でその役割も多様化と増大を続け、今では常時人々の生活を維持するIoT機器があらゆる場所に溢れています。

そういった機器を管理・統制するためのプロトコルもまた、障害発生時および復旧時にどのような動作をすべきなのか、改めて議論する必要があるようにも思います。

現在の通信においては、通信障害が発生することは最大の問題ではありません。NTTドコモの事象もKDDIの事象も、小さな障害や不具合からの復旧時に大量の機器からの応答要求に対応しきれず飽和してしまったことが最大の事故を引き起こしました。

「どのように障害を起こさないのか」ではなく、「どのように障害からの復旧作業を安全に行うのか」、そして「障害復旧時に人々が取るべき行動や方法をどのように伝えるのか」が、今問われています。