🛠️ [refactor] 학생-수업 캐싱 전략을 단순 Set 저장으로 변경

[binary-ho]

🛠️ 리팩토링이 필요한 부분

기존 구현

현재 메모리를 아끼기 위해, 학생-수업 데이터가 1개인 경우, String으로 저장하고,
학생이 들을 수 있는 수업이 2개가 될 때 부터는 set으로 저장하고 있다.

이렇게 구현한 이유는 두 가지 이유에서인데,

1. 대부분의 상황에서 학생은 (시간적으로) 한번에 한 수업에만 출석한다.
   정말 우연의 일치로 학생이 잘못 신청하고, 강사가 잘못 승인하는 경우에나, 두 가지 이상의 수업에 출석 가능한 상황이 벌어진다.
2. 기본적으로 set이 데이터를 더 사용한다. 어찌보면 당연한데, 데이터를 하나만 저장했을 때 약 100 바이트 정도 차이났다. (물론 글자 수에 따라 달라질 수 있다) Set을 구축하기 위해 약 50 바이트 보다 적은 오버헤드가 있는 것으로 추정된다.

따라서, 데이터가 없을 때는 String으로 저장하고, 읽고

2개일 때 부터는 Set으로 저장하고 읽도록 구현해 두었다.

정확히는 현재 데이터의 저장 type을 확인해서, type에 따라 다른 저장-읽기 정책을 수행하고 있는 것이다.

문제 상황

문제는 테스트시 예상치 못한 예외가 발생하는 것을 확인했다.

겨우 1만개 데이터를 저장하는데 얼추 2 ~ 3회의 예외가 발생했고, 해당 데이터는 저장되지 않았다.

이유는 싱글 스레드지만, 이벤트 루프로 처리되는 레디스 특성상 type을 확인하고 저장하는 사이에 이미 다른 타입으로 바뀌어 읽는 방식이 바뀌어버렸기 떄문이다.

set인데, string으로 읽거나 저장하는 연산을 수행한 것이다.

해결

다양한 방법을 고려했다.

1. 실패하는 경우 리트라이 한다. -> 다루기 까다롭다. 정확히 예측하기 힘든 상황인데, 계속 방법을 바꿔가면서 리트라이 하는 것은 위험해 보였다.
2. 타입 확인과 저장 과정이 한번에 이루어지도록 구현 -> 일종의 락이 걸려야 할텐데, 빠른 캐싱이 더 중요한 상황이라, 매력적으로 다가오지 않았다.
3. 방치 -> 방치하는 것도 방법이다 1만건 중 단 1, 2건이기 때문이다.
   하지만 학생이 2개 이상의 수업에 등록 되어있는 상황에서, 캐시 데이터가 아예 없다면 DB에서 데이터를 가져오기 때문에 문제가 없지만, 여러개 중 하나만 누락된다면, DB를 거치지 않기 때문에 사실상 캐시 데이터가 지워지기 전까진 출석이 불가능할 수도 있다.
4. 따라서 최종적으로 애초에 Set으로 저장하기로 결정했다. -> 읽고 쓰는 방식을 통일

트레이드 오프로 포기하게 되는 것은 용량이다. 이에, 기존 max-memroy를 2MB에서 5MB로 늘렸다.

메모리가 1GiB인 서버 스펙상 이정도는 감수할 만하다고 생각되었다.

그리고 크기를 직접 비교해본 결과 (매우 보수적으로 비교) 일단 string만 있을 때 보다 약 100 바이트 정도의 크기 차이가 났다.

약 208 바이트가 나왔는데, key와 value의 길이에 따라 달라진다고 생각해서 300 바이트라고 가정해도, 1만명 동시 캐싱시 3MB가 안된다. 이는 동시에 1만명이 출석할 수 있는 양이다.

내 서버의 현재 목표는 1000명 동시 출석이기 때문에 차고 남는다.

나머지 2MB는 1만명이 동시에 가입했을 때 이메일 인증으로 쓰기 위해 남겨 두었다.

리팩토링 작업 브랜치

feature/save-attendee-as-set

☑ Refactoring TODO

• Attendee의 Redis Read/Cache전략 Enum을 삭제한다
• Attendee Cache 데이터를 Set을 통해 저장하고 읽는 방식으로 통일한다