Skip to main content

​
よくある質問

​
オンボーディングとプロビジョニング

お問い合わせフォームから ClickHouse までご連絡ください。チームが組織で BYOC を有効化します。その後、専用のクラウドアカウント (AWS アカウント、GCP プロジェクト、または Azure サブスクリプション) を準備し、標準オンボーディングガイドに従ってください。BYOC 専用のアカウント、プロジェクト、またはサブスクリプションを使用することを強く推奨します。
エンドツーエンドで約 45～90 分かかります。時間に幅があるのは、その大半をクラウドプロバイダーによるリソース (Kubernetes クラスター、ロードバランサー、ネットワークコンポーネント) のプロビジョニングが占め、その所要時間は実行ごとに異なり、ClickHouse では制御できないためです。プロビジョニングが停滞する場合、最も一般的な原因はアカウント側にあります。
  • CloudFormation template または Terraform module を適用前に変更した場合。たとえば、PermissionsBoundary を追加した場合や、命名規則に合わせて IAM ロール名を変更した場合です (AWS では、ClickHouse が別の名前を明示的に承認していない限り、デフォルトの ClickHouseManagementRole 名を維持してください) 。提供されたアーティファクトをそのまま適用してください。サポート対象のカスタマイズはパラメーターとして公開されており、それ以外の変更には事前に ClickHouse の承認が必要です。
  • 組織レベルのポリシー (AWS SCP、iam.allowedPolicyMemberDomains などの GCP 組織ポリシー、またはロール割り当てを制限する Azure ポリシー) により、ロールの引き受けや IAM バインディングがブロックされている場合。
  • オンボーディングロールの外部 ID が一致しない場合 (以下の外部 ID に関する質問を参照) 。
  • アカウントのクォータ制限 (たとえば、AWS の Elastic IP または VPC) 。
プロビジョニングは自動的に再試行され、根本的な問題が解決されると自己修復します。インフラストラクチャが数時間以上停滞したままの場合は、サポートにお問い合わせください。
ClickHouse Cloud コンソールでは、オンボーディングの開始時に AWS アカウント用の外部 ID が生成され、CloudFormation リンク内の ExternalID パラメーターにあらかじめ入力されます。Terraform を使用する場合は、同じ値を external_id として渡してください。同じ AWS アカウント上のすべての BYOC インフラストラクチャは、同じ外部 ID を共有します。独自の値を指定しないでください。ClickHouse の自動化が想定する値と一致している必要があり、一致しない場合はクロスアカウントロールを引き受けられず、プロビジョニングが失敗します。詳細については、AWS 外部 IDを参照してください。
外部 ID が導入される前にオンボーディングされた BYOC インフラストラクチャでは、後方互換性のためにプレースホルダー値 emptyid が使用されます。既存のレガシーデプロイメントがある AWS アカウントに新しいインフラストラクチャを追加すると、コンソールはこのプレースホルダーを再利用し、アカウント内のすべてのインフラストラクチャで一貫した信頼設定を維持します。一意の外部 ID に切り替えたい場合は、ClickHouse Support にお問い合わせください。
AWS および GCP では、BYOC インフラストラクチャと同じアカウントまたはプロジェクトにある既存の VPC にデプロイできます。AWS および GCP のカスタマイズガイドを参照してください。GCP では、別のホストプロジェクトの Shared VPC もサポートされています。オンボーディングモジュールではホストプロジェクトとサブネットを直接指定できます。セットアップと前提条件については、その「Shared VPC」セクションを参照してください。Azure で独自の VNet を使用する機能は近日提供予定です。AWS では、別のアカウントから共有されたサブネット (AWS RAM) はサポートされていません。代わりに、VPC peering または PrivateLink を介して既存のネットワークに接続された専用アカウントを使用してください。customer-managed VPC では、デフォルトで private load balancer のみが有効になることに注意してください (configurationを参照) 。
いいえ。Kubernetes クラスター (EKS、GKE、または AKS) は ClickHouse が作成し、完全に管理します。これは、ClickHouse がプラットフォームを確実に運用し、常に最新の状態に保つために必要です。
クラウドアカウント内でも可能ですが、同居するリソースは常にある程度、ClickHouse の権限範囲に含まれます。AWS では、ほとんどの書き込み権限がタグおよびプレフィックス単位でスコープ設定されています (ClickHouse によってプロビジョニングされたリソースには clickhouse-byoc=true が付与されます) 。ただし、一部の EC2 アクションはタグ単位でスコープ設定できません。GCP と Azure では、オンボーディング用の ID にプロジェクトまたはサブスクリプション単位の権限が付与されます。リソースは ClickHouse によってプロビジョニングされたリソースとは分離し、すべてのクラウドで専用のアカウント、プロジェクト、またはサブスクリプションを使用することを強く推奨します。Kubernetes クラスター内でも、制約はありますが可能です。テイントとトレランスを設定した独自のノードグループを使用し、ClickHouse 管理のネームスペースは使用せず、ClickHouse コンポーネントのリコンシリエーションを妨げる可能性があるクラスター全体に適用される admission コントローラーやポリシーエンジンはインストールしないでください。競合がないことを確認できるよう、事前にサポートへ計画をお知らせください。

