Trwałość danych i serializacja w Durable Functions dla Azure Functions

Środowisko uruchomieniowe Durable Functions automatycznie utrwala parametry funkcji, zwraca wartości i inny stan do centrum task hub w celu zapewnienia niezawodnego wykonywania. Jednak ilość i częstotliwość danych utrwalonych w trwałej pamięci mogą mieć wpływ na efektywność działania aplikacji oraz koszty transakcji przechowywania. W zależności od typu danych przechowywanych przez aplikację konieczne może być również rozważenie przechowywania danych i zasad ochrony prywatności.

W tym artykule wyjaśniono, jakie dane są utrwalane, jak obsługiwać duże ładunki i dane poufne oraz jak dostosować serializacji dla każdego obsługiwanego języka.

W tym artykule:

Zawartość centrum zadań

Centra zadań przechowują bieżący stan wystąpień i wszystkie oczekujące komunikaty:

  • Stany instancji przechowują bieżący stan i historię instancji. W przypadku wystąpień orkiestracji ten stan obejmuje stan uruchomieniowy, historię orkiestracji, dane wejściowe, dane wyjściowe i status niestandardowy. W przypadku instancji jednostki zawiera ona stan jednostki.
  • Komunikaty przechowują dane wejściowe lub wyjściowe funkcji, ładunki zdarzeń i metadane używane do celów wewnętrznych, takie jak routing i kompleksowa korelacja.

Komunikaty są usuwane po przetworzeniu, ale stany wystąpień są zachowywane, chyba że zostaną jawnie usunięte przez aplikację lub operator. W szczególności historia orkiestracji pozostaje w pamięci nawet po zakończeniu orkiestracji.

Aby zapoznać się z przykładem tego, jak stany i komunikaty reprezentują postęp orkiestracji, zobacz przykład wykonywania centrum zadań.

Gdzie i jak stany i komunikaty są reprezentowane w magazynie , zależy od dostawcy magazynu. Domyślnym dostawcą usługi Durable Functions jest usługa Azure Storage, która utrwala dane w kolejkach, tabelach i obiektach blob na określonym koncie usługi Azure Storage .

Typy danych, które są serializowane i utrwalane

Na poniższej liście przedstawiono różne typy danych, które będą serializowane i utrwalane podczas korzystania z funkcji Durable Functions:

  • Wszystkie dane wejściowe i wyjściowe funkcji orkiestratora, aktywności i jednostki, w tym wszelkie identyfikatory i nieobsługiwane wyjątki
  • Nazwy funkcji orkiestratora, działania i jednostki
  • Nazwy i ładunki zdarzeń zewnętrznych
  • Niestandardowe ładunki stanu orkiestracji
  • Komunikaty zakończenia orkiestracji
  • Trwałe ładunki czasomierza
  • Trwałe adresy URL żądań i odpowiedzi HTTP, nagłówki i treści
  • Wywołania encji i ładunki sygnału
  • Ładunki stanu jednostki

Aby uzyskać wskazówki dotyczące zarządzania rozmiarem ładunku i ochrony poufnych elementów na tej liście, zobacz poniższe sekcje.

Zachowaj niewielkie dane wejściowe i wyjściowe dla Durable Functions

Problemy z pamięcią mogą wystąpić, jeśli przekazujesz duże dane wejściowe i wyjściowe do i z interfejsów API Durable Functions. Dane wejściowe i wyjściowe są serializowane w historii orkiestracji, dzięki czemu duże ładunki mogą w czasie znacznie przyczynić się do nieograniczonego wzrostu historii. Ten wzrost ryzykuje powodowanie wyjątków pamięci podczas odtwarzania.

Aby zminimalizować wpływ dużych danych wejściowych i wyjściowych, możesz:

  • Deleguj pracę do pod-koordynatorów, aby zrównoważyć obciążenie pamięci związanej z historią w wielu orkiestratorach, utrzymując niewielkie zużycie pamięci przez pojedyncze historie.
  • Przechowuj duże dane w zewnętrznym repozytorium (takim jak Azure Blob Storage) i przekazuj lekkie identyfikatory, które umożliwiają pobieranie tych danych wewnątrz funkcjach aktywności w razie potrzeby.

