왓챠 - 기술 블로그(로그플랫폼)

watcha-log-system.md

소개

안녕하세요. WATCHA 입니다.
WATCHA는 영화, TV, 도서를 평가, 리뷰를 할수있는 WATCHA와 영화, 드라마등 감상할수 있는 WATCHA PLAY 서비스를 제공하고 있습니다.
WATCHA에서 로그 수집 및 분석 시스템을 개선하면서, 경험한 내용을 공유해보자 합니다.

왜 로그 시스템이 필요했을까?

이전에 WATCHA에서는 로그를 RDB에 저장하거나, Third Party 솔루션을 이용하여 분석후 향후 방향이나 서비스 개선을 하고 있었습니다. 하지만 점점 성장함에 따라 사용자가 늘어나고있고, 로그 데이터양이 빠르게 증가하면서 기존에 구축된 시스템으로는 점점 느려지고, 빠르게 분석하기 어려워졌습니다. 그리고 여러 영역에 파편화된 로그로 인해 통합 분석이 힘들어져서 개선 필요성을 느꼈습니다.

그래서?

최대한 로그를 분석이 용이하게 1.한곳에 통합하고, 원하는 데이터를 2.빠르게 분석이 가능하고, 어떠한 환경이든 3.유연하게 수집 및 가공 가능한 시스템을 내부적으로 구축하기로 하였습니다.

1. 한곳에 통합

로그를 한곳에 저장, 빠르게 분석할수 있는 Google BigQuery를 이용하게 되었습니다.
선택했던 이유는 BigQuery는 Google 솔루션인 FireBase, Google analytics 등 클라이언트 영역에서 발생하는 로그들도 손쉽게 BigQuery에 통합이 가능하여, Web, App, Server 모든 영역에서 발생하는 로그를 한곳에 모을수가 있습니다.

2. 빠르게 분석

한곳에 분석용 로그가 모여 있으면, 원하는데이터는 쉽게 취합하여 분석이 가능하고, Google BigQuery를 이용하게 되면 대용량 데이터도 빠르게 분석이 가능합니다.

3. 유연하게 수집 및 가공

WATCHA 에서는 여러 서비스들이 AWS 내에 구성되어 있습니다.
서비스별로 Rails, NodeJs, Scala, Java, Python 등 다양한 플랫폼 및 언어로 구성되어 있고, 실행 환경도 다릅니다.
그래서 멀티클라우드(AWS, GCP), OS 및 특정 언어와 라이브러리에 종속적이지 않고, 실시간으로 로그를 유실 없이 수집하기위해서 여러 기술을 사용해서 구현하였습니다.

사용 기술스택

전체 로그 시스템 구성 설명에 앞서, 사용한 기술에 대해서 간략하게 설명합니다.

• 멀티 클라우드(GCP, AWS): 현재 WATCHA 대부분 서비스들은 AWS에 서비스중입니다. 그리고 로그시스템은 대부분 GCP를 이용하고 있습니다. 멀티클라우드 사이에는 보안연결로 VPN 통신하며, VPN 연결은 해당 링크를 참고 하시면 됩니다.

• Fluent-Bit: Fluentd의 경량버전입니다. C로 구현되어 있고, 라이브러리에 의존성이 없습니다. Fluentd보다는 가볍고 빨라서 대용량 로그 수집에 최적화 되어있습니다. 단점으로는 Zero Dependencies를 지향하다 보니 기본적으로 제공하는 기능이 적습니다.

• BigQuery: 모든 로그저장 및 분석용으로 사용합니다. STANDARD SQL 쿼리 형태로 검색 가능하며, FireBase, Google Analytics 데이터도 BigQuery에 통합가능합니다.

• PubSub: GCP에서 SAAS형태로 제공하는 QUEUE 서비스입니다. 대용량에 최적화 되어 있으며, 비슷한 기술로는 Kafka와 비교 되고 있습니다.

• Kubernetes: 도커 컨테이너 오케스트레이션 플랫폼이며, WATCHA에서는 Helm이용해 배포, 운영중에 있습니다. Consul, Prometheus, Grafana 로그 모니터링 시스템과 Airflow, Embulk와 같은 데이터가공 툴을 운영하고 있습니다.

• Consul, Prometheus, Grafana: Consul은 Service Discovery 서비스이고, Prometheus은 Metric 수집, Grafana는 수집한 Metric을 Visualization하는 서비스입니다. WATHCA에서는 해당 서비스들은 로그 모니터링시스템에 사용하고 있습니다.

• AirFlow: 데이터 가공을 위한 플로우를 관리하는 서비스입니다. WATCHA에서는 BigQuery에 있는 데이터를 여러 단계로 나눠서 원하는 데이터 생성(ETL)시 이용하고 있습니다.

• Embulk: 여러 데이터소스로 부터 다른곳으로 마이그레이션 해주는 서비스 입니다. 현재 WATCHA에서는 RDS데이터를 BigQuery로 마이그레이션하며, 좀더 분석이 용이하게 하기 위해 이용하고 있습니다.

• Flexible App Engine: GCP에서 docker로 배포하고 자동으로 autoscaling 해주는 SAAS 형태로 제공하는 솔루션 입니다. 여기선 PubSub으로 받은 data를 분석하여 처리하는 작업에 이용합니다.

• Elastic Cloud: Elastic사에서 만든 솔루션들을 직접 호스팅, 관리 해주는 Cloud 서비스 입니다. WATCHA에서는 실시간으로 유입되는 데이터를 분석, 검색 및 모니터링을 하기 위해서 Elastic Search 와 Kibana를 이용하고 있습니다. 장점으로는 Downtime 없는 업데이트, 안정성, 고객 서포트 및 다양한 X-PACK 및 Custom Plugin 지원합니다.

• DataStudio: Google에서 제공하는 Visualization 솔루션입니다. BigQuery와 통합하여 가공한 데이터를 그래프 형태로 사내에 공유하고 있습니다.

• CloudBuild: GCP에서 제공하는 CI/CD 툴입니다. CI/CD Pipeline을 구축하여 코드 커밋시 테스트케이스 통과되면 자동으로 배포되도록 이용하고 있습니다.

• Terraform: Code로 인프라를 관리해주는 툴로써 GCP 인프라 설정은 Terraform을 이용하고 있습니다.

• Golang: 동시성 처리 부분에 우수한 성능과 편리성을 제공하는 언어입니다. WATHCA에서는 Fluent-Bit Plugin 개발, 실시간으로 받은 데이터를 가공후 처리 및 여러 로직에서 이용하고 있습니다.

• Protocol Buffers: 여러 언어를 지원하는 직렬화 프로토콜입니다. WATHCA에서는 로그스펙을 Protobuf로 정의후, 여러팀에 문서화 필요없이 쉽게 공유하며, 사용언어에도 구애 받지않고 로그 수집에 이용하고 있습니다.

전체 로그 시스템 구성

로그 시스템은 수집파트, 처리파트, 모니터링파트 총 3부분으로 나누어져 있습니다. 아래는 전체적인 로그 시스템 구성도 입니다.

수집부분

로그 파일에서 데이터를 수집해 전송하거나, 서비스내에서 직접로그를 전송하는경우, 여러환경(사용언어, 라이브러리, OS ..등)을 고려해야하고, 로그를 추가할때마다 스펙에 대한 커뮤니케이션 비용이 발생하는 에로사항이 많습니다.
그래서 로그스팩을 쉽게 공유하고, 여러언어로 라이브러리로 제공 할수있는 Protobuf를 표준 프로토콜로 이용하고 있습니다.

수집 부분에서는 총 3가지 방식*으로 로그를 수집하고 있습니다.

• FireBase: FireBase를 사용해 Client에서 발생하는 로그수집를 합니다. 관리툴에서 설정만 조절하면 쉽게 BigQuery로 마이그레이션 됩니다.

• Fluent-Bit: 여러 서비스에서 로그 파일에서 로그를 수집합니다. Fluent-Bit 기능이 적은 관계로 PubSub에 로그전송과 모니터링을 위해 Consul에 등록하는 Plugin을 Golang개발후 C Shared Library형태로 컴파일해 이용하고 있습니다.
  전송 포맷은 Protobuf를 이용하고 있으며, 다른 서비스에 추가시에 쉽게 배포가 가능하도록 CLI툴을 개발하여 배포하고 있습니다.

