KDDIの通信障害で起きた「輻輳」とは何か?
2022年7月2日にKDDIで大規模な通信障害が起きました。
きっかけとなったのは、コアルータと呼ばれる機器の定期メンテナンス(機器交換)でした。
ここで何らかのトラブルが起き、KDDIがサービス提供するauを始めとする多くのサービスに接続できない(利用できない)状況となりました。
7/2の深夜に事故が発生し、最終的な復旧確認は7/5の夕刻と実に3日半の時間を要しています。
今回は、この事故の概要と「輻輳(ふくそう)」について解説します。
1. KDDIの大規模通信障害
このトラブルは7/2の深夜に発生し、7/3中は電話や通信がしづらい状況が続き、7/4の午後にようやくほぼ復旧した(最終的な復旧確認は7/5の夕方)というものです。
この事故はコアルータと呼ばれるネットワーク機器を定期メンテナンスで交換する時に起きました。
余談:
コアルータというのは、ルータの一種です。
ルータはネットワーク機器の一種でご存知の方も多いでしょう。
実際、家電量販店でも売っていて、数万円も出せば上位機種が買えます。
一方、コアルータは大規模ネットワークの根幹を支えるルータです。
家庭用ルータとは全くの別物で一台で○千万、○億円の世界です。
ところが、このルータ交換の過程で予期しないサービス不良が起きます。
具体的にはVoLTEという機器を使った音声サービスで一部が不通となり、それが続いたところから担当者は切り戻しを決断します。
余談
切り戻しというのは、作業を中止して作業前の状態に戻すことです。
予定していた作業を取り消すわけですから、その日の作業は完全に無駄です。
また、切り戻し作業にも失敗リスクはあります。
担当者にとって切り戻しは大切な保険ですが、やりたくない作業の一つです。
ところが、切り戻しを行ったところ、大量の再接続依頼を受けることになります。
これは当然のことで、前段の通信断によって通信エラーとなった端末は、再接続依頼をしてきます。これが1件や2件ならどうということもありません。
ですが、通信断になった数万や数百万の端末から、ほぼ同時に依頼が来ると、ネットワークがひどい渋滞状態になります。
これが今回のトラブルのキーワードとなる「輻輳」です。
この輻輳の発生により、さらにKDDIの不幸が続きます。
VoLTEサービス側でのエラーにより、他システムとの不整合が発生します。
具体的には、VoLTE側が保持している現在位置情報と加入者DBと呼ばれるデータベースとの間の不一致です。
接続依頼が来た時には、先に加入者DBの位置情報データを、次にVoLTE側の位置情報データを更新する手順となっていました。
加入者DBの更新は問題なく行えるのですが、VoLTE側を更新しようとしても接続エラーになってしまうと、更新が行えません。そのため、本来なら両方が更新されるべきなのに、加入者DBだけが更新され、VoLTE側が置いてけぼりを食う結果となります。
そのため、両者で矛盾が生じ、システムはそれを解消という余計な仕事をも抱え込むことになります。
通信断という比較的シンプルなトラブルから始まったトラブルのはずが、輻輳を生ずることによって、国内のauの大半の回線を巻き込む通信障害になってしまったというのがこの事故の特徴です。
2. ルータの交換ってそんなに難しいの?
何となく保守用の機器交換と聞くとこんなイメージの方が多いのではないでしょうか。
1)新しい機器を設置する
2)新しい機器の電源を入れる
3)接続用のケーブルなどを繋ぎ直す
4)旧い機器の電源を落として、回収する。
ですが、ルータは通信機器です。
通信はいつ発生するかわかりません。このやり方だと、3)のケーブル交換時は通信が切断されます。
コアルータを必要とするほどの大規模ネットワークではものすごい量のデータが往き来します。1ミリ秒の切断でさえ、何千何万の通信障害になりますから、こんな雑な作業が許されるはずがありません。
ですので、新しいコアルータへの切り換えには例えば次のような手間をかける必要があるのです。
1)あらかじめ新しいコアルータを適切に設定し検証する
2)新しいコアルータを本番環境に設置する。
3)新しいコアルータの電源を入れる。
4)新しいルータが接続されたことを各ネットワーク機器に通知
5)旧いルータが切断されることを各ネットワーク機器に通知
6)新しいコアルータと周辺サーバの動作を確認する。
7)旧いコアルータへの依頼が来なくなったことを確認する。
8)旧いコアルータの電源を落として、回収する。
交換と言いながら、実際には2つのコアルータを同時稼動させ、除々に旧機種への依頼をフェードアウトさせるわけです。このシナリオ作成は知識のあるネットワーク技術者でないとできず、かなりのスキルが要ります。
余談
「1)あらかじめ新しいコアルータを適切に設定し検証する」とは?
ルータの設定は非常に繊細で、多岐にわたります。
その設定を間違うと目的サーバに辿り着けません。
設定の正しさ検証が必要ですが、とても目視でできる作業ではありません。
そのため、検証用の擬似環境を用意し、そこで設定内容を何日もかけて確認するのです。
これをネットワーク屋さんやSEは検証作業と呼んでいます。
3. 輻輳
さて、今回のトラブルで一躍、有名となった「輻輳」という現象です。
一般的にはネットワークが「パンクすること」や「渋滞している状態」といった説明がされています。もちろん、現象のイメージはわかるでしょうが、実際に何が起きているかがわかりにくい説明です。
パンクといったって、ネットワークの帯域までは使えるんじゃないの?と思いますし、渋滞といっても別に通信速度が遅くなるわけではありません。
一体何が起きているのでしょうか?
4. 輻輳が起きるメカニズム
輻輳は「ふくそう」と読みます。どちらの文字も車扁(くるまへん)の文字で日常的に使う漢字ではありません。
筆者自身もネットワーク上でのトラブル用語としてしか使ったことがなかったのですが、一般的な言葉だったようです。
辞書によりますと、「輻」は車のスポーク(自転車などのタイヤを支える細い棒)のこと、「輳」は集まることだそうで、「輻輳」は「一箇所に集中して混み合うこと」。
さて、ネットワークの輻輳も、確かに一箇所にデータが集中することなのですが、さらにやっかいな特性があります。
それは本来のネットワークの能力が発揮できなくなる点です。
例えば、100の通信を処理できるネットワーク回線があり、通常は20の通信が発生しているとします。
これが40や50になっても一時的に待たされたとしても大きな問題にはなりません。
ですが、80、90ともなると処理が追い付かずエラーになるケースが出てきます。
これが続出すると、100ある通信路の多くが「依頼を受けてはエラーを返す」という無駄な通信に費やされてしまいます。
さらに、依頼数が増えてくると「エラーを返す」ことすら滞りがちになります。
こうなると100ある通信路の一部しか使えない(他は返信が来ず膠着状態になる)状態に陥ります。
まさにこの状態が「輻輳」なのです。
一般的には、「100の通信路があるのなら200の通信ができないのはわかるけど、100の通信は論理的にできるよね、それ以下になるなんてありえないよね」とお考えだと思います。
ですが、ネットワーク回線で輻輳に陥ると、100の能力のある回線でも、10、20の通信しかできなくなります。
5. 輻輳の解消が難しい理由
輻輳にはさらに「解消が難しい」という面倒な特徴があります。
なぜなら、エラーとなった端末は同じ処理を再度リクエストするからです。
エラーがエラーを呼ぶ状態です。
端末が悪気なく再リクエストをすることで、輻輳はより深刻化されます。
では、解消は不可能なのでしょうか?
実は輻輳の解消方法というのは極めてシンプルです。
要は依頼回数を減らせば良いのです。
依頼が来なければネットワーク回線が混む理由がなくなりますから、輻輳は自然解消します。
実際、今回のKDDIの事故では、通信制限という形で接続依頼の50%を意図的に門前払いにするという対応を取られました。
これによって、輻輳は除々に解消の方向に向かい、発生から2日半経った7/4の日中にはほぼ解消されたようです。
逆に言うと、通信の半分を制限してからでも輻輳の解消には半日を要したということになりますから、発生してしまった輻輳への対処がいかに難しいかを如実に示しています。
6. まとめ
7/2にKDDIで大規模な通信障害が起きました。
機器の交換時に何らかの不具合が起き、通信断が発生しました。
その後元に戻したところ、今度は復旧を求めた大量の通信により、輻輳が発生。
さらにその影響でVoLTEサーバ側と加入者DB間のデータ不一致が発生。
終束宣言までに3日半もの時間を要してしまったトラブルでした。
2021年10月に発生したドコモの通信障害の場合でも輻輳の発生と解消が大きな課題でしたが、今回も同様に輻輳の発生が事故をより深刻なものとしました。
輻輳というのはネットワークで起きるトラブルの一種で解消させるには、通信量を減らすしかないというやっかいな現象です。
実際に今回のケースでも、KDDI側で50%の通信制限を長時間にわたって行うことでようやく輻輳が解消できたようでした。
今回の事故については、KDDI側の対応の甘さを指摘する声もあるようです。
しかし、輻輳制御については、まだまだ研究も少ないようですし、実効的な対策があるわけでもありません。筆者としては、KDDIは現状で取れる手段、取るべき対策は取っていたと感じます。
KDDIの会見では、今回の事故を活かした輻輳の研究を進めるという言葉もありました。
これを機に輻輳という魔物に対抗できる銀の弾丸の誕生を楽しみにしたいと思います。
次回もお楽しみに。
(本稿は 2022年7月に作成しました)
本Noteはメルマガ「がんばりすぎないセキュリティ」からの転載です。
当所はセミナーなどを通して皆さんが楽しく笑顔でITを利用いただくために、 難しいセキュリティ技術をやさしく語ります。
公式サイトは https://www.egao-it.com/ です。
この記事が気に入ったらサポートをしてみませんか?