| r31 vs r32 | ||
|---|---|---|
| ... | ... | |
| 44 | 44 | |
| 45 | 45 | HTTP 5xx 오류가 발생한 것뿐만 아니라, 장애 기간 동안 CDN 응답 지연(latency)도 크게 증가했습니다. 이는 디버깅 및 모니터링 시스템이 많은 CPU를 사용했기 때문인데, 이 시스템들은 잡히지 않은 오류를 자동으로 추가 디버깅 정보와 함께 처리하도록 설계되어 있습니다. |
| 46 | 46 | |
| 47 | '''{{{+5 Cloudflare가 요청을 처리하는 방식과, 오늘 이 과정에서 무엇이 잘못되었는지에 대한 내용.}}}''' | |
| 47 | 48 | |
| 49 | Cloudflare로 들어오는 모든 요청은 네트워크에서 정해진 경로를 거칩니다. 요청은 브라우저에서 웹페이지를 불러오거나, 모바일 앱이 API를 호출하거나, 다른 서비스에서 자동으로 들어오는 트래픽일 수 있습니다. | |
| 48 | 50 | |
| 51 | 이 요청들은 먼저 HTTP와 TLS 계층에서 처리되고, 그다음 핵심 프록시 시스템(“Frontline”, 줄여서 FL)을 통과하며, 필요하면 Pingora를 통해 캐시를 조회하거나 원본 서버에서 데이터를 가져옵니다. | |
| 49 | 52 | |
| 53 | 핵심 프록시가 작동하는 방식에 대해서는 [[https://blog.cloudflare.com/20-percent-internet-upgrade/|여기서]] 이전에 더 자세히 공유한 바 있습니다. | |
| 54 | ||
| 55 | [[파일:클플 오류4.png]] | |
| 56 | ||
| 57 | 요청이 핵심 프록시를 통과하는 동안, Cloudflare는 네트워크에서 제공하는 다양한 보안 및 성능 기능을 실행합니다. 프록시는 각 고객의 고유한 구성과 설정을 적용하며, WAF 규칙 적용, DDoS 방어, 트래픽을 Developer Platform이나 R2로 라우팅하는 작업 등을 수행합니다. 이는 도메인별 모듈을 통해 이루어지며, 모듈이 프록시를 통과하는 트래픽에 구성과 정책 규칙을 적용합니다. | |
| 58 | ||
| 59 | 그 모듈 중 하나인 Bot Management가 오늘 장애의 원인이었습니다. | |
| 50 | 60 | == 에러 상황 == |
| 51 | 61 | {{{#!wiki style="border: 1px solid gray; border-top: 5px solid crimson; padding: 12px" |
| 52 | 62 | '''{{{+1 Cloudflare Global Network experiencing issues}}}''' |
| ... | ... |