마이크로서비스 아키텍처 구축(전면 개정판)

207

5

장

마이크로서비스의 통신 구현

RPC

는 상황이 좀 더 까다로울 수 있다. 예를 들면 필자는

v1

.

createCustomer

,

v2

.

create

Customer

와 같이 메서드를 다른 네임스페이스에 배치해 프로토콜 버퍼로 이 방식을 처리했지

만, 네트워크를 통해 전송되는 동일한 타입에 대한 다른 버전을 지원하려고 할 때 이 방식은 매

우 힘들었다.

5.7.45.7.4

어떤 방식을 선호하는가? 어떤 방식을 선호하는가?

같은 팀이 마이크로서비스와 소비자 모두 관리하는 상황이라면 제한된 상황에서 락스텝 릴리

스를 사용하는 것은 다소 안심이 된다. 실제로 일회성 상황이라 가정하고 영향도가 단일 팀으

로 제한될 때 이 방식을 수행하는 것은 적절하다. 하지만 일회성 활동이 일상 업무가 될 위험이

있고 독립적으로 배포할 가능성이 있으므로 필자는 이 방식을 매우 신중하게 대한다. 락스텝

배포가 너무 잦으면 머지않아 분산형 모놀리스가 될 것이다.

앞서 논의했듯이 동일한 마이크로서비스에 대한 다른 버전을 공존시키는 것은 문제가 될 수 있

어 짧은 시간 동안 마이크로서비스 버전을 나란히 실행할 계획인 상황에서만 하는 게 좋다. 현

실적으로는 소비자에게 업그레이드할 시간을 줘야 할 때 몇 주 이상 걸릴 수도 있다. 블루-그

린 배포나 카나리아 릴리스처럼 마이크로서비스 버전이 공존할 수 있는 상황에서는 혼재된 기

간이 훨씬 짧아 이 방식의 단점이 보완된다.

필자는 가능하다면 구 엔드포인트를 에뮬레이션하는 것을 대체로 선호한다. 공존하는 마이크

로서비스 버전의 ...