2015-09-15

# Deview 2015

2015.09.14~ 2015.09.15

이틀동안 Deview에 참석하였다. 스프링캠프2015 이후 국내 컨퍼런스 참관은 오랜만이여서 정말정말 재밌게 들었다. 항상 컨퍼런스 참가할 때 마다 느끼는 것. 세상은 넓고 초고수는 많다.

많은 것들을 배웠던 이틀을 나름의 스케치를 남기며 일단 마무리를 할까 한다.(메모에 가깝다. 오타가 많다) 워낙 한정된 시간(50분)에 발표다 보니 대부분 속도도 빠르고 잘 모르는 부분은 잘못된 정보도 있을 수 있다. (혹 틀린 내용이 있거나 좋은 의견이 있으실 경우 댓글로 남겨주시면 감사하겠습니다!)

물론 후에 오픈될 발표 영상이 더 도움이 많이 되겠지만, 많은 발표중 어떤 것들을 들어야 할까. 혹은 다른 사람은 어떤 점을 주목했는가. 에 대해 조금이나마 도움이 되고자 포스팅을 해본다.

Deview 공식 페이지 : http://deview.kr/2015 (opens new window) 발표 slide : http://deview.kr/2015/schedule (opens new window)

# 'Day 1'

# [1] 네이버 효과툰은 어떻게 만들어졌나?

slide : http://www.slideshare.net/deview/111-52720751

스크롤에 디펜던시를 / 타임라인 >> 스크롤에 맞춰서

# 저작툴

Angularjs + node webkit
빠른 개발 가능, 향후 web으로 갈 수 있음.

# 서비스

모션 구현. — 앱 : cocos2dx — Web Viewer 호환성 확보 — PC wheel >> smooth croll — 이미지 용량 문제 >> auto crop

# TODO

누구나 쉽게 쓸 저작툴
다국어 번역 >> 이미지에서 text 뽑기.
flash와 경쟁할 모션 플랫폼.

# parallax

고고고, 악의는 없다, 소름

# 하이브리드 개발자의 장점

개발자가 기획을 많이 들어가는 프로젝트
직접 작가의 요구사항 파악
효과툰은 애니메이션이 아니다.
scroll mapping, instantly 등등

# 동작 원리

json 으로 packaging(위치와 event mapping)
-- AssetManager -- PageMangeer
scrolll position에 따라.
DOM mode / Canvas mode
최적화 / 안정성 / 호환성
이미지 적절히 자르기 -- 그냥 2048px 이 아니라 공백찾아서 알아서 거기서 자르게

# render line

가변 최적화 선.
모바일 화면 크기마다 최적화선이 다르다
ex) mobile 75% 쯤 , PC 85% 쯤

# 스크롤 이벤트 구현

PC는 native scroll
사파리 7, 웹뷰 scrpit scroll 나머지 아이폰은 native scroll
안드로이드 같은 경우는 sciprt, natibe, stillcut, canvas 다양하게 사용하고 잇음.

# 서비스 런칭까지

9월 고민 시작 >> 11월 1.0 비슷 릴리즈 >> 서비스준비 4개월
개발자 3.5명

# [2] 네이버 효과툰 구현 이야기

slide : http://www.slideshare.net/deview/121-52734801

# 저작툴

$watch > dirty checking 해결 $emit(‘{event’}) >> Controller.$on() $Broadcast
ng-route 메모리 부족
자식 창이 끄고 키고>> 3기가까지 올라갓다.

html 파일로 직접 접근
ui-route 를 더 추천

ng-repeat

directive in directive $scope가 계속 물고가서 안그러면 나중에 노드/리스너 등이 계속 늘어남
명시적으로 $destroy 해주어야 함

SVG 렌더링 이슈
ng-show를 같이 사용

# 외부 모듈 사용하여 개발할때의 이슈

$scope 변수가 반영되는 조건

dom 이벤트 —> $safeApply in Directive > scope. $root.$ safeApply

undo/redo opensource memento 네이버 : memento-promise
psd.js

문제 한글이름이 깨짐
이름이 너무 길면 파싱이 깨짐

python psd-tools — 한글 레이어 이름 해결 — 긴 height psd 메모리 문제 없음. — psd 자동 나누기도 가능

# unit test

Strider cd 사용

# test

Protractor

문제 발생 >> 노드js 파싱 못함. 화면을 보면서 테스트 코드를 넣고 싶다 >> 자스민jasmine 활용

# 뷰어 이슈

스크롤
사운드
ie 구버전

스크롤

스크롤 이벤트 특성의 문제.

스크립트 스크롤 사용 다 움직이니 메모리를 먹어서 최신기기도 버버벅 거대한가 아니라 해당 구간의 작은 를 움직이자. display:none 하면 reflow 비용이 있지만 display:block으로 레이어 생성 비용이 더 큼으로

적당한 크기로 나눌 필요가 있다 가로 * 세로 = 1024 * 1024 * 3

lazy loading src 지정하는 순간 >> Paint (ImageDecode) 발생 버벅거림이 느껴짐 scrollEnd 이벤트

