前回に引き続き serverless.yml の Functions プロパティについてまとめていきたいと思います。
基本的には以下のドキュメントを読んでまとめ、思うところを徒然に書いていきます。内容の保証はしません、というか間違ってる可能性も多いにあるので鵜呑みにせず一次情報に当たってください。
- アーキテクチャ
- ランタイム管理
- SnapStart
- VPC 設定
- 環境変数
- タグ
- Lambda レイヤー
- ロググループ
- バージョニング
- DLQ
- KMS キー
- X-Ray
- 非同期呼出
- EFS
- エフェメラルストレージ
- Lambda Hashing Algorithm 移行
- 感想
アーキテクチャ
Lambda の CPU アーキテクチャを指定します。
provider.architecture, functions.<function name>.architecture に記載します。
arm64 の場合
functions: hello: architecture: arm64
インテルの場合はドキュメントに記載がないですが、x86_64 を書けばよいと思います。
ランタイム管理
セキュリティパッチ等のランタイム更新タイミングをモードとして指定します。
provider.runtimeManagement, functions.<function name>.runtimeManagement に記載します。
モードは auto, onFunctionUpdate, manual（デフォルト値） が指定可能です。
各モードの詳細はこちら。
provider に設定する場合、auto, onFunctionUpdate が利用可能です。
provider: runtimeManagement: onFunctionUpdate
functions に設定する場合は3つのモードすべて記述することができます。この場合、mode の他に arn を指定する必要があります。
functions: hello: runtimeManagement: mode: manual arn: <aws runtime arn>
"aws runtime arn" って何でしょうか？ CloudFormation での記載方法と同じように ランタイム識別子である python3.9 とか nodejs16.x とかを記載すればよいのでしょうか。
識別子の一覧は以下参照。
SnapStart
コールドスタート問題を解消するためにキャッシュされた関数のスナップショットから起動する機能です。2023/2 現在では Java11 ランタイムのみでサポートされます。他にもいろいろと制限があるのでご注意。
functions.<function name>.snapStart に記載します。
functions: hello: runtime: java11 snapStart: true
VPC 設定
VPC Lambda 用設定です。
provider.vpc, functions.<function name>.vpc に記載します。
functions: hello: vpc: securityGroupIds: - securityGroupId1 - securityGroupId2 subnetIds: - subnetId1 - subnetId2
provider に設定しているが、一部の関数には適用したくない（パブリック Lambdaとしたい）場合には ~ で継承しないように設定できます。
provider: name: aws vpc: securityGroupIds: - securityGroupId1 - securityGroupId2 subnetIds: - subnetId1 - subnetId2 functions: hello: # パブリックな Lambda となる handler: handler.hello vpc: ~ users: # provider 継承により VPC Lambda となる handler: handler.users
実行ロールについて 上記の設定を行った場合、デフォルトでは "AWSLambdaVPCAccessExecutionRole" がアタッチされます。
カスタムロールを利用する場合は、ENI の create, describe, delete 権限が必要なことに注意してください。
インターネットアクセスについて
デフォルトでは VPC Lambda はインターネットアクセスができないため、VPC エンドポイントや NAT GW の設定が必要なことに注意してください。
環境変数
provider.environment, function.<function name>.environment に記載します。両方に同じ環境変数が存在する場合は functions の値で上書きされます。
provider: name: aws environment: SYSTEM_NAME: mySystem TABLE_NAME: tableName1 functions: hello: # 2つの環境変数を継承する handler: handler.hello users: handler: handler.users environment: # SYSTEM_NAME を継承し、TABLE_NAME は上書きする TABLE_NAME: tableName2
外の値を参照したい場合の書き方については以下参照。
タグ
provider.tags, functions.<function name>.tags に記載します。両方に同じタグが記載されている場合は functions の値で上書きされます。
provider: tags: foo: bar baz: qux functions: hello: # 2つのタグを継承する handler: handler.hello users: handler: handler.users tags: # baz を継承し、foo は上書きする foo: quux
Lambda レイヤー
functions.<function name>.layers に記載します。
functions: hello: handler: handler.hello layers: - arn:aws:lambda:region:XXXXXX:layer:LayerName:Y
ロググループ
functions.<function name> 直下に disableLogs, logRetentionInDays, logDataProtectionPolicy を指定します。
デフォルトでは Serverless Framework により Lambda のロググループを新規作成されますが、これを無効化するために disableLogs が利用できます。
logRetentionInDays は文字通りログ保管期間（日数）の設定です。
logDataProtectionPolicy はログのマスク処理の設定をします。Serverless 側のドキュメントには詳細な記載方法がなかったのですが、AWS 公式ドキュメント記載のポリシー構文に従って書けばよさそうです。
functions: hello: handler: handler.hello disableLogs: true # ロググループを新規作成しない goodBye: handler: handler.goodBye logRetentionInDays: 14 # 14日間保持 logDataProtectionPolicy: # ポリシー構文に従い記述 Name: data-protection-policy
既存のロググループを指定するときはどうするんだろう...（ベストプラクティスからはかけ離れていることは承知の上で）。
バージョニング
Serverless Framework では serverless deploy の度にバージョンを上げていきます。古いバージョンはフレームワークの管理対象ではないため自分で削除していく必要があります。
serverless deploy を2回やったときの図
関数バージョンをオフにするには provider.versionFunctions = false を設定します。
provider: versionFunctions: false
DLQ
リトライが失敗した際の DLQ 送信先を設定します。
functions.<function name>.onError に SNS トピック ARN を設定します。resources で定義した SNS を組込関数（Ref, Fn::GetAtt など）で指定することもできそうです。
functions: hello: handler: handler.hello onError: arn:aws:sns:us-east-1:XXXXXX:test
SQS のサポートは現状はないようなので、今後に期待。
KMS キー
環境変数を暗号化するための KMS キーを設定します。
service.awsKmsKeyArn, functions.<function name>.awsKmsKeyArn で指定することができ、functions は service の値を継承または上書きします。
service: awsKmsKeyArn: arn:aws:kms:us-east-1:XXXXXX:key/some-hash provider: name: aws environment: TABLE_NAME: tableName1 functions: hello: handler: handler.hello awsKmsKeyArn: arn:aws:kms:us-east-1:XXXXXX:key/some-hash # キー上書き environment: TABLE_NAME: tableName2 goodbye: # キー継承 handler: handler.goodbye
X-Ray
X-Ray トレースを有効化します。
provider.tracing, functions.<function name>.tracing で設定します。functions は provider の設定を継承または上書きします。
provider: name: aws runtime: nodejs14.x tracing: lambda: true functions: hello: handler: handler.hello tracing: Active goodbye: handler: handler.goodbye tracing: PassThrough
定義可能な値は Active, PassThrough です。
非同期呼出
送信先
非同期に実行された Lambda 関数の処理結果を他の Lambda や AWS サービスに送ることができます。ターゲットとして同じサービス内の Lambda 関数、外部の Lambda 関数、EventBridge イベントバス、SQS キュー、SNS トピックを設定できます。
functions.<function name>.destinations に onSuccess, onFailure に識別子※を設定します。※同じ serverless.yml 内で解決可能な関数名もしくは ARN。
ARN に CloudFormation 組込関数を利用する場合は明示的に type を指定する必要があります。
type は sns, sqs, eventBus, function から選択します。
functions: asyncHello: handler: handler.asyncHello destinations: onSuccess: otherFunctionInService # 同じサービス内の他 Lambda 関数（serverless 内で解決可能） onFailure: arn:aws:sns:us-east-1:xxxx:some-topic-name # SNS トピック ARN asyncGoodBye: handler: handler.asyncGoodBye destinations: onFailure: type: sns # ARN に CloudFormation 組込関数を利用する場合 arn: Ref: SomeTopicName
ほぼ SAM と同じ書きぶりですね。
リトライ試行
リトライ期間とリトライ回数を設定します。
リトライ期間は functions.<function name>.maximumEventAge, リトライ回数は functions.<function name>.maximumRetryAttempts に設定します。
それぞれ、60 ~ 21600 秒（6時間）、0 ~ 2 （回）で設定できます。
functions: asyncHello: handler: handler.asyncHello maximumEventAge: 7200 maximumRetryAttempts: 1
maximumEventAge と maximumRetryAttempts は片方しか必要なくても両方定義する必要があるようです。
エラーハンドリングについては以下の記事がとても参考になります。
EFS
これは個人的にほとんど使わなそうなので軽く。。。というか EFS マウントできるんですね。恥ずかしながら初めて知りました（VPC Lambda やったことないからという言い訳をしておきます）。
functions.<function name>.fileSystemConfig に マウント先の localMountPath と EFS の ARN arn を指定します。
functions: hello: handler: handler.hello fileSystemConfig: localMountPath: /mnt/example arn: arn:aws:elasticfilesystem:us-east-1:111111111111:access-point/fsap-0d0d0d0d0d0d0d0d0 vpc: securityGroupIds: - securityGroupId1 subnetIds: - subnetId1
エフェメラルストレージ
Lambda の /tmp サイズです。
functions.<function name>.ephemeralStorageSize に設定します。512 ~ 10240 MB で指定可能です。
functions: helloEphemeral: handler: handler.handler ephemeralStorageSize: 1024
Lambda Hashing Algorithm 移行
この章は現在 v3 を利用していて provider.lambdaHashingVersion = 20200924 を設定している人のためのマイグレーションガイドのようです。
provider.lambdaHashingVersion は Serverless Framework が関数のパッケージングに利用するハッシュアルゴリズムのバージョンですが、v3 では諸々の問題が修正され、初めから v3 を利用する人にとってはあまり関係がなさそうなので割愛します。
現在は非推奨ですね。
感想
2回にわたって Functions プロパティを見てきました。大体把握しましたが実際に書いてみないとなんともという感じですね。
そういえば、Lambda の基本的な設定であるメモリやタイムアウト設定はどこにあるんでしょうか。
ドキュメント一番上の functions 記載例の中にしれっと memorySize, timeout, provisionedConcurrency などの設定が入っていますね。全部が全部親切にドキュメンテーションされているわけではないので詰まったら都度ググるが正解ですかね。
ちなみに今回はドキュメントを読んでいきましたが、最新版をいち早く見るにはやはりリポジトリ直で見るのがよさそうです。ついこの間GAされた機能もサポートされていてスピード感がすごい。examples もとても充実していますね。
以上で Function の回を終わります。次回は API Gateway 設定か StepFunctions 周りを見ていきたいと思います。
