입사한지 얼마되지 않았을 무렵, 정해진 시간에 특정 조건에 데이터들을 변경하고, 사용자들에게 알림톡을 보내는 기능이 필요해졌다. 처음에는 이러한 기능을 어떻게 부르는지 이름조차 몰랐기에, 특정시간에 기능수행과 같은 키워드로 검색하다가 이러한 기능을 크론잡 또는 스케줄러, 배치 이런식으로 부르는 것 같아 더 자세하게 찾아봤던것 같다.
무엇을 써야할까?
검색해보니 방식은 여러가지가 있었다.
- cron
- node_schedule
- mysql event
- aws lambda
cron
cron은 ec2 instance 내에서 스크립트를 사용해 정해진 시간에 이벤트를 발생시키는 것이었다. 그러나 현재 오토스케일링이 적용되어 있어, 하나의 인스턴스에만 해당 cronjob이 동작해야했다. 그러다보니 하나의 인스턴스에서만 해당 cronjob이 실행되도록 하기란 쉽지 않을 것 같았다. 그리고 현재 무중단 배포를 위해서 손으로긴 하지만 업데이트마다 블루/그린 배포를 진행했었다. 그러다보니 동작해야하는 시간에 서버인스턴스가 종료되고 있는 경우, 동작이 누락되지 않을까 하는 걱정이 있었다. (탈락)
node_schedule
node_schedule은 nodejs의 스케줄 패키지이다. 서버가 실행되고 있는 경우에만 동작한다는 단점이 있고, 마찬가지로 하나의 서버에서만 동작해야하는데, 어떻게 처리해야할지 걱정이 되었다. (탈락)
mysql event
단순히 데이터 수정만 하면되는 경우에 사용하면 좋을 것 같다는 생각이 들었다. 그러나 알림톡도 발송해야 했고, 모든 크론잡이 한곳에 모여서 관리되었으면 했다. (탈락)
aws lambda
aws의 lambda함수와 event bridge를 이용해 정해진 시간에 lambda함수를 실행시키는 방식이었다. 람다내에서 데이터베이스에 연결하고 알림톡 API를 호출하게되면, 서버 인스턴스의 개수와 관계없이 한번만 동작할 수 있고, 서버는 무중단으로 배포되고 있기 때문에 API요청이 누락될 일도 없다고 생각했다. 마침 aws 크레딧도 엄청 많이 있었기 때문에 요금에 대한 문제도 없었다.
느꼈던 문제점
만들고 사용하다보니 느꼈던 문제점이 몇가지 있었다.
1. 서버에 있는 함수들을 사용할 수 없고 API만 사용가능 했기에 직접 코드를 새로 작성해야한다는 것이었다. (API를 사용하고 있었기 때문에, 크론잡용 토큰을 별도로 추가하고, 환경변수 세팅들이 필요했다.)
2. 서버전체가 정지할 경우, 크론잡도 정상적으로 동작하지 않을 수 있다는 것이다.
3. 지금은 slack을 알림과 이메일 알림을 통해 크론잡이 정상적으로 동작하고 있는지 확인할 수 있지만, 처음 만들 당시에는 그런 부분들을 몰랐기에 cloudwatch에 들어가서 직접 확인해야했다.
4. 코드를 zip하거나 s3에 올려 사용해야했다. 별도 깃헙 레퍼지토리에서 관리하고 있긴 했어서 github action을 통해 자동으로 배포될 수 있도록 확장할 수 있었을 것 같다. 하지만 제작해놓으면 수정이 많지 않았고, 만들어야 하는 숫자도 많지 않아 자동화를 시도하진 않았다.
결과
만족했던 것 같다. 따로 로깅을 만들지 않아도 cloudwatch에서 바로 동작 로그를 확인할 수 있다는 것도 좋았고, 크론잡 동작시간을 변경하거나 멈추는 일등은 서버의 수정없이 단순히 aws에서 마우스 몇번의 클릭으로 변경이 가능해서 오히려 편리했던것 같다.
