[01] NDC18 - 로그 시스템 구축 경험 공유

개굴로그·2023년 3월 26일
NDC18데이터엔지니어링
0

presentation-review

목록 보기
1/1

개요

앞으로는 제가 감명깊게 본 발표 자료에 대해 요약을 시리즈로 운영해보려고 합니다.

그 처음이 될 글은 로그 시스템에 관한 발표자료이며, 크게 5가지 파트로 나뉘어져 있습니다.

발표 제목: [NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유
발표자: 전효준
NDC18-전효준님 발표자료


1. 로그는 쌓아서 뭐하나

발표에서 나온 로그는 크게 '서비스 로그' 와 '시스템 로그' 로 나뉩니다.

  1. 서비스 로그
    • 서비스를 운영하면서 발생하는 로그 (Ex. 아이템 획득 기록, 로그인 기록, 등)
    • 서비스 운영 / 의사결정을 위한 분석 / 주요 지표 추출 등
  2. 시스템 로그
    • 시스템에서 발생하는 로그 (Ex. 클라이언트 요청 기록, 서버 응답 기록, 오류 기록 등)
    • 개발자 생산성 확대 / 빠른 이슈 대응 등

이를 종합해보았을 때, 지속적 발전을 위한 중요한 요소 = 로그 인 것입니다.
(** 발표에서는 '요소' 대신 '도구' 라고 나왔습니다.)


2. 로그 시스템의 목표

로그 시스템이란 무엇일까요?
개인적으로는 위에서 보았던 분석, 지표 추출, 이슈 대응과 같은 로그를 가지고 작업을 하기 위한 준비 과정 을 로그 시스템이라고 생각합니다.


그렇다면, 좋은 로그 시스템이란 무엇일까요?

발표자분께서 제시한 로그 시스템의 목표 는 다음과 같습니다.
이는, 로그 시스템을 설계하시는 많은 엔지니어 분들의 목표와 비슷할 것이라 생각됩니다.

  1. 높은 가용성
    • 시스템이 죽으면 로그가 유실되기 때문에 높은 가용성이 보장되어야 함.
    • 항상 잘 살아서 돌아가는 시스템
  2. 실시간 조회
    • 빠르고 쉽게 로그를 조회할 수 있어야 함
    • 또한 원하는 로그 검색이 가능해야 함
    • 이는 생산성 향상과 직결
  3. 분석 및 시각화
    • 빠른 분석
    • 분석 결과 또는 지표에 대한 시각화
  4. 관리부담 최소화
    • 로그 유입량에 따른 Auto Scale out

즉,
알아서 (관리부담 최소화)
잘 (높은 가용성) 수집하고
빠르게 조회(실시간 조회)하고
분석(분석 및 시각화) 할 수 있는

로그 시스템이 곧 좋은 로그 시스템이라고 할 수 있을 것 같습니다.


3. 로그 시스템 아키텍처

이 파트의 경우 각 컴포넌트에 대한 설명이 나와있는데, 이는 직접 발표자료를 보시는 것을 권장드립니다.

로그 시스템 아키텍처는 크게 3단계로 나뉩니다.

  1. 수집

    • 서버에 쌓인 로그를 수집하고 적재하는 과정 (ETL)
      • Fluentd: 로그 수집 Agent
      • AWS Kinesis: 관리형 스트리밍 데이터 저장(큐) 서비스
      • AWS Lambda: 데이터 처리를 위한 Serverless 컴퓨팅 서비스 (Kinesis의 이벤트 트리거)
      • AWS S3: 데이터 저장소

  2. 조회

    • 추가적인 AWS Lambda 를 사용하여 Elastic Search에 데이터 적재
      • ES에서 실시간 조회가 가능
      • Kibana를 통해 시각화 가능
      • AWS Elasticsearch Service 사용 (완전 관리형 서비스)
    • 요금 이슈
      • 최근 3개월의 로그만 저장
      • 그 이후의 로그는 S3에 저장된 로그 사용

  3. 분석

    • AWS EMR: 클러스터를 구성하기 위해 사용.
      • Apache Spark: 인메모리 방식을 통해 데이터를 처리하는 Cluster Computing Engine (범용 분산 플랫폼)
      • Zeppelin: 대화식 분삭이 가능한 웹 기반 노트북 (Spark 사용을 쉽게 해줌)
    • AWS DataPipeline: Batch Job 구성
      • 특정 시간에 + 클러스터를 실행하고 + 특정 JOB을 수행하라
      • Job이 실패한 경우 자동 재시도
      • 실행이 끝난 경우 클러스터 종료(자원 반납)

확장 포인트
1. Kinesis: 로그 유입량에 따른 샤딩 확장 및 축소
2. EMR: 분석 시간을 줄이려면 Cluster 확장

저희 회사에서는 AWS 대신 GCP를 사용하고 있는데, 파이프라인 구성은 비슷해보이네요.

약간 다른 점이 있다면

  1. Kinesis와 비슷한 기능을 하는 Cloud Pub/Sub 대신
  • Cloud Logging에 데이터를 저장합니다.
  • 기본적으로 GCP에서는 Cloud Logging 이라는 서비스를 통해 GCP의 다양한 서비스(Compute Engine, Cloud Storage, App Engine) 로그를 수집합니다.
  1. Lambda와 비슷한 기능을 하는 Cloud Function 대신
  • Log Router를 사용하여 Cloud Logging에 쌓인 데이터들을 쿼리로 추출 후 BigQuery에 쌓게 됩니다.

비슷한 상품군: (Fluentd -> Google-Fluentd, Kinesis -> Cloud Pub/Sub, Lambda -> Cloud Function, S3 -> GCS)


4. '잘' 사용하기

해당 챕터에서는 위에서 설명드렸던 로그 시스템 아키텍쳐의 각 컴포넌트들을 '잘' 사용하는 방법에 대해 설명해주셨습니다.

AWS의 컴포넌트에 대해 깊이 있게 설명해주셨는데, 이거는 요약하는게 맞을까 싶네요..
위 아키텍쳐에서 꽤나 중요한 내용이라 직접 발표자료를 읽으시는게 더 도움이 될 것 같습니다.

  1. Kinesis 와 Lambda (발표자료 참고)

  2. 로그 저장 방식

    • Lambda를 통해 1000개의 로그를 Json 파일로 저장
    • Json 로그를 Parquet 형식으로 가공 (1시간 배치)
      • Parquet: 스키마를 가진 컬럼형 저장 포맷
      • 이를 통해 수많은 파일을 몇 개의 파일로 변환할 수 있으며
      • 네트워크 비용을 줄이는 효과를 가져옴
    • Table Partitioning
      • date를 Partition 기준으로 설정
      • 조회 시 날짜를 특정하여 조회 비용(네트워크 비용)을 줄여줌

  3. 로그 스키마 관리

    • 구조화된 데이터 유형(Json, Parquet)을 사용하기 때문에 스키마 관리가 필수
      • 다양한 로그 유형 = 다양한 스키마
      • 새로운 스키마는 언제든지 추가될 수 있어야 함
      • 스키마 변경에 대해 컬럼 추가만 가능 (하위호환성 유지)
    • 로그 스키마 업데이트 (서버 코드 상에서 로그 스키마 관리)
      • 스키마 별 Class 추가 또는 업데이트
      • 새로운 버전 배포시 Spark StructType JSON 포맷으로 스키마 추출
      • S3에 스키마 저장 (스키마 저장소를 따로 관리)
      • Parquet 변환시 스키마 정보를 읽고 변환 수행

  4. EMR Spark 클러스터 스펙

    • 메모리, 네트워크 속도를 고려하여 설정

사실 이 챕터가 누군가에게는 이번 발표의 핵심일 수도 있겠다는 생각이 들었습니다.
AWS를 사용중인 회사라면 더더욱 그럴 것 같네요.

개인적으로는 S3에 저장된 Parquet를 가지고 쿼리를 날릴 수 있다는게 신기하네요.. GCP도 되나 궁금해요.


5. 개선할 점

마지막으로는 설계한 시스템에서 개선할 점을 발표해 주셨습니다.
이 파트는 제가 해당 데이터 파이프라인에 대해 자세하게 알지 못하기 때문에 간단하게만 요약하려고 합니다.

  1. 분석의 대중화
    • 분석을 원하는 사람은 많으나, 분석을 할 줄 아는 사람(SQL을 다루는 사람)은 적다.
  2. 분석 규모에 따른 Auto Scaling
  3. 시각화의 다양화
    • Zeppelin 에 매우 의존 (제한이 많음)
    • 복잡한 시각화의 경우 Jupyter Notebook 사용
  4. 로그 스키마 변경
    • 이미 쌓인 로그에 대해 Migration 불가능
    • 컬럼 이름 변경이 안되서 야기되는 불편함 존재
  5. 로그 파악의 어려움
    • 각 로그 스키마에 대해 파악이 어려움
    • 문서화의 필요성

여기까지 [NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유 발표에 대해 요약을 해보았습니다.

처음 이 발표 자료를 보았던 시절에는, 데이터 파이프라인이 뭔지도 모르는 응애 개발자였어서 감흥이 없었습니다.

듀랑고 라는 게임내에서 쌓이는 로그의 예시부터, 로그 시스템의 목표, 로그 시스템 아키텍처(데이터 파이프라인), 그 파이프라인에 녹아져 있는 노하우, 그리고 개선점까지...

최근에 다시 읽어보니, 이건 데이터 엔지니어로 들어온 신입분들에게 무조건 추천해주고 싶은 발표자료네요.

이러한 발표자료를 모두에게 공유해주시고 포스팅을 허락해주신 전효준님께 다시 한 번 감사드립니다.
저도 언젠가는 이러한 발표를 할 수 있는 엔지니어가 되길 희망하며, 이상으로 글을 마치겠습니다.

긴 글 읽어주셔서 감사합니다.

profile
개굴로그
gaegul

0개의 댓글