아, 안녕하세요. 저는 오늘 발표를 맡게 된 강대명이라고 합니다. 오늘 주제는 우리 서비스의 레디스는 왜 매일 장애가 날까라는 주제고요.

사실 제가 좀 발표를 하게 되면서 어떤 고민을 했냐면 모든 세션이 AI 관련 세션인데 이 세션만 전혀 AI 관련 내용이 없어요.

그 서비스에 관한 내용들이고요.

그리고 이제 레디스에 대해서 장애가 나는 케이스가 어떤 것들이 있느냐 요런 것들에 대해서 좀 얘기를 드리려고 하는 세션입니다.

네. 그래서 혹시 AI와 레디스를 어떻게 접목하느냐 이렇게 생각하시고 들어오셨으면 좀 실망을 하실 것 같고요.

그런데 그냥 레디스를 많이 쓰시는 분들은 어 이런 식으로 장애가 났었지 아니면 이런 식으로 날 수 있구나에 대해서 생각을 하시는 세션이 될 거 같습니다.

네 오늘 주제 다시 한번 말씀드리지만 레디스 장애의 패턴에 대한 소개를 할 거고요.

그 간단하게 레디스를 먼저 소개를 드리면 우리가 Redis는 아마 대부분 Redis 내용을 들어보셨을 거예요.

혹시 Redis가 전혀 뭔지 모르시는 분 혹시 계신가요? 네. 손을 드시는 분들 있지만 네.

페이크라고 생각하고 네. 그네 다들 이 포인트에서 웃기려고 한 건 아니지만 예 저는 발표를 내용 전달보다 웃기는 데 사실은 좀 신경을 쓰는 사람이긴 한데요.

네. 인메모리 키밸류 노 SQL이라고 좋은 얘기는 다 들어가 있거든요.

그 그리고 다양한 자료 구조를 제공하고 있어요.

Redis가 뭐 키밸류 스토리지, 리스트, 맵, 해시 뭐 그다음에 셋 집합이라는 거 그다음에 소티드 셋 정렬된 집합 그다음에 뭐 스트림 이렇게 다양한 것들을 제공하고 있는데요.

그래서 굉장히 지금 많은 서비스 업체들이 쓰고 있고요.

거의 여러분들이 이름을 들으면 알 수 있는 대부분의 업체들이 굉장히 많은 양의 서버를 쓰고 있고 제가 그 예전에 카카오했을 때 뭐 몇백 대 규모로 Redis 서버들을 운영을 했었거든요.

그게 2016년, 15년 이럴 때예요. 사실 그러니까 지금은 더 많이 쓰겠죠.

그리고 2009년에 최초로 공개됐고 그 살바토레 살피르라고 해 가지고 그 트위터명 아니면 깃허브명은 안티레즈인데 이분이 개발을 했고 장점이 뭐냐면 겟셋 그러니까 키를 키-밸류 구조에서 키를 주고 밸류를 가져오는 것과 아니면 키를 주고 그 밸류를 세팅하는 그런 단순한 명령이 초당 10만 TPS 정도가 나와요.

그래서 초당 10만 TPS라는 얘기는 1초에 10만 번 정도에 실행이 된다라는 거거든요.

그럼 굉장히 빠르죠. 그래서 그런 속도 때문에 굉장히 많이 쓰게 되고요.

여러분들이 만약에 MySQL, 포스트그레스 SQL 같은 DB를 쓰시면 보통 초당 1천에서 굉장히 비싼 거 있으면 초당 한 만 정도까지 쓸 수 있거든요.

그러면 그런 거에 비하면 굉장히 속도가 빠르다는 걸 알 수 있습니다.

근데 이제 여러 가지 좀 이슈들이 생기고 지금은 Redis라는 회사가 소유권을 가져가 있는 상태예요.

네. 그래서 이제 Redis에서 '바이키'라는 오픈 소스가 다시 한번 더 포크가 나왔거든요.

Redis도 오픈 소스지만 거기서 2024년 3월에 정확하게 Redis 7.2.

그러면서 Redis의 RSAL, SSPL이란 라이선스가 적용이 되면서 클라우드 서비스를 하는 업체들은 Redis를 7.2.

