티스토리 뷰

Architecture

Service Based Architecture

realizers 2023. 9. 13. 23:40
728x90
반응형

Service Based Architecture

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

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

 

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

 

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

 

Service Based Architecture

 

서비스 계약

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

 

💡 서비스 기반 계약

 

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

 

💡 소비자 중심 계약

 

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

 

 

서비스 계약 버전 관리

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

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

 

계약 버전 번호

 

데이터베이스 분할

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

 

 

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

 

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

 

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

 

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

 

 

Service Based Architecture의 장단점

장점

 

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

단점

 

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

 

 

 

 

 

참고

 

 

 

 

 

 

 

728x90
반응형
저작자표시

'Architecture' 카테고리의 다른 글

Space Based Architecture  (0) 2023.09.21
Event Driven Architecture  (0) 2023.09.16
Microkernel Architecture  (0) 2023.09.09
PipeLine Architecture  (0) 2023.09.07
Layered Architecture  (1) 2023.09.06