SOA(Service-Oriented Architecture)

menu icon

SOA(Service-Oriented Architecture)

애플리케이션 개발과 통합의 발전에서 중요 단계인 SOA(service-oriented architecture)를 살펴봅니다.

SOA(Service-Oriented Architecture)란?

SOA(Service-Oriented Architecture)는 서비스 인터페이스를 통한 소프트웨어 컴포넌트의 재사용을 가능하게 하는 방법을 정의합니다. 이러한 인터페이스는 매번 깊은 통합을 수행하지 않고도 새 애플리케이션에 빠르게 통합될 수 있는 방식으로 공통 통신 표준을 활용합니다.

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

이러한 서비스는 맨 처음부터 빌드가 가능하지만, 종종 서비스 인터페이스로서 레코드의 레거시 시스템에서 기능을 노출하여 작성됩니다.

이러한 방식으로, SOA는 지난 수십 년간 애플리케이션 개발과 통합의 발전에서 중요한 단계를 보여줍니다. SOA가 1990년대 후반에 등장하기 전에는 애플리케이션을 다른 시스템에 있는 기능 또는 데이터에 연결하려면 복잡한 지점간 통합, 즉 개발자들이 각각의 새로운 개발 프로젝트에 대해 부분적으로 또는 전체적으로 재작성해야 했던 통합이 필요했습니다. SOA를 통해 이러한 기능을 노출하면 매번 심층 통합을 재작성할 필요가 없습니다.

비록 SOA 및 최신 마이크로서비스 아키텍처가 공통적으로 많은 단어들을 공유하고 있지만, 이들은 단지 느슨하게 관련되어 있을 뿐이며 사실 이 기사에서 나중에 설명하는 대로 다양한 범위에서 작동한다는 점을 유념하세요.

ESB란?

ESB(enterprise service bus)는 중앙집중화된 컴포넌트가 백엔드 시스템으로의 통합을 수행한 후 이러한 통합을 서비스 인터페이스로 사용할 수 있도록 하는 패턴입니다. 이는 데이터 모델의 변환, 심층 연결, 라우팅 및 잠재적으로 여러 요청의 구성을 수행하며, 새 애플리케이션에서 재사용할 수 있도록 단일 서비스 인터페이스로 이를 사용할 수 있도록 합니다. ESB 패턴은 일반적으로 위의 기능에 적합한 특수 설계된 통합 런타임 및 툴링을 사용하여 구현됨으로써 최고의 가능한 생산성을 보장합니다.

이론적으로는 ESB 없이도 SOA를 구현할 수 있지만, 애플리케이션 소유자는 각각 서비스 인터페이스를 노출하는 고유한 방법을 찾아야 하며, 이는 엄청난 작업(인터페이스가 결국 재사용 가능한 경우에도)이며 향후에 상당한 유지보수 문제를 야기합니다. 사실 ESB는 결국 SOA 구현의 사실상 요소로 간주됨으로써 두 용어는 종종 동의어로 사용되어 혼란을 야기합니다.

"ESB(Enterprise Service Bus) 소개"를 읽고 ESB에 대해 자세히 알아보세요.

SOA의 장점

앞서 있는 아키텍처와 비교하여, SOA는 기업에 상당한 이점을 제공합니다.

  • 비즈니스 민첩성 향상, 시장 출시 속도 개선: 모든 신규 개발 프로젝트를 재작성하고 이와 다시 통합하는 대신에 재사용 가능한 서비스 인터페이스에서 애플리케이션을 어셈블하는 효율성을 통해 개발자는 신규 비즈니스 기회에 대응하여 훨씬 더 신속하게 애플리케이션을 구축할 수 있습니다.
  • 신규 시장에서 레거시 기능을 활용하는 능력: 잘 만들어진 SOA를 통해 개발자들은 하나의 컴퓨팅 플랫폼 또는 환경에서 손쉽게 '락인된' 기능을 사용할 수 있으며 이를 신규 환경과 시장으로 확장할 수 있습니다. 예를 들어, 많은 회사에서는 SOA를 사용하여 메인프레임 기반 금융 시스템에서 웹으로 기능을 노출함으로써 고객들이 이전에 회사의 직원이나 비즈니스 파트너와의 직접 상호작용을 통해서만 액세스할 수 있었던 프로세스와 정보를 서비스할 수 있도록 합니다.
  • 비즈니스와 IT 간의 협업 개선: SOA에서 서비스는 비즈니스 용어(예: '보험 견적 생성' 또는 '자본 장비 ROI 계산')로 정의될 수 있습니다. 이를 통해 비즈니스 분석가는 보다 나은 결과를 유도할 수 있는 중요 인사이트(예: 서비스에서 정의하는 비즈니스 프로세스의 범위 또는 프로세스 변경의 비즈니스 함의)에 대해 개발자와 보다 효율적으로 작업할 수 있습니다.

SOA 예제

