오늘 포스팅할 내용은 ELK Stack의 요소중 하나인 Logstash(로그스태시)입니다. 로그스태시 설명에 앞서 로그란 시스템이나 애플리케이션 상태 및 행위와 관련된 풍부한 정보를 포함하고 있습니다. 이러한 정보를 각각 시스템마다 파일로 기록하고 있는 경우가 대다수 일겁니다. 그렇다면 과연 이러한 정보를 파일로 관리하는 것이 효율적인 것인가를 생각해볼 필요가 있습니다. 한곳에 모든 로그데이터를 시스템별로 구분하여 저장하고 하나의 뷰에서 모든 시스템의 로그데이터를 볼 수 있다면 굉장히 관리가 편해질 것입니다. 이러한 모든 로그정보를 수집하여 하나의 저장소(DB, Elasticsearch 등)에 출력해주는 시스템이 로그스태시라는 시스템입니다. 앞선 포스팅에서 다루어보았던 Filebeat와 연동을 한다면 파..

실시간 로그 집계와 같은 대용량 데이터 처리를 위해서는 애플리케이션의 처리량(Throughput)이 높아야 한다. 카프카에서는 대용량의 실시간 데이터 처리를 위해 배치 전송, 파티션, 분산 기능을 구현했다. 또한 중앙 시스템의 역할을 하는 중요한 서비스에서 서버 장애가 발생하더라도 서비스에 영향이 없도록 데이터의 안정적인 저장을 위해 리플리케이션 기능과 분산된 서버에서 자동으로 파티션의 리더를 선출하는 기능을 구현했다. 카프카는 분산된 데이터 파이프라인을 표준화하고 통합하길 원했고, 처리량에 중점을 두고 설계되었다. 이에 따라 카프카에는 높은 처리량과 빠른 메시지 전송, 운영 효율화 등을 위해 분산 시스템, 페이지 캐시, 배치 전송 처리 등의 기능이 구현되었다. 카프카 디자인의 특징1) 분산 시스템동일한..

카프카 프로듀서 주요 옵션 (https://kafka.apache.org/documentation/#producerconfigs) 옵션 설명 bootstrap.servers 카프카 클러스터는 클러스터 마스터라는 개념이 없기 때문에 클러스터 내 모든 서버가 클라이언트의 요청을 받을 수 있다. 해당 옵션은 카프카 클러스터에 처음 연결을 하기 위한 호스트와 포트 정보로 구성된 리스트 정보를 나타낸다. 정의된 포맷은 "호스트 이름:포트, 호스트 이름:포트, 호스트 이름:포트"이다. 전체 카프카 리스트가 아닌 호스트 하나만 입력해 사용할 수 있지만, 이 방법을 추천하지는 않는다. 카프카 클러스터는 살아있는 상태이지만 해당 호스트만 장애가 발생하는 경우 접속이 불가하기 때문에, 리스트 전체를 입력하는 것을 권장한다..

토픽의 파티션 수가 증가함에 따라 빠른 전송이 가능하다. 그렇다면 토픽의 파티션 수를 많이 늘리는 것이 무조건 좋은 것은 아니다. 파티션 수가 늘어나면 오히려 카프카에 좋지 않은 영향을 미칠 수도 있다. (1) 파일 핸들러의 낭비각 파티션은 브로커의 디렉토리와 매핑되고, 저장되는 데이터마다 2개의 파일(인덱스와 실제 데이터)이 있다. 카프카에서는 모든 디렉토리의 파일들에 대해 파일 핸들을 열게 된다. 결국 파티션의 수가 많을수록 파일 핸들 수 역시 많아지게 되어 리소스를 낭비하게 된다. (2) 장애 복구 시간 증가카프카는 높은 가용성을 위해 리플리케이션을 지원한다. 브로커에는 토픽이 있고, 토픽은 여러 개의 파티션으로 나뉘어 있으므로, 브로커에는 여러 개의 파티션이 존재하게 된다. 또한, 각 파티션마다 ..