Analyse av hosting og kostnader
Dette dokumentet beskriver hosting-arkitekturen, grenser for gratisnivå og anbefalinger for skalering av Billettsalg-applikasjonen.
Hurtigreferanse — $0/måned
| Tjeneste | Nivå | Månedlig kostnad |
|---|---|---|
| Azure Static Web Apps | Free | $0 |
| Azure Functions | Consumption (1M gratis) | $0 |
| Azure Cosmos DB | Free tier (1000 RU/s) | $0 |
| Resend | Gratis, dagens betavolum | $0 |
| Log Analytics | PerGB2018, betavolum | $0 |
| Application Insights | Arbeidsområdebasert, begrenset | $0 |
| Totalt | $0 |
Hele stakken kan kjøres uten kostnad med dagens betavolum så lenge bruken holder seg innenfor gjeldende gratisgrenser hos Azure og Resend. Application Insights har en grense på 0,1 GB per dag, og den første produksjonskontrollen målte omtrent 12,6 MB over 24 timer. Leverandørgrenser og priser kan endres, så kontroller dem før budsjettering.
Nåværende arkitektur
| Tjeneste | Formål | Nivå |
|---|---|---|
| Azure Static Web Apps | Frontend-hosting + API-ruting | Free |
| Azure Functions (Consumption) | Backend API | Consumption (betal per bruk) |
| Azure Cosmos DB | Database | Serverless / Provisioned |
| Resend | E-poster med innloggingslenker og invitasjoner | Gratis eller betalt e-postabonnement |
| Log Analytics | Lagring av produksjonslogger | PerGB2018 |
| Application Insights | API-telemetri og varsler | Arbeidsområdebasert |
Grenser for gratisnivå
Azure Static Web Apps (Free)
- Båndbredde: 100 GB/måned
- Lagring: 0,5 GB
- Egendefinerte domener: 2
- SSL-sertifikater: Inkludert
- Staging-miljøer: 3
Azure Functions (Consumption Plan)
- Kjøringer: 1 000 000 per måned
- Beregning: 400 000 GB-sekunder per måned
- Kjøringstidsgrense: Maks 10 minutter
Azure Cosmos DB (Serverless)
- Request Units: Betal per forespørsel (~$0,25 per million RU-er)
- Lagring: $0,25/GB/måned
- Gratisnivå-alternativ: 1000 RU/s + 25 GB gratis (provisioned-modus)
Transaksjons-e-post med Resend
- Gjeldende gratisabonnement: 3 000 transaksjons-e-poster per måned
- Gjeldende dagsgrense på gratisabonnementet: 100 e-poster
- Betalte abonnementer: Tilgjengelig når månedsvolum eller dagstopper overstiger gratisgrensene
Se Resend-priser for gjeldende grenser og priser. Applikasjonen bruker Resend i produksjon. Når RESEND_API_KEY mangler, logger utviklingsoppførselen bare maskert mottaker-, emne- og avsendermetadata. De beskyttede responsfeltene devLink og devCode er bare tilgjengelige i E2E-testmodus.
Azure Monitor
- Oppbevaring av arbeidsområdetelemetri: 31 dager for Application Insights-data som lagres i det tilknyttede Log Analytics-arbeidsområdet
- Daglig inntaksgrense: 0,1 GB, omtrent 100 MB
- Tidlig varsel: 80 MB over 24 timer
- Rutinemessig telemetri: utvalgsbegrenses til opptil fem elementer per sekund per funksjonsinstans
- Frontendtelemetri: ingen egen nettleser-SDK
Skaleringsscenarioer
Scenario: 1 500 brukere
| Tjeneste | Konsekvens | Risikonivå |
|---|---|---|
| Static Web Apps | 100 GB båndbredde er mer enn nok | ✅ Lav |
| Azure Functions | Godt innenfor 1M kjøringer | ✅ Lav |
| Cosmos DB | Kan nå 1000 RU/s-grensen ved topp i bestillinger | ⚠️ Middels |
| E-post | ~3000–4500 e-poster/måned for innlogging | ⚠️ Lav-Middels |
Cosmos DB-vurdering
Med 1 500 brukere fordelt på flere kor:
- Lagring: Effektiv datamodell (~1–2 GB totalt). ✅
- Gjennomstrømning: 1000 RU/s delt mellom alle operasjoner.
Risikoscenario: 200+ medlemmer som bestiller billetter i et 30-minutters vindu før fristen kan forårsake hastighetsbegrensning (HTTP 429-feil).
Estimat for e-postvolum
- 1 500 brukere × 2–3 innlogginger/måned = 3 000–4 500 e-poster/måned
- Den nedre delen av intervallet når den gjeldende månedsgrensen på gratisabonnementet.
- Den øvre delen overstiger den gjeldende månedsgrensen, og konsentrerte innloggingsdager kan også overstige dagsgrensen.
- Et betalt Resend-abonnement kan være nødvendig. Kontroller gjeldende leverandørpriser i stedet for å bruke et fast estimat per e-post.
Anbefalinger
Bli på gratisnivå når:
- Brukerne er fordelt på flere kor
- Billettbestilling skjer gradvis over flere dager (ikke i siste liten)
- Sporadisk treghet ved toppbelastning er akseptabelt
Vurder betalt kapasitet når:
- Stabil ytelse i perioder med høy trafikk er viktig
- Flere store kor bruker systemet samtidig
- Du trenger leverandørfunksjoner eller kapasitet utover gratisgrensene
Eksempel på betalt konfigurasjon
| Tjeneste | Konfigurasjon | Kostnadsveiledning |
|---|---|---|
| Cosmos DB | Autoskalering eller høyere klargjort kapasitet | Bruk prissiden for Azure Cosmos DB eller kalkulatoren |
| Static Web Apps | Behold Free hvis grensene fortsatt er tilstrekkelige | $0 innenfor gjeldende Free-grenser |
| Functions | Behold Consumption hvis inkludert forbruk er tilstrekkelig | Bruksbasert utover inkludert forbruk |
| Resend | Velg abonnement etter faktisk månedsvolum og dagstopper | Bruk gjeldende Resend-priser |
Ikke behandle dette eksemplet som et pristilbud. Region, trafikkmønster, leverandørendringer og valgte funksjoner påvirker sluttkostnaden.
Optimaliseringsstrategier (gratisnivå)
Hvis du blir på gratisnivå, vurder disse optimaliseringene:
1. Hurtigbuffer (caching)
- Hurtigbufre ofte etterspurte data (arrangementer, billetttyper)
- Bruk localStorage for brukersesjonsdata
2. Batchoperasjoner
- Samle flere små skrivinger til færre operasjoner
- Bruk masseoperasjoner der det er mulig
3. Fordel last
- Sett bestillingsfrister til tidspunkter utenom topp (f.eks. kl. 14 i stedet for midnatt)
- Send påminnelses-e-poster i grupper gjennom hele dagen
4. Effektive spørringer
- Spør alltid etter partisjonsnøkkel (
organizationId) - Unngå spørringer på tvers av partisjoner
- Bruk projeksjoner for å returnere kun nødvendige felt
Overvåking
Produksjonsutrullingen har fire aktiverte varselregler som bare vises i portalen:
- Mer enn fem mislykkede forespørsler på fem minutter
- Mer enn ti unntak på 15 minutter
- Mer enn tre mislykkede avhengigheter på fem minutter
- Mer enn 80 MB fakturerbart inntak over 24 timer
Ingen handlingsgrupper er koblet til. Gjennomgå varsler i Azure Monitor, og følg fortsatt med på Cosmos DB Request Units, API-responstid, Function-feil og e-postlevering.
Inntaksgrensen styrer overvåkingsvolumet, ikke applikasjonstrafikken. Hvis telemetrien når grensen, kan overvåkingen være ufullstendig til grensen tilbakestilles, men applikasjonen fortsetter å behandle forespørsler.
Planleggingssignaler etter antall brukere
Antall brukere alene bestemmer ikke kostnaden. Innloggingsfrekvens, bestillingstopper, telemetrivolum og Cosmos DB Request Units er sterkere signaler.
| Brukere | Planleggingssignal for e-post | Planleggingssignal for database |
|---|---|---|
| 100–500 | Vanligvis forenlig med lavt volum, med forbehold om dagsgrensen | Vanligvis forenlig med dagens gratisallokering |
| 1 000 | Overvåk daglige innloggingstopper og samlet månedsvolum | Overvåk Request Units i bestillingsperioder |
| 1 500 | Eksemplet over kan overstige gjeldende Resend Free-grense | Bestillingstopper kan gi struping |
| 3 000+ | Planlegg og budsjetter fra gjeldende Resend-priser | Modeller Request Units og vurder betalt kapasitet |
Beregn på nytt fra målt produksjonsbruk før du endrer abonnement.
Når bør du skalere
Umiddelbar handling nødvendig hvis:
- Brukere rapporterer vedvarende trege responser
- Cosmos DB-metrikker viser hyppige 429-feil (hastighetsbegrensning)
- E-postlevering begynner å feile jevnlig
Planlegg på forhånd når:
- Du legger til nye store kor (100+ medlemmer hver)
- Det nærmer seg store konsertsessonger
- Brukerveksten overstiger 2 000 aktive brukere
Se også: Azure-utrulling · Arkitektur