루퍼스 9주차 WIL

루퍼스 9주차 WIL

이번 주 핵심 인사이트

1. Redis의 본질을 이해하면 사용법이 따라온다

이번 주차 랭킹 기능을 구현하기 위해 Redis ZSet이 필요했다.

문득 이런 다양한 기능이 필요한 Redis는 어쩌다 만들어지게 되었을까?가 궁금해졌고 Redis의 탄생 배경을 찾아봤다.

Redis는 2007년 LLOOGG라는 서비스에서 “빠른 쓰기”와 “최근 N개 빠른 조회”를 MySQL로 감당하지 못한 문제를 해결하기 위해, 인메모리 + 싱글스레드 + I/O 멀티플렉싱이라는 기술을 사용하도록 만들어졌다.

탄생배경과 동작원리를 알고 나니 “Key가 많은 환경에서 Keys 명령어를 쓰면 위험해요”라는 실무 조언이 “싱글스레드 구조에서 하나의 명령어가 오래 걸리는 명령어 사용을 피해야 해요”를 뜻하는 것이구나로 다가왔다.

지난 주차에 낙관적인 락, 비관적인 락의 용어 탄생에 대해서도 알아본 적이 있는데, 이렇게 기술과 탄생 배경을 같이 학습하는 것이 내가 기술을 이해하는 것에 꽤나 도움이 되는 것을 느꼇다.

특정 문제 상황을 주로 생각하는 나에게, 근본적인 개념과 탄생배경을 딸각 연결해주는 AI 서브 에이전트를 만들어볼까? 라는 고민이 들었다.

2. 실패 처리는 “구분”이 핵심이다

Kafka Batch Listener를 사용하여 랭킹 스코어를 처리하는 과정에서 부분 실패를 어떻게 처리할지 고민했다. 전체 롤백, 이벤트 단위 트랜잭션, DLQ 조합 등 여러 옵션이 있었는데, 지금은 학습 프로젝트라 전체 롤백으로 단순하게 갔다.

만약 부분 실패에 대한 재처리가 필요하다면, 예외를 Exception으로 넓게 잡지 않고 네트워크 실패처럼 재시도하면 성공할 수 있는 예외만 잡아야 한다는 것도 배웠다. 지난 주차 피드백이랑 연결되는 부분이어서, 앞으로는 재처리나 예외 핸들링의 범위에 주의를 기울여야겠다.

3. 시간의 양자화라는 개념을 처음 알았다

랭킹 키를 ranking:all:yyyyMMdd 형태로 설계하면서 “시간의 양자화”라는 개념을 배웠다.

점수를 단순 누적하면 1년간 10000점 쌓은 상품을 오늘 출시된 신상품이 절대 이길 수 없다. yyyyMMdd처럼 일별로 키를 분리하면 매일 0점에서 시작하니까 신상품에게도 기회가 생기고, TTL로 메모리도 관리할 수 있다.

콜드 스타트 문제(새 윈도우 시작 시 랭킹이 비어있음)는 전날 점수의 일부를 carry-over하는 방식으로 해결할 수 있다는 것도 알게 됐다.