AWSのBYOC (自分のクラウドを持ち込む)
概要
BYOC (Bring Your Own Cloud) は、ClickHouse Cloud を自分自身のクラウドインフラストラクチャにデプロイすることを可能にします。これは、特定の要件や制約があり、ClickHouse Cloud のマネージドサービスを利用できない場合に便利です。
アクセスをご希望の方は、お問い合わせください。 詳細は、利用規約を参照してください。
BYOC は現在、AWS のみでサポートされています。GCP および Azure の待機リストに参加するには、こちらをクリックしてください。
BYOC は大規模なデプロイメント向けに特別に設計されており、顧客はコミット契約に署名する必要があります。
用語集
- ClickHouse VPC: ClickHouse Cloud が所有する VPC。
- 顧客 BYOC VPC: 顧客のクラウドアカウントが所有する VPC で、ClickHouse Cloud によってプロビジョニングおよび管理され、ClickHouse Cloud BYOC デプロイメントに専用されています。
- 顧客 VPC: 顧客のクラウドアカウントが所有する他の VPC で、顧客 BYOC VPC に接続する必要のあるアプリケーションに使用されます。
アーキテクチャ
メトリックとログは顧客の BYOC VPC 内に保存されます。ログは現在、EBS にローカルに保存されています。今後のアップデートでは、ログは顧客の BYOC VPC 内の ClickHouse サービスである LogHouse に保存される予定です。メトリックは、顧客の BYOC VPC 内にローカルに保存された Prometheus と Thanos スタックを介して実装されます。

オンボーディングプロセス
顧客は、お問い合わせを通じてオンボーディングプロセスを開始できます。顧客は専用の AWS アカウントを持ち、使用するリージョンを知っている必要があります。現時点では、ClickHouse Cloud がサポートしているリージョンでのみ BYOC サービスを起動することができます。
AWS アカウントの準備
顧客は、ClickHouse BYOC デプロイメントをホスティングするために専用の AWS アカウントを準備することを推奨します。これにより、より良い隔離が確保されます。ただし、共有アカウントや既存の VPC を使用することも可能です。詳細は下記の BYOC インフラストラクチャの設定 を参照してください。
このアカウントと初期の組織管理者のメールアドレスを使用して、ClickHouse サポートに連絡できます。
BYOC セットアップの初期化
初期の BYOC セットアップは、CloudFormation テンプレートまたは Terraform モジュールを使用して実行できます。どちらのアプローチでも、ClickHouse Cloud の BYOC コントローラがインフラストラクチャを管理できるように、同じ IAM ロールが作成されます。ClickHouse を実行するために必要な S3、VPC、およびコンピューティングリソースは、この初期設定には含まれていないことに注意してください。
CloudFormation テンプレート
Terraform モジュール
BYOC インフラストラクチャの設定
CloudFormation スタックを作成した後、インフラストラクチャを設定するように求められます。これには S3、VPC、および EKS クラスターが含まれます。特定の設定はこの段階で決定する必要があります。後から変更できません。具体的には:
- 使用したいリージョン: ClickHouse Cloud 用の任意の 公開リージョン のいずれかを選択できます。
- BYOC 用の VPC CIDR 範囲: デフォルトでは、BYOC VPC CIDR 範囲に
10.0.0.0/16
を使用します。他のアカウントとの VPC ピアリングを行う予定の場合は、CIDR 範囲が重複しないように注意してください。BYOC 用に、必要なワークロードを収容できる最小サイズ/22
の適切な CIDR 範囲を割り当ててください。 - BYOC VPC のアベイラビリティゾーン: VPC ピアリングを使用する予定の場合、ソースアカウントと BYOC アカウント間でアベイラビリティゾーンを揃えることで、クロス AZ トラフィックコストを削減できます。AWS では、アベイラビリティゾーンの接尾辞(
a, b, c
)は、アカウント間で異なる物理ゾーン ID を表す場合があります。詳細については、AWS ガイドを参照してください。
顧客管理 VPC
デフォルトでは、ClickHouse Cloud は BYOC デプロイメントのために専用の VPC をプロビジョニングします。ただし、アカウント内の既存の VPC を使用することもできます。これには特定の設定が必要で、ClickHouse サポートを通じて調整しなければなりません。
既存の VPC の設定
- ClickHouse Cloud が使用するために、異なる 3 つのアベイラビリティゾーンにまたがって、少なくとも 3 つのプライベートサブネットを割り当ててください。
- 各サブネットには、ClickHouse デプロイメントに十分な IP アドレスを提供するために、最小 CIDR 範囲
/23
(例:10.0.0.0/23)を確保してください。 - 各サブネットに
kubernetes.io/role/internal-elb=1
タグを追加して、適切なロードバランサーの設定を有効にしてください。


