🚀 [feature] 레디스 장애상황 출석 대비

[binary-ho]

문제 상황

현재 구현으로는, 수강생 정보 (Attendee) 캐싱은 실패하더라도 출석이 가능하지만,
열린 수업에 대한 정보인 OpenLecture 객체의 캐싱에 실패한다면 출석이 불가능한 상황이다. (수업 OPEN이 불가능하다) 즉, 레디스에 문제가 생긴다면 영원히 출석할 수 없게 된다.
또한 회원가입 과정에서 이메일 인증을 하는데 이 때도 레디스 사용이 필수다! 물론 나중에 OAuth가 도입되면서 이메일 인증은 불필요해지나, 분명 고민해봤어야 하는게 맞는 문제다.

감사하게도 얼마 전 면접 자리에서 이 부분에 대해 어떤 대처를 생각해 보았는지에 대한 질문을 받았고
문제를 인식하게 됐다.

해결책 후보들

일단 기본적으로 Redis 장애에 대한 경보를 설치한다.

1. Redis의 가용성 기능들인 센트럴이나 클러스터링 기능들은 너무 거창하다. 이들은 여러 서버를 운용하는 경우에 쓸만하다.
   • 센트럴은 최소 3개의 물리 서버를 운용할 것을 권하고 있다.
   • 클러스터링 또한 다수의 노드를 사용할 것을 권하고 있다.
   • 단순 복제는 데이터는 저장되지만, 자동 복구가 안 된다.
   • Redis 가용성 때문에 그만큼의 서버를 운용하는 것은 큰 낭비이다.
2. 레디스 사용이 불가능한 동안 DB나 로컬 캐시를 임시로 사용하도록 한다.
   • 지금 가장 시도해 보고 싶은 방법이다.
   • 문제는 장애는 어떻게 판단할 것이냐, 장애가 끝나는 것은 어떻게 판단할 것이냐, 장애가 끝난 이후 임시 저장소의 데이터는 어떻게 다시 레디스에 저장할 것이냐이다. 한번 고민해보자.
3. 레디스를 전부 걷어내고 로컬 캐싱으로 대체한다
   • 솔직히 현재 이 방법을 선택하지 않을 이유가 없다. 맨 처음엔 전혀 고려하지 못했고, 지금은 대체하지 않을 이유가 없다고 생각한다. 하지만, 평소 Redis를 공부하고 싶었던 만큼 일단 계속 사용해보려고 한다. 실제로 이제까지 Redis를 사용하면서 많이 공부하게 됐었다. 나중에 동시 쓰기 개선에 쓰일 수도 있는데, 그 뒤에도 정 필요 없다면 걷어내자

☑ Implement TODO

• [ ]