Skip to main content
W&B Weave をセルフホストすると、その環境と設定に対するより多くの制御が可能になります。これにより、より分離された環境を作成し、追加のセキュリティコンプライアンスを満たすことができます。 このドキュメントでは、Altinity ClickHouse Operator を使用して W&B Self-Managed デプロイメントで W&B Weave を実行するために必要なコンポーネントをデプロイする方法を説明します。最終的に、独自の Kubernetes クラスター上で本番グレードの Weave インスタンスが、レプリケートされた ClickHouse データベースと S3互換オブジェクトストレージによって支えられて実行されるようになります。このガイドは、組織内で W&B のデプロイと運用を担当する Kubernetes 管理者およびプラットフォームエンジニア向けです。 セルフマネージド Weave デプロイメントは、バックエンドを管理するために ClickHouseDB に依存します。このデプロイメントでは以下を使用します:
  • Altinity ClickHouse Operator: Kubernetes 向けのエンタープライズグレードの ClickHouse 管理ツール。
  • ClickHouse Keeper: 分散型コーディネーションサービス (ZooKeeper の代替)。
  • ClickHouse Cluster: トレースストレージ用の高可用性データベースクラスター。
  • S3互換ストレージ: ClickHouse データ永続化のためのオブジェクトストレージ。
詳細なリファレンスアーキテクチャについては、W&B Self-Managed Reference Architecture を参照してください。

セットアップに関する重要なメモ

このガイドの設定例は参考用です。Kubernetes 環境は組織ごとに異なるため、セルフホストのインスタンスでは、通常、次の項目を調整する必要があります。
  • セキュリティとコンプライアンス: 組織のセキュリティポリシーおよび Kubernetes または OpenShift の要件に従って、セキュリティコンテキスト、runAsUser や fsGroup の値、その他のセキュリティ設定を調整します。
  • リソースのサイジング: 記載されているリソース割り当ては出発点にすぎません。想定されるトレース量とパフォーマンス要件に基づく適切なサイジングについては、W&B Solutions Architect チームにご相談ください。
  • インフラストラクチャー固有の設定: ストレージクラス、ノードセレクター、その他のインフラストラクチャー固有の設定を、ご使用の環境に合わせて更新します。
これらの設定は、そのまま適用するソリューションではなく、テンプレートとして扱ってください。

アーキテクチャ

次の図は、セルフマネージドの Weave デプロイメントにおいて、W&B Platform、ClickHouse クラスター、ClickHouse Keeper コーディネーションサービス、S3 ストレージがどのように連携するかを示しています。

前提条件

開始する前に、環境が以下の要件を満たしていることを確認してください。セルフマネージドの Weave インスタンスには以下のリソースが必要です:
  • Kubernetes cluster: バージョン 1.29 以降。
  • Kubernetes nodes: マルチノードクラスター (高可用性のために最低 3 ノードを推奨) 。
  • Storage class: 永続ボリューム用の動作する StorageClass (例: gp3、standard、nfs-csi) 。
  • S3 bucket: 適切なアクセス権限を持つ事前設定済みの S3 または S3互換バケット。
  • W&B Platform: すでにインストールされ実行中。W&B Self-Managed Deployment Guide を参照してください。
  • W&B license: W&B Support から提供される Weave 有効化ライセンス。
この前提条件リストのみに基づいてサイジングの決定を行わないでください。リソース要件はトレース量と使用パターンによって異なります。詳細については、Resource requirements を参照してください。

必須ツール

インスタンスを設定するには、次のツールが必要です:
  • クラスターアクセスが設定された kubectl。
  • helm バージョン 3.0 以降。
  • AWS 認証情報 (S3 を使用する場合) または S3互換ストレージへのアクセス。

ネットワーク要件

Kubernetes クラスターには、次のネットワーク構成が必要です。
  • clickhouse namespace 内の Pod が、wandb namespace 内の Pod と通信できる必要があります。
  • ClickHouse ノード同士が、ポート 8123、9000、9009、2181 で通信できる必要があります。

セルフマネージド Weave インスタンスをデプロイする

以下のステップでは、オペレーターのデプロイ、ストレージの準備、ClickHouse Keeper と ClickHouse クラスターのデプロイ、および W&B プラットフォームでの Weave の有効化について説明します。各ステップは前のステップで作成したリソースに基づいているため、順番に完了してください。

Altinity ClickHouse Operator のデプロイ

Altinity ClickHouse Operator は Kubernetes 内の ClickHouse インストールを管理します。オペレーターを最初にインストールすることで、後続のステップで ClickHouse Keeper と ClickHouse クラスターのリソースを宣言でき、オペレーターがそれらをリコンサイルします。

Altinity Helm リポジトリを追加

オペレーターの設定を作成する

ch-operator.yaml という名前のファイルを作成します。このファイルは、オペレーターのデプロイメントのセキュリティコンテキストとメタデータを定義します:
ここに示す containerSecurityContext の値は、ほとんどの Kubernetes ディストリビューションで使用できます。OpenShift の場合は、プロジェクトに割り当てられた UID 範囲に合わせて runAsUser と fsGroup を調整する必要があります。

オペレーターをインストールする

オペレーターのインストールを確認する

オペレーターが稼働したので、ClickHouse クラスターが依存する永続ストレージとコーディネーションサービスをプロビジョニングできます。

S3 ストレージを準備する

ClickHouse では、データの永続化に S3 または S3互換ストレージが必要です。このステップでは、バケットを作成し、ClickHouse がそれに認証する方法を設定します。

S3 バケットを作成する

AWS アカウントまたは S3互換のストレージプロバイダーで S3 バケットを作成します。[BUCKET-NAME] をバケット名に、 [REGION] を AWS リージョンに置き換えてください:

S3 認証情報を設定する

ClickHouse はバケットからの読み取りと書き込みに認証情報を必要とします。S3 アクセスの認証情報を提供する方法は 2 つあります。W&B は、クラスターに長期的なシークレットを保存しないため、AWS 上のオプション A (IRSA) を推奨します。 Kubernetes ノードに S3 アクセス権を持つ IAM ロールがある場合、ClickHouse は EC2 インスタンスのメタデータを使用できます:
必須の IAM ポリシー (ノードの IAM ロールに関連付ける) :
静的な認証情報を好む場合は、Kubernetes シークレットを作成します: [ACCESS-KEY] を AWS アクセスキーに、 [SECRET-KEY] を AWS シークレットキーに置き換えてください:
次に、そのシークレットを使用するように ClickHouse を設定します (ステップ 4 の ch-server.yaml の設定を参照してください) 。

ClickHouse Keeper のデプロイ

ClickHouse Keeper は、データレプリケーションと分散 DDL クエリの実行のためのコーディネーションシステムを提供します。ClickHouse クラスターをデプロイする前に Keeper をデプロイする必要があります。ステップ 4 の ClickHouse サーバーは起動時に Keeper に接続するためです。

Keeper の設定を作成する

ch-keeper.yaml という名前のファイルを作成します。このマニフェストでは、3 レプリカの Keeper クラスターをアンチアフィニティ、永続ストレージ、および Altinity オペレーターが Keeper Pod をプロビジョニングするために使用する設定とともに定義します。
設定に関する重要な変更点:
  • StorageClass: storageClassName: gp3 を、クラスターで使用可能な StorageClass に合わせて変更してください。
  • セキュリティコンテキスト: runAsUser と fsGroup の値を、組織のセキュリティポリシーに準拠するように調整してください。
  • アンチアフィニティ: クラスターのトポロジと HA 要件に応じて、affinity セクションをカスタマイズするか削除してください。
  • リソース: CPU とメモリの値は一例です。適切なサイジングについては、W&B Solutions Architect にご相談ください。
  • 命名: metadata.name または configuration.clusters[0].name を変更する場合は、ch-server.yaml (ステップ 4) 内の Keeper のホスト名もそれに合わせて更新する必要があります。

ClickHouse Keeper リソースをデプロイする

Keeper デプロイメントを検証

Keeper が実行中なので、それを使用して調整を行う ClickHouse クラスターをデプロイできます。

ClickHouse クラスターをデプロイする

Weave トレース データを保存する ClickHouse サーバー クラスターをデプロイします。これはガイドの中で最大のステップです。クラスターはステップ 3 の Keeper サービスとステップ 2 の S3 Bucket の両方に接続するためです。

ClickHouse Server 設定の作成

