6月30日、株式会社gumi CTO 堀内康弘氏による技術セミナー「Python×Django×AWSで作るソーシャルアプリ ～3日に1つアプリをリリースできた理由～」が開催された。オプト主催のソーシャルアプリコンテスト タイアップセミナーの一環で、今回で2回目の開催となる。
ソーシャルアプリ開発に
Python×Django×AWSを選んだワケ
gumiは、エンタメ情報に特化したモバイルSNS「gumi」を手がける開発会社で、日本初の携帯向けOpenSocialプラットフォーム「gumi Platform」を提供したことでも知られる。35タイトル以上のmixiアプリを開発・運用しており、提供者ごとのユーザー数ランキングで上位3位に入るなど、モバイル向け開発に強みを持っている。
同社では「再利用を考えた設計」「自動処理によるシステム化」を徹底することで、次々とアプリをリリースできるようにしているという。開発にはPythonとWebアプリケーションフレームワークの「Django」、サービス管理はGit、デプロイはCapistrano、サービス運用はAmazon Web Services（AWS）を利用。virtualenvとpipでアプリごとにバーチャルなPython環境を構築している。
開発言語Pythonの選定理由については、Googleが使っているという信頼感の他に、Pythonの設計哲学の一つ「There should be one.」でも表されるコードの可読性・統一性を挙げた。堀内氏のPython歴は1年だが、それ以前は10年ほどPerlでWebアプリケーション開発に従事していたという。Perlでは「There's more than one way to do it.」とPythonの真逆の考え方があり、当然メリットも少なくないが、堀内氏としてはモジュールの選定やバージョン依存による環境構築の問題、自分にしか分からないコードの可読性の低さといった悩みを抱えていたようだ。Pythonでは誰が書いても同じようなコードになるため、チーム開発により適しているのではないかという見解を示した。
また、Djangoでは「フルスタック」の機能が提供されるため、環境構築に悩まされず、アプリ開発に専念しやすい。データ管理のWebインターフェイスも「組込みのadmin（管理画面）機能」で簡単に実装でき、細かいデータ調整が多いゲーム開発に便利。「プロジェクトがアプリケーションの固まりで構成される」概念があるため、オープンソーシャルに特化した部分を切り分けて他のゲームで再利用しやすいことや、なかなか教育のコストがかけづらいベンチャー企業で重宝する「充実したドキュメントの存在」も長所として述べた。
AWSの導入は、検定アプリをリリースした際、アクセス集中により数分でシステムダウンしてしまったことがきっかけ。サーバーを自前で増強するには数日かかるため、すぐに使え、アプリケーションの変更も必要ないAWSを選択したという。インフラ専任エンジニアがいない状況だったので運用コストを抑えることができ、新しい試みを気軽にテストできるオンデマンドの料金体系もメリットも享受できた。知人の会社ではレイテンシやコストの問題でまだ導入が進んでいない印象だと述べつつも、同社でAWSを使い続けている理由について、「将来的にはクラウドサービスが主流になると考えている」「システム化された運用、規模の経済によって利用料金が毎年安くなっている」「やるとなったらすぐにやる、という社長方針（物理サーバーの調達に数日かかるのはナンセンス）」と説明した。
ソーシャルゲーム開発の要は「負荷分散」
携帯向けソーシャルゲームの開発が従来のWebアプリとの異なる点について、アクセスが直接ではなくプラットフォーム経由で来る「やりとりする相手の違い」、OAuth Signatureでアクセス元のプラットフォームを保証しQueryStringでユーザーIDを取得する「ユーザー認証方法の違い」、ユーザー情報・行動履歴・課金・招待などの操作が行える「豊富なAPI」の3つを挙げた。中でも面白いゲームを作るカギはAPIの活用にあるとし、ユーザーがユーザーを呼ぶ仕組みをしっかり設計することで、雪だるま式にユーザーが増えていくという実感を示した。特に位置情報については、キラーアプリがまだ出ていないので今後期待しているテーマだという。
また、「開発効率も重要だが、実際に動くシステムを作るのが一番大事」と、あらかじめ負荷分散を考慮した設計の重要性を強調した。人気のあるアプリケーションでは、リリース直後に数万人のユーザーがつき、1日あたり3,000万PVを超すことも少なくない。
具体的にまず考慮すべき点として「データベースへの書き込み」を挙げた。Webアプリであれば分散、データベースからの読み込みであればレプリケーションで対応できるが、書き込み処理はスケールしにくくボトルネックになりがち。解決策として、「主キーによる参照を意識する（gumiではMySQLのInnoDBを使っている）」「ManyToManyFieldは基本使わない」「filterもあまり使わない」ことによる、「遅いクエリの見直し」を勧めた。例えば、友達リストを実装する場合、通常、ユーザーテーブルと中間テーブルによる多対多のリレーションを考えるが、ユーザーが100万件規模になるとJOINの処理の負荷がかなり高くなってしまう。このような場合は、ユーザーテーブルに友達フィールドとしてカンマ区切りのIDを持たせ工夫しているという。
さらなる対策としては、「データベースへのアクセスを減らす」ことを考える。gumiでは、読み取り処理については「memcached」（オンメモリのハッシュテーブル、Djangoでは標準機能で使える）、書き込み処理については「Tokyo Tyrant」（データ永続性のある高速なハッシュテーブル）を利用しているという。ロワイヤル系ゲームへの適用例として、memcachedはユーザーのPlayerインスタンスのような毎回取得されるモデルや、FAQなどリアルタイム性の低いページのキャッシュに。Tokyo Tyrantは計算が煩雑な総攻撃力の算出を、攻撃アイテムの増加などのイベントのタイミングで計算して登録しておき、通常は参照するだけにする、といった使い方を紹介した。
なお、同社の一般的なアプリの構成としては、Amazon EC2側はロードバランサーが1～2台、アプリケーションサーバーが5～20台、ログ管理用のNFSサーバーが1台、memcachedのキャッシュサーバーが1台、Tokyo Tyrantのデータベースサーバーが2台で、Amazon RDS側でMySQL 5.1のデータベースサーバーが1台という組み合わせが使われているとのこと。
