DBMS의 스케줄러 vs 스케줄러 서버 구성

문제 상황

• 일정 주기마다 특정 데이터의 삭제가 필요한 요구사항.
• Scheduler 서버가 별도로 분리되어 있지 않음.
• 해당 로직이 관리되고 있는 서버에 문제 발생 시 Scheduler의 기능들도 동작하지 않을 것.
• 점점 Scheduler 코드들의 중요도와 타 서비스의 의존도가 높아지고 있는 상황.

처리

• DB의 Scheduler를 이용하면 성능면에서 우수할 수 있지만, 성능을 고려할만큼의 쿼리가 아니라고 판단.
• 다른 개발자가 DB를 까지 않으면 해당 로직에 대한 존재 유무를 알 수 없기 때문에 유지보수 측면에서 Server 로직에 작성하는 것이 맞다고 판단하였음.

정리

• 별도의 Scheduler 서버로 분리하는 것이 먼저라고 생각되었지만, 우선순위에서 계속 밀리다가 결국에는 문제가 발생할 시점이 다가와서야 분리를 고려하게 됨.
• 비슷한 상황이 왔을 때, 서비스를 분리하는 시점을 잘 파악할 수 있어야 할 것 같음. 무조건 분리하는 것은 유지보수의 용이성을 떨어뜨릴 것이고, 현재와 같은 경우는 공수가 더 커질 수 있기 때문.

MySQL Event Scheduler 사용 방법 기록

-- event_scheduler 기능이 켜져 있는지 확인
SHOW VARIABLES LIKE 'event%';

-- event_scheduelr 기능이 꺼져 있는 경우
SET GLOBAL event_scheduler = ON;

-- 등록된 event 목록 조회
SELECT * FROM information_schema.events;

-- evnet 등록
CREATE EVENT evt_delete_expried_privacy_info
ON SCHEDULE EVERY 1 WEEK
COMMENT '만료된 개인정보 폐기'
DO
    DELETE FROM tst_user_privacy_info
    WHERE status = 2

https://dev.mysql.com/doc/refman/8.0/en/create-event.html