コンピュート分離とは？
コンピュート分離について説明する前に、ClickHouse Cloud におけるサービスとは何かを理解しておくとわかりやすいでしょう。 各 ClickHouse Cloud サービスには、次のものが含まれます。- 専用の CPU とメモリ クラスターを備えた ClickHouse のコンピュートノード (レプリカと呼ばれます)
- サービスに接続するためのエンドポイント (または ClickHouse Cloud の UI コンソールから作成された複数のエンドポイント) 。ローカル接続やサードパーティアプリからの接続に使用します (例:
https://dv2fzne24g.us-east-1.aws.clickhouse.cloud:8443) - サービスがすべてのデータとメタデータの一部を保存するオブジェクトストレージ フォルダー:
図 1 - ClickHouse Cloud 内の単一サービス 単一のサービスだけでなく、同じ共有ストレージにアクセスできる複数のサービスを作成することもできます。これにより、データを複製することなく、特定のワークロードに専用のリソースを割り当てられます。 この考え方をコンピュート分離と呼びます。 コンピュート分離では、各サービスがそれぞれ独自のレプリカ群とエンドポイントを持ちながら、同じオブジェクトストレージ フォルダーを使用し、同じテーブルやビューなどにアクセスします。 つまり、ワークロードに適したサイズのコンピュートを選択できます。小規模なレプリカ 1 つで十分なワークロードもあれば、完全な高可用性 (HA) と、複数のレプリカにまたがる数百 GB のメモリを必要とするワークロードもあります。 また、コンピュート分離を使うことで、読み取り処理と書き込み処理を分離し、相互に干渉しないようにすることもできます。
図 2 - ClickHouse Cloud におけるコンピュート分離
ウェアハウス とは何ですか？
- プライマリ サービス
DWH Prod - セカンダリ サービス
DWH Prod Subservice
図 3 - ウェアハウス の例 ウェアハウス 内のすべてのサービスは、以下を共有します。
- Region (例: us-east1)
- クラウドサービスプロバイダー (AWS、GCP、または Azure)
- ClickHouse データベースのバージョン
- ClickHouse Keeper (レプリカの管理用)
アクセス制御
データベース認証情報
ウェアハウス内のすべてのサービスは同じテーブル群を共有するため、サービス間でアクセス制御も共有されます。 つまり、Service 1 で作成されたすべてのデータベースユーザーは、同じ権限 (テーブルやビューなどに対する grants) で Service 2 も利用でき、その逆も同様です。 各サービスで使用するエンドポイントは異なりますが、ユーザー名とパスワードはすべてのサービスで共通です。つまり、以下の図に示すように、同じストレージを使用するサービス間ではユーザーが共有されます。図 4 - ユーザー Alice は Service 1 で作成されましたが、同じ認証情報を使って、同じデータを共有するすべてのサービスにアクセスできます
ネットワークアクセス制御
他のアプリケーションや一時的なユーザーによる特定のサービスへのアクセスを制限するには、ネットワーク制限を適用できます。 そのためには、ClickHouse Cloudコンソールで、アクセスを制限したいサービスのタブにあるSettingsに移動します。 IP フィルタリング設定はサービスごとに個別に適用できるため、どのアプリケーションがどのサービスにアクセスできるかを制御できます。 これにより、特定のサービスへのアクセスを制限できます。 以下の例では、Alice は ウェアハウス 内のサービス 2 へのアクセスを制限されています。図 5 - Alice は、ネットワークアクセス制御の設定によりサービス 2 へのアクセスを制限されています また、default ユーザーではなく個別のユーザーとして接続する場合は、ClickHouse のロールと grants を適用してデータへのアクセスを制御することもできます。
読み取り専用サービスと読み書きサービス
- 読み書き
- ClickHouse に対してデータの読み取りと書き込みの両方が可能
- バックグラウンドマージ処理 (例: データ挿入後のパーツのマージ) を実行するため、CPU とメモリを消費する
- データを外部にエクスポートできる
- 読み取り専用
- データの読み取りのみ可能で、ClickHouse 内のデータの書き込みや変更はできない
- システムテーブルを除きバックグラウンドマージ処理を実行しないため、リソースを読み取りクエリに全面的に使える
- 外部へのデータエクスポート (例: テーブル関数経由) は引き続き可能だが、ClickHouse 内のデータは変更できない
- バックグラウンドマージによって稼働状態が維持されることがある読み書きサービスとは異なり、すぐにアイドル状態になる
図 6 - ウェアハウス内の読み書きサービスと読み取り専用サービス
- 読み取り専用サービスは現在、ユーザー管理操作 (CREATE、DROP など) をサポートしています。
- リフレッシュ可能なマテリアライズドビュー は、ウェアハウス内の読み書き (RW) サービスでのみ実行されます。
- サービスのタイプ (読み取り専用 または 読み書き) は作成時に固定され、その後 Cloud Console から変更することはできません。読み取り専用 と 読み書き を切り替えるには、ウェアハウス内に希望するタイプの新しいサービスを作成してください。
スケーリング
ウェアハウス内の各サービスは、独立してスケーリングされます。レプリカの数とサイズの調整、水平および垂直オートスケーリングの有効化、非アクティブ時の自動アイドル化の設定を行えます。 プライマリサービスを含む各サービスは単一レプリカで実行できますが、production 環境には推奨されません。高可用性を確保するため、少なくとも 2 つのレプリカを使用してください。Scale tier および Enterprise tier では、サポートへの問い合わせなしで、単一レプリカのプライマリサービスとセカンダリサービスを利用できます。標準の1:4 プロファイルを使用する Scale サービスおよび Enterprise サービスは、セルフサービスによる垂直オートスケーリングをサポートしています。一方、カスタムプロファイルを使用する Enterprise サービスでは、サポートによる垂直リサイズが必要です。Basic tier のサービスはサイズが固定されています。詳細については、Large single-replica services を参照してください。
ウェアハウス内のすべてのサービスのレプリカ数の合計は、デフォルトで 50 に制限されています。詳細については、使用量制限 を参照してください。上限を引き上げるには、サポート にお問い合わせください。
スケジュールスケーリング は、ウェアハウス内の個々のサービスに使用できます。ただし、ウェアハウスの上限は引き続き適用されます。ピーク時にすべてのサービスのレプリカ数の合計がウェアハウスの上限内に収まるよう、スケジュールを計画してください。詳細については、Automatic scaling を参照してください。
clusterAllReplicas の動作の変更
1 つの ウェアハウス に複数の サービス があると、clusterAllReplicas() の動作が変わります。
default クラスター名を使用した場合、対象になるのは ウェアハウス 内のすべての サービス ではなく、現在の サービス に属するレプリカのみです。
たとえば、サービス 1 から clusterAllReplicas(default, system, processes) を呼び出すと、返されるのは サービス 1 上で実行中のプロセスだけです。
ウェアハウス 内のすべての サービス をまたいでクエリを実行するには、代わりに all_groups.default クラスター名を使用してください。
制限事項
ワークロード分離の制限事項
一部のワークロードは特定のサービスに分離できません。つまり、あるサービス上のワークロードが、同じウェアハウス内の別のサービスに影響するケースがあります。具体的には、次のようなものがあります。-
すべての読み書きサービスは、デフォルトでバックグラウンドマージ処理を実行します。 ClickHouse にデータを挿入すると、データベースはまずデータを一時的なパーティションに書き込み、その後バックグラウンドでマージを実行します。これらのマージは、メモリや CPU リソースを消費することがあります。2 つの読み書きサービスが同じストレージを共有している場合、両方のサービスでバックグラウンド処理が実行されます。つまり、Service 1 で
INSERTクエリが実行されても、そのマージ処理自体は Service 2 で完了することがあります。 読み取り専用サービスはバックグラウンドマージを実行しません。読み書きサービス上のマージを無効にするには、サポートにお問い合わせください。 - すべての読み書きサービスで S3Queue テーブルエンジンの insert 操作が実行されます。 読み書きサービス上に S3Queue テーブルを作成すると、そのウェアハウス内の他のすべての読み書きサービスでも、S3 からのデータの読み取りとデータベースへの書き込みが実行される場合があります。
- idling が有効な場合、ある読み書きサービスでの inserts によって、別の読み書きサービスがアイドル状態に移行できなくなることがあります。 あるサービスが、別のサービスのためにバックグラウンドマージ処理を実行する場合があります。こうしたバックグラウンド処理によって、後者のサービスがアイドル状態に移行できなくなることがあります。バックグラウンド処理が完了すると、そのサービスはアイドル状態になります。読み取り専用サービスは影響を受けません。
参考情報
- ClickHouse のバージョン: アップグレードスケジュールは、プライマリサービスの設定によって決まります。セカンダリサービスに、プライマリサービスとは独立したリリーススケジュールを設定することはできません。
-
CREATE/RENAME/DROP DATABASEクエリは、デフォルトでアイドル化または停止中のサービスによってブロックされることがあります。 サービスがアイドル化または停止中のときにこれらのクエリを実行すると、処理がハングする場合があります。これを回避するには、セッション単位またはクエリ単位でsettings distributed_ddl_task_timeout=0を指定して、データベース管理クエリを実行できます。
- プライマリサービスのアイドル化: プライマリサービスの自動アイドル化はデフォルトで有効になっています。
料金
バックアップ
- 1 つの ウェアハウス 内のすべての サービス は同じストレージを共有するため、バックアップはプライマリ (初期) サービス でのみ作成されます。これにより、ウェアハウス 内のすべての サービス のデータがバックアップされます。
- ウェアハウス のプライマリ サービス からバックアップを復元すると、既存の ウェアハウス には接続されていない、まったく新しい サービス として復元されます。復元が完了したらすぐに、その新しい サービス にさらに サービス を追加できます。
ウェアハウス の設定方法
ウェアハウスの作成
図 7 - プラス記号をクリックして、ウェアハウス内に新しいサービスを作成します サービス作成画面では、新しいサービスのデータ元として、元のサービスがドロップダウンで選択された状態になります。作成後、これら 2 つのサービスで 1 つのウェアハウスが構成されます。
ウェアハウス名の変更
- services ページの右上にある「Sort by warehouse」を選択し、ウェアハウス名の横にある鉛筆アイコンをクリックします
- いずれかのサービスでウェアハウス名をクリックし、そこで名前を変更できます
ウェアハウスの削除
- 最初に作成したサービス以外の、すべてのサービスを削除します。
- 最初のサービスを削除します (警告: この手順ですべてのウェアハウスデータが削除されます) 。