테넌트 수명 주기를 고려한 멀티 테넌시 설계

안녕하세요 주간SaaS 입니다. 오늘은 마이크로소프트에서 발행한 Tenant lifecycle considerations in a multitenant solution 라는 가이드를 소개 합니다.

B2B SaaS에서는 빈번하게 upsell, cross-sell, 고객 유치 그리고 이탈이 일어납니다(*물론 이탈은 막아야하는 미션이지만요). 이 과정에서 아키텍처 관점에서 테넌트 그리고 그에 연결된 자원의 신분이 바뀌기 때문에 이에 대한 적절한 변화와 대응이 필요합니다. 그래서 테넌트의 수명 주기를 사전에 그린 후 아키텍처를 설계 하는것이 중요합니다. 이런 관점에 도움이 될만한 글 입니다.

그럼 좋은 하루 보내세요!

멀티테넌트 아키텍처를 고려할 때는 테넌트 수명 주기의 여러 단계를 모두 고려하는 것이 중요합니다. 이 페이지에서는 기술 의사 결정자를 위한 테넌트 수명 주기 단계와 각 단계의 중요 고려 사항에 대한 가이드를 제공합니다.

평가판 테넌트(Trial Tenant)

SaaS 솔루션을 구축할 때는 많은 고객이 솔루션 구매를 결정하기 전에 평가판(Trial)을 요청하거나 필요로 한다는 점을 고려하세요.

평가판에는 다음과 같은 특별히 고려할 사항들이 있습니다:

서비스 요구 사항: 평가판에도 정식 고객의 데이터와 동일한 데이터 보안, 성능 및 서비스 수준 요구 사항이 적용되어야 하나요?
인프라: 평가판 테넌트에 정식 고객과 동일한 인프라를 사용해야 하나요, 아니면 평가판 테넌트 전용 인프라를 사용해야 하나요?
마이그레이션: 고객이 평가판 사용 후 서비스를 구매하는 경우, 평가판 테넌트의 데이터를 유료 테넌트로 어떻게 마이그레이션할 수 있나요?
요청 절차: 평가판을 요청할 수 있는 사용자에 제한이 있나요? 솔루션의 남용을 어떻게 방지할 수 있나요? 평가판 테넌트의 자동 생성을 허용하나요, 아니면 팀이 각 요청에 관여하나요?
제한 사항: 시간 제한, 기능 제한, 성능 관련 제한 등 평가판 고객에게 어떤 제한을 두고 싶거나 설정해야 하나요?

일부 상황에서는 freemium 가격 모델이 평가판 제공의 대안이 될 수 있습니다.

새 테넌트 온보딩

새 테넌트를 온보딩할 때는 다음 사항을 고려하세요:

프로세스: 온보딩을 셀프 서비스, 자동화된 프로세스 또는 수동 프로세스로 진행할 것인가요?
데이터 거주지(Data residency): 테넌트에게 데이터 위치에대한 특정 요구 사항이 있나요? 예를 들어, 데이터 주권 규정이 적용되나요?
규정 준수: 테넌트가 규정 준수 표준(예: PCI DSS, HIPAA 등)을 충족해야 하나요?
재해 복구: 테넌트가 복구 시간 목표(RTO) 또는 복구 지점 목표(RPO)와 같은 특정 재해 복구 요구 사항을 가지고 있나요? 이러한 요구 사항이 다른 테넌트에게 제공하는 보증과 다른가요?
정보: 테넌트를 완전히 온보딩하기 위해 어떤 정보가 필요한가요? 예를 들어 조직의 법적 이름을 알아야 하나요? 애플리케이션을 브랜딩하기 위해 회사 로고가 필요한지, 필요하다면 어떤 파일 크기와 형식이 필요한가요?
청구: 플랫폼에서 다양한 가격 옵션과 청구 모델을 제공하나요?
환경: 테넌트에게 사전 제작 환경이 필요한가요? 그리고 해당 환경에 대한 가용성에 대한 기대치가 정해져 있나요? 일시적(온디맨드)인가요, 아니면 항상 사용 가능한가요?

