다중 고객 분리형 소프트웨어 서비스 백엔드 ( FastAPI )

Multitenant SaaS Backend 개요

운영을 전제로 설계되어지는 멀티 테넌트 SaaS 백엔드 구조입니다 완성된 제품이라기보다는, 실제 운영 가능한 형태로의 기초 단계입니다.

Python 기반으로 구성한 멀티 테넌트 SaaS 백엔드로 단순 CRUD API가 아니라, 테넌트 분리 + 구독 + 비동기 처리까지 포함된 구조입니다.

주의 / 대상 제한

이 프로젝트는 멀티테넌트 구조를 전제로 합니다.

tenant isolation, shared DB 설계, async task 처리에 대한 이해가 없는 경우

구조적 리스크를 스스로 판단하기 어렵기 때문에 사용을 권장하지 않습니다.

데이터 격리, 권한 경계, 비동기 작업 처리에 대한 안정성은

사용자의 설계 및 검증 책임에 포함됩니다.

What this is (핵심 차이)

이 프로젝트는 일반적으로 많이 보이는
“사이트를 여러 개 생성하는 플랫폼”과는 방향이 다릅니다.

테넌트마다 시스템을 복제하는 방식이 아니라,
하나의 서비스 안에서 tenant context로 분리되는 구조를 선택했습니다.

각 테넌트는 별도의 인스턴스가 아니라
같은 애플리케이션과 데이터 모델 위에서 동작하며,
요청 단위 컨텍스트로 논리적으로 격리됩니다.

그래서 이 구조는

• 멀티 인스턴스형 CMS / 호스팅 플랫폼이 아니라
• shared DB 기반의 싱글 서비스 + 멀티 컨텍스트 구조

에 가깝습니다.

즉,

“사이트 여러 개”가 아니라
“하나의 서비스 안에 여러 고객(조직/팀)이 들어온 상태”를 전제로 합니다.

Where this fits

이 구조는 다음과 같은 서비스에 적합합니다.

• 조직/팀 단위로 분리되는 협업 도구
• 구독 기반 SaaS (usage / billing 포함)
• B2B 관리형 플랫폼
• 내부 운영툴 (admin / audit / tenant isolation 필요)

서비스를 복제하는 방식보다,
하나의 도메인 모델을 공유하면서 tenant context로 분리하는 구조가 필요한 경우에 맞습니다.

Core Features

• Host 기반 tenant resolution
• 사용자 / 조직 / 멤버십 관리
• 구독 및 결제 상태 관리
• usage tracking 및 경고 처리
• 관리자 API 분리 (admin scope)
• Celery 기반 비동기 작업 처리
• DB commit 이후 task dispatch 구조

Architecture

• FastAPI 단일 앱 + Celery worker / scheduler 분리
• SQLAlchemy session 기반 트랜잭션 처리
• tenant context middleware
• systemd + nginx 기반 운영

Design Direction

• Django 대신 FastAPI 선택 (명시적 구조 + 비동기 처리)
• ORM은 SQLAlchemy 2.x
• queue는 Redis + Celery 유지
• container 없이 systemd 기반 운영

현재 상태

• API / worker / scheduler 모두 운영 중
• reverse proxy 연결 완료
• health check endpoint 정상

Limitations

• 테스트 코드 없음
• CI/CD 없음
• 일부 운영 설정은 환경 의존적
• 구조 검증은 진행 중

Why this structure

이 프로젝트는 “확장 가능한 SaaS 백엔드”를 기준으로 설계했습니다.

• 단일 서비스 위에서 tenant isolation
• sync request와 async 작업 분리
• billing / usage / domain logic 통합

피드백 받고 싶은 부분

• shared DB 기반 멀티테넌트 구조가 적절한지
• DB commit 이후 task dispatch 방식
• Celery 사용 방식 (과한지 여부)
• 운영 기준에서 부족한 요소

Summary

멀티테넌트 SaaS를 전제로 구성한 FastAPI 기반 백엔드입니다.
사이트를 복제하는 방식이 아니라, 하나의 서비스 안에서 여러 고객을 처리하는 구조를 지향합니다.