本番環境への移行

本番環境に ClickStack をデプロイする際には、セキュリティ、安定性、および適切な構成を確保するために、追加で考慮すべき事項がいくつかあります。これらは、使用しているディストリビューションがオープンソース版かマネージド版かによって異なります。

マネージド型 ClickStack

本番環境でのデプロイには、Managed ClickStack の利用を推奨します。これはデフォルトで業界標準の セキュリティプラクティス が適用され、強化された暗号化・認証・接続性と、管理されたアクセス制御に加えて、次の利点を提供します。

• ストレージから独立したコンピュートの自動スケーリング
• オブジェクトストレージに基づく低コストかつ実質無制限の保持期間
• Warehouse を用いて読み取り・書き込みワークロードを個別に分離できる機能
• 統合された認証
• 自動化された バックアップ
• シームレスなアップグレード

Managed ClickStack を利用する際は、ClickHouse Cloud に対するこれらのベストプラクティスに従ってください。

インジェストのセキュリティ保護

デフォルトでは、オープンソースディストリビューションの外部にデプロイされた ClickStack OpenTelemetry Collector は保護されておらず、OTLP ポートで認証を要求しません。

インジェストを保護するには、OTLP_AUTH_TOKEN 環境変数を使用して collector をデプロイする際に認証トークンを指定します。詳細は "Securing the collector" を参照してください。

インジェスト用ユーザーの作成

OTel collector が Managed ClickHouse にインジェストを実行し、かつ otel など特定のデータベースにインジェストが送信されるようにするため、専用ユーザーを作成することを推奨します。詳細は "Creating an ingestion user" を参照してください。

Time To Live (有効期限 (TTL)) の設定

Managed ClickStack デプロイメントに対して、Time To Live (TTL) が適切に設定されていることを確認してください。これはデータの保持期間を制御します。デフォルトの 3 日は、変更が必要になることが多くあります。

リソース見積もり

以下では、想定されるインジェスト量に基づき、ClickStack のデプロイに必要なコンピュートおよびストレージリソースを見積もるためのモデルを示します。算出される値はあくまで概算であり、初期ベースラインとして利用してください。規定的な答えではありません。実際に必要となるリソースは、クエリの複雑さ、同時実行数、保持ポリシー、インジェスト処理量の変動によって異なります。必ずリソース使用量を監視し、必要に応じてスケールしてください。

すべての数値は非圧縮の生インジェストに基づきます

このページのすべての数値 - スループット (MB/s、TB/月) 、CPU サイジング、ストレージ - は、非圧縮の生インジェスト量、つまりアプリケーションによって生成され、圧縮が適用される前に OpenTelemetry collector に送信されるデータサイズを基準にしています。

この値は、既存のログ、トレース、メトリクスのパイプラインから見積もってください。以下の表にあるストレージ値には、この生データ量に対する想定10 倍圧縮率がすでに適用されています。

ClickStack をデプロイする際は、インジェストとクエリという 2 つの独立したワークロードをまかなえるようにコンピュートをプロビジョニングしてください。

ワークロード	推定リソース
インジェスト	持続的なインジェストスループット 10 MB/s あたり 1 vCPU
クエリ	1 QPS あたり 1 vCPU、かつ持続的なインジェストスループット 10 MB/s あたり 1 vCPU

クエリとインジェストの分離

ほとんどのセルフマネージド環境では、インジェストとクエリは同じノードを共有します。この場合は、Total CPUs をベースラインとして使用してください。インジェスト用とクエリ用のコンピュートを個別にプロビジョニングする分離スケーリングは、ClickHouse Cloud では 個別のコンピュートプール (別名 Warehouses) によってサポートされています。

前提

• ストレージについては10 倍圧縮率を想定しています。これは通常、ログとトレースに対しては保守的な見積もりです。
• クエリ SLA は、P50 が 1.5 秒、P99 が 5 秒です。
• ほとんどのクエリは直近のデータに対して実行され、約 1 時間付近でピークを迎え、約 6 時間まで裾を引く対数正規分布に従うと想定しています。古いデータをクエリするために、専用のコンピュートをプロビジョニングしたい場合もあります。ClickHouse Cloud では、使用していないときはこれを idle 状態にできるため、コストは発生しません。
• クエリ用コンピュートはインジェスト用コンピュートとは独立してスケールできますが、本質的にはインジェスト量に結び付いています。インジェストが増えるとデータ密度が高まり、その結果、クエリ時のスキャン量が増え、それに伴ってクエリ用コンピュート要件も高くなると想定しています。

以下の表は、1 秒あたりのインジェストスループット (MB/s) の増加に応じたサイジング例と、それに対応する 1 か月あたりのデータ量 (TB) を示しています。これは、すべてのクエリタイプ (検索、ダッシュボード、アラート) を通じて ClickStack からの平均 1 QPS が持続すると仮定したものです。

MB/s	TB/月	Ingest CPUs	Query CPUs	Total CPUs	総ストレージ (1 か月あたり) (GB)
10	25.92	1	3	4	2,592
20	51.84	2	6	8	5,184
50	129.6	5	15	20	12,960
100	259.2	10	30	40	25,920
200	518.4	20	60	80	51,840
500	1,296	50	150	200	129,600
1000	2,592	100	300	400	259,200

お使いの環境に合わせてサイジング前提をさらに調整する方法の詳細については、"Refining sizing assumptions for your environment" を参照してください。

オブザーバビリティワークロードの分離

リアルタイムアプリケーション分析など、すでに他のワークロードをサポートしている既存の ClickHouse Cloud サービスに ClickStack を追加する場合は、オブザーバビリティトラフィックを分離することを強く推奨します。

Managed Warehouses を使用して、ClickStack 専用の子サービスを作成します。これにより、次のことが可能になります。

• 既存アプリケーションからインジェストおよびクエリ負荷を分離
• オブザーバビリティワークロードを独立してスケール
• オブザーバビリティクエリが本番分析に影響を与えるのを防止
• 必要に応じて、サービス間で同じ基盤データセットを共有

このアプローチにより、既存のワークロードに影響を与えずに、オブザーバビリティデータの増加に応じて ClickStack を独立してスケールさせることができます。

より大規模なデプロイやカスタムサイズのガイダンスが必要な場合は、より正確な見積もりについてサポートまでお問い合わせください。

ClickStack オープンソース

ネットワークおよびポートのセキュリティ

デフォルトでは、Docker Composeはホスト上のポートを公開し、コンテナ外部からアクセス可能にします。これはufw(Uncomplicated Firewall)などのツールが有効になっている場合でも同様です。この動作はDockerネットワークスタックに起因するもので、明示的に設定しない限り、ホストレベルのファイアウォールルールをバイパスします。

推奨:

本番環境で必要なポートのみを公開してください。通常はOTLPエンドポイント、APIサーバー、フロントエンドです。

例えば、docker-compose.yml ファイル内の不要なポートマッピングを削除するかコメントアウトします。

ports:
  - "4317:4317"  # OTLP gRPC
  - "4318:4318"  # OTLP HTTP
  - "8080:8080"  # Only if needed for the API
# Avoid exposing internal ports like ClickHouse 8123 or MongoDB 27017.

コンテナの分離とアクセスの強化に関する詳細は、Dockerネットワークドキュメントを参照してください。

セッションシークレットの構成

本番環境では、セッションデータの保護と改ざん防止のため、ClickStack UI (HyperDX) の EXPRESS_SESSION_SECRET 環境変数に強力でランダムな値を設定する必要があります。

アプリサービスの docker-compose.yml ファイルに追加する手順は以下の通りです:

  app:
    image: ${IMAGE_NAME_HDX}:${IMAGE_VERSION}
    ports:
      - ${HYPERDX_API_PORT}:${HYPERDX_API_PORT}
      - ${HYPERDX_APP_PORT}:${HYPERDX_APP_PORT}
    environment:
      FRONTEND_URL: ${HYPERDX_APP_URL}:${HYPERDX_APP_PORT}
      HYPERDX_API_KEY: ${HYPERDX_API_KEY}
      HYPERDX_API_PORT: ${HYPERDX_API_PORT}
      HYPERDX_APP_PORT: ${HYPERDX_APP_PORT}
      HYPERDX_APP_URL: ${HYPERDX_APP_URL}
      HYPERDX_LOG_LEVEL: ${HYPERDX_LOG_LEVEL}
      MINER_API_URL: 'http://miner:5123'
      MONGO_URI: 'mongodb://db:27017/hyperdx'
      NEXT_PUBLIC_SERVER_URL: http://127.0.0.1:${HYPERDX_API_PORT}
      OTEL_SERVICE_NAME: 'hdx-oss-api'
      USAGE_STATS_ENABLED: ${USAGE_STATS_ENABLED:-true}
      EXPRESS_SESSION_SECRET: "super-secure-random-string"
    networks:
      - internal
    depends_on:
      - ch-server
      - db1

