Simple Log Service (SLS) は、コンシューマープロセッサーを使用したリアルタイムデータ消費機能を提供します。Structured Process Language (SPL) を使用して、消費前にサーバー上でデータを処理できます。このトピックでは、コンシューマープロセッサーの概念、メリット、利用シーン、課金ルール、およびサポートされている消費ターゲットについて説明します。
仕組み
コンシューマープロセッサーは、SPL を使用して SLS データをリアルタイムで処理します。この機能は、サードパーティソフトウェア、多言語アプリケーション、クラウド製品、ストリームコンピューティングフレームワークなど、さまざまなアプリケーションに適しています。SPL は、半構造化ログ向けに設計されたパフォーマンス専有型のデータ処理言語です。行フィルタリング、列のトリミング、正規表現ベースの抽出など、サーバー上でログデータの前処理とクリーニングが可能です。処理後、クライアントは構造化形式でデータを受信します。SPL 構文の詳細については、「SPL 構文」をご参照ください。
メリット
-
インターネット経由でのデータ消費におけるデータ転送コストを削減します。
たとえば、ログを SLS に書き込み、その後インターネット経由で消費する場合、内部システムに配布する前にログをフィルタリングする必要があるかもしれません。SPL ベースの消費を使用すると、SLS 内で直接ログをフィルタリングできます。これにより、大量の無関係なログがコンシューマーに送信されるのを防ぎ、データ転送コストを節約できます。
-
ローカルの CPU リソースを節約し、コンピューティングを高速化します。
たとえば、ログを SLS に書き込み、その後ローカルマシンでコンピューティングのために消費する場合、SPL ベースの消費を使用して SLS 内で直接コンピューティングを実行します。これにより、ローカルリソースの消費が削減されます。
課金ルール
-
ご利用の Logstore がデータ書き込み量課金モードを使用している場合、コンシューマープロセッサーを使用しても追加料金は発生しません。Simple Log Service (SLS) のパブリックエンドポイントからデータをプルする場合にのみ、アウトバウンドデータ転送に対して課金されます。コストは圧縮データの量に基づいて計算されます。詳細については、「データ書き込み量課金モードの課金項目」をご参照ください。
-
ご利用の Logstore が機能別課金モードを使用している場合、コンシューマープロセッサーを使用するとサーバー側のコンピューティング料金が発生します。パブリックエンドポイントを使用する場合は、アウトバウンドデータ転送に対しても課金されることがあります。詳細については、「機能別課金モードの課金項目」をご参照ください。
消費ターゲット
次の表に、SLS がコンシューマープロセッサーでサポートする消費ターゲットを示します。
|
タイプ |
ターゲット |
説明 |
|
多言語アプリケーション |
多言語アプリケーション |
Java、Python、Go などの言語に基づくアプリケーションは、コンシューマープロセッサーベースのコンシューマーグループを使用して SLS からデータを消費できます。詳細については、「API を使用したデータ消費」および「コンシューマーグループを使用したログの消費」をご参照ください。 ベストプラクティス：「SDK を使用したコンシューマープロセッサー (SPL) ベースのログ消費」 |
|
クラウド製品 |
Alibaba Cloud Flink |
Alibaba Cloud Flink リアルタイムコンピューティングを使用して、SLS からデータを消費できます。詳細については、「Simple Log Service (SLS)」をご参照ください。 ベストプラクティス： |
|
ストリームコンピューティング |
Kafka |
この機能が必要な場合は、チケットを送信してください。 |
注意事項
-
コンシューマープロセッサーは、サーバー上で複雑な計算を実行します。SPL の計算の複雑さやデータの特性によって、サーバー側のデータ読み取りレイテンシーがわずかに増加する可能性があります。たとえば、5 MB のデータを処理すると、レイテンシーが 10 ms から 100 ms 増加することがあります。ただし、サーバー側のレイテンシーが増加しても、データのプルからローカルでの計算完了までの合計時間であるエンドツーエンドのレイテンシーは、通常は減少します。
-
コンシューマープロセッサーを使用する際、SPL 構文エラーやソースデータフィールドの欠落などの問題により、データ損失や消費の失敗が発生する可能性があります。詳細については、「エラー処理」をご参照ください。
-
コンシューマープロセッサー構成における SPL 文の最大長は 4 KB です。
-
コンシューマープロセッサーのシャード読み取り制限は、通常のリアルタイム消費と同じです。コンシューマープロセッサーのシャード読み取りトラフィックは、SPL 処理前の生データ量に基づいて計算されます。制限の詳細については、「データの読み取りと書き込み」をご参照ください。
制限事項
|
項目 |
説明 |
|
Consume Processor の数 |
各プロジェクトで作成可能な Consume Processor の最大数は 100 個です。クォータの増量を希望する場合は、チケットを送信してください。 |
|
Consume Processor 構成における SPL 文の長さ |
各 SPL 文は 4,000 文字を超えてはなりません。 |
|
Consume Processor における SPL 命令の制限 |
行処理命令のみがサポートされています。集約、論理判断、その他の類似操作を行う命令はサポートされていません。 |
|
Consume Processor の更新または削除の有効期間 |
Consume Processor 構成の更新または削除は、1 分以内に有効になります。 |
よくある質問
-
コンシューマープロセッサー使用時に ShardReadQuotaExceed エラーを処理するにはどうすればよいですか？
-
このエラーコードは、シャードの読み取りトラフィックがクォータを超えたことを示します。この問題を解決するには、次のいずれかのソリューションを使用します：
-
クライアントアプリケーションでこのエラーが発生した場合は、一定期間待ってから操作をリトライしてください。
-
または、手動でシャードを分割することもできます。これにより、結果として得られるシャードから新しいデータを消費する際の各シャードの読み取り速度が低下します。
-
-
-
コンシューマープロセッサーのトラフィックシェーピングポリシーは何ですか？
-
コンシューマープロセッサーのスロットリングポリシーは、標準のデータ消費と同じです。詳細については、「データの読み取りと書き込み」をご参照ください。コンシューマープロセッサーのトラフィックは、SPL 処理前の生データ量に基づいて計算されます。
-
たとえば、生データサイズが 100 MB (圧縮) であると仮定します。データが SPL 文
* | where method = 'POST'によってフィルタリングされた後、クライアントに返されるデータは 20 MB (圧縮) です。スロットリング目的のトラフィックは 100 MB として計算されます。
-
-
-
ルールを使用してデータを消費した後、「プロジェクトモニタリング」の「トラフィック/分」チャートでアウトバウンドトラフィックが低いのはなぜですか？
-
プロジェクトモニタリングの「トラフィック/分」チャートのアウトバウンドトラフィック値は、SPL 処理後のデータ量を示しており、生データ量ではありません。SPL 文に行フィルタリングや列のトリミングなど、データ量を削減する命令が含まれている場合、アウトバウンドトラフィック値は低くなることがあります。
-