サーバーレス関数の活用

物理マシンの管理からクラウド機能の活用まで、サーバーレスは端に位置しています。 自分の責任は自分のコードだけであり、コードの実行時にのみ支払います。 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 を利用すると、複雑さが増します。 まず、モジュール式の疎結合設計でアプリケーションを設計することをお勧めします。 次に、追加の複雑さを正当化するサーバーレスが提供する利点があるかどうかを特定します。