스케쥴러 잡을 만들면서 알게 된 내용들

Restart Programmer
4 min readFeb 23, 2024

--

회사에 존경스러운 시니어 및 사수가 될만한 분들이 왔다. 사수님들의 노하우와 많은 분들이고, 그로 코드리뷰는 내 바지가랑이가 찢어지는 수준이였다.

내가 cron job을 변경하면서 다음과 같은 부분을 지적받으면서 이를 정리하기 위해서 이번 글을 적어본다.

Photo by Christopher Gower on Unsplash

작은 청크단위로 데이터를 나누기

나는 C#에서 타입스크립트로 멀티 스레드 언어에서 싱글 스레드로 하다보니 많이 성능에 대한 부분을 신경써야 했는데, 일단 기본적인 작은 청크 단위로 데이터를 가져오고 데이터를 수신하는 방향으로 신경 써야했다.

이는 가장 간단한 테크닉이긴 하지만 정말 유용하다. 예를 들어 1년동안 로그인하지 않는 유저들을 대상을 쿠폰을 주는 이메일을 보낸다는 가정을 하게 되면, 1년동안 로그인한 유저의 데이터를 가져오는데도 나눌 수 있다면 나누었고, 이메일을 보낼 때 특히 100명이든 1000명이든 다 보내도록 하지 않고, 이를 나누어서 처리했다.

내가 생각하고 정리해서 찾아본 청크 단위로 나누는 이유는 아래와 같다.

  • 대량의 데이터를 한번에 메모리에 로드하지 않고, 작은 청크 단위로 나누어서 순차적으로 처리하면 사용되는 메모리를 아낄 수 있다.
  • 대용량 데이터를 네트워크로 전송할때 각 청크의 전송 실패시 재전송하면 되므로 전체적으로 네트워크 효율성과 안정성이 증가함
  • 오류가 났을 경우 오류난 청크만 재처리하면 되므로 복구가 용이함.

나누어서 처리하게 되면 여러가지 장점을 많이 가지게 되므로 큰 단위로 처리해야하는 경우는 나누어서 처리할 수 있는 방안을 백엔드 개발자라면 필수적으로 생각해야함을 다시 한번 배웠다.

DB에 대한 이해도가 중요함

백엔드 개발자로서 제일 중요한건 DB에 대한 이해도라고 생각이 들었다. 실제로 DB에 대한 이해도가 제일 중요하다고 말하는 분이 많았다. 이는 RDBMS 아니라도 NoSQL도 마찬가지다.

어떤 상황에서 Lock이 걸리는지와 어떤 상황에서 인덱스가 걸리는지에 따라서 속도차나 성능을 비교해보면 너무 차이난다는 것을 알 수 있어고, 특히나 이런 상황이 점점 트래픽이 올라가면서 설계와 상황에 따라서 자주 발생한다는 점을 알았다.

Redis도 다양한 자료구조를 지원하고, 지원하는 기능을 잘 사용하면 캐시를 통해서 정말 많은 성능 최적화가 된다는 사실을 배웠다. 특히 실시간 랭크 시스템을 만들거면 Sorted Set을 사용하면 정말 성능 좋고 쉽게 만들 수 있다는 사실을 배웠다.

즉 인덱스와 어떤 상황에서 Lock이 걸리는지 파악하고, 어떻게 캐시를 사용하는지 알면 성능을 극한으로 끌어올릴 수 있다고 생각한다.

Photo by Giulio Magnifico on Unsplash

Cursor Base

데이터를 가져올떄 커서 기반으로 가져오게 되면 정말 많은 이득을 받을 수 있다. 특히나 성능에 이득을 받을 수 있는데, 이를 머리를 사용해서 만들면 누구보다 좋은 스케쥴 잡을 만들 수 있다.

PK 값이 int 로 된 Auto increment인 경우 시간 복잡도를 줄이는 방법으로 커서 기반으로 조회하는 방법이 있다.

예를 들면 데이터 생성 시간이 어느 정도 이상 되는 값을 가져오게 된다면 차라리 그 시간 이상인 경우의 pk 값을 가져와서 그 이상 부터 pk 값으로 조회하게 되면 MySQL은 PK 인덱스가 되어 있어서 상당히 많은 성능적인 이득을 보게된다. (이렇게 만들어라는 코드리뷰를 정말 많이 받았다.)

위 이야기도 정말 많이 못 풀어서 설명했지만 큰 원리는 찾아서 볼 수 있을거 같았다.

적어도 이 블로그에서 이 글은 다시 한번 내가 성능에 대해서 생각하고 공부의 방향을 잡도록 할 수 있을거 같았다.

이런 배움을 배울 수 있는 나의 사수들에게 너무 감사함을 느낀다.

--

--