Gegevenspersistentie en serialisatie in Durable Functions voor Azure Functions

De Durable Functions runtime bewaart automatisch functieparameters, retourwaarden en andere statussen naar de taakhub om betrouwbare uitvoering te bieden. De hoeveelheid en frequentie van gegevens die worden bewaard in duurzame opslag, kunnen echter van invloed zijn op de prestaties van toepassingen en de opslagtransactiekosten. Afhankelijk van het type gegevens dat uw toepassing opslaat, moet mogelijk ook rekening worden gehouden met gegevensretentie en privacybeleid.

In dit artikel wordt uitgelegd welke gegevens behouden blijven, hoe u grote nettoladingen en gevoelige gegevens verwerkt en hoe u serialisatie aanpast voor elke ondersteunde taal.

In dit artikel:

Inhoud van taakhub

Taakhubs slaan de huidige status van instanties en eventuele in behandeling zijnde berichten op.

  • Instantiestatussen slaan de huidige status en geschiedenis van een exemplaar op. Voor orkestratie-exemplaren omvat deze status de runtimestatus, de orkestratiegeschiedenis, invoer, uitvoer en aangepaste status. Voor entiteitsexemplaren bevat deze de entiteitsstatus.
  • Berichten slaan functie-invoer of -uitvoer, nettoladingen van gebeurtenissen en metagegevens op die worden gebruikt voor interne doeleinden, zoals routering en end-to-end correlatie.

Berichten worden verwijderd nadat ze zijn verwerkt, maar exemplaarstatussen blijven behouden, tenzij ze expliciet door de toepassing of een operator worden verwijderd. In het bijzonder blijft een orkestratiegeschiedenis in de opslag, zelfs nadat de orkestratie is voltooid.

Zie het uitvoeringsvoorbeeld van de taakhub voor een voorbeeld van hoe statussen en berichten de voortgang van een orkestratie vertegenwoordigen.

Waar en hoe statussen en berichten worden weergegeven in de opslag , is afhankelijk van de opslagprovider. Gebruik Durable Task Scheduler omdat het een beheerde backend biedt voor taakhubs en de onderliggende state store voor je afhandelt. Toch blijft Azure Storage een solide optie voor bestaande workloads en voor apps die hun eigen opslagbronnen willen beheren.

Opslagprovider Hoe de toestand wordt opgeslagen Aanbevolen gebruik
Duurzame Taakplanner Orkestratie en entiteitstoestand worden opgeslagen in de beheerde scheduler-backend achter een taakhubbron. Voorkeursoptie voor nieuwe Durable Functions-apps en beheerde deployments.
Azure-opslag Toestand en berichten worden weergegeven in wachtrijen, tabellen en blobs in een Azure Storage-account. Goede match voor bestaande apps of implementaties die al afhankelijk zijn van Azure Storage.

Typen gegevens die worden geserialiseerd en bewaard

In de volgende lijst ziet u de verschillende typen gegevens die worden geserialiseerd en behouden wanneer u functies van Durable Functions gebruikt:

  • Alle invoer en uitvoer van orchestrator-, activiteits- en entiteitsfuncties, inclusief id's en niet-verwerkte uitzonderingen
  • Namen van orchestrator-, activiteits- en entiteitsfuncties
  • Namen en payloads van externe gebeurtenissen
  • Aangepaste orchestratiestatus-payloads
  • Beëindigingsberichten voor orkestratie
  • Duurzame timergegevensbelasting
  • Duurzame HTTP-aanvraag- en antwoord-URL's, headers en payloads
  • Nettoladingen voor entiteitsoproepen en -signaal
  • Nettoladingen van entiteitsstatus

Zie de volgende secties voor hulp bij het beheren van de nettoladinggrootte en het beveiligen van gevoelige items in deze lijst.

Houd Durable Functions invoer en uitvoer klein

U kunt geheugenproblemen ondervinden als u grote invoer- en uitvoergegevens naar en van Durable Functions-API's opgeeft. Invoer en uitvoer worden geserialiseerd in de orkestratiegeschiedenis, wat betekent dat grote gegevensladingen in de loop van de tijd aanzienlijk kunnen bijdragen aan onbegrensde geschiedenisgroei. De groei loopt het risico geheugen-uitzonderingen te veroorzaken tijdens het opnieuw afspelen.

Als u de impact van grote invoer en uitvoer wilt beperken, kunt u het volgende doen:

  • Delegeer werk aan suborchestrators om de geheugenbelasting van de geschiedenis te verdelen over meerdere orchestrators, waardoor de geheugenvoetafdruk van afzonderlijke geschiedenissen klein blijft.
  • Sla grote gegevens op in externe opslag (zoals Azure Blob Storage) en geef lichtgewicht id's door waarmee u die gegevens in activiteitsfuncties kunt ophalen wanneer dat nodig is.

