AWS Lambdaの初期化処理と初期化タイミングの考慮不足によるはまりどころ

こんにちは、TIGの辻です。失敗談をテーマにした連載の5本目です。

AWS Lambda（以下Lambda）は様々なユースケースで利用できる、なにかと便利で強力なサービスです。本ブログでも以下のようにLambdaに関するたくさんの記事が投稿されています。

私もLambdaが好きで、Lambdaの実行時間制約以内で終了する処理であれば、初手の候補の1つとしてLambdaを考えます。

そんなLambdaですが、予約済同時実行数⁵を1に制限して使っていたときに、初期化処理と初期化タイミングの考慮不足により、はまったことがありました。本記事ではLambdaの初期化処理についておさらいした後、はまったケースの事例や原因、対応した方法を紹介します。

Lambdaのライフサイクルと初期化処理

Lambda実行環境のライフサイクルは3つに分かれています。INITとINVOKEとSHUTDOWNです。

https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/lambda-runtime-environment.html より

INITフェーズでは、関数インスタンス（Lambda関数が実行される環境のこと）作成やハンドラ関数外に実装されている初期化処理が行われます。たとえばGoの場合、AWSのサンプルにある ² 以下のような init() の処理はINITフェーズで行われます。

package main

import (
        "log"
        "github.com/aws/aws-lambda-go/lambda"
        "github.com/aws/aws-sdk-go/aws/session"
        "github.com/aws/aws-sdk-go/service/s3"
        "github.com/aws/aws-sdk-go/aws"
)

var invokeCount = 0
var myObjects []*s3.Object
func init() {
        svc := s3.New(session.New())
        input := &s3.ListObjectsV2Input{
                Bucket: aws.String("examplebucket"),
        }
        result, _ := svc.ListObjectsV2(input)
        myObjects = result.Contents
}

func LambdaHandler() (int, error) {
        invokeCount = invokeCount + 1
        log.Print(myObjects)
        return invokeCount, nil
}

func main() {
        lambda.Start(LambdaHandler)
}

データベースとの接続などの、実行タイミングに依存しない処理を初期化処理として実施し、グローバル変数として再利用できるようにすることはパフォーマンスの観点から有効です。ハンドラの関数外に宣言されているグローバル変数は、Lambdaの関数インスタンスの一部として保存され、その後のリクエストで再利用されることがあるためです。³

なお、上のサンプルで LambdaHandler() に該当するハンドラ関数内の処理はINVOKEフェーズで実行されます。

はまりケース

はまりケースでもパフォーマンスを考慮して、TCP通信の確立をLambdaの初期化処理として実装していました。構成はざっくり以下のようなクライアント／サーバモデルです。

対向システム（サーバ）
- ある処理を受け付けるサーバがある。スケールアウトはしない
- サーバ制約上、複数のクライアントから同時に接続することはできない
Lambda（クライアント）
- 対向システムとTCP通信して処理を行う
- 同期呼び出しLambdaである
- Lambdaは複数起動しても通信確立できないため、予約済同時実行数を1としていた
- TCP通信するための変数はグローバル変数として宣言し、初期化処理で通信を確立するようにしていた

対向システムの制約と（詳細は割愛しますが）非機能要件上、Lambdaの予約済同時実行数を1で絞ることで、Lambdaが2つ以上同時実行されないようにしている、という点がトリッキーな感じです。⁷

このとき、ロングランテスト⁸中に、稀に以下の問題となる事象を観測することがありました。