Ako optimalizovať náklady na Amazon S3?

Webové služby Amazonu (AWS), a najmä službu Simple Storage (S3), široko používa mnoho jednotlivcov a spoločností na správu svojich údajov, webových stránok a serverov. Tie siahajú od izolovaných jednotlivcov a malých startupov až po hodnotiace spoločnosti s miliardami dolárov, ako sú Pinterest a (predtým) Dropbox. Táto stránka nie je zamýšľaná ako sprievodca inštaláciou S3; na internete nájdete mnoho ďalších takýchto sprievodcov. Je zameraný skôr na jednotlivcov a spoločnosti, ktorých očakávané náklady na S3 sa pohybujú medzi 7,50€ mesačne a 7460€ mesačne. Ďalšie podobné zoznamy tipov sú k dispozícii online.

Táto stránka sa tiež nezaoberá inými druhmi optimalizácií S3, ako je optimalizácia segmentu, názvov priečinkov a súborov a poradia operácií zameraných na maximalizáciu priepustnosti alebo minimalizáciu latencie. Väčšina týchto optimalizácií neovplyvňuje náklady priamo (pozitívne ani negatívne). Okrem toho sa spravidla stávajú relevantnými iba v podstatne väčšom rozsahu, ako je rozsah, v ktorom sa pravdepodobne bude nachádzať cieľové publikum na tejto stránke. Viac informácií o takýchto optimalizáciách si môžete prečítať v oficiálnom sprievodcovi S3 a inde.

Časť 1 zo 6: Široké porozumenie s3

1
Pochopte svoj prípad použitia s3. S3 je možné použiť na mnoho cieľov.
- Ako miesto na ukladanie súborov na živé zobrazovanie na webových stránkach vrátane obrazových súborov alebo celého statického webu (spravidla za sieťou CDN, ako je Amazon CloudFront alebo CloudFlare).
- Ako „dátové jazero“, miesto pre údaje, ktoré spotrebúvate alebo ktoré generujete vo svojich aplikáciách: S3 sa v zásade stáva dlhodobým úložiskom pre vaše údaje, pričom vaše pôvodne vygenerované údaje sa zaznamenávajú do S3 a rôzne aplikácie čítajú zo S3., transformácia údajov a zápis späť do S3.
- Ako „dátový sklad“ miesto na ukladanie dlhodobých záloh štruktúrovaných a neštruktúrovaných dát, ktoré nie sú určené na ďalšiu aktívnu spotrebu.
- Ako miesto na uloženie spustiteľných súborov, skriptov a konfigurácií potrebných na spustenie nových inštancií EC2 s vašimi aplikáciami (alebo aktualizáciu aplikácií na existujúcich inštanciách).
2
Pochopte hlavný spôsob, akým s3 ovplyvňuje náklady. Nasledujúce čísla sú určené pre štandardné úložisko. Oznamy súvisiace s inými formami ukladania sú prediskutované neskôr. Všetky náklady sa uplatňujú a vykazujú osobitne pre každé vedro a každú hodinu; inými slovami, ak si stiahnete podrobný prehľad o fakturácii, zobrazí sa vám jedna riadková položka pre každú kombináciu segmentu, hodiny a typu ceny.
- Náklady na skladovanie: Náklady sa merajú v úložnom priestore vynásobené časom. Za pridelené množstvo úložného priestoru neplatíte vopred. Zakaždým, keď použijete viac ukladacieho priestoru, zaplatíte za toto extra úložisko príplatok za množstvo času, ktorý využijete. Náklady sa preto môžu v priebehu času meniť, pretože sa zmenil objem uložených údajov. Náklady na skladovanie sa vykazujú osobitne pre každé vedro každú hodinu. Ceny sa líšia podľa regiónov, ale sú v rámci každého regiónu fixné. V marci 2020 sa náklady pohybujú od 2,3 centov za GB-mesiac v americkom štandarde (Severná Virgínia) do 405 centov za GB-mesiac v Sao Paule.
- Požadovaná cena: V prípade štandardného úložiska sa náklady na žiadosti PUT, COPY, POST alebo LIST pohybujú od 0€ za 1000 žiadostí v regiónoch USA do 0€ za 1000 žiadostí v Sao Paule. Náklady na GET a všetky ostatné žiadosti sú rádovo menšie v rozsahu od 0€ za 10000 žiadostí vo všetkých regiónoch USA do 0€ za 10000 žiadostí v Sao Paule. Všimnite si však, že väčšina nákladov spojených s požiadavkou GET je zachytená v nákladoch na prenos dát (ak je žiadosť podaná mimo regiónu). Upozorňujeme, že v prípade údajov uložených v iných druhoch ukladacieho priestoru je cena za žiadosť o niečo vyššia. Ďalším druhom požiadaviek, ktoré sa stávajú relevantnými pri diskusii o zásadách životného cyklu, je žiadosť o prechod životného cyklu (napr. Prechod niečoho zo štandardného úložiska na IA alebo ľadovec).
- Náklady na prenos dát: Náklady sú v rámci tej istej oblasti AWS nulové (inštancie S3 -> S3 aj S3 -> EC2), približne 2 centy za GB za prenos údajov medzi regiónmi a približne 9 centov za GB za prenos údajov do externých AWS.
- Ceny za vyhľadávanie: To sa nevzťahuje na štandardné úložisko, ale skôr na dve ďalšie triedy úložísk, konkrétne IA a Glacier. Táto cena sa vzťahuje na GB za získané údaje.
3
Pochopte ústrednú úlohu vedier pri organizovaní súborov s3 a používanie „objektu“ pre súbory s3.
- Pod svojim účtom môžete vytvárať segmenty. Vedro je identifikované reťazcom (názov vedra). V celom S3 môže byť medzi zákazníkmi iba jeden segment s daným názvom segmentu; preto možno nebudete môcť používať názov segmentu, ak ho už používa niekto iný.
- Každý segment je priradený k oblasti AWS a je replikovaný vo viacerých zónach dostupnosti v rámci tejto oblasti. Informácie o zóne dostupnosti nie sú k dispozícii koncovému používateľovi, ale predstavujú interný detail implementácie, ktorý pomáha S3 udržiavať vysokú trvanlivosť a dostupnosť údajov.
- Do každého segmentu môžete uložiť svoje súbory priamo pod vedro alebo do priečinkov. Priečinky nie je potrebné vytvárať ani odstraňovať. Ak súbor uložíte, automaticky vytvorí existujúce „priečinky“, aby cesta k súboru mala zmysel, ak ešte neexistujú. Akonáhle sa pod ním nenachádzajú žiadne súbory, priečinok automaticky prestane existovať.
- S3 ukladá informácie ako úložisko kľúč-hodnota: pre každú predponu, ktorá nie je názvom súboru, ukladá sadu súborov a priečinkov s touto predponou. Pre každý názov súboru to namapuje na skutočný súbor. Najmä rôzne súbory vo vedre môžu byť uložené vo veľmi odlišných častiach dátového centra.
- S3 nazýva svoje súbory „objekty“ a s týmto pojmom sa môžete stretnúť pri čítaní informácií o S3 inde.
4
Pochopte rôzne spôsoby interakcie so súbormi s3.
- Súbory môžete nahrávať a sťahovať online prihlásením sa prostredníctvom prehliadača.
- Medzi nástroje príkazového riadka založené na Pythone patrí rozhranie príkazového riadka AWS, zastarané s3cmd a novšie s4cmd.
- Ak používate Javu alebo iný jazyk, ktorý je založený na JVM (napríklad Scala), k objektom S3 máte prístup pomocou AWS Java SDK.
- Nástroje na nasadenie, ako sú Ansible a Chef, ponúkajú moduly na správu zdrojov S3.
5
Pochopte výhody a nevýhody zaobchádzania s s3 a jeho odlišnosti od tradičného súborového systému.
- S S3 vyžaduje trochu viac gymnastiky (a času behu), aby ste získali celkový obraz o množstve údajov použitých v vedre alebo v podpriečinkoch tohto vedra. Je to preto, že tieto údaje sa nikde nezaznamenávajú priamo, ale je potrebné ich vypočítať pomocou rekurzívnych vyhľadávaní kľúč-hodnota.
- Nájdenie všetkých súborov, ktoré zodpovedajú regexu, môže byť veľmi nákladná operácia, najmä ak tento regex obsahuje zástupné znaky v strede výrazu a nie na konci.
- Nie je možné vykonávať operácie, ako je pridávanie údajov do súboru: musíte súbor získať, upraviť ho a potom celý upravený súbor znova zálohovať (informácie o možnostiach synchronizácie nájdete nižšie).
- Presúvanie alebo premenovanie súborov v skutočnosti zahŕňa odstraňovanie objektov a vytváranie nových. Presunutie priečinka zahŕňa odstránenie a opätovné vytvorenie všetkých objektov pod ním. Každý presun súboru zahŕňa volanie GET a PUT, čo vedie k zvýšeniu cien za žiadosť. Pohybujúce sa objekty môžu byť navyše drahé, ak sú objekty uložené v triedach úložiska (Standard-IA a Glacier), kde načítanie stojí peniaze.
- S3 môže podporovať veľkosti súborov až 5 TB, ale prenos údajov medzi regiónmi sa môže začať zamotávať pri súboroch s veľkosťou viac ako niekoľko stoviek megabajtov. CLI používa pre veľké súbory viacdielne nahrávanie. Uistite sa, že ak vaše programy pracujú s veľkými súbormi, fungujú prostredníctvom viacdielneho nahrávania alebo rozdelia výstup na menšie súbory.
- S3 neposkytuje plnú podporu pre rsync. Existuje však príkaz synchronizácie (synchronizácia aws s3 v AWS CLI a synchronizácia s3cmd v s3cmd), ktorá synchronizuje všetok obsah medzi lokálnym priečinkom a priečinkom S3 alebo medzi dvoma priečinkami S3. V prípade súborov, ktoré existujú v zdrojovom aj cieľovom priečinku, dokáže detegovať identické súbory a vyhnúť sa prenosu údajov, ak sú súbory identické; nie je však taký účinný ako rsync, pretože v prípade, že sa súbory trochu líšia, môže byť potrebné vykonať úplný prenos, zatiaľ čo pre veľmi podobné súbory rsync posiela iba malý rozdiel. Ďalším rozdielom oproti rsync je, že sa týka celého priečinka a názvy súborov nemožno zmeniť.

Za náklady na prenos dát zaplatíte iba raz — Ak replikujete vedro na východe USA, za náklady na prenos dát zaplatíte iba raz.

Časť 2 zo 6: Zipsovanie/kompresia údajov

1
Skôr ako začnete, uistite sa, že komprimujete údaje tam, kde to umožňujú požiadavky vašej aplikácie.
- Zistite, aké formy zipovania a kompresie sú kompatibilné s procesmi, ktoré používate na generovanie údajov, a s procesmi, ktoré používate na čítanie a spracovanie údajov.
- Uistite sa, že na najväčšie skládky údajov používate zapínanie a kompresiu, pokiaľ to neprekáža vašej aplikácii. Hlavnými kandidátmi na kompresiu sú predovšetkým nespracované denníky používateľov a štruktúrované údaje založené na aktivite používateľov.
- Kompresia spravidla ušetrí nielen náklady na úložný priestor, ale aj náklady na prenos (pri čítaní/zápise údajov) a môže dokonca viesť k zrýchleniu vašej aplikácie, ak je čas nahrávania/sťahovania väčším problémom ako miestny čas kompresie/dekompresie.. Často to tak býva.
- Napríklad prevod veľkých štruktúrovaných dátových súborov na formát BZ2 môže spôsobiť zníženie úložného priestoru faktorom pohybujúcim sa od 3 do 10; BZ2 je však náročný na výpočty na zips a rozbalenie. Ďalšie kompresné algoritmy, ktoré je potrebné zvážiť, sú gzip, lz4 a zstd.
- Medzi ďalšie možné spôsoby zmenšenia priestoru patrí použitie úložiska založeného na stĺpcoch namiesto ukladania na riadkoch a použitie binárnych formátov (ako napríklad AVRO) namiesto formátov čitateľných pre človeka (napríklad JSON) na dlhodobé uchovávanie údajov.
2

