re:Invent 2024: SupercellのSquad Bustersローンチ戦略とAWS活用
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - How Supercell’s newest game launched with tens of millions of players (GAM309)
この動画では、SupercellのSquad Bustersというゲームのグローバルローンチについて、AWS Technical Account ManagerのPhil Wardと、Supercellの開発チームが詳しく解説しています。Supercellの特徴的なCell Modelという組織体制や、4,000万人の事前登録者に対応するためのAWSインフラ設計、Load Testingの手法、AWS Countdownの活用方法などが具体的に語られています。特に、世界7つのAWSリージョンにまたがる2,300台のサーバー、15,000以上のCPU、20以上のAuroraクラスターを用意し、ローンチ後24時間で1,700万人が参加するという大規模なローンチを、問題なく成功させた技術的な取り組みが詳細に説明されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWS Technical Account ManagerによるSquad Bustersローンチ紹介
こんにちは。AWS の Technical Account Manager の Phil Ward です。この2年間、Supercell のアカウントチームをサポートしてきました。Supercell をサポートしてきた中で最も印象的だったのは、本日お話しする最新ゲーム Squad Busters のローンチを計画するお手伝いをさせていただいたことです。本日は Supercell から2人の同僚に登壇していただきます。1人目は Supercell の Cloud Governance チームの Toni Syvanen、 そして2人目は Squad Busters のバックエンド AWS プラットフォームを支える3人のサーバーエンジニアの1人である Tomi Joki-Korpela です。
本日のアジェンダですが、まず Toni から Supercell の特徴についてご紹介し、その後 Squad Busters というゲームについての概要をお話しします。続いて Tomi がゲームの詳細な技術アーキテクチャとローンチに向けた準備について説明します。私からは AWS Countdown と、AWS サポートとしてローンチをどのように支援したかについてお話しします。最後に Toni がまとめとして、ローンチ当日の結果についてご報告します。なお、本セッションはレベル300の技術的な内容となりますので、詳細な技術的側面にも踏み込んでまいります。
Supercellの特徴とSquad Bustersゲーム概要
みなさん、こんにちは。Supercell の Senior Cloud Governance Engineer の Toni Syvanen です。Supercell には今年から在籍していますが、AWS については10年以上の経験があり、そのうち5年間は北欧のさまざまなゲーム業界のお客様やスタジオと仕事をしてきました。長年にわたって、ゲーム関連のお客様が AWS テクノロジーを活用できるようサポートしてきました。では、Supercell について簡単にご紹介させていただきます。こちらが Supercell のミッションステートメントです。少し時間を取って読んでみましょう。ご覧の通り、私たちのゲームに対する期待値はかなり高く設定されています。プレイヤーの皆様には何年もゲームを楽しんでいただき、一生心に残る思い出を作り、友達と語り合っていただきたいと考えています。
私たちの歴史を振り返ると、2010年の設立から14年が経ちました。 その間、2年ごとに着実に1本か2本のゲームをリリースしてきました。5本のゲームを順調にリリースした後、2018年以降は新作のリリースがなく、次のゲームについて世界中から大きな期待が寄せられていました。そして今年、ついに Squad Busters をリリースしました。写真は、質素な最初の作業机に座る CEO の様子と、現在のヘルシンキの新オフィスです。
現在、世界中に650人のスタッフがおり、45の国籍が集まっています。2ヶ月前には、ヘルシンキ、上海、サンフランシスコ、韓国のスタジオから全員が集まりました。 Supercell の特徴は、ゲーム開発者をアーティストとして捉えていることです。アーティストとして、彼らには自分たちのゲームにとって最善の判断を下してほしいと考えています。この観点から、従来型の組織モデルは私たちの働き方に適していません。なぜなら、アーティストに「ゲームにこれを入れなさい」と指示して、良い作品が生まれたことがあるでしょうか？
私たちは実際、Cell Modelという異なるモデルを採用しています。これは当社の社名Supercellにも含まれているものです。このモデルでは、ゲームチームが全ての決定権を持っています。どんなゲームを作るかから、どんな技術を選ぶかまで、全てチームが決めるのです。今回はAWSテクノロジーについて話していますが、Tomiはチームの一員として、AWSテクノロジーを採用するという判断を下しました。私たちは、各チームが自分たちのゲームにとって最善の判断ができるよう、権限を与えることを重視しています。
このモデルのもと、Squad Bustersの前に、私たちは5つのゲームをグローバルにリリースし、 60億回以上のインストール数を達成しました。そして現在も、これら5つのゲームで月間2億人以上のアクティブプレイヤーを維持しています。 しかし、一般的にはあまり知られていないことですが、公開前、あるいは時にはSoft Launch後でさえも中止になったゲームがどれだけあるかということです。私たちと言いましたが、実際にはゲームチーム自身が判断を下したのです。
中止になったゲームは30本以上あります。これは経営陣が「このゲームはリリースしない」と言ったわけではなく、チーム自身が「私たちの高い期待値に達していない」と判断したのです。私たちは、 ゲームをリリースするかどうかについても、ゲームチームが最良の判断を下せると考えています。今年、ゲームチームはSquad Bustersのリリースを決定しました。これは私たちの最新作です。では、Squad Bustersがどんなゲームなのか、簡単に見てみましょう。
要約すると、Squad Bustersは10人のプレイヤーが参加するモバイルマルチプレイヤーゲームで、他のプレイヤーと競いながらジェムを集め、最終的に最も多くのジェムを集めた人が勝利します。プレイヤー対ワールドとプレイヤー対プレイヤーの両方の要素があり、ゲームセッション中にさまざまなアクションを楽しむことができます。 グローバルなプレイヤーベースを特徴としており、地域ごとにプレイヤーを分けることはしていません。ヨーロッパやアジアに友達がいても、一緒にパーティを組んでゲームをプレイすることができます。他のSupercellゲームからおなじみのヒーローたちも登場します。Clash of ClansのBarbarian（野蛮人）やHay Dayのニワトリとしてプレイすることができます。ゲームの世界観も既存のゲームからインスピレーションを得ており、例えばBoom Beachの戦場エリアでプレイすることもできます。
Squad Bustersのローンチ準備と技術アーキテクチャ
これらの要素は、クエストやアチーブメントをクリアすることでアンロックされ、経験値を獲得して新しい世界やキャラクターをアンロックしていきます。 では、実際にローンチについて話しましょう。 2023年に、2回のクローズドベータで公開テストを行いました。世界の限られた地域で招待制のベータテストを実施し、ゲームメカニズムがプレイヤーに合っているか、楽しんでもらえるかを確認しました。今年の初めに、Soft Launchを行うことを発表しました。Squad Bustersの場合、世界の特定の国々でリリースすることを意味しました。北欧諸国（フィンランド、スウェーデン、ノルウェー、デンマーク）、カナダ、メキシコ、そしてアジア太平洋地域の複数の国々が含まれていました。
数週間のSoft launchを経て、今年5月29日に正式リリースを迎えることになりました。 このローンチに対する期待値は非常に高く、Supercellの歴史上最大のローンチを目指していました。その実現のため、他のSupercellゲームでクロスプラットフォームおよびクロスゲームのプロモーションを大規模に展開し、おなじみの世界観やキャラクターと遊べる新作ゲームの登場をアピールしました。また、Apple App StoreやGoogle Play Storeで事前登録を受け付け、プレイヤーがローンチ日にゲームをプレイしたい意思を示すと、自動的にデバイスにダウンロードされる仕組みを用意しました。右側にあるように、4,000万人以上のプレイヤーが事前登録し、様々な特典が用意されました。
これらの特典は、プレイヤーが初日からゲームを始める動機付けとなりました。さらに、ローンチを成功させるため、多くのContent creator、Twitchストリーマー、YouTuberとコラボレーションを行い、攻略ガイドや初心者向けのコンテンツを制作してもらいました。このようにゲームへの期待は高まっていましたが、 4,000万人もの事前登録者がいることは、私たちに大きな課題をもたらすことも意味していました。これだけのプレイヤーにサービスを提供するために必要なサーバー数を見積もり、世界のどの地域にそれらを配置するかを決める必要がありました。これはグローバルローンチで、世界中で同時にリリースするため、プレイヤーにサービスを提供する場所のバランスをどうとるかを考えなければなりませんでした。そしてもちろん、ゲームローンチでよくある課題として、ローンチ時の急激なアクセス増加への対応がありました。ゲームを開放した瞬間に殺到する大量のプレイヤーにどう対処するか。
これらの課題への回答として、同僚のTommyに技術的な解決策について詳しく説明してもらいましょう。どうぞ、Tommy。ありがとう、Tony。こんにちは。私はTommy Karolaです。Server Engineerとして12年間Supercellで働いています。re:Inventには何度も参加していますが、発表するのは今回が初めてです。Squad Bustersのローンチについてお話しできることを嬉しく思います。というのも、私たちは素晴らしいローンチを実現できたと考えているからです。
マーケティングチームがこのローンチのために計画している活動について聞いたときの気持ちを今でも覚えています。 「これは大変なことになるぞ」と思いました。膨大な数のプレイヤーが押し寄せることは明らかで、果たしてその数を処理できるのかと心配でした。2012年に初めてリリースしたHay Dayのことを思い出しました。あの時も予想をはるかに上回るユーザーが集まり、スケーリングに関して控えめに言っても様々な問題が発生しました。Hay Dayについては多くの話がありますが、今回は触れません。Q&Aセッションや発表後に聞いていただければと思います。Tonyも言及したように、Supercellはこれまでに多くのローンチを経験してきており、マーケティングチームは常により多くのユーザーを初日に集めたがるため、ローンチの規模は徐々に大きくなってきています。そこで今回の本当の問題は、Squad Bustersのローンチ日がどれほどの規模になるのかということでした。
しかし、ローンチ自体について見ていく前に、 Squad Bustersの内部構造について少し深く掘り下げてみましょう。Squad Bustersはリアルタイムマルチプレイヤーゲームで、シミュレーションはクライアントとサーバーの両方で行われますが、クライアントは信頼できないためサーバーが権威を持っています。クライアントを信頼してしまうと、ハッキングを試みる人々が必ず現れるからです。シミュレーションは50ミリ秒ごとに更新されるため、かなり頻繁に更新が行われています。また、バトルは遅延の影響を受けやすいため、プレイヤーにできるだけ近い場所でバトルを実行する必要があります。
Squad Bustersの内部構造とAWSサービスの活用
Squad Bustersや私たちの全てのゲームのもう一つの特徴は、Statefulサービスであるということです。最近はStatelessの方が一般的なので、なぜStatefulを使用しているのか疑問に思われるかもしれません。特にここre:inventではStatelessという言葉ばかり耳にしますが、ゲームの場合、実はStatefulの方が理にかなっています。なぜなら、ゲームではプレイヤーのアクションに対して素早い反応が求められるからです。私たちのゲームでは、クライアントはサーバーからの応答を待たずに、プレイヤーのアクションに即座に反応します。その後、サーバーが同じアクションを実行し、クライアントの状態と照合します。状態が一致すれば、ゲームは継続できます。ただし、サーバーがこれらのアクションを検証するためには、クライアントと同じゲーム状態を持っている必要があります。Statefulアプローチを採用することで、アプリケーションと共にゲーム状態を保持でき、外部のキャッシュやデータベースに依存する必要がなくなります。さらに、Statefulアプローチの利点として、ゲーム状態をデータベースに更新する頻度をコントロールできるため、データベースの負荷も軽減できます。ここで全体的なアーキテクチャをご覧いただけます。
このアーキテクチャはシンプルに見えますが、非常に高いスケーラビリティを持っています。数百万人の同時接続プレイヤーまでスケールアップできます。基本的に、ここにあるものは全てスケーラブルです。左側にはバトル以外の全てを処理するメインサイト、右側には実際のバトルが行われるBattle Siteが表示されています。これらのBattle Siteは、プレイヤーの近くに配置するため、世界中の異なるAmazonリージョンに分散されています。
これは私たちのアーキテクチャを簡略化した図ではありますが、AWSサービスへの依存関係はそれほど多くありません。その理由は、私たちが必要とした時点で、多くのサービスがまだ実装されていなかったからです。例えば、Amazon GameLiftには多くの興味深く有用なサービスがありますが、私たちが必要とした時点では利用できませんでした。そのため、自前で実装する必要がありました。正直なところ、私たちは少しコントロールにこだわる傾向があります。自分たちの運命は自分たちでコントロールしたいと考えており、特に問題が発生した際に、実装の深部まで掘り下げてバグを素早く修正できることは便利です。
デバイスでゲームが開始された時の流れを見ていきましょう。ゲームを開くと、クライアントはまずProxyインスタンスと呼ばれるものに接続しようとします。そのアドレスはラウンドロビンDNSから取得し、そのProxyインスタンスとTCP接続を確立します。このTCP接続は、デバイスでゲームが実行されている間、維持されます。クライアントが接続すると、Proxyはダウンロードする新しいコンテンツがあるかどうかをクライアントに伝え、もしある場合はAmazon CloudFrontからダウンロードします。
次に、プレイヤーをゲームにログインさせます。実際のログインはProxyの背後にあるService Nodeと総称されるインスタンスで行われますが、これらのService Nodeは異なるユースケースに合わせて調整されています。ログイン用のノードがあり、ログイン時にはAmazon Auroraからプレイヤーの状態を読み込みます。ログイン後、メインサイトは現在アクティブなBattle Siteをクライアントに通知します。その後、クライアントはそれらの全てのBattle SiteにUDPピングを送信します。これは、全てのBattle Siteへのレイテンシーを知り、このプレイヤーにとって最適なサイトを特定するためです。この情報をメインサイトに送り返し、メインサイトはこれをMatchmakingや分析に使用します。
こちらの地図は、プレイヤーがバトルを行っている際に収集された世界各地の平均レイテンシーを示しています。青色は良好なレイテンシー、赤色は悪い状態、黄色はその中間を表しています。私たちはこの地図と収集したデータを使って、世界のどの地域でプレイヤーが良好なレイテンシーを体験しているか、そしてより良い体験のためにどこに新しいバトルリージョンを追加すべきかを把握しています。この地図を見ると、Latin Americaに新しいバトルサイトがあれば良さそうに見えますが、実はそう単純ではありません。そこに新しいバトルサイトを追加すると、マッチメイキングプールが小さくなってしまい、その地域のプレイヤーがバトルに参加するまでの待ち時間が長くなってしまうのです。バトルサイトの数を決めるのは、常にこのようなバランス調整の問題なのです。
次に、プレイヤーが他のプレイヤーとバトルをしたい時に何が起こるのかを見てみましょう。マッチメイキングシステムは、ログイン時に収集した最新の情報を使って、そのプレイヤーに最適なバトルリージョンを探します。もちろん、同じような経験値を持つプレイヤーを見つける必要があるので、必ずしもベストな場所とは限りませんが、参加する全プレイヤーにとって十分に良い場所でバトルが行われるように努めています。適切なバトルリージョンが見つかると、マッチメイキングシステムはそのバトル用のバトルサーバーインスタンスを準備します。参加プレイヤー数や、プレイするマップ、ゲームモードなどの情報を伝えます。そして、バトルインスタンスはメインサイトに接続情報（IPアドレスやポート番号など）を伝え、その情報を参加予定のクライアントに送信します。全クライアントの接続が完了すると、バトルを開始できます。
クライアントはより良いレイテンシーを実現するためにUDPを使ってBattle Serverインスタンスに接続します。1つのBattle Serverインスタンスで動いているのはあなたのバトルだけではありません - 実際には何百ものバトルが同時に実行されており、必要に応じてBattle Serverインスタンスの数を調整することができます。世界のある地域でより多くのバトルが必要になった場合、その地域のBattle Serverインスタンスの数を増やすことができます。これは理にかなっています。なぜなら、真夜中で誰もプレイしていない地域では多くのバトルインスタンスを実行する必要がないため、リージョンごとのインスタンス数を動的に変更できるのです。
約4分間のバトルが終了すると、バトル結果がメインサイトに送信され、プレイヤーの状態がAmazon Auroraに更新されます。このアプローチを採用することで、バトルサーバーリージョンにデータベース接続を持つ必要がなく、データベースはメインサイトでのみ実行されています。
Amazon Auroraについて、なぜDynamoDBではなくAuroraを使用しているのか疑問に思われるかもしれません。これには歴史的な背景があります。Supercellでの開発を始めた当初、以前の会社での経験からMySQLを選択しました。当時はMySQLを自前でホスティングし、EC2インスタンス上で運用していました。最初のゲームが予想をはるかに超える人気を博したとき、複数のデータベースインスタンスを実行できるようにシャーディングを急いで実装する必要がありました。シャーディングは社内で実装しました。ゲームの人気が高まり、シャードを追加していくにつれて、フェイルオーバーやレプリケーションの管理が大きな負担になってきました。現在、私たちの大規模なゲームでは100個近いシャードが存在します。
Auroraが登場したタイミングは私たちにとって完璧でした。というのも、ちょうどその時に代替案を探していたところだったからです。実際、Amazon Auroraには非常に満足しており、私たちのすべてのプレイヤーゲームがAurora上で動作しています。Stateful Architectureも、データベースへの状態の保存頻度を調整できるため、データベース負荷の軽減に役立っています。また、Aurora 3とI/O最適化を試してみたいと考え、データベースインスタンスタイプとしてGravitonを選択しました。新しいゲームでは新しい技術を試しやすいため、Squad Bustersをこれらの新技術を試す最初のゲームとして選びました。現在、すべてのゲームをAmazon Aurora 3に移行するプロセスを進めており、すでに移行を完了したゲームもあります。
AWS Countdownを活用したローンチサポート
課題について見ていきましょう。クライアントのログインが潜在的なボトルネックになる可能性があることは認識していました。他のゲームでも、イベント時やメンテナンス後に大勢のプレイヤーが一斉にログインする際に同様の状況を経験しています。幸い、これは他のゲームですでに解決済みの課題でした。ログインを処理する十分な数のサービスノードを用意するだけで対応できます。Squad Bustersには、いくつかの救済策があります。新規プレイヤーがゲームを始める際、オフラインでプレイできるチュートリアルに入るため、サーバーへの負荷があまりかかりません。もう一つの救済策はタイムゾーンです。全員が同時に起きているわけではないので、負荷を分散させることができます。
もう一つの課題は、必要なサーバー数の見積もりでした。そのために、ローンチ日に予想されるプレイヤー数を見積もる必要がありました。ローンチ日の最大同時接続プレイヤー数を400万人と見積もりました。この数字はどのように算出したのでしょうか？Toniが言及した4,000万人の事前登録者数があり、大まかな計算として10で割ることで、1日あたりの同時接続ユーザー数の概算を出すことができます。ただし、事前登録した全員がローンチ日に来るわけではないことも把握していました。
他のデータポイントとして、他のゲームからの分析データがありました。400万人の同時接続プレイヤーで十分だと確信していました。この数字を使って、必要なサーバー数を見積もることができました。メインサイトは他のゲームと似ているため、他のゲームの状況を参考にしてメインサイトのサーバー数を算出できました。バトルサイトは新しい要素だったため、必要なサーバー数を理解するためにロードテストを実施する必要がありました。
私たちのテストアプローチはユニークです。十分な負荷を生成するために、多数のサーバー上でカスタムロードテストクライアントを実行します。このロードテストクライアントは実際のプレイヤーをシミュレートし、ゲームをプレイすることができ、バトルさえもプレイ可能で、モバイルクライアントと同じプロトコルを使用します。そのため、サーバーから見ると、モバイルクライアントと全く同じように見えます。通常、これらのロードテストは本番環境と同様の別環境で実行することを望みます。最低でも10万人の同時接続プレイヤーでロードテストを実行したいと考えています。なぜなら、問題が発生する可能性がある場合、その規模で問題が見え始めるからです。通常、システムの限界点を確認するためにさらに大きな負荷をかけることも望ましいです。システムがどれだけの負荷に耐えられるかを知っておくことは重要だからです。
システム全体のLoad Testを実施したくない場合もあります。コストがかかりすぎるからです。Squad Bustersでは、Battle Serverインスタンスに対してのみLoad Testを行い、1台のサーバーで処理できるバトル数を検証しました。また、メモリリークなどの時間経過で発生する問題を発見するため、長時間実行するLoad Testも通常行います。Load Testの結果の監視にはPrometheusとGrafanaを使用しています。こちらは興味深い例で、1台のBattle Serverインスタンスに対して、200バトルと250バトルの2つの異なるテストを実行した結果です。このCPUグラフでは、青いバーがサーバーが処理できる最大のCPU負荷を示しています。
250バトルでもCPU使用率は最大値の半分程度なので、もっとバトル数を増やせそうに見えます。私も最初はそう考えました。しかし、別のグラフを見てみると、このグラフはシミュレーションが負荷に追いついているかどうかを示していますが、250バトルではすでに遅延が発生していることがわかります。ここから学べる教訓は、CPUグラフだけではサービスが過負荷状態かどうかを判断できないということです。もし250バトルで運用していたら、プレイヤーにとって良くない体験になっていたでしょう。
Load Testを行う際は、テスト実行の記録を残しておくことをお勧めします。何度もテストを行うことになり、結果を忘れてしまうからです。おまけに、スクリーンショットを撮っておけば、将来のre:Invent発表で使えます。Load Testの結果をいくつか共有したいと思いますが、これらはワークロード固有のものなので、皆さんの場合には当てはまらないかもしれません。私たちはBattle ServerにC7ファミリーの使用を目指していたので、様々なC7アーキテクチャーをテストしました。私たちのワークロードでは、AWSからのフィードバックに基づき、C7gが価格と可用性の面で最適でした。ただし、C7gが使用したい全てのリージョンで利用できないと聞いたため、C6gもテストしました。
Load Testで発見したもう一つの興味深い点は、より大きなインスタンスサイズを使用すると、実は私たちのワークロードではパフォーマンスが低下したことです。これは、Javaを使用しており、大きなインスタンスサイズではJavaのガベージコレクターによる停止時間が長くなったためです。そのため、比較的小さい2xlargeを選択しましたが、私たちのワークロードには最適でした。この時点で、私たちの側は launch の準備が整っていましたが、成功させるために利用可能な全てのサポートを活用したいと考えていました。
未知の要素を最小限に抑えたいと考えていました。私たちの側の未知の要素は既に特定できていると思っていましたが、すでにAmazonと密接に協力していたにもかかわらず、AWS側の可視性は限られていました。一斉にプレイヤーが参加するlaunch前とlaunch中に、専任のサポートエンジニアに支援してもらえると良いと考えました。それこそがAWS Countdownで得られるものですが、AWS Countdownについてより詳しく説明するために、Philに引き継ぎたいと思います。
AWS Countdownの詳細と Squad Bustersへの適用
ありがとう、Tommy。Tommyが言及したように、SupercellはゲームのローンチにAWS Countdownを活用しました。多くの方がCountdownとその活用方法についてご存知ないかもしれませんので、その背景と、ゲームローンチをサポートするためにAWSサポートと共にどのように活用できるかについてご説明したいと思います。 AWSサポートの各レベルについて改めてご説明しますと、Squad Bustersでプレイヤーの旅が進化していくのと同様に、AWSサポートにも顧客の成熟度に応じた4つの有料レベルがあります。まず、AWSでテストや初期開発を行うお客様向けのDeveloperサポート、次にクラウドでライブゲームワークロードを運用するお客様向けのBusinessサポート、そしてAWS上でビジネスクリティカルなワークロードを運用する成熟度の高いお客様向けのEnterprise On-RampとEnterpriseサポートがあります。これらのEnterpriseレベルには、私のようなTechnical Account Managerの指定とCountdownなどのプロアクティブなプログラムへのアクセスが含まれています。
Countdownは、ゲームローンチなどの計画されたイベントの実施中に、アーキテクチャやスケーリングのガイダンス、そして運用サポートを提供するAWSサポートのエンゲージメントです。これらのイベントに対して、Countdownは計画の最適化を支援し、AWSサポートエキスパートの専門知識を活用し、専任のサポートエンジニアを通じてトラブルシューティングを加速することで、ゲームの背後にあるAWSプラットフォームに自信を持ってローンチできるようサポートします。CountdownはEnterpriseとEnterprise On-Rampサポートレベルに含まれる特典です。Businessサポートのお客様向けの有料オプションもあり、Technical Account Managerが主導します。また、Tommyが言及したように、AWSサポートの専任Cloud Support Engineerが主導し、ライブイベントの実施中に24時間体制でカバレッジを提供するプレミアムティアオプションもあります。
AWS Countdownは、まるで自分のSquadを構築するようなもので、容量計画やTechnical Account Managerとの対話、あるいはCloud Support Engineerによる特定の技術トピックに関する詳細な検討など、ローンチを成功させるために必要な専門知識とサポートでゲームチームを補強することができます。 Countdownはフェーズ分けされたプロセスで、イベント前に必要な作業を計画し文書化する十分な時間を確保するため、通常はイベントの6～8週間前にご相談いただくようお願いしています。これは柔軟に対応可能で、1～2週間後に予定があるような場合でも、できる範囲でサポートさせていただきます。
初期段階では、イベントの目標を評価します。Squad Bustersの場合、ソフトローンチの計画、対象国、ユーザー数、イベントの順序などについて話し合います。これらの成果を踏まえ、環境がニーズを満たし、目標を達成できるよう構築されているか評価します。そうすることで、すべてを確認し、より自信を持ってゲームをローンチすることができます。すべての終了後、レビューを行い、学んだ教訓や見落としていた点を評価し、次のローンチに向けて準備します。
Squad Bustersについては、SupercellとAWSの長期的なEnterpriseサポートエンゲージメントの一環としてローンチを追跡していました。ソフトローンチの約8週間前から正式な計画が始まり、Squadチームと定期的なミーティングを持ち、サポートの計画とローンチを成功させるために必要な作業の評価に専念しました。Tommyが言及したように、私たちはローンチに対してかなり高い目標を持っており、達成したいプレイヤー数を主要な指標として設定しました。早い段階で、Supercellはローンチ時に最高レベルのサポートと保証を提供するため、Countdown Premiumの利用を決定しました。
Squad Bustersの開発プロセスにおいて、Countdownチームがどのような判断をSupercellに提供したのか、いくつか例を挙げてみましょう。Tomiが言及したように、Supercellは広範なLoad Testingを実施し、Instance Familyの中でC7gが最もコストパフォーマンスに優れているという結論に達していました。
AWSサポートは、これらのインスタンスがいつどこで利用可能かを詳しく評価しました。サンパウロなど、彼らが展開を予定していた一部のリージョンではその時点でC7gが利用できなかったため、ローンチに向けたLoad Testingの代替案を評価・提案しました。万が一、可用性やキャパシティに問題が発生した場合に備えて、バックアップオプションを用意していたのです。
次に考慮したのはリージョンの選択で、特に北東アジアにおけるBattle Siteに最適なリージョンを検討しました。彼らが言及したレイテンシー情報とAWSのキャパシティ情報の両方を考慮し、大阪やソウルではなく東京リージョンを選択しました。主な理由はC7gの可用性でした。
最後に、様々なReserved Instanceのオプションについて議論しました。大規模なローンチやイベントを計画する際の重要なポイントは、特定のタイミングで大量のキャパシティが必要になることです。AWSには、Zonal Reserved InstancesやOn-Demand Capacity Reservationsなど、キャパシティを確保するための様々な仕組みがあります。また、On-Demandインスタンスのみを使用して事前にスケールアップする方法もあります。これらの選択肢について情報を提供しましたが、実際にキャパシティをどのように計画したかについては、Toniから説明してもらいましょう。
Squad Bustersローンチ当日の結果と得られた教訓
先ほど述べたように、私たちは不確実な要素を排除したかったので、Load TestingとAWS Countdownチームからのフィードバックに基づいて判断を下す必要がありました。ローンチ当日のAuto Scaling Groupの最小キャパシティを高めに設定することにしました。完全に動的にスケールアップ・ダウンすることも可能でしたが、ローンチ当日に限っては、プレイヤーのゲーム開始までの待ち時間を最小限に抑えるため、最小値を非常に高く設定しました。Capacity Reservationメカニズムの使用は見送りました。というのも、ローンチ日の1週間前から、その新しい最小値に向けて環境のスケールアップを開始していたからです。数日前には必要なキャパシティをすべて確保できており、新しいAuto Scaling Groupのロールアウトが必要となるようなアップデートもないことがわかっていたため、Capacity Reservationを使用することは追加の作業が発生するだけで、メリットがないと判断しました。
ローンチ当日は、世界中の7つのAWSリージョンにまたがる2,300台のサーバーを展開しました。右側の地図で示されているように、アメリカに複数、ヨーロッパに複数、そして南アメリカに1つ、アジアパシフィック地域に複数と、グローバルなプレイヤーベースをカバーする配置となっています。これは、ゲームやバトルのシミュレーション用に15,000以上のCPUを用意したことを意味し、さらにLoginサービスやProxyサービスなどのサポート機能も備えていました。また、20以上のAuroraクラスターを用意し、データベースクラスター間で負荷を均等に分散させ、ホットスポットの発生を防ぐ構成としました。
ローンチ当日、オフィスはSquad Bustersの世界観を再現した空間に変身し、大勢の人々が集まっていました。コンテンツクリエイターたちが、ゲームチームと一緒にローンチ当日の様子を撮影するために集まっていました。確かTomiはポータルサークルの周辺にいたと思います。 また、世界中の著名な場所で大規模なマーケティング活動も展開されました。ローンチ当日には、ハリウッドスター、YouTubeスター、TikTokスターなど、あらゆる層に向けた著名人が登場する大規模なローンチトレーラーも公開されました。 では、実際にはどのような展開だったのでしょうか？タイムラインを追いやすくするため、UTC時間の午前7時30分を起点に見ていきましょう。この時点で、全てのアプリストアでゲームを公開することを決定しました。グラフの中央に見える青い線は、Soft launchがまだ進行中だった時点での基本的な同時接続プレイヤー数を示しています。アプリストアでの公開スイッチを入れると、
わずか30分後には、同時接続プレイヤー数が20万人にまで急上昇しました。さらに待つこと1時間で、 世界中で同時に50万人のプレイヤーが遊んでいる状態に達しました。これは全て、 UTC時間の午前11時までは一切マーケティング活動を行っていない状態での数字です。
この50万人は、ゲームが利用可能になったことに気づいて自発的にプレイを始めた人々でした。そしてさらに1時間後には、 同時接続数が100万人を突破しました。これは、サーバー容量として準備していた400万人には及びませんでしたが、順調な立ち上がりを見せていました。その後24時間の推移を見ると、明らかにレベルアップしていることがわかります。先ほど言及したように、タイムゾーンは現実のものなので、太平洋の位置がグラフ上で明確にわかります。その時間帯は何も起こらず、アジアで朝を迎えると再び上昇し始めるのです。
この写真は、マーケティングが開始される午前11時頃の、S3サーバーエンジニアたちの幸せそうな様子です。前列にいるJan、Tommy、そしてもう一人のTommyが、ハンバーガーとドリンクを楽しんでいます。この写真には写っていませんが、この3人をサポートする大きなチームがあります。私のようなAWS関連の質問対応や負荷対策を行うスタッフ、カスタマーサポートシステムやアナリティクスシステムに携わるスタッフなどです。このゲーム専属のバックエンド担当である3人のチームは独立して機能していますが、その背後には彼らをサポートする大規模なインフラストラクチャーチームが存在しているのです。
タイムゾーンについて言えば、これは本当に重要な要素なんです。ここに、ゲームにログインする人々のリアルタイムデータをアニメーション化したものがあります。光が点滅するたびに、誰かがゲームを起動してAnalyticsパイプラインを通過したことを表しています。ヨーロッパが正午の時、アジアではまだ夜9時頃なのでアクティビティが見られますが、この時間帯のアメリカはかなり静かです。この24時間のアニメーションを見ると、点滅する光が太陽の位置を追いかけているのがはっきりと分かります。ゲーム業界では「Follow the sun」が実際の現象として存在するんです。
結果を見ると、これは私たちにとって過去最大のローンチでした。そして、最も退屈なローンチだったという点でも嬉しく思っています。ローンチ中に大きな問題は一切ありませんでした。すべてが順調に進み、十分なキャパシティがあり、すべてのサポートシステムも正常に機能しました。予想される負荷の4倍以上に対応できる準備をしていたため、必要以上のキャパシティがありましたが、ローンチ直後にAuto Scalingに切り替えたので、400万の同時接続ユーザーに対応する上限を設けるのではなく、自動的にグラフに従って調整されるようになりました。ローンチ当日、CountdownチームからAWSの1つのRegionとその中の1つのAZで、私たちが使用していたInstance typeのキャパシティが不足する可能性があるという警告がありました。これは有用な事前警告でした。私たちは十分なInstanceを確保していたので心配はありませんでしたが、潜在的なエラーの原因を知ることができて価値がありました。ゲーム開始から最初の24時間で1,700万人が参加し、これは本当に素晴らしい結果でした。
これは私たちの歴史の中で最大のローンチとなりました。では、これまでお話ししたことから、どのような教訓を得ることができるでしょうか。 Tomiが言及したように、未知の要素を排除することです。これこそが、今回のローンチ準備で私たちが目指していたことでした。直面する可能性のある未知の要素をできる限り排除することです。
皆さんにLoad testingを強くお勧めします。なぜなら、本番環境に移行する前にワークロードの動作を経験することができるからです。既存のサービスに新しいイベントを追加する場合でも、Load testを実施して、新機能がワークロードの動作にどのような変化をもたらすかを把握してください。Quotaのチェックも重要です。自社のQuotaだけでなく、AWSのQuotaだけでもなく、周囲のあらゆるQuotaをチェックしてください。依存している様々なサービスにおいて、予期せぬQuotaに関する発見があることが多いからです。
私たちはカスタマーサポートサービスを利用していますが、自社では構築していません。私たちはゲームスタジオであり、サポートソフトウェアは作っていません。そのため、ローンチの成功に関連するこれらのシステムをすべてチェックし、周囲の全員がローンチの準備ができていることを確認してください。AWSチーム、つまりアカウントチーム、そしてアクセス権がある場合はCountdownチームにも早期に関与してもらってください。私たちが感じた最大の利点は、ローンチ当日ではなく、Countdownチームとの準備段階での議論にありました。私たちが知らないことは何か、そしてそれらの未知の要素をどのように排除するかを見極めることができたのです。
以上が本日のまとめとなりますが、AWS Games チームから、いくつかの参考リソースもご紹介するように依頼されています。AWSでゲームワークロードを実行するための様々なソリューションやリソースがご用意されています。最後のものは実は面白いんですよ - re:Inventのゲーム業界向けガイドです。最後のQRコードには、 AWSでのゲームローンチやゲームインフラに関する他のプレゼンテーションがたくさん含まれています。これで本日のプレゼンテーションは終わりですが、時間を確認したところ、質疑応答の時間が1、2問分ございます。会場の皆様、ご質問のある方は 挙手をお願いいたします。それでは、ご清聴ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion