아키텍처 [ study: 멀티 테넌시(Multi-tenancy) ]

아키텍쳐에 대해서 공부하던 중 멀티 테넌시(Multi-tenancy) 아키텍처에 대해서 알게되어 공부한 내용을 정리해 보았습니다.
멀티 테넌시는 SaaS 환경에서 핵심적인 개념이며, 효율적인 운영과 비용 절감을 가능하게 하지만 동시에 보안과 성능 문제를 해결해야 하는 과제가 있습니다.

---

1. 멀티 테넌시(Multi-tenancy)의 정의

멀티 테넌시란 하나의 애플리케이션 인스턴스와 인프라에서 여러 고객(테넌트, Tenant)을 동시에 지원하는 아키텍처를 의미합니다. 테넌트는 회사, 조직, 혹은 사용자 그룹을 지칭하며, 각 테넌트는 독립된 데이터와 구성을 가지지만 동일한 코드베이스와 시스템을 공유합니다.

즉, 한 번 개발하고 배포한 소프트웨어를 여러 고객이 함께 사용하는 구조라고 할 수 있습니다.

---

2. 싱글 테넌시와의 차이

• 싱글 테넌시(Single-tenancy): 고객마다 별도의 애플리케이션 인스턴스와 DB를 운영. 독립성이 강하지만 비용과 관리 부담이 큼.
• 멀티 테넌시(Multi-tenancy): 하나의 인스턴스에서 여러 고객을 지원. 비용 절감과 운영 효율성이 뛰어나지만, 보안과 성능 관리가 필요.

예를 들어, 싱글 테넌시는 고객 A, B 각각에게 서버와 DB를 따로 두는 반면,
멀티 테넌시는 하나의 서버/DB에서 고객 A와 B의 데이터를 구분하여 관리합니다.

---

3. 멀티 테넌시 구현 방식

멀티 테넌시는 주로 데이터베이스 분리 전략에 따라 구분됩니다.

1) 공용 DB, 공용 스키마 (Shared DB, Shared Schema)

• 하나의 DB와 하나의 테이블 구조 사용
• tenant_id 컬럼으로 테넌트 데이터를 구분
• 장점: 비용 최소화, 관리 단순화
• 단점: 성능 이슈와 데이터 격리 위험

2) 공용 DB, 개별 스키마 (Shared DB, Separate Schema)

• 하나의 DB를 공유하되 테넌트별 스키마를 따로 사용
• 장점: 데이터 논리적 분리 강화
• 단점: 테넌트가 많아지면 스키마 관리 복잡

3) 개별 DB (Separate DB per Tenant)

• 각 테넌트마다 별도의 DB 운영
• 장점: 보안과 독립성이 최상
• 단점: 관리 및 비용 증가

이 중 어떤 방식을 선택할지는 서비스 규모, 고객의 보안 요구, 운영 리소스 등에 따라 달라집니다.

---

4. 장단점 정리

장점

• 비용 절감: 인프라 공유로 효율적 운영
• 운영 편의성: 배포/업데이트를 한 번에 전체 테넌트에 적용 가능
• 확장성: 테넌트 수가 늘어나도 비교적 쉽게 대응

단점

• 보안 리스크: 테넌트 간 데이터 격리 실패 시 심각한 사고 발생
• 커스터마이징 어려움: 개별 테넌트 요구에 맞추기 힘듦
• 성능 문제: 특정 테넌트의 대규모 사용이 다른 테넌트에 영향을 줄 수 있음

---

5. 고려해야 할 사항

멀티 테넌시 아키텍처를 설계할 때 백엔드 개발자는 다음을 반드시 고려해야 합니다.

• 데이터 격리 보장: ORM 레벨에서 tenant_id 필터를 기본 조건으로 넣거나, DB 접근 계층에서 테넌트별 제한을 강제
• 보안: 인증/인가 체계에서 테넌트 단위 권한을 명확히 분리
• 성능 튜닝: 인덱스 전략, 캐싱, 쿼리 최적화를 통해 특정 테넌트의 쿼리가 전체 성능을 저해하지 않도록 설계
• 스케일링: 특정 대형 고객을 위해 DB를 분리하거나 전용 리소스를 제공하는 하이브리드 전략 고려
• 운영 도구: 테넌트 단위 모니터링, 로깅, 청구(Usage Billing) 시스템 제공 필요

---

6. 실제 서비스 사례

• Slack: 하나의 플랫폼에서 여러 회사(워크스페이스)를 테넌트로 지원
• GitHub: 공용 인프라 위에서 수많은 조직과 개인 계정을 지원
• Google Workspace: 테넌트별로 도메인, 사용자, 데이터가 독립되어 운영

이처럼 글로벌 SaaS 기업들은 멀티 테넌시 아키텍처를 기반으로 대규모 사용자를 안정적으로 지원하고 있습니다.

---

7. 트레이드오프 정리

멀티 테넌시는 단순히 비용 효율성을 위한 선택이 아닙니다.
보안, 성능, 커스터마이징이라는 세 가지 축 사이에서 끊임없이 트레이드오프를 고민해야 합니다.

• 보안 vs 비용: 개별 DB를 사용하면 보안은 강화되지만 비용 증가
• 성능 vs 운영 효율성: 공용 DB를 사용하면 효율적이지만, 특정 테넌트 부하가 전체에 영향을 줌
• 커스터마이징 vs 단일 코드베이스 유지: 개별 요구를 수용하면 코드 복잡성이 증가

백엔드 개발자는 이 트레이드오프를 이해하고, 서비스의 성격과 고객 요구에 맞는 전략을 선택해야 합니다.

---

마무리

멀티 테넌시는 SaaS 서비스에서 사실상 표준 아키텍처입니다.
그러나 단순히 인프라를 공유하는 것 이상의 의미를 가지며, 보안과 데이터 격리, 운영 편의성 사이에서 균형 잡힌 설계가 필요합니다.
백엔드 개발자는 데이터베이스 전략, 인증/인가 구조, 스케일링 전략을 면밀히 고민해야 안정적인 멀티 테넌시 서비스를 구축할 수 있습니다.

---

참고

slack: https://slack.engineering/how-slack-built-shared-channels/?utm_source=chatgpt.com
multi-tenancy: https://cloud.google.com/spanner/docs/implement-multi-tenancy?utm_source=chatgpt.com&hl=ko