논블로킹 IO나 가상 스레드 적용할 때는 먼저 다음을 검토하자.
- 문제가 있나?
- 문제가 있다면 네트워크 IO 관련 성능 문제인가?
- 구현 변경이 가능한가?
성능 문제가 없고 당분간 트래픽 증가 가능성 없다면 검토할 필요가 없다. 문제가 없는데 구현을 변경하는 것은 시간 낭비임.
논블로킹/비동기 IO 방식으로 구현하면 코드가 복잡해지고 유지보수 난이도가 올라감.
성능 문제가 있다면 네트워크 IO와 관련된 자원 문제인지 먼저 확인. 트래픽이 그대로인데 DB 쿼리 시간이 느려지면서 서버 응답이 길어지는 문제가 발생했다면 가상 스레드나 논블로킹을 적용해도 응답시간 줄일 수 없다.
논블로킹은 처리량만 향상시켜줄뿐임! 이 경우 쿼리를 최적화 하거나 캐시를 도입하는게 방법. 썸네일 생성 처럼 CPU 중심 작업도 마찬가지. 이미지 처리하는 과정에는 블로킹 IO가 없으니 가상 스레드나 논블로킹 입출력 도입해도 처리시간이 같다.
문제가 IO 관련이라면 그때는 구현 변경이 가능한지 따져본다. 예를들어 동시에 요청하는 클라 수가 늘어나면서 실행되는 스레드 수도 많아졌고, 그 결과 메모리 사용률이 98%까지 올라갔다 하자. 이게 지속되면 장애 발생할수도있다. 가상 스레드를 적용할 수 있다면 이를 사용하기만해도 메모리 사용률 줄일수있음. 만약 없다면 일단 메모리 늘리거나 서버 수평확장해서 문제를 완화할수밖에 없음.
다른 상황으로는
- 우선 순위에 밀려 성능 개선을 뒤로 둘때.
- 기술에 대한 익숙함. 예를 들어 웹소켓 서버의 동접이 늘어 성능 문제 발생했다치자. 이때 논블로킹 입출력쓰면 효과 볼수있지만, 개발자가 관련 기술 모르면 성능 개선이 어려움.
정리하자면…
- 문제가 있다
- 그 문제가 네트워크 IO 관련이다
- 구현 변경이 가능한 상황이다 라면 변경 시도 ㄱㄱ