Logstash 리버스 엔지니어링

초기에는 로그 수집기에 대해 일부 프로바이더는 ELK 스택 중 하나인 Logstash를 통해 로그 수집을 수행하고 있었습니다. 하지만 아래의 이유로 기존 사용 중이던 Logstash를 모두 Pure Typescript 로직으로 마이그레이션을 진행할 필요가 있었습니다.

• 로그 수집 시 외부로 나가는 패킷을 고객사의 특정 프록시 서버를 경유하여 나가도록 해야하고, 이는 수집하는 프로바이더에 따라 달라질 수 있어야 함. → Logstash는 전체 인스턴스 단위로만 프록시 설정을 줄 수 있음
• 로그 수집 파이프라인은 동적인 생성, 수정, 삭제가 가능해야 함. → Logstash는 파이프라인의 설정을 파일 기반으로 수행하는데, 해당 요구사항을 위해서는 파이프라인 설정 파일을 자주 확인한 뒤 리로딩해주어야 하고, 이 과정에서 프로세스의 안전성이 저하됨.
• 온프레미스 설치형 제품의 경우 Logstash의 이미지 크기가 부담이 되는 상황 (DevOps 의견)

이로 인해 Logstash를 덜어내기 전에, Logstash가 Aws, Azure, Gcp에서 로그를 수집하는 방법론과 내부 처리 로직을 파악하기 위해 1~2일 정도 Logstash의 소스코드를 까보는 시간을 가졌습니다.

https://github.com/logstash-plugins/logstash-input-s3

https://github.com/logstash-plugins/logstash-input-azure_event_hubs

https://github.com/logstash-plugins/logstash-input-google_pubsub

이틀에 걸친 리버스 엔지니어링을 통해 얻은 결과는 크게 두가지입니다.

• 3사 로그 수집에 대한 방법론 획득
• 수집 로그에 대한 비동기 처리 방법론(with 옵저버 패턴)

특히 후자를 보고 기존 수집 로직에 대한 성능 개선 방안을 수립할 수 있었습니다.

성능 개선 포인트

기존에 작성되어 있던 로직의 흐름은 다음과 같습니다.

// 간단하게 로직의 흐름을 보이기 위해 작성했으며 실제 코드가 아닙니다.
class Pipeline {
  private input: Input;
  private filter: Filter:
  private output: Output;

  ...
  // 내부 타이머를 이용하여 해당 로직을 지속적으로 호출
  private async collectLog(): Promise<void> {
    const log = await this.input.collectLog();
    await this.output.sendLog(this.filter.exec(log));
  }
}