503 Service Unavailable

이 오류의 의미와 확인 방법

• 브라우저, API 클라이언트 또는 모니터링 도구에 503 Service Unavailable 또는 Service Temporarily Unavailable이 표시됩니다.
• 트래픽이 많을 때 오류가 나타나고 요청량이 줄어들면 사라집니다.
• CMS 업데이트 또는 배포 후 유지 관리 모드가 해제되지 않아 사이트를 계속 사용할 수 없습니다.
• 필수 데이터베이스, 캐시 서비스 또는 upstream API를 사용할 수 없는 동안 오류가 지속됩니다.
• rate limiting, WAF 규칙, 라우팅 또는 비정상적인 load balancer 상태 점검으로 인해 특정 URL, 클라이언트, 요청 패턴 또는 백엔드에서만 503 응답을 받습니다.
• 응답 헤더 또는 프록시가 생성한 오류 페이지를 보면 요청이 애플리케이션에 도달하지 않았을 가능성이 있습니다.

가능성이 높은 순서의 주요 원인

1. 서버 과부하 — 정상적인 요청량이나 트래픽 급증으로 CPU, 메모리, 활성 연결, 웹 서버 워커, PHP-FPM 워커 또는 데이터베이스 연결이 고갈됩니다.
2. 해제되지 않은 유지 관리 모드 — CMS 업데이트 또는 배포가 유지 관리 플래그를 활성화했지만, 중단 후 이를 제거하지 못합니다. WordPress에서는 남아 있는 .maintenance 파일이 원인일 수 있습니다.
3. 사용할 수 없는 필수 종속 서비스 — 애플리케이션이 요청 처리에 필요한 데이터베이스, 캐시 계층 또는 내부 API에 연결하지 못합니다. 종속 서비스 자체는 실행 중이어도 애플리케이션 호스트나 네트워크에서 접근할 수 없을 수 있습니다.
4. 의도적인 rate limiting 또는 WAF 동작 — 트래픽이 임계값을 초과하거나 보안 규칙에 일치하면 rate limiter 또는 웹 애플리케이션 방화벽이 503 응답을 반환할 수 있습니다.
5. 잘못된 load balancer 상태 점검 — 상태 점검이 잘못된 경로를 사용하거나 잘못된 응답 코드를 예상하여 정상적인 백엔드 인스턴스를 사용할 수 없는 것으로 표시할 수 있습니다.
6. 프록시 또는 upstream 구성 문제 — reverse proxy, CDN 또는 upstream 서비스가 애플리케이션에 요청이 도달하기 전에 503을 생성할 수 있습니다.

해결 방법

1. 503을 생성한 계층 식별

응답 헤더를 확인하고 애플리케이션, 웹 서버, reverse proxy, CDN 또는 WAF, load balancer의 로그를 서로 비교하세요. 응답이 애플리케이션에서 생성되었는지, 아니면 요청이 애플리케이션에 도달하기 전에 생성되었는지 확인합니다. 이렇게 하면 차단 계층이 다른 곳에 있는데 애플리케이션 설정을 변경하는 일을 방지할 수 있습니다.

2. 장애 발생 시점의 리소스 사용량 확인

CPU, 메모리, 활성 연결, 웹 서버 워커, 해당하는 경우 PHP-FPM 워커 및 데이터베이스 연결을 검토하세요. top 또는 htop 같은 읽기 전용 모니터링 도구, 호스팅 대시보드 및 인프라 모니터링을 사용하여 한도에 도달했는지 확인합니다.

• 리소스가 한도에 가까웠다면 장애를 과부하 또는 용량 문제로 처리하세요.
• 리소스 사용량이 정상이었다면 유지 관리 상태, 종속 서비스, rate limit, WAF 규칙 및 상태 점검을 조사하세요.

3. 불완전한 유지 관리 상태 해제

