1. 개요
watch 에서는 필요에 따라 로그 데이터를 접근성이 편리한 rdb에 저장하거나, 여러 외부 솔루션을 적용하여 다양한 패턴 분석을 통해 서비스 개선을 하고 있다.
하지만, 서비스가 성장함에 따라 로그 데이터가 빠르게 증가하면서 기존에 구축된 방식을 이용해서는 분석이 어려워져 빠른 개선이 필요한 상황
로그를 한곳에 통합, 데이터를 빠르게 분석하고, 어떠한 환경에서도
유연하게 수집 및 가공이 가능한 시스템 구축이 필요
2. 프로젝트 목표
1) 로그를 한곳에 통합,
- 로그를 한곳에 저장 빠르게 분석 가능한 구글 빅쿼리 사용
- 구글 솔루션인 firebase, google analytics 등 클라이언트 영역에서 발생하는 로그들도 손쉽게 bigquery에 통합 가능
- Web, app, server 등 모든 영역에서 발생하는 로그를 모을 수 있음
2) 데이터를 빠르게 분석
- 빅쿼리를 이용한 대용량 데이터 분석 및 한곳으로 로그를 모음으로써 효율적인 취합, 분석 가능
- 어떠한 환경에서도 유연하게 수집 및 가공 가능한 시스템 구축
- 여러 서비스들이 aws 내 , 다양한 플랫폼 및 언어로 구성, 실행환경도 다름
3) 멀티클라우드, 특정 언어와 라이브러리에 종속되지 않고 실시간으로 로그 수집을 위한 여러 기술 사용
3. 전체 로그 시스템 구성
로그 시스템은 수집, 처리, 모니터링 3개의 파트로 나뉘어져 있음
4. 수집 부분
로그 파일에서 데이터를 수집하여서 전송하거나, 서비스 내에서 직접 로그를 전송하는 경우, 여러 환경을 고려해야하며, 로그 추가 시, spec 에 대한 커뮤니케이션 비용이 발생하는 애로 사항이 많다.
그래서 로그 구조를 쉽게 공유하고, 여러 언어로 라이브러리로 제공할 수 있는 protobuf 를 표준 프로토콜로 이용
수집부분에서는 3가지 방식으로 로그를 수집한다
1) firebase
- 클라이언트에서 발생하는 로그를 수집, 관리툴에서 설정을 조절하면 쉽게 빅쿼리로 migration 됨.
2) fluent-bit
- 여러 서비스의 로그 파일을 수집, fluent-bit 는 기능이 적어서 pubsub 으로 로그 전송
- 모니터링을 위해 consul 에 등록하는 플러그인을 개발 후 이용
3) direct 전송
- 결제 이력과 같은 주요 이벤트는 서비스에서 직접 전송
- 전송 포맷은 protobuf 를 이용하여 여러 언어로 라이브러리 형태로 제공하여 편리하게 전송 가능
5. 처리 부분
- pubsub 에서 로그를 전송받아 가공 후, 저장하고 있음. 새로운 부분ㄴ이 추가되더라도 자동으로 빅쿼리 테이블에 저장되며, 로직 변경 없이도 새로운 로그 포맷에 대응.
- 카나리 배포 방식을 사용하고 있음
- embulk 를 이용하여 빅쿼리에 저장하고 있음. embulk 를 통해 rds 데이터를 빅쿼리에 동기화
- 서비스 데이터는 aws 의 rds 로 저장되어 서비스에 이용 중
- elastic cloud 에서 elastic search 와 kibana 를 이용함
- 왓챠에서는 how-warm 클러스터 구조로 elastic search 를 구성, 최신 데이터는 hot 노드에, 기간이 지난 데이터는 warm 노드로 이동
6. 모니터링 부분
- 모니터링 부분은 이런 로그 수집에 대한 모니터링 및 대응을 하기 위해 만들어짐.
- 서비스 중인 서버 및 새로 개발되는 서비스 서버들도 유동적으로 변화하는 환경에서 대응할 수있도록 개발
- kubernetes + helm 을 이용해 손쉽게 - 배포 및 관리 가능
1) consul
- fluent-bit 가 consul 에 등록하게 되면, 서비스 별로 로그수집 에이전트가 live 한지 체크. Healthcheck 메시지를 보내 로그수집 agent 가 live 한지 체크
2) Prometheus
- consul 을 이용하여 서비스별로 live 한 에이전트 리스트를 찾아, 직접 agent 에 접근하여 metric 을 수집. Cpu/메모리 사용량, 수집된 로그의 in/out 수치 등 수집
3) grafana
- Prometheus 에서 수집한 metric 을 시각화해서 보여줌. 모니터링 알람 설정 가능
7. 배포 / 인프라 관리
- 모든 개발 영역에서 필수적인 부분
- 잘 만들어진 tool 을 사용하고 코드로 관리하도록 해서 manual 하게 사람이 배포 및 관리하는 작업을 최소화하는 방향으로 진행
8. 결론
왓챠의 데이터 파이프라인은 다른 서비스를 연결해서 사용한다는 것이 특이점이라고 볼 수 있을 것 같다.
보통 데이터 파이프라인이라고 하면.. 같은 서비스(예를 들면 aws 만 사용한다던가..) 내의 서비스들을 활용하여 최적의 파이프 라인을 구축하는 것을 생각하게 되는데..
왓차의 경우에는 필요한 서비스가 있으면 다른 서비스에서 가져와서 그것을 활용하는 모습은 차후 데이터 파이프라인 구축에 있어 배워야될 점이라고 생각된다. 한가지 클라우드 서비스만을 이용하는 것보다는 다른 클라우드에 있더라도 장점이 있는 서비스를 이용할 수 있다면, 좀 더 유연하게 나의 서비스를 운영할 수있기 때문이지 않을까 한다.
실제로, 왓챠에서는 유연하게 서비스를 이용한 결과 여러가지 positive 한 이득을 얻고 있는 것 같다.
- 대용량 데이터 분석에 큰 메리트가 있는 BigQuery를 이용하여 클라이언트, 서버 등의 데이터를 통합하여 다양한 분석이 가능해 졌고, Standard Query 형태로 분석이 가능해 접근성도 많이 좋아졌습니다.
- 그리고 Elastic Cloud를 이용하면 Hot-Warm 구조 ElasticSearch 클러스터를 손쉽게 운영하는 것이 가능하며 SSO, Security 등 X-PACK 및 Custom 플러그인 사용이 가능합니다.
- lastic사에서 직접 개발 서포트 및 Downtime 없는 빠른 업데이트를 할 수 있어 큰 메리트가 있습니다.