개요
서비스 지향 아키텍처(SOA)는 네트워크에서 공통의 통신 언어를 사용하는 서비스 인터페이스를 활용하여 소프트웨어 구성 요소를 다시 사용할 수 있게 만드는 소프트웨어 설계 유형입니다.
서비스란 독립적인 소프트웨어 기능 단위 또는 기능 모음을 가리킵니다. 서비스는 지정된 정보를 검색하거나 작업을 실행하는 등 구체적인 태스크를 완료하도록 설계되어 있습니다. 서비스에는 완전한 개별 비즈니스 기능을 수행하는 데 필요한 코드와 통합 데이터가 들어 있으며, 원격으로 서비스에 액세스할 수 있고 독립적으로 상호작용하거나 업데이트할 수 있습니다.
다시 말해 SOA는 별도로 배포 및 유지관리되는 소프트웨어 구성 요소를 통합하고, 이러한 구성 요소가 서로 통신하고 연동되도록 함으로써 여러 시스템에서 실행되는 소프트웨어 애플리케이션을 구성할 수 있습니다.
서비스 지향 아키텍처는 어떻게 작동하나요?
1990년 말에 SOA가 상용화되기 전에는 어떤 애플리케이션을 다른 시스템의 서비스와 연결하려면 접속, 라우팅, 데이터 모델 변환 등 수준 높은 P2P(point-to-point) 통합을 비롯하여 복잡한 프로세스를 거쳐야 했고, 이후 새로운 프로젝트를 할 때마다 개발자가 이 과정을 반복해야 했습니다. 이를 “모놀리식(monolithic)” 모델이라고 하는데, 애플리케이션 전체의 코드가 하나의 배포에 구현되기 때문입니다. 모놀리식 모델에서는 애플리케이션의 어느 측면이 제대로 작동하지 않을 경우 애플리케이션 전체를 잠시 오프라인 상태로 전환한 다음 문제를 해결하고 새 버전을 다시 배포해야 했습니다.
SOA에서는 요청을 보내거나 데이터에 액세스할 때 SOAP, JSON, ActiveMQ, Apache Thrift와 같은 표준 네트워크 프로토콜을 사용하여 서비스를 공개하므로 개발자가 처음부터 새로 통합할 필요가 없습니다. 그 대신 엔터프라이즈 서비스 버스(ESB)라는 패턴을 사용하면 됩니다. ESB는 중앙화된 구성 요소와 백엔드 시스템을 통합한 다음 이를 서비스 인터페이스의 형태로 제공합니다. 따라서 개발자는 기능을 다시 만드는 대신에 기존 기능을 재사용할 수 있습니다.
서비스 지향 아키텍처 스타일인 경우 서비스는 "느슨한 결합" 시스템을 사용하여 통신합니다. 이런 식으로 어떤 시스템 또는 네트워크 내의 여러 구성 요소("요소")를 서로 연결하면 상호 종속성을 줄이면서도 정보를 전달하거나 비즈니스 프로세스를 조율할 수 있습니다. 이로 인해 결과적으로 새로운 애플리케이션이 생성됩니다.
모놀리식 방식보다 나은 점
- 출시 일정 단축 및 유연성 향상: 서비스 재사용이 가능하므로 훨씬 더 쉽고 빠르게 애플리케이션을 조합할 수 있습니다. 즉, 모놀리식 애플리케이션처럼 개발자가 매번 새로 시작하지 않아도 됩니다.
- 신규 시장에서 레거시 인프라 활용: SOA에서는 개발자가 어떤 플랫폼 또는 환경의 기능을 선택한 다음 새로운 플랫폼 또는 환경에 확대 적용하기가 더 수월합니다.
- 더 효율적인 애자일 개발 방식으로 비용 절감
- 손쉽게 유지관리: 모든 서비스는 독립적으로 완성된 형태이므로 다른 서비스에 영향을 주지 않고 필요에 따라 수정하고 업데이트할 수 있습니다.
- 확장성: SOA에서는 여러 가지 서비스, 플랫폼, 프로그래밍 언어로 실행할 수 있기 때문에 확장성이 획기적으로 향상됩니다. 또한 표준화된 통신 프로토콜을 사용하는 SOA에서는 클라이언트와 서비스 간의 상호 작용을 줄일 수 있습니다. 이러한 상호 작용이 줄어들면 애플리케이션을 더 부담 없이 편리하게 확장할 수 있습니다.
- 안정성 강화: 큰 코드보다 작은 서비스를 디버깅하기가 더 쉽기 때문에 SOA에서는 더 안정적인 애플리케이션을 만들 수 있습니다.
- 편리한 이용: SOA 기능은 누구나 이용 가능합니다.
SOA 역할
서비스 지향 아키텍처의 구성 요소는 3개의 역할로 이루어집니다.
서비스 제공업체
서비스 제공업체는 웹 서비스를 생성하고 이를 서비스 레지스트리에 제공합니다. 서비스 제공업체는 서비스 약관에 대한 책임이 있습니다.
서비스 브로커 또는 서비스 레지스트리
서비스 브로커 또는 서비스 레지스트리는 요청자에게 서비스에 대한 정보를 제공할 책임이 있습니다. 브로커는 퍼블릭 또는 프라이빗일 수 있습니다.
서비스 요청자 또는 서비스 사용자
서비스 요청자는 서비스 브로커 또는 서비스 레지스트리에서 서비스를 찾고, 서비스를 받기 위해 서비스 제공업체에 연결합니다.
Red Hat과 마이크로서비스에 대한 추가 정보
서비스 지향 아키텍처 vs. 마이크로서비스
서비스 지향 아키텍처에서 처음 선보인 서비스의 개념이 오늘날 클라우드 컴퓨팅 및 가상화(미들웨어, 마이크로서비스 등)의 주요 구성 요소로 발전했습니다.
SOA와 마이크로서비스 아키텍처는 그 유사성 때문에 혼동하기 쉽습니다. 이 둘의 근본적인 차이점은 범위에 있습니다. SOA가 전사적인 아키텍처 접근 방식이라면 마이크로서비스는 애플리케이션 개발 팀 내의 구현 전략입니다.
그리고 각각의 구성 요소와 통신하는 방법도 다릅니다. SOA는 ESB를 사용하는 반면, 마이크로서비스끼리는 언어의 제약이 없는 API를 통해 스테이트리스(stateless) 방식으로 통신합니다. 마이크로서비스의 API에는 언어의 제약이 없기 때문에 개발 팀에서 사용하고 싶은 툴을 선택할 수 있습니다. 따라서 마이크로서비스의 내결함성과 유연성이 더 우수할 수 있습니다.
SOA는 서비스로서의 소프트웨어(SaaS)와 혼동될 때도 있습니다. SaaS는 클라우드 애플리케이션과 기본 IT 인프라 및 플랫폼을 사용자에게 제공하는 클라우드 컴퓨팅 형태이며, SOA의 웹 서비스는 서비스 제공업체가 SaaS 애플리케이션으로 제공할 수 있습니다. 일반적으로 클라우드 서비스 제공업체(예: AWS, Azure, IBM Cloud)는 SaaS 애플리케이션이 호스팅되는 클라우드 환경을 관리합니다.
사용자는 컴퓨터 또는 모바일 기기의 웹 브라우저를 통해 소프트웨어와 상호작용합니다. 이는 REST 또는 SOAP와 같은 API를 사용해 소프트웨어를 다른 기능에 연결할 수도 있습니다.
Red Hat과 마이크로서비스
컨테이너 기술의 발전에 힘입어 마이크로서비스는 클라우드 네이티브 애플리케이션의 기반으로 자리잡았습니다. Linux 컨테이너의 형태로 배포되고 메시지 라우팅을 위해 메시 네트워크 또는 API를 통해 연결된 마이크로서비스는 서로 느슨하게 결합되어 있습니다.
각 요소가 하나의 비즈니스 기능을 구현하고, 소규모 DevOps 팀에서 지속적인 통합(Continuous Integration, CI)과 지속적인 제공(Continuous Delivery, CD) 같은 워크플로우에 따라 각 요소를 독립적으로 개발합니다. 따라서 모놀리식 개발 주기의 제약에서 벗어나 더 빠른 소프트웨어 개발, 자동 배포, 정기적인 업데이트가 가능합니다.
Red Hat은 Red Hat® Enterprise Linux®, Red OpenShift 등이 포함된 Red Hat 오픈소스 포트폴리오를 통해 여러 기업과 협력할 수 있습니다. 빠른 속도와 우수한 적응성을 자랑하는 클라우드 컴퓨팅 환경으로 인프라 및 애플리케이션 개발 업무를 점차 이전하는 한편 기존 인프라를 최대한 활용하고자 하는 기업이라면 Red Hat과 파트너십을 활용해 보세요.
