ECRを導入して、Lambdaの制限容量問題を解決
株式会社モバイルファクトリー / 川西亨弥
メンバー / フルスタックエンジニア・プロダクトエンジニア / 従業員規模: 51名〜100名
| ツールの利用規模 | ツールの利用開始時期 |
|---|---|
| 11名〜50名 | 2024年11月 |
| ツールの利用規模 | 11名〜50名 |
|---|---|
| ツールの利用開始時期 | 2024年11月 |
アーキテクチャ
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
Lambdaのデプロイパッケージサイズ上限250MBに対しすでに240MBを使用しており、パッケージ更新などをきっかけにいつ上限を超えてもおかしくない状況だった。
加えて、Nuxt 2からNuxt 3への移行に伴いさらにサイズが増加することが見込まれたため、サービスを維持するための対応が必要だった。
どのような状態を目指していたか
- デプロイ手順を変更することなく、サービスを維持できる状態
- Nuxt 3への移行後も、Lambdaのサイズ上限に余裕を持たせられる状態
比較検討したサービス
- AWS Amplify
比較した軸
- 導入コストが低いこと
- セキュリティ上で問題がないこと
選定理由
Amazon ECR(Elastic Container Registry)を用いたコンテナイメージ形式でのLambdaデプロイを採用した。決め手は以下の3点。
- パッケージサイズ上限の大幅な緩和:通常のLambdaデプロイパッケージは250MBが上限だが、コンテナイメージ形式では最大10GBまで対応できるため、今回の容量逼迫の課題を根本的に解決できる
- 既存構成への影響が小さい:Dockerfileを用意してイメージをpushする構成に変更するだけで済み、アプリケーションコードや既存のデプロイフローを大きく変える必要がない
- 社内に知見がある:別プロジェクトでの導入実績があり、運用ノウハウを活用できる
比較検討したAWS Amplifyは、運用ポリシーに合わず採用を見送った。
導入の成果
改善したかった課題はどれくらい解決されたか
最大の課題であったLambdaのデプロイパッケージサイズ上限(250MB)への逼迫は、ECRを用いたコンテナイメージ形式への移行によって解消された。コンテナイメージ形式ではサイズ上限が10GBまで緩和されるため、パッケージサイズの制約を気にすることなくNuxt 3への移行が完了した。
また、当初目指していた「既存のデプロイ手順を大きく変えずにサービスを維持する」という点も達成でき、運用フローへの影響は最小限に抑えられている。
どのような成果が得られたか
パッケージサイズを意識せずに、必要なライブラリを自由に追加・更新できるようになった
導入時の苦労・悩み
- Nuxt 2からNuxt 3への移行に加えて、Serverless Frameworkをv2からv3への移行も同時に進めていたことから、アクセスできなかった際に、どちらに原因があるのかを調査するのが困難だった点
- AWSの構成を変更するのは初めてだったので、ECRからデータを取得するのに時間を要した点
導入に向けた社内への説明
上長・チームへの説明
Lambdaのパッケージサイズが上限に迫っていたという課題の緊急性に加え、ECRを用いた構成は社内の別プロジェクトですでに運用実績があったため、「実績のある構成を踏襲する」という形で、大きな議論なくチームおよび上長の合意を得ることができた。
活用方法
よく使う機能
Lambdaへのコンテナイメージのデプロイ:ECRに格納したコンテナイメージをLambdaから参照することで、パッケージサイズ上限を10GBまで拡張できる
ツールの良い点
- 導入コストが低い
ツールの課題点
- 反映時にDockerのビルドが必要になるため、反映までに時間がかかる
今後の展望
- 公式サイトのため規模が大きくなる見込みは低いが、規模拡大時にはS3への分離なども検討したい
株式会社モバイルファクトリー / 川西亨弥
メンバー / フルスタックエンジニア・プロダクトエンジニア / 従業員規模: 51名〜100名
よく見られているレビュー
株式会社モバイルファクトリー / 川西亨弥
メンバー / フルスタックエンジニア・プロダクトエンジニア / 従業員規模: 51名〜100名


