Ska du använda ett S3-alternativ för objektlagring?

0
11
Shutterstock/Gorodenkoff

Amazon’s Simple Storage Service (S3) tillhandahåller ett mycket användbart gränssnitt för att lagra objekt i redudant molnlagring, där du inte behöver oroa dig för den underliggande hårdvaran. Utöver att vara en tjänst som erbjuds av Amazon, är det också ett industristandard API, och det finns många tjänster som är kompatibla med det.

Vad Är S3-kompatibel?

I många fall, om du flyttar till en annan molnleverantör, måste du omarbeta mycket av din applikation. Men om du använder S3 som din objektlagringsbackend kommer du att kunna flytta sömlöst till många andra tjänster.

Detta beror på att S3 är en öppen API-standard. AWS's Simple Storage Service är bara en implementering av denna standard; det är inbyggt och kommer uppenbarligen att ha det bästa stödet, men det finns andra tjänster som erbjuder acceptabel prestanda och stabilitet, ofta till lägre kostnad.

Att byta till dessa tjänster är lätt—du måste helt enkelt ändra URL-slutpunkten som din applikation använder, och det är vanligtvis bra att gå efter några mindre justeringar av nyckelhanteringen. Du måste migrera dina data med rclone, men det är ingen svår process, bara en lång process i vissa fall.

Det är ingen hemlighet att AWS är dyrt. S3 är inte annorlunda, och även om det är väldigt billigt att lagra filer, är det faktiskt inte så att få åtkomst till dessa filer. I en typisk läs/skrivtung arbetsbelastning som serverar livefiler till användare, är det vanligtvis billigt att lagra filerna; de högsta kostnaderna är faktiskt AWS dataöverföringsavgifter och S3 begärandeavgifter:

Annons

När du ser en kostnadsutforskare som denna, kanske du är frestad att överväga en tredjepartstjänst som kommer att vara billigare på dataöverföringsavgifterna för din arbetsbörda.

De två stora konkurrenterna till AWS S3 är från Google och Microsoft. Google har sitt okreativa namn “Cloud Storage,” och Microsoft Azure har Azure Blob Storage. Googles lagring är S3-kompatibel och är relativt lätt att migrera också. Azure, å andra sidan, är inte S3-kompatibel, även om det finns verktyg som S3Proxy som kan lappa ihop dem.

Men alla lagringstjänster från de tre stora molnleverantörerna kommer att debitera dig höga avgifter för data. De är designade för företagskunder, och om du är ett litet företag som försöker minimera dina kostnader bör du leta någon annanstans. Det finns andra alternativa molnleverantörer som Digital Ocean och Vultr som erbjuder mer strömlinjeformade prismodeller med liknande kvalitetstjänster.

Digitala havet

< /p>

Digital Ocean är en molnleverantör designad för att vara enkel. Även om den inte erbjuder lika många funktioner som stora leverantörer som AWS, fungerar den vanligtvis precis som de tjänster den erbjuder. En av dessa tjänster är objektlagring, där hinkar kallas Spaces, och det är vad vi kommer att rekommendera om du funderar på att flytta bort från AWS.

Utrymmen är ganska enkla. Baspriset är 5 USD i månaden och inkluderar 250 GB lagringsutrymme tillsammans med en hel TB utgående dataöverföring. Det här är en vansinnigt bra affär—samma användning skulle kosta över 90 USD på AWS S3.

Ytterligare datalagring är 0,02 USD per GB, ganska standard jämfört med S3 (men högre om du planerar att använda billigare arkiv lagring), och ytterligare data är rimligt prissatt till 0,01 USD per överförd GB, vilket är 90 % billigare än AWS-priser.

Annons

Naturligtvis kommer detta med några gränser, och tyvärr finns det många fler nackdelar och strängar kopplade till denna fantastiska affär.

  • 750 förfrågningar, per IP-adress, till alla dina utrymmen.< /li>
  • 150 kombinerade operationer per sekund till valfritt utrymme, inte inklusive GET-förfrågningar.
  • Totalt 240 operationer inklusive GET-förfrågningar.
  • 5 PUT- eller COPY-förfrågningar per 5 minuter till något enskilt objekt i ett utrymme

Även om dessa räntegränser inte är bra att ha, är gränserna ganska generösa och du kommer sannolikt inte att nå dem. Om du är nära att gå över kan du minimera effekten av dem genom att ha flera mellanslag. Om du är osäker kan du aktivera bucket-statistik i S3 för att kontrollera din nuvarande användning.

RELATERAT: Hur man aktiverar och visar förfrågningsstatistik för en AWS S3 Bucket i CloudWatch

