TIL - 20260524

juni·2026년 5월 23일
TIL

TIL

목록 보기
360/468

0524 웹 마스터 실전 (8/N): 웹사이트 모니터링과 장애 대응

✅ 1. 웹사이트 모니터링이란?

  • 웹사이트 모니터링이란 웹사이트가 정상적으로 접속되는지, 서버가 안정적으로 동작하는지, 오류가 발생하지 않는지 지속적으로 확인하는 작업입니다.
  • 웹 마스터는 단순히 사이트를 만드는 것에서 끝나는 것이 아니라, 운영 중인 사이트가 항상 정상적으로 작동하도록 관리해야 합니다.
  • 특히 쇼핑몰, 상담 신청 페이지, 사전예약 페이지처럼 매출과 직접 연결되는 사이트에서는 장애가 곧바로 손실로 이어질 수 있습니다.

➕ 1-1. 모니터링이 중요한 이유

  • 장애를 빠르게 발견할 수 있음

    • 사이트가 접속되지 않거나 API 오류가 발생했을 때 빠르게 알 수 있습니다.
    • 사용자의 신고를 받고 나서야 장애를 알게 되면 대응이 늦습니다.

  • 서비스 신뢰도 유지

    • 사용자는 사이트가 자주 느리거나 오류가 나면 신뢰하지 않습니다.
    • 특히 결제, 상담 신청, 회원가입 같은 기능에서 오류가 발생하면 이탈률이 크게 증가합니다.

  • 원인 분석에 필요한 데이터 확보

    • 장애가 발생했을 때 로그와 지표가 남아 있어야 원인을 찾을 수 있습니다.
    • 기록이 없으면 “왜 장애가 났는지”를 추측으로만 판단하게 됩니다.

✅ 2. 모니터링해야 할 주요 항목

➕ 2-1. 서버 상태

  • 서버가 정상적으로 실행 중인지 확인해야 합니다.

  • EC2, Lightsail, 온프레미스 서버 등 어떤 환경이든 기본적으로 CPU, 메모리, 디스크 사용량을 확인해야 합니다.

  • 주요 지표

    • CPU 사용률
    • 메모리 사용률
    • 디스크 사용량
    • 네트워크 사용량
    • 서버 재부팅 여부
    • 프로세스 실행 상태

  • 주의할 점

    • CPU가 계속 90% 이상이면 서버가 과부하 상태일 수 있습니다.
    • 메모리가 부족하면 애플리케이션이 죽거나 응답이 느려질 수 있습니다.
    • 디스크가 가득 차면 로그 저장, 파일 업로드, DB 동작에 문제가 생길 수 있습니다.

➕ 2-2. 웹 서버 상태

  • Nginx, Apache 같은 웹 서버가 정상적으로 요청을 받고 응답하는지 확인해야 합니다.

  • 웹 서버 로그를 보면 사용자의 요청, 응답 코드, 에러 발생 여부를 확인할 수 있습니다.

  • 확인할 항목

    • 200 OK 응답이 정상적으로 발생하는지
    • 404 Not Found가 과도하게 많지 않은지
    • 500 Internal Server Error가 발생하지 않는지
    • 특정 URL에서 오류가 반복되지 않는지
    • 요청 처리 시간이 갑자기 길어지지 않았는지
# Nginx access log 확인
tail -f /var/log/nginx/access.log

# Nginx error log 확인
tail -f /var/log/nginx/error.log

➕ 2-3. 애플리케이션 상태

  • React, NestJS, Spring, Node.js 같은 애플리케이션이 정상적으로 동작하는지 확인해야 합니다.

  • 프론트엔드는 화면이 깨지거나 JavaScript 오류가 발생할 수 있고, 백엔드는 API 응답 실패나 DB 연결 오류가 발생할 수 있습니다.

  • 백엔드에서 확인할 항목

    • API 응답 상태 코드
    • 요청 처리 시간
    • DB 연결 오류
    • 외부 API 호출 실패
    • 인증/인가 오류
    • 예외 발생 로그

  • 프론트엔드에서 확인할 항목

    • JavaScript 런타임 오류
    • API 호출 실패
    • 이미지, CSS, JS 파일 로딩 실패
    • 특정 브라우저에서만 발생하는 오류
    • 모바일 화면 깨짐

➕ 2-4. 데이터베이스 상태

  • DB는 서비스의 핵심 데이터가 저장되는 곳이므로 반드시 모니터링해야 합니다.

  • DB 장애가 발생하면 로그인, 주문, 상담 신청, 관리자 페이지 등 대부분의 기능이 영향을 받습니다.

  • 확인할 항목

    • DB 연결 가능 여부
    • 느린 쿼리 발생 여부
    • 커넥션 수 증가
    • 디스크 용량
    • 백업 상태
    • 락(lock) 발생 여부

  • 실무 예시

    • 상담 신청 목록 조회가 갑자기 느려진 경우
    • 관리자 페이지에서 데이터 저장이 실패하는 경우
    • 특정 이벤트 페이지 접속 시 DB 조회가 몰리는 경우
    • 외부 광고 유입 증가로 DB 부하가 급증하는 경우

✅ 3. 장애 대응의 기본 흐름

  • 장애 대응은 감정적으로 당황해서 이것저것 만지는 것이 아니라, 일정한 순서대로 확인해야 합니다.
  • 순서를 정해두면 장애 상황에서도 빠르게 원인을 좁힐 수 있습니다.

➕ 3-1. 1단계: 장애 범위 확인

  • 먼저 장애가 전체 서비스 문제인지, 일부 기능 문제인지 확인합니다.

  • 확인 질문

    • 사이트 전체가 접속되지 않는가?
    • 특정 페이지에서만 오류가 나는가?
    • 관리자 페이지만 문제인가?
    • API만 문제인가?
    • PC와 모바일 모두 문제인가?
    • 특정 브라우저에서만 문제인가?

➕ 3-2. 2단계: 최근 변경 사항 확인

  • 장애는 대부분 최근 변경 사항과 관련이 있는 경우가 많습니다.

  • 배포, 설정 변경, DB 변경, 외부 API 변경, 도메인/DNS 변경 등을 확인해야 합니다.

  • 확인할 변경 사항

    • 최근 프론트엔드 배포
    • 최근 백엔드 배포
    • Nginx 설정 변경
    • 환경변수 변경
    • DB 테이블 구조 변경
    • 외부 API 키 변경
    • SSL 인증서 갱신
    • 도메인 또는 DNS 설정 변경

➕ 3-3. 3단계: 로그 확인

  • 장애 원인을 찾을 때 가장 중요한 것은 로그입니다.
  • 로그를 보지 않고 코드를 추측으로 수정하면 문제를 더 키울 수 있습니다.
# 최근 에러 로그 확인
tail -n 100 /var/log/nginx/error.log

# 실시간 로그 확인
tail -f /var/log/nginx/error.log

# 특정 키워드 검색
grep "500" /var/log/nginx/access.log
grep "error" /var/log/nginx/error.log

  • 로그 확인 기준

    • 오류가 발생한 시간대 확인
    • 어떤 URL에서 오류가 났는지 확인
    • 어떤 상태 코드가 반환되었는지 확인
    • 같은 오류가 반복되는지 확인
    • 배포 직후부터 오류가 시작되었는지 확인

➕ 3-4. 4단계: 임시 조치

  • 원인을 완전히 해결하기 전이라도 사용자 피해를 줄이기 위한 임시 조치가 필요할 수 있습니다.

  • 임시 조치 예시

    • 문제가 된 배포를 이전 버전으로 롤백
    • 장애 페이지에 점검 안내 문구 표시
    • 문제가 되는 기능 일시 비활성화
    • 트래픽이 몰리는 페이지 캐싱 적용
    • 서버 재시작
    • 외부 API 장애 시 대체 문구 표시

  • 단, 서버 재시작은 원인을 지우는 행동이 될 수 있으므로, 가능하면 재시작 전에 로그를 먼저 확인해야 합니다.

➕ 3-5. 5단계: 원인 해결 및 재발 방지

  • 장애를 임시로 복구한 뒤에는 반드시 원인을 정리해야 합니다.

  • “다시 되니까 끝”이라고 생각하면 같은 장애가 반복됩니다.

  • 정리할 내용

    • 언제 장애가 발생했는가?
    • 어떤 사용자가 영향을 받았는가?
    • 직접 원인은 무엇인가?
    • 근본 원인은 무엇인가?
    • 어떻게 복구했는가?
    • 다음에는 어떻게 예방할 것인가?

