테넌트 통합 및 데이터 액세스를 위한 아키텍처 접근 방식

시스템이 조직의 경계를 넘어 통합되는 것이 일반적입니다. 다중 테넌트 솔루션을 빌드할 때 테넌트의 시스템으로 데이터를 다시 보내거나 해당 시스템에서 데이터를 수신해야 하는 요구 사항이 있을 수 있습니다. 이 문서에서는 다중 테넌트 솔루션에 대한 통합을 설계하고 개발하기 위한 주요 고려 사항 및 접근 방식을 간략하게 설명합니다.

참고

여러 통합 지점을 제공하는 경우 각 통합 지점을 독립적으로 고려하는 것이 가장 좋습니다. 서로 다른 통합 지점에는 요구 사항이 서로 다른 경우가 많으며 여러 가지 방법으로 동일한 시스템을 함께 연결하는 경우에도 다르게 디자인됩니다.

주요 고려 사항 및 요구 사항

데이터 흐름 방향

데이터가 흐르는 방향을 이해하는 것이 중요합니다. 데이터 흐름 방향은 ID 관리 방법 및 솔루션의 네트워킹 토폴로지와 같은 아키텍처의 여러 측면에 영향을 미칩니다. 두 가지 일반적인 데이터 흐름이 있습니다.

• 내보내기는 데이터가 다중 테넌트 시스템에서 개별 테넌트 시스템으로 흐르는 것을 의미합니다.
• 가져오기는 테넌트 시스템에서 다중 테넌트 시스템으로 데이터를 가져오는 것을 의미합니다.

논리 데이터 흐름 방향과 반드시 일치하지 않는 네트워킹 데이터 흐름 방향을 고려하는 것도 중요합니다. 예를 들어 테넌트의 시스템에서 데이터를 가져올 수 있도록 테넌트 아웃바운드 연결을 시작할 수 있습니다.

전체 또는 사용자 위임 액세스

많은 시스템에서 특정 데이터에 대한 액세스는 특정 사용자로 제한됩니다. 한 사용자가 액세스할 수 있는 데이터는 다른 사용자가 액세스할 수 있는 데이터와 동일하지 않을 수 있습니다. 전체 데이터 집합을 사용할 것인지 또는 가져오거나 내보낼 데이터 세트가 특정 사용자에게 액세스 권한이 있는 항목을 기반으로 하는지 여부를 고려하는 것이 중요합니다.

예를 들어 고객 소유 데이터 저장소를 기반으로 보고 및 비즈니스 인텔리전스를 제공하는 다중 테넌트 서비스인 Microsoft Power BI를 고려해 보세요. Power BI를 구성할 때 데이터베이스, API 및 기타 데이터 저장소에서 데이터를 가져오도록 데이터 원본 을 구성합니다. 다음과 같은 두 가지 방법으로 데이터 저장소를 구성할 수 있습니다.

• 기본 데이터 저장소에서 모든 데이터를 가져옵니다. 이러한 접근 방식을 사용하려면 전체 데이터 저장소에 액세스할 수 있는 ID에 대한 자격 증명이 Power BI에 제공되어야 합니다. 그런 다음 Power BI 관리자는 Power BI로 가져온 후 가져온 데이터에 대한 권한을 별도로 구성할 수 있습니다. Power BI는 권한을 적용합니다.
• 사용자의 권한에 따라 기본 데이터 저장소에서 데이터의 하위 집합을 가져옵니다. 사용자가 데이터 원본을 만들 때 자격 증명 및 관련 권한을 사용합니다. Power BI에서 가져오는 데이터의 정확한 하위 집합은 데이터 원본을 만든 사용자의 액세스 수준에 따라 달라집니다.

두 방법 모두 유효한 사용 사례가 있으므로 테넌트의 요구 사항을 명확하게 이해하는 것이 중요합니다.

전체 데이터 집합을 사용하는 경우 원본 시스템은 대상 시스템을 신뢰할 수 있는 하위 시스템으로 효과적으로 처리합니다. 이러한 유형의 통합에서는 사용자 ID 대신 워크로드 ID를 사용하는 것도 고려해야 합니다. 워크로드 ID는 단일 사용자에 해당하지 않는 시스템 ID입니다. 워크로드 ID에는 원본 시스템의 데이터에 대한 높은 수준의 권한이 부여됩니다.

