학교 프로젝트를 하면 꼭 작성해야하는 설계서
그리고 기획서 등등..
거기에 빠지지않는 여러 다이어그램중 하나인 아키텍처 다이어그램을
msa 기반으로 만들어보려한다.
근데 msa 랑 soa 두개의 정의가 모호해
한번 내친구에게 물어보고 답을 얻었다.
① 중앙 집중형 통신(ESB) vs 가볍고 단순한 통신(Smart Endpoints)
SOA (ESB 중심): SOA는 ESB(Enterprise Service Bus)라는 강력하고 지능적인 중앙 미들웨어를 둡니다. 이 ESB가 서로 다른 서비스 간의 프로토콜 변환, 메시지 라우팅, 데이터 포맷 변환 등을 전부 처리합니다. 시스템 전체의 비즈니스 오케스트레이션(흐름 제어)을 ESB가 쥐고 있기 때문에, ESB가 죽으면 시스템 전체가 마비되는 단점(Single Point of Failure)이 있습니다.
MSA (Dumb Pipes, Smart Endpoints): 반면 MSA는 "통로(Pipe)는 가볍게 만들고, 끝단(Endpoint)을 똑똑하게 만들자"는 철학을 가집니다. 중앙 버스 미들웨어 없이, 서비스들이 가벼운 HTTP REST API나 gRPC를 통해 직접 혹은 API Gateway를 거쳐 최소한의 규격으로 통신합니다.
② 데이터베이스 공유 vs 데이터베이스 격리
SOA: 대개의 경우 서비스들은 쪼개져 있지만, 백엔드의 데이터베이스는 하나로 공유합니다. 이 때문에 특정 서비스의 스키마를 변경하려면 다른 서비스 개발팀과 상의해야 하며, DB 병목 현상이 발생하면 전체 시스템 성능이 저하됩니다.
MSA: "Database Per Service" 원칙을 고수합니다. 각 마이크로서비스는 자신만의 전용 데이터베이스를 가집니다. 서비스 A는 PostgreSQL을 쓰고, 서비스 B는 MongoDB를 써도 무방합니다. 서로의 DB에 직접 쿼리를 날릴 수 없고 오직 API를 통해서만 데이터를 주고받기 때문에 영속성 레이어의 독립성이 완벽히 보장됩니다.
간략히 보면 msa 는 말그대로 micro 단위까지 독립적으로 설계된 아키텍처인 거 같았습니다.
그래서 msa하면 떠오르느 대표적인 회사인 Netflex의 아키텍처를 보면

이게 아키텍처 구조이다..
토나오는 비주얼
어쩄든 가트너가 제시한 msa 아키텍처 표준안을 살펴보고
내 서비스에 맞는 미들웨어들을 넣어
내 아키텍처를 작성해보았다.

많이 비슷한 다이어그램의 모형인데, 똑같이 중요한 6가지가 있다.
오른쪽에 Outer Architecture Capability라고 적혀있는데
1. External Gateway
2. Service Mesh
3. Runtime Platform
4. Backing Services
5. Tlelmetry
6. CI/ CD Automation
이 6가지를 고수하며 작성해 보았다
무료 미들웨어들을 고집했고, 많이 추상적이라 개발하려고 하는 서비스 입에 맞춰서 수정이 더 필요하다..
더 수정이 필요한 부분은 수정해 다시 게시하도록 하겠다.