2014/10/3 DevLove関西 発表資料

1. システムをダイナミックに
運用する
2014-10-03 DevLOVE関西 運用現場の話を聞いてみる
@daiksy

2. 自己紹介
粕谷 大輔 (@daiksy)
フリュー株式会社
ソーシャルゲームの運用・開発
Scala + Playframework2

3. 何に対して”ダイナミック”
に運用するのか？

4. 1日数回のリリース
ボタンサイズ・位置調整
文言の変更
画像差し替え
軽微な不具合修正 etc

5. 1日数回のリリース
商用リリースがゼロの営業日は
基本的に存在しない！

6. 2-4週間おきに大型アップデート
機能追加
販売アイテムの追加
イベント（クリスマス・ハロウィンなど）

7. 2-4週間おきに大型アップデート
アップデート時は原則無停止
DBの定義変更時などは
計画停止する場合もある

8. 高負荷
広告出稿
期間（時間帯）限定イベント
瞬間的に通常の2～10倍のPV
イベントで秒間2万リクエストくらい

9. 1. インフラ

10. 1.インフラ
AWSを利用
EC2, RDS, S3
スケーラビリティを重視

11. 1.インフラ
スケールアウトの自動化
1日1回商用サーバのAMIを作成
このAMIから自動的に指定台数分
サーバーを自動構築
負荷タイミングが比較的読みやすいので、
オートスケールはやっていない

12. 2.ワンタッチデプロイ

13. 1.ワンタッチデプロイ
hikyakuさん
社内IRCに常駐するbot
IRCでhikyakuさんにお願いするとデプロイしてくれる

14. 1.ワンタッチデプロイ
hikyakuさんの仕事
githubからコードを取得してビルド
対象サーバをロードバランサから切り離す
対象サーバに対してデプロイ & アプリケーションの再起動
ロードバランサに再接続
↑ロードバランサに接続されてる全サーバに対してこれを実施

15. 1.ワンタッチデプロイ
きめ細やかなデプロイ
アプリケーションの構成要素すべて
viewのみ
画像やアニメーションのみ
アプリケーションのメンテナンスモードへの切り替え

16. 3.サーバ監視

17. 3.サーバ監視
外部会社に監視を依頼
CPU使用率, ディスク使用率, ロードアベレージ etc
閾値超過でアラート・または電話連絡
CPU使用率80%以上 etc

18. 3.サーバ監視
RDSのディスク容量は過去数回、アラートを検知して増設
(なぜかいずれも長期休暇中……)
AWSなので増設は簡単（数回クリックするだけ）

19. 3.サーバ監視
EC2はまれにインスタンスが勝手に再起動されたりする
デプロイを必要としない軽微な障害は監視会社が
復旧手順を実施してくれる
たまに夜中に電話で起こされるが、
だいたい「復旧済みです」連絡
!
ありがたい

20. 4.障害対応

21. 4.障害対応
リモート接続(VPN)
緊急連絡網
なぜかLINE
夜中に友達からLINEが来ると心臓止まりそうになる
一斉通知できるツールならなんでもいいが、
割りとリアルタイムでのやりとりが求められるので
チャットツールの方がよい（メールはだめ）

22. 5.テスト

23. 5.テスト
今年から
テストチームを
新設

24. 5.テスト
テストチーム
ゲームは人依存の確認項目が多い
シナリオの整合性
プレイ感覚（難易度調整とか遷移の快適さとか）
デザインの美しさ（ボタンサイズは適切か etc）

25. 5.テスト
テストチーム導入以前
開発チームがテストケース作成 & 実施
-> システムテストに近いイメージ？
企画チームが通しチェック
-> シナリオとかデザインとか

26. 5.テスト
テストチーム導入以降
開発チームは単体テストと簡単な動作確認だけ
-> 単体テストはJenkinsでCI
最低限のテストだけでカバレッジは低い
出荷前にテストチームがプレイ
-> 新規開発時約5日間、イベント開発時約2日間程度
-> システム的な観点（仕様を満たせているか）
-> プレイヤー的な観点（シナリオやデザイン、動線など）

27. 5.テスト
品質はどうなったか？
テスト期間中の課題摘出件数は実施以前と以降でほぼ横ばい
テストチーム導入後も
信頼度成長曲線による出荷判定をクリア
リリース後の重篤な不具合は今のところゼロ
システム的な品質は以前と変わらない
プレイヤー的な観点からの課題摘出が増加
-> ゲーム的なクオリティがアップ！

28. まとめ
インフラはAWSでスケーラブル
hikyakuさんで楽々デプロイ
サーバー監視で障害時の手順削減
テストチームは神チーム

29. ご清聴ありがとうございました