멀티테넌트 SaaS 아키텍처: 격리, 빌링, AI 기능 및 확장 선택

이 기술 아티클은 SaaS 제품을 설계하거나 초기 설계를 벗어난 제품을 개선하고 있는 CTO, 아키텍트, 시니어 엔지니어를 대상으로 합니다. SaaS 플랫폼 엔지니어링 가이드에서는 사일로, 풀, 브릿지 테넌시 모델과 컨트롤 플레인을 소개합니다. 이 아티클은 각 레이어에서 격리가 어떻게 적용되는지, 데이터가 어떻게 파티셔닝되는지, 빌링이 어떻게 연결되는지, AI 기능이 테넌트 경계 내에 유지되는 방법, 플랫폼 확장 방법을 한 단계 더 깊이 다룹니다. 마켓플레이스는 마켓플레이스 플랫폼 아키텍처에서 다룹니다.

컨텍스트: 테넌트, 사용자, 배포

먼저 테넌트를 정의합니다. B2B SaaS에서 테넌트는 일반적으로 여러 사용자를 가진 고객 조직입니다. 일부 고객은 별도의 자회사나 테스트 및 프로덕션 환경처럼 여러 테넌트가 필요합니다. B2C 제품에서는 테넌트가 개인, 가족 또는 그룹일 수 있습니다. Microsoft의 Azure Architecture Center는 이 정의와 테넌시 모델이 고객에게 수용 가능한지 여부가 기술적 결정만큼이나 상업적 결정이라는 점을 지적합니다.

논리적 테넌트와 이를 서비스하는 배포를 분리합니다. 배포(스탬프라고도 함)는 하나의 인프라 집합입니다. 여러 테넌트가 배포를 공유하거나 하나의 테넌트가 전용 배포를 가질 수 있습니다. 처음부터 테넌트-배포 맵을 유지하면 나중에 애플리케이션을 재작성하지 않고도 테넌트를 배포 간에 이동할 수 있습니다.

격리는 레이어별로 결정됩니다

SaaS 테넌트 격리 전략에 관한 AWS 백서는 격리를 SaaS 설계의 근본이라고 설명하며, 테넌트 경계를 침범하는 것을 비즈니스에 회복하기 어려운 사건으로 기술합니다. Microsoft는 격리를 단일 스위치가 아닌 스펙트럼으로 설명합니다. 실제로 각 레이어는 별도의 답을 갖습니다:

일반적이고 합리적인 결과는 풀링된 애플리케이션 티어와 필요한 테넌트를 위한 격리된 데이터입니다. Microsoft는 일부 구성 요소를 테넌트별로 분리하고 다른 구성 요소를 공유하는 것을 수평 파티셔닝이라 하고, 선택된 테넌트에 전체 전용 배포를 제공하는 것을 수직 파티셔닝이라고 합니다.

데이터 파티셔닝 옵션

풀링된 데이터베이스의 경우, 애플리케이션 코드뿐만 아니라 데이터베이스 자체에서 격리를 적용합니다. PostgreSQL의 행 보안 정책이 한 방법입니다. 테이블에 활성화되면 정책이 허용하지 않는 한 행이 숨겨지므로, 테넌트 필터 없는 쿼리는 모든 것이 아닌 아무것도 반환하지 않습니다. 두 가지 세부 사항이 중요합니다. 정책은 테이블별로 활성화해야 하며, 테이블 소유자, 슈퍼유저 및 BYPASSRLS 속성을 가진 역할은 기본적으로 이를 우회합니다. 따라서 애플리케이션은 테이블을 소유하지 않는 역할로 연결하거나, 소유자에게도 정책이 적용되도록 테이블이 행 보안을 강제하게 설정해야 합니다.

빌링 및 미터링 아키텍처

멀티테넌트 SaaS의 빌링은 단일 통합이 아닌 파이프라인입니다.

AI 기능: 데이터 격리 및 테넌트별 모델 비용

어시스턴트, AI 검색, 요약은 대부분의 화면보다 한 요청에서 더 많은 테넌트 데이터를 읽으므로 동일한 경계가 동일한 장소에서 적용되어야 합니다. AI 거버넌스는 이를 뒷받침하는 정책을 설정합니다.

• 프롬프트 외부에서 검색을 필터링합니다. 검색 서비스는 세션 컨텍스트의 테넌트 및 사용자 권한을 적용합니다. "이 고객의 데이터만 사용하라"는 프롬프트 지시는 격리가 아닙니다.
• 모든 AI 캐시를 테넌트별로 키를 지정합니다. 테넌트 키 없는 캐시된 답변과 임베딩은 한 고객의 콘텐츠를 다른 고객에게 반환할 수 있습니다.
• 공유 학습에서 테넌트 데이터를 제외합니다. 한 테넌트의 데이터로 공유 모델을 파인튜닝하지 않으며, 요청에 대한 학습을 제외하는 조건의 모델 제공업체를 선택합니다. 규제 테넌트는 지역 또는 전용 모델 배포가 필요할 수 있습니다.
• 테넌트별 모델 비용을 미터링합니다. 토큰과 호출은 테넌트 간에 크게 다릅니다. 기능별로 속성을 지정하고 엔타이틀먼트를 통해 한도를 적용합니다.
• 오프보딩 시 삭제합니다. 탈퇴하는 테넌트의 임베딩, 인덱스, 로깅된 프롬프트는 데이터베이스 행과 함께 삭제됩니다.

확장 선택

테넌트 마이그레이션 경로를 일찍 계획합니다. 테넌트의 데이터가 공유 데이터베이스에서 전용으로 이동하는 방법, 트래픽 전환 방법, 결과 검증 방법을 미리 설계하는 것이 나중에 즉흥적으로 고안하는 것보다 훨씬 쉽습니다.

