08. Fluentd high availability config

본 글은 https://docs.fluentd.org/을 번역/요약/정리/사견 추가한 글입니다.

1. 개요

트래픽이 많은 웹사이트의 경우, fluentd의 high-availability 설정을 하는 것을 추천합니다. 그렇다면 high-availability 설정은 뭘까요?!

2. Message Delivery Semantics

Fluentd는 주로 이벤트 로그를 전달하는 시스템을 위해 설계되었습니다. 이런 시스템에선 몇 가지 배송 방법이 있습니다.

• At most once: 메시지는 즉시 전달됨. 전송 실패시 전달을 못하고 메시지를 잃을 수 있음.
• At least once: 메시지는 최소 1번 전달됨. 실패시 2번 보낼 수도 있음.
• Exactly once: 메시지는 딱 한 번 전달됨. 가장 이상적

만약 시스템이 이벤트를 하나라도 잃을 수 없고 딱 한 번씩 전달되어야 한다면(exactly once), 전송 속도보다 더 빠르게 이벤트가 유입될 시 이벤트를 그만 받아야 합니다. 적절한 방법은 로깅을 동기적으로 하고 fluentd가 이벤트를 받지 못할 때 에러를 리턴하는 것입니다.

하지만 로깅을 동기적으로 하는 것은 어플리케이션의 성능에 부정적인 영향을 줍니다. 그렇기 때문에 fluentd는 at most once, at least once 방식을 추가로 제공합니다. 이 방법으로 어플리케이션은 로깅을 비동기적으로 할 수 있고 이로 인해 성능을 보장받을 수 있습니다. 대신 로깅 이벤트 전송 실패의 리스크를 떠안아야 합니다.

하지만 대부분의 실패 시나리오는 방지 가능합니다. 다음 장부터 어떻게 fluentd를 구성하면 실패를 최대한 방지하면서도 high-availability가 가능한지 설명드리겠습니다.

3. Network Topology

High-availiability를 달성하기 위해서는 log forwarders와 log aggregators가 있어야 합니다.

 

 

'Log forwarder'는 로컬의 이벤트를 받기 위해 모든 노드에 설치되어 있습니다. 이벤트를 받으면 log forwarders는 log aggregators로 보냅니다. Log forwarder의 가벼운 프로세싱을 위해선 fluent-bit도 좋은 선택지입니다.

'Log aggregator'는 log forwarders로부터 지속적으로 이벤트를 받는 데몬입니다. 이벤트를 모았다가 주기적으로 클라우드에 데이터를 넣습니다. 

3.1. Log forwarder 설정 예

# TCP input
<source>
  @type forward
  port 24224
</source>

# HTTP input
<source>
  @type http
  port 8888
</source>

# Log Forwarding
<match mytag.**>
  @type forward

  # primary host
  <server>
    host 192.168.0.1
    port 24224
  </server>
  # use secondary host
  <server>
    host 192.168.0.2
    port 24224
    standby
  </server>

  # use longer flush_interval to reduce CPU usage.
  # note that this is a trade-off against latency.
  <buffer>
    flush_interval 60s
  </buffer>
</match>

TCP, HTTP로 입력을 받은 후 log aggregator로 이벤트를 보내는 모습입니다.

3.2. Lg aggregator 설정 예

# Input
<source>
  @type forward
  port 24224
</source>

# Output
<match mytag.**>
  # ...
</match>

TCP로 이벤트를 받는 모습입니다.

4. 실패 시나리오들

4.1. Forwarder 실패

Log forwarder가 어플리케이션으로부터 이벤트를 받으면, 이벤트는 먼저 디스크 버퍼에 쓰여지고 조건에 따라 aggregator로 이벤트를 보냅니다. 

이 방법은 데이터 손실에 본질적으로 강합니다. 만약 log forwarder가 죽으면 디크스에 있는 버퍼를 다시 가져와 보내면 되고 forwarder와 aggregator 사이의 네트워크가 문제가 있다면 전송을 재시도하면 됩니다.

하지만 데이터를 손실할 수 있는 시나리오가 존재하긴 합니다

• 이벤트를 받자마자 fluentd가 죽어서 버퍼에 쓰지 못한 경우
• forwarder가 쓰는 디스크가 망가져서 버퍼 파일을 잃은 경우

4.2. Aggregator 실패

Log aggregator가 이벤트를 받으면, 먼저 디스크 버퍼에 이벤트를 쓰고 조건에 따라 클라우드로 이벤트를 보냅니다. 즉, forwarder와 동작 방식이 유사하고 데이터를 손실할 수 있는 시나리오도 유사합니다.