Amazon Game Tech Night 8 に参加してきました #AmazonGametech

はじめに

おはようございます､加藤です｡Amazon Game Tech Night #8に参加してきたので､ブログ化します｡

オンラインゲーム開発におけるクラウド・デザイン・パターン

畑史彦 Solutions Architect, Amazon Web Services Japan

ゲームならではのAWSのアーキテクチャを紹介するセッションでした｡

Case1 定期的なバッチ処理

運用負荷をなく楽に実装したい､コスト最適化したい

• EC2 + Crontab
  • 古典的なバッチ
  • オンプレと同様で馴染みがある
  • インスタンスを常に稼働させておく必要がある
• Lambda + Scheduled Events
  • CloudWatch Eventから任意のタイミングでLambdaを実行する
  • Cron式, Rate式を使用してタイミングを制御できる
  • コスト効果とサーバー管理から開放される
  • 注意
  • 15分の実行タイムアウト
  • 使えるリソースの制限
• ECS(EC2) + Scheduled Events
  • CloudWatch Eventから任意のタイミングでECSを実行する(立ち上げる)
  • 1回限りのバッチ用として使い捨てでコンテナを使用する
  • Spot Instanceを利用することで更にコスト最適化が期待できる
• ECS(Fargate) + Scheduled Events
  • EC2でのECSと比べてコストが割高になる可能性があるがサーバー管理から開放される

Case2 Web API サーバーをスケーラブルに構築したい

• EC2 + ELB
  • ELBでロードバランス
  • Auto Scalingを利用してインスタンス数の制御を自動化
  • Auto Scaling スケールプラン
  • スケジュールベース
    • 時間を決めて自動で増減
  • 手動スケーリング
    • あらかじめ予約しておいた動作に従ってスケーリング(宣伝を打つなど予測される場合に向いている)
  • 動的スケーリング
    • 予期せぬ負荷に対応する
    • 平均CPU使用率などを基準にスケールする
• Lambda + API Gateway
  • サーバーレス構成
  • リクエストをトリガーにLambdaを起動する
  • サーバー管理が不要
  • 利用料金を低減できる可能性がある
  • Cognito によるAPIアクセス制御
  • 注意
  • カスタマイズ性は低い
  • 新しいアーキテクチャなので開発チームに運用ノウハウがない可能性も...
• ECS(EC2) + ELB
  • コンテナ構成
  • クラスタ/コンテナそれぞれにAuto Scalingで管理可能
  • Spot Instanceで更にコストを削減できる
• ECS(Fargate) + ELB
  • サーバー管理が不要
  • EC2に比べて割高になる可能性がある
• GameSparks
  • Game BaaS(Backend as a Service)
  • オンラインゲーム開発に必要な一通りの機能をサービスとして提供
  • SDKによる容易な導入
  • サーバーの管理やスケーリングの管理も不要
  • アクティブユーザー数に応じた従量課金

Case3 ランキング(リーダーボード)をリアルタイムで反映して表示したい

• Redis SortedSet
  • ゲーム業界では知名度のある方法(知見が多い)
  • Amazon ElastiCache(Redis)を使用する
  • 注意
  • オンメモリで動くの永続性が必要ならバックアップが必要
  • ランキングロジックが複雑な場合は独自で作り込みが必要
• DynamoDB
  • AWSが提供するNoSQL
  • あらかじめスループットを予約できる
  • 注意
  • Redisのようなランキングに最適化されたAPIはない
  • レイテンシは1桁ミリ秒これ以上を求めるならDAX
• GameSparks Leaderboards
  • GameSparksがランキング機能を提供している
  • 他は自分で実装してGameSparksのランキング部分だけ使用することも可能
  • ランキングロジックの柔軟なカスタマイズが可能

Case4 ユーザーが投稿するコンテンツに不適切な内容が含まれていないか自動で検知したい

• Amazon Comprehend(Abusive Intent)
  • 文章の感情を分析
  • キーフレーズ検出
  • 攻撃的な内容などの検出が可能

Case5 漠然とした不安への対処(AWS最適な方針を学びたい)

• AWS Whitepaper
  • セキュリティのベストプラクティス
  • クラウドアーキテクチャのベストプラクティス
  • マイクロサービス
  • スケーラブルなゲームパターン
  • マルチプレイヤーゲームサーバーの最適化方法
• AWS Well Architected Framework
  • 大局的な考え方やベストプラクティス
  • チェックリストで構成をチェックできる
• BlackBelt Online Seminar
  • AWSJのメンバーがAWSに関する内容を紹介するオンラインセミナー

質疑応答

• Q: バッチ間の依存がある場合のAWSのベストプラクティスは?
• A: 例えば以下のサービスが有効
  • Step Functions
  • Code Pipeline
  • Simple Work Flow

AWS上でのオンラインゲーム リリースガイド 〜本番リリースを安全に乗り切るためにやっておきたいアクションまとめ〜

