ESB의 운명 SOA 시대의 기원부터 더 나은 접근 방식을 찾는 데 영감을 준 과제까지

이 두 부분으로 구성된 시리즈에서는 최신 통합 아키텍처가 상호 연결되는 애플리케이션만큼 민첩성을 확보하기 위해 어떤 접근 방식을 취하고 있는지 살펴봅니다. 중앙 집중식 엔터프라이즈 서비스 버스(ESB) 패턴은 그 목적을 달성했고 여전히 자리를 지키고 있지만, 많은 기업이 통합 아키텍처에 대한 컨테이너화 및 분산화 접근 방식을 모색하고 있습니다.

1부에서는 ESB의 운명을 살펴봅니다. 서비스 지향 아키텍처(SOA) 시대에 중앙 집중형 ESB 패턴이 어떻게 그리고 왜 생겨났는지 간략하게 살펴보고, 그로 인해 발생한 과제도 살펴보겠습니다. 또한 API가 이러한 그림에서 어떤 역할을 하는지, 그리고 이 모든 것과 마이크로서비스 아키텍처 사이에는 어떤 관계가 있는지도 살펴보겠습니다. 이러한 역사를 명확하게 이해하지 못하면 앞으로 어떻게 더 나은 서비스를 제공할 수 있을지에 대해 확신을 가지고 이야기할 수 없습니다.

SOA는 엔터프라이즈급 범위를 가지며 애플리케이션 간 통합이 어떻게 이루어지는지 살펴봅니다. 마이크로서비스 아키텍처는 애플리케이션급 범위를 가지며 애플리케이션의 내부 구조가 어떻게 구축되는지 다룹니다 .

2부에서는 더욱 가볍고 민첩한 통합 스타일을 소개하고, 마이크로서비스의 기반 기술과 원칙을 활용하여 새로운 애플리케이션이 현대 혁신의 속도와 규모에 맞춰 필요한 통합을 수행할 수 있도록 통합 아키텍처가 어떻게 활용할 수 있는지 살펴봅니다. 또한, 각 사업부의 자율성과 생산성을 높이기 위해 통합을 더욱 근본적으로 분산화하는 방법도 살펴보겠습니다.

먼저 중앙 집중형 ESB가 어떤 모습인지, 그리고 어디에서 유래했는지 명확하게 살펴보겠습니다.

ESB 패턴을 이전 패턴과 차별화

ESB라는 용어는 일반적으로 통합 런타임을 설명하는 데 매우 느슨하게 사용되지만 이는 역사적, 구조적 측면에서 매우 부정확합니다.

2000년 직전의 어느 시점을 되돌아보면, 통합은 거의 전적으로 비동기식으로 진행되었으며, 파일과 메시지를 사용하여 기록 시스템 간 통합을 이루었습니다. 각 지점 간 통합을 위해 각 시스템 내부 또는 주변에 코드를 작성하는 데는 많은 비용이 들었고, 그 결과 복잡한 상호작용이 얽히고설켜 있었습니다.

그림 1. 지점 간 패턴과 허브 앤 스포크 패턴

그 결과, 모든 시스템 사이에 통합 허브를 도입하고, 연결을 훨씬 더 간단하게 만드는 도구를 제공하며, 수행된 통합 작업을 어느 정도 재사용할 수 있게 되었습니다.

이 주로 비동기식 허브 앤 스포크 아키텍처가 ESB 패턴보다 상당히 앞선다는 점에 유의하는 것이 매우 중요합니다. 아직 공개된 서비스는 없습니다. 허브 앤 스포크의 이벤트 기반 상호작용 패턴은 오늘날에도 여전히 매우 일반적이며, 나중에 살펴보겠지만 최신 애플리케이션에서 이벤트를 통해 데이터를 수신하는 것을 선호하는 경향이 커지면서 다시 인기를 얻고 있는 것 같습니다. 따라서 허브 앤 스포크 패턴은 ESB 패턴과 동일하지 않지만, 동일한 통합 런타임을 사용하여 구현될 수 있습니다.

