원글 페이지 : 바로가기
https://idyidy.tistory.com/entry/60-kafka%EB%9E%80이전 블로그에 kafka를 설명하면서 redis와 RabbitMQ에 대해 간단히 설명하였습니다. 저번 블로그에서는 kafka에 대해 자세히 알아보았으니 이번 블로그에서는 redis와 RabbitMQ에 대해 자세히 알아보겠습니다. 접근 방향성 kafka, redis, RabbitMQ는 모두 메세지 큐 형식의 시스템입니다. 또한 이전 블로그에서 kafka는 이벤트 브로커이고, RabbitMQ는 메세지 브로커라고 언급한 바가 있기에 메세지 큐, 메세지/이벤트 브로커에 대해 다시 한번 자세히 보고 넘어가겠습니다. 메세지 큐란? 메세지 지향 미들웨어(MOM, Message Oriented Middleware)를 구현한 시스템으로 데이터 교환을 위해 나온 기술입니다. 메세지 큐 구조 – Producer : 정보를 제공하는 자 – Comsumer : 정보를 제공받아서 사용하려는 자 – Message Queue : Producer의 데이터를 임시 저장 및 consumer에 제공하는 곳 메세지 큐 장점 1. Message Queue에 임시 저장소가 있기에 나중에 처리가 가능합니다. 2. 애플리케이션과 분리되어 있습니다. 3. Producer와 Comsumer 서비스를 확장할 수 있습니다. 4. consumer 서비스가 장애가 생기더라도 애플리케이션이 중단되는 것은 아니며 메세지는 계속 Message Queue에 남아있습니다. 5. Produder가 생성한 메세지가 Message Queue에 들어가면 Comsumer에게 서비스가 전달되는 것을 보장합니다. 메세지 브로커란? 메세지 브로커는 producer가 생산한 메세지를 메세지를 큐에 저장하고, 저장된 데이터를 consumer가 가져갈 수 있도록 중간 다리 역할을 하는 것을 브로커라고 합니다. 보통 서로 다른 시스템에서 데이터를 비동기로 처리하기 위해 사용하고, 이러한 구조를 pub/sub 구조라고 합니다. 또한 전 블로그에서도 설명했듯이, pub/sub의 대표적인 소프트웨어는 redis, RabbitMQ가 있습니다. 이벤트 브로커란? 이벤트 브로커는 기본적으로 메세지 브로커의 기능을 가지고 있어 메세지 브로커 역할도 수행할 수 있습니다. 대표적인 소프트웨어는 kafka가 있습니다. 메세지 브로커와 이벤트 브로커의 차이점 가장 큰 차이점은 이벤트 브로커는 publisher가 생산한 이벤트를 바로 삭제하지 않고 저장하는 방식입니다. 이로 인해 consumer가 오류가 나거나 장애가 일어나도 그 시점에서 이벤트를 처리할 수 있습니다. 이벤트 브로커가 메세지 브로커보다 더 많은 양의 데이터를 처리할 수 있는 능력이 있습니다. 위에 설명한 메세지 브로커에 대해 생각하고 본격적으로 redis와 RabbitMQ에 대해 설명하겠습니다. Redis란? 출처 : https://velog.io/@djc06048/%EA%B0%9C%EB%85%90%EC%A0%95%EB%A6%AC-Kafka-Redis-RabbitMQ%EB%9E%80 Redis(Remote Dictionary Server)는 고가용성으로 Key-Value 구조의 비정형 데이터를 저장하고 관리하기 위한 오픈 소스 기반의 NoSQL입니다. 또한 In-Memory 데이터 구조를 가진 저장소이고, 주로 DB, Cache, 메세지 큐, Shared Memory 용도로 사용됩니다. In-Memory 더보기 인메모리는 RAM에 데이터를 올려서 사용하는 방식입니다. 즉, 메모리 내부에서 데이터가 처리되기에 저장하거나 조회할 때 하드디스크를 거치는 과정이 없어 속도가 빠르지만, RAM의 특성인 휘발성 때문에 메모리 용량을 초과하는 데이터를 처리할 경우에 데이터가 유실될 수 있는 위험이 존재합니다. 하지만 redis를 사용하게 되면 데이터가 유실될 수 있고, 데이터베이스는 물리 디스크에 직접 쓰기 때문에 서버에 문제가 발생하더라도 데이터가 손실되지 않는데 인메모리 데이터 구조를 가진 저장소인 redis 왜 쓰는 걸까? redis를 사용하는 이유 첫째로, Key를 통해 결과를 빠르게 가져올 수 있습니다. 둘째로, 규모가 작거나 사용자가 많지 않은 서비스의 경우 데이터베이스로도 무리가 가지 않지만, 사용자가 늘어난다면 데이터베이스가 과부하될 수 있기에 캐시 서버를 도입하여 사용하는데, 이 캐시 서버를 이용할 수 있는 것이 redis입니다. 즉 같은 요청이 여러 번 들어오는 경우에 매번 데이터베이스를 거치는 것이 아닌 캐시 서버에 저장된 결괏값을 바로 줍니다. 이로 인해 데이터베이스의 부하가 줄어들고, 서비스 속도도 느려지지 않는 장점이 있기에 사용합니다. *알아도 쓸모 있을까(?) 하는 정보 : 캐시는 파레토 법칙에서 나왔으며 모든 결과가 아닌 20퍼만 캐싱해도 전체적으로 효율을 끌어올릴 수 있다고 합니다. 캐시 서버는 Look aside cache 패턴과 Write Back 패턴이 존재합니다. Look aside cache 출처 : https://velog.io/@hope1213/Redis%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C 1. 클라이언트가 데이터를 요청합니다. 2. 웹서버는 데이터가 존재하는지 캐시 서버에 먼저 확인합니다. 3. 캐시 서버에 데이터가 있으면 DB에 데이터를 조회하지 않고 캐시 서버에 있는 결괏값을 클라이언트에게 바로 반환합니다. 4. 캐시 서버에 데이터가 없으면 DB에 데이터를 조회하여 캐시 서버에 저장하고 결과값을 클라이언트에게 반환합니다. Write Back 1. 웹서버는 모든 데이터를 캐시 서버에 저장합니다. 2. 캐시 서버에 특정 시간 동안 데이터가 저장됩니다. 3. 캐시 서버에 있는 데이터를 DB에 저장합니다. 4. DB에 저장된 캐시 서버의 데이터를 삭제합니다. 이때 Writer Back 방식은 매번 DB에 접근할 필요 없이 특정 시점에만 DB에 접근해 속도 저하를 방지할 수 있지만, 처음 캐시에 저장할 때 장애가 발생하면 데이터가 날아갈 위험이 존재합니다. redis특징 – key-value 방식입니다. – 인메모리를 사용하기에 데이터 처리가 빠릅니다. – 한 번에 하나의 명령만 처리할 수 있는 싱글 스레드입니다. 그렇기에 처리하는 데 시간이 오래 걸리는 요청은 안 하는 것이 좋습니다. 그 외 redis에 관한 내용 redis는 인메모리 기법을 사용하기에 데이터가 날아갈 위험이 있습니다. 위 문제를 해결하기 위해 순간적으로 메모리에 있는 내용 전체를 디스크에 옮겨 담는 방식인 RDB(Snapshotting) 방식과 Redis의 모든 연산을 log파일에 기록하는 AOF(Append On File)방식이 있습니다. RabbitMQ란? RabbitMQ는 AMQP를 구현하여 Producer와 Consumer 사이에 메세지를 중계해주는 메세지 브로커입니다. *AMQP(Advenced Message Queuing Protocol) : 메세지 지향 미들웨어를 위한 개방형 표준 응용 계층 프로토 * 미들웨어 : 개발자와 운영자가 애플리케이션을 더욱 효율적으로 구축하고 배포하도록 돕는 소프트웨어 및 클라우드 서비스 출처 : https://velog.io/@holicme7/Apache-Kafka-%EC%B9%B4%ED%94%84%EC%B9%B4%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80 1. Producer : 메세지를 생성하고 발송하는 주체입니다. 2. Consumer : 메세지를 받아서 처리하는 주체입니다. 3. Exchange : Producer로부터 전달받은 메세지를 어떤 큐에 전달할 지 결정하는 객체입니다. Binding 규칙에 따라 큐로 보내는 방식은 4가지 타입이 존재합니다. 4. Binding : Exchange와 Queue를 연결하는 관계입니다. Exchange에서 Binding 규칙에 의해 적절한 큐로 메세지를 전달합니다. 5. Queue : RabbitMQ 안에서 메세지를 일시적으로 저장하는 장소입니다. Consumer들은 Queue에 저장된 메세지를 받습니다. 여기서 Binding 규칙에 따라 큐로 보내는 4가지 방식에 대해 더욱 자세히 들어가 보겠습니다. Exchange Type 4가지 Exchange Type에는 Direction Exchange, Topic Exchange, Headers Exchange, Fanout Exchange 총 4가지 타입이 있습니다. Direction Exchange Direction Exchange Dirction Exchange는 큐와 Exchange가 라우팅 키를 이용해 바인딩되는 기법입니다. Direction Exchange는 다양한 소비자에게 일을 분배하기 위해 사용됩니다. 즉, 메세지가 queue가 아닌 consumer들 사이에서 로드밸런싱 됩니다. Topic Exchange Topic Exchange 메세지에 포함된 라우팅 키를 패턴에 이용하여 메세지를 라우팅 하는 방식입니다. 이때 키 전체가 일치하거나 일부 패턴과 일치하는 모든 큐로 메세지가 전달됩니다. Fanout Exchange direction Exchange와 다르게 전체 큐를 대상으로 처리하는 기법입니다. 즉, Fanout Exchange로 발행된 메세지는 Fanout Exchange에 연결된 모든 큐에 전달되고, 자연스럽게 라우팅 키를 평가할 필요가 없어지기에 상당한 성능적인 이점이 있습니다. Header Exchange 라우팅 키를 사용하지 않고, 메세지 속성 중 headers 테이블을 사용해 특정한 규칙의 라우팅을 처리하는 기법입니다. 정리 redis : Key-Value 구조의 비정형 데이터를 저장하고 관리하기 위한 오픈 소스 기반의 NoSQL RabbitMQ : produce와 consumer 사이에 메세지를 중계해주는 메세지 브로커