Stop met geld verspillen aan Cloud Cold Starts: een praktische oplossing

Uw klant klikt op een knop. Ze wachten. En wachten. Uw serverless-functie zit vast in een "cold start."

Deze vertraging doet pijn. Het frustreren van gebruikers. Het maakt uw app traag aanvoelen. En het ergste van alles, u betaalt voor die inactieve tijd terwijl de cloud uw code opstart.

Stel dat u die wachttijd kunt verkorten met een aanzienlijk deel zonder uw toepassing opnieuw te schrijven? Nieuw onderzoek toont aan dat dit mogelijk is.

Wat onderzoekers ontdekten

Onderzoekers van MIT hebben onderzocht waarom serverless-functies zo langzaam opstarten. Ze ontdekten dat de opstarttijd in twee duidelijke delen kan worden opgesplitst.

1. Platforminstellingen. Dit is de taak van de cloudprovider. Het omvat het downloaden van uw code, het maken van een beveiligde omgeving en het laden van de runtime (zoals Node.js of Python). U heeft weinig controle over dit proces.

2. Toepassingsinitialisatie. Dit is de taak van uw code. Het omvat het laden van bibliotheken, het verbinden met databases, het lezen van configuratiebestanden en het uitvoeren van uw eigen opstartlogica. Dit is waar u een grote invloed op heeft.

Stel uzelf voor dat het een bezorging van eten is. Platforminstellingen zijn het restaurant dat uw bestelling voorbereidt. Toepassingsinitialisatie is de chauffeur die het eten bij u thuisbezorgt. Als de chauffeur een lange, omweg neemt, is uw eten nog steeds koud.

De belangrijkste bevinding? Onderzoekers hebben een systeem genaamd "initscripts" gemaakt om het tweede deel aan te pakken - de initialisatie van uw toepassing.

Initscripts werken door delen van uw toepassing van tevoren voor te bereiden. Het is alsof u een voorverwarmde oven heeft in plaats van te wachten tot deze elke keer opwarmt wanneer u iets wilt bakken. Ze houden kritieke componenten warm en klaar, zodat wanneer een aanvraag binnenkomt, uw functie rechtstreeks naar de hoofdtaak kan springen.

U kunt het volledige artikel hier lezen: Snel einde-aan-einde cloudtoepassingscold-start met initscripts.

De figuur uit het onderzoek toont waar de tijd wordt besteed tijdens een cold start. Het 'Init'-gedeelte is de initialisatie van uw toepassing - het primaire doelwit voor optimalisatie.

Dit is belangrijk omdat voor korte taken de cold-startlatentie een groot deel van de totale tijd is. Als een taak 1000 ms duurt en 800 ms cold start is, vermindert het verkorten van de initialisatietijd rechtstreeks de totale uitvoeringsduur en uw cloudrekening.

Hoe u dit vandaag kunt toepassen

U hoeft niet te wachten tot cloudproviders initscripts bouwen. U kunt dezelfde principes nu toepassen om uw functies te versnellen. Hier is hoe.

Stap 1: Meet uw initialisatietijd

U kunt niet repareren wat u niet meet. Eerst moet u erachter komen hoe lang de opstarttijd van uw app duurt.

Hoe u het doet:

1. Voeg gedetailleerde logging toe aan het begin van uw functiehandler.
2. Log een tijdstempel direct wanneer de functie wordt aangeroepen.
3. Log een andere tijdstempel nadat alle initialisatiecode is uitgevoerd (bijv. nadat databaseverbindingen zijn gevestigd, configuraties zijn geladen).
4. Het verschil is uw initialisatietijd.

Voorbeeld in AWS Lambda (Node.js):
```javascript
let startTime = Date.now();
let dbConnection;

// Uw initialisatiecode
async function initialize() {
const config = await loadConfigFromS3();
dbConnection = await connectToDatabase(config.dbUrl);
await cacheReferenceData();
return Date.now() - startTime;
}

// De hoofdhandler
exports.handler = async (event) => {
if (!dbConnection) {
const initDuration = await initialize();
console.log(Cold start-initialisatie duurde: ${initDuration}ms);
}
// ... hoofdlogica
};
```

Stap 2: Identificeer en lazy-load zware afhankelijkheden

Importeert u grote bibliotheken bovenaan uw bestand? Verbindt u zich direct met elke externe service? Dit vertraagt elke cold start.

Hoe u het doet:

1. Controleer uw importverklaringen en initialisatiecode.
2. Voor elke zware bibliotheek of serviceverbinding die niet nodig is voor elke functie-uitvoering, verplaats deze naar de specifieke codepad die deze gebruikt.
3. Dit wordt lazy loading genoemd.

