DEVIEW 2021

목차

1.Backgrounds and issues

• "데이터 주권 주의" 와 "데이터 이동 제한" 이란
• "데이터 이동 제한" 지켜지지 않는다면
• 데이터 시스템 분리 구축 시 발생되는 문제

2. 네이버 지표의 특성

• 네이버 서비스의 구조적인 특징
• 네이버 서비스의 유연한 지표 특징과 이를 위한 난관

3. 글로벌 통합 가상 테이블 구축

• 글로벌 통합 가상 테이블 구축
• ClickHouse 분산 테이블 엔진을 활용한 분리 구축

4. 글로벌 Clickhouse 구성

• Shard & Replication
• Nested Distributed Tables - Write & Read
• High Availability

5. 통합 테이블 활용

• 통합 테이블 활용 예제

6. 왜 ClickHouse 였는가

• LSM Tree 를 통해서 본 Clickhouse의 특징
• Distributed Table Engine
• 기타 다양한 응용

7. 성능 분석

• 성능 측정
• 성능의 주요 요소
• 성능 요소 요약

8. Wrap-up

• 마치며

대상

• 글로벌 지표 제공 서비스가 필요한 개발자
• 빠른 글로벌 DBMS 구축이 필요한 개발자

본 세션에서는 Multi-tenancy k8s Cluster 환경의 Cloud에서 다양한 컴포넌트들에 대한 모니터링을 어떻게 제공했는지 함께 살펴보려고 합니다.
먼저 모니터링에 대한 이해를 위해, 모니터링에 필요한 요소들을 정의해보고 어떤 부분을 수집하고 가시화했는지 소개드립니다.
그리고 사용자가 늘어나면서, 모니터링에 대한 부하가 점점 누적되어 다양한 문제에 직면하게 된 부분과
이를 어떻게 해결해서, 현재는 어떤 형상의 모니터링을 제공하고 있는지에 대한 내용과 적용 과정을 공유드립니다.

목차

1. Cloud Monitoring

• Cloud Monitoring이란?
• Cloud Monitoring을 위한 요소
• Cloud Monitoring 구성

2. Cluster Monitoring

• Cluster Monitoring을 위한 요소
• Cluster Monitoring 구성

3. Large-scale Monitoring Crisis

• 대용량 Prometheus의 한계
• 운영하면서 받은 문의
• 시스템에 대한 개선

4. Distributed Container Monitoring

• 분산 처리의 필요성
• 분산 수집, 쿼리
• 사용자 관점의 분산
• 현재의 모니터링 시스템 형상

대상

• 컨테이너 환경에서 모니터링을 사용하는 방법이나 구조에 관심이 있으신 분
• 대규모 모니터링 시스템 구축을 고민하시는 분
• Prometheus와 Victoria-metrics가 어떻게 활용되었는지 궁금하신 분

광고주가 어떤 사람들에게 광고를 보여줬더니 다른 때보다 물건이 잘 팔렸습니다. 계속 높은 성과를 유지하기 위해 이 사람들과 비슷한 사용자들을 찾고 싶다면 어떻게 하면 좋을까요?
본 세션에서는 네이버 광고 타게팅 서비스 모델 중 하나인 look-alike 모델의 기법과 실서비스 적용 경험을 공유하고자 합니다.
Look-alike 모델은 광고 서비스 사용자(광고주)가 일부 오디언스 풀을 제공하면, 해당 오디언스 풀에 가장 가까운 유저들을 원하는 수만큼 찾아주는 모델입니다. 사용자 입력에 대한 빠른 응답을 위하여 전체 문제는 offline과 online 두 파트로 분리하였습니다. Offline에서는 딥러닝을 이용하여 유저의 행동을 적절히 임베딩하고, online에서는 이 임베딩 벡터를 기반으로 빠르게 가장 가까운 유저를 찾아 내보내는 작업을 수행합니다.
개발 기간 중 시뮬레이션을 통해 적절하게 제공되는 오디언스 풀 하에서 광고의 CTCVR과 CVR, CTR 등 중요 광고 지표들을 크게 개선할 것으로 기대할 수 있었습니다.

