【レポート】ここ1〜2年でぐんと組みやすくなった「API型ゲームサーバーのサーバーレス化と安定運用」 #AWSSummit

クライアントとサーバ間の通信が頻繁ではないタイプのゲームにおいて、ゲームサーバをサーバーレス構成とすることは多くのメリットがあります。特にここ1〜2年の間に発表された新サービス・新機能はとても有効ということで、AWSのアップデートにキャッチアップするには最適のセッションをレポートします
2020.09.14

9/8 から始まりました AWS Japan Summit Online 2020。ライブ配信セッション AWS-24「API 型ゲームサーバーのサーバーレス化と安定運用」を拝聴しましたのでレポートします。

API型、つまりクライアントとサーバー間の通信が常時(≓頻繁に)行われていないタイプのゲームにおいて、ゲームサーバーをサーバーレス構成とすることは多くのメリットがあります。一方でデメリットやリスクもあり、それをAWSのサービスではどう回避・緩和するか。。そういった話が語られた有益なセッションでした。
特にここ1〜2年の間に発表された新サービス・新機能はとても有効ということで、AWSのアップデートにキャッチアップするには最適の内容となってます!

概要

インフラのプロビジョニングが不要であったり、自動でスケールするなどの特徴を備えたサーバーレスサービスを活用することで、運用負荷を低減しコスト効率の良いアーキテクチャを構築することができます。API 型ゲームサーバーにおいても、AWS Lambda の各種アップデートによりサーバーレス化を進める機能が充実し、このようなメリットを受けやすくなっています。一方で、サーバーレス化するとそれまで顕在しなかった課題が生じることがあります。 本セッションでは、ゲームサーバーにおけるサーバーレス事例を紹介するとともに、どのような課題が生じ得るかとその対処を説明します。

動画および資料

スピーカー

木村 秀平

  • アマゾン ウェブ サービスジャパン株式会社
    ゲーム エンターテイメント ソリューション部
    ソリューションアーキテクト
  • 好きなサービス
    • AWS Lambda、Amazon S3

内容

  • まとめ(いきなり!)
    • API型のゲームサーバーではサーバーレスサービスを検討する価値は高い
    • サーバーレスサービスは機能追加しやすい
      • 特にここ1-2年のアップデートはゲームサーバ向き
    • アクセス増加で規模が大きくなると対策検討が必要
      • スロットリング、コスト最適化
    • リトライ処理や負荷試験は必要
  • Agenda
    • サービスの紹介、メリット
    • 事例
    • 特徴
    • サーバーレス化の課題と対処

サーバーレスアプリケーションの特徴

  • サーバー管理が不要
    • 開発者とAWSで役割を分担する
      • 開発者はアプリとスケールアウト設計程度
    • 設計検証から本番導入までの期間短縮
    • キャパシティ管理・運用管理の負荷低減
    • アイドル時のコスト削減
  • 柔軟なスケーリング
  • アイドル時リソースの確保が不要
  • 高可用性

  • AWSが提供する豊富なサーバーレスサービス
    • 今回は特に Amazon API GatewayAWS LambdaAmazon DynamoDB に注目

事例紹介

Joyient

HABBY

Game Server Services (GS2)

  • どれもAPI Gateway, Lambda, DynamoDB がキーテクノロジ

特徴

  • ゲームサーバーの定義
    • ゲームロジックを処理するサーバー、またはその周辺
    • 分類1:セッション型
      • 常時接続
      • リアルタイム、頻繁な状態同期
    • 分類2:API型
      • 都度接続
      • 一人向けゲーム、モバイル、状態同期が少ないゲーム向き
      • 今回説明するのはこっち
  • 特徴
    • アクセスに波がある、特定のタイミングでアクセス急増が頻発する
    • RDBMSが多い、ロジックが複雑
    • プログラミング言語が様々
    • 24時間アクセスがある、安定期にはRIなどで長期稼働
    • -> 「(かつての)サーバーレス化を困難にする要因」
      • = 現在は解消・緩和されている

サーバーレス化と安定稼働

ゲームサーバーのサーバーレス化を阻害してきた原因

  • 課題1:言語ランタイムの対応
    • Lambdaはランタイム言語が決まっていた
    • -> カスタムランタイム('18/12〜)
  • 課題2:DBの変更が困難(RDBMS -> KVS)
    • なぜ定番構成はDynamoDBなのか?
    • RDSでの課題↓
    • 課題2-1:VPC Lambdaは起動に時間がかかった(Cold Start問題)
      • -> ENIの共通化('19/09)-> デプロイ時に共通のENI、Cold Start問題が解消
    • 課題2-2:DBコネクション数の増加(各Lambdaが接続に行く、コネクションプーリングが使えない
      • -> RDS Proxy('20/06)-> コネクションプーリングが可能に。ただしDBの接続許容数が増えるわけではない

安定運用

  • 不安定要因1:同時アクセスの増加
    • スロットリング(HTTPステータスコード429)
      1. 同時実行数の上限を確認、上限緩和申請を
    • 同時実行可能数の増加速度を確認
      • 同時実行可能な数は500/ふんずつ増える、コレを超えるとスロットリング
      • 事前の対処が必要
  • Provisioned Concurrency - '19/12

  • 不安定要因2:不十分なリトライ処理
    • Design for failureを考えて設計する必要あり
    • 詳細は別セッションを参照
  • 不安定要素3:不十分な負荷試験と上限緩和
    • Lambda - 最大同時実行数は特に重要
    • API Gateway
    • DynamoDB キャパシティ制限
    • 必要に応じて上限緩和

Tips:関連サービスのアップデート

まとめ

  • API型のゲームサーバーではサーバーレスサービスを検討する価値は高い
  • サーバーレスサービスは機能追加しやすい
    • 特にここ1-2年のアップデートはゲームサーバ向き
  • アクセス増加で規模が大きくなると対策検討が必要
    • スロットリング、コスト最適化
  • リトライ処理や負荷試験は必要

上手に使って良いサーバーレスライフを!

最後に

AWS Summit Online は 9/30 まで開催です。是非ご参加ください!