Ray`s Tech Lab

레디스(Redis)의 개념

Remote Dictionary Server의 줄임말로, key-value 구조의 비정형 데이터를 저장하고 관리하기 위한 오픈 소스 기반의 NoSQL DB다. 타 DB처럼 디스크에 데이터를 저장하는게 아닌 메모리에 데이터를 저장하는 인-메모리 DB이며, 메모리를 통한 빠른 속도 때문에 Cache 용도로 많이 활용되지만 그 외에도 Message Broker나 Streaming engine으로서의 역할도 맡을 수 있다.

Message broker로 쓰인다는 것의 의미 : 분산 시스템에서 메시지 전달 및 이벤트 처리를 관리하기 위한 중요한 역할을 하는 소프트웨어 컴포넌트로 활용된다는 것

Streaming engine로 쓰인다는 것의 의미 : 스트림(Streams)라고 불리는 자료 구조를 활용해 실시간 데이터 처리를 위한 목적으로 활용된다는 것

레디스에서 고가용성을 확보하는 방법

1. Stand alone (No HA)

Redis 서버 1대로 아키텍처를 구성하는 방법을 말하며, 해당 서버가 다운되면 인생 끝나는 것이므로 고가용성이 보장되지 않는다. 서버가 다운될 시 AOF 또는 snapshot을 사용해 재시작한다.

AOF : Append Only File의 줄임말로, Redis의 변경 사항을 기록하는 파일을 말한다. Redis 서버에 새로운 명령(조회는 제외)이나 데이터 변경이 발생하면, 해당 명령 또는 변경 내용을 AOF 파일에 연속적으로 추가한다. 이는 변경 사항을 로그로 남기는 방식이다.

snapshot : 특정 시점에 메인 메모리에 있는 모든 레디스 데이터를 디스크에 쓴 것, 즉 일종의 백업을 말한다.

2. 이중화 (a.k.a Master & Slave, Half HA)

Redis 서버 2대로 아키텍처를 구성하는 것을 말하며, Slave는 Master의 데이터를 실시간으로 전달받아 보관한다. Master가 다운될 시 Slave를 FailOver시킬 수 있으나 수동으로 직접 해줘야 한다. Slave를 하나가 아닌 여러 개를 둘 수도 있다.

3. 이중화 + 센티널 (HA, 무중단 서비스 가능)

Master & Slave 구성에 센티널(Sentinal)을 추가해서 각 서버를 감시하도록 하도록 하는 아키텍처를 구성하는 것을 말한다. 센티널은 Master를 감시하고 있다가 Master가 다운되면 Slave를 Master로 승격시킨다. Redis Client(즉 Application)은 새로운 Master로 접속해서 서비스를 계속한다. 센티널은 데이터 처리는 담당하지 않으며, 센티널 자체가 다운되는 상황을 고려해 일반적으로 3대의 센티널을 운용한다.

센티널이란 : Master와 Slave들을 감시하고 있다가 Master가 다운되면 이를 감지해서 관리자의 개입없이 자동으로 Slave를 Master로 올려주는 감시자(보초)를 말한다. 즉 센티널은 감시, 자동 장애조치(Automatic FailOver)의 역할을 하며 알림(FailOver될 때 관리자한테 메일 보내던가 하는..)의 역할도 맡을 수 있다.

4. 레디스 클러스터 (HA)

샤딩(sharding)을 사용하여 복수의 Redis노드에 데이터를 분할하는 방식으로 아키텍처를 구성하는 것을 말한다. Master가 3대라면, 전체 데이터를 3대에 나누어 저장하는 것이다. (100개가 있다면 1번에 33, 2번에 33, 3번에 34개 이런 식으로). 데이터들의 key에 hash함수를 멕인 값에 따라 어느 Master 서버로 데이터를 둘지 결정하게 된다. 각 Master 서버가 데이터 처리 뿐만 아니라 센티널 역할도 같이 수행하며, 최소 3대의 Master 서버가 필요하다.

샤딩을 통해 데이터들을 분할해서 각 Master 서버에 저장하기 때문에 하나의 서버라도 다운되면 데이터 유실이 생기지 않을까라는 생각을 할 수 있으나, 위 그럼처럼 클러스터를 구성하면 아무리 Master들이 다운되도 하나의 서버만 살아있다면 정상적인 운용이 가능하다.

클러스터 방식을 통해 여러 대의 서버가 하나로 묶여 마치 1개의 시스템처럼 동작하게 되며, 여러 서버에 데이터를 분산하여 저장하기 때문에 부하를 여러 대의 서버로 분산시키므로 더 빠른 속도로 사용자에게 서비스를 제공할 수 있게 된다. 

샤딩(Sharding)이란 : 대량의 데이터를 처리하기 위해 여러 개의 데이터베이스에 분할하는 기술 즉 DBMS안에서 데이터를 나누는 것이 아니라 DBMS 밖에서 데이터를 나누는 방식임에 유의하자.

클러스터 vs 센티널

우선 둘 다 고가용성을 챙길 수 있다. 그러나 클러스터는 확장성이 있는 반면, 센티널은 확장성이 없는 아키텍처다. 또한 클러스터는 센티널에 비해 빠른 액세스 속도를 보일 수 있다. 반면 센티널은 클러스터에 비해 배포 및 관리가 용이하다. 따라서, 일반적으로 중소 정도의 규모라면 센티널을, 수평적 확장이 필요한 대규모의 경우는 클러스터를 추천한다고 한다.

참고한 자료

http://redisgate.kr/redis/configuration/redis_overview.php

현재 내가 소마에서 진행 중인 프로젝트는 jwt를 활용중이며, rdb에 refresh token을 저장하고 재발급에 활용하고 있다. 시퀀스 다이어그램으로 보면 다음과 같은 구조다.

(참고 : refresh token을 db에 저장한 뒤 클라이언트가 재발급 요청 시 보내진 refresh token과 대조하는 이유 = 악의적 사용자가 지 맘대로 만든 refresh token으로 재발급 요청해서 access token을 받으려 하는걸 막을 수 있고, 악의적 사용자가 refresh token을 탈취했다고 해도 우리 쪽에서 db에 있는 refresh token을 없애준다든가 하는 식으로 조치를 취해줄 수도 있고,, 로그아웃 구현 시에도 편리하고.. 등등)

그러나 이 방법의 단점을 꼽자면 다음과 같은 부분들이 있다

1. rdb에서 refresh token을 가져오는데 시간이 좀 걸린다
2. rdb에 저장된 토큰데이터들 중 만료기간이 지난 토큰들을 개발자가 코드를 작성하든 뭐 하든 해서 직접 삭제시켜줘야한다

이를 인메모리 데이터베이스인 redis를 사용하면, 해당 단점들을 개선할 수 있다

1. 우선 메모리에 저장하기 때문에 rdb대비 토큰을 가져오는 속도가 빠를 것이고
2. ttl을 설정해주면 만료기간 지난 토큰들은 알아서 없어진다

따라서 refresh token을 관리하던 방법을 rdb에서 redis로 바꾸기로 했다. 물론 인메모리 데이터베이스인 만큼 꺼지면 다 날라가긴 하지만, refresh token은 날라가도 크리티컬한 피해는 없다. 번거로울 수 있지만 다시 로그인하면 되는 거니까.

우선 AWS에서 ElastiCache로 Redis를 쓸 거다. 문제는 ElastiCache는 같은 VPC에서만 접속하는걸 허용해서 로컬에서 접근할 수 없다는 것. 그러나 ssh 터널링 등을 통한 방법으로 로컬에서도 ElastiCache에 접근이 가능하다. 이건 내가 쓴 글이 있으니 링크를 달겠다.

https://jofestudio.tistory.com/110

Bastion Host를 통해 접근하는 방식이므로 ElastiCache에 달아주는 보안그룹에는 Bastion Host 쪽에서 오는 6379포트에 대한 인바운드를 열어줘야 한다.

스프링부트에선 다음과 같은 의존성을 추가한다.

implementation 'org.springframework.boot:spring-boot-starter-data-redis'

그 다음 application.properties에 다음과 같이 작성해준다(application.yml을 사용한다면 그에 맞춰 수정하면 됨)

spring.data.redis.host=localhost
spring.data.redis.port=6379

참고로 로컬에서 ssh 포트포워딩을 통해 elastiCache에 접속하는 중이므로 host는 localhost로 한 것이다.

그리고 다음과 같은 Configuration Class를 만들어준다.

@Configuration
public class RedisConfig {
    @Value("${spring.data.redis.host}")
    private String host;

    @Value("${spring.data.redis.port}")
    private int port;

    @Bean
    public RedisConnectionFactory redisConnectionFactory() {
        return new LettuceConnectionFactory(host, port);
    }

    @Bean
    public RedisTemplate<String, Object> redisTemplate() {
        RedisTemplate<String, Object> redisTemplate =  new RedisTemplate<>();
        redisTemplate.setConnectionFactory(redisConnectionFactory());

        // 일반적인 key:value의 경우 시리얼라이저
        redisTemplate.setKeySerializer(new StringRedisSerializer());
        redisTemplate.setValueSerializer(new StringRedisSerializer());

        return redisTemplate;
    }
}

• RedisConnectionFactory : Redis 서버와의 연결을 만들고 관리하는 빈
• RedisTemplate : Redis와의 상호작용을 돕는 빈. 즉 얘를 핸들링하여 레디스와 짝짝꿍하는 것
• Serializer설정 : RedisTemplate의 디폴트 Serializer는 JdkSerializationRedisSerializer인데, 문제는 redis-cli를 통해 개발자가 직접 redis안에 있는 애들을 볼 때 Jdk직렬화된 애들은 그 값을 도무지 알아먹을 수가 없어서, 편의를 위해 StringRedisSerializer로 설정(이렇게 하면 String값 그대로 Redis에 저장됨)

참고 : 직렬화(seriailize) = 객체 등을 바이트 스트림 형태의 연속적인 데이터로 변환하는 것. 반대는 역직렬화(deserialize)

그리고 다음과 같은 RefreshTokenService를 만들어준다.

@RequiredArgsConstructor
@Service
public class RefreshTokenService {
    private final RedisTemplate<String, Object> redisTemplate;
    private final Long REFRESH_TOKEN_EXPIRE_TIME = 60 * 60 * 24 * 30L;

    public void saveRefreshToken(String email, String refreshToken) {
    	// 이메일을 key로, 토큰값을 value로
        redisTemplate.opsForValue().set(email, refreshToken, REFRESH_TOKEN_EXPIRE_TIME, TimeUnit.SECONDS);
    }

    public String getRefreshToken(String email) {
        Object refreshToken = redisTemplate.opsForValue().get(email);
        return refreshToken == null ? null : (String) refreshToken;
    }

    public void deleteRefreshToken(String email) {
        redisTemplate.delete(email);
    }
}

나는 Refresh Token의 유효기간을 1달로 잡았기 때문에, 60 * 60 * 24 * 30 = 30일을 유효기간으로 설정해 저장하도록 구현했다. 분이 아니라 다른 시간 단위로도 저장 가능하니, 본인 취향따라 하면 된다.(TimeUnit.SECONDS 이쪽)

이제 이를 활용해 원래 rdb를 사용하던 로직을 바꿔줬다.

• 로그인 후 jwt(access token, refresh token)을 생성하고 refresh token을 rdb에 저장하던 것 => refresh token을 redis로 저장. 이 때 redis에 기존에 쓰던 refresh token이 있으면 덮어씌운다
• 토큰 재발급 요청시 rdb에서 refresh token가져오던 것 => redis에서 가져온다
• 토큰 재발급 후 재발급된 refresh token을 rdb에 저장하던 것 => redis로 저장. 이 때 redis에 기존에 쓰던 refresh token이 있으면 덮어씌운다

이제 로그인 요청, 인가인증이 필요한 요청, 토큰 재발급 요청에 대한 수행과정들을 시퀀스 다이어그램으로 표현하면 다음과 같아진다.

아 그리고 이 과정에서 추가적으로 고민했던 게, 토큰재발급 요청을 인증된 유저만 받을지였다. 구글링해서 나오는 다른 예제들을 보면 재발급 요청은 인증을 안 해도 가능하게끔 하는 예제가 대부분이었는데, 나는 고민 끝에 재발급 요청도 인증을 한 유저만 할 수 있게끔 했다. 왜냐하면, 당연히 보안을 위해서. 인증할 필요없이 refresh token만 덜렁 보내서 재발급받을 수 있다면, refresh token이 탈취당하면 너도나도 내 refresh token으로 재발급을 무료로 시도할 수 있기 때문이다. 

인증은 access token을 통해 이뤄지며, 재발급 요청은 우리 플젝에선 앱 접속시 자동로그인을 위한 재발급을 위할 때가 아니라면 access token이 만료됐을 때 이뤄질 거다. 만료된 토큰은 검증과정에서 ExpiredJwtException을 뱉을 텐데, 그러면 만료된 토큰에 대한 인증을 어떻게 할 수 있는가?

처음에 생각한 것은 임시 통행증(Authentication)을 끊어주는 거였다. 스프링 시큐리티는 ContextHolder에 Authentication이 들어있다면 인증됐다고 판단하므로, ExpiredJwtException이 터졌을 때 재발급경로로 요청이 온 것이라면(이는 request객체를 까서 판단 가능) 임시로 Authentication을 만들어 ContextHolder에 넣어주면 되는거다. 

try {
	jwtProvider.validateAccessToken(accessToken);
} catch (ValidTimeExpiredJwtException ex) {
	// access token이 만료됐지만 재발급하는 요청에 대한 처리 - 임시로 인증됐다고 처리한다
	if (request.getRequestURI().equals(REISSUE_PATH)) {
		setTemporaryAuthenticationToContextHolder();
		return;
	}
	request.setAttribute("exception", ex.getMessage());
	return;
} catch (CustomJwtException ex) {
	request.setAttribute("exception", ex.getMessage());
	return;
}

    private void setTemporaryAuthenticationToContextHolder() {
        // 임시 권한 생성
        List<GrantedAuthority> temporaryAuthorities = new ArrayList<>();
        temporaryAuthorities.add(new SimpleGrantedAuthority(ROLE_USER.name()));
        // 임시 통행증 발급
        Authentication authentication = new UsernamePasswordAuthenticationToken(
                "temporaryAuthentication", "", temporaryAuthorities
        );
        SecurityContextHolder.getContext().setAuthentication(authentication);
    }

이렇게 해도 잘 동작한다. 하지만! 나중에 소마 내 다른 연수생이 작성한 코드들을 몰래보다가, ExpiredJwtException의 인스턴스로부터 jwt클레임을 추출 가능하다는 놀라운 사실(!)을 깨달았다. 따라서 단순히 유효기간이 만료된 토큰이라면 정상적인 토큰에서 claim을 빼내는 것처럼 claim을 빼낼 수 있다.

    private String extractEmailFromToken(String accessToken) {
        try {
            return Jwts.parserBuilder()
                    .setSigningKey(accessKey)
                    .build()
                    .parseClaimsJws(accessToken)
                    .getBody()
                    .getSubject();
        } catch (ExpiredJwtException ex) {
            return ex.getClaims().getSubject();
        }
    }

역시 남의 코드 보면서 배우는게 참 많아.. 암튼, 이를 통해 ExpiredJwtException이 터지면 재발급 요청인지를 판단하고, 재발급 요청이라면 기존 인증 절차와 마찬가지로 동작시킬 수 있다.

이런 과정들을 거쳐 redis를 도입했다. 그러면 속도는 얼마나 개선됐을까?

RDB(AWS RDS)만 사용했을 땐 평균 180ms정도가 걸렸으나,

Redis(AWS ElastiCache)를 사용하고나선 평균 100ms정도가 걸리게 됐다. 약 80ms정도 속도가 빨라진 것이다.

아직 학생 수준인 내게 80ms 정도라는 숫자가 의미가 있는지는 모르겠다. 그러나 트래픽이 많아질수록, 단축된 시간 X 요청횟수가 실제적인 성능 개선이라고 생각한다면 의미있는 개선을 이뤄낸게 아닐까싶다. okky에 문의한(?) 결과 운영자분께서 elastiCache를 통해 80ms 정도 개선한 것이면 잘 한 것이라고 해서 나름 뿌듯함.

굳이 레디스를 도입했어야 하는가? 라는 질문도 받을 수 있다. 맞는 말이다. 일단 배포를 안 한 만큼 재발급 요청에 대한 트래픽이 현재 없는 상태인데 굳이 80ms 높이겠다고 레디스? + 사용자 입장에서도 체감되는 개선인가? 라는 질문도 추가적으로 받을 수 있겠다. 한마디로, 지금 레디스를 도입하는 건 오버 엔지니어링이 아니겠냐는 말로 정리할 수 있겠다

그러나 속도 측면 말고도 유효기간이 만료된 토큰이 개발자가 뭘 하지 않아도 레디스에서 날라간다는 점에서 개인적으로 나름의 의미는 있다고 생각한다. 또한 학생 신분인 내가 레디스를 이렇게 처음 접하게 된 것도 의미가 충분한다. 마지막으로 돈 문제. ElastiCache 그거 돈 들지 않느냐! 굳이 레디스 필요없는데 왜 레디스 달아서 돈 나가게 하냐! 

당연히 실무라면, 혹은 내가 실제로 이 서비스를 운영하고 있는 단계면 어떻게든 돈 적게 쓸라고 쥐어짰겠지만, 난 지금 소마에서 지원금을 받으면서 플젝을 하고 있는 상태. 돈이 좀 드는 AWS 서비스들을 이것저것 써보면서 학습하는게 스스로한테 좋을 터. 그렇기 때문에 Redis를 이렇게 써보는게 의미가 있다고 생각한다. 허허헣