✅ 4. 실무에서 자주 발생하는 장애 유형

➕ 4-1. 502 Bad Gateway

  • Nginx가 뒤쪽의 애플리케이션 서버와 통신하지 못할 때 자주 발생합니다.

  • 가능한 원인

    • Node.js/NestJS 서버가 죽음
    • 포트 번호 설정 오류
    • PM2 프로세스 중단
    • 애플리케이션 배포 실패
    • 서버 리소스 부족
# PM2 프로세스 확인
pm2 list

# PM2 로그 확인
pm2 logs

# 애플리케이션 재시작
pm2 restart app

➕ 4-2. 404 Not Found

  • 요청한 페이지나 파일을 서버에서 찾을 수 없을 때 발생합니다.

  • 가능한 원인

    • 잘못된 URL
    • 프론트엔드 라우팅 설정 문제
    • 빌드 파일 누락
    • 이미지 경로 오류
    • Nginx try_files 설정 문제

  • React SPA에서 자주 발생하는 문제

    • /event/galaxy 같은 경로로 직접 접속했을 때 서버가 해당 파일을 찾지 못해 404가 발생할 수 있습니다.
    • 이 경우 Nginx에서 모든 경로를 index.html로 보내도록 설정해야 합니다.
location / {
  try_files $uri /index.html;
}

➕ 4-3. 500 Internal Server Error

  • 서버 내부에서 예외가 발생했을 때 나타납니다.

  • 가능한 원인

    • 코드 예외 처리 누락
    • DB 쿼리 오류
    • 환경변수 누락
    • 외부 API 응답 오류
    • 권한 없는 파일 접근
    • 데이터 형식 불일치

  • 대응 방법

    • 백엔드 로그 확인
    • 오류 발생 API 확인
    • 요청 파라미터 확인
    • 최근 배포 코드 확인
    • DB 연결 상태 확인

➕ 4-4. SSL 인증서 문제

  • HTTPS 접속 시 “안전하지 않은 사이트” 경고가 뜨거나 접속이 차단될 수 있습니다.

  • 가능한 원인

    • SSL 인증서 만료
    • 인증서 자동 갱신 실패
    • 도메인과 인증서 정보 불일치
    • 중간 인증서 설정 누락
    • Nginx SSL 설정 오류
# certbot 인증서 상태 확인
sudo certbot certificates

# 인증서 갱신 테스트
sudo certbot renew --dry-run

✅ 5. 모니터링 도구

➕ 5-1. AWS CloudWatch

  • AWS에서 제공하는 모니터링 서비스입니다.

  • EC2, RDS, Lambda, ELB 등 AWS 리소스의 상태를 확인할 수 있습니다.

  • 활용 예시

    • EC2 CPU 사용률 확인
    • RDS 연결 수 확인
    • 서버 디스크 사용량 경고
    • 특정 로그 패턴 감지
    • 알람 발생 시 이메일 또는 Slack 알림 전송

➕ 5-2. Sentry

  • 프론트엔드와 백엔드 애플리케이션 오류를 수집하는 도구입니다.

  • 사용자가 직접 신고하지 않아도 어떤 오류가 발생했는지 확인할 수 있습니다.

  • 확인 가능한 정보

    • 오류 메시지
    • 오류가 발생한 파일과 라인
    • 사용자 브라우저 정보
    • 발생 시간
    • API 요청 정보
    • 배포 버전

➕ 5-3. UptimeRobot

  • 웹사이트가 정상적으로 접속되는지 주기적으로 확인해주는 도구입니다.

  • 사이트가 다운되면 이메일, 문자, Slack 등으로 알림을 받을 수 있습니다.

  • 활용 예시

    • 메인 홈페이지 접속 확인
    • 상담 신청 페이지 접속 확인
    • 관리자 페이지 접속 확인
    • API 헬스체크 URL 확인
https://www.example.com/health
https://api.example.com/health

