Data Engineering/데이터엔지니어링 케이스 스터디

[Data Engineering] Case Study 2. Flink 기반 log streaming pipeline - Log 와 사용자를 잇는 무지개 다리 / 카카오 클라우드 플랫폼팀

쟈누이 2021. 1. 31. 16:51
반응형

카카오 파이프로스트 프로젝트

추후 해당 링크를 통해 다시 스터디 할 것

if.kakao.com/session/116

 

if(kakao)2020

오늘도 카카오는 일상을 바꾸는 중

if.kakao.com

 

 

1.     Streaming? Pipeline?


1)     로그 파이프라인

  • 로그 파이프라인이란 데이터 처리 단계의 출력이 다음 단계의 입력으로 이어지는 구조
  • 로깅 이벤트 시퀀스를 처리하는 플로우
  • Source 와 destination 이 있는 데이터 흐름
  • 로그 데이터 전송과 변환을 자동화(최근에 추가된 정의)

 

2)     스트리밍

  • 데이터의 연속적인 흐름
  • 데이터 흐름 안에서 의 연속적인 연산과 처리
  • Real time
  • Like video streaming
  • 로그 파이프라인에 비해 실시간성이 매우 강조되는 것

3)     Batch vs Stream

출처 : https://if.kakao.com/session/116

배치와 스트리밍의 차이를 잘 설명한 예시같다. 배치는 일정개수 만큼 싣어서 목적지에 전달, 스트리밍은 계속돌아가는 체인 위에 원하는 데이터를 언제든지 싣어서 보내는 것이다.

 

카카오의 로그파이프 라인은 KEMI 라는 전사 플랫폼을 개발하여 사용중에 있음

케미란 KAKAO EVENT METERING & MONITERING 의 약자로서 모든 리소스에서 발생하는 자료들을 수집 적재하고 이를 필요한 이벤트로 만들어 적재 적소에 전달하는 플랫폼

 

케미 설명 링크 : https://tech.kakao.com/2016/08/25/kemi/

 

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

KEMI(Kakao Event Metering & monItoring)는 카카오의 전사 리소스 모니터링 시스템 입니다.서버, 컨테이너와 같은 리소스의 메트릭 데이터를 수집해서 보여주고 설정한 임계치에 따라 알림을 보내주는 KEMI

tech.kakao.com

 

케미 아키텍쳐 단면도

 

출처 : https://if.kakao.com/session/116

람다 아키텍처를 따르고 있음. 로그들이 log aggregator 인 FLUENTD 를 통해서 모이게된다.

log aggregator에서 취합한 데이터들은 하둡과 카프카에 동시 전송중.

 

하둡에 저장된 데이터들은 배치작업들 통해 일정 주기로 엘리스틱 서치에 전송, 개발자들은 주기를 기다렸다가 엘라스틱 서치나 하이브에서 로그를 쿼리해서 사용할 수 있음. 카프카에 프로듀싱된 로그들은 log tailer 라는 CLI 툴을 통해 실시간을 확인 가능, 또한 카카오에서 개발한 DIKE 를 통해 실시간을 생성되는 로그에서 쿼리를하여 로그기반 알람 할수 있음

 

출처 : https://if.kakao.com/session/116

위쪽 하둡을 베이스로 한 부분에서는 배치작업을 통해 작업이 수행되고 아래 카프카를 베이스로 한 부분에서는 스트리밍 작업을 통해 작업이 수행되고 있다.

 

 

2.     Needs


실시간이 매우 중요해짐, 로그 스트리밍 기능이 중요해짐..

출처 : https://if.kakao.com/session/116

 

다양한 니즈가 존재…내 입장에서 공부하면서 어떤 것으로 묶어볼 수 있을까 고민을 해도 잘 안되었었음..

출처 : https://if.kakao.com/session/116

하지만 개설된 파이프라인으로 보았을 때, 실시간 스트리밍 데이터를 처리하고 파악하고자하는 니즈가 많았기 때문에, 배치작업에서 쓰이던 엘라스틱 서치를 스트리밍 파트로 이전을 하여 스트리밍 데이터를 쉽고 정확하게 측정이 가능하도록 한 것 같다..

 

이러한 파이프라인이 제대로 작동하기 위해서는 지속적인 데이터 프로세싱이 가능한 파이프라인을 개발해야만 했는데, 

즉, 위의 이미지에서 카프카에서 엘라스틱 서치로 이어지는 ‘ToDo’ 부분에 스트리밍 프로세싱이 가능한 파이프라인의 추가적인 개발이 필요했음.

 

 

3.     Apache flink


