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

Simple Log Service:ビジネスキー集約によるクエリの高速化

最終更新日:Aug 19, 2026

ビジネスキー集約ストレージは、Simple Log Service (SLS) の Logstore におけるストレージ拡張機能です。この機能は、trace ID や session ID などの単一のビジネスキーを持つログを、同一の ShardGroup に書き込みます。この機能を使用しない場合、これらのログはすべてのシャードに分散され、各ポイントクエリは Logstore 全体をスキャンするため、データが増加するにつれて低速になります。この機能を有効にすると、書き込み方法やクエリ構文を変更することなく、クエリ時に無関係なシャードをプルーニングできます。

重要

ビジネスキー集約ストレージは、現在 ap-southeast-8 リージョンでのみリリースされています。ビジネスキーポリシーを計画する前に、お使いの Logstore のリージョンをご確認ください。

利用シーン

ビジネスキー集約ストレージは、クエリ条件に同じビジネスキーフィールドに対する等価条件が一貫して含まれる場合に、クエリがスキャンするシャードの数を削減します。以下の表に、典型的なシナリオと推奨されるビジネスキーの組み合わせを示します。

シナリオ

推奨ビジネスキー

メリット

トレースのトラブルシューティング

trace_id、 service + trace_id

単一のコールチェーンをクエリする際にシャードのスキャン範囲を絞り込み、トレースログの取得を高速化します。

エージェントアプリケーションのオブザーバビリティ

trace_id、 agent_run_id、 session_id

1 回のエージェント実行におけるモデルコール、ツールコール、リトリーバル、メモリ操作、異常をまとめて格納し、トレースクエリを高速化します。

ユーザーセッション分析

tenant_id + session_id、 tenant_id + user_id

単一のユーザーまたはセッションの完全な行動ログを迅速に返します。

注文とトランザクションのトラブルシューティング

tenant_id + order_id、 transaction_id

注文の例外、支払いの失敗、トランザクションチェーンの問題を迅速に特定します。

ホストとクライアントのアクセスログ

__source__ + remote_addr、 host

トラブルシューティングのために、同じソース、クライアント、またはドメイン名からのアクセスログをグループ化します。

IoT とデバイスのログ

tenant_id + device_id

単一デバイスの操作、アラート、接続ログを迅速に返します。

セキュリティ監査と攻撃の追跡

src_ip、 account_id、 ak_id、 user_id

特定の IP アドレス、アカウント、AccessKey、またはユーザーの行動ログを追跡します。

不適切なシナリオ

以下のシナリオでは、ビジネスキー集約ストレージのメリットは限定的であるか、書き込みホットスポットが発生する可能性があります。有効にする前に、クエリパターンとデータの分布を評価してください。

シナリオ

理由

クエリに固定のビジネスキーがほとんど含まれない

SLS はビジネスキーによるシャードのプルーニングができないため、メリットは限定的です。

Logstore のシャードが少なすぎる

各 ShardGroup に含まれる書き込み可能なシャードが少なすぎるため、災害復旧能力が制限されます。

ビジネスキーの値が著しく偏っている

ビジネスキーフィールドの値が不均一に分布しているため、書き込みスキューが発生します。たとえば、単一の user_id が全ログの 20% 以上を占める場合、それに対応する割合のログが同じ ShardGroup に書き込まれます。

お使いの Logstore がこれらのシナリオのいずれかに一致する場合、この機能を有効にするかどうかを決定する前に、「前提条件」で書き込み可能なシャードの構成を確認し、候補となるビジネスキーフィールドの値の分布とカバレッジを確認してください。

前提条件

  • プロジェクトと Logstore を作成します。手順については、「プロジェクトの管理」および「Logstore の管理」をご参照ください。

  • trace_id、 session_id、 user_id、 order_id などのビジネスキーフィールドを計画します。ログに一貫して存在し、クエリフィルターとして頻繁に使用され、高い選択度を持つフィールドを選択してください。

  • ターゲット Logstore の書き込み可能なシャードの数を確認します。8 つの書き込み可能なシャードが推奨構成です。これにより、各 ShardGroup は約 2 つの書き込み可能なシャードを保持でき、妥当な災害復旧能力を確保できます。4 つの書き込み可能なシャードでこの機能を有効にすることもできますが、その場合、各 ShardGroup は約 1 つの書き込み可能なシャードしか保持できず、災害復旧能力は制限されます。シャードの数を表示および調整するには、「シャードの管理」をご参照ください。

制限

