[컴퓨터월드] 핸드메이드 커머스 플랫폼 ‘아이디어스’를 운영하고 있는 스타트업 백패커(대표 김동환)가 클라우드 네이티브 기업으로 한발 다가섰다. 기존 온프레미스 환경에서 운영하던 IT 시스템을 아마존웹서비스(Amazon Web Services, 이하 AWS) 클라우드 기반의 확장성이 뛰어나고 빠른 컨테이너(Container) 서비스인 ‘아마존 엘라스틱 컨테이너 서비스(Amazon ECS, Elastic Container Service)’로 옮긴데 이어 운영과 비용 효율성을 확보하고자 관리형 쿠버네티스(Kubernetes) 서비스인 ‘아마존 엘라스틱 쿠버네티스 서비스(Amazon EKS, Elastic Kubernetes Service)’로 고도화한 것이다. 백패커는 이러한 클라우드 전환 과정의 조력자로 AWS 전문 클라우드 관리 서비스 제공사(MSP) 솔트웨어(대표 이정근)를 선택했다. 백패커에서 IT 시스템 전반에 걸친 데브옵스(DevOps)를 담당하고 있는 하동현 리더를 만나 백패커의 클라우드 여정에 대해 자세히 들어봤다. 

확대되는 비즈니스, 클라우드로 따라잡았다

백패커는 손으로 직접 만든 작품을 작가가 직접 등록하고 판매할 수 있는 플랫폼인 ‘아이디어스(idus)’를 운영하고 있다. 글로벌 No.1 크리에이터 에코시스템이라는 목표 아래 창작자의 가치사슬을 혁신하며 비즈니스를 확대하고 있는 백패커는 아이디어스 플랫폼을 개발하는 조직과 운영하는 조직, 고객 관련 조직, 작가 관리 및 영입 조직, 기획 조직 등으로 구성돼 있다.

백패커의 누적 거래액은 7,600억 원을 돌파했고, 애플리케이션 다운로드도 1,550만 건에 달한다. 2018년 대비 아이디어스의 누적 거래액은 15배 이상 증가했다.

백패커는 회사가 고속 성장하면서 시스템의 효율적인 운영에 대해 고민하기 시작했다. 백패커는 비즈니스 초기 서버 2대에서 아이디어스 플랫폼을 운영했다. 하지만 서비스 이용자가 급격하게 늘어나며 플랫폼의 확장성을 확보해야 하는 문제에 직면했다. 백패커는 이에 대한 해결책으로 아마존웹서비스(AWS) 클라우드 서비스 도입을 결정했다. AWS의 클라우드 서비스로 확장성과 유연성을 확보해 비즈니스 성장에 대응하려 한 것이다.

사실 백패커가 처음부터 AWS를 사용한 것은 아니었다. 백패커 하동현 데브옵스셀 리더는 “AWS를 처음부터 사용하지 않고 타사의 클라우드 서비스를 활용했었다. 하지만 백패커의 급격한 성장을 구체적으로 지원해줄 수 있는 클라우드 서비스는 아니었다”면서, “다른 클라우드 서비스를 물색하기 시작했고, 그 과정에서 AWS의 다양한 도입 성공사례가 눈에 들어왔다. AWS가 우리의 비즈니스 성장을 뒷받침할 수 있을 것이라는 확신이 들었다”는 말로 AWS를 선택한 이유를 설명했다.

백패커는 ‘아마존 EC2(Amazon EC2, Amazon Elastic Compute Cloud)’와 같은 기본적인 IaaS을 비롯해 코드로 인프라를 구성할 수 있는 IaC 서비스 등 다양한 서비스를 도입했다.

백패커는 특히 도입한 AWS 서비스 중 플랫폼에 큰 영향을 주는 서비스로 AWS의 컨테이너 서비스인 ‘아마존 ECS’를 들었다. 컨테이너는 클라우드 네이티브 환경을 구현하기 위한 필수 요소로 꼽힌다. 컨테이너는 애플리케이션에 대한 수정부터 배포까지 컨테이너(기능) 단위로 개별화하고, SW를 구성하는 OS, 미들웨어 등의 요소를 컨테이너 별로 묶어 애플리케이션을 구동하는 기술이다. 특히 빠른 개발과 배포가 강점이다.

