0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@kiyotaman(清田 史和 Fumikazu Kiyota)

Kagura Memory Cloud アーキテクチャ概要

0
Posted at

Kagura Memory Cloud は、本番運用を前提に設計された、モダンでスケーラブルなアーキテクチャで構築されています。チーム規模で LLM Knowledge Base パターン（Karpathy の LLM Wiki）を実装しています。詳細は下記の LLM Knowledge Base — 5 層マッピング を参照してください。

LLM Knowledge Base — 5 層マッピング

Karpathy のパターンでは、あらゆる「生きたナレッジベース」を 5 つの層として捉えます。Kagura での実装は次のとおりです。

Layer Karpathy の意図 Kagura での実装 コード上の場所
Ingest 生のソースを取り込む REST /api/v1/memory、MCP remember、R2 ファイルストレージ（バイナリ Blob）、外部フィード用のリソーストークン backend/src/api/routes/memory.py, backend/src/api/routes/files.py, backend/src/services/resource_indexer.py
Compile LLM が生データを構造化された Wiki ページへ書き換える MCP-as-compile-API: チャットエージェントが、事実ごとに構造化された remember(summary, content, type, tags, importance) を発行する（継続的なマイクロコンパイル）。Sleep Maintenance の各フェーズ（統合、重複排除、エッジ形成）がバッチ統合を担う。 backend/src/mcp_server/tools/memory.py, backend/src/services/sleep/orchestrator.py
Index ナビゲーションのためのページ単位 TOC 自動管理されるトリプルインデックス: BM25（キーワード）+ Qdrant ベクトル（セマンティック）+ Hebbian グラフ（関係性）。コンテキスト単位の TOC は list_contexts / get_context_info で提供。 backend/src/services/search_service.py, backend/src/services/graph_service.py, Qdrant collection
Query 必要に応じてページを直接読み、検索する Hybrid Search（セマンティック 60% + BM25 40%）、AI Reranker（Voyage / Cohere / Ollama）、偶発的発見のための explore グラフ探索 backend/src/services/search_service.py, backend/src/services/reranker_service.py
Enhance 複利的ループ — 回答が新しいページとしてフィードバックされる Hebbian learning: recall() のたびに、同時に取得されたメモリ間のエッジを強化する（LLM コストゼロのバックグラウンド・グラフ進化）。Sleep Maintenance が定期的に再編成する。明示的な書き戻し: /kagura-memory:session-summary スキルが、合成された回答を新しいメモリとして保存するようユーザー/エージェントに促す。ノイズ回避のためオプトイン。 backend/src/neural/, backend/src/services/sleep/, claude-skills/session-summary.md

Karpathy のパターンとの違い: Kagura はチーム/組織規模（マルチテナント DB）を対象にしており、各 remember() をマイクロコンパイル（継続的）として扱います。一方、LLM Wiki パターンは、個人規模（約 100 件の Markdown ページ）を対象とし、Wiki の一括書き換えを想定しています。コンパイルインターフェースは、自由形式の文章ではなく、Pydantic MemoryCreate によってスキーマ強制されます。

システムアーキテクチャ

┌─────────────────────────────────────────────────────────────┐
│                     Client Applications                      │
│  (Claude Desktop, Claude Code, ChatGPT, Web UI, Custom)     │
└─────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────┐
│                    Authentication Layer                      │
│  OAuth2 (Google, GitHub) │ API Keys │ JWT Tokens            │
└─────────────────────────────────────────────────────────────┘
                              ↓
