도움말 및 유용한 정보

이 문서에서는 Cloud Functions의 설계, 구현, 테스트, 배포를 위한 권장사항을 설명합니다.

정확성

이 섹션에서는 Cloud Functions의 설계 및 구현을 위한 일반적인 권장사항을 설명합니다.

멱등 함수 작성

함수를 여러 번 호출해도 함수에서 동일한 결과가 나와야 합니다. 이렇게 하면 코드 중간에 이전 호출이 실패할 경우 호출을 재시도할 수 있습니다. 자세한 내용은 이벤트 기반 함수 재시도를 참조하세요.

백그라운드 활동 시작 금지

백그라운드 활동이란 함수가 종료된 뒤에 발생하는 모든 활동입니다. Node.js 이벤트 기반 함수에서 callback 인수를 호출하는 등 함수 반환 또는 신호 완료가 발생하면 함수 호출이 종료됩니다. 단계적 종료 이후에 실행되는 모든 코드는 CPU를 사용할 수 없으므로 진행되지 않습니다.

또한 동일한 환경에서 후속 호출을 실행하면 백그라운드 활동이 다시 시작되어 새 호출을 방해합니다. 이로 인해 예상치 못한 동작 및 진단하기 어려운 오류가 발생할 수 있습니다. 일반적으로 함수가 종료된 후에 네트워크에 액세스하면 연결이 재설정됩니다(ECONNRESET 오류 코드).

개별 호출의 로그에서 호출이 끝났음을 알리는 줄 다음에 로깅된 내용을 찾으면 백그라운드 활동이 종종 감지될 수 있습니다. 특히 콜백 또는 타이머와 같은 비동기 작업이 있으면 백그라운드 활동은 코드에 더 깊이 숨어 있을 수 있습니다. 함수를 종료하기 전에 모든 비동기식 작업이 완료되도록 코드를 검토합니다.

항상 임시 파일 삭제

임시 디렉터리의 로컬 디스크 저장소는 메모리 내의 파일 시스템입니다. 작성한 파일은 함수에 제공되는 메모리를 사용하며 가끔 호출 시 그대로 유지됩니다. 이 파일을 명시적으로 삭제하지 못하면 결국 메모리 부족 오류가 발생한 후 콜드 스타트가 진행될 수 있습니다.

Google Cloud 콘솔의 함수 목록에서 개별 함수를 선택한 후 메모리 사용량 플롯을 선택하면 이 함수에서 사용한 메모리를 확인할 수 있습니다.

장기 스토리지에 액세스해야 하는 경우 Cloud Storage 또는 NFS 볼륨과 함께 Cloud Run 볼륨 마운트를 사용하는 것이 좋습니다.

파이프라인을 사용하여 큰 파일을 처리하면 메모리 요구사항을 줄일 수 있습니다. 예를 들어 읽기 스트림을 만들고 스트림 기반 프로세스를 통해 이를 전달한 후 Cloud Storage에 출력 스트림을 직접 작성하는 방식으로 Cloud Storage에서 파일을 처리할 수 있습니다.

함수 프레임워크

동일한 종속 항목이 여러 환경에 일관되게 설치되도록 하려면 패키지 관리자에 함수 프레임워크 라이브러리를 포함하고 종속 항목을 특정 버전의 함수 프레임워크로 고정하는 것이 좋습니다.

이렇게 하려면 관련 잠금 파일에 원하는 버전을 포함합니다(예: Node.js의 경우 package-lock.json, Python의 경우 requirements.txt).

함수 프레임워크가 종속 항목으로 명시적으로 나열되지 않은 경우 사용 가능한 최신 버전을 사용하여 빌드 프로세스 중에 자동으로 추가됩니다.

도구

이 섹션에서는 도구를 사용하여 Cloud Functions를 구현, 테스트, 상호작용하는 방법을 설명합니다.

로컬 개발

함수 배포에는 시간이 다소 걸리므로 로컬에서 함수 코드를 테스트하는 것이 더 빠를 수 있습니다.

SendGrid를 사용하여 이메일 전송

Cloud Functions는 25번 포트의 발신 연결을 허용하지 않으므로 SMTP 서버에 비보안 방식으로 연결할 수 없습니다. 이메일 전송에 권장되는 방법은 SendGrid와 같은 서드 파티 서비스를 사용하는 것입니다. 기타 이메일 전송 관련 옵션은 Google Compute Engine의 인스턴스에서 이메일 전송 튜토리얼을 참조하세요.

성능

이 섹션에서는 성능 최적화를 위한 권장사항을 설명합니다.

낮은 동시 실행 방지

콜드 스타트는 비용이 많이 들기 때문에 급증하는 동안 최근에 시작한 인스턴스를 재사용할 수 있으면 부하를 처리하는 데 큰 도움이 됩니다. 동시 실행을 제한하면 기존 인스턴스를 활용하는 방식이 제한되므로 콜드 스타트가 더 많이 발생합니다.

현명하게 종속 항목 사용

