Modello di app Web affidabile per .NET - Applicare il modello

Questo articolo illustra come applicare il modello Reliable Web App. Il modello Reliable Web App è un set di principi e tecniche di implementazione che definiscono come modificare le app Web (replatform) durante la migrazione al cloud. È incentrato sugli aggiornamenti minimi del codice che è necessario apportare per avere successo nel cloud.

Per facilitare l'applicazione di queste linee guida, è disponibile un'implementazione di riferimento del modello Reliable Web App che è possibile distribuire.

Architettura dell'implementazione di riferimento. Scaricare un file di Visio di questa architettura.

Le indicazioni seguenti usano l'implementazione di riferimento come esempio in tutto. Per applicare il modello Reliable Web App, seguire queste indicazioni allineate ai pilastri di Well-Architected Framework:

Affidabilità

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni che l'utente ha preso con i clienti. Per altre informazioni, vedere l'elenco di controllo per la revisione della progettazione per l'affidabilità. Il modello Reliable Web App introduce due modelli di progettazione chiave a livello di codice per migliorare l'affidabilità: il modello Di ripetizione dei tentativi e il modello a interruttore.

Usare il modello Di ripetizione dei tentativi

Il modello Di ripetizione dei tentativi risolve le interruzioni temporanee del servizio, definiti errori temporanei, che in genere si risolvono entro pochi secondi. Questi errori spesso derivano dalla limitazione del servizio, dalla distribuzione dinamica del carico e dai problemi di rete negli ambienti cloud. L'implementazione del modello Di ripetizione dei tentativi comporta la reinviazione di richieste non riuscite, consentendo ritardi configurabili e tentativi prima di concedere un errore.

Le applicazioni che usano il modello Di ripetizione dei tentativi devono integrare gli SDK (Client Software Development Kit) di Azure e i meccanismi di ripetizione dei tentativi specifici del servizio per migliorare l'efficienza. Le applicazioni che non hanno questo modello devono adottarlo usando le indicazioni seguenti.

Provare prima il servizio di Azure e gli SDK client

La maggior parte dei servizi di Azure e degli SDK client dispone di un meccanismo di ripetizione dei tentativi predefinito. È consigliabile usare il meccanismo di ripetizione dei tentativi predefinito per i servizi di Azure per accelerare l'implementazione.

Esempio: l'implementazione di riferimento usa la resilienza della connessione in Entity Framework Core per applicare il modello Di ripetizione dei tentativi nelle richieste a database SQL di Azure (vedere il codice seguente).

services.AddDbContextPool<ConcertDataContext>(options => options.UseSqlServer(sqlDatabaseConnectionString,
    sqlServerOptionsAction: sqlOptions =>
    {
        sqlOptions.EnableRetryOnFailure(
        maxRetryCount: 5,
        maxRetryDelay: TimeSpan.FromSeconds(3),
        errorNumbersToAdd: null);
    }));

Usare la libreria Polly quando la libreria client non supporta i tentativi

Potrebbe essere necessario effettuare chiamate a una dipendenza che non è un servizio di Azure o che non supporta il modello di ripetizione dei tentativi in modo nativo. In tal caso, è necessario usare la libreria Polly per implementare il modello Di ripetizione dei tentativi. Polly è una libreria di resilienza .NET e di gestione degli errori temporanei. Con esso, è possibile usare le API Fluent per descrivere il comportamento in una posizione centrale dell'applicazione.

Esempio: l'implementazione di riferimento usa Polly per configurare l'inserimento delle dipendenze ASP.NET Core. Polly applica il modello Retry ogni volta che il codice costruisce un oggetto che chiama l'oggetto IConcertSearchService . Nel framework Polly questo comportamento è noto come criterio. Il codice estrae questo criterio nel GetRetryPolicy metodo e il GetRetryPolicy metodo applica il criterio Di ripetizione ogni volta che l'app Web front-end chiama i servizi di ricerca concert dell'API Web (vedere il codice seguente).

private void AddConcertSearchService(IServiceCollection services)
{
    var baseUri = Configuration["App:RelecloudApi:BaseUri"];
    if (string.IsNullOrWhiteSpace(baseUri))
    {
        services.AddScoped<IConcertSearchService, MockConcertSearchService>();
    }
    else
    {
        services.AddHttpClient<IConcertSearchService, RelecloudApiConcertSearchService>(httpClient =>
        {
            httpClient.BaseAddress = new Uri(baseUri);
            httpClient.DefaultRequestHeaders.Add(HeaderNames.Accept, "application/json");
            httpClient.DefaultRequestHeaders.Add(HeaderNames.UserAgent, "Relecloud.Web");
        })
        .AddPolicyHandler(GetRetryPolicy())
        .AddPolicyHandler(GetCircuitBreakerPolicy());
    }
}

