플레이스 AI 개발의 MLOps w/ Kubernetes
문서 시리즈
도입기에서 확장/최적화 단계로 가는 과도기인 (2021년 8월)시점에 작성된 문서임을 알려드립니다.
플레이스 AI 개발 부서 업무 범위
Experimental > Production
플레이스 AI개발 부서는 Experimental에서 Production까지 담당하고 있습니다. 서비스 응용 수준의 머신러닝 과제를 발굴하여 데이터 수집부터 모델링, 서빙까지 머신러닝 과제의 전체 프로세스를 개발하고 있습니다.
Experimental > Production Phase 용어는 Kubeflow의 ML workflow 설명을 기준으로 언급했습니다. https://www.kubeflow.org/docs/started/kubeflow-overview/#introducing-the-ml-workflow
부서 배경
초기 업무 전략: 효율, 효과
저희 팀은 올해에 신설되었습니다. 다른 AI 개발팀이나 신설팀과 마찬가지로 팀의 당위성을 빠르게 입증해야 했습니다. 초기에는 팀에 기반이 없는 상황이라 여러 비지니스 요구사항을 개발하면서 동시에 팀의 시스템을 구축해야 하는 상황이었습니다. 효율적이고 효과적인 업무 전략으로 팀이 지속할 수 있는 방안을 고민해야하는 상황이었습니다. 이러한 배경으로 MLOps에 대해 고민하게 되었습니다.
MLOps란?
DevOps (Development + Operations)를 시작으로 다양한 Ops개념이 생겨났습니다. 먼저 공통적으로 Ops란 무엇인지 살펴보고, 이 문서의 키워드인 ‘MLOps’를 정의 하겠습니다
개발의 여러 요소 중에 새로운 것 또는 비지니스 요구사항 외에도 반복적이고 공통적인 여러 요소가 있습니다. 이러한 요소를 실체화해서 새로운 부분을 지속가능 하게 하도록 하는 솔루션을 Ops로 생각해 볼 수 있습니다. 따라서 Ops는 보통 플랫폼 형태로 구현되고 적용됩니다.
여러 Ops를 구별하는 기준은 ‘새로운 것 또는 공통 요소를 무엇을 중심으로 볼 것인가?’ 하는 관점에 있다고 할 수 있습니다. MLOps(ML + Ops)는 새로운 요소를 머신러닝 모델링을 중심으로 봤을 때, 나머지 공통 요소를 MLOps의 관심사로 생각 볼 수 있습니다.
머신러닝 프로젝트의 개발 업무 요소
이 그림은 MLOps 와 함께 자주 인용되는 ‘머신러닝 시스템에서의 숨겨진 기술 부채’라는 논문에서 가져온 그림입니다. 가운데 검은 배경의 머신러닝 코드 부분은 머신러닝 시스템 전체에서는 작은 부분만 차지한다는 메시지를 담고 있습니다. 실제 프로덕션에 머신러닝 개발 결과를 적용하기 위해서는 머신러닝 자체 이외에도 많은 구성 요소를 고려해야 합니다.
MLOps 전략
MLOps의 구성 요소 : 데브옵스 + 데이터 엔지니어링 + 머신러닝
MLOps는 세부적으로 ‘데브옵스 + 데이터 엔지니어링 + 머신러닝’ 3가지로 구분할 수 있습니다. 팀 환경에 따라 이 3가지의 방향성이나 우선 순위, 도입한 플랫폼 등은 다를 수 있습니다.
Ops는 팀 문화에 맞춰 도입
위 표는 저희 팀에서 도입한 내용을 정리한 내용입니다.
- DevOps: cloud-native로 방향성을 정하고 k8s 플랫폼을 선택하여 운영하고 있습니다. 사내 k8s 플랫폼인 n2c를 활용하여 여러 구성 요소들을 배포, 운영 하고 있습니다.
- Data Engineering: hadoop 기반으로 빅데이터를 처리 할 수 있는 환경을 구성했습니다. offline storage(hdfs)와 대규모 데이터 처리(spark)는 사내 hadoop 클러스터인 c3s를 활용하고 있습니다. 그 외에도 kafka를 활용하여 stream pipeline을 구성하고 model artifact나 기타 데이터 공유를 위해 사내 network storage 플랫폼인 nubes와 ceph를 활용하고 있습니다.
- ML(Machine Learning): ML에서 Ops요소로는 GPU 자원을 쉽게 활용할 수 있도록 GPU 클러스터 자원을 추상화 하는 부분이 있었습니다. 기본적으로 k8s를 기반으로 운영하고 있지만 경우에 따라 다른 사내 플랫폼인 c3dls과 nsml도 활용하고 있습니다. (ray framework도 같이 검토하고 있습니다.) model serving은 torchserve 프래임워크를 사용하고 있습니다.
MLOps 플랫폼을 선정할 때, 저희가 활용할 수 있었던 주요 사내 플랫폼의 특징은 아래와 같습니다.
k8s 플랫폼
- 사내 k8s 클러스터이자 플랫폼인 n2c 활용. (적은 인력으로 자체 k8s 클러스터를 운영하는게 부담.)
- namespace-scope의 권한으로만 작업 (cluster-scope의 작업 제한).
- n2c 플랫폼에서 elasticsearch와 kafka cluster를 쉽게 구축할 수 있도록 k8s operator 제공해주고 있음.
hadoop 플랫폼
- 사내 hadoop 클러스터이자 플랫폼인 c3s 활용.
- yarn 자원 할당에 지연 시간이 있으나 1~2분 내로 할당되고 있고, 클러스터 공용 큐의 컴퓨팅 자원이 충분함.
기술 스택
머신러닝 프로젝트의 전체 프로세스를 개발하기 때문에 다양한 기술을 활용하고 있습니다.
k8s-hosted container
복잡한 초기 셋업과 의존성 관리
앞선 기술 스택에서 보셨듯이 전체 ML 파이프라인을 위한 환경에는 많은 구성 요소들이 있습니다. 의존성 관리나 버전 관리 요소가 많기 때문에 프로젝트나 개발자간 파편화 되기 쉽습니다.
k8s, network storage, airflow 등 여러 연관 플랫폼에 접근하거나 GPU 자원을 할당받고 사용하기 위한 모든 내용들을 로컬에 환경을 일일이 셋업해야 한다면 새로운 팀원이 참여하거나 프로젝트를 공유할 때에 환경을 셋업하기 부담스럽습니다. 또한 로컬과 배포 환경이 각각 셋업하는 방식에 달라져 개발과 운영 환경의 차이로 인한 파편화도 증가하게 됩니다.
통합 개발 환경 구성요소
- Dev: 코드 실행 환경 구성
- Data: 데이터 중심의 처리/분석 환경 구성
- Modeling: 모델링 중심의 실험 환경 구성
개발 환경의 여러 구성 요소를 앞서 구분한 3가지 기준으로 정리해볼 수 있습니다. 첫째로 개발한 코드를 시스템 환경에 맞춰서 실행시킬 수 있는 환경이 필요합니다. 두번째로 데이터를 분석하기 위해 데이터를 모으고 대규모의 데이터를 병렬 처리를 요청할 수 있는 환경이 필요합니다. 마지막으로 모델링을 위해 GPU 리소스를 할당받고, 머신러닝 프레임워크를 활용할 수 있는 일관된 환경이 필요합니다.
개발 환경을 팀원간 합의하고 구성할 때, production 배포 환경과 유사하게 구성하고 여러 프로젝트에서 동일한 환경으로 반복 개발할 수 있는 환경을 고려했습니다.
sandbox
팀내 개발자의 개발 환경을 어떻게 통합하여 쉽게 제공하고 관리할 수 있을까 고민했습니다. 저희 팀만의 기술 요소와 정책을 실체화 해서 제공하도록 했습니다. 이를 위해 container, k8s, vscode, web editor를 활용했습니다.
sandbox: k8s-hosted container
저희는 통합 개발 환경을 docker 이미지로 구성해서 개인별로 k8s에 배포하고, 배포된 컨테이너에 개발자가 접속해서 개발 할 수 있도록 했습니다. 컨테이너로 패키징하여 기본적인 환경을 쉽게 제공하고 관리할 수 있었습니다. 또한 프로덕션 환경과 동일하게 k8s내에 개발 환경을 구성하여 환경에 따른 파편화가 최소화 되었습니다.
sandbox: 로컬 환경에서 접근 방법
개발 도구는 기본적으로 vscode를 활용했습니다. vscode에서 제공하는 원격 컨테이너 연동 기능(vscode remote container)으로 클라이언트 로컬 개발 환경과 유사한 경험으로 개발할 수 있었습니다. 그리고 브라우저를 통해서 접근할 수 있는 vscode server와 jupyter notebook 을 추가했습니다. 클라이언트에서는 vscode나 브라우저만 있으면 되기 때문에, 클라이언트 환경을 가볍게 구성할 수 있었습니다.
Network Storage
n2c(사내 k8s 플랫폼) 에서 활용한 네트워크 스토리지 타입은 크게 두 가지가 있습니다. 한번에 하나의 pod에만 마운트할 수 있는 타입인 cephrbd가 있고 여러 pod에 마운트할 수 있는 타입인 cephfs와 nubes가 있습니다. 상황에 따라 두 가지 스토리지 타입을 모두 활용했습니다. (k8s의 PersistentVolume의 AccessModes 와 관련) 이러한 네트워크 스토리지는 사내 k8s 플랫폼인 n2c 환경에서 파일시스템으로 마운트할 수 있어서 쉽게 활용할 수 있었습니다.
추가로 여러 network storage를 브라우저나 URL로 쉽게 관리하고 공유할 수 있도록 filebrowser를 활용했습니다.
Network Storage 활용 예 — sandbox
개인 개발 환경에도 여러 네트워크 스토리지를 연동해서 목적에 맞게 활용하고 있습니다. 여러 컨테이너 간 공유하는 데이터는 여러 pod에서 동시에 마운트 할 수 있는 cephfs나 nubes를 활용하고 홈디렉토리와 같이 개인별로 독립적인 데이터는 ReadWriteOnce 접근 모드만 가능한 cephrbd를 활용하고 있습니다.
Container Layer 구성
다음은 컨테이너 레이어 구성 입니다. 이미지 레이어에는 자주 변하지 않는 기본적인 환경만 구성하도록 했습니다. 그리고 소스코드나 빌드 결과물은 writable layer 로 마운트 했습니다. 이러한 구성으로 반복적인 변경과 배포에서도 동일한 이미지를 활용할 수 있었고, 코드 변화에 따라 도커 이미지를 반복적으로 빌드하는 과정을 생략할 수 있었습니다.
k8s기반의 Infrastructure as Code
복잡한 플랫폼 셋업
- 복잡한 플랫폼 구성 요소
- 복잡한 의존성 관리
다음은 플랫폼 도입 방식에 대한 내용 입니다. 저희 부서의 MLOps는 다양한 기술 스택을 포괄하고 있고, 여러 플랫폼을 활용해야 했습니다. 하지만 플랫폼 요소 하나도 도입하는게 어려울 때가 많았습니다. 예를 들어 airflow 을 구축하려면 내부적으로 웹, 스케쥴러, 워커 클러스터, 워커관리자, 비동기큐, 데이터베이스를 구성해야 합니다. 이런 구조를 파악해서 각 요소를 배포하고 연동하는 작업은 복잡합니다. 또한 플랫폼에서 요구하는 의존 패키지를 설치하고 버전을 맞추는 일은 번거롭습니다.
Infrastructure as Code
Infrastructure as code(IaC)라는 개념이 있습니다. 코드로 인프라를 프로비셔닝하고 관리하는 개념을 말합니다. Ansible이나 Terraform이 이와 관련된 대표적인 솔루션입니다. 이러한 솔루션에는 플랫폼을 프로비셔닝을 할 수 있는 오픈소스와 저장소가 있습니다.
Infrastructure As Code 솔루션 별 코드 저장소
- Ansible: https://galaxy.ansible.com/
- Terraform: https://registry.terraform.io/
k8s package 활용
사내 n2c(k8s)에서 오퍼레이터를 통해 제공해주는 플랫폼 뿐만 아니라, 다른 kubernetes package를 활용해서도 플랫폼을 구축했습니다. k8s 패키지 매니저로는 기본적으로 helm를 활용하였고, 경우에 따라 kustomize도 활용했습니다.
K8S기반의 Infrastructure as Code 도입
IaC 오픈소스 도입 효과
- 양질의 기술 부채
- 오픈소스에는 소프트웨어 개발과 인프라 운영 측면에서 고려된 경험이 축적 (Best Practices)
- 갚기 좋은 (혹은 갚지 않아도 될) 제 1금융권 같은 양질의 기술 부채
- 세부사항은 점진적으로 커스터마이징 하여 최적화
2. 플랫폼 구성 요소를 하나의 패키지로 관리
- 세부적인 네트워크 토폴로지 구성, 설정을 위한 비용 감소
- 여러 요소를 하나의 그룹 단위로 패키징
- 공통 차트를 활용하여 인프라 설정 내용 재사용
Ansible, Terraform과 비슷하게 k8s 생태계에도 artifact hub(https://artifacthub.io/)라는 저장소가 있습니다. 저희는 이 저장소의 오픈소스 패키지를 활용하여 플랫폼을 k8s에 구축했습니다. 저희 부서의 MLOps 범위가 넓고, 개발 리소스가 부족한 상황이었기 때문에 필연적으로 기술 부채가 많을 수 밖에 없습니다. IaC 도입의 큰 장점은 경험이 축적된 모범사례를 초기값으로 가질 수 있어서 부채를 갚기 쉽거나 혹은 갚지 않아도 되는 것으로 개선할 수 있다는 점이었습니다.
Workflow Engine 선정
k8s로 workflow를 수행할 수 있는 플랫폼을 이와 같이 검토했었습니다. 저희는 전체 ML 파이프라인 범위를 담당하고 있기 때문에, 솔루션이 일반적인 app개발, 데이터 엔지니어링, 머신러닝 작업 모두에 적합해야 했습니다. 또한 자동화 요소가 다양하기 때문에 유연하게 workflow를 구성할 수 있어야 했습니다. 이러한 이유로 저희는 workflow 자동화 솔루션으로 airflow 선택했습니다.
Airflow — KubernetesPodOperator
airflow의 KubernetesPodOperator API를 활용하여 task를 k8s의 pod 단위로 실행하도록 했습니다.
GPU 환경은 별도 클러스터로 구성되어 있고, 저희도 namespace를 여러 개로 구성했기 때문에, 다른 클러스터나 네임스페이스에 배포할 수 있도록 k8s 클라이언트 인증 설정을 추가했습니다.
Notebook 형태의 소스 개발과 배포 (papermill)
데이터 엔지니어링에서는 notebook 형태의 개발 코드가 있습니다. 또한 실험 단계에서 개발한 notebook을 자동화해야 할 경우도 있습니다.
저희는 papermill 도구를 활용했습니다. 먼저 notebook 코드를 정리하고 파라미터를 선언하여 코드를 정리합니다. 사용자 인터렉션이 없는 자동화 환경에서 notebook을 실행시키고 런타임 파라미터를 주입했습니다. datasource, datamart, feature engineering, batch prediction 등의 구간에서 활용하고 있습니다.
시스템 구조
이 도식은 시스템 전체 구조입니다. 위쪽에 스토어가 배치되어 있고, 아래쪽에는 머신러닝 파이프라인에 맞춰 각 구간에 맞는 구성 요소를 배치한 그림입니다.
시스템 구조 상세 설명 (다음 문서에서 계속…)
다음에 공유 드릴 문서에서는 사용자 추천 과제을 사례로 머신러닝 파이프라인을 설명합니다. 사례와 함께 시스템 구조를 설명합니다.
마무리
Ops는 팀의 문화, 성숙도, 추구하는 방향성, 담당자의 역량등을 고려해서 상황에 맞는 솔루션을 찾아야 합니다. 저희 팀은 사내 플랫폼과 오픈소스를 활용하여 적은 자원으로 최대의 효과를 만들기 위해, 해당 시점에 판단할 수 있는 가장 적합한 솔루션을 선별했습니다. 이 문서에서는 사내 저희 부서 상황에 맞는 한가지 사례을 소개해드렸다고 생각합니다. 따라서 이 문서의 선택 기준과 결과는 팀에 따라 다를 수 있는 내용일 것입니다.
저는 아직 MLOps에 대해 배우고 있으며, 부서 시스템도 최적화하고 수정해야할 부분이 많으므로 부족한 부분이 있다면 공유해주셨으면 좋겠습니다. 이 글이 ML 시스템을 구성하거나 MLOps를 도입하려는 분들 또는 이 분야에 관심 있는 분들에게 작게나마 도움이 되었으면 합니다.
기타 용어 설명
- k8s: kubernetes 약자, k + 8(ubernete: 8글자) + s
- pai: 플레이스 AI개발 부서 코드명
- n2c(또는 ncc): NAVER 사내 k8s 플랫폼 (Naver Container Cluster)
- c3s: NAVER 사내 hadoop 플랫폼 (Common Central Cluster + Secure)
- nubes: NAVER 사내 글로벌 오브젝트 스토리지 플랫폼
- ceph: 오픈소스 Ceph 기반 NAVER 사내 분산형 스토리지 시스템
채용 공지
NAVER 플레이스 AI개발에서는 같이 일할 동료 개발자를 찾고 있습니다.
