<div id="readability-page-1" class="page"><div id="overflow-container" role="main"><article><div><p>얼마 전 열렸던 <a href="https://deview.kr/2020">DEVIEW 2020</a>의 세션 중 하나인 <a href="https://deview.kr/2020/sessions/329">‘밑바닥부터 만드는 인공지능 서빙 플랫폼’</a> 발표를 듣고 그 내용을 요약합니다. 플랫폼 개발의 이유를 명확하게 설명하고 이로부터 이어지는 시스템의 설계 내용이 논리적으로 잘 맞아떨어져서 즐겁게 들을 수 있었던 발표였습니다. 마이크로서비스들의 배포와 서빙을 위한 플랫폼과 머신러닝 배포 및 서빙 플랫폼 사이에 기능적, 기술적으로는 연관관계가 많이 있는 반면에, 둘 사이에 사용자, 환경, 작업 흐름의 차이 때문에 현실적으로는 머신러닝에 국한된 프로덕트가 필요하다는 생각을 가지게 되었습니다.</p><hr><ul><li>시작<ul><li>2019년 초 weight 파일 + 인퍼런스 코드 + flask 서버로 서빙 시작</li><li>지금은 각 모듈을 공통화</li></ul></li><li>모델 공통화 동기<ul><li>모델 수 증가 -&gt; 서빙을 위한 엔지니어링 코스트 증가</li><li>지속적인 모델 학습과 배포: A/B 테스트, 로그를 저장하고 이를 통한 학습</li><li>사내시스템 연동: 유지보수가 잘 안되는 코드</li><li>협업 가능한 환경 구축: 엔지니어가 모델러로부터 받은 인퍼런스 코드를 재작성하는 엔지니어링 코스트. 모델러와 엔지니어의 관심사에 따라 분리.</li><li>공통화 요소<ul><li>게이트웨이<ul><li>인증, 레이트리미트, 로깅, 트래픽 관리, 비동기 처리</li></ul></li><li>인퍼런스를 위한 공통 라이브러리 (SDK)<ul><li>모델러 등의 협업 인터페이스 정의</li><li>http, grpc 라이브러리 제공</li><li>모델 디스커버리, 로깅, 헬스체크 고려 (?)</li></ul></li><li>이종의 환경을 디플로이하기 위한 시스템<ul><li>이종의 환경을 디플로이하기 위한 단일한 인터페이스</li></ul></li></ul></li></ul></li><li>MDS: 공통 모델 패키징<ul><li>요구사항<ul><li>ML 프레임워크 – 텐서플로, PyTorch -&gt; 베이스 이미지 제공</li><li>REST API -&gt; Decorator/Flask</li><li>CPU/GPU 환경 -&gt; GPU 환경을 위한 operator, 배치 처리 기능 추가</li><li>종속성/배포 문제로 인해 Docker -&gt; 모든 배포에 Docker 사용</li></ul></li><li>모델 서빙 클래스: 전처리, 인퍼런스, 후처리 코드를 decorator로 지정</li><li>모델 서빙 클래스 + 모델 파일로 이루어진 모델 패키지를 생성</li><li>mds는 모델 패키지의 서빙 클래스를 flask와 연동하여 서빙</li><li>배치 인퍼런스: 여러 리퀘스트를 한꺼번에 처리</li><li>멀티 모델 파이프라인</li></ul></li><li>DPLO: 공통 모델 배포<ul><li>요구사항<ul><li>CPU/GPU 클러스터 -&gt; 사내 주요 클러스터 오퍼레이터 구현</li><li>배포 단계 제어 및 이력 관리 -&gt; 선언적 배포 구성 파일</li><li>라우팅 자동화 -&gt; 엔드포인트 자동 등록</li></ul></li><li>모델 패키지를 S3에 업로드하고 DPLO에 배포 요청</li><li>DPLO는 패키지를 다운로드 받아서 이미지를 빌드하고 Docker Registry에 업로드</li><li>요청 받은 클러스터로 배포<ul><li>k8s 오퍼레이터 (NCC 클러스터 – 네이버 사내 컨테이너 클러스터), C3DL 오퍼레이터 (C3DL 클러스터 – 네이버 사내 딥러닝 플랫폼)</li></ul></li><li>클러스터의 엔드포인트 정보를 얻어 AIGW의 라우팅 정보를 업데이트</li><li>기술<ul><li>golang으로 작성</li><li>gRPC API 및 gRPC gateway로 REST API 노출</li><li>배포 요청은 protobuf로 정의</li></ul></li><li>선언 파일을 통한 배포<ul><li>Git을 통한 배포 제어 및 관리</li><li>배포 상태와 배포 선언 파일 사이의 변경 관리</li></ul></li><li>동적 엔드포인트 디스커버리<ul><li>새로운 인스턴스 배포/기존 인스턴스 재시작에 따른 엔드포인트 정보 업데이트</li><li>MDS는 Route provider (Consul)에 라우트 정보를 등록, AIGW는 Route provider로부터 엔드포인트 업데이트</li></ul></li></ul></li><li>AIGW: 공통 모델 라우팅<ul><li>nginx, istio 대신 직접 개발</li><li>라우팅 scheme: project/model/version<ul><li>project: 서비스, model: ML 기능, version: 버전</li><li>버전 사이에서는 weighted round robin, 하나의 버전 내에서는 round robin</li></ul></li><li>요청 미러링 기능<ul><li>서비스 중인 모델의 요청을 복제해서 신규 모델에 요청 실행 가능</li></ul></li><li>가중치 기반 라우팅<ul><li>카나리 배포, A/B 테스트를 위한 버전간 가중치 라우팅</li></ul></li><li>로그 유통<ul><li>기본적인 메트릭 전송</li><li>anomaly detection</li><li>사내 로그 저장/분석 플랫폼 활용</li><li>로그 시각화<ul><li>미러링된 요청 구분 가능</li></ul></li></ul></li><li>모델 서빙 모니터링<ul><li>모델 서버의 작동 여부</li><li>쓰루풋, 응답 코드, latency, connection 수 등의 메트릭 모니터링</li></ul></li></ul></li></ul></div></article></div></div>

