Serverless Frameworkで複数のLambdaの管理を楽にする

Serverless Frameworkを検討したきっかけ

業務で使うサーバーが、いつの間にかAWSになってから、毎日AWSを業務で利用しています。 AWSには、沢山のサービスがありますが、私のお気に入りはAWS Lambdaです。

理由は、とりあえずシンプルに作れるから!
プロジェクトが始まると、切り出せそうな処理はどんどんLambda Functionとして作ってはデプロイを繰り返します。

結果、案件も終わりが見えた頃には、「Lambda Functionいっぱい問題」発生。 このパターンが日常的にあり、修正や管理のコストが大きくなることが多いです。

Lamda大量問題

Lambda Function自体は便利ですが、以下の悩みがあります。

  • デプロイされているソース状態がわからない (パッケージサイズによるけど)
  • 数が多くなるとデプロイが大変。以下の手順を手動で何度も行うのは大変
    1. 最新ソースをgitからclone
    2. npm install
    3. zip圧縮
    4. AWSにアップロード
    5. 動作確認

お手製ツールを用意したりなどで、なんとかごまかし運用をしていた所、弊社のアーキテクトから「Serverless Framework使えば?」とのアドバイスを受け「何やそれ?」ってなったのが、導入のきっかけになります。 (キャッチアップせーよ、頭使って仕事しろよって話ですね。。。)

Serverless Frameworkって何?

Serverless Frameworkとは、お手軽に「サーバレスアーキテクチャ」を構築することができるフレームワークです。もちろん、AWSのLambda Functionにも対応しています。

そもそもサーバーレスアーキテクチャって何?

簡潔にいうと、「常時起動しているサーバーを使わずにアーキテクチャ(仕組み)が実現できている状態」というニュアンスが近いです。 メリットとしては、常時起動サーバーがなくなり、以下のサーバーあるあるの問題がなくなることです。

  • サーバーを常時起動している場合、使用していない時間も料金がかかる問題
  • 起動しているサーバーは、誰がメンテナンスするの問題
  • サーバー設定担当者によって構成が微妙に違うので、デプロイしたらコードが動かない問題

重複しますが、そんなサーバー関連の問題を減らすことができる「サーバレスアーキテクチャ」をお手軽に構築できるのが、「Serverless Framework」となります。

Serverless Frameworkのメリット

Serverless Frameworkによるメリットは、以下です。

  • サーバーレスアーキテクチャを簡単に構築できる
  • サーバーレスアーキテクチャの管理が簡単になる
  • フレームワークにより、サーバーレスアーキテクチャ構築手法が一本化できる

私がLambda Functionで導入した時に嬉しかった点は以下です。

  • デプロイの負担が減った!
  • 環境変数の追加漏れがなくなった!
  • 関連する複数のLambda Functionを一括で更新できるようになった!(これがとにかく便利でした)

Serverless Frameworkのデメリット

メリットだけではなく、デメリットもあるにはあります。

  • 理解するまでの学習コストがかかる
  • 慣れるまでは、初回の準備が面倒
  • ローカルでのテスト実行時の起動速度が遅くなる

AWSのLambda FunctionとS3を使って実践

成果物の要件を以下と定義します。

  1. Lambda Function 1の挙動
    1. 実行したらHelloWorldを出力
    2. S3にhello.jsonをアップロード
  2. Lambda Function 2の挙動
    1. S3からhello.jsonを読み込み
    2. hello.jsonの中身を出力
  3. Server Frameworkで動く状態になっていること

Lambda Function 1の作成

以下のコードを作成して、AWSにデプロイします。

Lambda1をデプロイ

S3の操作を行うためのロール設定

S3でロール設定

テストなので、とりあえずS3のフルアクセス権限を設定しています。
※プロダクションコードの場合は、適切な権限設定を行ってください。

ロールを設定

以下のように環境変数も設定。

環境変数を設定

Lambda Function 1の実行

無事「Hello World」がコンソール上に出力されました。

Lambda1の実行結果

無事、S3に「hello.json」がアップロードされました。

S3にアップロード

Lambda Function 2の作成

以下のコードを作成して、AWSにデプロイします。

Lambda2をデプロイ

  • ロールは、さきほど作成したものを使いまわして設定
  • 環境変数は、さきほどのLambda Function 1と同じ内容を設定

無事、S3からファイルを読み込み、中身を出力できました。

Lambda2の実行結果

Lambda FunctionをServerless Frameworkとして設定

envファイルを作成し、Lambda Functionに設定する環境変数情報を設定します。 envファイルは、以下のようにYAML形式でシンプルに記述できます。(リージョンやバケットは適宜書き換えてください)

Serverless Framework本体用にYAML形式の設定ファイルを作成します。 今回は、以下のような設定ファイルを用意しました。

Serverless Frameworkでインフラリソースの管理

Serverless Frameworkでは、Lambda Functionで使用する周辺リソース(S3,SQSなど)も同時にデプロイ管理することができます。手動で作成した既存のリソースも使用しても問題ありません。

Lambda FunctionをServerless Frameworkでデプロイ

Serverless Frameworkでデプロイを行います。

serverless deploy --aws-profile ${profile指定が必要な時のみ} --verbose --stage dev 

関係するLambda Functionが一括でデプロイされました。

Lambdaの一括デプロイ

環境変数が設定されていることを確認

環境変数を確認

今回は一括でデプロイしましたが、以下のようなコマンドで個別にデプロイすることもできます。

serverless deploy --aws-profile ${profile指定が必要な時のみ} --verbose --stage dev -f helloworld 

Serverless Frameworkの動作確認

ちゃんと動くかテストします。

Serverless Frameworkの動作確認

無事、Serverless FrameworkでアップロードしたLambda Function 1が動作しました。

Serverless Frameworkの設定に問題がなければ、Lambda Function 1を実行した時に保存されるS3ファイルをトリガーにして、Lambda Function 2が動いているはずなので、Cloud Watchのログを確認します。

ログを確認

無事、Serverless FrameworkでアップロードしたLambda Function 2が動作しました。

念のため、手動での実行テストも行います。

手動テスト結果

無事、Serverless Frameworkでアップロードした、Lambda Function 2が動作しました。

まとめ

実際に、Serverless Frameworkを使って便利だなぁと思った点は以下となります。

  • とにかくデプロイが楽になった
  • 関係するLambda Functionを一括でデプロイできる
  • こういうパターンで組む時にデプロイミスが減った Cloud Design Pattern: Queuing Chainパターン
  • 環境変数の管理が楽になった
  • ウェブコンソール上で設定していた時にあったようなミスがなくなった

新しいことを取り入れるのは、いつも億劫になりがちですが、実際にやってみると「何でもっと早くこれにせんかったんや」と思うことが多いです。Serverless Frameworkについても、その一つです。

まだ使ってみたことがない方は、お試しいただければと思います。