Amazon Game Tech Night #17 ~AWS Pop-Up Loft Osaka~ https://gametechnightosaka.splashthat.com/
Game Server Services https://gs2.io
もうそこまで迫っている！ Cloud2.0 時代の開発Game Server Services株式会社代表取締役社長 丹羽 一智
View Slide
自己紹介代表取締役社長CEO 丹羽 一智新卒で株式会社セガに入社、携帯電話向けのゲームおよびサーバ開発業務に従事。約3年勤める任天堂株式会社に入社、ニンテンドー3DSのOS開発や、ゲームサーバの開発・運用。Nintendo Switchのサーバシステム設計などに従事。約7年間勤める2016年9月 Game Server Services 株式会社を設立
Game Server Services(GS2)ゲームに必要なサーバシステムをクラウドとして提供サーバ開発・運用をせずに本格的なスマホゲームを開発・運営
Cloud2.0
Cloud 2.0: Code is no longer King— Serverless has dethroned ithttps://medium.com/@PaulDJohnston/cloud-2-0-code-is-no-longer-king-serverless-has-dethroned-it-c6dc955db9d5
Cloud 1.0Amazon EC2 Amazon RDS Amazon ElastiCache
Cloud 1.0AWS CloudSDK
Cloud 2.0AWS CloudSDKSimple Storage Service
フルマネージドサービスSimple Storage ServiceAmazon KinesisData FirehoseAmazon SimpleNotification ServiceAmazon Simple QueueServiceAWS Lambda Amazon DynamoDBAmazon API GatewaySimple Storage ServiceAWS AppSyncAmazon AthenaAWS FargateComputeApplicationIntegration Database Messaging Logging
BaaS(バックエンド・アズ・ア・サービス)Authentication Payment Gaming
ロックイン
ロックイン＝悪？フルマネージドサービスやBaaSはOSSではない||ロックインされる||だめなこと（なんだっけ？）
コントローラブル＝対処する責任があるMySQL は ロックインされないしかし多くの責任を負うことになるたとえば、マスターサーバが落ちたとき…• 本当に何かあったときに昇格できる？• Master / Slave のデータは絶対そろっている？• 障害復旧後、新しい Slave を作らないといけないけど、誰がいつやる？この責任ってアプリケーションの価値を高めてるんだっけ？
障害は起こるときは起こる！自分たちの責任で運用している仮想サーバのプロセスが突然シャットダウン！偉い人「どうしてこうなったんだ！！再発防止はどうするんだ！」エンジニア「検討します…（でかい仕事が割り込んできたぞ…）」フルマネージドサービス で障害が発生！SNS「ほぎゃあああああああ」偉い人「なんか凄いことになってるな」エンジニア「AWSに状況を聞きます」AWS「すいません。二度と同じことが起こらないように対策します」エンジニア「頼んだで」
Cloud 2.0 脳にするために
イベント駆動・マイクロサービス設計
イベント駆動設計フルマネージドサービス ＝ コードに手を入れられないフルマネージドサービス の イベント に呼応する処理を記述してアプリケーションを実装||新しいプログラミングパラダイム
例クエスト ミッション プッシュ通知クエストクリアしたでクエストクリア回数を＋１クエストクリア回数が10を超えていればプッシュ通知を送信ミッション達成おめでとう。報酬を取りに来てなOKクエストをクリアしたとき：ミッションのカウンターが変化したとき：
クエストイベント駆動設計はマイクロサービスの延長ミッションプッシュ通知クエストクリアしたでクエストクリア回数を＋１クエストクリア回数が10を超えていればプッシュ通知を送信ミッション達成おめでとう。報酬を取りに来てなOKクエストをクリアしたとき：ミッションのカウンターが変化したとき：キューを挟むキューを挟む非同期レスポンス
クエストマイクロサービス化で障害耐性が高くなるミッションプッシュ通知クエストクリアしたでクエストクリア回数を＋１クエストクリア回数が10を超えていればプッシュ通知を送信ミッション達成おめでとう。報酬を取りに来てなOKクエストをクリアしたとき：ミッションのカウンターが変化したとき：キューに溜まるキューを挟むミッション復旧後に非同期レスポンスとりあえず返るミッションが死亡
NoSQLを使いこなす
NoSQL を使いこなすRDBMS には絶対に性能の限界がある一部の NoSQL は正しい用法において性能の上限がないAuroraDocumentDBAmazon DynamoDBRedshift NeptuneRDS ElastiCache性能上限アリ 性能上限ナシ
DynamoDB の分散方法アイテム（レコード）キャラクターID経験値覚えている技AWS管理のサーバクラスタ書き込みパーティション パーティション パーティションパーティション パーティション パーティション
DynamoDB の保存容量AWS管理のサーバクラスタ 容量やばい…なんてことにはならない
DynamoDB の保存容量AWS管理のサーバクラスタ勝手にパーティションが増えてデータはオンデマンドで再配置される
DynamoDB の分散方法アイテム（レコード）キャラクターID経験値覚えている技AWS管理のサーバクラスタ書き込みどのパーティションに保存しよう？パーティション パーティション パーティションパーティション パーティション パーティション
DynamoDB の分散方法アイテム（レコード）キャラクターID経験値覚えている技AWS管理のサーバクラスタパーティションキー（主キー）パーティションキーからパーティションを決定
DynamoDB のスケールしない使い方(R)AWS管理のサーバクラスタ超人気データ一つのデータに読み込みが集中するのは苦手
DynamoDB のスケールしない使い方(R)AWS管理のサーバクラスタDynamoDBStream で更新S3にとってはちょろい読み込みデータの配信方法を最適化
DynamoDB のスケールしない使い方(W)AWS管理のサーバクラスタ超人気データ一つのデータに書き込みが集中するのも苦手
DynamoDB のスケールしない使い方(W)AWS管理のサーバクラスタ超人気データSQS/Kinesis を挟んでバッファリングしよう
NoSQL は怖くない・データのIOを1つのデータに集中させない・検索させたい場合は、DynamoDB Stream を使って検索用のデータベースやインデックスを作成するこの2点を意識して使うだけで運用不要のデータベースを使える
ステートレスに設計する
ステートレス設計サーバに状態を持つと耐障害性が下がる運用不要にするにはサーバで状態を持ってはいけない8月の障害で下記現象が発生したが、サーバに状態を持たなければ両方避けられたALB/ELB でスティッキーセッションを使っていた時に正しくフェイルオーバーされなかったEBSのデータが消失した
ステートの逃がし方AWS LambdaAmazon API Gateway Amazon DynamoDB状態をDBに逃がす
ステートの逃がし方AWS LambdaAmazon API Gateway Amazon DynamoDB課題：安くはない
ステートの逃がし方AWS LambdaAmazon API GatewayAWS Step FunctionsStateStep Functions で状態を管理
ステートの逃がし方AWS LambdaAmazon API GatewayAWS Step FunctionsState課題：安くはない
ステートの逃がし方AWS LambdaAmazon API Gateway状態を応答するAWS Lambda状態をつけて再開XXX以降のデータくれ- ZZZ- YYY- XXX
ステートの逃がし方AWS LambdaAmazon API Gateway状態を応答するAWS Lambda状態をつけて再開課題：改ざん・ロールバックできるBBB以降のデータも実はあったりするだろうか？
ステートレス設計改ざんに対しては署名や暗号化によって対処できるがロールバックは避けることができないロールバックが許容できるかでステートをどこに持つかを考えるのがよい
Cloud 2.0 = イケてる設計で運用をなくす
覚えること多くて大変？だったら、BaaS を使おう！GS2 はこれらの設計を忠実に実行していますhttps://gs2.io
kazutomo
nenonaninu
drumath2237
koic
kako351
miyakemito
nttcom
colopl
yusukeshimizu
daina0321
6onoda
katzueno
eliasnogueira
morganepeng
lara
jlugia
davidbonilla
hursman
eileencodes
cherdarchuk
maltzj
deanohume
denniskardys
jmmastey
lauravandoore