WordPress의 경우 업데이트가 완료되었거나 사이트가 유지 관리 상태로 전환될 권한이 있는지 확인한 다음, SFTP로 연결하여 사이트 루트에 .maintenance라는 파일이 있는지 확인하세요. 업데이트가 완료되었는데 이 파일이 남아 있다면 파일을 삭제한 후 사이트를 다시 테스트하세요. 파일을 삭제하면 사이트의 유지 관리 상태가 변경되므로 활성 업데이트 또는 배포 중에는 삭제하지 마세요.

다른 플랫폼과 배포 도구는 플래그 파일 또는 환경 변수를 사용할 수 있습니다. 업데이트 또는 배포 프로세스를 확인하여 유지 관리 모드를 활성화하는 요소와 프로세스 중단 후 정리 단계가 실행되었는지 파악하세요.

4. 애플리케이션 서버에서 종속 서비스 테스트

데이터베이스, Redis 또는 Memcached 같은 캐시 계층 및 필요한 내부 서비스가 실행 중이며 애플리케이션 서버에서 접근 가능한지 확인하세요. 연결 오류, 인증 실패, 타임아웃 및 서비스 로그 항목을 확인합니다.

종속 서비스가 전반적으로는 정상 작동하더라도 네트워크 접근, 자격 증명, 라우팅 또는 서비스 수준의 장애로 인해 특정 애플리케이션 호스트에서 접근할 수 없을 수 있습니다.

5. 실제 과부하 해결

설정을 늘리기 전에 한도를 초과한 리소스를 식별하세요. 병목은 CPU, 메모리, 데이터베이스 연결, 웹 서버 연결 또는 PHP-FPM 워커일 수 있습니다.

단기적으로는 비용이 큰 작업을 줄이고, 호스트에 충분한 여유 용량이 있으며 변경 권한이 있는 경우에만 한도를 늘리거나, 적합한 페이지에 캐시를 추가하세요. 반복적으로 발생하는 요청량에는 한도를 계속 높이기보다 CDN 또는 캐시 계층과 추가 백엔드 용량을 고려하세요.

6. rate limit, WAF 규칙 및 load balancer 상태 점검 확인

Nginx, Apache, CDN 또는 기타 프록시 및 보안 로그에서 의도적으로 503 응답을 반환하는 규칙을 검토하세요. 상태 점검 경로, 예상 상태 코드 및 백엔드 등록 상태를 확인합니다. 특정 URL, 클라이언트 또는 백엔드에서만 실패한다면 이 정보로 전체 사이트 장애와 트래픽 제어 또는 라우팅 문제를 구분할 수 있습니다.

7. 수정 사항 검증

실패했던 요청을 다시 실행하고 애플리케이션, 프록시 및 종속 서비스 로그를 확인하세요. 정상적인 요청이 성공하는지 확인하고, 가능하다면 비슷한 트래픽 수준이나 시간대에서 테스트하세요. 일시적인 증상만 해소하는 것이 아니라 장애를 유발한 조건 자체를 해결했는지 확인합니다.

예방 및 해결 확인 방법

• 배포 및 업데이트 스크립트가 부분적인 실패 후에도 cleanup 또는 finally 단계에서 유지 관리 플래그를 제거하도록 하세요.
• CPU, 메모리, 활성 연결, 워커 사용량 및 데이터베이스 연결을 모니터링하고 용량이 고갈되기 전에 알림을 설정하세요.
• 적합한 페이지와 데이터베이스 작업을 캐시하여 트래픽 급증 시 백엔드 용량을 덜 사용하도록 하세요.
• 올바른 경로와 예상 응답 코드를 기준으로 load balancer 상태 점검을 테스트하세요.
• rate-limit 및 WAF 변경 사항을 검토하여 의도적인 503 응답과 서비스 장애를 구분할 수 있도록 하세요.
• 장애를 상호 연관 지어 분석할 수 있도록 동일한 시간 범위의 애플리케이션, 프록시, 종속 서비스 및 인프라 로그를 보관하세요.
• 수정 후에는 원래 오류를 유발한 조건과 유사한 환경에서 사이트를 검증하세요.

자주 묻는 질문