Voorbeeld: In plaats van dit bovenaan uw bestand:
```python
import huge_machine_learning_library # Traag om te importeren
import generate_pdf_library # Alleen gebruikt voor één rapporttype

def handler(event):
# Hoofdlogica
``}

Doe dit:
```python
def handler(event):
if event['reportType'] == 'pdf':
import generate_pdf_library # Alleen geïmporteerd wanneer nodig
generate_pdf_library.create(event)
# Hoofdlogica
``}

Stap 3: Gebruik vooraf toegewezen concurrency (de huidige "initscript")

Grote cloudplatforms bieden een functie die het initscriptconcept rechtstreeks nabootst: Vooraf toegewezen concurrency (AWS Lambda), Minimale instanties (Google Cloud Run) of Premium-plannen (enkele serverless-platforms).

Hoe u het doet:

1. Voor bedrijfskritieke, gebruikersgerichte functies (zoals uw login-API of checkout-proces), betaalt u een beetje extra om één of meer instanties "warm" te houden.
2. Het platform initialiseert uw functie van tevoren. De volgende aanvraag slaat de cold start over.
3. Dit is een directe afweging: u betaalt een kleine, doorlopende vergoeding om latentiesprongen te elimineren.

Schat de kosten: Als een functie 100 ms initialisatietijd heeft en 100.000 keer per maand wordt aangeroepen, betaalt u voor 10.000 seconden (2,7 uur) aan pure initialisatieberekenings tijd. Vooraf toegewezen concurrency kan minder kosten dan die verspilde tijd en zal zeker de gebruikerservaring verbeteren.

Stap 4: Optimaliseer uw implementatiepakket

Het platform moet uw code downloaden. Maak dat sneller.

Hoe u het doet:

1. Verklein pakketgrootte. Gebruik tools zoals webpack (Node.js) of pip install --no-deps (Python) om alleen noodzakelijke code te bundelen.
2. Gebruik lagen. Voor AWS Lambda, plaats grote, algemene afhankelijkheden (zoals database-stuurprogramma's) in een aparte Laag. Lagen worden in de cache opgeslagen, dus ze worden niet op elke cold start gedownload.
3. Kies een mager runtime. Een aangepaste runtime op basis van een minimale Linux-afbeelding (zoals alpine) kan sneller opstarten dan een volledige standaardruntime.

Het onderzoek toont aan hoe het verminderen van de initialisatietijd (het oranje gedeelte) de totale runtime voor korte functies aanzienlijk vermindert.

Stap 5: Architectuur voor stateless initialisatie

Ontwerp uw functie zodat de initialisatie die wel moet gebeuren, eenvoudig en herhaalbaar is.

Hoe u het doet:

1. Verplaats complexe instellingen (bijv. het compileren van sjablonen, het laden van grote AI-modellen) naar een aparte, warme service of cache deze extern (zoals in Amazon S3 of Redis).
2. Laat uw functie het vooraf berekende resultaat ophalen bij het opstarten. Het downloaden van een snelle cache is vaak sneller dan het opnieuw opbouwen van scratch.
3. Houd functiehandlers echt stateless. Push-state naar externe databases of caches.

Waar u op moet letten

Deze benadering is krachtig, maar heeft beperkingen.

1. Het lost platformoverhead niet op. Initscripts richten zich op uw initialisatiecode. U bent nog steeds afhankelijk van de snelheid van uw cloudprovider bij het downloaden van binaries en het instellen van de sandbox. Kies providers die bekend staan om snelle cold starts.
2. Complexiteitstrade-off. Lazy loading en geavanceerde optimalisatie maken uw code complexer. Pas deze technieken alleen toe op high-traffic, latentiegevoelige functies. Over-engineer geen achtergrondtaak die één keer per dag wordt uitgevoerd.
3. Kosten van warme instanties. Het gebruik van vooraf toegewezen concurrency voegt een vaste maandelijkse kostenpost toe. Modelleer deze kosten tegen de besparingen van vermindering van de uitvoeringsduur en de bedrijfswaarde van snellere antwoorden voordat u deze overal inschakelt.

Uw volgende stap

Begin met meten. Kies deze week uw meest belangrijke klantgerichte serverless-functie. Voeg de initialisatietijdslogboeken van Stap 1 toe. U zult waarschijnlijk verbaasd zijn over hoeveel tijd wordt besteed aan het alleen maar klaar zijn.

Zodra u uw basislijn kent, pak de laaghangende vruchten aan: lazy-load één zware bibliotheek of schakel vooraf toegewezen concurrency in op één kritieke functie.

Hoeveel seconden wachttijd van de klant (en compute-afval) zijn verborgen in uw cold starts vandaag?