당근마켓 채팅 시스템이 현대화 되어온 과정

이 기사는 5월 10~11일 개최된 <AWS 서밋 코리아 2022>에서 당근마켓 변규현 엔지니어가 발표한 세션 ‘2200만 사용자를 위한 채팅 시스템 아키텍처’에 기반을 두고 있습니다.

당근마켓에서 채팅시스템을 개발하는 변규현 엔지니어가 당근마켓에 입사할 당시 당근마켓 사용자는 약 200만명 정도였다. 이미 많은 사용자가 있는 서비스였지만 당근마켓의 성장속도는 예사롭지 않았다. 그야말로 기하급수적으로 이용자가 증가했다. 현재 당근마켓은 2200만명의 회원을 자랑한다. 변 엔지니어가 입사할 당시만해도 당근마켓의 IT 아키텍처는 단순했다. 루비온레일즈로 개발한 모놀리식 아키텍처로 구성돼 있었다. 데이터베이스도 포스트그레SQL 하나뿐 이었고, 모든 데이터가 그곳에 담겨있었다.

하지만 회원이 급증하고 조직도 커지면서 이와 같은 아키텍처는 부담이 됐다. 우선 루비온레일즈는 쉽고 개발이 편리하지만 국내에서는 활용률이 높지 않고 시스템이 커졌을 때 성능 이슈가 있다. 이는 개발자 수급이 어렵고, 앱의 기능이 많아질수록 성능이 떨어질 가능성이 있다는 것을 의미한다. 필요에 따라 고(Go Lnag), 자바 코틀린, Nodj.js, 파이썬 등 다양한 언어를 수용할 수 있는 구조가 개발자를 구하기도 쉽고 성능도 최적화할 수 있다.

당근마켓 내부에서는 자연스럽게 마이크로서비스아키텍처(MSA)로 전환할 필요성이 대두됐다. 다양한 개발환경을 수용할 수 있어야 하기 때문이다. 모놀리식 아키텍처는 장애도 잦았다. 모든 시스템이 하나의 구조로 개발된 모놀리식 아키텍처는 작은 부분이 잘못돼도 전체 시스템에 영향을 주기 때문이다. MSA는 레고블록처럼 독립적인 서비스를 조립해 붙이는 방식의 아키텍처다.

당근마켓은 MSA로 전환하면서 채팅 시스템을 별도의 마이크로서비스로 독립시키기로 했다. 변 엔지니어가 참여한 이 프로젝트에는 당근마켓 내에서 처음으로 고 언어(Go Lnag)를 사용하기로 했다. 마이크로서비스로 독립하는 과정에서 자연스럽게 데이터베이스도 독립하게 됐다.

기존에는 채팅 데이터도 메인 포스트그레SQL에 저장됐다. 채팅 데이터는 용량이 크기 때문에 메인 데이터베이스의 60%가 채팅 데이터로 채워졌다. 채팅 데이터의 50%는 인덱싱 데이터였다. 포스트그레SQL의 경우 데이터베이스를 효율적으로 활용하기 위해 주기적으로 베큠(Vacuum)이라는 청소과정이 필요한데, 채팅을 위한 테이블에 베큠을 실행하면 전체 시스템이 영향을 받았다. 채팅 때문에 앱의 응답시간이 저하되곤 했다.

메인 데이터베이스에서 채팅 데이터데이스를 분리하기로 한 것은 자연스러운 선택이었다. 여기서 흥미로운 점은 새로운 채팅 데이터베이스로 포스트그레SQL이 아닌 AWS 다이나모DB가 선택됐다는 부분이다. 당시 당근마켓의 새로운 채팅 시스템 개발팀은 2명 밖에 되지 않았다. 이 때문에 데이터베이스 관리가 필요없는 매니지드 서비스 중에서 선택해야 했다. 또 채팅 데이터 규모가 워낙 크기 때문에 페타바이트 데이터를 다룰 수 있는 데이터베이스여야 했다. 이같은 조건 중에 선택한 것이 다이나모DB다.

변 엔지니어는 다이나모DB를 선택한 이유를 “고가용성을 보장하고 온디맨드 모드로 사용하면서 오토스케일링이 지원되는 최적의 서비스였다”라고 설명했다.

하지만 데이터베이스를 그냥 바꾸기만 하면 되는 간단한 작업은 아니었다. 포스트그레SQL은 전통적인 관계형 DB인 반면, 다이나모DB는 소위 말하는 NoSQL DB이다. 기존의 SQL을 사용할 수 없게 된다는 의미다. 기존 관계형 DB에서 사용하던 분석방법을 사용할 수 없게 됐다.

이 때문에 당근마켓은 데이터 분석을 위해 채팅에 별도의 파이프라인을 구축했다. 다이나모DB의 데이터를 실시간으로 처리하기 위해 ▲다이나모DB 스트림, 스트림 데이터를 원하는 곳에 적재하기 위한 ▲람다, 이벤트 버퍼를 받아 S3에 업로드하는 ▲파이어호스, 데이터웨어하우스의 스토리지 역할을 하는 ▲S3, 그리고 이런 데이터를 볼 수 있도록 지원하는 ▲아테나로 구성했다.

채팅을 마이크로서비스로 독립시키면서 기존 시스템과의 연결을 위한 API는 고 언어로 짰다. 또 기존 서버 로직에 강하게 결합할 필요가 있는 API는 인터널 API로 재구현했다.

변 엔지니어는 “기존 채팅 시스템을 완전히 재구현해 새롭게 서버를 작성하고 배포까지 성공했다”면서 “당근마켓에서 채팅으로 인한 서비스 장애는 없다고 봐도 좋다”고 자신했다.

아키텍처뿐 아니라 채팅의 메시징 방법도 바꿨다. 기존에는 구글의 FCM(Firebase Cloud Messaging)에 의존적인 구조였는데, FCM에서 푸시 메시지가 밀리면 유저가 접속하고 있어도 메시지를 받지 못하는 경우가 있었다. 이를 개선하기 위해 웹소켓이 연결된 유저는 FCM의 상태와 무관하게 이벤트를 받아서 처리할 수 있도록 했다.

변 엔지니어는 “현재의 채팅 시스템은 복잡해 보이지만 각 구성요소를 처음부터 생각하고 개발한 것은 아니었다”면서 “필요에 따라 어떤 구성 요소가 있을까, 지금의 문제점은 무엇일까, 두 달 혹은 세 달 후에 더 운영이 편한 방식은 무엇일까를 고민해서 나온 플랫폼으로, 서비스가 느슨하게 연결된 형태로 운영하고 있다”고 강조했다.

글. 바이라인네트워크
<심재석 기자>shimsky@byline.networ