- S3 ゲートウェイエンドポイントを設定 VPC にすでに S3 ゲートウェイエンドポイントが設定されていない場合は、セキュアでプライベートな通信を有効にするために作成する必要があります。このエンドポイントにより、ClickHouse サービスは公共インターネットを経由せずに S3 にアクセスできます。以下のスクリーンショットを参照して、設定の例を確認してください。

ClickHouse サポートに連絡する 以下の情報を含むサポートチケットを作成します。
- あなたの AWS アカウント ID
- サービスをデプロイしたい AWS リージョン
- あなたの VPC ID
- ClickHouse のために割り当てたプライベートサブネット ID
- これらのサブネットがあるアベイラビリティゾーン
オプション: VPC ピアリングの設定
ClickHouse BYOC のために VPC ピアリングを作成または削除するには、次の手順に従います。
ステップ 1: ClickHouse BYOC のためのプライベートロードバランサーを有効にする
ClickHouse サポートに連絡して、プライベート ロードバランサーを有効にしてください。
ステップ 2: ピアリング接続を作成する
- ClickHouse BYOC アカウントの VPC ダッシュボードに移動します。
- ピアリング接続を選択します。
- ピアリング接続を作成するをクリックします。
- VPC リクエスターを ClickHouse VPC ID に設定します。
- VPC アクセプターを対象の VPC ID に設定します。(適用可能な場合は別のアカウントを選択)
- ピアリング接続の作成をクリックします。

ステップ 3: ピアリング接続リクエストを承認する
ピアリングアカウントに移動し、(VPC -> ピアリング接続 -> アクション -> リクエストを受け入れる)ページで顧客はこの VPC ピアリングリクエストを承認できます。

ステップ 4: ClickHouse VPC ルートテーブルに宛先を追加する
ClickHouse BYOC アカウント内で、
- VPC ダッシュボードでルートテーブルを選択します。
- ClickHouse VPC ID を検索します。プライベートサブネットに接続された各ルートテーブルを編集します。
- ルートタブの下にある編集ボタンをクリックします。
- もう 1 つのルートを追加をクリックします。
- 宛先として対象 VPC の CIDR 範囲を入力します。
- 「ピアリング接続」を選択し、ターゲットのためにピアリング接続の ID を選択します。

ステップ 5: 対象 VPC ルートテーブルに宛先を追加する
ピアリング AWS アカウント内で、
- VPC ダッシュボードでルートテーブルを選択します。
- 対象 VPC ID を検索します。
- ルートタブの下にある編集ボタンをクリックします。
- もう 1 つのルートを追加をクリックします。
- 宛先として ClickHouse VPC の CIDR 範囲を入力します。
- 「ピアリング接続」を選択し、ターゲットのためにピアリング接続の ID を選択します。

