ロードバランサー
BYOC デプロイメントでは、Network Load Balancers (NLBs) を使用して、ClickHouse サービスへのトラフィックを管理・ルーティングします。ネットワーク構成に応じて、パブリック または プライベート のロードバランサーエンドポイントを選択できます。
パブリックロードバランサー:
- ClickHouse サービスへのパブリック (インターネット向け) アクセスを提供します。
- 通常、ClickHouse 管理の専用 VPC を使用する場合はデフォルトで有効になります。
- セキュリティを強化するため、顧客管理 VPC を使用する場合はデフォルトで無効になります。
- プライベート (内部) アクセスを提供し、接続されたネットワーク内からのみアクセスできます。
- 通常、顧客管理 VPC を使用する場合はデフォルトで有効になります。
- 通常、ClickHouse 管理の専用 VPC を使用する場合はデフォルトで無効になります。
AWS のプライベートロードバランサーのセキュリティグループ
BYOC デプロイメントでプライベートロードバランサーを使用する場合は、想定しているプライベートネットワーク (ピアリングされた VPC など) からのアクセスを許可するため、適切なセキュリティグループルールが設定されていることを確認する必要があります。デフォルトでは、このセキュリティグループは VPC 内からのトラフィックのみを許可します。 プライベートロードバランサーのセキュリティグループを設定するには、次の対応を行ってください。 ClickHouse Support に連絡して、特定の送信元ネットワークからのトラフィックを許可する受信セキュリティグループルールへの変更を依頼してください。- VPC Peering: ピアリングされた VPC の CIDR 範囲からのトラフィックを許可するルールを依頼してください。
- PrivateLink: トラフィックはロードバランサーのセキュリティグループの制御対象ではないため、セキュリティグループの変更は不要です。
- その他のネットワーク構成: ご利用の構成を伝えてください。状況に応じてサポートが対応します。
プライベートロードバランサーのセキュリティグループに対する変更は、すべて ClickHouse Support が実施する必要があります。これにより、設定の一貫性が確保され、ClickHouse Cloud 管理環境内での競合を回避できます。
PrivateLink、Private Service Connect、または プライベートリンク
ネットワーク分離とセキュリティを最大限に高めるため、BYOC デプロイでは AWS PrivateLink、GCP Private Service Connect、または Azure プライベートリンク を利用できます。これらのオプションを使用すると、VPC/VNet peering を必要とせず、エンドポイントをパブリックインターネットに公開することなく、アプリケーションから ClickHouse Cloud サービスにプライベート接続できます。 手順を追ったセットアップについては、Private Networking Setup guideを参照してください。Kubernetes API のプライベート接続
デフォルトでは、BYOC クラスターの Kubernetes API サーバーのエンドポイントはパブリックインターネットからアクセス可能です。AWS では、IP フィルタリングにより、ClickHouse NAT ゲートウェイの IP からのアクセスのみに制限されています。GCP と Azure では、代わりにクラウドの IAM によって制御されます (Kubernetes API サーバーの公開を参照) 。より強固なセキュリティを実現するには、Kubernetes API サーバーを、プライベートネットワーク接続経由でのみアクセスできるように制限できます。 利用可能なプライベート接続オプションは、クラウドプロバイダーによって異なります:Tailscale (デフォルト)
プライベート API エンドポイントが有効になっている場合、ClickHouse 管理サービスは、トラブルシューティングアクセスに使用されるものと同じ Tailscale のゼロトラストネットワークを介して Kubernetes API サーバーに接続します。この接続の仕組みの詳細については、Tailscale Private Network を参照してください。プライベート接続を Tailscale のみに依存している場合、Tailscale エージェントが利用できなくなると、ClickHouse Support がお使いの環境にアクセスできなくなるリスクがあります。その結果、トラブルシューティングやサポート対応に時間がかかる可能性があります。
AWS VPC Lattice
VPC Lattice 接続は現在プライベートプレビューです。お使いのデプロイメントで有効にするには、ClickHouse Support にお問い合わせください。
- ClickHouse Cloud は、BYOC VPC 内の EKS API サーバーのエンドポイントを対象とする VPC Lattice Resource Gateway と Resource Configuration を自動的にプロビジョニングし、AWS Resource Access Manager (RAM) を通じて、その Resource Configuration を ClickHouse Cloud の管理アカウントと共有します。
- ClickHouse の管理サービスとお使いの Kubernetes API サーバーとの間のトラフィックは、すべて AWS のプライベートネットワーク内にとどまります。
- RAM 共有はお使いのアカウントから作成され、単一の BYOC クラスターに限定されます。これを削除すると、プライベートアクセス経路はただちに無効になります。
- Kubernetes クラスター内で動作するエージェントにアクセスが依存しないため、クラスター内コンポーネントが利用できない場合でも、ClickHouse Support はトラブルシューティングのためのアクセスを維持できます。
GCP のプライベートコントロールプレーンエンドポイント
GCP へのデプロイメントでは、GKE クラスターの IP ベースのコントロールプレーンエンドポイントを無効化して、パブリックインターネットから到達できないようにできます。この場合、ClickHouse の管理サービスは DNS ベースのエンドポイント (*.gke.goog) 経由でコントロールプレーンにアクセスします。このアクセスは、送信元 IP の許可リストではなく、お客様のプロジェクト内で ClickHouse が借用する service account に付与された container.clusters.connect IAM 権限によって承認されます。
- アクセスは完全にお客様のプロジェクト内のクラウド IAM によって管理されるため、その権限を取り消せば、このアクセスパスも無効になります。
- リクエストはお客様の VPC ネットワーク内ではなく Google のフロントエンドで終端されます。そのため、ネットワーク的にプライベートな接続としてではなく、コントロールプレーンへのアクセスパスの一つとして評価してください。
- ClickHouse エンジニアによるトラブルシューティングアクセスには、引き続き Tailscale を使用します。
Azure プライベートリンク
Azure 上のデプロイメントでは、Azure プライベートリンク を介して AKS API サーバーにプライベートに接続できます。- クラスターは API Server VNet Integration を有効にしたプライベートクラスターとして作成され、パブリック FQDN は無効化されます。
- ClickHouse Cloud は、お客様のサブスクリプション内で API サーバーの内部ロードバランサーの前段に Private Link Service をプロビジョニングし、あわせて ClickHouse Cloud の管理用 VNet 内に対応するプライベート エンドポイントを作成します。この接続が自動承認されるのは、ClickHouse Cloud の管理用サブスクリプションからの接続に限られます。
- ClickHouse の管理サービスとお客様の API サーバー間のトラフィックは、Azure のバックボーンネットワーク内で完結します。
- ClickHouse エンジニアによるトラブルシューティングアクセスには、引き続き Tailscale を使用します。
ノードグループ
Kubernetes のノードグループは、BYOC デプロイメントで ClickHouse サービスを実行するために必要なリソースを提供するコンピュートインスタンスの集まりです。ClickHouse Cloud はこれらのノードグループを管理し、設定とスケーリングを自動的に行います。デフォルト設定
BYOCクラスターは、2種類の主要なノードグループでプロビジョニングされます。- システムノードグループ ClickHouse Operator、Istio (サービスメッシュ用) 、監視コンポーネント (Prometheus、Grafana、AlertManager) 、クラスターオートスケーラー、そのほかの中核サービスなど、重要なシステムワークロードをホストします。これらのノードでは通常、標準的な x86 のインスタンスタイプが使用されます。
- ワークロードノードグループ server や Keeper サービスを含む、ClickHouse のデータワークロード専用のノードグループです。デフォルトでは、ワークロードノードは ARM ベースのインスタンス上で稼働し、パフォーマンスとコスト効率のバランスに優れています。ただし、別の CPU/メモリプロファイルを指定したり、要望に応じて x86 アーキテクチャに切り替えたりすることもできます。
ノードグループのカスタマイズ
特殊なリソースやアーキテクチャが必要な場合は、以下のカスタマイズに対応できます。ご相談や導入については、ClickHouse Support までお問い合わせください。- インスタンスタイプの選択 パフォーマンス、コンプライアンス、高メモリ/CPU、予約済みリソースの活用などの要件に合わせて、特定のインスタンスタイプを選択できます。
- CPU/メモリ比率 必要に応じて、ワークロードノードグループのコンピュートプロファイルを調整できます。
- アーキテクチャ 必要に応じて、ワークロードノードグループのアーキテクチャを ARM から x86 に切り替えられます。
注: Spot (プリエンプト可能) インスタンスはサポートされていません。すべての BYOC ノードグループは、デフォルトでオンデマンドインスタンス上で実行されます。
ノードグループのカスタマイズや設定変更は、すべて ClickHouse Support と連携して実施する必要があります。これにより、互換性、安定性、最適なパフォーマンスを確保できます。
自動スケーリング
クラスターのノードグループは、クラスターオートスケーラーによって、次の要素に基づいて自動的にスケールされます。- ポッドのリソースリクエストと上限
- クラスター全体の容量と使用率
- ClickHouse サービス のスケーリング要件