Skip to main content
W&B Weave をセルフホストすると、その環境や設定をより細かく制御できます。これにより、より分離された環境を構築し、追加のセキュリティ要件やコンプライアンス要件に対応しやすくなります。このドキュメントでは、Altinity ClickHouse Operator を使用して、W&B Self-Managed デプロイで W&B Weave を実行するために必要なコンポーネントをデプロイする方法を説明します。最終的には、レプリケーションされた ClickHouse データベースと S3互換オブジェクトストレージを基盤とする、本番環境対応の Weave インスタンスを独自の Kubernetes クラスター上で稼働させられるようになります。このガイドは、組織内で W&B のデプロイと運用を担当する Kubernetes 管理者およびプラットフォームエンジニアを対象としています。 セルフマネージド Weave のデプロイでは、バックエンドの管理に ClickHouseDB を使用します。このデプロイでは、次を使用します。
  • Altinity ClickHouse Operator: Kubernetes 向けのエンタープライズグレードの ClickHouse 管理。
  • ClickHouse Keeper: 分散コーディネーションサービス (ZooKeeper の代替) 。
  • ClickHouse Cluster: トレースストレージ向けの高可用性データベースクラスター。
  • S3互換 storage: 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 クラスター: バージョン 1.29 以降。
  • Kubernetes ノード: マルチノード クラスター (高可用性のため、少なくとも 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。
  • バージョン3.0以降のhelm。
  • AWS認証情報 (S3を使用する場合) 、またはS3互換ストレージへのアクセス。

ネットワーク要件

Kubernetes クラスターでは、以下のネットワーク設定が必要です。
  • clickhouse namespace 内の Pod は、wandb namespace 内の Pod と通信できる必要があります。
  • ClickHouse ノード同士は、ポート 8123、9000、9009、2181 を介して通信できる必要があります。

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

以下の手順では、operator のデプロイ、ストレージの準備、ClickHouse Keeper と ClickHouse クラスターのデプロイ、さらに W&B Platform で Weave を有効にする方法を順に説明します。各手順は前の手順で作成したリソースを前提としているため、記載された順序どおりに完了してください。

Altinity ClickHouse Operator をデプロイする

Altinity ClickHouse Operator は、Kubernetes 上の ClickHouse インストールを管理します。先に operator をインストールしておくと、後続のステップで、operator によって調整される ClickHouse Keeper と ClickHouse クラスターのリソースを宣言できるようになります。

Altinity Helmリポジトリを追加する

Operator の設定を作成

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

operatorをインストールする

operator がインストールされていることを確認する

operator が実行中になったので、ClickHouse クラスターが依存する永続ストレージと調整サービスをプロビジョニングできるようになりました。

S3ストレージを準備する

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

S3バケットを作成する

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

S3認証情報を設定する

ClickHouse がバケットの読み取りと書き込みを行うには、認証情報が必要です。S3へのアクセス認証情報を指定する方法は2つあります。AWS では、長期間有効なシークレットをクラスターに保存せずに済むため、W&B はオプション 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 クエリの実行を調整するためのシステムです。Step 4 の ClickHouse サーバーは起動時に Keeper に接続するため、ClickHouse クラスターをデプロイする前に Keeper をデプロイする必要があります。

Keeper の設定を作成する

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

ClickHouse Keeperをデプロイする

Keeper のデプロイを確認する

Keeper が稼働しているので、これを協調サービスとして使用する ClickHouse クラスターをデプロイできるようになりました。

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

次に、Weave Trace Data を保存する ClickHouse サーバークラスタをデプロイします。このステップは、クラスターがステップ 3 の Keeper サービスとステップ 2 の S3 バケットの両方に接続するため、このガイドの中で最も大がかりなステップです。

ClickHouse サーバー設定を作成する

ch-server.yaml という名前のファイルを作成します。このマニフェストでは、ClickHouse クラスター、Keeper への接続、Weave ユーザーアカウント、そしてトレースデータに使用する S3 ストレージポリシーを定義します:
重要な設定更新が必要です。
  1. StorageClass: storageClassName: gp3 を、お使いのクラスターの StorageClass に合わせて更新します。
  2. S3 endpoint: [BUCKET-NAME] と [REGION] を実際の値に置き換えます。
  3. Cache size: <max_size>40Gi</max_size> は、永続ボリュームのサイズ (50Gi) より小さくする必要があります。
  4. セキュリティコンテキスト: runAsUser、fsGroup、およびその他のセキュリティ設定を、組織のポリシーに合わせて調整します。
  5. Resource allocation: CPU とメモリの値はあくまで例です。想定されるトレース量に基づく適切なサイジングについては、W&B Solutions Architect に相談してください。
  6. Anti-affinity rules: クラスターのトポロジと高可用性の要件に応じて、カスタマイズするか削除します。
  7. Keeper hostnames: Keeper ノードのホスト名は、ステップ 3 の Keeper デプロイメントの命名 (「Keeper naming」) と一致している必要があります。
  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 レプリカが bucket 内のそれぞれ専用のフォルダに書き込むようになります。

認証情報を設定する (Option B のみ)

Step 2 の Option B (アクセスキー) を使用する場合は、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 の名前空間です (例: 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 Platform で Weave を有効にする

次に、Weave のトレースで ClickHouse クラスターを使用するように、W&B Platform を設定します。このステップでは、外部で管理されている 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 Custom Resource を更新する

Weave の設定を追加するには、W&B Platform の Custom Resource (CR) を編集します。
重要な設定:
  • 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 にアクセスする

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

Weave ライセンスの状態を確認する

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

Weave の機能をテストする

Weave が正しく動作していることを確認するために、Python テストを作成します。
これを実行したら、組織内の W&B UI の traces ページでトレースを確認してください。トレースが表示されたら、セルフマネージドの 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 の endpoints と Naming を確認してください:
接続に失敗する場合は、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 operator のログを確認します。

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

リソース要件

このセクションでは、一般的な 2 つのデプロイメントプロファイルに対するリソース割り当ての例を示します。クラスターを計画する際の開始点として使用し、観測されたワークロードに基づいて数値を調整してください。
このセクションのリソース割り当ては、あくまで開始時の目安の一例です。実際に必要となる要件は、以下の要因によって異なります。
  • トレース取り込み量 (1 秒あたりのトレース数)
  • クエリパターンと同時実行数
  • データ保持期間
  • 同時接続ユーザー数
ご利用のユースケースに適したサイジングを判断するため、必ず W&B の Solutions Architect チームに相談してください。リソースが不足するとパフォーマンス上の問題につながる可能性があり、逆に過剰に割り当てるとインフラストラクチャーコストの無駄になります。

本番環境の最小構成

開発、テスト、またはトラフィック量が少ない本番環境に適しています。 トレース量が多い本番ワークロード向け: 高トレース量の本番環境に適しています。 超高ボリュームのデプロイについては、トレース量やパフォーマンス要件に応じたカスタムのサイジング推奨事項について、W&B Solutions Architect チームにお問い合わせください。

高度な設定

このセクションでは、セルフマネージドの Weave デプロイ向けのカスタマイズ オプションについて説明します。これには、垂直スケーリングまたは水平スケーリングによる ClickHouse 容量の拡張、keeper と server の両方の設定でイメージタグを変更して ClickHouse のバージョンを更新すること、さらに ClickHouse の健全性を監視することが含まれます。 インスタンスに高度な変更を加える際は、それらの変更がパフォーマンス要件と信頼性要件に適合していることを確認するため、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. Credentials: ClickHouse のパスワードは、プレーンテキストではなく Kubernetes シークレットに保存してください。
  2. Network policies: ClickHouse へのアクセスを制限するため、NetworkPolicies の実装を検討してください。
  3. RBAC: サービスアカウントには、必要最小限の権限のみを付与してください。
  4. S3 bucket: 保存時の暗号化を有効にし、bucket へのアクセスは必要な IAM ロールのみに制限してください。
  5. TLS: 任意です。本番環境では、ClickHouse クライアント接続で TLS を有効にしてください。

アップグレード

以下の手順では、operator、ClickHouse サーバー、Weave Trace コンポーネントの日常的なアップグレードについて説明します。コンポーネントは一度に 1 つずつアップグレードし、次に進む前に deployment が正常な状態であることを確認してください。
Weave では、サポートされる ClickHouse バージョンが必要です。ClickHouse または W&B Server をアップグレードする前に、アップグレード時の ClickHouse 互換性とサポートされる W&B Server リリースを参照してください。ClickHouse Server と ClickHouse Keeper は一緒にアップグレードしてください。

ClickHouse Operator のアップグレード

ClickHouse Server のアップグレード

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

Weave Trace のアップグレード

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

参考資料

サポート

本番デプロイや問題がある場合:
  • W&B サポート: support@wandb.com
  • ソリューションアーキテクト: 超大規模デプロイ、カスタムサイジング、デプロイ計画について。
  • サポートへの問い合わせに含める内容:
    • weave-trace、ClickHouse pod、operator のログ。
    • W&B バージョン、ClickHouse バージョン、Kubernetes バージョン。
    • クラスター情報とトレース量。

FAQ

Q: 3 つではなく 1 つの ClickHouse レプリカを使用できますか? 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: 示されているアンチアフィニティ ルールは、高可用性のための推奨事項です。クラスターのサイズ、トポロジ、可用性要件に基づいて調整または削除してください。小規模なクラスターや Dev 環境では、アンチアフィニティ ルールが不要な場合があります。