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

[藤本真樹，ITmedia]

ボトルネックはデータアクセス

　Webアプリケーションでは、とにかくレスポンスタイムが重要になります。レスポンスタイムはユーザーの使い勝手に直結しますし、あまりにレスポンスが悪いとユーザーはページのリロードを試みます。つまり、トラフィックがさらに増えるわけで、サチュレーション*が起こってしまうのです。これを避けるためには、基本的なレスポンスタイムを低く抑える必要があります。

　そのためWebアプリケーション開発者の間では、データアクセスのスケーラビリティ確保がよく話題に上ります。大規模サイトに使われるようなWebアプリケーションであれば、ストレージへのアクセス手段としてRDBMSが使われており、特にOSSのRDBMSであるMySQLやPostgreSQLのチューニング方法がよく議論されます。

　しかし、結局のところ、「インデックスを正しく利用する、パラメータを正しく設定する」などという基本的な対策ができているならば、その次にやるべきことはディスクI/Oにかんするものがほとんどです。ある程度チューニングしてみて、それでもレスポンスタイムが十分低く抑えられない場合は、

1. とにかくすべてのデータをページキャッシュ（あるいはtmpfsなどを利用してメモリ）上に置く
2. データが大きすぎてメモリ上に乗らない場合は、データを分割する（パーティーショニング）

という2点が基本原則となってきます。

　具体的には1の対策は、大量のメモリを積んだマシンを用意することを意味しますので、予算的な問題さえ解決できれば難しいことではありません。しかし、予算の都合は必ず存在しますし、データは無限に増え続けるので、いつでもこの方法が使えるわけではありません。エンジニアリング的解決法としては、2の方法が有効です（コラム2）。以下では、データ分割の手法について説明しましょう。

コラム2　いろいろなアプローチ

　大規模サイトの運営に当たって問題を解決していくというのは、実にさまざまな選択肢の中から1つの手法を選ぶことです。資金に余裕があれば、高価なハードウェアを投入することで多くの問題を解決できますし、逆に強力なエンジニアリングパワーがあれば、資金がなくてもソフトウェアでもさまざまな問題を解決できます。

　また、問題が起こったときに「解決のためのコストを割けない、やる気がない」という場合には、そのアプリケーションやサイトを売却してビジネス的なゴールとすることも当然可能です（この場合、ちょっと違ったスキルが必要となりますが）。

　重要なのは、開発チームや会社として、ある程度基本的なスタンスを決めておくことだと考えられます。例えばGREEでは現在のところ、

• ハードウェアはPCサーバ1種類のみ（メモリやHDD、CPUの多少異なるケースがあるものの、ほぼすべて同じハードウェア）
• 商用ソフトウェアやアプライアンスサーバは利用しない
• 後はソフトウェアで解決する

というスタンスで問題解決の方法を考えています。

テキストデータの分離

　データの分割手法として、データベーステーブルに含まれるテキスト型のフィールドを別のストレージ、あるいは別のサーバに分離するという方法があります。例えばブログのデータを保存するための、リスト1のようなスキーマを持つテーブルがあるとします。

blogテーブル:
+----------------------+----------+------+-----+---------+-------+
| Field                | Type     | Null | Key | Default | Extra |
+----------------------+----------+------+-----+---------+-------+
| id                   | int(11)  |      |     | 0       |       |
| user_id              | int(11)  | YES  |     | NULL    |       |
| publication_datetime | datetime | YES  |     | NULL    |       |
| title                | text     | YES  |     | NULL    |       |
| content              | text     | YES  |     | NULL    |       |
+----------------------+----------+------+-----+---------+-------+

リスト1　ブログのデータを保存するテーブル

図1　テキストデータを分割する

　このとき、titleとcontentフィールドがWHERE句*の条件となることはまずありません。非常に小規模なアプリケーションでは、LIKEなどを利用*することもあるかもしれませんが、それなりの規模になると、こういったテキストフィールドをLIKE検索するのは自殺行為になってきますし、あるとしても特殊なケースで、通常は別途全文検索用のサーバを構築して、そちらで検索を行うのが一般的かと思います。

　そこで、WHERE句の対象にならない、つまりプライマリキーを利用してコンテンツを取得、あるいは更新するだけのテキストフィールドを、リスト2のように、

1. メタデータのみを持つテーブル
2. 1のメタデータと1:1で関連づけられるテキストデータを持つテーブル

に分離するという手が使えます（図1）。

blogテーブル:
+----------------------+----------+------+-----+---------+-------+
| Field                | Type     | Null | Key | Default | Extra |
+----------------------+----------+------+-----+---------+-------+
| id                   | int(11)  |      |     | 0       |       |
| user_id              | int(11)  | YES  |     | NULL    |       |
| publication_datetime | datetime | YES  |     | NULL    |       |
+----------------------+----------+------+-----+---------+-------+


blog_textテーブル:
+----------------------+----------+------+-----+---------+-------+
| Field                | Type     | Null | Key | Default | Extra |
+----------------------+----------+------+-----+---------+-------+
| id                   | int(11)  |      |     | 0       |       |
| title                | text     | YES  |     | NULL    |       |
| content              | text     | YES  |     | NULL    |       |
+----------------------+----------+------+-----+---------+-------+

リスト2　ブログのデータを分割して保存する

　テキストデータに関しては、場合によってはデータベースである必要すらなく、単純なテキストファイルでもよいかもしれません。そして、

• 2の保存先を1を持つデータベースサーバから切り離す
• テキストデータは、メタデータを検索後にそのプライマリキーを利用して必要に応じて取得／更新を行う

というようにアプリケーションを構築します。実際にはこの処理をデータアクセスレイヤーで吸収し、アプリケーションに掛かるコストを抑えるのがよいでしょう。

　ブログやSNSのように、テキストフィールドが大半を占めるようなテーブルが存在する場合、このようなテキストデータの分離は、比較的低コストで、またアプリケーションの動作を特に制限することなくパフォーマンスを向上させることが可能です。

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

サチュレーション

英単語のsaturationで、「飽和する」の意。IT業界では、マシンなどの性能を限界まで使い切ってしまうことを指すが、特に処理が追いつかないことで再送処理などを生み、処理を増やすという負の連鎖を指すことが多い。

WHERE句

データベースのテーブルからレコードを抽出するときに、条件を指定するためのSQL構文。

LIKEなどを利用

ワイルドカードを使ってテキストデータを検索するためのSQL演算子。