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

사실 제가 좀 발표를 하게 되면서 어떤 고민을 했냐면 모든 세션이 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 Conf 5th] 우리 서비스의 Redis는 왜 매일 장애가 날까? (강대명)

Scripts