[DB] 마이크로서비스에서 공유형 DB를 사용한다는 것

공유형 DB는 초기에 빠르게 검토된다,

 

You are always integrating through a database - Musings on shared databases in a microservice architecture

마이크로서비스 아키텍처의 공유 데이터베이스에 대한 고찰 -당신은 항상 데이터베이스를 통해 통합하고 있다.-

 

블로그

inoio gmbh | You are always integrating through a database - Musings on shared databases in a microservice architecture

 

---

끄적끄적...

 

최근 차세대 서비스의 인프라를 준비하고 있는 동기에게 질문을 받았다.

 

"애플리케이션에서 DB 스키마가 변경되면 애플리케이션이 알아서 변경된 스키마를 인식할 수 있게 만들 수 있나요?"

 

차세대 인프라를 준비하고 있었다는 사실은 알고 있어서 대충 어떤 이슈인지는 감이 왔다.

 

관련 서비스들 공유형 DB를 사용하고 있다 보니, 특정 서비스에서 스키마를 변경하는 작업을 할 경우

 

다른 서비스까지 전체적으로 영향을 받고 있는 것이다.

 

실제 운영에서는 변경된 스키마를 반영한 후 배포하는 것을 꼼꼼하게 체크하기에 문제는 없는데,

 

이 작업 과정이 순탄치 않았던 모양이다. 

 

나는 DB를 공유하지 말고 부분적으로 분리될 수 있는 부분을 식별해서 서비스로 빼는 게 좋겠다고 조언 해줬다.

 

쉽지 않은 작업일테지만 이런 작업을 한 번, 두 번 성공하다 보면 속도가 붙을 것이니 장기적으로 본다면 괜찮은 솔루션이 될 거라고...

 

내 동기는 막내 위치(그것도 인프라...)에 있는 실무진이라서 그런 제안을 드라이빙할 힘이 없었다. 

 

그러다 위의 글을 알게 되었고 좋은 글인 것 같아 해당 동료에게 공유 했었는데, 개인적인 생각도 글로 남겨보려고 한다.

 

짧게 요약하면 공유형 DB는 양날의 칼이라는 점.

 

트레이드오프가 분명히 있고 실무적 관점에서 공유형 DB는 매력적인 설루션이라는 것.

 

운영중인 비즈니스 요구사항이 공유형 DB가 적합한 케이스인지를 먼저 체크해 보는 것.

 

공유형 DB가 문제를 일으킨다면 Bespoke API 혹은 이벤트 소싱 방식을 검토해 보는 것을 권장한다는 글이다.

 

저자는 이벤트 소싱 쪽을 긍정적으로 생각하고 있다.

 

---

 

공유형 DB의 단점들...

1. A centrally designed schema will by owned by everyone and suite no one.

중앙화된 스키마는 모두가 관리하게 되지만, 모두에게 적합한 DB가 아니다.

 

2. Separate schemas for each application will have an impedance mismatch between them. Domain-driven design has taught us that there is hardly ever agreement over the meaning of terms across different contexts.

공유형 DB에서 각 애플리케이션에 분리된 스키마를 통합하는 경우(의역), 불일치(용어적)가 발생할 수 있습니다. 도메인 주도 설계는 서로 다른 컨텍스트(Bounded Context)에서 용어의 의미에 대해 거의 일치된 의견이 나오지 않는다는 점을 우리에게 가르쳐 줍니다.

 

3. Applications that expose their own data schema to the outside world suddenly have to deal with schema evolution beyond their own control.

서비스의 데이터 스키마를 외부에 노출하는 애플리케이션은 자신의 통제를 벗어난 스키마 진화(생애주기) 문제를 다뤄야 합니다.

 

4. The same database technology has to be used by all for a dataset, even if there are radically different requirements for accessing it (some might need strong transactionality, others may need high read scalability)

공유형 DB를 사용하는 모든 개발자가 동일한 데이터 베이스 기술을 사용해야 합니다.

 

5. Noisy neighbors can affect the performance of other applications

공유 자원들이 애플리케이션 성능에 영향을 미칠 수 있습니다. [DB, 서버, 네트워크 등등...]

 

6. The central database server becomes a single point of failure for all applications

중앙화된 데이터베이스 서버가 애플리케이션 서비스의 치명적인 fail point가 될 수 있습니다.

 

 

나의 생각...

 

1번의 단점에 공감이 많이 된다.

 

현재 차세대를 진행 중인 팀과 협업 중에 있는데, 데이터베이스 변경건에 대해서 민감하게 반응을 보인다.

[요구사항 정리, 기획서.. 메일로 공식적인 요청..ㅠ]

 

데이터베이스 변경과 관련된 작업이 잡히면 관련 팀들이 모두 모여 이 사안을 다 인지하고 넘어가는 방식으로 작업이 진행되고 있는 것.

 

단순한 테이블 추가의 문제가 아닌 것인데, 1번의 표현대로 관련된 관계자가 해당 스키마를 가지고 있지만,

 

그 누구도 이 스키마에 피팅되는 팀이 없기 때문이다.

 

결국엔 서비스 개발 속도가 느려지거나 외부 서비스에서 데이터를 조달하는 방식으로 API를 연결하게 되는데,

 

