인프런 커뮤니티 질문&답변
작성한 질문수
수평적 확장을 통해 병목 지점 해소를 한 이유가 궁금합니다.
해결된 질문
작성
·
118
0
안녕하세요.
최근 성능 최적화와 관련되어 병목 지점을 명확히 하고싶어 해당 강의를 수강중인 한 학생입니다.
강의 내용 중, ec2 의 cpu의 사용량이 100% 찍어, 수평적 확장을 통해 병목 지점을 해소하려고 한 내용을 확인하였습니다.
현재 개발되어있는 spring boot 프로젝트에서 tomcat 서버의 pool 사이즈에 대한 설정과 hikari pool 에 대한 사이즈 설정이 default 로 들어가 있어서 문제가 발생할 수도 있을 것 같다라는 생각이 듭니다. (default 가 min : 10 으로 설정되어있어, 이를 처리하기 하기 위한 thread 생성을 하다 보니, 더 늘어났다고 생각)
물론, 해당 spring boot 의 서버의 자원을 모니터링 하기 위한 툴이 적용되어 있지 않아 판단이 어려운 부분이 있긴 할 것 같습니다. 만약, 스카우터 등을 사용해 모니터링 한 결과, cpu 사용량이 100퍼센트까지 치솟는 지점이, 신규 thread 가 막 늘어나고, 요청들이 waiting 되는걸 확인한다면, pool 사이즈 부터 건들여 보는게 맞을까요?
답변 2
1
안녕하세요 BaekGwa님! 재밌는 시도를 하고 계시군요:)
예전에 저도 hikari pool의 값을 변경하면서
조금 더 성능을 극대화할 수 있는 부분이 있지 않을까해서
부하 테스트를 기반으로 여러 가지 실험을 했던 적이 있습니다!
지금 해주신 질문은 다방면으로 고민을 해보면서 실력이 늘 경험을 많이 하실 수 있을 것 같아서
정답은 먼저 알려드리지 않아보도록 할게요ㅎㅎㅎ
말씀해주신 대로 thread가 늘어나고 있는 지를 어떻게 모니터링 할지 먼저 고민해보세요.
그리고 hikari pool이 어떤 의미를 가지고 있는 지, 어떤 특징을 가지고 있는 지 조사해보시고,
thread pool과의 차이점도 같이 찾아보시기 바랍니다.
그런 뒤에 thread가 포화되었을 때 어떻게 해야 성능 개선을 할 수 있을 지
고민해보셔도 좋을 것 같습니다!!
고민해보시고 또 중간에 깨달으신 내용이 생기거나
막히시는 내용이 생기시면 또 질문 남겨주세요~~
같이 또 고민해드릴게요ㅎㅎㅎ
또한, 만약 시스템에 대한 tps 가 정해져서 내려오고 가장 많이 부하가 걸리는 테스트 시나리오가 작성된다면, 역으로 서버 하드웨어 성능을 어느정도 대략적으로 계산해 볼 수도 있겠네요.
이론적인 부분은 아주 잘 정리하셨습니다!!
괜찮은 가설을 잘 세우신 상태이고
이제 부하 테스트를 기반으로 실제 세우신 가설이 맞는 지를
검증해보시면 좋을 것 같아요 😀
지금까지의 이론이 BeakGwa님만의 지식이 되려면
반드시 실제 테스트를 겸해봐야 하니
꼭 한 번 실제로 부하테스트를 해보면서
이론적인 내용이 정말 맞는 지도 같이 체크해보시기 바랍니다!
0
안녕하세요, 인프런 AI 인턴입니다. BeakGwa님.
강의 내용을 바탕으로 수평적 확장을 통한 병목 지점 해소에 대해 이해하고 계신 점, 그리고 현재 프로젝트의 설정에 대한 고민을 나누어 주셔서 감사합니다. 병목을 해소하는 방법에는 여러 가지가 있으며, 그중에 수평적 확장은 효율적인 방법 중 하나입니다.
병목 해소 전략:
수평적 확장의 이유:
- 수평적 확장은 단일 서버의 한계를 넘어서 여러 대의 서버로 부하를 분산하여 고성능을 유지할 수 있게 합니다. 특히 CPU 사용량이 극도로 높을 때는 서버 수를 늘려 부하를 줄일 수 있습니다.
- 수평적 확장은 단일 서버의 한계를 넘어서 여러 대의 서버로 부하를 분산하여 고성능을 유지할 수 있게 합니다. 특히 CPU 사용량이 극도로 높을 때는 서버 수를 늘려 부하를 줄일 수 있습니다.
톰캣 및 히카리 풀 설정:
- 톰캣 서버와 히카리CP(Hikari Connection Pool)는 일정한 스레드와 커넥션을 유지하여 성능을 최적화합니다. 그러나 기본 설정으로는 대규모 트래픽을 감당할 수 없는 경우가 많습니다.
- 기본 값이 min: 10으로 되어 있다면, 이를 환경에 맞게 조정하여 CPU 부하를 줄일 수 있습니다. 부하에 따라 적절한 수치를 설정해야 하며, 스레드가 과도하게 생성되어 병목 현상이 발생할 수 있습니다.
- 톰캣 서버와 히카리CP(Hikari Connection Pool)는 일정한 스레드와 커넥션을 유지하여 성능을 최적화합니다. 그러나 기본 설정으로는 대규모 트래픽을 감당할 수 없는 경우가 많습니다.
모니터링의 중요성:
- 스카우터와 같은 모니터링 툴을 활용하여 시스템의 상태를 지속적으로 체크하는 것이 중요합니다. 이를 통해 CPU 사용량, 스레드 수, 대기 중인 요청 등을 실시간으로 확인할 수 있습니다.
- CPU 사용량이 신규 스레드의 무분별한 증가로 인해 100%에 도달한다면, Tomcat과 HikariCP 풀의 크기를 실제 트래픽 패턴에 맞춰 조정해 보세요.
- 스카우터와 같은 모니터링 툴을 활용하여 시스템의 상태를 지속적으로 체크하는 것이 중요합니다. 이를 통해 CPU 사용량, 스레드 수, 대기 중인 요청 등을 실시간으로 확인할 수 있습니다.
관련된 토론 및 답변은 다음 링크를 참고하시면 더 많은 인사이트를 얻을 수 있습니다:
-
- 여기에서 서버의 수평적 확장이 어떻게 병목을 해결할 수 있는지에 대해 자세히 설명되고 있습니다.
- 여기에서 서버의 수평적 확장이 어떻게 병목을 해결할 수 있는지에 대해 자세히 설명되고 있습니다.
-
- 톰캣과 히카리CP의 설정 최적화에 대한 질문이 다루어진 내용입니다.
- 톰캣과 히카리CP의 설정 최적화에 대한 질문이 다루어진 내용입니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
아, 많이 놓치고 있던 부분이 있네요.
1. hikari pool 은 DB 커넥션의 Connection 개수를 의미. 또한 이 thread 는, 주로 IO 바운드 작업이 많다.
오히려 따라서 오히려 컨텍스트 스위칭 비용으로 인해 성능 저하가 될 가능성 높다.
예시로, 100개의 hikari cp 을 100개 설정해놓았고, 실제로 엄청 많은 데이터가 쏟아져, 100개 모두 connection 이 연결되었고, cpu 의 코어 갯수는 8개가 되어있다.
이경우, 잦은 컨텍스트 스위칭으로 스레드 개당 처리 속도가 상당히 느려져, 이후 요청들의 대기 시간이 증가하거나, 응답시간이 초과 혹은 spec out 될 수 있다.
따라서, 기본적으로 최대의 성능을 내기 위해서는, CP 는 cpu 코어 개수와 동일한 것이 베스트다
하지만, CP를 cpu 까지 낮춘다면, 문제가 발생할 수 있는 부분이, 더 많은 트래픽을 감당하지 못한다.
만약, application server 의 한 api가 2개의 connection 을 다루는 경우, 경우에 따라 데드락이 발생할 수 도 있을 것 이다.
이유는, 10개의 cp를 가지고 있고, 1Thread 당 2개의 connection 을 가지는 요청을 처리할 때, 만약 10Thread 가 동시에 실행되면, 10개 thread 모두 다음 커넥션을 얻기위해 무한정 대기하다, time-out 을 터트릴 것 이다.
사실상 제일 빠르게 데드락 걸려버리기!
따라서, 기본 개수는 cpu 코어 개수와 동일하게 지정하되, 우리 서버의 TPS 에 맞게, 또한 서버 한 요청당 connection 을 얼마나 소비하는지 확인해서 알맞게 알맞게 설정하는게 필요하다.
hikari 에서는,
pool size = Tn x (Cm - 1) + 1이라는 공식을 추천하고 있다.Tn은 동시에 접속하는 connection 의 수를 의미하니, 요런건 목표 tps 와 부하 테스트를 통해 알아보는게 좋을 듯 합니다.그리고 +1 덕분에, 데드락을 방지할 수 있게 되었다.
이론적으로 알고있던 부분을 최대한 녹여서 어제 새벽부터 하루종일 고민하고 자료 검색해봤었네요... 많은 케이스를 실습해보지는 않아 많이 부족하지만 검토 한번 부탁드려도 될까요? 같이 고민할 사람이 없네요 ㅠ