다중 테넌트 컨트롤 플레인에 대한 고려 사항

다중 테넌트 솔루션은 여러 평면으로 구성되어 있으며, 각각의 평면은 고유한 책임을 가지고 있습니다. 데이터 평면을 사용하면 사용자와 클라이언트가 시스템과 상호 작용할 수 있습니다. 컨트롤 플레인은 플랫폼 관리자의 작업을 지원하기 위해 모든 테넌트에서 액세스 제어, 프로비전 및 시스템 유지 관리와 같은 상위 수준 작업을 관리합니다.

이 문서에서는 컨트롤 플레인의 책임 및 요구 사항에 맞는 컨트롤 플레인을 디자인하는 방법에 대한 정보를 제공합니다.

예를 들어 재무 레코드를 관리하기 위한 부기 시스템을 고려해 보세요. 여러 테넌트가 시스템에 재무 기록을 저장합니다. 사용자가 시스템에 액세스하여 재무 레코드를 보고 입력할 때 데이터 평면을 사용합니다. 데이터 평면은 솔루션의 기본 애플리케이션 구성 요소일 가능성이 높습니다. 테넌트는 일반적으로 의도한 대로 시스템을 사용하기 위한 기본 인터페이스로 봅니다.

반면, 컨트롤 플레인은 새 테넌트에 온보딩하고, 각 테넌트에 대한 데이터베이스를 만들고, 다른 관리 및 유지 관리 작업을 수행합니다. 제어 평면이 없으면 관리자는 수동 프로세스를 사용해야 합니다. 경우에 따라 데이터 평면과 제어 평면 작업이 얽혀서 솔루션이 과도하게 복잡해집니다.

많은 복잡한 시스템에는 컨트롤 플레인이 포함됩니다. 예를 들어 Azure 컨트롤 플레인 Azure Resource Manager는 Azure 리소스를 배포하고 구성하는 API, 도구 및 백 엔드 구성 요소 집합입니다. 또한 Kubernetes 컨트롤 플레인은 작업자 노드에 Kubernetes Pod를 배치하는 것과 같은 많은 작업을 관리합니다. 거의 모든 SaaS(Software as a Service) 솔루션에는 테넌트 간 작업을 처리하는 컨트롤 플레인이 있습니다.

다중 테넌트 솔루션을 디자인할 때는 컨트롤 플레인을 고려해야 합니다. 다음 섹션에서는 컨트롤 플레인의 범위를 지정하고 디자인하는 방법을 설명합니다.

컨트롤 플레인의 책임

컨트롤 플레인 또는 해당 책임에 대한 템플릿은 하나도 없습니다. 솔루션의 요구 사항 및 아키텍처는 컨트롤 플레인에서 수행해야 하는 작업과 작동 방식을 결정합니다. 일부 다중 테넌트 솔루션에서 컨트롤 플레인은 광범위한 책임을 가지며 그 자체로 복잡한 시스템입니다. 다른 다중 테넌트 솔루션에서 컨트롤 플레인에는 기본적인 책임만 있습니다.

일반적으로 컨트롤 플레인에는 다음과 같은 많은 핵심 책임이 있을 수 있습니다.

• 리소스 관리: 테넌트별 리소스를 포함하여 워크로드를 제공하는 시스템 리소스를 프로비전하고 관리합니다. 컨트롤 플레인은 배포 파이프라인을 호출 및 오케스트레이션 하거나 배포 작업을 직접 실행할 수 있습니다.

• 리소스 구성: 새 테넌트가 인식되도록 공유 리소스를 다시 구성 합니다. 예를 들어 컨트롤 플레인은 들어오는 트래픽이 올바른 테넌트의 리소스에 도달하도록 네트워크 라우팅을 구성하거나 리소스 용량을 조정해야 할 수 있습니다.

• 테넌트 구성: 각 테넌트 구성을 저장하고 관리합니다.

• 테넌트 수명 주기 관리: 테넌트 온보딩, 재배치 및 오프보딩을 포함하여 테넌트 수명 주기 이벤트를 처리합니다.

• 원격 측정: 각 테넌트의 사용된 기능과 시스템 성능을 추적합니다.

• 소비 추적:각 테넌트의 리소스 소비량을 측정하고 집계합니다. 소비 메트릭은 청구 시스템에 알리거나 리소스 거버넌스를 지원할 수 있습니다.

완전 다중 테넌트 모델을 사용하고 테넌트별 리소스를 배포하지 않는 경우 기본 컨트롤 플레인은 테넌트 및 관련 메타데이터만 추적할 수 있습니다. 예를 들어 새 테넌트가 서비스에 등록할 때 컨트롤 플레인은 데이터베이스의 적절한 레코드를 업데이트하여 나머지 시스템이 새 테넌트의 요청을 처리할 수 있도록 할 수 있습니다.

반면, 솔루션이 자동화된 단일 테넌트 모델과 같은 테넌트별 인프라가 필요한 배포 모델을 사용하는 경우 컨트롤 플레인에 더 많은 책임이 있을 수 있습니다. 새 테넌트를 온보딩할 때 Azure 인프라를 배포하거나 다시 구성해야 할 수 있습니다. 이 시나리오에서 컨트롤 플레인은 Resource Manager 또는 Kubernetes 컨트롤 플레인과 같은 다른 도구에 대한 컨트롤 플레인과 상호 작용할 수 있습니다.

고급 제어 평면은 더 많은 책임을 맡을 수 있습니다.

• 자동화된 유지 관리 작업: 이전 데이터 삭제 또는 보관, 데이터베이스 인덱스 만들기 및 관리, 비밀 및 암호화 인증서 회전을 비롯한 일반적인 유지 관리 작업을 수행합니다.

• 테넌트 배치: 스탬프 사용 목표, 테넌트 요구 사항 및 빈 압축 전략과 같은 기준에 따라 기존 배포 또는 스탬프에 테넌트 할당

• 테넌트 리밸런싱: 사용량이 변경됨에 따라 배포 스탬프 간에 기존 테넌트 균형을 조정합니다.

• 고객 활동 추적: Dynamics 365와 같은 외부 고객 관리 솔루션과 통합하여 고객 활동을 추적합니다.

컨트롤 플레인 범위 지정

솔루션에 대한 컨트롤 플레인을 빌드하는 데 얼마나 많은 노력을 기울이는지 신중하게 고려합니다. 컨트롤 플레인은 직접적인 고객 가치를 제공하지 않으므로 고품질 컨트롤 플레인 설계 및 빌드에 대한 엔지니어링 노력을 정당화하기 어려울 수 있습니다. 그러나 시스템이 성장하고 확장됨에 따라 성장을 따라잡기 위해 자동화된 관리 및 운영이 점점 더 필요합니다.

특정 상황에서는 모든 제어 평면이 필요하지 않을 수 있습니다. 시스템에 테넌트가 10개 미만인 경우 이 방법이 작동할 수 있습니다. 팀은 제어 평면의 책임을 맡아 수동 작업 및 프로세스를 사용하여 테넌트 온보딩 및 관리할 수 있습니다. 그러나 테넌트 및 해당 구성을 추적하기 위한 프로세스와 중앙 위치를 유지 관리해야 합니다.

몇 가지 테넌트를 넘어 성장하면 각 테넌트를 추적하고 리소스 및 테넌트 전체에서 모니터링을 적용하는 이점을 얻을 수 있습니다. 팀에서 테넌트 관리에 점점 더 많은 시간과 노력을 소비하는 것을 알 수 있습니다. 또는 팀 구성원이 관리 작업을 수행하는 방식의 불일치로 인해 버그 또는 운영 문제가 발생할 수 있습니다. 이러한 상황이 발생하는 경우 이러한 책임을 맡을 보다 포괄적인 제어 평면을 빌드하는 것이 좋습니다.

컨트롤 플레인 디자인

컨트롤 플레인의 요구 사항 및 범위를 확인한 후에는 컨트롤 플레인을 설계하고 아키텍처를 구성해야 합니다. 컨트롤 플레인은 중요한 구성 요소이며 아키텍처의 다른 부분과 동일한 수준의 계획을 수립할 자격이 있습니다.

고려 사항

이러한 고려 사항은 워크로드의 품질을 향상시키는 데 사용할 수 있는 일련의 기본 원칙인 Azure Well-Architected Framework의 핵심 요소를 구현합니다. 자세한 내용은 Well-Architected Framework를 참조하세요.

컨트롤 플레인은 자체 시스템으로 작동하므로 디자인할 때 Well-Architected Framework 의 5가지 핵심 요소를 모두 고려해야 합니다. 다음 섹션에서는 집중해야 할 특정 영역을 강조 표시합니다.

신뢰도

안정성은 애플리케이션이 고객에 대한 약정을 충족할 수 있도록 하는 데 도움이 됩니다. 자세한 내용은 안정성에 대한 디자인 검토 검사 목록을 참조하세요.

컨트롤 플레인은 종종 중요 업무용 구성 요소 역할을 합니다. 컨트롤 플레인에 필요한 적절한 수준의 복원력과 안정성을 계획해야 합니다.

컨트롤 플레인 중단의 영향을 고려합니다. 극단적인 경우 중단으로 전체 솔루션을 사용할 수 없게 될 수 있습니다. 컨트롤 플레인이 단일 실패 지점이 아니더라도 중단으로 인해 다음과 같은 문제가 발생할 수 있습니다.

• 시스템에서 새 테넌트에 등록할 수 없으므로 판매 및 비즈니스 성장에 영향을 줄 수 있습니다.

• 시스템에서 기존 테넌트는 관리할 수 없으므로 지원 팀에 더 많은 호출이 발생합니다.

• 테넌트의 소비량을 측정하거나 사용량에 대해 청구할 수 없으므로 수익 손실이 발생합니다.

• 보안 인시던트에 대한 응답으로 테넌트를 사용하지 않도록 설정하거나 다시 구성할 수 없습니다.

• 유지 관리 부채가 누적되어 시스템에 장기적인 손상을 입힙니다. 예를 들어 솔루션에 오래된 데이터를 야간 정리해야 하는 경우 디스크가 가득 차거나 성능이 저하할 수 있습니다.

가용성 목표, RTO(복구 시간 목표) 및 RPO(복구 지점 목표)를 포함하여 제어 평면에 대한 서비스 수준 목표를 정의합니다. 컨트롤 플레인에 대해 설정한 목표가 고객에게 제공하는 목표와 다를 수 있습니다.

안전

보안은 의도적인 공격 및 중요한 데이터 및 시스템의 오용에 대한 보증을 제공합니다. 자세한 내용은 보안성에 대한 디자인 검토 검사 목록을 참조하세요.

컨트롤 플레인은 종종 높은 권한이 있는 시스템입니다. 컨트롤 플레인 내의 보안 문제는 치명적인 결과를 초래할 수 있습니다. 디자인 및 기능에 따라 컨트롤 플레인은 다음 형식을 포함하여 다양한 유형의 공격에 취약할 수 있습니다.

• 비밀에 대한 무단 액세스: 컨트롤 플레인은 모든 테넌트에 대한 키 및 비밀에 액세스할 수 있습니다. 제어 평면에 액세스할 수 있는 공격자는 모든 테넌트의 데이터 또는 리소스에 액세스할 수 있습니다.

• 배포 기능 남용: 컨트롤 플레인은 종종 Azure에 새 리소스를 배포할 수 있습니다. 공격자는 컨트롤 플레인을 악용하여 구독에 자신의 리소스를 배포하고 잠재적으로 막대한 비용이 발생할 수 있습니다.

• 서비스 거부: 공격자가 컨트롤 플레인을 사용하지 않도록 설정하면 시스템 및 비즈니스에 즉각적이고 장기적인 손상이 발생할 수 있습니다. 컨트롤 플레인 가동 중지 시간의 잠재적인 결과는 안정성을 참조 하세요.

