오늘은 데이터가 분산되어 있는 환경일 때 조회할 수 있는 방법에 대해 기록해보자.
찾아본 여러 방법 중 많이 이용하는 방법 3가지를 조사했었다.
설계 패턴 1. 데이터 공유 방식 (View)
설계 패턴 2. 공통 마이크로서비스 활용
설계 패턴 3. ReadOnly DB 활용

B와 C서비스에서 A DB로 직접 접근하는 형태의 조회 방식을 사용할 수 있다.
하지만 그렇게 구성할 경우 서비스간 결합도가 높아지는 문제가 발생할 수 있다.
이를 해소하기 위해서 위와 같이 View 스키마를 만들고 외부 서비스가 대신 해당 스키마를 바라보도록 설계하는 방식이다.
이를 통해 View가 유지되는 A DB의 자체 스키마를 변경할 수 있고, 불필요한 데이터를 숨기거나,
테이블 조인을 수행한 후 View로 제공할 수 있다.
하지만 이러한 방식도 물리적으로 동일한 DB 내에 Table과 View가 함께 공존한다는 차원에서 결합도가
완전히 분리되었다고 보기엔 어렵다.

하나의 공통 서비스를 만들고 Shared Data를 관리하는 방식이다.
상호 공유되어야 하는 데이터를 공통 서비스 내 공통 DB에 저장하는 방식이다.
공통 서비스는 Front 서비스에게 공통 데이터를 직접 접근할 수 있도록 엔드포인트를 제공하고,
마이크로서비스 간에는 공통데이터 또는 공유 데이터를 조회할 수 있는 API를 제공한다.
각각 A, B, C 서비스는 DB에 직접 접근하지 않고 API를 호출하여 결과를 전달받는 방식으로 구현한다.
독립성을 현저히 낮춰 줄 수 있는 API 호출 방식으로 가장 선호하는 방식이다.
마이크로서비스 아키텍처를 구성해 나가기 위한 구성 요소로 Rest API를 이야기 하는 이유도 바로 이와 무관하지 않다.
독립적인 DB에 대한 조회는 특히 실시간성 조회가 강조되는 경우 API를 통해 조회하도록 설계하는 것이 좋다.

B 서비스는 A 서비스에 데이터 변경을 위해 A API를 호출한다.
이 때 A DB에 변경된 데이터는 ReadOnly DB로 복제되고 A서비스를 조회할 경우 이 ReadOnly DB를 통해 접근할 수 있다.
복제를 구현할 수 있는 방안들은 공통적으로 타이밍 이슈가 발생할 수 있다는 점을 염두하고 설계해야한다.
ReadOnly DB를 적용하면, 데이터를 보호하고, 읽기 전용 NoSQL DB를 활용하여 성능상 이점을 가져갈 수 있다.
특히 분산 DB 데이터 관리 방안으로 CQRS나 API Composition을 위한 조회 용도의 DB로 활용하기 좋다.
물리적으로 독립된 환경에 Replication을 구성할 수 있어 보다 안정적인 서비스 제공이 가능하다.
특히 마이크로서비스 환경에서 CQRS DB 등을 적용하기 위한 패턴으로 적합하다.
다만, 데이터 정합성에 보다 노력을 기울여야 한다.
데이터 정합성에 있어서 해결이 잘된다면 ReadOnly DB 활용 패턴을 이용한 CQRS 방식을 사용하는 것이 제일 좋은 것 같았다.