또는 사용자 범위 데이터를 사용하는 경우 위임 과 같은 접근 방식을 사용하여 데이터 집합에서 올바른 데이터 하위 집합에 액세스해야 할 수 있습니다. 그런 다음 대상 시스템은 특정 사용자와 동일한 권한을 효과적으로 가져옵니다. 사용자 위임에 대한 자세한 내용은 아래의 위임된 사용자 액세스 접근 방식을 참조하세요. 위임을 사용하는 경우 사용자가 프로비전 해제되거나 권한이 변경되는 시나리오를 처리하는 방법을 고려합니다.

실시간 또는 일괄 처리

실시간 데이터로 작업할지 또는 데이터를 일괄 처리로 보낼지 여부를 고려합니다.

실시간 통합의 경우 다음과 같은 접근 방식이 일반적입니다.

• 요청/응답은 클라이언트가 서버에 대한 요청을 시작하고 응답을 수신하는 위치입니다. 일반적으로 요청/응답 통합은 API 또는 웹후크를 사용하여 구현됩니다. 요청은 승인 및 응답을 기다리는 동기 요청이 될 수 있습니다. 또는 비동기 요청-회신 패턴과 같은 항목을 사용하여 응답을 기다리는 비동기 요청이 될 수 있습니다.
• 느슨하게 결합된 통신은 시스템을 느슨하게 결합하도록 설계된 메시징 구성 요소를 통해 사용하도록 설정되는 경우가 많습니다. 예를 들어 Azure Service Bus는 메시지 큐 기능을 제공하고 Azure Event Grid 및 Event Hubs는 이벤트 기능을 제공합니다. 이러한 구성 요소는 통합 아키텍처의 일부로 사용되는 경우가 많습니다.

반면 일괄 처리 통합은 백그라운드 작업을 통해 관리되는 경우가 많으며, 하루 중 특정 시간에 트리거될 수 있습니다. 일반적으로 일괄 처리 통합은 교환된 데이터 집합이 클 수 있기 때문에 Blob Storage 컨테이너와 같은 스테이징 위치를 통해 수행됩니다.

데이터 볼륨

이 정보는 전체 시스템 용량을 계획하는 데 도움이 되므로 통합을 통해 교환하는 데이터의 양을 이해하는 것이 중요합니다. 시스템 용량을 계획할 때 서로 다른 테넌트는 서로 다른 양의 데이터를 교환할 수 있습니다.

실시간 통합의 경우 볼륨을 지정된 기간 동안의 트랜잭션 수로 측정할 수 있습니다. 일괄 처리 통합의 경우 볼륨을 교환된 레코드 수 또는 바이트 단위의 데이터 양으로 측정할 수 있습니다.

데이터 형식

두 당사자 간에 데이터를 교환하는 경우 둘 다 데이터의 형식을 지정하고 구성하는 방법을 명확하게 이해하는 것이 중요합니다. 데이터 형식의 다음 부분을 고려합니다.

• JSON, Parquet, CSV 또는 XML과 같은 파일 형식
• 포함할 필드 목록, 날짜 형식 및 필드의 null 허용 여부 등의 스키마

다중 테넌트 시스템을 사용하는 경우 가능하면 모든 테넌트에 대해 동일한 데이터 형식을 표준화하고 사용하는 것이 가장 좋습니다. 이를 통해 각 테넌트의 요구 사항에 맞게 통합 구성 요소를 사용자 지정하고 다시 테스트할 필요가 없습니다. 그러나 경우에 따라 다른 테넌트와 통신하기 위해 다른 데이터 형식을 사용해야 할 수 있으므로 여러 통합을 구현해야 할 수도 있습니다. 이러한 상황을 간소화하는 데 도움이 되는 방법은 구성 가능 통합 구성 요소 섹션을 참조하세요.

테넌트 시스템에 대한 액세스

일부 통합에서는 테넌트의 시스템 또는 데이터 저장소에 연결해야 합니다. 테넌트의 시스템에 연결할 때 연결의 네트워킹 및 ID 구성 요소를 신중하게 고려해야 합니다.

