CLOUDFLARE 장애로 인한 고찰

 

아니.. 내 사이드 프로젝트가!! 접속이 안돼!

(왼쪽은 서비스 장애 / 오른쪽은 정상적으로 나올 때)

 

무슨 일이야?

•  2025년 11월 18일 오후 쯤에 CLOUDFLARE 장애 소식을 들음
• 나는 사이드 프로젝트로 타로카드 사이트를 운영중인데, CLOUDFLARE의 DNS를 사용중, 접속 에러 발생 확인
• 오후 늦게 뉴스 등장 "클라우드플레어, 글로벌 네트워크 장애 발생...AI·SNS·게임 등 서비스 마비" [링크]
• 다만 나의 경우엔 서버가 집에 있는 미니 PC라서 우회 방법이 아예 없진 않았음, 하지만 지정된 DNS로는 접근이 불가
• 클라우드 서비스라는 단일 인프라의 의존도는 이러한 리스크가 있는듯

클라우드 서비스란?

• 인터넷을 통해 서버, 스토리지, 소프트웨어 등 IT 자원을 필요에 따라 빌려 쓰는 서비스
• 실제 서버는 다른 지역에 있고, 비용을 내면 임대해서 사용
•  대표적으로 아마존의 AWS, Microsoft의 AZURE, GOOGLE의 GCP, CLOUDFARE, NAVER의 NAVER CLOUD PLATFIRM.. (더있지만 일단 대표적인거..)

클라우드 서비스 대신 가능한 방법은?

• 서버를 직접 구매해서 내 사무실에서 운용 (단, 사용자에 따른 네트워크 이슈가 있을수 있고, 서버는 비싸다!)
• 서버를 임대 또는 구매 후 위탁 운영해서 사용 (네트워크 리스크 감소, 가비아 IDC등에 위탁운영, 단 IDC에서 문제 발생시에도 대응 시간이 걸림)

 

리스크가 있어도 클라우드 서비스를 쓰는 이유는?

• 다양한 네트워크, 보안 프로그램이 있음
• 구축 시간이 매우 빠르고, 리소스 확장이 편리 함
• 서버를 구매하는 것보다 가격적인 메리트가 있음
• 2012년 즈음엔 AWS도 전부 영어여서 진입장벽이 있었으나 현재는 관리 기능이 매우 편리함 (이외에도 많은 장점이..)

장애에 따른 보상체계는?

• 장애가 있는 동안에 서비스의 고객이탈이 매출하락과 서비스 이미지가 떨어지는데,  사실 보상이 의미있나 싶긴한데..
• 일단 기본적으로 SLA 기준에 따라서 대응하는 듯.. [참고링크]
• AWS : 월 가동 시간 백분율로 99%이상, 99~95%, 95% 미만으로 구분해서 크레딧을 청구 받음
• 물론 이러한 손해 배상은 천재지변이나 정기점검 등 불가피한 사유가 있는 경우는 제외된다. 또 손해배상은 고객이 직접 청구사유나 청구금액 및 산출근거를 기재해 제출해야 하는 수고가 필요하다.
• CLOUDFLARE : P1~P4 문제에 따라 서비스 크레딧을 받음
• NAVER : 장애보상청구서 작성 후 SLA 기준에 따라 보상기준이 달라짐.

클라우드 서비스 장애에 어떻게 무중단 서비스를 제공해야 할까?

• 다중 클라우드 & 자원 이중화 전략 : 단일 클라우드 업체에 의존하지 않고, 자원을 공유하여 장애 발생시 자동으로 복구 전환할수 있는 서비스를 함께 사용 -> 현실적으로 리소스가 가능할까..? 자체 서버가 있지 않는 한 작은 기업은 쉽지 않을 텐데
• 지속적인 모니터링 : 클라우드 disk 모니터링이나 네트워크 모니터링 로그를 분석 -> 예전에 제니퍼 소프트나 GCP의 disk 모니터링을 봤는데, 서버가 아예 나가버리면 답이 없음

각 클라우드 서비스의 대시보드

(이미지는 AWS의 health 대시보드) AWS : https://health.aws.amazon.com/health/status GCP : https://status.cloud.google.com/?hl=ko NAVER : https://dashboard.worksmobile.com/kr CLOUDFLAE : https://www.cloudflarestatus.com/ 그런데 대시보드 사이트가 다운되는 경우도 있다고 하던데..

개발자로서 대응해야 할 것

• 서버의 접근이 완전 차단된게 아닌, 일반적인 에러 상황이지만.. 대비하면 좋으니까.. 
• 외부 라이브러리등에 대한 의존성 제거 (되도록 프로젝트 소스 내에서 해결)
• 서버에서 에러코드 분류화 및 의미있는 에러메세지와 코드 체계 적립
• 에러메세지에 대한 로그 처리, 모니터링 및 분석 절차 수립
• 프론트에서 에러코드 리턴시 고객이 납들할만한 정보(?) 노출 (default page)

나라면 어떻게 했을까

•  운용중인 서비스와 리소스에 따라 다르게 전략을 세울듯
•  고객이 많고, 리소스가 있다면 다중클라우드 방식을 사용해서, 에러 발생시 모니터링 알람이 오고 복구가 늦어진다 하면 다른 클라우드로 전환 (고객의 이탈이 매출 하락으로 이어지기 때문에 꼼꼼해야 할 듯)
• 고객이 적고, 리소스가 없다면 사실 답이 없을 듯.. 그냥 대기.. ㅠㅠ
  (서버 오류에 대한 고객 보상을 줘야 하나..? 커머스면 (할일)쿠폰, 메세지면 이모티콘등.. 모두 기업 입장에선 지출이고.. 개발자의 영역이 아닌 사업부의 영역이 되는건가)

 

추가 (이번 오류의 실제 원인)

https://blog.cloudflare.com/18-november-2025-outage/ 데이터베이스 시스템(ClickHouse)의 권한 변경이 트리거가 됨. 이로 인해 Bot Management 시스템에서 사용하는 “feature 파일”이 예상보다 두 배 이상 커짐. 이 커진 파일이 네트워크상의 모든 머신에 배포되었고, 그 파일을 읽는 트래픽 라우팅 소프트웨어에 크기 초과 오류(limit exceeded) 가 발생 → 결과적으로 HTTP 5xx 에러가 다수 나옴. 처음엔 DDoS 공격인 줄로 오인함 → 나중에 내부 구성 변경이 원인이라는 것이 확인됨.

 

 

이번일은 휴먼에러지만.. 완벽하게 해결하는 방법은 없는 걸까..