​
コンピュートとスケーリング

はい。インフラストラクチャ (Kubernetes クラスターを含む) は、クラウドアカウント／プロジェクト／サブスクリプションとリージョンの組み合わせごとに一度だけプロビジョニングすればよく、そのリージョン内で作成するすべてのサービスで共有されます。
サポート対象リージョンのドキュメントに記載されているすべてのパブリックリージョンで、BYOC をデプロイできます。BYOC は 3 つのアベイラビリティゾーンにまたがってプロビジョニングされるため、ゾーンが 3 つ未満のリージョンおよび AWS Local Zones はサポートされていません。必要なリージョンが記載されていない場合は、利用可否について ClickHouse 担当者にお問い合わせください。
ClickHouse インスタンス自体 (ClickHouse server と ClickHouse Keeper) に加え、clickhouse-operator、クラスターオートスケーラー、Istio、監視スタックなどのサポートサービスも実行されます。これらの共有コンポーネントのリソース消費量は比較的安定しており、ClickHouse サービスの数やサイズに比例して増加するわけではありません。大まかな目安として、これらのワークロード専用のシステムノードグループには、合計で約 48 vCPU、192 GB のメモリが必要です。たとえば AWS では、約 6 台の 2xlarge インスタンスに相当します。さらに、各ウェアハウスでは、同じウェアハウス内のすべてのサービスで共有される専用の 3 ノード ClickHouse Keeper ensemble が実行されます。詳細はコストモデルを参照してください。
サービスレベルの (垂直) オートスケーリングはロードマップに含まれています。現在利用可能な機能は、コンソールでの手動の垂直・水平スケーリング、予測可能な負荷パターン向けのスケジュールスケーリング、断続的なワークロード向けの自動アイドル化と復帰、インフラストラクチャレベルでのノードグループの自動スケーリングです。ノードを自分で管理する必要はありません。ClickHouse Keeper は ClickHouse によって監視およびスケーリングされます。
BYOC は任意のインスタンスタイプではなく、厳選されたノードグループ上で実行されます。ワークロードノードグループ (ClickHouse server と Keeper) はデフォルトで ARM ベースのメモリ最適化インスタンス (AWS では Graviton) を使用し、システムノードグループは通常 x86 インスタンスを使用します。異なるインスタンスファミリー、CPU とメモリの比率、またはアーキテクチャは、サポートへのリクエストに応じてプロビジョニングできます。スポットインスタンスはサポートされていません。設定を参照してください。
各レプリカは、それぞれ専用ノード上の 1 つの Pod として実行されます。ノードサイズはレプリカサイズに合わせられ、ノードはオンデマンドでプロビジョニングされ、複数のレプリカが 1 つのノードに配置されることはありません。そのため、非常に小さいレプリカは非効率的です。ハードウェアに占めるオーバーヘッドの割合が大きくなり、ネットワークおよびディスク帯域幅はインスタンスサイズに応じて拡張されます。コンソールで提供されるサイズ未満のものは、サポートを通じたカスタムリクエストとなります。
はい。BYOC ではウェアハウス (コンピュート分離) がサポートされています。複数のサービスで同じデータを共有できるため、インジェスト専用のサービスとクエリ専用のサービスを割り当てることができます。

​
ネットワークとセキュリティ

