1. 분산 캐시(distributed cache) eg. Redis
분산 캐시는 데이터를 메모리에 저장해서 빠르게 접근할 수 있도록 하는 기술이다. 여러 노드에 데이터를 분산 저장해서 높은 가용성과 확장성을 제공하고, 주로 데이터베이스의 부하를 줄이며, 응답시간을 단축하는 데 사용된다.
주요 기능으로는 자주 접근되는 데이터를 메모리에 저장하고 이를 통해 데이터베이스 쿼리 또는 계산 작업을 생략함으로써 빠르게 데이터를 조회할 수 있도록 한다.
또한, 분산 저장 방식은 높은 가용성과 확장성을 제공한다. 예를 들면 자주 사용되는 사용자 세션 정보를 레디스와 같은 분산 캐시에 저장하여 빠른 조회 뿐만 아니라 여러 서버 간에 세션 데이터를 공유할 수 있으므로 스케일 아웃에도 용이하다.
2. 메시지 브로커(message broker) eg. RabbitMQ
메시지 브로커는 애플리케이션 간의 메시지 전달을 중개하는 역할이다.
메시지브로커는 메시지를 발행자(프로듀서)로부터 받아서 큐에 저장하고, 이를 소비자(컨슈머)에게 전달한다. 이를 통해 컴포넌트 간 통신을 비동기적으로 처리할 수 있다. 그리고 애플리케이션의 구성 요소들을 느슨하게 결합시키고 서로 독립적으로 운영할 수 있게 한다.
메시지브로커는 point-to-point와 pub-sub 발행/구독 메시징으로 나눌 수 있는데, 포인트투포인트는 일대일 관계인 메시지 큐에서 각 메시지는 하나의 수신자에게만 전달되며, 오직 한번만 이용되는 패턴이다. 보통 한번만 실행되어야하는 경우 호출되고, 예를 들면 급여나 재무 관련된 트랜잭션 처리에 사용할 수 있다.
발행/구독 메시징은 각 메시지의 생성자는 이를 토픽에 발행하고, 다수의 메시지 이용자는 메시지를 수신하고 싶은 토픽을 구독한다. 그리고 어떤 토픽에 대해 발행된 모든 메시지는 이를 구독한 모든 애플이케이션에 배포되는 방식이다. (일대다 브로드캐스트 스타일의 배포 방법)
예를 들면, 항공편의 착륙 시간 또는 지연 상태에 관한 업데이트를 배포할 경우, 여러 관계자가 이 정보를 활용할 수 있으므로 펍섭 방식이 적합하다고 볼 수 있다.
3. 이벤트 브로커(event broker) eg. Apache Kafka
이벤트 브로커는 실시간으로 발생하는 이벤트 데이터를 수집하고, 이를 처리 및 전달하는 역할을 한다. 데이터가 발생한 순서대로 이벤트를 처리하며, 대규모 스트리밍 데이터의 실시간 처리가 가능하다.
시스템에서 발생하는 모든 상태 변화를 이벤트로 기록하고, 이것을 기반으로 시스템의 현재 상태를 재구성하거나 과거 상태를 복원할 수도 있다.
또한, 대규모 데이터를 처리하기 위해 고안된 시스템으로 데이터가 손실되지 않도록 내구성을 보장하며, 여러 노드에 걸쳐 데이터를 분산 저장한다.
pub-sub(발행/구독) 패턴을 기반으로 동작하며, 데이터를 토픽으로 구독하는 형태로 운영한다. 보통 로그 수집이나 실시간 분석(사용자 맞춤형 추천 제공 등) 등에 사용할 수 있다.
🌟 추가 질문
📍 캐시를 분산해서 얻는 장점은 무엇을까?
한 서버에 오류가 발생하더라도 다른 서버를 통해 조회가 가능하다. 그리고 한 쪽으로만 집중적으로 부하가 가지 않는다는 장점이 있다.
📍 그렇다면 여러 대의 클러스터를 구성해야 된다고 할 때, 몇 대의 클러스터에 몇 대의 노드가 있는 것이 이상적일까?
보통 홀수 세대부터 시작을 한다. 이유는 일단 마스터라고 하는 메인 노드가 전체적인 관리를 한다고 가정했을 때, 이 노드가 죽는 경우 다른 노드로 마스터를 결정하게 된다. 이때 만약 노드가 2대라면 한 대가 죽었을 때 한쪽에서는 데이터를 잃어 버렸는지 아닌지 알 수가 없게 된다. 따라서 최소 3대부터 설정한 다음 5대, 7대 등 홀수로 늘려나가는 편이 좋다.
📍 분산 캐시의 위치는 어디가 적합할까?
빠른 성능을 위해 최대한 애플리케이션에 가까이 두는 것이 좋다. 제일 가까운 곳이라고 하면 그 서버 자체일 수도 있다.
만약 애플리케이션의 성능이 굉장히 중요하다고 했을 때, 애플리케이션이 있는 서버에 함께 설치를 해서 클러스터 안에 포함시키는 방법도 존재한다.
이 방식이 아니더라도 AWS 같은 경우 같은 리전에 같은 데이터센터에 들어갈 수 있게 하는 방법도 있고, 실제 온프레미스에서도 캐시와 애플리케이션 서버는 가까우면 가까울수록 좋다.
또한, 분산 애플리케이션 환경에서 어떻게 동시성 문제를 처리하는가 했을 때 많이 볼 수 있는 방법이 레디스의 분산 캐시 또는 데이터베이스의 낙관적 락과 비관적 락이 존재한다.
(분산 환경일 경우 여러 대의 서버를 띄우기 때문에 메서드에 싱크로나이즈드를 걸어봤자 동시성 문제가 해결되지 않는다.)
📍 RabbitMQ 와 Kafka 차이는?
RabbitMQ는 메시지 교환, 즉 애플리케이션 간에 메시지를 교환을 위해 중앙화된 버스를 사용하자는 의미에서 나온 기술이고, pub-sub보다는 큐를 사용한 방식이 굉장히 많다.
큐 한쪽에 계속 메시지를 보내고, 큐가 중간에 길이 나눠져서 그 조건에 따라 어떤 메시지는 어디로 보내고 어떤 메시지는 다른곳으로 보내고 하는 방식이다. 그렇게 하다 보니 RabbitMQ는 라우팅에 특화된 장점이 있고, 특별히 어떤 메시지에 어떤 자료 콘텐츠가 있느냐에 따라서 라우팅도 가능하다.
기본적인 개념은 일단 상대방한테 메시지를 보낼 때 상대방이 누구인지에 대해 어느 정도 인식이 있어야 되는게 큐라고 볼 수 있다. 그리고 메시지가 전달되면 큐에서 빼서 버리기 때문에 휘발성 메시지를 보내는게 많고, 이걸 보통 우체부로 예시를 들 수 있다.
하지만, 휘발성 자료가 주가 된 방식이라 어느 정도의 용량만 커버할 수 있는 걸로 처음에 개발이 되었고, 많은 회사에서 이 방식을 사용하면서 점점 스케일 아웃에 문제가 발생하게 된다. RabbitMQ는 처음부터 단일 서버나 몇 개의 클러스터를 구성해도 각각의 클러스터에서 따로 작동하게 구성하다 보니 성능적으로 어느 정도 이상이 되면 더 이상 커버가 되지 않는다.
따라서 대규모 데이터를 처리하기 위해 토픽을 만들어서 발행하는 게시판 형식의 카프카가 만들어졌고, 물론 실시간 이벤트 처리도 가능하지만, 메시지 큐를 대신하기도 한다.
이벤트가 일어나면 해당 토픽에 발행하고, 모든 메시지들은 큐처럼 쌓이지만 지워지지 않는다. 따라서 읽는 사람 입장에선 구독하는 날짜에 상관없이 이미 모든 메시지가 쌓여있기 때문에 이전 게시물도 확인이 가능하다. 따라서 대용량 처리가 가능하며, 로그 처리나 메시징으로도 많이 쓰인다.
참고 자료
메시지 브로커란?
[Architecture] 메시지 브로커와 이벤트 브로커 - 메시지와 이벤트 그리고 RabbitMQ 와 Kafka
