ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • [2018.10.11~12] Deview 2018
    후기/세미나 2018. 10. 22. 00:07

      작년에 이어 올해도 데뷰를 다녀왔다. 작년엔 하루 밖에 못갔지만 이번에는 사내신청과 일반신청 각각 하루씩 당첨되어 이틀 모두 갈 수 있었다. 네이버와 계열사들 그리고 다른 회사들의 기술 노하우들을 무료로 들을 수 있는 귀한 시간이었다. (이틀이나 회사를 빠지는게 좀 그래서 금요일은 컨퍼런스 끝나고 저녁 6시에 출근하긴 했지만...)

      동시에 4개의 세션이 이틀간 진행되니 정말 다양한 분야의 기술들을 접할 수 있었다. 관심있고 업무와 관련된 것부터 시작해서 React Native나 Druid, 인공지능 챗봇 등 생소하고 안해 본 기술들까지 들을 수 있었다.

      전에 검색팀에서 검색서비스를 만들었다 보니 이번에 검색과 관련된 세션들이 눈에 많이 들어왔다. Fashion Visual Search, 네이버 검색과 개인화, Search Reliability Engineering (부제: 지진에도 흔들리지 않는 네이버 검색시스템) 등을 흥미롭게 들었다. 네이버 검색에 대해 불만을 갖는 사람들이 종종 있긴 하지만 그래도 네이버는 검색을 통해 세상에 알린 회사이고 검색을 빼놓고는 이야기 할 수 없을 것 같다. 지금도 Search & Clova로 분리할 만큼 검색에 대한 품질과 사용자 경험을 높이려고 노력 하는 것을 알 수 있었다.



      전체 타임 테이블은 아래와 같다. (그냥 복붙 하다 보니 보기가 좋지는 않다.)

      (출처: Deview 2018 홈페이지)

    Day 1

    • 10:00 ~ 10:40키노트 송창현 / NAVER LABS

    • 11:00 ~ 11:45글자읽는 AI: 밑바닥부터 외국어 정복까지이활석 / NAVER / Clova VisionReact Native: 웹 개발자가 한 달 만에 앱 출시하기이성민 / SNOW해커의 관점에서 바라보기박세준 / Theori / CEO & Researcher지난 1년간의 웨일 브라우저와 그 미래 (부제: 제품 매니저가 들려주는 생생한 기술/제품 이야기)김효 / NAVER / Whale / PO

    • 12:00 ~ 12:45모바일 환경에서 실시간 Portrait Segmentation 구현하기서석준 / 하이퍼커넥트 / 머신러닝 엔지니어책에서는 맛볼 수 없는 HTML5 Canvas 이야기 (부제: Web Worker를 이용해 캔버스 성능을 극대화하기)방진호 / 삼성전자 / Web Platform Developer서비스 오리엔티드 블록체인을 위한 스케일링 문제 해결이홍규 / 언체인 / 대표Learn how Material Design makes it easier and faster to build apps without compromising qualityJonathan Chung / Google / UX Lead

    • 12:45 ~ 14:00LUNCH

    • 14:00 ~ 14:45LINE x NAVER 개발 보안 취약점 이야기허규, 이명재 / NAVERJavaScript 배틀그라운드로부터 살아남기박재성 / NAVER / PaaS게임 엔진을 활용한 자율 주행 시뮬레이션정재원 / Baidu USAModern C++ 무조건 써야해?신미영 / NAVER / Whale

    • 15:00 ~ 15:45파파고 서비스 2년의 경험김준석 / NAVER / PAPAGO / PO네이버에서 사용되는 여러가지 Data Platform, 그리고 MongoDB이덕현 / NAVER Business Platform / Data Platform병리 AI 제품 개발을 위한 데이터 관리 및 좌충우돌 삽질기이경원 / 루닛 / 소프트웨어개발 / 백엔드 엔지니어WebAppFramework, XWhale 개발기조진철 / NAVER / Whale

    • 16:00 ~ 16:45쿠팡 서비스 Cloud Migration을 통해 배운 것들양원석 / Coupang / Principal Software Engineer웹 성능 최적화에 필요한 브라우저의 모든 것이형욱 / NAVER / Whale모바일 키보드, 스마트보드에 AI 적용하기이승윤 / NAVER / SmartBoardprintf("Hello, AR"); //세상을 바꾸는 새로운 눈방현우 / 어반베이스 / CTO

    Day 2

    • 09:00 ~ 10:00REGISTER

    • 10:00 ~ 10:45인공지능이 인공지능 챗봇을 만든다이재원 / NAVER / Company AI이미지를 이해하는 이미지검색: 텍스트기반 이미지검색에 CNN 이용하기조근희 / NAVER / 통합검색Clova 화자인식이봉진 / NAVER / SpeechAI 칩 개발에 사용되는 엔지니어링백준호 / 퓨리오사에이아이

    • 11:00 ~ 11:45C3, 데이터 처리에서 서빙까지 가능한 하둡 클러스터남경완 / NAVER / System&Solution누구나 만드는 내 목소리 합성기 (부제: 그게 정말 되나요?)이봉준 / NAVER / VoiceTensorRT를 활용한 딥러닝 Inference 최적화한재근 / 엔비디아컴퓨터 비전을 이용한 실내 지도 자동 업데이트 방법: 딥러닝을 통한 POI 변화 탐지정성균, Jérome Revaud / NAVER LABS

    • 12:00 ~ 12:45Fashion Visual Search최승권, Jon Almazan / NAVER / Clova Vision기계독해 QA: 검색인가, NLP인가?서민준 / NAVER / Clova ML대형 컨테이너 클러스터에서의 고가용성 Network Load Balancing: Maglev Hashing Scheduler in IPVS, Linux Kernel송인주 / NAVER / Container Cluster PlatformDeep Learning to help student’s Deep Learning김병학 / Udacity / AI Team / Senior AI Research Scientist

    • 12:45 ~ 14:00LUNCH

    • 14:00 ~ 14:45Ai Serving Platform: 하루 수 억 건의 인퍼런스를 처리하기 위한 고군분투기현동석, 양은숙 / NAVER / System&Solution네이버 검색과 개인화최재걸 / NAVER / 통합검색Fast & Accurate Data Annotation Pipeline for AI applications이정권 / Superb AI로봇이 현실 세계에 대해 학습하도록 만들기Tomi Silander / NAVER LABS EUROPE

    • 15:00 ~ 15:45Druid로 쉽고 빠르게 빅데이터 분석하기송은혜 / NAVER / 콘텐츠소비통계NSML: 머신러닝 플랫폼 서비스하기 & 모델 튜닝 자동화하기김민규, 김진웅 / NAVER / Clova NSMLWikipedia-scale Q&AJulien Perez / NAVER LABS EUROPEPapago Internals: 모델분석과 응용기술 개발신중휘, 정권우, 김재명 / NAVER / Papago

    • 16:00 ~ 16:45Search Reliability Engineering (부제: 지진에도 흔들리지 않는 네이버 검색시스템)김재헌, 손주식 / NAVER / System&SolutionNAVER 광고 deep click prediction: 모델링부터 서빙까지김윤중, 임지훈 / NAVER / 비즈플랫폼개발스트림 저장소 최적화 이야기: 아파치 드루이드로부터 얻은 교훈손지훈 / Imply / 백엔드 / 소프트웨어 엔지니어QANet: Towards Efficient and Human-Level Reading Comprehension on SQuADAdams Wei Yu / Carnegie Mellon University


      아래는 행사 사진들이다.




      아래는 들은 세션들에 대한 필기이다.

    Day 1

    Keynote (10:00, 송창현 CTO)

    Ambient Intelligence

    • understanding : 스마트렌즈
    • anticipatory
    • natural UX : Papago
    • 검색
      • 텍스트
      • 이미지 음성/대화 주변정보 추천
      • 공간검색
    • 그린닷
      • 연결
      • 발견
      • 위치/이동 Naver 지도 API 무제한 제공 xDM platform: 통합 지도 플랫폼
      • WAYFINDING: 실내/실외 측위, 이해, 연결 기술 Never Stop Dreaming!

    React Native: 웹 개발자가 한 달 만에 앱 출시하기 (11:00, 이성민, N Studio SNOW, Track B)

    1. React Native 선택의 이유
    • 페이스북, 인스타그램, 바이두, 텐센트 등의 기업들이 사용 중
    • 선택의 결과
      • 투입한 개발 리소스 낮음
      • 플랫폼간 공유 코드 높음
    1. RN 완벽한 이해
    • Virtual Dom
    • Threading Structure
      • Bridge를 통한 스레드들 간의 통신
    • Native -> Bridge -> Javascript -> Bridge -> Native React Native의 발전 방향
      • Facebook에서 내부 수정 중
    1. Cake 프로젝트에서 얻은 노하우 & 팁 30가지
    • react-native-cli로 시작하는 것을 추천
    • Optional Chaining: Null Safety Coding 가능
    • Flow: 정적 타입 체크 가능
      • 실시간 검사
      • 자동완성
      • 빠른 함수 이동
    • 성능을 고려한 정적 이미지 사용
    • 성능을 고려한 리모트 이미지 사용
    • JavaScriptCore의 동작 오류 (1/2)
    • 플랫폼 별 컴포넌트 스타일링
    • 효율적인 애니메이션 사용 (1/2)
    • 무거운 코드의 올바른 실행 시점
    • 효율적인 레퍼런스 사용
    • 앱 크기에 대한 걱정은 오해

    서비스 오리엔티드 블록체인을 위한 스케일링 문제 해결 (12:00, 이홍규, Unchain, Track C)

    1. LINE이 바라보는 blockchain platform
    • history
      • 비트코인, 이더리움
      • platform으로 동작
      • 킬러 서비스
    • 현재
      • 이더리움 4300만개의 계좌가 존재 (10/5)
      • dApp
      • 대중적인 플랫폼은 아님
      • 얼리어답터도 dApp 서비스를 사용하기 어려움
    • 방향성
      • 대중이 쉽게 접하고 사용할 수 있는 서비스 구현
    • 서비스는 어떤 블록체인이 필요한가?
      • 사용자가 안심하고 쉽게 사용할 수 있고
        • private key 안심 금고
        • login, blockchain 속도 등 동일한 UX
        • -> Private Blockchain & 자체 dApp
      • dApp을 만들기 쉽고 사용자들에게 쉽게 소개할 수 있고
        • smart contract 안정성
        • 개발 편의성
        • -> Blcokchain as a Service (API)
      • 많은 서비스들이 사용하여 빠르게 확장해 나갈 수 있는
        • scale out ???
    1. 스케일링 문제를 해결하기 위한 시도들
    • 시도들
      • Layer 2
        • 라이덴 네트워크
      • Layer 1
        • 합의알고리즘 개선
        • 샤딩
    • 라이덴 네트워크
      • 오프체인 확장 솔루션
      • 당사자들 간에 비넙ㄴ한 소액 결제가 많을 때 효율적
      • Multi-hop 지원해서 다자간 거래 가능
    • 플라즈마
      • 메인 체인 위에 올라가는 차일드 체인 (=플라즈마 체인)
      • 장점
        • 빠른 TPS
        • 수수료 절감
    • 플라즈마 캐시
      • 이슈 - 서로 상충된느 증명 비용과 수수료 해결
        • 비싼 exit 신청
        • 수수료
    • 샤딩
      • 이슈
        • Merge 작업이 필요
        • 단일 샤드에서 51% 어택을 통해 악의적인 샤드를 만들 수 있음
    1. 현재 제안/구현되고 있는 방법
    • 라이덴 네트워크 프로젝트
    • 사이드체인 프로젝트
      • 룸네트워크
    • 인터체인 프로젝트
      • WAN chain
      • 코스모스
    • 샤딩
      • 쿼크체인
        • 테스트넷 릴리즈 (테스트넷 TPS 14,000 이상)
      • 질리카
        • 테스트넷 v2.0 출시 (테스트넷 TPS 2,828)
        • POW 사용
    • 프로젝트의 한계
      • 사이드체인
        • 이더리움을 root chain으로 사용하여 빠른 confirmation 어려움
      • 인터체인 / 샤딩
        • 테스트넷까지 구현되어 있음
        • 아직 dApp이 없음
    1. LINE blockchain에서의 접근법
    • LINEAR Network: root-leaf chain
      • Scale out으로 많은 서비스 수용
      • Leaf chain 사이의 가치/정보의 상호교환 지원
      • 안정적인 블록체인 플랫폼 환경 제공
      • 서비스가 필요로 하는 기능에 집중한 블록체인 픞랫폼 제공
      • Phase 1, 2
    • LINEAR Relayer
      • Relayer
        • 담합 방지를 위한 분산 구성
        • Kafka를 활용한 Relayer의 안정적인 failover 구조 지원
      • Hashed timelock contract
        • transaction이 중간에 강탈되거나 변조되지 않도록 함
      • Exchange Transaction ID
      • 이종 체인간 송금 Process
      • 동작 시간
        • confirmation time은 2초 이내
        • fetch는 30초마다
        • 체인간 송금은 5분 이내에 동작
        • 전체 동작의 timelock은 10분을 고려
    • LINEAR Porotocol
      • 더 쉬운 확장
      • 더 빠른 속도
      • 더 안전한 교환
    • Milestone
      • LINEAR Netowrk: Relayer
        • 2018.12 출시 후 서비스 연동 예정
      • LINK Chain public MainNet
        • 2019년 상반기 출시 예정
      • LINEAR Network Protocol
        • 2019년 출시 및 public 적용 예정

    네이버에서 사용되는 여러가지 Data Platform, 그리고 MongoDB (15:00, 유덕현, NBP, Track B)

    1. NAVER에서의 Data Platform
    • 초창기
      • 2 tier
      • DB 앞에 캐시 추가
      • 원활한 데이터 처리를 위해 HBase 사용
    1. MongoDB가 어떻게 대안이 되고 있는가?
    • 지원 Coverage 확대
      • schemaless, sharding, secondary index, transaction 처리 등등이 필요함
    • Schema-less
      • _id (12byte)와 컬럼 이름도 저장해야해서 더 많은 용량이 필요함 -> 성능상 취약해 질 수 있음
      • 서비스마다 사전에 데이터에 대한 구조나 정의를 하지 않아도 되는 장점이 있음
    • Sharding
      • DB 측면에서 가능
    • Secondary Index
    • Transaction
    • JSON 지원
    • IDC DR (IDC Disaster Recovery)
    1. 네이버에서 MongoDB를 사용하면서 겪은 에피소드들
    • Mongos 관리
    • L4와 getmore
    • Mongos <-> shard 커넥션
      • 환경에 맞게 connection timout, min, max 세팅해야함
    • Node.js driver
    • Storage Engine
      • WiredTiger만 사용 중
      • eviction problem
      • Checkpoint
    • Background Index
      • 짧은 주기로 인덱스를 만들고 멈추고를 반복
      • 서비스 영향이 있을 수 있으니 서비스가 한가할 때 수행
    • Compact: Maintanance 기간에만 수행
    • Balancer
    • Clustered Index: 해당 key 값 기준으로 실제 데이터가 정렬되어 있음
    • Unique Index
      • index가 로컬이라 각 샤드별로만 유니크함
    • 개인정보 - 전자금융거래법
      • MongoDB 3.6 버전의 authenticationRestrictions 기능 사용 중
    1. 개인적으로 바라보는 MongoDB의 장단점 그리고 전망 (vs RDBMS)
    • 과연 NoSQL인가?
    • 성능과 안정성
    • 전망
    • MongoDB for Naver Cloud Platform

    쿠팡 서비스 Cloud Migration을 통해 배운 것들 (16:00, 양원석, Coupang, Track A)

    1. 클라우드 이전 계획 및 선행 프로젝트
    • 클라우드 이전 원칙
      • Availability, Scalability, Performance
    • 클라우드 이전 전략
      • Roman Riding
        • 데이터센터와 클라우드 동시 운영
        • 리스크 최소화
    • 클라우드 이전 준비
      • Dynamic Routing
        • DB Connetion Manager
        • API Gatway를 통한 트래픽 조절
        • Microservice cloude 이관
      • Canary Testing
        • Blue Green Deployment
          • 무중단 배포
          • 빠른 Rollback 지원
      • Log 수집, 저장
        • ELK Stack
    • 새로운 문제들
      • 전파되는 장애
      • 예상치 못한 곳에서 발생하는 장애
    • 마이크로서비스와 클라우드를 통해 배운 것
      • 모든 것에서 실패 가능
        • 모든 것을 리소스로 생각하고 대비 필요
          • Retry
          • Fallback
          • Circuit Breaker
        • 예측 못하는 것을 예측하라
          • Fault Injection Testing
          • Chaos Monky
      • 혼돈 속에 살기
        • 안정 상태 찾기
        • 변경 내역 찾기
        • Auto Scaling
          • 조건: 폐기 가능
      • 다른 장애로부터 배우기
        • 사건 사고는 필연적인 것
        • 장애 리포트
        • SRE (Site Reliability Engineering) 정리


    Day 2

    인공지능이 인공지능 챗봇을 만든다 (10:00, 이재원, Naver, Track A)

    1. 스스로 언어를 배우는 인공지능 만들기 : AutoML과 NLP/Chatbot 개념 소개
    2. 우리 챗봇의 말하기 실력은 몇 점? : Chatbot 자동 평가 프로세스
    • 인공지능이 언어를 배우는 과정
    • AutoML
      • 진화된 인공지능 프로그램
      • Data Corpus -> Data Cleansing -> Feature Selection, Preprocessing, Construction -> Model Selection -> Parameter Optimization -> Model Validations
    1. 말뭉치 줄게, 챗봇 다오 : Chatbot 자동학습 프레임워크
    • 말뭉치는 좋은 선생님
    • 챗봇의 변신은 무죄!
    • AutoML을 도와줄 Framework
    1. 인공지능 챗봇의 말하기 실력은?
    • 성능 평가 기준
      • 적절한, 친근한, 명확한, 자연스러운 답변
      • 정확한 의도 파악
      • 노이즈에 강건
      • 재사용 가능 여부
    1. 클러스터링, 그리고 하이퍼파리미터 튜닝
    • What is Clustering?
      • 데이터에 대한 정보 없이 주어진 데이터의 클러스터를 결정
    1. Closing Comments
    • 성능: IQ x 노력^2 이라고 생각

    컴퓨터 비전을 이용한 실내 지도 자동 업데이트 방법: 딥러닝을 통한 POI 변화 탐지 (11:00, 정성균 NAVER LABS, Jérome Revaud NAVER LABS EUROPE, Track D)

    1. Self-Updating Maps
    • Waht is a Point of Interest (POI)?
    • SSIM (scalable semantic indoor mapping)
      • Mapping, Service, POI Analysis
    1. Review of Prior work
    • Change detection
    1. System overview
    • POI Change Detection
    1. POI change detection
    • Working with image pairs
      • How to make pairs?
        • use semantic content (e.g. tag shops)
      • Geometry-based image pairing
        • computing geometric overlap between two images
        • Intersection of Union
    • Proposed approach
    • Triplet sampling
    • Training procedure
      • sample a triplet
      • If it has a negative loss, take a small step (back propagation)
      • Repeat
    • Syntehtic examples
      • What defines a POI's identity?
      • We should make the network specifically focus on signage
      • Adding synthetic iages = a simple way to influence the training
    • Neuron activations
    • Result aggregation
      • Overall procedure at test time
        • Make image pairs
        • Pairs scoring
        • Spatial aggregation
    1. Experimental Results
    • Datasets
      • Hanam Starfield (2017 Spring / 2017 Fall)
        • 5 story building including 323 POIs
        • 15 POIs changes
      • COEX (2018 June / 2018 Aug)
        • 250 POIS on B1 floor (commercial area)
        • 2 POIs changes
    • Evaluation emtrics
      • Standard mAP (= mean-Average-Precision)
      • PCD AP (= POI Change Detection AP)

    Fashion Visual Search (11:00, 최승권 NAVER / Clova Vision, Jon AlmazanNAVER LABS EUROPE, Track A)

    1. Background
    • Visual Search (ex. 네이버 스마트 렌즈)
    1. System Essentials
    • 구성요소
      • Data
      • Feature Extractor
      • Search System
    1. 패션 이미지 검색을 담당하다
    • 문제
      • 카테고리 혼동
      • 배경: 얼굴, 배경색 등
      • 색, 패턴
    • Stragety
      • 색인 시간 줄이기
        • DB 이미지 개수 줄이기: 2억 -> 4000만
      • 문제를 나눠서 해결하자
        • 모델 카테고리 세분화: Depth-2, 3
        • 디텍터: 카테고리 혼동 해결, 브랜드 탐지
        • 앙상블
      • 변화에 유연한 검색 시스템
        • Search System: ANNS 방식 포기
        • 대안: Inverted Index
        • 지속적인 품질 개선
        • 실수 만회
        • 서비스 스펙 변경에 빠른 대응
      • AI 서비스를 한다는 것은 -> Trial and Error
    • Attribute Collection Search System
      • -> 속성 더하여 검색!
      • -> 속성을 '단어'로 정의 할 수 있을까?
      • Feature Vector 조작이 가능할까? -> 안됨
    • Fashion Image Retrieval
    • Attribute manipulation: a common space
    1. Result
    • DeepFashion dataset

    네이버 검색과 개인화 (13:00, 최재걸, 네이버/통감검색, Track B)

    1. 검색에 개인화가 필요한가?
    • Personalized Search
      • Privacy : 개인화가 익숙한 시대
      • Filter Bubble: 뭔가 빠트리고 보는 건 아닌가...
        • ex. 스포츠 뉴스를 보면 다른 모든 뉴스를 날려버리는 현상
      • 구글 10%, 빙 15% 적용 중
    • 검색이 이루고자 하는 목적
      • 검색의도에 맞는 검색결과를 제공한다.
    • 최대 다수의 최대 만족
      • 최대한 많은 사람을 만족 시킬 수 있는 결과물 구성
    1. 개인화가 필요한 경우
    • 확신할 수 있는 수준의 방법이 필요하다!
      • Click Entropy
      • User Entropy
      • Potential curve for personalization
      • Precision이 80%넘지 못함
    • 3-Level Query Ambiguity
      • Query(디오) - Entity(가수 디오) - Property(가수 디오 사진) - Document(전신 가수 디오 사진)
      • Precision 95% +
    • 개인 맞춤 검색을 위한 선결 조건
      • 개인의 검색 의도를 잘 파악할 수 있는가?
    1. 개인의 검색 의도 파악
    • 검색의도는 사용자의 마음속에...
    • 사람의 기억은 장기 기억과 단기기억으로 나뉜다.
    • HuMM (Human Memory Mirror)
      • 사람이ㅡ 기억 방식을 모방하여 3개의 계층으로 구성
      • Immediate - Working - Long Term memory
    • 적절한 유저에게 개인화 적용
    • 개인의 의도 파악 - 어려운 점
      • 데이터가 Sparse 하다.
    1. 개인화 검색 확장
    • 개인화 검색 확장
      • Precision을 담보하는 방향으로 확장
      • 비슷한 유형의 다른 유저의 Long Term 메모리를 근거로 사용

    Druid로 쉽고 빠르게 빅데이터 분석하기 (15:00, 송은혜, Naver, Track A)

    1. 데이터 분석의 필요성
    • 서비스에 제공하여 소비자 만족도 올림
    1. Druid, 그게 뭔데?
    • 컬럼기반 분산저장소
    • Druid vs. Elasticsearch vs. Kudu
      • 요구사항
        • 임의의 조건 조합 분석 (원본 < 조합)
        • 데이터 유효기간 없음 (데이터 감소 X)
        • 내부 분석 환경
        • 개발/운영비용 최소화 (관리 인원 5명)
      • 후보 선정 이유
        • Druid(v0.10.0): 저장/질의기능 제공, 빠른 필터 처리
        • Elasticsearch(v2.3): 기존 사용 플랫폼, 저장/질의기능 제공
        • Kudu(v1.4): 가장 적은 저장공간, 빠른 조회기능, 질의기능 미제공(질의엔진 필요)
    1. Druid로 분석하기 - 기본편
    • Imply-UI: 유료
    • Grafana: Druid plugin을 설치하여 연동 가능, DSL 질의 방식 이해 필요
    • Superset: 기본 제공 그래프 가장 많음, 세세한 권한관리 기능, 표현 자유도가 높음
    • Metabase: Application 방식, 깔끔한 UI, 그래프의 세부적인 설정 불가
    1. Druid 성능 향상시키기 - 고급편
    • Service Architecture
    • 질의성능 향상시키기
      • TopN 결과 안정성 향상
      • TopN 쿼리 확장
        • Segment Data -> Aggregation -> Result 생성
      • Spark-Druid Connector
        • Locality
        • Segment Partition pruning
        • Using Druid Filter
    • 저장성능 향상시키기
      • Hash Partition 확장
      • Druid Spark Batch

    Search Reliability Engineering (부제: 지진에도 흔들리지 않는 네이버 검색시스템) (16:00, 김재헌 & 손주식 NAVER / System&Solution, Track A)

    1. 들어가며
    • 네이버 검색시스템의 목표
      • 많은 사용자가 동시에 검색해도 서비스에 문제가 없어야 한다
      • 1초 안에 검색 결과가 나와야 한다
    • 네이버 검색시스템의 현재 상황
      • 수백 개의 검색 서비스
      • 수만 대의 서버 장비
      • 하루 수십억 건의 검색 요청
      • 수백억 건의 컨텐츠
    • SRE: Site Reliability Engineering
      • 글로벌 스케일의 서비스를 제공하면서 어떻게 하면 시스템의 신뢰성을 보장할지 고민하는 기술 분야이자 방법론, 문화
    • Search Reliability Engineer
    1. 네이버 검색시스템의 SRE
    • 효율적인 정보 체계 도입
      • 서비스 ID 발급 -> 구조 가시화 -> 성능/비용 측정
    • 가용량 지표 개발
    • 가용량 경보 시스템 운영
    • 검색시스템 통합 대시보드 개발
    • 자동 경보 분석
      • 그래프 모양을 보고 판단 가능한 경우: 지표의 방향을 부호로 인코딩 (ex. 기울기 1: 급하강, 7: 급상승)
    • 2가지 철학
      • 문제 분석 관점: Macro Analysis. 거시적 관점
      • 장애관제 방식: Blackbox Monitoring
    1. 실제 사례 소개
    • 요일 별 트래픽 패턴
      • 주중 / 주말에 일정한 패턴을 보임
    • 스포츠 경기나 특정 이벤트에 QPS가 튐
    1. Search Reliability Engineer
    • 엔지니어와 시스템
      • 새벽, 주말의 장애관제
        • IC (Incident Commander): 전체 Incident 통제의 역할
        • Scribe: 서기, 필경사 역할
        • IC와 Scribe가 돌아가며 담당
    • SRE 문화
      • 비난 없는 사후분석: 사실에 기반하여 분석
      • SRE 홍보 활동: 글쓰기, 정기 Report 발행, 교육 등 SRE 문화 전파


    댓글

Designed by Tistory.