吉田 英世 Solutions Architect, Amazon Web Services Japan(@aquaviter)

リリースまのでステップ

どのタイミングでどういったアクションを行えば良いのか

設計フェーズ

• 新サービスと新機能のキャッチアップ
  • 設計段階でキャッチアップすることで開発期間の短縮とコスト圧縮が期待できる
  • SQSのFIFO
  • NAT→VPCのエンドポイント
  • 設計段階で知っている/いないの差は大きい
• ソリューションアーキテクトによるレビュー
  • ゲームの仕様からアプリ/システムの要件が明確になっている状態でレビュー
  • インフラだけでなくApp, DBもサポート
  • ベストエフォート対応
  • レビューを受けられる場所
  • 自社(担当SA)
  • AWS Loft Tokyo
  • AWSを個別相談会
• AWS Well-Architected Framework
  • クラウドにおけるシステム設計･運用のベストプラクティス
  • 質問と回答形式でアーキテクチャをチェックできる
• ゲームにおけるデータストアの選択
  • 選択肢
  • ElastiCache
    • セッション
    • ステート
    • キャッシュ
  • RDS
    • マスタ
    • ユーザ
    • アイテム
  • S3
    • コンテンツ
    • ログ
  • トラブル例: 全ての行動ログをMySQLに同期的にストア
    • 常に高負荷となるためインスタンスコスト増
    • ストレージ単価が他のデータストアより高い
    • レコード増加でパフォーマンス低下
    • MySQLのトラブルでゲーム全体に障害が波及
    • →一旦は非同期にS3に保存して後からAthenaやRedshiftなどでクエリ実行

実装フェイズ

• アカウント戦略
  • タイトル/ステージ毎にAWSアカウントを分割する
  • 部署･会社共通のPayerアカウントに紐付ける
  • あるゲームで高負荷であることが同一アカウント内の他ゲームへ影響を与える可能性がある
  • リソース上限など
  • マルチアカウントの管理機能が充実してきている
  • アカウント間の連携がしやすくなってきている
  • Organization
• AWS環境のコード化
  • 少ない人数で大きなインフラを管理できる
  • ヒューマンエラーの排除
  • ガバナンスを効かせやすい
  • デプロイをソフトウェアチックに実行
  • CloudFormation, SSM, CloudWatch, Config, Trusted Advisor
• ゲームにオススメのAWSサービス
  • DDos対策
  • Shield
  • WAF
  • AWS WAF
  • 脆弱性検知
  • Inspector

テスト(非機能テスト)

• 負荷テストにまつわる問題
  • 負荷テストを行っていないという場合が多い
  • ボトルネックが特定できないまま
  • AWSへの事前申請ができていなくて十分な負荷がかかっていなかった
  • 負荷テストは必ず実施しよう
• 確認ポイント
  • 実際のワークロードでテストを行っているか
  • 目的のスループット/レイテンシを処理できるか
  • ボトルネック箇所の特定
  • 各コンポーネントの特性とスケールするとどうなるのかを把握する
  • 各コンポーネントの障害時の影響を調査する
• ボトルネックの特定
  • メトリクスを確認
  • Enhanced Monitoring, Performance Insight
  • アプリケーションのプロファイラも有効
  • 全体のテストで特定できないなら個々を対象にテストする

Auroraを含めた負荷テストの注意ポイント

• 本番のワークロードで負荷テストを実施
  • キャッシュを含めたテストの為に1時間以上のテストを推奨
• パラメータグループはデフォルト設定のままでまず試す
• max_connectionsは最大16,000
  • インスタンス数 ✕ コネクション数を把握
  • アプリ側のスケールアウトによるコネクション溢れに注意
• ロックによるパフォーマンス影響も注意

障害テスト

• 負荷テスト中に障害テストを実施する
  • Appのエラーハンドリング
  • レスポンスタイム低下時のサービス影響
  • データ不整合の有無
• Auroraは障害挿入クエリを実行してシミュレーション可能
  • ALTER SYSTEM CRASH
• ChaosMonkeyによりAWSの上の本番システムでインスタンスをランダムに落とす

セキュリティテスト

• 許可されるリソース
  • EC2, RDS, Aurora, CloudFront, API Gateway, Lambda. Lightsail, DNS Zone Walking
• 申請が必要
• エージェントレスInspector
  • インスタンスの空きポートを確認可能
  • スケジュール実行で定期的に可能

テストの際のAWSへの申請

• ELB暖機申請
  • 急激な負荷を想定する場合に必要
  • CLB/ALBが対象
  • Business/Enterpriseサポートが対象
• 上限緩和申請
  • 各サービスにはハード･ソフトリミットがある
  • 1〜2週間前の申請をしよう
• ネットワーク負荷テスト申請
  • 持続的に1分以上1Gbps, 1Gppsを超えるトラフィックが発生する場合

AWSサポートの契約

