항해 플러스 백엔드 과정 7주차 회고

1. 문제 (과제, 프로젝트를 진행하면서 부딪혔던 기술적인 문제)

이번 주차를 지나며 겪었던 문제는 대기열 시스템의 성능 저하와 확장성 부족 문제였습니다. 기존 DB 시스템이 일시적으로 많은 트래픽을 처리하지 못하고, 시스템의 확장성에도 한계가 있었습니다. 이는 사용자 경험에 부정적인 영향을 미쳤으며, 안정적인 서비스 제공을 위해 개선이 필요했습니다.

2. 시도

문제를 해결하기 위해 다음과 같은 시도를 했습니다:

1. Redis를 이용한 대기열 시스템 구현: 메모리 기반의 데이터 저장소인 Redis를 사용하여 대기열 시스템을 구현하였습니다.
2. Redis의 다양한 자료구조 활용: sorted set과 set 자료구조를 활용하여 대기열과 참가열을 효율적으로 관리했습니다.
3. 스케줄러 적용: 일정 주기로 대기열에서 참가열로 유저를 이동시키는 스케줄러를 적용하여 트래픽을 분산시켰습니다.
4. 토큰 검증 및 TTL 갱신 로직 구현: 유효한 API 호출 시 토큰의 TTL을 갱신하여 사용자의 세션을 유지하도록 했습니다.
5. 캐싱 전략 도입: Look Aside 및 Write Around 패턴을 사용하여 캐시를 적용, 조회 성능을 향상시켰습니다.

3. 해결

문제를 다음과 같이 해결했습니다:

1. Redis 기반 시스템 도입: 고성능의 메모리 기반 데이터 저장소인 Redis를 사용하여 대기열 시스템을 개선, 빠른 읽기/쓰기 성능을 통해 트래픽 처리 능력을 향상시켰습니다.
2. 효율적인 자료구조 사용: 대기열에는 sorted set을, 참가열에는 set을 사용하여 유저를 효율적으로 관리하였습니다.
3. 스케줄러로 트래픽 분산: 스케줄러를 통해 유저를 일정 간격으로 분산시켜 대기열에서 참가열로 진입시켜 트래픽을 안정적으로 분산시켰습니다.
4. 캐싱을 통한 성능 개선: 캐싱 전략을 도입하여 DB 조회 빈도를 줄이고, 시스템 응답 속도를 향상시켰습니다.

4. 알게된 것

문제를 해결하며 다음과 같은 점을 새롭게 알게 되었습니다:

1. Redis의 강력함: Redis를 사용함으로써 고성능의 대기열 시스템을 구축할 수 있었고, 다양한 자료구조를 통해 유연한 데이터 관리를 할 수 있었습니다.
2. 캐싱의 중요성: 캐싱을 도입하여 DB 부하를 줄이고, 성능을 크게 향상시킬 수 있음을 확인했습니다.
3. 트래픽 분산의 효과: 스케줄러를 사용하여 트래픽을 분산시킴으로써 시스템 안정성을 높일 수 있었습니다.

---

Keep : 현재 만족하고 계속 유지할 부분

이번 주를 마무리 하며 만족했던 부분은 Redis를 도입하여 대기열 시스템을 고도화 시킨것입니다. 또한 캐싱 전략을 통해 DB 부하를 줄이고 응답 속도를 개선한 부분도 만족스러웠습니다.

Problem : 개선이 필요하다고 생각하는 문제점

1. 대기열 시스템에서 참가열의 자료구조를 Set을 사용했는데 Hash Set이나 다른 구조로 변경 해보는것도 고려중입니다.
2. 참가열 토큰 TTL 갱신을 API 호출 마다 토큰검증 할때 해주고 있는데 이부분도 조금 개선이 필요해 보입니다.

Try : 문제점을 해결하기 위해 시도해야 할 것

이 문제점을 해결하기 위해 다음 한 주간 시도할 것은 다음과 같습니다:

1. 부하 테스트: 부하 테스트를 수행하여 초기 설정 값을 최적화합니다.
2. 캐싱 전략 개선: 캐시 갱신 주기 및 만료 시간을 최적화하여 캐시 효율을 높입니다.
3. 불필요한 로직 제거: 기존 DB로 사용하고있던 대기열 로직 제거