이는 데이터 관리 측면에서 보면 옳지 않은 방향이다.

[데이터 관리 주체가 데이터를 주는 게 아닌, 외부 의존 서비스에서 데이터를 보유하고 API로 가져오는 방식이기 때문...]

 

나중에 분석이나 통계측면의 이슈에서 외부 서비스에 분석, 통계 API가 덕지덕지 붙게 되고

 

거버넌스 측면에서도 모호한 영역들이 발생하게 되는 것이다.

 

나의 경우 현재 DB에 스키마를 변경할 것인가 외부에 DB를 두는 방식으로 데이터를 조달할 것인가에 데드락이 걸려 있는 상황이다.

 

 

2번의 경우 용어와 관련된 충돌 이슈인 것 같다.

 

DDD에서는 특화된 도메인별로 컨텍스트를 두는 것을 제안한다.

 

거대한 비즈니스도 부분적으로 보면 작은 컴포넌트 형식의 비즈니스로 구분되고 이 구분되는 영역에서는 팀이나 부서가 다르기에 용어를 다르게 사용한다는 것이다. (DDD에서 용어는 매우 중요한 개념이다.)

 

공유형 DB 스키마에서는 많은 도메인 용어들이 사용될 것이다.

 

테이블명부터 칼럼명까지 여러 용어들이 사용되는데, 공유형 DB에 속한 팀들이 협의를 하고 용어를 통일하는게 아닌 이상 공유형 DB를 사용하는 모든 관계자는 같은 용어이지만 서로 다르게 이해하는 용어들을 피할 수 없게 된다.

 

소규모 인원으로 서비스를 개발하고 있는 우리 팀만 하더라도 LLM에서 나온 결과를 Completion으로 명명하느냐 Result로 명명하느냐에서 차이점이 발생한다. 

 

수백개의 테이블에서 각각의 용어들이 고유하게 사용될 수 있음을 어떻게 보장하고, 모든 관계자가 동일한 개념을 가지고 있다고 어떻게 확인할 수 있을까?

 

이 부분은 소통쪽에서 큰 비용을 야기하고 나중가서는 개발쪽에서 요구사항을 잘못 이해하거나 요구사항을 잘못 분석하는 결과를 야기할 수 있다. (협업 개발 부서끼리 다르게 이해한 용어로 대화를 진행하다가 어! "용어" ~~뜻으로 사용하는거 아니었어요?가 빈번하게 발생하는 것이다.)

 

4,5,6 번의 경우 인프라적인 이슈 혹은 기술적 이슈로 생각된다.

 

6번의 경우 SFP(단일 장애 지점) 이슈가 존재한다.

 

잘못된 SQL로 DB쪽 자원을 크게 잡아먹는 경우 애플리케이션의 DB IO 병목 현상을 야기하게 되고, 최종적으로는 서비스 가용성에 영향을 줄 수 있다. 이 이슈도 실무에서 자주 만나는 이슈이다.

 

공유형 DB 참을수 없는 유혹

 

시작은 공유형 DB로 시작한다. 마이크로서비스 아키텍처 전문가인 샘 뉴먼의 조언도 비슷하다.

 

처음부터 마이크로서비스로 시작하는 것보다 모놀리식으로 시작해 부분적으로 명확하게 도려낼 수 있는 부분들을 작게작게 쪼개는 것을 권한다.

 

공유형 DB는 참기 힘든 유혹이다.

 

프로젝트 초기에 빠르게 결과물을 확인해야 하는 상황에서 DB을 여러개 둬서 관리하는 작업은 쉽지 않고, 상급자에게 이런 상황을 설득하기도 쉽지 않다. 인프라쪽에서도 의문 부호 가득한 질문을 한다.

 

거기에 요구사항을 처음부터 명확하게 이해하기도 쉽지 않다.

 

요구사항이 곧 데이터의 구조(스키마)가 될텐데 이는 작업 도중에 시간에 따라 변경된다.

[요구사항이 변경되거나 개발진이 다르게 이해한 부분을 바로 잡거나...]

 

우리 팀도 현재 4개의 서비스에서 의존하고 있는 공통 서비스를 만들고 있는데 공유형 DB를 사용하고 있다.

 

단 외래키 의존성을 분리하고 스키마 다이어그램으로만 스키마의 정보를 관리하고 있다.

 

DB 소프트웨어에서 스키마를 그림으로 표시하면 테이블만 펼쳐질 뿐 누가 누구랑 연관되어 있는지 알 수 없다.

 

스키마 다이어그램을 통해 도려낼 수 있는 부분을 명확하게 두고 있다. 다만 서비스쪽 코드의 의존성이 분리되는 것은 또 다른 이야기이다.

 

실무적인 관점에서 어느 시점 이후로 분리될 부분을 도려내지 않는다면 점점 비대해져서 움직임이 둔해지는 상황이 오게 된다.

 

경쟁사의 속도와 다른 개발 속도를 가진다면 서비스의 운명도 위험해질 수 있는 것이다.

---

 

이후의 글은 공유형 DB의 대안이 될 수 있는 사례들을 살펴본다. (Bespoke API, Event Souring)

 

해당 내용은 정리하기엔 너무 많아서 시간이 되면 따로 읽어보기를 권한다.