標準オンボーディングとは?
標準の BYOC オンボーディングは、CloudFormation または Terraform の手順を開始してから最初の ClickHouse サービスに接続できるようになるまで、エンドツーエンドでおよそ 45~90 分かかります。
アクセスを申請する
オンボーディング
AWS アカウント/GCP プロジェクト/Azure サブスクリプションを準備する
1
クラウドプロバイダーを選択
2
アカウント/プロジェクト/サブスクリプションの準備
初期のBYOCセットアップは、CloudFormation template (AWS)、Terraform module (GCP)、または Terraform module (Azure) を使用して実行できます。これにより、高い権限を持つID (IAM role/service account/service principal) が作成され、ClickHouse CloudのBYOC controllersがインフラストラクチャを管理できるようになります。
ClickHouseの実行に必要なStorage buckets、VPC/VNet、Kubernetes cluster、コンピュートリソースは、この初期セットアップには含まれません。これらは次のステップでプロビジョニングされます。
AWS向けTerraform Module
AWSデプロイメントでCloudFormationではなくTerraformを使用する場合は、terraform-byoc-onboarding moduleを使用してください。<version>を、モジュールのリリースページにある最新のタグに置き換えます。常に最新リリースを使用してください。このモジュールはclickhouse_management_role_arnを出力します。標準的なフローでは、この値に対して何かを行う必要はありません。オンボーディングはClickHouse Cloud consoleで続行されます。ただし、設定がデフォルトと異なる場合 (たとえば、連携するカスタムロール名を使用する場合) はClickHouseからこの値の提示を求められるため、控えておいてください。このモジュールは以前、
https://s3.us-east-2.amazonaws.com/clickhouse-public-resources.clickhouse.cloud/tf/byoc.tar.gzでtarballとして配布されていました。このURLは現在も利用できますが、非推奨です。上記のGitHubモジュールを使用してください。AWS 外部ID
AWSでは、セットアップ時に作成されるIAMロールが、混乱した代理者問題を防ぐために外部ID (sts:ExternalId) を使用してClickHouse Cloudを信頼します。ClickHouse Cloud consoleは、オンボーディングを開始するとAWSアカウント用の外部IDを生成し、CloudFormationリンクにあらかじめ入力します。Terraformを使用する場合は、同じ値をexternal_idとして渡してください。同じAWSアカウント上のすべてのBYOCインフラストラクチャは、同じ外部IDを共有します。外部IDの導入前にオンボードされたBYOCインフラストラクチャでは、後方互換性のためにプレースホルダー値
emptyidが使用されます。既存のlegacyデプロイメントがあるAWSアカウントにインフラストラクチャを追加すると、consoleはこの値を表示します。これにより、そのアカウント上のすべてのインフラストラクチャで一貫した信頼設定が維持されます。一意の外部IDに切り替える場合は、ClickHouse Supportにお問い合わせください。3
BYOC インフラストラクチャをセットアップする
ClickHouse Cloud コンソールから、オブジェクトストレージバケット、VPC/VNet、Kubernetes クラスターを含むインフラストラクチャのセットアップを求められます。一部の設定は後から変更できないため、この段階で決定する必要があります。具体的には次のとおりです。
- リージョン: BYOC デプロイメントでは、サポート対象リージョンのドキュメントに記載されているすべてのパブリックリージョンを利用できます。現在、Private Region はサポートされていません。
-
VPC/VNet CIDR 範囲: デフォルトでは、BYOC VPC (AWS/GCP) または VNet (Azure) の CIDR 範囲として
10.0.0.0/16を使用します。別のアカウントとの VPC/VNet peering を予定している場合は、CIDR 範囲が重複しないようにしてください。最小サイズはクラウドによって異なります。- AWS:
/23 - Azure:
/23 - GCP:
/20
- AWS:
-
アベイラビリティゾーン: VPC peering を予定している場合は、ソースアカウントと BYOC アカウントのアベイラビリティゾーンを揃えることで、AZ 間トラフィックのコスト削減につながる場合があります。たとえば AWS では、アベイラビリティゾーンの接尾辞 (
a、b、c) が、アカウントごとに異なる物理ゾーン ID を表すことがあります。詳細については、AWS ガイドを参照してください。
事前検証
Set up Infrastructure をクリックすると、ClickHouse Cloud はリソースを作成する前に、アカウントに対して一連の読み取り専用のプリフライトチェックを実行します。すべてのチェックに合格すると、プロビジョニングが続行されます。チェックに失敗した場合、セットアップは一時停止され、問題の内容が console に正確に表示されるため、リソースが作成される前に修正できます。チェックでは次の点が確認されます。- 権限 — 管理ID (IAM role / service account / service principal) に、ClickHouse Cloudがデプロイメントをプロビジョニングおよび運用するために必要な権限が付与されています。
- 有効化されたサービス (GCP) — 必要なGoogle Cloud API (Compute Engine、Kubernetes Engine、Cloud Storage、Network Connectivity、IAM) がプロジェクトで有効になっています。
- ネットワーク (AWS の既存VPC使用) — VPCとサブネットが、サブネットサイズ、必要なタグ、アベイラビリティゾーンの分散、アウトバウンド接続、利用可能なIPアドレスに関するネットワーク要件を満たしています。
- クォータとガードレール (AWS) — アカウントに十分なサービスクォータ (VPC、NAT ゲートウェイ、Elastic IP、EKS クラスター、vCPUs) があり、必要なアクションを妨げる組織ポリシー (SCP) が設定されていません。
iam:CreateRole · explicitDeny)。成功したチェックをすべて確認するには、Show passed checks を展開してください。これらの失敗を解消するには、最新のClickHouse CloudFormationまたはTerraform stackを再実行するか、報告されたactionsを管理用のidentity (IAM role / service account / service principal) に付与したうえで、次のいずれかを選択してください。- 再検証 — 事前チェックを再実行します。報告された問題を修正した後、プロビジョニング前にセットアップの準備が整っていることを確認するために使用してください。
- それでも続行 — チェックがFailedでもプロビジョニングを続行します。報告された失敗が誤検知であると確信できる場合にのみ使用してください。そうでない場合、プロビジョニングが途中で失敗する可能性があります。
最初の BYOC ClickHouse サービスを作成する
- サービス名: ClickHouse サービスに、わかりやすく説明的な名前を入力します。
- BYOC インフラストラクチャ: サービスを実行する BYOC 環境 (クラウドアカウントとリージョンを含む) を選択します。
- リソース構成: ClickHouse レプリカに割り当てる CPU とメモリの量を選択します。
- レプリカ数: 高可用性を高めるため、レプリカ数を設定します。