다음을 통해 공유

다중 테넌트 솔루션의 테넌트 수명 주기 고려 사항

  • 아티클

다중 테넌트 아키텍처를 고려할 때 테넌트의 수명 주기에서 다양한 단계를 모두 고려하는 것이 중요합니다. 이 페이지에서는 기술적 의사 결정자에게 수명 주기의 단계 및 각 단계에 대한 중요한 고려 사항에 대한 참고 자료를 제공합니다.

평가판 테넌트

SaaS 솔루션을 빌드할 때 많은 고객이 솔루션을 구매하기 위해 커밋하기 전에 평가판을 요청하거나 요구하는 것이 좋습니다.

평가판에는 다음과 같은 특별한 고려 사항이 따라옵니다.

  • 서비스 요구 사항: 평가판에는 전체 고객을 위한 데이터와 동일한 데이터 보안, 성능 및 서비스 수준 요구 사항이 적용되어야 하나요?
  • 인프라: 전체 고객과 동일한 인프라를 평가판 테넌트에 사용해야 하나요, 아니면 평가판 테넌트에 대한 전용 인프라가 있어야 하나요?
  • 마이그레이션: 고객이 평가판 후에 서비스를 구매하는 경우 평가판 테넌트에서 유료 테넌트로 데이터를 마이그레이션하려면 어떻게 할까요?
  • 요청 프로세스: 평가판을 요청할 수 있는 사용자에 대한 제한이 있나요? 솔루션 남용을 방지하려면 어떻게 해야 할까요? 평가판 테넌트 자동 생성을 허용하나요, 아니면 팀이 각 요청에 참여하나요?
  • 제한: 시간 제한, 기능 제한 또는 성능 제한과 같은 평가판 고객에게 어떤 제한을 적용하거나 적용해야 하나요?

경우에 따라 평가판을 제공하는 대신 프리미엄 가격 책정 모델이 될 수 있습니다.

새 테넌트 온보딩

새 테넌트를 온보딩할 때 다음 질문을 고려하세요.

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

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

테넌트의 인프라 업데이트

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

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

테넌트 인프라 스케일링

테넌트에 계절별 비즈니스 패턴이 있는지 또는 솔루션에 대한 사용량 수준이 다른 방식으로 변경될 수 있는지를 고려합니다.

예를 들어 소매업체에 솔루션을 제공하는 경우 특정 연도의 특정 시간이 일부 지역에서는 특히 바쁘고 다른 시간에는 조용할 것으로 예상할 수 있습니다. 이러한 계절성이 솔루션을 디자인하고 크기를 조정하는 방식에 영향을 주는지 여부를 고려합니다. 테넌트 하위 집합이 갑자기 예기치 않게 부하가 증가하여 다른 테넌트 성능이 저하되는 경우와 같이 계절성이 시끄러운 인접 문제에 어떤 영향을 줄 수 있는지 유의하세요. 개별 테넌트의 인프라 크기 조정, 배포 간에 테넌트 이동, 트래픽 급증 및 트로프를 처리하기에 충분한 수준의 용량 프로비저닝을 포함하는 완화를 적용하는 것이 좋습니다.

인프라 간에 테넌트 이동

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

  • 재조정: 수직 분할된 접근 방식을 따라 테넌트를 인프라에 매핑하고 부하를 다시 분산하기 위해 테넌트를 다른 배포로 이동해야 합니다.
  • 업그레이드: 테넌트는 SKU 또는 가격 책정 계층을 업그레이드하고 다른 테넌트로부터 격리가 높은 단일 테넌트 전용 배포로 이동해야 합니다.
  • 마이그레이션: 테넌트는 데이터를 전용 데이터 저장소로 이동하도록 요청합니다.
  • 지역 이동: 테넌트는 데이터를 새 지리적 지역으로 이동해야 합니다. 이 요구 사항은 회사 인수 중 또는 법률 또는 지정학적 상황이 변경될 때 발생할 수 있습니다.

테넌트의 데이터를 이동하는 방법과 요청을 해당 인스턴스를 호스트하는 새 인프라 집합으로 리디렉션하는 방법을 고려합니다. 또한 테넌트를 이동하면 가동 중지 시간이 발생할 수 있는지 여부를 고려하고 테넌트가 위험을 완전히 인식해야 합니다.

테넌트 병합 및 분할

테넌트 또는 고객을 고정적이고 변하지 않는 엔터티로 생각하고 싶은 유혹이 있겠지만 실제로는 그렇지 않은 경우가 많습니다. 다음은 그 예입니다.

  • 비즈니스 시나리오에서 회사는 서로 다른 지역에 있는 회사를 포함하여 인수 또는 합병될 수 있습니다.
  • 비즈니스 시나리오에서 기업은 분할하거나 매각할 수 있습니다.
  • 소비자 시나리오에서 개별 사용자는 가족에 합치거나 가족을 떠날 수 있습니다.

데이터, 사용자 ID 및 리소스의 병합 및 분리를 관리하는 기능을 제공해야 하는지 여부를 고려해야 합니다. 또한 데이터 소유권이 병합 및 분할 작업 처리에 미치는 영향을 고려합니다. 예를 들어 가족이 서로 사진을 공유할 수 있도록 빌드된 소비자 사진 애플리케이션을 고려해 보겠습니다. 사진은 사진을 제공한 개별 가족 구성원이 소유하고 있나요, 아니면 가족 전체가 소유하고 있나요? 사용자가 가족을 떠나는 경우 해당 데이터를 제거해야 하나요, 아니면 가족의 데이터 집합에 유지해야 하나요? 사용자가 다른 가족으로 합치는 경우 과거 사진이 그들과 함께 이동해야 하나요?

테넌트 오프보딩

또한 경우에 따라 솔루션에서 테넌트 제거가 불가피합니다. 다중 테넌트 솔루션에서는 이러한 경우에 다음과 같은 몇 가지 중요한 고려 사항이 따라옵니다.

  • 보존 기간: 고객 데이터를 얼마나 오래 유지 관리해야 하나요? 특정 기간 후에 데이터를 삭제하기 위한 법적 요구 사항이 있나요?
  • 다시 등록: 고객이 다시 등록할 수 있는 기능을 제공해야 하나요? 데이터 보존 기간 내에 다시 가입하는 경우 해당 데이터를 계속 사용할 수 있나요?
  • 리밸런싱: 공유 인프라를 실행하는 경우 인프라에 대한 테넌트 할당의 균형을 다시 조정해야 합니까?

테넌트의 비활성화 및 재활성화

고객의 계정을 비활성화하거나 재활성화해야 하는 상황이 있습니다. 다음은 그 예입니다.

  • 고객이 비활성화를 요청했습니다. 소비자 시스템에서 고객은 구독 취소를 선택할 수 있습니다.
  • 고객에게 요금을 청구할 수 없어서 구독을 비활성화해야 합니다.

비활성화는 임시 상태를 의도한 오프보딩과는 별개입니다. 그러나 일정 기간이 지나면 비활성화된 테넌트를 오프보딩하도록 선택할 수 있습니다.

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

보안 주체 작성자:

  • John Downs | 주요 소프트웨어 엔지니어

기타 기여자:

비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인하세요.

다음 단계

솔루션에 사용할 가격 책정 모델을 고려합니다.