ELK Stack을 개선해보자 #2
what is efficient architecture for elk?
주의!
이 글은 스타트업에 다닐 적, elk stack을 통하여 구축하라는 명령 하달로 인하여 급하게 준비한 내용이다.
금액적 측면에 대한 제한과.. 시간의 제한이 있었으므로 단순히 이런 생각을 했구나~! 라고 보고 넘기면 되겠다.
어떤 식으로 구성하는 게 가장 좋을까? 가장 오랫동안 고민했다. 우선, 어떻게 구성할지를 정하기 위해서는 그만큼 Background 지식이 필요하다. 하지만 필자는 ELK stack이라곤 정말 ELK 이 3가지만 알았다. 그 외에도 다양한 메세징 큐와 filebeat 등이 존재한다는 점에서 사실 많이 놀랐으며 다시 한번 고민하게 되었다. 그렇다면 가장 좋은 구성은 무엇일까?
기본적인 ELK stack의 레이어는 다음과 같다.
초기에 사용하면 좋을 법 한 구성
위 구성은 아주 심플한 구성이다. Beats는 Logstash로 대체될 수 있다. 아마 기존 로그 서버에 가까운 구성이 아닐까 싶다. 저 Beats만 Logstash로 대체되었을 뿐이니..
처리 및 데이터 복구 능력을 중점으로 구성
위 구성은 다량의 로그가 수집되는 서버에서 많이들 사용하는 구성이다. 별도의 메세징 큐가 존재하며, 해당 큐를 통해서 로그의 유실을 최소화할 수 있다.
입력 소스들 처리 유연성을 중점으로 구성
이는 가장 노멀 구성에서 Logstash를 Indexer로 사용하며 ES 쪽도 별도의 노드를 더 구성하였다.
수정할 서버는 처리 및 데이터 복구 능력을 위한 구성으로 진행하려 한다. beats 부분은 logstash로 변경하여 결국은 아래와 같은 구성이 될 것 같다.
Logstash(Shipper) < > Kafka / Redis < > Logstash(Indexer) < > Elasticsearch < > Kibana
출처 : https://www.elastic.co/pdf/architecture-best-practices.pdf
