Day2 세션들 중 관심있는 세션들을 슬라이드 내용을 중심으로 요약정리했습니다

---

WebtoonMe 개발기: 내가 웹툰 안으로 들어가면 여신강림 임주경 보다 이쁠까 안이쁠까?

김승권, 백지혜/ NAVER WEBTOON

1. WebtoonMe 소개: 내가 웹툰으로 들어가면 어떤 느낌일까?

2. “웹툰으로 변환” 여정을 위한 모델 개발

• 생성 모델의 트렌드를 읊고 이를 바로 적용하자
  • 기존에는 성능이 좋은 “모델”을 만드는 것이 중요했다면,
  • 최근에는 이 모델을 활용하여 task에 적합한 (1) 고품질의 “데이터”를 생성한 후
  • (2) 가볍고 학습이 쉬운 별도의 network를 학습시키는 것이 트렌드
  • 웹툰 캐릭터의 경우 데포로메가 심하기 때문에 얼굴 변환이 잘 안되는 문제 발생
• 현업의 니즈를 바로바로 적용하자
  • 다양한 피부 톤 반영
  • 다양한 조명 조건 반영
  • 캐릭터 고유 피부 반영
  • 추론 속도 개선
  • 빠른 Ad-hoc 기능 반영

3. 힘들게 만든 모델, 어떻게 밖으로 내보내지?

• 빠른 프로덕트 프로토타이핑
  • 추상화 높은 방법론으로 최대한 빠른 결과로 작지만 유의미한 성공을
  • 보여주고
  • 이를 바탕으로 전문가를 섭외해서 추상화를 낮추자!
• 만들었는데 어떻게 홍보를 해야하지?

4. WebtoonMe 이렇게 활용 했어요.

• 방송에 데뷔한 네이버 쇼핑라이브 기술 지원 사례
• 직접 웹툰 컷으로 들어가 볼 수 있는 실시간 체험 존 구축
• 목마른 사람이 우물파는 컨셉의 현업 기술 지원

5. WebtoonMe 다음은?

• WebtoonMe 판을 키워보기
• 높은 개인화, 실시간 변환, 다양한 웹툰 캐릭터 지원

NSML: 대규모 HPC 클러스터의 효율적 활용을 위한 Scheduler, Monitoring, Diagnostics

박흥석,조애리,이하영/ NAVER Cloud

1. Introduction

• NAVER 대규모 분산학습 플랫폼: NSML
  • 고성능 하드웨어와 고용량의 스토리지를 쉽게 사용할 수 있도록 학습 모델링 관련 도구를 제공하는 플랫폼
  • NSML Pods는 최대 GPU 128장 규모의 모델까지 학습 가능한 대규모 HPC 클러스터
  • NSML Pod 내 모든 GPU 서버는 고속 네트워크 InfiniBand(IB)로 연결
  • NSML Pod 내 GPU 서버 간 통신 병목 최소화 → 분산 학습에 유리
• NSML의 대규모 HPC 클러스터와 효율화 전략
  • Scheduling (GPU 활용률을 높이는 스케쥴링)
  • Monitoring (대규모 HPC 클러스터 모니터링 도구 개발)
  • Diagnostics (정형화하기 어려운 분산학습 엔지니어링 이슈 진단)

2. Scheduler

• GPU 점유 환경의 문제점
  • GPU 서버를 팀별로 구입하고 점유해 사용
  • 흩어진 GPU 자원을 모아 효율적으로 배분하기 위해 수요 및 정책에 따른 스케쥴링 도입
• GPU 활용률을 높이기 효율적인 스케줄링 전략
  • 자원 파편화 현상 : 할당량 감소로 이어짐
  • 파편화 (Fragmentation)
    • 자원을 배정하고 회수하는 과정에서 발생하는 작은 리소스 조각
    • 파편화된 리소스들은 사용되지 못하고 방치됨
  • 할당률을 저해하는 가장 큰 요소
    • 사용자의 실험 스펙상이
    • 호스트에 종속되어 있는 자원
  • 리소스 유형 정의
    • GPU 개수에 비례하여 CPU, RAM 등의 호스트 자원을 배정
    • 호스트 내 자원 파편화 방지
  • MostAllocated 정책 적용
    • 소규모 실험이 대규모 실험의 할당을 저해해서는 안 됨
    • 리소스를 많이 사용 중인 호스트부터 우선 배치
  • 실험 규모에 따라 NSML Pod에 역할 부여
    • 규모가 유사한 실험끼리 조합해서 배치
    • 다양한 실험 규모에 따른 호스트 자원 파편화 방지
  • 할당량 향상으로는 한계가 있다
    • 수요에 비해 상대적으로 부족한 공급량