Dessutom kan utrymmen med över 3 miljoner objekt, eller 1,5 miljoner med versionering aktiverad, kräva “intermittenta underhållsperioder” för att säkerställa konsekvent prestanda. Däremot har jag personligen en hink med över 2 miljoner versionerade objekt som inte har tyckts ha upplevt någon betydande stilleståndstid under 6 månader, så detta kanske inte är en vanlig företeelse.

En stor nackdel med Spaces jämfört med S3 är gränssnittet. Spaces är enkelt, och om du bara vill ladda upp ditt webbplatsinnehåll eller lagra några grundläggande filer, tillåter webbgränssnittet uppladdningar, nedladdningar och redigering av de flesta inställningar. Men om du lagrar många filer eller behöver avancerad konfiguration, är det uppriktigt sagt ganska dåligt, och du måste huvudsakligen arbeta med det över S3 API.

Till exempel—Spaces har inte ens en webbredigerare för att välja din livscykelkonfiguration, som hanterar lagring av gamla versioner av objekt som används som säkerhetskopior i händelse av att användaren raderas. Det betyder också att det inte finns något sätt att komma åt eller ta bort versionerade objekt utan att lista versionerna via API:et och komma åt dem direkt med versions-ID.

De har inte heller mycket dokumentation. För att aktivera versionshantering, till exempel, var vi tvungna att konsultera S3’s egen dokumentation för att använda den mestadels ignorerade PutBucketVersioning-slutpunkten, som tack och lov stöds på Spaces trots att den ignoreras i DO’s dokument. Du måste aktivera det via denna slutpunkt:

PUT ?versionshantering <VersioningConfiguration xmlns=”http://s3.amazonaws.com/doc/2006-03-01/”> <Status>Aktiverad</Status> </VersioningConfiguration>

Och aktivera sedan versionens utgång:

PUT ?lifecycle <LifecycleConfiguration xmlns=”http://s3.amazonaws.com/doc/2006-03-01/”> <Regel> <ID>Hink</ID> <Prefix>*</Prefix> <Status>Aktiverad</Status> <NoncurrentVersionExpiration> <NoncurrentDays>90</NoncurrentDays> </NoncurrentVersionExpiration> </Regel> </LifecycleConfiguration> Annons

API-nycklar är också väldigt grundläggande. Du kommer inte att ha granulär kontroll över enskilda hinkar, objekt eller något annat som följer med AWS IAM. Detta kan vara ett problem om du planerar att ge nycklar till tredje part.

Sammantaget är Digital Ocean-upplevelsen definitivt inte i närheten av hur bra AWS's S3 är. Men om du klarar dig bra med gränserna och inte har något emot att använda API:et för vissa uppgifter, kan det säkert spara massor av pengar på bandbreddskostnader.

Självvärd

Eftersom S3 är en öppen standard är det också något du kan vara värd för själv , vilket kommer att vara att föredra för många människor. Det finns massor av verktyg för att göra detta, men ett av de bästa är MinIO, som körs på Kubernetes (K8s).

Att vara på K8s innebär att du kan köra det på alla offentliga moln, inklusive köra det genom serverlöst K8s tjänster som AWS EKS. Men du skulle fortfarande bli föremål för bandbreddskostnader i det här fallet.

Där MinIO verkligen lyser är med dedikerade servrar, hybridmolnlösningar och körning på lokala datacenter. Om du betalar för en dedikerad nätverksanslutning till en server, kommer du inte att bli sämre om du mättar den anslutningen. Detta kan göra lagring med egen värd mycket billig om du planerar att leverera mycket data till slutanvändare.

Att köra på din egen hårdvara omfattas inte heller av samma begränsningar som tjänster som S3. Du kan vara värd för MinIO på blixtrande snabba servrar och få bättre prestanda vid läs/skriv tunga arbetsbelastningar (och du kommer inte att debiteras för förfrågningar). Naturligtvis kommer du att behöva betala hårdvarukostnaderna för denna prestanda.

Annons

Där det faller platt är på redudans—eftersom S3 lagrar din data på så många olika platser, 8217;s i princip garanterat att alltid fungera och aldrig förlora din data, med undantag för en gigantisk meteor. MinIO, å andra sidan, kan vara värd på en enda server eller genom en distribuerad distribution. Om du är värd på en enda server kommer du att bli snål om din instans går ner. Det är det billigaste alternativet, men vi rekommenderar starkt flera servrar i ett kluster eller åtminstone att göra någon form av backup till S3.

MinIO är gratis att vara värd under GNU AGPL-licensen, men du vann& #8217;inte får något stöd. Företagslicenser börjar på $1000/månad och ger support dygnet runt samt en “Panic Button,” som kommer att ha sina dataåterställningsingenjörer redo att hjälpa dig åtgärda allvarliga serverfel.