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

208

2

부

구현

필자는 많은 상황에서 이러한 변경 사항을 처리하는 방법이 논의된 적이 없고 결국 온갖 종류

의 문제로 이어진다는 사실을 확인했다. 스키마와 마찬가지로 하위 호환성이 없는 변경을 어느

정도 명시한다면 작업을 상당히 단순화할 수 있다.

변경 사항을 어떻게 처리할 것인지에 대한 합의를 도출하기 위해 많은 양의 문서와 대규모 회

의가 반드시 필요한 것은 아니다. 하지만 락스텝 릴리스의 길을 따르지 않는다고 가정하면, 마

이크로서비스 소유자 및 소비자 모두 다음 몇 가지 사안을 명확히 고려해야 한다.

●●

인터페이스를 변경해야 할 이슈는 어떻게 제기할 것인가?

●●

소비자와 마이크로서비스 팀이 변경될 사항에 동의하도록 어떻게 협업할 것인가?

●●

소비자를 업데이트하기 위해 누가 작업을 수행할 것인가?

●●

변경 사항에 동의한다면, 소비자가 인터페이스를 제거하기 전에 새로운 인터페이스로 전환하기까지 얼

마나 걸리는가?

효과적인 마이크로서비스 아키텍처의 비밀 중 하나는 소비자 우선 방식을 수용하는 것임을 기

억하라. 여러분의 마이크로서비스는 소비자가 호출하기 위해 존재한다. 소비자의 요구는 가장

중요하며 업스트림 소비자에게 문제를 일으킬 마이크로서비스를 변경하는 경우 반드시 고려해

야 한다.

물론 어떤 상황에서는 소비자를 변경하는 것이 불가능하다. 구 버전의 넷플릭스

API

를 사용하

는 구형 셋톱박스에 문제가 발생했던 넷플릭스 사례를 예로 들어보자. 이러한 구형 셋톱박스는

쉽게 업그레이드할 수 없으므로 지원을 중단할 수 있는 수준으로 ...