SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

最新イベントはこちら!

Enterprise IT Women's Forum

2025年1月31日(金)17:00~20:30 ホテル雅叙園東京にて開催

Security Online Day 2025 春の陣(開催予定)

2025年3月18日(火)オンライン開催

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けの講座「EnterpriseZine Academy」や、すべてのITパーソンに向けた「新エバンジェリスト養成講座」などの講座を企画しています。EnterpriseZine編集部ならではの切り口・企画・講師セレクトで、明日を担うIT人材の育成をミッションに展開しております。

お申し込み受付中!

EnterpriseZine(エンタープライズジン)

EnterpriseZine編集部が最旬ITトピックの深層に迫る。ここでしか読めない、エンタープライズITの最新トピックをお届けします。

『EnterpriseZine Press』

2024年秋号(EnterpriseZine Press 2024 Autumn)特集「生成AI時代に考える“真のDX人材育成”──『スキル策定』『実践』2つの観点で紐解く」

DB Magazineスペシャル

DeNAの人気サイトに学ぶ LAMPによるWeb-DBシステム構築/運用の極意(前編)

エンタープライズでのオープンソース使いこなし術


株式会社ディー・エヌ・エーでは、オープンソースソフトウェアを活用して、「モバオク」「モバゲータウン」などのWeb/携帯電話向け大規模サービスを開発/運営している。特にMySQLについては数百台単位でレプリケーション運用しており、新しいオープンソースソフトウェアの導入も積極的に行なっている。本パートでは、このような実績を通して見い出されてきたWeb-DBシステムの構築/運用ノウハウを紹介していく。  (DB Magazine 2007年6月号より転載)

モバオク/モバゲータウンとは

 「モバオク」(画面1)は、株式会社モバオクが運営する携帯電話およびPC向けのオークションサービスで、2007年2月末時点での有料会員数84万人、出品数284万品、1日のページビュー数7000〜8000万という規模である。

画面1:「モバオク」公式サイトトップページ
画面1:「モバオク」公式サイトトップページ

 「モバゲータウン」(画面2)は、株式会社ディー・エヌ・エー(以下、DeNA)が運営している携帯電話サービスで、無料ゲームやSNSを提供している。こちらは2007年3月時点の会員数が400万人で、1日のページビュー数も3億を超えている。

画面2:「モバゲータウン」のトップページ
画面2:「モバゲータウン」のトップページ

 このように、どちらもサービスとしては世界最大級の規模となっている。システムはどちらもDeNAが開発/運用しており、LAMPベースでMySQLのレプリケーションを多用しているという特徴がある。MySQLのスレーブサーバーだけでも、モバオクは約50台、モバゲータウンは約200台を運用している。このような大規模システムであるが、各サービスとも5人程度のメンバーで開発/運用両面を担当している。

 以降では、両システムで利用しているオープンソースソフトウェアの開発/運用ノウハウについて紹介する。

MySQLの活用/運用術

レプリケーションの活用

 MySQLには、標準でシングルマスタの非同期レプリケーション機能が搭載されている注1(図1)。レプリケーションはDBの複製を用意する仕組みで、一般的にこの複製を多数用意して参照系クエリの負荷分散に利用する。

図1:シングルマスタ非同期レプリケーションの概念
図1:シングルマスタ非同期レプリケーションの概念
注1

 PostgreSQLでもSlony-Iという非同期レプリケーションの仕組みが用意されている。

 シングルマスタの非同期レプリケーション機能では、マスタサーバーが1台に限定され、マスタからスレーブへの複製は非同期で行なわれるため遅延が生じ、短時間のスケールで見ると全スレーブとの同期が保証されない。しかし、その反面スレーブの台数を増加させていってもマスタサーバーの更新負荷は大きくならず、スケーラビリティを維持できるという利点がある。DeNAによる運用実績でも、マスタとスレーブ間の遅延は通常数秒程度以内に収まる。

 このレプリケーションを利用する場合、アプリケーション側ではデータ更新時にはマスタサーバーへ接続し、データ参照のみを行なう場合はスレーブサーバーへ接続するように作成する必要がある。

 Webや携帯電話向けサービスの場合、小さな規模で始めてユーザー規模、データ規模、ページビュー数を徐々に増加させていくことが多い。小さな規模のためDBの負荷分散が不要な場合でも、マスタサーバー1台、スレーブサーバー1台の構成にしておけば、マスタサーバーに突然障害が起きてもまったく同じデータがスレーブサーバーに常時コピーされるので、スレーブサーバーを新マスタサーバーとして利用できる。

マスタ分割/参照分割をあらかじめ想定する

 データ更新の頻度が高く大量な場合、単一のマスタサーバーによる運用だとスレーブ側はマスタから流れてくるレプリケーションデータに基づく更新を行なうだけで手一杯になり、参照要求に十分に応えられなくなる。システム規模の拡大により、このような状態になった場合、「マスタ分割」という作業が必要になってくる。

