다음을 통해 공유

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

  • 아티클

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

  • 테넌트에 대한 중요한 정보를 저장하는 테넌트 카탈로그:
    • 테넌트 구성.
    • 테넌트 리소스에 대해 배포된 SKU입니다.
    • 테넌트가 할당되는 배포 스탬프입니다.
  • 테넌트 수명 주기 이벤트에 의해 트리거되는 환경의 변경 내용을 관리하기 위한 프로세스입니다. 예를 들어 테넌트 온보딩, 테넌트 오프보딩 및 필요한 정기적인 유지 관리가 있습니다.

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

이 문서에서는 컨트롤 플레인을 디자인하고 만드는 데 고려할 수 있는 몇 가지 방법을 설명합니다. 여기에 설명된 접근 방식 목록은 포괄적이지 않습니다. 이 방법은 모두 유효하지만 다른 유효한 아키텍처가 있습니다.

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

다음 표에서는 컨트롤 플레인에 대해 고려할 수 있는 몇 가지 방법 간의 차이점을 요약합니다. 수동, 하위 코드 및 사용자 지정 방법을 비교합니다.

고려 사항 수동 로우 코드 사용자 지정
운영 오버헤드 높음 낮음-중간 낮음
이 방법이 적합한 수명 주기 이벤트의 빈도 희귀 가끔씩 자주
구현할 시간과 복잡성 낮음 중간 높음
컨트롤 플레인 유지 관리 책임 낮음 중간 높음
테스트 가능성 낮음 중간 높음
불일치 위험 높음 중간-낮음 낮음

수동 프로세스

완전히 자동화된 컨트롤 플레인을 빌드하는 것이 항상 중요한 것은 아니며, 특히 시작 중이고 소수의 테넌트만 있는 경우 특히 그렇습니다.

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

참고 항목

수동 제어 평면은 다중 테넌트 애플리케이션 관리를 시작하는 좋은 방법이지만 소수의 테넌트(5-10 미만)에만 적합합니다. 수동으로 온보딩하는 각 테넌트에 따라 관리 오버헤드 및 불일치 위험이 증가합니다. 테넌트가 몇 개뿐이고 자동화 또는 셀프 서비스 온보딩이 필요하지 않은 경우에만 이 방법을 사용해야 합니다.

테넌트 온보딩 및 유지 관리 활동과 같은 프로세스의 경우:

  • 스크립트를 수동으로 실행하더라도 가능한 경우 스크립트 또는 자동화된 파이프라인을 만듭니다. 스크립트 또는 파이프라인을 사용하여 각 테넌트에 대해 단계가 일관되게 실행되도록 합니다.
  • 처음에 스크립깅할 수 없는 작업의 경우 프로세스를 철저하고 명시적으로 문서화합니다. 방법 및 이유를 문서화합니다. 누군가가 나중에 작업을 자동화하게 되면 둘 다 잘 이해해야 합니다.

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

컨트롤 플레인에 스크립트 및 기타 수동 프로세스를 사용하는 한 가지 방법을 보여 주는 다이어그램

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

수동 접근 방식의 장점

  • 경량: 설명서, 스크립트 및 파이프라인은 쉽게 개발하고 수정할 수 있습니다. 이렇게 하면 프로세스를 신속하게 반복하고 발전시킬 수 있으므로 프로세스를 구성할 때 적합합니다.
  • 저렴한 비용: 수동 접근 방식을 유지 관리하고 실행하는 것은 저렴합니다.
  • 프로세스의 유효성을 검사합니다. 결국 더 자동화된 접근 방식을 사용하려는 경우에도 개념 증명으로 수동 접근 방식을 시작하는 것이 더 강력한 자동화 개발에 시간을 투자하기 전에 유지 관리 전략의 유효성을 검사하는 좋은 방법입니다.

수동 접근 방식의 단점

  • 제어 부족: 이 접근 방식은 올바른 작업을 수행하는 데 관련된 모든 사람에게 의존합니다. 누군가가 실수로 또는 의도적으로 규정 된 프로세스에서 벗어날 수 있습니다. 프로세스의 모든 변화는 환경의 불일치 위험을 증가하므로 지속적인 관리가 훨씬 더 어려워집니다.
  • 액세스 제어 과제: 이 방법을 사용하는 경우 일반적으로 솔루션을 운영하는 모든 사람에게 광범위하게 범위가 지정되어 매우 관대한 액세스 권한을 부여해야 하므로 액세스 세분화에 대한 모범 사례를 따르기가 어렵습니다.
  • 확장성: 수동 프로세스를 실행하는 데 필요한 작업은 관리해야 하는 테넌트 수로 확장됩니다.
  • 테스트 용이성: 수동 프로세스는 유효성을 검사하고 테스트하기 어렵습니다.

