『あんさんぶるスターズ！！』新作アプリをコンテナ化してわかったこと　学習コストの低いAmazon ECS導入プロセスとその結果

人気ゲーム『あんさんぶるスターズ！！Music』のコンテナ化

鷲見啓志氏：それでは「『あんさんぶるスターズ！！Music』を支える Amazon ECS ～人気ゲームの新作でのコンテナ化～」というタイトルで、Happy Elementsの鷲見が発表させていただきます。本日はよろしくお願いいたします。

それではさっそくですが、内容に入らせていただきます。発表に先立ちまして、今回の発表で使うAWSサービスの略称の一覧となります。今回は触れる技術も多いため、あらかじめこちらで用語を統一させていただきます。

それでは自己紹介です。鷲見啓志と申します。2019年1月より、Happy Elements株式会社に勤務しております。

インフラエンジニアのチームのリーダーをしておりまして、主な業務は複数のゲームタイトルのインフラの運用と、導入支援を行っております。趣味は自転車で、休日は大阪・北摂の山の中でもがいております。AWS利用歴は10年、好きなAWSサービスはAuroraとなります。

次に、私の所属する会社の紹介です。Happy Elements株式会社と申します。

北京を拠点にアジア圏でゲームサービスを展開する、Happy Elementsグループの日本子会社となっております。日本市場に向けたオリジナルゲームの開発・運営を行っています。開発拠点は京都の四条烏丸にあり、240名のスタッフが日々、スマートフォンゲームの開発・運営にいそしんでおります。

現在、提供しているタイトルの代表的なものとしては『あんさんぶるスターズ！！Basic／Music』『メルクストーリア』『ラストピリオド』といったタイトルとなります。

コンテナ導入以前の課題からリリース後まで

それではセッションの中身に入る前に、今日お話しする内容について、あらかじめ紹介していきたいと思います。

2020年3月15日にリリースした『あんさんぶるスターズ！！Music』のECSでのコンテナ化にフォーカスを当て、コンテナ導入の経緯、技術選定、直面した課題、リリース時の様子についてご紹介いたします。

本日紹介していく流れですが、まずコンテナの導入以前に抱えていた課題について。次に、コンテナの導入と技術選定について。次に、コンテナの導入で直面した課題と解決方法について。最後に、リリース時の様子とその後についてお話ししていきます。

後半、リリース時の構成やリリース時の状況について、かなり具体的な情報を共有いたしますので、最後までご覧いただけますと幸いです。

また今回想定している聴講者は、コンテナやECSの導入をこれから検討したいと考えている技術選定の担当者・責任者、またこれから始める、もしくは進行中のインフラエンジニアの方を想定しております。

『あんさんぶるスターズ！！』シリーズの魅力

今回の対象となるゲーム『あんさんぶるスターズ！！』について紹介させていただきます。2015年4月にリリースした男性アイドルの育成ゲーム『あんさんぶるスターズ！』は、総ダウンロード数300万件を超え、大変ご好評いただいている人気タイトルで、2019年にはアニメ化も行われました。この『あんさんぶるスターズ！』をリニューアルし、新章となるアプリを2つ、2020年の3月にリリースしました。

1つは『あんさんぶるスターズ！！Basic』。こちらは旧タイトルのリニューアル版で、従来のプレイスタイルで遊んでいただけるゲームとなっております。もう1つは『あんさんぶるスターズ！！Music』、こちらは新作のリズムゲームとなっております。今回お話しさせていただくのは、こちらの『Music』となります。ちなみにリニューアル前は『あんさんぶるスターズ』の後ろの「！」が1つでしたが、リニューアル後は「！」が2つとなっております。

『あんさんぶるスターズ！！Music』は、3Dキャラクターのライブシーンをバックにリズムゲームをプレイするスタイルのゲームとなっております。自分の好きなキャラクターへの入れ替えや、衣装の着せ替えも可能になっています。

この『あんさんぶるスターズ！！Music』ですが、どのぐらい遊ばれているタイトルかといいますと、リリース前の事前登録者数は70万人、リリース当日のダウンロード数は140万件となっております。

