Porady i wskazówki

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

W tym dokumencie znajdziesz sprawdzone metody projektowania, implementowania, testowania i wdrażania Cloud Functions.

Poprawność

Ta sekcja zawiera ogólne sprawdzone metody projektowania i wdrażania Cloud Functions.

Pisanie funkcji idempotentnych

Funkcje powinny dawać ten sam wynik, nawet jeśli są wywoływane wielokrotnie. Dzięki temu możesz ponownie wywołać funkcję, jeśli poprzednie wywołanie nie powiodło się w połowie wykonywania kodu. Więcej informacji znajdziesz w artykule o powtarzaniu funkcji wywoływanych przez zdarzenia.

Nie uruchamiaj aktywności w tle

Aktywność w tle to wszystko, co dzieje się po zakończeniu działania funkcji. Wywołanie funkcji kończy się, gdy funkcja zwraca wartość lub w inny sposób sygnalizuje zakończenie, np. przez wywołanie argumentu callback w funkcjach sterowanych zdarzeniami w Node.js. Żaden kod uruchamiany po łagodnym zakończeniu nie ma dostępu do procesora i nie będzie się rozwijać.

Ponadto, gdy w tym samym środowisku zostanie wywołana kolejna operacja, Twoja aktywność w tle zostanie wznowiona, co zakłóci nowe wywołanie. Może to prowadzić do nieoczekiwanego działania i błędów, które są trudne do zdiagnozowania. Dostęp do sieci po zakończeniu działania funkcji zwykle powoduje zresetowanie połączeń (kod błędu ECONNRESET).

Aktywność w tle można często wykryć w dziennikach poszczególnych wywołań, znajdując wszystko, co zostało zapisane po wierszu informującym o zakończeniu wywołania. Aktywność w tle może być czasami ukryta głębiej w kodzie, zwłaszcza gdy występują operacje asynchroniczne, takie jak funkcje zwrotne lub minutniki. Sprawdź kod, aby upewnić się, że wszystkie operacje asynchroniczne zostały zakończone, zanim zakończysz funkcję.

Zawsze usuwaj pliki tymczasowe

Pamięć lokalna dysku w katalogu tymczasowym to pamięć podręczna w pamięci operacyjnej. Tworzone przez Ciebie pliki zużywają pamięć dostępną dla funkcji i czasami są przechowywane między wywołaniami. Nieusunięcie tych plików może w ostatecznym rozrachunku doprowadzić do błędu braku pamięci i następnego zimnego uruchomienia.

Pamięć używaną przez poszczególne funkcje możesz sprawdzić, wybierając je w liście funkcji w konsoli Google Cloud i klikając wykres Wykorzystanie pamięci.

Jeśli potrzebujesz dostępu do długoterminowego miejsca na dane, rozważ użycie Cloud Run wolumenu zamontowanego za pomocą Cloud Storage lub wolumenów NFS.

Możesz zmniejszyć wymagania dotyczące pamięci podczas przetwarzania większych plików, korzystając z przesyłania danych w ruchu. Możesz na przykład przetworzyć plik w Cloud Storage, tworząc strumień odczytu, przekazując go przez proces oparty na strumieniach i zapisując strumień wyjściowy bezpośrednio w Cloud Storage.

Platforma funkcji

Aby zapewnić spójne instalowanie tych samych zależności we wszystkich środowiskach, zalecamy uwzględnienie biblioteki Functions Framework w menedżerze pakietów i przypięcie zależności do konkretnej wersji Functions Framework.

Aby to zrobić, dodaj preferowaną wersję do odpowiedniego pliku blokady (na przykład package-lock.json w przypadku Node.js lub requirements.txt w przypadku Pythona).

Jeśli funkcja Functions Framework nie jest wymieniona jako zależność, zostanie automatycznie dodana podczas procesu kompilacji, korzystając z najnowszej dostępnej wersji.

