이 페이지는 Cloud Translation API를 통해 번역되었습니다.

Node.js 애플리케이션 프로파일링

이 페이지에서는 프로파일링 데이터를 캡처하고 이 데이터를 Google Cloud 프로젝트로 전송하도록 Node.js 애플리케이션을 수정하는 방법을 설명합니다. 프로파일링에 대한 일반 정보는 프로파일링 개념을 참조하세요.

Node.js의 프로필 유형:

힙
실제 경과 시간

지원되는 Node.js 언어 버전:

Node.js 14 이상
Node.js 출시 정책은 출시 일정을 참고하세요.

지원되는 프로파일링 에이전트 버전:

가장 최신 버전의 에이전트가 지원됩니다. 일반적으로 1년이 지난 출시 버전은 지원되지 않습니다. 최근에 출시된 버전의 에이전트를 사용하는 것이 좋습니다.

지원되는 운영체제:

Linux. Node.js 애플리케이션 프로파일링은 표준 C 라이브러리가 glibc 또는 musl로 구현된 Linux 커널에서 지원됩니다. Linux Alpine 커널의 구성 정보는 Linux Alpine에서 실행을 참조하세요.

지원되는 환경:

Compute Engine
Google Kubernetes Engine(GKE)
App Engine 가변형 환경
App Engine 표준 환경
Google Cloud 외부(추가 구성 요구사항에 대한 자세한 내용은 Google Cloud 외부에서 실행되는 애플리케이션 프로파일링 참조)

Profiler API 사용 설정

프로파일링 에이전트를 사용하기 전에 기본 Profiler API가 사용 설정되어 있는지 확인합니다. Google Cloud CLI 또는 Google Cloud Console을 사용하여 API 상태를 확인하고 필요한 경우 사용 설정할 수 있습니다.

gcloud CLI

워크스테이션에 Google Cloud CLI를 아직 설치하지 않은 경우 Google Cloud CLI 문서를 참조하세요.

다음 명령어를 실행합니다.

gcloud services enable cloudprofiler.googleapis.com

자세한 내용은 gcloud services를 참조하세요.

Google Cloud 콘솔

Enable the required API.
Enable the API
API 사용 설정됨이 표시되어 있으면 API가 이미 사용 설정된 것입니다. 그렇지 않으면 사용 설정 버튼을 클릭합니다.

서비스 계정에 IAM 역할 부여

Google Cloud 리소스에 애플리케이션을 배포하고 있으며 기본 서비스 계정을 사용하고 있고 해당 서비스 계정에 대한 역할 부여를 수정하지 않은 경우 이 섹션을 건너뛰어도 됩니다.

다음 중 하나를 실행하는 경우 서비스 계정에 Cloud Profiler Agent (roles/cloudprofiler.agent)의 IAM 역할을 부여해야 합니다.

기본 서비스 계정을 사용하고 있지만 역할 부여를 수정한 경우
사용자가 만든 서비스 계정을 사용하고 있습니다.
워크로드 아이덴티티를 사용하는 경우 Kubernetes 서비스 계정에 Cloud Profiler 에이전트 역할을 부여합니다.

Google Cloud 콘솔 또는 Google Cloud CLI를 사용하여 서비스 계정에 IAM 역할을 부여할 수 있습니다. 예를 들어 gcloud projects add-iam-policy-binding 명령어를 사용할 수 있습니다.

gcloud projects add-iam-policy-binding GCP_PROJECT_ID \
    --member serviceAccount:MY_SVC_ACCT_ID@GCP_PROJECT_ID.iam.gserviceaccount.com \
    --role roles/cloudprofiler.agent

이전 명령어를 사용하기 전에 다음을 바꿉니다.

GCP_PROJECT_ID: 프로젝트 ID입니다.
MY_SVC_ACCT_ID: 서비스 계정의 이름입니다.

자세한 내용은 프로젝트, 폴더, 조직에 대한 액세스 관리를 참고하세요.

Cloud Profiler 사용

지원되는 모든 환경에서 @google-cloud/profiler 패키지를 설치하고 애플리케이션에 require 문을 추가한 후 일반적인 방법으로 애플리케이션을 배포하여 Profiler를 사용합니다.