스크롤이 잠시 멈췃을때 다음 구간 이미지 불러오기 pre-lolad + 미리 IamgeDecode해두기
체감 성능을 올릴수 잇음.

GPU 가속을 받는 소성을 사용.
컨텐츠 영역일때만 활성화. 스크립트 스크롤을 비활성화.

사운드

HTML5 Audio 동시에 여러 리소스 재생 불가능
WebAudio Api 사용 : 동시에 여러 사운드 리소스 재상 가능 는 문제는 갤럭시 시리즈.. 리소스가 여러개 겹치면 브라우저 크래시

iOS 명시적인 사용자 액션에 의해서만 사운드 재생 가능. (한번만 하면 나중에는 프로그래밍 적으로 가능 >> 첨 시작할떄 아무 소리 없는 오디오를 틀어서 나중에 쓸수 잇게 꼼수)

자동 재생의 문제 > 갤럭시는 안댐 -_-;
다른 음악 앱 재생이 멈추는 경우.

딱 node를 받는 event 순간을 알 수 있음. 맞춰 재생 가능

@webkit-animate르 해결 > 미리 set ccss파일로 선언 >> ie8~ie9의 경우 자바스크립트 정규식으로 분석하여 스크립트로 해결

# [3] Packetbeat 과 Elasticsearch 를 이용한 실시간 모니터링

slide : http://www.slideshare.net/deview/131-packetbeat-elasticsearch

layer 에서 모든 프로토콜을 받아서 실제 pysical protocol 몸을 받아서 request와 reponse를 해서

no- pipiline의 경우 꼬리에 꼬리를 물고 잇어서 쉽지만 pipelining이 되어있으면 request랑 response 페어를 맞춰줘야함.

따라서 모든 request-response pair json obj를 만들어주고 그 안에 관련 info들을 넣음. ( ex. response code, get method 등등)

SQL / DNS >> json 으로 info packaging

packetbeat로 만든 data > elastic search cluster > cabin / dashboard (기존 logstash와 비슷?)
packet beat : listens to the beat of the network packets
Top beat : operating system metrics
File Beat : logs
metrics beat : internal beats of systems via apis
TOP BEAT
sample : output obj : Device name. mount point 등등
File beat
based > Logstash-forwarder spice code
sample : log level, 등등
libbeat > common
go library
ligging, handling 등등. enable to fork?
deployment
send to log stash
Date histogram
Percentiles aggregation >> can get average >> approximate values, T-digest
date_time + percentiles response >> can be combinable
Latency histogram
response time repartition 리스폰스 얼마나 걸렷는지 애버리지 알랴주는건가?
kibana config 제공
Pipieline aggregations
new in elasticsearch 2.0

derivative aggregation

constantly gworing /
caculating moving average.

오래된 데이터는 important를 낮춰서 계산. 최신이 더 중요한 data 수집된 데이터와, 무빙 에버리지, threshold, mean

파도 모양 트랜드의 경우

문제는 average/예측이 늦음. 실제 일어나는것 보다.

cyclic trenad 그래서 >> Holt-Winters(triple exponential) model works better for seasonal data 데모 http://demo.elastic.co/packetbeat

# Q&A

why go?

cpu/memory 를 많이 쓰고 싶지 않았다.
자바는 너무 무거워
파이썬/루비는 너무 느려
씨 >> 너무 어려웡. 오래걸릴것 같아.
고 >> 굿 랭기지
여러 플랫폼에 쓰여야함. >> 따로 deployment를 해야하지만. supportable
logstash를 사용 하는게 편하지만 만약 json parser를 뭐 만들면 뭐 쓸 수 잇긴 허지

aggregation

모든 aggregation을 직접 custom해서 쓸 수 있다.
예로 보여준것은 standard 뿐이고 직접 맞춰 할수 잇다.

Flume 이용중 flume vs .filebeat

elastic search 를 붙히기 쉽다.
simple
flume의 검색?(이게 뭔지 안들렷..ㅠ) 은 엘라스틱보다 느리다.

다운타임동안 어케 처리할꺼임.

ping을 계속 날림. > 만약 missing data가 잇는지 확인
도커 지원 함

performance, benchmark?

pretty row resouces
지금은 샘플을 auto로 가지고 잇으면서 하지만 앞으로는 좀더 주요한 데이터를 가지고 있고 아닌건 drop data 를 할 수 있도록

# [4] React Everywhere

slide : http://www.slideshare.net/deview/141-react-everywhere

믿고 듣는 초고수

# React

npm으로 설치
babel로 하위 커버

>> babel-core/browser 로 translate — jsx가 아니네 >> 0.14 부터 폐기 --> 나도 바꿔야 겟다.

관심사의 분리
예전에 뷰와 로직을 분리했던 것을 관심사에 따라 분리시켰다
Angular 의 directive보다 훨씬 쉬움.
state와 props
비교 조정 >> 아직 효율적인 알고리즘 발견 ㄴㄴ
휴리스틱을 이용해 현실적인 효율을 찾아낸다 >> 일반적 사용할때 문제를 없앰
virtual dom
virtual dom에서 동일 레벨끼리 비교하여 필요한 부분만
같은 컴포넌트는 그대로 사용(효율성) 아닌경우에는 다시 그린다
key 가 없는 컴포넌트는 철번쨰 요소부터 재사용
list에서는 key를 사용하는게 더 효율적 >>> 가끔 Key 안해주면 계속 warn 해댐... 어케 버츄어 돔이 구현되엇는지 slide 링크 확인
Life Cycle
componentwillmount —>—>— willunmount (공식페이지에 있는 내용이니 참고하자)

