[SW 정글 124일차] 나만의 무기 32일차 (생명체 사망 리팩토링)

오늘의 주요 작업은 생명체 사망 리팩토링이다.

어제 오전 6시쯤 침대에 누워 잠에 들려고 할 때 조장님이 방에 와서 제안한 것이다.

 

기존의 생명체 사망 처리는 00시 00분에 스케줄러가 돌아서 자동으로 사망처리해야할 생명체를 DB 테이블에서 상태처리를 UPDATE 처리해주는 형식이였다.

그리고 다른 테이블에서 UPDATE나 DLETE를 해줘야하는 작업은 트리거에 의존하고 있었다.

트리거에 의존하는 것은 현업에서 지양한다는 멘토님의 얘기를 듣고 계속 트리거를 제거하고 sql문으로 해결하려고 틈틈히 고민하고 있었는데 해결을 하지 못하고 있는 상태였다.

 

 

생명체 사망 처리에서 바꾸고자 한 구조는 당일 챌린지를 수행하고 인증을 해야할 생명체에게 오후 11시 30분에 실시간으로 noti를 해주는 것이다.

이를 위해서는 지금 소켓서버 커넥션 구조가 잘 되어있어서 소켓서버를 리팩토링할 필요는 없었다.

(물론 클라이언트에서 noti를 위한 추가 작업이 필요)

그러면 여기서 추가되어야 할 것은 noti를 날릴 생명체를 DB에서 SELECT해와야 하는 것이고 SELECT해온 정보를 소켓서버에서 실시간으로 커넥션된 유저들에게 날릴 수 있다.

 

하지만 이보다는 redis라는 인 메모리 방식 db를 도입하기로 결정했다.

redis는 인 메모리 방식이기 때문에 read나 write작업이 디스크 방식인 일반 RDBMS나 NoSQL보다는 빠르다.

 

전체적인 방식은 다음과 같다.

1. 23시 30분에 스케줄러가 돌아서 아직 인증을 하지 않은 생명체 리스트를 key-value 형식으로 redis에 저장을 한다.

2. redis에 저장을 한 정보들을 소켓서버에서 읽어서 실시간으로 noti를 날린다.

2-1. 23시 30분 ~ 00시 00분에 인증을 한 생명체는 죽어야 할 대상에서 제외되므로 redis 리스트에서 삭제한다.

3. 00시 00분이 되면 redis에 남은 리스트를 조회하여 사망처리를 위한 DB 배치작업을 한다.

(DB 배치작업은 생명체 테이블 상태값변경, 챌린지 테이블 참여자수 -1, 유저테이블과 챌린지 테이블 N:M관게를 위한 foreign key를 가지고 있는 테이블에서 row 삭제)

 

 

여기서 드는 의문점은 스케줄러를 node api server에서 돌리는 것이 맞을까?

그냥 소켓서버에서 돌려도 되지 않을까?

-> 어차피 현재 서버 구조도에서는 api server와 소켓서버가 같이 있기 때문에 작업복잡도 면에서 누가 더 바쁘니까 여기서 해야한다는 고려안해도 될 듯.

-> 그러므로 기존에 api server에 있는 스케줄러 코드를 리팩토링 하는 작업이 개발시간투입량이 더 적을 것으로 예상

 

 

redis를 꼭 써야하는가?

-> db에서 select해 온 정보를 임시적으로 담고 있어야할까하는 면에서는 이렇게 담아두면 00시 00분에 사망처리하는 작업에서 시간복잡도 면에서 줄어든다.

모든 row를 보면서 23시 30분에 했던 작업과 겹치는 작업을 하지 않고 redis에 들어있는 정보를 기반으로 할 수 있다.

-> redis에서 정보를 관리하는 것이 MySQL에서 임시 테이블을 만들어서 관리하는 것보다 빠르다.

-> 빨라야 하는 이유는 소중히 키우던 생명체를 잃을 수 있는 위기에 처해있으므로 noti를 빠르게 전달해줘야한다.

-> but, 우리의 서비스에서는 데이터가 많지 않기 때문에 시간적으로 크게 차이는 나지 않는다.

 

 

 

해야할 것은 명확히 정해졌고 일단 인증요청 api를 손보고 00시 00분 사망처리 스케줄러는 완성은 했지만 비동기 처리를 위한 코드 수정이 필요해서 자고 온 뒤에 하려고 한다.