ウェアハウスの紹介: ClickHouse Cloud におけるコンピュート-コンピュート分離

現代のクラウドデータベースサービスにおいて、コンピュート-コンピュート分離は特定のワークロード、ユーザー、ビジネス機能に対してコンピュートリソースを分離することで、データベースパフォーマンスとリソース管理を最適化する強力なアプローチを提供します。従来のリソース共有モデルとは異なり、この方法では、読み取りや書き込みなど、異なるタイプのデータベース操作に専用のコンピュートインスタンスを割り当てるため、相互干渉のリスクが低減します。特に需要の高い環境では、ワークロードが変動することでクエリの速度や信頼性に影響が生じる可能性があり、こうした場面で特に有用です。

本記事では、ClickHouse Cloud におけるコンピュート-コンピュート分離の導入を発表し、その重要性と、何よりユーザーにとって何を意味するのかを解説します。

データベースにおけるコンピュート-コンピュート分離とは、異なるユーザー、ワークロード、あるいはオペレーションタイプごとに専用のコンピュートリソースを割り当て、互いに干渉しないようにする仕組みを指します。コンピュートリソースを分離することで、あるクエリのパフォーマンスや安定性が他のワークロードによって影響を受けることを防ぐことができます。
類似の結果を、クォータやリミットを活用することで部分的に実現することも可能ですが、柔軟性や保証の面では、コンピュート-コンピュート分離の持つ特性には及びません。

実際には、ユーザーは同じデータ（テーブルやビューなど）を読み書きする際に、異なる専用のコンピュートプールを用意できるようになります。それぞれが異なるタスク向けに分離されているのです。

このような分離は、以下のようなシナリオで非常に役立ちます。

一部のユースケースでは、書き込み操作がクエリ実行時間に対して非常に敏感になる場合があります。こうしたシナリオでは、データベース内の他のクエリによって INSERT や UPDATE の実行時間が影響を受けないことが望ましいです。特にユーザーや BI ツールから直接投げられるアドホッククエリでは、非効率的だったり、リソースを過度に消費したりするクエリが実行される可能性があり、他のクエリにまで影響が及びがちです。

コンピュート-コンピュート分離を行うことで、最も重要なワークロード――例えば INSERT 操作――に専用のコンピュートリソースを割り当て、他のクエリに左右されないパフォーマンスを実現できます。場合によっては、書き込みよりも特定の読み取り操作のほうが重要であるケースもあるでしょう。その場合も同様に、専用のコンピュートリソースを割り当てることで確実にパフォーマンスを確保できます。

大規模企業では、数十、あるいは数百ものチームや部署が同じデータベースやデータウェアハウスにアクセスすることがあります。同じデータにアクセスしていても、チームごとに求められるパフォーマンスレベルが異なる場合がありますし、他チームとコンピュートリソースを共有することで、クエリパフォーマンスが不安定になることを好まないこともあります。

さらに、コスト管理や予算上の理由から、チームごとにデータベースの利用料金を分離したい場合も多いでしょう。

このようなシナリオにおいて、コンピュート-コンピュート分離は以下のメリットをもたらします:

• チームごとのワークロードを分離し、互いのクエリが相互にパフォーマンスへ影響を及ぼさないようにできる
• 各チームに対して、異なるコンピュートサイズやアイドル設定を適用することができ、必要な性能とコストを最適化しやすくなる
• 各チームの利用コストを明確に分離し、アイドリングを有効にしている場合でもクエリのコストをはっきりと把握できる

ある種のワークロードは極めて重要度が高い一方、多少のダウンタイムを許容してコストを削減したい場合もあります。例えば:

• エンドユーザーに提供している製品のチャートや可視化は最高レベルの可用性が求められるため、3 つのアベイラビリティゾーンを使用すべきです。ただし、これらのクエリ自体は比較的シンプルであり、CPU やメモリを大量に必要としないことも多いです。
• ETL/ELT クエリは重要でありリソースを大きく消費しますが、失敗した場合に再実行が可能です。よって、2 つのアベイラビリティゾーンで合計 2 ノードだけを割り当てる程度で十分といったケースもあります。
• 手動で実行される大規模なアドホッククエリは、メモリを大量に消費する可能性があり、またアナリストが平日の勤務時間 (例えば 5 日×8 時間) のみ作業するといった前提ならば、その時間以外はアイドリングしても問題ありません。さらに、一時的なノード障害があってもリトライ可能で、ある程度の失敗は許容できるかもしれません。そういった場合、1 つのアベイラビリティゾーンに単一ノードを割り当てるだけで十分かもしれません。

このように、コンピュート-コンピュート分離を用いることで、各ワークロードが求める高可用性レベルをそれぞれ確保しつつ、同じデータベースを使う複数のチームに対してコストを分離することが可能です。

ClickHouse Cloud において、各データベースインスタンスには以下が含まれます:

• 1 つ以上の ClickHouse ノード（またはレプリカ）のグループ
  （アベイラビリティ設定に応じて 1 ノード以上で構成）
• サービス URL をもつエンドポイント（ClickHouse Cloud の UI コンソールを経由して複数作成可能）
  例: https://dv2fzne24g.us-east-1.aws.clickhouse.cloud:8443
• サービスがすべてのデータおよび一部のメタデータを保存するオブジェクトストレージフォルダ
• 通常 3 ノード構成の keeper インスタンス:

ここに、新たに ウェアハウス (Warehouses) という概念を導入します。ウェアハウスとは、同じデータ（テーブル、ビュー、関数など）を共有する複数のサービスをまとめたセットです。各ウェアハウスには、プライマリサービス（最初に作成されたサービス）と、1 つ以上のセカンダリサービスが含まれます。
例として、2 つのサービスを含むウェアハウスを以下に示します。

このようなウェアハウス内の各サービスは、それぞれ以下を独自に持っています:

• エンドポイント: どのワークロードや BI ツール、ETL/ELT システムがどのノード群を利用するかを調整するため
• コンピュートノード: 他サービスとの干渉を防ぎ、各ワークロードを独立して実行できる。たとえば、以下を個別にスケール可能:
  • サービスあたりのノード数
  • ノードサイズ (RAM の GiB 単位)
    ※インスタンスサイズが大きいほど vCPU も多くなる
  • サービスのアイドリング設定
  • エンタープライズ ティアの顧客の場合、サービス単位で異なる CPU/RAM 比率を選択可能。
    あるワークロードでは圧縮/解凍に CPU を多く要し、別のワークロードでは複雑なクエリにメモリを多く要するといったケースに対応するため、これらを分離して最適化できる
• ネットワークアクセス設定: アプリやユーザーが特定のサービスにアクセスできないように制限をかけるなど

一方、同じウェアハウス内のすべてのサービスに共通するものは以下です:

• データ: すべてのサービスが同じデータを扱うため、同じウェアハウス内のどのサービスで SELECT クエリを実行しても同じ結果が得られる
• Keeper インスタンス: Keeper はデータのノード間レプリケーションや調整を行うため、同じデータを扱うすべてのサービスは共有の Keeper クラスタを利用する
• バックアップ: 同じデータを複数のサービスでバックアップしたくはないので、最初に作成されたプライマリサービスのみでバックアップを行う
• 現時点では、すべてのサービスが以下を同一にする必要がある:
  • クラウドプロバイダ (AWS、GCP、Azure のいずれか)
  • リージョン
  • ClickHouse のデータベースバージョン

UI 上では、2 つ以上のサービスを持つ最初のウェアハウスが作成されると、同じウェアハウスに属するサービスがグルーピングされて表示されます。下記の例では、2 つのウェアハウスが存在します:

• DWH_pre_prod: 4 つのサービスを持つ
• DWH_for_tests_us_east_1: 1 つのサービスのみ

コンピュート-コンピュート分離を実現するには、主に 2 つの問題に対処する必要がありました。1 つは異なるコンピュートグループ間でのデータ同期、もう 1 つはクエリワークロードがサービスごとの境界を守り、同じウェアハウス内の別サービスが持つリソースを使用しないようにすることです。

