თქვენი CDN-ის შექმნა და კონფიგურაცია

კონტენტის მიწოდების ქსელები (CDN) გამოიყენება ვებსაიტებსა და აპლიკაციებში, ძირითადად, სტატიკური ელემენტების ჩატვირთვის დასაჩქარებლად. ეს ხდება სხვადასხვა გეოგრაფიულ რეგიონში მდებარე CDN სერვერებზე ფაილების ქეშირების გამო. CDN-ის საშუალებით მონაცემების მოთხოვნით, მომხმარებელი იღებს მას უახლოეს სერვერიდან.

კონტენტის მიწოდების ყველა ქსელის მუშაობის პრინციპი და ფუნქციონირება დაახლოებით იგივეა. ფაილის ჩამოტვირთვის მოთხოვნის მიღების შემდეგ, CDN სერვერი იღებს მას ერთჯერად ორიგინალური სერვერიდან და აძლევს მომხმარებელს, ამავე დროს ქეშირებს მას გარკვეული პერიოდის განმავლობაში. ყველა შემდგომ მოთხოვნას პასუხობენ ქეშიდან. ყველა CDN-ს აქვს ფაილების წინასწარ ჩატვირთვის, ქეშის გასუფთავების, ვადის გასვლის თარიღის დაყენების და სხვა.

ხდება ისე, რომ ამა თუ იმ მიზეზის გამო, თქვენ უნდა მოაწყოთ კონტენტის მიწოდების საკუთარი ქსელი, შემდეგ კი - დაგვეხმაროს შემდეგი ველოსიპედის აწყობის ინსტრუქციები.

წყარო: ინფოგრაფიული ვექტორი შექმნილი pikisuperstar - www.freepik.com

როცა გჭირდება საკუთარი CDN

განვიხილოთ შემთხვევები, როდესაც თქვენი საკუთარი CDN-ის გაშვებას აზრი აქვს:

• როდესაც არსებობს ფულის დაზოგვის სურვილი და ხარჯები, თუნდაც იაფი CDN-ების გამოყენებისას BunnyCDN თვეში რამდენიმე ასეულ დოლარს შეადგენს
• თუ გვინდა მივიღოთ მუდმივი ქეში ან ქეში სერვერისა და არხის მეზობლების გარეშე
• CDN სერვისებს არ აქვთ ყოფნის წერტილები თქვენთვის საჭირო რეგიონში
• საჭიროა ნებისმიერი სპეციალური შინაარსის მიწოდების პარამეტრები
• ჩვენ გვსურს დავაჩქაროთ დინამიური შინაარსის მიწოდება პროდუქციის სერვერის მომხმარებლებთან უფრო ახლოს განთავსებით
• არსებობს შეშფოთება, რომ მესამე მხარის CDN სერვისმა შეიძლება არალეგალურად შეაგროვოს ან გამოიყენოს ინფორმაცია მომხმარებლის ქცევის შესახებ (გამარჯობა GDPR-ის არა-შესაბამისი სერვისები) ან ჩაერთოს სხვა უკანონო ქმედებებში

უმეტეს შემთხვევაში, უფრო მიზანშეწონილია გამოიყენოთ არსებული მზა გადაწყვეტილებები.

რა გჭირდებათ დასაწყებად

მშვენიერია, თუ თქვენ გაქვთ საკუთარი ავტონომიური სისტემა (AS). მასთან ერთად შეგიძლიათ ერთი და იგივე IP მივანიჭოთ რამდენიმე სერვერს და ამ ინსტრუქციის მიხედვით ქსელის დონეზე, მიმართეთ მომხმარებლებს უახლოეს ერთთან. აღსანიშნავია, რომ /24 მისამართის ბლოკითაც კი შესაძლებელია კონტენტის მიწოდების ქსელის აგება. ზოგიერთი სერვერის პროვაიდერი საშუალებას გაძლევთ გააკეთოთ განცხადება გამოსაყენებლად მათთვის ხელმისაწვდომ ყველა რეგიონში.

თუ არ ხართ IP მისამართების ბლოკის ბედნიერი მფლობელი, მაშინ მარტივი CDN-ის გასაშვებად დაგჭირდებათ:

• დომენის სახელი ან ქვედომენი
• მინიმუმ ორი სერვერი სხვადასხვა რეგიონში. სერვერი შეიძლება იყოს გამოყოფილი ან ვირტუალური
• geoDNS ინსტრუმენტი. მასთან ერთად, მომხმარებელი, რომელმაც მიმართა დომენს, მიმართული იქნება უახლოეს სერვერზე

დაარეგისტრირეთ დომენი და შეუკვეთეთ სერვერები