ビジネスキー集約ストレージには、以下の制限が適用されます。

  • サポートされるリージョン — ビジネスキー集約ストレージは、現在 ap-southeast-8 リージョンでのみリリースされています。他のリージョンはサポートされていません。

  • サポートされるリソース — Logstore のみがビジネスキー集約ストレージをサポートします。

  • ビジネスキーフィールドの数 — 1 つ以上、2 つ以下のビジネスキーフィールドを設定する必要があります。

  • フィールドの順序 — フィールドの順序はルート計算に関与します。フィールドの順序を変更すると、ポリシーの変更として扱われます。

  • 欠損値または空の値 — ビジネスキーフィールドが存在しないか、その値が空の場合、ハッシュ計算では空の文字列が使用されます。

  • ShardGroup の数 — ShardGroup の数は、4、8、16、32、64 のように 2 のべき乗である必要があります。

  • ポリシーの変更による影響 — 新しいポリシーは短い遅延の後に有効になり、有効になった後に書き込まれるログにのみ適用されます。SLS は履歴データを再分散しません。

ビジネスキー集約ストレージの設定

ビジネスキー集約ストレージは、Logstore の作成時にオンにするか、既存の Logstore のプロパティページで設定します。どちらのエントリポイントでも同じ設定項目が表示され、ビジネスキーフィールドと ShardGroup の数はどちらの場合も同じ意味を持ちます。

新しい Logstore でのビジネスキー集約ストレージの有効化

  1. Simple Log Service コンソール にログインします。

  2. [プロジェクト] リストで、ターゲットプロジェクトをクリックします。

  3. ログ管理 > Logstores タブで、 + アイコンをクリックします。

  4. Logstore の作成 ページで、 [ビジネスキー集約ストレージ] 設定項目を見つけます。

  5. [ビジネスキー集約ストレージ] スイッチをオンにし、 [ビジネスキーフィールド] と [ShardGroup の数] を設定します。現在の書き込み可能なシャードの数に基づいてコンソールが推奨する ShardGroup の数を入力するには、 [推奨値を使用] をクリックします。

  6. [OK] をクリックします。

既存の Logstore でのビジネスキー集約ストレージの変更または無効化

  1. Simple Log Service コンソール にログインします。

  2. [プロジェクト] リストで、ターゲットプロジェクトをクリックします。

  3. ログ管理 > Logstores タブで、ターゲット Logstore にポインターを移動し、 [変更] を選択します。

  4. Logstore のプロパティページのナビゲーションペインで、 [ビジネスキー集約ストレージ] をクリックします。

  5. 以下のいずれかの方法で設定を構成します。

    • 機能を有効にするか、その設定を変更するには、 [ビジネスキー集約ストレージ] スイッチをオンにし、 [ビジネスキーフィールド] と [ShardGroup の数] を設定します。ビジネスキーフィールド、その順序、または ShardGroup の数を変更することはポリシーの変更として扱われ、新しいポリシーは変更が有効になった後に書き込まれるログにのみ適用されます。

    • 機能を無効にするには、 [ビジネスキー集約ストレージ] スイッチをオフにします。これにより、新しいログはビジネスキーで集約されなくなり、ビジネスキーのプルーニングも適用されなくなります。

  6. [保存] をクリックします。

    ビジネスキー集約ストレージを無効にした後も、すでに書き込まれたログは元のシャードに残ります。SLS はそれらを移行または再分散しないため、この機能を無効にしてもデータ損失やデータの再書き込みは発生しません。

パラメーター

以下の表に、Logstore の作成ページと Logstore のプロパティページにあるビジネスキー集約ストレージの設定項目について説明します。

パラメーター

説明

ビジネスキー集約ストレージ

ビジネスキー集約ストレージを有効にするかどうかを指定します。スイッチをオンにすると、SLS は同じビジネスキーを共有するログを同じ ShardGroup に書き込みます。

ビジネスキーフィールド

ログがどの ShardGroup に書き込まれるかを決定するフィールドです。1 つまたは 2 つのフィールドを設定します。

ShardGroup の数

ビジネスキー集約に使用される論理グループの数です。値は 2 のべき乗である必要があります。(推奨) コンソールの推奨値を使用してください。

推奨値を使用

現在の書き込み可能なシャードの数に基づいて、推奨される ShardGroup の数を計算します。

シャードデータ範囲の均衡状態

現在の Logstore のシャードデータ範囲が均衡しているかどうかを示します。これは、データ範囲の再分散が必要かどうかを判断するのに役立ちます。

データ範囲の再分散

シャードデータ範囲を再分散して、不均衡なシャードデータ範囲を修正します。データ範囲の再分散を実行する前に、たとえば SDK を介して、ログが指定されたハッシュキーで書き込まれているかどうかを確認してください。

ShardGroup の数の選択