Jeśli używasz Durable Task Scheduler, możesz również użyć obsługi dużych ładunków, aby przekazać większe ładunki do usługi Azure Blob Storage.

Wskazówka

Najlepszym rozwiązaniem do radzenia sobie z dużymi danymi jest przechowywanie ich w magazynie zewnętrznym i materializowanie tych danych tylko wewnątrz działań w razie potrzeby.

Praca z danymi poufnymi

Dane wejściowe i wyjściowe (w tym wyjątki) do i z interfejsów API Durable Functions są trwale utrwalane w storage wybranego dostawcy. Jeśli te dane wejściowe, wyjściowe lub wyjątki zawierają poufne dane (takie jak wpisy tajne, parametry połączenia lub dane osobowe), każda osoba mająca dostęp do odczytu do zasobów dostawcy magazynu może je uzyskać.

Aby bezpiecznie obsługiwać poufne dane, pobieraj te dane w funkcjach działań z Azure Key Vault ani ze zmiennych środowiskowych i nigdy nie komunikuj tych danych bezpośrednio z lub do orkiestratorów ani jednostek. Takie podejście pomaga zapobiegać wyciekowi poufnych danych w zasobach pamięci.

Podobnie uprawnienia do zapisu do zasobów pamięci masowej muszą być ściśle kontrolowane, ponieważ dane w pamięci masowej, przy których manipulowano, mogą zmienić działanie orkiestracji. Aby uzyskać więcej informacji na temat zabezpieczania magazynu centrum zadań, zobacz Zabezpieczanie magazynu centrum zadań.

Wskazówka

Te wskazówki dotyczą również interfejsu CallHttp API orkiestratora, który utrwala ładunki żądań i odpowiedzi w magazynie. Jeśli docelowe punkty końcowe HTTP wymagają uwierzytelniania, zaimplementuj wywołanie HTTP wewnątrz aktywności lub użyj wbudowanej obsługi tożsamości zarządzanej oferowanej przez CallHttp, która nie zapisuje poświadczeń w magazynie.

Note

Unikaj rejestrowania danych zawierających wpisy tajne, ponieważ każda osoba mająca dostęp do odczytu do dzienników (na przykład w usłudze Application Insights) może uzyskać te wpisy tajne.

Szyfrowanie w spoczynku

W przypadku korzystania z dostawcy usługi Azure Storage wszystkie dane są automatycznie szyfrowane w spoczynku. Jednak każda osoba mająca dostęp do konta magazynu może odczytywać dane w postaci niezaszyfrowanej. Jeśli potrzebujesz silniejszej ochrony danych poufnych, rozważ najpierw szyfrowanie danych przy użyciu własnych kluczy szyfrowania, aby dane zostały utrwalone w postaci wstępnie zaszyfrowanej.

Alternatywnie użytkownicy platformy .NET mają możliwość implementowania niestandardowych dostawców serializacji, którzy zapewniają automatyczne szyfrowanie. Przykład niestandardowej serializacji z szyfrowaniem można znaleźć w tym przykładzie na GitHub.

Note

Jeśli zdecydujesz się wdrożyć szyfrowanie na poziomie aplikacji, pamiętaj, że orkiestracje i byty mogą istnieć przez nieokreślony czas. Ma to znaczenie, gdy nadchodzi czas na rotację kluczy szyfrowania, ponieważ orkiestracja lub elementy mogą działać dłużej niż polityka rotacji kluczy. Jeśli nastąpi rotacja kluczy, klucz używany do szyfrowania danych może nie być już dostępny do odszyfrowywania go przy następnym wykonaniu aranżacji lub jednostki. Dlatego szyfrowanie niestandardowe jest zalecane tylko wtedy, gdy aranżacje i jednostki mają być uruchamiane przez stosunkowo krótki czas.

Zabezpiecz magazyn danych centrum zadań

