하이브리드 및 다중 클라우드 패턴과 관행

이 문서는 하이브리드 및 다중 클라우드 배포, 아키텍처 패턴, 네트워크 토폴로지에 대해 설명하는 여러 부분으로 구성된 시리즈 중 1부입니다. 1부에서는 하이브리드 및 다중 클라우드 배포 기회와 문제점을 알아보고, Google Cloud Platform(GCP)을 사용하는 하이브리드 설정의 접근 방식과 구현 방법에 대한 안내를 제공합니다.

이 시리즈는 다음과 같은 부분으로 구성됩니다.

디지털화 및 변화하는 시장의 요구에 신속히 적응해야 하는 필요성으로 인해 기업 IT에 대한 요구사항과 기대가 커졌습니다. 많은 회사는 기존 인프라 및 프로세스를 사용하여 이러한 추세를 수용하고 이에 맞춰 조정하기가 어렵다고 생각합니다.

게다가 IT 부서는 비용 효율성을 높이기 위해 면밀한 감시와 압박을 받고 있기 때문에 데이터 센터와 장비를 확장하고 현대화하기 위한 추가 자본 지출(CapEx) 투자의 당위성을 입증하기가 어렵습니다.

하이브리드 클라우드 전략은 실용적인 솔루션을 제공합니다. 공용 클라우드를 사용하면 사전 CapEx 투자 없이 IT 용량 및 기능을 확장할 수 있습니다. 기존 인프라에 하나 이상의 클라우드 배포를 추가하면 기존 투자를 유지할 수 있을 뿐 아니라 단일 IT 공급업체에만 의존하지 않아도 됩니다. 또한 하이브리드 전략을 사용하면 리소스의 필요에 따라 애플리케이션 및 프로세스를 점진적으로 현대화할 수 있습니다.

하이브리드 클라우드 및 다중 클라우드

각 기업마다 작업 부하, 인프라, 프로세스가 고유하므로 특정 요구에 맞게 각 하이브리드 전략을 조정해야 합니다. 그 때문에 하이브리드 클라우드다중 클라우드라는 용어가 일관적이지 않게 사용되는 경우가 있습니다.

GCP 맥락에서 하이브리드 클라우드라는 용어는 공용 또는 상호 연결된 작업부하가 여러 컴퓨팅 환경 즉, 공용 클라우드 기반 하나와 사설 클라우드 하나 이상에 배포되어 있는 설정을 의미합니다.

가장 일반적인 예는 다음 다이어그램처럼 사설 컴퓨팅 환경을 결합하는 경우이며, 일반적으로 기존 온프레미스 데이터 센터와 공용 클라우드 컴퓨팅 환경을 결합합니다.

사설 컴퓨팅 환경과 공용 클라우드 컴퓨팅 환경 결합

다중 클라우드라는 용어는 다음 다이어그램처럼 공급업체 둘 이상의 공용 클라우드를 결합하는 설정을 의미합니다.

둘 이상의 공용 클라우드 공급업체를 결합하는 다중 클라우드 토폴로지

다중 클라우드 설정에는 사설 컴퓨팅 환경이 포함될 수도 있습니다.

둘 이상의 공용 클라우드 공급업체 및 사설 환경을 결합하는 다중 클라우드 토폴로지

하이브리드 클라우드 및 다중 클라우드 설정이 필요한 요인

하이브리드 및 다중 클라우드 설정은 일시적일 수 있으며 이전을 쉽게 수행할 수 있도록 제한된 시간 동안만 유지될 수 있습니다. 대부분의 조직이 각 시스템을 최대로 활용하기 위해 새 시스템을 빌드하고 기존 시스템을 발전시키므로 이러한 설정은 실행되는 위치와 상관없이 이 조직의 나중 상태를 나타낼 수도 있습니다. 따라서 하이브리드 및 다중 클라우드 설정은 IT 환경에서 영구적인 요소일 수 있습니다.

하이브리드 또는 다중 클라우드 설정은 목표가 아니라 비즈니스 요구사항을 충족하기 위한 수단입니다. 따라서 적절한 하이브리드 또는 다중 클라우드 설정을 선택하려면 먼저 이 요구사항을 명확히 해야 합니다.