컨트롤 플레인을 디자인하고 구현할 때 보안 모범 사례를 따르고 포괄적인 위협 모델을 만들어야 합니다. 이 모델은 솔루션의 잠재적 위협 및 보안 문제를 식별하고 완화해야 합니다.

운영 효율성

운영 우수성은 애플리케이션을 배포하고 프로덕션에서 계속 실행하는 운영 프로세스를 다룹니다. 자세한 내용은 Operational Excellence에 대한 디자인 검토 검사 목록을 참조하세요.

컨트롤 플레인은 중요한 구성 요소이므로 프로덕션 환경에서 배포하고 작동하는 방법을 신중하게 고려해야 합니다.

솔루션의 다른 부분과 마찬가지로 해당 기능을 철저히 테스트할 수 있도록 컨트롤 플레인의 비프로덕션 인스턴스를 배포해야 합니다. 컨트롤 플레인에서 배포 작업을 수행하는 경우 비프로덕션 제어 평면이 Azure 환경과 상호 작용하는 방식과 비프로덕션 리소스를 배포할 Azure 구독을 고려합니다. 실수로 요금이 누적되지 않도록 테스트 리소스를 신속하게 정리하는 방법을 계획합니다.

또한 컨트롤 플레인에 대한 팀의 액세스를 제어하는 방법을 계획합니다. 팀 구성원이 업무를 수행하는 데 필요한 권한만 부여합니다. 이 방법은 보안 인시던트 방지 및 우발적인 잘못된 구성의 영향을 줄이는 데 도움이 됩니다.

구성 요소

컨트롤 플레인을 빌드하기 위한 템플릿은 하나도 없습니다. 디자인하고 빌드하는 구성 요소는 요구 사항에 따라 달라집니다. 대부분의 컨트롤 플레인은 API 및 백그라운드 작업자 구성 요소로 구성됩니다. 일부 솔루션에서 컨트롤 플레인에는 팀이나 고객이 사용할 수 있는 사용자 인터페이스도 포함되어 있습니다.

테넌트 워크로드에서 컨트롤 플레인 격리

컨트롤 플레인의 리소스를 테넌트의 데이터 평면을 제공하는 리소스와 분리해야 합니다. 예를 들어 별도의 데이터베이스 서버, 애플리케이션 서버 및 기타 구성 요소를 사용합니다. 테넌트별 리소스와 별도로 전용 Azure 리소스 그룹에 컨트롤 플레인 리소스를 유지합니다.

컨트롤 플레인 격리는 다음과 같은 이점을 제공합니다.

• 크기 조정을 별도로 구성할 수 있습니다. 예를 들어 컨트롤 플레인에는 일관된 리소스 요구 사항이 있을 수 있으며 테넌트의 리소스는 필요에 따라 탄력적으로 확장될 수 있습니다.

• 명확한 분리는 컨트롤 플레인과 데이터 평면 사이에 격벽 을 만들어 시끄러운 이웃 문제가 솔루션 전체에 퍼지는 것을 방지하는 데 도움이 됩니다.

• 컨트롤 플레인은 일반적으로 높은 수준의 액세스 권한을 가진 높은 권한이 있는 시스템입니다. 컨트롤 플레인 격리는 보안 취약성의 가능성을 줄여 공격자가 전체 시스템에서 권한을 상승시킬 수 있도록 합니다.

• 별도의 네트워킹 및 방화벽 구성을 배포할 수 있습니다. 데이터 평면 및 제어 평면에는 일반적으로 다양한 유형의 네트워크 액세스가 필요합니다.

장기 실행 작업의 시퀀스 오케스트레이션

컨트롤 플레인은 종종 여러 시스템 간의 조정이 필요한 장기 실행 작업을 수행합니다. 이러한 작업에는 복잡한 오류 모드가 있을 수도 있으므로 장기 실행 작업 또는 워크플로를 지원하는 기술을 선택해야 합니다.

예를 들어 새 테넌트를 온보딩할 때 컨트롤 플레인은 다음 작업을 순서대로 실행할 수 있습니다.

1. 새 데이터베이스를 배포합니다. 이 Azure 배포 작업을 완료하는 데 몇 분 정도 걸릴 수 있습니다.

