MSA - 전환 계획 DB 분리 관련 참고 자료

MSA 전환시에 고민되는 DB, 스키마 문제에 대한 선구자들이 많이 있다. 

아래 글들을 꼭 읽어보고 정리해 보면 좋겠다.

마이크로서비스 아키텍처의 기준과 DB 분리

마이크로서비스 아키텍처의 기준과 DB 분리

인상적인 그림이 있다.

전환시에 꼭 참고하자.

MSA 전환 단계별 DB 이전

 

MSA 전환 계획 DB 분리 관련 참고 자료를 정리해 드릴게요.😊

MSA 전환을 위해서는 서비스 별로 DB를 반드시 쪼개야 하는 것은 아니지만, 장기적인 관점에서 바라보았을 때 점진적 이행이 가능한 형태로 데이터베이스를 분리해 나가는 것이 중요합니다. DB 분리는 인프라 아키텍처, 어플리케이션 아키텍처 측면에서 커다란 변화를 불러일으키며, 비용, 성능, 인력, 모델링 등 여러 측면을 고려해야 합니다²³.

MSA 서비스 분리 원칙은 다음과 같습니다²:

- 단계적으로 마이그레이션 해야 한다. 처음에 크게 분리하고 추후에 작게 분리 하라. 서비스 분리 공식은 없다.

- 작고 분리가 쉬운 서비스로 워밍업하라. 기존 Monolith에서 분리 가능한 작은 기능, 신규 개발 되는 작은 기능, 내부적인 의존성이 가장 적은 기능, 장애가 발생해도 전체 시스템에 영향이 적은 기능, 데이터의 크기, 테이블의 개수가 적은 기능 등을 선정하라.

- 핵심 기능의 분리에 대응할 준비를 하라. 핵심 기능은 다른 기능들과의 결합도가 높을 가능성이 크기 때문에 의존성 분석 과정이 필요하다. 정적 분석 도구를 활용하여 상세 의존성을 분석하고, 비즈니스 구조를 기반으로 분리하거나 도메인 주도 설계를 적용하여 Sub Domain 및 Bounded Context를 발견하라.

- 코드의 재사용 vs 재개발을 고민하라. 일반적으로 코드를 재사용하여 서비스를 구성하는 것이 효율적으로 보이지만, 오히려 비효율을 초래할 가능성이 높다. 오랜 기간 유지보수 된 코드는 기술 부채가 많이 쌓여 있고, 도메인 경계가 명확하지 않을 가능성이 높다. 따라서 요구사항을 다시 파악하여 해당 기능에 대한 비즈니스 도메인을 명확화하고, 새로운 기술 스택을 도입하여 재작성하는 것이 장점이 될 수 있다.

- 진화적인 서비스 분리를 하라. 서비스를 분리할 때 가장 큰 고민거리 중 하나가 서비스의 크기이다. 얼마나 작게 분리할 것인가에 대해 고민이 많은데, 사실 정답은 없다. 너무 작게 분리하면 각 서비스는 응집도 높은 비즈니스 로직 없이 CRUD만 수행하게 되고 서비스의 개수는 폭발적으로 늘어나게 될 것이다. 너무 많은 수의 서비스는 되려 운영에 대한 복잡도를 늘리게 되는 문제를 야기한다.”

- 반복/점진적 분리를 하라. 전체 Monolith를 MSA로 전환하는 것은 길고 비용이 많이 드는 여정이다. 리스크를 최소화하며 마이크로서비스로 전환해 나가기 위해서는 백엔드 → 데이터베이스 (데이터) → 프론트엔드 순으로 점진적인 변화를 가져가는 것이 효과적이다. 또한 서비스의 단위는 유동적으로 변화할 수 있으므로, 설계에 대한 고민을 반복적으로 하며 추가적으로 분리하는 진화적인 사고를 가지는 것이 좋다.

 

출처: Bing과의 대화, 2023. 5. 11.
(1) [MSA] MSA 서비스 분리 원칙 및 고려사항 - 벨로그. https://velog.io/@sorzzzzy/MSA-MSA-서비스-분리-원칙-및-고려사항.
(2) 마이크로서비스 아키텍처의 기준과 DB 분리 - 나라의 IT 잡아먹기. https://waspro.tistory.com/718.
(3) [MSA] MSA 서비스 분리 원칙 및 고려사항 - 벨로그. https://bing.com/search?q=MSA+%ec%a0%84%ed%99%98+%ea%b3%84%ed%9a%8d+DB+%eb%b6%84%eb%a6%ac. 
(4) [마이크로서비스 아키텍처 : 패턴과 핵심 기술] MSA 분리 전략 - MSA .... https://yummy0102.tistory.com/367.