9.7 KiB
9.7 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 | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Atlassian — Tenant Context and Isolation in Cloud Platform | company-tech-blog | https://www.atlassian.com/engineering/cloud-architecture-and-guidelines | raw | medium |
|
|
|
2026-05-22 | 2026-05-27 |
Atlassian Cloud — Tenant Context / Isolation
Layer:
raw/company-tech-blogs/— Atlassian Engineering 의 Cloud Architecture and Operational Guidelines. 수십만 tenant 를 운영하는 대표 hybrid (Bridge) 사례; shard 단위 isolation + tenant context (cloudId) 전파 패턴. 출처 주의: company-tech-blog 이므로 본 자료의 권장 사항을 "공식 best practice" 로 일반화 금지. ca-tmpl 미래 hybrid 확장의 사례 reference 로만 사용. 검증된 요약은/ingest후wiki/concepts/에 별도 작성.
Parent / 활용 branch (필수)
| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| raw/branch-notes/feature-tenant-context-policy | Topic 6 Multi-tenancy 대안 6 (hybrid Deployment Stamps / shard) 의 대규모 사례 baseline. tenant context (cloudId/tenantId) 전파 = ca-tmpl 의 SecurityContext → repository 사상과 동일. |
| raw/branch-notes/feature-repository-access-permission-contract | "Cross-tenant access is explicitly forbidden at the storage layer; tenant context is mandatory in every query" 원칙이 CROSS_TENANT_ADMIN capability 의 명시적 escape hatch 설계 정당화. |
| raw/project-notes/ca-skeleton-operational-contract | §18 Control Plane Contract (Tenant Context Policy) 의 hybrid 확장 사례 reference. |
컨텍스트 / 왜 저장했는지
Atlassian Cloud (Jira, Confluence) 는 수십만 tenant 를 운영하는 대표 사례. shard 단위 isolation + tenant_id 전파 패턴은 ca-tmpl 미래 확장 (hybrid) 에 가장 가까운 실제 운영 사례.
출처 / Source
- 원본 URL: https://www.atlassian.com/engineering/cloud-architecture-and-guidelines
- 관련 글: "How we manage data residency on AWS", "Tenant context propagation"
- 아카이브 URL: (미수집)
- 저자 / 조직: Atlassian Engineering
- 발행일: rolling docs (페이지 자체에 명시 없음)
- 마지막 확인일: 2026-05-27
- 재검증 결과 (2026-05-27): 원본 URL (
https://www.atlassian.com/engineering/cloud-architecture-and-guidelines) WebFetch 결과 HTTP 404 Not Found — 페이지가 이동/삭제됨. Atlassian engineering blog index (atlassian.com/blog/atlassian-engineering) 와 developer docs (developer.atlassian.com/cloud/jira/platform/multi-tenancy/) 도 redirect 또는 404. archive.org snapshot 도 WebFetch 차단. 2026-05-25 작성 당시 인용된 4개 quote 모두 verbatim 재확인 불가; claim strengthcompany-case-study+needs-confirmation유지. wiki 추출 또는 외부 인용 전 다른 출처 corroboration 필수.
핵심 인용 / Key quotes (verbatim, 2026-05-22 작성 시 인용)
needs-confirmation [§Shard assignment — 2026-05-25 capture, 2026-05-27 원본 URL 404] "Each Atlassian Cloud tenant is assigned to a shard — a unit of deployment that hosts many tenants but is operated as a single unit."
needs-confirmation [§Tenant context propagation — 2026-05-25 capture, 2026-05-27 원본 URL 404] "We propagate a tenant context (cloudId/tenantId) through every service call so that downstream services can enforce tenant-scoped data access."
needs-confirmation [§Data residency / realm — 2026-05-25 capture, 2026-05-27 원본 URL 404] "Data residency is implemented by placing all of a tenant's data in a specific realm (region), with metadata routing requests to the correct realm."
needs-confirmation [§Storage layer enforcement — 2026-05-25 capture, 2026-05-27 원본 URL 404] "Cross-tenant access is explicitly forbidden at the storage layer; tenant context is mandatory in every query."
Claims Extracted / 추출된 주장
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| ATL-MT-C1 | Atlassian Cloud 의 각 tenant 는 shard (many tenant 를 호스팅하지만 single unit 로 운영되는 deployment 단위) 에 할당 | needs-confirmation [§Shard assignment] "Each Atlassian Cloud tenant is assigned to a shard — a unit of deployment that hosts many tenants but is operated as a single unit." | company-case-study + needs-confirmation |
Atlassian Jira / Confluence Cloud 운영 사례 | shard 크기 / tenant 배분 알고리즘 / rebalancing 메커니즘은 본 인용에 없음 |
| ATL-MT-C2 | Tenant context (cloudId/tenantId) 가 모든 service call 을 통해 전파되어 downstream service 가 tenant-scoped data access 를 enforce | needs-confirmation [§Tenant context propagation] "We propagate a tenant context (cloudId/tenantId) through every service call so that downstream services can enforce tenant-scoped data access." | company-case-study + needs-confirmation |
Atlassian internal RPC / microservices 운영 | propagation 의 구체 transport (HTTP header / gRPC metadata / message header) 는 본 인용에 없음 |
| ATL-MT-C3 | Data residency 는 tenant 의 모든 data 를 특정 realm (region) 에 배치 + metadata routing 으로 구현 | needs-confirmation [§Data residency / realm] "Data residency is implemented by placing all of a tenant's data in a specific realm (region), with metadata routing requests to the correct realm." | company-case-study + needs-confirmation |
Atlassian Cloud 의 GDPR / 데이터 주권 요구 시나리오 | realm 간 tenant 이동 / 복제 / 장애 시 failover 정책은 본 인용에 없음 |
| ATL-MT-C4 | Cross-tenant access 는 storage layer 에서 명시적으로 금지; tenant context 는 모든 query 에 mandatory | needs-confirmation [§Storage layer enforcement] "Cross-tenant access is explicitly forbidden at the storage layer; tenant context is mandatory in every query." | company-case-study + needs-confirmation |
Atlassian 의 internal multi-tenancy enforcement | 정확한 enforcement 메커니즘 (RLS / ORM filter / static analysis) 은 본 인용에 없음 |
Usage Boundaries / 적용 경계
- 이 자료가 직접 증명하는 것:
ATL-MT-C1~C4: Atlassian 의 shard + tenant context propagation + storage layer enforcement 운영 사례 (단, 인용 verbatim 재확인 실패)
- 이 자료가 증명하지 않는 것:
- shard 모델이 모든 SaaS 의 best practice 라는 일반화 (company-tech-blog → 사례, 표준 아님)
- 한국 fintech / 금융권 규제에서 shard 가 충분한 isolation 으로 인정되는지 (Atlassian 은 글로벌 enterprise SaaS, 규제 컨텍스트 다름)
- tenant context propagation 의 specific 구현 (HTTP header / JWT claim / Thread-local) 권장
- shard rebalancing / tenant migration 의 운영 절차 (블로그에 명시 없음)
- 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- ca-tmpl 이 shard 모델로 확장될 trigger 조건 (tenant 수 / 단일 deployment 부하 / 규제)
- "storage layer enforcement" 의 ca-tmpl 구현 방식 — Hibernate Filter + CROSS_TENANT_ADMIN capability 의 조합이 Atlassian 의 "mandatory in every query" 와 동등한 강도인지
- 본 raw 인용 verbatim 의 정확성은 페이지 사람 검증 또는 archive.org snapshot 으로 보강
- "company-tech-blog" 이므로 wiki 추출 시 AWS / Hibernate 공식 자료와 corroboration 필요 (공식 best practice 로 단정 금지)
메모 / Notes (내 프로젝트 해석)
본 섹션은 자료 직접 인용 아님. ca-tmpl 결정 컨텍스트 해석.
- isolation 수준 (shared/schema-per-tenant/db-per-tenant):
- shard 안에서는 shared DB + tenant_id (pool에 가까움)
- shard 자체가 deployment stamp 역할 → 실질적으로 hybrid (Bridge)
- tenant resolution 방식: cloudId(=tenant_id)를 모든 internal RPC header/context로 전파. 외부 진입은 OAuth token 안의 tenant claim.
- scale 한계: shard 추가로 horizontal scale. 단일 shard 크기는 운영적으로 cap.
- 운영 복잡도:
- shard rebalancing (tenant 이동) 매우 복잡
- 전체 fleet rollout이 shard별 canary로 진행됨 → 안전하지만 시간 소요
- security/compliance: realm으로 GDPR/data residency 해결. tenant context propagation 자체가 security boundary.
- 비용: 단순 pool보다 비쌈. 전부 silo보다 훨씬 쌈.
- 장점:
- blast radius 제한
- tenant 단위 SLA 차등 가능
- data residency 자연 지원
- 단점:
- 모든 서비스가 tenant context를 강제로 요구 → 초기 framework 투자 필요
- 회사 규모(수십~수백 명 인프라 팀) 없이는 운영 어려움
- ca-tmpl과의 차이:
- ca-tmpl은 현재 단일 deployment + opt-in tenant_id. shard 개념 없음.
- tenant context propagation (header/JWT → SecurityContext → repository) 자체는 ca-tmpl과 동일한 사상.
Related / 관련
- 같은 주제 다른 raw:
- raw/official-docs/multitenancy-aws-saas-tenant-isolation-whitepaper — AWS 의 Silo/Pool/Bridge 분류 (Atlassian shard ≈ Bridge)
- raw/official-docs/multitenancy-hibernate-user-guide — Hibernate ORM 의 3 strategy
- raw/official-docs/multitenancy-microservices-io-pattern — microservices.io database-per-service
- raw/company-tech-blogs/multitenancy-stripe-citus-schema-per-tenant — schema-per-tenant 한계치 사례
- 인용하는 branch:
- 인용하는 project:
- 인용한 wiki 요약: (미작성)