웹 서비스를 운영하다 보면 다음과 같은 상황을 한 번쯤 겪게 됩니다. 어느 날 갑자기 사용자로부터 서비스가 정상적으로 동작하지 않는다는 문의가 들어오지만, 서버 화면만 봐서는 어떤 문제가 발생했는지 바로 알 수 없습니다. 서버는 여전히 실행 중이고, 네트워크도 정상처럼 보이기 때문입니다.

이럴 때 문제의 원인을 파악하기 위해 가장 먼저 확인하는 것이 바로 로그(Log)입니다. 로그에는 시스템에서 발생한 다양한 이벤트가 기록되기 때문에, 문제가 언제 발생했는지, 어디에서 발생했는지, 어떤 요청이 있었는지를 추적할 수 있습니다.

이번 글에서는 로그가 무엇인지, 그리고 로그가 어떤 형태로 기록되는지에 대해 기본 개념을 중심으로 살펴보겠습니다.

1. 로그란 무엇인가

로그는 시스템에서 발생한 일을 기록하는 데이터입니다. 사용자가 언제 요청을 보냈는지, 서버가 어떤 응답을 했는지, 오류가 발생했는지 등 시스템 내부에서 일어난 다양한 상황이 시간 순서대로 기록됩니다. 이러한 로그를 통해 시스템에서 실제로 어떤 일이 발생했는지 추적하고 원인을 파악할 수 있습니다. 예를 들어 웹 서버에서 사용자가 API를 호출하면, 요청과 응답에 대한 정보가 로그로 남게 됩니다.

하나의 로그에는 여러 정보가 포함되어 있으며, 이는 서버에서 어떤 일이 발생했는지 이해하는 데 활용됩니다. 로그에서 자주 확인할 수 있는 주요 구성 요소는 다음과 같습니다.

• timestamp: 로그가 발생한 시간으로, 이벤트 발생 시점을 확인하는 데 사용됩니다.
• level: 로그의 중요도를 나타내며 DEBUG, INFO, WARN, ERROR로 구분됩니다.
  • DEBUG: 개발 및 분석을 위한 상세 로그입니다.
  • INFO: 정상 동작 상태를 의미합니다.
  • WARN: 이후 문제로 이어질 수 있는 상태입니다.
  • ERROR: 실제 오류가 발생한 상황입니다.
• request: 클라이언트의 요청을 의미합니다.
  • method: 요청 방식으로 GET, POST, PUT 등이 사용됩니다.
  • path: 요청한 API 또는 리소스의 경로입니다.
  • protocol: HTTP 프로토콜 버전을 의미합니다.
• status: 요청 처리 결과를 나타내는 HTTP 상태 코드입니다.
• latency: 요청 처리에 걸린 시간입니다.

모든 로그가 동일한 형식을 사용하는 것은 아니며, 운영체제, 웹 서버, 애플리케이션, 데이터베이스 등 각 시스템의 목적에 따라 형식이 달라질 수 있습니다. 하지만 대부분의 로그에는 공통적으로 다음과 같은 정보가 포함됩니다. timestamp는 이벤트가 발생한 시간, level은 로그의 중요도, message는 어떤 이벤트가 발생했는지에 대한 설명입니다. 결국  로그는 언제, 어디에서, 어떤 일이 발생했는지를 확인하기 위해 사용됩니다.

2. 로그의 종류

로그는 시스템의 종류와 목적에 따라 다양한 형태로 생성됩니다. 같은 시스템이라도 어떤 정보를 기록하느냐에 따라 로그의 종류가 달라질 수 있습니다.

대표적으로 다음과 같은 로그가 있습니다.

• 웹 서버 로그
  • 사용자가 웹 서버에 요청을 보냈을 때 생성됩니다.
  • 어떤 URL이 호출되었는지, 응답 상태 코드는 무엇인지 등을 확인할 수 있습니다.

• 애플리케이션 로그
  • 애플리케이션 내부에서 발생하는 이벤트를 기록합니다.
  • 사용자 로그인, 비즈니스 로직 실행, 오류 발생 등의 정보가 포함됩니다.

• 데이터베이스 로그
  • 데이터베이스에서 실행된 쿼리나 트랜잭션 등의 정보를 기록합니다.
  • 데이터 변경 이력이나 성능 분석에 활용됩니다.

• 시스템 로그
  • 운영체제 수준에서 발생하는 이벤트를 기록합니다.
  • 시스템 시작, 서비스 실행, 보안 이벤트 등의 정보가 포함됩니다.

이처럼 로그는 시스템의 종류에 따라 다양한 형태로 생성됩니다. 하지만 형식은 서로 달라도, 대부분 시스템에서 어떤 일이 발생했는지를 기록하기 위한 데이터라는 공통된 목적을 가지고 있습니다.

3.로그는 어떻게 생성되는가

로그는 실제로 어떤 방식으로 생성될까요? 로그는 시스템이 동작하는 과정에서 다양한 방식으로 기록됩니다. 시스템에 따라 파일로 저장되기도 하고, 콘솔(stdout)에 출력되기도 하며, 개발자가 코드에서 직접 로그를 남기도록 설정할 수도 있습니다.

