[TIL - 67일 차] Kafka와 Spark Streaming 기반 스트리밍 처리 (2)

Udemy 데이터 시스템 발전 여정 살펴보기

Udemy 데이터 팀 빌딩 여정

2014년 8월 : 데이터 엔지니어링 팀 설립

• 데이터 웨어하우스 (Redshift) 도입
• 데이터 소스 추가 요청을 받는 슬랙 채널 개설
• ETL 프로세스 개발
  • 처음에는 crontab으로 관리하다 Pinterest의 Pinball로 이전
  • 기본 개발 언어는 파이썬, 지금은 Airflow 사용
  • B2B 강사 보수 계산 (소비율에 따라 계산)
  • 중요 파이프라인의 경우 SLA (Service Level Agreement) 설정 후 지표 계산
• 백엔드/프런트엔드 엔지니어링 팀과 다양한 협업 시작
  • Incremental Update를 하기 위해 프로덕션 DB 테이블 스키마 변경
    • updated_at과 deleted 필드 추가
  • 사용자 이벤트 로그를 프로덕션 DB에서 nginx 로그로 빼는 작업 수행
    • 처음에는 이를 파이썬 스크립트로 처리
    • 나중에 이를 Hadoop 클러스터를 만들고 HDFS로 복사한 뒤 Hive로 처리
    • 궁극적으로 Kafka에 적재하고 다수의 Consumer로 처리 (Connect 사용)
    • 사용자 이벤트를 처리하는 마이크로 서비스를 구현하고 K8s 위에서 실행

2015년 4월 : 데이터 분석 팀 설립

• Decision Science 팀
• BI 툴 도입 (ChartIO -> Tableau)
• B2C 마케팅 기여도 분석 프로세스 정립
• B2B 세일즈 파이프라인 분석 프로세스 정립
• 내부 직무 전환 제도를 통해 디지털 마케터를 분석가로 뽑음
• 데이터 분석 요구 프로세스 도입
  • 티켓의 수와 카테고리가 데이터 관련 만족도와 개선 방향의 중요 지표가 됨
  • 투명성의 중요성
• 지표 표준화
  • 매출, Active Students, Active Instructors 등
  • 지표 기반 의사결정 방법 교육 -> Next Feature Fallacy (지표의 수를 늘리려고 함)
  • 지표의 수는 적은 게 좋음
• 현업 팀과의 협업 가속화
  • 하이브리드 모델
  • 해결하는 수보다 요청이 더 많기에 Self-service 모델로 전환을 모색
  • 매주 두 번 데이터 관련 오피스 아워 진행
  • 데이터 관련 요청이 모두 보이는 슬랙 채널 개설

2015년 4월 데이터 사이언스 팀 설립

• Product Science 팀
• ML 모델을 프로덕션에 사용하기 시작
• A/B 프로세스 도입
• ML 모델 배포 프로세스 도입
  • 엔지니어링 팀과 긴밀한 협업 시작
  • MLOps 프로세스 정착
• 다양한 조직에서 ML 관련 도움 쇄도
  • 인력 부족
  • 분산 환경으로 전환 필요성 절감

Udemy 추천 엔진 1기

2015년 5월 : ML 추천 모델 개발 시작

• Hadoop 클러스터 도입
  • 클라우드가 아닌 On-prem에 직접 설치
  • 배치 처리에 초점을 맞춤
  • Hive와 Python 기반 UDF로 사용자 이벤트 데이터 처리

Hadoop

• Nginx
  • 보통 웹서버의 앞단에 로드밸런서(Load Balancer)로 사용
  • 동시에 요청을 로그하는데 사용 (HTTP 요청 헤더와 응답 헤더 내용을 기록)
  • 다수의 서버에게 로드를 분배하며 문제가 있는지 체크

Nginx

• A/B 프로세스 도입
  • 객관적인 비교 프로세스를 도입하기 위함
  • 자세한 분석을 위해 Tableau를 대시보드 툴로 도입
• 모델 배포 프로세스 협의 시작
  • 사용자별 추천 강의를 하루에 한 번 저장하는 걸로 시작 (Daily Batch Processing)
  • MLOps 프로세스를 도입하여 매일 모델을 새로 훈련
  • 하둡 클러스터의 도입 없이는 불가능
• 모델 배포 프로세스 과정
  1. R로 만든 모델 빌딩 : 훈련 데이터는 Hive로 정제
  2. 모델을 PMML 포맷으로 덤프
  3. 자바로 만든 추천 마이크로 서비스에서 API 형태로 서빙

Udemy 데이터 인프라 클라우드 이전

