Deview 2018 후기

작성일 | In

No Image

지난 1년간의 웨일 브라우저와 그 미래 - 김효님

Whale 현재 상황

  • Desktop : 1100만
  • Mobile : 42만
  • XWhale(Naver 앱 내부엔진) : 3000만
  • 전체 브라우저의 Whale 시장 점유율 : 1.4%

예전에 목표 했던 것

  • Move the Web Forward
    • Active-x, exe 제거
    • 플러그인 호환 모드 지원 중단.
    • 신한은행에 적용.
    • 아직도 남은 문제들이 있지만 현재 정부의 노력으로 변화가 생길 것 같은 기대.
  • 모두가 쉽게 쓰는 브라우저 웨일
    • 다양한 플랫폼
    • 참여 플랫폼 : 확장앱, 테마 스토어, 개발자 센터
  • 기술 / 보안
    • 성능 / 메모리 / 파워 절약
    • Safe Browsing

모두가 쉽게 쓰는 브라우저 웨일

  • 왜 Mobile Whale을 시작했는가?
    • Desktop Whale 사용자 만족도가 높아서 도전해보자.
  • 세상엔 많은 모바일 브라우저가 많다.
    • 많은 브라우저와 Whale은 무엇이 차별화 되었는가?
      • 스페이스
      • 사이드바 : 번역
      • 디자인 : 새탭, 배경 테마
      • 편의기능 : 다중 검색 엔진
      • 기술 : 웹번역, 각종 세이빙 기능
  • Mobile 특화 기능
    • 퀵바 : 사이트로 가장 빠르게 이동하는 방법
    • 퀵서치 : 가장 빠른 검색
    • 벨리 : 사이드뷰
    • 강력한 홈버튼
    • 심플 모드 : 보다 간결한 메인 UI
    • 뉴탭 : 사진 배경으로 감성을 전달
    • 퀵 네비게이션, 스마트 네비게이션, 고급 미디어

모든 기능을 다 넣자 VS 최대한 심플하게

  • 기능 == 버튼
  • 새로운 기능 == 추가 버튼
  • 버튼이 많아지면?
    • 복잡 == 모바일에 적합하지 않음.
    • 모바일은 심플해야하는데..
  • 결국엔?
    • 많은 고민 끝에 아래에 5개의 버튼 상단의 버튼 2개 구조

버튼(기능)을 뷰에서 제거하면 사용자가 기능을 찾아서 사용할까?

  • 아니다. 사용자들은 기능을 찾아서 사용하지 않는다.
  • 홈버튼은 찾아서 사용하겠지만 벨리버튼은 사용자가 찾아서 사용하지 않을 것 같다.
  • 그래서 벨리버튼을 살리고 홈버튼을 제거했다.

새탭의 감성은 시간 Resource 부족으로 포기

  • 안드로이드 : 데스크탑과 같은 크로미움 베이스
  • ios : 크로미움으로 개발 시작해볼까?
    • iOS 개발자가 Object C, C++를 잘 모르는 상황이 발생
      • 개발 속도가 원하는 만큼 나오지 않음.
    • 기존 버젼 폐기 및 신규 개발 : Swift
    • iOS, 안드로이드 완전한 단일 버전은 불가능
      • 다른 기술, 다른 감성
      • 엔진 개발 vs OS 제공 단일 엔진

우리가 스크랩하는 방법?

  • 카톡, 라인의 개인 대화방
  • 북마크
  • 메모장에 link와 설명
  • 페이스북 나만 보기 / 비공개
  • 전용앱(포켓, Keep)

솔루션이 많다는 얘기는 강력한 솔루션이 없다라는 것을 의미.

  • 브라우저에 붙여서 강력하게 만들자. 그래서 탄생한게 벨리(Belly)

하지만 사용자는 벨리가 뭔지 모른다?

  • 많은 설명이 필요하면 그만큼 직관적이지 않다는 것.
  • 좀 더 서비스를 직관적으로 이해하도록 해야함.

