summary
- redis pub/sub 으로 실무 bus_refresh 구현의 한계점으로 인한 3가지 대안 모색
- 큐 -> CDL 데이터 넘어가는 것 관측
- PEL 메세지 삭제 이슈로 consumer 자동정리로직 제거(다른 consumer 에게 이관 후 consumer 폐기처리하도록 변경필요)
redis 단순 bus-refresh 한계점
저번 포스팅 작업진행 후 몇 가지 한계점(개선점)을 관측하였습니다.
- 결국 현재 설정값이 여러 파드 내 정상적으로 적용되어있는지 확인할려면, 파드에서 다시 응답을 토픽에 쏘아 올려야 합니다.
- 설정 값들에 버저닝을 적용한 뒤 어떤 어플리케이션이 어떤 버전의 값을 수신하고 적용하고 있는지 트래킹이 필요합니다.
- 민감한 설정값이기에 ACL 도 붙여서 통제하에 관리해야합니다.
- 변경 로그또한 생성하여 관리해야합니다.
유지보수 측면에서 aws-secret + bus-refresh 이 결합된 무언가를 개발하여 관리하는 것은 매우 비효율적이라고 판단하였습니다. 그래서 대안으로 3가지를 보았는데,
- 센트럴 도그마 Line
- Spring config server + rabbit mq
- rabbitmq consumer 로 bus refresh 이벤트 리스닝. git private repo 점근권한 관리 및 commit hash 를 /actuator info 에 노출시키고 micrometer 에 집계해서 grafana 에 노출시키기.
- Spring config server + watcher 구현체로 config server polling 해서 직접 버전 controll
1, 3번이 그마나 가장 간단한 작업이 될 것 같습니다. 하지만 일단 지금은 이것이 주가 아니라서 최대한 stream 모니터링에 맞춰서 작업을 이어나가겠습니다.
summary:0 에 max retry 횟수인 5회 초과 시 CDL 로 넘어가는 것 지표 관측
일부러 에러를 냈고 잘 넘어감과 동시에 CDL 넘어간 이후에는 천천히 소비되도록 수정하였습니다. 5회 retry 까지는 1초마다, CDL 에서는 3초 마다. CDL 에서 일정 횟수 이상 메세지가 쌓이면 즉시 알림가도록 설정해야 할 것 같습니다. 또한 CDL 에선 천천히 메세지 소비하도록 수정한 뒤 재관측 할 것입니다.
summary:0 내 consumer group 의 pending 메세지 삭제이유
여러 설정 값들을 수정 하면서 특정 컨슈머 그룹의 pending 메세지가 삭제되는 과정을 발견하였습니다. 아마도 consumer group 자동정리로직에 의해 삭제되고 다시 재로딩되면서 문제가 발생한 것 같습니다.
consumer 을 제거할 때 PEL 내 엔트리가 같이 삭제되면서 해당 메세지가 몇 번/언제 reproduced 되었는지 가 사라집니다. consumer group 단위로 pending 을 관리하는게 아니라 consumer 단위로 관리하고 있네요. 그렇다면 직접 consumer 자동정리는 꺼놔야할 것 같습니다.
이 부분은 XAUTOCLAIM으로 오래된 consumer의 pending을 현재 consumer로 모두 가져오도록 수정한 뒤 제거하게 된다면 정상동작 할 것 같습니다.