미러링 패턴

Last reviewed 2023-12-14 UTC

미러링 패턴은 특정 기존 환경의 설계를 새 환경에 복제하는 것을 기반으로 합니다. 따라서 이 패턴은 주로 환경 하이브리드 패턴을 따르는 아키텍처에 적용됩니다. 이 패턴에서는 한 환경에서 개발 및 테스트 워크로드를 실행하고 다른 환경에서 스테이징 및 프로덕션 워크로드를 실행합니다.

미러링 패턴은 테스트 및 프로덕션 워크로드가 서로 직접 통신하지 않는다고 가정합니다. 그러나 두 워크로드 그룹을 일관된 방식으로 관리하고 배포할 수 있어야 합니다.

이 패턴을 사용하는 경우 다음 요구사항에 맞는 방식으로 두 컴퓨팅 환경을 연결합니다.

  • 지속적 통합/지속적 배포(CI/CD)는 모든 컴퓨팅 환경 또는 특정 환경에서 워크로드를 배포하고 관리할 수 있습니다.
  • 모니터링, 구성 관리, 기타 관리 시스템은 컴퓨팅 환경 전반에서 작동해야 합니다.
  • 워크로드는 컴퓨팅 환경 간에 직접 통신할 수 없습니다. 필요한 경우 통신을 세분화하고 제어해야 합니다.

아키텍처

다음 아키텍처 다이어그램은 CI/CD, 모니터링, 구성 관리, 기타 관리 시스템, 워크로드 통신을 지원하는 이 패턴의 상위 수준 참조 아키텍처를 보여줍니다.

데이터가 Google Cloud의 CI/CD 및 관리자 VPC와 온프레미스 프로덕션 환경 간에 이동합니다. 또한 Google Cloud 내의 CI/CD-VPC와 개발 및 테스트 환경 간에 데이터가 이동합니다.

앞의 다이어그램에서 아키텍처에 대한 설명은 다음과 같습니다.

  • 워크로드는 기능 환경(개발, 테스트, CI/CD, 관리 도구)에 따라 Google Cloud 측의 별도 VPC에 분산됩니다.
  • 공유 VPC는 개발 및 테스트 워크로드에 사용됩니다. CI/CD 및 관리 도구에는 추가 VPC가 사용됩니다. 공유 VPC를 사용할 경우 다음과 같습니다.
    • 애플리케이션은 환경 및 서비스 프로젝트별로 다른 팀에서 관리합니다.
    • 호스트 프로젝트는 개발 및 테스트 환경 간의 네트워크 통신 및 보안 제어와 VPC 외부로의 네트워크 통신 및 보안 제어를 관리하고 제어합니다.
  • CI/CD VPC는 비공개 컴퓨팅 환경에서 프로덕션 워크로드를 실행하는 네트워크에 연결됩니다.
  • 방화벽 규칙은 허용된 트래픽만 허용합니다.
    • 침입 방지 서비스(IPS)를 사용해서 설계 또는 라우팅을 변경하지 않고 위협 방지를 위해 심층 패킷 검사를 구현하는 Cloud Next Generation Firewall Enterprise를 사용할 수도 있습니다. Cloud Next Generation Firewall Enterprise는 패킷 가로채기 기술을 사용하여 구성된 위협 서명에 대해 워크로드를 투명하게 검사하는 Google 관리 영역 방화벽 엔드포인트를 만들어 작동합니다. 또한 위협으로부터 워크로드를 보호합니다.
  • 내부 IP 주소를 사용하여 피어링된 VPC 간의 통신을 사용 설정합니다.
    • 이 패턴의 피어링을 통해 CI/CD 및 관리 시스템은 개발 및 테스트 워크로드를 배포하고 관리할 수 있습니다.
  • 다음 일반 권장사항을 고려하세요.

