메시지 큐 기반 아키텍처가 요즘 인기가 떨어지는 이유는 뭔가요?

• 2010년초까지만 해도 MQ기반 분산 시스템 구축 얘기가 많았는데 요즘은 글들이 별로 없음
• 생각하는 몇가지 이론들은 다음과 같은데, 이중 하나일지 다른 분들 생각은 어떤지 궁금함
  • Redis가 대부분의 케이스 및 캐싱까지 처리해서 더 이상 별도의 메시지 브로커 운영이 쓸모없어짐. Kafka는 정말 대규모로 가버림.
  • DB(광범위하게 봤을때)가 대규모 처리를 훨씬 잘하게 되면서, "일시적인"처리들을 메인 저장소에서 처리하게 됨
  • MQ 기반 아키텍처가 기대만큼 잘 작동하지 않는 다는 것을 알아버려서 이제 다른 방식을 사용함
  • 사실은 이제 MQ 기술이 성숙기에 접어들어서, 사람들이 관련 글을 쓸만큼 흥미롭지는 않음. 하지만 여전히 널리 사용되고 있음

hnthrowaway_99

• 2000년대 후반부터 2010년 초반의 많은 "인기" 아키텍처가 결국 "당신은 구글이 아님. 당신 회사는 구글이 절대 될 수 없음" 사실을 깨닳고 사라졌음
• 그 시기에는 "성공한 대기업이 구축한 방식으로 구축" 하려는 열망이 컸음
• 하지만 그 이후로 많은 사람들이 99%의 기업에게는 복잡성이 필요하지 않다는 것을 깨달았음
• 하드웨어와 표준 데이터베이스가 훨씬 더 좋아지면서 이러한 "Scalability Trick"이 필요한 기업은 점점 더 줄어들고 있음
• "이 모든걸 Postgres로 하면 안 되는 이유가 있을까요?"의 내 기준은 10년전 보다 훨씬 높아졌음
• 이 댓글에 달린 댓글들
  • 이제 적절한 비용으로 사용가능한 훨씬 큰 싱글 머신이 생김. 예전엔 소규모 클러스터가 필요했지만, 이제 싱글 시스템으로도 다양한 워크로드를 많이 수용 가능
  • 솔직히 말하면, 난 구글에서 큐를 제거하는 여러개의 프로젝트에 참여했었음. 그러니 아마 그 이상일지도(인기가 떨어진 것 이상)

biglain

• 냉소적이지만, 내 생각에 MQ 아키텍처와 이에 대한 블로깅은 "Resume Driven Development"였음. 실제로는 모노리스를 넘어 확장할 필요없이 단일 노트북에서 실행가능한 일을 하는.
• 이 사람들이 아마도 한달에 수천만원씩 AWS 비용을 내는 악몽같은 Microservice 재앙을 구축하는 사람들이었고
• "실제 비즈니스 문제를 실용적인 방식으로 해결하는 것보다, 기술적인 업적을 쌓는 것을 경력의 우선순위로 삼는 사람들"이 요즘은 AI에 대해 Hyping하며 블로그에 글을 올리고 있음

tuckerconnelly

