트렌비의 기술스택 이야기

트렌비 창업 당시에는 쇼핑몰을 처음부터 만드는 결정을 내리기는 어려웠습니다. 이 비지니스가 제대로 동작될 수 있을지 먼저 테스트 해보는 것이 가장 중요했기 때문입니다. 그래서 고도몰이라는 쇼핑몰 솔루션을 이용했습니다.

그러다가 1년이 지나서 트렌비는 급격한 성장을 그려낼 수 있었고 비지니스에 확신을 가지고 개발자를 채용하기 시작했습니다. 2017년 가을 5명의 개발자를 구성하고, 본격적으로 어떤 트래픽이 몰려와도 끄떡없는 아키텍처를 설계하기로 마음먹게 된 것이죠. 더불어 Front-end에서도 충분히 매력적이고 빠른 웹사이트를 만들어보자고 다짐했고 개발팀이 셋업되고 1년 반이라는 시간에 거쳐서 트렌비 웹사이트와 저희 자체적인 백오피스 시스템까지 개발할 수 있었습니다.

트렌비의 기술스택은 먼저 다음과 같습니다.

그럼 한가지씩 스택을 살펴보도록 하겠습니다.

프론트엔드

저희의 Front-End의 기술은 리액트를 채택했습니다. 솔직히 M.E.A.N. 스택과 같은 Angular 도 있었지만, 리액트 만큼 잘 짜여진 프레임워크라고 생각이 들기 어려웠습니다. 리액트만 가지고서는 할 수 있는 것들이 제한적이기 때문에 보일러플레이트와 리덕스를 도입하여 다양한 기능들을 구현할 수 있었습니다.

리액트의 싱글웹 페이지는 모바일 앱에 올려도 네이티브와 분간이 어려울 정도로 빠른 속도를 보여줄 수 있습니다. 저희는 웹이 모바일 앱에 올라가는 것은 느리다는 선입견이 강했기 때문에 네이티브 앱을 개발하고 있었는데요. 테스트로 앱에 올려본 뒤에 이렇게 빠를 수가 있을까? 싶은 부분에서 큰 고뇌에 빠지기도 했습니다.

지금은 네이티브 앱과 더불어 리액트를 개발할 수 있는 프론트엔드 개발자들과 웹 퍼블리셔가 트렌비의 UI를 위해서 노력해주시고 있습니다.

백엔드

백엔드는 큰 고민없이 Java를 선택했습니다. 자바를 선택한 이유는 크게 두가지가 있습니다. 첫번째는 트렌비가 스케일업을 할때 개발자들을 얼만큼 빠르게 채용할 수 있는가 였습니다. 물론, 좋은 개발자들은 언어가 크게 중요하지 않다는 것을 알지만, 그래도 갑자기 GO나 스칼라를 하라고 하면 약간의 런닝 타임을 가져야 하고 더불어 약간 평범한 개발자들은 채용하기 어려워진다는 한계를 바로 인지하고 있었습니다.

두번째는 안정성을 위해서 Java를 선택하였습니다. 지금이 어느시기에 안정성 이야기를 하냐고 할 수 있지만 시스템 운영에서 가장 어려운 것이 아무 이유없이 죽어나가며 이상동작을 보이는 부분을 접할때 해결할 수 있는 리소스가 얼만큼 있느냐? 아니면 얼만큼 비슷한 현상을 만나봤느냐가 굉장히 중요합니다.

개인의 역량 탓일수도 있겠지만 이전 스타트업에서 Node를 사용한 적이 있었는데 트래픽이 넘치면서 이상동작을 보이는 순간 많이 해맸던 경험이 있습니다. 그래서 백엔드는 조금 더 보수적인 기술 스택을 선택할 수 밖에 없었습니다.

참고글: 스타트업에서는 어떤 기술을 이용해야 할까?

백엔드는 API 서비스를 지원하는 부분과 관리자 시스템을 개발하고 있습니다. 데이터를 조회하는 부분에서는 스프링 붓을 이용하고 있습니다. CI 솔루션으로는 젠킨스와 팀씨티를 이용하고 있습니다.

