SOA vs 마이크로서비스: 차이점은 무엇인가요?

IT나 클라우드 컴퓨팅 분야에서 일한다면 서비스 지향 아키텍처(SOA)와 마이크로서비스에 대한 논쟁에 대해 잘 알고 있을 것입니다. 요즘 모두가 마이크로서비스와 민첩한 애플리케이션에 대해 이야기하고 있습니다.

언뜻 보기에 두 접근 방식은 비슷해 보이고, 어떤 면에서는 실제로 그렇습니다. 두 가지 모두 민첩한 애플리케이션 개발 및 배포를 위한 클라우드 또는 하이브리드 클라우드 환경을 포함하며, 빅데이터의 속도 및 운영 요구 사항을 충족하도록 확장할 수 있습니다. 두 방법 모두 크고 복잡한 애플리케이션을 작고 유연한 구성 요소로 나눕니다. 그리고 두 아키텍처 모두 각 서비스마다 고유한 책임이 있다는 점에서 기존의 일체형 아키텍처와 다릅니다.

그러나 이러한 주요 공통점에도 불구하고 두 접근 방식을 자세히 살펴보면 중요한 차이점이 드러납니다.

서비스 지향 아키텍처(SOA)는 재사용 가능한 소프트웨어 구성 요소 또는 서비스를 활용하는 애플리케이션 구성 요소의 소프트웨어 개발에 대한 전사적인 접근 방식입니다. SOA 소프트웨어 아키텍처에서 각 서비스는 고객의 신용 확인, 웹사이트 로그인 또는 모기지 신청 처리와 같은 특정 비즈니스 기능을 실행하는 데 필요한 코드 및 데이터 통합으로 구성됩니다.

서비스 인터페이스는 느슨한 결합을 제공하는데, 이는 통합이 어떻게 구현되는지에 대한 지식이 거의 없거나 전혀 없이 호출될 수 있음을 의미합니다. 이러한 느슨한 결합과 서비스 게시 방식 덕분에 개발팀은 회사 전체의 다른 애플리케이션에서 구성 요소를 재사용하여 시간을 절약할 수 있습니다. 이는 이점인 동시에 위험이기도 합니다. ESB(엔터프라이즈 서비스 버스)에 대한 공유 액세스로 인해 문제가 발생하면 연결된 다른 서비스에도 영향을 미칠 수 있습니다.

XML 데이터는 SOA 아키텍처 기반 솔루션의 핵심 요소입니다. 예를 들어, XML 기반 SOA 애플리케이션을 사용하여 웹 서비스를 구축할 수 있습니다.

SOA는 1990년대 후반에 등장했으며 애플리케이션 개발 및 통합의 발전에 있어서 중요한 단계를 나타냅니다. SOA가 등장하기 전에는 모놀리식 애플리케이션을 다른 시스템의 데이터나 기능에 연결하려면 복잡한 지점 간 통합이 필요했으며, 개발자는 새로운 개발 프로젝트마다 이를 다시 만들어야 했습니다. SOA를 통해 해당 기능을 공개하면 매번 심층적인 통합을 다시 만들 필요가 없습니다.

SOA는 4가지 유형의 서비스를 제공합니다.

1. 비즈니스 애플리케이션에 중요한 기능적 서비스(즉, 비즈니스 서비스).
2. 기능을 구현하는 역할을 하는 엔터프라이즈 서비스.
3. 앱 개발 및 배포에 사용되는 애플리케이션 서비스.
4. 보안 및 인증과 같은 백엔드 프로세스에 중요한 역할을 하는 인프라 서비스.

각 서비스는 세 가지 구성 요소로 이루어져 있습니다.

1. 서비스 공급자가 서비스 소비자의 요청을 실행하는 방법을 정의하는 인터페이스.
2. 서비스 제공자와 서비스 소비자가 상호 작용하는 방식을 정의하는 계약.
3. 서비스 코드인 구현.

SOA 서비스를 결합하여 더 높은 수준의 서비스 및 애플리케이션을 만들 수 있습니다.

SOA와 마찬가지로 마이크로서비스 아키텍처는 느슨하게 결합되고 재사용 가능한 전문화된 구성 요소로 구성되어 있으며, 종종 서로 독립적으로 작동합니다. 마이크로서비스는 또한 높은 수준의 응집성, 즉 경계 컨텍스트를 사용합니다. 제한된 컨텍스트는 종속성이 거의 없는 독립된 엔티티 또는 단위로서 구성 요소와 해당 데이터 간의 관계를 나타냅니다. 마이크로서비스는 기업 전체에 적용되기보다는 일반적으로 애플리케이션 프로그래밍 인터페이스(API)를 통해 통신하여 특정 비즈니스 기능을 수행하는 개별 애플리케이션을 구축합니다. 이러한 접근 방식은 특히 특정 사업 분야에 대한 민첩성, 확장 가능성 및 복원력을 높여줍니다. 일반적으로 Java는 마이크로서비스를 개발하는 데 사용되는 프로그래밍 언어입니다. Golang이나 Python 같은 다른 프로그래밍 언어도 사용할 수 있습니다.