AWS と GCP では、最初から付与する権限を減らせます。オンボーディングアーティファクトはパラメーター化されているため、自身の VPC を使用する場合、VPC のネットワークトポロジーを管理する権限を付与しないようにできます (CloudFormation では IncludeVPCWritePermissions、Terraform モジュールでは include_vpc_write_permissions) 。GCP では、制限されるのはトポロジー管理のみです。ClickHouse は、Private Service Connect NAT サブネット、サービスアタッチメント、イングレスアドレスなど、VPC 内で所有するネットワーキングリソースへの書き込みアクセスを維持します。AWS ではさらに、サポートを通じて有効化されるプライベートプレビューで、IAM ロールを自身で管理できます (IncludeIAMWritePermissions=false、顧客管理 IAM ロールを参照) 。また、クロスアカウントロールは、混乱した代理人問題によるアクセスを防ぐため、外部 ID で保護されています。Azure では、オンボーディングモジュールは現時点で、スコープ設定パラメーターのない固定のサブスクリプションスコープのロールを付与します。すべてのクラウドにおいて、一部の権限は特定の機能でのみ必要であり、その機能を使用しない場合は削除できます。アーティファクトで指定可能な範囲を超えて権限を制限する必要がある場合は、サポートにお問い合わせください。プロビジョニング後は、管理アイデンティティから一方的に権限を削除しないでください。ClickHouse はインフラストラクチャを継続的に整合させているため、権限が不足するとプロビジョニング、アップグレード、サポートに支障が生じます。付与済みの権限を変更する場合や完全にオフボードする場合は、サポートと調整してください (下記の廃止に関する質問を参照) 。
権限リファレンスでは、AWS、GCP、Azure におけるすべてのロールとアイデンティティ、およびその目的の概要を確認できます。オンボーディング (ブートストラップ) アイデンティティについては、正確なポリシー範囲が公開アーティファクト、すなわち CloudFormation template と Terraform modulesによって定義されており、セキュリティチームが直接監査できます。オンボーディング後に ClickHouse が作成する追加のアイデンティティ (コントローラーロール、サービスアカウント、マネージドアイデンティティ) は、権限リファレンスでクラウドプロバイダーごとに説明されています。これらはお客様のアカウント内に存在するため、クラウドコンソールで実際のポリシーを確認し、CloudTrail または GCP/Azure の同等のサービスで作成および使用状況を確認できます。AWS では、管理ロールの書き込み権限の大半は、clickhouse-cloud-* などのリソースタグと名前プレフィックスでスコープ設定されているため、通常は自身が作成していないリソースを変更できません (一部の EC2 アクションはタグでスコープ設定できません) 。また、お客様のデータバケットに対するオブジェクトレベルのアクセス権はありません。オブジェクトへのアクセスは、ClickHouse ワークロードにスコープ設定されたクラスター内アイデンティティに限定されます。GCP と Azure では、オンボーディングアイデンティティが代わりにプロジェクトまたはサブスクリプションスコープの権限を保持します。このため、専用のプロジェクトまたはサブスクリプションを強く推奨しています。継続的な整合性維持に必要なため、読み取り権限の範囲はより広くなります。
デフォルトでは、お客様のデータには一切アクセスできません。トラブルシューティングのため、エンジニアは内部のジャストインタイム・エスカレーションプロセスを経る必要があります。アクセスは期間限定かつ証明書ベースで、system.* テーブル (顧客データテーブルを除く) に限定され、ログに記録され、セキュリティチームによって監査されます。ClickHouse のエンジニアが実行するクエリはすべて、お客様自身の system.query_log で確認できます。インフラストラクチャの診断では、同じく承認を要するエスカレーションにより、Tailscale 経由で Kubernetes API server およびクラスター内の監視スタックへの期間限定アクセスを付与することもできます。データアクセスモデルについては ClickHouse data access、接続モデルについては ネットワークセキュリティを参照してください。
はい。お客様がエンジニアによるクラスターへのアクセスを承認できる、お客様管理の仕組みの実装はロードマップに含まれています。現在、エンジニアはクラスターへのジャストインタイムアクセスを取得するために、内部エスカレーションプロセスを経る必要があります。これはログに記録され、セキュリティチームによって監査されます。
送信されるのは運用メタデータのみです。サービスおよびバックアップの状態イベント、請求用の使用量メトリクス、アラート通知が該当します。お客様のデータ、バックアップ、ログ、監視データは、お客様のアカウント内に保持されます。送信フローの完全な一覧については、ネットワークセキュリティを参照してください。
デフォルトでは、Kubernetes API エンドポイントはパブリックですが、ClickHouse の NAT IP アドレスのみに制限されています。このデフォルト設定を使用している間は、コントロールプレーンによるクラスター管理に必要なため、ClickHouse の許可リストエントリを削除しないでください。代わりに、ClickHouse チームと調整のうえ、エンドポイントをプライベートアクセス専用に切り替えることもできます。Tailscale (アウトバウンド専用で、トラブルシューティングアクセスにも使用) または AWS では VPC Lattice (プライベートプレビュー) を使用します。詳細は configuration を参照してください。これは Kubernetes API にのみ適用される点に注意してください。クラウドプロバイダー API 呼び出し (たとえば AWS の EKS や EC2) は、クロスアカウントでのロール引き受けを通じて ClickHouse Cloud のネットワークから発信されるため、Tailscale 経由でルーティングすることはできません。詳細は cloud provider APIs vs the Kubernetes API を参照してください。
AWS では、Customer BYOC VPC と S3 間のテーブルデータ、バックアップ、ログのトラフィックは、AWS S3 API 経由で HTTPS (ポート 443) を使用します。このトラフィックは S3 ゲートウェイ VPC エンドポイントを経由するため、AWS ネットワーク内に留まり、パブリックインターネットを通過せず、NAT ゲートウェイ料金も発生しません。GCP では、Google API へのアクセスにも同様に Private Google Access を使用します。Azure では、データはお客様のサブスクリプション内の Azure Blob Storage アカウントに保存されます。
いいえ。テーブルデータのブロブはテーブルごとのパスを持たない共有レイアウトで保存されるため、オブジェクトをテーブルに対応付けることはできず、直接変更するとサービスが破損するおそれがあります。bucket の内容は絶対に直接変更しないでください。問題が疑われる場合は、サポートチケットを起票してください。
クライアント接続は、TLS ポート上のロードバランサーで終端されます。8443 (HTTPS インターフェイス) および 9440 (TLS 経由のネイティブプロトコル) です。ポート 443 も HTTPS インターフェイスにルーティングされます。MySQL インターフェイス (ポート 3306) は現在 BYOC では公開されていません。ロードマップに含まれています (概要 を参照) 。ネットワーク内では、クラスター内通信にポート 9000 のネイティブプロトコル、ポート 8123 の HTTP、レプリケーションおよび分散クエリ用のポート 9009 のサーバー間通信を使用します。これらの内部ポートおよび ClickHouse Keeper のポートがロードバランサーで公開されることはありません。
ClickHouse 管理 VPC では、各サービスに IP アクセスリストで保護されたパブリックロードバランサーがデフォルトで割り当てられます。お客様のネットワークおよびピアリングされたネットワークから到達可能なプライベートロードバランサーは、ClickHouse Cloud コンソールで追加で有効にできます (Load Balancers を参照) 。customer-managed VPC ではデフォルトが逆になり、プライベートロードバランサーのみが有効になります。IP フィルタリングはイングレスプロキシ層で適用されるため、スキャンではロードバランサーのポートが開いているように見える場合がありますが、リストにない送信元からの接続は拒否されます。依存先がなくなれば、パブリックエンドポイントを完全に無効にできます。コンソールの Connection via selector には、サービスで有効な各接続経路のエンドポイントが表示されます。connectivity を参照してください。
現時点ではできません。サービスエンドポイントは、ClickHouse 管理の証明書とともに clickhouse-byoc.com 配下にプロビジョニングされます。
公開された単一のエンドポイントリストはありません。クラスターには、クラウドプロバイダー API へのプライベートアクセスに加え、正常に機能するアウトバウンドインターネットアクセス (直接または NAT 経由) が必要です。詳細は、ネットワーク接続要件を参照してください。ネットワークポリシーで明示的な一覧が必要な場合は、サポートに連絡して設定を確認してください。
EBS CSI ドライバー、ノード設定ジョブ、Prometheus node exporter (/proc および /sys を読み取ります) など、一部のプラットフォームコンポーネントには、正当な理由から昇格された権限またはホストファイルシステムへのアクセスが必要です。スキャナーで検出事項が報告された場合は、サポートに共有してください。各項目が仕様によるものか、対応が必要かを確認します。
現在、BYOC ではサポートされていません。保存データはクラウドプロバイダー管理のキーで暗号化されます。現在予定されている機能の一覧については、概要を参照してください。

