[GCP]Serverless 서비스인 Cloud Run 알아보기 10부 — Log Sync 와 EventArc 를 통해 여러 프로젝트의 이벤트 통합 방법

이정운 (Jungwoon Lee)
google-cloud-apac
Published in
22 min readApr 22, 2024

안녕하세요 이정운 입니다.

Google Cloud 에서 제공하는 컨테이너 기반의 Serverless 솔루션인 Cloud Run 에 대해서 살펴보고 실제 테스트해보면서 써볼 수 있는 시간을 가져보는 시리즈를 하단과 같이 진행하고 1차 마무리를 했었습니다.

[GCP]Serverless 서비스인 Cloud Run 알아보기 1부 — Cloud Run 개요
[GCP]Serverless 서비스인 Cloud Run 알아보기 2부 — 로컬에서 개발하기(Cloud Code)
[GCP]Serverless 서비스인 Cloud Run 알아보기 3부 — 업데이트 및 트래픽 조정
[GCP]Serverless 서비스인 Cloud Run 알아보기 4부 — 서버리스 VPC 액세스
[GCP]Serverless 서비스인 Cloud Run 알아보기 5부 — Eventarc 를 통한 이벤트 받기
[GCP]Serverless 서비스인 Cloud Run 알아보기 6부 — Cloud logging 과 Eventarc 를 통한 이벤트 처리
[GCP]Serverless 서비스인 Cloud Run 알아보기 7부 — Cloud Storage FUSE 를 활용하여 여러 서비스간의 데이터 공유
[GCP]Serverless 서비스인 Cloud Run 알아보기 8부 — Cloud Run Jobs 서비스
[GCP]Serverless 서비스인 Cloud Run 알아보기 9부 — 안 알려졌지만 주목할만한 2022년 업데이트 정리

이와 같이 Cloud Run 시리즈는 1차로 마무리하고, 거진 1년이라는 시간이 지나가고 있는데 이번에 EventArc 와 Cloud Run 을 활용하는 괜찮은 Use case 를 발견해서 활용하시는데 도움이 될까 추가해서 10부로 이야기를 드리려고 합니다.

Route Cloud Audit Logs events across projects
https://cloud.google.com/eventarc/docs/cross-project-triggers#audit-logs-events

Project 1 — User projects(일반 프로젝트들 — 이벤트 발생)
Project 2 — Central project(여러 프로젝트들의 이벤트를 모아서 처리하는 프로젝트)

이번 이야기에서 말씀드릴 Use case 는 기업에서 활용되는 Google cloud 프로젝트가 여러개 있는 경우에 관리와 거버넌스를 강화하는 차원에서 각 프로젝트의 필요한 이벤트를 받아서(예:GCE 인스턴스 생성/삭제 같은) 필요한 액션을 하거나 조치를 해야 하는 경우에 활용될 수 있는 형태입니다. 이를 좀 더 기술적으로 설명드리면, 자원에 관련된 액션이 발생했을때 자동 생성되는 Cloud Audit Log 를 활용해서 해당 Audit log 이벤트를 Cloud Logging 의 Log Sync 로 다른 프로젝트로 보냅니다. 그리고 해당 프로젝트에서 Cloud Pub/Sub 을 통해 EventArc 를 동작하게 하고 이를 통해서 Cloud Run 을 수행하여 원하는 비니지스 로직/액션/조치를 수행할 수 있는 아키텍처 입니다.

단순한 아키텍처 그림과 짧은 설명만으로는 바로 이해가 조금 어려울 듯 하며, 그렇기 때문에 해당 아키텍처에 대해서 실제 테스트 해보고 어떻게 동작하는지 확인해보는 시간을 가져보도록 하겠습니다.

#1) Audit logs, Log sync 살펴보기

이야기 진행 전에 먼저 처음으로 살펴보고 이해를 해야하는 것은 Cloud Audit logs 가 무엇인지, Log sync 가 무엇인지 알아보는 부분입니다.

Cloud Audit Logs overview
https://cloud.google.com/logging/docs/audit

Cloud Audit logs 는 이름 그대로 클라우드 감사 로그를 의미하며 Google cloud 서비스는 리소스 내의 관리 활동과 액세스를 기록하는 감사로그를 작성하도록 되어있습니다. 감사 로그는 온프레미스 환경과 투명성 수준이 동일한 Google Cloud 리소스 내에서 ‘누가 언제 어디서 무엇을 했는가?’ 라는 질문에 답하는 데 도움을 줄 수 있으며, 감사 로그를 사용 설정하면 보안, 감사, 규정 준수 항목이 Google cloud 데이터 및 시스템에서 취약점 발생에 대한 부분 또는 외부 데이터 오용 가능성등을 모니터링할 수 있습니다.