დომენის რეგისტრაციით ყველაფერი მარტივია - ჩვენ ვრეგისტრირდებით ნებისმიერ ზონაში ნებისმიერ რეგისტრატორთან. თქვენ ასევე შეგიძლიათ გამოიყენოთ ქვედომენი CDN-სთვის, მაგალითად, მსგავსი რამ cdn.domainname.com. სინამდვილეში, ჩვენს მაგალითში ჩვენ ამას გავაკეთებთ.

რაც შეეხება სერვერების შეკვეთას, ისინი უნდა იქირავოთ იმ რეგიონებში და ქვეყნებში, სადაც თქვენი მომხმარებლის აუდიტორია მდებარეობს. თუ პროექტი ინტერკონტინენტურია, მაშინ მოსახერხებელია ჰოსტინგის პროვაიდერების არჩევა, რომლებიც ერთდროულად სთავაზობენ სერვერებს მთელ მსოფლიოში. მაგალითები: OVH, იჯარით ვებ и 100 ტბ - გამოყოფილი სერვერებისთვის, ვალერი и ციფრული ოკეანე — ვირტუალური ღრუბლისთვის*.

ჩვენი პირადი CDN-სთვის ჩვენ შევუკვეთავთ 3 ვირტუალურ სერვერს სხვადასხვა კონტინენტზე. ზე ვალერი სერვერზე ამისთვის $5/თვეში მივიღებთ 25GB SSD ადგილები და 1 ტბ ტრაფიკი. ინსტალაციისას აირჩიეთ უახლესი Debian. ჩვენი სერვერები:

ფრანკფურტის, IP: 199.247.18.199

ჩიკაგოში, IP: 149.28.121.123

Singapore, IP: 157.230.240.216

*Vultr და DigitalOcean 100 დოლარის კრედიტს ჰპირდებიან მომხმარებლებს, რომლებიც დარეგისტრირდებიან სტატიაში მოცემული ბმულების საშუალებით გადახდის მეთოდის დამატებისთანავე. ავტორი ამისგან იღებს მცირე კომპლიმენტსაც, რაც მისთვის ახლა ძალიან მნიშვნელოვანია. გთხოვთ იყოთ გაგებით.

geoDNS-ის დაყენება

იმისთვის, რომ დომენზე ან CDN ქვედომენზე წვდომისას მომხმარებელი იყოს მიმართული სასურველ (უახლოეს) სერვერზე, გვჭირდება DNS სერვერი geoDNS ფუნქციით.

geoDNS-ის პრინციპი და მოქმედება შემდეგია:

1. განსაზღვრავს კლიენტის IP-ს, რომელმაც გაგზავნა DNS მოთხოვნა, ან რეკურსიული DNS სერვერის IP-ს, რომელიც გამოიყენება კლიენტის მოთხოვნის დამუშავებისას. ასეთი რეკურსიული სერვერები, როგორც წესი, პროვაიდერების DNS-ებია.
2. კლიენტის IP ცნობს მის ქვეყანას ან რეგიონს. ამისთვის გამოიყენება GeoIP მონაცემთა ბაზები, რომელთაგან დღეს ძალიან ბევრია. არის კარგი უფასო პარამეტრები.
3. კლიენტის მდებარეობიდან გამომდინარე, აძლევს მას უახლოეს CDN სერვერის IP მისამართს.

DNS სერვერი geoDNS ფუნქციით შეიძლება იყოს შეიკრიბეთ საკუთარი ხელით, მაგრამ უმჯობესია გამოიყენოთ მზა გადაწყვეტილებები DNS სერვერების ქსელით მთელს მსოფლიოში და ანიკასტი ყუთიდან:

• CloudDNS საწყისი $9.95/თვეში, GeoDNS ტარიფი, ნაგულისხმევად არის ერთი DNS Failover
• ზილორე საწყისი $25/თვეში, DNS Failover ჩართულია
• ამაზონის მარშრუტი 53 საწყისი $35/თვეში წმინდა 50 მილიონი გეო-მოთხოვნისთვის. DNS Failover ირიცხება ცალკე
• DNS დამზადებულია მარტივად საწყისი $125/თვეში, არის 10 DNS Failover
• CloudFlare, "Geo Steering" ფუნქცია ხელმისაწვდომია Enterprise-ის გეგმებში

geoDNS-ის შეკვეთისას ყურადღება უნდა მიაქციოთ ტარიფში შეტანილი მოთხოვნების რაოდენობას და გაითვალისწინოთ, რომ დომენის მიმართ მოთხოვნის ფაქტობრივმა რაოდენობამ შეიძლება რამდენჯერმე გადააჭარბოს მოლოდინს. მილიონობით ობობა, სკანერი, სპამერი და სხვა ბოროტი სულები დაუღალავად მუშაობენ.