목차

1. Look-alike

• 광고주의 요구
• 기존 오디언스 기능
• 유사 타겟(Look-alike)

2. Model Architecture

• 전체 구조
• Offline Part
• Online Part

3. Offline Part: User Embedding

• 목표
• User Embedding Learning
• Embedding 시각화

4. Online Part: Look-alike Learning

• 목표
• PU Learning

5. Service Part

• 서비스 시스템 구성
• 최적화

6. Experiments & Results

• 오프라인 테스트
• 실 서비스 성능 테스트
• 성능 개선 실험

7. Conclusion

• 방법 및 성과 정리

대상

• 네이버 서비스를 사용할 때 이 광고가 왜 나에게 보여지는지 궁금하신 분들
• 네이버 광고 타게팅 모델이 어떻게 만들어지는지 궁금하신 분들
• 네이버 대용량 행동 로그가 광고 서비스에 어떻게 활용되는지 궁금하신 분들
• 딥러닝 기법의 실제 광고 서비스 적용 예시가 궁금하신 분들

클로바앱은 음성 UI 기반 어시스턴트 서비스의 단일 GUI로, 서비스 이용자들에게 필수적인 제어 UX를 제공하고 있습니다. 서비스의 주요 제품은 스피커 클라이언트와 도메인 스킬이고, 서버는 이들을 잇는 플랫폼으로 동작할 때, 이들 모두에 대해 알아야 하는 앱에는 어떤 복잡도가 누적될 수 있을까요?

이 세션에서는 클로바앱에서 Android 앱 개발자가 직접 클로바앱 전용으로 API 규격을 만들고 관리하며 어쩌다 보니 서버사이드 개발을 겸하게 된 사례를 소개합니다. 반 년 간의 개발 프로토타이핑, 반 년 간의 기획 검토와 품질 검증을 비롯한 실용화와 실증을 거치고, 이후 1 년 간 프로덕션에서 제 역할을 하며, 2 년 동안 이 프로젝트의 목표는 어떻게 변해 왔는지 알려드립니다. 누구보다 빨리 달려야 제자리를 지키는 서비스에서, 강물보다 빨리 헤엄쳐서 흐름을 거슬러 오르는 연어로 사는 수많은 개발자들에게 공감과 먼지팁을 전달하고자 합니다.

목차

1. 클로바앱이 쏘아올린 작은 공

• 클로바 어시스턴트 서비스
• 클로바앱의 역할
• 출시, 기능개선, 서포트… – 기기 제어
• 출시, 기능개선, 서포트… – 기기 OOBE

2. 과거부터 현재까지 눈덩이 굴리기

• 탐험의 시작
• 주요 기술결정 Pros & Cons
• 점진적 배포 개념 수립
• 주요 업데이트 사례

3. 그 다음 단계의 주제들

• 끝, 없는 탐험
• 약속된 자유의 개척지
• FAQ & Conclusion

대상

• 서비스 고유의 어려움까지도 사랑하는 서비스 개발자
• 개발조직 내부의 문제를 가시적으로 풀어나가는 방법에 관심이 있는 분
• 외부 요구사항을 처리하느라 내부 문제를 친구로 두고 함께 살아가게 된 서비스 개발조직의 모든 분
• 이 복잡하고 어려운 문제에 진심으로 신경쓰는 사람이 나뿐인 것 같아 외로움을 느끼거나 다른 사람의 시행착오 사례가 필요한 분

하이퍼커넥트에서는 다양한 서비스들이 개발되고 있고 이에 사용할 딥러닝 모델들이 연구되고 있습니다. 하지만 연구가 빠르게 끝나도 이 모델들을 실제로 배포하는 데에는 많은 어려움이 따릅니다. 모델을 빠르게 개발하려면 연구가 끝난 모델을 실제로 출시해서 적용해보고 결과를 얻어야 하는데 배포에 들어가는 시간이 길어질수록 모델 개발 사이클이 느려지는 문제가 있습니다.