private static IAsyncPolicy<HttpResponseMessage> GetRetryPolicy()
{
    var delay = Backoff.DecorrelatedJitterBackoffV2(TimeSpan.FromMilliseconds(500), retryCount: 3);
    return HttpPolicyExtensions
      .HandleTransientHttpError()
      .OrResult(msg => msg.StatusCode == System.Net.HttpStatusCode.NotFound)
      .WaitAndRetryAsync(delay);
}

Il gestore dei criteri per l'istanza RelecloudApiConcertSearchService applica il modello Di ripetizione dei tentativi in tutte le richieste all'API. Usa la HandleTransientHttpError logica per rilevare le richieste HTTP che possono riprovare in modo sicuro e quindi ripetere la richiesta in base alla configurazione. Include una certa casualità per attenuare potenziali picchi di traffico verso l'API se si verifica un errore.

Usare il modello a interruttore

L'associazione dei modelli di ripetizione dei tentativi e interruttore espande la funzionalità di un'applicazione per gestire le interruzioni del servizio che non sono correlate a errori temporanei. Il modello interruttore impedisce a un'applicazione di tentare continuamente di accedere a un servizio non rispondente. Il modello interruttore rilascia l'applicazione ed evita di sprecare cicli di CPU in modo che l'applicazione mantenga l'integrità delle prestazioni per gli utenti finali.

Esempio: l'implementazione di riferimento aggiunge il modello a interruttore nel GetCircuitBreakerPolicy metodo (vedere il codice seguente).

private static IAsyncPolicy<HttpResponseMessage> GetCircuitBreakerPolicy()
{
    return HttpPolicyExtensions
        .HandleTransientHttpError()
        .OrResult(msg => msg.StatusCode == System.Net.HttpStatusCode.NotFound)
        .CircuitBreakerAsync(5, TimeSpan.FromSeconds(30));
}

Nel codice il gestore dei criteri per l'istanza RelecloudApiConcertSearchService applica il modello di interruttore a tutte le richieste all'API. Usa la HandleTransientHttpError logica per rilevare le richieste HTTP che possono riprovare in modo sicuro, ma limita il numero di errori di aggregazione in un periodo di tempo specificato.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per la sicurezza. Il modello Reliable Web App usa le identità gestite per implementare la sicurezza basata sulle identità. Gli endpoint privati, il web application firewall e l'accesso limitato all'app Web forniscono un ingresso sicuro.

Applicare privilegi minimi

Per garantire sicurezza ed efficienza, concedere solo agli utenti (identità utente) e ai servizi di Azure (identità del carico di lavoro) le autorizzazioni necessarie.

Assegnare autorizzazioni alle identità utente

Valutare le esigenze dell'applicazione per definire un set di ruoli che coprono tutte le azioni utente senza sovrapposizioni. Eseguire il mapping di ogni utente al ruolo più appropriato. Assicurarsi che ricevano l'accesso solo a ciò che è necessario per i loro compiti.

Assegnare autorizzazioni alle identità del carico di lavoro

Concedere solo le autorizzazioni critiche per le operazioni, ad esempio le azioni CRUD nei database o l'accesso ai segreti. Le autorizzazioni di identità del carico di lavoro sono persistenti, quindi non è possibile fornire autorizzazioni JUST-In-Time o a breve termine per le identità del carico di lavoro.

• Preferisce il controllo degli accessi in base al ruolo. Iniziare sempre con il controllo degli accessi in base al ruolo di Azure per assegnare le autorizzazioni. Offre un controllo preciso, assicurando che l'accesso sia controllabile e granulare. Usare il controllo degli accessi in base al ruolo di Azure per concedere solo le autorizzazioni necessarie per il servizio per eseguire le funzioni desiderate.

• Integrare i controlli di accesso a livello di servizio di Azure. Se il controllo degli accessi in base al ruolo di Azure non copre uno scenario specifico, integrare i criteri di accesso a livello di servizio di Azure.

Configurare l'autenticazione e l'autorizzazione degli utenti

L'autenticazione e l'autorizzazione sono aspetti critici della sicurezza delle applicazioni Web. L'autenticazione è il processo di verifica dell'identità di un utente. L'autorizzazione specifica le azioni che un utente può eseguire all'interno dell'applicazione. L'obiettivo è implementare l'autenticazione e l'autorizzazione senza indebolire il comportamento di sicurezza. Per raggiungere questo obiettivo, è necessario usare le funzionalità della piattaforma applicativa di Azure (app Azure Service) e del provider di identità (Microsoft Entra ID).

Configurare l'autenticazione utente

Proteggere l'app Web abilitando l'autenticazione utente tramite le funzionalità della piattaforma. app Azure Servizio supporta l'autenticazione con provider di identità come Microsoft Entra ID, offload del carico di lavoro di autenticazione dal codice.

Configurare l'autenticazione e l'autorizzazione del servizio

