CloudFlare Pages 소개

CloudFlare Pages는 초기 출시 때부터 사용했었는데 혼자만 잘 쓰기엔 너무 좋아서 소개해보려고 합니다.

 

Netlify, Vercel 등을 써봤지만 앞으로의 경쟁에서 이 회사들은 CloudFlare Pages를 이길 수 없을 것 같습니다.

CloudFlare Pages

 

Netlify와 Vercel은 트래픽 100GB를 제공하지만 CloudFlare Pages는 무료 계정에서 약관을 위반하지 않는 이상 트래픽이 무제한이고 프로젝트 수도 제한이 없고 빌드수는 월간 500개 제한이 있습니다.

다른 서비스와 비교했을 때 트래픽이 가장 크고, 서버리스 제공량 부분이 그 다음으로 클 것 같습니다.

 

아무래도 2년 안에 이 분야(흔히 Jamstack이라고 불리는)에서 점유율을 거의 다 가져갈 수 있지 않을까 생각됩니다.

 

 

CloudFlare Pages 초기버전의 문제점 (해결됨)

초기버전에서는 잘 활용하지 않았는데, 이유를 나열해보자면 크게 4가지가 있었습니다.

1. 느린 빌드 시간
2. 클라우드 플레어 엣지 위치
3. 자체 서버리스 functions가 없었음
4. * 처리 버그

 

느린 빌드 시간 (해결됨)

CloudFlare Pages 초기에는 빌드 시간이 빌드할 대상이 없는 경우에도 1분~3분이 소요되었습니다.

Netlify와 Vercel의 10초 이내 빌드와는 매우 큰 차이가 있었는데..

 

2022년쯤부터 10초 정도로 빌드되는 fast build beta가 나왔고,

며칠 전인 4월 1일에 완전히 빠른 빌드로 이전되어 10초 정도로 전 세계 클라우드플레어 엣지에 배포가 됩니다.

(이제는 느린 빌드 문제가 해결되었습니다.)

 

 

클라우드 플레어 엣지 위치 (해결됨)

초기버전에서는 엣지가 미국(LAX)엣지를 줬고 타 서비스의 서버리스 functions 같은 서비스도 없었기 때문에 미국에 있는 서버에 클플을 연결해서 쓰는 게 훨씬 좋았었는데.

(기능면에서 서버를 활용하는 게 좋았고, 속도면에서는 차이가 없었기 때문에)

 

현재는 한국과 가까운 리전에서 처리를 하기 때문에 활용할 가치가 높아졌습니다.

 

블로그 같은 정적 웹, 기존에 사용하던 방식에서 API부분만 분리하고 웹 부분을 클라우드 플레어 pages에 의존해도 될 정도라고 생각됩니다.

 

 

자체 서버리스 functions가 없었음 (해결됨)

클라우드 플레어에는 Workers라는 엣지에서 실행 가능한 서버리스 기능이 있는데

초기 페이지스에서 제공하지 않았기 때문에 활용도가 많이 떨어졌었습니다.

 

지금은 배포 루트에 있는 functions 폴더에 위치한 소스를 실행 가능합니다.

 

다만, 워커에는 있는 console.log를 기록할 수 있는 기능이 없다는 게 아직 차이점이자 남아있는 단점 같습니다.

또한 현재는 번들링이 안 되는 게 단점입니다. (앞으로는 되겠죠)

 

 

* 처리 버그 (해결됨)

*으로 여러 문자에 매칭 할 수 있는데, 이 규칙이 특이하게 아래와 같이 매칭이 안되었습니다.

/*.js
	Access-Control-Allow-Origin: *

이 경우 루트에 있는 /script.js 나 /a.js 등 모두 적용되지 않았었는데 현재는 고쳐진 문제입니다.

 

 

제한(Limits)

현재 제한을 두고있는건 아래와 같습니다.

• 빌드 시간: 빌드 당 최대 20분
• 커스텀 도메인 연결: 10개
• 파일 총 개수: 20,000개
• 파일당 최대 용량: 25MiB (2^20바이트)
• 헤더 룰: 100개
• 리다이렉트 룰: 100개
• 사이트 수: 계정에 개수 제한이 없지만 너무 많은 생성 시 제한이 걸릴 수 있으며 해제 요청 필요

 

 

헤더 설정법

헤더는 프로젝트 루트가 아닌 빌드 위치에 _headers 파일로 지정 가능합니다.

# This is a comment
/secure/page
  X-Frame-Options: DENY
  X-Content-Type-Options: nosniff
  Referrer-Policy: no-referrer

/static/*
  Access-Control-Allow-Origin: *
  X-Robots-Tag: nosnippet

https://myproject.pages.dev/*
  X-Robots-Tag: noindex

클라우드 플레어의 예제는 위와 같은데

 

#으로 주석 처리를 할 수 있고

주소를 적고, 아래에 탭(Tab)으로 {헤더 이름}: {헤더 값}으로 지정하면 된다.

 

*으로 여러 문자에 매칭 할 수 있는데

/*.js
	Access-Control-Allow-Origin: *

이 경우 루트에 있는 '/script.js', '/a.js', '/test/script.js' 등에 적용된다. (칠한 부분이 *에 매칭한 부분이다.)

 

*로 구분하는 경우 아래와 같은 규칙도 적용 가능하다.

/*/script.js
	Access-Control-Allow-Origin: *

/test/script.js 또는 /test/test2/test3/script.js 등 에 적용됩니다.

 

* 은 / 를 포함해서 깊이에 상관없이 매칭이 됩니다.

 

*으로 매칭하면 a/b/c/d 도 매칭이 되는데 폴더 깊이를 제한하고 싶다면 :변수 형태로 작성하면 됩니다.

/:test/script.js
	Access-Control-Allow-Origin: *

이 값은 아래의 주소 등에 매칭됩니다.

• /test/script.js
• /a/script.js
• /abcd/script.js

그러나 /a/b/c/script.js 에는 매칭되지 않습니다.

/:test1/:test2/:test3/script.js
	Access-Control-Allow-Origin: *

위 경우에는 변수를 3번 써서 매칭하거나, *을 통해 깊이와 상관없이 매칭하는등의 방법이 있겠습니다.

 

 

리다이렉트 설정법

리다이렉트도 설정 파일은 index.html이 위치하는 빌드 위치에 _redirects 파일에 정의할 수 있습니다.

여기의 매칭 규칙도 위의 헤더 파일과 비슷합니다. (*과 :변수 사용 방법이 동일)

[접속주소] [리다이렉트할 주소] [code?]

간단하게 접속했을 때, 어디로 보낼지 한 줄에 한 개씩 적으면 됩니다.

 

마찬가지로 *을 사용할 수 있습니다. *에 해당하는 값에는 :splat으로 매칭 가능합니다.

Netlify, Vercel과의 차이가 있다면, 리다이렉트만 지원하고 프록시 방식은 지원하지 않습니다.

 

/home301 / 301 #http301 영구 이전
/home302 / 302 #http302 임시 이전
/querystrings /?query=string 301
/twitch https://twitch.tv
/trailing /trailing/ 301
/notrailing/ /nottrailing 301
/blog/* https://blog.my.domain/:splat # *에 해당한 부분을 :splat으로 매칭시켜 이전
/products/:code/:name /products?code=:code&name=:name #:code, :name으로 들어온 값을 쿼리스트링 안으로

위 예제는 클라우드 플레어에서 제공하는 예제입니다.

 

페이지스에서는 프록시 방식을 지원하지 않기 때문에 맨 아래 예제는 굳이 이용할 필요가 없을 것 같습니다.

당연하게도 리다이렉트 될 주소로 직접 요청하는 게 더 좋습니다.

 

 

맺음말

아무래도 Netlify와 같은 다른 서비스에서는 제공하는 기능이 많습니다. 이걸 통해서 고객을 묶어둘 수 있을 겁니다.

 

저는 따로 의존한 부분이 없어 CloudFlare Pages를 쓰는데 문제가 없었고요.

아무래도 이런 부가기능을 많이 사용한 경우 옮기기에는 어려움이 있을 겁니다.

근데 다른 곳에 의존하지 않는 정적 웹 사이트는 옮기지 않을 이유가 없을 것 같습니다.

 

블로그도 일부 기능(댓글, 검색 등)만 별도 API로 만들어 처리하면 처리 양이 매우 줄을 것이고

API로 기능을 분리할 수 있는 사이트의 경우에도 마찬가지일 것으로 생각됩니다.

 

저는 이걸 써보면서 너무 좋아서 조금 시간을 들여 CloudFlare Pages와 연계해서 쉽게 빌드하여 사용할 수 있는 로컬 빌드 방식을 따로 설계해서 제작해서 쓰고 있습니다.

로컬에서 변경사항을 바로 빌드하고 git push 해서 배포까지 바로 가능하도록 제작해서 활용 중입니다.

기능을 덧붙여서 CMS형태로 더 편하고 + 코드를 직접 안 만져도 될 정도로 만들까는 고민중입니다.

Cloudflare Pages