본 세션에서는 모델을 관리하고 빠르게 배포하기 위해 개발한 시스템 전반에 대해 소개하고자 합니다. GitOps을 통해 모델을 관리하고 자체 제작한 Kubernetes 컨트롤러를 통해 명령어 한 줄이면 모델을 서버에 배포할 수 있게 했습니다. 세션 내용은 모델 배포 사이클에 어떤 어려움이 있는지, 또 시스템 구성요소들이 이러한 어려움을 어떻게 해결하는지를 소개합니다.

목차

1. Introduction

• Clova Face Kit이란?
• 지원 기능
• 사용처
  • 강남언니
  • FaceSign(네이버 신사옥에 사용 예정)
  • Naver 포토 클라우드
  • Line eKYC

2. Hands-On

• Settings & Options
• iOS
• Android
• Python
• JavaScript

3. Closing

강연 내용

On-Device ML의 영역은 이제 iOS/Android를 넘어 다양한 영역으로 넓혀가고 있습니다.
본 강연에서는 Clova Face Kit의 구조 및 성능을 개선하기 위해 어떤 방법을 취했는지와 사용법을 간단히 소개합니다.
현재도 다양한 서비스에 사용되고 있는 Clova Face Kit을 보다 많은 분께서 사용하시기를 바라며 본 Hands-On을 준비하였습니다.

강연 대상

• On-Device ML 에 관심있는 분들
• 얼굴인식 service를 개발/기획하시는 분들
• 얼굴인식 기능을 원하는 사업자 분들

이 세션에서는 네이버 회원들을 괴롭히는 피싱에 대해서 알아보고, 회원들을 피싱으로부터 보호하기 위한 웨일 브라우저의 노력과 그 결과를 공유합니다.

피싱 정보 수집 및 탐지 자동화를 위해 연구를 진행했던 다양한 기술(URL 기반 탐지, 웹 페이지 text 기반 탐지, 이미지 기반 탐지)들에 대해서 공유합니다. 또한 이러한 기술이 웨일 브라우저에 어떻게 적용될 수 있는지에 대해서 설명합니다.

피싱의 진화에 따라 웨일 팀과 Security 팀에서 대응하고 있는 방식에 대해서 소개하고, 우리가 네이버의 데이터를 피싱 대응에 어떻게 활용하는지에 대해서 소개합니다.

목차

1. 피싱과 웨일

• 최신 피싱 특성
• 웨일 소개

2. 웨일 안티 피싱 구조

• 웨일 피싱 대응 시스템 구조

3. 웨일 Safe Browsing

• 웨일 safe browsing 개발 고려사항
• 웨일 safe browsing 운영 고려사항

4. 웨일 CSD 피싱 탐지 기술

• URL 기반 탐지
• HTML 컨텐츠 기반 탐지
• 시각적 특성 기반 탐지

5. 진화하는 피싱 대응

• 피싱 진화에 대한 대응
• 피싱 데이터 확보 전략

목차

1. 검색 서비스와 사용자

• 검색 서비스의 구성요소
• 검색 사용자는 어떤 흔적을 남길까?
• 검색 로그 분석팀은

2. 사용자 행동 모델링

• 사용자 행동 모델링
• Primitive Feature
• Click Model 이란?
• PGM Click Models
• Advanced PGM Click Models
• Neural Click Models
• Click Model Evaluation
• Future work

3. 네이버 클릭데이터셋(CLARA)과 Pyclick 프레임 워크

• 클릭 데이터셋에 대하여
• CLARA 예시를 통한 클릭 데이터셋의 이해
• 새로워진 CLARA 데이터셋: CLARA2
• CLARA2의 생성과정
• Pyclick; 직접 Click Model을 만들어보자
• Pyclick을 활용한 클릭모델 학습과정
• Our Contribution
• Pyclick Tutorial

