PostgreSQLで効率的な負荷分散を実現し、モバゲーやmixiを追撃

携帯電話向けのSNSサイトを運営するオープンドアは、システム基盤にPostgreSQLを採用。サービス別のDB分散とPostgreSQLの拡張ツールを活用したDBレプリケーションにより、効率的な負荷分散の仕組みを構築した。

公開 2008年02月28日 10時00分

更新 2012年09月06日 13時12分

[石田己津人]

印刷する

オープンソースのPostgreSQLでシステムを構築

　10代、20代を中心に急激な普及を見せる“ケータイSNS”。会員数が865万人に達する「モバゲータウン」や月間118億ページビュー（PV）を誇る「mixi」（約6割がモバイル経由）など、大手SNSサイトが存在感を増している（数値はいずれも2007年12月現在）。そうした中で先行組を激しく追撃しているのが、オープンドアが運営する携帯電話向けのSNSサイト「大集合NEO」だ。

　2007年1月にスタートした大集合NEOは、SNSのみならず、アバターやゲーム、小説、動画、日記、チャットなどのサービスをすべて無料で楽しめるのが特徴だ。アバターやサイト内通貨の使い勝手の良さで先行サイトと差別化を図り、2007年夏に50万人だった会員数が2008年2月時点で2倍の100万人に達している。

　その大集合NEOのシステム基盤を担っているのは、MySQLとオープンソースデータベース（DB）の双へきを成す「PostgreSQL」である。

Web事業部第3事業グループシステム開発チーム
課長代理清水敏彦氏

　システム開発チームの清水敏彦氏は、「収益の見通しを立てづらい新規事業立ち上げの段階で、商用DBの採用は考えていませんでした。そのため、オープンソースソフトウェアのPostgreSQLとMySQLを比較検討し、性能の良さと社内での利用実績からPostgreSQLを選びました」と導入の経緯を語る。

　オープンドアは、総合旅行情報サイト「トラベルコちゃん」を始めとするWebサイトを幾つも手掛けるとともに、PostgreSQLによる開発・運用ノウハウを長年蓄積してきた。そのため、大集合NEOのシステム構成においても、LinuxをプラットフォームにWebサーバのApache、プログラミング言語のPHP、PostgreSQLという、社内で実績のある組み合わせを選択したというわけだ。

　しかし、大集合NEOを立ち上げるに当たっては、従来のWebサイトとは決定的に違う点があった。それは、事業計画の当初から急ピッチな会員数やアクセス数の伸びが想定されており、「早い段階で過去に経験したことのないアクセス数に達することが見込まれていました」（清水氏）。

pgpoolとSlony-lを組み合わせてレプリケーション

　その予想は的中した。サービス開始直後の2007年2月には、会員数が5万人、月間PVは2000万近くとなり、Webサーバ1台とDBサーバ1台という最小構成では限界に達したのだ。加えて、携帯電話向けのWebサイトでは小さなトランザクションが大量に発生するため、DBサーバへの負荷が大きくなるという問題も事態の悪化に拍車を掛けていた。

　そこで大集合NEOの開発チームは、PostgreSQLを中心としたオープンソース製品のサポートを手掛けるSRA OSSに技術コンサルティングを依頼した。同社からの提案は、どちらもPostgreSQL向けの拡張ツールであるコネクションプールサーバ「pgpool II」とレプリケーションソフト「Slony-l」を併用したマスター・スレーブ方式の負荷分散だった。

　pgpool IIは、アプリケーションの要求に応じてDB接続を逐一行わず、プールしたDB接続を使い回してオーバーヘッドを減らす「コネクションプーリング」と、更新クエリはマスターへ、参照クエリは参照専用のスレーブもしくはマスターへ振り分ける「ロードバランス機能」を主な特徴としている。一方のSlony-lは、マスターからスレーブへ更新データを非同期モードで転送しDBレプリケーションを行うというものだ。

　大集合NEOでは、マスター1台に対してスレーブ3台を配置したDBレプリケーションを導入し、急増し続けていたクエリを分散した。さらに清水氏は、「性能のボトルネックを調べ、高速ディスクを採用したりクエリやプログラムの見直しを行いました。そのおかげでシステム性能は全体的に改善し、危機的な状態を乗り越えることができました」と当時を振り返る。

各DBサーバの負荷が高まればマスタ・スレーブ構成に移行。さらに負荷が増えれば、スレーブを増設していくことで参照クエリを細かく分散する

　それでも、pgpool IIやSlony-lによるDBレプリケーションには課題もあった。マスターで実行されたデータ更新が各スレーブへ反映されるまでの遅延である。マスターとスレーブのデータ更新を独立して行う非同期方式のSlony-Iでは構造的に遅延が避けられないが、大集合NEOでも「最大10秒ほどのズレが生じたため、ユーザーが書き込んだ内容を即座に参照できないケースが出てきてしまいました」と、清水氏は打ち明ける。

　大集合NEOにはユーザーが書き込みを行うサービスが多く、DBクエリの2割近くが更新系となっている。そのため、更新処理が集中するマスターはもとより、同様にデータ更新を行わなければならない各スレーブでも全般的にサーバ性能が劣化し、DBレプリケーションに遅延が発生しやすくなっていたのだ。

　「アクセス数に対して、サーバの数が絶対的に足りませんでした」（清水氏）

サービス別のDB分散とDBレプリケーションの併用

　そうこうしている間にも会員数とPVは急増した。2007年春には、早くもさらなる負荷分散が必要になったのだ。そこで大集合NEOの開発チームは、SRA OSSの技術コンサルティングを受けながら新しい仕組みを導入した。

　それは、日記、足跡、伝言板といったサービスごとにDBのテーブルを切り出すことだった。その上で、アクセスの多い主要サービスを個別にpgpool IIやSlony-lによるマスター・スレーブのDBレプリケーションで負荷分散するようにしたのだ。現在は20数台のDBサーバで分散（一部のDBサーバは複数サービスのテーブルを搭載）し、そのうちの約半数がマスター・スレーブ構成である。「各サービスは独立しているので複数テーブルをJOINすることはあまりなく、DBを分散してもアプリケーションは複雑になりませんでした」と、清水氏は語る。

　この手法のメリットは、サービスが増えるごとにDBサーバを追加し、負荷が高まれば個々にDBレプリケーションを導入できる点にある。つまり、柔軟なDBサーバの拡張が可能なのだ。2007年春から1年近くが経過した今でも、この負荷分散の仕組みに変わりはない。

　そして負荷分散とサーバマシンのスケールアップにより、課題だったDBレプリケーションの遅延も今や1秒以下に抑えられている。さらに、遅延が絶対に許されないデータ更新についてはpgpoolで参照クエリもマスター側へ振り分けるように設定し、ユーザーレベルでの更新遅延を根絶している。

　SRA OSSによれば、大集合NEOはPostgreSQLを活用する国内の携帯電話向けWebサイトの中では最大規模だという。清水氏は、「ライセンス不要のPostgreSQLを採用したことで機動的にシステムを増強できました。PostgreSQLの安定性の高さは、サービスの開発や品質維持に貢献してくれています」と話す。

　大集合NEOが業界トップのモバゲータウンを追撃するには、まだまだ会員数とPVを増やし続けなければならない。大集合NEOの開発チームは、性能が向上したといわれるPostgreSQL 8.3へのバージョンアップやクラスタリング構成による可用性向上なども検討中だ。コンテンツプロバイダーの生き残り競争が始まった携帯電話向けSNSサイトの中で、PostgreSQLで高性能インフラを手に入れた大集合NEOが、今後どのような展開を見せるのか注目である。