# 웹팩/핫모듈대체/유니버셜 랜더링

Webpack
nescape 3,0 대 이후로 ? require module 가 음스짐..
requirejs로 하는 안되나???
비슷한 다른거 browserify
의존석에 맞게 static asset으로 변환 -- commonjs 와 AMD 모두 지원

핫 모듈 대체를 이용
watch를 하거나, 리빌드를 하거나 뭐 이런거.를 기존에 해왓지
핫 모듈 대체를 이용하면 실시간으로 기능을 갱신 가능 >> 오오오 스고이 써봐야겟다!!

$ npm install webpack
$ babel-core 바벨 번역기 (dev에 사용하기 위해서)
$ babel-loader 바벨 로더 ( 웹팩에서 바벨을 수행하기 위해서)
$ react

webpack.config.js

 module.exports = {
     emtry : {진입하는 파일 ex) .hello.jsx} ,
     output : {
          path : {_dirname+ /build}
          filenaem : {hello.js}
     },
     module : {
          loaders : [
                .jsx?로 끝나는 파일을  node_module 파일들을 압ㅇㅇ압축
          ]
     }
};

별도의 jsx 파일에서는 CommonJS 방식으로 react 참조해야함.

실행

$ webpack
$ webpack -w (watch)

ES6 style

import React form ‘react’;                                         // ES6 import
class HelloClass extends React.Component {                // 상속
     render( ){
          return <h1>hello</h1>
     }
}

장점 : 훨씬 깔끔해보임 익숙한 class모델
단점 : 이벤트 전파 부분이나 기존과 다름.
확인을 좀 더 한뒤 넘어가는게 더 좋을듯.

# Hot module replacement 핫 모듈 대체

동적으로 코드 모듈 교체 기법

업데이트 메니페스트 json
하나이상 청크 가 업뎃되면
파일 하나? 가 청크 "웹 소켓"이 열려서 작업햇던 청크를 핫모듈에게 알려주고 그때마다 적절한 용량으로 상채 보관등을 하며 업데이트가 된다. ㅣ플레이스 없이 알아서 바꿔줌.
리액트/플럭스/리덕스 프레임워크에 거의 잇음..
모듈 단위로 라이브 리로드가능.
그때그떄 매니페스트 만들어야함 >> 고로 직접 만들기 힘듬 -_- 이미 있는걸 사용하자 ..
ex ) React HMR
loaders : “react-hot” << Dan 로더깍는 노인

# Universal Rendering

과거 Front와 Backend가 구분이 나누어져 잇엇음.. ex) Angular 1.x / Express.js
Isomorphic/Universial rendering 백앤드와의 장벽이 무너짐 ex ) React, Angular 2.x

 virtual DOM > renderToString  > HTML String
                    > render                > DOM

demo : 일렉트론
리액트 네이티브는 하이브리드가 아님

# [5] 웹 브라우저 감옥에서 살아남기

slide : http://www.slideshare.net/deview/152-52736153

회사 Entry
HTML5
내부 interpreting >> 60fps
루프기반의 인터프터여서 클라이언트 연산량이 높아 부하가 높음 (특수사항)
jQuery/angular를 쓰면 안되는 case
selector : sizzle 라이브러리가 돔을 찾아냄.. > sql로 select문으로 찾는거랑 비슷.. 클라이언트가 계산. 난 양심이 없음 막씀.
초당 39만~ 84만 엘레멘트를 찾아야함.
Dom이 복잡하고 업데이트가 잦은 상황에서 jQuery Selector를 거의 사용할수 음슴...

그래서 2웨이 바인딩으로 Dom과 Data연동 $digest 루프가 돌면서 $watch list 모델 변경을 dirty-check ( 변화있는 얘를 찾아서 뭐가 변햇는지 보고 data를 변화시킴) >> 어짜피 비대한 모델에 잦은 변화 >> 초당 3천에서 24만 체크

극도로 느려짐 coz of dirty-check

# 대안

직접 ViewClass가 DomElement에 property를 줘서 구현.
Modal Obj 구현(getter/setter) > observer를 구현 >>> 빨라짐

# Observer 패턴

getter/setter에 이벤트가 들어오면 observer에게 notify를 날려 바뀜.
연산이 따로 들어가지 않기때문에 빠름
Dom 을 많이 고치지 않는게 빠르게 할 수 잇다
Model Obj 도 Store에 해놓고 listener 등록해서 하면 될듯?

# 게임 디자인 패턴을 이용한 웹개발

Entity Component System

각각의 엔티티(객체)는 컴포넌트(기능)을 갖는다.

엔티티의 기능을 추가하고 싶으면 component를 개발

기능 추가가 용이
Component 디펜던시 분리 성공 기능이 명확하게 분리

