メインコンテンツへスキップ
メインコンテンツへスキップ

AWS 向け BYOC オンボーディング

オンボーディングプロセス​

お客様は、こちら からお問い合わせいただくことで、オンボーディングプロセスを開始できます。専用の AWS アカウントと、利用予定のリージョンをあらかじめご用意いただく必要があります。現時点では、ClickHouse Cloud がサポートしているリージョンでのみ BYOC サービスを起動できます。

AWS アカウントの準備​

ClickHouse BYOC デプロイメントをホストするために、より高い分離を確保する目的で、専用の AWS アカウントを用意することを推奨します。ただし、共有アカウントや既存の VPC を使用することも可能です。詳細は、後述の Setup BYOC Infrastructure を参照してください。

このアカウントと組織の初期管理者のメールアドレスを用意したら、ClickHouse サポートまでお問い合わせください。

BYOC セットアップの初期化​

初期の BYOC セットアップは、CloudFormation テンプレートまたは Terraform モジュールのいずれかを使用して実行できます。どちらの方法でも同じ IAM ロールが作成され、ClickHouse Cloud からの BYOC コントローラーがインフラストラクチャを管理できるようになります。なお、ClickHouse の実行に必要な S3、VPC、およびコンピューティングリソースは、この初期セットアップには含まれません。

CloudFormation テンプレート​

BYOC CloudFormation テンプレート

Terraform モジュール​

BYOC Terraform モジュール

module "clickhouse_onboarding" {
  source   = "https://s3.us-east-2.amazonaws.com/clickhouse-public-resources.clickhouse.cloud/tf/byoc.tar.gz"
  byoc_env = "production"
}

BYOC インフラストラクチャのセットアップ​

CloudFormation スタックを作成すると、クラウドコンソールから S3、VPC、EKS クラスターを含むインフラストラクチャのセットアップを求められます。この段階で決定しなければならない設定がいくつかあり、後から変更することはできません。具体的には次のとおりです。

  • 使用するリージョン: ClickHouse Cloud が提供しているパブリックリージョンのいずれか 1 つを選択します。
  • BYOC 用の VPC CIDR 範囲: 既定では、BYOC VPC の CIDR 範囲として 10.0.0.0/16 を使用します。別アカウントとの VPC ピアリングを行う予定がある場合は、CIDR 範囲が重複しないようにしてください。必要なワークロードを収容できるよう、BYOC 用に最小でも /22 のサイズを持つ適切な CIDR 範囲を割り当ててください。
  • BYOC VPC のアベイラビリティーゾーン: VPC ピアリングを利用する予定がある場合、送信元アカウントと BYOC アカウント間でアベイラビリティーゾーンを揃えると、AZ 間トラフィックのコスト削減に役立ちます。AWS では、アベイラビリティーゾーンのサフィックス (a, b, c) は、アカウントごとに異なる物理ゾーン ID を表すことがあります。詳細については AWS ガイドを参照してください。

お客様管理の VPC​

既定では、ClickHouse Cloud は BYOC デプロイメントにおいて分離性を高めるため、専用の VPC をプロビジョニングします。ただし、アカウント内に既存の VPC がある場合は、それを利用することも可能です。その場合は特定の設定が必要となり、ClickHouse Support を通じて調整する必要があります。

既存の VPC を構成する

  1. ClickHouse Cloud が使用できるように、少なくとも 3 つの異なるアベイラビリティーゾーンにまたがって、合計 3 つ以上のプライベートサブネットを割り当てます。
  2. 各サブネットには、ClickHouse デプロイメントに十分な IP アドレスを確保するため、最小でも /23 (例: 10.0.0.0/23) の CIDR 範囲を設定してください。
  3. 適切なロードバランサー構成を有効にするため、各サブネットに kubernetes.io/role/internal-elb=1 というタグを追加します。

BYOC VPC サブネット


