Bangun dan sesuaikan CDN Anda

Content Delivery Networks (CDNs) digunakan di situs dan dalam aplikasi terutama untuk mempercepat pemuatan elemen statis. Ini terjadi karena caching file pada server CDN yang terletak di wilayah geografis yang berbeda. Setelah meminta data melalui CDN, pengguna menerimanya dari server terdekat.

Prinsip operasi dan fungsionalitas semua jaringan pengiriman konten kira-kira sama. Setelah menerima permintaan untuk mengunduh file, server CDN pernah mengambilnya dari server asli dan memberikannya kepada pengguna, sekaligus melakukan caching untuk periode waktu tertentu. Semua permintaan selanjutnya dijawab dari cache. Semua CDN memiliki opsi untuk preloading file, membersihkan cache, mengatur periode penyimpanannya, dan banyak lagi.

Kebetulan karena satu dan lain alasan Anda perlu mengatur jaringan pengiriman konten Anda sendiri, dan kemudian - biarkan kami membantu Anda membangun sepeda lain.


Sumber: Vektor infografis yang dibuat oleh pikisuperstar - www.freepik.com


Saat Anda membutuhkan CDN Anda sendiri


Pertimbangkan kasus-kasus ketika memulai CDN Anda sendiri masuk akal:

  • ketika Anda ingin menghemat uang, dan menjalankan biaya bahkan ketika menggunakan CDN murah seperti BunnyCDN adalah beberapa ratus dolar sebulan
  • jika kita ingin mendapatkan cache permanen atau cache tanpa tetangga di server dan saluran
  • di wilayah yang Anda butuhkan, layanan CDN tidak memiliki titik kehadiran
  • pengaturan pengiriman konten khusus yang diperlukan
  • kami ingin mempercepat pengiriman konten dinamis dengan menempatkan lebih dekat ke pengguna server produksi
  • ada kekhawatiran bahwa layanan CDN pihak ketiga dapat secara tidak sah mengumpulkan atau menggunakan informasi tentang perilaku pengguna (halo ke layanan tanpa kepatuhan GDPR) atau terlibat dalam tindakan ilegal lainnya

Dalam kebanyakan kasus lain, lebih disarankan untuk menggunakan solusi yang sudah jadi.


Apa yang perlu Anda jalankan


Luar biasa jika Anda memiliki sistem otonom Anda sendiri. Dengannya, Anda dapat menetapkan IP yang sama ke beberapa server dan mengikuti instruksi ini di tingkat jaringan untuk mengarahkan pengguna ke yang terdekat. Perlu dikatakan bahwa meskipun dengan blok alamat / 24, dimungkinkan untuk membangun jaringan pengiriman konten. Beberapa penyedia server memungkinkan Anda membuat pengumuman untuk digunakan di semua wilayah yang tersedia bagi mereka.

Jika Anda bukan pemilik yang senang dengan blok alamat IP, maka untuk menjalankan CDN sederhana Anda perlu:

  • . ,
  • geoDNS . , ,



Dengan registrasi domain, semuanya sederhana - daftar di zona apa pun dengan registrar apa pun. Anda juga dapat menggunakan subdomain untuk CDN, seperti sesuatu seperti cdn.namedomain.com . Sebenarnya dalam contoh kita, kita akan melakukannya.

Adapun server pemesanan, mereka harus disewa di wilayah dan negara di mana audiens pengguna Anda berada. Jika proyek ini antarbenua, akan lebih mudah untuk memilih penyedia hosting yang menawarkan server di seluruh dunia segera. Contoh: OVH , Leaseweb, dan 100Tb untuk server khusus, Vultr dan DigitalOcean untuk cloud virtual *.

Untuk CDN pribadi kami, kami memesan 3 server virtual di berbagai benua. Di vultrdi server sebesar $ 5 / bulan kami mendapatkan ruang SSD 25GB dan lalu lintas 1TB . Saat memasang, pilih Debian terbaru. Server kami:

