EFK(ELK) 구축 해보기!! (서버 로그 수집) - 2. EFK 소개와 아키텍처

EFK(ELK) 구축 해보기!! (서버 로그 수집) - 2. EFK 소개와 아키텍처

EFK란

우선

EFK는

ElasticSearch, Fluentd, Kibana

의 앞자 글자만을 딴 것이다.

 

더 잘 알려진 ELK는

Elastic stack으로 구성되었으며, 여기서 L은 Logstash이다.

 

Elastic stack의 유료화로 인해

ElasticSearch -> OpenSearch

Fluentd

Kibana -> OpenDashboard

를 사용한다.

 

Fluentd

• Log를 수집, 파싱, 전송을 담당한다.
• App의 파일을 읽기 위해 App과 같은 호스트에 뜬다.
• Fluentd는 적은 리소스로 로그를 파싱&전송
• 규칙을 태그 방식으로 정한다.

OpenSearch(ElasticSearch)

• Log를 저장하는 저장소다.
• 텍스트 데이터의 검색에 특화된 인덱싱 방법을 가지고 있어,
  로그 저장소 및 검색 시스템으로 사용하기 좋다.
• 데이터 타입과 형식에 유연성을 제공한다.
  미리 스키마를 선언하지 않더라더라도 저장된 데이터 형식에 맞게 자동으로 인덱싱을 할 수 있다.

OpenDashboard(Kibana)

• OpenSearch와 연동이 되며 사용하기 쉬운 시각화 도구이다.
• UI를 통해 원하는 로그를 쉽게 찾고 추이를 볼 수 있다.

Logstash vs Fluentd

Logstash와 Fluentd가 제공하는 기능들은 차이가 거의 없다.

 

메모리의 버퍼 큐에서 큰 차이를 보이는데,

Logstash는 메모리상에 고정된 크리의 큐를 가지고 있어 throughput(처리량) 대비 높은 유입량을 대비하기 위해서는 외부 큐(Redis, Kafka)에 의존해야한다.

반면, Fluentd는 메모리 또는 디스크에 끝없는 배열로 구성된 버퍼를 가진다. 따라서 외부큐에 의존하지 않고도 유입량에 대한 관리가 가능하다. 재시작시 디스크에서 읽어 재처리도 가능하다.

 

문법에서도

Logstash는 if-else문으로 이벤트를 관리하고

Fluentd는 태그로 관리한다.

 

요구사항에 따른 아키텍처 구성

1) 작은 규모의 서비스에서의 기본 아키텍처

 

하지만 이 경우 로그 수집기인 Fluentd에 부하가 일어나면 로그가 유실될 수 있다.

 

2) 로그 수집기 역할을 나눈 아키텍처

 

보통 로그를 처리하면서 부하가 발생하는데,

이렇게 Forwarder와 Collector로 나누면

Fluentd의 부하를 방지할 수 있다.

이때 가운데에 로드밸런서를 배치해 더욱 과부하를 줄여준다. 이때는 보통 라운드로빈만으로도 충분하다.

클러스터 운영이 어렵다면 kafka로 대체도 가능하다.

 

Forwarder는 각 노드(인스턴스)에서 최소한의 파싱과 전송만 담당한다.

Collector는 전달된 로그를 파싱하고 적절한 스토리지로 전송한다.

 

하지만 이 경우도 문제가 있는데

바로 로그 저장소인 ElasticSearch에서 트래픽을 받아주지 못하는 경우다.

 

ElasticSearch는 들어오는 데이터를 저장하고 바로 인덱싱을 하는데 이 시간이 길어질 수도 있다.

여러 Fluentd가 데이터를 동시에 보내는데 이 과정이 오래걸리면 Bottleneck이 된다.

Fluentd의 버퍼가 가득차면 로그가 유실될 수 있다.

 

이 때 OpenSearch의 ingest node라는 서버로 스토리지에서 자장 효율을 높여줄 수 있다.

한마디로 인덱싱 전, 저장하는 노드에 대량의 저장요청이 가능하다는 것이다.