ステップ 6: ピアリング VPC アクセスを許可するようにセキュリティグループを編集する
ClickHouse BYOC アカウント内では、ピアリング VPC からのトラフィックを許可するようにセキュリティグループの設定を更新する必要があります。ピアリング VPC の CIDR 範囲を含むインバウンドルールの追加をリクエストするには、ClickHouse サポートにお問い合わせください。
ClickHouse サービスは、ピアリングされた VPC からアクセス可能であるべきです。
ClickHouse にプライベートにアクセスするために、プライベート ロードバランサーとエンドポイントが、ユーザーのピアリング VPC からのセキュアな接続のためにプロビジョニングされます。プライベートエンドポイントは、公共エンドポイント形式に -private
接尾辞を付加したものです。例:
- 公共エンドポイント:
h5ju65kv87.mhp0y4dmph.us-west-2.aws.byoc.clickhouse.cloud
- プライベートエンドポイント:
h5ju65kv87-private.mhp0y4dmph.us-west-2.aws.byoc.clickhouse.cloud
オプションとして、ピアリングが機能していることを確認した後、ClickHouse BYOC の公共ロードバランサーの削除をリクエストできます。
アップグレードプロセス
私たちは、ClickHouse データベースのバージョンアップグレード、ClickHouse オペレーター、EKS、その他のコンポーネントを含むソフトウェアのアップグレードを定期的に行っています。
シームレスなアップグレードを目指していますが(例えば、ローリングアップグレードや再起動)、ClickHouse のバージョン変更や EKS ノードのアップグレードなどの一部はサービスに影響を及ぼす可能性があります。顧客はメンテナンスウィンドウ(例:毎週火曜日 午前1時 PDT)を指定できます。これにより、これらのアップグレードは予定された時間にのみ行われることが保証されます。
メンテナンスウィンドウは、セキュリティや脆弱性の修正には適用されません。これらはオフサイクルアップグレードとして扱われ、適切な時間を調整するために迅速なコミュニケーションが行われ、運用への影響を最小限に抑えます。
CloudFormation IAM ロール
ブートストラップ IAM ロール
ブートストラップ IAM ロールには、以下の権限があります。
- EC2 および VPC 操作: VPC および EKS クラスターのセットアップに必要です。
- S3 操作(例:
s3:CreateBucket
): ClickHouse BYOC ストレージ用のバケットを作成するために必要です。 route53:*
権限: Route 53 にレコードを設定するための外部 DNS に必要です。- IAM 操作(例:
iam:CreatePolicy
): コントローラが追加のロールを作成するために必要です(詳細は次のセクションを参照)。 - EKS 操作:
clickhouse-cloud
プレフィックスで始まるリソースに制限されています。
コントローラによって作成される追加 IAM ロール
CloudFormation によって作成された ClickHouseManagementRole
に加えて、コントローラはいくつかの追加ロールを作成します。
これらのロールは、顧客の EKS クラスター内で実行されるアプリケーションによって引き受けられます:
- ステートエクスポーターロール
- ClickHouse Cloud にサービス ヘルス情報を報告する ClickHouse コンポーネント。
- ClickHouse Cloud が所有する SQS キューに書き込むための権限が必要です。
- ロードバランサーコントローラ
- 標準の AWS ロードバランサーコントローラ。
- ClickHouse サービス用のボリュームを管理する EBS CSI コントローラ。
- 外部 DNS
- DNS 設定を Route 53 に伝播させます。
- Cert-Manager
- BYOC サービス ドメインの TLS 証明書をプロビジョニングします。
- クラスターオートスケーラー
- 必要に応じてノードグループのサイズを調整します。
K8s-control-plane および k8s-worker ロールは、AWS EKS サービスによって引き受けられることを意図しています。
最後に、data-plane-mgmt
は、ClickHouse Cloud コントロールプレーンコンポーネントが、ClickHouseCluster
や Istio 仮想サービス/ゲートウェイなどの必要なカスタムリソースを調整できるようにします。
ネットワーク境界
このセクションでは、顧客の BYOC VPC への出入りするさまざまなネットワークトラフィックを扱います:
- インバウンド: 顧客の BYOC VPC に入るトラフィック。
- アウトバウンド: 顧客の BYOC VPC から発信されるトラフィックで、外部の宛先に送信されます。
- パブリック: 公共のインターネットからアクセス可能なネットワークエンドポイント。
- プライベート: VPC ピアリング、VPC プライベートリンク、または Tailscale などのプライベート接続を介してのみアクセス可能なネットワークエンドポイント。
Istio ingress は、ClickHouse クライアントトラフィックを受け入れるために AWS NLB の背後にデプロイされています。
インバウンド、パブリック(プライベート可)
Istio ingress ゲートウェイは TLS を終了します。証明書は、CertManager によって Let's Encrypt でプロビジョニングされ、EKS クラスター内のシークレットとして保存されます。Istio と ClickHouse の間のトラフィックは、同じ VPC に存在するため、AWS によって暗号化されています。
デフォルトでは、インバウンドは IP アロウリストフィルタリングでパブリックにアクセス可能です。顧客は、VPC ピアリングを設定してプライベートにし、公共接続を無効にすることができます。IP フィルタを設定してアクセスを制限することを強く推奨します。
アクセスのトラブルシューティング
インバウンド、パブリック(プライベート可)
ClickHouse Cloud エンジニアは、Tailscale 経由でトラブルシューティングアクセスを要求します。彼らは、BYOC デプロイメントのために、ジャストインタイム証明書ベースの認証でプロビジョニングされます。
請求クレイパー
アウトバウンド、プライベート
請求クレイパーは、ClickHouse から請求データを収集し、ClickHouse Cloud が所有する S3 バケットに送信します。
それは、ClickHouse サーバーコンテナとともにサイドカーとして実行され、定期的に CPU およびメモリメトリックをスクレイピングします。同じリージョン内のリクエストは、VPC ゲートウェイサービスエンドポイントを経由します。
アラート
アウトバウンド、パブリック
AlertManager は、顧客の ClickHouse クラスターが不健全な場合に ClickHouse Cloud にアラートを送信するように設定されています。
メトリックとログは顧客の BYOC VPC 内に保存されます。ログは現在、EBS にローカルに保存されています。今後のアップデートでは、これらは BYOC VPC 内の ClickHouse サービスである LogHouse に保存されます。メトリックは、顧客の BYOC VPC にローカルに保存された Prometheus と Thanos スタックを使用します。
サービス状態
アウトバウンド
ステートエクスポーターは、ClickHouse サービス状態情報を、ClickHouse Cloud が所有する SQS に送信します。
機能
サポートされている機能
- SharedMergeTree: ClickHouse Cloud と BYOC は同じバイナリと設定を使用します。したがって、SharedMergeTree などの ClickHouse コアからのすべての機能が BYOC でサポートされています。
- サービス状態を管理するためのコンソールアクセス:
- 開始、停止、終了などの操作をサポートします。
- サービスとステータスを表示します。
- バックアップと復元。
- 手動の垂直および水平スケーリング。
- アイドル状態。
- ウェアハウス: コンピュータ・コンピュータ分離
- Tailscale を介したゼロトラストネットワーク。
- 監視:
- Cloud コンソールには、サービスの健康状態を監視するための組み込みヘルスダッシュボードが含まれています。
- Prometheus スクレイピングによる Prometheus、Grafana、Datadog との集中監視。設定手順については、Prometheus ドキュメントを参照してください。
- VPC ピアリング。
- 統合: フルリストはこちらのページを参照してください。
- セキュア S3。
- AWS PrivateLink。
計画された機能(現在サポートされていません)
- AWS KMSまたは CMEK(顧客管理暗号化キー)
- インジェスト用の ClickPipes
- オートスケーリング
- MySQL インターフェース
FAQ
コンピュート
この単一の EKS クラスターで複数のサービスを作成できますか?
はい。インフラストラクチャは、各 AWS アカウントおよびリージョンの組み合わせごとに一度だけプロビジョニングされる必要があります。
BYOC のサポートリージョンはどれですか?
BYOC は ClickHouse Cloud と同じセットの リージョン をサポートします。
リソースオーバーヘッドはありますか? ClickHouse インスタンス以外のサービスを実行するために必要なリソースは何ですか?
ClickHouse インスタンス(ClickHouse サーバーと ClickHouse Keeper)以外に、clickhouse-operator
、aws-cluster-autoscaler
、Istio などのサービスを実行し、監視スタックを管理しています。
現在、これらのワークロードを実行するために専用ノードグループ内に 3 つの m5.xlarge ノード(各 AZ に 1 つ)があります。
ネットワークとセキュリティ
セットアップ完了後にインストール時に設定した権限を取り消すことはできますか?
現状では、これは不可能です。
ClickHouse エンジニアがトラブルシューティングのために顧客インフラにアクセスするための将来のセキュリティ管理策を検討しましたか?
はい。顧客がエンジニアのクラスターへのアクセスを承認できる顧客制御メカニズムの実装は、私たちのロードマップにあります。現時点では、エンジニアはクラスターへのジャストインタイムアクセスを得るために内部エスカレーションプロセスを経る必要があります。これはログに記録され、私たちのセキュリティチームによって監査されます。
作成された VPC IP 範囲のサイズはどれくらいですか?
デフォルトでは、BYOC VPC に 10.0.0.0/16
を使用します。将来のスケーリングのために少なくとも /22 を予約することを推奨しますが、制限を希望する場合は、30 のサーバーポッドに制限される可能性がある場合は /23 を使用することも可能です。
メンテナンスの頻度を決定できますか?
メンテナンスウィンドウをスケジュールするにはサポートに連絡してください。最低でも週一回の更新スケジュールを期待してください。
可観測性
内蔵監視ツール
ClickHouse BYOC は、さまざまなユースケースに対応するいくつかのアプローチを提供します。
可観測性ダッシュボード
ClickHouse Cloud には、メモリ使用量、クエリレート、I/O などのメトリックを表示する高度な可観測性ダッシュボードが含まれています。これは ClickHouse Cloud ウェブコンソールインターフェースの 監視 セクションでアクセスできます。

