メインコンテンツへスキップ
このガイドでは、オープンソースユーザー向けに、ハードウェア、コンピュート、メモリ、ディスクの構成に関する一般的な推奨事項を説明します。セットアップを簡素化したい場合は、ClickHouse Cloud の利用をお勧めします。ClickHouse Cloud は自動的にスケールし、ワークロードに適応しながら、インフラストラクチャ管理にかかるコストを最小限に抑えます。 ClickHouse クラスターの構成は、アプリケーションのユースケースやワークロードパターンに大きく左右されます。アーキテクチャを計画する際は、次の要素を考慮する必要があります。
  • 同時実行数 (1 秒あたりのリクエスト数)
  • スループット (1 秒あたりに処理される行数)
  • データ量
  • データ保持ポリシー
  • ハードウェアコスト
  • 保守コスト

ディスク

ClickHouse で使用するディスクの種類は、データ量、レイテンシ、スループットの要件によって異なります。

パフォーマンスの最適化

パフォーマンスを最大限に引き出すには、I/O に最適化された AWS のプロビジョンド IOPS SSD ボリューム またはご利用のクラウドプロバイダーが提供する同等のボリュームを直接アタッチすることを推奨します。

ストレージコストの最適化

コストを抑えるには、汎用 SSD EBS ボリュームを使用できます。 また、ホット/ウォーム/コールド アーキテクチャにおいて、SSD と HDD を組み合わせた階層型ストレージを実装することもできます。あるいは、コンピュートとストレージを分離するために、ストレージとして AWS S3 を利用することも可能です。コンピュートとストレージを分離したオープンソース版 ClickHouse の利用方法については、こちらのガイドをご覧ください。コンピュートとストレージの分離は、ClickHouse Cloud では標準で利用できます。

CPU

どの CPU を使用すべきですか?

使用する CPU の種類は、利用パターンによって異なります。ただし一般的には、高頻度で同時実行されるクエリが多いアプリケーション、より多くのデータを処理するアプリケーション、またはコンピュート負荷の高い UDFs を使用するアプリケーションでは、より多くの CPU コアが必要になります。 低レイテンシまたは顧客向けアプリケーション 顧客向けワークロードのように、数十ミリ秒レベルのレイテンシ要件がある場合は、I/O に最適化された AWS の EC2 i3 ファミリー または i4i ファミリー、もしくはクラウドプロバイダーが提供する同等のインスタンスを推奨します。 高同時実行数アプリケーション 同時実行数 (毎秒 100 件超のクエリ) を重視するワークロードには、AWS の コンピュート最適化 C シリーズ またはクラウドプロバイダーが提供する同等のインスタンスを推奨します。 データウェアハウジングのユースケース データウェアハウジングのワークロードやアドホックな分析クエリには、メモリ最適化されている AWS の R タイプシリーズ またはクラウドプロバイダーが提供する同等のインスタンスを推奨します。

CPU 使用率はどの程度を目安にすべきですか?

ClickHouse には、標準的な CPU 使用率の目標値はありません。iostat などのツールで平均 CPU 使用率を測定し、想定外のトラフィックスパイクに対応できるよう、それに応じてサーバーのサイズを調整してください。ただし、アドホッククエリを伴う分析用途やデータウェアハウジングのユースケースでは、CPU 使用率は 10~20% を目安にしてください。

使用すべき CPU コア数はどれくらいですか?

必要な CPU コア数は、ワークロードによって異なります。ただし、一般的には CPU タイプに応じて、以下のメモリ対 CPU コア比を推奨しています。
  • M-type (汎用的なユースケース) : メモリ対 CPU コア比 4 GB:1
  • R-type (データウェアハウジングのユースケース) : メモリ対 CPU コア比 8 GB:1
  • C-type (コンピュート最適化のユースケース) : メモリ対 CPU コア比 2 GB:1
