Databricks: gids voor het opschalen van Databricks Apps

Samenvatting

Databricks Apps opschalen vraagt om prestatiedoelen, async code, herstelbare state en testen met echte belasting.

Databricks Apps: wat er gebeurt

Databricks beschrijft in een nieuwe gids hoe teams Apps laten doorgroeien van enkele gebruikers naar honderden of duizenden gebruikers. De aanpak begint vóór de eerste code: bepaal hoe snel acties moeten reageren en hoeveel gelijktijdige gebruikers de applicatie tijdens piekuren moet verwerken.

De app compute-laag bedient de gebruikersinterface en coördineert aanroepen naar andere services. Zwaar werk hoort daar niet thuis. Code moet tijdens het wachten op services responsief blijven, meerdere instanties ondersteunen en per gebruiker caching toepassen. Async code helpt daarbij.

De gids verdeelt het opschalen over vier fasen: ontwerp, bouw, testen en uitrollen, en beheer. Voor prestaties adviseert Databricks latency op basis van een percentiel, zoals p95. Bij streaming AI-responsen telt ook de tijd tot het eerste token.

Waarom Databricks Apps tellen

De architectuur bepaalt hoe een sessie een herstart doorstaat. Soft state mag opnieuw worden opgebouwd. Hard state hoort in Lakebase of Unity Catalog-tabellen, zodat elke instantie een sessie opnieuw kan samenstellen. Dat onderscheid voorkomt dat een specifieke instantie onmisbare sessie-informatie bevat.

Meer compute lost niet automatisch elk knelpunt op. Teams moeten eerst vaststellen waar verzoeken tijd verliezen en welke services de belasting dragen. Loadtests en telemetrie geven vervolgens richting aan de keuze voor instancegrootte, het aantal workers en het aantal instanties. Ook Lakebase-verbindingen vragen een eigen capaciteitsinschatting.

Concrete takeaway voor Databricks Apps

Leg vóór de bouw twee meetbare doelen vast: de gewenste latency en de piekbelasting. Beschrijf daarna enkele gebruikersreizen, zoals het openen van een dashboard of het indienen van een vraag, inclusief de services die elke actie aanroept.

Test die reizen onder verwachte piekbelasting en controleer cold starts apart. Gebruik de meetgegevens om compute en het aantal instanties te kiezen, in plaats van standaard voor XLarge te kiezen. Controleer ten slotte welke state in Lakebase of Unity Catalog moet staan, zodat een nieuwe instantie een sessie kan herstellen.