2019년 10월 31일 목요일

DEVIEW 2019 Day2 참가 세션 메모

세션에 참가해서 필요한 내용이나 기억에 남길 것을 메모함. 자세한 내용은 발표자료 참고.



[Multi-Tenancy Kubernetes on Bare-Metal Servers (네이버 컨테이너 클러스터)]


이팀은
. Container oriented : 베어메탈, 컨테이너 오케스트레이션
. Cost efficient : 범용서버 직접 구축
. Help containerize : 컨테이너 클러스트 + 레지스트리, 모니터/로깅, 교육,가이드 등 컨테이너화를 촉진하는 활동

효율적인 컨테이너 적용하려고 노력함 > Multi-Tenancy Kubernetes 로 불림
= 하나의 Kubernetes를 namespace로 나눠서 제공하는 것

Pros
. 모든 사용자가 Kubernetes자체 서버를 보유할 필요 없음
. 모든 사용자를 의한 여유 리소스를 보유할 필요 없음.
. 모든 사용자가 직접 Kubernetes를 운영할 필요 없음
Cons
. 신뢰성 있는 유저 필요
. 사용자가 Kubernetes의 모든 기능을 사용 할 수 없음
. Kubernetes가 매우 커지고 사용자도 많아서 운영하기 힘듬



현재 네이버
12+ 클러스터, 300+ 네임스페이스, 1000+ 유저
가장 큰 싱글 클러스터에 5000+ 팟 10000+ 컨테이너

2019 목표 => Elastic, efficient

Elastic한 서빙
.대규모, 실시간, 신뢰성

Efficient한 리소스 활용
.리소스 여구량, 시간대별 사용령이 모두 다름
.여유 리소스 최소화
.서버 대수 최소화 

로드밸러스 지표는 전체의 5% 수준 
> 800+ 200mac 32kcps 3G througbput

Kubernetes
대규모 클러스터 (20 node vs 500 node)
. 다수 클러스터 노드 관리, 관리서버(ETCD, api server) 과부하, 복잡해지는 관리시스템

사용 제한 
. 클러스터 영향을 주는 API 제한, 클러스터 전체에 적용되는 권한 제한 > 오픈소스 활용 걸림돌(노드/클러스터 분리, 전체 적용)

다양한 요구사항을 Affinity/Anti affinity 로 해결
. 노드 분리(private node 등), 리소스 장애 예방(리소스 부족 노드에 anti affinity 적용)

Runtime의 리소스 제한
. LimitRange 정책으로 container/pod의 리소스를 제한 (cpu 0.1 min 4 8 max), request는 limit 비율에 맞춰

Namespace Quota로 사용자별 허용 리소스 제어

Rescheduling
.long run pod이 많은 노드의 리소스 부족
.사용자가 request/limit을 잘 설정 안함
.스케줄러가 똑똑하지 않은 것 같음
> 심할경우 강제로 pod?를 죽임

자동제공 모니터링
.Prometheus/grafana provisioning 잘 정리된 텝플릿 제공
.kube event를 사용자가ㅜ 인 할 수 있도록

내년에
Network,resouce, runtime에 대한 isolation
Kubernetes Reliable Engineering + SRE
보다 많은 Cloud Native 서비스로 네이버의 경쟁력을 향상하도록


ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ



[안드로이드 앱의 다중 웹뷰 환경에서 성능 병목 진단 및 최적화 사례]


웹브라우저 엔진 vs 시스템 엔진
. 웹뷰 파편화 vs 유지보수 비용
. 웹뷰를 내장 시 크기 증가 vs 플랫폼은 버전별 피쳐 다름

XWhale 
. Crosswalks 계승
. 시스템 웹뷰 대체
. 네이버앱과 네이버 카페


사용성개선을 위한 다중 웹뷰 활용 

. 앱 초기화 시 복수의 웹뷰 사전 생성
=> 백그라운드 로딩 및 렌더링 수행으로 반응성 개선 예상

다중 웹뷰 생성에 따른 부담
. 브라우저 엔진 초기화
. Renderer 프로세스 생성 
. 웹뷰 생성 
. 웹페이지 로딩 

웹뷰 생성 측면
.웹뷰 생성 지연 이슈
.웹페이지 로딩 지연 이슈 (IPC로 인해 navigation이 시작되기전 지연)
>비동기 웹뷰 초기화 400ms, 백그라운드 웹뷰 초기화 지연 400ms

