3/11 激突！ Aiming x CloverLab のインフラ対決で発表させていただいた資料になります。 サービスインフラエンジニア視点によるプロジェクトの流れとインフラエンジニアの役割を説明しています。 2017/3/11 15:10 アップロード 2017/3/11 16:11 文字が表示されない不具合修正

1. 2017/03/11 激突！ Aiming x CloverLab [インフラ対決]編
サービスが生まれてから死ぬまで
株式会社Aiming 大阪Studio インフラチーム 菅野明洋

2. 自己紹介
✤ 名前
✤ 菅野 明洋(すげの あきひろ)
✤ 所属
✤ 株式会社Aiming
大阪スタジオ インフラチーム
✤ 業務内容
✤ 最近は老朽化したサーバを入れ替えてる
✤ 担当タイトル:
✤ 剣と魔法のログレス
✤ 剣と魔法のログレス いにしえの女神
✤ etc
✤ 最近やっているゲーム
✤ ゼルダ ブレスオブザワイルド

3. 免責事項
✤ 本発表における見解は、
私自身の見解で行っております。
✤ 所属する会社、団体の見解を
反映したものではありませんので、ご了承ください。

4. 今回発表するもの
✤ プロジェクトが始まりリリースする過程の話
✤ お金やスケジュール管理等の話は含まない
✤ 技術よりプロジェクトの流れの話
✤ サービスインフラエンジニア視点での話

5. サービスインフラの役割

6. サービスインフラって何するの？
✤ ユーザに提供するサービスの
インフラ設計・構築・保守・運用・障害対応など

7. 開発 インフラ
開発とインフラの役割分担
保守
監視
構築
設計
開発
テスト
リリース
計画

8. 私の考えるインフラエンジニア
✤ 行動理念
✤ チームが全力を出せる環境の提供・サポート
✤ ユーザが快適に遊べる環境の提供

9. プロジェクトの流れ

10. プロジェクトの流れ
✤ 企画
✤ 設計・開発
✤ α〜β版開発
✤ リリース
✤ クローズ
}今日話すところ

11. 開発前〜初期

12. 企画・性能要件の確認
✤ どんなゲームか？
✤ ゲーム仕様によって負荷や負荷特性が変わる
✤ どれくらいのユーザが来るのか?
✤ 初期流入予想など

13. 納期の確認
✤ 始まる前からリリース日が決まってることもある
✤ クロスメディア展開する場合等
✤ 企業の戦略で出すタイミングが決まってる
✤ とりあえずで決まっていることも
✤ 開発工数や人員計画からリリース日が決まる

14. 予算の確認
✤ 予算が先に決まっていたら合わせる
✤ サーバ費用がいくらになるのか予想し見積もる
✤ 正確性は二の次で計画で出すために算出することも多い

15. 開発初期〜中期

16. 開発環境の構築
✤ 先ず開発するには必要
✤ 開発者がアサインされる前に機材だけ調達することもある

17. 開発の支援
✤ 補助ツールの用意
✤ バージョン管理システム
✤ CIツール
✤ etc

18. 技術検証
✤ 設計を決める前に行う
✤ 新技術で何が出来るのか？出来ないのか？
✤ 新しい遊びを提供できるか？
✤ どれくらいの量の処理が可能か？
✤ 障害に強くなるのか？

19. 監視システム
✤ 性能値を計測の為に初期段階から用意することがある

20. 開発初期〜中期で心がけていること
✤ スケジュールが不透明のなか精度高い見積もりを行う
✤ 設計ミスは多大な損害を与えるので
設計・検証では注意する

21. このフェーズ起因でトラブった事例
✤ ミドルウェアの特性判断ミスにより
予期せぬ不具合が発生し、作り直しが発生した
✤ 検証・検討不足により
想定通りの性能、拡張性、対障害性を発揮しなかった

22. リリース準備

23. ステージング(テスト)環境の準備
✤ 本番環境を低コストで再現する環境

24. 本番環境構築
✤ ゲームシステムを動かす環境
✤ 要件に従って構築する
✤ 大体1〜3ヶ月の期間がかかる
✤ サーバ購入や契約から構築まで

25. 負荷試験
✤ リリース後、多くのユーザを受け入れられるかの検証
✤ 大体1〜2ヶ月かかる
✤ 期間には、システムのチューニングも含む

26. 障害試験
✤ 障害を意図的に起こす
✤ 想定通りにデータが保護されているか、
ダウンタイムが削減されるか等をチェック

27. リリース後の他部署の動きを把握
✤ 広告や関連する放送時間等の時間は全て把握
✤ ユーザが急に来るため、システムが高負荷になる
✤ アニメや動画サイトの生放送など
全てのスケジュールの把握

28. リリース準備で心がけていること
✤ サーバはミスが無いように何度もチェック
✤ リリース後に問題発覚した時の修正は
リリース前に修正するより倍以上のコストがかかる

29. このフェーズ起因でトラブった事例
✤ システムが想定通りに動かずサービスダウン
✤ 流入予測を失敗してサービスダウン
✤ どんなに準備してもトラブルは発生するが
最初が評判に関わることも多いため軽減したい

30. リリース

31. リリース
✤ サービスリリース(サービスイン)

32. リリース直後

33. リリース直後
✤ 障害対応
✤ リリース直後は負荷問題や不具合トラブルが多い
✤ 負荷対策
✤ 増設
✤ チューニング

34. 発展〜安定期

35. 発展〜安定期
✤ ユーザの増加による対応
✤ 増設
✤ イベント時の負荷対応

36. リプレース

37. リプレース
✤ 老朽化によるサーバ交換
✤ 再設計
✤ コスト削減
✤ 負荷試験
✤ 1〜6ヶ月かかるイメージ(システム規模による)

38. 衰退

39. 衰退
✤ ユーザ数が減ってきます
✤ コスト削減
✤ サーバの削減
✤ システム統合

40. プロジェクトの寿命の指標
✤ サーバ費用が売上の5%を下回る案件は安泰
✤ サーバ費用が売上の10%を超える案件はヤバイ
✤ 利益から継続が難しいと判断されることが多いため
※この指標は実体を反映したものではありません
口伝で伝えられたものであるため情報の出処は不明です

41. サービスクローズ

42. サービスクローズ
✤ ユーザ-サーバ間の通信経路の閉鎖
✤ データのアーカイブ
✤ データ
✤ ログ
✤ サーバの撤去・解約

43. サービスクローズの注意点
✤ システムを壊したら情報が取れないため注意
✤ 後から警察からログを要求されることもあるため
漏れはダメゼッタイ

44. 最後に

45. インフラは地盤
✤ インフラエンジニアの仕事は、
他の人が築き上げたプログラムを動かす地盤固め
✤ 地盤が安定していないと動くプログラムも安定しない
✤ 作業に置ける妥協は全てを崩すことがある
✤ とは言え時間とコストのバランスは大事

46. インフラエンジニアは黒子
✤ インフラエンジニアの仕事は目立たない
✤ しかし、掛け替えのない職種です
✤ サーバが無いとオンラインゲームも動きません
✤ 分かる人には分かる重要な職種です
✤ 裏で支えて安定させることは自信につながる
✤ プロジェクトリリースした時の達成感もとても大きい

47. インフラエンジニアの良いところ
✤ 同時に複数案件に関わることが多い職種
✤ いろんな案件の情報・技術を見て学ぶことが出来る

48. つまり、インフラは楽しいよ

49. Aimingでは一緒に働く人を募集中

50. ご静聴ありがとうございました。