Deview Day 1

Quality without QA

VSync

• 모니터는 어떻게 화면을 업데이트 할까?
  • 그래픽 드라이버에 버퍼에 있는 것을 그냥 찍는다.
• Tearing
  • 현재 프레임에 이전 프레임의 화면이 보이는 경우
  • 모니터가 화면을 갱신하는 동안 버퍼스왑이 발생해서 생김.
• Vsync
  • 모니터가 업데이트 되는 동안 버퍼 스왑을 금지.
  • Vsync을 켜면 모니터의 갱신주기에 버퍼스왑 시기를 맞추게 된다.
• fps
  • 당연하지만 높을수록 좋다.
  • 일정하면 좋다(자연스러워 보인다).
  • 모니터 refresh rate에 맞춰줘야 일정해 보이고 매끄러워 보인다.
• Vsync 정보가 필요하다!
  • API가 각 벤더별로 존재한다.
• requestAmimationFrame
  • Vsync와 매칭되게 연결
• requestIdleCallback
  • IdelCallback을 달수 있음.

How Riot Works

• 개발자의 철학
• 고양이가 pt를 캐리한다!
• 애자일 이야기

영상 분석

• 영상 분석 방법
  • Heat Map - 그부분에 몇번 갔는지
  • Movement Flow - 움직임 분석
  • profile - 사람 분석
• 딥러닝을 어떻게 적용했는가?
  • 이미지 분류
  • 큰회사가 많이 도전 한다.
  • 돈이 많이 드는 기술?
    • 공개 데이터 셋이 많더라
    • 스탠퍼드 대학의 데이터셋이 좋더라..
    • 얼굴인식은 FERET
  • 뉴로 네트워크 이야기 갓재화
    • back propergation
    • 계산량이 많다..
  • 괜찮아 GPU가 있잖아..
• 딥러닝 방법?
  • 계열은 많다..
  • 목적을 분명히 하고 공부할것
    • 영상은 컨볼루션 뉴로네트워크
    • Time이 들어가면 딴거..
  • 코드를 가지고 공부하면 쉽다.
• 그래서 적용기
  • 기법
    • Harr Cascade Classify
    • Convorsu N.W
  • 데이터셋
    • FERET
  • FINE Tuning
    • CNN 을 ImageNet 데이터셋으로 학습
    • 마지막 레이어만 문제에 맞게 변경
    • 그리고 타겟 데이터 셋으로 다시 학습
    • 효율이 좋더라.
  • 노이즈 첨가하면 성능이 올라간다?
    • 회전, Cut
      • 안되더라..
    • Blind(일부분 가리기), Blur
      • 성능 올라가더라
  • 결국 데이터 셋이 좋아야 성능이 좋다.
    • 데이터 분포가 일정해야 하고
    • 라벨링이 잘 되어야 한다.

소감 : 갓재화. 패턴인식 내용 그대로 나옴. 패턴인식 수업 꼭 들으세요.

Web compositing

• CSS애니매이션은 브라우져 제작자에게는 끔찍하다..

• VSync을 기다리다고 Spin Lock을 한다.

• Javascript를 쓰니까 뭔가 느려질 가능성이 높다.

• 뭔가 잘 모르겠는 이야기 지나감

• WebGL

  • 화면 만드는쪽이랑 그리는 쪽이 타이밍이 다르다!
    • 싱크로나이즈 이슈!
    • 여러가지 방법으로 해결
      • 버퍼 스왑

• 2DCanvas

  • WebGL과 비슷하지만 더 어렵다.
  • 이전 버퍼가 있어야 하기 떄문
    • 카피가… 비싸..

• 뭔가 후르륵…. 암튼 별의별 난관이 많다.

소감 : 뭔가 안드로메다…

DEVIEW Day2

Large Scale Backend Service development using Node.js, Docker AWS

• 아이유 PM님이 일을 시킨다.
  • 하겠습니다.
  • 하지만 미친 요구사항
• 리더보드 프로젝트
  • 소환사 매칭
    • 대규모 API과 대규모 쿼리
    • 빠듯한 개발 시간
• Goal
  • 확장성
  • 성능
  • 빠른 이터레이션
• 사용기술
  • EC2
  • 엘레스틱 서치
  • 레디스
  • 클라우드 플레어
    • 캐싱과 DDOS
    • SSL
  • Node.js
    • 성능 짱
    • 생산성
• Node.js
  • 멀티 코어
    • 리버스 프록시로 멀티코어 대응
    • Native Clustering
  • 늘 그렇듯 콜백 헬
    • 그리고 늘 그렇듯 프로
  • 성능개선 프로파일링
    • –prof
    • 프로파일링 위해서 라이브러리 설치했더니 성능이 떨어짐
      • 몇개만 설치함
    • 0.12 버전의 기능을 사용함.
• Redis
  • 생략
  • 압도적인 실행 성능
    • 부하를 잘 버틴다.
    • 고차원 데이터 타잎지원
• Docker & AWS
  • 결합해서 사용
  • deploy2ecs 라는 툴을 만들어서 사용.
    • AWS가 너무 많은 학습내용이 있다.
    • 선언적 배포 관리가 가능하다.
    • 내가 vm-manager를 개발하는 것과 비슷한 이유인듯..
      • 설정을 관리하고, 현재 상태를 쉽게 알게 한다.
  • T2는 CPU가 자주 스틸당함
    • c4.xlarge 씀
• 비용
  • 퍼포먼스 최적화 하면 비용이 준다.
  • 일단 100대의 서버가 월 20000불이라니…

Docker

• 하게 된 이유
  • 이미지로 배포하면 좋겠다
  • Docker는 된다.
• Orchestration
  • 여러게의 컨테이너로 하나의 서비스를 구성하는 것
  • 이유
    • composition
    • Replication
    • Write Once Run Anywhere
  • 요소
    • 스케줄링
    • 뭔가
    • 뭔가
    • 뭔가 발표자료 참조
  • docker Swarm
    • API가 부족함
    • 매력적이지만 아직 프로덕트에 쓰는건 아닌것 같다.
  • Kubernetes
    • 구글에서 씀
    • 구글 컨테이너 엔진
    • 안정적
• 처음에는 간단한 젠키스 서비스 부터..
  • 근데 쓴게 간단치 않다… 뭐가 많네.. 그냥 해봐야 할듯..
    • 쉽데…
• 몇가지 이슈
  • 컨테이너는 stateless해야한다.
  • 컨테이너에 인스턴스 종료후 데이터를 보관해야 한다.
  • Multi-Cluster를 고려해야…
    • 클러스터별로 다른 경우가 생긴다.
• 도로시
  • 오오 자동화 오오

서킷

• 클라우드 OS?
• 뭔가 특이한데…?
• https://github.com/gocircuit/circuit
• 가상화 계층을 진짜 코드로 쓸수 있다.
  • 언어는 golang
  • 이걸 활용해서 docker를 관리하는 오케스트레이션 서비스를 만들수도 있다.
  • 상태 확인도 코드로 가능해진다.
• 코드 설명…
  • 장황하지만 요약하자면 바로 전세션에서 했던거 그대로 함 + 코드니까 스케쥴링도 됨.

WiFi로 위치 인식하기(mute.ly)

• 스마트 폰에서 위치 인식하기
  • 센서
    • 소리
      • 스타벅스에서 쓰는방법
      • 초음파를 통해서 인식함
    • 비콘
      • 2.4GHz
      • 사람이 복잡하면 잘 안될 수 있다.
      • 세기가 약하다.
    • 와이파이
      • 가장 많이 쓴다.
      • 세기도 세다
    • 마그네틱
      • 자기장의 패턴을 인식
      • 2m정도의 정확도.
      • 다른것과 보충해야 써먹을 만 함.
    • 가속도계….
