Serverless Framework から lambroll + Terraform に移行しているお話
はじめまして、wind-up-bird です。スタディストの SRE Unit に入ってから約半年が経ちました。今回は社内で利用している Serverless Framework を lambroll に移行しているのでその話を少し書いてみようと思います。
これまでの開発の流れ
スタディストでは AWS Lambda および周辺リソース（AWS IAM や Amazon API Gateway など）の管理はこれまで Serverless Framework を利用していました。開発からリリースの流れは以下の通りです。
- Lambda の開発
- serverless.yml を作成
- 開発者がデプロイ担当者に連絡する
- 担当者がローカルの環境から serverless deploy を手動実行
Serverless Framework 導入当初は管理しているリソースが少なくこの運用でもあまり問題になりませんでしたが、時間の経過とともに管理対象が多くなり、だんだん運用がしんどくなってきました。
課題感
課題としては主に2つが挙げられます。
- 開発速度の低下
- 手動実行による弊害
具体的には、リリースが自動化されておらず、開発者と担当者間のコミュニケーションコストおよびリリースまでのタイムラグが発生してしまいます。また、リリース担当者の負荷もさることながら、担当者（複数人）のローカル環境（Serverless Framework や Node のバージョンなど）が統一されていないというのも問題意識としてありました。
これらの課題感を背景にリリースフローの見直しを行いました。
リリースフローの検討
見直しに当たり、以下のような方針を検討しました。
- Serverless Framework を引き続き使いつつ、リリースを自動化する
- Lambda 含めすべて Terraform に移行する
- Terraform で管理するが、 Lambda だけは別リリースフローにする
まず1つ目の方針ですが、既存のコードを再利用しつつ、CircleCI や AWS CodeBuild 等で serverless deploy を実行することを検討しました。この場合、実行環境を整備するだけなのでそこまで大変ではないですが、Severless Framework や Node のバージョンアップは今後も継続して実施していく必要があります。加えて、Serverless Framework は裏側で Cloud Formation が動くため、長いものだとデプロイ完了までに数分かかってしまうというのも課題としてありました。
次に2つ目の方針ですが、スタディストでは AWSリソースを Terraform で管理しています。また、開発者は Terraform を普段利用することが多いため、Terraform へ移行することは親和性が高いと考えました。しかし、 Lambda を Terraform でリリースしようとすると、依存ライブラリを含む zip アーカイブをどのように管理するかという問題が発生します。
最後に3つ目の方針ですが、2つ目で出てきた問題を解決するために、Lambda だけを別のリリースフローに切り出す方針を考えました。
ここは、チームのメンバーともPros/Consを話し合い、最終的に3つ目の方針で移行していくこととしました。
Lambda のリリース
Lambda だけ別のリリースフローにする場合、 CLI や SDK を利用するパターンもあると思いますが、今回は lambroll というツールを使ってみることにしました。
特に、作者のブログにも書かれていますが、以下の点にメリットを感じています。
- Lambda のデプロイに特化したミニマルなツールである
- 継続してメンテナンスが行われている
また、GitHub Actions も用意されているので、導入も容易であると判断しました。
以上をまとめると、
- Lambda: lambroll on GitHub Actions でリリース
- それ以外: Terraform で管理
としました。次にLambdaをどのように管理・リリースしているか紹介したいと思います。
lambroll on GitHub Actions
まず、Lambda のソースコード(lambda_function.py)と function.json を特定のディレクトリで管理するようにしています。なお、Lambda 本体は検証/本番環境で共通、環境差は環境変数（〜.env で定義）で吸収するようにしています。
lambda
├── README.md
└── service-A
├── README.md
├── function.json
├── lambda_function.py
├── production.env
└── staging.envまた、対応するGithub Actionsは以下のように設定しています。
Lambda関数や環境変数に変更があったときに Github Actions が走り、検証環境と本番環境にリリースされる流れになります。
ちなみに、 GitHub Actions の承認機能も利用しており、特定の開発者が承認したときにリリースされるようにしています。
導入してみてどうだったか
今回の導入によって、以下の点でメリットがあったかなと思います。
- 開発からリリースまでの速度が向上
- コミュニケーションコストの低下
(社内の声）
しかし、まだセキュリティ面で課題があり、現状だと IAM User を払い出して Credential を GitHub Actions の環境変数として設定しています（なお、権限は Lambda 関連に絞っています）。この点に関しては、以下のような仕組みもある（ 現時点ではまだ非公式のようです）ので将来的に解消していけたらいいなと思っています。
まとめ
ということで、Serverless Framework を移行している事例を紹介してみました。これからも開発のスピードを上げる取り組みをどんどんやっていきたいと思います。
おわりに
スタディストでは、今後さらなる事業拡大を目指すためにも、より多くの仲間を求めています。
ご興味がありましたら、ぜひ一緒に働きましょう。
よろしくお願いします！
