Kafka를 먼저 읽어보시면 이해가 더 잘되실겁니다.
도입기
기존에는 node 서버가 요청을 받아서 데이터를 가공하여 FCM으로 전달하는 서버로 구성되어 있었는데, 몇가지 문제가 있었습니다.
- 토큰 만료 여부(Response)를 받지 않고 무조건 쏘기만 하고 있었음
- 프로젝트 아이디만 다른 같은 소스를 복붙하여 폴더를 여러개 만들어 프로세스를 여러개 띄워 nginx에서 바라보게 해놨음
- 모니터링이 안달려있음
- (하나의 소스로 합칠 경우)프로젝트 ID를 추가해야 할 때 기존 푸시 서비스가 일시적으로 마비될 수 있음
기존 로직
Request-Reply 패턴 적용하여 구현한 Kafka 로직
이번 도입에선 FCM 키가 만료되었을 경우 삭제를 위해 Request-Reply 패턴을 적용하여 Response를 받고있습니다.
고려점
- 이후에 프로젝트 ID가 추가될 때 Topic을 추가하지 않고**(Producer를 수정하지 않고)** Consumer의 코드만 수정하면 되도록 판단 로직을 Consumer에 넣기 → 기존 push는 정상적으로 가는 것을 보장할 수 있게 처리. Rolling을 하든 Blue/Green을 하든 기존 push에 영향이 없어야 함.
- 수신자가 같은 경우 순서가 보장될 수 있도록 하기 → fcm token을 key로 하여 동일한 파티션으로 분배되게 처리. 같은 파티션 내에선 순서가 보장됨.
const keyVal = {
key: payload.pushData.token, // 메시지 키로 pushData.token 값을 사용
value: payload // 메시지 본문에 pushData 전체를 포함
};
const result$ = this.clientKafka.send(kafka_topic, keyVal);UNREGISTERED에러가 발생할 경우, DB에서 해당 push_id 삭제 → Request-Reply 패턴 적용. → Producer에서 응답 토픽을 구독, 요청-응답 매핑(correlation id)을 추가- 모니터링 달기 → 아직 시도중