この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
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で役割を分担する
- 柔軟なスケーリング
- アイドル時リソースの確保が不要
- 高可用性
- AWSが提供する豊富なサーバーレスサービス
- 今回は特に Amazon API Gateway、AWS Lambda、Amazon DynamoDB に注目
事例紹介
Joyient
- DAU500万
- 保守運用の人的コストをきらってサーバーレスに
- AWS 案例研究：嘉谊互娱
HABBY
- アーキテクチャが公開されている
- AWS 案例研究：HABBY
Game Server Services (GS2)
- ゲームサーバーに必要な機能をAPIサービスとして提供
- フルサーバーレスの構成、イベント駆動
- 監視コストが低い（re:Inventに社員全員で行ける）
- 【Startup Architecture of the year 2018受賞者インタビューシリーズ】Game Server Services 丹羽一智氏 | AWS Startup ブログ
- どれも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の接続許容数が増えるわけではない
- 課題3：RIが使えない（コスト要因）
- -> Compute Savings Plans (SPs) であればEC2だけでなくFargate/Lambdaにも適用
- Savings Plan Update: Save Up to 17% On Your Lambda Workloads | AWS News Blog
安定運用
- 不安定要因1：同時アクセスの増加
- スロットリング（HTTPステータスコード429）
-
- 同時実行数の上限を確認、上限緩和申請を
- 同時実行可能数の増加速度を確認
- 同時実行可能な数は500/ふんずつ増える、コレを超えるとスロットリング
- 事前の対処が必要
- Provisioned Concurrency - '19/12
- アクセスの急増に対処するための機能
- 設定した数の同時実行をCold Startなしで行える
- アカウントの同時実行上限の中から、1関数の1バージョンに適用する
- APIで使える
- AWS Lambda 関数スケーリング - AWS Lambda
- AWS Lambdaのスロットリング緩和 / How to manage throttling for AWS Lambda - Speaker Deck
- 不安定要因2：不十分なリトライ処理
- Design for failureを考えて設計する必要あり
- 詳細は別セッションを参照
- 不安定要素3：不十分な負荷試験と上限緩和
- Lambda - 最大同時実行数は特に重要
- API Gateway
- DynamoDB キャパシティ制限
- 必要に応じて上限緩和
Tips：関連サービスのアップデート
- API Gateway HTTP API
- 低レイテンシ・高コスト
- 選択項目 HTTP APIおよび REST APIs - Amazon API Gateway
- AWS Step Functions Express Workflow
- 同上
- 大量のリクエストを処理できるようになった
- AWS Step Functions Express Workflows のご紹介
まとめ
- API型のゲームサーバーではサーバーレスサービスを検討する価値は高い
- サーバーレスサービスは機能追加しやすい
- 特にここ1-2年のアップデートはゲームサーバ向き
- アクセス増加で規模が大きくなると対策検討が必要
- スロットリング、コスト最適化
- リトライ処理や負荷試験は必要
上手に使って良いサーバーレスライフを！
最後に
AWS Summit Online は 9/30 まで開催です。是非ご参加ください！
25