대표적으로 다음과 같은 방식으로 로그가 생성됩니다. 파일로 저장되는 로그는 가장 일반적인 방식으로, 로그를 파일 형태로 기록하는 방법입니다. 예를 들어 Linux 서버에서는 /var/log 경로에서 로그 파일을 확인할 수 있으며, syslog나 nginx의 access.log와 같은 파일에 시스템과 서비스에서 발생한 이벤트가 지속적으로 기록됩니다.

콘솔(stdout, stderr)로 출력되는 로그도 많이 사용됩니다. 특히 Docker나 Kubernetes와 같은 컨테이너 환경에서는 애플리케이션 로그를 파일이 아니라 stdout으로 출력하고, 이를 플랫폼에서 수집하여 관리하는 구조가 일반적입니다. 애플리케이션이 실행되면 콘솔에서 로그를 확인할 수 있으며, 이러한 로그는 로그 수집 시스템에서 모아서 관리됩니다.

개발자가 직접 남기는 로그도 있습니다. 애플리케이션 코드에서 특정 이벤트가 발생했을 때 로그를 기록하도록 구현할 수 있으며, 예를 들어 사용자 로그인 성공이나 데이터베이스 연결 실패와 같은 상황을 코드에서 직접 로그로 남길 수 있습니다. 이를 통해 문제 분석이나 서비스 상태 확인에 활용할 수 있습니다.

이처럼 로그는 파일, 콘솔 출력, 애플리케이션 코드 등 다양한 방식으로 생성되며, 이러한 로그를 통해 시스템에서 어떤 일이 발생했는지 추적할 수 있습니다.

4. 운영 환경에서의 로그 수집: Kubernetes 사례

지금까지 살펴본 것처럼 로그는 다양한 시스템에서 생성됩니다. 웹 서버, 애플리케이션, 데이터베이스, 운영체제 등 여러 곳에서 로그가 발생하기 때문에, 운영 환경에서는 이러한 로그를 한 곳으로 모아서 관리하는 구조를 사용합니다.

이 과정을 로그 수집(Log Collection)이라고 합니다. 예를 들어 Kubernetes 환경에서는 로그 수집을 위해 Fluent Bit과 같은 로그 수집 도구를 사용하기도 합니다. 또한 AWS EKS에서는 다음과 같은 유형의 로그를 CloudWatch Logs 등으로 수집할 수 있습니다.

• Application Logs는 컨테이너 애플리케이션에서 출력되는 로그입니다. (/var/log/containers)
• Data Plane Logs는 Kubernetes 노드 및 kubelet 관련 로그입니다. (kubelet, kube-proxy, docker)
• Host Logs는 노드 운영체제에서 발생하는 시스템 로그입니다. (/var/log/messages, /var/log/dmesg)

이러한 로그를 통해 클러스터 상태와 애플리케이션 동작을 보다 자세하게 확인할 수 있습니다. 최근 파이브클라우드에서 설계한 AWS EKS 환경에서는 Fluent Bit Add-on을 활용하여, 클러스터에서 실행되는 각 애플리케이션 컨테이너의 stdout 로그를 CloudWatch Logs로 수집하도록 구성했습니다.

이렇게 수집된 로그는 Kubernetes Namespace 기준으로 CloudWatch Log Group이 생성되도록 설정했습니다. 예를 들어 특정 네임스페이스의 로그만 수집하도록 필터를 구성하면, CloudWatch Logs에는 다음과 같은 로그 그룹이 생성됩니다.

/aws/eks/fastfive-cluster/fastfive-app: fastfive-app 네임스페이스의 모든 Pod 로그
/aws/eks/fastfive-cluster/fastfive-web: fastfive-web 네임스페이스의 모든 Pod 로그
/aws/eks/fastfive-cluster/fallback: 필터 매칭 실패 시 기록되는 기본 로그 그룹

각 로그 그룹 내부에서는 Pod 단위로 로그 스트림이 생성됩니다. 예를 들어 fastfive-app 네임스페이스에서 다음과 같은 Pod가 실행 중이라면

fastfive-web-a1234567
fastfive-web-b1234567
fastfive-app-c1234567

CloudWatch Logs에서는 위 Pod 이름을 기준으로 로그 스트림이 생성됩니다. 이러한 구조를 사용하면 특정 서비스에서 발생한 로그를 빠르게 조회할 수 있으며, 서비스 단위의 장애 분석을 수행할 수 있습니다.

또한 필요에 따라 Kubernetes Deployment에 label을 추가하고, Fluent Bit 필터에서 해당 label을 활용하도록 구성하면 로그를 더욱 세분화하여 관리할 수 있습니다. 이처럼 운영 환경에서는 로그를 단순히 기록하는 것에 그치지 않고, 중앙 로그 시스템으로 수집하여 서비스 상태를 분석하고 문제 원인을 파악할 수 있도록 구성합니다.

지금까지 로그가 무엇인지, 그리고 Kubernetes 환경에서 로그가 어떻게 수집되는지에 대해 간단히 알아보았습니다. 실제 운영 환경에서는 서비스 규모와 아키텍처에 따라 로그 수집 방식이나 분석 구조가 조금씩 달라질 수 있습니다.

​만약 Kubernetes, AWS, 로그 수집 및 모니터링 환경 구축과 관련해 고민이 있으시다면 언제든지 파이브클라우드에 문의해 주세요. 다양한 클라우드 운영 경험을 바탕으로 최적의 아키텍처를 함께 고민해 드리겠습니다.