また4月10日にTwitter社のブログで公開された記事では「世界中で今年最もツイートされたゲーム」のトップ10に入れていただいております。こちらをご覧いただけると、大変ご好評いただいている人気タイトルだということがおわかりいただけるかと思います。

リニューアル前後の技術構成比較

それではこの『あんさんぶるスターズ！！Music』。どのような技術で動いているのか、技術構成について説明していきたいと思います。

『あんさんぶるスターズ！！Music』の全体の技術スタックはこのようになっております。サーバーサイドの言語はRubyが2.6で、フレームワークとしてはRailsの6.0で動いており、これらがAWSのサービス群を利用し稼働しております。

サーバーサイドのアーキテクチャはこのようになっております。まずスマートフォンからのアクセスをCloudFrontで受け取り、その後ろのALBで負荷分散を行います。負荷分散を行われた先はEC2起動タイプのECSとなっており、この上でRuby on Railsが動いております。

またバックエンドでは、ユーザーのデータを扱うデータベースとしてシャーディングで水平分散したAuroraが、ゲームのマスターデータを扱うデータベースとしてシャーディングなしのAurora。またキャッシュサーバーとしてElastiCacheのRedisとmemcachedが、それぞれ稼働しております。

それではここから、リニューアル前にどのような課題を抱えていたのか、リニューアル前の「！」1つの『あんさんぶるスターズ！』がどのような環境で動いていたのかと一緒に、説明していきたいと思います。

リニューアル前の「！」1つの『あんさんぶるスターズ！』は、このようなアーキテクチャで動いておりました。オンプレミスのデータセンター上で物理サーバーが稼働しており、Ruby2.2.9、Rails4.1.10と、少し古い環境で稼働しておりました。

データストアとしてはユーザーのデータをCassandraで、マスターデータはMySQLで、キャッシュサーバーとしてはRedis・memcachedを利用しておりました。

2019年時点でサービスを提供しているゲームタイトルのAPIサーバについては、オンプレミスのデータセンター上で稼働しておりました。

オンプレミス時代の3つの課題

この時代に抱えていた課題は大きく3つ。1つ目は「スケールしない環境・リソースの無駄遣い」。2つ目は「技術的負債」。3つ目は「時間のかかる環境構築」という、大きく3つの課題がありました。それぞれ詳しく見ていきたいと思います。

まず1つ目は「スケールしない環境・リソースの無駄遣い」という課題です。オンプレミスのデータセンターの物理サーバー上でサービスが動いている環境でしたので、サーバーの増減をすぐに行うことができないというデメリットがありました。サーバーの調達には2週間のリードタイムがかかります。そのため想定外の突発的なスパイクが発生した場合、それに対応することができません。

また弊社のゲームでは、ゲーム内のイベントの開始・終了のタイミングにアクセスが集中します。アクセス集中時の負荷に合わせでサーバを準備しているため、イベントの開始・終了時以外のアクセスの少ない時期はサーバーが遊んでいる状況で、リソースを無駄に使っているという課題がありました。

次に2つ目の「技術的負債」という課題ですが、ユーザーファーストを重視する社風により技術的負債が蓄積していったという経緯があります。ユーザーに楽しんでもらうことを重視し、ゲームへのコンテンツ・機能の追加を最優先にしていった結果、インフラ・ミドルウェアのメンテナンス、新しい要素技術の導入などは後回しになっていきました。

後回しになったのはいいんですけれども、機能・コンテンツの追加のほうが優先度が高いため、いつまで経っても返済に着手することができません。結果として技術的負債を返す時間を確保できないまま、負債が蓄積していきました。RubyやRailsのバージョンが少し古かったのも、このような経緯です。

最後は「時間のかかる環境構築」という課題です。開発環境の構築に時間がかかる上に、複数タイトルを動かすような場合にはローカル環境にミドルウェアが複数バージョン同居し、環境の切り替えを意識する必要が出てくるといった問題点がありました。環境構築については、環境構築の開始から完了まで半日から1日かかっておりました。