새로운 Whale

  • 메인 UI는 최대한 심플하게
    • 사용자에게 넓은 화면
    • 필요한 기능은 메뉴 안으로
    • 메뉴는 보다 계층적으로
  • 새탭 : 감성과 편리/정보를 같이 잡아주는 곳
  • Belly -> Scrapbook
    • Rebranding
    • 다시 보고 싶은 건 뭐든 담는 스크랩
    • 사용자들에게 제대로 전달 안된 이유가 이름이 아니길 바라면서.

데스크탑과 모바일

  • 데스크탑 웨일을 쓰는 이유
    • 캡쳐가 편해서, 새탭/디자인이 이뻐서
    • 모두 다르다.
  • 모바일 웨일을 쓰는 이유
    • 데스크탑처럼 다양하지 않고 단순하다.
    • 탄탄한 브라우저의 기본기가 필요하다.

앞으로의 Whale

  • Naver Tech Platform = Global Platform
  • Future Info Platform
    • 사물 브라우저

Question

  • Naver - Whale 관계?
    • 크롬과 구글 앱의 관계
      • Naver앱은 Naver를 사용하기 최적화된 앱
      • Whale앱은 브라우징하기 최적화된 앱
    • 앞으로 Naver와 Whale의 엔진이 동일하게 진행될 예정
  • Progressive Web 지원 여부?
    • 지원할 예정
  • 크로미움의 보안 이슈과 같은 내용은 어떻게 동기화 하고 있나?
    • 보안에 대한 issue는 cherrypick하여 rebase하여 동기화 중.
  • Global 전략을 위해 Opensource할 생각이 있는가?
    • Yes.
    • 오픈소스에는 준비할게 많아서 시간이 필요.

후기

  • 웨일 확장앱 플랫폼 소개.
    • 이런건 누가 만들까? 결국엔 개발자들.
    • 개발자들이 웨일가서 만들까? 크롬에 가서 만들까?
    • 생태계 조성이 필요해 보인다.
  • Whale - Conference 진행할 예정.
  • 왜 IT 대기업들은 Browser를 만드려고 할까?
    • 구글의 크롬, 애플의 사파리, 네이버의 웨일, 아마존, 바이두 등등.
    • 소비자를 Lock-in하는 효과를 얻지 않을까?
      • 하지만 생각보다 많은 리소스와 지식을 가진 개발자들이 필요해 보인다.

Slide

서비스 오리엔티드 블록체인을 위한 스케일링 문제 해결 - 이홍규님

후기

  • 블록체인의 기본적인 개념이 없어서.. 너무 어려움.
  • 나중에 블록체인 구조와 이론 책을 읽어보고 다음에 다시 읽어보자.

Slide

Javascript 배틀그라운드로부터 살아남기 - 박재성님

  • Marc Andreessen
    • 당시 웹은 정적이였다. DOM 인터렉션을 통해 다이내믹한 웹을 만들고자 하는 비전
    • Mocha -> Livescript -> JavaScript
    • MS의 JS : JScript
    • Action Script : Flash에서 사용
  • Ajax, Json의 등장.
  • Server-Side Javascript
    • Node.js
  • Modules
    • AMD(RequireJS), CommonJs
  • Package Manager
    • NPM
    • bouler

Framework 등장.

  • 1세대.
    • jQuery
    • Prototype
    • MooTools
  • 2세대
    • AngularJs
    • React
    • Vue

다양한 Browser의 등장.

  • Evergreen Browser
    • 과거와 달라진 브라우저 버전의 중요성
  • Vanilla 개발은 일반적이지 않음

오늘날의 JS 개발은?

  • 프레임워크 + 개발 도구
  • Library -> Framework
    • 크로스 브라우징 문제가 Native Level로 내려감
    • 따라서 그런 Library를 제거하는 모습
      • Github에서 jQuery를 제거하는 움직임

Babel

  • 2014년 발표.
  • ES6 -> ES5로 전환해줌.
    • 브라우저가 새 문법을 지원하지 않더라도 사용가능.
    • -> function 알아서 변환해줌.

