작성
·
108
답변 2
0
안녕하세요, 이도원입니다.
MSA 도입에 있어서 DB에 대한 부분은 가장 큰 숙제라고 생각됩니다. 특히 Legacy 시스템을 MSA화 하는 프로젝트의 경우라면 더욱이 DB에 대한 분할 부분을 고민하지 않을 수 없습니다. 다만, MSA라고 해서 반드시 하나의 서비스당 분리 된 독립적인 DB를 사용해야 한다는 규칙을 지켜야하는 것은 아니라고 생각됩니다. 프로그래밍 언어나 데이터 스토리지를 독립적으로 실행할 수 있고, 데이터의 종속성을 배제하여 서비스를 개발하고 배포할 수 있는 장점이 있음과 동시에, 데이터 동기화에 대한 부분을 명확하게 해결하지 못한다면 DB의 분할보다는 단일 DB(Shared DB)를 통해, Read, Write DB 등으로 구분하여 구성하는 것이 더 효율적일 수도 있습니다. 강의에서는 분리 된 서비스에서 동일 데이터를 취급할 때, 문제가 될 수 있으니, 이 부분을 해결하기 위해 동기화 매커니즘을 기술적으로 도입하거나, 기능적으로 처리해 주어야 한다고 설명드렸습니다. 작업 서비스여서 데이터를 분리하고, 큰 서비스여서 데이터를 통합하여 사용한다는 개념보다는 데이터의 취급 형태가 조회성이 많은지 업데이트성이 많은지, 처리량은 어떤지, 동기화 방식이 실시간으로 처리되어야 하는지, 비동기화로 처리되지만 약간의 Delay를 허용하는지, 분산 트랜잭션에 대한 처리가 준비되어 있는지 등을 고려한 다음 데이터 분리 및 통합을 고려해야 한다고 생각됩니다.
추가 질문사항 있으시면 다시 글 남겨 주세요.
감사합니다.
0
안녕하세요, 인프런 AI 인턴입니다.
마이크로서비스 아키텍처(MSA)에서 각 서비스가 다른 데이터베이스(DB)를 사용하는 방식은 서비스의 독립성을 보장하기 위해 널리 사용됩니다. 각 서비스가 독자적인 DB를 사용함으로써, 서비스 간의 결합도를 낮출 수 있고, 각 서비스의 확장성과 유지 보수성이 향상됩니다.
현업에서는 MSA 환경에서 DB 동기화 문제를 해결하기 위해 여러 방안을 사용합니다. 가장 일반적인 접근 방식은 각각의 마이크로서비스가 자신만의 데이터베이스를 소유하는 것이며, 필요한 정보의 일관성과 동기화를 유지하기 위해 이벤트 기반 통신(예: Kafka)을 사용하는 이벤트 소싱과 CQRS(Command Query Responsibility Segregation) 패턴 등을 활용합니다. 또한, 데이터 일관성과 동기화를 위해 데이터베이스 레벨에서의 복제(replication) 기능이나, 애플리케이션 수준에서의 API 호출을 통한 데이터 동기화 방식을 사용하기도 합니다.
하지만 서비스의 규모가 작거나 특정 상황에서는 성능이나 관리의 편의성을 위해 한 개의 데이터베이스를 여러 서비스가 공유하는 방식을 선택할 수도 있습니다. 이 경우 서비스 간의 결합도가 증가할 수는 있지만, 동기화 처리가 용이해지는 장점이 있습니다. 결국, 각 프로젝트의 요구 사항과 팀의 상황에 따라 가장 적합한 방식을 선택하게 됩니다.
동기화 문제에 대한 구체적인 해결 방안이나 선택은 프로젝트의 요구 사항, 팀의 기술 스택, 그리고 프로젝트에서 중요하게 여기는 요소들(성능, 유지 보수성, 확장성 등)에 따라 달라질 수 있습니다.