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

신규 메신저 서비스 배포

두 메신저 서비스의 연동 및 데이터 마이그레이션을 마친 뒤, 대망의 신규 메신저 서비스의 배포가 시작됐습니다.

이번 포스트에서는 사용자들에게 신규 메신저 서비스를 배포하고 기존 메신저 서비스를 비활성화 및 종료하는 과정을 정리해보겠습니다.

점진적 서비스 배포 및 모니터링

처음부터 전체 사용자를 대상으로 신규 메신저 서비스를 배포할 경우, 예상치 못한 부분에서 문제가 발생한다면 메신저 서비스로 거래를 진행하고 있던 다수의 사용자가 불편을 겪을 수도 있기 때문에

아래와 같이 특정 비율의 사용자들에게 먼저 신규 메신저 서비스를 배포하고 실시간으로 모니터링을 진행하면서 신규 메신저 서비스가 문제없이 동작하면 다시 신규 메신저 서비스의 배포율을 올리고 모니터링 하는 과정을 반복했습니다.

기존 메신저 서비스 비활성화 및 종료

전체 사용자들에게 신규 메신저 서비스를 배포한 뒤, 기존 메신저 서비스를 비활성화 및 종료시키기 위해 신규 메신저 서비스를 지원하지 않는 구버전 앱 사용자들에게

구버전 앱에서 사용 중인 메신저 서비스의 지원 중단을 안내하면서 앱 업데이트를 유도하는 푸시 알림과 번개톡 메시지를 발송했습니다.

그리고 사용자 대부분이 신규 메신저 서비스를 지원하는 버전의 앱을 사용하고 있을 때, 다른 서비스와 컴포넌트에서 기존 메신저 서비스를 사용하는 부분을 신규 메신저 서비스로 교체하는 작업을 진행했습니다.

이후 기존 메신저 서비스를 비활성화 시키면서 하드코딩 된 앱 업데이트 안내 문구를 표시하다가 신규 메신저 서비스를 지원하지 않는 구버전 앱의 지원이 중단되는 시기에 기존 메신저 서비스도 같이 종료되었습니다.

신규 메신저 서비스 이전 결과

현재 실시간 메신저 서비스의 API 서버는 하루에 대략 천만 건의 요청을 처리하고 있으며, Cloud Firestore의 경우 약 수만 개의 클라이언트에게 실시간 데이터 변경 이벤트를 전달하면서 동시에 억 단위의 데이터 읽기 작업과 천만 건의 데이터 쓰기 작업을 처리하고 있습니다.

위와 같은 규모의 트래픽을 처리하면서 적은 개발 비용으로도 메신저 서비스를 관리할 수 있었기 때문에 전보다 빠르게 메신저 서비스에 새로운 기능을 추가하거나 개선이 필요한 부분들을 변경할 수 있었고, 메신저 서비스에서 발생하는 여러 문제의 원인을 파악하고 해결할 수 있었습니다.

지금까지 Firebase와 Cloud Firestore로 새로운 메신저 서비스를 구현하고 기존 메신저 서비스를 이전하는 과정을 정리해봤는데요.

실시간 메신저 서비스와 비슷한 규모의 서비스를 이전하거나 서비스에 Firebase와 Cloud Firestore를 도입하려는 분들께

4개의 포스트가 나름의 레퍼런스가 될 수 있길 바라면서 포스트를 마무리하겠습니다. 끝까지 읽어주셔서 감사합니다.