CDN 수집 및 설정

CDN(콘텐츠 전송 네트워크)은 주로 정적 요소의 로드 속도를 높이기 위해 웹사이트와 애플리케이션에서 사용됩니다. 이는 다른 지역에 위치한 CDN 서버에 파일을 캐싱함으로써 발생합니다. CDN을 통해 데이터를 요청하면 사용자는 가장 가까운 서버에서 데이터를 받습니다.

모든 콘텐츠 전달 네트워크의 작동 원리와 기능은 거의 동일합니다. CDN 서버는 파일 다운로드 요청을 받으면 원본 서버에서 해당 파일을 한 번 가져와 사용자에게 제공하는 동시에 지정된 기간 동안 캐시합니다. 모든 후속 요청은 캐시에서 응답됩니다. 모든 CDN에는 파일 미리 로드, 캐시 지우기, 캐시 만료 설정 등을 위한 옵션이 있습니다.

어떤 이유로든 자신만의 콘텐츠 전달 네트워크를 구성해야 하는 경우가 있으며, 다음 자전거 조립 지침이 도움이 될 수 있습니다.

출처 : pikisuperstar가 만든 인포그래픽 벡터 — www.freepik.com

언제 자체 CDN이 필요합니까?

자체 CDN을 실행하는 것이 적합한 경우를 살펴보겠습니다.

• 같은 저렴한 CDN을 사용하더라도 비용과 운영 비용을 절약하고 싶을 때 버니씨디엔 한 달에 수백 달러에 달하는 금액
• 영구 캐시를 원하거나 서버와 채널에 이웃이 없는 캐시를 원할 경우
• CDN 서비스에는 필요한 지역에 접속 지점이 없습니다.
• 특별한 콘텐츠 전달 설정이 필요합니다.
• 우리는 프로덕션 서버를 사용자에게 더 가깝게 배치하여 동적 콘텐츠 전달 속도를 높이고 싶습니다.
• 타사 CDN 서비스가 사용자 행동에 대한 정보를 부적절하게 수집 또는 사용하거나(GDPR을 준수하지 않는 서비스의 경우) 기타 불법 활동에 참여할 수 있다는 우려가 있습니다.

대부분의 경우에는 기존의 기성 솔루션을 사용하는 것이 더 적절합니다.

시작하기 위해 필요한 것

자신만의 자율시스템(AS)이 있다면 정말 좋습니다. 이를 통해 동일한 IP를 여러 서버에 할당할 수 있으며 이 지시에 따라 네트워크 수준에서 사용자를 가장 가까운 곳으로 안내합니다. /24 주소 블록으로도 콘텐츠 전달 네트워크를 구축할 수 있다는 점은 주목할 만합니다. 일부 서버 공급자는 사용 가능한 모든 지역에서 사용할 수 있도록 광고할 수 있습니다.

IP 주소 블록의 운 좋은 소유자가 아닌 경우 간단한 CDN을 시작하려면 다음이 필요합니다.

• 도메인 이름 또는 하위 도메인
• 서로 다른 지역에 있는 두 개 이상의 서버. 서버는 전용이거나 가상일 수 있습니다.
• geoDNS 도구. 도움을 받으면 도메인에 액세스하는 사용자가 가장 가까운 서버로 연결됩니다.

도메인 등록 및 서버 주문

도메인 등록을 사용하면 모든 것이 간단합니다. 모든 등록 기관을 통해 모든 영역에 등록합니다. 예를 들어 CDN에 하위 도메인을 사용할 수도 있습니다. cdn.도메인이름.com. 사실, 우리의 예에서는 그렇게 할 것입니다.

서버 주문의 경우 사용자 청중이 위치한 지역 및 국가에서 임대해야 합니다. 프로젝트가 대륙 간이라면 전 세계에 서버를 제공하는 호스팅 제공업체를 선택하는 것이 편리합니다. 예: OVH, 리스웹 и 100TB - 전용 서버의 경우, 벌 터 и DigitalOcean — 가상 클라우드*의 경우.

개인 CDN의 경우 서로 다른 대륙에 3개의 가상 서버를 주문합니다. 유 벌 터 서버에서 $5/월 우리는 얻을 것이다 25GB SSD 장소와 1TB 트래픽. 설치하는 동안 최신 Debian을 선택합니다. 우리 서버:

프랑크푸르트, IP: 199.247.18.199

시카고, IP: 149.28.121.123

싱가포르, IP: 157.230.240.216

*Vultr와 DigitalOcean은 결제 방법을 추가한 후 이 기사의 링크를 사용하여 가입하는 사용자에게 100달러의 크레딧을 약속합니다. 저자도 이에 대해 작은 칭찬을 받았는데, 이는 지금 그에게 매우 의미 있는 일이다. 이해해 주시기 바랍니다.

geoDNS 설정

사용자가 CDN 도메인 또는 하위 도메인에 액세스할 때 원하는(가장 가까운) 서버로 연결되도록 하려면 geoDNS 기능이 있는 DNS 서버가 필요합니다.

geoDNS의 원리와 작동 절차는 다음과 같습니다.

1. DNS 요청을 보낸 클라이언트의 IP 또는 클라이언트 요청을 처리할 때 사용되는 재귀 DNS 서버의 IP를 정의합니다. 이러한 재귀 서버는 일반적으로 DNS 공급자입니다.
2. 클라이언트의 IP는 해당 국가 또는 지역을 식별합니다. 이를 위해 오늘날 매우 많은 GeoIP 데이터베이스가 사용됩니다. 좋은 것들도 있어요 무료 옵션.
3. 클라이언트의 위치에 따라 가장 가까운 CDN 서버의 IP 주소를 제공합니다.

geoDNS 기능을 갖춘 DNS 서버는 직접 조립해 보세요, 그러나 전 세계의 DNS 서버 네트워크와 함께 기성 솔루션을 사용하는 것이 더 낫습니다. 애니캐스트 박스에서:

• 클라우드DNS 부터 $9.95/월, GeoDNS 관세, 기본적으로 하나의 DNS 장애 조치가 있습니다
• 질로레 부터 $25/월, DNS 장애 조치 활성화됨
• 아마존 경로 53 부터 $35/월 순수 50천만 개의 지역 쿼리의 경우. DNS 장애 조치 비용은 별도로 청구됩니다.
• 쉬운 DNS 부터 $125/월, 10개의 DNS 장애 조치가 있습니다.
• Cloudflare, "Geo Steering" 기능은 Enterprise 관세에서 사용할 수 있습니다.

geoDNS를 주문할 때 요금에 포함된 요청 수에 주의하고 도메인에 대한 실제 요청 수가 예상보다 몇 배 더 높을 수 있다는 점을 고려해야 합니다. 수백만 명의 거미, 스캐너, 스패머 및 기타 악령이 지칠 줄 모르고 일합니다.

거의 모든 DNS 서비스에는 CDN 구축에 필수적인 서비스인 DNS 장애 조치가 가격에 포함됩니다. 도움을 받으면 서버 작동 모니터링을 설정할 수 있으며, 수명의 징후가 없는 경우 DNS 응답에서 작동하지 않는 서버의 주소를 백업 주소로 자동 교체할 수 있습니다.

CDN을 구축하기 위해 우리는 클라우드DNS, GeoDNS 관세.

개인 계정에 도메인을 나타내는 새 DNS 영역을 추가해 보겠습니다. 하위 도메인에 CDN을 구축하고 기본 도메인이 이미 사용 중인 경우 영역을 추가한 후 즉시 기존 작업 DNS 레코드를 추가하는 것을 잊지 마세요. 다음 단계는 CDN 도메인/하위 도메인에 대해 여러 A 레코드를 생성하는 것입니다. 각 레코드는 우리가 지정한 지역에 사용됩니다. 대륙이나 국가를 지역으로 지정할 수 있으며, 소지역은 미국과 캐나다에서 사용할 수 있습니다.

