2006年10月14日

NTTさんの障害対策を考察する

こちらのエントリーで、NTTさんの大規模障害が、どのような障害理由であったかを簡単に考察しましたので、続いてどのような対策をすべきかを考察してみようか思います。


■高負荷について
まず、一つめの原因である高負荷状態となった点について、補足事項を含めて、考察します。



●パケット流量
さて、SIP網におけるパケットの流量なのですが、実は、「え?そうなの???」という事実があったりしますので、その辺から、解説します。

・SIPパケット
SIPベースのIP電話がどのように通信を行うかは、「こちら」をみていただくとよいかと思います。

下の方に有る図の 3〜4, 7〜9 の矢印が、通話を開始する(セッションを張る)SIPパケットとなります。この 9 矢印まで終わった時点で、通話が確立されます。
そして、これ以降は、1〜3分おきくらいに(キープアライブ処理のため)、同様のやりとりをします。
パケットサイズ的には、矢印1つ、1000Bytesくらいです。




・RTPパケット(音声、映像などのメディアパケット)
通話開始後は、音声を相手に届けるために、RTPという音声パケットが流れるのですが、これが、上記図の 10 の矢印に相当するモノになります。
パケットサイズ的には、256Bytes前後のパケットが1秒間に50個、流れます。(256Bytes * 50packets/s * 2(全二重) = 4kBytes/s = 32kbps です。すなわち、ISDNが64kbps(同時2通話)なのと同じとなります。)

で、上記図をよく見ていただくと、セッションを張ったUA同士で直接やりとりされます。すなわち、P2Pでやりとりされているのです!



・パケットのまとめ
要するに、SIP網において、サーバを経由するパケットは、最初の通話開始の(セッションを張る)SIPパケットとキープアライブのSIPパケットだけで、その他のパケットは、P2Pで通信されるのです。(正確には違いますが、大枠としてはそういう認識でOKです。)
すなわち、サーバを経由するパケットは、通話全体のパケットの数%にも満たないような量しかないのです。


逆に言うと、(通話全体から見れば)ほとんど、パケットが通らないはずのSIPサーバが、高負荷状態となって落ちているのです!!!
それくらい、SIPサーバというヤツは、負荷に弱いわけです。




●原因
負荷に弱い原因は、下記の理由と思われます。

・Text型パケットである
・可変長のパケット、ヘッダーである
・何らかのDBに依存して、ルーティングを行う

という特性があるため、ASIC(チップ)化しにくいのです。それは、ソフトウェアで処理する場合も、よって、ソフトウェアで処理せねばならず、負荷に弱い構造となってしまうのです。
(ASICとソフトウェア処理では、数百倍の性能差は、余裕で出てしまいます。)



■バグについて
つづいて、バグについてですが、ご存じのようにバグというモノは、コードの量に比例して増加し、運用年数に反比例して減っていきます。



●今後のSIP網
現在の通話のSIP網は、今後、NGN(IMS)に置き換えられていく流れとなっています。
すなわち、現在のコードがさらに拡張(増加)され、新規運用となるのです。



●まとめ
バグの性質と今後のSIP網を考慮すれば、当面の間は、バグを取り切ることは不可能ではないかと思います。



■対策
さて、ここでSIP網がどのような構造をしているかを考えますと、NGNがインターネットを再構築しようとしていると言われているように、SIP網というのは本質的にインターネットと同じ構造をしています。

しかし、現在のSIP-Proxy(SIPにおけるRouterの役割をするもの)は、ある発信先への経路情報は、唯一に決定されるという実装になっていることが多いようです。NTTさんの実装がどうなっているかは分かりませんが、経験から言わせてもらえれば唯一に決定される実装になっているはずです。

すなわち、インターネットが安定して稼働するキモである「迂回路」が実装されていないのです。

そして、「迂回路の実装」こそが、SIP網に施すべき安定化対策であると、私は考えています。これにより、「負荷分散」が可能となり付加対策され、「マルチベンダー」になることにより「一つのバグにより全体が落ちる」ことが無くなります。


現状での対策としては、キャリアやISP間で相互接続をして、迂回路を設定できるようにするというあたりが、現実的なところだと思います。
さらに、その先としては、SIP-Proxy自体に迂回設定を実装していくことも考えられます。SIP自体が、セッション層のTransportととしての役割を持っているため、SIP自体をIPに近い機能を持ったRoutingプロトコルとして使用してしまおうという考え方です。
これの具体例としては、SIPベースで、BGPのようなプロトコルを実装してしまうようなイメージです。SIP IXさんが、一番近いところにいるといえるでしょう。

Creative Commons License
This weblog is licensed under a Creative Commons License.