ShardGroup の数は、クエリプルーニングの粒度を決定します。設定する ShardGroup の数が多いほど、各クエリがスキャンするシャードの数は少なくなりますが、各グループが保持できる書き込み可能なシャードの数も少なくなり、災害復旧能力が低下し、ホットスポットのリスクが増加します。コンソールは、Logstore 内の現在の書き込み可能なシャードの数に基づいて値を提案し、その推奨値は、クエリプルーニングの効率、災害復旧能力、およびホットスポットのリスクのバランスを考慮したものです。

現在の書き込み可能なシャード

推奨される ShardGroup

説明

4

4

グループあたり約 1 つの書き込み可能なシャード。クエリのプルーニングは可能ですが、災害復旧能力は制限されます。

8

4

グループあたり約 2 つの書き込み可能なシャード。この機能の使用を開始する際に適しています。

16

4 または 8

クエリの高速化要件に基づいて値を選択します。

32

8 または 16

高頻度のポイントクエリに適しています。

64

16 または 32

大規模なポイントクエリ、トレースのトラブルシューティング、セッション分析に適しています。

[推奨値を使用] をクリックして、推奨値を適用します。範囲内で、値が高いほどクエリプルーニングの粒度が細かくなり、値が低いほど各 ShardGroup でより多くの書き込み可能なシャードを保持できます。

クエリヒットとフォールバック条件

ビジネスキー集約ストレージを有効にすると、すべてのビジネスキーフィールドに対する等価条件がクエリに含まれている場合、そのクエリはビジネスキープルーニングにヒットします。SLS は、ビジネスキーの値からターゲットの ShardGroup を計算し、Logstore のすべてのシャードではなく、そのグループのシャードのみをスキャンします。これにより、計算対象のデータ量が削減されます。

たとえば、ビジネスキーフィールドが tenant_id と agent_run_id で、クエリに次の条件が含まれているとします。

tenant_id = 'tenant-a' AND agent_run_id = 'run-001'

SLS はこれらの値から単一のターゲット ShardGroup を特定し、そのグループのシャードのみをスキャンします。

以下の場合、クエリはビジネスキー集約ストレージにヒットせず、全シャードスキャンにフォールバックします。

  • ビジネスキーフィールドの欠落 — クエリにビジネスキーフィールドのいずれかが含まれていません。

  • 非等価一致 — ビジネスキーフィールドが、等価条件ではなく、あいまい一致、範囲一致、または正規表現によって照合されています。

  • あいまいなビジネスキーの値 — クエリ式が一意のビジネスキーの値に解決されません。

  • 時間範囲内のポリシーの変更 — クエリの時間範囲がポリシーの変更をまたいでいるか、現在のポリシーが有効になる前に書き込まれたログを対象としているため、単一のポリシーをプルーニングに使用できません。

  • 機能が無効 — Logstore でビジネスキー集約ストレージが有効になっていません。

課金

ビジネスキー集約ストレージによって、Logstore の課金方法が変更されることはありません。有効にした後も、書き込み、ストレージ、クエリ、分析の料金は、Logstore の現在の課金方法に基づいて請求されます。

クエリがビジネスキープルーニングにヒットすると、スキャンデータ量とクエリの実行時間が減少し、関連するクエリおよび分析料金も同様に減少する可能性があります。実際のメリットは、クエリに完全なビジネスキーが含まれているかどうか、ShardGroup の数、データの分布、およびクエリの時間範囲によって異なります。

よくある質問

ビジネスキー集約ストレージを有効にした後、クエリが著しく高速化されないのはなぜですか?

まず、クエリが「クエリヒットとフォールバック条件」で説明されているヒット条件を満たしているか確認してください。クエリがヒット条件を満たしている場合は、次の設定上の原因を確認してください。

  • 大部分のログにビジネスキーフィールドが欠落しているため、集約効果が弱くなっています。

  • ShardGroup の数が少なすぎるため、プルーニングされるシャードがほとんどありません。

ビジネスキーフィールドが存在しない場合はどうなりますか?

SLS はハッシュ計算で空の文字列を使用するため、値が欠落しているか空であるすべてのログは同じ ShardGroup に書き込まれます。多数のログでビジネスキーフィールドが欠落している場合、書き込みスキューが発生します。ビジネスキー集約ストレージを有効にする前に、ビジネスキーフィールドのカバレッジを確認してください。

データ範囲の再分散はいつ必要ですか?

[シャードデータ範囲の均衡状態] が、シャードデータ範囲の不均衡を示している場合に、データ範囲の再分散を検討してください。実行する前に、たとえば SDK を介して、ログが指定されたハッシュキーで書き込まれているかどうかを確認してください。アプリケーションが指定されたハッシュキーで書き込みを続けている場合、再分散後もホットスポットが持続する可能性があります。