Cloud Logging

Cloud Logging 은 구글 클라우드에서 돌아가는 것들이 남긴 기록을 한곳에 모아 주는 서비스입니다. 서버에 직접 들어가 파일을 뒤지지 않아도 브라우저 화면에서 찾아봅니다. 모인 기록을 얼마나 오래 둘지, 어디로 더 흘려보낼지도 이 서비스가 정합니다.

쉽고 빠른 이해

Cloud Logging 은 여러 서버와 서비스가 남긴 기록을 한 통에 모아 검색하게 해 주는 서비스입니다. 결제가 실패한 시각만 알면 그 몇 초 사이에 어느 서비스가 무슨 오류를 냈는지 한 화면에서 훑습니다.

기록이 기계마다 파일로 흩어져 있으면 장애 하나를 좇는 데 서버 여러 대를 돌아다녀야 합니다. 게다가 기계가 사라지면 그 안의 파일도 같이 사라집니다.

어떻게 도는가:

클라우드 서비스와 수집 프로그램이 기록을 한 건씩 보냅니다
들어온 기록을 규칙에 따라 보관 통이나 다른 저장소로 나눠 보냅니다
쌓인 기록을 조건을 걸어 찾아봅니다
자주 찾는 조건은 숫자로 바꿔 경보에 씁니다

대가가 있습니다. 받아들인 양만큼 값이 매겨져서 기록을 헤프게 남기면 비용이 빠르게 큽니다. 보관 기간이 지난 기록은 지워집니다. 보내고 찾는 방식이 구글 클라우드에 맞춰져 있어 다른 곳으로 옮기려면 수집 경로를 새로 짜야 합니다.

상세

프로그램은 무슨 일을 했는지를 한 줄씩 남깁니다. 이 기록을 로그라고 부릅니다. Cloud Logging 은 그 로그를 받아 저장하고 찾아 주는 관리형 서비스입니다. 쓰는 쪽이 설치하거나 서버를 띄울 것이 없고, 구글 클라우드 계정 안에 이미 켜져 있습니다.

이런 서비스가 필요해진 까닭은 로그가 원래 기계에 붙어 있기 때문입니다. 서버 한 대 시절에는 그 기계의 파일을 열면 끝이었습니다. 서비스가 여러 대에 나뉘고 요청 하나가 그중 몇 대를 거치게 되면서, 한 건의 장애를 좇는 데 기계를 돌아다녀야 하는 일이 됐습니다.

기계가 오래 살지 않는 것도 이유입니다. 부하에 따라 늘었다 줄고 배포할 때마다 갈리는 환경에서는 기계가 사라질 때 그 안의 파일도 같이 사라집니다. 그래서 로그를 기계 밖으로 내보내 따로 모아 두는 쪽으로 갑니다.

이름이 한 번 바뀐 물건입니다. 예전에는 Stackdriver Logging 이라고 불렀고, 구글 클라우드로 들어오면서 지금 이름이 됐습니다.

아래는 로그 한 건이 어떻게 생겼는지부터 시작해 그것이 들어오는 길, 갈라지는 지점, 쌓이는 통, 찾는 방법 순으로 따라갑니다. 마지막에 이 서비스가 포기한 것을 봅니다.

로그 한 건의 생김새

Cloud Logging 이 다루는 단위는 파일이 아니라 로그 항목 한 건입니다. 텍스트 파일을 줄 단위로 읽는 것이 아니라, 칸이 정해진 기록 하나하나를 받습니다. 이렇게 칸을 나눠 남기는 방식을 구조화 로그라고 합니다.

칸	담는 것
시각	그 일이 일어난 때
심각도	정보 · 경고 · 오류처럼 급한 정도
자원	어느 가상 머신 · 어느 컨테이너 · 어느 함수가 남겼나
로그 이름	성격이 같은 기록을 묶는 이름
내용	남긴 본문. 한 줄 글이거나 키와 값의 묶음
라벨	나중에 걸러 내려고 붙이는 꼬리표

칸이 나뉘어 있어서 「오류만」 · 「이 서비스의 것만」 같은 조건이 문자열 뒤지기가 아니라 칸 비교가 됩니다. 본문만 텍스트로 남기면 그런 조건을 걸 수 없습니다. 그래서 애플리케이션이 로그를 남길 때 본문을 키와 값의 묶음으로 적는 편이 뒤에 찾기 쉽습니다.

