관측성 백엔드

관측성 백엔드는 서비스들이 내보낸 기록을 받아 쌓아 둡니다. 사람이 그 기록을 뒤져 볼 수 있게 해 줍니다. 장애가 나면 개발자는 이 서버에 물어서 그때 무슨 일이 있었는지 되짚습니다. 한 제품의 이름이 아니라 이 일을 맡은 서버들을 통틀어 부르는 말입니다.

쉽고 빠른 이해

관측성 백엔드는 서비스가 보낸 기록을 모아 두었다가 물으면 찾아 줍니다. 결제 서비스가 요청마다 걸린 시간을 보내 두면, 나중에 「지난 한 시간 동안 실패한 결제가 몇 건인가」를 이 서버에 물어볼 수 있습니다.

이것이 없으면 기록이 서버마다 흩어져 있습니다. 서버마다 하나씩 들어가 파일을 열어 봐야 합니다. 서버가 사라지면 기록도 같이 사라집니다.

어떻게 도는가:

1. 서비스가 보내는 기록을 받습니다
2. 종류에 맞는 모양으로 저장하고, 오래된 것은 줄이거나 지웁니다
3. 사람이 물으면 찾아서 답하고, 그래프를 그리고, 값이 이상하면 알림을 보냅니다

대가도 있습니다. 기록은 매 순간 쌓이므로 저장 비용이 계속 늘어납니다. 백엔드도 돌보아야 할 시스템이라, 멈추면 지켜보는 눈도 같이 감깁니다.

서버 한 대에서 서비스 하나가 돈다면 로그 파일을 열어 보는 것으로 충분합니다. 서버가 여러 대로 늘어 요청 하나가 서비스 여럿을 지나기 시작하면 백엔드가 필요해집니다.

상세

병원의 의무기록실을 떠올려 봅시다. 여러 진료과의 의사가 환자를 볼 때마다 진료 기록을 남깁니다. 그 기록은 한 방에 모여 환자 번호와 날짜별로 정리됩니다. 몇 달 뒤 다른 의사가 같은 환자를 보면 의무기록실에서 지난 기록을 꺼내 읽습니다.

관측성 백엔드는 서비스가 보낸 기록을 받아 저장하고, 사람이 묻는 것을 찾아 주는 서버 쪽 시스템입니다. 결제 서비스가 요청마다 걸린 시간과 성공 여부를 보낸다고 해 봅시다. 백엔드는 그것을 쌓아 두었다가 「지난 한 시간 동안 실패한 결제」를 물으면 골라서 보여 줍니다.

서비스가 보내는 이 기록을 텔레메트리라고 부릅니다. 돌아가는 프로그램이 자기 상태를 스스로 적어 밖으로 내보내는 데이터입니다. 서버에 들어가 보지 않고도 안에서 무슨 일이 나는지 알려고 내보냅니다.

이름 앞머리의 관측성은 밖으로 나온 기록만 보고 시스템 안을 얼마나 알아낼 수 있는가 하는 성질입니다. 관측성 백엔드는 그 성질을 쓸 수 있게 기록을 받아 두는 쪽입니다. 「백엔드」는 기록을 만들어 보내는 쪽 뒤에 서서 받는 서버라는 뜻입니다.

사용자 요청을 처리하는 애플리케이션 서버도 흔히 백엔드라고 부릅니다. 그 서버는 이 이야기에서 기록을 보내는 쪽입니다. 둘을 헷갈리지 않도록 이 항목에서는 받는 쪽만 백엔드라고 부릅니다.

기록이 백엔드에 닿는 길

기록은 서비스에서 곧장 백엔드로 가기도 하고, 중간을 한 번 거치기도 합니다. 이 소절은 그 길을 따라가며 백엔드가 어디에 서는지 봅니다.

출발점은 계측입니다. 코드 안에 기록을 내보내는 부분을 심어 두는 일입니다. 심어 둔 곳에서만 기록이 나오므로, 백엔드는 계측이 보낸 것만 받을 수 있습니다.

중간에는 흔히 수집기가 섭니다. 여러 서비스의 기록을 받아 묶고 거른 뒤 백엔드로 넘기는 중간 프로그램입니다. 서비스는 수집기 주소 하나만 알면 됩니다. 백엔드를 바꾸는 일은 수집기 설정에서 끝납니다.

flowchart TD
    S["서비스들"] -->|계측이 내보냄| C["수집기"]
    S -.->|곧장 보내기도| R
    subgraph BE["관측성 백엔드"]
        R["받기"] --> W["저장"]
        W --> Q["조회"]
    end
    C --> R
    Q --> V["화면"]
    Q --> N["알림"]

그림의 가운데 상자가 관측성 백엔드입니다. 받고, 저장하고, 물으면 찾아 답합니다. 찾은 결과는 사람이 보는 화면이 되기도 하고, 값이 선을 넘으면 알림이 되기도 합니다.

백엔드가 맡는 네 가지 일

