Eiti prie turinio 
Kelių CDN priegloba tampa aktuali, kai vienas paslaugų teikėjas nebegali patikimai palaikyti pasaulinio našumo ir pastebimi sutrikimai. Parodysiu, kada vienas CDN neveikia, kaip keli tinklai sąveikauja tarpusavyje ir kaip galima optimizuoti našumą, Prieinamumas ir išlaidas tuo pačiu metu.
Centriniai taškai
- Apsauga nuo gedimų naudojant perjungimą įvykus gedimui ir alternatyvius maršrutus.
- Veikimas per kelių CDN regioninius pajėgumus
- Mastelis viršūnėms, renginiams ir naujoms rinkoms
- Išlaidų kontrolė pagal srauto ir kainos logiką
- Apsauga su nuoseklia politika ir WAF
Kada CDN nebepakanka?
Vienas CDN pasiekia savo galimybių ribas, kai naudotojai visame pasaulyje Vėlavimas viršūnės lemia klaidas arba SLA svyravimus. Kai tik atskiri regionai dažnai būna lėtesni arba atsiranda laiko viršūnių, pasikliauju bent dviem papildomais paslaugų teikėjais. Jei reguliariai kyla maršruto parinkimo problemų, ilgesnės talpyklos praleidimo grandinės ar pasikartojančios PoP perkrovos, pereinu prie kelių CDN strategijos. Taip pat naudoju apsauginius tinklus, apsaugančius nuo prastovų, kai vyksta tiesioginiai renginiai, pristatymai ar kampanijos su dideliu srautu. Jei norite įsigilinti, galite rasti glaustą įvadą į Kelių CDN strategijos, kuriame apibendrinami praktiniai atvejai ir atrankos kriterijai.
Kaip veikia "Multi-CDN
Sujungiu kelis tinklus ir valdymo užklausas per DNS, "Anycast" ir realaus laiko signalus į kokybė. Duomenų srauto tvarkytuvas nustato paskirties vietas pagal vėlavimą, paketų praradimą, prieinamumą ir sąnaudas. Jei paskirties vieta atšaukiama arba kokybė pablogėja, įvyksta perjungimas, ir maršruto parinktuvas siunčia naujas užklausas į geresnį CDN. Turinį suskirsčiau pagal tipą: paveikslėliai, vaizdo įrašai, HTML ir API gali naudoti skirtingus tinklus. Taip galiu išnaudoti stipriąsias atskirų paslaugų teikėjų puses ir nepasikliauti vienu Infrastruktūra būti priklausomam.
diegimo planas ir migracijos strategija
"Multi-CDN" diegiu žingsnis po žingsnio: pirmiausia Kanarų eismas 1-5 proc. į antrąjį tinklą, stebimą naudojant RUM ir sintetinius patikrinimus. Įvedimo etape trumpam (30-120 sekundžių) nustačiau DNS TTL, kad būtų galima greitai ištaisyti maršrutizavimo sprendimus. Ribines konfigūracijas (antraštės, CORS, suspaudimas, Brotli/Gzip, HTTP/3) riboju iki minimumo. Identiškas ir patikrinkite juos naudodami lyginamuosius testus. Dokumentuoju talpyklos raktus, slapukų ir užklausos parametrų normalizavimą, kad būtų galima atkurti skirtingų CDN pasiekimus. Tik tada, kai p95 / p99 yra stabilūs, padidinu srautą kiekvienoje rinkoje. Prieš paleidimą praktikuoju išvalymą, klaidų puslapius, TLS perjungimą ir perjungimą įvykus gedimui Etapinė sritis su realaus eismo šešėliais (šešėlinis eismas), kad išvengtumėte netikėtumų X dieną.
Tipiniai taikymo scenarijai ir ribinės vertės
Jei regionas įkeliamas 20-30 proc. lėčiau arba piko dienomis padaugėja klaidų, pereinu prie kelių CDN. Net ir plečiant veiklą į naujus žemynus, kelios CDN iš karto pastebimai Privalumai, nes prieigos taškai yra arčiau naudotojų. Elektroninėje prekyboje svarbi kiekviena sekundė, todėl nuo visuotinės kampanijos planavimo pradžios skaičiuoju antrą ar trečią tinklą. Srautinių renginių atveju du kartus užtikrinu atsisiuntimų segmentus ir paskirstau žiūrovus į geriausią maršrutą. Jei pasiekiu API spartos ribas arba TLS rankų paspaudimus, papildomus pajėgumus pritraukiu per antrąjį tinklą. Teikėjas į.
Atranka ir kepimas: kriterijų katalogas
Prieš pasirašydamas bet kokią sutartį, patikrinu Kepimo konkursas su realiais apkrovos profiliais. Lyginu: regioninių PoP tankį ir tarpusavio ryšius, HTTP/3/QUIC kokybę, IPv6 aprėptį, spartos ribas, kraštinių skaičiavimų galimybes, valymo SLA, objektų dydžio ribas, užklausos antraštės ribas ir nuoseklumą. Registravimas ir metrikos. Būtina atkuriama konfigūracija per API/IaC, kad galėčiau sinchronizuoti skirtingų paslaugų teikėjų politiką. Taip pat tikrinu teisinius reikalavimus (duomenų buvimo vietos, antriniai tvarkytojai), palaikymo atsako laiką ir Planai funkcijų, kurių man prireiks per artimiausius 12-24 mėnesius. Lemiamas veiksnys yra ne teorinis didžiausias pralaidumas, bet Stabilumas p95/p99 reikšmių, esant apkrovai, ir klaidų tvarkymas kraštiniais atvejais.
Maršrutizavimo žvalgyba: "Anycast", DNS ir RUM
Derinu "Anycast DNS" greitam paskirties vietos rinkimui su aktyviu matavimu naudojant sintetinius patikrinimus ir realių naudotojų RUM duomenis. Valdiklis naudoja signalus Vėlavimas, trikdžius, nuostolius ir HTTP klaidas, kad būtų galima nuolat teikti pirmenybę tikslams. Vengiu atsitiktinio paskirstymo, nes jis didina išlaidas ir blogina kokybę. Vietoj to nustatau deterministines taisykles ir svorį pagal rinką, paros laiką ir turinio tipą. Tokiu būdu kiekvienas sprendimas išlieka skaidrus ir galiu nustatyti prioritetus Maitinimas tikslingai tobulinti.
Eismo politika ir valdymo logika: pavyzdžiai
Apibrėžiu taisykles, kurios pasiteisino praktikoje: sunku Juodieji sąrašai blogesniems regionams pagal CDN, minkštus svorius mažiems kokybės skirtumams ir Išlaidų koridoriai kiekvienai šaliai. Kampanijų atveju didinu palankių CDN dalį tol, kol vėlavimo ir (arba) klaidų rodikliai išlieka mažesni už ribines vertes. API atveju, griežtesni TTFB ir Prieinamumas-slenksčiai nei vaizdams. Nuo laiko priklausančiose taisyklėse atsižvelgiama į vakaro pikus arba sporto įvykius. Histerezė yra labai svarbi, kad maršrutas nesvyruotų trumpalaikių šuolių metu. Saugau sprendimų žurnalus, kad vėliau galėčiau suprasti, kodėl užklausa buvo priskirta tam tikram tinklui.
Išlaidų kontrolė ir sutartys
Planuoju išlaidas eurais per mėnesį ir paskirstau srautą ekonomiškai pagrįstoms kryptims. Daugelis CDN siūlo apimties skalę už GB; viršijus tam tikras ribas, faktinė vieno pristatymo kaina sumažėja. Nustatau biudžeto ribas kiekvienam regionui ir perkeliu apkrovą, kai kainos pakyla arba pajėgumai tampa riboti. Palaikau buferį įvykių dienoms ir deruosi dėl minimalių pirkimų su aiškiais SLO. Taikant šią drausmę Kainos Paslauga yra nuspėjama, o naudotojai ir toliau aptarnaujami greitai.
Domenų talpyklos patvirtinimas ir nuoseklumas
Kelių CDN aplinkoje Išvalyti-Saugumas yra labai svarbus. Naudoju pakaitinius raktus ir (arba) žymes, kad grupės būtų pripažintos negaliojančiomis, ir išbandau „momentinį išvalymą“ iš visų paslaugų teikėjų su vienodais naudingaisiais krūviais. Jei įmanoma, naudoju švelnų išvalymą ir (arba) senumo žymėjimą, kad išvalymo metu naudotojams ir toliau būtų teikiamos paslaugos (stale-while-revalidate, stale-if-error). Griežtai riboju neigiamas talpyklas (4xx/5xx), kad išvengčiau klaidų plitimo. Kiekvienam turinio tipui atskirai nustatau TTL ir užtikrinu vienodų Keisti-strategijos. Dinaminių variantų atveju saugau valymo eiles ir tikrinu rezultatus atsitiktine atranka (URL hash sąrašai), kad nė vienas CDN neliktų pasenęs.
Išlaikykite nuoseklų saugumą
Visiems tinklams taikau tuos pačius TLS standartus, DDoS apsaugą ir WAF gaires. Standartizuotos taisyklės sumažina atakų plotą ir užkerta kelią konfigūracijos skirtumams, kurie vėliau sukelia klaidų. Automatizuoju sertifikatų valdymą ir keičiu raktus pagal nustatytas taisykles. Intervalai. Turiu identiškas API ir botų apsaugos taisykles ir centralizuotai registruoju metrikas. Tai padeda išlaikyti Gynyba vienodai, nepriklausomai nuo to, kuris CDN aptarnauja užklausą.
Tapatybės, žetonų ir raktų valdymas
Saugomam turiniui naudoju Pasirašyti URL adresai ir JWT su aiškiu galiojimu, auditorijos ir leidėjo patikrinimais ir laikrodžio nuokrypio tolerancijomis. Pagrindinę medžiagą keičiu per centrinę KMS, kuri gali automatiškai aprūpinti visus CDN. Išlaikau nuoseklius raktų ID, kad atnaujinimas vyktų be prastovų, ir atskiriu rašymo raktus nuo skaitymo raktų. HLS/DASH apsaugau Grojaraščiai ir segmentus tolygiai, įskaitant trumpus TTL žetonus kiekvienam segmentui. Kiekviena taisyklė yra versija kaip kodas, kad galėčiau iš karto atpažinti nukrypimus tarp paslaugų teikėjų.
Stebėsena ir išmatuojamumas
Vienu metu vertinu iš naudotojo perspektyvos ir iš galinės dalies. RUM duomenys parodo, kaip apkroviami tikri lankytojai; sintetiniai testai anksti atskleidžia maršruto nustatymo problemas. Klaidų biudžetai kontroliuoja mano išleidimo greitį, SLO susieja maršrutizavimo sprendimus su aiškiomis ribomis. Standartizuotame prietaisų skydelyje CDN lyginami naudojant vienodus pagrindinius duomenis ir atskleidžiami nukrypimai. Be patikimo Stebėsena "Multi-CDN" lieka aklas; norėdamas priimti patikimus sprendimus, naudojuosi skaičiais.
Stebimumas ir registravimas
Pridedu žurnalus į centrinį Schema kartu: request_id, edge_pop, tls_version, http_protocol, cache_status, origin_status, bytes, costs-attribution. Imties imtį reguliuoju pagal įvykius (pilna, kai 5xx, sumažinta, kai 2xx). Siekiant užtikrinti duomenų apsaugą, krašte užmaskuoju asmeninius duomenis. Koreliacijos su galiniais pėdsakais leidžia atlikti pagrindinių priežasčių analizę tarp sistemų ribų. Kalibruoju įspėjimus pagal p95/p99 ir Tendencijos o ne tik griežtas ribas, kad galėčiau anksti ir patikimai atpažinti pablogėjimą.
Turinio skaidymo į dalis ir spartinančiosios talpyklos strategijos
Aš padalinau turinį: HTML ir API reikia greito TTFB, vaizdams naudingi PoP su dideliu kraštiniu pajėgumu, vaizdo įrašams reikia didelio Srautas. Kiekvieno tipo talpyklos raktus, TTL ir variantus laikau atskirai, kad talpyklos pasiektų aukštą lygį. Pasirašyti URL adresai ir žetonai apsaugo saugomą turinį, o viešas turtas talpinamas į talpyklą agresyviai. Statiškas turinys gali būti platinamas plačiai, o į dinamišką turinį reaguoju netoli šaltinio, naudodamasis sumaniais kraštiniais skaičiavimais. Šis atskyrimas tampa vis labiau Pataikymo rodikliai iš bet kurio CDN.
Kilmės architektūra ir ekranavimas
Planuoju Kilmė - skydai už CDN, kad palengvintumėte galinę dalį ir išvengtumėte griausmingų bandų. Dėl pasaulinio vėlavimo naudoju regionines replikas (pvz., saugyklos kibirus) su nuosekliu negaliojimo srautu. TLS tarp CDN ir pradinio tinklo yra privalomas; tikrinu SNI, abipusį TLS ir ribojamuosius IP leidimus arba privačias jungtis. Dideliems medijos failams nustatau diapazono užklausas ir Vidutinio lygio talpyklos kad pakartotiniai bandymai neužtvindytų "Origin". Atsilikimo strategijos ir grandinės pertraukikliai apsaugo nuo kaskadinių klaidų, jei atskiri regionai sugenda.
Srautinės transliacijos ir vaizdo įrašų priegloba: ypatingos funkcijos
Vaizdo įrašo atveju skaičiuojamas pradžios laikas, atstatymo sparta ir pastovi bitų sparta. Prieš svarstydamas kainas, segmentus nukreipiu pagal nuostolius ir drebėjimą, nes vizualinis patogumas lemia konvertavimą. Prisitaikantis bitų srautas naudingas dėl pastovaus vėlavimo, todėl tikrinu tikslus pagal segmento dydį. Dideliems renginiams planuoju apšildomąjį srautą ir turiu paruoštus rezervinius kelius. Jei norite patobulinti savo pristatymą, žr. CDN optimizavimas konkretūs svertai Srautinė transliacija.
HTTP versijos ir transporto protokolai
Įsitikinu, kad visi CDN HTTP/2 ir HTTP/3/QUIC yra stabilūs, o 0-RTT veikia tik tais atvejais, kai atkūrimas nekelia jokios rizikos. Lyginu TCP derinimą (pradinis langas, BBR) ir H3 parametrus apkrovos testuose. IPv6 yra privalomas; atskirai testuoju p95 v4 ir v6, nes kai kuriuose tinkluose v6 kelias turi geresnius maršrutus. TLS standartai (min. 1.2, pageidautina 1.3) ir OCSP susegimas yra standartizuoti; nustatau vienodus šifrus, kad būtų išvengta sesijos pakartotinio naudojimo ir Veikimas atkuriamas.
Pagrindiniai skaičiai ir SLO, kurie yra svarbūs
Neturint aiškių tikslų, bet koks optimizavimas yra silpnas, todėl daugybę CDN valdau naudodamas keletą griežtų rodiklių. Naudoju vizualinius rodiklius, tokius kaip LCP suvokiamai kokybei, TTFB ir talpyklos pasiekimo rodiklius kraštų kokybei. Matuoju prieinamumą iki sekundės ir atskirai vertinu klaidų tipus pagal 4xx ir 5xx. Stebiu kiekvieno regiono ir kiekvieno GB išlaidas, kad galėčiau dinamiškai perkelti srautą. Toliau pateiktoje lentelėje nurodyti tipiniai tikslai, kad Komandos laikykitės krypties.
| Pagrindinis skaičius | Tikslinė vertė | Pastaba |
|---|---|---|
| Vėlavimas (95 psl.) | < 200 ms | kiekvienam regionui reguliariai patikrinkite |
| TTFB (95 psl.) | < 300 ms | Atskirai įvertinkite HTML/API |
| Spartinančiosios atmintinės pataikymo rodiklis | > 85 % | Skirstymas pagal turinio tipą ir priemonė |
| Prieinamumas | > 99,95 % | sintetinis ir RUM koreliuoja |
| Atkūrimo dažnis (vaizdo įrašas) | < 1,0 % | Suderinti segmentų dydžius ir tikslus |
| Vieno GB kaina | Biudžeto intervalas € | kontrolė pagal regioną ir pritaikyti |
Eksploatavimas, bandymai ir chaoso inžinerija
Planuoju Žaidimų dienos realiomis gedimo šalinimo pratybomis: užspauskite DNS paskirties vietas, laikinai atjunkite visą CDN, imituokite talpyklos ištrynimus. Veiksmų knygose pateikiami aiškūs bendravimo su incidentu žingsniai, eskalavimo paslaugų teikėjams būdai ir atsarginė logika. Kas šešis mėnesius išbandau sertifikatų atnaujinimą, raktų rotaciją, WAF taisyklių diegimą ir avarinius valymus. Praktikuoju TTL strategijas su kintamais laiko langais, kad avariniu atveju nereaguočiau per lėtai arba per daug agresyviai. Kiekvienos pratybos baigiasi Pomirtiniai tyrimai, kuriuos pritaikau prie politikos ir automatizavimo.
Architektūros pavyzdys: daugiaautoritetis DNS + 3 CDN
Atskiriu autoritetingąjį DNS į du nepriklausomus paslaugų teikėjus ir trumpiesiems maršrutams naudoju "Anycast". Virš to yra srauto tvarkytuvas, kuris realiuoju laiku įvertina paskirties vietas ir kontroliuoja perjungimą. Trys CDN yra skirtingo pajėgumo: vienas Šiaurės Amerikai, vienas EMEA ir vienas Azijos ir Ramiojo vandenyno regionui. Saugumo politika, sertifikatai ir registravimas yra standartizuoti, kad būtų galima greitai atlikti auditą. Dėl regioninio platinimo verta atkreipti dėmesį į Geografinis apkrovos balansavimas, kuriuos susieju su vėlavimo ir sąnaudų signalais, kad Viršūnės perimti.
Atitiktis ir duomenų vieta
Laikau Duomenų vieta nuosekliai: Žurnalai ir kraštinių skaičiavimų duomenys išlieka tame regione, kuriame jie sukurti. Jautrioms rinkoms apibrėšiu geografines taisykles, pagal kurias užklausos nukreipiamos tik per įgaliotuosius prieigos taškus. Įgyvendinu standartizuotus saugojimo laikotarpius, maskavimo ir prieigos kontrolės priemones ir jas dokumentuoju audito tikslais. Reguliariai tikrinu pagalbinių duomenų tvarkytojų sąrašus; kai atliekami pakeitimai, įvertinu riziką ir alternatyvas. Regionuose, kuriuose yra specialūs tinklai, planuoju specialius maršrutus ir tikrinu Atitiktis prieš padidinant srautą.
Trumpai apibendrinant: Sprendimo patikrinimas
Užduodu sau penkis klausimus: ar regione dažnai būna didelis Vėlavimas? Ar per renginius ar kampanijas našumas prastėja? Ar neįmanoma palaikyti prieinamumo vien tik tinklu? Ar daugėja palaikymo bilietų dėl laiko trukmių, nors galinė dalis yra sveika? Ar išlaidos ir SLO neatitinka tikslų, nors optimizavimas jau atliktas? Jei čia prikibčiau vieną ar daugiau kartų, planuočiau kelių CDN prieglobą - su aiškiais rodikliais, nuosekliu saugumu ir maršrutizavimu, kuris optimizuoja našumą ir prieinamumą. Išlaidos vienodai.
