Mer datorkraft, mindre kostnad
Datorkraft är dyrt. Stora uträkningar kräver hög prestanda. Elobina stod inför ett problem där de behövde en kraftig server för att kunna generera stora bildfiler för tryck, men relativt sällan. Problemet med det här är att stora servrar är dyra, oavsett om de används ett par timmar i veckan eller om de används dygnet runt. Men tänk om man bara hade behövt betala för den tid man faktiskt nyttjar processorkraften, istället för att betala för en maskin som är igång dygnet runt?
Den andra oktober 2017 införde AWS (Amazon Web Services) att de tar betalt per sekund som deras servrar är igång, istället för per påbörjad timme som det var tidigare. Det här gör det möjligt att sätta upp större och dyrare servrar som bara behöver köras ett par minuter, och som sedan kan stängas ner så fort de är klara.
Vi valde att utnyttja det här för att lösa Elobinas problem. Tanken var att de ska kunna skapa en lista med bilder som ska genereras, utan att behöva vänta flera timmar på att bildfilerna ska skapas. Notera dock att AWS Lambda också möjliggör det vi ville åstadkomma, det vill säga att få tillgång till mycket datorkraft vid behov och slippa betala för den tid som vi inte behöver. Vi valde att inte använda oss av AWS Lambda då det innebar tekniska begränsningar så som tillgängligt minne.
Idé och utförande
För att hantera filer som ska genereras satte vi upp en kö med hjälp av AWS’s tjänst SQS (Simple Queue Service). SQS tillåter tjänster att skicka meddelanden mellan sig, och i vårt fall för att köa bildfiler som ska genereras. Vi använde oss därefter av AWS CloudWatch för att övervaka om kön innehåller några filer som ska genereras; finns det något i kön så startas ett larm om att kön behöver hanteras.
Vi hade sedan tidigare en större server uppsatt hos Amazon som användes just för att kunna bearbeta de här tyngre filerna, den här servern konfigurerade vi om att vid uppstart läsa från vår kö i AWS SQS.
Det sista vi behövde var ett sätt att starta upp och stänga ner servern efter behov. För det här använde vi oss av EC2 Auto Scaling; en tjänst för att starta upp och stänga ner servrar baserat blanda annat på larm från AWS CloudWatch. Vanligtvis används EC2 Auto Scaling för att starta upp fler servrar vid till exempel hög belastning, men i vårt fall ville vi bara starta upp en server när det fanns jobb i kön. Vi kopplade på de larm vi skapade via CloudWatch, med parametrarna att starta upp en server så fort det fanns jobb att utföra i kön, och att sedan stänga ner den aktiva servern så fort jobbkön var tom.
Det slutgiltiga flödet blev att när vi lägger till ett jobb i kön så går ett larm igång, vilket resulterar i att en server startar upp, som betar av listan med jobb tills kön är tom. När kön slutligen är tom går ett annat larm av, som säger till EC2 Auto Scaling att stänga ner aktiva servrar.
Resultat
På grund av att vi inte behöver ha en server uppe dygnet runt, så kunde vi gå upp i serverstorlek. Det här resulterade i att filer som tidigare kunde ta 40 minuter att generera istället nu bara tar fem minuter. Det här i kombination med att servern bara är igång under tiden som filer behöver genereras resulterar i att kostnaderna för den större servern är lägre än kostnaderna för den gamla mycket mindre servern.
Slutresultatet blev att filerna genereras snabbare och till en billigare driftskostnad! Vi har dessutom möjlighet att när som helst höja nivån ytterligare om så skulle behövas. Finns där något du kan tänka dig som du skulle vilja ha billigare och bättre? Kontakta oss på NewSeed så hjälper vi dig ta fram förslag!
Uppföljning 2019-02-05
Den här lösningen blev bättre än vi vågat hoppas på. Under januari var servern igång endast ca 16,5 timmar av 744. Detta ledde till en total driftskostnad på $1.67! Läs hela uppföljningen här på vår sida.