読み取りワークロードと書き込みワークロードの分離

​

読み取りと書き込みを分離する理由

• 書き込みが読み取りの性能を落とさなくなる。 継続的な OpenTelemetry インジェスト (insert そのものと、それに続くバックグラウンドマージ) は、ダッシュボードや検索のクエリと CPU およびメモリを奪い合います。インジェスト実行中は読み取りレイテンシが目に見えて悪化し、停止すると回復します。
• 読み取りが書き込みを妨げなくなる。 この競合は双方向に発生します。重いアドホッククエリや高コストなダッシュボードの描画がサービスのメモリを使い切り、insert が遅くなるどころか完全に失敗することもあります。
• 読み取り専用コンピュートをクエリに専念させられる。 読み取り専用サービスは、システムテーブル以外でバックグラウンドマージを実行しません。また、マージによって起動状態が維持されうる読み書きサービスと異なり、遅延なくアイドル状態に入ります。
• それぞれを個別にサイジングできる。 sizing model は ingest compute と query compute を別々に見積もり、warehouse では両者をそれぞれ独立したサービスとしてプロビジョニングできます。モデルのベースラインである 1 QPS を超えると query compute が支配的になり、5 QPS の計算例ではインジェストに 58 vCPU、クエリに 290 vCPU という結果になります。つまり、小規模な書き込みサービスで、はるかに大規模な読み取りサービスにデータを供給できます。
• アイドル化とオートスケーリングはサービス単位で設定できる。 各サービスがそれぞれのレプリカ数、オートスケーリング、自動アイドル化の設定を持つため、書き込みサービスは継続的インジェストのために常時稼働させたまま、読み取りサービスは業務時間外にアイドル化させるといった構成が可能です。
• ストレージは重複しない。 warehouse 内のサービスは同じオブジェクトストレージのフォルダーと同じテーブルを共有し、ストレージの課金は一度だけです。
• エンドポイントごとにアクセスを制限できる。 IP access list はサービスごとに適用されるため、書き込みエンドポイントは collector からのみ、読み取りエンドポイントは ClickStack デプロイメントからのみ到達可能にできます。ネットワークアクセス制御のガイドを参照してください。

​

アーキテクチャ

• warehouse の最初のサービスは常に読み書きであり、サービスの種別は作成時に固定されます。読み取り専用と読み書きを切り替えるには、warehouse 内に新しいサービスを作成してください。
• warehouse 内のすべてのサービスは、同じクラウドプロバイダー、リージョン、ClickHouse バージョン、Keeper、およびプライマリサービスのアップグレードスケジュールを共有します。
• インジェストに使用する読み書きサービスは1 つにしてください。マージはストレージを共有するすべての読み書きサービスに割り当てられるため、あるサービスでの挿入に対するマージが別のサービスで実行されることがあります。その別のサービスが重いクエリも処理している場合、それらのクエリはマージを実行しているサービス上で CPU とメモリを奪い合います。その結果、最初のサービスの挿入に対するマージが遅くなり、挿入パフォーマンスも低下します。クエリワークロードは読み取り専用サービスに集約し、マージをインジェストから分離する必要がある場合にのみ 2 つ目の読み書きサービスを追加してください。

​

分離されたデプロイメントのセットアップ

CREATE DATABASE otel;
CREATE USER hyperdx_ingest IDENTIFIED WITH sha256_password BY '<strong-password>';
GRANT SELECT, INSERT, CREATE DATABASE, CREATE TABLE, CREATE VIEW ON otel.* TO hyperdx_ingest;

CLICKHOUSE_ENDPOINT=https://<read-write-service>.clickhouse.cloud:8443
CLICKHOUSE_USER=hyperdx_ingest
CLICKHOUSE_PASSWORD=<strong-password>
HYPERDX_OTEL_EXPORTER_CLICKHOUSE_DATABASE=otel

SELECT 
    user, 
    query_kind, 
    http_user_agent,
    count()
FROM clusterAllReplicas('default', system.query_log)
WHERE event_time > now() - toIntervalMinute(10) 
  AND type = 'QueryFinish'
  AND is_initial_query = 1
GROUP BY ALL
ORDER BY count() DESC;

SELECT 
    hostName() AS host, 
    query_kind, 
    count()
FROM clusterAllReplicas('all_groups.default', system.query_log)
WHERE event_time > now() - toIntervalMinute(10) 
  AND type = 'QueryFinish'
  AND is_initial_query = 1
GROUP BY ALL;

​

マージをインジェストから分離する

• どちらの読み書きサービスについても、自動アイドル化に依存しないでください。 マージを無効化したサービスであっても、ウェアハウス内の他のサービスでのインサートによって生成されるパーツのダウンロードおよび削除イベントは処理します。また、マージされていないパーツが多数存在すること自体がアイドル化を妨げる要因になります。どちらの読み書きサービスも常時稼働している前提で計画してください。
• どちらの読み書きサービスにもクエリを向けないでください。 読み書きサービス上で重い SELECT クエリを実行すると、CPU とメモリをめぐってマージ処理と競合します。これはまさに、このトポロジーが回避しようとしている障害モードです。前述のとおり、ClickStack は読み取り専用サービスに向けてください。
• ミューテーションが存在する場合、それを実行したサービス上で追跡されます。 オブザーバビリティにおいてミューテーションはまれです。ClickStack のスキーマは ttl_only_drop_parts = 1 を設定しているため、通常の保持期間管理では行をミューテーションで削除するのではなく、TTL マージの際に期限切れのパーツ全体を削除します。ミューテーションを生成する ALTER をインジェストサービスに送信した場合、それはマージサービスによって実行され、その進捗はインジェストサービスではなくマージサービス側の system.mutations に現れます。

​

管理と DDL

• テーブル作成 - 初回のインジェスト時に ClickStack collector が自動的に実行します
• 保持期間を変更するための 有効期限 (TTL) の変更
• クエリ高速化のための materialized view の作成
• スキップ索引、projections、その他のパフォーマンス最適化 の追加

CREATE DATABASE otel
SETTINGS distributed_ddl_task_timeout=0

​

エージェント型ワークロードの分離

claude mcp add --transport http clickstack https://mcp.clickhouse.cloud/clickstack \
  --header "x-service-id: <read-only-agent-service-id>"

​

アラート

​

alert 評価の分離

• 共通の alerts と、それに付随する dashboards は alert 評価用サービス上にのみ存在し、クエリ用サービスで作業しているユーザーからは見えません。通知はいずれの場合も同じ宛先に配信されるため、ユーザーが失うのは定義の可視性であって、alert 機能そのものではありません。
• alert 評価用サービス上の SOURCES は別個の object です。デフォルトの OpenTelemetry スキーマを使用しているものは自動検出されますが、カスタムのログソースは、alert から参照できるようにするために、そちらでも設定する必要があります。

​

その他の考慮事項