クエリとインジェストの分離ほとんどのセルフマネージド環境のデプロイメントでは、インジェストとクエリは同じノードを共有します。この場合は、Total CPUsをベースラインとして使用してください。インジェスト用とクエリ用のコンピュートを個別にプロビジョニングする分離スケーリングは、ClickHouse Cloud では separate compute pools aka Warehouses を通じてサポートされています。
前提
前提
- ストレージには10倍の圧縮率を想定しています。これは通常、ログとトレースに対しては保守的な見積もりです。
- クエリSLAは、P50が1.5秒、P99が5秒です。
- ほとんどのクエリは直近のデータに対して実行され、約1時間付近でピークを迎え、約6時間まで裾を引く対数正規分布に従うと想定しています。より古いデータをクエリするために、専用のコンピュートをプロビジョニングしたい場合もあります。ClickHouse Cloud では、使用していないときはこれをアイドル状態にできるため、コストは発生しません。
- クエリ用コンピュートはインジェスト用コンピュートとは独立してスケールできますが、本質的にはインジェスト量と結び付いています。インジェストが増えるにつれてデータ密度が高まり、その結果クエリ時のスキャン量が増加し、それに伴ってクエリ用コンピュートの必要量も増えると想定しています。
環境に合わせたサイジング前提の調整
このモデルは、検索、ダッシュボード、アラートを含むすべてのクエリタイプを合算した、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
- 月間の圧縮後容量: 1,500 TB ÷ 10 = 150 TB/月
- 3 か月保持の場合: 150 TB × 3 = 合計 450 TB
オブザーバビリティ ワークロードの分離
リアルタイムのアプリケーション分析など、すでに他のワークロードをサポートしている既存の ClickHouse Cloud サービスに ClickStack を追加する場合は、オブザーバビリティ トラフィックを分離することを強く推奨します。 ClickStack 専用の子サービスを作成するには、Managed Warehouses を使用します。これにより、次のことが可能になります。- 既存のアプリケーションから取り込みおよびクエリの負荷を分離する
- オブザーバビリティ ワークロードを個別にスケールする
- オブザーバビリティのクエリが本番環境の分析に影響するのを防ぐ
- 必要に応じて、サービス間で同じ基盤データセットを共有する