ESB 패턴의 형성

새천년이 시작되면서, 우리는 인터페이스를 위한 최초의 진정한 크로스 플랫폼 프로토콜의 시작을 목격했습니다. 인터넷과 HTTP는 보편화되었고, XML은 HTML의 힘으로 서서히 자리를 잡아가고 있었으며, 동기식 웹 서비스 인터페이스를 제공하는 SOAP 프로토콜은 이제 막 형태를 갖춰가고 있었습니다. 이러한 표준의 비교적 폭넓은 수용은 과거처럼 방대한 통합 코드 없이도 모든 시스템이 실시간 동기식 원격 프로시저 호출을 통해 다른 시스템을 발견하고 통신할 수 있는 더 밝은 미래를 예고했습니다.

이러한 일련의 사건들을 통해 서비스 지향 아키텍처(SOA)가 탄생했습니다. SOA의 핵심 목적은 웹 서비스와 같이 잘 구성되고 사용하기 쉬운 동기식 인터페이스를 통해 기록 시스템에 묻혀 있는 데이터와 기능을 노출하는 것이었습니다. SOA는 단순히 서비스를 노출하는 데 그치지 않고, 백엔드 시스템을 비즈니스 요구에 맞게 조정하기 위해 상당한 리엔지니어링 작업을 수반하기도 했습니다. 하지만 최종 목표는 재사용 가능한 서비스 모음을 구축하는 것이었습니다. 이를 통해 매번 심층적인 통합의 부담 없이 새로운 애플리케이션을 구현할 수 있었습니다. 통합이 처음 완료되어 서비스로 노출되면 다음 애플리케이션에서 재사용할 수 있었기 때문입니다.

하지만 이 간단한 통합은 일방적인 방정식이었습니다. 노출 프로토콜과 데이터 형식을 표준화할 수는 있었겠지만, 백엔드 기록 시스템은 일반적으로 오래되었고 현재 인터페이스에 맞는 프로토콜과 데이터 형식이 구식이었습니다. 기존 시스템과 새로운 크로스 플랫폼 프로토콜 사이를 중재할 무언가가 필요했습니다.

그림 2. 동기 노출 패턴

웹 서비스를 통한 이러한 동기식 노출 패턴이 바로 엔터프라이즈 서비스 버스(ESB)라는 용어의 시초가 되었습니다. 이름에서 알 수 있듯이, "엔터프라이즈" 전반에 걸쳐 웹 "서비스"를 노출할 수 있는 중앙 집중식 "버스"입니다. 허브 앤 스포크 패턴에서 유래한 백엔드 시스템에 연결하는 기술(통합 런타임)은 이미 구축되어 있었습니다. 이러한 통합 런타임은 SOAP/HTTP를 통해 동기식으로 통합을 노출하도록 간단히 학습시킬 수 있었고, 그렇게 ESB가 완성되었습니다.

ESB라는 용어를 둘러싼 일반적인 혼란은 이 단계에서 패턴을 구현하는 구성 요소가 통합 런타임(Integration Runtime) 하나뿐이었다는 사실에서 비롯됩니다. 따라서 이 통합 런타임을 단순히 ESB라고 부르는 경우가 많았습니다. 통합 런타임은 실제로 두 가지 개별 패턴(허브 앤 스포크 패턴과 서비스 노출 패턴)을 수행했지만, 아키텍처 다이어그램에서는 이 두 패턴이 매우 유사하여 하나로 통합되었습니다. 그 이후로 ESB라는 용어는 어떤 패턴을 수행하든 통합 런타임 자체를 지칭하는 데 무분별하게 사용되었습니다.

중앙 집중식 ESB 패턴에 문제가 생긴 이유는 무엇입니까?

SOA는 여러 가지 이유로 ESB 구현보다 조금 더 복잡한 것으로 드러났습니다. 그중 가장 중요한 것은 누가 그러한 전사적 프로그램에 자금을 지원할 것인가 하는 문제였습니다. ESB 패턴 자체를 구현하는 것 또한 결코 쉬운 일이 아니었습니다.

