로깅 안티패턴 Top 10

2005년부터 2023년까지 수백 가지의 로그 포맷을 파싱하면서 많은 문제 사례를 접했는데, 어디에도 어떻게 로깅해야 하는가에 대한 좋은 가이드가 없었습니다. 이에 대표적으로 피해야 할 로깅 안티패턴 10선을 정리하였습니다.

안티 패턴

1. 이스케이프 처리 누락

이스케이프 누락은 가장 흔하게 발견되는 사례입니다. 예를 들어 KEY=VALUE KEY2=VALUE2 와 같은 형식으로 로그 포맷을 정의했다면, VALUE에 공백이나 = 문자가 포함될 경우를 고려해야 합니다. KEY="VALUE" 와 같은 형식으로 정의했다면, VALUE에 큰 따옴표가 포함될 경우를 대비한 이스케이프 규칙이 필요합니다. CSV 형식으로 정의했으나 값에 쉼표가 포함된 경우에 대한 이스케이프가 없었던 사례도 있습니다. 이스케이프 규칙이 반영되지 않으면 수신 시스템은 휴리스틱한 처리를 할 수 밖에 없습니다.

2. 버전 헤더 누락

여러분의 솔루션이나 장비는 단 하나의 버전으로 통일되어 고객사에 배포되지 않습니다. 심하게는 한 고객사에서 동일 웹방화벽 제품에 대해 10종의 서로 다른 로그 포맷을 목격한 적도 있습니다. 로그 시작 부분에 버전이 명시되어 있지 않으면, 고객이 로그 파싱이 무언가 잘못된 것을 발견한 이후에야 대응하게 됩니다.

그 때 파서를 수정하려고 해도, 버전 헤더가 없으면 뭔가 로그의 특징적인 부분을 식별해서 파싱을 시도할 수 밖에 없습니다. 휴리스틱한 방법을 사용하여 어떻게든 버전 차이를 식별하더라도 여전히 로그 파싱이 100% 완벽하게 되리라 기대하기 어렵습니다.

3. 로그 타입 누락

하나의 솔루션이나 장비에서는 단 한 가지의 로그 유형만 나오지 않습니다. 당연히 여러 종류의 로그 유형들이 혼합되어 발생합니다. 하지만 로그 시작 위치에 로그 타입 정보가 없으면 이것도 버전 헤더 누락과 마찬가지로 무언가 특징적인 문자열을 식별하여 휴리스틱하게 파싱할 수 밖에 없습니다.

4. 호환성 고려 미비

로그 포맷을 업데이트 할 때는 자연히 필드 순서를 개발자가 보기 좋은 순서대로 다시 정렬하려는 유혹을 느끼게 됩니다. 하지만 외부 시스템을 고려한다면 새로운 필드는 반드시 끝부분에 추가해야 합니다. 만약 로그 중간에 새로운 필드를 삽입하게 되면, 외부 시스템은 버전별로 다른 포맷 파싱 규칙을 적용할 수 밖에 없습니다. 하위 호환성이 없는 로그에 버전 헤더까지 없다면 이것은 파싱에 매우 큰 어려움을 야기합니다.

5. 자연어 문장 사용

사람이 읽기 좋은 자연어 문장으로 로그를 기록하면, 프로그램으로 파싱하기가 극도로 어려워집니다. 대표적 예는 Cisco ASA 방화벽이나 네트워크 스위치의 로그들인데, 메시지 패턴별 정규식 수천 개를 추가해야 모든 경우의 수를 처리할 수 있게 됩니다. 대부분은 파싱을 포기하고 일부 필요한 로그만 파싱하여 활용하는 사태가 벌어집니다.

6. 고정 길이 형식 사용

정반대로 필드별 최대 길이가 정의된 고정 길이 로그 형식은 프로그램이 처리하기에 아주 좋은 것 아니냐고 생각할 수도 있겠습니다. 하지만 대부분의 풀텍스트 인덱스 엔진은 특수 문자를 기준으로 문자열을 분할하여 토큰을 추출하기 때문에, 의도하지 않은 값들이 하나의 토큰으로 인덱스되고 이 때문에 별도의 파싱이 없이는 검색 자체가 어려워집니다.

고정 길이로 인해 공백으로 비는 부분이 발생하므로 비효율적이기도 하며 이후 로그 포맷 업데이트에도 매우 불리합니다.

