Intro

이번 주제는 SOA, Service Oriented Architecture에 대해 포스팅 해 보도록 하겠다.

Service Oriented Architecture

서비스 지향 구조라는 의미다.
업무상에 일 처리에 해당하는 부분들을 하나의 서비스로 판단해서 네트워크에 연동하여 시스템 전체를 구축 해 나가는 방법론이다.

조금 더 쉽게 얘기 해 보자면, 기존의 시스템들은 각각 독립적인 업무 시스템이라고 할 수 있다.

하지만 SOA는 특정한 기능을 하는 단위인 서비스들을 배열하여 하나의 업무를 구성한다고 할 수 있다.
더 간단히 얘기해보면 기존에 제공 되어있는 서비스들을 조합하여 하나의 시스템을 구축한다고 할 수 있다.

MSA VS SOA

MSA와 차이점이 존재하는가? 라는 의문이 들 수 있다. MSA와 SOA의 기본 철학은 비슷하다.
MSA 또한 작은 서비스들을 조합하여 하나의 시스템을 구축한다. 하지만 MSA가 조금 더 작은 단위의 아키텍쳐 형태를 지닌다.

예를 하나 들어보자면, SOA 구조에서는 여러가지의 서비스가 하나의 DB를 공유하는 상황이 생길 수 있다.
하지만 MSA라면, 그 서비스들 각각이 개별적인 DB를 가지고 있을 것이다. 그 정도로 MSA가 더 작은 단위로 아키텍쳐를 구성한다는 의미다. SOA는 모듈 내에서 공유할 수 있는 건 최대한 공유하는 특성을 가진다 . 이 특성이 바로 이 예시라고 할 수 있다.

또한 SOA는 서비스의 Flow를 유지하려고 한다, 하지만 MSA는 서비스의 Flow를 구별한다.
SOA는 특정한 서비스에 대한 루틴을 관련 된 서비스들이 수행한다면, MSA는 모든 루틴이 구별 되어있다.

결제를 한다고 하면, SOA라면 하나의 루틴이 진행된다면, MSA는 사용자가 결제창에서 결제 방법을 구하거나 장바구니를 수정하는 루틴, 실제 결제 루틴이 모두 분리되어 있다는 의미다.

MSA는 애플리케이션 구축에 좀 더 유리하다고 할 수 있다. 각 MSA 서비스 끼리 Stateless 한 API를 통해 통신한다면 SOA는 ESB를 통해 구성요소가 통신한다. 즉 MSA가 SOA에 비해 좀 더 유연성이 높고 내결함성이 우수하다고 할 수 있다.

SOA의 장점

우선 모놀리식에 비해 상당히 유연한 장점들을 지닌다.
먼저 출시 일정을 단축할 수 있고 레거시 인프라의 사용이 수월해진다. 유지보수 또한 용이하고 확장성, 안정성에 이점을 가질 수 있다.

Outro

Monolithic, SOA, MSA 세 가지 아키텍쳐에 대해 알아보았다.
다음 포스팅의 주제는 Serverless로 돌아오도록 하겠다.

Reference

https://www.redhat.com/ko/topics/cloud-native-apps/what-is-service-oriented-architecture