目次

事件だらけの2022年7月夏

連続する通信キャリアの障害

原因について

さらに深堀り、長引いた要因は？

「がんばれau」？

一般ユーザーの対応法と企業の事前準備

システムトラブルは永久に（なくなりません）

事件だらけの2022年7月夏

今回は別のテーマを書く予定だったのですが、2022年7月2日～5日にかけて起こった「au通信障害」をテーマにします。と、書き始めたタイミングで、姉さん事件です(*1)。7月8日に安倍元首相が銃撃され、病院で死亡。参院選当日の7月10日には、八王子にカマ男(*2)が出現。何が起こった日本。熱さのあまりおかしくなったのでしょうか？コロナの新規罹患者も東京で10000人を越えました(7月12日)。これは3月16日以来で、4カ月ぶりらしいです。さらに、21日には東京で30000人も突破、新記録です。全国では18万人超え。18万というと東京立川市、神奈川小田原市あたりの人口と同じです。

<図表22-1 仮面ライダーに登場したカマキリ男>

【参考】朝日新聞デジタル：カマを持って改札通ろうとした男、駅員さすまたで制止　京王八王子駅
（https://www.asahi.com/articles/ASQ7B671XQ7BUTIL024.html）

参院選挙についても語りたいですが、選挙システムについては「第拾四夜　選挙で悩む管理者の夜」で記述しています。参考にしてください。さらに、今回の選挙では「特例郵便等投票」が可能になりました。新型コロナウイルス感染症で宿泊・自宅療養等をしている方で、一定の要件に該当する方のみ、郵便での投票が可能になる制度です。一種の不在者投票(*3)といえます。
【参考】総務省HP 特例郵便等投票
（https://www.soumu.go.jp/senkyo/senkyo_s/news/tokurei_yuubin.html）

あ、重大なことを忘れていました。7月14日には、「第16回システム管理者感謝の日イベント」がありましたね。さらに、続報待ちですが、7月21日にはMicrosoftTeamsで障害発生。メジャーな会議ツールでもあるので、企業やセミナー会社、在宅勤務リーマンに影響が多々あったようです。スケートの羽生結弦選手のプロ転向宣言が7月19日。24日夜に桜島噴火。そしてプロ野球では、史上最低の勝率（4月14日にＮＰＢ史上最低勝率0.63）を叩きだしていた阪神タイガースが、前半戦折り返し時点（7月24日）で借金返済し、2位タイ。とらほー。

いろいろなネタがありすぎておなかいっぱいなのですが、ここはITに関連する「au通信障害」にしようと思います。久々に大きなシステムトラブルです。

連続する通信キャリアの障害

今回の障害はau/KDDIでしたが、近年通信キャリアでの通信障害/システムトラブルが多発しています。

三大キャリア全てで発生。そして、影響時間も延びています。回線数や影響範囲も多くなっています。これは、スマホや携帯電話の普及を意味しています。今回は、auだけでなくau網を使用している各種のシステムにも影響が及びました。

＜図表22-2 影響回線の数＞

原因について

ソフトバンクではLTE交換機のソフトウェア(*4)、ドコモではネットワークの設備工事、今回のauではルーターの交換が障害発生の起因です。純粋にソフトウェアな問題というよりも、ハードウェアや内蔵ソフト、手順が問題といえます。今回のau障害については、最初の起因は機器交換→ルート変更されず【音声通信15分不通】→切り戻し判断→復旧後のアクセス集中+再接続要求で【輻輳(*5)】。

＜図表22-3 KDDI障害説明1＞　　　　　　　　　＜図表22-4 KDDI障害説明2＞

ネットワークに詳しい方であれば、分かると思いますが、ネットワークの通信応答には「再接続要求」がよくあります。ネットワークがつながらない場合によく、「再度、接続します」「3分後に接続します」などのアクションです。
そして、次に発生したのは加入者データベース。加入者（＝契約回線）毎に端末IDや位置情報など更新しているデータベース。このデータベースにも輻輳が発生。正確には、負荷低減策実施中のVoLTE交換機とのやり取りで輻輳が発生。そして、この加入者データベースの負荷低減を図ると、（複数ある）加入者データベース自体の同期がとれなくなり、さらに障害が波及。

彦〇「障害のドミノ倒しや～」

この障害復旧をしている間に、次の障害を引き起こすパターンは、過去の「みずほ障害」と似ています。特に2011年に発生した障害。東日本大震災の義援金に起因するトラブルでした。振り込み出来ず→オンラインへの障害への派生、そしてバッチ処理にも影響。現代のような複数のシステムが関連する状況ではよくあることかもしれません。
また、システム復旧が間に合わず、影響が拡大することも最近の傾向としてみられます。ということは、システムの障害復旧には「時間」が必要、いや「短時間」で対処することが肝要となってきています。

【参考】「第七夜　みずほ障害で悩む管理者の夜」

