12月22日16時、Skypeが利用できなくなり始めた。始めは影響を受けたユーザは少なかったが、次第に広まり、24時間近くネットワークが停止する事態にまで発展した。1週間後、SkypeのCIOであるLars Rabbe氏は 今回の機能停止の事後分析を行い、何が起こったのかの説明をした。
Skypeか中核部分を第3世代P2Pネットワークに依存している。このネットワークには膨大な数のピアノードとスーパーノードがあり、ひとつのノードには数百のノードが繋がっている。コミュニケーションしたいふたつのノードや複数のノードの間の経路を見つけるための中央ディレクトリが存在しないため、仮想ネットワークはスーパーノードをディレクトリとして扱う。クライアントがSkypeに入ると自身をスーパーノードに登録する。IPアドレスを登録することで接続を確立したい他のクライアントから見つけられるようになるのだ。そして、クライアントは他のクライアントとIMや音声/ビデオのセッションを確立したいときに、スパーノードに問い合わせを行う。対象のクライアントのIPアドレスを取得し、2つのクライアントの間で直通の通信経路が確立されるのだ。スーパーノードはSkypeのネットワークにとって極めて重要なのだ。
また、Skypeはオフラインのメッセージの配送を支援するたくさんのサーバーがある。膨大な未配送メッセージがあることを想定して、これらのサーバーは少し遅れてメッセージを送信する。しかし、Skype for Windows バージョン 5.0.0.152にはバグがあり、この遅延メッセージを受信した時にアプリケーションがクラッシュしてしまう。最新のSkypeやひとつ前のバージョン、Windows以外のバージョンはこのバグの影響はないのだが、50%近くのユーザーが問題はバグがあるバージョンを使っていたということだ。このバージョンはSkype 5の最初のバージョンであり、おおよそオンラインにいた40%のユーザがクラッシュし、30%近いスーパーノードがダウンした。
そして、動作を続けているクライアントや再起動したクライアントはまだ動いているスーパーノードに問い合わせをしたので、問い合わせを受けたスーパーノードは過負荷になった。スーパーノードが過負荷になったときのための保護機能がある。これはクライアントのシステムのリソースを消耗してしまわないようにするためだ。この保護機能によってスーパーノードが次々にシャットダウンしてしまった。その結果、Skype全体が機能停止してしまったというわけだ。
Skypeはスーパーノードなしでは機能しない。サービスを復旧しようとまずは数百のスーパーノードを起動し、それから数千のスーパーノードを起動した。どんなシステムでこの起動を行ったのかは明らかにされていない。おそらく、自前のシステムやAmazon EC2上に展開したシステムを使ったと思われる。ネットワークは作動されたスーパーノードを中心に復旧し24時間後にはサービス全体が復旧した。再起動する必要のあったスーパーノードのほとんどを停止させたが、一部はそのままにしておいた。これはクリスマスでネットワークの利用が盛んなときに何かトラブルが発生した場合に備えるためだ。
本件から得られる教訓は、多くのユーザーは必要がなければ自分のソフトウエアをアップデートしない。Skypeには新しいバージョンがあり、それは問題を引き起こさない。しかし、ほとんどのユーザはバグのあるバージョンを使っていたのだ。SkypeはGoogle Chromeに搭載されているような自動更新の仕組みを検討するつもりだ。
ユーザに‘自動’更新の仕組みを提供することを検討しています。すべてのユーザに最新のSkypeを使い続けてもらうためです。今回のような失敗を再び起こす可能性を低めるためにはこの仕組みは有用だと思います。
もうひとつ教訓がある。それは、ソフトウエアを徹底的にテストしたということを保証するためにできることはすべてやるべきだ、ということだ。Skypeは“システムに影響を与える可能性のあるバグを検知し回避するためのより良い方法を見つけ出すためのテストプロセス”を検討するつもりだ。
そして最後の重要な教訓はオフラインのメッセージを扱うようなネットワークを支援するサーバーの性能についてだ。氏は、“Skypeユーザを支えるコアシステムの性能を定期的に見直し、性能とシステムの復旧力に継続して投資を行うつもりです。”と説明する。
SkypeのチーフブロガーであるPeter Parkes氏によれば、エンタープライズバージョンとSkype Connectは今回の機能停止の影響を受けなかった。