네트워크 액세스

다음 옵션을 포함할 수 있는 테넌트의 시스템에 액세스하기 위한 네트워크 토폴로지를 고려합니다.

• 인터넷을 통해 연결합니다. 인터넷을 통해 연결하는 경우 연결이 보호되고 데이터가 암호화되는 방법 테넌트가 IP 주소에 따라 제한하려는 경우 솔루션에서 사용하는 Azure 서비스가 아웃바운드 연결에 대한 고정 IP 주소를 지원할 수 있는지 확인합니다. 예를 들어 필요한 경우 NAT Gateway를 사용하여 고정 IP 주소를 제공하는 것이 좋습니다. VPN이 필요한 경우 테넌트에서 키를 안전하게 교환하는 방법을 고려합니다.
• 테넌트의 환경에 배포된 에이전트는 유연한 접근 방식을 제공할 수 있으며 테넌트가 인바운드 연결을 허용할 필요가 없도록 방지할 수 있습니다.
• Azure Relay와 같은 릴레이는 인바운드 연결을 방지하는 방법도 제공합니다.

자세한 내용은 다중 테넌트용 네트워킹 접근 방식에 대한 지침을 참조하세요.

인증

연결을 시작할 때 각 테넌트에서 인증하는 방법을 고려합니다. 다음 접근 방식을 고려합니다.

• API 키 또는 인증서와 같은 비밀 테넌트의 자격 증명을 안전하게 관리하는 방법을 계획하는 것이 중요합니다. 테넌트의 비밀이 누출되면 주요 보안 인시던트가 발생하여 많은 테넌트에 영향을 미칠 수 있습니다.
• 테넌트의 자체 Microsoft Entra 디렉터리에서 발급한 토큰을 사용하는 Microsoft Entra 토큰입니다. 토큰은 다중 테넌트 Microsoft Entra 애플리케이션 등록 또는 특정 서비스 주체를 사용하여 워크로드에 직접 발급될 수 있습니다. 또는 워크로드가 테넌트 디렉터리 내의 특정 사용자를 대신하여 리소스에 액세스하는 위임된 권한을 요청할 수 있습니다.

어떤 방법을 선택하든 테넌트가 최소 권한 원칙을 따르고 시스템에 불필요한 권한을 부여하지 않도록 합니다. 예를 들어 시스템에서 테넌트의 데이터 저장소에서만 데이터를 읽어야 하는 경우 시스템에서 사용하는 ID에 쓰기 권한이 없어야 합니다.

시스템에 대한 테넌트의 액세스

테넌트가 시스템에 연결해야 하는 경우 전용 API 또는 기타 통합 지점을 제공하는 것이 좋습니다. 그러면 솔루션의 노출 영역의 일부로 모델링할 수 있습니다.

경우에 따라 테넌트에게 Azure 리소스에 대한 직접 액세스를 제공하기로 결정할 수 있습니다. 파급 효과를 신중하게 고려하고 안전한 방식으로 테넌트 액세스 권한을 부여하는 방법을 이해해야 합니다. 예를 들어 다음 방법 중 하나를 사용할 수 있습니다.

• 공유 액세스 서명과 같은 보안 조치를 사용하여 특정 Azure 리소스에 대한 제한된 액세스 권한을 부여하는 발레 키 패턴을 사용합니다.
• 전용 스토리지 계정과 같은 통합 지점에 전용 리소스를 사용합니다. 통합 리소스를 핵심 시스템 리소스와 분리하는 것이 좋습니다. 이러한 접근 방식을 사용하면 보안 인시던트에서 폭발 반경을 최소화할 수 있습니다. 또한 테넌트가 실수로 리소스에 대한 많은 연결을 시작하고 용량을 소모하는 경우 시스템의 나머지 부분도 계속 실행됩니다.

규정 준수

테넌트의 데이터와 직접 상호 작용하거나 해당 데이터를 전송하기 시작하면 테넌트의 거버넌스 및 규정 준수 요구 사항을 명확하게 이해하는 것이 중요합니다.

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

API 노출