• NSML 스케줄러 도입기
  • 경제학 전문가와 협업하여 자원 활용에 대한 정성적 / 정량적 분석 진행
  • GPU 활용률
  • 리소스 유형별 대기 시간
  • 팀별 리소스 사용 현황
  • 규모에 따른 구역 활용률
    • 전체 사용자별 GPU 점유 시간
    • 우선순위 낮은 소규모 실험 활용률
  • 커스텀 스케쥴링 도입
    • k8s Scheduler Framework를 활용해 커스터마이징
    • GPU 활용률을 높이는 방향으로 할당 제어
  • 정책 우선순위 기반 스코어링
    • 실험 규모, 대기 시간에 따른 스케쥴링 우선순위 조정
  • 중, 대규모 학습 예약
    • 규모가 큰 실험에 대한 예약 시스템 도입
  • 분산학습 지원
    • 반드시 같은 NSML Pod 내에 배치
    • 동시 실행 보장 (coscheduling)

3. Monitoring

• 대규모 HPC 클러스터 관측의 배경
  • 자원 활용량의 극대화: 운영자 & 사용자 모두의 노력 필요
• 기존 모니터링 & MLOps 도구의 한계
  • MLOps 플랫폼: 모델 학습에 대한 가시성 제공에 집중, 개별 학습에 대한 단순 시스템 지표 제공
  • Cloud 모니터링 플랫폼: 서비스 인프라 모니터링에 집중, 학습 이상 상태 탐지 기능 구축 어려움
  • 클러스터 자원 현황과 학습 상태를 한눈에 파악할 수 있는 “통합된 가시성” 제공
• 모니터링 도구 개발 과정
  • 전체 클러스터 자원(수천 개의 GPU) 상태와 할당된 실험 상태를 동시에 표현해야 함
    • Unit visualization
    • 사용자의 멘탈 모델과 가장 일치하는 방식, GPU 자원 하나를 정사각형 유닛으로 매칭하여 시각화
    • 유닛에 생삭, 패턴을 매핑하여 아웃라이어를 빠르게 드러낼 수 있음
    • 웹 어플리케이션
      • deck.gl(WebGL 프레임워크)로 구현
      • 유닛 위치/컬러 트랜지션을 통해 클러스터 자원의 실시간 상태 변화를 직관적으로 이해
  • 운영자/사용자의 서로 다른 모니터링 니즈를 만족해야 함
    • Atomic Unit Visualization Grammar 논문의 유닛 시각화 활용 기법 구현
    • 클러스터의 물리적 요소, 실험의 논리적 요소를 포함한 다양한 데이터 속성을 계층 구조로 표현할수 있도록 설계
  • 자원이나 실험의 이상 현상을 빠르게 탐지할 수 있도록 도와야 함
    • Violation rule을 통한 힌트 제공
      • 학습 시작 시점부터 GPU 활용률 등 시스템 지표의 95%, 25% 분위값을 춫적
      • 사용자가 정의한 임계치 이하의 실험들을 하이라이팅
      • 강조된 실험들은 빠르게 진단 도구로 분석하도록 유도
  • 문제를 디버깅할 수 있는 상세한 시슽메 지표 데이터를 제공해야 함
• HPC 클러스터 관측하기

4. Diagnostics

• 분산학습 시 마주하는 엔지니어링 이슈
  • Data Parallelism: 데이터를 머신별로 나누어 학습
  • Model Parallelism: 모델을 머신별로 나누어 학습
  • 동기화 병목: 일부 Worker의 작업이 지연될 수 있음
    • workload imbalance 로 인한 작업 지연
    • 일부 노드 / GPU의 장애로 연산 지연
    • 노드 간 / GPU 간 데이터 통신 지연
  • 강력하지만, 대규모 실험의 엔지니어링 이슈를 효과적으로 드러내지 못함
  • 분산학습 전략에 따른 다양한 지표 패턴