ESB 패턴은 종종 ESB의 "E"를 문자 그대로 받아들여 전체 기업 또는 기업의 각 중요 부분에 대해 최소한 하나씩 단일 ESB 인프라를 구현했습니다. 수십 또는 수백 개의 통합이 프로덕션 서버 클러스터에 설치되었을 수 있으며, 이를 확장하면 해당 클러스터 내의 모든 복제본에 존재하게 됩니다. 이러한 강력한 중앙 집중화는 ESB 패턴 자체에는 필요하지 않지만 결과 토폴로지에는 거의 항상 존재합니다. 적어도 처음에는 그럴 만한 이유가 있었습니다. 하드웨어와 소프트웨어 비용이 공유되었고, 서버 프로비저닝은 한 번만 수행하면 되었으며, 소프트웨어의 상대적 복잡성으로 인해 개발 작업을 수행하기 위해 숙련된 통합 전문가로 구성된 전담 팀이 하나만 필요했습니다.

중앙 집중식 ESB 패턴은 한 프로젝트에서 다음 프로젝트로 인터페이스를 재사용할 수 있다면(SOA의 핵심 이점 제안), 통합 비용을 상당히 절감할 수 있는 잠재력을 가지고 있었습니다. 그러나 이러한 기업 간 이니셔티브를 조율하고 지속적인 자금 지원을 확보하는 것, 그리고 그 자금이 개발 비용을 충당할 만큼 충분히 재사용 가능한 서비스에만 적용되도록 하는 것은 매우 어려운 것으로 드러났습니다. ESB 패턴이 구현되는 동시에 표준과 툴링이 성숙해지고 있었기 때문에, 단일 서비스를 공개하는 데 드는 구현 비용과 시간이 비현실적으로 높았습니다.

새로운 애플리케이션에서 혁신 속도가 더 빨라지기를 기대했던 사업부 팀은 SOA와 확장된 ESB 패턴에 점점 더 좌절감을 느끼게 되었습니다.

중앙 집중식 ESB 패턴의 몇 가지 과제는 다음과 같습니다.

• 인터페이스에 변경 사항을 배포하면 관련 없는 다른 인터페이스가 불안정해질 가능성이 있으므로, 광범위한 인터페이스에 대한 복잡한 회귀 테스트가 필요한 경우가 많았습니다.
• 런타임은 포함된 통합의 수로 인해 상당한 크기를 가지고 있었기 때문에 시작 및 중지가 매우 바람직하지 않았습니다. 가능한 한 실행 상태를 유지하고 실시간으로 패치해야 했습니다. 이로 인해 서버 구성을 추적하기 어려웠고, 테스트 및 진단을 위한 환경 복제도 어려웠으며, 변경 사항 추가에 대한 저항이 매우 컸습니다.
• 이러한 대규모 서버에 고가용성 및 재해 복구 기능을 갖춘 토폴로지를 구축하는 데는 많은 비용이 들었습니다. 확장에는 사전 계획이 필요했고, 추가 서버 구축에는 많은 비용이 들었습니다.
• 새 버전에 도입된 최신 미들웨어 수정 사항과 기능을 적용하는 것은 기존 통합 기능에 영향을 미칠 수 있어 위험했습니다. 따라서 서버는 일반적으로 여러 버전 이전 버전을 실행했습니다. 따라서 통합 개발자는 새 버전에서 이미 사용 가능한 기능에 대한 해결책을 개발해야 했습니다.
• 통합 전문가 팀은 통합 툴을 알고 있었지만, 공개하려는 애플리케이션을 이해하지 못하는 경우가 많았으며, 이로 인해 구현 주기에 리드 타임이 더 길어졌습니다.
• 통합은 여전히 ​​복잡한 분야였습니다. 좋은 인터페이스를 제공하는 시스템이 드물었기 때문에 심도 있는 기술이 필요했습니다. 소수의 통합 전문가만이 통합을 생성, 유지 관리 및 관리할 수 있었습니다. 이러한 전문 인력을 모으기 위해, 그들은 종종 별도의 "SOA" 팀을 구성하여 폭포수형 방식으로 작업을 수신하는 엄격한 절차를 적용했으며, 모든 애플리케이션 개발 프로젝트에 별도의 종속성을 도입했습니다.
• 당시에는 서비스 검색 기능이 미숙했습니다. 런타임 구성 요소와 서비스 레지스트리를 통합하는 옵션이 거의 없었습니다. 이로 인해 두 가지 결과 중 하나가 발생했습니다. 문서가 별도로 저장되어 빠르게 구식이 되거나, 문서가 전혀 저장되지 않아 재사용 시마다 사람 간의 상호 작용이 필요하게 되어 재사용에 따른 출시 시간 단축이라는 약속이 무산되었습니다.