2010년까지, 사실상 모든 산업 분야의 선도적 기업들이 SOA 구현을 위해 전력을 기울이고 있었습니다. 예를 들면 다음과 같습니다.

  • Delaware Electric은 SOA에 의존하여 이전에는 서로 소통하지 않았던 시스템을 통합했으며, 결과적으로 5년간 주에서 강제한 전기 요금 동결 중에 기업이 지불능력을 유지할 수 있도록 도와준 개발 효율성을 얻었습니다.
  • Cisco는 주문 프로세스를 Cisco의 부서, 인수 및 비즈니스 파트너가 웹 사이트에 통합할 수 있는 서비스로서 주문 프로세스를 노출함으로써 모든 제품과 채널에서 제품 주문 경험이 일치하는지 확인하기 위해 SOA를 채택했습니다.
  • 필라델피아의 IBC(Independence Blue Cross)는 환자 데이터를 처리하는 다양한 구성요소(IBC 고객 서비스 에이전트, 의사 진료실, IBC 웹 사이트 사용자)가 동일한 데이터 소스('단일 버전의 진실')를 사용하여 작업 중임을 확인할 수 있도록 SOA를 구현했습니다.

SOA 대 마이크로서비스

전문가들은 SOA 및 마이크로서비스를 비교하고 서로 간의 관계의 미묘함을 정의하는 수천 개의 인쇄 및 디지털 페이지를 채웠습니다. 이 기사의 목적상, 둘 사이의 주된 차이점은 사용의 범위와 컴포넌트의 커플링입니다.

  • SOA는 전사적 개념입니다. 이를 통해 기존 애플리케이션은 느슨하게 결합된 인터페이스를 통해 노출될 수 있으며, 이들 각각은 확장된 엔터프라이즈의 일부의 애플리케이션이 기타 애플리케이션의 기능을 재사용할 수 있게 해주는 비즈니스 기능에 대응됩니다.
  • 마이크로서비스 아키텍처는 애플리케이션 범위 개념입니다. 이는 단일 애플리케이션의 내부를 독립적으로 변경, 스케일링 및 관리할 수 있는 작은 조각으로 분할할 수 있도록 합니다. 이는 애플리케이션이 서로 간에 통신하는 방법을 정의하지 않습니다. 따라서 우리는 SOA에서 제공하는 서비스 인터페이스의 엔터프라이즈 범위로 다시 돌아갑니다.

마이크로서비스 아키텍처는 가상화, 클라우드 컴퓨팅, Agile 개발 사례 및 DevOps의 부상으로 인해 출현하여 인기를 얻었습니다. 이러한 상황에서 마이크로서비스의 장점들은 대부분 컴포넌트의 완전한 디커플링으로부터 발생하며, 이는 다음을 간소화하고 개선합니다.

  • 개발자 민첩성과 생산성: 마이크로서비스를 사용하면 개발자가 애플리케이션의 나머지를 따라잡지 않고도 애플리케이션의 일부에 신기술을 통합할 수 있습니다. 임의의 컴포넌트를 다른 컴포넌트와 독립적으로 수정, 테스트 및 배치할 수 있으며, 이는 반복 주기를 가속화합니다.
  • 확장성: 마이크로서비스는 클라우드 확장성을 최대한 활용할 수 있습니다. 컴퓨팅 리소스의 가장 효율적인 사용과 워크로드 요구사항에 대한 가능한 가장 빠른 응답을 위해 임의의 컴포넌트를 기타 컴포넌트와 독립적으로 스케일링할 수 있습니다.
  • 탄력성: 다시 말하지만, 디커플링 덕분에 한 마이크로서비스의 장애는 기타 마이크로서비스에 영향을 주지 않습니다. 그리고 각 마이크로서비스는 기타 컴포넌트나 전체 애플리케이션을 최대의 공통 가용성 요구사항에 적용하지 않고도 자체 가용성 요구 사항을 수행할 수 있습니다.

SOA와 마이크로서비스 간의 차이점에 대한 자세한 설명은 "SOA 대 마이크로서비스: 차이점"을 참조하세요.

마이크로서비스 아키텍처가 애플리케이션 설계에 대한 민첩성, 확장성 및 탄력성을 개선할 수 있는 가능성과 동일한 방식으로 이러한 동일한 기술을 통합에 적용할 수도 있습니다. 시간이 지나면서 과도하게 중앙집중화된 ESB 패턴과 이와 연관된 중앙집중화된 통합 전문가 팀이 병목 현상이 될 수 있으므로, 이는 매우 중요합니다. 마이크로서비스 원칙에서 차용함으로써, 우리는 잠재적으로 ESB를 더욱 세분화된 분산형 통합으로 해체할 수 있습니다. 이는 애자일 통합 이면의 핵심 전제 중 하나입니다.

SOA 및 IBM Cloud

회사가 IT 인프라를 하이브리드 클라우드 접근 방법으로 이동함에 따라, SOA 기반의 워크로드를 포함하여 다양한 워크로드를 보다 가볍고 유연한 클라우드 배치 모델로 전환할 가능성이 매우 높아졌습니다. IBM은 SOA를 선도하는 기업 중 하나이며, IBM Cloud 오퍼링과 서비스는 기존의 SOA 투자를 활용하고 이를 클라우드로 확장할 수 있습니다.

다음 단계로 진행:

SOA는 핵심 애플리케이션이나 데이터베이스가 어디에 있는지와 무관하게 다양한 채널에서 서비스를 이용할 수 있도록 하는 기능을 제공하며, 이를 통해 기업들은 클라우드 여정에서 애플리케이션을 현대화하면서 투자를 활용할 수 있습니다.

IBM Cloud 계정을 통해 지금 시작하세요.