# 단점

초기 개발 공수
최적화된 형태구현은 아니다. ex) 유저 entity의 경우 초기 init만 해주면 되는데 위에서와 같이 초당 몇번씩 같이 update됨

# 웹소켓으로 구현한 웹과 하드웨어

오프라인 실제 프로그래밍을 위해
HW CONNECT SERVER 웹소켓으로
아두이노 websocket 내장시켜 궈궈 ,

# What’s next

code analysis
real-time letter
10월중 open source > 재밋겟당
Canvas / SVG

# [6] JPA와 모던 자바 데이터 저장 기술

slide : http://www.slideshare.net/deview/162-jpa

객체/관계형 데이터베이스 다름
객체 > sql에 맞게 바꾸고 넣고 등등등 하는 일들이 계속 됨.

# 성능 최적화

1차 캐시와 동일성 보장 SQL에서 가져온거 를 다시 가져오면 1차 캐시(같은 트랜젝션 안에서 보장) 에
트랜젝션을 지원하는 쓰기 지연

트랜젝션 커밋때까지 insert sql모음
jdbc batch sql 기능을 사용해서 한번에 sql 전송 >> 알아서 최적화 해줌

# 지연 로딩 / 즉시 로딩

지연 로딩 : 객체가 실제 사용 될 때 로딩

Member member = memberDao.find(memberId);
Team team = member.getTeam; > select * from member

즉시로딩 : 한방에 로딩!

Member member = memberDao.find(memberId);
Team team = member.getTeam; > select * from member join other table

# JPA 기반 프로젝트

Spring data API
queryDSL

spring data api

인터페이스만 작성.
스프링 데이터 jpa가 구현 객체를 동적(런타임에) 으로 생성 주입. 짱짱!
paging /Sorting 도 해줌
메소드 이름으로 추론하여 찾아줌. — parameter로 Sort sort 넘기면 알아서 — parameter로 Pageable pageable 알아서 페이지 >> 두번이 날라감. find all 해오고, page 전체를 select해옴
@Query(), jpql 도 가능 .
Web domain class convertor도 바로 가능하다. 오오 스고이

queryDSL

동적 쿼리
sql, JPQL을 코드로 작성할 수 있도록 도와주는 빌더 API
오픈소스
JPQL의 문제점 type-check 불가능

# 장점

문자가 아닌 코드로 작성 > 컴파일 시점에 문법 오류 발경
코드 자동완성
제약조건은 따로 빼서 재사용 조립 가능
데이터 베이스 변경에도 매우 유연함.

# 성능 이슈

실무에서는 즉시보다는 지연로딩이 더 나음( 한번에 하면 쿼리가 튈 확률이 높음)
N+1문제 > 대부분 페치 조인으로 해결
내부 파서 문제가 잇을 경우 > 정적 쿼리로 해결 (한번 가져온거 재사용)

# [7] JPA BOF

집에 가려고 하다가 칠판에서 보고 급 참석
왠지 커머스 관련 개발자들이 많이 계셨음.
평소 개발 커뮤니티에서 뵙던 연예인들이 계셨음. 신기신기
다른 개발자들의 삽질기를 들어 보니 내가 했던 삽질과 똑같고.. 고민도 똑같아서.. 왠지 세상은 넓고 삽질은 똑같다...라는 생각이 들었음.
아직 ORM이 많이 안쓰이고 있음을 한번 더 느낌.

# 'Day 2'

# [8] Large scale backend service development using Node.js, Docker and AWS

slide : http://www.slideshare.net/deview/212-large-scale-backend-service-develpment

늦어서...뒤에서 서서 듣느라 필기 못함.
성능 최적화를 통해 비용절감을 드라마틱하게 할 수 있음을 보여주심.
게임 서버 구축 혹은 AWS를 쓰는 사람에게 정말 도움될만한 좋은 사례 발표.

# [9] Docker Orchestration

slide : http://www.slideshare.net/deview/221-docker-orchestration

# Docker

하나의 배포 서버를 다 한번에 하면 comflict 문제가 날수 잇다.

# 배포 서비스의 고민

커스터 마이즈를 하고 싶다.
pakage > deploy > service
서비스 상태를 관리해 주고 싶다 (history를 가지고 잇다가 rollback,deploy

“상태"를 이미지로 배로 deploy == rollback

# 도커 주목

가상머신보다 가벼운 컨테이너 >> 효율적 리소스 공유
이미지단위 빌드, 배포, 롤백이 용이
write once, run anywhere

도커 설명은 생략

Orchestration 오케스트레이션 여러개의 컨테이너로 하나의 서비스로

# Why?

composition 여러종류의 컨테이너로 구성된 서비스 설정 및 연동
replication 스케일러빌리티, high availability
write once, run anywhere 같은 이미지가 local/cluster에서 모두 동작하도록

# 요소

스케쥴링 ( 서비스 컨텍스트에 따라서 나눠주는거 ex) 병렬해야하는거 하나가 아니라 각각 컨테이너에게 할당 )
컨테이너 사이/ 외부 네트워킹
discovery - 컨테이너 찾는 방법 ex) membership , DNS ..
로깅 모니터링 얼럿 등

