Lambda マネージドインスタンスのベストプラクティス - AWS Lambda
キャパシティープロバイダーの設定インスタンスタイプの選択Function Configurationスケーリング設定セキュリティコスト最適化モニタリングとオブザーバビリティランタイム固有の考慮事項次のステップ

Lambda マネージドインスタンスのベストプラクティス

キャパシティープロバイダーの設定

キャパシティープロバイダーを信頼レベル別に分けます。セキュリティ要件が異なるワークロード用ごとに、別々のキャパシティープロバイダーを作成します。キャパシティープロバイダーはセキュリティ境界として機能するため、同じキャパシティープロバイダーに割り当てられたすべての関数は相互に信頼されている必要があります。

わかりやすい名前を使用します。キャパシティープロバイダーに名前を付け、使用目的と信頼レベルを明確に示します (例: production-trusted、dev-sandbox)。これにより、チームは各キャパシティープロバイダーの目的とセキュリティ体制を理解できます。

複数のアベイラビリティーゾーンを使用します。キャパシティープロバイダーを作成するときに、複数のアベイラビリティーゾーンにまたがるサブネットを指定します。Lambda は AZ の耐障害性を確保するため、デフォルトで 3 つのインスタンスを起動し、関数の高可用性を実現します。

インスタンスタイプの選択

Lambda にインスタンスタイプを選択させます。デフォルトでは、Lambda はワークロードに最適なインスタンスタイプを選択します。利用可能なインスタンスタイプの数を制限すると可用性が低下する可能性があるため、Lambda マネージドインスタンスが選択したインスタンスタイプを使用することをお勧めします。

特定の要件に応じてインスタンスタイプを指定します。特定のハードウェア要件がある場合は、互換性のあるインスタンスのリストに許可されたインスタンスタイプを設定します。例えば、次のようになります。

  • 高いネットワーク帯域幅を必要とするアプリケーションの場合は、いくつかのインスタンスタイプを選択します。

  • コスト制約のあるテスト環境または開発環境の場合は、m7a.large などの小さいインスタンスタイプを選択します。

Function Configuration

適切なメモリと vCPU 設定を選択します。関数の複数同時実行をサポートしているメモリと vCPU 設定を選択します。サポートされている関数の最小サイズは 2GB と 1 vCPU です。

  • Python アプリケーションでは、Python が複数同時実行を処理する方法のため、メモリと vCPU の比率 (4 対 1 または 8 対 1 など) が高い方を選択します。

  • IO をほとんど実行しない CPU 集約型のオペレーションまたは関数の場合は、複数の vCPU を選択します。

  • ウェブサービスやバッチジョブなどの IO 負荷の高いアプリケーションでは、複数同時実行が最適です。

最大同時実行数を適切に設定します。Lambda は、リソースの消費とスループットのバランスをとる最大同時実行数の適切なデフォルトを選択します。関数のリソース使用量に基づいてこの設定を調整します。

  • 関数呼び出しで使用する CPU が非常に少ない場合、最大同時実行数を増やす (vCPU あたり最大 64 個)

  • アプリケーションが大量のメモリを消費し、CPU が非常に少ない場合、最大同時実行数を減らす

同時実行数が非常に少ない実行環境では、スロットリングが発生したり、スケーリングが困難になる可能性があることに注意してください。

スケーリング設定

適切なターゲットリソース使用率を設定します。デフォルトでは、Lambda はスロットルが発生しないよう、トラフィックが 5 分以内に 2 倍へ増加しても処理可能なヘッドルームを保持しています。ワークロードの特性に基づいてこれを調整します。

  • スロットルの影響を受けにくい非常に安定したワークロードやアプリケーションの場合は、使用率を高めてコストを削減するために、ターゲットを高レベルに設定します。

  • トラフィックがバーストする可能性があるワークロードの場合、リソースターゲットを低レベルに設定して追加のヘッドルームを維持します。

トラフィックの増加を計画します。トラフィックが 5 分以内に 2 倍以上になると、Lambda がインスタンスと実行環境をスケールアップするため、スロットリングが表示されることがあります。迅速なスケールアップ期間中に可能性のあるスロットリングを処理するようにアプリケーションを設計します。

セキュリティ

PassCapacityProvider アクセス許可に最小特権を適用します。必要なキャパシティープロバイダーにのみ lambda:PassCapacityProvider アクセス許可を付与します。リソースレベルのアクセス許可を使用して、ユーザーが関数に割り当てることができるキャパシティープロバイダーを制限します。

キャパシティープロバイダーの使用状況をモニタリングします。AWS CloudTrail を使用して、キャパシティープロバイダーの割り当てとアクセスパターンをモニタリングします。これにより、不正アクセス試行の検知が可能となり、セキュリティポリシーへの準拠が保証されます。

信頼できないワークロードを分離します。信頼できないワークロード間のセキュリティ分離を行う上でコンテナに依存するべきではありません。相互に信頼されていないワークロードを分離するには、別個のキャパシティープロバイダーを使用します。

コスト最適化

EC2 料金オプションを活用します。EC2 Savings Plans とリザーブドインスタンスを活用してコストを削減します。これらの料金オプションは、基本的な EC2 コンピューティングに適用されます (15% の管理料金は割引されません)。

定常状態のワークロード向けに最適化します。Lambda マネージドインスタンスは、大量のトラフィックが予測できる定常状態の関数に最適です。バーストトラフィックパターンでは、Lambda (デフォルト) の方が費用対効果が高い場合があります。

リソース使用率をモニタリングします。CloudWatch メトリクスを追跡して、CPU とメモリの使用率を把握します。実際の使用パターンに基づいて関数のメモリ割り当てとインスタンスタイプの選択を調整し、コストを最適化します。

モニタリングとオブザーバビリティ

キャパシティープロバイダーのメトリクスをモニタリングします。CPUUtilization、MemoryUtilization、vCPUAvailable、MemoryAvailable などのキャパシティープロバイダーレベルのメトリクスを追跡して、ワークロードに対して十分なリソースを利用できるようにします。

実行環境メトリクスをモニタリングします。ExecutionEnvironmentConcurrency や ExecutionEnvironmentConcurrencyLimit などの実行環境レベルのメトリクスを追跡して、スケーリング動作を理解し、発生可能性のあるスロットリングを特定します。

CloudWatch アラームを設定します。主要なメトリクスの CloudWatch アラームを作成して、問題を事前に特定します。

  • CPU またはメモリの使用率が高い

  • 使用可能な容量

  • 同時実行数の上限に近づいている状態

ランタイム固有の考慮事項

ランタイム固有のベストプラクティスに従います。各ランタイムは、複数同時実行を別々の方法で処理します。詳細な推奨事項については、ランタイム固有のガイドを確認してください。

  • Java: リクエスト固有の状態に対してスレッドセーフコレクション、AtomicInteger、および ThreadLocal を使用する

  • Node.js: すべてのリクエスト固有の状態に対して InvokeStore を使用し、グローバル変数を回避する

  • Python: リクエスト ID を使用して、/tmp で一意のファイル名を使用し、プロセスベースのメモリ分離を検討する

スレッドセーフと同時実行に問題がないかテストします。本番環境にデプロイする前に、スレッドセーフの問題、競合状態、同時ロード時の適切な状態分離について、関数を徹底的にテストします。

次のステップ