多くの場合、機能を異なる関数に分離すると、パフォーマンスが向上し、アプリケーションを維持しやすくなり、スケーラビリティが向上します。ただし、Lambda の「モノリス」は、既存のアプリケーションを移行する際に便利な足がかりになる場合があります。
単一の Lambda 関数にはどの程度の機能を含めるべきですか。
関数は、マイクロサービス内の AWS サービス間のデータフローにおいて、単一のタスクを実行する必要があります。ただし、機能タスクが小さすぎると、アプリケーションのレイテンシーが増加し、多数の関数の管理時にオーバーヘッドが発生する可能性があります。関数の正しい範囲は、ユースケースによって決まります。
Lambda ベースのアプリケーションは複数のリージョンで動作できますか。
はい。DynamoDB や Amazon S3 を含め、多くのサーバーレスサービスは複数のリージョンにレプリケーションおよびサポートを提供します。Lambda 関数はデプロイパイプラインの一部として複数のリージョンにデプロイでき、API Gateway はこの設定をサポートするように設定できます。これを実現する方法を示す「アーキテクチャの例
Lambda 関数は時間指定スケジュールで実行できますか。
はい。EventBridge のルールでスケジュールされた式を使用して、Lambda 関数をトリガーすることができます。この形式では、cron 構文を使用して 1 分単位で設定できます。例については、このチュートリアルを参照してください。
呼び出し間で Lambda 関数に状態を保持させるには、どうすればよいですか。
多くの場合、DynamoDB テーブルが理想的な保持方法です。DynamoDB テーブルは低レイテンシーのデータアクセスを提供し、Lambda サービスに合わせてスケールできるためです。このサービスを使用している場合、Amazon EFS for Lambda
どのようなタイプのワークロードがイベント駆動型アーキテクチャに適していますか。
イベント駆動型アーキテクチャは、ネットワークを使用して異なるシステム間で通信するため、レイテンシーが変動します。リアルタイム取引システムなどの、非常に低いレイテンシーを必要とするワークロードでは、この設計は最適な選択肢ではない場合があります。しかし、スケーラビリティと可用性の高いワークロードや、トラフィックパターンが予測不可能なワークロードの場合は、イベント駆動型アーキテクチャがこれらの需要を満たす効果的な方法を提供できます。
Lambda サービスの関数に 15 分の制限があるのはなぜですか。
Lambda 関数はイベントを処理するために存在し、ほとんどのイベントは非常に迅速に処理されます。通常、本番環境の呼び出しの大部分は 1 秒未満で処理されます。関数の期間は、1 つのイベントを処理するためにかかる時間によって決まります。一部のコンピューティング負荷の高いワークロードは数分かかることがありますが、完了するまでに 15 分かかるものはほとんどありません。
より長い期間が必要になる場合は、関数コードが単一のイベントを処理し、単一のタスクを実行し、このドキュメントで説明されているベストプラクティスを使用していることを確認します。多くの場合、単一のイベントを処理し、処理に必要な時間を短縮するように関数を再設計できます。
予約された同時実行数のある関数が受信トラフィックに合わせてスケールされないのはなぜですか？
Lambda 関数の予約された同時実行数は、キャパシティの最大値としても機能します。合計同時実行数に対するソフト制限を引き上げても、この動作には影響しません。より多くのトラフィックを処理するために予約された同時実行数を持つ関数が必要な場合、予約された同時実行数の値を更新できます。これにより、関数の最大スループットが向上します。
プロビジョニングされた同時実行数を持つ関数でコールドスタートが発生する理由は?
関数に X-Ray モニタリングを追加することで、Lambda のスケールアップ時のコールドスタートを測定できます。プロビジョニングされた同時実行数を使用する関数は、実行環境が呼び出し前に準備されるため、コールドスタート動作を示しません。ただし、プロビジョニングされた同時実行数は、$LATEST バージョンではなく、関数の特定のバージョンまたはエイリアスに適用する必要があります。コールドスタート動作がまだ確認される場合、プロビジョニングされた同時実行数が設定されたエイリアスのバージョンを呼び出していることを確認してください。
Lambda 関数に使用するのに最適なランタイムは何ですか？
Lambda はランタイムの選択に依存しません。シンプルな関数の場合、Python や Node.js などのインタープリター言語が最速のパフォーマンスを提供します。より複雑な計算を使用する関数の場合、Java などのコンパイル済み言語は初期化に時間がかかることがありますが、Lambda ハンドラーでは迅速に実行されます。ランタイムの選択は、開発者の好みや言語の精通度にも影響されます。
SDK バージョンが変更されないようにするにはどうすればよいですか？
AWS が新しいサービスや機能をリリースすると、組み込み SDK は予告なく変更される場合があります。SDK バージョンは、必要な特定のバージョンで Lambda レイヤーを作成することでロックできます。その後、サービスに組み込まれたバージョンが変更されても、関数は常にレイヤーのバージョンを使用します。
Lambda ベースのアプリケーションが、予想されるトラフィックに合わせてスケールできることをテストするにはどうすればよいですか？
アプリケーションが予想どおりにスケールされることを確認するには、開発プロセスで負荷テストを使用して、予想されるトラフィックレベルをシミュレートします。
プロビジョニングされた同時実行数にはどのワークロードが適していますか?
プロビジョニングされた同時実行数は、2 桁のミリ秒台の応答時間で関数を利用できるように設計されています。一般に、この機能のメリットを最も享受するのはインタラクティブワークロードです。ウェブアプリケーションやモバイルアプリケーションなど、これらはユーザーがリクエストを開始するアプリケーションであり、レイテンシーに最も敏感です。データ処理パイプラインなどの非同期ワークロードは、レイテンシーの影響を受けにくいことが多いため、通常はプロビジョニングされた同時実行数は必要ありません。
Lambda 関数が出力をログ記録しない理由は?
Lambda 関数が CloudWatch にログを出力していない場合は、まず関数が呼び出し元によって呼び出されていることを確認します。呼び出し元サービスのログと、イベントが関数をトリガーしたことを示す CloudWatch メトリクスを確認します。次に、CloudWatch Logs で関数を確認します。関数のカスタムコードに他の明示的なログ記録がない場合でも、すべての Lambda 関数は 3 行をログに記録します。
関数が呼び出されているにもかかわらず CloudWatch にログ記録が見られない場合は、関数のアクセス許可を確認してください。IAM ロールにはログ記録のアクセス許可が含まれている必要があります。そうでない場合、関数はサービスにログを書き込むことができません。AWSLambdaBasicExecutionRole ポリシーを関数の実行ロールにアタッチし、これらのアクセス許可を付与できます。