2. 테넌트 메타데이터 카탈로그를 업데이트합니다. 이 작업에는 Azure SQL 데이터베이스에 대한 명령 실행이 포함될 수 있습니다.

3. 새 테넌트에 환영 전자 메일을 보냅니다. 이 작업은 Microsoft가 아닌 API를 호출하여 전자 메일을 보냅니다.

4. 새 테넌트에 대한 청구서를 준비하도록 청구 시스템을 업데이트합니다. 이 작업은 가끔 실패하는 비 Microsoft API를 호출합니다.

5. 새 테넌트 추적을 위해 CRM(고객 관계 관리) 시스템을 업데이트합니다. 이 작업은 Microsoft가 아닌 API를 호출합니다.

시퀀스의 단계가 실패하는 경우 응답하는 방법을 고려합니다.

• 실패한 작업을 다시 시도합니다. 예를 들어 2단계의 Azure SQL 명령이 일시적인 오류로 실패하는 경우 다시 시도할 수 있습니다.

• 다음 단계를 계속 진행합니다. 예를 들어 판매 팀이 나중에 고객을 수동으로 추가할 수 있으므로 청구 시스템에 대한 업데이트가 실패하도록 허용할 수 있습니다.

• 워크플로를 포기하고 수동 복구 프로세스를 트리거합니다.

또한 각 실패 시나리오에 대한 사용자 환경을 고려합니다.

공유 구성 요소 관리

컨트롤 플레인은 특정 테넌트에 전용이 아닌 공유되는 모든 구성 요소를 인식해야 합니다. 일부 구성 요소는 스탬프 내의 모든 테넌트 간에 공유될 수 있습니다. 다른 구성 요소는 지역의 모든 스탬프 간에 공유되거나 모든 지역 및 스탬프에서 전역적으로 공유될 수도 있습니다. 테넌트를 온보딩, 다시 구성 또는 오프보딩할 때 컨트롤 플레인은 이러한 공유 구성 요소를 처리하는 방법을 알고 있어야 합니다.

일부 공유 구성 요소는 테넌트가 추가되거나 제거될 때 재구성이 필요합니다. 예를 들어 전역적으로 공유되는 Azure Front Door 프로필이 있다고 가정해 보겠습니다. 사용자 지정 도메인 이름이 있는 테넌트를 추가하는 경우 컨트롤 플레인은 해당 도메인 이름에 대한 요청을 올바른 애플리케이션으로 라우팅하도록 프로필의 구성을 업데이트해야 할 수 있습니다. 마찬가지로 테넌트가 오프보딩되면 하위 도메인 인수 공격을 방지하기 위해 컨트롤 플레인이 Azure Front Door 프로필에서 사용자 지정 도메인 이름을 제거해야 할 수 있습니다.

공유 구성 요소에는 컨트롤 플레인에서 따라야 하는 복잡한 크기 조정 규칙이 있을 수 있습니다. 예를 들어 빈 압축 방법을 사용하여 테넌트의 데이터베이스를 배포하는 경우 컨트롤 플레인은 각 새 데이터베이스를 Azure SQL 탄력적 풀에 할당해야 합니다.

추가하는 10번째 데이터베이스마다 풀에 할당된 리소스를 늘려야 한다고 판단할 수 있습니다. 테넌트를 추가하거나 제거할 때 컨트롤 플레인은 풀의 구성을 다시 평가하고 풀의 리소스를 변경할지 여부를 결정해야 합니다. 단일 탄력적 풀에 할당할 수 있는 최대 데이터베이스 수에 도달하면 새 풀을 만들고 새 테넌트 데이터베이스에 해당 풀을 사용해야 합니다. 컨트롤 플레인은 변경이 발생할 때 크기 조정 및 재구성을 포함하여 이러한 공유 구성 요소를 각각 관리해야 합니다.

컨트롤 플레인에서 공유 구성 요소를 관리하는 경우 여러 작업이 병렬로 발생할 때 발생할 수 있는 경합 상태를 인식하는 것이 중요합니다. 예를 들어 다른 테넌트를 오프보딩하는 동시에 새 테넌트를 온보딩하는 경우 최종 최종 상태가 일관되고 크기 조정 요구 사항을 충족하는지 확인해야 합니다.