비즈니스 동인 및 제약조건

비즈니스 측면의 일반적인 동인 및 제약조건은 다음과 같습니다.

  • CapEx 또는 일반 IT 지출 감소
  • 변화하는 시장 요구에 더 잘 대응할 수 있도록 유연성 및 민첩성 증대
  • 고급 분석 서비스와 같은 기능은 기존 환경에서 구현이 어려울 수 있음
  • 서비스 품질 및 가용성 향상
  • 비용 및 리소스 소비와 관련된 투명성 개선
  • 데이터 주권 관련 법률 및 규정에 유의
  • 공급업체에 종속되지 않도록 하거나 종속 비율 줄이기

설계 및 개발 동인

설계 및 개발 측면의 일반적인 동인은 다음과 같습니다.

  • 애플리케이션 롤아웃을 자동화 및 가속화하여 출시 시간 및 주기 시간 단축
  • 높은 수준의 API 및 서비스를 사용하여 개발 속도를 높임
  • 컴퓨팅 및 저장소 리소스 프로비저닝 가속화

운영 요구사항 및 제약조건

운영 측면에서 고려해야 할 요구사항 및 제약조건은 다음과 같습니다.

  • 컴퓨팅 환경 전반에서 일관된 인증, 승인, 감사, 정책 보장
  • 일관된 도구 및 프로세스를 사용하여 복잡성 제한
  • 환경 전반에서 가시성 제공

아키텍처 제약조건

아키텍처 측면에서 가장 큰 제약조건은 기존 시스템에서 비롯되는 경우가 많으며 다음 사항이 포함될 수 있습니다.

  • 애플리케이션 간 종속 항목
  • 시스템 간 통신을 위한 성능 및 지연 시간 요구사항
  • 공용 클라우드에서 사용할 수 없는 하드웨어 또는 운영체제에 의존
  • 라이선스 제한

전체 목표

하이브리드 및 다중 클라우드 전략의 목표는 다음을 설명하는 계획을 통해 이러한 요구사항을 충족시키는 것입니다.

  • 각 컴퓨팅 환경에서 실행하거나 각 컴퓨팅 환경으로 이전해야 하는 작업 부하
  • 여러 작업 부하에 적용할 패턴
  • 사용할 기술 및 네트워크 토폴로지

기본적으로 하이브리드 및 다중 클라우드 전략은 비즈니스 요구사항에 기반합니다. 하지만 비즈니스 요구사항에서 사용 가능한 전략을 도출하는 방법은 대부분 명확하지 않습니다. 선택하는 작업 부하, 아키텍처 패턴, 기술은 비즈니스 요구사항에 따라 달라질 뿐 아니라 서로 주기적으로 영향을 줍니다. 다음 다이어그램은 이 주기를 보여줍니다.

작업 부하, 패턴, 기술이 비즈니스 요구사항에 영향을 미치는 방식과 이들이 비즈니스 요구사항에 따라 달라지는 방식

비전 정의

이러한 종속 항목과 제약조건이 얽혀 있는 상황에서 모든 작업 부하와 요구사항을 고려하는 계획을 정의하기란 어려우며 특히 복잡한 IT 환경의 경우 더욱 그렇습니다. 게다가 계획을 수립하는 데는 시간이 걸리며 이로 인해 경쟁 관계에 있는 이해관계자가 이익을 볼 수도 있습니다.

이런 상황을 피하려면 먼저 비즈니스 관점에 초점을 맞추고 다음과 같은 질문에 답하는 비전을 세웁니다.

  • 현재 접근 방법과 컴퓨팅 환경이 충분하지 않은 이유는 무엇인가요?
  • 공용 클라우드를 사용하여 최적화할 주요 측정항목은 무엇인가요?
  • 하이브리드 또는 다중 클라우드 설정을 얼마나 오래 사용할 계획인가요? 이 설정을 영구적으로 사용할 계획인가요, 전체 클라우드 이전 기간 동안 일시적으로 사용할 계획인가요?

비전 선언문에는 이러한 목표를 달성하는 방법이 나와 있지 않습니다.

비전에 동의하고 관련 이해관계자의 승인을 얻으면 계획 프로세스의 다음 단계를 진행할 수 있습니다.

하이브리드 및 다중 클라우드 전략 설계

비전을 정한 후에는 전략을 자세히 설정할 수 있습니다.

  1. 초기 작업 부하 평가를 수행합니다. 비전 문서에 정리되어 있는 목표를 고려하면서 공용 클라우드로 배포하거나 이전함으로써 혜택을 얻을 수 있는 계획된 기존 작업 부하의 후보 목록을 파악합니다. 이 항목은 다음 섹션에서 자세히 논의합니다.

  2. 파악한 후보 작업 부하에서부터 적용 가능한 패턴을 파악하고 이 패턴을 바탕으로 후보 토폴로지를 파악합니다.

    적용 가능한 패턴 및 토폴로지가 둘 이상인 경우 단일 패턴 및 토폴로지를 결정할 수 있도록 작업 부하 선택 항목을 구체화하세요. 필요에 따라 반복하여 선택 항목을 좁힙니다.

    여러 패턴 및 토폴로지를 적용하는 방식은 대규모 조직에서 실행 가능한 접근 방법입니다. 하지만 이 접근 방법은 복잡성이 추가되어 진행 속도가 느려질 수 있으므로 이상적이라고 할 수 없습니다.

  3. 작업 부하의 우선순위를 지정합니다. 여러 요구사항을 고려할 때 반복적인 접근 방법을 사용하는 것이 가장 좋습니다.

  4. 공용 클라우드에 배포하거나 이전할 초기 작업 부하를 선택합니다. 이 작업 부하가 비즈니스와 관련해 중요도가 높지 않거나 이전하기가 매우 어렵더라도 예정된 배포 또는 이전을 수행하기 위한 청사진으로 사용할 수 있는지 확인합니다.

    이전할 작업 부하를 선택하는 동안 GCP 측에서 준비를 시작합니다.

  5. 첫 번째 배포를 위한 클라우드 환경을 준비하는 데 필요한 GCP 조직, 프로젝트, 정책을 설정합니다.

  6. 네트워크 토폴로지를 구현하고 GCP와 사설 컴퓨팅 환경 사이에 필요한 연결을 설정합니다.

작업 부하

어떤 컴퓨팅 환경에서 어떤 작업 부하를 실행할 것인지에 대한 결정은 하이브리드 및 다중 클라우드 전략의 효과에 큰 영향을 미칩니다. 클라우드에 잘못된 작업 부하를 배치하면 배포가 복잡해지며 이점을 거의 누릴 수 없게 됩니다. 적절한 위치에 적합한 작업 부하를 배치하면 작업 부하를 줄일 수 있을 뿐 아니라 각 환경의 혜택을 파악하는 데도 도움이 됩니다.

클라우드 우선

공용 클라우드를 사용하는 일반적인 방법은 클라우드를 우선 사용하는 것입니다. 이 접근 방법에서는 공용 클라우드에 새 작업 부하를 배포합니다. 이 경우 기술적인 이유 또는 조직상의 이유로 클라우드 배포를 사용할 수 없는 경우에만 사설 컴퓨팅 환경에 기존 배포를 사용하는 것이 좋습니다.

클라우드 우선 전략은 장단점이 있습니다. 긍정적인 측면에서 보면 클라우드 우선 전략은 미래 지향적입니다. 기존 작업 부하를 이전하는 수고를 들이지 않거나 그 수고를 최소화하면서 깔끔한 클라우드 네이티브 방식으로 새 작업 부하를 배포할 수 있습니다.

부정적인 측면에서 보면 클라우드 우선 전략을 사용하는 경우 기존 작업 부하를 활용할 기회를 놓칠 수 있습니다. 새로운 작업 부하는 전체 IT 작업 부하 중 일부에 불과할 수 있으며 전체 IT 지출 및 성능에 미치는 영향은 제한적일 수 있습니다. 기존 작업 부하를 이전하는 데 드는 시간은 클라우드에 새 작업 부하를 배포할 때보다 훨씬 더 큰 장점이 있거나 절약 효과가 있을 수 있습니다.

