카카오는 내부 로그 수집 시스템으로 kemi-log를 운영하고 있습니다. kemi-log는 여러 가지 오픈 소스를 이용하여 구축되었으며, 특히 Fluentd를 메인 컴포넌트로 활용하여 수년간 운영해온 플랫폼입니다. 이 글에서는 Fluentd를 대체하기 위한 마이그레이션 프로젝트를 소개하고자 합니다. 구체적으로는 이러한 프로젝트를 진행하게 된 배경과 개발 과정, 그리고 실제 도입 후 달성한 성과에 대해 설명하고자 합니다.kemi-log는 현재는 발전하여 아래와 같은 구조를 가지고 있습니다.2개 레이어로 구성된 시스템 아키텍처의 log aggregator 영역은 2개의 레이어로 분리되어 있습니다. 1 layer는 사용자로부터 직접 로그 데이터를 수신하게 되고 2 layer는 1 layer로부터 데이터를 넘겨받아 각각의 스토리지로 데이터를 전송하는 역할을 맡고 있습니다.2개의 layer로 분리하게 된 이유는 스토리지 쪽으로 데이터를 보내는 기능이 시스템 자원을 많이 차지하고 운영상 이슈가 발생하는 경우가 있기 때문이었습니다. aggregator가 하나라면 특정 스토리지 전송 쪽 이슈가 발생했을 때 모든 aggregator가 영향을 받게 됩니다. 그래서 2개의 layer로 분리해서 1 layer에서는 일단 로그를 받아서 버퍼링을 하고 있고 2 layer를 통해서 받은 로그를 스토리지에 저장하도록 하고 있습니다. 2 layer도 스토리지 별로 여러 개로 그룹핑되어 있습니다. 특정 서비스의 로그 트래픽이 많은 경우 분리해서 관리하기 위한 용도와 스토리지 쪽 장애가 발생했을 때 그 때문에 다른 스토리지로의 적재에 영향을 미치지 않도록 하기 위해서 구분하는 용도입니다.Fluentd는 설정을 파일로 기록하고 관리합니다. 신규 로그 데이터를 받거나 기존의 설정을 변경하려면 설정 파일을 변경하고 업데이트해야 합니다. 이런 설정 작업이 자주 있습니다. 운영 초기에는 Ansible을 통해서 이런 변경사항을 반영하고 Fluentd를 재시작했었습니다. 운영경험이 쌓여 나가면서 작업 실수를 줄이기 위해서 여러 대의 Fluentd를 모아서 클러스터화 하고 그걸 통합해서 관리할 수 있는 tug라는 시스템을 만들어서 사용했습니다.tug는 중앙에서 전체 Fluentd들을 관리하는 역할을 하는 tug-server와 Fluentd와 같은 서버에 있으면서 tug-server로부터 Fluentd 설정을 받아서 반영하는 tug-agent로 구성되어 있습니다.직접 tug라는 Fluentd 설정 관리 시스템을 만들고, 필요한 경우는 오픈 소스인 Fluentd에 코드 기여를 하면서 운영해 왔지만 Fluentd의 구조상 한계에 부딪히게 되었습니다.Fluentd의 구조적 한계를 극복하기 위해 대체 Logriver라는 새로운 로그수집기를 자체 개발하게 되었습니다.Fluentd의 대안을 생각하면서 그동안 새롭게 나온 여러 가지 오픈 소스들을 대안으로 생각해 보았습니다. 하지만 이미 사내에서는 Fluentd를 통한 로그 수집이 표준화되어 있었기 때문에 카카오 내부의 수만 대의 서버에 Fluent

