Paano Kumita ng $1 Milyon Gamit ang AWS sa Isang Taon

Kung napunta ka sa page na ito sa pag-aakalang yayaman ka sa ilang pamamaraan ng mabilisang pagyaman, ikinalulungkot kong biguin ka. Mas gugustuhin ng artikulong ito kung paano bawasan ang iyong mga singil sa cloud cost ng $1 milyon. Sa paggawa niyan, magkakaroon ka ng dagdag na milyong dolyar sa kita — na maaari mong gastusin sa pagbili ng aking online na kurso kung paano yumaman gamit ang AWS ( link sa kurso dito ).

Kadalasang napapansin at hindi napapansin ang halaga ng cloud sa simula ng mga proyekto ng Mga Kumpanya. Natuklasan ng 2021 HashiCorp survey na halos 40% ng mga kumpanya ang gumastos nang labis sa mga gastos sa ulap noong 2021 [ 1 ]. Noong 2023, halos lahat ng kumpanya (94%) ay umamin na sila ay nag-aaksaya ng pera sa cloud [ 1 ] at hindi bababa sa 30% ng cloud cost ang nasayang [ 2 ]. Ang paggasta sa ulap ay halos $500 bilyon noong 2022 — samakatuwid ang pinag-uusapan natin ay tungkol sa $150 bilyon na nasayang sa isang taon!!

Hindi lamang ito ay isang alalahanin ng mga napalampas na kita kundi pati na rin ang mga mahihirap na kasanayan sa pagpapanatili. $150 bilyon ng nasayang na enerhiya!

Kasama sa mga natuklasang ito ang malalaking negosyo gayundin ang mas maliliit, mula sa high-cloud maturity hanggang sa low-cloud maturity. Ito ay tumutukoy sa AWS, ngunit ang parehong mga prinsipyo ay maaaring ilapat sa anumang iba pang cloud provider. Kaya, kung ang anumang bahagi ng iyong trabaho ay nasa cloud, kung gayon ang artikulong ito ay para sa iyo.

Nagsasalita ako mula sa pananaw ng data engineer, ngunit ang parehong mga natutunan ay maaaring ilapat sa iba pang mga kasanayan sa software engineering.

Sumisid tayo.

Ano ang kinakailangan upang gumastos ng $1 milyon sa mga gastos sa ulap sa isang taon?

Ang ganitong uri ng cloud bill ay karaniwang pinaghihigpitan sa napakalaking negosyo na nagpapatakbo sa buong mundo kasama ang milyun-milyong customer.

Upang mabigyan ka ng ideya, ang isang $1 milyon na cloud bill ay maaaring magresulta mula sa isang Spark ETL na pagpoproseso ng trabaho ~1.5Tb bawat oras 24x7 para sa 365 araw sa isang taon. Ang isa pang halimbawa ay maaaring isang application na tumatanggap ng bilyun-bilyong kahilingan sa isang araw mula sa maraming lokasyon sa mundo.

Sa isang malaking enterprise, may daan-daang application sa ganitong laki — na nagreresulta sa bilyong dolyar na mga kontrata sa mga cloud-provider. Halimbawa, may pangako ang Airbnb na gumastos ng $1.2 bilyon sa mga mapagkukunan ng ulap sa loob ng limang taon sa pagtatapos ng 2019 [3 ].

Sa Expedia, binawasan namin ang mga gastos para sa pagpoproseso ng data na ETL na nagkakahalaga ng $1.1 milyong dolyar sa isang taon hanggang sa $100,000 lamang sa isang taon sa pamamagitan ng pagpapatupad ng mga kasanayan sa pag-optimize. Iyan ay 91% na bawas sa gastos!!

Hindi lahat ng kumpanya ay may mga application na napakalaking laki ngunit isipin na bawasan ang iyong cloud cost ng 90% para lamang sa isang application o para sa iyong buong kumpanya.

Paano tayo magsisimulang mag-ipon?

HAKBANG 1: Hamunin ang iyong mga pagpapalagay sa disenyo

Pumunta at kumuha ng listahan ng iyong mga pinakamahal na application at hamunin ang iyong mga pagpapalagay sa disenyo .

• Gumagawa ka ba ng application na may 99.999% availability at sub-millisecond latency ngunit sa totoo lang ay magiging sapat ang mga user na may 99% availability at daan-daang millisecond latency?
• Gumagawa ka ba ng mga dataset na may bilyun-bilyong row ngunit gagamit lang ng mga pagsasama-sama ng ilan sa mga panukala ang mga user?
• Real-time ka bang nagla-landing ng data ngunit isang beses lang sa isang araw sinusuri ang data?
• Nire-refresh mo ba ang cache tuwing 10 segundo ngunit talagang nagbabago lang ito sa mga araw?

Ang lahat ng mga tanong na ito ay bumalik sa pinakamahalagang tanong: paano gagamitin ang application? Ano ang halaga ng negosyo para umiral ito? Paano tayo tinutulungan ng application na makamit ang isang ibinigay na layunin?

