로그 수집/전송 단계를 외부 프로세스로 분리해야 하는 이유

이 포스팅에서 다루고자 하는 대상은 로그를 생성하는 어플리케이션과 로그를 저장하는 시스템이 서로 별개라서, ‘로그 전송’ 단계가 있는 경우입니다. 자바를 예를 들면, log4j에서 DBAppender를 사용하여 외부의 DB에 로그와 관련된 정보를 저장하는 경우가 해당됩니다.  다만, 그저 단순히 로컬 디스크에 로그를 저장하고 그치고 마는 경우라도 참고할만한 내용이 있을 것입니다.

log4j 같이 inner-process 타입 로깅의 경우 어플리케이션과 같은 프로세스 내에서 로그를 기록합니다. 이 방식에서는 어플리케이션 프로세스의 상태가 로그 저장에 영향을 줄 수 있습니다. 가령 예를 들어 Out of memory exception이 발생한 경우, 이 OOME를 유발한 행위에 대한 로그가 실제로 기록되는지는 보장할 수 없습니다. 저장될 로그의 내용이 프로세스 내부의 어떤 버퍼에 의해 관리되고 있다면 더욱 그렇습니다. 또한, 어딘가에 임시로 기록이 되었다고 하더라도, 어플리케이션이 재기동하기전까지는 다른 계층으로 전송되지 않는다는 점이 문제점으로 남습니다.

단순 유실/즉시성의 문제를 넘어 다른 문제도 존재합니다. 웹서비스에서는 대부분의 로그가 사용자로부터의 Request 요청과 밀접하게 연관되어 있습니다. Request 요청 횟수가 많아지면 당연히 그에 따라 로그도 증가합니다. 문제는 DDoS 같은 상황에서 웹서버의 부하가 인프라 전체의 부하로 확대될 수 있다는 점입니다. 로그 전송 단계에 주의를 기울이지 않은 시스템에서는 웹서버의 작은 부하가 전체 인프라를 다운시켜버리는 상황도 종종 발생합니다. 따라서 한 계층의 부하가 다른 계층으로 전파되지 않도록, 중간에서 부하를 제어할 수 있는 메커니즘이 필요합니다.

그리고 서비스와 로깅에 필요한 컴퓨팅 리소스를 적절히 분배하는 것 또한 중요합니다. 한 머신에 node.js 의 인스턴스가 10개 떠 있다고 하더라도, 로그를 처리하는 프로세스는 1개면 충분한 경우가 있다는 것이죠.

일반적으로 inner-process 로깅의 경우 형태는 단순하지만, 앞서 언급한 상황에 효율적으로 대응하기가 어렵고 한계도 있습니다. 대신 outer-process 형태의 로깅은 하드웨어의 장애가 아닌 이상 이런 이슈에 대해 비교적 수월하게 대응을 할 수 있습니다.

이런 측면에서 flume, fluentd 등은 활용성이 높은 솔루션입니다. 특히, 이 두 오픈소스는 유연하게 구성을 할 수 있고, 플러그인을 통한 확장성이 좋아서 outer-process 로깅 패턴을 적용하는데 좋은 출발점이 될 수 있으니 참고하시기 바랍니다.

Advertisements

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중

%d 블로거가 이것을 좋아합니다: