> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-fix-nav-issues.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# リソースの見積もり

> Managed ClickStack デプロイメント向けのリソース見積もりガイド

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

<Warning>
  **すべての数値は非圧縮の生インジェストに基づいています**

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

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

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

| Workload   | Estimated resources                               |
| ---------- | ------------------------------------------------- |
| **Ingest** | 持続的なインジェストスループット10 MB/sごとに1 vCPU                  |
| **Query**  | 1 QPSごとに1 vCPU、かつ持続的なインジェストスループット10 MB/sごとに1 vCPU |

<Info>
  **クエリとインジェストの分離**

  ほとんどのセルフマネージド環境のデプロイメントでは、インジェストとクエリは同じノードを共有します。この場合は、**Total CPUs**をベースラインとして使用してください。インジェスト用とクエリ用のコンピュートを個別にプロビジョニングする分離スケーリングは、ClickHouse Cloud では [separate compute pools aka Warehouses](/ja/products/cloud/features/infrastructure/warehouses) を通じてサポートされています。
</Info>

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

以下の表は、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 |

<div id="refining-sizing-assumptions">
  ## 環境に合わせたサイジング前提の調整
</div>

このモデルは、検索、ダッシュボード、アラートを含むすべてのクエリタイプを合算した、ClickStack からの継続的な平均 1 QPS を前提としています。

クエリ量がこれを上回る場合は、必要な CPU を目標 QPS に応じて線形にスケールさせます。たとえば、100 MB/s で取り込むデプロイメントで目標が 9 QPS の場合、クエリ用に必要な CPU はベースラインの 10 ではなく 90 (10 × 9) となり、合計は 100 CPU (取り込み 10 + クエリ 90) になります。

ストレージの見積もりは、保守的に圧縮率 10 倍を前提としています。実際には、ログ、トレース、メトリクスはこれより高い圧縮率になることがよくあります。本番環境に入る前に圧縮率とストレージ要件を把握できるよう、データのサンプルで事前にテストすることを推奨します。保持期間を長くする場合に必要なストレージは、1 か月あたりのストレージ量に保持する月数を掛けて計算してください。

これは、クエリ分布が比較的均等であることを前提としています。より負荷の高い過去データ参照やアーカイブクエリに偏ったワークロードでは、必要なコンピュートが大きく異なる可能性があるため、負荷テストで検証する必要があります。今後は、クエリ分布パターンの違いに応じてクエリ用コンピュートを外挿できる、より柔軟なサイジングモデルを導入する予定です。

<div id="worked-example">
  ### 計算例
</div>

**要件:** 月間 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    |

<div id="isolating-workloads">
  ## オブザーバビリティ ワークロードの分離
</div>

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

ClickStack 専用の**子サービス**を作成するには、[**Managed Warehouses**](/ja/products/cloud/features/infrastructure/warehouses) を使用します。これにより、次のことが可能になります。

* 既存のアプリケーションから取り込みおよびクエリの負荷を分離する
* オブザーバビリティ ワークロードを個別にスケールする
* オブザーバビリティのクエリが本番環境の分析に影響するのを防ぐ
* 必要に応じて、サービス間で同じ基盤データセットを共有する

このアプローチにより、既存のワークロードへの影響を避けつつ、オブザーバビリティ データの増加に合わせて ClickStack を独立してスケールできます。

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