마이크로서비스는 진정한 클라우드 네이티브 아키텍처 접근 방식으로, 종종 컨테이너에서 작동하므로 독립적인 서비스를 만들 수 있도록 확장 가능한 이식성이 뛰어납니다. 팀은 마이크로서비스를 사용하여 코드를 보다 쉽게 업데이트하고, 다양한 구성 요소에 대해 다양한 스택을 사용하고, 구성 요소를 서로 독립적으로 확장할 수 있습니다. 이 접근 방식은 단일 기능에 너무 많은 부하가 걸려 전체 애플리케이션을 확장해야 할 때 발생하는 낭비와 비용을 줄여줍니다. 마이크로서비스는 독립성이 뛰어나 다른 대안에 비해 내결함성이 높은 서비스를 제공합니다.

마이크로서비스 아키텍처에 대한 자세한 내용은 다음 동영상을 참조하세요.

두 접근 방식의 주요 차이점은 범위에 있습니다. 간단히 말해서, 서비스 지향 아키텍처(SOA)는 엔터프라이즈 범위를 갖는 반면, 마이크로서비스 아키텍처는 애플리케이션 범위를 갖습니다.

이러한 차이점을 무시하면 각 접근 방식의 핵심 원칙 중 상당수가 호환되지 않게 됩니다. 범위의 차이를 받아들인다면, 두 가지가 경쟁하기보다는 오히려 잠재적으로 서로를 보완할 수 있다는 걸 금방 깨닫게 될 겁니다.

이러한 구분이 적용되는 몇 가지 사용 사례는 다음과 같습니다.

SOA에서는 통합의 재사용성이 주요 목표이며, 기업 수준에서는 어느 정도 재사용성을 위해 노력하는 것이 필수적입니다. SOA 아키텍처의 재사용성 및 구성 요소 공유는 확장성과 효율성을 높입니다.

마이크로서비스 아키텍처에서 애플리케이션 전체에서 런타임에 재사용되는 마이크로서비스 구성 요소를 만들면 종속성이 발생하여 민첩성과 복원력이 저하됩니다. 마이크로서비스 구성 요소는 일반적으로 분리를 개선하기 위해 데이터 복제를 복사하고 수용하여 코드를 재사용하는 것을 선호합니다.

SOA의 재사용 가능한 서비스는 주로 RESTful API와 같은 동기식 프로토콜을 사용하여 기업 전체에서 사용할 수 있습니다.

그러나 마이크로서비스 애플리케이션 내에서 동기식 호출은 실시간 종속성을 유발하여 복원력을 떨어뜨립니다. 이러한 종속성으로 인해 지연이 발생할 수도 있으며, 이는 성능에 영향을 미칩니다. 마이크로서비스 애플리케이션 내에서는 게시/구독 모델을 사용하여 마이크로서비스 구성 요소가 다른 구성 요소의 데이터에 발생하는 변경 사항을 최신 상태로 유지할 수 있도록 하는 이벤트 소싱과 같이 비동기 통신을 기반으로 하는 상호 작용 패턴이 선호됩니다.

SOA에서 서비스를 제공하는 분명한 목표는 모든 애플리케이션이 기본 소스에서 직접 데이터를 동기적으로 가져오고 변경하여 복잡한 데이터 동기화 패턴을 유지할 필요성을 줄이는 것입니다.

마이크로서비스 애플리케이션에서 각 마이크로서비스는 다른 시스템에 데이터가 중복되는 경우에도 다른 마이크로서비스, 그리고 다른 애플리케이션으로부터의 독립성을 보장하는 데 필요한 모든 데이터에 대한 로컬 액세스 권한을 갖는 것이 이상적입니다. 물론 이러한 중복은 복잡성을 증가시키므로 민첩성과 성능 향상과 균형을 맞춰야 하지만 이는 마이크로서비스 설계의 현실로 받아들여지고 있습니다.

