SlideShare a Scribd company logo
Python × Django × AWSで作る
   ソーシャルアプリ開発現場

      株式会社gumi
       堀内康弘
アジェンダ


•   自己紹介
•   会社紹介
•   開発���制の紹介
•   gumiとAWS
•   RDS
自己紹介


• 株式会社gumi CTO
• Twitter: horiuchi
• 10年くらいウェブアプリ作ってます。
 – Perl 10年、Python 1年
• ゲームが好きです。
 – 今はMGO,MGSPWやってます。
• ランニング、筋トレにはまってます。
会社紹介


• 35タイトル以上のアプリを開発・運用
• 延べユーザ数10,000,000人
• 多プラットフォーム展開
 – mixi、モバゲ、GREE
• ソーシャルゲームはもちろん、ソーシャル
  ライフ分野のアプリも作ってます
ソーシャルゲーム x ソーシャルライフ




ソーシャルライフ系              ソーシャルゲーム系
・空飛ぶ                   ・DeNA     Rekoo 650万
→マイミク通信簿 340万           →怪盗ロワイヤル 
                            幕末英雄伝→サンシャイン牧場
        ファンクラブ
                       250万 キャバウォーズ460万
        同級生掲示板              刑事ハードボイルド
                       ・ ウノウ     Rakoo 380万
                            現在開発中×2
        卒業アルバム
                        →まちつく 270万
                                 →みんなの農園
        同級生を探せ              占い診断系×40+
                       ・ ベクター 190万 160万
                        →恋する私の王子様→みんなの動物広場
                        150万      140万
サポートツール系

・ GPS連動アド         ・ Facebook connect
・ リワードプラス(アドウェイズ) ・ mixi connect
・ poncan(ドリコム)    ・ connect with twitter
                  ・ gree connect
ソーシャルライフ




ファンクラブ   220,000人



同級生掲示板 520,000人


卒業アルバム おとなver. 300,000人

同級生をさがせ! 120,000人
占い、診断系アプリ



SM診断〜あなたの本性暴きます   O型度判定〜う〜んO型かなぁ?
浮気性チェック!          2人のラブラブ度診断
 その愛本物?ニセモノ?      恋の成就度診断
犬タイプvs猫タイプ        のだめカンタービレ進級試験初級
草食系 vs 肉食系         戦国雑学王決定戦★立志編
ザ★おバカ検定           のだめマエストロコンクール
むっつり度ちぇ〜っく!!    ノーマル?orアブノーマル?
A型度判定〜本当にA型です��?
                のだめカンタービレ進級試験中級
常識・非常識〜あなた常識人?
                のだめカンタービレ進級試験上級
 KY診断〜空気読めてる?
                戦国クイズ王全国ランキング
 ナルシスト★診断
 モテ↑非モテ↓診断
B型度判定〜ジーマーで型B?
じじばば検定〜若さ保ってる?
フリ派?フラれ派?
                  合計 約600万ユーザー
AB型度判定〜ABですが何か?
ソーシャルゲーム


• 2009年2月 幕末英雄伝 660,000人
• 2009年3月 キャバウォーズ 1,300,000人
• 2009年4月 刑事ハードボイルド 600,000人
• 2009年5,6,7月 多プラットフォーム展開
開発体制
開発体制

•   1アプリ1チーム体制
•   Pythonエンジニア 25人(うち女性6人)
•   開発者は全員Mac
•   開発言語はPython x Django
•   エディタは自由
    (Emacs,vi,Eclipse,NetBeans)
•   southでスキーマ管理
•   Gitでソース管理
•   Capistranoでdeploy
•   AWSでサービス運用
Why Python ?


• そこにあった
• There should be one
    – コードの可読性、統一感
• virturalenv, pip
    – 環境構築の容易さ
Why Django?


• これもあった
• フルスタック
    – コードの統一化
• admin
    – コードの再利用
• application
    – 再利用可能な設計
• ドキュメント
    – 学習コスト、教育コストの削減
• スケジュールされたバージョンアップ
Why AWS?