Ak nie je možné komprimovať údaje v mieste, kde ich prvýkrát píšete, zvážte spustenie alternatívneho postupu na opätovné prijatie a kompresiu údajov. Toto je vo všeobecnosti suboptimálne riešenie a je veľmi zriedka nevyhnutné, ale môžu nastať prípady, keď je to relevantné. Ak sa pozriete na takéto riešenie, budete musieť spustiť výpočty opatrne na základe nákladov na opätovné testovanie a komprimáciu údajov a celkového času, ktorý plánujete uchovať.

Časť 3 zo 6: Optimalizácia nákladov na úložisko

1
Pochopte rozdiely medzi štyrmi typmi úložiska s3.
- Štandardné úložisko je najdrahšie na ukladanie, ale je najlacnejšie a najrýchlejšie na vykonanie zmien údajov. Je navrhnutý tak, aby vydržal 99,999999999% (viac ako rok, tj. To je očakávaný zlomok objektov S3, ktoré prežijú viac ako rok) a 99,99% dostupnosť (dostupnosť odkazujúca na pravdepodobnosť, že daný objekt S3 je prístupný v danom čase). Všimnite si toho, že v praxi je veľmi zriedkavé prísť o dáta v S3 a existujú väčšie rizikové faktory pre stratu dát, ako dáta, ktoré skutočne zmiznú z S3 (medzi tieto väčšie faktory patrí náhodné vymazanie dát a niekto úmyselne nabúranie do vášho účtu za účelom odstránenia obsahu, alebo dokonca aj Amazon je nútený odstrániť vaše údaje kvôli tlaku vlád).
- Úložisko so zníženou redundanciou (RRS) bývalo o 20% lacnejšie ako štandardné úložisko a ponúka o niečo menšiu redundanciu. Možno ich budete chcieť použiť pre veľa vašich údajov, ktoré nie sú veľmi dôležité (napríklad úplné protokoly používateľov). Toto je navrhnuté pre 99,99% trvanlivosť a 99,99% dostupnosť. V decembri 2016 však zľavy na štandardnom úložisku nesprevádzali zodpovedajúce zníženia cien voči RRS, takže RRS sú v súčasnosti rovnako alebo drahšie.
- Štandardné úložisko - Infrequent Access (nazývané S3 - IA) je možnosť, ktorú Amazon predstavil v septembri 2015 a ktorá kombinuje vysokú odolnosť S3 s nízkou dostupnosťou iba 99%. Je to možnosť ukladania dlhodobých archívov, ku ktorým nie je potrebné často pristupovať, ale keď je potrebné k nim pristupovať, je potrebné k nim pristupovať rýchlo. S3 - IA je účtovaný poplatok minimálne 30 dní (aj keď sú objekty pred tým odstránené) a minimálna veľkosť objektu je 128 KB. Je to zhruba o polovicu drahšie ako S3, aj keď presná zľava sa líši podľa regiónu.
- Ľadovec je najlacnejší spôsob ukladania. Glacier však stojí za zrušenie archivácie a opätovné sprístupnenie na čítanie a zápis, pričom suma, ktorú musíte zaplatiť, závisí od počtu žiadostí o načítanie, rýchlosti, akou chcete údaje získať, a veľkosti načítaných údajov. Súbory Glacier majú tiež minimálne 90-dňovú dobu uchovávania: za súbory, ktoré boli do tej doby odstránené, sa účtuje zvyšok 90 dní po ich odstránení.
2
Zistite, ako rastú vaše náklady.
- V prípade použitia, kde máte pevnú sadu súborov, ktoré pravidelne aktualizujete (efektívne odstraňujete staršie verzie), sú vaše mesačné náklady na ukladací priestor približne konštantné s pomerne tesnou hornou hranicou. Váš kumulatívne úložisko útraty rastie lineárne. Toto je typický scenár pre sadu spustiteľných súborov a skriptov.
- V prípade použitia, keď neustále generujete nové údaje konštantnou rýchlosťou, vaše mesačné náklady na úložisko rastú lineárne. Váš Kumulatívne náklady skladovania rastie kvadraticky.
- V prípade použitia, kde samotná miera generovania údajov rastie lineárne, vaše mesačné náklady na úložisko rastú kvadraticky a vaše kumulatívne náklady na úložisko neustále rastú.
- V prípade použitia, kde je rýchlosť generovanie dát rastie exponenciálne, ako vaše mesačné náklady ukladanie dát a svoje kumulatívne náklady na ukladanie dát rastie exponenciálne rovnako.
3
Zistite, či objektová verzia má pre vaše ciele zmysel.
- Objektová verzia vám umožňuje ponechať staršie verzie súboru. Jednou z výhod je, že sa môžete vrátiť k staršej verzii.
- Keď používate verzovanie objektov, môžete ho skombinovať s politikami životného cyklu a vyradiť verzie staršie ako určitý vek (ak nejde o aktuálnu verziu).
- Ak používate objektovú verziu, majte na pamäti, že iba zoznam súborov (pomocou aws s3 ls alebo online rozhrania) spôsobí, že podceníte celkové použité úložisko, pretože vám sú účtované poplatky za staršie verzie, ktoré nie sú uvedené v zozname.
4
Pozrite sa na zásady životného cyklu vašich údajov.
- Môžete nastaviť pravidlá na automatické odstraňovanie údajov v konkrétnych segmentoch alebo dokonca s konkrétnymi predponami v rámci segmentov, ktoré sú staršie ako určitý počet dní. To vám môže pomôcť lepšie kontrolovať náklady na S3 a tiež vám pomôže dodržať rôzne zásady ochrany osobných údajov a údajov. Upozorňujeme, že niektoré zákony a zásady uchovávania údajov môžu vyžadovať, aby ste údaje uchovávali minimálny čas; tieto stanovujú dolnú hranicu doby, po ktorej môžete údaje z politík životného cyklu odstrániť. Iné zásady alebo zákony môžu vyžadovať, aby ste údaje v určitom časovom období vymazali; tieto stanovujú hornú hranicu času, po ktorom je potrebné odstrániť údaje z vašich zásad životného cyklu.
- Vďaka politike životného cyklu na vymazanie sa spôsob, akým rastú vaše náklady, veľmi mení. Teraz, pri konštantnom prúde prichádzajúcich údajov, zostanú vaše mesačné náklady na úložný priestor konštantné, a nie lineárne, pretože zatiaľ ukladáte iba pohyblivé okno údajov než všetky údaje. Aj keď veľkosť prichádzajúcich údajov rastie lineárne, vaše mesačné náklady na úložisko rastú iba lineárne a nie kvadraticky. To vám môže pomôcť prepojiť náklady na infraštruktúru s vašim príjmovým modelom: ak sú vaše mesačné výnosy zhruba úmerné rýchlosti, s akou dostávate údaje, model úložiska je škálovateľný.
- Technické obmedzenie: nemôžete nastaviť dve politiky s rovnakým segmentom, kde jedna predpona je podmnožinou druhej. Myslite na to, keď budete premýšľať o tom, ako ukladať údaje S3.
- Okrem politík životného cyklu na vymazanie môžete nastaviť aj politiky na archiváciu údajov (tj. Ich konverziu zo štandardného úložiska na ľadovec), čím sa znížia náklady na úložisko. Glacier má však minimálnu dobu uchovávania 90 dní: účtuje sa vám 90 dní úložiska v Glacieri, aj keď sa ho do tej doby rozhodnete odstrániť. Preto, ak máte v úmysle čoskoro odstrániť, pravdepodobne nie je dobré presťahovať sa na ľadovec.
- Môžete mať aj zásadu životného cyklu na prevod údajov v S3 (štandardné úložisko) na S3 - IA. Táto zásada je ideálna pre údaje, o ktorých očakávate, že k nim budete často pristupovať bezprostredne po ich vytvorení, ale zriedka potom. Súbory v IA majú minimálnu veľkosť objektu (za menšie súbory sa vám účtuje veľkosť súboru 128 kB) a minimálne 30-dňové obdobie uchovávania.
- Všimnite si toho, že samotné prechody životného cyklu stoja peniaze a často je lepšie vytvárať objekty priamo v požadovanej triede úložiska, než ich prevádzať. Budete musieť urobiť výpočty pre váš prípad použitia, aby ste vedeli, či a kedy má prechod životného cyklu zmysel.
5
Na určenie najlepšej triedy úložiska na základe prípadu použitia použite nasledujúcu heuristiku. Aj keď hovoríme, akoby sme mali do činenia s jediným súborom, v skutočnosti myslíme na nastavenie, kde sa to deje oddelene a nezávisle pre veľký počet súborov.
- Prvým krokom k určeniu správnej triedy úložiska je získať odhad veľkosti súboru, doby uchovávania, očakávaného počtu prístupov (a tiež toho, ako sa tento počet v priebehu času líši v závislosti od veku) a maximálneho času, na ktorý môžete čakať. keď potrebujete k niečomu pristupovať. Všetky tieto položky môžete použiť ako parametre vo vzorci, ktorý vypočítava očakávané náklady na používanie každej triedy úložiska. Vzorec je dosť komplikovaný.
- Presné prahové hodnoty pre tieto položky sa môžu líšiť v závislosti od aktuálnych cien vo vašom regióne. Ceny sa líšia podľa regiónov a časom sa menia. Ide najmä o nasledujúcu vec: ceny za úložisko pre každú triedu úložísk, ceny za vyžiadanie pre každú triedu úložísk, ceny za načítanie pre každú triedu úložísk a požiadavky na minimálnu veľkosť a minimálne obdobie uchovávania. S týmito výhradami je heuristika nižšie.
- Ak máte v úmysle uchovávať údaje dva týždne alebo menej, uprednostňuje sa štandardné úložisko pred úložiskom IA aj pred úložiskom Glacier. Dôvodom je, že minimálne doby uchovávania (30 dní pre IA, 90 dní pre ľadovec) rušia cenové výhody (nanajvýš dvojnásobné pre IA, asi šesťkrát pre ľadovec) na dva týždne alebo menej.
- Ak je veľkosť vášho súboru 64 kB alebo menšia, štandardné úložisko vždy prevyšuje úložisko IA. Dôvodom je, že požiadavka minimálnej veľkosti IA (128 kB) ruší cenovú výhodu (nanajvýš dvojnásobok).
- Ak máte v úmysle pristupovať ku každému súboru raz za mesiac alebo častejšie, potom v porovnaní s IA a Glacier zvíťazí štandardné úložisko. Dôvodom je, že dodatočné náklady čo i len na jedno načítanie údajov ničia úsporu mesačného úložiska.
- Povedzme, že máte údaje, ktoré musíte pôvodne uchovávať jeden mesiac v štandardnom úložisku, a potom ich môžete presunúť na IA na mesiac alebo dlhšie, pretože očakávate, že k nim potom už nebudete musieť vôbec pristupovať. Presunúť do IA má zmysel iba vtedy, ak je celkový počet megabajtov mesiacov v stave IA na súbor najmenej 1. Dôvodom je, že náklady na prechod na IA v životnom cykle je potrebné prekonať úsporou nákladov. Ak napríklad chcete údaje uchovávať ešte jeden mesiac, veľkosť súboru by mala byť aspoň 1 MB, aby sa vyplatili. Uvedomte si, že minimálne 30-dňové obdobie robí prechody na kratšie časy ešte výhodnejšími.
- Podobne pri migrácii na ľadovec je zlomová hodnota približne 2,5 megabajtu mesiaca pre každý súbor. Všimnite si však, že minimálne 90-dňové obdobie uchovávania na ľadovci to komplikuje; ak máte v úmysle ťažiť z presunu údajov na Glacier na mesiac, veľkosť súboru by mala byť 7,5 MB alebo väčšia.
- Ak očakávate, že po zapísaní do S3 nebudete potrebovať prístup k obsahu, optimálna stratégia je zvyčajne buď štandardná alebo Glacier, pričom kompromis závisí od obdobia uchovávania. Medzi tým však existuje sladké miesto, kde je najlepšou možnosťou IA (napríklad uloženie 128 kB na jeden mesiac). Na ilustráciu to ukazuje obrázok jednoduchého prípadu, kedy je potrebné uchovávať jeden súbor pevného súboru. veľkosť na pevný čas, s nulovým očakávaným prístupom po jeho uložení. Čas v mesiacoch je na horizontálnej osi a veľkosť súboru v GB je na osi y. Bod je zafarbený na modrú, červenú alebo žltú podľa toho, či je z hľadiska nákladov optimálna trieda úložiska štandardná, IA alebo ľadovec. Používame náklady ako v americkom štandardnom regióne v decembri 2016.
- Keď zvyšujete očakávaný počet prístupov k údajom, štandard sa stáva optimálnym pre stále viac prípadov použitia (tj. Pre väčšie veľkosti údajov a pre dlhšie obdobia uchovávania). IA sa začína stávať optimálnymi aj v prípadoch, kde by predtým bol optimálny ľadovec. Inými slovami, štandard preberá od IA a IA od Glacier.
6
Na základe prípadu použitia úložiska použite nasledujúce benchmarky zdravého rozumu. Pomôže vám to pochopiť, koľko môžete očakávať v súvislosti s nákladmi na úložisko.
- Ak naživo zobrazujete statický web alebo obrázky: Náklady na úložisko budú pravdepodobne niekoľko centov, pričom podrobnosti závisia od veľkosti vášho webu. Hlavnými nákladmi na obsluhu živého webu sú cena za žiadosť a náklady na prenos.
- Ak ukladáte dátové jazero, pričom hlavným prúdom generovaným používateľmi je aktivita na webe alebo v aplikáciách (tj denníky webových žiadostí): riadok denníka jednotlivých webových žiadostí sa môže líšiť v maximálnej veľkosti od 1 kB (ak ponecháte všetky štandardné hlavičky a polí) do 10 KB (ak zahrniete aj periférne informácie o používateľovi a kontexte). Ak získate milión webových žiadostí mesačne a staré denníky webových žiadostí budete uchovávať jeden mesiac, znamená to, že úložný priestor sa pohybuje medzi 1 GB a 10 GB, čo je medzi 2,3 centu a 40,5 centa za mesačné náklady na úložisko. Náklady sa lineárne menia tak s návštevnosťou, ako aj s rozhodnutím, ako dlho ich uložiť. Napríklad pri miliarde webových žiadostí mesačne a ukladaní údajov na rok sa vaše mesačné náklady na ukladanie dát vyšplhajú až niekde medzi 210€ a 3630€ Použitie binárnych formátov a zipsovanie/komprimovanie môže ešte viac znížiť náklady.
- Ak ukladáte archívy obrázkov a videozáznamov: Ak ste napríklad televízna sieť, ktorá pravidelne točí zábery a chce mať k dispozícii archívy starých záberov, ak by to neskôr bolo relevantné. Toto je prípad použitia, kde môže byť celkový úložný priestor dosť významný. Napríklad pri 10 hodinách denných videozáznamov môžete každý deň pridať niečo v rozsahu 100 GB (nekomprimované). Ak by ste tieto zábery vložili na prvý rok do štandardného úložiska a potom archivovali na Glacier ďalších deväť rokov, vaše celkové údaje by dosiahli 365 TB (36,5 TB v štandardnom úložisku) a vaše mesačné náklady na úložisko S3 (pred kompresiou) by bolo asi 1640€ (dve tretiny pre Glacier, jedna tretina pre štandardné úložisko). Kompresia rôznych druhov môže znížiť náklady na skladovanie faktorom pohybujúcim sa od 2 do 10.
- Je poučné pozrieť sa na účty niektorých používateľov napájania S3, aby ste získali predstavu o tom, ako veľmi sa môžu účty líšiť.
  - Dropbox mal údajne 500 petabajtov dát v S3, než ich presunul na svoje vlastné servery. Pri súčasných cenách uvádzaných online by to stálo asi 7,80 milióna EUR mesačne. Napriek tomu, že Dropbox pravdepodobne získal výraznú zľavu a dosiahol výhody vyplývajúce z deduplikácie a kompresie údajov, jeho účet bol pravdepodobne stále najmenej stovky tisíc dolárov mesačne.
  - Ďalším extrémnym príkladom veľkého používateľa je DigitalGlobe, ktorý do S3 presúva 100 PB satelitných snímok s vysokým rozlíšením.
  - Pinterest uviedol, že denne pridáva 20 terabajtov dát, čo v štandardnom úložisku znamená, že ich mesačný účet sa každý deň zvýši o 450€/mesiac. Ak by táto miera pridávania údajov pokračovala desať rokov, mali by celkové úložisko asi 75 PB a mesačný účet rádovo státisíce dolárov.
  - Okrem týchto extrémnych prípadov použitia však majú dokonca niektoré z najväčších svetových spoločností pomerne nízke účty za S3. Koncom roka 2013 napríklad spoločnosť Airbnb oznámila, že má 50 TB údajov z domácich fotografií vo vysokom rozlíšení, čo by pri dnešných cenách stálo približne 860€ mesačne.

Pochopte ústrednú úlohu vedier pri organizovaní súborov s3 a používanie „objektu“ pre súbory s3.

Časť 4 zo 6: Optimalizácia nákladov na prenos údajov

1
Ak používate s3 na obsah zobrazovaný naživo, vložte ho za sieť CDN, ako napríklad amazon cloudfront, cloudflare alebo maxcdn.
- CDN má veľký počet okrajových miest v rôznych častiach sveta, zvyčajne od desiatok do stoviek.
- Požiadavka používateľa na stránku je smerovaná na najbližšie umiestnenie okraja CDN. Toto okrajové umiestnenie potom skontroluje, či má aktualizovanú kópiu zdroja. Ak nie, stiahne ho z S3. V opačnom prípade doručí kópiu, ktorú má.
- Výsledok: koncoví používatelia vidia vyššiu dostupnosť a nižšiu latenciu (pretože zdroje sú obsluhované z miesta, ktoré je im fyzicky blízke) a počet žiadostí a množstvo prenosu údajov zo servera S3 je udržiavané na nízkej úrovni. Pokiaľ nikdy neaktualizujete súbory, počet žiadostí je výslovne obmedzený (počtom umiestnení na okraji) X (počtom súborov); ak aktualizujete súbory, musíte ich tiež vynásobiť počtom aktualizácií súborov.
2
Pochopte kľúčovú výhodu spoločného umiestnenia systému ec2/s3. Ak je vašim primárnym použitím pre S3 čítanie a zápis údajov do inštancií EC2 (tj. Ktorýkoľvek z prípadov použitia iných ako inštancia poskytovania živých ponúk), potom túto výhodu najlepšie využijete, ak sa váš vedro S3 nachádza v rovnakej oblasti AWS ako Inštancie EC2, ktoré do neho čítajú alebo zapisujú. Bude to mať niekoľko výhod:
- Nízka latencia (menej ako sekunda)
- Vysoká šírka pásma (viac ako 100 Mbit/s): Všimnite si toho, že šírka pásma je v skutočnosti medzi rôznymi americkými regiónmi celkom dobrá, takže to nie je závažný problém, ak sú všetky vaše regióny v USA, ale môže byť významné medzi USA a EÚ, EÚ a ázijsko-tichomorský región alebo USA a ázijsko-tichomorský región.
- Žiadne poplatky za prenos dát (cenu za žiadosť však stále platíte)
3
Určte umiestnenie (oblasť AWS) vedra (s) s3.
- Ak používate inštancie EC2, ktoré čítajú alebo zapisujú do vedier S3: Ako je uvedené v kroku 1, kolokácia S3 a EC2, pokiaľ je to možné, pomáha so šírkou pásma, latenciou a nákladmi na prenos dát. Preto pri hľadaní vášho vedra S3 je dôležité zvážiť: kde očakávate, že budú mať inštancie EC2, ktoré budú interagovať s týmto vedrom S3? Ak sú inštancie EC2 väčšinou inštancie typu backend, mali by ste zvážiť náklady na tieto inštancie. Ak ide o inštancie frontendu, zvážte, z ktorých regiónov očakávate väčšiu návštevnosť. Celkovo by ste mali očakávať, že úvahy o inštancii EC2 budú pri určovaní regiónu dôležitejšie ako úvahy o S3. Preto má spravidla zmysel rozhodnúť sa najskôr, kde očakávate kapacitu inštancie EC2, a potom tam mať svoje lopaty S3. Všeobecne,Náklady na S3 sú nižšie v rovnakých oblastiach ako inštancie EC2, takže to našťastie nespôsobuje konflikt.
- Ak existujú aj ďalšie služby AWS, ktoré musíte mať, ale nie sú dostupné vo všetkých oblastiach, môže to tiež obmedziť váš výber regiónu.
- Ak často sťahujete súbory z domáceho počítača do S3, môžete zvážiť získanie vedra v regióne bližšie k vášmu domovu, aby ste zlepšili latenciu nahrávania. Toto by však malo byť v porovnaní s ostatnými menšia úvaha.
- Ak očakávate, že budete používať S3 na živé zobrazovanie statických obrázkov, rozhodnite sa podľa umiestnenia, odkiaľ očakávate návštevnosť.
- V niektorých prípadoch zásady, ktoré ste povinní dodržiavať na základe zákona alebo zmluvy, obmedzujú váš výber regiónu pre ukladanie údajov S3. Majte tiež na pamäti, že fyzické umiestnenie vášho vedra S3 môže ovplyvniť to, čo sú vlády schopné legálne prinútiť Amazon vydať vaše údaje (aj keď tieto prípady sú pomerne zriedkavé).
4
Zistite, či má replikácia medzi regiónmi pre váš segment zmysel. Replikácia medzi regiónmi medzi segmentmi v rôznych oblastiach automaticky synchronizuje aktualizácie údajov v jednom segmente s údajmi v iných segmentoch. Zmena nemusí nastať okamžite a najmä zmeny veľkých súborov sú obmedzené obmedzeniami šírky pásma medzi regiónmi. Majte na pamäti nasledujúce výhody a nevýhody replikácie medzi regiónmi.
- Platíte viac za náklady na úložisko S3, pretože rovnaké údaje sa zrkadlia vo viacerých oblastiach.
- Platíte v S3 <-> náklady na prenos dát S3. Ak však údaje čítajú alebo zapisujú inštancie EC2 vo viacerých oblastiach, môže to byť kompenzované úsporou nákladov na prenos dát S3 -> EC2. Toto môže pomôcť hlavne vtedy, ak načítavate rovnaké údaje S3 do inštancií EC2 v mnohých rôznych oblastiach. Predpokladajme napríklad, že máte 100 inštancií na východe USA a na západe USA, kde potrebujete načítať rovnaké údaje z vedra S3 na západe USA. Ak nereplikujete tento segment na USA na východ, zaplatíte za náklady na prenos 100 dátových prenosov z vedra S3 na počítače na americkom východe. Ak replikujete vedro na východe USA, zaplatíte iba raz za náklady na prenos dát.
- Replikácia medzi regiónmi má preto veľký zmysel pre spustiteľné súbory, skripty a relatívne statické údaje, kde oceňujete redundanciu medzi regiónmi, kde sú aktualizácie údajov zriedkavé a kde je väčšina prenosu údajov v S3-> EC2. smer. Ďalšou výhodou je, že ak sa tieto údaje replikujú medzi regiónmi, je oveľa rýchlejšie roztočiť nové inštancie, čo umožňuje flexibilnejšie architektúry inštancií EC2.
- Na protokolovanie aplikácií (kde údaje načítava mnoho inštancií frontendu a je potrebné ich zaznamenávať na centrálnom mieste v S3) je lepšie použiť službu, ako je Kinesis, na zhromažďovanie dátových tokov medzi regiónmi, a nie používať medziregionálne replikované vedrá S3.
- Ak používate S3 na živé zobrazovanie statických obrázkov na webových stránkach, replikácia medzi regiónmi môže mať zmysel, ak je návštevnosť vašich webových stránok globálna a dôležité je rýchle načítanie obrázkov.
5
Ak synchronizujete pravidelné aktualizácie už existujúcich súborov, zvoľte štruktúru priečinkov, ktorá umožňuje použitie funkcie synchronizácie AWS cli.
- Príkaz „aws s3 sync“ sa správa ako rsync, ale je ho možné spustiť iba na úrovni priečinka. Preto si ponechajte štruktúru priečinkov, aby ste mohli používať tento príkaz.
6
Pri odhadovaní nákladov na prenos majte na pamäti nasledujúcu heuristiku.
- V prípade statických webových stránok, ktoré sú v prevádzke, sa mesačný prenos údajov bez systému CDN rovná celkovému času návštevnosti každej navštívenej stránky (vrátane obrázkov a ďalších zdrojov načítaných na stránke). Napríklad pre milión zobrazení stránky a priemernú veľkosť stránky 100 kB je celkový objem dát 100 GB a stojí 6,70€ mesačne.
- V prípade živých statických webových stránok za sieťou CDN ukladá sieť CDN hornú hranicu celkového prenosu údajov. Konkrétne, ak údaje neaktualizujete vôbec, aby sieť CDN obsluhovala vlastnú vyrovnávaciu pamäť, celkový prenos údajov von je obmedzený súčinom celkovej veľkosti vašich webových stránok a počtom koncových umiestnení siete CDN bez ohľadu na návštevnosť. objem. Ak má napríklad váš web celkom 1000 strán, z ktorých každá má 100 kB, celková veľkosť je 100 MB. Ak existuje 100 okrajových umiestnení, celkový limit dátového prenosu je 10 GB za mesiac alebo limit nákladov 90 centov za mesiac. Ak však aktualizujete niektoré súbory, po každej aktualizácii musíte každý súbor znova započítať.
- Rozsah, v akom siete CDN šetria, v porovnaní s tým, že nemajú žiadnu sieť CDN, závisí od rozmanitosti prístupu k vášmu obsahu a tiež od geografického rozloženia prístupu. Ak je k vášmu obsahu prístup v jednej geografickej oblasti, ušetríte viac. Ak ľudia pristupujú k malému počtu stránok na vašom webe, ušetríte viac. Ak v rámci každého regiónu ľudia pristupujú k malému počtu stránok na vašom webe (aj keď sa stránky líšia podľa regiónu), ušetríte viac. Úspora CDN sa môže pohybovať od 50% do 99%.