그래서 거기에 반대하는 사람들이 포크를 하게 됐는데 이게 재밌는 게 다시 2025년 4월 말에 다시 Redis가 저 RSAL, SSPL이라는 라이선스를 버리고 그 AGPL 버전 3를 적용하면서 다시 오픈 소스로 돌아오긴 했어요.

그런데 Redis의 이 AGPL은 어떤 거냐면 서버로서 여러분들이 쓰면 소스 코드를 안 바꾸더라도 그 만약에 서버로 여러분들이 쓰는데 소스 코드를 바꾸게 되면 실제로 배포가 아니더라도 배포라고 보고 소스 전체 서비스의 소스 코드를 다 공개해야 돼요.

굉장히 강력한 GPL 라이선스거든요.

그래서 함부로 여러분들이 레디스 버전을 쓰게 되면 문제가 생길 수 있어요, 회사에서.

그래서 발키를 쓰는 게 사실은 좀 더 좋고요. 그런데 지금 레디스 파일, 발키 파일부터 조금씩 세분화가 좀 가지가 쳐지고 있거든요.

그런데 아직까지 큰 차이는 없지만 여러분들이 그런 거에 대한 고민을 선택하시면서 좀 고민을 하셔야 된다.

나중에 레디스를 쓸지 발키를 쓸지를 고민을 하셔야 됩니다.

네. 그럼 이제 우리 서비스의 주제로 돌아서 우리 서비스의 레디스는 왜 매일 장애가 날까?

이런 거죠. 왜 매일 장애가 날까요?

뭐 예전에는 하드웨어 장애가 굉장히 많았거든요. 제가 그 M모사 메일 서비스를 개발할 때는 서버가 한 1,000대쯤 되는데 그럼 하루에 무조건 다섯 대 정도가 죽어요.

그런데 이게 왜 죽냐면 하드웨어 장애가 많았거든요.

파워가 나가는 거, 하드 디스크가 나가는 거. 심지어 메모리가 나갈 때도 있고 CPU가 나갈 때도 있어요.

굉장히 여러 가지가 발생을 하는데 이제 Redis의 장애는 대부분 사람의 실수가 많아요.

근데 아까 전에 말했지만 아까 Redis 잘 모르시는 분 했을 때 손 드시는 분이 몇 분 안 계셨거든요.

그런데 그만큼 Redis를 이미 많이 쓰고 있어요.

사람이 굉장히. 그런데도 여전히 좀 잘못 알고 있는 게 많은 거예요.

많이 알고 계신데 여전히 잘못 알고 있는 부분들이 많은 거거든요.

그래서 많은 대부분을 좀 얘기를 해 보면 많은 곳에서 쓰니까 Redis가 대부분 잘 해 줄 거야라는 생각을 많이 가지고 계세요.

성능도 좋고 어 여러분들 페이스북에서도 쓰고 뭐 구글에서도 쓰고 네이버도 쓰고 카카오도 쓰는데 그러면 다들 좋은 거니까 쓰지 않을까라고 생각을 하시는데 기능 자체가 어떻게 보면 굉장히 단순하거든요.

레디스나 바키 같은 경우에 그렇기 때문에 조심해서 쓰지 않으면 반대로 더 장애가 자주 일어나는 게 레디스나 바키라고 보시면 될 거 같습니다.

일단 문제의 근원, 그 레디스는 싱글 스레디드예요. 지금 이제 8 버전부터 약간 기능이 추가됐지만 레디스는 본질적으로 싱글 스레디드고요.

싱글 스레디드라는 거는 한 번에 처리할 수 있는 게 딱 한 개라는 얘기예요.

CPU에서 한 번에 하나만 처리할 수 있는데 이렇게 패킷이 막 들어가면 뭐 프로세스 인풋 버퍼, 버퍼, 버퍼, 프로세스 커맨더 이런 함수를 통해서 패킷이 완성이 되면 파싱을 하고 됐을 때 바로 실행을 시키는 구조거든요.

기본적인 베이스로 봤을 때는. 그러면 이거를 처리하는 동안에는 다른 명령이 전혀 처리를 할 수가 없어요.

이게 문제의 핵심이에요. 그러니까 레디스는 싱글 스레드인데 동시에 여러 명령을 처리.

아까 제가 초당 10만 TPS 정도가 나온다고 했잖아요.

그러면 굉장히 짧은 명령들을 빨리빨리 처리하는 거예요.

그게 긴 명령이 오면 안 된다라는 거거든요.

