クラウドワークス エンジニアブログ

日本最大級のクラウドソーシング「クラウドワークス」の開発の裏側をお届けするエンジニアブログ

Serverless Frameworkからlambroll + Terraformへ移行した話

はじめに

こんにちは。株式会社クラウドワークスで「クラウドリンクス」の開発を担当しているエンジニアの松村です。

クラウドリンクスでは、WebアプリケーションをAWS上で運用しており、LambdaやECS (Fargate) などを活用したサーバーレス構成を採用しています。

今回は、その中でもLambdaのデプロイ基盤をServerless Frameworkからlambroll + Terraform構成に移行した事例を紹介します。

同じような移行を検討している方にとって、少しでも参考になればうれしいです。

背景

クラウドリンクスではAWS Lambda関数のデプロイにServerless Frameworkを利用していました。 便利なツールではありましたが、次の課題がありました。

  • Serverless Framework v3のEOL
    • 2024年末で公式サポートが終了。
  • v4からライセンス変更

これらを背景に、Lambda関数のデプロイ方法を見直し、Serverless Frameworkに代わる新しいデプロイツールの検討を進めました。

検討した代替ツール

Lambdaのデプロイ方法を見直すにあたり、いくつかの代替ツールを比較検討しました。 Lambda関数をTypeScriptで実装しており、ビルドやデプロイ時の開発効率も比較の観点に含めました。

ツール メリット デメリット
Serverless Framework ・移行工数が少ない
・周辺のリソースも管理できる
・プラグインが豊富 		・有償ライセンス（v4以降）
・インフラコードとアプリケーションコードが混在
・CloudFormation縛り
・プラグイン依存によるスイッチングコストの高さ
AWS SAM（Serverless Application Model） ・AWS公式が推奨
・周辺リソースも管理できる
・TypeScriptのビルドを支援 		・CloudFormation縛り
・インフラコードとアプリケーションコードが混在
lambroll ・インフラコードとアプリケーションコードを分離できる
・関数単位でシンプルにデプロイ可能
・OSSで無料利用可能 		・TypeScriptのコンパイルは別途必要

最終的に、「Lambda関数はlambrollで管理し、それ以外のAWSリソースはTerraformで管理する」という分離方針を採用しました。

lambrollの概要

lambrollはGo製のAWS Lambda専用デプロイツールで、以下のような特徴を持ちます。

  • Lambda関数単体の管理に特化
  • デプロイ、ロールバック、バージョン管理、ログ表示をサポート
  • 既存関数の取り込みが可能
  • 他リソースは別管理が必要

Serverless Framework と lambroll の比較

項目 Serverless Framework lambroll
管理対象 Lambda関数 + 各種AWSリソース （API Gateway, CloudFrontなど）
を統合管理		 Lambda関数のみ
設定ファイル serverless.yml（YAML記述） function.json または function.jsonnet
ライセンス形態 v4以降は商用プランあり（年商200万ドル以上は有料） OSS（無料）

移行の進め方

移行は以下のステップで段階的に行いました。

1. lambrollの導入・調査

2. 一部関数をzip→ECRイメージ化
Lambdaパッケージサイズが50MBを超える関数をコンテナ化し、ECRリポジトリを新規作成。

3. 関数単位でlambrollデプロイが可能な状態にする
ディレクトリ構成を整理し、設定ファイル等の追加

4. CloudFormationリソースをTerraformへ移行 (Route53, CloudFront, API Gatewayなど)

  • CloudFormationテンプレートの構造を確認し、リソース一覧を整理
  • Terraform側で対応するリソース定義を作成
  • 既存リソースを terraform import でStateに取り込み
  • terraform plan を実行し、CloudFormationとの差分を確認

5. 段階的移行
影響範囲の小さい関数から順に移行。安全に切り替えを進行。

実際に苦労した点と工夫

1. CloudFormationとTerraformのリソース定義単位の違い

Terraformで定義し直したAPIが同等に動作するかを検証するため、テスト用リソースを作成し、動作一致を確認しました。

2. Lambda関数とAPI Gatewayの紐付け問題

TerraformでAPI Gatewayを作成する際、LambdaがTerraform管理下にないと参照エラーが発生。Terraform側にダミーのaws_lambda_functionリソースを定義し、依存関係を解消。 さらに、Lambdaコードの変更はTerraformでは管理しないようにlifecycle.ignore_changesを設定しました。

得られた成果

  • 関数単位でシンプルにデプロイ可能に
  • 構成の明確化：Lambdaとインフラを明確に分離
  • Terraform連携性の向上：リソース管理をTerraformに統一し、構成の一貫性を確保

まとめ

Serverless FrameworkのEOL対応をきっかけに、Lambdaのデプロイツールを見直しました。

当初はEOL対応という守りの目的から始まりましたが、結果的に、Terraformによるインフラ管理の統一と、lambrollによるシンプルなLambdaデプロイを実現できました。

これにより、構成の明確化・デプロイ時間の短縮といった副次的な効果も得られ、ツール変更が単なる移行作業ではなく、運用基盤の整理と改善の機会になりました。

最後に、クラウドワークスグループでは共に働く仲間を募集しております。ご興味のある方は以下のリンクから採用情報をご確認ください。

crowdworks.co.jp

© 2016 CrowdWorks, Inc., All rights reserved.