• Direct 전송: 결제 이력과 같은 주요 이벤트는 서비스에서 직접 전송 하고 있습니다. 전송 포맷은 Protobuf를 이용하고 여러언어(Ruby, Scala, Javascript, Go .. 등)로 라이브러리 형태로 제공하여 편리하게 전송가능합니다.

처리부분

PubSub으로 받은 데이터 와 AWS내에 있는 RDS 데이터를 BigQuery 또는 Elastic Search에 저장하거나, BigQuery에 저장된 데이터를 배치처리로 가공, 분석 및 Visualization 하는 부분을 담당합니다. 그리고 실시간 분석 및 모니터링을 위해서 Elastic Cloud에서 Elastic Search 및 Kibana를 이용하고 있습니다.

• 실시간 BigQuery 저장: PubSub에서 로그를(Protobuf 형태) 전송받아 가공후 저장을 하고 있습니다.
  실시간 데이터 가공 및 저장은 다른 대안으로 Spark 유사한 Dataflow도 이용할수 있습니다.
  그렇지만 로그 추가 및 변경시에 코드수정 없이도 Protobuf 구조를 추출해 알맞은 BigQuery 테이블에 저장하거나 중복된 로그는 조건에 따라 자동 필터할수 있고 Elasticsearch 및 실시간 데이터가 필요한곳에 원하는 형태로 전달해주는등 다양한 용도로 이용하기 위해 직접 개발했습니다.
  현재는 동시성 처리부분에 개발이 쉽고 성능부분에서도 장점이 있는 Golang으로 개발되어있고, 성능적으로 튜닝도 하여 적은 머신으로 많은 데이터를 빠르게 처리 하고 있습니다.
  게다가 Protubuf 데이터를 Reflect하여 데이터타입과 테이블을 추론해서 코드 수정없이도 저장할수 있고, 상황상 발생할수있는 중복데이터는 해쉬화 및 로직을 통해 중복 저장되지 않도록 구현되어 있습니다.
  해당 프로세스는 Flexible App Engine에서 동작하고 있고, CloudBuild로 CI/CD 파이프라인을 구현하여 코드 변경시 자동으로 트리거되어 테스트케이스 통과후 자동으로 배포 되고 있습니다.
  배포 방식은 카나리(canary)배포로 하고있어, 일부 트래픽을 새로 배포된 프로세스로 옮기고, 이상징후가 없을시 전체 트래픽을 옮기는 방식으로 운영하고 있습니다.

• Embulk를 이용한 BigQuery 저장: 서비스 데이터는 AWS내에서 RDS로 저장되어 서비스에 이용되고 있습니다.
  로그만으로 데이터분석하기에는 한계가 있고, 서비스 데이터도 BigQuery내에서 로그랑 함께 분석하면 원하는 정보를 뽑을수 있다고 생각하여서, 주기적으로 Embulk를 통해 서비스 데이터를 BigQuery에 동기화 하고 있습니다.
  Embulk 프로세스는 Packer를 이용해 빌드후 주기적으로 K8S Pod 형태로 돌고 있습니다.

• Elastic Cloud 이용한 실시간 분석: BigQuery와 같은 빅데이터 분석용으로 만들어진 솔루션으로 실시간 분석, 가벼운 검색 및 특정 상황에 대한 모니터링을 하기에는 비용, 성능에 있어서 어울리진 않습니다. 그래서 Elastic Cloud에서 Elastic Search 와 Kibana를 SAAS형태로 이용하고 있습니다.
  Elastic Cloud에서 Elastic Search 와 Kibana를 이용하게 되면 Elastic사에 직접 관리 해주고 Downtime 없이 ElasticSearch 업데이트가 가능하고, X-PACK 및 Custom Plugin 도 손쉽게 사용가능하게 되어 있습니다.
  현재 WATCHA에서는 다양한 X-PACK을 이용하여 Single Sign On(SSO)을 적용하여 손쉽게 로그인이 가능하고, Security 설정 및 모니터링에 적극 활용하고 있습니다.