그럼 첫 번째로 이제 어떤 문제가 있냐? 제가 항상 이 이슈를 들거든요.

`KEYS` 커맨드라는 게 있어요. 이 `KEYS` 커맨드는 레디스에 존재하는 모든 키를 찾아 가지고 주는 명령이에요.

예. 이런 얘기를 가끔씩 하면 어 그건 너무 많이 알고 있다라는 얘기도 많이 하시거든요.

그런데 여전히 굉장히 큰 회사들, 뭐 아까 전에 말한 노란 회사, 녹색 회사 뭐 이런 회사들에서도 여전히 같은 이슈가 발생하고 있어요.

뭐 교육이 안 됐을 수도 있고 사용법에 대한 실수도 있는데 일단 `KEYS`가 어떤 명령인지 먼저 설명을 드릴게요.

`KEYS`는 `KEYS` 다음에 패턴을 주면 이런 정규 표현식 같은 비슷한 패턴을 주면 그 패턴에 일치하는 키를 돌려 주는 명령이에요.

그러니까 레블업 매니저 이렇게 프리픽스 주고 별표를 주면 쟤들을 찾아 가지고 이제 유저한테 키를 돌려주는 거죠.

그래서 이제 흔하게 생각하는 게 어떤 거냐면 레디스는 잘 만든 툴이고 굉장히 속도가 빠른 툴이니까 방금 제가 말한 레블업 매니저 애스터리스크(asterisk) 별표 같은 걸 주면 쟤들만 찾아서 시작하는 것들을 굉장히 효율적으로 찾아서 전달해 줄 거라고 생각하는 게 일반적인 생각이거든요.

레디스는 빠르고 그러니까 이런 명령도 다 빠를 거야라고 생각을 하는데 실제로 레디스의 메모리 구조를 보면 방금 키를 찾는 거는 거대한 해시 테이블이에요.

그 해시 테이블이라는 거는 이렇게 뭐 구현하는 방법이 여러 가지가 있거든요.

그런데 레디스는 버킷 구조를 쓰고 뭐 001 해서 끝자리가 같은 비트로 떨어지는 해시값으로 떨어진 애들을 요렇게 링크드 리스트로 연결해서 충돌을 방지하는 충돌이라는 거는 같은 버킷에 같은 키가 여러 개, 여기 발키 컴프 이렇게 두 개가 있잖아요.

그러면 충돌이 일어난 거거든요.

충돌이 일어났을 때 다 한 번 더 해싱을 해서 이중 해싱을 해서 하는 그 해 충돌을 피하는 방법이 있고 이렇게 선형 링크드 리스트 구조로 만들어서 체인 형태로 집어넣는 구조가 있는데 레디스는 체이닝 구조로 사용하고 있고요.

요렇게 충돌이 일어나면 링크드 리스트 형태로 집어넣고 있어요.

그러면 이렇게 되면 키를 해싱하기 때문에 키를 해싱하고 내가 원하는 키를 찾아내는 건 굉장히 빨라요.

선형 링크드 리스트지만 요게 많아지면 링크드 리스트에 많아지면 사실은 전체가 찾는데 오래 걸리겠죠.

그 개수가 조금만 늘어나도 버킷을 늘리면서 그걸 해소를 해 주거든요.

그래서 특정 키를 찾는데는 레디스는 굉장히 빠르게 설계가 돼 있는 거예요.

해시는 O(1) 비고로 표현을 하면 O(1)로 표현이 돼 있거든요.

그러니까 굉장히 빠른 거죠. 그런데 우리가 이렇게 생각해 보는 거예요.

이게 CS적인 지식인데 해시 테이블에서 라이크 서치.

여러분들 DB에 쓰시면 어떤 키워드를 포함했는가 해서 퍼센트를 쓰면서 DB에서 쿼리를 주면 라이크 서치라고 해 가지고 그 키워드가 있는 걸 전부 다 가져오거든요.

그런데 해시 테이블에서 과연 우리가 생각해 보면 라이크 서치가 가능할까 생각하는 거죠.

해시는 원래 키 전부가 있을 때 그걸 해싱해서 값을 가져오는 건데 라이크는 어떤 값이 들어갈지 모르는 거잖아요.

그다음 해시의 특징은 문자가 틀려지면 전체 해시값이 틀려져야 되는 구조거든요.

