Ottimizzare le applicazioni Python per Cloud Run

Questa guida descrive le ottimizzazioni per i servizi Cloud Runscritti nel linguaggio di programmazione Python, insieme alle informazioni di base per aiutarti a comprendere i compromessi coinvolti in alcune delle ottimizzazioni. Le informazioni riportate in questa pagina integrano i suggerimenti generali per l'ottimizzazione, che si applicano anche a Python.

Molte delle best practice e delle ottimizzazioni di queste applicazioni web tradizionali basate su Python ruotano attorno a:

  • Gestione di richieste in parallelo (I/O sia basati su thread che non bloccanti)
  • Riduzione della latenza di risposta utilizzando il pool di connessioni e il raggruppamento in batch non critici come l'invio di tracce e metriche alle attività in background.

Ottimizza l'immagine container

Ottimizzando l'immagine del contenitore, puoi ridurre i tempi di caricamento e di avvio. Tu puoi ottimizzare l'immagine:

  • Inserire nel container solo ciò di cui l'app ha bisogno in fase di esecuzione
  • Ottimizzazione del server WSGI

Inserisci nel contenitore solo ciò di cui la tua app ha bisogno in fase di esecuzione

Valuta quali componenti sono inclusi nel container e se sono obbligatori per l'esecuzione del servizio. Esistono diversi modi per ridurre al minimo immagine container:

  • Utilizza un'immagine di base più piccola
  • Spostare file di grandi dimensioni all'esterno del contenitore

Utilizza un'immagine di base più piccola

Docker Hub fornisce una serie di immagini di base Python ufficiali che puoi utilizzare, se scegli di non installare Python dal codice sorgente all'interno dei container. Sono basati sul sistema operativo Debian.

Se utilizzi l'immagine python di Docker Hub, valuta la possibilità di utilizzare la versione slim. Queste immagini sono di dimensioni inferiori perché non includono una serie di pacchetti che potrebbero essere utilizzati per creare, ad esempio, le ruote, il che potrebbe non essere necessario per la tua applicazione. Ad esempio, l'immagine Python include il compilatore, il preprocessore e le utility di base GNU C.

Per identificare i dieci pacchetti più grandi in un'immagine di base, puoi eseguire questo :

DOCKER_IMAGE=python # or python:slim
docker run --rm ${DOCKER_IMAGE} dpkg-query -Wf '${Installed-Size}\t${Package}\t${Description}\n' | sort -n | tail -n10 | column -t -s $'\t'

Poiché esistono meno pacchetti di basso livello, anche le immagini basate su slim offrono una minore superficie di attacco per le potenziali vulnerabilità. Tieni presente che queste immagini potrebbero non includere gli elementi necessari per creare le ruote dall'origine.

Puoi inserire di nuovo pacchetti specifici aggiungendo una riga RUN apt install alla Dockerfile. Scopri di più sull'utilizzo dei pacchetti di sistema in Cloud Run.

Sono disponibili anche opzioni per i container non basati su Debian. L'opzione python:alpine potrebbe comportare un contenitore molto più piccolo, ma molti pacchetti Python potrebbero non avere i wheel precompilati che supportano i sistemi basati su Alpine. L'assistenza sta migliorando (vedi PEP-656), ma continua a essere variata. Puoi anche valutare la possibilità di utilizzare distroless base image, che non contiene gestori pacchetti, shell o altri programmi.

Spostare i file di grandi dimensioni all'esterno del contenitore

I file di grandi dimensioni, come gli asset multimediali e così via, non devono essere inclusi nel contenitore di base.

Google Cloud offre più opzioni di hosting, come Cloud Storage, per archiviare questi elementi di grandi dimensioni. Sposta gli asset di grandi dimensioni in questi servizi, quindi fai riferimento a questi asset dalla tua applicazione in fase di esecuzione.

Ottimizzare il server WSGI

Python ha standardizzato il modo in cui le applicazioni possono interagire con i server web mediante l'implementazione dello standard WSGI, PEP-3333. Uno dei più comuni Il server WSGI è gunicorn e viene utilizzato in gran parte della documentazione di esempio.

Ottimizza gunicorn

Aggiungi il seguente CMD a Dockerfile per ottimizzare l'invocazione di gunicorn:

CMD exec gunicorn --bind :$PORT --workers 1 --threads 8 --timeout 0 main:app

Se stai valutando la possibilità di modificare queste impostazioni, regola il numero di worker e di thread in base all'applicazione. Ad esempio, prova a utilizzare un numero di worker uguale ai core disponibili e assicurati che ci sia un miglioramento delle prestazioni, quindi modifica il numero di thread. L'impostazione di un numero eccessivo di worker o thread può avere un impatto negativo, come una latenza dell'avvio a freddo più lunga, più memoria consumata, meno richieste al secondo e così via.

Per impostazione predefinita, gunicorn visualizza i worker e rimane in ascolto sulla porta specificata quando anche prima di valutare il codice dell'applicazione. In questo caso, devi configurare probe di avvio personalizzati per il tuo servizio, poiché il probe di avvio predefinito di Cloud Run contrassegna immediatamente un'istanza di container in stato integro non appena inizia l'ascolto su $PORT.

Se vuoi modificare questo comportamento, puoi richiamare gunicorn con l'impostazione --preload per valutare il codice dell'applicazione prima dell'ascolto. In questo modo puoi:

  • Identifica bug di runtime seri al momento del deployment
  • Risparmiare risorse di memoria

Prima di aggiungere questo elemento, devi considerare l'applicazione in fase di precaricamento.

Altri server WSGI

Non hai la limitazione all'utilizzo di gunicorn per eseguire Python nei container. Puoi utilizzare qualsiasi server web WSGI o ASGI, a condizione che il contenitore rimanga in ascolto sulla porta HTTP $PORT, come da contratto di runtime del contenitore.

Le alternative più comuni sono uwsgi, uvicorn e waitress.

Ad esempio, nel file denominato main.py contenente l'oggetto app, il valore le seguenti chiamate avviano un server WSGI:

# uwsgi: pip install pyuwsgi
uwsgi --http :$PORT -s /tmp/app.sock --manage-script-name --mount /app=main:app

# uvicorn: pip install uvicorn
uvicorn --port $PORT --host 0.0.0.0 main:app

# waitress: pip install waitress
waitress-serve --port $PORT main:app

Possono essere aggiunti come riga CMD exec in un file Dockerfile o come voce web: in Procfile quando si utilizzano i buildpack di Google Cloud.

Ottimizza le applicazioni

Nel codice del servizio Cloud Run, puoi anche ottimizzare per tempi di avvio e utilizzo della memoria più rapidi.

Riduci i thread

Puoi ottimizzare la memoria riducendo il numero di thread, utilizzando strategie reattive non bloccanti ed evitando le attività in background. Inoltre, evita di scrivere nell'email come indicato nel pagina di suggerimenti generali.

Se vuoi supportare le attività in background nel tuo servizio Cloud Run, imposta la CPU del servizio Cloud Run in modo che sia sempre allocata in modo da poter eseguire attività in background al di fuori delle richieste e avere comunque accesso alla CPU.

Riduci le attività di avvio

Le applicazioni Python basate sul web possono avere molte attività da completare durante l'avvio, ad esempio precaricare i dati, riscaldare la cache, stabilire pool di connessioni e così via. Queste attività, se eseguite in sequenza, possono essere lente. Tuttavia, se vuoi per l'esecuzione in parallelo, devi aumentare il numero di core CPU.

Al momento Cloud Run invia una richiesta di un utente reale per attivare un'istanza di avvio a freddo. Gli utenti con una richiesta assegnata a un'istanza appena avviata potrebbero avere tempi lunghi ritardi. Al momento Cloud Run non dispone di un controllo di "idoneità" per evitare di inviare richieste a applicazioni non pronte.

Passaggi successivi

Per altri suggerimenti, vedi