昨年12月23日午前1時頃からほぼ24時間にわたって続いたSkypeの全世界的不具合．このようなSkypeの全世界的不具合は，2007年8月にも発生しており，その時にSkypeはその信頼性に深い傷を負った．特にビジネスでSkypeを使用していたユーザーは，Skype使用の断念を検討したはずだ．
しかしその後Skypeは安定的な運用が続き，信頼性はほぼ回復されていたと言ってよかった．不具合を体験した多くのSkypeユーザーは，同社が大規模不具合から得られたデータを元に，何らかの対策をシステムに対して行ったものと考えていたことだろう．ところが…
一般ユーザーのSkype需要が高まるであろうクリスマスイブの前日に，悪夢は再びよみがえった．
その時，ご存じのように，TwitterはSkype不具合のツイートに埋め尽くされ，サーバは過負荷状態となり，一時的にはクジラ状態（過負荷によるシステムダウン）に陥る場面もあった．Skype側が不具合の状況について，Twitterを使って報告を行ったことも，この過負荷状態の一因だったかもしれない．いずれにしてもSkypeは他のサービスをも巻き込みながら復旧にもがき苦しんだ．そして発生から20時間後，ようやくこの未曾有の全世界的不具合は終息を迎えることになった．
昨年12月29日SkypeのCIOである Lars Rabbe が，そのブログ上に「今回の不具合に関するお詫びと今後の対策」を発表した．そこには，今回の不具合の発生過程が書かれていた．それによると
- 22日：オフラインのインスタント・メッセージをサポートするサーバクラスターが過負荷状態に陥った
- Skype側は過負荷状態のサーバを使用不能（注：日本語訳では「機能不全」となっているが，原文では「disabled」）にしたり，あるいはサーバからクライアント要求を取り除くことで対処
- Skypeクライアントに対する上記サーバからの反応が遅延（上記対策が間に合わなかったため）
- Skype for Windowsクライアントのバージョン5.0.0152（注：全スーパーノードの２５％～３０％を含む）にはバグがあり，この反応遅延を処理できずにハング
- 多くのユーザーが上記クライアントを一斉に再起動
- 上記のサインイン処理のために，生き残っているスーパーノードネットワークに通常の100倍のトラフィックが発生
- この負荷に対して耐えきれないスーパーノードは，自己防衛システムを発動（注：おそらく他のノードからの接続拒否）
- 処理できない負荷は，生き残っている他のスーパーノードに転送され，同じくそのスーパーノードも過負荷状態になり，やはり自己防衛システム発動．
- 以下スーパーノードネットワークはデス・スパイラルに陥り（注：日本語訳は「肯定的なフィードバック」となっているが，原文は「positive feedback loop」であり，「正のフィードバック」が訳としては正しいと思われる），SkypeのP2Pネットワークにカタストロフィが訪れる
- Skype側が数百のメガ・スーパーノードを投入（注：投入の正確な日時は不明）
- 23日昼：全ユーザーの15～20%しか回復されていないため，数千のメガ・スーパーノードを投入
- 24日0時頃：大多数のユーザーの接続が回復
- 24日昼：グループビデオ通話リソースもスーパーノード化して投入
- 24日夕方～夜：スーパーノードネットワークの安定を確認
- 25日：上記リソースをグループビデオ通話用に戻し，ある程度のメガ・スーパーノードをネットワークから切り離す（注：一部は安定性確保のため残す）
というものだった．最初のオフラインメッセージ処理用サーバのオーバーロードが，なぜ起こったのかは記載されていない．ホリデーシーズンの影響もあったのかもしれない．その後の流れは，比較的単純だ．
この記事にはスーパーノードの機能についても，以下のように解説されている．
スーパーノードは通常のノードと比較して、ディレクトリーとして機能したり、他のスカイプ・クライアントをサポートしたり、それらの接続をサポートしたり、それぞれのスーパーノードごとに数百のピア・ノードをまとめたローカルな一群を作成する点において重要
上記に書かれているとおり，スーパーノードはSkype通信の接続中継
（ルーティング）を行うのが主な役割だ．このいわゆるP2P通信は，サーバ経由通信とは異なり，負荷分散が簡単でインフラ投資が少なくて済む等のメリットを持つ．ただ今回の記述で，スーパーノードにディレクトリ機能があることを私は初めて知った．ディレクトリ機能とは，一般的な使用においては，メールアドレス
（連絡先）等のデータベースを意味する．Skypeにおいては，おそらく通信相手のネットワーク上の位置を特定する機能だと推測される．またスーパーノードは数百のピア・ノード
（スーパーノードに所属する通常のノード）を束ねていることから，スーパーノードは，この所属ピア・ノードのディレクトリ情報を持っているのだろう．通信相手のネットワーク位置特定は，おそらくスーパーノード同士のネットワークへの問い合わせによって解決されると想像される．また問い合わせ負荷を軽減するために，それぞれのスーパーノードはキャッシュを持っているに違いない．
さらに
オペレーション上のパラメータが期待値の範囲内でない場合、スーパーノードには自らを守り、それらをホストするシステムに不利益となる影響を避けるためのメカニズムが組み込まれています。
この自己防衛システムの詳細については記載されていないが，おそらくノードダウンに陥りそうな負荷がスーパーノードにかかったときに，他のスーパーノードからの問い合わせを拒否する機能と想像される．つまり自らをスーパーノードネットワークから切り離し，最悪な状態であるノードダウンを避ける方法だ．これならば，自己防衛システムを発動したスーパーノードに所属するピア・ノード同士の通信だけは，確保できる可能性が高い．またおそらく自己防衛システム発動スーパーノードは，定期的にスーパーノードネットワークに接続し，他のスーパーノードからの問い合わせ数をモニタリングし，負荷が許容範囲であれば，ふたたび問い合わせを受け付ける「自己防衛状態解除」システムも組み込まれているのだろう．
Skypeでは，この自己防衛システム発動のトリガーとなる負荷閾値を，現在のSkypeネットワークからの観測値とコンピュータ・シミュレーション等により，決定したのだろう．ただしご存じのように，P2Pネットワークは非線形でダイナミックな複雑系であり，ネットワーク挙動の完全な未来予測は不可能だ．今回，自己防衛システムは結果的には，スーパーノードネットワークを崩壊させる一因ともなってしまった．
ネットワーク挙動の完全制御は本質的に不可能であり，カタストロフィーに落ちる可能性を0にすることはできない．ネットワーク運営者にできることは，コストの許す限り，様々な，互いに独立した緊急時対策を，常に準備しておくことだろう．自己防衛システムによるスーパーノードネットワーク維持が失敗した時，Skype側にはまだ（最後の）切り札が残っていた．
それは，「メガ・スーパーノード」インスタンスの投入だった．ブログ記述によると
P2Pネットワーク上に何百ものスカイプ・ソフトウェアのインスタンスを作成し、複数の専用スーパーノードの働きを担わせました
（おそらくアウトソーシング仮想マシン上だと思われるが）Skypeは一時的に数百のスーパーノードをP2Pネットワーク上に投入し，壊滅状態にあったスーパーノードネットワークを支えようとしたわけだ．ただ…，この呼称には疑問が残る．なぜキロ
(K=数千)にも満たない
数百のスーパーノードで，メガ
(M=数百万)なる呼称をつけたのだろう？確かに「キロ・スーパーノード」では頼りない印象を受ける時代ではあるが，もともと想定されていたスーパーノード投入数の単位は，数百ではなく，数百万ではなかったのか？
いずれにしても，緊急時シミュレーションをSkype側では行っているはずであり，緊急事態に対するメガ・スーパーノードの適切な投入量，その効果予想，さらには対策コストをも事前に計算していると思われる．しかし残念ながら数百という初期の投入量は，今回の危機に対して適切ではなかった．これが，SKypeネットワークの回復に24時間近くかかった要因となったのは間違いないだろう．
ブログ記事によると，SKype側は今後の対策として
- パッチ及びバグ修正済みクライアントの提供
- 新しい自動更新方法の検討
- 障害検知のスピードを上げる
- ベータテスト方法の検討
- 中核システム容量を定期的に見直す
をあげている．これらの対策は当然と言えば，当然のことだ．
ただ自分としては，
メガ・スーパーノードの投入タイミングと投入量の判断について，全く記載されていないことに疑問が残る．もし迅速に数千単位あるいは数万単位のメガ・スーパーノードが投入されていたのであれば，もっと早く障害から回復できたのではないか？一端，崩壊してしまったP2Pネットワークが再び正常化するまでの時間は，線形ではないはずであり，それをSkype側も熟知していたはずだ．初期に大量のメガ・スーパーノードが投入されていれば，カタストロフィに陥る前に，SKypeネットワークを安定させることができ，しかもすぐにメガ・スーパーノードを離脱させ，メガ・スーパーノード維持コストをも押さえることができたかもしれない．Skype経営陣の判断は適切だったのだろうか？それとも「緊急時対策コストを最小限に抑えるために，カタストロフィ発生から復旧までには，24時間かけてよい」という危機管理ポリシーが存在するのだろうか？
サービスのダウンタイム時間と，ユーザーの信頼度の関係も，線形でないように私には感じられる．Skype側は「復旧がクリスマスイブに間に合って良かった」としているが，信頼を再び裏切られたユーザーの失望感やSkype使用に対する不安が，クリスマスイブに影響しないとでも言うのだろうか？今回の不具合対策発表の他に，
有料ユーザーには30分無料通話クーポンを配布しているようだが，無料ユーザーには何もないのだろうか？実際，無料ユーザーの中でも一部のユーザーは，スーパーノードとしてSkypeネットワークを支え，それに貢献しているユーザーもいるはずだ．
これを機に，Skype側はスーパーノードであるクライアント上に，それを明示し，サービス貢献度
（処理量・サービスアップタイム）に応じて，無料通話クーポンやポイントなどの何らかのキックバックを与えてはどうか？そうすれば，そのユーザーはスーパーノードをできるだけ維持するように，以前よりも努力するだろう．
いずれにしても，今回上げたSkype側の対策案はまだ不十分に思う．危機管理にはいくらでもコストをかけることはできる．したがってどこまで危機対策を行うのか，明確な危機管理ポリシーを経営陣は採択する必要がある．AUをはじめとして，Skypeが今後の携帯端末やスマートフォンに採用されていくのは間違いないだろう．そうなればSkypeネットワークはさらに大規模な社会インフラとなると同時に，その複雑度を増し，挙動予測はますます難しくなる．そのような状況下で今回のような大規模な不具合が発生すれば，社会的混乱すら招きかねない．Skype経営陣には，社会インフラ企業としての自覚を持って，危機管理ポリシーの再検討に着手していいただきたい．
