[2019.10.29] Deview 2019, Day2

https://deview.kr/2019/schedule

DEVIEW 2019

 

  티켓 신청을 폰으로 이틀 다 성공했다. Day1은 AI위주라 팀원분께 양도를 했고(하필 그날 대통령이 오실 줄이야...) 웹, 서버 등을 주로 발표한 Day2 하루만 다녀왔다.

 

  하루에도 수TB, 수십억건의 로그가 발생하는 네이버 검색에서 필요한 부서에 어떻게 잘 제공하고 있는지, Pinpoint가 점점 더 안정성과 성능을 올리고 있는지, Serverless 환경에서의 성능이슈 해결 공유, 콘텐츠 검색개발에서 주DB인 몽고DB의 속도 이슈를 해결했는가 등은 네이버의 기술력을 알아볼 수 있는 시간이었다. 쿠팡의 개인화 추천 시스템과 11번가의 Kafka를 활용한 MSA 전환기 등도 흥미로운 주제였다. 특히 11번가의 Kafka 관련된 내용은 최근 프로모션 관련 된 것을 개발하면서 Kafka를 사용한 경험과 맞물려 공감이 되면서도 재미있었다. 발표도 너무 재밌게 잘해주셔서 집중도 잘됐다.

 

  첫째날 keynote에 문재인 대통령이 깜짝 등장하여 연설을 하였다고 하는데 가지 못해서 살짝 아쉬웠다. 언제 대통령을 개발자 행사에서 만날 수 있을까. 그리고 얼굴인식을 통한 본인 인증 시스템이 도입되었는데 인식률이 매우 좋아(가까이 가자마자 본인 인증이 바로 완료 됨) 네이버의 기술력에 놀랐습니다. 기존에 인증했던 방법(이름과 이메일을 알려주고 사람이 직접 체크) 보다 훨씬 빠르고 간단했다. 처음엔 '인식 잘 안되고해서 더 혼란스럽지 않을까?' 생각도 들었으나 나의 큰 착각이었다.

 

  올해도 네이버 및 계열사들, 그외 다른 회사들에서 다양한 기념품들(유리컵, 부기보드, 티셔츠, 스티커, 노트, 에코백 등)을 나누어 주며 리크루팅과 홍보에 힘쓰고 있었다. 어디 좋은 회사 없나 보았지만 역시 우리 회사보다 나은데는 없는 것 같다.

 

  팀원분도 참석하여 같이 점심도 먹고 세션도 들으며 심심하지 않은 시간들을 보낼 수 있었다. 내년에도 더 다채롭고 의미있는 발표들이 많이 있었으면 좋겠다.

---

<시간표>

DAY 2

• 09:00 ~ 10:00
  • REGISTER
• 10:00 ~ 10:45
  • 네이버 로그를 지탱하는 힘
 (DataStore 로그 저장소)이윤경, 강민우 / NAVER / Big data&AI Platform
  • 모바일 시대, 웹브라우저는 더 새로운 웹 경험을 만들 수 있을까? (Whale 2.0 + Live coding)김효, 김지한 / NAVER / Whale
  • Multi-Tenancy Kubernetes on Bare-Metal Servers (네이버 컨테이너 클러스터)이종현 / NAVER / Container Platform
  • 고품질 영상의 안정적 송출, 네이버 모바일 라이브 스트리밍 (V LIVE 에서 PRISM LIVE STUDIO 까지)김정명 / NAVER / 동영상플랫폼
• 11:00 ~ 11:45
  • Pinpoint는 어떻게 observability를 강화했는가구태진 / NAVER / Observability Platform
  • 안드로이드 앱의 다중 웹뷰 환경에서 성능 병목 진단 및 최적화 사례이성원 / NAVER / Whale
  • 퍼블릭 클라우드 서비스를 위한 네트워크 가상화 모델정정화 / NBP(Naver Business Platform) / Network Delivery Service
  • 덕질의 끝을 보여주고 싶은 Vlive박정영, 오한기 / NAVER / V DEV
• 12:00 ~ 12:45
  • ms 단위의 Serverless World에서 Docker의 성능 한계 극복하기김동경 / NAVER / PaaS
  • Fail Fast, Learn Faster SRE (실패에서 배워나가는 SRE)김재헌, 유호균 / NAVER / Service System Reliability
  • 앱 패러다임 변화 어떻게 적응할 것인가? (모듈 중심의 안드로이드 앱 설계)신동길 / NAVER / 네이버앱개발
  • 고품질 라이브 서비스의 유지 비결 (라이브 미디어 스트리밍 서버 개발기)강인철 / NAVER / 동영상플랫폼
