有名ウェブサイトの技術開発プロセスの詳細な説明

文/リン・ハオ

インターネットは長年にわたって発展を続けており、優れたウェブサイトも数多く存在します。これらのウェブサイトのほとんどは、10 年以上存在しています。このような長い発展期間中、ビジネス上の課題に加えて、多くの技術的な課題にも直面しました。私は、Alexa ランキング上位の Web サイト (2012 年 4 月 21 日時点のランキング) をいくつか選択し、ビジネスの成長における課題に技術的にどのように対処しているかを確認しました。

Googleは現在Alexaで第1位にランクされています。 1997年に研究プロジェクトとして誕生しました。インデックスは月に1回構築され、シャーディング（shard by doc）によって複数のサーバー（Index Server）に分散されます。特定のWebページデータもシャーディングによって複数のサーバー（Doc Server）に分散されます。ユーザーがリクエストを送信すると、フロントエンドサーバーはIndex Serverにリクエストを送信してスコアリングされた転置インデックスを取得し、Doc Serverから特定のWebページ情報（Webページのタイトル、検索キーワードに一致するフラグメント情報など）を抽出して、最終的にユーザーに表示します。

インデックスされたウェブページの数が増えるにつれて、この構造はインデックスサーバーとドキュメントサーバーを追加することでインデックスとウェブページのデータを保存できるようになりましたが、それでも他の多くの問題に直面しました。そのため、その後の10年間で、Googleは上記の構造を大幅に改善しました。

1999 年、Google はクエリ インデックス結果とドキュメント フラグメント情報をキャッシュするキャッシュ クラスタを追加し、同時に、インデックス サーバーとドキュメント サーバーを Replicate を通じてクラスタに変換しました。これら 2 つの変換の利点は、Web サイトの応答速度、サポートされるトラフィック、および可用性が向上することです。この変更によりコストが増加しました。ハードウェアにおける Google のスタイルは、高価なハイエンド ハードウェアを使用することではなく、ソフトウェア レベルでシステムの信頼性と高性能を確保することでした。そのため、同年、Google はコストを削減するために自社設計のサーバーを使い始めました。 2000 年、Google は独自のデータ センターの設計を開始し、さまざまな方法 (エアコンの代わりに他の冷却方法を使用するなど) を使用して PUE (電力使用効率) を最適化し、自社設計のサーバーにも多くの最適化を施しました。 2001 年、Google はインデックスの形式を変更し、すべてのインデックスをメモリに格納しました。この変更により、Web サイトの応答速度とサポートできるトラフィック量が大幅に向上しました。 2003 年に、Google は Google Cluster Architecture という記事を公開しました。その Cluster 構造は、ハードウェア LB + Index Cluster + Doc Cluster + 多数の安価なサーバー (IDE ハードディスク、コスト効率の高い CPU など) で構成されています。並列処理 + シャーディングにより、ハードウェア要件を削減しながらも、応答速度が速いことを保証します。同年、GoogleはGoogle File System（GFSは2000年に開始）に関する論文を発表しました。この論文も、高価なハードウェアを使わず、GFS + 多数の安価なサーバーを通じて大量のデータを保存できるというGoogleのスタイルを大きく反映しています。 2004 年に Google はインデックスの形式を再度変更し、Web サイトの応答速度がさらに向上しました。同年、Google は MapReduce に関する論文を発表し、MapReduce と多数の安価なサーバーを組み合わせることで、これまでは高価なミニコンピュータ、中型コンピュータ、さらにはメインフレームを必要としていたコンピューティング タスクを迅速に完了できると述べています。これは明らかに、Google がインデックスを迅速に構築するのに大いに役立ちました。 2006 年、Google は BigTable (2003 年にオンライン化) に関する論文を発表しました。これにより、膨大なデータの分析がオンライン システムの要件を満たすようになり、Google の Web サイトの応答速度が大幅に向上しました。

上記 3 つの論文は、業界における大量データの保存、分析、検索の方法を完全に変え (噂: Google は GFS、MapReduce、BigTable の置き換えを完了した)、業界における Google の技術的リーダーシップを確立しました。

シナリオによっては、Google はデータの保存に MySQL も使用します。同様に、Google は MySQL に多くの変更を加えています。Google が使用する MySQL に関する情報は、https://code.google.com/p/google-mysql/ で確認できます。

2007年、Googleはインデックス構築時間を数分に短縮しました。新しいWebページが登場すると、数分でGoogleで検索できます。同時に、インデックスクラスターは、さまざまなGoogle検索（Webページ、画像、ニュース、書籍など）に対して、プロトコルバッファーを通じて外部にサービスを提供しています。インデックスクラスターが提供するサービスに加えて、広告、語彙チェックなど、他の多くのサービスがあります。 Google 検索では、主に C++ または Java で記述された 50 を超える内部サービスを呼び出す必要がある可能性があります。 2009 年に Google が発表した記事「Google の Linux 利用方法」では、リソース消費タイプの異なるアプリケーションを同じマシンに展開するなど、マシンの利用率向上のために Google も多大な努力を払ってきたことが明らかになりました。

その後、Google は、主に検索のリアルタイム パフォーマンスの向上と、より多くのデータの保存を目的として、Colossus (次世代の GFS のようなファイル システム)、Spanner (次世代の BigTable のような大規模ストレージおよびコンピューティング アーキテクチャ)、およびリアルタイム検索 (Colossus ベース) を開発しました。 Google は、大量データに関連する技術の革新に加えて、TCP の初期輻輳ウィンドウ値の増加、HTTP の SPDY プロトコルの改善、新しい画像形式 WebP など、業界の従来の技術にも継続的に革新をもたらしています。

Google の発展過程において、同社の技術革新は主に、スケーラビリティ、パフォーマンス、コスト、可用性という 4 つの側面を中心に展開されました。高価なハードウェアを使用しない Google のスタイルと、他の Web サイトを上回るデータ量により、同社の技術革新は基本的に従来のソフトウェアおよびハードウェア技術の革新であることが決定されました。

Facebookは現在Alexaで第2位にランクされています。これは LAMP を使用して構築されており、ビジネスの成長に伴い、多くの技術的な変更も行われてきました。

変革の第一歩として、Facebook はまず LAMP 構造に Memcached を追加してさまざまなデータをキャッシュし、システムの応答時間とサポート可能なトラフィック量を大幅に改善しました。次に、ニュース フィードや検索などのより一般的な機能をサービスとしてフロントエンド PHP システムに提供するために、サービス レイヤーを追加しました。フロントエンド システムは、Thrift を通じてこれらのサービスにアクセスしました。 Facebook はさまざまなサービスを作成するために複数の言語を使用しており、主に C++、Java、Erlang など、さまざまなシナリオに適した言語を選択しています。

Memcached の広範な使用とトラフィックの継続的な増加により、Memcached にアクセスするためのネットワーク トラフィックが大きくなりすぎ、スイッチがサポートできなくなりました。Facebook は、UDP を使用して Memcached にアクセスする方法を変更し、単一接続でのネットワーク トラフィックを削減しました。その他にもいくつか変更点があります。詳しくは http://on.fb.me/8R0C をご覧ください。

スクリプト言語としての PHP は、開発が簡単で使いやすいという利点がありますが、CPU とメモリを多く消費するという欠点があります。 Facebookのトラフィックが一定規模にまで成長すると、この欠点はより顕著になりました。そこでFacebookは2007年以来、この問題を解決するためにさまざまな方法を試みてきました。そしてついに、Facebookハッカソンから生まれたHipHop製品が成功を収めました。 HipHop は PHP を C++ コードに自動的に変換できます。Facebook が HipHop を使用した後、同じ構成のマシンでサポートされるリクエストの数は以前の 6 倍になり、CPU 使用率は平均 50% 低下し、Facebook は大量のホストを節約できました。今後、Facebook は HipHop をさらに改良します。HipHop を通じて、PHP はバイトコードにコンパイルされ、実行のために HipHop VM に配置され、その後、JIT と同様に HipHop VM によってマシン コードにコンパイルされます。

2009年、FacebookはBigPipeを開発し、このシステムの助けを借りて、Facebookはウェブサイトの速度を2倍にすることに成功しました。 Facebook のトラフィックが増加するにつれて、多くのサーバーから実行ログを収集することが困難になったため、Facebook はこの問題を解決するために Scribe を開発しました。 MySQL に保存されているデータについては、Facebook は垂直分割ライブラリと水平分割テーブルを使用して、増大するデータ量に対応しています。 Facebook のテクノロジー システムの重要な部分として、Facebook はオンライン スキーマ変更など、MySQL に対して多くの最適化と改善も行っています。詳細については、http://www.facebook.com/MySQLAtFacebook を参照してください。

開発当初、Facebook は写真の保存にハイエンドのストレージ デバイス (NetApp や Akamai など) を使用していました。写真の数が増え続けるにつれて、コストも大幅に増加しました。そこで、Facebook は 2009 年に写真の保存に Haystack を開発しました。 Haystack は安価な PC サーバーをストレージに使用できるため、コストを大幅に削減できます。