これら抱えていた課題を解決するため、オンプレミスからクラウド環境への移行を決定し、その移行先にAWSを選択しました。その中で今回、なぜコンテナ化を進めていくことになったのか、コンテナ化を推し進めた理由についてお話しいたします。

コンテナ導入を決めた3つの理由とその結果

今回コンテナ化を進めた理由としては、1つ目は「環境構築と管理の容易さ」、2つ目は「可搬性の確保と環境差異の排除」、3つ目は「技術的負債の返済」。この3つの点から考慮した結果となります。

まずは「環境構築と管理の容易さ」という点ですが、コンテナを使うことで得られるメリットとして、環境構築の容易さという点があります。Dockerをインストールして数コマンドで構築が完了するという点は、非常に魅力的でした。

また環境管理の容易さという点ですが、こちら、人やPCによる環境差異がなくなります。ローカル環境でミドルウェアが複数バージョン必要となるようなケースでも、必要なタイミングにのみコンテナを起動するだけとなり、ローカル環境の管理が容易になります。

さらにInfrastructure as Codeの実現というところで、プロビジョニングからアプリケーションまでDockerファイルで設定ができます。Dockerファイルを見れば誰でも構成がわかりますし、同じ構成で環境を作ることができます。こういったコンテナのメリットに魅力を感じたというのが、まず1つとなります。

2つ目の「可搬性・環境差異の排除」についてですが、可搬性についてはLinuxコンテナであれば、Dockerコンテナが動く環境ならどこでも動きます。もちろんほかのクラウドベンダーでもオンプレミスでも、Dockerさえ動けば動かすことができます。最悪移行に失敗した場合も、切り戻しがしやすいのかなといった点がありました。

また環境間の差異の排除につきましては、可搬性があるのでどの環境でも同じイメージで動かすことができます。ローカル、開発、ステージング、本番といった環境ごとのインフラ設定の差異がなくなり、環境依存の不具合が発生しづらくなります。どの環境でも動く一貫性が保証されます。こういったコンテナの持つメリットにも魅力を感じました。

最後の「技術的負債の返済」という点につきましては、今回はクラウド移行のタイミングでちょうど新技術採用のチャンスでした。今までの技術的負債を返済して、一歩前に進みたい。ただ、今からEC2で従来のオンプレミス環境と同様の使い方をしていたのでは、またすぐ負債が溜まっていく未来が見えてしまいます。このタイミングで、今回はフルマネージドサービスの活用と、一歩進んでコンテナの採用へと進みたい。そのように考えました。

これら3つの理由から、コンテナの導入を決意しました。なおコンテナ導入で、抱えていた課題のうち「技術的負債」「時間のかかる環境構築」が解決できます。ちなみにもう1つの「スケールしない環境」という課題については、AWSへ移行を決めた時点で解決することができております。

『あんさんぶるスターズ！！Music』に使用したコンテナ技術の選定

では『あんさんぶるスターズ！！Music』では、どのコンテナ技術サービスを利用するような選択をしたのか。ここからはコンテナの技術選定についてお話ししたいと思います。

AWSには2つのコンテナオーケストレーションのサービスがあります。1つはAmazon ECS、もう1つはAmazon EKSです。

1つ目はAmazon ECS、正式な名前は「Amazon Elastic Container Service」です。AWSが開発・運用しているAWSネイティブなコンテナオーケストレーションサービスです。

2つ目はAmazon EKS、正式な名前は「Amazon Elastic Kubernetes Service」です。OSSのコンテナオーケストレーションツールのデファクトと言われているKubernetesを、AWSでマネージドサービスとして提供しているサービスとなります。

どちらもコントロールプレーンはAWSが管理してくれます。ちなみにコンテナオーケストレーションツールについては、弊社でもお世話になっているソリューションアーキテクトの濵さんのセッションで詳しく解説されているそうなので、ぜひそちらもご覧ください。

改めての確認となりますが『あんさんぶるスターズ！！Music』ではECSを採用しております。ではなぜECSを選択したのか、その理由について説明していきたいと思います。

運用管理・学習教育コストが抑えられるAmazon ECS

Amazon ECSを選んだ理由ですが「Amazon EKSと比べて運用管理・学習教育コストが抑えられる」といった理由となります。

ECSもコンテナオーケストレーションのサービスですので概念はやや複雑ですが、EKSはさらに複雑になります。そもそもベースとなるKubernetesが、覚えないといけない概念も多い上に複雑に関連しあっていて、かなり複雑になっています。運用にはKubernetesに対する深い理解が必要となります。その点ECSは、EKSと比べるとかなりシンプルになっております。

EKSを採用するのであれば、Kubernetesに詳しいエンジニアが複数人必要であると判断しました。ECSの場合も学習することは必要ですが、今いるエンジニアが学ぶことで対応可能と判断しました。このような結果、よりシンプルで運用管理・学習教育コストが抑えられる、ECSを採用することに決めました。

コンテナ起動の環境と起動タイプの考え方

ECSを採用することにした場合もう1つ考えないといけないのが、コンテナが起動する環境、起動タイプとなります。

ECSでは2つの起動タイプが準備されています。1つはEC2起動タイプ、もう1つはFargate起動タイプです。こちらの採用について見ていきたいと思います。

EC2起動タイプは、管理しているEC2インスタンスのクラスターで、コンテナ化されたアプリケーションを実行することができます。EC2インスタンスの管理は自分で行う必要があります。もう1つのFargate機能タイプ、こちらはバックエンドインフラストラクチャーをプロビジョニング及び管理することなく、コンテナ化されたアプリケーションを実行できます。コンテナが起動するバックエンドのインフラも自動で設定管理してくれますので、EC2インスタンスの管理は必要ありません。

一見するとFargateのほうがメリットも多く良いように感じられるんですけれども、スマートフォンゲームの運用ではイベントの開始時などに急なスパイクが立つことが多く、必要に応じ瞬時にスケールアウトできるスケール性能が求められます。この点、EC2起動タイプはイメージキャッシュを有効活用でき、スケール速度を出すことができるという特性があり、スマートフォンゲームの運用ではEC2起動タイプのほうが合致すると判断し、今回はEC2起動タイプを採用しました。

なおイメージキャッシュについては、昨年AWSジャパンの大阪オフィスで開催された「Container Night」というイベントでお話しさせていただきましたので、そちらの資料もよろしければご覧ください。

というわけで『あんさんぶるスターズ！！Music』のコンテナは、ECSによるオーケストレーションのもと、EC2起動タイプで動いております。

「ECSをEC2起動タイプで動かす」という判断を下しましたので、その後はECSでのコンテナの導入を進めていくことになります。導入を進めていく中で、いくつかの課題が出てきました。ここからは導入時に出てきた課題と、その解決についてご紹介していきたいと思います。

新技術の教育とビルド＆デプロイ

今回が初の本格的なコンテナの導入ということで、以下の課題が出てきました。

1つ目は「コンテナ・Docker・ECSの教育」、2つ目は「ビルド＆デプロイ」、3つ目は「キャパシティ設計」となります。

1つ目の課題は「コンテナ・Docker・ECSの教育」です。インフラエンジニアが学習するのは当然なんですけれども、実際にアプリケーションの開発を行うエンジニアにも、コンテナ・Docker・ECSの概念や使い方を理解してもらわないといけません。

とはいえ自分たちもまだ学習したばかりですし、資料を準備するような時間もありませんでした。「さあ、どうしよう」ということになりましたが、この課題にどう対処したのかといいますと、AWSジャパンのソリューションアーキテクトの方を講師にお招きし「コンテナDojo」というタイトルで座学とハンズオンの社内セミナーを実施しました。

ソリューションアーキテクトの濵さん・藤原さんにコンテナの基礎からECSの概念、動かし方までみっちり教えていただき、開発メンバーも基本的なところを理解することができました。濵さん・藤原さん、ありがとうございました。

2つ目の課題は「ビルド＆デプロイ」となります。今まではコードのデプロイを、Capistranoというツールを利用して行っておりました。しかし今後はデプロイ対象がコードからコンテナイメージに変わります。Capistranoに変わるデプロイ方法を検討しなければいけません。