┌──────────────────────┬──────────────────────────────────────┐
│   MCP Server (HTTP)  │          REST API (FastAPI)          │
│  - 45 MCP Tools      │  - Memory CRUD                       │
│    (memory / agent   │  - OAuth2 endpoints                  │
│     substrate / edges│  - API Key management                │
│     / contexts / tags│  - Agent state + feedback lanes      │
│     / files /analyses│  - Resource Ingest API               │
│     / resources /    │  - Admin: sleep-reports, neural cfg  │
│     sleep / usage)   │                                      │
│  - Session Mgmt      │                                      │
│  - JSON-RPC          │                                      │
└──────────────────────┴──────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────┐
│                      Service Layer                           │
│  MemoryService │ SearchService │ EmbeddingService           │
│  GraphService │ NeuralMemoryEngine │ WorkspaceService       │
│  PermissionService │ SleepService │ LLMService              │
│  ResourceIndexer │ ContextService │ QuotaService            │
└─────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────┐
│                     Data Access Layer                        │
│  SQLAlchemy async models (backend/src/models/)              │
│  + service-owned queries (no dedicated repository layer)    │
└─────────────────────────────────────────────────────────────┘
                              ↓
┌──────────────┬──────────────┬──────────────┬───────────────┐
│  PostgreSQL  │   Qdrant     │    Redis     │  External API │
│  - Memories  │  - Vectors   │  - Sessions  │  - OpenAI     │
│  - Workspace │  - BM25      │  - Cache     │  - Cohere     │
│  - Resources │  (single     │  - Rate Lmt  │  - Stripe     │
│  - Graph     │   collection)│              │               │
└──────────────┴──────────────┴──────────────┴───────────────┘

3 層メモリアーキテクチャ

Layer 1: Summary

  • 目的: 高速な検索と取得
  • 内容: 簡潔な要約（10〜500 文字）
  • 保存先: PostgreSQL + Qdrant ベクトル
  • ユースケース: 初期検索結果

Layer 2: Context Summary

  • 目的: 文脈理解
  • 内容: 中程度の説明（最大 2000 文字）
  • 保存先: PostgreSQL
  • ユースケース: 検索結果プレビューの表示

Layer 3: Details

  • 目的: 完全な情報
  • 内容: 全文 + 構造化メタデータ（JSON）
  • 保存先: PostgreSQL
  • ユースケース: 選択後の詳細表示

ハイブリッド検索システム

User Query
    ↓
┌─────────────────────────────┐
│  Query Processing           │
│  - Tokenization             │
│  - OpenAI Embedding         │
└─────────────────────────────┘
    ↓
┌──────────────┬──────────────┐
│  Semantic    │   BM25       │
│  (Vector)    │  (Keyword)   │
│  60% weight  │  40% weight  │
└──────────────┴──────────────┘
    ↓               ↓
Results A       Results B
    └───────┬───────┘
            ↓
    ┌───────────────┐
    │  Fusion       │
    │  (Weighted)   │
    └───────────────┘
            ↓
    ┌───────────────┐
    │  Cohere       │
    │  Reranking    │
    └───────────────┘
            ↓
      Final Results

検索ウェイト

  • セマンティック検索: 60%（意味の一致に強い）
  • BM25 全文検索: 40%（正確なキーワード一致に強い）
  • リランキング: Cohere multilingual-v3.0

Neural Memory Engine

エッジの由来

Neural Memory のエッジは origin 判別子（neural_memory_edges.origin, VARCHAR(20), CHECK constraint valid_edge_origin）を持ちます。この値によってエッジの寿命が制御されます。値は 3 種類あります。

hebbian semantic declared
Source HebbianLearner における実行時の同時活性化（recall() の書き込み側 — Issue #120 参照） Sleep の edge_discovery（cosine sim ≥ 0.5） MCP create_edge によるユーザー明示
Weight rule § Formulas を参照 — Δw_ij ← η · (a_i · C_i) · (a_j · C_j) − λ · w_ij。0.0〜3.0 にクランプ 作成時の cosine_sim（0.5〜1.0）。decay による変更なし ユーザー指定（デフォルト 1.0）
Decays あり — 夜間の DecayManager.bulk_decay_weights(only_origin='hebbian') なし なし
Pruned あり — prune_threshold 未満なら DecayManager.prune_weak_edges(only_origin='hebbian') なし なし
Re-verified 対象外 月次の semantic_edge_reverify cron が、エンドポイントのメモリが soft-delete された行を削除 対象外