백패커는 ‘아마존 ECS’ 서비스를 활용해 기존 아이디어스의 기능들을 컨테이너에 분산함으로써 운영 환경을 개선했고 보다 빠른 기능 개발을 가능케 했다. ‘아마존 ECS’를 통해 보다 빠르게 플랫폼 내 개별 기능을 개발하고 배포할 수 있는 환경이 마련된 것이다.

컨테이너 서비스를 도입한 이유에 대해 하동현 리더는 “IT 혁신 차원에서 컨테이너 기술이 주목받고 있는 상황에서 우리가 이 기술에 관심을 갖는 것은 당연했다. 백패커는 ‘과하게 기술에 집착’하는 오버엔지니어링을 추구하는 회사로 서비스 혁신을 위해 투자를 아끼지 않는다”며, “AWS 이전에 사용했던 클라우드 서비스는 컨테이너 기반이 아니었다. 가상머신(VM) 위에서 아이디어스를 운영했다. 개발과 운영 측면에서 불편 사항들이 생기기 시작했다. 이를 컨테이너 기반으로 서비스를 이관한다면, 불편함을 해소할 수 있을 것으로 기대했다. 이러한 이유로 AWS로 이관할 때 ‘아마존 ECS’로 플랫폼을 구성했다”고 설명했다.

그는 “협력사를 통한 각종 기술과 교육 등의 지원이 필요한 상황이었기 때문에 AWS로 이전하면서 MSP 사업자 선정에도 신중을 기했다. 여러 MSP 기업을 검토한 결과 솔트웨어를 선택했다. AWS에 집중하면서 비즈니스를 확장하고 있던 솔트웨어와 백패커의 요구하는 바와 지향점이 일맥상통했다”면서, “실제로 솔트웨어는 오픈소스 영역을 포함한 전문 지원과 교육, 비용적인 측면에서 많은 도움을 줬다”고 덧붙였다.

‘아마존 EKS’로 컨테이너 운영 환경 혁신

백패커는 ‘아마존 ECS’ 기반 컨테이너 환경을 구현하는 것에 그치지 않고 보다 고도화된 쿠버네티스(Kubernetes) 서비스인 ‘아마존 EKS’를 도입했다. 백패커는 그동안 ‘아마존 ECS’를 통해 컨테이너로 다양한 서비스들을 담았고 이를 개선하는 작업을 꾸준히 수행한 결과 개발 측면에서의 민첩성과 효율성을 확보할 수 있었다. 하지만 늘어나는 컨테이너의 수만큼 운영 편의성과 개발자를 지원할 수 있는 서비스가 필요했다. 이에 백패커는 컨테이너를 자동으로 관리하고 조율해주는 AWS의 쿠버네티스 서비스인 ‘아마존 EKS’ 도입을 결정한 것이다.

쿠버네티스는 흔히 컨테이너 오케스트레이션 기능을 가진 플랫폼으로 컨테이너가 배포되는 VM 또는 물리머신인 ‘워커노드’와 워커노드의 집합체인 클러스터 전체를 관리하는 ‘마스터 쿠버네티스’로 구성돼있다. 또 쿠버네티스에 의해 배포 및 관리되는 컨테이너는 ‘포드(Pod)’라는 단위로 묶인다. ‘포드’는 하나 이상의 컨테이너를 포함하며, 같은 ‘포드’에 있는 컨테이너들은 서로 로컬 통신이 가능하고 디스크 자원도 공유할 수 있다.

이처럼 단순히 컨테이너 환경을 구현한 것을 넘어 운영의 효율성까지 고려해 쿠버네티스를 적용하기 위해선 많은 기술적 지식이 요구된다. 이와 관련, 하동현 리더는 “실제로 ‘아마존 EKS’를 제대로 사용하기 위해 많은 기술 지식이 필요하다. 이 과정에서 기술적인 부분에 대해서는 솔트웨어의 컨설팅, 기술지원을 받았다”면서, “이렇게 ‘아마존 EKS’로 구현한 쿠버네티스 환경은 컨테이너를 보다 잘 운영할 수 있는 기반이 됐다. 현재 애플리케이션을 실제 환경에 배포하는 속도도 향상됐고, 컨테이너 운영의 효율성이 늘면서 비용 측면에서도 크게 절감됐다. 아직 도입한 지 오래되지 않았지만 상당한 효과가 나타나고 있다. 시간이 지나면 효과는 더욱 더 커질 것”이라고 설명했다.

