App Engine을 사용하여 서버 측 태그 지정 설정

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

Google Cloud Platform(GCP) App Engine에서 태그 관리 서버 프로비저닝
실시간 트래픽을 처리할 수 있도록 태그 관리 서버 업그레이드
Google 태그 관리자 컨테이너를 실행하는 서버 수 늘리기 또는 줄이기
서버를 프로비저닝한 후 태그 관리 서버 버전을 최신 상태로 유지

기본 요건

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

1. 서버 프로비저닝

App Engine 인스턴스에서 태그 관리 서버를 새로 생성하려면 다음을 완료해야 합니다.

태그 관리자에서 새 서버 컨테이너를 만듭니다.
새 Google Cloud 프로젝트(GCP)를 만듭니다.
새 App Engine 태그 관리 서버를 프로비저닝합니다.
새 태그 관리 서버의 URL을 태그 관리자 서버 컨테이너에 추가합니다.

Google 태그 관리자 서버 컨테이너 만들기

Google 태그 관리자를 엽니다.
계정 행에서 더보기 메뉴 > 컨테이너 만들기를 클릭합니다.
새 서버 컨테이너를 만듭니다.
'태그 관리 서버 수동 프로비저닝' 라디오 버튼을 클릭합니다. 컨테이너 구성을 기록해 둡니다. 컨테이너 구성은 서버를 프로비저닝하는 데 필요합니다.

새 GCP 프로젝트 만들기

태그 관리 서버를 위한 새 GCP 프로젝트를 만드는 방법은 다음과 같습니다.

Google Cloud 콘솔을 엽니다.
새 GCP 프로젝트를 만듭니다.
프로젝트 이름을 지정합니다. 편의를 위해 컨테이너 ID를 사용하는 것이 좋습니다. 이 이름은 GCP 내에서만 사용됩니다.
태그 관리 서버를 만들기 위해 필요하므로 GCP 프로젝트 ID를 기록해 둡니다.

새 태그 관리 서버 프로비저닝

태그 관리 서버를 만드는 방법은 다음과 같습니다.

Cloud Shell을 엽니다.
Cloud Shell에서 GCP 프로젝트를 설정합니다. 다음과 같이 project ID를 앞에서 기록한 GCP 프로젝트 ID로 바꿉니다.
```
gcloud config set project project ID
```
셸 스크립트에 따라 태그 관리 서버를 만듭니다. 배포 유형을 testing으로 설정합니다.

팁: 메시지에 무엇을 입력해야 할지 잘 모르겠다면 ?를 입력하여 도움을 받으세요.
```
bash -c "$(curl -fsSL https://googletagmanager.com/static/serverjs/setup.sh)"
```

태그 관리자에 태그 관리 서버 URL 추가

Google 태그 관리자를 엽니다.
관리 > 컨테이너 설정에서 URL 추가를 클릭합니다. 서버의 URL을 모르면 Cloud Shell에서 다음 명령어를 실행하세요.
```
gcloud app browse
```
결과: 태그 관리 서버를 설정하고 testing 구성으로 프로비저닝했습니다. 이제 서버 측 태그 지정을 테스트할 수 있습니다.

초기 서버 구성(`testing`)

테스트 구성은 소량의 테스트 트래픽을 보내서 태그 관리자의 미리보기 기능을 사용하여 제품을 살펴보는 데 적합합니다. 이 구성은 표준 환경의 App Engine F1 인스턴스 클래스이며 대부분의 경우 비용이 발생하지 않습니다.

2. 프로덕션에서 App Engine 사용

production 구성에서는 매월 서버별로 약 40달러(USD)가 청구됩니다. 각 서버는 가변형 환경에서 vCPU 1개, 0.5GB 메모리, 10GB 디스크를 갖춘 App Engine 인스턴스입니다.

App Engine 결제와 더불어 결제 관련 알림을 구성하는 방법을 파악하려면 App Engine 비용 관리를 참고하세요. 결제 관련 알림을 설정하는 것이 좋습니다.

권장되는 프로덕션 설정

서버가 중단될 경우 발생 가능한 데이터 손실의 위험을 줄이기 위해 적어도 3개의 서버를 실행하는 것이 좋습니다. 하지만 서버를 더 많이, 또는 더 적게 실행해도 됩니다. 3~6개의 자동 확장 서버(기본값)가 초당 50~200개의 요청을 처리할 것으로 예상됩니다. 성능은 태그 수와 태그의 역할에 따라 달라집니다.

태그 관리 서버를 구성하는 방법은 다음과 같습니다.