Sticky-upsert invariant: create_or_update_edge の upsert パスは一方向です。実行時の Hebbian co-recall 書き込み（常に origin='hebbian'）は、既存の semantic または declared エッジを hebbian に降格させることができません。origin は upsert 内部で導出されるのではなく呼び出し元によって設定されるため、昇格は非 Hebbian の書き手が非 Hebbian origin を明示的に選んだときだけ発生します。実行時に非 Hebbian origin を生成する書き手は、正確に 2 つです。Sleep maintenance の edge_discovery フェーズ（backend/src/services/sleep/edge_discovery.py）は origin='semantic' を書き込み、MCP create_edge ツール（backend/src/mcp_server/tools/edge.py）は origin='declared' を書き込みます。（単発の backend/scripts/backfill_semantic_edges.py 移行スクリプトも origin='semantic' を書き込みますが、これは実行時の書き込みパスではありません。）実行時の Hebbian co-recall は非 Hebbian origin を選ばないため、既存の非 Hebbian エッジをそのまま残すことしかできません。この不変条件は「双方向の昇格」ではなく「降格しない」ことです。

neural_memory_edges を維持するバックグラウンドジョブ:

  • DecayManager（夜間） — origin='hebbian' の行にのみ指数減衰を適用し、しきい値未満の pruning を行う。semantic と declared の行はスキップされる。
  • semantic_edge_reverify（毎月 1 日 04:15 UTC） — origin='semantic' の行を走査し、エンドポイントのメモリが soft-delete されている場合に削除する。計算量は O(edges) であり O(memory²) ではないため、コンテキストが大きくなっても低コストに保てる。

数式

Hebbian update（backend/src/neural/hebbian.py — recall() ごとに、semantic-gating しきい値 min_similarity_for_edge を満たした同時活性化ペアへ適用）:

Δw_ij ← η · (a_i · C_i) · (a_j · C_j) − λ · w_ij
  • η — 学習率（config.learning_rate）
  • a_i, a_j — 同時活性化したノードの活性化強度
  • C_i, C_j — 各ノードの信頼度 / trust score（poisoning defense。低信頼ノードの寄与を小さくする）
  • λ — 更新ごとに適用される L2 decay 係数（重みの爆発を防ぐ。下記の夜間の時間ベース decay とは別）
  • w_ij — 現在のエッジ重み。[0.0, 3.0] にクランプされる

時間ベース decay（backend/src/neural/decay.py — origin='hebbian' のみに夜間適用）:

w_ij(t + Δt) = w_ij(t) · exp(−decay_rate · Δt)

decay 後、w_ij < prune_threshold の行は prune_weak_edges によって削除されます。semantic と declared の行は構造上 decay の対象外（only_origin='hebbian' フィルタ）なので、どれだけ Δt が大きくても残り続けます。これが、N が増えても内容ベースのエッジを生存させるための重要な性質です。

エッジのライフサイクル

hebbian
  recall() co-activation                 reinforced by next co-recall
  + semantic gating passed         ┌─► weight rises (Δw_ij update)
       │                           │
       ▼                           │
  create_or_update_edge ───────────┘
  (origin='hebbian')               not reinforced
       │                          ┌─► nightly DecayManager
       ▼                          │   weight *= exp(−decay_rate · Δt)
  edge exists ────────────────────┘
       │                          weight < prune_threshold
       └──────────────────────────► prune_weak_edges() removes row

semantic
  sleep edge_discovery
  + cosine_sim ≥ min_similarity_for_edge
       │
       ▼
  create_or_update_edge ──► edge exists (origin='semantic')
  (origin='semantic',           │
   weight=cosine_sim)           │   endpoint memory soft-deleted
                                └─► monthly semantic_edge_reverify removes row
                                    (never touched by DecayManager)

