다음을 통해 공유

다중 테넌트 솔루션의 네트워킹을 위한 아키텍처 접근 방식

  • 아티클

Azure에 배포된 모든 솔루션에는 일종의 네트워킹이 필요합니다. 솔루션 디자인 및 워크로드에 따라 Azure의 네트워킹 서비스와 상호 작용하는 방법이 다를 수 있습니다. 이 문서에서는 Azure에서 다중 테넌트 솔루션의 네트워킹 측면에 대한 고려 사항 및 지침을 제공합니다. 상위 수준 및 애플리케이션 계층 접근 방식을 통한 가상 네트워크와 같은 하위 수준 네트워킹 구성 요소에 대한 정보를 포함합니다.

참고

Azure 자체는 다중 테넌트 환경이며 Azure의 네트워크 구성 요소는 다중 테넌트를 위해 설계되었습니다. 자체 솔루션을 설계하기 위해 세부 정보를 이해할 필요는 없지만 Azure가 가상 네트워크 트래픽을 다른 고객의 트래픽으로부터 격리하는 방법에 대한 자세한 정보를 볼 수 있습니다.

주요 고려 사항 및 요구 사항

인프라 및 플랫폼 서비스

사용하는 서비스 범주에 따라 네트워킹 구성 요소에 대한 관심사가 다를 수 있습니다.

인프라 서비스

가상 머신 또는 Azure Kubernetes Service 같은 인프라 서비스를 사용할 때마다 서비스 연결의 기반이 되는 가상 네트워크 또는 VNet을 고려하고 설계해야 합니다. 또한 디자인에 통합해야 하는 다른 보안 및 격리 계층도 고려해야 합니다. 네트워크 계층 컨트롤에만 의존하지 마십시오.

플랫폼 서비스

App Service, Azure Cosmos DB 또는 Azure SQL Database와 같은 Azure의 플랫폼 서비스를 사용하는 경우 사용하는 특정 아키텍처에 따라 필요한 네트워킹 서비스가 결정됩니다.

인터넷에서 플랫폼 서비스를 격리해야 하는 경우 VNet을 사용해야 합니다. 사용하는 특정 서비스에 따라 Application Gateway 같은 프라이빗 엔드포인트 또는 VNet 통합 리소스로 작업할 수 있습니다. 그러나 공용 IP 주소를 통해 플랫폼 서비스를 사용할 수 있도록 하고 방화벽 및 ID 제어와 같은 서비스 자체 보호 기능을 사용하도록 선택할 수도 있습니다. 이러한 상황에서는 VNet이 필요하지 않을 수 있습니다.

플랫폼 서비스에 VNet을 사용할지 여부는 다음과 같은 여러 요구 사항에 따라 달라집니다.

  • 규정 준수 요구 사항: 특정 규정 준수 표준을 충족해야 할 수 있습니다. Azure 환경을 특정 방식으로 구성하도록 요구하는 표준도 있습니다.
  • 테넌트의 요구 사항: 자체 조직에 네트워크 계층 격리 또는 제어에 대한 특정 요구 사항이 없더라도 테넌트에는 있을 수 있습니다. 테넌트가 솔루션에 액세스하는 방법과 네트워크 디자인에 대한 가정이 있는지 여부를 명확하게 이해해야 합니다.
  • 복잡성: 가상 네트워크를 이해하고 작업하는 것이 더 복잡할 수 있습니다. 팀이 관련된 원칙을 명확하게 이해하도록 하세요. 그렇지 않으면 안전하지 않은 환경을 배포할 가능성이 있습니다.

프라이빗 네트워킹 사용의 의미를 이해해야 합니다.

서브넷 크기 조정

VNet을 배포해야 하는 경우 전체 VNet과 VNet 내의 서브넷의 크기 조정 및 주소 공간을 신중하게 고려해야 합니다.

Azure 리소스를 VNet에 배포하는 방법과 각 리소스에서 사용하는 IP 주소 수를 명확하게 이해해야 합니다. 테넌트별 컴퓨팅 노드, 데이터베이스 서버 또는 기타 리소스를 배포하는 경우 예상되는 테넌트 증가 및 리소스의 수평 자동 크기 조정에 맞게 충분히 큰 서브넷을 만들어야 합니다.

