MSA 그리고 분산 어플리케이션 기술 비교

기업의 아키텍처를 담당하는 담당자 분들을 만나 이야기 하다 보면 많은 분들이 과거 분산 아키텍처는 계속해서 실패했다는 이야기를 하곤 합니다. 이에 과거 분산 아키텍처 기술과 MSA를 비교하는 표를 만들어 보았습니다. 개인적으로 MSA는 클라우드 시대 어플리케이션을 구성하는 기본 아키텍처가 될 것이라고 봅니다. 

 

 이 표에는 그간의 분산 어플리케이션 아키텍처가 왜 실패했었는지도 기술했습니다. 

	RPC	CORBA	EJB	SOA	MSA
시기	•1980년대 중후반	•1990년대 초반	•2000년대 초반	•2000년대 중반	•2010년대 중반
특징	•가장 오래된 프로세스간 통신 방식 •원격의 프로시저를 로컬에서 동작	•OMG그룹에서 표준 정의 •로컬/원격 객체 간  메소드 호출 표준 규격 •다양한 언어를 지원	•원격 자바 객체 호출 표준 •트랜잭션을 관리하는 세션빈과 데이터를 관리하는 엔티티빈으로 구성	•서비스 재사용성에 초점 •SOAP과 XML을 사용하는 웹서비스 기반으로 발전 •벤더 중심 생태계 발전	•Cloud向 어플리케이션 아키텍처로 가장 많이 사용 •폴리글랏 지원 •오픈소스 중심으로   발전
장점	•통신 로직 구현에 드는 개발 코스트 절감 •다양한 언어를 가진 환경에서 쉽게 확장 가능	•다양한 클라이언트 지원 •오픈소스 방식을 통한 벤더 종속 탈피	•J2EE 표준 스펙으로 구축 비용이 상대적으로 저렴	•다양한 클라이언트 지원(XML, SOAP) •서비스 재 사용성 높음	•다양한 성공 사례 존재 •REST(JSON)의 확산과 함께 인터페이스간 연계 용이
단점	•새로운 학습 비용 발생 •가독성이 떨어지는   코드	•높은 구현 난이도	•높은 구현 난이도 •전사 표준 아키텍처  적용 한계  (J2EE만 지원)	•ESB 종속성 발생 •비즈니스 서비스와 연계된 ESB와 레거시간 통합 불편	•높은 플랫폼 도입   난이도
IDL/ 프로토콜	•IDL 無 •Stub/Skeleton 有	•OMG IDL •Stub/Skeleton 사용 •IIOP 사용	•IDL 대신 Remote Interface 및 DD 파일 사용 •Stub/Skeleton 사용	•SOAP •WSDL	•JSON/RESTful(http/https)    * lightweight protocol(REST/JSON)
비즈니스 허브	•없음	•없음	•없음	•ESB	•API Gateway
서비스 라우팅/ 레지스트리	•없음	•없음	•JNDI	•UDDI	•Service Mesh
트랜잭션 처리	•없음 •보상 트랜잭션	•없음 •보상 트랜잭션	•XA를 이용한 2PC 지원	•없음 •보상 트랜잭션	•없음 •보상트랜잭션(SAGA)
저변화 실패 요인	•송신자와 수신자 사이에 인터페이스를 IDL를 통한 인터페이스 정의 •엔터프라이즈 대응  미흡	•높은 구현 난이도 •분산 아키텍처에 대한 시장 이해도 부족 •엔터프라이즈 대응  미흡	•단일 아키텍처 지원 •낮은 성능 및 개발  생산성 •ORMapping에 대한 낮은 이해도 •Lightweight java 프레임워크 발전	•시장 성숙도 부족으로 인한 기업 내 거버넌스 대응 미흡 •벤더 중심의 아키텍처 주도(ESB:Middleware 중심) •아키텍처 도입을 드라이브할 플랫폼 변혁이 없었음(e.g.클라우드)

 

이 표는 최근 제가 직접 수행했었던 시중 은행 차세대 시스템 구축을 위한 ISP 컨설팅에서 고객에게 첨부의 자료로 제출되었었습니다.

과거의 분산 아키텍처 기술과 MSA의 기술이 어떤 차이가 있는지 궁금해 하시는 분들께 도움이 되었으면 좋겠습니다.

 

감사합니다.