채팅 방식 질문입니다!

안녕하세요. 제 강의에 WebSocket을 연결해서 STOMP 프로토콜로 채팅 메시지를 보내는 부분도 있고, RabbitMQ로 웹소켓의 메시지 브로커 역할을 하는 부분도 있습니다. 내장 브로커를 써도 되고 RabbitMQ를 써도 되는데, 가급적 확장성을 고려하면 RabbitMQ 메시징을 사용하는 것을 추천 드립니다.

강의와 살짝 무관하지만.. MQ에 대한 질문이 있습니다!

안녕하세요.Queue를 유지하는 방식은 여러가지 유형이 지원됩니다. 데드레터가 아니더라도 구성하기 나름이라고 생각합니다.가장 쉬운건 팬아웃으로 지정한 뒤 메시지를 여러 큐에 복제하는 방식도 있고보관하는 방식 (MessageDeliveryMode.PERSISTENT 옵션이나 Lazy Queue)등도 있고로직으로 처리 (로그 파일 떨구기, 큐 전송 전에 raw 를 DB에 저장)등 간접 방식으로 처리하는 게 하나 있을거고클러스터를 구성해서 복제를 하되 특정 노드는 백업용도로만 사용하면 소실이 되더라도 백업본을 뒤져오면 될거 같긴 합니다. 시도해보진 않았으나 지원되는 방식은 많으니 고민하기 나름이라고 봅니다. 두번째는 마지막 강의에 보면 TCC에 대한 내용이 나옵니다.이때 DB에 저장한 상태에서 컨슈머를 처리한족에서 시간 배치, 일배치 등으로 전체 raw 데이터의 대사 비교를 요청하면 API 형태로 재전송하는 규약을 만들어주면 됩니다.즉, 큐를 어딘가에 저장하고 있다가 특정 오프셋 부터 재전송하는 API를 제공하면 문제 없이 해당 요건도 처리가 가능합니다. 답변이 되었는지 모르겠네요.완강이 얼마 남지 않았으니 화이팅 하세요!감사합니다.

챕터18 retry yml 강의 부분 질문

