【レポート】『あんさんぶるスターズ！！ Music』を支える Amazon ECS ～人気ゲームの新作でのコンテナ化～ #AWSSummit

こんにちは、コンサルティング部の後藤です。

皆さん、AWS Summit Online 2020楽しんでいますか？今年のAWS Summitはオンライン形式でライブセッションが9/8 ~ 9/9の期間配信されており、150を超えるオンデマンドセッションも9/30まで視聴することが出来ます。

今回はその中からHappy Elements様の事例セッションを見てきましたので、セッションレポートを投稿させて頂きます。

『あんさんぶるスターズ！！ Music』を支える Amazon ECS ～人気ゲームの新作でのコンテナ化～

セッション概要

2020 年 3 月 15 日スマートフォンゲームアプリ『あんさんぶるスターズ！』の新作リズムゲーム『あんさんぶるスターズ！！ Music』をリリースしました。人気タイトルの続編となる新作のリリースに向け、コンテナ技術の採用を計画し、導入準備を進め、リリースされたアプリのサーバーサイドは Amazon ECS で稼働しています。本セッションでは当アプリのリリースまでのコンテナ化にフォーカスを当て、経緯・技術選定・発生した課題と解決方法・リリース時およびリリース後の状況についてお話させていただきます。

スピーカー

Happy Elements 株式会社 インフラグループ グループリーダー 鷲見 啓志 氏

本セッションについて

• 本セッションの対象者
  • （コンテナやAmazon ECSの導入を・・・）
  • これから検討したいと考えている技術選定の担当者・責任者
  • これから始めるインフラエンジニア
  • 現在進めているインフラエンジニア
• 本セッションアジェンダ
  • 1.コンテナの導入以前に抱えていた課題について
  • 2.コンテナ導入と技術選定について
  • 3.コンテナの導入で直前した課題と解決方法について
  • 4.リリース時の様子とその後

『あんさぶるスターズ！！』について

2015/04にリリースし、総ダウンロード数は300万件を超える男性アイドル育成ゲーム『あんさぶるスターズ！』の新章として新しくリニューアルしたタイトル。 『あんさぶるスターズ！！Basic』と『あんさぶるスターズ！！Music』の2タイトルになるが、今回紹介するのは『あんさぶるスターズ！！Music』になります。

『あんさぶるスターズ！！Muisc』は2020/03/15にリリースしており、事前登録者数は70万、リリース当日のダウンロード数は140万件となっており、Twitter社のブログで公開された「世界中で今年もっともツイートされたゲームのTop10」に入るタイトルになっています。

技術構成

• スマートフォンからのアクセスをCloudFrontで受け取り、ALBで負荷分散。
• EC2起動タイプのECSを採用。
  • サーバサイドの言語にはRuby2.6 Rails6.0を使用。
• データベースにはAuroraとElastiCacheを採用。
  • Auroraは水平分割でシャーディングされたUserDB、シャーディング無しのMasterDBとして使用。
  • ElastiCacheではMemcached、Redisを使用。

『あんさぶるスターズ！』時代の状況と課題

オンプレミスのデータセンターで稼働しており、Ruby2.2.9 Rail 4.4.10と古いバージョンを使用していた。

そこで挙げられた課題は以下の3点

• スケールしない環境、リソースの無駄使い
  ゲームの特性上、イベント開始時や終了時にアクセスが集中するがオンプレミス環境で稼働しているため突発的なアクセスに対応出来ない。
  また、アクセスが集中しない時期はサーバのスペックが余分となってしまう。

• 技術的負債
  ユーザに楽しんでもらうことを重視していたためゲームコンテンツ機能の追加を最優先にしてきた。
  その結果インフラやミドルウェアのメンテナンス、新しい技術の導入が後回しとなった。

• 時間のかかる環境構築
  オンプレミス環境であるため開発環境構築に時間かかるうえ、複数タイトルの開発を行う場合複数のミドルウェアのバージョンが同居するため、環境ごとに切り替えを意識しないといけない。
  GithubからのソースコードDLやRuby、Rails、Unity等ミドルウェアのインストールやバージョン合わせで開発を開始出来るまで半日から1日ほど要した。

コンテナ化を進めた理由

• 環境構築と管理の容易さ

  • 環境構築の容易さ
    Dockerインストールして数コマンドで構築が完了するのが魅力的。

  • 環境管理の容易さ
    人や環境による差異が無くなる。
    ミドルウェアが複数バージョン必要なケースでもコンテナを起動するのみ。

  • Infrastructure as Codeの実現
    誰でもDockerファイルを確認することで構成を把握することができ、同じ構成を構築できる。

• 可搬性、環境差異の排除

  • 可搬性
    Dockerコンテナが動く環境であればAWS以外の環境やオンプレミスでも稼働可能。 移行が失敗した際にも切り戻しが容易な点も魅力的。

  • 環境差異の排除
    コンテナ環境にすることで環境に一貫性を持たせられる。
    開発、ステージング、本番といった環境毎の設定差異がなくなり、環境依存の不具合が減る。

• 技術的負債の返済
  AWSを使用してもEC2でオンプレミス同様の使い方ではまた負債が溜まってしまう。そこでフルマネージドサービスの活用やコンテナの採用を決定。

コンテナ技術選定

Amazon ECS と Amazon EKSどちらを使用するか検討した結果、今回はAmazon ECSの採用した。