Zaplecze magazynu, które hostuje centrum zadań, jest granicą zaufania krytycznego. Durable Task Framework ufa danym odczytywanym z pamięci masowej podczas odtwarzania orkiestracji i przetwarzania komunikatów. Każdy, kto ma dostęp do zapisu do magazynu centrum zadań, może manipulować stanem aranżacji, oczekującymi komunikatami lub przechowywanymi ładunkami. Może to zmienić zachowanie aplikacji, wywołać niezamierzone działania lub doprowadzić do zdalnego wykonania kodu w kontekście Twojej aplikacji funkcji.

Important

Nie ujawniaj poświadczeń magazynu centrum zadań ani nie przyznawaj uprawnień do zapisu niezaufanym podmiotom. Dostęp do zapisu do magazynu centrum zadań może służyć do zmiany zachowania aplikacji, w tym wyzwalania dowolnego wykonywania kodu.

Wspólna odpowiedzialność

Zabezpieczanie zaplecza magazynu jest twoim zadaniem, tak samo jak zabezpieczanie każdej bazy danych, która przechowuje stan aplikacji lub kod. Struktura Durable Task Framework nie wykonuje weryfikacji integralności przechowywanych danych, dlatego opiera się na kontroli dostępu warstwy magazynu, aby zapobiec nieautoryzowanym modyfikacjom.

W przypadku korzystania z usługi Durable Task Scheduler zaplecze magazynu jest w pełni zarządzane i zabezpieczone przez usługę przy użyciu uwierzytelniania tożsamości zarządzanej i kontroli dostępu opartej na rolach (RBAC). W przypadku zapleczy magazynowych BYO (bring-your-own), takich jak Azure Storage, MSSQL lub Netherite, należy samodzielnie zabezpieczyć bazowe zasoby magazynowe.

Note

Nie współdziel jednego koncentratora zadań między niezaufanymi dzierżawcami. Koncentrator zadań nie wymusza ograniczeń dostępu między swoimi użytkownikami, więc każdy dzierżawca, który może odczytywać dane w koncentratorze zadań lub je zapisywać, może wpływać na wszystkie orkiestracje i encje w jego obrębie. Podobnie nie należy polegać na oddzielnych centrach zadań w ramach tego samego zaplecza co granica zabezpieczeń. Chociaż Durable Task Scheduler obsługuje mechanizm RBAC ograniczony do poszczególnych hubów zadań, mechanizmy kontroli sieciowej, takie jak listy dozwolonych adresów IP i prywatne punkty końcowe, obowiązują wyłącznie na poziomie harmonogramu, więc huby zadań w ramach harmonogramu nie stanowią granicy izolacji zabezpieczeń. To samo dotyczy dostawców magazynowania BYO — każdy dzierżawca mający dostęp do konta magazynu lub bazy danych może uzyskać dostęp do wszystkich hubów zadań w tym zapleczu. Jeśli potrzebujesz izolacji bezpieczeństwa między dzierżawcami, aprowizuj oddzielną infrastrukturę dla każdego dzierżawcy: oddzielne konta magazynowe lub bazy danych dla dostawców BYO albo oddzielne wystąpienia usługi Durable Task Scheduler.

Lista kontrolna dotycząca wzmacniania zabezpieczeń magazynu

Zastosuj następujące najlepsze rozwiązania, aby chronić magazyn centrum zadań:

  • Używaj połączeń opartych na tożsamości zamiast ciągów połączeń z kluczami dostępu do magazynu. Tożsamości zarządzane zapewniają szczegółową kontrolę dostępu i eliminują ryzyko wycieku poświadczeń. Zobacz Konfigurowanie tożsamości zarządzanej dla Durable Functions.
  • Zastosuj role RBAC o najmniejszych uprawnieniach. Przyznaj tylko wymagane minimalne uprawnienia. Unikaj przyznawania użytkownikom lub usługom, które go nie potrzebują, szerokiego dostępu do konta magazynu danych.
  • Ogranicz dostęp sieciowy do konta magazynu danych za pomocą prywatnych punktów końcowych lub punktów końcowych usługi. Zapobiega to nieautoryzowanemu dostępowi na poziomie sieci do danych centrum zadań.
  • Monitoruj dostęp do magazynu, włączając dzienniki zasobów usługi Azure Monitor dla konta magazynu, zwłaszcza kategorię dziennika StorageWrite. Kieruj te dzienniki do miejsca docelowego poza monitorowanym kontem magazynu, na przykład do usługi Log Analytics, aby nie można było ich modyfikować. Zobacz Dzienniki magazynu.
  • Regularnie zmieniaj poświadczenia, jeśli używasz parametrów połączenia. Traktuj klucze konta magazynowego z taką samą ostrożnością jak wszelkie inne poświadczenia o wysokich uprawnieniach.
  • Rozważ użycie zaplecza magazynu zarządzanego. Durable Task Scheduler automatycznie zarządza zabezpieczeniami magazynu, w tym szyfrowaniem, uwierzytelnianiem i izolacją sieci.

Dostosowywanie serializacji i deserializacji

Opcje dostosowywania serializacji różnią się w zależności od języka. Wybierz kartę języka, aby wyświetlić dostępne opcje.

Domyślna logika serializacji

Durable Functions dla .NET wewnętrznie używa Json.NET do serializacji orchestracji i danych jednostki do JSON. Domyślne ustawienia Json.NET, które są używane, to:

Dane wejściowe, dane wyjściowe i stan:

JsonSerializerSettings
{
    TypeNameHandling = TypeNameHandling.None,
    DateParseHandling = DateParseHandling.None,
}

Wyjątki:

JsonSerializerSettings
{
    ContractResolver = new ExceptionResolver(),
    TypeNameHandling = TypeNameHandling.Objects,
    ReferenceLoopHandling = ReferenceLoopHandling.Ignore,
}

Przeczytaj bardziej szczegółową dokumentację na ten temat JsonSerializerSettingstutaj.

Dostosowywanie serializacji przy użyciu atrybutów .NET

Podczas serializacji Json.NET szuka różnych atrybutów w klasach i właściwościach, które kontrolują sposób serializacji i deserializacji danych z JSON. Jeśli jesteś właścicielem kodu źródłowego dla typu danych przekazanego do interfejsów API Durable Functions, rozważ dodanie tych atrybutów do typu w celu dostosowania serializacji i deserializacji.

Dostosowywanie serializacji za pomocą wstrzykiwania zależności

Aplikacje funkcji przeznaczone dla .NET i uruchamiane w środowisku uruchomieniowym usługi Functions w wersji 3 mogą używać Dependency Injection (DI) w celu dostosowania sposobu serializacji danych i wyjątków. Poniższy przykładowy kod pokazuje, jak za pomocą DI zastąpić domyślne ustawienia serializacji Json.NET, przy użyciu niestandardowych implementacji interfejsów usługi IMessageSerializerSettingsFactory i IErrorSerializerSettingsFactory.

using Microsoft.Azure.Functions.Extensions.DependencyInjection;
using Microsoft.Azure.WebJobs.Extensions.DurableTask;
using Microsoft.Extensions.DependencyInjection;
using Newtonsoft.Json;
using System.Collections.Generic;

[assembly: FunctionsStartup(typeof(MyApplication.Startup))]
namespace MyApplication
{
    public class Startup : FunctionsStartup
    {
        public override void Configure(IFunctionsHostBuilder builder)
        {
            builder.Services.AddSingleton<IMessageSerializerSettingsFactory, CustomMessageSerializerSettingsFactory>();
            builder.Services.AddSingleton<IErrorSerializerSettingsFactory, CustomErrorSerializerSettingsFactory>();
        }

        /// <summary>
        /// A factory that provides the serialization for all inputs and outputs for activities and
        /// orchestrations, as well as entity state.
        /// </summary>
        internal class CustomMessageSerializerSettingsFactory : IMessageSerializerSettingsFactory
        {
            public JsonSerializerSettings CreateJsonSerializerSettings()
            {
                // Return your custom JsonSerializerSettings here
            }
        }

        /// <summary>
        /// A factory that provides the serialization for all exceptions thrown by activities
        /// and orchestrations
        /// </summary>
        internal class CustomErrorSerializerSettingsFactory : IErrorSerializerSettingsFactory
        {
            public JsonSerializerSettings CreateJsonSerializerSettings()
            {
                // Return your custom JsonSerializerSettings here
            }
        }
    }
}

Następne kroki

  • Last updated on