7. 코드 값 사용

애플리케이션에서는 로케일 처리를 위하여 ID 값을 사용하는 경우가 많습니다. 그렇지만 SIEM과 같은 외부 시스템은 ID에 대응하는 문자열 리터럴을 알 수가 없습니다. 물론 로그 포맷 정의서에 수백 개의 코드에 대한 명세를 작성하여 전달하기도 하지만, 장비나 솔루션이 업데이트 되면 새로 추가된 ID에 대한 정보는 역시 외부 시스템에서 즉각 알 수가 없으므로 기대한대로 파싱되지 않습니다. 코드 값 대신에 처음부터 영문 문자열을 사용하는 것이 변화에 대응하는 좋은 방법입니다.

8. 단위 변환

특히 바이트 값을 KB나 MB 단위로 기록하는 경우가 종종 있습니다. 아무래도 직관적으로 사람이 보기 편하기 때문에 이런 변환을 수행할 것입니다. 그러나 일부 값이 손실되어 정확하게 트래픽 총량을 계산할 수가 없을 뿐 아니라, 파싱 시점에 바이트 단위로 수치를 재변환하기 위해 별도의 로직을 작성해야 합니다.

9. 국제화 고려 미비

그동안 경험한 대부분의 로그의 타임스탬프 값에서 시간대를 보기 어려웠습니다. 여러분의 솔루션이나 장비가 같은 시간대에만 있다면 상관없다고 생각할 수도 있지만, 가령 AWS 인스턴스는 기본 시간대가 UTC에 맞춰져 있기 때문에 별도의 설정으로 타임존 보정을 하지 않으면 정확한 타임스탬프 값을 맞출 수가 없게 됩니다.

한편, 2023년에도 여전히 확장완성형으로 로그를 전송하는 사례가 있습니다. 요즘 세상에 UTF-8을 사용하지 않을 이유가 없습니다.

10. 길이 초과 잘림

JSON 형식의 로그를 SYSLOG over UDP로 전송하게 했는데 로그가 잘리면서 JSON 파서로는 파싱할 수 없게 되는 로그들도 있습니다. SYSLOG를 사용한다면 1000바이트 이내로 로그를 정리하는 것이 좋습니다. 이론적으로는 64K도 가능하지만 MTU를 넘는 로그를 UDP로 전송하면 패킷이 수십 개로 분할되고 이는 커널 스택에 도달하는 과정에서 쉽게 유실될 수 있습니다.

SQL 등 감사 로그를 SYSLOG over UDP로 보내도록 설계한 시스템들도 종종 보게 됩니다. 백업, 복원 수행 시에 SQL 감사 로그는 간단히 메가바이트 단위로 넘어갑니다. 이렇게 되면 감사 로그 본연의 목적을 달성할 수 없게 됩니다.

방화벽처럼 대량의 로그가 발생하는 네트워크 장비가 아니라면 HTTPS로 REST API를 지원하는 방안을 권장합니다. 물론 최근 글로벌 벤더 방화벽은 대부분 HTTPS를 통한 로그 조회도 지원합니다. SYSLOG over UDP는 패킷 스니핑에 전송 내용이 그대로 노출되기 때문입니다.

결론

로그 포맷을 설계할 때 이미 잘 정의된 형식을 사용하는 것을 권장합니다.

  • JSON: 로그 길이가 그리 길지 않다면 가장 범용적인 JSON 포맷이 좋습니다. 대부분의 로그 통합 시스템은 JSON을 그대로 인식할 수 있습니다.
  • CSV: 반복적으로 키 문자열을 쓰는게 낭비로 느껴진다면, CSV가 대안입니다. 단, 버전, 타입 필드를 시작 위치에 포함하고 이스케이프에 유의하세요.
  • WELF: 키=값 형식을 선호한다면 WELF 포맷 규칙을 추천합니다. 단, WELF는 쓸만한 외부 라이브러리가 없으므로 직접 로깅 모듈을 작성하는 과정에서 예외 처리들을 세밀하게 검토해야 합니다.

둘러보기

더보기

쿼리는 어떤 과정을 거쳐서 실행되는가

