AWS向けBYOC（Bring Your Own Cloud）
概要
BYOC (Bring Your Own Cloud) は、独自のクラウドインフラストラクチャにClickHouse Cloudをデプロイできるようにします。これは、ClickHouse Cloudのマネージドサービスを利用できない特定の要件や制約がある場合に便利です。
アクセスをご希望の場合は、お問い合わせください。 詳細については、利用規約を参照してください。
BYOCは現在、AWSのみでサポートされており、GCPとMicrosoft Azureは開発中です。
BYOCは大規模なデプロイメント専用に設計されており、顧客には契約の締結が求められます。
用語集
- ClickHouse VPC: ClickHouse Cloudが所有するVPC。
- Customer BYOC VPC: 顧客のクラウドアカウントに属し、ClickHouse Cloudによってプロビジョニングおよび管理される、ClickHouse Cloud BYOCデプロイメント専用のVPC。
- Customer VPC: 顧客のクラウドアカウントによって所有され、Customer BYOC VPCに接続する必要があるアプリケーション用のその他のVPC。
アーキテクチャ
メトリクスとログは顧客のBYOC VPC内に保存されます。ログは現在、EBSにローカル保存されています。将来のアップデートでは、ログは顧客のBYOC VPC内のClickHouseサービスであるLogHouseに保存される予定です。メトリクスは、顧客のBYOC VPC内にローカルに保存されたPrometheusとThanosスタックを経由して実装されています。
オンボーディングプロセス
顧客は、私たちに連絡することで、オンボーディングプロセスを開始できます。顧客は、専用のAWSアカウントを持ち、使用するリージョンを把握している必要があります。現在のところ、BYOCサービスは、ClickHouse Cloudでサポートされているリージョンでのみ立ち上げることが許可されています。
専用AWSアカウントの準備
顧客は、ClickHouse BYOCデプロイメントをホスティングするための専用のAWSアカウントを準備する必要があります。これにより、より良い分離が保証されます。この情報と初期の組織管理者のメールがあれば、ClickHouseサポートに連絡できます。
CloudFormationテンプレートの適用
BYOCセットアップは、CloudFormationスタックを通じて初期化され、BYOCコントローラーをClickHouse Cloudからインフラストラクチャを管理するための役割を作成します。ClickHouseを実行するためのS3、VPC、およびコンピュートリソースはこのスタックには含まれていません。
BYOCインフラストラクチャのセットアップ
CloudFormationスタックを作成した後、クラウドコンソールからS3、VPC、およびEKSクラスターなどのインフラストラクチャをセットアップするように促されます。この段階で特定の設定が決定される必要があります。なぜなら、後で変更することはできないからです。具体的には：
- 使用したいリージョン: ClickHouse Cloudの公開リージョンのいずれかを選択できます。
- BYOCのVPC CIDR範囲: デフォルトでは、BYOC VPC CIDR範囲に
10.0.0.0/16が使用されます。他のアカウントでVPCピアリングを使用する予定がある場合は、CIDR範囲が重複しないようにしてください。BYOC用に適切なCIDR範囲を割り当て、必要な作業負荷を収容できるように最小サイズを/22にしてください。 - BYOC VPCのアベイラビリティゾーン: VPCピアリングを使用する予定がある場合は、ソースおよびBYOCアカウント間でアベイラビリティゾーンを一致させることで、AZ間のトラフィックコストを削減できます。AWSでは、アベイラビリティゾーンのサフィックス（
a, b, c）はアカウントにより異なる物理ゾーンIDを表す場合があります。詳しくはAWSガイドを参照してください。
オプション: 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を検索します。プライベートサブネットに接続されている各ルートテーブルを編集します。
- ルートタブの下で編集ボタンをクリックします。
- もう一つのルートを追加をクリックします。
- ターゲットVPCのCIDR範囲を宛先として入力します。
- ターゲットとして「ピア接続」を選択し、ピア接続のIDを指定します。
ステップ5 ターゲットVPCのルートテーブルに宛先を追加する
ピアAWSアカウントで、
- VPCダッシュボードのルートテーブルを選択します。
- ターゲットVPC IDを検索します。
- ルートタブの下で編集ボタンをクリックします。
- もう一つのルートを追加をクリックします。
- ClickHouse VPCのCIDR範囲を宛先として入力します。
- ターゲットとして「ピア接続」を選択し、ピア接続のIDを指定します。
ステップ6 セキュリティグループを編集してピアVPCアクセスを許可する
ClickHouse BYOCアカウントで、
- ClickHouse BYOCアカウントで、EC2に移動し、infra-xx-xxx-ingress-privateの名前のプライベートロードバランサーを見つけます。
- 詳細ページのセキュリティタブの下で、名前のパターンが
k8s-istioing-istioing-xxxxxxxxxの関連セキュリティグループを見つけます。
- このセキュリティグループのインバウンドルールを編集し、ピアVPC CIDR範囲（または必要に応じて必要なCIDR範囲）を追加します。
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 Operator、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のコンポーネントで、サービスのヘルス情報をClickHouse Cloudに報告します。
- ClickHouse Cloudが所有するSQSキューへの書き込み権限が必要です。
- ロードバランサーコントローラー
- 標準のAWSロードバランサーコントローラー。
- ClickHouseサービスのボリュームを管理するためのEBS CSIコントローラー。
- External-DNS
- Route 53へのDNS設定を伝播します。
- Cert-Manager
- BYOCサービスドメイン向けのTLS証明書を準備します。
- Cluster Autoscaler
- 必要に応じてノードグループのサイズを調整します。
K8s-control-planeおよびk8s-workerロールは、AWS EKSサービスによって引き受けられます。
最後に、**data-plane-mgmt**は、ClickHouse CloudコントロールプレーンコンポーネントがClickHouseClusterやIstio Virtual Service/Gatewayなどの必要なカスタムリソースを調整できるようにします。
ネットワーク境界
このセクションでは、顧客BYOC VPCへの入出力トラフィックをカバーします：
- インバウンド: 顧客BYOC VPCに入るトラフィック。
- アウトバウンド: 顧客BYOC VPCから発生し、外部に送信されるトラフィック。
- パブリック: 公開インターネットからアクセスできるネットワークエンドポイント。
- プライベート: VPCピアリング、VPCプライベートリンク、またはTailscaleのようなプライベート接続を介してのみアクセス可能なネットワークエンドポイント。
Istioのインバウンドは、ClickHouseクライアントトラフィックを受け入れるためにAWS NLBの背後にデプロイされます。
インバウンド、パブリック（プライベートである可能性あり）
IstioインバウンドゲートウェイはTLSを終了します。CertManagerによりLet's Encryptから提供された証明書は、EKSクラスター内のシークレットとして保存されます。IstioとClickHouse間のトラフィックは、AWSによって暗号化されていますこれは、同じVPC内にあるためです。
デフォルトでは、インバウンドは公開アクセス可能で、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を介したゼロトラストネットワーク。
- 監視:
- クラウドコンソールにサービスの健康を監視するための組み込みの健康ダッシュボードが含まれています。
- 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を予約することをお勧めしますが、サイズを制限したい場合は/23を使用することも可能です。ただし、サーバーポッドが30以内に制限される可能性がある場合は、/23を選択してください。
メンテナンスの頻度を決定できますか？
サポートに連絡してメンテナンスウィンドウをスケジュールしてください。最低でも週に1回の更新計画が期待されます。
可視性
組み込みの監視ツール
可視性ダッシュボード
ClickHouse Cloudには、メモリ使用量、クエリレート、I/Oなどのメトリクスを表示する高度な可視性ダッシュボードが含まれています。これは、ClickHouse CloudのWebコンソールインターフェースの監視セクションでアクセスできます。
高度なダッシュボード
system.metrics、system.events、system.asynchronous_metricsなどのシステムテーブルからのメトリクスを使用して、サーバーのパフォーマンスおよびリソース利用状況を詳細に監視するダッシュボードをカスタマイズできます。
Prometheus統合
ClickHouse Cloudは、監視用のメトリクスをスクリーピングするために使用できるPrometheusエンドポイントを提供します。これにより、GrafanaやDatadog等のツールと統合して表示できます。
HTTPSエンドポイント /metrics_all を介したサンプルリクエスト
サンプルレスポンス
認証
ClickHouseのユーザー名とパスワードのペアを使用して認証できます。メトリクスをスクリーピングするために最小限の権限を持つ専用ユーザーを作成することをお勧めします。最低でも、レプリカ間のsystem.custom_metricsテーブルに対するREAD権限が必要です。例えば：
Prometheusの構成
以下に示したのは、構成の一例です。targetsエンドポイントは、ClickHouseサービスにアクセスするのと同じものです。
また、このブログ投稿およびClickHouseのPrometheusセットアップドキュメントもご覧ください。