전체 글
-
[개념] Kafka 리밸런싱STOVE DEVCAMP 3기/알림 서비스 2023. 3. 10. 03:17
## 컨슈머 그룹 카프카 프로듀서가 전송한 메시지는 토픽의 파티션에 나눠서 저장됨 파티션에 저장된 메시지들은 컨슈머들에 의해 읽혀짐 하나 이상의 카프카 컨슈머들은 '컨슈머 그룹'을 형성함 ## 카프카 리밸런싱 상황 프로듀서에서 생산하는 메시지를 하나의 컨슈머가 모두 처리하는 구조 컨슈머 쪽이 병목이 되어 카프카 파티션에 처리되지 않은 메시지가 쌓일 수 있음 이러한 지연은 데이터 파이프라인의 실시간성을 떨어뜨리고 결국 장애를 발생시킬 수 있음 개선 위와 같은 문제를 해결하기 위해 데이터 읽어가는 컨슈머 쪽의 스케일 아웃이 필요함 즉, 컨슈머 그룹의 컨슈머를 추가하여 데이터 처리량을 늘리는 작업임 컨슈머 그룹에 컨슈머가 추가되면, 컨슈머 그룹에 속한 컨슈머들이 토픽의 파티션들의 소유권을 나눠가지게 됨 이러한..
-
[알림 서비스] 알림 서비스 구조 개선 방향 수립STOVE DEVCAMP 3기/알림 서비스 2023. 3. 10. 03:15
💡 구조 개선 방안 상세와 이에 대한 멘토님의 피드백을 정리한 문서입니다. 📌 개선 대상 알림 생성 기능 처리 구조 📌 최종 목적 알림 서버가 재시작되거나 장애가 발생해도 생성된 알림이 유실되지 않고 Firebase에 전송되도록 함 알림 생성 API 지연응답으로 유저/트윗 서비스에 장애를 전파하지 않도록 함 Firebase에 장애가 발생하거나 Firebase 전송 오류가 발생해도 생성된 알림이 유실되지 않고 Firebase에 전송되도록 함 📌 현재 처리 구조의 문제점 및 보완할 점 파악 알림 서버가 재시작되거나 장애가 발생하여 서버가 다운되면, Firebase에 아직 전달되지 않은 알림 메시지는 유실됨 Firebase에 장애가 발생하거나 Firebase 전송 오류가 발생하면, 알림 메시지가 유실됨 알림 ..
-
[알림 서비스] 알림 서비스 구조 개선 - 대량의 알림 데이터 처리를 위한 장기적 관점의 확장 가능한 구조 설계STOVE DEVCAMP 3기/알림 서비스 2023. 3. 10. 03:12
📌 개선 대상 현재 구조(알림 요청, 알림 전송) 동작 방식 전송할 알림 메시지를 데이터베이스에 저장하고, 스케줄러를 사용해 주기적으로 전송할 메시지를 데이터베이스에서 조회해 FCM에 알림을 전송함 📌 기존 처리 구조의 보완할 점 파악 1) 알림 요청 부분 Spring Boot에서는 Thread Pool을 사용해 다중 요청을 처리함 주의 : 다중 요청을 받을 수 있다는 의미이고, 이것이 처리량이 향상된다는 의미가 아님 서버 Scale-Out 시 처리량 향상 가능함 따라서, 알림 요청 부분은 장기적인 관점에서 대량의 알림 데이터 처리가 가능한 구조임 2) 알림 전송 부분 일정 간격으로 하나의 스케줄러가 실행되고, 한 번의 실행에서 알림을 조회하고 발송하는 작업을 순차적으로 실행하는 구조임 현재 구조에서는 ..
-
[MSA] Spring Cloud Gateway로 API 게이트웨이 구축하기STOVE DEVCAMP 3기/MSA 2023. 3. 10. 03:10
📌 Spring Cloud Gateway 1) 스프링 클라우드 게이트웨이란 스프링에서 제공하는 API 게이트웨이 구축을 위한 라이브러리 중 하나임 API 게이트웨이가 추상적인 개념이라면, 스프링 클라우드 게이트웨이는 구현체 느낌 2) 구성 요소 크게 3가지 구성요소가 존재함 Route 고유ID, 목적지 URI, Predicate, Filter로 구성됨 게이트웨이로 요청된 URI의 조건이 참일 경우, 매핑된 해당 경로로 요청을 전달해줌 Predicate 주어진 요청이 조건을 충족하는지 테스트하는 구성요소 각 요청 경로에 대해 충족해야 하는 1개 이상의 조건자를 정의할 수 있음 만약 정의된 모든 Predicate에 매칭되지 않는다면 HTTP 404 Not Found를 반환함 Filter 요청 및 응답에 대한..