Micro Service Archtecture 이해하기 3. SOA(Service Oriented Archtecture) 이해

서비스지향 아키텍처(SOA)란?

대규모 시스템 환경에서 업무 처리 단위를 각각의 서비스로 반영하여 데이터 중심이 아닌 전체 시스템을 서비스 중심으로 설계하는 아키텍처 스타일입니다. 마이크로서비스 아키텍처가 주목받기 이전부터 기업 환경에서 중복되는 프로세스나 업무들을 하나의 서비스 단위로 개발하여 각 서비스는 호출 가능한 상태로 개발하자는 노력이 계속되어 왔습니다.

간단하게 SOA와 Monolithic Archtecture도 비교해봅시다.

medium.com - What is Service-Oriented-Architecture? (https://medium.com/@SoftwareDevelopmentCommunity/what-is-service-oriented-architecture-fa894d11a7ec)

 서비스의 생성과 활용을 높여서 비즈니스 환경 변화와 업무 변화에 민첩하게 대응할 수 있는 아키텍처를 갖추기 위함입니다. 서비스지향 아키텍처의 몇 가지 특징에 대하여 알아보겠습니다.

1. 번째 특징. 서비스 계약.
   서비스 계약은 서비스와 서비스 소비자와의 계약을 뜻합니다. 서비스는 약속한 기능을 수행해야 하고, 서비스 소비자는 서비스를 사용하기 위한 계약 규칙을 준수해야 합니다.
   
   
2. 번째 특징. 서비스의 가용성. 
    서비스지향 아키텍처에서 서비스들의 가용성을 보장하기 위한 소프트웨어적인 방법으로 타임아웃 기능 구현을 제안합니다.
   일정 시간 동안 서비스 요청에 대한 반응이 없으면 기존 요청 경로를 차단하고, 다른 경로로 요청 경로를 변경하는 기능을 가동하여 서비스가 정상적으로 수행되도록 합니다.
    이렇게 서비스 가용성을 유지하기 위한 방법을 서비스 라우팅이라고 합니다. 라우팅 기능을 L4/L7 같은 하드웨어 장비를 이용하여 구현할 수도 있고, 서킷 브레이커(circuit breaker) 같은 소프트웨어적인 기능으로 구현할 수 있습니다.
   
   
3. 번째 특징. 보안.
    서비스지향 아키텍처에서는 서비스 간에 호출이 발생할 수 있습니다. 이때, 하나의 서비스가 다른 서비스를 호출할 경우 별도의 인증 및 권한 확인 없이 바로 호출할 수 있는 구조가 되면 자칫 보안상 문제가 될 수 있습니다. 권한에 관한 제어권을 서비스 자체에 넘기면 이런 문제는 다소 해결됩니다.
4. 번째 특징. 트랜잭션. 
    서비스가 분할되고 서비스에서 발생하는 트랜잭션들에 대한 일관성 유지입니다. 일반적으로 서비스지향 아키텍처에서는 성능상의 문제로 데이터베이스 읽기 전용 데이터 저장소와 데이터베이스 쓰기 전용 데이터 저장소를 분리-구성하도록 권고합니다.
   읽기 수행의 지연으로 쓰기가 불가능한 상황은 발생하지 않을 것입니다. 하지만, 쓰인 데이터를 읽기 위해서는 데이터의 이동이 필요합니다. 이 부분에서 데이터의 일관성과 실시간 동기화 이슈가 발생합니다. (아래 단락에서 추가 설명이 있습니다.)
   
   
5. 번째 특징. 서비스 관리
    서비스들의 수가 많아지면 이들 간의 관계를 관리해야 합니다. 상황에 따라서는 서비스가 동적으로 증가하여 과부하나 오류 상황에서도 지속 가능한 서비스가 가능하도록 관리됩니다. 특정 서비스의 오류가 발생하면 자연스럽게 다른 정상적인 서비스로 요청 흐름의 변경도 가능합니다. 서비스의 상태는 항상 실시간으로 관리되고 시각화하여 모니터링할 수 있어야 합니다.
   
   
6. 번째 특징에서 더 나아가, 트랜잭션과 데이터 동기화 문제는 저도 실무에서 많이 고민하고 있는 부분인데요, 자세히 알아보는 포스팅을 추후에 작성해보도록 하겠습니다.

서비스 지향 아키텍처에서 데이터베이스는 클라우드의 핵심 개념인 BASE(Basically Available Soft State Eventual Consistency) 트랜잭션입니다. 'basically available'의 대표적은 기술 메커니즘은 낙관적 잠김(optimistic locking)과 큐(queue)이고, 'soft sate'는 외부 전달 데이터로 인해서 상태가 갱신되는 것입니다. 즉, 두 개의 노드가 있으면 한쪽에서 전달된 데이터로 인해 다른 한쪽의 노드가 갱신된다는 사상입니다. 'eventual consistency'는 두 노드의 데이터가 일시적으로 불일치한 시점이 있고 일관성이 없는 상태이지만, 결국에는 두 노드의 데이터가 같아진다는 개념입니다.   

SOA(Service Oriented Archtecture)와 MSA(Micro Service Archtecture)의 차이점

비즈니스 변화 대응을 위한 서비스 중심의 아키텍처라는 점에서 공통점이 있지만, 서비스의 상대적 크기와 관심사, 오너십(ownership), 기술 구조에서 차이가 있습니다. 

SOA와 MSA의 공통점은 소프트웨어를 설계할 때 서비스 중심의 설계를 지향하는 것입니다. 기능 중심의 모듈 재사용보다 상위 수준의 서비스 수준에서의 재사용성에 초점을 맞춥니다. 나만 SOA는 비즈니스 측면에서의 서비스 재사용성을 강조하는 반면, MSA는 한 가지 작은 서비스에 집중하기를 강조합니다. 이외에도 SOA는 되도록 많은 서비스의 공유를 위해 ESB(Enterprise Service Bus)라는 서비스 채널을 이용하여 서비스를 공유하고 재사용하는데 초점을 맞춘다면, MSA는 되도록 서비스를 공유하지 않고 독립되어 실행되는 것을 지향합니다. 

medium.com - What is Service-Oriented-Architecture? (https://medium.com/@SoftwareDevelopmentCommunity/what-is-service-oriented-architecture-fa894d11a7ec)

SOA와 MSA의 차이점을 정리해 봅시다.

1. 서비스의 상대적 크기와 관심사에서의 차이점입니다.
    MSA에서 서비스는 작고 한 가지 일에 집중하는 반면, SOA 서비스는 비즈니스에 집중합니다.
   책을 판매하는 비즈니스 모델에서 SOA관점으로 접근하면, '제품 관리', '주문관리' 등으로 구성된 서비스를 구성할 것입니다.
   MSA관점으로 접근하면 좀 더 세분화하여, 제품 조회, 제품 등록, 제품 로케이션 관리,... 주문 조회, 주문 등록 등으로 구체화할 수 있습니다.
   
   
2. 서비스 오너십 측면에서 MSA는 하나의 작은 팀에서 관리합니다.
    MSA는 하나의 독립된 팀에서 개발하고 관리합니다. 반면 SOA의 서비스는 비즈니스 프로세스의 흐름과 관련된 서비스를 공유하기 위해서 중앙의 인프라 미들웨어에 탑재하고, 필요에 따라서 연결 및 조합하여 새로운 서비스를 만들어 냅니다. 이 과정에서 업무팀, 공통 기능 개발팀 등 관련 부서와의 협업이 반드시 필요합니다.
   
   
3. 서비스 공유 정도의 차이입니다. 
    MSA는 서비스 공유의 최소화를 지향하는 반면, SOA는 되도록 많은 서비스의 공유를 지향합니다.
   MSA는 서비스 간의 결합도를 낮추어 변화에 능동적으로 대응하기 위한 민첩성에 초점을 두지만, SOA는 재사용을 높여 비용을 절감하고 품질을 높이는 데 초점을 둡니다.
   
   
4. 기술 방식의 차이입니다. 
    SOA가 공통의 서비스를 ESB라는 공통된 채널에 모아 사업 측면에서 공통 서비스 형식으로 서비스를 제공하였다면, 마이크로서비스는 각각의 독립된 서비스가 필요에 따라 노출된 REST API를 사용합니다.

결국, SOA는 통합과 공유, MSA는 분산과 독립이라는 개념으로 구분할 수 있습니다. 

Why MSA?

- 민첩한 서비스 
 민첩한 서비스를 만들기 위해서는 서비스 단위를 아주 작게 만들어서 즉시 개발 배포하여 시장의 반응을 볼 수 있는 형태여야 합니다.
기업의 조직이 세분되고, 각각의 조직이 자율적이고 독립적으로 서비스를 생성하고 배포할 수 있다면 보다 능동적으로 비즈니스 환경에 대처할 수 있습니다. 

 - 유연한 인프라
 서비스 개발에서 배포, 운영까지 서비스의 확장이 자유롭고 관리가 쉬운 자동화된 인프라입니다. 기업의 문화와 적절한 방법론 그리고 이를 실천할 수 있는 기술적 인프라가 서로 조화를 이룰 때 마이크로서비스의 진정한 가치가 빛나는 것입니다.

 - Happy Path
 위에서 언급한 MSA의 특성은 'Happy Path'를 구현하기에 적절합니다. Happy Path는 서비스의 기본적인 사상을 실체화하기 위한 최소한의 작업 경로를 뜻합니다.

 

참고 자료

• [Granular Application Architecture Patterns(세분화된 애플리케이션 아키텍처 패턴)]
• 자바기반의 마이크로서비스 이해와 아키텍처 구축하기 - 박성훈 지음
• What is Service Oriented Archtecture

What Is Service-Oriented Architecture?

자바 기반의 마이크로서비스 이해와 아키텍처 구축하기

Granular Application Architecture Patterns