Facebook は、データの保存に MySQL を使用するだけでなく、近年、新しい方法も模索し始めています。 2008 年、Facebook はメッセージ受信トレイ検索の新しい保存方法として Cassandra を開発しました。しかし、2010 年に Facebook は Cassandra を放棄し、メッセージのストレージとして HBase に切り替え、2011 年にはさらに多くの Facebook プロジェクト (Puma や ODS など) に HBase を適用しました。 Facebook は現在、ユーザーと関係のデータを MySQL から HBase に移行しようとしていると言われています。

Facebook は 2009 年以来、運用コストを削減するために独自のデータセンターとサーバーの設計に取り組んでおり、PUE がわずか 1.07 のデータセンターの関連技術を公開しています。 Facebook のテクノロジーに関する基本原則は、「可能な場合はオープンソース製品を使用し、必要に応じて最適化し、コミュニティにフィードバックを提供する」ことです。この原則は、Facebook の技術開発の歴史を通じて実践されてきたことがわかります。Facebook の技術変革も、主にスケーラビリティ、パフォーマンス、コスト、可用性の 4 つの側面を中心に展開しています。

テンセントWeiboに再投稿

Twitterは現在Alexaで8位にランクされています。 2006 年にリリースされたときは、Ruby On Rails + MySQL を使用して構築されていました。2007 年には、応答速度を向上させるために、キャッシュ レイヤーとして Memcached が追加されました。 TwitterはRuby on Railsをベースに迅速な開発能力を誇っていましたが、アクセス数が増えるにつれてCPUとメモリの消費量もTwitterにとって苦痛になってきました。そこでTwitterは、Ruby GCの最適化バージョンを書くなど、多くの変更と努力を重ねてきました。

2008年、Twitterは段階的にJavaに移行することを決定し、主要な開発言語としてScalaを選択しました（理由は「Rubyプログラマーだらけの部屋にJavaを売り込むのは難しかった」ため）。主要な通信フレームワークとしてThriftを採用し、サービスフレームワークとしてFinagleを開発しました。これにより、フロントエンドシステムがさまざまな通信プロトコルを気にする必要がなくなり、さまざまなバックエンド機能をサービスとして公開できます（たとえば、ユーザーは同じサービス呼び出し方法を使用して、Memcache、Redis、およびThriftサーバーにアクセスできます）。メッセージミドルウェアとしてKestrelを開発しました（以前はRubyで書かれていたStarlingを置き換えました）。

