AWS Fargateを活用してコスト削減するには #AWSreInvent

こんにちは。ゲームソリューション部の出村です。

AWS re:Invent 2023のセッションである「Boosting efficiency: How to realize 70% cost reduction with AWS Fargate」のレポートをお届けします。

セッション概要

''' In this session, discover how a leading enterprise SaaS company, using AWS Fargate and AWS Graviton, transformed their data-intensive grid service. Learn how they achieved 70% cost reduction within 6 months, grew peak traffic from 1,000 RPS to 50,000 RPS, and increased deployment velocity from once weekly to twice daily using AWS CodePipeline. Explore their cell-based architecture strategies for improved scalability and efficiency. '''

スピーカー

• Steven Follis : AWS
• Skylar Graika : Smartsheet

内容について

このセッションでは、AWS Fargateを採用した企業（Smartsheet）がどのようにコスト削減を進めていったかについての話がメインでした。

AWS Fargateを採用したら即コスト削減できたという単純な話ではなく、それに行き着くまでにいろいろ試行錯誤があったことがよく分かるセッションでした。

AWS Fargateとは

最初はAWS Fargateの特徴についての説明でした。サーバーレスなのでオペレーションがシンプルになる、手動で行う事がEC2に較べて減るのでより安全になる、利用料金は使った分だけ掛かります、といったこれまでにあった説明から始まりました。

Smartsheetでの方針

次にSmartsheetの方からサービスの紹介と今回のメインであるコスト削減した方針についての話がありました。キーワードはOptimize、Propel、Scaleです。これらのキーワードの詳細について順に触れていきます。

Optimize

Optimize（最適化）についてです。こちらはコストの最適化といった意味です。

CPUはGraviton2プロセッサを利用する、サービス（機能）に特化したサーバー構成にする、といった具合です。CPU数やメモリは、利用状況にあわせて増減する設定となっています。

オンプレミスから現在のFargateを利用した構成になるまでさまざまな対策が行われてきましたが、その都度で、トランザクション単位のコストが下がり使われる量が増えました。

コストの最適化は、きちんとAWSの料金を理解した上で最適なオートスケールを設定し、レガシーなサービスを取り除くことで進めていきました。

Propel

Propel（推進）についてみていきます。こちらは、技術よりは組織としてどのように変えていったかを解説されていました。

こちらは、CodePipeline + Fargateに最適な形に進めていきました。

メンテナンスではなく自動化すること、複雑からシンプルへ、メンテナンスではなく自動化へ、決まったSREがいる組織からT型エンジニアがいる組織へと変化していきました

今回のサービスでは、Terraformを利用した自動化を行いセルベースのアーキテクチャで構成されています。セルベースについては、[レポート] Cell-Basedアーキテクチャでblast radiusを縮小 #reinvent #ARC411 | DevelopersIOで解説されているので、そちらを参考にしてください。

デプロイ環境はGitLabを利用したCI/CD環境で構成されており、ECR、CodePipeline〜CodeDeployを通じてFagateでデプロイされています。

シンプルな構成し、マネージドサービスに移行するといった事を進めていきました。

Scale

最後にScale（拡張）をみていきます。こちらは、より多くのリクエストに対応できるように進められていきました。

最適なアーキテクチャのデザインパターンの採用、パフォーマンスのモニタリングなどで、その時のリクエスト状況に合わせた対応ができるようになっています。あと、セルベースアーキテクチャについても詳しく触れられていました。

状況予測を予測し、厳しい負荷テストなどを行うことで拡張性を担保しました。

所感

Fargateといった技術の採用だけではなく、それにあわせてエンジニア採用の方針を変更したり、人材の所属まで変えてしまうという事例はみたことがなかったので、とても新鮮でした。このような方針も、これまでの試行錯誤の中で生まれた結果であり、今後よりよい技術が登場した際にも、それにあわせて対応できる組織だろうとも感じました。このような変化に柔軟に対応できる組織は強いですね。