BYOC VPC サブネットのタグ

  1. S3 ゲートウェイエンドポイントを構成する
    VPC にまだ S3 ゲートウェイエンドポイントが構成されていない場合は、VPC と Amazon S3 間のセキュアでプライベートな通信を有効にするために、1 つ作成する必要があります。このエンドポイントにより、ClickHouse のサービスはパブリックインターネットを経由せずに S3 にアクセスできます。構成例については、以下のスクリーンショットを参照してください。

BYOC S3 エンドポイント

ClickHouse サポートへの連絡
次の情報を記載してサポートチケットを作成します:

  • AWS アカウント ID
  • サービスをデプロイしたい AWS リージョン
  • VPC ID
  • ClickHouse 用に割り当てたプライベートサブネット ID
  • これらのサブネットが属しているアベイラビリティゾーン

オプション: VPC ピアリングのセットアップ​

ClickHouse BYOC の VPC ピアリングを作成または削除するには、次の手順に従います:

ステップ 1: ClickHouse BYOC 用のプライベートロードバランサーを有効化する​

ClickHouse サポートに連絡し、プライベートロードバランサーの有効化を依頼します。

ステップ 2 ピアリング接続を作成する​

  1. ClickHouse BYOC アカウントで VPC ダッシュボードに移動します。
  2. 「Peering Connections」を選択します。
  3. 「Create Peering Connection」をクリックします。
  4. VPC Requester に ClickHouse の VPC ID を設定します。
  5. VPC Accepter に対象 VPC ID を設定します（必要に応じて別アカウントを選択）。
  6. 「Create Peering Connection」をクリックします。

BYOC ピアリング接続の作成

ステップ 3 ピアリング接続リクエストを承認する​

ピアリング先アカウントの (VPC -> Peering connections -> Actions -> Accept request) ページに移動し、この VPC ピアリングリクエストを承認します。


BYOC ピアリング接続の承認

ステップ 4 ClickHouse VPC のルートテーブルに宛先を追加する​

ClickHouse BYOC アカウントで、

  1. VPC ダッシュボードで「Route Tables」を選択します。
  2. ClickHouse の VPC ID を検索し、プライベートサブネットに関連付けられている各ルートテーブルを編集します。
  3. 「Routes」タブの「Edit」ボタンをクリックします。
  4. 「Add another route」をクリックします。
  5. Destination に対象 VPC の CIDR 範囲を入力します。
  6. Target に「Peering Connection」と、そのピアリング接続の ID を選択します。

BYOC ルートテーブルの追加

ステップ 5 対象 VPC のルートテーブルに宛先を追加する​

ピアリング先の AWS アカウントで、

  1. VPC ダッシュボードで「Route Tables」を選択します。
  2. 対象 VPC ID を検索します。
  3. 「Routes」タブの「Edit」ボタンをクリックします。
  4. 「Add another route」をクリックします。
  5. Destination に ClickHouse VPC の CIDR 範囲を入力します。
  6. Target に「Peering Connection」と、そのピアリング接続の ID を選択します。

BYOC ルートテーブルの追加

ステップ 6: セキュリティグループを編集してピアリングされた VPC からのアクセスを許可する​

ClickHouse BYOC アカウントで、ピアリングされた VPC からのトラフィックを許可するように Security Group の設定を更新する必要があります。ピアリングされた VPC の CIDR 範囲を含むインバウンドルールの追加を依頼するため、ClickHouse サポートに連絡してください。

これで、ピアリングされた VPC から ClickHouse サービスにアクセスできるようになります。

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:00 PDT）を指定でき、その時間帯にのみこうしたアップグレードが実施されるようにできます。

注記

メンテナンスウィンドウは、セキュリティおよび脆弱性修正には適用されません。これらは通常のスケジュール外のアップグレードとして対応し、運用への影響を最小限に抑えられるよう、適切な時間を調整するためのタイムリーなコミュニケーションを行います。

CloudFormation IAM ロール​

ブートストラップ IAM ロール​

