Scala future/blocking

늘 휴가를 가면 뭔가 이슈가 터진다.
이번 여름도 오랜만에 머리 식히려, 회사 이메일 다 무시하고 1주일 쉬고 왔는데, 
와서 체크해보다보니 creative unexpiration script가 일주일간 실행되지 않아 bidding 결과가 떨어 지는 일이 생겼다.
하필 휴가 출발하는 첫날 실행되던 Job이 vertica DB resource 이슈로  DB Connection 을 생성하지 못했는데, 
또 하필 그 Job이 Terminate 되지 않고 Hang up되어 그대로 Schedule 이 멈춰버린 것 이었다.

일단 어찌저찌 수습을 했지만, 이번엔 Tech Support 에서도 꽤 심하게 반응을 해서 Monitoring 방법을 찾아 보게 되었다.

다행히 최근에 Kubernetes 에서 Prometheus 를 통한 metrics를 구현 하게 되어 이 Job도 그렇게 해보기로 생각해 보았다.
docs/content/docs/instrumenting/exposition_formats.md at main · prometheus/docs (github.com)

문제는 CronJob 에 대해서도 Prometheus가 metrics 를 지원하냐 인데 prometheus 관련 annotation을 넣었더니 metrics  end-point를 1분 마다 hitting하는것은 확인이 된다.
그럼 1분 동안의 데이터를 유실할 수 있는 문제가 생기는데, 우리는 Job이 실행되는 거만 체크하려는 거니깐 1분 데이터 정도는 큰 문제가 되지 않을 듯 싶었다. 다만 전에는 모든 처리가 끝나고 메일 보내기 전에 metrics count를 set하게 되어 있었는데, 이걸 매번 creative processing할 때 metrics 를 update 하도록 변경해야 하였다.

당연히 문제 없이 될 줄 알았는데... 이게 Job 시작할 때 50 정도 까지 Counting을 하고 바로 Counting이 되지 않는 거다.
코드를 봐도 문제가 없고, 로그를 보면 Prometheus 가 metrics end point도 잘 hit하는게 보인다.

이게 무슨 문제일까 싶어서 metrics count method에서 로그를 찍게 해보니 Cronjob이 끝날때쯤에 갑자기 count method가 집중적으로 찍히는게 보인다.

이게 무슨 일일 까 싶었는데... 찾아 보니 future에 map을 사용할 경우 같은 future내의 connected processing이 되는 게 아닌 또 다른 future 객체가 생성되어 map operation이 수행되는 것이다.
내 local 환경에서는 map을 써도 단일 thread내에서 처리되듯이 큰 문제 없이 수행이 되는데..
서버에만 가면 metrics 의 count method를 위한 map processing을 처음 50개 정도는 바로 진행하지만 그 이후는 모두 wait 하였다가 cronjob이 끝날 때 한꺼번에 처리 해서 생긴 문제였다.
생각해보면 metrics count같은 method를 매번 처리 하는 것 보다 한번에 몰아서 처리하는 게 성능상으로는 더 좋을 것 같다는 생각이 든다.

어쨋든.. future.map을 이전 process 이후 바로 실행하게 하려고 찾아보다보니 blocking을 사용하면 전체 processing를 하나의 thread로 묶어서 처리 할 수 있게 되어 있다.

Understanding Scala Futures and Execution Contexts – Beyond the lines

Understanding Scala Futures and Execution Contexts – Beyond the lines

늘 느끼는 거지만 future가 개념 잡기도 어렵지만 사용하기도 참 어려운 기술이라는 생가이다.
아니면 아직도 예전 blocking 기반의 기술 에서 벗어나지 못해서 인걸 수도 있겠다.