서버 다운 행동강령

저번 주 목요일, 출근 하는 도중에 운영중인 서비스가 문제가 있다는 메시지가 왔다.

서비스가 급작스럽게 느려졌다. 혹은 아예 접속이 안된다. 라는 요청이 들어왔다. 회사가 코 앞이라 최대한 빨리 회사에 출근해서 노트북을 펼쳤다. 초반에 접근을 잘못해서 해멘 부분이 있었는데 다행히 사내 동료분들이 도와주셔서 문제를 해결할 수 있었다.

아직 서비스 운영을 한 경험이 많지는 않지만, 짧은 기간 동안 산전수전 많이 굴러서인지 나름대로의 규칙이 생겼다. 그리고 이번 글은 이 규칙에 대해서 공유해보고자 한다.

때때로, 당장의 문제를 해결하는 방법이 있다. 하지만 이것이 언제든지 재발 할 수 있는 여지를 남겨 둔다면 차라리 시도하지 않는 것이 좋다.

나는 당장의 문제를 해결하는 몇 가지 방법을 경험했는데 아래와 같다.

당장 서비스를 이용하지 못하는 유저가 있고, CS가 밀려들어오는 상황은 충분히 경험해보지 않으면 멘탈이 박살 안나는게 이상하다. 그렇기 때문에, 어떻게든 일단 돌아가게 하는 가장 빠른 방법이기 때문에 이런 선택을 한다.

하지만 이러한 선택은 에러 발생의 원인을 찾을수 있는 단서를 잃는 경우가 많다.

어느 정도의 단서는 남을 지도 모르지만, 그렇지 않은 경우 당시 프로세스의 자원 사용 상황등은 라이브로 확인 하는것이 좋다.

그리고 대부분의 경우 재시작하여 문제가 완전히 해결되는 경우는 잘 없다.

1번과 마찬가지로 단서를 잃는 경우가 많다.

뿐만 아니라, 재배포라는 것은 시간을 10분 이상 잡아먹는 일이다. 그렇기 때문에 근거 없는 롤백은 시간만 잡아먹는 일이다.

물론 최근 코드반영이 이루어 졌다거나, 의심 되는 부분이 있다면 롤백을 시도하여 문제를 해결한 후에 원인을 찾는 것이 맞다고 생각한다.

하지만 그런게 아니라면 최근 배포된 코드를 충분히 살펴 보고 롤백은 차선책으로 선택하는 것이 좋다.

단서를 수집하다보면, 결정적인 증거를 발견할 때가 있다. 하지만 이 때 그것이 원인인지 증상인지 생각해보는 것이 중요하다. 자칫 원인이 아니라 증상인데 이를 잘못 판단하여 해결하려 한다면 해결 할 수 없는 늪에 빠지는 경우가 있다.

하나의 간단한 사례를 예로들면 이렇다.

어느날 다수의 특정 쿼리가 idle상태로 실행되지 못하고 있었다. 데이터베이스의 CPU 사용량은 100%였다.

당연히 해당 쿼리를 의심해보지 않을 수 없다. 하지만 이는 원인이 아니라 증상이다. 해당 쿼리는 미들웨어에서 발생하는 쿼리였고 이미 CPU점유율을 100%로 찍었기에, 서비스에서 항상 실행되는 해당 쿼리가 idle상태로 가장 많이 노출되는 것이였다. 만약 해당 쿼리가 계속 원인이라고 생각하고 조사한다면 답을 찾을 수 없을 것이다.

서버 다운이라는 상황 자체가 급박한 상황이라 판단력이 흐려지는 경우가 많은데, 원인이라고 생각했던 문제가 해결되지 않는다면 이것이 증상인지 원인인지 다시 한 번 진단해 볼 필요가 있다.

파편적인 정보로는 해결이 어려우므로 미리 여러 모니터링 툴을 사용해서 적용해보는 것을 추천한다.

나 같은 경우에도 우리 서비스에 맞는 모니터링 툴을 제안하기위해 Datadog, Sentry, AWS CloudWatch 등을 사용해보았다.

제안서를 작성하면서 정리한 내 경험을 공유한다.