ClickHouse Cloud のアーキテクチャ上の 2 つの重要な設計が、このデータ同期を効率的に実現する助けとなっています。
1 つ目は ストレージとコンピュートの分離 です。クラウドプロバイダのストレージ（例: S3）上の同じデータを共有できるため、異なるサービス間でデータを同期しやすくなります。
2 つ目はテーブルスキーマやメタデータの同期において SharedMergeTree テーブルエンジン を使用しており、Keeper フリートを活用した軽量なメタデータ同期を実現している点です。

さらに、コンピュート分離を実装するためには、replica-group の概念 をレプリケートされたデータベース内で利用します。このアプローチにより、分散クエリやパラレルレプリカにおける負荷は各レプリカグループ内に限定され、同じウェアハウス内であっても他サービスのリソースを追加で消費することを防ぎます。この仕組みにより、隔離性と効率性が保たれます。

これらの技術基盤に加えて、コンピュート-コンピュート分離をフルサポートするため、以下の変更も行いました:

• ウェアハウス内の各サービスを個別に監視し、アイドリングや自動スケールを独立して行えるようにした
• ウェアハウス単位でのネットワーク分離・ストレージ分離をセキュリティのために強化
• 同一ウェアハウス内のサービス間でデータベース同期を強制
• 読み取り専用サービス (read-only) ではマージや挿入処理を行わないようにし、バックグラウンドジョブ（ミューテーションなど）が読み取り専用サービスに影響を与えないようにした（詳細は「Background operations」節を参照）

同じウェアハウス内のすべてのサービスは、同じテーブルやビューを共有しているため、ユーザー/ロールやアクセス制御（権限付与）も共有されます。つまり、「サービス 1」で作成されたデータベースユーザーは、「サービス 2」でも同じ権限（テーブルやビューへのアクセスなど）を使ってログイン可能です。ユーザーはサービスごとに異なるエンドポイントを使用する一方、ユーザー名やパスワードは同一となります。
言い換えると、ウェアハウス内のサービス間でユーザー情報は共有されるということです:

ただし、一部のサービスを特定のアプリやアドホックユーザーからアクセスできないようにしたい場合もあるでしょう。これは、ネットワーク制限を設定することで実現できます。既存の通常サービスで行っている設定方法と同様に、ClickHouse Cloud コンソールの対象サービスの Service タブで Settings に移動し、設定を行います。

サービスごとに IP フィルタリング設定を適用できるため、どのアプリやユーザーがどのサービスにアクセス可能かを制御できます。

特定のサービスを読み取り専用にし、ウェアハウス内の一部サービスだけで書き込みを行わせたいケースもあります。これは、最初に作成されたプライマリサービス以外のサービスを 読み取り専用 に設定することで実現できます（最初のサービスは常に書き込み可能である必要があります）。

ClickHouse は、データ挿入後のマージ処理のように、リソースを大量消費するバックグラウンドオペレーションをいくつか実行します。これらのマージ処理には多くのメモリや CPU リソースが必要となる場合があります。

コンピュート-コンピュート分離を完全に実現するため、バックグラウンドのマージは書き込み可能 (read-write) なサービスのみで行うようにしました。したがって、重要な読み取りワークロード専用に読み取り専用サービスを用意すれば、そのサービスではマージが実行されず、読み取りパフォーマンスへの影響を回避できます。

一方、複数の読書き可能 (RW) サービスがある場合、いずれのサービスでも、どのサービスから行われた INSERT に対してもマージを実行する可能性があります。これは、マージ処理自体が、トリガーとなったクエリと直接結びついていないためです。その結果、別のサービスで発生した重い書き込みが、別サービスに影響を及ぼすケースもまれにありえます。将来的には、どの RW サービスがバックグラウンドジョブを実行するかを制御し、クエリを発行したサービスに対応する形で処理を分散できる設定を導入する予定です。