• 와이파이로 어떻게?
  • 거리에 따라 세기가 로그 스케일로 감소
    • 장애물에 따라서 다름
    • 감쇠하는 패턴을 나타내기는 하지만 별로 정확하지 않다.
  • 삼변 측량! (삼각 측량)
  • Finger printing
    • WiFi에도 지문이 있다.
    • 특정 지점의 지문을 얻어와서 현재위치 파악
    • 근데 와이파이가 켜져 있어야…
    • 패턴분석을 하는 방법은?
      • Tanimoto
      • Cosine
• 그런데…
  • 스캔 할때 보면 10~20%는 잘안된다.
  • 몸으로 가리면 시그날 감소.
  • AP가 움직인다!!!
    • 움직이는거는 제외하자
  • 같은 아이디가 많다.
    • 02:e0:83:54:70:9X <- 유니크 하지 않다.
  • WiFi가 몇개없으면 잘 안된다.
  • 기기마다 편차가 있다.
    • 디바이스가 달라지면 학습 데이터가 필요없어진다.
  • 에이징(시간에 따라 변하면)
• 서버에다 올려서 비교하면 같이 있는지 알수 있다.

코끼리 냉장고에 집어 넣기

• 추천엔진
  • content-base
    • 이미 내용을 잘아야 한다.
    • 메타데이터가 없으니까 뽑기도 힘들다.
  • collaborative filtering
    • 많이 쓴다.
• based 모델
  • 비슷한거 뽑은다음에 안한거 추천
  • 자카드
  • 근데 크기가 문제…
    • 컴비네이션이 늘어난다.
    • 하둡!
    • spark때문에 약빨이 떨어졌다.
  • pre-clustering을 하자
    • 클러스터링도 무거우니까 클러스터링을 가볍게 하자.
    • 구글 개인화 논문
      • MinHash
        • Locality hash
        • 적은 버킷에 충돌나게 넣으면 클러스터링!
          • O(n)짜리 클러스터링
        • 적은 문제로 나누어 처리
        • 해쉬 평션을 잘 짭시다.
• Minhash
  • Permutation을 한 임의의 순서대로 읽으면서 첫 true의 인덱스를 구한다.
  • 이것도 계산량이 많다.
  • Universal hash를 잔뜩 만들어 대신 쓴다. -> 라이브러리 쓰세요.
  • 이걸 잘 처리하면 클러스터링이 된다.
  • 논문읽으면 이해 됩니다.
• 더 멋지게 만들자.
  • 두개의 문제가 있다. (느리다, 구리다)
  • Heavy I/O가 잦다.
  • 클러스터링
    • 장정 : 후보를 한정한다. 스피드 빠름
    • 단점 : 후보를 한정한다. 퀄리티 낮음
  • I/O가 무거운 이유
    • 데이터 부익부 빈익빈
    • 극단적인 데이터
    • 인기있는 데이터
      • 자주등장
      • 긴 click Stream
      • 로딩도 갉아먹고..
      • 메모리가 무너지고, CPU가 무너지고
  • 해결방법
    • 긴걸 짧은 걸로 대신하자
    • minhash로 다 대체 하자
  • 근데..
    • 오차는?
    • 해쉬평션을 더 많이 쓴다.
    • 100개 정도면 충분한것 같다.
• feature의 갯수가 fixed 면
  • 예측 가능해짐
  • 메모리에다 올려놓아도 예상이 가능해짐
  • 그리고 작다 크기가..
• minhash는 min의 Chain
  • 결합법칙이 가능하다.
    • 증분이 가능하다!
  • 멱등성이 있다.
    • 그냥 계산 많이 해도 된다.
  • High TPS 상황도 대응합니다.
• 근데 100개면 이거도 계산하는게 만만치 않은데?
  • 세컨더리 인덱스로 만듭시다. (키 밸류 뒤집어서)
  • 뭔가 신기하지만 잘됨
  • 자카드가 매우 빨리 계산됨
  • 메모리에서 돌아야함. - redis
    • string
    • mget
    • snappy
    • pipe
• 정리
  • 그냥 PPT보자
  • 뭐 원래 더 복잡하지만, 대충 봤을때 줄일수 있다.
  • 확률적 자료구조를 사용 하는게 굉장히 유용할수 있다.