수동 접근 방식에서 벗어나는 것을 고려해야 하는 경우

  • 팀이 애플리케이션을 유지 관리하기 위해 수행해야 하는 작업량을 따라갈 수 없는 경우 예를 들어 테넌트 수가 중요한 지점 이상으로 확장되는 경우 대부분의 팀에서는 5~10개의 테넌트 사이입니다.
  • 중요한 수의 테넌트를 초과하여 테넌트 증가를 예상하고 해당 테넌트 수를 관리하는 데 관련된 작업을 준비해야 하는 경우.
  • 불일치의 위험을 완화해야 하는 경우 예를 들어 누군가가 프로세스를 올바르게 따르지 않거나 프로세스에 너무 많은 모호성이 있기 때문에 발생하는 몇 가지 실수를 관찰할 수 있습니다. 일반적으로 더 많은 테넌트가 수동으로 온보딩되고 팀이 성장함에 따라 불일치 위험이 증가합니다.

로우 코드 컨트롤 플레인

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

Microsoft Power Platform은 이러한 플랫폼 중 하나의 예입니다. Power Platform을 사용하는 경우 Dynamics 365, Dataverse 또는 Microsoft 365에서 테넌트 카탈로그를 유지할 수 있습니다. 처음에는 모든 것을 자동화하는 데 완전히 커밋하지 않으려는 경우 수동 프로세스에 사용하는 것과 동일한 테넌트 카탈로그를 유지하는 것이 좋습니다.

테넌트 온보딩 및 유지 관리의 경우 Power Automate를 사용하여 테넌트 관리를 수행하고, 테넌트를 구성하고, 파이프라인 또는 API 호출을 트리거하는 워크플로를 실행할 수 있습니다. Power Automate에서 데이터에 액세스할 수 있는 위치에 있는 경우 Power Automate를 사용하여 테넌트 카탈로그의 변경 내용을 감시할 수 있습니다. 수동 테넌트 카탈로그를 사용하는 경우 Power Automate 워크플로를 수동으로 트리거할 수도 있습니다. 팀의 누군가가 무언가를 확인하거나 완전히 자동화할 수 없는 추가 단계를 수행해야 하는 경우 워크플로에 수동 승인 단계를 포함하도록 결정할 수 있습니다.

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

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

Power Automate 및 Dataverse를 로우 코드 컨트롤 플레인으로 사용하는 한 가지 방법을 보여 주는 다이어그램

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

로우 코드 접근 방식의 이점

  • 경량: 낮은 코드 워크플로 집합을 만들고 주변 시스템에 연결하는 것은 빠르고 저렴합니다.
  • 플랫폼 도구 사용: 네이티브 플랫폼 기능을 사용하여 데이터를 저장하고, 팀에서 사용할 관리 포털을 만들고, 워크플로가 실행되는 동안 모니터링할 수 있습니다. 네이티브 플랫폼 기능을 사용하면 많은 구성 요소를 직접 빌드하지 않아도 됩니다.
  • 사용자 지정 가능: 더 많은 사용자 지정이 필요한 경우 일반적으로 사용자 지정 코드 및 프로세스로 워크플로를 보강할 수 있습니다. 예를 들어 Power Automate를 사용하여 GitHub Actions에서 배포 워크플로를 트리거하거나 Azure Functions를 호출하여 사용자 고유의 코드를 실행할 수 있습니다. 이는 점진적 구현을 용이하게 하는 데도 도움이 됩니다.
  • 낮은 오버헤드: 낮은 코드 서비스는 일반적으로 완전히 관리되므로 인프라를 관리할 필요가 없습니다.

