SOA(Service Oriented Architecture) & ESB & SOAP
Service Oriented Architecture, SOA는 서비스 지향 설계 방식으로, 서비스 단위로 개발을 하고, 각 서비스들의 기능을 공유함으로써 재가용성을 확보하는 아키텍처이다.
MSA랑 상당히 비슷하게 느껴지는데, 어떤 이는 SOA가 상위 개념이고, MSA는 SOA를 구현하는 하나의 아키텍처라고 하기도 하며, 어떤 이는 SOA가 재사용을 한다는 것과 통신 방식이 다른 것으로 해서 차이를 구분하기도 한다.
위 그림 보면 SOA와 MSA가 정말 잘 간단하게 정리되어 있다. 위 그림으로 바로 이해가 힘드므로, 다른 그림으로 한번 더 이해를 해보면,
위와 같다.
두 아키텍처의 차이점은
MSA는 클라이언트와 API gate way가 연결되어 있고, API gateway는 또 여러 마이크로 서비스들과 연결되어 있으며, 이 마이크로 서비스들 또한 REST API 등으로 연결되어 있으며, 데이터 포맷으로는 HTML, XML, JSON 등 다양한 포맷을 지원하고, Stateless 라는 특징을 가진다.
그에 반해 SOA는 각 서비스들이 가지고 있는 공통의 서비스, A가 있다고 하면 A 서비스는 ESB라는 공통 채널을 통해서 각 서비스들이 공유해서 사용함으로써 재가용성을 확보할 수 있는 아키텍처 이다. A의 서비스는 예는 아래와 같다.
*ESB(Enterprise Service Bus)는 중앙 집중식 소프트웨어 컴포넌트가 백엔드 시스템에 대한 통합(라우팅, XML 변환 포함) 을 수행하고, 재사용하기 위해 서비스 인터페이스로 사용할 수 있는 통합 및 변환을 수행하는 패턴이다.
그리고 서비스 간 통신은 SOAP이란 프로토콜을 사용하며 데이터 포맷은 XML만 지원하며, stateful 특징을 가진다.
ESB를 통해서 여러 서비스들을 조합(통합)하여 큰 하나의 시스템으로 관리 운영 할 수 있도록 지원한다.
*SOAP(Simple Object Access Protocl)은 다른 언어로 다른 플랫폼에서 빌드된 애플리케이션이 통신할 수 있도록 설계된 최초 프로토콜이다.(당연히 REST API 나오기 이전) 컴퓨터 네트워크 상에서 HTTP, SMTP등을 이용하여 XML을 교환하기 위한 통신 규약으로 HTTP 기반에서 동작하기 때문에 프록시와 방화벽의 영향 없이 통신이 가능하다. 하지만 REST API에 비해서 구조가 복작하여 다루기가 어렵고, 무겁다는 단점이 있다.
*Stateful : 한번 연결이 유지되면 서비스가 종료되기 전까지 끊지 않고 계속적으로 이어지는 방식
*Stateless : 한번 데이터를 전송할 때마다 연결하고 끊어버리는 방식
또한 MSA의 마이크로서비스들은 각 서비스마다 독립젹인 DB를 보유하고 있지만, SOA는 하나의 RDB를 사용한다.
(독립적인 DB를 보유하는 것이 무조건 장점은 아닐 것이다. 예를 들어 A와 B의 서비스가 회원정보를 사용한다고 할 때, A와 B 둘 다 회원정보를 가지는 방법(이 방법은 동기화 문제, 중복 문제로 안할테지만,여튼), A(혹은 B)가 회원정보를 가지고 있고, B(혹은 A)가 A(혹은 B)를 참조해서 하는 방법, 아님 회원정보를 담당하는 C라는 서비스가 있어 A와 B가 C를 참조하는 방법 등이 있을 것이다. 즉 MSA에서는 서비스간 통신이 필요하다. 모든 DB 정보에 바로 접근할 수가 없기 때문이다. 하지만 SOA 같은 형태에서는 DB의 모든 정보에 접근이 되기 때문에, 다른 서비스와 통신을 고려할 필요가 없다.)
또한 MSA는 여러 언어로 개발이 가능하지만, SOA는 하나의 언어로 개발해야된다.
MSA는 뉴스, 가젯 같이 UI 성격을 가지는, 작은 서비스 단위로 세분화 된 웹 기반 시스템에 적절하고, 크고 복잡한 비즈니스 어플리케이션환경에는 SOA가 적절하다.
(서비스가 세분화 될 수록 복잡도가 늘어날테고, 관리포인트가 늘어날 수 밖에 없기 때문에, 이미 한 시스템이 충분히 복잡하다면, 관리 포인트를 하나로 집중 시키고, 더 많은 세분화 지양하는 것이 좋을 것이다.)
이렇게 구분할 수 있지만, SOA의 경우 성공사례가 적고, 구현하기 쉬운것도 아니다. MSA라고 구현하기 쉬운 편은 아니지만, 성공사례는 SOA보다 많다. 그래도 비용이SOA 보다 많은 비용이 들 것이기 때문에, 각 상황에 알맞은 아키텍처를 이용해야된다.(공부하기 위해서 자료를 찾다보면 SOA는 ... 인것같고, MSA가 성공적으로 정착한 아키텍처로 보인다. 아님 알려주세요)
SOA를 구분해보면, Fundamental SOA라고 해서 기본적은 SOA, 기존의 하나의 시스템이 었던 것을 각각 서비스화 하고 동시에 하나의 시스템으로 만드는 통합하여 운영하는 기본 개념정도가 있는 아키텍처이다. (공부하면서 이해한 바로는 MSA도 Fundamental SOA에서 발전된 형태 중 하나)
기본 개념의 ESB라는 것이 추가된 아키텍처가 Networked SOA이다.
Fundamental SOA의 경우 서비스와 Front End가 필요에 따라 서로 각각 다 연결되어 있다면, 좀 더 효율적인 관리 및 통제를 위해 ESB를 둔 것이 Networked SOA이다. 이유는 모르겠지만, 이것을 SOA라고 많이 설명을 하고 있다.
그리고 기본 개념에서 BPA/BAM/BPM 개념을 포함하여 만들어진 아키텍처가 Process Oriented Soa이다. 언급이 잘 안되는 내용이라 정확히는 이해를 하지 못했으나, 간단한 설명을 보았을 때, CI CD를 포함한 개념으로 보인다. 이 아키텍처가 나중에 MSA가 되는거 아닌가 모르겠다. 어쨌든 프로세스들을 자동화 시킨다는 개념의 아키텍처있다. 이 아키텍처는 제대로 되진 못했는지 금방 CI CD 개념 DevOps로 넘어가서 그런지 자료가 별로 없다.
정리해보면 SOA의 하나의 구현 방법이 Networked SOA(ESB, SOAP 사용), 그리고 추후에 MSA(API Gateway, REST API 등을 사용)으로 발전했다 라고 봐도 되지 않을까 싶다.
적절한 비유 인지는 모르겠지만, MSA가 소비에트 사회주의 공화국 연방처럼, 사회주의라는 서비스를 수행하기 위해서 각 나라들이 연결되어 있는 것으로 비유할 수 있을 것 같다. 뭐 공산대회 같은 것들을 통해(API Gateway) 각 나라(서비스)들의 요청을 받기도 보내기도 한다. 그리고 각 나라(서비스)들의 언어(여러 개발 언어)나 문화(HTML, JSON, XML...)가 다를테지만, 마르크스 사상(REST API)으로 연결되어 있어 문제 없이 교류(통신)이 가능하고, 이런 마르크스 사상(REST API)으로 묶여있으므로 마르크스 사상으로 가득찼다고(RESTful)할 수 있다.
그럼 SOA는 미국으로 비유해볼 수 있을 것 같은데, 자유주의라는 서비스를 수행하기 위해서, 각 주가 각자의 할 일은 하지만, 각 주 모두 미국 연방 정부를 거쳐서 서비스를 수행한다. 미국 연방 정부의 서비스가 공통된, 재가용 되는 서비스라고 볼 수 있다. 주 마다(출신 계열마다) 다른 문화와 언어를 가질 수 있지만, 이민자들로 이루어진 하나의 미국이란 생각(SOAP)을 통해 미국인(서비스)들은 각자의 언어가 아닌 영어(하나의 개발언어)로만 대화(통신)하고 미국 문화(XML)라는 하나의 문화만 존재한다.
모놀리식은 북한으로 보면 되지 않을까 싶다. 아니면 원시 부족, 부족장 한명에 의해 컨트롤 되는 조직 정도로 보면 될 것 같다.