필자는 "Apache Camel을 이용한 마이크로 웹 서비스 개발" 글 등에서 아파치 카멜이 마이크로 서비스를 구축하는 데 좋은 도구로 사용될 수 있다는 말을 남긴 적이 있다. 그런데 그곳에서는 마이크로 서비스의 개념에 대해서는 별로 설명하지 않고 간단히 언급 정도만 했었다. 그리고 나서는 마이크로 서비스를 좀 더 소개할 필요가 있다고 느꼈고 이 글을 통해 간단하기는 하지만 마이크로 서비스가 갖는 핵심적인 특징을 간단히 소개하고자 한다.
"마이크로 서비스 아키텍처 스타일(Microservice architecture style)"은 독립적으로 배포 가능한 서비스들의 묶음으로 소프트웨어 애플리케이션을 설계하는 방법 을 말하지만, 아직까지는 이 아키텍처 스타일에 대한 정확한 정의는 없다. 그럼에도 마이크로 서비스 아키텍처 스타일은 비즈니스 개발, 배포 자동화, 지능적인 엔드포인트, 중립적인 언어나 데이터, 비 집중화된 제어 등의 공통적인 특징들을 갖는다.
마이크로 서비스란 용어를 처음 만든 사람은 마틴 파울러(Martin Fowler)다. 그는 그의 블로그에서 마이크로 서비스를 다음과 같이 언급했다.
"마이크로 서비스(Microservice)"는 소프트웨어 아키텍처에 있어서 아직은 새로운 용어다. 일반적으로 이런 것들은 얕잡아 보게 되고 무시되는 경향이 있기는 하지만, 이 짧은 용어는 점점 더 설득력 있게 보이는 소프트웨어 시스템들의 스타일을 설명한다. 우리는 지난 몇 년 동안 이런 스타일이 적용된 수많은 프로젝트들을 보아왔다. 결과는 지금까지 긍정적이었다. 이런 긍정적인 결과들로 인해 이 스타일은 점점 우리 동료들의 기본적인 기업 애플리케이션 개발 스타일이 되어가고 있다. 그러나 불행히도 아직까지 마이크로 서비스 스타일이 무엇인지, 어떻게 적용하는지에 대해 대강이라도 설명하는 정보들은 부족하다.
마이크로 서비스 아키텍처 스타일(Microservice architecture style)은 작은 서비스(service)들의 집합으로써 애플리케이션(monolithic application)을 개발하는 방법이다. 서비스들은 각각이 프로세스고, 서로 HTTP, JMX, JMS, AMQP, STOMP, REST API 같은 가벼운 통신 메커니즘을 사용한다. 서비스들은 비즈니스를 구현하고, 각각은 완전히 자동화된 방법으로 독립적으로 배포될 수 있다. 서비스들을 위해 최소한의 중앙 관리를 사용한다. 서비스들은 다른 프로그래밍 언어로 개발될 수 있고, 다른 데이터 저장 기술을 사용할 수도 있다.
마이크로 서비스 스타일(Microservice style)은 덩어리 스타일(monolithic style)과 비교된다. 덩어리 애플리케이션은 덩어리 단위로 개발된다. 일반적으로 기업 애플리케이션들은 세 주요 부분으로 구성된다. (사용자의 브라우저에서 동작하는 HTML 페이지와 자바스크립트를 구성하는) 클라이언트 측 사용자 인터페이스 로직과 (일반적으로 관계형 데이터베이스를 사용하는) 도메인 로직과 서버 측 애플리케이션 로직이다. 애플리케이션은 HTTP 요청을 수락하고, 도메인 로직으로 데이터베이스로부터 데이터를 갱신하거나 추출해, 브라우저에게 전송할 HTML 뷰에 덧붙여 클라이언트에 응답을 반환한다. 이런 기업 애플리케이션들은 덩어리 구조를 갖는다. 즉 한 덩어리 안에서 로직을 실행한다. 변경이 필요한 경우, 이런 애플리케이션은 이를 반영한 전체 애플리케이션을 새롭게 빌드해 배포해야 한다.
이런 덩어리 아키텍처는 LINUX 운영 체제 같은 견고한 아키텍처를 접근하기 위해서는 자연스러운 방법이다. 덩어리 애플리케이션의 모든 로직은 단일 프로세스에서 실행된다. 이런 애플리케이션은 언어의 특징을 이용해 패키지(네임스페이스), 클래스, 메소드(함수)들로 나눠 소프트웨어를 모듈화/구조화 시킨다. 이런 애플리케이션이더라도 (오랫동안 실행 및 테스트 방법이 발전해 왔으므로) 개발자 컴퓨터에서 테스트되거나 실행될 수 있다. 테스트와 운영 배포는 정해진 절차에 따라 순차적으로 진행한다. 덩어리 아키텍처 스타일에서는 부하 분산기(load-balancer) 뒤에 인스턴스들을 실행함으로 서버 성능을 수평적으로 확장시킨다.
덩어리 애플리케이션 아키텍처 스타일은 성공적일 수 있으나, (특히 클라우드에 배포되는 애플리케이션들인 경우) 사람들은 점점 더 좌절을 맛보게 되었다. 변경 주기는 이들을 더욱 옥죄었다. 덩어리 애플리케이션은 작은 부분을 변경하더라도, 전체 애플리케이션을 다시 빌드하고 배포해야 한다. 결과적으로 시간이 지나면서 모듈 구조는 훼손되고, 여러 모듈 중에 한 모듈만 변경하는 것도 쉽지 않게 된다. 일부만 확장하려고 해도, 전체 애플리케이션을 확장해야 하므로, 많은 자원을 사용해야 한다.
다음은 덩어리 아키텍처 스타일과 마이크로 서비스 아키텍처 스타일의 배포 방식 비교다.
위 그림은 마틴 파울러의 블로그에서 인용했다.
이런 좌절들이 기업 애플리케이션 아키텍처 스타일을 마이크로 서비스 아키텍처 스타일로 향하게 했다. 즉 애플리케이션을 서비스들의 묶음으로 만드는 것이다. 마이크로 서비스 아키텍처 스타일의 서비스들은 독립적으로 배포될 뿐만 아니라 확장된다. 서비스들은 견고한 모듈 경계를 가지고 있어, 설령 다른 언어로 개발된 서비스라도 함께 동작할 수 있다. 뿐만 아니라 서비스마다 관리하는 팀이 다를 수도 있다. 이런 특징들을 갖는 것이 마이크로 서비스다.
필자는 마이크로 서비스 아키텍처 개념을 몰랐던 지난 몇 년 전부터 몇몇 글에서 100줄 이내로 프로그램하는 기술을 소개한 적이 있다. 기상청 서버에서 기상 정보를 얻어 오는 애플리케이션을 개발한다거나, 자동 메일 발신 애플리케이션을 개발한다거나, 확장 가능한 웹 서비스를 제공하는 플랫폼을 개발한다거나 등 모두 아주 적은 개발량으로 비즈니스 기능을 수행하는 애플리케이션을 개발하는 방법을 소개했었다. 그리고 이런 프로그램들의 핵심 도구로 아파치 카멜(Apache Camel)을 이용했다. 그런데 이런 개발 방법이 마이크로 서비스 아키텍처와 닮았음을 알게 되었다. 이 지점에서 필자는 IT의 진지한 고민은 타국에서 마이크로 서비스 아키텍처를 고민하던 사람들과 결국 같은 지향점을 찾아 가는 과정이 아닐까 생각하게 되어 신기하기도 했다. 그리고 더 나아가 마이크로 서비스 아키텍처의 기저에는 느슨한 결합(loose coupling)과 메시징 기반의 기업 통합 패턴(Enterprise Integration Patters)이 자리 잡고 있다고 필자는 생각한다.
과거 가장 거대한 몸집을 자랑하던 공룡들은 진화에서 도태됐고, 몸집은 아주 작지만 기능적으로 잘 분업화된 사회 구조를 가진 개미들은 현재 지구상에서 가장 번성하고 있다. (지구에 사는 개미들의 전체 무게가 지구에 사는 사람들의 전체 무게보다 무겁다고 한다.) 필자는 이런 진화의 필연과 덩어리 아키텍처 스타일이 마이크로 서비스 아키텍처 스타일로 변하는 과정이 많이 닮았다고 생각한다. 그러므로 마이크로 서비스 아키텍처 스타일은 기업 아키텍처 스타일에서 중요한 아키텍처 스타일이 될 것이라 미래를 예측해 본다.
참고 사이트
좋은글 감사합니다
답글삭제정성스럽게 정리해주셔서 감사합니다.
답글삭제뿌리를 아는건 참 중요한 것 같습니다.
감사합니다. 좋은 글 읽고 갑니다.
답글삭제