Configurare l'autenticazione e l'autorizzazione del servizio in modo che i servizi nell'ambiente dispongano delle autorizzazioni per eseguire le funzioni necessarie. Usare identità gestite in Microsoft Entra ID per automatizzare la creazione e la gestione delle identità del servizio, eliminando la gestione manuale delle credenziali. Un'identità gestita consente all'app Web di accedere in modo sicuro ai servizi di Azure, ad esempio Azure Key Vault e database. Facilita inoltre le integrazioni di pipeline CI/CD per le distribuzioni in app Azure Servizio. Tuttavia, in scenari come distribuzioni ibride o con sistemi legacy, continuare a usare le soluzioni di autenticazione locali per semplificare la migrazione. Transizione alle identità gestite quando il sistema è pronto per un approccio moderno alla gestione delle identità. Per altre informazioni, vedere Monitoraggio delle identità gestite.

Usare DefaultAzureCredential per configurare il codice

Usare DefaultAzureCredential per fornire le credenziali per lo sviluppo locale e le identità gestite nel cloud. DefaultAzureCredential genera un oggetto TokenCredential per l'acquisizione di token OAuth. Gestisce la maggior parte degli scenari di Azure SDK e delle librerie client Microsoft. Rileva l'ambiente dell'applicazione per usare l'identità corretta e richiede i token di accesso in base alle esigenze. DefaultAzureCredential semplifica l'autenticazione per le applicazioni distribuite in Azure Per altre informazioni, vedere DefaultAzureCredential.

Esempio: l'implementazione di riferimento usa la classe durante l'avvio DefaultAzureCredential per abilitare l'uso dell'identità gestita tra l'API Web e Key Vault (vedere il codice seguente).

builder.Configuration.AddAzureAppConfiguration(options =>
{
     options
        .Connect(new Uri(builder.Configuration["Api:AppConfig:Uri"]), new DefaultAzureCredential())
        .ConfigureKeyVault(kv =>
        {
            // Some of the values coming from Azure App Configuration are stored Key Vault. Use
            // the managed identity of this host for the authentication.
            kv.SetCredential(new DefaultAzureCredential());
        });
});

Usare l'infrastruttura come codice per creare identità gestite

È consigliabile usare i modelli Bicep per creare e configurare l'infrastruttura di Azure per supportare le identità gestite. Le identità gestite non usano segreti o password, quindi non è necessario un insieme di credenziali delle chiavi o una strategia di rotazione dei segreti per garantire l'integrità. È possibile archiviare i stringa di connessione nel servizio Configurazione app.

Esempio: l'implementazione di riferimento usa modelli Bicep per creare (1) l'identità gestita, (2) associare l'identità all'app Web e (3) concedere l'autorizzazione di identità per accedere al database SQL. L'argomento Authentication nella stringa di connessione indica alla libreria client Microsoft di connettersi con un'identità gestita (vedere il codice seguente).

    Server=tcp:my-sql-server.database.windows.net,1433;Initial Catalog=my-sql-database;Authentication=Active Directory Default

Per altre informazioni, vedere Connessione al database SQL da .NET servizio app.

Usare un archivio segreti centrale per gestire i segreti

Quando si sposta l'applicazione nel cloud, usare Azure Key Vault per archiviare in modo sicuro tutti questi segreti. Questo repository centralizzato offre archiviazione sicura, rotazione delle chiavi, controllo degli accessi e monitoraggio per i servizi che non supportano le identità gestite. Per le configurazioni dell'applicazione, è consigliabile app Azure Configurazione.

Esempio: l'implementazione di riferimento archivia i segreti seguenti in Key Vault: (1) nome utente e password del database PostgreSQL, (2) Password della cache Redis e (3) il segreto client per l'ID Microsoft Entra associato all'implementazione di Microsoft Authentication Library (MSAL).

Non inserire Key Vault nel flusso di richiesta HTTP

Caricare i segreti da Key Vault all'avvio dell'applicazione anziché durante ogni richiesta HTTP. Key Vault è destinato all'archiviazione e al recupero sicuro dei dati sensibili durante la distribuzione. L'accesso ad alta frequenza all'interno delle richieste HTTP può superare le funzionalità di velocità effettiva di Key Vault, causando limitazioni delle richieste e errori di codice di stato HTTP 429. Per altre informazioni, vedere Limiti delle transazioni di Key Vault.

Usare un metodo per accedere ai segreti in Key Vault

Quando si configura un'app Web per accedere ai segreti in Key Vault, sono disponibili due opzioni principali:

• impostazione servizio app'app: Usa un'impostazione dell'app in servizio app per inserire il segreto direttamente come variabile di ambiente.

