[소프트웨어 아키텍처] 서비스 기반 아키텍처 스타일

토폴로지

서비스 기반 아키텍처의 기본 토폴로지는 각각 따로 배포된 유저 인터페이스와 원격서비스, 그리고 모놀리스 데이터 베이스로 이루어진 대규모 분산 레이어 구조 입니다. 여러 서비스가 단일 모놀리식 데이터베이스를 공유 하므로 어플리케이션 서비스는 다 합해도 4~12개 평균 7개 정도 입니다.

서비스 기반 아키텍처의 도메인 서비스는 각각 단일 인스턴스로 배포하지만 확장성, 내고장성, 처리량 요구사항에 따라 인스턴스를 여럿 둘 수도 있습니다. 또한 서비스는 원격 액세스 프로토콜로 유저 인터페이스 외부에서 접속할 수 있습니다. 유저 인터페이스는 프록시나 게이트웨이로 구성된 API 레이어를 통해 서비스에 접속 할 수 있지만 대개는 서비스 로케이터 패턴에 따라 유저 인터페이스, API 게이트웨이, 프록시에 내장된 유저 인터페이스를 직접 액세스 합니다.

마지막으로 서비스 기반 아키텍처의 경우 중앙 공유 데이터베이스를 사용한다는 특징이 있습니다. 따라서 서비스는 기존 모놀리식 레이어드 아키텍처와 동일한 방식으로 SQL 쿼리와 조인 기능을 사용하면 됩니다.

서비스 기반 아키텍처 사용 예시

서비스 기반 아키텍처는 도메인 주도 설계와 궁합이 잘 맞습니다. 서비스 단위를 큰 단위로 나누고 그 범위를 도메인으로 한정하기 때문에 각 도메인은 개별 배포된 도메인 서비스에 딱 맞아 떨어진다고 보면 됩니다. 서비스 기반 아키텍처 서비스는 각각 지정된 도메인을 포함하므로 그 기능을 단일 소프트웨어 단위로 구분하면 해당 도메인을 더 쉽게 변경할 수 있습니다.

전자상거래(E-Commerce) 시스템

서비스 구성 예

• Order Service : 주문 생성, 상태 변경
• Payment Service : 결제 승인/취소
• Product Service : 상품 정보 조회
• Inventory Service : 재고 차감
• Member Service : 회원 정보

특징

• 하나의 애플리케이션(또는 몇 개의 애플리케이션) 안에 존재
• DB는 공유하거나 스키마만 분리
• REST API로 서비스 간 호출

👉 마이크로서비스처럼 완전 분리는 아니지만
👉 주문/결제/재고 로직이 서로 독립적으로 진화 가능

통신사 청구(Billing) 시스템

서비스 구성 예

• Billing Service : 청구 계산
• Rating Service : 사용량 요율 계산
• Invoice Service : 청구서 생성
• Payment Service : 수납 처리
• Customer Service : 고객 정보

왜 서비스 기반이 잘 맞나?

• 도메인이 명확하게 분리됨
• 청구서·요율·수납 로직 변경 빈도가 다름
• 전체를 마이크로서비스로 쪼개기엔 운영 복잡도 과도

배치 중심 시스템 (대용량 처리)

서비스 구성 예

• Collect Service : 데이터 수집
• Validate Service : 검증
• Calculate Service : 계산
• Generate Service : 결과 생성

특징

• 서비스별 배치 Job 운영
• 장애 격리 가능
• 전체를 마이크로서비스로 쪼개면 오히려 비효율

정리

서비스 기반 아키텍처는 복잡하지 않게 도메인 서비스별로 나눠 설계 할 수 있는 아키텍처 입니다. 여러개의 서비스로 잘게 나누게 되면 서비스간 호출 및 복잡도 이슈가 발생하게 되는데 서비스 기반 아키텍처의 경우 큰 단위로 나누는 편이라 분산 아키텍처만큼 정교한 조율은 필요로 하지 않습니다.