xDev Asia

各サービスに独自のデータベースが必要なのはなぜですか?適切なデータベースを選択するための戦略: PostgreSQL、MongoDB、Redis、Elasticsearch。共有データベースのアンチパターン。データの分離、スキーマの所有権、および移行戦略。

マイクロサービスとマイクロフロントエンドのシステム設計 — 基本から運用まで

パート 3: マイクロサービスのデータアーキテクチャ

xdev.asia

はじめに

「サービスごとのデータベース」はマイクロサービスの基本パターンです。これがなければ、実際のマイクロサービスは存在せず、同じデータベース (分散モノリス) を共有するモジュールだけが存在します。この記事では、その理由、適切な DB の選択方法、データ共有の処理方法について説明します。

サービスごとのデータベース — 各サービスは独自のデータベースを所有します

1. サービスごとにデータベースを使用する理由

1.1 共有データベース — 分散モノリスへの道

❌ Shared Database Anti-pattern:
┌────────┐ ┌────────┐ ┌────────┐
│User µS │ │Order µS│ │Payment │
└───┬────┘ └───┬────┘ └───┬────┘
    │          │          │
    └──────────┼──────────┘
               ▼
    ┌─────────────────────┐
    │  Shared PostgreSQL  │
    │  ├── users          │  ← ai own schema này?
    │  ├── orders         │  ← coupling tại data layer
    │  ├── payments       │  ← thay đổi schema = break all
    │  └── products       │
    └─────────────────────┘

問題:

スキーマの変更はすべてのサービスに影響します
データベースを独立して拡張できない
密結合 - 導入は同時に行う必要があります
ユースケースごとに異なるデータベースを使用することはできません

1.2 サービスごとのデータベース

✅ Database per Service:
┌────────┐    ┌────────┐    ┌────────┐
│User µS │    │Order µS│    │Cart µS │
└───┬────┘    └───┬────┘    └───┬────┘
    │             │             │
    ▼             ▼             ▼
┌────────┐  ┌────────┐    ┌────────┐
│PostgreSQL│ │PostgreSQL│  │ Redis  │
│(users)  │  │(orders) │   │(carts) │
└─────────┘  └─────────┘  └────────┘

Mỗi service own data riêng.
Schema changes chỉ ảnh hưởng 1 service.
Có thể chọn DB phù hợp nhất cho use case.

2. 多言語永続性 — 適切な DB を選択する

2.1 意思決定マトリックス

使用例	データベース	なぜ
ユーザープロフィール、注文	PostgreSQL	ACID、リレーショナル、成熟した
製品カタログ	PostgreSQL + Elasticsearch	リレーショナル + 全文検索
ショッピングカート	Redis	高速、一時的な TTL サポート
セッションストア	Redis	メモリ内、有効期限が短い
アクティビティログ、イベント	MongoDB / Kafka	スキーマに柔軟、追加のみ
推奨事項	Neo4j / Redis	グラフの関係 / キャッシュ
アナリティクス/BI	クリックハウス / BigQuery	列形式の高速集計

2.2 電子商取引プラットフォームのデータベース設計

┌─────────────────────────────────────────────┐
│ User Service → PostgreSQL                   │
│   users, addresses, preferences             │
├─────────────────────────────────────────────┤
│ Product Service → PostgreSQL + Elasticsearch│
│   products, categories, reviews (PG)        │
│   search index (ES)                         │
├─────────────────────────────────────────────┤
│ Cart Service → Redis                        │
│   cart:{userId} → JSON (items, quantities)  │
│   TTL: 7 days (auto-expire abandoned carts) │
├─────────────────────────────────────────────┤
│ Order Service → PostgreSQL                  │
│   orders, order_items, order_status_history  │
├─────────────────────────────────────────────┤
│ Payment Service → PostgreSQL                │
│   transactions, refunds, payment_methods    │
└─────────────────────────────────────────────┘

3. データ共有パターン

サービス A がサービス B からのデータを必要とする場合:

3.1 APIの構成

サービス A は、データが必要なときにサービス B の API を呼び出します。シンプルですが、実行時の依存関係が作成されます。

3.2 イベントを伴う状態転送

サービス B がデータを含むイベントを公開 → サービス A がローカルコピーを保存します。

ProductService publishes: ProductUpdated {id, name, price, image}
OrderService subscribes → lưu product snapshot trong order_items
→ Không cần gọi ProductService khi hiển thị order history

3.3 CQRS (詳細はレッスン 9 を参照)

イベントから読み取りに最適化されたビューを作成します (専用のクエリサービス)。

4. スキーマ移行戦略

各サービスは独自のスキーマを管理します。

Flyway / Liquibase (Java) または Prisma Migrate / Knex (Node.js)
ソースコードでバージョン管理された移行スクリプト
下位互換性のある変更: 列の追加 (NULL 可能)、テーブルの追加
重大な変更: 多段階の移行 (新規追加 → データ移行 → 古いデータの削除)

概要

サービスごとのデータベース は、実際のマイクロサービスでは交渉の余地がありません
ユースケースに応じたDBの選択（ポリグロット永続化）
イベント (推奨) または API 呼び出し によるデータ共有
スキーマの移行は各サービスチームの責任です

次の記事: レッスン 8: Saga パターンと分散トランザクション

レッスン 7: サービスごとのデータベースと多言語の永続性