Service Based Architecture

Architecture

Service Based Architecture

realizers 2023. 9. 13. 23:40

728x90

Service Based Architecture

서비스 기반 아키텍처는 각각 따로 배포된 유저 인터페이스와 원격 서비스 그리고 데이터베이스로 이루어진 대규모 분산 아키텍처입니다.

모놀리식 기반의 아키텍처를 가지고 있는 조직에서 마이크로서비스 아키텍처로 전환활 때 넘어가야 할 산들이 많은데(코드 분리, 데이터베이스 분리, 모니터링, 로깅, 분산 트랜잭션) 서비스 기반 아키텍처에서는 많은 변경이 필요 없다고 합니다.

서비스 기반 아키텍처에서 서비스는 큼지막한 단위로 분리해 별도로 배포하는 애플리케이션의 일부입니다. 이 아키텍처에서 도메인 서비스는 각각 단일 인스턴스로 배포하며, 확장성, 내고장성, 처리량 또는 요구사항에 따라 인스턴스를 여러 개 둘 수 있습니다. 또한, 서비스마다 데이터베이스를 가질 수 있거나, 중앙 공유 데이터베이스를 사용할 수 있습니다. 따라서 기본 모놀리식 아키텍처에서 동일한 방식으로 SQL 쿼리와 조인을 사용할 수 있습니다.

아래 그림을 보면 Service A는 데이터베이스가 독립적으로 존재하며, Service B, C는 데이터베이스를 공유하여 사용하고 있습니다. 이때 중요한 점은 각 데이터베이스에 있는 도메인 데이터를 다른 도메인의 서비스가 필요로 하지 않도록 설계하는 것입니다. 그렇게 해야 도메인 서비스 간 상호 통신을 방지하고(서비스 기반 아키텍처에서는 반드시 삼가야 한다고 함), 데이터베이스 간의 중복 데이터를 방지할 수 있습니다.

서비스 계약

서비스 기반 아키텍처에서는 서비스 기반 계약과 소비자 중심 계약이라는 두 가지 기본 유형의 서비스 계약 모델을 사용할 수 있습니다. 두 계약의 차이점은 협업의 정도입니다.

💡 서비스 기반 계약

서비스 기반 계약의 경우 서비스는 계약의 유일한 소유자이며, 일반적으로 서비스 소비자의 요구를 고려하지 않고 계약을 자유롭게 발전시키고 변경할 수 있습니다. 이 계약은 서비스 소비자가 새로운 서비스 기능을 필요로 하거나 원하는지 여부에 관계없이 모든 서비스 소비자가 새로운 서비스 계약 변경 사항을 채택하도록 강제합니다.

💡 소비자 중심 계약

소비자 중심 계약은 소비자가 협력하여 계약을 정의합니다. 그런 다음 서비스 공급자는 계약을 충족하기 위해 서비스를 구현합니다.
이 계약에서는 일반적으로 서비스 소비자가 누구인지, 각 서비스 소비자가 서비스를 사용하는 방법을 알아야 합니다. 서비스 소비자는 계약 변경을 자유롭게 제안할 수 있으며, 서비스는 다른 서비스 소비자에게 미치는 영향에 따라 이를 채택하거나 거부할 수 있습니다.

서비스 계약 버전 관리

서비스 계약의 맥락에서 또 다른 중요한 주제는 계약 버전 관리입니다. 계약 버전 관리를 사용하면 계약 변경을 포함하는 새로운 서비스 기능을 출시하는 동시에 이전 계약을 아직 사용하고 있는 서비스 소비자에게 이전 버전과의 호환성을 제공할 수 있습니다.

아래 그림에서 소비자 A와 소비자 B가 사용하는 계약은 동일하지만 버전 번호가 다릅니다. 예를 들어 버전 1.0에서는 의사소통 방법이 XML 기반일 수 있지만 버전 1.1에서는 JSON 기반에 요청사항 필드가 추가된 버전입니다. 이때 버전 1.0은 호환성을 유지하기 위해 바로 없앨 수 없습니다. 이는 위에서 설명한 소비자 중심 계약에 대한 개념에 더 가깝습니다.

데이터베이스 분할

서비스 기반 아키텍처의 여러 서비스는 중앙 공유 데이터베이스를 사용할 수 있습니다. 그러나 이러한 데이터베이스 커플링은 테이블 스키마 변경 시 문제가 발생할 수 있습니다. 예를 들어 테이블 스키마를 올바르게 변경하지 않은 경우 해당 변경으로 인해 모든 서비스에 영향을 미치기 때문에 이러한 변경 작업은 많은 노력이 필요하게 됩니다.

🧨 단일 공유 라이브러리 사용

모든 서비스의 엔티티 객체가 공유하는 단일 라이브러리를 생성하는 것은 서비스 기반 아키텍처 관점에서 가장 비효율적인 구현 방법입니다.
테이블 구조가 조금이라도 변경이 발생하면 해당 엔티티 객체가 포함된 단일 공유 라이브러리도 같이 변경을 해야 하는데, 변경된 테이블의 사용 여부와 상관없이 전체 서비스를 일제히 변경 후 재배포할 수밖에 없습니다.

💡 여러 공유 라이브러리 사용

데이터베이스 변경 영향도와 리스크를 낮추는 방법은 데이터베이스를 논리적으로 분할하고, 이러한 분할을 연합 공유 라이브러리를 통해 명시하는 것입니다.
데이터베이스를 논리적으로 분할함으로써 변경의 여파를 줄일 수 있습니다. 또한 모든 서비스의 공통 테이블을 변경하기 전에 먼저 해당 데이터베이스에 접근하고 있는 서비스들과 사전에 조율하는 과정이 필요합니다. 그리고 수정 권한을 관리자에게 맡김으로써 아무나 변경할 수 없도록 해야 합니다.

Service Based Architecture의 장단점

장점

분산 아키텍처에 속하긴 하나 서비스 기반 아키텍처의 도메인 서비스는 큼지막한 단위로 구성되므로 다른 분산 아키텍처에 비해 ACID 트랜잭션이 더 잘 보존할 수 있습니다.
분산 아키텍처 중에서 가장 구현하기 쉽고, 비용면에서 효율적입니다.

단점

서비스가 여러개이고, 도메인 서비스 간 상호 통신을 방지해야 하는데 실제 운영 상황에서는 이를 구현하기 어렵지 않을까? 생각이 듭니다.

참고

728x90

저작자표시