출처 : https://if.kakao.com/session/116

카카오 클라우드 팀은 이를 위해 오픈소스인 아파치 Flink 를 선택하였음.

 

Flink 는 스트림 프로세싱 프레임워크로 무한하고 경계가 없는 스트림 서비스를 처리하는데 최적화된 컴퓨팅 엔진이다. 다른 프레임 워크들이 ‘at least’ 라는 전략으로 데이터가 여러 번 중복 전송될 수 있다는 전재를 깔고 들어가는 반면, Flink 는 exactly once 전략으로 체크포인트를 지정해 여러 번 중복 전송되지 않고 도중에 끊기면 지정된 체크포인트에서 다시 데이터가 전송되어 중복전송을 하지 않는 프레임 워크로 생각하면 이해하기 쉬울 것 같다

 

 

4.     What is bifrost


위 To do 프로세스를 연결하기 위해 개발한 것이 바로 바이프로스트인데, 이 바이프로스트는 앞서 설명한, Flink 를 기반으로 개발했다고 한다. 스트리밍 방식으로 데이터를 처리하면서 카카오 내부의 많은 로그 데이터들을 처리해야 되었기 때문에, exactly once 전략으로 중복 전송이 적어 신뢰성이 높았기 때문으로 생각한다. 

출처 : https://if.kakao.com/session/116

 

바이프로스트가 포함된 최종적인 아키텍처

출처 : https://if.kakao.com/session/116

 

바이프로스트를 통해 실시간으로 스트리밍 로그를 카프카에서 엘라스틱 서치로 전달할 수 있게 되었고 사용자들의 니즈를 충족시켜주는 파이프라인 개발이 가능했다고 한다.

출처 : https://if.kakao.com/session/116

바이프로스트는 쿠버네티스에서 운용되고 있으며, 장애가 발생했을 시 쿠버네티스가 이를 탐지하고 복구하여 서비스의 신뢰도가 대폭 향상되는 장점을 가져왔다. 

출처 : https://if.kakao.com/session/116

이처럼 카카오 클라우드 팀은 바이프로스트를 통해 쿠버네티스를 이용하여 잡과 테스크들을 관리하고 데이터가 원활하게 스트리밍 될 수 있는 환경을 만들어주고 있었다

 

 

5.     경험기


1) 상황에 따른 Rebalance 와 Rescale 의 선택의 중요성

출처 : https://if.kakao.com/session/116

바이프로스트의 주요 업무는 신뢰성있는 데이터의 전달 이었기 때문에 개발 초기에 수십대의 노드에 테스크를 골고루 분배하는 것이 효율적인 방법이라 생각했지만, 노드간 통신 때문에 네트워크 비용이 발생할 수 있다는 것을 고려하지 않았기에 이 방법은 그렇게 효율적인 방법이 아니었다. 

 

노드간 연산이 많을 경우에는 리밸런싱이 효율적인 방법이 될 수 있으나 만약에, 노드간 연산이 적을 경우에는  노드간 통신으로 인한 네트워크 비용이 발생을 최대한 줄이기 위해서 노드 내에서 여러 테스크로 나누어 분배하는 것이 더 효율적일 수 있다. 

 

 

2) 유사한 프로세스는 한 바구니에 잘 담아 업무의 효율성을 높이자

 

출처 : https://if.kakao.com/session/116

연관된 테스크들을 잘 묶으면 효율성을 높일 수 있다. 연관된 테스크, 연속적으로 데이터를 처리하는 테스크들끼리 묶으면 더욱 효율적으로 데이터를 처리할 수 있다.

 

 

3) 모니터링이 중요하다 ( 백프레셔를 잘 확인하자)

 

백 프레셔를 잘확인하자. 백프레셔란 파이프가 좁아지는 코스에서 데이터들이 좁은 코스에 몰려 압력이 상승하여 데이터 처리에 딜레이가 생기는 현상을 말한다. 흔히, 좁은 공간에 물질이 몰리면 엄청난 압력과 딜레이가 발생한다는 현실세계의 물리적 개념이 적용된 것이  백프레셔라고 생각하면 된다.

 

백 프레셔는 오퍼레이터와 오퍼레이터간의 원활한 스트리밍 처리를 확인하는데 가장 중요한 개념 중 하나로 통하고 있으며, 예를 들면 만약 앞의 오퍼레이터가 10개의 데이터를 넘겼는데 뒤의 오퍼레이터가 5개의 데이터밖에 처리못하면, 5개의 데이터가 누적이 되는 것이다. 이것이 백프레셔가 올라가는 원리이다.

 

 

반응형