마이크로서비스 아키텍처 구축 : 대용량 시스템의 효율적인 분산 설계 기법_맛보기

이것은 새로운 코드의 배포보다는 시스템이 지원하는 국가를 더 빈번히 변경할 것을 염두에 둔
것처럼 보였다. 그러나 진짜 이유가 무엇이든, 이러한 데이터베이스에 저장된 공유 정적 데이터
의 사례는 매우 많이 볼 수 있다. 향후에 뮤직 쇼핑몰의 모든 서비스가 이런 동일한 테이블을 참
조하게 된다면 어떻게 해야 할까?
몇 가지 대안이 있다. 첫째는 이 테이블을 각 패키지에 복제하는 것이다. 장기적으로 보면 그 테
이블은 각 서비스 내부에서도 복제될 수 있다. 물론 이것은 잠재적으로 일관성 문제를 초래한다.
예를 들어 필자가 호주 동해안에 뉴먼토피아 9 를 세워 한 테이블에만 반영하고 다른 곳에 반영
하지 않는다면 어떻게 될까?
둘째는 공유 정적 데이터를 코드로 다루는 것이다. 이것은 아마도 서비스의 부분으로 배포되는
속성 파일에 저장되거나 열거형 개체 enumeration 가 될 수 있다. 동작 중인 데이터베이스 테이블을
변경하는 것보다 설정 파일을 변경하는 것이 훨씬 용이하겠지만, 데이터 일관성에 대한 문제는
여전히 존재한다. 하지만 이것은 대개 매우 합리적인 접근 방법이다.
셋째는 극단적일 수 있는데, 이 정적 데이터를 특정 독립적인 서비스 안에 삽입하는 것이다. 필
자가 접한 몇몇 상황에서 정적 데이터의 참조와 관련된 규모, 복잡도, 규칙들은 이 방법으로 보
장하기에 충분하지만, 단지 국가 코드만을 위해 사용하기에는 아마도 과분할 것이다!
대부분의 상황에서 단순한 방법이기 때문에 개인적으로 필자는 이러한 데이터를 설정 파일이나
코드에 직접 삽입하는 방식을 시도하고 싶다.
5.9 예: 공유 데이터
좀 더 복잡한 예를 살펴보자. 변경 가능한 공유 데이터는 여러분이 시스템을 분리하려 할 때 자
주 발생하는 문제가 될 수 있다. 우리의 재무 코드는 고객의 주문 결제를 추적하고, 반품할 때 환
불 또한 추적한다. 한편 창고 코드는 고객 주문이 발송되고 수취되는 것을 보여주기 위해 테이
블 레코드를 갱신한다. 이 모든 데이터는 웹사이트 상의 편리한 장소에 보여지고 고객은 그들의
계정으로 어떤 일이 진행되는지 볼 수 있다. 이를 단순화하기 위해 [그림 5-5]와 같이 이 모든
정보를 꽤 일반적인 고객 기록 테이블 내에 저장했다.
9 옮긴이_ 필자의 이름 샘 뉴먼(Sam Newman)을 딴 가상의 국가
134 마이크로서비스 아키텍처 구축