Google Cloud를 사용하여 서버리스 Node.js 기능 구현
게시 됨: 2022-03-11소프트웨어를 만드는 것은 좋은 코드를 작성하는 것으로 끝나지 않습니다. 소프트웨어가 배포되고 요청을 적절하게 처리할 수 있고 성능과 실행 비용을 방해하지 않고 확장할 수 있을 때 완료됩니다.
당신은 아마도 이 모든 것을 처리하기 위해 클라우드 컴퓨팅이 있는 방법에 대해 생각하고 있을 것입니다. "그래서 이 새로운 서버리스 제품은 무엇입니까, Vignes?"
서버리스 컴퓨팅은 하드웨어 및 소프트웨어 설정, 보안, 성능, CPU 유휴 시간 비용에 대해 걱정할 필요가 없는 클라우드 플랫폼에서 코드가 실행되는 아키텍처 스타일입니다. 소프트웨어 환경도 추상화하는 인프라를 넘어 클라우드 컴퓨팅의 발전입니다. 이는 코드를 실행하는 데 구성이 필요하지 않음을 의미합니다.
서버리스를 사용하는 경우 작업 스타일은 다음과 같습니다.
코드를 개발합니다.
서비스 제공업체에 코드를 업로드합니다.
트리거(이 경우 HTTP 요청)를 구성합니다.
우리의 작업이 완료되었습니다! 이제 플랫폼 공급자가 들어오는 요청과 확장을 처리합니다.
서버리스 마이크로서비스 소개
서버리스 아키텍처는 종종 마이크로서비스 스타일 디자인과 결합됩니다. 마이크로서비스는 하나의 특정 모듈에 대한 요청을 처리하는 대형 소프트웨어의 독립 실행형 부분입니다. 서버리스 환경에서 실행할 수 있는 마이크로서비스를 생성하면 코드를 유지 관리하기 쉽고 배포 속도가 빨라집니다.
AWS Lambda 및 GCF, 비교 소개
서버리스 기능은 종종 "서비스로서의 백엔드" 또는 "서비스로서의 기능"이라고 합니다. 서버리스 컴퓨팅 공급자의 수가 증가하기 시작했습니다. 그러나 Amazon Web Services의 AWS Lambda Functions 및 Google Cloud의 Google Cloud Functions (GCF)와 같은 일부 전통적인 대기업은 서버리스 옵션도 제공합니다. 후자는 현재 베타 버전이지만 제가 사용하고 있습니다. 그들은 비슷하게 작동하지만 그들 사이에는 몇 가지 중요한 차이점이 있습니다.
| AWS 람다 | 구글 클라우드 기능 | |
|---|---|---|
| 언어 지원 | Node.js, 파이썬, C#, 자바 | 노드.js |
| 트리거 | DynamoDB, Kinesis, S3, SNS, API 게이트웨이(HTTP), CloudFront 등 | HTTP, Cloud PubSub, Cloud Storage 버킷 |
| 최대 실행 시간 | 300초 | 540초 |
이 기사에서는 GCF를 사용하여 서버리스 코드 배포를 구현하는 프로세스를 살펴보겠습니다. Google Cloud Functions는 서버나 런타임 환경을 관리할 필요 없이 클라우드 이벤트에 응답하는 작은 단일 목적 함수를 만들 수 있는 가벼운 이벤트 기반 비동기 컴퓨팅 솔루션입니다.
GCF에는 트리거를 기반으로 분리된 세 가지 가능한 구현이 있습니다.
HTTP 트리거 HTTP 요청을 클라우드 기능으로 라우팅
내부 Google 게시/구독 트리거 게시 및 구독 요청을 클라우드 기능으로 라우팅
클라우드 스토리지 버킷 트리거 스토리지 버킷에 대한 모든 변경 사항을 클라우드 기능으로 라우팅
Google Cloud Functions를 사용하여 HTTP 트리거 기반 설정을 만들어 보겠습니다.
Google Cloud Functions는 특별한 추가 설정이나 설치가 필요하지 않습니다. GCF는 기본 노드 환경이 설정되고 실행할 준비가 되었는지 확인합니다. HTTP를 트리거로 사용하여 클라우드 함수를 생성하면 함수를 트리거할 URL을 제공합니다. API 게이트웨이를 매개체로 통신하는 AWS Lambda에 비해 Google Cloud Functions는 projectID 및 지역을 기반으로 URL을 즉시 제공합니다.
서버리스 Node.js 애플리케이션 만들기
코드를 GCF에서 실행 가능하게 하려면 코드를 하나의 단일 함수로 래핑해야 합니다. GCF는 트리거가 발생할 때마다 해당 특정 함수를 호출합니다. 이를 수행하는 가능한 방법은 업로드하는 것입니다.
단일 파일: 요청에 따라 다른 함수를 호출하는 기본 함수를 내보냅니다.
여러 파일: 다른 모든 파일이 필요하고 기본 기능을 시작점으로 내보내는
index.js파일이 있습니다.여러 파일:
"main": "main.js"를 시작점으로 사용하여package.json에 하나의 기본 파일을 구성합니다.
위의 모든 방법이 작동합니다.
GCF에는 지원되는 특정 노드 런타임 버전이 있습니다. 코드가 해당 특정 버전을 지원하도록 작성되었는지 확인하십시오. 이 글을 작성하는 시점에서 GCF는 Node 버전 v6.11.1을 지원합니다.
함수를 생성하기 위해 고려해야 할 몇 가지 옵션이 있습니다.
메모리 이것은 한 번의 실행 시간 동안 요청을 처리하는 데 필요한 메모리 양을 알려줍니다. MB 단위로 정의됩니다. 소규모 응용 프로그램의 경우 128MB면 충분하지만 최대 2GB까지 늘릴 수 있습니다.
시간 초과 시간 초과는 이름에서 알 수 있듯이 예상 코드 실행 시간 초과를 정의합니다. 그 후에 코드가 종료되고 중지됩니다. 이 시점 이후의 모든 실행은 갑자기 중지됩니다. 최대 시간 초과는 540초입니다.
실행할 함수 주 핸들러 파일에서 하나 이상의 함수를 내보낼 수 있지만 요청 처리를 위해 트리거되어야 하는 함수를 하나 구성해야 합니다. 이를 통해 개발자는 HTTP 메서드/URL을 기반으로 여러 진입점을 가질 수 있습니다.
코드를 업로드하려면 코드의 복사 붙여넣기를 수행하여 기능 포털을 생성하면 됩니다. 파일이 두 개 이상인 경우 내용을 압축하고 파일을 업로드합니다. ZIP 파일의 경우 index.js 파일이나 package.json 파일 중 하나가 있어야 하며, 메인 파일이 언급되어 있어야 합니다.

