본문
비용을 약 2만배 이상 줄인 테스트웍스의 APM 활용기
관련링크
모든 개발-운영 조직은 서비스 개발과 운영을 함께 하므로 서비스가 조금이라도 느려지는 일을 원치 않을 것입니다. 특히, 서비스 개발과 비즈니스 개발을 함께하고 인력이 부족한 스타트업은 사람과 시간이 부족한 조직이라 그만큼 해야 하는 일도 두 배, 세 배 그 이상일 것입니다.
기술 기반의 성장과 함께 소셜 미션을 수행하는 데이터 전문 사회적 기업 테스트웍스는 ‘나를 알고 적을 알면 위태롭지 않다’라는 생각으로 개발 단계에서 발생한 문제를 모니터링과 함께 해결했는데요. 테스트웍스 개발팀이 가진 챌린지를 어떻게 해결했는지, 비용을 약 2만 배 이상 줄일 수 있었던 방법을 확인해 보시기 바랍니다.
테스트웍스와 테스트웍스에서 운영 중인 서비스에 대해 소개해 주세요.
테스트웍스는 기술 기반의 성장과 함께 사회에 기여할 수 있는 업무를 수행하고 있는 업계 유일의 인공지능 데이터 및 소프트웨어 테스트 전문 스타트업입니다. 테스트웍스는 4차 산업의 핵심이 되는 인공지능 데이터 셋 구축과 자동화 플랫폼 기술력에 다양한 계층의 강점을 살려 포용적 고용의 기회를 제공하고 있습니다.
현재 테스트웍스에서는 다섯 개 서비스를 개발 및 운영하고 있습니다. 크라우드-소싱 방식의 인공지능 학습용 데이터 수집 가공 전문 플랫폼 aiworks, 데이터를 효율적으로 자동화-가공-관리를 위한 블랙올리브, 엣지 컴퓨팅 기술 기반으로 더 빠르게 필요한 이미지와 영상 데이터를 수집할 수 있는 Edge AI, 테스트웍스만의 기술로 데이터 품질 검증에 최적화된 서비스 ADQ, 원격으로 반도체 개발에 필요한 CI/CT/CD 체계를 구축할 수 있는 Tedworks를 개발 및 제공하고 있습니다.
테스트웍스의 개발 환경은 어떻게 구성되었나요?
운영환경과 유사한 환경을 클라우드에 탑재하였고 형상 관리와 동료 검토를 통한 브랜치 전략 기반의 배포 환경과 통상 2주단위의 스프린트 개발 목표의 일정과 품질관리를 하였고 모든 단계별 진행현황을 실시간으로 소통하고 이슈 발생과 해소를 위한 협업 환경에 중점을 두었습니다. 개발 환경 또한 APM을 적용하여 단위 테스트중 먼저 식별 가능한 위험 요소를 제거하기 위해 노력하였습니다.
모니터링 도입 전, 어떤 과제가 있었는지 소개해 주세요.
첫째, 서비스 개발에 더 집중해야 하는 시점이라 서비스 아키텍처까지 고민하기 어려운 구조입니다. 또한, SQL을 쓴다 하더라도 서비스를 빨리 개발하고 배포해야 하기 때문에 성능까지 고려하기 어렵다는 것이었습니다.
둘째, 성능 개선을 하기 위해 모니터링 서비스를 이용해야 한다는 자체에 대한 인식 부족이 부족했습니다. ‘나를 알고 적을 알면 위태롭지 않다’는 말이 있습니다. 모든 서비스는 주말에도 서비스는 계속되고 있는데, 장애가 발생하면 장애 지점을 빠르게 찾아 해결해야 하는 것입니다. 모니터링이 이러한 역할을 하는데, 만약 모니터링 자체를 모른다면 장애 지점을 찾는 데 시간 낭비하다가 사용자가 이탈해 버리는 일이 발생하는데 이러한 문제를 직면했습니다.
마지막으로, 모니터링으로 문제를 해결하기 전에 원활한 서비스를 위한 체크포인트를 점검했습니다. 비용과 증설로 비교적 빠르게 해결할 수 있는 서버, 네트워크와 사용자의 PC, 사용자의 사용 수준 등 개발에서는 할 수 없는 부분을 제외했습니다. 모니터링에서 서비스의 어느 지점에 문제가 있는지 식별할 수 있는 영역으로 서비스 아키텍처, 서비스 개발 언어 활용, 데이터베이스 SQL 활용, 애플리케이션이었습니다.
모니터링 도입 후 테스트웍스의 문제를 해결한 사례를 소개해 주세요.
<접속 시간 단축>
접속하는데 3초 이상이 걸린다면 개선 대상이라 생각하고, 와탭 애플리케이션 모니터링에서 제공하는 히트맵 대시보드를 확인했습니다. 3초라고 지정한 이유는 사용자가 이탈을 결심하는데 통상 3초 이상으로 기준을 잡았습니다. 그 결과, 3초부터 80초까지 대다수가 존재한 것을 확인할 수 있었고 이 정도로는 실제 서비스가 어려운 상태라 판단했습니다.
다음으로 서비스 접속을 저해하는 요소를 알아보기 위해 TX 프로파일 차트를 확인했습니다. 정상적인 서비스에서 서버 부하를 유도하는 내용 식별할 수 있었으며, 50초 이상이던 Front Read I/O와 Slow SQL가 문제였습니다.
식별한 다음에 SQL을 찾아보니 쓰지 않는 7백만 건의 SQL을 조회해서 서버가 죽는 현상이 발생한 것이었습니다. 이를 개선하기 위해 SQL 실행 시 정확히 필요한 모집합으로 범위를 제한했습니다. 변경 전 7백만 건의 SQL을 단 280건으로 줄었습니다. 이는 1/25,000 수준입니다.
이러한 요인들이 서비스 로드가 느려지는 것을 넘어 JVM의 가용 메모리를 과다하게 사용하여 서버가 작동되지 않는 이슈까지 함께 발생했습니다. 모니터링으로 발생한 문제를 해결함으로써 SQL 로드 시간이 기존에는 10초부터 80초까지 걸렸던 시간이 150ms로 줄었습니다. 50초 이상이던 Front Read I/O를 서버 자원을 사용하지 않도록 구글의 CDN I/O를 이용하도록 변경해 서버 부하를 원천적으로 제거했습니다.
<서비스 지연 패턴>
3초 이내로 반응하는 정상적인 서비스라면 히트맵은 아래로 깔리는 패턴을 보여야 합니다. 하지만 어느순간부터 가로, 세로 라인 등의 비정상적인 패턴이 보이기 시작했습니다. 이러한 패턴이 왜 갑자기 생겼는지 히트맵을 보고, 3초 이상 응답하는 트랜잭션은 서비스 불능이라 처리하고 해당 트랜잭션을 조치했습니다.
<서비스 불능 개선>
서비스 불능을 개선한 케이스입니다. 서비스 불능은 ‘서비스가 되는 것도, 안되는 것도 아닌’ 상태를 의미합니다. 스케일이 80초까지 되어있고, 최대 300초까지 로드되는 상황이었습니다. 사용자 입장에서는 서비스에 아예 접근이 안 되는 상태였습니다. 모니터링을 통해 다섯 단계를 나눠 문제를 해결했습니다.
- 먼저 어떤 요인이 우리 시스템에 영향을 미치는지 1, 2순위 요인부터 제거해보자는 우선순위를 정했습니다.
- 필요한 데이터만 필요시에 조회해야 하는데 이 시스템은 사용하지 않는 데이터로 인한 시스템 불능을 나타내는 현상을 발견했습니다. 필요하지 않은 데이터까지 조회되는 부분을 개선했습니다.
<소스코드 개선>
소스코드에서 불필요한 SQL을 제거했습니다. 또한, 전체 조회를 방지하는 where 절 밑에 true를 넣는 등의 보안에 치명적인 SQL을 제거했습니다. 아래 결과처럼 인스턴스 응답 시간, SQL, 트랜잭션 SQL 응답 시간 등 개선 전과 비교했을 때 각 영역 별 차트를 봐도 확연히 차이가 나는 것을 확인할 수 있습니다.
이렇게 모니터링을 통해 동시 접속자 수가 5명임에도 시스템이 불능 상태였다면, 지금의 경우 동시 접속자 수가 140배 이상 늘어나고 전 세계에서 접속함에도 트랜잭션의 99.9%가 3초 내로 정상 응답하는 것을 와탭 히트맵을 통해 확인할 수 있었습니다.
와탭 모니터링을 한 문장으로 어떻게 표현할 수 있을까요?
어제보다 나은 오늘, 오늘보다 나은 내일을 만든다고 생각합니다. 특히 스타트업이 위태롭지 않기 위해서는 모니터링은 선택이 아닌 필수라고 판단됩니다.
개인적으로 정보 시스템을 한 번에 좋게 만드는 것은 어려운 일인 것 같습니다. 특히 스타트업에서는 사업 및 기능 개발도 해야 하고, 서비스 운영도 함께하고 있어 아키텍처 개선까지 시작하면 한 번에 시스템을 개선하는 일은 더 어려운 것 같습니다.
하지만 모니터링을 사용하지 않았다면 정보 시스템을 개선하는 일은 이보다 더 오랜 시간이 걸렸을 것으로 생각하며, 앞으로도 서비스 기능을 개발하고 비즈니스 성장을 위해 지금처럼 모니터링을 십분 활용할 예정입니다.