마이크로서비스 : 특징 두번째 이야기

분권 데이터 관리

모노리스의 시스템을 살펴보면 단일 통합 데이터베이스를 사용하고 있습니다. 이러한 단일 데이터베이스를 유지하는 방식은 벤더의 라이센서 모델과 데이터베이스의 기능 확장에 그 뿌리를 두고 있습니다. 마이크로서비스는 Polyglot Persistence 접근 방법을 선택하며, 서비스별로 데이터베이스를 갖도록 설계를 합니다. 즉, 이 말은 각각의 저장소가 분산되어 있어야 하며, 다른 서비스의 저장소를 직접 호출할 수가 없고 API를 통해서만 접근해야 함을 의미합니다. 그런데 이런 케이스에는 반드시 등장하는 문제가 있습니다.

 

마이크로서비스 : 특징 두번째 이야기

 

데이터 일관성 문제입니다. 주문 서비스와 배송 서비스가 있다고 생각을 해겠습니다. 상품이 1건 주문되면 배송도 1건 발생해야 합니다. 보통 이러한 처리는 동시적인 트랜잭션으로 처리가 됩니다. 그런데 2개의 서비스를 트랜잭션으로 묶으면 마이크로서비스의 장점인 독립적인 서비스 제공이 어렵게 됩니다. 따라서 마이크로서비스는 이러한 케이스에 데이터 일관성을 유지하기 위해 두 서비스 간의 트랜잭션이 아닌 협업을 강조합니다. 이 말은 Eventual Transaction이라도 하고 결과적 일관성이라고도 합니다.

두 서비스의 데이터가 일시적으로 불일치하는 시점에 있고 일관성이 없는 상태이지만, 결국에는 두 데이터가 같아진다는 개념입니다. 보통 이벤트와 Q를 써서 해결합니다. 상품이 주문되면 상품이 주문됐다는 이벤트를 Q에 보냅니다. 그리고 상품 서비스에 있는 자신의 수행 작업을 완료합니다. 배송 서비스는 Q에서 상품이 주문됐다는 이벤트를 읽고 배송 서비스를 수행합니다.

배송 서비스가 실패했다면 마찬가지로 Q에 실패된 배송 이벤트를 던지고 나머지 서비스들은 이를 읽어서 본인의 서비스를 처리하면 됩니다.

 

 

똑똑한 끝지점 단순한 파이프

여섯 번째 MSA 특징은 똑똑한 끝지점 단순한 파이프입니다. 기존의 SOA는 서비스 간의 연계 및 공유를 위해 UDDDI 및 ESB라는 서비스 채널을 사용했습니다. 특히 ESB를 강조해서 ESB가 기본적인 연계에 의해 비즈니스 처리 등을 한다고 많이 강조를 했습니다. 마이크로서비스는 smart endpoints and dumb pipes 방식을 선호합니다.

이는 Domain Logic은 서비스 속에서 응집성 높게 유지되어야 하고, 각각의 서비스의 연결은 느슨해야 한다는 것을 의미합니다. 따라서 REST와 같은 단순한 도구를 SOA에서 사용하는 UDDDI, SOAP, WSDR과 같은 도구보다 선호합니다. 또한 서비스 연결을 위해 Rabbit MQ나 Zero MQ 같은 가벼운 메시지 버스를 주로 사용합니다. 그리고 느슨한 연결을 위해 잦은 호출이 필요한 고운 입자 인터페이스 방식을 호출이 적은 거친 입자의 인터페이스 방식으로 변경하여 사용할 필요가 있습니다.

 

 

실패를 위한 설계

일곱 번째 MSA 특징은 실패를 위한 설계입니다. 마이크로서비스는 언제든 실패할 수 있으며, 실패해서 더 이상 진행할 수 없을 때도 자연스럽게 대응할 수 있도록 설계해야 합니다. 다양한 실패에 대비하여 자동으로 테스트할 수 있는 환경을 마련해야 하고, 이런 마이크로서비스의 실패를 감지하고 대응하기 위해서는 실시간 모니터링 체계를 갖추어야 합니다.

예로 서킷 브레이크 패턴을 말할 수 있겠는데요. 서킷 브레이크 패턴은 회로 차단기처럼 각각의 서비스를 모니터링하고 있다가 하나의 서비스가 다운되거나 실패되면 이를 호출하는 서비스의 연계를 차단하고 이에 적절한 대응을 하기 위해 만드는 것을 의미합니다. 이러한 설계는 서비스가 긴급 장애 상황에 빠르고 유연하게 대응할 수 있도록 합니다.