알림 서비스로 시작하는 서버 개발

https://www.youtube.com/watch?v=CmTO68I2HSc 

 

개요

if(kakao) 2022 발표에서 카카오뱅크의 김민수 님의 발표인 알림 서비스로 시작하는 서버 개발을 요약해보고자 합니다.

 

카카오뱅크의 알림

카카오 모빌리티의 알림 예시

이체, 카드 사용, 광고 등의 이벤트 발생 시 알림을 생성하였습니다.

카카오뱅크에서는 알림 시스템을 어떻게 만들었을까요?

 

카카오뱅크의 알림 시스템 V1

현재 아키텍처는 알림 생성과 조회를 담당하는 알림 서버의 구조입니다.

하지만 이체나 카드 사용량이 많아져 알림 생성에 부하가 걸린다면 어떻게 될까요?

알림 서버의 CPU 사용량이 100%에 가까워지거나 스레드가 고갈될 수 있습니다.

이렇게 되면 알림생성으로 발생한 장애가 알림 조회까지 전파가 됩니다.

 

카카오뱅크의 알림 시스템 V2 - 생성 / 조회 서버 분리

생성 서버와 조회 서버를 분리하는 아키텍처를 가져갈 수도 있습니다.

관리 포인트는 증가하지만 생성에서 장애가 발생해도 조회는 그대로 가능합니다.

 

하지만 여전히 생성 서버에서 장애가 발생할 경우에는 연계된 서비스에 장애를 전파합니다.

예를 들어 생성시 지연이 발생하거나 time out이 발생하면 이체를 위한 알림을 위해 이체가 안될 수도 있습니다.

 

알림이라는 서브기능으로 인해 메인기능인 이체가 안된다면 안됩니다.

 

카카오뱅크의 알림 시스템 V3 - 신뢰성 있는 서버

Async Thread Pool인 비동기를 활용한 아키텍처로 빠른 응답을 보장할 수 있습니다.

이제 알림 요청과 알림 생성과 경계가 생겨서 알림 생성의 장애가 연계시스템의 장애로 전파되지 않습니다.

 

하지만 비동기의 단점으로 알림이 정상적으로 만들어졌는지 당장 알 수 없습니다. (실시간이 아니다!)

또한 중간에 배포가 일어나거나.. 내부적으로 실패하게 된다면?

알림은 유실되며 운영 신뢰성은 보장되지만 데이터 신뢰성은 보장되지 않습니다.

유실이 되었다면 재처리를 구현해야 하며 개발 및 관리 포인트가 증가됩니다.

 

카카오뱅크의 알림 시스템 V4 - Message Queue 도입

알림 요청과 알림 생성이 여전히 분리되었고, 생성 서버가 다운되거나 재시작하더라도 Message Queue에서 Kafka라면 로그로 Disk로 저장되기 때문에 더 이상 데이터는 유실되지 않습니다.

 

Message Queue에 장애가 발생한다면?

고가용성을 내부적으로 보장하고, 장애가 발생하더라도 Disk에 저장하기 때문에 Dequeue 부분에는 문제가 없습니다.

하지만 Enqueue가 불가능하기 때문에 초기 요청을 Database에 저장할 수 있습니다.

이후에 내부적인 재처리를 통해 보장할 수 있습니다. (Transaction Outbox 패턴을 사용하신 것 같습니다)

 

 

추가 요구사항

• 12개월의 데이터를 조회하고 싶어요
• 대용량의 알림 템플릿을 엑셀로 다운로드 / 업로드하고 싶어요

서비스에 영향을 주지 않도록 내부 서비스는 별도의 서버로 구성하였습니다.

또한 데이터베이스도 서비스 데이터베이스와 Archive 데이터베이스로 분리하여 구성했습니다.

 

서비스 DB는 3개월의 정보만 필요했기 때문에 Delete From Table Where (3개월 이전)을 사용할 수도 있습니다.

하지만 서비스 DB에서 대용량 데이터를 삭제하게 되면 lock, transaction log의 I/O 등으로 부하를 발생시킬 수 있습니다.

 

이때 DB의 파티셔닝을 활용하여 월마다 알림 데이터를 저장할 수 있습니다. 

이후에는 테이블 하나를 삭제하면서 데이터를 삭제할 수 있습니다.

 

늘어나는 알림..

늘어나는 알림에 대비하여 서버도 대비해야 합니다.

• application을 scale-out 할 수 있어야 한다.
• DB를 Sharding 할 수 있어야 한다.

하지만 샤딩을 사용하며 DB를 추가하는 경우에 데이터 재조정과 라우팅이 필요합니다.

 

지속가능한 서비스를 위해 다양한 구조와 장/단점을 알아보고 단점을 극복하는 과정을 알아보았습니다.