11 KiB
title, source_type, url, archive_url, status, confidence, tags, related_projects, related_branches, created, last_reviewed
| title | source_type | url | archive_url | status | confidence | tags | related_projects | related_branches | created | last_reviewed | ||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Microservices.io — Database per Service Pattern (Multi-Tenancy 인접 추론) | official-doc | https://microservices.io/patterns/data/database-per-service.html | raw | medium |
|
|
|
2026-05-22 | 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:
- 인용하는 project:
- 인용한 wiki 요약: (미작성)