우리의 경우 CDN은 하위 도메인에서 발생합니다. cdn.sayt.in. 영역을 추가하여 sayt.in, 하위 도메인에 대한 첫 번째 A 레코드를 생성하고 북미 전체를 시카고에 있는 서버로 연결해 보겠습니다.

기본 지역에 대해 하나의 항목을 만드는 것을 잊지 말고 다른 지역에 대해서도 작업을 반복해 보겠습니다. 결국 얻는 것은 다음과 같습니다.

스크린샷의 마지막 기본 항목은 지정되지 않은 모든 지역(유럽, 아프리카, 위성 인터넷 사용자 등)이 프랑크푸르트의 서버로 전송된다는 의미입니다.

이것으로 기본적인 DNS 설정이 완료되었습니다. 이제 도메인 등록 기관의 웹사이트에 접속하여 현재 도메인 NS를 ClouDNS에서 발급한 NS로 교체하면 됩니다. 그리고 NS가 업데이트되는 동안 서버를 준비하겠습니다.

SSL 인증서 설치

당사의 CDN은 HTTPS를 통해 작동하므로 도메인 또는 하위 도메인에 대한 SSL 인증서가 이미 있는 경우 이를 모든 서버(예: 디렉터리)에 업로드하세요. /etc/ssl/도메인/

인증서가 없으면 Let's Encrypt에서 무료로 인증서를 얻을 수 있습니다. 이것에 딱 맞습니다 ACME 쉘 스크립트. 클라이언트는 편리하고 구성하기 쉬우며, 가장 중요한 점은 ClouDNS의 API를 통해 DNS를 사용하여 도메인/하위 도메인을 검증할 수 있다는 것입니다.

우리는 서버 중 하나인 유럽 199.247.18.199에만 acme.sh를 설치합니다. 이 서버에서 인증서는 다른 모든 서버로 복사됩니다. 설치하려면 다음을 수행하십시오.

root@cdn:~# wget -O - https://get.acme.sh | bash; source ~/.bashrc

스크립트를 설치하는 동안 당사의 참여 없이 인증서를 추가로 업데이트하기 위한 CRON 작업이 생성됩니다.

인증서 발급 시 도메인 확인은 API를 사용하여 DNS를 통해 수행되므로 Reseller API 메뉴의 ClouDNS 개인 계정에서 새 API 사용자를 생성하고 비밀번호를 설정해야 합니다. 결과 auth-id와 비밀번호를 파일에 기록합니다. ~/.acme.sh/dnsapi/dns_cloudns.sh (파일과 혼동하지 마세요. dns_clouddns.sh). 주석을 제거하고 편집해야 하는 줄은 다음과 같습니다.

CLOUDNS_AUTH_ID=<auth-id>
CLOUDNS_AUTH_PASSWORD="<пароль>"

이제 SSL 인증서를 요청해 보겠습니다. cdn.sayt.in

root@cdn:~# acme.sh --issue --dns dns_cloudns -d cdn.sayt.in --reloadcmd "service nginx reload"

매개변수에는 앞으로 각 인증서 유효성 업데이트 후에 웹 서버 구성을 자동으로 다시 로드하는 명령을 지정했습니다.

인증서를 획득하는 전체 과정은 최대 2분 정도 소요될 수 있으므로 중단하지 마십시오. 도메인 유효성 검사 오류가 발생하면 명령을 다시 실행해 보세요. 마지막에는 인증서가 다운로드된 위치를 확인합니다.

이 경로를 기억해 두세요. 인증서를 다른 서버에 복사할 때와 웹 서버 설정에서 지정해야 합니다. Nginx 구성을 다시 로드할 때 발생하는 오류에는 주의를 기울이지 않습니다. 완전히 구성된 서버에서는 인증서를 업데이트할 때 오류가 나타나지 않습니다.

SSL에서 우리에게 남은 것은 파일 경로를 유지하면서 수신된 인증서를 다른 두 서버에 복사하는 것뿐입니다. 각각에 동일한 디렉터리를 만들고 복사본을 만들어 보겠습니다.

root@cdn:~# mkdir -p /root/.acme.sh/cdn.sayt.in/
root@cdn:~# scp -r [email protected]:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/

인증서를 정기적으로 업데이트하기 위해 다음 명령을 사용하여 두 서버 모두에 일일 CRON 작업을 생성합니다.

scp -r [email protected]:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/ && service nginx reload

이 경우 원격 원본 서버에 대한 접근을 구성해야 합니다. 키로, 즉. 비밀번호를 입력하지 않고. 이것을하는 것을 잊지 마십시오.

Nginx 설치 및 구성

정적 콘텐츠를 제공하기 위해 캐싱 프록시 서버로 구성된 Nginx를 사용합니다. 패키지 목록을 업데이트하고 세 서버 모두에 설치해 보겠습니다.

root@cdn:~# apt update
root@cdn:~# apt install nginx

기본값 대신 아래 스포일러의 구성을 사용합니다.
nginx.conf

user www-data;
worker_processes auto;
pid /run/nginx.pid;

events {
    worker_connections 4096;
    multi_accept on;
}

http {
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    types_hash_max_size 2048;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    access_log off;
    error_log /var/log/nginx/error.log;

    gzip on;
    gzip_disable "msie6";
    gzip_comp_level 6;
    gzip_proxied any;
    gzip_vary on;
    gzip_types text/plain application/javascript text/javascript text/css application/json application/xml text/xml application/rss+xml;
    gunzip on;            

    proxy_temp_path    /var/cache/tmp;
    proxy_cache_path   /var/cache/cdn levels=1:2 keys_zone=cdn:64m max_size=20g inactive=7d;
    proxy_cache_bypass $http_x_update;

server {
  listen 443 ssl;
  server_name cdn.sayt.in;

  ssl_certificate /root/.acme.sh/cdn.sayt.in/cdn.sayt.in.cer;
  ssl_certificate_key /root/.acme.sh/cdn.sayt.in/cdn.sayt.in.key;

  location / {
    proxy_cache cdn;
    proxy_cache_key $uri$is_args$args;
    proxy_cache_valid 90d;
    proxy_pass https://sayt.in;
    }
  }
}

구성에서 다음을 편집합니다.

• 최대 크기 — 캐시 크기가 사용 가능한 디스크 공간을 초과하지 않음
• 비활성 — 액세스되지 않은 캐시된 데이터의 저장 시간
• ssl_certificate и SSL_certificate_key — SSL 인증서 및 키 파일의 경로
• 프록시_캐시_유효 — 캐시된 데이터의 저장 시간
• 프록시 패스 — CDN이 캐싱을 위해 파일을 요청할 원본 서버의 주소입니다. 우리의 예에서는 이것이다 sayt.in

보시다시피 모든 것이 간단합니다. 지시문의 유사성으로 인해 캐싱 시간을 설정하는 데 유일한 어려움이 발생할 수 있습니다. 비활성 и 프록시_캐시_유효. 우리의 예를 사용하여 살펴 보겠습니다. 이런 일이 일어날 때 비활성=7일 и Proxy_cache_valid 90일:

• 7일 이내에 요청이 반복되지 않으면 이 기간이 지난 후 데이터가 캐시에서 삭제됩니다.
• 요청이 7일마다 한 번 이상 반복되면 캐시의 데이터는 90일 후에 오래된 것으로 간주되며 다음 요청 시 Nginx는 해당 데이터를 업데이트하여 원래 서버에서 가져옵니다.

편집을 마치고 nginx.conf, 구성을 다시 로드합니다.

root@cdn:~# service nginx reload

우리의 CDN은 완전히 준비되었습니다. 월 15달러. 우리는 3개 대륙에서 접속 지점과 1TB의 트래픽(각 위치마다 XNUMXTB)을 받았습니다.

CDN 작동 확인

다양한 지리적 위치에서 CDN에 대한 ping을 살펴보겠습니다. 모든 핑 서비스가 이에 적합합니다.