다음은 백패커 하동현 데브옵스셀 리더와의 인터뷰를 일문일답으로 구성한 것이다.

“‘아마존 EKS’로 전환, 도전의 연속이었다”

Q. ‘아마존 EKS’로 전환하고자 했던 이유는 무엇인가.
A. 컨테이너의 운영 효율성을 확보하고자 했다. ‘아마존 ECS’를 통해 컨테이너 환경을 구현했지만, 서비스 개선이 지속되면서 운영해야 하는 컨테이너의 수도 증가하기 시작했다. 시스템 복잡도가 늘어나는 만큼 개발 조직은 물론, 운영 조직의 관리에 부담이 증가했다. 이에 컨테이너의 관리를 효율화할 수 있는 플랫폼인 쿠버네티스를 눈여겨봤고, 가벼운 백그라운드 개념검증(PoC)을 통해 쿠버네티스를 적용하기 시작했다. 물론 이 과정에서 우리와 클라우드 여정을 함께하고 있는 파트너인 솔트웨어의 도움을 받았다.

Q. ‘아마존 EKS’로의 전환 과정에 대해 말해달라.
A. 처음엔 가볍게 백그라운드로 개념검증(PoC)을 했다. ‘아마존 ECS’를 잘 활용하고 있었기 때문에 ‘아마존 EKS’에 대한 기대가 높았다. 그만큼 많은 시도도 했다. 높은 기대 속에 다양한 시도를 함으로써 진행 속도가 더디기도 했다. 하지만 최소한 ‘아마존 ECS’에서 사용하던 기능들은 모두 ‘아마존 EKS’에 포함돼야 한다는 기준으로 이관 작업을 진행했고, 조금씩 구성을 갖춰 나간 뒤 솔트웨어와 협업해 부족한 부분을 보완했다.

Q. 전환하는 과정에서 기술적인 어려움은 없었는지, 또한 솔트웨어로부터 어떠한 도움을 받았는지.
A. 기술적인 어려움에 대해 보안과 배포 부분 사례를 통해 얘기해 보겠다. 먼저 보안 부분에서는 쿠버네티스와 웹 애플리케이션 방화벽(WAF)을 연동하는데 어려움이 있었다. 우리가 ‘아마존 EKS’를 도입하는 과정에서 WAF와 쿠버네티스를 연동하는 방법에 대한 고민이 있었고 WAF를 쿠버네티스 앞단에 붙이려고 했었다. 물론 인터넷 웹사이트에서 검색해보면 사례들은 쉽게 찾을 수 있다. 하지만 이러한 사례를 실무에 적용하기에는 굉장히 어려웠다. 이런 문제 해결에 WAF-쿠버네티스 연동 아키텍처 설계부터 구현하는 것까지 솔트웨어로부터 많은 도움을 받았다.

배포 부분에서는 일부 셀에서 애플리케이션 블루/그린(Blue/Green) 배포 전 그린에 붙어서 상태를 확인하고 싶다는 요구가 있었다. 처음에는 내부 접속에 대해 항상 그린 서비스를 보도록 설정하면 해결할 수 있겠다고 간단히 생각했었다. 하지만 막상 아르고(Argo)CD 롤아웃(Rollouts)의 배포 진행 순서에서 문제가 발생해 ‘리플리카(replica)’가 0인 상태에서 ‘그린 리플리카셋(Green replicaset)’에 트래픽이 흐르는 문제가 발생했다. 이는 내부망을 사용하는 조직 전체에 혼란을 줄 수 있기에 다른 방법을 찾아야만 했다. 많은 방법을 시도해봤고, 결국 오퍼레이터를 통해 해당 애플리케이션 그린 리플리카셋의 리플리카가 1개 이상인 시점에 내부 접속은 그린 서비스를 보게 해야 하는 단계까지 이르렀다.

결국 솔트웨어와 ‘아마존 EKS’ 업무를 진행하는 동료가 이스티오 버추얼 서비스(Istio Virtual Service)의 헤더 매치(header match)를 통해 해결하자는 아이디어를 냈고 애플리케이션 배포 전 그린에 붙어 상태를 확인할 수 있었다. 또한 MSA 도입을 하면 통신이 복잡해져서 서비스메쉬(Service Mesh) 도입이 필요한데 구성 및 설정이 매우 까다롭지만 이 부분 또한 도움받았다.