웹페이지 로딩 성능 측면
각 주제판에서 동일 css 파싱 시 시간 소모
. Loading은 caching되지만 parsing은 caching이 안됨
비용이 높은 js 문제
. Layout의 큰 변화를 야기하는 js
. DOM 전반에 대한 전면적인 변경
> rendering reschdule는 의미 없음 



성능지표?
. W3C navigation timing APi5 
. RAIL 성능 모델 
 : Response, Animation, Idle, Load
. First meaningfulpaint 
 : First meaningful paint : 페이지 layout이 급격히 변하는 순간
. Time to interactive 
. User metrics histogram 
 : chrome 브라우저에 실행정보가 누적된 in-memory DB, cache hit ratio 확인 가능

HTTP cache의 맹점
이미지 로딩 부하

성능 개선 방안
. Background 웹뷰 생성 지연 
 > 다른 리소스로 인해 종료 시간은 동일
. 브라우저엔진 비동기 초기화
 > thread 생성 overhead, callback의존성으로 효과 미비
. Priviligded HTTP cache 구현 
 > 지정된 URL 패턴, 지정된 referer, 지정된 resource type에 대해서 보존 기간 보장
 > image cache hit ratio 14%, paint 30-40m 향상
 > lower tier에서 80-120ms 개선 효과
. Cross Webview CSS cache 구현
 > Render 프로세스가 모든 웹뷰 접근(global cache)
 > css rule set은 웹페이지의 라이프사이클과 맞춤
 > 466ms의 CSS parsing이 한번만 발생
. Proxy기반 이미지 최적화
 > 디바이스 디스플레이 파편화에 대응이 어려움
 > 실제로 화면에서 보여주는 사이즈가 그림 사이느보다 커서 그닥..

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ



[앱 패러다임 변화 어떻게 적응할 것인가? (모듈 중심의 안드로이드 앱 설계)]


뭐가 변했는가?
Hardware(멀티코어, 드양한 디스플레이) 
Platform 
. Dalvik->JIT/ART 
. APP Bundle(Dynamic Feature & Delivery) 
Language (FunctionalProgramming, kotlin)
다양한 프레임워크 
. JetPack 
. RxJava 
. Lottie 
. Retrofit 
. Glide, Picasso, OkHttp 

좋은 앱은? 
. Multi-Featured 
. Multi-Media 
. Multi-CORE 
. Big-Sized 
. Multi-Module 
에서 효율적 + 빠른 개발과 유지 보수 

함수형 프로그래밍 - 간결한 코딩, 이벤트 처리 효율성

안드로이드는 Activity가 메인이자 하나의 앱 단위가 될 수도 있음. 
So library를 로드하면 프로세스를 다시 띄워 죽이지 않는 한 살아 있음
멀티프로세스 지원 필요

아키텍쳐 기반의 접근
Language Tookit 
. Kotlin Tookit 
View-Data 패턴 
. MV. MVC. MVP. MVVM 
State Model. Finite State Machine 
. State Model- 간단한 이벤트로 상태관리 (디바이스) 
. FSM - 이벤트에 따른 상태변화와 동작 구조(프로토콜, 앱상태) 
Media Processing 
. Piped Stream Model 
. Multiplexed Event Queue Model 
모듈화 
. Layed Project
. Dynamic Feature Module

어떤 것을 어떻게 적용할까?
.Kotlin toolkit 
.이벤트 라우팅 필요
.View data model
.Network model
.Multimedia model
 : MQ(센서), Produce-consumer(미디어생성 소비),pipes&filters(실시간 미디어 생성 소비)
.대용량앱 모듈 구조
 : 안드로이드 제공 기술을 사용 가능하나 결국 프로젝트, 모듈, 리소스, 코드를 컴포넌트로 분리하는게 필요함




ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ



[React, Angular, Vue를 한 번에 지원하기 위한 설계 (Cross Framework Component)]


Cross Framework Component(CFC)
> 하나의 공통 모듈 기반으로 다양한 프레임워크를 지원하기 위해 효과적인 구조를 가진 컴포넌트

Egjs의 바닐라 컴포넌트를 제공하여 다양한 기능을 사용할 수 있게 하였지만 프레임워크에서 사용 시 문제 발생
: 바닐라 컴포넌트가 각 프레임워크에서 동작이 다르거나 프레임워크에서 필요한 기능을 제공하지 않을 수 있음.

프레임워크를 래핑하거나 수정한다면 동작 이상 중복 코드의 문제다 있음 > DOM 조작