テスト段階からのサポート契約をおすすめ(ビジネス以上)

リリース時

• 上限緩和申請
• リソースの確保
  • 数日前からインスタンスを立ち上げておく
  • オンデマンドキャパシティ予約

Infrastructure Event Management

• リリースに合わせてAWSのエンジニアが待機してリアルタイムのサポートを提供

• AWSからの内容の濃いヒアリングなど､サービス提供側にも負荷は多いサービス

• 全てのタイトルで使用するようなものではなく重要なタイトルで使用する

APIスロットリングエラーに遭遇したら

• APIコールのしきい値や内部動作仕様は非公開
• アプリケーション側でリトライ, アクセス頻度を下げる
• アクセスの分散
  • エクスポネンシャルバックオフ

本番運用で行いたいこと

• Trusted Advisor
  • コスト/パフォーマンス/セキュリティ/耐障害性/サービス制限
• 平常時/ピーク時の負荷のトレンド把握
  • ASGポリシーを時間ベースで設定
• 新サービス/機能の積極的な導入
• ゲーム機能追加によるワークロード変更時のテスト

[ユーザ・セッション] オレ的最強ECS & Fargate build環境 on AWS

駒井 祐人様 株式会社アカツキ 日課はBBQ サーバサイドエンジニア

Intro

• 300以上のコンテナが常時起動している(EC2, Fargate)

• ゲームプロジェクトでは100%がコンテナ

• 1日当り100こ個のコンテナをビルド

• ビルド環境のコスト $20/Month

• これらはCodeBuildによって実現されている

CodeBuild基本編

• docker Build on Jenkins
  • EC2でJenkinsを動かしてECRにPush
  • それなりにスペックが必要
  • 同時実行数の問題
  • Jenkinsのメンテナンス
• CodeBuildとは
  • フルマネージドのビルドサービス
  • うれしみ
  • サーバーレス + スケーラビリティ
  • AWSの各サービスと連携
    • SSM ParameterStore
  • VPC内で実行が可能
  • 豊富なビルド環境
  • Cloud Formationで管理
    • 新しい環境を作る時に一緒にビルド環境も作れる

デプロイ

• AWS推奨のパターン
  • CodePipelineを基本に組み立てていく
  • CodePipelineとは
  • フルマネージドのパイブラインサービス
  • AWS Integrationが豊富
  • GitHubのpush hookによるCI/CD
  • 手動承認も可能
• なぜアカツキではCodePipelineを使わないのか
  • 複数環境
  • 複数条件
  • ゲームマスタのversion
  • アセットのversion
  • 上記をエンジニア以外がデプロイ
  • デプロイ変数が持てない
  • エンジニア以外にはUIが難易度高い

• Jenkins Blue Ocean

  • シンプルかつ美しいJenkins UI
  • エンジニア以外でもわかりやすい
  • ティーンエージャー向けJenkins!!
  • step単位のログで見やすい
  • Pipeline as as CodeのGUI support
  • Pipelineの為に使用している
  • CodeBuildに環境変数を渡せる
• このアーキテクチャで幸せになったこと
  • インターフェイスが直感的
  • エンジニア以外でも簡単!
  • スケーラビリティ
  • コスト減
  • 月間ビルド費用 $20

CodeBuild応用編

• ビルド高速化
  • Image軽量化
  • 実際のNginxコンテナのImageサイズ
  • 21MB
  • ビルドキャッシュ
  • 途中までビルドした状態を保存しておく
  • CodeBuildのS3キャッシュ
  • Docker Layer Cache
  • Docker 18.09 以降の新機能
  • Multi stage buildの並列ビルド
  • Cache mount
• バッチ処理
  • ビルド済みのイメージ(ECR格納)
  • このイメージをCodeBuildで実行してバッチ処理として使用する
  • メリット
  • ビルド済みのアプリケーションロジックを再利用できる
    • Lambdaでは再現しにくい
  • サーバーレス
  • 長時間･並列バッチも可能
  • デメリット
  • CodeBuildのプロビジョニングに30〜40秒程度余計な時間がかかる
• セキュリティ
  • Role/IAMキーの権限は最小にしたい
  • Role
    • 最小の権限
  • IAMキー
    • 最小の権限
    • IPアドレス制限
  • CodeBuildからECRにPushする時のIP制限への対策
  • CodeBuildをVPC内で実行
  • NAT Gateway経由でEIPを使ってIPアドレスを固定する

あとがき

私は､ゲーム向けの仕事や活動をしていないのですが､なんか面白そうなイベントだなーと思いふらっと参加してみました｡結果参加して良かったです!!ゲーム業界の人はもちろん私のようなゲームに関わりのない人間でもアーキテクチャの話や負荷試験の注意点など､そのまま使えるノウハウがたっぷりでした｡
個人的にはアカツキさんのCodeBuildでバッチ処理を行っているっていう話が興味深かったです!