თითქმის ყველა DNS სერვისი მოიცავს აუცილებელ სერვისს CDN-ის შესაქმნელად - DNS Failover. მისი დახმარებით, შეგიძლიათ დააყენოთ თქვენი სერვერების მუშაობის მონიტორინგი და სიცოცხლის ნიშნების არარსებობის შემთხვევაში, ავტომატურად შეცვალოთ არასამუშაო სერვერის მისამართი სარეზერვო მისამართით DNS პასუხებში.

ჩვენი CDN-ის ასაშენებლად, ჩვენ გამოვიყენებთ ღრუბელი DNS, GeoDNS ტარიფი.

მოდით დავამატოთ ახალი DNS ზონა თქვენს პირად ანგარიშში, თქვენი დომენის მითითებით. თუ ჩვენ ვაშენებთ CDN-ს ქვედომენზე და მთავარი დომენი უკვე გამოიყენება, მაშინ ზონის დამატებისთანავე არ დაგავიწყდეთ არსებული სამუშაო DNS ჩანაწერების დამატება. შემდეგი ნაბიჯი არის CDN დომენის / ქვედომენისთვის რამდენიმე A- ჩანაწერის შექმნა, რომელთაგან თითოეული გამოყენებული იქნება ჩვენ მიერ მითითებულ რეგიონში. თქვენ შეგიძლიათ მიუთითოთ კონტინენტები ან ქვეყნები, როგორც რეგიონები, ქვერეგიონები ხელმისაწვდომია აშშ-სა და კანადაში.

ჩვენს შემთხვევაში, CDN გაიზრდება ქვედომენზე cdn.sayt.in. ზონის დამატებით ამბობენ.შიშექმენით პირველი A-ჩანაწერი ქვედომენისთვის და მიუთითეთ მთელი ჩრდილოეთ ამერიკა სერვერზე ჩიკაგოში:

მოდით გავიმეოროთ მოქმედება სხვა რეგიონებისთვის, დაგვავიწყდეს, რომ შევქმნათ ერთი ჩანაწერი ნაგულისხმევი რეგიონებისთვის. აი რა ხდება ბოლოს:

ბოლო ნაგულისხმევი ჩანაწერი ეკრანის სურათზე ნიშნავს, რომ ყველა დაუზუსტებელი რეგიონი (და ეს არის ევროპა, აფრიკა, სატელიტური ინტერნეტის მომხმარებლები და ა.შ.) გაიგზავნება ფრანკფურტის სერვერზე.

ეს ასრულებს DNS-ის ძირითად დაყენებას. რჩება დომენის რეგისტრატორის ვებსაიტზე გადასვლა და ამჟამინდელი დომენის NS-ების შეცვლა ClouDNS-ის მიერ გაცემულით. და სანამ NS-ები განახლდება, ჩვენ მოვამზადებთ სერვერებს.

SSL სერთიფიკატების ინსტალაცია

ჩვენი CDN იმუშავებს HTTPS-ზე, ასე რომ, თუ უკვე გაქვთ SSL სერთიფიკატები დომენისთვის ან ქვედომენისთვის, ატვირთეთ ისინი ყველა სერვერზე, მაგალითად, დირექტორიაში. /etc/ssl/yourdomain/

თუ არ არის სერთიფიკატები, შეგიძლიათ მიიღოთ უფასო Let's Encrypt-დან. იდეალურია ამისთვის ACME Shellscript. კლიენტი მოსახერხებელი და მარტივი დასაყენებელია და რაც მთავარია, ის საშუალებას გაძლევთ დაადასტუროთ დომენი/ქვედომენი DNS-ით ClouDNS API-ის საშუალებით.

ჩვენ დავაყენებთ acme.sh-ს მხოლოდ ერთ სერვერზე - ევროპული 199.247.18.199, საიდანაც სერთიფიკატები დაკოპირდება ყველა დანარჩენზე. ინსტალაციისთვის, გაუშვით:

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

სკრიპტის ინსტალაციის დროს შეიქმნება CRON სამუშაო სერტიფიკატების შემდგომი განახლებისთვის ჩვენი მონაწილეობის გარეშე.

სერთიფიკატის გაცემისას, დომენი შემოწმდება DNS-ის გამოყენებით API-ს გამოყენებით, ასე რომ, ClouDNS პირად ანგარიშში Reseller API მენიუში, თქვენ უნდა შექმნათ ახალი მომხმარებლის 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 root@199.247.18.199:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/

სერთიფიკატების რეგულარულად განახლებისთვის, შექმენით ყოველდღიური CRON სამუშაო ორივე სერვერზე ბრძანებით:

scp -r root@199.247.18.199:/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 სერთიფიკატისა და საკვანძო ფაილებისკენ
• proxy_cache_valid - ქეშირებული მონაცემების შენახვის დრო
• proxy_pass — ორიგინალური სერვერის მისამართი, საიდანაც CDN ითხოვს ფაილებს ქეშირებისთვის. ჩვენს მაგალითში ეს ამბობენ.ში

