DBMS導入事例：PostgreSQL
PostgreSQLで効率的な負荷分散を実現し、モバゲーやmixiを追撃
携帯電話向けのSNSサイトを運営するオープンドアは、システム基盤にPostgreSQLを採用。サービス別のDB分散とPostgreSQLの拡張ツールを活用したDBレプリケーションにより、効率的な負荷分散の仕組みを構築した。
オープンソースの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が、今後どのような展開を見せるのか注目である。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
新着ホワイトペーパー PR
-
製品資料
[株式会社MatrixFlow] 「物流リソース最適化」ガイド：人員・配車・傭車を出庫依頼の確定前に決めきる -
製品資料
[株式会社キーエンス] なぜRPA導入は頓挫する？ シナリオ作成の壁を乗り越える解決策とは -
製品資料
[株式会社セールスフォース・ジャパン] 「CRMは設計と無関係」は本当か？ PLMとの融合で実現する高速開発 -
事例
[日本ヒューレット・パッカード合同会社] AIエージェントの時代にどう備える？ 「新たな働き手」を支える3要素とは -
製品資料
[日本ヒューレット・パッカード合同会社] “横並びの自動化”から脱却、AI活用で生産性と競争力を高める秘訣
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
法務と開発者で「言葉が通じない」問題 トヨタやソニーが語るOSS管理の真実
-
2
なぜ「全社配布Copilot」は使われないのか？ 失敗に学ぶAI定着
-
3
なぜ「Gemini 4 Argon」は出遅れたのか？ Googleが狙う“逆転のシナリオ”
-
4
ChatGPTは“検索しまくり”でGeminiは“淡泊”？ データが明かすAIの裏側
-
5
損保ジャパンはなぜ「COBOL」を捨てなかったのか？ 脱メインフレームの真相
-
6
情シスの約8割が転職や退職を意識 調査で分かった“辞めたくなる最大の理由”
-
7
「結局使わなくなる」Microsoft 365 Copilotを半年で定着 キリンの3施策
-
8
「Wi-Fi 7」経由でWindowsが乗っ取られる？ 最高権限奪取の恐怖
-
9
「中堅・中小企業のネットワーク・セキュリティ運用実態」に関するアンケート
-
10
情報漏えいはなぜ繰り返されるのか 今すぐ見直すべき「境界」
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化？ 2026年夏の3事例から見えた動向と対処方法
-
2
家庭用Wi-Fiルーターの業務利用は危険？ 避けるべき理由と具体的な対策
-
3
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
4
財務部門がAIを最大限に活用する方法 無駄のない戦略的リーダーシップへの道
-
5
LLMが兵器化？ 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
6
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
7
なぜRPA導入は頓挫する？ シナリオ作成の壁を乗り越える解決策とは
-
8
生成AIを開発に導入しても効果が見えない？ 実証実験で分かった成果と課題
-
9
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ？
TechTargetジャパン SNS
@techtarget_itmをフォロー
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー