AWSのECS on FargateのARM化によるコスト最適化〜調査・計画・移行、そして本番で起きた課題〜

こんにちは。スマートバンクSREの@uehiraです！

SREチームはサービスの成長につれて増えていくインフラコストを最適化することをミッションとしており、当記事ではコスト最適化の一環として、我々が管理するクラウドリソースをX86ベースのプロセッサからARMベースのプロセッサに切り替えた試みについてご紹介します。

前提として、スマートバンクが提供する家計簿アプリB/43ではインフラ基盤としてAWSを採用していますので、本記事の内容はB/43のインフラ基盤の一部をGravitonへ移行した話となります。

なお、FinTechスタートアップとしてのAWSインフラ設計については以下の記事にまとめているのでぜひご覧ください！

blog.smartbank.co.jp

背景

初めになぜプロセッサを切り替えることにしたのか、背景を簡単に説明いたします。

コスト最適化をミッションとして持つSREチーム

冒頭に書いた通り、スマートバンクのSREチームはサイトの安定稼働だけではなくコストの最適化をミッションの1つとしています。

スマートバンク社内ではOKRを運用しており各チーム内で目標を設定しています。前年度の目標設定の際に「コスト削減もっとできるのでは？」と私が提案したところ、経営陣がすごい勢いで食いついたためチームOKRにコスト最適化を組み込むことになりました。（スタートアップとしては大事なことです）

ARMベースのプロセッサへ移行するメリット

コスト削減

ARMベースのプロセッサが高効率・低コストであることは知られていますが、クラウドインフラでどのような効果があるのかは2023年前半では弊社内では未知数でした。あるときSREチームのEMである@maaaatoが前職で同じチームだった @vvvatanabe さんと話していたところ「ARM化でコスト削減できたからおすすめだよ！」と聞き、それだけ効果があるならミッションに紐づくことなのでぜひやってみようという流れになりました。@vvvatanabe さん感謝です！

vvvatanabe さんのコスト削減の話は資料が公開されていたので記載しておきます。

speakerdeck.com

開発環境と本番環境の差異を減らす

2023年以降スマートバンクのエンジニアの開発環境はM1以降のmacOSで統一しています。（プライベートではWindowsやLinuxを使うエンジニアもおりますが、機器管理上の都合などによります。この話もいずれどこかで）

AppleシリコンもARMベースであり、ローカル開発環境・ステージング環境・本番環境すべてのCPUアーキテクチャが統一できるメリットもあると考えました。

調査・計画

ここから実際の切り替えに関する話をしていきます。なお、我々が移行した時期は2023年の9月〜12月あたりのため、記事を公開する2024年9月時点ではやや古い情報があるかもしれません。ご容赦ください。

さて、ARMベースのプロセッサに切り替えるにあたりまずは調査・計画から始めました。本番で切り替え可能だと自信を持てるようになることがゴールです。

ARMに切り替える手順の調査
コスト削減幅の見積もり
影響範囲の調査
本番の切り替え計画を立てる

ARMに切り替える手順の調査

docs.aws.amazon.com

  runtime_platform {
    cpu_architecture = "ARM64"
  }

これをかくだけなので、意外に簡単でした。(terraform書式)

コスト削減幅の見積もり

aws.amazon.com

1時間あたりのUSD

アーキテクチャ	CPU	MEM	合計
X86	0.05056	0.00553	0.05609
ARM	0.04045	0.00442	0.04487

約20%削減可能であることがわかり、更に削減したい場合はリザーブドすることも可能でした。

アプリケーションの影響範囲調査

理想的には社内で管理するすべてのクラウドリソースをGravitonにしたいと考えましたが、場合によっては切り替えられないかもしれません。まずは対象を洗い出し、切り替え可否を選定しました。

ECS Fargateで実行されるWebアプリケーションサーバー
- ステージング環境
- 本番環境
Aurora
- ステージング環境
- 本番環境
セルフホストしてるAirflow
- AirflowバージョンをあげないとARM対応イメージがなかった
BIツールとしてのRedash
- 公式がARMイメージをサポートしてない、配布していなかった
- 自前でビルドしないといけないので運用が煩雑になる

