아키텍처 및 이를 구현하는 데 사용하는 구성 요소에 관계없이 솔루션의 구성 요소를 배포하고 구성해야 합니다. 다중 테넌트 환경에서는 특히 각 테넌트에 대한 전용 리소스를 배포하는 경우 또는 시스템의 테넌트 수에 따라 리소스를 다시 구성하는 경우에 Azure 리소스를 배포하는 방법을 고려해야 합니다. 이 페이지에서는 솔루션 설계자에게 다중 테넌트 솔루션 배포에 대한 참고 자료를 제공하고 배포 전략을 계획할 때 고려해야 할 몇 가지 방법을 보여 줍니다.
주요 고려 사항 및 요구 사항
배포 전략을 계획하기 전에 요구 사항을 명확하게 파악하는 것이 중요합니다. 구체적인 고려 사항은 다음과 같습니다.
- 예상 규모: 적은 수의 테넌트(예: 5개 이하)를 지원할 것으로 예상하나요, 아니면 많은 수의 테넌트로 확장할 예정인가요?
- 자동화되거나 지원되는 온보딩: 테넌트를 온보딩할 준비가 되면 자동화된 절차를 수행하여 프로세스를 직접 완료할 수 있나요? 또는 새 테넌트가 요청을 시작하면 요청을 받은 후 수동으로 온보딩하나요? 팀의 수동 승인 단계(예: 서비스 남용 방지)가 필요한가요?
- 프로비전 시간: 테넌트를 온보딩할 준비가 되면 온보딩 프로세스를 얼마나 빨리 완료해야 하나요? 명확한 대답이 없는 경우 초, 분, 시간 또는 일 단위로 측정해야 하는지를 고려합니다.
- Azure Marketplace: Azure Marketplace를 사용하여 배포를 시작할 계획인가요? 이 경우 새 테넌트 추가를 위해 충족해야 하는 요구 사항이 있습니다.
또한 온보딩 및 프로비저닝 단계, 자동화 및 리소스 관리 책임도 고려해야 합니다.
온보딩 및 프로비전 단계
테넌트를 온보딩할 때 수행해야 하는 모든 작업을 고려하고 수동으로 수행되더라도 이 목록과 워크플로를 문서화합니다. 온보딩 워크플로에는 일반적으로 다음이 포함됩니다.
- 상업 계약의 수락.
- 새 테넌트에 대한 시스템을 구성하는 데 필요한 정보의 수집.
- 수동 승인 단계(예를 들어 서비스의 사기 또는 남용을 방지하기 위한 목적).
- Azure에서 리소스 프로비저닝,
- 도메인 이름 만들기 또는 구성하기.
- 테넌트용 첫 번째 사용자 계정을 만들고 해당 자격 증명을 테넌트로 안전하게 전송하는 등 배포 후 구성 작업을 수행합니다.
- DNS 레코드 변경과 같은 수동 구성 변경 사항.
새 테넌트를 온보딩하는 데 필요한 워크플로를 명확하게 문서화합니다.
또한 테넌트에 대해 프로비전해야 하는 특정 Azure 리소스를 고려합니다. 각 테넌트에 대한 전용 리소스를 프로비전하지 않더라도 새 테넌트가 온보딩될 때 리소스를 배포해야 하는지를 고려합니다. 이 문제는 테넌트가 특정 지역에 데이터를 저장해야 하는 경우 또는 솔루션의 스탬프 또는 구성 요소 한도에 도달해서 다음 테넌트 일괄 처리에 대해 또 다른 인스턴스를 만들어야 하는 경우에 발생할 수 있습니다.
온보딩 프로세스가 다른 테넌트, 특히 동일한 인프라를 공유하는 테넌트에 방해가 될 수 있는지 여부를 고려합니다. 예를 들어 공유 데이터베이스를 수정해야 하는 경우 이 프로세스로 인해 다른 테넌트에서 인지할 만큼 성능에 영향을 줄 수 있나요? 이러한 영향을 방지할 수 있는지 또는 정상적인 작동 시간 외에 온보딩 프로세스를 수행하여 완화할 수 있는지 고려합니다.
Automation
자동화된 배포는 클라우드 호스팅 솔루션에 항상 권장됩니다. 다중 테넌트 솔루션으로 작업하는 경우 다음과 같은 이유로 배포 자동화가 더욱 중요해집니다.
- 규모: 수동 배포 프로세스는 테넌트 모집단이 증가함에 따라 점점 더 복잡해지고 시간이 많이 걸립니다. 테넌트 수가 증가함에 따라 자동화된 배포 접근 방식을 더 쉽게 확장할 수 있습니다.
- 반복 가능: 다중 테넌트 환경에서는 모든 테넌트에서 배포에 일관된 프로세스를 사용합니다. 수동 프로세스를 사용하면 오류 발생 가능성 또는 단계가 일부 테넌트에 수행되고 다른 테넌트에 수행되지 않을 가능성이 생깁니다. 이러한 수동 프로세스는 환경을 일관되지 않은 상태로 두어 팀이 솔루션을 관리하기 어렵게 만듭니다.
- 중단의 영향: 수동 배포는 자동화된 배포보다 훨씬 더 위험하고 중단되기 쉽습니다. 다중 테넌트 환경에서는 배포 오류로 인한 시스템 전체 중단 시 모든 테넌트가 영향을 받을 수 있으므로 영향이 클 수 있습니다.
다중 테넌트 환경에 배포하는 경우 배포 파이프라인을 사용하고 Bicep, JSON ARM 템플릿, Terraform 또는 Azure SDK와 같은 IaC(코드 제공 인프라) 기술을 사용해야 합니다.
Azure Marketplace를 통해 솔루션을 제공하려는 경우 새 테넌트에 대해 완전히 자동화된 온보딩 프로세스를 제공해야 합니다. 이 프로세스는 SaaS 처리 API 설명서에 설명되어 있습니다.
최대 리소스 용량
테넌트 리소스를 공유 리소스에 프로그래밍 방식으로 배포하는 경우 각 리소스에 대한 용량 제한을 고려합니다. 해당 한도에 접근하면 추가 스케일링을 지원하기 위해 리소스의 또 다른 인스턴스를 만들어야 할 수 있습니다. 배포하는 각 리소스의 한도와 또 다른 인스턴스를 배포하도록 트리거하는 조건을 고려합니다.
예를 들어 솔루션에 Azure SQL 논리 서버가 포함되어 있고 솔루션이 각 테넌트에 대한 해당 서버에 전용 데이터베이스를 프로비전한다고 가정해 보겠습니다. 단일 논리 서버에는 한도가 있으며 여기에는 논리 서버가 지원하는 최대 데이터베이스 수가 포함됩니다. 이러한 한도에 가까워지면 테넌트 온보딩을 계속할 수 있도록 새 서버를 프로비전해야 할 수 있습니다. 이 프로세스를 자동화할지 증가를 수동으로 모니터링할지 고려합니다.
리소스 관리 책임
일부 다중 테넌트 솔루션에서는 각 테넌트에 대한 전용 Azure 리소스(예: 각 테넌트에 대한 데이터베이스)를 배포합니다. 또는 리소스의 단일 인스턴스에 보관할 테넌트 수를 정해서 가지고 있는 테넌트 수가 Azure에 배포하는 리소스 집합을 결정하도록 할 수도 있습니다. 다른 솔루션에서는 단일 공유 리소스 집합을 배포한 다음 새 테넌트를 온보딩할 때 리소스를 다시 구성합니다.
이러한 각 모델마다 다양한 방법으로 리소스를 배포하고 관리해야 하며 프로비전하는 리소스의 수명 주기를 배포하고 관리할 방법을 고려해야 합니다. 두 가지 일반적인 접근법은 다음과 같습니다.
- 테넌트를 배포하는 리소스의 구성으로 처리하고 배포 파이프라인을 사용하여 해당 리소스를 배포 및 구성합니다.
- 테넌트를 데이터로 처리하고 컨트롤 플레 인을 프로비전하고 테넌트용 인프라를 구성합니다.
이러한 접근 방식에 대한 추가 논의는 아래에 나와 있습니다.
테스트
모든 배포 도중과 이후에 솔루션에 대해 철저한 테스트 계획을 세웁니다. 자동화된 테스트를 사용하여 솔루션의 기능 및 비기능적 동작을 확인할 수 있습니다. 테넌트 격리 모델을 테스트하고 Azure Chaos Studio와 같은 도구를 사용하여 실제 중단을 시뮬레이션하는 오류를 의도적으로 도입함으로써 구성 요소가 사용할 수 없게 되거나 오작동하는 경우에도 솔루션이 작동하는지 확인하는 것이 좋습니다.
고려해야 할 접근 방식 및 패턴
Azure 아키텍처 센터 및 더 넓은 커뮤니티의 여러 디자인 패턴은 다중 테넌트 솔루션의 배포 및 구성과 관련성이 있습니다.
배포 스탬프 패턴
배포 스탬프 패턴에는 테넌트 또는 테넌트 그룹에 대한 전용 인프라 배포가 관련됩니다. 단일 스탬프는 여러 테넌트를 포함하거나 단일 테넌트 전용일 수 있습니다. 단일 스탬프를 배포하도록 선택하거나 여러 스탬프에서 배포를 조정할 수 있습니다. 각 테넌트에 전용 스탬프를 배포하는 경우 전체 스탬프를 프로그래밍 방식으로 배포하는 것도 고려할 수 있습니다.
배포 링
배포 링을 사용하면 서로 다른 시간에 다양한 인프라 그룹에 업데이트를 배포할 수 있습니다. 이 방법은 일반적으로 배포 스탬프 패턴과 함께 사용되며, 스탬프 그룹은 테넌트 기본 설정, 워크로드 유형 및 기타 고려 사항에 따라 고유한 링에 할당할 수 있습니다. 자세한 내용은 배포 링을 참조하세요.
기능 플래그
기능 플래그 를 사용하면 단일 코드베이스를 유지하면서 솔루션의 새 기능 또는 버전을 다른 테넌트에게 점진적으로 노출할 수 있습니다. Azure App Configuration을 사용하여 기능 플래그를 관리하는 것이 좋습니다. 자세한 내용은 기능 플래그를 참조하세요.
특정 고객에 대해 특정 기능을 선택적으로 사용하도록 설정해야 하는 경우가 있습니다. 예를 들어 특정 기능에 대한 액세스를 허용하는 다양한 가격 책정 계층이 있을 수 있습니다. 기능 플래그는 일반적으로 이러한 시나리오에 적합한 선택이 아닙니다. 대신 각 고객이 가진 라이선스 자격을 추적하고 적용하는 프로세스를 빌드하는 것이 좋습니다.
피해야 할 안티패턴
다중 테넌트 솔루션을 배포하고 구성할 때 스케일링 기능을 억제하는 상황을 방지하는 것이 중요합니다. 포함되는 내용은 다음과 같습니다.
- 수동 배포 및 테스트. 위에서 설명한 대로 수동 배포 프로세스는 리스크를 더하고 배포 기능을 저하시킵니다. 자동화된 배포에 파이프라인을 사용하거나, 프로그래밍 방식으로 솔루션 코드에서 리소스를 만들거나, 둘 다 조합하는 것이 좋습니다.
- 테넌트용 특수 사용자 지정 단일 테넌트에만 적용되는 기능 또는 구성 배포는 피합니다. 이런 방법은 배포 및 테스트 프로세스를 더 복잡하게 만듭니다. 대신 각 테넌트에 대해 동일한 리소스 종류와 코드베이스를 사용하고, 임시 변경 사항 또는 점진적으로 롤아웃되는 기능에 대해 기능 플래그와 같은 전략을 사용하거나, 라이선스 자격을 사용한 다양한 가격 책정 계층을 통해 기능을 요구하는 테넌트에게 선택적으로 해당 기능을 지원하는 것이 좋습니다. 격리된 리소스 또는 전용 리소스가 있는 테넌트에 대해서도 일관되고 자동화된 배포 프로세스를 사용합니다.
구성 또는 데이터로서의 테넌트 목록
다중 테넌트 솔루션에 리소스를 배포할 때 다음 두 가지 방법을 고려할 수 있습니다.
- 자동화된 배포 파이프라인을 사용하여 모든 리소스를 배포합니다. 새 테넌트가 추가되면 파이프라인을 다시 구성하여 각 테넌트에 대한 리소스를 프로비전합니다.
- 자동화된 배포 파이프라인을 사용하여 테넌트 수에 의존하지 않는 공유 리소스를 배포합니다. 각 테넌트에 대해 배포되는 리소스의 경우 애플리케이션 내에서 리소스를 만듭니다.
두 가지 방법을 고려할 때 테넌트 목록을 구성 또는 데이터로 처리하는 방법을 구분해야 합니다. 이러한 구분은 시스템에 대한 컨트롤 플레 인을 빌드하는 방법을 고려할 때도 중요합니다.
테넌트 목록을 구성으로
테넌트 목록을 구성으로 처리할 때 중앙 집중식 배포 파이프라인에서 모든 리소스를 배포합니다. 새 테넌트가 온보딩되면 파이프라인 또는 해당 매개 변수를 다시 구성합니다. 일반적으로 재구성은 다음 다이어그램과 같이 수동 변경을 통해 수행됩니다.
새 테넌트를 온보딩하는 프로세스는 다음과 유사할 수 있습니다.
- 테넌트 목록을 업데이트합니다. 이 작업은 일반적으로 파이프라인 자체를 구성하거나 파이프라인 구성에 포함된 매개 변수 파일을 수정하여 수동으로 수행합니다.
- 실행할 파이프라인을 트리거합니다.
- 파이프라인은 새 테넌트별 리소스를 포함하여 전체 Azure 리소스 집합을 다시 배포합니다.
이 방법은 소수의 테넌트 및 모든 리소스가 공유되는 아키텍처에서 잘 작동하는 경향이 있습니다. 단일 프로세스를 사용하여 모든 Azure 리소스를 배포하고 구성할 수 있으므로 간단한 방법입니다.
그러나 더 많은 수의 테넌트(예: 5~10개 이상)에 접근하면 테넌트를 추가할 때 파이프라인을 다시 구성하는 것이 번거로워집니다. 배포 파이프라인을 실행하는 데 걸리는 시간도 크게 증가하는 경우가 많습니다. 또한 이 방법은 셀프 서비스 테넌트 생성을 지원하기가 쉽지 않고, 실행하려면 파이프라인을 트리거해야 하므로 테넌트가 온보딩되기 전의 리드 타임이 더 길어질 수 있습니다.
데이터로서의 테넌트 목록
테넌트 목록을 데이터로 처리할 때도 파이프라인을 사용하여 공유 구성 요소를 배포합니다. 그러나 각 테넌트에 대해 배포해야 하는 리소스 및 구성 설정의 경우 리소스를 명령적으로 배포하거나 구성합니다. 예를 들어 컨트롤 플레인은 Azure SDK를 사용하여 특정 리소스를 만들거나 매개 변수가 있는 템플릿의 배포를 시작할 수 있습니다.
새 테넌트를 온보딩하는 프로세스는 다음과 유사할 수 있으며 비동기식으로 발생하게 됩니다.
- 시스템의 컨트롤 플레인에 대한 API 요청을 시작하는 등 테넌트를 온보딩하도록 요청합니다.
- 워크플로 구성 요소는 만들기 요청을 수신하고 나머지 단계를 오케스트레이션합니다.
- 워크플로에서 Azure에 테넌트별 리소스의 배포를 시작합니다. 이는 Azure SDK를 사용하거나 Bicep 또는 Terraform 템플릿의 배포를 명령적으로 트리거하는 것과 같은 명령적 프로그래밍 모델을 사용하여 달성할 수 있습니다.
- 배포가 완료되면 워크플로는 새 테넌트의 세부 정보를 중앙 테넌트 카탈로그에 저장합니다. 각 테넌트에 대해 저장된 데이터에는 테넌트 ID 및 워크플로에서 만든 모든 테넌트별 리소스에 대한 리소스 ID가 포함될 수 있습니다.
이렇게 하면 전체 솔루션을 다시 배포하지 않고 새 테넌트에 대한 리소스를 프로비전할 수 있습니다. 해당 리소스만 배포하면 되기 때문에 각 테넌트에 대해 새 리소스를 프로비전하는 데 소요되는 시간이 짧아질 가능성이 높습니다.
그러나 이 방법은 빌드하는 데 훨씬 더 많은 시간이 소요되는 경우가 많으므로, 테넌트 수 또는 충족해야 하는 프로비전 시간이 들어가는 노력을 정당화할 만큼 충분해야 합니다.
이 방법에 대한 자세한 내용은 다중 테넌트 제어 평면에 대한 고려 사항을 참조하세요.
참고
Azure 배포 및 구성 작업을 완료하는 데는 시간이 걸리는 편입니다. 적절한 프로세스를 사용하여 이러한 장기 실행 작업을 시작하고 모니터링해야 합니다. 예를 들어 비동기 요청-회신 패턴을 따르는 것이 좋습니다. Azure Logic Apps 및 Durable Functions와 같은 장기 실행 작업을 지원하도록 설계된 기술을 사용합니다.
예제
Contoso는 고객을 위해 다중 테넌트 솔루션을 실행합니다. 현재 6개의 테넌트가 있으며 향후 18개월 이내에 300개의 테넌트로 증가할 것으로 예상됩니다. Contoso는 각 테넌트에 전용 데이터베이스가 있는 다중 테넌트 앱 접근법을 따릅니다. 단일 App Service 리소스 집합과 모든 테넌트 간에 공유되는 Azure SQL 논리 서버를 배포했고, 다음 다이어그램과 같이 각 테넌트에 대한 전용 Azure SQL 데이터베이스를 배포합니다.
Contoso는 Bicep을 사용하여 Azure 리소스를 배포합니다.
옵션 1 - 모든 항목에 배포 파이프라인 사용
Contoso에서 배포 파이프라인을 사용하여 모든 리소스를 배포하는 것을 고려할 수 있습니다. 파이프라인은 각 테넌트에 대한 Azure SQL 데이터베이스를 비롯해 모든 Azure 리소스를 포함하는 Bicep 파일을 배포합니다. 매개 변수 파일은 테넌트 목록을 정의하고 Bicep 파일은 다음 다이어그램과 같이 리소스 루프를 사용하여 나열된 각 테넌트에 대해 데이터베이스를 배포합니다.
Contoso가 이 모델을 따르는 경우 새 테넌트의 온보딩의 일부로 매개 변수 파일을 업데이트해야 합니다. 그런 다음 파이프라인을 다시 실행해야 합니다. 또한 예기치 않게 높은 속도로 증가하고 단일 Azure SQL 논리 서버에서 지원되는 최대 데이터베이스 수에 근접하는 경우처럼 어떤 한도에 가까워졌는지 여부를 수동으로 추적해야 합니다.
옵션 2 - 배포 파이프라인과 명령적 리소스 만들기의 조합 사용
또는 Contoso에서 Azure 배포에 대한 책임을 분리하는 것을 고려할 수 있습니다.
Contoso는 배포해야 하는 공유 리소스를 정의하는 Bicep 파일을 사용합니다. 공유 리소스는 다음 다이어그램과 같이 모든 테넌트를 지원하고 테넌트 맵 데이터베이스를 포함합니다.
그런 다음 Contoso 팀은 테넌트 온보딩 API를 포함하는 컨트롤 플레인을 빌드합니다. 영업 팀이 새 고객에게 판매를 완료하면 Microsoft Dynamics는 API를 트리거하여 온보딩 프로세스를 시작합니다. 또한 Contoso는 고객이 사용하며 API도 트리거하는 셀프 서비스 웹 인터페이스를 제공합니다.
API는 새 테넌트를 온보딩하는 워크플로를 비동기적으로 시작합니다. 워크플로는 다음 방법 중 하나로 수행할 수 있는 새 Azure SQL 데이터베이스의 배포를 시작합니다.
- Azure SDK를 사용하여 Azure SQL 데이터베이스를 정의하는 두 번째 Bicep 파일의 배포를 시작합니다.
- Azure SDK를 사용하여 관리 라이브러리를 통해 Azure SQL 데이터베이스를 명령적으로 만듭니다.
데이터베이스를 배포한 후 워크플로는 다음 다이어그램과 같이 테넌트 목록 데이터베이스에 테넌트 목록을 추가합니다.
진행 중인 데이터베이스 스키마 업데이트는 해당 애플리케이션 계층에서 시작됩니다.
참가자
Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.
보안 주체 작성자:
- John Downs | 수석 고객 엔지니어, FastTrack for Azure
기타 기여자:
- Bohdan Cherchyk | 수석 고객 엔지니어, FastTrack for Azure
- Arsen Vladimirskiy | 수석 고객 엔지니어, FastTrack for Azure
비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.
다음 단계
- 다중 테넌트 솔루션을 업데이트하기 위한 고려 사항을 검토합니다.
- 스토리지 및 데이터에 대한 아키텍처 접근 방식을 고려합니다.
- 다중 테넌트 솔루션에서 Azure Resource Manager를 사용하는 방법을 고려합니다.