쿼리는 사용자와 데이터베이스를 매개하는 역할을 수행합니다. 응용프로그램을 개발할 때 파일 입출력을 직접 다루는 대신 데이터베이스를 사용하는 이유는 의도하는 데이터 처리 결과를 간단하게 얻을 수 있기 때문인데요. 쿼리를 사용하면 프로그램 코드를 작성하는 것에 비해 같은 작업을 훨씬 짧게 표현할 수 있습니다. 예를 들어 웹 로그에서 클라이언트 IP별 다운로드 트래픽 총량을 계산하려면 아래와 같은 과정을 거쳐야 합니다. 웹 로그는 아래와 같은 형식으로 기록됩니다. ``` 110.70.47.162 - - [23/May/2020:13:24:22 +0900] "GET /static/images/favicon.png HTTP/1.1" 200 57692 "-" "Mozilla/5.0 (iPhone; CPU iPhone OS 13_4 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/81.0.4044.124 Mobile/15E148 Safari/604.1" 849 ``` 1. 웹 로그 파일을 연다. 2. IP와 정수로 구성된 해시테이블을 초기화한다. 3. 웹 로그 파일을 개행 문자로 분리해서 행 단위로 읽어들인다. 1. 웹 로그에서 클라이언트 IP와 전송량에 해당되는 문자열을 추출한다. 2. 전송량 문자열을 정수로 변환한다. 3. 해시테이블에서 클라이언트 IP를 조회한다. 4. 기존 누적값과 현재 전송량을 합산하여 클라이언트 IP와 전송량의 쌍을 다시 해시테이블에 넣는다. 4. 파일 끝을 만나면 해시테이블의 모든 클라이언트 IP 키를 순회하면서 결과를 출력한다. 5. 웹 로그 파일을 닫는다. 프로그래밍 언어에 따라 다르지만 파이썬으로는 몇 줄, 자바로는 수십 줄 정도 구현이 필요할 것이고, 클라이언트 IP가 엄청나게 많아서 메모리에 다 올릴 수 없는 상황은 고려하지 않고 있습니다. 만약 일반적인 데이터베이스 테이블에 웹 로그가 파싱되어 저장되어 있는 상태라면 일반적으로 SQL을 이용해서 간단하게 1줄로 쿼리할 수 있습니다. ``` SELECT client_ip, SUM(bytes) FROM weblog GROUP BY client_ip ``` weblog 테이블에 데이터가 정규화된 형태로 존재한다면 로그프레소 쿼리는 아래와 같이 표현합니다. ``` table weblog | stats sum(bytes) by client_ip ``` 일반 데이터베이스는 테이블에 적재되지 않은 데이터를 처리하지 못하지만, 로그프레소는 아래와 같이 추출과 형 변환을 포함하여 모든 데이터 처리를 한 줄로 표현할 수 있습니다. ``` textfile access_log | rex field=line "^(?<client_ip>\S+).* (?<bytes>\S+)$" | eval bytes=long(bytes) | stats sum(bytes) by client_ip ``` ## 쿼리 실행 단계 데이터베이스는 위와 같이 기술한 쿼리 문장을 실제 실행 가능한 코드로 변환해야 합니다. 이 과정은 크게 쿼리 파싱, 최적화, 실행으로 구분합니다. ### 쿼리 파싱 ![Operator Tree](/media/ko/2020-05-25-query-execution/operator_tree.png) 쿼리는 한 줄로 간단하게 표현하였지만 프로그램 코드를 직접 작성한 것과 동일하게 동작하려면 각 기능 단위가 사용자의 의도에 맞게 배치되어야 합니다. 데이터베이스는 이러한 기능 단위를 쿼리 연산자 (Query Operator) 라고 부릅니다. 각 쿼리 연산자는 레코드를 입력 받아서 고유의 데이터 처리를 수행한 후 출력하며, 다음 연산자는 이전 연산자의 출력을 입력으로 받아들입니다. 위의 그림에서 실행 흐름은 아래에서 위로 올라가는 방향으로 표현되어 있는데 이것이 약간 부자연스럽게 느껴질 수 있습니다. 하지만 조인 연산이 포함되는 경우에 하단이 늘어나면서 넓게 배치되고 결과는 하나로 모이게 되므로 트리 형태로 표현하는 것이 유리하고, 그에 맞춰서 실행 흐름은 아래에서 위로 표시하는 것입니다. ### 최적화 데이터베이스는 쿼리를 파싱하여 트리 형태로 만들고 난 후에 이를 논리적, 물리적으로 최적화하는 과정을 수행합니다. 예를 들어, 위의 경우에 집계를 수행하므로 테이블 혹은 파일의 레코드 순서는 중요하지 않습니다. 따라서 병렬화된 테이블 스캔 혹은 파일 스캔으로 변환할 수 있습니다. 이 외에도 타입 추론, 비용 계산, 조인 순서, 필터링 위치 결정은 쿼리 최적화에서 중요한 주제인데 이는 나중에 다시 다루도록 하겠습니다. ![Query Optimizer](/media/ko/2020-05-25-query-execution/query_optimizer.png) ### 실행 최적화를 거치고 나면 최종적으로 쿼리 실행 계획 (Query Plan) 이 완성됩니다. 데이터베이스는 이 쿼리를 실행하는데 어느 정도의 CPU, 메모리, 디스크 자원을 사용할지 결정해야 합니다. 가장 단순하게는 프로그램을 직접 구현해서 실행하듯이 단일 프로세스가 쿼리를 실행할 수 있습니다. **프로세스 모델** PostgreSQL처럼 역사가 오래된 데이터베이스는 프로세스 모델 기반으로 동작합니다. ![Process Model](/media/ko/2020-05-25-query-execution/process_model.png) 프로세스 모델은 클라이언트가 접속하면 새로운 프로세스를 생성해서 할당합니다. 유닉스 프로그래밍 스타일의 오랜 전통이기도 하지만, 공유 메모리를 기반으로 프로세스를 분리하는 이런 실행 모델은 프로그램 오류로 크래시가 발생하더라도 해당 프로세스만 영향을 받기 때문에 상대적으로 장애에 견고합니다. 프로세스가 재시작하더라도 디스크에서 다시 읽어들일 필요 없이 공유 메모리 영역이 그대로 유지되는 장점도 있습니다. IBM DB2, Oracle (11g 이하 버전) 데이터베이스는 이러한 아키텍처로 설계되어 있습니다. 그러나 프로세스를 fork 하는 방식은 상당히 무거운 편입니다. 프로세스 풀링을 통해 어느 정도 단점을 희석시키기는 하지만, 운영체제에 실행을 맡기므로 스케줄링을 세밀하게 관리하기 어렵고 CPU 캐시 활용도 비효율적입니다. **스레드 모델** 로그프레소 쿼리 엔진은 스레드 모델 기반으로 동작합니다. ![Thread Model](/media/ko/2020-05-25-query-execution/thread_model.png) 로그프레소는 쿼리마다 하나의 쿼리 스케줄러 스레드를 실행합니다. 쿼리 스케줄러는 쿼리 실행 계획에서 의존성이 해소된 실행 가능한 태스크를 선별하여 쿼리 태스크를 병렬적으로 실행합니다. 스캔이나 정렬과 같이 실행 성능에 큰 영향을 미치는 요소는 별도의 스레드 풀이 할당되어 있어서, CPU를 최대한 활용하여 빅데이터 쿼리를 실행합니다. 로그프레소 쿼리 엔진은 푸시 모델로 구성되어 있기 때문에, 스캔 스레드의 병렬화가 전체 쿼리의 수행 성능을 좌우합니다. 메모리에 캐시된 페이지를 처리하는 경우 이러한 병렬화는 수 배 이상의 성능 차이를 낼 수 있습니다. 다음 편에서는 Pull 모델과 Push 모델의 장단점을 알아보도록 하겠습니다. ## 레퍼런스 - [PostgreSQL 12 Documentation: 1.2. Architectural Fundamentals](https://www.postgresql.org/docs/12/tutorial-arch.html) - [Oracle 18c Database Concepts: 15 Process Architecture](https://docs.oracle.com/en/database/oracle/oracle-database/18/cncpt/process-architecture.html#GUID-4B460E97-18A0-4F5A-A62F-9608FFD43664)

2020-05-25

소나 4.0.2312 출시 - 앱 시대의 개막

로그프레소 소나 4.0.2312.0 버전이 출시되었습니다. 이번 릴리스는 앱 관리, 로그프레소 CTI 지원, 클러스터 기반 룩업 및 예약된 쿼리, 센트리 자동 설치 기능을 포함합니다.

2023-12-08