공감세미나: 오픈소스 튜토리얼 19.12.14 토

1. 데이터 엔지니어링을 위한 오픈소스 튜토리얼

1) redash

카카오에서 실제로 어떻게 데이터 파이프라인을 구축하는지 알려주고자 함. (여개모/ 카카오 선물하기 백엔드->데이터로 포지션 옮긴 5년차 개발자 분)

redash? : 데이터 소스를 연결하면 데이터를 시각화하기 좋은 데이터 시각화 대시보드. 지원하는 데베/데이터소스 종류 가 매우 많음. -> 매우 막강한 오픈소스로 자리잡고 있음

회사 내에서 사용하기 큰 무리 없음. 파이썬으로 되어 있음. 커스터마이징 해서 쓰기도 함.

도커 기반으로 간단히 설치 가능- 클라우드 기반이나 컴포즈 기반 둘다 가능. 로컬로 설치해보고 괜찮으면 aws 연결하면 굳

 

md들이 전년도와 올해? 뭐 판매량 비교였나... 그 데이터를 시각화해서 보고싶어 했는데, 원래 그러려면 admin 만들고...? 데이터 불러오고 개발을 해야 하는데, 이 툴 덕분에 개발 과정을 거치지 않고 그들의 needs를 매우 잘 충족시킬수 있었음.

 

쿼리로 대시보드를 만들수도 있고, 태깅을 달 수도 있음. md별로 각자 대시보드가 있음. 하둡에 있는 데이터를 redash를 통해 조회하는 것이 훨 중요. 애초에 서비스 장애의 80% 가까이가 데베 장애인 경우가 많다. 모든 걸 다 데베에서 접근하려고만 하니까 부하가 생기곤 했다. 데베 사이즈보다 인덱사 사이즈가 더 커지는 상태가 발생해서 데이터를 지워야하는 경우까지 초래했다. 그럼 해결? -> 서비스는 모두 데베를 바라볼 수밖에 없으니, 배치를 바꾸자. 배치는 하둡 데이터를 바라보게 하고, 정합성을 잘 맞추게 하자. 어드민은 분산처리가 잘되는 elasticsearch를 사용하자... 등으로.

다른 도구는 superset, zepplin 등이 있음

도커 기반 설치 주소: https://redash.io/help/open-source/setup#docker

 

<Q&A>

..하둡에서 매일 데이터 스냅샷을 만드는 식으로 버저닝을 하고 있고, 옛날 데이터는 필요없으니 지우는 식으로 하고 있음

데이터 적합성을 맞춘다? - 데베 말고 다른 곳에 데이터가 있단 것인데, 어떻게 갭을 메꾸나? - 커머스다 보니 데이터가 무조건 누적되다보니 , 상태만 변경이 되는 방식이다. 주문을 하면 주문 상태 데이터가,... 그러나 만약 누가 주문을 취소한다, 그렴 지금 스냅샷 데이터로는 정합성이 안맞잖아? 이건 실시간으로 카프카로 취소 아이디를 받고, 엘라스틱서치나 하둡을 갖고 조인을 할 수 있는 데이터를..갖고와서...다시 accept를 한다나...

insert update 방식 말고 계속 누적하는 방식 사용하는 회사도 있나?...

 

2) apache NiFi

nifi.apache.org/docs.html

자바 기반의 아파치 라이센스 2.0

나이아가라 파일즈의 약어

NSA에서 개발된 데이터 플로우 엔진. 나중에 오픈소스로 내놓은 것. 소웨 간 데이터 흐름을 자동화하게 만든 설계

도커 기반 설치: 

컴포넌트 종류가 여러 가지가 있음. 

이걸 도입하고 나니 데이터 파이ㅡ라인을 신경 쓸 일이 줄었다. 대신 놓칠 수 없는 소중한 데이터면 생각을 해봐야함, 로그성 데이터라서 가능했던 것.

* 카카오라 해서 인력이 풍부하진 않음. 일 안하는 사람은 더럽게 안하고 열심히 하는 사람은 열심히 한다. 대기업일수록 심함. 몇년간 잠을 못잤는데, 혼자서 5가지 일을 했었기 때문. 

* 이번에 걷어냈다. 사람이 한명 들어와서

* fail이 났을 때 이걸 어떻게 처리할 것인지가 관건. 어디가 병목인지 파악하고 ... 어렵지만 블랙박스를 쓰는 방법도 있음

단점 1: 실수로 configuration을 지운 경우, 복구할 방법이 없음. 그래서 백업 방법도 미리 고려해둬야함

로그 같은 경우는 컨슘을 해서 하둡, 엘라스틱서치, 다른 데베 등에 넣을 수 있음. 단 유실될 수 있는 부분이 있어서 retry 같은 부분도 고려해야 함

단점 2: 모니터링. api같은게 있는 경우... 뭐가 확인이 어렵다고 함

공정/실험 데이터 등 잃어버리면 안되는 데이터의 경우엔 - spark streaming해서 캐치해서 하둡 등에 적재하는 식으로 하면 유실 없었음.

카카오는 상용 툴을 안쓰고 거의 오픈소스 커스터마이징해서 쓴다고 함.

 

 

 

2. 오픈소스 배포, 모니터링 튜토리얼

KeyClock auth server. JBUG에 있는 오픈소스고, 이걸로 채팅앱 만들 것. 이미 완성된 기능이 많아서 실무에 바로 도입해도 될 정도

카톡 채팅방 입장 = regiter / channel / ... 프로토콜 따라 명칭 다름

커넫ㄱ션: 현재 몇명인지를 받는 파트

vertx: 내부적으로 네티 서버가 돌고 있는 오픈소스 라이브러리. 네티가 원랜 어려운데 좀더 쉽게 쓸 수 있게 맵핑해둔 것. 일반 tcp서버로도 쓸 수 있게 ..

소켓 서버 1개를 큐에 연결하여 여러 개에서도 사용할 수 있게 하는 일을 할 것. 실무에선 소켓 서버1대로는 일 못하니까

큐라는것은 한번 보냈을 때, 원랜 보장할 수 없는 것을 보장할 수 있게 하는 것이 큐 시스템이라고 생각한다. 보냈다는 것을 여러 형태로 보장해준다.

exactlu once: 큐를 정의하는 용어. 적어도 한번은 보장을 해준다. 비동기 이벤트 아키텍처, 아카(오픈소스) 안의 메일 박스가 모두 메시지 큐.

vertx, spring 등의 서드파티들 모두 래빗메시지큐 클라이언트 지원한다. 대신 vertx서 제공하는 래빗 클라이언트 쓰면 코드가 덜 우아해보일 순 있다.

큐는 보내거나 받거나 한 동작만 하면 되기 때문에 오히려 더 ㄹ어렵.

토픽/큐라는 두가지 형태를 지원한다. 토픽은 일대 다, 큐는 일대일. 여려멍 들어가있는 채팅방은 토픽을 구현하는 것. 메시지를 토픽에 발행하면 실시간으로 메시자가 간다. 큐는 이벤트 드리븐 시스템

이를테면 주문 메시지, 결제 메시지. 큐와 토픽에 그런 차이가 있음

 

채널을 하나 만든 담에, 이안에서 내가 원하는 ... 이 안에서 소켓 통신... 큐 시스템이 소켓으로 붙는다. 소켓 시스템을 정의하는 것이 채널. 소켓으로 터널링이 되고, 이 안에서 토픽이든 큐든 쓰게된다.

<코드 설명>

채널을 큐에 연결, 토픽에 큐를 바인드(토픽을 쓰려면 큐를 쓸 수 밖에 없는게 래빗 시스템)

분산 서버를 만드는 것이 목적이므로 각 서버들은 큐를 하나씩 바라보고, 토픽에 하나씩 꽃혀 있.

그게 chat-queue1 declare파트, 그담이 bind 파트(바로 다음 줄)

컨슈머 -> 채널에 대한 소비자를 하나 만드는 것 . 등록을 하면 된다 -> 큐의 메시지를 컨트롤하는 것이므로 등록을 한다.

add 쓰는 파트.

메시지가 초기화되는 이유... : 데이터가 메모리에 저장되어 있었는데 서버 내렸다 닫아서 이렇게 된 것. 나중에 redis 써서 store 해볼 것임

큐의 ㅇ니크 아이디가 매번 바뀌게 하거나, 아이디를 해시?로 만들어서 큐를 만들던지...

요즘 분산 시스템은 주로 컨테이너로 운영하기 때문에 어디로 뻗어나갈지 모름. 그래서 해시화를 해야하는...

또 뒤에서 이를 관리하는 백 시스템도 필요하게 되는 것

 

데복스/인프라가 아니면 파이프라인을 직접 구축할 일은 없.

mesosphere dc os, 마라톤, 쿠버네티스 -> 스케줄링 들어가있는 오픈소스 솔루션들

컨테이너 장점이자 단점이 기존 상태를 유지하려고 하는 것. 단점이 되어 로컬에 볼륨 마운트를 해두지 않는 경우에는 에러가 난다 그러면 컨테이너 내부 내용이 전부 삭제됨

 

redis는 ~ 프로토콜로 쓰란 규약만 있지 ~를 지원해주지 않는다... jedis와 ~라는 프로토콜 2가지가 있다.

레디스도 마찬가지로 레디스 서버랑 소켓으로 붙어야 한다.

레디스는 초당 10만tps까지 나와줄 수 있는 성능... 보통 2~30개 열어두고 씀

레디스는 스트링만 저장할 수 있음 그래서 모든걸 스트링으로 바꿔야함

 

scouter: apm soltion. 어플에 대한 특화된. 이에 대해 상세한 모니터링을 가능하게 함