こちらについてはいろいろなツールを検討し試していった結果、このような構成に落ち着きました。

パイプラインの管理はJenkins、ソースコードの管理はGitHub、ビルドツールはCodeBuild、イメージの管理はECR、デプロイツールはCodeDeployを利用しております。それでは実際のビルドの処理の流れを説明していきます。

まずゲームタイトルの運用メンバーが、Jenkinsに対してデプロイの指示を出します。JenkinsはCodeBuildに対してビルドの指示を出します。ビルドの指示を受けたCodeBuildはGitHubからコードを取得しDockerイメージを生成、ECRにDockerイメージを登録します。その後JenkinsはCodeDeployに対してデプロイの指示を出します。指示を受けたCodeDeployはECRからイメージを取得、ECSにイメージのデプロイを行います。

今回はBlue／Greenデプロイを採用しておりますので、この段階ではまだデプロイは完了しておりません。その後運用メンバーが確認を行い、Jenkinsにデプロイの承認を指示します。指示を受けたJenkinsは、CodeDeployに対してトラフィックの切り替えの指示を出します。CodeDeployはECSに対してトラフィックの切り替えを行います。この段階でBlue／Greenの切り替えが行われ、ビルド＆デプロイが完了ということになります。これがビルドからデプロイまでの一連の流れとなっております。

リソースキャパシティの考え方

では、次にまいります。3つ目の課題ですが、「キャパシティ設計」となります。ECSとEC2起動タイプを選択した場合、EC2を含め各種リソースのキャパシティを検討する必要があります。

ここで軽く、ECSで扱う概念を説明しておきますと、ECSでは「クラスター」というのが一番大きな概念で、この中で「サービス」と「タスク」が稼働しています。サービスはどのタスクをいくつ動かし、どのロードバランサーと関連付けるなどの、タスクを束ねて管理する考え方になります。

またタスクはタスク定義に基づき、Dockerコンテナを束ねて管理する考え方です。またEC2起動タイプの場合は、クラスター内でコンテナインスタンスが稼働します。デプロイはタスク単位で行われ、EC2インスタンス上にタスク単位でコンテナが配備されていきます。

このような考え方のため、タスクあたりのコンテナ数をいくつにするのか、コンテナあたりのCPU・メモリをいくつにするのか。またインスタンスあたりのタスク数をいくつにするのか、インスタンスのインスタンスファミリー・サイズ・台数をどうするのかといった、リソースキャパシティを考える必要が出てきます。

強いインスタンスに多くのタスクを搭載することもできますが、障害時の影響範囲が大きくなります。またタスクの少ない弱めのインスタンスをいっぱい立ち上げるといったこともできますが、その場合インスタンスの管理の手間がかかります。このようなトレードオフも考えながら検討していく必要があります。

ワークロードによってもリソースの使用状況が異なるため、たった一つの正解というものは存在しません。インスタンスファミリー・サイズ・タスク数・コンテナ数・コンテナへのCPUとメモリの割り当てなど、いろいろ組み合わせて単体の負荷試験を実施し、パフォーマンスを測定。結果として出てきたパフォーマンス数値を比較し最適解を導き出すといった、地道な方法でキャパシティ設計を行いました。

それではここから、負荷試験とキャパシティ設計について、もう少し詳しく見ていきたいと思います。

負荷試験とキャパシティの設計

負荷試験ツールにはLocustを利用しております。こちらPythonで作られた負荷試験ツールで、Pythonのコードでテストシナリオを書くことができます。このLocustを動かす、負荷試験をかける側の環境もECSで動いており、こちらはFargate起動タイプを採用しております。

コンテナイメージを事前に作成し、多くのタスクを同時並列実行し負荷をかけていきます。今回はWeb APIサーバーへの負荷試験なので、インターネットを経由する必要があり、別のAWSアカウントでこの環境を準備しております。

今回Fargateを使っておりますので、EC2の起動停止などの必要がなく、いつでも必要なタスクを上限まで使うことができ、大量のタスクを並行実行するのにとても便利に使わせていただきました。

