Dataverse の Azure Synapse Link で同期遅延が発生する場合の原因と対処方法

Published: / Last update: / Contributors:
feedback 共有

こんにちは、Power Platform サポートチームの河津です。

本記事では、Dataverse の Azure Synapse Link(以下、Synapse Link)を利用してデータを Azure Data Lake Storage (ADLS) Gen2 や Fabric にエクスポートされている環境において、データの同期に遅延(数十分~数時間程度)が発生するケースについて、その仕組みと原因、対処方法を Q&A 形式でご案内いたします。

この記事でわかること

  • Synapse Link のニアリアルタイム同期の仕組みと、遅延が発生し得る条件がわかる
  • 長時間トランザクションが変更追跡(Change Tracking)に与える影響がわかる
  • 1 つのテーブルのトランザクションが全テーブルの同期に影響する理由がわかる
  • フォールバック同期ジョブによる自動復旧の仕組みがわかる
  • 同期遅延の検知方法や緩和策の考え方がわかる

Synapse Link のニアリアルタイム同期とはどのような仕組みですか? (Q1)

【結論】Synapse Link は Dataverse のデータ変更を「ニアリアルタイム」で ADLS Gen2 や Fabric に同期する機能ですが、リアルタイム性が常に保証されるものではございません。同期のパフォーマンスは複数の要因に依存しており、特にトランザクション量の多い環境ではデータの反映に時間がかかる場合がございます。

Synapse Link の差分同期(DeltaSync)は、Dataverse のバックエンドにある SQL Server の 変更追跡(Change Tracking) 機能を利用しております。前回の同期以降に追加・更新・削除されたレコードを検出し、ADLS Gen2 上のファイルとして出力する仕組みです。

Append モード(CSV 形式)をご利用の場合、インクリメンタル更新フォルダが最短 5 分間隔 で作成され、その時間内に発生した変更データが格納されます。

ただし、公式ドキュメントでは以下のように記載されております。

ニアリアルタイム同期のパフォーマンスは、初期データロードサイズ、データチャーンレート、変更量など複数の要因に依存します。(中略)このような高ボリュームのシナリオでは、ニアリアルタイムのデータ可用性は保証されません。

<参考資料>


同期遅延が発生する主な原因は何ですか? (Q2)

【結論】同期遅延の主な原因として、Dataverse 上で 長時間にわたるトランザクション が実行されていることにより、変更追跡で管理されるバージョン番号が一時的に固定され、変更レコードが更新されなくなるケースが挙げられます。

Dataverse のバックエンド SQL Server では、変更追跡のためにデータベース全体で共通の行バージョン番号が管理されています。この変更追跡の性質として、長時間実行中のトランザクションが存在すると、そのトランザクションが完了するまでバージョン番号の進行が止まり、変更レコードが更新されない動作となっております。

具体的には、以下のような流れで同期遅延が発生する場合がございます。

  1. Dataverse 上で何らかの処理(プラグイン、バッチ処理、大量データ操作など)により長時間のトランザクションが開始される
  2. そのトランザクションが完了するまで、変更追跡のバージョン番号が固定される
  3. バージョン番号が固定されている間、他のテーブルで正常にコミットされた変更であっても変更追跡クエリから返されなくなる
  4. Synapse Link の差分同期処理自体は正常に動作し続けますが、取得可能な変更レコードが 0 件となるため、ファイルへの出力が行われない状態となる
  5. 長時間トランザクションが完了するとバージョン番号が進行し、それまでに溜まっていた変更が一斉にエクスポートされる

長時間トランザクションが発生しやすいケース

以下のような操作は、長時間にわたるトランザクションを発生させる可能性がございます。

シナリオ
大量レコードの一括操作 CreateMultiple / UpdateMultiple で数万件を一括処理するプラグイン
複雑なプラグインチェーン 1 つのレコード操作をきっかけに、連鎖的に大量のレコードが生成されるプラグイン
Excel エクスポート Dataverse から大量のデータを Excel にエクスポートする操作
バッチ処理 夜間バッチなどで大量のデータ移行やデータ変換を行う処理
ロールアップフィールドの定期再計算 Dataverse のシステムジョブ「Calculate Rollup Field」がロールアップフィールドの再計算を実行する際、対象レコード数が多い場合に長時間トランザクションとなる場合がある