さらに深堀り、長引いた要因は？

今回のシステム障害ですが、そもそもの発端はルーターの交換という定期的な作業から始まっています。そして異常が発生したから、切り戻し。つまり前の機器に戻すという作業を行いました。ここまでは本当に通常の作業です。まったくおかしくありません。しかし、切り戻った後の再接続要求による負荷、そしてその負荷低減を行った後に、データベースの同期が未完全、が問題です。うん、難しいです。そこまで想定して復旧をしないといけない。かなり困難です。最初から負荷分だけでなく超負荷を想定してシステム基盤を構築しなくてはいけない。さらに、普通に負荷分散されている機器が1つ故障ではずれた場合、流量制御をしつつ対処する必要がありそうです。

以下に7月4日20時から行われたオンライン記者説明会の一部をピックアップします。

以上【参考/引用】「au通信障害」KDDIの会見質疑詳報、なぜここまで障害が長引いたのか？　スマホ時代の課題とは？
（https://k-tai.watch.impress.co.jp/docs/news/1422344.html）から

吉村氏の発言のように、今回の復旧は現状の動いているサービスに極力影響を与えないように、徐々に復旧するという方法を取ったようです。この方法が正しいかどうかはわかりませんが、方向性は同意します。思いっきり一部を切断などして復旧をねらっても、二次災害や想定外のさらなる輻輳が発生する可能性が高そうです。そもそも、システム全体の構成やデータやトラフィックの流量を想定しきれていれば問題ないのですが、現時点では難しいでしょう。

「がんばれau」？

今回の障害で、ネットでは「使えない」などの苦情だけでなく、「障害復旧のために頑張っている人に感謝。応援します」などの応援メッセージが多数寄せられたことが注目されています。でもシステムの中のヒト的には、なんかピントがずれている気がします。このメッセージって、よく自然災害などで自衛隊の方々やコロナ禍での医師や看護師にむけての応援と同等のつもりなのでしょうが、システム開発やトラブル復旧の現場では、ごく少数の「わかる」エンジニアが徹夜で活躍するだけです。決して人海戦術はできません。応援はありがたいのですが、そこは勘違いしないでください。システムの全体像や影響範囲などをしっかりと知らないと手を出せない分野です。駆け出しエンジニアが多数いてもなんにもならない状態です。さらに、動いて当たり前のシステムの復旧は本当にストレスが溜まります。感謝の声より金に換算してほしいのが本音です。そして、ネットでの感謝の声は、対処している非駆け出しエンジニアなスペシャリストには、たぶんリアルでは見えていません。ほとんどの開発現場では、特に情報流出を気にするような会社/部署では、私物スマホの持ち込みが禁止のエリアもあります。特に重要システムに関連するエリアは厳しいです。キーボードを叩き、ホワイトボードに影響や残課題を書き込み、少数の優秀なエンジニアで対策をブラッシュアップする現場。感謝はありがたいのですが、静かに見守りましょう。

一般ユーザーの対応法と企業の事前準備

今回のネットワーク障害を受けて、そのようなケースでの一般ユーザーの対処案についてです。ある媒体で、ある有識者が以下のような意見を述べていました。一般人がこのような事態で対処できることは3つ

・複数のキャリアのスマホを所持（＝2台持ち)
・一台の端末に複数のキャリアの契約(*6)
・WI-FIの所持

対処方法としては１つのことしかいっていません。「1つのキャリアだけでなく複数の経路を持っておけ」だけです。「通勤時の電車遅延に対処するために、別経路を考えておけ」と全く同じです。でも、一般人にはまず無理ですよね、複数契約やモバイルなWI-FIの所持。無料のWI-FIスポットも、たくさん人が集まれば繋がり難くなりますし。
ただ、企業がビジネスの継続のために複数回線を持つのは必要なことです。俗にいうミッションクリティカルなシステムの構築では、絶対に複数回線、複数電源のシステムを構築します。バックアップサイトも作ります。でも、個々人でそのような対処はかなりきついですよね。一人BCP(*7)かよ、とツッコミたくなります。

システムトラブルは永久に（なくなりません）

さて、暑い最中でのシステムトラブル。いらいらがつのったと思います。それも実質2日以上、土日を含んでの障害です。待ち合わせでのスマホ使用はできず、じっと涼しい自宅でステイホームされた方も多かったと思います。しかしシステム関係者はよく知っていると思いますが、システムトラブルは確実に起こります。ゼロにすることはできません。そのような事態が発生したときに、いかに早く復旧させるか、は現状人海戦術では不可能です。エンジニアのセンス・知識・経験は必須です。このようなトラブルに対応できるようなエンジニアが身体を壊さぬよう、祈っております。
では良き眠りを（合掌）。

「決定をあせってはならない。ひと晩眠ればよい知恵が出るものだ」by アレクサンドル・プーシキン