• 커뮤니케이션: 마이크로서비스 아키텍처에서 각 서비스는 자체 통신 프로토콜을 사용하여 독립적으로 개발됩니다. SOA를 사용하면 각 서비스가 엔터프라이즈 서비스 버스(ESB)라고 하는 공통 통신 메커니즘을 공유해야 합니다. SOA는 ESB를 통해 제공하는 서비스를 관리하고 조정합니다. 그러나 ESB는 전체 기업의 단일 장애 지점이 될 수 있으며, 단일 서비스 속도가 느려지면 전체 시스템에 영향을 미칠 수 있습니다.
• 상호 운용성: 마이크로서비스는 일을 단순하게 유지하기 위해 HTTP/REST(Representational State Transfers) 및 JMS(Java 메시징 서비스)와 같은 경량 메시징 프로토콜을 사용합니다. SOA는 SOAP(단순 개체 액세스 프로토콜), AMQP(고급 메시징 큐 프로토콜) 및 MSMQ(Microsoft 메시징 큐)와 같은 이기종 메시징 프로토콜에 대해 더 개방적입니다.
• 서비스 세분화: 마이크로서비스 아키텍처는 고도로 전문화된 서비스로 구성되며, 각 서비스는 한 가지 일을 매우 잘 수행하도록 설계되어 있습니다. 반면, SOA를 구성하는 서비스는 소규모의 전문 서비스부터 기업 전체에 걸친 서비스까지 다양합니다.
• 속도: 공통 아키텍처를 공유하는 장점을 활용하면 SOA는 개발과 문제 해결을 단순화합니다. 그러나 이러한 특성 때문에 SOA는 중복을 통해 공유를 최소화하는 마이크로서비스 아키텍처보다 느리게 동작하는 경향이 있습니다.
• 거버넌스: 공유 리소스를 포함하는 SOA의 특성으로 인해 모든 서비스에서 공통 데이터 거버넌스 표준을 구현할 수 있습니다. 마이크로서비스의 독립적인 특성으로 인해 일관된 데이터 거버넌스가 가능하지 않습니다. 이를 통해 각 서비스의 유연성이 향상되고, 조직 전체에서 더욱 활발한 협업이 촉진될 수 있습니다.
• 스토리지: 스토리지 리소스가 할당되는 방식도 SOA와 마이크로서비스가 다릅니다. SOA 아키텍처는 일반적으로 주어진 애플리케이션 내의 모든 서비스가 공유하는 단일 데이터 저장 계층을 포함하는 반면, 마이크로서비스는 필요한 모든 서비스에 대한 데이터 저장을 위해 전용 서버나 데이터베이스를 제공합니다.

일부 조직에서는 SOA 아키텍처가 모놀리스를 대체하는 디딤돌이 되어 더욱 유연하고 민첩한 환경을 제공합니다. SOA 서비스는 대규모 환경에서 개발되고 사용될 수 있지만, 자사 관할 범위 내에서 비즈니스 프로세스를 처리하고자 하는 개별 기업의 특정 요구 사항은 해결하지 못합니다. DevOps는 조직이 SOA 아키텍처에서 마이크로서비스로 전환하여 특정 요구 사항을 해결하는 데 도움이 될 수 있습니다.

각 아키텍처 스타일에는 장점이 있는데, 어떤 스타일이 목적에 가장 적합한지 어떻게 결정할 수 있을까요? 일반적으로 이는 애플리케이션 환경의 규모와 다양성에 따라 달라집니다.

SOA와 마이크로서비스는 모두 자동화를 사용하여 비즈니스 프로세스를 가속화할 수 있습니다. 규모가 더 크고 다양한 환경일수록 서비스 지향 아키텍처(SOA)를 선호하는 경향이 있는데, 이는 엔터프라이즈 서비스 버스(ESB)를 통해 이기종 애플리케이션과 메시징 프로토콜 간의 통합을 지원합니다. 웹 및 모바일 애플리케이션을 포함한 소규모 환경에서는 이러한 강력한 통신 계층이 필요하지 않으며 마이크로서비스 아키텍처를 사용하여 개발이 더 쉽습니다.

SOA와 마이크로서비스 논쟁은 훨씬 더 복잡하다고 말하는 사람들이 있고, 이는 사실입니다. 여기에는 훨씬 더 많은 내용이 있습니다. 이러한 세부적인 차이에 대한 보다 기술적인 설명은 SOA와 마이크로서비스 관련 학습 허브 문서를 참고하는 것을 권장합니다. 이 문서들은 매우 심층적인 정보를 제공합니다. 그러나 비즈니스 관점에서 범위가 핵심적인 차이점입니다.

• 마이크로 서비스란 무엇인가요?
• SOA(서비스 지향 아키텍처)란 무엇인가요?
• 애자일 vs 워터폴

민첩한 애플리케이션을 구축하는 방법에 대해 자세히 알아보려면 민첩한 애플리케이션 아키텍처 전자책을 무료로 다운로드하세요.