Docker ecosystem 에 여러가지들이 일군 ..

첫 논의 docker swarm, kubernetes
콜록콜록 9년동안 빌드 배포하면서 몸이 많이 망가짐..ㅠㅠ

# docker swarm

하나의 도커에는 좋지만 여러개의 오케스트라에는 적절치 못한것 같다
but develop 속도가 빨라 나중에 다시 고려해볼만 하다

# kubernetes

google style의 클라우드 서비스 관리
클러스터를 가장 빠르게 구축, 안정성 좋음

가장 적합

# step 1. build pool

기존 jenkins > dockerize
기존 빌드 시스템에서 kube 서버에 도커 create 요청하게되면 docker registry 에 image를 가지고 생성
효과

fast build ( vm 보다 더 효율적이다 > 빌드 자원의 공유로 고성능 빌드 가능 )
pre built
no management

# 배운점

컨테이너는 stateless
이미지는 docker registry에 이미지를 계속 올린다. >> 백업이 제대로 되고 잇는지 확인 어려움. (직접 받아서 실행해 봐야함 )

Environment Variable 변경이 어려움 (ex. JAVA_HOME 을 나중에 바꾸기 힘듬 , 백개 다 받아서 다시 고쳐서 뭐 등등등)

컨테이너 데이터의 저장 방법이 필요 — 컨테이너 종료 후에도 info 들이 필요. (history)
multi-cluster 관리가 필요하다. — 하나 띄우고 나서 생각하자. 라고 하면 늦엉 ㅋ.ㅋ 이른 시점부터 를 고려야함. — ex) Multi-IDC, Network ACL — local, alpha용 .

# step 2. ShipDock : shipping docker