Gebruik voor de Durable Task Scheduler ondersteuning voor grote payloads om grotere payloads over te brengen naar Azure Blob Storage. Voor nieuwe apps wordt dit patroon aanbevolen wanneer een orkestratie grote payloads moet doorgeven tussen blijvende bewerkingen. Als je de Azure Storage-provider gebruikt, kun je nog steeds het claim-check-patroon dat in de volgende sectie wordt getoond toepassen en lichtgewicht referenties tussen de bewerkingen doorgeven.

Tip

De aanbevolen procedure voor het omgaan met grote gegevens is om deze in externe opslag te bewaren en die gegevens alleen binnen activiteiten te materialiseren, wanneer dat nodig is.

Geef referenties naar grote payloads door

Kies het patroon dat past bij jouw opslagprovider.

Duurzame Taakplanner

Als je Durable Task Scheduler gebruikt, schakel dan ondersteuning voor grote payloads in zodat de runtime grotere payloads naar Azure Blob Storage schrijft en een kleine referentie via de scheduler stuurt. Een typische configuratie wordt weergegeven in de scheduler-documentatie:

{
  "version": "2.0",
  "extensions": {
    "durableTask": {
      "storageProvider": {
        "type": "azureManaged",
        "connectionStringName": "DTS_CONNECTION_STRING",
        "payloadStorageEnabled": true,
        "payloadStorageThresholdBytes": 262144
      },
      "hubName": "%TASKHUB_NAME%"
    }
  }
}
Azure-opslag

Met de Azure Storage-provider kun je het Claim Check-patroon gebruiken om de orkestratiegeschiedenis klein te houden terwijl je toch grote payloads verwerkt. De orchestrator geeft een lichtgewicht referentie door die de blobcontainer en blobnaam bevat, en de activiteit leest of schrijft de payload uit Azure Blob Storage indien nodig.

De volgende voorbeelden gaan ervan uit dat je al een blob in je opslagaccount hebt. Begin de orkestratie met een referentie zoals {"container":"large-payloads","blobName":"input/job-123.json"}. De activiteit creëert indien nodig de processed-payloads uitvoercontainer. De sampleverwerkingsstap kopieert de invoerbytes ongewijzigd; Vervang het door je applicatielogica.

Important

Neem nooit opslaggegevens of een shared access-handtekening (SAS) op in de referentie. Het systeem bewaart de referentie in de orkestratiegeschiedenis. Deze voorbeelden gebruiken een app-instelling met de naam PAYLOAD_STORAGE_CONNECTION_STRING om de opslagcode beknopt te houden. Voor productieworkloads gebruik je Microsoft Entra ID om toegang tot blobdata te autoriseren.

Dit voorbeeld vereist de Azure. Storage.Blobs NuGet-pakket.

using System;
using System.Threading.Tasks;
using Azure.Storage.Blobs;
using Microsoft.Azure.Functions.Worker;
using Microsoft.DurableTask;

public record BlobReference(string Container, string BlobName);

public static class LargePayloadFunctions
{
    [Function("ProcessLargePayload")]
    public static async Task<BlobReference> RunOrchestrator(
        [OrchestrationTrigger] TaskOrchestrationContext context)
    {
        BlobReference inputReference = context.GetInput<BlobReference>()
            ?? throw new InvalidOperationException("A blob reference is required.");

        return await context.CallActivityAsync<BlobReference>(
            nameof(ProcessLargePayloadActivity), inputReference);
    }

    [Function(nameof(ProcessLargePayloadActivity))]
    public static async Task<BlobReference> ProcessLargePayloadActivity(
        [ActivityTrigger] BlobReference inputReference)
    {
        string connectionString =
            Environment.GetEnvironmentVariable("PAYLOAD_STORAGE_CONNECTION_STRING")
            ?? throw new InvalidOperationException("Payload storage is not configured.");
        BlobServiceClient service = new BlobServiceClient(connectionString);

        BlobClient inputBlob = service
            .GetBlobContainerClient(inputReference.Container)
            .GetBlobClient(inputReference.BlobName);
        BinaryData inputData = (await inputBlob.DownloadContentAsync()).Value.Content;

        BlobContainerClient outputContainer =
            service.GetBlobContainerClient("processed-payloads");
        await outputContainer.CreateIfNotExistsAsync();

        string outputName = $"processed/{Guid.NewGuid():N}.json";
        await outputContainer.GetBlobClient(outputName)
            .UploadAsync(inputData, overwrite: true);

        return new BlobReference(outputContainer.Name, outputName);
    }
}

