사용자 도구

사이트 도구


사이드바

blog:using-cloudflare

클라우드플레어 사용기

이 웹사이트에 클라우드플레어를 사용하고 있습니다. 여기에는 두 가지 목표가 있습니다. 하나는 비용을 최소화한 호스팅 서비스를 사용해 CPU나 동시 IO 수에 제한이 있지만 그럭저럭 사이트를 서비스하는 겁니다. 다른 하나는 웹 기술에 대한 지식이 별로 없어도 기본적인 수준의 보안을 갖추는 것입니다.

배경

오래 전부터 개인 웹사이트를 가지고 있었습니다. HTML을 FTP를 통해 서버에 올려 사이트를 만들던 시대에서 시작해 몇 가지 블로그 도구를 전전하다가 한동안은 텀블러에 도메인을 붙여 사용하다가 또 한동안은 S31)에 스태틱 페이지 제너레이터2)로 만든 페이지를 올려 사용하다가 원활한 운영을 위해서는 페이지 제너레이터가 서버에 붙어있어야 한다는 교훈을 얻은 뒤 사이드메뉴를 포함해 거의 모든 페이지를 웹에서 직접 만들어낼 수 있는 위키3) 시스템에 정착하고 다시 몇 년이 흘렀습니다. 처음 몇 년 동안에는 호스팅 비용이 비싼 시대여서 웹사이트를 운영하려면 어느 정도 비용을 지출해야 한다는 인식이 있었지만 시간이 흐르면서 호스팅을 받아가며 별볼일없는 개인 웹사이트를 운영하는데 돈을 꽤 내는 것이 과연 옳은가 하는 의구심이 들기 시작했고 언젠가 공개된 논문을 읽으러 들어간 한 교수님의 웹사이트가 드랍박스4)에 올려진 HTML파일인 것에 충격을 받아 저런 분도 드랍박스를 통해 사이트를 운영하는데 고작 내가 돈을 낭비할 의미가 있는가 하는 생각을 하기에 이르렀습니다. 참고로 언제부턴가 드랍박스는 HTML 렌더링을 중단해 더이상 저런 방법으로 웹사이트를 운영할 수 없긴 합니다만. 여튼 그때를 계기로 위키를 사용하고는 싶지만 비용은 최소화하려고 방법을 궁리하기 시작했습니다.

웹 기술에 대한 지식이 거의 없고 할 줄 아는 거라곤 호스팅 서비스에 위키를 인스톨하고 글 쓰는 정도인 사람 입장에서 비용을 줄일 수 있는 방법 역시 뾰족한 것은 아니었습니다. 그냥 호스팅 서비스를 가장 싼걸로 바꿨습니다. 한달에 3000원 좀 안되는 돈을 내면 어처구니없는 제한이 붙은 호스팅 서비스를 사용할 수 있었습니다. 비용을 더 낮추기에는 이미 사이트가 요구하는 스토리지 크기가 제법 커져서 저 정도가 한계가 아닐까 싶습니다.

다만 여기서부터 문제가 생겼는데 워낙 싼 호스팅을 사용하다 보니 이미지를 처리하는데 부하가 컸습니다. 아이폰에서 찍은 이미지 여러 장이 들어있는 페이지를 몇 개 로딩하다 보면 사이트 전체가 버벅거렸고 호스팅 회사로부터 리소스 제한을 초과했다는 메일을 받기 일쑤였습니다. 이를 어쩔까 고민하다가 몇 년 전에 클라우드플레어5)라는 CDN 서비스가 있다는걸 알게됐습니다. 일단 무료로 사용해볼 수 있다길래 덥썩 시도해봤습니다. 회사에 속하지 않은 개인 사이트를 운영하는 장점 중 하나는 관심있는 서비스를 별 부담없이 적용해볼 수 있다는 점입니다. 뭐 문제가 생기면 그냥 되돌리면 그만이니까요. 그 사이에 몇 시간쯤 사이트가 오프라인이라고 해서 누가 뭐라고 할 것도 아니고요.

소개

잠깐 소개하면 클라우드플레어는 CDN 서비스입니다. 내 비루한 호스팅 서버 앞단에서 저를 포함한 사용자들의 요청을 중간에서 보관해놨다가 중복된 요청을 받으면 내 호스팅 서버에 파일을 요청하는 대신 보관해놨던 파일을 서빙합니다. 도메인 네임서버를 클라우드플레어로 돌려놓고 클라우드플레어 설정에서 내 호스팅 서버를 가리켜두면 설정이 끝나기 때문에 AWS6)에 서버를 만든다든지 웹서버 설정을 바꾼다든지 하는 작업에 막연한 두려움이 있는 사람 수준에서도 시작하기에 나쁘지 않았습니다. 일단 이렇게 설정해두면 내 도메인을 향하는 모든 요청은 일단 클라우드플레어를 거치며 설정에 따라 내 호스팅 서버로 향하는 요청을 상당히 많이 줄일 수 있습니다. 가령 지난 30일 사이에 트래픽 기준으로 전체의 71%를 클라우드플레어가 처리했습니다. 제 호스팅 서버는 나머지 29%만 서빙했고요. 이렇게 제 호스팅 서버는 클라우드플레어의 오리진 서버가 됐습니다.

사실 어느 순간 호스팅에서 CDN을 제거하면 무슨 일이 벌어질지, 혹은 지금 수준의 서비스를 사용하려면 돈을 얼마나 더 내야 할지 예상하기는 어렵습니다만 클라우드플레어로부터 받고 있는 서비스는 지금까지는 나쁘지 않습니다. 그래서 오늘은 클라우드플레어로부터 받고 있는 서비스와 제가 한 설정을 소개해 보려고 합니다.

사전 조건

시작하기 전에 몇 가지 조건에 해당해야 합니다.

  1. 도메인을 가지고 있고 네임서버를 변경할 수 있다.
  2. 호스팅 서비스나 EC2 등을 통해 웹사이트를 호스팅하고 있다.
  3. 검색엔진 최적화가 별로 중요하지 않다. (특히 TTFB7)에 신경쓰지 않는다.)
  4. 웹서버 로그가 별로 중요하지 않다. (해결방법8)이 있음.)
  5. 전체 트래픽 중 이미지가 차지하는 비중이 큰 편이다.

문제 해결

클라우드플레어에 계정을 만들고 네임서버를 확인한 다음 도메인 서비스에서 네임서버를 이걸로 바꿔주면 설정은 끝납니다. 기존 웹서버를 직접 가리키던 DNS가 서서히 클라우드플레어로 전환되기 때문에 딱히 중간에 서비스가 중단되지도 않을 겁니다. 그러면 클라우드플레어를 통해 몇 가지 문제를 완화할 수 있게 됩니다.

  1. 핫링크나 봇에 의한 접근을 알아서 처리해준다.
  2. 사이트 전체를 'https'로 서빙한다.
  3. 이미지를 클라우드플레어가 서빙하게 한다.
  4. 로그인이 필요한 영역의 보안을 강화한다.

일단 여러 접근 중 클라우드플레어가 생각하기에 안전하지 않은 것 같은 접근을 알아서 처리해줍니다. 클라우드플레어 입장에서 평판 점수가 낮은 사용자가 접근을 시도하면 알아서 처리해줍니다. 차단하든지 사람 맞는지 확인하든지 하는 식입니다. 설정은 적당히 추상화되어있고 중간이나 낮은 수준의 보안 옵션을 사용해서 지금까지 딱히 문제가 되지는 않았습니다.

