13 KiB
| slug | sidebar_label | sidebar_position |
|---|---|---|
| /ja/guides/sizing-and-hardware-recommendations | サイズおよびハードウェアの推奨事項 | 4 |
サイズおよびハードウェアの推奨事項
このガイドでは、オープンソースユーザー向けのハードウェア、コンピュート、メモリ、およびディスク構成に関する一般的な推奨事項について説明します。セットアップを簡略化したい場合は、ClickHouse Cloud の使用をお勧めします。これは、インフラ管理に関連するコストを最小限に抑えつつ、ワークロードに自動的に対応し、スケールします。
ClickHouse クラスターの構成は、お客様のアプリケーションのユースケースやワークロードパターンによって大きく異なります。アーキテクチャを計画する際には、以下の要因を考慮する必要があります。
- 同時実行性（リクエスト数/秒）
- スループット（処理される行数/秒）
- データ量
- データ保持ポリシー
- ハードウェアコスト
- メンテナンスコスト
ディスク
ClickHouse で使用するディスクの種類は、データ量、レイテンシー、スループットの要件によって異なります。
パフォーマンスを最適化する
パフォーマンスを最大化するために、AWS のプロビジョンドIOPS SSDボリューム またはクラウドプロバイダーの同等の提供を直接接続することをお勧めします。これはIOを最適化します。
ストレージコストを最適化する
コストを抑えるために、汎用SSD EBSボリュームを使用できます。また、ホット/ウォーム/コールドアーキテクチャを使用してSSDとHDDを組み合わせた階層型ストレージを実装することもできます。また、ストレージを分離するためにAWS S3を使用することも可能です。コンピュートとストレージの分離でオープンソースのClickHouseを使用するためのガイドはこちらをご覧ください。ClickHouse Cloud ではデフォルトでコンピュートとストレージの分離が利用可能です。
CPU
どの CPU を使用すべきか？
使用する CPU の種類は、使用パターンに依存します。ただし、一般的に、多くの頻繁な同時実行クエリを処理し、より多くのデータを処理する、または計算集約的な UDF を使用するアプリケーションは、より多くの CPU コアを必要とします。
低レイテンシまたは顧客向けアプリケーション
顧客向けワークロードのように10ミリ秒単位の低レイテンシ要件に対しては、AWS の i3 ライン または i4i ライン またはクラウドプロバイダーの同等のIO最適化された提供をお勧めします。
高同時実行性アプリケーション
同時実行性を最適化する必要があるワークロード（1秒あたり100以上のクエリ）に対しては、AWS の計算最適化されたCシリーズ またはクラウドプロバイダーの同等の提供をお勧めします。
データウェアハウジングユースケース
データウェアハウジングワークロードやアドホック分析クエリに対しては、AWS の Rタイプシリーズ 又はクラウドプロバイダーのメモリ最適化された提供をお勧めします。
CPU 利用率はどの程度にすべきか？
ClickHouse に標準的な CPU 利用率の目標はありません。iostat などのツールを利用して平均の CPU 使用率を測定し、予期しないトラフィックの急増を管理できるようにサーバーのサイズを調整します。ただし、アドホッククエリを伴う分析またはデータウェアハウジングユースケースの場合、10-20% の CPU 利用率を目標とすべきです。
何 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つのレプリカを持つことを推奨します（または 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 を使用する企業のアーキテクチャに関するブログ記事です。