Logstash execution model
출처: 문서
본문
Logstash 실행 모델
여기 Logstash가 내부적으로 이벤트를 처리하는 방법을 간략히 소개해요.
이벤트를 동시에 처리하기
Logstash가 여러 입력을 통해 이벤트를 수신하도록 구성할 수 있어요. 각 입력은 자체 스레드에서 실행되어 서로를 차단하지 않아요. 동시에 두 개의 이벤트가 들어오면 Logstash는 두 이벤트를 동시에 처리해요.
이벤트를 수신하고 입력 코덱을 적용한 후 Logstash는 이벤트를 작업 큐로 보내요. 파이프라인 워커 또는 배처가 필터와 출력, 그리고 출력에 사용되는 코덱을 포함한 나머지 작업을 수행해요. 각 파이프라인 워커도 자체 스레드에서 실행되므로 Logstash는 여러 이벤트를 동시에 처리해요.
이벤트를 배치로 처리하기
파이프라인 워커는 파이프라인 전체의 처리량을 최적화하기 위해 작업 큐에서 이벤트를 배치로 소비해요.
Logstash가 배치로 작업하는 이유 중 하나는 파이프라인 워커 내에서 한 번에 처리되는 이벤트 수에 관계없이 실행해야 하는 코드가 있기 때문이에요. 100개의 이벤트에 대해 해당 코드를 100번 실행하는 대신 100개의 이벤트 배치에 대해 한 번 실행하는 것이 더 효율적이에요.
또 다른 이유는 일부 출력 플러그인이 이벤트를 배치로 그룹화하기 때문이에요. 예를 들어 OpenSearch에 100개의 요청을 보내는 경우 OpenSearch 출력 플러그인은 Bulk API를 사용하여 100개의 요청을 그룹화한 단일 요청을 보내요.
Logstash는 두 가지 구성 옵션, 즉 최대 배치 크기를 나타내는 숫자와 배치 지연으로 배치 크기를 결정해요. 배치 지연은 Logstash가 처리되지 않은 이벤트 배치를 처리하기 전에 기다리는 시간이에요.
최대 배치 크기를 50으로, 배치 지연을 100ms로 설정하면 Logstash는 작업 큐에 처리되지 않은 이벤트가 50개 있거나 100밀리초가 경과하면 배치를 처리해요.
최대 배치 크기에 도달하지 않았더라도 배치를 처리하는 이유는 처리 지연을 줄이고 적시에 이벤트를 계속 처리하기 위해서예요. 이는 이벤트 양이 적은 파이프라인에 잘 작동해요.
웹 서버의 오류 로그를 처리하여 OpenSearch로 푸시하는 파이프라인이 있다고 상상해 보세요. OpenSearch Dashboards를 사용하여 오류 로그를 분석하고 있어요. 처리하는 이벤트 수가 적기 때문에 50개에 도달하는 데 오랜 시간이 걸릴 수 있어요. Logstash는 이 임계값에 도달하기 전에 이벤트를 처리해요. 그렇지 않으면 OpenSearch Dashboards에 오류가 나타나기까지 오랜 지연이 발생할 수 있기 때문이에요.
기본 배치 크기와 배치 지연은 대부분의 경우에 잘 작동해요. 성능을 세밀하게 최적화해야 하는 경우가 아니라면 기본값을 변경할 필요가 없어요.
CPU 코어 기반 최적화
파이프라인 워커의 수는 노드의 CPU 코어 수에 비례해요.
2개의 CPU 코어가 있는 서버에서 5개의 워커를 실행하면 5개의 워커가 이벤트를 동시에 처리할 수 없어요. 반면에 10개의 CPU 코어가 있는 서버에서 5개의 워커를 실행하면 Logstash 인스턴스의 처리량이 제한돼요.
고정된 수의 워커를 실행하면 경우에 따라 성능이 저하될 수 있으므로 Logstash는 인스턴스의 CPU 코어 수를 확인하고 실행 중인 플랫폼에 맞게 성능을 최적화하도록 파이프라인 워커 수를 선택해요. 예를 들어 로컬 개발 머신은 프로덕션 서버와 동일한 처리 성능을 갖지 않을 수 있어요. 따라서 다른 머신에 대해 Logstash를 수동으로 구성할 필요가 없어요.