• それしかなかった
  – サーバ追加のタイムラグが小さい。
  – オペレーションコストを減らせる。
  – 実験・テストを気軽にできる。
gumiとAWS
GumiとAWS


• 全てのアプリをAWS上で運用
• EC2インスタンス140台
   – Us-east 100台
   – Us-west 20台
   – Singapore 20台
• RDS 12台
• 今月の費用は$80,000
AWS との出会い
2009年11月


•   mixiアプリモバイルリリース
•   検定アプリをリリース
•   データセンターハーフラック
•   物理サーバ3台
5分でサーバダウン
どうしよう?


• プログラムのチューニング?
  – 一定の効果はあるものの
• サーバを増設?
  – 時間がかかる
  – ラックに空きがない
AWS がいいらしい
調査開始


• ボタンひとつでサーバを増やせるらしい
• AutoScalingで負荷に���わせてサーバの台
  数を自動で調整できるらしい
• RDSという簡単にMySQLを使えるサービ
  スがリリースされたらしい
これしかない!
初期のサーバ構成
初期の構成


• ロードバランサにELB
• AutoScalingでAppサーバを伸縮
• NFSサーバにプログラムソースを配置
ELB


• 検定導入当初すこぶる順調
• ゲームに導入(アクセス量が多い)
• ELB自身のスケールアップ時の通信断問題
   – 10分間にレスポンスタイム10秒以上のリ
      スクエストが1000件あるとアウト
   – 現在はAmazonに依頼しあらかじめスケー
      ルアップさせておくことで回避可能
• mod_proxy_balancerに置きかえ
Auto Scaling


•   AutoScaleしたときの感動
•   プログラムが安定しないと・・・
•   NFSサーバの負荷問題
•   ELBをやめた影響
•   いったん使用停止
RDS


•   お手軽にMySQLサーバを使える
•   Multi-AZにより、高可用性アップ
•   ディスク容量は余裕をもたせる
•   RDSを前提とした設計
     – Read memcached
     – Write Tokyo Tyrant
現在のサーバ構成
AWS 現状の課題


• ネットワーク、IOまわりの安定性
  – EBSがたまに不安定になる
  – 突然名前が引けなくなる
     • 8ヶ月で2回程度
  – 稼働率は物理サーバと変わらない
RDS
RDSのいい点


•   セットアップが簡単
•   バックアップが自動
•   スケールアップが簡単
•   セキュリティ設定も簡単
•   パッチも勝手に適用してくれる
•   適正なデフォルト設定
•   Multi-AZにより、高可用性アップ
Multi-AZについて


• 別のzoneにホットスタンバイを作成
• フェイルオーバーしてくれる
• バックアップ時のI/Oフリーズがなくなる
• セキュリティーパッチ時のフリーズもなく
  なる
• スケールアップ時のフリーズもなくなる
• コストは2倍
RDSの悪い点 (Multi-AZ以前)


•   レプリケーションできない
•   タイムゾーンを変更できない
•   バックアップ時にI/Oフリーズ
•   スケールアップ時にフリーズ
•   セキュリティパッチ適用時にフリーズ
RDSのベストプラクティス (Multi-AZ以前)


• レプリケーションできない
  → ないものと考える
• タイムゾーンを変更できない
  → アプリで吸収
• バックアップ時にI/Oフリーズ
  → じっと我慢
• スケールアップ時にフリーズ
  → じっと我慢
• セキュリティパッチ適用時にフリーズ
  → パッチが出ないことを祈る
RDSの悪い点 (Multi-AZ後)


•   レプリケーションできない
•   タイムゾーンを変更できない
•   バックアップ時にI/Oフリーズ
•   スケールアップ時にフリーズ
•   セキュリティパッチ適用時にフリーズ
•   ��ストは2倍に
RDSを実運用で使う際に


•   文字コードをUTF-8に
•   バックアップは有効に
•   Multi-AZも有効に
•   レプリケーションは考えない
•   タイムゾーンを考慮する
RDSの利用手順


1. インスタンスの生成
2. セキュリティーグループの生成・設定
3. パラメータグループの生成・設定
4. セキュリティーグループ、パラメータグル
  ープをインスタンスに適用
RDS インスタンスの生成


acmeという名前のインスタンスを生成

$ rds-create-db-instance --db-instance-
  identifer acme --allocated-storage 5
  --db-instance-class db.m1.small
  --engine MySQL5.1 --master-
  username foo --master-user-password
  bar –multi-az true
RDS セキュリティーグループの作成


acme-sgというセキュリティーグループを
 作成

$rds-create-db-security-group acme-sg
 --db-security-group-description
 "security group for acme"
RDS セキュリティーグループの設定


acme-sgに属するRDSのインスタンスが
 EC2のセキュリティーグループfoobarに属
 するインスタンスからアクセスできるよ
 う設定する
$rds-authorize-db-security-group-
 ingress acme-sg --ec2-security-
 group-name foobar --ec2-security-
 group-owner-id 0000-0000-0000
RDS セキュリティーグループの設定2


acme-sgに属するRDSのインスタンスがIP
 xxxx.xxxx.xxxx.xxxxからアクセスできる
 よう設定する

$ rds-authorize-db-security-group-
  ingress acme-sg --cidr-ip
  xxx.xxx.xxx.xxx/32
RDS パラメータグループを作成


acme-pgというパラメータグループを作成

$ rds-create-db-parameter-group
  acme-pg -e MySQL5.1 -d "parameter
  group for acme"
RDS カスタムパラメータの定義

$ rds-modify-db-parameter-group foomoo 
--parameters="name=slow_query_log, value=ON, method=pending-reboot" 
--parameters="name=long_query_time, value=1, method=pending-reboot" 
--parameters="name=min_examined_row_limit, value=100, method=pending-reboot" 
--parameters="name=character_set_client, value=utf8, method=pending-reboot" 
--parameters="name=character_set_connection, value=utf8, method=pending-reboot" 
--parameters="name=character_set_database, value=utf8, method=pending-reboot" 
--parameters="name=character_set_results, value=utf8, method=pending-reboot" 
--parameters="name=character_set_server, value=utf8, method=pending-reboot" 
--parameters="name=collation_connection, value=utf8_general_ci, method=pending-reboot" 
--parameters="name=collation_server, value=utf8_general_ci, method=pending-reboot" 
--parameters="name=connect_timeout, value=2, method=pending-reboot" 
--parameters="name=innodb_fush_log_at_trx_commit, value=2, method=pending-reboot"
RDS 編集したパラメータの確認


編集したパラメータの確認
$ rds-describe-db-parameters acme-pg
  --source user
RDS セキュリティグループ、パラメータグループの適用


acme-sg,acme-pgをacmeに適用

$ rds-modify-db-instance acme -a
  acme-sg -g acme-pg
RDS リブート


設定を適用するためインスタンスを再起動
 する

$ rds-reboot-db-instance amce
RDS インスタンスの確認


できたインスタンスの状態確認
$ rds-describe-db-instances acme
DBINSTANCE acme 2010-06-23T03:18:31.240Z
 db.m1.small mysql5.1 5 foo available
 acme.xxxxx.us-east-1.rds.amazonaws.com 3306
 us-east-1d 1 y
   SECGROUP acme-sg active
   PARAMGRP acme-pg in-sync
RDS 接続確認


設定したmasteruserで接続確認

$   mysql -ufoo -pbar -h acme.xxxxx.us-east-
    1.rds.amazonaws.com
RDS スケールアップ




$ rds-modify-db-instance acme --db-
  instance-class db.m1.large --apply-
  immediately
RDS リストア


$ rds-restore-db-instance-to-point-in-
  time bar -s foo -l

$ rds-restore-db-instance-to-point-in-
  time bar -s foo -r 2010-05-
  04T09:20:00Z
slow_logを消す方法


ストアドプロシージャが定義されている

CALL mysql.rds_rotate_slow_log;
ご静聴ありがとうございました。
人材絶賛募集してます!
    Twitter: horiuchi
Mail: horiuchi@gu3.co.jp

More Related Content

0730 bp study#35発表資料