あらためまして
株式会社ディー・エヌ・エーの高岡です。主にインフラ関連を担当しています。
この連載の前回も記載しましたが、特にファシリティ関連のインフラエンジニアに関しては、転職による仕事の違いはほとんどありません。なので、事務的な作法は全て覚え直しなのは仕方ないとして、実作業では、「効率的に運用が徹底されている」と思ったり「こういった部分に興味は無い傾向にあるようだ」など客観的に見て、プラスになる部分は、どんどん吸収させていただいています。
さて、今回からはソーシャルゲームで一躍有名に、大規模システムを運営する事となったディー・エヌ・エーの数字的な部分と、それを支える技術を見ていきたいと思います。技術に関してとはいっても、MySQLやPerl等に関しては既に有名な方々から発信されていますので、私からは、インフラ、ファシリティに関するアーキテクチャを解説できればと思います。
ディー・エヌ・エーが大規模と呼ばれる理由
以下のグラフはディー・エヌ・エーのIRから取得した資料です。主にモバオク（au oneモバオク含む）とモバゲータウンに関連した数値をピックアップしてみました。
はじめにモバオク関連ですが、こちらは有料会員が123万人前後で推移しております。PV数等が公表されていないために、ネットワークやインフラ的な規模は想定し難いの割愛しますが、経営的には非常に優良なサービスと言えると思います。
図1 モバオクの推移
次にモバゲータウンの数値です。
図2 モバゲータウンの推移
会員数に関しては、右肩上がりの奇麗なグラフとなっています。2010年7月は2,048万人となっており、日本の人口、競合他社を加えた分母を考えると成長の域はあるものの、天井も見えつつある数字かと思ったりします。そして、その2,048万人が利用するサービスは74,015（百万）PVという数字となって現れます。
図3 モバゲータウン月刊PV推移
細分化してみると以下の通りとなります。
| 単位 | アクセス数（百万） |
| 月 | 74,015 |
| 日（1ヵ月30日計算） | 2,467 |
| 時間 | 102 |
| 分 | 1.7 |
| 秒 | 0.028 |
数値は平均化されてコンスタントに処理していることはなく、昼夜、平日休日、コンテンツのイベント的な仕掛けによって大きく左右されます。しかしながら、改めて見ても日本有数のPV数を誇るといっても過言でもありません。
大まかな構成
次は実際にどのようなキャスティングでこのPVを処理しているのか見てみましょう。
①通常、一般的なサービスを構築する際の構成として、アプリケーションサーバ（Webサーバ）とデータベースサーバの関係（階層）に関してほとんど変わりはありません。（図4）
図4
この状態で順調にサービスが成長した場合、Webサーバ側で大量リクエストの処理に詰まってしまう可能性があります（図1の赤い線の部分）理由は先述したサービス成長に伴うリクエスト増加とDBサーバに対する処理応答待ち、すなわちデータ量の増加等が挙げられます。
この問題を解決する場合のインフラ側の対応として、静的コンテンツのキャッシュや、データベース問い合わせ結果の一時保管（一時キャッシュ）が挙げられます（分散KVSやmemcachedなどといったキーワードがこのあたりに該当することが多くあります）。
このような仕組みの導入による対応とあわせてデータベース側のチューニングを同時に施すことにより、そのシステムの限界点はかなりのレベルまで引き上げることができます。
②さらにサービスが成長を続けた場合ネックになる部分としては、お察しの通り、ネットワーク関する回線や機器の性能限界となりボトルネックとなります（図5）。
図5
対応としては回線、ネットワーク機器の増強を行いますが、昨今のSNS市場の爆発的な負荷増加は、こうした対応の上を行くもの、また会社としてもその上を目指すものであり、それらを考慮した対策が必要となります。
③大規模リクエストを処理する。または、大容量コンテンツ（動画のストリーミングやデータダウンロード）のやり取り等を行うシステムは、そのシステム外で比較的インターネット直結に近い部分にキャッシュを置き、負荷の原因になるものを、そこでキャッシュする設計になっていたります（図6）。
図6
ディー・エヌ・エーの場合、静的コンテンツとして、アバターのパーツ等における画像コンテンツをこの対象とする事で、同様のコンテンツを処理する通信は全て外部のキャッシュにて解決しております。 このようなシステムを一般的にCDN（※1）と呼びます。
CDN化を実現するプロダクトとサービス
それではこれらのシステムはどのように構築されるべきものなのでしょうか？ 具体的なサービスやプロダクトで見てみましょう。
アカマイ（Akamai）によるCDNサービス
CDN環境を実現するための専門のインフラ設備を持った業者です。現時点ではディー・エヌ・エーをはじめ、名高い企業が利用しており、正に業界最大手であります。 コンテンツ転送量を積算にて課金したりするため、サービスが成長すると比例してコストを必要としますが、急成長による、通信量、負荷等の吸収、サービス開始までのリードタイムが短くて済む等の利点があります。
有償サービスを利用しない場合、自社でサーバや回線の調達を行い、運用まで含めて面倒を見る必要があります。その際に利用するべきプロダクトとしていくつかありますので、よく検証をして、自社のスタイルにあったプロダクトを選定することをお勧めします。
squid
比較的歴史が古く、有名なプロダクトです。設計が古いため、昨今のプロダクトと比較するとハードウェアリソースを使い切れないとか、そもそもプロダクトとしてのパフォーマンスの限界等と言われることもあるようです。たとえば、ロードアベレージが高い割にはCPUのコアが単一でしか利用できない（他のコアを利用しないなど）これは直近のハードウエアとの組み合わせでよく聞かれることですが、逆に非常に安定している事と、有力な情報がたくさん手に入ると思います。展開するサービスが安定している等といったことなどと総合して検討すればと思います。
nginx
軽量Webサーバやリバースプロキシ、L7などでのロード分散としての資料は手に入りやすいのですが、コンテンツキャッシュとしての事例がなかなか見当たらず、実際に利用する場合は検証が必要かと思います。
TrafficServer
USのYahoo!が部分的に採用していたもので、元々は昔買収したInktomi（懐かしい）にも同様のものがあったかと思います。それを進化させたものかどうかの確証はありませんが、日本のYahoo!でも一部採用されているらしいとのこと。ビッグユーザが大々的に利用し、オープンソース化に踏み込んだプロダクトとあれば、今後注目される可能性があります。
varnish
少し前から名前を聞き始めるようになりました。国内外、名高いサービスでも採用されているようで、少し検索してみれば（利用しているサービスは限定的な可能性もありますが）Twitter、FacebookをはじめWikia、Slashdot、Opera、VGなどで利用しているようです。
自社サービスのコンテンツをCDN化する場合、以上のような性質を持つプロダクトを、図6の静的コンテンツのキャッシュ部分に該当するサーバに導入、設定を行いサービス展開します。
CDNのシステム構成
それでは、静的コンテンツを分散してキャッシュするシステム構成はどのようにすべきでしょうか？ ここからは机上の設計と検証、本番への一部組み込みを行い改善するというサイクルを重ねて安定させていく所ではありますが、一番最初の大方針は重要です。特に、現状同等の構成でさらなるアクセス向上を前提に考えるようであれば、インターネット側に負荷分散できる仕組みを置き、その内部は階層的になるようキャッシュサーバを配置することを検討します。
最終的には、キャッシュサーバ側の代表（親）を決めて、キャッシュ内で解決できなかったコンテンツをオリジナルからロードできる形を検討します。
図7 キャッシュサーバの構成
基本中の基本の構成、動きはそんなに複雑ではありません。内部にあるものを外部に出すために必要な関連付けを行うことと、内部の動きを理解しておけば、初めてでもそれなりに構築できると思います。たとえば、リクエストを受け付ける部分をキャッシュ側にするのであれば、DNSの名前解決の先を変更したりする必要があります。
CDN内のキャッシュサーバは、リクエストされたデータをある一定の単位で保持することができること、キャッシュに無い場合の挙動（APサーバなど後ろへパスする）、利用状況からよりアクセス頻度の高いコンテンツと、そうでないコンテンツを、たとえばメモリ上へ展開する、ディスクへ退避させるなどを定義できること、特定のコンテンツなど、明示的にpurgingすることができることが基本機能として求められることかと思います。
同じように運用機能として何を提供するべきか十分に検討する必要があります。たとえば、間違ってコンテンツを登録したため、緊急で消したい（部分的なキャッシュクリア）、ある程度まとめて消したい（バッチ的な機能）などは実際にアプリケーションを開発、運用している担当が必要とする機能だと思います。
また、安定運用、効率化という観点では、ヒット率向上のスコアリング化、コンテンツ消滅のためのルール等を決め、チューニングする必要があるでしょう。
まとめ
ディー・エヌ・エーの場合、現在外部サービスを利用している関係上、上記に関わる「サービスを通じた実践的なノウハウ」を今の所は持ち合わせておりませんが、いろいろな可能性を日々検証しています。
次回は、どのような検証を行っているか、その内容と結果について紹介できればと思います。
