DataWorks:リアルタイム同期タスクの遅延に対するソリューション

ボトルネックがソース側か送信先側かを特定する

オペレーションセンターで該当ノードの 詳細 タブを開きます（リアルタイムノード O&M > リアルタイム同期ノード > リアルタイム DI ページからノード名をクリック）。

リーダー統計情報 および ライター統計情報 のセクションで、waitTimeWindow (5 分) の値を比較します。このメトリックは、過去 5 分間にノードがソースからの読み取りまたは送信先への書き込みを待機した時間を示します。値が大きい方の側がボトルネックとなります。

このビューへのアクセス方法の詳細については、「リアルタイム同期タスクの管理」をご参照ください。

リアルタイム同期ノードは、ソースからの読み取りと送信先への書き込みをシーケンスで実行します。書き込みが読み取りよりも遅い場合、送信先がリーダーにバックプレッシャーをかけ、データ取り込みが遅くなります。調査は waitTimeWindow (5 分) の値が大きい側に集中してください — その側がボトルネックの発生源です。

遅延発生期間中の例外を確認する

同一パネルの ログ タブで、遅延が急増したタイムウィンドウ内に以下のキーワードが含まれていないか検索します：

• Error

• error

• Exception

• exception

• OutOfMemory

遅延発生期間中に例外ログが確認された場合は、「リアルタイム同期に関するよくある質問」を参照し、ノード構成の最適化によって問題が解消されるかを確認してください。

メモリ不足（OOM）エラーを確認する

フェールオーバー タブで、10 分間に 1 回を超えてフェールオーバーが発生しているかを確認します。頻繁なフェールオーバーは、ノードのメモリ不足を示唆しています。

原因を確認するには、フェールオーバーイベント 列内のフェールオーバーイベントにマウスカーソルを合わせるか、アクション列の 詳細の表示 をクリックして、フェールオーバー直前の完全なログを確認します。OutOfMemory の文字列をいずれかのログ内で検索してください。該当するエラーが見つかった場合、ノードに割り当てられたメモリ量を増やす必要があります。

ノードの作成方法に応じた方法で、メモリサイズを増加させます：

データスキューまたはスループット制限の確認（Kafka、DataHub、LogHub ソースの場合）

Kafka、DataHub、または LogHub から読み取るノードでは、各パーティションまたはシャードを 1 つのスレッドが消費します。ほとんどの入力データが少数のパーティションまたはシャードに集中している場合、それらのチャネルがボトルネックとなり、並列スレッド数をいくら増やしてもノードは遅延します。

データスキューの診断：

リーダー統計情報 下の 詳細 タブで、合計バイト数 メトリックを確認します。これを、同じソース上で正常に動作している他のノードの同様のメトリックと比較します。著しく高い値は、当該ノードのソースパーティションが不均等に多くのデータを受信していることを示します。

合計バイト数 の値は、ノードの開始オフセットからの累積値です。長期間実行されているノードでは、この数値が現在のスキューを反映していない可能性があります。その場合は、ソースシステムのメトリックを直接確認してください。

データスキューが確認された場合、対応は上流で実施する必要があります — Kafka トピック、DataHub トピック、または LogHub Logstore 内のパーティション／シャードへのデータ配分を再調整（リバランス）します。ノード自身の構成を変更しても、ソースレベルのスキューは解消されません。

スループット制限の枯渇を診断する：

上流システムからソースへの送信レート、または単一パーティション／シャードからノードへの送信レートが、ソースシステムの上限に達している場合、追加のパーティションまたはシャードを追加します。

複数のリアルタイム同期ノードが同一の Kafka トピック、DataHub トピック、または LogHub Logstore から読み取っている場合、すべてのノードの合計読み取りレートがソースの制限を超えているかを確認してください。

大規模トランザクションまたは大量の DDL／DML 操作の確認（MySQL ソースの場合）

MySQL から読み取るノードでは、大規模トランザクションのコミットや、多数の DDL 操作またはデータ操作言語（DML）操作がソースで実行されると、バイナリログの増加速度がノードの処理速度を上回り、ノードが遅延します。

バイナリログを急速に拡大させる操作の例：

• 大規模テーブル全体でのフィールド値の更新

• 多数の行の削除

原因の診断：

詳細 タブで、データ同期速度を確認します：

• 同期速度が非常に高い場合、バイナリログのボリュームが急速に増加していることが確認できます。

• 表示される速度が特に高くない場合は、MySQL サーバー上で監査ログおよびバイナリログのメトリックを直接確認し、実際のバイナリログ増加率を把握してください。

詳細 タブに表示される同期速度は、実際のバイナリログ消費レートを過小評価している可能性があります。ノード構成でソースデータベースまたはテーブルが指定されていない場合、ノードはデータを読み取った後にフィルター処理を行うため、これらのテーブルの読み取りスループットは表示される速度および総バイト数に含まれません。

大規模トランザクションまたは一時的な大量変更が原因である場合、ノードが追いつくまで待機してください。バイナリログの未処理データがすべて処理されると、遅延は自然に減少します。

過剰なフラッシュ操作の確認（MaxCompute 送信先で動的パーティショニングを使用する場合）

MaxCompute へ書き込むノードで フィールド値による動的パーティショニング を使用している場合：ノードは、フラッシュ間隔（デフォルト：1 分）内で検出された各一意のパーティション値ごとに、1 つの書き込みキューを保持します。最大キュー数はデフォルトで 5 です。

フラッシュ間隔内の異なるパーティション値の数がキュー制限を超えると、ノードはすべてのバッファリング済みデータに対してフラッシュをトリガーします。頻繁なフラッシュは、書き込みスループットを大幅に低下させます。

問題の診断：

[ログ] タブで、以下を検索します：

アップローダーマップのサイズが uploaderMapMaximumSize に達しました

このメッセージが表示された場合、送信先の構成パネルを開き、パーティションキャッシュキュー のサイズを増加させてください。

並列スレッド数の増加または分散実行モードの有効化

上記のいずれの原因にも該当せず、遅延が継続的なビジネストラフィックの増加によって引き起こされている場合、並列スレッド数を増やすことで遅延を低減できます。

スレッドおよびメモリの構成ガイドライン：

スレッド数を追加する際は、常にメモリも比例して増加させてください。比率は 4:1 を使用します — たとえば、スレッド数を 2 倍にする場合は、メモリ割り当て量も 2 倍にしてください。

ノードの作成方法に応じた方法で、並列スレッドおよびメモリを構成します：

分散実行モード は、単一マシンのリソース上限を解除します。現在、以下の組み合わせでサポートされています：