高度なダッシュボード
system.metrics
、system.events
、system.asynchronous_metrics
などのシステムテーブルからのメトリックを使用して、サーバーのパフォーマンスとリソース利用状況を詳細に監視するためにダッシュボードをカスタマイズできます。

BYOC Prometheus スタックへのアクセス
ClickHouse BYOC は、Kubernetes クラスターに Prometheus スタックをデプロイします。そこからメトリックにアクセスしてスクレイピングし、自分の監視スタックと統合できます。
ClickHouse サポートに連絡して、プライベートロードバランサーを有効にし、URL をリクエストしてください。この URL はプライベートネットワーク経由でのみアクセスでき、認証はサポートしていません。
サンプル URL
Prometheus 統合
非推奨: 上記のセクションの Prometheus スタック統合を代わりに使用してください。ClickHouse Server メトリックの他に、K8S メトリックや他のサービスからのより多くのメトリックを提供します。
ClickHouse Cloud は、監視のためのメトリックをスクレイプするために使用できる Prometheus エンドポイントを提供します。これにより、Grafana や Datadog などのツールとの統合が可能になります。
HTTPS エンドポイント /metrics_all 経由のサンプルリクエスト
サンプルレスポンス
認証
ClickHouse のユーザー名とパスワードのペアを、認証に使用できます。メトリックをスクレイプするために最低限の権限を持つ専用ユーザーを作成することをお勧めします。最低限、system.custom_metrics
テーブルのレプリカ全体に対する READ
権限が必要です。例えば:
Prometheus の設定
以下に設定例を示します。targets
エンドポイントは、ClickHouse サービスにアクセスするために使用されるものと同じです。
さらに、このブログ記事および ClickHouse 用の Prometheus セットアップドキュメントも参照してください。
稼働時間 SLA
ClickHouse は BYOC に対して稼働時間 SLA を提供していますか?
いいえ、データプレーンは顧客のクラウド環境にホストされているため、サービスの可用性は ClickHouse の管理下にないリソースに依存します。したがって、ClickHouse は BYOC デプロイメントに対して正式な稼働時間 SLA を提供していません。追加の質問がある場合は、[email protected] にお問い合わせください。