블로그 각종 장애 처리 일지

개발

블로그 각종 장애 처리 일지
최종 수정일:

알바몬 때문에 많이 바쁜 나날을 보내느라 반년 이상 블로그 글이 정전이었습니다.
코드는 꾸준히 수정하고 있었는데, 글까지 쓸 짬을 도무지 못 내겠더라고요.

코드 수정 사항들도 많긴 하지만…쌓인 기간이 기간이니만큼 사소한 장애 상황들에 관한 얘기로 좀 채워볼까 합니다.

시작하기 전 짧은 사족으로, 무려 이게 올해 첫 글입니다.

접근 불가능

문제 상황

워드프레스 자동 업데이트가 다소 불안정하여, 자동 업데이트가 진행된 이후에는 php-fpm을 restart하기 전까지 워드프레스가 정상 작동을 못 하는 일이 자주 있습니다.
외에도 천재지변 등의 사유로 지난 8개월간 블로그 자체에 접근이 불가능해진 적이 3회 있었습니다.

해결책

1. 사내 공개망에서 SSH 등 접근할 수 있도록 설정

아무래도 혼자 관리하는 서버라, 무식하게 차단(blocking)으로 구멍이 생길 수 있는 부분 대부분을 막습니다.
회사 랩탑, 사내 공개망 IP에서 서버 관리용 도구(SSH, 관리자 페이지 등)에 접근할 수 있도록 작업해뒀습니다.

2. 관련 알림 Discord로 발송하도록 변경

블로그에 최신 글을 작성하면 Github README에 자동으로 업데이트하기 위해, 1시간마다 github actions에 cronjob이 돌고 있습니다.
그래서 블로그 접근이 불가능해지면 bash script에 오류가 발생해 github actions가 정상적으로 실행되지 않았다고 카카오톡 알림이 오는데, 업무 중에는 카카오톡은 잘 안 보다 보니 정오부터 알림이 오고 있었는데 자정에 집에 오며 확인하는 등의 상황이 반복되었습니다.

디스코드 Webhook 알림

알림, 메모 등으로 사용할 목적으로 만들어둔 서버가 있어서, 알림을 전부 Discord로 보내도록 수정하였습니다.
여담으로, 댓글 관련된 알림 메일도 제거하고 Webhook으로 대체하였습니다.

3. 모니터링

먼저, github actions에 돌고 있던 cronjob에도 실패했을 때 Discord 알림을 보내도록 작업했습니다.
별다른 공수 없이 10 ~ 20분이면 끝나는 작업이라 제일 먼저 진행했고, 데이터를 제대로 못 불러왔을 때 README를 이상하게 업데이트하던 소소한 오류도 손봐뒀습니다.


조금 더 세세하게 확인해보려고, Simple health checker라는 bash script를 만들어서 cron을 돌리고 있었습니다.

  1. HTTP 상태 코드 확인
  2. HTTP 응답 값이 예상된 값이지 확인
  3. HTTP 응답 속도 확인

간단하게 위 작업 정도 진행할 수 있는 스크립트입니다. 문제가 있으면, 1번에 첨부했던 이미지처럼 알림이 옵니다.
다음에 글을 또 쓸 때 다루겠지만, 개발 서버용 데스크탑을 하나 더 들이고, 리버스 프록시 서버도 하나 더 들여 관리는 제곱 이상으로 힘들어지고, 불안감은 세제곱 이상으로 커진 상태라 최소한 안심은 할 수 있는 상태로 만들어두고 싶었습니다.


진행하다 보니 bash script 짜는 게 참 재미는 있지만 귀찮기도 하고…조금 더 다양한 모니터링을 진행하고, 현재 서버 상태를 보여주는 페이지도 별도로 제작하고 싶어 Uptime kuma라는 모니터링 툴을 도입했습니다.
오늘 새벽에 끝내고, 테스트들 전부 옮긴 뒤 bash script 돌리던 cronjob은 종료했습니다.

https://status.marshallku.com에서 현재 서비스의 상태를 확인하실 수 있습니다.
당연히 별도 클라우드에서 돌아가고 있습니다.

4. self-healing...?

#!/bin/bash
url="http://localhost/health"
http_response=$(curl -s -w '\n%{http_code}\n' "$url")
http_status=$(echo "$http_response" | tail -n 1 | awk '{print $1}')
 
if [ "$http_status" -ne 200 ]; then
    sudo systemctl restart nginx
    sudo systemctl restart php8.0-fpm
fi

거창하게 self-healing이라고 부를 것 까지도 없이, 사실 이런 소규모 서비스에서는 그냥 cronjob으로 ping 찔러보고 수틀리면 nginxphp-fpm 껐다 켜버리는 게 제일 신경 쓸 것도 없고 좋지 않을까 싶기도 합니다.
물론 불가피한 일이 생겼을 때를 대비해서 외부에서 HTTP 접근 등 테스트는 유지하겠지만…한 번만 더 워드프레스 자동 업데이트가 장애를 유발하면 그냥 저 스크립트 sudo 권한으로 3분 주기 정도로 돌려둘 생각입니다.

댓글 관련 다양한 오류

당연하지만, 원래 라이브에 올리기 전에 테스트 서버에 올려두고 항상 테스트를 진행해왔습니다.
그냥 apache(심지어 여기부터 메인 서버랑 달랐습니다), mysql, php 등을 설치해두고 돌리고 있었기에, 초기화하며 모든 설정이 사라졌습니다.

물론 백업 된 자료가 없어도 메인 서버에 있는 자료들 긁어다 구축하면 되기에 시간만 조금 투자하면 가능했겠지만, 안 그래도 바쁜데 테스트 코드만 적당히 돌리고 라이브에서 테스트하자는 생각이 많은 문제를 낳았습니다.

문제 상황

해결책

1. 모니터링

모니터링 툴을 도입할지, 어차피 핵심 기능이 많지 않으니 주기적으로 테스트를 진행하고 그 결과를 볼지 고민 중입니다.
일단 저부터가 Adguard 등으로 구글의 tracker부터, datadog 등 사용자를 모니터링하는 건 전부 차단하고 사는 유저인데다…방문자가 그리 많지 않아서 과연 RUM에 의존할 수 있을지 의문이 많습니다.

2. 테스트베드 구축

네, 고작 이거 테스트하자고 쿠버네티스 클러스터를 구성하고 있습니다.
IaC 안 쓰다가 반년 넘게 제대로 테스트 환경도 구축을 안 했고(솔직히 아무리 바빠도 한 주 잡고 두어 시간 정도씩 잠 줄였으면 할 수 있었다고 봅니다), '고작 그런 거' 하자고 오버 엔지니어링 하는 게 홈서버의 낭만이지 않을까 싶기도 합니다.

사실 홈 서버에서 블로그 굴리면서 배울 수 있는 것들은 어느 정도 다 배운 것 같아 짬이 나도 예전처럼 많이 수정하진 않아서, 그렇게까지 필요성이 높지도 않고 동기가 확실치도 않아서 7월 되기 전엔 테스트 베드 구축을 끝낼 생각입니다.
미뤄지면 한도 끝도 없을 것 같네요.

이런 말을 댓글 관련해서만 이렇게 많은 오류가 있었다고 적은 다음에 적으려니 말에 힘이 많이 없는 느낌이지만…아무튼, 그렇습니다.


이제 시간적 여유가 꽤 있어서, 다시 글을 좀 써볼까 합니다.
MSA 전환하며 배운 것들, 상술한 것처럼 테스트 서버용 데스크탑 하나 더 구성한 얘기, AWS Summit 갔던 얘기, 엘리스에서 진행한 레이서 테크톡에서 발표했던 얘기 등등 쓸 말은 많은데 시간이 없어 못 하고 있었는데 이제야 조금씩 써볼 수 있겠네요.
물론 이렇게 말해두고 다시 바빠져 버리면 말짱 꽝이긴 하지만, 그러지 않길 바라봅니다.


이 글 작성하고 보니 push 알림 서버 db에 장애가 있네요. 인생 쉽지 않습니다.

Report an issue