그런데 이제 재밌는 거는 프리픽스 서치 아까 제가 말씀드렸듯이 레블업 매니저 별표 요런 것들은 빅블트리 구조라면 좀 빨리 찾을 수 있어요.

그런데 반대로 포스트픽스 뭐로 별표 애스터리스크 레디스라는 걸 줬을 때 쟤를 찾는 거는 B-플러스 트리 구조를 거꾸로 하면 사실은 거꾸로, 그러니까 문자를 저장할 때 거꾸로 한 번 더 저장해 주면 쉽게 찾을 수 있거든요.

그래서 쉬운데, 아스터링크 레디스 아스터링크는 어떻게 찾아야 될까요?

B-플러스 트리 구조로 가더라도 프리픽스 서치가 될 수가 없거든요.

그래서 이제 보통 이런 아스터링크 구조는 앵그램 형태, 뭐 세 글자씩 자르겠다, 네 글자씩 자르겠다는 게 검색한테 많이 쓰는 기법인데 앵그램으로 잘라서 다 저장해 놔야만 찾을 수가 있거든요.

그러니까 결론적으로 말하면 해시 테이블에서 라이크 서치는 빠를까요, 느릴까요?

느릴 수밖에 없다라는 거예요. 그다음에 느린 이유는 하나를 바로 찾을 수가 있는 게 해시인데 그렇게 찾을 수가 없고 전체 데이터를 처음부터 끝까지 모든 걸 찾아야 된다는 거예요.

그래서 이렇게 프리픽스 구조든 포스트픽스 구조든 아니면 이 풀 중간에 있는 걸 찾아야 되는 건데 전부 다 모든 키를 처음부터 끝까지 가봐야 대부분 찾을 수 있어요.

리스트나 셋 같으면 프리픽스나 포스트픽스는 좀 빨리 찾을 수 있는데 왜냐면 인덱스 쪽에서 빨리 찾아가지고 넘어가서 뒷부분은 피할 수 있지만 해시에서는 해시를 다 해봐야 되기 때문에 전부 다 검색해야 되는 거예요.

그럼 결론적으로 무슨 얘기가 돼야 되냐면 어떤 패턴을 주든지간에 키즈에서는 모든 키를 검색하게 돼요.

우리가 흔히 아까 오해하던 게 뭐냐면 이 패턴의 키가 적으면 빨리 찾을 거였는데 알고 보면 이 키즈라는 커맨드는 패턴하고 상관없이 전체 키가 몇 개 있는가에 영향을 받는 거예요.

그러니까 전혀 상관없는 다른 패턴의 키가 만약에 100만 개 있다.

그러면 100만 개를 일단 다 찾아봐야만 내가 원하는 패턴을 알 수 있게 된다라는 게 KEYS 커맨드의 문제거든요.

근데 이거를 의외로 착각하시는 분이 꽤 많아요.

그러니까 KEYS는 저 패턴이 안 맞으면 빨리 찾을 거니까 다른 데이터는 많아도 KEYS 패턴만 작으면 될 거라고 생각하고 KEYS를 사용하시는 분들이 있는데 그런 거랑 상관없이 전체 데이터 개수에 영향을 받기 때문에 점점 키가 쌓이면 쌓일수록 느려지게 됩니다.

그리고 가장 큰 문제는 뭐냐면 KEYS 아까 전에 싱글 스레드라고 제가 Redis 싱글 스레드라고 말씀을 드렸잖아요.

[Lablup Conf 5th] 우리 서비스의 Redis는 왜 매일 장애가 날까? (강대명)

래블업(Lablup) : Make AI Accessible

래블업은 클라우드 컴퓨팅과 인공지능(AI) 기술을 통해 컴퓨팅 연구 및 서비스에 새로운 패러다임을 제시합니다.
Lablup is pioneering a new paradigm in computing research and services through cloud computing and artificial intelligence (AI) technologies.



Lablup Inc

Redis 장애는 대부분 사용자의 실수로 발생하며, 특히 Redis가 '잘 만들어진 빠르고 좋은 툴'이라는 오해 때문에 부적절한 사용이 문제의 원인이 됩니다.

Redis는 싱글 스레드 아키텍처로, `KEYS` 명령과 같이 O(N) 복잡도를 가지는 작업은 전체 Redis 동작을 멈추게 하여 심각한 성능 저하와 장애를 유발합니다. 이는 Redis가 짧은 명령을 빠르게 처리하는 데 최적화되어 있기 때문입니다.

대기열 구현 시 리스트 사용과 같이 데이터 특성에 맞지 않는 자료 구조를 선택하거나, Base64 이미지 인코딩처럼 예상치 못하게 큰 데이터를 Redis 키에 저장할 경우, Redis의 처리 속도 저하 및 장애가 발생할 수 있으므로 적절한 자료 구조 선택과 데이터 크기 관리가 필수적입니다.

오늘 발표는 Lablup Conf에서 '우리 서비스의 Redis는 왜 매일 장애가 날까?'라는 주제로 진행됩니다. 다른 AI 관련 세션과 달리, 이 세션은 **실제 서비스에서 발생하는 Redis 장애 케이스와 해결 방안**에 초점을 맞춥니다. Redis는 많은 기업에서 사용하지만, 잘못된 사용으로 인해 장애가 자주 발생합니다.

Redis 기본 이해 및 라이선스 이슈

Redis는 인메모리 키-밸류 NoSQL 데이터베이스로, 리스트, 맵, 해시, 셋, 소티드 셋 등 **다양한 자료 구조를 제공하며 초당 10만 TPS의 매우 빠른 처리 속도**를 자랑합니다. 2009년 살바토레 산필리포가 개발했으며, 카카오 등 대규모 서비스에서도 수백 대 규모로 운영될 만큼 널리 사용됩니다. 이러한 속도는 MySQL이나 PostgreSQL 같은 관계형 데이터베이스에 비해 압도적으로 빠르기 때문에 많은 서비스에서 활용됩니다.

최근 Redis는 라이선스 정책 변경으로 인해 이슈가 있었습니다. 2024년 3월 Redis 7.2.4 버전부터 RSAL, SSPL 라이선스가 적용되어 클라우드 서비스 업체들은 Redis를 사용할 수 없게 되었고, 이에 반대하는 사람들이 **'발키리(Valkey)'라는 오픈소스 포크를 만들었습니다.** 2025년 4월 말 Redis는 다시 AGPL 버전 3로 전환했지만, 이 라이선스는 서버로 사용할 경우 소스 코드를 변경하지 않아도 전체 서비스의 소스 코드를 공개해야 할 정도로 강력하여, 기업에서는 Redis 사용 시 라이선스 선택에 신중해야 합니다. 현재는 발키리 사용이 더 권장되는 상황입니다.

Redis 장애의 주요 원인: 사람의 실수

Redis 장애의 주된 원인은 하드웨어 장애보다는 **'사람의 실수'가 훨씬 많습니다.** 많은 사람이 Redis의 성능과 범용성을 믿고 무조건 잘 작동할 것이라고 생각하지만, Redis는 기능 자체가 단순하므로 조심해서 사용하지 않으면 오히려 장애가 자주 발생할 수 있습니다. 이미 Redis를 많이 사용하고 있음에도 불구하고, 여전히 잘못된 이해와 사용법으로 인해 문제가 생기는 경우가 빈번합니다.

Redis는 본질적으로 싱글 스레드 방식으로 동작합니다. 이는 **한 번에 하나의 명령만 처리할 수 있다는 의미**입니다. 즉, 특정 명령이 실행되는 동안에는 다른 모든 명령의 처리가 지연될 수 있습니다. Redis가 초당 10만 TPS를 처리한다는 것은 짧은 명령들을 빠르게 처리한다는 것이며, 긴 명령이 실행되면 전체 시스템에 심각한 영향을 미칠 수 있습니다.

가장 흔한 장애 유발 요인 중 하나는 **`KEYS` 커맨드 사용**입니다. `KEYS` 커맨드는 Redis에 존재하는 모든 키를 패턴에 따라 찾아 반환하는 명령인데, 많은 사람들이 패턴에 일치하는 키가 적으면 빠르게 작동할 것이라고 오해합니다. 하지만 Redis의 해시 테이블 구조는 라이크 서치(LIKE search)에 최적화되어 있지 않으며, `KEYS` 커맨드는 **패턴과 상관없이 모든 키를 처음부터 끝까지 검색**해야 합니다.

만약 Redis에 100만 개의 키가 존재하고 `KEYS` 커맨드를 실행하면, 이 명령이 모든 키를 순회하는 데 약 1초가 소요될 수 있습니다. Redis는 싱글 스레드이므로 `KEYS` 커맨드가 실행되는 동안 다른 모든 작업이 멈춥니다. 초당 10만 TPS를 처리하는 Redis가 1초 동안 멈추게 되면, **그 시간 동안 다른 99,999개의 명령은 대기하거나 타임아웃**이 발생하게 되어 서비스 장애로 이어집니다. 특히 애플리케이션 서버에서 Redis 호출 시 설정된 짧은 타임아웃(예: 300ms) 때문에 대량의 타임아웃 오류가 발생할 수 있습니다.

`KEYS` 커맨드 대신 **`SCAN` 커맨드를 사용하는 것이 권장됩니다.** `SCAN`은 `KEYS`와 동일한 데이터를 가져오지만, 한 번에 짧은 구간을 여러 번 반복하여 전체 키를 순회하는 방식입니다. 비록 전체 수행 시간은 `SCAN`이 더 길 수 있지만, 중간중간 비는 시간에 다른 명령들이 처리될 수 있어 Redis가 블로킹되는 문제를 해결할 수 있습니다. 또한, `KEYS`나 `SCAN`으로도 해결하기 어려운 빠른 검색이 필요할 경우, 특정 자료 구조에 키를 저장하거나 다른 저장소를 활용하는 등 서비스 특성에 맞는 방안을 고려해야 합니다.

잘못된 자료 구조 선택으로 인한 장애

Redis에서 대기열을 구현하는 경우가 많습니다. 대기열은 빨리 사라지고, 특정 시점에 트래픽이 몰리며, **순서 보장이 매우 중요하다는 특징**이 있습니다. 이러한 특성 때문에 DB 기반의 대기열은 사용자 폭주에 취약하여 게임 서버 등에서 장애를 유발하는 경우가 많습니다. Redis는 인메모리 구조로 DB의 인덱스 경합, 트랜잭션, 디스크 I/O 문제를 해결할 수 있어 대기열 구현에 적합한 대안으로 여겨집니다.

대기열 구현 시 순서 보장이 중요하므로, 대부분 '리스트(List)' 자료 구조를 떠올립니다. 리스트는 `RPUSH`로 맨 뒤에 추가하고 `LPOP`으로 앞에서부터 뽑아오는 방식으로 대기열에 적합해 보입니다. 하지만 **사용자에게 자신의 대기 순서를 보여주는 기능이 추가될 때 문제가 발생**합니다. 리스트에서 특정 값의 순서를 찾는 `LPOS` 명령은 리니어 서치(Linear Search) 방식으로 동작하여, 리스트의 데이터가 많아질수록 느려지는 O(N)의 시간 복잡도를 가집니다.

예를 들어, 대기열의 뒷 순번에 있는 사용자가 자신의 순서를 조회할 경우, `LPOS`는 리스트의 모든 요소를 순차적으로 탐색해야 하므로 Redis를 멈추게 만들고 결국 장애로 이어질 수 있습니다. 이러한 문제를 해결하기 위해서는 **'Sorted Set' 자료 구조를 활용**해야 합니다. Sorted Set은 정렬된 집합으로, 정렬 기준(예: 삽입 시간)을 주면 자동으로 정렬되며, 순서를 찾는 명령이 O(log N)의 시간 복잡도를 가져 매우 빠르게 동작합니다. 실제 사례에서도 리스트를 Sorted Set으로 변경하여 문제가 해결된 경우가 있습니다.

Redis는 **너무 큰 데이터를 저장할 때도 문제가 발생**할 수 있습니다. 하나의 컬렉션에 너무 많은 데이터가 들어가거나, 하나의 키-밸류 쌍에 10MB, 20MB 이상의 큰 데이터를 집어넣는 경우입니다. Redis의 권장 키 크기는 몇 KB 수준이며, 텍스트 데이터로는 1MB 이상 채우기 어렵지만, 의도치 않게 큰 데이터가 들어가는 경우가 있습니다.

