이 자료는 하이브리드 및 멀티 클라우드 배포, 아키텍처 패턴 및 네트워크 토폴로지에 대해 설명하는 다중 파트 시리즈 중 두 번째 부분입니다. 이 파트에서는 일반적인 하이브리드 및 멀티 클라우드 아키텍처 패턴을 살펴봅니다. 이 문서에서는 이러한 패턴이 가장 적합한 시나리오와 Google Cloud를 사용하여 이를 구현하기 위한 권장사항을 설명합니다.
시리즈는 다음 세 부분으로 구성됩니다.
- 하이브리드 및 멀티 클라우드 패턴과 권장사항
- 하이브리드 및 멀티 클라우드 아키텍처 패턴(이 문서)
- 하이브리드 및 멀티 클라우드 네트워크 토폴로지
모든 기업은 고유한 애플리케이션 워크로드 포트폴리오를 통해 하이브리드 또는 멀티 클라우드 설정의 아키텍처에 대한 요구사항과 제약 조건을 관리합니다. 이러한 제약 조건 및 요구 사항을 충족하도록 아키텍처를 설계하고 맞춤화해야 하지만 몇 가지 일반적인 패턴에 의존할 수 있습니다.
패턴은 2가지 범주로 나뉩니다.
애플리케이션의 분산 배포를 사용하는 패턴입니다. 이러한 패턴의 목적은 컴퓨팅 환경의 다양한 속성과 특성을 활용하여 가장 적합한 애플리케이션을 컴퓨팅 환경에서 실행하는 것입니다.
애플리케이션의 중복 배포를 기반으로 하는 패턴입니다. 이러한 패턴에서는 용량 또는 복원력을 증가시키기 위해 동일한 애플리케이션을 여러 컴퓨팅 환경에 배포합니다.
분산 배포 패턴
기본 컴퓨팅 환경에서 하이브리드 또는 멀티 클라우드 설정으로 마이그레이션하는 경우 기존 애플리케이션에 적용되는 제약 조건을 고려해야 합니다. 또한 각 컴퓨팅 환경에서 제공하는 고유한 기능을 활용하고자 할 것입니다. 이러한 분산형 패턴은 두 목표 사이의 신중한 균형을 맞추는 것을 목적으로 합니다.
단계식 하이브리드
대부분의 애플리케이션은 프런트엔드 또는 백엔드로 분류할 수 있습니다.
프런트엔드 애플리케이션은 최종 사용자 또는 기기에 직접 노출됩니다. 따라서 이러한 애플리케이션은 성능에 민감하며 새로운 기능과 개선 사항이 개발됨에 따라 자주 출시될 수 있습니다. 프런트엔드 애플리케이션은 대체로 데이터를 저장 및 관리하는 백엔드 애플리케이션을 사용하므로, 프런트엔드 애플리케이션에서는 상태 정보를 저장하지 않거나 소량의 데이터만 관리합니다.
백엔드 애플리케이션은 일반적으로 데이터 관리에 초점을 맞춥니다. 이러한 애플리케이션의 주요 당면 과제로는 볼륨 내 데이터 처리 및 적절한 보호가 포함됩니다. 새로운 백엔드 애플리케이션 출시는 프런트엔드 애플리케이션보다 빈도가 낮은 경향이 있습니다.
단계식 하이브리드 패턴은 먼저 기존 프런트엔드 애플리케이션을 퍼블릭 클라우드에 배포하는 데 초점을 맞춘 개념입니다. 이 패턴에서는 비공개 컴퓨팅 환경에 남아 있는 기존 백엔드 애플리케이션을 재사용합니다. 프런트엔드 애플리케이션을 케이스별로 마이그레이션합니다.
다음 다이어그램은 전형적인 단계식 하이브리드 패턴을 보여 줍니다.
시간이 지남에 따라 클라우드에 배포하는 애플리케이션의 일부가 증가하여 백엔드 애플리케이션을 퍼블릭 클라우드로 이동할 수도 있습니다.
장점
프런트엔드 애플리케이션에 초점을 맞추면 다음과 같은 몇 가지 이점이 있습니다.
프런트엔드 애플리케이션은 백엔드와 다른 프런트엔드에 따라 다르지만, 백엔드는 프런트엔드에 의존하지 않습니다. 따라서 프런트엔드 애플리케이션을 격리 및 이전하는 것은 복잡한 종속 항목을 가질 수 있는 백엔드 애플리케이션을 이전하는 것보다 덜 복잡할 수 있습니다.
프런트엔드 애플리케이션은 종종 상태 정보를 저장하지 않거나 자체적으로 데이터를 관리하지 않으므로, 이전이 덜 까다로울 수 있습니다.
기존 또는 새롭게 개발된 프런트엔드 애플리케이션을 퍼블릭 클라우드에 배포하면 다음과 같은 몇 가지 주요 이점이 있습니다.
많은 프런트엔드 애플리케이션은 자주 변경될 수 있습니다. 퍼블릭 클라우드에서 이러한 애플리케이션을 실행하면 효율적이고 자동화된 방식으로 업데이트를 배포하는 데 사용할 수 있는 지속적 통합/지속적 배포(CI/CD) 프로세스 설정이 간소화됩니다.
성능에 민감한 프런트엔드와 빈번하게 변경될 수 있는 프런트엔드는 클라우드 배포를 사용 설정하는 부하 분산, 다중 지역 배포 및 자동 확장 기능의 이점을 크게 누릴 수 있습니다.
사용자 인터페이스나 API 구현 여부 또는 IoT(사물 인터넷) 데이터 수집 여부에 관계없이 프런트엔드 애플리케이션은 Firebase, Cloud CDN 또는 Cloud IoT와 같은 클라우드 서비스에서 제공되는 이점을 누릴 수 있습니다.
백엔드에서 규제 또는 사법적 제한 사항이 적용되는 데이터를 관리하는 경우, 규제 내에서 작업할 방법을 찾을 때까지 데이터를 영구적으로 또는 최소한 비공개 컴퓨팅 환경에 유지해야 할 수 있습니다.
또한 비공개 컴퓨팅 환경에서 프런트엔드를 유지하면서 클라우드에 백엔드를 구축하는 것이 일반적이지는 않지만 단계식 하이브리드 패턴을 적용할 수도 있습니다. 이러한 접근 방식은 무게감 있고 단일화된 프런트엔드를 다룰 때 가장 적합합니다. 이러한 경우 백엔드 기능을 반복적으로 추출하고 클라우드에 이러한 새로운 백엔드를 구축하는 것이 더 쉬울 수 있습니다.
권장사항
단계식 하이브리드 패턴을 적용하는 경우에는 다음 방법을 고려합니다.
gated egress 또는 meshed 토폴로지를 사용합니다. 대부분의 사용자 상호작용은 여러 컴퓨팅 환경에 연결된 시스템에서 이루어지기 때문에 이러한 시스템 간에 지연 시간이 짧고 빠른 연결성이 중요합니다. 따라서 고가용성, 짧은 지연 시간, 적절한 처리량 수준을 설계하는 것이 중요합니다.
환경 간의 통신 지연 시간을 최소화하려면 지리적으로 비공개 컴퓨팅 환경과 가까운 Google Cloud 리전과 상호 연결 위치를 선택합니다.
단계식 하이브리드 설정에서는 일반적으로 Google Cloud에서 비공개 컴퓨팅 환경(이그레스)으로 이전하는 것보다 Google Cloud(인그레스)로 들어오는 데이터가 많습니다. 하지만 Google Cloud에서 송신되는 트래픽에는 이그레스 가격이 적용됩니다. Dedicated Interconnect 또는 다이렉트 피어링을 사용하면 청구 요금을 줄일 수 있습니다.
환경 간의 통신이 단방향인지 확인합니다. 퍼블릭 클라우드에서 실행 중인 프런트엔드 애플리케이션은 비공개 컴퓨팅 환경에서 실행되는 백엔드와 통신할 수 있지만 그 반대로는 불가능합니다.
환경 간에 교환되는 데이터가 중요할 수 있으므로, 가상 사설망(VPN) 터널, 전송 계층 보안(TLS) 또는 두 가지 모두를 사용하여 모든 통신을 암호화해야 합니다.
특히 프로토콜, API, 인증 메커니즘이 백엔드에서 일관되지 않는 경우에는 기존 백엔드 서비스의 일부로 API 게이트웨이를 배포하는 것이 좋습니다. API 게이트웨이는 통합 레이어 역할을 할 뿐만 아니라 초크 포인트 역할도 할 수 있습니다. 이 게이트웨이를 사용하면 모든 교차 환경 통신에 적용되는 추가 보안 및 감사 수단을 구현할 수 있습니다.
환경 경계에서 시스템을 안전하게 인증할 수 있도록 환경 간에 일반 ID를 설정합니다.
개별 워크로드의 경우, 다음과 같은 추가 권장사항을 고려합니다.
비록 이 패턴의 프런트엔드 애플리케이션에 초점이 맞춰져 있지만, 백엔드 애플리케이션을 최신화해야 함을 인식해야 합니다. 백엔드의 개발 속도가 프런트엔드의 개발 속도보다 상당히 느린 경우, 이 차이로 인해 프로젝트에 추가적인 복잡성이 발생할 수 있습니다.
변환 및 이동 마이그레이션을 사용하려면 Google Cloud와 비공개 컴퓨팅 환경 간의 공통 런타임 레이어로 Kubernetes를 사용합니다. Kubernetes를 사용하면 워크로드를 현대화하고 서로 다른 시간에 Google Cloud로 마이그레이션할 수 있으므로 워크로드가 다른 워크로드에 크게 의존하고 개별적으로 마이그레이션될 수 없는 경우에 유용합니다.
환경 간의 양방향 통신이 필요하지 않습니다. 이를 위해서는 퍼블릭 클라우드에 CI/CD 시스템 배포도 고려합니다.
단계식 하이브리드 시나리오에서는 이러한 환경에서 일관된 도구와 CI/CD 프로세스를 사용하면 운영 효율성을 높일 수 있습니다. 필수적으로 따라야 하는 것은 아닙니다.
프런트엔드 작업 부하를 실행하기 위해 Kubernetes를 사용하는 경우, 선택기가 없는 서비스를 사용하여 비공개 컴퓨팅 환경에서 실행 중인 모든 서비스 또는 API 게이트웨이를 검색할 수 있습니다. Kubernetes 스터브 도메인을 사용하여 Consul과 같은 외부 DNS 기반 서비스 검색 시스템과 통합할 수 있습니다.
분할 멀티 클라우드
분할 멀티 클라우드 패턴은 여러 공급업체에서 운영하는 여러 퍼블릭 클라우드 환경을 통합하여 최적의 컴퓨팅 환경에서 애플리케이션을 유연하게 구현할 수 있습니다. 다음 다이어그램은 전형적인 분할 멀티 클라우드 패턴을 보여 줍니다.
필요에 따라 워크로드를 퍼블릭 클라우드 환경에서 다른 환경으로 이동할 수 있는 기능을 유지할 수 있습니다. 이 경우 워크로드 이동성이 주요 요구사항이 됩니다. 워크로드를 여러 컴퓨팅 환경에 배포하고 환경 간에 워크로드를 이동하는 기능을 유지하려면 환경 간의 차이를 추상화해야 합니다.
Google Cloud는 다양한 방식으로 워크로드를 배포하는 데 사용할 수 있는 다양한 서비스를 제공합니다. 하지만 어떤 경우에는 Google Cloud를 다른 클라우드 제공업체와 결합하여 클라우드 환경 간에 워크로드를 분할하는 것이 좋습니다. 예시
단일 공급업체로의 커밋을 방지하려면 여러 클라우드 제공업체에 애플리케이션을 분산해야 합니다.
규제상의 이유로, 사용자는 Google Cloud가 아직 존재하지 않는 국가의 특정 사용자층 분류 기준 및 데이터를 처리합니다.
여러 클라우드 제공업체에 애플리케이션을 배포하여 제공업체가 제공하는 최고 서비스 중 하나를 선택할 수 있습니다.
장점
다음은 분할 멀티 클라우드 패턴의 몇 가지 주요 이점입니다.
공급업체에 종속되지 않도록 할 수 있습니다. 이러한 패턴은 전략적 위험을 줄이는 데 유용하며 나중에 계획 또는 파트너 관계를 변경할 수 있는 유연성을 제공합니다.
워크로드를 이동할 수 있으면 컴퓨팅 환경 간에 워크로드를 이동하여 운영을 최적화할 수 있습니다.
권장사항
분할 멀티 클라우드 설정의 전략적 이점을 이 설정이 제공하는 추가적인 복잡성과 비교합니다. 여러 클라우드 환경에서 워크로드 이동성과 일관된 도구 사용을 달성하면 개발, 테스트 및 운영 작업이 향상됩니다.
중요 업무용 워크로드에 대해서만 또는 법률 또는 규정상의 이유로 단일 퍼블릭 클라우드 환경이 워크로드를 수용할 수 없는 경우에만 멀티 클라우드 환경을 사용합니다.
특히 통신이 동시에 처리되는 경우, 서로 다른 퍼블릭 클라우드 환경에서 실행되는 시스템 간의 종속 항목을 최소화합니다. 이러한 종속 항목으로 인해 성능과 전반적인 가용성이 저하될 수 있습니다.
환경 간의 차이를 없애려면 컨테이너와 Kubernetes 사용을 고려합니다.
배포 및 모니터링을 위한 CI/CD 프로세스와 도구가 클라우드 환경 전반에 걸쳐 일관되는지 확인합니다.
환경 간에 교환되는 데이터가 민감한 데이터일 수 있으므로 VPN 터널이나 TLS 또는 둘 다 사용하여 모든 통신이 암호화되도록 해야 합니다.
환경 경계에서 시스템을 안전하게 인증할 수 있도록 환경 간에 일반 ID를 설정합니다.
Kubernets를 사용하는 경우, 컴퓨팅 환경에서 DNS 이름으로 검색 가능한 서비스를 만들기 위해 ExternalDNS 사용을 고려합니다.
Anycast IP 기반 Google Cloud 부하 분산기를 사용하여 여러 Google Cloud 리전에 걸쳐 요청을 분산할 수 있지만 여러 클라우드에 사용자 요청을 배포할 수는 없습니다. 이 배포를 위해 라운드 로빈 또는 Geo DNS를 사용해야 합니다. 예를 들어 NS1, Orafle®, Akamai를 사용할 수 있습니다.
분석 하이브리드 및 멀티 클라우드
엔터프라이즈 시스템에서 대부분의 워크로드는 다음과 같은 범주로 분류됩니다.
트랜잭션 워크로드에는 영업, 재무 처리, 엔터프라이즈 리소스 계획 또는 통신과 같은 대화형 애플리케이션이 포함됩니다.
분석 워크로드에는 데이터를 변환, 분석, 상세검색 또는 시각화하여 의사결정 프로세스를 지원하는 애플리케이션이 포함됩니다.
분석 시스템은 API를 쿼리하거나 데이터베이스에 액세스하여 트랜잭션 시스템에서 데이터를 얻지만, 대부분의 기업에서 분석 및 트랜잭션 시스템은 분리되어 느슨하게 결합되는 경향이 있습니다. 분석 하이브리드 및 멀티 클라우드 패턴의 개념은 2가지 컴퓨팅 환경에서 두 종류의 워크로드를 실행하여 기존의 이러한 분할을 활용하는 것입니다. 원시 데이터는 비공개 컴퓨팅 환경에서 실행 중인 워크로드에서 추출된 다음 분석 처리에 사용되는 Google Cloud에 로드됩니다. 일부 결과는 트랜잭션 시스템에 다시 공급될 수 있습니다.
장점
클라우드에서 분석 워크로드를 실행하면 다음과 같은 몇 가지 주요 이점이 있습니다.
분석워크로드는 상당한 양의 데이터를 처리해야 하는 경우가 많고 데이터가 급증할 수 있으므로, 특히 퍼블릭 클라우드 환경에 배포하기에 적합합니다. 컴퓨팅 리소스를 동적으로 확장하여 대규모 데이터세트를 신속하게 처리할 수 있으며 초기 투자를 하거나 컴퓨팅 장비를 오버프로비저닝할 필요가 없습니다.
Google Cloud는 초기 구입부터 처리 및 분석, 최종 시각화까지 전체 수명 주기 동안 데이터를 관리할 수 있는 다양한 서비스를 제공합니다.
Cloud Storage는 데이터 레이크를 빌드하는 데 매우 적합합니다.
비공개 컴퓨팅 환경에서 Google Cloud로 데이터를 이동하는 인그레스 트래픽은 무료입니다.
권장사항
분석 하이브리드/다중 클라우드 패턴을 구현하려면 다음 권장사항을 고려합니다.
handover 토폴로지를 사용하여 내부 데이터화를 사용 설정합니다. 분석 결과를 트랜잭션 시스템에 다시 제공해야 하는 경우, 핸드오버 및 gated egress 토폴로지를 결합합니다.
Pub/Sub 큐 또는 Cloud Storage 버킷을 사용하여 비공개 컴퓨팅 환경에서 실행 중인 트랜잭션 시스템에서 Google Cloud로 데이터를 전송합니다. 이러한 큐 또는 버킷이 데이터 처리 파이프라인과 워크로드의 소스로 사용될 수 있습니다.
기존 Hadoop 또는 Spark 워크로드가 있는 경우, 작업을 Dataproc으로 마이그레이션하고 기존 HDFS 데이터를 Cloud Storage로 마이그레이션하는 것을 고려합니다.
비공개 컴퓨팅 환경에서 Google Cloud로 초기 데이터 전송을 수행하는 경우 데이터 세트 크기 및 사용 가능한 대역폭에 가장 적합한 전송 방식을 선택합니다.
여러 환경에서 일관된 도구와 프로세스를 사용합니다. 분석 하이브리드 시나리오에서는 이러한 관행이 선행 조건은 아니지만 운영 효율성을 높일 수 있습니다.
에지 하이브리드
클라우드에서 워크로드를 실행하려면 클라이언트의 경우 신속하고 안정적인 인터넷 연결이 보장되어야 합니다. 현재의 네트워크를 고려하면, 이러한 요구사항은 클라우드 채택에 있어 거의 문제가 되지 않습니다. 그러나 지속적인 연결을 사용할 수 없는 시나리오가 있습니다.
해상 선박과 기타 차량은 간헐적으로 연결되거나 지연 시간이 긴 위성 링크에만 액세스할 수 있습니다.
공장이나 발전소가 인터넷에 연결되어 있을 수 있습니다. 이러한 시설에는 링크의 가용성 보장을 초과하는 안정성 요구사항이 있을 수 있습니다.
상점이나 슈퍼마켓은 필요할 때만 가끔 연결되거나 업무상 중요한 거래를 처리하는 데 필요한 안정성 또는 처리량을 제공하지 않는 링크를 사용할 수 있습니다.
에지 하이브리드 패턴은 시간 및 업무상 중요한 워크로드를 네트워크의 에지에서 로컬로 실행하는 동시에 다른 모든 워크로드에 클라우드를 사용하여 이러한 문제를 해결합니다. 에지 하이브리드 설정에서 인터넷 링크는 종종 비동기식으로 관리 목적으로 사용되며 시간 및 업무상 중요한 트랜잭션에는 포함되지 않는 비임계 구성요소입니다.
장점
에지와 클라우드에서 서로 다른 워크로드를 실행하면 다음과 같은 몇 가지 이점이 있습니다.
시간 및 업무상 중요한 워크로드를 에지에서 실행하면 지연 시간이 단축되고 자가 효율성이 향상됩니다. 인터넷 연결이 실패하거나 인터넷 연결을 일시적으로 사용할 수 없는 경우에도 모든 중요 트랜잭션을 계속 실행할 수 있습니다. 동시에 전체 워크로드의 상당 부분에 클라우드를 사용함으로써 이점을 얻을 수 있습니다.
컴퓨팅 및 스토리지 장비에 대한 기존 투자를 재사용할 수 있습니다.
시간이 지남에 따라 특정 애플리케이션을 다시 작동하거나 일부 에지 위치에 더욱 안전한 인터넷 링크를 장착하여 에지에서 실행되는 워크로드의 비율을 점차적으로 줄일 수 있습니다.
에지에서 Google Cloud로 데이터를 이전하는 인그레스 트래픽은 무료입니다.
권장사항
에지 하이브리드 패턴을 구현하는 경우에는 다음 권장사항을 고려합니다.
통신이 단방향인 경우, gated ingress 토폴로지를 사용합니다. 양방향 통신인 경우에는 gated ingress 및 egress 토폴로지를 고려합니다.
에지에서 실행 중인 시스템과 클라우드 환경에서 실행 중인 시스템 간의 종속 항목을 최소화합니다. 각 종속 항목은 에지 하이브리드 설정의 안정성과 지연 시간 이점을 약화시킬 수 있습니다.
여러 에지 위치를 효율적으로 관리 및 운영하려면 클라우드에 중앙 집중식 제어 기준면이 있어야 합니다.
클라우드와 에지 환경에서 배포 및 모니터링용 도구와 CI/CD 프로세스가 일관성을 갖는지 확인합니다.
다양한 에지 위치 및 에지 위치와 클라우드 간의 차이를 없애기 위해 컨테이너와 Kubernetes 사용을 고려합니다. Kubernets는 공통 런타임 레이어를 제공하므로, 컴퓨팅 환경에서 작업 부하를 지속적으로 개발, 실행, 운영하고 에지와 클라우드 간에 작업 부하를 이동할 수 있습니다.
환경 경계에서 시스템을 안전하게 인증할 수 있도록 환경 간에 일반 ID를 설정합니다.
환경 간에 교환되는 데이터가 중요할 수 있으므로, VPN 터널, TLS 또는 모두 사용하여 모든 통신이 암호화되었는지 확인합니다.
중복 배포 패턴
다음 섹션에서는 여러 컴퓨팅 환경에 걸쳐 애플리케이션을 이중으로 구축하는 데 필요한 일반적인 패턴을 살펴봅니다. 이러한 패턴에서는 용량 또는 복원력을 높이기 위해 동일한 애플리케이션을 여러 컴퓨팅 환경에 배포합니다
환경 하이브리드
환경 하이브리드 패턴의 개념은 기존 데이터 센터에 워크로드의 프로덕션 환경을 유지하면서도 다른 비프로덕션 환경에 퍼블릭 클라우드를 사용하는 것입니다.
이전할 워크로드를 평가하는 경우, 퍼블릭 클라우드에서 특정 애플리케이션을 실행하면 다음과 같은 문제가 발생할 수 있습니다.
- 관할 구역 또는 규제 사항에 따라 특정 국가에 데이터를 보관해야 할 수 있습니다.
- 타사 라이선스 조건에 따라 클라우드 환경에서 특정 소프트웨어가 작동하지 않을 수 있습니다.
- 애플리케이션은 이동 중인 워크로드와 마찬가지로 로컬에서만 사용할 수 있는 하드웨어 기기에 액세스해야 할 수 있습니다.
이 경우, 프로덕션 환경뿐만 아니라 개발, 테스트 및 스테이징 시스템을 포함하여 애플리케이션의 수명 주기와 관련된 모든 환경을 고려합니다. 클라우드 마이그레이션을 어렵게 만드는 제한사항은 프로덕션 환경과 해당 데이터에는 적용되지만 다른 환경에서는 적용되지 않습니다.
다음 다이어그램은 전형적인 환경 하이브리드 패턴을 보여 줍니다.
프로덕션 시스템과 다른 환경에서 개발 및 테스트 시스템을 실행하는 것은 위험해 보일 수 있으며 기존 권장사항 또는 이러한 환경 간의 차이를 최소화하려는 시도와 상충됩니다. 이러한 우려가 틀리지는 않지만, 개발 및 테스트 프로세스의 단계를 구분하는 경우에는 적용되지 않습니다.
개발, 테스트, 배포 프로세스는 애플리케이션마다 다르지만 일반적으로 다음과 같은 단계의 변화를 수반합니다.
- 개발: 출시 후보 생성
- 기능 테스트 또는 사용자 승인 테스트: 출시 후보가 기능 요구 사항을 충족하는지 확인
- 성능 및 안정성 테스트: 출시 후보가 비작동 요구 사항을 충족하는지 확인
- 스테이징 또는 배포 테스트: 배포 절차가 작동하는지 확인
- 프로덕션
실질적으로 단일 환경에서는 이러한 단계를 두 개 이상 수행할 수 없으므로 일반적으로 각 단계에 전용 환경이 하나 이상 있어야 합니다.
테스트 결과가 의미 있고 운영 배포에 적용되도록 하려면 애플리케이션 수명 주기 동안 사용하는 환경이 가능한 한 다음 규칙을 충족해야 합니다.
모든 환경은 기능적으로 동일합니다. 즉, 아키텍처, API, 운영 체제와 라이브러리 버전은 동일하며, 시스템은 환경 전체에서 동일하게 작동합니다. 이러한 동일성은 애플리케이션이 한 환경에서 작동하지만 다른 환경에서 실패하거나 결함이 재현되지 않는 상황을 방지합니다.
성능 및 안정성 테스트, 스테이징, 프로덕션에 사용되는 환경은 비기능적으로 동등합니다. 즉, 성능, 규모, 구성, 운영 및 유지관리되는 방식은 동일하거나 약간의 방식의 차이만 존재합니다. 그렇지 않으면 성능 및 스테이징 테스트가 무의미해집니다.
특히 개발 및 기능 테스트에 사용되는 환경이 다른 환경과 기능적으로 다를 경우에는 문제가 없습니다. 이 상황은 환경 하이브리드 패턴과 잘 맞습니다.
Kubernets를 공통 런타임 레이어로 사용하여 워크로드 이동성을 보장하고 컴퓨팅 환경 간의 차이를 제거하여 모든 환경에서 기능적 동일성을 확보합니다.
비공개 컴퓨팅 환경에서 프로덕션, 스테이징, 성능 및 안정성 테스트를 위한 환경을 실행하여 기능 및 비기능적 동일성을 보장합니다.
퍼블릭 클라우드에서 개발 및 기능 테스트 환경을 실행합니다. 이러한 환경은 나머지 환경과 기능적으로 동일하지만 성능과 같은 비기능적인 측면은 다를 수 있습니다.
장점
퍼블릭 클라우드에서 개발 및 기능 테스트 워크로드를 실행하면 다음과 같은 몇 가지 이점이 있습니다.
필요에 따라 환경을 자동으로 회전하거나 분해할 수 있습니다. 예를 들어 커밋 또는 가져오기 요청마다 전체 환경을 프로비저닝하고 테스트를 실행한 후 다시 분해할 수 있습니다.
개발 및 테스트 환경은 종종 간헐적으로 사용됩니다. 사용하지 않는 동안 가상 머신(VM) 인스턴스를 중지하거나 요청 시에만 환경을 프로비저닝하여 비용을 줄일 수 있습니다.
퍼블릭 클라우드에서 이러한 환경을 실행하면 클라우드 및 관련 도구에 대한 친숙성과 신뢰도가 높아지므로 다른 워크로드를 이전할 수 있습니다.
권장사항
환경 패턴을 성공적으로 구현하려면 다음 권장사항을 고려합니다.
미러링된 토폴로지를 사용하여 서로 다른 환경의 시스템이 서로 통신할 수 없도록 합니다. 시스템은 환경 간에서 통신할 필요가 없으므로, 일반 ID를 설정할 필요가 없습니다.
작업 부하를 이동 가능하게 하고 환경 간의 차이를 없애려면 컨테이너와 Kubernets를 사용합니다. 하지만 작업 부하 이동성의 한계를 알고 있어야 합니다.
CI/CD 프로세스가 컴퓨팅 환경 전반에 걸쳐 일관t성이 있는지, 정확하게 동일한 바이너리, 패키지 또는 컨테이너 세트가 다양한 환경에 배포되는지를 확인합니다.
워크로드를 배포, 구성, 운영하려면 컴퓨팅 환경에서 작동하는 공통 도구 체인을 설정해야 합니다. Kubernets를 사용하면 이러한 일관성을 유지할 수 있지만, 서로 다른 컴퓨팅 환경에서 실행 중인 클러스터에 연결하거나 인증하는 방법은 약간씩 다를 수 있습니다.
Kubernets를 사용하는 경우, Jenkins와 같은 CI 시스템을 사용하여 여러 환경에서 클러스터에 배포하고 작동하는 배포 파이프라인을 구현합니다. 또한 Google Kubernetes Engine(GKE)에서 Jenkins 자체를 실행할 수도 있습니다.
Google Cloud 및 기존 클라우드 환경에서 동일한 도구를 사용하여 로깅 및 모니터링합니다. Prometheus와 같은 오픈소스 모니터링 시스템 사용을 고려합니다. 서로 다른 팀이 테스트 및 운영 워크로드를 관리하는 경우, 동일한 도구를 사용하면 교육 효과와 복잡성이 줄어들 수 있지만 별도의 도구를 사용하는 것도 허용될 수 있습니다.
데이터베이스, 스토리지 및 메시지 서비스를 선택하는 경우 Google Cloud에서 동등하게 관리되는 제품을 사용합니다. 관리형 서비스를 사용하면 개발 및 테스트 환경을 유지하는 관리 작업이 줄어들 수 있습니다.
다음 표에서는 일반적인 OSS 제품과 호환되는 Google Cloud 제품을 보여줍니다.
| OSS 제품 | Google Cloud 제품과 호환 가능 |
|---|---|
| Apache HBase | Cloud Bigtable |
| Apache Beam | Dataflow |
| Apache Hadoop | Dataproc |
| MySQL, PostgreSQL | Cloud SQL |
| Redis | Memorystore |
| 네트워크 파일 시스템(NFS) | Filestore |
| JMS, Kafka | Pub/Sub |
비즈니스 연속성 하이브리드 및 멀티 클라우드
이상적으로는 업무 핵심 시스템이 재해 발생 시 복원력을 발휘하도록 설정되어 있습니다. 여러 리전에 걸쳐 시스템 및 데이터를 복제하고 단일 장애점을 방지함으로써 로컬 인프라에 영향을 미치는 자연 재해의 위험을 최소화할 수 있습니다. 그러나 이 방법은 사용자 오류나 소프트웨어 결함으로 인해 운영 중단 위험을 해결하지 못합니다. 따라서 다른 종류의 재해가 발생할 경우 최소한의 데이터 손실로 허용 가능한 제한 시간 내에 시스템을 복구할 수 있도록 재해 복구(DR) 계획을 세우는 것이 중요합니다.
DR 계획의 핵심은 데이터를 다른 지리적 위치에 자주 백업하여 복구 지점 목표(RPO)를 최소화하는 것입니다. 또한 두 번째 위치에 콜드, 웜 또는 상시 대기 시스템을 유지하면 복구 시간 목표(RTO)가 최소화될 수 있습니다.
중앙 데이터 센터에서 중요 작업용 시스템을 실행할 때 DR의 한 가지 접근 방식은 다른 리전에 위치한 보조 데이터 센터에서 대기 시스템을 유지하는 것입니다. 그러나 보다 비용 효율적인 접근 방식은 장애 조치를 위해 퍼블릭 클라우드 기반 컴퓨팅 환경을 사용하는 것이며 이것이 비즈니스 연속성 하이브리드 패턴의 이면입니다.
이러한 패턴을 보다 덜 흔하면서 필수로 요구되는 경우가 적은 방식으로 변형한 패턴이, 프로덕션 환경에서 하나의 클라우드 제공자를 사용하고 DR 환경에서 다른 클라우드 제공자를 사용하는 비즈니스 연속성 다중 클라우드 패턴입니다. 여러 클라우드 공급업체 전반에 걸쳐 워크로드 복사본을 배포하면 멀티 리전 배포에서 제공하는 것보다 가용성을 높일 수 있습니다.
장점
비즈니스 연속성을 위해 공용 클라우드를 사용하면 다음과 같은 다양한 이점을 얻을 수 있습니다.
Google Cloud에서는 선택할 리전이 12개 이상 있으므로, 이를 통해 동일한 대륙 내 다른 사이트나 다른 대륙의 사이트에도 데이터를 백업 또는 복제할 수 있습니다.
중지된 VM 인스턴스는 스토리지 비용만 발생시키며 실행 중인 VM 인스턴스보다 매우 저렴하므로, 수동 대기 시스템 유지 비용을 최소화할 수 있습니다.
Google Cloud의 종량제 모델을 사용하면 실제로 사용하는 스토리지 및 컴퓨팅 용량에 대해서만 비용을 지불할 수 있으며, 필요에 따라 DR 환경을 늘리거나 줄일 수 있습니다.
권장사항
비즈니스 연속성 패턴을 사용하는 경우, 다음 권장사항을 고려합니다.
장애 조치 및 복구 절차와 함께 인프라를 문서화하는 재해 복구 계획을 만듭니다.
RPO 및 RTO에 따라 Google Cloud에 데이터를 백업하기에 충분한지 또는 콜드, 웜, 상시 대기 시스템을 유지해야 하는지 여부를 결정합니다. Google Cloud에 구현하는 일반적인 시나리오와 조언은 재해 복구 계획 가이드를 참조하세요.
데이터 백업만 수행하는 경우에는 handover 토폴로지를 사용합니다. 그렇지 않으면, mirrored 토폴로지를 고려합니다.
특히 통신이 동시에 처리되는 경우, 서로 다른 환경에서 실행되는 시스템 간 종속 항목을 최소화합니다. 이러한 종속 항목으로 인해 성능과 전반적인 가용성이 저하될 수 있습니다.
여러 환경에서 양방향으로 데이터를 복제하는 경우, 분할 브레인 문제에 노출될 수 있습니다. 이 문제를 설명하자면, 두 환경 간의 통신이 끊기는 경우에 양측의 시스템 모두 상대측 환경이 사용할 수 없게 된 것으로 판단할 수 있습니다. 두 시스템은 저마다 데이터에 대한 배타적 액세스 권한이 있다고 결론 내리고, 궁극적으로 상호 충돌하는 수정을 할 수도 있습니다. 이러한 분열을 방지하는 한 가지 방법은 세 번째 컴퓨팅 환경을 추가하는 것입니다. 이 방법을 사용하면 데이터 복제를 사용하는 시스템은 데이터 수정이 안전할 것인지 결정하기 전에 쿼럼을 확인할 수 있습니다. 또는 연결이 복원된 후 충돌하는 데이터 수정이 조정되도록 허용할 수 있습니다.
CI/CD 시스템 및 아티팩트 저장소가 단일 장애 지점이 되지 않도록 합니다. 환경 하나를 사용할 수 없는 경우에도 새 출시를 배포하거나 구성 변경사항을 계속 적용할 수 있어야 합니다.
환경 간에 교환되는 데이터가 민감한 데이터일 수 있으므로 VPN 터널이나 TLS 또는 둘 다 사용하여 모든 통신이 암호화되도록 해야 합니다.
대기 시스템을 사용하는 경우에는 여러 환경에서 시스템이 일관성을 갖도록 워크로드가 이동할 수 있어야 합니다. 컨테이너와 Kubernets 사용을 고려합니다.
대기 시스템 배포를 CI/CD 프로세스에 통합합니다. 이러한 통합을 통해 애플리케이션 버전과 구성이 여러 환경에서 일관성을 유지할 수 있습니다.
핫 대기 시스템을 사용하는 경우에는 부하 분산기를 사용하여 자동 장애 조치를 생성하지만 부하 분산기도 실패할 수 있다는 점에 유의하세요. 예방 조치로, 재해 발생 시 사용자를 대기 시스템으로 다시 라우팅할 수 있도록 DNS를 구성합니다. 상당히 짧은 TTL을 사용하여 DNS 변경사항이 신속하게 전파되고 Cloud DNS가 제공하는 100% 업타임 SLA를 사용하도록 합니다.
클라우드 버스팅
인터넷 애플리케이션, 특히 사용자를 대상으로 하는 애플리케이션은 사용량이 급격하게 변동될 수 있습니다. 대부분의 엔터프라이즈 애플리케이션은 이러한 문제를 겪지 않지만, 대부분의 기업에서는 다른 종류의 급격히 증가한 워크로드에 해당하는 배치 또는 CI/CD 작업을 처리해야 합니다.
리소스 초과 프로비저닝을 통해 기본 데이터 센터 기반 컴퓨팅 환경에서 급격히 증가하는 워크로드를 수용할 수 있지만 이 방식은 비용 면에서 효율적이지는 않습니다. 배치 작업의 경우, 시간에 민감한 작업에서는 지연을 활용하는 것이 쉽지는 않지만 장시간 동안 실행을 연장하여 활용률을 최적화할 수 있습니다.
클라우드 버스트 패턴의 개념은 기본 부하에 비공개 컴퓨팅 환경을 사용하고 추가 용량이 필요할 때 일시적으로 클라우드로 전환하는 것입니다.
클라우드 버스팅 시나리오의 핵심 요구사항은 워크로드 이동성입니다. 워크로드를 여러 환경에 배포하는 것을 허용할 때는 환경 간의 차이를 없애야 합니다.
클라우드 버스팅 패턴은 대화형 워크로드와 배치 워크로드에 적용됩니다. 그러나 대화형 워크로드를 처리하는 경우에는 환경 간에 요청을 배포하는 방법을 결정해야 합니다.
유입되는 사용자 요청을 기존 데이터 센터에서 실행되는 부하 분산기로 라우팅한 후 부하 분산기가 요청을 로컬 및 클라우드 리소스에 배포하도록 할 수 있습니다. 이 방법을 사용하려면 기존 데이터 센터에서 실행 중인 부하 분산기 또는 다른 시스템이 클라우드에 할당된 리소스를 추적하고 리소스의 자동 확장 또는 축소 작업을 시작해야 합니다.
한편 이 방법을 사용하면 활동이 적은 시간에 모든 클라우드 리소스를 사용 해제할 수 있습니다. 반면 리소스를 추적하기 위한 메커니즘을 구현하는 것은 기성 부하 분산기 솔루션의 기능을 초과할 수 있으므로 전반적인 복잡성이 증가할 수 있습니다.
또는 먼저 Google Cloud로 요청을 라우팅한 다음 여러 환경에 배포할 수 있습니다. Google Cloud 부하 분산기는 Google Cloud 리소스 간 분산 및 자동 확장을 지원하므로, Google Cloud 부하 분산기를 추가적인 커스텀 부하 분산 메커니즘과 결합하여 요청 배포를 촉진해야 합니다. 이러한 방법은 추가적인 복잡성을 초래합니다.
요청이 적을 때 Google Cloud의 모든 리소스를 종료하려는 경우 순차 순환 DNS를 사용하여 부하 분산을 실행하는 것은 실용적이지 않습니다. DNS 업데이트는 느리게 전파되는 경향이 있으므로 부하 분산에 DNS를 사용하면 요청을 처리할 수 있는 리소스가 없을 때 사용자가 Google Cloud로 라우팅될 위험이 있습니다.
이러한 어려움을 고려할 때 클라우드 버스팅은 대개 대화형 워크로드보다 일괄 워크로드에 더 적합합니다.
장점
이 아키텍처 패턴의 주요 이점은 다음과 같습니다.
클라우드 버스팅을 통해 데이터 센터 및 비공개 컴퓨팅 환경에 대한 기존 투자를 재사용할 수 있습니다. 재사용은 영구적으로 가능하거나 기존 장비가 교체될 때까지 유효할 수 있으며, 장비 교체 시점이 되면 전체 클라우드 이전을 고려할 수 있습니다.
최대 수요를 충족하기 위해 더 이상 초과 용량을 유지할 필요가 없으므로, 비공개 컴퓨팅 환경의 활용률과 비용 효율성을 높일 수 있습니다.
클라우드 버스팅을 통해 컴퓨팅 리소스를 과도하게 프로비저닝하지 않고도 배치 작업을 적시에 실행할 수 있습니다.
권장사항
클라우드 버스팅 구현 시 다음 권장사항을 고려하세요.
meshed 토폴로지를 사용하여 클라우드에서 실행 중인 작업 부하가 다른 컴퓨팅 환경에서 실행되는 작업 부하와 동일한 방식으로 리소스에 액세스할 수 있도록 합니다. 워크로드가 허용하는 경우, 클라우드에서 다른 컴퓨팅 환경으로의 액세스만 허용할 수 있습니다.
환경 간의 통신 지연 시간을 최소화하려면 지리적으로 비공개 컴퓨팅 환경에 가까운 Google Cloud 리전과 상호 연결 위치를 선택합니다.
일괄 워크로드에 대해서만 클라우드 버스팅을 사용하는 경우, 모든 Google Cloud 리소스를 비공개 상태로 유지하여 인터넷에서 이러한 리소스로 직접 액세스할 수 없도록 하여 보안 공격 영역을 줄일 수 있습니다.
24시간 이상 실행되지 않고 시간이 크게 중요하지 않는 작업의 경우, 일반 VM 인스턴스보다 훨씬 저렴한 선점형 VM 인스턴스 사용을 고려합니다. 그러나 작업이 실행 중인 VM을 선점할 경우, 시스템이 작업을 자동으로 재시작할 수 있어야 합니다.
컨테이너를 사용하여 작업 부하 이동성을 달성합니다. 리소스 집약적인 일괄 워크로드의 경우 Compute Engine VM에서 이러한 컨테이너를 직접 배포하고 관리형 인스턴스 그룹을 사용하여 VM 수를 확대할 수 있습니다. 대화형 워크로드 또는 리소스 집약도가 낮은 다양한 워크로드의 경우 Google Kubernetes Engine (GKE)을 클러스터 자동 확장과 결합하여 이러한 컨테이너를 배포할 수도 있습니다. 그러나 GKE에서는 항상 구역당 노드가 최소한 1개 이상 실행 중이어야 합니다.
Google Cloud에서 다른 컴퓨팅 환경으로 전송되는 트래픽을 모니터링합니다. 이 트래픽에는 이그레스 요금이 부과됩니다.
환경 간에 교환되는 데이터가 민감한 데이터일 수 있으므로 VPN 터널이나 TLS 또는 둘 다 사용하여 모든 통신이 암호화되도록 해야 합니다.
버스팅 클라우드 패턴을 사용하여 CI 시스템을 동적으로 확장합니다. Jenkins를 사용하는 경우 Google Compute Engine 플러그인을 사용하여 Compute Engine의 Jenkins 인스턴스를 관리 및 자동 확장할 수 있습니다.
환경 경계에서 시스템을 안전하게 인증할 수 있도록 환경 간에 일반 ID를 설정합니다.
다음 단계
- 공통 아키텍처 패턴을 실현하는 데 적합한 네트워크 토폴로지 알아보기
- 하이브리드 방법과 적절한 작업 부하 선택 방법 알아보기
- GKE 문서와 가이드를 살펴봅니다.
- Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항을 살펴봅니다. Cloud 아키텍처 센터 살펴보기