무신사가 가고 있는 클라우드 네이티브 여정

잘나가는 온라인 패션 커머스 플랫폼 기업 무신사의 IT 인프라는 어떻게 구축돼 있을까. 2009년 이커머스 사업을 본격 시작한 뒤 지난 10년여간 급성장 가도를 달려온만큼 서비스를 뒷받침하는 IT 인프라도 그동안 많은 변화가 있었을 것이라는 점을 예상할 수 있다.

무신사는 지난 2019년 퍼블릭 클라우드 서비스로 전환했다. 물리적 IT 인프라를 운영하다 아마존웹서비스(AWS)로 이전했다.

당시는 무신사의 대표 서비스인 무신사스토어의 회원과 입점 브랜드, 거래 규모가 가파르게 성장하던 와중이었다.

현재 무신사스토어의 회원수는 840만명 이상, 입점 브랜드 수도 6000개가 넘는다. 무신사스토어가 갓 출시된 해인 2011년 무신사닷컴의 회원수는 39만명, 입점 브랜드는 100개였던 것에 비하면 매우 가파른 성장세다. 그에 맞게 연간 총 거래액도 급증했다. 2013년 거래액 100억원을 처음 돌파한 데 이어 2018년 4500억, 지난해에는 1조원을 넘었다. 2020년 총 거래액은 1조4000억원이다.

엄청난 성장세만큼 온라인 트래픽 규모도 계속 증가한 것은 물론이다.

“2019년 무신사는 물리서버 기반으로 서비스를 제공해왔다. 계속 증가하는 트래픽을 감당하기 어려워지면서, 해결 방안으로 클라우드 마이그레이션 프로젝트를 진행했다. 빠르게 진행하기 위해 리프트앤시프트(Lift and Shift) 전략을 취했고, EC2 RDS 등 단순한 모델로 구성했다.”

심호진 무신사 SRE 파트 리더는 지난달 온라인으로 열린 CNCF(Cloud Native Computing Foundation) 코리아 주최 행사인 ‘쿠버네티스 커뮤니티 데이(KCD)’에서 당시를 이렇게 회상했다.

무신사는 2019년 초부터 시작해 11월 블랙 프라이데이 전에 이전 작업을 마쳤다.

심 리더는 “짧은 기간 동안 전환을 진행해 2019년 11월 블랙 프라이데이 기간에는 순탄치 않았다. 첫 트래픽 유입부터 장애가 발생했다. 이를 계기로 인프라뿐 아니라 애플리케이션도 클라우드 네이티브 환경으로 전환하는 것이 필요하다고 뼈저리게 느꼈다.”

이듬해부터 무신사는 본격적인 클라우드 네이티브 여정에 돌입했다. 먼저 개발조직을 중심으로 마이크로서비스아키텍처(MSA)로 전환했고 서버리스(Serverless) 환경도 일부 활용했다. SRE 파트에서는 인프라 전반에서 클라우드 환경에 최적화하기 위한 작업을 지속했다. 2020년 다시 돌아온 블랙프라이데이, “이 때는 장애가 거의 없이 서비스할 수 있었다”는 게 심 리더의 얘기다.

현재 무신사는 퍼블릭 클라우드에서 제공하는 관리 기능을 최대한 활용하고 있다. 올해 초에는 쿠버네티스 기반의 컨테이너 환경 도입을 진행했고, 서버리스 활용도 더 늘어났다.

그는 쿠버네티스를 사용하게 된 이유로 먼저 쉽고 빠른 애플리케이션 배포를 들었다. “20019년 클라우드 전환 이후 누적 배포량이 크게 늘어났다. 연 3만9500회, 일간으로는 평균 108회 서비스 배포가 이뤄지고 있다. 애플리케이션 개발팀은 모놀리스 구조에서 MSA 구조로 계속 전환 중인데 기대하는 배포 증가량에 비해 실제 배포 증가량은 떨어지는 상황이었다. AWS 코드 파이프라인을 기반으로 배포하게 되는데 총 들어가는 배포 시간이 15분 내외였다. EC2 기반의 느린 배포 속도로 잦은 서비스 배포가 어려우니 개발팀에서는 통합 배포를 선호하게 됐다. 이는 코드 복잡성과 영향도를 키워 서비스 장애를 야기하는 결과를 내기도 한다.”