마찬가지로 관리되는 서비스를 사용할 때는 IP 주소가 사용되는 방식을 이해하는 것이 중요합니다. 예를 들어 Azure CNI(Container Networking Interface)와 함께 Azure Kubernetes Service를 사용하는 경우 서브넷에서 사용되는 IP 주소 수는 노드 수, 수평 크기 조정 방법 및 사용하는 서비스 배포 프로세스와 같은 요인을 기반으로 합니다. VNet과 Azure App Service 및 Azure Functions 통합을 사용하는 경우 사용되는 IP 주소 수는 계획 인스턴스 수에 따라 달라집니다.

서브넷을 계획할 때 서브넷 구분 지침을 검토합니다.

퍼블릭 또는 프라이빗 액세스

테넌트가 인터넷을 통해 서비스에 액세스하도록 할지, 개인 IP 주소를 통해 서비스에 액세스하도록 할지 고려합니다.

인터넷 기반(퍼블릭) 액세스의 경우 방화벽 규칙, IP 주소 허용 목록 및 거부 목록, 공유 비밀 및 키, ID 기반 컨트롤을 사용하여 서비스를 보호할 수 있습니다.

개인 IP 주소를 사용하여 서비스에 대한 연결을 사용하도록 설정해야 하는 경우 Azure Private Link 서비스 또는 테넌트 간 가상 네트워크 피어링을 사용하는 것이 좋습니다. 일부 제한된 시나리오의 경우 Azure ExpressRoute 또는 Azure VPN Gateway를 사용하여 솔루션에 대한 프라이빗 액세스를 사용하도록 설정하는 것도 고려할 수 있습니다. 일반적으로 이 방법은 테넌트가 적고 각 테넌트에 전용 VNet을 배포할 때만 의미가 있습니다.

테넌트의 엔드포인트에 대한 액세스

Azure 내부 또는 외부에서 테넌트 네트워크 내의 엔드포인트에 데이터를 보내야 하는지 여부를 고려합니다. 예를 들어 고객이 제공한 웹후크를 호출해야 하는지 아니면 테넌트에 실시간 메시지를 보내야 하는지 고려하세요.

테넌트의 엔드포인트에 데이터를 보내야 하는 경우 다음과 같은 일반적인 방법을 고려합니다.

  • 솔루션에서 테넌트의 엔드포인트로의 인터넷 연결을 시작합니다. 연결이 고정 IP 주소에서 시작되어야 하는지 여부를 고려합니다. 사용하는 Azure 서비스에 따라 NAT Gateway, 방화벽 또는 부하 분산 장치를 배포해야 할 수 있습니다.
  • 에이전트를 배포하여 위치와 관계없이 Azure 호스트 서비스와 고객의 네트워크 간에 연결을 사용하도록 설정합니다.
  • 단방향 메시징의 경우 이벤트 도메인과 함께 Azure Event Grid와 같은 서비스를 사용하는 것이 좋습니다.

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

이 섹션에서는 다중 테넌트 솔루션에서 고려할 수 있는 몇 가지 주요 네트워킹 방법을 설명합니다. 먼저 핵심 네트워킹 구성 요소에 대한 하위 수준 접근 방식을 설명한 다음, HTTP 및 기타 애플리케이션 계층 문제에 대해 고려할 수 있는 접근 방식을 설명합니다.

서비스 공급자가 선택한 IP 주소를 사용하는 테넌트별 VNet

경우에 따라 테넌트를 대신하여 Azure에서 전용 VNet 연결 리소스를 실행해야 합니다. 예를 들어 각 테넌트에 대해 가상 머신을 실행하거나 프라이빗 엔드포인트를 사용하여 테넌트별 데이터베이스에 액세스해야 할 수 있습니다.

제어하는 IP 주소 공간을 사용하여 각 테넌트에 대해 VNet을 배포하는 것이 좋습니다. 이 방법을 사용하면 허브 및 스포크 토폴로지를 설정하여 트래픽 수신 및 송신을 중앙에서 제어해야 하는 경우 등에 VNet을 사용자 고유의 용도로 함께 피어링할 수 있습니다.

그러나 테넌트가 VNet 피어링 등을 사용하여 생성된 VNet에 직접 연결해야 하는 경우 서비스 공급자가 선택한 IP 주소는 적절하지 않습니다. 사용자가 선택한 주소 공간이 자체 주소 공간과 호환되지 않을 수 있습니다.

테넌트가 선택한 IP 주소를 사용하는 테넌트별 VNet

사용자가 테넌트 대신 관리하는 VNet과 자체 VNet을 테넌트가 피어링해야 하는 경우 테넌트가 선택한 IP 주소 공간을 사용하여 테넌트별 VNet을 배포하는 것이 좋습니다. 이 시스템을 사용하면 각 테넌트가 시스템 VNet의 IP 주소 범위가 자체 VNet과 겹치지 않도록 할 수 있습니다. 겹치지 않는 IP 주소 범위를 사용하여 네트워크가 피어링과 호환되도록 할 수 있습니다.

