Iceberg(빙산) Microservice

위 빙산 모습을 단순화하면 다음과 같다

그런데 혹시 다음과 같은 빙산을 본적이 있는가?

당연히 있을 수 없는 모습이다. 불안정해 보이고 부자연스러운 모습이다.

 

Microservice 별로 Data를 갖고 관련된 기능을 구현하면서 Client 에서 뭐가 필요할지 모르니 CRUD 형태로 최대한 많은 API를 노출한다고 생각하면, 아마도 이러한 부자연스러운 빙산의 모습이 될 것이다.

 

이러한 형태로 API가 노출된다면 DB Schema 또는 로직 등의 변경에 따라 API가 계속 흔들리게 되고 Client에 대한 영향력이 증가할 수 밖에 없다. API 정련이 필요하다. 제공하는 Provider 입장 뿐 아니라 Consumer와 상의하여 패턴화해야 한다.

 

이것은 단지 REST API 만의 문제가 아니다. Publish하는 Domain Event 도 마찬가지 일 것이다. 예를 들어 주문등록, 수정, 삭제, 조회를 기계적으로 Publish하기 보다는 주문의 Lifecycle을 이해하고 이를 사용하는 타 서비스와 협의하여 주문완료, 주문변경완료, 주문취소완료 등으로 Event를 정의하고 Publish 하는 것이 바람직할 것이다.

 

다시 자연스러운 모습으로 돌아와 보자.

수면 위로 노출된 API수를 가능한 최소화 해야하고, 변경을 최소화 할 수 있는 안정적인 API로 구성되어야 한다. API 규약은 Client와의 약속/계약이므로 Provider입장에서 일방적으로 변경할 수 없다.

 

수면 아래 Microservice 영역 내부에서는 API 변경을 최소화 하면서 구현체를 수정해야 한다. 그래야 Client에 대한 신뢰도가 높아질 것이다. 이렇게 된다면 Microservice 내부의 데이터(DB Schema)가 숨겨지고(Information Hiding), 로직이 드러나지 않게(Client가 알 필요 없게, Encapsulation) 될 것이다.

 

참고 : https://chrisrichardson.net/post/architecture/2022/03/16/isp-service-apis.html

Icebergs, the Interface Segregation Principle and microservices