마이크로 서비스 아키텍처가 마이크로 서비스 당 별도의 데이터베이스를 필요로하는 경우 비용이 많이 들고 관리가 불가능합니다. 왜 필요한가요?

마이크로 서비스에 대해 읽었으며 격리를 달성하기 위해 서비스마다 별도의 DB를 만드는 것이 비논리적 인 것 같습니다. 웹 서비스와 단일 데이터베이스 만 사용하여 동일한 결과를 얻을 수 있습니다. 왜 필요한가요? 데이터베이스를 분리하는 것은 논의 할 수없는 것입니다. 아니면 내가 틀렸다? 이것에 대해 안내해 줄 수 있습니까?

왜 필요한가요?

당신은하지 않습니다.

각 서비스에 대해 별도의 데이터베이스를 만들면 도메인 경계를 강화하는 데 도움이되지만 한 가지 방법 일뿐입니다. 모든 서비스가 동일한 데이터베이스를 공유하는 것을 막을 수있는 것은 없습니다.

서비스가 작동하고 다른 서비스가 소유 한 데이터에 예기치 않은 일을하지 않는 한 괜찮습니다.

나는 당신이 무엇을 읽었는지 모르지만, 마이크로 서비스 아키텍처에 대해 많은 다른 의견이 있다는 것을 알고 있어야합니다. 여기 주제에 대한 좋은 블로그 게시물이 있습니다.

나는 사람들이이 개념을 부분적으로 사소하게 "각 마이크로 서비스가 자체 데이터베이스를 소유하고 제어해야하며 두 서비스가 데이터베이스를 공유해서는 안된다"고 언급 한 것을 보았다. 아이디어는 건전합니다. 서비스간에 단일 데이터베이스를 공유하지 마십시오. 경쟁하는 읽기 / 쓰기 패턴, 데이터 모델 충돌, 조정 문제 등과 같은 충돌이 발생하기 때문입니다.

그러나 단일 데이터베이스는 ACID 트랜잭션, 단일 위치, 잘 이해 (kinda?), 관리 할 수있는 장소 등 많은 안전과 편의를 제공합니다.

마이크로 서비스로의 여정은 바로 여정 입니다. 회사마다 다릅니다. 단단하고 빠른 규칙은 없으며 트레이드 오프 만 있습니다.

마이크로 서비스에 대한 가장 어려운 부분 : 데이터

Dan Wilson이 대답 할 때 실제로 필요하지 않습니다. 마이크로 서비스는 새로운 것이 가장 중요하며, 모든 새로운 인기가있는 것처럼 사람들은 많은 가치를 제공하지 않더라도 많은 곳에서 사용합니다.

마이크로 서비스를 사용하면 "마이크로"수준에서 독립적으로 배포하고 확장 할 수 있습니다. 이 세분성은 개발 팀을보다 효과적으로 분리하고 하나의 큰 릴리스보다는 필요에 따라 릴리스하고 새로운 기술이나 프로세스를 독립적으로 시도하는 등의 작업을 수행 할 수 있기 때문에 많은 기술적 이점과 비 기술적 이점을 제공합니다. DB에 대한 의존성 때문에 많은 것들이 있습니다. 다른 서비스의 데이터에 대해 걱정하지 않고 서비스를 배포 할 수 없으면 손실 된 것입니다.

데이터베이스를 분리하는 것은 논의 할 수없는 것입니다. 아니면 내가 틀렸다?

즉, 당신은 또한 명백한 잘못입니다.

클라우드에서 작업 할 때는 데이터베이스가 저렴합니다. 보통 무료! 물론, 서버 비용은 들지만 마이크로 서비스 당 개별 서버에 대해서는 이야기하지 않습니다 (최소한 처음에는 아님). (논리적으로) 확장 가능한 데이터베이스에 영향을주는 데이터베이스 간 쿼리를 피하는 데 부지런한 한 많은 (논리적) 데이터베이스가있는 단일 서버 만 있으면됩니다. 지옥, 크로스 DB 쿼리는 Azure SQL과 같은 일부 클라우드 데이터베이스 서비스에서 불가능합니다. 부지런 할 필요조차 없습니다 ...

