Python으로 Wanted 서비스의 헬스 체크하기
안녕하세요 원티드랩 QA팀 김명관입니다.
저희 팀에서는 품질 업무를 위한 다양한 스크립트를 개발하여 활용하고 있습니다. 그 중에는 Wanted를 비롯한 주요 서비스들의 활성 상태를 체크하는 스크립트도 있는데요. 이번 글에서는 Python을 이용하여 Wanted 주요 서비스의 안정성을 체크하는 스크립트를 만들게 된 배경과 운영 방식에 대해 공유 드리려고 합니다.
헬스 체크 스크립트 작성 배경
원티드랩에서는 데이터독을 이용해 서비스와 서버의 상태를 실시간 모니터링 하고 있습니다. 그리고 오토 스케일링 기능을 이용해 유저 유입량에 따라 서버의 리소스를 유동적으로 활용합니다.
하지만, 특정 시점에 유입량이나 서버로의 요청이 비정상적으로 치솟는 경우 자동 스케일업 되는 시간 동안 서비스가 불안정해지는 일이 가끔 일어나곤 했습니다.
이런 경우 데이터독으로부터 특정 슬랙 채널로 경고 메시지가 발송되도록 되어있지만 해당 채널에는 그 외 데이터독으로부터 발송되는 주기적인 리포팅, 상태 알림 등 다양한 목적의 메시지도 함께 수신되다 보니 QA로서 유저가 체감할 수 있는 정도의 서비스 성능 저하, 최악의 경우 장애로 이어질 수 있는 상황을 인지하고 빠르게 대응하는데 어려움이 있었습니다.
더군다나 이렇게 간헐적으로 잠깐 발생했다 사라지는 장애성 이슈의 경우, 재발방지를 위한 장기적인 대책 논의로 이어나가기가 쉽지 않았습니다.
따라서 QA팀에서는 사용자 입장에서 체감할 수 있는 장애성 이슈들을 모니터링하고 집계/분석할 수 있는 도구를 만들게 되었습니다.
문제 해결
1. 서비스 상태 체크, 결과 수집 → Python, Google Sheet
2. 스케줄링 → Jenkins
3. 시각화/리포트 → Looker Studio (Google Data Studio)
1. 서비스 상태 체크, 결과 수집
스크립트 실행 시 가장 먼저 URL이 담긴 txt 파일에서 체크 대상 URL을 가져옵니다.
그 후 requests.get() 메소드를 이용하여 해당 URL에 접근하고 서비스 페이지에서 HTTP 상태 코드를 반환 받게 됩니다.
requests.get()의 status_code로써 접근했던 URL의 HTTP 상태 코드를 받아볼 수 있습니다. HTTP 상태 코드가 헬스 체크의 주요 검증 대상이 되는데요, 해당 코드가 300 이하인 경우 해당 서비스가 정상 상태인 것으로 간주하고 다음 URL로 넘어가거나 모니터링 사이클을 종료합니다.
하지만 HTTP 상태 코드가 300 이상인 경우 해당 서비스가 비정상 상태인 것으로 간주하고 스크립트를 끝내지 않은 상태로 30초를 대기한 뒤 해당 URL에 다시 접근합니다.
재 접근한 결과 1분 이상 연속적으로 비정상 상태가 유지되는 경우 QA팀 채널로 아래와 같은 메시지를 발송 합니다.
에러가 해결되지 않은 채로 5분, 10분이 되는 시점에 리마인드를 위해 추가로 더 메시지를 발송하고 있으며, 에러가 해결되면 해당 사이트가 복구 되었다는 메시지를 발송합니다.
서비스로부터 10초 이상 응답이 오지 않는 경우 스크립트 내에서 타임아웃 에러를 발생 시키고 있으며, 그 외에도 서비스 측에서 예상치 못한 에러가 발생하면 모두 동일한 처리를 하여 아래와 같은 로직을 타게 됩니다.
서비스 헬스 체크 스크립트의 로직을 간단히 요약하면 다음과 같습니다.
1. 1분간 이상 증상이 지속되면 즉시 URL과 HTTP 상태코드/에러 메세지, 에러 지속 시간을 QA팀 채널에 발송.
2. 발생한 에러의 종류 별로 카운트하여 Google Sheet로 전송.
3. 에러가 해결되는 경우 복구 되었다는 메시지를 발송.
2. 스크립트 스케줄링
QA팀에서 활용 중인 스크립트는 Jenkins를 이용하여 실행하고 있습니다. 서비스 헬스 체크 스크립트는 1분마다 실행하도록 설정하여 매일 약 10,000 건의 모니터링을 수행합니다.
3. 시각화/리포트
Python 스크립트로 검증하고 Google Spread Sheet에 집계된 에러 기록들을 이용하여, Looker Studio(구 Google Data Studio)에서 일간, 주간, 시간대 별 에러 발생 통계를 확인할 수 있는 차트 형태로 가공하여 제공하였습니다.
마치며
QA 팀에서는 주기적인 사이트 모니터링/테스트의 목적으로 데이터독의 Synthetic Monitoring 기능도 사용하고 있습니다. 쉽게 자동화된 테스트를 구성하고 스케줄링하고 알림을 받을 수 있는 강력한 도구이지만, QA의 니즈를 100% 만족시키기에는 아쉬움이 있습니다.
그런 부족한 부분을 충족시키기 위한 도구 개발 혹은 프로그래밍을 통해서만 검증할 수 있는 영역의 테스트를 위해 QA 팀에서는 Python을 메인 개발 언어로 사용하고 있습니다.
Python + Jenkins + Looker Studio(구 Google Data Studio)를 이용하여 처음으로 테스트 결과를 수집하고 시각화까지 하는 것에 도전해 봤는데요. 우여곡절도 있었지만, 다양한 용도로 활용해볼 수 있는 기술 셋을 경험해 볼 수 있었고, 작게나마 결과물도 만들어 냈다는 것에 성장의 기쁨도 맛볼 수 있었던 경험이었습니다.
앞으로도 QA로서 다양한 품질 활동들을 효율화하고 데이터를 집계하여 의미있는 인사이트를 제공할 수 있는 방법들을 배우고 익혀나갈 것입니다.
마지막으로, 계속 도전하고 개선하며 성장할 수 있는 과제가 있는 QA팀과 원티드랩에 감사합니다.
