파티션을 나눈 멀티 클라우드 아키텍처 패턴은 여러 다른 클라우드 서비스 제공업체가 운영하는 여러 퍼블릭 클라우드 환경을 조합한 것입니다. 이 아키텍처를 사용하면 이 시리즈의 첫 번째 부분에서 논의한 멀티 클라우드 공급자와 고려사항에 따라 최적의 컴퓨팅 환경에 애플리케이션을 유연하게 배포할 수 있습니다.
다음 다이어그램은 파티션을 나눈 멀티 클라우드 아키텍처 패턴을 보여줍니다.
이 아키텍처 패턴은 두 가지 다른 방법으로 빌드할 수 있습니다. 첫 번째 접근 방법은 여러 퍼블릭 클라우드 환경에서 애플리케이션 구성요소 배포를 기준으로 합니다. 이러한 접근 방법을 복합 아키텍처라고도 부르며, 계층형 하이브리드 아키텍처 패턴과 동일합니다. 하지만 퍼블릭 클라우드와 함께 온프레미스 환경을 사용하는 대신 최소한 2개 이상의 클라우드 환경을 사용합니다. 복합 아키텍처에서 단일 워크로드 또는 애플리케이션은 둘 이상의 클라우드에서 제공되는 구성요소를 사용합니다. 두 번째 접근 방법은 각기 다른 퍼블릭 클라우드 환경에 서로 다른 애플리케이션을 배포합니다. 다음 목록은 두 번째 접근 방법의 비즈니스 요소를 보여줍니다.
- 두 기업 간의 인수 합병 과정에서 서로 다른 클라우드 환경에 호스팅되는 애플리케이션을 완벽하게 통합할 수 있습니다.
- 유연성을 높이고 조직 내 다양한 클라우드 기본 설정을 지원할 수 있습니다. 이 접근 방식을 채택하면 조직 부서가 특정 요구 및 기본 설정에 가장 적합한 클라우드 제공업체를 선택할 수 있습니다.
- 멀티 리전 또는 전역 클라우드 배포에서 운영할 수 있습니다. 기업이 특정 리전 또는 국가의 데이터 상주 규제를 준수해야 할 경우에는 기본 클라우드 제공업체에 해당 지역의 클라우드 리전이 없는 경우 해당 위치에서 사용 가능한 클라우드 제공업체 중에서 선택해야 합니다.
파티션을 나눈 멀티 클라우드 아키텍처 패턴을 사용할 때는 필요에 따라 하나의 퍼블릭 클라우드 환경에서 다른 환경으로 워크로드를 이동하는 기능을 선택적으로 유지보수할 수 있습니다. 이 경우 워크로드의 이식성이 중요한 요구사항이 됩니다. 워크로드를 여러 컴퓨팅 환경에 배포하고 환경 간에 워크로드를 이동하는 기능을 유지하려면 환경 간의 차이를 추상화해야 합니다. GKE Enterprise를 사용하면 일관적인 거버넌스, 운영, 보안 상황에 따라 멀티 클라우드 복잡성을 해결하는 솔루션을 설계 및 빌드할 수 있습니다. 자세한 내용은 GKE Multi-Cloud를 참조하세요.
앞에서 언급한 것처럼 일부 경우에는 Google Cloud를 다른 클라우드 제공업체와 조합하고 이러한 클라우드 환경 간에 워크로드를 나눠야 할 업무적 기술적 이유가 존재할 수 있습니다. 멀티 클라우드 솔루션은 특정 업체에 대한 고착을 최소화하고 규제 요구사항을 충족하는 데 도움을 주면서도 멀티 클라우드 환경 전체에서 애플리케이션을 마이그레이션 및 빌드하고 이식성을 최적화할 수 있는 유연성을 제공합니다. 예를 들어 Google Cloud를 Oracle Cloud Infrastructure(OCI)에 연결하여 비공개 Cloud Interconnect를 사용하는 각 플랫폼 기능을 활용하여 OCI에서 실행되는 구성요소를 Google Cloud에서 실행되는 리소스와 조합하는 멀티 클라우드 솔루션을 빌드할 수 있습니다. 자세한 내용은 Google Cloud 및 Oracle Cloud Infrastructure – 멀티 클라우드 최대 이점 활용을 참조하세요. 또한 Cross-Cloud Interconnect는 Google Cloud와 다른 지원되는 클라우드 서비스 제공업체 사이의 고대역폭 전용 연결을 지원하여 높은 클라우드 간 트래픽 볼륨을 처리하는 멀티 클라우드 솔루션을 설계하고 빌드할 수 있습니다.
장점
멀티 클라우드 아키텍처를 사용하면 비즈니스 요인, 고려사항, 전략, 접근 방법에서 설명하는 대로 몇 가지 업무적 기술적 이점을 제공하지만 각각의 잠재적 이점을 얻을 수 있는 가능성을 세부적으로 평가하는 것이 중요합니다. 평가 시에는 연관된 직접 또는 간접 과제와 잠재적 걸림돌을 신중하게 고려하고 이를 효율적으로 탐색할 수 있는지 확인해야 합니다. 또한 애플리케이션 또는 서비스의 장기적 증가로 인해 최초의 이점을 넘어설 만큼 복잡성이 증가할 수 있다는 것도 주의해야 합니다.
다음은 파티션을 나눈 멀티 클라우드 아키텍처 패턴의 몇 가지 중요한 이점입니다.
단일 클라우드 제공업체에 대한 약정을 최소화할 필요가 있을 때는 멀티 클라우드 제공업체 간에 애플리케이션을 분산할 수 있습니다. 결과적으로 클라우드 공급업체 간에 어느 정도까지 서비스 플랜을 변경할 수 있으므로 벤더 고착을 비교적 줄일 수 있습니다. 개방형 클라우드는 GKE Enterprise와 같은 Google Cloud 기능을 여러 다른 물리적 위치에 제공할 수 있게 도와줍니다. Google Cloud 기능을 온프레미스, 멀티 퍼블릭 클라우드, 에지로 확장함으로써 유연성과 민첩성을 제공하고 혁신을 주도할 수 있습니다.
규제상의 이유로, Google Cloud가 클라우드 리전을 지원하지 않는 국가에서 사용자 기반 및 데이터의 특정 분류 기준을 처리할 수 있습니다.
파티션을 나눈 멀티 클라우드 아키텍처 패턴은 기본 클라우드 제공업체에 클라우드 리전 또는 접속 지점이 없는 위치에서 지연 시간을 줄이고 사용자 경험의 전반적인 품질을 개선하는 데 도움이 될 수 있습니다. 이 패턴은 분산 CDN과 함께 Cross-Cloud Interconnect 및 CDN Interconnect와 같은 고용량 및 낮은 지연 시간을 지원하는 멀티 클라우드 연결을 사용할 때 특히 유용합니다.
다른 클라우드 제공업체가 제공하는 최상의 서비스 중에서 선택할 수 있는 방식으로 여러 클라우드 제공업체에 애플리케이션을 배포할 수 있습니다.
파티션을 나눈 멀티 클라우드 아키텍처 패턴은 두 기업의 애플리케이션과 서비스가 서로 다른 퍼블릭 클라우드 환경에 호스팅될 수 있는 병합 합병 시나리오를 지원하고 가속화하는 데 도움이 됩니다.
권장사항
- 미션 크리티컬 이외의 워크로드 배포로 시작합니다. 그런 후 보조 클라우드에서의 초기 배포를 이후 배포 또는 마이그레이션을 위한 패턴으로 활용할 수 있습니다. 하지만 법률 및 규제적으로 특정 워크로드가 특정 클라우드 리전에 상주해야 하는 경우와 기본 클라우드 제공업체가 필수 지역에 리전을 갖고 있지 않은 경우에는 이 접근 방법을 사용할 수 없습니다.
- 특히 통신이 동시에 처리되는 경우, 서로 다른 퍼블릭 클라우드 환경에서 실행되는 시스템 간의 종속 항목을 최소화합니다. 이러한 종속 항목은 성능을 느리게 하고, 전반적인 가용성을 줄이고, 잠재적으로 추가적인 아웃바운드 데이터 전송 요금을 발생시킬 수 있습니다.
- 환경 간의 차이를 없애려면 애플리케이션에서 지원되고 가능한 경우에 컨테이너 및 Kubernetes 사용을 고려해야 합니다.
- 배포 및 모니터링을 위한 CI/CD 파이프라인과 도구가 클라우드 환경 전반에 걸쳐 일관되는지 확인합니다.
- 사용 중인 애플리케이션에 대해 가장 효과적이고 효율적인 통신 솔루션을 제공하는 최적의 네트워크 아키텍처 패턴을 선택합니다.
- 통신은 세부적으로 조정하고 제어해야 합니다. 보안 API를 사용해서 애플리케이션 구성요소를 노출합니다.
- 특정 비즈니스 및 기술적 요구사항에 따라 메시 아키텍처 패턴 또는 게이트 네트워킹 패턴 중 하나를 사용하는 것이 좋습니다.
- 가용성 및 성능 기대치를 충족시키기 위해 엔드 투 엔드 고가용성(HA), 낮은 지연 시간, 적절한 처리량 수준을 설계합니다.
민감한 정보를 보호하기 위해서는 전송 중 상태의 모든 통신을 암호화하는 것이 좋습니다.
- 연결 레이어에서 암호화가 필요한 경우 선택한 하이브리드 연결 솔루션에 따라 다양한 옵션을 사용할 수 있습니다. 이러한 옵션에는 VPN 터널, Cloud Interconnect를 통한 HA VPN, Cross-Cloud Interconnect용 MACsec이 포함됩니다.
멀티 클라우드 파티션을 나눈 아키텍처 패턴의 일부로 여러 CDN을 사용 중이고 다른 CDN에 Google Cloud의 대규모 데이터 파일을 입력하는 경우 Google Cloud와 지원되는 공급업체 사이에 CDN Interconnect 링크를 사용해서 트래픽을 최적화하고 잠재적으로 비용을 최적화하는 것이 좋습니다.
시스템이 환경 경계 간에 안전하게 인증을 수행할 수 있도록 환경 간에 ID 관리 솔루션을 확장합니다.
Google Cloud와 다른 클라우드 플랫폼 간에 요청을 효율적으로 분산하기 위해서는 Cloud Load Balancing을 사용하면 됩니다. 자세한 내용은 온프레미스 위치 또는 다른 클라우드로 트래픽 라우팅을 참조하세요.
- Google Cloud에서 다른 환경으로의 아웃바운드 데이터 전송 볼륨이 높으면 Cross-Cloud Interconnect를 사용하는 것이 좋습니다.
여러 백엔드 간에 프로토콜, API, 인증 메커니즘의 불일치 문제를 해결하기 위해서는 가능한 경우 API 게이트웨이 또는 프록시를 통합 퍼사드로 배포하는 것이 좋습니다. 이러한 게이트웨이 또는 프록시는 중앙화된 제어 지점으로 작동하며 다음과 같은 측정을 수행합니다.
- 추가 보안 측정을 구현합니다.
- 백엔드 코드 변경사항으로부터 클라이언트 앱과 기타 서비스를 보호합니다.
- 모든 교차 환경 애플리케이션과 분리된 구성요소 사이의 통신을 위한 감사 추적을 지원합니다.
- 기존 서비스와 및 현대화된 서비스 사이에 중간 통신 레이어 역할을 수행합니다.
- Apigee 및 Apigee Hybrid를 사용하면 온프레미스 환경, 에지, 기타 클라우드, Google Cloud 환경 간에 엔터프라이즈급 및 하이브리드 게이트웨이를 호스팅하고 관리할 수 있습니다.
다음과 같은 경우 API 게이트웨이와 Cloud Load Balancing을 사용해서 여러 리전 간에 대규모 API 트래픽 관리, 보안, 분산을 위한 강력한 보안 솔루션을 제공할 수 있습니다.
- 여러 다른 리전에 Apigee API 런타임을 위한 멀티 리전 장애조치 배포
Cloud CDN으로 성능 향상
Google Cloud Armor를 통해 WAF 및 DDoS 보호 제공.
가능한 경우에는 Cloud 환경 간에 로깅 및 모니터링을 위한 일관적인 도구를 사용합니다. 오픈소스 모니터링 시스템을 사용할 수도 있습니다. 자세한 내용은 하이브리드 및 멀티 클라우드 모니터링 및 로깅 패턴을 참조하세요.
단일 애플리케이션의 구성요소가 둘 이상의 클라우드 환경에 배포되는 분산 방식으로 애플리케이션 구성요소를 배포할 경우 계층형 하이브리드 아키텍처 패턴을 위한 권장사항을 참조하세요.