그리고 데이터베이스를 공유하는 마이크로 서비스도 보았지만 각 서비스에는 고유 한 스키마가 있습니다. 다시 말하지만 데이터 경계를 넘는 쿼리를 피하는 데 부지런해야합니다.

많은 장소가 부지런하지 않습니다. 이들은 엔트리 레벨 개발자 또는 마이크로 서비스 접근 방식을 소중하게 생각하지 않거나 팀 리더가 열악하거나 타임 라인 압력을 가해 사람들이 지름길을 택하게합니다.

별도의 데이터베이스를 사용하는 것이 서비스 독립성을 허용하는 분리를 강제 실행하는 가장 깨끗한 방법이지만 유일한 방법은 아닙니다. 그리고 그것은 비싸지 않습니다 -특히 공유 데이터베이스에서 데이터 경계를 시행하는 데 소비 한 시간 / 급여와 비교할 때 비용 이 많이 들지 않습니다 .

왜 필요한가요?

마이크로 서비스 (대부분 SOA)의 막대한 이점은 구현뿐만 아니라 사용중인 기술의 내부 추상화 수준이 높다는 것입니다. 예를 들어 시스템이 5 개 팀에 의해 5 개의 마이크로 서비스 형태로 개발 된 경우 한 팀은 다른 팀에 의견을 묻지 않고도 완전히 다른 기술 스택 (예 : Microsoft 스택에서 LAMP로)으로 전환 할 수 있습니다.

Amazon AWS 또는 Twilio를보십시오. 서비스가 Java 또는 Ruby로 구현되었는지 알고 있습니까? 그들은 Oracle, PostgreSQL, Cassandra 또는 MongoDB를 사용합니까? 그들은 몇 대의 기계를 사용합니까? 당신은 심지어 그것에 관심이 있습니까; 다시 말해, 이러한 기술 선택이 해당 서비스 사용 방식에 영향을 미칩니 까? ... 더 중요한 것은 다른 데이터베이스로 이동하는 경우 이에 따라 클라이언트 응용 프로그램을 변경해야합니까?

두 서비스가 동일한 데이터베이스를 사용하면 어떻게됩니까? 발생할 수있는 문제의 일부는 다음과 같습니다.

• 서비스 개발 팀 1은 SQL Server 2012에서 SQL Server 2016으로 이동하려고합니다. 그러나 팀 2는 더 이상 사용되지 않는 기능을 사용하여 SQL Server 2016에서 제거되었습니다.

• 서비스 1은 대성공입니다. 두 머신 (마스터 및 페일 오버)에서 데이터베이스를 호스팅하는 것은 더 이상 옵션이 아닙니다. 그러나 클러스터를 여러 시스템으로 확장하려면 샤딩과 같은 전략이 필요합니다. 한편, 팀 2는 현재 규모에 만족하며 다른 것으로 이동할 이유가 없습니다.

• 서비스 1은 기본 인코딩으로 UTF-8로 이동해야합니다. 그러나 서비스 2는 Code Latin 1을 사용하여 만족합니다.

• 서비스 1은 특정 이름을 가진 사용자를 추가하기로 결정합니다. 그러나이 사용자는 이미 몇 달 전에 두 번째 팀에 의해 생성되었습니다.

• 서비스 1에는 다양한 기능이 필요합니다. 서비스 2는 매우 중요한 구성 요소이며 공격 위험을 줄이기 위해 데이터베이스 기능을 최소한으로 유지해야합니다.

• 서비스 1에는 15TB의 디스크 공간이 필요합니다. 속도는 중요하지 않으므로 일반 하드 디스크는 완벽합니다. 서비스 2는 최대 50GB가 필요하지만 가능한 한 빨리 액세스해야하므로 데이터가 SSD에 저장되어야합니다.

• ...

모든 작은 선택은 모든 사람에게 영향을 미칩니다. 모든 결정은 모든 팀의 사람들이 공동으로 수행해야합니다. 타협해야합니다. SOA의 맥락에서 원하는 것을 자유롭게 수행 할 수있는 자유와 비교하십시오.

너무 관리하기 어렵다 ...]

