Redis 장애
Redis 장애 대응
14일 오후 2시 36분 ~ 38분 사이에 서버에 장애가 발생했다. 장애 포인트는 AWS Elasticache Redis였고, 36분부터 문제가 생겨 38분에 복구되었다. 장애가 발생한 이유는 무엇이고, 어떻게 개선할 것인지에 대해 생각했던 것을 기록하는 글이다.
장애가 2분이나 유지된 이유
Redis 서비스에서 Primary 1대 Replica 1대를 사용하고 있는데, FailOver 설정을 해두지 않아서, Replica가 자동으로 Primary로 승격되지 않아 장애가 유지되었다. 즉, 장애 복구시간동안, Redis에 대한 요청이 모두 실패하여, 엮여있는 부분에서 장애가 발생하였다.
장애 발생에 따라 문제가 된 부분
서버에서 세션정보를 저장하는 DB로 Redis를 사용하고 있는데, 유저가 API를 요청하면, 해당 세션이 유효한지 여부를 검증할 수 없는 문제가 발생하였다.
추후, 장애 발생을 방지하기 위해 어떻게 개선할 것인가
- Redis FailOver: true 설정 ( 기존에는 false로 설정되어있었음. )
- Redis Version 5.0.4 -> 5.0.6 으로 업그레이드
- MultiAZ 설정 ( 기존에는 false로 설정되어 있었음. )
추가적인 개선
- Redis의 Read Replica에 대해서 요청하지 않고 있는데, 읽을 때, Read Replica의 EndPoint로 요청하도록 개선
개선 근거
Redis FailOver true 설정
해당 설정이 되어 있었으면, replica가 자동으로 primary로 승격되어 장애 시간이 2분이나 되지 않았을 것이다. 하지만, false로 되어 있었기 때문에, primary가 복구될 때 까지 계속 장애가 유지되었다.
Redis Version 5.0.4 -> 5.0.6 으로 업그레이드
아래의 문서를 근거로 버전을 업그레이드 할 예정이다. 만약, 문제가 생겨서 Replica가 Primary로 승격된다고 할 때, 읽기 쓰기 모두 장애는 발생하지 않는 방법이 있다면 해당 방법을 사용하는 것이 맞다 생각한다.
AWS 문서 발취
ElastiCache for Redis 클러스터의 경우, 클러스터에서 들어오는 쓰기 요청을 처리하는 중에 계획된 노드 교체가 완료됩니다.
다중 AZ가 활성화되어 5.0.5 이상 엔진에서 실행 중인 Redis 클러스터 모드 비활성화 클러스터의 경우, 클러스터에서 들어오는 쓰기 요청을 처리하는 중에 계획된 노드 교체가 완료됩니다.
다중 AZ가 활성화되어 5.0.4 이하 엔진에서 실행 중인 Redis Cluster 모드 비활성화 클러스터의 경우, DNS 업데이트와 관련하여 짧은 쓰기 중단이 발생할 수 있습니다. 이 중단은 최대 몇 초가 걸릴 수 있습니다. 이 프로세스는 다중 AZ를 활성화하지 않은 경우 발생하는 새 기본 노드를 다시 생성하고 프로비저닝하는 것보다 훨씬 빠릅니다.
이후, 업데이트 내역을 살펴보니, 바로 올려도 문제는 없을것 같긴 한데, 테스트정도는 해보는게 맞다고 생각한다. 따라서, 개발서버용 Redis를 미리 5.0.6 으로 올려서 테스트 해보고 업데이트할 예정이다.
MultiAZ 설정
만약, 특정 리전에서 장애가 발생할 경우, 해당 리전에 primary와 replica가 함께 떠있다면, 그것은 곧 장애로 이어진다. 설정을 true로 변경하게 되면, 두개 이상의 리전에서 동시에 문제가 발생하지 않는다면, 서비스는 문제없이 유지될 것이다.
Redis Read Replica End Point 사용
해당 부분은 기존에 사용하고 있지 않아서, 사용하려고 한다. 코드 상에서 Read라면, Read EndPoint로 요청할 것이고, Write라면, Primary EndPoint에 요청하게끔 개선할 예정이다.