테넌트가 온보딩된 후에는 '평소와 같은 비즈니스' 상태로 전환됩니다. 그러나 이 상태에서도 여전히 몇 가지 중요한 수명 주기 이벤트가 발생할 수 있습니다.

테넌트 인프라 업데이트

테넌트의 인프라에 업데이트를 적용하는 방법을 고려해야 합니다. 테넌트마다 업데이트 적용 시기가 다를 수 있습니다.

테넌트 배포 업데이트에 대한 기타 고려 사항은 업데이트를 참조하세요.

테넌트의 인프라 확장

테넌트의 비즈니스 패턴이 계절에 따라 달라지거나 솔루션의 소비 수준이 달라질 수 있는지 생각해보세요.

예를 들어 소매업체에 솔루션을 제공하는 경우 일 년 중 특정 시기가 일부 지역에서는 특히 바쁘고 다른 지역에서는 한산할 것으로 예상할 수 있습니다. 이러한 계절성이 솔루션을 설계하고 확장하는 방식에 영향을 미치는지 고려하세요. 일부 테넌트의 부하가 갑자기 예상치 못하게 증가하여 다른 테넌트의 성능이 저하되는 경우와 같이 계절적 요인이 소음 이웃 문제에 어떤 영향을 미칠 수 있는지 알아야합니다. 이를 위하여, 개별 테넌트의 인프라 확장, 배포 간에 테넌트 이동, 트래픽의 급증과 감소를 처리할 수 있는 충분한 수준의 용량 프로비저닝 등 완화 조치를 적용하는 것을 고려할 수 있습니다.

인프라 간에 테넌트 이동

다음과 같은 여러 가지 이유로 인프라 간에 테넌트를 이동해야 할 수 있습니다:

리밸런싱: 테넌트를 인프라에 매핑하기 위해
업그레이드: 테넌트가 SKU 또는 가격 티어를 업그레이드하는 경우, 다른 테넌트와의 격리가 더 높은 단일 테넌트 전용 배포로 이동해야 합니다.
마이그레이션: 테넌트가 데이터를 전용 데이터 저장소로 옮기도록 요청하는 경우.
리전 이동: 테넌트가 데이터를 새로운 지역으로 이동해야 하는 경우입니다. 이는 회사를 인수하거나 법률 또는 지정학적 상황이 변경될 때 발생할 수 있습니다.

테넌트의 데이터를 이동하는 방법과 인스턴스를 호스팅하는 새로운 인프라 집합으로 요청을 리디렉션하는 방법을 고려하세요. 또한 테넌트를 이동하면 다운타임이 발생할 수 있는지 여부를 살피고 테넌트가 이러한 위험을 충분히 인지하고 있는지 확인해야 합니다.

테넌트 병합 및 분할

테넌트나 고객을 정적이고 변하지 않는 실체라고 생각하기 쉽습니다. 하지만 실제로는 그렇지 않은 경우가 많습니다. 예를 들어

비즈니스 시나리오에서는 서로 다른 지역에 위치한 회사를 포함하여 회사를 인수하거나 합병할 수 있습니다.
마찬가지로 비즈니스 시나리오에서는 회사가 분할되거나 매각될 수 있습니다.
소비자 시나리오에서는 개인 사용자가 가족에 가입하거나 탈퇴할 수 있습니다.

데이터, 사용자 ID, 리소스의 병합 및 분리를 관리할 수 있는 기능을 제공해야 하는지 여부를 고려하세요. 또한 데이터 소유권이 병합 및 분리 작업 처리에 어떤 영향을 미치는지도 고려하세요. 예를 들어, 가족들이 서로 사진을 공유할 수 있도록 만들어진 소비자 사진 애플리케이션을 생각해 봅시다. 사진의 소유권은 사진을 제공한 가족 구성원 개인에게 있나요, 아니면 가족 전체에 있나요? 사용자가 가족을 떠나는 경우 해당 사용자의 데이터를 제거해야 할까요, 아니면 가족의 데이터 세트에 남겨 두어야 할까요? 사용자가 다른 가족에 가입하면 이전 사진도 함께 이동해야 하나요?