無線にゃん、ここ数年大規模通信障害を起こし、まことにもうしわけ
という話ではなくて。昨日のauとか、去年くらいのドコモとか、大規模通信障害というやつが起こっていますね。しかも、起こったらとことん大規模。
実際、この辺は避けようがないというのが実態だと思うんです。そもそも論ですが、携帯電話ネットワークというのは、どういう風に作られているのか、というと、超たくさんの基地局をたくさんの制御局に収容してそれらをほどほどの数の交換局に集約して、みたいな感じに作られているものですよね。LTE以降、この辺はIPアクセスによるフラットなネットワークを志向、なんていうことも言われていますが、実際に物理的にネットワークを作ろうとすると、どうしてもどこかに「呼処理」が集中するポイントが生じてしまいます。
呼処理というのは、簡単に言えば、ある携帯電話が正当なものであることを確認しその通信要求が正当なものであることを確認し適当なポリシーのもとに通信リソースを割り当てる、一連の処理のことです。ある一人の加入者が全国どこでも使えるようにする、という要求を満たす場合、すべてのネットワークノードは必ずつながっていなくてはなりません。さらに、その加入者の通信オプションや課金を正しく扱うためには、その加入者の情報がすべてのノードで整合性ある形でアクセスできなければなりません。今回のauの障害でもキーワードで出てきた、加入者情報の不一致云々、の話です。
仮に加入者情報サーバを二重化していたとしても、その二台のサーバの間に「データの不整合」が生じてはならないので、二台の間では常に整合性のためのやり取りが行われます。また、今回の障害の原因と言われているVoLTE交換機(IMS)も同じように「ある加入者の唯一性」を保証しなければ正常な処理はできません。そうした唯一性の保証が必要なサーバ類をたくさん置いて障害が起きても一部にしか影響が出ないようにする、というのは当然どこのキャリアもやっているわけですが、では、それらのサーバ間を直接メッシュ接続できるか? というと、そんなことはもちろん無理です。メッシュ接続というのは、例えば2台と3台のサーバ群同士をつなげる場合、6本の線を直結させる、というやり方。今や加入者情報サーバだのIMSだのは何十台という規模で、メッシュ接続するとなると数百本の接続が必要になります。もちろん、論理的にこれができることは当然ですが、じゃあ物理的にできるか、というと、一つの筐体に何百本のケーブルをつないでそれぞれが独立した回線で全国につながる、なんていうことは無理です。回りくどく書きましたが、物理的にはどこかで集約するための巨大なルータ的なものに入ることになります。このルータにはもちろんその他いろんな通信が論理的には別々の回線のようにふるまいながら収容されています。
さて、もしこのルータが壊れたら。当然、このルータも冗長化されていますから、即座にスタンバイ系に切り替わるわけで、一見、あらゆる呼処理が集中していても問題がないように思われます。ただ、この冗長化した二台のルータは、つながっています。比喩でもなんでもなく、冗長、というのは、その二台を束ねる何らかのコントローラの上で成立するものです。このコントローラ機能は、古くは独立した装置だったりしましたが、最近では二台のルータ間やルータの下位ノードとの間で成立している冗長化プロトコルのステートマシンという論理的な存在が担っています。なんにしろ、その二台の状態を把握して障害時に正しく切り替え処理を行う頭脳の役割が存在し、それを介して必ず冗長した二台のルータはつながっている、ということです。
そしてこの頭脳そのものは、冗長化できません。だから、もしこの頭脳に何らかの変調が起きると、冗長機能が働かなくなります。もちろん、その状態でもルータ自身が正しく動いていれば問題ありませんが、この頭脳が変調を起こすような設定の誤りやバグというのは、えてして、片方のルータが落ちたときに顕在化するものです。つまり、あらゆる呼処理が集中しているルータ自身、どんなに完璧な冗長を組んだとしても全台破綻、ということがありうるわけです。これは隕石が落ちてくるほどの低い確率ですが、でも実際に隕石は落ちてくる。だから、そうした事態に備えた訓練を各キャリアは欠かさないわけです。
こうした呼処理が集中する場所で通信断が起きると、先ほどの「唯一性」と「整合性」を重視するサーバたちは一斉にうごめき始めます。データの不整合が発生した可能性がある以上、何とかして最新の情報を得なければならないからです。また、そういった状態になると、端末側も通信の接続や再開ができないために、何かあったのかもしれない、ということで、通信の手続きを最初からやり直そうとします。こうしたことが雪だるま式に膨らんでいくことで設備の処理能力が枯渇し、なおかつ「唯一性」に自信が持てなくなった各種ノードは通信手続きをやめてしまうわけで、大規模な障害に至るということです。
こうした大規模な障害を回復させるには、まず、入ってくる量を減らすところから始めます。つまり、基地局で「規制」をかけます。これで、端末が何度もアクセスすることを防ぎます。次に、「唯一性」と「整合性」を回復させなければなりませんが、これも、冗長を組んだたくさんの装置を一台ずつ同期させていくという地道な作業になるはずです。なおかつ、その同期させようとするデータが大きすぎるとこれまた設備負荷になり、安全弁が働いて途中で止まり、芋づる式にデータすべてが再び不整合、なんていう面白いことが起こったりします。面白くないですねすみません。そんなことを考えると、一度集約部分で混乱が起きるとその終息にどのくらい時間がかかるかというのは全く誰にも読めない、と思われるわけです。
実際、最近は小規模な障害は比較的減っていますが、ごくまれにこういうどでかいのが起こる感じですよね。それは、障害を防ぐ仕組みがどんどん進んでいるから、ということの裏返しでもあります。標準化でも障害耐性というのは大きなテーマで、障害を防ぐ、障害が起きた時も小規模で済ます、起きた障害が速やかに収束する、そうした仕組みを標準の中にどんどん作り込んでいるので、実は日常的に小さな障害は起こってるんだけど利用者にばれるほどにまで大きくならない、みたいなところはあります。で、最後に残ったのが、こういう物理的にドカンとくるやつ。こういうのもしっかりと機能と収容加入者数をばらして分散化していけばいいわけですが、いかんせん、「唯一性」の問題があり、どこかにどうしても集中する場所が生じることになります。仮にそういうのを物理的にばらして置いたとしても、その物理的に離したサーバの間を加入者が移動するような場合には情報を交換する必要があるわけで、やっぱりそこでは最低二台の間での集中は起こります。ついでに言えば、昨今の官製値下げの影響で、各社ともぎりぎりまで設備を集約して効率化しようと頑張っています。三社ともアホみたいに利益を出しているように見えますがそれぞれがそれぞれに帳簿上の利益を減らせない大人の都合があってしわ寄せは設備投資に向かうわけです。
こういうことが起こらないようにするにはどうすればいいのか? という話については、まあぶっちゃけ、完全に物理的に隔離された冗長ネットワークがあればいいんじゃね? ってことになります。簡単に言えば、別キャリアです。もちろん別キャリアにしてローミングで救済する仕組みにしても、そこに「ローミング接続」があったら無意味です。なので、ローミング情報も何らかの形で隔離して持っていく必要があります。13桁のパスワードをかけたUSBとかで。というのは冗談にしても、実際、一つのキャリアの全域である加入者の唯一性を保証するという条件でネットワークを物理的に分断することはできないので、最悪他キャリアにローミングできる仕組みを全キャリアでしっかりと話し合った方がいいよね、と私は思うのです。もちろん、大障害の時にローミングアクセスが集中してローミング先も落ちた、なんていう本末転倒なことは必ず起こるので、ローミングでの利用については相当に絞った形にするしかないでしょうが。で、そのローミング利用料をお互いに払うようにすれば、ある意味、障害のリスクをカネで解決してるわけですから、お互いいろいろと楽になるよね。
ということで、無線にゃん、今後一切このような長期間の障害を起こすことのないようしっかりと見直しを・・・いや、別にしなくていっか。ではまた来週か来月か来年か♪
今回のKDDIは災難でしたね…
いくら冗長化されていても不具合を起こすと突然おかしくなり、復旧まで時間がかかる経験があるので、今回の記事は成程と思いながら拝見しました。
大規模障害のニュースの中で、緊急通報も使えなかったとのことで、最近システムが変わり、こういった障害発生時に使えなくなったという話を目にしたのですが、もし本当でしたらこの辺りも解説頂けると嬉しいです。