declared
  MCP create_edge tool
       │
       ▼
  create_or_update_edge ──► edge exists (origin='declared')
  (origin='declared')           │
                                │   MCP delete_edge / update_edge
                                └─► row removed or weight updated
                                    (never touched by DecayManager or reverify)

Sticky-upsert detail: co-recall によって、すでに semantic または declared エッジが存在するペアに対して create_or_update_edge が呼ばれた場合でも、既存行の origin は保持されます（降格しません）。Hebbian の数式によって weight は変更される場合がありますが、その行は夜間 decay ループの対象外であり続けます。

読者向けの説明（海馬 / 大脳皮質のアナロジーや 1/N² の動機）については、concepts doc の Neural Memory § Edge Origins を参照してください。移行履歴、デプロイ runbook、backfill 手順については docs/operations/semantic-edge-rollout.md を参照してください。Memory.scope（working / persistent）のライフサイクルについては Sleep Maintenance を参照してください。これは edge origin とは直交しており、Sleep Consolidation によって管理されます。

Note: 上記のスキーマは v0.16.x 時点で出荷済みの状態を反映しています。より豊かな 2 軸の provenance スキーマ（relation × origin × frozen flag）は RFC #84 として設計中であり、将来のリリースでこの分類を拡張する可能性があります。

Activation Spreading

seed memory からのグラフベース探索:

Seed Memory
    ↓
  [depth=1]
    ├── Related Memory 1 (weight=0.9)
    ├── Related Memory 2 (weight=0.7)
    └── Related Memory 3 (weight=0.5)
         ↓
       [depth=2]
         ├── Sub-related 1 (weight=0.8)
         └── Sub-related 2 (weight=0.6)

Parameters:

  • depth: 最大ホップ数（デフォルト: 2、最大: 5）
  • min_weight: 最小エッジ重み（デフォルト: 0.5）
  • relation_types: relation type によるフィルタ

Unified Scoring

複数のシグナルを組み合わせます。

score = (
    0.4 * semantic_score +
    0.3 * graph_score +
    0.2 * temporal_score +
    0.1 * trust_score
)

Agent Memory Substrate Lanes

人間向けナレッジベースに加えて、Kagura は agent memory substrate でもあります（epic #885, v0.24.0 / v0.25.0）。自律エージェントのループには、セマンティックメモリストアが直接提供すべきではない 3 つのものが必要です。すなわち、永続的な完全一致スクラッチ状態、明示的な有用性シグナル、そして振る舞いに影響してよい情報を区切る provenance/trust 境界です。これらは memories の横に置かれる専用 lane として提供されます。意図的に別テーブルに分離することで、クエリ時にフィルタするのではなく、構造的に recall() から除外されます。読者向けの概念モデル（4 つのプリミティブ — delivery / trust / state / feedback — と「新しい type ではなく primitive」という判断）については、Concepts › Agent Memory Substrate を参照してください。

Lane separation

Lane Table recall() に含まれるか 別 lane にしている理由
Knowledge memories Yes（Hybrid Search） 検索対象のコーパス
Agent state agent_states No key→value の完全一致スクラッチ（task、plan step、cursor）。これをセマンティック検索しても意味がなく、結果を汚染する
Feedback retrieval_feedback No recall 品質に関する append-only シグナル。embedding すると feedback-of-feedback ループを作ってしまう

agent_states は set_state / get_state（MCP）および /api/v1/contexts/{id}/state*（REST）から読み書きされます。retrieval_feedback は feedback（MCP）および POST /api/v1/contexts/{id}/feedback（REST）から扱われます。どちらも contexts に対して ON DELETE CASCADE で FK しているため、エージェントの state と feedback はコンテキストとともに削除されます（GDPR/APPI erasure に自動追従）。

Trust boundary（provenance と振る舞いに影響する read）