예를 들어, 위지윅 에디터에서 이미지를 복사하여 붙여넣을 때, 일부 에디터는 이미지를 Base64로 인코딩하여 HTML 본문에 직접 삽입합니다. 휴대폰으로 찍은 사진(4~6MB)이 Base64로 인코딩되면 33% 정도 크기가 증가하여 6MB 이상이 될 수 있습니다. 이러한 이미지가 서너 개만 포함되어도 하나의 게시글이 30MB에 달할 수 있으며, 이 글이 Redis 키의 밸류로 저장될 경우 **하나의 호출만으로도 Redis가 수백 밀리세컨드 이상 지연**될 수 있습니다. 이는 초당 10개밖에 처리하지 못하는 상황을 야기하여 Redis의 성능 저하 및 장애로 이어집니다.

따라서 캐싱할 때 **데이터 사이즈 체크는 필수**입니다. Redis는 기본적으로 512MB의 최대 밸류 크기를 권장하며, 이러한 큰 데이터는 Redis의 빠른 처리 속도를 저해하므로 주의해야 합니다.

결론: Redis 장애 예방을 위한 핵심

Redis 장애를 예방하기 위한 핵심은 **O(N) 명령의 위험성을 인지하고 피하는 것**입니다. Redis는 싱글 스레드이므로, 데이터량이 많아질수록 느려지는 O(N) 명령은 전체 시스템을 블록할 수 있습니다. 만약 O(N) 명령이 불가피하다면, 특정 키를 쪼개서 컬렉션에 값을 분산 저장하는 등의 방법을 고려해야 합니다. 또한, **서비스 특성에 맞는 적합한 자료 구조를 선택하는 것이 중요**합니다. Spring Redis 토큰 스토어 사례처럼 부적합한 자료 구조 선택은 대규모 장애로 이어질 수 있으므로, Redis 사용 시에는 항상 명령의 시간 복잡도와 데이터 크기를 고려해야 합니다.

발표자가 언급한 Redis의 라이선스 변경(RSAL, SSPL -> AGPL v3)이 클라우드 서비스 제공 업체 및 Redis 사용자에게 어떤 영향을 미치는지 설명해 주세요.

Redis를 사용할 때 'KEYS' 명령어 사용이 서비스 장애를 유발하는 주요 원인과 그 해결책인 'SCAN' 명령어의 작동 방식에 대해 자세히 알려주세요.

Redis에서 대기열을 구현할 때 리스트(List) 자료구조 사용 시 발생할 수 있는 문제점과, 이를 해결하기 위해 Sorted Set을 사용하는 것이 어떻게 도움이 되는지 설명해 주세요.

Redis에 너무 큰 데이터를 저장할 때 발생할 수 있는 문제점은 무엇이며, 특히 이미지와 같은 데이터가 Base64 인코딩되어 저장될 경우 어떤 추가적인 문제가 발생할 수 있는지 궁금합니다.

발표자가 강조하는 Redis 장애의 주요 원인인 'O(N) 명령의 위험성'에 대해 구체적으로 설명하고, 이를 피하기 위한 권장 사항은 무엇인가요?

Redis 장애의 원인과 해결 방안 소개

발표 주제는 서비스의 Redis 장애 원인 분석이며, AI 관련 내용은 없음

Redis는 인메모리 키-밸류 NoSQL로 다양한 자료 구조를 제공함

많은 서비스에서 사용되며, 초당 10만 TPS의 빠른 처리 속도를 가짐

2009년 살바토레 산필리포가 개발했으며, 겟셋 명령은 초당 10만 TPS를 처리함

Redis 라이선스 변경과 Valkey의 등장

Redis 라이선스 변경으로 클라우드 업체들이 7.2.4 버전부터 Redis 사용에 제약이 생겼고, 이에 반대하여 Valkey가 포크됨

Redis의 AGPLv3 라이선스는 서버로 사용할 경우 소스코드 변경 여부와 상관없이 배포로 간주하여 전체 소스코드 공개 의무를 발생시킬 수 있음

회사에서는 Valkey 사용이 더 나을 수 있으며, Redis와 Valkey 중 선택을 신중히 해야 함

Redis 장애의 주요 원인: 사람의 실수와 오해

과거 하드웨어 장애가 많았으나, Redis 장애는 대부분 사람의 실수로 발생함

Redis를 많이 사용하지만 여전히 잘못 알고 있는 부분이 많으며, Redis가 모든 것을 잘 처리해 줄 것이라는 오해가 있음

Redis는 기능이 단순하여 조심해서 사용하지 않으면 오히려 장애가 더 자주 발생할 수 있음

Redis의 싱글 스레드 아키텍처와 `KEYS` 명령어의 위험성