• Riferimento diretto al segreto: fare riferimento direttamente al segreto all'interno del codice dell'applicazione. Aggiungere un riferimento specifico nel file delle proprietà dell'applicazione, ad esempio application.properties per le applicazioni Java, in modo che l'app comunichi con Key Vault.

È importante scegliere uno di questi metodi e attenersi a esso per semplicità ed evitare complessità non necessarie.

Preferisce i metodi di accesso temporaneo

Usare le autorizzazioni temporanee per proteggersi da accessi non autorizzati e violazioni. Usare firme di accesso condiviso (SAS) per l'accesso temporaneo. Usare la firma di accesso condiviso delega utente per ottimizzare la sicurezza quando si concede l'accesso temporaneo. È l'unica firma di accesso condiviso che usa le credenziali di Microsoft Entra e non richiede una chiave dell'account di archiviazione.

Usare endpoint privati

Usare endpoint privati in tutti gli ambienti di produzione per tutti i servizi di Azure supportati. Gli endpoint privati forniscono connessioni private tra le risorse in una rete virtuale di Azure e i servizi di Azure. Per impostazione predefinita, la comunicazione con la maggior parte dei servizi di Azure attraversa la rete Internet pubblica. Gli endpoint privati non richiedono modifiche al codice, configurazioni dell'app o stringa di connessione. Per altre informazioni, vedere Come creare un endpoint privato e Procedure consigliate per la sicurezza degli endpoint.

Esempio: configurazione app Azure, database SQL di Azure, cache di Azure per Redis, Archiviazione di Azure, servizio app Azure e Insieme di credenziali delle chiavi usano un endpoint privato.

Usare web application firewall e limitare il traffico Internet in ingresso

Tutto il traffico Internet in ingresso verso l'app Web deve passare attraverso un web application firewall per proteggersi da exploit Web comuni. Forzare tutto il traffico Internet in ingresso a passare attraverso il servizio di bilanciamento del carico pubblico, se disponibile, e il web application firewall.

Esempio: l'implementazione di riferimento forza tutto il traffico Internet in ingresso attraverso Frontdoor e Web Application Firewall di Azure. Nell'ambiente di produzione mantenere il nome host HTTP originale.

Configurare la sicurezza del database

Amministrazione istrator a livello di database concede le autorizzazioni per eseguire operazioni con privilegi. Le operazioni con privilegi includono la creazione e l'eliminazione di database, la modifica di schemi di tabella o la modifica delle autorizzazioni utente. Gli sviluppatori hanno spesso bisogno dell'accesso a livello di amministratore per gestire il database o risolvere i problemi.

• Evitare autorizzazioni con privilegi elevati permanenti. È consigliabile concedere agli sviluppatori solo l'accesso JIT per eseguire operazioni con privilegi. Con l'accesso JIT, gli utenti ricevono autorizzazioni temporanee per eseguire attività con privilegi

• Non assegnare autorizzazioni elevate all'applicazione. Non è consigliabile concedere l'accesso a livello di amministratore all'identità dell'applicazione. È consigliabile configurare l'accesso con privilegi minimi per l'applicazione al database. Limita il raggio di esplosione di bug e violazioni della sicurezza.

Ottimizzazione dei costi

L'ottimizzazione dei costi consiste nell'esaminare i modi per ridurre le spese non necessarie e il sovraccarico di gestione. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per Ottimizzazione costi. Il modello Reliable Web App implementa tecniche di rightsizing, scalabilità automatica ed utilizzo efficiente delle risorse per un'app Web ottimizzata per i costi.

Diritti delle risorse per ogni ambiente

Comprendere i diversi livelli di prestazioni dei servizi di Azure e usare solo lo SKU appropriato per le esigenze di ogni ambiente. Gli ambienti di produzione necessitano di SKU che soddisfino i contratti di servizio (SLA), le funzionalità e la scalabilità necessarie per la produzione. Gli ambienti non di produzione in genere non richiedono le stesse funzionalità. Per un risparmio aggiuntivo, prendere in considerazione le opzioni dei prezzi di Sviluppo/test di Azure, le prenotazioni di Azure e i piani di risparmio di Azure per il calcolo.

Esempio: l'implementazione di riferimento usa i parametri Bicep per attivare le configurazioni di distribuzione delle risorse. Uno di questi parametri indica i livelli di risorsa (SKU) da distribuire. L'app Web usa gli SKU più efficienti e costosi per gli ambienti di produzione e gli SKU più economici per l'ambiente non di produzione (vedere il codice seguente).

var redisCacheSkuName = isProd ? 'Standard' : 'Basic'
var redisCacheFamilyName = isProd ? 'C' : 'C'
var redisCacheCapacity = isProd ? 1 : 0

Usare la scalabilità automatica

