이 튜토리얼에서는 Google Cloud Platform 애플리케이션으로 다음을 수행할 수 있는 Google Stackdriver를 살펴봅니다.
- App Engine, Compute Engine, Container Engine에서 실행되는 애플리케이션에서 디버그 스냅샷을 만듭니다.
- 애플리케이션 로그 보기
- 측정항목을 설정하고 모니터링하며 알림을 받으세요.
- API 호출을 추적하고 코드의 응답 시간 및 잠재적 병목 현상을 분석하세요.
- 앱을 배포할 필요 없이 실행 중인 애플리케이션에 로그 포인트를 추가합니다. 이 기능은 매우 고유하며 도움이 될 수 있습니다.
이 튜토리얼에서는 처음부터 다음을 수행합니다.
- Google Cloud Platform 프로젝트 (특히 App Engine) 만들기
- Google Cloud Platform 프로젝트 소스 저장소 설정
- GitHub에서 제공하는 표준 방명록 Python 애플리케이션 소스를 활용합니다.
- 코드 배포
- 실행 중인 애플리케이션의 디버그 스냅샷을 가져오는 방법 알아보기
- 로깅 및 애플리케이션 호출 trace 살펴보기
- 현재 실행 중인 애플리케이션에 로그 지점을 추가합니다. 이 기능은 이 블로그 게시물(다시 시작하지 않고 애플리케이션에 애플리케이션 로그 추가하기)에서 처음 다뤘습니다.
이제 시작해 볼까요?
이 콘텐츠는 Romin Iani에서 처음 만들었으며 여기에 게시되었습니다.
자습형 환경 설정
Google 계정 (Gmail 또는 Google 앱)이 아직 없다면 계정을 만들어야 합니다. Google Cloud Platform Console (console.cloud.google.com)에 로그인하여 새 프로젝트를 만듭니다.
모든 Google Cloud 프로젝트에서 고유한 이름인 프로젝트 ID를 기억하세요(위의 이름은 이미 사용되었으므로 사용할 수 없습니다). 이 ID는 나중에 이 Codelab에서 PROJECT_ID라고 부릅니다.
다음으로 Google Cloud 리소스를 사용하려면 Cloud Console에서 결제를 사용 설정해야 합니다.
이 codelab을 실행하는 과정에는 많은 비용이 들지 않지만 더 많은 리소스를 사용하려고 하거나 실행 중일 경우 비용이 더 들 수 있습니다(이 문서 마지막의 '삭제' 섹션 참조).
Google Cloud Platform의 신규 사용자는 $300 무료 체험판을 사용할 수 있습니다.
Google Cloud Shell
이 Codelab에서는 Cloud에서 실행되는 명령줄 환경인 Google Cloud Shell을 사용합니다.
이 Debian 기반 가상 머신에는 필요한 모든 개발 도구가 로드되어 있습니다. 영구적인 5GB 홈 디렉토리를 제공하고 Google Cloud에서 실행되므로 네트워크 성능과 인증이 크게 개선됩니다. 즉, 이 Codelab에 필요한 것은 브라우저뿐입니다(Chromebook에서도 작동 가능).
Google Cloud Shell을 활성화하려면 개발자 콘솔에서 오른쪽 상단의 버튼을 클릭하면 됩니다. 환경을 프로비저닝하고 연결하는 데는 몇 분 정도만 소요됩니다.
그런 다음 서비스 약관에 동의하고 'Cloud Shell 시작' 링크를 클릭합니다.
Cloud Shell에 연결되면 인증이 이미 완료되어 있고 프로젝트가 이미 PROJECT_ID으로 설정되어 있음을 확인할 수 있습니다.
gcloud auth list
명령어 결과
Credentialed accounts: - <myaccount>@<mydomain>.com (active)
gcloud config list project
명령어 결과
[core] project = <PROJECT_ID>
어떤 이유로 프로젝트가 설정되지 않은 경우 다음 명령어를 실행하면 됩니다.
gcloud config set project <PROJECT_ID>
PROJECT_ID를 찾고 계신가요? 설정 단계에서 사용한 ID를 확인하거나 콘솔 대시보드에서 찾아보세요.
중요: 마지막으로 기본 영역 및 프로젝트 구성을 설정합니다.
gcloud config set compute/zone us-central1-f
다양한 영역을 선택할 수 있습니다. 리전 및 영역 영역 문서에서 자세히 알아보세요.
사용 설정된 StackDriver API 확인
프로젝트에서 사용 설정된 API를 살펴보겠습니다. 검색창을 사용하여 아래와 같이 API 대시보드를 찾습니다.
프로젝트에 사용 설정된 특정 API를 살펴봅니다.
모든 Google Cloud Platform 프로젝트는 비공개 Git 호스팅을 제공하지만 먼저 작업할 기본 저장소를 만들어야 합니다. 콘솔 검색창을 사용하여 소스 저장소로 이동합니다.
'저장소 만들기'를 클릭하여 '기본값'이라는 새 코드 저장소를 만듭니다.
이제 Cloud Shell을 사용하여 이 디렉터리를 Google Cloud Shell 인스턴스로 클론합니다. 이를 위해 먼저 Google Cloud Shell 인스턴스에 디렉터리를 만들고 아래와 같이 이동합니다 (샘플 출력).
mkdir stackdriver-democd stackdriver-demo/이제 아래와 같이 gcloud 명령어를 통해 여기에 기본 저장소를 클론할 수 있습니다.
gcloud source repos clone default
콘솔에 다음과 같은 결과가 표시됩니다.
Cloning into '/home/gcp123_student/default'...
warning: You appear to have cloned an empty repository.
Project [qwiklabs-gcp-1234abc1234] repository [default] was cloned to [/home/gcp123_student/default].좋습니다. 설정된 git 리모컨을 좀 더 자세히 살펴보겠습니다. 무조건 내용을 전달하는 것은 아니며, 어떤 일이 일어났는지 보다 정확하게 파악할 수 있도록 지원해 주는 정보입니다.
생성된 기본 디렉터리로 이동한 후 아래와 같이 git remote -v 명령어를 실행합니다.
cd defaultgit remote -v콘솔 출력은 다음과 비슷하게 표시됩니다.
origin https://source.developers.google.com/p/qwiklabs-gcp-1234abc1234/r/default (fetch)
origin https://source.developers.google.com/p/qwiklabs-gcp-1234abc1234/r/default (push)Google Cloud 프로젝트와 연결된 Git 저장소를 올바르게 가리키는 것을 확인할 수 있습니다.
GitHub에서 방명록 애플리케이션 가져오기
사용할 애플리케이션은 방명록이라는 표준 App Engine 애플리케이션이며 공식 Google Cloud Platform GitHub 저장소에서 제공됩니다. 이 애플리케이션은 시작하기 위한 공식 문서의 일부입니다. GitHub 프로젝트는 https://github.com/GoogleCloudPlatform/appengine-guestbook-python에서 사용할 수 있습니다.
이제 이 코드를 Cloud Shell 인스턴스로 가져오겠습니다. 명령어와 그 결과는 다음과 같습니다.
git pull https://github.com/GoogleCloudPlatform/appengine-guestbook-python
콘솔에 다음과 같은 결과가 표시됩니다.
remote: Counting objects: 485, done. remote: Total 485 (delta 0), reused 0 (delta 0), pack-reused 485 Receiving objects: 100% (485/485), 436.42 KiB | 163.00 KiB/s, done. Resolving deltas: 100% (195/195), done. From https://github.com/GoogleCloudPlatform/appengine-guestbook-python * branch HEAD -> FETCH_HEAD
이제 모든 코드가 Cloud Shell 인스턴스에 로컬로 표시됩니다. GitHub 프로젝트에서 가져온 다양한 파일을 확인할 수 있습니다.
Cloud Shell을 사용하여 현재 코드를 프로젝트 Git 저장소에 푸시
이제 이 코드를 GCP 프로젝트 Git 저장소로 푸시하면 코드에 중단점, 로그 지점 등을 설정할 수 있습니다. 이 단계는 GitHub와 로컬 시스템, 기타 소스 코드 연결 방법을 직접 통합할 수 있으므로 필수 단계가 아닙니다.
여기서는 GCP 프로젝트 Git 저장소에 이 코드를 푸시하겠습니다. 이 작업은 아래와 같이 표준 git push 명령어를 통해 실행됩니다.
git push origin master
콘솔에 다음과 같은 결과가 표시됩니다.
Counting objects: 485, done. Compressing objects: 100% (280/280), done. Writing objects: 100% (485/485), 436.42 KiB | 0 bytes/s, done. Total 485 (delta 195), reused 485 (delta 195) remote: Storing objects: 100% (485/485), done. remote: Processing commits: 100% (152/152), done. To https://source.developers.google.com/p/qwiklabs-gcp-1234abc1234/r/default * [new branch] master -> master
이제 GCP Console과 Cloud Console로 돌아가 특히 개발 섹션으로 이동합니다. 소스 코드를 클릭하면 기본 저장소의 경우 모든 프로젝트 파일을 볼 수 있습니다. 아래에 샘플 출력이 표시됩니다.
이제 방명록 App Engine 애플리케이션을 배포할 준비가 완료되었습니다. 앱을 배포하려면 Google Cloud Shell 상태 및 기본 디렉터리에 있는지 확인합니다. 아래와 같이 gcloud app deploy 명령어를 사용합니다.
gcloud app deploy --version 1
리전을 선택하라는 메시지가 표시되면 [1] us-east1을 선택합니다.
콘솔에 다음과 같은 결과가 표시됩니다.
You are about to deploy the following services: — qwiklabs-gcp-1234abc1234/default/1 (from [/home/gcp123-student/default/app.yaml]) Deployed URL: [https://qwiklabs-gcp-1234abc1234.appspot.com] Do you want to continue (Y/n)? Y Beginning deployment of service [default]... File upload done. Updating service [default]...done. Deployed service [default] to https://qwiklabs-gcp-1234abc1234.appspot.com]
앱 배포 명령어에 버전 매개변수를 제공했습니다. "1" 값을 제공했습니다.
방명록 애플리케이션은 지속성을 위해 Google Cloud Datastore를 사용하므로 Datastore 색인을 업데이트해야 합니다. 색인은 index.yaml 파일에 지정되며 아래와 같이 gcloud datastore create-indexes 명령어를 사용합니다.
gcloud datastore create-indexes index.yaml
콘솔에 다음과 같은 결과가 표시됩니다.
You are about to update the following configurations: — qwiklabs-gcp-1234abc1234/index From: [/home/gcp123_student/default/index.yaml] Do you want to continue (Y/n)? Y
Datastore 색인을 업데이트하는 데 시간이 걸릴 수 있습니다. 상태를 확인하려면 'Datastore 색인'을 검색하고 '색인'을 클릭합니다. 색인이 빌드되는 동안에는 아래와 같이 값이 "색인 생성"인 상태가 표시됩니다.
Compute → App Engine으로 이동한 다음 아래와 같이 버전을 클릭하여 버전 1 앱을 배포했는지 확인할 수 있습니다.
이제 모든 것이 정상이며 https://<PROJECT_ID>.appspot.com로 이동하여 프로젝트를 살펴볼 수 있습니다. Datastore 색인이 준비되는 데 몇 분 정도 걸릴 수 있으므로 애플리케이션에 오류 (예: 내부 서버 오류)가 표시되면 몇 분 후에 다시 시도해 보세요.
이제 다음과 같이 로그인하고 방명록 항목을 몇 개 만들어 애플리케이션을 사용합니다.
좋습니다. 이제 Stackdriver 기능을 자세히 살펴볼 준비가 되었습니다.
먼저 실행 중인 애플리케이션의 스냅샷을 만드는 방법을 살펴보겠습니다. 스냅샷은 특정 코드를 디버그하거나 변수를 검사하는 등의 작업을 수행할 때 유용합니다. 이 모든 과정은 애플리케이션이 아직 제공 중일 때 발생합니다. 이는 애플리케이션에 문제 신고가 있을 때 디버그하여 앱에서 어떤 일이 일어나는지 확인하고, 여러 변수를 검사하고, 조건부로 스냅샷을 생성하는 등의 작업을 하려는 경우에 매우 유용합니다.
방명록 애플리케이션에서도 이제 그렇게 합니다. 누군가 홈페이지를 요청하는 경우 스냅샷을 요청하고, 특히 Datastore에 있는 인사말 목록을 가져오는 작업을 요청합니다.
이를 위한 코드는 guestbook.py 파일에 있습니다. 특히 Datastore에서 인사말 목록을 가져온 후에는 런타임에 코드를 검사하는 것이 좋습니다. 이는 #72행에서 수행됩니다. 따라서 줄 74에 중단점을 배치하면 #72가 실행되었음을 알 수 있습니다.
이렇게 하려면 AppEngine 버전 뷰에서 "Debug"를 클릭하거나 Stackdriver → 디버그로 이동하세요 . 아래와 같은 화면이 표시됩니다. 왼쪽의 파일(guestbook.py)을 선택한 후 아래와 같은 줄 번호를 클릭하면 됩니다.
위의 빨간색 상자에 강조표시된 메시지가 표시되며, 스냅샷이 트리거될 때까지 기다리는 중입니다. 이제 다음 페이지에 접속하기만 하면 됩니다.
https://<PROJECT_ID>.appspot.com
그렇게 하면 스냅샷이 활성화되고 아래와 같이 변수와 호출 스택 섹션이 채워집니다. 변수가 표시되는 방식을 살펴보고 변수를 펼쳐 값을 확인할 수 있습니다. 정말 유용합니다.
예를 들어 인사말 변수를 펼치면 생성된 방명록 항목 수에 해당하는 레코드가 표시됩니다.
매우 편리한 기능 중 하나는 언제든지 스냅샷을 다시 만들 수 있다는 것입니다. 언제든지 카메라 아이콘을 클릭하면 아래와 같이 스냅샷이 표시될 때까지 다시 한 번 대기합니다.
아래와 같이 표현식 필드를 사용하여 특정 변수를 추적할 수 있습니다. 예를 들어 인사말에 변수로 인사말을 하고 각 스냅샷이 조회되는 순간에 변수의 값을 검사하고 싶습니다. 아래 스크린샷과 같이 인사말 변수를 입력할 수 있습니다. 스냅샷에 도달하면 표시된 값이 채워집니다.
스냅샷을 특정 조건에서만 활성화하려면 아래와 같이 조건 필드를 사용하면 됩니다. 여기에서는 인사말이 1보다 많을 때만 스냅샷이 생성된다고 말합니다. 원하는 경우 실험해 보세요.
웹 애플리케이션 성능이 게시자가 설정한 요구사항을 충족하는지 확인하는 것이 매우 중요합니다. Stackdriver Trace는 애플리케이션의 지연 시간을 이해하는 데 도움이 되는 핵심 도구입니다.
App Engine은 기본적으로 모든 App Engine 애플리케이션에 사용 설정되며, 모든 엔드포인트에서 제공되는 것과 함께 모든 엔드포인트에 대한 매우 유용한 성능 세부정보를 제공합니다.
이 경우 홈페이지 ("/")를 누르면 방명록 항목이 표시되고 추가됩니다. 트레이스로 충분히 지연 시간을 확인할 수 있습니다. Stackdriver Trace 개요로 이동하면 아래와 같이 스크린샷이 표시됩니다. 최근 trace와 지연 시간을 확인합니다.
trace 중 하나를 클릭하면, 즉 URI 링크를 클릭하면 아래와 같이 자세한 trace가 표시됩니다.
지연 시간을 분석하고 어떤 시간이 가장 오래 걸리는지 파악할 수 있습니다. 위 시각화에서 Datastore 쿼리에 시간이 오래 걸리는 것을 확인할 수 있습니다. 한 가지 옵션은 데이터를 캐시하여 병목 현상을 줄이는 것일 수 있습니다. 이 모든 작업은 애플리케이션에 따라 달라지며 호출 추적에서 리팩터링이 필요할 수 있는 영역을 확인하는 데 매우 유용합니다.
Stackdriver Logging으로 이동하여 언제든지 애플리케이션 로그를 볼 수 있습니다 (아래 참고). 다양한 GCP 서비스 → 로그 유형 → 로그 수준 → 날짜 등부터 여러 필터를 사용할 수 있습니다.
아래 스크린샷에는 App Engine 애플리케이션 및 기본 버전 1의 로그가 나와 있습니다.
마지막으로, 사용할 수 있는 가능성에 대해 기대하게 하는 기능을 살펴보겠습니다. Google은 대개 개발자가 코드에 로그 구문을 입력하기 위해 최선을 다하고 있으므로 코드를 배포한 다음 로그를 통해 알고 있는 내용을 모두 알 수 있기를 바랍니다.
하지만 디버깅에 그치지 않고 일반적인 워크플로는 코드를 수정하고 추가 로그 구문에 넣은 후 다시 배포하고 모니터링하는 것입니다.
괜찮습니다. 하지만 이러한 로그 구문을 실행 중인 애플리케이션에 추가할 수 있다면 (지금 바로 로그 지점이라고 함) 어떻게 해야 할까요? 즉, 애플리케이션 중지, 코드 변경 및 재배포 프로세스를 진행할 필요가 없습니다. 대신 로그 지점 지원을 사용하여 애플리케이션 외부에서 로그 지점 목록을 관리할 수 있습니다.
Cloud Shell 내에서 지금 구성한 로그 지점의 현재 목록을 확인하겠습니다. 분명히 0이어야 합니다. 이 작업은 아래와 같이 gcloud 명령어를 통해 실행됩니다.
gcloud debug logpoints list
콘솔에 다음과 같은 결과가 표시됩니다.
Debug target not specified. Using default target: default-1 Listed 0 items.
이제 실행 중인 애플리케이션에 로그 지점을 추가하겠습니다. 로그 지점을 추가하려면 다음 작업을 해야 합니다.
- 소스 코드 파일과 로그 지점을 추가할 줄 번호를 식별합니다.
- 로그 메시지를 식별합니다. 이 로그 메시지는 하드코딩되거나 표현식일 수도 있습니다.
이 경우에는 아래와 같이 logpoints create 명령어를 통해 #74 행의 guestbook.py 파일에 로그 지점을 추가합니다.
gcloud debug logpoints create guestbook.py:74 "Fetched greetings from Datastore. Count of greetings : {len(greetings)}"
콘솔에 다음과 같은 결과가 표시됩니다.
Debug target not specified. Using default target: default-1
— id: 53538243519d4-f9a0-bdbce
location: guestbook.py:74
logLevel: INFO
logMessageFormat: Fetched greetings from Datastore. Count of greetings : {len(greetings)}
condition: None
status: ACTIVE
filename:linenumber와 로그 메시지를 위에서 제공했습니다. 로그 메시지에는 Datastore에서 가져온 인사말 수를 출력하는 표현식도 포함됩니다.
명령어를 실행하면 로그 지점이 추가되었다는 메시지가 표시됩니다. 아래 Cloud Shell의 스크린샷은 다음과 같습니다.
이제 logpoints list 명령어를 실행하면 다음과 같은 출력이 표시됩니다.
gcloud debug logpoints list
콘솔에 다음과 같은 결과가 표시됩니다.
Debug target not specified. Using default target: default-1
STATUS LOCATION CONDITION LOG_LEVEL LOG_MESSAGE_FORMAT ID
ACTIVE
guestbook.py:74 INFO Fetched greetings from Datastore. Count of greetings : {len(greetings)} 53538243519d4-f9a0-bdbce
실제 동작을 확인하려면 https://<PROJECT_ID>.appspot.com에서 홈페이지를 다시 누르세요. 이렇게 하면 코드가 호출되고 결과적으로 로그 지점이 생성됩니다. 이 로그는 애플리케이션 로그에 기본적으로 기록됩니다. 따라서 아래와 같이 Stackdriver Logging을 한 번 더 방문하면 됩니다.
특정 요청을 클릭하면 됩니다. 세부정보에 로그 지점이 실행되고 로그 메시지가 표시됩니다.
튜토리얼을 유용하게 활용하시기 바랍니다. Stackdriver 플랫폼에서 얻을 수 있는 몇 가지 기능만 다룹니다. 살펴볼 내용은 많습니다. 자세한 내용은 Google Cloud Platform 튜토리얼(https://rominirani.com/)을 통해 Romin irani's 블로그(이 Codelab의 원래 작성자)를 확인하세요.
또한 'Stackdriver의 모니터링 및 로깅 사용'이라는 다른 Codelab을 통해 애플리케이션의 상태를 더욱 정확하게 파악할 수 있습니다.
Codelab에 관한 의견이 있거나 이 페이지의 문제를 신고하려면 이 페이지 왼쪽 하단에 있는 "버그 찾기" 링크를 사용하세요.