게이트 이그레스

Last reviewed 2023-12-14 UTC

게이트 적용 이그레스 네트워킹 패턴의 아키텍처는 온프레미스 환경 또는 다른 클라우드 환경의 일부 API를 Google Cloud에 배포된 워크로드에 노출하는 것을 기반으로 합니다. 온프레미스 환경 또는 다른 클라우드 환경에서 공개 인터넷에 직접 노출하지 않습니다. API 게이트웨이, 프록시 또는 기존 워크로드의 퍼사드 역할을 하는 부하 분산기를 통해 이러한 제한된 노출을 촉진할 수 있습니다. API 게이트웨이 기능을 경계 네트워크와 같은 원격 경계 네트워크 세그먼트에 배포할 수 있습니다.

게이트 이그레스 네트워킹 패턴은 주로 계층형 애플리케이션 아키텍처 패턴파티션을 나눈 애플리케이션 아키텍처 패턴에 적용되지만 이에 국한되지는 않습니다. 내부 네트워크 내에 백엔드 워크로드를 배포할 때 게이트 이그레스 네트워킹은 온프레미스 컴퓨팅 환경 내에서 더 높은 수준의 보안을 유지하는 데 도움이 됩니다. 이 패턴을 사용하려면 다음 통신 요구 사항을 충족하는 방식으로 컴퓨팅 환경을 연결해야 합니다.

  • Google Cloud에 배포하는 워크로드는 내부 IP 주소를 사용하여 애플리케이션을 노출하는 API 게이트웨이 또는 부하 분산기(또는 Private Service Connect 엔드포인트)와 통신할 수 있습니다.
  • 비공개 컴퓨팅 환경의 다른 시스템은 Google Cloud 내에서 직접 연결할 수 없습니다.
  • 비공개 컴퓨팅 환경에서 Google Cloud에 배포된 워크로드로의 통신은 허용되지 않습니다.
  • 다른 환경의 비공개 API에 대한 트래픽은 Google Cloud 환경 내에서만 시작할 수 있습니다

이 가이드에서는 비공개 하이브리드 네트워크를 통해 연결된 하이브리드 및 멀티 클라우드 환경에 중점을 둡니다. 조직의 보안 요구사항에서 허용하는 경우 공개 IP 주소가 있는 원격 대상 API에 대한 API 호출을 인터넷을 통해 직접 연결할 수 있습니다. 하지만 다음 보안 메커니즘을 고려해야 합니다.

  • 전송 계층 보안(TLS)을 사용하는 API OAuth 2.0
  • 비율 제한
  • 위협 보호 정책
  • API 레이어의 백엔드에 구성된 상호 TLS
  • 양측의 사전 정의된 API 소스 및 대상과의 통신만 허용하도록 구성된 IP 주소 허용 목록 필터링

API 프록시를 보호하려면 다른 보안 측면을 고려하세요. 자세한 내용은 Apigee를 사용한 애플리케이션 및 API 보호 권장사항을 참조하세요.

아키텍처

다음 다이어그램은 이전 섹션에 나열된 통신 요구사항을 지원하는 참조 아키텍처를 보여줍니다.

데이터는 Google Cloud의 호스트 프로젝트에서 온프레미스 환경의 워크로드로 한 방향으로 흐릅니다.