• 분산학습 진단 도구 개발 과정
• 분산학습 엔지니어링 이슈 진단하기
  • 어떤 GPU/ Node를 분석해야 하는가?
    • 각 GPU 들의 지표 분포 / 패턴이 드러나도록 지표 preview 시각화
    • Violation rule에 해당하는 GPU는 강조
    • • Clustering 을 통해 확연한 차이 및 잠재된 imbalane / outlier 표현
  • 어떤 구간을 분석해야 하는가?
    • 시스템 지표 간 상관관계 분석
    • 상관관계 및 분포에서 멀리 떨어진 이상치 데이터 강조
    • 이상치 데이터와 상호작용, 해당 구간 상세 분석
  • 이상치를 직관적으로 드러내고, 효율적인 분석 방향 제시

  ### 5. What’s Next?

  • Scheduling
    • 데이터 기반 우선순위 스케쥴링 강화 (사용자의 월 소비량, GPU 활용률 실적 등)
  • Monitoring
    • 커스텀 가능한 학습 이상 상태 탐지 조건
  • Diagnostics
    • 이상치 탐지 방법론 고도화 (root cause 가시화)
    • 분산 학습 엔지니어링 이슈 알람 체계 구축

ML/AI 개발자를 위한 단계별 Python 최적화 가이드라인

문주혁/ NAVER Cloud

0. 모델러 출신이 CPU 속도를 신경쓰게된 배경

서버환경; X86_64(cuda)

개발자: computer vision 전공

사용언어: Python + OpenCV + NumPy (PyTorch)

1. Python 간단 프로파일링

• 이미지 로딩, 투명 픽셀 제거, 픽셀 카운팅, 패널 생성 으로 진행
• line profiler 소개 및 사용법
  • line by line profiling for Python
  • pip install line_porfiler
  • OSX / Apple silicon (arm)의 경우 Rosetta 필요
• profile 중 사고 방식 및 주의점

2. Python level 최적화

• 베이스 Python 코드 작성시 주의점
• OpenCV/NumPy 등 기존 Python 패키지 잘 쓰는 법
• python 패키지 같은 출력을 내는 여러 문법을 비교해 병목구간을 더 빠르게 바꿔보자

3. Semi-C level 최적화

• Cython/Numba를 활용한 최적화
• Numba/Cython 활용시 주의점 (언제 어떻게 써야하는가)
• 유용한 경우
  • 코드 내 pure Python 구현의 비중이 너무 큰 경우

4. C level 최적화

• Python/C API로 C extension 만들기
  • 각각의 crop이 독립적이므로 병렬처리를 하고싶지만, 원본 이미지가 GIL에 묶여있어 동시 접근 불가
  • C/C++ 에 가져가서 자유롭게 crop 해보자..
• C 라이브러리 활용하기 (feat. OpenMP 도입하기)
  • core implementation 위아래로 OpenMP 구문 추가
  • 87.7 ms → 4.64ms (-94.7%)
  • Python/C API 꼭 한번 써보라.
  • 진입 장벽은 있지만 개발이 자유로워진다.
  • 이런 때 아니면 언제 C/C++에 입문해볼까?
• 기존 Python 패키지 (OpenCV/NumPy)와 호환 가능한 C extension 만들기
• C extension 개발 시 주의점 (lifetime 관리, memory leak 예방)

5. 기타

• 도커 환경 및 환경 변수에 대한 이야기

웨일 브라우저 오픈 소스 생존기

이형욱/ NAVER Cloud

1. 브라우저 오픈소스 전성 시대

2. 웨일 브라우저와 크로미움

3. 리베이스의 무게를 견뎌라

• 리베이스란 무엇인가?
  • 사용중인 오픈소스의 버전을 최신 버전으로 가져오는 작업
• 브라우저에서 리베이스가 왜 중요한가?
  • 브라우저는 발전 속도가 빠른 웹플랫폼으로 빠른 속도로 따라 가야함
  • 리베이스 속도를 따라 가지 못하면 사이트 호환성, 보안등이 취약
  • 크로미움 오픈 소스를 실시간으로 따라 가지 못하는 것은 브라우저 생존과 직결
