로그 중앙화 시스템: Vector와 Loki를 활용한 모든 컨테이너 시스템 로그 집계

로그 관리가 왜 모든 개발자의 골칫거리가 되었을까

개발을 하다 보면 가장 마주치기 싫은 순간 중 하나가 바로 에러 로그를 찾아 헤매는 일입니다. 서비스가 커지고 컨테이너 기술이 대중화되면서 이 문제는 더욱 심각해졌습니다. 과거에는 서버 몇 대에 접속해서 로그 파일을 열어보면 그만이었지만, 지금은 수십 개 혹은 수백 개의 컨테이너가 동시에 돌아가는 시대입니다.

오늘날 우리는 도커와 쿠버네티스 같은 도구를 통해 애플리케이션을 쉽게 배포합니다. 하지만 이 과정에서 컨테이너는 언제든 생성되고 사라질 수 있는 일회성 존재가 되었습니다. 컨테이너가 꺼지는 순간 그 안에 있던 로그 파일도 함께 사라진다는 뜻입니다. 바로 이 지점에서 로그 중앙화 시스템의 필요성이 대두됩니다. 흩어져 있는 로그를 한곳에 모으지 않으면 장애가 발생했을 때 원인을 찾는 데만 엄청난 시간을 낭비하게 됩니다.

가장 가벼운 수집가 베터와 가장 똑똑한 저장고 로키

효과적인 로그 중앙화를 위해서는 로그를 수집하는 주체와 이를 안전하게 보관하고 검색할 수 있는 주체가 필요합니다. 이 역할에 가장 잘 어울리는 조합이 바로 베터와 로키입니다. 이 두 가지 도구가 왜 업계의 표준으로 자리 잡고 있는지 그 특성을 살펴보겠습니다.

베터는 시스템의 자원을 아주 적게 소비하면서도 엄청난 양의 로그를 빠르게 수집하는 에이전트입니다. 기존에 널리 쓰이던 무거운 수집기들과 달리, 메모리와 CPU를 적게 사용하여 컨테이너 환경에 최적화되어 있습니다. 서버마다 베터를 하나씩 배치해 두면, 그 서버에서 돌아가는 모든 컨테이너의 로그를 실시간으로 낚싯채듯 가로채어 목적지로 보낼 수 있습니다.

로키는 그라파나 Labs에서 만든 로그 전용 저장소입니다. 기존의 로그 검색 시스템들은 로그 내용 전체를 인덱싱하느라 엄청난 저장 공간과 비용을 소모했습니다. 하지만 로키는 발상의 전환을 했습니다. 로그 내용 전체를 인덱싱하는 대신, 메타데이터와 라벨만 인덱싱하고 실제 로그 본문은 압축해서 보관합니다. 이 방식 덕분에 비용은 획기적으로 줄어들고 로그 검색 속도는 놀라울 정도로 빨라집니다.

컨테이너 환경에서 로그를 모으는 실제 과정

실제 현업에서 베터와 로키를 어떻게 배치하고 활용하는지 그 흐름을 이해하는 것이 중요합니다. 이 시스템은 보통 다음과 같은 단계로 유기적으로 작동합니다.

• 컨테이너가 표준 출력으로 로그를 뿜어냅니다.
• 호스트 노드에 설치된 베터가 도커 엔진이나 쿠버네티스 로그 디렉토리를 모니터링하다가 이 로그를 실시간으로 감지합니다.
• 베터는 로그에 어떤 앱에서 나왔는지 어떤 서비스인지 구분할 수 있는 라벨을 붙여줍니다.
• 가공된 로그는 네트워크를 통해 중앙에 위치한 로키 서버로 전송됩니다.
• 로키는 전달받은 로그를 안전하게 저장하고 압축합니다.
• 사용자는 그라파나 대시보드 화면을 열어 로키에 쌓인 로그를 마치 데이터베이스를 조회하듯 편하게 검색하고 시각화합니다.

이 과정을 구축해 두면 개발자는 더 이상 각 서버에 SSH로 접속할 필요가 없습니다. 브라우저 창 하나만 띄워두고 에러가 발생한 시간대의 로그를 필터링하여 실시간으로 추적할 수 있습니다.

로그 시스템을 구축할 때 자주 하는 오해와 진실

로그 중앙화를 처음 시도하는 팀들이 흔히 빠지는 생각들이 있습니다. 잘못된 정보로 인해 시스템 도입이 늦어지거나 예산이 낭비되는 경우를 종종 봅니다.

