모두
모두콘텐츠
얼마 전 사이트가 느려졌다는 연락을 받고 서버를 열어봤는데, CPU는 멀쩡하고 디스크 여유 공간도 남아 있었다. 문제는 로그가 쌓인 파티션의 아이노드가 다 찬 것이었다. 용량 그래프 하나만 보고 있었다면 장애 원인을 찾는 데 시간이 더 걸렸을 것이다. 서버 모니터링은 그래프를 많이 만드는 일이 아니라, 서비스가 멈추기 전에 이상을 알아채고 어디부터 확인할지 정해 두는 일에 가깝다.
서버 상태보다 사용자 접속부터 확인한다
가장 먼저 외부에서 사이트가 열리는지 확인한다. 서버 안에서 웹서버 프로세스가 살아 있어도 사용자는 접속하지 못할 수 있다. 방화벽 규칙이 바뀌거나, SSL 인증서가 만료되거나, 데이터베이스 연결이 끊겨도 프로세스 상태만 보면 정상으로 나온다.
대표 페이지 한 곳을 1분 간격으로 확인하고 응답 코드와 응답 시간을 기록한다. 한 번 실패했다고 바로 새벽에 사람을 깨우기보다는 두세 번 연속 실패했을 때 알리도록 설정한다. 다만 결제나 로그인처럼 중요한 기능은 첫 화면과 따로 확인해야 한다. 첫 화면이 열리는 것과 주문이 완료되는 것은 다른 문제다.
응답 시간은 평균보다 느린 요청의 비율을 본다. 예를 들어 요청의 95%가 0.5초 안에 끝나던 사이트에서 이 값이 2초로 올라가면, 아직 접속은 되더라도 원인을 확인할 만하다. 방문자가 적은 새벽에는 요청 몇 건만으로 수치가 크게 흔들리므로, 요청 수와 함께 읽어야 한다.
CPU보다 함께 봐야 하는 숫자가 있다
서버 자원은 CPU 사용률, 사용 가능한 메모리, 스왑 입출력, 디스크 사용률과 아이노드, 디스크 대기 시간, 네트워크 오류를 기본으로 잡는다. 웹서버와 데이터베이스를 한 대에서 운영한다면 두 프로세스의 메모리와 연결 수도 따로 본다. CPU 사용률이 80%를 10분 넘게 유지하면 확인하는 식으로 시작할 수 있지만, 이 수치 하나로 증설을 결정하지는 않는다. 배치 작업 때문에 잠깐 치솟는 것과 실제 사용자 응답이 느려지는 것은 다르다.
메모리는 사용률 90%라는 숫자만으로 판단하기 어렵다. 운영체제가 남는 메모리를 캐시에 쓰기 때문이다. 사용 가능한 메모리가 계속 줄고 스왑 입출력이 늘면서 응답 시간까지 나빠지는지 봐야 한다. 디스크는 75%에서 한 번 알리고 85%에 도달하기 전에 조치할 시간을 확보하는 편이 실무에서 편했다. 로그가 급증하는 서버라면 남은 용량을 비율뿐 아니라 최근 증가 속도로도 계산한다. 하루에 5GB씩 늘고 20GB가 남았다면, 현재 사용률보다 남은 4일이 더 중요한 정보다.
트래픽도 월 방문자 수만으로 사양을 정하면 어긋난다. 하루 3만 페이지뷰라도 대부분이 한 시간에 몰리면 평균치로 계산한 서버는 버거울 수 있다. 초당 요청 수와 동시에 처리 중인 요청 수, 데이터베이스 쿼리 시간을 같은 시간대에 놓고 본다. 느려진 시간에 CPU와 메모리가 여유롭다면 서버를 키우기 전에 느린 쿼리, 외부 호출, 캐시 설정을 확인하는 게 순서다.
알림은 조치할 수 있는 것만 보낸다
운영 초기에 흔히 하는 실수가 모든 지표에 알림을 거는 것이다. 경고가 하루에 수십 개씩 오면 정작 사이트가 멈췄을 때도 확인이 늦어진다. 알림마다 누가 받고, 언제 확인하며, 첫 조치가 무엇인지 적어 둔다. 즉시 대응이 필요한 접속 불가와 디스크 부족은 알림으로 보내고, 일시적인 CPU 상승이나 방문자 증가 추세는 대시보드에서 확인하는 식이다.
알림은 서로 이어지는 원인과 증상도 구분해야 한다. 데이터베이스 장애로 첫 화면 확인, 응답 시간, 오류율 알림이 동시에 울렸다면 세 건의 사고가 아니다. 먼저 접속 불가를 알리고, 함께 나타난 지표를 원인 조사에 쓰면 된다. 알림 메시지에는 발생 시각, 대상 서버, 현재 값, 최근 정상 값이 들어가야 당직자가 바로 판단할 수 있다.
모니터링 시스템 자체가 같은 서버에서만 돌아가면 서버가 꺼졌을 때 알림도 사라진다. 최소한 외부 접속 확인은 감시 대상과 분리한다. 알림을 받을 연락 수단도 한 가지에만 의존하지 말고 실제로 도착하는지 가끔 시험한다.
백업과 인증서도 운영 지표로 넣는다
CPU 그래프가 정상이어도 복구할 수 없는 서버는 안전하지 않다. 백업 작업의 성공 여부와 마지막 성공 시각을 매일 확인한다. 파일만 백업하고 데이터베이스가 빠졌거나, 백업 파일이 같은 서버의 같은 디스크에만 있으면 장애 때 쓸 수 없을 수 있다. 월 1회라도 별도 환경에 복원해 로그인과 주요 데이터 조회까지 확인하는 편이 낫다. 백업 성공 알림보다 실제 복원 기록이 더 믿을 만하다.
SSL 인증서 만료일은 30일 전에 경고를 걸고, 갱신 뒤에는 외부에서 새 인증서가 보이는지 확인한다. 자동 갱신 작업이 성공해도 웹서버가 이전 인증서를 계속 내보내는 경우가 있다. 도메인 갱신일과 결제 수단 상태도 운영 일정에 넣어 둔다. 이런 항목은 트래픽이 적은 개인 사이트에서도 빠지면 바로 접속 장애로 이어진다.
처음부터 비싼 관제 서비스가 필요한 사이트는 많지 않다. 작은 사이트라면 외부 접속 확인, 기본 자원 지표, 백업 성공 여부부터 갖추고 한 달 정도 실제 변동 폭을 본 뒤 알림 기준을 조정해도 충분하다. 장애가 났을 때 내가 첫 10분 동안 확인할 화면이 무엇인지 떠올릴 수 있다면, 그 모니터링은 이미 쓸모가 있다.