როგორც ხედავთ, ყველაფერი მარტივია. სირთულე შეიძლება წარმოიშვას მხოლოდ ქეშირების დროის დაყენებაში დირექტივების მსგავსების გამო უმოქმედო и proxy_cache_valid. მოდით გავაანალიზოთ ისინი ჩვენი მაგალითით. აი რა ხდება როდის არააქტიური=7დ и proxy_cache_valid 90d:

• თუ მოთხოვნა არ განმეორდება 7 დღის განმავლობაში, მაშინ მონაცემები წაიშლება ქეშიდან ამ პერიოდის შემდეგ
• თუ მოთხოვნა მეორდება მინიმუმ 7 დღეში ერთხელ, მაშინ ქეშის მონაცემები ჩაითვლება მოძველებულად 90 დღის შემდეგ და Nginx განაახლებს მას შემდეგი მოთხოვნით, აიღებს მას ორიგინალური სერვერიდან.

დასრულდა რედაქტირება nginx.conf, გადატვირთეთ კონფიგურაცია:

root@cdn:~# service nginx reload

ჩვენი CDN მზად არის. 15$/თვეში. ჩვენ მივიღეთ ყოფნის წერტილები სამ კონტინენტზე და 3 ტბ ტრაფიკი: 1 ტბ თითოეულ ადგილას.

CDN-ის მუშაობის შემოწმება

მოდით შევხედოთ პინგებს ჩვენს CDN-ზე სხვადასხვა გეოგრაფიული მდებარეობიდან. ამისთვის იმუშავებს ნებისმიერი პინგ სერვისი.

გაშვების წერტილი
მასპინძელი
IP
საშუალო დრო, ms

გერმანია ბერლინი
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

Singapore
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

შედეგები კარგია. ახლა ჩვენ განვათავსებთ სატესტო სურათს მთავარი საიტის ძირში test.jpg და შეამოწმეთ მისი ჩამოტვირთვის სიჩქარე CDN-ის საშუალებით. ნათქვამია - დამზადებულია. შინაარსი სწრაფად მიეწოდება.

მოდით დავწეროთ პატარა სკრიპტი იმ შემთხვევაში, თუ გვსურს ქეშის გასუფთავება CDN წერტილზე.
გაწმენდა.შ

#!/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-ის შეცდომის ტოლერანტობის გასაზრდელად, რეკომენდებულია DNS Failover-ის კონფიგურაცია, რაც ხელს უწყობს A ჩანაწერის სწრაფად შეცვლას სერვერის გაფუჭების შემთხვევაში. ეს კეთდება დომენის მართვის პანელის DNS ჩანაწერებში.
• ფართო გეოგრაფიული დაფარვის მქონე საიტები უდავოდ მოითხოვს CDN-ების დიდ რაოდენობას, მაგრამ ნუ ვიქნებით ფანატიკოსები. სავარაუდოდ, მომხმარებელი ვერ შეამჩნევს მნიშვნელოვან განსხვავებას ფასიან CDN-თან შედარებით, თუ სერვერებს განათავსებთ 6-7 ლოკაციაზე: ევროპა, ჩრდილოეთ ამერიკა (აღმოსავლეთი), ჩრდილოეთ ამერიკა (დასავლეთი), სინგაპური, ავსტრალია, ჰონგ კონგი ან იაპონია.
• ზოგჯერ ჰოსტერები არ უშვებენ დაქირავებული სერვერების გამოყენებას CDN მიზნებისთვის. ამიტომ, თუ მოულოდნელად გადაწყვეტთ კონტენტის მიწოდების ქსელის სერვისად გამოყენებას, არ დაგავიწყდეთ წინასწარ წაიკითხოთ კონკრეტული ჰოსტინგის პროვაიდერის წესები.
• Გამოკვლევა წყალქვეშა კომუნიკაციების რუკაწარმოადგინოს როგორ არის დაკავშირებული კონტინენტები და გაითვალისწინოს ეს კონტენტის მიწოდების ქსელის შექმნისას
• შეეცადეთ შეამოწმოთ პინგები სხვადასხვა ადგილიდან თქვენს სერვერებზე. ამ გზით თქვენ შეგიძლიათ ნახოთ CDN წერტილებთან ყველაზე ახლოს მდებარე რეგიონები და უფრო სწორად დააკონფიგურიროთ GeoDNS
• ამოცანებიდან გამომდინარე, სასარგებლო იქნება Nginx-ის დაზუსტება ქეშირების სპეციფიკური მოთხოვნებისთვის და სერვერზე დატვირთვის გათვალისწინებით. ამაში ძალიან დამეხმარა სტატიები Nginx ქეშის შესახებ - აქ და სამუშაოს დაჩქარება მძიმე ტვირთის ქვეშ: აქ и აქ

წყარო: www.habr.com