안녕하세요. 수강자님.retry 설정은 내부적으로 Consumer (@RabbitListener) -> SimpleMessageListenerContainer (RabbitMQ 메시지 수신) -> RetryTemplate (설정된 max-attempts만큼 재시도)의 흐름을 탑니다.- 성공 → 정상 메시지 처리 완료- 실패 → 재시도 진행- 최대 재시도 초과 → DLQ 또는 폐기 처리이런 흐름인데, SimpleMessageListenerContainer 가 생성될 때 메시지를 받을 큐와 리스너가 등록이 됩니다. @RabbitListener를 사용하면 내부적으로 SimpleMessageListenerContainer가 자동으로 생성되기 때문에 retry 설정을 읽어서 exception 이 발생할 경우 RetryTemplate을 사용해서 자동으로 설정된 속성에 해당하는 작업을 수행하게 됩니다. 두번째 질문은 Spring 프레임워크에서 제공하는 Retry 기능입니다. 동작방식은 RabbitListener의 retry와는 다르지만, 동일한 기능을 제공합니다. (즉, 설정된 조건에 따라 예외가 발생하면 특정 횟수만큼 자동으로 재시도를 합니다)내부적으로는 Spring AOP와 프록시를 기반으로 메서드 단위에서 동작하고, RetryableInterceptor 를 사용하므로 호출 구조는 @RabbitListener로 설정해서 메시지 소비 단위로 처리하는 SimpleMessageListenerContainer 와는 다르므로 아래의 아티클을 읽어보시기 바랍니다. (https://hseong.tistory.com/89 와 https://codesnapmag.hashnode.dev/spring-retryable-annotation 를 참고) 감사합니다.

tutorial-step4 질문

안녕하세요. 수강자님 FanoutExchange는 라우팅 키를 무시하고 전체 브로드캐스트 되므로 질문하신 내용이 맞습니다. (아마 강의중간에 Fanout에서는 라우팅 키를 무시한다고 설명한 부분이 있을겁니다) 다만, 클라이언트의 설정(WebSocket)에 의해 특정 토픽만 구독하기 때문에 원하는 뉴스만 받게 됩니다.RabbitMQ에서 Consumer로 갈때는 fanout이기 때문에 모든 큐에 뉴스가 전달이 되고 Consumer에서 WebSocket에 전달되는 구조에서는 config.enableSimpleBroker("/topic"); 와 WebSocket의 SimpMessagingTemplate을 사용한 설정으로 인해 클라이언트가 해당하는 토픽(/topic/java)만 구독을 하게 됩니다. WebSocket은 모든 클라이언트에게 메시지를 보낼수도 있고, 특정 토픽만 선택적으로 필터링 해서 전달할수도 있습니다. 만약 웹소켓을 쓰지 않고 특정 토픽에 전달해서 해당 뉴스만 구독해야 한다면 Direct나 Topic 익스체인지를 써야 동일하게 동작하게 됩니다. 다만 이 경우 모든 클라이언트가 메시지를 받아야 하는 경우는 부적합 합니다. 정리하면 Fanout은 모든 큐에 메시지를 브로드캐스트하지만 WebSocket을 이용해 특정 뉴스 타입만 선택적으로 구독할 수 있습니다. (서로 독립적으로 동작합니다) 따라서 Pub/Sub의 성격을 이용해서 브로드 캐스트를 하는 것은 Direct나 Topic 보다 Fanout이 적합하고, 전체 브로드캐스트가 필요하지 않은 Pub/Sub의 일부 제한이 필요한 경우는 WebSocket과 STOMP를 통헤서 필터링 할 수 있다고 이해하시면 될거 같습니다. 감사합니다.

pub/sub, producer/consumer 차이

안녕하세요. 두개의 차이점중 가장 큰 부분은 하나의 메시지를 하나의 컨슈머가 처리하느냐, 여러 컨슈머가 처리하느냐로 판단하시면 될거 같습니다.Publish/Subscribe 패턴은 브로드캐스트 용도로 Fanout, Topic 익스체인지로 연결된 모든 큐에 메시지가 복제되서 전달이 되는것이고 Producer/Consumer 패턴은 하나의 큐를 하나의 컨슈머가(Direct) 처리 하는 방식입니다. 즉, 다수의 서비스가 동일한 메시지를 필요로 하면 pub/sub을, 하나의 메시지를 하나의 컨슈머가 처리하고 로드밸런싱을 통해 분배를 할 경우 producer/consumer 라고 보시면 되고 websocket은 프로토콜이나, 굳이 구조로 나누자면 pub/sub 방식이라고 보시면 되겠습니다. 감사합니다.

모듈질문

안녕하세요. 문의하신 사항이 모두 맞습니다.부연드리자면, 1번 모듈 구성은 회사 업무 구조를 따라 다소 다를 수 있습니다만, 저는 API 서버(클라이언트는 브라우저나 앱에서 접근) 와 프로듀서, 컨슈모 모듈을 분리하는 것을 추천 드립니다.이는 역할이 분명한 성격을 띄고 있고, 일반 비즈니스 모듈(API)의 배포가 빈번할텐데 이때 한묶음으로 프로듀서, 컨슈머가 같이 딸려서 배포가 다간다는게 잠재적으로 장애 위험이 있다고 봐야 하지 않을까 싶어서 나누는 걸 추천 드립니다. 2번, 워커(컨슈머) 노드들의 확장이 하나일때와 여러개일 때, 트래픽 증가에 따른 분배 처리를 보여드리려는 의도입니다. 노드는 트래픽 규모에 따라서 적절히 스케일링 하고, 큐 서버에서 분배 처리를 RR 혹은 Prefech 로 분해할 수 있다는 개념을 보여드리기 위해서 설정한 예제라고 보시면 됩니다. 감사합니다.

클러스터와 페더레이션 관련 PDF 내용은 어디서 확인할 수 있나요?

안녕하세요. 수강자님,강의 자료는 동영상 플레이어 하단에 수업 노트 보기에 이미 올라가 있습니다.(사진) 혹시 몰라서 PDF로 같이 강의에 첨부 드렸으니 강의를 다시 한번 확인 해주세요~완강 축하드립니다.수강평도 남겨주시면 감사하겠습니다.

msa 환경에서 브로드캐스트는 어떻게 이루어지나요?

안녕하세요. 8080, 8081을 설정해서 분배하는 것은 WorkQueue 방식의 예제로 설명한 것이고, 전체 구독자에게 발행하는 것은 Pub/Sub 모델이나 Fanout Exchange로 설정하면 됩니다.이 부분은 MSA 환경과 관련이 없고(MSA든 아니든 상관없이) 큐를 바라보고 있는 워커 노드가 중간 브로커(Exchange)를 통해 연결이 되면 동시에 Consume을 할 수 있습니다. 강의에 나온 pub/sub 모델과 Routing 모델 강의까지 살펴보시면 도움이 될거 같습니다.즐거운 공부 되세요~

첨부pdf 코드블럭 글자 수 넘어가면 짤리는 것 같아요

안녕하세요. 학습자님, 어제 안그래도 제보를 받고 강의자료에 대한 공지를 작성해서 새 소식으로 발행 했습니다. 안녕하세요. 코드빌런입니다. 노션에서 PDF로 변환해서 강의자료를 제공했습니다만, 코드가 길 경우 뒷 부분 코드가 짤린채로 PDF가 만들어진 것으로 확인 되고 있습니다.해서, 각 강의 자료 제공(각 챕터의 첫 강의들) 되는 영상의 수업 노트에 노션 문서의 주소들을 따로 정리해서 공유 했으니 수업에 차질이 없도록 사이트에서 원본 내용을 참고하시기 바랍니다. 감사합니다.문의 주셔서 감사드리고, 언제든 불편함이 있으면 제보해주세요.

10.Pub-Sub모델을 이용한 실시간 알림 (WebSocket, STOMP 이용) part 1 의 자료

안녕하세. 학습자님강의자료를 다시 첨부 했습니다. 구분이 필요할까봐 10.pub_sub을이용한실시간알림.pdf 이라고 이름은 바꿔서 등록했으니, 다시 한번 다운로드 해주세요.하시고 안되신다면 브라우저 기록 한번 지워보시기 시도해주시고, 그래도 안되면 다시 글을 남겨주시면 제가 인프런 측에 문의를 해보도록 하겠습니다. 불편을 드려서 죄송합니다. 열공하세요!