Prečítajte si tiež: Ako predávať hry na amazone?

Časť 5 zo 6: Optimalizácia nákladov kvôli cenám požiadaviek

1

Ak je cena za žiadosť veľkým problémom, uchovávajte svoje údaje v štandardnom úložisku. Ďalšie informácie nájdete v časti 3, krok 5.
2

Ak živo prevádzate statický web alebo statické obrázky alebo video prostredníctvom služby s3, vložte ho za sieť CDN. Je to z rovnakých dôvodov, aké sú uvedené v časti 4, krok 1.
3
Ak používate s3 ako úložisko dát na vyhľadávanie kľúč – hodnota, pri určovaní veľkostí súborov, do ktorých chcete uložiť svoje údaje, musíte vymeniť ceny za požiadavky PUT voči cenám za prenos údajov.
- Ak rozdeľujete údaje na veľký počet malých súborov, na vloženie údajov potrebujete veľký počet PUT, ale každé vyhľadávanie je rýchlejšie a používa menej dátových prenosov, pretože z S3 musíte prečítať menší súbor.
- Na druhej strane, ak rozdelíte údaje na malý počet veľkých súborov, budete potrebovať malý počet PUT, ale každý prístup stojí veľa nákladov na prenos dát (pretože potrebujete prečítať veľký súbor).
- Kompromis sa zvyčajne stane niekde uprostred. Matematicky je počet súborov, ktoré by ste mali použiť, druhá odmocnina z pomeru nákladov na náklady za prenos dát k nákladom na PUT.
4

