インフラストラクチャ構成
このページでは、BYOC デプロイメントで利用可能な各種インフラストラクチャ構成オプションについて説明します。これらの構成により、特定の要件を満たすために、ネットワーク、セキュリティ、およびコンピュートリソースをカスタマイズできます。
ロードバランサー
BYOC デプロイメントでは、Network Load Balancer (NLB) を使用して ClickHouse サービスへのトラフィックを管理およびルーティングします。ネットワーク構成に応じて、パブリック または プライベート のロードバランサーエンドポイントを選択できます。
| Load Balancer Type | ClickHouse-managed Dedicated VPC | Customer-managed VPC |
|---|---|---|
| Public NLB | デフォルトで有効 | デフォルトで無効 |
| Private NLB | デフォルトで無効 | デフォルトで有効 |
Public Load Balancer:
- ClickHouse サービスへのパブリック (インターネット向け) アクセスを提供します。
- ClickHouse-managed dedicated VPC を使用している場合、通常はデフォルトで有効です。
- セキュリティ強化のため、customer-managed VPC を使用している場合はデフォルトで無効です。
Private Load Balancer:
- 接続されているネットワーク内からのみアクセス可能な、プライベート (内部) アクセスを提供します。
- customer-managed VPC を使用している場合、通常はデフォルトで有効です。
- ClickHouse-managed dedicated VPC を使用している場合はデフォルトで無効です。
要件に応じてどのエンドポイントを有効化するかを調整するには、ClickHouse Cloud Support にお問い合わせください。
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 を利用できます。これらのオプションにより、VPC ピアリングやエンドポイントをパブリックインターネットに公開することなく、アプリケーションから ClickHouse Cloud サービスへプライベートに接続できます。
セットアップ手順の詳細については、プライベートネットワーク設定ガイド を参照してください。
Kubernetes API プライベート接続
デフォルトでは、BYOC クラスターの Kubernetes API サーバーエンドポイントはパブリックインターネットから到達可能ですが、ClickHouse NAT Gateway の IP のみを許可する IP フィルタリングによってアクセスが制限されています。セキュリティをさらに強化するには、Tailscale を使用してプライベートネットワーク接続経由でのみアクセスできるよう、Kubernetes API サーバーを制限できます。
プライベート接続を Tailscale のみに依存している場合、Tailscale エージェントが利用不能になると、ClickHouse Support がお客様の環境へのアクセスを失うリスクがあります。これにより、トラブルシューティングやサポート対応が遅れる可能性があります。
プライベート API エンドポイントの設定を依頼するには、ClickHouse Support に連絡してください。
ノードグループ
Kubernetes のノードグループは、BYOC デプロイメントで ClickHouse サービスを実行するために必要なリソースを提供するコンピュートインスタンスの集合です。ClickHouse Cloud はこれらのノードグループを管理し、その設定とスケーリングを自動的に行います。
既定の構成
BYOC クラスターには、2 つの主要なノードグループタイプがプロビジョニングされます:
-
System Node Group
ClickHouse Operator、Istio（サービスメッシュ用）、監視コンポーネント（Prometheus、Grafana、AlertManager）、Cluster Autoscaler およびその他のコアサービスなど、重要なシステムワークロードをホストします。これらのノードは通常、標準的な x86 インスタンスタイプを使用します。 -
Workload Node Groups
サーバーおよび Keeper サービスを含む ClickHouse のデータワークロード専用です。既定では、ワークロードノードは ARM ベースのインスタンス上で動作し、パフォーマンスとコストのバランスに優れた高い効率を提供します。ただし、異なる CPU/メモリプロファイルを使用するように構成したり、リクエストに応じて x86 アーキテクチャに切り替えることもできます。
ノードグループのカスタマイズ
専用のリソースやアーキテクチャが必要ですか？ 以下のようなカスタマイズが可能です。要件の検討や実施については ClickHouse Support までお問い合わせください。
- インスタンスタイプの選択
パフォーマンス、コンプライアンス、大容量メモリ/CPU、あるいは予約済みリソースの活用といった要件を満たすために、特定のインスタンスタイプを選択できます。 - CPU/メモリ比
ワークロード用ノードグループのコンピュートプロファイルを、必要に応じて調整できます。 - アーキテクチャ
必要に応じて、ワークロード用ノードグループを ARM から x86 に切り替えることができます。
注: Spot（プリエンプティブル）インスタンスはサポートされていません。すべての BYOC ノードグループは、デフォルトでオンデマンドインスタンス上で動作します。
すべてのノードグループのカスタマイズおよび設定変更は、ClickHouse Support を通じて調整する必要があります。これにより、互換性、安定性、および最適なパフォーマンスを確保できます。
自動スケーリング
クラスターのノードグループは、クラスターオートスケーラーによって、次の条件に基づき自動的にスケールします。
- ポッドのリソース要求と制限
- クラスター全体のキャパシティと利用率
- ClickHouse サービスのスケーリング要件
手動での対応は不要です。ClickHouse Cloud が、デプロイメントに対する継続的なリソースおよびスケーリング管理を行います。
