명품 직구족이라면 잘 아는 ‘길트(Gilt)’는 가장 성공한 핫딜 쇼핑몰업체다. 길트는 2007년 서비스 시작 후 연매출 6억달러 규모 전자상거래업체로 성장했다. 회원에게 제공하는 파격적인 명품 세일판매가 길트의 인기비결이다.
길트는 미국 동부시간 기준으로 매일 정오에 특별 할인판매를 한다. 회원에게 정식 할인가에 추가 혜택을 받을 수 있는 쿠폰을 제공하면서 구매자를 끌어들인다. 이같은 사업모델에 길트의 IT조직은 순식간에 폭증하는 트래픽을 감당하면서, 효율적으로 서비스를 관리할 수 있는 탄력적인 인프라를 운영해야 한다.
지난달 길트의 엔지니어링 수석부사장인 아드리안 트레나만은 아마존웹서비스(AWS) 리인벤트2015 컨퍼런스에서 자사의 마이크로서비스 구축 사례를 발표했다. 그는 길트 서비스의 시작부터 현재에 이르는 마이크로서비스 도입기를 소개했는데, 서서 들어야 할 정도로 주목을 끌었다.
그는 2009년 3월 12일 하루의 길트 서비스 트래픽을 제시했는데, 5천 미만인 트래픽이 오후 3시에서 4시 사이에 분당 4만 이상으로 치솟는 모습이다. 폭증했던 트래픽은 오후 4시 이후 급전직하한다.
길트는 2007년 만들어질 때 ‘루비온레일즈(Ruby on Rails)’로 웹애플리케이션을 만들었다. 데이터베이스는 포스트그레SQL을 사용했고, 멤캐시(Memcache)로 캐시 환경을 구성했다. 루비온레일즈가 빠르게 서비스를 만들 수 있기 때문에 사용됐다고 한다.
그는 “루비온레일즈는 쉽고 빠르게 개발할 수 있지만, 사용자 경험에 문제가 많았다”며 “언젠가 한 명품을 할인판매했는데, 너무 많이 몰려서 서비스가 다운되고 말았다”고 말했다.
빠르게 성장하던 길트는 2011년 자바를 이용해 백엔드 서비스를 구축했다. 약 10개의 서비스가 자바로 만들어졌다. 뒷단의 각 시스템에서 처리하는 계층과, 콘텐츠 및 페이지를 조립해 웹애플리케이션에 노출해 주는 계층이 있다.
그는 “프로덕트서비스, 유저서비스, 카트 서비스 등 10개 서비스 각자가 매우 거대한 일체형 자바 앱이었다”며 “백여명의 엔지니어가 각 서비스에 매달리는데, 현업시스템을 혁신하기까지 많은 병목이 존재하고 오래걸렸다”고 설명했다.
그는 “하나의 마케팅 메시지를 가입자에게 전송하는데, 페이지 생성 서비스가 킬로바이트의 JSON 데이터를 프론트엔드에서 조합하게 된다”며 “단 하나의 문장만 틀려도 서비스 오류가 났다”고 덧붙였다.
갈수록 서비스가 거대해지면서 관리에 어려움을 겪었다고 한다. 서비스 일부분만 바꾸려 해도 오랜 시간 개발 공수를 들여야 하고, 시스템 전체를 업데이트해야 했다. 더 작은 서비스가 필요해졌다.
그는 “어떻게 우리의 팀이 전략적으로 움직일 수 있는지, 어떻게 빠르고 쉽게 현업시스템을 바꿀 수 있을지 고민했다”며 “그렇게 올해 마이크로서비스로 완전히 전환했다”고 말했다.
길트의 마이크로서비스 아키텍처는 32개의 내부용 툴 애플리케이션과 156개의 마이크로서비스로 이뤄진다. 프론트엔드는 자체 웹애플리케이션 개발프레임워크인 ‘플레이(play)’로 5~9개의 앱 서비스로 만들었다. 마이크로서비스는 추천, 이메일, 알림, 계산, 배송 등등의 여러 비즈니스 로직을 각각 담는다. 서비스의 개발환경은 자바뿐 아니라 스칼라, SBT 등 다양한 기술을 혼용했다.
그는 “각 팀은 자주적으로 기술과 툴, 프로세스를 택하고, 목표중심으로 업무를 추진한다”며 “빠르면서 개방적으로 실패하고, 어려울 때조차 가장 개방적이고 현명하게 행동하자는 생각을 공유한다”고 말했다.
단일 JVM 머신이 하나의 마이크로서비스를 이룬다. 각 머신은 프레임워크, 코드, 모니터링, 로깅 등을 담고 있다. 데이터는 독립적인 저장소에 쌓는다.
그는 “데이터스토어는 각 JVM 머신이 자체적으로 보유하는 형태”라며 “수백개 서비스가 하나의 DB를 공유하게 만드는 건 나쁜 생각”이라고 밝혔다. 이어 “DB를 여러 서비스가 공유하면, 스키마 한개만 바뀌어도 전체 마이크로 서비스를 붕괴시킬 수 있다”고 덧붙였다.
코드는 자바, 스칼라, 자바스크립트 등을 개발팀 취향에 맞게 사용한다. JVM이 아니라 노드JS를 사용하는 것도 가능하다.
단일 마이크로서비스의 코드 라인은 그리 많지 않다. 소스파일 용량도 크지 않다. 덕분에 마이크로서비스 내부에서 어떤 상황이 벌어지는지 쉽게 파악할 수 있게 됐다.
고가용성과 탄력성을 위한 서비스 디스커버리 모델은 간단하게 만들었다. 클라이언트가 로드밸런서를 거쳐 서비스를 이름으로 검색한다. 주키퍼가 사용됐다.
길트는 미국 내 2곳의 데이터센터에서 베어메탈 서버 기잔으로 서비스르 제공했었다. 그리고 올해 AWS 클라우드로 서비스를 모두 이전했다. 이전 작업은 3개월만에 완료됐다.
이전 작업은 데이터센터를 10기가비트이더넷, 2밀리초 레이턴시 네트워크로 AWS 가상프라이빗클라우드(VPC)에 연결해 진행됐다. 길트의 IT팀은 담당 서비스를 AWS에서 운영하는데 범용계정, 모바일, 개인화, 관리, 데이터 등 조직별로 계정을 사용한다. 각 팀은 데브옵스(DevOps)로 운영된다.
길트의 각 마이크로서비스는 여러 개의 AWS EC2 인스턴스에 담겼다. 그는 “하나의 마이크로서비스가 단일 EC2 인스턴스에 담겼다”며 “같은 박스에 여러 서비스 워크로드를 담는 건 나쁜 생각”이라고 밝혔다.
각 서비스는 도커 컨테이너로 만들어졌다. 그는 “도커는 빠르게 컨테이너를 배포할 수 있고, 서비스 가시성이 좋다”고 말했다.
서비스 디스커버리는 일부 요소만 AWS 기능으로 교체했다. 주키퍼를 계속 사용하고 HA와 폴트톨로런스를 위한 로드밸런서만 ‘AWS 엘라스틱로드밸런서(ELB)’로 바꿨다.
인스턴스 크기는 T2 마이크로와 스몰, 미디엄 위주로 사용한다. 마이크로서비스는 매우 작은 크기로 만들게 되므로, 하나의 서비스가 대규모 자원을 필요로 하지 않는다. 굳이 높은 사양의 비싼 인스턴스를 쓰지 않고, 저가 저사양 인스턴스를 다수 쓰는 게 좋다는 설명이다.
그는 “마이크로서비스 구축에 사용되는 AWS EC2 인스턴스로 T2마이크로와 T2스몰의 비중이 가장 높다”며 “JVM 하나를 한 인스턴스에 집어넣기 때문에 매우 저렴한 시스템을 많이 사용할 수 있어 만족스럽다”고 밝혔다.
관련기사
- AWS의 PaaS 진화, 키포인트는 ‘컨테이너’2015.11.05
- VM웨어, 마이크로서비스 본격 행보2015.11.05
- 오픈스택 설립자가 본 클라우드와 PaaS2015.11.05
- MS 애저 PaaS가 남달라 보이는 이유2015.11.05
길트는 마이크로서비스 도입을 통해 팀 간의 의존성을 없앴다. 코드를 빠르게 만들어 현업시스템으로 보낼 수 있게 됐다. 여러 시도가 병렬적으로 진행되며, 각 팀은 선호하는대로 사업을 진행할 수 있다.
클라우드까지 도입하면서 길트 IT팀은 데브옵스 체제로 전환됐다. 그는 “데브옵스는 AWS 다이나모DB나 키네시스 같은 새로운 기술에 대한 장벽을 낮추는 훌륭한 방법”이라며 “무엇보다 클라우드를 통해 비용 가시성이 좋아졌는데, 지난주 장바구니담당 엔지니어가 비용을 절반으로 줄였다고 보고했다”고 강조했다.