Als parallelle activiteiten meerdere grote resultaten opleveren, geef dan een lijst met referenties terug en geef die lijst door aan een uiteindelijke aggregatie-activiteit. De aggregatieactiviteit moet de payloads laden en combineren en vervolgens één laatste output blob schrijven. Laad of verbind de grote resultaten niet in de orchestrator.

Werken met gevoelige gegevens

Invoer en uitvoer (inclusief uitzonderingen) van en naar Durable Functions API's worden permanent bewaard in uw opslagprovider van keuze. Als deze invoer, uitvoer of uitzonderingen gevoelige gegevens bevatten (zoals geheimen, verbindingsreeksen of persoonsgegevens), kan iedereen met leestoegang tot de resources van uw opslagprovider deze verkrijgen.

Als u gevoelige gegevens veilig wilt verwerken, haalt u die gegevens op binnen activiteitsfuncties van Azure Key Vault of omgevingsvariabelen en communiceert u die gegevens nooit rechtstreeks naar of van orchestrators of entiteiten. Met deze aanpak voorkomt u dat gevoelige gegevens in uw opslagbronnen worden gelekt.

Op dezelfde manier moet schrijftoegang tot opslagresources strikt worden gecontroleerd, omdat gemanipuleerde gegevens in de opslag het orkestratiegedrag kunnen wijzigen. Zie Uw taakhubopslag beveiligen voor meer informatie over het beveiligen van de opslag van de taakhub.

Tip

Deze richtlijnen zijn ook van toepassing op de CallHttp orchestrator-API, die de verzoek- en antwoordpayloads in de opslag opslaat. Als voor uw doel-HTTP-eindpunten verificatie is vereist, implementeert u de HTTP-aanroep binnen een activiteit of gebruikt u de ingebouwde ondersteuning voor beheerde identiteiten die wordt aangeboden door CallHttp, waarmee geen referenties voor opslag worden bewaard.

Opmerking

Vermijd logboekregistratiegegevens met geheimen als iedereen met leestoegang tot uw logboeken (bijvoorbeeld in Application Insights) deze geheimen kan verkrijgen.

Versleuteling van opgeslagen data

Wanneer u de Azure Storage-provider gebruikt, worden alle gegevens automatisch in rust versleuteld. Iedereen met toegang tot het opslagaccount kan de gegevens echter lezen in de niet-versleutelde vorm. Als u een sterkere beveiliging voor gevoelige gegevens nodig hebt, kunt u overwegen eerst de gegevens te versleutelen met uw eigen versleutelingssleutels, zodat de gegevens in de vooraf versleutelde vorm behouden blijven.

.NET-gebruikers hebben ook de optie om aangepaste serialisatieproviders te implementeren die automatische versleuteling bieden. Een voorbeeld van aangepaste serialisatie met versleuteling vindt u in dit GitHub-voorbeeld.

Opmerking

Als u besluit om versleuteling op toepassingsniveau te implementeren, moet u er rekening mee houden dat indelingen en entiteiten voor onbepaalde tijd kunnen bestaan. Dit is belangrijk wanneer het tijd is om uw versleutelsleutels te vervangen, omdat een orkestratie of entiteiten langer kunnen draaien dan wat uw sleutelrotatiebeleid toestaat. Als er een sleutelrotatie plaatsvindt, is de sleutel waarmee uw gegevens worden versleuteld mogelijk niet meer beschikbaar om ze te ontsleutelen wanneer uw orchestratie of entiteit de volgende keer wordt uitgevoerd. Aangepaste versleuteling wordt daarom alleen aanbevolen wanneer orchestraties en entiteiten naar verwachting voor een relatief korte periode worden uitgevoerd.

Uw taakhubopslag beveiligen

De opslagback-end die als host fungeert voor uw taakhub, is een kritieke vertrouwensgrens. Het Durable Task Framework vertrouwt op gegevens die het tijdens het opnieuw afspelen van de orchestration en de verwerking van berichten uit de opslag leest. Iedereen met schrijftoegang tot de opslag van de taakhub kan de orchestratiestatus, wachtende berichten of opgeslagen nuttige gegevens manipuleren. Dit kan het gedrag van toepassingen wijzigen, onbedoelde acties activeren of uitvoering van externe code bereiken binnen de context van uw functie-app.

Important

Geef uw taakhub-opslagreferenties niet prijs en verleen geen schrijftoegang aan onvertrouwde partijen. Schrijftoegang tot taakhubopslag kan worden gebruikt om het gedrag van toepassingen te wijzigen, waaronder het activeren van willekeurige code-uitvoering.

Gedeelde verantwoordelijkheid