그렇다면 당신은 잘못하고 있습니다. 수동으로 배포한다고 가정합니다 .

이것은 어떻게해야하는지가 아닙니다. 데이터베이스를 실행하는 가상 머신 (또는 Docker 컨테이너)의 배치를 자동화해야합니다. 자동화 한 후에 2 대의 서버 또는 20 대의 서버 또는 2 천대의 서버를 배포하는 것은 크게 다르지 않습니다.

격리 된 데이터베이스에 대한 마술은 매우 관리하기 쉽다는 것 입니다. 수십 개의 팀이 사용하는 거대한 데이터베이스를 관리해 보셨습니까? 악몽이다. 모든 팀에는 특정 요청이 있으며, 무언가를 만지면 즉시 누군가에게 영향을 미칩니다. 데이터베이스가 앱과 쌍을 이루면 범위가 매우 좁아 져서 생각할 것이 훨씬 적습니다.

대규모 데이터베이스 에 전문 시스템 관리자 가 필요한 경우 한 팀에서만 사용하는 데이터베이스를이 팀에서 본질적으로 관리 할 수 ​​있으며 (DevOps 도 이와 관련 하여) 시스템 관리자의 시간이 절약됩니다.

너무 비싸

비용을 정의하십시오.

라이센스 비용은 데이터베이스에 따라 다릅니다. 클라우드 컴퓨팅 시대에 모든 주요 플레이어는 하나의 거대한 데이터베이스 대신 작은 데이터베이스가 많은 컨텍스트를 수용하도록 라이센스를 재 설계했다고 확신합니다. 그렇지 않은 경우 다른 데이터베이스로 이동하는 것을 고려할 수 있습니다. 그런데 오픈 소스가 많이 있습니다.

처리 능력에 대해 이야기하고 있다면 가상 컴퓨터와 컨테이너 모두 CPU 친화적이며, 하나의 거대한 데이터베이스가 동일한 작업을 수행하는 많은 작은 데이터베이스보다 적은 CPU를 소비한다는 것은 확실하지 않습니다.

문제가 메모리 인 경우 가상 머신은 적합하지 않습니다. 컨테이너는 필요한 것보다 많은 RAM을 소비하지 않는다는 것을 알고 원하는만큼 확장 할 수 있습니다. 큰 단일 데이터베이스에 비해 많은 작은 데이터베이스의 총 메모리 소비는 더 높지만 그 차이는 그다지 중요하지 않다고 생각합니다. YMMV.

“비싸다”고 생각하는 것에 의존하십시오.

데이터베이스가 반드시 고가의 상업용 데이터베이스 서버 일 필요는 없으며 (Oracle을 생각할 때) 반드시 자원이 부족한 것은 아닙니다. 요구 사항에 따라 SQLite 데이터베이스 또는 파일 시스템을 영구 데이터 저장소로 사용할 수 있습니다.

이러한 모든 서비스는 단일 데이터베이스 인스턴스 / 서버를 공유 할 수 있으며 서비스 당 격리 된 스키마 만 가질 수 있습니다.

여기서 핵심 논점은 서비스가 데이터를 소유하고 제어해야한다는 것입니다. 그것을 달성하는 방법은 선택과 기술적 세부 사항입니다.

서비스가 데이터를 소유하고 제어 할 수있는 가장 좋은 방법은 자체 "개인"데이터베이스를 보유하는 것입니다. 이를 통해 기술 및 데이터 체계 진화를 자유롭게 선택할 수 있습니다. 다른 서비스가 서비스 소유 데이터에 액세스 할 수있는 유일한 방법은 서비스에서 데이터를 요청하는 것입니다. 이런 식으로 내부 데이터 표현을 변경해야하는 경우 쉽게 변경할 수 있으며 다른 서비스는 중단되지 않습니다.

요약하자면. 서비스 당 데이터베이스를 보유하는 데 비용이 많이 들거나 필요하지는 않습니다. 마이크로 서비스를 개발할 때 특정 시점에서 결정해야 할 결정입니다. 각 선택에는 의미와 한계가 있습니다. 그것들을 연구하고 스스로 선택하십시오.