4. 검색에 활용하기

• User Modeling Process

대상

• 쇼핑/이미지/동영상/웹문서등 검색 서비스를 개발하시는 분들
• 검색 로그는 열심히 쌓고 있지만 어떻게 활용해야할지 모르시는 분들
• 사용자 모델 개발하기 위한 데이터 및 프레임워크가 필요하신 분들
• 네이버 검색에서 검색 사용자의 로그로 검색 개선을 하는 과정이 궁금하신 분들
• Pyclick 모델에 대해 입문하고 싶으신 분들

본 세션에서는 APM에서 Front-end 개발은 어떠한지 소개하고, APM이라는 카테고리에서 사용되는 다양한 UI 컴포넌트들의 기술적 난제들이 무엇인지, 그리고 어떻게 해결하고 있는지에 대한 노하우와 팁을 공유합니다.

목차

APM 소개

• APM이란?
• APM에서의 FE 개발

APM FE 개발자의 Focus

• APM의 목표
• 그 목표를 달성하기 위한 주요 요소들

고민과 해결

• Scatter Chart에서의 성능 개선
• 한눈에 알아보기 쉬운 Server Map
• 대규모 프로젝트에 Color System 적용하기(다크모드는 덤)

대상

• 데이터 시각화에 관심이 있으신 분
• APM FE 개발에 관심이 있으신 분
• 디자이너가 없는 프로젝트에서 UI/UX개선에 관심이 있으신 분

본 세션에서는 HBase기반 데이터 저장소 운영 경험을 공유합니다.

네이버 데이터 저장소는 HBase기반으로 HBase Locality를 높게 유지하면서 운영을 하고 있습니다.
HBase Locality에 대하여 알아보고 어떠한 방식으로 성능상 이점을 가지고 올 수 있는지 내부 구조를 살펴봅니다. (HDFS Short-circuit Local Reads)
HBase Locality를 높게 유지하면서 운영하는 방법과 HBase Locality를 낮추는 디스크 장애를 처리하면서 겪었던 문제와 해결 방법을 공유합니다.
마지막으로 데이터 저장소에서 HDFS Short-circuit Local Reads를 사용하였을 때 효과를 확인합니다.

목차

1. HBase기반 데이터 저장소

• 네이버에서 데이터 저장소가 필요한 이유
• HBase 기반 검색 데이터 저장소 (Deview 2017)
• HBase의 기본 구조

2. HBase Locality란

• Data Locality
• Hbase Locality
• HBase Locality를 올리는 방법

3. HBase Locality를 통한 읽기 성능 높이기

• LocatedBlocks의 순서
• HDFS Short-Circuit Local Reads

4. 네이버 데이터 저장소에서 HBase Locality를 지키기 위한 운영

• 운영시 HBase Locality를 지키는 방법
• 클러스터 규모와 비례하는 디스크 장애
• DataNode Hot Swap Drive
• 언마운트 불능 현상1
• HDFS Block 이 망가졌을 때 상태 공유
• Aggressive Purge
• 언마운트 불능 현상2
• 디스크 장애 처리 자동화

5. 네이버 데이터 저장소에서 효과

강연대상

• HBase 기반 검색 데이터 저장소의 발표에 관심이 있으셨던 분들
• HBase기반의 대용량 클러스터를 운영중인 분들
• HDFS기반의 데이터 처리에서 성능 이점을 얻고 싶으신 분들
• HDFS shortCircuit Reads내부 구조에 대하여 궁굼하신 분들
• 대규모 클러스터 운영시 디스크 장애처리에 지치신분들

본 세션에서는 네이버 클라우드 플랫폼의 Terraform provider를 개발한 경험을 가지고, VPC 예제를 통해 Terraform provider를 만드는 방법을 간단하게 알려드리고, 저희가 겪었던 사례와 팁 들을 공유 해 드리고자 합니다.

목차

1. Terraform provider란?

