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

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

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

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

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

ディスク​

ClickHouseで使用するディスクの種類は、データ量、レイテンシ、またはスループットの要件に依存します。

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

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

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

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

SDDとHDDを使用したホット/ウォーム/コールドアーキテクチャを利用した段階的ストレージを実装することもできます。あるいは、AWS S3をストレージとして使用し、計算とストレージを分離することも可能です。計算とストレージの分離に関するガイドはこちらをご覧ください。計算とストレージの分離は、ClickHouse Cloudでデフォルトで利用可能です。

CPU​

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

使用するCPUの種類は、使用パターンに依存します。ただし、一般に、同時実行クエリが多く、より多くのデータを処理するアプリケーションや、計算集約型のユーザー定義関数（UDF）を使用する場合は、より多くのCPUコアが必要になります。

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

顧客向けワークロードのために、レイテンシ要件が数ミリ秒の場合は、AWSのEC2 i3ライントまたはi4iライントを推奨します。または、クラウドプロバイダーの同等の提供物を選択してください。

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

同時実行性を最適化する必要があるワークロード（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を使用する場合、25CPUコアごとに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の構成は、特定のアプリケーションの要件によって大きく異なります。コストとパフォーマンスの最適化についてのサポートが必要な場合は、Salesに問い合わせてください。

ガイダンスを提供するために（推奨事項ではありません）、以下はプロダクションでのClickHouseユーザーの例示的な構成です。

Fortune 500 B2B SaaS​

ストレージ
月間新データ量30TB
合計ストレージ（圧縮後）540TB
データ保持18ヶ月
ノードごとのディスク25TB
CPU
同時実行性200+同時クエリ
レプリカの数（HAペアを含む）44
ノードごとのvCPU62
合計vCPU2700
メモリ
合計RAM11TB
レプリカごとのRAM256GB
RAMとvCPUの比率4:1
RAMとディスクの比率1:50

Fortune 500 Telecom Operatorのログユースケース​

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

さらなる読書​

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