auの障害の件、コアルーターの交換がトリガーになっているのに、記者会見のプレゼンの絵に掲載されていないので理解がしずらくなっているように思う。
発生事象概要 pic.twitter.com/EsNja9dLcp
— Munechika Nishida (@mnishi41) 2022年7月3日
クラウド運用の仕事をしていると、この「コアルーター」という言葉はよく出てきて、メンテナンスによる切り替え切り戻しの作業はクラウド事業者側でよくやってる。二台構成の場合は、以下のように実施する。
***
① 副系のファームウェア、機器交換などメンテナンスを実施する
② 主系から副系に切り替える
③ 動作確認
（もし問題がない場合）
④-a 主系のファームウェア、機器交換などメンテナンスを実施する
④-b 副系から主系に切り戻す
④-c 動作確認・・・完了
（もし問題があった場合）
④-d 副系から主系に切り戻す（至急）
④-e 副系の戻しを行う（ファームウェアの戻し、あるいは機器戻し）
④-f 主系から副系に切り替える
④-g 動作確認
④-h 副系から主系に切り替える
④-i 動作確認・・・完了
***
と、なかなか大変なのである。
今回はコアルーターの交換ということで、①で実施し、②を行ったらそこで正常に動かず輻輳が起こり、その上で④-dを行い切り戻したけれども、今度は輻輳時のエラー多発のため大量の状態不整合がソフトウェア側に起こり、輻輳が止まらなくなった、と理解した。
ネットワークエンジニア的には戻すだけなのだが、一度異常が起こった上位のソフトウェアを正常に戻すためには、ソフトウェアエラーが連発する状況を食い止める必要がある。
端末がつながろうとするときに、セッションを管理するデータベース側と、VoLTE交換機の持っている情報で状態が食い違うために再送が発生し、それでネットワーク流量がいつもより数倍の状態が収まらないと会見ではおっしゃっていた。だから、物理的にネットワークの流量制限を行い、長期化したのだと。
この、ハードウェア基因で基盤の状態が急激に変わった際、ソフトウェア側で不整合が起こり正常性チェックが邪魔をして動作不良になる、というパターンは何度か経験がある。
往々にして、基盤側とソフトウェア側は、担当者も設計者も別である。
トリガーは基盤側なのでとても申し訳ないのだが、不具合がソフトウェア側に移るので基盤側にできることがない。今回では、できることはルート変更や流量制限のところぐらいである。しかし、そんなことをしても、そもそも大量に不整合がソフトウェアで生じている状態では、まずは「正しい状態」に近づけないといけない。
今回は、データベースとVoLTE交換機の状態をまず一致させないと、また再送のための輻輳が起こるのでソフトウェア側の修正が必要になる。しかし基盤側ではかたずを飲んで作業を待つしかないのである。
当初の情報ではVoLTE交換機の障害と聞いたがこれは違いそうだ。システム設計時に、基盤の不具合が基因してネットワーク帯域上で輻輳が起きた際に、大量にデータベースとVoLTE交換機の間に不整合が起こるとは想定していなかったか、想定していたとしても再送で復旧すると考えていたはずである。しかし、それをさばくことができなかった。だから今、半手動で作業を継続していると思われる。
今回の件、基盤側では機器交換の手順は、ごくごく一般的なものだったんだろうと思う。開発環境でも十分テストをした機器を入れたのだろうし、かつそれで問題が起きたから戻すのも適切に行われた。ただ、その短い間に起こった輻輳を契機にソフトウェア側がメタメタになってしまった。だから、恒久対策としては、輻輳が起こってデータベースとVoLTE交換機の間の情報が不整合が起こった時に、通信量を抑えるトランザクションを開発しなきゃいけないんだろうな、と思う。
もしくは、ソフトウェア側でこのような大量再送時の通信量急増に耐えうる帯域を基盤側で用意するか。しかし、それならどれだけ性能を高めれば起きなくなるかを算定するかは非常に難しい。本番の状況は、本番でしか起きないからである。
似たような仕事をしているので、いろいろとお気持ちがわかってしまう。使う人は、「使えない、何でこんなに復旧に時間がかかるのか。再発防止策をすぐに。」となるだろうが、特に基盤の性能問題と、それを超えた際のソフトウェア不具合というのは、運の悪さも手伝ってなかなか短期的に解決するのが難しい。
特に、4Gもサービスインから10年で、機器交換も今後たくさんあるだろう。なかなか舵取りも大変だ。
そうだ、「1:00～3:00の間、au携帯電話はメンテナンスのため停止します」ではどうか、ダメか。本当大変なシステムだと心底思う。
