Azure で Event Hubs をサーバーレス関数と統合する

Azure Event Hubs

Azure Functions

Azure Monitor

Azure Event Hubs と Azure Functions を組み合わせて使用するソリューションでは、スケーラブルでコスト効率が高く、ほぼリアルタイムで大量のデータを処理できる、サーバーレス アーキテクチャの利点を得ることができます。 これらのサービスはシームレスに連携しますが、それらの関係をより複雑にする多くの機能、設定、複雑な詳細が存在します。 この記事では、パフォーマンス、回復性、セキュリティ、可観測性、スケールに関する主な考慮事項と手法を詳しく説明することで、この統合を効果的に活用する方法についてのガイダンスを提供します。

Event Hubs の主要な概念

Azure Event Hubs は、拡張性の高いイベント処理サービスであり、1 秒間に数百万件のイベントを受信できます。 Azure Functions 統合のパターンとベスト　プラクティスに進む前に、Event Hubs の基本的なコンポーネントについて理解しておくことをお勧めします。

次の図は、Event Hubs のストリーム処理のアーキテクチャを示しています。

イベント

イベントとは、過去に発生したファクトとして表される通知または状態の変更のことです。 イベントは不変で、イベント ハブ内で永続化されます。Kafka では "トピック" とも呼ばれます。 イベント ハブは、1 つまたは複数のパーティションで構成されます。

メジャー グループ

送信側でパーティションが指定されていない場合、受信したイベントはイベント ハブ内の複数のパーティションに分散されます。 各イベントは、1 つのパーティションにのみ書き込まれ、複数のパーティション間でマルチキャストされることはありません。 各パーティションはログとして機能し、レコードは追加専用のパターンで書き込まれます。 "コミット　ログ" の例えは、パーティション内のシーケンスの最後にイベントを追加する方法の性質を示すためによく使用されます。

複数のパーティションが使用されている場合は、同じイベント ハブ内から並列ログを使用できます。 この動作により、複数の次数の並列処理が可能になるため、コンシューマーのスループットが向上します。

コンシューマーとコンシューマー グループ

1 つのパーティションを、複数のコンシューマーで使用でき、それぞれが独自のオフセットを読み取って、管理します。

Event Hubs ではコンシューマー グループの概念を採用しており、複数のコンシューマー アプリケーションが、イベント ストリームの個別のビューをそれぞれ保有し、独自のペースで独自のオフセットによってストリームを別々に読み取ることができます。

詳細については、Event Hubs の概念と機能の詳細に関するページを参照してください。

Azure Functions でのイベントの使用

Azure Functions は、Event Hubs のトリガーおよび出力バインディングをサポートしています。 このセクションでは、イベント ハブのイベント ストリームに送信されたイベントに、Azure Functions がトリガーを使用して応答する方法について説明します。

Event Hubs によってトリガーされる関数の各インスタンスには、1 つの EventProcessorHost インスタンスが対応します。 (Event Hubs によって提供される) トリガーにより、1 つの EventProcessorHost インスタンスだけが特定のパーティションのリースを取得できるようになります。

たとえば、次のような特性を持つイベント ハブを考えてみます。

• 10 パーティション。
• 1,000 個のイベントがすべてのパーティション間に分散され、各パーティション内にさまざまな数のメッセージがある。

関数が最初に有効化されたときに存在する関数インスタンスは 1 つのみです。 最初の関数インスタンス Function_1 を呼び出しましょう。 Function_1 は、全 10 個のパーティションのリースを保持する EventProcessorHost の単一のインスタンスを持っています。 このインスタンスは、パーティション 1 から 10 のイベントを読み取ります。 この後、次のいずれかが発生します。

• 新しい関数インスタンスは必要とされない: Function_1 は、Functions のスケーリング ロジックが有効になる前に、1,000 個のイベントをすべて処理できます。 この場合、1000 個のメッセージはすべて Function_1 によって処理されます。

  

• さらに関数インスタンスが追加される: イベント ベースのスケーリングまたはその他の自動または手動のロジックによって、Function_1 が処理可能な数よりも多くのメッセージを含んでいると判断された場合、新しい関数アプリ インスタンス (Function_2) が作成されます。 この新しい関数にも、EventProcessorHost のインスタンスが関連付けられています。 基になるイベント ハブは、新しいホスト インスタンスがメッセージを読み取ろうとしていることを検出すると、ホスト インスタンス間でパーティションを負荷分散します。 たとえば、パーティション 1 から 5 が Function_1 に割り当てられ、パーティション 6 から 10 が Function_2 に割り当てられます。

  

