작성
·
487
0
답변 1
0
안녕하세요, 이도원입니다.
말씀하신 내용처럼 서비스 간의 통신 요청을 한 다음 응답을 기대리지 않고 다른 작업을 할 수 있다는게 Kafka나 RabbiMQ와 같은 메시징 큐 서비스의 특징입니다. 물론 Kafka의 요청을 처리하기 위한 용도로 도입하는 것이 아닌, 사용자의 요청을 필요로 하는 곳으로 전달해 주는 용도이고 그 작업을 Kafka에서 넘겨 줌으로써, 해당 서비스에서는 다른 작업을 처리할 수 있게 됩니다. GET방식에서의 비동기도 요청에 대한 응답이 오기까지 기다리지 않고 다른 작업을 진행하면서, 응답이 전달되면, 해당 처리를 하게 할 수 있습니다. 예를 들어 아래와 같은 대시보드 화면에서 각각의 그래프를 표시하는 데이터를 하나씩 GET 방식으로 요청했다고 생각해 보면, 데이터를 응답 받지 못한 그래프는 Loading 상태로 표시되면서, 응답이 전달된 요청에 대한 그래프는 바로 그래프를 표시하게 됩니다 바로 각각의 그래프를 처리하는 작업에서 MSA로 구현되고, 비동기로 응답된 데이터를 처리할 수 있게 됩니다.
<https://www.elastic.co/guide/en/kibana/current/dashboard.html>
WebFlux와 Message Broker는 사용 용도가 다르다고 생각됩니다. Spring WebFlux는 Spring Framework에서 그동안 동기 방식으로 처리되었던, ServletReqeust, ServletResponse 방식 대신 ServerRequest, ServerReponse를 사용하면서 비동기 프로그래밍을 처리하는 것이고, Messaging Broker는 시스템 간, 서비스 간, 애플리케이션 간에 메시지를 송수신 하기 위해 사용되는 기술입니다. 메시지로 전달될 수 있는 형태는 다양하며, 연결할 수 있는 시스템, 서비스, 애플리케이션도 다양합니다. 예를 들어, GPS와 연동되어 실시간 현재 위치(위도, 경도)를 데이터베이스에 저장하는 애플리케이션이 있다고 가정해 봅시다. GPS 정보를 1초에도 수십/수백 건의 데이터가 발생할 수 있고, 그 데이터를 데이터베이스에 저장하는 것은 성능도 문제고, 비용도 상당히 발생하는 작업이 될 겁니다. 이때 Messaging Broker를 도입하여, 발생하는 데이터를 송신하고, Broker에서는 Streming 된 데이터를 DB에 저장할 수도 있습니다. (https://www.confluent.io/product/ksql/)
추가 질문사항 있으시면 언제든지 글 남겨 주세요.
감사합니다.
자세한 답변 너무 감사합니다!!