이 문서에서는 전반적인 하이브리드 및 멀티 클라우드 아키텍처를 구성하는 데 중요한 역할을 하는 핵심 설계 고려사항을 중점적으로 설명합니다. 특정 워크로드뿐만 아니라 모든 워크로드를 포괄하여 전체 솔루션 아키텍처에서 이러한 고려사항을 종합적으로 분석하고 평가합니다.
리팩터링(Refactor)
리팩토링 마이그레이션에서는 워크로드가 새 환경에서 작동하는 것뿐만 아니라 클라우드 기능을 활용할 수 있도록 수정합니다. 성능, 기능, 비용, 사용자 환경에 적합하도록 각 워크로드를 개선할 수 있습니다. 리팩터링: 이동 및 개선에서 강조했듯이 일부 리팩터링 시나리오에서는 워크로드를 클라우드로 마이그레이션하기 전에 수정할 수 있습니다. 이러한 리팩터링 방식은 특히 하이브리드 아키텍처를 장기 대상 아키텍처로 빌드하는 것이 목표인 경우에 다음과 같은 이점을 제공합니다.
- 개발 프로세스를 향상시킬 수 있습니다.
- 지속적 통합/지속적 배포(CI/CD) 인프라와 도구에 투자하면 출시 주기를 가속화하고 피드백 사이클을 단축시킬 수 있습니다.
- 리팩터링을 기반으로 사용하여 애플리케이션 이동성을 갖춘 하이브리드 아키텍처를 빌드하고 관리할 수 있습니다.
이 방식이 잘 작동하게 하려면 일반적으로 온프레미스 인프라와 도구에 일정 부분 투자해야 합니다. 예를 들어 로컬 Container Registry를 설정하고 Kubernetes 클러스터를 프로비저닝하면 애플리케이션이 컨테이너화됩니다. 하이브리드 환경의 이 방식에서는 Google Kubernetes Engine(GKE) Enterprise 버전이 유용할 수 있습니다. 다음 섹션에서는 GKE Enterprise에 대한 자세한 내용을 다룹니다. 또한 자세한 내용은 GKE Enterprise 하이브리드 환경 참조 아키텍처를 참조하세요.
워크로드 이동성
하이브리드 및 멀티 클라우드 아키텍처에서는 데이터를 호스팅하는 컴퓨팅 환경 간에 워크로드를 이동할 수 있습니다. 워크로드가 환경 간에 원활하게 이동할 수 있게 하려면 다음 요인을 고려합니다.
- 애플리케이션과 해당 운영 모델을 크게 수정하지 않고도 애플리케이션을 한 컴퓨팅 환경에서 다른 컴퓨팅 환경으로 이동할 수 있습니다.
- 애플리케이션 배포와 관리는 컴퓨팅 환경 전반에서 일관적입니다.
- 가시성, 구성, 보안은 컴퓨팅 환경 전반에서 일관적입니다.
- 워크로드를 이동할 수 있게 하는 기능은 클라우드 중심이 되는 워크로드와 충돌해서는 안 됩니다.
인프라 자동화
인프라 자동화는 하이브리드 및 멀티 클라우드의 이동성에 필수적입니다. 인프라 생성을 자동화하는 일반적인 방법 중 하나는 코드형 인프라(IaC)를 사용하는 것입니다. IaC에는 사용자 인터페이스에서 VM, 보안 그룹 또는 부하 분산기와 같은 리소스를 수동으로 구성하는 대신 파일에서 인프라를 관리하는 작업이 포함됩니다. Terraform은 파일에서 인프라 리소스를 정의하는 데 널리 사용되는 IaC 도구입니다. Terraform을 사용하면 이기종 환경에서 이러한 리소스 생성을 자동화할 수도 있습니다.
Google Cloud 리소스 프로비저닝 및 관리 자동화에 도움이 되는 Terraform 핵심 기능에 대한 자세한 내용은 Google Cloud용 Terraform 청사진 및 모듈을 참조하세요.
Ansible, Puppet 또는 Chef와 같은 구성 관리 도구를 사용하여 공통 배포와 구성 프로세스를 설정할 수 있습니다. 또는 Packer와 같은 이미지 베이킹 도구를 사용하여 다양한 플랫폼의 VM 이미지를 만들 수 있습니다. 공유된 단일 구성 파일을 사용하면 Packer 및 Cloud Build를 사용하여 Compute Engine에서 사용할 VM 이미지를 만들 수 있습니다. 마지막으로 Prometheus 및 Grafana와 같은 솔루션을 사용하여 환경 전반에서 일관된 모니터링이 수행되도록 할 수 있습니다.
이러한 도구를 기반으로 다음 논리 다이어그램과 같이 공통 도구 체인을 조합할 수 있습니다. 이 공통 도구 체인은 컴퓨팅 환경 간의 차이를 없앱니다. 또한 프로비저닝, 배포, 관리 및 모니터링을 통합할 수 있습니다.
공통 도구 체인을 사용하면 이동성을 확보할 수 있지만 이 경우 몇 가지 단점이 있습니다.
- VM을 공통 기반으로 사용하면 진정한 클라우드 중심 애플리케이션을 구현하기가 어려워질 수 있습니다. 또한 VM만 사용하면 클라우드 관리형 서비스를 사용할 수 없게 됩니다. 관리 오버헤드를 줄일 수 있는 기회를 놓칠 수 있습니다.
- 공통 도구 체인을 빌드 및 유지보수하면 오버헤드와 운영 비용이 발생합니다.
- 도구 체인이 확장됨에 따라 회사의 특정 니즈에 맞춤화된 고유한 복잡성을 개발할 수 있습니다. 이렇게 복잡성이 증가하면 학습 비용이 증가할 수 있습니다.
도구와 자동화 개발을 결정하기 전에 클라우드 제공업체에서 제공하는 관리형 서비스를 살펴보세요. 제공업체에서 같은 사용 사례를 지원하는 관리형 서비스를 제공하면 복잡성을 일부 없앨 수 있습니다. 이렇게 하면 기본 인프라가 아닌 워크로드와 애플리케이션 아키텍처에 집중할 수 있습니다.
예를 들어 Kubernetes 리소스 모델을 사용하면 선언적 구성 방식을 통해 Kubernetes 클러스터 생성을 자동화할 수 있습니다. Deployment Manager 변환을 사용하여 Deployment Manager 구성과 템플릿을 Google Cloud에서 지원하는 다른 선언적 구성 형식(예: Terraform 및 Kubernetes 리소스 모델)으로 변환할 수 있으므로 게시하면 이동합니다.
또한 프로젝트 생성 및 해당 프로젝트 내에서 리소스 생성 자동화를 고려할 수 있습니다. 이 자동화는 프로젝트 프로비저닝에 코드형 인프라 방식을 채택하는 데 도움이 될 수 있습니다.
컨테이너와 Kubernetes
클라우드 관리형 기능을 사용하면 커스텀 도구 체인 빌드 및 유지보수에 대한 복잡성이 줄어들어 워크로드 자동화 및 이동성을 달성할 수 있습니다. 그러나 VM을 공통 기반으로만 사용하면 진정한 클라우드 중심 애플리케이션을 구현하기가 어려워집니다. 이를 해결할 수 있는 한 가지 해결책은 컨테이너와 Kubernetes를 대신 사용하는 것입니다.
컨테이너를 사용하면 소프트웨어를 환경 간에 이동하면서도 이를 안정적으로 실행할 수 있습니다. 컨테이너는 기본 호스트 인프라에서 애플리케이션을 분리하므로 하이브리드 및 멀티 클라우드와 같은 컴퓨팅 환경 전반에서 배포를 용이하게 합니다.
Kubernetes는 컨테이너화된 애플리케이션의 조정, 배포, 확장, 관리를 처리합니다. 오픈소스이며 Cloud Native Computing Foundation에서 관리합니다. Kubernetes를 사용하면 클라우드 중심 애플리케이션 기반을 형성하는 서비스가 제공됩니다. 다양한 컴퓨팅 환경에서 Kubernetes를 설치하고 실행할 수 있으므로 이를 사용하여 컴퓨팅 환경 전반에 공통 런타임 레이어를 설정할 수도 있습니다.
- Kubernetes는 클라우드 또는 사설 컴퓨팅 환경에 동일한 서비스 및 API를 제공합니다. 또한 VM 작업 시보다 추상화 레벨이 높기 때문에 일반적으로 수행할 기초 작업이 줄어들고 개발자 생산성이 향상됩니다.
- Kubernetes는 커스텀 도구 체인과는 달리 개발 및 애플리케이션 관리 모두에서 널리 채택되므로 기존 전문 지식, 문서, 타사 지원을 활용할 수 있습니다.
- Kubernetes는 다음과 같은 모든 컨테이너 구현을 지원합니다.
- Kubernetes 컨테이너 런타임 인터페이스(CRI) 지원
- 업계에서 애플리케이션에 대해 채택
- 특정 공급업체로 한정되지 않음
워크로드가 Google Cloud에서 실행되는 경우 Google Kubernetes Engine(GKE)과 같은 관리형 Kubernetes 플랫폼을 사용하여 Kubernetes를 간편하게 설치하고 운영할 수 있습니다. 이렇게 하면 운영 직원의 업무를 인프라 빌드 및 유지보수에서 애플리케이션 빌드 및 유지보수로 이동할 수 있습니다.
또한 노드 확장, 보안, 기타 사전 구성된 설정을 포함하여 클러스터 구성을 관리하는 GKE 운영 모드인 Autopilot을 사용할 수 있습니다. GKE Autopilot을 사용할 때는 확장 요구사항과 확장 한도를 고려합니다.
기술적으로는 여러 컴퓨팅 환경에서 Kubernetes를 설치하고 실행하여 공통 런타임 레이어를 설정할 수 있습니다. 그러나 사실상 이러한 아키텍처를 빌드하고 운영하면 복잡성이 가중될 수 있습니다. 컨테이너 수준 보안 제어(서비스 메시)가 필요하면 아키텍처가 더욱 복잡해집니다.
멀티 클러스터 배포 관리를 단순화하려면 GKE Enterprise를 사용하여 어디서나 최신 애플리케이션을 대규모로 실행하면 됩니다. GKE에는 워크로드를 보호하고 규정 준수 정책을 적용하며 심층적인 네트워크 관측 가능성과 문제 해결을 제공하는 강력한 관리형 오픈소스 구성요소가 포함되어 있습니다.
다음 다이어그램과 같이 GKE Enterprise를 사용하면 멀티 클러스터 애플리케이션을 Fleet으로 운영할 수 있습니다.
GKE Enterprise는 하이브리드 및 멀티 클라우드 아키텍처를 지원하기 위해 다음 설계 옵션을 지원합니다.
애플리케이션을 GKE Enterprise 하이브리드 환경으로 전환할 수 있도록 온프레미스나 통합 솔루션에 클라우드와 유사한 환경을 설계하고 빌드합니다. 자세한 내용은 GKE Enterprise 하이브리드 환경 참조 아키텍처를 참조하세요.
GKE Multi-cloud를 사용하여 일관된 거버넌스, 운영, 보안 상황에 따라 멀티 클라우드 복잡성을 해결하는 솔루션을 설계하고 빌드합니다. 자세한 내용은 GKE Multi-cloud 문서를 참조하세요.
또한 GKE Enterprise는 일관된 보안, 구성, 서비스 관리를 지원하는 유사한 환경의 논리적 그룹을 제공입니다. 예를 들어 GKE Enterprise는 제로 트러스트 분산형 아키텍처를 지원합니다. 제로 트러스트 분산형 아키텍처에서 온프레미스나 다른 클라우드 환경에 배포되는 서비스는 엔드 투 엔드 mTLS 보안 서비스 간 통신을 통해 환경 전체에서 통신할 수 있습니다.
워크로드 이식성 고려사항
Kubernetes 및 GKE Enterprise는 컴퓨팅 간의 다양한 복잡성과 차이점을 숨길 수 있는 워크로드 추상화 레이어를 제공합니다. 다음 목록에서는 이러한 추상화 중 일부를 설명합니다.
- 변경을 최소화하여 애플리케이션을 다른 환경으로 이동할 수 있지만 애플리케이션이 두 환경 모두에서 잘 작동한다는 의미는 아닙니다.
- 종속 서비스 근접성과 함께 기반 컴퓨팅, 인프라 보안 기능 또는 네트워킹 인프라의 차이로 인해 성능이 크게 달라질 수 있습니다.
- 컴퓨팅 환경 간에 워크로드를 이동하면 데이터도 이동해야 할 수 있습니다.
- 환경마다 데이터 스토리지, 관리 서비스, 시설이 다를 수 있습니다.
- Kubernetes 또는 GKE Enterprise로 프로비저닝된 부하 분산기의 동작과 성능은 환경마다 다를 수 있습니다.
데이터 이동
컴퓨팅 환경 간에 대규모 데이터를 이동, 공유, 액세스하는 것이 복잡할 수 있으므로 엔터프라이즈급 기업에서는 하이브리드 또는 멀티 클라우드 아키텍처 빌드를 주저할 수 있습니다. 이미 대부분의 데이터를 온프레미스나 클라우드 하나에 저장하고 있으면 더욱 주저할 수 있습니다.
그러나 Google Cloud에서 제공하는 다양한 데이터 이동 옵션은 기업에게 데이터를 이동, 통합, 변환하는 데 도움이 되는 포괄적인 솔루션 세트를 제공합니다. 이러한 옵션을 통해 기업은 자신의 특정 사용 사례를 충족하는 방식으로 여러 환경에서 데이터를 저장, 공유, 액세스할 수 있습니다. 궁극적으로 이러한 기능은 비즈니스 및 기술 의사 결정권자들은 더 쉽게 하이브리드 및 멀티 클라우드 아키텍처를 채택하게 합니다.
데이터 이동은 하이브리드 및 멀티 클라우드 전략과 아키텍처 계획에서 중요한 고려사항입니다. 팀은 다른 비즈니스 사용 사례와 사용 사례를 지원하는 데이터를 식별해야 합니다. 또한 스토리지 유형, 용량, 접근성 및 이동 옵션도 고려해야 합니다.
기업에게 규제 산업의 데이터 분류가 있는 경우 이러한 분류는 특정 데이터 클래스의 스토리지 위치와 리전 간 데이터 이동 제한사항을 식별하는 데 도움이 됩니다. 자세한 내용은 Sensitive Data Protection을 참조하세요. Sensitive Data Protection은 데이터 애셋을 검색, 분류, 보호할 수 있도록 설계된 완전 관리형 서비스입니다.
데이터 전송 계획부터 계획 구현 시 권장사항 사용에 이르기까지의 프로세스를 살펴보려면 Google Cloud로 마이그레이션: 대규모 데이터 세트 전송을 참조하세요.
보안
조직에서 하이브리드 및 멀티 클라우드 아키텍처를 채택함으로써 시스템과 데이터가 서로 다른 환경에서 분산되는 방식에 따라 공격 표면이 증가할 수 있습니다. 끊임없이 진화하는 위협 환경과 함께 공격 표면이 증가하면 무단 액세스, 데이터 손실, 기타 보안 이슈의 위험이 증가할 수 있습니다. 하이브리드 또는 멀티 클라우드 전략을 계획하고 구현할 때 보안을 신중하게 고려해야 합니다.
자세한 내용은 Google Cloud용 Attack Surface Management를 참조하세요.
하이브리드 아키텍처로 설계할 때 온프레미스 보안 방식을 클라우드로 확장하는 것이 항상 기술적으로 실행 가능한 것은 아닙니다. 그러나 하드웨어 어플라이언스의 네트워킹 보안 기능은 클라우드 중심 기능이며 분산 방식으로 작동합니다. Google Cloud의 클라우드 중심 네트워크 보안 기능에 대한 자세한 내용은 클라우드 네트워크 보안을 참조하세요.
하이브리드 및 멀티 클라우드 아키텍처로 인해 일관성 및 관측 가능성과 같은 추가적인 보안 문제가 발생할 수 있습니다. 퍼블릭 클라우드 제공업체마다 다양한 모델, 권장사항, 인프라 및 애플리케이션 보안 기능, 규정 준수 의무, 심지어 보안 서비스 이름을 포함한 고유한 보안 방식이 있습니다. 이러한 불일치는 보안 위험을 증가시킬 수 있습니다. 또한 공유 책임 모델은 클라우드 제공업체마다 다를 수 있습니다. 멀티 클라우드 아키텍처 내에서의 명확한 책임 경계를 식별하고 이해해야 합니다.
관측 가능성은 다양한 환경에서 유용한 정보와 측정항목을 얻기 위한 핵심입니다. 멀티 클라우드 아키텍처에서 일반적으로 각 클라우드는 보안 상황 및 잘못된 구성을 모니터링하는 도구를 제공합니다. 그러나 이러한 도구를 사용하면 가시성이 고립되어 전체 환경에서 고급 위협 인텔리전스를 빌드할 수 없습니다. 따라서 보안팀은 클라우드를 보호하기 위해 도구 또는 대시보드로 전환해야 합니다. 하이브리드 및 멀티 클라우드 환경에 중요한 엔드 투 엔드 보안 가시성이 없으면 취약점에 우선순위를 지정하고 취약점을 완화하기가 어렵습니다.
모든 환경의 전체 가시성과 상황을 얻으려면 취약점에 우선순위를 지정하고 식별한 취약점을 완화합니다. 중앙 집중식 가시성 모델을 사용하는 것이 좋습니다. 중앙 집중식 가시성 모델을 사용하면 여러 플랫폼의 여러 도구와 대시보드 간에 수동 상관관계를 사용할 필요가 없습니다. 자세한 내용은 하이브리드 및 멀티 클라우드 모니터링 및 로깅 패턴을 참조하세요.
보안 위험을 완화하고 워크로드를 Google Cloud에 배포하며 보안 및 규정 준수 목표를 달성하는 클라우드 솔루션을 계획 및 설계하도록 지원하는 계획의 일환으로 Google Cloud 보안 권장사항 센터 및 기업 기반 청사진을 살펴봅니다.
규정 준수 목표는 다양한 리전과 국가의 산업별 규정과 다양한 규제 요구 사항에 영향을 받으므로 다를 수 있습니다. 자세한 내용은 Google Cloud 규정 준수 리소스 센터를 참조하세요. 다음은 보안 하이브리드 및 멀티 클라우드 아키텍처에 권장되는 기본 방식 중 일부입니다.
맞춤형 통합 클라우드 보안 전략과 아키텍처를 개발합니다. 하이브리드 및 멀티 클라우드 보안 전략은 조직의 특정 니즈와 목표에 맞게 맞춤화되어야 합니다.
각 환경에서 다양한 기능, 구성, 서비스를 사용할 수 있으므로 보안 제어를 구현하기 전에 대상 아키텍처와 환경을 이해해야 합니다.
하이브리드 및 멀티 클라우드 환경 전반에서 통합 보안 아키텍처를 고려합니다.
클라우드 설계 및 배포, 특히 보안 설계와 기능을 표준화합니다. 이를 통해 효율성을 개선하고 통합 거버넌스와 도구를 사용 설정할 수 있습니다.
여러 보안 제어를 사용합니다.
일반적으로 단일 보안 제어만으로 모든 보안 보호 요구사항을 충분히 해결할 수 없습니다. 따라서 조직은 심층 방어라고도 하는 계층화된 방어 방식에 따라 보안 제어를 조합해서 사용해야 합니다.
보안 상황 모니터링 및 지속적인 개선: 조직은 다양한 환경을 모니터링하여 보안 위협과 취약점을 파악해야 합니다. 또한 보안 상황을 지속적으로 개선하기 위해 노력해야 합니다.
잘못된 보안 구성과 사이버 보안 위협을 식별하고 해결하는 데 클라우드 보안 상황 관리(CSPM)를 사용하는 것이 좋습니다. 또한 CSPM은 하이브리드 및 멀티 클라우드 전반에 걸쳐 취약점 평가 제공합니다.
Security Command Center는 Google Cloud에 기본 제공되는 보안 및 위험 관리 솔루션으로, 잘못된 구성과 취약점 등을 식별하는 데 도움이 됩니다. Security Health Analytics는 관리형 취약점 평가 스캔 도구입니다. Google Cloud 환경에서 보안 위험과 취약점을 식별하고 권장 해결책을 제공하는 Security Command Center 기능입니다.
Google Cloud용 Mandiant Attack Surface Management를 사용하면 조직에서 멀티 클라우드 또는 하이브리드 클라우드 환경 애셋을 더욱 잘 파악할 수 있습니다. 여러 클라우드 제공업체, DNS, 확장된 외부 공격 표면에서 애셋을 자동으로 검색하여 기업이 생태계를 심도 있게 이해할 수 있게 해줍니다. 이 정보를 사용하여 가장 위험한 취약점과 노출에 대한 해결 우선순위를 지정합니다.
- 클라우드 보안 정보 및 이벤트 관리(SIEM) 솔루션: 하이브리드 및 멀티 클라우드 환경에서 보안 로그 수집 및 분석하여 위협을 탐지하고 대응하도록 지원합니다. Google Cloud의 Google Security Operations SIEM은 한 곳에서 모든 보안 데이터를 수집, 분석, 감지, 조사하여 보안 정보와 이벤트 관리를 제공합니다.