개요

CloudFront를 사용하여 문제를 해결하는 방법을 이해하면 운영자와 SRE는 웹 애플리케이션의 다른 부분(CloudFront, 엣지 함수 또는 오리진)에서 발생할 수 있는 오류를 신속하게 해결할 수 있습니다. 이러한 오류로는 오리진이 과부하로 인해 5xx 오류를 반환하는 경우, CloudFront가 오리진에 연결할 수 없는 경우, 코드에서 처리되지 않은 예외가 발생하여 Lambda@Edge 실행이 실패한 경우 등이 있습니다.

오리진에 대한 사용자의 요청 추적

CloudFront는 처리하는 모든 요청에 대해 고유한 요청 ID를 생성합니다. 요청이 애플리케이션 스택을 통과할 때 해당 ID를 사용하여 요청을 추적하는 것이 좋습니다.

  • CloudFront는 HTTP 요청에 대한 응답을 반환할 때 요청 ID가 포함된 x-amz-cf-id 헤더를 추가합니다.
  • CloudFront는 액세스 로그의 요청에 대해 생성된 로그 레코드의 x-edge-request-id 필드에 요청 ID를 포함합니다. AWS WAF WebACL이 CloudFront 배포에 연결된 경우 WAF는 WAF 로그의 요청에 대해 생성된 로그 레코드의 requestId 필드에 요청 ID를 포함합니다. 예를 들어 OLX는 Slack의 고객 지원 엔지니어가 매일 WAF 로그의 rquest-ID로 특정 요청을 쿼리하여 차단된 이유를 파악한 다음 고객 티켓에 더 빠르게 응답하는 데 사용할 수 있는 채팅 봇을 구축했습니다.
  • CloudFront 배포에 엣지 함수가 구성된 경우 (CloudFront Functions 및 Lambda@Edge) 모두에 대해 이벤트 객체의 requestId 필드에 있는 함수에 요청 ID가 제공됩니다.
  • 캐시 미스(cache miss) 시 CloudFront는 요청을 오리진에 전달할 때 요청 ID 값과 함께 x-amz-cf-id 헤더를 요청에 추가합니다. 오리진 서버에 이 헤더를 로그하는 것이 좋습니다.

CloudFront를 사용하여 오류 문제 해결

모니터링 시스템(예: CloudWatch 경보)에서 4xx 또는 5xx 오류로 인한 응답 증가를 감지하면 오류 유형과 발생 위치를 자세히 분석하여 문제를 해결해야 합니다.

이를 위해서는 CloudFront의 액세스 로그를 필터링하여 오류 코드를 생성하고x-edge-result-type, x-edge-response-result-type, x-edge-detailed-result-type 로그 필드를 확인하여 문제를 더 잘 이해할 수 있도록 해야 합니다. 액세스 로그 분석은 로그를 어디에 저장하느냐에 따라 달라집니다. 매우 간단한 접근 방식은 표준 SQL 쿼리와 함께 Athena를 사용하여 S3에 저장된 로그를 쿼리하는 것입니다. 예를 들어, 다음 SQL 쿼리는 처음 100개 레코드로 제한된 특정 날짜 범위의 5xx 오류에 대한 로그를 필터링합니다.

SELECT * AS count FROM cloudfront_logs
WHERE status >= 500 AND "date" BETWEEN DATE '2022-06-09' AND DATE '2022-06-10'
LIMIT 100;


경우에 따라 WAF 또는 CloudFront의 로그를 통해 추가 문제 해결 정보를 확인할 수 있습니다. 예를 들어 AWS WAF 로그는 특정 요청이 차단된 이유를 설명할 수 있습니다. 또 다른 예는 CloudWatch Logs의 엣지 함수 로그를 확인하여 5xx를 초래한 실행 오류를 파악하는 것입니다. 마지막으로, CloudFront 캐시에서 오류 응답이 반환되는 시점과 그렇지 않은 시점을 알기 위해 CloudFront에서 오류를 캐싱하는 방법을 이해하는 것이 좋습니다.

CloudFront를 사용하여 지연 시간 문제 해결

모니터링 시스템(예: 오리진 지연 시간 및 캐시 적중률 지표에 대한 CloudWatch 경보)이 응답 지연 시간의 증가를 감지하면 지연 시간 병목 현상이 어디에 있는지 파악하여 이를 해결해야 합니다. 이를 위해 CloudFront의 액세스 로그의 지연 시간 필드를 분석하는 것을 고려해 보세요. 다음 필드를 검토하세요.

  • time-to-first-byte: CloudFront와 최종 사용자 간의 첫 번째 바이트 지연 시간(표준 로그 및 실시간 로그에서 확인 가능)
  • time-taken: CloudFront와 최종 사용자 간의 마지막 바이트 지연 시간(표준 로그 및 실시간 로그에서 확인 가능)
  • origin-fbl: CloudFront와 오리진 간의 첫 번째 바이트 지연 시간(실시간 로그에서 확인 가능)
  • origin-lbl: CloudFront와 오리진 간의 마지막 바이트 지연 시간(실시간 로그에서 확인 가능)

URL 또는 국가와 같은 관련 차원 중 하나로 SQL 쿼리를 그룹화하여 이러한 필드를 분석할 수 있습니다. 이를 통해 지연 시간 문제의 범위를 좁힐 수 있습니다. 또한 응답 헤더 정책에 구성된 경우 CloudFront의 서버 타이밍 헤더를 사용하여 클라이언트 측에서 동일한 정보를 찾을 수 있습니다. 아래 서버 타이밍 헤더는 내 요청이 마르세유의 MRS52-P1 pop에 대해 캐시 적중했으며 다운스트림 첫 번째 바이트 지연 시간이 64밀리초임을 설명합니다. 참고로 CloudFront에서 생성된 Age 헤더는 이 콘텐츠가 61초 이후 오리진에서 가져오거나 새로 고쳐졌음을 설명합니다.

CloudWatch RUM을 사용하여 웹 성능 문제 해결

CloudWatch RUM을 사용하면 Javascript 태그를 웹 페이지에 통합하여 클라이언트 측에서 애플리케이션을 모니터링할 수 있습니다. Javascript는 연결 단계 분석(DNS 조회, TCP 연결 등) 또는 Google Core Web Vitals(LCP, FID 등..)을 포함한 페이지 로드 시간과 같은 브라우저 API에서 데이터를 수집한 다음 대시보드 작성을 위해 CloudWatch RUM으로 전송합니다. 브라우저 유형, 사용자 국가 또는 특정 페이지 ID와 같은 특정 차원을 기준으로 필터링하여 애플리케이션 성능을 분석할 수 있습니다.

AWS Support 지원 요청

오류나 지연 문제를 추가로 해결하려면 AWS Support의 지원이 필요한 시나리오에서는 느린 요청이나 오류를 초래한 요청에 해당하는 CloudFront 요청 ID 목록이 포함된 지원 티켓을 엽니다. 지원 엔지니어는 제공된 요청 ID를 사용하여 내부 로그를 자세히 살펴보고 문제를 더 잘 이해하고 해결 방법에 대한 권장 사항을 제공할 수 있습니다.

Amazon CloudWatch 기반 실제 사용자 모니터링

리소스

이 페이지의 내용이 도움이 되었나요?

 피드백