Narzędzia

W tej sekcji znajdziesz wskazówki dotyczące korzystania z narzędzi do implementowania, testowania i interakcji z usługą Cloud Functions.

Lokalny proces programowania

Wdrażanie funkcji zajmuje trochę czasu, dlatego często szybciej jest przetestować kod funkcji lokalnie.

Unikanie limitów czasu wdrażania podczas inicjalizacji

Jeśli wdrożenie funkcji zakończy się błędem limitu czasu, oznacza to prawdopodobnie, że kod o zasięgu globalnym funkcji wymaga zbyt dużo czasu na wykonanie podczas procesu wdrażania.

Interfejs wiersza poleceń Firebase ma domyślny limit czasu na wykrywanie funkcji podczas wdrażania. Jeśli logika inicjowania w kodzie źródłowym funkcji (wczytywanie modułów, wywoływanie połączeń sieciowych itp.) przekroczy ten limit czasu, wdrożenie może się nie udać.

Aby uniknąć limitu czasu, zastosuj jedną z tych strategii:

(zalecane) użyj funkcji onInit(), aby opóźnić inicjalizację

Aby uniknąć uruchamiania kodu inicjowania podczas wdrażania, użyj elementu onInit(). Kod w haku onInit() będzie wykonywany tylko wtedy, gdy funkcja zostanie wdrożona do funkcji Cloud Run, a nie podczas samego procesu wdrażania.

const { onInit } = require('firebase-functions/v2/core');
const { onRequest } = require('firebase-functions/v2/https');

// Example of a slow initialization task
function slowInitialization() {
  // Simulate a long-running operation (e.g., loading a large model, network request).
  return new Promise(resolve => {
      setTimeout(() => {
          console.log("Slow initialization complete");
          resolve("Initialized Value");
      }, 20000); // Simulate a 20-second delay
  });
}
let initializedValue;

onInit(async () => {
  initializedValue = await slowInitialization();
});

exports.myFunction = onRequest((req, res) => {
  // Access the initialized value. It will be ready after the first invocation.
  res.send(`Value: ${initializedValue}`);
});

from firebase_functions.core import init
from firebase_functions import https_fn
import time

# Example of a slow initialization task
def _slow_initialization():
  time.sleep(20)  # Simulate a 20-second delay
  print("Slow initialization complete")
  return "Initialized Value"

_initialized_value = None

@init
def initialize():
  global _initialized_value
  _initialized_value = _slow_initialization()

@https_fn.on_request()
def my_function(req: https_fn.Request) -> https_fn.Response:
  # Access the initialized value. It will be ready after the first invocation.
  return https_fn.Response(f"Value: {_initialized_value}")

(Opcjonalnie) Zwiększ czas oczekiwania na wykrycie

Jeśli nie możesz zrefaktoryzować kodu, aby używać onInit(), możesz zwiększyć limit czasu wdrażania CLI za pomocą zmiennej środowiskowej FUNCTIONS_DISCOVERY_TIMEOUT:

$ export FUNCTIONS_DISCOVERY_TIMEOUT=30
$ firebase deploy --only functions

Wysyłanie e-maili za pomocą Sendgrid

Cloud Functions nie zezwala na połączenia wychodzące przez port 25, więc nie można nawiązywać niezabezpieczonych połączeń z serwerem SMTP. Zalecane jest wysyłanie e-maili za pomocą usługi zewnętrznej, takiej jak SendGrid. Inne opcje wysyłania e-maili znajdziesz w samouczku wysyłania e-maili z instancji na temat Google Compute Engine.

Skuteczność

W tej sekcji znajdziesz sprawdzone metody optymalizacji skuteczności.

Unikaj niskiej liczby jednoczesnych użytkowników