최근 ‘아마존 EKS’ 서비스에서 도메인 네임 시스템(DNS)를 해석하는데 어려움이 있었다. 하지만 이 역시도 솔트웨어가 기술적으로 해결할 수 있도록 도움을 줬다. 구체적으로는 우리가 제공한 로그를 솔트웨어가 진단한 후에 적절한 해결책을 제시해줬다.

마지막으로 쿠버네티스 스케일링에 관여하는 오픈소스 기술지원도 받았다. Descheduler는 불필요한 요소를 정리/정렬해주는 역할을 수행하며 Cluster autoscaler는 노드를 확장해준다. 자사인 경우 타이트하게 운영하기 위해 옵션 튜닝을 세밀하게 했는데 이러한 부분까지 솔트웨어에서 디테일하게 봐줬다.

Q. 컨테이너, 쿠버네티스를 활용하기 위해선 기존의 모놀리틱 아키텍처를 마이크로서비스 아키텍처(MSA)로 전환해야 하는 것으로 알고 있다.
A. 그렇다. 컨테이너 환경 구성 방식이 MSA 방법론과 잘 맞는다. 우리도 기존 모놀리틱으로 구성된 애플리케이션을 MSA로 전환하는 작업을 수행하고 있다. 미국의 클라우드 네이티브 기업으로 잘 알려진 넷플릭스도 7년에 가까운 시간을 투자했을 만큼 어려운 작업이다. 하나의 큰 덩어리 아키텍처에서 개별 기능을 잘게 나뉜 아키텍처로 바꿔야 한다. 어느 시점에 완전하게 MSA화 됐다고 말하기 어렵다. MSA화 과정에 있다고 봐야 한다.

현재 기존 애플리케이션에 영향을 주지 않도록 조금씩 덜어내는 작업을 수행하고 있다. 애플리케이션은 어느 한 부분을 수정할 경우 다른 부분도 영향을 받을 수밖에 없다. 최대한 영향을 주지 않게끔 조금씩 옮기고 있다.

Q. MSA로 옮기는 과정에서 우선순위는?
A. 비즈니스 핵심 기능부터 옮기고 있다. 가령 아이디어스 플랫폼에서 창작자가 판매하는 작품에 대한 도메인을 선제적으로 분리하거나, 플랫폼 회원에 관련된 부분을 예로 들 수 있다. 현재 우리는 지금 글로벌 진출을 준비하고 있는데, 글로벌 서비스와 관련해 신규 서비스는 MSA로 처음부터 분리해서 출시할 예정이다. 아직 옮기지 않은 서비스는 주로 검색과 관련된 서비스다. 이 역시 조만간 옮길 것이다. 준비는 끝난 상황이다.

“클라우드 최적화 통해 클라우드 네이티브 환경 구현”

Q. ‘아마존 EKS’로의 전환 후에도 최적화 작업을 꾸준히 수행해야 하는 것으로 알고 있다. 이 과정에서 솔트웨어의 ‘핏클라우드(Fitcloud)’라는 CMP툴을 사용한다고 들었다.
A. 최적화는 클라우드 도입이 끝나고 잠깐 하는 작업이 아니다. 꾸준히 진행해야 한다. 백패커는 자체적으로 모니터링 도구를 활용해 클라우드 리소스 활용을 진단하고 있다. 또한 솔트웨어가 개발한 ‘핏클라우드’라는 클라우드 관리 플랫폼(CMP)도 활용하고 있다. 핏클라우드는 클라우드 최적화에 필요한 다양한 기능을 갖고 있다. 리소스 활용 현황을 확인할 수 있는 메뉴가 있는데, 이를 적극적으로 활용해 리소스를 최적화하고 있다. 백패커는 서비스를 운영하면서 발견하는 모든 비효율적인 부분들을 개선하고 있다.

앞서 솔트웨어와 함께 ‘아마존 ECS’ 서비스에 대해서도 비용 최적화를 수행했다. ‘아마존 ECS’를 사용했을 때는 사용하는 만큼 비용을 할인 받을 수 있도록 예약 인스턴스(RI)로 구매해 사용하기도 했고, 애플리케이션이 운영되는 워커노드에는 스팟 인스턴스(SI)를 적용하기도 했다. 이 같은 노하우를 살려 ‘아마존 EKS’를 운영하며 비용 최적화에 집중하고자 한다.

