【2026年最新】QdrantをKubernetesで運用する方法｜冗長化と永続化の設計

定義と基本

QdrantのKubernetes運用とは、Pod固有の永続領域と分散レプリカを分けて設計し、障害時にも検索・更新を継続できる状態を管理することです。

PVCはローカルデータの存続、Qdrantのレプリカはサービス継続を担い、目的が異なります。StatefulSet、Headless Service、PodごとのPVCを基礎とし、ゾーンまたは物理ノードをまたぐ配置を指定します。ストレージは容量だけでなく、IOPS、レイテンシ、拡張可否、障害時の再アタッチ時間を比較します。

ローリング更新では同時停止数を制限し、各ピアの参加状態、レプリカの健全性、検索・書き込み試験を確認してから次のPodへ進めます。PVC保持ポリシー、コレクション削除権限、バックアップ暗号化、復元担当者まで稟議時に明文化すると、永続化をバックアップと誤認する事故を防げます。

公式情報からわかる特徴

2026年9月2日確認の公式分散デプロイ資料では、クラスターモードにより複数サービス間でデータを分散し、保存能力と安定性を高められると説明されています。自己管理版ではQDRANT__CLUSTER__ENABLED=trueで有効化でき、ピア間通信には既定で6335番ポートを使用します。このポートは書き込み操作に使われ得るため、公式も外部アクセスから隔離するよう求めています。

公式OverviewおよびSearch資料で確認できる機能は、密ベクトルと疎ベクトルによるハイブリッド検索、payload条件のフィルタリング、全文検索、再ランキングなどです。ただし、日本語の分かち書き精度や社内略語への適合が自動的に保証されるわけではありません。実データでRecall、誤検索、Top-K、応答時間を測定する必要があります。

公式Monitoring資料では、各ピアがPrometheus/OpenMetrics形式の/metricsを公開します。ロードバランサー越しの一地点だけではなく、全ピアを個別にスクレイプする必要があります。ここから先のアラート閾値、監査ログ保持、認証方式、復旧目標は公式機能だけでは決まらないため、組織のSLAと機密区分に基づく設計判断です。

比較と選定ポイント

冗長化が必要なら、単にQdrantのPod数を増やすのではなく、分散モード、レプリカ、永続ボリューム、障害ドメインを一体で設計します。Qdrant公式資料では分散デプロイをサポートし、peer間通信に既定で6335番ポートを使用します。このポートは書き込みに利用され得るため、外部公開せずNetworkPolicyなどでpeer間に限定する必要があります。

Qdrantはdense vectorに加え、sparse vector、全文検索、payload条件による絞り込み、ハイブリッド検索を提供すると公式資料に記載されています。ただし、日本語検索の品質は製品名だけでは決まりません。埋め込みモデル、形態素解析やsparse生成、チャンク分割、固有名詞・型番の再現率を評価用質問セットで測定してください。

機密情報では、部署・役職・テナントIDなどをpayloadへ保持し、検索時に必ずフィルタする設計が候補です。ただし、アプリケーションから任意条件を渡せるだけでは認可になりません。APIゲートウェイまたはRAGサービス側で本人属性から条件を強制生成し、検索条件、文書ID、利用者、応答結果を監査ログへ残します。厳格な行単位権限やトランザクションが中心なら、pgvectorを含むRDB構成も比較対象です。

導入形態・料金・責任分界

閉域・機密要件とKubernetes運用能力がある企業にはセルフホスト、基盤運用を減らしたい企業にはQdrant Cloudが候補です。料金はクラスタ容量、ストレージ、レプリカ、リージョン、通信量、サポート条件などで変動し得るため、固定額ではなく、2026年9月2日時点の公式料金表と個別見積もりを確認してください。

Kubernetesでの実装基準

• 各peerに専用PVCを割り当て、同一ボリュームを複数peerで共有しない。ストレージのIOPS、遅延、拡張可否、暗号化も確認する。
• PodDisruptionBudgetだけに依存せず、anti-affinity、ゾーン分散、readiness probe、計画停止手順を組み合わせる。
• バックアップはPVCスナップショットだけで完結したと判断せず、Qdrantのスナップショット取得・復元を別環境で定期検証する。
• HTTP・gRPCの利用者向けポートとpeer間ポートを分離し、TLS終端、認証情報をSecret管理し、RBACの変更履歴を監査する。

責任分界と運用費

セルフホストでは、企業側がKubernetes、Qdrantの更新、永続化、容量計画、バックアップ、復旧、脆弱性対応を担います。ライセンス費だけでなく、ノード、複製ストレージ、監視、待機系、運用人件費をTCOへ含めます。Qdrantは各peerの/metricsをPrometheus/OpenMetrics形式で公開し、ロードバランサー越しの一地点ではなく全peerを個別に収集することが公式に推奨されています。

クラウド版でも、データ分類、検索権限、埋め込みモデルへの送信範囲、RAG回答の監査は利用企業側に残ります。稟議ではRPO・RTO、SLA、データ所在地、削除証跡、サポート時間、障害時の連絡経路を明文化し、想定ノード喪失、ゾーン障害、誤削除、バージョン更新を受入試験に含めるべきです。

企業導入の設計・実装

本番環境では、QdrantをStatefulSetとノードごとのPersistentVolumeで構成し、複数Podを異なるKubernetesノードまたは可用性ゾーンへ分散させます。単にPod数を増やすだけでは冗長化にならないため、Qdrantの分散モード、コレクションのシャード数・レプリケーション係数、PVCの障害特性を一体で設計してください。

公式資料で確認できる事実：分散モードはQDRANT__CLUSTER__ENABLED=trueで有効化でき、peer間通信には既定で6335番ポートを使用します。このポートは書き込み操作に利用され得るため、外部公開せず、Headless ServiceとNetworkPolicyでQdrant Pod間だけに限定します。初期peerと参加peerの識別が必要なので、安定したPod名を持つStatefulSetが適します。

編集上の推奨設計：3 Pod以上を起点に、Pod anti-affinityまたはtopology spread constraintsで障害ドメインを分離し、PodDisruptionBudgetで計画停止時の同時退避を制限します。各Podのデータ領域にはReadWriteOnceのPVCを割り当て、ローカルディスクを使う場合はノード消失時の復旧時間を稟議条件へ明記します。レプリカはバックアップの代替ではありません。

RAGデータモデル

Embeddingモデル名・版・ベクトル次元・距離関数をコレクション定義と台帳で固定し、変更時は原則として別コレクションへ再投入します。チャンクにはdocument_id、chunk_id、tenant_id、department_id、acl、source_version、embedding_version、保持期限をPayloadとして付与します。チャンク長は一律に決めず、規程、表、FAQなど文書種別ごとに検索評価を行います。

容量は原文サイズではなく、ベクトル数、次元、Payload、インデックス、レプリカ数、更新時の余白から見積もります。小規模で単一障害点を許容できる検証環境なら1 Podも選択肢です。一方、Kubernetesや分散合意を運用できない組織では、Qdrant Cloud、マネージド検索基盤、PostgreSQL＋pgvectorの方が総運用費を抑えられる場合があります。

日本語検索・セキュリティの実務

日本語RAGでは、Qdrantの配置だけでなくEmbedding、語彙検索、権限制御を同時に検証します。公式資料ではdense vector、sparse vector、Payload条件によるFilter、両者を組み合わせるHybrid Retrievalが示されています。製品型番、法令番号、社内略語などdense検索が落としやすい語は、sparse検索や全文検索との併用候補です。

日本語対応Embeddingを、質問文と実文書から作った評価セットで比較し、Recall@K、回答根拠の採用率、部署別の漏えい件数、P95レイテンシを測定します。文字数だけの分割は見出しや条項を壊すため、見出し階層を保持しつつ適度に重複させます。原文、表題、ページ番号、参照URIはPayloadへ保存し、生成回答から根拠を追跡できるようにします。