openssl を使用して強度の高いシークレットを生成できます:

openssl rand -hex 32

シークレットをソース管理にコミットすることは避けてください。本番環境では、環境変数管理ツール(例: Docker Secrets、HashiCorp Vault、環境固有のCI/CD設定など)の使用を検討してください。

インジェストのセキュリティ保護

すべてのインジェストは、ClickStack ディストリビューションの OpenTelemetry (OTel) コレクターによって公開される OTLP ポート経由で行う必要があります。デフォルトでは、起動時に生成されるセキュアなインジェスト API key が必要です。このキーは OTel ポートにデータを送信する際に必須であり、HyperDX UI の Team Settings → API Keys で確認できます。

また、OTLPエンドポイントに対してTLSを有効化することを推奨します。

インジェスト用ユーザーの作成

ClickHouseへのインジェスト用にOTel collector専用のユーザーを作成し、インジェストが特定のデータベース(例: otel)に送信されるようにすることを推奨します。詳細については、"インジェストユーザーの作成"を参照してください。

ClickHouse

独自のClickHouseインスタンスを管理する場合は、以下のベストプラクティスに従ってください。

セキュリティのベストプラクティス

独自のClickHouseインスタンスを管理している場合、TLSの有効化、認証の強制、およびアクセス強化のベストプラクティスの遵守が不可欠です。実際の設定ミスとその回避方法については、このブログ記事を参照してください。

ClickHouse OSSは標準で堅牢なセキュリティ機能を提供しています。ただし、これらを利用するには設定が必要です。

• TLS を使用するには、config.xml で tcp_port_secure と <openSSL> を設定します。詳細は guides/sre/configuring-tls を参照してください。
• Set a strong password for the default user or disable it.
• 明示的にその意図がある場合を除き、ClickHouse を外部に公開しないでください。 デフォルトでは、listen_host を変更しない限り、ClickHouse は localhost のみにバインドされます。
• 認証手段を使用します。パスワード、証明書、SSHキー、外部認証機構 などがあります。
• アクセスを制限するには、IP フィルタリングと HOST 句を使用します。sql-reference/statements/create/user#user-host を参照してください。
• ロールベースアクセス制御 (RBAC) を有効にして、きめ細かな権限付与を行います。詳細は operations/access-rights を参照してください。
• クォータおよびその他の制限を厳格に適用するには、クォータ、settings profiles、および読み取り専用モードを使用します。
• 保存されているデータを暗号化し、安全な外部ストレージを使用してください。operations/storing-data および cloud/security/CMEK を参照してください。
• 認証情報のハードコードは避けてください。 named collections または ClickHouse Cloud の IAM ロールを使用してください。
• system logs と session logs を使用して、アクセスやクエリを監査します。

ユーザー管理とクエリ/リソース制限の確保については、外部認証機能およびクエリ複雑度設定も参照してください。

ClickStack UIのユーザー権限

ClickStack UIのClickHouseユーザーは、以下の設定を変更するアクセス権を持つreadonlyユーザーのみで十分です:

• max_rows_to_read (少なくとも 100 万行まで)
• read_overflow_mode
• cancel_http_readonly_queries_on_client_close
• wait_end_of_query

デフォルトでは、OSS と ClickHouse Cloud の両方で default ユーザーにこれらの権限が付与されていますが、これらの権限を持つ新しいユーザーを作成することを推奨します。

有効期限 (TTL) の設定

ClickStackデプロイメントに対して有効期限 (TTL)が適切に設定されていることを確認してください。これはデータの保持期間を制御します - デフォルトの3日間は変更が必要になることがよくあります。

MongoDB ガイドライン

公式の MongoDB セキュリティチェックリストに従ってください。