• Prologue
• Terrform provider에 대한 간략한 소개

2. How terraform works

• 예시를 통해 Terraform 이 어떻게 동작하는지 알아봅니다.

3. Terraform plugin 개발

• Terraform plugin이란?
• NCLOUD GO SDK 소개
• Terraform plugin개발
• Provider개발
• Resource개발 (VPC)
• Testing 및 Release 등

4. Appendix & Tips

• 비동기 API 다루기
• 동시성 이슈
• 순환 참조 이슈
• 그 외 Tip들

이 세션에서는 DEVIEW 2019에서 소개되었던 얼굴 인식 서비스 FaceSign이 코로나 시대에 들어서며 어떻게 성장해 왔는지 소개하고, 한정된 조건 안에서 최고의 유저 경험을 위해 고군분투한 고민과 노력들을 공유하고자 합니다.

목차

1. FaceSign

2. 마스크를 쓴 얼굴 인식 모델

• 마스크를 쓴 얼굴 인식 모델
• 멀티 모델 서빙 서버 설계
• 학습 데이터 파이프라인

3. 스피드 게이트

• Vision engine 경량화
• 이미지 처리 속도 개선
• 체온 측정
• 사용자 경험 개선
• 다각화된 테스트와 walk-thru

4. Anti-spoofing

• Anti-spoofing 모델과 실전

5. 네이버 신사옥 속 FaceSign

강연 대상

• AI 모델을 이용한 서비스 만들기를 시작하려는 분
• AI 서비스의 진짜 매운 맛이 궁금한 분
• 얼굴 인식 서비스에 관심 있는 분

본 세션에서는 우리가 특정 도메인을 위한 전용 딥러닝 번역기를 만들고자 할때, "데이터를 얼마나 넣어야, 나의 전용 모델이 내가 원하는 성능이 나오는지?" 또는 "이 데이터를 넣으면 얼마나 성능이 좋아질지?"를 예측하는 "perfomance estimation task"를 풀도록 합니다. 위의 문제를 풀기 위해, 제안한 방법은 주어진 데이터를 활용해 일일이 기계번역 모델을 finetuning할 필요 없이 몇개의 feature들만으로 finetuning한 후의 성능을 예측하도록 합니다. 이러한 방법론은 일일이 학습해야 하는 computation cost를 줄일 수도 있고, 실제 사용자들에게 얼마나 데이터를 넣어야 자신이 원하는 성능에 도달 할 수 있는지를 알 수 있습니다.

또한, 구체적으로 위의 문제를 효과적으로 풀기 위하여 어떠한 feature들을 활용하여 모델의 성능을 높이는 게 좋을지, 어떠한 구조를 만드는게 좋을지에 대해서 다양한 실험을 공유합니다. 그리고 본 세션에서는 가장 좋은 예측 성능을 보여주는 네트워크와 feature 조합을 제안합니다.. 그리고 앞서 정의한 문제상황에서 실제 예측 성능과 다양한 시나리오(e.g., 데이터의 갯수에 따른 성능 예측 등)에 따른 성능을 보여주도록 합니다. 이를 통해, 과거의 방법론들 대비해서 제안한 예측 모델의 정확도가 더욱 높고, 적은 training data 만으로 만들 수 있어 실제 시나리오에서 적용가능함을 보여줍니다.

목차

1. 도입배경

• 일상 생활에서 번역기
• 하나의 번역기의 한계& 전용 번역기의 필요성
• 전용 번역기 만들기
• 성능 그래프를 추론해야 하는 이유
• 기존 방법론의 한계 및 어려움
• Summary : challenges
  ​

2. 기계 번역 성능 예측 모델

• Instsance-level framework
• Domain difficulty features
• Corpus-level features
• Overview of the architecture
  ​

3. 실험 결과

• Experiment settings
• Baselines
• Performance on the unseen domain
• Interpolation and Extrapolation
• Analysis
• Performance with 0k anchor point
  ​

