본문 바로가기

분류 전체보기

(14)
 지난 7개월 간의 멘토링을 회고하며 (feat. F-Lab) 0. 들어가며 "🎶... 🎶..." 평범한 어느 날 오후, 그 어느때와 같은 일상이 진행되던 와중, 평소와 다름 없이 같은 벨소리가 울려퍼지기 시작했다. 별 생각 없이 평소처럼 전화를 받았는데, 수화기 넘어로 내가 맞는지 묻는 소리가 들려왔다. "안녕하세요. 000님 전화 맞나요?" "네" "축하드립니다. 최종 면접에 통과하셨습니다. ..." "... 네?!" 그 동안 가장 기다렸던 말이었기에, 놀라움에 몇 초간 그 자리에 멍하니 서 있을 수밖에 없었다. 믿기지 않았다. 얼마 전까지만 해도 나는, 되고 싶은 것은 있지만 무엇을 해야 할지 모르는 상황이었다. 불안했다. 그동안 개발과 관련된 접점이 전무했으니 더욱 그랬다. 인터넷에서 잘 정리되어 있다는 로드맵을 보았으나, 어마어마한 그 스케일에 압도되고 말..
배포 서버를 대상으로 한 성능테스트 및 성능개선 (5) - 공유코어가 원인 불명 성능저하의 문제일 수 있습니다. (feat. DB 서버 문제 해결) 안녕하세요. 지난 포스팅에서는 성능테스트를 계속 모니터링하면서 새로운 문제점을 찾고, 문제의 원인이 될만한 부분을 하나씩 확인하고 수정해보면서 총 8차시의 재 테스트를 걸쳐 문제를 해결해나가는 과정을 보았습니다. 다행히 처음 발견된 문제는 개선할 수 있었으나, 다른 문제가 또 나타나게 되었는데요. 바로 테스트 진행 시 일정시간만 지나면 다음과 같이 TPS가 급감해버리는 부분이었습니다. 해당 글을 작성한 후 몇번이고 테스트를 반복해보았지만 약 3분이 경과되는 시점에서 항상 똑같은 문제가 발생했습니다. 이번 포스팅은 위의 문제에 대한 해결 과정을 요약해서 다뤄보고자 합니다. 문제 해결과정 1) pinpoint & JvisualVM/JvvisualVM 살펴보기 가장 먼저 좀 더 나은 지표 확인을 위해 성능테스..
배포 서버를 대상으로 한 성능테스트 및 성능개선 (4) - 문제의 진짜 원인을 찾아서 (feat. 슬로우 쿼리 & BCrypt) 안녕하세요. 저번시간에는 문제의 원인일지 모르는 DB 커넥션과 커넥션 풀에 대해 이해하고, 커넥션 풀 크기를 조정한 뒤 2차로 다시 테스트를 수행해 보았습니다. 10개 였던 커넥션 풀 크기가 20개로 늘자 맨 처음 문제였던 getConnection 메소드 수행 시 대기 시간은 사라졌습니다. 다만, 커넥션 풀이 문제를 일으키는 진짜 원인이 아니었기에 또 다른 곳에서 문제가 발생하는 것을 확인할 수 있었습니다. 오늘은 문제의 원인이 될 만한 다른 부분을 분석해보고, 문제점이 발견되면 이를 개선하고 다시 성능 측정을 해봄으로써 실질적인 개선이 이루어졌는지 확인해보도록 하겠습니다. 문제가 발생하고 있는 지점을 좀 더 자세히 살펴봅시다. 저번 포스팅에 활용했던 사진을 다시 가져와 보았습니다. 여기서 확인했던 문제..
프로젝트를 위한 빌드 도구 선택하기 (feat. Ant vs Maven vs Gradle) 스프링과 여타 다른 웹 프로그래밍 학습을 하면서 읽었던 책들이나, 들었던 온라인 강의들은 모두 메이븐(Maven)을 사용했습니다. 때문에 메이븐을 조금씩 익히게 되었는데, 이전에는 필요한 라이브러리를 하나씩 손수 다운로드 받아왔던 터라, 비록 XML로 작성된 구조는 복잡했지만 자동으로 의존성 관리를 해주는 부분을 보며 꽤나 편리하다고 생각했습니다. 또한, 당시에는 다른 빌드 도구의 존재를 크게 지각하지 못했기에 프로젝트를 생성할 때 자연스럽게 익숙한 메이븐을 선택하게 되었습니다. 기존에 진행하던 Hello-World 프로젝트의 경우, 성능테스트 및 개선 작업까지 어느 정도 완료되어 조금 더 심화된 내용들을 학습하고 새롭게 익힌 기술 스택들도 적용해보고자 새로운 프로젝트를 구상하고 있는데요. 프로젝트를 생..
배포 서버를 대상으로 한 성능테스트 및 성능개선 (3) - DB Connection 안녕하세요. 저번 시간에는 nGrinder를 활용해 직접 성능테스트를 실행하고, 이를 pinpoint 등의 도구를 사용해서 모니터링을 해보는 시간을 가졌습니다. 그리고 원인은 확실하지 않지만 문제가 있는 부분도 찾아낼 수 있었는데요. 오늘은 해당 문제 해결의 실마리가 될 수도 있는 DB Connection에 대해 좀 더 살펴보고, 해당 내용을 실제로 적용한 뒤 테스트를 다시 진행해봄으로써 실제로 커넥션이 문제를 유발하고 있었는지 살펴보도록 하겠습니다. 먼저, 본론에 들어가기에 앞서 커넥션이 무엇인지부터 시작하겠습니다. DB connection이란? 커넥션은 이름이 의미하는 바와 같이 연결과 관련이 있습니다. 한 개체가 다른 서버 상에 존재하는 개체와 통신하기 위해서는 이를 뒷받침 할 수단이 필요한데, 이..
배포서버 성능테스트 및 성능개선 (2) - 직접 성능테스트를 진행해보고 경과를 모니터링 해봅시다. 안녕하세요. 저번시간에는 성능 테스트의 필요성을 알아보고 성능을 측정하는데 있어 대표적인 기준이 될만한 지표들에 대해서 살펴본 뒤 성능 테스트 시 사용할 도구들을 직접 설치해봄으로써 배포한 서버를 대상으로 한 성능 테스트를 진행하기 전 사전 작업을 완료하였습니다. 이제 테스트를 구동할 준비를 모두 마쳤으니 이번 시간에는 nGrinder를 사용해 타겟 서버에 직접 부하를 가해보면서 테스트가 진행되는 동안 pinpoint와 Jvisualvm 등의 도구를 통해 해당 서버가 부하 속에서도 제대로 동작하고 있는지 모니터링 해보는 시간을 갖도록 하겠습니다. 시작하기에 앞서 성능 테스트를 진행한 서버의 사양과 구조는 다음과 같습니다. 서버 사양 애플리케이션 서버 - CPU: 2코어, RAM: 4GB DB 서버 - C..
배포서버 성능테스트 및 성능개선 (1) - 성능테스트의 필요성을 살펴보고, 필요한 환경을 구성해 봅시다. 안녕하세요. 프로젝트를 진행하면서 기존에 구상했던 기능들을 구현할 때 대용량 트래픽 환경을 가정하고 최대한 신중히 코드를 작성해 왔습니다. CI와 CD를 구현해서 배포를 하고 나니 그간 공들여 진행한 프로젝트를 직접 public한 환경에서도 사용해볼 수 있게 되었는데요. 그러면서 문득 실제로도 많은 트래픽을 수용할 수 있는지와, 그러한 환경 속에서도 얼마나 빠르고 안정적인 속도로 서비스를 제공할 수 있는지가 궁금해지게 되었습니다. 때문에 성능 테스트를 진행하게 되었으며, 이번 포스팅은 이러한 과정에서 제가 마주했던 문제점과 그러한 문제들을 해결해가는 과정을 공유해보고자 합니다. 성능테스트의 필요성 성능 테스트란 그 이름이 의미하는 것처럼 해당 서비스의 성능적인 측면을 직접 테스트해보는 것을 의미합니다. ..
대용량 트래픽 속에서도 무거운 DB 조회 연산을 효율적으로 처리하는 방법은 무엇이 있을까요? (2) INTRO 안녕하세요. 오늘도 다시 찾아온 Soo입니다. 지난시간에는 DB에서 무거운 연산을 좀 더 효율적으로 처리하기 위해서 프로젝트를 진행하면서 지금까지 MySQL에 대해 학습한 내용을 바탕으로 EXPLAIN을 활용해 작성한 쿼리의 실행계획을 조회하고, 비효율적인 결과가 나타나는 부분을 찾아서 쿼리를 튜닝하는 시간을 가졌습니다. 그렇지만 여전히 문제가 되는 부분이 존재하는데 바로 조인 연산이 여전히 많이 필요하다는 점입니다. 이번 글에서는 이러한 문제점을 어떻게 해결해보았는지에 대해 작성해보고자 합니다. 조인연산을 어떻게 줄일 수 있을까? 지난 시간에 튜닝을 끝낸 쿼리를 다시 살펴보겠습니다. 각 이름들을 매핑시키기 위해서 총 다섯 번의 조인이 사용되었습니다. 조인은 그 특성상 당연히 단일 테이블을 가..