今日は本誌定番のすばらしい起業家たちやすばらしいVCたちのお話からすこし離れて、技術のお勉強をしよう。覚えておられると思うが、最近Dropboxは、ユーザ数が1億7500万に達したと発表し、もうハードディスクは要らない、という大胆な発言をしてニュースになった。すごいことだけど、でも、その背後にはどんな技術があるのだろう？ スタートアップは、成功するためにスケーラビリティをどうやって確保すべきか？ しかも、ユーザ数何億というレベルにまで…。そしてその秘訣は、相当早くからとてもシンプルで柔軟性のあるプラットホームを作っておくことに、あったのだ。
今日（米国時間7/11）ブダペストで行われたRAMPカンファレンスで、以前Dropboxでサーバ担当の技術者だったRajiv Erankiが、会場を埋め尽くす技術者たちを前に、その概要を述べた。彼は2008年にDropboxに入り、2011年に辞めた。“もっと違うことをしたかった”からだが、その中にはニューヨークでカクテルバーを開くことも含まれていたらしい。なお、RAMPの主催者は、ハンガリーに生まれて世界的にビッグなスタートアップになったPrezi、Ustream、そしてLogMeInだ。
大学に残れという話もあったErankiは、結局ふつうに卒業して当時まだユーザ数2000のDropboxに入った。彼ともう一人の計二人が、正社員としてバックエンドのスケールアップを担当した。そのころのDropboxは、データベース専用機が一台、フロントエンドのサーバが一台、という構成だった。
Erankiによると、初期のチームは“効率の悪いことをたくさんやりながら、数千というオーダーのユーザに対応していった”。
たとえば、Dropboxが最初に行ったデータベースのシャーディング(sharding, 分割)は、バグだらけだった。複数のデータベースにまたがるJOINを一本化できず、大量の非正規化(denormalization)をやった。
しかし、とくに大きな変更を加えたということはなくて、Dropboxの初期のこのような、行き当たりばったり、その場しのぎのやり方には、技術的に便利な面もあった。
たとえばユーザの行動に関するクェリを、コードを1行も書かずに簡単に実行できた。必要に応じて、複数のデータベースにまたがるJOINができた。MySQLのクェリを動かしながら大量のバグフィクスができる、という構造だったので、とても便利だった。大量の共有フォルダのあるユーザでも、データベースのクェリは一回でよかった。また、フロントエンドはつねに一つだったので、彼らが見るべきログも、つねに一つだった。
こういう、その場その場の工夫の積み重ねにより、“柔軟性とスケーラビリティの大きいシステムができあがった”、とErankiは言う。
つまり、最初のうちはデータベースを分割しなかったため、いろんな作業が複雑になることを避けられた。初期の取り組みから得られたもう一つの教訓は、言語としてPythonを選んで良かったなぁ、ということ。それは、何でも書ける、何でもできる言語だった。
ユーザ数が100万になっても、全プラットホームが前と同じ数百行のコードで動いていた。コードが数千行に肥大することはなかった。Pythonを使ったことによって、“何千行ものCのコードを書くことなくユーザ数4000万に達することができた”。クライアントアプリケーションも、Pythonで書いた。
彼らが重視したのは、開発、管理、そしてメンテナンスの容易さと、コードの堅牢性/確実性（シンプルで壊れにくいこと）だ。また、大量のグラフを出力する管理ツールを捨てて、簡単なダッシュボードを作り、そこからパフォーマンスを分析した。“ほとんどのグラフは何の役にも立たない”、と彼らは悟った。ダッシュボードではグラフを多用せず、項目と値をそのまま書いた（「ログインの失敗」など）。また、余剰クェリはmemcacheする、SQLクェリの最適化を遅らせるなどの、“ゆとり策”をとった。
そして分かってきたのは、“毎日のようにDropboxを大量に使うユーザは、それをCDNの代わりに使うなど不当な使い方をしている人か、または単なるバグだ”ということ。そして、ふつうの、まともな使い方をしている中位ユーザたちが、将来のDropboxのビジネスの基盤だと気づいた。特異な上位ユーザに目を奪われずに、ふつうのユーザをたいせつにする。そこからDropboxはビッグビジネスに育っていった。
Erankiはまた、次のようなレッスンも学んだ。
彼によると、前もって配慮したこと、“先走って巧妙を追うこと”は、必ず失敗した。むしろ、何もせずに、よく注視しながら成り行きにまかせるのがベストである。
ものごとが‘マーフィーの法則’的にまずくなるのを事前に防ぐためには、たとえばWebサーバをハードリブートして、それが自動リスタートできるかチェックする。できなければ、問題が起きている。
ログデータはきちんと保存することが重要。そして、古いコードは消さない方がよい。どちらも、あとになって必要になることがあるからだ。“消す必要のないものはそのまま残せ”、が鉄則だ。そして初期の経験から学んだのは: 新しい技術の導入には疑いの気持ちをもって…眉に唾をして…臨め、だ。
Erankiは、自分が犯した間違いからも学んだ。
ダウンタイムやパフォーマンスの劣化を、詳細に記録しなかった。
新規雇用は早めに。土壇場になって人を雇っても、ほとんど役に立たない。前もって、会社やシステムのことをよく知る期間が必要である。また、そういう人が多くなれば、今後の新規雇用も楽になる。
Erankiが初期のDropbox経験から学んだことの核心は: “前もってアーキテクチャに関してクレバーであることは難しい”、そして、“円滑なスケーリングのためには、プロジェクトの正しい優先順と、それらの構築プロセスが重要”、ということだった。
Dropboxは今の1億7500万から10億にスケールできるか、と聞かれた彼は、できる、と答えた。だって、今の5倍大きいだけだからね。
[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）