La scalabilità automatica automatizza la scalabilità orizzontale per gli ambienti di produzione. Scalabilità automatica in base alle metriche delle prestazioni. I trigger di prestazioni di utilizzo della CPU sono un buon punto di partenza se non si conoscono i criteri di ridimensionamento dell'applicazione. È necessario configurare e adattare i trigger di ridimensionamento (CPU, RAM, rete e disco) in modo che corrispondano al comportamento dell'applicazione Web. Non ridimensionare verticalmente per soddisfare le frequenti variazioni della domanda. È meno conveniente. Per altre informazioni, vedere Scalabilità nel servizio app Azure e scalabilità automatica in Microsoft Azure.

Esempio: l'implementazione di riferimento usa la configurazione seguente nel modello Bicep. Crea una regola di scalabilità automatica per il servizio app Azure. La regola aumenta fino a 10 istanze e il valore predefinito è un'istanza. Usa l'utilizzo della CPU come trigger per il ridimensionamento e il numero di istanze. La piattaforma di hosting dell'app Web aumenta al 85% l'utilizzo della CPU e aumenta al 60%. L'impostazione di scale-out dell'85%, anziché una percentuale più vicina al 100%, fornisce un buffer per la protezione dal traffico utente accumulato causato da sessioni permanenti. Protegge anche da picchi elevati di traffico ridimensionando in anticipo per evitare il massimo utilizzo della CPU. Queste regole di scalabilità automatica non sono universali (vedere il codice seguente).

resource autoScaleRule 'Microsoft.Insights/autoscalesettings@2022-10-01' = if (autoScaleSettings != null) { 
  name: '${name}-autoscale' 
  location: location 
  tags: tags 
  properties: { 
    targetResourceUri: appServicePlan.id 
    enabled: true 
    profiles: [ 
      { 
        name: 'Auto created scale condition' 
        capacity: { 
          minimum: string(zoneRedundant ? 3 : autoScaleSettings!.minCapacity) 
          maximum: string(autoScaleSettings!.maxCapacity) 
          default: string(zoneRedundant ? 3 : autoScaleSettings!.minCapacity) 
        } 
        rules: [ 
          ... 
        ] 
      } 
    ] 
  } 
}

Usare le risorse in modo efficiente

• Usare i servizi condivisi. La centralizzazione e la condivisione di determinate risorse offre l'ottimizzazione dei costi e un sovraccarico di gestione inferiore. Posizionare le risorse di rete condivise nella rete virtuale hub.

  Esempio: l'implementazione di riferimento inserisce Firewall di Azure, Azure Bastion e Key Vault nella rete virtuale hub.

• Eliminare gli ambienti inutilizzati. Eliminare gli ambienti non di produzione dopo ore o durante le festività per ottimizzare i costi. È possibile usare l'infrastruttura come codice per eliminare le risorse di Azure e l'intero ambiente. Rimuovere la dichiarazione della risorsa da eliminare dal modello Bicep. Usare l'operazione di simulazione per visualizzare in anteprima le modifiche prima di rendere effettive le modifiche. Eseguire il backup dei dati necessari in un secondo momento. Comprendere le dipendenze dalla risorsa che si sta eliminando. Se sono presenti dipendenze, potrebbe essere necessario aggiornare o rimuovere anche tali risorse. Per altre informazioni, vedere Operazioni di simulazione della distribuzione Bicep.

• Funzionalità di colocazione. Dove è disponibile capacità di riserva, colocare le risorse e le funzionalità dell'applicazione in una singola risorsa di Azure. Ad esempio, più app Web possono usare un singolo server (piano servizio app) o una singola cache può supportare più tipi di dati.

  Esempio: l'implementazione di riferimento usa una singola istanza di cache di Azure per Redis per la gestione delle sessioni sia nelle app Web front-end (archiviazione di token del carrello e MSAL) sia nelle app Web back-end (che contengono i dati dei concerti imminenti). Opta per lo SKU Redis più piccolo, offrendo più della capacità necessaria, usata in modo efficiente usando più tipi di dati per controllare i costi.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e la mantengono in esecuzione nell'ambiente di produzione. Per altre informazioni, vedere l'elenco di controllo per la revisione della progettazione per l'eccellenza operativa. Il modello Reliable Web App implementa l'infrastruttura come codice per le distribuzioni dell'infrastruttura e il monitoraggio per l'osservabilità.

Automatizzare la distribuzione

Usare una pipeline CI/CD per distribuire le modifiche dal controllo del codice sorgente all'ambiente di produzione. Se si usa Azure DevOps, è consigliabile usare Azure Pipelines. Se si usa GitHub, usare GitHub actions. supporto tecnico di Azure s arm template (JSON), Bicep e Terraform e include modelli per ogni risorsa di Azure. Per altre informazioni, vedere Modelli Bicep, Azure Resource Manager e Terraform e infrastruttura ripetibile.

Esempio: l'implementazione di riferimento usa l'interfaccia della riga di comando di Azure Dev e l'infrastruttura come codice (modelli Bicep) per creare risorse di Azure, configurare la configurazione e distribuire le risorse necessarie.

