この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
安定したゲームリリースのためのWell Architectedと負荷テスト
2019年11月20日（水）にアマゾン目黒オフィスでアマゾンウェブサービス社の自社イベント「Amazon Game Developers Conference」が開催されました。
本記事は、セッション「安定したゲームリリースのためのWell Architectedと負荷テスト」をレポートします。
スピーカー
アマゾン ウェブ サービス ジャパン株式会社 ソリューションアーキテクト 三上 卓也様
セッション概要
AWSではプレイヤーの需要に応じて柔軟にスケールを変更できる、グローバルなゲームインフラ環境を提供しています。ゲームリリース時には想定を超えるリクエストがあり、設計の不備や試験不十分により、システムが不安定となるケースがあります。 本セッションでは、クラウドのワークロードの設計と運用に適用するAWSのベストプラクティスであるWell Architectedフレームワークと負荷テストに焦点を当てて、安定したゲームリリースに向けたアクションについて紹介します。
レポート
ゲームリリースと性能について
- リリース時に大量のアクセスがある
-
定期的なアップデート、SNSの影響をなどでスパイクが起きる、特徴的なトラフィック
ゲームのリファレンスアーキテクチャ
-
アベイラビリティーゾーンを分割する
-
ELBバックエンドで、AutoScalingのEC2でスケールする(最近はSpotが増えてきている)
-
バイナリデータはすべてS3に配置。 合わせてCloudFrontを利用してS3をOriginに。
-
ステートフルな通信はRESTとは別のサーバーを用意
-
RDSの結果をElastiCacheを導入してキャッシュ
-
非同期実行JobはSQSを使う。疎結合アーキテクチャ
-
DB負荷が増えたらリードレプリカを追加する
-
リーダーボードなどNoSQLで良いところはElastiCacheやDynamoDBを活用する
-
通知はSNSやPinpointのようなマネージドサービスを活用する。
AWS Well-Architected Framework (設計〜リリース)
システム設計/運用のベストプラクティス
10年以上の経験からまとめたもの
5本の柱(運用上の優秀性, セキュリティ, 信頼性, パフォーマンス効率, コスト最適化)でできている
最近はベストプラクティスとの差異を確認する「AWS Well-Architected Tool」の日本語化も進んでいる。
- 要件検討/設計: ホワイトペーパーを活用してAWS構成を設計
-
構築: Well-Architected Reviewでベストプラクティスになっているかを確認
-
運用: 運用中のシステムをWell Architectedに則っているかレビュー
パフォーマンス効率
- 最新テクノロジーの標準化
→AWSのマネージドサービスを活用し、どのようにその機能を使っていくかに集中できる
- 数分でグローバルに展開
→コード化してすぐに展開できるように
- サーバーレスアーキテクチャを利用
→インフラを考慮しなくてもスケールする
- より頻繁に実験可能
→クラウドのメリットは環境をすぐ作ってすぐ壊せること、複数の環境を持つことができる。
→新しい機能開発、設計を試していける
- システムを深く理解
→アクセスパターン、ワークロードなどから機能ごとに違うサービスを活用する。
選択
機能に合わせてアプローチを選択。
コンピュート: EC2/ELB/ECS/EKS/Lambda/APIGateway(Serverless)
→インスタンスタイプで使い分けることも
ストレージ: EBS/S3(CloudFront配信)/S3 Glacier
→こちらも用途によって使い分け、IOPSが欲しければEBSのプロビジョニングIOPSを利用するなど
データベース:
https://aws.amazon.com/jp/gametech/database/
レビュー
環境構築のコード化を行うと試験環境を容易に構築でき、別リージョンに構築したテストなどもやりやすくなる。
CloudFormation/Systems Manager/ AWS OpsWorkなども活用する。
→負荷試験をリージョンを変えて行うことも可能。(東京リージョン以外だと20%ほど安くなる場合がある。)
負荷試験にスポットインスタンスを使いコストを抑える方法も。
Lambda@Edge
Lambda@Edge を使ったゲームプレイヤーへのカスタムコンテンツの配信
モニタリング
想定外の問題を検知して、自動でアクションできるようにモニタリング設定を行うことが重要。
アプリケーションの死活監視、ものと状態にロールバック、ログを保存、ユーザー分析など・・・
→CloudWatchを活用
CloudWatch Metrics(CPUr異様率などを可視化)
CloudWatch Logs(ログを貯める)
CloudWatch Insights(CloudWatch Logsにクエリーを走らせる)
CloudWatch Alarm(Metricsからアラームを発火)
CloudWatch Dashboard(可視化)
収集したメトリクスからAWS Chatbotから、Slackなどに通知することも可能。
SNSのアラートで自動修復するLambdaをキックすることも可能。
トレードオフ
キャッシュ: ElastiCache/CloudFront
パーティショニングキャッシュ: RDS, DynamoDB
圧縮: CloudFrontでGZIP圧縮 Redshiftで圧縮してデータを保管
バッファリング: SQSを活用して疎結合に
システムテスト
スケジュールに追われたりしていても、負荷テストをしていれば事前に防げることが多いので、きちんと実施する。
実際のワークロードでテストを行い、目的をまとめ、ボトルネックの特定ができていて、 インスタンスのパフォーマンスが変化することを確認する
負荷をかけながら障害を起こすとどうなるのかを確認しておく。
負荷テストのゴールは必要。
DAU/RPSなどの具体的な目標(ゴール)を決める
負荷試験を行いボトルネックの特定をしておく。
→メトリクスを確認する
→RDSはEnhanced Monitoring, Performance Insight, Performance Schemaを有効化する。
個々のコンポーネントごとに負荷をかけて特定する
Auroraで負荷テストをする場合
- 本番ワークロードで負荷テストを実施。
-
1時間以上の負荷テスト。
-
パラメーターはまずデフォルト、必要に応じて変更。
-
Max Connectionは最大16000
-
ロックによるパフォーマンス影響もチェック
負荷テスト中に障害テストも行う。
- 障害が発生した時にアプリケーションが正常にエラーハンドリングができているかも合わせて確認ができる。
-
データベースの整合性が取れるのかの確認
-
最近はChaosMonkeyなども
セキュリティーテスト
2019/03にテスト規定が変更
https://aws.amazon.com/jp/security/penetration-testing/
Amazon Inspectorを活用する。
テストをする際の申請
ELBの暖気申請
→徐々に負荷をかけるなら大丈夫だが、最初から大量のリクエストを送る場合は必要
上限緩和申請
EC2インスタンスなどの上限に当たる可能性があるので、申請を行う。
ネットワーク負荷テスト申請
- ほとんど該当しないが、1分間に1Gbps, 1Gppsを超える場合、悪用目的のようなトラフィックの場合、テスト対象以外へ影響を及ぼしうるトラフィックなど
-
1週間~2週間前に申請する
開発/テストの段階からAWSサポートを活用する。
-
トラブル解決を効率化
-
開発中も加入をおすすめ
-
お問い合わせ回数制限なし、日本語サポートあり
リリース直後
ELBの暖気申請
上限緩和申請
→CloudFront(データ転送レート: 40Gbps/リクエスト: 100000RPS)
→EC2などのサービス上限緩和申請
→可能な限り早めに申請。
リソースの確保
- 超大規模、グローバルの場合、確実にサーバーのリソースを確保する必要があるかもしれない。
-
オンデマンドはごく稀にキャパシティーが不足する時がある
→RI, 事前に起動, もしくはオンデマンドキャパシティー予約
Infrastructure Event Management
- 本番リリースに備えたサポート、本番稼働中のリアルタイムサポートを提供
-
AWSエンタープライズサポートに含まれる
→ビジネスプランでも追加料金で可能
- 大規模で重要なゲームにおすすめ
-
1~2ヶ月前に申し込み
事例
ネクソンの多彩なゲームコンテンツポートフォリオを支える基盤と運用の最適化について
ロマサガ RS の大規模トラフィックを捌く Amazon ECS & Docker 運用の知見
→動画
まとめ
Well-Architected Frameworkに基づいて設計/運用することの重要さがわかるセッションでした。
様々なAWSのマネージドサービスを活用して、"どのように実装するか"に集中できる点が、AWSの最大のメリットだと改めて思いました。
ちょうど「AWS Well-Architected Tool活用術セミナー」のスライドも公開されましたので、合わせてご覧ください！
90