​
アップグレードとメンテナンス

アップグレードはClickHouse Cloudと同様に行われます。サービスはリリースチャネル (fast、regular、slow) に登録され、スケジュールされたメンテナンスウィンドウに従います。設定についてはサポートにお問い合わせください。更新は最低でも週1回のスケジュールとなります。アップグレードはローリング方式で、レプリカごとに (make-before-break) 実行されるため、サービス全体のダウンタイムは発生しません。操作を参照してください。
ClickHouseは、プロバイダーのサポート終了日より前にKubernetesのアップグレードを先行して実施し、サポートを通じてお客様と実施時間帯を調整します。コントロールプレーンのアップグレードは透過的に行われます。ノードグループのアップグレードでは、make-before-break方式でノードを1台ずつローリング更新するため、ポッドの再起動に伴い短時間の接続リセットが発生する場合がありますが、データ損失はありません。操作を参照してください。

​
バックアップと災害復旧

お客様のクラウドアカウント内のオブジェクトストレージに保存されます。バックアップが環境外に出ることはありません。バックアップスケジュールと保持期間は設定可能です。調整についてはサポートにお問い合わせください。
ユーザーが作成したすべてのデータベース、テーブル、オブジェクトに加え、アクセスエンティティ (ユーザー、ロール、設定プロファイル、行ポリシー、クォータ) およびユーザー定義関数が含まれます。system.query_log などのシステムログテーブルは含まれません。
バックアップはチェーンを構成します。完全バックアップの後に、そのバックアップに依存するインクリメンタルバックアップが続きます。チェーン内のインクリメンタルバックアップを復元するにはベースとなる完全バックアップが必要なため、依存するすべてのインクリメンタルバックアップが保持期間を過ぎるまで、完全バックアップも保持・保存されます。
方法は2つあります。ClickHouse Cloud API のバックアップエンドポイントと、クラスター内の監視スタックで公開されるバックアップメトリクス (開始、完了、失敗のカウンター) です。独自の監視で失敗に対するアラートを設定することを推奨します。オブザーバビリティを参照してください。
BYOC は3つのアベイラビリティゾーンにまたがってデプロイされ、書き込みはオブジェクトストレージによる確認後にのみ確認応答されます。現時点ではクロスリージョンレプリケーションは利用できないため、リージョンレベルの災害復旧はバックアップに基づいて行われ、達成可能な RPO はバックアップ頻度によって決まります。別のリージョンのバケットへのバックアップを含め、目標に合わせてバックアップ頻度と宛先を設定できます。設定についてはサポートにお問い合わせください。