なお、ロールアップフィールドの再計算ジョブは Dataverse のシステムジョブとして自動的に実行されるため、お客様が明示的に操作を行っていない場合でも長時間トランザクションの原因となる可能性がございます。特に、マネージドソリューション(Dynamics 365 のアプリケーション等)によって導入されたロールアップフィールドが業務上使用されていない場合でも、バックログ(未処理の再計算キュー)が蓄積し、再計算ジョブの実行時間が長期化するケースが確認されております。

<参考資料>


長時間トランザクションがあると、なぜ全テーブルの同期が止まるのですか? (Q3)

【結論】変更追跡で使用されるバージョン番号はデータベース(組織)レベルで共通のシーケンスとして管理されているため、いずれか 1 つのテーブルで長時間トランザクションが存在すると、すべてのテーブルの同期に影響が及ぶ仕組みとなっております。

具体的には、以下のような仕組みです。

  1. 変更追跡のバージョン番号はデータベース全体で共通 — テーブルごとに独立しているわけではございません
  2. バージョン番号はデータベースレベルで固定される — いずれかのテーブルで未コミットのトランザクションが存在する場合、その時点のバージョン番号で変更追跡の進行が止まります
  3. 固定されたバージョンを超えるレコードは返されない — 他のテーブルで正常にコミットされたレコードであっても、変更追跡クエリの結果に含まれなくなります

たとえば、テーブル A で大量レコードの一括作成処理(長時間トランザクション)が実行されている場合、テーブル B や C で発生した変更も変更追跡から返されなくなります。

この動作は変更追跡の設計上の仕様でございます。長時間トランザクションが完了しますと、すべてのテーブルで溜まっていた変更が一斉にエクスポートされるため、「すべてのテーブルのファイル出力が同じ時刻に集中する」という現象として観測される場合がございます。

<参考資料>


遅延した同期はどのように復旧しますか? (Q4)

【結論】Synapse Link には、設計上 フォールバック同期ジョブ(automated hourly fallback synchronization job) が定期的に自動実行される仕組みが組み込まれております。通常の差分同期で取得できなかった変更データがあった場合でも、このフォールバックジョブが検知し回収します。

フォールバック同期ジョブの想定動作は以下のとおりです。

  1. 通常の差分同期は約 5 分間隔で実行されますが、変更追跡のバージョン番号が固定されている間は変更レコードが 0 件となります
  2. 長時間トランザクションが完了するとバージョン番号が進行し、それまでに溜まっていた変更が変更追跡から一斉に返されるようになります
  3. 仮にタイミングの問題で通常の差分同期がこれらの変更を拾えなかった場合でも、定期的にに実行されるフォールバックジョブがセーフティネットとして機能し、取りこぼしたデータを回収・出力します

このため、長時間トランザクションが単発で発生した場合、同期遅延はおおむね 約 1 時間〜2 時間程度 で自然に復旧いたします。遅延中のデータが失われることはございませんので、ご安心ください。

ただし、長時間トランザクションが連続的・断続的に発生する場合(例: ロールアップフィールドの再計算ジョブが大量のバックログを処理し続ける場合など)は、変更追跡のバージョン番号の固定が繰り返され、遅延が数時間に及ぶ可能性がございます。このようなケースでは、長時間トランザクションの発生源を特定し、根本的な対処を行うことが重要です。対処方法については Q5 をご参照ください。


同期遅延を防止・軽減するにはどうすればよいですか? (Q5)

【結論】同期遅延の根本的な原因は Dataverse 上の長時間トランザクションにございますため、対策としてはソースシステム側での長時間トランザクションの発生を抑制する方向が基本となります。

対策 1: 長時間トランザクションの特定と抑制