결과적으로, 이 전문 SOA 팀이 서비스를 구축하는 것은 본래 의도했던 지원 수단이 아니라 프로젝트의 병목 현상으로 이어졌습니다. 이로 인해 중앙 집중식 ESB 패턴은 부정적인 평판을 받게 되었습니다.

공식적으로 ESB는 서비스 노출을 의미하는 아키텍처 패턴입니다. 그러나 앞서 언급했듯이, 이 용어는 종종 지나치게 단순화되어 패턴을 구현하는 데 사용되는 통합 엔진을 지칭하는 데 사용됩니다. 이는 정적이고 노후화된 중앙 집중식 ESB 패턴을 그 사이에 급격하게 변화한 통합 엔진과 연결하는 오류를 범합니다.

오늘날의 통합 엔진은 훨씬 더 가볍고, 설치 및 사용이 간편하며, ESB 패턴이 탄생했을 당시에는 상상할 수 없었던 방식으로 배포될 수 있습니다. 이러한 최신 런타임이 어떻게 더욱 가볍고 분산화된 완전히 다른 아키텍처 패턴을 지원하는지 살펴보겠습니다.

ESB 패턴을 공식 노출 게이트웨이로 보완

요청/응답 기반 서비스 노출은 ESB 패턴과 그 이전의 이벤트 중심 허브 앤 스포크 패턴을 구분하는 핵심적인 요소입니다. SOAP 스타일의 RPC 인터페이스는 이해하고 사용하기가 복잡했고, JSON/HTTP를 사용하여 더 간단하고 일관된 RESTful 서비스를 노출하는 것이 널리 사용되는 노출 메커니즘이 되었습니다. 하지만 최종 목표는 동일했습니다. 표준화된 인터페이스를 통해 함수와 데이터를 제공하여 새로운 애플리케이션을 더욱 빠르게 구축할 수 있도록 하는 것이었습니다.

기업 내외부에서 이러한 서비스 인터페이스의 사용이 확대됨에 따라, 더욱 공식적인 노출 메커니즘이 필요했습니다. 단순히 웹 서비스 인터페이스나 최근에는 RESTful JSON/HTTP API를 통해 서비스를 제공하는 것만으로는 충분하지 않다는 것이 곧 명확해졌습니다. 해당 서비스는 잠재 고객이 쉽게 찾을 수 있어야 했고, 사용자는 서비스에 접근하고 사용법을 익히는 데 있어 최소한의 저항만 가하면 되는 경로가 필요했습니다. 또한, 서비스 또는 API 제공자는 트래픽 제어 및 적절한 보안 모델과 같은 사용 제어 기능을 구현할 수 있어야 했습니다.

그림 3. 별도의 서비스 노출 게이트웨이를 사용하여 ESB 패턴 향상

이러한 기능 중 일부는 통합 런타임에 도입될 수 있었지만, 중앙 집중식 ESB 패턴의 무겁고 복잡한 특성으로 인해 이미 과부하 상태인 ESB 팀에 더 많은 책임이 추가되는 것을 의미했습니다. 일반적인 대안은 서비스/API 노출 역할을 별도의 게이트웨이로 분리하는 것이었습니다.