DOM diff
.?

CFC 원리
. 컴퍼넌트에서는 data를 삭제해야하지만 프레임워크에서 dom을 삭제하므로 데이터만 삭제 필요.
. 데이터 확인, 동기화?를 위한 listdiffer 를 만듬
. 프레임워크에서는 dom을 삭제 후 listdiffer로 동기화(삭제 > 유지 > 추가)

*자세한 내용은 발표자료*



ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ



[2019년 FE 프레임워크를 배우는 기분(FE 인싸들이라면 알고 있어야 하는 프레임워크 기술들)]


발표자료를 읽어보자.
발표자료가 정말 인싸의 자료답다~!



ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ



[Armeria: 어디서나 잘 어울리는 마이크로서비스 프레임워크]



마이크로서비스에 대한 간략한 설명과
만드신 프레임워크의 장점에 대해서 소개하심
함께 slack이나 nhn, kakao에서 적용한 사례를 말씀하심.

2019년 10월 29일 화요일

DEVIEW 2019 Day1 참가 세션 메모

세션에 참가해서 필요한 내용이나 기억에 남길 것을 메모함. 자세한 내용은 발표자료 참고.
솔직히 ML, AI는 뭔소린지 모르겠음.



[외산 클라우드 없이 AI 플랫폼 제공하기: features, training, serving, and AI Suite]


자체 AI 플랫폼 이유
.security - 국내 데이터는 국내에서, 지리, 정부 승인 등
.cost 
.demand

네이버는 사용하던 AI 플랫폼이 있었음
이를 엮어서 > AI Suite : End-to-End AI platform

머신러닝을 위해서
데이터 처리 ㅡ 모델 학습 ㅡ 서빙이 필요함.
실제 개발에서는 
=> 데이터 처리가 오래 걸림, 자동화 고려 필요

AI Feature 안에서
. Dump : 데이터를 가져오고
. Analyze : 가시화를 통한 인사이트
. Batch : 데이터를 선별하여 feature vector생성

Facets
단점 
. 모든 데이터 클라이언트에서 돌리므로 성능 이슈 > 샘플링을 통해서 통계를 보고 인사이트를 얻음
. HDFS라 전체를 다 읽어야 샘플링 가능 > 일부를 읽어서 전체를 예상하고  estimation 하여 샘플링

모델연구시
. 최대 GPU자원 사용
. 동시 사용하여 성능 좋은 모델 선정
. 데이터 고정으로 캐싱하면 이득

하지만 제품화 시
. 최소한의 자원 사용 (비용문제 이유)
. 배포전 이전 모델의과 품질을 검증 필요
. 새로운 데이터로 캐싱 의미 없음

서빙 = APS 서빙 + 모델 서빙

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ




[Papago: Engineering BERT into NMT]


몇가지 적긴 했는데 그냥 발표자료를 참고하여 논문을 찾아 읽어야 할 듯

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ


[챗봇 1만 개의 모델 서빙하기: AI 서비스 어디까지 해봤니]


중요한 건 모델의 규모와 서비스 형태 

미신러닝
.수백 수천 토큰 질의를 해하는 모델
. 도메인 전용 학습이 필요하지 않은 모델
.10턴 이상 문맥을 고려하지 않는 모델

구축>훈련>평가>개선 흐름을 자동화
모델의 비용을 계산하고 결과를 봐야함.

Amdahl's law
무한의 컴퓨팅 자원을 투입해도 20%의 속도 개선이 가능함.
아니 경제적인 모델: 학습과 추론의 성능 최적화가 곧 비용인 시대

최적화?
. 모델 최적화
. 모델러와 소통
. Framework customizing, JNI 수준까지
. 확장 CPU Register사용(bert 120ms에서 bert AVX-512 MKL 7ms로 개선)

1만개 서빙?
. AutoML auto quantization
. One source multi environment models(네이버 C3DL 기반 동작)
. Decentralized clusters (kaa) akka, spark, scala, tf


ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ


[모바일 얼굴인식, 엔진부터 DEVIEW에 적용하기까지]


얼굴인식으로 인증 단계 감소
1:N의 얼굴 인식의 경우 보조 인증을 주로 사용

Face engine
얼굴 검출 > 특징점 검출 > 얼굴인식 딥러닝
=>Clova Face

얼굴 검출을 위한 모델 얘기는 발표자료 참고
Engine을 Product에 적용하는 얘기도 발표 자료 참고

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ



[어디까지 깎아봤니?: 모바일 서비스를 위한 가벼운 이미지 인식/검출 딥러닝 모델 설계]


발표를 들으며 "발표자는 진정 방망이모델 깍는 노인이구나"라는 생각이 머리를 계속 맴돌았음.
발표자료는 꼭 보시길

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ


[예약 전화도 쉽게 받는 인공지능 비서를 만드는 P;ㅠ]


이분은 회사에서 자주 본 것 같은데 비슷한 사람이었나?

아직도 전화 예약을 많이 한다.
사람도 전화응대를 잘 못한다.
스피커, 챗봇과는 다름

Conversation Space

Turn, Sequence, Activity,Task 로 대화를 구분

대화에는 실패가 없다. 
Command control 패턴과 같은 스피커에서와는 다르게 대화를 반복하여 해결 가능

Full duplex <> Gateway >ASR >DNNLU >SYNTH >Gateway

성능향상을 위한 모델
. Contextual hint
. Multi turn
. Task moving
. Barge in

엔지니어링 이슈들
. Latency
. Initiative Control

2019년 10월 28일 월요일

DEVIEW 2019 Key Note 메모

Deview key note 메모



https://platum.kr/archives/130372
https://byline.network/2019/10/28-67/


치타 시연 



Autonomous space + AI AR Automation
>> A(utonomous) city




하이브리드 HD 매핑
인도어, 아웃도어 모두 매핑
도로 HD MAP DATA 무상 배포

아웃도어 로봇 Alt platform 을
인도어 로봇 Around platform 와 통합

로봇과 제 2 사옥을
Human friendly Robot & Robot friendly Building 으로

Global AI R&D Belt : 한국/일본/프랑스/동남아의 인공지능 연구진과 스타트업, 기관들을 연결

새로운 표준
더 큰 연결의 가능성
기술 상상 도전

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

수아랩
퓨리오사AI chip

문재인 대통령님 연설




ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ



(네이버 서치)


인플루언서 검색 지원 > 창작자 연결
AI 기술 - 비전 검색 등등 기술 개발
"사용자 이해" 네이버 검색 기술의 핵심 가치
>Deep understanding



(네이버 플랫폼)

클라우드 네이티브 컴퓨팅
네이버 컨테이너 클러스트

.auto scaling 트래픽 예비자원
.서버 효율 증대

2019년 네이버 서비스  60% 이상 컨테이너 운영

Pinpoint 2015년 공개
+ Nel02? npot?
+ 지원 생태계 확장

클라우드 네이티브 컴퓨팅
Observability 확대를 위한 서비스
오픈소스 생태계 지원




(네이버 클라우드 플랫폼)

2014년 부터 퍼블릭 오픈

장점
.국내 자체 기술
.안정성, 보안 측면
.클라우드 서비스 대안



(네이버 동영상)


2013 
카메라 ㅡ 인코더 ㅡ 범용미디어버서 ㅡ CDN ㅡ 모바일 플레이어 
2015
모바일카메라ㅡ모바일 인코더ㅡ범용미디어서버
2018
모바일카메라ㅡ모바일 인코더ㅡ네이버미디어서버


2020년 까지 4K
안드로이드 지원 중, 삼성 스마트 티비 지원 예정




(네이버 AI)

사용자를 이해
사용자에게 감동 제공
사용자가 편리

이해
.정확하게 듣고 이해 (영상 사용)
.의도를 정확이 이해 (징면 인지)

감동
.자연스럽게 말하고(감정, 사투리)

편리
.영수증, 고지서 플레이릴스트 OCR
.얼굴인식
.Ai Call 음성전화 예약

Cloud AI API 제공

2019년 10월 21일 월요일

GDG Devfest 2019 메모

https://festa.io/events/559

발표자료 공유해주시면 감사할텐데..
이런 행사를 제공하는 것만으로도 감사.
다만 발표자 역량에 따라 발표내용이...






[Google Cloud 키노트]


시대의 흐름?
1. Dev & operation 
2. DevOps
3. Infrastructure as a code
4. SRE - site reliable engineering

Google cloud에서는 대규모의 여러 구글 서비스들을 지원 중 (Analytics, data, application ,infra 등-구글의 9-10억명 기반 서비스의 기반이기도 함.)

구글의 앱,서비스 제공 원칙
1. User를 먼저 생각
2. 기획안의 10배를 고민하고 생각함.
3. 공유할 수 있는 것들을 모두 공유하라


