마이크로서비스를 위한 AWS 빌딩 블록 이해하기

2006년부터 아마존닷컴은 쇼핑몰 서비스를 마이크로서비스 단위로 서비스를 분리하여 이를 API 인터페이스를 가지도록 하는 아키텍처를 도입하고 실제 서비스에 적용하였다. 아마존닷컴 CTO인 버너 보겔스(Dr. Warner Vogels)박사의 2006년 인터뷰를 인용해 보자.

“아마존닷컴은 10년전 (1995년) 웹 서버와 데이터베이스 백엔드를 가지는 모놀리식(Monolithic) 애플리케이션으로 시작하였습니다. 5년전(2001년) 아마존은 주요한 아키텍쳐 변화가 있었는데 2 티어(tier)기반에서 서로 다른 애플리케이션 기능을 제공하는 분산 서비스 플랫폼으로 변화하였습니다… 여러분이 지금 Amazon.com의 첫화면에 들어온다면, 그 페이지를 생성하기 위해 100여개가 넘는 서비스를 호출하여 만들고 있습니다.” A Conversation with Werner Vogels , 2006

아마존에서는 이러한 인터페이스를 가지는 각 서비스를 재료(Primitives)라는 용어로 부른다. 어떤 애플리케이션을 완성하기 위한 원료 혹은 재료로서 이를 빌딩 블록으로 조립하여, 원하는 서비스를 만들 수 있는 구성 요소를 말한다. 마치 레고블럭을 조립하여 우리가 원하는 모양의 레고를 만들 수 있는 것과 같은 원리이다

■마이크로 서비스를 위한 빌딩 블록 철학

아래 그림은 현재 아마존닷컴을 이루고 있는 수 천 개의 서비스들이 서로 어떤 연관 관계가 있는지 의존성에 대한 부분을 연결한 아키텍처이다. 수많은 점들이 서로 연결되어 있는 이러한 아키텍처 모양은 최근 마이크로 서비스 구조에서 자주 인용되는 모양이라고 할 수 있다.

아마존닷컴의 마이크로 서비스 간 의존성을 나타낸 아키텍처 지도 (2009)

2006년에 시작된 아마존웹서비스(AWS) 역시 이러한 아키텍처를 기반으로 서비스를 만들고 있다. AWS에서도 컴퓨팅, 데이터베이스, 스토리지를 비롯하여 모바일, 데이터 분석 등 다양한 영역에 세분화된 50여가지가 넘는 서비스를 제공하고 있으며, 그 서비스 역시 더 세분화된 서비스로 구성되어 있는데, 모든 기능은 API로서 호출이 가능하다.

즉, 사용자들이 사용하는 AWS 관리 콘솔, AWS 명령어 인터페이스(Command Line Interface), 그리고 언어별 SDK를 통해 API호출을 할 수 있다. 이제 AWS 사용자들은 필요로 하는 비즈니스 혹은 기술적 요구 사항을 AWS 서비스를 조합함으로 해결할 수 있고, 아마존닷컴과 마찬가지로 AWS 역시 원하는 애플리케이션을 만들기 위한 서비스 기반 빌딩 블록 철학이 자리잡고 있다.

그렇다면, 이러한 아마존닷컴의 많은 개별 서비스를 어떤 개발 조직과 문화로 만들고 있을까? 여기서 그 유명한 아마존의 '피자두판의 법칙'(Two Pizza Team)이 나온다. 즉, 가장 이상적인 팀의 크기는 피자두판으로 한끼를 때울 수 있는 인원으로 다수의 인원이 참여해야 하는 프로젝트라도 소수의 팀으로 나누어 구성하여, 각각의 작은 팀이 세부 기능에 대해 책임감과 투명성, 열정을 갖고서낮은 커뮤니케이션 비용으로 전담할 수 있게 한다. 즉, 분산된 독립적인 책임감과 주인의식을 갖는 팀에 의해 서비스가 만들어진다는 의미이다.

■독립된 데브옵스팀을 통한 서비스 개발 문화

하나의 작은 서비스에 작은 인원이 개발을 하고, 이를 개발부터 배포 및 운영 및 장애 처리까지 가능 하려면 필요한 것은 무엇일까? 바로 개발과 운영(DevOps)에 드는 많은 비용을 자동화 하고 시스템적으로 해결하는 도구를 제공하는 것이다. 아마존에서는 이를 위해 AWS를 통한 클라우드 인프라뿐만 아니라 많은 개발 및 배포 도구를 갖추고 있다.

예를 들어, 아마존에서는 10여년 전 다운타임 없이 개발 배포를 자동으로 진행하고, 헬스 체크 및 간편한 대시보드를 보유한 아폴로(Apollo)라는 내부 배포 시스템을 개발했다. 이 시스템은 배포 버전 관리 및 롤백에 대한 기능도 가지고 있다.

“수천명의 아마존 개발자들은 매일 Apollo를 사용하여, Java, Python, Ruby 앱을 웹 서비스로 네이티브 코드 서비스로 배포하고 있습니다. 지난 12개월 동안 Apollo는 5천만번이 넘는 개발, 테스트 및 정식 서버로 배포가 진행되었습니다. 이는 초당 한번 평균 한번 이상의 배포횟수입니다. “Werner Vogels, The Story of Apollo - Amazon’s Deployment Engine, 2014

코드 배포뿐만 아니라 테스트부터 정식 서비스까지 각단계에 어떤 배포 단계를 가지는가도 SW 테스트에 매우 중요하다. 아마존은 7년전 내부시스템에서 코드커밋에서부터 정식서비스까지 걸리는 시간을 측정했는데, 개발도구를 쓰는시간보다 프로세스상에 승인, 피드백, 알림 등을 하는 사람이 하는 일에서 시간이 많이 걸린다는 점을 알게 됐다. 이에 소스, 빌드, 테스트, 배포단계별로 사람의 영향을 최소화하는 파이프라인(Pipeline)이라는 도구를 개발했다. 이를 통해 알파, 베타, 정식 서비스 등 확장된 단계가 있더라도 자동화된 출시 과정을 거칠 수 있게 되었다.

이른바 출시 자동화라는측면에서 현재 회자되고 있는 전통적인 의미의 지속적 배포(Continuous Deploy) 및 지속적 통합(Continuous Integration)을구현하는 내부 제품이다. 이를 통해 수천개의 아마존 내부팀은 마이크로서비스 아키텍처를 기반으로 자동화된 개발도구를 사용하여 자동화된 배포를 통해 서비스를 빠르게 출시하고 지속적인 혁신을 이룰 수 있었다.