우리가 클라우드 최적화에 집중하는 이유는 플랫폼을 이용하는 고객이 쾌적하고 빠르게 서비스를 이용할 수 있게 하는 데 있다. 비용을 절감해 서비스 향상에 투자한다면 고객들의 서비스 만족도는 더욱 높아질 것이다.

Q. 클라우드를 사용하기 위해선 기술 교육도 필요할 텐데.
A. 백패커는 솔트웨어를 통해 1달에 1~2회 AWS에 대한 기술 교육을 받고 있다. 실제 솔트웨어는 1년에 총 12번 정기적으로 교육을 실시하고 있다. 클라우드와 관련된 교육 6번과 시큐리티, 컨테이너, 머신러닝, AI 등을 주제로 6번을 진행한다. 솔트웨어는 AWS에서 발급하는 교육(Immersion Day) 인증을 획득한 것으로 알고 있다. 솔트웨어는 AWS에서 만든 문서로 이론 교육을 진행한 후 실습까지 연계해 교육하고 있다.

교육에 대한 회사 내부 피드백도 좋다. 현재 백패커에는 데브옵스셀 조직과 같이 컨테이너, RDS 등 복잡한 클라우드 서비스를 이해하고 있는 직원들이 있기는 하지만 AWS 서비스에 대해 이해하지 못하는 애플리케이션 개발자도 있다. 그런 상황에서 솔트웨어가 제공하는 교육을 통해 일반 애플리케이션 개발자부터 데브옵스셀 조직까지 모두가 만족하고 있다. 기초부터 심화까지 모두를 아우를 수 있는 교육을 제공하고 있다는 의미다.

“유휴 자원 활용율 높이고 비용 20% 절감”

Q. ‘아마존 EKS’로 전환하면서 기술적인 부문과 비용적인 부문에 대해 효과가 있었는가.
A. 기술적으로는 ‘아마존 EKS’로 컨테이너 운영 효율성을 높일 수 있었고, 클러스터 오토스케일러를 통해 전보다 나은 스케일링이 가능해졌다. ‘아마존 EKS’는 컨테이너가 EC2 인스턴스 안에서 운영되는데, ‘아마존 EKS’에서는 컨테이너를 배포하거나 관리할 때 부족한 공간이 생기면 ‘아마존 EC2’ 인스턴스를 자동으로 추가한다. 인스턴스가 자동으로 추가되는 메트릭(기준)은 CPU 사용량이다. 쉽게 말해 컨테이너에 적합하도록 유연하게 설정하기 어려웠다는 것이다.

실제로 ‘아마존 EKS’를 도입한 후에는 ‘파드’의 유휴 CPU 사용량이 ‘아마존 ECS’를 사용했을 때보다도 현저히 줄었다. 수치로 표현하자면 기존에는 70%를 사용했다면, 지금은 85~90%를 사용하고 있다.

다음으로는 다양한 배포 전략을 자유롭게 선택할 수 있게 됐다. 현재 테라폼을 통해 AWS 자원 전체를 코드화해서 인프라를 운영하고 있다. 하지만 기존 ‘아마존 ECS’ 안에서 운영되는 서비스에 대해서는 코드로 관리하기 어려운 부분이 있었다. ‘아마존 EKS’를 도입한 후 컨테이너 생성부터 관리까지 모든 것을 ‘깃(Git)’으로 관리할 수 있게 됐다. 현재는 기초적인 단계이지만, 꾸준히 개선하면서 반복적인 작업을 자동화하려고 한다.

비용면에서도 이점이 많았다. 아직 ‘아마존 EKS’에서의 최적화 작업 초기 단계임을 감안하면 향후 최소 20% 비용을 줄일 수 있을 것 같다.

Q. 추가 도입을 고려하고 있는 클라우드 서비스가 있다면 소개해달라.
A. 서버리스 서비스에 주목하고 있다. 이미 많은 애플리케이션이 컨테이너화 됐지만, 아직 대부분이 ‘아마존 EC2’ 인스턴스 위에 운영되고 있다. 보다 높은 유연성과 가용성을 확보하기 위해 ‘AWS 람다(Lambda)’와 ‘AWS 파게이트(Fargate)’ 등 서버리스 서비스에 관심을 갖고 있다.