Istio 메시 확장을 통한 마이그레이션 지원: 개념

이 문서는 서비스 메시를 사용하여 가상 머신의 애플리케이션을 실행하는 온프레미스 데이터 센터와 같은 기존 환경의 기능을 Google Kubernetes Engine(GKE)으로 마이그레이션하는 방법에 대해 설명하는 시리즈의 1부입니다.

시리즈는 이 개념 문서 및 함께 제공되는 가이드로 구성됩니다. 이 문서에서는 마이그레이션의 근거를 설명하고 높은 수준의 단계를 간략하게 설명합니다. 이 가이드에서는 마이그레이션의 예를 통해 안내합니다.

소개

이 문서는 다음 요소를 최소화하면서 점진적으로 마이그레이션하고 현대화하려는 복잡한 인프라를 담당하는 IT 전문가를 대상으로 합니다.

  • 다운타임
  • 리팩토링 작업
  • 네트워크 운영의 복잡성

개념 설명은 모든 클라우드에 적용되므로 이 문서에서는 사용자가 클라우드 기술, 컨테이너 및 마이크로서비스에 대해 익숙하다고 가정합니다.

하이브리드 및 멀티 클라우드 패턴과 권장사항 문서에 설명된 것처럼 클라우드로 마이그레이션하는 패턴에는 크게 리프트 앤 시프트, 개선 및 이동, 전면 교체와 같은 세 가지 패턴이 있습니다. 이 문서에서는 패턴이 애플리케이션 전체가 아닌 애플리케이션의 각 기능에 적용되는 개선 및 이동이라는 특정 패턴을 설명합니다.

실제 마이그레이션 과정에서는 일부 기능이 Google Cloud에 있고 일부 기능은 여전히 기존 환경에 있는 하이브리드 아키텍처가 애플리케이션에 적용됩니다. 마이그레이션이 완료되면 전체 애플리케이션이 Google Cloud에서 호스팅됩니다.

용어

애플리케이션
이 문서에서 애플리케이션은 여러 기능이 있는 완전한 소프트웨어 시스템을 말합니다. 사용자는 애플리케이션을 단일 단위로 인식합니다. 예를 들어 책을 판매하는 웹사이트는 애플리케이션입니다.
특징

기능이란 서점 애플리케이션의 서평 기능과 같은 애플리케이션의 기능 단위입니다. 기능은 마이크로서비스로 구성됩니다.

기능은 어떤 종류의 데이터에도 의존하지 않는 스테이트리스(Stateless) 또는 데이터에 대한 의존성이 있는 스테이트풀(Stateful) 중 하나일 수 있습니다.

마이크로서비스

마이크로서비스는 애플리케이션 기능을 수용하도록 제작된 독립형 구성요소입니다. 이 문서에서 애플리케이션은 사용자가 구별할 수 없는 여러 마이크로서비스로 구성되어 있습니다. 예를 들어 서평을 처리하는 구성요소는 마이크로서비스입니다.

마이크로서비스 패턴에서 애플리케이션은 각각 특정 목표를 가진 여러 마이크로서비스의 집합체입니다. 예를 들어 책 등급을 처리하는 마이크로서비스와 서평을 처리하는 마이크로서비스가 있을 수 있습니다. 이러한 마이크로서비스는 느슨하게 결합되어야 하며 잘 정의된 API를 통해 상호작용해야 합니다. Polyglot 애플리케이션처럼 서로 다른 언어와 프레임워크로 작성될 수 있으며 수명 주기도 서로 다를 수 있습니다.

각 마이크로서비스의 경계를 더 자세히 정의하려면 다음 도구를 사용하여 마이크로서비스를 컨테이너화하면 됩니다.

서비스 메시

서비스 메시는 여러 서비스를 서로 연결하고 서비스 검색, 보안 통신, 부하 분산, 트래픽 관리, 모니터링 및 관찰 기능과 같은 높은 가치의 네트워킹 기능을 제공하는 소프트웨어입니다.

서비스 메시의 일반적인 구현은 각 서비스를 이러한 기능을 제공하는 프록시와 결합하는 것입니다. 서비스 프록시는 종종 사이드카라고 합니다. 사이드카의 역할은 애플리케이션의 지식 없이 포함된 애플리케이션을 보강하고 개선하는 것입니다.

마이그레이션

