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

Cloud Run을 사용하여 서버 측 태그 지정 설정

이 가이드에서는 다음 작업을 실행하는 방법을 설명합니다.

미리보기 서버를 프로비저닝하여 컨테이너에 미리보기 기능 사용 설정
실시간 트래픽을 처리할 수 있도록 태그 관리 서버 프로비저닝
Google 태그 관리자 컨테이너를 실행하는 서버 수 늘리기 또는 줄이기
서버를 프로비저닝한 후 태그 관리 서버 버전을 최신 상태로 유지

기본 요건

GCP 계정이 필요합니다. 계정이 없으면 새 GCP 계정을 만드세요.
GCP 결제 계정이 필요합니다. 계정이 없으면 GCP 결제 계정을 만드세요 (결제 계정 생성자 역할 필요).
프로젝트 생성자 및 결제 계정 사용자 역할이 필요합니다. 역할 추가에 대해 자세히 알아보세요.

미리보기 및 태그 관리 서버 프로비저닝

Cloud Run 서비스는 Google 태그 관리자에서 자동으로 프로비저닝하거나 Google Cloud에서 수동으로 프로비저닝할 수 있습니다.

서비스 구성 수정

서비스 구성을 변경하는 방법은 다음과 같습니다.

Cloud Run을 엽니다.
조정해야 하는 서비스를 선택합니다.
새 버전 수정 및 배포를 클릭합니다.
변경한 후 배포를 클릭합니다.

Cloud Run 비용

이 Cloud Run 구성에서 각 서버의 비용은 미화 약 45달러/월입니다. 각 서버는 CPU가 항상 할당된 가격 책정 모델을 사용하는 vCPU가 1개이고 메모리가 0.5GB인 Cloud Run 인스턴스입니다.

서버가 중단될 경우 발생 가능한 데이터 손실의 위험을 줄이기 위해 적어도 2개의 인스턴스를 실행하는 것이 좋습니다. 하지만 서버를 더 많이, 또는 더 적게 실행해도 됩니다. 2~10대의 서버를 자동 확장하면 초당 35~350개의 요청을 처리할 것으로 예상되지만 태그 수와 태그의 역할에 따라 성능이 달라집니다.

Cloud Run은 부하에 따라 동적으로 확장됩니다. max-instances 설정은 지불해야 하는 리소스 비용을 가장 크게 잡은 경우를 상정합니다. Cloud Run은 필요하지 않은 경우 그렇게 많은 인스턴스를 프로비저닝하지 않습니다.

Cloud Run 계산기

선택사항: App Engine에서 마이그레이션

이전에 App Engine 배포를 만들었고 더 이상 트래픽이 수신되지 않는 것이 확인된 경우 예상치 못한 청구 요금이 발생하지 않도록 App Engine 애플리케이션을 사용 중지하세요.

선택사항: 멀티 리전 배포

웹사이트가 전 세계에 존재하거나 서비스에 중복성을 구축하려는 경우 태그 관리 서버를 여러 리전에 배포합니다.

시작하기 전 참고 사항

부하 분산기를 만듭니다.
선택한 BACKEND_NAME을 기록해 둡니다.

배포에 더 많은 리전을 추가하는 방법은 다음과 같습니다.

