Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Multi-Region dispiegamento
Per MultiRegiongli PerRegionendpoint, Lambda replica gli artefatti di runtime in tutte le regioni di destinazione in modo che l'applicazione possa servire il traffico vicino agli utenti finali. È possibile gestire la funzione Web interamente dalla regione di origine. Le risorse replicate non sono visibili o modificabili nelle regioni di replica.
Il diagramma seguente mostra come il piano di controllo nella regione di origine prepara una revisione e ne replica il codice e la configurazione in una regione di replica e come i client raggiungono gli endpoint. MultiRegionPerRegion Una regione di replica non ha un piano di controllo. Un MultiRegionendpoint ha un dominio globale che esegue il routing in base alla latenza, non in base allo stato della regione. Per un PerRegionendpoint, gestisci il modo in cui i client raggiungono il dominio regionale in ogni regione, ad esempio con i record Route 53 o. CloudFront Il tipo di endpoint e le regioni vengono impostati al momento della creazione dell'endpoint e non è possibile modificarli in un secondo momento.
Argomenti
Cosa replica Lambda
Lambda replica quanto segue in ogni regione di destinazione:
-
Elemento di codice preparato: l'artefatto di runtime interno che Lambda deriva dall'oggetto sorgente Amazon S3 con versione.
-
Configurazione di revisione: timeout, concorrenza, variabili di ambiente e impostazioni di runtime.
-
Resource-based policy — Policy allegate alla funzione Web che ne garantiscono l'accesso.
-
Tag — I tag della funzione Web.
Le quote per le funzioni Web si applicano per. Regione AWS Ogni regione di destinazione impone le proprie quote di account sull'endpoint replicato. Ad esempio, il ridimensionamento dell'ambiente di esecuzione in una regione di replica è limitato dalla quota vCPU dell'account di tale regione. Per le quote degli account, vedere. Quote degli account
Visibilità delle repliche
Le risorse replicate non sono visibili nelle regioni di replica. Il piano di controllo di una funzione Web viene fornito solo nella relativa regione di origine, quindi tutte le richieste API devono essere inviate alla regione di origine. Questo include:
-
Elenca, ottieni e descrivi le richieste per la funzione Web, le sue revisioni e i suoi endpoint.
-
Crea, aggiorna ed elimina le richieste per la funzione, le revisioni e la configurazione degli endpoint.
Una richiesta API inviata all'endpoint del piano di controllo di una regione di replica ha esito negativo, indipendentemente da dove si trova il chiamante. Gli artefatti di runtime replicati esistono solo per consentire al piano dati di servire il traffico.
Quando si verifica la replica
La replica viene attivata quando si crea o si aggiorna un MultiRegionendpoint. PerRegion In particolare, la replica si verifica quando:
-
Si crea un PerRegion endpoint MultiRegion or con pesi di revisione che puntano a una revisione.
-
Si aggiornano i pesi di revisione su un dispositivo MultiRegion o PerRegion su un endpoint per includere una nuova revisione.
-
Aggiorna altre impostazioni dell'endpoint, ad esempio, o
authTypescalingConfigthrottleConfig, su un dispositivo o. MultiRegion PerRegion
La sola creazione di una revisione non attiva la replica. La revisione deve essere inclusa nei pesi di revisione di un endpoint con regioni di destinazione configurate. Poiché solo la modalità di distribuzione automatica disattivata è disponibile per tutti MultiRegion gli PerRegion endpoint, la replica è sempre il risultato di una modifica dell'endpoint apportata dall'utente.
Come funziona l'instradamento
Il comportamento di routing dipende dal tipo di endpoint:
- MultiRegion
-
Lambda fornisce un unico nome di dominio globale. Le richieste vengono instradate utilizzando un routing basato sulla latenza. Le richieste vengono instradate verso la regione che in genere fornisce la latenza di rete più bassa per il chiamante, in base alle misurazioni della latenza raccolte da Route 53 nel tempo. Poiché la latenza Internet cambia, Lambda non garantisce che ogni richiesta arrivi alla regione con la latenza più bassa. Lambda gestisce automaticamente i percorsi per te.
- PerRegion
-
Lambda fornisce un nome di dominio regionale separato in ciascuna regione di destinazione. Sei responsabile della gestione del modo in cui il traffico raggiunge ogni dominio regionale. Ad esempio, puoi configurare la tua politica di routing della Route 53 o inserire una CloudFront distribuzione davanti ai domini regionali.
Errori di replica
La replica può fallire in una regione a causa di un problema temporaneo del servizio. Se si crittografa la funzione Web con una chiave gestita dal cliente, anche una replica della chiave mancante nella regione di destinazione causa il fallimento della replica. Per i requisiti chiave multiregionali, consulta. Configurazione di una chiave gestita dal cliente
L'effetto di un errore di replica dipende dal fatto che si stia creando o aggiornando l'endpoint. Se la replica fallisce in qualsiasi regione mentre Lambda crea l'endpoint, l'endpoint passa allo stato Failed e non è richiamabile in nessuna regione. Per riprovare, elimina l'endpoint e crealo di nuovo. Se la replica fallisce in una regione durante un aggiornamento dell'endpoint, l'errore è limitato a quella regione. L'endpoint rimane richiamabile e le altre regioni continuano a funzionare normalmente.
Quando la replica di una nuova revisione non riesce in una regione, tale regione continua a servire il traffico utilizzando la revisione precedente che è stata implementata con successo. L'endpoint non viene ripristinato. Continua a funzionare con l'ultimo buono stato conosciuto in ogni regione.
È possibile visualizzare lo stato di ciascuna regione e aggiornare lo stato nel regionalEndpoints campo della GetWebFunctionEndpoint risposta. La voce di ciascuna regione include:
-
stateestateReason: lo stato di distribuzione della regione durante la creazione degli endpoint. -
updateStatuseupdateStatusReason— Il risultato dell'aggiornamento più recente (ad esempio, l'implementazione di una revisione) in quella regione.
Per risolvere un errore di replica, risolvete la causa principale (ad esempio, create una replica AWS KMS chiave nella regione interessata). Per riprovare un aggiornamento dell'endpoint non riuscito dopo aver risolto la causa principale, chiama di nuovo. UpdateWebFunctionEndpoint È possibile ripetere le stesse impostazioni o specificare solo il nome della funzione e il nome dell'endpoint. Entrambe le richieste avviano una nuova distribuzione nelle regioni di destinazione. Funziona solo quando l'endpoint è attivo. Se la creazione dell'endpoint non è riuscita, elimina l'endpoint e crealo di nuovo.
Consistenza finale
La replica degli artefatti del runtime alla fine è coerente. Non date per scontato che ogni regione esegua la nuova configurazione finché ogni regione non sarà inclusa nei report. updateStatus regionalEndpoints Successful
Resource-based le modifiche alle politiche possono finire di propagarsi dopo le modifiche al codice e alla configurazione. Durante la finestra di replica, le richieste nelle regioni di replica potrebbero essere valutate rispetto alla versione precedente della policy. Per ulteriori informazioni, consulta Replica ed eventuale coerenza.
