翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

サーバーレス を検討してください。NET

概要

サーバーレスコンピューティングは、アプリケーションを構築およびデプロイするための一般的なアプローチとなっています。これは主に、サーバーレスアプローチが最新のアーキテクチャを構築するときに提供するスケーラビリティと俊敏性が原因です。ただし、一部のシナリオでは、サーバーレスコンピューティングのコストへの影響を考慮することが重要です。

Lambda は、デベロッパーが専用サーバーを必要とせずにコードを実行できるようにするサーバーレスコンピューティングプラットフォームです。Lambda は、 にとって特に魅力的なオプションです。NET は、インフラストラクチャコストの削減を検討しているデベロッパーにとって魅力的なオプションです。Lambda を使用すると、 NETデベロッパーは、スケーラビリティが高く、費用対効果の高いアプリケーションを開発およびデプロイできます。サーバーレスアプローチを使用すると、デベロッパーはアプリケーションリクエストを処理するサーバーをプロビジョニングしなくなります。代わりに、デベロッパーはオンデマンドで実行される関数を作成できます。これにより、サーバーレスアプローチは、仮想マシンの実行、管理、スケーリングよりもスケーラブルで管理しやすく、潜在的にコスト効率が高くなります。その結果、アプリケーションが使用するリソースに対してのみ支払いが行われ、リソースの使用率不足やサーバーメンテナンスコストを心配する必要はありません。

デベロッパーは、最新のクロスプラットフォーム .NET バージョンを使用して、高速、効率的、費用対効果の高いサーバーレスアプリケーションを構築できます。。NET コア以降のバージョンは、以前の よりもサーバーレスプラットフォームでの実行に適した無料のオープンソースフレームワークです。NET フレームワークバージョン。これにより、デベロッパーは開発時間を短縮し、アプリケーションのパフォーマンスを向上させることができます。最新の 。NET は、C# や F# など、さまざまなプログラミング言語もサポートしています。このため、クラウドで最新のアーキテクチャを構築しようとしているデベロッパーにとって魅力的なオプションです。

このセクションでは、Lambda をサーバーレスオプションとして使用してコスト削減を実現する方法について説明します。Lambda 関数の実行プロファイルを微調整し、Lambda 関数のメモリ割り当てのサイズを適正化し、ネイティブ AOTを使用して、Graviton ベースの関数に移動することで、コストをさらに最適化できます。

コストへの影響

コストを削減できる量は、サーバーレス関数が実行する実行回数と各関数のメモリ量、期間など、いくつかの要因によって異なります。 は、1 か月あたり 100 万件の無料リクエストと 1 か月あたり 40 万 GB 秒のコンピューティング時間を含む無料利用枠 AWS Lambda を提供します。これらの無料利用枠の制限前後にあるワークロードの月額コストを大幅に削減できます。

また、Lambda 関数をターゲットとしてロードバランサーを使用する場合にも、追加コストが発生する場合があります。これは、Lambda ターゲット のロードバランサーによって処理されるデータの量として計算されます。

コスト最適化に関する推奨事項

Lambda 関数の適切なサイズ

適切なサイジングは、. NETベースの Lambda 関数のコスト最適化に不可欠です。このプロセスでは、コードを変更することなく、パフォーマンスと費用対効果のバランスが取れた最適なメモリ設定を特定します。

Lambda 関数のメモリを 128 MB から 10,240 MB まで設定することで、呼び出し中に使用可能な vCPU の量も調整できます。これにより、メモリまたは CPUバインドされたアプリケーションが実行中に追加のリソースにアクセスできるようになるため、呼び出し時間と全体的なコストが削減される可能性があります。

ただし、. NETベースの Lambda 関数に最適な設定を特定することは、特に変更が頻繁に行われる場合、手動および時間のかかるプロセスになる可能性があります。AWS Lambda Power Tuning ツールは、サンプルペイロードに対して一連のメモリ設定を分析することで、適切な設定を特定するのに役立ちます。

例えば、. NETベースの Lambda 関数のメモリを増やすと、パフォーマンスに影響を与えることなく、総呼び出し時間が向上し、コストを削減できます。関数に最適なメモリ設定は異なる場合があります。 AWS Lambda Power Tuning ツールは、各関数の最も費用対効果の高い設定を特定するのに役立ちます。

次のグラフ例では、この Lambda 関数のメモリが増加するにつれて、合計呼び出し時間が改善されます。これにより、関数の元のパフォーマンスに影響を与えることなく、実行全体のコストを削減できます。この関数の場合、関数の最適なメモリ設定は 512 MB です。これは、各呼び出しの合計コストに対してリソース使用率が最も効率的であるためです。これは関数ごとに異なり、Lambda 関数で ツールを使用して、適切なサイズ設定のメリットがあるかどうかを特定できます。

