만족
[CDN] 클라우드플레어의 느린 속도와 반쪽짜리 보안 본문
[CDN] 클라우드플레어의 느린 속도와 반쪽짜리 보안
Backend/이론 Satisfaction 2021. 9. 5. 19:15
이것은 클라우드플레어의 프록싱이 켜진 상태에서 네트워크 정보를 시각화한 것이다.
클라우드플레어의 프록싱 기능을 사용하면,
인증서 설치 없이 https를 사용하거나 캐싱 등의 기능을 사용할 수 있지만
위에서 본 것 처럼 TTFB가 심하게 치솟는다.
이참에 웹 페이지 제공 서버와 리소스 전용 서버를 제외하고(이 경우 cdn을 이용했을 때 얻어지는 캐싱 효과가 더 크다고 판단했다)
나머지(api 서버 등)는 전부 자체 ssl을 사용하고 프록싱 기능은 꺼버렸다.
왜 일부 서비스에서 cloudflare cdn을 사용하지 않기로 했는지 작성할 것이다.
TTFB가 늘어지는 이유가 뭘까
많은 블로그에서 찾아볼 수 있듯이 한국 망 사용료 관련 문제로 인해 무료 계정을 사용하면 외국에 있는 cdn으로부터 컨텐츠를 받아온다.
https://ryush00.tistory.com/448
만약 cdn서버가 한국에 있다면 위와 같은 구조로 되어 있더라도,
물리적으로 가까운 거리에 있기 때문에 "캐시 미스"가 발생해도 걸리는 시간은 크게 차이가 없다.
그러나 한국은 외국의 cdn을 사용해야 하기 때문에 아래 그림과 같은 일이 발생한다.
일단 해외로 나가게 되면 물리적인 거리 자체가 매우 멀어지게 된다.
예를 들어 선택된 cdn이 미국에 있는 서버라면,
서비스 이용자의 요청이 미국에 갔다가
cdn에서 "캐시 미스"가 발생하면 다시 cdn에서 한국으로 요청을 보내고
서비스 서버는 한국에서 미국으로 응답을 보냈다가
마지막으로 cdn이 서비스 이용자에게 최종적으로 컨텐츠를 보낸다.
(만약 캐시 바이패스 기능을 사용한다면 이 과정이 항상 일어난다)
정리하자면 최악의 경우 "한국(CDN에 요청)-> 미국(캐시 미스)-> 한국(캐시 갱신을 위해 요청)-> 미국(캐시 갱신)-> 한국(응답)" 이라는 괴상망측한 흐름이 되는 것이다.
TTFB는 Time To First Byte의 약자로, 클라이언트가 요청을 보내고 응답을 받기 시작했을 때 까지 걸리는 시간을 말한다.
요청한 작업은 서버에서 처리하는데 10ms도 걸리지 않을 정도로 간단한 응답이라,
대부분의 시간이 외국의 cdn과 통신하는 데 사용된다는 것이다.
게다가 현재 나타나는 126ms는 양호한 수치이다....
특정 시간대가 되면 TTFB가 500ms~700ms까지 쭉 늘어져버린다.
특히 서로 의존성이 있는 요청의 경우(1번 요청에서 응답을 받아야만 2번 요청을 진행할 수 있는 경우)
TTFB가 누적되어 매우 느려진다.
정말 희귀하게 이런 괴랄한 수치도 구경할 수가 있는데 진짜 뒷목잡힌다....
한 번 프록싱 기능을 끄고 속도를 측정해보면 다음과 같은 결과가 나온다.
TTFB의 감소폭이 1/10 이상으로 놀라울 정도로 빨라졌다.
Cloudflare CDN이 첫 번째 바이트를 받을 때 까지 기다리는 동안 얘는 커넥션부터 응답까지 다 끝내고도 150ms가량이 남는다.
이러니 아무리 최적화를 해 봐야 한국에서 태생적으로 문제가 있는 Cloudflare CDN를 사용하는 이상 속도 저하는 해결할 수가 없는 것이다.
당연하게도 더 이상 외국으로 트래픽을 보낼 필요가 없어지므로 이런 속도 향상이 가능했던 것이다.
서비스가 전 세계를 대상으로 한다면 Cloudflare의 CDN을 쓰는 것이 좋겠지만,
그렇지 않다면, 특히 한국을 대상으로 서비스하면서 프리티어 계정을 사용한다면 제거하는것이 훨씬 빠르다.
자동 SSL/TLS 적용: 반쪽짜리 보안
클라우드플레어를 사용하는 사람들 중 나처럼 귀찮은 ssl 인증서 작업을 하지 않기 위한 사용자들도 꽤 있을 것이다.
부끄럽게도 아직까지 ssl설치를 직접 해 본적이 없으며, 필요할 경우 cloudflare의 ssl/tls 기능을 사용해 땜빵하곤 했었다.
인증서를 설치하지 않고 cloudflare에서 제공하는 ssl서비스를 이용하게 되면
위와 같이 "가변" 탭을 사용할텐데 이 경우엔
클라이언트와 cloudflare간 통신은 암호화되지만 cloudflare와 원본 서버(내 서버)의 통신은 평문으로 이루어진다.
따라서 보안상으로도 좋지 않은 방법이다.
프록싱기능을 끄게 되면(DNS only) 이 기능도 사용할 수 없게 되는데
이 참에 함께 진행하여 보안성도 확보하였다.
-> 사실 이건 일부러 이렇게 하기도 한다
-> 어차피 사용자와 서버가 통신할 때 보안이 중요한 것이므로 https를 사용하는데
-> 프록시 <-> 원본 서버끼리도 https를 사용하면 양 측에서 데이터에 대한 추가 암/복호화가 필요하므로 부하가 커진다
클라우드플레어 CDN은 무조건 사용하면 안되는가?
그건 아니다.
일단 클라우드플레어 CDN의 서울리전이 존재하긴 한다.
다만 망사용료 문제로 유료 사용자만 사용할 수 있으며,
Under Attack 모드, 캐싱 등 유용한 기능을 많이 제공한다.
클라우드플레어 CDN은 다음 사용자에게 유용하다.
1. 귀찮은 작업을 생략하고 빠르게 서비스를 출시해야 하는 경우
2. 디도스 등 공격을 자주 받는 경우
3. 다국적 서비스를 하는 경우
4. 유료 사용자의 경우
5. 서버에 가해지는 트래픽 양이 과도하여 CDN이 필요한 경우
반대로 다음 사용자에게는 불리하다.
1. 중소규모 서비스를 운영하는 경우
2. 한국 사용자가 많으며, 무료 사용자의 경우
3. 각각의 역할(SSL, CDN 등)의 역할을 잘 모르고 그냥 사용하는 경우 (이 경우 실력 향상에도 좋지 않다)
다음 포스트에서는 아파치 서버에 ssl인증서를 설치하고 사용하는 방법에 대해 알아볼 것이다.
https://satisfactoryplace.tistory.com/309