다음을 통해 공유

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

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

비고

Azure는 여러 네트워크 구성 요소와 마찬가지로 다중 테넌트 환경입니다. 고유한 솔루션을 디자인하기 위해 세부 정보를 이해할 필요는 없지만 Azure가 다른 고객의 트래픽에서 가상 네트워크 트래픽을 격리하는 방법에 대해 자세히 알아볼 수 있습니다.

주요 고려 사항 및 요구 사항

인프라 및 플랫폼 서비스

네트워킹 구성 요소 고려 사항은 사용하는 서비스 범주에 따라 달라집니다.

인프라 서비스

VM(가상 머신) 또는 AKS(Azure Kubernetes Service)와 같은 인프라 서비스를 사용하는 경우 서비스의 연결을 뒷받침하는 가상 네트워크를 고려하고 디자인합니다. 또한 디자인에 통합해야 하는 다른 보안 및 격리 계층도 고려합니다. 네트워크 계층 컨트롤에만 의존하지 않습니다.

플랫폼 서비스

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

인터넷에서 플랫폼 서비스를 격리하려면 가상 네트워크를 사용합니다. 사용하는 서비스에 따라 Azure Application Gateway와 같은 프라이빗 엔드포인트 또는 가상 네트워크 통합 리소스로 작업할 수 있습니다. 또한 공용 IP 주소를 통해 플랫폼 서비스를 사용할 수 있도록 하고 방화벽 및 ID 제어와 같은 서비스 자체 보호를 사용할 수도 있습니다. 이러한 상황에서는 사용자 고유의 가상 네트워크를 배포하고 구성할 필요가 없을 수 있습니다.

다음 요인에 따라 플랫폼 서비스에 가상 네트워크를 사용할지 여부를 결정합니다.

  • 규정 준수 요구 사항: 특정 규정 준수 표준을 충족해야 할 수도 있습니다. 일부 표준에서는 특정 네트워크 컨트롤 사용과 같은 특정 방식으로 Azure 환경을 구성해야 합니다. 자세한 내용은 다중 테넌트 솔루션의 거버넌스 및 규정 준수에 대한 아키텍처 접근 방식을 참조하세요.

  • 테넌트의 요구 사항: 조직에 네트워크 계층 격리 또는 제어에 대한 요구 사항이 정의되지 않은 경우에도 테넌트가 있을 수 있습니다. 테넌트가 솔루션에 액세스하도록 계획하는 방법과 네트워크 디자인에 대한 가정이 있는지 여부를 명확하게 이해합니다.

  • 복잡성: 가상 네트워크는 복잡성을 발생합니다. 팀이 안전하지 않은 환경을 배포하지 않도록 관련 원칙을 명확하게 이해해야 합니다.

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

서브넷 크기 조정

가상 네트워크를 배포해야 하는 경우 서브넷을 포함하여 전체 가상 네트워크의 크기 조정 및 주소 공간을 신중하게 고려합니다.

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

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

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

공용 또는 프라이빗 액세스

테넌트가 인터넷을 통해 또는 개인 IP 주소를 통해 서비스에 액세스해야 하는지 여부를 고려합니다.

인터넷 기반(공용) 액세스를 위해 서비스를 보호하려면 방화벽 규칙, IP 주소 허용 목록 및 거부 목록, 공유 비밀 및 키 및 ID 기반 컨트롤을 사용합니다.

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

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

Azure 내부 또는 외부에서 테넌트 네트워크 내의 엔드포인트에 데이터를 보내야 하는지 여부를 고려합니다. 예를 들어 고객이 제공한 웹후크를 호출하거나 테넌트의 시스템에 실시간 메시지를 보낼 수 있습니다.

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

  • 인터넷을 통해 솔루션에서 테넌트의 엔드포인트로의 연결을 시작합니다. 연결이 고정 IP 주소에서 시작되어야 하는지 여부를 고려합니다. 사용하는 Azure 서비스에 따라 Azure NAT 게이트웨이, 방화벽 또는 부하 분산 장치를 배포하여 NAT(네트워크 주소 변환)를 사용해야 할 수 있습니다.

  • 에이전트를 배포하여 해당 위치에 관계없이 Azure 호스팅 서비스와 고객의 네트워크 간에 연결을 사용하도록 설정합니다.

  • Azure Event Grid와 같은 서비스를 사용하여 이벤트 도메인과 함께 일방형 메시징을 사용하는 것이 좋습니다.

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

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

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

일부 시나리오에서는 테넌트를 대신하여 Azure에서 전용 가상 네트워크 연결 리소스를 실행해야 합니다. 예를 들어 각 테넌트에 대해 VM을 실행하거나 프라이빗 엔드포인트를 사용하여 테넌트별 데이터베이스에 액세스해야 할 수 있습니다.

