Java, Go 성능 테스트 비교 글을 보고
필자가 주로 사용하는 개발 언어는 자바입니다. 실제로 여러 프로젝트에서 성능 튜닝 관련 업무를 수행하였습니다. 최근 몆년 동안에는 일반적인 API 서버 개발 시에는 주로 Go 언어를 사용하고 있습니다. 이유는 간단함과 Docker 패키징하기 쉽고, 부족한 서버 예산으로 메모리, CPU 를 작게 사용하는 언어라고 봤기 때문입니다.
간단하고, 쉬운 Docker 패키징 등은 개발자의 경험으로 확인할 수 있지만 서버의 메모리나 CPU의 사용에 대해서는 "대충 이럴 것이다" 라는 감만 있었지 확실한 테스트를 수행해 보지는 않았습니다. 마침 저와 비슷한 경험을 가진 개발자가 자바와 Go 언어에 대해 서버의 CPU, Memory 사용과, 응답 시간 등 성능에 대한 테스트를 수행한 글이 있어 간단하게 소개해보고자 합니다.
전형적인 테스트 오류
첫번째 테스트를 수행한 결과는 다음 글에서 확인할 수 있습니다.
이 글은 단순히 테스트 결과만 있고 그 결과에 대한 분석은 없습니다.
원본: https://dzone.com/articles/java-vs-go-multiple-users-load-test-1
위 테스트 결과에서 보듯이 Go 언어가 에러율이 3배 정도 나오고, Response time도 좋지 않은 것을 볼 수 있습니다. 하지만 이 글에서는 왜 에러가 많이 발생했는지 등에 대해서는 분석하지 않고 있습니다. 이 글을 처음 보았을 때 왜 이런 형태의 글을 쓰고 결과만 배포했는지 이해가 되지 않았습니다. 가짜 뉴스 또는 기레기의 느낌이 있었습니다.
테스트 결과에 대한 구체적인 분석이 없는 글은 이렇게 공개적으로 배포하지 않아야 한다는 것이 개인적인 생각입니다. 이런 글로 인해 부정확한 정보를 제공함으로써 독자자들이 오해하게 만들기 때문입니다.
테스트 오류에 대한 분석 및 재 테스트
다행히도 위의 테스트 들에 대해 테스트 수행 시 있었던 문제를 설명하고 다시 테스트한 글[1]이 올라 왔습니다.
이 글에서 첫번째 수행한 테스트의 문제점을 다음과 같이 설명하고 있습니다.
- PostgreSQL의 기본 Connection 갯수가 100인데 이 값을 그대로 사용하였다.
- Go의 sql.DB 객체는 실제 Connection이 아닌 Connection Pool이라고 볼 수 있는데 이 객체를 매번 요청마다 만들어서 사용하였다.
- sql.DB의 Connection은 Close 하지 않아도 되는데 Close 처리를 하였으며, 이 Close 처리 로직도 문제가 있어 처리 중 문제가 발생한 상황(Conneciton 재한 100개로 인해)에서 제대로 Close 가 되지 않는다.
- 많은 동시 접속을 테스트하기 위해서는 AWS t2 서버의 성능이 너무 낮다.
- 테스트 시나리오 자체에 문제가 있어 테스트 시나리오도 수정하였다.
2, 3번은 Go를 처음 사용할 때 많이 저지르는 실수라고 할 수 있습니다. 지금은 어떨지 모르겠는데 2년전에 확인했을 때에는 Go의 Connection Pool 자체도 자바의 Connection Pool 처럼 우아하지는 않은 것으로 알고 있습니다.
이런 테스트 상의 오류를 제거하고 테스트를 수행한 결과를 리포팅하고 있는데 여기서는 첫번째 테스트 수행해서 보여줬던 Response Time과 Error에 대한 결과는 정리를 하지 않았습니다. 테스트 수행 결과 콘솔에 나타난 내용을 보면 Go 언어에서 에러가 많이 발생하는 것을 볼 수 있습니다. 이 부분에 대한 분석은 없습니다.
그리고 아래 부분에 두가지 언어의 CPU, Memory 사용에 대한 결과를 정리하고 있는데 문서 상으로 보면 Go 언어가 월등히 효율적으로 사용하고 있다는 것을 볼 수 있습니다. 과연 이 실험의 결과가 사실일까요? 사실일수도 있고 아닐 수도 있습니다. 이유는 에러 부분에 대한 분석이 없기 때문입니다. 정상적인 상황이라면 4K 동접 수행 시에도 Go언어 사용에서도 에러가 많이 밝생하지 않아야 합니다. 에러가 많이 발생할 경우 당연히 CPU, Memory 등은 작게 사용할 수 있습니다.
에러 발생이 DB 연결 과정에서 발생했다면 DB fetch 이후에 처리해야 하는 메모리 적재, 타입 변환 등이 필요 없게 되고 이렇게 되면 CPU, Memory 사용도 필요 없게 되기 때문입니다. 즉, 이번 실험의 결과로 Go언어가 자바에 비해 CPU, Memory 사용 등에 있어 효과적이라고 단정하기는 어렵다는 것입니다[2].
다른 사람이 수행한 테스트 결과를 참고할 때
특정 플랫폼을 선택하는데 있어 성능 테스트는 아주 중요한 선택 요소 중의 하나 입니다. 이를 위해 직접 테스트를 수행할 수도 있고, 다른 사람이 수행한 테스트 결과를 참고할 수도 있습니다. 가장 좋은 것은 직접 테스트를 수행하는 것이지만 테스트 수행할 수 있는 시간적 여유가 없거나, 위 테스트 수행에서와 같이 새로운 플랫폼에 대한 완전한 이해가 없어 테스트 오류를 발생할 수도 있습니다. 이런 경우 다른 사람이 수행한 테스트 결과를 참고할 수 있는데 이런 테스트 결과 글만 참고한다면 난감할 수 있습니다.
필자는 하둡 플랫폼을 다루면서 많은 성능 테스트 관련 문서를 보았습니다. 어떤 문서에는 수백배 성능 향상이 되었다는 문서도 있었습니다. 이런 류의 오해를 주는 테스트 결과 문서들의 특징은 테스트 결과에 대한 분석을 제대로 하지 않는다는 것입니다. 왜 이런 결과가 나왔는지에 대한 분석 없이 실험 환경과 결과만 보여주고 있습니다.
따라서 다른 사람이 수행한 테스트 결과 문서를 참고할 때에는 좀 더 신중하게 봐야 할 것입니다. 가장 중요하게 봐야 할 부분은 데스트 결과에 대한 분석입니다. 왜 이런 결과가 나왔고, 테스트 중에 발생한 오류는 왜 나왔는지 등에 대한 내용입니다. 이런 분석이 없이 단순히 결과만 보여주고 있는 테스트 결과는 테스트 자체에 대한 신뢰를 떨어뜨리게 되고, 독자들에게 오해를 주게 됩니다.
가장 좋은 것은 직접 테스트를 수행하는 것인데 테스트를 수행할 때에도 테스트 수행 시 발생한 오류에 대한 부분을 반드시 고려해야 합니다. 이런 고려 없이 테스트를 수행하고 그 결과를 받아 들이게 되면 테스트를 수행하지 않은 것보다 더 좋지 않은 결과를 얻을 수 있습니다. 그리고 테스트에 대한 분석도 해야 하며 필요한 경우 테스트 결과를 외부에 공유하고 의견을 들어보는 과정을 거치는 것도 좋다고 생각합니다.
결론
두 플랫폼간 성능 테스트는 어느 플랫폼을 선택하느냐에 있어 아주 중요한 부분이지만 자칫 테스트를 잘못하거나 분석을 잘못하면 잘못된 선택을 할 수 있습니다. 그리고 공개되어 있는 테스트 결과 문서라고 해서 모두 신뢰할 수 있는 것은 아니고 테스트 상에 문제가 없는지, 결과에 대한 분석은 있는지, 그 분석이 타당하고 오류는 없는지 등에 대해 충분히 검토를 해야 합니다.
주석
[1]: 첫번째 글이 2018년에 게시되었고 두번째 글이 2020년에 게시되었으며, 두 글의 저자도 다른데 왜 이런 글이 다시 포스팅 되었는지도 조금은 의아합니다.
[2]: 3년 정도 Go 기반의 API 서버를 운영해본 필자의 경험에 의하면 CPU는 모르겠지만 메모리는 현저히 작게 쓰는 것 같았습니다.