여러 컨트롤 플레인 사용

복잡한 환경에서는 여러 영역을 관리하는 여러 컨트롤 플레인을 사용해야 할 수 있습니다. 많은 다중 테넌트 솔루션은 여러 스탬프에서 배포 스탬프 패턴 및 분할 테넌트를 따릅니다. 이 패턴에서는 전역 및 스탬프 책임을 위한 별도의 컨트롤 플레인을 만들 수 있습니다.

전역 컨트롤 플레인

전역 컨트롤 플레인은 일반적으로 테넌트에 대한 전반적인 관리 및 추적을 처리합니다. 전역 컨트롤 플레인에는 다음과 같은 책임이 있을 수 있습니다.

• 테넌트 배치: 전역 컨트롤 플레인은 테넌트가 사용해야 하는 스탬프를 결정합니다. 테넌트 지역, 각 스탬프의 용량 사용량 및 테넌트의 서비스 수준 요구 사항과 같은 요인에 따라 이 결정을 내릴 수 있습니다.

• 테넌트 온보딩 및 수명 주기 관리: 이러한 책임에는 배포에서 모든 테넌트 추적이 포함됩니다.

스탬프 컨트롤 플레인

각 배포 스탬프에는 해당 스탬프에 할당된 테넌트 및 리소스를 관리하는 자체 스탬프 제어 평면이 포함됩니다. 스탬프 컨트롤 플레인에는 다음과 같은 책임이 있을 수 있습니다.

• 테넌트 리소스 프로비저닝: 데이터베이스 및 스토리지 컨테이너와 같은 스탬프 내에서 테넌트별 리소스를 만들고 관리합니다.

• 공유 리소스 관리:공유 리소스 의 소비를 모니터링하고 최대 용량에 접근할 때 새 인스턴스를 배포합니다.

• 유지 관리 작업: 데이터베이스 인덱스 관리 및 정리 작업과 같은 스탬프 내의 작업을 처리합니다.

각 스탬프의 컨트롤 플레인은 전역 컨트롤 플레인과 좌표입니다. 예를 들어 새 테넌트가 등록하는 경우 전역 제어 평면은 처음에 테넌트의 리소스에 대한 스탬프를 선택할 수 있습니다. 그런 다음 전역 컨트롤 플레인이 스탬프의 컨트롤 플레인에 테넌트에 필요한 리소스를 생성하라고 지시합니다.

다음 다이어그램에서는 두 컨트롤 플레인이 단일 시스템에서 공존하는 방법을 보여줍니다.

테넌트 제어 평면

테넌트는 테넌트 수준 컨트롤 플레인을 사용하여 자체 논리 또는 물리적 리소스를 관리할 수 있습니다. 테넌트 컨트롤 플레인에는 다음과 같은 책임이 있을 수 있습니다.

• 구성 관리: 사용자 액세스와 같은 테넌트별 구성을 처리합니다.

• 테넌트 시작 유지 관리 작업: 데이터 백업 또는 이전 백업 다운로드와 같은 작업을 지원합니다.

• 업데이트 관리: 테넌트가 애플리케이션에 대한 자체 업데이트를 제어할 수 있도록 허용하는 경우 업데이트를 수행합니다.

다음 다이어그램에서는 전역 컨트롤 플레인, 스탬프 컨트롤 플레인 및 테넌트 제어 평면이 있는 복잡한 시스템을 보여줍니다.

기여자

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

대표 저자:

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

기타 기여자:

• 보흐단 체르치크 | 선임 고객 엔지니어, Azure용 FastTrack
• 랜던 피어스 | 고객 엔지니어, Azure용 FastTrack
• Daniel Scott-Raynsford | 파트너 기술 전략가
• Arsen Vladimirskiy | 수석 고객 엔지니어, FastTrack for Azure

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

다음 단계

• 잘 설계된 프레임워크

관련 리소스

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