The Last Mind

얼마 전 열렸던 DEVIEW 2020의 세션 중 하나인 ‘밑바닥부터 만드는 인공지능 서빙 플랫폼’ 발표를 듣고 그 내용을 요약합니다. 플랫폼 개발의 이유를 명확하게 설명하고 이로부터 이어지는 시스템의 설계 내용이 논리적으로 잘 맞아떨어져서 즐겁게 들을 수 있었던 발표였습니다. 마이크로서비스들의 배포와 서빙을 위한 플랫폼과 머신러닝 배포 및 서빙 플랫폼 사이에 기능적, 기술적으로는 연관관계가 많이 있는 반면에, 둘 사이에 사용자, 환경, 작업 흐름의 차이 때문에 현실적으로는 머신러닝에 국한된 프로덕트가 필요하다는 생각을 가지게 되었습니다.
시작
2019년 초 weight 파일 + 인퍼런스 코드 + flask 서버로 서빙 시작
지금은 각 모듈을 공통화
모델 공통화 동기
모델 수 증가 -> 서빙을 위한 엔지니어링 코스트 증가
지속적인 모델 학습과 배포: A/B 테스트, 로그를 저장하고 이를 통한 학습
사내시스템 연동: 유지보수가 잘 안되는 코드
협업 가능한 환경 구축: 엔지니어가 모델러로부터 받은 인퍼런스 코드를 재작성하는 엔지니어링 코스트. 모델러와 엔지니어의 관심사에 따라 분리.
공통화 요소
게이트웨이
인증, 레이트리미트, 로깅, 트래픽 관리, 비동기 처리
인퍼런스를 위한 공통 라이브러리 (SDK)
모델러 등의 협업 인터페이스 정의
http, grpc 라이브러리 제공
모델 디스커버리, 로깅, 헬스체크 고려 (?)
이종의 환경을 디플로이하기 위한 시스템
이종의 환경을 디플로이하기 위한 단일한 인터페이스
MDS: 공통 모델 패키징
요구사항
ML 프레임워크 – 텐서플로, PyTorch -> 베이스 이미지 제공
REST API -> Decorator/Flask
CPU/GPU 환경 -> GPU 환경을 위한 operator, 배치 처리 기능 추가
종속성/배포 문제로 인해 Docker -> 모든 배포에 Docker 사용
모델 서빙 클래스: 전처리, 인퍼런스, 후처리 코드를 decorator로 지정
모델 서빙 클래스 + 모델 파일로 이루어진 모델 패키지를 생성
mds는 모델 패키지의 서빙 클래스를 flask와 연동하여 서빙
배치 인퍼런스: 여러 리퀘스트를 한꺼번에 처리
멀티 모델 파이프라인
DPLO: 공통 모델 배포
요구사항
CPU/GPU 클러스터 -> 사내 주요 클러스터 오퍼레이터 구현
배포 단계 제어 및 이력 관리 -> 선언적 배포 구성 파일
라우팅 자동화 -> 엔드포인트 자동 등록
모델 패키지를 S3에 업로드하고 DPLO에 배포 요청
DPLO는 패키지를 다운로드 받아서 이미지를 빌드하고 Docker Registry에 업로드
요청 받은 클러스터로 배포
k8s 오퍼레이터 (NCC 클러스터 – 네이버 사내 컨테이너 클러스터), C3DL 오퍼레이터 (C3DL 클러스터 – 네이버 사내 딥러닝 플랫폼)
클러스터의 엔드포인트 정보를 얻어 AIGW의 라우팅 정보를 업데이트
기술
golang으로 작성
gRPC API 및 gRPC gateway로 REST API 노출
배포 요청은 protobuf로 정의
선언 파일을 통한 배포
Git을 통한 배포 제어 및 관리
배포 상태와 배포 선언 파일 사이의 변경 관리
동적 엔드포인트 디스커버리
새로운 인스턴스 배포/기존 인스턴스 재시작에 따른 엔드포인트 정보 업데이트
MDS는 Route provider (Consul)에 라우트 정보를 등록, AIGW는 Route provider로부터 엔드포인트 업데이트
AIGW: 공통 모델 라우팅
nginx, istio 대신 직접 개발
라우팅 scheme: project/model/version
project: 서비스, model: ML 기능, version: 버전
버전 사이에서는 weighted round robin, 하나의 버전 내에서는 round robin
요청 미러링 기능
서비스 중인 모델의 요청을 복제해서 신규 모델에 요청 실행 가능
가중치 기반 라우팅
카나리 배포, A/B 테스트를 위한 버전간 가중치 라우팅
로그 유통
기본적인 메트릭 전송
anomaly detection
사내 로그 저장/분석 플랫폼 활용
로그 시각화
미러링된 요청 구분 가능
모델 서빙 모니터링
모델 서버의 작동 여부
쓰루풋, 응답 코드, latency, connection 수 등의 메트릭 모니터링

Talk: DEVIEW 2020 밑바닥부터 만드는 인공지능 서빙 플랫폼

댓글