테스트 풀 확보.(기술 기반과 "돌아가는 버전”)
continuous deployment ( 푸시 앤 빌드/디플로이 )
PAAS 준비 (platform as a service) >> write once run anywhere

# overview

개발자가 > dogsight(UI) > 빌다가 만들면 도커레지스트리에 올리고 doh에서 도커가 mamange 하다가 kube api에 침. 실제 서버 디스커버리는 nginx로

# DOH : 도커오케스트레이션헤드쿼터

멀티 클러스터 관리( + 스케쥴링)

# 도로시 : 도커 베이스 빌더

인스턴스하게 도커 컨테이너 생성하여 이미지 빌드/푸시
젠킨스보다 stateless/가볍게 빌드

# Docksight

GUI 지원.
여러 클러스터를 지원하는 적절한 UI/CLI 음슴

# step3. Service Cluster

Consul

Networking

# [10] Them simplicity of cluster apps with the Circuit: Implementing a job scheduler

slide : http://www.slideshare.net/deview/231-the-simplicity-of-cluster-apps-with-circuit

command-line

$ circuit mkproc
$ circuit stdout
$ circuit wait
$ circuit stderr

# System Overview

System architecture

$ circuit start

설킷끼리 서로 server를 찾아서 >> failure가 잇는지 찾고

각각이 api endpoint를 갖고

만약 호스트 A에 설킷 클라이언트가 잇으면 host B(서킷 클라이언트가 죽어잇는) 에 찔러도 Host A에서 api 를 가지고 return

never fail, bcoz of colocation

# go API overview

Error handling
네트워크 다운이나 host가 죽엇다던가

# Anchor

클러스터 노드. single node
children을 가지고 있음 . hierarchy
root Anchor
지금 available 한 앵커에서 값 return
Proc 으로 Anchor의 state나 이런걸 떨거 줄 수 잇다?
듣다가 범상치 않아 발표자 소개 읽어보니 지니어스.

# implementing a job scheduler

design
user spec : per host 얼마나 할수 잇는지
http api server :어떤 집들이 돌고잇는지 보여줄것

# architect

host A에는 스케쥴러 >>>> http api 제공 B,C에는 잡 1,2 그리고 3을 돌린다. 각 ABC에는 서킷 클라이언트가 잇음

# State and logic

유저가 job을 더한다던가 status를 보겟다는 요청이 들어오면 일단 pend 에 쌓이고 써킷이 job을 뺀다던가 호스트를 넣거나 빼거나 스케쥴러는 컨트롤러랑 connect되서 job execute

golang을 좀 공부해야겟다

컨트롤러레 실제 잡들을 넣고

Controller state는 서킷에 의해 컨트롤 되며 job 쌓인 것들 pending 같은거 이런것도 다 관리 해주나방

scheduler에 잡이 들어오면 클라이언트 serverId를 가지고 어디에 커넥트 해야하는지를 보고 (HOST) 스케쥴 서비스 네임을 넘겨서 (SERVICE)

스케쥴러는 그걸 받고 일단 controller를 안락하고 jobs를 업뎃/add하고 다시 schedule()시킴.

만약 user로 부너 status 요청이 들어오면 controller lock을 하고 ......값 리턴? (놓쳣넹)

Run a job jobAnchor에 work({host}, “job”, {job.name})

github에 올라와 잇으니 한번 돌려봐야 알것다..

Universal cluster binaries — 확장해서 master 아래에 scheduler 가 있고 그 아래에 job을 실행 할 수 있음

master
ㄴ sched1
ㄴㄴ job1
ㄴㄴ job2
ㄴ sched2
ㄴㄴ job3

docker image를 이용해서 하나의 master/sched/job 을 다시 circuit sever로 쌓아서 여러 host끼리 묶을 수도 잇음.

클라우드 시스템에서 어플리케이션 사이 share에 편하도록?
Ship with Circuit included vs Hadoop required
inplinciple
새로 인프라를 띄우는게 부담스러움.
다른 랭기지랑도 합쳐서 쓸 수 있다.
센터 서버가 따로 음슴. >> 발표자는 이게 weak point라 생각 >> 센터가 죽으면 다 죽엉
이건 peer to peer 컨셉으로 master가 같이 잇기때문에 어떤 host가 살앗는지 죽엇는지 서로 알수 잇음.
아니면 그냥 세임 로직을 넣어도 댐
master는 유머와 connect 역할만하고 마스터 죽어도 스케쥴러는 알아서 돌고 잇음. 그냥 마스터만 다시 살리면 됨.

스케쥴러가 이미 돌고 잇으면 그냥 유저에게 알려줄뿐

살아잇는걸 찾기위해 뭐 주키퍼라던가 이런걸 사용하지 않아도 댐

# [11] Pesto 내부 구조 파헤치기

slide : http://www.slideshare.net/deview/245-presto

데이터 분석 DB
페이스북, 넷플릭스(페북다음) 드랍박스, 큐블 에어비엔비 등에서 사용중
페북 : 하루 3만건 ( 데이터 사이언티스트 1000명이 사용중)
넷플릭스 : 하루 2500건 /
에어비엔비 : Airpal 이라는 presto query execution tool >> open source
안써본 사람은 잇는 사람은 잇어서 한번만 쓰는 사람은 음성 ~ 마법의 툴
비슷 비슷 : 타조 / 임팔라

# presto

$ presto  
$ describe
$ select

기존 db와 비슷 like mySql
따로 러닝 커브가 없이 업무에 바로 사용 가능

# 장점

빠르다.interactive
기가바이트 부터 petabyte 급 도 빠르게
hive 보다 훨씬 빠르다
ORC 파일 reader를 쓰면 더 빠르게 대용량 처리 가능
자바로 짜여져있고, 플러그인 작성 가능. >> 플러그인 작성법은 낭중에 ㅋ
ANSI-SQL 표준 질의문을 사용
코드 제너레이션 가능
오픈 소스
임팔라는 소스가 오픈되어잇지만 풀리퀘 안받는데 여기는 받음 ㅋㅋㅋㅋㅋ
coordinator + worker (하이브랑 비슷)
http로 rest api로 커넥트
하이브/몽고 디비 등과 연결 가능

SELECT *
FROM hive.world.orders
JOIN mongo.deview.lineitem i

이런식으로 가능

기존에는 각각의 DB에서 가져온다음 어플단에서 combine해줫는데 그럴필요가 없음
노드 사이의 전달
(기존에는) “ ”라는 raw data가 지나갔는데 “PAGE"로 컬럼 형태로 전송

# Cluster memory manager

메모리 상에서 처리

특정 쿼리가 메모리를 많이 차지할 경우 >> out of memory

but Presto는 메모리 매니저가 위의 경우를 magaging 함 -- General pool -- Reseved Poool -- system pool
현재 실행중인 것 중에 많이 차지하는 얘가 먼저 끝나고 다른 얘들 돌도록 매니징
코디네이터는 각초마다 워커들의 메모리를 체크해서
내부 캐시를 통해 워커 메모리에 직접 key/value를 사용해서 올려놓고 나중에 join 해서 쓸 수 잇다고 함

# Security

kerveros ssl

# 내부 기능

버전이 괜춘한지 verifier
benchmark
query queue
JDBC driver
python/ruby 프레스코 클라이언트
Presto metrics < 내부 시스템 spec 확인 쉽게 해주는 툴 제공 (오픈소스)
Event Controller 외부 시스템에서 테러나 이런 것들 등등 받을 수 있도록 > 얼마만큼의 쿼리가 들어왓는지, 스텍 트레이스 등등

# Library

/airlift/slice
자바의 기본 바이트 버퍼가 느리다.
그래서 unsafe를 이용해 자체 만들어서 더 빠르게 읽어들임.
/airlift/airlift — 분산 시스템을 만드는 framework.
Fastutil — Fast Java Collection — 큰 자바 콜렉션을 더 빠르게 처리
ASM — Bytecode manapulation
그 밖에
jdk1.8
guice,
guaba
jetty
jackson
jersey

Method Variable Biding
@SqlType (“RegExp”) >>> @SqlType(VARCHAR) Slice pattern
@SqlType (BOOLEAN) >> @SqlType(VARCHAR) Slice source

자동 바인딩이 됨

# Plugin

데이터를 읽어 엔진에 보내주는 기능
하이브 버젼별, postgres kafka 등등
몽고디비는 내(발표자)가 만듬
Raptor
워커에 직접 orc format으로 넣어주고 그대로 빼주고
따로 하둡을 깔 필요 없음.
기본 하이브보다 더 빠르게 할수 잇음 — 실제 페북에서도 리얼타임 처리를 이걸로 하고 있다고 .
mongoDB plugin 만드는 방법 demo
타입 추가를 @JsonCreator로 더할수 잇음 ex ) 몽고 디비의 ObjectId

