이 문서에서는 Cloud Storage에서 Cloud Logging에 로그 가져오기에 설명된 참조 아키텍처를 배포하는 방법을 설명합니다.
이러한 안내는 로그 가져오기 작업을 구성하고 실행하려는 DevOps, 사이트 안정성 엔지니어(SRE), 보안 조사 담당자를 포함한 엔지니어 및 개발자를 대상으로 합니다. 이 문서에서는 사용자가 Cloud Run 가져오기 작업과 Cloud Storage 및 Cloud Logging을 사용하는 방법에 익숙하다고 가정합니다.
아키텍처
다음 다이어그램은 Google Cloud 서비스가 이 참조 아키텍처에 사용된 방법을 보여줍니다.
자세한 내용은 Cloud Storage에서 Cloud Logging에 로그 가져오기를 참조하세요.
목표
- Cloud Run 가져오기 작업 만들기 및 구성
- 작업 실행을 위한 서비스 계정 만들기
비용
이 문서에서는 비용이 청구될 수 있는 다음과 같은 Google Cloud 구성요소를 사용합니다.
프로젝트 사용량을 기준으로 예상 비용을 산출하려면 가격 계산기를 사용하세요.
시작하기 전에
가져오려는 로그를 이전에 Cloud Storage로 내보냈는지 확인합니다. 즉, 예상된 내보내기 형식으로 이미 구성되어 있어야 합니다.
In the Google Cloud console, activate Cloud Shell.
Create or select a Google Cloud project.
-
Create a Google Cloud project:
gcloud projects create PROJECT_ID
Replace
PROJECT_IDwith a name for the Google Cloud project you are creating. -
Select the Google Cloud project that you created:
gcloud config set project PROJECT_ID
Replace
PROJECT_IDwith your Google Cloud project name.
-
Enable the Cloud Run and Identity and Access Management (IAM) APIs:
gcloud services enable run.googleapis.com
iam.googleapis.com
PROJECT_ID를 대상 프로젝트 ID로 바꿉니다.
필요한 역할
이 솔루션을 배포하는 데 필요한 권한을 얻으려면 관리자에게 다음 IAM 역할을 부여해 달라고 요청하세요.
-
로그 버킷에 로그 작성자 역할을 부여하려면 대상 프로젝트에서 프로젝트 IAM 관리자 (
roles/resourcemanager.projectIamAdmin) 역할이 필요합니다. -
스토리지 버킷에 스토리지 객체 뷰어 역할을 부여하려면 스토리지 버킷이 호스팅되는 프로젝트에서 스토리지 관리자 (
roles/storage.admin) 역할이 필요합니다. -
서비스 계정을 만들려면 대상 프로젝트에서 서비스 계정 만들기 (
roles/iam.serviceAccountCreator) 역할을 수행해야 합니다. -
프로젝트에서 서비스를 사용 설정하려면 대상 프로젝트에서 서비스 사용량 관리자 (
roles/serviceusage.serviceUsageAdmin) 역할이 필요합니다. -
로그 버킷을 업그레이드하고 가져온 로그를 삭제하려면 대상 프로젝트에서 로깅 관리자 (
roles/logging.admin) 역할이 필요합니다. -
가져오기 작업을 만들고, 실행, 수정하려면 대상 프로젝트에서 Cloud Run 개발자 (
roles/run.developer) 역할이 필요합니다.
역할 부여에 대한 자세한 내용은 프로젝트, 폴더, 조직에 대한 액세스 관리를 참조하세요.
커스텀 역할이나 다른 사전 정의된 역할을 통해 필요한 권한을 얻을 수도 있습니다.
로그 애널리틱스를 사용하도록 로그 버킷 업그레이드
기본 로그 버킷을 사용하고 로그 애널리틱스를 사용하도록 업그레이드하는 것이 좋습니다. 하지만 프로덕션 환경에서는 기본 버킷이 요구사항을 충족하지 않을 경우에 자체 로그 버킷을 사용할 수 있습니다. 자체 버킷을 사용하도록 결정한 경우에는 대상 프로젝트에 수집되는 로그를 이 로그 버킷으로 라우팅해야 합니다. 자세한 내용은 로그 버킷 구성 및 싱크 만들기를 참고하세요.
버킷을 업그레이드할 때는 SQL을 사용해서 로그를 쿼리하고 분석할 수 있습니다. 버킷을 업그레이드하거나 로그 애널리틱스를 사용하는 데에는 추가 비용이 없습니다.
대상 프로젝트에서 기본 로그 버킷을 업그레이드하려면 다음을 수행합니다.
로그 애널리틱스를 사용하도록 기본 로그 버킷을 업그레이드합니다.
gcloud logging buckets update BUCKET_ID --location=LOCATION --enable-analytics다음을 바꿉니다.
- BUCKET_ID: 로그 버킷의 이름입니다(예:
_Default). - LOCATION: 지원되는 리전입니다(예:
global).
- BUCKET_ID: 로그 버킷의 이름입니다(예:
Cloud Run 가져오기 작업 만들기
작업을 만들 때 이 참조 아키텍처에 대해 제공된 사전 빌드된 컨테이너 이미지를 사용할 수 있습니다. 30일 보관 기간을 변경하도록 구현을 수정해야 하거나 다른 요구사항이 있는 경우에는 자체 커스텀 이미지를 빌드할 수 있습니다.
Cloud Shell에서 구성 및 환경 변수로 작업을 만듭니다.
gcloud run jobs create JOB_NAME \ --image=IMAGE_URL \ --region=REGION \ --tasks=TASKS \ --max-retries=0 \ --task-timeout=60m \ --cpu=CPU \ --memory=MEMORY \ --set-env-vars=END_DATE=END_DATE,LOG_ID=LOG_ID,\ START_DATE=START_DATE,STORAGE_BUCKET_NAME=STORAGE_BUCKET_NAME,\ PROJECT_ID=PROJECT_ID다음을 바꿉니다.
- JOB_NAME: 작업의 이름입니다.
- IMAGE_URL: 컨테이너 이미지에 대한 참조입니다.
us-docker.pkg.dev/cloud-devrel-public-resources/samples/import-logs-solution을 사용하거나 GitHub의 안내에 따라 이미지를 빌드한 경우 커스텀 이미지의 URL을 사용합니다. - REGION: 작업을 찾을 리전입니다. 추가 비용을 방지하려면 Cloud Storage 버킷 리전과 동일한 리전 또는 멀티 리전에 작업을 유지하는 것이 좋습니다. 예를 들어 버킷이 미국 멀티 리전인 경우 us-central1을 사용할 수 있습니다. 자세한 내용은 비용 최적화를 참고하세요.
- TASKS: 작업을 실행해야 하는 태스크 수입니다.
기본값은
1입니다. 시간 초과가 발생하면 태스크 수를 늘릴 수 있습니다. - CPU: CPU 한도이며, 1, 2, 4, 6, 8개 CPU일 수 있습니다.
기본값은
2입니다. 시간 초과가 발생한 경우 개수를 늘릴 수 있습니다. 자세한 내용은 CPU 한도 구성을 참조하세요. - MEMORY: 메모리 한도입니다.
기본값은
2Gi입니다. 시간 초과가 발생하면 개수를 늘릴 수 있습니다. 자세한 내용은 메모리 한도 구성을 참조하세요. - END_DATE: MM/DD/YYYY 형식의 날짜 범위의 끝입니다. 타임스탬프가 이 날짜보다 이전이거나 동일한 로그를 가져옵니다.
- LOG_ID: 가져오려는 로그의 로그 식별자입니다. 로그 ID는 로그 항목의
logName필드의 일부입니다. 예를 들면cloudaudit.googleapis.com입니다. - START_DATE: MM/DD/YYYY 형식의 날짜 범위의 시작입니다. 타임스탬프가 이 날짜보다 이후이거나 동일한 로그를 가져옵니다.
- STORAGE_BUCKET_NAME: 로그가 저장되는 Cloud Storage 버킷의 이름입니다(
gs://프리픽스 제외).
max-retries옵션은 중복 로그 항목을 유발할 수 있는 실패한 태스크에 대한 재시도를 방지하도록 0으로 설정됩니다.시간 초과로 인해 Cloud Run 작업이 실패하면 완전하지 않은 가져오기가 발생할 수 있습니다. 시간 초과로 인한 완전하지 않은 가져오기를 방지하려면 CPU 및 메모리 리소스와 함께
tasks값을 늘립니다.
이 값을 늘리면 비용이 늘어날 수 있습니다. 비용에 대한 자세한 내용은 비용 최적화를 참조하세요.
Cloud Run 작업을 실행할 서비스 계정 만들기
Cloud Shell에서 사용자 관리 서비스 계정을 만듭니다.
gcloud iam service-accounts create SA_NAMESA_NAME을 서비스 계정의 이름으로 바꿉니다.
스토리지 버킷에 대한 스토리지 객체 뷰어 역할을 부여합니다.
gcloud storage buckets add-iam-policy-binding gs://STORAGE_BUCKET_NAME \ --member=serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com \ --role=roles/storage.objectViewer다음을 바꿉니다.
- STORAGE_BUCKET_NAME: 가져오기 작업 구성에 사용한 스토리지 버킷의 이름입니다. 예를 들면
my-bucket입니다. - PROJECT_ID: 대상 프로젝트 ID입니다.
- STORAGE_BUCKET_NAME: 가져오기 작업 구성에 사용한 스토리지 버킷의 이름입니다. 예를 들면
로그 버킷에 대한 로그 작성자 역할을 부여합니다.
gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com \ --role=roles/logging.logWriterCloud Run 작업에 대한 서비스 계정을 설정합니다.
gcloud run jobs update JOB_NAME \ --region=REGION \ --service-account SA_NAME@PROJECT_ID.iam.gserviceaccount.comREGION을 Cloud Run 가져오기 작업을 배포한 동일한 리전으로 바꿉니다.
가져오기 작업 실행
Cloud Shell에서 생성된 작업을 실행합니다.
gcloud run jobs execute JOB_NAME \ --region=REGION
자세한 내용은 작업 실행 및 작업 실행 관리를 참고하세요.
작업을 다시 실행해야 하는 경우 중복 항목이 생성되지 않도록 이전에 가져온 로그를 삭제합니다. 자세한 내용은 이 문서의 뒷부분에 있는 가져온 로그 삭제를 참조하세요.
가져온 로그를 쿼리할 때는 쿼리 결과에 중복 항목이 표시되지 않습니다.
Cloud Logging은 쿼리 결과에서 중복 항목(동일한 삽입 ID와 타임스탬프를 갖는 동일한 프로젝트의 로그 항목)을 삭제합니다. 자세한 내용은 Logging API 참조에서 insert_id 필드를 참고하세요.
결과 확인
작업이 성공적으로 완료되었는지 검증하려면 Cloud Shell에서 가져오기 결과를 쿼리할 수 있습니다.
gcloud logging read 'log_id("imported_logs") AND timestamp<=END_DATE'
가져온 로그가 출력에 표시됩니다. 이 프로젝트가 지정된 기간 내에 둘 이상의 가져오기 작업을 실행하는 데 사용된 경우에는 출력에 이러한 작업에서 가져온 로그도 표시됩니다.
옵션과 로그 항목 쿼리에 대한 자세한 내용은 gcloud logging read를 참조하세요.
가져온 로그 삭제
동일한 작업을 두 번 이상 실행해야 할 경우에는 중복된 항목과 비용 증가를 방지하기 위해 이전에 가져온 작업을 삭제합니다.
가져온 로그를 삭제하려면 Cloud Shell에서 로그 삭제를 실행합니다.
gcloud logging logs delete imported_logs
가져온 로그를 삭제하면 마지막 가져오기 작업 실행의 결과뿐만 아니라 대상 프로젝트로 가져온 모든 로그 항목이 삭제됩니다.
다음 단계
- GitHub 저장소에서 구현 코드 검토
- 로그 애널리틱스 및 SQL을 사용하여 가져온 로그를 분석하는 방법 알아보기
- 그 밖의 참조 아키텍처, 다이어그램, 튜토리얼, 권장사항을 알아보려면 클라우드 아키텍처 센터를 확인하세요.
참여자
저자: 레오니드 얀쿨린 | 개발자 관계 엔지니어
기타 참여자: