배달의 민족 주문~!: ServerSentEvents로 실시간 알림 전송하기 #우아콘2025 #우아한형제들

우아한테크·우아콘 2025 2025·7개월 전·

#spring-webflux#kotlin-coroutines#server-sent-events#mqtt#aws-iot#real-time-notification

AI 요약

주문 접수 알림의 기존 MQTT 구조가 legacy client의 payload 제한, topic 권한 부재, 전용 port 차단, WebView 인증서 관리 문제를 안고 있었던 데서 출발한다. AWS IoT로 인증·payload를 개선하고 Server-Sent Events로 웹 친화적 단방향 전달 경로를 세우며 하루 4천만 건을 안정화한 과정을 따라간다.

핵심 포인트

기존 MQTT는 zero payload라 client가 API 재조회로 상태를 비교해야 했고, topic 권한 부재로 타 partner topic 구독이 가능했으며 전용 port 차단·WebView 인증서 관리 문제까지 겹침
AWS IoT의 X.509 인증서·topic 권한으로 보안을 강화하고 정형 payload에 문구·event type·sound type을 실어 client update 없이 알림을 제어, 남은 port·WebView 문제는 HTTP 단방향 SSE로 해결(WebSocket은 과도하다 판단)
모든 server가 broker event를 받고 실제 session을 가진 node만 전달하는 broadcast 구조로 순서 보장·scale-out 단순성을 확보하고, Last-Event-ID 재전송·commit URL 수신 기록·활성 session 단일 검증으로 신뢰성과 보안을 보강
buffer 0·suspend coroutine channel의 Kafka 정체는 capacity·overflow 정책으로, 배포 후 동시 재접속 CPU spike는 session 유지시간·reconnect jitter로 해결하고 capability에 맞는 event만 보내 I/O 절감

왜 읽나실시간 알림 전송 구조를 MQTT에서 웹 친화적으로 전환하려는 백엔드 개발자에게 SSE broadcast 설계와 재연결·backpressure 운영 함정을 담은 대용량 실전기.

챕터별 상세

011:30 – 3:01

MQTT 기반 주문 알림의 기존 흐름

도메인 서버가 상태 변경을 DB에 기록한 뒤 MQTT publisher로 알리고, client는 자기 topic을 구독하다 메시지를 받으면 API로 최신 데이터를 다시 조회해 알림을 만들었다. 이 구조는 payload에 정보가 거의 없어 client가 이전 상태와 응답을 비교해야 했고 알림 시점과 문구가 애플리케이션 버전에 묶였다.

AWS IoT의 X.509 인증서와 topic 권한으로 보안을 강화하고 정형 payload에 문구·event type·sound type을 넣어 client update 없이 알림을 제어할 수 있게 했다. 남은 port와 WebView 문제에는 HTTP 단방향 push인 SSE가 적합했으며, 양방향 WebSocket을 도입해 기존 API interface 전체를 다시 정의하는 것은 알림 요구에 비해 과도하다고 판단했다.

모든 server가 broker event를 받고 실제 session을 가진 node만 client에 전달하는 broadcast 방식을 택해 network 호출은 늘지만 순서 보장, scale-out 단순성, 낮은 유실 가능성을 우선했다. 재연결 시 Last-Event-ID 이후의 event를 DB에서 복구하고, 반드시 한 번 확인해야 하는 알림은 commit URL로 수신을 기록하며, 동일 계정의 활성 session을 하나로 검증해 중복 연결과 정보 노출을 막았다.

buffer가 0이고 overflow가 suspend인 coroutine channel 때문에 Kafka 처리가 멈추던 문제는 적절한 capacity와 overflow 정책으로 해결했다. 배포 뒤 모든 client가 같은 주기로 재접속해 CPU가 튀는 현상에는 session 유지 시간과 reconnect jitter를 주었고, client capability에 맞는 event만 보내 I/O를 줄였다. 최종적으로 polling과 비용을 낮추면서 하루 평균 4천만 건을 안정적으로 처리했다.