サーバーレス関数の活用

ヒント

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

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

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

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

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

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

前へ次へ