클라우드플레어는 플랜들의 한계에 대해서 절대로 정확하게 설명하지 않습니다.
그냥 프리 플랜조차도 어떠한 차별도 없으며 기능상의 차이만 있다는
절대 못믿을 소리만 반복해대죠.
심지어는 플랜별 웹소켓 연결 가능 갯수같은 것조차도 알려주질 않으니
실사용량 측정 및 계획에 의존한 플랜 선택이 참 어렵습니다.
다만 그동안 검색해본 바에 따르면 플랜에서 한계를 결정하는 요소가 있기는 합니다.
플랜에 따라 딱히 캐쉬 우선 순위나 대역폭 점유율 같은 것에는 차이가 없지만
concurrent connection의 갯수에 limit가 있다고 답변한 경우를 2개 찾을 수 있습니다.
이 커넥션이 브라우저<->클플간의 커넥션인지 아니면 클플<->서버간 커넥션인지는
정확히 알 수 없지만 하여튼 클플은 순간적인 커넥션 갯수의 피크가 한계를
넘지 않는 이상 그외의 요소로는 딱히 제재를 하지 않는다는걸 알 수 있습니다.
아마 이미 캐쉬된 정적 파일을 단순 다운로드하는 브라우저<->클플간 커넥션을
구지 카운트할 것 같진 않구요..
클플<->서버간 커넥션 갯수가 핵심일거라고 전 추측합니다.
이렇게 추측하는 이유는 이렇습니다.
클플은 HTTP/2를 지원합니다. HTTP/2로 접속하는 경우 물리적인 커넥션은
딱 하나뿐입니다. 그러나 모든 사용자가 다 HTTP/2를 사용하는건 아닙니다.
그냥 HTTP로 접속할 수도 있고 이 경우엔 커넥션이 다수 생성됩니다.
즉 브라우저<->클플간의 커넥션 갯수는 굉장히 가변적인 것입니다.
경우에 따라 커넥션 갯수 차이가 굉장히 크기 때문에 기준을 정하기가 애매할 것입니다.
또한 실제 서버에 주는 부하를 생각해봐도 그렇습니다.
보통 웹서버 셋팅하실때 정적파일 부담은 별로 고려 안하잖아요.
PHP가 동시에 몇개 실행될 수 있는가가 서버 최적화의 기본이듯이
클플도 비슷하지 않을까 생각합니다.
그렇다면 클플<->서버간 커넥션에 한계가 있다는 가정하에
정적파일 로딩을 위한 커넥션들은 상수로 두고
클플에 캐쉬되지 않고 바이패스되는 동적 페이지들에 대한 동시 호출 갯수가
실질적으로 플랜의 한계를 결정짓는게 아닐까 합니다.
제 추측이 올바르다면 클플을 경유하는 동적 페이지 호출은 최소화하고
클플을 단지 정적 파일들의 캐쉬 용도로만 쓴다면 프리플랜이라 할지라도
굉장히 한계가 높을거라고 생각합니다.
반대로 동적 페이지를 일일이 클플 경유해서 호출하고 그 숫자가 많은 경우
사용 트래픽이 얼마 되지 않더라도 플랜 한계에 도달할거구요.
이 추측은 제 사이트 운영으로 앞으로 테스트해보도록 하겠습니다.
