CHAPTER 10 클라우드에서 사용하는 레디스 [PART 02 실전]

I. OSS와 레디스의 차이

1. 고유 기능

(1) 완전 관리형 서비스 형태 제공

ElastiCache는 다른 AWS 서비스와의 통합이 용이할 뿐만 아니라 완전 관리형 서비스로 운영되며, 하드웨어 프로비저닝, 소프트웨어 패치 적용, 셋업, 설정 작업, 모니터링, 장애 시 자동 복구 등 대부분의 작업이 자동화되어 있다
반면, OSS Redis는 장애 대응이나 메트릭 모니터링 등 운영 전반을 사용자가 직접 관리해야 하며, 클라우드 플랫폼과의 통합 역시 별도의 작업이 필요하다
ElastiCache는 백업(자동 및 수동), 복원, 이벤트 알림, 셀프서비스 업데이트 기능을 갖추고 있어 관리 편의성이 높다

→ 실무에서는 운영 부담을 줄이고 안정적인 Redis 환경을 구성하는 데 유리하다
특히 빈번한 패치 적용, 장애 복구, 자동 스케일링과 같은 작업이 중요한 환경에서는 관리형 서비스의 이점이 크다

(2) ElastiCache 고유 기능

ElastiCache는 OSS Redis에 없는 고유 기능들을 다수 제공한다

• 자동 페일오버
• 지능형 스왑 메모리 관리
• 고유 매개변수 (예: reserved-memory-percent, close-on-replica-write)
• 온라인 리딩
• 자동 쓰기 슬롯 스로틀링
• 데이터 계층화
• 자동 스케일링
• 일부 노드 유형에서 I/O 다중 스레드 처리
• 지역 간 레플리케이션
• 계획된 유지보수의 온라인 실행

→ 실무에서는 높은 가용성과 안정성 확보를 위한 구조가 필요하며, ElastiCache의 자동 페일오버 및 지역 간 레플리케이션은 이러한 요구에 적합하다
또한 스로틀링, 온라인 리딩 기능은 복제 지연을 줄이고, 안정적인 읽기 트래픽 처리에 유용하다
자동 스케일링은 예상치 못한 트래픽 증가 상황(예: 정기적 송금 폭주 등)에 효과적으로 대응할 수 있다

---

II. 클라우드에서 사용하는 방법

ElastiCache는 OSS 버전 레디스와 호환되며, 기본적으로 애플리케이션에서 동일한 방식으로 접근할 수 있다
API를 통해 AWS CLI나 SDK에서도 생성할 수 있으며, 생성 시 보안 그룹 설정에 유의해야 한다
생성한 클러스터의 보안 그룹이 TCP 6379 포트에 대해 인바운드 허용되어 있어야 하며, 기본적으로 같은 VPC 내의 EC2에서만 접근이 허용된다는 점을 주의해야 한다

1. 엔드포인트

ElastiCache는 redis-cli와 동일한 방식으로 엔드포인트를 통해 연결할 수 있으며, 제공되는 엔드포인트 종류는 다음과 같다

• 설정 엔드포인트
• 프라이머리 엔드포인트
• 리더 엔드포인트
• 각 노드의 엔드포인트

클러스터 모드가 활성화된 경우 설정 엔드포인트를 사용하며, 이때 클라이언트가 클러스터 기능을 지원해야 한다
redis-cli에서는 --cluster 옵션으로 클러스터 기능을 사용할 수 있다
클러스터 모드가 비활성화된 경우에는 프라이머리와 리더 엔드포인트를 사용하게 된다

 

실무 관점에서

• 보안 그룹 설정이 잘못되면 VPC 내에서도 접근이 불가능하므로 사전 테스트 환경에서 CIDR을 넓게 열어두고, 점차 제한하는 방식으로 운영 가능
• 클러스터 모드 여부에 따라 사용하는 엔드포인트가 달라지므로, 클라이언트 라이브러리가 클러스터 모드를 지원하는지 여부를 검토해야 한다
• 설정 엔드포인트를 사용할 경우 redis-cli에서 클러스터 기능을 반드시 활성화해야 하며, 클라이언트 미지원 시 운영상 큰 이슈가 될 수 있다
• 여러 리전에서 서비스를 구성할 경우, 리전 간 복제 및 설정 엔드포인트 활용이 고가용성 설계에 필수적이다

 

III. 클라우드를 활용한 트러블슈팅

ElastiCache for Redis 사용 시 성능 저하, 연결 오류, 응답 지연 등이 발생할 수 있으며, 이를 진단하기 위한 핵심 항목은 다음과 같다.

1. 다양한 메트릭 확인 (CloudWatch 기반)

ElastiCache는 기본적으로 AWS CloudWatch와 연동되어 있으며, 다음 메트릭을 중심으로 진단 가능하다.

(1) CPU 관련

• CPUUtilization: 전체 노드의 평균 CPU 사용률 (여러 VCPU 포함)
• EngineCPUUtilization: Redis 엔진이 실제 사용하는 단일 VCPU의 사용률
  • ElastiCache는 싱글 스레드 기반으로 작동하므로, 전체 CPUUtilization은 낮아도 EngineCPUUtilization이 100%에 근접하면 병목이 발생한 것

→ 실무에서는 전체 CPU보다 Redis의 단일 스레드 병목(EngineCPUUtilization)에 주의해야 하며, 이 값이 90% 이상이면 성능 저하로 이어질 수 있음
→ 해결책: 파티셔닝을 통한 부하 분산, 리드 레플리카 추가, 클러스터 모드 전환

(2) 메모리 관련

• SwapUsage: 노드의 물리 메모리가 부족할 때 디스크로 스왑이 발생한 양 (MB 단위)
  • 스왑은 디스크 I/O이기 때문에 성능에 치명적 영향을 줄 수 있음
• Evictions: Redis가 메모리 부족으로 데이터를 강제로 제거한 횟수
  • LRU 정책 등에 따라 오래된 키가 제거되며, 캐시 누락(cache miss) 가능성 증가

→ 실무에서는 메모리 여유를 충분히 확보하고, reserved-memory-percent 파라미터를 조정해 스왑 발생을 예방하는 것이 중요함
→ 정기 백업이나 큰 키 쓰기 직전 스왑 증가를 모니터링하면 문제 조기 발견 가능

(3) 연결 관련

• CurrConnections: 현재 Redis 인스턴스에 연결된 클라이언트 수
  • 갑작스러운 증가 시 클라이언트 폭주, 연결 누수 가능성 있음

→ 실무에서는 커넥션 풀을 적절히 사용하고, 연결 종료가 정상적으로 이루어지는지 확인 필요

 

2. 유지보수 창 (Maintenance Window) 확인

• AWS는 정기적으로 노드의 패치나 내부 유지보수를 수행하며, 사용자가 지정한 유지보수 시간대에 실행
• 유지보수 중에는 일시적인 재시작, 연결 끊김 등의 현상이 발생할 수 있음

→ 실시간 서비스에서는 유지보수 시간이 사용자 활동이 가장 적은 시간대로 설정되어야 함
→ 실시간 거래 시스템에서는 유지보수 시간과 성능 저하 시점을 대조해 문제 원인을 추적 가능

 

3. ElastiCache 이벤트 로그 확인

• ElastiCache는 다음과 같은 이벤트를 기록함:
  • 노드 장애 및 자동 복구
  • 클러스터 크기 변경
  • 백업 완료
  • 파라미터 그룹 변경
  • 유지보수 시작 및 완료 등

→ 이벤트 로그는 AWS 콘솔, CLI, 또는 CloudWatch Events를 통해 확인 가능
→ 문제가 발생한 시점과 이벤트 로그를 대조하면 원인 파악이 용이함
→ 예를 들어 노드 장애와 자동 복구 이벤트가 있고 같은 시간대에 레이턴시 급등이 발생했다면, 그 원인을 빠르게 추적 가능함

 

실무 적용 요약

• ElastiCache 성능 저하 시에는 CloudWatch + 이벤트 로그 + 유지보수 기록을 종합 분석해야 한다
• Redis의 싱글 스레드 특성상 EngineCPUUtilization이 높은 경우가 많으며, 일반적인 CPU 모니터링만으로는 병목 파악이 어렵다
• 메모리 부족은 Evictions, SwapUsage 메트릭을 통해 빠르게 감지하고, 메모리 할당량 및 eviction 정책 검토가 필요하다
• 실시간 트래픽이 많은 금융 서비스의 경우, 장애 재현보다 모니터링 체계와 사전 설정이 문제 예방의 핵심이다