- [C813] 마이크로서비스를 구성할 때, 데이터베이스를 꼭 분리해야 하나요? 데이터가 한 곳에 모여있지 않고 중복되어도 괜찮은가요? 모범 사례를 알아보고, 이유를 함께 적어주세요.
마이크로서비스에서 데이터가 갖는 의미는 굉장히 크다. 사실상 MSA의 성공 여부를 판단하는 기준이 데이터에 달려 있다고 해도 과언이 아니다. 대부분의 MSA 개발 방법들은 데이터 처리에 관련이 있으며, 데이터의 분할 방식에 따라 영향도가 커질 수도 작아 질수도 있다. 기존 모놀리식 어플리케이션이 마이크로서비스로 변화하는 과정에서 어플리케이션은 화면, 백엔드, 데이터로 세분화 된다. 대체로 MVC 구조에 익숙한 모놀리식 어플리케이션과 다르게 View 영역이 하나의 마이크로서비스로 분리되며, Persistent 영역은 마이크로서비스 별 독립된 데이터베이스로 구성된다. 때로는 화면에서 직접 조회가 가능한 데이터베이스도 존재한다.
모놀리식 어플리케이션에서 마이크로서비스 아키텍처로의 전환은 BIG BANG 방식으로 전환하는 TOP DOWN 방식을 여전히 선호하는 것이 국내 프로젝트의 실정이지만, 아키텍처 사상의 변화는 커버넌스 측면은 물론 어플리케이션의 구조적인 변화가 크게 발생하기 때문에 올바른 전환 방식이라 할 수 없다. 리스크를 최소화하며 마이크로서비스로 전환해 나가기위해서는 백엔드 → 데이터베이스(데이터) → 프론트엔드 순으로 점진적인 변화를 가져가는 것이 효과적이다.
먼저 백엔드 어플리케이션을 마이크로서비스로 전환하는 과정에 대해 간단히 살펴보자.
"아키텍트는 서비스 단위를 결정하기 위해 Bounded Context를 적용하여 서비스 범위를 정의하고, 그 기준에 따라 서비스가 결정되면, 서비스간 인터페이스 방식을 결정하며, 인터페이스를 위한 기술셋을 선택한다. 개발자는 API를 식별하고, 인터페이스에 필요한 기술요소들을 활용하여 개발한다."
이때 마이크로서비스 전환이 시작되는 시점부터 반드시 데이터베이스를 분리해야 하는가? 라는 질문이 있을 수 있다. 결론부터 말하자면 반드시 초기부터 데이터를 구분할 필요는 없다. 물론 장기적인 관점에서 바라보았을때, 점진적 이행이 가능한 형태로 데이터베이스를 분리해 나가는 것은 중요하지만, 초기 마이크로서비스 아키텍처를 적용하여 프로젝트를 시작하는 시점에서 데이터베이스를 분리하는 것은 위험도가 굉장히 높아 질뿐 아니라, 프로젝트 실패시 부담해야할 리스크 역시 커질 수 있다.
MSA 방법론, 모델링, 분석/설계, 개발, 테스트, 이행을 거치며, 마이크로서비스의 단위는 유동적으로 변화할 수 있다. 어플리케이션 영역(화면, 백엔드)에서는 변화에 따라 대응 개발하기 용이하지만, 데이터의 재배치, 테이블의 재설계는 어플리케이션 전체에 영향을 끼칠 수 있는 영역으로 재설계가 용이하지 않고 데이터의 변화에 따라 어플리케이션 구조 변화에 큰 영향을 주게된다. 따라서 Persistent의 경우 백엔드 서비스의 전환이 완료되거나, 안정화 된 이후에 설계하는 것이 좋고, 특히나 빅뱅방식의 전환은 지양해야 한다.....나도 아직 잘 이해가 안가서, 모범 사례는 아래의 링크로 갈음한다.
https://www.slideshare.net/awskorea/microservices-architecuture-on-aws
아래의 다른 참조보다 가장 잘 보고, 이해한 참조..
마이크로서비스 기반 클라우드 아키텍처 구성 모범사례를 잘 모아놨다.
https://www.slideshare.net/balladofgale/spring-camp-2018-11-spring-cloud-msa-1
https://www.bucketplace.co.kr/post/2021-11-19-오늘의집-msa-여정-part-1-시작/
https://docs.microsoft.com/ko-kr/azure/architecture/microservices/design/data-considerations
https://waspro.tistory.com/718
https://www.youtube.com/watch?v=KDMXLowyhAY
https://thenewstack.io/microservices-vs-monoliths-an-operational-comparison/
[C814] 여러 도메인을 가지고 있는 서비스에서, 하나의 서비스에서는 성공했지만 연관된 다른 서비스에서 실패하는 “부분 실패”의 경우 어떻게 처리해야 하나요? 음식 주문에서 결제에는 성공했지만, 주문에는 실패하는 경우를 예를 들어 설명하세요.
마이크로서비스의 설계 원칙은 서비스별로 데이터베이스를 갖도록 설계되었다. 각 저장소 서비스별로 분산해야하고 반드시 API를 통해 접근해야 한다. 하지만 불가피하게 데이터의 복제와 중복 허용이 필요하다.
분산된 데이터베이스에서 발생할 수 있는 분산 트랜잭션 이슈가 생길 수 있으나, 데이터의 일관성을 유지함으로써 (결과적 일관성만 유지한다) 해결 할 수 있다. 부분의 실패가 전체의 실패로 이어지지 않는 것이 중요하다.
- 결제한 것을 취소(롤백..?)하고 주문이 불가능하다는 안내를 클라이언트에게 전달한다.
- 주문이 가능해질때까지 클라이언트를 대기시킨다.
힘들다. 몸이 아파서 그런가 자꾸 부정적인 감정이 든다.
좀 .. 어렵다.
