AWS Fargate または AWS Lambda?

Fargate: AWS Fargate はコンテナ用のサーバーレスコンピューティングエンジンで、Amazon ECS でオーケストレーションに使用されます。Docker コンテナにパッケージ化できるプログラミング言語またはランタイム環境をサポートしています。この柔軟性により、アプリケーションのニーズに合ったほぼすべての言語、フレームワーク、またはライブラリを使用できます。Python、Java、、Node.jsGo、.NET、Ruby、PHP、またはカスタム言語や環境も使用できます。Fargate は、コンテナにカプセル化されている限り、それらを実行できます。この幅広い言語サポートにより、Fargate はさまざまなアプリケーションの実行に最適です。これには、レガシーシステム、多言語マイクロサービス、最新のクラウドネイティブアプリケーションが含まれます。

Lambda: は、Fargate よりも限られた言語のネイティブサポート AWS Lambda を提供します。Lambda 関数は、イベント駆動型ワークロード専用に構築されています。Lambda は、以下の言語とランタイムを正式にサポートしています。

Lambda はカスタムランタイムもサポートしています。カスタムランタイムでは、独自の言語またはランタイム環境を導入できます。ただし、ネイティブにサポートされているオプションを使用するよりも多くのセットアップと管理が必要です。コンテナイメージから Lambda 関数をデプロイする場合は、 で関数を記述できますRust。 AWS OS 専用のベースイメージを使用し、Rustランタイムクライアントをイメージに含めます。 AWSが提供するランタイムインターフェイスクライアントのない言語を使用する場合は、独自の言語を作成する必要があります。