substrate はサーバー強制の trust boundary を追加します。これにより、信頼されていない外部コンテンツが、暗黙のうちに指示として扱われることを防ぎます（間接プロンプトインジェクション — OWASP LLM01 / LLM03）。

  • memories.source_type（VARCHAR(20), NOT NULL, CHECK） — サーバーが stamp する provenance。クライアントからは供給されない。値は manual / file / url / vault / api / connector。既存行は migration e35_887 によって manual に backfill。
  • contexts.trust_tier（VARCHAR(20), NOT NULL, default trusted, CHECK） — trusted または external。connector-fed contexts は external。
  • Trust filter — recall(filters={"trust_tier": "trusted"}) は、context が external tier のメモリ、および source_type="connector" のメモリを除外します（defence-in-depth）。MemoryService の recall 内部（backend/src/services/memory_service.py）で適用されます。オプトインであり、結果をモデルのコンテキストへ戻す read に使うことを想定しています。

Feedback eval gate — 自己更新ループを作らない

feedback シグナルは将来的な Eval→Skill 自己更新ループの前提条件ですが、そのループを閉じるには gate があります。golden retrieval eval gate（#344）が green になるまでは、feedback をもとにメモリを昇格、降格、再ランキング、書き換えする仕組みは出荷しません。eval harness（backend/tests/eval/ — leakage check、corpus-schema、stratification、metrics）の決定的レイヤーは通常の CI で実行されます。live P@5 / MRR measurement（make eval-retrieval）が数値的な regression gate ですが、まだ CI には接続されていません（#336）。完全なポリシーは Retrieval Feedback & Eval Gate を参照してください。

Connector canonical chat schema

setup_connector（#910 / #911）で provision された connector は、登録時に canonical chat resource schema を seed します。これは単一の text フィールド（fulltext+vector indexed）で、ai-worker によるメッセージ単位の LLM 要約を保持します。lineage（source_uri / memory details）は payload ではなく event_metadata に保持されます。定義は ConnectorProvisioningService（backend/src/services/connector_provisioning.py）にあります。

データベース設計

PostgreSQL Tables

テーブルはドメイン別にグルーピングされています。正式な一覧は backend/src/models/ にあります。

Identity & access

  • users — ユーザーアカウント
  • api_keys — API key 管理（SHA256 hash）
  • external_api_keys — OpenAI/Cohere key（Fernet 暗号化）
  • oauth_clients / oauth_authorization_codes / oauth_tokens — OAuth2 server
  • audit_logs — セキュリティ関連の監査ログ

Workspaces & contexts（最上位 tenancy）

  • workspaces — 最上位の組織単位（team / project owner）
  • workspace_members — role assignment（Owner / Admin / Member / Viewer）
  • workspace_invitations — pending invitation
  • workspace_addons — workspace ごとの addon entitlement
  • contexts — workspace に scoped された memory namespace
  • context_members — context ごとの access（private / shared）
  • context_search_configs — context ごとの hybrid search weights と reranker tuning

Memories & graph

  • memories — 3 層メモリストレージ。サーバーが stamp する source_type（provenance）と delivery_mode（on_recall / always / on_trigger）を持つ
  • attachments — memories に紐づくファイル添付
  • neural_memory_edges — 主要な Hebbian edge storage（workspace + context scoped）
  • graph_memory — legacy NetworkX JSON（read path はまだ参照しているが、新規 write は neural_memory_edges へ行う）

Agent memory substrate（epic #885, v0.24.0 / v0.25.0 — Agent Memory Substrate Lanes 参照）

  • agent_states — context ごとの key→value JSON scratch state。任意の TTL（expires_at）を持つ。(context_id, key) で unique。構造的に recall() から除外される
  • retrieval_feedback — (context_id, memory_id) ごとの append-only helpful signal。user_id に帰属。構造的に recall() から除外される
  • （contexts.trust_tier + memories.source_type が provenance/trust boundary を追加する。上記のカラム説明を参照）