Het beveiligen van de opslagback-end is uw verantwoordelijkheid, hetzelfde als het beveiligen van elke database waarin de status of code van de toepassing wordt opgeslagen. Het Durable Task Framework voert geen integriteitscontrole uit op opgeslagen gegevens, dus is het afhankelijk van de toegangsbeheer van de opslaglaag om onbevoegde wijzigingen te voorkomen.

Backend Beveiligingsverantwoordelijkheid Guidance
Duurzame Taakplanner Microsoft beheert de onderliggende opslagbackend. Je beheert identiteiten, toegang tot de taakhubs en beveiliging op app-niveau. Voorkeursstandaard voor nieuwe Durable Functions-apps.
Azure Storage en andere BYO-providers Je beheert het opslagaccount of de database en de bijbehorende beveiligingsmaatregelen. Goede match voor bestaande workloads of deployments die al afhankelijk zijn van Azure Storage.

Opmerking

Deel geen enkele taakhub tussen niet-vertrouwde tenants. Een taakhub dwingt geen toegangsgrenzen af tussen de gebruikers, zodat elke tenant die naar de taakhub kan lezen of schrijven, invloed kan hebben op alle indelingen en entiteiten erin. Vertrouw ook niet op afzonderlijke taakhubs binnen dezelfde backend als beveiligingsgrens. Hoewel Durable Task Scheduler ondersteuning biedt voor RBAC die is afgestemd op afzonderlijke taakhubs, zijn netwerkbesturingselementen zoals IP-acceptatielijsten en privé-eindpunten alleen van toepassing op scheduler-niveau, zodat taakhubs binnen een planner geen beveiligingsisolatiegrens vormen. Hetzelfde geldt voor BYO-opslagproviders: elke tenant met toegang tot het opslagaccount of de database kan alle taakhubs op die back-end bereiken. Wanneer u beveiligingsisolatie tussen tenants nodig hebt, richt u afzonderlijke infrastructuur in voor elke tenant: afzonderlijke opslagaccounts of databases voor BYO-providers of afzonderlijke Durable Task Scheduler-exemplaren.

Controlelijst voor opslagbeveiliging

Pas de volgende aanbevolen procedures toe om uw taakhubopslag te beveiligen:

  • Gebruik identiteitsgebaseerde verbindingen voor de backend die je kiest.

    • Met Durable Task Scheduler kun je vertrouwen op beheerde identiteiten en RBAC voor de scheduler en taakhubs.
    • Bij Azure Storage en andere BYO-providers geef je waar mogelijk de voorkeur aan beheerde identiteit boven verbindingsstrings.

    Zie Configureer een beheerde identiteit voor Durable Functions.

  • RBAC-rollen met minimale bevoegdheden toepassen. Verleen alleen de minimaal vereiste machtigingen. Vermijd het verlenen van brede opslagtoegang aan gebruikers of diensten die het niet nodig hebben.

  • Beperk de netwerktoegang tot uw opslagaccount of schedulerimplementatie met privé-eindpunten of service-eindpunten. Deze beperking helpt ongeautoriseerde netwerktoegang tot taakomapgegevens te voorkomen.

  • Opslagtoegang bewaken door Azure Monitor resourcelogboeken in te schakelen voor uw opslagaccount, met name de logboekcategorie StorageWrite. Routeer deze logboeken naar een bestemming buiten het bewaakte opslagaccount, zoals Log Analytics, zodat ze niet kunnen worden gemanipuleerd. Zie opslaglogboeken.

  • Vernieuw uw referenties regelmatig als u verbindingsstrings gebruikt. Behandel de sleutels van opslagaccounts met dezelfde zorg als elk ander aanmeldingsgegeven met uitgebreide bevoegdheden.

  • Overweeg een back-end voor beheerde opslag. Durable Task Scheduler verzorgt automatisch de beveiliging van opslag, inclusief authenticatie, RBAC en netwerkisolatie, terwijl Azure Storage expliciete opslagcontrole biedt.

Serialisatie en deserialisatie aanpassen

Serialisatieaanpassingsopties variëren per taal. Selecteer het taaltabblad om de beschikbare opties te bekijken.

.NET Isolated en System.Text.Json

Durable Functions die worden uitgevoerd in het .NET Isolated-werkproces, gebruiken dezelfde objectserialisator die globaal is geconfigureerd voor je Azure Functions-app (zie WorkerOptions). Deze serializer is System.Text.Json standaard in plaats van Newtonsoft.Json. Alle wijzigingen in WorkerOptions.Serializer zijn transitief ook van toepassing op Durable Functions.

Zie de JSON-serialisatie en deserialisatie in .NET overzichtsdocumentatie voor meer informatie over de ingebouwde ondersteuning voor JSON-serialisatie in .NET.

Volgende stappen