インフラストラクチャ設定

このページでは、BYOC デプロイメントで利用できる各種インフラストラクチャ設定オプションについて説明します。これらの設定により、要件に応じてネットワーク、セキュリティ、コンピュートリソースをカスタマイズできます。 BYOC デプロイメントでは、Network Load Balancers (NLBs) を使用して、ClickHouse サービスへのトラフィックを管理・ルーティングします。ネットワーク構成に応じて、パブリック または プライベート のロードバランサーエンドポイントを選択できます。 パブリックロードバランサー:

• ClickHouse サービスへのパブリック (インターネット向け) アクセスを提供します。
• 通常、ClickHouse 管理の専用 VPC を使用する場合はデフォルトで有効になります。
• セキュリティを強化するため、顧客管理 VPC を使用する場合はデフォルトで無効になります。

プライベートロードバランサー:

• プライベート (内部) アクセスを提供し、接続されたネットワーク内からのみアクセスできます。
• 通常、顧客管理 VPC を使用する場合はデフォルトで有効になります。
• 通常、ClickHouse 管理の専用 VPC を使用する場合はデフォルトで無効になります。

要件に応じて有効にするエンドポイントは、ClickHouse Cloud Support と連携して調整できます。 BYOC デプロイメントでプライベートロードバランサーを使用する場合は、想定しているプライベートネットワーク (ピアリングされた VPC など) からのアクセスを許可するため、適切なセキュリティグループルールが設定されていることを確認する必要があります。デフォルトでは、このセキュリティグループは VPC 内からのトラフィックのみを許可します。 プライベートロードバランサーのセキュリティグループを設定するには、次の対応を行ってください。 ClickHouse Support に連絡して、特定の送信元ネットワークからのトラフィックを許可する受信セキュリティグループルールへの変更を依頼してください。

• VPC Peering: ピアリングされた VPC の CIDR 範囲からのトラフィックを許可するルールを依頼してください。
• PrivateLink: トラフィックはロードバランサーのセキュリティグループの制御対象ではないため、セキュリティグループの変更は不要です。
• その他のネットワーク構成: ご利用の構成を伝えてください。状況に応じてサポートが対応します。

ネットワーク分離とセキュリティを最大限に高めるため、BYOC デプロイでは AWS PrivateLink または GCP Private Service Connect を利用できます。これらのオプションを使用すると、VPC peering を必要とせず、エンドポイントをパブリックインターネットに公開することなく、アプリケーションから ClickHouse Cloud サービスにプライベート接続できます。 手順を追ったセットアップについては、Private Networking Setup guideを参照してください。 デフォルトでは、BYOC クラスターの Kubernetes API サーバーのエンドポイントはパブリックインターネットからアクセス可能ですが、IP フィルタリングにより、ClickHouse NAT ゲートウェイの IP からのアクセスのみに制限されています。より強固なセキュリティを実現するには、Kubernetes API サーバーを、プライベートネットワーク接続経由でのみアクセスできるように制限できます。 利用可能なプライベート接続オプションは 2 つあります: プライベート API エンドポイントが有効になっている場合、ClickHouse 管理サービスは、トラブルシューティングアクセスに使用されるものと同じ Tailscale のゼロトラストネットワークを介して Kubernetes API サーバーに接続します。この接続の仕組みの詳細については、Tailscale Private Network を参照してください。 AWS のデプロイメントでは、サードパーティ製コンポーネントを使わずに、AWS VPC Lattice 経由で Kubernetes API サーバーにプライベート接続することもできます。

• 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 はトラブルシューティングのためのアクセスを維持できます。

プライベート API エンドポイントの設定を依頼するには、ClickHouse Support にお問い合わせください。 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 サービス のスケーリング要件

手動での対応は不要です。デプロイメントにおける継続的なリソース管理とスケーリング管理は、ClickHouse Cloud が行います。