マスタ分割とは

 マスタ分割とは、文字通り複数のマスタサーバーを用意し、読み書きするテーブルによってアプリケーションから接続するDBを使い分ける方法である。

 モバオクシステムでの分割の例を図2に示す。

図2:MySQLレプリケーションの構成図
図2:MySQLレプリケーションの構成図

 モバオクシステムでは、サービス開始から1年ほど経ったタイミングで、ユーザー系テーブルと出品系テーブルにマスタ分割を行なった。出品系テーブルには、出品情報(商品名、商品説明、開始価格など)のほか、出品物に関するQ&A情報や、入札情報などが含まれる。ユーザー系テーブルには、出品系テーブル以外のデータ、つまり会員情報、落札後の取引情報(落札者/出品者の連絡先情報や支払い/送付方法の選択など)、評価(オークションの取引を通しての感想を落札者/出品者相互に評価したデータ。取引相手が信頼に足るか判断する材料とする)などのデータが含まれる。

 出品系テーブルとユーザー系テーブルは将来的にマスタ分割することを想定していたため、開発開始時から1つのSQLでJOINしないような作りにしている。

 また、出品数が増えた場合、出品ID(個々の出品を識別するユニークなID)を分割数で割った際の余り値で収容マスタを決定することで分散できるようになっている。例えば、出品系テーブルを2系統にマスタ分割する場合、出品IDを2で割った余り(出品ID % 2)が0であるか1であるかで、INSERTするマスタサーバーを切り替えるような処理が可能である(LIST1)。

LIST1:出品ID % 2でマスタサーバーのハンドルを切り替える例(Perl)
sub _getItemHandle {
my $item_id = shift;
if ($item_id % 2 == 0) {
return DA::getHandle($_::ITEM_M1);
} else {
return DA::getHandle($_::ITEM_M2);
}

参照クエリを高速処理する参照分割

 さらに、同じマスタに収容されているテーブルでも、参照するテーブルによって接続するスレーブを分ける「参照分割」も有効である。OSのファイルキャッシュも含め、テーブルやインデックスのデータがすべてメモリに載ってしまうとディスクI/Oが発生しないため、参照クエリを高速に処理できる。

 モバオクでは、ユーザー系マスタサーバーに収容されている評価系テーブルとそれ以外のユーザー系テーブルとの間で参照分割を行なっている。もし、それぞれで6GBの容量を占めていたとすると、両方をメモリに載せるためには12GB以上必要となる(恐らく実際は16GB程度のメモリが必要だろう)。

 しかし、参照分割を行なうのならば、それぞれが6GBのメモリで済むため、8GBのサーバーが2セットあれば事が足り、メモリ購入費用も抑えられる注2(図3)。ただし、この参照分割の場合もアプリケーション側では評価系テーブルとそのほかのユーザー系テーブルとをJOINするようなSQLは利用しないことが前提になる。また、これを前提にしておけば、基本的にマスタ自体を分割することも可能である。

図3:参照分割
図3:参照分割
注2

 実際にはレプリケーションにより参照範囲以外のデータも更新されるので、ここまでくっきりとは分かれないが、ここでは単純化して説明している。

 モバオクでは、マスタ分割は2系統、参照分割は3系統で行なっているので、アプリケーションのロジック側では更新/参照するテーブルを考慮して5つのDBハンドルを使い分けている。ただし、これはどのテーブルがどのハンドルに関連付けられているか、またデータ参照のみか更新を含むかによって判断が付くので、アプリケーションの開発上は特に問題になっていない。

次のページ
Web サーバー/スレーブDB サーバー間の負荷分散

この記事は参考になりましたか?

  • Facebook
  • X
  • Pocket
  • note
DB Magazineスペシャル連載記事一覧

もっと読む

この記事の著者

能登 信晴(ノト トキハル)

株式会社ディー・エヌ・エーにて、ケータイ向けサービス開発と運用を担当。以前はソリューション事業の一環で顧客企業向けコンサルティングや提携サイト構築プロジェクト統括なども行なっていた。「DeNA 技師のメモ」更新中。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

早乙女 正巳(サオトメ マサミ)

株式会社ディー・エヌ・エーにて、ケータイ向けサービス「モバコレ」の立ち上げと運用を担当。以前はディー・エヌ・エーのPC サービスの開発を幅広く担当していた。モバコレに関しては1 人で物流/決済などを含むすべての開発を約2 ヶ月で行なった。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

EnterpriseZine(エンタープライズジン)
https://enterprisezine.jp/article/detail/25 2008/12/09 12:06

Job Board

AD

おすすめ

アクセスランキング

アクセスランキング

イベント

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング