155 câu hỏi đã được viết

0

안녕하세요 ! 질문 잘 해주셨어요 ~

질문해주신 내용에 답변 드려볼게요 !

"하나의 DB 를 띄우고 스키마로 분리하는 경우도 있나요 ??"

-> 네 ! 특히 초기 단계의 서비스나 리소스가 제한적인 환경에서는 DB를 하나만 띄우고 스키마만 분리해서 운영하기도 해요 ~

비용과 관리 복잡도를 줄일 수 있어서 현실적인 타협안이 되기도 해요 !

다만 강의에서 DB를 서비스별로 완전히 분리하는 방식으로 구성한 이유는, MSA의 핵심 개념인 "독립성"을 제대로 이해하고 경험해보는 것이 목적이기 때문이에요!

실무에서도 DB를 물리적으로 완전히 분리하는 게 MSA의 이상적인 형태인 건 맞아요 !

DB를 하나로 공유하게 되면 한쪽 서비스의 DB 장애나 성능 저하가 다른 서비스에도 영향을 미치게 되고, 서비스 간 독립 배포도 어려워질 수 있거든요 ~

결국 "DB를 몇 대 띄우느냐"보다는 서비스끼리 서로의 DB에 직접 접근하지 않고 API로만 통신하는 독립성을 지키는 것이 MSA의 핵심이라고 보시면 돼요 !

실제 운영 환경에서는 비용, 팀 규모, 서비스 성격에 따라 유연하게 결정하게 돼요 :)

추가로 궁금하신 점 있으시면 언제든 추가 질문 남겨주세요~~

0

안녕하세요, 인프런 AI 인턴입니다. SJ님.

Microservices Architecture(MSA)에서는 각 마이크로서비스가 자신만의 데이터베이스를 갖는 것이 원칙입니다. 각 서비스가 독립적으로 책임을 지고, 다른 서비스와의 결합도가 낮아야 하기 때문에, 데이터베이스도 독립적으로 운영하는 것이 이상적입니다.

각 서비스별 독립적인 데이터베이스 운영의 이유

1. 독립적인 확장: 서비스별로 독립적으로 확장할 수 있습니다. 특정 서비스의 트래픽이 급증해도 다른 서비스에 영향을 미치지 않습니다.

2. 장애 격리: 한 서비스의 데이터베이스에 장애가 발생하더라도 다른 서비스에는 영향을 미치지 않게 됩니다.

3. 보안 및 데이터 보호: 서비스마다 다른 보안 정책을 적용할 수 있어, 민감한 데이터는 별도로 보호할 수 있습니다.

그러나, 상황에 따라서는 하나의 데이터베이스 인스턴스를 여러 스키마로 분리하여 사용하는 경우도 있습니다. 주로 데이터베이스 라이선스 비용 문제나, 인프라 비용을 절감해야 하는 상황에서 고려됩니다.

스키마 분리 사용의 단점

1. 결합도 증가: 스키마를 분리해서 사용하면, 여러 서비스가 동일한 데이터베이스 인스턴스를 공유하기 때문에 결합도가 생길 수 있습니다.

2. 성능 문제: 한 계약을 사용하는 여러 서비스가 동시에 데이터베이스에 접속하게 되면, 성능 병목 현상이 발생할 수 있습니다.

3. 운영 복잡성: 여러 스키마의 변경이 필요한 경우, 관리 및 운영이 복잡해질 수 있습니다.

이와 관련한 더 구체적이고 실질적인 사례나 질문들은 다음의 유사한 게시물을 참고하시면 도움이 될 것입니다:

• Microservices와 독립 데이터베이스 관리
  
• MSA에서 효율적인 스키마 관리
  

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.