2018년 동향

  • 버전 구분 중요성 감소
    • Evergreen 브라우저는 스펙을 빠르게 구현
  • 정적 타입 시스템(loose typing)
    • 버그 감소 (15% 감소 연구결과)
    • 효율적 코드작성
    • Language : Typescript, PureScript
    • Tools: Flow

Web Assembly

  • 어느 브라우저에서나 빠르게 실행되는 바이너리로 바꾸는 기술

React

  • 라이센스 이슈 -> MIT
  • 성능 개선.

Vue.js

  • 40K Github Stars
  • Nuxt.js
  • NativeScript - Vue
  • Ver 3.0

Angular

  • Ivy Renderer
  • Angular Elements

Web Components

  • All Major browsers Support

Polymer

  • Factory 메서드 통한 요소정의

브라우저 밖의 동향

  • NPM
    • 가장 많이 사용하고 모듈도 많음.
  • YARN
    • NPM의 전체 다운로드의 0.03%
    • 속도도 NPM만큼 빠르지 않음.
  • Webpack
    • 향상된 빌드 시간 : 60 ~ 98% 감소
    • mode property
      • development, production, none
    • Configuration Headache
    • Parcel과 같은 도구는 무설정 번들링

정리하자면?

  • 매몰비용 오류의 함정
    • 특정 도구에 투자한 노력이 많아지면, 나의 선택(도구)이 합리적이었다는 것을 자신이나 다른 사람들에게 설득하기 위해 노력.
  • Magpie Developer
    • 대체로 개발자들은 기존에 문제없이 사용하던 기술들을 뒤로하고, 새롭고 반짝 이는 것들에 너무 쉽게 관심을 빼앗긴다.
    • 모든 기술에는 장점과 단점이 있으니 파악부터하자.
  • 최신 업데이트 항상 정답인가?
    • 무엇이 정답이라 할 수 없다.
    • 각자의 사정은 모두 다르다.
    • 상황에 따라 적절한 정답을 찾아가는게 핵심.
  • 우리의 자세는?
    • Everything is amazing and nobody is happy
    • Expert로써 모든 플랫폼의 모든 것을 알아야 한다는 생각
    • 모든 것을 배우는 것이 해결책인가?
    • 단순하게 현재 작업에 필요한 것. 또는 끌리는 것에 집중
    • 적당한 밸런스
      • 적당한 호기심
      • 지속적인 꾸준함은 필요.

후기

  • Front 세계는 아직 내겐 너무 다양하고 많은 것 같다.
  • 토이 프로젝트로 하나만 시도해보는 것도 나쁘지 않을 것 같다.
  • 들어본 이름들이 있었지만 정확히 무슨 역할인지 몰랐는데 이번 기회에 알게 되었다.

Slide

네이버에서 사용되는 여러가지 Data Platform, 그리고 Mongo DB - 이덕현님

네이버에서의 Data Platform

  • 초기 모습 : 2 tier 구조
    • Web Server
    • RDBMS
      • MySQL, ORACLE
  • 서비스가 점점 커지면서 DB Query는 점점 복잡하고 무거워 짐
    • 빠른 응답을 보장하기 위해, DB앞에 Cache 사용
    • Redis, ARCUS
  • 지표를 저장하기에는 RDBMS는 공간과 비용에서 문제가 발생
    • 원활한 데이터 처리를 위해 Hadoop기반의 HBase 사용
  • Schema-less하고 Sharding과 secondary Index, Transaction처리가 가능한 Data Platform MongoDB도 지원하게 됨.

Schema-less

table A{
    userNumber int
    , userCellPhoneNumber char(13)
}
  • RDBMS : 1 row 당 17byte
  • MongoDB : 1 doc 당 46byte (_id 포함시 58Byte) Type 저장
  • RDBMS에 비해 disk READ/WRITE (IO) 측면에서 보면 더 안 좋을 수 있다.

