이 아키텍처 가이드에서는 Google Cloud를 사용하여 하이브리드 및 멀티 클라우드 환경을 계획하고 설계하는 방법에 대한 실무 안내를 제공합니다. 이 문서는 세트의 세 문서 중 첫 번째 문서입니다. 비즈니스 및 기술 관점에서 이러한 아키텍처와 관련된 기회와 고려사항을 검토합니다. 또한 입증된 다양한 하이브리드 및 멀티 클라우드 아키텍처 패턴을 분석하고 논의합니다.
하이브리드 및 멀티 클라우드 아키텍처 패턴에 관한 문서 세트는 다음과 같이 구성됩니다.
- 하이브리드 및 멀티 클라우드 아키텍처 빌드: Google Cloud를 사용하여 하이브리드 및 멀티 클라우드 설정을 설계하기 위한 전략 계획을 논의합니다(이 문서).
- 하이브리드 및 멀티 클라우드 아키텍처 패턴: 하이브리드 및 멀티 클라우드 전략의 일부로 채택할 일반적인 아키텍처 패턴을 논의합니다.
- 하이브리드 및 멀티 클라우드 보안 네트워킹 아키텍처 패턴: 네트워킹 관점에서 하이브리드 및 멀티 클라우드 네트워킹 아키텍처 패턴을 논의합니다.
이러한 각 아키텍처 문서를 독립적으로 읽을 수 있지만 가장 큰 이점을 얻으려면 아키텍처 결정을 내리기 전에 순서대로 읽는 것이 좋습니다.
시장 수요의 급격한 변화로 인해 동적 확장, 최적화된 사용자 환경을 위한 성능 향상, 보안 등 엔터프라이즈 IT에 대한 요구사항과 기대치가 높아졌습니다. 많은 대기업에서 기존 인프라와 프로세스만으로는 이러한 요구와 기대치를 충족하는 데 어려움을 겪고 있습니다. IT 부서도 비용 효율성을 개선해야 한다는 압박을 받고 있어 데이터 센터 및 장비에 대한 추가 자본 투자를 정당화하기 어렵습니다.
퍼블릭 클라우드 컴퓨팅 기능을 사용하는 하이브리드 클라우드 전략은 실용적인 솔루션을 제공합니다. 퍼블릭 클라우드를 사용하면 초기 자본 투자 비용 없이 컴퓨팅 플랫폼의 용량 및 기능을 확장할 수 있습니다.
Google Cloud와 같은 하나 이상의 퍼블릭 클라우드 기반 솔루션을 기존 인프라에 추가하면 기존 투자를 유지할 수 있을 뿐만 아니라 단일 클라우드 공급업체에만 의존하지 않아도 됩니다. 또한 하이브리드 전략을 사용하면 리소스의 필요에 따라 애플리케이션 및 프로세스를 점진적으로 현대화할 수 있습니다.
아키텍처 결정과 하이브리드 또는 멀티 클라우드 전략 계획을 계획하는 데 도움이 되도록 고려해야 할 몇 가지 잠재적인 과제와 설계 고려사항이 있습니다. 여러 파트로 구성된 이 아키텍처 가이드는 다양한 아키텍처의 잠재적인 이점과 잠재적인 과제를 모두 강조합니다.
하이브리드 클라우드 및 멀티 클라우드 개요
기업의 고유한 워크로드, 인프라, 프로세스에 따른 각각의 니즈에 맞춰 하이브리드 클라우드 전략을 조정해야 합니다. 그 때문에 하이브리드 클라우드 및 멀티 클라우드라는 용어가 일관적이지 않게 사용되는 경우가 있습니다.
이 Google Cloud 아키텍처 가이드의 맥락에서 하이브리드 클라우드라는 용어는 워크로드가 여러 컴퓨팅 환경(예: 온프레미스 데이터 센터 또는 코로케이션 시설과 같이 퍼블릭 클라우드에 기반하고 적어도 하나는 비공개 환경에 기반)에 배포되는 아키텍처를 설명합니다.
멀티 클라우드라는 용어는 최소 두 개 이상의 공개 CSP를 결합하는 아키텍처를 의미합니다. 다음 다이어그램에 설명된 것처럼 때때로 이 아키텍처에는 비공개 컴퓨팅 환경(프라이빗 클라우드 구성요소 사용이 포함될 수 있음)이 포함됩니다. 이러한 구성을 하이브리드 및 멀티 클라우드 아키텍처라고 합니다.
참여자
저자: 마르완 알 샤위 | 파트너 고객 엔지니어
기타 참여자:
- 사우드 알바제이 | 고객 엔지니어, 애플리케이션 현대화
- 안나 베렌버그 | 엔지니어링 연구원
- 마르코 페라리 | 클라우드 솔루션 설계자
- 빅터 모레노 | Cloud Networking 제품 관리자
- 요하네스 패싱 | 클라우드 솔루션 설계자
- 마크 슐라겐하우프 | 네트워킹 테크니컬 라이터
- 다니엘 스트레벨 | 애플리케이션 현대화 부문 EMEA 솔루션 책임자
- 아밋 윌리엄스 | 개발자 관계팀 엔지니어
동인, 고려사항, 전략, 접근 방식
이 문서에서는 비즈니스 목표, 동인, 요구사항을 정의하고 설명하며, 이러한 요소가 하이브리드 및 멀티 클라우드 아키텍처를 구성할 때 설계 결정에 미치는 영향을 설명합니다.
목표
조직은 하이브리드 또는 멀티 클라우드 아키텍처를 특정 비즈니스 목표를 달성하기 위한 영구적인 솔루션으로 채택하거나 클라우드로의 이전과 같은 특정 요구사항을 용이하게 하기 위한 임시 상태로 채택할 수 있습니다.
비즈니스에 관한 다음 질문에 답변하면 비즈니스 요구사항을 정의하고 비즈니스 목표의 일부 또는 전부를 달성하는 방법에 관한 구체적인 기대치를 설정하는 데 도움이 됩니다. 이러한 질문은 기술적으로 이를 달성하는 방법이 아니라 비즈니스에 필요한 사항에 중점을 둡니다.
- 하이브리드 또는 멀티 클라우드 아키텍처를 채택하기로 한 결정의 근거가 되는 비즈니스 목표는 무엇인가요?
- 하이브리드 또는 멀티 클라우드 아키텍처는 어떤 비즈니스 및 기술 목표를 달성하는 데 도움이 되나요?
- 이러한 목표에 영향을 미친 비즈니스 요인은 무엇인가요?
- 구체적인 비즈니스 요구사항은 무엇인가요?
하이브리드 및 멀티클라우드 아키텍처의 맥락에서 기업 고객의 비즈니스 목표 중 하나는 단일 지역에서 온라인 판매 운영 또는 시장을 확장하여 시장 부문의 글로벌 리더 중 하나가 되는 것입니다. 비즈니스 목표 중 하나는 6개월 이내에 전 세계 (또는 특정 지역) 사용자의 구매 주문을 받기 시작하는 것입니다.
앞서 언급한 비즈니스 요구사항과 목표를 지원하기 위한 잠재적인 주요 기술적 목표 중 하나는 퍼블릭 클라우드의 글로벌 기능과 서비스를 사용하여 기업의 IT 인프라와 애플리케이션 아키텍처를 온프레미스 전용 모델에서 하이브리드 아키텍처로 확장하는 것입니다. 이 목표는 구체적이고 측정 가능해야 하며 대상 지역 및 타임라인 측면에서 확장 범위를 명확하게 정의해야 합니다.
일반적으로 하이브리드 또는 멀티 클라우드 아키텍처는 그 자체가 목표가 되는 경우는 거의 없으며 특정 비즈니스 요구사항에 따른 기술적 목표를 달성하기 위한 수단입니다. 따라서 적절한 하이브리드 또는 멀티 클라우드 아키텍처를 선택하려면 먼저 이 요구사항을 명확히 해야 합니다.
IT 프로젝트의 비즈니스 목표와 기술 목표를 구분하는 것이 중요합니다. 비즈니스 목표는 조직의 목표와 사명에 중점을 두어야 합니다. 기술적 목표는 조직이 비즈니스 요구사항과 목표를 충족할 수 있는 기술적 기반을 구축하는 데 중점을 두어야 합니다.
비즈니스 요인은 비즈니스 목표 및 목표 달성에 영향을 미칩니다. 따라서 비즈니스 요인을 명확하게 파악하면 시장 수요 및 동향과 더 관련성 높은 비즈니스 목표를 수립하는 데 도움이 될 수 있습니다.
다음 플로우 차트는 비즈니스 요인, 목표, 목적, 요구사항, 기술적 목표 및 요구사항, 그리고 이러한 모든 요소가 서로 어떻게 관련되어 있는지 보여줍니다.
비즈니스 및 기술적 동인
비즈니스 동인이 기술적 목표에 어떤 영향을 미치는지 고려하세요. 하이브리드 아키텍처를 선택할 때 영향을 미치는 일반적인 비즈니스 요인은 다음과 같습니다.
- 데이터 주권 관련 법률 및 규정에 유의
- 클라우드 재무 관리 및 FinOps와 같은 비용 최적화 분야의 지원을 받아 자본 지출 (CAPEX) 또는 일반 IT 지출을 줄입니다.
- 하이브리드 또는 멀티클라우드 아키텍처에서 재해 복구 솔루션을 빌드하는 것과 같이 CAPEX를 줄이는 데 도움이 되는 시나리오에 따라 클라우드 채택이 이루어질 수 있습니다.
- 사용자 환경 개선
- 변화하는 시장 수요에 맞게 유연성과 민첩성을 향상시킵니다.
- 비용 및 리소스 소비에 대한 투명성 개선
하이브리드 또는 멀티 클라우드 아키텍처를 함께 채택하기 위한 비즈니스 요인을 고려하세요. 개별적으로 고려하지 마세요. 최종 결정은 비즈니스 우선순위의 균형에 따라 달라야 합니다.
조직이 클라우드의 이점을 실현한 후에는 비용이나 높은 보안 수준의 데이터를 온프레미스에서 호스팅해야 하는 특정 규정 준수 요구사항과 같은 제약사항이 없다면 완전히 이전하기로 결정할 수 있습니다.
단일 클라우드 제공업체를 채택하면 복잡성 감소, 서비스 간 통합 내장, 약정 사용량 할인과 같은 비용 최적화 옵션과 같은 여러 이점을 얻을 수 있지만, 멀티클라우드 아키텍처가 비즈니스에 유용할 수 있는 시나리오도 있습니다. 다음은 멀티클라우드 아키텍처를 채택하는 일반적인 비즈니스 동인과 각 동인과 관련된 고려사항입니다.
- 데이터 주권 관련 법률 및 규정 준수: 가장 일반적인 시나리오는 조직이 새로운 지역 또는 국가로 비즈니스를 확장하고 새로운 데이터 호스팅 규정을 준수해야 하는 경우입니다.
- 기존에 사용 중인 클라우드 서비스 제공업체 (CSP)에 해당 국가에 로컬 클라우드 리전이 없는 경우 규정 준수를 위해 일반적인 해결 방법은 해당 국가에 로컬 클라우드 리전이 있는 다른 CSP를 사용하는 것입니다.
- 비용 절감: 비용 절감은 기술이나 아키텍처를 채택하는 가장 일반적인 비즈니스 요인입니다. 하지만 멀티 클라우드 아키텍처를 채택할지 결정할 때는 서비스 비용과 잠재적인 가격 할인 외에도 다른 요소를 고려해야 합니다. 여러 클라우드에서 솔루션을 빌드하고 운영하는 데 드는 비용과 기존 시스템에서 발생할 수 있는 아키텍처 제약 조건을 고려합니다.
멀티클라우드 전략과 관련된 잠재적 문제로 인해 얻는 이점이 적을 수 있습니다. 멀티 클라우드 전략을 사용하면 나중에 추가 비용이 발생할 수 있습니다.
멀티클라우드 전략을 개발하는 것과 관련된 일반적인 문제는 다음과 같습니다.
- 관리 복잡성 증가
- 일관된 보안 유지
- 소프트웨어 환경 통합
- 일관된 클라우드 간 성능과 안정성 달성
- 멀티클라우드 기술을 갖춘 기술팀을 구성하는 데는 비용이 많이 들 수 있으며, 서드 파티 회사에서 관리하지 않는 한 팀을 확장해야 할 수도 있습니다.
- 각 CSP의 제품 가격 책정 및 관리 도구를 관리합니다.
- 통합된 비용 가시성과 대시보드를 제공할 수 있는 솔루션이 없으면 여러 환경에서 비용을 효율적으로 관리하기 어려울 수 있습니다. 이 경우 해당하는 경우 Looker 클라우드 비용 관리 솔루션을 사용할 수 있습니다. 자세한 내용은 Cloud Billing 비용 관리를 효과적으로 최적화하기 위한 전략을 참고하세요.
- 각 CSP의 고유한 기능 사용: 멀티클라우드 아키텍처를 사용하면 조직이 단일 클라우드 제공업체에서 제공하는 옵션에 국한되지 않고 추가적인 신기술을 사용하여 자체 비즈니스 기능을 개선할 수 있습니다.
- 예상치 못한 위험이나 복잡성을 방지하려면 앞서 언급한 일반적인 문제를 비롯하여 실행 가능성 및 효과성 평가를 통해 잠재적인 문제를 평가하세요.
- 공급업체 종속 방지: 기업이 단일 클라우드 제공업체에 종속되지 않도록 하려는 경우가 있습니다. 멀티 클라우드 접근 방식을 사용하면 비즈니스 요구사항에 가장 적합한 솔루션을 선택할 수 있습니다. 그러나 이 결정의 실행 가능성은 다음과 같은 여러 요인에 따라 달라집니다.
- 기술적 종속 항목
- 애플리케이션 간 상호 운용성 고려사항
- 애플리케이션 다시 빌드 또는 리팩터링 비용
- 기술 스킬 세트
- 일관된 보안 및 관리 가능성
- 비즈니스 관련 중요도가 높은 애플리케이션의 안정성 및 가용성 수준 향상: 일부 시나리오에서는 멀티클라우드 아키텍처가 중단에 대한 복원력을 제공할 수 있습니다. 예를 들어 CSP의 한 리전이 다운되면 트래픽이 동일한 리전의 다른 CSP로 라우팅될 수 있습니다. 이 시나리오에서는 두 클라우드 제공업체 모두 해당 리전에서 필요한 기능 또는 서비스를 지원한다고 가정합니다.
특정 국가 또는 지역의 데이터 상주 규정에 따라 개인 식별 정보(PII)와 같은 민감한 정보를 해당 위치에 저장해야 하는 경우 멀티클라우드 접근 방식을 통해 규정을 준수하는 솔루션을 제공할 수 있습니다. 한 리전에서 두 개의 CSP를 사용하여 서비스 중단에 대한 탄력성을 제공하면 규제 제한사항을 준수하는 동시에 가용성 요구사항을 해결할 수 있습니다.
다음은 멀티클라우드 아키텍처를 채택하기 전에 평가해야 하는 몇 가지 탄력성 고려사항입니다.
- 데이터 이동: 멀티클라우드 환경 내에서 데이터가 얼마나 자주 이동하나요?
- 데이터 이동 시 상당한 데이터 전송 요금이 발생할 수 있나요?
- 보안 및 관리 가능성: 잠재적인 보안 또는 관리 복잡성이 있나요?
- 기능 패리티: 선택한 지역의 두 CSP 모두 필요한 기능과 서비스를 제공하나요?
- 기술 스킬 세트: 기술팀에 멀티 클라우드 아키텍처를 관리하는 데 필요한 기술이 있나요?
멀티클라우드 아키텍처를 사용하여 복원력을 개선하는 것이 타당한지 평가할 때는 이러한 모든 요소를 고려하세요.
멀티 클라우드 아키텍처의 실행 가능성을 평가할 때는 장기적 이점을 고려하는 것이 중요합니다. 예를 들어 재해 복구 또는 신뢰성 향상을 위해 여러 클라우드에 애플리케이션을 배포하면 단기적으로 비용이 증가할 수 있지만 서비스 중단이나 장애를 방지할 수 있습니다. 이러한 실패는 장기적인 재정적, 평판적 손상을 초래할 수 있습니다. 따라서 단기 비용과 멀티클라우드 채택의 장기적인 잠재적 가치를 비교하는 것이 중요합니다. 또한 장기적인 잠재적 가치는 조직 규모, 기술 규모, 기술 솔루션의 중요도, 업계에 따라 달라질 수 있습니다.
하이브리드 또는 멀티 클라우드 환경을 성공적으로 만들 계획인 조직은 Cloud Center of Excellence (COE)를 구축하는 것을 고려해야 합니다. COE팀은 클라우드로 전환하는 동안 조직 내 내부 팀이 비즈니스에 서비스를 제공하는 방식을 혁신하는 데 중추적인 역할을 할 수 있습니다. COE는 조직이 클라우드를 더 빠르게 채택하고, 표준화를 추진하며, 비즈니스 전략과 클라우드 투자 간의 조정을 강화할 수 있는 방법 중 하나입니다.
하이브리드 또는 멀티 클라우드 아키텍처의 목표가 임시 상태를 만드는 것이라면 일반적인 비즈니스 요인은 다음과 같습니다.
- 단기 프로젝트의 CAPEX 또는 일반 IT 지출을 줄여야 하는 필요성
- 비즈니스 사용 사례를 지원하기 위해 이러한 인프라를 빠르게 프로비저닝하는 기능 예를 들면 다음과 같습니다.
- 이 아키텍처는 기간 한정 프로젝트에 사용될 수 있습니다. 온프레미스 데이터를 계속 사용하는 동시에 제한된 기간 내에 대규모 분산 인프라가 필요한 프로젝트를 지원하는 데 사용할 수 있습니다.
- 대기업이 인프라 및 애플리케이션 현대화를 비즈니스 우선순위에 맞게 조정하는 데 도움이 되도록 하이브리드 아키텍처를 일정 기간 사용하고 구축해야 하는 다년간의 디지털 혁신 프로젝트의 필요성
- 기업 합병 후 임시 하이브리드, 멀티 클라우드 또는 혼합 아키텍처를 만들어야 하는 경우 이렇게 하면 새 조직에서 새 클라우드 아키텍처의 최종 상태에 대한 전략을 정의할 수 있습니다. 합병하는 두 회사가 서로 다른 클라우드 제공업체를 사용하거나 한 회사는 온프레미스 프라이빗 데이터 센터를 사용하고 다른 회사는 클라우드를 사용하는 경우가 많습니다. 두 경우 모두 합병 및 인수의 첫 번째 단계는 거의 항상 IT 시스템을 통합하는 것입니다.
기술적 요인
이전 섹션에서는 비즈니스 동인을 설명했습니다. 주요 아키텍처 결정을 승인받으려면 거의 항상 이러한 드라이버의 지원이 필요합니다. 그러나 기술적 이익이나 제약 조건에 기반할 수 있는 기술적 동인도 비즈니스 동인에 영향을 줄 수 있습니다. 경우에 따라 기술적 요인을 비즈니스 요인으로 변환하고 비즈니스에 긍정적이거나 부정적인 영향을 미칠 수 있는 방식을 설명해야 합니다.
다음 목록에는 하이브리드 또는 멀티클라우드 아키텍처를 채택하는 데 일반적으로 작용하는 기술적 요인 중 일부가 포함되어 있습니다.
- 고급 분석 서비스 및 AI와 같은 기술적 기능은 기존 환경에서 구현하기 어려울 수 있습니다.
- 서비스 품질 및 성능 개선
- 애플리케이션 롤아웃을 자동화 및 가속화하여 출시 시간 및 주기 시간 단축
- 높은 수준의 API 및 서비스를 사용하여 개발 속도를 높임
- 컴퓨팅 및 저장소 리소스 프로비저닝 가속화
- 서버리스 서비스를 사용하여 유연한 서비스와 기능을 더 빠르고 대규모로 빌드합니다.
- 글로벌 인프라 기능을 사용하여 글로벌 또는 멀티 리전 아키텍처를 빌드하여 특정 기술 요구사항을 충족합니다.
임시 하이브리드 및 임시 멀티클라우드 아키텍처 모두에서 가장 일반적인 기술적 동인은 온프레미스에서 클라우드 또는 추가 클라우드로의 마이그레이션을 용이하게 하는 것입니다. 일반적으로 클라우드 마이그레이션은 거의 항상 자연스럽게 하이브리드 클라우드 설정으로 이어집니다. 기업은 우선순위에 따라 애플리케이션과 데이터를 체계적으로 전환해야 하는 경우가 많습니다. 마찬가지로 단기 설정은 특정 기간 동안 클라우드에서 사용할 수 있는 고급 기술을 사용하여 개념 증명을 용이하게 하는 것을 목적으로 할 수 있습니다.
기술 설계 결정
확인된 기술적 목표와 그 요인은 비즈니스 중심의 아키텍처 결정을 내리고 이 가이드에서 설명하는 아키텍처 패턴 중 하나를 선택하는 데 중요합니다. 예를 들어 특정 비즈니스 목표를 지원하기 위해 회사는 3~6개월 동안 연구 및 개발 관행을 구축하기 위한 비즈니스 목표를 설정할 수 있습니다. 이 목표를 지원하기 위한 주요 비즈니스 요구사항은 가능한 한 최소한의 CAPEX로 연구 및 설계에 필요한 기술 환경을 구축하는 것입니다.
이 경우 기술적 목표는 임시 하이브리드 클라우드 설정을 갖추는 것입니다. 이 기술적 목표의 원동력은 클라우드의 주문형 가격 책정 모델을 활용하여 앞서 언급한 비즈니스 요구사항을 충족하는 것입니다. 또 다른 요인은 높은 컴퓨팅 용량과 빠른 설정이 가능한 클라우드 기반 솔루션이 필요한 특정 기술 요구사항의 영향을 받습니다.
하이브리드 및 멀티 클라우드 아키텍처에 Google Cloud 사용
오픈소스 솔루션을 사용하면 하이브리드 및 멀티 클라우드 접근 방식을 더 쉽게 채택하고 공급업체 종속을 최소화할 수 있습니다. 하지만 아키텍처를 계획할 때는 다음과 같은 잠재적 복잡성을 고려해야 합니다.
- 상호 운용성
- 관리 효율성
- 비용
- 보안
오픈소스에 기여하고 오픈소스를 지원하는 클라우드 플랫폼을 기반으로 하면 하이브리드 및 멀티 클라우드 아키텍처를 채택하는 과정을 간소화할 수 있습니다. 개방형 클라우드는 최대한의 선택권을 제공하고 복잡성을 추상화하는 접근 방식을 제공합니다. 또한 Google Cloud는 공급업체 종속을 최소화하고, 최고의 솔루션을 사용하며, 규제 요건을 충족하면서 하이브리드 및 멀티 클라우드 환경에서 애플리케이션을 유연하게 마이그레이션, 빌드, 최적화할 수 있는 유연성을 제공합니다.
Google은 오픈소스 생태계의 최대 참여자 중 하나이며 오픈소스 커뮤니티와 협력하여 Kubernetes와 같이 잘 알려진 오픈소스 기술을 개발하고 있습니다. Kubernetes를 관리형 서비스로 출시하면 하이브리드 및 멀티클라우드 관리 가능성과 보안과 관련된 복잡성을 줄일 수 있습니다.
하이브리드 및 멀티 클라우드 전략 계획
이 문서에서는 하이브리드 및 멀티 클라우드 전략을 계획할 때 사전 정의된 비즈니스 고려사항을 적용하는 방법을 중점적으로 설명합니다. 동인, 고려사항, 전략, 접근 방식으로 안내를 확장합니다. 이 자료에서는 기업에서 이러한 전략을 계획할 때 고려해야 할 비즈니스 고려사항을 정의하고 분석합니다.
비전 및 목표를 명확히 하고 합의합니다.
궁극적으로 하이브리드 또는 멀티 클라우드 전략의 주된 목적은 특정 비즈니스 목표에 맞춰 각 비즈니스 사용 사례에 대해 확인된 비즈니스 요구사항과 관련 기술 목표를 달성하는 것입니다. 이 목표를 달성하려면 다음 고려사항이 포함된 체계적인 계획을 세우세요.
- 각 컴퓨팅 환경에서 실행해야 하는 워크로드
- 여러 워크로드에 적용할 애플리케이션 아키텍처 패턴
- 사용할 기술 및 네트워킹 아키텍처 패턴
모든 워크로드와 요구사항을 고려하는 계획을 정의하기란 어려우며 특히 복잡한 IT 환경의 경우 더욱 그렇습니다. 게다가 계획을 수립하는 데는 시간이 걸리며 이로 인해 이해관계자의 비전이 상충될 수도 있습니다.
이러한 상황을 피하려면 최소한 다음 질문에 답하는 비전 성명서를 미리 작성합니다.
- 특정 비즈니스 목표를 달성하기 위한 타겟 비즈니스 사용 사례는 무엇인가요?
- 현재 접근 방식과 컴퓨팅 환경이 비즈니스 목표를 달성하기에 충분하지 않은 이유는 무엇인가요?
- 퍼블릭 클라우드를 사용하여 최적화할 주요 기술적 측면은 무엇인가요?
- 이 새로운 접근 방식으로 어떻게 비즈니스 목표를 최적화하고 달성할 수 있나요?
- 하이브리드 또는 멀티 클라우드 설정을 얼마나 오래 사용할 계획인가요?
핵심 비즈니스 및 기술 목표와 동인에 대해 합의한 다음 관련 이해관계자의 승인을 얻으면 계획 프로세스의 다음 단계에 대한 토대를 마련할 수 있습니다. 제안된 솔루션을 조직의 전체적인 아키텍처 비전과 효과적으로 일치시키려면, 이 이니셔티브를 이끌고 후원하는 팀 및 이해관계자와 협력하세요.
기타 고려사항을 파악하고 명확히 설명
하이브리드 또는 멀티 클라우드 아키텍처를 계획할 때는 프로젝트의 아키텍처 및 운영 제약조건을 파악하고 이에 동의하는 것이 중요합니다.
운영 측면에서 볼 때 다음 일부 목록은 아키텍처를 계획할 때 고려해야 할 몇 가지 제약 조건을 생성할 수 있는 몇 가지 요구 사항을 제공합니다.
- 여러 클라우드를 개별적으로 관리하고 구성하는 것과 다양한 클라우드 환경을 관리하고 보호하는 종합적인 모델을 구축하는 것 간에 선택합니다.
- 환경 전반에서 일관된 인증, 승인, 감사, 정책을 보장합니다.
- 여러 환경에서 일관된 도구와 프로세스를 사용하여 보안, 비용, 최적화 기회를 종합적으로 파악합니다.
- 일관된 규정 준수 및 보안 표준을 사용하여 통합 거버넌스를 적용합니다.
아키텍처 계획 측면에서 가장 큰 제약조건은 기존 시스템에서 비롯되는 경우가 많으며 다음 사항이 포함될 수 있습니다.
- 애플리케이션 간 종속 항목
- 시스템 간 통신을 위한 성능 및 지연 시간 요구사항
- 퍼블릭 클라우드에서 사용할 수 없는 하드웨어 또는 운영체제에 의존
- 라이선스 제한
- 멀티 클라우드 아키텍처의 선택된 리전에서 필요한 기능의 가용성에 대한 종속성
워크로드 이동성, 데이터 이동, 보안 측면과 관련된 기타 고려사항에 대해 자세히 알아보려면 기타 고려사항을 참조하세요.
하이브리드 및 멀티 클라우드 아키텍처 전략 설계
관련 비즈니스 요구 사항을 통해 비즈니스 및 기술 목표의 세부 사항을 명확히 한 후(이상적으로는 비전 선언문을 명확하게 하고 합의한 후) 하이브리드 또는 멀티 클라우드 아키텍처를 생성하기 위한 전략을 수립할 수 있습니다.
다음 플로우 차트는 이러한 전략을 수립하는 논리적 단계를 요약해서 보여줍니다.
하이브리드 또는 멀티 클라우드 아키텍처 기술 목표 및 요구 사항을 결정하는 데 도움이 되도록 이전 플로우 차트의 단계를 비즈니스 요구 사항 및 목표부터 시작합니다. 전략을 구현하는 방법은 각 비즈니스 사용 사례의 목표, 동인, 기술 마이그레이션 경로에 따라 달라질 수 있습니다.
기억해야 할 점은 마이그레이션이 여정이라는 것입니다. 다음 다이어그램은 Google Cloud로 마이그레이션에 설명된 대로 이 여정의 단계를 보여줍니다.
이 섹션에서는 위의 다이어그램에 나온 '평가', '계획', '배포', '최적화' 단계에 관한 안내를 제공합니다. 하이브리드 또는 멀티 클라우드 이전의 맥락에서 이 정보를 제공합니다. 모든 마이그레이션은 Google Cloud로 마이그레이션 가이드의 마이그레이션 경로 섹션에 설명된 안내 및 권장사항에 따라야 합니다. 이러한 단계는 모든 워크로드에 한 번에 적용되는 것이 아니라 각 워크로드에 개별적으로 적용될 수 있습니다. 특정 시점에서 여러 워크로드가 서로 다른 단계에 있을 수 있습니다.
평가 단계
평가 단계에서는 초기 워크로드 평가를 수행합니다. 이 단계에서는 비전 및 전략 계획 문서에 설명된 목표를 고려하세요. 퍼블릭 클라우드로 배포 또는 마이그레이션하면 이점을 얻을 수 있는 워크로드 후보 목록을 먼저 식별하여 마이그레이션 계획을 결정합니다.
시작하려면 비즈니스에 중요하지 않고 마이그레이션 마이그레이션하기 너무 어렵지 않은 워크로드(다른 환경의 워크로드에 대한 종속 항목이 거의 또는 전혀 없음)를 선택하되 향후 배포 또는 마이그레이션의 청사진으로 사용할 만큼 일반적인 워크로드를 선택합니다.
이상적으로는 선택한 워크로드 또는 애플리케이션은 완료 후 비즈니스에 측정 가능한 영향을 미치는 대상 비즈니스 사용 사례 또는 기능의 일부여야 합니다.
잠재적인 마이그레이션 위험을 평가하고 완화하려면 마이그레이션 위험 평가를 수행하세요. 멀티 클라우드 환경으로의 마이그레이션에 대한 적합성을 결정하려면 후보 워크로드를 평가하는 것이 중요합니다. 이 평가에는 다음을 포함하여 애플리케이션 및 인프라의 다양한 측면을 평가하는 작업이 포함됩니다.
- 선택한 클라우드 제공업체와의 애플리케이션 호환성 요구사항
- 가격 책정 모델
- 선택한 클라우드 제공업체에서 제공하는 보안 기능
- 애플리케이션 상호 운용성 요구사항
또한 평가를 실행하면 여러 클라우드 환경에서 데이터 개인 정보 보호 요건, 규정 준수 요구사항, 일관성 요구사항, 솔루션을 식별하는 데 도움이 됩니다. 파악한 위험은 마이그레이션하거나 운영할 워크로드에 영향을 줄 수 있습니다.
기존 워크로드를 평가하는 데 도움이 되는 Google Cloud Migration Center와 같은 여러 도구 유형이 있습니다. 자세한 내용은 Google Cloud로 마이그레이션: 평가 도구 선택을 참고하세요.
워크로드 현대화의 관점에서 볼 때 적합성 평가 도구는 VM 워크로드를 평가하여 워크로드가 컨테이너로 현대화할 수 있는지 또는 Compute Engine으로 마이그레이션할 수 있는지 결정하는 데 도움이 됩니다.
계획 단계
계획 단계에서 식별된 애플리케이션 및 필요한 클라우드 워크로드부터 시작하여 다음 작업을 수행합니다.
- 애플리케이션 마이그레이션 웨이브 및 경로를 정의하는 우선순위가 지정된 마이그레이션 전략을 수립합니다.
- 적용 가능한 상위 수준 하이브리드 또는 멀티 클라우드 애플리케이션 아키텍처 패턴을 식별합니다.
- 선택한 애플리케이션 아키텍처 패턴을 지원하는 네트워킹 아키텍처 패턴을 선택합니다.
이상적으로는 클라우드 네트워킹 패턴을 시작 영역 설계와 통합해야 합니다. 시작 영역 설계는 전반적인 하이브리드 및 멀티 클라우드 아키텍처의 핵심 기반 요소 역할을 합니다. 설계는 이러한 패턴과 원활하게 통합되어야 합니다. 시작 영역을 단독으로 설계하지 마세요. 이러한 네트워킹 패턴을 시작 영역 설계의 하위 집합으로 간주합니다.
시작 영역은 각각 다른 네트워킹 아키텍처 패턴을 사용하는 여러 애플리케이션으로 구성될 수 있습니다. 또한 이 단계에서는 하이브리드 또는 멀티 클라우드 통합 및 배포를 위한 클라우드 환경 시작 영역을 준비하기 위해 Google Cloud 조직, 프로젝트, 리소스 계층 구조의 설계를 결정하는 것이 중요합니다.
이 단계에서는 다음 사항을 고려해야 합니다.
- 이전 및 현대화 접근 방식을 정의합니다. 이전 접근 방식에 관한 자세한 내용은 이 가이드의 뒷부분을 참고하세요. Google Cloud로 이전의 이전 유형 섹션에서도 자세히 설명되어 있습니다.
- 평가 및 탐색 단계 발견 항목을 사용합니다. 이를 마이그레이션하려는 후보 워크로드에 일치시킵니다. 그런 다음 애플리케이션 마이그레이션 웨이브 계획을 개발합니다. 이 계획에는 평가 단계에서 결정한 예상 리소스 크기 요구사항이 포함되어야 합니다.
- 의도한 하이브리드 또는 멀티 클라우드 아키텍처의 분산 애플리케이션과 애플리케이션 구성요소 간에 필요한 통신 모델을 정의합니다.
- 선택한 아키텍처 패턴에 대해 영역, 리전, 멀티 리전, 전역과 같은 워크로드를 배포하는 데 적합한 배포 원형을 결정합니다. 선택한 원형은 비즈니스 및 기술 요구 사항에 맞는 애플리케이션별 배포 아키텍처를 구성하기 위한 기반을 형성합니다.
- 각 마이그레이션 단계 또는 웨이브의 명확한 주요 단계와 함께 마이그레이션의 측정 가능한 성공 기준을 결정합니다. 기술적 목표가 하이브리드 아키텍처를 단기 설정으로 갖추는 것이더라도 기준을 선택해야 합니다.
- 애플리케이션이 하이브리드 설정에서 작동하는 경우, 특히 여러 환경에 분산된 구성요소가 있을 수 있는 애플리케이션의 경우 애플리케이션 SLA 및 KPI를 정의합니다.
성공적인 마이그레이션을 계획하고 관련 위험을 최소화하는 데 도움이 되는 마이그레이션 계획에 대한 정보를 참조하세요.
배포 단계
배포 단계에서는 마이그레이션을 실행할 준비가 된 것입니다. 잠재적인 요구사항의 수를 고려할 때 반복적인 접근 방식을 사용하는 것이 가장 좋습니다.
계획 단계에서 개발한 마이그레이션 및 애플리케이션 웨이브를 기반으로 워크로드의 우선순위를 지정하세요. 하이브리드 및 멀티 클라우드 아키텍처를 사용하면 Google Cloud와 다른 컴퓨팅 환경 간에 필요한 연결을 설정하여 배포를 시작할 수 있습니다. 하이브리드 또는 멀티 클라우드 아키텍처에 필요한 통신 모델을 사용하려면 해당 네트워킹 패턴과 함께 선택한 설계 및 네트워크 연결 유형을 기준으로 배포를 수행해야 합니다. 전반적인 시작 영역 설계 결정에 이 접근 방식을 사용하는 것이 좋습니다.
또한 정의된 애플리케이션 성공 기준에 따라 애플리케이션 또는 서비스를 테스트하고 검증해야 합니다. 이상적으로 이러한 기준에는 프로덕션으로 이동하기 전에 기능 및 부하 테스트(비기능) 요구 사항이 모두 포함되어야 합니다.
최적화 단계
최적화 단계에서 배포 테스트: 테스트를 완료하고 애플리케이션 또는 서비스가 기능 및 성능 용량 기대치를 충족하면 프로덕션으로 이동할 수 있습니다. Cloud Monitoring과 같은 Cloud 모니터링 및 가시성 도구는 애플리케이션 및 인프라의 성능, 가용성, 상태에 대한 유용한 정보를 제공하고 필요한 경우 최적화하는 데 도움을 줄 수 있습니다.
자세한 내용은 Google Cloud로 마이그레이션: 환경 최적화를 참조하세요. 하이브리드 또는 멀티 클라우드 아키텍쳐용 도구를 설계하는 방법에 대한 자세한 내용은 하이브리드 및 멀티 클라우드 모니터링과 로깅 패턴을 참조하세요.
후보 워크로드 평가
다양한 워크로드에 적합한 컴퓨팅 환경을 선택하는 것은 하이브리드 및 멀티 클라우드 전략의 성공에 큰 영향을 미칩니다. 워크로드 배치 결정은 구체적인 비즈니스 목표에 부합해야 합니다 따라서 이러한 결정은 측정 가능한 비즈니스 효과를 제공하는 타겟팅된 비즈니스 사용 사례에 따라 이루어져야 합니다. 하지만 비즈니스상 가장 중요한 워크로드/애플리케이션으로 시작하는 것이 항상 필요하거나 권장되는 것은 아닙니다. 자세한 내용은 Google Cloud로 마이그레이션 가이드의 먼저 마이그레이션할 앱 선택을 참고하세요.
비즈니스 및 기술 동인 섹션에서 설명한 대로 하이브리드 및 멀티 클라우드 아키텍처에는 다양한 유형의 동인과 고려 사항이 있습니다.
다음 요소 요약 목록은 측정 가능한 비즈니스 효과를 얻을 수 있는 하이브리드 또는 멀티클라우드 아키텍처 컨텍스트에서 이전 사용 사례를 평가하는 데 도움이 됩니다.
- 기존 온프레미스 데이터를 사용하여 머신러닝 모델을 학습시키는 인공 지능 기능과 같은 특정 비즈니스 기능을 지원하기 위해 클라우드 서비스를 사용하여 실현할 수 있는 시장 차별화 또는 혁신 가능성
- 애플리케이션의 총 소유 비용 절약 가능성
- 가용성, 탄력성, 보안 또는 성능의 향상 가능성(예: 클라우드에 재해 복구(DR) 사이트 추가)
- 개발 및 출시 프로세스의 속도 향상 가능성(예: 클라우드에서 개발 및 테스트 환경 빌드)
다음 요소는 이전 위험을 평가하는 데 도움이 됩니다.
- 마이그레이션으로 인해 발생한 서비스 중단의 잠재적 영향
- 팀이 퍼블릭 클라우드 배포 경험이 있는지 또는 신규 클라우드 제공업체나 두 번째 클라우드 제공업체에 대한 배포 경험이 있는지 여부
- 기존 법률 또는 규정 제한을 준수해야 할 필요성
다음 요소는 마이그레이션의 기술적 어려움을 평가하는 데 도움이 됩니다.
- 애플리케이션의 크기, 복잡성, 수명
- 여러 컴퓨팅 환경에서 다른 애플리케이션 및 서비스와의 종속 항목 수입니다.
- 서드 파티 라이선스로 인한 제한사항
- 운영체제, 데이터베이스 또는 기타 환경 구성의 특정 버전에 대한 종속 항목
초기 워크로드를 평가했으면 우선순위를 정하고 마이그레이션 웨이브 및 접근 방식을 정의할 수 있습니다. 그런 다음 적용 가능한 아키텍처 패턴과 지원되는 네트워킹 패턴을 파악할 수 있습니다. 평가는 시간이 지남에 따라 달라질 수 있으므로 이 단계는 여러 번 반복해야 할 수 있습니다. 따라서 첫 번째 클라우드 배포를 수행한 후 워크로드를 다시 평가하는 것이 좋습니다.
하이브리드 또는 멀티 클라우드 아키텍처를 채택하기 위한 아키텍처 접근 방식
이 문서에서는 워크로드를 클라우드로 마이그레이션하기 위한 일반적이고 검증된 접근 방식과 고려사항에 대한 안내를 제공합니다. 하이브리드 또는 멀티 클라우드 아키텍처 채택을 위한 전략을 설계 안내에서 더 나아가 하이브리드 또는 멀티 클라우드 아키텍처 채택을 위한 전략을 설계하기 위해 몇 가지 가능하고 권장되는 단계를 논의합니다.
클라우드 우선
퍼블릭 클라우드를 사용하는 일반적인 방법은 클라우드 중심 접근 방식을 사용하는 것입니다. 이 접근 방식에서는 기존 워크로드는 그대로 유지하면서 새 워크로드를 퍼블릭 클라우드에 배포합니다. 이 경우 기술적인 이유 또는 조직상의 이유로 퍼블릭 클라우드 배포를 사용할 수 없는 경우에만 비공개 컴퓨팅 환경에 기존 배포를 사용하는 것이 좋습니다.
클라우드 우선 전략은 장단점이 있습니다. 긍정적인 측면에서 보면 클라우드 우선 전략은 미래 지향적입니다. 기존 워크로드를 이전하는 수고를 들이지 않거나 그 수고를 최소화하면서 현대화된 방식으로 새 워크로드를 배포할 수 있습니다.
클라우드 중심 접근 방식은 특정 이점을 제공할 수 있지만 기존 워크로드를 개선하거나 사용할 기회를 놓칠 수 있습니다. 새로운 워크로드는 전체 IT 환경의 일부에 해당할 수 있으며 IT 비용 및 성능에 미치는 영향은 제한적일 수 있습니다. 기존 워크로드를 마이그레이션하는 데 시간과 리소스를 할당하면 클라우드 환경에서 새 워크로드를 수용할 때보다 훨씬 더 큰 이점이 있거나 비용을 절감할 수 있습니다.
엄격한 클라우드 우선 전략을 따르면 IT 환경 전체의 복잡성이 높아질 수도 있습니다. 이러한 접근 방법은 잠재적인 과도한 환경 간 통신으로 인해 중복성, 성능 저하 또는 개별 워크로드에 적합하지 않은 컴퓨팅 환경을 초래할 수 있습니다. 또한 업계 규정 및 데이터 개인 정보 보호법을 준수하면 기업에서 민감한 정보를 보유한 특정 애플리케이션을 마이그레이션하는 것이 제한될 수 있습니다.
이런 위험을 감안할 때 선별한 워크로드에 대해서만 클라우드 우선 접근 방법을 사용하는 것이 좋습니다. 클라우드 중심 접근 방식을 사용하면 클라우드 배포 또는 마이그레이션에서 가장 많은 이점을 얻을 수 있는 워크로드에 집중할 수 있습니다. 이 접근 방식은 기존 워크로드의 현대화도 고려합니다.
클라우드 중심 하이브리드 아키텍처의 일반적인 예시는 중요한 데이터를 보유한 기존 애플리케이션 및 서비스를 새 데이터 또는 애플리케이션과 통합해야 하는 경우입니다. 통합을 완료하기 위해 API 인터페이스를 사용하여 기존 서비스를 현대화하는 하이브리드 아키텍처를 사용하면 새 클라우드 서비스 및 애플리케이션에서 사용할 수 있도록 잠금이 해제됩니다. Apigee와 같은 클라우드 API 관리 플랫폼을 사용하면 애플리케이션 변경을 최소화하면서 이러한 사용 사례를 구현하고 기존 서비스에 보안, 분석, 확장성을 추가할 수 있습니다.
마이그레이션 및 현대화
하이브리드 멀티 클라우드 및 IT 현대화는 서로 긍정적인 영향을 미치는 연결된 개념입니다. 퍼블릭 클라우드를 사용하면 IT 워크로드의 현대화를 촉진하고 간소화할 수 있습니다. IT 워크로드를 현대화하면 클라우드에서 더 많은 것을 얻을 수 있습니다.
워크로드 현대화의 주요 목표는 다음과 같습니다.
- 변화하는 요구사항에 대응할 수 있도록 민첩성 향상
- 인프라 및 운영 비용 절감
- 안정성과 복원력을 높여 위험 최소화
하지만 마이그레이션 프로세스의 모든 애플리케이션을 동시에 현대화하는 것이 불가능할 수 있습니다. Google Cloud에 마이그레이션에 설명된 대로 다음 마이그레이션 유형 중 하나를 구현하거나 필요에 따라 여러 유형을 조합할 수 있습니다.
- 재호스팅(리프트 앤 시프트)
- 플랫폼 변경(리프트 및 최적화)
- 리팩토링(이동 및 개선)
- 재설계(지속적인 현대화)
- 재빌드(삭제 및 교체(전면 교체라고도 함))
- 재구매
하이브리드 및 멀티 클라우드 아키텍처에 대한 전략적 결정을 내릴 때는 비용 및 시간 관점에서 전략의 실행 가능성을 고려하는 것이 중요합니다. 리프트 앤 시프트 또는 플랫폼 이전으로 시작해서 다음 단계로 리팩터링 또는 재설계하는 단계적 마이그레이션 접근 방식을 고려할 수 있습니다. 일반적으로 리프트 앤 시프트는 인프라 관점에서 애플리케이션을 최적화하는 데 도움이 됩니다. 클라우드에서 애플리케이션을 실행한 후에는 클라우드 우선 아키텍처와 기능을 사용하여 클라우드 서비스를 더 쉽게 사용하고 통합하여 최적화할 수 있습니다. 또한 이러한 애플리케이션은 하이브리드 네트워크 연결을 통해 다른 환경과 계속 통신할 수 있습니다.
예를 들어 대규모 모놀리식 VM 기반 애플리케이션을 리팩터링하거나 재설계하고 이를 클라우드 기반 마이크로서비스 아키텍처를 기반으로 여러 개의 독립적인 마이크로서비스로 전환할 수 있습니다. 이 예시에서 마이크로서비스 아키텍처는 Google Kubernetes Engine(GKE) 또는 Cloud Run과 같은 Google Cloud 관리형 컨테이너 서비스를 사용합니다. 그러나 애플리케이션의 아키텍처 또는 인프라가 대상 클라우드 환경에서 그대로 지원되지 않는 경우 이러한 제약 조건을 극복하기 위해 플랫폼 이전, 리팩터링 또는 마이그레이션 전략 재설계(가능한 경우)부터 시작하는 것을 고려할 수 있습니다.
이러한 마이그레이션 접근 방식을 사용할 때는 애플리케이션 현대화를 고려하세요(적용할 수 있고 실행 가능한 경우). 현대화에는 사이트 안정성 엔지니어링(SRE) 또는 DevOps 원칙을 채택하고 구현해야 할 수 있으므로 하이브리드 설정에서 애플리케이션 현대화를 비공개 환경으로 확장해야 할 수도 있습니다. SRE 원칙을 구현하는 데는 핵심적인 엔지니어링이 포함되지만 기술적 과제라기보다는 변환 프로세스에 가깝습니다. 따라서 절차적, 문화적 변화가 필요할 가능성이 높습니다. 조직에서 SRE를 구현하는 첫 번째 단계인 리더십 승인을 얻는 방법에 대해 자세히 알아보려면 SRE를 사용할 때 계획을 세우지 않는 것은 실패를 계획하는 것을 참조하세요.
다양한 마이그레이션 방법 조합
여기서 설명하는 각 마이그레이션 접근 방식에는 몇 가지 강점과 약점이 있습니다. 하이브리드 및 멀티 클라우드 전략을 따르는 경우의 장점은 단일 접근 방법만을 사용하지 않아도 된다는 것입니다. 그 대신 다음 다이어그램에 표시된 것처럼 각 워크로드 또는 애플리케이션 스택에 가장 적합한 방법을 결정할 수 있습니다.
이 개념 다이어그램은 각 워크로드 또는 애플리케이션의 고유한 비즈니스, 기술 요구 사항 및 목표에 따라 다양한 워크로드에 동시에 적용할 수 있는 다양한 마이그레이션 및 현대화 경로 또는 접근 방식을 보여줍니다.
또한 동일한 애플리케이션 스택 구성요소가 동일한 마이그레이션 접근 방식이나 전략을 따를 필요는 없습니다. 예를 들면 다음과 같습니다.
- 애플리케이션의 백엔드 온프레미스 데이터베이스는 Google Cloud의 Cloud SQL을 사용하여 자체 호스팅 MySQL에서 관리형 데이터베이스로 플랫폼을 이전할 수 있습니다.
- GKE Autopilot을 사용하여 컨테이너에서 실행되도록 애플리케이션 프런트엔드 가상 머신을 리팩터링할 수 있습니다. 여기서 Google은 노드, 확장, 보안, 기타 사전 구성된 설정을 포함한 클러스터 구성을 관리합니다.
- 온프레미스 하드웨어 부하 분산 솔루션 및 웹 애플리케이션 방화벽 WAF 기능은 Cloud Load Balancing 및 Google Cloud Armor로 대체될 수 있습니다.
워크로드가 다음 중 한 개라도 해당하는 경우 재호스팅(리프트 앤 시프트)을 선택합니다.
- 환경의 종속 항목 수가 상대적으로 적습니다.
- 리팩터링할 가치가 없거나 마이그레이션이 불가능하기 전에는 리팩터링할 가치가 없는 것으로 간주됩니다.
- 서드 파티 소프트웨어를 기반으로 합니다.
다음 워크로드 유형에는 리팩터링(이동 및 개선)을 고려하세요.
- 종속을 해제해야 하는 종속 항목이 있습니다.
- 클라우드에 수용할 수 없는 운영체제, 하드웨어 또는 데이터베이스 시스템을 사용합니다.
- 컴퓨팅 리소스 또는 저장소 리소스를 효율적으로 사용하지 않습니다.
- 약간의 노력 없이는 자동화된 방식으로 배포할 수 없습니다.
재빌드(삭제 및 교체)가 다음 유형의 워크로드에 대한 요구사항을 충족하는지 고려합니다.
- 더 이상 현재 요구사항을 충족하지 않습니다.
- 비즈니스 요구사항을 손상시키지 않고 유사한 기능을 제공하는 다른 애플리케이션과 통합할 수 있습니다.
- 서비스가 종료된 타사 기술을 기반으로 합니다.
- 더 이상 경제적이지 않은 타사 라이선스 비용이 필요합니다.
신속한 마이그레이션 프로그램은 Google Cloud에서 고객이 권장사항을 사용하고, 위험을 낮추고, 비용을 제어하고, 성공적인 클라우드로의 여정을 간소화하도록 돕는 방법을 보여줍니다.
기타 고려사항
이 문서에서는 전반적인 하이브리드 및 멀티 클라우드 아키텍처를 구성하는 데 중요한 역할을 하는 핵심 설계 고려사항을 중점적으로 설명합니다. 특정 워크로드뿐만 아니라 모든 워크로드를 포괄하여 전체 솔루션 아키텍처에서 이러한 고려사항을 종합적으로 분석하고 평가합니다.
리팩터링(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은 한 곳에서 모든 보안 데이터를 수집, 분석, 감지, 조사하여 보안 정보와 이벤트 관리를 제공합니다.
Google Cloud를 사용하여 하이브리드 및 멀티 클라우드 아키텍처 빌드: 다음 단계
- Google Cloud로 마이그레이션을 시작하는 방법 자세히 알아보기
- 하이브리드 및 멀티 클라우드의 일반적인 아키텍처 패턴과 가장 적합한 시나리오 및 적용 방법 알아보기
- 하이브리드 및 멀티 클라우드 아키텍처의 네트워킹 패턴과 설계 방법 자세히 알아보기
- Google Cloud에서 다양한 배포 원형을 살펴보고 분석하고 비교하기
- Google Cloud의 시작 영역 설계에 대해 알아보세요.
- Google Cloud 아키텍처 프레임워크에 대해 자세히 알아보기
- VM을 Compute Engine에 이전하기 위한 권장사항 읽어보기