이러한 Audit logs 는 크게 API 호출이나 리소스의 구성 또는 메타데이터를 수정하는 기타 작업과 관련된 로그 항목인 관리 활동 감사 로그(Admin Activity audit logs), 리소스의 구성 또는 메타데이터를 읽는 API 호출뿐만 아니라 사용자가 제공한 리소스 데이터를 생성, 수정 또는 읽는 사용자 주도 API 호출과 관련된 로그 항목인 데이터 액세스 감사 로그(Data Access audit logs), 리소스 구성을 수정하는 Google Cloud 작업의 로그 항목을 포함하는 시스템 이벤트 감사 로그(System Event audit logs), 보안 정책 위반으로 인해 Google Cloud 서비스가 사용자 또는 서비스 계정에 대해 액세스를 거부할 때 기록되는 정책 거부 감사 로그(Policy Denied audit logs) 로 구성됩니다.

그렇기 때문에, 이런 감사로그를 활용하면 생각보다 많은 사용자 작업을 모니터링 할 수 있으며 이를 통해서 필요한 경우 이벤트등을 추가하여 더 다양한 작업들을 추가적으로 수행 할 수 있습니다. 예를 들어 GCE(VM) 의 경우에는 리소스 생성/삭제 뿐만 아니라 업데이트/패치 등의 정보를 관리 활동 감사 로그 에서 확인 가능합니다.

Compute Engine audit logging information
https://cloud.google.com/compute/docs/logging/audit-logging

이러한 감사로그는 관리콘솔에서 Logging > Log Explorer 메뉴를 통해서 확인 가능하며 관리 활동 감사 로그를 확인한다면 log name 에서 activity 를 선택하시면 하단과 같이 관리 활동 감사 로그를 확인 가능합니다.

예를 들어 GCE 로 범위를 좁혀서 확인하면 하단과 같이 insert(생성), delete(삭제) 에 대한 관리 활동 감사 로그를 확인 가능합니다.

Audit Log 에 대해서 간단하게 살펴봤으니 다음으로 Log Sync 가 무엇인지 알아보도록 하겠습니다. Google cloud 는 로그를 저장/관리/활용하기 위해서 Cloud Logging 이라는 솔루션을 제공하고 있습니다. 다시 말씀드려서 Google cloud 에서 사용되는 모든 GCE(VM), GKE 와 같은 자원 부터 솔루션들까지의 모든 로그는 단일 저장소이며 콘솔인 Cloud Logging 으로 수집되고 하나의 대시보드인 Log Explorer 를 통해서 로그를 보거나 분석할 수 있습니다. 이때, Cloud Logging 이 가진 좋은 기능중에 하나인 Log Sync 는 이름 그대로 로그를 다른 대상으로 라우팅할 수 있는 기능을 제공하는 역할을 수행합니다. Cloud Logging 의 다른 로그 버킷, 다른 Google cloud 프로젝트, Pub/Sub topics, BigQuery dataset, Cloud Storage 버킷등의 다양한 타겟을 지원하고 있습니다.

How to create log sinks
https://youtu.be/3Wtbde9fB_Y

이제 이를 정리해서 다시 말씀드리면, Audit Log 는 감사로그 이기 때문에 해당 프로젝트의 여러 자원에 대해서 ‘누가 언제 어디서 무엇을 했는가?’ 라는 다양한 정보를 가지고 있고 Log Sync 는 로그를 다른 대상, 특히 다른 Google cloud 프로젝트로 라우팅 할 수 있습니다. 따라서, 이를 조합하게 되면 여러 Google cloud 프로젝트의 Audit Log 를 Log sync 를 활용해서 하나의 특정 프로젝트로 라우팅 할 수 있으며 이를 통해서 수집된 Audit Log 를 라우팅 받는 특정 프로젝트에서 EventArc 와 Cloud Run 을 통해서 원하는 어떠한 작업(예:감사작업)을 수행할 수 있습니다.

첨부 #1.1) Eventarc 에 대해서 좀 더 상세사항이 궁금하면 이전에 진행되 이야기를 참고하시기 바라겠습니다.

