ClickHouse/docs/ja/cloud/reference/architecture.md

sidebar_label	slug
アーキテクチャ	/ja/cloud/reference/architecture

ClickHouse Cloud アーキテクチャ

オブジェクトストアに支えられたストレージ

• 事実上無制限のストレージ
• データを手動で共有する必要なし
• 特にあまり頻繁にアクセスされないデータを保存する際のコストが大幅に低減

コンピュート

• 自動スケーリングとアイドリング：事前にサイズを決定する必要がなく、ピーク使用に合わせて過剰プロビジョンする必要もなし
• 自動アイドリングと再開：誰も使っていないときに未使用のコンピュートを走らせる必要がない
• デフォルトで安全で高可用性

管理

• セットアップ、監視、バックアップ、および請求は自動的に行われます。
• コストコントロールはデフォルトで有効であり、Cloud コンソールを通じて調整できます。

サービスのアイソレーション

ネットワークのアイソレーション

すべてのサービスはネットワーク層でアイソレーションされています。

コンピュートのアイソレーション

Production および Development サービスは、それぞれの Kubernetes スペース内で別々のポッドにデプロイされ、ネットワークレベルでアイソレーションされています。Dedicated サービスは専用の VM 上で自身の Kubernetes オペレーターと共に実行されます。

ストレージのアイソレーション

すべてのサービスは、共有バケット(AWS, GCP)またはストレージコンテナ(Azure)の別々のサブパスを使用します。

AWS では、ストレージへのアクセスは AWS IAM を介して制御され、各 IAM ロールはサービスごとにユニークです。Production および Dedicated サービスについては、CMEKが有効化されて使用停止時の高度なデータアイソレーションを提供します。CMEK は現在、AWS サービスのみでサポートされています。

GCP および Azure では、サービスはオブジェクトストレージのアイソレーションが確保されており（すべてのサービスが自身のバケットまたはストレージコンテナを持っています）。

同時実行制限

ClickHouse Cloud サービスでは、秒あたりのクエリ数 (QPS) に制限はありません。ただし、1 レプリカあたり1000 の同時クエリ制限があります。QPS は最終的に、平均クエリ実行時間とサービス内のレプリカ数による関数となります。

セルフマネージドの ClickHouse インスタンスや他のデータベース/データウェアハウスと比較した ClickHouse Cloud の主な利点は、レプリカを追加する（水平スケーリング）ことで簡単に同時実行数を増やせることです。