Sharding

  • Scale up
    • 단일 서버 spec 증가
  • Scale out
    • 여러대의 서버로 데이터 분산
  • RDBMS는 응용에서 샤딩으로 Scale out 구현 할 수 있지만?
    • 확장성이 떨어지며
    • 개발 및 관리의 Overhead 발생
  • 이를 해결하기 위해 Db Level에서 Sharding을 제공하는 NoSQL
    • 개발 Cost 절감

Secondary Index

  • 단순 bigdata성 데이터는 Hbase를 사용하고 있음
    • HBase는 제품 자체에서 Secondary Index를 제공해주지 않음
    • Coprocessor, hIndex, Phoenix을 통해 secondary Index와 비슷하게 구현은 가능
    • 검색에 알맞게 데이터를 재 저장하는 방식

Transaction

  • MongoDB ~ 3.6까지
    • 1 Document (row Level Lock)
  • MongoDB 4.0부터
    • Multi Document Transaction

IDB DR

  • 서비스가 점점 중요해짐에 따라 IDC 이중화가 필요해짐
    • DR(Disaster Recovery) 요구됨.
  • Auto failover가 가능한 Data Platform
  • MongoDB 정책 상 홀수로 운영하여
    • 50% 넘는 생존율이 필수

Mongos 관리

  • Mongos(Router) 서버
  • Client 서버와 동일하게 있도록 가이드

L4와 getmore

  • Sharding에서의 L4(network switch)사용을 초기에는 권장했으나 getmore 이슈로 제거
  • getmore 함수 특성상 질의했던 Node에 다시 질의해야 하는 특성이 있음
    • L4를 사용할 경우 Round Robin을 통해 다시 Node에 질의하기 힘들기 때문에 L4를 제거.

Mongos <-> shard 커넥션

  • Connection 관리에 문제가 있음
    • Connection 관련 Parameter가 너무 낮다면?
      • 성능상 좋지않다.
    • 너무 높게 잡으면?
      • connection이 많아져 장애를 유발할 수 있다.

테스트 해보고 상황에 따라 적절하게 반영할 것.

Storage Engine

  • NoSQL Storage Engine 확인하기
  • eviction
    • Memory Buffer에서 오래된 data(dirty page) 삭제하는 작업
  • checkpoint
    • memory buffer와 disk 사이의 데이터 불일치를 해소하기 위해서 memoery -> disk로 data sync 하는 작업
  • compact
    • 주로 새벽시간에 스켸줄로 운영하고 있음.

후기

  • DBA 관점에서 Storage Engine까지 알게된 좋은 계기가 되었다.

Slide

쿠팡 서비스 Cloud Migration을 통해 배운 것들 - 양원석님

  • 100개의 Microservice
    • 목동 IDC, 분당 IDC
    • 서버 추가하기 위해서는 오랜 시간이 소요되는 단점.

문제점

  • 추가 및 확장 진행 시간
  • 확장하지 못해서 장애 발생

클라우드 이전 원칙

  • 확장성을 확보하기 위해 클라우드로 이전
  • 서비스 무중단
  • 고객에게 만족도에 영향을 주지 않는다.

Roman Ride

  • 데이터센터와 클라우드 동시운영
  • 리스크 최소화
  • 작은 변화
  • 빠른 Rollback

Dynamic Routing

  • DB Connection Manager
    • 공통 라이브러리 형태
    • Dynamic Config
    • 상태 모니터링과 조작을 위한 admin
    • 빠른 Rollback 지원
    • ZooKeepper를 사용하여 설정 관리
  • DB 이관 순서
    • Read DB 연결 이동
    • Write DB 연결 이동
  • API Gateway를 통한 트래픽 조절
    • 기존 API Gateway를 활용
  • 트래픽이 작고 영향도가 낮은 것부터 진행
  • 0 ~ 100% 까지 트래픽 Rame-up
  • 빠른 Rollback
  • instance size 이슈