[GCP]Serverless 서비스인 Cloud Run 알아보기 5부 — Eventarc 를 통한 이벤트 받기
https://medium.com/google-cloud-apac/gcp-serverless-%EC%84%9C%EB%B9%84%EC%8A%A4%EC%9D%B8-cloud-run-%EC%95%8C%EC%95%84%EB%B3%B4%EA%B8%B0-5%EB%B6%80-eventarc-%EB%A5%BC-%ED%86%B5%ED%95%9C-%EC%9D%B4%EB%B2%A4%ED%8A%B8-%EB%B0%9B%EA%B8%B0-f0771b656c4f

첨부 #1.2) Audit Log 중에 데이터 액세스 감사 로그(Data Access audit logs)는 BigQuery 를 제외하고는 기본이 disabled 입니다. 필요하신 경우 하단의 가이드 참고해서 enable 할 수 있습니다.

Enable Data Access audit logs
https://cloud.google.com/logging/docs/audit/configure-data-access

첨부 #1.3) 이전 파트의 관리 활동 감사 로그를 보신 분들은 의문을 가지셨을 수도 있는데 GCE 오퍼레이션에 대한 관리 활동 감사 로그가 2개가 나오게 됩니다. 하나는 오퍼레이션 시작을 로깅하는 operation.first=true 이고 다른 하나는 오퍼레이션의 완료를 의미하는 operation.last=true 로그 입니다.

만약 GCE 오퍼레이션에 의한 하나의 관리 활동 감사 로그만을 이벤트로 추출하려면 하단과 같이 필터에서 operation.last=”true” 를 추가하시면 됩니다.

protoPayload.request.@type="type.googleapis.com/compute.instances.insert"
operation.last="true"

#2) Log Sync 와 EventArc 를 통해 여러 프로젝트의 이벤트 통합을 위한 Central project 설정

기본적인 개념에 대해서 파트 #1 에서 이해를 했을거라고 보고 이제 실제 테스트해보려고 했던 아키텍처를 구현하는 작업을 해보도록 하겠습니다. 처음에 설명드린 것처럼 하단의 가이드의 아키텍처 형태를 테스트 해볼 예정이며 실제 기업내에 존재하는 여러 프로젝트를 의미하는 User projects 와 이런 여러 프로젝트들의 Audit Log 이벤트를 수집해서 비지니스 로직이나 감사와 같은 필요한 어떠한 액션을 수행하는 Central project 로 구성됩니다.

Route Cloud Audit Logs events across projects
https://cloud.google.com/eventarc/docs/cross-project-triggers#audit-logs-events

Project 1 — User projects(일반 프로젝트들 — 이벤트 발생)
Project 2 — Central project(여러 프로젝트들의 이벤트를 모아서 처리하는 프로젝트)

그럼 실제 아키텍처를 구현하기 위해서 Central project 를 하나 지정한 후에(또는, 만든 후에) 해당 프로젝트에서 설정 작업을 수행합니다.

처음으로 수행할 작업은 이벤트를 받고 감사나 필요한 어떠한 액션을 수행하는 Cloud Run 애플리케이션을 배포하는 것입니다. 본 아티클에서는 간단하게 받은 이벤트를 출력하는 샘플 애플리케이션을 활용하지만 Cloud Run 은 Serverless 형태로 Container 을 구동할 수 있기 때문에 그 안의 로직 변경을 통해서 원하는 작업을 수행할 수 있습니다.

Receive events using Pub/Sub messages (gcloud CLI)
https://cloud.google.com/eventarc/docs/run/pubsub#run-clone-sample-repository-nodejs

git clone https://github.com/GoogleCloudPlatform/nodejs-docs-samples.git

cd nodejs-docs-samples/eventarc/pubsub/

gcloud builds submit --tag gcr.io/$(gcloud config get-value project)/events-pubsub

gcloud run deploy helloworld-events-pubsub-tutorial \
--image gcr.io/$(gcloud config get-value project)/events-pubsub \
--allow-unauthenticated

정상적으로 Cloud Run 애플리케이션이 배포 되었다면 관리콘솔에서도 하단과 같이 확인할 수 있습니다.

다음으로 Pubsub 이벤트를 받을 수 있는 Eventarc trigger 를 생성합니다. 이때 Destination 은 방금전에 배포한 Cloud Run 을 지정합니다. (Eventarc 에 대한 좀 더 상세 내용은 이전의 아티클을 참고하시기 바라겠습니다. — [GCP]Serverless 서비스인 Cloud Run 알아보기 5부 — Eventarc 를 통한 이벤트 받기)

Route Cloud Pub/Sub events to Cloud Run
https://cloud.google.com/eventarc/docs/run/route-trigger-cloud-pubsub#gcloud

