あらためまして
株式会社ディー・エヌ・エーの高岡です。主にインフラ関連を担当しています。
この連載の前回も記載しましたが,特にファシリティ関連のインフラエンジニアに関しては,転職による仕事の違いはほとんどありません。なので,事務的な作法は全て覚え直しなのは仕方ないとして,実作業では,「効率的に運用が徹底されている」と思ったり「こういった部分に興味は無い傾向にあるようだ」など客観的に見て,プラスになる部分は,どんどん吸収させていただいています。
さて,今回からはソーシャルゲームで一躍有名に,大規模システムを運営する事となったディー・エヌ・エーの数字的な部分と,それを支える技術を見ていきたいと思います。技術に関してとはいっても,MySQLやPerl等に関しては既に有名な方々から発信されていますので,私からは,インフラ,ファシリティに関するアーキテクチャを解説できればと思います。
ディー・エヌ・エーが大規模と呼ばれる理由
以下のグラフはディー・エヌ・エーのIRから取得した資料です。主にモバオク(au oneモバオク含む)とモバゲータウンに関連した数値をピックアップしてみました。
はじめにモバオク関連ですが,こちらは有料会員が123万人前後で推移しております。PV数等が公表されていないために,ネットワークやインフラ的な規模は想定し難いの割愛しますが,経営的には非常に優良なサービスと言えると思います。
次にモバゲータウンの数値です。
会員数に関しては,右肩上がりの奇麗なグラフとなっています。2010年7月は2,048万人となっており,日本の人口,競合他社を加えた分母を考えると成長の域はあるものの,天井も見えつつある数字かと思ったりします。そして,その2,048万人が利用するサービスは74,015(百万)PVという数字となって現れます。
細分化してみると以下の通りとなります。
| 単位 | アクセス数(百万) |
|---|---|
| 月 | 74,015 |
| 日(1ヵ月30日計算) | 2,467 |
| 時間 | 102 |
| 分 | 1.7 |
| 秒 | 0.028 |
数値は平均化されてコンスタントに処理していることはなく,昼夜,平日休日,コンテンツのイベント的な仕掛けによって大きく左右されます。しかしながら,改めて見ても日本有数のPV数を誇るといっても過言でもありません。
大まかな構成
次は実際にどのようなキャスティングでこのPVを処理しているのか見てみましょう。
①通常,一般的なサービスを構築する際の構成として,アプリケーションサーバ(Webサーバ)とデータベースサーバの関係(階層)に関してほとんど変わりはありません。(図4)
この状態で順調にサービスが成長した場合,Webサーバ側で大量リクエストの処理に詰まってしまう可能性があります(図1の赤い線の部分)理由は先述したサービス成長に伴うリクエスト増加とDBサーバに対する処理応答待ち,すなわちデータ量の増加等が挙げられます。
この問題を解決する場合のインフラ側の対応として,静的コンテンツのキャッシュや,データベース問い合わせ結果の一時保管(一時キャッシュ)が挙げられます(分散KVSやmemcachedなどといったキーワードがこのあたりに該当することが多くあります)。
このような仕組みの導入による対応とあわせてデータベース側のチューニングを同時に施すことにより,そのシステムの限界点はかなりのレベルまで引き上げることができます。
②さらにサービスが成長を続けた場合ネックになる部分としては,お察しの通り,ネットワーク関する回線や機器の性能限界となりボトルネックとなります(図5)。
対応としては回線,ネットワーク機器の増強を行いますが,昨今のSNS市場の爆発的な負荷増加は,こうした対応の上を行くもの,また会社としてもその上を目指すものであり,それらを考慮した対策が必要となります。
③大規模リクエストを処理する。または,大容量コンテンツ(動画のストリーミングやデータダウンロード)のやり取り等を行うシステムは,そのシステム外で比較的インターネット直結に近い部分にキャッシュを置き,負荷の原因になるものを,そこでキャッシュする設計になっていたります(図6)。
ディー・エヌ・エーの場合,静的コンテンツとして,アバターのパーツ等における画像コンテンツをこの対象とする事で,同様のコンテンツを処理する通信は全て外部のキャッシュにて解決しております。 このようなシステムを一般的にCDN(※1)と呼びます。
- ※1
- CDN(Contents Delivery Network)とは, Webコンテンツをインターネット経由で配信するために最適化されたネットワークのことである。コンテンツ配信網とも。(WikiPediaより)

