클라우드플레어, 웹 요청 경로 추적 기능 베타 공개…외부 추적 정보 기본 거부

클라우드플레어가 2일 웹 요청이 자사 네트워크를 지나는 과정을 한 화면에서 살펴보는 ‘Cloudflare Traces’를 공개 베타로 선보였다. 보안 규칙의 차단 여부부터 주소 변환, 캐시, 워커 실행, 원본 서버 연결까지 지원되는 처리 단계를 기록한다.

차단과 지연이 생긴 지점을 한 경로에서 확인

회사 설명에 따르면 실제 운영 트래픽의 요청마다 지원되는 단계의 처리 시간과 결과를 ‘스팬’으로 남긴다. 운영자는 대시보드에서 한 요청의 경로를 펼쳐 규칙이 요청을 막았는지, 캐시를 건너뛰어 원본 서버로 갔는지 확인할 수 있다. 모든 내부 처리 단계가 기록되는 것은 아니다.

추적은 도메인별로 켠다. 전체 요청 중 기록할 비율을 정하거나 특정 요청에 별도의 비율을 적용할 수 있다. 클라우드플레어 개발 문서는 규칙이 여러 개 맞을 때 처음 일치한 규칙을 적용한다고 설명한다. 따라서 어떤 트래픽을 더 자세히 남길지에 따라 규칙 순서를 점검해야 한다.

외부 요청의 추적 식별자는 기본적으로 수용하지 않아

서로 다른 서비스의 기록을 한 흐름으로 잇는 기능도 제공한다. 클라우드플레어는 W3C의 추적 문맥 형식으로 식별자를 전달하고, 기록을 OpenTelemetry Protocol(OTLP) 목적지로 내보낼 수 있다고 밝혔다. OpenTelemetry 명세는 OTLP를 관측 자료의 전송 규약으로 정의한다. 이 규약을 지원한다는 사실만으로 다른 업체의 운영 도구와 자동 연동된다는 뜻은 아니다.

다만 외부 요청에 실려 온 추적 문맥은 기본 설정에서 거부한다. 클라우드플레어 문서는 이를 받아들일 경우 발신자를 검증하지 않으므로 연결된 추적 기록을 신뢰할 수 없는 자료로 취급하라고 경고한다. 원본 서버로 식별자를 전달해도 서버 쪽에 별도 계측이 없으면 그 서버의 처리 기록이 저절로 만들어지지는 않는다.

이번 공개 범위는 베타다. 회사는 DDoS 규칙 등 더 많은 단계를 자동으로 기록하는 기능과 장기 보관 확대를 후속 계획으로 제시했다. 현재의 지원 범위와 향후 계획, 실제 운영 환경에서의 성능은 구분할 필요가 있다.

출처: https://blog.cloudflare.com/cloudflare-tracing/
개발 문서: https://developers.cloudflare.com/observability/traces/ 및 https://developers.cloudflare.com/observability/traces/configuration/
OTLP 명세: https://opentelemetry.io/docs/specs/otlp/
대표 이미지: AI 생성 이미지 / 데이마크