ESB(엔터프라이즈 서비스 버스)

menu icon

ESB(엔터프라이즈 서비스 버스)

이 가이드는 ESB(SOA의 필수 컴포넌트), 그 장점 및 마이크로서비스 아키텍처와 관련된 방법에 대해 자세히 설명합니다.

ESB(엔터프라이즈 서비스 버스)란?

ESB 또는 엔터프라이즈 서비스 버스는 중앙 집중식 소프트웨어 컴포넌트가 백엔드 시스템에 대한 통합을 수행하고(및 데이터 모델, 심층 연결, 라우팅 및 요청의 변환) 새 애플리케이션에서 재사용하기 위해 서비스 인터페이스로 사용할 수 있는 통합 및 변환을 수행하는 패턴입니다. ESB 패턴은 일반적으로 최고의 생산성을 보장하는 특별히 디자인된 통합 런타임과 툴 세트를 사용하여 구현됩니다.

ESB와 SOA

ESB는 SOA 또는 서비스 지향 아키텍처의 필수 컴포넌트로서 1990년대 후반에 등장한 아키텍처입니다. SOA는 서비스 인터페이스를 통해 소프트웨어 컴포넌트를 재사용할 수 있는 방법을 정의합니다. 이러한 인터페이스는 매번 깊은 통합을 수행하지 않고도 새 애플리케이션에 빠르게 통합될 수 있는 방식으로 공통 통신 표준을 활용합니다.

SOA의 각 서비스는 완전한 개별 비즈니스 기능(예: 고객의 신용 확인, 월별 대출 납입금 계산 또는 모기지 신청 처리)을 실행하는 데 필요한 코드 및 데이터 통합을 구현합니다. 서비스 인터페이스는 느슨한 결합을 제공하며 이는 아래에 구현되는 방법에 대한 지식이 거의 없거나 전혀 없이 호출될 수 있음을 의미합니다. SOAP(단순 오브젝트 액세스 프로토콜)/HTTP 또는 JSON/HTTP와 같은 표준 네트워크 프로토콜을 사용하여 서비스를 노출하여 데이터를 읽거나 변경하기 위한 요청을 전송합니다. 서비스는 개발자가 신속하게 검색하여 새 애플리케이션을 구축하는 데 재사용할 수 있는 방식으로 공개됩니다.

이러한 서비스는 처음부터 빌드할 수 있지만 서비스 인터페이스로 레코드의 레거시 시스템으로부터 기능을 노출하여 생성하는 경우가 많습니다. 이때 ESB의 필요성이 제기됩니다. 레거시 시스템 및 레코드 시스템은 일반적으로 SOA 네트워크 프로토콜을 사용하여 작업하기 위해 변환되고 통합되어야 하는 이전 프로토콜 및 독점 데이터 형식을 사용합니다. ESB는 필요한 때에 이러한 변환과 통합을 수행합니다. ESB를 사용하지 않고 SOA를 구현할 수 있지만, 애플리케이션 소유자들은 서비스 인터페이스를 노출하는 고유한 방법을 찾아야 하며, 이는 많은 작업(결국 인터페이스를 재사용할 수 있는 경우에도)을 요구하면 향후에도 상당한 유지보수 문제를 야기할 수 있습니다.

SOA에 대한 자세한  정보와 ESB의 역할에 대해 알아보려면 "SOA(서비스 지향 아키텍처) 소개"를 참조하세요.

이점

이론적으로 중앙집중형 ESB는 엔터프라이즈에서 서비스 전달 및 통합을 표준화하고 극적으로 단순화할 수 있는 잠재력을 제공합니다. 하드웨어 및 소프트웨어 비용을 공유하고, 서버를 한 번만 프로비저닝하고, 단일 전문가 팀이 통합을 개발 및 유지하기 위해 태스크를 수행합니다(필요한 경우, 교육을 받을 수 있음).

개발자는 단일 프로토콜을 사용하여 ESB에 연결하고 서비스 간에 상호작용을 지시한 다음 명령을 변환하고 메시지를 라우트하며 명령을 실행하기 위해 필요한 대로 데이터를 변환하기 위해 ESB로 이동하는 명령을 실행할 수 있습니다. 이렇게 하면 개발자가 애플리케이션을 통합하는 데 걸리는 시간을 훨씬 더 적게 사용하고 애플리케이션을 구성하고 개선하는 데 더 많은 시간을 사용할 수 있습니다. 이러한 통합을 한 프로젝트에서 다음 프로젝트로 재사용할 수 있는 기능은 여전히 높은 생산 이득과 절감 가능성을 다운스트림에 제공합니다.

