마이크로 서비스(MSA)의 경계

마이크로 서비스를 사용하면 이점을 얻을 수 있지만, 경험에 비추어보면 몇 가지 문제가 있었다.

영향을 최소화 할 수 있도록 도출된 문제를 인식하는 것이 중요하기에 여기에 몇 가지 적는다.

문제 중 하나는 마이크로 서비스의 경계를 잡는 일이다. 이것은 가장 어려운 작업이다.

마이크로 서비스 범위 설정

각각의 마이크로 서비스가 단일 책임의 원칙을 수용하는 구조라면 이 글을 쓸일이 없었을 것이다.

커머스 플랫폼에서 결제를 담당하는 서비스를 생각해보자.

처음에는 두 가지의 지불 방법 (카드와 바우처)만 존재했고, 이 두가지 방법이 동일한 서비스에서 구현되었다고 가정한다. 여기에 계좌 이체, Paypal등 다른 결제 방식이 추가된다고 하면 어떻게 해야 하는가?

미래의 요구 사항을 미리 알면 설계 시 혹은 경계 설정시 보다 현명한 결정을 내리겠지만, 현실은 그렇지 않다. 따라서 현재의 정보를 바탕으로 결제를 담당하는 서비스를 단일로 하기로 결정 했다고 가정해보자.

시간이 지나서 Paypal 및 Apple Pay로 결제를 하기 위한 새로운 요구사항이 생겼다. 기존 서비스에서 이런 새로운 결제 방식을 구현 하면 서비스가 커지게 되고 의도치 않게 “많은 책임” 이 생기게 된다.

따라서 새로운 요구 사항은 결제 방식에 따라 다른 서비스로 결제할 수 있도록 책임을 분할하기로 결정을 하게 된다.

Paypal과 Apple Pay를 사용하는 결제는 별도의 서비스로 구현되지만 이미 결제를 구현한 기존 서비스는 어떻게 되는지 고민이 필요하다.

Paypal과 Apple Pay를 결제 방식에 따라 단일 책임을 정의했기에 기존 서비스는 위에서 결정된 접근 방식과 맞지 않게 된다.

결과적으로 기존 서비스를 새로운 서비스로 분할이 되어야 한다.

Monolithic 어플리케이션에서는 위의 예시가 비교적으로 간단한 코드 리팩토링에 해당되지만, 마이크로 서비스 아키텍처에서는 새로운 서비스를 옮겨져야 한다. (새로운 코드 저장소, 새로운 빌드 파이프라인, 환경 구성 등)

서비스의 범위가 변경되면 이름도 변경되어야 한다. 위의 예에서 원래 서비스의 이름이 “Payment”라고 가정하면, 결제 방식이 새롭게 정의되었기에 기존 이름은 더 이상 사용하기가 애매해진다.

“Paypal” 및 “Apple Pay”라는 서비스가 있는 공간에서 기존 이름인 “Payment”는 무엇을 의미하는지 고민을 하게 된다.

끊임없이 변화하는 환경에서 불가피하게 일부 서비스의 책임은 시간이 지남에 따라 재정의 될 필요가 있다. 마이크로 서비스의 크기에 대한 규칙으로 재정의 하긴 애매하다. 최적의 솔루션이 없다면 경험에 기반한 접근 방식이 최선의 방법일 수 있다.

서비스의 일부가 자주 변경되면 서비스를 두 가지로 나눌 수 있다는 신호
특정 테스트가 필요하거나 테스트 시간이 오래 걸리는 서비스는 다른 서비스를 방해하지 않도록 자체 서비스로 만드는 것이 좋다.
데이터 베이스 또는 Queue와 같은 외부 리소스에 접근하는 코드도 서비스에 캡슐화 해야 한다. 서비스를 시작한 다음 외부와 전혀 관련이 없는 일부 기능을 사용하기 위해 외부 리소스를 사용하여 로컬 환경을 구성하지 않아도 되기 때문이다.

하나의 사례를 보자.

Eurostar라는 회사는 25년 동안 런던과 다른 유럽간 열차 티겟을 판매해오는 회사이다. 약 3년전에 그들은 Monolithic을 마이크로 서비스 아키텍처로 변경하기 위해 “검색”, “체크아웃”과 같은 새로운 서비스를 개발했다.

새로운 마이크로 서비스가 개발된 직 후, Eurostar는 기차표를 판매하는 비즈니스외에 여행사가 되고, 호텔 숙박 및 패키지 상품을 판매하기로 전략적으로 결정을 하게 된다. “호텔 검색”, “호텔 체크아웃”등의 새로운 서비스가 만들어졌다.

기존 기차표를 판매하던 “검색”, “체크아웃”등의 서비스의 이름이 적절하다고 생각되지는 않는다.

결국 비즈니스가 변하는 시기에 서비스를 다시 검토하고 리팩토링을 해야 할 시점이 오게 된다는 것을 인지해야 한다.

즉, 비즈니스가 변경되는 상황에서는 처음 수립한 마이크로 서비스의 경계가 적절하지 않기에, 상황 발생시 기존 서비스에 대해서도 리팩토링을 염두해야 한다는 것이다.

따라서, 마이크로 서비스 경계 설정시 그 당시의 정보를 기준으로 설정하고 이후 비즈니스 상황이 변경되면 리팩토링에 대한 접근법을 지녀야 한다.