大規模SNS実現のためのGREEのアプローチ：大規模サイトの舞台裏（5/5 ページ）

[藤本真樹，ITmedia]

そのほかの工夫

　データアクセス以外の要素については、概念をそれぞれ簡単に説明します。

安全でスケーラビリティの高いストレージの実現

　ユーザーがアップロードする画像や動画、音楽などのデータは、それこそ無限に増え続けていくため、スケーラブルなストレージを持つことは（アプリケーションの性質にもよりますが）非常に重要です。

　GREEでは、通常のPCサーバ2台を1ユニットとして、前述のマッピングデータと組み合わせてスケーラビリティを確保しています。具体的には次のようなポイントがあります。

1. データがアップロードされた段階で、マッピングデータを基に、当該データをどのユニットに保存するかを決定する
2. アプリケーションがデータを保存するタイミングで、ユニット内すべてのサーバに同じデータを保存する（2つのサーバそれぞれにデータを保存。特にGREEではWebDAVを利用している）
3. ユニット間のサーバは、mod_rewriteとmod_proxyを利用し、片方のサーバでデータが欠損している場合でも、もう一方のサーバにリダイレクトさせるように設定しておく（Apacheを利用している場合は簡単で、リスト10のような設定でこれを実現できる）
4. ユニット内のデータの欠損をチェック／修復するツールと、ユニット間のデータ移動ツールを準備しておく

　あるユニットのストレージがあふれそうになった場合には、新しくユニットを用意し、ユニット間データ移行ツールを利用します。「このユーザーIDはこっちのユニット」というように移動させることでデータを分散させることができます。

RewriteCond %{REQUEST_METHOD} GET|HEAD
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-f
RewriteCond %{HTTP:Via} !my-server.example.com
RewriteCond %{HTTP:Via} !another-server.example.com
RewriteRule .* http://another-server.example.com$0 [P]

リスト10　データの欠損時にリダイレクトする設定

　このような方法でストレージにかんしては多くの問題を解決できますが、これ以外にもLVSを利用してクラスタリングを行う方法や、商用のストレージを利用する方が効率的な場合もあります。いずれにせよ、やはりさまざまな選択肢から適切な方法を選択していく必要があるでしょう。

サーバ構築／運用

　サーバが100台、200台と増えてくると、サーバの構築/運用方法もまじめに考える必要が出てきます。GREEでは現在、すべてのサーバにDebian GNU/Linuxを利用しているので、サーバに関するすべての処理をDebianパッケージにまとめていき、GREE用のapt-lineを用意することでこのコストを低減しています。例えば「Webサーバが必要だ！」となったら、

# apt-get install gree-ws

とするだけでWebサーバができあがる、といった感じです。それ以外にも、ネットワークストレージ上にXenのイメージデータを置き、各サーバではそのイメージを利用してサービスを提供するといった方法や、ディスクイメージを何台かのサーバに集中して格納し、それ以外のサーバはすべてそのディスクイメージを利用してネットワークブートする、といった方法を取っている企業もあるそうです。

ほかにも工夫の余地あり

　これ以外にも、全文検索*、サービス間連携*、リリースツール、Webデザインパターン、リポーティングなどなど、開発のプラットフォームとして必要なものはたくさん考えられます。GREEでもこれらすべてが（十分な状態で）そろっているわけではなく、日々改善や追加を進めているという状況です。また、すべて自分たちで作る必要はなく、むしろよいソフトウェアを適切に導入していくのも重要だと考えています。

おわりに

　冒頭で書いたとおり、Webアプリケーションの構築手法については、非常に多くの情報が共有されています。しかしながら、実際に一定以上の規模のWebアプリケーションを構築、運用する場合には、それ以外にも実に多くの問題を解決していかなければなりません。本稿が今後そういった問題を解決する際に、何かのヒントになれば幸いです（コラム3）。

コラム3　Webサイト管理者のつぶやき

　ここしばらくの実感として、オープンソースソフトウェアの成熟、フレームワークの一般化やノウハウの公開とその蓄積も手伝って、「本当にWebアプリケーションを作りやすくなった」と感じます。それなりの規模や複雑さを伴ったサイトでも1人で作れますし、定番レイアウトやアイコンが自由に使える形で公開されており、デザインが苦手な方でも利用できます。

　そういった中で、GREEとして何をしていくべきか日々考えたりもするのですが、大事なことの1つとして挙げられるのは、「GREEとしての開発プラットフォーム」を作って成長させることだと思っています。「開発プラットフォーム」には2つの意味があって、1つは新しくサービスを構築していくためのプラットフォーム、そしてもう1つは、個々のサービスのスケーラビリティを保つためのプラットフォームです。

　GREEでは、これを実現するための要件を20個程度の「フィールド」にブレークダウンし、アプリケーション開発と同時にこういったプラットフォームの構築を（少しずつですが）進めています。わたし個人の意見としては、「開発プラットフォーム」を強力に持っているのがGoogleで、Googleの非常に大きなアドバンテージはその点にあるのではないかと思っています。

　ちなみに開発プラットフォームは、技術的なものにとどまりません。例えばアプリケーションフレームワークなどはその1つですが、それ以外にも、チーム構成や導入の仕方、日々の働き方といったところまでも考えていく必要があります。

　また、GREEではそれぞれの「フィールド」に関して、

1. 概念（どういうアプローチをするか決める）
2. 個別の実装（個々の問題に対して、決まったアプローチで個別に実装する）
3. 共通化された実装（問題解決の方法を共通化して再利用を可能にする）
4. 透過的な実装（意識しないでも問題が発生しない）

という4つのレベルで考えています。

このページで出てきた専門用語

全文検索

GREEではMySQL＋Sennaを全文検索サーバとして利用し、それを簡単に扱うためのライブラリを準備しています。

サービス間連携

ソースコードベース、外部APIベースなどが考えられる。

ITmedia オルタナティブ・ブロガーの意見

システム/ソフトウェアの性能やスケーラビリティを競争領域に via kwout

本記事は、オープンソースマガジン2006年8月号「大規模サイトの舞台裏」の内容を最新の情報を交えながら再構成したものです。