동적 큐 이름 설정 방법 및 SimpleRabbitListenerContainerFactory의 재정의에 따른 Retry 설정 미적용 관련 질문입니다.

안녕하세요. 수강자님 동적 큐 네임 바인딩과 관련해서는 SpEL도 동작은 하겠으나 (저도 테스트는 안해봤습니다) 제가 이해한 질문은 동적 큐 바인딩을 통해 브로드 캐스트 하는 방식이 맞는지 물어보신거 같습니다. @Configuration public class RabbitMQConfig { // Bean으로 큐 이름 저장 (한 번만 생성) @Bean public String dynamicPublishNotificationQueueName() { return PUBLISH_NOTIFICATION_QUEUE + ":" + UUID.randomUUID().toString(); } @Bean public Queue publishNotificationQueue( @Qualifier("dynamicPublishNotificationQueueName") String queueName) { // 주입받아서 사용 return new Queue(queueName, false, true, true); // durable=false, exclusive=true, autoDelete=true } @Bean public FanoutExchange publishNotificationExchange() { return new FanoutExchange(PUBLISH_NOTIFICATION_EXCHANGE); } @Bean public Binding publishNotificationBinding( Queue publishNotificationQueue, FanoutExchange publishNotificationExchange) { return BindingBuilder .bind(publishNotificationQueue) .to(publishNotificationExchange); } } @Component public class NotificationSubscriber { @RabbitListener(queues = "#{@dynamicPublishNotificationQueueName}") public void consumePublishNotificationMessage(Notification notification) { notificationService.publishNotification(notification); } }이런식으로 작성해서 3개의 인스턴스를 바탕으로 테스트 해보시고, 로깅을 추가해서 테스트 해보시면 좋을거 같습니다. 두번째 질문의 retry 관련해서는, SimpleRabbitListenerContainerFactory 를 수동으로 정의하고 RabbitListenerContainerFactoryConfigurer.configure 를 별도로 핸들링하지 않으면 Spring boot의 property가 작동하지 않는다고 않는다고 알고 있습니다. 아래의 코드를 보시고 테스트를 한번 해보시기 바랍니다. @Bean public SimpleRabbitListenerContainerFactory rabbitListenerContainerFactory( ConnectionFactory connectionFactory) { SimpleRabbitListenerContainerFactory factory = new SimpleRabbitListenerContainerFactory(); factory.setConnectionFactory(connectionFactory); // configurer.configure()를 호출하지 않음! // YAML 설정이 전혀 적용되지 않음 return factory; }이 코드는 아래와 같이 정의할 수 있습니다.@Bean public SimpleRabbitListenerContainerFactory rabbitListenerContainerFactory( ConnectionFactory connectionFactory, RabbitListenerContainerFactoryConfigurer configurer) { // ⭐ 주입 SimpleRabbitListenerContainerFactory factory = new SimpleRabbitListenerContainerFactory(); // Boot 설정 먼저 적용 configurer.configure(factory, connectionFactory); // 추가 커스터마이징 (Boot 설정 덮어쓰기) factory.setDefaultRequeueRejected(false); factory.setMessageConverter(myCustomConverter()); return factory; }configurer의 configure 에 래빗팩토리와 커넥션 팩토리를 통해 application.yml의 설정을 반영해야 합니다. 요건이나 환경이 정확하지 않아서 다소 상세하게 답변 드리기 어려운 점 참고하시기 바랍니다.

RabbitMQ 익스체인지 질문

안녕하세요 수강자님. 질문하신 내용이 정확합니다. Direct exchange에 해당하는 내용인데 제가 착각하고 잘못 설명했네요. 강의 자료 수정하겠습니다. 좋은 내용 알려주셔서 정말 감사드립니다.

강의 자료 관련

안녕하세요. 수강자님. 2강에 강의자료 공지가 있었는데 못보셨나봅니다. https://2dell.notion.site/RabbitMQ-1792d6475f85808eaf95c4b66b4bf7dc?pvs=4 참고하시기 바랍니다. 강의 수강해주셔서 감사드립니다.

지원서 작성 가이드와 샘플이력서 살펴보기 강의질문

안녕하세요. 수강자님포트폴리오는 한장에 하나의 프로젝트가 다 들어가도록 핵심을 정리해서 보여줘야 합니다.물론 신입일 경우 많은 내용을 보여주고 싶은 마음이 있겠으나, 서류를 검토하는 입장에서는 내용이 많다고 더 보지도 않고 오히려 서류가 많아져서 정작 중요하게 부각되어야 할 내용이 보이지 않는 경우가 많습니다.따라서 이력서와 마찬가지로 단순하고 명확하게 작성하는게 중요합니다. 경력직인 경우 포트폴리오는 필요없습니다. 경력기술서에 자세히 적으면 되고, 본인이 직접 한 업무라면 그에 따른 설명도 지원하고자 하는 회사의 업무 방향에 맞게 작성해서 어필해야 합니다. 연관관계가 있다면 더욱 좋겠죠? 무료편에는 회사 공고 분석이 다소 적은 분량으로 올라가있습니다만, 채용 공고를 분석해서 그에 맞는 방향으로 이력서를 수정해서 제출해야 합니다. 참고하시기 바랍니다.

인증 에러

안녕하세요. 메시지 에러 자체는 RabbitMQ의 인증 에러 인데요, 도커 ps와 log를 확인해보시고, management 에 접근해보시기 바랍니다. (admin/admin으로 http://localhost:15672에 접근되는지) 원래 기본 계정은 guest/guest 입니다. 강의에 나온대로 RabbitMQ를 먼저 설치한 뒤 테스트 해보시고 제대로 된다면 도커 설정의 문제이므로 (로그나 권한 실행 타이밍으로 인한 에러)일 이 부분을 체크 먼저 하시고 범위를 줄여오류 사항을 예측해봐야 합니다.구글에서 docker rabbitmq access reused error 로 검색했을때 위에 언급한 문제들의 해결방법이 나오므로 참고해보시되, 먼저 어드민 콘솔 부터 접근 되는지, 계정이 맞는지 부터 점검 해보시기 바랍니다. 감사합니다.

RabbitMQ에서의 트랙잭션 메시징 질문

안녕하세요. 수강자님 DB와 RabbitMQ같은 메시지 브로커의 트랜잭션은 서로 독립적입니다.그래서 RabbitMQ에서 트랜잭션을 구현하려면 DB와는 별도로 자체에서 처리하는 방식으로 "처리는 가능" 합니다. 19강 자료에 나와있는데, amqp-client에 의존성 (starter-amqp에 포함)channel.txSelect():트랜잭션 시작. 이후 모든 메시지 전송 작업은 이 트랜잭션 내에서 실행.channel.txCommit():트랜잭션 커밋. 모든 작업이 성공적으로 수행되었음을 RabbitMQ에 알림.channel.txRollback():트랜잭션 롤백. 트랜잭션 내 작업을 무효화하고 변경사항을 되돌림.이 방식으로 처리는 가능합니다만, 아시다시피 메시지큐는 비동기 환경에서 분산 메시징을 처리하는데 탁월한 미들웨어이기 때문에 이 방식으로 굳이 트랜잭션을 구현하는게 의미있나? 라는 관점에서 보면 구현 비용대비 실효성이 떨어지는 편입니다따라서 19강에서 설명하는 바와 같이 Outbox 패턴(db에 별도로 저장 한 뒤 다른 프로세스를 통해 메시지 처리)이나 TCC와 같은 형태의 재시도와 보정을 통한 멱등성을 보장하는게 훨씬 업무적으로는 좋은 선택이라고 판단합니다. 완강이 얼마 남지 않으셨네요. 마무리 잘 하시기 바랍니다. 감사합니다.

기술분석 - 배포시스템을 구축해야한다면? 부분은 강의가 제공되지 않는건가요?

안녕하세요. 수강자님빌드 배포 관련 사항은 제가 임의의 시나리오를 통해 CI/CD를 개발한다면 어떻게 아케텍처를 분석해서 적용할 수 있는가를 가상으로 설정해서 설명해보려고 넣었습니다만, 중요도에 비해 강의 분량이 다소 과하고 면접에서 필요한 부분의 개념은 강의 자료에 나온 키워드만 이해하셔도 무리없겠다 생각해서 생략 했습니다.해당 설명이 19강에서 다시 언급은 되었는데, 목차에서 관련 내용을 업데이트 하질 못했네요. 혼란을 드려 죄송합니다.블루그린/카나리 배포 정도의 차이와 특징 등을 이해하시면 되는데 여기에 더해서 배포 시스템을 개발 할 때 분석하고 적용해야 할 기능들을 정리하는건 기술면접에 큰 도움은 안될거 같아 강의를 듣는 입장에서 효율상 시간 부담을 덜어 드리고자 과감히 생략했으니 양해 부탁드립니다. 감사합니다.

Nginx와 로드밸런서의 관계

안녕하세요. 질문 알람을 제때 못받아서 답변이 다소 늦어진 점 죄송합니다. 강의에서 언급한 Nginx를 통해 부하분산을 한다와 이후에 로드 밸런싱 기법에 대해서 바로 설명을 이어서 하였습니다. 웹 서버 자체의 로드 밸런싱을 통해 부하분산을 할 수 있다고 이해하시면 되겠습니다.장표의 그림상으로는 별도의 로드밸런서 장비가 있었으나, 없을 경우 웹 서버들로도 충분히 로드밸런싱을 구성할 수 있다는 내용입니다. 감사합니다.

안녕하세요 "섹션2 8. Consumer간 작업 분배" 에서 질문 있습니다.

안녕하세요. 수강자님 컨슈머가 붙은 상태에서 정상적으로 메시지 큐에서 컨슈머에 전달 되면 정확하게는 처리중인 상태입니다.내부에서 따로 설정한 로직 (여기서는 슬립 후 처리) 이후 소진이 완료되고 ack 가 호출되고 이때가 소진이 완료된 시점이 됩니다. 로그가 빨리 올라와서 구분이 어려울 수 있으니 초 단위로 대기를 준 부분이 아직 처리가 안된 상태이고, 이 후에 메시지가 출력된 이후에 ack 가 전달되면 소비가 완료된 상태입니다.해당 강의는 메시지의 전달과 처리, 처리 완료 후 프로세스를 설명한 것이므로 초 단위 처리하는 부분이 실제 비즈니스 영역의 로직을 대체해서 소진 완료 이전에 로직을 실행하고 실행 후 act 가 날라가고 처리완료(소진완료) 된다고 이해하시면 됩니다. 감사합니다.

안녕하세요 섹션2. 12번 강의에서 질문 있습니다.

수강자님 안녕하세요. 특정한 뉴스를 발행하는 경우 데이터가 쌓이는게 우려될 경우 Direct로 설계하는게 맞고, 회원 등급별로 후처리 등을 염두에 둘 경우 팬아웃으로 써도 무방하빈다.pub/sub을 이용한 알람이 주 예제이고, 뉴스구독의 경우 fanout이든, direct이든 topic이든 구현하는 목적에 부합하는 방식으로 선택하시면 되는 문제라서 예제에서 단계별로 흐름을 설명하면서 각 exchange의 특징을 보여들릴 목적이지 뭘 선택하느냐는 실제 개발 환경에서의 목적에 따라 취사선택하시면 됩니다. 발행/구독 모델에 특정 사용자만 매칭해서 쏴야 할 경우, 전체에게 다 발행할 경우, 관심사 별로 유연하게 할 경우 해당 업무는 설계하는 목적에 따라 각각 direct, fanout, topic 을 선택해서 진행하시면 됩니다. 감사합니다.