こちら、図にするとこのようなイメージになります。Locustが稼働するコンテナを搭載しているタスクを複数並列で実行し、インターネット経由で対象に負荷をかけていくといったイメージになります。

で、実施している負荷試験については、最小構成での機能単位の負荷試験となります。ここでの主な目的はパフォーマンスの測定となります。

今回はキャパシティ設計のため、同じイメージとテストシナリオでインスタンスタイプ・サイズ・タスク数・コンテナ数・CPUとメモリの割り当ての組み合わせを変えて、パフォーマンスを測定しております。

こちら実際の画面のサンプルですが、Locustで負荷をかけメトリクスをCloudWatchやDatadog、New Relicで確認します。比較に使ったのは処理件数や処理時間、CPUの利用率などのメトリクスとなります。これらのメトリクスを比較検討していきました。

リリース時の全体構成

パフォーマンスの比較検討によるキャパシティ設計の結果、リリース時にどのような構成になったのか、ここからお伝えしていきたいと思います。ほかではあまり見たことのない具体的な数値・情報をお出ししますので、今回の目玉の1つなのかなと思っております。よくご覧ください。ちなみに事前登録の70万人のユーザーが来ても絶対に落ちないようにという考えで、かなり余裕をもった構成になっております。

APIサーバーはここまでお伝えしてきたとおり、EC2起動タイプのECSで動いております。EC2インスタンスにはc5.4xlargeを81台準備しております。インスタンス1台あたりのタスク数は5つ、APIのサービスが4つと、監視用のDatadogエージェントのタスクを1つ設定しています。

またタスクあたりのコンテナ数ですが、メインとなるAPIサービスのタスク1つあたりのコンテナ数は6個。6コンテナを動かすようにしており、Railsのコンテナが5つ、Nginxのコンテナが1つ動くようになっております。Railsのコンテナは合計1,620個動くような設定になっております。

また今回のキャパシティ設計の結果で、データベースやキャッシュサーバーの構成も決定しております。ユーザーのデータを扱うデータベースのAuroraにつきましては、db.r5.4xlargeを20台準備しています。こちら10シャードで水平分散し、それぞれマスターとレプリカが1つずつの構成となっております。またゲームのマスターデータを扱うデータベースのAuroraは、db.r5.4xlargeを2台で動かしています。シャーディングなしのマスターとレプリカ、1つずつの構成となっております。

キャッシュサーバーについてはElastiCacheのmemcachedとRedisを使っており、memcachedはcache.r5.2xlargeを3台、Redisはcache.r5.largeを2台の構成で動かしております。

これらをアーキテクチャの図にまとめますと、このようになります。この構成でリリース直後に想定される最大のアクセスを迎え撃ちます。

なおリリース直後のアクセス数が最大となる時期は終わっておりますので、現在はタイプの見直し・台数の削減を行い、リザーブドインスタンスの購入やスポットインスタンスの活用でコスト削減対策も行っております。

不具合なくノートラブルで終わったリリース作業

それでは、想定するアクセス数をさばくためのキャパシティ設計も終わり、ユーザーを待ち受ける準備ができました。ここからはユーザーを待ち受けた当日の、リリースの状況もお見せしたいと思います。ここも数字などをお出ししていますので、よくご覧いただけると良いかと思います。

2020年3月15日、15時にリリースを行いました。大きな不具合が出ていないことを確認できてから告知したかったため、ユーザーへの告知は20時に実施しています。

こちらはリリース後のアクセス数の推移となります。15時にリリースを行い、一気にアクセス数が跳ね上がっていきます。17時20分に最大のピークを迎えます。この時で、秒間1万リクエストほどのアクセス数となりました。ちなみに想定していた数字はこの倍以上でしたので、まだだいぶ余裕がありました。

その後一旦下がり、リリース告知を行った20時に2度目の山を迎えます。この時は初回ほどのアクセスではありませんでした。リリース日を事前に告知していたため待ち構えていてくださったユーザーが多く、プレーできるようになったことがSNSで拡散していき、告知前にアクセス数の最大ピークを迎えました。意図せずアクセスが負荷分散された結果になったようです。

