すべてのプロダクト
Search
ドキュメントセンター

DataWorks:リアルタイム同期ノードのレイテンシに対するソリューション

最終更新日:Jan 11, 2025

このトピックでは、リアルタイム同期ノードのレイテンシの問題を解決するために使用できるソリューションについて説明します。

レイテンシの原因がソース側かデスティネーション側かを確認する

DataStudio でリアルタイム同期ノードが作成されている場合は、オペレーションセンターでノードの実行詳細を表示する必要があります。[オペレーションセンター] ページに移動し、左側のナビゲーションペインで [リアルタイムノード O&M] > [リアルタイム同期ノード] を選択します。[リアルタイム DI] ページで、リアルタイム同期ノードの名前を見つけ、ノード名をクリックします。表示されるパネルの [詳細] タブで、リアルタイム同期ノードの実行詳細を表示できます。詳細については、リアルタイム同期タスクの管理 をご参照ください。

[詳細] タブで、リーダー統計セクションとライター統計セクションの [waitTimeWindow (5 min)] メトリックの値を確認します。[waitTimeWindow (5 min)] メトリックの値は、リアルタイム同期ノードがソースからデータを読み取るか、デスティネーションにデータを書き込むことができるようになる前に、過去 5 分間に待機した期間を示します。[waitTimeWindow (5 min)] メトリックは、データ同期のレイテンシを引き起こすボトルネックがソース側にあるか、デスティネーション側にあるかを確認するのに役立ちます。ボトルネックは、[waittimewindow (5 Min)] メトリックの値が大きい方です。

レイテンシの原因となるシステムで例外が発生しているかどうかを確認する

ボトルネックが存在する側を特定したら、同じパネルの [ログ] タブをクリックし、Error、error、Exception、exception、OutOfMemory などのキーワードで例外情報を検索して、レイテンシ期間中に次の図に示されている情報に類似した例外情報が存在するかどうかを確認できます。このような例外が存在する場合は、「リアルタイム同期のFAQ」を参照して、リアルタイム同期ノードの構成を最適化することで問題を解決できるかどうかを判断できます。

説明

リアルタイム同期ノードは、ソースシステムからデータを読み取り、デスティネーションシステムにデータを書き込みます。データの書き込みに必要な時間がデータの読み取りに必要な時間よりも長い場合、デスティネーションシステムはソースシステムにバックプレッシャーをかけます。その結果、データの読み取り速度が低下します。これは、ボトルネックが存在するシステムが別のシステムにバックプレッシャーをかけ、システムで例外が発生する可能性があることを示しています。この場合、ボトルネックが存在するシステムに特に注意を払う必要があります。

Exception information

リアルタイム同期ノードで Out of Memory ( OOM ) エラーが頻繁に報告されているかどうかを確認する

同じパネルの [フェイルオーバー] タブをクリックして、リアルタイム同期ノードで頻繁なフェイルオーバーが発生しているかどうかを確認できます。10 分以内に複数のフェイルオーバーが発生した場合、頻繁なフェイルオーバーが発生していることを示します。リアルタイム同期ノードで頻繁なフェイルオーバーが発生する場合は、[フェイルオーバーイベント] 列のフェイルオーバーイベントにポインターを移動して、フェイルオーバーの原因となった例外の詳細情報を表示できます。また、フェイルオーバーレコードの [アクション] 列の [詳細の表示] をクリックして、フェイルオーバー前にリアルタイム同期ノードに対して生成された完全なログを表示することもできます。詳細な例外情報または完全なログで、OutOfMemory キーワードを含むエラーメッセージを検索できます。リアルタイム同期ノードに設定されているメモリが不足していることが原因でフェイルオーバーが発生した場合、エラーメッセージは詳細な例外情報または完全なログに存在します。この場合、リアルタイム同期ノードのメモリサイズを増やす必要があります。Event

リアルタイム同期ノードのメモリサイズを設定するには、次のいずれかの方法を使用できます。

  • リアルタイム同期ノードが DataStudio ページで作成され、単一のテーブルから別の単一のテーブルにデータを同期するために使用される場合は、ノードの構成タブに移動し、右側のナビゲーションペインで [基本構成] をクリックし、[基本構成] タブでノードのメモリサイズを設定できます。

  • リアルタイム同期ノードが DataStudio ページで作成され、データベースから DataHub データソースなどのデータソースにデータを同期するために使用される場合は、ノードの構成タブに移動し、右側のナビゲーションペインで [基本構成] をクリックし、[基本構成] タブでノードのメモリサイズを設定できます。

  • リアルタイム同期ノードがデータ同期ソリューションによって生成される場合は、ソリューションの構成ページの [リソースの設定] ステップでノードのメモリサイズを設定できます。

