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