Vo všeobecnosti je pre dátové jazero lepšie použiť menší počet stredne veľkých súborov.
5
Ak rozdeľujete údaje na súbory, použite malý počet súborov strednej veľkosti (niekde medzi 1 MB a 100 MB), aby ste minimalizovali ceny za žiadosť a preťaženie.
- Menší počet väčších súborov znižuje počet požiadaviek potrebných na načítanie a načítanie údajov, ako aj na zápis údajov.
- Pretože s každým čítaním súboru je spojená malá latencia, distribuované výpočtové procesy (ako sú procesy založené na Hadoop alebo Apache Spark), ktoré čítajú súbory, budú vo všeobecnosti postupovať rýchlejšie s malým počtom súborov strednej veľkosti ako s veľkým počet malých súborov.
- Čím menší je váš celkový počet súborov, tým lacnejšie je spúšťať dotazy, ktoré sa pokúšajú priradiť ľubovoľné regulárne výrazy.
- Dôležitou výhradou je, že v mnohých prípadoch je prirodzeným typom výstupu veľký počet malých súborov. To platí pre výstupy pracovného zaťaženia distribuovaných počítačov, kde každý uzol v klastri počíta a vydáva malý súbor. Platí to aj vtedy, ak sa údaje zapisujú v reálnom čase a chceme ich zapísať v krátkom časovom intervale. Ak očakávate, že budete tieto údaje čítať a spracovávať opakovane, zvážte zlúčenie údajov do väčších súborov. Pokiaľ ide o údaje prichádzajúce v reálnom čase, zvážte použitie streamovacích služieb, ako je Kinesis, na zhromažďovanie údajov pred ich zapísaním do S3.
6