백엔드의 일은 넷으로 나뉩니다. 넷 중 하나라도 빠지면 기록은 있어도 쓸 수 없습니다.

받기는 무거운 일입니다. 서비스 수십 개가 쉬지 않고 기록을 보내므로, 백엔드는 읽는 일보다 쓰는 일을 훨씬 많이 합니다. 장애가 없는 날의 기록은 대개 아무도 다시 읽지 않습니다.

그래서 저장은 쓰기를 싸게 하는 쪽으로 짜입니다. 들어온 순서대로 뒤에 붙여 쓰고, 여러 건을 묶어 압축합니다. 대신 찾을 때는 묶음을 풀어 훑어야 하므로 할 일이 늘어납니다.

조회에는 꼬리표가 쓰입니다. 꼬리표는 기록마다 붙은 이름표입니다. 「서비스=결제」나 「응답 코드=500」 같은 것입니다. 조회할 때 이 이름표로 기록을 골라냅니다.

사람은 백엔드에 전용 쿼리 언어로 묻습니다. 「결제 서비스의, 지난 한 시간의, 응답 코드 500」처럼 이름과 시간 범위와 꼬리표로 범위를 좁혀 나갑니다.

조회 결과를 그래프 여러 장으로 한 화면에 늘어놓은 것이 대시보드입니다. 사람이 들여다볼 때 씁니다.

알림은 사람이 안 볼 때를 맡습니다. 정해 둔 조회를 주기마다 저절로 돌리고, 값이 정해 둔 선을 넘으면 담당자에게 메시지를 보냅니다.

신호마다 다른 저장 방식

백엔드가 받는 기록은 크게 세 가지입니다. 이 셋을 흔히 신호라고 부릅니다. 한 건의 모양도, 주로 받는 물음도 달라서 저장하는 방식이 갈립니다.

메트릭은 숫자라서 시간 순서로 늘어놓으면 됩니다. 이름과 꼬리표가 같은 값들을 한 줄로 묶고, 그 줄 끝에 시각과 숫자를 계속 덧붙입니다. 이 한 줄을 시계열이라고 부릅니다.

시계열을 담는 데 맞춘 저장소가 시계열 데이터베이스입니다. 이웃한 값끼리 차이가 작아 압축이 잘 됩니다. 시간 범위로 잘라 읽기도 빠릅니다.

로그는 글이라서 찾는 방법이 둘로 갈립니다. 한쪽은 낱말마다 그 낱말이 나오는 줄을 적어 둔 색인을 만듭니다. 이 색인을 역색인이라고 부릅니다. 어떤 낱말로 찾아도 빨리 나옵니다. 대신 색인이 커집니다. 기록이 들어올 때마다 색인을 고쳐야 합니다.

다른 쪽은 꼬리표에만 색인을 걸고 본문은 압축해 묶어 둡니다. 찾을 때는 꼬리표로 범위를 좁힌 뒤 그 안을 처음부터 훑습니다. 저장은 싸지만 범위가 넓으면 훑을 양이 늘어 검색이 오래 걸립니다.

트레이스는 조각으로 들어옵니다. 서비스 하나가 요청을 처리한 한 구간을 스팬이라고 부릅니다. 스팬은 저마다 다른 서비스에서 따로 도착합니다.

스팬마다 같은 요청을 가리키는 번호가 붙어 있습니다. 이 번호를 트레이스 ID(identifier, 식별자)라고 부릅니다. 백엔드는 같은 번호의 스팬을 모아 요청 하나가 거쳐 간 길을 다시 맞춥니다.

세 신호를 잇는 꼬리표

장애를 좇을 때는 세 신호를 오가게 됩니다. 이 소절은 그 오가기가 무엇에 기대는지 봅니다.

순서는 대개 이렇습니다. 메트릭으로 언제부터 응답이 늦어졌는지 찾고, 그 시간대의 트레이스로 어느 구간에서 시간이 걸렸는지 찾습니다. 그 구간의 로그로 무슨 일이 있었는지 읽습니다.

오가려면 세 신호가 같은 꼬리표를 써야 합니다. 서비스 이름이 메트릭에서는 order, 로그에서는 order-svc 이면 두 기록을 잇지 못합니다. 로그 줄에 트레이스 ID 를 함께 적어 두면 트레이스에서 로그로 곧장 건너갑니다.

따로 두는 구성과 한데 모은 구성

백엔드는 제품 하나일 때도 있고 여럿의 묶음일 때도 있습니다. 신호마다 저장소를 따로 두고 화면만 하나로 모으는 구성이 흔합니다. 한 제품이 세 신호를 다 받는 구성도 있습니다.

따로 두면 신호마다 가장 맞는 저장 방식을 고를 수 있습니다. 대신 돌보아야 할 시스템이 셋이 됩니다. 신호 사이를 잇는 꼬리표도 사람이 맞춰야 합니다. 한데 모으면 잇기는 쉽지만 세 신호를 한 제품의 방식에 다 맡깁니다.

