성능향상을 위한 개발 1 - Batch Job, Quartz Scheduler

성능향상을 위한 개발 1 - Batch Job, Quartz Scheduler (오타가 있네.. 사실 Quarts인줄 알았ㄷ)

 

2021년을 맞이하며 나도 어느덧 2년차 개발자가 되었다. 작년이 0년차였음 1년차인가. 작년엔 사내 시스템에 대한 큰 그림을 그려가기위해 온 시간을 할애했다면 나름 2년차인 올해엔 그 그림을 글로써 적어 누군가(최소한 나)와 공유를 해보기로 했다. 아는 것을 글로 적는 건 또 다른 문제이니까. 물론 개발에 있어 skill up하는 것이 우선이지만, 이러한 일들이 결국 skill up에 긍정적인 영향을 줄 것이라 믿는.. 믿어본다. 공학을 전공했지만 나름 문과 성향이 짙어 개발자의 인생에 내가 잘하는 무엇인가를 더해보고 싶었는데, 지금이 그 시작이 되는 것 같아 꽤나 설레이기도 한다. 사실 지금 글 다쓰고 폰트 수정하고 있었는데 맥북 꺼져서 설레는 감정은 다 사라지고 남은건 분노 뿐이다. 됐고, 어디 그 설레임 다시 한 번 느껴볼까?

 

---

1. 배치, 왜 필요할까?

회사에서 개발을 반년 정도, 길게 하진 않았지만 한 가지 느낀점은 성능에 대한 고민은 뭐랄까. 떡볶이에 치킨, 치킨에 치즈볼, 치즈볼에 떡볶이 같은 존재랄까. 그래, 떨어질 수 없는 사이다. 정말 안하고 싶은데, 안하면 허전하고.. 허접하고.. 뭐 그런.. 어쨌든, 최근에 새로운 서비스 개발을 담당했는데 내용은 아래와 같다.

 

- 앞으로는 쭉,
- 특정 조건을 만족하는 유저들을 대상으로

- 특정 정보를 암호화할 것

- 단, 해당 서비스 추가로 인해 유저 입장에서 latency는 최소화 할 것

 

물론 특정 조건을 만족하는 유저가 대상이긴 하지만, 여전히 대용량의 데이터를 읽고, 가공하고, 처리하면 서버는 순식간에 CPU, I/O 등의 리소스를 점유해서 정작 사용자 입장에서 중요한 서비스 처리는 후순위로 밀려나게 되고, 이는 고객 pain으로 이어질 수 있다. 굳이 실시간으로 처리하지 않아도 되는데 API를 개발하는 것은 리소스 차원에서 낭비라는 의미이다. 뿐만 아니라, 만약 대용량의 데이터 처리 중간에 실패한다면 다시 처음부터 처리해야할까. 지금의 나처럼. 대용량 데이터 처리를 위해서는 비지니스 로직 - 지금의 내 상황에서는 특정 정보를 암호화 하는 것- 외에 부가적으로 고려해야할 사항이 많은데, 이를 위한 것이 '배치 어플리케이션, Batch Job'이다.

 

즉, Batch Job은
- 대용량의 데이터를
- (최대한) 사용자로부터 자유롭게 (사용자 몰래)
- 정확하고 (충돌, 중단 없이)
- 신속하고 (사용자 몰래2)
- 다른 어플리케이션 혹은 서비스에 방해가 되지 않도록 수행되어야 한다.
물론 작업 중 issue가 발생할 것을 고려해 로그를 남기거나 알림을 주는 것은 당연한 문제이겠지.

 

개발자들은, 최소한 나는, 이처럼 추상적인 개념 설명만 들으면 답답해서 구체적인 내용을 봐야 속이 상-쾌 해지는데, 그 부분에 대해서도 짚어볼거다. 이번 포스트에서는 추상적인 설명만 할 거지만. 개발 이전에 이런 내용들을 알아야 적재적소에 잘 활용할 수 있다는 믿음이 있다. 우리 시스템은 Spring FW기반이므로 Spring Batch에 대해서 적어봐야지.

 

---

2. Batch는 알겠는데 Quartz는 뭘까? 

다시 본론으로 돌아와서, 담당했던 서비스를 개발하기 위해 비슷한 케이스를 분석했더니 batch job은 알겠는데 Quartz가 항상 옆에 있었다. 뭐랄까. 떡볶이에 치킨.. 치킨에 치ㅈ....  쉽게 말하자면 일은 batch job이 하고, 이러한 일을 언제 할지 스케줄러의 역할을 Quartz가 한다. 즉, 대용량의 데이터를 비지니스 로직에 따라 처리하는 것은 batch job의 영역, 스케줄 기능을 더해주는 것이 Quartz의 영역이다.

 

---

3. Additional Cases

배치는 대용량의 데이터 처리를 Quartz Scheduler를 활용해 트래픽이 몰리는 시간을 피해 처리함으로써 서버 성능을 유지시키는 방법이라고 말했다. 만약, 고려해야할 비지니스 로직은 따로 없고, A시스템에서 B시스템으로 대용량의 데이터를 전송해야할 때도 배치를 사용하면 좋을까? 결론부터 말하자면 NO이다. 이럴땐 MQ를 활용하는 것이 성능 측에서 훨씬 이득이다. MQ에 대해서도 설명하자면 길어질 수 있으므로 다음 포스트에서 따로 다루도록하고, 간단하게 설명하자면 송신 시스템과 수신 시스템 사이의 중재자 역할을 한다. 이렇게 될 경우, 배치처럼 one-time으로 이루어지는 상황이 아닌 real-time에서도 활용될 수 있다.

대표적으로 RabbitMQ, ActiveMQ, Kafka 등이 있고, 최근엔 AWS에서 지원을 하는 케이스도 봤다.