• 가공 및 Visualization: BigQuery에 1차 가공되어 저장된 데이터에서 좀더 원하는 정보를 얻거나, 특정 지표를 보여주기 위해서는 더 세부적인 데이터 가공이 필요합니다.
  그래서 AirFlow를 이용해서 여러단계로 걸쳐 데이터를 가공하여서 BigQuery 또는 Storage에 저장을 하고 있습니다. 이렇게 가공된 데이터는 DataStudio로 그래프 형태로 만들어져 사내에 공유하고 있습니다.

모니터링 부분

로그 Agent 상태를 모니터링 합니다. 이전에 예상치 못한 문제로 로그수집을 이뤄지지 않고 로그가 유실되는 상황이 있었습니다.(유실된 상황을 인지하는데도 오랜 시간이 걸렸습니다.)
모니터링 부분은 로그시스템에 가장 핵심적인 로그 수집부분에 발생할수 있는 상황에 대한 모니터링 및 대응을 위해 만들어 졌습니다.
서비스중인 서버들이 유동적으로 변화하는 환경에서 대응할수 있게 개발되어있고, Kubernetes + Helm 이용하여 손쉽게 배포 및 관리를 하고 있습니다.

• Consul: Fluent-Bit가 Consul에 등록을 하게되면, 서비스 별로 Live한 로그 Agent를 확인이 가능합니다. 주기적으로 HealthCheck 메시지를 보내어 Agne Live한지 체크합니다.

• Prometheus: Consul을 이용하여 서비스별로 Live한 Agent 리스트를 찾아, 직접 Agent에 접근하여 Metric을 수집합니다. CPU/메모리 사용량, 수집된 로그의 IN/OUT 수치 등을 수집합니다.

• Grafana: Prometheus에서 수집한 Metric을 Visualization해서 보여줍니다. 게다가 모니터링 알림을 설정하여, 이상이 있을시 Slack으로 알림을 전송합니다.

모니터링 부분은 전반적으로 로그 유실을 최소화하기 위한 목적으로 만들어져 있습니다. 게다가 Consul을 이용해 로그 Agent에 Runtime에 설정 바꾸는 부분에도 활용되고 있습니다.

배포/인프라 관리

전체적으로 정리해보면

• AWS 및 GCP 인프라 구성: Terraform 으로 관리되어 있어, 코드로 인프라를 관리하게 되어 변경이력을 알기 쉽고, 편리하게 이용하고 있습니다.

• Log Agent: Manual하게 배포를 위한 cli tool 직접 개발하여 운영을 하고 있습니다.

• Embulk: Packer를 이용하여 빌드후 private docker hub에 저장하고 있습니다.

• Data Pipeline(Go): CloudBuild를 이용하여 테스트 통과후 카나리(canary) 배포를 하고 있습니다.

• K8S Application: helm 패키지 매니저를 통하여 배포를 하고 있습니다.

결론

클라이언트, 서버로그 모두 BigQuery에 수집하게 되면서 디테일하고, 빠른 분석이 가능하고, 쉽게 공유가 가능해 사용하는 시간 및 노력에 비해 만족도가 높습니다.
Learning 비용이 많지 않고, Standard SQL을 지원하기에 쉽게 쿼리하여 원하는 데이터도 뽑아 볼수 있습니다.
그러나 개발자가 아닌 분들도 원하는 정보를 얻을수 있는 UI 제공과 같은 편의성 기능이라던지, 데이터 파이프라인 편의성 제공 등과 같이 개발자가 손쉽게 접근할수 있는 구성, CPT ..등 늘어나는 서비스를 위한 성능 개선을 위해 아직 앞으로더 진행해야할 작업들이 많습니다. 그런 부분도 같이 개선하고, 성장할 개발자를 모집하고 있습니다. 연락주세요.

구현 스펙이 꽤 커서 수집, 처리, 모니터링 파트를 각각 글 1개로 써서 3부작으로 만들어도 충분히 좋을 것 같아요! 🙌

길게 쓸려면 길게 쓸수도 있지만, 공수가 많이들어서 3부작으로는 힘들꺼 같아요 ㅋㅋ