Ak vidíte veľké neočakávané náklady na žiadosti, vyhľadajte nečestné procesy, ktoré robia zhodu regexu. Zaistite, aby akákoľvek zhoda regulárnych výrazov používa zástupné znaky čo najbližšie ku koncu súboru.
7
Pri požiadavkách na náklady majte na pamäti nasledujúcu heuristiku.
- Náklady na žiadosť by sa mali pohybovať od 0% do 20% nákladov na skladovanie. Ak sú vyššie, zvážte, či používate správnu triedu úložných priestorov, ukladáte údaje v správnych veľkostiach alebo robíte zbytočné alebo neefektívne operácie. Tiež skontrolujte nepotrebné prechody v životnom cykle, ako aj nečestné procesy zhody regulárnych výrazov.
- Náklady na žiadosti by mali byť nižšie ako náklady na prenos, ak sú vaše údaje primárne odosielané mimo AWS (ak sa vaše údaje odosielajú v rámci rovnakého regiónu AWS, nemali by existovať žiadne poplatky za prenos údajov, takže to neplatí, pretože náklady za žiadosti budú pozitívne, pričom náklady na prenos budú nulové).

Na vysokej úrovni by ste mohli chcieť nahlásiť rozdelenie nákladov medzi skladovanie, prenos a stanovovanie cien.