Configurare il monitoraggio

Per monitorare l'app Web, raccogliere e analizzare metriche e log dal codice dell'applicazione, dall'infrastruttura (runtime) e dalla piattaforma (risorse di Azure). Aggiungere un'impostazione di diagnostica per ogni risorsa di Azure nell'architettura. Ogni servizio di Azure ha un set diverso di log e metriche che è possibile acquisire. Per altre informazioni, vedere Monitorare la piattaforma e Monitorare servizio app.

Monitorare le metriche di base

Usare app Azure lication Insights per tenere traccia delle metriche di base, ad esempio velocità effettiva delle richieste, durata media delle richieste, errori e monitoraggio delle dipendenze. Usare AddApplicationInsightsTelemetry dal pacchetto Microsoft.ApplicationInsights.AspNetCore NuGet per abilitare la raccolta di dati di telemetria. Per altre informazioni, vedere Abilitare la telemetria di Application Insights e l'inserimento delle dipendenze in .NET.

Esempio: l'implementazione di riferimento usa il codice per configurare le metriche di base in Application Insights (vedere il codice seguente).

public void ConfigureServices(IServiceCollection services)
{
   ...
   services.AddApplicationInsightsTelemetry(Configuration["App:Api:ApplicationInsights:ConnectionString"]);
   ...
}

Creare dati di telemetria personalizzati in base alle esigenze

Usare Application Insights per raccogliere dati di telemetria personalizzati per comprendere meglio gli utenti dell'app Web. Creare un'istanza della TelemetryClient classe e usare i TelemetryClient metodi per creare la metrica corretta. Trasformare la query in un widget dashboard di Azure.

Esempio: l'implementazione di riferimento aggiunge metriche che consentono al team operativo di identificare che l'app Web sta completando correttamente le transazioni. Verifica che l'app Web sia online monitorando se i clienti possono effettuare ordini, non misurando il numero di richieste o l'utilizzo della CPU. L'implementazione di riferimento usa TelemetryClient tramite l'inserimento delle dipendenze e il TrackEvent metodo per raccogliere dati di telemetria sugli eventi correlati all'attività del carrello. I dati di telemetria tengono traccia dei ticket aggiunti, rimossi e acquistati dagli utenti (vedere il codice seguente).

• AddToCart conta quante volte gli utenti aggiungono un determinato biglietto (ConcertID) al carrello.
• RemoveFromCart registra i ticket rimossi dagli utenti dal carrello.
• CheckoutCart registra un evento ogni volta che un utente acquista un ticket.

this.telemetryClient.TrackEvent conta i biglietti aggiunti al carrello. Fornisce il nome dell'evento (AddToCart) e specifica un dizionario con concertId e count (vedere il codice seguente).

this.telemetryClient.TrackEvent("AddToCart", new Dictionary<string, string> {
    { "ConcertId", concertId.ToString() },
    { "Count", count.ToString() }
});

Per altre informazioni, vedi:

• API di Application Insights per metriche ed eventi personalizzati
• Classe TelemetryClient
• Metodi client di telemetria

Raccogliere metriche basate su log

Tenere traccia delle metriche basate su log per ottenere maggiore visibilità sull'integrità e sulle metriche essenziali dell'applicazione. È possibile usare query Linguaggio di query Kusto (KQL) in Application Insights per trovare e organizzare i dati. Per altre informazioni, vedere metriche basate su log di app Azure lication Insights e metriche basate su log e metriche preaggregate in Application Insights.

Abilitare la diagnostica della piattaforma

Un'impostazione di diagnostica in Azure consente di specificare i log e le metriche della piattaforma da raccogliere e dove archiviarli. I log della piattaforma sono log predefiniti che forniscono informazioni di diagnostica e controllo. È possibile abilitare la diagnostica della piattaforma per la maggior parte dei servizi di Azure, ma ogni servizio definisce le proprie categorie di log. Diversi servizi di Azure hanno categorie di log da scegliere.

• Abilitare la diagnostica per tutti i servizi supportati. I servizi di Azure creano automaticamente i log della piattaforma, ma il servizio non li archivia automaticamente. È necessario abilitare l'impostazione di diagnostica per ogni servizio ed è necessario abilitarla per ogni servizio di Azure che supporta la diagnostica.

• Inviare la diagnostica alla stessa destinazione dei log applicazioni. Quando si abilita la diagnostica, selezionare i log da raccogliere e dove inviarli. È necessario inviare i log della piattaforma alla stessa destinazione dei log dell'applicazione in modo da poter correlare i due set di dati.

Efficienza prestazionale