Uruchomienia „na zimno” są kosztowne, dlatego możliwość ponownego użycia niedawno uruchomionych instancji podczas nagłego wzrostu obciążenia to świetna optymalizacja pozwalająca radzić sobie z obciążeniem. Ograniczenie współbieżności ogranicza możliwości wykorzystania istniejących instancji, co powoduje większą liczbę uruchamiania „na zimno”.

Mądre korzystanie z zależności

Funkcja nie ma stanu, dlatego środowisko wykonawcze jest często inicjowane od podstaw (podczas tzw. uruchamiania na zimno). W przypadku uruchomienia „na zimno” jest oceniany globalny kontekst funkcji.

Jeśli Twoje funkcje importują moduły, czas ich wczytywania może wydłużać opóźnienie wywołania podczas uruchamiania „na zimno”. Możesz zmniejszyć to opóźnienie, a także czas potrzebny do wdrożenia funkcji, prawidłowo wczytując zależności i nie wczytując zależności, których Twoja funkcja nie używa.

Używanie zmiennych globalnych do ponownego używania obiektów w przyszłych wywołaniach

Nie ma gwarancji, że stan funkcji zostanie zachowany na potrzeby przyszłych wywołań. Jednak Cloud Functions często wykorzystuje środowisko wykonania z poprzedniego wywołania. Jeśli zadeklarujesz zmienną w zakresie globalnym, jej wartość może być używana ponownie w kolejnych wywołaniach bez konieczności ponownego obliczania.

Dzięki temu możesz przechowywać w pamięci podręcznej obiekty, które mogą być kosztowne do odtworzenia przy każdym wywołaniu funkcji. Przeniesienie takich obiektów z ciał funkcji do zakresu globalnego może znacznie poprawić wydajność. W tym przykładzie ciężki obiekt jest tworzony tylko raz na instancję funkcji i udostępniany wszystkim wywołaniom funkcji, które docierają do danej instancji:

console.log('Global scope');
const perInstance = heavyComputation();
const functions = require('firebase-functions');

exports.function = functions.https.onRequest((req, res) => {
  console.log('Function invocation');
  const perFunction = lightweightComputation();

  res.send(`Per instance: ${perInstance}, per function: ${perFunction}`);
});

import time

from firebase_functions import https_fn

# Placeholder
def heavy_computation():
  return time.time()

# Placeholder
def light_computation():
  return time.time()

# Global (instance-wide) scope
# This computation runs at instance cold-start
instance_var = heavy_computation()

@https_fn.on_request()
def scope_demo(request):

  # Per-function scope
  # This computation runs every time this function is called
  function_var = light_computation()
  return https_fn.Response(f"Instance: {instance_var}; function: {function_var}")
  

Szczególnie ważne jest przechowywanie w pamięci podręcznej połączeń sieciowych, odwołań do bibliotek i obiektów klienta interfejsu API w zakresie globalnym. Przykłady znajdziesz w sekcji Optymalizacja sieci.

Ograniczanie uruchomień „na zimno” przez ustawienie minimalnej liczby instancji

Domyślnie Cloud Functions skaluje liczbę instancji na podstawie liczby żądań przychodzących. Możesz zmienić to domyślne działanie, ustawiając minimalną liczbę instancji, które Cloud Functions musi utrzymywać w gotowości do obsługi żądań. Ustawienie minimalnej liczby instancji ogranicza uruchomienia „na zimno” aplikacji. Jeśli aplikacja jest wrażliwa na opóźnienia, zalecamy ustawienie minimalnej liczby instancji i dokończenie inicjalizacji w momencie wczytywania.

Informacje o uruchomieniu „na zimno” i inicjalizacji

Inicjowanie globalne odbywa się w momencie wczytywania. Bez tego pierwsze żądanie musiałoby przeprowadzić inicjalizację i załadować moduły, co wydłużyłoby czas oczekiwania.

Inicjowanie globalne ma jednak również wpływ na uruchomienia „na zimno”. Aby zminimalizować ten wpływ, inicjuj tylko to, co jest potrzebne do pierwszego żądania, aby opóźnienie pierwszego żądania było jak najmniejsze.

