データ変換のパフォーマンスに影響する要因と、シャードおよび変換ロジックを調整してスループットを最適化する方法について説明します。
仕組みに基づき、データ変換ジョブの全体的な速度は、ソース LogStore のシャード数と変換ロジックの複雑さによって決まります。 目安として、シャードあたり 1 MB/s の非圧縮データの処理スループットを見込んでください。これは、シャードあたり 1 日約 85 GB に相当します。 たとえば、ソース LogStore のデータ書き込みレートが 1 日あたり 1 TB の場合、少なくとも 12 個のシャードに分割する必要があります (1,024 GB / 85 GB/シャード ≈ 12)。 シャードの分割の詳細については、「シャードの分割」をご参照ください。
データ変換のパフォーマンス
データ変換の速度は、変換ロジックに依存します。主な要因は次のとおりです：
-
出力データ
-
出力データの量が増えるほど、パフォーマンスは低下します。ログエントリをより多く生成する (たとえば、1 つのエントリを複数に分割する)、フィールドを追加する、またはコンテンツサイズを増やすと、CPU とネットワークリソースの消費が増え、スループットが低下します。
-
複数の送信先に書き込む、各ログエントリに多数のタグを追加する、またはロググループを増やすと、パフォーマンスが低下します。各操作により、ネットワークのやり取りとオーバーヘッドが増加します。
-
-
変換ロジック
複雑な変換ロジックでは、検索、計算、外部リソースの同期が増えます。これらは追加のコンピューティングおよびネットワークリソースを消費するため、スループットが低下します。
-
外部データソース
サードパーティのソースを使用してデータエンリッチメントを行う場合、取得するデータ量が多いほど変換が遅くなります。別リージョンの OSS オブジェクトなど、クロスリージョンでのデータ取得はパフォーマンスをさらに低下させます。
ソース Logstore のスケーリング
-
リアルタイムデータ変換のスケーリング
リアルタイムデータ変換のパフォーマンスを向上させるには、シャード数を増やしてください。シャードの課金方法の詳細については、「機能別課金」をご参照ください。
-
履歴データ変換のスケーリング
シャードの分割が影響するのは、新しく書き込まれるデータのみです。シャード数が少ない Logstore 内の大量の履歴データを処理するには、複数のデータ変換ジョブを作成してください。各ジョブが重複しない個別の時間範囲を処理するように設定してください。たとえば、9 月 1 日から 9 月 10 日までの履歴ログを処理する場合、
[9/1, 9/2), [9/2, 9/3), ..., [9/10, 9/11)のように日単位でデータを処理する 10 個のジョブを作成できます。説明変換時間はログ受信時間です。詳細については、「データ変換ジョブの作成」をご参照ください。
送信先 Logstore のスケーリング
送信先 Logstore に必要なシャード数は、次の 2 つの要因に依存します：
-
書き込みスループット
単一の Logstore シャードは、最大 5 MB/s の書き込みスループットをサポートします。必要な送信先シャード数は、ソースシャード数と処理同時実行数に基づいて見積もってください。たとえば、ソース Logstore に 20 シャードがある場合、送信先 Logstore には少なくとも 4 シャードが必要です。
-
クエリと分析の要件
送信先 Logstore のデータに対してインデックスを作成し、クエリを実行する場合は、クエリ範囲に基づいてシャード数を計画してください。経験則として、一度にクエリするログエントリが 5,000 万件ごとに 1 シャードをプロビジョニングしてください。たとえば、1 日あたり 10 GB のログを書き込み、平均的なログエントリが 1 KB だとします。これは 1 日あたり 1,000 万件のログエントリに相当します。クエリで 30 日間にまたがる必要がある場合、約 3 億件のログエントリをクエリすることになります。このシナリオでは、送信先 Logstore を 6 シャード (3 億件 / シャードあたり 5,000 万件) で構成してください。