【ITニュース解説】🔄 Syncing Microsoft Fabric OneLake Using Logic Apps + OneLake APIs

この記事では、Microsoft FabricのデータレイクであるOneLakeに、Logic AppsとOneLake APIを組み合わせてリアルタイムに近い形でデータを同期する方法について解説する。従来のデータ連携がバッチ処理（ある程度のデータをまとめて処理する）に偏りがちだったのに対し、この手法ではイベントが発生するたびに即座にデータをOneLakeに取り込むことが可能になる。特に、コンプライアンスシステムのような上流システムから発生する「データが作成された」「更新された」「削除された」といったイベントを、効率的にOneLakeに書き込む具体的な手順とその技術的な工夫が示されている。

まず、連携の出発点となるのは「イベント駆動型トリガー」だ。コンプライアンスシステム内でデータに変更があると、そのシステムは「Webhookイベント」と呼ばれる通知を生成して送信する。Webhookとは、特定のイベントが発生したときに、あらかじめ設定されたURLにHTTPリクエストを送る仕組みのことだ。この通知には、どのようなイベントが起きたか（例えば「UPDATED」）、そしてそのイベントに関わる具体的なデータ（例えば「CustomerId: 12345」「Status: Inactive」など）がJSON形式で含まれている。このJSONデータは、Logic Appsの「HTTPトリガー」によって受け取られる。Logic Appsは、Microsoft Azureが提供するクラウドベースのサービスで、様々なアプリケーションやサービスを連携させ、自動化されたワークフローを簡単に作成できる。

次に、Logic Appsは受け取ったイベントを処理するための「オーケストレーション」を行う。オーケストレーションとは、一連の複雑な処理の流れを管理・調整することだ。Logic Appのワークフローは以下の主要なステップを実行する。まず、HTTPトリガーでWebhookイベントを受け取る。次に、OneLakeにファイルを保存するために必要なファイル名、ファイルのパス、OneLakeへの接続URLなどの変数を初期化する。その後、受け取ったイベントから実際のデータ（ペイロード）を取り出し、それをOneLakeに書き込める形式（JSON）に整え、そのデータのバイト数を計算するといった準備を行う。そして、イベントのタイプ（作成、更新、削除）に応じて処理を分岐させ、適切なOneLake APIを呼び出す準備をするのだ。

Logic AppsからOneLakeへデータを書き込む際には、OneLake DFS REST APIというものを使用する。API（Application Programming Interface）とは、異なるソフトウェア同士が情報をやり取りするための窓口のようなものだ。REST APIは、Web技術を基盤としたAPIの一種で、HTTPリクエストを使ってデータを操作する。Logic Appは、このOneLake DFS REST APIを使って以下の3つの操作を順次実行する。

1. 空ファイルの作成: まず、PUTリクエストを使って、これからデータを書き込むための空のファイルをOneLake上に作成する。リクエストのURLには、対象となるOneLakeのワークスペース、レイクハウス、保存先のフォルダ、ファイル名が指定される。
2. ペイロードの追加: 次に、PATCHリクエストをaction=appendというオプション付きで送信し、Webhookで受け取ったJSONデータを先ほど作成した空ファイルに書き込む。このとき、データの書き込み開始位置（position=0）を指定する。
3. ファイルの確定 (Flush): 最後に、もう一度PATCHリクエストをaction=flushというオプション付きで送信し、書き込んだデータを最終的に確定させる。この操作によって、OneLake上のファイルが完全に利用可能になり、後続の分析パイプラインなどのシステムから読み取れるようになる。

ここで、「ファイルの確定 (Flush)」の際に重要な課題がある。action=flushのAPIを呼び出すときには、positionパラメータとして、書き込んだデータの正確なバイト数を渡す必要があるのだ。しかし、このバイト数をプログラムで計算するのは非常に難しいことが分かった。最初の試みとして、JSONデータをBase64エンコードしてからバイト数を計算する方法が試されたが、UTF-8エンコーディングの特性、JSON内の空白文字、シリアル化（オブジェクトからJSON文字列への変換）の際に生じるわずかな違いなどによって、計算結果が実際のバイト数と1〜2バイトずれることがあった。このわずかなずれがあると、OneLakeは「InvalidFlushPosition」というエラーを返してしまい、データの確定に失敗してしまうのだ。

この問題に対して、記事では非常に clever な「ワークアラウンド」（回避策）が紹介されている。それは、OneLake自身に正しいバイト数を教えてもらう方法だ。具体的には、まずaction=flushのリクエストをpositionパラメータを付けずに送信する。このとき、本来書き込むべきペイロード（JSONデータ）はリクエストのボディに含める。OneLakeはpositionがないため、このリクエストを「BadRequest」（不正なリクエスト）として拒否する。しかし、そのエラー応答の中に「Content-Length」というヘッダー情報が含まれており、この「Content-Length」が、実際に送られてきたペイロードの正確なバイト数を示しているのだ。

Logic Appはこのメカニズムを利用する。まず、「HackToGetPosition」と名付けられたHTTP PATCHアクションを使って、わざとpositionなしのflushリクエストを送り、エラー応答を受け取る。次に、そのエラー応答の中から「Content-Length」の値（正確なバイト数）を抽出し、その値を使って改めて正確なpositionを指定したflushリクエストを送信する。この「プローブ（探り）」と「確定」の二段階のやり取りにより、常に正確なオフセットでファイルを確定できるようになり、オペレーションが確実かつ堅牢になる。

Logic Appがこの一連の処理を完了すると、WebhookイベントのデータはOneLake内にJSONファイルとして保存される。ファイルは、イベントタイプ（作成、更新、削除）ごとに自動的に整理されたフォルダに格納される。例えば、データ作成イベントによるファイルはcreatedフォルダに、更新イベントによるファイルはupdatedフォルダにといった具合だ。各ファイルには一意のGUID（グローバル一意識別子）が名前として付けられ、その中には元のWebhookイベントの生のデータ（ペイロード）がそのまま格納されている。これらのファイルは、OneLakeに接続された後続の分析パイプラインやデータ処理システムで、すぐに利用できる状態となるのだ。

このように、Microsoft Fabric OneLake、Logic Apps、OneLake APIを組み合わせることで、上流システムからのイベントをリアルタイムに、かつ信頼性の高い方法でデータレイクに連携できる。特に「Flush Offset」の課題解決方法は、システム連携における実践的な工夫が凝縮されており、システムエンジニアを目指す者にとって、API連携の奥深さと問題解決の面白さを学ぶ良い事例となるだろう。この手法は、データ駆動型アプリケーションの構築や、リアルタイムに近いデータ分析基盤の構築において、非常に有効なアプローチだ。