데이터는 위의 다이어그램을 통해 다음과 같이 이동합니다.

  • Google Cloud 측에서 워크로드를 가상 프라이빗 클라우드(VPC)에 배포할 수 있습니다. VPC는 단일 또는 다중(공유 또는 비공유)일 수 있습니다. 배포는 조직의 프로젝트 및 리소스 계층 구조 설계와 일치해야 합니다.
  • Google Cloud 환경의 VPC 네트워크는 다른 컴퓨팅 환경으로 확장됩니다. 이러한 환경은 온프레미스이거나 다른 클라우드에 있을 수 있습니다. 내부 IP 주소를 사용하는 환경 간의 통신을 용이하게 하려면 적절한 하이브리드 및 멀티 클라우드 네트워킹 연결을 사용합니다.
  • 특정 VPC IP 주소에서 시작되고 원격 게이트웨이 또는 부하 분산기로 향하는 트래픽을 제한하려면 IP 주소 허용 목록 필터링을 사용합니다. 스테이트풀(Stateful) 방화벽 규칙을 사용하면 이러한 연결의 반환 트래픽이 허용됩니다. 다음 기능을 조합하여 사용하면 허용된 소스 및 대상 IP 주소로만 통신을 보호하고 제한할 수 있습니다.

  • 모든 환경은 겹치지 않는 RFC 1918 IP 주소 공간을 공유합니다.

변형

게이트 이그레스 아키텍처 패턴은 이 패턴의 통신 요구 사항을 여전히 고려하는 다양한 설계 요구 사항을 충족하기 위해 다른 접근 방식과 결합될 수 있습니다. 패턴은 다음 옵션을 제공합니다.

Google Cloud API 게이트웨이 및 전역 프런트엔드 사용

Apigee에서 고객 프로젝트 VPC로 Google Cloud로 전송된 다음 Cloud에서 온프레미스 환경 또는 다른 클라우드 인스턴스로 흐르는 데이터

이러한 설계 접근 방식에서 API 노출과 관리는 Google Cloud 내에서 수행됩니다. 위의 다이어그램에서 볼 수 있듯이 API 플랫폼으로 Apigee를 구현하여 이를 달성할 수 있습니다. 원격 환경에 API 게이트웨이 또는 부하 분산기를 배포할지 여부는 특정 요구 사항과 현재 구성에 따라 달라집니다. Apigee는 두 가지 연결 프로비저닝 옵션을 제공합니다.

  • VPC 피어링 사용
  • VPC 피어링 미사용

Google Cloud 전역 프런트엔드 기능인 Cloud Load Balancing, Cloud CDN(Cloud Interconnect를 통해 액세스 시) 및 Cross-Cloud Interconnect는 온프레미스 환경과 다른 클라우드 환경에 호스팅된 백엔드를 가진 애플리케이션에 대한 사용자의 액세스 속도를 향상시킵니다.

콘텐츠 전송 속도는 Google Cloud 접속 지점(PoP)에서 이러한 애플리케이션을 제공하여 최적활할 수 있습니다. 전 세계적으로 160개가 넘는 상호 연결 시설과 180개 이상의 인터넷 교환 시설에 Google Cloud PoP가 있습니다.

PoP가 Apigee와 Cloud CDN을 사용하여 고성능 API를 제공하는 데 어떻게 도움이 되는지 알아보려면, YouTube에서 Apigee 및 Cloud CDN을 사용하여 고성능 API 제공을 시청하세요.

  • 지연 시간 감소
  • API를 전역적으로 호스팅합니다.
  • 최대 트래픽에 대비한 가용성을 높입니다.

앞의 다이어그램에 표시된 설계 예시는 VPC 피어링 없이 Private Service Connect를 기반으로 합니다.

이 설계의 Northbound 네트워크는 다음을 통해 설정됩니다.

  • 클라이언트 요청이 종료되고 트래픽을 처리한 후 Private Service Connect 백엔드로 라우팅하는 부하 분산기(다이어그램의 LB)
  • Private Service Connect 백엔드를 사용하면 Google Cloud 부하 분산기가 프로듀서 서비스 연결과 연결된 Private Service Connect 연결을 통해 Private Service Connect network endpoint groups(NEGs)를 사용하여 게시된 서비스(Apigee 런타임 인스턴스)에 고객 요청을 전송할 수 있습니다.

