大規模サービスを展開する企業が陥るジレンマ

このところ大きなサービスを持ってる大きな企業が運用するウェブサイトについて考えることが多かったので、ちょっと書き殴ってみるとします。

一見すると大企業ってのは人もたくさんいるし資金もたくさんあるし、小さな企業と競争になっても、簡単にそれを踏みつぶしてしまえるような印象を受けます。いやいや、そんなに簡単じゃないんだよっていうのがイノベーションのジレンマであり、大企業病のジレンマであり。で、ウェブの企業にもう一つ当てはまるジレンマがあるなあと最近思います。

はてなダイアリーのキーワードページに、Yahoo! ニュースのトピックページからリンクされることがあります。そのニュースが Yahoo! Japan のトップページに載ってたりするものだと、キーワードページへの瞬間最大トラフィックが恐ろしいことになります。最近は対策を練ったので問題ないのですが、一時期は Yahoo! トップに載ってるニュースからリンクされるとキーワードページがダウンしたりしてました。(ニュースからリンクされてる記事を見ると、ときおり「現在閲覧しづらい状況が....」と出たりしますが、それはトラフィックに耐えきれずに相手方が落ちているという。) 名付けて Yahoo! アタック。

月間数億のPVを裁いてるサービスですらリンクしただけで落とせちゃう Yahoo! Japan 本体のトラフィックってのはもうそれこそ桁違いなわけで、その運用の様子は想像しただけでも吐き気がしてきます。

となると、Yahoo! Japan みたいな企業は、新サービスを始めたその瞬間から、自社のポータルからの誘導でものすごいトラフィックを稼げるわけであり、これは他社がもたない強力なアドバンテージに思えます。でも、想像してみてください、あなたが明日、Yahoo! Japan でサービスをオープンさせられることになりましたと言って、どんなシステムを用意しますか? サーバーの台数は大丈夫? 負荷分散は十分に行えている? ネットワーク帯域は? 冗長性は...? などなど心配が耐えません。

その一方で、個人でウェブのサービスをリリースするなんてのは、気楽なもんです。せいぜい来ても 100 〜 1,000アクセスかそこらだし、アクセスが増えてきてもサーバーをもう一台追加するとかすれば当分はしのげます。その間に、現在のトラフィック/ユーザー数の背丈に見合った品質確保のためのノウハウを身につけるなり投入するなりすれば良く、それは小さければ小さいほど容易い。

ここにジレンマがあるんですよね。大きな企業で、大きなサービス、強力な導線を持ってる企業ってのは、そのサービスの初期段階からきちっとした設備投資、品質確保を行わないといけない。サービスを少しずつ育てていくということが難しく、リリースした次の日からいきなり運用保守モードになってしまう。

What Is Web 2.0 のなかでオライリーは、早期に且つ頻繁に機能を改善、リリースしていくことが重要だと述べていますが、トラフィックが大量に集まるサービスではその変更がどうしても難しくなってきます。ユーザー数が多いために、新しい機能を追加したり既存の機能を変更したりする場合の影響が大きかったり、あらかじめ十分な負荷分散を見積もらないと変更できなかったり。それから、企業として、求められる責任の度合いがどうしても大きくなる。そういう状況では、どうしても変化に対して鈍くなり、遅くなってしまいます。

たとえばはてなダイアリーは、現在 100 台以上のサーバーで運用されていて、データベースのパーティショニングや、コンテンツキャッシュの仕組みなんかはいたるところにあって、その運用と開発に結構な工数がかかっています。これはサーバーが1台のときから継続的に運用開発をしてきたからできた芸当で、初日から 100 台サーバー用意して、なんて言われてもたまったもんじゃありません。

いきなり100台はオーバーにしろ、大きな企業ではそういうことが常なんだろうなあと。ニフティにいたときも、ココログをオープンするときにはその辺にすごく神経使いましたし。それでも開始早々障害が起こって、何日も会社に泊まったりしました。そういう状況で、早期に且つ頻繁にリリースしる! それが Web 2.0 だ! なんて言われても「オイオイ」って話になるなあと。

大規模トラフィックを処理するっていうのは、ある程度の規模を超えると銀の弾丸は存在せず、Try and Error による泥臭い努力の上でなんとかやっていけるもんだという点は、Inside LiveJournal's Backend (PDF) や Flickr and PHP (PDF) なんかを見てもその様子がよく分かります。どこも同じようなことで苦労してるなあ、という感じ。そして、成長に応じて、問題の顕在化がゆるやかだったおかげでそれに対応することができたというのもやっぱり共通点なんですよね。

愚痴ばっかり言っててもしょうがないので、将来のために対策などを考えてもいます。このジレンマに対応するメソッドというのはおそらく過去の事例の中にいくつかあるかなと。そのパターンを洗い出してみたい。

ひとつめ。小さい頃から育ってきてノウハウを身につけ、ユーザーを確保したベンチャー企業を丸ごと買収して自社のサービスに取り込む方法。Yahoo! における Flickr 買収、Six Apart による LiveJournal買収とかそういうパターン。これらの買収の主目的は他にもいろいろあるんだろうけど。まあそういうのもありますよってことで。

ふたつめ。Google には低レベルレイヤのコア技術がいくつかあるそうですが、そういうものを早期に確立して、技術面での変化に対するリスクを下げるという方法。Yahoo! にも、大量のトラフィックをさばくための独自の技術があると聞いてます。

これからは Binary 2.0 だ! なんてちょっと笑い話っぽいですが、あんがい笑ってる場合じゃないかもしれない。間違いなく、はてなに足りないテクノロジーはこのレイヤにあるし、そこで成果を出すことができればもっと飛躍できるのではないかと思っています。

ただ、全部 C や C++ で作るとかそういうのはアレなので、やはり Lightweight な言語とフレームワークで開発自体はラピッドに、開発者の技術レベルがある程度ばらついてても対応できるような開発体制でいつつ、彼らがそれを意識しなくても良い、低レベルレイヤでそれらアプリケーションを支える特化型の技術を持っているという、そういうのが理想かなと思います。

みっつめ。Google やサイボウズのように、新規プロジェクトや新しいサービスをラボとして、本ちゃんのものから隔離する方法。あまり本サービスからトラフィックを流したりとか、そういうことをせずに小さなところからスタートさせて、少しずつ育てていくと。あんまり本体から隔離させすぎると、ただの研究で終わってしまいかねないので、その辺のバランスの取り方とかやり方が重要になりそうです。

よっつめ。クローズドな環境で育てていく方法。ベータ希望ユーザーにのみ新プロダクトを解放したりとか。GMail が招待制だったりするのもその一例かな。はてなでは以前にダイアリーの管理画面をリニューアルするときに、この方法を取りました。

他にも色々あると思うけど(なんかいいのあったらぜひコメントなりトラックバックで教えてください)、これもやっぱり銀の弾丸は存在せず、Try and Error と組み合わせが重要なのかなと思います。あと、大前提として、そういう類のことを実現できる企業文化を小さなころから大切にすること。

はてなもユーザーさんもトラフィックも増えてきたし、こういうことを真剣に考えていかないと、いずれイノベーションが止まってしまいかねないなと、最近思うのでした。