​
オブザーバビリティ

監視スタック (Prometheus、Grafana、AlertManager) はお客様のアカウント内で稼働しており、private connectivity 経由で直接利用できます。PromQL API 経由でクエリを実行したり、自社の Prometheus にフェデレーションしたり、サービスごとに ClickHouse の /metrics_all エンドポイントをスクレイプしたりできます。現時点では、Datadog などのサードパーティプラットフォーム向けのすぐに利用できるインテグレーションはありません。各プラットフォームの Prometheus 互換インジェストを介して統合してください。エンドポイントとセットアップについては、オブザーバビリティを参照してください。

​
コスト

請求は2つに分かれます。ClickHouse Cloud はサービスに割り当てられたメモリに基づいて課金し、クラウドプロバイダーは基盤となるインフラストラクチャの実費を上乗せなしで直接請求します。現在、詳細なコストリファレンスは AWS のみを対象としています。コストモデル、課金対象の AWS サービス、AWS サービス制限を参照してください。

​
可用性とライフサイクル

AWS、GCP、Azure はすべて一般提供されています。各クラウドでサポートされている機能とリージョンについては、概要を参照してください。
ClickHouse コンソールからサービスと BYOC インフラストラクチャを終了してください。クラウドプロバイダーのコンソールでリソースを削除したり、権限を取り消したりすることから始めないでください。処理の途中でコントロールプレーンとの接続が切断され、手動でのクリーンアップが必要になります。コンソールからの終了処理が完了したら、オンボーディングスタック (CloudFormation stack または Terraform module) と残存するリソースをすべて削除します。AWS では、ClickHouse が作成したすべてのリソースに clickhouse-byoc=true タグが付けられているため、後で列挙して何も残っていないことを確認できます。GCP と Azure では、オンボーディング時に使用した専用のプロジェクトまたはサブスクリプションが、確認対象の範囲を限定します。

​
アップタイム SLA

いいえ。データプレーンはお客様のクラウド環境でホストされるため、サービスの可用性は ClickHouse の管理下にないリソースに左右されます。そのため、ClickHouse は BYOC デプロイメントに対する正式なアップタイム SLA を提供していません。稼働中のサービスは ClickHouse コントロールプレーンとは独立して動作します。コントロールプレーンで障害が発生しても、お客様のアカウントで稼働中のサービスが停止することはありません。ご不明な点があれば、support@clickhouse.com までお問い合わせください。
最終更新日 2026年8月14日