ソースでデータの偏りが発生しているか、ソースのパーティションまたはシャードの数を増やす必要があるかを確認する

リアルタイム同期ノードのソースが Kafka、DataHub、または LogHub データソースであり、レイテンシが前述の理由で発生していない場合は、ソースでデータの偏りが発生しているか、ソースのパーティションまたはシャードからデータが読み取られる転送速度がソースで許可されている最大転送速度に達しているかを確認する必要があります。

Kafka、DataHub、または LogHub データソースからデータを同期するために使用されるリアルタイム同期ノードの場合、各パーティションまたはシャードのデータの消費には単一のスレッドのみを使用できます。ソースに書き込まれたデータの大部分が少数のパーティションまたはシャードに格納され、残りのパーティションまたはシャードに少量のデータのみが格納されている場合、ソースでデータの偏りが発生したり、データの大部分を格納しているパーティションまたはシャードのデータが消費されるときにボトルネックが発生する可能性があります。その結果、リアルタイム同期ノードでレイテンシが発生します。この場合、リアルタイム同期ノードの構成を調整しても問題は解決しません。Kafka、DataHub、または LogHub データソースのアップストリームシステムでデータの偏りの問題を解決する必要があります。データの偏りの問題が解決されると、レイテンシの問題も解決されます。

[オペレーションセンター] の [リアルタイム DI] ページでリアルタイム同期ノードを見つけ、ノードの [詳細] タブに移動して、リーダー統計セクションの合計バイト数のメトリックの値を表示できます。同じ手順を実行して、正常に実行されている他のリアルタイム同期ノードの [詳細] タブに移動し、リーダー統計セクションの合計バイト数のメトリックの値を表示できます。次に、取得したメトリック値を比較できます。リアルタイム同期ノードのメトリックの値が他のリアルタイム同期ノードのメトリックの値よりも大きい場合、リアルタイム同期ノードのソースでデータの偏りが発生しています。[詳細] タブに表示される合計バイト数には、前のオフセットから同期されたデータのバイト数が含まれます。リアルタイム同期ノードが長時間実行されている場合、表示される合計バイト数は現在のデータの偏りの状況を反映していない可能性があります。この場合、ソースシステムのメトリックを確認して、ソースでデータの偏りが発生しているかどうかを判断する必要があります。

アップストリームシステムからソースにデータが転送される転送速度、またはソースの単一のパーティションまたはシャードからデータが読み取られる転送速度がソースで許可されている最大転送速度に達した場合は、ソースのパーティションまたはシャードの数を増やすことでレイテンシの問題を解決できます。Kafka では、Kafka クラスタの単一のパーティションからデータを読み取ることができる最大転送速度を設定できます。DataHub では、DataHub トピックの単一のパーティションからデータを読み取ることができる最大転送速度を 4 MB/s に制限しています。LogHub では、LogHub Logstore の単一のシャードからデータを読み取ることができる最大転送速度を 10 MB/s に制限しています。

説明

複数のリアルタイム同期ノードが同じ Kafka トピック、DataHub トピック、または LogHub Logstore のデータを消費する場合、ノードがデータを読み取る転送速度の合計が、関連するデータソースで許可されている最大転送速度を超えていないかどうかを確認する必要があります。

ソースタイプが MySQL の場合、ソースで大規模なトランザクションが送信されているか、多数の DDL または DML 操作によってソースのデータが頻繁に変更されているかを確認する

リアルタイム同期ノードのソースが MySQL データソースであり、レイテンシが前述の理由で発生していない場合は、ソースで大規模なトランザクションが送信されているか、多数の DDL または DML 操作によってソースのデータが頻繁に変更されているかを確認する必要があります。ソースで大規模なトランザクションが送信されているか、多数の DDL または DML 操作によってソースのデータが頻繁に変更されている場合、MySQL データソースのバイナリログが急速に増加し、増加速度がリアルタイム同期ノードが MySQL データソースのデータを消費する速度を超える可能性があります。その結果、リアルタイム同期ノードでレイテンシが発生する可能性があります。

たとえば、ソース MySQL テーブルのフィールドの値を変更したり、MySQL テーブルから大量のデータを削除したりすると、MySQL データソースのバイナリログが急速に増加します。[オペレーションセンター] の [リアルタイム DI] ページでリアルタイム同期ノードを見つけ、ノードの [詳細] タブに移動して、ノードのデータ同期速度を表示できます。

  • データ同期速度が高いほど、バイナリログの増加速度が高いことを示します。

  • [詳細] タブに表示されるデータ同期速度が過度に高くない場合は、MySQL サーバーの監査ログとバイナリログに関連するメトリックの値を表示して、バイナリログの実際の増加速度を取得できます。