그러나 이 방법을 사용하면 서로 다른 테넌트의 VNet 간에 IP 주소 범위가 겹칠 가능성이 있으므로 테넌트의 VNet을 함께 피어링하거나 허브 및 스포크 토폴로지를 채택할 가능성이 낮아집니다.

허브 및 스포크 토폴로지

허브 및 스포크 VNet 토폴로지를 사용하면 여러 스포크 VNet과 중앙 집중식 허브 VNet을 피어링할 수 있습니다. VNet의 트래픽 수신 및 송신을 중앙에서 제어하고 각 스포크 VNet에서 리소스의 상호 통신 가능 여부를 제어할 수 있습니다. 각 스포크 VNet은 Azure Firewall 같은 공유 구성 요소에도 액세스할 수 있으며 Azure DDoS Protection과 같은 서비스를 사용할 수 있습니다.

허브 및 스포크 토폴로지를 사용하는 경우 피어링된 최대 VNet 수와 같은 제한을 계획하고 각 테넌트의 VNet에 겹치는 주소 공간을 사용하지 않도록 합니다.

허브 및 스포크 토폴로지는 선택한 IP 주소를 사용하여 테넌트별 VNet을 배포할 때 유용할 수 있습니다. 각 테넌트의 VNet은 스포크가 되며 허브 VNet에서 공통 리소스를 공유할 수 있습니다. 크기 조정을 위해 여러 VNet에서 공유 리소스의 크기를 조정하거나 배포 스탬프 패턴을 사용하는 경우 허브 및 스포크 토폴로지도 사용할 수 있습니다.

팁

솔루션이 여러 지리적 지역에서 실행되는 경우 일반적으로 각 지역에 별도의 허브 및 허브 리소스를 배포하는 것이 좋습니다. 이 방법을 사용하면 리소스 비용이 더 많이 발생하지만 여러 Azure 지역을 불필요하게 통과하여 요청 대기 시간을 늘리고 글로벌 피어링 요금을 유발할 수 있는 트래픽이 방지됩니다.

고정 IP 주소

테넌트가 인바운드 트래픽, 아웃바운드 트래픽 또는 둘 다에 정적 공용 IP 주소를 사용하는 데 서비스가 필요한지 여부를 고려하세요. 서로 다른 Azure 서비스는 다양한 방법으로 고정 IP 주소를 사용하도록 설정합니다.

가상 머신 및 기타 인프라 구성 요소를 사용하는 경우 인바운드 및 아웃바운드 고정 IP 주소 지정에 부하 분산 장치 또는 방화벽을 사용하는 것이 좋습니다. NAT Gateway를 사용하여 아웃바운드 트래픽의 IP 주소를 제어하는 것이 좋습니다. 다중 테넌트 솔루션에서 NAT 게이트웨이를 사용하는 방법에 대한 자세한 내용은 다중 테넌트에 대한 Azure NAT Gateway 고려 사항을 참조 하세요.

플랫폼 서비스를 사용할 때 사용하는 특정 서비스에 따라 IP 주소를 제어할 수 있는지 여부와 방법이 결정됩니다. 가상 머신과 같은 리소스를 VNet에 배포한 다음 NAT 게이트웨이 또는 방화벽을 사용하는 등 특정 방식으로 리소스를 구성해야 할 수 있습니다. 또는 서비스에서 아웃바운드 트래픽에 사용하는 현재 IP 주소 세트를 요청할 수 있습니다. 예를 들어 App Service는 애플리케이션의 현재 아웃바운드 IP 주소를 가져오는 API 및 웹 인터페이스를 제공합니다.

에이전트

테넌트가 솔루션에서 시작한 메시지를 수신하도록 설정해야 하거나 테넌트의 자체 네트워크에 있는 데이터에 액세스해야 하는 경우, 네트워크 내에서 배포할 수 있는 에이전트(온-프레미스 게이트웨이라고도 함)를 제공하는 것이 좋습니다. 이 방법은 테넌트의 네트워크가 Azure, 다른 클라우드 공급자 또는 온-프레미스에 있는지 여부에 관계없이 작동할 수 있습니다.

