落とし穴にハマるな！AWS Lambdaを利用するときの6つの注意点
サーバーレスには「サーバーの構築や管理が不要」など、多くのメリットがあります。このため、サーバーレスはここ数年急速に注目を集めています。
そして、サーバーレスの代表格と言えるのがAWS Lambdaです。サーバーレスと聞くとAWS Lambdaを思い浮かべる人も多いのではないでしょうか？
とはいえ、AWS Lambdaを用いてサーバーレスアプリケーションを構築するには落とし穴に入らないよう注意が必要です。この記事ではAWS Lambdaを利用するときの注意点を6つ紹介します。
AWS Lambdaを使うときの6つの注意点
同時実行数に制限がある
同時実行数とは1秒間に同時に実行することができる関数の上限のことです。例えば、AWS Lambdaの場合、実行に5秒かかる関数が毎秒1件ずつ起動される場合は、最大の同時実行数が5となります。
AWS Lambdaでは上限値は同一アカウントの同一リージョン内で1,000までとなっています。上限に達すると、それ以上の関数の呼び出しは制限（スロットリング）されます。
スロットリングを回避するためにはいくつか方法があります。
その1つが「リトライ処理を組み込む」という方法です。同期処理の場合、スロットリングが発生するとLambda関数は429エラーを返却します。このエラーが発生した場合、関数の呼び出し元でリトライ処理を実行します。非同期処理の場合は最大6ん時間間隔を空けて自動的にリトライします。
また、AWS Lambdaの場合、上限緩和の申請をすれば、同時実行数の増加が認められることがあります（ただし、必ず認められるとは限りません）。アーキテクチャを分析し、改善の余地がないかを検討した上で申請をしてみてください。
実行時間に制限がある
実行時間にも制限があります。
AWS Lambdaの場合、実行時間は15分以内となっています。このため、15分以上の時間がかかる処理を実行することができないため、処理時間が15分以上にならないよう処理を分割して並列化する処理設計が必要です。とはいえ、並列化すると同時実行数の制限に引っかかる可能性があるため、この点も考慮しながら対応しなければなりません。
また、Lambda以外のサーバーレスサービスの制限にも考慮が必要です。
例えば、サーバーレスアプリケーションの構築としてよくあるのが、API Gateway + Lambdaという組み合わせです。この場合はAPI Gatewayの制限にも考慮する必要があります。
API Gatewayの場合、最大29秒でタイムアウトとなる仕様となっています。このため、29秒以内にLambda関数から値を返却し、以降は非同期で処理を実行するなどです。
もし処理の分割・並列化が難しい場合は15分以上かかる処理をAmazon EC2で実装するなどの対応が必要です。
モニタリングやエラー解析が複雑となる
モニタリングやエラー解析が複雑となることにも注意が必要です。
サーバーレスアプリケーションでは複数の関数が関連して動作します。このため、一般的なアプリケーションよりもモニタリングが難しいのが実情です。
また、Lambdaでは、Node.jsやPythonなどの複数の言語にランタイムで使用できるようになっています。しかし、Lambdaで提供されているランタイムの大部分が内部に隠蔽されているため、問題が発生した時の解析や切り分けが難しくなります。
この時、AWSのサービスの1つである「AWS X-Ray」を使用することでトラブルシューティングに必要な情報を収集することができます。AWS X-Rayとはリクエストに対するモニタリング情報を収集するサービスです。Lambdaコンソールから該当の関数を選択し、AWS X-Rayでアクティブトレースを有効にすることで使用できます。
なお、エラーログのモニタリングはAWSのサービスの1つであるCloudWatchを利用して行います。
AWS Lambda単体での使用はできない
AWS Lambda単体ではLambda関数の実行ができません。Lambda関数を実行させるためには、他のサービスリソースで処理を起動させるきっかけとなるトリガーを設定する必要があります。
なお、Lambdaを実行するトリガーには大きく分けて2種類あります。1つめはトリガーと同期して関数を起動するタイプです。これは、API Gatewayや手動実行が該当します。2つめはイベントが発生したことを検知して非同期で関数を実行するタイプです。これはAmazon S3、CloudWatch Log、CloudWatch Eventsからの実行などが該当します。
重複起動の可能性があり得る
非同期で関数を実行する場合は重複起動の可能性があります。非同期処理でLambdaがイベントを処理できずにエラーとなった場合、自動的に2回再試行されるためです。
重複起動しないためには設計時の考慮が必要です。Lambdaが起動する時にDynamoDBにトリガーとなったイベントを保存します。そして、重複起動が発生した場合はDynamoDBに保存されているイベントを確認して後続処理を動かさないなどです。
このように設計時に重複処理を発生させないように対応することで防ぐことができます。
クラウドベンダーに依存する
サーバーレスの仕組みを利用する場合、利用するクラウドベンダーのサービスに依存します。例えば、GCPでサーバーレスの仕組みを利用してサービスを構築後、何らかの理由でAWSに移行する場合、作り直しが必要なほど移行が困難です。なぜなら、AWSとGCPではサーバーレスの仕組みや実装方式が異なるためです。これは、オンプレミスで作成したシステムをAWSに移行する場合も同様です。
サーバーレスに移行を行うためにほぼ作り直しが必要となるため莫大なコストがかかることになります。このため、一度Lambdaでサービスを構築した場合はAWSに依存することとなります。このため、「AWSでシステムを構築・運用する」という覚悟が必要です。
まとめ
この記事ではAWS Lambdaを利用するときの注意点を6つ紹介しました。
AWS Lambdaを用いてサーバーレスアプリケーションを構築するにあたり、同時実行数や実行時間などの注意が必要です。なお、AWS Lambda単体ではLambda関数を実行することができません。API GatewayやAmazon S3など、他のサービスリソースと組み合わせて構築しなければなりません。
また、サーバーレスでアプリケーションを構築する時にはクラウドベンダーに依存することになります。なぜならサーバーレスの仕様がクラウドベンダーそれぞれで異なり、独自仕様となっているからです。AWSを利用するのであれば「AWSでシステムを構築・運用する」という覚悟が必要です。
このように、AWS Lambdaを利用してサーバーレスアプリケーションを構築するには、その特徴を理解することが必要です。注意点を把握して目的に合ったアプリケーションを構築しましょう。