제어하는 IP 주소 공간을 사용하여 각 테넌트에 대한 가상 네트워크를 배포하는 것이 좋습니다. 이 방법을 사용하면 허브 및 스포크 토폴 로지 설정과 같이 가상 네트워크를 함께 피어링하여 트래픽 수신 및 송신을 중앙에서 제어할 수 있습니다.

테넌트가 가상 네트워크 피어링을 사용하는 등 사용자가 만든 가상 네트워크에 직접 연결해야 하는 경우 서비스 공급자가 선택한 IP 주소를 사용하지 않습니다. 선택하는 주소 공간이 기존 주소 공간과 충돌할 수 있습니다.

테넌트에서 선택한 IP 주소를 사용하는 테넌트별 가상 네트워크

테넌트가 자체 가상 네트워크를 대신 관리하는 가상 네트워크와 피어링해야 하는 경우 테넌트가 선택하는 IP 주소 공간을 사용하여 테넌트별 가상 네트워크를 배포하는 것이 좋습니다. 이 설정을 통해 각 테넌트는 시스템의 가상 네트워크에 있는 IP 주소 범위가 자체 가상 네트워크와 겹치지 않도록 하여 피어링에 대한 호환성을 가능하게 합니다.

그러나 이 방법을 사용하면 테넌트의 가상 네트워크를 함께 피어링하거나 허브 및 스포크 토폴로지 채택을 방지할 수 있습니다. 피어된 가상 네트워크는 겹치는 IP 주소 범위를 사용할 수 없으며 테넌트가 자체 IP 주소 범위를 선택하면 서로 겹치는 범위를 선택할 수 있습니다.

허브 및 스포크 토폴로지

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

허브 및 스포크 토폴로지 사용 시 피어된 가상 네트워크의 최대 수와 같은 제한을 계획합니다. 각 테넌트의 가상 네트워크에 겹치는 주소 공간을 사용하지 마세요.

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

팁 (조언)

솔루션이 여러 지리적 지역에 걸쳐 있는 경우 트래픽이 여러 Azure 지역을 넘지 않도록 각 지역에 별도의 허브 및 허브 리소스를 배포합니다. 이 방법은 리소스 비용이 더 많이 발생하지만 요청 대기 시간을 줄이고 전역 피어링 요금을 줄입니다.

고정 IP 주소

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

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

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

요원

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

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

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

테넌트의 네트워크에 연결하기 위해 에이전트를 제공하는 Microsoft 서비스에는 다음 예제가 포함됩니다.

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

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

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

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

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

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

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

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

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

정적 콘텐츠 호스팅 패턴

정적 콘텐츠 호스팅 패턴은 클라우드 네이티브 스토리지 서비스의 웹 콘텐츠를 제공하고 콘텐츠 배달 네트워크를 사용하여 콘텐츠를 캐시합니다.

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

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

피해야 할 안티패턴

가상 네트워크 연결 계획 실패

가상 네트워크에 리소스를 배포하면 솔루션의 구성 요소를 통해 트래픽이 흐르는 방식을 크게 제어할 수 있습니다. 그러나 가상 네트워크 통합은 특히 PaaS(Platform as a Service) 구성 요소에 대해 고려해야 하는 복잡성, 비용 및 기타 요소를 더 많이 도입합니다.

프로덕션 환경에서 구현하기 전에 네트워크 전략을 테스트하고 계획하여 문제를 식별합니다.

제한을 계획하지 않음

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

작은 서브넷

특히 크기를 조정할 때 배포하려는 리소스 또는 리소스 인스턴스 수를 지원하도록 각 서브넷의 크기를 조정합니다. PaaS 리소스를 사용하는 경우 리소스의 구성 및 크기 조정이 서브넷에 필요한 IP 주소 수에 어떤 영향을 미치는지 이해합니다.

부적절한 네트워크 세분화

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

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

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

테스트 없이 호스트 헤더 다시 쓰기

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

그러나 Host 헤더를 다시 쓰면 일부 백 엔드 서비스에 문제가 발생할 수 있습니다. 애플리케이션에서 HTTP 리디렉션 또는 쿠키를 발급하는 경우 호스트 이름의 불일치가 애플리케이션의 기능을 손상할 수 있습니다. 특히 이 문제는 App Service 및 Azure Functions와 같은 다중 테넌트 인프라에서 실행되는 백 엔드 서비스를 사용할 때 발생할 수 있습니다. 자세한 내용은 호스트 이름 보존 모범 사례를 참조하세요.

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

기여자

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

대표 저자:

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

기타 기여자:

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

  • Last updated on