Resource ingest（v0.12.0 Resource Foundation）

  • resources — 正規化された Resource entity（UUID PK）。satellite tables は resource_pk 経由で FK
  • resource_events — append-only event log（upsert / delete events）
  • resource_schemas — Resource ごとに宣言された versioned schema
  • indexer_state — (resource, context) ごとの indexer cursor と error metrics
  • resource_tokens — Resource ごとの ingest token（workspace-scoped）

Plans, quotas & sleep

  • user_plans / plan_changes — plan state と履歴
  • usage_stats — rate-limit と quota counter
  • sleep_reports — Sleep Maintenance 実行ごとの summary
  • sleep_actions — reversible action audit log（rollback_sleep_run で使用）

Configuration

  • neural_config — workspace ごとの neural engine config
  • config_overrides — system-level config override
  • mcp_tool_descriptions — admin-editable な MCP tool description override

Qdrant Collections

設計: embedding model ごとに単一の共有 collection を持ち、payload filter で scope を分離します。

  • Default collection: kagura_memories（OpenAI text-embedding-3-small, 512 dims）
  • 非 default model: kagura_memories_{model_slug}_{dim}（例: kagura_memories_qwen3_embedding_8b_4096）
  • Name resolution: backend/src/db/qdrant.py の get_collection_name(model, dimensions)
  • Isolation: すべての point は payload に workspace_id + context_id を持ち、検索時には Qdrant filter が追加される
  • Named vectors: dense（VectorParams）+ bm25（SparseVectorParams）。anonymous vectors は拒否される
  • Distance metric: Cosine
  • Tokenizer: Multilingual（日本語を自動サポート）

Features:

  • セマンティックベクトル検索
  • 全文 BM25 検索（MatchText + sparse vector）
  • メタデータフィルタリング（workspace / context / tags / importance）

従来の「1 user = 1 collection」設計（kagura_user_{user_id}）は single-collection migration によって置き換えられました。新規 deployment には per-user collection は残っていません。

Redis Storage

  1. Sessions: session-based authentication（7 日 TTL）
  2. Cache: embedding cache、search results
  3. Rate Limiting: key ごとの request counter

セキュリティアーキテクチャ

Authentication Flow

User → OAuth2 Login → Session Cookie → Access Token
                                    ↓
                            API Key Creation
                                    ↓
                        External API Access

Authorization Model

Authorization は workspace-scoped RBAC です。認証済みのすべての request は、データアクセス前に (user, workspace, context) の triple として解決されます。

System roles（users 上の flag）:

  • System admin: operator-level access（user management、system config、admin API endpoints）
  • Standard user: default — workspace membership によって scoped

Workspace roles（workspace_members row ごと）:

  • Owner: billing、members、contexts、memories、settings
  • Admin: members と shared contexts の管理、memories の read/write
  • Member: assigned contexts 内の memories の read/write
  • Viewer: assigned contexts への read-only access

Context-level privacy:

  • Private（is_private=true）: 作成者のみアクセス可能
  • Shared（is_private=false）: 適切な role を持つすべての workspace member がアクセス可能

すべての check は backend/src/services/permission_service.py の PermissionService を経由します。client が raw workspace_id を supply しても、server-side verification なしに信頼されることはありません。

Encryption

  • API Keys: SHA256 hash storage
  • External API Keys: Fernet symmetric encryption
  • JWT Tokens: HS256 signing（1 時間 expiration）
  • OAuth2 Secrets: SHA256 hash storage

Signup Gate

admin-configurable な signup gate（backend/src/services/signup_gate_service.py）は、OAuth callback の user-creation step の前に置かれます。これは GitHub と Google の両方に一様に適用されます（#655 以降。もともとの #358 Phase 1 design は Google Consent Screen の test-user list を信頼していましたが、この list は sensitive scopes では厳格に強制される一方、basic profile scopes では click-through できてしまうためです）。