gcloud eventarc triggers create events-pubsub-trigger-001 \
--location=asia-northeast3 \
--destination-run-service=helloworld-events-pubsub-tutorial \
--destination-run-region=us-central1 \
--event-filters="type=google.cloud.pubsub.topic.v1.messagePublished"

정상적으로 생성되었다면 하단과 같이 관리콘솔에서도 생성된 EventArc 를 확인 가능합니다.

추가적으로 Pubsub 이벤트를 받도록 생성했기 때문에 자동으로 Pubsub Topic 도 생성된 것을 확인 가능합니다. (해당 Pubsub Topic 이름은 향후 활용할 것이기 때문에 기억해두시기 바라겠습니다.)

첨부 #2.1) 만약 현재까지 설정을 사전 테스트 해보고 싶다면 하단과 같이 gcloud 명령을 이용하여 생성된 Pubsub 으로 샘플 메세지를 보내서 확인 가능합니다.

export RUN_TOPIC=$(gcloud eventarc triggers describe events-pubsub-trigger-001 --location=asia-northeast3 \
--format='value(transport.pubsub.topic)')

gcloud pubsub topics publish $RUN_TOPIC --message "Runner"

EvenArc 설정이 정상적으로 되었다면 샘플 메시지를 Pubsub 으로 보내게 되면 하단과 같이 Cloud Run 의 log 에서 수행된 로그 메시지를 확인할 수 있어야 합니다.

#3) Log Sync 와 EventArc 를 통해 여러 프로젝트의 이벤트 통합을 위한 User project 설정

이전 파트에서 Central project 에 대한 EventArc 설정을 마무리했으면, 이제 실제적으로 이벤트를 수집할 User project 에 Log Sync 생성을 해야 합니다. 기 언급한 대로 Log Sync 를 통해서 이벤트 발생시 생성되는 Audit log 를 Central project 로 전달하는 구성을 할 예정입니다.

설정을 할 User project 로 이동한 후 특정 Audit log 를 다른 프로젝트의 Pubsub topic 으로 전달할 Log Sync 를 생성합니다. 참고로 log-filter 의 내용은 파트 #1 에서 언급한 필터를 사용했습니다.

gcloud logging sinks create cross-project-sink \
pubsub.googleapis.com/projects/jwlee-argolis-202104/topics/eventarc-asia-northeast3-events-pubsub-trigger-001-574 \
--log-filter='protoPayload.request.@type="type.googleapis.com/compute.instances.insert"
operation.last="true"'

Log Sync 가 정상적으로 생성되었다면 생성시에 하단과 같은 메시지를 확인할 수 있습니다. 특히, 결과를 보시면 아시겠지만 Log Sync 가 동작하기 위해서 사용되는 Service account 이름과 필요한 Role 이 언급되어 있습니다.

이 부분에 대해서 조금 상세 내용은 하단의 링크를 참고하시기 바라겠습니다.

Route logs to supported destinations
https://cloud.google.com/logging/docs/export/configure_export_v2#dest-auth

나온 메시지에 따라 Log Sync 동작을 위해서 Central project 에서 사용되는 Service account 에 필요한 Pubsub 권한을 주어야 합니다. 이를 위해서 관리콘솔의 상단의 프로젝트 네비게이터에서 Central project 로 이동한 후에 해당 프로젝트의 IAM 메뉴로 이동합니다.

해당 메뉴에서 Grant Access 아이콘을 클릭하여 하단과 같이 이전에 가이드 나온데로 해당 Service account 에 필요한 Pubsub 권한(Pub/Sub Publisher) 를 부여합니다.

여기까지 수행하셨다면 테스트를 위한 모든 설정은 잘 완료하신 것 입니다.

첨부 #3.1) 참고로 Logging sync 는 관리콘솔에서 하단과 같이 확인 가능합니다. (Logging > Log Router)

#4) Log Sync 와 EventArc 를 통해 여러 프로젝트의 이벤트 통합 구성 테스트 해보기

이전 파트까지 해서 Log Sync 와 EventArc 를 통한 여러 프로젝트의 이벤트 통합 구성 설정을 완료 하였으니 이제 실제 테스트를 통해서 해당 구성이 잘 동작하는지 확인해보도록 하겠습니다.

