[2018.10.11~12] Deview 2018

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