Match key: signup_allowlist の (provider, subject_id)。subject_id は IdP の不変 identity です（github row では GitHub numeric ID、google row では OIDC sub claim）。email は matching に使いません。email を使うと IdP 側での email-change attack を再び開いてしまうためです。

Modes（singleton signup_gate_config.mode）:

  • manual: (provider, subject_id) が allowlist にあり、state='active' の場合にのみ signup を許可
  • github_sponsors / both: Phase 2（現時点では GitHub に対して NotImplemented。Google は sponsorship が GitHub 固有であるため manual に fallback）

Blocked signup observability: blocked attempt はすべて audit_logs（action=signup_blocked）に記録されます。email は HMAC 化され、plaintext では保存されません。triage のため IP / User-Agent も記録されます。/signup-blocked?provider=<p>&sub=<first8> への blocked redirect により、frontend は完全な identity を漏らさずに admin-contact prompt を表示できます。

Admin API: POST /api/v1/admin/signup-gate/allowlist は {github_username}（legacy GitHub shape）または {provider: "google", email} を受け付けます。Google の追加では、既存の users row から OIDC sub を解決します。つまり、invitee は allowlist 登録前に少なくとも一度 Google OAuth を完了している必要があります（email による pre-OAuth invitation は Phase 2 follow-up）。

スケーラビリティ上の考慮

Horizontal Scaling

  • Backend: stateless FastAPI（replica で scale）
  • Frontend: Next.js static export（CDN-ready）
  • Database: PostgreSQL connection pooling（asyncpg）
  • Redis: cluster mode support

Performance Optimizations

  • Async I/O: すべての database operation は async
  • Connection Pooling: PostgreSQL（最大 20）、Redis（10）
  • Caching: embedding 用 Redis cache（60 分 TTL）
  • Batch Processing: APScheduler による background tasks

Resource Usage（per instance）

  • CPU: 2〜4 cores（推奨）
  • Memory: 4〜8 GB（推奨）
  • Storage: 1000 memories あたり約 100 MB（PostgreSQL + Qdrant）

デプロイアーキテクチャ

┌──────────────────────────────────────┐
│         Load Balancer (GCP)          │
└──────────────────────────────────────┘
              ↓
┌──────────────────────────────────────┐
│      Backend Instances (Docker)      │
│  - your-domain.com (production)      │
│  - localhost:8080 (development)      │
└──────────────────────────────────────┘
              ↓
┌──────────────────────────────────────┐
│     Managed Services (GCP)           │
│  - Cloud SQL (PostgreSQL)            │
│  - Qdrant Cloud                      │
│  - Memorystore (Redis)               │
└──────────────────────────────────────┘

技術スタック

Layer Technology Version
Backend FastAPI 0.115+
Database PostgreSQL 15+
Vector DB Qdrant 1.15+
Cache Redis 7+
Frontend Next.js 16
ORM SQLAlchemy 2.0+（async）
Auth Authlib 1.3+
AI OpenAI API Latest
Reranking Cohere API Latest
Graph NetworkX 3.0+

Monitoring & Observability

Logging

  • Format: structured JSON logs（structlog）
  • Levels: DEBUG, INFO, WARNING, ERROR
  • Destinations: stdout（Docker）, CloudWatch（prod）

Metrics（Future）

  • request latency（p50, p95, p99）
  • error rates
  • database query performance
  • memory usage per user

Health Checks

  • /health - basic health check
  • /api/v1/info - detailed system info
  • database connection status
  • Qdrant connection status
  • Redis connection status

今後の拡張

  1. Multi-region Deployment: global CDN + regional databases
  2. Real-time Collaboration: shared memories 向け WebSocket support
  3. Advanced Analytics: user behavior insights、usage patterns
  4. Custom Embeddings: 特定 domain 向け fine-tuned models
  5. GraphQL API: 複雑な query のための REST 代替
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?