ちなみにB/43システムのコンポーネントは以下のようになっています。詳細は省略しますが、複数のWebアプリケーションサーバーの移行が必要だということが伝わればと思います。

さらに詳しい情報は https://smartbank.co.jp/recruit/engineer-summary をご参照ください。

ECS on Fargate と ECS on EC2 の差分

それぞれのWebアプリケーションサービスの本番環境はすべてECS on Fargateなのですが、一部のステージング環境では一部ECS on EC2上で動かしています。ECS on Fargateの場合は切り替えがタスク定義のみの修正なので楽なのですが、ECS on EC2 の場合はコンテナを動作させるHOSTのEC2も切り替えが必要になるため考慮しなければなりません。

社内のステージング環境で切り替えテスト

切り替え手順自体は難しくないことがわかったので、社内のステージング環境で切り替えたあとのアプリケーションが動くか？などの検証を始めました。機能として壊れるものはなかったのですが、Railsアプリでライブラリインストール（bundle install）が遅くなる事象が見つかりました。

Gemまわりだったので、サーバーサイドエンジニアと一緒に調査しました。どうやらgrpcのGemのコンパイルで遅いまでわかったのですが、原因まではわからずでした。

dockerのイメージビルドにてキャッシュを使って早くすることにしました。

本番の切り替え計画を立てる

本番で両方のイメージのインスタンスが立ち上がっている状態にして、すぐに切り戻せるようにしましたまず、現状のX86とARMのdocker imageを共存させてどちらからでも起動できる状態にしました。

X86のimageをpush

docker push $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/test-image:latest-amd64

ARMのimageをpush

docker push $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/test-image:latest-arm64

上記のそれぞれをmanifestで紐づける

docker manifest create $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/test-image:latest $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/test-image:latest-amd64 $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/test-image:latest-arm64

こうすることでdocker pullするクライアントがアーキテクチャを判断し対象のimageをpullしてくれます。この状態でX86の起動は問題ないことを担保しました。また、本番環境以外のEC2のlaunch configを修正し、全部書き換えではなくARMを追加する形で実施しEC2を入れ替えます。残るは本番の切り替えですが、以下の3行を追加し、deployするのみの状態にしました。

タスクは3行の変更だけでOK

runtime_platform {
     cpu_architecture = "ARM64"
}

切り替えが問題なく、3ヶ月ほど動作してアプリケーションに問題がなければX86のイメージを掃除します。

移行

実際に作業するときdevチャンネルで連絡した上で作業 しました。

事前の手順にしたがって移行を実施しました。

taskのアーキテクチャを変えてapplyするだけにした
- 立ち上がったコンテナは自分がARMだと認識してるので、ARMイメージを取得して起動してきます
- その後、codedeployからデプロイします
メンテナンス入れずに有事の際は全社の協力が得られることから日中に実施しました。
安全のためアプリケーション1つずつ切り替えを実施しました
- 一日で多数のアプリケーションの切り替えを実施すると、有事の際どこで問題が発生しているか切り分けにくくなるためです
それぞれ当日は問題なく移行できました

移行後におきたこと

問題

ARM化したあとの社内のパフォーマンス確認定例で問題がわかりました。もう少し深ぼって調べたところ、レイテンシーavgが下がっていることがわかりました。

タイミング的にARM化が疑わしかったため、問題切り分けでARM化を戻したらすぐに改善したので原因が明らかでした。

対処

戻すのは簡単だったのでX86に戻しました 事前に準備していたとおり切り戻しました。切り戻しできる状態で切り替えを実施したので、良かったと思います。

しかしながら、この問題は未解決です…

結果

コスト削減幅
- 結果、約20%削減となりました
- AWSアカウント全体の料金から見ると、ARM化と同時にコストが増えるような別の変更やユーザーアクセスの増加などで、単純に前月比で20%削減したとは見えない
terraformのコード掃除
- 3ヶ月様子をみて問題ないと判断して掃除した
未解決問題
- RubyでARMイメージを使った際に性能劣化した事例があれば教えてください...