에이전트는 사용자가 지정하고 제어하는 엔드포인트에 대한 아웃바운드 연결을 시작하고 장기 실행 연결을 활성 상태로 유지하거나 간헐적으로 폴링합니다. Azure Relay를 사용하여 에이전트에서 서비스로의 연결을 설정하고 관리하는 것이 좋습니다. 에이전트는 연결이 설정되면 서비스가 올바른 테넌트에 연결을 매핑할 수 있도록 테넌트 식별자에 대한 일부 정보를 인증하고 포함합니다.

에이전트는 일반적으로 테넌트에 대한 보안 구성을 간소화합니다. 특히 온-프레미스 환경에서 인바운드 포트를 여는 것은 복잡하고 위험할 수 있습니다. 에이전트는 테넌트가 이러한 위험을 감수할 필요가 없도록 합니다.

테넌트의 네트워크에 연결할 에이전트를 제공하는 Microsoft 서비스의 예는 다음과 같습니다.

Azure Private Link 서비스는 테넌트의 Azure 환경에서 솔루션으로 프라이빗 연결을 제공합니다. 테넌트는 자체 VNet에서 Private Link 서비스를 사용하여 온-프레미스 환경에서 서비스에 액세스할 수도 있습니다. Azure는 개인 IP 주소를 사용하여 트래픽을 서비스로 안전하게 라우팅합니다.

Private Link 및 다중 테넌트 지원에 대한 자세한 내용은 다중 테넌트 지원 및 Azure Private Link를 참조하세요.

도메인 이름, 하위 도메인 및 TLS

다중 테넌트 솔루션에서 도메인 이름 및 TLS(전송 계층 보안)를 사용하는 경우 여러 가지 고려 사항이 있습니다. 다중 테넌트 및 도메인 이름에 대한 고려 사항을 검토합니다.

게이트웨이 라우팅 및 게이트웨이 오프로드 패턴

게이트웨이 라우팅 패턴 및 게이트웨이 오프로드 패턴에는 계층 7 역방향 프록시 또는 게이트웨이 배포가 포함됩니다. 게이트웨이는 다음 기능을 포함하여 다중 테넌트 애플리케이션에 대한 핵심 서비스를 제공하는 데 유용합니다.

  • 테넌트별 백 엔드 또는 배포 스탬프로 요청 라우팅.
  • 테넌트별 도메인 이름 및 TLS 인증서 처리.
  • WAF(웹 애플리케이션 방화벽)를 사용하여 요청에 보안 위협이 있는지 검사.
  • 응답을 캐싱하여 성능 개선.

Azure는 Azure Front Door, Azure Application Gateway 및 Azure API Management를 포함하여 이러한 목표의 일부 또는 전부를 달성하는 데 사용할 수 있는 여러 서비스를 제공합니다. NGINX 또는 HAProxy와 같은 소프트웨어를 사용하여 자체 사용자 지정 솔루션을 배포할 수도 있습니다.

솔루션의 게이트웨이를 배포하려는 경우 먼저 필요한 모든 기능을 포함하는 완전한 프로토타입을 빌드하고 애플리케이션 구성 요소가 예상대로 계속 작동하는지 확인하는 것이 좋습니다. 또한 트래픽 및 테넌트 증가를 지원하기 위해 게이트웨이 구성 요소의 크기를 조정하는 방법도 이해해야 합니다.

정적 콘텐츠 호스팅 패턴

정적 콘텐츠 호스팅 패턴에는 클라우드 네이티브 스토리지 서비스에서 웹 콘텐츠를 제공하고 CDN(콘텐츠 배달 네트워크)을 사용하여 콘텐츠를 캐시하는 작업이 포함됩니다.

단일 페이지 JavaScript 애플리케이션과 같은 솔루션의 정적 구성 요소와 이미지 파일 및 문서와 같은 정적 콘텐츠에 Azure Front Door 또는 다른 CDN을 사용할 수 있습니다.

솔루션이 설계된 방식에 따라 CDN 내에서 JSON 형식의 API 응답과 같은 테넌트별 파일 또는 데이터를 캐시할 수도 있습니다. 이 방법은 솔루션의 성능 및 확장성을 개선하는 데 도움이 될 수 있지만 테넌트 간 데이터 유출을 방지하기 위해 테넌트별 데이터가 충분히 격리되어 있는지 여부를 고려하는 것이 중요합니다. 데이터가 업데이트되거나 새 애플리케이션 버전이 배포되는 경우와 같이 캐시에서 테넌트별 콘텐츠를 제거하는 방법을 고려합니다. URL 경로에 테넌트 식별자를 포함하면 특정 파일, 특정 테넌트와 관련된 모든 파일 또는 모든 테넌트의 모든 파일을 제거할지 여부를 제어할 수 있습니다.

