システムをダイナミックに運用する from DevLove関西
- 1. システムをダイナミックに 運用する 2014-10-03 DevLOVE関西 運用現場の話を聞いてみる @daiksy
- 2. 自己紹介 粕谷 大輔 (@daiksy) フリュー株式会社 ソーシャルゲームの運用?開発 Scala + Playframework2
- 4. 1日数回のリリース ボタンサイズ?位置調整 文言の変更 画像差し替え 軽微な不具合修正 etc
- 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 滨搁颁で丑颈办测补办耻さんにお愿いするとデプロイしてくれる
- 14. 1.ワンタッチデプロイ hikyakuさんの仕事 githubからコードを取得してビルド 対象サーバをロードバランサから切り離す 対象サーバに対してデプロイ & アプリケーションの再起動 ロードバランサに再接続 ↑ロードバランサに接続されてる全サーバに対してこれを実施
- 15. 1.ワンタッチデプロイ きめ細やかなデプロイ アプリケーションの構成要素すべて viewのみ 画像やアニメーションのみ アプリケーションのメンテナンスモードへの切り替え
- 16. 3.サーバ监视
- 17. 3.サーバ监视 外部会社に監視を依頼 CPU使用率, ディスク使用率, ロードアベレージ etc 閾値超過でアラート?または電話連絡 CPU使用率80%以上 etc
- 18. 3.サーバ监视 RDSのディスク容量は過去数回、アラートを検知して増設 (なぜかいずれも長期休暇中……) 础奥厂なので増设は简単（数回クリックするだけ）
- 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. ご清聴ありがとうございました