• 최근 마이크로서비스가 너무 복잡하고 중복 코드가 많아서 모놀리스로 전환했음. 마이크로서비스가 없으면 메시지 큐의 필요성이 줄어듦
• 비동기 작업의 경우 한 프로젝트에 RabbitMQ를 사용했는데, 너무 오래되고 과도하게 설계된 느낌이 들었음
• 그리고 그 주변의 많은 도구(Celery)는 redis(bullmq)를 중심으로 구축된 최신 도구만큼 좋지도 않았음
• 다단계의 DAG 스타일 프로세스의 경우, 나는 가능하면 하나의 큰 작업에서 모든 것을 처리하거나 작은 수의 작업으로 나누어서 처리하는 것을 선호
• 정말 DAG가 필요하다면 이를 위해 특별히 제작된 도구(Airflow)가 있음. 하지만 문제를 디버깅하기 어렵다고 들었기 때문에 가급적 피하는 것이 좋음
• 나는 Redis의 멀티노드 아키텍처가 터무니없이 지나치게 복잡해서 확장에 문제가 있어 단일 노드를 고수중. 하지만 수작업으로 샤딩하는 것은 나한테는 괜찮고 잘 작동함
• 이글에 대한 kypro의 댓글
  • 내 경험상 모놀리스는 복잡성을 줄이는 것이 아니라 복잡성을 이동시킬 뿐
  • 모놀리스의 가장 큰 문제점은 도메인 간의 관심사가 명확하고 명시적으로 분리되어 있지 않기 때문에 시간이 지나면 모놀리스 코드베이스가 고도로 상호 연결된 스파게티 코드의 난장판으로 변하기 쉽다는 점
  • 특히 많은 개발자와 함께 대규모 프로젝트를 구축하는 경우, 자신이 다루는 코드의 도메인 복잡성을 모두 이해하지 못하는 개발자가 많다면 더욱 그러함
  • 모놀리스는 개발자가 적은 소규모 프로젝트에 적합하지만, 그렇지 않은 경우에는 몇 년 안에 대부분 모놀리스를 구축한 것을 후회하게 될 것
  • 또한 중복된 코드 포인트에 대해서도 동의하지 않음. 같은 언어를 사용하고 프로젝트 간에 패키지를 공유한다고 가정할 때 왜 그것이 큰 문제가 되는지 모르겠음
  • 어쨌든 마이크로 서비스 작업을 하면서 이런 문제는 제가 겪어본 적이 없음
  • 또한 마이크로서비스가 평균적으로 모놀리스보다 더 복잡한지에 대해서도 의문을 제기하고 싶음
  • 내가 마이크로서비스 아키텍처에서 가장 좋아하는 점은 개별 마이크로서비스를 이해하고 기여하기가 얼마나 간단한가 하는 점
  • 마이크로서비스의 아키텍처와 프로비저닝은 더 복잡할 수 있지만, 마이크로서비스를 작업하는 개발자의 입장에서는 모노리스에 비해 훨씬 더 간단하게 작업할 수 있음

democracy

• 이 생각이 맞는 것 같음 : "MQ 기술은 이제 막 성숙해져서 글을 쓸 만큼 흥미롭지는 않지만 여전히 널리 사용되고 있음"
• 메시징 기반 아키텍처는 매우 인기 있음
• 이 글에 대한 댓글들
  • casper14 : 동의함. 그냥 하나의 도구가 되었음. 더 이상 클라우드에서 가상 머신을 사용하는 방법에 대해 글을 쓰는 사람이 아무도 없는 것처럼
  • bwhaley : 이게 바로 정답. 대규모로 실행되는 거의 모든 분산 시스템은 어느 정도 용량으로 메시지 큐를 사용한다고 장담할 수 있음
  • ipsum2 : 이게 유력함. 예전에는 앵귤러를 리액트로 다시 작성하는 것에 대한 포스팅이 인기가 있었지만, 지금은 모두들 그냥 리액트를 사용하거나 리액트를 vue로 리라이팅하는 것에 대한 글을 씀

busterarm

• 인기 없는 답변을 주려고 해
• 큐, 스트림 및 Pub/Sub는 대부분의 엔지니어가 잘 이해하지 못하는 개념
  • 언제 필요한지 모르고, 제대로 사용하는 방법도 모르며, 엉뚱한 용도로 사용함
  • 나는 여전히 위의 모든 것(SQS/SNS/RabbitMQ/Kafka/Google Pub/Sub)으로 작업하고 있음
