もうそこまで迫っている！ Cloud2.0 時代の開発

Amazon Game Tech Night #17
~AWS Pop-Up Loft Osaka~
https://gametechnightosaka.splashthat.com/

Game Server Services
https://gs2.io

Transcript

1. もうそこまで迫っている！ Cloud2.0 時代の開発 Game Server Services株式会社 代表取締役社長 丹羽 一智
2. 自己紹介 代表取締役社長CEO 丹羽 一智 新卒で株式会社セガに入社、携帯電話向けのゲームおよびサーバ開発業 務に従事。約3年勤める 任天堂株式会社に入社、ニンテンドー3DSのOS開発や、ゲームサーバの 開発・運用。Nintendo Switchのサーバシステム設計などに従事。約7年 間勤める 2016年9月 Game Server Services 株式会社を設立
3. Game Server Services(GS2) ゲームに必要なサーバシステムをクラウドとして提供 サーバ開発・運用をせずに 本格的なスマホゲームを開発・運営
4. Cloud2.0
5. Cloud 2.0: Code is no longer King — Serverless has dethroned it https://medium.com/@PaulDJohnston/cloud-2-0-code-is-no-longer- king-serverless-has-dethroned-it-c6dc955db9d5
6. Cloud 1.0 Amazon EC2 Amazon RDS Amazon ElastiCache
7. Cloud 1.0 AWS Cloud SDK
8. Cloud 2.0 AWS Cloud SDK Simple Storage Service
9. フルマネージドサービス Simple Storage Service Amazon Kinesis Data Firehose Amazon Simple Notification Service Amazon Simple Queue Service AWS Lambda Amazon DynamoDB Amazon API Gateway Simple Storage Service AWS AppSync Amazon Athena AWS Fargate Compute Application Integration Database Messaging Logging
10. BaaS(バックエンド・アズ・ア・サービス) Authentication Payment Gaming
11. ロックイン
12. ロックイン＝悪？ フルマネージドサービスやBaaSはOSSではない || ロックインされる || だめなこと（なんだっけ？）
13. コントローラブル＝対処する責任がある MySQL は ロックインされない しかし多くの責任を負うことになる たとえば、マスターサーバが落ちたとき… • 本当に何かあったときに昇格できる？ • Master / Slave のデータは絶対そろっている？ • 障害復旧後、新しい Slave を作らないといけないけど、誰がいつやる？ この責任ってアプリケーションの価値を高めてるんだっけ？
14. 障害は起こるときは起こる！ 自分たちの責任で運用している仮想サーバのプロセスが突然シャットダウン！ 偉い人「どうしてこうなったんだ！！再発防止はどうするんだ！」 エンジニア「検討します…（でかい仕事が割り込んできたぞ…）」 フルマネージドサービス で障害が発生！ SNS「ほぎゃあああああああ」 偉い人「なんか凄いことになってるな」 エンジニア「AWSに状況を聞きます」 AWS「すいません。二度と同じことが起こらないように対策します」 エンジニア「頼んだで」
15. Cloud 2.0 脳にするために
16. イベント駆動・マイクロサービス設計
17. イベント駆動設計 フルマネージドサービス ＝ コードに手を入れられない フルマネージドサービス の イベント に 呼応する処理を記述してアプリケーションを実装 || 新しいプログラミングパラダイム
18. 例 クエスト ミッション プッシュ通知 クエストクリアしたで クエストクリア回数を＋１ クエストクリア回数が10を超えていれば プッシュ通知を送信 ミッション達成おめでとう。報酬を取りに来てな OK クエストをクリアしたとき： ミッションのカウンターが変化したとき：
19. クエスト イベント駆動設計はマイクロサービスの延長 ミッション プッシュ通知 クエストクリアしたで クエストクリア回数を＋１ クエストクリア回数が10を超えて いればプッシュ通知を送信 ミッション達成おめでとう。報酬を取りに来てな OK クエストをクリアしたとき： ミッションのカウンターが変化したとき： キューを挟む キューを挟む 非同期レスポンス
20. クエスト マイクロサービス化で障害耐性が高くなる ミッション プッシュ通知 クエストクリアしたで クエストクリア回数を＋１ クエストクリア回数が10を超えて いればプッシュ通知を送信 ミッション達成おめでとう。報酬を取りに来てな OK クエストをクリアしたとき： ミッションのカウンターが変化したとき： キューに溜まる キューを挟む ミッション復旧後に非同期レスポンス とりあえず返る ミッションが死亡
21. NoSQLを使いこなす
22. NoSQL を使いこなす RDBMS には絶対に性能の限界がある 一部の NoSQL は正しい用法において性能の上限がない Aurora DocumentDB Amazon DynamoDB Redshift Neptune RDS ElastiCache 性能上限アリ 性能上限ナシ
23. DynamoDB の分散方法 アイテム （レコード） キャラクターID 経験値 覚えている技 AWS管理のサーバクラスタ 書き込み パーティション パーティション パーティション パーティション パーティション パーティション
24. DynamoDB の保存容量 AWS管理のサーバクラスタ 容量やばい… なんてことにはならない
25. DynamoDB の保存容量 AWS管理のサーバクラスタ 勝手にパーティションが 増えて データはオンデマンドで 再配置される
26. DynamoDB の分散方法 アイテム （レコード） キャラクターID 経験値 覚えている技 AWS管理のサーバクラスタ 書き込み どのパーティションに保存しよう？ パーティション パーティション パーティション パーティション パーティション パーティション
27. DynamoDB の分散方法 アイテム （レコード） キャラクターID 経験値 覚えている技 AWS管理のサーバクラスタ パーティションキー （主キー） パーティションキーから パーティションを決定
28. DynamoDB のスケールしない使い方(R) AWS管理のサーバクラスタ 超人気データ 一つのデータに 読み込みが 集中するのは苦手
29. DynamoDB のスケールしない使い方(R) AWS管理のサーバクラスタ DynamoDB Stream で更新 S3にとっては ちょろい読み込み データの配信方法を 最適化
30. DynamoDB のスケールしない使い方(W) AWS管理のサーバクラスタ 超人気データ 一つのデータに 書き込みが 集中するのも苦手
31. DynamoDB のスケールしない使い方(W) AWS管理のサーバクラスタ 超人気データ SQS/Kinesis を挟んで バッファリングしよう
32. NoSQL は怖くない ・データのIOを1つのデータに集中させない ・検索させたい場合は、DynamoDB Stream を使って 検索用のデータベースやインデックスを作成する この2点を意識して使うだけで運用不要のデータベースを使える
33. ステートレスに設計する
34. ステートレス設計 サーバに状態を持つと耐障害性が下がる 運用不要にするにはサーバで状態を持ってはいけない 8月の障害で下記現象が発生したが、サーバに状態を持たなければ両方避けられた ALB/ELB でスティッキーセッションを使っていた時に 正しくフェイルオーバーされなかった EBSのデータが消失した
35. ステートの逃がし方 AWS Lambda Amazon API Gateway Amazon DynamoDB 状態をDBに逃がす
36. ステートの逃がし方 AWS Lambda Amazon API Gateway Amazon DynamoDB 課題：安くはない
37. ステートの逃がし方 AWS Lambda Amazon API Gateway AWS Step Functions State Step Functions で状態を管理
38. ステートの逃がし方 AWS Lambda Amazon API Gateway AWS Step Functions State 課題：安くはない
39. ステートの逃がし方 AWS Lambda Amazon API Gateway 状態を応答する AWS Lambda 状態をつけて再開 XXX以降のデータくれ - ZZZ - YYY - XXX
40. ステートの逃がし方 AWS Lambda Amazon API Gateway 状態を応答する AWS Lambda 状態をつけて再開 課題：改ざん・ロールバックできる BBB以降のデータも実は あったりするだろうか？
41. ステートレス設計 改ざんに対しては署名や暗号化によって対処できるが ロールバックは避けることができない ロールバックが許容できるかでステートをどこに持つかを考えるのがよい
42. Cloud 2.0 = イケてる設計で運用をなくす
43. 覚えること多くて大変？ だったら、BaaS を使おう！ GS2 はこれらの設計を忠実に実行しています https://gs2.io