スポンサーリンク
新年度が始まった4月3日を襲ったのは、ANAのチェックイン障害と、フレッツ光の広域障害だった。
フレッツ光の障害は緊急電話を使えない時間もあり、総務省に先ごろ報告書が提出された。その内容を見ていく。
光回線についてのまとめはこちら。
NTT東日本のWEBに詳細な情報が出ているのでそれを引用する。
まずはどういう事象だったかというと、2023年4月3日 午前7時10分～8時53分まで(一部ひかり電話は10時8分まで)通信サービスが利用できない、あるいは利用しづらい状況になった。
ここでいう通信サービスはフレッツ光によるインターネットアクセスだけでなく、ひかり電話も含まれる。
影響範囲は下表のとおり。首都圏を直撃した。
フレッツ光障害 230403 出典：NTT東日本 以下同じ
※NTT西日本でも同時に障害が起きている。
障害の原因はサイバー攻撃ではなく、NTT局舎内の加入者収容装置にソフトウェア不具合が内在していたものがあり、条件がそろったときに不具合が発生して障害となったそうだ。まあ、よくある話だが、普通は出荷前に片づけておいてくれればよかった。おそらく条件がレアすぎて出荷前はわからなかったのだろう。
NTT東日本のWEBに発生原因が書かれているので引用する。
マルチキャスト受信において、複数の条件が重なったことに起因し、加入者収容装置（パケット転送部）が再起動を繰り返し、当該エリアの一部のお客さまの通信サービスがご利用できない、またはご利用しづらいという状況が発生。当該パケットの受信が停止したことで、サービスが順次復旧。
当社・通信機器メーカーによる解析の結果、加入者収容装置［該当機種］のマルチキャストの内部処理において、ソフトウェア不具合が内在しており、それが原因であることが、判明しております。
フレッツ光障害 230403
要約しながら補足すると、こういうことになる。
トリガになったものはマルチキャストパケット。これは1対多の片方向通信によく使われる方式で、オンラインで行われるイベントにも使われる。
ZoomやTeamsのWEB会議では多対多で行われる場合は会議ブリッジが必要になる。会議ブリッジは有限のリソースなので、例えば1万人の参加する会議というものは実現が難しい。
一方でマルチキャストを使うと、音声、映像のパケットはマルチキャストという特殊なパケットになるが、途中のルータによって制御、分岐されて、1対多の通信を実現できる。
ルータの機能で処理できるので、会議ブリッジは不要になる。ネットワークにかける負荷が少ないので大規模なイベントではこれを使っていると思われる。
今回の事象では、マルチキャストの通信が入ってきたことで始まった。
マルチキャストのパケットが原因というところはにわかに信じがたいので、おそらく何かほかに条件があると思う。
とにかく受診したために上図のパケット転送部が中身を評価した際に不具合が発生した。この不具合は致命的なものだったらしく、パケット転送を行うソフトウェアがおそらくクラッシュして停止した様だ。
このような重要なインフラを支えるハードウェア、ソフトウェアは通常は冗長構成、つまり2つのシステムを同時に用意し、稼働系が処理を行う一方で待機系は可動系がクラッシュした際に新稼働系になるべくずっと待っている。
NTTのフレッツサービスのシステムの可用性をどのように実現しているかはわからないが、上記のような冗長構成、あるいはもっと高度な方式でサービスを止めないような仕組み作っていると思われる。
パケット転送部が冗長構成なので、＃１がクラッシュしたことを契機に待機系の＃2が起動して、受信したマルチキャストパケットの処理を始める。
このとき、切り替えのため一瞬だけサービスが止まる。通常はこれは一瞬なので今回のような大規模なサービス停止には至らない。
しかし、待機系が稼働系になって処理を始めたものは、問題発生原因のマルチキャストパケットだ。
待機系も稼働系と同じソフトウェアで通常は動いてるので、当然新稼働系もクラッシュするだろう。
新稼働系がクラッシュすると、新待機系(旧稼働系)に切り替わって、これもまたクラッシュする、と永遠に続いたのではないだろうか。
マルチキャストであるため、パケットが受信者を収容する加入者収容装置に転送された。同じソフトウェアを使う装置であった場合は、同様にクラッシュしていたと思われ、このため広範囲になったのだろう。
上記推測の中で「稼働系と待機系の間でクラッシュを続けた」と書た。この仮定が正しいとしたら、マルチキャストに続いて処理を待つ他のユーザのパケットが処理されず大規模障害になった、は成立する。
一方で受信したマルチキャストパケットを永久に処理できなかったら、いったいどうやって復旧したのだろうと思う。
おそらくパケット転送部が載ったサーバを電源断するなどでマルチキャストパケットを消滅させたのではないだろうか。
NTT東日本が提出した再発防止策は下表のとおり。
フレッツ光障害 230403 再発防止策
有効な対策は、
装置再起動を繰り返さないようにするための「フェールセーフ機能」等の共同検討
というところだろう。
メーカと検証するとか通信状況を確認する、というものは一見有効に見えるが未知の問題に対しては効果がない。
フェールセーフ機能をもっと実装することで、さらに言えば想定されるケースのフェールセーフを先回りして実装すれば未知の問題にもある程度対応できるだろう。
この手の問題はまだまだ出てくる。そして知見が蓄積されて製品は改良され、品質は向上する。
しかし新製品が出たら新たな問題が内包されて、同様の大規模障害が発生する。その繰り返しだ。
終わりなき人間とソフトウェアの戦い。AIにより終止符が打たれるのだろうか。
PR
