환경 하이브리드 아키텍처 패턴을 사용하면 기존 데이터 센터에 워크로드의 프로덕션 환경을 유지할 수 있습니다. 그런 다음 개발 및 테스트 환경 또는 기타 환경에 퍼블릭 클라우드를 사용합니다. 이 패턴은 여러 컴퓨팅 환경에 걸쳐 동일한 애플리케이션을 중복으로 배포하는 데 의존합니다. 이 배포의 목표는 용량, 민첩성, 복원력을 높이는 것입니다.
마이그레이션할 워크로드를 평가하는 경우, 퍼블릭 클라우드에서 특정 애플리케이션을 실행하면 다음과 같은 문제가 발생할 수 있습니다.
- 관할 구역 또는 규제 사항에 따라 특정 국가에 데이터를 보관해야 할 수 있습니다.
- 타사 라이선스 조건에 따라 클라우드 환경에서 특정 소프트웨어가 작동하지 않을 수 있습니다.
- 애플리케이션은 로컬에서만 사용할 수 있는 하드웨어 기기에 액세스해야 할 수 있습니다.
이 경우 프로덕션 환경뿐만 아니라 개발, 테스트, 스테이징 시스템을 포함하여 애플리케이션의 수명 주기에 관련된 모든 환경을 고려합니다. 이러한 제한사항은 프로덕션 환경과 해당 데이터에 적용되는 경우가 많습니다. 실제 데이터를 사용하지 않는 다른 환경에는 적용되지 않을 수 있습니다. 조직의 규정 준수 부서 또는 이에 상응하는 팀에 문의하세요.
다음 다이어그램은 일반적인 환경 하이브리드 아키텍처 패턴을 보여줍니다.
프로덕션 시스템과 다른 환경에서 개발 및 테스트 시스템을 실행하는 것은 위험해 보일 수 있으며 기존 권장사항 또는 환경 간의 차이를 최소화하려는 시도와 상충될 수 있습니다. 이러한 우려가 틀리지는 않지만, 개발 및 테스트 프로세스의 단계를 구분하는 경우에는 적용되지 않습니다.
개발, 테스트, 배포 프로세스는 애플리케이션마다 다르지만 일반적으로 다음과 같은 단계의 변화를 수반합니다.
- 개발: 출시 후보 생성
- 기능 테스트 또는 사용자 승인 테스트: 출시 후보가 기능 요구사항을 충족하는지 확인합니다.
- 성능 및 안정성 테스트: 출시 후보가 비기능 요구사항을 충족하는지 확인합니다. 부하 테스트라고도 합니다.
- 스테이징 또는 배포 테스트: 배포 절차가 작동하는지 확인
- 프로덕션: 신규 또는 업데이트된 애플리케이션을 출시합니다.
실질적으로 단일 환경에서는 이러한 단계를 두 개 이상 수행할 수 없으므로 일반적으로 각 단계에 전용 환경이 하나 이상 있어야 합니다.
테스트 환경의 주요 목적은 기능 테스트를 실행하는 것입니다. 스테이징 환경의 주요 목적은 애플리케이션 배포 절차가 의도한 대로 작동하는지 테스트하는 것입니다. 출시가 스테이징 환경에 도달할 시점에는 기능 테스트가 완료되어야 합니다. 스테이징은 소프트웨어를 프로덕션 배포에 배포하기 전의 마지막 단계입니다.
테스트 결과가 의미 있고 운영 배포에 적용되도록 하려면 애플리케이션 수명 주기 동안 사용하는 환경이 가능한 한 다음 규칙을 충족해야 합니다.
- 모든 환경은 기능적으로 동일합니다. 즉, 아키텍처, API, 운영체제 및 라이브러리 버전은 동일하며 시스템은 환경 전체에서 동일하게 작동합니다. 이러한 동일성은 애플리케이션이 한 환경에서 작동하지만 다른 환경에서 실패하거나 결함이 재현되지 않는 상황을 방지합니다.
- 성능 및 안정성 테스트, 스테이징, 프로덕션에 사용되는 환경은 비기능적으로 동등합니다. 즉, 성능, 규모, 구성, 운영 및 유지 관리되는 방식은 동일하거나 약간의 방식의 차이만 존재합니다. 그렇지 않으면 성능 및 스테이징 테스트가 무의미해집니다.
일반적으로 개발 및 기능 테스트에 사용되는 환경이 다른 환경과 기능적으로 다를 경우에는 문제가 없습니다.
다음 다이어그램에 표시된 대로 테스트 및 개발 환경은 Google Cloud에서 빌드됩니다. Cloud SQL과 같은 관리형 데이터베이스는 Google Cloud에서 개발 및 테스트를 위한 옵션으로 사용할 수 있습니다. 개발 및 테스트는 온프레미스 환경에서 동일한 데이터베이스 엔진과 버전, 기능적으로 동등한 버전 또는 테스트 단계 후 프로덕션 환경에 출시된 새 버전을 사용할 수 있습니다. 그러나 두 환경의 기본 인프라는 동일하지 않으므로 성능 부하 테스트에 이 접근 방식을 적용할 수 없습니다.
다음 시나리오는 환경 하이브리드 패턴과 잘 맞습니다.
- 해당하고 실행 가능한 경우 Kubernetes를 공통 런타임 레이어로 사용하여 모든 환경에서 기능적 동일성을 확보합니다.
Google Kubernetes Engine (GKE) Enterprise 버전은 이 접근 방식을 지원하는 핵심 기술이 될 수 있습니다.
- 워크로드 이동성을 보장하고 컴퓨팅 환경 간의 차이를 추상화합니다. 제로 트러스트 서비스 메시를 사용하면 다양한 환경 간에 필요한 통신 분리를 제어하고 유지할 수 있습니다.
- 퍼블릭 클라우드에서 개발 및 기능 테스트 환경을 실행합니다. 이러한 환경은 나머지 환경과 기능적으로 동일할 수 있지만 성능과 같은 비기능적인 측면은 다를 수 있습니다. 이 개념은 위의 다이어그램에 나와 있습니다.
- 비공개 컴퓨팅 환경에서 프로덕션, 스테이징, 성능 (부하 테스트) 및 안정성 테스트를 위한 환경을 실행하여 기능 및 비기능적 동일성을 보장합니다.
설계 고려사항
- 비즈니스 요구사항: 애플리케이션의 각 배포 및 출시 전략에는 고유한 장단점이 있습니다. 선택한 접근 방식이 특정 요구사항에 부합하는지 확인하려면 비즈니스 요구사항과 제약조건을 철저히 평가한 후 선택하세요.
- 환경 차이: 이 패턴의 일환으로 이 클라우드 환경을 사용하는 주된 목표는 개발 및 테스트입니다. 최종 상태는 테스트된 애플리케이션을 비공개 온프레미스 환경 (프로덕션)에서 호스팅하는 것입니다. 클라우드 환경에서는 예상대로 작동하지만 프로덕션 환경 (온프레미스)에서는 작동하지 않을 수 있는 기능을 개발하고 테스트하지 않으려면 기술팀에서 두 환경의 아키텍처와 기능을 알고 이해해야 합니다. 여기에는 다른 애플리케이션 및 하드웨어 인프라(예: 트래픽 검사를 실행하는 보안 시스템)에 대한 종속 항목이 포함됩니다.
- 거버넌스: 회사에서 클라우드에서 개발할 수 있는 항목과 테스트에 사용할 수 있는 데이터를 제어하려면 승인 및 거버넌스 프로세스를 사용하세요. 이 프로세스를 통해 회사는 온프레미스 프로덕션 환경에 없는 클라우드 기능을 개발 및 테스트 환경에서 사용하지 않도록 할 수도 있습니다.
- 성공 기준: 조직의 소프트웨어 품질 보증 표준에 부합하는 명확하고 사전 정의된 측정 가능한 테스트 성공 기준이 있어야 합니다. 개발하고 테스트하는 모든 애플리케이션에 이 표준을 적용합니다.
- 중복: 개발 및 테스트 환경에는 프로덕션 환경만큼 안정성이 필요하지는 않지만 중복 기능과 다양한 장애 시나리오를 테스트할 수 있는 기능이 필요합니다. 오류 시나리오 요구사항에 따라 개발 및 테스트 환경의 일부로 중복을 포함하도록 설계할 수 있습니다.
장점
퍼블릭 클라우드에서 개발 및 기능 테스트 워크로드를 실행하면 다음과 같은 몇 가지 이점이 있습니다.
- 필요에 따라 환경을 자동으로 시작하고 종료할 수 있습니다.
예를 들어 각 커밋 또는 pull 요청에 대해 전체 환경을 프로비저닝하고 테스트를 실행한 다음 다시 사용 중지할 수 있습니다. 이 접근 방식에는 다음과 같은 이점도 있습니다.
- 비활성 상태인 가상 머신 (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 |