”타임딜 쇼핑 서비스에 Firestore를 어떻게 활용했는지 소개하려고 합니다.

나석현제품길드 O파티 리더
Google Cloud Firestore를 사용하게 된 이유

타임딜 기능의 특성상, 특정 시간 내에 특정 개수를 판매하며 판매되어 남은 상품 개수 정보를 모든 유저에게 실시간으로 제공하는 것이 가장 중요했습니다. 실시간으로 접속되어 있는 모든 클라이언트의 데이터를 동기화하기 위해서는 Socket 서버와 Client를 바인딩하여 데이터를 받도록 구현하는게 일반적일텐데요.

Socket Server 구축에 따른 관리 포인트 증가, Client Connection 증가에 따른 서버군 확장・Infra 관리 등 부가적인 리스크를 줄이기 위해 Firestore를 활용했습니다.

타임딜 실시간 데이터 동기화 구조

타임딜에서 데이터를 동기화하는 구조는 상품 구매 완료 처리 후, Logic Server에서 동기화해야 하는 데이터를 REST 방식을 통해 Firestore 컬렉션에 데이터를 업데이트하게 됩니다.  데이터가 업데이트 되면 Firestore에서 데이터 변화에 따라 바인딩 되어있는 Client에 데이터를 동기화 시킵니다.

Rest API를 통한 동기화 과정

Firestore 연동 방식은 아래와 같이 REST 뿐만 아니라, 언어별 라이브러리를 지원하고 있습니다.

  • API 참조
    • Android
    • iOS – Swift
    • iOS – Objective-C
    • 웹
    • Cloud Functions
    • Node.js
    • 자바
    • Pyhon
    • Go
    • C#
    • PHP
    • Ruby
    • REST
    • RPC
우리 서비스는 Ruby를 사용하고 있는데 왜 REST API를 사용하게 되었을까?

그 이유는 단순합니다. 개발 당시 Ruby를 지원하지 않았기 때문입니다. 지금은 Google 라이브러리 및 오픈 소스 등 Firestore를 사용할 수 있는 많은 것들이 있지만 개발 당시에는 Ruby에서 사용할 수 있는 방식은 REST 밖에 없었습니다.

REST API로 Patch 하는 과정
  1. API를 통해 Access Token을 요청하여 받아온다.
    • Access Token을 받아오기 위해 Firebase service account, private key, Firebase id 값을 기반으로 만든 JWT Token을 보낸다.
  2. Access Token을 가지고 Firestore Patch API를 사용해 데이터 Patch를 한다.
Firestore 장・단점
  1. 별도의 Socket 서버를 구축할 필요가 없다.
  2. 오픈 소스를 이용하여 구현이 용이하다.
    • 초기 개발 당시에는 오픈 소스가 없어서 위처럼 API 기반으로 자체 구현하였지만, 현재는 여러 오픈 소스를 활용할 수 있어 쉽게 사용할 수 있을 것으로 기대됩니다.
  3. 이번에 사용한 기능처럼 시스템적인 데이터를 실시간으로 전달하는 용도로는 좋으나, 채팅같이 변화가 많은 유저 기반의 데이터는 비용적으로 문제가 될 수 있을 것 같습니다.

개발 초기에 실시간 데이터를 처리해야하는 기능을 구현하는데에 고민이 많았습니다. 실험적으로 서비스 기능을 운영한 뒤 정식화・고도화 할 수도 있고, 하지 않을수도 있는 서비스라는 점에서 일반적인 Socket Server를 구축하기에는 작업 범위가 Heavy 하다고 생각되었습니다. 요구 사항이 실시간으로 전달해야하는 데이터가 상품의 잔여 갯수 하나이기도 했고요.

Firestore는 이와 같이 유저간의 실시간 데이터 전달이 아닌 서비스에서 제공하는 제한적인 실시간 데이터를 기반으로 할 때 활용하기 좋다는 생각이 들었습니다.