사이트 전체를 https로 서빙할 수 있게 됐습니다. 지금이야 Let's Encrypt9) 같은 서비스를 통해 인증서를 발급받아 호스팅 서비스에 올리기만 하면 해결할 수 있는 문제이지만 처음 클라우드플레어를 사용하기 시작하던 시대에는 인증서 비용이 비쌌습니다. 사실 그런게 필요한지조차 잘 몰랐습니다. 암호화는 무거워서 로그인 페이지에만 쓰자는 강좌가 넘쳐났던 기억입니다. 클라우드플레어는 사이트 50개를 하나로 묶어 인증서를 발급해 내 사이트도 https를 통해 서빙하게 해주고 또 오리진 인증서를 발급해 호스팅 서버와 클라우드플레어 사이 구간도 암호화할 수 있게 해줍니다. 브라우저에서 인증서를 눌러보면 발급 대상이 내 도메인 네임은 아니지만 뭐 모바일 시대에 주소 전체가 녹색으로 표시되는 것이 아닌 이상 누가 신경쓰겠나 싶기도 합니다.

다음은 원래 목적이던 이미지 서빙을 대신하게 하는 건데 이건 페이지 규칙 설정에서 특정 경로를 완전히 캐싱하고 캐시의 TTL을 길게 설정했습니다. 제가 사이트에 사용하는 도쿠위키는 모든 이미지의 경로가 /_media/로 시작하는데 이 경로를 무조건 캐싱하게 설정했습니다. 덕분에 전체 트래픽 요청의 약 70%가 오리진 서버에 도달하지 않게 됐지만 잃은 부분도 있습니다. 오리진 서버에서 이미지를 삭제하더라도 캐시에는 남아있어 계속해서 표시됩니다. 보안상의 문제도 있고 또 이미지를 교체해야 할 경우 기존 파일을 교체하는 대신 항상 새로운 파일을 올려야만 사이트를 정상적으로 사용할 수 있습니다.

지금 올라가 있는 웹사이트는 공개된 부분과 공개되지 않은 부분이 있습니다. 제대로 구성한다면 둘을 서로 다른 서브도메인으로 분리해 완전히 다른 서비스로 구성하는게 옳겠습니다만 또 그러기에는 귀찮기도 하고 관리 부담도 있고 해서 위키 하나에 ACL10)을 통해서만 보안을 유지하고 있었습니다. 물론 현대의 웹서버는 이전에 비해 큰 보안사고가 덜 일어나는 모양이기도 하고 또 위키의 ACL이 꽤 잘 동작하는 것도 사실이며 2FA 플러그인을 붙여서 로그인 시도를 조금 더 고통스럽게도 만들었지만 여전히 이게 잘 돌아가고 있긴 한 것인지 의심이 가는 것도 사실이었습니다. 이 때 사용할 수 있는 '액세스'11)라는 서비스를 제공하는데 클라우드플레어가 내 오리진 서버 앞에서 문지기 역할을 하고 있어 가능한 서비스입니다. 클라우드플레어의 로그인을 요구할 경로를 지정하고 로그인 방식을 지정해두면 이 경로에 접속하려고 할 때 위키 로그인에 앞서 클라우드플레어 로그인이 나타납니다. 저는 메일주소를 통해 PIN코드를 받아 인증하는 옵션을 설정했는데 일단 위키 로그인 페이지에 도달하려면 클라우드플레어의 인증을 통과해야 합니다. 다만 이 설정을 사용하려면 웹서버에서 클라우드플레어 아이피12) 이외의 아이피로부터 오는 모든 접근을 차단해야 합니다.

결론

사실 언제까지나 이런식으로 사용할 수는 없으리라는 생각입니다. 클라우드플레어가 언제까지나 서비스를 무료로 제공할지 알 수 없으니까요. 그때가 되면 일단 Let's Encrypt13) 에서 인증서를 발급받아 적용하고 호스팅 서비스를 더 비싼걸로 바꿔야만 할겁니다. 하지만 일단 지금 체계에서는 1년에 도메인 비용을 포함해서 4만 얼마만 내면 그럭저럭 봐줄만한 웹사이트를 유지할 수 있어 한동안은 이 체계를 유지할 작정입니다.

blog/using-cloudflare.txt · 마지막으로 수정됨: 2019-03-29 13:02 저자 neoocean