リソースの見積もり
以下では、想定されるインジェスト量に基づき、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 |
お使いの環境に合わせてサイジングの前提を調整する
このモデルは、検索、ダッシュボード、アラートを含むすべてのクエリ種別を合算したうえで、ClickStack から平均 1 QPS のクエリが継続的に発生することを前提としています。
クエリ量がこれより多い場合は、目標 QPS を CPU 要件に掛けて、必要な CPU を比例的に増やしてください。たとえば、100 MB/s で取り込みを行うデプロイメントで目標が 9 QPS の場合、必要なクエリ用 CPU はベースラインの 10 ではなく 90 (10 × 9) となり、合計 CPU 数は 100 (取り込み 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 か月あたりの秒数 (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 vCPU
クエリ用コンピュート
クエリ用コンピュートは、取り込み処理量と QPS の両方に応じて増加します。5 QPS の場合:
(579 ÷ 10) × 5 = 58 × 5 = クエリに 290 vCPU
ストレージ
30 日間にわたり 579 MB/s を維持すると、生の取り込み量は月間 1,500 TB になります。想定する 10 倍の圧縮率を適用すると:
- 月あたりの圧縮後容量: 1,500 TB ÷ 10 = 150 TB/月
- 3 か月保持の場合: 150 TB × 3 = 合計 450 TB
まとめ
| リソース | 値 |
|---|---|
| 取り込み用コンピュート | 58 vCPU |
| クエリ用コンピュート | 290 vCPU |
| 合計コンピュート | 348 vCPU |
| 月あたりのストレージ (圧縮後) | 150 TB |
| 3 か月保持のストレージ | 450 TB |
オブザーバビリティワークロードの分離
すでにリアルタイムのアプリケーション分析など、他のワークロードをサポートしている既存の ClickHouse Cloud サービスに ClickStack を追加する場合は、オブザーバビリティのトラフィックを分離することを強く推奨します。
Managed Warehouses を使用して、ClickStack 専用の子サービスを作成します。これにより、次のことが可能になります。
- 既存のアプリケーションから、取り込みとクエリの負荷を分離する
- オブザーバビリティワークロードを個別にスケールする
- オブザーバビリティのクエリが本番環境の分析に影響するのを防ぐ
- 必要に応じて、サービス間で同じ基盤データセットを共有する
この方法により、オブザーバビリティデータの増加に応じて ClickStack を個別にスケールできる一方で、既存のワークロードへの影響を避けられます。
より大規模なデプロイメントやカスタムのサイジングに関するガイダンスが必要な場合は、より正確な見積もりについてサポートまでお問い合わせください。
