『 イドラ ファンタシースターサーガ 』を支える GCP | Google Cloud INSIDE Games & Apps
•
3 likes•5,459 views
2019-04-18 thu. 第 7 回 Google Cloud INSIDE Games & Apps 株式会社セガゲームス安倉 剛司氏 と森田 公一氏の登壇スライドです。
Recommended
More Related Content
What's hot
What's hot (20)
Similar to 『 イドラ ファンタシースターサーガ 』を支える GCP | Google Cloud INSIDE Games & Apps
Similar to 『 イドラ ファンタシースターサーガ 』を支える GCP | Google Cloud INSIDE Games & Apps (20)
More from Google Cloud Platform - Japan
More from Google Cloud Platform - Japan (20)
Recently uploaded
Recently uploaded (15)
『 イドラ ファンタシースターサーガ 』を支える GCP | Google Cloud INSIDE Games & Apps
- 2. 自己紹介 安倉 剛司 株式会社セガゲームス 第３事業部 プログラムセクション リードプログラマー 2000年セガ・エンタープライゼス（現セガゲームス）に入社。 コンシューマタイトルでUIや3Dグラフィックを担当後、 サーバエンジニアに転じて運営タイトルの開発と運営を担当。 現在は『イドラ ファンタシースターサーガ』のテクニカルディレクターとして開発 と運営に取り組んでいる。
- 3. 自己紹介 森田 公一 株式会社セガゲームス 第３事業部 テクニカルサポートセクション リードプログラマー 2012年セガ（現セガゲームス）に入社。 主にサーバサイドエンジニアとして運営タイトルの開発を担当。 現在は各種クラウドサービスの評価／検証、既存タイトルのコンテナ化、 Kubernetes を利用した共通基盤の開発に取り組んでいる。
- 4. 本日のアジェンダ • 『イドラ ファンタシースターサーガ』の事例紹介 ◦ アプリ紹介 ◦ サーバ構成 ◦ GAEとDatastoreの活用事例 ◦ Firebase Realtime Databaseのチャット事例 ◦ Stackdriver活用事例 • Kubernetes Engine 活用事例紹介 ◦ 共通基盤サービスの事例 ◦ 『イドラ』開発環境の運用効率化の事例 ◦ Kubernetes Engine 活用事例まとめ
- 7. アプリ紹介 7
- 9. Common Point Servers Raid API Servers General API Servers サーバ構成 Game Client Dev/Ops Team Cloud Load Balancing GM Tool Server Compute Engine Operation Server Compute Engine DB Server Common MySQL Compute Engine Master/Slave Instances HTTPS HTTPS SSH DB Server Shard 0/1 MySQL Compute Engine Master/Slave Instances Memcached Server Compute Engine 4 Instances WebGW Server Compute Engine API Server Compute Engine Multiple Instances Batch Server Compute Engine Service Server Compute Engine Multiple Instances DB Server Common MySQL Compute Engine Master/Slave Instances DB Server Shard 0/1 MySQL Compute Engine Master/Slave Instances API Server Compute Engine Multiple Instances Chat Server Firebase Realtime Database Redis Server Compute Engine 3 Instances Cloud Datastore App Engine SEGA ID Service PSO2 Server Official Web Server Common Infrastructure Services Kubernetes Engine Multiple InstancesCloud Storage
- 10. 『イドラ ファンタシースターサーガ』 の事例紹介 GAE と Datastore の活用事例
- 11. GAEとDatastoreの活用事例 • GAE導入理由 • 『イドラ』と『PSO2』で共有する『イドラポイント』サーバが必要 • 『イドラポイント』サーバを独立したサーバにしたい • 『イドラ』がメンテナンス中でも『PSO2』でポイントを使いたい • 『PSO2』がメンテナンス中でも『イドラ』でポイントを貯めたい • メンテナンスフリーで管理コストを減らしたい • 構成 • GolangでREST APIを構築 • Cloud Datastoreでポイントデータ管理 • GAEの運用実績 • 2018年11月27日サービス開始から約5ヶ月経過 • 障害は一度もなく稼働を続けている
- 12. GAEとDatastoreの活用事例 •共通ポイント獲得状況の解析事例 ゲーム側GCPプロジェクト 解析側GCPプロジェクト DB Server Compute Engine KPI Data BigQuery Cloud StorageCloud Storage Cloud Datastore
- 13. 『イドラ ファンタシースターサーガ』 の事例紹介 Firebase Realtime Database のチャット事例
- 14. Firebase Realtime Databaseのチャット事例 •Realtime Database導入理由 • 開発当初は予定していなかった • サーバの工数が確保できなかった • Stackdriverと連携ができる
- 15. Firebase GCP Firebase Realtime Databaseのチャット事例 Game Client Dev/Ops Team GM Tool Server Compute Engine API Server Compute Engine Multiple Instances Chat Server Firebase Realtime Database Stackdriver Logging KPI Data BigQuery Firebase Functions
- 16. Firebase Realtime Databaseのチャット事例 •Realtime Databaseのチャット用データ構成 "chats" : { // ルーム情報 "rooms" : { }, // ユーザ情報 "users" : { }, // メッセージ情報 "messages" : { }, }
- 17. Firebase Realtime Databaseのチャット事例 •ルーム情報のデータ構成 "chats" : { // ルーム情報 "rooms" : { "RoomID1", "RoomID2", "RoomID3", "RoomID4", ・・・ },
- 18. Firebase Realtime Databaseのチャット事例 •ユーザ情報のデータ構成 "chats" : { // ユーザ情報 "users" : { "UUID1" : { userName: "AAAAAAAA" userNo:1 rooms : { "RoomID1", "RoomID2", }, }, ・・・ },
- 19. Firebase Realtime Databaseのチャット事例 •メッセージ情報のデータ構成 "chats" : { // メッセージ情報 "messages" : { "RoomID" : { 1: { message:”チャットメッセージ” その他チャット情報 }, ・・・ }, ・・・ },
- 20. Firebase Realtime Databaseのチャット事例 •ルールについて • クライアントからのアクセス制限のためのルール • ゲームサーバーからは管理者権限でアクセスできる { "rules": { ".read": false, ".write": false, // ルーム情報 "rooms": {} // ユーザ情報 "users": {} // メッセージ情報 "messages": {}
- 21. Firebase Realtime Databaseのチャット事例 •ルーム情報のルール例 // ルーム情報 "rooms": { // 読み込みは誰でもOK ".read": "auth != null", // 追加できるのは管理者権限のみ（サーバから追加する） ".write": "false",
- 22. Firebase Realtime Databaseのチャット事例 •ユーザ情報のルール例 // ユーザ情報 "users": { ".read": false, ".write": false, // ユーザ毎のルール "$uid": { // ユーザ情報の読み込みは自分自身のみ ".read": "auth.uid == $uid", ".write": "false", // userNoとuserNameを必須とする ".validate": "newData.hasChildren(['userNo', 'userName'])",
- 23. Firebase Realtime Databaseのチャット事例 •メッセージ情報のルール例 // メッセージ情報 "messages": { ".read": false, ".write": false, // ルーム毎のアクセシビリティ "$roomid": { // chats/rooms/$roomidにルーム情報がありかつ、 // chats/users/auth.uid/rooms/$roomidにルーム情報がある ". read": "(root.child('chats').child('rooms').child($roomid).exists() && root.child('chats').child('users').child(auth.uid).child('rooms').child($roomid) .exists())", ". write":
- 25. Stackdriver活用事例 •Stackdriver Monitoring • Realtime Databaseも含めて監視 •Stackdriver Logging • サーバのすべてのログをfluentdで転送してLoggingで閲覧 • ApacheのアクセスログやOSのMessageログなど
- 31. 共通基盤サービスの要件 1. 特定の言語に依存しない 2. 特定のクラウドベンダーに依存しない 3. タイトルごとに独立している 4. メンテナンスコストが低い 5. 可用性／スケーラビリティが高い ⇒ ライブラリではなく、独立したサービスとして実装（gRPC+Protocol Buffers）
- 32. 共通基盤サービスの要件 1. 特定の言語に依存しない 2. 特定のクラウドベンダーに依存しない 3. タイトルごとに独立している 4. メンテナンスコストが低い 5. 可用性／スケーラビリティが高い ⇒ ライブラリではなく、独立したサービスとして実装（gRPC+Protocol Buffers） ⇒ コンテナ＋Kubernetes でポータビリティを確保 ⇒ 各タイトルのクラウド環境内に個別にシステムを構築 ⇒ Infrastructure as Code & Immutable Infrastructure ⇒ Kubernetes の自己修復／オートスケール機能を活用 ⇒ マイクロサービスアーキテクチャを採用 Kubernetes で すべて解決！
- 33. 共通基盤サービス構成 SEGA HTTPS GitLab Cluster Push image CIS Dev Cluster Common Infrastructure Service(Develop) Build/Push image CIS Production Cluster Default Pool SEGA ID ServiceFixed Nodes Kubernetes Engine 2 Nodes Autoscaling Pool Autoscale Nodes Kubernetes Engine Autoscaling CIS Pods kube-system pods Authentication Firebase Cloud MessagingMessaging Virtual Currency Git push/ Run manual jobs helm tiller Authentication CIS Services(dev) Kubernetes Engine Pull image helm install/ upgrade CIS Images Container Registry helm install/upgrade Game Infrastructure KPI Logs/ DB Snapshots Game Servers Compute Engine Management Tool Compute Engine gRPC Internal Load Balancing Pull image IDOLA Production DB Server MySQL Compute Engine Kubernetes Engine Push notification Apple App Store Validate Receipts Logging Stackdriver Logging
- 34. Game Infrastructure Instance Group #F9FBE7 共通ログ基盤サービス構成 CIS Production Cluster Log Aggregator Pool Aggregator Nodes Kubernetes Engine Autoscaling KPI Logs/ DB SnapshotsGame Servers Compute Engine Internal Load Balancing IDOLA Production Syslog Apache Logs App Logs Stackdriver Logging tail Instance Group #F9FBE7 KPI Logs/ DB Snapshots Syslog Apache Logs App Logs tail Management Tool Compute Engine Forwarder Fluentd td-agent Forwarder Fluentd td-agent forward Log AggregationLog Aggregation Re-tagging + Filtering Fluentd td-agent + fluent-plugin-google-cloud SEGA Web Console HTTPS GitLab Cluster Git push/ Run deploy jobs Kubernetes Enginehelm upgrade fluent.conf fluent.conf Edit
- 35. Kubernetes Engine 活用事例紹介 『イドラ』 開発環境の運用効率化の事例
- 36. 以前の開発環境 Game Infrastructure Instance Group #F9FBE7 KPI Logs/ DB SnapshotsGCP 1 Compute Engine API Server Service Server Management Tool Redis Server Memcached Server MySQL Instance Group #F9FBE7 KPI Logs/ DB SnapshotsGCP 2 Compute Engine API Server Service Server Management Tool Redis Server Memcached Server MySQL Static external IP Static external IP SEGA Dev/Check Team Instance Group #F9FBE7 KPI Logs/ DB SnapshotsGCP 3 Compute Engine API Server Service Server Management Tool Instance Group #F9FBE7 KPI Logs/ DB SnapshotsGCP N Compute Engine API Server Service Server Management Tool IDOLA Development … … Common Infrastructure Services Kubernetes Engine Multiple Instances SEGA Repository Server Admin Run deploy jobs Compute Engine Clone Create/Delete instance
- 37. 以前の開発環境の主な問題点 • 1 環境に 1 GCE インスタンスが必要 • 新しい環境の追加は気軽にはできないため、あらかじめ十分な数の環境を用意する必要がある • 各環境は複数人で共用かつ別用途で使い回しなため、何かしら変更する場合は相談と全体への周知が必 須 • 環境名は「”GCP”＋連番」なため、用途やアプリバージョンなどは別途管理表が必要
- 38. 改善後の開発環境 SEGA Run build/deploy jobs SEGA Dev/Check Team IDOLA DevelopmentGame Cluster Nodes Kubernetes Engine Autoscaling kube-system podsNginx Ingress Controller Nginx Ingress Controller Virtual Host Name helm tiller Namespace “latest” Common Infrastructure Services Game Servers Namespace “v10101-rev12345-newevent” Common Infrastructure Services Game Servers … CIS Images Container Registry Pull image GitLab Cluster Kubernetes Engine Push image helm install/upgrade Repository Dev/Check Team Clone
- 39. 新開発環境の改善点 • 1 環境に 1 GCE インスタンスが必要 ⇒コンテナ化したことで 1 インスタンス（ノード）に複数の環境を乗せられるように • 新しい環境の追加は気軽にはできないため、あらかじめ十分な数の環境を用意する必要がある ⇒オートスケールを活用し、すべて自動化することで、簡単に環境を追加／削除可能に • 各環境は複数人で共用かつ別用途で使い回しなため、何かしら変更する場合は相談と全体への周知が必 須 ⇒用途ごとに専用環境を作成、使い捨てに ⇒関係者だけが利用するため、事前の相談と周知が不要に • 環境名は「”GCP”＋連番」なため、用途やアプリバージョンなどは別途管理表が必要 ⇒環境名に命名規則を導入。名前から用途やバージョンを推測できるように
- 40. 改善の結果 • インスタンス料金が約１/２に！ • 完全自動化により、インフラ管理コストがほぼ 0 に！ • 誰でも簡単に自分専用の環境を作成できるようになり、チェック作業効率が UP！
- 42. Kubernetes のメリット • コンテナ＋Kubernetes なら「Infrastructure as Code」、 「Immutable Infrastructure」を簡単に実現できる ⇒ 結果として、自動化やインフラの管理に掛かるコストを大幅に削減できた • コンテナ、Kubernetes はマイクロサービス アーキテクチャと相性が良い ⇒ 多数のサービスとそのインフラの管理は Kubernetes がなければ やっていられない ⇒ 不要なサービスを省いたり、必要最小限でスケールアウトできるので コストメリットも大きい • Kubernetes 環境さえあればどこにでもポーティングできる
- 43. Kubernetes のデメリット • やはり学習コストは高い ◦ Kubernetes だけでなく Docker や Helm など覚えることが多い ◦ 特に Kubernetes はコンテナだけでなく抽象化されてたインフラリソースなどもまとめて 管理するため、アプリ開発者にはやや負担が大きい ⇒ 専門チームを組織しナレッジを蓄積する ⇒ アプリ開発者の責任範囲をコンテナイメージ作成までとし、その先は専門チームに 任せられるのが理想
- 44. 最後に