権限Filterには認証済みIDから確定したtenant_idやACLを渡し、利用者が送信したPayload条件をそのまま信用してはいけません。Filterは検索範囲を狭める機能であり、単独の認証・認可境界とは扱わず、API GatewayまたはRAGアプリ層で認証、認可、レート制限を実施します。部署・機密区分をまたぐ影響が大きい場合は、コレクションやクラスター自体の分離も検討します。

閉域環境ではHTTP/gRPCの公開先を内部LoadBalancer等に限定し、6335番ポートをNetworkPolicyで隔離します。資格情報はKubernetes Secretと外部Secrets管理基盤で管理し、イメージや設定へ埋め込みません。検索ログには質問全文や取得チャンクを無条件に残さず、利用者IDの仮名化、Payloadのマスキング、保存期間、監査担当者だけが閲覧できる権限を定義します。

監視・更新・バックアップ

監視はKubernetesのPod稼働確認だけでは不十分です。Qdrantは各peerの/metricsからPrometheus/OpenMetrics形式のメトリクスを公開するため、ロードバランサー経由の1地点ではなく全peerを個別にスクレイプします。公式資料で確認できる指標には、バージョン、リカバリーモード、コレクション数、point数、vector数、シャードごとの最小アクティブレプリカ数などがあります。

アラートはPod再起動、OOM、CPU・メモリ・PVC使用率、検索エラー率、P95/P99遅延、アクティブレプリカ不足、インデックス作成停滞を対象にします。メトリクスの一部カウンターは再起動でリセットされるため、Prometheus側で履歴を保持します。アプリケーションログにはrequest ID、tenant、処理時間、Top-K、Filter適用有無、使用モデル版を残し、質問本文や機密Payloadは必要性を審査してから記録します。

更新時は、対象バージョンの互換性と公式アップグレード手順を都度確認し、ステージング環境でスナップショット復元、ローリング更新、検索品質を試験します。PodDisruptionBudgetがあってもQdrant内部のレプリカ状態までは保証しないため、更新前後にクラスター状態とアクティブレプリカを確認し、一度に複数peerを停止しない運用手順を作成します。

バックアップはQdrantのスナップショット機能を利用する場合でも、同一PVC内に置いたままにせず、暗号化したオブジェクトストレージなど別障害ドメインへ転送します。コレクション定義、Payload index、Embeddingモデル、投入元文書、アプリ設定も復旧対象です。RPO・RTOに応じて取得頻度と保持世代を決め、四半期など定期的に空の検証クラスターへ復元し、件数、検索結果、権限Filter、引用元まで照合します。

レプリカ障害、PVC破損、クラスター全損を分けた復旧手順を用意し、再投入可能な原文とEmbeddingパイプラインも保持します。公式情報確認日は2026年9月2日です。使用バージョンによってメトリクスや復旧手順が異なり得るため、導入時には固定したQdrant版の公式資料で再確認してください。

導入手順

本番導入では、先に可用性・データ保護・検索品質の要件を決め、StatefulSetと永続ボリュームを中心に設計します。以下はセルフホスト版QdrantをKubernetesへ配置する標準的な進め方です。

1. 要件と障害範囲を定義する

   ベクトル件数、次元数、更新量、同時検索数、目標レイテンシ、RPO・RTOを整理します。Pod、ノード、Availability Zoneのどこまで耐えるかを決めないまま、レプリカ数だけを増やしても稟議可能な冗長化設計にはなりません。

2. 検索方式とコレクションを設計する

   日本語RAGではdense検索だけでなく、製品番号や固有名詞を拾うsparse検索、全文検索、payload filterを比較します。Qdrant公式資料ではdense・sparseを組み合わせたHybrid Retrievalとフィルタリングが案内されています。評価用質問と正解文書を用意し、Top-Kや再ランキングを測定します。

3. 永続ストレージを選定する

   各Podへ専用PVCを割り当て、再スケジュール後もデータが残るStorageClassを選びます。必要容量にはベクトル、payload、インデックス、一時的な最適化処理、増加余地を含めます。ディスク性能は投入速度と検索遅延に影響するため、検証環境でIOPSも計測します。

