Redis - Hash

Redis의 Hash 자료구조란?

field-value 쌍의 집합으로 구성된 레코드 타입

 

출처: 인프런 - jscode, 섹션 8. 비전공자도 이해할 수 있는 Redis 중급/실전

 

마치 json의 key-value와 같은 형태를 떠올리면 이해하기 쉬울 것 같다.

하나의 Key값에 여러 개의 field-value 쌍이 존재하는 형태이다.

 

해시는 객체를 표현하기에 편리하고, 하나의 해시에 담을 수 있는 필드 수에는 (메모리만 충분하다면) 실질적인 한계가 없다.

덕분에 애플리케이션에서 해시를 여러 용도로 자유롭게 활용할 수 있다.

---

Hash 기본 명령어

 

데이터 삽입

// HSET [KEY] [FIELD]  [VALUE]
HSET bike:1 model Deimos

// 여러 개의 field-value 삽입 또한 가능
HSET bike:1 brand Ergonom type 'Enduro bikes' price 4972

 

Key에 저장된 모든 field-value 조회

// HGETALL [KEY]
HGETALL bike:1

1) "model"
2) "Deimos"
3) "brand"
4) "Ergonom"
5) "type"
6) "Enduro bikes"

 

특정 field의 value 조회

// HGET [KEY] [FIELD]
HGET bike:1 model
"Deimos"

 

2개 이상의 field의 value 조회

// HMGET [KEY] [FIELD 1] [FIELD 2] ...
HMGET bike:1 model brand

1) "Deimos"
2) "Ergonom"

 

value에 TTL 걸기

// HEXPIRE [KEY] [SECONDS] [NX | XX | GT | LT] FIELDS [NUMFIELDS] [FIELD1] [FIELD2]...
HEXPIRE bike:1 300 FIELDS 2 model brand

 

• NX : 필드에 만료 시간이 없을 때만 새로 설정
• XX : 필드에 이미 만료 시간이 있을 때만 설정
• GT :  새 만료 시간이 기존 값보다 길 때만 설정
• LT : 새 만료 시간이 기존 값보다 짧을 때만 설정
• NUMFIELDS : 지정할 필드 수

여기서 [NX | XX | GT | LT] 는 필수가 아니다. ( 미입력 시 조건 없이 무조건 만료 설정 )

 

위 명령어들 이외에도 수 많은 Hash 관련 명령어가 존재하기 때문에 더 많은 정보를 확인하고 싶다면 아래 공식 문서를 참고하면 좋을 것 같다....

https://redis.io/docs/latest/commands/#hash

Commands

 

왜 세션 스토리지를 Redis(Hash)로 구축해야 할까? 

 

서버가 2대 이상인 경우

 

우리가 일반적으로 사용하는 프레임워크(Spring Boot, Nest.js 등)는 각 프레임워크마다 세션을 다루는 방식이 상이한데,

Spring Boot를 예로 들면 그 밑단의 서블릿 컨테이너인 Tomcat이 HttpSession 구현을 제공한다.

즉, Spring Boot에서 실제적인 세션을 다루는 주체는 Tomcat이다.

출처: https://docs.spring.io/spring-boot-data-geode-build/1.7.x/reference/html5/guides/caching-http-session.html

 

 

이때 Tomcat의 StandardManager가 활성 세션을 저장하는 방식이다.

출처: https://tomcat.apache.org/tomcat-10.1-doc/config/manager.html

 

여기서 default one이 바로 StandardManager이다.

 

활성 세션(Active Session)이란?

현재 만료되지 않은, 유효한 세션

 

 

세션에 대한 포스팅이 아니기 때문에 간략하게 정리를 하자면,

"Spring Boot에서는 Tomcat이 세션 관리를 담당하고, 이때 세션은 Tomcat 프로세스의 메모리에 저장된다"

 

결론적으로는, 모든 프레임워크마다 세션을 다루는 방식은 다르지만, 하나의 공통점은 서버가 2대 이상으로 늘어나면, 각 서버의 세션이 서로 공유되지 않는 문제점이 발생한다.

 

출처: https://hstory0208.tistory.com/

 

위 그림과 같은 상황을 살펴봤을 때, 서버가 2대 이상이기 때문에 로드밸런서에 의해 여러 서버에 요청을 골고루 보내게 된다.

하지만 각 서버마다의 세션 정보가 다르기 때문에 어떤 요청에서는 인증이 성공하지만 어떤 요청에서는 인증이 실패하는 상황이 발생한다.

 

출처: https://hstory0208.tistory.com/

따라서 위 그림과 같이 외부에 별도로 세션 스토리지를 두어서 2개 이상의 서버가 존재할지라도 동일한 세션 정보로 처리가 가능하도록 하는 것이 대부분이라고 한다.

이때 외부 세션 스토리지로 많이 사용하는 것이 바로 Redis이다.

 

Redis Hash로 세션 스토리지 구축하기

Spring Boot에서는 spring-session-data-redis 라이브러리를 제공하기 때문에 쉽게 Redis로 세션 스토리지를 구축할 수 있다.

해당 라이브러리에 대한 의존성 추가를 한 뒤, 다음과 같이 RedisSessionConfig를 작성해준다.

@Configuration
@EnableRedisHttpSession
public class RedisSessionConfig {

}

 

@RedisSessionConfing 어노테이션을 추가해서 Redis기반 세션관리를 활성화해준다.

 

이후 appliacation.yml에 session: store-type: redis를 추가해준다.

spring:
  datasource:
    url: 
    username: root
    password: password
    driver-class-name: com.mysql.cj.jdbc.Driver
  data:
    redis:
      host: localhost
      port: 6379
  jpa:
    hibernate:
      ddl-auto: create
    show-sql: true
  // 해당 내용 추가
  session:
    store-type: redis

 

놀랍게도 이렇게만 작성해주면 모든 세팅이 완료된다.

 

이후 세션 정보는 로컬 스토리지에 저장되는 것이 아닌 Redis에 저장되기 때문에, 서버가 2대 이상이어도 Redis에 저장된 세션 정보로 동작한다.

 

이때 세션 정보가 바로 Hash 형태로 Redis에 저장되게 된다.

 

그래서 실제로 redis-cli에 접속해서 Key 값을 조회하면

spring:session:sessions:[세션 식별 값]

 

와 같은 형태로 Key값이 조회됨을 확인할 수 있다

 

또한 위 Key값으로 세션에 저장된 값 또한 조회가 가능하다.

HGETALL [세션이 저장된 key]

 

위와 같이 명령어를 쳤을 때, sessionAttr:userId, sessionAttr:name와 같이 userId와 name의 field가 value와 함께 조회됨을 확인할 수 있다.

 

이때 조회되는 value의 텍스트가 깨져서 보일 수 있는데, 그 이유는 Spring Session이 세션 값을 RedisSerializer로 직렬화하여, 직렬화된 바이트로 Redis에 저장하기 때문이라고 한다.

 

이때 텍스트가 깨지지 않도록 하고 싶다면, JSON 직렬화로 저장하면 된다고 한다.