Firebase와 Cloud Firestore로 실시간 메신저 서비스 이전 Part 1

메신저 서비스 이전 배경

안녕하세요. 저는 번개장터에서 상점 간 거래 프로세스와 관련된 서비스를 개발 및 관리하는 Trade Lab에서 백엔드 소프트웨어 엔지니어로 근무 중인 김동현입니다.

앞으로 총 4개의 포스트를 통해 번개장터에서 Firebase와 Cloud Firestore로 새로운 메신저 서비스를 구현하고 기존에 구현된 메신저 서비스와 교체하는 과정들을 정리해서 공유해 드릴 예정이며,

이번 포스트에서는 기존에 구현된 실시간 메신저 서비스의 구조와 새로운 메신저 서비스로 이전하게 된 계기를 정리해보겠습니다.

As-is

번개장터에서는 상점 간 거래 진행 시 구매자와 판매자의 양방향 소통을 돕는 ‘번개톡’ 이라는 실시간 메신저 서비스를 지원하고 있으며,

사용자들은 메신저 서비스를 통해 관심이 있는 상품에 대한 문의와 답변을 남기거나 상점 간 거래 진행 시 필요한 정보들을 (구매자 주소, 판매자 계좌 번호 등) 실시간으로 공유할 수 있습니다.

기존에 구현된 실시간 메신저 서비스는 번개장터가 네이버의 계열사였을 때, 네이버의 자회사인 캠프모바일에서 지원하는 메신저 서버와 클라이언트를 번개장터의 클라이언트와 인프라에 이전해서 사용하고 있으며,

사진과 같이 메신저 서비스의 데이터를 관리하면서 여러 메신저 서비스 이벤트를 발행하는 IM (Instant Messaging) 서버, 대화방에 접속 중인 앱 또는 웹 클라이언트 세션과 실시간으로 통신하며 클라이언트와 IM 서버에서 발생하는 이벤트를 전달하는 앱 클라이언트 세션 서버와 웹 클라이언트 세션 서버,

마지막으로 IM 서버와 번개장터의 내부 서비스를 연동하면서 클라이언트에게 메신저 서비스의 주요 비즈니스 로직을 제공하는 API 서버까지 총 4개의 메신저 서버와 클라이언트가 실시간으로 메신저 서비스의 데이터와 이벤트를 교환하는 구조였습니다.

서비스 운영 초기에는 메신저 서버와 클라이언트 모두 별다른 문제 없이 동작했습니다. 하지만 시간이 지나고 번개장터의 서비스 규모가 커지면서 접속 중인 사용자들과 트래픽의 양도 같이 증가했으며, 이에 따라 메신저 서비스에도 새로운 문제들이 발생했습니다.

하지만 당시 메신저 서비스, 특히 메신저 서버의 경우 서로 다른 기술 스택으로 구현된 4개의 프로젝트를 관리할 수 있을 만큼 개발 인력이 충분하지 않아서 정확한 문제의 원인을 파악하거나 해결이 어려운 상황이었고, 이는 메신저 서비스를 개선하거나 새로운 기능을 추가할 때도 똑같이 적용됐습니다.

To-be

번개장터에서 진행되는 상점 간 거래는 대부분 메신저 서비스를 통해 진행되고 있으며, 상점 간 거래 진행 시 주소와 계좌번호 같은 개인적인 정보를 대화방에 안전하게 공유하며 거래를 진행할 수 있는 ‘톡거래’ 와

구매자가 물품을 수령하고 구매를 확정하는 순간에 판매자에게 결제된 금액이 정산되는 ‘번개페이’ 등 메신저 서비스를 통해 사용자들의 안전하고 편리한 거래를 돕는 여러 기능과 서비스를 지원하고 있습니다.

그래서 메신저 서비스에 문제가 발생하면 상점 간 거래 프로세스에도 문제가 생기면서 거래 중인 다수의 사용자가 불편을 겪을 수도 있기 때문에 빠르게 문제의 원인을 파악하고 대응할 수 있어야 했습니다.

그리고 이를 위해서는 현재의 개발 인력으로 관리할 수 있을 만큼 개발 및 관리 비용이 개선된 새로운 구조의 메신저 서비스가 필요했습니다.