그레이스풀 셧다운과 데몬 스레드의 관계 질문

Question

안녕하세요 강사님 좋은 강의 잘 듣고 있습니다 강의에서 말씀하신 그레이스풀 셧다운과 데몬스레드의 관계까 제가 이해한 의미와 조금 달라서 여쭤봅니다. 저는 그레이스풀 셧다운을 진행 중인 작업을 마무리하고 안전하게 종료하는 것으로 이해하고 있는데 데몬 스레드는 JVM 종료 시 작업이 중간에 끊길 수도 있다고 알고 있습니다. 그래서 “레디스 이벤트 처리 과정이 백그라운드에서 알아서 들어가기 때문에 데몬 스레드를 사용하면 자연스럽게 그레이스풀 셧다운이 된다”라는 설명에서 레디스의 백그라운드 이벤트 처리 방식과 데몬 스레드 사용이 어떤 식으로 연결되는지를 조금 더 구체적으로 알고 싶습니다. 또, 메시지를 소비하는 도중에 애플리케이션이 종료된다면 메시지 손실 가능성은 없는지도 궁금합니다. 그리고 실무 환경에서도 보통 이런 방식(데몬 스레드 기반)으로 Redis Pub/Sub 리스너를 구성하는지 아니면 다른 종료 처리 방식을 더 선호하는지도 알고 싶습니다. 좋은 강의 잘 듣고있습니다! 감사합니다.

Hong · Answer

안녕하세요 swws7946님 질문 감사합니다. 말씀해주신 부분처럼 그레이스풀 셧다운 데몬 스레드의 관계에서는 좀 상충되는거 같네요. 제가 언급했던 자연스럽게 그레이스풀이 진행이 된다라는 것이 조금 부정확한거 같습니다. 더 정확히 말하면, 애플리케이션 종료 시 별도의 종료 트리거 없이 빠르게 정리된다가 맞는거 같네요.   Redis Pub/Sub은 기본적으로 이벤트 기반의 비동기 처리 입니다. 그런 형태로 인해서 각 메시지마다 독립적으로 처리가 되고, 상태를 저장하지도 않는 특징이 있습니다. 그래서 데몬 스레드를 사용해도 상대적으로 안전한 것인지 지금 생각해보면 완벽한 그세리으풀이 구현이 된건 아닌거 같네요. 저의 실수인거 같습니다.   메시지 손실에 대해서는 당연하게 존재합니다. 예를들면 메세지를 Redis에서 받았지만, 처리중인 상태에서 애플리케이션이 종료가 된다던지, 네트워크 지연이나 JSON을 파싱하는 과정에서 종료가 된다던지 다분하게 발생가능합니다. 또한 Redis Pub/Sub은 전송 후 잊어버리는 Fire And Forget이라는 형태이기 떄문에 실질적으로 저장을 하면서 전송하는 것이 아니기 떄무ㅐㄴ이죠.   하지만 메시지라는 부분에 좀 더 집중하시면 좋을꺼 같습니다. 유실이 되는 경우도 허용한다는 것이 기본적으로 깔려있기 떄문입니다. 하지만 나는 이 부분도 싫다면, Kafka와 같이 중간 저장을 해주는 MSQ를 사용하시는것이 더 좋습니다.   저는 채팅 메시지가 몇 개가 손실되는 것보다는 시스템의 단순함과 좀 더 응답성에 초점을 맞추어서 촬영된 내용이라고 봐주시면 됩니다. 하지만 결제정보나 좀 더 중요한 부분이 있다면 당연하게요 더 신중하게 고려가 되어야 하겠죠 질문 감사합니다 :)