ウェアハウス

コンピュート分離について説明する前に、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 におけるコンピュート分離

ClickHouse Cloud では、ウェアハウス とは同じデータを共有するサービスの集合です。 各 ウェアハウス には、プライマリ サービス (最初に作成されるサービス) と、1 つ以上のセカンダリ サービスがあります。 たとえば、以下のスクリーンショットでは、2 つのサービスで構成される ウェアハウス「DWH Prod」を確認できます。

• プライマリ サービス 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 内のデータは変更できない
  • バックグラウンドマージによって稼働状態が維持されることがある読み書きサービスとは異なり、すぐにアイドル状態になる

重要な読み取りワークロードを、書き込みやマージのオーバーヘッドから切り離すために、サービスを読み取り専用にしたい場合があります。 これは 2 つ目のサービスと、それ以降に作成する追加サービスで設定できます。ただし、最初のサービスは常に読み書きサービスです。以下の図を参照してください。

図 6 - ウェアハウス内の読み書きサービスと読み取り専用サービス

ウェアハウス内の各サービスは、独立してスケーリングされます。レプリカの数とサイズの調整、水平および垂直オートスケーリングの有効化、非アクティブ時の自動アイドル化の設定を行えます。

プライマリサービスを含む各サービスは単一レプリカで実行できますが、production 環境には推奨されません。高可用性を確保するため、少なくとも 2 つのレプリカを使用してください。Scale tier および Enterprise tier では、サポートへの問い合わせなしで、単一レプリカのプライマリサービスとセカンダリサービスを利用できます。標準の 1:4 プロファイルを使用する Scale サービスおよび Enterprise サービスは、セルフサービスによる垂直オートスケーリングをサポートしています。一方、カスタムプロファイルを使用する Enterprise サービスでは、サポートによる垂直リサイズが必要です。Basic tier のサービスはサイズが固定されています。詳細については、Large single-replica services を参照してください。

ウェアハウス内のすべてのサービスのレプリカ数の合計は、デフォルトで 50 に制限されています。詳細については、使用量制限 を参照してください。上限を引き上げるには、サポート にお問い合わせください。

スケジュールスケーリング は、ウェアハウス内の個々のサービスに使用できます。ただし、ウェアハウスの上限は引き続き適用されます。ピーク時にすべてのサービスのレプリカ数の合計がウェアハウスの上限内に収まるよう、スケジュールを計画してください。詳細については、Automatic scaling を参照してください。

1 つの ウェアハウス に複数の サービス があると、clusterAllReplicas() の動作が変わります。 default クラスター名を使用した場合、対象になるのは ウェアハウス 内のすべての サービス ではなく、現在の サービス に属するレプリカのみです。

たとえば、サービス 1 から clusterAllReplicas(default, system, processes) を呼び出すと、返されるのは サービス 1 上で実行中のプロセスだけです。 ウェアハウス 内のすべての サービス をまたいでクエリを実行するには、代わりに all_groups.default クラスター名を使用してください。

SELECT * FROM clusterAllReplicas('all_groups.default', system, processes)

一部のワークロードは特定のサービスに分離できません。つまり、あるサービス上のワークロードが、同じウェアハウス内の別のサービスに影響するケースがあります。具体的には、次のようなものがあります。

• すべての読み書きサービスは、デフォルトでバックグラウンドマージ処理を実行します。 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 を指定して、データベース管理クエリを実行できます。

たとえば:

CREATE DATABASE db_test_ddl_single_query_setting
SETTINGS distributed_ddl_task_timeout=0

サービスを手動で停止した場合、クエリを実行するには再度起動する必要があります。

• プライマリサービスのアイドル化: プライマリサービスの自動アイドル化はデフォルトで有効になっています。

コンピュートの価格は、1 つの ウェアハウス 内のすべてのサービス (プライマリおよびセカンダリ) で共通です。ストレージ料金が課金されるのは 1 回のみで、最初の (元の) サービスに含まれます。

ワークロードの規模と選択したティアに基づいてコストを見積もるには、pricing ページの料金計算ツールを参照してください。Usage Breakdown テーブルには、サービスごとのコンピュートコストの内訳が表示されます。

• 1 つの ウェアハウス 内のすべての サービス は同じストレージを共有するため、バックアップはプライマリ (初期) サービス でのみ作成されます。これにより、ウェアハウス 内のすべての サービス のデータがバックアップされます。
• ウェアハウス のプライマリ サービス からバックアップを復元すると、既存の ウェアハウス には接続されていない、まったく新しい サービス として復元されます。復元が完了したらすぐに、その新しい サービス にさらに サービス を追加できます。

ウェアハウスを作成するには、既存のサービスとデータを共有する 2 つ目のサービスを作成する必要があります。これは、既存のサービスのいずれかにあるプラス記号をクリックして行えます。

図 7 - プラス記号をクリックして、ウェアハウス内に新しいサービスを作成します

サービス作成画面では、新しいサービスのデータ元として、元のサービスがドロップダウンで選択された状態になります。作成後、これら 2 つのサービスで 1 つのウェアハウスが構成されます。

ウェアハウス名を変更する方法は 2 つあります。

• services ページの右上にある「Sort by warehouse」を選択し、ウェアハウス名の横にある鉛筆アイコンをクリックします
• いずれかのサービスでウェアハウス名をクリックし、そこで名前を変更できます

ウェアハウスを削除すると、すべてのコンピュートサービスとデータ (テーブル、ビュー、ユーザーなど) が削除されます。この操作は元に戻せません。 ウェアハウスを削除できるのは、最初に作成したサービスを削除する場合のみです。手順は次のとおりです。

1. 最初に作成したサービス以外の、すべてのサービスを削除します。
2. 最初のサービスを削除します (警告: この手順ですべてのウェアハウスデータが削除されます) 。