ringoさん
VIEW
加入者DBの不一致とは auの通信障害で「加入者データベースの不一致」が話題に
au通信障害の流れ
2日1:35 コアネットワークのメンテナンス作業中にルーターで障害が発生
1:50 一部音声通信が不通になっていることが判明。メンテナンス前の状態に戻す
2:17 貯まったトラフィックで音声交換機がパンク状態に。その後、加入者データベースもパンク
3:00 通信規制を実施 https://t.co/gHmS5LYRxZ
au通信障害、ざっくり言うと、
ルーター交換で不具合発生（15分で復旧）
↓
復旧後に通信リクエストが貯まり、交換機がパンク
↓
交換機のパンクが加入者データベースのパンクに波及
↓
加入者データベースで“不一致”が発生
という4段階の混乱があり、復旧まで時間がかかっている、という流れです
IoT回線での影響数は150万回線と少なめですが、これは障害の影響がIoT回線の中でも「SMSを利用する回線」に限られているため。コネクティッドカーの制御回線などは別系統で管理しているため、影響がないとしています。
まとめ。ルーターの交換したが設定がおそらく間違っていた。それによりVoLTE 交換機での輻輳が発生した。輻輳が発生すると利用者側からの再送要求が行われる。それの影響で加入者データベースにも輻輳が発生した。その影響で加入者データベースと VoLTE 交換機でのデータの不一致が発生した。地獄だ。
iPhone は音声が繋がらなくてもデータは繋がる、Android は音声が繋がらないとデータが繋がらない端末もある。それとは別に輻輳制御を行ったため接続しづらくなった。トリガーはルーター交換による設定ミス（の可能性）輻輳発生。
時系列を見ると問題に気付いたタイミングが 1:50 で 2:00 には社長には連絡が言ってたとのことなので、エスカレーションは的確に行われていたし、むしろおかしいレベルで早いので現場判断がすごい。
加入者データベースに書き込んでから VoLTE 交換機にデータを書き込むが加入者データベースに書き込めても、VoLTE 交換機が輻輳により障害が発生していたので書き込めなかったので、データの不一致が発生した。
au障害ざっと書くと
①メンテ作業でNWのルート変更した時に音声不通が発生。
②ルート変更切り戻しを実施。
③ユーザーの再接続処理多発でVoLTE交換機で輻輳発生→VoLTE交換機、無線側で流量制御対処実施。
④再接続処理多発で加入者DB側でも輻輳発生→負荷低減対処(西日本と東日本のNW切り離し)
通信は仕組みとして最初に加入者DBにアクセスしてステータスを書き、その後VoLTE交換機にアクセスしてそこで呼制御するんだけど、加入者DBとVoLTE交換機の間でステータス不一致だと通信出来ないと。
輻輳発生してることによりリクエスト捌けてないから、
加入者DBへのステータス書き込みに失敗した状態でVoLTE交換機にアクセスしにいって状態不一致で通信不可ってのが発生してると。
これって、復旧作業としてはおそらくトラフィックの推移見つつ、流量制御の解除してく位しか出来ないと思うんだけど。
となると、復旧見込み時間がどんどん伸びるのもわからなくないよね。
結局トラフィックが落ち着くの待つしかないんだから。