ECSタスクに配慮したイメージ削除スクリプトの活用術
はじめに
株式会社Rehab for JAPAN 開発2部技術横断チームの鈴木です。
昨今、円安の影響もありAWSコスト削減のプラクティスが注目されています。
弊社でも昨年からAWSのコスト削減に本格的に取り組み始め、約1年でAWS全体のコストをトータルで約50%削減することができました。今後ブログなどでこの取り組みで得た知見を皆さんと共有できたらと考えています。
また、ブログでご紹介する内容はあくまで弊社の場合の一例であり、すべての状況に必ずしも適合するとは限りませんので一例として参考にしていただければ幸いです。
ターゲット
AWSコスト削減を実施している方
要約
この記事では、ECR(Elastic Container Registry)のイメージ管理の取り組みを紹介します。
イメージ管理をECRの標準機能である「ライフサイクルポリシールール」ではなく、自前のスクリプトで実施した理由やスクリプトの処理について書いてあります。
背景
昨今、新しいサービスや環境が増えるにつれECRのコストも上昇傾向にありました。AWS全体からみれば小さな金額ですが、将来を見据えて今から対策を取ることで大きなコスト削減につながると考え、ECRのイメージ管理の仕組み作りに着手しました。
本題に入る前に簡単ですがインフラ構成を紹介させていただきます。
弊社のサービスのRehab Cloudのシステムはプラットフォームを中心に各サービスが連携しています。各サービスのベースとなるインフラ構成は共通していますが、細かい部分はサービス毎で異なります。また、インフラはCDKで管理されています。
[インフラ基本構成]
なぜECRのライフサイクルポリシーを使わなかったか?
ECRには設定したポリシーに従い自動でイメージを削除するライフサイクルポリシーという機能がありますが、私たちは自前のスクリプトで対応する方法を選びました。
その理由は下記2つになります。
古いイメージを使い続けるECSタスクを考慮したポリシーを使いたい
自前のスクリプトを作成した最大の理由は、古いイメージを使い続けるECSタスクも考慮したかったからです。
ECRのライフサイクルポリシーでは、次の2つの条件のいずれかで設定できます。
- イメージ数（imageCountMoreThan）：イメージの世代数
- プッシュからの経過日数（sinceImagePushed）：イメージがプッシュされてからの日数
いずれの条件もイメージのプッシュされた日付で判定されます。
日付のみで削除判定される場合、タイミングによっては「起動中のECSタスクがライフサイクルポリシーで設定した日付よりも古いイメージを利用している場合、そのイメージも削除される」という事象が発生する可能性があります。
ECSタスクで利用中のイメージが削除されるとECSタスクが何かの理由で再起動した時にpullするイメージが無くECSタスクが起動できなくなる恐れがあります。
イメージタグの運用ルールが未確立であるため
現在、イメージタグの命名規則の運用がチーム間で統一されていません。
この状況でECRのライフサイクルポリシーを利用すると、チームごとに異なるポリシーを管理する必要があり、技術横断チームの運用コストが高くなってしまいます。
以上の2つの理由から私たちは次のような方針を取りました
- まずは自前のスクリプトで柔軟に対応する
- イメージタグの運用ルールが整ってから、ECRのライフサイクルポリシーの利用を検討する
この方法なら、特殊な運用要件に対応しつつ将来的にはより効率的なイメージ管理に移行できると考えました。
自前スクリプトの最大のメリット
自前スクリプトの最大のメリットは自社の運用要件に合わせてカスタマイズができるという点です。
今回作成したスクリプトの削除判定は、「日付」 + 「ECSタスクで利用の有無」に基づいて削除判定を行うため、上記で記載したようなECSタスクで利用中のイメージが削除されるという事態を回避できます。
デメリットは運用コスト(スクリプト修正とそれに伴う検証)になります。
削除判定
| 条件 | 削除される |
|---|---|
| イメージタグがないもの | はい |
| 最新のイメージのpush日から30日以前でECSに利用されていないイメージ | はい |
| 最新のイメージのpush日から30日以内のイメージ | いいえ |
| 最新のイメージのpush日から30日以前でECSに利用中のイメージ | いいえ |
スクリプトの処理
スクリプト処理は下記のステップで実行されます。
-
ECSタスクの情報を取得: 現在稼働しているECSタスクから、タスク定義とイメージの情報を取得します。
-
ECSで利用中か判定: ECRで管理しているイメージとECSタスクで利用されているイメージを突き合わせてECSで利用中かを判定します。
-
最新のpushから30日以内のイメージのチェック: リポジトリ毎に最新のイメージの日時を確認し、その日時から30日以内のイメージを削除対象から除外します。30日以内のイメージはECSで利用中かの判定も確認して削除判定をします。
-
イメージタグ有無のチェック: 各リポジトリでイメージタグが無いもの(“-”)はすべて削除対象となります。
-
削除実行: 上記ステップで削除判定されたイメージを削除します。ログに削除したイメージ情報を出力します。
中身のコードに関しては別の回で紹介できたらと思っています。
システム構成
- EventBridge: 毎日1:00に実行(イベントスケジュール)
-
Lambda: ECRイメージ管理スクリプトを実行
スクリプト導入後のコスト推移
2024年1月〜3月にかけて導入し約80%の削減ができました。
まとめ
弊社の運用要件に合わせた自前スクリプトでECRで管理されているイメージを効率的に削除でき、コスト削減に役立てることができました。
イメージタグの運用ルール確立後は古いイメージを使い続ける環境にだけスクリプトを実行し、
他はECRのライフサイクルポリシーを利用することを考えています。
この記事が参考になった場合は、ぜひ "いいね"やシェアをお願いします。
ここまで記事を読んでいただきありがとうございます。
最後に、一言だけ弊社の紹介をさせてください。
弊社は「歳を重ねることが 楽しみになる 社会の創造」を目指しているスタートアップです。
それを実現するために様々なサービスをリリース中です。
Discussion