다중 테넌트 솔루션의 제어 평면에 대한 아키텍처 접근 방식

제어 평면은 SaaS(Software as a Service) 및 다중 테넌트 솔루션의 중요한 부분입니다. 대규모 솔루션을 관리하는 데 도움이 될 수 있습니다. 일반적으로 컨트롤 플레인은 다음 두 가지 주요 구성 요소로 구성됩니다.

• 테넌트 카탈로그는 다음 정보를 포함하여 테넌트에 대한 중요한 정보를 저장합니다.

  • 테넌트 구성
  • 테넌트 리소스에 대해 배포된 SKU
  • 테넌트가 할당되는 배포 스탬프

• 환경의 변경 내용을 관리하는 프로세스입니다. 테넌트 수명 주기 이벤트는 이러한 프로세스를 트리거합니다. 예를 들어 테넌트 온보딩, 테넌트 오프보딩 및 필수 정기적인 유지 관리가 있습니다.

컨트롤 플레인은 애플리케이션으로 작동합니다. 솔루션의 다른 부분에 적용하는 것과 동일한 엄격하고 주의하여 컨트롤 플레인을 디자인해야 합니다. 컨트롤 플레인이 무엇인지, 컨트롤 플레인이 중요한 이유 및 디자인 고려 사항에 대한 자세한 내용은 다중 테넌트 컨트롤 플레인에 대한 고려 사항을 참조하세요.

이 문서에서는 컨트롤 플레인을 디자인하고 만드는 데 사용할 수 있는 방법을 설명합니다. 각 접근 방식은 유효하지만 이 지침 외부의 다른 아키텍처는 특정 시나리오에 더 적합할 수 있습니다.

고려해야 할 접근 방식 및 패턴

다음 표에서는 컨트롤 플레인에 대한 수동, 하위 코드 및 사용자 지정 방법 간의 차이점을 요약합니다.

수동 프로세스

특히 몇 개의 테넌트만 사용하여 시작할 때 항상 완전히 자동화된 컨트롤 플레인을 빌드할 필요는 없습니다.

팀이 액세스할 수 있는 위치에 저장된 Excel 통합 문서 또는 JSON 파일과 같은 중앙 위치에 테넌트 카탈로그를 유지할 수 있습니다. 형식에 관계없이 데이터를 프로그래밍 방식으로 쉽게 작업할 수 있도록 정보를 구조화된 방식으로 저장해야 합니다.

테넌트 온보딩 및 유지 관리 활동과 같은 프로세스에 대해 다음 요소를 고려합니다.

• 가능한 경우 스크립트 또는 자동화된 파이프라인을 수동으로 실행하더라도 만듭니다. 스크립트 또는 파이프라인은 각 테넌트에 대해 단계가 일관되게 실행되는 데 도움이 됩니다.

• 처음에 스크립깅할 수 없는 작업의 경우 프로세스를 명확하고 자세한 단계로 문서화합니다. 방법 및 이유를 설명합니다. 이 정보는 다른 사용자가 나중에 작업을 자동화하는 데 도움이 됩니다.

다음 다이어그램에서는 초기 컨트롤 플레인에 대한 수동 프로세스 방법을 보여 줍니다.

이 아키텍처의 Visio 파일을 다운로드합니다.

수동 접근 방식의 장점

• 경량: 설명서, 스크립트 및 파이프라인은 쉽게 개발하고 수정할 수 있습니다. 이러한 유연성을 통해 프로세스를 신속하게 반복하고 발전시킬 수 있으므로 프로세스를 구성할 때 이상적입니다.

• 저가: 수동 접근 방식을 유지 관리하고 실행하는 것은 저렴합니다.

• 프로세스 유효성 검사: 수동 접근 방식은 개념 증명 역할을 합니다. 이를 통해 전체 자동화를 빌드하는 데 시간과 리소스를 커밋하기 전에 유지 관리 전략을 테스트하고 확인할 수 있습니다.

수동 접근 방식의 단점