`@google-cloud/profiler`를 설치하기 전에

@google-cloud/profiler 패키지는 내장 모듈에 종속됩니다. 이 내장 모듈을 위해 사전 빌드된 바이너리는 Node 14/16용 Linux 및 Alpine Linux에서 사용할 수 있습니다. 추가 종속 항목은 필요하지 않습니다. @google-cloud/profiler는 node-pre-gyp를 사용하여 설치할 사전 빌드된 바이너리를 결정합니다.

사전 빌드된 바이너리가 없는 다른 환경에서 @google-cloud/profiler를 사용하는 경우 모듈 node-gyp가 바이너리를 빌드하는 데 사용됩니다. node-gyp로 바이너리를 빌드하는 데 필요한 종속 항목에 관한 자세한 내용은 node-gyp 설치 문서를 참고하세요.

설치

Cloud Profiler의 최신 버전을 설치하려면 다음을 수행합니다.

    npm install --save @google-cloud/profiler

Trace 에이전트도 사용하는 경우 애플리케이션을 수정할 때 Trace 에이전트 패키지(@google-cloud/trace-agent) 다음에 Profiler 패키지를 가져옵니다.

Compute Engine

Compute Engine에서 다음을 수행합니다.

Cloud Profiler의 최신 버전을 설치합니다.
```
npm install --save @google-cloud/profiler
```
애플리케이션 require 코드를 수정하여 프로파일링할 서비스의 이름을 service에 할당하는 serviceContext 객체를 만듭니다. 원하는 경우 프로파일링할 서비스 버전을 version에 할당할 수 있습니다. 이러한 구성 옵션에 대한 자세한 내용은 서비스 이름 및 버전 인수를 참조하세요.
```
require('@google-cloud/profiler').start({
  serviceContext: {
    service: 'your-service',
    version: '1.0.0',
  },
});
```

GKE

GKE에서 다음을 수행합니다.

Dockerfile을 수정하여 Profiler 패키지를 설치합니다.
```
FROM node:10
...
RUN npm install @google-cloud/profiler
```
애플리케이션 require 코드를 수정하여 프로파일링할 서비스의 이름을 service에 할당하는 serviceContext 객체를 만듭니다. 원하는 경우 프로파일링할 서비스 버전을 version에 할당할 수 있습니다. 이러한 구성 옵션에 대한 자세한 내용은 서비스 이름 및 버전 인수를 참조하세요.
```
require('@google-cloud/profiler').start({
  serviceContext: {
    service: 'your-service',
    version: '1.0.0',
  },
});
```

App Engine

App Engine 가변형 환경과 App Engine 표준 환경에서 require 코드는 다음과 비슷합니다.

require('@google-cloud/profiler').start();

App Engine에서는 service 매개변수와 version 매개변수가 환경에서 파생되므로 이러한 매개변수를 지정할 필요가 없습니다. 따라서 serviceContext 객체를 만들 필요가 없습니다.

데이터 분석

Profiler가 데이터를 수집하면 개발자가 Profiler 인터페이스를 사용하여 이 데이터를 보고 분석할 수 있습니다.

Google Cloud 콘솔에서 Profiler 페이지로 이동합니다.

Profiler로 이동

검색창을 사용하여 이 페이지를 찾을 수도 있습니다.

서비스 이름 및 버전 인수

Profiler 에이전트를 로드할 때는 서비스 이름 인수와 선택적 서비스 버전 인수를 지정하여 구성합니다.

서비스 이름은 Profiler가 해당 서비스의 모든 복제본에 대한 프로파일링 데이터를 수집할 수 있게 해줍니다. 프로파일러 서비스는 각 서비스 버전 및 영역(zone)의 조합에서 각 서비스 이름에 평균적으로 프로필이 1분에 하나씩 수집되도록 보장합니다.

예를 들어 두 버전이 3개 영역(zone)의 복제본에서 실행 중인 서비스가 있다면 프로파일러가 해당 서비스에 대한 프로필을 평균적으로 1분에 6개씩 만듭니다.

복제본에 서로 다른 서비스 이름을 사용하면 서비스가 불필요하게 자주 프로파일링되므로 오버헤드도 높아집니다.