Časť 6 zo 6: monitorovanie a ladenie

1
Nastavte si monitorovanie nákladov na s3.
- Váš účet AWS má prístup k fakturačným údajom, ktoré poskytujú úplné rozdelenie nákladov. Nastavte upozornenie na fakturáciu, aby sa údaje začali odosielať do služby Amazon CloudWatch. Potom môžete nastaviť ďalšie upozornenia pomocou služby CloudWatch. Údaje CloudWatch prichádzajú ako dátové body každých niekoľko hodín, ale neobsahujú podrobný rozpis všetkých dimenzií záujmu.
- Kedykoľvek si môžete zo svojho root účtu stiahnuť podrobné rozpis podľa hodín a typu služby. Tieto údaje zvyčajne meškajú 24 až 48 hodín, tj. Posledných 24 až 48 hodín sa vám nezobrazia žiadne informácie. V prípade S3 si môžete stiahnuť údaje v tabuľke alebo vo formáte CSV s rozdelením na hodiny, segment, región a typ operácie (ZÍSKAŤ, POST, ZOZNAM, Vložiť, VYMAZAŤ, HEADOBJECT alebo čokoľvek, čo je vašou operáciou).
2
Píšte skripty, ktoré vám poskytnú ľahko čitateľné denné správy o vašich nákladoch rozdelené rôznymi spôsobmi.
- Na vysokej úrovni by ste mohli chcieť nahlásiť rozdelenie nákladov medzi skladovanie, prenos a stanovovanie cien.
- V rámci každého z nich možno budete chcieť rozdeliť náklady ďalej podľa triedy úložiska (Standard, RRS, IA a Glacier).
- V rámci stanovovania cien žiadostí možno budete chcieť rozdeliť náklady podľa typu operácie (ZÍSKAŤ, POST, ZOZNAM, Vložiť, VYMAZAŤ, HEADOBJECT alebo podľa toho, aké sú vaše operácie).
- Môžete tiež poskytnúť členenie podľa segmentu.
- Obecným pravidlom je, že musíte rozhodnúť o počte dimenzií, ktoré hĺbite, obchodovaním s ľahkým rýchlym porozumením a dostatočnou zrnitosťou. Všeobecne dobrým kompromisom je zahrnúť hĺbkové analýzy naraz po jednej dimenzii (napr. Jednu hĺbkovú analýzu podľa segmentu, jednu podrobnú analýzu podľa úložiska vs. cena za prenos vs. cena za žiadosť, jedno zobrazenie podľa triedy úložiska) do denného prehľadu a prejsť iba na ďalšie podrobné informácie. ak sa vám zdá niečo neobvyklé.
3
Vytvorte model očakávaných nákladov a pomocou skriptu identifikujte nezrovnalosti medzi skutočnými nákladmi a vašim modelom.
- Bez modelu, aké by mali byť náklady, je ťažké sa na ne pozrieť a zistiť, či sa mýlia.
- Proces budovania nákladového modelu je dobrým cvičením na jasné vyjadrenie vašej architektúry a potenciálne myslenie na vylepšenia aj bez toho, aby ste sa pozerali na vzor skutočných nákladov.
4
Ladenie vysokých nákladov.
- Ak sú vinníkom náklady na skladovanie, pozrite si časť 3.
- Ak sú na vine veľké náklady na prenos dát, pozrite si časť 4.
- Ak je vinníkom vyžiadanie ceny, pozrite si časť 5.

Náklady na prenos — Hlavnými nákladmi na obsluhu živého webu sú cena za žiadosť a náklady na prenos.

Tipy

Sledujte svoje náklady na Amazon S3. Nemôžete optimalizovať to, čo nemeriate. Jednou z najväčších výhod S3 je, že nemusíte príliš premýšľať o ukladaní súborov: máte efektívne neobmedzené ukladanie súborov, ktoré nie je viazané na konkrétnu inštanciu. Ponúka to veľkú flexibilitu, ale na druhej strane to tiež znamená, že stratíte prehľad o tom, koľko dát používate a koľko vás to stojí. Mali by ste pravidelne kontrolovať svoje náklady na S3 a tiež nastaviť fakturačné upozornenia AWS v službe Amazon CloudWatch, aby vás upozornili, keď náklady na S3 v danom mesiaci prekročia prahovú hodnotu.
Nepoužívajte Amazon S3 na žiadne operácie, ktoré vyžadujú latenciu menej ako sekundu. S3 môžete použiť na inicializáciu inštancií, ktoré prevádzkujú tieto operácie, alebo na pravidelné obnovovanie údajov a konfigurácií v týchto inštanciách, ale nespoliehajte sa na GETy súborov S3 pri operáciách, na ktoré musíte odpovedať do milisekúnd. Ak na protokolovanie používate S3, uložte aktivity lokálne do pamäte vo vašej inštancii frontendu (alebo ich napíšte do streamu, akým je napríklad Kinesis) a potom ich pravidelne zaznamenávajte do S3.
Nepoužívajte S3 na aplikácie, ktoré vyžadujú časté čítanie a zápis údajov. Amazon S3 je vhodný viac na strednodobé a dlhodobé zaznamenávanie údajov než ako miesto na ukladanie a rýchlu aktualizáciu a vyhľadávanie údajov. Zvážte použitie databáz (a iných úložísk údajov) na rýchlu aktualizáciu údajov. Pri S3 je dôležité pamätať na to, že nie je zaručená okamžitá konzistencia čítania/zápisu: načítanie novo zapísaného súboru môže zápisu trvať niekoľko sekúnd po zápise. Navyše, ak sa ho pokúsite použiť týmto spôsobom, uvidíte aj veľký účet, pretože cena žiadostí sa pri použití S3 týmto spôsobom zvýši.