먼저 ‘User project’ 에서 테스트 목적으로 GCE(VM) 인스턴스를 하나 생성해보도록 하겠습니다.(해당 프로젝트에서 GCE 생성에 대한 Audit Log 가 나오는지 Log Explorer 에서 먼저 확인) 그리고 나서 ‘Central project’ 에서 구성된 아키텍처와 같이 생성된 Audit Log 가 Log Sync 를 통해서 EventArc 로 보내지고 해당 이벤트가 결국은 로직을 만들어 놓은 Cloud Run 에서 호출되는지 확인해 봅니다.

정상적으로 구성되었다면 하단과 같이 ‘Central project’ 의 Cloud Run 의 로그를 Log Explorer 에서 살펴봤을때 ‘User project’ 에서 만들어진 GCE 생성에 관련된 Audit Log 가 그대로 Cloud Run 의 출력으로 나오는 것을 확인할 수 있습니다.

첨부 #4.1) 만약, 하나의 user project 가 아니라 폴더레벨이나 조직레벨로 전체 프로젝트에 대한 Log Sync 를 구성해서 해당 작업을 수행하길 원한다면 해당 방식의 구성도 가능합니다. 상세 내용은 하단의 가이드를 참고하세요.

Collate and route organization-level logs to supported destinations
https://cloud.google.com/logging/docs/export/aggregated_sinks

첨부 #4.2) 참고로 Aggregated sink 를 생성할때 non-intercepting 나 intercepting 중에 사용자의 필요에 따라 옵션을 선택할 수 있게 업데이트 되었습니다. non-intercepting aggregated sink 는 이름 그대로 sync 를 설정한 프로젝트에서도 계속적으로 log 가 쌓여서 확인이 가능한 것을 의미하며 intercepting aggregated sink 는 설정한 프로젝트에서는 log 가 남지 않는 설정을 의미합니다.

Collate and route organization- and folder-level logs to supported destinations
https://cloud.google.com/logging/docs/export/aggregated_sinks

지금까지 제일 처음에 말씀드린 것처럼 Google cloud 프로젝트가 여러개 있는 경우에 관리와 거버넌스를 강화하는 차원에서 각 프로젝트에서 발생한 이벤트를 수집해서(예:GCE 인스턴스 생성/삭제 같은) 필요한 액션을 하거나 조치를 수행하는 아키텍처를 Cloud Audit Log 와 Log Sync, EventArc 를 통해서 구성하고 테스트 해봤습니다. 보셔서 아시겠지만 Google cloud 가 자체적으로 제공하는 기능을 통해서 손쉽게 구성이 가능하며 Audit Log 에는 다양한 이벤트들이 들어가 있으므로 이를 활용하게 되면 지금 말씀드린 방안과 다른 다양한 use case 도 쉽게 커버 가능하지 않을까 합니다.

그럼 여기까지해서 간만에 다시 진행한 Serverless 서비스인 Cloud Run 알아보기 10부 — Log Sync 와 EventArc 를 통한 여러 프로젝트의 이벤트 통합 방법에 대한 이야기는 마무리 하고 다음에 다시 더 좋은 이야기로 돌아오도록 하겠습니다. ^^&

Disclaimer: 본 글의 작성자는 Google 직원이지만 Google cloud 를 공부하는 한 개인으로서 작성된 글입니다. 본 글의 내용, 입장은 Google 을 대변하지 않으며 Google 이 해당 콘텐츠를 보장하지 않습니다.

참고 자료 #1

Route Cloud Audit Logs events across projects
https://cloud.google.com/eventarc/docs/cross-project-triggers#audit-logs-events

Cloud Audit Logs overview
https://cloud.google.com/logging/docs/audit

Compute Engine audit logging information
https://cloud.google.com/compute/docs/logging/audit-logging

How to create log sinks
https://youtu.be/3Wtbde9fB_Y

Enable Data Access audit logs
https://cloud.google.com/logging/docs/audit/configure-data-access

Receive events using Pub/Sub messages (gcloud CLI)
https://cloud.google.com/eventarc/docs/run/pubsub#run-clone-sample-repository-nodejs

Route Cloud Pub/Sub events to Cloud Run
https://cloud.google.com/eventarc/docs/run/route-trigger-cloud-pubsub#gcloud

Route logs to supported destinations
https://cloud.google.com/logging/docs/export/configure_export_v2#dest-auth

Collate and route organization- and folder-level logs to supported destinations
https://cloud.google.com/logging/docs/export/aggregated_sinks

--

--

이정운 (Jungwoon Lee)
google-cloud-apac

Technical engineer who dreams better future. (These thoughts are my own personal opinions, and do not reflect or represent Google’s opinions or plans.)