당시 SRE 파트에서는 테라폼과 엔서블을 이용한 인프라 프로비저닝을 선호하고 있었다고 한다. “코드 기반으로 관리하니 변경 추적이 쉽고 실수도 방지하기 좋고 기타 파이프라인 도구와 합쳐서 사용할 때 인프라를 자동화할 수 있다. 자동화를 통해 생산성을 향상시키고 적은 코드로 많은 리소스 형상관리가 가능하다”는 게 이유다.

하지만 개발팀에서는 새로운 문법 사용방법을 터특해야했고 퍼블릭 클라우드를 잘 알지 못하는 상황에서 테라폼 등을 효과적으로 사용하기 어려웠던 문제가 있었다. 이들의 관심사는 비즈니스 요구사항 어떻게 해소할지, 클린 코드를 어떻게 작성할지, 또는 MSA 아키텍처를 어떻게 전환할지 등이었다. 그러다보니 사일로 환경이 계속 유지되는 상황이었다.

이는 무신사가 일부이긴 하지만 메니페스트(Manifest) 관련 공동 관리형 모델로 전환하는 계기로 이뤄졌다. “개발팀에서 접근하기에 어렵지 않았고 이해하고 사용하기 변했다. 메니페스트 수정 후 푸시하면 배포돼 파이프라인이 실행되고 짧은 시간 안에 쿠버네티스 리소스까지 반영됐다.”

서비스 어카운트, 스토리지, RBAC(Role-Based Access Control) 등 개발팀이 직접 관리하기 어려울 수 있거나 권한이나 보안 영향이 큰 영역은 의도적으로 SRE 파트가 전담하도록 의도적으로 분리 관리하도록 지정했다.

무신사는 인프라를 클라우드 네이티브로 운영할 수 있도록 도움이 되는 다양한 기술을 사용하고 있다. 예를 들어 모니터링 에이전트나 사이드카(Sidecar) 인젝션을 사용하고, 컨트롤러 오퍼레이터를 개발해 인프라 운영 효율을 높일 수 있도록 하고 있다. 심 리더는 “CNCF에 등록돼 있는 수많은 인큐베이팅(incubating) 그레주에이티드(Graduated) 프로젝트들은 클라우드 네이티브 여정을 가속화해주기 때문에 사용을 마다할 이유가 없다”고 표현했다.

쿠버네티스 도입 후 두드러진 변화는 무엇일까. 일단 서비스 배포 파이프라인이 변경됐다. 초기 빌드 단계는 기존과 유사하게 젠킨스에서 도커 빌드를 했지만 그 다음 단계부터 이미지 푸시하고 테스트하고 롤백 업데이트 후 다시 배포 등은 모두 달라졌다. 그 결과 이전에 서비스 배포에 소요되던 시간이 15분에서 7분으로 줄었다. 53%의 속도가 개선된 결과를 얻었다.

테라폼과 엔서블로 관리하던 영역은 쿠버네티스 관리 영역과 충돌하거나 중첩돼 대거 줄었다.

프록시를 통한 트래픽 흐름 제어나 애플리케이션프로그래밍인터페이스(API) 보안 관련 잇점도 기대하고 있다.

현재 관측성과 분석(Observability&Analysis) 영역 고도화를 진행하고 있다. 단순 모니터링이나 로그 수집을 넘어 오픈 텔레메트리 기반 분산 추적(Distributed Tracing) 기능을 도입 중이라는 설명이다.

그는 “개발팀에서 서비스를 개발하다보면 겪게 되는 다양한 문제들이 있다. 쿠버네티스를 도입하면서 EC2 환경에서는 해결하지 못했던 것들을 손쉽게 해결했다”며 “하지만 아직 갈 길이 멀다. 서비스 메시는 넘어야 할 큰 산이고, 컨테이너 보안 문제는 기존 운영체제(OS)와는 다른 위협이어서 새롭게 극복해야 할 과제”라고 말했다.

심 리더는 다만 “쿠버네티스 통한 클라우드 네이티브 여정이 과연 올바른지 의심하지 않았다. 이미 물리적 환경에서 퍼블릭 클라우드 전환 때 단순 총소유비용(TCO) 분석만으로 올바른 결과를 알아냈고 유연한 클라우드 인프라 환경에 대한 충분한 가치를 맛봤다. 개발조직 문화에도 영향을 미쳤다. 이를 위해서는 소프트웨어 구조 변화도 함께 해야 극대화될 수 있을 것”이라고 강조했다.

글. 바이라인네트워크
<이유지 기자>yjlee@byline.network