Batch System With Node.js, Lambda, and PostgreSQL
- Part 1. 배치 시스템 설계
목차
Part 1. 배치 시스템 설계
Part 2. 데이터 업로더 (feat. Law SQL) (링크)
Part 3. 데이터베이스 테스트 (feat. Jest) (링크)
Part 4. 결과 알람 (feat. Slack) (링크)
Part 5. 스케쥴링 (feat. AWS EventBridge rules) (링크)
Intro
백엔드 개발자로 스타트업 초기 멤버로 합류하며 여러가지 시행착오를 겪었다. 많은 일들이 있었지만 가장 어려웠던 것 중 하나가 데이터를 다루는 과정이었다. 초기에는 csv 파일을 그대로 읽어 DB에 옮겼다. 하지만 비지니스가 커질수록 데이터 양도 증가하고 의존성도 늘어남에 따라 많은 문제가 발생했다.
따라서 배치 시스템을 구축하기로 결정하였고 이 포스팅은 그에 관한 내용을 다룬다.
개발 초기 매우 단순했던 데이터 업로드 과정
데이터가 적을 땐 이정도 수준으로도 관리가 됐지만 금방 감당할 수 없는 수준에 이르렀다.
기존 방식의 문제점 및 개선 방안
문제 1. 데이터 관리의 어려움
문서를 직접 다루면서 데이터의 일관성과 정확성을 유지하기 어려움.
문서 작업에 드는 시간도 오래 걸림.
-> 데이터 적재용 Database 운영
문제 2. 자동화 어려움
매번 스크립트를 직접 실행을 시켜줘야했고 데이터 오류로 멈추는 경우가 자주 발생함.
업로드가 완료되면 데이터가 잘 들어갔는지 확인하는 것도 시간이 들었음.
-> 배치 시스템 자동화
문제 3. 디버깅 어려움
csv 내 어느 데이터에서 오류가 발생하는지 디버깅하기가 어려움.
-> 업로드 결과 모니터링 및 알림 시스템
문제 4. 속도 느림
문서를 읽고 스크립트를 실행하는 방식이었기에 큰 데이터를 처리할 땐 현저하게 속도가 느림.
-> 효율적인 배치 시스템 적용, Law Query 사용
문제 5. 데이터 담당자와의 업무 경계 모호함
업무의 책임과 역할 분담이 명확하지 않았음.
계속해서 csv 파일을 직접 수정하는 작업을 하게 됨.
-> 데이터 담당자와 백엔드 개발자가 관리하는 DB를 명확하게 구분
새로운 배치 시스템
- DB to DB 업로드 시스템
- DB를 활용한 데이터 무결성, 일관성, 유효성 유지(Columns 속성 및 Constraints 사용)
- Raw Query를 사용하여 업로더 속도 향상 및 복잡한 비지니스 로직 구현
- 테스트
- 에러 및 배치결과 결과 슬랙 알림
- 스케쥴러를 사용하여 배치 자동 실행
느낀점
새로운 배치 시스템이 안정화되기까지 시행착오를 겪었지만, 비교적 짧은 시간 내에 많은 변화가 생겼다.
이전 시스템과 비교하면 그 차이는 너무나 크다.
예전에는 직접 문서를 수정하고 스크립트를 실행하고 테스트하고 하는 게 너무 귀찮고 번잡했다.
이제는 업로드, 알림, 테스트 등 모든 작업이 자동화로 돌아간다.
내가 오직 할 일은 모든 배치 작업이 정상이라 판단되면 수동으로 데이터 버전만 올려주면 된다.
새로운 배치 시스템을 만들고 무엇보다 좋은건 마음이 훨씬 편안해졌다는 것이다.
이전에는 한 달에 한 번씩 데이터를 업로드할 때마다 새벽에 마음 조리며 작업을 해야 했던 괴로운 시절이 있었다..
물론 100% 완벽한 시스템은 아닐것이고 언젠가 또 한번 갈아엎어야 하는 날이 올지도 모르겠다.
하지만 다행히도 최근에는 문제 없이 잘 운영되고 있다.
문제가 생겼을 땐 테스트 또는 제약 조건 등을 추가하며 즉시 대처하고 있다.
댓글남기기