많은 사람들이 로그는 무조건 엘라스틱서치로만 모아야 한다고 생각합니다. 물론 엘라스틱서치는 훌륭하고 강력한 도구이지만, 그만큼 대규모의 서버 자원과 관리가 필요합니다. 소규모나 중간 규모의 팀에게는 유지 관리 비용이 과도할 수 있습니다. 반면에 로키는 구조가 단순하여 운영 부담이 적고 인프라 비용을 대폭 아낄 수 있습니다.

또 다른 오해는 모든 로그를 빠짐없이 전부 저장해야 한다는 강박입니다. 디버그 레벨의 사소한 로그부터 시스템 상태 로그까지 전부 저장하면 금방 저장 용량이 바닥납니다. 비즈니스에 치명적인 에러와 경고 위주로 수집 수준을 조절하고, 오래된 로그는 자동으로 지워지는 보존 정책을 반드시 세워야 합니다.

비용을 아끼면서 효율적으로 로그를 운영하는 실전 노하우

인프라 비용은 늘 줄이고 싶은 숙제입니다. 로그 시스템을 운영하면서 비용을 최적화할 수 있는 몇 가지 실용적인 방법들이 있습니다.

로그 레벨을 철저히 관리하는 것이 첫 번째 출발점입니다. 개발 환경에서는 상세한 디버그 로그를 남기더라도, 운영 환경에서는 인포나 웨어닝 레벨 이상만 수집하도록 베터의 필터 기능을 설정해야 합니다. 쓸데없는 로그가 줄어드는 것만으로도 네트워크 대역폭과 저장 공간 비용을 동시에 아낄 수 있습니다.

클라우드 환경을 사용한다면 오브젝트 스토리지를 로키의 백엔드로 활용하는 것이 좋습니다. 로키는 아마존 에스쓰리나 구글 클라우드 스토리지 같은 저렴한 객체 스토리지와 완벽하게 연동됩니다. 비싼 고성능 디스크 대신 저렴한 오브젝트 스토리지에 압축된 로그를 밀어 넣으면 대용량 로그도 아주 적은 비용으로 몇 달씩 보관할 수 있습니다.

라벨을 너무 잘게 쪼개는 행위도 피해야 합니다. 로키에서 라벨의 가짓수가 너무 많으면 성능이 떨어지고 인덱스 크기가 커집니다. 사용자 아이디나 요청 주소처럼 경우의 수가 무한한 값은 라벨로 만들지 말고, 로그 본문 안에 포함시켜야 합니다. 서비스 이름, 환경 이름, 네임스페이스처럼 딱 떨어지는 항목만 라벨로 사용하는 것이 정석입니다.

로그 시스템 운영에 관해 자주 묻는 질문들

로그가 너무 많이 쌓여서 로키가 느려지면 어떻게 해야 하나요

로키의 성능 저하는 대부분 불필요하게 많은 라벨을 사용했거나 쿼리 범위가 너무 넓을 때 발생합니다. 라벨 카디널리티를 낮추고, 쿼리를 날릴 때 반드시 시간 범위를 좁게 설정하는 습관을 들여야 합니다. 또한 청크 크기나 압축 설정을 점검하여 시스템 스펙에 맞게 튜닝하는 과정이 필요합니다.

베터 대신 기존에 쓰던 다른 수집기를 계속 써도 되나요

기존에 사용하던 수집기가 있다면 그것을 활용해도 무방합니다. 하지만 베터는 컨테이너 환경에서 메모리와 CPU를 훨씬 적게 먹도록 설계되었기 때문에, 컨테이너 밀도가 높은 환경일수록 베터로 전환했을 때의 자원 절감 효과가 뚜렷하게 나타납니다.

로그 유출이나 보안 문제는 어떻게 대비해야 하나요

로그 안에는 실수로 포함된 비밀번호나 토큰, 개인정보가 찍힐 수 있습니다. 베터 단계에서 정규식을 이용해 민감한 패턴을 마스킹하거나 필터링하는 전처리 과정을 반드시 거쳐야 합니다. 또한 로키로 향하는 통신 구간은 암호화하고 접근 권한을 엄격하게 통제하는 보안 설정이 필수입니다.

장애가 나서 로키 서버가 죽으면 앱 로그는 다 유실되나요

베터는 로키 서버와의 통신이 끊어지면 잠시 로컬 디스크나 메모리에 로그를 버퍼링해 두는 기능을 제공합니다. 네트워크가 복구되거나 로키가 살아나면 밀렸던 로그를 다시 전송하기 때문에 일시적인 장애로 인한 로그 유실을 최소화할 수 있습니다.