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

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

맥락: 테넌트, 사용자 및 배포

먼저 테넌트를 정의하세요. 기업 간 SaaS에서 테넌트는 일반적으로 많은 사용자를 가진 고객 조직입니다. 일부 고객은 여러 테넌트가 필요한 경우도 있는데, 예를 들어 별도의 자회사나 별도의 테스트 및 프로덕션 환경이 필요할 수 있습니다. 기업과 소비자 간 제품에서 테넌트는 한 명의 개인, 가족 또는 그룹일 수 있습니다. Microsoft의 Azure 아키텍처 센터는 이 정의와 테넌시 모델이 고객에게 수용 가능한지 여부는 기술적인 결정만큼이나 상업적인 결정이라고 설명합니다.

논리적 테넌트와 그것을 제공하는 배포를 분리하세요. 배포는 때로 스탬프라고도 불리며, 하나의 인프라 세트입니다. 많은 테넌트가 하나의 배포를 공유할 수도 있고, 하나의 테넌트가 자체 배포를 가질 수도 있습니다. 처음부터 테넌트-배포 맵을 유지하면 나중에 애플리케이션을 다시 작성하지 않고도 배포 간에 테넌트를 이동할 수 있습니다.

격리는 계층별로 결정됩니다

SaaS 테넌트 격리 전략에 관한 AWS 백서는 격리가 SaaS 설계의 근본이라고 말하며, 테넌트 경계를 넘는 것은 비즈니스에 회복 불가능한 사건이 될 수 있다고 설명합니다. Microsoft는 격리를 단일 스위치가 아닌 스펙트럼으로 설명합니다. 실제로 각 계층은 고유한 답을 가집니다:

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

데이터 파티셔닝 옵션

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

빌링 및 미터링 아키텍처

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

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

어시스턴트, AI 검색 및 요약은 대부분의 화면보다 한 요청에서 더 많은 테넌트 데이터를 읽으므로, 동일한 경계를 동일한 위치에서 적용해야 합니다. AI 거버넌스가 그 뒤에 있는 정책을 설정합니다.

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

확장 선택

테넌트 마이그레이션 경로를 일찍 계획하세요. 테넌트의 데이터가 공유 데이터베이스에서 자체 데이터베이스로 어떻게 이동하는지, 트래픽이 어떻게 전환되는지, 결과를 어떻게 검증하는지를 포함합니다. 가장 큰 고객이 요청할 때 압박 속에서 고안하는 것보다 미리 설계하는 것이 훨씬 쉽습니다.

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

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

테스트 근거: 무엇을 테스트할 것인가

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

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

예시: Printcart

Printcart는 Netbase JSC의 5개 비즈니스 사업부 중 하나로, 온라인 주문을 인쇄 준비 파일과 라우팅된 주문 처리로 전환하는 웹투프린트 및 주문형 인쇄 플랫폼입니다. 판매자 자체 스토어 또는 Shopify, Wix, WooCommerce 앱으로 운영되며, 약 7일 이내에 설정이 가능하고 10년 서비스 기간 동안 10,000개 이상의 파트너를 보유하고 있다고 보고합니다. 그 많은 판매자에게 하나의 제품으로 서비스를 제공하는 것이 이 문서에서 설명하는 멀티테넌트 문제입니다. 각 판매자는 공유 플랫폼에서 자체 카탈로그, 주문 및 스토어 연결이 필요합니다. Printcart 포트폴리오 레코드는 Netbase JSC가 엔지니어링하고 운영하는 내용을 다루며, 인쇄 및 포장은 분야 맥락을 보여줍니다.

자체 제품 외에도 Netbase JSC는 2020년부터 이름이 공개되지 않은 미국 고객을 위한 멀티테넌트 클라우드 ERP의 오프쇼어 개발 및 관리 파트너로 일하고 있으며, 이는 중소기업에 SaaS로 판매됩니다.

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 인사이트를 더 둘러볼 수도 있습니다.

관련 서비스 및 솔루션