AWS Elasticache Fail-over될 때, 주의할 점(경험)

왜 이 경험을 하게 되었을까?

현재 Redis의 Memory 용량이 일정 예약사이즈 허용치보다 높아져서 자동 스냅샷 또는 제대로 작동이 어려운 상황에 처했다.

아마도 expired가 되지 않는게 이슈였고 TTL이 지나치게 길거나 없는 것이 문제가 되는 것 같았다.

레거시 프로젝트기 때문에 요청받은대로 검토만 했었다.

 

---

 

내가 해야할 것은 무엇이었을까?

이럴 때, 할 수 있는 일은?

- 키제거

- 스케일업

 

---

 

내가 뭘 했을까?

키 제거는 당연히 할 수 있는 간단한 일이면서 비용적으로 도움이 되는 일이었다.

그렇기 때문에 우선 Redis와 Server의 구조를 파악해야 했고

Redis에 어떤 정보가 저장되는지? 만약 Redis에서 중요 정보를 사용한다면 언제 DB와 동기화 시키는지?

등과 같은 정보가 필요했다.

역시 레거시를 파악해보니 TTL이 적용되지 않은 키가 많았고 옛날의 키가 쓰이지 않음에도 저장되고 있었다.

 

하지만 정확하게 어떠한 키를 사용하고 안하는지 모르기 때문에

서버 운영자에게 물어봤다.

redis memory 사용률이 높아져서 key를 좀 삭제하고 싶다. 그리고 앞으로 키 SET할 때는 TTL좀 두는것이 어떻냐?라고 얘기를 했다.

알겠다 하고 키 이름 및 명령어를 알려줬다.

나는 어떠한 일이 생기더라도 스냅샷이 있고, replication을 진행한 상태라서 redis key를 삭제했다.

사실.. 해당 명령어가 부하가 많이가고 레디스가 싱글스레드이기 때문에 작업 중  다른 작업을 못하는 것을 알았지만.. 부하가 그렇게 크지 않을 것이라 생각했다.

나는 운영자가 유저 볼륨이나 키가 얼마나 생산됐는지 파악해서 나에게 커맨드를 준것이라고 생각했기 때문이다.

예시를 주자면

EVAL "local keys = redis.call('keys', 'test:2020*'); for i, key in ipairs(keys) do redis.call('del', key); end; return 'Keys removed';" 0

아래 해당하는 Key 목록을 iterator 로 꺼내서 하나씩 del을 날리는 것이었다.

하지만 키 볼륨이 대단했었고 healthcheck 의 주기가 그렇게 느슨하게 되어있지 않았기 때문에

저 스크립트를 실행하는 동안에 다른 작업을 수행할 수 없게 되고 Fail-over가 났던 것이다.

replication에서도 동시에 쓰기 작업을 진행했기 때문에 또 다시 Fail-over가 났다.

정확하게 말하자면 Fail-over가 2번나서 새로운 redis 노드가 생겼다는 말과 같다.

redis는 휘발성이다. RAM과 같은 CPU에 적재하기 쉬운 High-tier 메모리란 말이다.

그래서 나는 레플리케이션이 있다라고 안심하던 찰나에 모든 정보를 잃어버렸다.

내게 남은 것은 스냅샷 이었다.

 

 

---

 

잘 수습했을까?

다행히 adb 덤프를 주기적으로 하고 있고 로그로도 복구가 가능한 수준이었기 때문에

DB log를 통해 대상자를 파악하고 복구할 수 있었다.

역시 깨달은 것이 많았다.

- 오래된 애플리케이션의 운영자는 자기 자신도 누구한테 인수인계를 받았기 때문에 잘 모른다.

- replication이 있더라도 fail-over가 연속되는 경우도 있으니 항상 조심할 것

- redis가 없더라도 response time이 느려질 뿐 서비스에 영향이 가선 안될 것

- 스냅샷도 부담이될 수 있기에 적당한 주기를 찾아볼 것

- 서버 운영자가 제일 잘 알겠지 ~ 라는 마인드로 접근하지 말고 내가 한번 더 검증해볼 것

 

을 배웠다.

다음엔 내가 운영자한테 key랑 del 쓰셨는데요. redis 부하를 위해서 scan으로 페이지네이션하고 unlink를 쓰는게 좋지 않을까요? 라고 할 수 있는 사람이 되어야 겠다.