4. Conclusion & Future work

• Summary
• Future work
  ​

대상

• 기계번역 및 NLP 분야에 관심을 가지고 있는 연구자 및 개발자
• Domain adaptation, transfer learning , Machine translation의 서비스 적용에 대해 관심을 가지고 있는 분들

본 세션에서는 네이버 컨텐츠 검색에서 실제로 서비스하고 있는 영화 취향 추천에 대한 내용을 공유합니다.
어떤 데이터를 어떻게 가공해서 사용했는지, 해당 데이터가 어떤 알고리즘에 의해서 모델에 반영되는지 등 모델을 제작하며 고려한 부분과, 모델 제작 중 생기는 문제들을 어떻게 해결하는지를 다룹니다.
또, 많은 유저들의 취향을 어떻게 저장하며 어떤 방식으로 서빙하는지 등 서빙을 위한 플랫폼 설계 방식과 이후 제공되는 결과들에 대해 다룹니다.

목차

1. 조금 덜 똑똑한 추천?

• 정교한 추천, 부담스럽다
• 조금 덜 똑똑한 추천

2. 기반 데이터와 알고리즘

• 데이터 소개
• Knowledge Graph 및 사용 알고리즘 소개

3. 영화 취향 추천 모델

• Knowledge Base 구조화 및 분석
• 영화 추천 모델 구조 제작
• 영화 추천 모델 제작 및 개선

4. 취향 추천 시스템 구조

• 모델의 연산 시간
• 3단계 구조

5. 적용된 데이터 Flow

• 구성 요소 / 데이터 Flow
• 정기 업데이트
• 상시 업데이트
• 조회

대상

• 새로 제공되는 영화 취향 추천이 어떤 방식으로 제공되는지 궁금한 분들
• 대용량의 데이터를 저장하고 사용하는 구조에 대해 궁금한 분들
• Knowledge Graph를 사용한 추천에 대해 궁금한 분들

Kubernetes확산은 Stateless Container 에서 Stateful Container 범위가 넓어지고 있습니다.
Stateful Container를 위해서 데이터를 "빠르고, 안전하면서 비용 효율적으로" 저장해야 합니다.
이를 위해 네이버에서는 Ceph 과 OpenStack, 그리고 자체 개발한 Plugin을 통해 Kubernetes와 연동하여 사용중입니다.
네이버에서 컨테이너 데이터를 어떻게 빠르고, 안전하고, 비용 효율적으로 저장하는지와 이를 어떻게 효율적으로 모니터링하는지를 소개합니다.

목차

1. Stateful Application

• Stateful Application Containerizing
• Local vs Remote Storage
• Thick vs Thin Storage

2. Cloud Native Storage

• Kubenetes Storage Provisioner
• Custom Provisioner and Flow

3. Troubleshooting

• 클러스터 성능 이슈
• 분산 서비스 on 분산 스토리지 이슈
• 스토리지 증설(Scale-out)의 현실적인 문제점

4. Operation Tools and Tips

• Performance Monitoring with Thanos
• Log Monitoring with PLG Stack
• Grafana Dashboard Templates

대상

• 쿠버네티스로 스테이트풀 서비스 전환을 고려하시는 분들
• 컨테이너에 네트워크 스토리지 적용이 필요하시는 분들

CLOVA Note 서비스에 SwiftUI를 적용한 경험을 공유합니다.

SwiftUI는 Apple Platform Application 개발을 위한 새로운 프레임워크입니다. SwiftUI의 초기 버전은 UIKit에서 지원하던 기능들을 전부 지원하지는 않습니다. CLOVA Note에서 SwiftUI를 적용하기 위해 어떤 Architecture를 사용했고 SwiftUI에서 지원하지 않는 기능들을 구현하기 위해 UIKit을 통합하여 서비스를 출시하기까지의 과정에 대한 내용입니다.

목차

1. SwiftUI

2. SwiftUI in CLOVA Note

• Architecture
• Integration with UIKit