Sentry는 주로 "Exception Monitoring" 를 관리하는데 도움이 됨. 간단한 기능으로 유저 보다 빠르게 에러를 발견하고 조치를 취하려면 적절한 조치라고 생각이 됨

에러가 쌓이면 위와 같이 이슈 티켓이 발행 되는데 발생한 위치, 횟수와 유저 정보등을 정리해서 시각화 해주는 기능을 제공한다. 슬랙등과 연동도 되기 때문에 인스턴스의 시스템로그를 직접 확인하지 않고도 빠르게 모니터링 할 수 있다.

뿐만 아니라 성능에 대한 모니터링도 어느 정도 제공한다. 어떤 요청에서 평균적으로 얼마만큼의 시간이 소요되고, 어떤 레이어에서 부하가 심한지에 대해서도 정보를 제공한다.

Datadog은 주로 "Performance Monitoring" 를 관리하는데 더욱 도움이 됨. 특히 복잡한 인프라간의 상관관계를 한눈에 파악 할 수 있음

다른 서비스들와 통합이 쉽고 이를 통해 여러 인프라를 한 눈에 모니터링 할 수 있다.

Sentry와 마찬가지로 요청별 부하 상태에 대한 정보를 얻을 수 있다. Sentry에 비해 조금 더 정확한 정보를 얻을 수 있고, 하나의 요청에 발생하는 여러 자원 상황 (DB CPU, SQL, Server CPU )등 관련된 다른 수치들과도 동시에 비교 가능하다.

Metrics는 호스트 수준 메모리 사용량 (메모리 누수) 및 TCP 재전송 속도, 시스템, SQL, nginx에서 측정한 수치들을 데이터 포인터로 저장함. 이렇게 측정한 여러 데이터를 시간순으로 나열하여 동시에 비교 할 수 있다.

Watchdog은 잠재적 인 애플리케이션 및 인프라 문제를 자동으로 감지하는 APM 성능 및 인프라 메트릭을위한 알고리즘 기능. Watchdog은 다음과 같은 추세와 패턴을 관찰함.

위 APM과 인프라 Metrics을 보고 패턴을 인식하고, 불규칙성등을 찾아 에러를 조기에 진단하는 기능을 제공한다.

Datadog와 마찬가지로 "Performance Monitoring" 에 좀 더 도움이 됨.

AWS 서비스에서 발생하는 로그와 지표들을 통한 알람을 손쉽게 관리 할 수 있음. 서비스 간의 이동도 쉬운 것도 장점.

RDS 성능 개선 도구로 실시간으로 발생하는 SQL과 사용 자원에 대한 모니터링을 지원함.

도저히 내 힘으로 극복할 수 없는 경우도 분명히 발생한다.

운 좋게 시니어 개발자나 다른 동료개발자가 함께라면 좋겠지만 그렇지 않은 경우에 스스로 극복해야 하는 경우도 분명 찾아온다.

이를 해결하기 위해서, 아래의 기본적인 두 가지 전제는 바탕이 되어야 한다. 만약 아래의 두가지를 못하는 서비스가 있다면 연습을 하거나, 모니터링 툴, APM등의 서비스를 사용해서 준비해두자.

해결할 수 없었던 이슈를 마주하는 건, 마치 이길 수 없는 고수와 싸우는 것과 같다. 이 때, 문제가 해결된채로 복기 없이 끝낸다면 얼마나 좋은 기회를 놓치는 것인가. 고수가 초보와 자주 붙어주지 않는 것처럼 서버는 자주 떨어지지 않는다. 해프닝으로 끝낼 게 아니라 시간단위로 어떤 생각을 했고 어떤 식으로 접근하려 했는지 꼼꼼히 정리하자.

동료 개발자가 있다면 정리한 내용을 바탕으로 토론하는 것이 큰 배움이 될 수 있다.

누구도 눈치채지 못하면 이슈가 아니다. 이슈 발생 전후로 서버의 자원을 모니터링하고 있다면 이상 발생 시, 사용 중인 메신저(Slack 등)으로 알람을 맞춰두자.