Southbound 네트워킹은 다음을 통해 설정됩니다.

  • 고객 VPC의 내부 부하 분산기(다이어그램의 ILB)와 연결된 서비스 연결을 참조하는 Private Service Connect 엔드포인트
  • 하이브리드 연결 네트워크 엔드포인트 그룹(하이브리드 연결 NEG)으로 ILB가 배포됩니다.

  • 하이브리드 서비스는 VPN 또는 Cloud Interconnect와 같은 하이브리드 네트워크 연결을 통한 하이브리드 연결 NEG를 통해 액세스됩니다.

자세한 내용은 하이브리드 연결로 리전별 내부 프록시 네트워크 부하 분산기 설정Private Service Connect 배포 패턴을 참조하세요.

Private Service Connect를 사용하여 원격 서비스 노출

VPC의 워크로드에서 시작된 후 Cloud Load Balancing, 하이브리드 연결 NEG, Cloud VPN 또는 상호 연결을 통해 Google Cloud에서 온프레미스 환경 또는 다른 클라우드로 이동하는 데이터

다음 시나리오에서 원격 서비스를 노출하려면 Private Service Connect 옵션을 사용하세요.

  • API 플랫폼을 사용하고 있지 않거나 다음과 같은 이유로 VPC 네트워크를 외부 환경에 직접 연결하지 않으려는 경우:
    • 보안 제한 또는 규정 준수 요구사항이 있는 경우
    • 합병 및 인수 시나리오와 같이 IP 주소 범위가 겹치는 경우
  • 기한이 짧더라도 환경에서 클라이언트, 애플리케이션, 서비스 간의 안전한 단방향 통신을 사용 설정하려는 경우
  • 확장성이 뛰어난 멀티 테넌트 또는 단일 테넌트 서비스 모델을 제공하려면 다른 환경에 게시된 서비스에 연결하기 위해 서비스 제작자 VPC(전송 VPC)를 통해 여러 소비자 VPC에 대한 연결을 제공해야 할 수 있습니다.

API로 사용되는 애플리케이션에 Private Service Connect를 사용하면 게시된 애플리케이션에 내부 IP 주소가 제공되어 리전 간 및 하이브리드 연결을 통해 비공개 네트워크 내에서 안전하게 액세스할 수 있습니다. 이 추상화는 하이브리드 및 멀티 클라우드 연결 모델을 통해 다양한 클라우드 및 온프레미스 환경의 리소스 통합을 용이하게 합니다. Private Service Connect를 사용하여 세분화된 액세스 제어로 서비스를 게시함으로써 온프레미스 환경 또는 다른 클라우드 환경에 있는 애플리케이션을 안전하게 노출하고 통합을 가속화할 수 있습니다. 이 경우 다음 옵션을 사용할 수 있습니다.

앞의 다이어그램에서 애플리케이션의 VPC 네트워크에 있는 워크로드는 Private Service Connect 엔드포인트를 통해 온프레미스 환경 또는 다른 클라우드 환경에서 실행되는 하이브리드 서비스에 연결할 수 있습니다. 이는 다이어그램에 설명되어 있습니다. 단방향 통신을 위한 설계 옵션은 전송 VPC에 대한 피어링을 대신할 옵션을 제공합니다.

Cloud VPN 또는 Cloud Interconnect를 통해 온프레미스 환경 또는 다른 클라우드로 나가기 전에 Google Cloud 내부 여러 VPC를 통과하는 데이터

앞의 다이어그램에서 설계의 일부로 여러 개의 프런트엔드, 백엔드 또는 엔드포인트가 동일한 서비스 연결에 연결할 수 있으므로 여러 VPC 네트워크 또는 여러 소비자가 동일한 서비스에 액세스할 수 있습니다. 다음 다이어그램과 같이 애플리케이션이 여러 VPC에 액세스할 수 있도록 할 수 있습니다. 이 접근성은 IP 주소 범위가 겹치더라도 여러 소비자 VPC에서 서비스를 사용하는 멀티 테넌트 서비스 시나리오에서 도움이 될 수 있습니다.