Twitter は、データ保存に常に MySQL を使用してきました。開発プロセスでの小さなエピソードとして、Facebook が Cassandra をオープンソース化したとき、Twitter はそれを使用する予定でしたが、最終的には断念して MySQL を使い続けました。Twitter の MySQL バージョンはオープンソース化されています (https://github.com/twitter/mysql)。 Twitter も、大量のデータに対応するためにデータベースとテーブルをシャーディングする方式を採用しています。ツイートのキャッシュには Memcached を使用し、タイムライン情報は Redis に移行してキャッシュしています。

2010 年、Twitter は主に制御性の向上を目的として、ソルトレイクシティに初の自社データセンターを建設しました。 Twitter の開発プロセスを見ると、過去 6 年間の技術的変革は主にスケーラビリティと使いやすさを中心に展開されてきました。

テンセントWeiboに再投稿

電子商取引サイトの従業員として、Alexa で 21 位にランクされたこの有名な電子商取引サイトの技術的進化についてご紹介させてください。

1995 年に eBay が誕生しました。これは CGI で書かれ、データベースとして GDBM を使用していましたが、最大で 50,000 個のオンライン製品しかサポートできませんでした。 1997 年、eBay はオペレーティング システムを FreeBSD から Windows NT に、データベースを GDBM から Oracle に移行しました。 1999 年、eBay はフロントエンド システムを Cluster (以前はホストが 1 つだけ) に変換し、ロード バランサーとして Resonate を採用し、バックエンドの Oracle マシンを Sun E1000 ミニコンピュータにアップグレードしました。同年、可用性を向上させるために、バックアップ データベースとしてデータベースにマシンが追加されました。フロントエンドマシンはトラフィックの増加に対応できましたが、データベースマシンは1999年11月にボトルネック（CPUとメモリを追加できなくなった）に達したため、11月から業務に応じてデータベースを複数のデータベースに分割し始めました。 2001 年から 2002 年にかけて、eBay はデータを水平に分割し、たとえば製品をカテゴリ別に格納し、Oracle ミニコンピュータを Sun A3500 に置き換えました。2002 年には、Web サイト全体が Java で構築されるように移行されました。この段階で、データベース シャーディングの影響を遮断するために DAL フレームワークが作成され、開発者が機能開発をよりスムーズに開始できるように開発フレームワークが設計されました。 eBay の開発プロセス全体を見ると、技術的な変革は主にスケーラビリティと可用性を中心に展開されています。

テンセントは現在Alexaで9位にランクされています。当初、QQ IM は単一のアクセス サーバーを使用してユーザーのログインとステータスの維持を処理していましたが、同時オンライン ユーザー数が 100 万人に達すると、このサーバーではサポートできなくなりました。そのため、QQ IM はすべての単一サーバーをクラスター化し、ステータス同期サーバーを追加して、クラスター内のステータスの同期を完了しました。ユーザー情報は MySQL に保存され、個別のライブラリとテーブルがあり、友人関係は独自に実装したファイル ストレージに保存されます。プロセス間通信の効率を向上させるために、Tencent は独自にユーザーモード IPC を実装しました。その後、テンセントは、増加するオンライン ユーザーをサポートするために、状態同期サーバーを同期クラスターに変換しました。これまで数回の改革を経て、基本的に数千万人のオンラインユーザーを同時にサポートできるようになりましたが、可用性は比較的低いものでした。そこでテンセントはQQ IMを再度改革し、同じ都市のIDC間での災害復旧を実現し、監視および運用保守システムの構築を強化しました。その後、テンセントは、主に柔軟性の向上、都市間IDCのサポート、数千万人の友人のサポートを目的として、QQ IMアーキテクチャを完全に書き換えることを決定しました（おそらく2009年から現在まで）。この大きな技術的変革の過程で、Tencent のデータは MySQL に保存されなくなり、すべて独自に設計されたシステムに保存されるようになりました。

QQ IM の技術的進化の観点から見ると、その技術的変革は主にスケーラビリティと可用性を中心に展開されます。

2003年に淘宝網が誕生しました。phpAuctionという商用ソフトウェアを直接購入し、それを淘宝網に変えました。 2004 年にシステムは PHP から Java に移行され、MySQL は Oracle (ミニコンピュータ、ハイエンド ストレージ デバイス) に移行され、アプリケーション サーバーとして WebLogic が使用されるようになりました。 2005年から2007年の開発過程で、JBossがWebLogicに取って代わり、データベースがパーティション化され、BDBをベースに分散キャッシュが行われ、小さなファイルの保存をサポートするために分散ファイルシステムTFSが独自に開発され、独自のCDNが構築されました。 2007年から2009年にかけて、アプリケーションシステムは垂直に分割されました。分割後は、システムがサービスの形で外部に機能を提供し、データは垂直と水平に分割されました。

データの垂直・水平分割後、Oracle のコストはますます高くなったため、その後数年間、Taobao は Oracle から MySQL にデータを徐々に移行し、同時に HBase を使用して履歴取引注文の保存と取得をサポートするなど、新しいデータ ストレージ ソリューションを試行し始めました。近年、Taobao は Linux カーネル、JVM、Nginx などのソフトウェアの修正とカスタマイズを開始しました。また、独自の低エネルギー サーバーを設計し、ソフトウェアとハ​​ードウェアの両方を最適化して、コストをさらに削減しました。

Taobao の開発プロセス全体を見ると、技術変革は主にスケーラビリティと可用性を中心に展開されており、現在は徐々にパフォーマンスとコストに重点が置かれています。 Taobaoの現在のAlexaランキングは14位です。

要約する

上記のAlexaランキングのウェブサイトの技術開発プロセスから判断すると、各ウェブサイトは、ビジネス、チーム構成、作業スタイルが異なるため、技術開発のさまざまな段階でビジネス開発をサポートするためにさまざまな方法を採用します。ただし、基本的には、スケーラビリティ、可用性、パフォーマンス、コストを中心に展開します。比較的大規模に開発されると、ウェブサイトの技術構造には多くの類似点が生まれ、これらの構造は進化し続けます。

著者の林昊は現在、Taobao で働いています。2007 年から 2010 年にかけて、彼は Taobao のサービス フレームワークの設計と実装を担当しました。このサービス フレームワークは Taobao で広く使用されており、毎日 150 億件以上のリクエストを処理しています。2011 年に、彼は Taobao での HBase の実装を担当し始めました。現在、Taobao には HBase を使用したオンライン プロジェクトが 20 件以上あります。

原題: 有名ウェブサイトの技術開発プロセスを詳細に解説

キーワード: 詳細な説明、有名、ウェブサイト、技術開発、歴史、リン・ハオ、インターネット、開発、長年、その中で、ウェブマスター、ウェブサイトの宣伝、金儲け