ブートストラップ IAM ロールには、次の権限があります。

  • EC2 および VPC の操作: VPC と EKS クラスターをセットアップするために必要です。
  • S3 の操作（例: s3:CreateBucket）: ClickHouse BYOC ストレージ用のバケットを作成するために必要です。
  • route53:* 権限: External-DNS が Route 53 内のレコードを設定するために必要です。
  • IAM の操作（例: iam:CreatePolicy）: コントローラーが追加のロールを作成するために必要です（詳細は次のセクションを参照してください）。
  • EKS の操作: 名前が clickhouse-cloud プレフィックスで始まるリソースに限定されます。

コントローラーによって作成される追加の IAM ロール​

CloudFormation で作成される ClickHouseManagementRole に加えて、コントローラーは複数の追加ロールを作成します。

これらのロールは、顧客の EKS クラスター内で動作するアプリケーションによって引き受けられます。

  • State Exporter Role
    • ClickHouse Cloud にサービスのヘルス情報を報告する ClickHouse コンポーネントです。
    • ClickHouse Cloud が所有する SQS キューへ書き込む権限が必要です。
  • Load-Balancer Controller
    • 標準的な AWS ロードバランサーコントローラーです。
    • ClickHouse サービス向けのボリュームを管理する EBS CSI Controller です。
  • External-DNS
    • DNS 設定を Route 53 に伝搬します。
  • 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 との間を流れるさまざまなネットワークトラフィックについて説明します。

  • Inbound: 顧客の BYOC VPC に入ってくるトラフィック。
  • Outbound: 顧客の BYOC VPC を起点として外部の宛先に送信されるトラフィック。
  • Public: パブリックインターネットからアクセス可能なネットワークエンドポイント。
  • Private: VPC ピアリング、VPC Private Link、Tailscale などのプライベート接続経由でのみアクセス可能なネットワークエンドポイント。

Istio イングレスは AWS NLB の背後にデプロイされており、ClickHouse クライアントトラフィックを受け付けます。

Inbound, Public (Private にすることも可能)

Istio イングレスゲートウェイは TLS を終端します。Let's Encrypt を用いて CertManager によりプロビジョニングされた証明書は、EKS クラスター内の Secret として保存されます。Istio と ClickHouse は同じ VPC 内に存在するため、それらの間のトラフィックは AWS によって暗号化されます。

デフォルトでは、イングレスは IP 許可リストによるフィルタリング付きでパブリックに公開されています。顧客は VPC ピアリングを構成してプライベート接続にし、パブリック接続を無効化できます。アクセスを制限するため、IP フィルター の設定を強く推奨します。

アクセスのトラブルシューティング​

Inbound, Public (Private にすることも可能)

ClickHouse Cloud のエンジニアは、Tailscale を介したトラブルシューティング用アクセスを必要とします。彼らには、BYOC デプロイメント向けにジャストインタイムの証明書ベース認証がプロビジョニングされます。

Billing scraper​

Outbound, Private

Billing scraper は ClickHouse から課金データを収集し、ClickHouse Cloud が所有する S3 バケットに送信します。

これは ClickHouse サーバーコンテナのサイドカーとして動作し、CPU とメモリのメトリクスを定期的にスクレイピングします。同一リージョン内のリクエストは VPC ゲートウェイサービスエンドポイント経由でルーティングされます。

アラート​

Outbound, Public

AlertManager は、顧客の ClickHouse クラスターの状態が異常な場合に、ClickHouse Cloud へアラートを送信するよう構成されています。

メトリクスとログは顧客の BYOC VPC 内に保存されます。ログは現在、ローカルの EBS に保存されています。今後のアップデートでは、BYOC VPC 内の ClickHouse サービスである LogHouse に保存される予定です。メトリクスは Prometheus と Thanos のスタックを使用し、BYOC VPC 内にローカル保存されます。

サービス状態​

Outbound

State Exporter は、ClickHouse のサービス状態情報を ClickHouse Cloud が所有する SQS に送信します。