작성
·
117
1
이전에 아래와 같이 답변을 주신 글이 있습니다.
1. Consumer가 거절하는 경우는 대부분 Celery자체가 어떻게 처리해야 할지 몰라서 일어나는 경우고, 보통 그런경우 새로운 Queue를 만드셔서 넣어 놓으신다음에 엔지니어가 나중에 수동으로 처리하는 경우가 대부분이고, 많은 에러가 난다면 그 전체를 다시 Queue에 넣어 Consumer를 고친 다음에 처리합니다.
2. ACK Timeout이 나는 경우 Broker에서 확답을 못 받았기 때문에 그 메세지는 그대로 있고, Consumer가 재시작하는 순간에 다시 Queue에서 불러와 처리할 수 있습니다.
이에 추가적인 질문을 드리려 합니다.
1번에 대한 질문에서 거절이라는 의미로 "celery에서 작업을 가져왔지만 어떻게 처리할지 모른다"는게 이해가 잘 가지 않네요.
이미 구현된 코드에서 처리할지 모른다는 경우가 어떤게 있을까요? 잘못된 arguments는 에러가 발생할 테고, 작업에서 만약 DB나 I/O가 필요한데 해당 정보가 없다면... 이 또한 예외나 에러가 발생할 텐데.. 이러한 모든 상황은 3번에 포함되는 것이라 1번의 경우가 어떤게 있을지 예시를 혹시 들어주시면 감사드리겠습니다.
2번에 대해 ack는 수신자가 전달하는 것인데 consumer는 queue에서 작업을 가져가서 처리하지만 queue에서는 ack를 timeout 내 수신하지 못한 상황이고, 이 때문에 queue에서 작업을 삭제하지 않았다면 consumer는 동일한 작업을 다시 가져가 중복처리를 하게 되는거 아닌가요? 이에 대한 처리는 실무에서는 어떻게 하는지 알고 싶습니다.
답변 2
0
감사합니다.
Apache Spark를 설치하여 사용할 정도라면 큰 규모의 시스템이 되지 않고서는 고려하기 어려울것 같습니다.
검색을 하니 ack의 timeout과 관련해 부하분산을 구축하면서 트래픽이 증가하면 쉽게 발생하는 문제인것 같네요.
복잡도가 크지 않고, 구축에 부담이 되지 않을 방법에 대해 고려를 해봐야 할것 같습니다. ack timeout 증가를 시키는 방법에 대해서 제시 하던 글도 있었는데 이 또한 단점이 있어 그리 쉽지는 않은 작업 같습니다.
0
안녕하세요 bluebmus님,
1번의 경우 코드 배포를 할 경우에 한사람이 모든 것을 코디네이트하고 작은 프로젝트라면 이런 문제가 안 일어나겠지만, 10명 이상의 엔지니어가 같이 협업을 해서 몇십개의 다른 작업을 만들게 되면 어떻게 될까요? 그리고 파이프라인은 계속 온라인이어야 하는 상태구요. 이럴 경우 배포가 잘못 되거나, 데이터의 포맷이 upstream에서 무심코 바뀌거나 하는 경우를 생각하시면 될 듯 합니다.
2번의 경우의 답변을 드리자면, 일단 이런 상황이 생각보다 빈번하게 일어나고(보통은 네트워크 이슈), 이럴 경우에는 dedupe 로직을 코드에 넣어 주시거나, 데이타 처리라면 downstream인 다음 작업에서 dedupe을 하시면 됩니다.
정말 열심히 공부하시네요 ㅎㅎㅎ 많이 배워가시고 도움이 많이 되셨으면 좋겠습니다. 마지막으로 강의 좋으셨다면 좋은 리뷰 한번 시간내어 주셔서 남겨주시면 감사하겠습니다.
Deduplication에 대한 패키지는 없고, 보통 Downstream에서 Apache Spark를 사용해서 중복 이벤트 아이디 자료들을 제거합니다.
Redis를 사용하신다면, 말씀하신대로 Event id만 저장하시고, 작업 시작하기전에 기존에 처리를 했는지 안했는지를 확인하는 방법도 하나인 듯 합니다.
답변 감사드립니다 ^^
Deduplication에 대해 검색을 해봤을 때 국내는 없는 것 같고, 해외의 경우도 자료가 많지 않더라고요.
관련한 패키지가 있을까요?
제가 생각할 때, worker가 이벤트를 가져왔을 때, 이벤트 id를 lock과 같은 개념으로 redis나 db에 저장을 하여 이중으로 확인하는 과정이 제일 먼저 생각이 나는데요. 이러면 또 고려해야 할게 추가적으로 늘어나기 때문에 복잡도가 크게 증가될거 같더군요.
혹시 필드에서 많이 사용하는 중복 요청 제거 로직은 어떤 패턴을 사용하는지 알 수 있을까 싶습니다.