# Future

cost based optimization
join hint
곧 추가가 되지 않을까?

표준 질의 사용 spark 와 대비 햇을때 계속해서 안정화 되어가고 잇음.

억단위 데이터가 잇을때 정확한 값을 안주고 근사치를 준다?

# 데이터 샘플링 방법

실제 질의

정확한 값 select * from hive.world where condition

샘플링 기능 제공 ( 근사치를 뽑아주는)

하이브보다 정확성은 똑같고 스피드는 평균적으로 10배정도

# [12] S2Graph: A Large scale graph database with HBase

slide : http://www.slideshare.net/deview/263-s2graph-largescalegraphdatabasewithhbase2

서비스들에서 관계들을 모아 모아서
문제점 — 데이터가 엄청 커 : 대략 관계 10억건, 사용자 2억건
계속 유저 액티비티가 늘어남 데이터 사이즈 10억건
업데이트 만 2억권
계속 변화하는 데이터

# 하고 싶엇던것

바로바로 서비스에 가져다 쓸 수 있게
친구가 좋아한건 바로바로 업뎃 되엇으면 좋겟다 ( 5분뒤 동기화 ㄴㄴ ) 고로, 결과를 캐싱하면 안댐.

시간순서(timestamp)가 아닌 랭킹 로직이 들어갓으면 좋겟다.
pull strategy (차용한것 ) ( push strategy 라는것 도 잇음. 나중에 설명)

# BEFORE

원래는 각 서비스 별로 데이터 베이스가 샤딩 되어잇음.
만약 웹툰을 좋아한 사람을 찾으려면 카카오API를 통해 친구를 얻고 웹툰 DB 또 찾아야함
api 를 통해 하다보니 케파 문제도 잇고
api 계속 뚤어줘야 하고 그러다 보니 개발 속도가 느려짐
한쪽이 바뀌면 다른쪽도 바꿔야 하는 구조적 문제
mysql를 저장하다보니 클릭이라던가 이런건 수집이 어려웟음.
비지니스적으로 의미잇는 데이터를 insett 하지 못햇엇음.

# AFTER

서비스앱 >> 다 쏴줘 >> S2GraphDB (stateless app servers) >> HBase

# 그래서 S2Graph를 왜 만들엇는가

다른 솔루션들을 찾아보앗지만 성능 이슈/복잡도/입맛에 맞춰 바꾸기 힘듬 등
(사내에서 일케 쓰여요) Storage as a Service + Graph API = Realtime Breatdth First Search
단순 BFS를 빠르게 집중.

# 왜 마이에스큐엘 안하고 그래프DB왜 써?

성능/유지보수가 더 용이함
사실 뒤에서 써도댐. >> DB 디펜던시가 음슴.

# 추천

Batch 로 취향이 비슷한 사람을 뽑고 >> S2graph에 올리면 취향이 비슷한 사람들이 반응한것들을 뽑을 수 잇음
이 Batch 부분은 S2Graph는 완전 별개임 (S2Graph는 서빙하는 곳임)
쿼리 타임을 어케 주느냐에 따라 다이나믹 정도가 달라질 수 잇음.( 최근순을 더 가중치를 주면 다이나믹, 최근에 가중치를 낮추면 static)

similar Users는 배치지만 user-product interaction은 계속 다이나믹하게 달라지고 잇음.

# Item-based CF

batch layer가 뒤로 빠짐
similar products 부분은 배치로
Grouping으로 나눠서 배치 작업을 없앨 수도 있다.

# Spreading Activation

나랑 같은 프로덕트를 반응한 사람들을 찾아서 그 사람들이 반응한 다른 product들을 뽑을 수 있다 (no batch) 마이에스큐엘의 경우 self join 때문에 성능 문제가 나오지만 hbase의 경우 성능이 좋아짐) 컨텐츠의 생명 주기가 짧을 경우 효과가 크다 ex) 뉴스

다음카카오 19개 서비스
설득 힘들엇음 (graph로 표현 가능한지)
object = vertex
Relation = Edge
BFS가 필요하더라

####API

####Vertex

Vertex 를 insert/delete/select 가능 (inser overide)
key/value

# Edge

CRUD
관계까지 들어간다.
key/value
임의의 프로퍼티 저장 가능.
정렬이 되어잇음. 속도 보장을 위해

# Query

queryparam으로 스텝을 이루고 그 스텝들이 쿼리를 구성
스텝을 멀티플로 지원
사내 서비스들이 rails를 많이 쓰는데 쓰레드를 구현하기 힘들어서 concurrent 하게 오퍼레이션을 해줄 수 잇도록 만들엇다.
pinterest도 비슷한가 쓰는데 이런 기능 음슴

# Indices

index 추가 가능.
int long float string data 다 서포트

