이벤트 기반 마이크로서비스 구축

Microservice architecture는 이미 널리 쓰이고 있다. 개인적으로 기록하는 노트를 보니 microservice에 대해 처음으로 기록한 게 2017년 12월이었다. 새로운 기술을 유용하다고 판단하면 짧은 시간에 많은 회사들이 뛰어들어 채택하고 성과를 내거나 실패한다. 성공이 더 많으면 더 확산되고 또 하나의 defacto standard가 된다. 동기식microservice는 이미 그렇게 되었다. 하지만 이전의 많은 표준들이 그렇듯 장점과 함께 단점을 가지고 있고, 그 단점을 해결하기 위해 event-driven microservice가 나왔다.

Microservice는 말 그대로 service를 micro하게 나눴다. 하나의 service는 그 자체로 완결되어야 한다. 각 service끼리는 최소한의 필요한 정보를 주고받으면 되고, data는 각 service의 DB에 저장된다. 각 service의 성격에 따라 RDB나 nosql이나 필요한 최적의 storage를 선택하면 된다. 하지만 실제 product에서는 이렇게 이상적으로 loosely coupled service를 만드는 건 매우 힘든 일이다. 여러 종류의 DB를 쓰면 DBA가 관리하기 어려울 수도 있고 최적의 환경을 만들기 불가능할 수도 있다. 트랜잭션이 어렵거나 불가능할 수 있고, join을 할 수 없으니 각 data를 통합해서 보기 위해 application에서 처리를 해야 하거나 서로 다른 DB에 중복 저장해야 할 수도 있다.

이 책은 event-driven microservice의 기초부터 기존 서비스와의 통합, 지원 도구나 테스트 배포까지 전반적인 모든 부분을 설명한다. 다만 책에서도 설명하듯이, 또 언제나 그렇듯 event-driven microservice 역시 silver bullet은 아니다. 데이터 트랜잭션을 DBMS가 아니라 application에서 처리하기 때문에 분산 환경에서 트랜잭션을 처리할 수 있고, 각 service는 성격에 맞는 최적의 DB를 선택할 수 있지만, 그만큼 application에서 신경써야 하는 일이 늘어난다. 동기식 microservice는 일관된 commit이나 rollback을 할 수 없지만, event-driven microservice는 해당 event를 발행해서 실패한 service부터 requeue나 dead letter queue 기능을 사용해 retry를 할 수 있다. 하지만 그만큼 실시간성은 떨어질 수밖에 없고 그래서 eventual이라는 용어를 사용하게 된다. Message queue를 사용해 loosely coupled service를 구현할 수 있고 서비스 흐름을 단순화시킬 수 있으나 message 전달의 신뢰성 문제가 발생할 수 있다. 즉 언제나 그렇듯 비즈니스 요구사항과 개인/조직의 역량에 따라 architecture 설계가 필요하다. Oreilly의 책이 언제나 그렇듯 읽어서 바로 적용할 수 있는 설명보다는 좀 더 기본에 가까운 설명을 하기에 바로 이해하기 어려울 수 있지만 이 책을 여러 번 읽으면 event-driven microservice를 이해하는데 큰 도움이 될 거 같다.

• 한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다