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

ESB는 데이터 모델의 변환을 수행하고, 연결을 처리하고, 메시지 라우팅을 수행하고, 통신 프로토콜을 변환하고, 잠재적으로 여러 요청의 구성을 관리합니다. ESB는 이러한 통합 및 변환을 새로운 애플리케이션에서 재사용할 수 있는 서비스 인터페이스로 제공할 수 있습니다.

ESB 패턴은 일반적으로 패턴은 일반적으로 최고의 생산성을 보장하기 위해 특별히 설계된 통합 런타임 및 툴 세트(예: ESB 제품)을 사용하여 구현됩니다.

ESB는 1990년대 후반에 등장한 소프트웨어 아키텍처인 SOA(서비스 지향 아키텍처)의 필수 구성 요소입니다. SOA는 서비스 인터페이스를 통해 소프트웨어 구성 요소를 재사용할 수 있게 만드는 방법을 정의합니다. 이러한 서비스는 일반적으로 표준 인터페이스(예: 웹 서비스)를 사용하므로 새 애플리케이션에서 서비스가 수행하는 기능을 복제하지 않고도 빠르게 새 애플리케이션에 통합할 수 있습니다.

SOA의 각 서비스는 완전하고 개별적인 비즈니스 기능(예: 고객의 신용 확인, 월별 대출 상환액 계산 또는 모기지 신청 처리)을 실행하는 데 필요한 코드와 데이터를 구현합니다. 서비스 인터페이스는 느슨한 결합을 제공합니다. 즉, 아래에서 서비스가 구현되는 방법을 거의 또는 전혀 알지 못한 상태에서 호출할 수 있어 애플리케이션 간의 종속성이 줄어듭니다.서비스 인터페이스의 기반이 되는 애플리케이션은 Java, Microsoft.Net, Cobol 또는 기타 프로그래밍 언어로 작성하거나, 공급업체에서 패키지 엔터프라이즈 애플리케이션으로 제공하거나(예: SAP), SaaS 애플리케이션(예: SalesforceenCRM), 오픈 소스 애플리케이션으로 제공됩니다.

서비스 인터페이스는 확장 가능한 마크업 언어(XML)를 기반으로 하는 표준 태그 구조인 웹 서비스 정의 언어(WSDL)를 사용하여 정의되는 경우가 많습니다. 이 서비스는 데이터 읽기 또는 변경 요청을 전송하기 위해 SOAP(단순 객체 액세스 프로토콜)/HTTP 또는 JSON/HTTP와 같은 표준 네트워크 프로토콜을 사용하여 노출됩니다. 서비스 거버넌스는 개발 수명주기를 제어하며, 서비스가 적절한 단계에서 레지스트리에 게시되므로 개발자가 신속하게 서비스를 찾아 재사용하여 새로운 애플리케이션 또는 비즈니스 프로세스를 조립할 수 있습니다.

서비스는 처음부터 자체 빌드할 수 있지만 기존 레코드 시스템에서 함수를 노출하여 만드는 경우가 많습니다. 기업은 기존 시스템 앞에 표준 기반 서비스 인터페이스를 제공하거나, ESB를 사용하여 어댑터 또는 커넥터를 통해 레거시 시스템에 직접 연결하거나, 애플리케이션에서 자체 API를 제공하는 방식 중 원하는 것을 선택할 수 있습니다. 어떤 경우든 엔터프라이즈 서비스 버스는 새 애플리케이션을 기존 인터페이스로부터 보호합니다. ESB는 기존 시스템 서비스에 연결하는 데 필요한 변환 및 라우팅을 수행합니다.

ESB 아키텍처 없이 SOA를 구현할 수도 있지만, 이는 단순히 여러 서비스를 보유하는 것과 다르지 않습니다. 각 애플리케이션 소유자는 필요한 서비스에 직접 연결하고, 각 서비스 인터페이스를 충족하기 위해 필요한 데이터 변환을 수행해야 합니다. 인터페이스를 재사용할 수 있더라도 많은 작업이 필요하며, 각 연결이 지점 간 연결이므로 향후 유지 관리에 상당한 어려움이 발생합니다.

이론적으로 중앙 집중식 ESB는 기업 전반의 서비스 간 커뮤니케이션, 메시징 및 통합을 표준화하고 획기적으로 간소화할 수 있는 잠재력을 갖고 있습니다. 하드웨어와 소프트웨어 비용을 공유할 수 있으며, 통합된 사용량에 따라 필요한 서버를 프로비저닝하여 확장 가능한 중앙 집중식 솔루션을 제공합니다.전문가로 구성된 단일팀에게 통합을 개발하고 유지 보수하는 업무를 맡기고, 필요한 경우 교육도 받을 수 있습니다.