Frankfurt , ip: 199.247.18.199

Chicago , ip: 149.28.121.123

Singapura , ip: 157.230.240.216

* Vultr dan DigitalOcean menjanjikan pinjaman $ 100 kepada pengguna yang terdaftar menggunakan tautan dalam artikel segera setelah menambahkan metode pembayaran. Penulis juga menerima pujian kecil dari ini, yang sangat penting baginya sekarang. Mohon pengertian.


Konfigurasikan geoDNS


Sehingga ketika pengguna mengakses domain atau subdomain CDN, ia diarahkan ke server yang diinginkan (paling dekat dengannya), kita memerlukan server DNS dengan fungsi geoDNS.

Prinsip dan prosedur geoDNS adalah sebagai berikut:

  1. Menentukan IP klien yang mengirim permintaan DNS, atau IP dari server DNS rekursif yang digunakan untuk memproses permintaan klien. Server rekursif ini biasanya penyedia DNS.
  2. By IP client tahu negara atau wilayahnya. Untuk ini, basis GeoIP digunakan, yang ada banyak sekali saat ini. Ada beberapa opsi gratis yang bagus .
  3. Bergantung pada lokasi klien, ia memberinya alamat IP dari server CDN terdekat.

Anda dapat membangun sendiri server DNS dengan fungsi geoDNS , tetapi lebih baik menggunakan solusi yang sudah jadi dengan jaringan server DNS di seluruh dunia dan Anycast di luar kotak:

  • louDNS dari $ 9,95 / bulan , tarif GeoDNS, secara default ada satu DNS Failover
  • Zilore mulai $ 25 / bulan , DNS Failover diaktifkan
  • Amazon Route 53 mulai $ 35 / bln untuk 50 juta net geo-request. Kegagalan DNS dibebankan secara terpisah
  • DNS Made Easy dari $ 125 / bln , ada 10 DNS Failover
  • Cloudflare , Fitur Geo Steering Tersedia dalam Tarif Perusahaan

Saat memesan geoDNS, Anda harus memperhatikan jumlah permintaan yang termasuk dalam tarif dan mempertimbangkan bahwa jumlah panggilan aktual ke domain dapat melebihi harapan beberapa kali. Jutaan laba-laba, pemindai, spammer, dan roh jahat lainnya bekerja tanpa lelah.

Hampir semua layanan DNS termasuk sangat diperlukan untuk membangun layanan CDN - DNS Failover. Dengan menggunakannya, Anda dapat mengonfigurasi pemantauan server Anda dan, jika tidak ada tanda-tanda kehidupan, secara otomatis mengganti alamat server yang tidak berfungsi dengan server cadangan dalam jawaban DNS.

Untuk membangun CDN kami, kami akan menggunakan ClouDNS , tarif GeoDNS.

Tambahkan zona DNS baru di akun Anda, yang menunjukkan domain Anda. Jika kita akan membangun CDN pada subdomain, dan domain utama sudah digunakan, maka segera setelah menambahkan zona, jangan lupa untuk menambahkan catatan DNS yang ada. Langkah selanjutnya adalah membuat untuk domain / subdomain CDN beberapa catatan-A, yang masing-masing akan diterapkan ke wilayah yang kita atur. Anda dapat menentukan benua atau negara sebagai wilayah, subkawasan tersedia untuk AS dan Kanada.

Dalam kasus kami, CDN akan dibangkitkan pada cdn.sayt.in subdomain . Menambahkan zona sayt.in , buat catatan A pertama untuk subdomain dan arahkan semua Amerika Utara ke server di Chicago:


Ulangi untuk wilayah lain, ingat untuk membuat satu entri untuk wilayah default. Inilah hasilnya:



Catatan default terakhir dalam tangkapan layar berarti bahwa semua wilayah yang tidak ditentukan (dan ini adalah Eropa, Afrika, pengguna Internet satelit, dll.) Akan dikirim ke server di Frankfurt.

Ini melengkapi konfigurasi DNS dasar. Tetap pergi ke situs web pendaftar domain dan mengganti NS domain saat ini dengan yang dikeluarkan oleh ClouDNS. Dan sementara NS akan diperbarui, kami akan menyiapkan server.


Instal Sertifikat SSL


CDN kami akan berfungsi pada HTTPS, jadi jika Anda sudah memiliki sertifikat SSL untuk domain atau subdomain, unggah ke semua server, misalnya, di direktori / etc / ssl / yourdomain /

Jika tidak ada sertifikat, Anda bisa mendapatkan yang gratis dari Let's Encrypt. Skrip ACME Shell sangat cocok untuk ini . Klien nyaman dan mudah dikonfigurasi, dan yang paling penting - memungkinkan Anda untuk memvalidasi domain / subdomain untuk DNS melalui API dari ClouDNS.

Kami akan menginstal acme.sh hanya di salah satu server - Eropa 199.247.18.199, dari mana sertifikat akan disalin ke yang lain. Untuk menginstal, lakukan:

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

Selama instalasi skrip, tugas CRON akan dibuat untuk pembaruan sertifikat lebih lanjut tanpa partisipasi kami.

Verifikasi domain saat mengeluarkan sertifikat akan dilakukan menggunakan DNS menggunakan API, oleh karena itu, dalam akun pribadi ClouDNS di menu Reseller API, Anda perlu membuat API pengguna baru dan menetapkan kata sandi untuk itu. Auth-id yang dihasilkan dengan kata sandi ditulis dalam file ~ / .acme.sh / dnsapi / dns_cloudns.sh (jangan disamakan dengan file dns_clou d file dns.sh ). Berikut adalah baris-baris untuk menghapus komentar dan mengedit:

CLOUDNS_AUTH_ID=<auth-id>
CLOUDNS_AUTH_PASSWORD="<>"

Sekarang kami meminta sertifikat SSL untuk cdn.sayt.in

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

Dalam parameter untuk masa depan, kami menetapkan perintah untuk memuat ulang konfigurasi server web secara otomatis setelah setiap pembaruan masa berlaku sertifikat di masa mendatang.

Seluruh proses untuk mendapatkan sertifikat bisa memakan waktu hingga 2 menit, jangan diganggu. Jika kesalahan validasi domain terjadi, coba jalankan perintah lagi. Pada akhirnya kita akan melihat di mana sertifikat diunggah:



Ingat jalur ini, mereka harus ditentukan saat menyalin sertifikat ke server lain, serta dalam pengaturan server web. Kami tidak memperhatikan kesalahan memuat ulang file konfigurasi Nginx - pada server yang sepenuhnya dikonfigurasi itu tidak akan hadir ketika memperbarui sertifikat.

Yang tersisa bagi kami melalui SSL adalah menyalin sertifikat yang diterima ke dua server lain dengan menyimpan jalur ke file. Buat direktori yang sama di masing-masing dan buat salinan:

root@cdn:~# mkdir -p /root/.acme.sh/cdn.sayt.in/
root@cdn:~# scp -r root@199.247.18.199:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/

Agar pembaruan sertifikat teratur, kami akan membuat tugas CRON harian di kedua server dengan perintah:
scp -r root@199.247.18.199:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/ && service nginx reload

Dalam hal ini, akses ke server sumber jarak jauh harus dikonfigurasikan dengan kunci , mis. tanpa memasukkan kata sandi. Jangan lupa melakukannya.


Instal dan konfigurasikan Nginx


Untuk mengembalikan konten statis, kami akan menggunakan Nginx, yang dikonfigurasi sebagai server proxy caching. Perbarui daftar paket dan instal di ketiga server:

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

Alih-alih default, gunakan konfigurasi dari spoiler di bawah ini:
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;
    }
  }
}