この演習は、新しい更新がリリースされたときに、統合テストの一環として定期的に完了することをお勧めします。更新頻度が低い場合は、定期的にこの演習を実行して、関数が調整され、適切なサイズであることを確認します。Lambda 関数に適したメモリ設定を特定したら、プロセスに適切なサイズを追加できます。 AWS Lambda Power Tuning ツールは、新しいコードのリリース中に CI/CD ワークフローで使用できるプログラム出力を生成します。これにより、メモリ設定を自動化できます。

AWS Lambda Power Tuning ツールを無料でダウンロードできます。ツールの使用方法については、「 でステートマシンを実行する方法」を参照してください GitHub。

Lambda はネイティブ もサポートしておりAOT、これにより . NETアプリケーションが事前にコンパイルされます。これにより、 NET関数の実行時間を短縮することで、コストを削減できます。ネイティブAOT関数の作成の詳細については、「Lambda ドキュメント」の「ネイティブAOTコンパイルによる関数NET」を参照してください。

アイドル状態の待機時間を避ける

Lambda 関数の期間は、請求の計算に使用される 1 つのディメンションです。関数コードがブロッキング呼び出しを行うと、レスポンスの受信を待機する時間に対して課金されます。この待機時間は、Lambda 関数が連鎖している場合、または関数が他の関数のオーケストレーターとして機能している場合に長くなる可能性があります。バッチオペレーションや注文配信システムなどのワークフローがある場合、管理オーバーヘッドが追加されます。さらに、Lambda の最大タイムアウト 15 分以内にすべてのワークフローロジックとエラー処理を完了できない場合があります。

関数コードでこのロジックを処理する代わりに、ワークフローのオーケストレーターAWS Step Functionsとして使用するソリューションを再設計することをお勧めします。標準ワークフローを使用する場合、ワークフローの合計期間ではなく、ワークフロー内の状態遷移ごとに請求されます。さらに、再試行、待機条件、エラーワークフロー、コールバックのサポートを 状態に移行して、Lambda 関数がビジネスロジックに集中できるようにします。詳細については、 AWS コンピューティングブログのAWS Lambda 「コストの最適化」パート 2 を参照してください。

Graviton ベースの関数に移動する

次世代 Graviton2 プロセッサを搭載した Lambda 関数が一般公開されました。ARMベースのプロセッサアーキテクチャを使用する Graviton2 関数は、さまざまなサーバーレスワークロードに対して、最大 19% のパフォーマンスを 20% 低コストで提供するように設計されています。レイテンシーが小さく、パフォーマンスが向上する Graviton2 プロセッサを搭載した 関数は、ミッションクリティカルなサーバーレスアプリケーションのパワーアップに最適です。

Graviton ベースの Lambda 関数への移行は、 にとってコスト効率の高いオプションです。NETLambda コストの最適化を検討しているデベロッパーにとっては、 です。Graviton ベースの関数は、従来の x86 プロセッサの代わりに ARMベースのプロセッサを使用します。これにより、パフォーマンスを犠牲にすることなく、大幅なコスト削減につながる可能性があります。

Graviton ベースの関数に移行するにはいくつかの利点がありますが、考慮すべき課題や考慮事項もあります。例えば、Graviton ベースの関数では Amazon Linux 2 を使用する必要があります。NETこれは、すべての アプリケーションと互換性がない場合があります。さらに、 ARMベースのプロセッサと互換性のないサードパーティーのライブラリや依存関係との互換性に問題がある可能性があります。

を実行している場合。NET Lambda でアプリケーションをフレームワーク化し、サーバーレスを活用する場合は、 の Porting Assistant を使用して、アプリケーションを最新の NETに移植することを検討できます。 NETこれにより、レガシー .NET アプリケーションの最新の . への移植を加速しNET、アプリケーションを Linux で実行できるようになります。

次のグラフは、素数を計算する関数の x86 アーキテクチャと ARM/Graviton2 アーキテクチャの結果を比較しています。

関数は単一のスレッドを使用しています。メモリが 1.8 GB で設定されている場合、両方のアーキテクチャの最小期間が報告されます。さらに、Lambda 関数は 1 v 以上にアクセスできますがCPU、この場合、関数は追加の電力を使用できません。同じ理由から、コストは最大 1.8 GB のメモリで安定しています。メモリが増えると、このワークロードには追加のパフォーマンス上の利点がないため、コストが増加します。Graviton2 プロセッサは、このコンピューティング集約型関数のパフォーマンスを向上させ、コストを削減します。

Graviton で および ARMベースのプロセッサを使用するように関数を設定するには、以下を実行します。

追加リソース