모든 NPM 모듈 종속성은 package.json 에 언급되어야 합니다. GCF는 최초 설정 중에 package.json 파일에 언급된 모듈을 설치하려고 시도합니다.
200 상태와 일부 메시지를 반환하는 간단한 핸들러를 만들 수 있습니다. 함수를 만들고 소스에 다음 코드를 추가합니다.
exports.httpServer = function httpServer(req, res) { console.log(req); res.status(200).send('Server is working'); } 함수가 생성되면 제공된 URL을 열어 함수를 트리거합니다. 다음과 같이 응답해야 합니다.
이제 로그의 req 개체를 살펴보겠습니다. 로그를 보기 위해 GCF는 콘솔에서 바로 옵션을 제공합니다. 수직 점을 클릭하고 로그 옵션을 엽니다.
이제 /users 에 대한 간단한 경로를 처리하도록 코드를 업데이트하겠습니다.
다음 코드는 /users 경로에 대한 간단한 GET 및 POST 요청을 처리하는 데 사용됩니다.
exports.httpServer = function httpServer(req, res) { const path = req.path; switch(path) { case '/users': handleUsers(req, res); break; default: res.status(200).send('Server is working'); } }; const handleUsers = (req, res) => { if (req.method === 'GET') { res.status(200).send('Listing users...'); } else if (req.method === 'POST') { res.status(201).send('Creating User...') } else { res.status(404); } } 업데이트 후 이제 브라우저에서 테스트해 보겠습니다. 하지만 이번에는 끝에 /users 를 사용합니다.
멋지네요. 라우팅을 사용하여 기본 HTTP 서버를 만들었습니다.
운영 및 디버깅
코드가 이야기의 끝이었다면 서버리스 Node.js 애플리케이션과 같은 인프라 옵션을 조사하지 않았을 것입니다. 다음은 배포 및 디버깅과 같은 일반적인 작업을 처리하는 방법에 대한 간략한 요약입니다. Node.js 개발자가 이미 다른 애플리케이션에서 하고 있는 일.
전개:
함수용 코드는 4가지 방법으로 배포할 수 있습니다.
콘솔에 코드 복사 붙여넣기
ZIP 파일 업로드
클라우드 스토리지 버킷에서 ZIP 파일로 배포
클라우드 소스 저장소에서 배포
가장 편리한 옵션은 분명히 소스 리포지토리에서 배포하는 것입니다.
기도:
함수를 생성하는 동안 콘솔은 https://<region>-<project-id>.cloudfunctions.net/<function-name> 형식의 함수를 트리거하는 HTTP URL을 제공합니다.
AWS Lambda의 함수에는 함수 실행을 시작하는 데 추가 시간이 소요되는 콜드 스타트 문제가 있습니다. 일단 시작되면 다음 실행이 정상적으로 응답합니다. 이 초기 추가 시작 시간을 콜드 스타트라고 합니다. 이 주제와 관련된 GCF에 대한 공식 문서는 없지만 테스트 중에 콜드 스타트 문제는 나타나지 않았습니다.
디버깅:
GCF는 Google Cloud의 Stackdriver Logging 서비스와 통합됩니다. 모든 콘솔 로그와 오류가 여기에 기록되며 이미 배포된 코드를 디버그하는 데 도움이 됩니다.
테스트:
콘솔은 JSON을 입력으로 전달하여 함수를 테스트하는 옵션을 제공합니다. 함수는 입력으로 JSON을 사용하여 호출되고 출력은 콘솔에 표시됩니다. 요청(입력) 및 응답은 Express.js 프레임워크와 유사하며 개발 프로세스 자체에서 단위 테스트가 가능합니다. Node.js 테스트에 대한 복습이 필요한 경우 실제로 통합 테스트를 수행하기 위한 Node.js 가이드를 확인하세요.
제한 사항 및 다음 단계
서버리스 기능을 사용하면 나름의 장점이 있지만 한계도 있습니다.
공급업체 종속: 우리가 작성하는 코드를 하나의 특정 서비스 제공업체로 제한합니다. 코드를 다른 공급자로 이동하려면 마이그레이션에 상당한 노력을 기울여 코드를 다시 작성해야 합니다. 이는 큰 문제가 될 수 있으므로 서비스 제공업체를 선택할 때 매우 신중해야 합니다.
요청 수 및 하드웨어 리소스 제한: 공급자는 종종 함수가 한 번에 처리할 병렬 요청 수를 제한합니다. 메모리 제한도 있습니다. 이러한 유형의 제한은 공급자에게 문의하여 더 높일 수 있지만 여전히 존재합니다.
Google Cloud Functions는 많이 성숙해지고 개선되고 있습니다. 특히 지원 가능한 언어로 자주 개선되고 업데이트됩니다. GCP 기능을 사용할 계획이라면 변경 로그를 주시하여 구현의 주요 변경 사항을 방지하세요.
Toptal 엔지니어링 블로그에 대한 추가 정보:
- TypeScript 및 Jest 지원 작업: AWS SAM 자습서
