Skip to main content
以下では、想定されるインジェスト量に基づいて、ClickStackのデプロイメントに必要なコンピュートリソースとストレージリソースを見積もるためのモデルを示します。ここで算出される値はあくまで推定値であり、初期ベースラインとして利用してください。これは一律の答えではありません。実際に必要となるリソースは、クエリの複雑さ、同時実行数、保持ポリシー、インジェストスループットの変動によって異なります。リソース使用量は常に監視し、必要に応じてスケールしてください。
すべての数値は非圧縮の生インジェストに基づいていますこのページのすべての数値 (スループット (MB/s、TB/月) 、CPUサイジング、ストレージ) は、非圧縮の生インジェスト量、つまりアプリケーションによって生成され、圧縮が適用される前にOpenTelemetry Collectorへ送信されるデータサイズを基準にしています。これは、既存のログ、トレース、メトリクスのパイプラインから見積もるべき値です。以下の表のストレージ値には、この生データ量に対して想定される10倍の圧縮率がすでに適用されています。
ClickStackをデプロイする際は、インジェストとクエリという2つの独立したワークロードをまかなえるようにコンピュートをプロビジョニングしてください。
クエリとインジェストの分離ほとんどのセルフマネージド環境のデプロイメントでは、インジェストとクエリは同じノードを共有します。この場合は、Total CPUsをベースラインとして使用してください。インジェスト用とクエリ用のコンピュートを個別にプロビジョニングする分離スケーリングは、ClickHouse Cloud では separate compute pools aka Warehouses を通じてサポートされています。
  • ストレージには10倍の圧縮率を想定しています。これは通常、ログとトレースに対しては保守的な見積もりです。
  • クエリSLAは、P50が1.5秒、P99が5秒です。
  • ほとんどのクエリは直近のデータに対して実行され、約1時間付近でピークを迎え、約6時間まで裾を引く対数正規分布に従うと想定しています。より古いデータをクエリするために、専用のコンピュートをプロビジョニングしたい場合もあります。ClickHouse Cloud では、使用していないときはこれをアイドル状態にできるため、コストは発生しません。
  • クエリ用コンピュートはインジェスト用コンピュートとは独立してスケールできますが、本質的にはインジェスト量と結び付いています。インジェストが増えるにつれてデータ密度が高まり、その結果クエリ時のスキャン量が増加し、それに伴ってクエリ用コンピュートの必要量も増えると想定しています。
以下の表は、1秒あたりメガバイト単位で増加するインジェストスループットに基づくサイジング例と、それに対応する月あたりテラバイト単位のデータ量を示しています。これは、すべてのクエリタイプ (検索、ダッシュボード、アラート) を通じて、ClickStack から平均1 QPSが継続的に発生することを前提としています。

​
環境に合わせたサイジング前提の調整

このモデルは、検索、ダッシュボード、アラートを含むすべてのクエリタイプを合算した、ClickStack からの継続的な平均 1 QPS を前提としています。 クエリ量がこれを上回る場合は、必要な CPU を目標 QPS に応じて線形にスケールさせます。たとえば、100 MB/s で取り込むデプロイメントで目標が 9 QPS の場合、クエリ用に必要な CPU はベースラインの 10 ではなく 90 (10 × 9) となり、合計は 100 CPU (取り込み 10 + クエリ 90) になります。 ストレージの見積もりは、保守的に圧縮率 10 倍を前提としています。実際には、ログ、トレース、メトリクスはこれより高い圧縮率になることがよくあります。本番環境に入る前に圧縮率とストレージ要件を把握できるよう、データのサンプルで事前にテストすることを推奨します。保持期間を長くする場合に必要なストレージは、1 か月あたりのストレージ量に保持する月数を掛けて計算してください。 これは、クエリ分布が比較的均等であることを前提としています。より負荷の高い過去データ参照やアーカイブクエリに偏ったワークロードでは、必要なコンピュートが大きく異なる可能性があるため、負荷テストで検証する必要があります。今後は、クエリ分布パターンの違いに応じてクエリ用コンピュートを外挿できる、より柔軟なサイジングモデルを導入する予定です。

​
計算例

要件: 月間 1.5 PB の取り込み、5 QPS、3 か月保持。 MB/s への換算 サイジングモデルは MB/s で表されます。月間 1.5 PB (1,500 TB) を持続スループットに換算すると、次のようになります。
  • 1,500 TB = 1,500,000,000 MB
  • 1 か月あたりの Seconds (30 日) : 30 × 24 × 60 × 60 = 2,592,000
  • MB/s = 1,500,000,000 ÷ 2,592,000 ≈ 579 MB/s
取り込みコンピュート 持続的な取り込みが 10 MB/s ごとに 1 vCPU 必要とすると、次のようになります。 579 ÷ 10 = 取り込みに 約 58 vCPUs クエリコンピュート クエリコンピュートは、取り込みスループットと QPS の両方に応じて増加します。5 QPS の場合: (579 ÷ 10) × 5 = 58 × 5 = クエリに 290 vCPUs ストレージ 30 日間にわたって 579 MB/s を維持した場合、生の取り込み量は月間 1,500 TB です。想定される 10 倍の圧縮率を適用すると、次のようになります。
  • 月間の圧縮後容量: 1,500 TB ÷ 10 = 150 TB/月
  • 3 か月保持の場合: 150 TB × 3 = 合計 450 TB
要約

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

リアルタイムのアプリケーション分析など、すでに他のワークロードをサポートしている既存の ClickHouse Cloud サービスに ClickStack を追加する場合は、オブザーバビリティ トラフィックを分離することを強く推奨します。 ClickStack 専用の子サービスを作成するには、Managed Warehouses を使用します。これにより、次のことが可能になります。
  • 既存のアプリケーションから取り込みおよびクエリの負荷を分離する
  • オブザーバビリティ ワークロードを個別にスケールする
  • オブザーバビリティのクエリが本番環境の分析に影響するのを防ぐ
  • 必要に応じて、サービス間で同じ基盤データセットを共有する
このアプローチにより、既存のワークロードへの影響を避けつつ、オブザーバビリティ データの増加に合わせて ClickStack を独立してスケールできます。 大規模なデプロイメントやカスタム サイジングのガイダンスが必要な場合は、より正確な見積もりについてサポートにお問い合わせください。
最終更新日 2026年6月12日