ECRを導入して、Lambdaの制限容量問題を解決

ツール導入前の課題

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からデータを取得するのに時間を要した点

• 公式サイトのため規模が大きくなる見込みは低いが、規模拡大時にはS3への分離なども検討したい