Qiita/Qiita Teamは元々EC2で動かしていたアプリケーションサーバーを、1年少々かけて以下のように徐々に変更していました。
- EC2(c5系) -> ECS on EC2(c7i系)
- ECS on EC2(c7i系) -> ECS on Fagrate(x86)
- ECS on Fagrate(x86) -> ECS on Fargate(Arm)
今回は最後のECS on Fagrate(x86) -> ECS on Fargate(Arm)についてのお話です。
(ECSへの移行は Qiita を ECS 化しました #ecspresso - Qiita にまとまっています)。
Arm移行の動機
Armに移行する同期は以下のようなものでした。
- 安い
- 料金表を見れば分かる通り、On demandで約20%、Savings Plansだと25%程度x86より安い
- レスポンスタイムに関して改善する可能性がある(それによってサーバー台数を減らせる可能性がある)
- 他社で改善した事例あり
- 悪化した例も存在したため、レスポンスタイムが悪化してないかは移行中常に監視していました
移行について
ECS化の時と同様に、検証環境でテストし、リクエスト比率を徐々に変更して本番環境をArmへ移行という手順を取りました。
やったこととしては、大まかに以下の通りです。
- armとx86両対応イメージを作る
- GitHub Actions に Arm64 ランナーが来たので Docker のマルチプラットフォームイメージをビルドしてみる を参考にx86/armどちらでも使えるイメージを作成し、ECRにアップしていました
- ecspressoを使ってarmで動作する用のECS Serviceとtask definitionを作成
- 従来の定義からplatformをArmと指定しただけのtask definitionを、現在動作しているものとは別で作成しました
- 新規でtarget groupを作成し、新しいECS taskはそちらを使うようにすることで後述するlbでのリクエスト切り替えを行えるようにしました
- lb listener ruleのweightを変更することで、徐々にリクエストをArmで動作するECS taskに移行する
安全に移行したい場合、ECS Serviceなども完全に分けて、別のtarget groupに紐つけて徐々にweightを変えてしまうのが一番早いと思います。lb listener ruleをterraformで管理している場合は、weightだけignoreしてコンソールやCUIから変えると良いでしょう。
移行した結果
移行した結果、具体的な数値はお見せできませんが、大体20％程度レスポンスタイムが改善しています。
また、レスポンスタイムの改善によりCPUの利用効率が良くなったのか、x86と同じautoscaling policyで動かしていたにもかかわらず、ピーク時間のサーバー台数も30%程度削減しています。これにより、当初見込んでいた額より多くのサーバー費用削減を行うことができました(画像はQiitaのサーバー台数の推移で、昼は多く、夜は少ないです)。
最後に副次的なメリットとして、spot instanceが確保しやすくなったというのがあります。
1月下旬からFaragte Spotの枯渇が発生しやすくなり、spot instanceを利用している一部環境でデプロイに失敗することもあったのですが、Armに切り替えたことでほとんどなくなりました。
移行した感想＋まとめ
サーバー費用を抑えられたのはもちろん、レスポンスタイムが20%近く良くなったのは想定以上の収穫でした。
イメージさえ用意できれば簡単に移行できるので、x86で動かしているサーバーがある場合は是非意向を検討してみると良いでしょう。