このトピックでは、リアルタイム同期タスクのレイテンシーに関する問題をトラブルシューティングし、解決する方法について説明します。
ボトルネックの特定：ソースまたはデスティネーション
DataStudio のリアルタイム同期タスクについては、に移動し、タスク名をクリックして詳細を表示します。 詳細については、「リアルタイム同期タスクの実行と管理」をご参照ください。
実行詳細で、[Window Wait Time (5 min)] メトリックを確認します。このメトリックは、過去 5 分間にタスクがソースからの読み取りまたは宛先への書き込みを待機していた時間を示します。これは、データ同期のボトルネックを特定するのに役立ちます。レイテンシーが発生した場合、メトリック値が高い側が通常ボトルネックです。
システム例外の確認
ボトルネックを特定したら、Logs タブに移動します。"Error", "error", "Exception", "exception", or "OutOfMemory" などのキーワードを検索し、高レイテンシーの期間から例外スタックを見つけます。例外が見つかった場合は、その詳細を使用し、「一般的なエラーの処理」を参照して、タスク設定を最適化することで問題が解決されるかどうかを確認します。
リアルタイム同期タスクは、あるシステムからデータを読み取り、別のシステムに書き込みます。データの書き込みがデータの読み取りよりも遅い場合、デスティネーションシステムがソースシステムにバックプレッシャーをかけ、速度を低下させる可能性があります。つまり、一方のシステムのボトルネックが、もう一方のシステムで例外を引き起こす可能性があります。ボトルネックとして特定されたシステムの例外を優先的に調査してください。
次のコードは、例外スタックトレースの典型的な例です。
java.lang.NullPointerException
at com.alibaba.streamx.core.util.EngineHelper.filterJobConfiguration(EngineHelper.java:31)
at com.alibaba.streamx.core.flink.trans.SinkFunctionAdaptor.open(SinkFunctionAdaptor.java:602)
at org.apache.flink.api.common.functions.util.FunctionUtils.openFunction(FunctionUtils.java:36)
at org.apache.flink.streaming.api.operators.AbstractUdfStreamOperator.open(AbstractUdfStreamOperator.java:102)
at org.apache.flink.streaming.api.operators.StreamSink.open(StreamSink.java:48)
at org.apache.flink.streaming.runtime.tasks.StreamTask.openAllOperators(StreamTask.java:439)
at org.apache.flink.streaming.runtime.tasks.StreamTask.invoke(StreamTask.java:288)
at org.apache.flink.runtime.taskmanager.Task.run(Task.java:747)
at java.lang.Thread.run(Thread.java:853)頻繁な OOM エラーの確認
タスク詳細で Failover タブに移動し、10 分間に 1 回を超える頻度で発生する頻繁なフェイルオーバーがないか確認します。フェイルオーバーが頻繁に発生する場合は、各イベントの例外情報を確認します。OutOfMemory キーワードを含むメッセージが見つかった場合、タスクのメモリが不足しており、メモリ不足 (OOM) の問題が繰り返し発生しています。
メモリを増やすには、タスクエディターを開き、Running Resources エリアで CU 値を増やします。
ソースのデータスキューまたはパーティション制限の確認
ソースが Kafka、DataHub、または LogHub であり、前の手順で例外やフェールオーバーが見つからなかった場合は、ソースシステムでデータスキューがないか確認します。また、パーティションまたはシャードの読み取りトラフィックが同期速度制限に達していないかも確認します。
Kafka、DataHub、LogHub をソースとする場合、各パーティションまたはシャードは、単一の並列スレッドによってのみ消費されます。データが少数のパーティションまたはシャードに集中し、他のパーティションまたはシャードがほぼ空の場合、このデータスキューが消費のボトルネックとなり、レイテンシーを引き起こす可能性があります。この問題は、タスク設定の調整では解決できません。Kafka、DataHub、または LogHub システムの上流のデータ生成アプリケーションでデータスキューを解決する必要があります。データ分散が均等になると、レイテンシーは解消されます。
「タスク詳細」ダイアログボックスで、Running Information タブに切り替え、各リーダースレッドの合計バイト数を確認します。あるリーダースレッドのバイト数が他のスレッドよりも著しく多い場合、データスキューが発生している可能性があります。ただし、合計バイト数には、最後に処理されたオフセット以降に処理されたすべてのデータが含まれます。長時間実行タスクの場合、このメトリックは最近のデータスキューを反映していない可能性があります。データスキューが発生しているかどうかを確認するには、ソースシステムの監視メトリックも確認する必要があります。
単一のパーティションまたはシャードのデータトラフィックが制限に達している場合は、ソースシステムのパーティションまたはシャードの数を増やすことで、レイテンシーを解決できます。たとえば、Kafka クラスターではパーティション読み取りの速度制限が構成されていることがあり、単一の DataHub パーティションの最大読み取り速度は 4 MB/s、単一の LogHub シャードの最大読み取り速度は 10 MB/s です。リアルタイム同期タスクが単一パーティションの読み取り速度制限を超える場合は、ソースシステムのパーティションまたはシャードの数を増やすことで、レイテンシーを解決します。
複数のリアルタイム同期タスクが同じ Kafka トピック、DataHub トピック、または LogHub ログストアからデータを消費する場合は、すべてのタスクの合計読み取り速度がソースの制限を超えないようにしてください。
MySQL における大規模トランザクションまたは頻繁な変更の確認
MySQL をソースとするリアルタイム同期タスクで、前の手順で例外やフェールオーバーが見つからなかった場合は、ソースシステムで大規模なトランザクションが処理されているか、多数の DML および DDL 操作などの頻繁な変更が発生しているかを確認してください。これらのアクティビティにより、タスクの消費速度を上回る速さでバイナリログが増大し、レイテンシーが発生する可能性があります。
たとえば、テーブル全体のフィールドを更新したり、大量のデータを削除したりすると、バイナリログが急激に増加する可能性があります。タスク詳細ダイアログボックスで、Running Information タブに切り替えて同期速度を表示します：
同期速度が高い場合は、バイナリログが急速に増大していることを示しています。
同期速度が高くない場合は、MySQL サーバーのバイナリログ統計と監査ログを確認し、実際の増大速度を特定します。
同期速度は、タスクが MySQL バイナリログを消費する実際の速度を反映していない場合があります。トランザクションまたは変更がタスク構成に含まれていないデータベースまたはテーブルに関連する場合、タスクは読み取り後にこのデータをフィルタリングします。このフィルタリングされたデータは、同期速度またはデータ量の統計には含まれません。
大規模なトランザクションまたは一時的な変更の急増がレイテンシーの原因であることを確認できた場合、タスクは変更のバックログを処理し終えると、最終的に追いつきます。
動的パーティショニングにおける頻繁なフラッシュの確認
MaxCompute に書き込むリアルタイム同期タスクでフィールドコンテンツに基づく動的パーティショニングを選択する場合は、MaxCompute テーブルのパーティション列にマッピングされるソース列を注意深く監視してください。Basic Configurations パネルで設定された 1 回の Flush Interval (デフォルトは 1 分) 内では、この列の一意の値の数を少なくする必要があります。
フラッシュ間隔内では、MaxCompute テーブル向けのデータは、リアルタイム同期タスク内の一連のキューにキャッシュされます。各キューは、1 つの MaxCompute 書き込み操作のデータをキャッシュします。デフォルトの最大キュー数は 5 です。構成されたフラッシュ間隔内で、ソースパーティション列の個別値 (ユニーク値) の数がこの制限を超えると、キャッシュされたすべてのデータが即時にフラッシュされます。頻繁なフラッシュ操作は、書き込みパフォーマンスを著しく低下させる原因となります。
MaxCompute テーブルパーティションのキャッシュキューが枯渇したことが原因で頻繁なフラッシュがトリガーされているかどうかを確認するには、タスク詳細ダイアログボックスで Logs タブに切り替えて、メッセージ uploader map size has reached uploaderMapMaximumSize を検索します。
同時実行数の増加または分散実行の有効化
前の手順で、レイテンシーが例外ではなくソーストラフィックの増加によるものであることが判明した場合は、タスクの同時実行数を増やすことで軽減できます。
同時実行数を増やす場合は、タスクのメモリも増やす必要があります。一般的な目安として、並列スレッドを 4 つ追加するごとに 1 GB のメモリを追加します。
タスクの同時実行数とメモリを次のように構成します。
DataStudio で作成された単一テーブルから単一テーブルへの ETL リアルタイム同期タスクでは、右側の Basic Configurations をクリックして、タスクの並行度とメモリを設定します。 [基本設定] パネルでは、[同期方法]、[分散実行モード] スイッチ、[リソースグループ]、[CU]、[並列スレッド数] などのパラメーターを設定できます。 [詳細設定] を展開して、[フラッシュ間隔] (デフォルト: 60000 ms) と [MaxCompute チャネルリソース] を設定します。 たとえば、[ストリーミングトンネル] を選択し、[スロット数] を設定します。
DataHub へのデータベース移行など、その他の DataStudio タスクの場合は、Configure Resource ステップで並列スレッド数を、Basic Configurations パネルでメモリを設定します。
同期ソリューションタスクでは、Configure Resource ステップで並列スレッド数とメモリを設定できます。
分散実行モードが無効になっている場合は、並列スレッド数を 32 以下に設定します。並列スレッド数を 20 を超えて設定すると、単一マシンのリソースボトルネックによりレイテンシーが発生する可能性があります。特定のチャネルでは、分散実行モードを有効にしてパフォーマンスを向上させることができます。分散実行モードをサポートするチャネルは、次の表に示されています。
タスクタイプ | ソース | デスティネーション |
DataStudio ETL タスク | Kafka | MaxCompute |
DataStudio ETL タスク | Kafka | Hologres |