Di konfigurasi, edit:

  • max_size - ukuran cache tidak melebihi ruang disk yang tersedia
  • tidak aktif - waktu penyimpanan untuk data dalam tembolok yang tidak ada yang diakses
  • ssl_certificate dan ssl_certificate_key - jalur ke sertifikat SSL dan file kunci
  • proxy_cache_valid - waktu penyimpanan untuk data yang di-cache
  • proxy_pass - alamat server asli dari mana CDN akan meminta file untuk caching. Dalam contoh kita, ini adalah sayt.in

Seperti yang Anda lihat, semuanya sederhana. Kompleksitas hanya dapat muncul dalam pengaturan waktu cache karena kesamaan dari arahan tidak aktif dan proxy_cache_valid . Kami akan menganalisisnya dalam contoh kami. Inilah yang terjadi dengan tidak aktif = 7d dan proxy_cache_valid 90d :

  • jika permintaan tidak diulang dalam 7 hari, maka data akan dihapus dari cache setelah periode ini
  • jika permintaan diulang setidaknya sekali setiap 7 hari, maka data dalam cache akan dianggap usang setelah 90 hari dan pada permintaan berikutnya Nginx akan memperbaruinya dengan mengambilnya dari server asli

Setelah selesai mengedit nginx.conf , muat ulang konfigurasi:

root@cdn:~# service nginx reload

CDN kami sepenuhnya siap. Untuk $ 15 / bulan kami mendapat titik kehadiran di tiga benua dan 3 TB lalu lintas: 1 TB di setiap lokasi.


Memeriksa pengoperasian CDN


Mari kita lihat ping ke CDN kami dari lokasi geografis yang berbeda. Untuk ini, semua layanan ping cocok.
Titik peluncuranTuan rumahAKU PWaktu rata-rata, ms
Jerman Berlincdn.sayt.in199.247.18.1999.6
Belanda, Amsterdamcdn.sayt.in199.247.18.19910.1
Prancis Pariscdn.sayt.in199.247.18.19916.3
Inggris Raya, Londoncdn.sayt.in199.247.18.19914.9
Kanada Torontocdn.sayt.in149.28.121.12316.2
AS, San Franciscocdn.sayt.in149.28.121.12352.7
AS, Dallascdn.sayt.in149.28.121.12323.1
AS, Chicagocdn.sayt.in149.28.121.1232.6
AS, New Yorkcdn.sayt.in149.28.121.12319.8
Singapuracdn.sayt.in157.230.240.2161.7
Jepang Tokyocdn.sayt.in157.230.240.21674.8
Australia, Sydneycdn.sayt.in157.230.240.21695.9
Hasilnya bagus. Sekarang kita akan menempatkan test image test.jpg di root situs utama dan memeriksa kecepatan unduhannya melalui CDN. Tidak lebih cepat dikatakan daripada dilakukan . Konten dikirim dengan cepat.

Kami akan menulis skrip kecil jika kami ingin menghapus cache pada titik 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


Untuk menghapus seluruh cache, jalankan saja, file terpisah dapat dibersihkan seperti ini:

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


Alih-alih kesimpulan


Akhirnya, saya ingin memberikan beberapa tips yang berguna untuk segera melangkahi menyapu, yang pada satu waktu membuat kepala saya sakit:

  • Untuk meningkatkan toleransi kesalahan CDN, disarankan untuk mengonfigurasi DNS Failover, yang membantu dengan cepat mengubah catatan jika terjadi kegagalan server. Ini dilakukan di panel kontrol catatan DNS domain
  • CDN, . CDN, 6-7 : , (), (), , ,
  • CDN. , , -
  • , ,
  • Coba periksa ping dari berbagai tempat ke server Anda. Jadi, Anda dapat melihat wilayah terdekat dengan titik CDN dan mengkonfigurasi GeoDNS dengan benar
  • Bergantung pada tugasnya, itu tidak pada tempatnya untuk mengkonfigurasi Nginx untuk persyaratan caching tertentu dan memperhitungkan beban pada server. Artikel-artikel tentang cache Nginx - di sini dan percepatan pekerjaan di bawah beban berat: di sini dan di sini banyak membantu saya.

All Articles