Lambda は、本質的にイベント駆動型コンピューティング用に設計されています。Lambda 関数は、データ、ユーザーアクション、またはスケジュールされたタスクの変更に応じてトリガーされます。多くの とネイティブに統合されます AWS のサービス。これには、Amazon S3 (ファイルのアップロード時に関数を呼び出すなど）、DynamoDB (データ更新時にトリガーするなど）、API Gateway (HTTP リクエストの処理など) が含まれます。Lambda イベント駆動型アーキテクチャは、イベントにすぐに応答する必要があるアプリケーションに最適です。これらのアプリケーションには永続的なコンピューティングリソースは必要ありません。

Fargate はネイティブにイベント駆動型ではありません。ただし、追加の定型ロジックを使用すると、Amazon SQS や Kinesis などのイベントソースと統合できます。Lambda は、この統合ロジックの大部分を自動的に処理します。Fargate では、これらのサービスの APIs を使用して、この統合を自分で実装する必要があります。

Fargate は、コンテナ化されたアプリケーションを実行するように設計されています。コンテナの CPU、メモリ、ネットワーク設定を定義できる柔軟なランタイム環境を提供します。Fargate はコンテナベースのモデルで動作します。長時間実行されるプロセス、永続的なサービス、特定のランタイム要件を持つアプリケーションをサポートします。Fargate のコンテナは、実行時間にハード制限がないため、無期限に実行できます。これにより、継続的に実行する必要があるアプリケーションに最適です。Fargate のコンテナ再起動ポリシーを使用すると、タスク内の個々のコンテナは、タスク全体を再起動せずに自動的に再起動できます。これにより、マルチコンテナワークロードの耐障害性が向上します。Fargate は、オブザーバビリティが強化された CloudWatch Container Insights と統合されています。この機能を使用すると、コンテナごとの詳細なメトリクスとトレースを取得して、アプリケーションのパフォーマンスをモニタリングできます。

Lambda 関数は、存続期間の短いイベント駆動型タスク用に最適化されています。Lambda 関数の最大実行時間は、呼び出しごとに 15 分です。これにより、Lambda 関数はファイル処理、リアルタイムデータストリーミング、HTTP リクエスト処理などのシナリオに適しています。これらのタスクは短く、長時間実行されるプロセスは必要ありません。

Lambda の耐久性の高い関数を使用すると、複数の呼び出しで状態を最大 1 年間保持できる長時間実行されるワークフローを構築できます。耐久性の高い 関数は、組み込みのエラー処理、自動再試行、障害後の復旧を提供します。耐久性の高い関数 SDK は、JavaScript、TypeScript、、PythonJava、および C# (.NET) で使用できます。待機期間中、関数はコンピューティング料金を発生させずに停止します。永続的な関数を使用すると、以前は永続的なコンピューティング環境が必要だったユースケースに対処できます。

長時間実行されるワークロードに対して耐久性のある関数と Fargate を選択する場合は、実行パターンを検討してください。耐久性のある関数は、人間による承認、スケジュールされた遅延、外部 API コールバックなど、ほとんどの時間を待機に費やすワークフローに対して費用対効果があります。待機期間中はコンピューティング料金が発生しません。Fargate は、データ処理、永続的ネットワーク接続、中断することなくアクティブに維持する必要があるサービスなど、継続的なコンピューティングを必要とするワークロードに適しています。

Lambda では、ランタイム環境がより抽象化されます。基盤となるインフラストラクチャをあまり制御できません。標準関数の場合、各呼び出しは独立しており、ステートレスです。呼び出し間で保持する必要がある状態またはデータは、外部で管理する必要があります。例としては、データベースやストレージサービスなどがあります。

Fargate は、実行中のタスクの数を調整してスケーリングします。これは、コンテナオーケストレーションサービス (Amazon ECS) で定義された目的の状態に基づいています。スケーリングは、Amazon EC2 Auto Scaling を使用して手動または自動で実行できます。詳細については、 AWS Containers ブログの「Under the hood: Amazon ECS and Fargate increase task launch rates」を参照してください。

Fargate では、各タスクは分離された環境で実行されます。スケーリングには、追加のタスクを起動するか、負荷に基づいてタスクを停止する必要があります。Amazon ECS サービススケジューラは、サービスあたり 1 分未満で最大 500 個のタスクを起動できます。これは、ウェブおよびその他の長時間実行されるサービスに適用されます。Amazon ECS は予測スケーリングもサポートしています。履歴パターンを使用して、需要の急増が発生する前にタスクを事前に増やします。CPU およびメモリ使用率のターゲット追跡ポリシーは、20 秒のメトリクス解決をサポートします。これにより、スケーリングシグナルの検出が高速化されます。Amazon ECS は、アベイラビリティーゾーン間でサービスタスクを自動的に再調整することもできます。これにより、高可用性が維持されます。Fargate は Fault Injection Service (FIS) と AWS 統合されています。FIS を使用すると、制御されたフォールトインジェクション実験を実行してアプリケーションの耐障害性をテストできます。

Lambda の場合、同時実行数は、 AWS Lambda 関数が同時に処理している処理中のリクエストの数です。これは Fargate の同時実行とは異なります。利用可能なコンピューティングリソースとネットワークリソースがある限り、各 Fargate タスクは同時リクエストを処理できます。Lambda は、同時実行リクエストごとに、実行環境の個別のインスタンスをプロビジョニングします。関数がより多くのリクエストを受信すると、Lambda は実行環境の数を自動的にスケーリングします。これは、アカウントの同時実行数の制限に達するまで続きます。デフォルトでは、Lambda はアカウントに対して同時実行数の合計を 1,000 回に制限します。この制限は、 のすべての関数に適用されます AWS リージョン。必要に応じて、クォータの引き上げをリクエストできます。

Lambda マネージドインスタンスでは、スケーリングの動作は異なります。マネージドインスタンスは、同時リクエストごとに新しい実行環境をプロビジョニングする代わりに、CPU リソース使用率に基づいて非同期的にスケーリングします。各実行環境は、複数の同時呼び出しを処理できます。このアプローチはリソース使用率を最大化します。定常状態または予測可能なワークロードに適しています。

デフォルトのコンピューティングタイプを使用する Lambda 関数ごとに、同時実行スケーリングレートは 10 秒ごとに 1,000 実行インスタンスです。これは、アカウントの最大同時実行数まで続きます。詳細については、 AWS 「 コンピューティングブログ」の「Lambda 関数は、大量のリクエストを処理するときに 12 倍速くスケーリングされるようになりました」を参照してください。10 秒間のリクエスト数が 1,000 を超える場合、追加のリクエストはスロットリングされます。次のグラフは、アカウントの同時実行数を 7000 と仮定して Lambda スケーリングがどのように機能するかを示しています。

Lambda 関数ではコールドスタートが発生する可能性があります。これらは、しばらくアイドル状態になった後に関数が呼び出されたときに発生します。コールドスタート中、Lambda サービスは新しい実行環境を初期化します。これには、ランタイム、依存関係、関数コードのロードが含まれます。コールドスタート時間は、ランタイム、パッケージサイズ、初期化ロジックに応じて、100 ミリ秒未満から 1 秒以上までさまざまです。Java や C# など、初期化時間が長いランタイムでは、最適化なしでコールドスタートを長くすることができます。コールドスタートは、低レイテンシーの応答を必要とするアプリケーションのパフォーマンスに影響を与える可能性があります。

Lambda のコールドスタートを軽減するには、次の戦略を検討してください。

Fargate は通常、Lambda と同じ方法でコールドスタートの影響を受けません。Fargate タスクを開始する時間は、イメージレジストリからタスクで定義されたコンテナイメージをプルするのにかかる時間に直接相関します。Fargate は、Seekable OCI (SOCI) でインデックス化されたコンテナイメージの遅延ロードもサポートしています。SOCI を使用してコンテナイメージを遅延ロードすると、Fargate で Amazon ECS タスクを起動する時間が短縮されます。Fargate は SOCI インデックスマニフェスト v2 を使用します。これにより、遅延ロードのパフォーマンスが向上します。Fargate でタスクが開始されると、長時間実行されるプロセスになります。常にリクエストを処理する準備ができています。スケーリングイベントに応じて新しいタスクを開始する必要がある場合は、初期化中に多少の遅延が発生する可能性があります。これは通常、Lambda コールドスタートと比較してそれほど重要ではありません。

Fargate は、コンテナ化されたアプリケーションのメモリと CPU リソースの両方をきめ細かく制御します。Fargate でタスクを起動するときに、アプリケーションの CPU とメモリの正確な要件を指定できます。CPU とメモリの割り当ては独立しています。ワークロードに最適な組み合わせを選択できます。0.25 vCPUs から 32 vCPUs までの CPU 値を選択できます。メモリの範囲は、設定に応じて、タスクごとに 0.5 GB～244 GB です。

この柔軟性は、特定のパフォーマンス特性を持つアプリケーションに最適です。例としては、メモリを大量に消費するデータベースや CPU バウンド計算タスクなどがあります。Fargate では、リソースの割り当てを最適化できます。コストとパフォーマンスを効果的にバランスさせることができます。

Lambda では、メモリと CPU がリンクされています。CPU は、選択したメモリ量に比例して自動的に割り当てられます。128 MB から 10 GB までのメモリ割り当てを 1 MB 単位で選択できます。CPU はメモリとともに最大 6 vCPU までスケーリングされます。メモリ設定が高いほど、CPU 電力が増加します。ただし、CPU 割り当て自体を直接制御することはできません。

このモデルは、わかりやすいように設計されています。CPU 設定を管理することなく、メモリ設定をすばやく調整できます。ただし、CPU リソースとメモリリソースの間で特定のバランスを必要とするワークロードでは柔軟性が低い場合があります。Lambda モデルは、メモリのニーズに基づいて簡単にスケーリングするタスクに適しています。複雑または高度に固有のリソース需要があるアプリケーションには最適ではない場合があります。

Fargate にタスクをデプロイすると、タスクは Amazon VPC (Amazon Virtual Private Cloud) で実行されます。これにより、ネットワーク環境を完全に制御できます。セキュリティグループ、ネットワークアクセスコントロールリスト (ACLs)、ルーティングテーブルを設定できます。各 Fargate タスクは、専用のプライベート IP アドレスを持つ独自のネットワークインターフェイスを取得します。必要に応じてパブリック IP アドレスを割り当てることができます。

Fargate は、ロードバランシング ( AWS Elastic Load Balancing を使用）、VPC ピアリング、VPC AWS のサービス 内の他の への直接アクセスなどの高度なネットワーク機能をサポートしています。は、サポートされている への安全なプライベート接続 AWS PrivateLink にも使用できます AWS のサービス。これにより、インターネットを経由することを回避できます。Fargate タスクは Amazon VPC Lattice もサポートしています。これにより、service-to-service接続、セキュリティ、オブザーバビリティが提供されます。Fargate タスクは IPv6-only設定で実行できます。これにより、タスクは IPv6 経由でのみ通信できます。

デフォルトでは、Lambda 関数はマネージドネットワーク環境で実行されます。ネットワークインターフェイスまたは IP アドレスを直接制御することはできません。ただし、Lambda は AWS Hyperplane を使用してカスタマーマネージド VPC にアタッチできます。これにより、VPC 内のリソースへのアクセスを制御できます。

Lambda 関数がカスタマーマネージド VPC にアタッチされると、VPC セキュリティグループとサブネット設定が継承されます。これにより、同じ VPC 内の他の AWS のサービス (RDS データベースなど) と安全にやり取りできます。Lambda は多数の同時実行環境を作成してスケーリングするため、 はそれぞれ独自のデータベース接続を維持します。同時実行数が多いと、データベース接続の制限が枯渇する可能性があります。リレーショナルデータベースにアクセスするには、Amazon RDS Proxy を使用して接続をプールおよび管理します。これにより、同時実行数が多いときに接続が枯渇することを回避できます。

Lambda サービスは、Network Function Virtualization プラットフォームを使用して NAT 機能を提供します。これにより、Lambda VPC がカスタマー VPCs。Lambda 関数を作成または更新するときに、必要な Elastic Network Interface (ENIs) を設定します。また、アカウントの ENIs を複数の実行環境で共有することもできます。これにより、Lambda は関数のスケール時にネットワークリソースをより効率的に使用できます。

ENIsは、リージョンあたり 250 のソフト制限を持つ使い果たせるリソースです。VPC アクセス用に Lambda 関数を設定する場合は、Elastic Network Interface の使用状況をモニタリングします。同じ AZ および同じセキュリティグループの Lambda 関数は ENIs を共有できます。Lambda で同時実行制限を引き上げる場合は、Elastic Network Interface の引き上げが必要かどうかを評価してください。制限に達すると、VPC 対応 Lambda 関数の呼び出しがスロットリングされます。

Fargate の料金は、コンテナに割り当てられたリソースに基づいています。具体的には、タスクごとに選択する vCPU とメモリを意味します。1 秒あたり 1 分の最低料金が請求されます。コストは、アプリケーションが消費するリソースに直接関連しています。アプリケーションがリクエストをアクティブに処理しているかどうかにかかわらず、プロビジョニングした分に対して料金が発生します。Fargate は、特定のリソース設定が必要な予測可能なワークロードに適しています。割り当てられたリソースを調整することで、コストを最適化できます。Fargate Spot は、x86 ベースの Linux ワークロードと ARM ベースの Linux ワークロードの両方で使用できます。これにより、耐障害性のあるアプリケーションのコストを大幅に削減できます。関連サービスには追加料金が発生する場合があります。これには、データ転送、ストレージ、ネットワーク (VPC、Elastic Load Balancing など) が含まれます。

Lambda には、イベント駆動型およびpay-per-executionという異なる料金構造があります。リクエストの数と実行期間に基づいて課金されます。期間はミリ秒単位で測定されます。Lambda は、関数に割り当てるメモリ量も考慮します。コストは、使用するメモリと実行時間に基づいてスケーリングされます。料金モデルには無料利用枠が含まれています。1 か月あたり 100 万件の無料リクエストと 400,000 GB 秒のコンピューティング時間を提供します。これにより、Lambda は少量の散発的なワークロードに対して特にコスト効率が高くなります。

Lambda 料金モデルは、予測不可能なトラフィックパターンやバーストトラフィックパターンのアプリケーションに最適です。実際の関数の呼び出しと実行時間に対してのみ料金が発生します。アイドル状態の容量をプロビジョニングしたり、料金を支払う必要はありません。

Lambda マネージドインスタンスでは、Lambda は EC2 料金モデルを使用するインスタンスベースの料金を提供します。これには、オンデマンド、リザーブドインスタンス、Compute Savings Plansが含まれます。これにより、定常状態または予測可能なワークロードのコスト効率を高めることができます。

Fargate と Lambda の両方が Compute Savings Plans の対象となります。これにより、一貫したコンピューティング使用量のコミットメントと引き換えに、コストを最大 66% 削減できます。これは、1 年または 3 年の期間で 1 時間あたりのドル単位で測定されます。

2 つのサービス間のコストを比較すると、通常、トラフィック量が少ない場合に Lambda で支払う料金が少なくなります。ただし、Fargate の 1 秒あたりのリソース請求は、持続的な高スループットのワークロードに対してより経済的になる傾向があります。リクエスト量が増えると、Lambda のコストは直線的にスケールされます。対照的に、プロビジョニングされたリソース内で処理されたリクエストに関係なく、Fargate のコストは比較的安定しています。