엄격한 클라우드 우선 전략을 따르면 IT 환경 전체의 복잡성이 높아질 수도 있습니다. 이러한 접근 방법은 과도한 환경 간 통신으로 인해 중복성, 성능 저하 또는 개별 작업 부하에 적합하지 않은 컴퓨팅 환경을 초래할 수 있습니다.

이런 위험을 감안할 때 선별한 작업 부하에 대해서만 클라우드 우선 접근 방법을 사용하는 것이 좋습니다. 그렇게 하면 클라우드 배포 또는 이전을 최대한 활용할 수 있는 작업 부하에 집중할 수 있습니다. 이 접근 방법은 기존 작업 부하의 현대화도 고려합니다. 이에 대해서는 다음 섹션에서 설명합니다.

이전 및 현대화

하이브리드/다중 클라우드 및 IT 현대화는 서로 긍정적인 영향을 미치는 연결된 개념입니다. 공용 클라우드를 사용하면 IT 작업 부하를 현대화하고 간소화할 수 있고 IT를 현대화하면 클라우드를 보다 잘 활용할 수 있습니다.

작업 부하 현대화의 주요 목표는 다음과 같습니다.

  • 변화하는 요구사항에 대응할 수 있도록 민첩성 향상
  • 인프라 및 운영 비용 절감
  • 안정성 및 탄력성을 향상하여 비즈니스 위험을 최소화

리프트 앤 시프트

리프트 앤 시프트는 작업 부하를 크게 변경하지 않고 사설 컴퓨팅 환경의 작업 부하를 공용 클라우드로 이전하는 프로세스를 설명합니다. 이 프로세스에는 기존 가상 머신(VM)과 해당 이미지를 Compute Engine으로 이전하는 작업이 포함되는 경우가 많습니다.

사설 컴퓨팅 환경이 아닌 Compute Engine에서 VM을 실행하면 다음과 같은 이점이 있습니다.

  • 컴퓨팅 및 저장소 리소스를 신속하게 프로비저닝하면 장비를 조달하여 기존(사설 또는 온프레미스) 데이터 센터에 설치할 때 발생하는 지연을 방지할 수 있습니다.

  • 선불 약정 또는 투자 없이 사용하는 컴퓨팅 리소스에 대해서만 비용을 지불합니다.

  • 결과적으로 운영 작업을 자동화하여 노력과 비용을 줄일 수 있습니다.

또한 애플리케이션을 클라우드 네이티브로 다시 작성하면 상당한 추가 이점을 얻을 수 있습니다.

  • 자동 확장을 사용하면 필요할 때만 컴퓨팅 리소스를 프로비저닝할 수 있으므로 과도한 프로비저닝 비용이 발생하지 않습니다.

  • Kubernetes와 같은 클러스터 관리자를 활용하면 오류 발생 시 애플리케이션을 자동으로 다시 시작하거나 다른 머신으로 이전하여 애플리케이션의 복원력을 높일 수 있습니다.

  • 관리형 서비스를 사용하면 운영 오버헤드를 더욱 줄일 수 있습니다.

  • 배포를 자동화하여 제품 개발 및 출시 프로세스를 가속화하면 비즈니스가 피드백, 변경 요구사항, 시장 요구에 더 신속하게 대응할 수 있습니다.

클라우드 네이티브 애플리케이션이 되도록 애플리케이션을 이동 및 변환하여 작업 부하 현대화

이 다이어그램에 나와 있는 것처럼 기존 작업 부하를 현대화할 때 애플리케이션을 클라우드로 이동하고 또한 애플리케이션을 클라우드 네이티브 애플리케이션으로 변환하는 것이 좋습니다.

변환 및 이동

