이는 시스템의 규모와 실제 문제의 크기에 따라 사용자의 상황에 따라 달라지기 때문에 명확한 해결책은 없습니다. 데이터베이스가 실제로 병목 현상입니까?
이 (안타깝게도 다소 긴) 답변은“마이크로 서비스는 나쁘고 인생에는 모 놀리 식입니다!”와 같은 내용을 읽게되지만 이것이 저의 의도는 아닙니다. 내 요점은 마이크로 서비스와 분산 데이터베이스가 다양한 문제를 해결할 수는 있지만 자체 문제가 없어야한다는 것입니다. 아키텍처를 강력하게 주장하려면 이러한 문제가 적용되지 않고 완화 될 수 있으며이 아키텍처가 비즈니스 요구에 가장 적합한 선택임을 보여 주어야합니다.
분산 데이터는 어렵다.
더 나은 스케일링을 가능하게하는 동일한 유연성은 더 약한 보증의 단점입니다. 특히 분산 시스템은 추론하기 가 훨씬 더 어렵습니다.
원자 업데이트, 트랜잭션, 일관성 / 참조 무결성 및 내구성은 매우 중요하며 급히 포기해서는 안됩니다. 데이터가 불완전하거나 오래되었거나 완전히 틀린 경우에는 데이터가 거의 없습니다. 비즈니스 요구 사항으로 ACID를 가지고 있지만 즉시 사용할 수없는 데이터베이스 기술을 사용하는 경우 (예 : 많은 NoSQL 데이터베이스 또는 마이크로 서비스 당 DB 아키텍처), 응용 프로그램 은 그 차이를 메워 그 보증을 제공해야합니다.
이것은 불가능하지는 않지만 제대로하기에는 까다 롭습니다. 매우 까다 롭습니다. 특히 각 데이터베이스에 여러 작성자가있는 분산 설정에서. 이러한 어려움은 데이터 손실, 불일치 데이터 등을 포함하여 버그가 발생할 가능성이 높습니다.
예를 들어, Cassandra 분석 부터 시작하여 잘 알려진 분산 데이터베이스 시스템 의 Jepsen 분석을 읽어보십시오 . 나는 그 분석의 절반을 이해하지 못하지만 TL; DR은 분산 시스템이 너무 어려워서 업계를 선도하는 프로젝트조차도 뒤늦게 분명하게 보일 수있는 방식으로 잘못 이해하기도합니다.
분산 시스템은 또한 더 큰 개발 노력을 암시합니다. 어느 정도까지는 개발 비용이나 하드웨어 강화 비용 사이에 직접적인 상충 관계가 있습니다.
예 : 매달린 참조
실제로 ACID를 완화 할 수 있는지 여부와 방법을 확인하려면 컴퓨터 과학이 아니라 비즈니스 요구 사항을 살펴 봐야합니다. 예를 들어 많은 외래 관계는 그다지 중요하지 않을 수 있습니다. 제품 – 범주 n : m 관계를 고려하십시오. RDBMS에서는 기존 제품과 기존 범주 만 해당 관계의 일부가 될 수 있도록 외래 키 제약 조건을 사용할 수 있습니다. 별도의 제품 및 카테고리 서비스를 도입하고 제품 또는 카테고리를 삭제하면 어떻게됩니까?
이 경우 큰 문제가되지 않을 수 있으며 더 이상 존재하지 않는 제품이나 범주를 필터링하도록 응용 프로그램을 작성할 수 있습니다. 그러나 트레이드 오프가 있습니다!
여기에는 JOIN여러 데이터베이스 / 마이크로 서비스에 대한 응용 프로그램 수준이 필요할 수 있으며 데이터베이스 서버에서 응용 프로그램으로 처리가 이동하기 만합니다. 총로드가 증가하고 네트워크를 통해 추가 데이터를 이동해야합니다.
페이지 매김으로 혼란 스러울 수 있습니다. 예를 들어 카테고리에서 다음 25 개의 제품을 요청하고 해당 응답에서 사용할 수없는 제품을 걸러냅니다. 이제 응용 프로그램에 23 개의 제품이 표시됩니다. 이론적으로 제품이없는 페이지도 가능합니다!
각 관련 변경 후 또는 정기적으로 매달린 참조를 정리하는 스크립트를 실행하는 것이 좋습니다. 이러한 스크립트는 여전히 존재하는지 여부를 확인하기 위해 백업 데이터베이스 / 마이크로 서비스에서 모든 제품 / 카테고리를 요청해야하기 때문에 상당히 비쌉니다.
이것은 분명해야하지만 명확성을 위해 ID를 재사용하지 마십시오. 자동 증분 스타일 ID는 괜찮을 수도 있고 아닐 수도 있습니다. GUID 또는 해시는 예를 들어 항목이 데이터베이스에 삽입되기 전에 ID를 할당 할 수있는 등의 유연성을 제공합니다.
예 : 동시 주문
이제 제품 – 주문 관계를 고려하십시오. 제품이 삭제되거나 변경되면 주문은 어떻게됩니까? 이제 간단하게 디스크 공간을 거래 할 수 있도록 관련 제품 데이터를 주문 항목에 간단히 복사 할 수 있습니다. 그러나 제품 가격이 변경되거나 해당 제품을 주문하기 직전에 제품을 사용할 수 없게되면 어떻게됩니까? 분산 시스템에서는 효과가 전파되는 데 시간이 걸리며 오래된 데이터로 인해 순서가 진행될 수 있습니다.
다시이 문제에 접근하는 방법은 비즈니스 요구 사항에 따라 다릅니다. 오래된 주문이 허용 될 수 있으며 나중에 주문을 이행 할 수없는 경우 주문을 취소 할 수 있습니다.
그러나 이는 동시 설정과 같은 옵션이 아닐 수도 있습니다. 처음 10 초 이내에 콘서트 티켓을 구매하기 위해 서두르는 3000 명의 사람들을 고려하고, 가용성의 변화가 전파 되려면 10ms가 필요하다고 가정하자. 여러 사람에게 마지막 티켓을 판매 할 확률은 얼마입니까? 와 그 충돌이 처리하지만, 포아송 분포를 사용하는 방법에 따라 달라집니다 λ = 3000 / (10s / 10ms) = 3우리가 얻을 P(k > 1) = 1 - P(k = 0) - P(k = 1) = 80%10ms의 간격 당 충돌의 기회를. 사기를 저 지르지 않고 주문의 대부분을 판매하고 나중에 취소 할 수 있는지 여부는 법무 부서와 흥미로운 대화로 이어질 수 있습니다.
실용주의는 최고의 기능을 체리 피킹하는 것을 의미합니다.
다행스럽게도 분산 데이터베이스 모델로 이동할 필요가 없다는 것이 좋은 소식입니다. 마이크로 서비스를“적절하게”하지 않으면 마이크로 서비스 클럽을 탈퇴 할 수 없습니다. 그러한 클럽이없고 마이크로 서비스를 구축 할 수있는 진정한 방법이 없기 때문입니다.
실용주의는 항상 승리하므로 문제를 해결할 때 다양한 접근 방식을 혼합하고 일치시킵니다. 이는 중앙 데이터베이스가있는 마이크로 서비스를 의미 할 수도 있습니다. 실제로 분산 데이터베이스의 고통을 겪지 않아도됩니다.
마이크로 서비스없이 확장 할 수 있습니다.
마이크로 서비스에는 두 가지 주요 이점이 있습니다.
- 개별 팀이 독립적으로 개발 및 배포 할 수있는 조직의 이점 (서비스는 안정적인 인터페이스를 제공해야 함).
- 각 마이크로 서비스를 독립적 으로 확장 할 수있는 운영상의 이점 .
독립적 인 확장이 필요하지 않은 경우 마이크로 서비스는 그다지 매력적이지 않습니다.
데이터베이스 서버는 이미 읽기 복제본을 추가하여 독립적으로 확장 할 수있는 일종의 서비스입니다. 저장 프로 시저를 언급했습니다. 그것들을 줄이면 다른 확장 성 토론이 무의미한 영향을 미칠 수 있습니다.
또한 모든 서비스를 라이브러리로 포함하는 확장 가능한 단일체를 가질 수 있습니다. 그런 다음 더 많은 모노리스 인스턴스를 시작하여 확장 할 수 있습니다. 물론 각 인스턴스는 상태 비 저장이어야합니다.
이는 모놀리스가 너무 커서 합리적으로 배포 할 수 없을 때까지 또는 일부 서비스에 특별한 리소스 요구 사항이있어 독립적으로 확장하려는 경우가 있습니다. 추가 자원과 관련된 문제점 도메인에는 별도의 데이터 모델이 포함되지 않을 수 있습니다.
강력한 비즈니스 사례가 있습니까?
조직의 비즈니스 요구를 알고 있으므로 분석을 기반으로 마이크로 서비스 당 데이터베이스 아키텍처에 대한 인수를 만들 수 있습니다.
- 특정 규모가 필요하며이 아키텍처는 이러한 설정 및 대체 솔루션에 대한 개발 노력의 증가를 고려하여 확장 성을 확보하기위한 가장 비용 효율적인 접근 방법입니다. 과
- 비즈니스 요구 사항에 따라 위에서 설명한 것과 같은 다양한 문제가 발생하지 않고 관련 ACID 보증이 완화됩니다.
반대로,이를 입증 할 수없는 경우, 특히 현재 데이터베이스 설계가 미래에 충분한 규모를 지원할 수있는 경우 (동료가 생각하는 것처럼), 귀하도 답을 얻습니다.
확장성에 큰 YAGNI 구성 요소도 있습니다. 불확실성에 직면 한 것은 현재 확장 성을 구축하기위한 전략적 비즈니스 결정입니다 (총 비용은 낮지 만 기회 비용이 필요하며 필요하지 않을 수 있음). 실제 규모에 대한 아이디어). 이것은 주로 기술적 결정이 아닙니다.