pr

ミツバチワークスのエンジニアは、「月間57億PV」という巨大なトラフィックをさばくため、さまざまな技術を駆使してインフラを構築している。主と副の2本立てでデータベースを運用し、300台のサーバを使いながら「負荷の限界」に挑むエンジニアに、技術ノウハウを聞く。

　ミツバチワークスが運営するケータイブログサービス「DECOLOG」は、異色のサービスである。10代後半から20代前半の女性に最も人気のあるケータイブログサービスで、「デコメール」などを利用して、かわいくカラフルなブログを作成できる。広告基準を厳しくすることで女性ユーザーにも不安なく使ってもらえるような安心感を作り出し、口コミだけでじわじわとアクセス数を伸ばしてきた。

　結果、2010年7月実績で月間57億PV（ページビュー）超、想定800万UU（ユニークユーザー）、会員登録者数180万件と、ケータイブログサイトでは国内最大のサービスとして成長している（図1）。

　同社が異色なのは、サービスがここまでの規模に成長していながら、アプリケーション構築からサーバ運用までをごく少人数のエンジニアが行っていることだ。特にサーバ運用の体制は「片手で数えられる人数で回しています」（同社ディベロップメントディレクター 諸富洋氏）というから驚く。

　同社は、膨大なトラフィックと大量のコンテンツに対応するため、さまざまな技術を自力で選定し、インフラを構築してきた。エンジニアの1人である諸富氏に、同社が編み出したインフラ運用のノウハウを聞いた。

アクセス急増の時期に会社へ参加

　諸富氏は、初めは「助っ人」だった。フリーエンジニアの立場で、2009年10月に同社のシステム構築・運用に参加した。このころ、すでにDECOLOGは月間30億PVを超える大型サービスとして急成長を続けていた。

　「アクセスが伸びていたサービスの中身に興味を持ちました。最初は半年の約束で参加しました」

　そこでの実績を買われ、2010年4月から同社に加わった。「半年働いて、会社の雰囲気も気に入っていました。これから伸びていくサービスに、外注ではなく当事者として参加する、というところに面白さを感じました」と、諸富氏は振り返る。現在、同社の技術責任者を務める利根川郷氏とともに、インフラ運用からアプリケーション開発までかかわっている。

「デコメ絵文字」対応のため、膨大な数の画像ファイルを扱う

　同社のシステム構成は、図2のように変遷した。現在の構成は、Web層とデータベース層の両方で、複数のキャッシュ機構と負荷分散機構を取り入れた複雑なものとなっている。

　このような構成が必要となった背景には、単にトラフィックが多いだけでなく「データ量が多い」という事情がある。DECOLOGでは、「デコメール」などで使われる「デコメ絵文字」をブログの記事中で利用できる仕組みを実現している。「デコメ絵文字」はそれぞれが画像ファイルなので、同サービスが扱う画像ファイル数は非常に多い。そこで画像データベースの取り扱いが大きな課題となる。

　DECOLOGサービスの初期には、画像データベースの負荷を解消する手段として、画像をデータベース管理システムに格納するのではなく、ファイルシステムへ格納するやり方を試みたことがある。だが、UNIXファイルシステムのinodeが足りなくなってしまい、やむなく断念した。ファイルシステムの上限値に達するほどの画像ファイル数を取り扱う点が、DECOLOGの大きなチャレンジなのである。

Web層とデータベース層それぞれに キャッシュ機構と負荷分散機構を組み入れる

　同社のインフラのキャッシュ機構と負荷分散機構の概要を、図2に沿って説明しよう。まず、サーバへのトラフィックは、ロードバランサーが振り分ける。その後、画像ファイルへのWebアクセスを分散するため、エッジ・サーバ部分で、軽量WebサーバソフトNginx（エンジンエックス）の機能を利用して、コンシステント・ハッシングに基づく負荷分散を実施する。そのうえで、HTTPキャッシュサーバsquidを利用してWebアクセスを高速化している。

　同社のサービスの場合、特にボトルネックとなりやすいのは、データベース層である。データベース・アクセスを高速化するため、メモリ上にデータベース・アクセスをキャッシュするmemcachedを活用。さらに、データベース管理システム（MySQL）への直接のデータベース・アクセスの分散のため、LVS（Linux Virtual Server）を活用している。だが、高速化の工夫はこれだけでは終わらない。

主と副の2本立てでデータベースを運用。 大量のトラフィックと画像ファイルに対処

　一般に、大量のトラフィックを集めるシステムでは、データベース・アクセスをメモリ上のキャッシュにより吸収し、データベース管理システム（同社の場合MySQL）へのアクセスを極力減らすことが望ましいとされている。ただしDECOLOGの場合、キャッシュによる高速化だけでなく、MySQLのデータベース・アクセス自体を高速化する仕組み作りも欠かせなかった。

　DECOLOGには、このサービス特有の条件がある。まずユーザーの記事更新が活発なため、記事データのライフサイクルが早い。つまり頻繁にアクセスされる時期が短いのだ。次に、「デコメ絵文字」があるため、1本の記事に含まれる画像ファイルの数が通常のブログサービスに比べて格段に多く、キャッシュのヒット率を保つことが難しい。

