이번 기사는 Microservice로 Application을 작성하는데 있어서 7번째이자, 마지막 글이다. 첫번째 글에서는 Microservice Architecture 패턴에 대해서 소개하고, Microservice를 사용하는 장단점에 대해서 논의했다. 다음 글에서는 API Gateway 사용, Inter-process communication, 서비스 검색, Event-Driven 데이터 관리, Microservice 배포 등의 다양한 측면에 대해서 논의했다. 이번 글에서는 monolithic application을 microservice로 마이그레이션(전환)하는 전략에 대해서 살펴 보려고 한다.
이 시리즈 기사들을 통해서 microservice architecture와 장단점, 언제 사용하는지에 대해 이해할 수 있도록 돕고자 한다. Microservice Architecture가 여러분의 조직에 적합할 수도 있다.
그러나, 크고 복잡한 monolithic application을 작성하는 정말 좋은 기회가 있다. Application 개발과 배포에 대한 일상적인 경험은 느리고 고통스럽다. Microservice는 머나먼 너바나(열반, 해탈)처럼 보인다. 다행스럽게도 Monolithic Hell에서 벗어나는데 사용할 수 있는 전략이 있다. 이 기사에서는, Monolithic Application을 Microservice로 점진적으로 리팩토링하는 방법에 대해서 설명할 것이다.
Overview of Refactoring to Microservices
(Microservice로 리팩토링하기 개요)
Monolithic Application을 Microservice로 변환하는 과정은 Application 현대화의 한 형태이다. 개발자들이 수십년동안 해왔던 일이기도 하다. 결과적으로, Application이 Microservice로 리팩토링할 때, 재사용할 수 있는 몇 가지 아이디어들이 있다.
사용하지 않는 전략 중 한가지는 "Big Bang" 재개발이다. Big Bang은 아무런 사전 준비 없이 새로운 Microservice 기반 Application을 개발하는데 모든 역량을 집중해야 한다. 호소력 있는 것처럼 들리지만, 극도로 위험하고 실패로 끝나기 쉽다. Martin Fowler가 리포트에서 말하는 것처럼, "Big Bang 재개발을 보장하는 유일한 방법은 Big Bang 뿐이다."
Big Bang 재개발 대신에, Monolithic Application을 점진적으로 리팩토링해야 한다. 점차적으로 Microservice를 구성하는 신규 Application을 개발하여 monolithic application과 함께 실행한다. 시간이 지나면, monolithic application으로 구현된 기능의 양은 완전히 사라지거나 또다른 microservice가 될 때까지 줄어든다. 이 전략은 고속도로에서 시속 70마일로 운전하는 도중에 자동차 정비하는 것과 유사한 도전이지만, Big Bang 재개발보다 훨씬 덜 위험하다.
Martin Fowler는 이러한 Application 현대화 전략을 Strangler Application(교착 상태 응용 프로그램)이라고 한다. 그 이름은 열대 우림에서 발견되는 strangler vine (a.k.a strangler fig - 알려진 것처럼, 다른 나무에 기생하여 그 나무를 감고 올라가 말려 죽이는 나무의 한 종류. 직역하면, 교살 포도 나무)에서 비롯되었다. 가끔은 나무가 죽어서 포도 나무 모양을 남긴다. Application 현대화도 같은 패턴을 따른다. Legacy Application 주위에 Microservice로 구성된 새로운 Application을 구축하고, 결국 Legacy Application은 사라질 것이다.
이제, 다른 전략을 살펴보자.
Strategy 1 – Stop Digging
(첫번째 전략 - 채굴 금지)
홀의 법칙(Law of Hole)은 구멍에 있을 때마다 채굴하는 것을 멈춰야 한다는 것을 알려주고 있다. 이것은 monolithic application을 관리할 수 없을 때, 따라야할 훌륭한 조언이다. 다른 말로 하면, monolithic application을 더 크게 만드는 것을 멈춰야만 한다. 이것은 신규 기능을 구현할 때, monolithic에 코드를 추가하지 않아야 한다는 것을 의미한다. 대신에 이 전략의 커다란 아이디어는 독립형 microservice에 새로운 코드를 넣는 것이다. 다음 다이어그램은 이러한 접근법을 적용한 시스템 아키텍처를 보여준다.
새로운 서비스와 legacy monolith 뿐만 아니라, 2가지 구성 요소들이 있다. 첫번째는 HTTP 요청을 처리하는 Request Router이다. 앞서 기사에서 설명한 API Gateway와 유사하다. Router는 새로운 기능에 대한 요청을 새로운 서비스로 보낸다. Legacy 요청은 monolith로 전송한다.
다른 구성 요소는 Glue Code이다. "Glue Code"는 Monolith에 통합되어 있다. 서비스는 격리되어 있지 않고, 종종 Monolith에서 보유하고 있는 데이터에 접근해야 한다. Monolith나 서비스 혹은 양쪽 모두에 있는 "Glue Code"가 데이터 통합을 담당한다. 서비스는 Monolith에 있는 데이터를 읽거나 쓰는데 Glue Code를 사용한다.
서비스가 monolith 데이터에 접근하는데 3가지 전략이 있다.
1. Monolith에서 제공하는 원격 API 호출2. Monolith의 데이터베이스에 직접 접근3. Monolith의 데이터베이스와 동기화된 자체 복사본 데이터 유지
Glue Code는 때때로 Anti-corruption Layer(반부패 계층)로 불리기도 한다. 왜냐하면 본래의 도메인 모델을 가진 서비스가 Legacy Monolith 도메인 모델이 갖는 개념에 의해 오염되는 것을 Glue Code가 방지하기 때문이다. Glue Code는 2가지 다른 모델들 사이에 변환된다. Anti-corruption Layer라는 용어는 읽어야만 하는 책, 이후 백서로 개량된 Eric Evans의 Domain Driven Design에서 처음 나타났다. Anti-corruption Layer를 개발하는 것은 사소한 일이 될 수도 있다. 그러나, monolithic hell에서 벗어나기 원한다면, 하나를 창조하는 것이 필수적이다.
가벼운 서비스로써 새로운 기능을 구현하는 것은 몇 가지 장점이 있다. Monolith가 더 관리할 수 없게 되는 것을 방지한다. 서비스를 monolith와 독립적으로 개발, 배포, 확장할 수 있다. 신규로 만드는 서비스마다 Micorservice Architecture의 장점을 경험할 수 있다.
그러나, 이러한 접근 방법이 monolith의 모든 문제점을 해결하는 것은 아니다. 이러한 문제들을 해결하려면 monolith를 분해할 필요가 있다. 그렇게 하기 위한 전략을 살펴 보자.
댓글을 달아 주세요
댓글 RSS 주소 : http://www.yongbi.net/rss/comment/782