누가 돌리느냐로도 갈립니다. 직접 서버에 설치해 돌리면 저장 공간과 확장을 스스로 챙겨야 합니다. 남이 운영하는 관리형 서비스로 보내면 그 일은 덜지만, 요금이 보내는 양을 따라 늘어납니다.

보내는 형식의 표준

보내는 쪽이 백엔드 제품마다 다른 형식을 쓰면 문제가 생깁니다. 백엔드를 바꿀 때마다 서비스 코드를 고쳐 다시 배포해야 합니다.

그래서 기록의 모양과 보내는 방법을 표준으로 정해 두는 흐름이 있습니다. OpenTelemetry가 그 표준을 만드는 프로젝트입니다. 서비스가 이 표준으로 보내면 받는 백엔드를 바꿔도 서비스 코드를 고치지 않습니다.

비용을 정하는 세 가지

백엔드는 받은 만큼 쌓습니다. 그래서 비용은 얼마나 잘게, 얼마나 오래, 얼마나 많이 쌓느냐로 정해집니다.

잘게 쌓는 비용은 꼬리표에서 옵니다. 꼬리표 값이 몇 가지인지를 카디널리티라고 부릅니다.

메트릭을 저장하는 백엔드는 꼬리표 조합 하나마다 시계열을 한 줄씩 따로 만듭니다. 조합이 늘면 시계열 줄 수도 그만큼 늘어납니다.

아래는 설명을 위해 잡은 수입니다. 응답 시간 메트릭 하나에 꼬리표를 하나씩 더해 갈 때 시계열이 몇 줄이 되는지 셉니다.

꼬리표의 가짓수가 서로 곱해지기 때문입니다. 사용자 ID 처럼 끝없이 늘어나는 값을 꼬리표로 달면 시계열이 사용자 수만큼 불어납니다. 그런 값은 메트릭 대신 로그나 트레이스에 적습니다.

오래 쌓는 비용은 보존 기간이 정합니다. 기간이 지난 기록은 백엔드가 지웁니다. 신호마다 기간을 다르게 잡는 경우가 많습니다.

오래된 메트릭은 다운샘플링으로 줄이기도 합니다. 10초 간격으로 받은 값을 한 시간에 한 점으로 접어 남기는 식입니다. 추세는 남지만 그 한 시간 안에서 튄 값은 사라집니다.

많이 쌓는 비용은 보내기 전에 줄입니다. 요청 가운데 일부의 트레이스만 남기는 샘플링이 그 방법입니다. 고르는 방법에 따라 나중에 보고 싶은 실패 건이 안 남아 있을 수 있습니다.

백엔드 자신의 장애

백엔드도 서버에서 도는 시스템입니다. 지켜보는 서비스와 같은 장애에 같이 휘말리면, 가장 필요한 순간에 기록을 못 봅니다.

그래서 백엔드는 지켜보는 서비스와 떨어진 곳에 두는 편입니다. 백엔드가 멈추면 알림도 멈추므로, 백엔드가 살아 있는지를 바깥에서 따로 확인하기도 합니다.

백엔드가 필요해지는 규모

서버 한 대에서 서비스 하나가 돈다면 로그 파일을 열어 보는 것으로 충분합니다. 백엔드를 세우면 그 서버를 돌보는 일이 새로 생깁니다.

서버가 여러 대로 늘고 요청 하나가 서비스 여럿을 지나가기 시작하면 사정이 바뀝니다. 기록이 흩어집니다. 서버가 사라지면 기록도 같이 사라집니다. 이때부터 기록을 한곳에 모아 두는 백엔드가 값을 합니다.

관련 항목

관측성 백엔드가 받는 신호

로그 · 메트릭 · 트레이스 · 스팬 · 프로파일 · 이벤트

관측성 백엔드 앞에서 기록을 만들어 보내는 단계

계측 · 자동 계측 · 수집기 · 익스포터 · 에이전트 · 샘플링

관측성 백엔드를 이루는 구성 요소

시계열 데이터베이스 · 역색인 · 오브젝트 스토리지 · 쿼리 언어 · 대시보드 · 알림

관측성 백엔드로 보내는 기록의 모양을 정하는 표준

OpenTelemetry · OTLP · 시맨틱 컨벤션 · Trace Context

관측성 백엔드를 구현한 제품

Prometheus · Grafana · Loki · Tempo · Jaeger · Elasticsearch · InfluxDB · Datadog

관측성 백엔드의 비용을 좌우하는 요인

카디널리티 · 보존 기간 · 다운샘플링 · 집계 · 압축 · 저장 비용

관측성 백엔드를 들이는 방식

관리형 서비스 · SaaS · 자체 호스팅 · 벤더 종속

관측성 백엔드가 속하는 상위 실천

관측성 · 모니터링 · 텔레메트리 · 분산 추적 · APM · SRE