mirror of
https://github.com/ClickHouse/ClickHouse.git
synced 2024-12-15 02:41:59 +00:00
191 lines
14 KiB
Markdown
191 lines
14 KiB
Markdown
---
|
||
title: ウェアハウス、またはコンピュート・コンピュート分離
|
||
slug: /ja/cloud/reference/compute-compute-separation
|
||
keywords: [コンピュート分離, クラウド, アーキテクチャ, コンピュート・コンピュート, ウェアハウス, ウェアハウス]
|
||
description: ClickHouse Cloud での複数の、分離されたノードグループの使用方法
|
||
|
||
---
|
||
|
||
# ウェアハウス、またはコンピュート・コンピュート分離（プライベートプレビュー）
|
||
|
||
## コンピュート・コンピュート分離とは?
|
||
|
||
各ClickHouse Cloudサービスには以下が含まれます：
|
||
- ClickHouseノード（またはレプリカ）のグループ - **開発**ティアサービスには2ノード、**本番**ティアサービスには3ノード
|
||
- サービスに接続するために使用するエンドポイント（またはClickHouse Cloud UIコンソールで作成された複数のエンドポイント）、これはサービスURLです（例：`https://dv2fzne24g.us-east-1.aws.clickhouse.cloud:8443`)
|
||
- サービスがすべてのデータと一部のメタデータを保存するオブジェクトストレージフォルダー：
|
||
|
||
<br />
|
||
|
||
<img src={require('./images/compute-compute-1.png').default}
|
||
alt='NEEDS ALT'
|
||
class='image'
|
||
style={{width: '200px'}}
|
||
/>
|
||
|
||
<br />
|
||
|
||
_Fig. 1 - 現在のClickHouse Cloudサービス_
|
||
|
||
コンピュート・コンピュート分離により、ユーザーは複数のコンピュートノードグループを作成できます。これらはそれぞれ独自のエンドポイントを持ち、同じオブジェクトストレージフォルダーを使用するため、同じテーブル、ビューなどを持つことが可能です。
|
||
|
||
各コンピュートノードグループは独自のエンドポイントを持つため、どのレプリカセットをワークロードに使用するか選択できます。あるワークロードは小型のレプリカ1つで満足できるかもしれませんし、他のワークロードは高可用性（HA）と何百ギガのメモリを必要とするかもしれません。コンピュート・コンピュート分離により、読み取り操作を書き込み操作から分離し、相互に干渉しないようにすることも可能です。
|
||
|
||
<br />
|
||
|
||
<img src={require('./images/compute-compute-2.png').default}
|
||
alt='NEEDS ALT'
|
||
class='image'
|
||
style={{width: '500px'}}
|
||
/>
|
||
|
||
<br />
|
||
|
||
_Fig. 2 - ClickHouse Cloudのコンピュート_
|
||
|
||
このプライベートプレビュープログラムでは、既存のサービスのデータを共有する新しいサービスを作成したり、同じデータを共有する複数のサービスを持つ完全に新しいセットアップを作成することができます。
|
||
|
||
## ウェアハウスとは何ですか?
|
||
|
||
ClickHouse Cloudでの_ウェアハウス_は、同じデータを共有するサービスのセットです。
|
||
各ウェアハウスには主要なサービス（最初に作成されたサービス）と副サービスがあります。以下のスクリーンショットでは、同じデータを共有する「DWH Prod」というウェアハウスと2つのサービスが含まれていることが分かります：
|
||
- 主要サービス「DWH Prod」
|
||
- 副サービス「DWH Prod Subservice」
|
||
|
||
<br />
|
||
|
||
<img src={require('./images/compute-compute-8.png').default}
|
||
alt='NEEDS ALT'
|
||
class='image'
|
||
style={{width: '800px'}}
|
||
/>
|
||
|
||
<br />
|
||
|
||
_Fig. 3 - ウェアハウスの例_
|
||
|
||
ウェアハウス内のすべてのサービスは同じものを共有します：
|
||
|
||
- 地域（例：us-east1）
|
||
- クラウドサービスプロバイダー（AWS, GCPまたはAzure）
|
||
- ClickHouseデータベースのバージョン
|
||
|
||
サービスは所属するウェアハウスごとにソートできます。
|
||
|
||
## アクセス制御
|
||
|
||
### データベース資格情報
|
||
|
||
ウェアハウス内のすべてが同じテーブルセットを共有しているため、他のサービスへのアクセス制御も共有します。これは、サービス1で作成されたすべてのデータベースユーザーが、同じ権限（テーブル、ビューへの付与など）を持ってサービス2も使用できることを意味します。ユーザーは各サービスの別のエンドポイントを使用しますが、同じユーザー名とパスワードを使用します。つまり、_ユーザーは同じストレージを使って作業するサービス間で共有されます：_
|
||
|
||
<br />
|
||
|
||
<img src={require('./images/compute-compute-3.png').default}
|
||
alt='NEEDS ALT'
|
||
class='image'
|
||
style={{width: '500px'}}
|
||
/>
|
||
|
||
<br />
|
||
|
||
_Fig. 4 - ユーザーAliceはサービス1で作成されましたが、同じ資格情報を使って同じデータを共有するすべてのサービスにアクセスできます_
|
||
|
||
### ネットワークアクセス制御
|
||
|
||
他のアプリケーションやアドホックユーザーによる特定のサービスの使用を制限することはしばしば有用です。これはネットワーク制限を使用して実現できます。現在通常のサービスに設定されているのと同様に設定できます（ClickHouse Cloudコンソールの特定のサービスタブの**設定**に移動）。
|
||
|
||
IPフィルタリング設定を各サービスに別々に適用できるため、どのアプリケーションがどのサービスにアクセスできるかを制御できます。これにより、特定のサービスの利用を制限できます：
|
||
|
||
<br />
|
||
|
||
<img src={require('./images/compute-compute-4.png').default}
|
||
alt='NEEDS ALT'
|
||
class='image'
|
||
style={{width: '400px'}}
|
||
/>
|
||
|
||
<br />
|
||
|
||
_Fig. 5 - ネットワーク設定によりAliceはサービス2にアクセス不可とされています_
|
||
|
||
### 読み取り vs 読み書き
|
||
|
||
特定のサービスの書き込みアクセスを制限し、ウェアハウス内のサービスのサブセットのみが書き込みを許可されるようにすることが有用な場合があります。これを行うには、2番目およびn番目のサービスを作成するときに行えます（最初のサービスは常に読み書き可能であるべきです）：
|
||
|
||
<br />
|
||
|
||
<img src={require('./images/compute-compute-5.png').default}
|
||
alt='NEEDS ALT'
|
||
class='image'
|
||
style={{width: '400px'}}
|
||
/>
|
||
|
||
<br />
|
||
|
||
_Fig. 6 - ウェアハウス内の読み書き可能および読み取り専用のサービス_
|
||
|
||
## スケーリング
|
||
|
||
ウェアハウス内の各サービスは以下に対してワークロードに合わせて調整できます：
|
||
- ノード（レプリカ）の数。現在、ノード（レプリカ）の最小数は2です。
|
||
- ノード（レプリカ）のサイズ
|
||
- サービスが自動的にスケールするかどうか
|
||
- サービスが非アクティブ時にアイドル状態にするべきか（グループ内の最初のサービスには適用できません - **制限**セクションを参照してください）
|
||
|
||
## 動作の変更
|
||
|
||
サービスでコンピュート・コンピュートが有効になると（少なくとも1つの副サービスが作成された場合）、`clusterAllReplicas()` 関数呼び出しは`default` クラスタ名を使用して、呼び出されたサービスのレプリカのみを活用します。つまり、同じデータセットに接続されている2つのサービスがあり、サービス1から `clusterAllReplicas(default, system, processes)` が呼ばれる場合、サービス1で実行されているプロセスのみが表示されます。必要に応じて、例えば `clusterAllReplicas('all_groups.default', system, processes)` を呼び出してすべてのレプリカに到達することもできます。
|
||
|
||
## 制限事項
|
||
|
||
このコンピュート・コンピュート分離が現在プライベートプレビュー中であるため、この機能を使用する場合にはいくつかの制限事項があります。これらの制限の多くは、機能がGA（一般公開）にリリースされた後に解除されます：
|
||
|
||
1. **主要（元の）サービスは最近作成されたか、移行されているべきです。** 残念ながら、すべての既存のサービスが他のサービスとストレージを共有できるわけではありません。昨年中にサービスがサポートする必要があるいくつかの機能（共有Merge Treeエンジンなど）をリリースしたため、未更新のサービスはほとんど他のサービスとデータを共有できません。これはClickHouseバージョンに依存しません。
|
||
|
||
良いニュースは、我々が古いサービスを新しいエンジンに移行し、追加のサービスを作成できるようにすることができます。ご希望のサービスが移行する必要があるかどうか、サポートにお問い合わせください。
|
||
|
||
2. **主要サービスは常に稼働中であり、アイドル状態になってはならない（GAの数時間後にこの制限は解除されます）。** プライベートプレビュー中およびGA後の数時間は、主要サービス（通常は他のサービスを追加することで拡張したい既存のサービス）は常に稼働しており、アイドル設定が無効化されています。少なくとも1つの副サービスがある場合、主要サービスを停止またはアイドル状態にすることはできません。すべての副サービスが削除されたら、元のサービスを再び停止またはアイドル状態にできます。
|
||
|
||
3. **時にはワークロードを隔離できないことがあります。** データベースワークロードを互いに隔離するオプションを提供することを目的としていますが、1つのサービスのワークロードが同じデータを共有する別のサービスに影響を与えるコーナーケースがあるかもしれません。これは主にOLTPのようなワークロードに関連する非常に稀な状況です。
|
||
|
||
4. **すべての読み書き可能なサービスはバックグラウンドマージ操作を実施します。** ClickHouseにデータを挿入すると、最初にデータベースはデータをステージングパーティションに挿入し、その後バックグラウンドでマージ操作を行います。これらのマージはメモリとCPUリソースを消費します。2つの読み書き可能なサービスが同じストレージを共有している場合、両方ともバックグラウンド操作を実行しています。つまり、サービス1で`INSERT`クエリがありますが、マージ操作がサービス2で完了することがあるかもしれません。読み取り専用のサービスはバックグラウンドマージを実行しないため、この操作にリソースを費やしません。
|
||
|
||
5. **一つの読み書き可能なサービスでの挿入操作が、アイドル状態にした場合のもう一つの読み書き可能なサービスを防ぐことがある。** 前のポイントのため、第二のサービスが最初のサービス用にバックグラウンドマージ操作を行います。これらのバックグラウンド操作は、第二のサービスがアイドル状態になるのを妨げる可能性があります。バックグラウンド操作が完了すると、サービスはアイドル状態になります。読み取り専用サービスは影響を受けず、遅延なくアイドル状態になります。
|
||
|
||
6. **CREATE/RENAME/DROP DATABASEクエリはアイドル/停止状態のサービスによってブロックされる可能性がある（GAの際に制限は解除されます）。** これらのクエリはハングすることがあります。これを回避するには、セッションまたはクエリ単位で `settings distributed_ddl_task_timeout=0` でデータベース管理クエリを実行することができます。例：
|
||
|
||
```sql
|
||
create database db_test_ddl_single_query_setting
|
||
settings distributed_ddl_task_timeout=0
|
||
```
|
||
|
||
## 料金
|
||
|
||
プライベートプレビュー中に作成された追加のサービスは通常どおり請求されます。コンピュート価格はウェアハウス内のすべてのサービス（主および副）で同じです。ストレージは一度だけ請求されます - それは最初の（オリジナルの）サービスに含まれています。
|
||
|
||
## プライベートプレビュー終了後に何が起こるか
|
||
|
||
プライベートプレビュープログラムが終了し、コンピュート・コンピュート分離機能がGAにリリースされると、新しく作成されたサービスはコンピュート・コンピュート分離機能の一部としてそのまま残ります。データやサービスが削除されることはありません。
|
||
|
||
## バックアップ
|
||
|
||
- 単一ウェアハウス内のすべてのサービスが同じストレージを共有しているため、バックアップは主要（初期）サービス上のみで作成されます。これにより、ウェアハウス内のすべてのサービスのデータがバックアップされます。
|
||
- ウェアハウスの主要サービスのバックアップを復元する場合、既存のウェアハウスと接続されていない完全に新しいサービスに復元されます。復元が完了した直後に新しいサービスに他のサービスを追加できます。
|
||
|
||
## 始める方法
|
||
|
||
組織内でコンピュート・コンピュート分離プライベートプレビューを有効にするには、ClickHouse Cloudサポートチームに連絡してください。チームがこの機能を有効にすると、組織内の既存のサービスに追加のサービスを作成できるようになり、プラス記号をクリックします。
|
||
|
||
<br />
|
||
|
||
<img src={require('./images/compute-compute-7.png').default}
|
||
alt='NEEDS ALT'
|
||
class='image'
|
||
style={{width: '800px'}}
|
||
/>
|
||
|
||
<br />
|
||
|
||
_Fig. 7 - ウェアハウス内で新しいサービスを作成するためにプラス記号をクリック_
|
||
|