4. 分散モードで配置する

   StatefulSet、Headless Service、Pod間通信を構成し、QDRANT__CLUSTER__ENABLED=trueを設定します。公式資料上、内部通信の既定ポートは6335であり、外部公開せず全peer間だけで到達可能にします。初期peerのURIと後続peerのbootstrap先を固定的に解決できる構成にします。

5. レプリカと配置制約を設定する

   コレクションのshard数とreplication factorを、ノード数と障害許容数から決めます。Pod anti-affinityやtopology spread constraintsで同一ノードへの集中を避け、PodDisruptionBudgetで計画停止時の同時退避数を制限します。KubernetesのPod数とQdrantのデータレプリカ数は別概念です。

6. 閉域化・権限・監査を実装する

   NetworkPolicy、Private Load Balancerまたは内部Ingressで通信元を限定し、認証情報はSecretで管理します。部門・テナント分離をpayload filterだけに依存すると実装漏れが起こり得るため、API層で認可を強制します。操作主体、対象コレクション、検索・更新結果を追跡できる監査ログも別途設計します。

7. 監視、バックアップ、復旧試験を行う

   公式資料では各peerの/metricsをPrometheus/OpenMetrics形式で取得できます。ロードバランサー越しの一地点ではなく全peerを個別にscrapeし、容量、遅延、エラー、active replica数を監視します。レプリケーションは誤削除対策ではないため、スナップショットの外部保管と定期リストア試験を実施してから本番化します。

向くケース・向かないケース

Qdrant on Kubernetesは、既存のKubernetes運用基盤を利用しながら、検索構成やデータ配置を自社で制御したい組織に向きます。一方、運用要員や復旧試験の時間を確保できない場合は慎重な判断が必要です。

向くケース

• 機密文書を閉域内に置き、外部SaaSへの送信を制限したい
• 日本語の意味検索と固有語検索を組み合わせ、payload条件で部署や文書属性を絞りたい
• Prometheus、Kubernetes監視、バックアップ基盤を既に運用している
• データ量や負荷に応じ、shardとreplicaを明示的に設計したい

向かないケース

• 小規模検証で、分散構成の運用コストが検索基盤の価値を上回る
• データベース担当者がおらず、夜間障害や容量逼迫へ対応できない
• 厳格な文書単位認可をデータベースだけで完結できると期待している
• ベクトル検索が不要で、既存RDBや全文検索エンジンだけで要件を満たせる

後者ではQdrant Cloud、他社のマネージドVector Database、PostgreSQL拡張、OpenSearchなども、機能だけでなく運用費と監査要件を含めて比較します。

導入前チェックリスト

次の項目に未回答がある場合、Podを配置する前に設計レビューを行います。

1. 年間のベクトル件数、次元数、payload容量、増加率を見積もったか
2. 許容停止時間、許容データ損失、想定するノード・AZ障害を定義したか
3. PVCの拡張、再接続、障害時の復旧挙動を対象StorageClassで検証したか
4. shard数、replication factor、Pod数の関係を文書化したか
5. 6335番ポートを外部から遮断し、peer間通信だけに限定したか
6. 機密区分、テナント認可、Secret更新、監査ログの責任者を決めたか
7. 日本語のdense・sparse・hybrid検索を実データで比較したか
8. 全peerのメトリクス、容量、レプリカ異常に対する通知を設定したか
9. スナップショットの外部保管、暗号化、保持期間、リストア手順を確認したか

結論

QdrantをKubernetesで安定運用する要点は、StatefulSetを置くことではなく、PVC、分散モード、データレプリカ、障害領域、外部バックアップを一体で設計することです。閉域接続、認可、監査、日本語検索品質も導入判断に含めます。

既存のKubernetes運用能力があり、構成を自社管理する必要があるなら有力な選択肢です。専任運用者を置けない場合は、マネージドサービスや既存検索基盤を含む総保有コストで比較するのが現実的です。

一次情報・参考リンク

• Qdrant Documentation – Overview
• Qdrant Search
• Qdrant Distributed Deployment
• Qdrant Monitoring