Canary testing

  • Blue Green Deployment
  • docker로 배포
  • 10분간 테스트 진행
  • 기존 환경과 비교 테스트
  • Metric 정보 비교
    • CPU
    • Memory
    • Load
    • tomcat,requestCount, tomcat.currentThreadBusy
    • jvm.gc.fullgc.times, etc
  • Log 수집, 저장
    • ELK Stack
    • Object Storage
    • 압축, 라이프 사이클 적용.
      • 로그 종류 별로 Life cycle을 다르게 적용.
  • 분산된 Service의 현황은?
    • Pinpoint를 통해 볼 수 있다.

새로운 문제들

  • 전파되는 장애
    • 낮아지는 SLA
  • 예상치 못한 곳에서 발생하는 장애
    • Noisy Neighbor Problem
    • 공유 자원, 클라우드 서비스 제공 자원
    • 클라우드의 CPU 자동 패치로 인한 장애

마이크로서비스와 클라우드를 통해 배운 것.

모든 것에서 실패 가능하다.

  • Load Balancer
  • DB, Cache
  • Queue
    • 공용 자원은 되도록이면 사용하지 않는 방식으로
  • Object Storage
  • Block Storage
    • 비동기 방식
    • MemDisk
  • 위 문제를 어떻게 해결할까?
    • Retry
    • Fallback
    • Circuit Breaker
      • Hystrix
      • Valves

예측 못하는 것을 예측하라

  • Chaos Engineering
  • Chaos Monkey
  • 복구 기능 테스트
  • 약점 찾아내기

혼돈 속에 살기

  • 장애 복구 되었나요?
  • 1시간 내에 배포나 변경된 내역 확인 부탁드려요.
  • 복잡한 시스템 상황에서 상태 확인 어려움
  • 모든 서비스 관계를 알기 어려움
  • 안정 상태 찾기
    • 서비스의 건강도 측정
    • 주기 적극 활용
      • 트레픽이 높은 경우
      • 매달 1일 00시
      • 일요일 저녁
  • 변경 내역 확인 하기
    • 각 서비스의 상태
    • 배포 이력
    • 인프라 변경 이력
    • dns, security, auth

Auto Scaling

  • 요청에 따라 자동 조절
  • 이벤트 준비 시간 단축
  • Target Tracking Policy
  • 메트릭 정보(CPU, Request 등)
  • 폐기 가능(Disposability)
    • 빠른 시작과 빠른 정상 종료 보장
    • 시작이 오래걸리면 Auto Scaling이 트래픽을 따라가지 못함
    • 정상 종료가 오래 걸리면 새로운 배포시 리소스 문제 발생
    • 빠르게 늘리고 천천히 줄인다.
    • 민감하지 않게 잘 만들기

다른 장애로 부터 배우기

  • 사건 사고는 필연적인 것.
  • 대용량의 복잡한 분산 시스템
  • 끊임없는 변화
  • 지속적인 안정화

장애 리포트

  • 타임라인
    • Detection에 걸린 시간
    • 원인 찾는데 걸린 시간
    • 복구에 걸린 시간
  • 원인 찾기
    • 고객 관점에서 5 why 작성
  • 재발 방지
    • Poka-Yoke

Site Reliability Engineering (SRE)

  • Service Reliability를 책임
  • 복잡한 장애 상황에서 컨트롤 타워
  • 장애에 대한 지식 공유

  • 장애 재발 방지

  • 잘한 것
    • 작은 변화와 빠른 Rollback
    • 공통 배포 파이프라인 유지
    • 만든 사람이 운영하는 문화
    • 장애 관리 문화
  • 다르게 해보고 싶은 것
    • 복잡도 관리
    • 도커 오케스트레이션 적용
    • 클라우드 네이티브

후기

  • 클라우드 관련된 내용을 많이 들어봤지만 설명을 너무 잘해주셔서 많이 배우는 세션이였다.
  • 모니터링도 중요하지만 어떤 지표를 가지고 어떻게 모니터링할 것인가 하는 부분에서 많이 배운거 같다.
  • 모든 경험하신게 클라우드 네이티브 자바 책에 녹아 있다니 시간이 된다면 읽어봐야겠다.

Slide

0%