Upload direktno na S3 s potpisanim URL-om, umjesto preko backenda

Kad sam počeo raditi na državnom sistemu za lične karte i pasoše, prvo sam pročitao račun za cloud. Bio je osam puta veći nego što je trebalo, iz tri odvojena razloga. Ovdje pišem o trećem, jer u njemu griješe skoro svi i jer najlošije podnosi rast.

Svaki zahtjev za ličnu kartu ili pasoš u tom sistemu bio je upload: fotografije lica, fotografije dokumenata i biometrijski podaci snimljeni na terenu. Svaki od tih fajlova putovao je do skladišta preko backenda.

Obrazac izgleda bezazleno. Fajl stigne na vaš server, middleware ga baferuje, kod ga validira, a onda ga pošaljete u object storage:

1app.post('/upload', upload.single('file'), async (req, res) => {2  await s3.putObject({3    Bucket: BUCKET,4    Key: key(req),5    Body: req.file.buffer,6  })7  res.json({ ok: true })8})

Pritom se dešavaju tri stvari koje na malom deploymentu ne primijetite.

Svaki bajt zauzima memoriju instance. Fotografija od 4 MB drži 4 MB RAM-a dok traje zahtjev, pa pedeset istovremenih uploada drži 200 MB koji ne rade ništa osim što čekaju. Na kraju instancu dimenzionišete prema najvećem broju istovremenih uploada umjesto prema poslu koji aplikacija radi.

Svaki bajt uz to dvaput prelazi mrežu, od klijenta do vašeg servera i od servera do skladišta. Plaćate prenos koji nije morao postojati, a plaćate ga još jednom latencijom, jer upload klijenta nije gotov dok vaš server ne završi svoj.

Granicu propusnosti tada određuje instanca, a ne skladište. Object storage prima daleko više istovremenih upisa nego bilo koji pojedinačni aplikacioni server. Kad server stavite u sredinu, servis napravljen za takvo opterećenje zamijenite onim koji za njega nije napravljen.

Ništa od ovoga ne izbacuje grešku. Vidite samo veću instancu, sporije uploade i račun za koji mislite da je normalna cijena rada sistema.

Klijent uploaduje direktno u skladište, a vaš server bajtove nikad ne vidi. Server samo odlučuje smije li se upload desiti i potpisuje URL koji dopušta taj jedan upload i ništa više. AWS takav URL zove presigned URL.

1// server: authorize, then sign2app.post('/upload-url', requireAuth, async (req, res) => {3  const key = `applications/${req.user.id}/${randomUUID()}`4 5  const url = await getSignedUrl(6    s3,7    new PutObjectCommand({8      Bucket: BUCKET,9      Key: key,10      ContentType: req.body.contentType,11    }),12    { expiresIn: 300 },13  )14 15  res.json({ url, key })16})

1// client: upload straight to storage2const { url, key } = await api.post('/upload-url', {3  contentType: file.type,4})5 6await fetch(url, {7  method: 'PUT',8  body: file,9  headers: { 'Content-Type': file.type },10})11 12await api.post('/applications', { photoKey: key })

Server ovdje provjerava ko traži, odlučuje gdje fajl smije završiti i postavlja kratak rok isteka, a da pritom ne dotakne nijedan bajt fajla.

Fajl više ne možete pregledati prije nego što stigne, pa prije potpisivanja provjerite ono što možete: content type, prijavljenu veličinu i ko traži. Ostalo provjerite kad objekt već postoji. U praksi je to korak koji pročita sačuvani objekt i odbaci ga ako nije ono za šta se izdavao.

Server uz to više ne zna kad je upload završen. To mu javlja klijent, a klijenti lažu ili nestanu. Zato ili provjerite da objekt postoji prije nego što zapis smatrate potpunim, ili se pretplatite na događaje iz skladišta i pustite da se zapis sam dovrši.

Potpisani URL koji je iskorišten, a nikad potvrđen, iza sebe ostavi objekt na koji ne pokazuje nijedan zapis. Lifecycle pravilo koje u jednom prefiksu briše takve objekte ne košta ništa, a poštedi vas toga da za njih saznate tek godinu dana kasnije.

Pet minuta je obično dobar rok isteka: dovoljno dugo za sporu vezu, a dovoljno kratko da URL koji procuri ne vrijedi ništa do trenutka kad ga neko pronađe.

Dozvolu dajte što užu. Potpisani URL je ovlaštenje, pa ga potpišite za jedan ključ, jednu metodu i jedan content type.

Na tom projektu ovo je bila jedna od tri izmjene, a zajedno su spustile mjesečni račun s 24.000 $ na 2.000 $. Ova je bila najvažnija zbog prirode proizvoda. Svaki zahtjev u njemu bio je upload, pa je većina posla sistema išla putanjom uploada.

Instance su postale manje jer više nisu držale fajlove, a uploadi brži jer je svaki fajl putovao jednom umjesto dvaput. Granica propusnosti preselila se sa servera koje smo vodili mi na skladište koje vodi Amazon.

Ponekad treba. Ako fajl morate obraditi prije pohranjivanja, na primjer promijeniti mu veličinu, transkodirati ga, ukloniti metapodatke ili ga skenirati na malver prije nego što bude sačuvan bilo gdje, bajtovi moraju stići do nečega što taj posao može obaviti.

I tada je bolje da fajl naknadno iz skladišta povuče worker nego da svaki bajt prolazi kroz vaš API server. Provjerite i treba li vam išta od ovoga, ili fajlovi idu preko servera samo zato što je tako bilo u tutorijalu.