Siyempre, ang lahat ng mga sagot na ito ay madalas na hindi malinaw sa simula ng isang proyekto; ngunit iyon ang dahilan kung bakit ang disenyo ay dapat palaging isang umuulit na proseso — nagbibigay-daan sa mga pagbabago na mangyari nang walang putol hangga't maaari. Dapat tanggapin ng mga inhinyero ang ebolusyon at pagbabago, na iniayon ang pag-unlad ng application sa epekto.

HAKBANG 2: I-fine-tune ang iyong mga mapagkukunan ng imprastraktura sa iyong mga pangangailangan

Ang ikalawang hakbang ay binubuo ng pagbibigay sa application ng mga tamang mapagkukunan at pag-tune nito sa tamang imprastraktura.

Bilang isang inhinyero, magkaroon ng kamalayan kung paano kinakalkula ang mga gastos sa cloud. Halimbawa, ang AWS ay nagbibigay ng mga spot instance, kung saan maaari kang mag-bid para sa presyo ng cluster — partikular itong kapaki-pakinabang kung mayroon kang fault-tolerant at flexible na application. Gamitin ang mga ito kung magagawa mo — inaangkin ng AWS ang hanggang 90% na pagbawas sa mga gastos [ 4 ].

Ang ilang iba pang mga pagsasaalang-alang na maaari mong tugunan ay:

• Naglilingkod ka ba sa mga customer sa buong mundo o sa isang heograpikal na lugar lamang? Kailangan mo ba talaga ang iyong imprastraktura upang mabuhay sa buong mundo o maaari mo ba itong i-set up nang mas malapit sa iyong customer base?
• Masyado mo bang binibigyan ang iyong mga cluster instances? Subukang tiyakin na may sapat na kapasidad upang mahawakan ang mga peak load nang walang mga hindi kinakailangang gastos. Gamitin ang auto-scaling upang dynamic na isaayos ang mga mapagkukunan batay sa aktwal na pangangailangan, na pumipigil sa labis na pagbabayad para sa mga idle na mapagkukunan.
• Kung nagtatrabaho ka sa data at Spark, tiyaking nauunawaan mo ang mga konsepto at pag-tune ng Spark! Kung hindi mo gagawin, tingnan ang mga sumusunod na mapagkukunan [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ].

HAKBANG 3: Gumamit ng mga instance ng AWS Graviton

May kaunti o walang mga disbentaha sa paggamit ng mga instance ng AWS Graviton. Ang AWS ay namuhunan nang malaki sa paglikha ng mga pinaka-cost-effective na processor. Maaari kang makakuha ng hanggang 40% na pagbawas sa paggasta sa cloud sa pamamagitan lamang ng paglipat mula sa isang intel-based na processor patungo sa isang ARM-based na processor [ 10 ].

Ang tanging babala dito ay ang iyong application ay kailangang tugma sa mga ARM-based na processor kung saan tumatakbo ang Graviton. Kung nakikitungo ka sa isang pinamamahalaang serbisyo tulad ng RDS o OpenSearch, walang anumang komplikasyon sa paglipat — ang AWS ay tumatalakay sa pinagbabatayan na OS at pagkakatugma ng application. Kung gumagawa ka ng sarili mong application, maaaring kailanganin mong i-recompile ang package depende sa kung aling wika ang iyong ginagamit — Walang pagbabago ang Java at iba pang mga wika samantalang nangangailangan ng pansin ang Python.

HAKBANG 4: Subaybayan ang iyong paggasta sa gastos at turuan ang kamalayan sa gastos

Panghuli, huwag kalimutang patuloy na subaybayan ang iyong mga gastos para sa mga hindi inaasahang peak at sorpresa. Ang gastos sa araw 0 ng iyong aplikasyon ay magiging iba sa gastos sa araw na 170. Tiyaking sinusubaybayan mo ang mga pagbabago, at nauunawaan mo kung bakit nangyayari ang pagbabago: ito ba ay nagsasalansan ng mga gastos sa pag-iimbak ng s3 o ito ay isang one-off lang spike?

I-set up ang mga kinakailangang alerto at mga gabay sa pagpapatakbo !

Mahalaga, ipatupad ang mga tag ng paglalaan ng gastos upang subaybayan ang paggastos ayon sa departamento, proyekto, o kapaligiran. Iwasan ang panganib na lumikha ng data swamp kung saan ang gastos ay hindi masusubaybayan o nangangailangan ng mahabang paglalakbay sa iba't ibang log system. Ito ay dapat na mabilis at simple upang bumalik sa anumang ibinigay na gastos sa aplikasyon.

Mga huling pag-iisip

Saan ka man nagtatrabaho, mahirap balansehin ang paghahatid ng mga bagong feature sa pag-optimize ng mga kasalukuyan. Sino ang hindi na-pressure na maghatid ng mga bagong kakaibang feature sa bilis ng liwanag.

Gayunpaman, ito ay mahalaga para sa parehong mga inhinyero at mga tagapamahala na gumawa ng sinadya at maagap na mga desisyon tungkol sa kanilang mga kasalukuyang proyekto, pamamahala ng mga panganib at pagkakataon nang epektibo.