• 나는 북미의 상위 3~4개 학교 출신의 가장 "뛰어난" 엔지니어들만 고용하는 회사에서 일하고 있으며, 거의 모든 엔지니어에게 이것이 첫 직장임
• 우리 엔지니어들은 다음과 같은 미친 짓을 해왔음:
  • RabbitMQ에서 수만 개의 100MB 메시지를 순식간에 큐에 올려놓고 왜 폭파되는지 궁금해함
  • 이렇게 하지 말라는 모든 경고에도 불구하고 일반적으로 RabbitMQ에서 상당히 큰 용량의 메시지를 보냄
  • 2024년 최신 RabbitMQ 버전에서 새 프로젝트를 시작하고 클래식 큐를 사용하려고 함
  • 복제 정책 없이 쿼럼 대기열을 만들거나 말 그대로 HA를 만들기 위해 아무 것도 하지 않음
  • 관리 사용자가 게스트/게스트인 상태에서 인터넷에 클러스터를 노출함
  • 조직의 가장 고위급 아키텍트가 새로운 아키텍처 패턴을 선언하고, 조직 전체 회의를 개최하고 데모를 함
    • 메시지를 대기열에 집어넣은 다음 백채널을 만들어 두 번째 소비자가 대기열에 있는 메시지를 온디맨드 처리할 수 있도록 하는 새로운 미덕/패턴을 찬양함 (그리고 더 이상 대기열이 아니게 함)
    • 그리고 나를 제외하고는 아무도 "왜 순서대로 처리해야 하는 메시지를 대기열에 넣는가?"라고 말하지 않았고, 그 '패턴'이 자리를 잡았음!
  • Kafka를 기본 메시지 큐로 사용하기
  • 중앙 데이터센터에서 전 세계에 분산된 데이터센터로 데이터를 전송하고, 각 대상 데이터센터가 업데이트된 객체를 수신했음을 확인할 때까지 객체에 대한 글로벌 잠금과 모든 작업을 수행. 데이터가 AJAX 요청과 함께 전송되었으므로 이 프로세스는 비동기식이라고 주장
• 결과적으로 사람들은 그다지 대단한 일을 할 필요가 없는데도 여전히 잘 해내고 있음. 따라서 도구는 오용, 남용, 과소 사용되기도 함
• 잘 사용되고 있는 곳에서는 아마 그런 얘기를 듣지 못할 것
• 중요한 사실: 우리 조직에는 엔지니어 1명당 30개가 넘는 마이크로서비스가 있음. 제발 날 죽여줘. 거대한 모노레포에 수천 개의 마이크로서비스가 있는 다른 조직에서 일하느니 말 그대로 커트 코베인이 되고 싶음
• 이 글에 대한 댓글들
  • zug_zug : 실제 데이터를 통해 이 이론을 뒷받침해 보면
    • 뉴욕 에서 Akka(스칼라의 이벤트 기반 큐잉)를 사용하는 스타트업에 근무 했었음
    • 왜 그랬을까? 이전 직장의 관리자가 이 방법으로 "모든 것이 느렸을 때" 회사를 "구했다"고 해서 새 직장에서 이를 의무화했기 때문일까?
    • 큐잉이 필요했던 업무는 무엇이었을까? 웹사이트를 통해 직원들의 401k를 보여주고, 자산 구성을 조정하도록 하고, 하루에 수백 통의 이메일을 발송한 것이 전부
    • 예상대로 사람들은 401k 웹사이트에 로그인하는 경우가 거의 없었음
    • 그곳에서 일한 지 1년 정도 지나서 나는 서버가 계속 잘못 구성되어 있었고 기본적으로 웹 요청에 대한 동시성이 0이라는 사실을 깨달았음
    • (2개의 프로덕션 서버가 항상 필요한 모든 트래픽을 처리하고 있었기 때문에 이를 인지하지 못함)
    • 결국 불필요하고 불필요한 복잡성을 가중시킨다는 이유로 Akka를 제거
    • 지난 달에 이 회사는 현금 회수 옵션으로 또 다른 펀딩 라운드를 진행했는데, 분명히 가치가 올라갔고 여전히 잘하고 있는 것 같음
  • scary-size : 이건 정말 "뛰어난" 엔지니어만 고용하는 것 같지는 않은데?
  • roncesvalles : 디자인 리뷰 프로세스가 없는 것 같아. 그리고 나라면 유명 대학 졸업자보다, 이름 없는 대학교 출신 2-5년차 개발자를 뽑을 것 같아. 소프트웨어 엔지니어가 커리어의 첫 5년 동안 배우고 성장하는 양은 엄청나며, 아마도 나머지 커리어를 합친 것보다 더 많을 것.

burutthrow

• MQ는 꽤나 상품화(commoditized)되었다고 생각함
• Confluent나 RedPanda 또는 MSK를 서비스로 구매하면 Kafka를 직접 관리할 필요가 없음
• 변경 데이터 캡처(CDC)도 매우 훌륭하고 메인스트림이 되었음. RDBMS에 데이터를 쓴 다음 변경 데이터를 캡처하여 다른 시스템으로 전파하는 것은 비교적 쉬움
• 예를 들어, 메시지 큐는 CDC 시스템이 메시지를 전달하는 데 사용하는 백본에 불과하기 때문에 이러한 패턴은 사람들이 카프카에 대해 쓰지 않는다는 것을 의미
• 이러한 아키텍처는 분명히 여전히 존재하며 대부분 조직의 제약 조건을 충족함
• Kafka와 같이 한번 쓰고 여러 번 읽는 큐가 있는 경우 조직의 다른 부분에 API를 노출하는 것. 많은 회사에서 이 패턴을 사용하여 여러 팀 간에 데이터를 섞어 사용
• 많은 마이크로서비스를 소유하고 있는 소규모 팀은 이력서 중심의 개발자처럼 느껴지지만, 하지만 엔지니어가 100명 이상인 회사에서는 이 패턴이 합리적

angarg12

• MQ는 분산 시스템 도구 상자에 있는 도구임. 적절할 때는 훌륭하게 작동
• 당신의 이론이 정말 맞다면 난 이거라고 생각함 "사람들은 보통 새롭고 반짝이는 것에 대해 블로그 포스팅을 작성함"
• 나는 개인적으로 디자인에 항상 큐를 사용하며, 특히 디커플링이 높은 서로 다른 시스템 간에 데이터를 전송할 때 큐를 사용
• 내가 겪은 유일한 고통은 업스트림 시스템에서 7일 동안의 데이터를 다시 채워서 오래된 요청으로 큐가 막혔을 때였음
  • 정상적으로 실행했다면 모든 데이터를 처리하는 데 100시간 이상이 걸렸을 것이고, 새로운 데이터의 지연 시간도 엄청나게 늘어났을 것
  • 해결책은 큐를 수동으로 제거하고 누락된 최신 데이터를 수동으로 다시 채우는 것이었음
• 바인딩되지 않은 큐 크기에 주의해야 하지만 여전히 훌륭한 도구라고 생각

rossdavidh

• MQ는 Gartner Hype Cycle 에서
  • '부풀려진 기대의 정점(Peak of inflated expectations)'을 지나고
  • '환멸의 골짜기(trough of disillusinment)'를 지나
  • '깨달음의 비탈길(Slope of Enlightment)' 심지어는 '생산성의 고원(plateau of productivity)'으로 향해가고 있음

robertclaus

• "분명히 우리 모두는 여전히 메시지 큐와 워커를 사용하고 있으며, 단지 그것에 대해 글을 쓰지 않을 뿐"이라는 댓글이 마이크로서비스와 실질적인 확장성에 대한 논쟁 때문에 뒤쪽에 묻혀 있다는 점이 매우 흥미로움
• 이 댓글을 읽는 주니어 엔지니어는 더 이상 웹 서버의 과중한 연산을 워커에 떠넘겨서는 안 된다는 잘못된 인상을 받을 수 있음

pm90

