Spring Batch 비동기 전송의 한계
기존 로직
기존엔 데이터를 위의 순서대로 Target System에 전달해야만 데이터가 정상적으로 저장되는 구조였습니다.
문제는 송장 정보와 위치 정보의 차량 상태가 일치하지 않는 문제가 있었습니다.
문제의 원인은 각 도메인을 4분간격으로 전송을 하다보니 송장 I/F의 차량 상태와 I/F 위치 정보의 차량 상태가 시간차이로 데이터가 불일치 한다는 것이었습니다.
변경된 로직
그래서 I/F 위치 정보만 별개로 진행할 수 있게끔 변경하였습니다.
또한 평소에 위치 정보가 너무 실시간성이 떨어진다는 의견이 있어 10초 단위로 전달을 하게 되었습니다.
서비스 속도 저하 문제
개발 서버에서 기존의 방식대로 api 데이터를 전송하고 싶었지만 순차적으로 진행하던 I/F 위치 정보를 다른 배치들과 병렬로 처리하다 보니 서비스가 느려지는 문제가 발생했습니다.
해당 문제의 원인을 분석하던 중 Netty Thread Pool 사용률과 메모리 사용량이 계속해서 점진적으로 올라가는 것을 보고,
문제의 원인이 무엇일까를 확인하던 중 WebClient를 Blocking으로 사용해서 서비스의 속도가 저하된 사례를 확인했습니다.
해당 사례와 모니터링의 수치를 확인했을 때 변경된 로직에서는 더 이상 blocking 방식으로는 api 전송이 어려울 것 같다는 판단이 들었습니다.
그래서, 팀장님과 함께 기존 데이터들의 성격이 비동기적인 구조를 가지고 있는지를 확인해보았는데, 다행히도 전달되는 도메인은 순서대로 전달되지만 데이터는 비동기적으로 전송이 되어도 문제가 없을 것이란 결론이 났습니다.
이에, Spring Batch에 있는 데이터를 비동기적으로 전송하는 것을 테스트 해봐야겠다는 생각이 들어 관련된 글들을 찾고 있던 중 충격적인 글을 보게 됩니다.
Spring Batch 책임자인 fmbenhassine가 Spring Batch는 비동기적인 구조로 데이터를 전송할 수 없다.. 라고 github issue에 답변을 달아버린 것입니다.
MOM(Message Oriented Middleware)의 도입
Middleware를 통해 애플리케이션의 처리를 분리하자..!
아.. 해당 글을 보고 기존에 만든 프로젝트를 엎어야 하나.. 라는 생각이 들던 찰나 다행히 MOM(Message Oriented Middleware)을 이용하면 비동기 메시지를 보낼 수 있다는 것을 알게 됩니다.
이를 통해 애플리케이션을 새롭게 구축하는게 아니라 middleware를 통해 Spring Batch의 동기적 처리와 Spring Webflux의 비동적 처리를 완벽히 구분할 수 있겠다는 판단이 들었습니다.
물론 middleware를 도입함으로 인해 middleware의 관리적 측면, 자원적인 측면, 비용적 측면을 고려할 수 밖에 없었습니다.
이에 선배 개발자분과 함께 어떤 MOM을 도입할 수 있을지를 알아보게 되었습니다.
Redis Stream을 사용하자..!
여러가지 측면을 봐야겠지만.. 그 중에서도 가장 신경써야 할 부분은 서버의 자원적인 측면이었습니다.
그리고 자원적인 측면으로 확인했을 때 결론적으로 Redis Stream을 선택하게 되었습니다.
사실 안전성과 내구성의 측면에서 확인했을 땐 Apache Kafka나 RabbitMQ를 사용하는게 맞다고 판단했습니다.
하지만.. 할당받을 수 있는 서버의 한계로 인해 최대한 서버의 자원을 고려해야했기에 아쉬움을 뒤로하고 인프라팀과 협의하에 Redis Stream을 선택하게 되었습니다.
Redis Stream 사용시 주의사항
이후 인프라팀과 함께 Redis Stream 사용시 주의사항을 알아보았는데, 개발을 하는 입장에서 주의해야할 2가지 정도를 전달받았습니다.
1. O(N) 명령어를 사용하지 말자
O(N)과 관련된 명령어를 사용하게 되면 Redis가 다른 작업을 할 수 없게 된다고 합니다.
그렇기에 특히 운영중엔 keys 등의 키워드를 사용하지 말것을 조언해주었습니다.
2. BigKey에 유의할 것
레디스 키의 할당을 500KB 이하로 유지하도록 권장해야한다고 합니다.
키가 할당받는 값이 500KB를 넘어갈 경우 Redis가 다른 키의 작업이 지연이 생길 수도 있다는 내용을 알려주었습니다.
Redis Stream과 관련한 사용시 주의사항은 앞으로도 운영을 하며 좀 더 추가하도록 하겠습니다.
출처
'Project&기능개선 > 출하 정보 연동 프로젝트' 카테고리의 다른 글
| [출하 정보 연동 프로젝트] Listener 연결시 TIME_WAIT 발생 (2) | 2025.04.24 |
|---|---|
| [출하 정보 연동 프로젝트] Keyset Pagination을 통한 조회 기능 구현 (0) | 2025.04.22 |
| [출하 정보 연동 프로젝트] 데이터 흐름 정리 및 연동 시스템간 분석 (0) | 2024.09.26 |