이러한 노출 기능은 현재 API 관리로 알려진 기능으로 발전하여 서비스/API 노출을 간편하게 관리할 수 있게 되었습니다. 게이트웨이는 트래픽 관리(속도/처리량 제한), 암호화/복호화, 정보 삭제, 보안 패턴 등 API 관리 관련 기능에 집중하도록 특화될 수도 있습니다. 또한, 게이트웨이는 사용 가능한 API를 설명하고 API 사용을 위한 셀프 구독을 활성화하며, API 사용자와 제공자 모두에게 분석 기능을 제공하는 포털로 보완될 수 있습니다.

점점 더 현대적인 기록 시스템은 노출 게이트웨이를 사용하여 제어된 노출만 필요한 HTTP 기반 인터페이스를 이미 제공하고 있었습니다. 통합 런타임은 보다 특이한 프로토콜, 데이터 형식, 여러 요청의 구성과 같이 더 복잡한 통합이 수행되거나 트랜잭션 기능이 필요한 경우에만 필요했습니다.

API 관리 계층의 도입은 당연한 질문으로 이어졌습니다. ESB는 이제 무엇일까요? 많은 사람들이 통합 런타임과 ESB 패턴을 하나로 간주해 왔습니다. 하지만 실제로 ESB 패턴이 서비스와 API를 노출하는 것에 관한 것이라면, 이 패턴의 경계는 통합 런타임과 노출 게이트웨이를 모두 포함하며, 경우에 따라서는 게이트웨이만 포함하기도 합니다. 그러나 ESB와 통합 런타임의 연관성이 잘못되었기 때문에, ESB라는 용어는 일반적으로 이렇게 사용되지 않는다는 점을 받아들여야 합니다.

기업 경계 밖으로 확산된 API

API를 효과적으로 노출하는 메커니즘이 성숙해지자 기업 외부에도 노출될 수 있다는 점이 분명해졌습니다. 처음에는 모바일 애플리케이션과 단일 페이지 웹 애플리케이션에서 여전히 널리 사용되는 백엔드-프런트엔드(BFF) 패턴을 만들기 위한 것이었습니다. 이 패턴에서 API는 프런트엔드 애플리케이션 전용으로 개발되었으며, 합리적인 데이터 모델, 이상적인 운영 세분화, 특화된 보안 모델 등을 통해 프런트엔드 애플리케이션의 요구 사항에 완벽하게 부합했습니다. 곧 API를 더 광범위하게 노출하여 모든 파트너가 애플리케이션을 개발할 수 있다는 점이 분명해졌고, 이는 완전히 새로운 협업 기회를 열어주었습니다.

그림 4. 외부 서비스/API 게이트웨이와 API 경제의 시작

기업마다 다르기 때문에 정확한 역사적 순서를 파악하기는 어렵습니다. 일부 기업의 API 관리 개념은 외부 노출로 시작되어 나중에 ESB 패턴을 보완하기 위해 내부로 도입되었습니다. 어떤 순서로든 외부 API는 많은 기업의 온라인 페르소나에 필수적인 요소가 되었으며, 최소한 웹사이트와 모바일 애플리케이션만큼 중요합니다.