로그가 들어오는 길

로그가 이 서비스에 닿는 경로는 누가 보내느냐로 갈립니다. 클라우드가 알아서 보내는 것, 기계에 얹은 프로그램이 보내는 것, 애플리케이션이 스스로 보내는 것입니다.

첫째, 구글 클라우드 서비스가 스스로 보냅니다. 부하 분산기가 받은 요청, 서버를 직접 띄우지 않고 함수만 올려 두는 서버리스 실행 기록, 누가 무슨 설정을 바꿨는지를 남기는 감사 로그가 여기 해당합니다.

둘째, 가상 머신 안에 수집 프로그램을 띄워 보냅니다. 이 프로그램을 에이전트라고 부릅니다. 에이전트는 기계 안의 로그 파일과 시스템 로그를 지켜보다가 새 줄이 생기면 밖으로 보냅니다.

셋째, 애플리케이션이 직접 보냅니다. 각 언어의 클라이언트 라이브러리가 로그 항목을 만들어 넘깁니다. 표준 출력에 찍기만 해도 실행 환경이 대신 걷어 가는 경우가 많아서, 직접 보내는 길을 안 쓰고도 로그가 모입니다.

로그 라우터와 싱크

들어온 로그는 곧장 저장되지 않습니다. 로그 라우터라는 한 지점을 반드시 지나고, 라우터가 어디로 보낼지 정합니다. 목적지 하나하나를 싱크라고 부릅니다.

flowchart TD
    A["구글 클라우드 서비스"] --> R
    B["가상 머신 안의 에이전트"] --> R
    C["직접 보내는 애플리케이션"] --> R
    R["로그 라우터"] --> D["로그 버킷"]
    R --> E["오브젝트 스토리지"]
    R --> F["데이터 웨어하우스"]
    R --> G["메시지 큐"]

싱크마다 조건식을 답니다. 조건에 맞는 로그만 그 목적지로 갑니다. 그래서 같은 로그 한 건이 여러 목적지에 동시에 복사되기도 하고, 어느 목적지에도 안 가기도 합니다.

목적지는 성격이 다릅니다. 검색해 볼 로그는 이 서비스 안의 로그 버킷에 담습니다. 오래 싸게 두기만 할 로그는 오브젝트 스토리지인 Cloud Storage 로 보냅니다. 표로 놓고 집계할 로그는 데이터 웨어하우스인 BigQuery 로, 다른 시스템이 실시간으로 받아 가야 할 로그는 메시지 큐인 Pub/Sub 으로 보냅니다.

라우터에는 버리는 규칙도 답니다. 제외 조건에 걸린 로그는 저장되지 않고 값도 안 매겨집니다. 서버가 살아 있는지 몇 초마다 확인하는 요청은 성공 기록만 끝없이 쌓이는데, 그런 로그를 여기서 떨어내는 것이 비용을 줄이는 첫 손질입니다.

로그 버킷과 보존 기간

로그 버킷은 이 서비스 안에서 로그를 담는 통입니다. 프로젝트마다 기본 통이 하나 서 있고, 따로 만들지 않아도 로그가 거기 쌓입니다. 통마다 보존 기간을 정하고, 기간이 지난 로그는 지워집니다.

감사 로그 가운데 설정 변경 기록은 별도의 통에 따로 담깁니다. 이 통은 지울 수도, 보존 기간을 줄일 수도 없습니다. 사고가 났을 때 「누가 무엇을 바꿨나」를 지운 흔적까지 포함해 남겨 두려는 설계입니다.

보존 기간은 값과 직결됩니다. 기본 기간을 넘겨 오래 두면 그만큼 보관 값이 붙습니다. 그래서 오래 둘 로그는 버킷 기간을 늘리는 대신 오브젝트 스토리지 싱크로 빼는 선택을 자주 합니다.

조건을 걸어 찾는 질의

쌓인 로그는 로그 탐색기라는 화면에서 찾습니다. 질의는 칸 비교를 늘어놓는 꼴입니다. 「자원 종류가 이것이고 심각도가 오류 이상이며 라벨의 서비스 이름이 저것인 것」처럼 조건을 겹쳐 범위를 좁힙니다.

시간 범위를 먼저 좁히는 것이 요령입니다. 이 서비스는 낱말 하나로 전체를 뒤지는 전문 검색 엔진이 아니라, 시각과 자원으로 구간을 자른 뒤 그 안을 보는 쪽에 맞춰져 있습니다. 범위를 안 자르고 본문 낱말만 던지면 느리고 값도 많이 듭니다.

표로 놓고 집계해야 하는 질문은 질의로는 답이 안 나옵니다. 「하루 동안 오류가 어느 사용자에게 몰렸나」 같은 것입니다. 이럴 때는 버킷을 분석용으로 켜서 SQL(Structured Query Language, 구조화 질의 언어)로 조회하거나, 아예 데이터 웨어하우스 싱크로 빼서 거기서 집계합니다.

로그에서 뽑아내는 지표

같은 질의를 매번 돌리는 대신 로그 기반 지표를 세워 둡니다. 조건에 맞는 로그가 들어올 때마다 수를 세거나 값의 분포를 쌓는 숫자입니다. 로그가 문장에서 숫자로 바뀌는 지점입니다.

숫자가 되면 모니터링 쪽으로 넘어갑니다. 「오류 로그가 분당 몇 건을 넘으면 알린다」 같은 경보를 걸고, 그래프로 추세를 봅니다. 사람이 로그를 계속 들여다보지 않아도 이상이 있을 때 먼저 연락이 옵니다.

지표는 로그 본문을 안 갖고 있습니다. 「몇 건이 났나」만 알려 주고 「무슨 내용이었나」는 안 알려 줍니다. 그래서 경보로 알아채고 로그 탐색기로 내려가 원문을 보는 순서로 씁니다.

포기한 것

검색 엔진이 아닙니다. 낱말이 얼마나 잘 맞는지로 순위를 매기지 않고, 조건에 맞는 것을 시간 순으로 돌려줍니다. 사람이 시각과 자원을 알고 들어온다는 전제 위에 서 있습니다.

받아들인 양으로 값을 매깁니다. 그래서 「일단 다 남기고 나중에 본다」가 통하지 않습니다. 무엇을 안 남길지, 무엇을 라우터에서 떨어낼지 정하는 일이 운영의 한 축이 됩니다.

순서를 보장하지 않습니다. 로그는 여러 기계에서 제각각 올라오고, 늦게 도착한 항목이 뒤늦게 끼어듭니다. 시각 칸으로 정렬해 봐도 밀리초 단위 앞뒤는 믿을 것이 못 됩니다. 인과를 따져야 하면 분산 추적처럼 요청 하나에 꼬리표를 달아 잇는 도구를 따로 씁니다.

항목 크기에 상한이 있습니다. 큰 본문을 통째로 실으면 잘립니다. 덩치 큰 요청 본문이나 응답 전문을 로그에 그대로 넣는 방식은 여기서 막힙니다.

구글 클라우드에 맞춰져 있습니다. 다른 클라우드나 자체 기계의 로그도 보낼 수 있지만 수집 경로를 직접 짜야 합니다. 싱크 설정과 질의 문법이 이 서비스의 것이라서 나중에 옮기려면 그 부분을 다시 만듭니다.

Cloud Logging

상세

로그 한 건의 생김새

로그가 들어오는 길

로그 라우터와 싱크

로그 버킷과 보존 기간

조건을 걸어 찾는 질의

로그에서 뽑아내는 지표

포기한 것

관련 항목

Cloud Logging 이 담고 다루는 기록의 종류

Cloud Logging 을 이루는 구성 요소

Cloud Logging 이 로그를 넘겨 주는 저장소

Cloud Logging 으로 로그를 보내는 수집 도구

Cloud Logging 과 같은 역할을 두고 겨루는 로그 서비스

Cloud Logging 이 로그를 넘겨 이어 가는 관측 기능

Cloud Logging 이 로그를 받아 오는 실행 환경

Cloud Logging 이 속하는 상위 분류

Cloud Logging 을 다룰 때 같이 정하는 운영 규칙