낮은 코드 접근 방식의 단점

  • 필수 전문 지식: 낮은 코드 플랫폼을 사용하여 프로세스를 만들고 이러한 플랫폼을 효과적으로 사용하려면 일반적으로 독점적인 지식이 필요합니다. 많은 조직에서 이미 이러한 도구를 사용하므로 팀에는 이미 필요한 전문 지식이 있을 수 있지만 그렇지 않을 수도 있습니다. 이러한 플랫폼을 효과적으로 사용하기 위해 팀을 교육해야 하는지 여부를 고려해야 합니다.
  • 관리: 대량의 낮은 코드 구성 관리를 처리하는 것은 어려울 수 있습니다.
  • 테스트 용이성: 컨트롤 플레인의 변경 내용을 테스트하고 승격하는 방법을 고려합니다. 관리되는 플랫폼에서는 일반적으로 코드가 아닌 구성을 통해 변경되므로 테스트 및 승격을 위한 일반적인 DevOps 프로세스를 만드는 것이 더 어렵습니다.
  • 디자인: 보안 및 안정성과 같은 비기능적 요구 사항을 충족하는 방법에 대해 신중하게 생각해 보세요. 이러한 요구 사항은 종종 낮은 코드 플랫폼에서 관리됩니다.

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

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

사용자 지정 컨트롤 플레인

사용자 고유의 완전히 사용자 지정된 컨트롤 플레인을 만드는 것도 고려할 수 있습니다. 이 옵션은 가장 유연하고 강력한 기능을 제공하지만 가장 많은 작업이 필요합니다. 테넌트 카탈로그는 일반적으로 데이터베이스에 저장됩니다. 이 경우 카탈로그를 직접 사용하지 않고 대신 사용자 지정 애플리케이션 또는 조직의 CRM(고객 관계 관리) 애플리케이션과 같은 시스템일 수 있는 관리 인터페이스를 통해 관리합니다.

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

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

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

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

Durable Functions, SQL 데이터베이스 및 서비스 버스를 사용하여 만든 컨트롤 플레인을 보여 주는 다이어그램

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

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

  • 완전한 유연성 및 사용자 지정 가능성: 컨트롤 플레인의 기능을 완벽하게 제어할 수 있으며 요구 사항이 변경되면 변경할 수 있습니다.
  • 테스트 용이성: 컨트롤 플레인 애플리케이션에 표준 SDLC(소프트웨어 개발 수명 주기)를 사용하고 기본 애플리케이션과 마찬가지로 테스트 및 배포에 대한 일반적인 접근 방식을 구현할 수 있습니다.

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

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

하이브리드 접근 방식

하이브리드 접근 방식을 사용하는 것도 고려할 수 있습니다. 수동 및 자동화된 시스템의 조합을 사용하거나 Microsoft Power Platform과 같은 관리형 플랫폼을 사용하여 사용자 지정 애플리케이션으로 보강할 수 있습니다. 사용자 지정 컨트롤 플레인의 사용자 지정이 필요하지만 완전히 사용자 지정 시스템을 빌드하고 유지 관리하지 않으려는 경우 하이브리드 접근 방식을 구현하는 것이 좋습니다. 어떤 시점에서 수동 프로세스 또는 관리되는 플랫폼에 대한 자동화된 사용자 지정은 완전히 사용자 지정된 시스템만큼 복잡해질 수 있습니다. 티핑 포인트는 모든 조직에 대해 다르지만 하이브리드 접근 방식을 유지 관리하는 것이 번거로운 경우 완전히 사용자 지정 시스템으로 전환하는 것이 좋습니다.

점진적 구현

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

피해야 할 안티패턴

  • 너무 오랫동안 수동 프로세스에 의존합니다. 시작하거나 테넌트 수가 적고 매우 간단한 관리가 필요한 경우 수동 프로세스를 사용하는 것이 합리적이지만 성장함에 따라 자동화된 솔루션으로 확장하는 방법을 계획해야 합니다. 수동 프로세스의 요구를 따라잡기 위해 추가 팀 구성원을 고용해야 하는 경우 컨트롤 플레인의 일부를 자동화하기 시작해야 한다는 좋은 신호입니다.
  • 장기 실행 워크플로에 부적절한 도구 사용 예를 들어 표준 Azure 함수, 동기 API 호출 또는 실행 시간 제한이 있는 기타 도구를 사용하여 Azure Resource Manager 배포 또는 다단계 오케스트레이션과 같은 장기 실행 작업을 수행하지 않도록 합니다. 대신, 장기 실행 워크플로 또는 작업 시퀀스를 수행할 수 있는 Azure Logic Apps, Durable Functions 및 기타 도구와 같은 도구를 사용합니다. 자세한 내용은 Azure Functions 성능 및 안정성 및 비동기 요청-회신 패턴을 참조하세요.

참가자

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

주요 작성자:

기타 기여자:

다음 단계