この記事はCohesityのファウンダー、CEOでCrunch NetworkのメンバーMohit Aronの執筆
独立企業としてはYahooは最後の日々を迎えつつあるようだ。一方、GoogleはAppleと時価総額世界最大の企業の座を争っている。わずか10年前と少し前には、YahooとGoogleが激しく競争していたとは信じがたい。
当時、現在のような状態を予測できたものは誰もいなかっただろう。両社の状況にやがてこれほど大きな差がつくと、誰にせよ当時予測できたと考えるなら馬鹿げている。そうではあっても、GoogleとYahooの歴史を振り返ることからわれわれは多くを学べると思う。
私は2003年に Googleで働き始めた。GoogleとYahooは当時急成長中だったウェブの覇権をめぐって激しい競争を繰り広げていた。この問題には非常に多くの要因が影響を与えていたが、中でも最終結果に決定的な役割を果たしたと思われるのが、それぞれの企業のコアとなるインフラへの取り組み方だったと思う。
私はこの記事の主役ともいうべきGoogle File Systemの開発に密接に関係していたので、それが見方に影響を与えているだろう。そうであってもGoogleとYahooのインフラに対する態度を比較することからわれわれは急速に変化するテクノロジー世界にあって持続性の高いビジネスの構築の方法について多くの教訓が得られそうだ。
当面の対応 vs. 将来の持続性
21世紀に入ってインターネットが普及期に入ると、検索、メール、地図などのサービスの規模、需要が爆発的に拡大し始めた。これに対応する方法がGoogleとYahooでは鋭い対照を見せた。Yahooの場合、NetAppシステムという形で必要とされるサーバー数の猛烈な速度での増大に対処しようとした。
YahooのほとんどのサービスはNetAppストレージ・デバイス上で作動するようになり、同社のサーバーの設定と追加は非常に簡単になった。これによりYahooは需要に対応することに成功し、自身としてもNetAppデバイスの最大のユーザーとなった。
しかし（たまたま近所のマウンテンビューに本社を構えた） Googleは独自開発のソフトウェアをインフラとする戦略を採用した。これはその後GFS―Google File Systemとして知られるようになったが、専用ハードウェアではなく、あらゆるサービスに対応可能な汎用性の高いソフトウェアを中心としたエコシステムを構築しようというものだった。
Google File Systemはコモディティー―安価な市販品―のサーバーを用いて柔軟かつ故障耐性の高いシステムを構築することにより、スケーラビリティーと信頼性の問題を同時に、かつ決定的に解決するものだった。Googleが地図からクラウド・ストレージまで多様なサービスを簡単、高速に展開することを可能としたのはGFSだった。
スケーリングの複雑な側面
ミッション・クリティカルな分野でGFSを利用できるようになるまでにGoogleは4年をかけている。Googleが開発に投入した人員、資金などのリソースは莫大なものだ。
その間、Yahooは専用ハードウェアをベースにしたNetAppファイルを急速に追加し続け、拡大する需要に対処していた。インターネット・ビジネスの世界でYahooははるか先を行っているように見えた。
しかし、Yahooの「市場ニーズに即座に対応する」というアプローチにはやがてほころびが出始めた。需要の規模と多様性が拡大し続けるにつれ、専用ハードウェア・ベースのインフラは開発作業の重複という問題を引き起こし始めた。これは効率を下げ、最後にはコストの上昇を招いた。Yahooが新しいサービスを始めるつど、そのサービス専用にNetAppプラットフォームを改造する必要が生じた。
Yahoo検索とYahooメールが直面した技術的課題は同種のものであったにもかかわらず、それぞれが異なるカスタマイズを受けたNetAppで作動していたため、技術陣は別々に問題を解決しなけれならなかった。
これはリソースと非効率性の著しい増大を意味した。全社的に共通のプラットフォームは存在せず、異なるサービスは異なるサーバー、異なるコンピューティング能力を必要とした。
NetAppハードウェアのコストはYahooの規模の拡大と同じ速さで増大し、Yahooの利益の大きな部分に食い込むこととなった。
解決法を探す前に、問題を徹底的に理解することが重要
これに対して Googleは、規模を拡大し新サービスを追加するときに起きるはずの問題を、それが起きる前に予期し、効率的に対処できるようGoogle File Systemの開発に全力を挙げた。
その結果、たとえばYouTubeを買収したとき、GoogleはYouTubeのエンジニアに対し「きみらのバックエンドは捨ててわれわれのファイルシステムを使いたまえ」と指示することができた。すべてのGoogleサービスはGFS上で作動していたので、エンジニアはたった一度のGSFのアップグレードで全社のサービスをアップグレードすることができた。
また汎用性の高いGFSを利用できたため、コンピューティング・パワーを異なるサービス間で共有することが簡単だった。検索を実行しているサーバーに処理能力の空きが生じたら直ちにメールの処理に移ることができた。しかもこうしたサーバーはコモディティー製品だったので、ムーアの法則に従い、日々急速に価格をげていた。
これに反してYahooでは開発の複雑性と処理コストが爆発的に増大し始め、 新サービスの追加でGoogleのペースについていくことが不可能になっていった。
ゼロから考えることの重要性
後から考えれば、これはアーキテクチャーの柔軟性の重要さを示すものと言えるかもしれない。しかしこうした例は、アプリケーションややインフラの開発といったテクノロジー企業特有の分野を超えて、持続性のあるビジネスを構築する上で何が重要かを示す教訓にできるのではないかと思う。私がGoogle時代に学んだもっとも重要な点は「解決法を探す前に、問題を徹底的に理解することが重要」ということだった。
何であれ問題を見たら、解決法をゼロから考えることが重要だ。エンジニア（多くの場合、同時にファウンダーでもある）は既存の解決法に引きずられてはならない。これまでにこれこれの対策が取られてきたなどいう情報にはまず目をつぶることだ。自分自身が理想と考える解決法を編み出すことが大切だ。それを得たならば、既存の手法を検討し、どれを用いることができるか、どこを改良すればいいのかを考える手順となる。
スタートアップが既存の大企業をひっくり返し、そのサービスで自らの地位を確立するためにはこれが必須の条件となる。AmazonはAWSというIaaSをスタートさせることによって、ハードウェアのリースと処理のアウトソーシングの王者としてエンタープライズITに君臨してきたComdiscoを倒産させた。スタートアップに席巻されたくない大企業にはこれが教訓になった。たとえばFacebookは現在もサーバーからデータセンター、カメラまで独自のインフラ開発に全力を投じている。
往々にして「ゼロから考える」ことは目先の成長を犠牲にする場合がある。動きの速いシリコンバレー企業にとっては、その意味で「苦い薬」だが、長期的な持続可能性を考えたとき避けては通れない。即効性はあるもののその場限りの対応は結局のところ複雑性と処理コストを加速度的に増大させるというはるかに重大なリスクを持ち込むことを意味する。
Googleはあらゆるウェブ・サービスに適用可能な柔軟性と単純性を目標としてGFSを開発した。それに対してYahooの複雑なインフラは、一時的に成功を収めたものの、長期的にはYahooのビジネスに今日見られるような限界を持ち込む原因となった。
[原文へ]
（翻訳：滑川海彦@FacebookGoogle+）
（2016年5月23日TechCrunch日本版「Google対Yahoo—インターネット戦争でどうしてここまで差がついたのかを振り返る」より転載）
【関連記事】