서비스 이름을 선택할 때 다음에 유의하세요.

애플리케이션 아키텍처에서 서비스를 분명히 나타내는 이름을 선택합니다. 단일 서비스 또는 애플리케이션만 실행하는 경우에는 서비스 이름 선택이 크게 중요하지 않습니다. 하지만 애플리케이션이 마이크로 서비스 집합으로 실행되는 경우와 같은 사례에서는 서비스 이름 선택이 중요합니다.
서비스 이름 문자열에 프로세스 ID와 같은 프로세스 관련 값을 사용하지 않도록 합니다.
서비스 이름 문자열은 다음과 같은 정규 표현식과 일치해야 합니다.

^[a-z0-9]([-a-z0-9_.]{0,253}[a-z0-9])?$

imageproc-service와 같은 정적 문자열을 서비스 이름으로 사용하는 것이 좋습니다.

서비스 버전은 선택사항입니다. 서비스 버전을 지정하면 Profiler가 여러 인스턴스의 프로파일링 정보를 집계하여 올바르게 표시할 수 있습니다. 배포된 서비스의 여러 버전을 표시할 때 서비스 버전을 사용할 수 있습니다. Profiler UI를 사용하면 서비스 버전별로 데이터를 필터링할 수 있습니다. 그러면 이전 버전과 새로운 버전의 코드 성능을 비교할 수 있습니다.

서비스 버전 인수 값은 자유 형식 문자열이지만 이 인수 값은 일반적으로 버전 번호와 유사합니다(예: 1.0.0 또는 2.1.2).

에이전트 로깅

프로파일링 에이전트는 로깅 정보를 보고할 수 있습니다. 로깅을 사용 설정하려면 에이전트를 시작할 때 logLevel 옵션을 설정합니다. 지원되는 logLevel 값은 다음과 같습니다.

0: 모든 에이전트 로깅을 중지합니다.
1: 오류 로깅을 사용 설정합니다.
2: 경고 로깅을 사용 설정합니다(기본값)
3: 정보 로깅을 사용 설정합니다.
4: 디버그 로깅을 사용 설정합니다.

서비스 컨텍스트를 제공하는 동일한 객체에서 logLevel 값을 설정합니다.

require('@google-cloud/profiler').start({
    serviceContext: { ... }
    logLevel:       3
});

Linux Alpine으로 실행

Linux Alpine용 Node.js 프로파일링 에이전트는 Google Kubernetes Engine 구성에서만 지원됩니다.

빌드 오류

npm install을 실행하고 다음 오류와 함께 빌드가 실패할 경우 Dockerfile에 일부 빌드 종속 항목이 없는 것입니다.

ERR! stack Error: not found: make

이 문제를 해결하려면 Dockerfile의 빌드 단계에 다음 문을 추가합니다.

RUN apk add python3 g++ make

인증 오류

Linux Alpine(예: golang:alpine 또는 alpine)으로 실행되는 Docker 이미지를 사용하면 다음 인증 오류가 표시될 수 있습니다.

connection error: desc = "transport: authentication handshake failed: x509: failed to load system roots and no roots provided"

이 오류를 확인하려면 에이전트 로깅을 사용 설정해야 합니다.

이 오류는 Linux Alpine을 사용하는 Docker 이미지에 루트 SSL 인증서가 기본적으로 설치되어 있지 않음을 나타냅니다. 이러한 인증서는 프로파일링 에이전트가 Profiler API와 통신하는 데 필요합니다. 이 오류를 해결하려면 Dockerfile에 다음 apk 명령어를 추가합니다.

FROM alpine
...
RUN apk add --no-cache ca-certificates

그런 다음 애플리케이션을 다시 빌드하고 다시 배포해야 합니다.

알려진 문제

Node.js용 프로파일링 에이전트는 프로그램의 정상 종료를 방해합니다. 따라서 프로그램의 모든 태스크가 완료된 후 프로그램이 종료되기까지 최대 1시간이 소요될 수 있습니다. 예를 들어 Ctrl-C를 사용하여 SIGINT를 발행하면 프로세스가 정상적으로 종료됩니다.