たとえば、M-type CPU を使用する場合は、CPU コア 25 個あたり 100GB のメモリをプロビジョニングすることを推奨します。アプリケーションに適したメモリ量を判断するには、メモリ使用量のプロファイリングが必要です。メモリ問題のデバッグに関するこのガイドを参照するか、組み込みのオブザーバビリティダッシュボードを使用して ClickHouse を監視できます。

メモリ

CPU の選択と同様に、メモリ対ストレージ比率およびメモリ対 CPU 比は、ユースケースによって異なります。 一般に、必要な RAM 容量は次の要因に左右されます。
  • クエリの複雑さ
  • クエリで処理されるデータ量
ただし、一般的にはメモリが多いほどクエリは高速に実行されます。 コストを重視するユースケースでは、データをディスクに書き出せるようにする設定 (max_bytes_before_external_group_bymax_bytes_before_external_sort) を有効にすることで、少ないメモリ量でも運用できますが、クエリパフォーマンスに大きな影響を与える可能性がある点に注意してください。

メモリ対ストレージ比率はどの程度にすべきですか?

データ量が少ない場合は、メモリ対ストレージ比率が 1:1 でも問題ありませんが、総メモリ量は 8GB を下回らないようにしてください。 データ保持期間が長いユースケースやデータ量が多いユースケースでは、メモリ対ストレージ比率は 1:100 ~ 1:130 を推奨します。たとえば、10TB のデータを保存する場合は、レプリカごとに 100GB の RAM を確保することを推奨します。 顧客向けワークロードのようにアクセス頻度が高いユースケースでは、メモリ対ストレージ比率を 1:30 ~ 1:50 とし、より多くのメモリを使用することを推奨します。

レプリカ

各分片につき、少なくとも 3 つのレプリカ (Amazon EBS を使用する場合は 2 つのレプリカ) を確保することを推奨します。また、レプリカを追加して水平スケーリングを行う前に、まずはすべてのレプリカを垂直方向にスケールアップすることを推奨します。 ClickHouse は自動では分片化されず、データセットの再分片化には大量のコンピュートリソースが必要です。そのため、将来的にデータの再分片化が必要にならないよう、一般には利用可能な中で最大のサーバーを使用することを推奨します。 自動的にスケールし、ユースケースに応じてレプリカ数を簡単に制御できる ClickHouse Cloud の利用もご検討ください。

大規模ワークロード向けの構成例

ClickHouse の構成は、個々のアプリケーションの要件に大きく左右されます。コストとパフォーマンスの両面でアーキテクチャの最適化について支援をご希望の場合は、営業担当までお問い合わせください あくまで参考情報であり推奨構成ではありませんが、以下に本番環境で ClickHouse を利用しているユーザーの構成例を示します。

Fortune 500 B2B SaaS

ストレージ
月間新規データ量30TB
総ストレージ容量 (圧縮後) 540TB
データ保持期間18か月
ノードあたりのディスク容量25TB
CPU
同時実行数200件超の同時実行クエリ
レプリカ数 (HAペアを含む) 44
ノードあたりのvCPU62
合計 vCPU2700
メモリ
合計RAM11TB
レプリカあたりのRAM256GB
RAM 対 vCPU 比率4 GB:1
RAM 対ディスク比率1:50

ログ用途における Fortune 500 の通信事業者

ストレージ
月間ログデータ量4860TB
合計ストレージ容量 (圧縮後) 608TB
データ保持期間30日
ノードあたりのディスク容量13TB
CPU
レプリカ数 (HA ペアを含む) 38
ノードあたりの vCPU42
合計 vCPU1600
メモリ
合計 RAM10TB
レプリカあたりの RAM256GB
RAM 対 vCPU 比率6 GB:1
RAM 対ディスク比率1:60

参考資料

以下は、オープンソースのClickHouseを利用している企業のアーキテクチャに関する公開ブログ記事です。
最終更新日 2026年6月12日