개요
2025년 11월 18일 오후 8시경, Cloudflare에서 전세계적으로 장애가 발생했습니다. Spotify, ChatGPT와 같이 Cloudflare를 사용중이던 서비스들은 사용이 불가능했고, 디도스 방어를 위해 Cloudflare를 사용중이던 하이스코어 역시 api 요청을 할 수 없어 사용이 불가능해졌습니다.
1차 대응
처음에는 금방 복구될것 이라고 생각했습니다. 그래서 임시로 앱 실행시 노출되는 업데이트 알림 다이얼로그를 이용해서 Cloudflare 장애 사실을 띄우도록 설정하고 복구를 기다렸습니다. 그러나 Cloudflare는 1시간이 지나도 복구가 되지 않았습니다. 여기서부터 식은땀이 나기 시작했습니다. 업데이트 알림 다이얼로그 데이터도 결국 서버에서 가져오는건데, 시간이 지날수록 간단한 데이터도 가져오지 못해서 앱이 아무것도 뜨지 않고 타임아웃으로 먹통이 되는 일이 많아졌습니다.
2차 대응
오후 9시경, 급한대로 도메인의 네임서버를 Oralce Cloud DNS로 설정해서 Cloudflare를 경유하지 않게 만들어 급한 불을 끄고, 복구가 되면 다시 복구시키려고 했습니다. 그러다 문득 앞으로도 이런식으로 외부 서비스 장애에 의해 내 서비스가 먹통이 되면 어떡하지 라는 생각이 들었고, 이런 가능성을 최소화 하기위해 Cloudflare 의존성을 완전히 제거하기로 결정했습니다.
디도스 방어 문제 해결하기
그러나 Cloudflare를 무턱대고 제거하기엔 큰 문제가 있었습니다. Cloudflare는 디도스에 대한 방어를 기본적으로 제공합니다. 그런데 Cloudflare를 제거하면 디도스를 방어해주던 방파제가 사라집니다. 때문에 어떻게 해야 Oracle Cloud 서비스 만으로 디도스 방어가 가능한지 조사했습니다.
Oracle Web Application Firewal(WAF)
열심히 검색해본 결과, WAF라는 서비스를 찾았습니다.
WAF는 HTTP/HTTPS 트래픽을 모니터링해서 SQL 인젝션, XSS와 같은 웹 공격에 대해 방어하는 서비스입니다.
여러 규칙을 설정해두면 설정해둔 규칙에 따라 요청을 거절하거나 일정 시간 차단하는것도 가능합니다.
서버까지 요청이 전달되지 않고 WAF에서 먼저 걸러지기 때문에, 비정상적인 요청이 서버까지 전달되어 문제가 생기는걸 방어해줍니다.
저는 WAF의 많은 규칙중 반복적인 요청 차단을 설정했습니다.
여러 다른 설정들이 있기는 했는데, 정확히 어떤걸 방어하는 옵션인지 자세히 알지 못해서 다 켜놓지는 못했습니다.
나중에 시간되면 옵션 하나하나 살펴보고 설정할 예정입니다.
서버 ip 숨기기
Cloudflare를 제거함으로써 발생하는 두 번째 문제는 서버 ip 노출이었습니다. 기존에는 Cloudflare의 프록시 설정을 통해 도메인의 ip는 Cloudflare에서 사용하는 공개 ip중 하나로 나왔습니다. 그러나 Cloudflare를 제거하고 DNS를 직접 설정하면 서버의 ip가 그대로 노출됩니다. 저는 이 문제를 해결하기 위해 Oracle Load Balancer를 사용했습니다.
Oracle Load Balancer
로드밸런서는 트래픽을 여러 서버에 고르게 분산시켜주는 서비스입니다. 그래서 원래는 개념만 알고있고 한번도 사용을 안해봤는데, 로드밸런서는 자체적인 퍼블릭 ip를 가지고 내부적으로 분배한다는 사실을 이용해서 서버 ip를 감추는데 사용해 보고자 사용하게 되었습니다. 이로써 도메인의 ip는 로드밸런서를 가르키고, 서버의 ip는 외부에 노출하지 않게 되었습니다.
후기
이렇게 WAF와 로드밸런서를 이용해서 Cloudflare에서 사용하던 기능들을 직접 구현하고 Cloudflare를 완전히 제거하는데 성공했습니다. 이번 장애로 인해 지나친 외부 서비스 의존은 예측 불가능한 서버 장애 확률을 높일 수 있다는 교훈을 얻게 되었고, 앞으로도 서버는 이런 방식으로 구축할 것 같습니다.