openservey

opensurvey (IDINCU) 성능 개선기 – (상세 내용)

오픈서베이의 성능 개선 이야기 with WhaTap !

 

 

blog_signup_banner_b (3)

이번 글을 시작으로 와탭 모니터링을 이용한 성능 개선 사례들을 종종 공유하고자 합니다. 첫 번째 주인공은 IDINCU입니다.

 

IDINCU(아이디인큐)의 제품 소개

product_lineup_idincu_img

IDINCU는 국내 모바일 설문조사에서 선두를 달리고 있는 스타트업으로, 오픈서베이와 오베이라는 두 가지 제품을 제공합니다.

오픈서베이는 설문을 만들고, 설문의 타겟을 설정하고, 설문 결과를 보여줄 수 있는 플랫폼이며, 오베이는 패널들이 설문에 응답할 수 있는 플랫폼입니다.

글로벌하게 두 가지 서비스가 함께 운영되다 보니 사업적인 모델뿐만 아니라 내부 시스템 도 복잡해졌습니다. 

 

도입 계기

여느 스타트업처럼 빠르게 시장에 침투하기 위해 SSA(Single Service Architecture)로 출발을 하였습니다. 글로벌 서비스로 성장하면서 MSA(Micro Service Architecture)로 전환이 필요하게 되었고, 그 여파로 시스템은 더 복잡해졌습니다. 이 과정에서 원래 사용하던 legacy system을 한 번에 걷어내는 것은 쉽지 않았기 때문에 legacy와 새로운 시스템이 공존하게 되었습니다.

결국 병목 지점을 더 찾기가 힘들어졌고, 문제의 원인을 찾을 만한 여유가 없어 서버를 재시작하고, Scale Out 즉 용량을 늘리는 문제로 해결을 했습니다. 하지만 메모리를 비롯한 서버 비용에 대한 부담이 증가하였습니다.

 

문제를 해결하기 위해 다양한 방법을 시도하였으나…

VisualVM, Observium, Graylog, ELK stack 등 다양한 시스템을 도입해 문제들을 개선하긴 했지만, 이것조차 한계에 부딪혔습니다.

기존의 모니터링 시스템들은 대부분 실시간 기반이기 때문에, 문제가 생겼을 때 해당 시스템을 켜서 보고 있어야 합니다. 그러나 실제 상황에서는 시스템을 보고 있을 시간도 없고 확실성도 떨어졌습니다.  구축하는데 개발자들의 자원도 많이 들어갔고요. 

 

성능 개선기 1 – Jedis의 병목을 발견하다.

이에 비해 와탭은 큐브 분석을 통해서 문제 상황의 재현이 가능하도록 다양한 관점의 로그를 입체적으로 보여 주었습니다.

5분 단위로 사용자, 트랜잭션 현황, 자원 사용량, 병목 지점 및 트랜잭션 유형 등을 가지고 있어서 바둑을 복기 하듯이 과거 데이터를 다양한 관점으로 볼 수 있다는 장점이 크게 와 닿았습니다. 

실제 트랜잭션의 덤프를 분석하는 액티브 분석을 통해서, Jedis 라이브러리의 병목 지점을 찾았습니다. 액티브 분석을 통해서 개선한 문제 중 하나가 Redis connection pool입니다. IDINCU는 고객들의 세션 관리를 위해 Redis를 사용하고 있었는데, Jedis라는 라이브러리의 기본 connection pool 값이 8로 설정되어 있었습니다. 이러한 사실을 와탭을 통해 발견하고, connection pool 값을 48로 변경한 후 문제는 말끔하게 해결되었습니다.

 

성능 개선기 2 – DB의 병목을 히트맵을 통해 발견하다.

문제가 발생한 다른 부분은 DB connection pool이었습니다. 응답이 늘어나면 connection pool이 차며 HitMap의 트랜잭션들이 세로로 줄을 서는 현상이 발생했습니다. 이것 역시 connection pool을 적절하게 조정하며 많은 부분이 해결되었습니다.