운영: 릴리스, 마이그레이션, 복구

• 링 방식으로 릴리스합니다. 내부 테넌트에 먼저 배포하고, 소수의 고객, 그 다음 전체 고객 순으로 테넌트별 피처 플래그를 사용하여 출시합니다.
• 플리트 전체의 스키마 마이그레이션을 자동화합니다. 테넌트별 스키마 또는 데이터베이스의 경우, 하나의 릴리스가 수많은 마이그레이션을 의미합니다. 어떤 테넌트가 어떤 버전에 있는지 추적합니다.
• 플랫폼 전체가 아닌 단일 테넌트를 복구합니다. 고객은 단일 테넌트의 데이터 복구를 요청할 것입니다. 요청이 오기 전에 테스트해 두십시오.
• 테넌트별 비용을 측정합니다. 미터링과 클라우드 청구서를 결합하여 어떤 테넌트와 플랜이 비용을 충당하는지 파악합니다.

테스트 증거: 테스트해야 할 항목

이것은 특정 프로젝트의 결과가 아닌 일반 엔지니어링 관행입니다:

• 크로스 테넌트 접근 테스트. 다른 테넌트의 데이터를 읽거나 변경하려는 모든 엔드포인트와 잡에 대해 실패해야 하는 자동화된 테스트.
• 행 정책 테스트. 테넌트 컨텍스트 없이 실행된 쿼리는 애플리케이션의 데이터베이스 역할 하에서도 행을 반환하지 않아야 합니다.
• 노이지 네이버 부하 테스트. 한 테넌트가 높은 부하를 생성하는 동안 다른 테넌트의 응답 시간을 측정합니다.
• 단일 테넌트 복구 테스트. 깨끗한 환경에 백업에서 한 테넌트를 복구하고 레코드를 비교합니다.
• 미터링 테스트. 재생된 이벤트와 중복된 이벤트가 동일한 사용량 합계를 생성해야 합니다.
• 크로스 테넌트 AI 테스트. 다른 테넌트의 레코드에 대해 질문받은 어시스턴트는 캐시된 답변을 포함하여 아무것도 찾지 못해야 합니다.

더 광범위한 검사는 SaaS 보안 체크리스트에 있습니다.

사례: Printcart

Printcart는 Netbase의 5개 비즈니스 사업부 중 하나로, 온라인 주문을 인쇄 준비 파일과 라우팅된 이행으로 전환하는 웹투프린트 및 온디맨드 인쇄 플랫폼입니다. 판매자 자체 스토어 또는 Shopify, Wix, WooCommerce 앱으로 실행되며, 약 7일의 설정 기간으로 2,000개 이상의 스토어를 지원합니다. 하나의 제품에서 이렇게 많은 판매자를 지원하는 것이 이 아티클에서 설명하는 멀티테넌트 문제입니다. 각 판매자는 공유 플랫폼에서 자체 카탈로그, 주문, 스토어 연결이 필요합니다. Printcart 포트폴리오 레코드에서 Netbase JSC가 엔지니어링하고 운영하는 내용을 다루며, 인쇄 및 패키징에서 섹터 컨텍스트를 확인할 수 있습니다.

자체 제품 외에도, Netbase JSC는 2020년부터 중소기업에 SaaS로 판매되는 미국 고객의 멀티테넌트 클라우드 ERP(고객 이름 비공개)의 오프쇼어 개발 및 관리 파트너로 활동하고 있습니다.

Netbase JSC의 멀티테넌트 구축 접근 방식

Netbase JSC는 AWS, Google Cloud, DigitalOcean, Cloudflare와 함께 작업합니다. 클라우드 파트너 티어나 클라우드 인증은 주장하지 않습니다. 일반적인 타임라인은 SaaS MVP의 경우 8~12주, 중간 규모 제품의 경우 3~6개월, 엔터프라이즈 플랫폼의 경우 범위에 따라 6~12개월 이상입니다. 이는 범위이지 견적이 아닙니다. 보안은 첫 번째 스프린트부터 설계에 포함됩니다. 보안 코드 리뷰, 전송 중 TLS 및 저장 시 AES, 역할 기반 접근 제어, 관리자 대시보드 MFA, 취약점 스캐닝, 재해 복구 계획이 포함됩니다. AI 모델은 제품별로 선택하며 특정 벤더에 종속되지 않습니다. SaaS 개발 서비스가 제품을 구축하며, SaaS 제품 액셀러레이터는 계정, 테넌트, 역할, 빌링을 위한 재사용 가능한 모듈에서 시작합니다.

이 아티클의 한계

• 일반적인 패턴과 일반 관행을 설명합니다. 올바른 조합은 테넌트, 데이터, 지역 및 고객 계약에 따라 다릅니다.
• 인용된 AWS 백서는 AWS에 의해 역사적 참조로 표시되어 있습니다. 격리 원칙은 여전히 널리 사용되지만, 서비스 세부 사항은 현재 AWS 가이드를 확인하십시오.
• PostgreSQL은 데이터베이스 강제 격리의 한 예로 사용되며, 다른 데이터베이스는 다른 메커니즘을 제공합니다.
• 타임라인은 일반적인 범위입니다. Printcart는 공개된 제품 정보를 바탕으로 설명되며, 여기서는 성능 지표를 주장하지 않습니다.

다음 단계

테넌트 프로필, 데이터 민감도, 가격 모델을 공유해 주시면, 첫 번째 릴리스를 위한 격리 및 빌링 설계를 선택할 솔루션 리뷰를 예약하겠습니다. 관련 서비스를 확인하거나 더 많은 Netbase JSC 인사이트를 살펴볼 수도 있습니다.

관련 서비스 및 솔루션