技術

AWS Lambdaを使う時に注意すべき5つのこと

AWS Lambdaはインフラを(あまり)意識することなく気軽に関数が実行できる優れたサービスです。使用頻度も多いかと思います。ただ、このLambdaを使用するときはいくつか注意する必要があります。今回は個人的に注意している点をまとめてみました。

1. コールドスタートとホットスタートがあることを意識する

Lambdaにはコールドスタートをホットスタートがあります。Lambdaは通常は、実行時にコンテナ生成からはじめまります。いわゆるコールドスタートで、実行までタイムラグがあります。前回実行から時間がたっていない場合は、起動中のコンテナをそのまま使用するホットスタートになり、応答速度は早くなります。求められるパフォーマンスがシビアなシステムの場合は、ホットスタートにするために、リクエストがなくても定期的にLambda関数を実行するような対策、いわゆるウォームアップが必要になってきます。

また意図せずともホットスタートになるので、前回実行時のオブジェクトをそのまま使用されたりすることもあります。実装時はこのことを意識しながら実装していく必要があります。またトラブルシューティング時にこの辺の調査もできるようなしたいので、ログ出力にも気を使う必要があります。

2. 制限容量をサイズを意識する

Lambda関数には50MBのサイズ制限があります。外部ライブラリの依存が多くなってきたら、圧縮してLambda Layerに置くこともできますが、圧縮しても250MBの容量制限があります。そして、この容量についてはAWSに制限緩和のリクエストはできません。

250MB以上の外部ライブラリが必要な場合、EFSをマウントしてEFSにライブラリを置いてそこからロードする必要があります。ただこれは少々、設定が面倒なのでできれば避けたいシステム構成です。

なので、実装時もサイズの大きい外部ライブラリをバンバン使うようなことはさけ、コンパクトにシンプルに作ることを心がける必要があります。

3. 実行回数を意識する

LambdaはFailした場合は、自動で3回までリトライ実行されます。

なので、冪等性を意識した実装にするか、再試行回数をデフォルトから0回に変更するなどの対策が必要になってきます。

LambdaはDynamoDBとセットで使うことが多くトランザクション管理が難しいですし、他のAWSサービスと連携することも多く、冪等性の担保は難しい場合があります。その場合は、私は諦めて再試行回数を0にすることが多いです。使う側でリトライかけられることもありますし、再試行しないほうがトラブルが起きにくいです。

4. 実行ロールを意識する

Lambdaには実行ロールを設定する必要があります。Lambdaからアクセスできる他のAWSサービスを設定する必要がありますが、開発時はこの辺を適当にやってしまいがちです。各サービスに対して、フルアクセスを付与したりしがちです。

開発時はそれでいいのですが、検証や本番にリリースした段階でアクセス権を絞ろうとするときに適切なアクセス件を設定するのは大変です。

下手にアクセス権を絞ったため、開発環境では出なかったアクセス権エラーが起きたということに成りかねません。

こういった事態を避けるためにも、実行ロールの設定は、開発環境時からしっかりとやるべきです。

5. ネットワーク(VPC)のアクセス可能性を意識する

LambdaはデフォルトではVPC外にあり呼び出すだけで手軽に実行できますが、VPC内に設置することもできます。

サーバーレスといえど、ネットワーク構成は意識する必要があります。VPC内のAWSリソースにアクセスしたいときはVPC内に起き、その場合、VPC外のリソースにアクセスしたいときはセキュリティや通信コストなどを考えVPCエンドポイントを設定したりする必要があります。

まとめ

以上、AWS Lambdaを使用するときに注意すべき4事項でした。

  1. コールドスタートとホットスタート
  2. 容量制限
  3. 実行回数(リトライ回数)
  4. 実行ロール
  5. VPC構成

Lambdaはもう何年も使っていますが、いまだにはまることがあったりします。シンプルに見えて奥が深いサービスだと思います。