L'efficienza delle prestazioni è la capacità di dimensionare il carico di lavoro per soddisfare in modo efficiente le richieste poste dagli utenti. Per altre informazioni, vedere l'elenco di controllo per la revisione della progettazione per l'efficienza delle prestazioni. Il modello Reliable Web App usa il modello Cache-Aside per ridurre al minimo la latenza per i dati altamente richiesti.

Usare il modello Cache-Aside

Il modello Cache-Aside è una strategia di memorizzazione nella cache che migliora la gestione dei dati in memoria. Il modello assegna all'applicazione la responsabilità di gestire le richieste di dati e garantire la coerenza tra la cache e un archivio permanente, ad esempio un database. Quando l'app Web riceve una richiesta di dati, cerca prima la cache. Se i dati sono mancanti, vengono recuperati dal database, risponde alla richiesta e aggiorna la cache di conseguenza. Questo approccio riduce i tempi di risposta e migliora la velocità effettiva e riduce la necessità di aumentare la scalabilità. Inoltre, rafforza la disponibilità del servizio riducendo il carico nell'archivio dati primario e riducendo al minimo i rischi di interruzione.

Esempio: l'implementazione di riferimento migliora l'efficienza dell'applicazione memorizzando nella cache i dati critici, ad esempio le informazioni per i concerti imminenti cruciali per le vendite di biglietti. Usa la cache di memoria distribuita di ASP.NET Core per l'archiviazione degli elementi in memoria. L'applicazione usa automaticamente cache di Azure per Redis quando trova un stringa di connessione specifico. Supporta anche ambienti di sviluppo locali senza Redis per semplificare la configurazione e ridurre i costi e la complessità. Il metodo (AddAzureCacheForRedis) configura l'applicazione per l'uso di cache di Azure per Redis (vedere il codice seguente).

private void AddAzureCacheForRedis(IServiceCollection services)
{
    if (!string.IsNullOrWhiteSpace(Configuration["App:RedisCache:ConnectionString"]))
    {
        services.AddStackExchangeRedisCache(options =>
        {
            options.Configuration = Configuration["App:RedisCache:ConnectionString"];
        });
    }
    else
    {
        services.AddDistributedMemoryCache();
    }
}

Per altre informazioni, vedere Memorizzazione nella cache distribuita in ASP.NET metodo Core e AddDistributedMemoryCache.

Memorizzare nella cache i dati con esigenze elevate

Classificare in ordine di priorità la memorizzazione nella cache per i dati a cui si accede più di frequente. Identificare i punti dati chiave che determinano il coinvolgimento degli utenti e le prestazioni del sistema. Implementare strategie di memorizzazione nella cache specifiche per queste aree per ottimizzare l'efficacia del modello Cache-Aside, riducendo significativamente la latenza e il carico del database. Usare Monitoraggio di Azure per tenere traccia della CPU, della memoria e dell'archiviazione del database. Queste metriche consentono di determinare se è possibile usare uno SKU di database più piccolo.

Esempio: l'implementazione di riferimento memorizza nella cache i dati che supportano i concerti imminenti. La pagina Prossimi concerti crea la maggior parte delle query da database SQL e produce un output coerente per ogni visita. Il modello Cache-Aside memorizza nella cache i dati dopo la prima richiesta di questa pagina per ridurre il carico nel database. Il codice seguente usa il metodo per eseguire il GetUpcomingConcertsAsync pull dei dati nella cache Redis da database SQL. Il metodo popola la cache con i concerti più recenti. Il metodo filtra in base all'ora, ordina i dati e restituisce i dati al controller per visualizzare i risultati (vedere il codice seguente).

public async Task<ICollection<Concert>> GetUpcomingConcertsAsync(int count)
{
    IList<Concert>? concerts;
    var concertsJson = await this.cache.GetStringAsync(CacheKeys.UpcomingConcerts);
    if (concertsJson != null)
    {
        // There is cached data. Deserialize the JSON data.
        concerts = JsonSerializer.Deserialize<IList<Concert>>(concertsJson);
    }
    else
    {
        // There's nothing in the cache. Retrieve data from the repository and cache it for one hour.
        concerts = await this.database.Concerts.AsNoTracking()
            .Where(c => c.StartTime > DateTimeOffset.UtcNow && c.IsVisible)
            .OrderBy(c => c.StartTime)
            .Take(count)
            .ToListAsync();
        concertsJson = JsonSerializer.Serialize(concerts);
        var cacheOptions = new DistributedCacheEntryOptions {
            AbsoluteExpirationRelativeToNow = TimeSpan.FromHours(1)
        };
        await this.cache.SetStringAsync(CacheKeys.UpcomingConcerts, concertsJson, cacheOptions);
    }
    return concerts ?? new List<Concert>();
}

Mantenere aggiornati i dati della cache