　この条件に対応するため、同社は更新時期が新しいデータを格納する主データベースと、古いデータも含めたアーカイブを格納する副データベース（アーカイブ・データベース）の2本立てでデータベースを運用するという方法を編み出した。

　大量のトラフィックに対応するため、主データベースは図3に示すように分割を施している。記事IDを見て、アクセスするデータベースを振り分ける。これにより、1つのデータベースにアクセスが集中してボトルネックになることを防ぐ。

　ただし、せっかく分割しても、個々のデータベース容量が大きくなり過ぎると、アクセス速度が低下してしまう。そこで、全データを格納した副データベース（アーカイブ・データベース）を用意し、一定の期間を過ぎたデータへのアクセスは、副データベースを参照する形としている。この副データベースへのアクセスは低速だが、アクセス発生の頻度は低い。このやり方で、新しいデータを格納した主データベースの容量が大きくなりすぎて低速になることを防いでいる。

　主データベースから古いデータを削除するため、一定期間ごとに主データベースの内容は入れ替える。主と副の2系統のデータベースを持つことで、このような運用が可能となった。

「どんなパケットが飛ぶかを考えないとプログラムが書けない」

　アプリケーション開発には、PHPを利用している。このアプリケーション開発や、日々の運用でも、独特の注意が必要だという。

　「圧倒的なトラフィックの前では計算外のことが出てきます。例えば、データの移動方法やキャッシュの消し方を間違えると、Webサイトが落ちる事態に陥ることもあります。アプリケーション・プログラムも、『サーバの間でどんなパケットが飛ぶか』を考えながら書く必要があります」

　同社は、同社のサービスやコンテンツの特性に対処するため、日々新しい技術を試している。「もともと技術好きなので、いろいろなツールを試します。ただ、最終的な採用に至らない場合も多い」と、諸富氏。前述の軽量WebサーバソフトNginxも、試行錯誤した中から選定したソフトウェアである。

　同社は、最近注目を浴びている、いわゆる「NoSQLデータベース」も試している。Tokyo Cabinet/Tokyo Tyrant（平林幹雄氏がミクシィ所属時に開発）、Flare（グリー 藤本真樹氏らが開発）などを評価したが、採用には至っていない。諸富氏によれば、「あるサービスでうまく機能しても、別のサービス、別のコンテンツではうまく機能しない場合がある」という。

　ただし、利用条件が変われば結果も変わってくる。「今後、NoSQLの得意な人に開発チームに参加してもらい、実力を発揮してもらう可能性は十分にあると思います」と諸富氏は語る。

　運用ツールとして、Capistranoを導入している。Ruby on Railsの運用ツールとして知られているが、PHPで開発したアプリケーションにも適用できる。

　「数十台のサーバのセットアップを一挙に実行でき、ずいぶん助かっていますね」

一晩で200GByte超のログをHadoopで解析する

　巨大なトラフィックを集める同社のサービスでは、ログ解析も大仕事だ。ログファイルの容量は、なんと1日で220GByte。11台のノードを使い、Hadoop（MapReduceアルゴリズムによる分散処理フレームワーク）※を活用して、ログ解析を実施している。諸富氏に解析時間を聞いたところ、「午前4時半から解析を始めて昼ごろまで」という答えが返ってきた。昼ごろにログ解析結果が出れば、必要な対策を日中に施せる。そのため、「昼までに解析が終わるように、とノードを増やしていったら11台まで増えました」と諸富氏は語る。例えば、2秒以上かかっているアクセスがあれば、すぐ分かるようになっている。

※Hadoopについて「米Yahoo!が開発した」と記載しておりましたが、誤りであったため、2010年9月22日20時に修正いたしました。

　失敗談もある。「一時期、なんでもHadoopで処理するブームのような時期があって。ところがHadoopで分散処理して10分以上かかった処理が、sedとawk（それぞれUNIXの基本的なコマンド）では5分で済んだこともあります。適材適所は大事ですね」と笑う。

「仕組み作り」を考える日々

　日々、膨大なデータ量をさばく諸富氏に、同社のインフラ運用に対する考え方を聞いた。「ポイントとして、1回トラブルが起きたら、同じトラブルは起きない仕組みを作るようにする。できなければ、すぐ検知可能にする」ことが方針だという。

　例えば、同社ではデータベースのレプリケーション（複製）では、slaveに最低3台のサーバを適用している。2台構成の場合、1台のデータベースが壊れたときはシステムから外して復旧することになるが、その間は運用中のサーバが1台だけとなり、冗長性がなくなってしまう。経験から、常に冗長性を維持するため3台のサーバが必要との結論になった。

　少人数で巨大なサービスを構築、運用するミツバチワークスは、日々工夫を重ね、独自のノウハウを編み出しつつある。これらの技術の一端は、Twitter（@DECOLOG_TECH）で見られる。「技術的な質問も含めて、気軽に話しかけていただけるとうれしい」と、諸富氏は語る。

　DECOLOGは、300台のサーバ群と多層キャッシュ機構・負荷分散機能に支えられ、今日も果敢に莫大なトラフィックとデータを処理し続けている。

提供：ミツバチワークス株式会社
企画：アイティメディア営業企画
制作：＠IT自分戦略研究所 編集部
掲載内容有効期限：2010年9月30日