--------------------------------------------------------------------------------


[안드로이드 기반 AR 세계로의 초대]

안드로이드 7.0 이상
지원기기가 특정되어 있음


Android, unity, ios, unreal

Unity - all in one engine
AR core SDK for unitiy를 다운로드 받음.

Case study
- Life style 
 Streem사에 나온 VR 기반 가전 가이드 서비스
- Game
 Tend AR 사용자 얼굴로 가상의 물고기를 조정하는 펫 게임
- real estate
 Curate에서 가구를 배치할 수 있는 서비스
개발 및 학습 팁
- AR core API reference
- community : guthub, stack, AR experiments

--------------------------------------------------------------------------------


[Reactive Native와 Flutter를 고민하는 개발자분들에게]

Native platform, hybrid platform

Flutter skia ui 엔진이 모든 위젯을 그림
디바이스 platform, sdk 종속성 없음

React Native는 Platform 기본 컴포넌트를 활용하여 Platform, sdk 종속성이 있음

React Native는 bridge를 사용하고 플랫폼 종속적은 컴포넌트를 지원하여 이라 플랫폼용 코드 구현이 필요하기도 함.

Flutter도 스타일이 구분되어 있어 각 스타일을 다른 플랫폼에서  유지하기 위해서 분기처리 필요함.

모두 Platform specific code를 위해 platform code를 작성하여 호출함.

App size , 
Android hello world, Flutter 4.5M, Raect Native 7.1M
Flutter은 engine이 4M
React native js engine이 5M

iOS
Flutter 52M, React Native 24M
Flutter 30M, complied dart module 20M
Js core 15M

개발자 측면
.IDE 지원은 충분
.Hit reload 모두 지원

Dart는 인터프리터가 아닌 컴파일 언어, class 기반으로 중첩 코드 형태로 개발 해야함
JS - html을 활용하여 개발 가능

Architecture 
F BLoC 패턴,  페이지당 BLoC를 하나씩 개발 필요
R Flux 패턴, redux 데이터가 한 방향으로 이동, 함수형 프로그래밍에 최적화

3rd party library
F Package manager
R NPM
Reactive native의 라이브러리가 많고 flutter은 많지 않고 퀄리티도 부실함.

예제도 마찬가지
Flutter은 stack overflow보다 github 이슈에 있는 경우 많음

Flutter
- Camera library는 사용 못함
- Google 인증 library는 로그인 수준만 사용 가능
- video player도 성능 문제, frame drop
- web view도 성능 문제

--------------------------------------------------------------------------------



[Toy project가 쏘아올린 작은 공]

Pingcloud-cli
https://github.com/reoim/pingcloud-cli

개인 golang 공부를 사용하기 위해 시작
결국 뱅크샐러드 취업 및 다른 취업 기회 얻음

- 적절한 커뮤니티네 공유
- README.md 정리, 최대한 자세히 정리 아니면 문의 폭탄

실력이 증요(자격증, 공부, 컨퍼런스 발표 등), 실력을 알리는 것도 중요(블로그, 링크드인, 커뮤니티 등)

-----------------------------------------------------------------------------


[Declarative(<->imperative) UI patterns]

Declarative programming
필요한 것을 선언하여 사용 

Declarative UI patterns
화면에 필요한 컴포넌트를 선언하며 UI로 부터 구현을 분리?
사용할 컴포넌트를 선언(css선언하듯이)

왜?
화면 이동 시 개발자 버든을 줄여줌
게발자는 상태를 정의하면 되고 프레임워크에서 알아서 트랜지션을 처리
>앱의 기능 구현에 집중
>적은 코드량
>예측 가능한 코드

Flexibility
Data + UI code + behavior로 분리됨

Flutter에서는
UI = f(state)

Widget 기반으로 개발
- react에서 영향
- 현재 state로 보여줄 UI를 표시
- immutable 선언하여 수정 없이 사용

Flutter render tree
: 기존 뷰 같은 개념
Render Object
: 인스턴스화가 비용이 들어서 render tree가 업데이트 될 경우 재사용함 

React
- declarative, component base
- reconciliation(UI component tree를 저정하기 위해 On 알고리즘 사용) - flutter와 유사

Jetpack Compose
- Event handling을 명확히 > data input으로 event 주입

Swift UI
- view protocol 정의
- inheritance 보다는 compsition
- Modifier로 정의