• さらに N 個の関数インスタンスが追加される: イベント ベースのスケーリングまたはその他の自動または手動のロジックによって、Function_1 と Function_2 のどちらにもその処理能力を超える数のメッセージがあると判断されると、新しい Function_N の関数アプリ インスタンスが作成されます。 インスタンスは、N がイベント ハブのパーティションの数と同じかそれを超える時点まで作成されます。 この例では、Event Hubs は、パーティションを再び負荷分散します。この場合、 Function_1...Function_10 のインスタンス間で負荷分散します。

  

スケーリングが発生すると、N 個のインスタンスは、イベント ハブのパーティション数よりも多くなる場合があります。 この状況は、イベント ドリブンのスケーリングによってインスタンス数が安定しているときや、他の自動または手動のロジックでパーティションの数よりも多くのインスタンスが作成されたために発生する可能性があります。 この場合、EventProcessorHost インスタンスは、他のインスタンスからのパーティションが使用できるようになったときにのみ、そのロックを取得します。これは、任意の時点で、同じコンシューマー グループの 1 つの関数インスタンスだけが、ロックを保持しているパーティションにアクセスして読み取ることができるためです。

すべての関数の実行が (エラーの有無にかかわらず) 完了すると、関連付けられているストレージ アカウントにチェックポイントがコミットされます。 チェックポイント処理が成功すると、関数はイベントの新しいバッチを処理する準備が整います。

従量課金、Flex 従量課金および Premium Azure プランでは、動的なイベント ベースのスケーリングが可能です。 Kubernetes にホストされる関数アプリでは、Event Hubs 用の KEDA スケーラーを利用することもできます。 現時点では、関数アプリが Dedicated (App Service) プランでホストされている場合、イベント ベースのスケーリングを行うことはきません。この場合は、ワークロードに基づいて適切な数のインスタンスを決定する必要があります。

詳細については、Azure Functions における Azure Event Hubs のバインドに関する記事、および「Azure Functions の Azure Event Hubs トリガー」を参照してください。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパル作成者:

• David Barkol | プリンシパル ソリューション スペシャリスト (GBB)

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

パフォーマンスと拡張性

Azure Event Hubs と Azure Functions を組み合わせて使用するソリューションでは、スケーラブルでコスト効率が高く、ほぼリアルタイムで大量のデータを処理できる、サーバーレス アーキテクチャの利点を得ることができます。 これらのサービスはシームレスに連携しますが、それらの関係をより複雑にする多くの機能、設定、複雑な詳細が存在します。 この記事では、パフォーマンス、回復性、セキュリティ、可観測性、スケールに関する主な考慮事項と手法を詳しく説明することで、この統合を効果的に活用する方法についてのガイダンスを提供します。

Event Hubs の主要な概念

Azure Event Hubs は、拡張性の高いイベント処理サービスであり、1 秒間に数百万件のイベントを受信できます。 Azure Functions 統合のパターンとベスト　プラクティスに進む前に、Event Hubs の基本的なコンポーネントについて理解しておくことをお勧めします。

次の図は、Event Hubs のストリーム処理のアーキテクチャを示しています。

イベント

イベントとは、過去に発生したファクトとして表される通知または状態の変更のことです。 イベントは不変で、イベント ハブ内で永続化されます。Kafka では "トピック" とも呼ばれます。 イベント ハブは、1 つまたは複数のパーティションで構成されます。

メジャー グループ

送信側でパーティションが指定されていない場合、受信したイベントはイベント ハブ内の複数のパーティションに分散されます。 各イベントは、1 つのパーティションにのみ書き込まれ、複数のパーティション間でマルチキャストされることはありません。 各パーティションはログとして機能し、レコードは追加専用のパターンで書き込まれます。 "コミット　ログ" の例えは、パーティション内のシーケンスの最後にイベントを追加する方法の性質を示すためによく使用されます。

複数のパーティションが使用されている場合は、同じイベント ハブ内から並列ログを使用できます。 この動作により、複数の次数の並列処理が可能になるため、コンシューマーのスループットが向上します。

コンシューマーとコンシューマー グループ

1 つのパーティションを、複数のコンシューマーで使用でき、それぞれが独自のオフセットを読み取って、管理します。

