글로벌 칼럼 | 2015년은 ‘마이크로서비스’의 해

서비스(역주: 마이크로서비스 아키텍처에서는 각 컴포넌트를 서비스(Service)라 지칭한다)로 애플리케이션을 구축하는 아이디어는 항상 매력적으로 들린다. 표준 API를 사용해서 동일한 서비스를 이용하는 애플리케이션을 만들 수 있는데 굳이 처음부터 개발할 이유는 없다. 이와 같은 서비스가 제대로 공급되기 위해서는 매우 놀라운 ‘규모의 경제’를 즐길 수 있어야 한다.

과거에 이러한 개념을 구현하기 위한 시도는 있었으나 개발 작업이 과도하게 많아지는 탓에 실패로 돌아가고 말았다(대표적으로는 CORBA와 SOA가 있다). 그러나 크기도 작고, API 스러우며, 단일 구조로 이뤄진 마이크로서비스에 관한 가장 흥미로운 점 가운데 하나는 개발자로부터 시작됐다는 점이다. 최근 들어 마이크로서비스에 관한 관심이 높아지고 있다.

실제로 마이크로서비스 아키텍처를 적용한 좋은 예시를 들어보고자 한다. 소비자용 와이파이 핫스팟 기기를 판매하는 업체인 카르마(Karma)의 CTO이자 공동창립자인 스테판 보르제의 블로그를 확인하면 된다. 보르제는 블로그를 통해 자사 개발팀이 마이크로서비스 아키텍처를 적용하여 온라인 스토어를 개발했다고 전했다.
 

우리는 백엔드 애플리케이션을 개발했으며, 이를 의미 있는 조각으로 나눴다. 개발하기에 앞서 우리가 당면한 과제에 우선 친숙해지고자 했으며, 문제를 더 자세히 파악할수록 앱을 어떤 단위로 나눠야 할지를 명확하게 알게 됐다. 조각으로 나눠야 할 구간을 발견하면 우리는 이를 하나의 서비스로 쪼갰다.

물론 처음에 이런 조각들의 크기는 상대적으로 컸지만, 마이크로서비스를 채택함에 따라 우리는 이러한 조각들이 더 작아질 수도 있다는 사실을 알게 됐다.

 

- 스테반 보르제의 블로그 원문 가운데 일부 발췌

예를 들자면, 본래 모놀리식 앱에 있던 ‘저장’ 컴포넌트를 주문 처리, 실행 및 서비스 추적으로 쪼개는 것이다. 보르제 개발팀은 프론트엔드 애플리케이션도 서비스 단위로 나눴다고 덧붙였다. 보르제는 “특정 기능을 세분화된 독립적인 서비스로 분리하는 것은 생산성 향상에 큰 도움이 됐다”고 말했다. 부분적으로는 개발자가 모놀리식 애플리케이션의 모든 종속성을 유지할 필요가 없기 때문이다.

현재 카르마는 마이크로서비스의 가장 중요한 문제를 테스트하고 있다. 보르제는 “작업의 최종 결과는 정확한 원인과 결과를 상당히 알기 어려운 수준이다. 문제는 연쇄적으로 발생하는데, 어떤 지점이 잘못됐는지 파악하기가 어렵다”고 말했다.

애자일 소프트웨어 개발 선언문(Agile Manifesto)의 선언자 가운데 한사람인 마틴 파울러는 마이크로서비스 테스트에 관해 상당히 자세한 다양한 접근 방식을 개략적으로 발표하기도 했다. 파울러는 개별 서비스 단위의 테스트를 지지하지만, 이 전체 시스템이 제대로 작동하는지를 확인하기에는 충분하지 못하다는 점을 인정한다. 파울러는 마이크로서비스의 가장 어려운 문제를 풀기 위해 개발자가 머리를 맞대는 데 도움이 되는 일련의 통합, 컴포넌트, 컨트랙트(Contract), 종단 간 테스트 전략을 펼친다.

또 다른 문제가 있다. 어떤 마이크로서비스로 트래픽이 몰릴지를 항상 예측할 수 없다는 것이다. 이 때문에 카르마도 자사의 전자상거래 플랫폼을 AWS(Amazon Web Service)에 배치한 것으로 보이는데, AWS의 오토스케일링(Autoscaling)은 그 어떤 서비스라도 부하가 늘어나면 자동으로 서버를 늘리거나 줄이는 기술로 병목현상을 확실히 없애는 데 도움된다. 즉, 마이크로서비스와 클라우드는 일종의 동반자 개념이라고 보면 된다. 이론적으로는 VM웨어나 오픈스택(OpenStack)을 사용하여 오토스케일링 폐쇄형 클라우드를 구축할 수 있으나, 기술적인 어려움 때문에 공용 클라우드가 공고한 지위를 확보하고 있다.

마이크로서비스의 기초가 되는 또 다른 최신 기술에는 도커(Docker)가 있다. 도커는 애플리케이션 패키징 및 리눅스 컨테이너로 배포하기 위한 기술이다. 이처럼 마이크로서비스와 도커는 완벽한 조합이며, 대다수의 공용 클라우드가 현재 도커를 지원하는 이유이기도 하다.

물론, 마이크로서비스가 모든 문제를 해결해줄 수 있는 것은 아니다. 그러나 다른 서비스 기반의 접근 방식이 실패한 전적이 있기는 하지마는, 개발자로부터 시작된 방식이기 때문에 성공을 거둘 가능성이 있다. 개발자가 서비스 및 단위 유형을 결정하고, 규모가 큰 기업으로 트렌드가 확산됨에 따라 개발팀은 자신의 조직에 가장 적합한 서비스를 결정할 수 있다.

마이크로서비스 아키텍처에 기반한 개발은 과거의 유선환경이었다면 불가능했을 일이다. 마찬가지로 개발자의 성숙한 공동 작업 태도 또한 이러한 트렌드를 양산하는 데 일조했다. 상명하달식 명령을 그대로 따르기보다는 유기적으로 소프크웨어 아키텍처를 창조할 수 있는 문화로 바뀐 덕분이다.

실제로 많은 기업에서 근무하는 개발자들은 관리자의 의사에 상관없이 이미 마이크로서비스 아키텍처를 적용하고 있다. 공공 또는 폐쇄형과 관계없이 적절한 클라우드 인프라를 갖추고 마이크로서비스 아키텍처를 적용한다면 개발자의 생산성을 높이는 데 도움이 될 뿐만 아니라, 공수가 낮았던 애플리케이션의 개발도 가능하게 될 것이다. editor@itworld.co.kr