[Node.js] Node.js 프로파일링

Ref

• 이 글은 인프런 퇴근길 밋업 중 김경덕 님의 발표 내용을 정리한 내용입니다.
• 해당 발표는 인프런에서 발표 자료를 제공하고 있으니, 원문을 참고하시는 것을 추천드립니다.

서론

• Node.js는 싱글 스레드인 이벤트 루프로 이벤트들을 처리하며 비동기 API를 사용함.
• Node.js의 전체 런타임에서 스레드가 하나인 것은 아님. (worker_threads)
• 만약 Event loop에서 CPU-intensive한 작업을 하면 어떻게 될지와 이를 분석하는 툴을 소개하는 것이 발표 주제.

CPU-intensive

• CPU 연산을 많이 요구해서 오래 CPU를 점유하는 작업.
• 발표자는 호출 시 20초 간 이벤트 루프를 점유하는 함수를 작성하여 호출하였음.
• 테스트를 통해 다른 해당 점유로 인하여 다른 request 들이 처리 안되는 것을 확인함.
• 즉, 이벤트 루프를 특정 코드가 오래 점유하면 다음과 같은 현상이 발생함.
  1. Node.js의 request 처리량 감소.
  2. 레이턴시 증가.
  3. 물리 인스턴스를 증가시켜도 퍼포먼스가 비례하게 증가하지 않음.
• 3번의 내용은 Scale Out을 해도 성능 향상을 해결할 수 없다는 것을 의미하기 때문에 크리티컬함.

CPU-intensive한 코드 분석

• 결국 앞선 이유로 결국 문제되는 코드를 찾아서 해결해야 함.
• 어떤 API 호출 시 이벤트루프가 오래 blocking 되는 현상이 있는지 확인.
• 이벤트루프가 blocking이 된다면 어떤 함수에서 해당 현상이 일어나는지 파악.
• API 종류가 많다면 레이턴시가 긴 API나 빈번하게 호출되는 API를 차례대로 조사.

clinicjs(성능 분석 툴) / k6(부하 테스트 툴)

• Doctor
  • event loop가 딜레이 되는 시간을 측정하는 도구.
    • cpu 사용량, 메모리 사용량, 소켓 수를 알 수 있는 도구.
• flame: 가장 딜레이 시킨 함수를 찾아줌.
  • 어떤 함수가 가장 오랫동안 cpu를 점유하는지 Flame Graph를 볼 수 있는 도구.
• 발표자는 k6라는 오픈소스로 부하테스트를 한다고 함.

발표를 본 후 내 결론

• 평소 이슈 발생 시 분석 가능한 환경을 잘 구성해 두었는가에 대한 고찰 후 분석 환경에 대한 개선이 필요함.
• 돌이켜 생각해보면 그 동안의 성능 이슈를 일으킨 API들을 보면 어느 정도 부하가 있을 가능성에 대한 예측이 가능했던 것 같음. 테스트에 대한 고려가 충분하였는가에 대한 고찰과 개선이 필요함.
• 예를 들어 k6 좋으니까 무조건 도입하자는 것이 아니라, 상황에 맞게 적절하게 해석하여 점차 개선해나가는 것이 중요하다고 생각함.
• 싱글스레드로 서문을 열 때 부터 역시 기초를 잘 다지는 것이 중요하다고 다시금 생각이 들었음. 과연 내가 사용하는 언어, 도구에 대해 잘 알고 쓰고 있는가 스스로 꾸준한 점검이 필요함.