타사 로그 파이프라인 / 모니터링 지표 수집 시스템

베스핀 추천 

https://www.bespinglobal.com/stackdriver-gcp-monitoring-20180813/

Stackdriver를 이용한 GCP의 로깅 및 모니터링 소개 - BESPINGLOBAL

- 현재는 stackdriver에서 monitoring으로 변경됨

- https://console.cloud.google.com/monitoring/dashboards/resourceList/kubernetes?authuser=0&project=mlops-dev-344406&supportedpurview=project&timeDomain=1h&pageState=(%22integrations%22:(%22p%22:7),%22interval%22:(),%22gkeTableState%22:()) 

 

29cm - 무신사 로그 시스템 ( 2021.07.9)

https://medium.com/29cm/29cm-%EB%A1%9C%EA%B7%B8-%EC%88%98%EC%A7%91-%EC%8B%9C%EC%8A%A4%ED%85%9C-%EC%86%8C%EA%B0%9C-e7955d7deec6

29CM 로그 수집 시스템 소개

기존 로그 시스템

- fluntd는 각각의 서버에 사이드카로 들어감

- fluntd의 컨테이너들은 fluentd aggretator한테 데이터 송신해서 모든 로그 데이터를 집계해서 ES에 인덱싱함

 

문제 발생

elasticsearch의 disk 부족으로 적재 실패 - slack 알림

디스크 증량했지만 증량 기간동안의 데이터 유실

데이터 유실되지 않도록 신규 로그 시스템 구축

 

기존 아키텍처의 단점

ES가 느려지거나 일시적인 장애 발생시 fluentd aggregator가 버퍼 역할을 해줘야함

fluentd aggregator 구축 방법

1. 파드에 PV를 연결해 파일이나 memory에 데이터를 씀

2. PV를 연결하지 않고 pod 내 파일이나 memory에 기록

 

PV연결 시 문제

Fluentd의 장점인 수평 확장을 하게되면 PV를 하나씩 다 연결해줘야하기 때문에 볼륨 확장에 제약이 생김

memory에 기록하기에는 너무 많은 리소스를 사용할 수 있음

 

pod내 작성시 문제

pod 재시작시 휘발됨

실제로 이 방식을 사용하는데 디스크 부족일 때 aggregator가 메모리가 치솟으면서 OOM killed나고 데이터 없어짐

 

신규 로그 시스템

 

kafka 도입

- ES에서 장애가 나도 kafka가 버퍼 역할을 해주어 기록된 로그 자체가 유실되지 않도록 함

- kafka의 retention을 3일로 지정. 주말에 ES가 장애가 나도 복구되는 즉시 kafka의 로그데이터를 ES에 인덱싱 할 수 있음

 

fluentd를 logstash로 변경

- logstash의 베이스 이미지에는 kafka 플러그인이 기본으로 설치되어있음 (fluentd는 미설치)

 

프로토콜 선택 이유

29CM 내부에서는 TCP 프로토콜의 사용이 어려운 인프라 운영환경이 존재하고,

추후 카프카의 Rest Connector로 변경할 가능성까지 고려하여

http 프로토콜 기반의 로그 전송 프로토콜을 사용하는 것으로 결정

 

* 추후 kafka 튜닝 포인트 - 1) 어떻게 처리량을 높이고 2) 가용성을 늘릴 수 있을 지 (본문 참고)

 

네이버 - 검색 (2017 deview)

- https://deview.kr/2017/schedule/201

백억 개의 로그를 모아 검색하고 분석하고 학습도 시켜보자: 로기스

 

로그 처리 플랫폼을 자체 제작함

 

1) 모든 로그를 한 곳에서 모음

2) 로그 타입을 정의

3) 검색 기능 제공

4) 빅데이터 처리를 위한 로그 데이터 수집을 별도로 함

 

* data scientist는 전체 데이터를 가져와야할 경우가 있음

- elastic search는 특정 로그를 검색하는 용도여서, 모든 데이터를 가져오면 장애가 쉽게 남

- 검색은 elastic search에서, 많은 데이터 처리는 HBase에서로 나눔

elastic search

- 로그 브라우저 제공 -> 문제 추적, 데이터 가시화

- elastic search api 제공 -> 사용자 대시보드, 알림 시스템 구현, 딥러닝 등의 프로토타이핑

 

분산 저장 시스템 HBase

- 빅데이터 처리

- ml 학습에서 사용할 데이터

 

 

전체 아키텍처

- 앞쪽 logstash들이 클라이언트에서 수집된 로그를 처리 (다양한 프로토콜 및 트레픽을 처리하기 위한 분산처리)

- kafka로 수집

- 뒤쪽 logstash들로 로그를 파싱함. 보안 문제로 개인정보를 여기서 다 제거하고, 특정 권한을 가진 사용자만 로그를 조회할 수 있게함

 

로그 포맷

- 로그의 시간으로 APM 자체 제공 (영상 32:30에 시연 나옴)

 

하이퍼커넥트 - 라이브 스트리밍 추천 시스템 (22.01.24)

https://hyperconnect.github.io/2022/01/24/event-driven-recsys.html

이벤트 기반의 라이브 스트리밍 추천 시스템 운용하기

실시간 방송중인 스트리머를 취향에 맞춰 추천해주는 시스템

실시간 모니터링 데이터를 가져와 다시 input data로 사용하는 방식

 

특징

1. 실시간으로 현재 방송중인 스트리머만 추천해야함

2. 컨텍스트가 자주 바뀌기 때문에 실시간 데이터를 기반으로 inference를 해야함

- batch job으로 DB에 쌓아놓고 가져오는게 불가능