[詳細] タブに表示されるデータ同期速度は、リアルタイム同期ノードがバイナリログを消費する実際の速度を正確に反映していない可能性があります。トランザクションまたは変更に関係するデータベースまたはテーブルがリアルタイム同期ノードで指定されていない場合、ノードはデータベースおよびテーブルから読み取られたデータを、データが読み取られた後に除外します。その結果、これらのデータベースまたはテーブルからデータが読み取られる速度は、ノードの全体的なデータ同期速度にカウントされず、関連するデータはノードによって読み取られるデータの合計量にカウントされません。

大規模なトランザクションまたは多数の一時的なデータ変更が原因でレイテンシが発生していることが確認された場合は、大規模なトランザクションまたは一時的なデータ変更に関係するデータがリアルタイム同期ノードによって処理されるまで待つことができます。データが処理されると、レイテンシは徐々に減少します。

デスティネーションのフィールド値による動的パーティション分割の構成が原因で、リアルタイム同期ノードでフラッシュ操作が頻繁に実行されているかどうかを確認する

リアルタイム同期ノードのデスティネーションが MaxCompute データソースであり、デスティネーションを構成するときにパーティション分割方法をフィールド値による動的パーティション分割に設定した場合は、デスティネーション MaxCompute テーブルのパーティションキー列にマッピングできるソース列を選択する必要があります。また、リアルタイム同期ノードの [基本構成] タブで指定された [フラッシュ間隔] 内の列挙値の数が過度に大きくないことを確認する必要があります。デフォルトのフラッシュ間隔は 1 分です。

指定されたフラッシュ間隔に該当し、MaxCompute テーブルに書き込まれるのを待機しているデータは、リアルタイム同期ノードのキューのグループに格納されます。各キューは、MaxCompute テーブルに書き込む必要があるデータレコードをキャッシュします。デフォルトのキューの最大数は 5 です。MaxCompute テーブルのパーティションキー列に対応する選択されたソース列の指定されたフラッシュ間隔内の列挙値の数がキューの最大数を超えると、書き込まれるすべてのデータに対してフラッシュ操作がトリガーされます。頻繁なフラッシュ操作は、データの書き込みパフォーマンスに大きな影響を与えます。

MaxCompute テーブルに書き込まれるデータを格納するために使用されるキューの枯渇が、頻繁なフラッシュ操作をトリガーしているかどうかを確認する必要があります。[オペレーションセンター] の [リアルタイム DI] ページでリアルタイム同期ノードを見つけ、ノードの [ログ] タブに移動し、ノードのログで uploader map size has reached uploaderMapMaximumSize を検索します。ログに情報が含まれている場合は、デスティネーションの構成パネルに移動し、パーティションキャッシュキューのサイズを増やします。

リアルタイム同期ノードの並列スレッドの数を増やすか、分散実行モードを有効にする

前述の確認を実行した後、レイテンシがビジネストラフィックの増加によって発生していると判断した場合は、リアルタイム同期ノードの並列スレッドの数を増やすことでレイテンシを削減できます。

説明

リアルタイム同期ノードの並列スレッドの数を増やした後、ノードのメモリサイズも増やす必要があります。リアルタイム同期ノードの並列スレッドの数とメモリサイズは、4:1 の比率に基づいて増やすことができます。

リアルタイム同期ノードの並列スレッドの数とメモリサイズを設定するには、次のいずれかの方法を使用できます。

  • リアルタイム同期ノードが DataStudio ページで作成され、単一のテーブルから別の単一のテーブルにデータを同期するために使用される場合は、ノードの構成タブに移動し、右側のナビゲーションペインで [基本構成] をクリックし、[基本構成] タブでノードの並列スレッドの数とメモリサイズを設定できます。

  • リアルタイム同期ノードが DataStudio ページで作成され、データベースから DataHub データソースなどのデータソースにデータを同期するために使用される場合は、ノード構成タブの [リソースの設定] ステップでノードの並列スレッドの数を設定し、ノードの [基本構成] タブでノードのメモリサイズを設定できます。

  • リアルタイム同期ノードがデータ同期ソリューションによって生成される場合は、ソリューションの構成ページの [リソースの設定] ステップでリアルタイム同期ノードの並列スレッドの数とメモリサイズを設定できます。

リアルタイム同期ノードに対して分散実行モードが有効になっていない場合は、ノードに 32 以下の並列スレッドを設定することをお勧めします。リアルタイム同期ノードに 20 を超える並列スレッドを設定すると、単一マシンのリソースが不足しているためにノードでレイテンシが発生する可能性があります。次の表に、分散実行モードを有効にできるノードのタイプと、モードをサポートするソースとデスティネーションのタイプを示します。

ノードタイプ

ソースタイプ

デスティネーションタイプ

DataStudio ETL ノード

Kafka

MaxCompute

DataStudio ETL ノード

Kafka

Hologres