• 12:45 ~ 14:00
  • LUNCH
• 14:00 ~ 14:45
  • 속도의, 속도에 의한, 속도를 위한 몽고DB (네이버 컨텐츠검색과 몽고DB)박근배 / NAVER / 지식DB서비스플랫폼
  • React, Angular, Vue를 한 번에 지원하기 위한 설계 (Cross Framework Component)최연규 / NAVER / FE-Platform
  • 대용량 멀티테넌트 시큐어 하둡 클러스터를 시행착오 없이 만들기권병창 / NAVER / Big data&AI Platform
  • 네이버 동영상 서비스를 지탱하는 VOD 플랫폼 개발기조성철 / NAVER / 동영상클라우드1개발
• 15:00 ~ 15:45
  • 쿠팡 추천 시스템 2년간의 변천사 (상품추천에서 실시간 개인화로)오성민 / Coupang / Recommendation
  • 2019년 FE 프레임워크를 배우는 기분(FE 인싸들이라면 알고 있어야 하는 프레임워크 기술들)박재성 / NAVER / PaaS
  • Tracing, 눈발자국 만들기박한범 / KossLab / 오픈프론티어
  • 동영상 스트리밍 서비스, 빠르게 더 빠르게 (Ultra Low Latency, Ultra Fast Playing)황현동, 이종혁 / NAVER / 동영상플랫폼
• 16:00 ~ 16:45
  • 스케일아웃없이 순간 급증하는 주문 처리하기 (Microservice with Kafka)김태경 / 11번가 / Platform Engineering
  • console.warn('좀 불안하지?') //node.js 모니터링을 위한 pinpoint node agent 개발기배근배 / NAVER / 쇼핑전시개발
  • Armeria: 어디서나 잘 어울리는 마이크로서비스 프레임워크이희승 / LINE+
  • 대규모 클러스터 모니터링 도전기: 모니터링, 어디까지 알아보고 오셨어요? Cluster level 부터 User level까지주정인, 이영곤 / NAVER / Big data&AI Platform

 

---

<사진>

 

---

 

<필기>

네이버 로그를 지탱하는 힘
 (DataStore 로그 저장소) 이윤경, 강민우 / NAVER / Big data&AI Platform (10:00 ~ 10:45, Hall A)

1. 로그 저장 이야기 (강민우 NAVER)
   • 기존 문제
     • 생산자와 소비자의 강한 결함
     • 매번 커뮤니케이션 필요
   • 로그 저장소의 주요 역할
     • 유실 없는 로그 저장
     • 원하는 기간 + 필요한 필드
     • 동일한 인터페이스
     • 보안 정보에 대한 처리
   • 고유 식별자 할당
     • UUID 버전 1 모방: Sender 서버 IP + 로그 생성 시간 (ns) + Variant 값 (사용자로부터 받음)
   • RowKey 디자인
   • 동일한 region으로 쏠리는 hot spot 현상 발생 가능 (RowKey 앞부분이 동일해서)
     • salt를 추가해서 분산되게 처리
   • 저장 공간을 용도별로 분리
   • 티켓
     • 리소스 관리 및 접근 제어
       • 티켓마다 사용량 제어 (마이그레이션 시 변경)
   • DataStore에서 필요한 데이터를 사용자가 찾아가기 쉽게 됨
2. 로그 활용 이야기 (이윤경 NAVER)
   • 네이버 검색 로그
     • 하루 수TB, 수십억 건
   • 로그를 찾는 사람들
     • 서비스 개발자, 검색 모델링, Data Scientist, 높으신 분들...
   • 로그 활용의 문제점
     • 요구사항 - 결재 - 분석결과 - 지표 - reject ...
     • 번거로운 프로세스, 수동적, 부정확한 지표(폐쇄적)
   • 로그를 오픈하고 자유롭게 분석하자!
   • 로그 사용성의 어려움
     • 분산파일 시스템, 프로그래밍, 터미널 환경, MapReduce ...
   • SQL Inteface 도입
     • Hive, beeline, hue, zeppelin
   • 가공 테이블 성능
     • ORC Format
     • Partitions
     • Buckets

