2024 우아콘
Last updated
Last updated
2024년에는 우아콘에 드디어 가게되었다! 부푼 마음을 가지고 컨퍼런스에 참여하게 됐고, 굿즈들과 이벤트들도 엄청 많았다. 세션에서는 공개가 되지 않았지만, ML기반 추천 로직을 보여주는 장표도 있었는데 흥미로웠다. 갈 수 있도록 도와주신 분께 감사드립니다!
내가 이 컨퍼런스에 참여하게 되고 해당 세션들을 선택한 이유들은 다음과 같다.
게이트웨이 검토를 하다가 도입하지 못하였는데 배달의 민족 게이트웨이의 도입 이후 보안적 사항들이나 기술적 어려움을 어떻게 극복하신지 확인해보고싶었다.
Kafka를 사용할때 한번씩 겪으시는 장애이슈들을 어떤 방식으로 풀어나가셨는지 궁금했다.
설정
용도
대규모로 동시성이 일어나는 상황 대규모 트래픽을 받을때 Kafka 를 이용한 최적화를 어떤 방식으로 접근하시고 해결하셨는지 궁금했기도하다.
API Gateway가 시간 순으로 어떻게 발전해왔는지 설명해주셨다.
배달의 민족에서는 왜 API Gateway가 필요한가?
클라이언트 의존성 증가로 확장성이 저하된다.
불필요한 비즈니스 정책이 노출 될 수 있다.
MSA로 전환하면서, 횡단 관심사 문제가 커지면서, 인증, 라우팅, 보안, 흐름제어 같은 문제를 담당하게됨
인증은 JWT를 사용했다고 하셨는데, JWT Key값 변경은 어떻게 진행하시게 될지 궁금했다.
토스의 경우, Passport 값을 복호화해서 뒷단의 서비스들에 전달하게 되는데 JWT Key값 변경에 대한 유지보수 비용은 없는 것 같다.
라우팅은 운영테스트, 타겟팅, 카나리 배포, 점진 배포 등으로 활용하고 계신다고 한다.
인프라 구성에 대한 관심사와 엮어져 있는데 이부분들에 대한 자동화는 어떻게 진행하신지 궁금했다.
우아콘에서 제일 재밌게 봤던 내용이었다. 외부 연동은 연동 처리는 제한된 대역폭과 연동 대상의 제한된 리소스로 인해 노하우가 많이 필요한 업무라고 생각한다.
카프카 클러스터를 운영하고 계신 분들이 짧고 굵게 장애들에 대한 원인 파악과 개선점 까지 설명해주셨다.
메시지플랫폼을 운영하시면서, 통신사, 외부 서비스 장애, 내부 버그, 벤더사 장애 등 Kafka 장애 이슈들을 설명해주셨다. 역시나 외부 서비스 이슈가 43퍼센트 정도로 무조건 이슈가 생긴다는 가정을 하고 운영을 해야하는 것으로 보였다.
외부 서비스들에 대한 모니터링 노력들을 시작으로, 가용성을 위한 조치들을 먼저 설명해주셨다.
opsgenie 로 연동해서 알람
각 통신사들과 각 벤더사들마다 장애 알람
트래픽을 다른 벤더사로 전환하는 기능 도입
아키텍처 개선을 결심하게된 장애 이슈들로 가용성 목표를 이뤄내지 못했고, 이에 따른 개선 여정을 시작하셨다.
'10월, 11월에 56% 발송 실패'에 대한 장애의 원인은 Invalid Producer Epoch Exception이 발생하면서 컨슈머 쪽의 파티션 컨슈밍이 중단되었고, 특정 파티션에 대한 lag이 증가되면서 장애를 확인하게 됐다.
카프카는 중복 방지 프로듀서와 트랜잭션 기능을 통해 메시지 중복 전송을 방지하는데 인프라의 심플함을 위해 exactly once 옵션을 켜뒀었는데 이 때문에 이슈가 생겨 장애가 났었다고 한다.
Kafka의 exactly once 옵션을 제거함에 따라, 메시지의 중복을 redis로 메시지의 해시를 사용해 제거했고, 메모리 TTL 시간과 클러스터 사이즈를 늘림으로써 중복 방지 문제는 해결했다고 한다.
장애의 원인을 제거한 이후 3배의 처리량을 처리해달라는 요청이 생겼고, 이에 따른 여러가지 최적화 방안들을 수립하여 진행하셨다.
개선에 대한 의사결정 과정
현재 카프카 파티션의 수는 720 개로 파티션을 늘리는것은 장애 발생시 복구 시간과 복잡성이 증가해서 채택하지 않았다고 하셨으며, 커밋 과정에서 파티션들의 동기화가 일어나게되면서 레이턴시가 증가한다고 했습니다. (리소스 증가 + 리스크는 증가하는 결정)
첫번째 개선안은 '푸시 발송 구조를 개선'를 진행하셨다.
Google 의 FCM 서비스를 사용하는데 15분 이상 응답이 안오는 이슈가 있음에 따라, 적절한 TIME LIMITER 처리를 해주셨다고 한다. [1]
두번째 개선안은 '비동기처리에대한 개선'
발송 이후 동기적으로 커밋하는게 아니라 Sender에게 요청을 보낸 순간에 commit 함으로써 처리량을 개선했다. [2]
일시적인 실패 재처리 (실패시 dead letter queue)
어느 정도의 동시성을 사용할 수 있을 지 검수하기
트래픽 성격에 따른 스레드풀 분리 (즉시성 vs 비정기적) [3]
세번째 개선안은 '불필요한 카프카 요청 제거'
배치 리스너를 적용함으로써 메시지를 비동기로 처리
카프카 I/O를 최대한 줄임으로써, Latency를 감소 시켰다.
성과
이를 통해, 파티션 수를 720개에서 100개로 줄이고, 처리량을 3배로 증가 시켰다고 하셨다.
MySQL 에서 수십만개의 가게 데이터에 대한 트리거로 실시간 변경 사항을 처리하는데 생긴 데드락과 타임아웃을 어떻게 극복 하셨는지 설명해주셨다.
