도움말 및 유용한 정보

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

정확성

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

멱등 함수 작성

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

백그라운드 활동 시작 금지

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

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

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

항상 임시 파일 삭제

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

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

임시 디렉터리 외부에 작성하려고 시도해서는 안 되며 플랫폼 또는 OS 독립 메서드를 사용하여 파일 경로를 구성해야 합니다.

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

함수 프레임워크

함수를 배포하면 함수 프레임워크가 현재 버전을 사용하여 종속 항목으로 자동 추가됩니다. 동일한 종속 항목이 다양한 환경에 일관되게 설치되도록 하려면 함수를 특정 버전의 함수 프레임워크로 고정하는 것이 좋습니다.

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

도구

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

로컬 개발

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

Firebase 개발자는 Firebase CLI Cloud Functions 에뮬레이터를 사용할 수 있습니다.

SendGrid를 사용하여 이메일 전송

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

성능

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

현명하게 종속 항목 사용

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

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

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

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

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

Node.js

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}`);
});

Python

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

이 HTTP 함수는 요청 객체(flask.Request)를 가져오고 응답 텍스트 또는 make_response를 사용하여 Response 객체로 변환할 수 있는 값 집합을 반환합니다.

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

전역 변수의 지연 초기화 실행

전역 범위에서 변수를 초기화하는 경우 초기화 코드가 항상 콜드 스타트 호출을 통해 실행되므로 함수의 지연 시간이 증가합니다. 경우에 따라 try/catch 블록에서 서비스가 적절하게 처리되지 않으면 호출되는 서비스에 간헐적인 시간 초과가 발생합니다. 모든 코드 경로에서 사용되지는 않는 객체가 있다면 수요에 맞춰 초기화를 지연하는 것이 좋습니다.

Node.js

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');
});

Python

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

이 HTTP 함수는 지연 초기화된 전역을 사용합니다. 여기서는 요청 객체(flask.Request)를 가져오고 응답 텍스트 또는 make_response를 사용하여 Response 객체로 변환할 수 있는 값 집합을 반환합니다.

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

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

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

이러한 런타임 옵션에 대한 자세한 내용은 확장 동작 제어를 참조하세요.

추가 리소스

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