"2015년 3월 ObjectRocket.com/blog에 최초 게시"
Redis®는 정말 훌륭한 도구이며, 개발자 커뮤니티에서도 큰 사랑을 받고 있습니다. Antirez의 작은 개인 프로젝트에서 시작해 이제는 업계 표준 인메모리 데이터 저장소로 자리 잡았습니다. 그만큼 Redis를 올바르게 사용하기 위한 모범 사례들도 함께 발전해 왔는데요. 이 글에서는 Redis를 제대로 활용하기 위한 10가지 핵심 팁을 살펴보겠습니다.
1. KEYS 명령어 사용을 멈추세요
글의 첫머리부터 외치듯 시작하는 것이 좋은 방법은 아니지만, 이것이 아마도 가장 중요한 포인트입니다. Redis 인스턴스를 점검하다 보면 commandstats를 열었을 때 KEYS 명령이 눈에 띄는 경우가 너무나 흔합니다. 프로그래밍 관점에서 보면 아래와 같은 의사 코드가 자연스럽게 느껴질 수 있습니다.
for key in 'keys *':
doAllTheThings()
하지만 키가 예를 들어 1,300만 개쯤 된다면 상황은 달라집니다. KEYS는 O(n) 복잡도를 가지며, 여기서 n은 반환되는 키의 개수입니다. 즉, 처리 속도가 데이터베이스 전체 크기에 좌우됩니다. 더 심각한 문제는 이 작업이 진행되는 동안 해당 인스턴스에서 다른 어떤 명령도 실행할 수 없다는 점입니다.
대안으로 SCAN을 사용해 보세요. SCAN은 데이터베이스를 점진적인 단위로 순회할 수 있게 해주며, 반복자(iterator) 기반으로 동작하기 때문에 필요할 때 멈추고 다시 진행할 수 있습니다.
2. Redis를 느리게 만드는 원인 파악하기
Redis는 로그가 그리 상세하지 않기 때문에 인스턴스 내부에서 무슨 일이 벌어지고 있는지 추적하기가 쉽지 않습니다. 다행히 Redis는 commandstat 유틸리티를 제공하여 다음과 같은 정보를 확인할 수 있습니다.
127.0.0.1:6379> INFO commandstats
# Commandstats
cmdstat_get:calls=78,usec=608,usec_per_call=7.79
cmdstat_setex:calls=5,usec=71,usec_per_call=14.20
cmdstat_keys:calls=2,usec=42,usec_per_call=21.00
cmdstat_info:calls=10,usec=1931,usec_per_call=193.10
이 출력 결과를 통해 각 명령이 몇 번 실행되었는지, 그리고 실행에 걸린 시간(마이크로초 단위의 총합과 호출당 평균)을 한눈에 파악할 수 있습니다. 통계를 초기화하고 싶다면 CONFIG RESETSTAT 명령을 실행하면 깨끗한 상태에서 다시 측정을 시작할 수 있습니다.
3. Redis-Benchmark는 기준선으로만 활용하세요
Redis의 창시자인 Salvatore는 이렇게 강조했습니다. "GET/SET으로 Redis를 테스트하는 것은 비 오는 날 페라리가 사이드미러를 얼마나 잘 닦는지 시험하는 것과 같다." 많은 분들이 Redis-Benchmark 결과가 기대에 못 미치는 이유를 문의해 오시는데, 결과를 해석할 때는 다음과 같은 다양한 요소들을 고려해야 합니다.
- 클라이언트 측의 한계
- 버전 간의 차이
- 동시에 진행 중인 다른 테스트
Redis-Benchmark는 redis-server가 정상적으로 동작하는지 확인할 수 있는 훌륭한 기준선을 제공합니다. 하지만 이것을 진정한 부하 테스트(load test)로 여겨서는 안 됩니다. 부하 테스트는 실제 운영 환경에 최대한 가까운 조건에서 애플리케이션이 어떻게 동작하는지를 반영해야 하기 때문입니다.
4. 해시(Hash)는 당신의 가장 좋은 친구입니다
해시에게 저녁 식사에 초대장을 보내고, 정성껏 대접해 보세요. 기회만 준다면 해시가 가져다줄 행복에 놀라게 될 것입니다. 다음과 같은 키 구조를 너무나 자주 봐 왔습니다.
foo:first_name
foo:last_name
foo:address
이 예제에서 foo는 사용자 이름이라고 가정할 수 있고, 각 줄은 서로 다른 개별 키입니다. 이런 구조는 오류 가능성을 높이고 불필요한 키를 계속 늘려갑니다. 대신 해시를 사용해 보세요. 그러면 단 하나의 키로 모든 것을 관리할 수 있습니다.
127.0.0.1:6379> HSET foo first_name "Joe"
(integer) 1
127.0.0.1:6379> HSET foo last_name "Engel"
(integer) 1
127.0.0.1:6379> HSET foo address "1 Fanatical Pl"
(integer) 1
127.0.0.1:6379> HGETALL foo
1) "first_name"
2) "Joe"
3) "last_name"
4) "Engel"
5) "address"
6) "1 Fanatical Pl"
127.0.0.1:6379> HGET foo first_name
"Joe"
5. TTL(Time To Live)을 설정하세요!
가능한 한 만료 키(expiring key)를 적극적으로 활용하세요. 대표적인 예가 임시 인증 키 저장입니다. OAUTH와 같은 인증 키를 발급받으면 대개 만료 시간이 함께 제공됩니다. 키를 설정할 때 동일한 만료 시간을 지정하면 Redis가 알아서 정리해 줍니다! 더 이상 KEYS로 수많은 키를 일일이 순회하며 청소할 필요가 없습니다.
6. 적절한 축출(Eviction) 정책 선택하기
키 정리 주제에 이어 축출 정책에 대해서도 짚고 넘어가겠습니다. Redis 인스턴스가 가득 차면 Redis는 키를 축출하기 시작합니다. 사용 사례에 따라 다르지만, 만료 키를 사용하고 있다면 volatile-lru를 권장합니다. 캐시 용도로 운영하면서 만료 설정이 없다면 allkeys-lru를 고려해 볼 수 있습니다. 사용 가능한 옵션들은 공식 문서에서 확인하시기 바랍니다.
7. 중요한 데이터라면 try/except를 사용하세요
데이터가 반드시 Redis 인스턴스에 저장되어야 한다면 try/except 처리를 강력히 권장합니다. 대부분의 사람들은 Redis 클라이언트를 fire-and-forget(발사 후 망각) 방식으로 설정하기 때문에, 키가 실제로 데이터베이스에 기록되지 않는 경우에 대비해야 합니다. 이 경우 Redis 호출에 추가되는 복잡성은 거의 없으며, 중요한 데이터가 제자리에 안전하게 도달하는지 보장할 수 있습니다.
8. 하나의 인스턴스에 몰아주지 마세요
가능한 한 워크로드를 여러 Redis 인스턴스에 분산하세요. Redis Cluster는 버전 3.0.0부터 사용할 수 있으며, 키 범위를 기준으로 주(primary)-복제본(secondary) 세트에 키를 분배할 수 있게 해줍니다. Redis Cluster의 동작 원리에 대한 자세한 설명과 튜토리얼은 redis.io 공식 문서에서 확인할 수 있습니다. 클러스터링이 어렵다면 네임스페이싱(namespace)을 통해 키를 여러 인스턴스에 나누어 배치하는 방식을 고려해 보세요. 데이터 파티셔닝에 대한 훌륭한 가이드도 redis.io에서 찾을 수 있습니다.
9. 코어가 많으면 성능이 좋아질까?
아닙니다. Redis는 단일 스레드(single-threaded) 프로세스로 동작하며, 영속화(persistence)가 활성화된 경우에도 최대 두 개의 코어만 사용합니다. 동일한 호스트에서 여러 인스턴스를 실행할 계획이 아니라면—그런 경우는 개발·테스트 용도 정도일 것입니다—Redis 인스턴스에는 두 개 이상의 코어가 필요하지 않습니다.
10. 고가용성(HA) 구성을 고려하세요!
Redis Sentinel은 이제 충분히 검증되었으며, 많은 사용자가 실제 운영 환경(Rackspace ObjectRocket 포함)에서 사용하고 있습니다. 애플리케이션이 Redis에 크게 의존한다면 서비스 중단 없이 온라인 상태를 유지하기 위한 고가용성(HA) 솔루션을 반드시 검토해야 합니다. 물론 직접 관리하고 싶지 않다면 Rackspace ObjectRocket이 24×7 지원과 함께 HA 플랫폼을 제공하니 한번 사용해 보시기 바랍니다.
Rackspace DBA Services에 대해 더 자세히 알아보세요.
피드백 탭을 통해 의견을 남기거나 질문할 수 있습니다. 또한 Sales Chat을 클릭해 지금 바로 상담을 시작할 수도 있습니다.
여기를 클릭하면 Rackspace Cloud 서비스 약관을 확인할 수 있습니다.