이 번에는 AKS(Azure Kubernetes Service) 상용 서비스에 적용한 후기 다섯 번째 내용으로, k8s 환경에서 로그를 통합 관리하게 해주는 EFK 기술에 대해 소개드리려고 합니다.우선 EFK는 ElasticSearch, Fluentd, Kibana의 줄임말인데요. 이 세 가지 기술을 사용하는 아키텍처는 여러가지가 있습니다.그 중에서 서비스에 맞는 아키텍처를 선정하여 진행하면 됩니다.Use Case #1: 각 Node에 Fluentd를 데몬셋으로 설치하고 개별적으로 ElasticSearch로 전송Use Case #2: 각 Pod에 Fluentbit을 Sidecar로 설치하고 Fluentd에서 통합 수집하여 ElasticSearch로 전송 Use Case #3: 각 Pod에 Fluentbit을 Sidecar로 설치하고 Kafka를 Fluentd와의 중간에 배치하여 Log손실을 방지 Use Case #4: 각 Application Server에 쉐어드 볼륨을 마운트하고 Fluentd에서 Log적재 파일을 직접 읽어 드림그 중에서 일반적으로 Use Case 1번과 Use Case 2번을 많이 적용하는데요. Fluentd를 데몬셋으로 설치하는 방안(1번 케이스)의 장단점에 대해 알아보겠습니다.• None• None 개별 Pod에 Sidecar로 설치하는 것 보다 리소스 경량화 가능 (Pod 마다 Sidecar를 설치하는데 소요되는 자원 절약)• None fluentbit은 경량이긴 하나 fluentd에서 제공하는 다양한 필터링 기능 사용 불가 (특정 namespace 혹은 pod 로그만 수집 등)• None• None 콘솔에 출력되는 stdout/stderr를 container 로그로 저장하므로 콘솔 로그를 수집에 맞게 Json 형식으로 출력해야 함• None Daemonset resource 관리가 어려움. (Log생성이 많은 Pod가 특정 노드에 몰릴경우 발생.)각 아키텍처의 장단점을 비교 분석한 결과, 저희 서비스는 아래와 같이 "Fluentd를 데몬셋으로 설치"하는 아키텍처를 구성하게 되었습니다.저희는 ElasticSearch와 kubernetes에 맞춤형 image인 "fluentd-kubernetes-daemonset-debian-elasticsearch"를 사용하여 쿠버네티스에 데몬셋으로 설치하였습니다.설치하는 방법은 아래와 같습니다.• None• None namespace : kube-system으로 설정 필요• None• None data 하위에 key로 적은 문자열 (예 : fluent.conf) : 파일명• None | 이후 내용 : txt 형태로 파일의 내용이 됨• None 설정 : filter란 이벤트 처리를 위한 중간 pipeline으로서, 생성할 경우 정의한 문자열 규칙과 동일하게 tag를 지정한 이벤트가 들어오면 로직을 처리 (예 : kubernetes.var.log.containers.**이면 tag로 kubernetes.*로 지정할 경우 filter에 걸림)• None key_name을 log로

안녕하세요. 인벤토리 스쿼드 백엔드 개발자 펭귄대장입니다! 인벤토리 스쿼드에서 재고 변경 이력을 관리하기 위해 OpenSearch + EFK 를 구축하게 되어 소개 드립니다. 이전 포스팅에서 자주 언급되었듯이, 올리브영은 Datadog 을 사용하여 올리브영의 온오프라인 서비스를 모니터링 하고 있습니다. 이미 로그 확인과 서비스 모니터링을 위해 Datadog 을 사용 중인데, 왜 재고만을 위해 별도로 OpenSearch + EFK 기반의 로그 시스템을 구축하게 되었을까요? 올리브영의 재고는 입고, 점간 이동, 주문, 반품, 감모, 자소 등 30개 이상의 이벤트 타입이 존재하며, 당일 매장별 상품(SKU)의 기초 재고 데이터 생성을 시작으로, 전체 SKU 기준으로 하루 최소 천만번 이상의 재고 변경이 발생합니다. 또한 오늘드림 서비스, 구매 가능 매장 안내 등에서 사용자의 일관된 경험 제공 및 사용자 경험의 만족도를 높이기 위해 재고의 정합성을 확보하는 것이 중요하며 이를 위한 재고 변경 이력 관리 및 용이한 추적이 필요했습니다. 마지막으로 재고 API 를 사용하는 도메인과 서비스가 늘어나고 있으며 확장 가능성을 위해 OpenSearch EFK 를 구축하게 되었습니다. 정리하면 아래와 같은 이점이 있습니다.• 커스터마이징 가능성: OpenSearch EFK를 사용하면 개발자가 로그 및 이력 데이터를 자유롭게 구성하고 분석할 수 있습니다. 따라서 특정 요구 사항에 맞게 로그 데이터를 유연하게 처리할 수 있습니다.• 비용 효율성: OpenSearch의 Index Lifecycle Management을 활용하여 로그 데이터의 수명주기를 관리하고 비용을 절감할 수 있습니다. 필요에 따라 데이터를 자동으로 삭제하거나 아카이빙하여 비용을 최적화할 수 있습니다.• Rest API 지원: OpenSearch는 Rest API를 지원하므로 로그 데이터의 적재뿐만 아니라 조회 및 분석에도 유연하게 활용할 수 있습니다. 변경 이력을 조회하는 API 서비스를 제공하는 등의 확장이 가능합니다.그럼 이제부터 OpenSearch 와 EFK 가 무엇인지, 어떤 특징이 있는지 간단히 알아보겠습니다. EFK 는 아래 기술들의 앞 글자를 합친 말로 로그 및 이벤트 관리를 위한 기술 스택을 칭합니다. ElasticSearch/OpenSearch: 데이터 인덱싱/저장/분석/검색 Fluentd/FluentBit: 데이터 수집/변환 및 OpenSearch로 전송 Kibana: 데이터 시각화 대시보드 ElasticSearch 에서 2021년 1월 이후 OpenSource 정책을 폐기함에 따라, Amazon 에서 ElasticSearch v7.1을 fork 하여 만든 AWS 의 PaaS 서비스입니다.• 실시간 분석 (real-time): 데이터가 입력(indexing)되고 그와 동시에 near real-time 속도로 색인 된 데이터의 검색, 집계 가능• 전문 검색 엔진 (full text): 루씬 기반으로, 역 파일 색인(역 인덱스) 구조로 데이터를 저장하여

로그를 분석할때 유용하게 사용할 수 있는 EFK 스택을 정리해본다.• None EFK에 대해서 알아본다.• None EFK를 설치하는 방법을 알아본다.• None EFK관련 나의 생각을 간단하게 정리해본다.로그 데이터는 현대 소프트웨어 개발 및 운영에서 중요한 부분을 차지하고 있습니다.제가 EFK 를 사용하게된 이유는 제가 개인적으로 맡은 업무를 진행하다가 보니스패머들이 제가 맞고 있는 시스템으로 이상패킷을 가지고 공격을 하더라고요;;그래서, 해당 공격에 대해서 로그 분석을 하려고 했는데 쉘 명령어(grep, cat 등등)를 통해서통계서버에서 데이터를 추출해서 보려고 하니 몬가 1%부족함을 느껴서 이번에 EFK 스택을 도입하는 과정에 있습니다.해당 부분은 이 아티클에서 다뤄보고자 합니다.로그 분석을 위해서는 데이터를 효과적으로 수집, 저장, 시각화하고 분석하는 것은 서비스를 운영하며 개선및 안정성을 위해 너무너무 중요한데요.저는 이부분을 해결할 수 있는 것이 공부하다보니 EFK 라고 느꼈고 제가 맡은 서비스에 도입하려고 노력중에 있습니다.그럼, 차근차근 제가 경험한 EFK 스택에 대해서 정리해보도록 할께요~EFK 스택은 Elasticsearch, Fluentd, Kibana의 조합으로 이러한 작업을 간편하게 수행할 수 있는 강력한 도구라고 말씀드리고 싶네요.그럼, Elasticsearch, Fluentd, Kibana에 대해서 간단하게 정리해보자면요 아래와 같습니다.Elasticsearch는 실시간 분산 검색 및 분석 엔진입니다.즉, 대용량의 데이터를 저장하고 효과적으로 검색할 수 있는 기능을 가지고 있죠.특히 JSON 문서로 데이터를 저장하며, RESTful API를 통해 데이터에 접근할 수 있다는 점이 좋은것 같고요..Elasticsearch 는 뛰어난 확장성과 성능을 제공하여 대규모의 로그 데이터도 효과적으로 처리할 수 있는 장점이 있는 것으로 개인적으로 생각합니다.Fluentd는 데이터 수집, 전송 및 로깅을 위한 오픈 소스 플랫폼이라고 머릿속에 넣어두시면 되고요. json및 어플리케이션 로그등등 다양한 소스에서 로그 데이터를 수집하고 Elasticsearch와 같은 목적지로 전송하는데 사용됩니다.특히 확장 가능한 플러그인 아키텍처를 통해 다양한 데이터 소스 및 목적지와 통합이 가능하다는 점이 장점이고요.Kibana는 Elasticsearch에서 저장된 데이터를 시각적으로 탐색하고 대화식 대시보드를 구축할 수 있는 시각화 도구입니다.사용자는 효과적인 대시보드를 생성하여 로그 데이터의 트렌드 및 패턴을 쉽게 이해할 수 있습니다.Kibana 가 없으면 쉘에서 스크립트와 명령어를 통해서 패턴을 분석해야겠죠..이노력을 조금이나마 줄여줄 수 있는 것이 바로 Kibana 입니다.이제까지 EFK 스택에 대해서 간단하게 정리해보았는데요.한마디로 EFK 스택은 로그 데이터를 효과적으로 수집하고 시각화하는 강력한 도구라고 말씀드리고 싶습니다.Elasticsearch의 검색 엔진, Fluentd의 데이터 수집 및 전송, 그리고 Kibana의 시각화