➕ 5-4. Google Analytics / Search Console

  • 장애는 서버 로그에서만 확인되는 것이 아닙니다.

  • Google Analytics나 Search Console에서도 이상 징후를 확인할 수 있습니다.

  • 확인 가능한 이상 징후

    • 특정 시간대부터 방문자 수 급감
    • 특정 페이지 이탈률 급증
    • 광고 유입은 있는데 전환이 발생하지 않음
    • 검색 노출 페이지에서 404 오류 증가
    • 모바일 사용자만 전환율 급감

✅ 6. 장애 대응 문서화

  • 장애를 처리한 후에는 반드시 문서로 남겨야 합니다.
  • 혼자 일하는 개발자라도 문서화가 되어 있으면 다음 장애 때 훨씬 빠르게 대응할 수 있습니다.

➕ 6-1. 장애 기록 템플릿

## 장애 기록

### 1. 발생 일시
- 2026-05-24 14:30

### 2. 장애 범위
- 이벤트 페이지 접속 시 502 오류 발생

### 3. 사용자 영향
- 사전예약 상담 신청 페이지 접근 불가

### 4. 원인
- NestJS 서버 배포 후 PM2 프로세스가 정상적으로 재시작되지 않음

### 5. 조치 내용
- PM2 로그 확인
- 프로세스 재시작
- Nginx 상태 확인
- 페이지 정상 접속 확인

### 6. 재발 방지
- 배포 스크립트에 PM2 상태 확인 명령 추가
- 헬스체크 URL 모니터링 추가
- 배포 후 체크리스트 작성

✅ 7. 웹 마스터 운영 체크리스트

➕ 7-1. 매일 확인할 항목

  1. 사이트 메인 페이지 접속 상태 확인
  2. 주요 이벤트/상품 페이지 접속 확인
  3. 상담 신청 또는 주문 기능 정상 작동 확인
  4. 서버 CPU, 메모리, 디스크 상태 확인
  5. 최근 에러 로그 확인
  6. 관리자 페이지 로그인 확인
  7. 외부 API 연동 상태 확인

➕ 7-2. 매주 확인할 항목

  1. 404 오류 페이지 증가 여부 확인
  2. 500 오류 발생 여부 확인
  3. SSL 인증서 만료일 확인
  4. DB 백업 상태 확인
  5. 광고 랜딩 페이지 정상 작동 확인
  6. Google Analytics 전환 데이터 확인
  7. Search Console 색인 오류 확인

➕ 7-3. 배포 후 확인할 항목

  1. 메인 페이지 정상 접속
  2. 주요 페이지 라우팅 확인
  3. API 응답 확인
  4. 로그인/인증 기능 확인
  5. 상담 신청 또는 주문 기능 확인
  6. 관리자 페이지 주요 기능 확인
  7. 브라우저 콘솔 오류 확인
  8. 모바일 화면 깨짐 여부 확인
  9. 로그에 에러가 발생하지 않는지 확인
  10. 이전 버전으로 롤백 가능한지 확인

📌 요약

  • 웹사이트 모니터링은 사이트가 정상적으로 접속되고, 서버와 애플리케이션이 안정적으로 동작하는지 지속적으로 확인하는 작업입니다.
  • 웹 마스터는 서버 상태, 웹 서버 상태, 애플리케이션 상태, 데이터베이스 상태를 함께 확인해야 합니다.
  • 장애 대응은 장애 범위 확인 → 최근 변경 사항 확인 → 로그 확인 → 임시 조치 → 원인 해결 및 재발 방지 순서로 진행하는 것이 좋습니다.
  • 실무에서 자주 발생하는 장애에는 502 Bad Gateway, 404 Not Found, 500 Internal Server Error, SSL 인증서 문제가 있습니다.
  • AWS CloudWatch, Sentry, UptimeRobot, Google Analytics, Search Console 같은 도구를 활용하면 장애를 더 빠르게 발견하고 분석할 수 있습니다.
  • 장애가 해결된 후에는 반드시 기록을 남겨야 하며, 배포 후 체크리스트와 모니터링 체계를 갖추는 것이 중요합니다.
profile
juni
이전 포스트

TIL - 20260523

다음 포스트

TIL - 20260525

0개의 댓글