Pinpoint는 어떻게 observability를 강화했는가 구태진 / NAVER / Observability Platform (11:00 ~ 11:45, Hall A)

1. 소개
   • Moniroting <-> Observability
   • Pinpoint
   • ScatterChart
2. 실시간 observability 확보하기
   • PinpointPacket
   • 콜렉터에서 Packet 수신
   • Handshake
   • 상태값 생성 및 변경
   • 에이전트 연결 정보 공유
   • 주키퍼 이벤트 저장
   • 웹 콜렉터 연동
   • StreamPacket 추가: 1초마다 Req/Res의 한계를 해결하기 위해
3. 효율적으로 observability 정보 저장하기
   • 해결해야 하는 문제
     • 사용자 늘어나 저장공간 부족, 네트워크 대역 부족 -> 조회 시간 증가
   • 데이터 저장방식 변경
   • Dynamic Encoding 지원
   • Hbase Parallel Scanner 개발
     • 여러 region에 넣고 병렬적으로 조회
4. 다양한 컴포넌트에 대한 observability 확보하기

ms 단위의 Serverless World에서 Docker의 성능 한계 극복하기 김동경 / NAVER / PaaS (12:00 ~ 12:45, Hall A)

1. Serverless Computing이란 무엇인가?
   • 진화 과정: Physical Machine - Virtual MAchine - Container - Serverless
2. Apache OpenWhisk
   • 액션의 실행
     • 같은 요청이라도 invoker에 따라 속도가 달라질 수 있음
   • Optimal한 스케쥴링이 불가능한 이유
     • 모든 invoker로부터 실시간으로 리소스 정보를 수집하고
     • 다른 Controller의 스케쥴링을 고려하고
     • 최적의 위치로 실행 요청을 전송
     • 을 2ms 이내에 이루어저야해서 어려움
   • Apache OpenWhisk의 스케쥴링 방식
     • Hash 함수를 통한 위치 결정
     • 각 컨트롤러가 리소스를 나누어 가짐
3. Docker daemon이 야기하는 성능 이슈
   • 액션간의 간섭
     • 최대 650배 느려짐
     • 이후의 모든 실행도 함께 느려짐 (sequantial하게 처리)
   • 앞선 실행을 기다리지 않음
     • 500ms보다 적은 실행시간을 가지는 경우 ColdStart보다 이전 실행을 기다리는게 나음
4. 성능 이슈를 극복한 방법
   • Pull 기반 스케쥴링
     • 컨테이너의 위치를 신경쓰지 않아도 됨
   • 컨테이너의 생성과 액션의 실행을 분리
5. 기타 - 오픈소스 컨트리뷰션 및 Committer 자격 확보

속도의, 속도에 의한, 속도를 위한 몽고DB (네이버 컨텐츠검색과 몽고DB) 박근배 / NAVER / 지식DB서비스플랫폼 (14:00 ~ 14:45, Hall A)

1. Why MongoDB
   • Fast, Scalable + Highly available
2. MongoDB 속도 올리기 - Index
   • 이해하기
     • 컬렉션당 최대 64개 인덱스만 생성 가능
     • 너무 인덱스가 많으면 오히려 side effect 발생
       • Frequent Swap, Write performance 감소
   • Index Prefix를 사용하자
   • 멀티 소팅
     • 소트 키들은 반드시 인덱스와 같은 순서로 나열 되어야만 한다.
     • compound 인덱스의 경우, 소팅 방향이 중요함
3. MongoDB 속도 올리기 - ^Index
   1. 하나의 컬렉션을 여러 컬렉션으로 나누자.
   2. 쓰레드를 이용해 대량의 Document를 upsert
   3. MongoDB 4.0으로 업그레이드
      • non-blocking secondary read 기능 도입
4. 미운 Index
   • Slow Queries...
   • key examined(찾기 위해 읽는 수)가 높아서 느렸음
   • 해결 방법
     • Hint 이용 vs 엄한 인덱스를 지우기 -> 엄함 인덱스 지우기

 

쿠팡 추천 시스템 2년간의 변천사 (상품추천에서 실시간 개인화로) 오성민 / Coupang / Recommendation (15:00 ~ 15:45, Hall A)

 

스케일아웃없이 순간 급증하는 주문 처리하기 (Microservice with Kafka) 김태경 / 11번가 / Platform Engineering (16:00 ~ 16:45, Hall A)

 

아래 두 세션은 노트북 배터리가 나가서 필기를 못함.