비즈니스 및 애플리케이션 요구사항을 충족하는 앞서 설명한 하이브리드 및 멀티 클라우드 네트워킹 연결 옵션 중 하나를 사용하여 이 CI/CD 연결을 설정합니다. 프로덕션 워크로드를 배포하고 관리할 수 있도록 이 연결은 여러 컴퓨팅 환경 간에 비공개 네트워크 도달성을 제공합니다. 모든 환경은 겹치지 않는 RFC 1918 IP 주소 공간을 사용해야 합니다.

개발 및 테스트 환경의 인스턴스에 인터넷 액세스가 필요한 경우 다음 옵션을 고려하세요.

  • 동일한 공유 VPC 호스트 프로젝트 네트워크에 Cloud NAT를 배포할 수 있습니다. 동일한 공유 VPC 호스트 프로젝트 네트워크에 배포하면 인터넷에서 이러한 인스턴스에 직접 액세스하지 못하게 만들 수 있습니다.
  • 아웃바운드 웹 트래픽의 경우 보안 웹 프록시를 사용할 수 있습니다. 프록시는 몇 가지 이점이 있습니다.

Google Cloud와 하이브리드 및 멀티 클라우드 환경에서 빌드, 테스트, 배포하는 데 도움이 되는 Google Cloud 도구 및 기능에 대한 자세한 내용은 Google Cloud의 DevOps 및 CI/CD 설명 블로그를 참조하세요.

변형

모든 통신 요구사항을 고려하면서 다양한 설계 요구사항을 충족하기 위해 미러링된 아키텍처 패턴에서는 다음 옵션을 제공하며 관련 설명은 다음 섹션에서 제공합니다.

환경당 공유 VPC

환경별 공유 VPC 설계 옵션을 사용하면 특정 조직 보안 요구사항을 충족하는 데 필요한 CI/CD 및 관리 도구를 비롯하여 환경 전반에서 애플리케이션 또는 서비스 수준을 분리할 수 있습니다. 이러한 요구사항은 여러 팀에서 관리해야 하는 다양한 서비스의 통신, 관리 도메인, 액세스 제어를 제한합니다.

이 설계는 서로 다른 환경 간에 네트워크 및 프로젝트 수준 격리를 제공하여 분리를 실현하므로 더 세분화된 커뮤니케이션과 Identity and Access Management(IAM) 액세스 제어가 가능합니다.

관리 및 운영 관점에서 이 설계는 환경 및 서비스 프로젝트별로 여러 팀에서 만든 애플리케이션과 워크로드를 유연하게 관리할 수 있도록 지원합니다. 다음과 같은 가능한 구조를 기반으로 네트워킹 운영팀에서 VPC 네트워킹 및 보안 기능을 프로비저닝하고 관리할 수 있습니다.

  • 한 팀이 모든 환경에서 모든 호스트 프로젝트를 관리합니다.
  • 여러 팀이 각 환경에서 호스트 프로젝트를 관리합니다.

호스트 프로젝트 관리는 각 팀의 팀 구조, 보안 운영, 액세스 요구사항을 기준으로 결정해야 합니다. 이 설계 변형은 각 환경 시작 영역 설계 옵션의 공유 VPC 네트워크에 적용할 수 있습니다. 그러나 하이브리드 네트워크를 통한 통신을 비롯하여 여러 환경 간에 허용되는 통신을 정의하려면 미러링 패턴의 통신 요구사항을 고려해야 합니다.

다음 다이어그램과 같이 각 기본 환경에 공유 VPC 네트워크를 프로비저닝할 수도 있습니다.

Google Cloud의 VPC 피어링은 개발 및 테스트 환경과 CI/CD 및 관리 서브넷 간에 데이터를 공유합니다. 이 서브넷은 Google Cloud와 온프레미스 환경 간에 데이터를 공유합니다.

중앙 집중식 애플리케이션 계층 방화벽

일부 시나리오에서는 보안 요구사항에 따라 애플리케이션 계층(레이어 7) 및 Cloud Next Generation Firewall의 기능을 능가하는 고급 방화벽 메커니즘을 사용한 심층 패킷 검사를 고려해야 할 수 있습니다. 조직의 보안 요구사항 및 표준을 충족하려면 네트워크 가상 어플라이언스(NVA)에 호스팅된 NGFW 어플라이언스를 사용하면 됩니다. 여러 Google Cloud 보안 파트너가 이 작업에 적합한 옵션을 제공합니다.

