3
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

私的 Serverless Framework ベストプラクティス

Posted at

Serverless Frameworkの設定で、新しいプロダクトを作るときやレビューするときに気をつけたい点をまとめました。

他の方のベストプラクティスも知りたいです! ぜひコメントや記事公開してください。

Serverless Frameworkもpackage.jsonに入れておこう

CLIですがグローバルインストールしないで、ちゃんとpackage.jsonでバージョン管理するようにしましょう。

npm install -D serverless

バージョンの違いで動かなった経験、何度かあります。

ログの設定をしよう

ログの設定はしっかりしておきましょう。

provider:
  logRetentionInDays: 14  # ログ保持期間
  tracing:  # x-rayトレースを採る
    apiGateway: true
    lambda: true

おまじないだと思って定型文的に入れています。

ゴミを残さない設定をしておこう

自動的に作られるデプロイメントバケットですが、気がついたら大量にできてたりします。アカウントで1つあれば十分なので、あらかじめバケットを作っておいて、以下のように既存バケットを使う設定にしておくのがおすすめです。

provider:
  deploymentBucket:
    # デプロイファイルの置き場に既存バケットcom.serverless.000000000.deploysを使用
    name: com.serverless.${aws:accountId}.deploys

同じく、Lambdaのバージョン管理もオフで良いと思います。これが有効だとAWS管理コンソールからLambdaを古いバージョンに切り替えができるのですが、正直この機能を使ったことはないありません。レポジトリの状況とデプロイしているものが乖離するので使わない方が良いと思います。むしろ、このバージョン管理が原因でLambdaコードストレージ(Lambda クォータ)のサイズ制限に引っかかってデプロイの妨げになることが多かったり1

provider:
  versionFunctions: false

権限は必要最低限にしよう

権限は必要最低限のものを与えましょう。

悪い例

provider:
  iam:
    role:
      statements:
        - Effect: Allow
          Action:
            - s3:ListBucket
          Resource:
            - arn:aws:s3:::*

良い例

provider:
  iam:
    role:
      statements:
        - Effect: Allow
          Action:
            - s3:ListBucket
          Resource:
            - arn:aws:s3:::my-example-bucket
            - ${cf:myStack.bucketName}

より細かく設定したい場合、Serverless IAM Roles Per Functionを導入するとよいかもしれません。

データ層はResourcesに含めない

Serverless.ymlの Resources ブロックは実質的にCloudFormationテンプレートなので、AWSのリソースならおおよそ何でも作れてしまいます。「やったー! IaCだー!」と何でもかんでもここに突っ込みたくなるところですが、 S3, DynamoDB, Cognito等々の「データ層」のリソースを記述するのはおすすめしません。こういったものについては serverless.ymlとは独立してCloudFormationテンプレートを用意しましょう。

理由は、いつかは sls deploy がコケて、どうしても sls remove せざるを得ない状況が訪れるからです2。そうなるとせっかくデータを突っ込んだリソースが消すか、或いは次のデプロイがリソースの重複でコケるかの二択になってしまいます。

データ層だけのCloudFormationスタックを別に用意しておけば、 sls remove するときも安心ですし、同じデータ層を参照するやつを2つデプロイして先行リリース環境を作ったりBlue-Green Deploymentだったりといったこともできます。ポイントはステージ名(--stage hoge)だけ変更すればいくらでも複製をデプロイしてすぐ使える状況を作っておくことだと思っています。

${cf:stackName.outputKey} で他のスタックのアウトプットを参照できることも活用しましょう。

  1. Lambdaのバージョン管理を使いたい場合はServerless Prune Pluginというのがあるので、そちらを導入すると良いでしょう。

  2. 正確にはServerless Frameworkがコケるというより、 Resources が原因でコケるケースが大半です。CloudFrontのリソースは割とトラブルが起きやすい印象です。なんにせよ「ないことはない」、いつかは起きる可能性がある事象と覚悟しておいたほうがいいでしょう。

3
4
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?