실시간 통합에는 일반적으로 사용할 테넌트 또는 다른 당사자에게 API를 노출하는 작업이 포함됩니다. API는 특히 외부 당사자가 사용하는 경우 특별한 고려 사항이 필요합니다. 다음 질문을 살펴보세요.

• API에 대한 액세스 권한이 부여되는 사용자
• API 사용자를 인증하는 방법
• API 사용자가 일정 기간 동안 수행할 수 있는 요청 수에 대한 제한 여부
• 각 API에 대한 API 및 설명서에 대한 정보 제공 방법 예: 개발자 포털 구현 여부

Azure API Management와 같은 API 게이트웨이를 사용하여 이러한 문제를 처리하는 것이 좋습니다. API 게이트웨이는 API가 따르는 정책을 구현할 수 있는 단일 위치를 제공하며 백 엔드 API 시스템의 구현을 간소화합니다. API Management에서 다중 테넌트 아키텍처를 지원하는 방법에 대한 자세한 내용은 다중 테넌트 솔루션에서 Azure API Management 사용을 참조하세요.

발레 키 패턴

경우에 따라 테넌트는 Azure Storage와 같은 데이터 원본에 직접 액세스해야 할 수 있습니다. 발레 키 패턴을 따라 데이터를 안전하게 공유하고 데이터 저장소에 대한 액세스를 제한하는 것이 좋습니다.

예를 들어 대용량 데이터 파일을 일괄 처리로 내보낼 때 이러한 접근 방식을 사용할 수 있습니다. 내보내기 파일을 생성한 후 Azure Storage의 Blob 컨테이너에 저장한 다음 시간 바인딩된 읽기 전용 공유 액세스 서명을 생성할 수 있습니다. 이러한 서명은 Blob URL과 함께 테넌트에게 제공될 수 있습니다. 그러면 테넌트는 서명이 만료될 때까지 Azure Storage에서 파일을 다운로드할 수 있습니다.

마찬가지로 특정 Blob에 작성할 수 있는 권한이 있는 공유 액세스 서명을 생성할 수 있습니다. 테넌트에게 공유 액세스 서명을 제공하는 경우 Blob에 해당 데이터를 작성할 수 있습니다. Azure Storage에 Event Grid 통합을 사용하면 애플리케이션에 데이터 파일을 처리하고 가져오도록 알림을 받을 수 있습니다.

Webhook

웹후크를 사용하면 테넌트가 제공하는 URL로 테넌트에게 이벤트를 보낼 수 있습니다. 전송할 정보가 있는 경우 테넌트의 웹후크에 대한 연결을 시작하고 HTTP 요청 페이로드에 데이터를 포함합니다.

고유한 웹후크 이벤트 시스템을 빌드하도록 선택하는 경우 CloudEvents 표준을 따라 테넌트의 통합 요구 사항을 간소화하는 것이 좋습니다.

또는 Azure Event Grid와 같은 서비스를 사용하여 웹후크 기능을 제공할 수 있습니다. Event Grid는 기본적으로 CloudEvents에서 작동하며 다중 테넌트 솔루션에 유용한 이벤트 도메인을 지원합니다.

참고

테넌트의 시스템에 아웃바운드 연결을 만들 때마다 외부 시스템에 연결한다는 것을 기억하세요. 테넌트 시스템의 문제가 시스템에 전파되지 않도록 재시도 패턴, 회로 차단기 패턴 및 격벽 패턴 사용 등의 권장 클라우드 사례를 따릅니다.

위임된 사용자 액세스

테넌트의 데이터 저장소에서 데이터에 액세스할 때 특정 사용자의 ID를 사용하여 데이터에 액세스해야 하는지 여부를 고려합니다. 그러면 통합에 사용자가 가지고 있는 권한과 동일한 권한이 적용됩니다. 이러한 접근 방식을 위임된 액세스라고도 합니다.

예를 들어 다중 테넌트 서비스가 테넌트의 데이터에 대해 기계 학습 모델을 실행한다고 가정합니다. Azure Synapse Analytics, Azure Storage, Azure Cosmos DB 등 각 테넌트의 서비스 인스턴스에 액세스해야 합니다. 각 테넌트에는 고유한 Microsoft Entra 디렉터리가 있습니다. 특정 사용자가 액세스할 수 있는 데이터를 검색할 수 있도록 솔루션에 데이터 저장소에 대한 위임된 액세스 권한을 부여할 수 있습니다.

데이터 저장소에서 Microsoft Entra 인증을 지원하는 경우 위임된 액세스가 더 쉽습니다. 많은 Azure 서비스는 Microsoft Entra ID를 지원합니다.

예를 들어 다중 테넌트 웹 애플리케이션 및 백그라운드 프로세스가 Microsoft Entra ID에서 테넌트의 사용자 ID를 사용하여 Azure Storage에 액세스해야 한다고 가정합니다. 다음 단계를 수행할 수 있습니다.

1. 솔루션을 나타내는 다중 테넌트 Microsoft Entra 애플리케이션 등록 을 만듭니다.
2. 로그인한 사용자로 Azure Storage에 액세스할 수 있는 위임된 권한을 애플리케이션에 부여합니다.
3. Microsoft Entra ID를 사용하여 사용자를 인증하도록 애플리케이션을 구성합니다.

사용자가 로그인한 후 Microsoft Entra ID는 사용자를 대신하여 Azure Storage에 액세스하는 데 사용할 수 있는 수명이 짧은 액세스 토큰을 애플리케이션에 발급하고 수명이 긴 새로 고침 토큰을 발급합니다. 백그라운드 프로세스가 새로운 액세스 토큰을 얻을 수 있고 사용자를 대신하여 Azure Storage에 계속 액세스할 수 있도록 시스템에서 새로 고침 토큰을 안전하게 저장해야 합니다.

메시징

메시징을 사용하면 시스템 또는 구성 요소 간의 비동기적이고 느슨하게 결합된 통신을 수행할 수 있습니다. 메시징은 일반적으로 통합 시나리오에서 원본 및 대상 시스템을 분리하는 데 사용됩니다. 메시징 및 다중 테넌트에 대한 자세한 내용은 다중 테넌트 솔루션의 메시징에 대한 아키텍처 접근 방식을 참조하세요.

테넌트 시스템과의 통합의 일부로 메시징을 사용하는 경우 Azure Service Bus의 공유 액세스 서명 또는 Azure Event Hubs의 공유 액세스 서명을 사용해야 하는지 여부를 고려합니다. 공유 액세스 서명을 사용하면 메시징 하위 시스템의 나머지 부분에 액세스하지 않고도 메시징 리소스에 대한 제한된 액세스 권한을 제3자에게 부여할 수 있습니다.

일부 시나리오에서는 서로 다른 테넌트에게 서로 다른 SLA(서비스 수준 약정) 또는 QoS(서비스 품질) 보증을 제공할 수 있습니다. 예를 들어 테넌트 하위 집합은 데이터 내보내기 요청이 다른 테넌트보다 더 빠르게 처리될 것으로 예상할 수 있습니다. 우선 순위 큐 패턴을 사용하면 서로 다른 수준의 우선순위에 대해 별도의 큐를 만들 수 있으며, 그에 따라 우선순위를 지정하는 작업자 인스턴스가 다릅니다.

구성 가능한 통합 구성 요소

경우에 따라 서로 다른 데이터 형식 또는 다양한 유형의 네트워크 연결을 사용하는 여러 테넌트와 통합해야 할 수 있습니다.

통합의 일반적인 접근 방식은 다음 유형의 작업을 수행하는 개별 단계를 빌드하고 테스트하는 것입니다.

• 데이터 저장소에서 데이터를 검색합니다.
• 데이터를 특정 형식 또는 스키마로 변환합니다.
• 특정 네트워크 전송을 사용하거나 알려진 대상 형식으로 데이터를 전송합니다.

일반적으로 Azure Functions 및 Azure Logic Apps와 같은 서비스를 사용하여 이러한 개별 요소를 빌드합니다. 그런 다음 Logic Apps 또는 Azure Data Factory와 같은 도구를 사용하여 전체 통합 프로세스를 정의하고 미리 정의된 각 단계를 호출합니다.

복잡한 다중 테넌트 통합 시나리오를 사용하는 경우 재사용 가능한 통합 단계의 라이브러리를 정의하는 것이 도움이 될 수 있습니다. 그런 다음 해당 테넌트의 요구 사항에 따라 각 테넌트의 워크플로를 빌드하여 적용 가능한 부분을 함께 작성할 수 있습니다. 또는 일부 데이터 세트 또는 통합 구성 요소를 테넌트에게 직접 노출하여 자체 통합 워크플로를 빌드할 수 있습니다.

마찬가지로 다른 데이터 형식 또는 다른 전송을 사용하는 테넌트에서 다른 사용자로 데이터를 가져와야 할 수도 있습니다. 이 시나리오의 좋은 방법은 테넌트별 커넥터를 빌드 하는 것입니다. 커넥터는 데이터를 표준화된 형식 및 위치로 정규화하고 가져온 후 기본 공유 가져오기 프로세스를 트리거하는 워크플로입니다.

테넌트별 논리 또는 코드를 빌드해야 하는 경우 손상 방지 계층 패턴을 따르는 것이 좋습니다. 이 패턴은 테넌트별 구성 요소를 캡슐화하는 동시에 나머지 솔루션은 추가된 복잡성을 인식하지 못하게 하는 데 도움이 됩니다.

계층화된 가격 책정 모델을 사용하는 경우 낮은 가격 책정 계층의 테넌트가 제한된 데이터 형식 및 전송 집합으로 표준 접근 방식을 따르도록 요구할 수 있습니다. 가격 책정 계층이 높을수록 제공하는 통합 구성 요소에서 더 많은 사용자 지정 또는 유연성을 제공할 수 있습니다.

피해야 할 안티패턴

• 기본 데이터 저장소를 테넌트에게 직접 노출 테넌트가 기본 데이터 저장소에 액세스하는 경우 해당 데이터 저장소의 보안을하기가 더 어려워질 수 있으며 실수로 솔루션에 영향을 주는 성능 문제가 발생할 수 있습니다. 데이터 저장소에 자격 증명을 고객에게 제공하지 말고 주 데이터베이스의 데이터를 동일한 데이터베이스 시스템의 고객의 읽기 복제본으로 직접 복제하지 마세요. 대신 전용 통합 데이터 저장소를 만들고 발레 키 패턴을 사용하여 데이터를 노출합니다.
• API 게이트웨이 없이 API를 노출합니다. API에는 액세스 제어, 청구 및 측광에 대한 특정 문제가 있습니다. 초기에 API 정책을 사용할 계획이 없더라도 API 게이트웨이를 초기에 포함하는 것이 좋습니다. 그러면 나중에 API 정책을 사용자 지정해야 하는 경우 타사에서 사용하는 URL과의 호환성이 손상되는 변경을 수행할 필요가 없습니다.
• 불필요하게 긴밀한 결합. 메시징 접근 방식을 사용하는 것과 같은 느슨한 결합은 보안, 성능 격리 및 복원력에 대한 다양한 이점을 제공할 수 있습니다. 가능하면 타사와의 통합을 느슨하게 결합하는 것이 좋습니다. 타사에 긴밀하게 연결해야 하는 경우 재시도 패턴, 회로 차단기 패턴 및 격벽 패턴과 같은 모범 사례를 따르는지 확인합니다.
• 특정 테넌트용 사용자 지정 통합. 테넌트별 기능 또는 코드는 솔루션을 테스트하기 어렵게 만들 수 있습니다. 또한 더 많은 코드 경로를 이해해야 하므로 나중에 솔루션을 수정하기가 더 어려워집니다. 대신 특정 테넌트 요구 사항을 추상화하고 유사한 요구 사항으로 여러 테넌트에서 다시 사용하는 구성 가능한 구성 요소를 빌드해 봅니다.

참가자

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

주요 작성자:

• John Downs | 주요 소프트웨어 엔지니어
• Arsen Vladimirskiy | 수석 고객 엔지니어, FastTrack for Azure

기타 기여자:

• Will Velida | FastTrack for Azure 고객 엔지니어 2

비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.

다음 단계

다중 테넌트 솔루션의 메시징을 위한 아키텍처 접근 방식을 참고하세요.