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

サーバーレス .NET を検討する

概要:

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

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

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

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

コストへの影響

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

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

コスト最適化の推奨事項

Lambda 関数のサイズを適切に設定する

適切なサイズ設定は、.NET ベースの Lambda 関数のコスト最適化に不可欠なプラクティスです。このプロセスでは、コードを変更することなく、パフォーマンスとコスト効率のバランスを取る最適なメモリ設定を特定します。

Lambda 関数のメモリを 128～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 の「How to execute the state machine」を参照してください。

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

アイドル待機時間を回避する

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

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

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

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

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

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

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

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

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

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

その他のリソース