• 그 기술이 지루해졌기에 관련 블로그 글이 줄어들었음
• 이건 좋은 것임. 예를 들어 RabbitMQ 공식 문서가 훨씬 더 좋고 매우 유용함
• 사람들은 Postgres/MySQL을 사용하는 것처럼 이를 주력으로 사용함
• 아키텍처 등을 설계하는 데 놀라운 기술도 필요하지 않음
• 난 지루한 소프트웨어를 사랑함 "I love boring software"

slowmovintarget

• 이러한 아키텍처의 대부분은 기업 데이터 센터에서 실행되었음
• 클라우드로 전환 후 소규모 상태 비저장 서비스를 만들면서(SPA의 등장) 복잡한 단계별 이벤트 중심 시스템이 덜 필요해짐
• 예를 들어 AWS에서는 SQS와 약간의 SNS를 사용하거나 몇 가지에 Kinesis를 사용하면 충분. 여기서는 MQ가 더 이상 설계의 중심이 되지 않음
• MQ 기반 아키텍처는 데이터 처리에는 좋지만 대화형 웹 사이트에는 적합하지 않으며, 대부분의 사람들이 대화형 웹 사이트를 구축한다면 선택의 여지가 없어 보임
• 나는 여전히 데이터 처리를 위한 이벤트 시스템을 설계함(특히 새로운 사실이 있지만 "틀렸거나" 이전 시점에 다른 정보를 알고 있어야 하는 불변의 비즈니스 데이터의 경우)
• 하지만 대부분의 앱에서는... 필요하지 않음

mannyv

• 우리 전체 백엔드는 큐 기반임
• 비동기식이고 빠른 응답 시간이 필요하지 않은 경우 큐를 사용할 것. 쉽고 안정적이며 큐가 람다를 구동할 수 있음
• 또한 큐를 사용하면 메트릭과 성능 데이터를 더 쉽게 수집 가능.
  • 부하가 많을 때는 큐에 최대 수백만 개의 메시지까지 부풀어 올랐다가 시간이 지나면서 줄어들게 되고,
  • 또는 원하는 대로 수백 개의 람다를 생성하여 모든 메시지를 처리할 수도 있음

vishnugupta

• 내 경험에 비추어 볼 때 MQ는 추상화 되어 버린거지, 사라지지는 않았음
• 예를 들어 SQS + 폴링에 대한 대기열은 서버를 적게 호출하는 프로세스가 되었음. 어딘가에 메시지 큐가 있지만 노출되지 않았을 뿐
• SQS보다 한 단계 더 추상화된 AWS SNS는 기능이 매우 풍부해져서 사실상 SQS를 대체할 수 있게 되었음
• 또한 스트리밍은 매우 안정적인 기술이 되었기 때문에 큐를 스트리밍 파이프로 사용하던 사용 사례는 스트리밍 전용으로 마이그레이션 되었음

memset

• 람다(클라우드 펑션)이 더 대중화되고 여러 플랫폼에서 지원되기 때문 일 수 있음
• 무언가를 큐에 추가하면 결국 큐에서 빼내고 처리해야 함. 람다는 한 번의 호출로 이 작업을 수행. 또한 워커를 실행하거나 확장할 필요가 없음
• Kafka는 임시 데이터 저장소로 사용되고, 스트림에서 수집하는 데 큰 생태계가 있기 때문에 계속 인기를 누리고 있다고 생각
• 나는 개인적으로 큐를 많이 사용하며 오픈 소스 SQS 대안을 구축하고 있음. 오픈 소스 람다 대체도 유용할지 궁금

liampulles

• "이제 MQ 기술이 성숙기에 접어들어서, 사람들이 관련 글을 쓸만큼 흥미롭지는 않음. 하지만 여전히 널리 사용되고 있음"
  • 이게 맞음. 간단한 Pub/Sub 메시징을 사용하는 비동기 통신의 간단한 사용 사례는 매우 유용하고 사용하기가 너무 어렵지 않다고 생각