• 기능 기반 배포 대비 일정 주기 배포가 어려운 이유?
  • Time based release 가 가능한 개발 문화와 인프라가 갖춰져야 가능한 도전
  • 브라우저는 단순한 앱이 아닌 하나의 웹 플랫폼으로 플랫폼 수준의 배포 난이도
  • 일정 주기 배포로 웹생태계 전반에 걸친 예측 가능성 확보가 가능해 짐
• 빠른 코드 리베이스를 위한 리베이스-봇 개발
  • 크로미움은 매달 대략 21,274 파일이 변경되고 735,896 라인 추가 410,142 라인 삭제
  • 웨일은 크로미움 소스에서 대략 1만여개 파일을 수정 하였음
  • 코드 리베이스를 잘 하기 위해서는 변경된 파일을 최소한의 컨플릭트로 반영하는 것!
  • 리베이스-봇의 개발로 자동으로 웨일 소스에 크로미움 패치들을 적용 (80%정도는 무충돌)
  • 컨플릭트 발생시 패치가 아닌 파일 단위로 관리 (작업 순서 관리에 유리
  • 자주 리베이스를 할 수록 코드 컨플릭트가 드라마틱하게 줄어 듬
• “매 PR마다 15만여개의 테스트 케이스를 12대의 테스트 봇을 활용해서 검증 함
• 배포 전 350여개의 테스트 케이스를 성능 봇을 활용해서 검증 함
• “배포 전 주요 사이트들을 대상으로 자동으로 메모리 사용량을 테스트 함
• 경쟁사 브라우저 대비 약점 이었던 리베이스 속도를 개선하여 글로벌 경쟁력 확보

4. 생존을 넘어서 기여하기

• 웨일의 Local User First 전략의 일환으로 국내 웹생태계 이슈는 웨일팀의 주요 관심사
• Safe Browsing DB, 텍스트 기반 피싱 탐지에 더 나아가 이미지 기반 실시간 피싱 탐지 기술 개발

Noir: 메일검색 서버를 반의 반으로 줄여준 신규 검색엔진 제작기

이창현, 신우진/ NAVER Search

1. 개별데이터 검색서비스와 역색인 검색

• 개별데이터 검색 서비스의 특징
  • 내가 받은 메일
  • 내가 속한 채팅룸 대화
  • 내 파일
• 기존 역색인 검색방식의 장단점
  • 단 한명의 메일을 검색하기 위해 전체문서 검색
  • 단 한명의 신규메일로 전체볼륨 업데이트 부하
  • Locality가 떨어져 제한된 메모리에서 검색성능을 만족하기 어려움
• 역색인 검색엔진으로 개별데이터 검색서비스 서빙 시 어려움
  • 해당 사용자 문서만 검색
  • 해당 사용자 볼륨만 업데이트
  • 검색대상 문서가 물리적으로 모이므로 성능 개선
• 신규 검색엔진 이전에 존재했던 개별 역색인 관리 솔루션의 한계
  • 개별 역색인 볼륨 방식
  • 검색시 동적으로 해당 볼륨을 메모리에 올려 검색
    • 장점: 역색인을 메모리에 상주시킬 필요 없음
    • 메모리 기반에서 disk 기반으로, 비용 감소
    • 일부 문서 set에 대해 작업하므로 문서 업데이트 및 검색 비용 감소
  • 수천만 이상의 개별 볼륨 서빙
  • 각 검색서버마다 다수의 볼륨 저장
  • 검색요청 시 적절한 검색서버를 찾아 검색
  • 색인 서버에서 볼륨생성 후 검색서버로 배포
  • 개별 역색인 볼륨 방식의 어려움
    • 일일 문서 수억 건 유입으로 서버비용이 가파르게 상승 (Disk 수요, 검색서버)
    • 문서 증분 비용이 비쌈 (CPU 수요, 색인서버
    • 큰 볼륨 검색 시 응답속도가 너무 느림
    • 수천만 역색인을 다루는 운영상의 어려움

2. 역색인을 대체하는 Full Scan 검색방식

• full scan 검색방식 소개
  • 문서 원본 scan, 문서가 쿼리와 부분일치할 시 검색됨
• 문서 블록단위 압축으로 full scan 검색성능 끌어올리기
  • 문서를 일정 크기로 모아 블록 단위 압축
  • 각 압축블록을 병렬적으로 Scan
• full scan 검색엔진 MVP버전 성능
• 역색인 검색엔진 대비 장점
• Noir (No information retrieval)

3. 신규 검색엔진 Noir

• full scan 방식을 사용하는 신규 검색엔진
  • 개별 데이터 서비스에서 충분한 검색속도
  • 볼륨 생성, 업데이트 비용이 저렴함
  • 검색볼륨과 문서볼륨의 역할이 통합된 볼륨
  • 부분일치 검색 방식
• 실서비스 적용 효과
  • 검색서버 1/3, 색인서버 없음
  • 볼륨구축 및 증분 비용 감소
  • 운영 공수 절감

4. 설계

• Noir 볼륨 설계
  • 문서 입력 연산 목표
  • 문서입력 중 검색 가능해야 한다
  • 문서입력 중 셧다운 당하더라도 볼륨이 망가지지 않아야 한다
  • 문서입력 비용을 최소화하고 싶다
    1. compaction 시작 전
    2. 기존 증분볼륨에 신규문서를 더해 압축
    3. 신규 압축블록은 기존 압축볼륨에 append
    4. 압축볼륨에 덧붙여진 블록과 새로 생성된 증분볼륨.v2 를 알고있는 메타데이터 디렉토리 생성
    5. 새 info 디렉토리로 심볼릭링크 변경
    6. 기존 info 디렉토리 삭제
• 볼륨 CRUD 방식
  • 문서 수정 요청 유입 시 매번 볼륨 내 문서를 수정하기 어려움
  • 별도의 Patch 볼륨에 변경내역을 쌓아둔 뒤 검색 시 동적으로 반영
  • 변경 내역이 많이 쌓이면 검색 성능 저하
  • 일정 이상 쌓이면 볼륨을 재구축해 반영
  • Timeout이 발생하면 검색한 결과를 최대한 반환
  • Timeout 발생지점 offset으로 나머지 문서 검색 가능
• 분산 구조
• 저널링
  • 서버 셧다운 시 인입된 요청이 유실되지 않게 한다
  • 요청을 WAL(Write Ahead Log)에 완전히 로깅 후 요청 수행
  • 서버 셧다운 시 기록된 모든 요청을 replay
• 토폴로지 버전 관리

5. 고도화

• Collation
  • 동일한 의미의 문자를 구분없이 검색하는 기능
  • 현재 구현: 검색 시 정규화
  • 검색 시 문서내용을 동적으로 정규화 개선 예정: 전처리 테이블
  • 문서내용을 미리 정규화해서 검색성능 개선
  • 문서 요약문 추출 시 테이블 활용
• 볼륨 샤딩

VictoriaMetrics: 시계열 데이터 대혼돈의 멀티버스

1. Background

• Monitoring NAVER Search System
• Large-scale time series data
• Time series DB History

2. A Deep-dive into Time series DB

• Time series DB = Index DB + Data Storage
• LSM Tree 구조를 통해 Read/ Write 모두 빠르게 처리
• Gorilla Compression 을 활용하여 압축률 향상 & 메모리 효율 증가
• High Churn Rate 상황은 피하는 것이 중요

3. Time series in the Multiverse of Madness

• Single Point of Failure 문제를 해결하기 위해 Cluster Mode 사용
• 다양한 Application의 서로 다른 접근 패턴으로 과부하 문제 발생
• Application들이 서로 영향을 주지 않도록 Multiverse 형태로 분리

4. Lessons Learned

• 비상등 역할을 잘 하기 위해서 지표 유실과 중단 시간 최소화 필요
• 지표 유실을 방지하기 위해 Message Queue 와 Data Buffering 도입
• 중단 시간 최소화를 위해 Pre-calculator 를 통한 Heavy Query 완화
• High Availability 구성을 위해 Multi-level Cluster 기능 도입
• 효과적인 Multiverse 운영을 위해 Data Migration 기능 활용

5. Takeaways

• Understand time series DBs and VictoriaMetrics
• It’s simple, but you still need to be skillful
• Let’s do it together