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

# ClickHouse Cloud アーキテクチャ

![ClickHouse Cloud architecture](@site/docs/ja/cloud/reference/images/architecture.svg)

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

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

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

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

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

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

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

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

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

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

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

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

## 同時実行制限

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

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