Google Cloud Platform Cloud Shell을 엽니다.
Cloud Shell에서 Cloud Platform 프로젝트를 설정합니다. 다음과 같이 project ID를 앞에서 기록한 GCP 프로젝트 ID로 바꿉니다.
```
gcloud config set project project ID
```
프로덕션 환경의 태그 관리 서버를 재구성하려면 아래의 설정 스크립트를 실행하세요. 다음 작업을 실행합니다.
```
bash -c "$(curl -fsSL https://googletagmanager.com/static/serverjs/setup.sh)"
```
1. 배포 유형을 production으로 변경합니다.
2. 프로덕션 트래픽을 제공할 추가 서버를 설정합니다. 최소 세 개의 서버를 사용하는 것이 좋습니다.

선택사항: 로깅 사용 중지

요청 로깅

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

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

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

콘솔 로깅

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

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

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 메시지는 로깅에서 제외되어야 합니다.
로그 탐색기에 새로운 콘솔 로그 메시지가 표시되지 않는지 확인합니다.

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

서버 측 태그 지정의 기본 배포는 App Engine 도메인에서 호스팅됩니다. 웹사이트의 하위 도메인을 사용하도록 배포를 수정하는 것이 좋습니다.

웹사이트 하위 도메인을 태그 관리 서버에 매핑합니다.

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

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

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

5. 검증

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

여러 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로 업그레이드).

태그 관리 서버를 업데이트하려면 이전에 사용한 것과 동일한 설정을 사용하여 설정 스크립트를 다시 실행하세요. 기본적으로 기존 설정이 적용됩니다.

태그 관리 서버를 업데이트하는 방법은 다음과 같습니다.

Google Cloud Platform Cloud Shell을 엽니다.
Cloud Shell에서 Cloud Platform 프로젝트를 설정합니다. 다음과 같이 project ID를 앞에서 기록한 GCP 프로젝트 ID로 바꿉니다.
```
gcloud config set project project ID
```
이전에 사용한 것과 동일한 설정을 사용하여 설정 스크립트를 실행합니다. 기본적으로 기존 설정이 적용됩니다.
```
bash -c "$(curl -fsSL https://googletagmanager.com/static/serverjs/setup.sh)"
```

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

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

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

프로덕션 배포 시간 초과 문제 해결

설정 스크립트를 실행하여 태그 관리 서버를 만들거나 재구성할 경우 스크립트가 타임아웃될 수도 있습니다. 이러한 일이 발생하는 데는 여러 이유가 있으며, 가장 일반적인 두 가지 이유는 다음과 같습니다.

서비스 계정에 잘못된 권한이 있음 - Compute Engine 및 App Engine 서비스 계정으로 프로덕션 배포를 배포하고 유지해야 합니다. 기본적으로 이러한 계정은 적절한 권한으로 사전 구성되어 있지만, 조직의 정책으로 인해 이러한 권한이 부적절할 수도 있습니다.
1. Google Cloud 콘솔의 왼쪽 탐색 메뉴에서 IAM 및 관리자 페이지로 이동합니다.
2. Compute Engine 서비스 계정 <project_number>-compute@developer.gserviceaccount.com 및 App Engine 서비스 계정 <project_name>@appspot.gserviceaccount.com을 찾습니다.
3. 두 서비스 계정 모두에 Editor 역할이 있어야 합니다. 두 계정 중 하나라도 Editor 역할이 없는 경우, 계정 오른쪽에 있는 연필 아이콘을 클릭하고 기존 역할 드롭다운을 클릭한 후 상단으로 스크롤하고 프로젝트, 편집자를 차례로 클릭하여 역할을 업데이트합니다.
할당량 부족 - 프로덕션 배포에서는 Compute Engine 할당량을 사용합니다. 프로젝트에 할당량이 충분하지 않으면 리소스를 프로비저닝하려고 시도하는 동안 배포가 타임아웃될 수 있습니다.
1. Google Cloud 콘솔의 왼쪽 탐색 메뉴에서 IAM 및 관리자 페이지로 이동한 후 왼쪽 탐색 메뉴의 할당량 탭을 클릭합니다.
2. 페이지 상단에서 표 필터링이라고 표시된 텍스트 상자를 클릭한 후 Compute Engine API를 입력하고 유일하게 표시된 결과를 클릭합니다.
3. 모든 할당량 상태가 한도 내에 있는지 또는 녹색 체크표시가 표시되어 있는지 확인합니다.
4. CPU를 찾아 클릭합니다. 현재 사용량과 배포 중인 인스턴스 수가 여전히 배포 리전의 한도를 넘지 않는지 확인합니다.