알바몬 때문에 많이 바쁜 나날을 보내느라 반년 이상 블로그 글이 정전이었습니다.
코드는 꾸준히 수정하고 있었는데, 글까지 쓸 짬을 도무지 못 내겠더라고요.
코드 수정 사항들도 많긴 하지만…쌓인 기간이 기간이니만큼 사소한 장애 상황들에 관한 얘기로 좀 채워볼까 합니다.
시작하기 전 짧은 사족으로, 무려 이게 올해 첫 글입니다.
접근 불가능
문제 상황
워드프레스 자동 업데이트가 다소 불안정하여, 자동 업데이트가 진행된 이후에는 php-fpm을 restart하기 전까지 워드프레스가 정상 작동을 못 하는 일이 자주 있습니다.
외에도 천재지변 등의 사유로 지난 8개월간 블로그 자체에 접근이 불가능해진 적이 3회 있었습니다.
해결책
1. 사내 공개망에서 SSH 등 접근할 수 있도록 설정
아무래도 혼자 관리하는 서버라, 무식하게 차단(blocking)으로 구멍이 생길 수 있는 부분 대부분을 막습니다.
회사 랩탑, 사내 공개망 IP에서 서버 관리용 도구(SSH, 관리자 페이지 등)에 접근할 수 있도록 작업해뒀습니다.
2. 관련 알림 Discord로 발송하도록 변경
블로그에 최신 글을 작성하면 Github README에 자동으로 업데이트하기 위해, 1시간마다 github actions에 cronjob이 돌고 있습니다.
그래서 블로그 접근이 불가능해지면 bash script에 오류가 발생해 github actions가 정상적으로 실행되지 않았다고 카카오톡 알림이 오는데, 업무 중에는 카카오톡은 잘 안 보다 보니 정오부터 알림이 오고 있었는데 자정에 집에 오며 확인하는 등의 상황이 반복되었습니다.
알림, 메모 등으로 사용할 목적으로 만들어둔 서버가 있어서, 알림을 전부 Discord로 보내도록 수정하였습니다.
여담으로, 댓글 관련된 알림 메일도 제거하고 Webhook으로 대체하였습니다.
3. 모니터링
먼저, github actions에 돌고 있던 cronjob에도 실패했을 때 Discord 알림을 보내도록 작업했습니다.
별다른 공수 없이 10 ~ 20분이면 끝나는 작업이라 제일 먼저 진행했고, 데이터를 제대로 못 불러왔을 때 README를 이상하게 업데이트하던 소소한 오류도 손봐뒀습니다.
조금 더 세세하게 확인해보려고, Simple health checker라는 bash script를 만들어서 cron을 돌리고 있었습니다.
- HTTP 상태 코드 확인
- HTTP 응답 값이 예상된 값이지 확인
- 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 찔러보고 수틀리면 nginx랑 php-fpm 껐다 켜버리는 게 제일 신경 쓸 것도 없고 좋지 않을까 싶기도 합니다.
물론 불가피한 일이 생겼을 때를 대비해서 외부에서 HTTP 접근 등 테스트는 유지하겠지만…한 번만 더 워드프레스 자동 업데이트가 장애를 유발하면 그냥 저 스크립트 sudo 권한으로 3분 주기 정도로 돌려둘 생각입니다.
댓글 관련 다양한 오류
당연하지만, 원래 라이브에 올리기 전에 테스트 서버에 올려두고 항상 테스트를 진행해왔습니다.
그냥 apache(심지어 여기부터 메인 서버랑 달랐습니다), mysql, php 등을 설치해두고 돌리고 있었기에, 초기화하며 모든 설정이 사라졌습니다.
물론 백업 된 자료가 없어도 메인 서버에 있는 자료들 긁어다 구축하면 되기에 시간만 조금 투자하면 가능했겠지만, 안 그래도 바쁜데 테스트 코드만 적당히 돌리고 라이브에서 테스트하자는 생각이 많은 문제를 낳았습니다.
문제 상황
- 댓글을 불러오는 데 실패하고 새로 고침이 무한 반복되고 있었습니다.
- 약 일주일 정도 지속되었던 문제입니다.
- 테스트 서버가 사라지다 보니, 관리자와 사용자의 버전을 다르게 구성할 수 있도록 했는데, 사용자 버전으로 추가한 버전에만 오류가 있었습니다.
- 관리자로 항상 접근하다 보니 인지 시점이 많이 늦어졌습니다.
- 비밀 댓글이 있는 포스트의 댓글이 노출되지 않고 있었습니다.
- 초기에 만든 부분 대부분은
json_encode등을 사용하지 않고 문자열을 조작해 JSON 응답을 만들어내고 있습니다. PHP 구조도 잘 모르던 시절이라 코드 재사용이 안 된 부분도 많습니다. - 비밀 댓글엔 아이콘을 출력하는데,
i태그에class속성을 넣기 위해 따옴표를 출력할 때\"형태로 작성해둔 부분이 있어, 따옴표 하나만 응답에 존재하였습니다. Invalid JSON이 되어버립니다. \\\＂형태로 수정하였습니다.
- 초기에 만든 부분 대부분은
- 댓글 필터링이 작동하지 않고 있었습니다.
- 워드프레스가 업데이트되며, 댓글을 삭제하는 함수(
wp_delete_comment)에 두 번째 인자인 강제 삭제 여부를 넘기지 않았을 때 오류가 발생하고 있었습니다. - 이 때문에 차단될 댓글(한글이 없는 댓글)을 작성하면 장애 페이지로 응답하여,
댓글을 불러오는 데 실패했습니다.란 토스트가 노출되고 있었습니다.
- 워드프레스가 업데이트되며, 댓글을 삭제하는 함수(
해결책
1. 모니터링
모니터링 툴을 도입할지, 어차피 핵심 기능이 많지 않으니 주기적으로 테스트를 진행하고 그 결과를 볼지 고민 중입니다.
일단 저부터가 Adguard 등으로 구글의 tracker부터, datadog 등 사용자를 모니터링하는 건 전부 차단하고 사는 유저인데다…방문자가 그리 많지 않아서 과연 RUM에 의존할 수 있을지 의문이 많습니다.
2. 테스트베드 구축
네, 고작 이거 테스트하자고 쿠버네티스 클러스터를 구성하고 있습니다.
IaC 안 쓰다가 반년 넘게 제대로 테스트 환경도 구축을 안 했고(솔직히 아무리 바빠도 한 주 잡고 두어 시간 정도씩 잠 줄였으면 할 수 있었다고 봅니다), '고작 그런 거' 하자고 오버 엔지니어링 하는 게 홈서버의 낭만이지 않을까 싶기도 합니다.
사실 홈 서버에서 블로그 굴리면서 배울 수 있는 것들은 어느 정도 다 배운 것 같아 짬이 나도 예전처럼 많이 수정하진 않아서, 그렇게까지 필요성이 높지도 않고 동기가 확실치도 않아서 7월 되기 전엔 테스트 베드 구축을 끝낼 생각입니다.
미뤄지면 한도 끝도 없을 것 같네요.
이런 말을 댓글 관련해서만 이렇게 많은 오류가 있었다고 적은 다음에 적으려니 말에 힘이 많이 없는 느낌이지만…아무튼, 그렇습니다.
이제 시간적 여유가 꽤 있어서, 다시 글을 좀 써볼까 합니다.
MSA 전환하며 배운 것들, 상술한 것처럼 테스트 서버용 데스크탑 하나 더 구성한 얘기, AWS Summit 갔던 얘기, 엘리스에서 진행한 레이서 테크톡에서 발표했던 얘기 등등 쓸 말은 많은데 시간이 없어 못 하고 있었는데 이제야 조금씩 써볼 수 있겠네요.
물론 이렇게 말해두고 다시 바빠져 버리면 말짱 꽝이긴 하지만, 그러지 않길 바라봅니다.
이 글 작성하고 보니 push 알림 서버 db에 장애가 있네요. 인생 쉽지 않습니다.