# 결론 : S2Grpah는 스토리지 서비스/ 그래프 모델

아파치 지라프랑 다른게 몬데? 시작점 vertex를 찍고 거기에 연관된 것들을 뽑아오는것에 집중 친구가 젤 많은 사람은? 이런고 노노

####PUSH 내가 라이크 하나할 경우 모든 친구 feed queue에 write 해야함.

select 가 빠름
timestamp로 하기에는 좋음.

# PULL

내가 라이크 해도 딱 하나만 write (post에 대해) 저장 event에 대해 update 1 번

대신 쿼리타임에 여러가지를 처리해야함

pull / push모두 지원하긴 하지만 pull이 response를 초당 2만 tps를 견딜 수 잇엇음 reponse 100ms under

기존 redis cache를 빼낼 수 잇엇음
WAL log 를 카프카에 남겨줌

데이터 분석가한것들이 S2Graph에 들어감

# 오픈소스

벌크 로더도 오픈소스

# AB 테스트

Edge 그래프가 지원되어서 사내에서 사용중

어떤 쿼리가 어떤 노출되엇고 어떤게 클릭이 되엇는지 그래프 그려줌
서비스에서는 edge 인서트만 해주면 됨.only

# S2Graph internal

예전 발표를 한번 보자.

# 성능

거의 디폴트의 hBase 사용
열악한 환경의 서비스

벤치마크 천개의 컬럼 1억 row 퍼포먼스 결과

ex. 친구 100명에 10명씩 43ms

# linear 스케일러블

쿼리 스텝이 늘어나도 성능 차이가 없다
모든 데이터를 모으고 추천을 편히 해주고 싶다.

####벤치마크 툴

nglinder

뭔가 말할려다가 더이상의 설명은 생략한다

# 그래프DB

orientDB? 100억건 넣어봤더니 느령.. insert가 오래걸리나보네. ** 실제로 어떤게 그사람들에게 노출되엇는지도 저장중. ** 샤딩 보다는 linear 스케일러빌리티

# 쿼리 리밋

성능상 갱장히 중요
BMT 미리 검수를 한다 b4
paging를 추천함

# 개인 느낀점

아쉬웠던 점부터 공유하자면.. 4개의 트랙이 동시진행 되다보니 듣고 싶어도 못들을 세션들이 좀 있다 ㅠ.ㅠ 아파치 스팍 관련이라던가 swift 프로그래밍, 로봇, pinpoint, 추천 등등. 참관하신 다른 분들의 이야기만 들어도 흥미진진한 발표들이 참 많았다. 그리고 머신러닝, 빅데이터, 추천은 역시 큰 화두였는데.. 그에 비해 내가 아는 빅데이터는 너무 초보적이여서..편식하며 듣지 않았나 싶다. 또, 부스들이 다양하지 못했다. 그동안 다른 컨퍼런스에서 보았던 다양한 기술 커뮤니티들이 없어서 조금 아쉬웠다.

당장 써먹어봐야겠다! 했던 것은.. 우선 최근 가장 많이 사용하고 있는 React 관련. React 세션에서는 "리액트"에 대한 기술 뿐만 아니라 함께 사용되는 Babel, Hot module replacement 와 같은 같이 쓸만한 기술들을 소개해 준 부분이 정말 좋았다. 생산성을 크게 올릴 수 있을 것 같다! 또한 JPA 세션을 통해 알게 된 성능최적화/지연로딩 즉시로딩 등. 앞으로 jpa를 쓸 때 좀 더 꼼꼼히 생각해볼 수 있을 것 같다.

기억에 남는 세션은 Circuit이였다. 서킷 클라이언트들의 P2P 네트워크와 마스터-스케쥴러-잡의 역할 등이 기존 내가 생각하던 시스템 아키텍쳐와는 달라 정말 신선했다! 고랭이 항상 관심은 있지만 차일피일 미뤄오고 있었는데, 서킷 써보기 위해 고랭을 공부해볼까 한다. 아직 공개된 demo 에 대한 문서화가 완료되지 않았다고 하는데, 얼른 보고싶다!

발표 중 인상깊었던 경험 공유는 네이버 효과툰 구현 발표에서 임대현님 이였다. 2011년 데뷰 참석 때 감명받으시고 저 자리에 서보고 싶다 라고 꿈꾸셨는데 2015년 드디어 그 자리에 섰다는 이야기였다. 개인적으로는 2012년 DevOn을 보며 아 저 회사 참 좋다. 나도 저 멋진 개발자들과 함께 일해보고 싶다! 라고 생각했는데 정말 입사하여 2013년 DevOn때 자원봉사활동으로 참가했었다 ㅎㅎ 완전히 같지는 않지만 비슷한(?) 감회를 느껴봐서 그런지 더 와닿았다. 언젠간 나도 저런 자리에 서 볼 수 있지 않을까?ㅎㅎ 과연ㅋㅋ

짧았던 이틀동안 많은 경험을 공유받았고 자극도 많이 받았다! 좋은 컨퍼런스 참관할 수 있게 도움 준 주변 많은 분들께 감사드리며 글을 마치겠다.