ch-server.yaml という名前のファイルを作成します。このマニフェストは、ClickHouse クラスター、Keeper への接続、Weave のユーザー アカウント、およびトレースデータに使用される S3 storage ポリシーを宣言します:
重要な設定更新が必要です:
  1. StorageClass: storageClassName: gp3 をクラスターの StorageClass に合わせて更新してください。
  2. S3 endpoint: [BUCKET-NAME] と [REGION] を実際の値に置き換えてください。
  3. Cache size: <max_size>40Gi</max_size> は永続ボリュームのサイズ (50Gi) より小さくする必要があります。
  4. Security context: runAsUser、fsGroup、およびその他のセキュリティ設定を組織のポリシーに合わせて調整してください。
  5. Resource allocation: CPU とメモリの値は例です。予想されるトレース量に基づく適切なサイジングについては、W&B Solutions Architect にご相談ください。
  6. Anti-affinity rules: クラスターのトポロジと高可用性のニーズに基づいてカスタマイズまたは削除してください。
  7. Keeper hostnames: Keeper ノードのホスト名は、ステップ 3 の Keeper デプロイメントの命名に一致する必要があります (「Keeper の命名規則」を参照) 。
  8. Cluster naming: クラスター名 weavecluster は変更可能ですが、ステップ 5 の WF_CLICKHOUSE_REPLICATED_CLUSTER の値と一致する必要があります。
  9. Credentials:
    • IRSA の場合: <use_environment_credentials>true</use_environment_credentials> を保持するか、環境変数にマッピングされたシークレットキーにアクセスしてください。

S3 設定の更新

ch-server.yaml の storage_configuration.xml セクションを編集します。 AWS S3 の例:
MinIO の例:
{replica} は削除しないでください。これにより、各 ClickHouse レプリカがバケット内の個別のフォルダーに書き込むようになります。

認証情報を設定する (オプション B のみ)

オプション B (アクセスキー) を使用する場合、ステップ 2 から、ch-server.yaml の env セクションがシークレットを参照していることを確認してください:
Option A (IRSA) を使用する場合は、env セクション全体を削除します。

Keeper の命名規則

Keeper のホスト名を正しく設定することは非常に重要です。ステップ 3 で作成したサービスと一致しない場合、ClickHouse は起動しません。zookeeper.nodes セクションに指定する Keeper ノードのホスト名は、ステップ 3 の Keeper デプロイメントに基づく特定のパターンに従います。 ホスト名のパターン: chk-[INSTALLATION-NAME]-[CLUSTER-NAME]-[CLUSTER-INDEX]-[REPLICA-INDEX].[NAMESPACE].svc.cluster.local 各要素の意味は次のとおりです。
  • chk は ClickHouseKeeperInstallation の接頭辞です (固定)。
  • [INSTALLATION-NAME] は ch-keeper.yaml の metadata.name です (例: wandb)。
  • [CLUSTER-NAME] は ch-keeper.yaml の configuration.clusters[0].name です (例: keeper)。
  • [CLUSTER-INDEX] はクラスターのインデックスで、単一クラスターの場合は通常 0 です。
  • [REPLICA-INDEX] はレプリカ番号で、レプリカが 3 つの場合は 0、1、2 のいずれかです。
  • [NAMESPACE] は Kubernetes の namespace です (例: clickhouse)。
デフォルト名を使用した例:
Keeper のインストール名をカスタマイズする場合 (例: metadata.name: myweave) は、次のようにします。
Keeper のクラスター名をカスタマイズする場合 (例: clusters[0].name: coordination):
実際の Keeper ホスト名を確認するには、次の手順を実行します。
ch-server.yaml 内の Keeper のホスト名は、Keeper デプロイメントによって作成された実際のサービス名と完全に一致させる必要があります。一致しない場合、ClickHouse サーバーはコーディネーションサービスに接続できません。

ClickHouse クラスターのリソースをデプロイする

ClickHouse のデプロイメントを確認する

これで、Keeper と S3 をバックエンドとする ClickHouse クラスターが稼働しました。残りのステップでは、W&B Platform をこのクラスターに接続し、Weave トレースがエンドツーエンドで流れることを確認します。

W&B プラットフォームで Weave を有効にする

次に、Weave トレースの保存先として ClickHouse クラスターを使用するよう、W&B プラットフォームを設定します。このステップでは、外部で管理している ClickHouse の接続先を W&B Operator に指定し、weave-trace サービスを有効にします。

ClickHouse の接続情報を確認する

以下の情報が必要です。
  • ホスト: clickhouse-wandb.clickhouse.svc.cluster.local
  • ポート: 8123
  • ユーザー: weave (ch-server.yaml で設定したもの)
  • パスワード: ch-server.yaml で設定したパスワード
  • データベース: weave (自動的に作成されます)
  • クラスター名: weavecluster (ch-server.yaml で設定したもの)
ホスト名は次の形式になります: clickhouse-[INSTALLATION-NAME].[NAMESPACE].svc.cluster.local

W&B カスタムリソースを更新する

W&B Platform のカスタムリソース (CR) を編集して、Weave の設定を追加します。
重要な設定:
  • clickhouse.replicated: true: 3 つのレプリカを使用する場合は必須です。
  • WF_CLICKHOUSE_REPLICATED: "true": レプリケーション構成では必須です。
  • WF_CLICKHOUSE_REPLICATED_CLUSTER: "weavecluster": ch-server.yaml のクラスター名と一致させる必要があります。
ここに示すセキュリティコンテキスト、リソース割り当て、その他の Kubernetes 固有の設定は参考例です。組織の要件に合わせてカスタマイズしてください。適切なリソースサイジングについては、W&B Solutions Architect チームにご相談ください。

更新した設定を適用する

Weave Trace のデプロイメントを検証する

Weave データベースを初期化する

weave-trace サービスは、初回起動時に必要なデータベーススキーマを自動的に作成します。この手順では、エンドユーザーに Weave を公開する前に、移行が正常に完了したことを確認します。

データベースの移行を監視する

データベースの作成を確認する

Weave が有効になっていることを確認する

最後のこのステップでは、Weave のライセンスが有効であること、W&B Console からアクセスできること、およびクライアント SDK からトレースを記録できることを確認します。

W&B Console にアクセスする

ウェブブラウザーで W&B インスタンスの URL にアクセスします。

Weave のライセンスステータスを確認する

W&B Console で次の操作を行います。
  1. Top Right Menu > Organization Dashboard に移動します。
  2. Weave access が有効になっていることを確認します。

Weave の機能をテストする

Weave が動作していることを確認するため、Python のテストを作成します。
これを実行した後、Weights & Biases UI で組織のトレース ページを開き、トレースを確認してください。トレースが表示されれば、セルフマネージドの Weave デプロイメントは正常に稼働しています。

トラブルシューティング

以下のセクションでは、デプロイメントでよく発生する問題とその解決方法を、症状が最初に現れるコンポーネントごとに説明します。

ClickHouse Keeper の問題

問題: Keeper の Pod が Pending 状態のまま進まない 解決策: 考えられる複数の原因を確認します。
  1. PVC と StorageClass の問題:
StorageClass が正しく設定されていること、および十分な空き容量があることを確認してください。
  1. アンチアフィニティとノードの可用性:
よくある問題:
  • アンチアフィニティには 3 つの個別のノードが必要ですが、クラスターのノード数が足りません。
  • ノードに、Pod のリクエストを満たすだけの CPU またはメモリがありません。
  • ノードの taint が原因で、Pod をスケジューリングできません。
解決策:
  • ノードが 3 つ未満の場合は、アンチアフィニティのルールを削除または調整します。
  • アンチアフィニティの制約を緩めるには、requiredDuringSchedulingIgnoredDuringExecution の代わりに preferredDuringSchedulingIgnoredDuringExecution を使用します。
  • ノードのリソースに余裕がない場合は、リソースリクエストを減らします。
  • クラスターにノードを追加します。

問題: Keeper Pod が CrashLoopBackOff の状態になる 解決策: ログを確認し、設定を検証します。
よくある問題:
  • セキュリティコンテキストが正しくない (runAsUser と fsGroup を確認してください) 。
  • ボリュームの権限に関する問題。
  • ポートの競合。
  • ch-keeper.yaml の設定エラー。

ClickHouse サーバーの問題

問題: ClickHouse が S3 に接続できない 解決策: S3 の認証情報と権限を確認します。

問題: ClickHouse が Keeper に接続できない 解決策: Keeper のエンドポイントと命名規則を確認します。
接続に失敗する場合は、ch-server.yaml 内の Keeper のホスト名が実際の Keeper デプロイメントと一致していない可能性があります。命名パターンについては、ステップ 4 の「Keeper の命名規則」を参照してください。

Weave Trace の問題

問題: weave-trace Pod が起動しない 解決策: ClickHouse の接続性を確認します。

問題: Console で Weave が有効と表示されない 解決策: 設定を確認します。
  1. ライセンスに Weave が含まれていることを確認します。
  2. wandb-cr.yaml で weave-trace.enabled: true と clickhouse.replicated: true が設定されていることを確認します。
  3. W&B オペレーターのログを確認します。

