콘텐츠로 이동






01.Loki stack소개

k8s에서 로그의 중요성

  1. Kubernetes 환경에서 로그 수집은 선택이 아니라 운영의 기본 요건이다. Pod는 짧은 생명주기를 가지며, 노드 장애나 재스케줄링이 발생하면 로컬 파일에만 남아 있던 로그는 쉽게 유실될 수 있다. 또한 여러 네임스페이스와 워크로드에 흩어진 로그를 직접 따라가며 보는 방식은 장애 분석에 많은 시간을 쏟을 수 밖에 없을것 같습니다.
  2. 이번에는 Rocky Linux 9에서 왜 로그 스택으로 Loki를 선택하는지와 왜 object storage 백엔드로 Ceph를 고려하는지를 정리해보려고 합니다.

Kubernetes 로그 수집의 문제점

  1. Kubernetes의 기본 로그는 각 노드의 컨테이너 로그 경로에 저장되며, 애플리케이션 Pod가 교체되거나 노드에 문제가 생기면 운영자가 과거 로그를 추적하기 어렵습니다.
  2. 단일 Pod 수준에서는 kubectl logs가 편리하지만, 다수 서비스와 다수 네임스페이스를 가진 클러스터에서는 중앙 수집, 보관, 검색 체계가 없으면 장애 대응 시간이 길어지는거죠

현실적인 문제는 크게 네 가지다.

  • 로그 보존이 애플리케이션 수명주기와 강하게 묶인다.
  • 노드별 파일 접근 방식은 멀티 테넌트 환경에서 일관된 조회 경험을 제공하기 어렵다.
  • 운영 로그와 애플리케이션 로그를 함께 검색하고 필터링하기가 번거롭다.
  • 장기 보관, 인덱싱, 비용 통제가 별도 설계 없이는 어렵다.

EFK, PLG, Loki 비교

로그 스택을 고를 때는 단순히 “잘 보이느냐”보다 저장 구조, 운영 복잡도를 봐야할것 같아요 아래 표는 Kubernetes 로그 수집 관점에서 EFK, PLG, Loki를 비교한 것이다.

항목 EFK Loki
기본 구성 Elasticsearch, Fluentd, Kibana Promtail 또는 Alloy, Loki, Grafana
저장 방식 전문 검색용 인덱스 중심 라벨 인덱스 + 로그 청크 저장
장점 강력한 전문 검색, 생태계 성숙 비용 효율적, 운영 부담이 상대적으로 낮음
단점 리소스 요구량과 운영 복잡도 큼 라벨 설계가 부실하면 검색 경험이 나빠질 수 있음
storage 적합성 로컬/블록/전용 스토리지 설계 필요 object storage 기반 운영에 특히 적합

Loki의 저장 구조와 object storage 필요성

  1. Grafana 문서에 따르면 Loki는 크게 두 종류의 데이터를 저장해야 한다고 하네요
    1. 실제 로그 데이터인 chunks
    2. 다른 하나는 검색과 조회에 필요한 index * Loki의 Single Store 방식은 index와 chunks를 모두 object storage에 저장하는 구조를 의미 합니다.
  2. 소규모 테스트 환경에서는 filesystem 기반으로 저장이 가능하지만, 운영환경이라면 object storage 이용을 권장합니다.

  3. 이 구조가 중요한 이유는 명확하다.

    • 로그 데이터와 인덱스를 내구성 있는 object storage에 둘 수 있다.
    • Loki를 scale-out 하더라도 저장소를 분리해 유연하게 운영할 수 있다.
    • filesystem 기반 저장소의 파일 수 한계와 운영 리스크를 피할 수 있다.
    • 장기 보관과 비용 통제를 더 현실적으로 설계할 수 있다.

  4. Ceph를 쓰는 이유

    1. AWS나 GCP같이 퍼블릭 클라우드 서비스를 사용할 수 없는 환경에서 사용할 수 있는 Ceph Object Gateway는 Amazon S3의 기본 데이터 접근 모델과 호환되는 RESTful API를 제공하므로, S3 클라이언트를 기대하는 애플리케이션과 자연스럽게 연결이 가능합니다.
    2. Ceph 및 관련 구성 요소를 안정적으로 운영하기에 무난한 기반이 된다.

전체 시리즈 아키텍처 개요

+---------------------------+
| Kubernetes Cluster        |
|                           |
|  +---------------------+  |
|  | Apps / Pods         |  |
|  | stdout / stderr     |  |
|  +----------+----------+  |
|             |             |
|             v             |
|  +---------------------+  |
|  | Promtail / Alloy    |  |
|  | Log Collector       |  |
|  +----------+----------+  |
+-------------|-------------+
              |
              v
      +---------------+
      | Loki          |
      | Index + Chunk |
      +-------+-------+
              |
              v
   +-----------------------+
   | Ceph Object Gateway   |
   | S3 Compatible API     |
   +-----------+-----------+
               |
               v
   +-----------------------+
   | Ceph Object Storage   |
   | Buckets for Loki Data |
   +-----------------------+

              ^
              |
      +-------+-------+
      | Grafana       |
      | Explore       |
      +---------------+
  • 이 아키텍처에서 수집기는 Kubernetes 노드와 Pod의 로그를 읽어 Loki로 전송하고, Loki는 인덱스와 로그 청크를 object storage에 저장한다. Grafana는 Loki를 데이터 소스로 연결해 Explore나 대시보드에서 로그를 조회하는 역할을 맡는다.



작성일: 2026년 7월 25일 ,  마지막 업데이트: 2026년 7월 25일