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

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

주요 고려 사항 및 요구 사항

데이터 흐름 방향

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

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

• 가져오기- 즉, 테넌트 시스템에서 다중 테넌트 시스템으로 데이터를 가져옵니다.

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

모든 액세스 또는 사용자 위임 액세스

많은 시스템에서 특정 데이터에 대한 액세스는 개별 사용자로 제한됩니다. 한 사용자가 액세스하는 데이터는 다른 사용자가 액세스하는 데이터와 다를 수 있습니다. 전체 데이터 집합을 사용할지 또는 가져오거나 내보내는 데이터가 각 사용자의 액세스 권한에 따라 달라지는지 고려해야 합니다.

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

• 기본 데이터 저장소에서 모든 데이터를 가져옵니다. 이 방법을 사용하려면 Power BI가 전체 데이터 저장소에 대한 권한이 있는 ID에 대한 자격 증명을 받아야 합니다. 데이터를 가져온 후 Power BI 관리자는 권한을 독립적으로 구성합니다. Power BI는 이러한 권한을 적용합니다.

• 사용자의 권한에 따라 기본 데이터 저장소에서 데이터의 하위 집합을 가져옵니다. 사용자가 데이터 원본을 만들 때 자격 증명 및 관련 권한을 사용합니다. Power BI에서 가져오는 데이터의 정확한 하위 집합은 데이터 원본을 만드는 사용자의 액세스 수준에 따라 달라집니다.

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

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

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

실시간 통합 또는 일괄 처리 통합

실시간 데이터를 사용할 것인지 아니면 일괄 처리로 데이터를 보낼 것인지를 고려합니다.

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

• 요청-응답 은 클라이언트가 서버에 대한 요청을 시작하고 응답을 수신하는 위치입니다. 일반적으로 요청-응답 통합은 API 또는 웹후크를 사용하여 구현됩니다. 요청은 승인 및 응답을 기다리는 동기식 요청일 수 있습니다. 또는 요청이 비동기 이고 비동기 Request-Reply 패턴 과 같은 항목을 사용하여 응답을 기다릴 수 있습니다.

• 느슨하게 결합된 통신은 시스템을 느슨하게 결합하도록 설계된 메시징 구성 요소를 통해 사용하도록 설정되는 경우가 많습니다. 예를 들어 Azure Service Bus는 메시지 큐 기능을 제공하고 Azure Event Grid 및 Azure Event Hubs는 이벤트 기능을 제공합니다. 이러한 구성 요소는 통합 아키텍처의 일부로 사용되는 경우가 많습니다.

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

데이터 볼륨

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

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

데이터 형식

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

• JSON, Parquet, CSV 또는 XML과 같은 파일 형식

• 포함된 필드 목록, 날짜 형식 및 필드의 Null 허용 여부와 같은 스키마

다중 테넌트 시스템에서 작업할 때 가능하면 모든 테넌트에 대해 동일한 데이터 형식을 표준화하고 사용합니다. 이 방법을 사용하면 각 테넌트의 요구 사항에 맞게 통합 구성 요소를 사용자 지정하고 다시 테스트하지 않아도 됩니다. 그러나 일부 시나리오에서는 서로 다른 테넌트와 통신하기 위해 다른 데이터 형식이 필요하므로 여러 통합을 구현해야 할 수도 있습니다. 이러한 유형의 시나리오를 간소화하는 데 도움이 되는 방법은 Composable 통합 구성 요소를 참조하세요.

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

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

네트워크 액세스

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

• 인터넷 연결은 연결 보안 및 데이터 암호화에 대한 우려를 제기할 수 있습니다. 인터넷을 통해 연결할 때 연결을 보호하고 데이터를 암호화하는 방법을 결정합니다. 테넌트가 IP 주소에 따라 액세스를 제한하려는 경우 솔루션에서 사용하는 Azure 서비스가 아웃바운드 연결에 대한 고정 IP 주소를 지원할 수 있는지 확인합니다. 예를 들어 필요한 경우 Azure NAT Gateway 를 사용하여 고정 IP 주소를 제공하는 것이 좋습니다. VPN이 필요한 경우 테넌트에서 키를 안전하게 교환하는 방법을 고려합니다.

• 테넌트의 환경에 배포되는 에이전트는 유연한 접근 방식을 제공할 수 있습니다. 에이전트를 사용하면 테넌트가 인바운드 연결을 허용할 필요가 없도록 할 수도 있습니다.

• 릴레이, 예를 들어 Azure Relay은 인바운드 연결을 피하는 방법도 제공합니다.

자세한 내용은 다중 테넌시에 대한 네트워킹 방법을 참조하세요.

인증

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

• 비밀 정보, 예를 들어 API 키 또는 인증서. 테넌트의 자격 증명을 안전하게 관리하는 방법을 계획하는 것이 중요합니다. 테넌트의 비밀이 누출되면 주요 보안 인시던트가 발생할 수 있으며 이로 인해 많은 테넌트에 영향을 줄 수 있습니다.

• Microsoft Entra 토큰은 테넌트의 Microsoft Entra 디렉터리가 발급하는 토큰을 사용하는 경우입니다. 토큰은 다중 테넌트 Microsoft Entra 애플리케이션 등록 또는 특정 서비스 주체를 사용하여 워크로드에 직접 발급될 수 있습니다. 또는 워크로드가 테넌트 디렉터리 내의 특정 사용자를 대신하여 리소스에 액세스하는 위임된 권한을 요청할 수 있습니다.

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

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

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

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

• SAS(공유 액세스 서명) 토큰과 같은 보안 조치를 사용하여 특정 Azure 리소스에 대한 제한된 액세스 권한을 부여하는 Valet 키 패턴을 사용합니다.

• 전용 스토리지 계정과 같은 통합 지점에 전용 리소스를 사용합니다. 통합 리소스를 핵심 시스템 리소스와 분리하는 것이 좋습니다. 이 방법을 사용하면 보안 인시던트 에서 폭발 반경 을 최소화할 수 있습니다. 또한 테넌트가 실수로 리소스에 대한 많은 수의 연결을 시작하고 용량을 소모하는 경우 시스템의 나머지 부분도 계속 실행됩니다.

규정 준수

테넌트의 데이터를 직접 조작하거나 전송하는 경우 테넌트의 거버넌스 및 규정 준수 요구 사항을 명확하게 이해하는 것이 중요합니다.

접근 방식 및 패턴

API 공개

실시간 통합에는 종종 테넌트 또는 다른 당사자가 사용할 API를 노출하는 작업이 포함됩니다. API에는 특히 외부 당사자가 사용하는 경우 특별한 고려 사항이 필요합니다. 다음 사항을 고려합니다.

• API에 액세스할 수 있는 사용자를 정의합니다.

• 안전하고 신뢰할 수 있는 방법을 사용하여 API의 사용자를 인증합니다.

• 각 API 사용자가 특정 기간 동안 수행할 수 있는 요청 수에 제한을 설정합니다.

• 각 API에 대한 명확한 정보 및 설명서를 제공합니다. 적절한 경우 개발자 포털을 구현하여 검색 및 온보딩을 지원합니다.

API 게이트웨이, 예를 들어 Azure API Management과 같은 것을 사용하여 이러한 문제 및 다른 여러 문제를 처리하는 것이 좋은 방법입니다. API 게이트웨이는 API가 따르는 정책을 구현할 수 있는 단일 위치를 제공합니다. 또한 백 엔드 API 시스템의 구현을 간소화합니다. 자세한 내용은 다중 테넌트 솔루션에서 API Management 사용을 참조하세요.

주차 대행 키 패턴

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

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

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

웹훅들

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

자신만의 웹후크 이벤트 시스템을 구축하기로 선택한 경우, 테넌트의 통합 요구 사항을 간소화하기 위해 CloudEvents 표준을 따르는 것을 고려하십시오.

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

위임된 사용자 액세스

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

예를 들어 다중 테넌트 서비스가 테넌트의 데이터에 대해 기계 학습 모델을 실행한다고 가정합니다. 분석용 Microsoft Fabric 작업 영역 , 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에 계속 액세스할 수 있도록 시스템에서 새로 고침 토큰을 안전하게 저장해야 합니다.

메시징

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

테넌트 시스템과의 통합의 일부로 메시징을 사용하는 경우 Service Bus 또는 Event Hubs에 SAS 토큰을 사용해야 하는지 여부를 고려 합니다. SAS 토큰은 나머지 메시징 하위 시스템에 액세스할 수 없도록 설정하지 않고도 외부 사용자 또는 시스템에 메시징 리소스에 대한 제한된 액세스 권한을 부여합니다.

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

구성 가능한 통합 구성 요소

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

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

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

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

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

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

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

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

피해야 할 안티패턴

• 기본 데이터 저장소를 테넌트에게 직접 노출 테넌트가 기본 데이터 저장소에 액세스하는 경우 해당 저장소를 보호하기가 더 어려워질 수 있습니다. 실수로 솔루션에 영향을 주는 성능 문제가 발생할 수도 있습니다. 고객에게 데이터 저장소에 자격 증명을 제공하지 않습니다. 기본 데이터베이스의 원시 데이터를 동일한 데이터베이스 시스템의 고객의 읽기 복제본으로 직접 복제하지 마세요. 대신 전용 통합 데이터 저장소를 만듭니다. 발렛 키 패턴을 사용하여 데이터를 공개합니다.

• API 게이트웨이 없이 API를 노출합니다. API에는 액세스 제어, 청구 및 측광에 대한 특정 문제가 있습니다. 초기에 API 정책을 사용할 계획이 없더라도 API 게이트웨이를 초기에 포함하는 것이 좋습니다. 이렇게 하면 나중에 API 정책을 사용자 지정해야 하는 경우 외부 클라이언트가 의존하는 URL을 호환성이 손상되는 변경을 수행할 필요가 없습니다.

• 불필요하게 긴밀한 결합. 메시징 방식을 사용하는 등 느슨한 결합은 보안, 성능 격리, 그리고 탄력성에 대해 다양한 이점을 제공할 수 있습니다. 가능하면 외부 시스템과 통합을 느슨하게 결합해야 합니다. 외부 시스템에 긴밀하게 연결해야 하는 경우 재시도 패턴, 회로 차단기 패턴 및 격벽 패턴과 같은 모범 사례를 따라야 합니다.

• 특정 테넌트용 사용자 지정 통합. 테넌트별 기능 또는 코드는 솔루션을 테스트하기 어렵게 만들 수 있습니다. 또한 더 많은 코드 경로를 이해해야 하므로 나중에 솔루션을 수정하기가 더 어려워집니다. 대신 특정 테넌트에 대한 요구 사항을 추상화하고 비슷한 요구 사항이 있는 여러 테넌트에서 다시 사용하는 구성 가능한 구성 요소를 빌드해 봅니다.

기여자

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

주요 작성자:

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

기타 기여자:

• Will Velida | FastTrack for Azure 고객 엔지니어 2
• 필리페 모레이라 | 클라우드 솔루션 설계자

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

관련 리소스

• 다중 테넌트 솔루션의 메시징을 위한 아키텍처 접근 방식