함수는 스테이트리스(Stateless) 방식이므로 실행 환경이 종종 처음부터 초기화되는 경우가 있는데 이러한 과정을 콜드 스타트라고 합니다. 콜드 스타트가 발생하면 함수의 전역 컨텍스트가 평가됩니다.

함수가 모듈을 가져오면 완전 시작 중 해당 모듈의 로드 시간이 호출 지연 시간에 추가될 수 있습니다. 함수가 사용하지 않는 종속 항목을 로드하지 않고 올바른 종속 항목을 로드하면 함수를 배포하는 데 필요한 시간은 물론 지연 시간도 줄일 수 있습니다.

전역 변수를 사용하여 이후 호출에서 객체 재사용

다음 호출에 대비해 함수의 상태가 유지된다는 보장은 없습니다. 하지만 Cloud Functions는 종종 이전 호출의 실행 환경을 재활용합니다. 전역 범위에서 변수를 선언하면 다시 연산할 필요 없이 후속 호출에서 변수 값을 재사용합니다.

이 방식을 사용하면 함수를 호출할 때마다 다시 만드는 데 비용이 많이 들 수 있는 객체를 캐싱할 수 있습니다. 이러한 객체를 함수 본문에서 전역 범위로 이동하면 성능이 매우 크게 향상될 수 있습니다. 다음 예에서는 리소스 사용량이 많은 객체를 함수 인스턴스당 한 번만 만든 후 특정 인스턴스에 도달하는 모든 함수 호출에서 공유합니다.

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}")
  

전역 범위에서 네트워크 연결, 라이브러리 참조, API 클라이언트 객체를 캐싱하는 것이 특히 중요합니다. 네트워킹 최적화에서 예시를 확인하세요.

최소 인스턴스 수를 설정하여 콜드 스타트 줄이기

기본적으로 Cloud Functions는 수신 요청 수를 기준으로 인스턴스 수를 확장합니다. Cloud Functions 요청 처리를 위해 준비할 최소 인스턴스 수를 지정하여 이러한 기본 동작을 변경할 수 있습니다. 최소 인스턴스 수를 설정하면 애플리케이션의 콜드 스타트가 줄어듭니다. 애플리케이션이 지연 시간에 민감한 경우 최소 인스턴스 수를 설정하고 로드 시 초기화를 완료하는 것이 좋습니다.

콜드 스타트 및 초기화에 대한 참고사항

전역 초기화는 로드 시 실행됩니다. 이 속성이 없으면 첫 번째 요청에서 초기화를 완료하고 모듈을 로드해야 하므로 지연 시간이 더 길어집니다.

그러나 전역 초기화는 콜드 스타트에도 영향을 미칩니다. 이 영향을 최소화하려면 첫 번째 요청에 필요한 것만 초기화하여 첫 번째 요청의 지연 시간을 최대한 짧게 유지합니다.

이는 지연 시간에 민감한 함수에 대해 위에 설명된 대로 최소 인스턴스를 구성한 경우 특히 중요합니다. 이 시나리오에서 로드 시 초기화를 완료하고 유용한 데이터를 캐싱하면 첫 번째 요청에서 초기화를 수행할 필요가 없으며 지연 시간이 짧아집니다.

전역 범위에서 변수를 초기화하는 경우 언어에 따라 초기화 시간이 길면 다음 두 가지 동작이 발생할 수 있습니다. - 일부 언어 및 비동기 라이브러리 조합의 경우 함수 프레임워크가 비동기식으로 실행되고 즉시 반환될 수 있으므로 코드가 백그라운드에서 계속 실행되어 CPU에 액세스할 수 없음과 같은 문제가 발생할 수 있습니다. 이를 방지하려면 아래 설명된 대로 모듈 초기화 시 차단해야 합니다. 이렇게 하면 초기화가 완료될 때까지 요청이 제공되지 않습니다. - 반면에 초기화가 동기식인 경우 초기화 시간이 길면 콜드 스타트가 더 오래 걸리게 되며, 이는 특히 부하가 급증하는 동안 동시 실행 수가 적은 함수에서 문제가 될 수 있습니다.

비동기 node.js 라이브러리를 사전 준비하는 예

Firestore를 사용하는 Node.js는 비동기 Node.js 라이브러리의 예입니다. min_instances를 활용하기 위해 다음 코드는 로드 시 로드 및 초기화를 완료하여 모듈 로드를 차단합니다.

TLA가 사용됩니다. 즉, ES6가 필요하며 node.js 코드에 .mjs 확장자를 사용하거나 package.json 파일에 type: module을 추가해야 합니다.

{
  "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.
});

전역 초기화의 예

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}.")
  

한 파일에서 여러 함수를 정의하고 여러 함수가 다른 변수를 사용하는 경우에 특히 중요합니다. 지연 초기화를 사용하지 않는다면 초기화만 하고 절대 사용하지 않는 변수에서 리소스를 낭비할 수 있습니다.

추가 리소스

'Google Cloud Performance Atlas' 동영상 Cloud Functions Cloud Functions 콜드 부팅 시간을 시청하여 성능 최적화에 대해 자세히 알아보세요.