[프로젝트 소개 및 설계 자료 조사] 클라우드 톡.

실시간 메시징 처리 서비스

HTTP 는 단방향 통신이죠. 우리가 보여지는 웹 페이지 말이에요.

사용자들은 일방적으로 미리 제공되는 페이지를 보게되고, 서버는 사용자의 반응에 따라서 응답을 할 때도 일방적으로 데이터를 보내게 돼요. 이런식으로 일방향을 왔다갔다 해도 뭐, 통신은 가능하긴 하죠!

 

그런데 메시지 처리는 속도, 그리고 동시성이 가장 중요한 포인트입니다.

 

우리는 양방향 처리가 가능한 메시징 서비스를 만드려고 해요

 

웹 소켓(Web Socket)과 Redis

HTTP 가 단방향 통신인 데에 반해, 웹 소켓은 양방향 통신이랍니다.

한 번 연결을 맺으면, 연결이 끊이지 않고 데이터를 실시간으로 주고받을 수 있죠.

 

이것이 바로 단방향 통신과의 차이점입니다.

단방향으로 통신하면 매 순간 연결을 새로 만들어야 하지요.

 

웹소켓의 STOMP 프로토콜 (Simple Text Oriented Messaging Protocol)

스트리밍 텍스트 지향 프로토콜이랍니다~ 그래서 보통 jackson-databind 라이브러리도 함께 추가해서 JSON 형식으로 데이터를 처리하곤 해요.

 

먼저 엔드포인트를 설정해서, 특정 엔드포인트에 여러 topic 을 등록할 수 있는데, 이때 topic 은 Spring 내부에서 path url 로 구분됩니다. 예를들어 /topic/chat 의 path 와 /user/online 의 path 는 다른 토픽으로 구분됩니다.

 

이렇게 path 를 구분해서 메시지를 전달하는 역할을 하는건 `메시지 브로커` 입니다. 클라이언트가 보낸 메시지를 라우팅하고, 구독한 클라이언트에게 메시지를 전달할 수 있어요.

 

네! 동일한 엔드포인트에서, 토픽 별로, 실시간 양방향으로 통신할 수 있게 해주는 프로토콜이랍니다!!!

 

 

 

그렇다면 양방향 통신에 Redis 가 필요한 이유는 뭘까요?

Redis 는 인메모리 데이터베이스(In-Memory Database)입니다.

그래요. 데이터를 디스크가 아닌 메모리에 저장한다는 의미지요.

그렇기 때문에 초고속 성능을 자랑하게 됩니다.

어머, 속도는 실시간 처리에서 필수적인 특성아닌가요?

 

네? 그러면 일반적인 RDBMS, 전통적인 관계형 데이터베이스냐고요?

아니요. Redis 는 NoSQL(Not Only SQL) 데이터베이스입니다.

데이터를 키(Key)-값(Value) 형태로 저장하지요. 그래서 스키마나 테이블로 고정된 형태로 저장되어 있다기보다는, 특정 자료구조(List, Set, Hash) 등의 형태로 저장합니다. 그래요. 테이블이나 데이터 간의 관계가 없어요!

 

유연하고 자유로운 데이터 관리가 가능하겠군요?

그럼으로 인해, NoSQL은 빠른 읽기/쓰기 성능과 단순한 데이터 모델을 지향했다는 것을 알 수 있습니다.

 

 

그러니까,

• User(회원) 데이터나 친구 관계 데이터 등의 영구적 데이터 저장이 필요하면 RDBMS를 추가로 도입하여, 서비스 로직을 구성할 수 있을 것이다.
• 그러나 지금 실시간으로, 채팅방에 누가 들어왔는지, 지금 온라인 상태인지 오프라인 상태인지, 메시지를 실시간으로 전송하고 수신받는 상황, 그러니까 상당히 일시적이고 휘발적이지만 신속함이 요구되는 데이터들은 Redis 로 처리하면 좋을 것이다.

 

 

Redis Client : Lettuce

네? 상추요?

 

Lettuce는 영어로 상추라는 의미긴 하지만, Redis 와 통신을 편리하게 추상화해놓은 도구입니다. RedisTemplate 같은 도구를 사용해서 손쉽게 Redis 를 구현할 수 있는 구현체 라이브러리라고 할 수 있지요~

 

Redis 와 애플리케이션(Spring) 간에 네트워크 통신을 추상화 해준다고 볼 수 있습니다. Spring Data Redis에서 RedisTemplate이나 Repository 방식으로 데이터를 다루게 해준다는 의미에요.

 

일반적으로 spring-data-redis 는 lettuce-core 가 만들어놓은 추상화 라이브러리 중, RedisTemplate을 Config(설정) 파일에서 Bean으로 등록해서 사용합니다. 그래요, Redis DB는 보통 따로 데이터 접근기술(JPA, MyBatis 등)을 두지 않는답니다! 바로 서비스 로직에 직접 호출해 사용합니다.

 

 

오.. 그러면 서비스 서버의 전원을 꺼버리면 Redis 데이터가 다 날아가겠네요?

오.. 네 아무래도........

.

.

.

일줄 알았겠지만, Redis 는 Persistence 설정을 하면 데이터를 디스크에 저장할 수도 있답니다. RDB 라는 Redis DataBase 를 이용해서 특정 시점의 메모리를 저장하여 스냅샷을 만들 수도 있고, AOF 라는 Append Only File 을 이용해서 모든 변경 사항을 로그로 기록할 수도 있어요! 데이터 백업도 가능하답니다?

 

오오 ~ 이건 나중에 더 알아봅시다

 

 

PUB / SUB, 그리고 TOPIC - Redis 의 구현 방식

Redis 는 메시지를 발행(Publish)하고 구독(Subscribe)하는 방식으로 동작합니다. 그리고 하나의 구독 채널은 Topic 이라고 불리죠.

 

어어..? pub/sub...... ? Java Design Pattern 에서 Observer 패턴이 생각난 당신! 백엔드 개발자시군요!

 

예.. 아무튼 신문을 구독하는 형식으로 Redis 는 구현됩니다. 이 설계 동작 방식에 대해서는 구현해보면서 차차 더 알아가보도록 해보자구요~ 왠지 메시징 큐가 무조건 쓰일거같은 느낌~