논리적으로 기업 외부에 API를 노출하는 것은 ESB 패턴의 확장일 뿐이며, 게이트웨이와 보안, 검색, 자체 관리와 같은 측면에 더 중점을 둡니다. 예를 들어, 지리적 및 네트워크 관점에서 볼 때 어디에나 존재할 수 있는 소비자와 기기에서 API를 사용하고 있다는 것은 명백합니다. 따라서 가용 대역폭과 소비자로 사용되는 기기의 성능을 고려하여 API를 다르게 설계해야 합니다. 하지만 이러한 차이점에는 기술적이지 않은 측면도 있습니다. 노출된 API의 비즈니스 목표 차이를 과소평가해서는 안 됩니다. 외부 API 노출은 SOA에서 내부 서비스가 그랬던 것처럼 재사용에 훨씬 덜 중점을 두고, 새로운 비즈니스를 위한 특정 틈새 시장을 타겟으로 하는 서비스 개발에 더 중점을 둡니다. API는 기업이 협력할 수 있는 혁신 파트너의 수를 획기적으로 늘릴 수 있는 기회를 제공하며(새로운 아이디어의 크라우드 소싱을 가능하게 함), 오늘날 흔히 볼 수 있는 산업 혁신에서 중요한 역할을 합니다. 이러한 인식으로 인해 현재 API 경제라고 불리는 것이 탄생했으며, 이는 그 자체로 널리 다루어지는 주제 입니다 .

여기서 중요한 점은 이러한 발전이 비즈니스에 필수적인 모든 핵심 거래를 수행하는 기존의 기록 시스템 과, 외부 소비자와의 새로운 상호작용 방식을 모색하며 혁신이 빠르게 진행되는 참여 시스템 간의 이미 심화되고 있던 격차를 더욱 심화시켰다는 것입니다. 이로 인해 바이모달 IT가 등장했습니다 . 분산되고 빠르게 변화하는 새로운 IT 영역은 개발에 훨씬 더 민첩해야 했고, 마이크로서비스 아키텍처 등을 활용한 새로운 애플리케이션 구축 방식이 등장하게 되었습니다.

마이크로서비스의 증가

앞서 고도로 중앙화된 통합 런타임의 문제점들을 다루었습니다. 다른 통합에 영향을 주지 않고 안전하고 빠르게 변경하기 어렵고, 비용이 많이 들고 확장이 복잡하다는 점 등이 그 예입니다. 익숙하게 들리시나요? 그럴 것입니다. 이는 당시 애플리케이션 개발 팀이 직면했던 과제와 정확히 동일했습니다. 즉, 너무 많은 상호 연결 및 상호 종속 코드를 포함하는 비대하고 복잡한 애플리케이션 서버는 복제나 확장이 어려운 취약하고 번거로운 토폴로지에 존재합니다. 궁극적으로 이러한 공통 패러다임이 마이크로서비스 아키텍처의 원칙을 탄생시켰습니다. IBM WAS Liberty와 같은 경량 애플리케이션 서버(몇 초 만에 시작되고 설치 공간이 매우 작음)가 등장하면서, 더 작은 가상 머신에서, 그리고 결국 Docker와 같은 컨테이너 기술 내에서 실행하는 것이 더 쉬워졌습니다.

IT 부서의 민첩성과 확장성 향상에 대한 끊임없는 요구를 충족하기 위해 애플리케이션 개발의 다음 논리적 단계는 애플리케이션을 더 작은 조각으로 나누어 서로 완전히 독립적으로 실행하는 것이었습니다. 결국 이러한 조각들이 작아지면서 마이크로서비스라는 이름이 붙게 되었습니다. 마이크로 서비스라는 용어는 종종 혼란을 야기하기 때문에 (특히 통합 분야에서는 더 그렇지만, "마이크로서비스"라는 용어가 이제 널리 사용되고 있기 때문에) 마이크로서비스 컴포넌트라는 이름이 더 적절할 것입니다 .

마이크로서비스 개념을 자세히 살펴보면 단순히 여러 작은 단위로 나누는 것보다 훨씬 더 광범위한 의도를 가지고 있음을 알 수 있습니다. 아키텍처, 프로세스, 조직 등에 미치는 영향이 있으며, 이 모든 것은 조직이 클라우드 네이티브 기술 발전을 더욱 효과적으로 활용하여 혁신 속도를 높일 수 있도록 지원하는 데 중점을 두고 있습니다.