REGION을 미리보기 서버가 배포된 리전으로 바꿉니다. 명령줄 옵션에 따라 미리보기 및 태그 관리 서버를 프로비저닝한 경우 이미 채워져 있을 수 있습니다.
CONTAINER_CONFIG를 태그 관리자의 컨테이너 구성 문자열로 바꿉니다. 명령줄 옵션에 따라 미리보기 및 태그 관리 서버를 프로비저닝한 경우 이미 채워져 있을 수 있습니다.
NEW_REGION을 태그 관리 서버를 배포할 새 리전으로 바꿉니다.
BACKEND_NAME을 부하 분산기를 프로비저닝하는 동안 선택한 이름으로 바꿉니다.
선택사항: 다른 리전을 추가하려면 NEW_REGION 변수를 대체하고 코드 스니펫을 다시 실행합니다.

    gcloud run deploy "server-side-tagging" \
    --region NEW_REGION \
    --image gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable \
    --platform managed \
    --ingress all \
    --min-instances 2 \
    --max-instances 10 \
    --timeout 60 \
    --allow-unauthenticated \
    --no-cpu-throttling \
    --update-env-vars PREVIEW_SERVER_URL="$(
      gcloud run services describe server-side-tagging-preview \--region "REGION" \
      --format="value(status.url)")",CONTAINER_CONFIG="CONTAINER_CONFIG" && \

    gcloud compute network-endpoint-groups create server-side-tagging-neg \
    --region=NEW_REGION \
    --network-endpoint-type=SERVERLESS \
    --cloud-run-service="server-side-tagging" && \

    gcloud compute backend-services add-backend --global "BACKEND_NAME" \
    --network-endpoint-group-region=NEW_REGION \
    --network-endpoint-group=server-side-tagging-neg

선택사항: 로깅 사용 중지

요청 로깅

기본적으로 모든 단일 요청에 대한 정보(예: 요청 경로, 쿼리 매개변수)가 로깅됩니다. 태그 관리 서버가 매월 수많은 요청을 처리하는 경우(예: 100만 개 이상) 이러한 로그 메시지로 인해 높은 로깅 요금이 발생할 수 있습니다. 로깅 요금을 줄이거나 없애려면 요청 로깅을 사용 중지하는 것이 좋습니다.

요청 로깅을 사용 중지하는 방법은 다음과 같습니다.

Google Cloud Platform에서 로그 라우터를 엽니다. 컨테이너 ID와 일치하는 프로젝트에 있는지 확인합니다.
유형: Cloud Logging 버킷, 이름: _Default 줄에서 더보기 메뉴를 선택한 후 싱크 수정을 클릭합니다.
싱크 대상에서 로그 버킷 _Default를 선택합니다.
싱크에 포함할 로그 선택에서 새 줄을 추가합니다. 다음 규칙을 기존 포함 필터에 입력합니다.
```
NOT LOG_ID("run.googleapis.com/requests")
```
부하 분산기에서도 로깅을 사용 중지하기 위해 새 줄을 추가하고 다음 규칙을 기존 포함 필터에 입력합니다.
```
NOT LOG_ID("requests")
```
참고: 이렇게 하면 서버 컨테이너로 전송되지 않는 요청을 포함하여 부하 분산기의 모든 로깅이 사용 중지됩니다.
싱크를 업데이트하여 변경사항을 적용합니다. 이제 요청이 로깅에서 제외됩니다.
로그 탐색기 로그에 새로운 요청이 표시되지 않는지 확인합니다.

콘솔 로깅

컨테이너의 태그 관리 서버, 클라이언트 또는 태그는 메시지를 콘솔에 로깅할 수 있으며 이로 인해 로깅 요금이 발생할 수 있습니다. 로깅 요금을 줄이거나 없애려면 원치 않는 콘솔 로그 메시지를 사용 중지하세요.

원치 않는 콘솔 로그 파악하기:

GCP에서 로그 탐색기를 엽니다.
태그에서 발생한 원치 않는 로그 메시지를 찾습니다. 예를 들면 다음과 같습니다.

태그는 다음 로그를 보낼 수 있습니다.
```
const logToConsole = require('logToConsole');

logToConsole('Custom message: ' + data.param1);
logToConsole('An important message to keep around!');
data.gtmOnSuccess()
```
textPayload 필드에서 해당 로그 메시지를 찾습니다.

콘솔 로그 메시지를 사용 중지하는 방법:

Google Cloud Platform에서 로그 라우터를 엽니다. 컨테이너 ID와 일치하는 프로젝트에 있는지 확인합니다.
유형: Cloud Logging 버킷, 이름: _Default 줄에서 더보기 메뉴를 선택한 후 싱크 수정을 클릭합니다.
싱크 대상에서 로그 버킷 _Default를 선택합니다.
싱크에 포함할 로그 선택에서 새 줄을 추가합니다. 다음 규칙을 기존 포함 필터에 입력합니다.
```
NOT textPayload:"Custom message:"
```
콘솔 로그의 경우 Custom message: 텍스트를 사용 중지하려는 콘솔 로그의 하위 스트링으로 대체합니다. 더 정교한 필터의 경우 로깅 쿼리 언어를 활용합니다.
싱크를 업데이트하여 변경사항을 적용합니다. 일치하는 logToConsole 메시지는 로깅에서 제외되어야 합니다.
로그 탐색기에 새로운 콘솔 로그 메시지가 표시되지 않는지 확인합니다.

2. 커스텀 도메인에 배포 매핑

커스텀 도메인을 설정하려면 전역 외부 애플리케이션 부하 분산기를 사용합니다.

3. Google 태그 관리자에 서버 URL 추가

이제 서버가 있으므로 Google 태그 관리자에 서버를 사용해야 한다고 알려야 합니다.

Google 태그 관리자를 엽니다.
태그 관리 서버를 가리키도록 할 서버 컨테이너를 클릭합니다.
관리 탭 > 컨테이너 설정에서 서버 컨테이너 설정을 엽니다.
URL 추가를 클릭하고 서버 URL을 붙여넣습니다.
저장 후 작업공간으로 돌아갑니다.

4. 유효성 검사

이제 태그 관리 서버를 설정했으므로 의도한 대로 작동하는지 확인합니다. 태그 관리자 작업공간에서 미리보기 버튼을 클릭합니다. 미리보기 페이지가 로드되면 모든 항목이 올바르게 설정된 것입니다.

여러 URL 미리보기

여러 도메인을 단일 태그 관리 서버에 매핑한 경우 각 URL이 컨테이너 설정에 추가되는지 확인하세요.

여러 URL을 제공한 경우 모든 경로(도메인 이름 뒤의 문자열)가 일치해야 합니다.

작동함	작동하지 않음
URL 1: `example.com/abc` URL 2: `example2.com/abc`	URL 1: `example.com/abc` URL 2: `example2.com/def`

여러 URL이 추가된 경우 미리보기 버튼 옆에 미리 볼 URL을 선택할 수 있는 아이콘이 표시됩니다.

태그 관리 서버 버전 업데이트

새로운 태그 관리 서버 업데이트에는 보안 취약점 수정사항 및 새로운 기능이 포함되어 있습니다. 태그 관리자에 업데이트하라는 메시지가 표시되면 최소한 메이저 버전 출시마다 태그 관리 서버를 업데이트하는 것이 좋습니다(예: 버전 1.x.x에서 2.x.x로 업그레이드).

태그 관리 서버를 업데이트하려면 이전에 사용한 것과 동일한 설정을 사용하여 새 버전을 배포하세요.

Cloud Run을 엽니다.
업데이트하려는 서비스를 선택합니다.
새 버전 수정 및 배포를 클릭합니다.
컨테이너 이미지 URL이 gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable로 설정되어 있는지 확인하고 배포를 클릭합니다.

업데이트가 성공했는지 확인하는 방법은 다음과 같습니다.

서버 컨테이너에서 미리보기 버튼을 클릭하여 새 디버그 세션을 시작하고 별도의 탭에서 요청을 보냅니다.
요약에서 콘솔 탭을 선택하고 태그 관리 서버를 업데이트하라는 메시지가 없는지 확인합니다.

서버가 성공적으로 업데이트된 후에도 최대 하루 동안 태그 관리 서버를 업데이트하라는 메시지가 표시될 수 있습니다. 그러나 미리보기 페이지에는 태그 관리 서버 버전에 대한 최신 메시지가 표시됩니다.