121 lines
11 KiB
Markdown
121 lines
11 KiB
Markdown
---
|
||
title: Microservices.io — Database per Service Pattern (Multi-Tenancy 인접 추론)
|
||
source_type: official-doc
|
||
url: https://microservices.io/patterns/data/database-per-service.html
|
||
archive_url:
|
||
status: raw
|
||
confidence: medium
|
||
tags: [ca-multi-tenancy, microservices-io, patterns]
|
||
related_projects: [ca-skeleton-operational-contract]
|
||
related_branches: [feature-tenant-context-policy, feature-repository-access-permission-contract]
|
||
created: 2026-05-22
|
||
last_reviewed: 2026-05-27
|
||
---
|
||
|
||
# Microservices.io — Multi-tenancy and Service Decomposition
|
||
|
||
> Layer: `raw/official-docs/` — Chris Richardson 의 microservices.io 패턴 카탈로그 "Database per Service" 페이지. database-per-service 패턴이 database-per-tenant 로 확장될 때의 trade-off 를 동일 원리로 적용 가능한 인접 자료.
|
||
> 검증된 요약은 `/ingest` 후 `wiki/concepts/`에 별도 작성.
|
||
> **출처 등급 주의**: microservices.io 는 vendor 가 아니라 author (Chris Richardson) 의 pattern catalog. 본 wiki 의 source_type 분류는 `official-doc` 으로 유지하나, Strength 는 `tutorial` 또는 `engineering-blog` 로 강등 (multi-tenancy 를 직접 다룬 페이지가 아니라 인접 패턴에서 추론하므로 confidence: medium).
|
||
|
||
## Parent / 활용 branch (필수)
|
||
|
||
| Branch | 이 자료가 정당화하는 결정 |
|
||
|---|---|
|
||
| [[raw/branch-notes/feature-tenant-context-policy]] | Topic 6 Multi-tenancy 대안 4 (database-per-tenant = full silo) 의 패턴 baseline. database-per-service 의 isolation/coupling trade-off 를 tenant 차원으로 확장 적용. |
|
||
| [[raw/branch-notes/feature-repository-access-permission-contract]] | CROSS_TENANT_ADMIN capability 가 database-per-tenant 전략에서 connection routing 레이어로 구현될 가능성 검토 근거. |
|
||
| [[raw/project-notes/ca-skeleton-operational-contract]] | §18 Control Plane Contract (Tenant Context Policy) 의 database-per-tenant 대안 평가 reference. |
|
||
|
||
## 컨텍스트 / 왜 저장했는지
|
||
|
||
microservices.io 는 outbox 와 동일한 신뢰도의 패턴 카탈로그. multi-tenancy 를 단일 단위 패턴으로 다루지는 않으나 **database-per-service** 논리가 **database-per-tenant** 로 확장될 때의 trade-off 를 동일 원리로 적용 가능.
|
||
|
||
## 출처 / Source
|
||
|
||
- 원본 URL: https://microservices.io/patterns/data/database-per-service.html
|
||
- 관련: "Saga", "Shared database" anti-pattern 논의
|
||
- 아카이브 URL: (미수집)
|
||
- 저자 / 조직: Chris Richardson, microservices.io
|
||
- 발행일: rolling docs (패턴 카탈로그)
|
||
- 마지막 확인일: 2026-05-27
|
||
- **재검증 상태 (2026-05-27)**: WebFetch 로 페이지 재확인 — **부분 검증**. C1 (loose coupling pros / multi-service transaction cons) 은 현재 페이지의 "Resulting context" 섹션에 2개의 별도 bullet 으로 존재 ("Helps ensure that the services are loosely coupled. Changes to one service's database does not impact any other services." + "Implementing business transactions that span multiple services is not straightforward.") — 2026-05-25 capture 의 단일 문장 형태는 paraphrase. C2 (Shared database anti-pattern verbatim) 및 C3 (regulatory/performance isolation verbatim) 는 현재 페이지 본문에서 verbatim 발견 불가 — `needs-confirmation` 유지. 자료 성격은 author (Chris Richardson) 의 pattern catalog 으로 `engineering-blog` 수준 유지.
|
||
|
||
## 핵심 인용 / Key quotes (verbatim, 2026-05-22 작성 시 인용)
|
||
|
||
> [§Database per Service — 2026-05-25 capture (paraphrase 으로 판명)] "Each service has its own database. ... Pros: loose coupling. Cons: implementing business transactions that span multiple services is more complex."
|
||
>
|
||
> [§Database per Service / Resulting context — 2026-05-27 verified, 2개 별도 bullet] (Pros bullet) "Helps ensure that the services are loosely coupled. Changes to one service's database does not impact any other services." / (Cons bullet) "Implementing business transactions that span multiple services is not straightforward."
|
||
|
||
> needs-confirmation [§Shared database anti-pattern — 2026-05-25 capture, 2026-05-27 페이지에서 verbatim 발견 실패] "Shared database is an anti-pattern in microservices because it creates runtime coupling and deployment coupling." — 현재 페이지에는 link reference "The Shared Database anti-pattern describes the problems that result from microservices sharing a database" 만 존재. 원문 verbatim 미확인 → `needs-confirmation` 유지.
|
||
|
||
> needs-confirmation [§Trade-offs — 2026-05-25 capture, 2026-05-27 페이지에서 verbatim 발견 실패] "When isolation is required (e.g., regulatory, performance), separate databases are appropriate; otherwise, the operational cost may outweigh the benefit." — 현재 페이지에 해당 문장 부재. archive.org 또는 별도 microservices.io 페이지 (multi-tenancy 전용) 에 있을 가능성 — 미검증 → `needs-confirmation` 유지.
|
||
|
||
## Claims Extracted / 추출된 주장
|
||
|
||
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|
||
|---|---|---|---|---|---|
|
||
| MSIO-DBPS-C1 | Database per service 패턴 — 각 서비스가 자체 DB 보유; pros = loose coupling, cons = multi-service transaction 구현 복잡 | [§Database per Service / Resulting context — 2026-05-27 verified] (Pros) "Helps ensure that the services are loosely coupled. Changes to one service's database does not impact any other services." / (Cons) "Implementing business transactions that span multiple services is not straightforward." | `engineering-blog` (microservices.io 는 Chris Richardson 의 pattern catalog 이며 official vendor doc 아님) | microservices 아키텍처 일반 | 본 패턴이 그대로 multi-tenancy 에 적용된다는 직접 주장은 본 페이지에 없음 — 외부 추론. 2026-05-25 의 단일 문장 capture 는 두 별도 bullet 의 paraphrase |
|
||
| MSIO-DBPS-C2 | Shared database 는 microservices anti-pattern (runtime coupling + deployment coupling 유발) | [§Shared database anti-pattern — 2026-05-25 capture, 2026-05-27 verbatim 발견 실패] "Shared database is an anti-pattern in microservices because it creates runtime coupling and deployment coupling." | `needs-confirmation` (verbatim 재확인 실패, 자료 성격 `engineering-blog`) | service 간 DB 공유 시나리오 | tenant 간 DB 공유 (Pool 모델) 가 anti-pattern 이라는 뜻은 아님 — service ≠ tenant. 별도 `shared-database.html` 페이지에서 원문 확인 필요 |
|
||
| MSIO-DBPS-C3 | Isolation 이 (규제 / 성능 등으로) 필요할 때 separate database 가 적절, 그렇지 않으면 operational cost 가 benefit 을 초과할 수 있음 | [§Trade-offs — 2026-05-25 capture, 2026-05-27 verbatim 발견 실패] "When isolation is required (e.g., regulatory, performance), separate databases are appropriate; otherwise, the operational cost may outweigh the benefit." | `needs-confirmation` (verbatim 재확인 실패, 자료 성격 `engineering-blog`) | DB 분리 의사결정 일반 | "regulatory" 의 구체 기준 (HIPAA / GDPR / 한국 전자금융감독규정) 권장은 본 인용에 없음. 현재 페이지 본문에 해당 문장 부재 — archive 또는 다른 microservices.io 페이지 확인 필요 |
|
||
| MSIO-DBPS-C4 | microservices.io 가 multi-tenancy 를 단일 단위 패턴으로 직접 다루지 않음 — database-per-tenant 적용은 외부 추론 | (부재 자체가 claim — 2026-05-27 페이지 재확인으로 부재 재확인) | `engineering-blog` (부재 사실 확인) | multi-tenancy 결정에 본 자료 인용 시 | microservices.io 가 multi-tenancy 를 부정한다는 뜻은 아님 |
|
||
|
||
## Usage Boundaries / 적용 경계
|
||
|
||
- **이 자료가 직접 증명하는 것**:
|
||
- `MSIO-DBPS-C1` ~ `C3`: microservices 컨텍스트에서 database-per-service 의 pros/cons + shared-database anti-pattern + isolation 필요성 기준 (단, 인용 verbatim 재확인 실패)
|
||
- `MSIO-DBPS-C4`: 본 자료가 multi-tenancy 를 직접 다루지 않는다는 부재 사실
|
||
- **이 자료가 증명하지 않는 것**:
|
||
- database-per-tenant 가 microservices.io 의 공식 권장이라는 직접 보증
|
||
- database-per-tenant 의 PgBouncer / connection pool 구체 수치 (1000 tenant × 10 pool = 10000 connection 같은 수치는 본 raw 메모 추론, 본 자료 인용 아님)
|
||
- shared schema + tenant_id 가 anti-pattern 이라는 일반화 (service shared DB ≠ tenant shared schema)
|
||
- **내 프로젝트에 적용하려면 추가 확인이 필요한 것**:
|
||
- ca-tmpl 이 microservices 아키텍처를 채택했는지 (monolith 라면 database-per-service 논리는 추론 적용 불가)
|
||
- database-per-tenant 전환 시점의 트리거 (tenant 수 / row 수 / 규제 요건) 는 별도 capacity planning 필요
|
||
- 본 raw 인용 verbatim 의 정확성은 페이지 사람 검증 또는 archive.org snapshot 으로 보강
|
||
|
||
## 메모 / Notes (내 프로젝트 해석)
|
||
|
||
> 본 섹션은 자료 직접 인용 아님. ca-tmpl 결정 컨텍스트 해석.
|
||
|
||
- isolation 수준: database-per-X 패턴은 tenant 차원에서 그대로 적용 가능 → **database-per-tenant (full silo)**.
|
||
- tenant resolution 방식: 무관. 어떤 resolution을 쓰든 connection routing layer가 필요.
|
||
- scale 한계:
|
||
- database-per-tenant: connection 폭증. 1000 tenant × 10 pool = 10000 connection. PgBouncer 같은 transaction-level pooler 필수.
|
||
- tenant 수 수만 단위에서는 별도 RDS instance 필요 → 비용 폭증.
|
||
- 운영 복잡도:
|
||
- 마이그레이션이 tenant 수만큼 반복 (Liquibase/Flyway가 지원하나 시간 소요)
|
||
- 백업/복원이 tenant 단위로 자연스러움 (장점)
|
||
- 모니터링이 N개 DB → 통합 metric pipeline 필요
|
||
- security/compliance:
|
||
- 가장 강한 isolation. application bug가 있어도 cross-tenant leak 불가능 (별도 credentials)
|
||
- 규제 산업(금융, 의료, 정부)에서 흔히 요구됨
|
||
- data residency: tenant DB를 region별로 둘 수 있음
|
||
- 비용: 가장 비쌈. 다만 enterprise tier 가격 모델로 흡수 가능.
|
||
- 장점:
|
||
- 강한 isolation
|
||
- noisy neighbor 완벽 차단
|
||
- tenant별 DB tuning 가능 (인덱스, autovacuum 설정 등)
|
||
- 백업/복원 단순
|
||
- 단점:
|
||
- 비용
|
||
- 마이그레이션 rollout 시간
|
||
- connection 관리 복잡
|
||
- tenant onboarding이 분 단위 → 시간 단위로 늘어남
|
||
- ca-tmpl과의 차이:
|
||
- ca-tmpl이 shared DB를 선택한 결정의 반대 극단.
|
||
- **migration 시점**: 단일 tenant가 전체 DB 부하의 50% 이상을 차지하기 시작 / 규제로 인한 isolation 강제 / enterprise tier 등장 시 검토.
|
||
|
||
## Related / 관련
|
||
|
||
- 같은 주제 다른 raw:
|
||
- [[raw/official-docs/multitenancy-aws-saas-tenant-isolation-whitepaper]] — AWS 의 Silo/Pool/Bridge 분류
|
||
- [[raw/official-docs/multitenancy-hibernate-user-guide]] — Hibernate ORM 의 3 strategy
|
||
- [[raw/company-tech-blogs/multitenancy-stripe-citus-schema-per-tenant]] — schema-per-tenant 한계치 사례
|
||
- [[raw/company-tech-blogs/multitenancy-atlassian-tenant-context]] — shard + tenant context 운영 사례
|
||
- 인용하는 branch:
|
||
- [[raw/branch-notes/feature-tenant-context-policy]]
|
||
- [[raw/branch-notes/feature-repository-access-permission-contract]]
|
||
- 인용하는 project:
|
||
- [[raw/project-notes/ca-skeleton-operational-contract]] (§18)
|
||
- 인용한 wiki 요약: (미작성)
|