ウェアハウスは ClickHouse Cloud に大きな柔軟性をもたらしますが、現時点の実装にはいくつかの制限があり、今後これらを取り除いていく予定です:

1. ウェアハウス内の最初のサービスは常に稼働状態でなければならず、アイドリングさせることはできません。セカンダリサービスが 1 つでも存在する場合、プライマリサービスを停止またはアイドリングにできません。すべてのセカンダリサービスを削除すると、オリジナルのサービスを再び停止やアイドリングにすることが可能です。

2. 前述のとおり、すべての読書き可能サービス (RW サービス) はバックグラウンドでマージ操作を実行します。たとえば、サービス 1 で INSERT クエリを実行した場合でも、マージはサービス 2 で行われる可能性があります。つまり、ある RW サービスのワークロードが、別の RW サービスのパフォーマンスに影響を与える場合があります。一方、読み取り専用 (RO) サービスはバックグラウンドでマージを実行しないため、この操作でリソースを消費しません。
   挿入や変換には単一の RW サービスを用い、他の用途には RO サービスを利用することを検討してください。

3. ある RW サービスに対する挿入 (INSERT) 処理が、アイドリングを有効にしている別の RW サービスをアイドリングできなくする場合があります。これは前のポイントと関連しており、1 つめのサービスの挿入処理に対して、2 つめのサービスがバックグラウンドマージを実行する可能性があるためです。このバックグラウンド処理が実行されている間は、2 つめのサービスはスリープ状態に入れません。マージ処理が完了すれば、そのサービスはアイドリングに移行します。読み取り専用サービスは影響を受けず、遅延なくアイドリングされます。

4. CREATE/RENAME/DROP DATABASE クエリは、デフォルト設定のままだと停止中やアイドリング状態のサービスによってブロックされ、クエリが完了しない可能性があります。回避するには、以下のようにセッションまたはクエリレベルで distributed_ddl_task_timeout=0 を設定してデータベース管理クエリを実行してください。

   1create database db_test_ddl_single_query_setting
   2settings distributed_ddl_task_timeout=0
   
   

ウェアハウスを正式リリースする前に、一部のお客様にプライベートプレビューとして提供し、実際の本番ワークロードでテストしていただきました。以下は、そのユーザーからのフィードバックの一部です:

"私たちは小規模なプライマリクラスターを用意して書き込み専用とし、大規模なクラスターは読み取り専用にしています。さらにアドホッククラスターを用意しておき、使用していないときはスリープに入るようにしています。アドホックは素晴らしいですね。ユーザーがどんな非効率なクエリを実行しても、本番環境に影響を与えないので助かります。"

Beehiiv.com

"今のところ順調です！ 今週はプライマリサービスに追加の負荷がかかったのですが、セカンダリサービスにトラフィックを振り分けることで、顧客向けクエリの速度を維持できました。"

CommonRoom.io

"`query_cache`、`allow_experimental_analyzer`、`allow_experimental_parallel_reading_from_replicas` とあわせてコンピュート-コンピュート分離を本番環境で運用し始めましたが、非常に素晴らしいです。まるで夢のような環境になりました。"

Vantage.sh

"コンピュート-コンピュート分離の効果は抜群です。テストの結果、現在 BigQuery で 30 分かかっている通常のコンピュートタスクが、30 秒ほどに短縮できました。ワークロードを分離できたおかげです。"

ABTasty.com

"8 時間かかっていた処理が、今は 30 分以内、あるいはそれ以下に短縮されました。他のサービスへの影響は特にありません。A+ 機能です。"

Cypress.io

本記事では、コンピュート-コンピュート分離が ClickHouse Cloud のお客様のテナント分離を高め、リソース消費やコストの全体最適化にどのように役立っているかを紹介しました。

ClickHouse Cloud の新規ユーザーとしてウェアハウスを体験するには、こちら から 300 ドル分の無料トライアルをお試しください。既存のユーザーの方は、製品内の案内に従い、ウェアハウスをサポートする新しいティアへ既存のデプロイを移行できます。詳しくは FAQ をご覧ください。