세션에 참가해서 필요한 내용이나 기억에 남길 것을 메모함. 자세한 내용은 발표자료 참고.
[Multi-Tenancy Kubernetes on Bare-Metal Servers (네이버 컨테이너 클러스터)]
이팀은
. Container oriented : 베어메탈, 컨테이너 오케스트레이션
. Cost efficient : 범용서버 직접 구축
. Help containerize : 컨테이너 클러스트 + 레지스트리, 모니터/로깅, 교육,가이드 등 컨테이너화를 촉진하는 활동
효율적인 컨테이너 적용하려고 노력함 > Multi-Tenancy Kubernetes 로 불림
= 하나의 Kubernetes를 namespace로 나눠서 제공하는 것
Pros
. 모든 사용자가 Kubernetes자체 서버를 보유할 필요 없음
. 모든 사용자를 의한 여유 리소스를 보유할 필요 없음.
. 모든 사용자가 직접 Kubernetes를 운영할 필요 없음
. 모든 사용자를 의한 여유 리소스를 보유할 필요 없음.
. 모든 사용자가 직접 Kubernetes를 운영할 필요 없음
Cons
. 신뢰성 있는 유저 필요
. 사용자가 Kubernetes의 모든 기능을 사용 할 수 없음
. Kubernetes가 매우 커지고 사용자도 많아서 운영하기 힘듬
. 사용자가 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에서 적용한 사례를 말씀하심.
만드신 프레임워크의 장점에 대해서 소개하심
함께 slack이나 nhn, kakao에서 적용한 사례를 말씀하심.
댓글 없음:
댓글 쓰기