確認ポイント 対策の方向性
大量レコードを一括処理するプラグイン バッチサイズを小さくし、トランザクションを分割する
長時間のバッチ処理 同期遅延が許容されない時間帯を避けて実行する
大量データの Excel エクスポート エクスポート対象を絞り込む、またはビューを最適化する

同期対象テーブル数が多い場合、複数の Synapse Link プロファイルに分割することで、処理の競合を低減できる可能性がございます。ただし、変更追跡のバージョン番号はデータベースレベルで管理されておりますため、長時間トランザクションによる遅延そのものはプロファイルの分割では防止できない点にご留意ください。

対策 3: ロールアップフィールドの管理

Dataverse のロールアップフィールドは、システムジョブ「Calculate Rollup Field」により定期的に再計算されます。対象レコード数が多い場合、この再計算処理が長時間トランザクションとなり、同期遅延の原因となることがあります。

以下の対応をご検討ください。

対応 内容
再計算ジョブの一時停止・間隔変更 [設定] → [システムジョブ] → [定期的なシステムジョブ] から「Calculate Rollup Field」ジョブの一時停止(Pause)や再計算間隔の変更が可能です
未使用ロールアップフィールドの確認 マネージドソリューション(Dynamics 365 アプリケーション等)により導入されたロールアップフィールドが業務上使用されていない場合、不要なフィールドの削除をご検討ください。ただし、マネージドソリューションの標準フィールドは削除できない場合があります

<参考資料>

同期遅延が許容されない要件について

Synapse Link のニアリアルタイム同期は、前述のとおり遅延時間に関する具体的な SLA や保証が提供されておらず、Dataverse 上のトランザクション状況によっては数十分~1 時間程度の遅延が発生する可能性がございます。そのため、リアルタイム性が厳密に求められるデータ連携の要件においては、別途、Dataverse Web API を直接利用した連携など、ご要件に応じた別のデータ連携手段をご検討ください。

<参考資料>


よくあるお問い合わせ

サポートへ実際にお寄せいただくお問い合わせの中から、関連性の高いものを Q&A 形式でご紹介いたします。

Q. Append モード(CSV)でインクリメンタルフォルダは作成されているのに、中にデータが入っていないことがあります。なぜですか?

A. インクリメンタルフォルダは約 5 分ごとに作成されますが、フォルダの作成と実際のデータ出力は非同期で行われます。長時間トランザクションにより変更追跡のバージョン番号が固定されている場合、フォルダは作成されるもののデータが 0 件のため CSV ファイルが出力されないケースがございます。長時間トランザクションが完了しバージョン番号が進行しますと、以降のフォルダにまとめてデータが出力されます。

Q. 同期遅延はどの程度の頻度で発生しますか? SLA はありますか?

A. Synapse Link のニアリアルタイム同期について、遅延時間に関する具体的な SLA は公式に提供されておりません。遅延の発生頻度は、環境ごとのデータ変更量やトランザクションのパターンによって異なります。同期遅延が業務に影響を与える場合は、Q5 でご紹介した対策をご検討いただければと存じます。


まとめ

  • Synapse Link のニアリアルタイム同期は Dataverse の変更追跡(Change Tracking)を基盤としており、高トランザクション環境ではデータの反映に遅延が生じる場合がございます
  • 同期遅延の主な原因は、Dataverse 上の長時間トランザクションが変更追跡のバージョン番号の進行を止めることによるものです
  • 変更追跡のバージョン番号はデータベースレベルで管理されるため、1 つのテーブルの長時間トランザクションが全テーブルの同期に影響を及ぼします
  • 遅延した同期はフォールバック同期ジョブにより自動的に復旧し、データの欠落は発生いたしません
  • 根本的な対策としては、長時間トランザクションの特定と抑制をご検討ください

注意事項(情報の更新可能性)

本記事の内容は執筆日時点の公開情報に基づいております。
仕様や UI、制限事項は将来変更される可能性がございます。
最新情報は公式ドキュメントをご確認くださいますようお願い申し上げます。

※本情報の内容(添付文書、リンク先などを含む)は、作成日時点でのものであり、予告なく変更される場合があります。