마이그레이션은 기존 환경에서 실행되는 하나 이상의 애플리케이션 기능을 Google Cloud와 같은 대상 환경으로 이동하는 프로세스입니다. 이 문서에서 마이그레이션은 다음 중 하나일 수 있습니다.

  • 빅뱅 마이그레이션: 애플리케이션의 모든 기능을 한 번에 마이그레이션하는 경우
  • 점진적, 기능별 마이그레이션: 한 번에 하나의 기능을 마이그레이션하는 경우
규정 준수 테스트 모음

테스트 모음은 지정된 요구사항을 충족하는지 확인하기 위해 환경에 대해 실행할 수 있는 일련의 테스트입니다. 환경이 유효하면 요구사항을 충족하는 것입니다. 예를 들어 테스트 요청에 대한 응답의 유효성을 검사하거나 애플리케이션의 종속 항목이 설치되어 있는지 확인할 수 있습니다.

수동 유효성 검사는 모니터링, 추적, 서비스 메시 시각화 도구로 시작할 수 있습니다. 그런 다음 테스트 모음을 구현하고 점차 발전시킬 수 있습니다.

  • 부하 테스트. 테스트 트래픽을 환경으로 자동 전송하고 결과를 평가하여 테스트 모음을 발전시킬 수 있습니다.
  • 규정 준수 테스트 도구. 전용 도구를 사용하여 테스트 모음을 설계하고 개발할 수 있습니다.

점진적인 마이그레이션 전략을 선택해야 하는 이유

한 번의 작업으로 하나 이상의 애플리케이션을 마이그레이션할 때 발생하는 문제와 위험 때문에 빅뱅 마이그레이션은 어려움이 있습니다. 시간과 예산에 제약이 있을 때 빅뱅 마이그레이션에 중점을 두면 새로운 애플리케이션 기능에 대한 작업을 수행할 수 있는 충분한 역량을 부여할 수 없습니다.

반대로 점진적, 기능별 마이그레이션은 마이그레이션할 작업 부하의 크기가 작기 때문에 전반적인 복잡성이 낮아집니다. 즉, 단일 기능은 전체 애플리케이션에 비해 적은 공간을 차지합니다. 점진적 마이그레이션을 통해 단일 위험 부담을 갖는 대신 더 적은 규모의 마이그레이션 이벤트 전체에 걸쳐 위험을 분산시킬 수 있습니다. 점진적 마이그레이션을 통해 마이그레이션팀은 여러 가지 기능을 수용할 수 있는 여러 마이그레이션 전략을 계획, 설계, 개발할 수 있습니다.

먼저 Google Kubernetes Engine에서 모놀리식 애플리케이션을 마이크로서비스로 마이그레이션에서 마이그레이션할 기능을 선택하는 방법과 스테이트풀(Stateful) 기능을 마이그레이션하는 방법에 대한 지침을 찾을 수 있습니다.

서비스 메시를 사용하는 이유

서비스 메시는 네트워크 기능(서비스 기능으로 트래픽을 라우팅하는 방법 및 시기)과 서비스 기능(비즈니스 로직의 구현 방법)을 분리합니다.

기존 환경에서 대부분의 서비스 호출은 모놀리식 플랫폼에서 발생하기 때문에 네트워크와 관련이 없습니다. 마이크로서비스 아키텍처에서 서비스 간의 통신은 네트워크를 통해 수행되며 서비스는 이 다른 모델을 처리해야 합니다. 서비스 메시는 네트워크 통신을 처리하는 기능을 추상화하므로 각 애플리케이션에서 구현할 필요가 없습니다. 또한 서비스 메시는 보안 통신 채널, 부하 분산, 트래픽 관리, 모니터링 및 관찰 기능을 즉시 사용할 수 있기 때문에 네트워크 운영의 복잡성을 줄여줍니다.

이 가이드에서는 Istio를 서비스 메시로 사용합니다. Istio 기능은 다음과 같습니다.

  • 트래픽 관리: HTTP, gRPC, WebSocket, TCP 트래픽에 대한 여러 가지 라우팅 규칙을 통해 세밀한 트래픽 제어
  • 탄력적인 기능 요청: 재시도, 장애 조치, 회로 차단기, 결함 주입
  • 플러그인이 가능한 정책 레이어와 구성 API를 통한 액세스 제어 및 비율 제한 지원
  • 클러스터 인그레스와 이그레스를 포함해 클러스터 내부의 모든 트래픽에 대한 자동 측정항목, 로그, trace
  • 서비스 계정을 기반으로 한 인증 및 승인을 통해 서비스 간 통신 보호
  • A/B 테스팅, Canary 롤아웃, 결함 주입, 비율 제한 같은 테스트 및 배포 태스크 용이

