DEVOCEAN

안녕하세요. 해리쓴입니다.

오늘 제가 풀어볼 주제는 마이크로서비스 아키텍처 같은 분산환경에서 성능을 확보하는 방법, 특히 각 서비스의 의존도를 높이지 않고 조회 성능을 확보하는 방법입니다.

우리에게 익숙한(?) 모놀리스 구조의 애플리케이션은 하나의 큰 애플리케이션과 통합DB로 구성되어 있습니다.

사용자가 무엇을 요구하더라도 DB내의 각 테이블을 Join해서 원하는 결과를 얻어낼 수 있습니다.

위 이미지에서 DB내에 있는 두 Table이 상품과 후기 정보를 저장하는 테이블이라고 가정해봅시다.

상품을 구매하기 위해 상품 후기를 참조해서 구매하려고 한다면, 상품 Table과 후기 Table을 Join 해서 후기가 좋은 상품을 검색할 수 있게 됩니다.

그런데 마이크로서비스 구조로 시스템이 구현되어 있다면, 어떻게 될까요? 애플리케이션과 DB가 분리되어 있어서 Join은 쓸수 없습니다.

이런 경우에는 사용자에게 상품 후기를 참조해서 상품을 고를 수 있게 하려면, 누군가 분리되어 있는 정보를 병합해야 합니다.

그럼 이 병합 기능은 어떤 서비스에서 하는게 맞을까요?

상품 서비스에 둔다고 하면, 상품을 조회할때마다 후기 서비스로 상품별 후기 정보를 요청해서 받아야 합니다.

예를 들어 상품을 조회할때 10개씩 보여 준다고 10번은 호출해야 한다는 것이죠.

이런 경우 서비스간 의존도는 높이지 않고, 두 서비스의 협력(?)으로 해결해야 할 요구사항은 아래와 같이 상품과 후기 정보를 결합한 별도 서비스와 DB를 구성하고,

새로운 상품의 추가나 삭제, 상품 가격 등 속성이 변경되는 경우, 상품의 후기가 등록되거나 수정되는 경우, 각각 메시지를 발행해서 상품 정보와 후기 정보를 결합해서,

사용자가 상품 후기를 참조해서 상품을 고를 수 있도록 데이터를 저장하는 방식으로 해결할 수 있습니다.

상품, 후기 서비스의 변경은 Query Service를 통해 상품과 후기 정보를 결합하는 기능을 수행하고, 결합된 데이터는 DB에 Matrialzed View 형태로 저장됩니다.

Materialized View 방식은 어떤 결과를 뽑아 내는 쿼리가 빈번히 사용 되는 경우 또는 시간이 많이 걸리는 Query의 수행속도 향상하기 위해서와 같이 비용이 많이 드는 Join이나,

Aggregate Operation 을 처리해야 하는 SQL을 위해, 데이터베이스의 한 Table(Materialized View)로 저장 하며, 그 테이블을 조회 하도록 하는 방식입니다.

이 방식을 마이크로서비스 아키텍처에서 Message Broker를 활용해서 구현하는 것입니다.

또 다른 방법으로 Serverless App이 상품과 후기 DB를 주기적으로 모니터링하다가 변경사항을 Materialized View가 있는 DB에 업데이트하는 방식으로도 구현할 수 있습니다.

정리하면,

분리된 서비스에서 관리하는 데이터의 결합이 필요한 경우, 두 서비스와 데이터의 의존성을 높이지 않고 원하는 기능을 구현하기 위해서는

아래 그림과 같이 CQRS 패턴과 Martialized View 패턴을 활용해서 아래와 같이 구현할 수 있습니다.

패턴이라는 용어를 썼더니 뭔가 어렵고 학술적인 느낌이 물씬 나는 것 같습니다.

패턴이란 소프트웨어 디자인 과정에서 자주 발생하는 문제들에 대한 전형적인 해결방식입니다.

패턴은 재사용, 재활용하는 코드 수준이 아니라 특정한 문제를 해결하는 방식을 알려주는 개념으로 옛날 책에서나 나오던 패턴을 활용해서 현재의 문제를 해결하는데 적용해 보았습니다.

그리고 본문의 다이어그램은 "excalidraw.com"에서 그렸습니다. 전문 설계 도구나 PPT보다 훨씬 사용하기 편합니다. 한번 써보세요.

읽어주셔서 감사합니다.