우리 서비스의 Redis는 왜 매일 장애가 날까?

Track 1_1700_Lablup Conf 2025_강대명

Transcript

2. 우리 서비스의 Redis는 왜 매일 장애가 날까? 강대명(래블업)
3. 주제 • Redis 장애 패턴 소개
4. Redis 소개 • In memory Key-Value NoSQL 로, 다양한 자료구조를 제공 • 2009년에 최초로 공개 o Salvatore Sanfilippo(antirez) 가 개발 • Get/Set 같은 단순한 명령은 초당 10만 RPS 정도의 성능이 나옴. • 지금은 소유권이 Redis 라는 회사로 넘어감.
5. Redis 와 Valkey •2024년 3월 Redis 7.2.4부터 Valkey 로 Fork 됨. oRedis에서 Redis 에 RSAL + SSPL 라이센스를 적용함 o두 개가 서로 다른 방향성으로 파편화 되기 시작함. •2025년 4월 말에 다시 Redis에 AGPLv3를 적용 •Redis ohttps://github.com/redis/redis •Valkey ohttps://github.com/valkey-io/valkey
6. 우리 서비스의 Redis는 왜 매일 장애가 날까?
7. 현재 많은 곳에서 Redis를 사용 중이다. • 그 만큼 많은 Redis 관련 지식을 알고 있는 중. • 그러나 여전히 잘못 알고 있거나 모르는 곳도 많음. • 많은 곳에서 쓰니 알아서 좋을 것이라고 생각하는 경향
8. Redis는 Single Threaded. - 문제의 근원
9. 먼저 가장 많은 이슈 - KEYS 커맨드
10. KEYS 의 사용법 • KEYS {Pattern} o Pattern에 일치하는 키를 돌려준다. • "lablup:manager:*"
11. "lablup:manager:*" 는 어떻게 동작할까? • 흔한 오해 o Redis는 잘 만들어진 툴이다. o 그러니, 전체 KEY 중에서 lablup:manager: 로 시작하는 것만 효율적으 로 찾아줄 것이다.
12. Redis 메모리 구조 - 거대한 HashTable
13. Hash Table 에서 Like Search가 쉬울까? • Hash Table은 해당 key를 빠르게 찾는 용도의 자료구조. • Like Search는 유용하지 않다. o Prefix Search 라면 B+ Tree 나 Patricia Tree 등으로 가능. ▪ "redis*" o Postfix Search 라면 Reverse형태로 Prefix Search를 응용하므로써 가능. ▪ "*redis" o 그러나 "*redis*"는? -> ngram
14. KEYS의 문제점 • 전체 데이터를 스캔해야 한다. o 어떤 Pattern을 주든지 모든 키를 순회해야 함. o O(N) -> 데이터 량이 많아질 수록 느려진다. • O(N)으로 Redis에 저장하는 key가 늘어날 수록 느려진다. • KEYS가 수행되는 동안에 Redis는 다른 작업을 처리하지 못한다.
15. KEYS와 SCAN 비교 - 전체 KEY 순회 기준 KEYS SCAN Cursor
16. KEYS를 SCAN 으로만 변경하면 문제가 사라질까? • SCAN을 이용하더라도, 전체 스캔 시간이 줄어들지는 않는다. o도리어 끊어서 하므로, 전체 스캔 시간 자체는 늘어난다. • 전체 데이터가 필요한게 아니라, 빨리 찾아야 하는 데이터라면 저장 방식에 대해서 더 고민을 해야 한다.
17. 잘못된 자료구조의 선택
18. 왜 Redis로 대기열을 구현할까? • 대기열 정보는 휘발성, 특정 시점에 몰리는 데이터, 순서 보장이 중요. • DB 기반 대기열의 경우 사용자 폭주에 취약하다. 사용자 폭주 API DB 인덱스 경합(hot index) 트랜잭션 락 Disk I/O 지연증가 타임아웃 서버 과부하
19. 어떤 자료구조를 선택할까요?
20. Redis로 대기열 구현 예 사용자 폭주 API Redis RPUSH 로 저장 LPOP 로 처리
21. 어떤 문제가 발생할 수 있을까? • 대기열에 있는 자기의 순서를 보여주는 기능이 들어가면 어떻게 될까? 대기열 : 1000번
22. 실제 장애 사례 • 모 서비스에서 대기열에 순서를 보여주는 기능을 넣고 장애발생 • List 에서 특정 key 의 순서는 lpos 명령을 사용. • lpos는 특정 값의 list내의 위치를 알려주는 함수
23. lpos – Linear Search 1 != 16 1 2 4 8 16 32 64 2 != 16 1 2 4 8 16 32 64 4 != 16 1 2 4 8 16 32 64 8 != 16 1 2 4 8 16 32 64 16 == 16 1 2 4 8 16 32 64 Lpos of 16 idx = 0 idx = 1 idx = 2 idx = 3 idx = 4
24. 너무 큰 데이터
25. 너무 큰 데이터 • Collection 에 많은 데이터가 들어가는 것도 문제. • 하나의 Key – Value에 엄청 큰 데이터가 들어가면 어떻게 될까? oRedis는 하나의 Key에 512 MB까지 들어갈 수 있다. • 그런데 누가 그런 사이즈를 Redis에 넣을까?
26. 너무 큰 데이터 • 공지 사항을 캐싱한다면 어떤 정보들이 들어갈 수 있을까? • 아래와 같은 이미지는 어떻게 저장될까?
27. 너무 큰 데이터 • <img id="logo" src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAA 1IAAAEsCAYAAADJkYKfAAAgAElEQVR4Xuy9e5gc1XUvulb1jIST3 HjakkCAbXqwAQswzBi/4hMOPTyFbGCUODc+ o이와 같은 형태로 이미지가 텍스트로 들어가 있을 수 있다. o현재 폰 사진 이미지 한장에 기본적으로 4~8MB 정도 base64 가 되면 33% 정도 늘어난다. ▪ Base64 변환 사이즈 = 기본 사이즈 / 3 * 4 • 캐싱할때 기본적인 사이즈를 꼭 체크해야 한다. oDB에도 이런 사이즈가 들어가면 안됨.
28. 정리 - O(N) 명령의 위험성 • Redis 는 기본적으로 Single Threaded • O(N) 명령을 수행하면 데이터 량이 많을 수록 느려진다. o해당 시간동안 다른 처리를 할 수 없다. • O(N) 명령을 써야 하는데 데이터가 많아지면? oKEY를 쪼개는 형태로 데이터의 분산이 필요함.
29. 우리의 Redis 가 매일 장애가 나는 이유! • Redis 자체는 심플한 In-Memory NoSQL Cache Store. • 하나의 명령이 길게 처리되는 경우는 무조건 피해야 한다. oO(N) 명령들 • 적합한 자료구조를 사용하지 않을 경우에 문제가 생긴다.