メインコンテンツまでスキップ
メインコンテンツまでスキップ

サイズとハードウェアの推奨事項

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

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

  • 同時処理数（リクエスト数/秒）
  • スループット（処理される行数/秒）
  • データ量
  • データ保持ポリシー
  • ハードウェアコスト
  • メンテナンスコスト

ディスク​

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

パフォーマンスの最適化​

パフォーマンスを最大化するために、AWSの プロビジョニングIOPS SSDボリューム もしくはクラウドプロバイダーからの同等のオファリングを直接接続することをお勧めします。これによりIOが最適化されます。

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

コストを抑えるためには、一般目的SSD EBSボリューム を使用することができます。

また、SSDとHDDを使用したホット/ウォーム/コールドアーキテクチャを実装することも可能です。別の選択肢として、計算とストレージを分離するために AWS S3 を使用することも可能です。計算とストレージの分離は、ClickHouse Cloudではデフォルトで利用可能です。

CPU​

どのCPUを使用すべきか？​

使用すべきCPUの種類は、利用パターンに依存します。ただし、一般的には、多くの頻繁な同時クエリを処理するアプリケーションや、より多くのデータを処理するアプリケーション、計算集約的なUDFを使用するアプリケーションは、より多くのCPUコアを必要とするでしょう。

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

ミリ秒単位の低レイテンシーが要求される顧客向けワークロードには、AWSのEC2 i3ライン または i4iライン もしくはクラウドプロバイダーからの同等のオファリングをお勧めします。これらはIO最適化されています。

高同時処理アプリケーション

同時処理を最適化する必要があるワークロード（100以上のクエリ/秒）には、AWSのコンピュート最適化Cシリーズ もしくはクラウドプロバイダーからの同等のオファリングをお勧めします。

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

データウェアハウジングのワークロードやアドホック解析クエリには、AWSのRタイプシリーズ もしくはクラウドプロバイダーからの同等のオファリングをお勧めします。これらはメモリ最適化されています。

CPU使用率はどのくらいが良いか？​

ClickHouseにおける標準のCPU使用率目標はありません。iostatなどのツールを利用して平均CPU使用率を測定し、予期しないトラフィックの急増に対応できるようサーバーのサイズを調整してください。ただし、アナリティクスやデータウェアハウジングのユースケースにおいてアドホッククエリを実行する場合、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の比率は、ユースケースに依存します。ただし、一般的には、メモリが多いほどクエリが速く実行されます。コストに敏感なユースケースの場合、メモリ量を低く設定することが可能ですが、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つのレプリカ（またはAWS EBSを使用する場合は2つのレプリカ）を持つことをお勧めします。さらに、追加のレプリカを追加する前にすべてのレプリカを垂直にスケールすることを推奨します（水平スケーリング）。

ClickHouseは自動的にシャーディングせず、データセットの再シャーディングには相当な計算リソースが必要です。したがって、将来データを再シャーディングする必要がないように、一般的には利用可能な最大のサーバーを使用することをお勧めします。

自動的にスケールし、ユースケースに合わせてレプリカ数を簡単に制御できるClickHouse Cloudの利用を検討してください。

大規模ワークロードの例設定​

ClickHouseの設定は、特定のアプリケーションの要件に大きく依存します。コストとパフォーマンスの最適化についてのサポートが必要な場合は、営業に連絡してください。

指針を提供するために（推奨ではなく）、以下は生産環境でのClickHouseユーザーの例設定です：

フォーチュン500 B2B SaaS​

ストレージ
月間新データ量30TB
総ストレージ（圧縮済み）540TB
データ保持18か月
ノードあたりのディスク25TB
CPU
同時処理数200+ 同時クエリ
レプリカ数（HAペアを含む）44
ノードあたりのvCPU62
総vCPU2700
メモリ
総RAM11TB
レプリカあたりのRAM256GB
RAM対vCPU比率4:1
RAM対ディスク比率1:50

フォーチュン500 テレコムオペレーターのログ使用ケース​

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

さらなる読み物​

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