au障害(1)

年末年始の重要時を襲ったauの通信障害、トリガは通信量の増大だった。
ドコモにしても同様に通信量の増大がトラブルのトリガになる。

何故これが予見出来なかったのか。
おそらくはチェックシステムがあったり事前試験はするのだろうが、実際のトラフィックを発生させる事が出来ないのでミスが見つからない。
机上でのテストやシミュレーションテストで発見出来ない穴に落ち込んでしまうわけだ。

SBMの場合はiPhone普及が早かった事、加入者数が少なかった事、ネットワークが遅かった事で急激なトラフィック上昇は避けられたのではないだろうか。
ドコモは通話料金恵上げを狙うXiシフトの加速でスマートフォン需要を喚起した。
Xiエリアなどau以下なのだが、スマートフォン自体のトラフィックが障害の元となった。
特にGoogleに加えてドコモの同期や通信、ドコモでは制御信号と呼んだが、それらが帯域ではなくセッションを使い果たした。

端末やサービスを作っている部署と基地局やネットワークを整備している部署の認識に差があった。
ネットワーク屋は帯域を広げる事で問題は起きないと認識していたのかも知れない。
F&Fサーバを自宅に置いていた時、情報メール送信時にNATメモリが不足してDNS引きが出来なくなる障害が起きた。
メール送信に要する帯域もCPUパワーも不足はなかったが、メール送信先の情報取得に問題が生じたわけだ。

そもそも民生用のルータはそんな利用を想定していない。
もっとも最近では複数台のPCでGooglemapなどを見るとNATメモリが不足する自体も報告はされている。
多くのポートをいっぺんに使って速度を上げようとする場合はNATメモリが不足する。
NATメモリが不足すると不足した分の通信が出来ないので遅延が生じる。
メール送信の為のDNS引きならばリトライが起きるので遅延が多少増えるだけだ。

ルータを変更してNATメモリ量が少し増えたのと、NATメモリの解放条件が改善された事でこの障害は回避出来た。
勿論ベストなパフォーマンスが出たとは言えないが、異常動作はなくなった。

移動体通信の場合はリアルタイム処理が基本なので遅延許容度が大きくはない。
待たせておくと待ち行列が増えすぎてしまうからだ。
その為ある所でセッションを破棄するが、すると移動機は即座に再リクエストをかけてくる。

続く…