問題: データベースの移行が失敗する 解決策: クラスター名が一致していることを確認します。 WF_CLICKHOUSE_REPLICATED_CLUSTER 環境変数の値は、ch-server.yaml 内のクラスター名と一致している必要があります。

リソース要件

このセクションでは、一般的な2つのデプロイ構成に対するリソース割り当ての例を紹介します。クラスターを計画する際の出発点として使用し、実際に観測したワークロードに基づいて数値を調整してください。
このセクションのリソース割り当ては、出発点となる例です。実際の要件は、以下によって異なります。
  • トレースの取り込み量 (1秒あたりのトレース数)
  • クエリのパターンと同時実行数
  • データの保持期間
  • 同時利用ユーザー数
具体的なユースケースに適したリソース規模を判断するため、必ずW&B Solutions Architect チームに相談してください。リソースの不足はパフォーマンスの問題につながり、過剰な割り当てはインフラストラクチャーのコストを無駄にします。

本番環境の最小構成

開発、テスト、または処理量の少ない本番環境に適しています。 トレース量が多い本番ワークロードの場合: 大量のトレースを扱う本番環境に適しています。 さらに大規模なデプロイメントの場合は、W&B Solutions Architect チームにお問い合わせください。実際のトレース量とパフォーマンス要件に応じて、個別のサイジングを提案します。

詳細設定

このセクションでは、垂直スケーリングまたは水平スケーリングによる ClickHouse のキャパシティ拡張、Keeper とサーバーの両方の設定でイメージタグを変更することによる ClickHouse バージョンの更新、ClickHouse の健全性のモニタリングなど、セルフマネージドの Weave デプロイメントのカスタマイズオプションについて説明します。 W&B では、インスタンスに高度な変更を加える際は、パフォーマンスと信頼性の要件を満たすよう、W&B Solutions Architect チームに相談することを推奨しています。

ClickHouse のスケーリング

ClickHouse のキャパシティを増やすには、次の方法があります。
  1. 垂直スケーリング: Pod ごとのリソースを増やします (シンプルな方法です) 。
    推奨事項: 実際のリソース使用量を監視し、それに応じてスケーリングしてください。極めて大量のデータを扱うデプロイメントについては、W&B Solutions Architect チームにお問い合わせください。
  2. 水平スケーリング: レプリカを追加します (慎重な計画が必要です) 。
    • レプリカを増やすには、データの再分散が必要です。
    • シャード管理については、ClickHouse のドキュメントを参照してください。
    • 本番環境で水平スケーリングを実施する前に、W&B Solutions Architect にご相談ください。

別の ClickHouse バージョンを使用する

別の ClickHouse バージョンを使用するには、ch-keeper.yaml と ch-server.yaml の両方でイメージタグを更新します。
互換性を確保するため、Keeper とサーバーのバージョンを一致させるか、Keeper のバージョンをサーバーのバージョン以上にしてください。
ClickHouse Server をアップグレードする際は、ClickHouse Keeper も互換性のあるバージョンにアップグレードしてください。W&B セルフマネージドデプロイメントの ClickHouse バージョンを変更する前に、アップグレード時の ClickHouse 互換性とサポートされる W&B Server リリースのページを確認してください。

ClickHouse の監視

モニタリングのために ClickHouse のシステム表にアクセスします:

バックアップと復旧

ClickHouse はデータを S3 に保存するため、S3 のバージョン管理機能とバケットレプリケーション機能により、バックアップ機能を標準で備えています。お使いのデプロイメントに適したバックアップ戦略については、W&B Solutions Architect チームにご相談のうえ、ClickHouse のバックアップに関するドキュメントを参照してください。

セキュリティに関する考慮事項

本番環境のデプロイメントでは、このガイドに示すデフォルト設定のセキュリティを強化してください。セキュリティチームと確認すべき特に重要な事項を以下に示します。
  1. 認証情報: ClickHouse のパスワードは、平文ではなく Kubernetes シークレットに保存してください。
  2. ネットワークポリシー: ClickHouse へのアクセスを制限するため、NetworkPolicies の導入を検討してください。
  3. RBAC: サービスアカウントに必要最小限の権限のみが付与されていることを確認してください。
  4. S3 バケット: 保存時の暗号化を有効にし、バケットへのアクセスを必要な IAM ロールに制限してください。
  5. TLS: オプションです。本番環境では、ClickHouse へのクライアント接続で TLS を有効にしてください。