.NET이라는 기술이 보일텐데요. 이 부분은 C#을 이용해서 크롤링 시스템을 운영하고 있습니다. 처음부터 빠르게 개발해오던 부분이 C#이었고, 각 관리하는 크롤링 대상들의 비지니스 로직을 가지고 있기 때문에 쉽게 걷어내지는 못하고 있습니다. (언젠가는 파이썬 + JSON CONFIG로 전환하려는 목표는 가지고 있습니다.)

미들웨어

솔직히 많은 트래픽을 다루는 것은 미들웨어가 핵심입니다. 큐와 캐시를 어떻게 잘 활용하느냐가 가장 중요한데요. 마이크로서비스 아키텍처에서 트래픽을 분산하고 트랜잭션의 개념처럼 각 서비스별로 어떤 업데이트를 보증하기 위해서는 Queue 시스템이 가장 중요한 역할을 하게 됩니다.

더불어 상당히 많은 양의 트래픽을 감당하려면 적재적소의 메모리 DB의 활용이 가장 중요하게 됩니다. 트렌비는 전세계의 200만건이 넘는 상품데이터를 저장하고 빠르게 검색될 수 있도록 진행해야 되는 부분이 가장 중요합니다. 여기서 가장 어려운 것이 상품수가 많아지면 소팅과 검색에 따라서 얼만큼 빠르게 데이터를 줄 수 있는가가 가장 중요한데요. 예상하시다시피 레디스와 엘라스틱 서치를 활용해서 해당 문제를 풀고 있습니다.

큐는 SQS라는 아마존에서 지원하는 기본큐를 사용하고 있는데요. 이 부분은 상품쪽에서만 사용하고 모든 서비스에서 이벤트 서브스크립션 모델로 아직은 사용하고 있지 않습니다. (이부분은 우선순위가 낮은 것은 아닌데 아직 손이 모잘라 구현을 못하고 있습니다. ㅠㅠ)

앞으로 더많은 트래픽과 대용량의 데이터를 봐양하는 부분이 있는데 이런 문제를 같이 풀고 싶으신 분들은 과감없이 채용페이지를 방문해주세요.

트렌비 채용페이지 가기

인프라

처음에는 Azure와 AWS를 같이 사용했었는데요. 요즘은 거의다 AWS만 사용하고 있습니다. 현재 약 100개 이상의 머신이 돌아가고 있는데요. AWS의 활용포인트는 유연한 확장이겠죠? 저희가 구성한 시스템 아키텍처는 아래와 같습니다.

각 서비스 별로 서비스 그룹이 있고, 이 서비스 그룹은 각자의 DB를 보는 마이크로서비스 아키텍처로 구성되어 있습니다. 프로덕트 DB는 마스터와 슬레이브로 구성되어 부하를 최대한 줄이고 있습니다. 더불어 API GATEWAY 시스템을 통해서 최대 1시간 정도 캐시를 적용하고 있구요.

로드밸런서를 통해서 부하를 각 서버에 따라서 나눠서 분산시키고 있습니다.

ELK 스택이라고 부르는 키바나와 로그스태시 그리고 엘라스틱서치를 활용하고 있는데요. 엘라스틱 서치를 활용해서 상품 리스팅들을 고도화 시키고, 로그스태시 로그를 통해서 신규 상품들과 품절 상품들을 동기화 처리를 진행합니다. 그리고 키바나 보드를 통해서 각 시스템을 모니터링하다가 이상 신호가 발생되면 슬랙 채널로 알람을 보내고 있습니다.

키바나 모니터링

트렌비의 기술스택은 약간의 시행착오를 거쳐서 계속 고도화시켜 나가고 있습니다. 이런 시스템을 같이 고민하고 개발에 참여하고 싶으신 분들은 부담없이 채용페이지에 방문해주시길 부탁드립니다.

항상 개발과 배워나가는 것이 즐럽고, 기술부채가 싫고, 코드스멜이 불편한 분들이라면 누구나 지원하실 수 있습니다.

박경훈

현재 트렌비 CEO로 일하고 있습니다. 15년 정도 개발자로 일을 하면서 약 10권의 책을 집필하고 번역하였고, 다양한 세미나 및 컨퍼런스에서 개발문화를 전파하는 활동을 해왔습니다. 2002년부터 훈스닷넷이라는 닷넷 최대 개발 커뮤니티를 운영하였습니다.

View all posts by 박경훈 →

댓글 남기기

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다