예시 두개가 납득이 잘 가지않네요 ㅠㅠ

35 câu hỏi đã được viết

1

좋은 질문을 주셔서 감사합니다, 목동개발자님. 말씀하신 포인트가 맞습니다. 응답을 바로 반환해야 하는 경우, 메시지 큐를 사용하면 불필요한 홉이 생겨 응답 속도가 느려질 수 있습니다.

다만, 메시지 큐는 비동기 처리가 필요하거나 리소스 분리가 필요한 상황에서 특히 유용합니다. 즉각적인 응답이 요구되지 않거나, 시스템 간 작업을 독립적으로 처리할 필요가 있을 때 큐를 사용하는 것이 적합할 수 있습니다. 또한, 큐는 재시도 메커니즘을 지원하고, 대규모 시스템에서의 안정성을 높이는 장점이 있습니다. 이런 이유로 저 같은 경우에는 예시 1에서는 메시지 큐를 적용하여 자료에 반영했습니다.

• User -> Message Queue -> OrderService 이러한 구조에서 사용자가 OrderService에 요청을 보낼 때, 메시지 큐를 거쳐야 하는 구조는 불필요한 네트워크 홉을 추가하고 실시간 응답 속도를 저하시킬 수 있습니다. 이러한 사용자-facing 서비스에는 메시지 큐가 적합하지 않을 수 있습니다. 즉, 실시간으로 응답이 필요한 상호작용에서는 큐가 불필요한 지연을 초래할 수 있습니다.

• OrderService -> 내부 시스템: 반면, OrderService가 Analytics, Fulfillment System, Email Notification Service와 같은 비동기 작업을 수행할 때는 메시지 큐가 유용합니다. 이 과정에서는 즉각적인 응답이 요구되지 않으며, 메시지 큐를 통해 비동기로 처리할 수 있어 시스템 간 결합도를 낮추고 확장성 및 안정성을 높일 수 있습니다.

사용자-facing 부분과 비동기 백그라운드 작업을 구분해 메시지 큐를 적절히 사용하는 것이 중요하다는 점을 자료에서 설명하려고 했는데 설명이 부족했던 것 같습니다. 죄송합니다.

예시 2에서도 좋은 관점에서 질문을 주셨습니다. 수강생 분들이 배울 수 있는 부분이 될 것 같습니다.

예시 2의 시나리오는 사용자가 "piano cat"을 검색할 때, Google 서버는 데이터베이스에서 가장 관련성 높은 10개의 결과를 조회해야 합니다. 그리고, 트래픽이 갑자기 증가하여 초당 약 100만 건의 요청이 발생하고, 이로 인해 서버가 모든 요청에 즉각적으로 응답하기 어려운 상황이 됩니다. 이때 메시지 큐를 사용하여 각 검색 요청을 큐에 넣고 순차적으로 처리하는 방식으로 부하를 관리하려고 하는 것을 나타내었습니다.

이 구조에서 여러 요청을 동시에 받아 순차적으로 처리하면 서버의 과부하를 방지할 수 있으며, Google Server가 다른 작업을 처리할 여유도 확보할 수 있습니다. 또한, 서버가 다운되거나 장애가 발생하더라도 큐에 요청이 남아 있어 복구 후에도 처리가 가능합니다.

그러나, 목동개발자님께서 말씀하신 것처럼 사용자는 큐에 요청이 쌓일수록 대기 시간이 길어져, 실시간 검색 요청에서는 불편함을 느낄 수 있습니다. 100만 건의 요청이 쌓이면 상당한 지연이 발생할 수 있습니다.따라서, 실시간 응답 요구에 부적합 하다고 할 수 있습니다. 이 방식은 트래픽 급증 시 서버를 보호할 수 있지만, 사용자 경험이 중요한 실시간 검색 서비스에서는 적합하지 않을 수 있습니다.

따라서, 메시지 큐가 트래픽 급증 시 서버 부하를 관리하는 데 유용하다는 점을 보여드리고 있지만, 실시간성을 요구하는 서비스에서는 캐시나 분산 시스템과의 조합이 필요하다는 점을 이해하실 수 있도록 구성하고자 했습니다.

좋은 관점에서의, 수강생분들께 도움이 되는 포인트의 질문 해주셔서 감사합니다.

그리고, 다시 한번 저의 설명이 부족했던 점 사과의 말씀드리며,

추후 강의 자료에서 보충하도록 하겠습니다.

0

안녕하세요, 인프런 AI 인턴입니다. 목동 개발자님께서 제시한 두 가지 예시에 대해 설명드리겠습니다.

Ex1: Message Queue와 OrderService

• 유리한 점: 메시지 큐를 사용하는 두 가지 주요 이유는 비동기 처리와 시스템의 디커플링(Decoupling)입니다.

  • 비동기 처리: 메시지 큐는 사용자의 요청을 즉시 수락하고 나중에 처리할 수 있도록 합니다. 이는 사용자가 즉각적인 응답을 받지 않아도 되는 상황에서 시스템의 전반적인 성능을 개선할 수 있습니다.
    
  • 디커플링: 메시지 큐를 통해 OrderService와 사용자 요청 간의 의존성이 줄어듭니다. 이는 시스템 확장성과 유지보수를 용이하게 합니다.
    

• Network Hop의 문제: 유효하지 않다면 메시지 큐가 불필요한 네트워크 홉을 추가하여 지연을 발생시킬 수 있습니다. 다만, 시스템 설계에서 이점을 제공할 수 있는 경우도 많습니다. 각종 실패 처리 및 재시도 메커니즘이 시스템 안정성을 보장할 수 있기 때문입니다.

유사한 질문에 대한 답변을 아래 링크에서 확인하실 수 있습니다:
- “메시지 큐의 장단점에 대한 이해”

Ex2: Google Server와 Results Store

• 이 패턴은 종종 구글 검색과 같은 대규모 시스템에서 효과를 볼 수 있습니다. 검색 요청을 처리하는 담당을 분리하여 더 나은 리소스 관리가 가능합니다.
  
• 리소스 효율성: 특정 서버가 지속적으로 검색 쿼리를 처리할 필요가 없어짐으로써 서버의 부하가 줄어듭니다.
  
• 응답 속도: 큐를 사용하면 처리가 매우 복잡하거나 시간이 오래 걸릴 수 있는 요청을 균일하게 처리할 수 있습니다. 결과적으로 전체적인 서비스 안정성과 효율성을 높일 수 있습니다.
  

관련된 더 많은 정보는 다음을 참조해 주세요:
- “검색 시스템에서의 메시지 큐 사용 사례”

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.