추천 DB를 바탕으로 비 실시간으로 동작하는 추천 시스템과(좌), 추천 API를 통해 실시간으로 동작하는 추천 시스템(우)

 

* 복잡도가 높은 실시간 추천 시스템 -> MSA와 이벤트 주도 아키텍처를 적용

- 높은 확장성과 낮은 결합도 보장

 

이벤트 주도 아키텍처의 장점

- 커뮤니케이션 비용을 최소화할 수 있음 (aipex에도 좋은 요소일듯)

 

ex) 추천 모델에서 평균 시청 시간을 input feature로 사용하려고 함

event driven이 아니면

1. 해당 api를 추가하도록 요청

2. 여러 msa에서 공유하는 DB 생성

 

api를 추가 요청할 때의 문제

api가 완료될 때까지 기다려야함

작업자와의 커뮤니케이션으로 오버헤드 발생

 

공유 DB 방식의 문제

다른 msa에 side effect가 생길 수 있음

write가 조심스러움

 

event driven이면

pub쪽은 이벤트 버스에 발행만 하면됨

sub쪽이 알아서 이벤트를 가져와 처리하면 됨

자유도가 높고 새로운 feature의 추가 속도가 빨라짐

 

Shared database 기반의 MSA와 (좌), Event 기반의 MSA (우)

아키텍처

하이퍼커넥트의 라이브 스트리밍 추천 백엔드 시스템

kafka에서 수집한 데이터는 apache flink라는 실시간 데이터 처리 프레임워크를 통해 가공됨

비동기로 flink에서 처리된 데이터는 db나 redis에 들어가게됨

필요한 데이터가 요청될 때가 아닌, 이벤트가 발행될 때 미리 가공하게 됨 - 하이퍼커넥트에서는 수십개 이상 피쳐를 사용하지만 동시에 수백개의 item이 담긴 추천 리스트도 수십~수백 밀리 초안에 처리되고 있음

 

카카오 - 전사 리소스 모니터링 시스템 (2016.08.25)

https://tech.kakao.com/2016/08/25/kemi/

카카오의 전사 리소스 모니터링 시스템 - KEMI(Kakao Event Metering & monItoring)

 

시스템 모니터링 지표

배치 job으로 1분마다 실행됨

인프라 시스템에서 매트릭 지표를 가져와 kafka에 데이터 넣음

(gcp 사용하면 대치 가능할듯)

 

로그 파이프라인

- 서비스 별 로그는 각 서버에 설치된 fluentd로 수집

- 로그를 hadoop과 kafka에 넣음

- hadoop은 batch job을 통해 10분 텀으로 elasticsearch로 indexing하고, kinana로 대시보드 제공

- kafka에 저장된 데이터는 etcd나 redis를 기반으로 실시간 알림

 

 

쏘카 - 데이터 엔지니어링팀 (2021.03.24)

https://tech.socarcorp.kr/data/2021/03/24/what-socar-data-engineering-team-does.html

쏘카 데이터 그룹 - 데이터 엔지니어링 팀이 하는 일

자유로운 통합 데이터 분석 환경 만들기

운영중인 서비스의 데이터들을 한 곳에 모아서 별도의 데이터 분석 환경을 제공해줘야함

데이터 수집 툴로 airflow 사용

통합 저장소로 bigquery를 사용

- bigquery 도입 이유 : 당장 사용하기 쉽고 인프라나 운영에 크게 신경쓸 것이 없기 때문입니다. 또한 비용도 저렴하고 쿼리 속도도 뛰어납니다.

 

아키텍처

기타 GCP 활용 예시

1.

https://m.blog.naver.com/olpaemi/222206599211

엘라스틱스택과 Operations(스택드라이버)로 간단하게 구글 클라우드 모니터링 환경 구축하기 (1) #O

 

- 구글 클라우드 리소스의 Audit, Firewall 및 VPC flow logs를 Operations(스택드라이버)로 전송

- Sink, Pub/Sub Topic을 만들어서 파일비트(Filebeat)로 구독해서 엘라스틱서치로 데이터를 전송

- 엘라스틱서치 데이터를 키바나로 확인

* 파일비트는 수집하고자 하는 서버나 호스트에 직접 인스톨해서 로그를 수집하는 것도 가능하지만 에이전트를 인스톨하기 힘든 환경에 대해서는 Operations(스택드라이버)를 이용해서 수집할 수 있음

 

2.

https://morioh.com/p/1436e06b8681

Exporting GCP Stackdriver logs to ELK Stack on Elastic Cloud

 

 

** 모델 서빙 **

https://tv.naver.com/v/23650633

어떻게 더 많은 모델을 더 빠르게 배포할 것인가? Zero-time delivery cycle from research to production

 

https://blogs.nvidia.co.kr/2021/06/04/simplifying-ai-inference-in-production-with-triton/

NVIDIA Triton 추론 서버로 AI 개발 ‘뚝딱’ | NVIDIA Blog

 

 

 

고려사항

모니터링 지표로 사용하기 위해서는 로그를 한곳에 모아서 api로 쿼리를 날려야함

 

elasticsearch : 지원됨

datadog : 15초 간격으로 batch 처리되어 지원됨

 

1. ELK를 붙이지 않고 gcp logging만 그대로 사용할 수 있을까?

- gcp logging에도 api 검색을 지원할까

 

2. 모든 로그를 한곳에 모아야함 -> 저장공간을 우리가 컨트롤할 수 있어야함

- elasticsearch는 가능

- datadog는 계약에 따라 저장 기간이 달라짐

- gcp logging은 확인해봐야함

 

3. kafka를 써야할지말지

 

4. gcp에서의 로그 파이프라인 사례

- kafka와 elk를 결합한 사례가 많은지