이 문서는 총 3부로 구성된 문서 중 두 번째 문서입니다. 일반적인 하이브리드 및 멀티 클라우드 아키텍처 패턴을 설명합니다. 또한 이러한 패턴이 가장 적합한 시나리오에 대해서도 설명합니다. 마지막으로 Google Cloud에 이러한 아키텍처를 배포할 때 사용할 수 있는 권장사항을 제공합니다.
하이브리드 및 멀티 클라우드 아키텍처 패턴에 관한 문서 세트는 다음과 같이 구성됩니다.
- 하이브리드 및 멀티 클라우드 아키텍처 빌드: Google Cloud를 사용하여 하이브리드 및 멀티 클라우드 설정을 설계하기 위한 전략 계획을 논의합니다.
- 하이브리드 및 멀티 클라우드 아키텍처 패턴: 하이브리드 및 멀티 클라우드 전략의 일부로 채택할 일반적인 아키텍처 패턴을 논의합니다 (이 문서).
- 하이브리드 및 멀티 클라우드 보안 네트워킹 아키텍처 패턴: 네트워킹 관점에서 하이브리드 및 멀티 클라우드 네트워킹 아키텍처 패턴을 논의합니다.
모든 기업은 고유한 애플리케이션 워크로드 포트폴리오를 통해 하이브리드 또는 멀티 클라우드 설정의 아키텍처에 대한 요구사항과 제약 조건을 관리합니다. 이러한 제약 조건 및 요구사항을 충족하도록 아키텍처를 설계하고 맞춤화해야 하지만 몇 가지 일반적인 패턴에 의존하여 기본 아키텍처를 정의할 수 있습니다.
아키텍처 패턴은 기술 솔루션, 애플리케이션 또는 서비스의 여러 기능 구성요소를 구조화하여 특정 요구사항이나 사용 사례를 해결하는 재사용 가능한 솔루션을 만드는 반복 가능한 방법입니다. 클라우드 기반 기술 솔루션은 여러 개의 고유한 분산 클라우드 서비스로 구성되는 경우가 많습니다. 이러한 서비스는 필요한 기능을 제공하기 위해 협력합니다. 이 맥락에서 각 서비스는 기술 솔루션의 기능적 구성요소로 간주됩니다. 마찬가지로 애플리케이션은 여러 기능 계층, 모듈 또는 서비스로 구성될 수 있으며, 각각은 애플리케이션 아키텍처의 기능 구성요소를 나타낼 수 있습니다. 이러한 아키텍처는 특정 비즈니스 사용 사례를 해결하도록 표준화하고 재사용 가능한 기본 패턴으로 사용할 수 있습니다.
애플리케이션 또는 솔루션의 아키텍처 패턴을 일반적으로 정의하려면 다음을 식별하고 정의합니다.
- 솔루션 또는 애플리케이션의 구성요소입니다.
- 각 구성요소에 대해 예상되는 함수(예: 그래픽 사용자 인터페이스를 제공하는 프런트엔드 함수 또는 데이터 액세스를 제공하는 백엔드 함수)
- 구성요소가 서로 그리고 외부 시스템 또는 사용자와 통신하는 방식 최신 애플리케이션에서는 이러한 구성요소가 잘 정의된 인터페이스 또는 API를 통해 상호작용합니다. 비동기 및 동기, 요청-응답, 대기열 기반과 같은 다양한 통신 모델이 있습니다.
다음은 하이브리드 및 멀티 클라우드 아키텍처 패턴의 두 가지 주요 카테고리입니다.
- 분산 아키텍처 패턴: 이러한 패턴은 워크로드 또는 애플리케이션 구성요소의 분산 배포를 사용합니다. 즉, 패턴에 가장 적합한 컴퓨팅 환경에서 애플리케이션 (또는 애플리케이션의 특정 구성요소)을 실행합니다. 이렇게 하면 패턴이 분산되고 상호 연결된 컴퓨팅 환경의 다양한 속성과 특성을 활용할 수 있습니다.
- 중복 아키텍처 패턴: 이러한 패턴은 워크로드의 중복 배포를 기반으로 합니다. 이러한 패턴에서는 동일한 애플리케이션과 구성요소를 여러 컴퓨팅 환경에 배포합니다. 목표는 애플리케이션의 성능 용량 또는 복원력을 높이거나 개발 및 테스트를 위해 기존 환경을 복제하는 것입니다.
선택한 아키텍처 패턴을 구현할 때는 적절한 배포 아키텍처를 사용해야 합니다. 배포 원형은 영역, 리전, 멀티 리전, 전역 중 하나입니다. 이 선택사항은 애플리케이션별 배포 아키텍처를 구성하기 위한 기반을 형성합니다. 각 배포 원형은 애플리케이션이 작동할 수 있는 장애 도메인의 조합을 정의합니다. 이러한 장애 도메인은 하나 이상의 Google Cloud 영역 또는 리전을 포함할 수 있으며, 다른 클라우드 제공업체의 온프레미스 데이터 센터 또는 장애 도메인을 포함하도록 확장될 수 있습니다.
이 시리즈에는 다음 페이지가 포함되어 있습니다.
중복 아키텍처 패턴
참여자
저자: 마르완 알 샤위 | 파트너 고객 엔지니어
기타 참여자:
- 사우드 알바제이 | 고객 엔지니어, 애플리케이션 현대화
- 안나 베렌버그 | 엔지니어링 연구원
- 마르코 페라리 | 클라우드 솔루션 설계자
- 빅터 모레노 | Cloud Networking 제품 관리자
- 요하네스 패싱 | 클라우드 솔루션 설계자
- 마크 슐라겐하우프 | 네트워킹 테크니컬 라이터
- 다니엘 스트레벨 | 애플리케이션 현대화 부문 EMEA 솔루션 책임자
- 아밋 윌리엄스 | 개발자 관계팀 엔지니어
분산 아키텍처 패턴
비하이브리드 또는 비멀티 클라우드 컴퓨팅 환경에서 하이브리드 또는 멀티 클라우드 아키텍처를 마이그레이션하는 경우 먼저 기존 애플리케이션 제약조건과 이러한 제약조건이 애플리케이션 실패의 원인이 되는 방법을 고려합니다. 애플리케이션이나 애플리케이션 구성요소가 서로 다른 환경에 분산된 방식으로 작동하면 이 고려사항이 더욱 중요해 집니다. 제약조건을 고려한 후 방지하거나 극복할 계획을 세웁니다. 분산형 아키텍처에서 각 컴퓨팅 환경의 고유한 기능을 고려해야 합니다.
설계 고려사항
다음과 같은 설계 고려사항이 분산형 배포 패턴에 적용됩니다. 대상 솔루션과 비즈니스 목표에 따라 각 고려사항의 우선순위와 효과가 달라질 수 있습니다.
지연 시간
서로 다른 컴퓨팅 환경에서 애플리케이션 구성요소(프런트엔드, 백엔드 또는 마이크로서비스)을 배포하는 아키텍처 패턴에서 통신 지연 시간이 발생할 수 있습니다. 이 지연 시간은 하이브리드 네트워크 연결(Cloud VPN 및 Cloud Interconnect)과 온프레미스 사이트와 클라우드 리전 간 또는 멀티 클라우드 설정에서 클라우드 리전 간의 지역적 거리에 의해 영향을 받습니다. 따라서 애플리케이션의 지연 시간 요구사항과 네트워크 지연에 대한 민감도를 평가해야 합니다. 지연 시간을 허용할 수 있는 애플리케이션은 하이브리드 또는 멀티 클라우드 환경의 초기 분산형 배포에 더 적합합니다.
임시 상태 아키텍처와 최종 상태 아키텍처 비교
기대와 비용, 규모, 성능에 대한 잠재적 영향을 지정하려면 계획 단계의 일부로 필요한 아키텍처 유형과 의도된 기간을 분석해야 합니다. 예를 들어 하이브리드 또는 멀티 클라우드 아키텍처를 장시간 또는 영구적으로 사용하려면 Cloud Interconnect를 사용하는 것이 좋을 수 있습니다. 아웃바운드 데이터 전송 비용이 줄어들고 하이브리드 연결 네트워크 성능이 최적화되도록 Cloud Interconnect는 할인된 데이터 전송 요율 조건을 충족하는 아웃바운드 데이터 전송 요금을 할인합니다.
안정성
신뢰성은 IT 시스템 설계 시 중요 고려사항입니다. 업타임 가용성은 시스템 신뢰성에 있어 필수적인 관점입니다. Google Cloud에서는 전환 기능을 통해 단일 리전 내 여러 영역 또는 여러 리전에 애플리케이션 중복 구성요소를 배포하여 애플리케이션 복원력을 높일 수 있습니다. 중복성은 애플리케이션의 전체 가용성을 향상시키기 위한 핵심 요소 중 하나입니다. 하이브리드 및 멀티 클라우드 환경에서 분산된 설정을 사용하는 애플리케이션의 경우 일관된 가용성 수준을 유지하는 것이 중요합니다.
온프레미스 환경이나 다른 클라우드 환경에서 시스템 가용성을 향상시키려면 장애 조치 메커니즘과 함께 애플리케이션과 해당 구성요소에 필요한 하드웨어 또는 소프트웨어 중복성을 고려합니다. 이상적으로는 모든 환경의 다양한 구성요소와 지원 인프라(하이브리드 연결 가용성 포함)에서 서비스나 애플리케이션의 가용성을 고려해야 합니다. 이 개념을 애플리케이션 또는 서비스의 복합 가용성이라고도 합니다.
애플리케이션의 복합 가용성은 구성요소 또는 서비스 간의 종속 항목에 따라 개별 서비스나 구성요소보다 높거나 낮을 수 있습니다. 자세한 내용은 복합 가용성: 클라우드 인프라의 전체 가용성 계산을 참조하세요.
원하는 시스템 신뢰성 수준을 달성하려면 명확한 신뢰성 측정항목을 정의하고 다양한 환경에서 자가 복구되고 중단을 효과적으로 견딜 수 있는 애플리케이션을 설계합니다. 서비스의 고객 경험을 측정하는 적절한 방법을 정의하려면 신뢰성 목표 정의를 참조하세요.
하이브리드 및 멀티 클라우드 연결
분산 애플리케이션 구성요소 간의 통신 요구사항은 하이브리드 네트워크 연결 옵션 선택에 영향을 줄 수 있습니다. 각 연결 옵션에는 장점과 단점뿐만 아니라 비용, 트래픽 볼륨, 보안 등과 같이 고려해야 할 특정 요인이 있습니다. 자세한 내용은 연결 설계 고려사항 섹션을 참조하세요.
관리 효율성
일관되고 통합된 관리 및 모니터링 도구는 워크로드 이식성 유무에 관계없이 성공적인 하이브리드 및 멀티 클라우드 설정의 핵심입니다. 단기적으로 이러한 도구를 사용하면 개발, 테스트, 운영 비용이 추가될 수 있습니다. 기술적으로는 사용하는 클라우드 제공업체가 많을수록 환경 관리가 더 복잡해집니다. 대부분의 퍼블릭 클라우드 공급업체에는 여러 기능이 있을 뿐만 아니라 클라우드 서비스 관리를 위한 다양한 도구, SLA, API도 있습니다. 따라서 잠재적인 단기 복잡성 및 장기적인 이점과 선택한 아키텍처의 전략적 이점을 비교해보세요.
비용
멀티 클라우드 환경의 클라우드 서비스 제공업체마다 고유한 청구 측정항목과 도구가 있습니다. 더욱 우수한 가시성과 통합 대시보드를 제공하려면 멀티 클라우드 비용 관리와 최적화 도구를 사용하는 것이 좋습니다. 예를 들어 여러 클라우드 환경에서 클라우드 중심 솔루션을 빌드할 경우 각 제공업체의 제품, 가격 책정, 할인, 관리 도구로 인해 이러한 환경 간의 비용이 일치하지 않습니다.
클라우드 리소스의 전체 비용을 계산하고 비용 가시성을 제공하는 잘 정의된 방법 하나를 사용하는 것이 좋습니다. 비용 최적화에는 비용 가시성이 필수적입니다. 예를 들어 클라우드 제공업체의 결제 데이터를 결합하고 Google Cloud Looker Cloud 비용 관리 블록을 사용하면 멀티 클라우드 비용에 대한 중앙 집중식 뷰를 만들 수 있습니다. 이 뷰는 여러 클라우드에 걸쳐 지출된 비용에 대한 통합된 보고서 보기를 제공합니다. 자세한 내용은 Cloud Billing 비용 관리를 효과적으로 최적화하기 위한 전략을 참조하세요.
또한 비용을 확인하기 위한 FinOps 사례를 사용하는 것이 좋습니다. 중앙팀은 강력한 FinOps 관행의 일환으로 개별 책임성을 장려하기 위해 리소스 최적화에 대한 의사결정 권한을 프로젝트에 관련된 다른 팀에 위임할 수 있습니다. 이 모델에서는 중앙 팀이 프로세스, 보고, 비용 최적화 도구를 표준화해야 합니다. 고려해야 할 다양한 비용 최적화 측면과 권장사항에 대한 자세한 내용은 Google Cloud 아키텍처 프레임워크: 비용 최적화를 참고하세요.
데이터 이동
데이터 이동은 특히 분산형 시스템의 경우 하이브리드 및 멀티 클라우드 전략과 아키텍처 계획에서 중요한 고려사항입니다. 기업은 다양한 비즈니스 사용 사례, 비즈니스를 지원하는 데이터, (규제 대상 산업용) 데이터 분류 방법을 파악해야 합니다. 또한 여러 환경에서 분산형 시스템의 데이터 스토리지, 공유, 액세스가 애플리케이션 성능과 데이터 일관성에 미치는 영향을 고려해야 합니다. 이러한 요인은 애플리케이션과 데이터 파이프라인 아키텍처에 영향을 미칠 수 있습니다. Google Cloud의 포괄적인 데이터 이동 옵션 세트를 사용하면 기업에서 단순성, 효율성 또는 성능 저하 없이 특정 니즈를 충족하고 하이브리드 및 멀티 클라우드 아키텍처를 채택할 수 있습니다.
보안
애플리케이션을 클라우드로 마이그레이션할 경우 일관성, 관측 가능성, 통합 보안 가시성과 같은 클라우드 중심 보안 기능을 고려해야 합니다. 퍼블릭 클라우드 제공업체마다 보안에 대한 고유한 방식, 권장사항, 기능이 있습니다. 표준적인 기능적 보안 아키텍처를 빌드하려면 이러한 기능을 분석하고 조정해야 합니다. 강력한 IAM 제어, 데이터 암호화, 취약점 스캔, 산업 규정 준수도 클라우드 보안의 중요한 측면입니다.
마이그레이션 전략을 계획할 때 앞에서 언급한 고려사항을 분석하는 것이 좋습니다. 애플리케이션 또는 트래픽 볼륨이 증가할 때 복잡성이 아키텍처에 발생할 가능성을 최소화하는 데 도움이 될 수 있습니다. 또한 시작 영역 설계 및 빌드는 클라우드 환경에서 엔터프라이즈 워크로드를 배포하기 위한 전제 조건입니다. 시작 영역은 기업이 여러 영역에서 클라우드 서비스를 더욱 안전하게 배포, 사용, 확장하는 데 도움이 되며 여기에는 ID, 리소스 관리, 보안, 네트워킹과 같은 다양한 요소가 포함됩니다. 자세한 내용은 Google Cloud의 시작 영역 설계를 참조하세요.
이 시리즈의 다음 문서에서는 다른 분산형 아키텍처 패턴을 설명합니다.
단계식 하이브리드 패턴
애플리케이션의 아키텍처 구성요소는 프런트엔드 또는 백엔드로 분류할 수 있습니다. 일부 시나리오에서는 여러 컴퓨팅 환경에서 작동하도록 이러한 구성요소를 호스팅할 수 있습니다. 컴퓨팅 환경은 계층형 하이브리드 아키텍처 패턴의 일부로서 온프레미스 비공개 컴퓨팅 환경과 Google Cloud에 배치됩니다.
프런트엔드 애플리케이션 구성요소는 최종 사용자 또는 기기에 직접 노출됩니다. 따라서 이러한 애플리케이션은 성능에 민감한 경우가 많습니다. 새로운 기능과 개선사항을 개발하기 위해 소프트웨어 업데이트를 자주 수행할 수 있습니다. 프런트엔드 애플리케이션은 일반적으로 백엔드 애플리케이션에 의존해서 데이터(및 비즈니스 로직과 사용자 입력 처리)를 저장하고 관리하기 때문에 종종 스테이트리스(Stateless) 상태이거나 데이터 볼륨을 제한적으로만 관리합니다.
접근성과 사용성을 높이기 위해서는 다양한 프레임워크 및 기술을 사용해서 프런트엔드 애플리케이션을 빌드할 수 있습니다. 성공적인 프런트엔드 애플리케이션에 대한 몇 가지 핵심 요소에는 애플리케이션 성능, 응답 속도, 브라우저 호환성이 있습니다.
백엔드 애플리케이션 구성요소는 일반적으로 데이터 저장 및 관리에 중점을 둡니다. 일부 아키텍처에서는 비즈니스 로직이 백엔드 구성요소 내에 포함될 수 있습니다. 새로운 백엔드 애플리케이션 출시는 프런트엔드 애플리케이션 출시보다 빈도가 낮은 경향이 있습니다. 백엔드 애플리케이션의 관리 과제는 다음과 같습니다.
- 대량의 요청 처리
- 대량의 데이터 처리
- 데이터 보안
- 모든 시스템 복제본 간의 현재 및 업데이트된 데이터 유지보수
3계층 애플리케이션 아키텍처는 여러 다른 애플리케이션 구성요소를 포함하는 전자상거래 웹사이트와 같이 비즈니스 웹 애플리케이션을 빌드하기 위한 가장 인기 있는 구현 중 하나입니다. 이 아키텍처에는 다음과 같은 계층이 포함됩니다. 각 계층은 독립적으로 작동하지만 밀접하게 연결되어 있으며 모두 하나로 기능합니다.
- 웹 프런트엔드 및 프레젠테이션 계층
- 애플리케이션 계층
- 데이터 액세스 또는 백엔드 계층
이러한 레이어를 컨테이너에 배치하면 확장 요구사항과 같은 기술적 요구가 분리되고 단계적인 접근 방법으로 마이그레이션하는 데 도움이 됩니다. 또한 이를 사용해서 여러 환경 간에 이동이 가능한 플랫폼에 무관한 클라우드 서비스에 배포하고, 자동화된 관리를 사용하고, Cloud Run 또는 Google Kubernetes Engine(GKE) 엔터프라이즈 에디션과 같은 클라우드 관리 플랫폼으로 확장할 수 있습니다. 또한 Cloud SQL과 같은 Google Cloud 관리 데이터베이스는 데이터베이스 레이어로 백엔드를 제공할 수 있게 도와줍니다.
계층형 하이브리드 아키텍처 패턴은 기존 프런트엔드 애플리케이션 구성요소를 퍼블릭 클라우드에 배포하는 데 중점을 둡니다. 이 패턴에서는 기존 백엔드 애플리케이션 구성요소를 비공개 컴퓨팅 환경에 배치합니다. 애플리케이션의 규모 및 특정 설계에 따라 사례별 기준으로 프런트엔드 애플리케이션 구성요소를 마이그레이션할 수 있습니다. 자세한 내용은 Google Cloud로 마이그레이션을 참조하세요.
백엔드 및 프런트엔드 구성요소가 온프레미스 환경에 호스팅된 기존 애플리케이션이 있으면 현재 아키텍처의 제한사항을 고려하세요. 예를 들어 애플리케이션이 확장되고 성능 및 신뢰성에 대한 수요가 증가함에 따라 애플리케이션 일부를 리팩터링하거나 다른 더 최적화된 아키텍처로 이동할지 여부에 대한 평가를 시작해야 합니다. 계층형 하이브리드 아키텍처 패턴을 사용하면 전체 전환을 수행하기 전에 일부 애플리케이션 워크로드와 구성요소를 클라우드로 이동할 수 있습니다. 또한 이러한 마이그레이션에서 발생하는 비용, 시간, 위험을 고려해야 합니다.
다음 다이어그램은 일반적인 계층형 하이브리드 아키텍처 패턴을 보여줍니다.
이전 다이어그램에서 클라이언트 요청은 Google Cloud에서 호스팅되는 애플리케이션 프런트엔드로 전송됩니다. 그런 다음 애플리케이션 프런트엔드는 애플리케이션 백엔드가 호스팅되는(이상적으로 API 게이트웨이 사용) 온프레미스 환경으로 다시 데이터를 전송합니다.
계층형 하이브리드 아키텍처 패턴에서는 다음 다이어그램의 아키텍처 예시에 표시된 것처럼 Google Cloud 인프라 및 전역 서비스의 이점을 활용할 수 있습니다. 애플리케이션 프런트엔드는 Google Cloud를 통해 도달할 수 있습니다. 또한 인프라에 대한 초과 프로비저닝 없이도 자동 확장을 통해 확장 요구에 동적으로 효율적으로 대응함으로써 프런트엔드에 탄력성을 더할 수 있습니다. Google Cloud에서 확장 가능한 웹앱을 빌드하고 실행하는 데에는 여러 가지 아키텍처를 사용할 수 있습니다. 각 아키텍처에는 여러 다른 요구사항에 따라 장점과 단점이 있습니다.
자세한 내용은 YouTube 동영상 Google Cloud에서 확장 가능한 웹앱을 실행하는 3가지 방법을 참조하세요. Google Cloud에서 전자상거래 플랫폼을 현대화하는 여러 방법들을 자세히 알아보려면 Google Cloud에서 디지털 상거래 플랫폼을 빌드하는 방법을 참조하세요.
이전 다이어그램에서 애플리케이션 프런트엔드는 Google Cloud에 호스팅되어 전역 부하 분산, 자동 확장, Google Cloud Armor를 통한 DDoS 보호를 사용하는 멀티 리전을 지원하고 전역적으로 최적화된 사용자 경험을 제공합니다
시간이 지남에 따라 퍼블릭 클라우드에 배포하는 애플리케이션 수가 증가하여 백엔드 애플리케이션 구성요소를 퍼블릭 클라우드로 이동을 고려해야 하는 지점에 도달할 수 있습니다. 높은 트래픽 요구가 예상될 경우 자체 인프라를 관리할 때 클라우드 기반 서비스를 선택하면 엔지니어링 노력을 줄이는 데 도움이 될 수 있습니다. 제약조건 또는 요구사항에 따라 온프레미스에서 백엔드 애플리케이션 구성요소 호스팅이 강제되지 않는 한 이 옵션을 고려하세요. 예를 들어 백엔드 데이터에 규제 제한사항이 적용될 경우 해당 데이터를 온프레미스에 보관해야 할 수 있습니다. 하지만 적용 가능하고 규정에도 맞으면 익명화 기법과 같은 Sensitive Data Protection 기능을 사용해서 필요에 따라 데이터 이동을 도울 수 있습니다.
계층형 하이브리드 아키텍처 패턴에서는 또한 일부 시나리오에서 Google Distributed Cloud를 사용할 수 있습니다. Distributed Cloud를 사용하면 Google에서 제공 및 유지보수되고 Google Cloud 데이터 센터와 별개인 전용 하드웨어에서 Google Kubernetes Engine 클러스터를 실행할 수 있습니다. Distributed Cloud가 현재 및 미래의 요구사항을 충족하도록 보장하기 위해서는 기존의 클라우드 기반 GKE 영역과 비교되는 Distributed Cloud의 제한사항을 파악해야 합니다.
장점
프런트엔드 애플리케이션에 먼저 중점을 두면 다음과 같은 여러 이점이 있습니다.
- 프런트엔드 구성요소는 백엔드 리소스에 의존하며 일부 경우에는 다른 프런트엔드 구성요소에 의존합니다.
- 백엔드 구성요소는 프런트엔드 구성요소에 의존하지 않습니다. 따라서 프런트엔드 애플리케이션을 격리하고 마이그레이션하는 것이 백엔드 애플리케이션을 마이그레이션하는 것보다 덜 복잡할 수 있습니다.
- 프런트엔드 애플리케이션은 종종 스테이트리스(Stateless) 방식이거나 그 자체로 데이터를 관리하지 않기 때문에 백엔드보다 마이그레이션하기에 덜 까다로울 수 있습니다.
- 프런트엔드 구성요소는 마이그레이션 중에 스테이트리스(Stateless) 아키텍처를 사용하도록 최적화할 수 있습니다. 자세한 내용은 YouTube 동영상 Cloud Run에 스테이트풀(Stateful) 웹앱을 이식하는 방법을 참조하세요.
기존 또는 새롭게 개발된 프런트엔드 애플리케이션을 퍼블릭 클라우드에 배포하면 다음과 같은 몇 가지 이점이 있습니다.
- 많은 프런트엔드 애플리케이션은 자주 변경될 수 있습니다. 퍼블릭 클라우드에서 이러한 애플리케이션을 실행하면 지속적 통합/지속적 배포(CI/CD) 프로세스 설정이 간소화됩니다. CI/CD를 사용해서 효율적이고 자동화된 방법으로 업데이트를 전송할 수 있습니다. 자세한 내용은 Google Cloud의 CI/CD를 참조하세요.
- 트래픽 부하가 다양하고 성능에 민감한 프런트엔드는 클라우드 기반 배포로 지원되는(이상적으로 스테이트리스(Stateless) 아키텍처 사용) 부하 분산, 멀티 리전 배포, Cloud CDN 캐싱, 서버리스 및 자동 확장 기능에서 상당한 이점을 얻을 수 있습니다.
GKE와 같은 클라우드 관리 플랫폼을 사용하여 컨테이너가 있는 마이크로서비스를 채택하면 마이크로서비스를 프런트엔드 구성요소로 확장하는 마이크로프런트엔드와 같은 현대적인 아키텍처를 사용할 수 있습니다.
마이크로서비스 확장은 일반적으로 동일 애플리케이션에서 여러 팀이 협업하는 프런트엔드에 사용됩니다. 이러한 종류의 팀 구조에는 반복적인 접근 방법과 지속적인 유지보수가 필요합니다. 마이크로프런트엔드를 사용할 때의 장점은 다음과 같습니다.
- 개발, 테스트, 배포를 위한 독립적인 마이크로서비스 모듈로 만들 수 있습니다.
- 각 개발팀에 따라 선호하는 기술과 코드를 선택할 수 있는 분리 기능을 제공합니다.
- 다른 팀에서 관리할 수 있는 나머지 프런트엔드 구성요소에 영향을 주지 않고 개발 및 배포 주기를 빠르게 지원할 수 있습니다.
사용자 인터페이스 또는 API를 구현하거나 사물 인터넷(IoT) 데이터 수집을 처리하든지 간에 프런트엔드 애플리케이션이 Firebase, Pub/Sub, Apigee, Cloud CDN, App Engine, Cloud Run과 같은 클라우드 서비스의 기능을 활용할 수 있습니다.
클라우드 관리 API 프록시는 다음을 도와줍니다.
- 마이크로서비스와 같은 백엔드 서비스에서 앱용 API를 분리합니다.
- 백엔드 코드 변경사항으로부터 앱을 보호합니다.
- 프런트엔드용 백엔드(BFF), 마이크로프런트엔드 등과 같은 기존 API 기반의 프런트엔드 아키텍처를 지원합니다.
- Apigee에서 API 프록시를 구현하여 Google Cloud 또는 기타 환경에서 API를 노출합니다.
또한 프런트엔드를 비공개 컴퓨팅 환경에 유지하면서 클라우드에 백엔드를 배포함으로써 계층형 하이브리드 패턴을 역방향으로 적용할 수 있습니다. 덜 일반적이지만 이 접근 방법은 규모가 크고 복잡한 모놀리식 프런트엔드를 다루는 데 가장 적합합니다. 이러한 경우 백엔드 기능을 반복적으로 추출하고 클라우드에 이러한 새로운 백엔드를 배포하는 것이 더 쉬울 수 있습니다.
이 시리즈의 3번째 부분에서는 이러한 아키텍처를 사용 설정하기 위해 가능한 네트워킹 패턴에 대해 논의합니다. Apigee Hybrid는 하이브리드 배포 모델에서 API 프록시를 빌드 및 관리하는 플랫폼으로서 도움이 됩니다. 자세한 내용은 계층형 모놀리식 및 마이크로서비스 아키텍처를 포함하여 느슨하게 결합된 아키텍처를 참조하세요.
권장사항
계층형 하이브리드 아키텍처를 계획할 때는 이 섹션의 정보를 참조하세요.
복잡성을 줄이기 위한 권장사항
계층형 하이브리드 아키텍처 패턴을 적용할 때는 전반적인 배포 및 운영 복잡성을 줄이는 데 도움이 될 수 있는 다음과 같은 권장사항을 고려하세요.
- 식별된 애플리케이션의 통신 모델에 대한 평가를 기준으로 이러한 애플리케이션에 대해 가장 효율적이고 효과적인 통신 솔루션을 선택합니다.
대부분의 사용자 상호작용은 여러 컴퓨팅 환경에 연결된 시스템에서 이루어지기 때문에 이러한 시스템 간에 지연 시간이 짧고 빠른 연결성이 중요합니다. 가용성 및 성능 기대치를 충족시키기 위해서는 고가용성, 낮은 지연 시간, 적합한 처리량 수준을 지원하도록 설계해야 합니다. 보안 관점에서는 통신을 미세 조정 및 제어해야 합니다. 이상적으로는 보안 API를 사용하여 애플리케이션 구성요소를 노출해야 합니다. 자세한 내용은 게이트 이그레스를 참조하세요.
- 여러 환경 간에 통신 지연 시간을 최소화하려면 애플리케이션 백엔드 구성요소가 호스팅된 비공개 컴퓨팅 환경에 지리적으로 가까운 Google Cloud 리전을 선택합니다. 자세한 내용은 Compute Engine 리전 선택 권장사항을 참조하세요.
- 특히 통신이 동시에 처리되는 경우, 서로 다른 환경에서 실행되는 시스템 간의 높은 종속 항목을 최소화합니다. 이러한 종속 항목은 성능을 느리게 하고, 전반적인 가용성을 줄이고, 잠재적으로 추가적인 아웃바운드 데이터 전송 요금을 발생시킬 수 있습니다.
- 계층형 하이브리드 아키텍처 패턴에서는 Google Cloud를 나가는 아웃바운드 트래픽에 비해 Google Cloud로 들어오는 온프레미스 환경의 인바운드 트래픽 볼륨이 더 클 수 있습니다. 그렇더라도 Google Cloud를 나가는 예상 아웃바운드 데이터 전송 볼륨을 알아야 합니다. 높은 아웃바운드 데이터 전송 볼륨이 이 아키텍처를 장기간 사용하려면 Cloud Interconnect 사용을 고려하세요. Cloud Interconnect는 연결 성능을 최적화하는 데 도움이 되며 특정 조건을 충족하는 트래픽에 대한 아웃바운드 데이터 전송 요금을 줄일 수 있습니다. 자세한 내용은 Cloud Interconnect 가격 책정을 참조하세요.
- 민감한 정보를 보호하기 위해서는 전송 중 상태의 모든 통신을 암호화하는 것이 좋습니다. 연결 레이어에 암호화가 필요하면 VPN 터널, Cloud Interconnect를 통한 HA VPN, Cloud Interconnect용 MACsec를 사용할 수 있습니다.
여러 백엔드 간에 프로토콜, API, 인증 메커니즘의 불일치 문제를 해결하기 위해서는 가능한 경우 API 게이트웨이 또는 프록시를 통합 퍼사드로 배포하는 것이 좋습니다. 이러한 게이트웨이 또는 프록시는 중앙화된 제어 지점으로 작동하며 다음과 같은 측정을 수행합니다.
- 추가 보안 측정을 구현합니다.
- 백엔드 코드 변경사항으로부터 클라이언트 앱과 기타 서비스를 보호합니다.
- 모든 교차 환경 애플리케이션과 분리된 구성요소 사이의 통신을 위한 감사 추적을 지원합니다.
- 기존 서비스와 및 현대화된 서비스 사이에 중간 통신 레이어 역할을 수행합니다.
- Apigee 및 Apigee Hybrid를 사용하면 온프레미스 환경, 에지, 기타 클라우드, Google Cloud 환경 간에 엔터프라이즈급 및 하이브리드 게이트웨이를 호스팅하고 관리할 수 있습니다.
하이브리드 설정을 지원하기 위해서는 하이브리드 연결이 지원되는 Cloud Load Balancing을 사용합니다. 즉, 클라우드 부하 분산의 이점을 온프레미스 컴퓨팅 환경에 호스팅되는 서비스로 확장할 수 있습니다. 이 접근 방법을 사용하면 서비스 중단을 없애거나 최소화하는 방식으로 Google Cloud로 단계별 워크로드 마이그레이션을 수행하고 분산 서비스로의 원활한 전환을 보장할 수 있습니다. 자세한 내용은 하이브리드 연결 네트워크 엔드포인트 그룹 개요를 참조하세요.
일부 경우에는 API 게이트웨이 또는 프록시와 애플리케이션 부하 분산기를 함께 사용해서 대규모 API 트래픽 관리, 보안, 분산을 위한 보다 강력한 솔루션을 제공할 수 있습니다. API 게이트웨이와 함께 Cloud Load Balancing을 사용하면 다음을 달성할 수 있습니다.
- Apigee 및 Cloud CDN과 함께 고성능 API를 제공하여 지연 시간을 줄이고, API를 전역적으로 호스팅하고, 피크 트래픽 기간에 가용성을 늘릴 수 있습니다. 자세한 내용은 YouTube 동영상 Apigee 및 Cloud CDN과 함께 고성능 API 제공을 참조하세요.
- 고급 트래픽 관리를 구현합니다.
- Google Cloud Armor를 DDoS 보호 및 네트워크 보안 서비스로 사용해서 API를 보호합니다.
- 여러 리전의 게이트웨이에서 효율적인 부하 분산을 관리합니다. 자세한 내용은 YouTube 동영상 Private Service Connect와 Apigee로 API 보호 및 멀티 리전 장애 조치 구현을 참조하세요.
API 관리 및 서비스 메시를 사용하여 마이크로서비스 아키텍처에서 서비스가 통신을 수행하고 노출되는 방식을 보호하고 제어할 수 있습니다.
- Cloud Service Mesh를 사용하여 서비스 간 인증, 승인, 암호화를 관리할 수 있는 분산 서비스로 구성된 시스템에서 서비스 품질을 유지보수하는 서비스 간 통신을 허용할 수 있습니다.
- 서비스를 API로 노출하여 조직 및 외부 사용자가 이러한 서비스를 소비할 수 있게 해주는 Apigee와 같은 API 관리 플랫폼을 사용합니다.
환경 경계에서 시스템을 안전하게 인증할 수 있도록 환경 간에 일반 ID를 설정합니다.
퍼블릭 클라우드에 CI/CD 및 구성 관리 시스템을 배포합니다. 자세한 내용은 미러링된 네트워크 아키텍처 패턴을 참조하세요.
운영 효율을 높이기 위해서는 여러 환경에서 일관적인 도구 구성과 CI/CD 파이프라인을 사용합니다.
개별 워크로드 및 애플리케이션 아키텍처를 위한 권장사항
- 비록 이 패턴의 프런트엔드 애플리케이션에 초점이 맞춰져 있지만, 백엔드 애플리케이션을 최신화해야 함을 인식해야 합니다. 백엔드 애플리케이션의 개발 속도가 프런트엔드 애플리케이션보다 상당히 느릴 경우에는 이러한 차이로 인해 추가적인 복잡성이 발생할 수 있습니다.
- API를 백엔드 인터페이스로 취급하면 통합, 프런트엔드, 개발, 서비스 상호작용을 원활하게 지원하고 백엔드 시스템 복잡성을 숨길 수 있습니다. 이러한 과제를 해결하기 위해 Apigee는 하이브리드 및 멀티 클라우드 배포에 대한 API 게이트웨이/프록시 개발과 관리를 지원합니다.
- 콘텐츠(정적과 동적), 검색 엔진 최적화 성능, 페이지 로드 속도 기대치를 기준으로 프런트엔드 웹 애플리케이션의 렌더링 접근 방법을 선택합니다.
- 콘텐츠 기반의 웹 애플리케이션을 위한 아키텍처를 선택할 때는 모놀리식, 서버리스, 이벤트 기반, 마이크로서비스 아키텍처 등 다양한 옵션을 이용할 수 있습니다. 가장 적합한 아키텍처를 선택하려면 현재 및 미래의 애플리케이션 요구사항에 따라 이러한 옵션을 철저하게 평가해야 합니다. 비즈니스 및 기술적 목표에 맞게 조정된 아키텍처 의사결정을 내리기 위해서는 콘텐츠 기반 웹 애플리케이션 백엔드를 위한 여러 아키텍처 비교 및 웹 백엔드의 주요 고려사항을 참조하세요.
마이크로서비스 아키텍처에서는 Kubernetes를 공통 런타임 레이어로 사용하여 컨테이너화된 애플리케이션을 사용할 수 있습니다. 계층형 하이브리드 아키텍처 패턴에서는 다음 시나리오 중 하나로 실행할 수 있습니다.
두 환경 전체(Google Cloud 및 온프레미스 환경)에서 실행
- 환경 전체에서 컨테이너 및 Kubernetes를 사용하면 워크로드를 현대화하고 서로 다른 시간에 Google Cloud로 마이그레이션하는 유연성이 있습니다. 따라서 워크로드가 서로 크게 의존하고 개별적으로 마이그레이션할 수 없는 경우에 도움이 됩니다. 또는 하이브리드 워크로드 이동성을 이용해서 각 환경에서 최상의 리소스를 사용할 수 있습니다. 모든 경우에 GKE Enterprise는 핵심적인 지원 기술이 될 수 있습니다. 자세한 내용은 GKE Enterprise 하이브리드 환경을 참조하세요.
마이그레이션 및 현대화된 애플리케이션 구성요소의 Google Cloud 환경에서 실행
- 컨테이너화 지원이 부족하거나 단기적으로 현대화를 위해 상당한 시간과 리소스가 필요한 기존 백엔드가 온프레미스로 있으면 이 접근 방법을 사용합니다.
웹 애플리케이션 아키텍처를 현대화하기 위해 마이크로서비스 아키텍처에 대한 모놀리식 앱 설계 및 리팩터링에 대한 자세한 내용은 마이크로서비스 소개를 참조하세요.
웹 애플리케이션의 요구에 따라 데이터 스토리지 기술을 조합할 수 있습니다. 다양한 데이터 스토리지 요구를 충족하기 위해서는 정형 데이터에 Cloud SQL을 사용하고 미디어 파일에 Cloud Storage를 사용하는 것이 일반적입니다. 하지만 선택은 사용 사례에 가장 크게 의존합니다. 콘텐츠 기반의 애플리케이션 백엔드 및 효율적인 모달성을 위한 데이터 스토리지 옵션에 대한 자세한 내용은 콘텐츠 기반 웹앱을 위한 데이터 스토리지 옵션을 참조하세요. 또한 Google Cloud 데이터베이스 옵션 설명을 참조하세요.
분할 멀티 클라우드 패턴
파티션을 나눈 멀티 클라우드 아키텍처 패턴은 여러 다른 클라우드 서비스 제공업체가 운영하는 여러 퍼블릭 클라우드 환경을 조합한 것입니다. 이 아키텍처를 사용하면 이 시리즈의 첫 번째 부분에서 논의한 멀티 클라우드 공급자와 고려사항에 따라 최적의 컴퓨팅 환경에 애플리케이션을 유연하게 배포할 수 있습니다.
다음 다이어그램은 파티션을 나눈 멀티 클라우드 아키텍처 패턴을 보여줍니다.
이 아키텍처 패턴은 두 가지 다른 방법으로 빌드할 수 있습니다. 첫 번째 접근 방법은 여러 퍼블릭 클라우드 환경에서 애플리케이션 구성요소 배포를 기준으로 합니다. 이러한 접근 방법을 복합 아키텍처라고도 부르며, 계층형 하이브리드 아키텍처 패턴과 동일합니다. 하지만 퍼블릭 클라우드와 함께 온프레미스 환경을 사용하는 대신 최소한 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 환경 간에 로깅 및 모니터링을 위한 일관적인 도구를 사용합니다. 오픈소스 모니터링 시스템을 사용할 수도 있습니다. 자세한 내용은 하이브리드 및 멀티 클라우드 모니터링 및 로깅 패턴을 참조하세요.
단일 애플리케이션의 구성요소가 둘 이상의 클라우드 환경에 배포되는 분산 방식으로 애플리케이션 구성요소를 배포할 경우 계층형 하이브리드 아키텍처 패턴을 위한 권장사항을 참조하세요.
분석 하이브리드 및 멀티 클라우드 패턴
이 문서에서는 분석 하이브리드 및 멀티 클라우드 패턴의 목표가 트랜잭션 워크로드와 분석 워크로드 간의 분할을 활용하는 것이라고 설명합니다.
엔터프라이즈 시스템에서 대부분의 워크로드는 다음과 같은 범주로 분류됩니다.
- 트랜잭션 워크로드에는 영업, 재무 처리, 엔터프라이즈 리소스 계획 또는 통신과 같은 대화형 애플리케이션이 포함됩니다.
- 분석 워크로드에는 데이터를 변환, 분석, 상세검색 또는 시각화하여 의사결정 프로세스를 지원하는 애플리케이션이 포함됩니다.
분석 시스템은 API를 쿼리하거나 데이터베이스에 액세스하여 트랜잭션 시스템에서 데이터를 얻습니다. 대부분의 기업에서 분석 및 트랜잭션 시스템은 분리되어 느슨하게 결합되는 경향이 있습니다. 분석 하이브리드 및 멀티 클라우드 패턴의 목표는 두 가지 컴퓨팅 환경에서 트랜잭션 및 분석 워크로드를 실행하여 기존의 이러한 분할을 활용하는 것입니다. 원시 데이터는 비공개 컴퓨팅 환경에서 실행 중인 워크로드에서 추출된 다음 분석 처리에 사용되는 Google Cloud에 로드됩니다. 일부 결과는 트랜잭션 시스템에 다시 공급될 수 있습니다.
다음 다이어그램은 잠재적인 데이터 파이프라인을 보여줌으로써 개념적으로 가능한 아키텍처를 보여줍니다. 각 경로/화살표는 사용 가능한 데이터 품질 및 타겟팅된 사용 사례에 따라 ETL 또는 ELT를 기반으로 할 수 있는 가능한 데이터 이동 및 변환 파이프라인 옵션을 나타냅니다.
Google Cloud로 데이터를 이전하고 데이터에서 가치를 창출하려면 데이터 수집, 통합, 복제 서비스의 완전한 제품군인 데이터 이동 서비스를 사용하세요.
위의 다이어그램에서 볼 수 있듯이 Google Cloud를 온프레미스 환경 및 기타 클라우드 환경과 연결하면 데이터 스트리밍 및 데이터베이스 백업과 같은 다양한 데이터 분석 사용 사례를 사용할 수 있습니다. 대량의 데이터 전송이 필요한 하이브리드 및 멀티 클라우드 분석 패턴의 기본 전송을 지원하기 위해 Cloud Interconnect 및 Cross-Cloud Interconnect는 온프레미스 및 기타 클라우드 제공업체에 대한 전용 연결을 제공합니다.
장점
클라우드에서 분석 워크로드를 실행하면 다음과 같은 몇 가지 주요 이점이 있습니다.
- 인바운드 트래픽(비공개 컴퓨팅 환경 또는 다른 클라우드에서 Google Cloud로 데이터 이동)은 무료일 수 있습니다.
- 분석워크로드는 상당한 양의 데이터를 처리해야 하는 경우가 많고 데이터가 급증할 수 있으므로, 특히 퍼블릭 클라우드 환경에 배포하기에 적합합니다. 컴퓨팅 리소스를 동적으로 확장하여 대규모 데이터 세트를 신속하게 처리할 수 있으며 초기 투자를 하거나 컴퓨팅 장비를 오버프로비저닝할 필요가 없습니다.
- Google Cloud는 초기 구입부터 처리 및 분석, 최종 시각화까지 전체 수명 주기 동안 데이터를 관리할 수 있는 다양한 서비스를 제공합니다.
- Google Cloud의 데이터 이동 서비스는 다양한 방식으로 데이터를 원활하게 이동, 통합, 변환할 수 있는 완전한 제품군을 제공합니다.
- Cloud Storage는 데이터 레이크를 빌드하는 데 매우 적합합니다.
Google Cloud를 사용하면 데이터 플랫폼을 현대화하고 최적화하여 데이터 사일로를 허물 수 있습니다. 데이터 레이크하우스를 사용하면 다양한 스토리지 형식을 표준화하는 데 도움이 됩니다. 또한 데이터에서 비효율성이 아닌 비즈니스 가치를 창출하는 데 필요한 유연성, 확장성, 민첩성을 제공할 수 있습니다. 자세한 내용은 BigLake를 참조하세요.
BigQuery Omni는 AWS 또는 Azure의 스토리지에 로컬로 실행되는 컴퓨팅 성능을 제공합니다. 또한 Amazon Simple Storage Service(Amazon S3) 또는 Azure Blob Storage에 저장된 자체 데이터를 쿼리하는 데도 도움이 됩니다. 이 멀티 클라우드 분석 기능을 사용하면 데이터팀이 데이터 사일로를 허물 수 있습니다. BigQuery 외부에 저장된 데이터를 쿼리하는 방법에 관한 자세한 내용은 외부 데이터 소스 소개를 참조하세요.
권장사항
분석 하이브리드 및 멀티 클라우드 아키텍처 패턴을 구현하려면 다음과 같은 일반적인 권장사항을 고려하세요.
- 핸드오버 네트워킹 패턴을 사용하여 데이터 수집을 사용 설정합니다. 분석 결과를 트랜잭션 시스템에 다시 제공해야 하는 경우 핸드오버 및 게이트 이그레스 패턴을 결합할 수 있습니다.
- Pub/Sub 큐 또는 Cloud Storage 버킷을 사용하여 비공개 컴퓨팅 환경에서 실행 중인 트랜잭션 시스템에서 Google Cloud로 데이터를 전송합니다. 이러한 큐 또는 버킷이 데이터 처리 파이프라인과 워크로드의 소스로 사용될 수 있습니다.
- ETL 및 ELT 데이터 파이프라인을 배포하려면 특정 사용 사례 요구사항에 따라 Cloud Data Fusion 또는 Dataflow를 사용하는 것이 좋습니다. 두 서비스 모두 데이터 파이프라인을 빌드하고 관리하기 위한 완전 관리형 클라우드 중심 데이터 처리 서비스입니다.
- 가치 있는 데이터 애셋을 탐색, 분류, 보호하려면 익명화 기법과 같은 Google Cloud Sensitive Data Protection 기능을 사용하는 것이 좋습니다. 이러한 기법을 사용하면 해당하고 규정을 준수하는 경우 무작위로 생성되거나 사전 결정된 키를 사용하여 개인 식별 정보(PII)와 같은 민감한 정보를 마스킹, 암호화, 대체할 수 있습니다.
- 기존 Hadoop 또는 Spark 워크로드가 있는 경우, 작업을 Dataproc으로 마이그레이션하고 기존 HDFS 데이터를 Cloud Storage로 마이그레이션하는 것을 고려합니다.
비공개 컴퓨팅 환경에서 Google Cloud로 초기 데이터 전송을 수행하는 경우 데이터 세트 크기 및 사용 가능한 대역폭에 가장 적합한 전송 방식을 선택합니다. 자세한 내용은 Google Cloud로 마이그레이션: 대규모 데이터 세트 전송을 참조하세요.
Google Cloud와 다른 클라우드 간에 트래픽 볼륨이 많은 장기적인 데이터 전송 또는 교환이 필요한 경우 Google Cloud Cross-Cloud Interconnect를 사용하여 Google Cloud와 다른 클라우드 서비스 제공업체 간에 고대역폭 전용 연결을 설정하는 것이 좋습니다(일부 위치에서 사용 가능).
연결 레이어에서 암호화가 필요한 경우 선택한 하이브리드 연결 솔루션에 따라 다양한 옵션을 사용할 수 있습니다. 이러한 옵션에는 VPN 터널, Cloud Interconnect를 통한 HA VPN, Cross-Cloud Interconnect용 MACsec이 포함됩니다.
여러 환경에서 일관된 도구와 프로세스를 사용합니다. 분석 하이브리드 시나리오에서는 이러한 관행이 선행 조건은 아니지만 운영 효율성을 높이는 데 도움이 될 수 있습니다.
에지 하이브리드 패턴
클라우드에서 워크로드를 실행하려면 일부 시나리오에서 클라이언트의 경우 신속하고 안정적인 인터넷 연결이 보장되어야 합니다. 현재의 네트워크를 고려하면, 이러한 요구사항은 클라우드 채택에 있어 거의 문제가 되지 않습니다. 그러나 다음과 같이 지속적인 연결을 사용할 수 없는 시나리오가 있습니다.
- 해상 선박과 기타 차량은 간헐적으로 연결되거나 지연 시간이 긴 위성 링크에만 액세스할 수 있습니다.
- 공장이나 발전소가 인터넷에 연결되어 있을 수 있습니다. 이러한 시설에는 인터넷 제공업체의 가용성 보장을 초과하는 안정성 요구사항이 있을 수 있습니다.
- 소매점과 슈퍼마켓은 가끔만 연결되거나 비즈니스에 중요한 거래를 처리하는 데 필요한 안정성이나 처리량을 제공하지 않는 링크를 사용할 수 있습니다.
에지 하이브리드 아키텍처 패턴은 시간적, 비즈니스적으로 중요한 워크로드는 네트워크의 에지에서 로컬로 실행하고, 그 외의 모든 워크로드는 클라우드를 사용하여 이러한 문제를 해결합니다. 에지 하이브리드 아키텍처에서 인터넷 링크는 관리 목적으로 사용되며, 주로 비동기식으로 데이터 동기화와 업로드에 활용되지만, 시간적, 비즈니스적으로 중요한 트랜잭션에는 관여하지 않는 비핵심 구성 요소입니다.
장점
특정 워크로드를 에지에서 실행하고 다른 워크로드를 클라우드에서 실행하면 다음과 같은 여러 가지 이점이 있습니다.
- 인바운드 트래픽(에지에서 Google Cloud로 데이터 이동)은 무료일 수 있습니다.
- 시간적, 비즈니스적으로 중요한 워크로드를 에지에서 실행하면 지연 시간이 단축되고 자가 효율성이 향상됩니다. 인터넷 연결이 실패하거나 인터넷 연결을 일시적으로 사용할 수 없는 경우에도 모든 중요 트랜잭션을 계속 실행할 수 있습니다. 동시에 전체 워크로드의 상당 부분에 클라우드를 사용함으로써 이점을 얻을 수 있습니다.
- 컴퓨팅 및 스토리지 장비에 대한 기존 투자를 재사용할 수 있습니다.
- 시간이 지남에 따라 특정 애플리케이션을 다시 작동하거나 일부 에지 위치에 더 안정적인 인터넷 링크를 장착하여 에지에서 실행되는 워크로드의 비율을 점차적으로 줄이고 클라우드로 이동할 수 있습니다.
- 사물 인터넷(IoT) 관련 프로젝트는 로컬에서 데이터 계산을 실행하여 비용 효율성을 높일 수 있습니다. 이를 통해 기업은 데이터 소스에 더 가까운 에지에서 일부 서비스를 로컬로 실행하고 처리할 수 있습니다. 또한 기업은 데이터를 클라우드로 선택적으로 전송할 수 있으므로 IoT 솔루션의 용량, 데이터 전송, 처리, 전반적인 비용을 줄일 수 있습니다.
- 에지 컴퓨팅은 기존 서비스와 현대화된 서비스 간에 중간 통신 레이어 역할을 할 수 있습니다. 예를 들어 Apigee Hybrid와 같이 컨테이너화된 API 게이트웨이를 실행할 수 있는 서비스입니다. 이를 통해 기존 애플리케이션과 시스템을 IoT 솔루션과 같은 현대화된 서비스와 통합할 수 있습니다.
권장사항
에지 하이브리드 아키텍처 패턴을 구현하는 경우에는 다음 권장사항을 고려합니다.
- 통신이 단방향인 경우, gated ingress 패턴을 사용합니다.
- 통신이 양방향인 경우 gated egress 및 gated ingress 패턴을 고려합니다.
- 솔루션이 공개 인터넷을 통해 Google Cloud에 연결되는 여러 에지 원격 사이트로 구성된 경우 소프트웨어 정의 WAN(SD-WAN) 솔루션을 사용할 수 있습니다. Google Cloud 파트너가 지원하는 서드 파티 SD-WAN 라우터와 함께 Network Connectivity Center를 사용하여 대규모로 보안 연결을 간편하게 프로비저닝하고 관리할 수도 있습니다.
- 에지에서 실행 중인 시스템과 클라우드 환경에서 실행 중인 시스템 간의 종속 항목을 최소화합니다. 각 종속 항목은 에지 하이브리드 설정의 안정성과 지연 시간 이점을 약화시킬 수 있습니다.
- 여러 에지 위치를 효율적으로 관리 및 운영하려면 클라우드에 중앙 집중식 관리 영역과 모니터링 솔루션이 있어야 합니다.
- 클라우드와 에지 환경에서 배포 및 모니터링용 도구와 CI/CD 파이프라인이 일관성을 갖는지 확인합니다.
- 해당하고 실행 가능한 경우 컨테이너와 Kubernetes를 사용하여 다양한 에지 위치 간의 차이와 에지 위치와 클라우드 간의 차이를 추상화하는 것이 좋습니다. Kubernetes는 공통 런타임 레이어를 제공하므로 컴퓨팅 환경 전반에서 워크로드를 지속적으로 개발, 실행, 운영할 수 있습니다. 에지와 클라우드 간에 워크로드를 이동할 수도 있습니다.
- 하이브리드 설정 및 운영을 간소화하려면 이 아키텍처에 GKE Enterprise를 사용하면 됩니다(여러 환경에서 컨테이너가 사용되는 경우). 온프레미스 또는 에지 환경에서 실행 중인 GKE Enterprise 클러스터를 Google Cloud에 연결해야 하는 가능한 연결 옵션을 고려하세요.
- 이 패턴의 일환으로 일부 GKE Enterprise 구성요소는 Google Cloud에 대한 일시적인 연결 중단 중에 유지될 수 있지만, Google Cloud에서 연결이 끊어진 상태를 GKE Enterprise의 일반적인 작동 모드로 사용해서는 안 됩니다. 자세한 내용은 일시적인 Google Cloud 연결 해제로 인한 영향을 참조하세요.
- 여러 백엔드 및 에지 서비스 간에 프로토콜, API, 인증 메커니즘의 불일치를 해결하기 위해서는 가능한 경우 API 게이트웨이 또는 프록시를 통합 퍼사드로 배포하는 것이 좋습니다.
이러한 게이트웨이 또는 프록시는 중앙화된 컨트롤 포인트로 작동하며 다음과 같은 측정을 수행합니다.
- 추가 보안 측정을 구현합니다.
- 백엔드 코드 변경사항으로부터 클라이언트 앱과 기타 서비스를 보호합니다.
- 모든 교차 환경 애플리케이션과 분리된 구성요소 사이의 통신을 위한 감사 추적을 지원합니다.
- 기존 서비스와 및 현대화된 서비스 사이에 중간 통신 레이어 역할을 수행합니다.
- Apigee 및 Apigee Hybrid를 사용하면 온프레미스 환경, 에지, 기타 클라우드, Google Cloud 환경 간에 엔터프라이즈급 및 하이브리드 게이트웨이를 호스팅하고 관리할 수 있습니다.
- 환경 경계에서 시스템을 안전하게 인증할 수 있도록 환경 간에 일반 ID를 설정합니다.
- 환경 간에 교환되는 데이터가 민감한 정보일 수 있으므로, VPN 터널, TLS 또는 둘 다를 사용하여 모든 통신이 전송 중에 암호화되었는지 확인합니다.
환경 하이브리드 패턴
환경 하이브리드 아키텍처 패턴을 사용하면 기존 데이터 센터에 워크로드의 프로덕션 환경을 유지할 수 있습니다. 그런 다음 개발 및 테스트 환경 또는 기타 환경에 퍼블릭 클라우드를 사용합니다. 이 패턴은 여러 컴퓨팅 환경에 걸쳐 동일한 애플리케이션을 중복으로 배포하는 데 의존합니다. 이 배포의 목표는 용량, 민첩성, 복원력을 높이는 것입니다.
마이그레이션할 워크로드를 평가하는 경우, 퍼블릭 클라우드에서 특정 애플리케이션을 실행하면 다음과 같은 문제가 발생할 수 있습니다.
- 관할 구역 또는 규제 사항에 따라 특정 국가에 데이터를 보관해야 할 수 있습니다.
- 타사 라이선스 조건에 따라 클라우드 환경에서 특정 소프트웨어가 작동하지 않을 수 있습니다.
- 애플리케이션은 로컬에서만 사용할 수 있는 하드웨어 기기에 액세스해야 할 수 있습니다.
이 경우 프로덕션 환경뿐만 아니라 개발, 테스트, 스테이징 시스템을 포함하여 애플리케이션의 수명 주기에 관련된 모든 환경을 고려합니다. 이러한 제한사항은 프로덕션 환경과 해당 데이터에 적용되는 경우가 많습니다. 실제 데이터를 사용하지 않는 다른 환경에는 적용되지 않을 수 있습니다. 조직의 규정 준수 부서 또는 이에 상응하는 팀에 문의하세요.
다음 다이어그램은 일반적인 환경 하이브리드 아키텍처 패턴을 보여줍니다.
프로덕션 시스템과 다른 환경에서 개발 및 테스트 시스템을 실행하는 것은 위험해 보일 수 있으며 기존 권장사항 또는 환경 간의 차이를 최소화하려는 시도와 상충될 수 있습니다. 이러한 우려가 틀리지는 않지만, 개발 및 테스트 프로세스의 단계를 구분하는 경우에는 적용되지 않습니다.
개발, 테스트, 배포 프로세스는 애플리케이션마다 다르지만 일반적으로 다음과 같은 단계의 변화를 수반합니다.
- 개발: 출시 후보 생성
- 기능 테스트 또는 사용자 승인 테스트: 출시 후보가 기능 요구사항을 충족하는지 확인합니다.
- 성능 및 안정성 테스트: 출시 후보가 비기능 요구사항을 충족하는지 확인합니다. 부하 테스트라고도 합니다.
- 스테이징 또는 배포 테스트: 배포 절차가 작동하는지 확인
- 프로덕션: 신규 또는 업데이트된 애플리케이션을 출시합니다.
실질적으로 단일 환경에서는 이러한 단계를 두 개 이상 수행할 수 없으므로 일반적으로 각 단계에 전용 환경이 하나 이상 있어야 합니다.
테스트 환경의 주요 목적은 기능 테스트를 실행하는 것입니다. 스테이징 환경의 주요 목적은 애플리케이션 배포 절차가 의도한 대로 작동하는지 테스트하는 것입니다. 출시가 스테이징 환경에 도달할 시점에는 기능 테스트가 완료되어야 합니다. 스테이징은 소프트웨어를 프로덕션 배포에 배포하기 전의 마지막 단계입니다.
테스트 결과가 의미 있고 운영 배포에 적용되도록 하려면 애플리케이션 수명 주기 동안 사용하는 환경이 가능한 한 다음 규칙을 충족해야 합니다.
- 모든 환경은 기능적으로 동일합니다. 즉, 아키텍처, API, 운영체제 및 라이브러리 버전은 동일하며 시스템은 환경 전체에서 동일하게 작동합니다. 이러한 동일성은 애플리케이션이 한 환경에서 작동하지만 다른 환경에서 실패하거나 결함이 재현되지 않는 상황을 방지합니다.
- 성능 및 안정성 테스트, 스테이징, 프로덕션에 사용되는 환경은 비기능적으로 동등합니다. 즉, 성능, 규모, 구성, 운영 및 유지 관리되는 방식은 동일하거나 약간의 방식의 차이만 존재합니다. 그렇지 않으면 성능 및 스테이징 테스트가 무의미해집니다.
일반적으로 개발 및 기능 테스트에 사용되는 환경이 다른 환경과 기능적으로 다를 경우에는 문제가 없습니다.
다음 다이어그램에 표시된 대로 테스트 및 개발 환경은 Google Cloud에서 빌드됩니다. Cloud SQL과 같은 관리형 데이터베이스는 Google Cloud에서 개발 및 테스트를 위한 옵션으로 사용할 수 있습니다. 개발 및 테스트는 온프레미스 환경에서 동일한 데이터베이스 엔진과 버전, 기능적으로 동등한 버전 또는 테스트 단계 후 프로덕션 환경에 출시된 새 버전을 사용할 수 있습니다. 그러나 두 환경의 기본 인프라는 동일하지 않으므로 성능 부하 테스트에 이 접근 방식을 적용할 수 없습니다.
다음 시나리오는 환경 하이브리드 패턴과 잘 맞습니다.
- 해당하고 실행 가능한 경우 Kubernetes를 공통 런타임 레이어로 사용하여 모든 환경에서 기능적 동일성을 확보합니다.
Google Kubernetes Engine (GKE) Enterprise 버전은 이 접근 방식을 지원하는 핵심 기술이 될 수 있습니다.
- 워크로드 이동성을 보장하고 컴퓨팅 환경 간의 차이를 추상화합니다. 제로 트러스트 서비스 메시를 사용하면 다양한 환경 간에 필요한 통신 분리를 제어하고 유지할 수 있습니다.
- 퍼블릭 클라우드에서 개발 및 기능 테스트 환경을 실행합니다. 이러한 환경은 나머지 환경과 기능적으로 동일할 수 있지만 성능과 같은 비기능적인 측면은 다를 수 있습니다. 이 개념은 위의 다이어그램에 나와 있습니다.
- 비공개 컴퓨팅 환경에서 프로덕션, 스테이징, 성능 (부하 테스트) 및 안정성 테스트를 위한 환경을 실행하여 기능 및 비기능적 동일성을 보장합니다.
설계 고려사항
- 비즈니스 요구사항: 애플리케이션의 각 배포 및 출시 전략에는 고유한 장단점이 있습니다. 선택한 접근 방식이 특정 요구사항에 부합하는지 확인하려면 비즈니스 요구사항과 제약조건을 철저히 평가한 후 선택하세요.
- 환경 차이: 이 패턴의 일환으로 이 클라우드 환경을 사용하는 주된 목표는 개발 및 테스트입니다. 최종 상태는 테스트된 애플리케이션을 비공개 온프레미스 환경 (프로덕션)에서 호스팅하는 것입니다. 클라우드 환경에서는 예상대로 작동하지만 프로덕션 환경 (온프레미스)에서는 작동하지 않을 수 있는 기능을 개발하고 테스트하지 않으려면 기술팀에서 두 환경의 아키텍처와 기능을 알고 이해해야 합니다. 여기에는 다른 애플리케이션 및 하드웨어 인프라(예: 트래픽 검사를 실행하는 보안 시스템)에 대한 종속 항목이 포함됩니다.
- 거버넌스: 회사에서 클라우드에서 개발할 수 있는 항목과 테스트에 사용할 수 있는 데이터를 제어하려면 승인 및 거버넌스 프로세스를 사용하세요. 이 프로세스를 통해 회사는 온프레미스 프로덕션 환경에 없는 클라우드 기능을 개발 및 테스트 환경에서 사용하지 않도록 할 수도 있습니다.
- 성공 기준: 조직의 소프트웨어 품질 보증 표준에 부합하는 명확하고 사전 정의된 측정 가능한 테스트 성공 기준이 있어야 합니다. 개발하고 테스트하는 모든 애플리케이션에 이 표준을 적용합니다.
- 중복: 개발 및 테스트 환경에는 프로덕션 환경만큼 안정성이 필요하지는 않지만 중복 기능과 다양한 장애 시나리오를 테스트할 수 있는 기능이 필요합니다. 오류 시나리오 요구사항에 따라 개발 및 테스트 환경의 일부로 중복을 포함하도록 설계할 수 있습니다.
장점
퍼블릭 클라우드에서 개발 및 기능 테스트 워크로드를 실행하면 다음과 같은 몇 가지 이점이 있습니다.
- 필요에 따라 환경을 자동으로 시작하고 종료할 수 있습니다.
예를 들어 각 커밋 또는 가져오기 요청에 대해 전체 환경을 프로비저닝하고 테스트를 실행한 후 다시 사용 중지할 수 있습니다. 이 접근 방식에는 다음과 같은 이점도 있습니다.
- 비활성 상태인 가상 머신 (VM) 인스턴스를 중지하거나 온디맨드 방식으로만 환경을 프로비저닝하여 비용을 절감할 수 있습니다.
- 각 풀 리퀘스트에 대해 임시 환경을 시작하여 개발 및 테스트 속도를 높일 수 있습니다. 이렇게 하면 유지보수 오버헤드도 줄이고 빌드 환경의 불일치도 줄일 수 있습니다.
- 퍼블릭 클라우드에서 이러한 환경을 실행하면 클라우드 및 관련 도구에 대한 친숙성과 신뢰도가 높아지므로 다른 워크로드를 이전할 수 있습니다. 이 접근 방식은 컨테이너와 Kubernetes를 사용하여 워크로드 이동성을 살펴보려는 경우(예: 여러 환경에서 GKE Enterprise 사용) 특히 유용합니다.
권장사항
환경 하이브리드 아키텍처 패턴을 성공적으로 구현하려면 다음 권장사항을 고려하세요.
- 최적의 네트워크 및 보안 설계를 비롯한 애플리케이션 통신 요구사항을 정의합니다. 그런 다음 미러링된 네트워크 패턴을 사용하여 서로 다른 환경의 시스템 간에 직접 통신이 이루어지지 않도록 네트워크 아키텍처를 설계합니다. 여러 환경 간에 통신이 필요한 경우 제어된 방식으로 이루어져야 합니다.
선택하는 애플리케이션 배포 및 테스트 전략은 비즈니스 목표 및 요구사항에 부합해야 합니다. 여기에는 다운타임 없이 변경사항을 출시하거나, 광범위한 출시 전에 특정 환경 또는 사용자 그룹에 기능을 점진적으로 구현하는 것이 포함될 수 있습니다.
워크로드를 이동 가능하게 하고 환경 간의 차이를 없애려면 Kubernetes와 함께 컨테이너를 사용할 수 있습니다. 자세한 내용은 GKE Enterprise 하이브리드 환경 참조 아키텍처를 참조하세요.
워크로드를 배포, 구성, 운영하기 위해 컴퓨팅 환경에서 작동하는 공통 도구 체인을 설정합니다. Kubernetes를 사용하면 이러한 일관성을 유지할 수 있습니다.
CI/CD 파이프라인이 컴퓨팅 환경 전반에 걸쳐 일관적이며 동일한 바이너리, 패키지 또는 컨테이너 세트가 이러한 환경 전반에 걸쳐 배포되는지 확인합니다.
Kubernetes를 사용하는 경우 Tekton과 같은 CI 시스템을 사용하여 여러 환경에서 클러스터에 배포하고 작동하는 배포 파이프라인을 구현합니다. 자세한 내용은 Google Cloud의 DevOps 솔루션을 참고하세요.
안전하고 안정적인 애플리케이션을 지속적으로 출시하려면 보안을 DevOps 프로세스의 필수 부분으로 통합하세요 (DevSecOps). 자세한 내용은 Dev(Sec)Ops 도구 키트를 사용하여 1시간 이내에 인터넷에 노출된 애플리케이션을 배포하고 보호하기를 참고하세요.
Google Cloud 및 기존 클라우드 환경에서 동일한 도구를 사용하여 로깅 및 모니터링합니다. 오픈소스 모니터링 시스템을 사용하는 것이 좋습니다. 자세한 내용은 하이브리드 및 멀티 클라우드 모니터링 및 로깅 패턴을 참조하세요.
서로 다른 팀이 테스트 및 프로덕션 워크로드를 관리하는 경우 별도의 도구를 사용하는 것이 허용될 수 있습니다. 하지만 동일한 도구를 서로 다른 보기 권한으로 사용하면 교육 노력과 복잡성을 줄일 수 있습니다.
기능 테스트를 위해 데이터베이스, 스토리지, 메시지 서비스를 선택하는 경우 Google Cloud에서 동등하게 관리되는 제품을 사용합니다. 관리형 서비스를 사용하면 개발 및 테스트 환경을 유지하는 관리 작업이 줄어들 수 있습니다.
민감한 정보를 보호하려면 전송 중인 모든 통신을 암호화하는 것이 좋습니다. 연결 레이어에서 암호화가 필요한 경우 선택한 하이브리드 연결 솔루션에 따라 다양한 옵션을 사용할 수 있습니다. 이러한 옵션에는 VPN 터널, Cloud Interconnect를 통한 HA VPN, Cloud Interconnect용 MACsec이 포함됩니다.
다음 표에서는 일반적인 OSS 제품과 호환되는 Google Cloud 제품을 보여줍니다.
| OSS 제품 | Google Cloud 제품과 호환 가능 |
|---|---|
| Apache HBase | Bigtable |
| Apache Beam | Dataflow |
| CDAP | Cloud Data Fusion |
| Apache Hadoop | Dataproc |
| MySQL, PostgreSQL | Cloud SQL |
| Redis 클러스터, Redis, Memcached | Memorystore |
| 네트워크 파일 시스템(NFS) | Filestore |
| JMS, Kafka | Pub/Sub |
| Kubernetes | GKE Enterprise |
비즈니스 연속성 하이브리드 및 멀티 클라우드 패턴
업무상 중요한 시스템에 비즈니스 연속성을 고려하는 주요 동인은 조직에 장애가 발생하거나 그 이후에 우수한 복원력으로 비즈니스 운영을 지속할 수 있도록 돕기 위한 것입니다. 여러 지리적 리전에 걸쳐 시스템 및 데이터를 복제하고 단일 장애점을 방지함으로써 로컬 인프라에 영향을 미치는 자연 재해의 위험을 최소화할 수 있습니다. 다른 장애 시나리오에는 사이버 보안 공격이나 시스템 구성 오류에 이르는 심각한 시스템 오류가 포함됩니다.
장애를 견딜 수 있도록 시스템을 최적화하는 것은 효과적인 비즈니스 연속성을 구축하는 데 필수입니다. 시스템 안정성은 성능, 복원력, 업타임 가용성, 보안, 사용자 환경을 포함하되 이에 국한되지 않는 여러 요인의 영향을 받을 수 있습니다. Google Cloud에서 안정적인 서비스를 설계하고 운영하는 방법에 대한 자세한 내용은 Google Cloud 아키텍처 프레임워크의 안정성 요소와 Google Cloud의 안정성 구성 요소를 참조하세요.
이 아키텍처 패턴은 여러 컴퓨팅 환경에 걸친 애플리케이션의 중복 배포에 의존합니다. 이 패턴에서는 안정성을 높이기 위해 여러 컴퓨팅 환경에 동일한 애플리케이션을 배포합니다. 비즈니스 연속성은 중단 이벤트 후에도 사전 정의된 허용 가능한 수준에서 주요 비즈니스 기능 또는 서비스를 계속할 수 있는 조직의 능력으로 정의할 수 있습니다.
재해 복구(DR)는 비즈니스 연속성의 하위 집합으로 간주되며 중요한 비즈니스 기능을 지원하는 IT 시스템이 중단된 후 가능한 한 빨리 작동하도록 보장하는 데 중점을 둡니다. 일반적으로 DR 전략과 계획은 더 광범위한 비즈니스 연속성 전략을 수립하는 데 도움이 되는 경우가 많습니다. 기술적인 관점에서 재해 복구 전략 수립을 시작할 때 비즈니스 영향 분석에서는 목표 복구 시간(RPO)과 복구 시간 목표(RTO)라는 두 가지 주요 측정항목을 정의해야 합니다. Google Cloud를 사용하여 재해 복구를 처리하는 방법에 대한 자세한 내용은 재해 복구 계획 가이드를 참조하세요.
RPO 및 RTO 목표 값이 작을수록 최소한의 데이터 손실로 중단되었을 때 서비스를 더 빠르게 복구할 수 있습니다. 하지만 이는 중복 시스템 구축을 의미하기 때문에 비용이 많이 듭니다. 거의 실시간으로 데이터 복제를 수행할 수 있고 오류 발생 후 동일한 규모로 작동하는 중복 시스템은 복잡성, 관리 오버헤드 및 비용을 증가시킵니다.
DR 전략이나 패턴을 선택하는 결정은 비즈니스 영향 분석을 통해 이루어져야 합니다. 예를 들어 금융 서비스 조직의 경우 단 몇 분의 다운타임으로 인해 발생하는 재정적 손실이 DR 시스템 구현 비용을 훨씬 초과할 수 있습니다. 그러나 다른 업계의 기업에서는 상당한 비즈니스 영향 없이 몇 시간 동안 다운타임이 지속될 수 있습니다.
온프레미스 데이터 센터에서 업무상 중요한 시스템을 실행하는 경우 DR 접근방식 중 하나는 다른 리전의 두 번째 데이터 센터에서 대기 시스템을 유지보수하는 것입니다. 그러나 보다 비용 효율적인 접근 방식은 장애 조치 목적으로 퍼블릭 클라우드 기반 컴퓨팅 환경을 사용하는 것입니다. 이러한 접근 방식은 비즈니스 연속성 하이브리드 패턴의 주요 동인입니다. 클라우드는 사용하지 않을 때 일부 DR 인프라를 사용 중지할 수 있기 때문에 비용 측면에서 특히 매력적일 수 있습니다. 더 저렴한 DR 솔루션을 달성하기 위해 클라우드 솔루션을 통해 기업은 RPO 및 RTO 값의 잠재적 증가를 수용할 수 있습니다.
앞의 다이어그램은 클라우드를 온프레미스 환경에 대한 장애 조치 또는 재해 복구 환경으로 사용하는 방법을 보여줍니다.
이러한 패턴을 보다 덜 흔하면서 필수로 요구되는 경우가 적은 방식으로 변형한 패턴이 비즈니스 연속성 멀티 클라우드 패턴입니다. 이 패턴에서 프로덕션 환경은 하나의 클라우드 제공업체를 사용하고 DR 환경은 다른 클라우드 제공업체를 사용합니다. 여러 클라우드 공급업체 전반에 걸쳐 워크로드 복사본을 배포하면 멀티 리전 배포에서 제공하는 것보다 가용성을 높일 수 있습니다.
여러 클라우드에서 DR을 평가하는 것과 리전이 다른 하나의 클라우드 제공업체를 사용할 때는 다음을 포함한 여러 고려사항을 철저히 분석해야 합니다.
- 관리 효율성
- 보안
- 전반적인 실현 가능성
- 비용
- 둘 이상의 클라우드 제공업체로부터 발생할 수 있는 아웃바운드 데이터 전송 요금은 지속적인 클라우드 간 통신으로 인해 비용이 많이 들 수 있습니다.
- 데이터베이스를 복제하는 동안 대량의 트래픽이 발생할 수 있습니다.
- TCO 및 클라우드 간 네트워크 인프라 관리 비용이 듭니다.
규제 요구 사항을 충족하기 위해 데이터를 해당 국가에 보존해야 하는 경우 해당 국가에도 있는 두 번째 클라우드 제공업체를 DR로 사용하는 것이 옵션이 될 수 있습니다. 보조 클라우드 제공업체를 사용할 경우 온프레미스 환경을 사용하여 하이브리드 설정을 구축할 수 있는 옵션이 없다고 가정합니다. 클라우드 솔루션 재설계를 방지하려면 이상적으로 두 번째 클라우드 제공업체가 리전 내에서 필요한 모든 기능과 서비스를 제공해야 합니다.
설계 고려사항
- DR 기대치: 비즈니스가 달성하고자 하는 RPO 및 RTO 목표는 DR 아키텍처와 구축 계획을 이끌어야 합니다.
- 솔루션 아키텍처: 이 패턴을 사용할 경우 DR 기대치를 충족하도록 온프레미스 환경의 기존 기능을 복제해야 합니다. 따라서 클라우드 환경에서 동일한(또는 더 최적화된) 기능과 성능을 제공하기 위해 애플리케이션 재호스팅, 리팩터링 또는 재설계의 타당성과 실행 가능성을 평가해야 합니다.
- 설계 및 구축: 클라우드 환경에서 엔터프라이즈 워크로드를 배포하려면 시작 영역을 구축하는 것이 거의 항상 전제 조건입니다. 자세한 내용은 Google Cloud의 시작 영역 설계를 참조하세요.
DR 호출: DR 설계 및 프로세스에서는 다음 질문을 고려하는 것이 중요합니다.
- DR 시나리오를 트리거하는 요인은 무엇인가요? 예를 들어 기본 사이트의 특정 기능이나 시스템 오류에 의해 DR이 트리거될 수 있습니다.
- DR 환경에 대한 장애 조치는 어떻게 호출되나요? 수동 승인 프로세스인가요 아니면 낮은 RTO 목표를 달성하도록 자동화할 수 있나요?
- 예상되는 RTO에 맞춰 장애 조치를 호출하려면 시스템 오류 감지 및 알림 메커니즘을 어떻게 설계해야 할까요?
- 장애가 감지된 후 트래픽은 어떻게 DR 환경으로 다시 라우팅되나요?
테스트를 통해 이러한 질문에 대한 답을 검증하세요.
테스트: DR에 대한 장애 조치를 철저히 테스트하고 평가합니다. RPO 및 RTO 기대치를 충족하는지 확인하세요. 이렇게 하면 필요할 때 더 자신 있게 DR을 호출할 수 있습니다. 프로세스 또는 기술 솔루션에 새로운 변경이나 업데이트가 있을 때마다 테스트를 다시 수행하세요.
팀 기술: 환경이 제3자에 의해 관리되지 않는 한, 하나 이상의 기술팀이 클라우드 환경에서 프로덕션 워크로드를 빌드, 운영, 문제 해결할 수 있는 기술과 전문성을 보유하고 있어야 합니다.
장점
비즈니스 연속성을 위해 Google Cloud를 사용하면 다음과 같은 몇 가지 이점이 있습니다.
- Google Cloud에는 전 세계적으로 선택할 수 있는 리전이 많기 때문에 이를 사용하여 동일한 대륙 내의 다른 사이트에 데이터를 백업하거나 복제할 수 있습니다. 또한 다른 대륙의 사이트에 데이터를 백업하거나 복제할 수 있습니다.
- Google Cloud는 이중 리전 또는 멀티 리전 버킷의 Cloud Storage에 데이터를 저장하는 기능을 제공합니다. 데이터가 두 개 이상의 서로 다른 지리적 리전에 중복 저장됩니다. 이중 리전 및 멀티 리전 버킷에 저장된 데이터는 기본 복제를 사용하여 지리적 리전 간에 복제됩니다.
- DR 구축을 위한 자본 비용 및 운영 비용을 줄이기 위해 다음 중 하나 이상의 옵션을 제공합니다.
- 중지된 VM 인스턴스는 스토리지 비용만 발생하며 VM 인스턴스를 실행하는 것보다 훨씬 저렴합니다. 즉, 수동 대기 시스템의 유지 비용을 최소화할 수 있습니다.
- Google Cloud의 종량제 모델을 사용하면 실제로 사용한 스토리지 및 컴퓨팅 용량에 대해서만 비용을 지불합니다.
- 자동 확장과 같은 탄력성 기능을 사용하면 필요한 만큼 DR 환경을 자동 확장하거나 축소할 수 있습니다
예를 들어 다음 다이어그램은 Compute Engine, Cloud SQL, Cloud Load Balancing과 함께 Google Cloud의 복구 구성요소를 사용하는 온프레미스 환경(프로덕션)에서 실행되는 애플리케이션을 보여줍니다. 이 시나리오에서는 지속적인 데이터 복제로 더 빠르게 복구할 수 있도록 VM 기반 데이터베이스 또는 Cloud SQL과 같은 Google Cloud 관리형 데이터베이스를 사용하여 데이터베이스가 사전 프로비저닝됩니다. 일반 작업 중 비용을 줄이기 위해 사전 생성된 스냅샷에서 Compute Engine VM을 실행할 수 있습니다. 이렇게 설정하고 장애 이벤트가 발생하면 DNS는 Cloud Load Balancing 외부 IP 주소를 가리켜야 합니다.
클라우드에서 애플리케이션을 작동하려면 웹 및 애플리케이션 VM을 프로비저닝해야 합니다. 목표 RTO 수준과 회사 정책에 따라 DR 호출, 클라우드에서 워크로드 프로비저닝, 트래픽 재라우팅까지의 전체 프로세스를 수동 또는 자동으로 완료할 수 있습니다.
인프라 프로비저닝 속도를 높이고 자동화하려면 코드형 인프라를 관리하는 것이 좋습니다. 지속적 통합 서비스인 Cloud Build를 사용하여 Terraform 매니페스트를 환경에 자동으로 적용할 수 있습니다. 자세한 내용은 Terraform, Cloud Build, GitOps를 사용하여 코드형 인프라 관리를 참조하세요.
권장사항
비즈니스 연속성 패턴을 사용하는 경우, 다음 권장사항을 고려합니다.
- 장애 조치 및 복구 절차와 함께 인프라를 문서화하는 재해 복구 계획을 만듭니다.
- 비즈니스 영향 분석과 식별된 필수 RPO 및 RTO 목표를 기반으로 다음 조치를 고려하세요.
- 데이터만 백업할 때는 핸드오버 패턴을 사용하는 것이 좋습니다. 그렇지 않으면 메시 패턴이 기존 환경 네트워크 아키텍처를 복제하는 데 좋은 옵션이 될 수 있습니다.
- 특히 통신이 동시에 처리되는 경우, 서로 다른 환경에서 실행되는 시스템 간 종속 항목을 최소화합니다. 이러한 종속 항목으로 인해 성능과 전반적인 가용성이 저하될 수 있습니다.
분할 브레인 문제를 방지하세요. 여러 환경에서 양방향으로 데이터를 복제하는 경우, 분할 브레인 문제에 노출될 수 있습니다. 분할 브레인 문제는 데이터를 양방향으로 복제하는 두 환경에서 서로 통신이 끊길 때 발생합니다. 이러한 분할로 인해 두 환경의 시스템은 다른 환경을 사용할 수 없으며 데이터에 독점적으로 액세스할 수 있습니다. 이로 인해 데이터 수정이 충돌할 수 있습니다. 분할 브레인 문제를 방지하는 두 가지 일반적인 방법은 다음과 같습니다.
- 세 번째 컴퓨팅 환경을 사용합니다. 이 환경에서는 시스템이 데이터를 수정하기 전에 쿼럼을 확인할 수 있습니다.
연결이 복원된 후 충돌하는 데이터 수정이 조정되도록 허용합니다.
SQL 데이터베이스를 사용하면 클라이언트가 새 기본 인스턴스 사용을 시작하기 전에 원래 기본 인스턴스에 액세스할 수 없도록 하여 분할 브레인 문제를 방지할 수 있습니다. 자세한 내용은 Cloud SQL 데이터베이스 재해 복구를 참조하세요.
CI/CD 시스템과 아티팩트 저장소가 단일 장애점이 되지 않도록 합니다. 환경 하나를 사용할 수 없는 경우에도 새 출시를 배포하거나 구성 변경사항을 계속 적용할 수 있어야 합니다.
대기 시스템을 사용할 때 모든 워크로드를 이동할 수 있게 합니다. 시스템이 환경 간에 일관성을 유지하도록 모든 워크로드는 이동 가능해야 합니다(애플리케이션에서 지원되고 실행 가능한 경우). 컨테이너와 Kubernetes를 고려하여 이 접근 방식을 달성할 수 있습니다. Google Kubernetes Engine(GKE) Enterprise 버전을 사용하면 빌드 및 작업을 간소화할 수 있습니다.
대기 시스템 배포를 CI/CD 파이프라인에 통합합니다. 이러한 통합을 통해 애플리케이션 버전과 구성이 여러 환경에서 일관성을 유지할 수 있습니다.
재해 발생 시 사용자를 대기 시스템으로 다시 라우팅할 수 있도록 합리적으로 짧은 TTL(수명) 값으로 DNS를 구성하여 DNS 변경 사항이 빠르게 전파되도록 합니다.
아키텍처 및 솔루션 동작에 적합한 DNS 정책 및 라우팅 정책을 선택합니다. 또한 여러 리전의 부하 분산기를 DNS 라우팅 정책과 결합하여 하이브리드 설정을 포함한 다양한 사용 사례에 전역 부하 분산 아키텍처를 생성할 수 있습니다.
여러 DNS 제공업체를 사용합니다. 여러 DNS 제공업체를 사용하는 경우 다음과 같은 이점이 있습니다.
- 애플리케이션 및 서비스의 가용성과 복원력을 향상시킵니다.
여러 제공업체 DNS 구성을 사용하여 온프레미스 및 클라우드 환경 간에 종속 항목이 있는 하이브리드 애플리케이션의 배포 또는 마이그레이션을 간소화합니다.
Google Cloud는 다중 DNS 제공업체를 통해 환경을 설정하고 운영하는 데 도움이 되는 octoDNS 기반의 오픈소스 솔루션을 제공합니다. 자세한 내용은 Cloud DNS를 사용하는 다중 제공업체 공개 DNS를 참조하세요.
대기 시스템을 사용하여 자동 장애 조치를 만들 때는 부하 분산기를 사용합니다. 부하 분산기 하드웨어가 실패할 수 있다는 점에 유의하세요.
이 아키텍처 패턴을 사용할 때 발생하는 일부 시나리오를 지원하려면 하드웨어 부하 분산기 대신 Cloud Load Balancing을 사용합니다. 내부 클라이언트 요청 또는 외부 클라이언트 요청은 가중치 기반 트래픽 분할과 같은 다양한 측정항목을 기반으로 기본 환경이나 DR 환경으로 리디렉션될 수 있습니다. 자세한 내용은 전역 외부 애플리케이션 부하 분산기의 트래픽 관리 개요를 참조하세요.
Google Cloud서 다른 환경으로의 아웃바운드 데이터 전송량이 많은 경우 Cloud Interconnect 또는 Cross-Cloud Interconnect를 사용하는 것이 좋습니다. Cloud Interconnect는 연결 성능을 최적화하는 데 도움이 되며 특정 조건을 충족하는 트래픽에 대한 아웃바운드 데이터 전송 요금을 줄일 수 있습니다. 자세한 내용은 Cloud Interconnect 가격 책정을 참조하세요.
RPO 및 RTO 목표를 포함하여 요구사항을 충족하는 데이터 백업, 복제, 기타 태스크를 용이하게 하려면 Google Cloud Marketplace에서 선호하는 파트너 솔루션을 사용하는 것이 좋습니다.
DR 호출 시나리오를 테스트하고 평가하여 대상 RTO 값과 비교할 때 재해로부터 애플리케이션이 얼마나 쉽게 복구될 수 있는지 파악합니다.
전송 중 통신을 암호화합니다. Google은 민감한 정보를 보호하기 위해 모든 전송 중 통신을 암호화할 것을 권고합니다. 연결 레이어에서 암호화가 필요한 경우 선택한 하이브리드 연결 솔루션에 따라 다양한 옵션을 사용할 수 있습니다. 이러한 옵션에는 VPN 터널, Cloud Interconnect를 통한 HA VPN, Cloud Interconnect용 MACsec이 포함됩니다.
클라우드 버스팅 패턴
인터넷 애플리케이션은 사용량이 급격하게 변동될 수 있습니다. 대부분의 엔터프라이즈 애플리케이션은 이러한 문제를 겪지 않지만, 대부분의 기업에서는 다른 종류의 급격히 증가한 워크로드에 해당하는 일괄 또는 CI/CD 작업을 처리해야 합니다.
이 아키텍처 패턴은 여러 컴퓨팅 환경에 걸친 애플리케이션의 중복 배포에 의존합니다. 목표는 용량, 복원력 또는 둘 다 높이는 것입니다.
리소스 초과 프로비저닝을 통해 데이터 센터 기반 컴퓨팅 환경에서 급격히 증가하는 워크로드를 수용할 수 있지만 이 방식은 비용 면에서 효율적이지는 않습니다. 일괄 작업의 경우, 시간에 민감한 작업에서는 작업을 지연시키는 것이 쉽지는 않지만 장시간 동안 실행을 연장하여 사용을 최적화할 수 있습니다.
클라우드 버스트 패턴의 개념은 기준 부하에 비공개 컴퓨팅 환경을 사용하고 추가 용량이 필요할 때 일시적으로 클라우드로 전환하는 것입니다.
앞의 다이어그램에서 데이터 용량이 온프레미스 비공개 환경에서 한도에 도달한 경우 시스템은 필요시 Google Cloud 환경에서 추가 용량을 확보할 수 있습니다.
이 패턴의 주요 동인은 확장 요구사항 변경에 대응하는 데 필요한 비용을 절감하고 시간과 노력을 줄이는 것입니다. 이 방식을 사용하면 추가 부하를 처리할 때 사용하는 리소스에 대해서만 비용을 지불하면 됩니다. 즉, 인프라를 초과 프로비저닝할 필요가 없습니다. 대신 주문형 클라우드 리소스를 활용하고 수요와 사전 정의된 측정항목에 맞게 확장할 수 있습니다. 따라서 수요가 최대로 증가하는 기간에 서비스 중단을 방지할 수 있습니다.
클라우드 버스팅 시나리오의 잠재적인 요구사항은 워크로드 이동성입니다. 워크로드를 여러 환경에 배포하는 것을 허용할 때는 환경 간의 차이를 추상화해야 합니다. 예를 들어 Kubernetes는 서로 다른 인프라를 사용하는 다양한 환경에서 워크로드 수준의 일관성을 확보할 수 있는 기능을 제공합니다. 자세한 내용은 GKE Enterprise 하이브리드 환경 참조 아키텍처를 참조하세요.
설계 고려사항
클라우드 버스팅 패턴은 대화형 워크로드와 일괄 워크로드에 적용됩니다. 그러나 대화형 워크로드를 처리하는 경우에는 환경 간에 요청을 배포하는 방법을 결정해야 합니다.
유입되는 사용자 요청을 기존 데이터 센터에서 실행되는 부하 분산기로 라우팅한 후 부하 분산기가 요청을 로컬 및 클라우드 리소스에 배포하도록 할 수 있습니다.
이 방식을 사용하려면 기존 데이터 센터에서 실행 중인 부하 분산기 또는 다른 시스템이 클라우드에 할당된 리소스도 추적해야 합니다. 또한 부하 분산기 또는 다른 시스템이 리소스의 자동 확장 또는 축소 작업을 시작해야 합니다. 이 방식을 사용하면 활동이 적은 시간에 모든 클라우드 리소스를 사용 중단할 수 있습니다. 그러나 리소스를 추적하기 위한 메커니즘을 구현하는 것은 부하 분산기 솔루션의 기능을 초과할 수 있으므로 전반적인 복잡성이 증가할 수 있습니다.
리소스를 추적하기 위한 메커니즘을 구현하는 대신 하이브리드 연결 네트워크 엔드포인트 그룹(NEG) 백엔드와 함께 Cloud Load Balancing을 사용할 수 있습니다. 이 부하 분산기를 사용하여 내부 클라이언트 요청 또는 외부 클라이언트 요청을 온프레미스와 Google Cloud 모두에 있고 가중치 기반 트래픽 분할과 같은 다양한 측정항목을 기준으로 하는 백엔드로 라우팅합니다. 또한 Google Cloud의 워크로드에 대해 부하 분산 제공 용량을 기준으로 백엔드를 확장할 수 있습니다. 자세한 내용은 전역 외부 애플리케이션 부하 분산기의 트래픽 관리 개요를 참조하세요.
이 방식에는 Google Cloud Armor DDoS 보호 기능 및 WAF를 활용하거나 Cloud CDN을 사용하여 클라우드 에지에서 콘텐츠를 캐싱하는 등 몇 가지 추가적인 혜택이 있습니다. 하지만 추가 트래픽을 처리하려면 하이브리드 네트워크 연결의 크기를 조정해야 합니다.
워크로드 이동성에 강조 표시된 대로 워크로드 일관성을 달성하기 위해 변경을 최소한으로 수행하여 애플리케이션을 다른 환경으로 이동할 수 있지만 그렇다고 해서 애플리케이션이 두 환경 모두에서 동일하게 작동한다는 의미는 아닙니다. 일반적으로 종속 서비스에 대한 근접성과 함께 기본 컴퓨팅, 인프라 보안 기능 또는 네트워킹 인프라의 차이에 따라 성능이 결정됩니다. 테스트를 통해 보다 정확한 가시성을 확보하고 성능 예상치를 이해할 수 있습니다.
클라우드 인프라 서비스를 사용하여 이동성 없이 애플리케이션을 호스팅할 환경을 구축할 수 있습니다. 수요가 최대로 증가하는 기간에 트래픽이 리디렉션되는 경우 클라이언트 요청을 처리하려면 다음과 같은 방식을 사용하세요.
- 일관된 도구를 사용하여 이 두 환경을 모니터링하고 관리합니다.
- 워크로드 버전 관리의 일관성을 확보하고 데이터 소스가 최신 상태인지 확인합니다.
- 수요가 증가하고 클라우드 워크로드가 애플리케이션에 대한 클라이언트 요청을 수락할 것으로 예상될 때 클라우드 환경을 프로비저닝하고 트래픽을 다시 라우팅하기 위해 자동화 기능을 추가해야 할 수 있습니다.
수요가 낮은 기간에 모든 Google Cloud 리소스를 종료하려는 경우 트래픽 부하 분산에 주로 DNS 라우팅 정책을 사용하는 것이 항상 최적이 아닐 수 있습니다. 그 이유는 주로 다음과 같습니다.
- 사용자에게 서비스를 제공하기 전에 리소스를 초기화하는 데 다소 시간이 걸릴 수 있습니다.
- DNS 업데이트는 인터넷을 통해 느리게 전파되는 경향이 있습니다.
결과는 다음과 같습니다.
- 요청을 처리하는 데 사용할 수 있는 리소스가 없는 경우에도 사용자가 클라우드 환경으로 라우팅될 수 있습니다.
- DNS 업데이트가 인터넷을 통해 전파되는 동안 사용자가 온프레미스 환경으로 일시적으로 계속 라우팅될 수 있습니다.
Cloud DNS를 사용하면 위치정보 DNS 라우팅 정책과 같은 솔루션 아키텍처 및 동작에 맞는 DNS 정책 및 라우팅 정책을 선택할 수 있습니다. 또한 Cloud DNS는 내부 패스 스루 네트워크 부하 분산기 및 내부 애플리케이션 부하 분산기의 상태 점검을 지원합니다. 이 경우 이 패턴을 기반으로 하는 전체 하이브리드 DNS 설정에 이를 통합할 수 있습니다.
내부 애플리케이션 부하 분산기 또는 리전 간 내부 애플리케이션 부하 분산기를 사용할 때와 같이 일부 시나리오에서는 Cloud DNS를 사용하여 Google Cloud에서 상태 점검을 통해 클라이언트 요청을 분산시킬 수 있습니다. 이 시나리오에서 Cloud DNS는 자체적으로 백엔드 인스턴스의 상태를 점검하는 내부 애플리케이션 부하 분산기의 전반적인 상태를 점검합니다. 자세한 내용은 DNS 라우팅 정책 및 상태 점검 관리를 참조하세요.
Cloud DNS 분할 범위를 사용할 수도 있습니다. Cloud DNS 분할 범위는 동일한 도메인 이름에 대해 DNS 쿼리 시작자의 특정 위치 또는 네트워크에 DNS 응답 또는 레코드를 설정하는 방식입니다. 이 방식은 일반적으로 각각 고유한 기능이 포함된 비공개 환경과 공개 환경을 모두 제공하도록 애플리케이션을 설계하는 요구사항을 해결하는 데 사용됩니다. 이 방식은 환경 간에 트래픽 부하를 분산시키는 데도 도움이 됩니다.
이러한 사항을 고려할 때 클라우드 버스팅은 대개 대화형 워크로드보다 일괄 워크로드에 더 적합합니다.
장점
클라우드 버스팅 아키텍처 패턴의 주요 장점은 다음과 같습니다.
- 클라우드 버스팅을 통해 데이터 센터 및 비공개 컴퓨팅 환경에 대한 기존 투자를 재사용할 수 있습니다. 재사용은 영구적으로 가능하거나 기존 장비가 교체될 때까지 유효할 수 있으며, 장비 교체 시점이 되면 전체 이전을 고려할 수 있습니다.
- 최대 수요를 충족하기 위해 더 이상 초과 용량을 유지할 필요가 없으므로 비공개 컴퓨팅 환경의 사용과 비용 효율성을 높일 수 있습니다.
- 클라우드 버스팅을 통해 컴퓨팅 리소스를 초과 프로비저닝하지 않고도 일괄 작업을 적시에 실행할 수 있습니다.
권장사항
클라우드 버스팅 구현 시 다음 권장사항을 고려하세요.
- 클라우드에서 실행 중인 워크로드가 온프레미스 환경에서 실행 중인 워크로드와 동일한 방식으로 리소스에 액세스할 수 있도록 하려면 최소 권한의 보안 액세스 원칙이 적용된 meshed 패턴을 사용합니다. 워크로드 설계에서 허용하는 경우 클라우드에서 온프레미스 컴퓨팅 환경으로의 액세스만 허용하고 그 반대는 허용하지 않을 수 있습니다.
- 환경 간의 통신 지연 시간을 최소화하려면 비공개 컴퓨팅 환경과 지리적으로 가까운 Google Cloud 리전을 선택합니다. 자세한 내용은 Compute Engine 리전 선택 권장사항을 참조하세요.
- 일괄 워크로드에 대해서만 클라우드 버스팅을 사용하는 경우, 모든 Google Cloud 리소스를 비공개 상태로 유지하여 보안 공격 표면을 줄입니다. Google Cloud 외부 부하 분산을 사용하여 워크로드에 대한 진입점을 제공하는 경우에도 인터넷에서 이러한 리소스로의 직접 액세스를 허용하지 않습니다.
아키텍처 패턴 및 타겟팅된 솔루션 동작에 적합한 DNS 정책 및 라우팅 정책을 선택합니다.
- 이 패턴의 일부로 DNS 정책 설계를 영구적으로 적용하거나 수요가 최대로 증가하는 기간에 다른 환경을 사용하여 추가 용량이 필요할 때 적용할 수 있습니다.
- 위치정보 DNS 라우팅 정책을 사용하여 리전 부하 분산기의 전역 DNS 엔드포인트를 만들 수 있습니다. 이 전술에는 Google Cloud 리전이 있는 온프레미스 배포와 함께 Google Cloud를 사용하는 하이브리드 애플리케이션을 포함하여 위치정보 DNS 라우팅 정책의 다양한 사용 사례가 있습니다.
동일한 DNS 쿼리에 대해 서로 다른 레코드를 제공해야 하는 경우 내부 및 외부 클라이언트의 쿼리와 같이 분할된 범위의 DNS를 사용할 수 있습니다.
자세한 내용은 하이브리드 DNS용 참조 아키텍처를 참조하세요.
DNS 변경사항이 빠르게 전파되도록 하려면 클라우드 환경을 사용하여 추가 용량이 필요할 때 사용자를 대기 시스템으로 다시 라우팅할 수 있도록 비교적 짧은 TTL(수명) 값으로 DNS를 구성합니다.
시간이 크게 중요하지 않고 데이터를 로컬에 저장하지 않는 작업의 경우 일반 VM 인스턴스보다 훨씬 저렴한 스팟 VM 인스턴스 사용을 고려합니다. 그러나 VM 작업이 선점되는 경우 시스템이 자동으로 작업을 재시작할 수 있어야 합니다.
해당되는 경우 컨테이너를 사용하여 워크로드 이동성을 달성합니다. 또한 GKE Enterprise는 이 설계를 지원하는 핵심 기술이 될 수 있습니다. 자세한 내용은 GKE Enterprise 하이브리드 환경 참조 아키텍처를 참조하세요.
Google Cloud에서 다른 컴퓨팅 환경으로 전송되는 트래픽을 모니터링합니다. 이 트래픽에는 아웃바운드 데이터 전송 요금이 부과됩니다.
아웃바운드 데이터 전송 볼륨이 높은 이 아키텍처를 장기간 사용하려면 Cloud Interconnect 사용을 고려합니다. Cloud Interconnect는 연결 성능을 최적화하는 데 도움이 되며 특정 조건을 충족하는 트래픽에 대한 아웃바운드 데이터 전송 요금을 줄일 수 있습니다. 자세한 내용은 Cloud Interconnect 가격 책정을 참조하세요.
Cloud Load Balancing을 사용할 때 해당되는 경우 애플리케이션 용량 최적화 기능을 사용해야 합니다. 이렇게 하면 전역으로 분산된 애플리케이션에서 발생할 수 있는 용량 문제를 해결하는 데 도움이 됩니다.
환경 경계에서 시스템을 안전하게 인증할 수 있도록 환경 간에 일반 ID를 설정하여 시스템 사용자를 인증합니다.
민감한 정보를 보호하려면 전송 중인 모든 통신을 암호화하는 것이 좋습니다. 연결 레이어에서 암호화가 필요한 경우 선택한 하이브리드 연결 솔루션에 따라 다양한 옵션을 사용할 수 있습니다. 이러한 옵션에는 VPN 터널, Cloud Interconnect를 통한 HA VPN, Cloud Interconnect용 MACsec이 포함됩니다.
하이브리드 및 멀티 클라우드 아키텍처 패턴: 다음 단계
- 하이브리드 및 멀티 클라우드 아키텍처에 접근하는 방법과 적절한 워크로드를 선택하는 방법을 알아보세요.
- 선택한 하이브리드 및 멀티 클라우드 아키텍처 패턴에 적합한 네트워킹 아키텍처 패턴에 대해 자세히 알아보세요.
- 클라우드 애플리케이션의 배포 아키타입에 대해 자세히 알아보세요.
- GKE를 사용하는 마이크로서비스 기반 전자상거래 웹 애플리케이션, 서버리스 API 기반 동적 웹 애플리케이션 등 다양한 아키텍처를 사용하여 전자상거래 웹 애플리케이션을 설계하고 배포하는 방법을 알아봅니다.