3. Summary

대상

SwiftUI에 관심있는 iOS 개발자

본 세션에서는 웨일을 차량용 플랫폼으로 만들기 위한 전반적인 설계과 시행 착오 과정을 공유합니다.

웹앱 기반의 앱을 구동한다는 일반적인 목적과, 차량용이라는 특수한 목적을 어떻게 융합하였는지,
하나의 시스템으로, 차량 좌석별로 달라지는 화면 출력과 제어 권한을 어떻게 나누어 가상화하였는지,
SW 친화적인 웨일과 HW 친화적인 AGL(차량용 리눅스)가 어떻게 결합이 되었는지에 대한 궁금증을 풀어 드립니다.
​

목차

1. 웨일 Auto - 웨일의 도메인을 확장하기 위한 PoC 과제

• 차량의 발전과 차량용 SW의 미래
• 네이버와 드림에이스의 협업
• 그래서 나온 결과물이 바로 이것!

2. 시작은 요구사항을 만들고 분석하는 것부터

• 필수적으로 구현되어야 하는 것
• 차량용 플랫폼이 되기 위해 만들어야 하는 것
• 그리고도 추가로 더 만들어야 하는 것

3. 플랫폼 필수 요소 만들기

• 윈도우 시스템
• 애플리케이션 프레임워크
• 웨일 스토어
• 필수 요소들로 이루어진 시스템 구조도

4. 차량용 플랫폼이 되기 위해 추가적으로

• 차량의 신호에 대응하기
• 차량의 HW적인 인터페이스에 대응하기
• 차량용 기본앱 제작
• 그 이외에도 이런 것들을…

5. AGL에서 구동하는 웨일 브라우저 만들기

• Chromium 68 → Whale 83 포팅
• Web Feature 구현 : PWA

6. AGL에서 구동하는 웨일 Auto

• AGL의 Web Feature 제거
• 웨일 Auto 를 위한 AGL API 개발
• Automotive API 를 이용한 차량정보 서비스 연동

대상

• OS급의 플랫폼 아키텍쳐는 어떻게 설계가 되는지 궁금하신 분들
• 차량용 SW의 미래에 대해 힌트를 얻고 싶으신 분들
• 웨일이 꿈꾸는 미래를 엿보고 싶으신 분

네이버 검색의 모니터링 시스템에서 시계열 데이터를 다루는 방법에 대해 소개합니다.
네이버의 검색 서비스 규모가 커지면서 수집 및 저장 해야하는 데이터도 함께 증가했습니다.
기존 구조에 한계를 느껴 대용량 시계열 데이터에 대응하기 위해 10년 이상 된 모니터링 시스템을 개선하고 RDB → 시계열 DB 전환 경험을 공유합니다.
기존 RDB 구조에서 가지고 있었던 한계점과 시계열 DB를 도입하게된 과정, 시계열 DB가 도입되며 개선된 구조와 얻게된 이점, 그리고 어떻게 활용했는지에 대해 공유드리려고 합니다.

목차

1. 모니터링 시스템 소개 및 기존 구조의 한계

• 네이버 검색 모니터링 시스템 소개
• 네이버 검색 모니터링 시스템이 걸어온 일
• 기존 모니터링 시스템의 구조와 한계

2. 통합 저장소 구축을 위한 TSDB 선정 과정

• TSDB 선정 과정
• TSDB 도입 과정
• TSDB 도입 후 저장구조 소개

3. 통합 저장소를 사용한 신규 모니터링 시스템 소개

• 신규 모니터링 시스템 구조 소개
• 신규 모니터링 시스템 구축으로 개선된 점

4. Querying Tips

• Queying에 대한 tip 소개

5. 마무리

• 마무리

강연 대상

• 네이버 검색에서 분당 생산되는 대용량 시계열데이터를 실시간으로 어떻게 수집하고 저장하는지 궁금한 분들
• 시계열 DB를 도입할 예정이시거나 관심 있으신 분들