Life is beautiful

　先日のPhotoShareのスケーラビリティのエントリーに関しては、さまざまなご意見をいただき、とても良い勉強になっている。ただし、少し分かりにくかった部分があると思うのでそこに関して補足しておく。

　サーバーのスケーラビリティに関してはすでに色々なところに書かれているが、今回の私が注目しているのは、どうやってサーバーのキャパシティを増やすか、という話ではなく、サーバーのキャパシティを超えたトラフィックが来てしまった際にどんな挙動をするように設計しておくのが良いか、という話である。

　限られた資源を使って数万人・数十万人の人たちにサービスを提供するかぎり、予想外の急激なトラフィック増加でサーバーに過負荷がかかったりすることはどうしてもあるわけで、そこで問題となるのは、その手の過負荷をどうさばくか。

　たとえば写真に付いたコメントを表示させる場合、「最新の情報をすぐに」表示するのが良いのが当たり前だが、それが過負荷のためにどうしても不可能になった場合に、

・表示するまで１５秒かかる
・表示はすぐにするが、それは１５秒前の状態（投稿されたコメントが反映されるまで１５秒かかる）

のどちらがユーザーから見てストレスが少ないか、どちらの状況になるように設計しておくべきか、という部分が私は重要だと考えている。

　また、通常ピーク時に３秒で処理出来ているところに、通常の倍のトラフィックが来てしまった時に、それを倍の６秒で処理出来るように作ってあるか、倍以上の９秒かかってしまうように設計してあるか、というのが「リニアにスケールするかどうか」という部分である。HTTP Requestに対するレスポンスが遅くなると、それに応じて同時アクセス数が増えてしまい、ペンディング中のスレッドが増えてしまう、そのためにさらにレスポンスタイムが遅くなる、という悪循環は、マルチスレッド型のHTTPを使ったアーキテクチャの根本的な弱点。安易にマルチスレッドに頼ったプログラミングは良くない理由はこの辺りにもある。

　そしてもちろん、もっとも大切なのは、トラフィックがキャパシティを超えて来てしまった時に、サーバーが落ちてしまうのか、単に処理速度がそれに応じて遅くなるだけなのか、という点。

　これらの点を考慮した上で、PhotoShareのようなCGMサービスの場合、「トラフィックがキャパシティを超えて増えてしまうとレスポンスが幾何級数的に遅くなり、しまいにはサーバーが落ちてしまう」という同期型のアーキテクチャではなく、「トラフィックがキャパシティを超えて増えてしまっても、レスポンス時間は常に一定で、単にユーザーの変更がサーバーに反映される時間がリニアに遅くなるだけで、サーバーが落ちることもない」という非同期型のアーキテクチャの方が適しているのではないか、というのが今回の話である。