• 제어 부족: 이 방법은 올바른 작업을 수행하는 데 관련된 모든 사람에게 의존합니다. 누군가가 실수로 또는 의도적으로 규정 된 프로세스에서 벗어날 수 있습니다. 프로세스의 모든 변화는 사용자 환경의 불일치 위험을 증가하므로 지속적인 관리가 어려워집니다.

• 액세스 제어 문제: 이 방법을 사용하려면 솔루션 운영자에게 광범위하게 범위가 지정되어 매우 관대하게 액세스해야 하는 경우가 많습니다. 이 액세스를 사용하면 액세스 구분 모범 사례를 적용하기가 어렵습니다.

• 확장성: 수동 프로세스를 실행하는 데 필요한 작업은 관리해야 하는 테넌트 수로 확장됩니다.

• 테스트 용이성: 수동 프로세스는 유효성을 검사하고 테스트하기 어렵습니다.

수동 접근 방식에서 전환하는 경우

• 팀이 애플리케이션을 유지 관리하는 데 필요한 워크로드를 따라갈 수 없는 경우 이 시나리오는 일반적으로 테넌트 수가 관리 가능한 임계값(일반적으로 5~10개 테넌트)을 초과하는 경우에 발생합니다.

• 중요한 수의 테넌트를 초과하여 테넌트 증가를 예상할 때, 더 많은 테넌트를 관리해야 하는 요구에 대비해야 합니다.

• 불일치의 위험을 완화해야 하는 경우 예를 들어 누군가가 프로세스를 올바르게 따르지 않거나 불분명한 프로세스 때문에 발생하는 실수를 관찰할 수 있습니다. 더 많은 테넌트가 수동으로 등록되고 팀이 성장함에 따라 불일치 위험이 증가합니다.

로우 코드 컨트롤 플레인

낮은 코드 또는 코드 없는 컨트롤 플레인은 비즈니스 프로세스를 자동화하고 정보를 추적하도록 설계된 플랫폼을 사용합니다. Microsoft Power Platform을 비롯한 많은 플랫폼을 사용하면 사용자 지정 코드를 작성하지 않고도 이러한 작업을 수행할 수 있습니다.

Microsoft Power Platform을 사용하는 경우 Dynamics 365, Dataverse 또는 Microsoft 365에 테넌트 카탈로그를 저장할 수 있습니다. 처음에 모든 것을 자동화하는 데 완전히 커밋하지 않으려는 경우 수동 프로세스에 사용하는 것과 동일한 테넌트 카탈로그를 유지할 수도 있습니다.

테넌트 온보딩 및 유지 관리의 경우 Power Automate를 사용하여 테넌트 관리를 수행하고, 테넌트를 구성하고, 파이프라인 또는 API 호출을 트리거하는 워크플로를 실행할 수 있습니다. Power Automate는 데이터에 대한 액세스 권한이 있는 경우 테넌트 카탈로그의 변경 내용을 모니터링할 수 있습니다. 수동 테넌트 카탈로그를 사용하는 경우 Power Automate 워크플로를 수동으로 트리거할 수 있습니다. 완전히 자동화할 수 없는 작업을 확인하거나 완료하기 위해 팀 구성원이 필요한 경우 워크플로에 수동 승인 단계를 포함합니다.

이 방법은 고객을 위한 셀프 서비스 등록도 지원합니다. 웹 애플리케이션은 사용자의 개입 없이 테넌트 카탈로그 항목을 자동으로 만들 수 있습니다.

다음 다이어그램에서는 Microsoft Power Platform을 사용하여 셀프 서비스 등록이 있는 컨트롤 플레인을 만드는 방법을 보여줍니다.

이 아키텍처의 Visio 파일을 다운로드합니다.

로우 코드 접근 방식의 이점

• 경량: 저코드 워크플로를 빠르고 저렴하게 만들어 주변 시스템에 연결할 수 있습니다.

• 플랫폼 도구를 사용합니다. 네이티브 플랫폼 기능을 사용하여 데이터를 저장하고, 팀의 관리 포털을 만들고, 워크플로를 모니터링할 수 있습니다. 이 방법을 사용하면 사용자 지정 구성 요소를 개발하고 유지 관리할 필요가 줄어듭니다.

