サーバーレス関数の活用

[アーティクル]
05/26/2023

ヒント

このコンテンツは eBook の「Azure 向けクラウドネイティブ .NET アプリケーションの設計」からの抜粋です。.NET Docs で閲覧できるほか、PDF として無料ダウンロードすると、オンラインで閲覧できます。

物理マシンの管理からクラウド機能の利用までの範囲で、サーバーレスは極端に存在します。ユーザーが責任を負うのは自分のコードだけであり、コードの実行時にのみ課金されます。 Azure Functions は、クラウドネイティブアプリケーションにサーバーレス機能を構築する方法を提供します。

サーバーレスとは

サーバーレスは、クラウドコンピューティングの比較的新しいサービスモデルです。それは、サーバーがオプションであるという意味ではありません。コードは、どこかのサーバー上で実行されます。違うのは、アプリケーションチームがサーバーインフラストラクチャの管理についてまったく関与しないということです。代わりに、クラウドベンダーがこの責任を担います。開発チームは、基礎の仕組みではなく、ビジネスソリューションを顧客に提供することによって生産性を向上させます。

サーバーレスコンピューティングでは、イベントによってトリガーされるステートレスコンテナーを使用してサービスをホストします。需要に応じてスケールアウトやスケールインできます。 Azure Functions のようなサーバーレスプラットフォームは、キュー、イベント、ストレージなどの他の Azure サービスと緊密に統合されています。

サーバーレスによって解決される課題

サーバーレスプラットフォームにより、時間とコストがかかる多くの問題が対処されます。

コンピューターとソフトウェアライセンスの購入
コンピューターとそのネットワーク、電力、A/C の要件のハウジング、セキュリティ保護、構成、保守
オペレーティングシステムとソフトウェアの修正プログラムの適用とアップグレード
アプリケーションソフトウェアをホストするための Web サーバーまたはコンピューターサービスの構成
プラットフォーム内でのアプリケーションソフトウェアの構成

多くの企業は、ハードウェアインフラストラクチャの問題をサポートするために大きな予算を割り当てています。クラウドに移行すると、これらのコストを削減できます。アプリケーションをサーバーレスに移行すると、それらをなくすことができます。

マイクロサービスとサーバーレス関数の違い

通常は、マイクロサービスにより、オンライン eコマースサイト用のショッピングカートなどのビジネス機能がカプセル化されます。ユーザーがショッピング体験を管理できるようにする複数の操作がそれによって公開されます。一方、関数は小さな軽量のコードブロックであり、イベントに応答して単一用途の操作が実行されます。マイクロサービスは、通常、要求に応答するように構成されます (多くの場合、インターフェイスから)。要求は、HTTP Rest または gRPC ベースでもかまいません。サーバーレスサービスは、イベントに応答します。そのイベントドリブンアーキテクチャは、実行時間の短いバックグラウンドタスクの処理に最適です。

サーバーレスに適したシナリオ

サーバーレスにより、トリガーに応答して呼び出される、実行時間の短い個々の関数が公開されます。このため、バックグラウンドタスクの処理に最適です。

アプリケーションでは、ワークフローのステップとしてメールを送信することが必要になる場合があります。マイクロサービス要求の一部として通知を送信する代わりに、メッセージの詳細をキューに配置します。 Azure 関数により、メッセージをデキューし、メールを非同期に送信することができます。これにより、マイクロサービスのパフォーマンスとスケーラビリティが向上します。キューベースの負荷平準化を実装すると、メールの送信に関連するボトルネックを回避できます。さらに、このスタンドアロンサービスは、さまざまなアプリケーションでユーティリティとして再利用できます。

キューとトピックからの非同期メッセージングは、サーバーレス関数をトリガーするための一般的なパターンです。ただし、Azure Functions は、Azure Blob Storage への変更など、他のイベントによってトリガーすることもできます。画像のアップロードをサポートするサービスでは、Azure 関数で画像サイズの最適化を行わせることができます。 Azure Blob Storage への挿入によって関数を直接トリガーすることができ、マイクロサービスの操作が複雑になることはありません。

多くのサービスには、ワークフローの一部として長時間実行されるプロセスがあります。多くの場合、これらのタスクは、ユーザーによるアプリケーションの操作の一部として実行されます。これらのタスクによってユーザーが待たされ、エクスペリエンスに悪影響を与える可能性があります。サーバーレスコンピューティングを使用すると、低速のタスクをユーザー操作ループの外に移動する優れた方法が提供されます。これらのタスクは必要に応じてスケーリングでき、アプリケーション全体をスケーリングする必要はありません。

サーバーレスを避ける必要がある場合

サーバーレスソリューションは、オンデマンドでプロビジョニングとスケーリングが行われます。新しいインスタンスが呼び出されるときは、コールドスタートが一般的な問題になります。コールドスタートとは、このインスタンスのプロビジョニングにかかる時間のことです。通常、この遅延は数秒ですが、さまざまな要因によってさらに長くなることがあります。プロビジョニングが完了すると、定期的に要求を受信している限り、1 つのインスタンスが保持されます。ただし、サービスが呼び出される頻度が低い場合は、Azure によってメモリから削除され、再度呼び出されたときにコールドスタートが必要になることがあります。コールドスタートは、関数が新しいインスタンスにスケールアウトするときにも必要です。

図 3-9 は、コールドスタートのパターンを示したものです。アプリがコールドのときに必要になる追加の手順に注意してください。

Cold versus warm start 図 3-9。コールドスタートとウォームスタートの比較。

コールドスタートを完全に回避するには、従量課金プランから専用プランに切り替えることができます。また、Premium プランにアップグレードして、1 つまたは複数の事前ウォーミングされたインスタンスを構成することもできます。このようにすると、別のインスタンスを追加する必要があるときに、既に稼働できる状態になっています。これらのオプションは、サーバーレスコンピューティングに関連するコールドスタートの問題を軽減するのに役立ちます。

クラウドプロバイダーは、コンピューティングの実行時間とメモリの消費量に基づいて、サーバーレスに課金されます。実行時間の長い操作やメモリ消費の多いワークロードは、常にサーバーレスに最適な候補というわけではありません。サーバーレス関数には、短時間で完了できる小規模の作業が好まれます。ほとんどのサーバーレスプラットフォームでは、数分以内に個々の関数が完了する必要があります。 Azure Functions のタイムアウト期間の既定値は 5 分で、最大 10 分まで構成できます。 Azure Functions Premium プランを利用すると、この問題も軽減できます。既定のタイムアウトは 30 分で、無制限に構成できます。コンピューティング時間はカレンダー時間ではありません。 Azure Durable Functions フレームワークを使用するさらに高度な関数は、数日間実行を一時停止することがあります。課金は、関数がウェイクアップして処理が再開されたときの、実際の実行時間に基づいて行われます。

最後に、アプリケーションのタスクに Azure Functions を利用すると、複雑さが増します。最初に、モジュール形式の疎結合のデザインで、アプリケーションを設計することをお勧めします。その後、複雑さが増すのを正当化できる利点がサーバーレスにあるかどうかを明らかにします。

前へ次へ

次の方法で共有