サイズとハードウェアの推奨事項
このガイドでは、オープンソースユーザー向けのハードウェア、コンピューティング、メモリ、およびディスク構成に関する一般的な推奨事項について説明します。設定を簡素化したい場合は、ClickHouse Cloud の使用をお勧めします。これにより、自動的にスケーリングし、ワークロードに適応しながらインフラ管理に関するコストを最小限に抑えます。
ClickHouse クラスターの構成は、アプリケーションのユースケースやワークロードパターンに大きく依存します。アーキテクチャを計画する際は、以下の要素を考慮する必要があります：
- 同時実行性（リクエスト/秒）
- スループット（処理される行/秒）
- データ量
- データ保持ポリシー
- ハードウェアコスト
- メンテナンスコスト
ディスク
ClickHouse で使用するディスクのタイプは、データ量、レイテンシ、またはスループット要件によって異なります。
パフォーマンス最適化
パフォーマンスを最大化するために、AWS の プロビジョニング IOPS SSD ボリューム への直接接続をお勧めします。これにより、IOが最適化されます。
ストレージコストの最適化
コストを抑えるためには、汎用 SSD EBS ボリューム を使用できます。
また、SSD と HDD を使用した ホット/ウォーム/コールド アーキテクチャ の tiered ストレージを実装することも可能です。あるいは、コンピュートとストレージを分離するために AWS S3 を使用することもできます。オープンソースの ClickHouse を使用してコンピュートとストレージを分離するガイドについては こちら を参照してください。コンピュートとストレージの分離は、ClickHouse Cloud ではデフォルトで利用可能です。
CPU
どの CPU を使用すべきですか？
使用する CPU のタイプは、使用パターンによって異なります。ただし、一般的に、多くの頻繁な同時クエリを処理するアプリケーションや、データ量が多いアプリケーション、または計算集約型の UDF を使用するアプリケーションは、より多くの CPU コアを必要とします。
低レイテンシまたは顧客向けアプリケーション
数十ミリ秒のレイテンシ要件（顧客向けワークロード向け）の場合、AWS の EC2 i3 ライン や i4i ライン またはクラウドプロバイダーの同等のオファリングをお勧めします。これらは IO 最適化されています。
高同時実行アプリケーション
同時実行最適化が必要なワークロード（100 回以上のクエリ/秒）の場合、AWS の コンピュート最適化 C シリーズ またはクラウドプロバイダーの同等のオファリングをお勧めします。
データウェアハウジングユースケース
データウェアハウジングワークロードやアドホック分析クエリの場合、AWS の R 型シリーズ またはクラウドプロバイダーの同等のオファリングをお勧めします。これらはメモリ最適化されています。
CPU 使用率はどのくらいにすべきですか？
ClickHouse に標準の CPU 使用率の目標はありません。平均 CPU 使用率を測定するために iostat などのツールを使用し、予期しないトラフィックの急増に対処できるようサーバーのサイズを調整してください。ただし、アナリティクスやデータウェアハウジングユースケースでアドホッククエリを使用する場合、CPU 使用率 10-20% を目指すべきです。
どのくらいの CPU コアを使用すべきですか？
使用する CPU 数はワークロードによって異なります。しかし、一般的には、CPU タイプに基づいて以下のメモリと CPU コアの比率を推奨します：
- M 種（汎用ユースケース）： メモリと CPU コアの比率 4:1
- R 種（データウェアハウジングユースケース）： メモリと CPU コアの比率 8:1
- C 種（コンピュート最適化ユースケース）： メモリと CPU コアの比率 2:1
例として、M 種の CPU を使用する場合、25 CPU コアあたり 100GB のメモリをプロビジョニングすることをお勧めします。アプリケーションに適したメモリ量を決定するには、メモリ使用量をプロファイリングする必要があります。メモリの問題をデバッグするための このガイド を読むか、ClickHouse を監視するために 組み込みの可視性ダッシュボード を使用してください。
メモリ
CPU の選択と同様に、ストレージ比率と CPU 比率に関するメモリの選択はユースケースに依存します。
必要な RAM のボリュームは通常、以下に依存します：
- クエリの複雑さ。
- クエリで処理されるデータの量。
一般に、メモリが多いほど、クエリの実行速度が速くなります。価格に敏感なユースケースの場合は、メモリ量を少なくすることが可能です。設定（max_bytes_before_external_group_by および max_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 |
| ノードあたりの vCPU | 62 |
| 合計 vCPU | 2700 |
| メモリ | |
| 合計 RAM | 11TB |
| レプリカあたりの RAM | 256GB |
| RAM と vCPU の比率 | 4:1 |
| RAM とディスクの比率 | 1:50 |
Fortune 500 テレコムオペレーターのログユースケース用
| ストレージ | |
| 毎月のログデータ量 | 4860TB |
| 合計ストレージ（圧縮） | 608TB |
| データ保持期間 | 30日 |
| ノードあたりのディスク | 13TB |
| CPU | |
| レプリカ数（HAペアを含む） | 38 |
| ノードあたりの vCPU | 42 |
| 合計 vCPU | 1600 |
| メモリ | |
| 合計 RAM | 10TB |
| レプリカあたりの RAM | 256GB |
| RAM と vCPU の比率 | 6:1 |
| RAM とディスクの比率 | 1:60 |
さらに読む
以下は、オープンソースの ClickHouse を使用している企業のアーキテクチャに関する公開されたブログ記事です：
