1. Overview of ElastiCache for Redis
•
고성능 인메모리 데이터베이스
•
Redis 인스턴스 장애시 자동으로 Failover
•
Redis 기본 파라미터를 사용하지 않고 EalstiCache가 추천/운영하기 효율적이라고 생각하는 파라미터로 기본 파라미터가 변경되어 있음.
•
타입 변경
•
타입 변경시 신규 Redis 인스턴스 생성 후 신규 Reid 인스턴스로 복제 진행. 복제가 완료되면 신규 인스턴스로 스위칭
→ 스위칭 시 클라이언트에서는 순단 발생. Redis 인스턴스의 IP 변경으로 인해…
클라이언트 DNS로 연결
→ 변경 작업은 최대한 영향도가 없는 시간에 진행
→ 운영 작업전 Failover될때 DNS 캐싱(TTL)으로 인해 얼마나 순단 발생하는 지 확인. TTL 조정 필요
•
스케일 아웃은 클러스터 모드로 사용할 때만 가능
•
데이터가 여러 샤드에 나누어져서 저장. 샤드를 추가하는 것을 스케일 아웃이라고 함.
•
온프레미스에서는 최소 3개의 마스터가 있어야 하나 ElastiCache에서는 하나 또는 두개의 샤드로도 클러스 사용 가능
•
최대 500개의 샤드. 샤드당 5개 복제
2. 가상 이슈 사례로 알아보는 ElastiCache 운영 방법
•
이슈 발생시 확인해야할 메트릭…
•
네트워크 - 인바운드, 아웃바운드
•
개발팀 - 변경, 새로 배포된 사항 확인
이슈 사례 1 - CPU 증가
•
CPU 92%
•
네트워크 트래픽 증가
•
커멘드 사용 수 저하로
→ 정상적으로 지금 요청 처리할 수 없는 상황은 아닌지 의심.
•
읽기 / 쓰기 커맨드 영향??
•
유형 별 카운트 지원
•
추가 메트릭을 Grafana 로 모니터링
•
mget 커맨드가 716.61ms 로 느리게 수행되고 있다.
→ 해당 시점에 5만개 가까이 한번에 실행됨.
•
위 그래프를 통해 mget이란 커맨드가 시스템 이슈에 영향을 미치고 있는것 같다…
•
mget 커맨드
→ Redis에서 String 형식의 키를 한번에 여러가 가저오는 커맨드
•
CLI에서 또는 로그 그룹에서 Slowlog 확인 가능
•
위 예에서는 mget 커맨드로 5000개 이상의 키를 가져오느라 뭔가 지연이 길어짐
→ CPU 피크
•
항상 slow log에 잡히는 것은 아니다.
•
Redis는 싱글 쓰레드로 동작하기 때문에 모든 클라이언트의 요청을 하나의 이벤트 루프에서 차근차근 수행
•
맨 우측 커맨드 경우 대기시간은 19초. 실제 처리는 1초 but, 응답은 20초
→ 이런 경우 slow log에 안잡힘
•
Redis 사용시 지연을 유발시키는 커맨드 자체를 사용하지 않는것이 좋다.
•
MGET + 위 커맨드
•
Hash, Set: 내부에 아이템이 많이 들어가면, 그런 아이템을 한번에 가져와서 지연 유발
◦
HGETALL: 내부에 모든 키와 밸류를 한번에 리턴하기 때문에 오래 걸릴 수 있다.
•
Sorted Set: 집합 연산을 할 수 있는데 집합의 카디널리티가 너무 크게 될수록 이런 집합 연산을 하는데에도 오랜 시간이 소요
•
ElastiCache에서는 엔진 CPU 사용률, CPU 사용률 메트릭 제공
•
엔진 CPU 사용률: 92%, CPU 사용률: 32%
◦
엔진 CPU 사용률 → Redis 프로세스 자체 Load
◦
CPU 사용률 → 서버 CPU 사용률
•
AWS에서는 CPU 갯수에 따라 아래처럼 모너터링 권고
→ CPU가 늘어날 수록 그 안에서 Redis가 얼마나 사용하고 있는 확인하기 어렵다.
◦
CPU가 4개 이상이면 → 엔진 CPU 사용률
◦
CPU가 2개 이하이면 → CPU 사용
→ Redis프로세스 뿐만 아니라 기타 백그라운드 모니터링 등에 사용하는 기타 백그라운드 프로세스의 로드가 같이 보는것이 좋다.
이슈 사례 2
•
네트워크 사용량 증가
•
네트워크 이슈로 인지하지 못한 이유…
◦
보통은… 대역폭이 부족해서 어 부족한 상황이다 하면은 왼쪽 그래프처럼 특정한 임계치에 더 이상 데이터가 증가하지 않는 더 이상 어 네트워크를 사용할 수 없는 이런 상황을 예상
◦
실제로는 오른쪽처럼 그런 임계치를 더 넘어선 데이터도 사용…
→ AWS 네트워크 I/O 크레딧 매커니즘으로 인해…
•
타입별로 쓸 수 있는 네트워크 대역폭이 정해짐.
•
대역폭보다 적은 네트워크를 사용할 때에는 어 크레딧 버킷에 크레딧을 이렇게 모아놨다가 더 많은 네트워크를 사용할 때 그 크레딧을 사용해서 네트워크 대역폭 버스트 네트워크 대역폭을 더 사용.
•
인스턴스에 따라 다르지만 5분에서 60분 정도 버스트 대역폭을 사용할 수 있고 버스트 대역폭은 인풋이 아웃풋이 다 각각 따르게 존재
•
Busting 될때 마다 “네트워크 수신 대역폭 허용 한도가 초과됨” 그래프에 카운팅됨.
•
Redis에 저장되는 데이터 압축 또는 스케일
이슈 사례 3 - 메모리 증가
•
개발팀에서 Redis에 데이터 입력하기 때문에 Redis운영팀에서는 데이터을 열어보기가 힘듬.
→ 그래서 분석 툴 개발했다. 
3. 신규 레디스 메모리 분석 툴 개발기
레디스 메모리 분석 툴 기능의 필요성
•
신규
◦
매일 새벽에 배치로 작업후 Grafana에 저장
◦
데이터 변화 파악 가능
Redis Keys Statistics 소개
Top 20 largest keys in Redis
Key Count by Type
Detailed Prefix Statistics
•
Redis에서 키 설계시 보통 콜론(:) 으로…