그러나 핵심적인 기술적 차이점에 다시 초점을 맞추면, 이러한 작은 독립적인 마이크로서비스 구성 요소는 더 큰 민첩성을 만들기 위해 독립적으로 변경되고, 클라우드 기반 인프라를 더 잘 활용하기 위해 독립적으로 확장되고, 24시간 온라인 애플리케이션에 필요한 복원력을 제공하기 위해 더 무자비하게 관리될 수 있습니다(제 기사 " 소는 애완동물이 아니다 " 참조).

그림 5. 마이크로서비스 아키텍처: 애플리케이션을 구축하는 새로운 방법

이론상으로 이러한 원칙은 어디에나 적용될 수 있습니다. 가장 흔히 볼 수 있는 곳은 시스템 참여 계층으로, 민첩성이 더욱 중요하기 때문입니다. 하지만 기록 시스템(SOR)의 민첩성, 확장성, 복원력을 향상시키는 데에도 사용될 수 있으며, 곧 살펴보겠지만 아키텍처의 다른 어느 곳에서도 사용될 수 있습니다.

의심할 여지 없이 마이크로서비스 원칙은 적절한 상황에서 상당한 이점을 제공할 수 있습니다. 하지만 이러한 기법을 사용하기에 적절한 시기를 선택하는 것은 매우 중요하며, 고도로 분산된 구성 요소를 올바르게 설계하는 것은 결코 간단한 문제가 아닙니다. 마틴 파울러의 의견 만 읽어봐 도 딜레마가 어떻게 전개되는지 알 수 있습니다. 결국 마이크로서비스 구성 요소의 형태와 크기를 결정하는 것은 전체 과정의 일부일 뿐입니다. 구성 요소를 분리하는 정도를 고려한 설계 선택 또한 매우 중요하며, 실질적인 현실과 마이크로서비스 관련 이점에 대한 열망 사이에서 끊임없이 균형을 맞춰야 합니다. 분리는 마이크로서비스의 기본이지만, 완전한 분리가 항상 좋은 마이크로서비스 설계라는 의미는 아닙니다. 좋은 설계는 항상 타협의 산물입니다. 간단히 말해, 마이크로서비스 기반 애플리케이션의 민첩성과 확장성은 설계의 완성도와 방법론의 성숙도에 따라 결정됩니다.

SOA와 마이크로서비스 아키텍처 비교

마이크로서비스 아키텍처를 SOA와 비교하고 싶은 유혹이 있습니다. 두 아키텍처가 많은 공통어를 공유하기 때문입니다. 하지만 곧 알게 되시겠지만, 이 비교는 오해의 소지가 있습니다. 두 용어는 매우 다른 두 영역에 적용되기 때문입니다.

그림 6. SOA는 엔터프라이즈 범위이고 마이크로서비스 아키텍처는 애플리케이션 범위입니다.

서비스 지향 아키텍처는 다른 시스템의 데이터를 통합하여 새로운 애플리케이션을 보다 빠르게 만들 수 있도록 재사용 가능하고 동기적으로 사용 가능한 서비스와 API를 만드는 기업 전체의 이니셔티브입니다.

반면, 마이크로서비스 아키텍처는 개별 애플리케이션 을 보다 민첩하고 확장 가능하며 복원력 있게 작성할 수 있는 옵션입니다.

각 접근 방식의 핵심 원칙 중 일부는 동일한 범위에 적용될 경우 완전히 양립할 수 없으므로, 이러한 범위의 차이를 인식하는 것이 중요합니다. 예를 들면 다음과 같습니다.

• 재사용: SOA에서는 통합의 재사용이 주요 목표이며, 기업 차원에서는 어느 정도 재사용을 위한 노력이 필수적입니다. 마이크로서비스 아키텍처에서 애플리케이션 전체에서 런타임에 재사용되는 마이크로서비스 구성 요소를 만들면 민첩성과 복원력이 저하되는 종속성이 발생합니다. 마이크로서비스 구성 요소는 일반적으로 코드를 복사하여 재사용하는 것을 선호하며, 곧 살펴보겠지만 구성 요소 간의 분리를 개선하기 위해 데이터 중복을 허용합니다.
• 동기식 호출: SOA의 재사용 가능한 서비스는 RESTful API와 같은 동기식 프로토콜을 주로 사용하여 기업 전반에 걸쳐 제공됩니다. 그러나 마이크로서비스 애플리케이션 내에서 동기식 호출은 실시간 종속성을 유발하여 복원력 저하와 지연 시간을 초래하여 성능에 영향을 미칩니다. 마이크로서비스 애플리케이션 내에서는 이벤트 소싱과 같은 비동기 통신 기반 상호작용 패턴이 선호됩니다. 이벤트 소싱에서는 게시-구독 모델을 사용하여 마이크로서비스 구성 요소가 다른 구성 요소의 데이터 변경 사항을 최신 상태로 유지할 수 있습니다.
• 데이터 중복: SOA에서 서비스를 노출하는 명확한 목표는 모든 애플리케이션이 주 소스에서 직접 데이터를 가져오고 변경할 수 있도록 하는 것입니다. 이를 통해 복잡한 데이터 동기화 패턴을 유지할 필요성이 줄어듭니다. 마이크로서비스 애플리케이션에서 각 마이크로서비스는 다른 마이크로서비스는 물론 다른 애플리케이션과의 독립성을 보장하기 위해 필요한 모든 데이터에 로컬로 접근할 수 있어야 합니다. 이는 다른 시스템에 데이터가 중복되는 것을 의미하더라도 마찬가지입니다. 물론 이러한 중복은 복잡성을 증가시키므로 민첩성과 성능 향상과 균형을 맞춰야 하지만, 이는 마이크로서비스 설계의 현실로 받아들여지고 있습니다. 마이크로서비스에서 데이터 중복이 매우 흔하기 때문에 각 데이터 유형에 대해 합의된 진실의 소스를 확보할 필요가 여전히 있습니다.

요약하자면, SOA는 엔터프라이즈급 범위를 가지며 애플리케이션 간 통합이 어떻게 이루어지는지 살펴봅니다. 마이크로서비스 아키텍처는 애플리케이션 급 범위를 가지며 애플리케이션의 내부 구조가 어떻게 구축되는지 다룹니다. 이는 훨씬 더 복잡한 논의를 비교적 간략하게 설명한 것이지만, 여기서 필요한 핵심 개념을 제공합니다.

통합에서 마이크로서비스 원칙 활용

그렇다면 애플리케이션을 더욱 세분화된 방식으로 구축하는 것이 합리적이라면, 이 아이디어를 통합에도 적용할 수 있지 않을까요? 전사적으로 중앙 집중화된 ESB 구성 요소를 더 작고 관리하기 쉬운 전용 구성 요소로 분할할 수 있습니다. 노출하는 각 인터페이스에 대해 하나의 통합 런타임을 사용하는 것까지 고려해 볼 수 있습니다.

이 패턴을 애자일 통합 아키텍처(AIA) 라고 부르지 만, 한때 경량 통합(Lightweight Integration) 이라고도 불렸습니다 . 이러한 용어는 AIA를 완전한 마이크로서비스 애플리케이션 아키텍처와 구분하며, 더 복잡한 중앙 집중식 통합 아키텍처와 밀접한 관련이 있는 ESB(Enterprise Business Business) 용어와도 구분합니다.

2부 에서는 애자일 통합 아키텍처를 더 자세히 설명하고, 통합 아키텍처가 마이크로서비스의 기반 기술과 원칙을 어떻게 활용할 수 있는지 살펴보겠습니다. 이를 통해 새로운 애플리케이션이 최신 혁신의 속도와 규모에 맞춰 필요한 통합을 수행할 수 있습니다.

감사의 말

이 기사의 내용에 대한 의견과 검토를 해주신 다음 분들께 감사드립니다: Andy Garratt, Nick Glowacki, Rob Nicholson, Brian Petrini, Claudio Tagliabue.

출처: https://developer.ibm.com/articles/cl-lightweight-integration-1/