서비스 메시를 시각화할 수도 있습니다. Kiali와 같은 도구는 Istio와 통합되어 서비스 메시의 일부인 서비스와 서로 연결된 방식을 보여줍니다.

다음 스크린샷은 Istio 메시를 나타내는 Kiali 서비스 그래프의 예시를 보여줍니다.

Istio 메시를 나타내는 Kiali 서비스 그래프

서비스 메시를 배포하고 구성하여 트래픽을 기존 환경 또는 대상 환경으로 동적으로 라우팅할 수 있습니다. 트래픽 관리는 메시의 서비스에 투명하기 때문에 애플리케이션의 구성을 수정하여 마이그레이션을 지원할 필요가 없습니다.

이 방법은 스테이트리스(Stateless) 기능에 적합하지만 스테이트풀(Stateful)이거나, 지연 시간에 민감하거나, 다른 기능과 결합이 많은 기능을 마이그레이션하려면 추가 계획 및 리팩토링이 필요합니다.

  • 스테이트풀(Stateful). 스테이트풀(Stateful) 기능을 마이그레이션할 때는 데이터도 마이그레이션해야 하므로 다운타임을 최소화하고 마이그레이션하는 동안 동기화 및 무결성 문제를 처리해야 합니다. Google Kubernetes Engine에서 모놀리식 애플리케이션을 마이크로서비스로 마이그레이션에서 데이터 마이그레이션 전략에 대해 자세히 알아볼 수 있습니다.
  • 지연 시간에 민감. 기능이 다른 기능과 통신할 때 지연 시간에 민감한 경우 마이그레이션 프로세스 중에 추가 구성 요소를 배포해야 할 수 있습니다. 데이터를 미리 가져오거나 레이어를 캐싱할 수 있는 프록시는 일반적으로 이 민감도를 완화하는 데 사용됩니다.
  • 다른 기능과 결합이 많음. 두 개 이상의 기능이 결합된 경우 동시에 기능을 마이그레이션해야 할 수 있습니다. 이 방법은 전체 애플리케이션을 마이그레이션하는 것보다 쉽지만 단일 기능을 마이그레이션하는 것보다 어려울 수 있습니다.

마이그레이션 계획

이 섹션에서는 서비스 메시를 사용하여 점진적, 기능별 마이그레이션을 수행하기 위한 계획을 보여줍니다. 이 계획은 다음 단계로 구성됩니다.

  1. 기존 환경을 평가합니다.
  2. 대상 환경에서 기반을 빌드합니다.
  3. 대상 환경에 서비스를 배포하고 트래픽을 대상 환경으로 라우팅합니다.
  4. 기존 환경의 트래픽 라우팅을 중지합니다.
  5. 기존 환경을 사용 중지합니다.

기존 환경 평가

마이그레이션 설계 또는 구현 작업을 수행하기 전에 기존 환경을 평가하여 정보를 수집하고 대상 환경에 대한 요구 사항과 테스트 및 유효성 검사를 위한 기준을 설정합니다. 먼저 마이그레이션할 모든 애플리케이션 기능의 카탈로그를 작성합니다. 각 기능에 대해 다음과 같은 질문에 답변할 수 있어야 합니다.

  • 런타임 환경 및 성능 요구 사항은 무엇인가요?
  • 다른 기능에 대한 종속 항목이 있나요?
  • 이 기능은 업무상 중요한가요?
  • 이 기능은 스테이트리스(Stateless) 또는 스테이트풀(Stateful)인가요?
  • 어느 정도의 리팩토링이 기능을 마이그레이션할 수 있을 것으로 예상되나요?
  • 이 기능으로 단순 마이그레이션 기간을 감당할 수 있나요?

평가 프로세스 및 마이그레이션할 기능에 대해 자세히 알아보세요. 그런 다음 기존 환경뿐만 아니라 마이그레이션하는 동안과 마이그레이션한 이후 대상 환경에 대한 규정 준수 테스트 모음을 기준으로 실행합니다.

테스트 모음은 마이그레이션하는 동안 유효성을 검사할 때 다음 측면에 중점을 두어야 합니다.

  • 프로비저닝. 구성하기 전에 환경에서 필요한 리소스를 프로비저닝합니다.
  • 구성. 환경에서 리소스를 프로비저닝한 후 애플리케이션 요구에 맞게 리소스를 구성합니다. 구성 테스트 모음을 사용하면 환경에서 애플리케이션을 호스팅할 준비를 완료하도록 할 수 있습니다.
  • 비즈니스 로직. 프로비저닝 및 환경 구성의 유효성을 검사한 후 애플리케이션의 비즈니스 로직 유효성을 검사합니다. 예를 들어 요청에 대한 응답의 유효성을 검사할 수 있습니다.

InSpec, RSpec, Serverspec은 자동화된 규정 준수 테스트 모음을 개발하는 도구입니다. 플랫폼에 상관없이 사용 가능하며 확장 가능하므로 기본 제공 컨트롤부터 시작하여 자체 컨트롤을 구현할 수 있습니다.

다음 다이어그램은 기존 환경의 예시를 보여줍니다.

기존 환경

대상 환경 프로비저닝

마이그레이션할 환경 및 애플리케이션에 대한 충분한 정보를 확보했으므로 평가 중에 설정한 요구사항에 따라 대상 환경을 프로비저닝할 수 있습니다.

이 단계에서 규정 준수 테스트 모음을 사용하여 대상 환경의 유효성을 검사할 수 있습니다. 하드웨어 및 네트워크 토폴로지와 같은 기존 환경과 대상 환경 간의 최종 차이점을 고려하여 테스트 모음을 업데이트해야 할 수도 있습니다. 완전한 제어 권한이 있는 온프레미스 환경에서 일반적으로 전체 스택에 대한 전체 액세스 권한이 없는 공용 클라우드 환경으로 마이그레이션한다는 점에 유의해야 합니다.

새로운 환경을 프로비저닝하고 있으므로, 감사 가능하고 반복 가능하며 자동으로 프로비저닝할 수 있는 인프라를 만들기 위해 코드형 인프라 방법론을 적용하는 것이 좋습니다.

다음 다이어그램은 기존 환경과 새로 프로비저닝된(현재 비어 있음) 대상 환경을 보여줍니다.

기존 환경 및 (비어 있는) 대상 환경

서비스 메시 구성

다음 단계는 기존 환경과 대상 환경을 포괄하는 서비스 메시를 설정하는 것입니다. 서비스 메시는 대상 환경으로 마이그레이션할 환경에서 실행 중인 다양한 마이크로서비스를 연결합니다. 이 단계에서는 서비스 메시가 비어 있으며 서비스가 등록될 때까지 대기 중입니다. 서비스 메시는 아직 프로덕션 트래픽을 수신하지 않습니다.

다음 다이어그램은 기존 환경과 대상 환경에서 비어 있는 서비스 메시를 보여줍니다.

기존 환경 및 비어 있는 서비스 메시

메시에 기존 환경의 서비스 추가

이 예에서 기존 환경은 서비스 메시와 직접 통합되지 않습니다. 이러한 통합을 위해서는 기존 환경에서 실행 중인 모든 서비스를 서비스 메시에 수동으로 등록해야 합니다. 이미 환경이 Kubernetes에서 실행 중인 경우 서비스 메시 API와의 기본 통합 덕분에 등록을 자동화할 수 있습니다.

이 단계에서 클라이언트는 여전히 기존 환경 인터페이스를 사용하여 마이그레이션 중인 마이크로서비스에 액세스합니다. 서비스 메시는 아직 프로덕션 트래픽을 수신하지 않습니다.

다음 다이어그램은 기존 환경에서 실행 중인 서비스가 서비스 메시에 추가되었음을 보여줍니다.

기존 환경에서 실행 중인 서비스가 서비스 메시에 추가됨

서비스 메시를 통해 서비스 노출

기존 환경이 등록된 상태에서 서비스 메시를 사용하여 기존 환경에서 실행 중인 마이크로서비스를 노출합니다. 이 단계는 마이그레이션 환경의 인터페이스에서 대상 환경의 인터페이스로 마이크로서비스 트래픽을 점진적으로 라우팅하는 경우입니다.

클라이언트는 부하 분산 레이어를 통해 두 환경의 인터페이스에 액세스하기 때문에 서비스 중단을 경험하지 않습니다. 또한 서비스 메시 내부의 트래픽 라우팅은 클라이언트의 별도 조치가 필요 없습니다. 클라이언트는 라우팅 구성 변경이 발생했는지 여부를 알 수 없습니다.

다음 다이어그램은 기존 환경에서 실행 중인 서비스가 서비스 메시를 통해 노출된 것을 보여줍니다.

기존 환경에서 실행 중인 서비스가 서비스 메시를 통해 노출됨

대상 환경에서 서비스 배포

이 단계에서는 대상 환경에 마이크로서비스를 배포합니다. 이 마이크로서비스를 이미 컨테이너화한 것으로 가정합니다. 따라서 이 프로세스가 완료되면 배포 환경을 선택하여 대상 환경에서 마이그레이션할 작업 부하를 초기화할 수 있습니다.

  • 대량 배포: 모든 마이크로서비스 인스턴스를 동시에 배포합니다.
  • 점진적 배포: 한 번에 하나의 마이크로서비스를 배포합니다.

대상 환경의 마이크로서비스 인스턴스는 아직 프로덕션 트래픽을 수신하지 않습니다.

스테이트풀(Stateful) 마이크로서비스를 마이그레이션할 때는 데이터도 마이그레이션해야 하므로 다운타임을 최소화하고 동기화 및 무결성 문제를 처리해야 합니다. 데이터 마이그레이션 전략에 대해 자세히 알아보세요.

대상 환경에서 실행 중인 마이크로서비스는 Kubernetes 및 Istio와의 고유 통합 덕분에 서비스 메시에 자동으로 등록됩니다. 이 단계에서 클라이언트는 계속해서 서비스 메시를 통해 노출된 기존 환경에서 실행 중인 마이크로서비스를 사용합니다. 대상 환경에서 실행 중인 마이크로서비스는 여전히 프로덕션 트래픽을 수신하지 않습니다.

다음 다이어그램에서는 프로덕션 트래픽을 수신하지 않는 확장된 서비스와 서비스 메시를 사용하여 노출된 기존 환경의 확장된 서비스를 보여줍니다.

프로덕션 트래픽을 수신하지 않는 확장된 서비스와 서비스 메시를 사용하여 노출된 기존 환경의 확장된 서비스

트래픽을 분할하는 라우팅 규칙 설정

이제 서비스 메시를 사용하여 기존 환경에서 실행 중인 서비스와 대상 환경에서 실행 중인 서비스 간에 프로덕션 트래픽을 분할하는 라우팅 규칙을 설정했습니다. 프로덕션 트래픽의 작은 부분을 대상 환경에서 실행 중인 마이크로서비스의 인스턴스로 라우팅하여 시작할 수 있습니다. 테스트 모음 및 강력한 모니터링을 통해 대상 환경에 대한 확신을 갖게 되면 시간 경과에 따라 전체 트래픽의 해당 부분을 늘릴 수 있습니다.

클라이언트 요청은 두 환경 모두에서 라우팅되기 때문에 관련 데이터 역시 마이그레이션되어야 하므로 스테이트풀(Stateful) 마이크로서비스에 대한 추가 계획 및 조정이 필요하며, 마이그레이션하는 동안 신뢰할 수 있는 여러 소스가 포함된 일시적인 단계가 있을 수 있습니다.

다음 다이어그램은 대상 환경에서 실행 중인 마이크로서비스와 기존 환경에서 실행 중인 마이크로서비스 간에 트래픽이 분리되는 방법을 보여줍니다.

대상 환경에서 실행 중인 마이크로서비스와 기존 환경에서 실행 중인 마이크로서비스 간에 분리되는 트래픽

또한 교차 환경 요청을 허용하지 않도록 라우팅 규칙을 구체화하는 것이 좋습니다. 따라서 클라이언트 요청이 기존 환경 또는 대상 환경에 도달할 때 해당 환경에 남아 있게 됩니다.

트래픽을 대상 환경으로 라우팅하기 위한 규칙 설정

이 단계에서는 라우팅 규칙을 업데이트하여 대상 환경에서 실행되는 서비스로 트래픽을 점진적으로 라우팅합니다.

다음 다이어그램은 기존 환경이 백업으로 유지되는 동안 트래픽이 대상 환경에만 라우팅되는 방법을 보여줍니다.

기존 환경이 백업으로 유지되는 동안 트래픽이 대상 환경에만 라우팅됨

기존 환경 사용 중지

이 단계에서는 기존 환경을 사용 중지합니다.

기존 환경을 사용 중지하기 전에 다음 사항을 확인합니다.

  • 기존 환경에서 실행 중인 마이크로서비스의 인스턴스로 트래픽이 라우팅되지 않습니다.
  • 기존 환경의 인터페이스를 통한 트래픽이 발생하지 않습니다.
  • 대상 환경이 완전히 검증되었습니다.

이러한 조건이 충족되면 대상 환경 프로비저닝 단계에서 설정한 부하 분산기를 가리키도록 DNS 레코드를 업데이트할 수 있습니다.

다음 다이어그램은 기존 환경이 사용 중지된 이후의 대상 환경만 보여줍니다.

대상 환경(기존 환경은 사용 중지됨)

다음 단계