또한 위의 Transaction List에서는 slow query를 확인할 수 있었습니다. 기존에도 slow query를 해결하려는 노력은 많이 해왔지만, 와탭을 사용하며 slow query를 확인하고 해결하는 과정이 더 쉬워졌습니다.

 

성능 개선기 3 – 메모리 누수 문제 잡기

세 번째 문제는 memory leak이었습니다.

서비스에 설문조사 결과를 export하는 로직이 있어서 Apache POI같은 API를 사용하게 되었는데, 이 부분에서 memory leak이 발생했습니다.

위 그래프에서 붉은색 선은 개선 전의 메모리 사용량인데, 작업이 끝나도 메모리 사용량이 줄지 않습니다. 이 문제를 해결하기 위해 Apache POI 같은 라이브러리를 최신 버전으로 업데이트하고, close 등의 구문도 추가를 하는 등의 노력 후 개선된 부분이 아래 쪽의 그래프입니다.

 

성능 개선기 4 – 사용자가 늘어나니!! 다른 곳에서 문제가…

지금까지 서버의 문제를 열심히 해결했습니다. 그러다 보니 서버의 성능이 좋아지고 트래픽이 늘어나, 다른 곳에서 문제가 터지기 시작합니다.

바로 IDC입니다. IDINCU는 KT의 IDC에 서버를 구축해 사용하고 있는데, 앞에서 이야기한 부분들을 모두 고쳤음에도 불구하고 응답이 밀리는 현상이 발생했습니다. 알고 보니 응답이 몰릴 때 packet loss가 발생하는 문제가 있었습니다.

이 문제를 해결하기 위해, IDC에서 사용하던 대역폭을 50Mbps에서 100Mbps으로 확장했습니다. 확장하고 나서 개선된 부분이 위 그래프의 2번입니다.

(3번은 DB 백업 시 packet loss가 덜 발생하도록 개선한 부분입니다.)

 

성능 개선기 5 – 서버의 설정 문제

다섯 번째로 해결한 문제는 Tomcat입니다. 기존에 사용하던 서버에서 새로운 서버로 이전을 하며 새로운 Tomcat을 만들었으나 설정 하는 것을 잊어버려 계속해서 문제가 생겼습니다. 와탭의 JVMP에서 컴포넌트 버전 및 다양한 설정 정보를 한눈에 볼 수 있었습니다. 

설정 정보에서 문제점을 발견한 후, Tomcat의 thread pool을 늘리고, BIO로 설정되어있던 기본값을 NIO로 변경하고, Spring boot를 사용하고 있는 서브 시스템들의 Spring boot 버전을 올리는 등의 작업을 통해 서비스의 성능을 더욱 개선할 수 있었습니다.

 

결론 – 핵심은 성능 개선보다, 성능 개선 비용을 얼마나 줄이느냐다!

결국 중요한 것은 튜닝을 해서 성능을 얼마나 개선시켰다는 것이 아닙니다.

물론 성능 또한 많이 개선됐습니다. 원래 tps가 40만 되어도 패널들의 응답이 밀리던 서비스가, 현재는 tps가 80이 되어도 서비스가 정상적으로 운영됩니다.

와탭이 없어도, 개발자들이 마음 먹고 달려든다면 이렇게 성능을 개선할 수 있습니다. 기존에도 많은 툴들이 있었고, 노력을 한다면 튜닝 포인트들을 찾지 못 하는 것은 아니었습니다.

그러나 대부분의 기업은 성능 개선에 집중할 여력이 없습니다. 특히 스타트업의 경우에는 더욱 그렇습니다. 와탭 APM은 단순히 어플리케이션을 모니터링하는 서비스가 아니라, 적은 비용으로도 쉽고 부담없이 성능 개선을 할 수 있도록 돕는 툴입니다.

와탭을 사용한다면 많은 시간을 들여서 시스템을 학습할 필요 없이, 짧은 시간만으로도 개선할 지점을 간편하게 알아낼 수 있습니다.

blog_signup_banner_b (3)