SaaS에서의 멀티테넌시

멀티테넌시는 다양한 스펙트럼으로 존재합니다. 공유 데이터베이스, 공유 스키마: 모든 테넌트의 데이터가 동일한 테이블에 존재하며, tenant_id 컬럼으로만 구분됩니다. 가장 낮은 비용과 가장 간단한 아키텍처이지만, 쿼리에서 tenant_id 필터링이 누락될 경우 데이터 유출 위험이 가장 높습니다. 공유 데이터베이스, 개별 스키마: 각 테넌트가 공유 데이터베이스 내에서 자체 스키마를 가집니다. 완전한 분리에 비해 인프라 비용을 절감하면서 약간 더 나은 격리를 제공합니다. 테넌트별 개별 데이터베이스: 각 고객의 데이터가 완전히 격리된 데이터베이스에 존재합니다. 가장 높은 격리 보장, 더 간단한 규정 준수 스토리이지만, 인프라 비용과 운영 복잡성(데이터베이스 마이그레이션이 N개의 데이터베이스에서 실행되어야 함)이 상당히 높습니다. 대부분의 SaaS 기업은 비용 효율성을 위해 공유 스키마로 시작하여 데이터 상주 또는 더 엄격한 규정 준수 제어가 필요한 엔터프라이즈 부문을 위해 더 큰 격리 수준으로 마이그레이션합니다.

멀티테넌시는 지원 팀에게 특정 문제 해결 과제를 안겨줍니다. 테넌트별 버그: Tenant A에게만 영향을 미치는 문제(동일한 코드 버전을 사용함에도 불구하고 Tenant B에게는 영향을 미치지 않음)는 일반적으로 다음으로 인해 발생합니다: Tenant A의 특정 데이터 상태 또는 구성, Tenant A에게만 활성화된 기능 플래그, 또는 Tenant A의 사용 패턴에 의해서만 도달하는 속도 제한. 지원 에이전트는 항상 조사를 특정 테넌트에 한정해야 합니다: "이 문제가 이 특정 고객에게만 재현됩니까, 아니면 모든 고객에게 재현됩니까?" 보편적으로 재현 가능한 버그는 제품 버그이며, 테넌트별 버그는 구성 문제 또는 데이터 무결성 문제입니다. 지원팀은 한 테넌트의 데이터를 수정하는 방식이 다른 테넌트의 데이터를 손상시키거나 아키텍처의 격리 보장을 위반하지 않도록 주의해야 합니다.

멀티테넌시는 '시끄러운 이웃(noisy neighbor)'이라는 운영 위험을 발생시킵니다. 즉, 한 테넌트의 높은 리소스 소비가 동일한 인프라를 공유하는 다른 테넌트의 성능을 저하시킬 수 있습니다. Product Ops는 엔지니어링 팀과 함께 모니터링 및 경고 전략을 공동으로 소유합니다. 테넌트별 리소스 소비 대시보드는 다른 테넌트에 영향을 미치기 전에 리소스 한계에 도달하는 테넌트를 식별합니다. 테넌트별 속도 제한(rate limiting) 및 리소스 할당량(resource quotas)이 주요 완화책입니다(속도 제한은 API 과도한 사용을 방지하고, 데이터베이스 쿼리 시간 초과는 장기 실행 쿼리가 공유 데이터베이스 리소스를 독점하는 것을 방지합니다). 엔터프라이즈 고객의 경우, Product Ops는 규정 준수 목적을 위해 아키텍처가 제공할 수 있는 격리 보장이 무엇인지 이해해야 합니다. 영업 및 지원 팀은 조달 대화에서 '내 데이터가 다른 고객으로부터 격리되어 있습니까?'라는 질문에 정확한 답변을 제공해야 합니다. 아키텍처가 필요한 격리를 제공할 수 없는 경우, 엔터프라이즈 티어는 단일 테넌트 또는 프라이빗 배포 옵션을 요구할 수 있습니다.