변환에 투자하기 전에 애플리케이션을 클라우드로 이동하는 것이 일반적인 순서이지만 일부 애플리케이션은 정반대의 접근 방법을 취하는 것이 더 나을 수 있습니다. 변환 및 이동이란 이미 구현된 애플리케이션을 리팩토링하고 현대화하는 것으로 이전을 시작하는 것입니다. 애플리케이션을 클라우드로 이동하기 전에도 변환을 수행하면 다음과 같은 이점이 있습니다.

  • 개발 프로세스를 향상시킬 수 있습니다.

  • 지속적 통합/지속적 배포(CI/CD) 인프라 및 도구에 투자하면 출시 주기와 피드백 주기를 단축할 수 있습니다.

변환 후 애플리케이션을 클라우드로 이동하면 자동 확장 기능을 사용하여 리소스를 신속하게 프로비저닝하고 비용 효율성을 높일 수 있으므로 프로비저닝을 과도하게 수행하지 않게 됩니다.

변환과 이동이 원활히 수행되도록 하려면 로컬 Docker 레지스트리 설정과 같은 온프레미스 인프라 및 도구에 투자하고 Kubernetes 클러스터를 프로비저닝하여 애플리케이션을 컨테이너화하는 것이 좋습니다.

전면 교체

전면 교체는 시스템을 삭제하고 교체하는 것을 말합니다. 어떤 경우에는 기존 시스템 및 코드베이스를 발전시키는 것이 비용 면에서 효율적이지 않을 수 있으며 아예 불가능한 경우도 있습니다. 요구사항이 크게 변경되었거나 기존 애플리케이션이 향후 투자에 적합하지 않은 소프트웨어 또는 하드웨어를 기반으로 하는 경우가 있습니다. 이런 경우 시스템을 교체하는 것이 더 나은 방법일 수 있습니다. 즉, 새 솔루션을 구매하거나 처음부터 최신 클라우드 네이티브 애플리케이션을 개발할 수 있습니다.

여러 가지 이전 접근 방법을 혼합하여 사용

세 가지 이전 접근 방법 모두 강점과 약점이 있습니다. 하이브리드 및 다중 클라우드 전략을 따르는 경우의 장점은 단일 접근 방법만을 사용하지 않아도 된다는 것입니다. 그 대신 각 작업 부하에 가장 적합한 접근 방법을 결정할 수 있습니다.

작업 부하가 다음 중 한 개라도 해당하는 경우 리프트 앤 시프트를 선택합니다.

  • 환경의 종속 항목 수가 상대적으로 적습니다.
  • 리팩토링할 가치가 없는 것으로 간주됩니다.
  • 타사 소프트웨어를 기반으로 합니다.

다음 작업 부하 유형에는 변환 및 이동을 고려합니다.

  • 종속을 해제해야 하는 종속 항목이 있습니다.
  • 클라우드에 수용할 수 없는 운영체제, 하드웨어 또는 데이터베이스 시스템을 사용합니다.
  • 컴퓨팅 리소스 또는 저장소 리소스를 효율적으로 사용하지 않습니다.
  • 자동화된 방식으로 쉽게 배포할 수 없습니다.

마지막으로, 다음과 같은 작업 부하에는 전면 교체가 적합합니다.

  • 더 이상 현재 요구사항을 충족하지 않습니다.
  • 서비스가 종료된 타사 기술을 기반으로 합니다.
  • 더 이상 경제적이지 않은 타사 라이선스 비용이 필요합니다.

이동성

대부분의 이전에서 작업 부하를 클라우드로 이동하는 작업은 일회성이며 되돌릴 수 없습니다. 하지만 하이브리드 및 특히 다중 클라우드 시나리오인 경우 나중에 클라우드 간에 작업 부하를 이동하고자 할 수 있습니다. 이 기능을 사용하려면 작업 부하를 이동할 수 있는지 확인해야 합니다.

  • 대규모 수정 없이도 컴퓨팅 환경 간에 작업 부하를 이동할 수 있는지 확인합니다.
  • 애플리케이션 배포 및 관리가 컴퓨팅 환경 전반에서 일관적인지 확인합니다.
  • 작업 부하를 이동할 수 있게 만드는 작업이 클라우드 네이티브인 작업 부하와 충돌하지 않는지 확인합니다.

인프라 레벨에서 Terraform과 같은 도구를 사용하여 이기종 환경에서 인프라 리소스(예: VM 및 부하 분산기) 생성을 자동화하고 통합할 수 있습니다. 또한, Ansible, Puppet, Chef와 같은 구성 관리 도구를 사용하여 공통 배포 및 구성 프로세스를 설정할 수 있습니다. 또는 Packer와 같은 이미지 베이킹 도구를 사용하여 단일 공유 구성 파일로 다양한 플랫폼의 VM 이미지를 만들 수 있습니다. 마지막으로 Prometheus 및 Grafana와 같은 솔루션을 사용하여 환경 전반에서 일관된 모니터링이 수행되도록 할 수 있습니다.

이러한 도구를 기반으로 다음 다이어그램과 비슷한 도구 체인을 조합할 수 있습니다. 이 도구 체인은 컴퓨팅 환경 간 차이를 추상화하고 프로비저닝, 배포, 관리, 모니터링을 통합할 수 있도록 합니다.

컴퓨팅 환경 간 차이를 추상화하고 프로비저닝, 배포, 관리, 모니터링을 통합하도록 만드는 도구 체인

공통 도구 체인을 사용하면 이동성을 얻을 수 있지만 이 경우 몇 가지 단점이 있습니다.

  • 클라우드 환경이 기본적으로 제공하는 특정 기능을 사용하지 못할 수 있습니다. 특히 VM을 공통 기반으로 사용하면 진정한 클라우드 네이티브 애플리케이션을 구현하기가 어려워집니다. VM을 사용하면 관리형 서비스를 사용하지 못하게 되어 관리 오버헤드를 줄일 수 있는 기회를 놓치게 될 수 있습니다.

  • 도구 체인을 구성하고 유지하는 데 오버헤드 및 운영 비용이 발생합니다.

  • 시간이 지나면서 도구 체인이 회사에 고유한 방식으로 복잡해질 수 있습니다. 이러한 복잡성으로 인해 학습 비용이 증가할 수 있습니다.

컨테이너와 Kubernetes

VM을 사용하여 작업 부하를 이동할 수 있도록 만드는 커스텀 도구 체인을 구성하고 유지 관리하는 데는 많은 어려움이 따릅니다. 이를 해결할 수 있는 해결책 한 가지는 컨테이너와 Kubernetes를 대신 활용하는 것입니다.

컨테이너를 사용하면 소프트웨어를 환경 간에 이동하면서도 이를 안정적으로 실행할 수 있습니다. Kubernetes는 컨테이너화된 애플리케이션의 조정, 배포, 확장, 관리를 처리하여 클라우드 네이티브 애플리케이션의 기반을 형성하는 서비스를 제공합니다. 다양한 컴퓨팅 환경에서 Kubernetes를 설치하고 실행할 수 있으므로 이를 사용하여 컴퓨팅 환경 전반에 공통 런타임 레이어를 설정할 수도 있습니다.

  • Kubernetes는 클라우드 또는 사설 컴퓨팅 환경에 동일한 서비스 및 API를 제공합니다. 또한 VM 작업 시보다 추상화 레벨이 높기 때문에 일반적으로 수행할 기초 작업이 줄어들고 개발자 생산성이 향상됩니다.

  • Kubernetes는 커스텀 도구 체인과는 달리 개발 및 애플리케이션 관리 모두에서 널리 채택되므로 기존 전문 지식, 문서, 타사 지원을 활용할 수 있습니다.

  • Kubernetes는 Docker 컨테이너를 사용합니다. 이 컨테이너는 특정 공급업체에 종속되지 않는 업계에서 채택된 애플리케이션 패키징 표준입니다. Kubernetes 자체는 오픈소스이며 Cloud Native Computing Foundation이 관리합니다.

Google Kubernetes Engine(GKE)과 같은 관리형 Kubernetes 플랫폼을 사용하면 Kubernetes를 설치하고 운영하는 수고를 들이지 않아도 되므로 운영 직원은 인프라가 아닌 애플리케이션에 집중할 수 있습니다. 다음 다이어그램은 관리형 Kubernetes 플랫폼의 모습을 보여줍니다.

