cron -> Lambda + EventBridge 전환을 선택한 이유
- 나는 현재 서비스 개발 과정에서 AWS 같은 환경에서의 비용 발생을 최소화하기 위해 Ubuntu OS 가 설치된 VM 환경에서 개발을 진행하고 있다.
- 현재 집에 구축된 홈랩에서 개발 환경을 제공하고 있으나 전기 공급 문제 or 인터넷 일시적 단절 문제 같은 24시간 안정성을 해치는 문제가 존재한다.
Linux 서버 자체에서 제공하는 스케줄링은 다음과 같은 문제로 피하려고 한다.
- ⚡ 전력 공급 불안정 → 서버 다운 → cron 중단
- 🌐 인터넷 연결 불안정 → 외부 API 호출 실패
- 🔥 하드웨어 장애 → 전체 서비스 중단
- 😱 외부에 있는 경우 → 장애 발생시 조치 어려움
위 문제로 cron을 사용하지 않는다고 하면? -> "홈랩을 기준으로 프로덕션 서비스를 운영하기 위한 서버에서 안정성이 고민된다면 AWS 같은 클라우드 환경에서 동작시키면 문제가 없는것 아닌가" 라는 질문이 100% 떠오르게 될것이다.
클라우드 환경의 프로덕션에서 만약 상황에 따라 다중 인스턴스 같은 Replica를 고려해야하는 상황이 찾아오게 된다면?
Load Balancer
├── Web Server 1 (cron 실행) ← 여기서만 실행해야 함
├── Web Server 2 (cron 실행 X)
└── Web Server 3 (cron 실행 X)
- 모든 서버에서 cron 실행 → 중복 작업 발생 😱
- 한 서버에서만 실행 → 해당 서버 다운 시 작업 중단 😱
- 서버 추가/제거 시마다 cron 설정 수정 필요 😱
내가 만드는 서비스에서는 이러한 오토 스케일링 같은 부분은 사실 필요할 일이 없을 수 있다. -> 100% 확신을 가지고 이야기 할 수 없는 부분이라면 이러한 변수까지 고려해서 방안을 찾는게 맞다고 생각한다.
내가 만드는 서비스의 프레임워크인 Django 의 Django-cron을 사용하더라도, 각 서버의 프로세스가 각자 크론을 따로 실행시키는것을 피할 수 없는것도 사실이다.
INSTALLED_APPS = [
'django_cron',
]
# 여전히 각 인스턴스에서 실행됨
@CronJobBase
class MyCronJob(CronJobBase):
schedule = Schedule(run_every_mins=5)
code = 'app.my_cron_job'
def do(self):로그 관리와 디버깅 또한 이러한 다중 인스턴스 같은 부분에서도 고려할 대상이 되어버린다.
# 서버 1
tail -f /var/log/cron.log | grep my_job
# 서버 2
ssh server2 "tail -f /var/log/cron.log | grep my_job"
# 서버 3
ssh server3 "tail -f /var/log/cron.log | grep my_job"- 😱 어느 서버에서 실행됐는지, 왜 실패했는지 파악하기 어려움
다중 환경에서의 배포 및 롤백의 복잡성이 증가하는 부분도 문제가 된다.
- cron 업데이트 시나리오
- 코드 수정
- 각 서버에 개별 배포
- cron 재시작
- 문제 발생 시 각 서버 개별 롤백
- 😱 다중 서버 중 1개의 서버라도 실패하는 경우 일관성 깨짐
위에 언급한 문제 말고도 모니터링 + 비용 + 서버 관리 + 개발/스테이징/프로덕션 등의 환경 관리 등등 많은 포인트들을 고려해야한다.
Lambda + EventBridge로 전환하게 된다면?
# 모든 로그가 CloudWatch에 중앙화
aws logs tail /aws/lambda/my-function --follow💰 비용 효율성 - 서버 운영 vs 서버리스
cron 스케줄링을 위한 추가적인 cron 서버를 운영하는 경우 다음과 같은 비용이 발생한다.
- EC2 t3.small: $16.79/월 (만약 사양이 부족하다면 여기서 추가적인 비용 발생 )
- 1분마다 크롤링 작업 실행 (24시간 풀 가동 필요)
- 서버 자체 리소스 사용은 정당함
- 추가 관리 비용: (저는 실제로 적용하지 않았지만 이러한 비용까지 발생할 수 있다는 점을 참고해주세요.)
- 서버 모니터링 도구: $15/월 (DataDog 등)
- 백업 스토리지: $5/월
- 관리 시간 (월 4시간 × $50): $200/월
- 연간 총 비용: $2,838
Lambda + EventBridge로 운영되는 경우 다음과 같은 비용이 발생한다.
- Lambda 요청: 월 43,200회 (1분마다) = 무료 (100만 요청 한도 내)
- Lambda 실행 시간: 월 720분 (평균 1초/회) = 무료 (40만 GB-초 한도 내)
- EventBridge: 월 43,200회 = $0.43
- 관리 시간: 거의 0시간
- 연간 총 비용: $5.16
연간 최대 절약 비용 : $2,833(99.8% 절약!)
관리 포인트의 극적인 단순화
- cron 환경
서버 관리:
✋ OS 보안 패치 (월 1회)
✋ 서버 상태 모니터링 (일일 체크)
✋ 디스크 용량 관리 (로그 정리)
✋ 네트워크 및 방화벽 설정
✋ cron 서비스 상태 확인
다중 인스턴스 관리 (확장 시):
✋ 어느 서버에서 cron 실행할지 결정
✋ 서버 추가/제거 시 cron 재배치
✋ 각 서버별 로그 수집 및 분석
✋ 로드밸런서와 cron 서버 분리 고려
배포 및 업데이트:
✋ 각 서버에 개별 배포
✋ 배포 실패 시 롤백 프로세스
✋ 환경별(dev/staging/prod) 개별 관리- Lambda + EventBridge 환경
관리할 것들:
✅ 코드 작성
✅ 배포 (1회 명령)
✅ 끝.
AWS가 자동 관리:
🤖 서버 패치 및 보안
🤖 가용성 및 확장
🤖 모니터링 및 로깅
🤖 장애 복구
🤖 백업 및 재해복구관리 복잡도의 실질적인 비교 예시
- cron 환경
1. 스크립트 파일 작성 (30분)
2. 각 서버에 파일 배포 (15분)
3. crontab 수정 (10분)
4. 권한 및 환경변수 설정 (15분)
5. 로그 로테이션 설정 (10분)
6. 모니터링 알람 설정 (30분)
7. 문서화 (20분)
총 소요 시간: 2시간 10분
관리 포인트: 7개 서버 × 7개 설정 = 49개 체크리스트- Lambda + EventBridge 환경
1. 함수 코드 작성 (30분)
2. 배포 (5분)
3. EventBridge 규칙 생성 (5분)
총 소요 시간: 40분
관리 포인트: 3개 체크리스트장애 대응 시나리오 비교 예시
- cron 환경
시나리오: 크롤링 작업이 갑자기 동작하지 않음
1. 어느 서버에서 문제인지 확인 (10분)
ssh server1 "sudo systemctl status cron"
ssh server2 "sudo systemctl status cron"
ssh server3 "sudo systemctl status cron"
2. 각 서버 로그 확인 (15분)
ssh server1 "tail -100 /var/log/cron.log"
ssh server2 "tail -100 /var/log/cron.log"
ssh server3 "tail -100 /var/log/cron.log"
3. 스크립트 실행 확인 (10분)
ssh server1 "cd /opt && python3 crawler.py"
4. 환경변수/권한 확인 (10분)
5. 수정 후 각 서버 재배포 (20분)
총 복구 시간: 65분- Lambda + EventBridge 환경
시나리오: Lambda 함수 실행 실패
1. CloudWatch에서 에러 로그 확인 (2분)
2. 로컬에서 코드 수정 (15분)
3. 배포 (1분)
총 복구 시간: 18분핵심 요약 정리
- 📊 비용: 연간 $2,833 → $5.16 (99.8% 절약)
- ⏰ 관리 시간: 2시간 10분 → 40분 (70% 단축)
- 🚨 장애 복구: 65분 → 18분 (72% 단축)
- 🎯 관리 포인트: 49개 → 3개 (94% 단순화)
결론적으로, 일정 단위로 동작하는 스케줄링이라면 서버를 기준으로 24시간 가동은 당연히 필요한 부분,
하지만 그로 인해 발생하는 남는 리소스 + 관리 오버헤드가 문제였고, Lambda + EventBridge를 통해 해결할 수 있었습니다.
이제 서버 관리 대신 실제 비즈니스 로직 개발에만 집중하시면 됩니다! 💪