다음 다이어그램에 표시된 것처럼 여러 네트워크 인터페이스를 사용하여 가상 프라이빗 클라우드와 비공개 컴퓨팅 환경 간의 네트워크 경로에 NVA를 배치할 수 있습니다.

Google Cloud의 VPC 피어링은 개발 및 테스트 환경과 CI/CD 및 관리 서브넷 간에 데이터를 공유합니다. 서브넷은 전송 VPC 네트워크를 통해 Google Cloud와 온프레미스 환경 간에 데이터를 공유합니다.

이 설계는 다음 다이어그램과 같이 여러 공유 VPC에서도 사용할 수도 있습니다.

Google Cloud의 VPC 피어링은 개발 및 테스트 환경과 CI/CD 및 관리 서브넷 간에 데이터를 공유합니다. 이 서브넷은 NVA를 사용하여 전송 VPC 네트워크를 통해 Google Cloud와 온프레미스 환경 간에 데이터를 공유합니다.

이 설계의 NVA는 경계 보안 계층 역할을 합니다. 또한 인라인 트래픽 검사를 사용 설정하고 엄격한 액세스 제어 정책을 적용하기 위한 기반이 됩니다.

VPC 방화벽 규칙 및 침입 방지 서비스 기능을 포함하는 강력한 다층 보안 전략을 위해 East-West 및 North-South 트래픽 흐름 모두에 추가 트래픽 검사 및 보안 제어를 포함하세요.

허브 및 스포크 토폴로지

또 다른 설계 변형은 개발 및 다양한 테스트 단계에 별도의 VPC(공유 VPC 포함)를 사용하는 것입니다. 이 변형에서는 다음 다이어그램과 같이 모든 단계 환경이 허브 및 스포크 아키텍처의 CI/CD 및 관리 VPC에 연결됩니다. 각 환경에서 관리 도메인과 기능을 분리해야 하는 경우 이 옵션을 사용하세요. 허브 및 스포크 통신 모델은 다음 요구사항을 충족하는 데 도움이 됩니다.

  • 애플리케이션이 모니터링, 구성 관리 도구, CI/CD, 인증과 같은 공통 서비스 집합에 액세스해야 합니다.
  • 허브를 통해 중앙 집중식으로 인바운드 및 아웃바운드 트래픽에 공통 보안 정책 집합을 적용해야 합니다.

허브 및 스포크 설계 옵션에 관한 자세한 내용은 중앙 집중식 어플라이언스를 사용하는 허브 및 스포크 토폴로지중앙 집중식 어플라이언스를 사용하지 않는 허브 및 스포크 토폴로지를 참조하세요.

개발 및 테스트 환경은 허브 VPC CI/CD 및 온프레미스 환경에 대한 관리 VPC에 데이터를 공유합니다.

위의 다이어그램과 같이 VPC 간 통신과 하이브리드 연결은 모두 허브 VPC를 통과합니다. 이 패턴의 일부로 연결 요구사항에 맞게 허브 VPC에서 통신을 제어하고 제한할 수 있습니다.

허브 및 스포크 네트워크 아키텍처에 포함되는 Google Cloud의 (스포크 및 허브 VPC 간) 기본 연결 옵션은 다음과 같습니다.

  • VPC 네트워크 피어링
  • VPN
  • 네트워크 가상 어플라이언스(NVA) 사용

설계 시 고려해야 할 옵션에 관한 자세한 내용은 허브 및 스포크 네트워크 아키텍처를 참조하세요. 스포크와 허브 VPC 간에 VPC 피어링을 통해 VPN을 선택하는 데 영향을 미치는 주요 요소는 트래픽 전달이 필요한 경우입니다. 트래픽 전이성은 스포크의 트래픽이 허브를 통해 다른 스포크에 도달할 수 있음을 의미합니다.

마이크로서비스 제로 트러스트 분산 아키텍처

하이브리드 및 멀티 클라우드 아키텍처에서는 프로덕션 환경을 개발 및 테스트 환경과 분리하는 등 기술 및 비즈니스 목표를 달성하기 위해 여러 클러스터가 필요할 수 있습니다. 따라서 네트워크 경계 보안 제어는 특히 특정 보안 요구사항을 준수해야 하는 경우에 중요합니다.

현재 클라우드 중심 분산 마이크로서비스 아키텍처의 보안 요구사항을 지원하는 것만으로는 충분하지 않으며 제로 트러스트 분산 아키텍처도 고려해야 합니다. 마이크로서비스 제로 트러스트 분산 아키텍처는 마이크로서비스 수준의 보안 정책 시행, 인증, 워크로드 아이덴티티로 마이크로서비스 아키텍처를 지원합니다. 트러스트는 ID 기반이며 각 서비스에 적용됩니다.

서비스 메시와 같은 분산 프록시 아키텍처를 사용하면 서비스가 호출자를 효과적으로 검증하고 각 요청에 대해 세분화된 액세스 제어 정책을 구현하여 더 안전하고 확장 가능한 마이크로서비스 환경을 지원할 수 있습니다. Cloud Service Mesh를 사용하면 Google Cloud 배포와 온프레미스 배포를 확장할 수 있는 공통 메시를 유연하게 사용할 수 있습니다. 메시는 승인 정책을 사용하여 서비스 간 통신을 보호합니다.

Kubernetes 클러스터 내 경량형 Apigee API 게이트웨이 배포인 Envoy용 Apigee 어댑터를 이 아키텍처에 통합할 수도 있습니다. Envoy용 Apigee 어댑터는 클라우드 중심 애플리케이션용으로 설계된 오픈소스 에지 및 서비스 프록시입니다.

데이터가 분산된 프록시 아키텍처를 통해 Google Cloud의 서비스와 온프레미스 환경 간에 이동합니다.

이 주제에 관한 자세한 내용은 다음 도움말을 참조하세요.

미러링 패턴 권장사항

  • 프로덕션 배포를 배포하거나 다시 구성하는 데 필요한 CI/CD 시스템은 가용성이 높아야 합니다. 즉, 모든 아키텍처 구성요소는 예상되는 수준의 시스템 가용성을 제공하도록 설계되어야 합니다. 자세한 내용은 Google Cloud 인프라 안정성을 참조하세요.
  • 코드 업데이트와 같은 반복 프로세스의 구성 오류를 없애기 위해 빌드, 테스트, 배포를 표준화하려면 자동화가 필수입니다. 자동화 시 다양한 검사와 보호 조치를 사용하는 방법을 자세히 알아보려면 배포 자동화를 참조하세요.
  • 이 설계에서 중앙 집중식 NVA를 통합하려면 보안 액세스 제어 수준이 다른 여러 세그먼트를 통합해야 할 수 있습니다.
  • NVA가 포함된 솔루션을 설계할 때는 모든 통신을 차단할 수 있는 단일 장애 지점을 방지하기 위해 NVA의 고가용성(HA)을 고려해야 합니다. NVA 공급업체에서 제공하는 HA 및 중복 설계와 구현 안내를 따르세요.
  • VPC 피어링 또는 VPN을 통해 온프레미스 IP 경로를 개발 및 테스트 VPC로 내보내지 않으면 개발 및 테스트 환경에서 온프레미스 환경으로의 네트워크 도달성을 제한할 수 있습니다. 자세한 내용은 VPC 네트워크 피어링 커스텀 경로 교환을 참조하세요.
  • Google API 액세스가 필요할 수 있는 비공개 IP 주소 지정이 사용되는 워크로드의 경우 VPC 네트워크 내에서 Private Service Connect 엔드포인트를 사용하여 Google API를 노출할 수 있습니다. 자세한 내용은 이 시리즈의 게이트 인그레스를 참조하세요.
  • 하이브리드 및 멀티 클라우드 네트워킹 아키텍처 패턴에 대한 일반적인 권장사항을 참조하세요.