Event Hubs ではコンシューマー グループの概念を採用しており、複数のコンシューマー アプリケーションが、イベント ストリームの個別のビューをそれぞれ保有し、独自のペースで独自のオフセットによってストリームを別々に読み取ることができます。

詳細については、Event Hubs の概念と機能の詳細に関するページを参照してください。

Azure Functions でのイベントの使用

Azure Functions は、Event Hubs のトリガーおよび出力バインディングをサポートしています。 このセクションでは、イベント ハブのイベント ストリームに送信されたイベントに、Azure Functions がトリガーを使用して応答する方法について説明します。

Event Hubs によってトリガーされる関数の各インスタンスには、1 つの EventProcessorHost インスタンスが対応します。 (Event Hubs によって提供される) トリガーにより、1 つの EventProcessorHost インスタンスだけが特定のパーティションのリースを取得できるようになります。

たとえば、次のような特性を持つイベント ハブを考えてみます。

• 10 パーティション。
• 1,000 個のイベントがすべてのパーティション間に分散され、各パーティション内にさまざまな数のメッセージがある。

関数が最初に有効化されたときに存在する関数インスタンスは 1 つのみです。 最初の関数インスタンス Function_1 を呼び出しましょう。 Function_1 は、全 10 個のパーティションのリースを保持する EventProcessorHost の単一のインスタンスを持っています。 このインスタンスは、パーティション 1 から 10 のイベントを読み取ります。 この後、次のいずれかが発生します。

• 新しい関数インスタンスは必要とされない: Function_1 は、Functions のスケーリング ロジックが有効になる前に、1,000 個のイベントをすべて処理できます。 この場合、1000 個のメッセージはすべて Function_1 によって処理されます。

  

• さらに関数インスタンスが追加される: イベント ベースのスケーリングまたはその他の自動または手動のロジックによって、Function_1 が処理可能な数よりも多くのメッセージを含んでいると判断された場合、新しい関数アプリ インスタンス (Function_2) が作成されます。 この新しい関数にも、EventProcessorHost のインスタンスが関連付けられています。 基になるイベント ハブは、新しいホスト インスタンスがメッセージを読み取ろうとしていることを検出すると、ホスト インスタンス間でパーティションを負荷分散します。 たとえば、パーティション 1 から 5 が Function_1 に割り当てられ、パーティション 6 から 10 が Function_2 に割り当てられます。

  

• さらに N 個の関数インスタンスが追加される: イベント ベースのスケーリングまたはその他の自動または手動のロジックによって、Function_1 と Function_2 のどちらにもその処理能力を超える数のメッセージがあると判断されると、新しい Function_N の関数アプリ インスタンスが作成されます。 インスタンスは、N がイベント ハブのパーティションの数と同じかそれを超える時点まで作成されます。 この例では、Event Hubs は、パーティションを再び負荷分散します。この場合、 Function_1...Function_10 のインスタンス間で負荷分散します。

  

スケーリングが発生すると、N 個のインスタンスは、イベント ハブのパーティション数よりも多くなる場合があります。 この状況は、イベント ドリブンのスケーリングによってインスタンス数が安定しているときや、他の自動または手動のロジックでパーティションの数よりも多くのインスタンスが作成されたために発生する可能性があります。 この場合、EventProcessorHost インスタンスは、他のインスタンスからのパーティションが使用できるようになったときにのみ、そのロックを取得します。これは、任意の時点で、同じコンシューマー グループの 1 つの関数インスタンスだけが、ロックを保持しているパーティションにアクセスして読み取ることができるためです。

すべての関数の実行が (エラーの有無にかかわらず) 完了すると、関連付けられているストレージ アカウントにチェックポイントがコミットされます。 チェックポイント処理が成功すると、関数はイベントの新しいバッチを処理する準備が整います。

従量課金、Flex 従量課金および Premium Azure プランでは、動的なイベント ベースのスケーリングが可能です。 Kubernetes にホストされる関数アプリでは、Event Hubs 用の KEDA スケーラーを利用することもできます。 現時点では、関数アプリが Dedicated (App Service) プランでホストされている場合、イベント ベースのスケーリングを行うことはきません。この場合は、ワークロードに基づいて適切な数のインスタンスを決定する必要があります。

詳細については、Azure Functions における Azure Event Hubs のバインドに関する記事、および「Azure Functions の Azure Event Hubs トリガー」を参照してください。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパル作成者:

• David Barkol | プリンシパル ソリューション スペシャリスト (GBB)

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

パフォーマンスと拡張性