その後は日を追うごとにアクセス数は落ち着いていきました。というわけで想定していたリリース直後の最大アクセスは、問題なく乗り越えることができました。

こちらリリース後のアプリケーションモニタリング、New Relicの画面となります。アプリケーション側の処理で、サービス全体でどのぐらいの時間がかかっているのかを平均で出したものになりますが、おおむね70ミリ秒以内にサーバ側の処理が完了しており、特にコンテナにして遅いと感じることはありません。

リリース後、サービスに影響を与えるような大きな不具合もなく、パフォーマンスも問題ありませんでした。『あんさんぶるスターズ！！Music』のリリース作業は、ほぼノートラブルで終えることができました。このようなかたちで、人気ゲームの新作でのコンテナ化は成功のうちに終えることができました。

コンテナ導入後に実感した効果と課題

ここからは、コンテナの導入で実際に感じた効果と課題を軽く紹介いたします。

実際にコンテナを導入して感じている効果は、メリットは環境構築が容易になった点。やはり実際に環境構築が容易になり、現在は数分で構築できるようになっております。また環境間の差異がないこと。こちらについては今のところ、特定の環境でだけ発生するような環境依存の不具合というものは発生しておりません。

またオートヒーリングという点ですが、こちらにつきましてはオーケストレーションの効能となるかと思うんですけれども、基本的にECSが設定したタスク数を維持してくれるようになっています。タスクが不意に落ちてアラートが発生したような場合でも「見に行くともう復旧している」というような状況で、復旧に手間がかからないというのは効果の大きな1つなのかなと考えております。

またこちらはコンテナの導入時の課題というか、新しい技術を導入した際には当然発生することではありますが、新しく導入した技術に合わせて運用方法を変更する必要が出てきます。マイグレーションなどのタスクの実行方法、定時バッチ処理の実行方法、ログの運用方法、デプロイ方法の変更など、コンテナ環境でどう実施するかの検討は行う必要があります。

あとはコンテナ導入で出てきたAWSさんへの改善要望となりますが、今回ログドライバーとして利用しているCloudWatchLogsの改善をお願いしたいと思います。対象となるログが見づらく、また見付けづらいといった点がありますのでUIの改善をぜひお願いしたいのと、お値段が少しお高い。今回サービス別のコストのトップ5に入ってきておりますので、お安くなるようにぜひ費用面の見直しもお願いしたいと思います。

またFargateについても、イメージキャッシュが使えるようになれば導入を再検討したいと思いますので、Fargateでもイメージキャッシュが使えるようになってもらえればなと思っております。

Amazon ECSはコンテナ導入に最適なサービスの一つ

最後にまとめとなります。

『あんさんぶるスターズ！！Music』では、環境構築の容易さ、可搬性、技術的負債の返済を目的にコンテナを導入しました。今回はECSをEC2起動タイプで動かすという選択をしております。導入時にはメンバー教育、ビルド＆デプロイの変更、キャパシティ設計という問題が発生しました。

コンテナを導入し、パフォーマンスの問題や大きな障害などは発生しておりません。コンテナ化の効用として実感しているのは、環境構築の容易さ、環境間の差異がなくなるという点、オートヒーリングによる復旧の手間がなくなったという点になります。

シンプルで学習コストの低いAmazon ECSは、コンテナ導入の第一歩として最適なサービスの1つだと思います。導入時に検討が必要な点、変更しなければならない点も少なくはありませんが、得られるメリットも大きいです。

今回の『あんさんぶるスターズ！！Music』の導入事例が、みなさんのAmazon ECS導入の一助となりますと幸いです。

最後に1つ告知をさせてください。Happy Elements株式会社では、一緒に働いてくれるメンバーを募集中です。インフラエンジニア、データエンジニア、アプリプログラマー、サーバーサイドプログラマーなど、複数の職種で積極採用中です。熱狂的に愛されるコンテンツを私たちと一緒に作りたい熱意のある方、ぜひご応募お待ちしております。詳しくは採用サイトをご覧ください。

以上、Happy Elementsの鷲見が発表させていただきました。本日はご静聴ありがとうございました。