Set up docs MCP以下では、想定されるインジェスト量に基づいて、ClickStackのデプロイメントに必要なコンピュートリソースとストレージリソースを見積もるためのモデルを示します。ここで算出される値はあくまで推定値であり、初期ベースラインとして利用してください。これは一律の答えではありません。実際に必要となるリソースは、クエリの複雑さ、同時実行数、保持ポリシー、インジェストスループットの変動によって異なります。リソース使用量は常に監視し、必要に応じてスケールしてください。
ClickStackをデプロイする際は、インジェストとクエリという2つの独立したワークロードをまかなえるようにコンピュートをプロビジョニングしてください。
| Workload | Estimated resources |
|---|---|
| Ingest | 持続的なインジェストスループット10 MB/sごとに1 vCPU |
| Query | 1 QPSごとに1 vCPU、かつ持続的なインジェストスループット10 MB/sごとに1 vCPU |
前提
- ストレージには10倍の圧縮率を想定しています。これは通常、ログとトレースに対しては保守的な見積もりです。
- クエリSLAは、P50が1.5秒、P99が5秒です。
- ほとんどのクエリは直近のデータに対して実行され、約1時間付近でピークを迎え、約6時間まで裾を引く対数正規分布に従うと想定しています。より古いデータをクエリするために、専用のコンピュートをプロビジョニングしたい場合もあります。ClickHouse Cloud では、使用していないときはこれをアイドル状態にできるため、コストは発生しません。
- クエリ用コンピュートはインジェスト用コンピュートとは独立してスケールできますが、本質的にはインジェスト量と結び付いています。インジェストが増えるにつれてデータ密度が高まり、その結果クエリ時のスキャン量が増加し、それに伴ってクエリ用コンピュートの必要量も増えると想定しています。
以下の表は、1秒あたりメガバイト単位で増加するインジェストスループットに基づくサイジング例と、それに対応する月あたりテラバイト単位のデータ量を示しています。これは、すべてのクエリタイプ (検索、ダッシュボード、アラート) を通じて、ClickStack から平均1 QPSが継続的に発生することを前提としています。
| MB/s | TB/month | Ingest CPUs | Query CPUs | Total CPUs | Total Storage (per month) (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 |
環境に合わせたサイジング前提の調整
このモデルは、検索、ダッシュボード、アラートを含むすべてのクエリタイプを合算した、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
要約
| リソース | 値 |
|---|---|
| 取り込みコンピュート | 58 vCPUs |
| クエリコンピュート | 290 vCPUs |
| 合計コンピュート | 348 vCPUs |
| 月間ストレージ (圧縮後) | 150 TB |
| 3 か月保持のストレージ | 450 TB |
オブザーバビリティ ワークロードの分離
リアルタイムのアプリケーション分析など、すでに他のワークロードをサポートしている既存の ClickHouse Cloud サービスに ClickStack を追加する場合は、オブザーバビリティ トラフィックを分離することを強く推奨します。
ClickStack 専用の子サービスを作成するには、Managed Warehouses を使用します。これにより、次のことが可能になります。
- 既存のアプリケーションから取り込みおよびクエリの負荷を分離する
- オブザーバビリティ ワークロードを個別にスケールする
- オブザーバビリティのクエリが本番環境の分析に影響するのを防ぐ
- 必要に応じて、サービス間で同じ基盤データセットを共有する
このアプローチにより、既存のワークロードへの影響を避けつつ、オブザーバビリティ データの増加に合わせて ClickStack を独立してスケールできます。
大規模なデプロイメントやカスタム サイジングのガイダンスが必要な場合は、より正確な見積もりについてサポートにお問い合わせください。