IP 주소 중복은 다양한 환경에 있는 애플리케이션을 통합할 때 발생하는 가장 일반적인 문제 중 하나입니다. 다음 다이어그램의 Private Service Connect 연결은 IP 주소 겹침 문제를 방지하는 데 도움이 됩니다. IP 주소 변환을 수행하기 위해 Cloud NAT 또는 NVA와 같은 추가 네트워킹 구성요소를 프로비저닝하거나 관리할 필요 없이 이를 수행합니다. 구성 예시는 Private Service Connect를 사용하여 하이브리드 서비스 게시를 참조하세요.

이 설계의 장점은 다음과 같습니다.

  • 잠재적인 공유 확장 종속성과 대규모 관리의 복잡성을 피할 수 있습니다.
  • 세분화된 연결 제어를 제공하여 보안을 개선합니다.
  • 서비스의 제작자 및 소비자와 원격 외부 환경 간의 IP 주소 조정이 줄어듭니다.

앞선 다이어그램의 설계 접근 방식은 Private Service Connect 옵션을 포함하여 앞에서 설명한 네트워킹 설계 옵션을 사용하여 이후 단계에서 Apigee를 API 플랫폼으로 통합하기 위해 확장될 수 있습니다.

Private Service Connect 전역 액세스를 사용하여 다른 리전에서 Private Service Connect 엔드포인트에 액세스할 수 있습니다.

Private Service Connect 엔드포인트에 연결하는 클라이언트는 엔드포인트와 동일한 리전이나 다른 리전에 있을 수 있습니다. 이 접근 방식은 여러 리전에서 호스팅되는 서비스 간에 고가용성을 제공하거나, 다른 리전의 단일 리전에서 사용 가능한 서비스에 액세스하기 위해 사용될 수 있습니다. 다른 리전에서 호스팅되는 리소스에서 Private Service Connect 엔드포인트에 액세스하는 경우 전역 액세스 권한이 있는 엔드포인트를 대상으로 하는 트래픽에 리전 간 아웃바운드 요금이 적용됩니다.

권장사항

  • Apigee 및 Apigee Hybrid를 API 플랫폼 솔루션으로 사용하면 여러 가지 이점이 있습니다. 보안 기능, 비율 제한, 할당량, 분석과 결합된 백엔드 서비스 API에 프록시 레이어와 추상화 또는 퍼사드를 제공합니다.
  • Google Cloud에서 VPC와 프로젝트 설계는 리소스 계층 구조와 보안 통신 모델 요구사항에 따라 결정되어야 합니다.
  • API 게이트웨이가 있는 API를 사용하는 경우 IP 주소 허용 목록도 사용해야 합니다. 허용 목록은 다른 환경에서 호스팅될 수 있는 API 소비자 및 API 게이트웨이의 특정 IP 주소 소스 및 대상으로의 통신을 제한합니다.
  • VPC 방화벽 규칙 또는 방화벽 정책을 사용하여 Private Service Connect 엔드포인트를 통해 Private Service Connect 리소스에 대한 액세스를 제어합니다.
  • 애플리케이션 부하 분산기를 통해 애플리케이션이 외부에 노출되는 경우 DDoS 및 애플리케이션 계층 보안 위협으로부터 보호하기 위해 Google Cloud Armor를 추가 보안 레이어로 사용하는 것이 좋습니다.
  • 인스턴스에 인터넷 액세스가 필요한 경우 애플리케이션(소비자) VPC에서 Cloud NAT를 사용하여 워크로드가 인터넷에 액세스하도록 허용합니다. 이렇게 하면 API 게이트웨이 또는 부하 분산기 뒤에 배포된 시스템에서 외부 공용 IP 주소로 VM 인스턴스를 할당하지 않아도 됩니다.

  • 하이브리드 및 멀티 클라우드 네트워킹 패턴에 대한 일반적인 권장사항을 참조하세요.