Athena로 CloudWatch Logs의 로그를 쉽게 분석

Athena의 Federated Query를 사용하여 CloudWatch Logs에 저장된 로그를 가장 적은 시간에 분석하는 방법과 이를 위한 로그 흐름 설계 노하우를 소개합니다.

의 목적

CloudWatch Logs는 로그를 저장하기 위한 간단하고 좋은 서비스입니다.
예를 들어 내가 현재 종사하고 있는 제품 중에서 조작 로그와 일괄 처리의 집행 로그 등은 건수가 많아지기 때문에 참고 빈도가 낮은 제품은 먼저 클라우드워치 로그에 넣는다.
클라우드워치 로그는 구축·실장·운용에 드는 비용이 낮아 가져오기 쉽지만, 한편으로는 단일 분석이 어려워 아테나 등을 활용해 유연하게 조회를 쓰려고 한다.
그러나 Athena가 조회할 수 있도록 모든 로그를 S3에 지속적으로 출력하는 메커니즘을 구축하려면 구축 과정에서 걸리는 시간과 조작에 걸리는 비용이 같지 않다.
Athena의 Federated Query를 사용하여 구축과 운용에 시간이 걸리지 않고 필요할 때 유연한 조회 분석 방법과 Athena에서 분석하기에 적합한 기록 흐름 디자인 예를 소개한다.

Federated Query 란 무엇입니까?

Athena Query Engine 버전 2에서는 Federated Query 기능을 사용할 수 있습니다.
이는 Athena를 S3 이외의 RDB, NoSQL, 기타 서비스 등과 연결해 S3 데이터와 마찬가지로 Athena에서 분석하는 기능이다.
애더나와 목적지를 연결하는 서비스를 이용하기 위해서는 연결 커넥터로 불리는 람바다를 준비해야 하고, 클라우드워치 등은 콘솔에서 조금만 조작해도 설정을 완료할 수 있는 정식 커넥터를 제공한다.
Federated Query

view

를 구축할 수 없음

write 동작을 할 수 없음

등 제한이 있지만 주파수가 낮은 로그의 특정 분석 용도는 충분하다.

Federated Query 구성

자세한 설정 방법은 생략했지만 Athena 콘솔의 데이터 원본 화면에서 '데이터 원본 연결' 을 누르면 연결부에서 선택Amazon CloudWatch Logs하면 설정할 수 있다.
기본적으로 화면에 따라 몇 가지 필요한 사항을 입력하면 설정을 완성할 수 있다.

CloudWatch Logs 데이터 소스

설정이 완료되면 Athena에서 새로운 데이터 원본을 사용할 수 있을 것입니다.
데이터 원본에서

CloudWatch Logs의 각 로그 그룹에 대한 데이터베이스

로그 그룹 내의 모든 로그 흐름의 표

준비 완료.

all_log_streams 테이블

모든 로그 흐름의 표를 제외하고 로그 그룹에 접근하는 모든 로그 흐름 all_log_streams 을 가로지르는 특수한 데이터 섹션을 만들었습니다.
내가 분석하고 싶은 기록 흐름이 하나로 확정되지 않을 때가 많기 때문에 주로 all_log_streams표를 사용한다.

테이블 정보 작성

작성된 테이블에는 다음과 같은 세 열이 있습니다.

log_stream: 로그 흐름 이름

time : unixtime

메시지: 로그에 기록된 메시지

타임의 비트가 많기 때문에 처리하기 어려워서 함수에 직접 맡기면 정확한 날짜와 시간으로 바꿀 수 없습니다.

from_unixtime(time / 1000.0, 'Asia/Tokyo')

처럼 1000을 나누면 정확한 날짜와 시간을 얻을 수 있다.

질의 작성 팁

JSON 정보의 분석

Federated Query로 작성된 from_unixtime 열은 문자열로만 처리됩니다. CloudWatch Logis 정보에 JSON이 저장되어 있으면 message 함수 등 JSON 조작 함수를 사용하여 자세히 분석할 수 있습니다.
예를 들어,

{
  "Foo": {
    "Bar": {
      "field1": 100
    }
  }
}

와 같은 json 문자열이 메시지 열에 저장된 경우json_extract의 값
누르다
Athena의 JSON 처리에 대한 자세한 내용은 공식 문서에 적혀 있습니다.

로그 흐름 잠금

Federated Query로 작성된 테이블은 field1 열에서 구분됩니다.log_stream 표에서 여러 개의 로그 흐름을 횡단 분석한 경우에도 로그 흐름의 이름을 적절하게 지정하여 스캔량과 실행 시간을 최소화할 수 있다.

ULID를 사용한 Athena 친선 로그 흐름 설계

로그 스트림을 잠글 때 GUID와 같은 전체 임의의 로그 스트림 이름을 사용하는 경우 모든 로그 스트림 이름을 나열해야 합니다.
만약 필요한 로그 흐름의 범위가 매우 넓다면, 이러한 무작위 로그 흐름의 이름은 불편할 수 있습니다.
로그 분석을 할 때 대상으로서의 기간은 대부분 고정되어 있다. 이러한 용도에서 로그 흐름의 이름의 유일성을 확보하고 시간 순서에 따라 정렬할 수 있다면 로그 흐름을 잠그기 쉬워 매우 편리하다.
이런 용도ULID는 매우 편리하다.
ULID는'시간순으로 정렬할 수 있는 무작위 128비트의 ID'다. ULID는 상위 48비트에 타임 스탬프를 저장하고 나머지는 무작위 비트레이트로 구성된다.
따라서 ULID를 사용하면 정렬 가능한 ID를 쉽게 만들 수 있습니다.
ULID의 구현은 여러 언어로 이루어지는데 저는 C#에서 사용합니다CySharp 기반 설치.
로그 스트림 이름에 base 64 인코딩된 ULID를 사용하는 경우

분석하고자 하는 기간의 최초 로그 흐름 이름은all_log_streams

분석할 기간의 마지막 로그 흐름 이름은AXveDqLXTQBeH+xaUtnLKQ==

의 경우 Athena 질의의 WHERE 문에서
지정

json_extract(message, '$.Foo.Bar.field1')

등 로그 흐름의 범위를 간단하게 지정할 수 있습니다.

총결산

Athena로 클라우드워치 로그에 저장된 로그를 간단하게 분석하는 방법을 소개했다.
주요 사항:

Athena의 Federated Query에서 ClodWatch Logs의 데이터는 Athena가 직접 처리할 수 있음

JSON 문자열은 AXwXnfcfH+EoOyVHDjDdsA== 등 함수를 통해 분석할 수 있다

로그 흐름 이름에 정렬 가능한 ULID 등을 사용하면 편리하다

내 제품은 최근에야 이 메커니즘을 도입했는데 운용상의 과제를 찾을 수 있다면 다시 한 번 추모하고 싶다.