미리보기 — AWS Migration Hub Refactor Spaces 기반 점진적 애플리케이션 리팩토링

기존 애플리케이션을 (일반적으로 마이크로서비스 기반의) 분산 애플리케이션으로 리팩터링할 수 있는 AWS Migration Hub의 새로운 기능인 AWS Migration Hub Refactor Spaces의 미리보기를 발표합니다.

기존 애플리케이션을 리팩터링하는 이유는 여러 가지가 있습니다. 예를 들면 코드를 더 모듈화하거나, 더 현대적인 프레임워크를 사용하거나, 다른 데이터 스토리지를 사용하기 위함입니다. 일반적으로 리팩터링의 목표는 시간이 지남에 따라 애플리케이션을 보다 쉽게 유지 관리하고 발전시키도록 하는 것입니다. 다른 이점으로는 대규모 워크로드 처리, 복원력 향상 또는 비용 절감 등이 있습니다. 하지만 리팩터링은 어렵습니다. 리팩터링을 비유하자면, 승객이 모두 승선한 비행기가 비행하는 상태에서 승객들이 아무것도 느끼지 못하는 중에 비행기의 엔진, 기내 좌석, 엔터테인먼트 시스템을 교체하는 것과 같습니다.

이러한 리팩터링 프로젝트를 성공적으로 수행한 고객과 이야기를 나누면서 우리는 교살자 무화과 설계 패턴이라는 공통된 패턴을 발견했습니다.

교살자 무화과는 숙주가 되는 나무 꼭대기에서 뿌리를 내리며 결국 숙주를 감싸거나 대체하는 식물 계열입니다. 저자인 Martin Fowler는 마이그레이션 설계 패턴을 설명하기 위해 해당 용어를 처음 고안했습니다. 그 의미는 ‘오래된 나무의 가장자리 주위에 점차적으로 새로운 시스템을 만들어 오래된 나무가 교살될 때까지 몇 년에 걸쳐 천천히 성장하게 하는 것’입니다.

교살자 패턴의 애플리케이션 적용
이 식물에서 영감을 받아 모놀리식 애플리케이션에서 기능을 추출하여 마이크로서비스로 다시 작성하고 싶을 수 있습니다. 그런 다음 트래픽을 이전 경로에서 새 경로로 점진적으로 라우팅합니다. 시간이 지남에 따라 모든 요청이 마이크로서비스로 라우팅되고 기존 애플리케이션은 폐기됩니다.

이러한 애플리케이션 변환 방식은 효과적이지만 장애물이 발생합니다. 기존 애플리케이션과 마이크로서비스를 분리하는 데 필요한 인프라를 만들어야 합니다. 이를 위해 AWS 클라우드에서는 여러 AWS 계정을 생성하여 팀 또는 서비스를 독립적으로 더 쉽게 운영해야 하는 경우가 많습니다. 여러 계정을 보유하는 것이 팀 간에 우려 사항과 결제를 분리하는 가장 효율적인 방법입니다. 여러 AWS 계정을 처리하는 경우 기존 애플리케이션과 새로운 서비스를 함께 연결하기 위해 네트워킹 인프라를 유지 관리해야 합니다. 또한 기존 애플리케이션에서 다른 계정의 새 서비스로 트래픽을 점진적으로 라우팅하는 라우팅 제어 시스템을 만들어야 합니다. 이러한 인프라를 대규모로 만들고 관리하는 것은 복잡합니다. 리팩터링 프로젝트에 추가적인 위험과 비용이 발생합니다.

Refactor Spaces 활용
AWS Migration Hub Refactor Spaces는 내가 하기 어려운 작업을 처리합니다. 첫째, 여러 AWS 계정 간의 연결을 활성화하기 위해 네트워킹 인프라를 마련합니다. 둘째, 내 레거시 애플리케이션에서 원격으로 수행된 API 호출을 라우팅하는 메커니즘을 만들고 관리합니다.

리팩터링하고 싶은 모놀리식 애플리케이션이 있다고 가정해 봅시다. 해당 애플리케이션은 ReactJS를 사용하는 웹 기반 프런트엔드로 구성됩니다. 프런트엔드 애플리케이션은 Amazon Simple Storage Service(Amazon S3)에서 호스팅되고 Amazon CloudFront를 통해 배포됩니다. 프런트엔드는 NodeJS 또는 Python으로 개발되고 여러 EC2 인스턴스에 배포된 모놀리식 애플리케이션에 대한 API 호출을 수행합니다. API는 당사가 창립 후 데이터 저장에 계속 사용해 왔던 관계형 데이터베이스를 사용합니다.

이 애플리케이션의 아키텍처는 다음 다이어그램으로 설명할 수 있습니다.

각 API에는 고유한 URI가 있습니다. 예를 들어 /cart API는 장바구니를 처리하고 /order API는 주문 시스템을 처리합니다. 교살자 무화과 패턴을 적용하고 새로운 마이크로서비스 집합에 /cart 기능을 추출하기로 했습니다. 이러한 마이크로서비스에 대한 AWS 계정을 생성합니다. 장바구니 관리 기능을 구현하기 위해 AWS Lambda 함수 집합을 개발하고 배포합니다. 대체적인 지연 시간이 짧기 때문에 Amazon DynamoDB를 장바구니 데이터 스토리지로 사용하기로 했습니다.

새 아키텍처의 스키마는 다음 다이어그램에 나와 있습니다.

하지만 지금은 두 가지 문제가 있습니다. 먼저 프런트엔드 애플리케이션에서 수행한 API 호출을 올바른 백엔드(모놀리스 또는 새로운 마이크로서비스)로 라우팅하는 라우팅 메커니즘을 설계, 코딩, 배포해야 합니다. 이 서비스는 별개의 AWS 계정에 배포될 가능성이 높습니다. 그런 다음 이러한 여러 AWS 계정 간에 네트워크 연결을 구성해야 합니다.

여기서 Refactor Spaces가 등장하기 시작합니다.

AWS Migration Hub Refactor Spaces 소개
Refactor Spaces를 사용하면 앞서 설명한 두 가지 문제인 API 호출 라우팅과 AWS 계정 간의 네트워크 연결을 처리하여 애플리케이션 리팩터링을 쉽게 관리할 수 있습니다. 이는 환경, 서비스, 애플리케이션 프록시로 구성됩니다. 이것이 작동하는 모습을 살펴보겠습니다.

AWS 관리 콘솔을 열고 AWS Migration Hub로 이동한 다음 Refactor Spaces를 선택합니다.

먼저 Refactor Spaces 환경(Environment)을 만듭니다. 환경은 피어링된 VPC로 구성된 다중 계정 네트워크 패브릭입니다. 이를 기반으로 환경에 추가된 서비스 VPC의 AWS 리소스가 AWS 계정 간에 직접 통신할 수 있습니다. 또한 계정 전체의 네트워킹 및 서비스에 대한 통합 보기를 제공합니다.

환경 생성(Create environment)에서 내 환경에 이름(Name)과 설명(Description)을 입력한 후 다음(Next)를 선택합니다.

그런 다음 애플리케이션을 정의합니다. 애플리케이션에 이름을 지정하고, 프록시를 배포할 VPC를 선택합니다.

애플리케이션은 서비스 컨테이너입니다. 여기에는 경로를 정의하는 프록시가 있습니다. 프록시를 사용하면 프런트엔드 애플리케이션이 단일 엔드포인트를 사용하여 여러 서비스에 연결할 수 있습니다. 모든 트래픽이 단일 프록시 엔드포인트에 도달한 다음, 규칙에 따라 여러 서비스로 전송됩니다.

앞에서 설명한 대로 여러 AWS 계정을 사용할 수 있습니다. 일반적으로 애플리케이션은 Refactor Spaces 애플리케이션 프록시를 호스팅하는 하나의 AWS 계정, 레거시 애플리케이션을 호스팅할 하나 이상의 AWS 계정, 첫 번째 마이크로서비스에 대한 하나의 AWS 계정으로 구성됩니다. 따라서 다른 AWS 계정 소유자가 이 Refactor Spaces 환경에 참여하도록 초대합니다. AWS 계정당 보안 주체 하나를 추가합니다. Refactor Spaces는 반복 작업에 시간을 허비하지 않고 를 활용하여 이를 수행합니다.

이 단계는 선택 사항입니다. Refactor Spaces는 하나의 AWS 계정 내에서 작동할 수 있습니다. 이후 단계에서 이 환경을 다른 AWS 계정과 공유할 수 있습니다.

AWS 계정 ID를 보안 주체(Principals)로 입력한 후 다음(Next)을 선택합니다.

마지막으로, 선택 사항을 검토하고 환경 생성 및 공유(Create & share environment)를 선택합니다(여기에 표시되지 않음).

마이크로서비스를 사용할 준비가 되었다고 가정하면, 다음 단계는 Refactor Spaces Services로 등록하는 것입니다. Refactor Spaces Services는 비즈니스 기능(일반적으로 마이크로서비스)을 제공하는 엔터티입니다. 이러한 서비스는 고유한 엔드포인트를 통해 연결할 수 있으며 Refactor Spaces Environment에서 계정 간에 상호 운용할 수 있습니다. 이번 예제에는 다음과 같은 네 가지 서비스가 있습니다.

• 모놀리식 앱. Refactor Spaces가 프런트엔드에서 시작된 모든 API 호출을 라우팅하는 기본 서비스입니다.
• /cart 기능을 구현하는 세 가지 마이크로서비스. 이 기능을 AdditItem, RemoveItem, ListItem이라는 세 가지 서비스로 리팩터링하기로 결정했습니다.

Refactor Space Services는 EC2, AWS Fargate에 배포된 컨테이너, Application Load Balancer, AWS Lambda 함수 등 모든 컴퓨팅 리소스 유형을 대상으로 할 수 있습니다.

왼쪽 메뉴에서 서비스 생성(Create service)을 선택합니다. 서비스 구성은 세 단계로 이루어집니다. 먼저 이 서비스를 정의할 Refactor Spaces 환경(Environment) 및 애플리케이션(Application)을 선택합니다. 둘째, 서비스에 이름 및 설명을 입력합니다. 셋째, 서비스 엔드포인트(VPC의 HTTP/HTTPS URL 또는 Lambda 함수)를 선택합니다.

모놀리식 애플리케이션은 달리 지정되지 않는 한 Refactor Spaces Application 프록시가 모든 API 호출을 라우팅하는 기본 경로입니다. /를 소스 경로(Source path)로 입력하고 하위 경로 포함(Include child path)을 선택합니다. 그런 다음 HTTP 동사에 모두 일치(Match all)가 선택되어 있는지 확인합니다.

완료되면 서비스 생성(Create service)을 선택합니다. 각 마이크로서비스에 대해 이 프로세스를 반복합니다. 이 데모에서는 총 4개의 Refactor Spaces 서비스를 만듭니다.

마지막 단계에서는 Refactor Spaces Application 프록시에 대한 라우팅 규칙을 정의합니다. 구성되면 이 프록시가 프런트엔드 애플리케이션의 새 API 엔드포인트가 됩니다. 내 프런트엔드 애플리케이션에서 변경해야 할 유일한 사항은 Refactor Spaces Application 프록시 URI를 가리키는 것입니다. 이 프록시는 경로 정의에 따라 API 호출을 서비스로 라우팅합니다. Application 프록시는 프라이빗 또는 퍼블릭 가시성을 통해 모든 컴퓨팅 플랫폼으로의 라우팅을 지원합니다. 현재, 프라이빗 엔드포인트는 퍼블릭 DNS 이름 또는 프라이빗 IP 주소를 통해 참조되어야 합니다. 각 API 호출은 이 프록시에 구성된 경로 집합에 대해 실행됩니다. 경로가 규칙과 일치하면 해당 경로에 대해 구성된 대상 서비스로 요청이 전송됩니다. 프록시에는 경로 규칙과 일치하지 않는 경우 요청을 기본 서비스로 전달하는 기본 경로가 있습니다.

방금 만든 서비스를 선택합니다. 그런 다음 지원할 소스 경로(Source path) 및 HTTP 동사(Verb)를 입력합니다. 내 서비스에 하위 경로(예: /cart/123)가 필요할 경우 하위 경로 포함(Include child paths)도 선택해야 합니다.

GetItem 및 RemoveItem 마이크로서비스에 대해 이 프로세스를 반복합니다. 서로 다른 HTTP 동사(각각 GET 및 DELETE)에 대해 이 서비스가 호출됩니다.

이 구성을 기반으로 Refactor Spaces는 다음과 같은 아키텍처를 만들고 관리합니다. Refactor Spaces Application 프록시 및 네트워크 패브릭은 별도의 AWS 계정에 배포됩니다. 내 모놀리식 애플리케이션 또는 마이크로서비스의 요구 사항에 따라 Amazon API Gateway를 추가로 구성할 수도 있습니다.

궁극적인 변화는 애플리케이션 프런트엔드를 위한 것입니다. 모놀리스의 엔드포인트 대신 Refactor Spaces Application 프록시 엔드포인트를 가리키도록 해당 구성을 수정합니다. 이제부터 Refactor Spaces는 기본적으로 API 호출을 모놀리스로 라우팅합니다. GET, POST, DELETE 동사에 대한 /cart 호출을 Lambda 함수로 구현된 새 마이크로서비스로 라우팅합니다.

시간이 지남에 따라 이전 모놀리스가 새로운 마이크로서비스 아키텍처에 의해 교살될 때까지 이 프로세스를 반복하여 다른 기능을 모놀리식 애플리케이션으로부터 하나씩 옮길 것입니다.

요금 및 가용성
AWS Migration Hub Refactor Spaces는 현재 미국 동부(버지니아 북부), 미국 서부(오레곤), 미국 동부(오하이오), 아시아 태평양(싱가포르), 아시아 태평양(시드니), 아시아 태평양(도쿄), 유럽(아일랜드), 유럽(프랑크푸르트), 유럽(런던), 유럽 (스톡홀름)의 10개 AWS 리전에서 사용할 수 있습니다. 언제나처럼 향후에 추가 지역으로 확장할 수 있기를 기대합니다.

이 새로운 기능은 현재 공개 평가판으로 사용할 수 있으며 등록할 필요가 없습니다. 지금 바로 사용할 수 있습니다. 평가판 기간에는 Refactor Spaces 사용 시 요금이 부과되지 않습니다. 하지만 AWS 계정에 프로비저닝하는 리소스(Amazon API Gateway, AWS Transit Gateway, 네트워크 로드 밸런서)에 대해서는 요금이 부과될 수 있습니다. 요금 세부 정보는 AWS Migration Hub의 요금 페이지에서 확인할 수 있습니다. 결제는 Refactor Spaces가 정식 출시될 때 시작됩니다.

지금 바로 애플리케이션 리팩터링을 시작하세요!

— seb