ECS採用を決めた点は「運用管理」「学習コスト」が抑えられるため。
EKSはKubernetesに対する深い知識が必要であるため、ECSのが学習コストが抑えられると判断。

ECSの採用を決めたら、次に2種類の起動タイプを選定する必要がある。

• EC2起動タイプ
  EC2インスタンスのクラスタでコンテナ化されたアプリケーションを実行可能。

• Fargate起動タイプ
  バックエンドインフラストラクチャをプロビジョニング及び管理することなくコンテナ化されたアプリケーションを実行可能。

一見Fargate起動タイプのがメリットが大きいように見えるが、スマートフォンゲームの利用用途では瞬時にスケール出来る性能が必要と判断。
イメージキャッシュを有効活用でき、スケール性能が高いためEC2起動タイプを採用した。

コンテナ導入での課題

今回は初のコンテナ導入となるため、以下の課題が出てきた。

• コンテナ・Docker・Amazon ECSの教育
  インフラメンバーはもちろん、開発メンバーへの教育も必要。しかし資料準備する時間が無かった。 そこで、AWSJのSAの方を講師に招き「コンテナDojo」として座学とハンズオンで社内セミナーを実施頂いた。

• ビルド&デプロイ
  今まではコードのデプロイには「Capistrano」を使用していたが、今後はコンテナイメージをデプロイする方法を検討する必要があった。
  色々なツールを検討した結果、パイプライン管理をJenkinsとして以下のような構成でデプロイを運用している。
  本作ではBlue/Greenデプロイを採用している。

• キャパシティ設計
  ECSでEC2起動タイプを選択した場合、タスクあたりのコンテナ数やコンテナあたりのCPU、メモリの割り当て、EC2のインスタンスファミリー、サイズ、台数の選定を検討する必要がある。
  大きいインスタンスに多くのタスクを立ち上げると障害時の影響が大きくなり、小さいインスタンスを多く立ち上げると管理が困難となるため、トレードオフが必要。

キャパシティ設計には各種リソースを色々な組み合わせで単体の負荷試験を実施し、パフォーマンスを測定して最適解を導き出した。

負荷試験にはPython製のツールである「Locust」を利用。
Locust実行環境（負荷をかける側の環境）にはECS Fargate起動タイプを採用して多くのタスクを同時並列実行して負荷をかけている。
WEB/APIサーバへの負荷試験となるため、別AWSアカウントからインターネット経由で負荷をかけている。

負荷試験のやり方は最小構成での機能単位で実施。
メトリクスはCloudWatch、Datadog、New Relicで確認し、処理件数や処理時間、CPU負荷で比較を行った。

リリース時の構成

負荷試験の結果を元にキャパシティを選定、事前登録者数70万人が来ても大丈夫なようにかなり余裕を持って設計している。

• APIサーバ
  • EC2インスタンス(c5.4xlarge x81台)
    インスタンス1台あたり5タスク(APIサービスタスク x4 , Datadogエージェントタスク x1)
    APIサービス1タスクあたり6コンテナ(Rails x5 , Nginx x1)
    Railsコンテナは合計 1620個 稼働
• データベース(RDS Aurora)
  • UserDB(db.r5.4xlarge x20台)
    10シャードで水平分散、1ClutserはMaster/Replica構成

  • MasterDB(db.r5.4xlarge x2台)
    Master/Replica構成

• キャッシュサーバ(ElastiCache)

  • Memcached(cache.r5.2xlarge x3台)
  • Redis(cache.r5.large x2台)

現在は既にタイプの見直しを行い、リザーブドインスタンスの活用してコストの見直しを行っている。

リリース時とその後

2020/3/15 15:00に告知無しのサイレントリリース。
大きな不具合が出ていないことを確認できてから告知をしたかったため、ユーザへの告知は20:00に実施。

15:00にリリース。
17:20に最大ピーク(秒間1万リクエスト、この倍のリクエストを想定していたためリソースには余裕があったとのこと。)
20:00にリリース告知を行い、二度目の山。

リリース直後、NewRelicを使用してアプリケーションの処理時間をモニタリングしたところ概ね70ms以内にサーバ側の処理が完了している。
コンテナに移行して大きく処理が遅くなる、といったことは無かった。

リリース後もサービスに影響を与える大きな不具合の発生なく、ほぼノートラブルでリリース作業を終えることが出来た。

コンテナ化の効果

• 環境構築が容易になった。
  現在は既に数分で構築できるようになった。

• 環境依存の不具合
  環境の設定差異による不具合は今は見られない。

• オートヒーリング
  オーケストレーションにもよるが、ECSは設定したタスク数を維持してくれるためアラートが発生してもすぐ復旧してくれる。

まとめ

学習コストの低いAmazon ECSはコンテナ導入の第一歩として最適なサービスの一つ。
導入時に検討が必要な点や既存設定から変更しなければならない点も少なくないが、得られるメリットが大きい。

最後に

Happy Elements様の『あんさぶるスターズ！！Music』のコンテナ導入事例に関するセッションでした。コンテナ導入に対する課題やキャパシティの選定、リリース時の負荷状況等非常に貴重な情報が盛りだくさんのセッションになっていると思います。
AWSでのコンテナ活用に関するセッションは今回のAWS Summit Online 2020でも多く取り扱われていますので、気になる方はどんどんセッションを見てみましょう！