힘겨웠던 성능 개선 프로젝트(아이디어)

  • 작년 옆팀으로 업무 지원을 위해 투입 된 적이 있다.
  • 주로 사용하는 언어가 아닌 다른 언어로 운영되는 시스템이였고, 정말로… 히스토리가 많은 시스템이였다.
  • 사업적 요소에 대한 기능 추가들을 진행하면서, 계속 음... 하면서 이상한 부분들이 있었다.
  • 역시나 개발이 되고나서 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 등을 통해 서비스 안정성을 확보했고 이후 다른 문제들이 복합적으로 터졌다.
  • 역시나 그 부분에 대해서 수습하기 위해 투입되었고, 어느정도 안정화를 하고 프로젝트를 종료했었다.
  • 자주 쓰던 모듈들을 이용하여 문제를 해결했던 과정을 나열해보았다.
  • 정답은 아니지만, 그 당시에 최선의 선택이였던 것 같아서 정리해보았다.

Related Posts