문제의 원인은 집 밖에 있었다

저는 사내에서 로그 모니터링 서비스를 만들고 있습니다.

 

어떤걸 만들고 있는지는 아래의 문서에서 확인하실 수 있습니다.

https://www.whatap.io/ko/log-monitoring/

로그 모니터링 | 와탭

본 문서에서는 '문제의 원인은 집밖에 있었다'라는 주제로 이야기를 풀어보려고 합니다.

(보안에 문제가 없는 선에서 이야기해야해서 생각보다 싱겁게 끝날 수 있습니다)

---

어느 날, 운영 환경에서 아래와 같은 현상이 발생했습니다.

CPU가 갑자기 왜..?

약 오전 10시 13분부터 10시 37분까지 약 30분동안 CPU System 지표가 갑자기 크게 증가합니다.

해당 서버의 여러가지 지표를 찾아봤지만 저 시간대에 특별히 무거운 트랜잭션이 발생하지는 않았습니다.

 

다만 특이한 점은 하루 전에도 비슷한 패턴의 문제가 발생했다는 점입니다.

어제는 왜..?

해당 시간대의 tps, heap memory, network in/out traffic, gc count, gc time를 확인했지만 별다른 특이사항을 확인할 수 없었습니다.

 

여기까지 확인하고 나니 꽤 많은 시간이 흘렀습니다. 정확한 Root Cause를 알 수 없는 상태로 CPU 지표를 가장 많이 사용하는 기능으로 '추정'된 grok-library 의 Thread 우선순위를 하로 낮추는 작업을 진행했습니다. 그리고 다음 날 문제가 해소되기를 기도했습니다.

Thread t = new Thread(/* 생략 */);
t.setPriority(/* 낮은 우선순위 값 */);

 

하지만 다음 날에도 어김없이 문제가 발생했습니다. 그런데 새롭게 발견된 단 한가지 특이사항은 이 때 DISK IO가 매우 높게 올라갔다는 점입니다.

저희 회사에서는 시계열 데이터를 다룰 때에 File을 활용한 자체적인 데이터베이스를 구축해서 사용합니다. 그래서 가장 핵심적인 병목 구간은 DISK IO 또는 IOPS입니다. 그리고 DISK IO를 사용하는 것은 한 번에 너무 많은 데이터를 조회할 때 발생합니다.

 

데이터를 너무 많이 오랫동안 조회하는 헤비 트랜잭션이 들어왔을 것으로 추측하고 히트맵을 확인해봅니다.

역시 10시 전후로 문제가 있었습니다! 80초나 걸린 헤비 트랜잭션이 10시 전후로 발생한 정황을 볼 때, 저 트랜잭션의 성능 최적화가 문제가 되어 DISK IO와 CPU 지표가 높게 친 것으로 추정했습니다.

 

그런데.. 저 트랜잭션을 확인해보니 DISK IO를 사용하지만 DISK IOPS를 모두 잡아먹을만큼의 기능은 아니었습니다.

그리고 이미 개선 작업이 진행 중인 API였습니다.

 

다시 사건은 미궁으로 빠지게 됩니다.. 

.

.

.

 

한참을 분석하다보니 서버 모니터링에서 특이사항이 발견되었습니다.

문제가 된 서버 프로세스와 같은 VM에 떠있는 다른 프로세스에서 문제가 되는 구간 대에 DISK I/O를 높게 사용한 것을 발견했습니다.

rsync라는 이름의 처음보는 프로세스가 DISK IO를 사용하고 있음을 발견

문제가 되는 구간대의 프로세스 성능을 확인해보니 아래와 같이 같았습니다.

최고점에서 약 30MiB를 사용한 서버 프로세스

최고점에서 약 200MiB를 사용한 rsync 프로세스

메인 서비스보다도 6배의 DISK IO를 사용하는 rsync 프로세스의 정체를 수소문해보니..

 

데브옵스팀에서 사용 중인 프로세스로 DISK 관련된 작업을 정해진 시간대(10시 13분 시작..)에 하루에 한 번 수행하는 역할을 했습니다.

 

이렇게 핵심적인 원인 파악은 종료되었고 대응 방향은 아래와 같이 진행되었습니다.

 

1. 데브옵스파트
  - rsync 배치 작업의 시간대를 늦은 밤 시간으로 조정
  - rsync 배치 작업의 DISK IO 속도를 추가 제한
2. 개발 파트

  - '추정'에 의해서 thread 우선순위를 낮추었던 부분을 원복

 

---

 

본 이슈의 원인을 직접 찾기 위해서 애플리케이션 모니터링, 서버 모니터링, 로그 모니터링을 조합해서 사용해보면서 크게 3가지를 느꼈습니다.

 

1. 문제가 발생한 시간대를 정확하게 알고 있을 때, 모니터링 서비스를 연계해서 분석하는 기능이 꼭 필요하다 (Application, Server, Log)

2. 분석을 해야하는 모니터링 대상의 특징을 고려해서, 어떤 시스템 자원의 사용량을 우선적으로 파악해야하는지 판단해야 한다 (DISK IOPS가 주요 병목인 시스템)

3. 문제의 원인은 집밖에 있을 수 있다