관리형 Kubernetes 플랫폼

작업 부하 이동성의 제한

작업 부하의 이동성을 높이기 위해 Kubernetes는 컴퓨팅 환경 간의 많은 복잡성과 차이점을 숨길 수 있는 추상화 레이어를 제공합니다.하지만 이 추상화에는 몇 가지 제한이 있습니다.

  • 변경을 최소한으로 수행하여 애플리케이션을 다른 환경으로 이동할 수 있지만 그렇다고 해서 애플리케이션이 두 환경 모두에서 잘 작동한다는 의미는 아닙니다. 종속 서비스 근접성 및 기반 컴퓨팅 또는 네트워킹 인프라의 차이로 인해 성능이 크게 달라질 수 있습니다.

  • 컴퓨팅 환경 간에 작업 부하를 이동하면 데이터도 이동해야 할 수 있습니다. 컴퓨팅 환경 간에 데이터를 복사하거나 이동하는 데 드는 시간, 노력, 예산 외에도 이러한 환경은 일반적으로 데이터를 저장하고 관리하기 위해 제공하는 서비스와 시설이 다릅니다.

  • Kubernetes는 다른 종류의 부하 분산기를 프로비저닝할 수 있는 통합된 방법을 제공합니다. 하지만 이러한 부하 분산기의 작동은 자세히 정의되어 있지 않으며 환경마다 미묘하게 다를 수 있습니다.

  • GKE는 역할 기반 액세스 제어(RBAC)를 Cloud Identity and Access Management와 통합하지만 다른 환경에서는 RBAC를 구성하고 작업 부하를 보호하는 방법이 다를 수 있습니다.

Kubernetes를 사용하더라도 컴퓨팅 환경이나 공용 클라우드 간 차이를 추상화하기가 어려울 수 있습니다. 작업 부하 이동성은 주로 자동화가 아닌 환경 간 이전 간소화를 목표로 합니다.

작업 부하 평가

진행 중인 새 프로젝트와 이미 실행 중인 수백 또는 수천 개의 작업 부하가 있는 경우 어떤 컴퓨팅 환경에 작업 부하를 배포하거나 이전할지 결정하기가 어려울 수 있습니다.

이런 결정을 일관되고 객관적으로 수행할 수 있도록 작업 부하를 기회, 위험, 기술적인 어려움별로 카테고리를 지정하고 점수를 매기는 것이 좋습니다.

다음 요소는 이전의 기회를 평가하는 데 도움이 됩니다.

  • 클라우드 서비스를 사용하여 실현할 수 있는 시장 차별화 또는 혁신 가능성
  • 애플리케이션의 총 소유 비용 절약 가능성
  • 가용성, 탄력성, 보안, 성능의 향상 가능성
  • 개발 및 출시 프로세스의 속도 향상 가능성

다음 요소는 이전의 위험을 평가하는 데 도움이 됩니다.

  • 처음에는 공용 클라우드 배포 경험이 제한적일 수 있다는 사실 또는 이전으로 인해 발생할 수 있는 중단의 영향
  • 기존 법률 또는 규정 제한을 준수해야 할 필요성

다음 요소는 이전의 기술적 어려움을 평가하는 데 도움이 됩니다.

  • 애플리케이션의 크기, 복잡성, 수명
  • 다른 애플리케이션과의 종속 항목 수
  • 타사 라이선스로 인한 제한사항
  • 운영체제, 데이터베이스 또는 기타 환경 구성의 특정 버전에 대한 종속 항목

초기 작업 부하를 평가했으면 작업 부하의 우선순위를 지정하고 적용 가능한 아키텍처 패턴네트워크 토폴로지를 파악할 수 있습니다. 이 단계는 여러 번 반복해야 할 수 있습니다. 시간이 지나면서 평가가 변경될 수 있기 때문에 첫 번째 클라우드 배포를 수행한 후에도 작업 부하를 다시 평가할 필요가 있습니다.

다음 단계

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...