アップグレード

以下の手順では、オペレーター、ClickHouse サーバー、Weave Trace コンポーネントの通常のアップグレードについて説明します。コンポーネントを 1 つずつアップグレードし、デプロイメントが正常であることを確認してから次に進んでください。
Weave には、サポートされる ClickHouse バージョンが必要です。ClickHouse または W&B Server をアップグレードする前に、アップグレード時の ClickHouse 互換性とサポートされる W&B Server リリースを参照してください。ClickHouse Server と ClickHouse Keeper は同時にアップグレードしてください。

ClickHouse オペレーターをアップグレードする

ClickHouse Server のアップグレード

ch-keeper.yaml と ch-server.yaml の両方でイメージのバージョンを更新し、サーバーのマニフェストを適用します。

Weave Trace をアップグレードする

wandb-cr.yaml のイメージタグを更新し、変更を適用します。

追加リソース

サポート

本番環境へのデプロイメントや問題について:
  • CoreWeave Forge サポート: forge-support@coreweave.com
  • ソリューションアーキテクト: 超大規模なデプロイメント、個別のリソース規模の算定、デプロイメント計画について。
  • サポートリクエストに含める情報:
    • weave-trace、ClickHouse Pod、オペレーターのログ。
    • W&B のバージョン、ClickHouse バージョン、Kubernetes のバージョン。
    • クラスター情報とトレース量。

よくある質問

Q: ClickHouse のレプリカを3つではなく1つだけ使用できますか? A: はい。ただし、本番環境では推奨されません。ch-server.yaml の設定を replicasCount: 1 に変更し、wandb-cr.yaml で clickhouse.replicated: false を設定してください。 Q: ClickHouse の代わりに別のデータベースを使用できますか? A: いいえ。Weave Trace には、高性能な列指向ストレージ機能を備えた ClickHouse が必要です。 Q: S3 ストレージはどのくらい必要ですか? A: 必要な S3 ストレージ容量は、トレース量、保持期間、データ圧縮によって異なります。デプロイ後の実際の使用量を監視し、それに応じて調整してください。ClickHouse の列指向形式は、トレースデータを効率的に圧縮します。 Q: ClickHouse で database 名を設定する必要がありますか? A: いいえ。weave-trace サービスが初回起動時に weave データベースを自動的に作成します。 Q: クラスター名が weavecluster でない場合はどうすればよいですか? A: 環境変数 WF_CLICKHOUSE_REPLICATED_CLUSTER をクラスター名と一致するように設定する必要があります。一致しない場合、データベースの移行が失敗します。 Q: 例に示されているセキュリティコンテキストをそのまま使用すべきですか? A: いいえ。このガイドに記載されている runAsUser や fsGroup などのセキュリティコンテキストは参考例です。組織のセキュリティポリシーに準拠するように調整する必要があります。特に OpenShift クラスターには、UID と GID の範囲に関する固有の要件があるため注意してください。 Q: ClickHouse クラスターの規模が適切かどうかを確認するにはどうすればよいですか? A: 想定されるトレース量と使用パターンを W&B Solutions Architect チームに伝えて相談してください。適切な規模に関する推奨事項が提供されます。デプロイメントのリソース使用量を監視し、必要に応じて調整してください。 Q: 例で使用されている命名規則を変更できますか? A: はい。ただし、すべてのコンポーネント間で一貫性を保つ必要があります。
  1. ClickHouse Keeper 名: ch-server.yaml の zookeeper.nodes セクションにある Keeper ノードのホスト名と一致する必要があります。
  2. ClickHouse クラスター名 (weavecluster): wandb-cr.yaml の WF_CLICKHOUSE_REPLICATED_CLUSTER と一致する必要があります。
  3. ClickHouse インストール名: weave-trace が使用するサービスのホスト名に影響します。
命名パターンと実際の名前の確認方法については、ステップ4の「Keeper の命名規則」セクションを参照してください。 Q: クラスターのアンチアフィニティ要件が異なる場合はどうすればよいですか? A: ここに示すアンチアフィニティルールは、高可用性を確保するための推奨事項です。クラスターの規模、トポロジ、可用性要件に応じて調整または削除してください。小規模なクラスターや開発環境では、アンチアフィニティルールが不要な場合もあります。
最終更新日 2026年9月30日