DEVIEW 2016

네이버 개발 컨퍼런스 DEVIEW 2016!

Posted by kingbbode on October 25, 2016

Recently by the same author:


3년차 웹 개발자

4년차로 접어든 웹 개발자의 3년차 늦은 회고

You may find interesting:


GDG DevFest Seoul 2016

한국 Google Developers Group의 개발 컨퍼런스!


학습 방법 및 웹 BackEnd 개발자 학습 로드맵 - 박재성

자바지기 박재성님이 제안하는 학습 방법을 소개

Session 1. 나는 서버를 썰 터이니 너는 개발만 하여라

개발자가 개발 업무에만 충실 할 수 있도록 신뢰 할 수 있는 인프라 시스템 구축!

Zinst

  • 무엇인가?
    • Puppet,Chef,Ansible 등과 유사한 DevOps 도구
  • 왜 만들었나?
    • 무료여야 한다,
    • Learning curve 낮아야 한다.
    • 개발 업무 프로세스/정책을 실애하기 위해서는, 중앙 집중 관리되는 자동화 시스템이 필수!
  • 강점
    • 운영체제와 독립적으로 명령어 통일
    • 설치와 동시에 설정 값 적용 가능
    • History 보관
    • 원격
    • 외부 환경에 의한 문제를 최소화
  • 어떻게?
    • Bash로 제작

개발자가 직접 손대지 않아도 되는 인프라 만들기

  • 시스템 자동화
  • 시스템 표준화
  • DSL(Domain Specific Language)
  • 개발자가 볼 수 있도록 만들기
    • 서버 구성 정보/관리문서가 없어도 되는 환경
  • 패키지화된 시스템의 권한 관리
  • 분산된 수십대의 서버를 서비스/네트워크 별로 동일하게 구축하기
  • 개발자가 직접 배포할 수 있는 환경
    • CI/CD 도구 및 프로세서 만들기

Session 2. QUIC을 이용한 네트워크 성능 개선

쿠키런의 라인 진출로 네트워크 CS가 증가! 그것을 해결하기 위하여 네트워크 성능을 개선!

  • HTTP/1.1 이슈를 해결하기 위하여 구글에서 SPDY & HTTP2를 만들었지만, 완벽하게 해결하진 못함
    • 모바일에서의 TCP문제이기 때문!
  • TCP + TLS 이슈!
    • 모바일 환경과 맞지 않음

그래서 나타난 구글에서 제안한 환경인 QUIC!

  • Q uick
  • U dp
  • I nternet
  • C onnection

QUIC

  • SPDY의 장점을 그대로 가져옴
  • UDP를 사용
  • RTT-0를 지원
  • Connection을 Migration

실제 적용

  • 구글 App Engine 사용하면 QUIC을 사용 가능
  • Alternate Protocol
    • 첫 통신의 경우 평범한 Http를 이용하여 Negotiation하고, 그 다음 요청부터 QUIC 접속
    • Cronet에서 Hint 추가하여 바로 QUIC으로 접속도 가능

Session 3. 스카우터

성능 메트릭의 Visualization으로 결과는 알 수 있다.

그렇다면 원인이 무엇인가!

APM
성능 메트릭 + 원인을 찾기위한 @

Scouter APM을 구현하는 기술

BCI(Byte code instrumentation)

bytecode에 직접 변경을 가해 소스코드의 수정없이 기능을 삽입할 수 있는 방법

  • premain()만 기억하자!
    • main() 전에 수행
    • 여기서 transformer를 통해 class 변경

Scouter APM


Session 5. 루빅스(RUBICS) 개발 이야기

루빅스 총 개발기간 21개월 (2015.02년부터 시작)

루빅스란?

코드네임 Tangram

  • 유한한 리소스를 가지고, 다양한 형태를 보여준다는 의미

즉, 콘텐츠 추천 시스템.

Model

MAB의 문제점 Cold Start Problem

  • Cold Start User : 의미있는 통계를 주는 사용자가 많지 않았다.
    • 해결 방법
      • Multi-Armed Bandit 전략
        • 탐색(Explore) -> 계산(Exploit)
        • 평가가 좋은 곳을 자주 간다
        • 많이 가면 확실(탐색을 줄여도), 적으면 불확실(탐색을 더)
  • 지속적 변화
    • CTR : 관심은 계속 떨어짐
    • Position, User Cluster 편향

루빅스는 변화를 반영(실시간)

System

Request = 50억

속도에 따라 다른 파이프라인

  • streaming(실시간) : couchbase
  • mini batch(단기) : hbase
  • batch(몇 일) : elastic, openTSDB

목표

  • 데이터에 기반해 진화하는 시스템
  • 고성능
  • 확장성
  • 장애 내구성

모댈 개선 과정

다양한 모델들을 계속하여 테스트하며, 가장 좋은 모델을 선정.

  • Offline Test

    • 과거 Log를 이용해서 모델 성능 검증
    • Online의 환경을 완벽 재현은 힘듬
    • 위험성이 없는 상태에서 모델들을 테스트
  • Online Bucket Test

    • A/B 테스트
    • 실시간 테스트 분석
    • 테스트 비율을 점차적으로 늘림
    • Data Flow V2

High Performance

서버의 99% Request 응답 시간 : 3ms

Serving Layer

Serving Layer는 단순할 수록 강한 성능을 낼 수 있다.

  • nginx
  • play-scala : non blocking의 솔루션
  • Couchbase: latency 문제에서 가장 강력
  • zukeeper

latency를 줄이기 위한 노력! 데이터 형태 변경!

서빙에 최적화된 데이터 준비

Network I/O 줄이기

  • 버켓, 콘텐츠 등 미리 가져올 수 있는 정보 Local Cache로 사용
  • ZK watch로 변화 감지하여 Cache

수평적 확장 가능

  • 노드 추가만으로 확장 가능.

장애 가용성

Micro service

작업을 목적에 따라 쪼갤 수 있음.

  • 독립적 개발 가능
  • 일부 장애가 전체 장애로 전파되지 않음
  • 관리 복잡도는 증가

Service Orchestration Tools

관리 복잡도를 해결 가능

  • Task 죽지 않도록 관리
  • 일관된 배포&롤백, 모니터링할 수 있음

Test Automation

  • 지속적으로 전체 데이터 파이프라인 테스트
  • state를 확인 가능하도록
  • Alert까지