【＋超裏話】mixi XmasのベルはWindows Azureの上で鳴り響く、大規模ソーシャルアプリの舞台裏
IT media エンタープライズさんですでに掲載頂いているとおり
mixi XmasのベルはWindows Azureの上で鳴り響く、大規模ソーシャルアプリの舞台裏
mixi Xmas 2011のご支援をさせて頂いた。
ここでは、優等生風にまとめたMSDN側のブログからの転載に加え、超裏話的な内容を
補足しつつ、このプロジェクトを振り返ることにしたい。
ちなみに、本日Azureアドベントカレンダーブログの当番枠をいただいている。
他のブログもかなりレベルが高めなので是非参考にして頂きたい。
まずは、Azure製品サイトに書いた内容の転載。プロジェクトの概要は把握頂けるかと。
---
もうすぐクリスマス。
日本のネットシーンにおけるクリスマスの一大イベントといえばMixi Xmas。
3回目を迎える今年も楽しんでおられる方も多いのではないでしょうか？
日本最大規模のソーシャルイベントであるMixi Xmas 2011、
実はWindows Azureで動いているのです。
Mixi Xmas 2011 (mixi アカウントへのログインが必要です)
こちらは、11/28 ～ 12/25 の期間に利用可能なソーシャルアプリで、
アプリ上でくつしたを飾って、友人のベルを鳴らし合ったり、
イベントに参加したりすることでレベルアップ、プレゼントに応募できる
仕組みになっています。また、mixi の決済機能を用いて、友人へギフトを
送ったりすることができる機能も備えています。
PC はもちろん、携帯電話やスマートフォンにも対応、12/20 時点で約250万ユーザーが
利用するアプリとなっており、 Windows Azure コンテンツ配信ネットワーク
(CDN: Contents Delivery Network) が活用されています。12/16～18 にはテレビ CM と
連動したキャンペーンが展開され、Windows Azure の拡張性を活用して柔軟に
スケールアウトさせることにより、突発的なアクセス増加にも対応しています。
ここではWindows Azureを使うことになった背景や簡単な技術解説をまとめてみます。
■採用の経緯
昨年までGoogle App Engine（以下、GAE）で運営されていたのですが、
今年はマイクロソフトがIE9の普及のためにスポンサーになることをきっかけとして、
バックエンドをWindows Azureにする検討を開始したのが夏の終わり頃。
その後、簡易的なパフォーマンス検証と見積もりをクリアして、採用に至っています。
利用者数の伸びが読めず、瞬間最大風速的なスパイクのあるアクセスをさばく
必要がありながら、約1ヶ月の短期利用という、まさにクラウドにおあつらえ向きな
日本最大規模のソーシャルイベントを大きな事故なく、Windows Azureで
ご支援できたことを非常に光栄に思います。混雑時に多少のご不便はおかけ
したかもしれませんが、常連ユーザーのみなさまからは昨年よりつながりやすく
なったとのありがたいコメントも頂いております。
■開発の実際
Google App Engineで動いていた昨年版のアプリをベースに開発しています。
再利用性の観点からJavaのコードをそのままWindows Azureで動かそうという話も
検討はしましたが、主にデータアクセスまわりで独特の実装となっている
Google App Engineのアプリを強引に移植するのではなく、Windows Azure での
安定性とパフォーマンスを重視してASP.NET MVC3で新規開発しています。
企画および全ての画面デザインやUIデザイン、PC向けのFlash、スマホの
演出部分の構築はバスキュール号が、スマホ、ガラケー向け画面含む
バックエンドはWindows Azureでの開発運用経験豊富なFIXERが担当し、
200画面を超える規模の開発を実質約1ヶ月で完了しています。
データの格納先はリレーショナルデータベースであるSQL Azureではなく、
主にKey Value StoreであるTable（GAEでのBig Tableに相当）を利用。
非同期処理のために、Queue（GAEでのTask Queueに相当）を活用しています。
■プロジェクトでの苦悩
キャンペーン向けの短期開発ということもあり、サービス開始当初、アプリのチューニングが
間に合わなかった場面ではインスタンス数を増やしてパフォーマンスを補う対応もしていました。
最終的には性能改善をはかっているものの、限られた時間の中で、アプリの性能を
クラウドリソースでカバーできたのはプロジェクト的に助かっています。
11月28日のサービス開始後、49時間で100万人に到達。昨年より9時間ほど早い
急激なユーザー数の伸びにWebサーバーおよびMemcachedを増強して対応しています。
パフォーマンスカウンタなどで状況をトラッキングしながら本番環境で遅い処理を発見し、
機動的に修正を加えており、複数台のインスタンスを順次更新してゆくインプレイス
アップグレードによりアプリ更新をダウンタイムなしで実施しています。
アプリの性能改善で重視していたのは非同期系のバランスです。サービスの仕組み上、
更新がリアルタイムに反映されなくてもよさそうな更新系の処理はQueue経由にすることで
フロントの応答時間を短縮しつつ、Mixi APIやマスター系のデータ参照はキャッシュ経由に
切り替え、キャッシュの生存期間を調整しています。
12月16日から18日にかけて3夜連続で24時前に放送されたTVCMと連動した企画では、
アクセスの集中を予期して動的生成しなくてもよいコンテンツを中心に構成した上で、
東京のCDNを活用しました。ちなみに、アプリ本体は香港のデータセンターで稼働しています。
■少し気が早いけど振り返り
今回のプロジェクトを通じて、Windows Azureはもちろん、ASP.NET MVC3もアプリを
しっかり作っていれば、定評のある開発生産性の高さや運用の手軽さだけでなく、
高負荷環境で良好なパフォーマンスを発揮できることを改めて証明できたと思います。
かかるサーバー費用は実質値上げ前のGAEで運用していた昨年実績に比べて
若干増えたものの、TVCM連動などの新しい試みを安定して提供することができました。
期間限定サービスということもあり、ピーク時に大量のインスタンス並べたとしても
費用面でのインパクトはさほど大きくなく、やはりキャンペーンサイトでの
Windows Azure活用は相性がよいです。
クリスマスまであと3日。今年もMixi Xmasでみなさんにちょっとステキなユーザー体験を
ご提供できたのは、運営主体であるバスキュール号の企画力、開発運用を担当した
FIXERの粘り強さ、いろいろな支援をしてくれた開発者コミュニティ含むマイクロソフトの
総合力が成功要因であったかと。この場をお借りして、Mixi Xmas 2011にご協力頂いた
皆様に改めてお礼申し上げます。
---
スマートフォンを含むモバイルアプリケーションやソーシャルアプリケーション、
ゲームといった分野でクラウドの活用が進んできています。詳細は下記をご覧ください。
● Windows Azure を利用して モバイルアプリを構築
- Windows Azure Website > Scenarios > Mobile
- MSDN Windows Azure デベロッパーセンター > iOS x Windows Azure 連携アプリケーション開発
● Windows Azure を利用して ゲーム、ソーシャルアプリを構築
● Windows Azure で利用できるOSS 言語、ツールなど
- Windows Azure Website > Develop > Downloads
- MSDN Windows Azure デベロッパーセンター > こんなときには Windows Azure Platform ～ すぐに、いつもの言語と環境で Web サイト構築と立ち上げ
● Windows Azure の利用プラン (サブスクリプション) の活用方法
---
さて、だいぶ長くなったが、ここから本題の超裏話。
まあ、プロジェクトにはいろいろあるわけで、ここからは現場で得られた教訓を、
巻き込んでしまった方々のブログを紹介しながら、みなさんと分かち合いたい。
いずれも正直ベースで現場で苦しんだポイント。
■mixiのJOIN停止
mixiアプリを作ったことがある方にはおなじみ「JOIN停止」問題。GREEやmobageでも
5秒ルールなるものがあるが、趣旨としてはほぼ同じと言える。画面がもたつくことなく
ユーザーエクスペリエンスを高めようという話に加え、帯域を占有させたくないという
通信キャリア側の都合もあってのことと思われる。応答時間が10秒を超えるリクエストが
過去3分以内に1000回発生すると、性能改善を怠っているソーシャルアプリへの
ペナルティとして、新規ユーザーの追加停止、すなわちJOIN停止が発生する仕様。
本番サービスが止まるわけではないが、ソーシャルアプリとしては致命的である。
今回はアプリの性能改善とリソース追加を愚直に行って対応しているが、JOIN停止を
回避するだけであれば下記のブログでまとめてくれている方策でも構わないはずだ。
あるいはnginxなんかでもよいかもしれない。さほど非機能要件にとらわれないような
業務系アプリであれば素直にAzureをPaaSとして使って頂いて全く問題ないが、
性能面での要求が厳しい場合には、これら対応が必要な場面もあり、
ちょっとIaaS的にアーキテクチャを工夫してみてもよいかもしれない。
そういった面での自由度と自動化のバランスはAzureのよいところと思う。
■Azure Storage Table の扱い
というか、Key Value Store全般の扱いについては、いろいろと注意が必要だ。
C#でTableを利用する場合、LINQ to Table と LINQ to Object を併用することになる。
LINQ to Table は非常に便利なのだが、取得できるエンティティ数が1000件未満で
あったり、クエリ実行時間5秒以下にする必要がある、ややツンな面もある。
Azure Tableによるデータ検索処理
IQueryableとIEnumerableって何が違うんでしたっけ？という方は上記ブログを
是非ご参照頂きたい。Tableは要領アタリコストも安いし、無限にスケールするし、
使い方によっては強力無比な心強い味方であることには変わりないのだが、
LINQ構文でSQLっぽい記述ができるとはいえ、リレーショナルデータベースを
扱う気分を抜けきらずに実装するとヤケドする可能性があるので要注意である。
■せっかくMVCだしVisual Studioだし
タイトルの通り。わかっちゃいるけど止められないという現場の都合もわからなくはない。
デザイナーとコーディング担当の分業で、デザイナー側に発言権が偏っている場合、
特に要注意である。このあたりを整理するのはプロジェクトマネージャーの責任。
とはいえ、運営開始後に状況に応じて機能変更をしてゆくソーシャル系アプリの場合、
終盤はもうぐちゃぐちゃで…。という声も聞こえてくる。
それがわかっているなら、せめて、テストを手間なく実施できる環境の整備を
最重点課題として意識しておいて頂きたい。機能面や性能面で何らかの問題が
発覚した際に、コード上でそれを直すのはカンタンなのだけど影響範囲がわからず
テストを手動でやるのは困難…なので見送りという悲しい状況は避けるべきである。
データアクセス層の変更と動作確認を簡易的に行える環境であれば、性能改善は
飛躍的にスムーズに行えるだろう。
特に日本の場合、残念なことにWeb系の方は慣れない方も多いかもしれないが、
Azureを使う場合、Visual Studioで開発することになるだろう。単なる高機能エディタ
としておくのはもったいない。すべてのテストを自動化できるようにしておけとは
言わないが、Visual Studioを使っているメリットを最大限享受して頂きたいものだ。
「そんなに便利なことできるんですか？」という一見ありがたい素直な反応を見るたびに、
我々の日頃の啓蒙不足を反省せざるを得ない。
---
他にもまだいろいろあるが、それは個別に飲みの席ででもお話ししたいと思う。
社内外でAzureに関わる人たちのポテンシャルを改めて感じたプロジェクトでもあった。
Azureの底力と我々の総合力を持ってすればできないことはそう多くないだろう。
今回関わってくれたすべての人たちに心からありがとう！と言わせていただきたい。
24日には超豪華プレゼント応募の締め切りが、25日には全プレゼントの発表が
待ち構えており運営サイドはまだ気が抜ける状態ではないのだが、
終わりのあるサービス、プロジェクトって素晴らしい。
すべてが終わって、26日になったら「バルス！」といいたいところをぐっとこらえて
1日遅れの「メリークリスマス！」を、笑顔で迎えたいね。