Redis는 본질적으로 싱글 스레드이며, 한 번에 하나의 명령만 처리 가능

`KEYS` 커맨드는 Redis에 존재하는 모든 키를 검색하여 반환하며, 이 명령은 여전히 많은 회사에서 문제로 발생

`KEYS` 명령은 Redis의 해시 테이블 구조에서 모든 키를 순회해야 하므로 매우 느림

`KEYS` 명령은 패턴과 상관없이 전체 키 개수에 영향을 받으며, 키 개수가 많아질수록 느려짐

`KEYS` 명령 수행 중에는 다른 작업이 전혀 처리될 수 없어, 1초만 지연돼도 수만 개의 명령이 타임아웃될 수 있음

`KEYS` 명령어 문제 해결 방안: `SCAN` 명령어와 자료 구조의 활용

`SCAN` 명령은 짧은 작업을 여러 번 반복하여 Redis 블록킹을 피할 수 있음

`SCAN`이 전체 수행 시간은 더 걸리지만, 중간에 다른 명령 처리가 가능하여 시스템 전체에 미치는 영향은 적음

API 호출 지연을 피하기 위해서는 `KEYS`나 `SCAN` 대신 적합한 자료 구조를 사용하여 키를 저장하고 검색해야 함

잘못된 자료 구조 선택과 대기열 구현 사례

Redis로 대기열을 구현하는 경우가 많지만, 잘못된 자료 구조 선택 시 장애가 발생할 수 있음

대기열은 빠른 처리, 특정 시점 트래픽 집중, 순서 보장이 중요하며, DB 기반 구현 시 사용자 폭주에 취약

순서 보장을 위해 `LIST` 자료 구조를 선택하는 경우가 많지만, 사용자 순서를 보여주는 기능에서 문제가 발생

`LPOS` 명령은 `LIST` 내 특정 값의 위치를 찾는 데 `O(N)` 알고리즘을 사용하여, 대기열이 길어지면 Redis 블록킹을 유발하여 장애를 발생시킴

대기열 문제 해결 방안: `Sorted Set` 활용

대기열 순서 보장 및 빠른 조회를 위해 `Sorted Set`을 사용하는 것이 적합

`Sorted Set`은 `O(log N)` 알고리즘을 사용하여, 리스트의 `O(N)`보다 훨씬 빠름

들어가는 시간이나 유니크한 카운트 값을 정렬 기준으로 사용하여 순서 보장과 속도 개선을 동시에 달성할 수 있음

너무 큰 데이터 사용 시 문제점

`O(N)` 자료 구조에 너무 많은 데이터가 들어가거나, 하나의 키에 너무 큰 데이터(10MB~20MB 이상)를 넣으면 문제가 발생

의도치 않게 Base64 인코딩된 이미지 데이터가 Redis 키 밸류로 저장되어 키 크기가 커지는 경우가 발생

스마트폰 사진(4~6MB)이 Base64로 변환되면 33% 정도 크기가 커져, 텍스트 형태의 6MB 데이터가 될 수 있음

위지윅 에디터에서 이미지 복사 붙여넣기 시 Base64로 변환되어 하나의 글이 30MB 이상 되는 키 밸류로 저장될 수 있음

30MB 크기의 키 밸류는 Redis 호출 시 밀리세컨드 단위로 속도를 저하시켜 처리량을 크게 감소시킴

Redis 캐싱 시 데이터 사이즈를 반드시 체크해야 하며, 권장 크기는 몇 KB 수준

Redis 장애 방지를 위한 최종 결론

Redis는 싱글 스레드이므로 `O(N)` 명령 사용 시 데이터량이 많아질수록 느려지는 위험성을 항상 인지해야 함

`O(N)` 명령이 불가피할 경우, 특정 키를 쪼개서 컬렉션에 값을 분산 저장하는 방법을 고려해야 함

Redis는 심플한 인메모리 NoSQL 캐시 스토어이므로 하나의 명령이 길게 처리되는 것을 피하고 테스트를 통해 검증해야 함

Redis 사용 시 특정 기능에 적합하지 않은 자료 구조를 선택하는 오류를 피해야 함 (예: 스프링 레디스 토큰 스토어의 리스트 저장 사례)

[Lablup Conf 5th] 우리 서비스의 Redis는 왜 매일 장애가 날까? (강대명)

스크립트