다중 테넌트 아키텍처를 고려할 때는 몇 가지 결정 사항과 고려해야 할 요소가 있습니다.
다중 테넌트 아키텍처에서는 테넌트 간에 리소스의 일부 또는 전부를 공유합니다. 이 프로세스는 다중 테넌트 아키텍처가 비용 및 운영 효율성을 제공할 수 있음을 의미합니다. 그러나 다중 테넌트에서는 복잡성이 발생합니다. 다음 질문을 스스로에게 물어봐야 합니다.
- 특정 솔루션에 대해 ‘테넌트’를 정의하려면 어떻게 해야 하나요? 테넌트는 고객, 사용자 또는 팀 또는 가족과 같은 사용자 그룹에 해당하나요?
- 다중 테넌트를 지원하려면 인프라를 어떻게 배포하고 테넌트 간에 어떤 수준까지 격리할 수 있나요?
- 솔루션에서 제공하는 상업용 가격 책정 모델은 무엇이며 가격 책정 모델은 다중 테넌트 요구 사항에 어떤 영향을 미치나요?
- 성능, 복원력, 보안 및 데이터 상주와 같은 규정 준수 요구 사항과 같은 차원 간에 테넌트에 어떤 수준의 서비스를 제공해야 하나요?
- 비즈니스 또는 솔루션을 성장하려면 어떻게 해야 할까요? 예상되는 테넌트 수로 확장될까요?
- 테넌트에 특이한 또는 특별한 요구 사항이 있나요? 예를 들어 가장 규모가 큰 고객에게 다른 고객보다 더 높은 성능 또는 더 강력한 보증이 필요한가요?
- Azure 환경을 모니터링, 관리, 자동화, 확장 및 관리하는 방법 및 다중 테넌트가 관리 전략에 어떤 영향을 주나요?
- 솔루션의 어떤 구성 요소가 테넌트 온보딩 및 관리를 처리하고 이러한 구성 요소를 어떻게 설계해야 하나요?
아키텍처에 관계없이 고객 또는 테넌트의 요구 사항을 명확하게 이해하는 것이 중요합니다. 고객에게 판매 약정을 했거나 계약 의무 또는 규정 준수 요구 사항을 충족해야 하는 경우 솔루션을 설계할 때 이러한 요구 사항이 무엇인지 알아야 합니다. 그러나 마찬가지로, 고객은 사물 이 작동하는 방식이나 행동 방식에 대한 암시적 기대를 가질 수 있으며, 이는 다중 테넌트 솔루션을 설계하는 방식에 영향을 줄 수 있습니다.
예를 들어 금융 서비스 업계의 기업에 판매하는 다중 테넌트 솔루션을 빌드한다고 상상해 보세요. 고객은 매우 엄격한 보안 요구 사항이 있으며 솔루션에서 사용하는 모든 도메인 이름의 포괄적인 목록을 제공하여 방화벽의 허용 목록에 추가할 수 있어야 합니다. 이 요구 사항은 사용하는 Azure 서비스 및 테넌트 간에 제공해야 하는 격리 수준에 영향을 줍니다. 또한 솔루션에 최소 수준의 복원력이 있어야 합니다. 전체 솔루션에서 고려해야 하는 명시적 및 암시적 요구 사항이 많을 수 있습니다.
이 섹션에서는 다중 테넌트 아키텍처를 계획할 때 제공해야 하는 몇 가지 고려 사항, 유도해야 하는 요구 사항 및 몇 가지 절충안을 간략하게 설명합니다.
대상 그룹
이 섹션의 문서는 특히 최고 기술 책임자(CTO) 및 설계자와 같은 기술 의사 결정자뿐만 아니라 제품 관리자와 관련이 있습니다. 대상 그룹에는 SaaS 솔루션을 개발하는 ISV(독립 소프트웨어 공급업체) 및 스타트업도 포함됩니다. 또한 다중 테넌트 아키텍처를 사용하는 모든 사용자는 이러한 원칙과 절충안에 대해 잘 알고 있어야 합니다.
다음 단계
솔루션에 대해 다른 테넌시 모델을 고려해 봅니다.