• 맞춤형: 필요한 경우 사용자 지정 코드를 사용하여 워크플로를 확장할 수 있습니다. 예를 들어 Power Automate는 GitHub Actions에서 배포 워크플로를 트리거하거나 Azure Functions를 호출하여 코드를 실행할 수 있습니다. 이러한 유연성은 점진적인 자동화 구현을 용이하게 하는 데 도움이 됩니다.

• 낮은 오버헤드: 낮은 코드 서비스는 일반적으로 완전히 관리되므로 인프라를 관리할 필요가 없습니다.

낮은 코드 접근 방식의 단점

• 필수 전문 지식: 낮은 코드 플랫폼은 프로세스를 효과적으로 빌드하고 관리하기 위해 독점 지식이 필요한 경우가 많습니다. 많은 조직에서 이미 이러한 도구를 사용하고 있으므로 팀에 필요한 전문 지식이 있거나 교육을 제공해야 할 수 있습니다.

• 경영: 대량의 낮은 코드 구성 관리를 처리하는 것은 어려울 수 있습니다.

• 테스트 용이성: 관리되는 플랫폼에서는 테스트를 위한 일반적인 DevOps 프로세스를 만들고 변경 내용을 승격하는 것이 더 어렵습니다. 일반적으로 코드가 아닌 구성을 통해 변경합니다.

• 디자인: 코드가 낮은 플랫폼은 종종 비기능 요구 사항을 관리하지만 여전히 표준에 부합하는지 확인해야 합니다. 보안 및 안정성과 같은 이러한 요구 사항을 충족하는 방법을 신중하게 평가합니다.

낮은 코드 접근 방식에서 벗어나는 것을 고려해야 하는 경우

결국 요구 사항이 너무 복잡해져서 낮은 코드 솔루션에 현명하게 통합할 수 없게 될 수 있습니다. 요구 사항에 맞게 도구 제한 사항을 해결해야 하는 경우 관리되는 솔루션에서 사용자 지정 컨트롤 플레인으로 이동해야 합니다.

사용자 지정 컨트롤 플레인

완전히 사용자 지정된 컨트롤 플레인을 만들도록 선택할 수 있습니다. 이 옵션은 가장 유연하고 강력한 기능을 제공하지만 가장 많은 작업이 필요합니다.

테넌트 카탈로그는 일반적으로 데이터베이스에 저장됩니다. 카탈로그로 직접 작업하지는 않습니다. 대신 사용자 지정 애플리케이션 또는 조직의 CRM(고객 관계 관리) 애플리케이션과 같은 시스템과 같은 관리 인터페이스를 통해 관리합니다.

일반적으로 테넌트 관리 기능을 지원하기 위해 컨트롤 플레인 구성 요소 집합을 만듭니다. 이러한 구성 요소에는 관리 포털 또는 다른 사용자 인터페이스, API 및 백그라운드 처리 구성 요소가 포함될 수 있습니다. 테넌트 수명 주기 이벤트가 발생할 때 코드 또는 인프라를 배포해야 하는 경우 컨트롤 플레인에 배포 파이프라인을 추가할 수도 있습니다.

장기 실행 처리에서 적절한 도구를 사용하는지 확인합니다. 예를 들어 테넌트 온보딩을 오케스트레이션하거나 배포를 관리하거나 외부 시스템과 통신해야 하는 구성 요소에 Durable Functions 또는 Azure Logic Apps 를 사용할 수 있습니다.

낮은 코드 방식과 마찬가지로 이 방법을 사용하면 고객에게 셀프 서비스 등록을 제공할 수 있습니다. 웹 애플리케이션은 사용자의 개입 없이 테넌트 카탈로그에 레코드를 직접 추가할 수 있습니다.

다음 다이어그램에서는 셀프 서비스 등록을 제공하는 기본 사용자 지정 컨트롤 플레인을 만드는 방법을 보여줍니다.

이 아키텍처의 Visio 파일을 다운로드합니다.

사용자 지정 접근 방식의 장점

• 완전한 유연성 및 사용자 지정 가능성: 컨트롤 플레인의 기능을 완전히 제어할 수 있으며 요구 사항이 변경되면 수정할 수 있습니다.

• 테스트 용이성: 컨트롤 플레인 애플리케이션에 표준 소프트웨어 개발 수명 주기를 사용하고 기본 애플리케이션에 대해 수행하는 것처럼 테스트 및 배포에 대한 일반적인 접근 방식을 구현할 수 있습니다.

사용자 지정 접근 방식의 단점

• 유지 관리 책임: 이 방법을 사용하려면 모든 것을 직접 만들어야 하므로 유지 관리 오버헤드가 더 많이 필요합니다. 컨트롤 플레인은 애플리케이션의 다른 부분만큼 중요합니다. 컨트롤 플레인의 안정성과 보안을 보장하기 위해 컨트롤 플레인을 개발, 테스트 및 운영하는 데 주의해야 합니다.

하이브리드 접근 방식

수동 및 자동화된 시스템을 결합하는 하이브리드 접근 방식을 고려할 수도 있습니다. 또는 Microsoft Power Platform과 같은 관리형 플랫폼을 사용하고 사용자 지정 애플리케이션으로 보강할 수 있습니다. 사용자 지정 컨트롤 플레인의 유연성이 필요하지만 완전히 사용자 지정 시스템을 빌드하고 유지 관리하지 않으려는 경우 하이브리드 접근 방식을 구현하는 것이 좋습니다. 그러나 수동 프로세스 또는 관리되는 플랫폼에 대한 자동화된 사용자 지정은 완전히 사용자 지정된 시스템만큼 복잡해질 수 있습니다. 하이브리드 접근 방식을 유지 관리하기가 어려워지면 완전히 사용자 지정된 시스템으로 전환하는 것이 좋습니다.

점진적 구현

결국 컨트롤 플레인을 자동화하려는 경우에도 해당 접근 방식을 시작할 필요가 없습니다. 초기 단계에서 애플리케이션 개발의 일반적인 접근 방식은 수동 제어 평면으로 시작하는 것입니다. 애플리케이션이 진행되고 더 많은 테넌트가 온보딩되면 병목 현상 영역을 식별하고 필요에 따라 자동화합니다. 이러한 변화는 하이브리드 접근 방식을 향해 이동합니다. 더 많은 작업을 자동화할 때 완전히 자동화된 컨트롤 플레인으로 전환할 수 있습니다.

피해야 할 안티패턴

• 수동 프로세스에 너무 오래 의존: 수동 프로세스는 시작하거나 테넌트 수가 적고 경량 관리가 필요할 때 잘 작동합니다. 하지만 성장함에 따라 자동화된 솔루션으로 확장하는 방법을 계획해야 합니다. 수동 프로세스의 요구를 따라잡기 위해 더 많은 팀 구성원을 고용해야 하는 경우 컨트롤 플레인의 일부를 자동화하는 것이 좋습니다.

• 장기 실행 워크플로에 부적절한 도구 사용: Azure Resource Manager 배포 또는 다중 단계 오케스트레이션과 같은 장기 실행 작업에는 표준 Azure 함수 또는 동기 API 호출과 같은 런타임 제한이 있는 도구를 사용하지 마세요. 대신 , Logic Apps 및 Durable Functions와 같은 장기 실행 워크플로 또는 작업 시퀀스를 지원하는 도구를 사용합니다. 자세한 내용은 Azure Functions 성능 및 안정성 및비동기 Request-Reply 패턴을 참조하세요.

기여자

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

주요 작성자:

• John Downs | 주요 소프트웨어 엔지니어, Azure 패턴 및 사례
• Landon Pierce | 고객 엔지니어

기타 기여자:

• 보단 체르치크 | 선임 고객 엔지니어
• 아르센 블라디미르스키 | 수석 고객 엔지니어

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

다음 단계

• Microsoft Power Platform
• 파워 오토메이트

관련 리소스

• 다중 테넌트 솔루션의 제어 평면에 대한 아키텍처 고려 사항
• 다중 테넌트 솔루션에 대한 아키텍처 접근 방식