서비스 지향 아키텍처(SAO) 특징과 MSA와의 차이점

0. 개요

전체 시스템을 서비스 중심으로 설계하는 아키텍처 스타일입니다.

기업 환경에서 중복되는 프로세스나 업무들을 하나의 서비스 단위로 개발합니다.

서비스의 생성과 활용을 높여 비즈니스 환경 변화와 업무 변화에 민첩하게 대응할 수 있는 아키텍처입니다.

이 서비스 지향 아키텍처에 다섯 가지의 주요 특징이 있습니다.

1. 서비스 계약
2. 서비스 가용성
3. 보안
4. 트랙잭션
5. 서비스 관리

SAO와 MSA 모두 비즈니스 변화 대응을 위한 서비스 중심 아키텍처라는 공통점이 있습니다.

하지만, MSA와 네 가지의 주요 차이점이 있습니다.

1. 서비스 상대적 크기와 관심사 차이
2. 서비스 오너십 차이
3. 서비스 공유 정도의 차이
4. 기술 방식의 차이

1. 특징

1.1 서비스 계약

서비스 계약은 서비스와 서비스 소비자와의 계약을 뜻합니다.

서비스는 약속한 기능을 수행해야 합니다.

서비스 소비자는 서비스를 사용하기 위한 계약 규칙을 준수해야 합니다.

서비스 계약은 때에 따라서 서비스 자체에 문제가 발생되거나 개선될 수 있습니다.

버전 관리를 통해 문제가 발생되면 롤백을 하고, 더 우수한 서비스를 안정적으로 제공하기 위해 높은 버전의 계약을 제공합니다.

1.2 서비스 가용성

SAO는 서비스들의 가용성을 보장하기 위해 타임아웃과 라우팅 기능 구현을 제안합니다.

일정 시간동안 서비스 요청에 대해 반응이 없으면(타임아웃) 기존 요청 경로를 차단하고, 다른 경로로 요청 경로를 변경(라우팅)하는 기능을 가동하여 서비스가 정상적으로 동작되게 합니다.

이 라우팅은 L4,L7과 같은 하드웨어 장비를 이용하거나 서킷 브레이커(Circuit Breaker)와 같은 소프트웨어 기능으로 구현할 수 있습니다.

1.3 보안

SAO에서는 서비스 간에 호출이 발생할 수 있습니다.

하나의 서비스가 다른 서비스 호출할 때 인증 및 권한 확인이 없으면 보안상 문제가 발생할 수 있습니다.

이 문제는 권한에 관한 제어권을 피호출 서비스 자체에 넘기면 다소 해결할 수 있습니다.

1.4 트랜잭션

SAO에서는 성능상의 문제로 읽기 전용 DB와 쓰기 DB를 분리 구성하도록 권고합니다.

이렇게 분리하면 동기화를 해야하기 때문에, 데이터 일관성 및 실시간 동기화 이슈가 발생합니다.

SAO에서 BASE(Basically Available Soft State Eventual Consistency) 기반의 DB를 사용합니다.

기본 가용성(Basically Available)는 요청시 읽기 DB에서 데이터를 가져옵니다. 즉, 쓰기 DB와 동기화 되지 전 정보를 읽어올 수 있습니다.

소프트 상태(Soft State)는 상태가 계속 변경될 수 있다는 의미입니다. 즉, 쓰기 DB와의 동기화로 인해 데이터가 바뀔수 있습니다.

최종 일관성(Eventual Consistency)는 동기화 완료시 데이터의 일관성을 보장한다는 의미입니다. 동기화 전에는 읽기 DB와 쓰기 DB의 데이터가 다룰 수 있지만, 동기화가 완료되면 결과정으로 데이터의 일관성이 보장됩니다.

1.5 서비스 관리

서비스들의 수가 동적으로 증가하여 과부하나 오류 상황에서도 가용성을 유지할 수 있도록 관리해야 합니다.

이를 위해 서비스의 상태는 항상 실시간으로 관리되고 시각화하여 모니터링할 수 있어야 합니다.

2. MSA와 차이점

2.1 서비스 상대적 크기와 관심사 차이

MSA는 작고 한 가지 일에 집중합니다.

SOA는 비즈니스에 집중합니다.

때문에, SOA에서는 여러 일이 하나의 비즈니스로 묶여 상대적으로 서비스 크기가 커질 수 있습니다.

2.2 서비스 오너십 차이

MSA는 서비스별로 하나의 작고 독립적인 팀에서 개발하고 관리합니다.

SOA는 서비스를 공유하기 위해 중앙의 인프라 미들웨어를 탑재하고, 필요에 따라서 연결 및 조합하여 새로운 서비스를 만듭니다.

따라서 업무팀, 공통 기능 개발팀, 개발팀 간의 상호 협력이 필요합니다.

2.3 서비스 공유 정도의 차이

MSA는 서비스 공유의 최소화로 결합도를 낮추기를 지향합니다.

SOA는 되도록 많은 서비스의 공유로 재사용율을 높여 비용을 절감하고 품질 향상을 지향합니다.

2.4 기술 방식의 차이

MSA는 각 독립된 서비스가 필요에 따라 REST API를 노출하고 사용합니다.

SOA는 공통의 서비스를 ESB라는 공통된 채널에 모아 사업 측면에서 공통 서비스 형식으로 제공합니다.

즉, SOA는 흩어져 있던 같은 역할을 하는 서비스들을 통합하여 ESB에 담아서 필요할 때 마다 사용할 수 있는 구조입니다.

결국 MSA는 분산과 독립이고 SOA는 통합과 공유라는 개념을 가진다고 할 수 있습니다.

위 그림에서 SOA에는 ESB를 제외하고도 UDDI, WSDL이라는 개념이 있습니다.

UDDI(Universal Description, Discovery and Integeration)는 SOA의 통합된 서비스들을 저장하는 서비스 저장소입니다.

WSDL(Web Services Description Language)는 UDDI에 공유한 서비스의 명세가 담겨있는 서비스 명세서입니다.

 

사용자는 WSDL의 명세를 찾고하여 stub이라는 클래스(프로그램)를 생성하여 서버와 SOAP를 이용하여 통신합니다. 만약 WSDL의 명세가 바뀌면 이를 참조하는 모든 클라이언트 프로그램을 바꿔야하기 때문에, 변경과 장애의 결합도가 매우 높습니다.

구분	MSA	SOA
사상	서비스 지향	서비스 지향
서비스 오너십	조직(팀) 단위 자율성 부여	조직(팀) 간 협업
서비스 크기	SOA 대비 작음	MSA 대비 큼
서비스 공유 정보	서비스 간 독립	서비스 공유
서비스 공유 방식	API	서비스 공유를 위한 미들웨어
서비스 통신 방식	RESTful API 등	SOAP, WSDL, UDDI, ESB

 

이 글은 '자바 기반의 마이크로서비스 이해와 아키텍처 구축하기' 책을 기반으로 작성했습니다.