힘겨웠던 성능 개선 프로젝트(아이디어)
- 작년 옆팀으로 업무 지원을 위해 투입 된 적이 있다.
- 주로 사용하는 언어가 아닌 다른 언어로 운영되는 시스템이였고, 정말로… 히스토리가 많은 시스템이였다.
- 사업적 요소에 대한 기능 추가들을 진행하면서, 계속
음...하면서 이상한 부분들이 있었다. - 역시나 개발이 되고나서 api 성능테스트를 진행하는데, 생각보다 성능이 나오지 않았다.
- 어디가 느린지 등을 보려고 했는데
apm이 없었다.- pinpoint 가 지원하지 않았고, 다른 지원하는 시스템들은 돈을 지불해야 했다.
-
일단 눈으로 수정 가능한 부분들을 몇가지 수정한 다음 프로덕트에 배포 했다.
- 그리고… 그리고… 역시나 예상한 것처럼 서버가 아프다는 신호를 보내기 시작했다.
- 아래는 이런 빈약한 상황에서 어떻게 성능 개선 작업을 진행 했었는지, 정리해 보았다.
아픈 얘들을 뽑아보자
- nginx 를 사용 중이였고, access log 를 따로 수집 중이였다.
- 특정
URI중 응답속도가 느리고, 호출수가 많은 것들부터 목록으로 뽑았다. - 상위 100개를 가지고 세부 분석을 하기로 했다.
- 최대한 왕건이를 뽑아서 수정해야 효과가 클 것이라고 판단했다.
어디가 아픈지 확인해보자
apm을 도입할 수 없었다.- zipkin 을 사용하여 확인해보자는 의견을 냈고, in memory 가 아닌 elasticsearch 로 변경하여 데이터를 쌓기로 했다.
- open tracing 포멧에 맞춰서 context 들에 정보들을 담아서 rest api 로 데이터를 쌓았다.
- https://zipkin.io/pages/data_model.html
아프게 해보자
- ngrinder 를 사용하여 부하테스트를 했고, 이전에 못본 call stack 들을 볼 수 있었다.
아픈곳을 보자
- 불필요하게 db 를 호출하는 부분 발견, in 절이나 쿼리 튜닝을 하여 호출 수를 줄였다.
- for loop 으로 단건으로 select 해오던 녀석들을 찾아서 수정 등…
- slow query 가 발생하는 곳들은 index 추가 등을 작업했다.
다른 개선안 제시…
- 아픈 곳들을 점검하고 치료를 했지만, 그럼에도 호출 수들이 많은 부분이 있었다.
- api gateway 를 두고 앞단에서 cache 할 수 있는 부분들을 골라서 추가하면 좋을 것 같다고 제안했지만, 대부분의 api 들이 개인화 데이터들이 포함되어 있어서 불가능해보였다.
- 나중에 된다면 개인화 영역과 공통 영역을 분리하여 api 를 개발하고, 공통영역은 cache 하는 형태로 변경하면 좋겠다는 피드백 받음.
결과…
- 조금은 나아졌지만 크게 효과는 없었다. 일단 scale up 과 scale out 등을 통해 서비스 안정성을 확보했고 이후 다른 문제들이 복합적으로 터졌다.
- 역시나 그 부분에 대해서 수습하기 위해 투입되었고, 어느정도 안정화를 하고 프로젝트를 종료했었다.
- 자주 쓰던 모듈들을 이용하여 문제를 해결했던 과정을 나열해보았다.
- 정답은 아니지만, 그 당시에 최선의 선택이였던 것 같아서 정리해보았다.