SOA(Service Oriented Architecture)란?
SOA(Service Oriented Architecture)
- 애플리케이션의 기능들을 비즈니스적인 의미를 가지는 기능단위로 묶어서 네트워크에서 공통적으로 쓰는, 어떤 표준화된 호출 인터페이스를 통해 서비스로 구현하고 이 서비스들을 기업의 업무에 따라 애플리케이션을 구성하는 소프트웨어 개발 아키텍처를 의미합니다.
- 2000년대 초반에 부각된 아키텍쳐 스타일로 SOA와 유사한 개념의 MSA가 근래 주요 분산 시스템 아키텍쳐로 자리잡았다.
- 주로 대용량 분산 시스템 구현하는데 사용되었다
- ![[Pasted image 20220811232833.png]]
Sevice의 의미
- 서비스라는 것은 비즈니스적인 의미를 가지는 기능들을 모아놓은 소프트웨어 컴포넌트를 뜻한다.
- 쉽게 말해 스프트웨어의 독립적인 기능 혹은 기능들을 뜻하는 용어이다. 특정 정보를 검색한다던지 어떤 작업을 실행하는 것처럼 구체적인 태스크가 있고 이를 수행하는 기능말이ㅏ. (Ex. 임직원 정보 서비스, 계좌 이체 서비스, 상품 주문 서비스)
- 일반적으로 SOA에서 말하는 서비스는 이 비즈니스 서비스를 의미한다.
- 이 서비스는 각각이 하나의 온전한 개별 기능, 비즈니스 기능을 수행하는데 필요한 코드, 데이터가 안에 담겨 있고 외부에서 액세스한다거나 각 비즈니스 서비스들이 독립적으로 상호작용할 수 있다.
- 이 서비스라는 것은 특정 플랫폼에 종속되는 개념이 아니다.
Service의 장점
- 90년대까지만 해도 SOA 개념이 없었기에 기업들은 타사의 애플리케이션과 소통하기 위해서 접속, 라우팅, 데이터 모델 변환 등 복잡한 P2P(point to point) 작업을 수행해야 했다. 이러한 방식이 monolithic 모델이다. 즉 1 애플리케이션 - 1 배포인 것이다. 한번 배포하면 끝.
- SOA은 요청 및 액세스를 하기 위해 SOAP, JSON, ActiveMQ, Apache Thrift와 같은 표준 네트워크 프로토콜을 사용하기에 서로 다른 서비스 및 애플리케이션간의 소통을 위한 프로토콜을 제로베이스에서 구축하지 않아도 된다. 적절한 프로토콜에 따르기만 하면된다.
- 이때 ESB(Enterprise Sevice Bus)라는 것이 쓰이는데 이것은 패턴으로 이 ESB 패턴은 중앙화된 구성요소(Component)와 백엔드 시스템을 통합하고 이를 서비스 인터페이스로 제공한다. 개발자는 이에 맞추서 기능을 구현해 사용하면 된다.
MSA와의 비교
- SOA는 2000년대 초반, MSA는 2010년대 후반에 유행한 디자인 아키택쳐이다.
- 2000년 당시에는 각광 받았지만 ESB가 트랜잭션 관리가 어려워 점차 사그라든 유행이라고 한다.
![[Pasted image 20220812001447.png]] 출처 : https://blog.naver.com/PostView.nhn?isHttpsRedirect=true&blogId=stmshra&logNo=221446919085&parentCategoryNo=&categoryNo=73&viewDate=&isShowPopularPosts=true&from=search 위 표를 확인해보면 SOA가 MSA와 비슷한 수준이 아닌 보다 넓은 상위 개념처럼 느껴진다. 하지만 서로간의 목적부터 차이를 보인다. SOA는 기존의 코드, 로직을 재사용하여 효율성을 추구한다는 것에 초점이 맞춰져 있다. 만든 애플리케이션을 빠르게 배포 및 적용하는데 초점을 둔다.
- 조직의 구조는 크게 영향이 없던 것과 달리 MSA는 서비스 & 조직을 구분하고 이들을 서로 이어주는 역할을 한다.
- SOA는 애플리케이션이라는 하나의 틀이 있고 그 안에서 활용되는 아키텍쳐로서 역할을 한다. 해당 디자인 패턴을 곧 애플리케이션의 패턴, 구조인 것이다.
- MSA는 이와 달리 서비스 간의 종속성이 느슨하고 서로 떨어져 있다. 각각의 기능과 상황에 맞추어 각자가 독립적인 아키텍처를 구성할 수 있다. 배포 또한 각 서비스가 따로따로 배포되는 것이 차이점이다.
- 서비스라는 개념을 정의하는 관점도 다르다. SOA는 재사용성에 초점을 두고 서비스를 나눈다. 하지만 MSA는 서비스들끼리 얼마나 이질적인지, 각 서비스의 기능과 역할이 얼마나 고유한지, 특징적인지에 초점을 맞추어 서비스를 정의한다. ![[Pasted image 20220812003014.png]]![[Pasted image 20220812002851.png]]
- 어떤 블로거분이 그림으로 정리해주신 것으로 명확하게 이해할 수 있는 예시이다. SOA는 일반적으로 첫번째 그림을 통해 애플리케이션을 구조화할 수 있는 방식처럼 보인다. 각 서비스들은 서로 고유한 기능을 수행하는데 환자관리 서비스가 필요한 서비스 조합들이 모여 환자관리 서비스가 연결되고 의사관리 서비스에 수반되는 서비스 조합들이 모여 의사관리가 작업이 이루어진다.
- 하지만 까놓고 보면 얼핏 MVC 패턴처럼 보이기도 해서 그냥 서비스 대신 컴포넌트라고 불러도 그리 이상하지 않다. SOA만의 특징이 잘 나타나지도 않고 SOA를 구현하려고 ESB를 학습할만큼의 복잡도나 어려움이 잘 안 느껴진다. ![[Pasted image 20220812002859.png]]
- 각 서비스들은 따로따로 배포되어 구분된다.
- 서비스 간의 통신
- SOA: SOAP, WS 표준같은 꽤 무거운 프로토콜을 활용해 ESB 패턴 기반의 스마트 파이프로 서비스간 소틍을 한다.
- MSA : REST, gRPC처럼 라이트한 프로토콜을 활용해 메시지 브로커 혹은 서비스 간 통신 중심의 덤파이프로 소통한다.
- 서로간에 사용하는 기술 스택 자체가 다르다.
- 데이터
- SOA: 전역 데이터 모델 및 공유 DB
- MSA: 서비스 개별 데이터 모델 및 DB
- 주요사례
- 대규모 모놀리식 어플리케이션 / 소규모 서비스
출처 https://azderica.github.io/01-architecture-soa/ https://blog.naver.com/PostView.nhn?isHttpsRedirect=true&blogId=stmshra&logNo=221446919085&parentCategoryNo=&categoryNo=73&viewDate=&isShowPopularPosts=true&from=search
댓글남기기