인프런 커뮤니티 질문&답변
작성한 질문수
consumer 재배포시 리밸런싱 이슈
작성
·
144
답변 2
0
안녕하세요~
컨슈머를 재배포할 경우 리밸런싱이 발생하는 것이 맞습니다. 그러나 리밸런싱이 일어나는 것은 전혀 문제되는 일이 아닐 수 있으며, 배포시에는 반드시 발생할 수 밖에 없습니다. 다만, 이 리밸런싱이 과도하게 일어나서 데이터의 지연이 발생하거나 로직상 데이터 유실이 발생하는 것이 문제가 될 수 있습니다.
말씀하신 대로 컨슈머와 실제 로직을 따로 돌리는 서버를 운영할 수도 있으나, 만약에 저라면 그렇게 운영하지 않을 것 같습니다. 왜냐하면 그만큼 네트워크 비용이 발생하기 때문이고, 리밸런싱은 배포 외에는 일어나는 일이 거의 없기 때문입니다. 다만, 아키텍처상 필요에 따라 분리하는 경우도 발생할 수 있을것 같네요.
리밸런싱 때 정상적인 커밋을 하지 못하거나 다른 이슈로 인해 데이터 처리는 중복이 발생할 수 있습니다. 그러한 경우에는 멱등성 처리를 할 수 있도록 처리하는 것이 일반적입니다. 관련된 내용은 아래 발표 내용을 참고하시면 좋을것 같습니다.
그리고 AWS VPC와 네트워크 비용 관련은 상황에 따라 다르고 특정 클라우드 환경에 대해 자세히 말씀드리기 어렵기 때문에 답변 어려운점 양해바랍니다.
0
안녕하세요, 인프런 AI 인턴입니다.
주신 정보 중 직접적으로 답변에 필요한 내용이 없어, 일반적인 지식을 바탕으로 답변드립니다.
consumer가 소비하는 로직이 변경되었을 때, 이를 재배포하면 Kafka Consumer Group 내에서의 리밸런싱이 발생하는 것은 Kafka의 특성 상 일반적인 현상입니다. Consumer Group에서 Consumer의 수가 변하거나, partition assignment에서 변경이 생겼을 때 리밸런싱이 이루어집니다. 이로 인해 잠시 동안 메시지 처리가 지연될 수 있으므로, 이를 관리하는 것이 중요합니다.
실제 운영 환경에서 로직을 변경하고 재배포할 때, 로직 자체를 별도의 서비스로 분리하여 배포하는 경우가 많습니다. 이렇게 하면 Consumer 자체의 변경없이 로직만 갱신할 수 있어 리밸런싱을 최소화하고, 유지보수성을 향상시킬 수 있습니다.
로직을 분리한 서버와 통신 방식으로는 REST API와 gRPC 둘 다 사용됩니다. 선택은 주로 시스템의 특성, 성능 요구사항, 개발 팀의 선호도 등에 따라 결정됩니다. REST API는 상대적으로 구현이 간단하고, 다양한 HTTP 기반 인프라와 호환성이 뛰어나는 반면, gRPC는 높은 성능과 효율적인 통신을 제공하며, 서비스 간의 강력한 인터페이스를 정의할 수 있다는 장점이 있습니다.
따라서 환경과 요구사항을 고려하여 적합한 방식을 선택해야 합니다.
안녕하세요
문제를 정리해보면
리밸런싱이 발생하는 동안 메세지 처리가 멈춤 실제 운영에서 문제가 되어 보임
poll을 해오고 commit을 아직 못한 컨슈머가 있다면 리밸런싱 발생할 경우 에러 발생
커밋되지 않은 이벤트를 다시 컨슘하여 중복 처리 발생
이러한 문제들을 해결하면서 컨슈머 그룹에 속한 컨슈머들 전체를 배포하시는 방법이 구체적으로 어떻게 하고 계시는지 궁금합니다.
추가로 네트워크 비용은 같은 VPC로 컨슈머와 프로세스 서버를 묶으면 그들끼리 통신하는 것에 대한 비용이 발생하지 않는 것으로 알고 있습니다.
이렇게 같은 VPC로 묶을 경우 어떤 문제가 발생하나요?