Pianificare gli aggiornamenti regolari della cache per la sincronizzazione con le modifiche più recenti del database. Determinare la frequenza di aggiornamento ottimale in base alla volatilità dei dati e alle esigenze degli utenti. Questa procedura garantisce che l'applicazione usi il modello Cache-Aside per fornire sia l'accesso rapido che le informazioni correnti.

Esempio: l'implementazione di riferimento memorizza nella cache i dati solo per un'ora. Ha un processo per cancellare la chiave della cache quando i dati vengono modificati. Il CreateConcertAsync metodo cancella la chiave della cache (vedere il codice seguente).

public async Task<CreateResult> CreateConcertAsync(Concert newConcert)
{
    database.Add(newConcert);
    await this.database.SaveChangesAsync();
    this.cache.Remove(CacheKeys.UpcomingConcerts);
    return CreateResult.SuccessResult(newConcert.Id);
}

Garantire la coerenza dei dati

Implementare meccanismi per aggiornare la cache immediatamente dopo qualsiasi operazione di scrittura del database. Usare aggiornamenti basati su eventi o classi di gestione dei dati dedicate per garantire la coerenza della cache. La sincronizzazione coerente della cache con le modifiche del database è fondamentale per il modello Cache-Aside.

Esempio: l'implementazione di riferimento usa il UpdateConcertAsync metodo per mantenere coerenti i dati nella cache (vedere il codice seguente).

public async Task<UpdateResult> UpdateConcertAsync(Concert existingConcert), 
{
   database.Update(existingConcert);
   await database.SaveChangesAsync();
   this.cache.Remove(CacheKeys.UpcomingConcerts);
   return UpdateResult.SuccessResult();
}

Testare le prestazioni del database

Le prestazioni del database possono influire sulle prestazioni e sulla scalabilità di un'applicazione. È importante testare le prestazioni del database per assicurarsi che sia ottimizzato. Alcune considerazioni chiave includono la scelta dell'area cloud corretta, il pool di connessioni, il modello cache-aside e l'ottimizzazione delle query.

• Testare gli hop di rete. Lo spostamento di un'applicazione nel cloud può introdurre hop di rete e latenza aggiuntivi per il database. È consigliabile verificare la disponibilità di hop aggiuntivi introdotti dal nuovo ambiente cloud.

• Stabilire una linea di base per le prestazioni. È consigliabile usare le metriche delle prestazioni locali come baseline iniziale per confrontare le prestazioni dell'applicazione nel cloud.

Passaggi successivi

Distribuire l'implementazione di riferimento seguendo le istruzioni nel repository GitHub. Usare le risorse seguenti per altre informazioni su applicazioni .NET, app Web, procedure consigliate per il cloud e migrazione.

Aggiornamento di applicazioni .NET Framework

L'implementazione di riferimento viene distribuita in un servizio app che esegue Windows, ma può essere eseguito in Linux. La piattaforma windows servizio app consente di spostare le app Web .NET Framework in Azure senza eseguire l'aggiornamento alle versioni del framework più recenti. Per informazioni sui piani di servizio app Linux o sulle nuove funzionalità e miglioramenti delle prestazioni aggiunti alle versioni più recenti di .NET, vedere le indicazioni seguenti.

• Panoramica della conversione da .NET Framework a .NET. Ottenere indicazioni in base al tipo specifico di app .NET.
• Panoramica di .NET Upgrade Assistant. Informazioni su uno strumento console che consente di automatizzare molte delle attività associate all'aggiornamento di progetti .NET Framework.
• Migrazione da ASP.NET a ASP.NET Core in Visual Studio. Informazioni su un'estensione di Visual Studio che consente di eseguire migrazioni incrementali di app Web.

Introduzione alle app Web in Azure

Per un'introduzione pratica alle applicazioni Web .NET in Azure, vedere questa guida per la distribuzione di un'applicazione Web .NET di base.

Procedure consigliate per il cloud

Per indicazioni sull'adozione e l'architettura di Azure, vedere:

• Cloud Adoption Framework. Può aiutare l'organizzazione a preparare ed eseguire una strategia per creare soluzioni in Azure.
• Framework ben progettato. Set di set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro.

Per le applicazioni che richiedono uno SLO superiore rispetto al modello Reliable Web App, vedere Carichi di lavoro cruciali.

Indicazioni sulla migrazione

Gli strumenti e le risorse seguenti consentono di eseguire la migrazione delle risorse locali ad Azure.

• Azure Migrate offre un servizio di migrazione, modernizzazione e ottimizzazione semplificato per Azure che gestisce la valutazione e la migrazione di app Web, SQL Server e macchine virtuali.
• Guide alla migrazione del database di Azure offre risorse per diversi tipi di database e strumenti diversi progettati per lo scenario di migrazione.
• app Azure acceleratore di zona di destinazione del servizio fornisce indicazioni per la protezione avanzata e il ridimensionamento delle distribuzioni servizio app.
• Applicazione e valutazione del codice di Azure Migrate