• 지금부터 시스템의 개선과 그에 따른 API 인프라스트럭처를 구현하고 관리하는 방법에 대해 알아보자.
• 이전 장에서 소개했던 아키텍처 기반을 구현하고 API 게이트웨이, 서비스 메시, 개발자 포털 같은 API 인프라스트럭처를 이용해 클라우드 기반 환경으로 시스템을 이전하는 방법에 대해 알아봄
• 애플리케이션을 ‘그대로 이전하는’ 방법, ‘플랫폼을 교체하는’ 방법, ‘리팩토링 또는 리아키텍처링하는’ 방법의 차이점을 알아보고 특정 상황에서 어떤 방법이 가장 적합한지 판단할 수 있는 스킬을 개발함
• 기존의 API 게잍웨이와 참석자 서비스를 클라우드로 마이그레이션 한느 방법을 보여줌
• 서비스 메시의 다중 위치/클러스터 기능을 이용해 서비스를 클라우드로 이전하는 방법도 살펴봄

사례 연구: 참석자 서비스를 클라우드로 이전하기

컨퍼런스 사례 연구 시스템의 다음 진화는 참석자 서비스를 클라우드 벤더의 인프라스트럭처로 이전하는 것.

가장 큰 이유는 컨퍼런스 시스템 소유자가 데이터센터를 직접 운영하는 부담을 없애고 싶어 하기 때문

• 게다가 새로운 서비스, 모놀리식 애플리케이션, 미들웨어, 데이터 스토어까지 모두 클라우드로 올기게 될 것
• 참석자 서비스를 먼저 마이그레이션 하는 이유는 가장 새로운 컴포넌트이자 대부분의 트래픽을 감당할 서비스이기 때문.

위 그림은 주 컨퍼런스 시스템 애플리케이션과 별개로 동작하는 참석자 서비스를 보여줌.

클라우드 마이그레이션 전략의 선택

가트너가 2010년 발행한 시가 ‘클라우드로의 이전: 호스트 교체, 리팩토링, 재검토, 재구축 또는 교체’를 토대로 AWS는 2016년 클라우드 마이그레이션의 ‘6가지 R’을 설명하는 블로그 포스트를 발행함

6가지 R