시작점
주인
IP
평균 시간(밀리초)

독일 베를린
cdn.sayt.in
199.247.18.199
9.6

네덜란드, 암스테르담
cdn.sayt.in
199.247.18.199
10.1

프랑스 파리
cdn.sayt.in
199.247.18.199
16.3

영국, 런던
cdn.sayt.in
199.247.18.199
14.9

캐나다, 토론토
cdn.sayt.in
149.28.121.123
16.2

미국, 샌프란시스코
cdn.sayt.in
149.28.121.123
52.7

미국, 달라스
cdn.sayt.in
149.28.121.123
23.1

미국, 시카고
cdn.sayt.in
149.28.121.123
2.6

미국, 뉴욕
cdn.sayt.in
149.28.121.123
19.8

싱가포르
cdn.sayt.in
157.230.240.216
1.7

일본 도쿄
cdn.sayt.in
157.230.240.216
74.8

호주, 시드니
cdn.sayt.in
157.230.240.216
95.9

결과는 좋습니다. 이제 메인 사이트의 루트에 테스트 이미지를 배치해 보겠습니다. 테스트.jpg CDN을 통해 다운로드 속도를 확인하세요. 그것은 말한다 - 완료. 콘텐츠가 빠르게 전달됩니다.

CDN 지점에서 캐시를 지우고 싶은 경우를 대비해 작은 스크립트를 작성해 보겠습니다.
purge.sh

#!/bin/bash
if [ -z "$1" ]
then
    echo "Purging all cache"
    rm -rf /var/cache/cdn/*
else
    echo "Purging $1"
    FILE=`echo -n "$1" | md5sum | awk '{print $1}'`
    FULLPATH=/var/cache/cdn/${FILE:31:1}/${FILE:29:2}/${FILE}
    rm -f "${FULLPATH}"
fi

전체 캐시를 삭제하려면 실행하면 됩니다. 다음과 같이 별도의 파일을 지울 수 있습니다.

root@cdn:~# ./purge.sh /test.jpg

결론 대신

마지막으로, 한때 저를 괴롭혔던 갈퀴를 즉시 뛰어넘을 수 있는 몇 가지 유용한 팁을 제공하고 싶습니다.

• CDN 내결함성을 높이려면 서버 장애 발생 시 A 레코드를 빠르게 변경하는 데 도움이 되는 DNS 장애 조치를 구성하는 것이 좋습니다. 이 작업은 도메인 DNS 레코드 제어판에서 수행됩니다.
• 지리적 범위가 넓은 사이트에는 의심할 여지 없이 많은 수의 CDN 포인트가 필요하지만 지나치게 열광하지는 마십시오. 아마도 유럽, 북미(동부), 북미(서부), 싱가포르, 호주, 홍콩, 일본 등 6~7개 장소에 서버를 배치한다면 사용자는 유료 CDN과 큰 차이를 느끼지 못할 것입니다.
• 때때로 호스팅 업체는 CDN 목적으로 임대 서버 사용을 허용하지 않습니다. 따라서 갑자기 콘텐츠 전송 네트워크를 서비스로 배포하기로 결정한 경우 특정 호스팅 공급자의 규칙을 미리 읽어보는 것을 잊지 마세요.
• 연구 수중 통신 지도대륙이 어떻게 연결되어 있는지 상상하고 콘텐츠 전송 네트워크를 구축할 때 이를 고려합니다.
• 확인해 보세요 여러 곳에서 온 핑 귀하의 서버에. 이렇게 하면 CDN 포인트에 가장 가까운 지역을 확인하고 GeoDNS를 보다 정확하게 구성할 수 있습니다.
• 작업에 따라 특정 캐싱 요구 사항에 맞게 Nginx를 사용자 정의하고 서버의 로드를 고려하는 것이 유용할 수 있습니다. Nginx 캐시에 관한 기사는 나에게 많은 도움이 되었습니다. 여기에 과부하시 작업 가속화 : 여기에 и 여기에

출처 : habr.com