サイジングとハードウェアの推奨事項

このガイドでは、オープンソースユーザー向けに、ハードウェア、コンピュート、メモリ、ディスクの構成に関する一般的な推奨事項を説明します。セットアップを簡素化したい場合は、ClickHouse Cloud の利用をお勧めします。ClickHouse Cloud は自動的にスケールし、ワークロードに適応しながら、インフラストラクチャ管理にかかるコストを最小限に抑えます。

ClickHouse クラスターの構成は、アプリケーションのユースケースやワークロードパターンに大きく左右されます。アーキテクチャを計画する際は、次の要素を考慮する必要があります。

• 同時実行数 (1 秒あたりのリクエスト数)
• スループット (1 秒あたりに処理される行数)
• データ量
• データ保持ポリシー
• ハードウェアコスト
• 保守コスト

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

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

コストを抑えるには、汎用 SSD EBS ボリュームを使用できます。

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

使用する CPU の種類は、利用パターンによって異なります。ただし一般的には、高頻度で同時実行されるクエリが多いアプリケーション、より多くのデータを処理するアプリケーション、またはコンピュート負荷の高い UDFs を使用するアプリケーションでは、より多くの CPU コアが必要になります。

低レイテンシまたは顧客向けアプリケーション

顧客向けワークロードのように、数十ミリ秒レベルのレイテンシ要件がある場合は、I/O に最適化された AWS の EC2 i3 ファミリー または i4i ファミリー、もしくはクラウドプロバイダーが提供する同等のインスタンスを推奨します。

高同時実行数アプリケーション

同時実行数 (毎秒 100 件超のクエリ) を重視するワークロードには、AWS の コンピュート最適化 C シリーズ またはクラウドプロバイダーが提供する同等のインスタンスを推奨します。

データウェアハウジングのユースケース

データウェアハウジングのワークロードやアドホックな分析クエリには、メモリ最適化されている AWS の R タイプシリーズ またはクラウドプロバイダーが提供する同等のインスタンスを推奨します。

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

必要な 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_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 を利用しているユーザーの構成例を示します。

以下は、オープンソース版 ClickHouseを利用している企業のアーキテクチャに関する公開ブログ記事です。

• Cloudflare
• eBay
• GitLab
• Lyft
• MessageBird
• Microsoft
• Uber
• Zomato