피해야 할 안티패턴

VNet 연결 계획 실패

VNet에 리소스를 배포하면 트래픽이 솔루션의 구성 요소를 통해 흐르는 방식을 상당 부분 제어할 수 있습니다. 그러나 VNet 통합으로 인해 추가 복잡성, 비용 및 고려해야 할 기타 요소도 발생합니다. 이 효과는 PaaS(Platform as a Service) 구성 요소에서 특히 그렇습니다.

프로덕션 환경에서 구현하기 전에 문제를 파악할 수 있도록 네트워크 전략을 테스트하고 계획하는 것이 중요합니다.

제한 계획 없음

Azure는 네트워킹 리소스에 영향을 주는 여러 제한을 적용합니다. 이러한 제한에는 Azure 리소스 제한과 기본 프로토콜 및 플랫폼 제한이 포함됩니다. 예를 들어 Azure App Service 및 Azure Functions 같은 플랫폼 서비스에서 대규모 다중 테넌트 솔루션을 빌드하는 경우 TCP 연결 및 SNAT 포트 수를 고려해야 할 수 있습니다. 가상 머신 및 부하 분산 장치를 사용하는 경우 아웃바운드 규칙 및 SNAT 포트에 대한 제한 사항도 고려해야 합니다.

작은 서브넷

특히 크기를 조정할 때 배포할 리소스 또는 리소스 인스턴스 수를 허용하도록 각 서브넷의 크기를 고려하는 것이 중요합니다. PaaS(Platform as a Service) 리소스를 사용하는 경우 리소스의 구성 및 크기 조정이 서브넷에 필요한 IP 주소 수에 미치는 영향을 이해해야 합니다.

부적절한 네트워크 구분

솔루션에 가상 네트워크가 필요한 경우 인바운드 및 아웃바운드(남북) 트래픽 흐름 및 솔루션 내 흐름(동서)을 제어할 수 있도록 네트워크 구분을 구성하는 방법을 고려합니다. 테넌트에 자체 VNet이 있어야 하는지 또는 공유 VNet에 공유 리소스를 배포할지 여부를 결정합니다. 접근 방식을 변경하는 것은 어려울 수 있으므로 모든 요구 사항을 고려한 다음, 향후 성장 목표에 적합한 접근 방식을 선택해야 합니다.

네트워크 계층 보안 컨트롤에만 의존

최신 솔루션에서는 네트워크 계층 보안을 다른 보안 컨트롤과 결합하는 것이 중요하며 방화벽 또는 네트워크 세분화에만 의존해서는 안 됩니다. 이를 제로 트러스트 네트워킹이라고도 합니다. ID 기반 컨트롤을 사용하여 솔루션의 모든 계층에서 클라이언트, 호출자 또는 사용자를 확인합니다. 보호 계층을 추가할 수 있는 서비스를 사용하는 것이 좋습니다. 사용할 수 있는 옵션은 사용하는 Azure 서비스에 따라 달라집니다. AKS에서는 상호 TLS 인증에 서비스 메시를 사용하고 네트워크 정책을 사용하여 동서 트래픽을 제어하는 것이 좋습니다. App Service에서는 인증 및 권한 부여에 대한 기본 제공 지원 및 액세스 제한을 사용하는 것이 좋습니다.

테스트 없이 호스트 헤더 다시 작성

게이트웨이 오프로드 패턴을 사용하는 경우 HTTP 요청의 Host 헤더를 다시 작성하는 것이 좋습니다. 이 방법을 사용하면 사용자 지정 도메인 및 TLS 관리를 게이트웨이로 오프로드하여 백 엔드 웹 애플리케이션 서비스의 구성을 간소화할 수 있습니다.

그러나 Host 헤더를 다시 작성하면 일부 백 엔드 서비스에 문제가 발생할 수 있습니다. 애플리케이션에서 HTTP 리디렉션 또는 쿠키를 발급하는 경우 호스트 이름의 불일치로 인해 애플리케이션의 작동이 중단될 수 있습니다. 특히 이 문제는 Azure App Service, Azure Functions, Azure Spring Apps와 같은 다중 테넌트인 백 엔드 서비스를 사용할 때 발생할 수 있습니다. 자세한 내용은 호스트 이름 유지 모범 사례를 참조하세요.

사용하려는 게이트웨이 구성을 사용하여 애플리케이션의 동작을 테스트해야 합니다.

참가자

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

보안 주체 작성자:

  • John Downs | 주요 소프트웨어 엔지니어

기타 기여자:

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

다음 단계