Jest to szczególnie ważne, jeśli skonfigurujesz minimalną liczbę instancji zgodnie z opisem powyżej w przypadku funkcji wrażliwej na opóźnienia. W takim przypadku wykonanie inicjalizacji w momencie wczytywania i zapisanie przydatnych danych do pamięci podręcznej sprawia, że pierwsza prośba nie musi być inicjowana i może być obsługiwana z niską latencją.

Jeśli inicjujesz zmienne w zakresie globalnym, w zależności od języka długi czas inicjowania może powodować 2 zachowania: – w przypadku niektórych kombinacji języków i bibliotek asynchronicznych framework funkcji może działać asynchronicznie i zwracać natychmiast, co powoduje, że kod nadal działa w tle, co może powodować problemy, takie jak brak możliwości uzyskania dostępu do procesora. Aby tego uniknąć, należy zablokować inicjalizację modułu, jak opisano poniżej. Dzięki temu żądania nie są też obsługiwane, dopóki nie zakończy się inicjalizacja. – z drugiej strony, jeśli inicjalizacja jest synchroniczna, długi czas inicjalizacji spowoduje dłuższe uruchomienia „na zimno”, co może być problemem, zwłaszcza w przypadku funkcji o niskiej współbieżności podczas skoków obciążenia.

Przykład wstępnego wczytania asynchronicznej biblioteki node.js

Node.js z Firestore to przykład asynchronicznej biblioteki node.js. Aby korzystać z min_instances, kod ten kończy wczytywanie i inicjowanie w momencie wczytywania, blokując wczytywanie modułu.

Używa TLA, co oznacza, że wymagany jest ES6. Możesz użyć rozszerzenia .mjs dla kodu node.js lub dodać type: module do pliku package.json.

{
  "main": "main.js",
  "type": "module",
  "dependencies": {
    "@google-cloud/firestore": "^7.10.0",
    "@google-cloud/functions-framework": "^3.4.5"
  }
}

import Firestore from '@google-cloud/firestore';
import * as functions from '@google-cloud/functions-framework';

const firestore = new Firestore({preferRest: true});

// Pre-warm firestore connection pool, and preload our global config
// document in cache. In order to ensure no other request comes in,
// block the module loading with a synchronous global request:
const config = await firestore.collection('collection').doc('config').get();

functions.http('fetch', (req, res) => {

// Do something with config and firestore client, which are now preloaded
// and will execute at lower latency.
});

Przykłady globalnej inicjalizacji

const functions = require('firebase-functions');
let myCostlyVariable;

exports.function = functions.https.onRequest((req, res) => {
  doUsualWork();
  if(unlikelyCondition()){
      myCostlyVariable = myCostlyVariable || buildCostlyVariable();
  }
  res.status(200).send('OK');
});

from firebase_functions import https_fn

# Always initialized (at cold-start)
non_lazy_global = file_wide_computation()

# Declared at cold-start, but only initialized if/when the function executes
lazy_global = None

@https_fn.on_request()
def lazy_globals(request):

  global lazy_global, non_lazy_global

  # This value is initialized only if (and when) the function is called
  if not lazy_global:
      lazy_global = function_specific_computation()

  return https_fn.Response(f"Lazy: {lazy_global}, non-lazy: {non_lazy_global}.")
  

Jest to szczególnie ważne, jeśli w pojedynczym pliku zdefiniujesz kilka funkcji, a różne funkcje używają różnych zmiennych. Jeśli nie użyjesz leniwej inicjalizacji, możesz marnować zasoby na zmienne, które są inicjowane, ale nigdy nie są używane.

Dodatkowe materiały

Więcej informacji o optymalizacji wydajności znajdziesz w filmie „Google Cloud Performance Atlas” Cloud Functions Czas rozruchu zimnego.