DBmagazine DeNAの

72万ユーザーをオープンソースでカバー
特集
株式会社ディー・エヌ・エー能登信晴 NOTO, Tokiharu
ディー・エヌ・エー（DeNA）が構築／運用する携帯向けオー
マンスについてはMySQLのInnoDBエンジンによる大量の
クションサービス「モバオク」は、会員数72万人、ページビュー
更新トランザクション処理をはじめ、Parl＋C言語を利用した
1日6000∼7000万にのぼるメガサイトである。携帯サイト
独自開発のDBアクセス機能やオンメモリDB、DB検索エンジ
には情報量、パフォーマンス、操作性など制限が多いが、モバ
ンにより実現している。本稿では、モバオクのシステム設計／
オクのシステムはLAMP（Linux＋Apache＋MySQL＋Perl）
構築、サービス開始後のシステム運用と拡張作業の2パートに
を利用することでこれらの問題を解決している。特に、パフォー
分けて、詳しく解説する。
PART
72万会員、1日7000万PVを
LAMPで支える
「モバオク」システム構築のポイント
PART
システム拡張から障害対策まで
快適なモバオク利用を実現する
運用管理の工夫とテクニック
S P E C I A L
F E A T U R E
2
PART
72万会員、1日7000万PVを
LAMPで支える
「モバオク」
システム構築のポイント
1
「モバオク」と
そのシステム規模
っている。このシステムはいわゆるLAMP
（Linux＋Apache＋MySQL＋Perl）で構
築されているが、C言語などで独自開発し
「モバオク」
（http://mbok.jp/）
は、株式
たユニークな部分も多い。また、初期構築
会社モバオクが運営するケータイ向けオーク
時からスケーラビリティを考慮していたた
注1
ションサービスである。携帯電話が1つあ
め、当初の設計のまま大きな変更を行なわ
ればいつでもどこでも
「すきまの時間」を使
ずに現在のシステム規模にまで対応できて
って出品／入札できるという手軽さが特徴
いる。
で、2006年9月末時点の有料会員（月額315
本特集では、モバオクシステムの設計と構
円）数は72万人、出品数は231万品、ペー
築、サービス開始後のシステム運用と拡張作
ジビューは1日あたり6000∼7000万と、ケ
業の2パートに分けて、できるだけ詳しく、こ
ータイサービスの世界では有数のメガサイト
のスケーラビリティを実現している秘密とユ
となっている
（画面1）
。2004年3月のサービ
ニークな独自開発部分や運用の実態を説明
ス開始以降、図 1に示すように会員数、出
していく。LAMP、特にMySQLの大規模
品数ともに成長を続けており、現在では利
運用事例として、多数の読者の参考になれ
用サーバー数は100台以上、DBデータ量
ば幸いである。
も100GBを超えている。
モバオクのシステム構築と運用は、株式
会社モバオクの親会社にあたる株式会社
注1：au携帯電話から接続する場合は、
「auオークション」と
いうブランドで提供される。
ディー・エヌ・エー（以下、DeNA）注2 が行な
注2：http://www.dena.ne.jp/
250
200
■ 無料会員数（万人）
■ 有料会員数（万人）
■ 期末出品数（万品）
150
100
50
0
04/1Q
図1
3Q
モバオクの会員数と出品数の推移
05/1Q
3Q
06/1Q
画面 1
携帯オークションサイト「モバオク」の
トップページ
特集
以降では、これらの開発方針に基づいて、
たため、どのくらい投資すれば利益が出る
モバオクシステムの
開発方針と体制
かの見込みも立たず、もしユーザーからの
実際にどのように開発が行なわれてきたの
支持が得られなかった場合はサービス自体
かを説明していく。
モバオクシステムの開発は、2003年11月
を取りやめることも想定していた。そのため、
下旬から2004年3月上旬までの約4ヶ月で
ソフトウェア、ハードウェアともにコストをかけ
行なわれ、その開発方針には大きく次の4つ
ずに構築から運用／拡張までを行なってい
があった。
く方針とした。
一般オークションサイト
と異なるサービス設計
③のパフォーマンスは、ユーザーにとにか
ビッダーズからの脱却
① シンプルで分かりやすいサービス
く軽快な使用感を提供したいという考えに
② 低コスト
（初期、拡張、ランニング）
基づいている。モバオクはコストをあまりか
モバオクシステムの開発を開始した2003年
③ パフォーマンスとスケーラビリティを重視
けずにサービスを開始するいわゆる「スモ
11月当時、DeNAにはすでにビッダーズが存
④ スーパーエンジニア1人が要件定義から
ールスタート」の形態をとったが、ユーザー
在していた。ビッダーズは、MSNオークション
リリースまでを一貫して行なう
の支持を得られた場合、当時から DeNA
やWoman.exciteオークションなど、提携サ
で運営していたショッピング／オークション
イトと共通したプラットフォームになっており、
①は、ケータイ画面の大きさには制約がある
サービス「ビッダーズ」
（http://www.
当時すでに全体で200万人以上の会員、約
こと、従来のPCオークションに馴染みのない
bidders.co.jp/、画面2）
と同程度の規模ま
100万品の出品数、1日あたり約800万ペー
ユーザーの利用も予想されることから来てい
で拡大するだろうと予測していた。そのた
ジビューの規模となっていた。このような場
る。また、サービスをシンプルにすることでシス
め、具体的には出品数100万、1日1000万
合、一般的に既存の会員体系を引き継ぎ、
テム側もシンプルにでき、将来的な機能のメン
ページビューまで対応できるスケーラビリテ
システムも既存のものを携帯サービスに展開
テナンス性も高められるという読みもあった。
ィを実現すべく設計／構築を行なうことにし
することが検討されるが、モバオクは別個の
②は、当たり前のことだがビジネスとして
た。②と③は一見相反する事象のように見
システムとして構築されることになった。その
コストを低く抑えられれば、その分利益率を
えるが、DeNAが開発したモバオクをはじめ
理由として、主に次の2つがある。
高められるというところから来ている。さら
とするモバイルサービスでは十分に両立で
に、サービス開始前は現在ほど多くのユー
きていると自負している。
ザーに支持されるという予測はしていなかっ
●
モバオクは純粋な個人間（C2C）
オークシ
④の背景には、当時のDeNA社内の一般
ョンを志向していたが、ビッダーズでは「ク
的な開発手法では要件定義者と設
ラブビッダーズ」
という有料店舗メニュー
計／実装者が分かれており、設計／
も提供しており、ショッピング（B2C）の傾
実装は多人数のチームで行なってい
向が強くなってきていた
たという状況がある。一方、モバオク
●
ビッダーズはすでに大きな
「マーケット」にな
システムの開発ではすべてを独力で
っており、提携サイトを含め社内外にステー
こなせる1人のスーパーエンジニアが
クホルダーが多く、システム変更を行なう際
一貫して担当した
（筆者ではないが）
。
の調整コストが大きくなってきていた
そのため、メンバー間のコミュニケーシ
画面 2 「ビッダーズ」のトップページ
ョンコストが発生せず、約4ヶ月という
そのため、あえて会員体系、システムとも
短期間の開発でサービス開始までこ
ビッダーズから独立したものとし、既存資産
ぎつけることができたのである。
より柔軟かつ機動的なサービス開発／運用
現在では、DeNAグループのモバ
を選択することになった。また、これにより
イルサービス開発の多くでこの手法が
既存資産から離れて自由なシステム設計も
利用されている。また、50％程度の完
可能となった。ただ、テーブル構造につい
成度で関係者に試用してもらい、そこ
ては事前にビッダーズのものを参照し、オー
からブラッシュアップしていくという手
クションで一般的に必要となるデータ構造
法も採用している。
を把握していた。
72 万会員、1 日 7000 万 PV を
LAMP で支える
「モバオク」
システム構築のポイント
PART
1
携帯サイトは最初からアフィリエイト対応を
最近では、携帯サイトへの集客などのためにアフィ
リエイト ASP を利用することが一般的になってきて
いる。アフィリエイト ASP では成果ベースで報酬が
発生するため、サイト側でどの ASP から誘導された
ユーザーがどのような成果アクション（入会、購入な
ど）を行なったかをトラッキングして、最終的に ASP
へ通知する。ASP は、この通知に基づいてサイトへ
の成果報酬を請求するわけだ。
PC サイトの場合、ほとんどの Web ブラウザがクッ
キー対応しているため、アプリケーション側の対
応はほぼ不要である。入会、購入などの成果が発
生する画面の HTML に ASP 指定の IMG タグを
入れれば、その IMG タグで指定された URL から
クッキーが回収され、成果が把握される。
一方、携帯サイトの場合、ブラウザのほとんど
がクッキーに対応していないため、別の仕組みが
必要になる。ユーザーが誘導される際は、ASP
から誘導を識別するための ID などのパラメータ
が誘導先サイトのURL に渡される。サイト側アプ
リケーションでは、画面遷移の間もそのパラメー
タを保持し続け、入会、購入などの成果アクショ
機能の取捨選択
ンが行なわれるタイミングでASPへ通知する
（図A）
。
したがって、携帯サイトのシステム構築時は、最初
からこの機能を持たせるように作っておくと後々便利
なのだが、実は、どのページでもこのパラメータ受け
取りと保持ができるようなシステムになっていれば、
誘導元からユーザーアクションまでの汎用的なトラッ
キングシステムにできる。これがあれば、広告利用
やキャンペーン実施時にどれくらい効果があったかも
把握でき、広くマーケティングに活用できる。
アフィリエイトASP
誘導IDなどの
パラメータ付き
誘導
成果
通知
受け取った
パラメータ付き
パラメータ保持
「ようこそ」
サイト内
画面推移
成果発生
入会／購入
完了画面
自社サイト
図A
携帯サイトにおけるアフィリエイト利用の仕組み
携帯電話のカメラで撮った画像を出品画像
にできる点である。PCオークションサイトへの
シンプルで分かりやすいサービスを実現
出品の場合、デジタルカメラか携帯で撮影し
するため、提供する機能は絞り込んだ。例
た画像ファイルを1度PCに移し、それを出品
えば、ビッダーズには最低落札価格という、
時にアップロードする必要がある。それに比
その価格を上回らなければ落札できない価
べ、モバオクの出品操作は携帯ユーザーの
格を開始価格とは別に設定できるが、この
多くがなじんでいる画像付きメールで行なえ
機能は不要と判断して実装しなかった。出
るので、はるかに手軽である。サイト上で出
品物を目立たせるためのスタンプや背景色
品操作を終えると、モバオクから画面4のよ
オプションも用意していない（画面3）。
うなメールが届き、出品者はこのメールに対
オークションサイトへの出品経験がある方な
ら覚えがあると思うが、たいていの場合、
し画像付きメールを返信するだけで画像掲
載を行なえる。
出品時の入力／設定項目が多く、この項目
を減らすだけでもユーザーの出品への抵抗
感を大きく減らせるはずという考え方である。
基盤ソフトウェアの選択
画面 3
入力項目の少ないモバオク出品画面
また、落札されなかった商品の自動再出
品機能は実装されているが、デフォルトではオ
フとなっている。これは、出品者が本気で売
モバオクシステムを構築した際の基盤ソフ
トウェアは、次のようになっている。
るつもりがない商品や購入者にとって魅力的
ためという面もあるが、さらに軽快かつ安定
したレプリケーション機能が標準で提供され
ていたというのが一番大きかった。レプリケ
ではない商品がサイトにとどまり続けることは
DB：MySQL 4.0.x
ーションはDBの複製を用意する仕組みで、
望ましくないと判断したためである。このよう
開発言語：Perl 5
一般的にこの複製をたくさん用意して負荷分
に、一般的なオークションサイトにある機能の
Webサーバー：Apache 1.3.x＋mod_
散に利用する。MySQLが標準で提供する
1つ1つについて吟味し、要不要を判断して
fastcgi
のはシングルマスターの非同期レプリケーショ
無駄をそぎ落としたサービスとした。
写メールによる画像登録
一方、使いやすさでこだわったところは、
MySQL の選択
データベースにMySQLを選択した理由に
は、開発方針の1つでもある低コスト実現の
ンである
（図2）
。
シングルマスターの非同期レプリケーション
では、マスターサーバーが1台に限定され、
マスターからスレーブへの複製は非同期で
特集
あるため遅延が生じ、短時間のスケールで
見ると全スレーブとの同期が保証されない。
まったのもモバオクサービス開始後の2004年
注3
6月であり、検討対象にならなかった。
り、
「慣れ親しんでいるプログラミング言語を
アプリケーション開発にも使用すべきと考え
しかしその反面、スレーブの台数を増加さ
せていってもマスターでの更新負荷は大きく
や細かなツールを作る際にPerｌを使ってお
InnoDB ストレージエンジンの選択
て選択した結果である」
と述べている。
ならず、スケーラビリティを維持できるという利
オークションサービスでは、参照だけでな
点がある。オークションの場合、入札から結
く出品、入札、出品物に関するQ&Aなど、
果表示までのタイムラグが数秒であれば許容
更新トランザクションも多い。MySQLではテ
図3に示すように、Apacheと独立した複数
範囲と考えているが、MySQLのレプリケー
ーブルの型（ストレージエンジン）
を選択でき、
のアプリケーションプロセスが常時起動し、
ション遅延はこの範囲に収まる。
参照中心の一般的なWebアプリケーション
UNIXドメインソケット注6 経由でApacheと通信
ただし、アプリケーションはデータ更新時は
では「MyISAM」
というストレージエンジンが
する仕組みが「FastCGI」である。アプリケー
マスターサーバーへ接続し、データ参照のみ
使われることが多い。これはテーブル単位の
ションプロセスは常時起動（永続化）
されてい
を行なう場合はスレーブサーバーへ接続す
ロック機構のみ用意され、
トランザクションも
るため、一般的な CGI のようにリクエストご
注4
Apache 1.3.x＋mod_fastcgiの選択
るように作成する必要がある。今でこそ
サポートされていないが、参照は高速だ。
とのプロセス起動が発生しない。リクエスト単
MySQLのレプリケーション機能の安定性／
一方、
「InnoDB」
というストレージエンジン
位のプロセス起動を省略できるPerlの処理系
高速性には定評があるが、モバオク開発当
は、
トランザクションをサポートし、行レベルの
にはmod_perlもあるが、モバオクシステムで
時はそれほど事例が公開されていなかった
ロックにも対応するため読み書きの並行処理
FastCGIを選択した理由は次の2つだ。
こともあり、独自にレプリケーション負荷試験
性能に優れるが、参照はMyISAMより遅い
を行ない、実用的な安定性と性能が出るこ
と言われている。開発の事前調査として、こ
とを確認した。PostgreSQLにも
「Slony-I」
の2つのストレージエンジンの比較実験を行
と独立するため、アプリケーションの問題
という同様のシングルマスターの非同期レプ
なったが、それぞれ1000万レコードを作成し
でApacheの動作自体に影響を与えるこ
リケーション機能があるが、ベータテストが始
てSQLを大量発行し、ほとんど参照のみと
とがない
いう状態から更新比率を増やしていったとこ
●
●
アプリケーションのメモリ空間が Apache
アプリケーションプロセス単位の常時起動
ろ、更新の割合が多くなるにつれてInnoDB
数を、Apacheプロセス数とは独立して細
の性能のほうが高くなることが判明した。こ
かく設定できる
のため、モバオクではInnoDBストレージエン
ジンをほぼ全テーブルで利用している。
なお、モバオクシステムの開発開始当初、
MySQL 4.1は「production（正式版）
」
とな
モバオクシステムでは、原則1サーバーあ
たり25アプリケーションプロセスを起動する
設定にして運用しているが、ほかにもPC向
注5
っていなかったので選択肢としなかった。
注3：http://gborg.postgresql.org/project/slony1/news/newsfull.
php?news_id=174
Perl 5 の選択
Perl 5の選択については、特にほかの言
語との比較などは行なっていない。開発を担
画面 4
画像掲載用メール（URLはサンプル）
当したエンジニアは、普段からファイルの処理
注4：Jeremy D. Zawodny、Derek J.Balling著『実践ハイ
パフォーマンスMySQL』
（オライリージャパン刊）によ
ると、MyISAMはクエリの90％が読み出しと仮定して
作られているという。
注5：MySQL 4.1の最初のproduction認定されたバージョン
は、2004年10月23日にリリースされた4.1.7である。
注6：同一のUNIXマシン上で、プロセス間通信を実現する
仕組みのこと。
スレーブ
DB
マスター
DB
スレーブ
DB
常時起動
参
照
専
用
HTTPリクエスト
apache
プロセス
UNIX
ドメイン
ソケット
HTTPレスポンス
更新は1台の
マスターDBでのみ可能
図2
非同期で
反映される
＝遅延あり
スレーブ
DB
シングルマスター非同期レプリケーションの概念
別プロセス
図3
FastCGIの概念図
アプリケーション
プロセス
72 万会員、1 日 7000 万 PV を
LAMP で支える
「モバオク」
システム構築のポイント
DB（マスター）
1
メール（送信）
メール
repli
け機能やサイト間連携を行なうためのAPI
PART
DB（バックアップ）
については別プロセスを起動しており、プロ
検索
セス数も個別に設定している。
データ
送信
メール（受信）
repli
メール
また、Apache 2.0.xではなくApache
写真添付メール
1.3.xを選択した理由は、次の2点である。
画像
DB（スレーブ）
●
当時のLinux kernel 2.4では、Apacheの
Web（アプリケーション）
マルチスレッド対応のメリットがあまり引き
出せなかった
●
当時は Apache 2.0.xと FastCGIとの組
図4
モバオクのシステム構成概要
み合わせでの動作実績が少なかった
きくなるため1本あたりの容量も本数も多く
このApacheとmod_fastcgiの組み合わ
●
DB設計とスケーラビリティ
−MySQLレプリケーション
している。
−テーブル間の疎な結合
せで、ピーク時には 1 サーバーあたり秒間
100リクエスト程度を処理できている。また、
CPU：Dual Xeon 2.40GHz
1サーバーで500∼700万ページビュー／日
−独自検索エンジン＋シェアードメモリ
OS：Red Hat 9
（初期）
、CentOS 4.x
（最近）
●
PerlXS＋C言語の活用
を処理できることが分かっているが、実際は
HDD：36GB×2∼126GB×4
●
キュー処理
この半分程度の処理数に収まるよう適宜サ
メモリ：2∼8GB（DBマスターでは16GBも）
●
変更しやすいコード
ーバーを増設している。
ファイルシステム：ext3
以下、それぞれのポイントについて詳しく
なお、サービス開始当初は以下のようなハ
ハードウェアの選択
ードウェア構成で、サーバーマシンは合計11
台であった。現在は100台以上の構成とな
選択方針と初期構成
っており、台数だけを見ても当初の10 倍近
い規模になっている。
前述したように、開発方針には低コストかつ
解説していく。
DB 設計とスケーラビリティ
MySQL のレプリケーション
MySQLのレプリケーション構成図を図5
に示す。DeNAでMySQLをレプリケーショ
［ハードウェア構成と現在の台数］
ン構成で使う場合は、マスターサーバー、ス
●
Webサーバー
（携帯向け）
：16台
レーブサーバーのほかにバックアップサーバ
ビリティを採用したため、ハードウェアはx86ア
●
DBマスター：2台
ーを用意している。このサーバーは、マスタ
ーキテクチャのPCサーバーを利用している。
●
DB バックアップ：2台
ーサーバーの障害時に手動でマスターサー
ビッダーズでは当時、主要DBサーバーが
●
DBスレーブ：20台
バーに切り替えられるほか、毎日データの
SPARC Solarisベースであったため、モ
●
検索サーバー：22台
SQLダンプを行なっており、過去2日分のス
バオクではすべてPCサーバーベースでサ
●
出品画像サーバー：16台
ナップショットを保存している。
ービスを構築してみるという実験の意味合
●
メールサーバー：6台
いもあった。
●
その他：16台以上
スモールスタートというのがあり、またMySQL
のレプリケーションによる台数追加のスケーラ
OSはLinuxとし、ディストリビューションは
フリーで入手できるRed Hat 9とCentOS
4.xを選んでいる。基本スペックは以下のと
おりだが、ケースバイケースでリーズナブルに
入手できるものを利用している。
また、出品画像を保存／提供するサー
バーについては、利用するHDD容量が大
スレーブサーバーは対応マスターサーバ
ー単位に必ず複数台用意しており、Web（ア
プリケーション）サーバーからスレーブサー
システム構成と設計／
構築のポイント
バーへの接続はDNSラウンドロビンによって
振り分けられている。図6に、BIND named
でのラウンドロビン設定の例を示す。アプリ
モバオクシステムにおけるシステム構成の
ケーション側では、DNS名前解決をして取
全体像を図 4 に示す。システム設計／実装
得したIPアドレスに接続しようとしてタイムア
のポイントは次のとおりだ。
ウトした場合は、ほかに返却されたIPアドレ
特集
スに接続し直すような共通機能が用意され
め、もともと1つのSQLでJOINしないような作
スター自体を分割することも可能である。
現在、マスター分割は2系統で、参照分割
ている。そのため、スレーブサーバーに障害
りにしていた。さらに出品数が増えた場合、出
が起こった場合でもサービスは停止しない
品ID
（個々の出品を識別するユニークなID）
は3系統で行なっているので、Perlのロジック
（1回だけタイムアウトするまで待たされると
を分割数で割った際の余り値で収容マスター
側では更新／参照するテーブルを考慮して5
を決定することで分散できるようになっている。
つのDBハンドルを使い分けている。ただ、こ
いうコストは存在する）。
例えば、出品系テーブルを2系統にマスタ
れはどのテーブルがどのハンドルに関連付け
「マスター分割」を想定したテーブル設計
ー分割する場合、出品IDを2で割った余り
られているかと、データ参照のみか更新を含
先述したとおり、オークションサービスではデ
（出品 ID % 2）が 0であるか 1であるかで
むかによって判断がつくので、アプリケーショ
ータ更新の頻度が多い。単一マスターサーバ
INSERTするマスターサーバーを切り替え
ーでの運用だと、いずれスレーブ側ではマス
るような処理ができるようになっている。
ン開発上は特に問題になっていない。
ターから流れてくるレプリケーションデータに基
さらに、同じマスターに収容されているテ
独自の分散検索エンジンとシェアードメモリ
づく更新がボトルネックになってしまうだろうと考
ーブルでも、参照するテーブルによって接続
モバオクでは、全ページビューの 30 ∼
え、設計当初より
「マスター分割」
を想定してシ
するスレーブを分ける「参照分割」
も利用し
40％程度をカテゴリ単位の商品リストと商品
ステム設計とテーブル設計を行なっていた。
ている。ファイルキャッシュも含め、テーブル
に対するキーワード検索結果閲覧（画面5）
やインデックスのデータがすべてメモリに載
が占めている。これらの機能へのアクセス
ーサーバーを用意し、読み書きするテーブル
ってしまうとディスクI/Oが発生しないため、
が多いことはビッダーズでも同じであったた
マスター分割とは、文字通り複数のマスタ
によってアプリケーションから接続するDBを
参照クエリを高速に処理できる。モバオクで
め、当初からこの部分をどう高速化し、スケ
使い分ける方法である。実際には、2005年
は現在、ユーザー系マスターサーバーに収
ールさせるかが課題だと考えていた。また、
2月にユーザー系テーブルと出品系テーブル
容されている評価系テーブルとそれ以外の
ユーザーは「きっと目当ての商品があるはず
にマスター分割を行なった。出品系テーブル
ユーザー系テーブルとの間で参照分割を行
だ」
と思えるならば、根気よく数多くの商品
には、出品情報（商品名、商品説明、開始
なっている。もし、それぞれで6GBの容量を
リストページをたどっていく。そのため、アプ
価格など）
のほか、出品物に関するQ&A情
占めていたとすると、両方をメモリに載せる
リケーションはすばやくレスポンスを返し、ユ
報、入札情報などが含まれる。ユーザー系
ためには12GB以上が必要となる
（おそらく
ーザーがサクサクとページをたどって行ける
テーブルは出品系テーブル以外のデータで、
16GBのメモリが必要だろう）。
ようにすることも重要である。モバオクでは、
会員情報、落札後の取引情報（落札者／出
しかし、参照分割をするならば、それぞれ
これを実現するため「シェアードメモリ」
（以
品者の連絡先情報や支払／送付方法の選
6GBのメモリで済むため、8GBのサーバーが
下、SHM）
というメモリ上のDBと検索エン
ジンを独自開発した
（図8）。
択など）
、評価（オークションの取引を通して
2セットあればこと足り、メモリ購入費用も抑え
の感想を落札者／出品者相互に評価を行
られる
（図7）注7。ただし、この参照分割の場
SHMはC言語で実装されており、アプリケ
なったデータ。取引相手が信頼に足るか判
合もアプリケーション側では評価系テーブルと
ーションからもCで実装されたライブラリを利
断する材料とする）
などのデータが含まれる。
そのほかのユーザー系テーブルとをJOINす
出品系テーブルとユーザー系テーブルは、将
るようなSQLは利用しないことが前提になる。
来的にマスター分割することを想定していたた
また、これを前提にしておけば、基本的にマ
（1）ゾーンファイルに以下のように記述する
マスター分割（2005/02）
md00
マスター
（ユーザー系）
スレーブ
（ユーザー系）
スレーブ
（ユーザー系）
バックアップ
（ユーザー系）
スレーブ
（評価系）
参照分割
図5
MySQLレプリケーション構成図
スレーブ
（評価系）
マスター
（出品系）
バックアップ
（出品系）
スレーブ
（出品系）
スレーブ
（出品系）
ユーザー系：会員情報、取引、評価、その他
● 出品系
：出品、Q&A、入札
● バックアップ
：毎日SQLダンプし、2日分を保存
●
注7：実際にはレプリケーションにより参照範囲以外のデー
タも更新されるので、ここまでくっきりとは分かれない
が、ここでは単純化して説明している。
IN A 192.168.100.10
IN A 192.168.100.11
IN A 192.168.100.12
（2）上記が mbok.dena.ne.jp ドメインに関する設定である場合、
「host md00.mbok.dena.ne.jp」を実行すると以下のような結果が返る
md00.mbok.dena.ne.jp has address 192.168.100.12
md00.mbok.dena.ne.jp has address 192.168.100.10
md00.mbok.dena.ne.jp has address 192.168.100.11
→ DNS問い合わせをするたびに返されるIPアドレスの順番は変わる。
問い合わせしたアプリケーションは返されたIPアドレスのうち、
最初に返されたものに接続しようとする。この仕組みでコネクションが
複数サーバーに分散される
図6
DNSラウンドロビンの設定例
72 万会員、1 日 7000 万 PV を
LAMP で支える
「モバオク」
システム構築のポイント
マスターDB
スレーブDB
ユーザー系テーブル
6GB
ユーザー系テーブル
6GB
出品系テーブル
6GB
出品系テーブル
6GB
メモリに載せて
参照させるに
は1 2 GB 以上
メモリが必要
マスターDB
（出品系）
図7
スレーブDB
スレーブDB
出品系テーブル
6GB
出品／更新
検索サーバーn
① query → item_ids
（TCP）
ユーザー系テーブル
6GB
図8
SHM
Webサーバー1
SHM
② item_ids
and/or categ_id
→ item_list
Webサーバーn
シェアードメモリと独自検索エンジンの仕組み
ークションサービスで
はなるべく多く商品を
参照分割
抽出できるほうが良い
用してアクセスされる。これには「PerlXS」と
という考え方に基づいてこの方式が選択さ
いう、PerlからCで実装されたライブラリを利
れた。また、この検索エンジンも出品マス
用する仕組みになっている。出品系マスター
タと同様「出品 ID % n」
（ n=2、3、……）
DBに対してINSERTやUPDATEがあった
のような形で複数台のマシンセットに分散
場合、DB上の更新を定期的にチェックして
できるようになっている。
いるdaemonプロセスにより各Web（アプリ
検索エンジンは、アプリケーションから検索
ケーション）サーバー上のSHMに配信され
キーワードを受け取るとそのキーワードを含
る。配信の遅延は数秒程度であるので、ほ
む出品物の出品IDリストを返すようになって
ぼリアルタイム反映だ。これにより、商品の検
いる。仮にこの出品IDのリストをSELECT
索結果やカテゴリ単位の商品リスト画面で必
文のWHERE句のIN演算子に与えるなら
要となる出品データはすべて各Webサーバ
ば、先述の「出品ID % n」のような形でマ
ー上に存在することになる。したがって、ユ
スター分割している場合、n台のDBサーバ
ーザーがカテゴリをたどって商品リストをブラ
ーに接続してSELECT結果を取得し、さら
ウズする場合、アプリケーションはDBアクセ
にアプリケーション上でマージ／ソートする必
ス不要で結果を即時に返せるわけだ。カテ
要がある。頻繁に行なわれる商品検索では、
ゴリ別の出品数などもリアルタイムに取得可
これは無視できない負荷である。実際は、検
能である。
索サーバーから検索結果として返された出
モバオクの独自検索エンジンもCで開発
され、データ追加時はサービス停止不要で
品IDリストに対応する商品名／現在価格／
終了時刻などのデータをSHMから取得し、
即インデックスに反映できる。SHMと同様
ユーザーに返す。これにより、キーワード検索
に、出品系マスターDBに対して INSERT
の場合もDBアクセスが不要となる。
/UPDATEがあった場合、その情報が検索
PerlXS ＋ C 言語の活用
エンジンに配信されインデックスへと即時に
追加される。この検索エンジンは簡易
モバオクシステムでは、パフォーマンスの問
bigram 注8 を利用しており、形態素解析は利
題が起きがちな部分をCで独自に実装を行
用していない。形態素解析を利用しない場
なっている。具体的な部分は次のとおりだ。
合、例えば「注目をあびる優れた検索エン
ジン」という検索対象が「あびる優」という
●
検索エンジン
検索キーワードで検索されてしまうというよ
うに、絞り込みより数多く検索対象を抽出
することを重視した検索結果となるが、オ
1
item_id % n
検索サーバー1
参照させるテー
ブルを限定すれ
ば、8GB程度の
メモリで済む
PART
注8：2文字単位で索引語を抽出するインデキシング方法。
例えば、
「実践活用術」という文字列からは「実践」
「践
活」
「活用」
「用術」という索引語が抽出される。
画面 5
キーワード検索結果画面
特集
●
シェアードメモリ
（SHM）
をmmap（）注9し、メモリ上のデータ構造にC
合は静的コンテンツとして返している。この
●
テンプレートエンジン
言語モジュール経由で値をセットするだけと
4パターンの画像でほとんどの携帯端末に
●
文字コード／絵文字変換処理
いう仕組みにしている。mmap（）
には同じフ
対応できるが、仮に対応できない携帯端末
ァイルをマップした他プロセスとメモリマッピン
から接続された場合はWebアプリケーショ
前述したように、Cで実装されたライブラ
グを共有する機能があり、このテンプレートエ
ンで動的に画像変換を行なって画像を返し
リをPerlから呼び出す部分はPerlXSを利
ンジンでもこの機能を利用しているため、メモ
ている。
用している。検索エンジン、SHMについて
リも効率的に利用されているのである。
このテンプレートエンジンは、次のような機
もすでに説明しているので、ここではテンプ
レートエンジンについて説明しよう。
能をサポートする。
テンプレートエンジンを独自開発するにあ
メールで出品画像を受け付けてから商品
画面などで画像閲覧されるまでの流れを図9
に示す。出品画像を提供するサーバーでは
Apache 1.3.x＋ mod_fastcgiとLinuxカー
HTMLエスケープ変換
たり念頭にあった課題は、
「HTTPリクエスト
●
に応じた処理を行なうたびに、テンプレートフ
値をテンプレートに埋め込む際に「<」
を
「<」
ーバー「tux」
を併用しており、HTTPリクエス
ネル内で動作するオープンソースのWebサ
ァイルを読み込んでparse（構文解析）
するの
などに変換
トはまずtuxで受ける。あらかじめ生成され
は非効率なので避けよう」
というものであった。
●
条件分岐
た4タイプの画像を返す場合はtuxがそのま
一度parseしたテンプレートデータはプロセス
if∼elsif∼elseの記述が可能。条件内では、
ま返し、動的な画像変換が必要な場合は
内にキャッシュしておくという手もあるが、
文字列比較、不等号（>、<）
を含む数値比
tux からApacheにリクエストが転送され、
FastCGIは複数の常駐プロセスが独立した
較、
「&&」
「II」の利用や条件分岐のネストも
FastCGIのプロセスで画像変換を行なう。画
メモリ空間で動作するため、キャッシュ共有が
可能
像変換には「ImageMagick」
というフリーソ
できずメモリ利用が非効率になるという問題
●
もある。そこで、事前にテンプレートをparse
Perlのリストを引数とし、全要素に対して処
してバイナリファイルに変換（コンパイル）
してお
理を繰り返すことが可能
き、アプリケーションでは都度バイナリファイル
●
①
②
ループ
携帯キャリア単位の出し分け
フトウェアを利用している。
以前は静的な画像ファイルもApacheで
返していたが、だんだんと画像ファイルのト
ラフィックが多くなってきたためtuxを導入
独自タグで範囲を区切り、その範囲を
「auケ
した。その後も画像ファイルへのトラフィッ
ータイのみに表示」
というようにアクセス元携
クが増加してロードバランサの性能限界に
帯キャリア単位で出し分けることが可能
近づいたので、社外の CDN（Contents
Delivery Network）サービス注10 を利用す
出品画像の扱いとキュー処理
携帯向け画像サーバー
①NTTドコモN503i
（画面サイズ：横118ピクセル×縦128ピクセル、カラー：4096
色、コンテンツ最大容量：10KB）
からアクセスされたときに返
される画像。画像のピクセルサイズは 75 × 100、容量は
5.98KB。
②NTTドコモN902iS
（画面サイズ：横 240 ピクセル×縦 270ピクセル、カラー：
26 万 2144 色、コンテンツ容量：100KB）
からアクセスされた
ときに返される画像。画像のピクセルサイズは180×240、容
量は7.94KB。
携帯向け画像変換の例
現在では、図10に示すように携帯端末か
らのアクセスは CDN へ向けられている。
携帯サービスでは、一般的に利用される
CDNではコンテンツのキャッシュを行なうた
携帯端末画面のピクセル幅、高さ、表示可
め、キャッシュに画像ファイルがあればその
能画像ファイルサイズの上限に合わせて適
まま携帯端末に返し、なければモバオクの
切な画像が返されることが多い。これによ
サーバーへ取得しに行く。画像の種類が少
り、能力の高い携帯では画面いっぱいに高
ない場合はWebサーバーのメモリ
（ファイル
精細表示される容量の大きい画像ファイル
キャッシュ）
に画像が載りきるため、少数の
を、旧世代の携帯では制限に応じてピクセ
Webサーバーでも大量のトラフィックをさば
ル数、容量ともに小さな画像ファイルをそれ
けるが、画像の種類が多い場合はディスク
ぞれ閲覧できる
（画面6）。
モバオクでは、出品画像が登録された時
点で、ファイル容量やピクセルサイズが異な
る4パターンの画像ファイルをあらかじめ生
成してサーバーに置き、アクセスがあった場
画面 6
るようになった。
注9：ファイルキャッシュが効く場合は、バイナリファイルの
読み込みもメモリからで済ませられる。
注10：ファイルサイズの大きいコンテンツを大量配信する
ために最適化されたネットワーク。ユーザーの接続
元に応じて効率良く配信できるサーバーを選択させ
るような処理を行なうものもある。
72 万会員、1 日 7000 万 PV を
LAMP で支える
「モバオク」
システム構築のポイント
PART
1
出品情報
アクセスが多くなり、多数の Web サーバー
set1（main）
ImageMagick
が必要となる。
変換fcgi
容量が大量に必要となるため1台あたりの
apache
変換キュー
また、出品画像サーバーの場合、ディスク
ImageMagick
変換／コピー
daemon
mail recv
購入額も大きくなる。CDNの料金は利用帯
変換キュー
ftp
set1（mirror）
4タイプ画像
ftp
域単位で課金されることが多く、一般的に
4タイプ画像
tux
変換fcgi
apache
tux
データセンターで利用する帯域単位の接続
料金に比べて高額になる。しかし、多数の
qmail
set2（main）
分配
daemon
ftp
Webサーバーが必要となる場合、Webサー
変換キュー
バーの購入コストとCDNの利用コストを比
較するとCDNの利用コストのほうが小さく
変換／コピー
daemon
画像添付メール
なることがあり、このような場合はCDN利用
set2（mirror）
4タイプ画像
apache
tux
ftp
4タイプ画像
をお勧めする。
キュー処理による直列化
変換fcgi
変換fcgi
apache
tux
図9
出品画像処理の仕組み
画像が添付された携帯メールは、図9の
ようにqmailで受け付けられ、即座に分配
① CDNにキャッシュがある場合はキャッシュを返す
キューとしてファイルシステム上のファイルに
書き出される。出品画像サーバーには複数
のセットが用意されており、出品物の出品ID
CDN
携帯
画像サーバー
に基づいて収容されるサーバーセットが決
この帯域で
CDN課金
定される仕組みとなっている。
分配キューに置かれたファイルは分配
② CDNにキャッシュがない場合は画像サーバーから取得
→ CDNにキャッシュされる
daemonに1つずつ読み込まれ、サーバー
セットが判断された後、FTPで出品画像サ
ーバー上の変換キューに置かれる。この変
図 10
CDNによる画像ファイル受け渡しの仕組み
換キューも、ファイルシステム上のファイルとし
て実現されている。変換キューのファイルも
くして並列処理する必要があるが、そうなる
た場合でも、受け取った画像ファイルはサー
1つずつ変換／コピーされてdaemonに読み
と今度はどのくらいまでプロセス数が必要で、
バーのキューファイルに書き出されているの
込まれ、4タイプの画像を生成した後、FTP
実際にどこまで増やせるのかの推測がつき
で再開が可能である。
で各画像サーバーに配信される。
にくい。さらに、このプロセス数の制限を
このようなメリットがあるため、われわれ
モバオクシステムではこのキュー処理が重
qmail側で制限できるか、サーバーの処理上
の開発チームではキュー処理を多用してい
視されており、画像処理以外にも幅広く利用
限を超えてしまった場合に送られてきたメー
る。この例ではqmailをトリガーとした処理
されている。図11にキュー処理の考え方を
ルがどうなるか（失われてしまうか）
はqmail
を取り上げたが、このようなキュー処理は
示す。まず、出品画像を受け付けるqmailか
の実装に依存してしまう。
HTTPリクエストをトリガーとした場合でも
利用できる。
ら直接fork（新しいプロセスを生成）
される
一方、キューを使った場合、qmailから実
プロセスにより、直接サーバー間で画像コ
行されるプロセスが行なうのはファイルシス
ピーする場合を考える。この場合、サーバ
テムへの書き出しだけなので、十分に短い
ー間コピーの1処理にかかる時間は、相手サ
処理とみなすことができる。いったんキュー
モバオクシステムでは独自のディスパッチ
ーバーの負荷やネットワークの状態に依存す
に直列化してしまえば、並列度は処理
ャを用意しており、リクエストされたURLと、
るため推測がつきにくい。もし時間がかかる
daemon側でコントロール可能である。また、
そこから呼び出されるPerlモジュール名、
ようであれば、同時実行するプロセス数を多
何らかの問題でdaemonが停止してしまっ
サブルーチンとの関係を設定ファイルで定
変更しやすいソースコード
特集
ヒアドキュメントを利用したモバオクソースコード例（
「よくある質問」での質問リストページの表示）
LIST
sub pageFaqList {
}
$rhData->{faqListObj} = \@faqListObj;
$rhData->{faq_categ_id} = $_::F->{faql};
$rhData->{categ_title} = getCtgTitle($_::F->{faql},$carrier);
my $func = shift;
my $rhData = {};
my $carrier = lc($ENV{MB_CARRIER_UA});
if($rhData->{categ_title}){
$nextUrl = "faq_l";
}else{
$nextUrl = "";
}
my $dbh = DA::getHandle('SLAVE');
my $sth = $dbh->prepare(<<"SQL");
select faq_q_$carrier faq_q, faq_a_$carrier faq_a, faq_data_id
from faq_data
where faq_categ_id=? and
del_flg = 0 and
faq_q_$carrier != "" and
show_flg = 1
SQL
$sth->execute($_::F->{faql});
my $nextUrl;
if ($sth->rows) {
my @faqListObj;
while (my $rhData = $sth->fetchrow_hashref()) {
push(@faqListObj, $rhData);
$rhData->{root_categ_id} = getRootCtgId($_::F->{faql});
$rhData->{subCtgObj} = getSubCtgList($_::F->{faql},$carrier);
} else {
$nextUrl = 'faq_top';
}
SQL文が
ヒアドキュメントで
べた書きされて
いる部分
my $html = HTMLTemplate::insert($nextUrl, $rhData);
Common::output(\$html, 'cache');
}
スする場合、同じデータアクセス
（DA）
クラス
qmailからforkされるプロセスで、直接サーバー間で画像コピーをしたら?
を使う実装が一般的だが、モバオクではこの
サーバー間コピー
qmail
ような実装を行なっていない。原則、URLと
② 上限は?
③ 上限を超えたら?
サーバー間コピー
の関連を示す設定ファイルが指し示すpmフ
サーバー間コピー
ァイルを読めば、その機能と処理の流れが分
① どれくらいかかる?
かるようになっており
（これを当初の開発者は
キューを使った直列化
書き出し
qmail
「一筆書きのように」
と表現している）
、SQLも
書き出し
→問題発生時
にも再開可能
ほとんどの場合、そのファイル内にヒアドキュ
サーバー間コピー
daemon
最低限の処理
（十分に短い）
図 11
サーバー間コピー
直列化
書き出し
サーバー間コピー
並列度を
コントロール可能
メント注11を使ってべた書きされている
（LIST）
。
これは、当初からサービス開始後にロジ
ックの調整／変更が頻繁に入ると想定して
いたため、プログラムを把握して変更できる
キュー処理の考え方
ようにと考えてのことである。携帯向けサー
ビスは1画面に表示できる情報が限られて
開発ウラ話：実装からサービス開始まで
モバオクシステムの開発は、本文冒頭にも述べた
とおり2003 年 11 月下旬から 2004 年 3 月上旬の
約 4 ヶ月で行なわれ、要件定義から設計／実装まで
1 名のスーパーエンジニアだけで担当した。11 月
下旬∼ 12 月中旬は、まず MySQL や基盤技術、アー
キテクチャに関する調査／実験を行ない、これまで
述べてきたような基盤技術や方針の選択／決定を行
なった。
12 月中旬より実装を開始し、1 ヵ月後の 1 月中旬
にはすでに動作するようになっていた。このタイミン
グから社内外のユーザーに試用してもらい、感想を
聞いてさらにブラッシュアップしていった。3 月に入
ってからは、出品物審査（出品禁止対象ではないか確
認する）など、社内でバックエンド業務を行なうため
のツール作成に取り掛かり、3 月下旬にサービス開
始となった。
タイトなスケジュールで開発にも苦労しただろう
と推測して、当時の開発者にその頃の様子を聞いた
ところ、デザイナーやマーケティングスタッフも含め
少人数チームでの開発だったため、
「身軽にノリ重視
で勢いよく進められた」と述べている。
サービス開発の苦労話としては、携帯の限られた
画面サイズではあまり図やイラストも使えず、ユーザ
ーを「利用する気にさせる」ガイドなどを作るのが難
しかったという話が挙がっていた。モバオクにはユ
ーザー登録、初入札、初出品など、ユーザー単位の
初アクションを検出して、ユーザーに案内メールを送
り
「初心者ナビ」というガイドに誘導する仕組みがあ
るが、これもこの際に考案されたという。
ただ、少し余談になるが、サービス開始から 3 週
間くらいは利用がほとんどなくて、関係者は冷や汗
をかいたという話だった。
いるため、1機能ごとの処理がシンプルであ
ること、サービスとしても全体の規模がそれ
ほど大きくないことなども理由として考えられ
るが、実際、開発に参加してみるとかなり読
みやすさを感じ、既存機能の把握も容易で
あった。
＊
＊
＊
以上、パート1では、モバオクシステムの構
築のポイントを具体的に説明してきた。オー
クションというアプリケーションに特化された
ポイントも多いが、MySQLのレプリケーショ
ン機能を前提としたマスター分割や参照分
割、キュー処理による直列化などは応用範
義できるようになっている。当然ながら、
注11：Perlスクリプト内で、複数行からなる文字列をそのま
ま書くための記法。Perlのほかにシェルスクリプトで
も利用可能である。LISTのSQL文もこの記法を使
って書かれている。
URLが分かればどのメソッドが実行される
かがすぐに分かるようにもなっている。
また、現在はDB上の同じテーブルにアクセ
囲の広い手法ではないだろうか。
ほかのポイントも含め、紹介した手法が読
者のみなさんのシステム構築時の選択肢の1
つになれば幸いである。
S P E C I A L
F E A T U R E
2
PART
2
システム拡張から障害対策まで
快適なモバオク利用を実現する
運用管理の工夫とテクニック
また、開発は外注せず、外部エンジニア
となるロードアベレージ値は次のとおりだ。
モバオクシステムの
運用体制とスキル
に参加してもらう場合でもDeNAエンジニア
と席を並べて同じように開発を行なってい
マスターDBサーバー：1.50
パート1の図1に示したとおり、モバオク
る。ただし、外部エンジニアは直接本番系
スレーブDBサーバー：4.00
はサービス開始以来、会員数、出品数とも
システムには触れられないポリシーになって
Web（アプリケーション）
サーバー：3.00
に成長を続け、現在では1日6000∼7000
いるため、運用については担当しない。
万ページビューのメガサイトとなっている。
このメガサイトを担当するDeNAのエンジ
ニアは5名で、原則として全員が追加機能
の開発と監視／運用業務の両方を担当し
マスター DB 分割作業の実際
システム
規模拡大への対応
パート1でも述べたように、モバオクシス
テムは初期構築時からマスター分割／参照
ている。開発と運用、アプリケーションとイ
モバオクのように会員数やページビュー
分割を行なうことを想定しており、システム
ンフラストラクチャの担当を分けず、チーム
などが増加していくサービスの場合、シス
規模の拡大に合わせて、必要なタイミング
メンバー全員ですべてを実施することによ
テム運用業務の中でもシステム規模拡大へ
で順次これらの対処を行なってきた。ここ
り、次のようなメリットが得られると考えて
の対応が大きな割合を占める。パート1で
では、マスター分割を行なう場合の作業手
いる。
も一部システム規模拡大への対応について
順を具体的に説明する。
触れたが、ここではシステム規模拡大にお
●
●
2つの役割（追加機能の開発と監視／運
いて特に重要と思われる「サーバーの追
用）で分け隔てるものがないため、意思
加」
「マスターDB分割作業の実際」
「メール
疎通がスピードアップする
配信の負荷対策」
「処理マージンの確保」に
インフラストラクチャの制約やパフォーマ
ついて順に説明していく。
ンスを考慮したアプリケーション開発が
できる
●
DB 側の移行準備
【手順 1】
レプリケーションの設定
新しく用意するマスターDBサーバー、ス
レーブDBサーバーの組み合わせに、従来
サーバーの追加
とは異なる名称の DB を作成（CREATE
アプリケーションやサービスの内容を
モバオクのように成長を続けるサービス
理解したうえでシステム監視／運用が
の場合、適切なタイミングでサーバーの追
レプリケーション設定を行なう
（図 1-①）。
できる
加が必要となる。モバオクでは、サーバー
設定後、レプリケーションが正常に動作し
追加が必要となるロードアベレージ値
注1
パート1で解説した内容を振り返ってみ
の目安を定めており、その値を超えるよ
てみると、DBやハードウェアなどインフラ
うであればサーバー追加を行なうように
ストラクチャのレイヤから、お客様が利用す
している注 2。
るサービスのレイヤまで全部を把握／考慮
DATABASE）
し、マスター／スレーブ間の
ていることを確認する。
【手順 2】従来のマスター DB から SQL ダ
ンプを取得
ロードアベレージ値以外にも判断基準と
したうえでシステムを構築すると、非常に低
なる数値は考えられるが、例えば、ディスク
コストでスケーラビリティの高いシステムが
I/Oがボトルネックとなっている場合でもロ
できることを示している。これを全エンジニ
ードアベレージ値に影響が出るため、ロー
アが実現できるようにするというのも、開発
ドアベレージ値をサーバー増設検討のトリ
と運用を分離しない理由の1つである。
ガーとしている。各サーバー追加のトリガー
注1：UNIXのw、uptimeなどのコマンドで表示される、マシ
ンの負荷を示す値。マシン上で実行可能となっている
ジョブの数の単位時間（過去1分、5分、15分）
あたり
の平均値である。
注2：実際はサービス内容やシステム構成によって、サーバ
ー増設を検討し始める必要のあるロードアベレージ値
は異なるはずなので、あくまで参考情報として見ていた
だきたい。
特集
mysqldumpコマンドを使い、従来のマ
SQLダンプの取得が完了したら、新マス
スターDBから新マスターに移行するテー
ターに取得したダンプデータを読み込ませ
ブルのSQLダンプを取得する。この際、-t
る
（図1-②）。
が行なわれる。
replicate-do-tableから始まる行は、レプ
オプション（CREATE TABLEステートメ
ントを書き出さない）
と-dオプション
（テーブ
の間でDB名が異なってもレプリケーション
リケーション対象のテーブルである。この
【手順 3】レプリケーションの実行
テーブル以外の更新データも従来マスター
ルのレコード情報を書き出さない）それぞ
新マスターの設定ファイルmy.cnfにLIST
から新マスターに流れてくるが、新マスター
れを付けて2回に分けて行なうと、テーブ
のようなDB名変換設定を行なってから、従
で実際に更新されるテーブルはこの行で指
ル定義とデータを別途にダンプでき、マス
来マスターのスレーブとしてレプリケーショ
定されたテーブルのみだ。
ター分割の際に合わせてカラム追加する場
ンを開始する
（図 1-③）。my.cnfの「repli
また、ここで新マスター／スレーブの組
合などに便利である。特にこのタイミング
cate-rewrite-db」から始まる行がDB名変
み合わせに対して、レプリケーション遅延の
は、行数が多く普段はカラム追加が困難な
換設定で、
「->」の左側が従来マスターの
監視を設定しておく。
テーブルでも実サービスに影響を与えずに
DB名、右側が新マスターのDB名である。
追加できるので絶好の機会である。
これにより、従来のマスターと新マスターと
LIST
アプリケーション側の移行準備
【手順 1】マスター分割の影響範囲を確認
マスター分割時のmy.cnf設定例
# DB 名変換： mbok データベースの更新を mbok_item データベースにレプリケーションする
replicate-rewrite-db = mbok -> mbok_item
replicate-do-db
= mbok_item
# レプリケーション対象テーブル
replicate-do-table
= mbok_item.item_data
replicate-do-table
= mbok_item.item_bid
replicate-do-table
= mbok_item.item_qa
事前に分割対象となるテーブル名でプロ
グラムを検索し、マスター分割の影響を把
握しておく。モバオクのように事前に分割を
想定したテーブル構成になっている場合は
良いが、そうでない場合はこの時点でそも
# スレーブ DB としての更新 SQL もバイナリログに書き出されるよう設定
log-bin
log-slave-updates
①
そも分割が可能であるかの判断が必要で
ある。
【手順 2】新マスター／スレーブの DB ハ
②
従来
マスター
レプリ
ケーション
新
マスター
更新
従来
スレーブ
ンドルを用意
従来
マスター
新
マスター
レプリケーション
開始
アプリケーションが新マスターを更新する
ためのDBハンドル、新スレーブを参照する
ダンプ
データ
ためのDBハンドルを従来とは別の変数名
新
スレーブ
従来
スレーブ
新
スレーブ
参照
で用意する。ただし、指し示す実体は従来
のDBハンドルと同じものとする。この段階
では従来マスター／スレーブの組み合わせ
アプリケーション
に対して接続するので、アプリケーション上
③
従来
マスター
レプリ
ケーション
開始
で完全に別のハンドルとして処理されてしま
④
うと、最悪の場合、コネクションを2倍消費
新
マスター
従来
マスター
新
マスター
新
スレーブ
従来
スレーブ
新
スレーブ
することになるので注意が必要だ。
【手順 3】プログラムの修正
従来
スレーブ
新DBハンドルを使うようにプログラムを
修正する。分割対象のテーブルとそれ以外
参照開始
アプリケーション
のテーブルとでJOINしている箇所がある
ような場合は、必要に応じてロジックの修
図1
マスター分割のための作業手順
正も行なう。
システム拡張から障害対策まで
快適なモバオク利用を実現する
運用管理の工夫とテクニック
PART
2
この段階では、ロジックとしては新DBハ
ンドルを使うが、実際は従来マスター／ス
レーブに接続している構成となる。
レプリケーションの停止
①
②
ここまでの準備が終了したら、新スレー
従来
マスター
ブのDBハンドルを実際に新スレーブへ接
×
新
マスター
新
マスター
従来
マスター
更新
開始
続するように変更する
（図1-④）。
従来
スレーブ
移行当日の作業
【手順 1】サービスの停止
新
スレーブ
新
スレーブ
従来
スレーブ
アプリケーション
アプリケーション
DB更新が起こらないようにサービスを停
止する。モバオクでは、メンテナンス中であ
マスター分割当日の作業手順
図2
る旨を示す静的ページを用意しておき、す
べてのWebアクセスに対してそのページを
問題なければ、新マスターで RESET
SLAVE を実行し、以後は新マスターで
Subject: 入札お知らせ
また、常時起動しているdaemonプロセス
START SLAVEしてしまっても従来マスタ
やcronから起動されるバッチなども止めて
ーで実行された RENAME TABLEが実
おく
（あるいはcronが実行されないタイミング
行されないようにする。その後、従来マスタ
を作業時間とする）
。監視も一時停止させて
ーでRENAME後のテーブルをDROPする。
あなたの出品中ｱｲﾃﾑに入札が入りました。
---------------[NO:12345]
ﾋﾞｰﾄﾙｽﾞ CD / Let It Be
現在価格:800円
---------------▼ｱｲﾃﾑﾍﾟｰｼﾞをﾁｪｯｸ
http://mbok.jp/_i?i=12345
---------------■配信停止
↓このﾒｰﾙが不要な方はｺﾁﾗ
http://mbok.jp/_msm
ﾓﾊﾞｵｸｻｰﾋﾞｽｶｳﾝﾀｰ
返す設定としている。
おく。さらに、従来のマスターから新マスター
へのレプリケーションも停止する
（図2-①）
。
ここまでの作業手順を見ていただけれ
ば分かると思うが、サービスを停止してい
【手順 2】新マスターへの接続設定とサー
ビスの再開
アプリケーションの新マスターを指し示
る間に実際に行なう作業は、レプリケーシ
ョン停止とハンドル設定の変更だけであ
画面 1
る。ハンドル設定については新しい設定フ
ユーザーに送られるメール例（出品者に
対する入札通知メール）
すDBハンドルの設定を変更し、実際に新
ァイルを事前に用意しておけば良いので、
マスターに接続されるようにする
（図2-②）
。
実質サービス停止は数分のレベルに抑え
という配信サーバーをPerlで独自に開発
その後、サービスを再開させる。しばらく
られる。
した。
（30分程度）
、エラーログや問い合わせログ
を確認し、また従来マスターの分割対象と
なったテーブルに更新が来ていないことも
確認する。
【手順 3】分割されたテーブルを DROP
メール配信の負荷対策
モバオクでは、入札、落札、商品に関する
qmailやpostfixは、SMTPというプロト
コルか、ローカルマシン上のコマンド実行に
よりメールを受け付け、送信先メールサー
Q＆Aなど、ユーザーのアクションタイミングで
バーに転送処理を行なう。調査したところ、
さまざまなメールが送信される
（画面1）
。ま
このメール受け付けの処理部分が遅いこと
た、会員向けのメールマガジンも送信してい
がボトルネックになっていると分かったため、
注3
問題がないようであれば、従来のマスタ
る
（画面 2）。したがって、適切なタイミング
mobamailではMySQLへの行INSERTに
ーから分割されたテーブルをDROPする。
でユーザーに合ったメールを配信するために
よってメールを受け付けることにした。これ
この際、従来マスターから新マスターへの
は、メール配信性能も重要である。
により受付処理が高速化された。
レプリケーションが止まっていない場合の事
当初、メール配信サーバーにはqmailを
故を防止するため、従来マスター上で
使っていたが、postfix 注4 に変更したところ、
RENAME TABLEを行ない、その後新
時間あたりの配信数がさらに向上すること
マスターには旧名称でテーブルが残ってい
が分かった。しかし、それ以上に性能向上
ることを確認する。
が必要な状態となったため、
「mobamail」
注3：ちなみに、メールマガジンのFromは[email protected]、
Subjectは「モバオクNEWS vol.91」
（カナは半角）で
ある。
注4：qmailと同様、sendmailの代替となるメールサーバー
プログラム。性能が良く管理しやすいという特徴を
持つ（http://www.postfix.org/）。
特集
ロバイダに分散しているので、送信元サー
そうに見えるメールサーバープログラムを
au、ソフトバンクモバイルの 3 キャリア（携
バーを増やして送信先サーバーへの接続
独自開発するとは大げさな……と思われる
帯電話事業者）の限られたメールサーバー
数を増やしていけば送信処理の並列度を
かもしれないが、実際は自社アプリケーシ
への送信となる点が特殊である。一般の
上げられ、性能も向上すると考えられる
ョンからの送信のみに特化しており、メール
また、携帯向けのメールは、NTTドコモ、
PC向けメール配信の場合、送信先メール
（図 3-①）。
受信処理が不要でセキュリティ対策機能も
一方、携帯向けメール送信の場合、受付
最小限で済むため、意外とシンプルに作成
サーバーの数が限られるため、単に送信元
されている。そのシンプルさが性能の良さ
サーバー数を増やしていけばスループット
にも反映されていると考えられる。
アドレスのドメインはさまざまなサービスプ
が増えるというものではない（図 3-②）。む
性能対策のほかにも、携帯キャリアのメ
しろ、接続先ドメインごとに細かくパラメー
ール拒否対応機能も用意した。携帯キャリ
タを設定して、性能をチューニングできるこ
アは迷惑メール対策の一環で、存在しない
とが重要である。mobamailでは、配信先
アドレスへのメール送信や過剰なメール送
ドメイン
（≒携帯キャリア）
ごとにプロセスを
信、コネクション要求が大量にあった場合、
割り当て、プロセスごとに次の項目を設定
送信元の IP アドレス単位で接続を拒否す
できるようにしている。
ることがある。もちろん、モバオクでは迷惑
メール送信を行なっていないが、短時間に
●
接続先メールサーバー
多くのメールを送信することはあるので、こ
●
メール送信間隔
の拒否に遭遇することがある。
●
同時接続数（送信並列数）
●
1接続中の連続送信数
かを調査し、パラメータ設定に反映させる
●
再送間隔
必要がある。mobamailでは、携帯キャリア
その場合、どのような経緯で拒否された
のメールサーバーとSMTPプロトコルでや
これにより、NTTドコモとauに対しては、
1時間あたり約25万通を、ソフトバンクモバ
イルに対しては約2万通の配信性能を達成
モバオクから送付される会員向けメー
ルマガジン
おく機能を持っている。
また、送信拒否は送信元IPアドレス単位
で行なわれ、一定時間が経過して拒否が解
している。
画面 2
り取りした内容をDB上にログとして残して
sendmail、qmail、postfixのような複雑
除されるまでは同じIPアドレスからのメール
送信ができなくなる。mobamailは、いった
ん受け付けたメールをまとめてほかのサー
① PC の場合
送信先メールサーバーが無数にあるので、送信元メールサーバーの追加が処理並列度向上につながりやすい
…
…
…
送信先
メールサーバー
バーに移して配信再開する機能も持ってい
るため、あるサーバーが送信拒否されても、
違うIPアドレスを持つサーバーで配信を再
開できるようになっている。ただし、携帯キャ
送信元
メールサーバー
…
② 携帯の場合
送信先メールサーバーの数が限られるので、送信元メールサーバーの追加が処理並列度向上につながりにくい
送信先
メールサーバー
リア側の条件変更は突発的に行なわれるた
め、これに合わせてこまめに送信パラメータ
のチューニングを行なうことは難しい。そのた
め、現在ではこういったノウハウを集積し、配
キャリアA キャリアB キャリアC
信性能も良い「SIELLA ENGINE 注 5」を利
用している。
送信元
メールサーバー
図3
携帯メール配信の特殊性
…
注5：シエラ株式会社より提供されている、携帯向けの高
速メール配信エンジン。
http://www.siella.jp/siella_engine.html。
システム拡張から障害対策まで
快適なモバオク利用を実現する
運用管理の工夫とテクニック
PART
2
処理マージンの確保
モバオクシステムでは、全体的にあらかじ
め処理マージンをとっておくようにしている。
キュー処理であれば、1つ処理した後に少
し多めにスリープを入れておく。処理性能
画面 3
daemon停止の通知メール例
が追いつかなくなってきた場合はこのマー
ジンを使って吸収し、吸収しきれている1∼
2日の間にサーバー構成を変える、処理方
画面 4
ディスク残り容量が少なくなった場合
の通知メール例
画面 6
DB接続不可の場合の通知メール例
法を見直すといった対処を行なっている。
1∼2日の間に、今までほかの機能に使
われていたサーバーを性能不足となってい
る機能担当に割り当て直すような構成変更
画面 5
テーブルスペースの残り容量が少なく
なった場合の通知メール例
は比較的頻繁に行なわれている。
24 時間 365 日の
システム監視
認する。レスポンスがほかの値である場合
や、接続がタイムアウトする場合は通知メー
ルが送られる。
モバオクは原則24時間365日利用される
サービスである。そのため、システムが安定
た際に「InnoDB free: ○○○ kB」という
ように表示されるので、この値をチェックし
daemon の実行状態
稼動しているかを常時確認する監視プログ
モバオクシステムでは「daemonctl」
という
ラムを動作させており、何か異常が発生す
コマンドが用意されており、多数ある
ればいつでも担当者全員に携帯メールが届
daemonの一括起動／停止／再起動が可
くようになっている。
基準値を下回る場合は通知メールを送る
（画面5）。
DB への接続可能性
能である。また、このコマンドは各daemon
各DBに接続ができない場合（コネクショ
フリーソフトウェアの「swatch」
（http://
プロセスの起動状態の表示機能も持ってお
ン上限に達している場合やDBサーバープ
swatch.sourceforge.net/）でsyslogを監視
り、監視プログラムから実行され、起動さ
ロセスが異常終了した場合など）
は、通知
し、特定文字列がログ出力されたら通知メ
れているはずのdaemonの停止が検知され
メールを送る
（画面6）
。スレーブDBで接続
ールを送る、
「MRTG」
（http://www.
た場合は通知メールが送られる
（画面3）。
不可となった場合は、ほかのスレーブに自
mrtg.jp/）のグラフでネットワークやサー
バーのリソース利用状態を把握する、とい
動的に接続されるので問題ないが、マスタ
ディスク残り容量
ーDBに障害が発生して接続不可能になっ
う定番とも言える監視作業も行なわれて
各サーバー単位に、空き容量下限、ディ
いるが、多くの監視プログラムはPerlで独
スク利用率上限、i-node利用率上限値を定
自に作成している。独自作成された監視
め、それぞれ1つでも下回る／上回る場合
プログラムの多くは5分ごとにcronで起動
は通知メールが送られる
（画面4）。
レプリケーションの遅延
テーブルスペースの残り容量
意しておき、マスター側でUPDATEした直
しており、監視ポイントは次に挙げるとお
りである。
要である。
あらかじめチェック専用のテーブルを用
MySQLのInnoDBストレージエンジンは、
Web サーバーの HTTP レスポンスコード
てしまった場合は、手動での切り替えが必
後から各スレーブ側でUPDATEされた行
事前にテーブルスペースをサーバー上のフ
のSELECTを繰り返し、値がUPDATEし
ァイルとして確保しておく形式となっている。
た値と一致するまでの時間をレプリケーシ
Webページに定期的に（ロードバランサを
したがって、確保している容量を超えたデ
ョン遅延時間としてミリ秒単位で計測して
通さずに）HTTP接続し、レスポンスコード
ータは追記できない。残り容量は、MySQL
いる。2000ミリ秒以上かかっている場合は
が正常であることを示す200であることを確
に「show table status」コマンドを実行し
警告メール（画面7）
を、20000ミリ秒以上か
Webサーバーにより、動的に生成される
特集
かっている場合は致命的エラーのメール
（画面8）
を送っている。
レプリケーション遅延は、サイト規模の拡
大によりじりじりと起こってくることもあるが、
前者の場合は更新SQLの発行間隔を長
処理キューの中に一定時間以上未処理で
くするなどの処理を行ない、後者の場合は
あるファイルがある場合も、キュー処理能力
原因となるプログラムを特定してSQLの見
を出品画像受付数が上回っている可能性
直しを行なう。
があるので通知メールを送るようにしている
多くは次のようなことが原因である。
（画面10）。
出品画像の処理
●
●
一時的に実行されるバッチファイルで大
過去10分間に一定数以上の出品がある
SMTP 接続可能性
量のデータ更新またはデータパージを行
にもかかわらず、出品画像の登録が0だっ
メールを受信する各サーバーにSMTP接
なっている
た場合は、出品画像処理に問題が生じてい
続を行ない、接続後正しい応答が返ってき
追加機能に非効率な SQLを発行するプ
る可能性があるので通知メールを送ってい
ているかを確認する。接続できない場合や
ログラムが含まれている
る
（画面9）
。また、パート1で紹介した画像
応答に異常がある場合は通知メールを送
っている
（画面11）。
メール送信キュー
メールは送信前にいったん送信メールサ
ーバーのキューに入れられてから送られる
が、そのキューに入っているメール数が一
定数を超える場合は、メール送信機能に何
画面 8
レプリケーション遅延を通知する致命
的エラーメール例
らかの問題が生じている可能性があるの
で、通知メールを送っている
（画面12）。
携帯キャリアのメール拒否
「メール配信の負荷対策」の項でも述べ
たように、各携帯キャリアは、迷惑メール対
策として存在しない送付先アドレスへのメ
画面 9
出品画像処理に問題が発生している際
の通知メール例
ール数や単位時間あたりの送信メール数を
見て、接続元サーバー単位に受信拒否を
行なうことがある。
モバオクでは、当然ながら迷惑メールを
送信していないが、それでも携帯キャリアの
メールサーバーに拒否されることがある。
そのため、送信メールサーバーでは送信先
携帯キャリアごとに送信キューを用意してお
画面 7
レプリケーション遅延を通知する警告
メール例
画面 10
一定時間以上画像キューが処理されな
い場合の通知メール例
り、キューに一定数以上のメールがあるに
もかかわらず過去60秒間に送信件数が0で
ある場合は、通知メールを送るようにしてい
る
（画面13）。
サーバーのロードアベレージとメモリ
サーバー単位にロードアベレージとメモリ
画面 11
SMTP接続に一定時間以上かかった場
合の通知メール例
画面 12
メール送信キューが一定数を超えた場
合の通知メール例
使用量の基準値を定めており、超過してい
る場合は通知メールを送っている
（画面14）
。
システム拡張から障害対策まで
快適なモバオク利用を実現する
運用管理の工夫とテクニック
PART
2
のauオークション開始、2005年7月の月額
システム障害時の対応
会費対応が挙げられる。
また、モバオクはユーザーの声を取り入れ
モバオクで利用するサーバー（Web＋ア
ることを重視しており、ユーザーアンケートで
プリケーションサーバー、検索サーバー、画
要望が多かった機能も追加してきている。こ
像サーバー、スレーブDBサーバーなど）
は、
のようにしてこれまで追加された機能には、
すべて2台以上を1セットとして用意されて
即決価格、入札お知らせメール、ウォッチリ
いるため、たとえセット内で1台のサーバー
スト終了間際通知メールなどがある。
が停止した場合でも、サービス自体は停止
しない仕組みになっている。ただ、マスター
DBサーバーはMySQLレプリケーションの
仕組み上、機能単位で1台のみの構成とな
画面 14
ロードアベレージ値が基準値を超えた
場合の通知メール例
画面 15
安心取引サービス「モバペイ」
そのほかの追加機能をいくつか紹介し
安全性を向上する「モバペイ」
PCユーザーをはじめ、携帯ユーザーにも
クアップDBをマスターDBへと切り替える
認知度が高いネットオークションサービスであ
必要がある。
るが、安全性に不安を感じているユーザーも
りである。
携帯キャリアによるメール拒否時の通
知メール例
よう。
るため、障害が起きた場合には手動でバッ
手動で切り替える場合の手順は次のとお
画面 13
まだまだ多い。そこで、モバオクでは今年の8
月より
「モバペイ」
という安心取引サービスを
開始した
（画面15）
。モバペイサービスの仕
① バックアップDBをレプリケーションのス
組みと取引の流れは次のとおりである
（図3）
。
レーブ設定から外す
② バックアップDBのバイナリログ
（MySQL
① 落札者の支払った落札代金をDeNAグ
のDB更新内容を示したログ）
と各スレー
ループの収納代行会社ペイジェントがい
ブDBのバイナリログを比較する
ったん預かる
③ バックアップDBのバイナリログより更新
が進んでいるスレーブ DB があった場合
② 代金が支払われたことが出品者に通知
される
は、一番進んでいるスレーブとのバイナリ
③ 出品者は通知に基づいて商品を発送する
ログ差分をバックアップDBに適用する
④ 落札者が受け取り通知操作を行なう
④ レプリケーションの設定を、バックアップ
DB →スレーブ DBとなるように変更し、
⑤ ペイジェントより代金が出品者に振り込
まれる
このレプリケーションが問題なく行なわれ
ていることを確認する
出品者は代金支払いを確認してから商品
⑤ アプリケーションの設定ファイルを変更
発送ができるので、
「発送したのに代金が入
し、マスターDB（更新用）の接続先をバ
金されない」
という心配がなく、また落札者
ックアップDBにする
は商品を受け取ってから出品者への支払
いを指示できるので、
「代金を支払ったのに
商品が届かない」
という心配がない、という
機能追加の開発
ように、出品者／落札者両者にとってメリッ
トのある取引方法である。
モバオクサービスの開始以来、社内外か
また、個人間の取引では利用することが
らの要望を取り入れながら、機能のブラッ
難しいクレジットカード決済やコンビニ支払
シュアップや追加を行なってきた。過去の大
いもサポートされており、より利便性も高ま
きな追加機能の開発としては、2005年1月
っている。
特集
PC ユーザーへの対応
モバペイ
2006年の10月26日からは、PCからの出
品／入札など、モバオクのフル機能を利用
③商品発送
できるようになった（画面16）
。PCに慣れて
モバオク！
出品者
②代金支払通知
④受取通知
落札者
au オークション
いるがゆえ、携帯からWebサイトを利用す
ることに煩わしさを感じるユーザー
（特に本
誌読者のような第一線のエンジニア）
は多い
各金融機関
各金融機関
出品者の
口座に振り込み
ペイジェント
⑤代金支払
図4
安心取引サービス「モバペイ」の概要
①代金支払
ATM
コンビニエンスストア
クレジットカード
ネットバンキング
での支払い
と推測しているが、そのような方にもモバオ
クを利用していただくことができるようにな
っている。また、自宅ではPCで、外出時に
は携帯で、というように利用シーンごとに使
い分けることも可能である。
このように、モバオクでは今後も多くのユ
ーザーに利用していただけるよう、機能の
追加開発やユーザービリティ向上を行なっ
ていく予定である。
おわりに
本特集では、携帯向けサービスのメガサ
イト
「モバオク」の開発／運用の実際を説明
してきた。PCや携帯向けのオンラインサービ
スを提供するベンチャー企業としては、オー
プンソースソフトウェアのLAMPを利用して、
ここまでトラフィックが多いサービスを低コス
トで自社開発／運用できていることは競争
力の源泉になっていると考えている。
DeNAとしては、今までの経験から、サ
ービス構築においてほとんどの場合に
「MySQLでOK」
という確信を持っている。
この確信が本特集の読後に読者の方とも
共有できていれば幸いである。
能登信晴（のとときはる）
画面 16
PC向けモバオクのトップページ
株式会社ディー・エヌ・エーにて、ケータイ向け
サービス立ち上げと運用を担当。以前はソリュ
ーション事業の一環で顧客企業向けコンサルテ
ィングや提携サイト構築プロジェクト統括など
も行なっていた。本稿パート 2 の冒頭でも解説
したとおり、モバオクシステムにかかわるあら
ゆる工程を担当している。

Download Report