DEVIEW 2018 -- Day 2 후기

2018, Oct 12    

DEVIEW 2018 — Day 2

1. 이미지를 이해하는 이미지검색: 텍스트기반 이미지검색에 CNN 이용하기

네이버의 이미지 검색 품질 향상에 대하여.

CNN: Convolutional Neural Network
CNN: 분류를 잘 하기 위해

Relevance Feedback: 사용자의 피드백을 검색 결과에 반영, 검색품질 향상

전통적인 검색기법은 한계가 있다.
개선 => 사람들이 왜 이미지 검색을 하는가?
이미지 이해를 위한 내용 분석이 필요: 검색 결과로 나타난 결과가 이미지가 아닌, 이미지와 함께 포함된 문서의 내용인 경우라면? 그것은 사용자의 요구와 다를 것.

n개의 대표 이미지로 m개의 후보 이미지를 re-ranking
=> 유사한 이미지끼리 묶어준다, 질의와 가장 가까운 이미지를 더 상단에 노출.

발표자료: SlideShare

2. C3, 데이터 처리에서 서빙까지 가능한 하둡 클러스터

Hadoop, Docker 경험이 없어서 전반적으로 무슨 말인지 거의 이해를 못했다.

발표자료: SlideShare

3. 대형 컨테이너 클러스터에서의 고가용성 Network Load Balancing: Maglev Hashing Scheduler in IPVS, Linux Kernel

발표자가 직접 구현한 IPVS Maglev Hashing Scheduler가 수 개월의 코드 리뷰와 수정 끝에 리눅스 커널 4.18에 포함된 이야기. load balancing까지 건드려 본 경험이 없어 이 세션도 상당 부분 이해하기 어려웠다.

발표자료: SlideShare

4. 네이버 검색과 개인화

같은 질의어에 대해 개인화를 통해 다른 결과, 혹은 같은 결과에서 어떤 것을 상위로 둘 것인지를 다르게 한다.
ex) ‘펜타곤’이라는 단어 검색 —> A) 아이돌 가수 펜타곤 B) 미국 국방성 펜타곤

구글은 10%, BING은 15% 정도가 개인화된 검색 결과, 현재 네이버는 1% 정도.

개인화된 결과를 제공하기 위해서는 precision이 확실하게 높아야 한다. 80% 정도로는 못 쓴다.

개인화는 3-Level Query Ambiguity를 기반으로 한다.
1) Entity Level: 같은 질의어에 대해 어떤 것을 지칭하는지 (가수 펜타곤? 미 국방성 펜타곤?)
2) Property Level: 해당 entity에 대한 어떤 것을 찾고자 하는 것인지 (‘전국 날씨’ 검색 —> 날씨 뉴스와 날씨 동영상 중 어떤 것을 상단에 보여줘야 하는가)
3) Document Level(Not Yet; precision 약 70%): entity, property보다 더 상세한 개념. (ex. 정해인 미소짓는 사진)

사람의 기억 방식을 모방한 3단계의 HuMM(Human Memory Mirror) 개념.
Immediate Memory —> Working Memory —> Long Term Memory

개인화 적용 효과: 클릭 비율은 증가, 스크롤은 감소

개인의도 파악의 어려운 점: 데이터가 sparse하다.

2019년 도입 예정인 개인화: 검색의 요구를 좀 더 반영한다.
ex) ‘지드래곤’ 검색
—> 인물 프로필을 상단에 or 대부분을 인물 사진만(인스타그램 쓰는 것처럼) or 영상만(기존의 네이버로서는 매우 혁신적인 방법을 구상 중)

발표자료: SlideShare

6. Search Reliability Engineering (부제: 지진에도 흔들리지 않는 네이버 검색시스템)

네이버 검색 시스템의 목표:
대용량 처리(High Throughput) —> 많은 사용자가 동시에 검색을 요청해도 문제 없어야 한다.
짧은 대기시간(Low Latency) —> 검색을 요청하면 1초 안에는 결과가 나와야 한다.
=> 이 시점에서, 학교 수업 때 얼핏 들었던 0.1초의 latency가 Amazon의 매출에 미치는 영향이 다시금 떠올랐다.

결국은 장애가 발생하지 않도록 예방하는 것이 가장 중요하다.

SRE: Site Reliability Engineering.
Search Reliability Engineering은 네이버 검색시스템에서 바라보는 SRE. “고비용 사후처리보다는 저비용 사전예방”
=> SRE라는 단어를 처음 들어봤는데, 이런 책이 따로 있을 정도로 전문적인 영역인 것 같다. 그러나 아직은 아무도 해보지 않은 분야라고 할 수 있고, 주변에서 참고할만한 사례가 적다고 한다.

Availability가 99.998%여도 1년으로 치면 10분의 장애인데, 이 정도 수치는 네이버에게 “대재앙”

SRE는 시스템이 안정적으로 돌아가게 만들기 위한 ‘모든’ 활동이다.

Incident(예기치 않았던 이벤트나 사건) 처리 후 많은 엔지니어들이 의욕・집중력 저하 등 각종 문제를 경험함. 엔지니어들의 심리적 안정을 위해 노력 중.

발표자료: SlideShare