소프트웨어 애플리케이션은 ESB에 연결('통신')한 후 ESB에 맡겨두기만 하면 ESB가 프로토콜을 변환하고, 메시지를 라우팅하고, 필요에 따라 데이터 형식으로 변환하여 트랜잭션을 실행할 수 있는 상호 운용성을 제공합니다. 엔터프라이즈 서비스 버스 아키텍처 접근 방식은 애플리케이션 통합, 데이터 통합, 서비스 오케스트레이션, 비즈니스 프로세스 자동화를 위한 시나리오를 지원합니다. 이를 통해 개발자는 통합에 들어가는 시간을 획기적으로 줄이고, 애플리케이션을 제공하고 개선하는 업무에 시간을 더 많이 투자할 수 있습니다. 또한 한 프로젝트가 끝난 후 다음 프로젝트에서 이러한 통합을 재사용할 수 있게 됨으로써 다운스트림에서 생산성 향상과 비용 절감의 가능성이 더욱 커졌습니다.

많은 조직에서 ESB가 성공적으로 배포되었지만, ESB를 병목 현상으로 생각하는 조직도 많았습니다. 하나의 통합을 변경하거나 개선하면 동일한 통합을 사용하는 다른 사용자가 불안정해질 수 있기 때문입니다. ESB 미들웨어에 대한 업데이트가 기존 통합에 영향을 미치는 경우가 많아서 업데이트를 수행하려면 상당한 테스트를 거쳐야 했습니다. ESB가 중앙에서 관리되었기 때문에 애플리케이션 팀은 곧 통합 순서가 돌아올 때까지 기다려야 했습니다. 통합의 양이 증가함에 따라 당시 ESB 서버에 대한 고가용성 및 재해 복구를 구현하는 데 더 많은 비용이 들었습니다.또한, 기업 간 프로젝트인 만큼 자금 조달이 어려웠기 때문에 이러한 기술적 과제를 해결하기가 훨씬 더 어려웠습니다.

결국 중앙 집중화된 ESB를 유지 보수, 업데이트 및 확장하는 데 큰 어려움이 따르는데다 비용 또한 많이 들었기 때문에 당시 ESB가 의도했던 생산성 향상을 지연시키는 경우가 많았고, SOA는 더 빠른 혁신 속도를 기대하던 실무팀에 실망을 안겨주곤 했습니다.

ESB의 흥망성쇠에 대해 더 자세히 알아보려면 "ESB의 운명"을 읽어보시기 바랍니다.

마이크로서비스 아키텍처를 사용하면 단일 애플리케이션의 내부를 작은 조각으로 나눠 독립적으로 변경, 확장 및 관리할 수 있습니다. 마이크로서비스는 가상화, 클라우드 컴퓨팅, 애자일 개발 관행 및 DevOps와 함께 등장하여 이들의 부상으로 힘을 얻었습니다. 마이크로 서비스는 다음과 같은 이점을 제공합니다.

• 개발자의 민첩성과 생산성 향상: 개발자가 애플리케이션의 나머지 부분을 건드리거나 '따라잡지' 않고도 애플리케이션의 한 부분에 새로운 기술을 통합할 수 있습니다.
• 더 간편하고 비용 효율적인 확장성: 모든 구성 요소를 다른 구성 요소와 독립적으로 확장할 수 있어 워크로드 수요에 가장 빠르게 대응하고, 컴퓨팅 리소스를 가장 효율적으로 사용할 수 있습니다.
• 복원력 향상: 한 구성 요소의 장애가 다른 구성 요소에 영향을 미치지 않고 각 마이크로서비스가 '최대 공통 가용성' 요구 사항에 따라 다른 구성 요소를 스테이킹하지 않고도 자체 가용성 요구 사항을 충족합니다.

마이크로서비스가 애플리케이션 설계에 제공하는 것과 동일한 세분성을 통합에도 적용하여 유사한 이점을 누릴 수 있습니다. 애자일 통합은 ESB를 상호 의존성 없이 세분화되고 분산된 통합 구성 요소로 분할하여 개별 애플리케이션 팀이 직접 소유하고 관리할 수 있도록 하는 개념입니다.