ストレージ イベントに応答してパイプラインを実行するトリガーを作成する
適用対象: 
Azure Data Factory Azure Synapse Analytics
ヒント
企業向けのオールインワン分析ソリューション、Microsoft Fabric の Data Factory をお試しください。 Microsoft Fabric は、データ移動からデータ サイエンス、リアルタイム分析、ビジネス インテリジェンス、レポートまで、あらゆるものをカバーしています。 無料で新しい試用版を開始する方法について説明します。
この記事では、Azure Data Factory または Azure Synapse Analytics パイプラインの中で作成できる、ストレージ イベント トリガーについて説明します。
イベントドリブン アーキテクチャ は、イベントの運用、検出、使用、およびリアクションを伴う、データ統合の共通的なパターンです。 データ統合シナリオでは、多くの場合、Azure Blob Storage アカウントでのファイルの到着や削除など、Azure Storage アカウントで発生するイベントからトリガーされるパイプラインをユーザーがトリガーする必要があります。 Data Factory および Azure Synapse Analytics のパイプラインは Azure Event Grid とネイティブに統合されているので、そういったイベントでパイプラインをトリガーできます。
ストレージ イベント トリガーの考慮事項
ストレージ イベント トリガーを使用する場合は、次の点を考慮してください。
- この記事で説明されている統合は、Azure Event Grid に依存しています。 サブスクリプションが Event Grid リソース プロバイダーに登録されていることを確認してください。 詳細については、「リソース プロバイダーと種類」を参照してください。
Microsoft.EventGrid/eventSubscriptions/アクションを実行できる必要があります。 このアクションは、EventGrid EventSubscription Contributorの組み込みロールの一部です。 - Azure Synapse Analytics でこの機能を使用している場合は、必ず Data Factory リソース プロバイダーにもサブスクリプションを登録してください。 これ以外では、"イベント サブスクリプション が作成できませんでした" というメッセージが表示されます。
- Blob Storage アカウントがプライベート エンドポイントの背後に存在し、パブリック ネットワーク アクセスをブロックしている場合は、Blob Storage から Event Grid への通信を許可するようにネットワーク規則を構成する必要があります。 Storage のドキュメントに従って、Event Grid などの信頼された Azure サービスにストレージへのアクセス権を付与するか、Event Grid のドキュメントに従って、仮想ネットワークのアドレス空間にマップする Event Grid のプライベート エンドポイントを構成できます。
- 現在、ストレージ イベント トリガーでサポートされているのは、Azure Data Lake Storage Gen2 と汎用バージョン 2 のストレージ アカウントのみです。 セキュア ファイル転送プロトコル (SFTP) のストレージ イベントを使用している場合は、フィルター セクションで SFTP Data API も指定する必要があります。 Azure Event Grid に制限があるため、Data Factory でサポートされるストレージ イベント トリガーは、ストレージ アカウントあたり最大 500 個のみです。
- 新しいストレージ イベント トリガーを作成したり、既存のものを変更したりするには、サービスへのサインインとストレージ イベント トリガーの発行に使用される Azure アカウントに、ストレージ アカウントでの適切なロールベースのアクセス制御 (Azure RBAC) 権限が付与されている必要があります。 その他のアクセス許可は必要ありません。 Azure Data Factory および Azure Synapse Analytics のサービス プリンシパルには、ストレージ アカウントまたは Event Grid に対する特別なアクセス許可は必要ありません。 アクセス制御の詳細については、「ロールベースのアクセス制御」セクションを参照してください。
- ストレージ アカウントに Azure Resource Manager ロックを適用した場合、BLOB トリガーが BLOB を作成または削除する機能に影響する可能性があります。
ReadOnlyロックでは作成と削除の両方が禁止され、DoNotDeleteロックでは削除が禁止されます。 トリガーに関する問題の発生を防ぐには、これらの制限事項を必ず考慮してください。 - データ フロー シンクからのトリガー メカニズムとして、ファイル到着トリガーを使用することはお勧めしません。 データ フローでは、ターゲット フォルダー内の多数のファイル名の変更タスクとパーティション ファイルのシャッフル タスクが実行されるため、データの完全な処理の前にファイル到着イベントが誤ってトリガーされる可能性があります。
UI を使用してトリガーを作成する
このセクションでは、Azure Data Factory および Azure Synapse Analytics のパイプラインのユーザー インターフェイス (UI) 内で、ストレージ イベント トリガーを作成する方法について説明します。
Data Factory の [編集] タブまたは Azure Synapse Analytics の [統合] タブに切り替えます。
メニューで [トリガー] を選択し、次に [新規作成/編集] を選択します。
[トリガーの追加] ページで、[トリガーの選択] を選択した後、[+ 新規] を選択します。
トリガーの種類には [ストレージ イベント] を選択します。
[Azure サブスクリプション] ドロップダウン リストからストレージ アカウントを選択するか、ストレージ アカウントのリソース ID を使用して手動で選択します。 イベントを発生させるコンテナーを選択します。 コンテナーの選択は必須ですが、すべてのコンテナーを選択すると、多数のイベントが発生する可能性があります。
Blob path begins withプロパティとBlob path begins withプロパティを使用すると、イベントを受信させたいコンテナー、フォルダー、BLOB 名を指定できます。 ストレージ イベント トリガーでは、これらのプロパティの少なくとも 1 つを定義する必要があります。 この記事の後半の例に示すように、Blob path begins withプロパティとBlob path begins withプロパティには共に、さまざまなパターンを使用できます。Blob path begins with: BLOB パスはフォルダーパスで始める必要があります。 有効な値として、2018/および2018/april/shoes.csvがあります。 コンテナーが選択されていない場合、このフィールドを選択することはできません。Blob path begins with: BLOB パスは、ファイル名または拡張子で終わる必要があります。 有効な値として、shoes.csvおよび.csvがあります。 コンテナー名とフォルダー名を指定する場合は、/blobs/セグメントで区切る必要があります。 たとえば、ordersという名前のコンテナーには、/orders/blobs/2018/april/shoes.csvの値を指定できます。 コンテナー内にフォルダーを指定するには、先頭の/文字を省略します。 たとえば、april/shoes.csvは、任意のコンテナー内のaprilというフォルダーにあるshoes.csvという名前のファイルで、イベントをトリガーします。
Blob path begins withとBlob path ends withは、ストレージ イベント トリガーで許可される唯一のパターン マッチングであることに注意してください。 その他の種類のワイルドカードによるマッチングは、トリガーの種類ではサポートされていません。トリガーが BLOB 作成 イベントか BLOB 削除 イベントのいずれか、またはその両方に応答するのかを選びます。 指定した保存場所で、各イベントにより、トリガーに関連付けられている Data Factory と Azure Synapse Analytics のパイプラインがトリガーされます。
ゼロ バイトの BLOB をトリガーで無視するかどうかを選択します。
トリガーを構成したら、[次へ: データのプレビュー] を選択します。 この画面には、ストレージ イベント トリガーの構成に一致する既存の BLOB が表示されます。 特定のフィルターがあることを確認します。 フィルターの構成範囲が広すぎると、作成または削除された多数のファイルと一致することになり、コストに大きく影響することがあります。 フィルター条件が検証されたら、 [完了]を選択します。
このトリガーにパイプラインをアタッチするには、パイプライン キャンバスに移動 し、[トリガー]>[新規作成/編集] の順に選択します。 作業ウィンドウが表示されたら、[トリガーの選択] ドロップダウン リストを選択し、作成したトリガーを選択します。 [次へ: データ プレビュー] を選択して、構成が正しいことを確認します。 その後、[次へ] を選択して、データ プレビューが正しいことを検証します。
パイプラインにパラメーターがある場合は、[トリガー実行パラメーター] 作業ウィンドウで指定できます。 ストレージ イベント トリガーにより、BLOB のフォルダー パスとファイル名が、プロパティ
@triggerBody().folderPathおよび@triggerBody().fileNameにキャプチャされます。 パイプラインでこれらのプロパティの値を使用するには、プロパティをパイプライン パラメーターにマップする必要があります。 プロパティをパラメーターにマップしたら、パイプライン全体で@pipeline().parameters.parameterName式を使用して、トリガーでキャプチャされた値にアクセスできます。 詳しい説明については、「パイプラインでのトリガー メタデータの参照」で確認してください。
前の例では、.csv で終わる BLOB パスがコンテナー sample-data の event-testing フォルダーに作成されたときにトリガーが起動するように構成されています。
folderPathプロパティとfileNameプロパティは、新しい BLOB の場所をキャプチャします。 たとえば、MoviesDB.csv が、パス sample-data/event-testing に追加された場合、@triggerBody().folderPathにはsample-data/event-testingの値が、@triggerBody().fileNameにはmoviesDB.csvの値が含まれます。 この例では、これらの値は、パイプライン パラメーターのsourceFolderおよびsourceFileにマップされており、それぞれ@pipeline().parameters.sourceFolderおよび@pipeline().parameters.sourceFileとしてパイプライン全体で使用できます。作業を終えたら、 [完了] を選択します。
JSON スキーマ
次の表に、ストレージ イベント トリガーに関連するスキーマ要素の概要を示します。
| JSON 要素 | 説明 | Type | 使用できる値 | 必須 |
|---|---|---|---|---|
| scope | ストレージ アカウントの Azure Resource Manager リソース ID。 | String | Azure Resource Manager ID | はい。 |
| イベント | このトリガーを起動するイベントの種類。 | Array | Microsoft.Storage.BlobCreated、Microsoft.Storage.BlobDeleted |
はい、これらの値の任意の組み合わせが必須です。 |
blobPathBeginsWith |
BLOB パスは、トリガーを起動するために指定されているパターンで始まる必要があります。 たとえば、/records/blobs/december/ のみが、records コンテナー下の december フォルダーにあるブロブのトリガーを起動します。 |
String | blobPathBeginsWith または blobPathEndsWith の少なくとも 1 つのプロパティに値を指定します。 |
|
blobPathEndsWith |
BLOB パスは、トリガーを起動するために指定されているパターンで終わる必要があります。 たとえば、december/boxes.csv のみが、december フォルダー内の boxes というブロブのトリガーを起動します。 |
String | blobPathBeginsWith または blobPathEndsWith の少なくとも 1 つのプロパティに値を指定します。 |
|
ignoreEmptyBlobs |
ゼロバイトの BLOB でパイプライン実行をトリガーするかどうか。 既定では、これは true に設定されています。 |
ブール値 | true または false | いいえ。 |
ストレージ イベント トリガーの例
このセクションでは、ストレージ イベント トリガーの設定の例を示します。
重要
以下の例に示すように、コンテナーとフォルダー、コンテナーとファイル、またはコンテナー、フォルダー、およびファイルを指定するたびに、パスの /blobs/ セグメントを含める必要があります。 blobPathBeginsWith の場合、トリガー JSON のフォルダーとコンテナー名の間に、UI が自動的に /blobs/ を追加します。
| プロパティ | 例 | 説明 |
|---|---|---|
Blob path begins with |
/containername/ |
コンテナー内の任意の BLOB のイベントを受信します。 |
Blob path begins with |
/containername/blobs/foldername/ |
containernameコンテナーおよび foldername フォルダー内の任意の BLOB のイベントを受信します。 |
Blob path begins with |
/containername/blobs/foldername/subfoldername/ |
サブフォルダーを参照することもできます。 |
Blob path begins with |
/containername/blobs/foldername/file.txt |
containername コンテナー下の foldername フォルダー内にある file.txt という名前の BLOB のイベントを受信します。 |
Blob path ends with |
file.txt |
任意のパスで file.txt という名前の BLOB のイベントを受信します。 |
Blob path ends with |
/containername/blobs/file.txt |
コンテナー containername の下の file.txt という名前の BLOB のイベントを受信します。 |
Blob path ends with |
foldername/file.txt |
任意のコンテナーの下の foldername フォルダーにある、file.txt という名前の BLOB のイベントを受信します。 |
ロールベースのアクセス制御
Data Factory および Azure Synapse Analytics のパイプラインでは、BLOB イベントにリンクされたパイプラインをリッスン、更新元としてサブスクライブ、およびトリガーする不正なアクセスは、Azure のロールベースのアクセス制御 (Azure RBAC) を使用して厳密に禁止されます。
- ストレージ イベント トリガーの新規作成や、既存のものの更新を正常に行うには、サービスにサインインしている Azure アカウントが、関連するストレージ アカウントに適切にアクセスできる必要があります。 それ以外の場合、"アクセスが拒否されました" というメッセージで操作が失敗します。
- Data Factory と Azure Synapse Analytics には Event Grid インスタンスに対する特別なアクセス許可は必要ありません。また操作のために、Data Factory または Azure Synapse Analytics のサービス プリンシパルに対し、特別な RBAC アクセス許可を割り当てる必要はありません。
次の RBAC 設定は、ストレージ イベント トリガーで機能します。
- ストレージ アカウントに対する所有者ロール
- ストレージ アカウントに対する共同作成者ロール
- ストレージ アカウント
/subscriptions/####/resourceGroups/####/providers/Microsoft.Storage/storageAccounts/storageAccountNameへのアクセス許可Microsoft.EventGrid/EventSubscriptions/Write
具体的には、次のように使用します。
- データ ファクトリ (たとえば開発環境内など) で作成する場合は、サインインしている Azure アカウントに前述のアクセス許可が必要です。
- 継続的インテグレーションと継続的デリバリーを通じて発行する場合、Azure Resource Manager テンプレートをテストまたは運用ファクトリに発行するために使用されるアカウントには、前述のアクセス許可が必要です。
サービスによって 2 つの約束がどのように実現されるかを理解するために、前に戻って、その裏側を見てみましょう。 Data Factory または Azure Synapse Analytics、Storage、および Event Grid 間における統合のワークフローの概要を次に示します。
新しいストレージ イベント トリガーを作成する
このワークフローの概要は、ストレージ イベント トリガーを作成するために、Data Factory が Event Grid とどのようにやり取りするのかを示しています。 データ フローは Azure Synapse Analytics でも同様であり、次の図での Data Factory の役割を、Azure Synapse Analytics パイプラインが果たします。
ワークフローからの大きな 2 つの要点。
- Data Factory と Azure Synapse Analytics は、ストレージ アカウントと直接接続しません。 サブスクリプションの作成要求は、代わりに Event Grid によってリレーされて処理されます。 このステップでは、サービスにストレージ アカウントへのアクセス権限は必要ありません。
- アクセス制御とアクセス許可のチェックは、サービス内で行われます。 サービスでは、ユーザーのアクセス許可がチェックされてから、ストレージ イベントをサブスクライブする要求が送信されます。 具体的には、サインインしてストレージ イベント トリガーを作成しようとしている Azure アカウントが、関連するストレージ アカウントに適切にアクセスできるかどうかをチェックします。 アクセス許可のチェックに失敗すると、トリガーの作成も失敗します。
ストレージ イベント トリガーでのパイプラインの実行
このワーク フローの概要では、ストレージ イベントで、パイプラインの実行が Event Grid を通じどのようにトリガーされるかを示しています。 Azure Synapse Analytics についても、このデータ フローは同じで、次の図での Data Factory の役割は、Azure Synapse Analytics パイプラインがを果たします。
サービス内でイベントが トリガーするパイプラインに関連する、ワークフローの 3 つの主な要点は次のとおりです。
Event Grid では、ストレージによってメッセージがシステムにドロップされたらできるだけ早くメッセージを中継するプッシュ モデルが使用されます。 これは、Pull システムが使用されている Kafka などのメッセージング システムとは異なります。
イベント トリガーは、受信メッセージのアクティブなリスナーとして機能し、これにより、関連付けられたパイプラインが適切にトリガーされます。
ストレージ イベント トリガー自体が、ストレージ アカウントと直接コンタクトすることはありません。
- ストレージ アカウント内のデータを処理するための Copy アクティビティやその他のアクティビティがパイプライン内にある場合、サービスは、リンク サービスに保存されている資格情報を使用して、ストレージ アカウントと直接コンタクトします。 リンク サービスが適切に設定されていることを確認します。
- パイプラインの中でストレージ アカウントを参照しないのであれば、ストレージ アカウントにアクセスするための権限をサービスに付与する必要はありません。
関連するコンテンツ
- トリガーの詳細については、パイプラインの実行とトリガーに関する記事を参照してください。
- パイプラインの中でトリガー メタデータを参照する方法については、「パイプライン実行でトリガー メタデータを参照する」をご覧ください。