이 문서에서는 Cloud Functions를 배포하는 중입니다.
정확성
이 섹션에서는 Cloud Functions의 설계 및 구현을 위한 일반적인 권장사항을 설명합니다.
멱등 함수 작성
함수를 여러 번 호출해도 함수에서 동일한 결과가 나와야 합니다. 이렇게 하면 코드 중간에 이전 호출이 실패할 경우 호출을 재시도할 수 있습니다. 자세한 내용은 이벤트 기반 함수 재시도를 참조하세요.
백그라운드 활동 시작 금지
백그라운드 활동이란 함수가 종료된 뒤에 발생하는 모든 활동입니다.
Node.js 이벤트 기반 함수에서 callback
인수를 호출하는 등 함수 반환 또는 신호 완료가 발생하면 함수 호출이 종료됩니다. 단계적 종료 이후에 실행되는 모든 코드는 CPU를 사용할 수 없으므로 진행되지 않습니다.
또한 동일한 환경에서 후속 호출을 실행하면 백그라운드 활동이 다시 시작되어 새 호출을 방해합니다. 이로 인해 예상치 못한 동작 및 진단하기 어려운 오류가 발생할 수 있습니다. 일반적으로 함수가 종료된 후에 네트워크에 액세스하면 연결이 재설정됩니다(ECONNRESET
오류 코드).
개별 호출의 로그에서 호출이 끝났음을 알리는 줄 다음에 로깅된 내용을 찾으면 백그라운드 활동이 종종 감지될 수 있습니다. 특히 콜백 또는 타이머와 같은 비동기 작업이 있으면 백그라운드 활동은 코드에 더 깊이 숨어 있을 수 있습니다. 함수를 종료하기 전에 모든 비동기식 작업이 완료되도록 코드를 검토합니다.
항상 임시 파일 삭제
임시 디렉터리의 로컬 디스크 저장소는 메모리 내의 파일 시스템입니다. 작성한 파일은 함수에 제공되는 메모리를 사용하며 가끔 호출 시 그대로 유지됩니다. 이 파일을 명시적으로 삭제하지 못하면 결국 메모리 부족 오류가 발생한 후 콜드 스타트가 진행될 수 있습니다.
Google Cloud 콘솔의 함수 목록에서 개별 함수를 선택한 후 메모리 사용량 플롯을 선택하면 이 함수에서 사용한 메모리를 확인할 수 있습니다.
임시 디렉터리 외부에 작성하려고 시도해서는 안 되며 플랫폼 또는 OS 독립 메서드를 사용하여 파일 경로를 구성해야 합니다.
파이프라인을 사용하여 큰 파일을 처리하면 메모리 요구사항을 줄일 수 있습니다. 예를 들어 읽기 스트림을 만들고 스트림 기반 프로세스를 통해 이를 전달한 후 Cloud Storage에 출력 스트림을 직접 작성하는 방식으로 Cloud Storage에서 파일을 처리할 수 있습니다.
함수 프레임워크
함수를 배포하면 함수 프레임워크가 현재 버전을 사용하여 종속 항목으로 자동 추가됩니다. 동일한 종속 항목이 다양한 환경에 일관되게 설치되도록 하려면 함수를 특정 버전의 함수 프레임워크로 고정하는 것이 좋습니다.
이렇게 하려면 관련 잠금 파일에 원하는 버전을 포함합니다(예: Node.js의 경우 package-lock.json
, Python의 경우 requirements.txt
).
도구
이 섹션에서는 도구를 사용하여 Google Cloud의 Cloud Functions와 상호작용할 수 있습니다.
로컬 개발
함수 배포에는 시간이 다소 걸리므로 로컬에서 함수 코드를 테스트하는 것이 더 빠를 수 있습니다.
Firebase 개발자는 Firebase CLI Cloud Functions 에뮬레이터.SendGrid를 사용하여 이메일 전송
Cloud Functions는 포트 25에서 아웃바운드 연결을 허용하지 않으므로 SMTP 서버에 비보안 연결을 설정하는 것입니다. 권장되는 전송 방법은 이메일은 SendGrid를 사용하는 것입니다. 다른 옵션을 찾아보실 수 있습니다 Gmail에서 이메일을 인스턴스에서 이메일 전송 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
)를 받아
응답 텍스트 또는
Response
객체 사용
make_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
)를 호출하여 응답 텍스트 또는
Response
객체로 변환할 수 있습니다.
make_response
한 파일에서 여러 함수를 정의하고 여러 함수가 다른 변수를 사용하는 경우에 특히 중요합니다. 지연 초기화를 사용하지 않는다면 초기화만 하고 절대 사용하지 않는 변수에서 리소스를 낭비할 수 있습니다.
최소 인스턴스 수를 설정하여 콜드 스타트 줄이기
기본적으로 Cloud Functions는 다음 기준에 따라 인스턴스 수를 확장합니다. 알 수 있습니다 이 기본 동작은 Cloud Functions에서 준비해야 하는 최소 인스턴스 수 제공할 수 있습니다 최소 인스턴스 수를 설정하면 애플리케이션의 콜드 스타트가 줄어듭니다. 애플리케이션이 지연 시간에 민감하다면 최소 인스턴스 수를 설정하는 것이 좋습니다.
이러한 런타임 옵션에 대한 자세한 내용은 확장 동작 제어를 참조하세요.추가 리소스
성능 최적화에 대한 자세한 내용은 'Google Cloud 성능 Versa 3 동영상 Cloud Functions 콜드 부팅 시간.