이 참조 아키텍처에서는 이전에 Cloud Storage로 내보낸 로그를 다시 Cloud Logging으로 가져오는 방법을 설명합니다.
이 참조 아키텍처는 로그 가져오기 작업을 구성하고 실행하려는 DevOps, 사이트 안정성 엔지니어(SRE), 보안 조사 담당자를 포함한 엔지니어 및 개발자를 대상으로 합니다. 이 문서에서는 사용자가 Cloud Run 작업 실행, Cloud Storage 및 Cloud Logging 사용 방법에 익숙하다고 가정합니다.
아키텍처
다음 다이어그램은 Google Cloud 서비스가 이 참조 아키텍처에 사용된 방법을 보여줍니다.
이 워크플로에는 다음 구성요소가 포함됩니다.
- Cloud Storage 버킷: Cloud Logging으로 다시 가져오려는 이전에 내보낸 로그를 포함합니다. 이러한 로그는 이전에 내보낸 것이기 때문에 예상되는 내보내기 형식으로 구성되어 있습니다.
- Cloud Run 작업: 로그 가져오기 프로세스를 실행합니다.
- Cloud Storage에서 로그 항목을 저장하는 객체를 읽습니다.
- Cloud Storage 버킷의 내보낸 로그 구성에 따라 요청된 기간에 지정된 로그 ID의 내보낸 로그를 찾습니다.
- 객체를 Cloud Logging API
LogEntry구조로 변환합니다. 여러LogEntry구조가 배치로 집계되어 Cloud Logging API 할당량 소비를 줄여줍니다. 필요한 경우 아키텍처가 할당량 오류를 처리합니다. - 변환된 로그 항목을 Cloud Logging에 기록합니다. 동일한 작업을 여러 번 다시 실행하면 중복 항목이 발생할 수 있습니다. 자세한 내용은 가져오기 작업 실행을 참조하세요.
- Cloud Logging: 변환된 로그 항목을 수집하고 저장합니다.
로그 항목은 라우팅 및 스토리지 개요에 설명된 대로 처리됩니다.
- Cloud Logging API 할당량 및 한도와 30일 보관 기간을 포함하여 Logging 할당량 및 한도가 적용됩니다. 이 참조 아키텍처는 기본 재시도 메커니즘과 함께 기본 쓰기 할당량으로 작동하도록 설계되었습니다. 쓰기 할당량이 기본값보다 낮으면 구현이 실패할 수 있습니다.
- 타임스탬프가 과거 시간이기 때문에 가져온 로그가 로그 기반 측정항목에 포함되지 않습니다. 하지만 라벨을 사용하도록 선택한 경우 타임스탬프가 가져오기 시간을 기록하고 로그가 측정항목 데이터에 포함됩니다.
- BigQuery: SQL을 사용해서 가져온 로그에 대해 분석 쿼리를 실행합니다(선택사항). Cloud Storage에서 감사 로그를 가져오기 위해 이 아키텍처는 로그 ID를 수정합니다. 가져온 로그를 쿼리할 때 이러한 이름 바꾸기를 고려해야 합니다.
사용 사례
조직에서 이슈 조사 또는 과거 이벤트에 대한 기타 감사를 위해 추가 로그 분석이 필요한 경우 이 아키텍처를 배포하도록 선택할 수 있습니다. 예를 들어 데이터베이스 액세스 감사의 일부로 지난 해 첫 번째 분기에 데이터베이스에 대한 연결을 분석해야 할 수 있습니다.
설계 대안
이 섹션에서는 이 참조 아키텍처 문서에 표시된 기본 설계의 대안을 설명합니다.
보관 기간 및 가져온 로그
Cloud Logging은 30일 보관 기간을 초과하지 않는 타임스탬프를 사용하기 위해 수신 로그 항목이 필요합니다. 타임스탬프가 가져오기 시간보다 30일이 넘는 가져온 로그 항목은 저장되지 않습니다.
이 아키텍처는 1일을 안전 기간으로 남겨두고 29일보다 오래된 가져오기 로그를 방지하기 위해 Cloud Run 작업에 설정된 날짜 범위를 검증합니다.
29일보다 오래된 로그를 가져오려면 구현 코드에 다음 변경사항을 수행한 후 Cloud Run 작업 구성에서 사용할 새 컨테이너 이미지를 빌드합니다.
- 날짜 범위의 30일 검증 삭제
- 원래 타임스탬프를 로그 항목에 사용자 라벨로 추가
- 현재 타임스탬프 내에서 수집되도록 로그 항목의 타임스탬프 라벨 재설정
이 수정을 사용할 때는 로그 애널리틱스 쿼리에서 timestamp 필드 대신 labels 필드를 사용해야 합니다. 로그 애널리틱스 쿼리 및 샘플에 대한 자세한 내용은 샘플 SQL 쿼리를 참조하세요.
설계 고려사항
다음 가이드라인은 조직 요구사항을 충족하는 아키텍처를 개발하는 데 도움이 될 수 있습니다.
비용 최적화
이 참조 아키텍처를 사용하여 로그를 가져오는 비용은 여러 요소의 영향을 받습니다.
다음과 같은 청구 가능한 Google Cloud 구성요소를 사용합니다.
비용을 증가시킬 수 있는 다음 요소를 고려하세요.
- 로그 중복: 추가적인 로그 스토리지 비용을 방지하기 위해서는 동일한 구성을 여러 번 사용해서 가져오기 작업을 실행하지 마세요.
- 추가 대상의 스토리지: 추가 로그 스토리지 비용을 방지하려면 대상 프로젝트에서 라우팅 정책을 사용 중지하여 추가 위치에서 로그 스토리지 또는 Pub/Sub 또는 BigQuery와 같은 다른 대상으로 로그 전달을 방지합니다.
- 추가 CPU 및 메모리: 가져오기 작업이 시간 초과되면 가져오기 작업 구성에서 가져오기 작업 CPU 및 메모리를 늘려야 할 수 있습니다. 이 값을 늘리면 발생하는 Cloud Run 비용이 늘어날 수 있습니다.
- 추가 태스크: 시간 범위 내에 매일 가져오는 예상 로그 수가 높으면 가져오기 작업 구성에서 태스크 수를 늘려야 할 수 있습니다. 이 작업은 태스크 간에 동일하게 기간을 분할하므로 각 태스크가 범위에서 동시에 비슷한 일 수를 처리합니다. 태스크 수를 늘리면 발생하는 Cloud Run 비용이 늘어날 수 있습니다.
- 스토리지 클래스: Cloud Storage 버킷의 스토리지 클래스가 Nearline, Durable Reduced Availability(DRA), Coldline과 같이 표준이 아니면 추가 비용이 발생할 수 있습니다.
- 다른 위치 간 데이터 트래픽: 로그를 가져오는 Cloud Storage 버킷과 동일한 위치에서 실행되도록 가져오기 작업을 구성합니다. 그렇지 않으면 네트워크 이그레스 비용이 발생할 수 있습니다.
Cloud Run 작업을 포함하여 예상 사용량을 기준으로 예상 비용을 산출하려면 가격 계산를 사용합니다.
운영 효율성
이 섹션에서는 솔루션 배포 후 분석 쿼리 관리를 위한 고려사항에 대해 설명합니다.
로그 이름 및 쿼리
로그는 로그 항목의 logName 필드에 정의된 프로젝트에 저장됩니다. 선택한 프로젝트에 로그를 가져오기 위해 이 아키텍처는 각 가져온 로그의 logName 필드를 수정합니다. 가져오기 로그는 로그 ID가 imported_logs인 선택한 프로젝트의 기본 로그 버킷에 저장됩니다(프로젝트에 스토리지 대상을 변경하는 로그 라우팅 정책이 없는 경우).
logName 필드의 원래 값은 original_logName 키를 사용해서 labels 필드에 보관됩니다.
가져온 로그를 쿼리할 때 원래 logName 값의 위치를 고려해야 합니다. 로그 애널리틱스 쿼리 및 샘플에 대한 자세한 내용은 샘플 SQL 쿼리를 참조하세요.
성능 최적화
가져오는 로그 볼륨이 Cloud Run 용량 한도를 초과하면 가져오기가 완료되기 전에 작업이 시간 초과될 수 있습니다. 불완전한 데이터 가져오기를 방지하기 위해서는 가져오기 작업에서 tasks 값을 늘려보세요. 또한 CPU 및 메모리 리소스를 늘리면 태스크 수를 늘릴 때 태스크 성능을 향상하는 데 도움이 됩니다.
배포
이 아키텍처를 배포하려면 Cloud Storage에서 Cloud Logging에 로그를 가져오는 작업 배포를 참조하세요.
다음 단계
- GitHub 저장소에서 구현 코드 검토
- 로그 애널리틱스 및 SQL을 사용하여 가져온 로그를 분석하는 방법 알아보기
- 그 밖의 참조 아키텍처, 다이어그램, 튜토리얼, 권장사항을 알아보려면 클라우드 아키텍처 센터를 확인하세요.
참여자
저자: 레오니드 얀쿨린 | 개발자 관계 엔지니어
기타 참여자: