이번 주에 새로 배운 것
우리 서비스에도 집계 처리가 존재한다. 그날 발생하는 출퇴근, 휴가, 근무외, 자리비움 등의 메트릭을 이벤트 처럼 쌓아두고 이들을 종합하여 급여를 산정할 수 있도록 한다. 이러한 집계처리가 특정 도메인에만 존재하는 기능들이라고 생각했는데, 이번 9주차에서는 상품 랭킹을 통해 집계처리의 범용성에 대해 생각해볼 수 있었다.
큰 틀은 정해져있고 그 다음은 도메인 특화된 부분이 존재한다는 것을 알게되었고, 내가 어떤 도메인을 좋아하는지 이제 찾아나서야 한다는 것을 깨달았다. 나는 어떤 도메인을 좋아할까? 이전에 읽고 정리했던 넷플릭스의 광고 도메인 관련 아티클처럼 조금씩 알아가면서 나 자신을 알아가는 시간을 갖아야겠다.
이번 주차에 다뤄보고, 고민해본 토픽들은 아래와 같다:
- Redis Sorted Set (ZSET)
- 키 설계
- 롱테일 현상
- 시간의 양자화
- 가중치 합산
- 콜드 스타트 문제
- 통계가 없을때 폴백 처리
- 스코어 캐리 오버
이런 고민이 있었어요
이번 주차에서 주로 고민했던 내용은 이 개념을 어떻게 인사도메인에 적용하냐는것이다. 사실 성과, 평가와 같은 전략적 인사시스템에는 랭킹이라는 주제는 의외로 쉽게 적용해볼만할것 같다. 하지만, 내가 속한 오퍼레이셔널 인사시스템은 주로 급여, 휴가, 근태를 다루는데 근태나 휴가에서 랭킹 시스템을 도입할 수 있을만한게 있을까? 참으로 곤란했다.
대신 일 집계처리에서 고민해볼만한 사항들과 아키텍처적인 관점에서 고민을 많이했었다. 현재의 집계 처리는 배치를 통해서 쌓인 여러 RDB 데이터를 기반으로 집계처리가 이뤄진다. 이 값들을 실제로 어떻게 유저들에게 서빙할지? 과제에서 진행했던것 처럼 인메모리 저장소를 도입하는것도 고려했는데, 물론 응답속도 측면에서 좋겠지만 복잡성이 증가해서 굉장히 곤란한 운영환경의 문제점들이 도드라질것 같다는 생각이다. 혼자서 설계하고 다듬으면 좋지만 내가 리딩을 하는 입장이 아니고, 도메인에 대한 지식들이 그리고 너무 많은 케이스들이 내 머릿속에 OOM을 발생시킨다. 이걸 해결하려고 문서화를 계속하고 있지만 만족스러운 결과를 얻기 까지는 상당히 오랜시간이 걸릴것 같다.
만약 캐싱처리를 한다고 했을때? 각각의 유저들이 자신만의 데이터를 보게될텐데 캐싱처리하는 의미가 없을 수 있다. 또한 유저들이 앱을 사용하는 시간은 결국 출근, 퇴근, 휴가 신청정도이기 때문에 키-값 저장소의 운영비용하고 복잡도가 너무 커질것 같다.
앞으로 실무에 써먹을 수 있을 것 같은 포인트
메시징, 이벤트, 키값 저장소, 관계형데이터베이스 등을 목적에 맞게 사용해서 하나의 효율적인 아키텍처를 구성하는 방법을 실무에 적용해볼 수 있을것 같다. 내가 프로젝트를 리딩하는 순간이 오거나, 아니면 개인프로젝트를 통해서 원하는 서비스를 만들어보는 연습을 해봐야겠다. 아직 우리 서비스는 개선 포인트도 많아서 그러한 순간들이 오기 기다려진다.
아쉬운 점 & 다음 주에 해보고 싶은 것
10주차는 배치처리에 대해 집중적으로 학습한다. 결과적으로 얻은 데이터를 Materilized View 방식으로 조회 성능을 높이게 된다. 새로운 개념같았지만, 이미 실무에서 동료 개발자들이 적극적으로 사용하는 방식이다. 다음주에 고민해볼 키워드들은 다음과 같다 :
- 스케줄링 : 스프링 스케줄러 혹은 쿼츠
- 재실행 전략 : 실패 시 부분 롤백 vs 전체 재실행
- 병렬 스텝 : 동시 실행으로 성능 향상
- 모니터링 : 실행 로그, 실패 알림, 처리 건수 추적
- Materialized View