• 우리(개발자 커뮤니티로서)는 이벤트 소싱, 복잡한 네트워크 및 불필요한 규모 구축을 극복했음. 즉, 우리는 과대광고 주기를 지났음
• 우리 팀은 비동기 Pub/Sub 및 동기 Request/Response에 NATS를 사용
  • 이는 명령 기반 모델이며 우리가 보낸 모든 메시지가 포함된 거대한 로그 테이블을 가지고 있음
  • 스키마와 이러한 메시지의 사용은 우리 팀 내부적이며, 사용 후 NATS에서 삭제됨
  • 우리는 at-least-once delivery를 하며 메시지 핸들러는 멱등성을 가질 것으로 예상함
• NATS의 잘못된 구성으로 인해 메시지가 재생되거나 메시지가 누락되는 문제가 한두 가지 있었지만 대체로 매우 성공적이었고, 우리는 3명으로 구성된 개발팀이었음
• 내 생각에는 Kubernetes와 같은 것임. 핵심만 지키고 영리하게 노력하지 않으면 잘 작동함

[finnchoi]

큐가 필요한 적절한 상황이 있습니다. 그러나 대부분의 규모와 사용 형태에서는 큐를 사용하거나 클러스터를 구성해서 동작시키는 것이 복잡도 상승과 성능면에서는 크게 장점이 없는 경우가 많습니다. 확장성과 대규모 데이터를 고려하여 구성된 큰 기업들이 자랑하는 복잡한 구조가 나의 시스템에 적절해질 시점은 도래하지 않을 수 있습니다.

기술적으로 매력도가 높은 신기술과 멋진 구조도 현실적인 문제를 고민하여 적절한 솔루션을 선택하는 것이 필요합니다. 대부분의 경우에는 처리할 큰 데이터도 없고, PostgreSQL로 처리 가능한 경우도 많습니다.

저희는 이런 문제를 인식하고 단순한 구조에서 TB 단위의 데이터를 단일 노드에서 처리 가능한 DB를 개발하고 있습니다. 조금은 조심스럽지만, 또 다른 옵션으로 살펴보시는 것을 권해 드립니다.
판례 데이터를 빠르게 검색 가능한 상태로 만들기

[dakbutfly]

대중적으로 절차지향은 이해하기 쉬우나 MQ 방식은 바로 와 닿지 않거나, 구조를 이해 하는데 어려움이 있다고 생각 합니다. 회사는 일반적으로 지식 수준이 동일 하지 않은 경우가 더러 있는데, 이때 잘못된 지식으로 MQ 를 쓰면 지옥이 되는 것 같습니다.

이거는 MQ 뿐만 아니라 대부분 어느 정도 지식을 요구 하는 기술들이 전반적인 교육 없이 적용 했을 때 늘 발생하는 문제라고 생각 합니다.

[nemorize]

PHP는 MQ가 사실상 필수...

[halfenif]

뜨끔!

지금 Toy Project로 Quee라는 이름이 들어간 것을 진행하고 있는데 말입니다.

[kandk]

솔직히 99%의 우리나라 내에서만 서비스할꺼면 다 필요없다고 봅니다..

[superwoou]

서비스 범위 보다는 서비스 성질/얼마나 비용 효율을 따져야 하느냐가 중요하지 않을까요?

[bus710]

아무래도 결정을 내리는 절차가 수직적이기 때문에 “절차지향적”인 것이 더 선호 되거나 적합하게 여겨지는 것일까요?
만약 각 부서와 팀이 느슨하게 조직되어 있다면 절차지향적이지 않은 아키텍쳐가 좀 더 원활히 동작하고, 그래서 이런 큐들의 응용이 더 잘 동작할 수 있는 것일지 궁금하네요.

[savvykang]

이력서 주도 개발이 이런 유행 현상을 관통하는 키워드인 것 같네요

[hyeonseokoh94]

이야 명언이네요 이력서 주도 개발이라..

[savvykang]

자매품으로 설레발 주도 개발도 있습니다