하지만 많은 조직에서 ESB가 성공적으로 전개되었고, 다른 많은 조직에서는 ESB가 SOA 전개의 병목현상으로 간주되었습니다. 하나의 통합을 변경하거나 향상시키면 종종 다른 통합이 불안정합니다. ESB 미들웨어에 대한 업데이트는 종종 기존 통합에 영향을 주었습니다. ESB가 중앙 집중식으로 관리되었기 때문에, 애플리케이션 팀들은 그들의 통합을 위해 줄을 서서 기다려야 했습니다. 통합 볼륨이 증가하면서 ESB 서버에 대한 고가용성 및 장애 복구를 구현하는 데 비용이 많이 소요되었습니다. 그리고 기업 교차 프로젝트로 진행되는 ESB는 자금 조달의 어려움이 입증되었고 관련 기술 과제를 해결하는 일이 쉽게 않았습니다.

결국, 중앙집중형 ESB를 유지 및 업데이트하고 확장하는 문제는 매우 압도적이고 값비싼 대가가 필요하기 때문에 ESB(및 SOA)는 종종 생산하기 원하는 이득의 실현을 지연시켜 더 큰 변화 속도를 기대하는 비즈니스 팀을 좌절시킵니다.

ESB의 흥망성쇠에 대한 자세한 내용은 "ESB의 운명"을 읽어보세요.

ESB와 마이크로서비스

마이크로서비스 아키텍처는 단일 애플리케이션의 내부를 독립적으로 변경되고 규모가 조정되고 관리될 수 있는 작은 조각으로 분할합니다. 마이크로서비스는 가상화, 클라우드 컴퓨팅, Agile 개발 사례 및 DevOps의 증가로 인해 급부상하고 관심을 받았습니다. 이러한 측면에서 마이크로서비스는 다음을 기능을 제공합니다.

  • 개발자의 민첩성과 생산성 향상. 개발자는 애플리케이션의 나머지 부분을 터치하거나 '캐치업'하지 않고도 애플리케이션의 한 부분에 새 기술을 통합할 수 있습니다.
  • 단순함, 매우 비용 효율적인 확장성. 워크로드 요구사항에 가장 빠르게 대응하고 컴퓨팅 리소스를 가장 효율적으로 사용함으로써 특정 컴포넌트를 다른 컴포넌트와 독립적으로 확장할 수 있습니다.
  • 향상된 복원성. 이는 한 컴포넌트의 실패가 다른 컴포넌트에 영향을 주지 않으며 각 마이크로서비스는 다른 컴포넌트를 '가장 일반적인 가용성' 요구사항에 고정시키지 않고 자체 가용성 요구사항에 대해 수행할 수 있기 때문입니다.

마이크로서비스가 애플리케이션 설계에 전달한 동일한 세분성을 유사한 장점과 함께 통합할 수 있습니다. 이는 개별 애플리케이션 팀이 스스로를 소유하고 관리할 수 있으며 상호 종속성이 없는 세분화된 분산된 통합 컴포넌트로 ESB를 구분하는 애자일 통합 아이디어입니다.

마이크로서비스에 대한 자세한 정보를 확인하려면 "마이크로서비스: 완벽 가이드" 그리고 "SOA vs 마이크로서비스: 그 차이점은?"을 확인하고, Dan Bettinger의 동영상" 마이크로 서비스란 무엇일까요?"를 참조하세요.

ESB와 IBM Cloud

회사가 IT 인프라를 하이브리드 클라우드 방식으로 이동함에 따라, SOA 및 ESB 패턴을 기반으로 하는 다양한 워크로드를 더 가볍고 유연한 배치 모델로 전환할 가능성이 높습니다. 이러한 전환은 조직이 거치는 클라우드로의 여정에서 애플리케이션 현대화의 한 부분입니다.  

다음 단계로 진행:

  • IBM Cloud  Pak for Integration을 포함하여 미들웨어 투자를 활용, 확장 및 현대화하는 방법에 대해 확인해 보세요.
  •  IBM Cloud Integration을 방문하여 개인화된 고객 경험을 위해 다양한 프라이빗  및 퍼블릭 클라우드에서 모든 애플리케이션 및 데이터를 연결하는 방법에 대해 알아보세요.

 IBM Cloud 계정으로 지금 시작하세요.