이 문서에서는 Istio 서비스 메시를 사용하여 가상 머신에서 애플리케이션을 실행하는 온프레미스 데이터 센터와 같은 기존 환경에서 Google Kubernetes Engine(GKE)으로 마이그레이션하는 아키텍처를 보여줍니다. 서비스 메시를 사용하면 네트워크 기능을 서비스 기능에서 분리하므로 마이그레이션 및 리팩토링의 복잡성을 줄일 수 있습니다.
이 문서에서는 마이그레이션의 근거를 설명하고 높은 수준의 단계를 간략하게 설명합니다. 이 아키텍처를 사용하면 한 번의 작업으로 마이그레이션을 수행하거나(빅뱅 마이그레이션이라고도 함) 점진적, 기능별 마이그레이션을 수행할 수 있습니다. 함께 제공되는 배포 문서는 예시 마이그레이션 과정을 안내합니다.
이 아키텍처 및 배포 가이드는 다음을 최소화하면서 점진적으로 마이그레이션 및 현대화려는 복잡한 인프라를 관리하는 IT 전문가들을 대상으로 합니다.
- 다운타임
- 리팩토링 작업
- 네트워크 운영의 복잡성
개념 설명은 모든 클라우드에 적용되므로 이 문서에서는 사용자가 클라우드 기술, 컨테이너 및 마이크로서비스에 대해 익숙하다고 가정합니다.
Google Cloud로 마이그레이션: 시작하기에 설명된 대로 클라우드로 마이그레이션하기 위한 몇 가지 패턴이 있습니다. 이 문서의 아키텍처는 리팩터링 패턴(이동 및 개선이라고도 함)을 사용하며, 이 패턴은 애플리케이션 전체에 적용되는 것이 아니라 애플리케이션의 각 기능에 적용됩니다.
실제 마이그레이션 과정에서는 일부 기능이 Google Cloud에 있고 일부 기능은 여전히 기존 환경에 있는 하이브리드 아키텍처가 애플리케이션에 적용됩니다. 마이그레이션이 완료되면 전체 애플리케이션이 Google Cloud에서 호스팅됩니다.
아키텍처
다음 다이어그램은 서비스 메시를 사용하여 원본 환경에서 실행되는 마이크로서비스 또는 Google Cloud로 트래픽을 라우팅하는 방법을 보여줍니다.
아키텍처에는 다음 구성요소가 포함됩니다.
원본 환경(이 경우 마이그레이션할 예시 워크로드를 호스팅하는 Compute Engine 인스턴스). 원본 환경은 온프레미스이거나 다른 클라우드 플랫폼에서 호스팅될 수도 있습니다.
서비스 메시(이 경우 Istio 게이트웨이)는 서로 다른 서비스를 함께 연결합니다. 서비스 메시는 서비스 검색, 보안 통신, 부하 분산, 트래픽 관리, 관찰 기능과 같은 고가치 네트워킹 기능을 제공합니다.
서비스 메시의 일반적인 구현에서는 각 서비스를 해당 기능을 제공하는 프록시와 결합합니다. 서비스 프록시는 종종 사이드카라고 합니다. 사이드카의 역할은 애플리케이션의 인식 없이 연결된 애플리케이션을 보강하고 개선하는 것입니다. 함께 제공되는 배포 가이드에서는 Envoy를 사이드카 프록시로 사용합니다.
마이크로서비스로 구성된 애플리케이션이 포함된 워크로드입니다. 마이크로서비스는 애플리케이션 기능을 수용하도록 제작된 독립형 구성요소입니다. 이 아키텍처에서 애플리케이션은 사용자가 구별할 수 없는 여러 마이크로서비스로 구성되어 있습니다. 예를 들어 서평을 처리하는 구성요소는 마이크로서비스입니다.
마이크로서비스 패턴에서 애플리케이션은 각각 특정 목표를 가진 여러 마이크로서비스의 집합체입니다. 예를 들어 책 등급을 처리하는 마이크로서비스와 서평을 처리하는 마이크로서비스가 있을 수 있습니다. 이러한 마이크로서비스는 느슨하게 결합되어야 하며 잘 정의된 API를 통해 상호작용해야 합니다. Polyglot 애플리케이션처럼 서로 다른 언어와 프레임워크로 작성될 수 있으며 수명 주기도 서로 다를 수 있습니다.
각 마이크로서비스의 경계를 추가로 정의하는 역할을 하는 컨테이너입니다. 이 아키텍처의 대상 환경은 Kubernetes에 따라 조정되므로 다음 도구를 사용하여 마이크로서비스를 컨테이너화하는 것이 좋습니다.
- Docker는 운영체제 수준에서 사용자 공간 수준 프로그램을 격리하는 도구입니다. 컨테이너라는 패키지를 실행합니다.
- Kubernetes는 컨테이너 작업 부하를 위한 최고의 통합 솔루션입니다. 서비스 검색, 부하 분산, 자가 복구 포드, 노드, 보안 비밀, 구성 관리와 같은 기능을 제공합니다.
- GKE는 Google Cloud의 일부인 관리형 Kubernetes 환경으로, 프로덕션에 즉시 사용할 수 있습니다.
마이크로서비스를 컨테이너화하는 방법에 대한 도움말은 컨테이너 빌드를 위한 권장사항 및 컨테이너 작업을 위한 권장사항을 참조하세요.
서비스 메시를 사용하여 마이그레이션을 수행하려면 다음 단계를 완료하세요.
- 기존 환경 평가: 정보를 수집하고 대상 환경에 대한 요구 사항과 테스트 및 유효성 검사를 위한 기준을 설정합니다.
- 대상 환경에서 기반 구축: 대상 환경을 프로비저닝하고 코드형 인프라 방법론을 적용하여 인프라를 감사, 반복, 자동 프로비저닝할 수 있도록 합니다.
- 서비스 배포 및 대상 환경으로 트래픽 라우팅 시작: 단일 작업을 완료하여 모든 마이크로서비스 인스턴스를 동시에 배포하거나 점진적 배포를 완료하여 한 번에 하나의 마이크로서비스를 배포합니다.
- 기존 환경으로 트래픽 라우팅 중지: 대상 환경에서 실행 중인 서비스로만 트래픽을 라우팅하도록 라우팅 규칙을 설정합니다.
- 기존 환경 사용 중지: 대상 환경 프로비저닝 단계에서 설정한 부하 분산기를 가리키도록 DNS 레코드를 업데이트합니다.
이 문서에서는 이 유형의 마이그레이션에 대한 몇 가지 설계 고려사항을 설명하고 함께 제공되는 배포 가이드에서는 마이그레이션을 완료하기 위한 자세한 단계를 제공합니다.
설계 고려사항
이 섹션에서는 안정성, 운영 효율성, 비용, 성능 최적화에 대한 특정 요구사항을 충족하는 아키텍처를 개발하는 데 도움이 되는 안내를 제공합니다.
신뢰성
다음 섹션에서는 마이그레이션 안정성에 대한 고려사항을 설명합니다.
점진적인 마이그레이션 전략 사용
이 아키텍처는 단일 작업 마이그레이션에 사용할 수 있지만 점진적인 마이그레이션 전략을 사용하는 것이 좋습니다. 하나 이상의 애플리케이션을 마이그레이션할 때 발생하는 문제와 위험 때문에 한 번의 작업으로 마이그레이션을 완료하는 데 어려움이 있습니다. 시간과 예산에 제약이 있을 때 단일 작업 마이그레이션에 중점을 두면 새로운 애플리케이션 기능에 대한 작업을 수행할 수 있는 충분한 역량을 부여할 수 없습니다.
반대로 점진적, 기능별 마이그레이션은 마이그레이션할 작업 부하의 크기가 작기 때문에 전반적인 복잡성이 낮아집니다. 즉, 단일 기능은 전체 애플리케이션에 비해 적은 공간을 차지합니다. 점진적 마이그레이션을 통해 단일 위험 부담을 갖는 대신 더 적은 규모의 마이그레이션 이벤트 전체에 걸쳐 위험을 분산시킬 수 있습니다. 점진적 마이그레이션을 통해 마이그레이션팀은 여러 가지 기능을 수용할 수 있는 여러 마이그레이션 전략을 계획, 설계, 개발할 수 있습니다.
먼저 마이그레이션할 기능을 선택하는 방법과 스테이트풀(Stateful) 기능을 마이그레이션하는 방법에 대한 안내는 'Google Cloud로 마이그레이션: 워크로드 평가 및 탐색'에서 먼저 마이그레이션할 앱 선택을 참조하세요.
규정 준수 테스트 모음 사용
마이그레이션을 용이하게 하려면 규정 준수 테스트 모음을 사용하는 것이 좋습니다. 테스트 모음은 지정된 요구사항을 충족하는지 확인하기 위해 환경에 대해 실행할 수 있는 일련의 테스트입니다. 환경이 유효하면 요구사항을 충족하는 것입니다. 예를 들어 테스트 요청에 대한 응답의 유효성을 검사하거나 애플리케이션의 종속 항목이 설치되어 있는지 확인할 수 있습니다.
수동 유효성 검사는 모니터링, 추적, 서비스 메시 시각화 도구로 시작할 수 있습니다. 그런 다음 테스트 도구 모음을 구현하고 다음과 같은 방법으로 점차 발전시킬 수 있습니다.
- 부하 테스트. 테스트 트래픽을 환경으로 자동 전송하고 결과를 평가하여 테스트 모음을 발전시킬 수 있습니다.
- 규정 준수 테스트 도구: 전용 도구를 사용하여 테스트 모음을 설계하고 개발할 수 있습니다.
그런 다음 기존 환경뿐만 아니라 마이그레이션하는 동안과 마이그레이션한 이후 대상 환경에 대한 규정 준수 테스트 모음을 기준으로 실행합니다.
테스트 모음은 마이그레이션하는 동안 유효성을 검사할 때 다음 측면에 중점을 두어야 합니다.
- 프로비저닝: 구성하기 전에 환경에서 필요한 리소스를 프로비저닝합니다.
- 구성: 환경에서 리소스를 프로비저닝한 후 애플리케이션 요구에 맞게 리소스를 구성합니다. 구성 테스트 모음을 사용하면 환경에서 애플리케이션을 호스팅할 준비를 완료하도록 할 수 있습니다.
- 비즈니스 로직: 환경 프로비저닝 및 구성의 유효성을 검사한 후 애플리케이션의 비즈니스 로직을 검증합니다. 예를 들어 요청에 대한 응답의 유효성을 검사할 수 있습니다.
Chef InSpec, RSpec, Serverspec은 자동화된 규정 준수 테스트 모음을 개발하는 도구입니다. 모든 플랫폼에서 작동하며 확장 가능하므로 기본 제공 컨트롤부터 시작하여 자체 컨트롤을 구현할 수 있습니다.
대상 환경을 프로비저닝할 때 규정 준수 테스트 모음을 사용하여 검증할 수 있습니다. 하드웨어 및 네트워크 토폴로지와 같은 기존 환경과 대상 환경 간의 최종 차이점을 고려하여 테스트 모음을 업데이트해야 할 수도 있습니다. 완전한 제어 권한이 있는 온프레미스 환경에서 일반적으로 전체 스택에 대한 전체 액세스 권한이 없는 공용 클라우드 환경으로 마이그레이션한다는 점에 유의해야 합니다.
기존 환경의 부하 분산 레이어에서 대상 환경으로 트래픽을 라우팅하기 전에 대상 환경에서 노출되는 마이크로서비스에 대해 비즈니스 로직 규정 준수 테스트 모음을 실행하는 것이 좋습니다. 테스트 모음을 사용하면 마이크로서비스가 예상대로 작동하는지 확인하는 데 도움이 됩니다. 예를 들어 서비스 메시에 의해 노출된 서비스에서 반환된 응답의 유효성을 검사할 수 있습니다. 변경사항을 롤백하고 기존 환경으로 되돌려야 할 경우에 대비하여 원래 경로를 백업 옵션으로 유지할 수 있습니다. 프로덕션 트래픽의 작은 부분을 대상 환경에서 실행 중인 마이크로서비스의 인스턴스로 라우팅하면 대상 환경에 대한 신뢰도를 높이고 시간이 지남에 따라 총 트래픽을 늘릴 수 있습니다.
교차 환경 요청 허용 안함
규정 준수 테스트 단계에서는 교차 환경 요청을 허용하지 않도록 라우팅 규칙을 조정하는 것이 좋습니다. 그러면 클라이언트 요청이 기존 환경 또는 대상 환경에 도달할 때 요청이 해당 환경에 남아 있게 됩니다. 교차 환경 요청을 허용하지 않는 것은 테스트가 대상 환경을 올바르게 검증하는 데 도움이 됩니다. 이러한 요청을 허용하지 않으면 사용자가 모르는 사이에 테스트가 대상 환경 대신 원본 환경에서 성공을 보고할 수 있습니다.
기존 환경 사용 중지
기존 환경을 사용 중지하기 전에 다음 사항을 모두 충족하는지 확인합니다.
- 기존 환경에서 실행 중인 마이크로서비스의 인스턴스로 트래픽이 라우팅되지 않습니다.
- 기존 환경의 인터페이스를 통한 트래픽이 발생하지 않습니다.
- 대상 환경이 완전히 검증되었습니다.
이러한 조건이 충족되면 대상 환경 프로비저닝 단계에서 설정한 부하 분산기를 가리키도록 DNS 레코드를 업데이트할 수 있습니다. 대상 환경이 검증되었는지 확실하지 않은 한 기존 환경을 사용 중지하지 마세요. 검증을 비즈니스 로직으로만 제한하지 말고 성능 및 확장성과 같은 기타 비기능적 요구 사항도 고려하세요.
운영 효율성
다음 섹션에서는 마이그레이션의 운영 효율성에 대한 고려사항을 설명합니다.
기존 환경 평가
마이그레이션 계획을 설계하거나 구현하기 전에 기존 환경을 평가하여 정보를 수집하고 대상 환경에 대한 요구 사항과 테스트 및 검증을 위한 기준을 설정해야 합니다. 먼저 마이그레이션할 모든 애플리케이션 기능의 카탈로그를 작성합니다. 각 기능에 대해 다음과 같은 질문에 답변할 수 있어야 합니다.
- 런타임 환경 및 성능 요구 사항은 무엇인가요?
- 다른 기능에 대한 종속 항목이 있나요?
- 이 기능은 업무상 중요한가요?
- 이 기능은 스테이트리스(Stateless) 또는 스테이트풀(Stateful)인가요?
- 어느 정도의 리팩토링이 기능을 마이그레이션할 수 있을 것으로 예상되나요?
- 이 기능으로 단순 마이그레이션 기간을 감당할 수 있나요?
자세한 내용은 Google Cloud로 마이그레이션: 워크로드 평가 및 탐색을 참조하세요.
스테이트리스(Stateless) 리소스와 스테이트풀(Stateful) 리소스 비교
이 아키텍처는 서비스 기능(비즈니스 로직의 구현 방법)을 네트워크 기능(서비스 기능으로 트래픽을 라우팅하는 방법 및 시기)에서 분리하므로 서비스 메시를 사용합니다. 함께 제공되는 배포에서는 Istio를 서비스 메시로 사용합니다.
기존 환경에서 대부분의 서비스 호출은 모놀리식 플랫폼에서 발생하기 때문에 네트워크와 관련이 없습니다. 마이크로서비스 아키텍처에서 서비스 간의 통신은 네트워크를 통해 수행되며 서비스는 이 다른 모델을 처리해야 합니다. 서비스 메시는 네트워크 통신을 처리하는 기능을 추상화하므로 각 애플리케이션에서 구현할 필요가 없습니다. 또한 서비스 메시는 보안 통신 채널, 부하 분산, 트래픽 관리, 구성이 필요하지 않은 관측 가능성 기능을 제공하기 때문에 네트워크 운영의 복잡성을 줄여줍니다.
서비스 메시를 배포하고 구성하여 트래픽을 기존 환경 또는 대상 환경으로 동적으로 라우팅할 수 있습니다. 트래픽 관리는 메시의 서비스에 투명하기 때문에 애플리케이션의 구성을 수정하여 마이그레이션을 지원할 필요가 없습니다.
이 방법은 스테이트리스(Stateless) 기능에 적합하지만 스테이트풀(Stateful)이거나, 지연 시간에 민감하거나, 다른 기능과 결합이 많은 기능을 마이그레이션하려면 추가 계획 및 리팩토링이 필요합니다.
- 스테이트풀(Stateful): 스테이트풀(Stateful) 기능을 마이그레이션할 때는 데이터도 마이그레이션해야 하는데, 이는 마이그레이션 중에 다운타임을 최소화하고 동기화 및 무결성 문제를 완화하기 위해서입니다. 'Google Cloud로 마이그레이션: 대규모 데이터 세트 전송'의 데이터 마이그레이션 접근 방식 평가 섹션에서 데이터 마이그레이션 전략에 대해 자세히 알아볼 수 있습니다.
- 지연 시간에 민감: 기능이 다른 기능과 통신할 때 지연 시간에 민감한 경우 마이그레이션 프로세스 중에 추가 구성 요소를 배포해야 할 수 있습니다. 데이터를 미리 가져오거나 레이어를 캐싱할 수 있는 프록시는 일반적으로 이 민감도를 완화하는 데 사용됩니다.
- 다른 기능과 결합이 많음: 둘 이상의 기능이 결합된 경우 동시에 기능을 마이그레이션해야 할 수 있습니다. 이 방법은 전체 애플리케이션을 마이그레이션하는 것보다 쉽지만 단일 기능을 마이그레이션하는 것보다 어려울 수 있습니다.
서비스 메시에 서비스 등록
기존 환경은 서비스 메시와 직접 통합되지 않으므로 마이그레이션을 구성할 때 기존 환경에서 실행 중인 모든 서비스를 서비스 메시에 수동으로 등록해야 합니다. 환경이 이미 Kubernetes에서 실행 중인 경우 기본 제공된 서비스 메시 API 통합을 사용하여 등록을 자동화할 수 있습니다.
기존 환경을 등록한 후에는 서비스 메시를 사용하여 기존 환경에서 실행 중인 마이크로서비스를 노출합니다. 그런 다음 기존 환경의 인터페이스에서 대상 환경의 인터페이스로 트래픽을 마이크로서비스로 점진적으로 라우팅할 수 있습니다.
클라이언트는 부하 분산 레이어를 통해 두 환경의 인터페이스에 액세스하기 때문에 서비스 중단을 경험하지 않습니다. 서비스 메시 내부의 트래픽 라우팅은 클라이언트에 투명하기 때문에 클라이언트는 라우팅 구성이 변경되었는지 알 수 없습니다.
비용 최적화
이 아키텍처에서는 비용이 청구될 수 있는 다음과 같은 Google Cloud 구성요소를 사용합니다.
아키텍처를 배포할 때 가격 계산기를 사용하여 예상 사용량을 기준으로 예상 비용을 산출할 수 있습니다.
성능 최적화
이 아키텍처에서 Compute Engine에서 실행 중인 서비스와 GKE에서 실행 중인 서비스 간에는 트래픽이 거의 균등하게 분할됩니다. 서비스 메시는 GKE 클러스터에서 실행되든 Compute Engine 인스턴스에서 실행되든, 선택한 서비스 인스턴스 간에 트래픽을 분산합니다. 모든 트래픽이 서비스 메시를 거치도록 하려면 Compute Engine에서 실행되는 워크로드가 서비스 메시의 서비스와 직접 연결하는 대신 가리키도록 다시 구성해야 합니다. DestinationRule 리소스를 사용하여 각 서비스 버전의 부하 분산 정책을 구성할 수 있습니다.
Deployment
이 아키텍처를 배포하려면 Istio 메시 확장을 통한 마이그레이션 배포를 참조하세요.
다음 단계
- GKE 자세히 알아보기
- Istio에 대해 읽어봅니다.
- 그 밖의 참조 아키텍처, 다이어그램, 튜토리얼, 권장사항을 알아보려면 클라우드 아키텍처 센터를 확인하세요.