On-prem에서 구축하는 데이터 인프라의 운영 비용, 노력이 만만치 않기 때문에 인프라를 클라우드로 이전하는 작업을 진행하였다.

2016년 : 클라우드 이전

• 직접 데이터 센터를 운영하는 경우 서버 증설에 보통 2-3달
• On-prem과 클라우드의 하이브리드 모델에서 클라우드로 이전
  • 기존 On-prem 서버는 개발용으로 전환
  • 서버 용량 확장에 걸리는 시간 대폭 감소 : 주문 - 배달 - 조립 - 설치 과정 불필요
• S3 등을 사용하면서 데이터 시스템 발전에 큰 도움이 됨

2016년 : 데이터 레이크와 Spark 도입

• Hive 중심의 YARN/Hadoop 환경에서 Hive/Spark 중심으로 변화
  • Spark 트레이닝 과정을 모든 데이터 엔지니어들과 원하는 데이터 과학자에게 제공
  • S3를 데이터 레이크와 HDFS로 사용
  • Hive meta-store 중심으로 테이블을 저장

Hive + Spark

• 여전히 Redshift를 정제된 구조화 데이터 분석을 위한 데이터 웨어하우스로 사용
• 데이터 엔지니어를 중심으로 Spark 교육 시작
  • 처음에는 Scala로 개발하다가 나중에 PySpark로 넘어감
  • Notebook(Jupyter, Zeppelin) 환경으로 데이터 과학자들도 Spark ML을 직접 사용하기 시작

Udemy 추천 엔진 2기

Kafka를 도입하면서 추천 엔진을 배치 중심에서 real-time으로 변경하였다.

2016년 : Kafka 도입

• 실시간 데이터 처리에 대한 요구 증대 : Kafka 도입 및 모든 사용자 이벤트는 먼저 Kafka에 저장
  • 하루 한 번 배치에서 실시간으로 추천하는 것으로 변경
  • 인력 부족과 경험 부족, 모니터링 책임 논의 등의 문제로 변경하는데 1년 이상 걸림
• Fraud detection 시스템도 추가
• CS 팀과 연동해 특정 사용자가 어떤 페이지를 보았는지 확인 가능

Kafka 아키텍처

2016년 : Spark ML과 Spark Streaming 사용

• Spark가 도입되면서 ML 모델링과 Stream 데이터 처리 시작
  • Scikit-learn, R 기반 모델링에서 Spark ML 기반으로 변경
• Spark-Streaming을 사용해 추천 모델을 실시간으로 변경 (2017년 여름)
  • 운영상의 이유로 처음에는 쉽지 않았음
  • 일부 Feature는 배치로 계산해 Cassandra에 저장 : Spark SQL, UDF 사용
  • 일부 Feature는 실시간으로 계산해서 사용 : Spark-Streaming, Kafka 사용

Udemy 이벤트 처리 시스템 2기

Nginx를 기반으로 수집되던 사용자 행동 이벤트가 어떻게 발전했는지 살펴보자.

이벤트 처리 시스템 1기

• 추천 엔진 2기 개발 때부터 2021년까지 사용한 구조
• Nginx를 사용한 사용자 이벤트 수집
• 실시간 처리와 배치 처리를 위한 두 개의 시스템 존재
  
  • 배치 처리는 syslog와 Flume 사용 : Nginx - syslog - Flume - S3
  • 실시간 처리는 Kafka 사용 : Nginx - syslog - logstash - Kafka
• 문제점
  • 낮은 확장성 : 확장이 쉽지 않은 복잡한 구조, 개발자 실수로 삭제하거나 수정이 빈번
  • 낮은 데이터 품질 : 실시간 이벤트 유효성 검사 메커니즘 부재, 스키마 검증 필요
  • 문서화 부족
• 해결책
  • Kafka를 더 많이 활용
    • Kafka Schema Registry 사용으로 이벤트 데이터 유효성 검증
    • Avro를 이벤트 데이터 포맷으로 사용해 스키마 검증
    • 두 개의 이벤트 스트림 Topic 사용
    • Kafka Connect를 사용해 S3로 적재
  • 이벤트 수집기를 별도로 구현
    • 프런트엔드, 백엔드, iOS, Android
    • 이벤트 수집기를 K8s 위에서 실행 (Auto-scaling), AWS EKS 사용

Avro

• Row-based 데이터 포맷으로 Binary 포맷
• Avro vs Parquet
  • Parquet은 Column-based
  • Parquet은 Spark나 DW 등에서 데이터 분석용으로 배치 쿼리 수행 시 더 적합한 포맷
  • Avro는 데이터 송수신이나 스키마 변경 감지 등에 더 최적화된 포맷