이미 지난 포스트를 통해 수많은 기업들의 현재 머신러닝 도입 상황과 비즈니스 가치, 앞으로의 머신러닝 업계의 동향 역시 살펴 보았습니다.
지난 문서 링크
머신러닝을 시작하는 개발자를 위한 - (1) 머신러닝 용어정리, 분류부터 MLOps까지
머신러닝을 시작하는 개발자를 위한 - (2) 머신러닝 서비스/프레임워크/툴킷 분류 및 전체 개발 흐름
머신러닝을 시작하는 개발자를 위한 - (3) 우리 개발자가 머신러닝을 해야 하는 이유는?
머신러닝을 시작하는 개발자를 위한 - (4) 2021년의 ML Trend - MLaaS와 MLOps(Machine Learning + DevOps)
2021년 머신러닝과 인공지능(AI) 트렌드 - MLaaS (서비스로의 머신러닝)
이 문서에서는 한단계 더 깊이, 많은 머신러닝을 도입한 선도 기업들의 여러 고민과 기술을 통한 해결 방안에 대해서 알아보도록 하겠습니다.
기존의 머신러닝 개발 패턴
익히 잘 알고 있는 구조입니다. 이 글을 보고 있는 DS(Data Scientist)나 개발자 역시, 현재도 이렇게 잘 개발을 하고 있을 것이고, 모델 빌드부터 배포까지, 충분히 잘 사용할 수 있는 검증된 패턴입니다.
하지만, 머신러닝 작업의 패턴이 다변화되고 고도화되면서, 이 패턴에서 많은 문제점이 발견되었죠
12가지의 머신러닝을 먼저 도입한 기업들의 고민
모든 기업의 문제는 "효율"과 "비용"이 최대의 과제입니다. 머신러닝을 먼저 도입하고 사용한 기업들은 어떤 고민이 있었고, 어떻게 이 문제들을 해결했을까요?
1. 데이터셋
개발자가 Git과 같은 SCM을 이용해 코드 관리를 하듯, 데이터 역시 Versioning해 관리할 필요가 있습니다. 예를 들어, 아무리 트레이닝을 진행해도 과거에 진행한 특정 데이터셋보다 더 성능이 좋아지지 않는 경우가 종종 생깁니다. 이전 버전의 데이터셋으로 모델을 재학습하고, 이 데이터셋을 기준으로 다시 조금씩 데이터셋을 보완해 가며, git의 branch처럼 조금씩 다른 버전의 데이터셋을 늘리면서 모델 성능을 향상 시킬 수 있습니다.
아마도 대부분의 경우 날짜 단위 폴더로 구별해 사용하거나 시퀀스를 이용해 계속 복사본을 중복 생성해 관리하는 분들도 있을겁니다.
하지만, 데이터셋의 크기가 수백기가로 커진다면? 하루에도 여러번 트레이닝을 수행하는데, 관리 해야할 버전이 한두개가 아니라면 어떻게 데이터셋을 버전별로, 효율적으로 잘 관리 할 수 있을까요?
2. 머신러닝 트레이닝 작업 실행(Run) 기록 및 metric 결과 관리
DS는 매번 머신러닝 트레이닝을 수행할 때마다 조금씩 변경하면서 트레이닝을 실행합니다. 데이터셋을 변경하거나, 알고리듬을 바꿔보거나, 등등의 시도를 하죠. 이 과정을 DS는 보통 팀원이 쓰는 공유 문서에 수작업으로 기록하거나 메일 등으로 공유합니다. 수많은 트레이닝을 수행하면서 이 과정을 반복해야 하죠. 수작업에서 누락되기도 하고, 다양한 metric이 누락되기도 합니다.
트레이닝 실행들을 어떻게 자동으로 잘 기록하고 유지할 수 있을까요? 단순 기록 뿐만 아니라, 트레이닝 완료 후, evaluation에 사용할 테스트 데이터셋을 이용해 최종 evalution을 수행하고, 그 결과도 함께 이 트레이닝 실행과 함께 자동으로 기록할 수 있을까요?
3. 머신러닝 트레이닝 코드 단일화 / 통일
DS는 자신의 머신에서 개발하고, 개발한 코드를 그대로 모델 트레이닝에 사용하기 위해 실행합니다. 하지만, 대부분의 경우 개발환경과 트레이닝 환경의 불일치가 발생하죠. GPU 머신은 더합니다. 한번 Python 패키지나 CUDA/CuDNN - Deep Learning 툴킷 패키지 버전 이슈에 빠지면 그날 하루 날리는거죠.
대부분의 경우, Docker를 이용하지만, 수많은 docker 환경 관리와 docker image 접근 등 보안 문제에 빠지기 시작합니다.
표준화된 머신러닝 또는 Deep learning 트레이닝과 어플리케이션 배포를 위한, 미리 잘 구성된 최적화된 image를 사용하거나, 기존 이미지에 나의 모듈을 추가한 custom docker image를 이용해 트레이닝 / 배포에 사용할 수는 없을까요?
4. 하이브리드 머신러닝 트레이닝 환경(On-prem과 클라우드)
트레이닝 머신을 로컬의 ML GPU 머신에서 잘 사용하고 있습니다. 하지만, 사내의 GPU 머신은 한정된 자원이죠.
네, 회사의 GPU 머신은 제한되어 있습니다. 트레이닝 돌리는 중인데, 옆팀에서 물어보죠.
트레이닝 언제끝나요? 우리팀 모델도 만들어야 하는데
기본적으로 모델 빌드 과정은 수행이 오래 걸리고, 한번 수행해서 끝나는게 아니라, 만들어진 모델에 대한 evalution 과정을 통해, 여러 데이터셋/파라미터로 계속 모델 빌드/테스트를 수행해야 합니다.
프로젝트 기간 중에는 또 열심히 사용되다가 프로젝트 완료되면 GPU 머신을 아무도 쓰지 않는 유휴 상황이 발생하는 경우도 있죠. 네, 답은 정해져있죠. 결국 클라우드 GPU 머신 쓰면 되는거 아니냐?
하지만, 직접 회사에서 운영하는 GPU 머신과, 클라우드 GPU 머신간 metric 관리가 쉽지 않고, 클라우드와 On-prem간 컴퓨팅 환경만 바꾸고, 모든 트레이닝 결과는 하나로 관리하는 "하이브리드" 머신러닝 모델 트레이닝은 수 없을까요?
- 로컬의 GPU를 쓰다가 대규모의 GPU 트레이닝 등은 클라우드 등을 사용해 트레이닝
- 로컬 실행이나 클라우드 실행 양쪽 모두 모니터링 / eval 결과를 한눈에 확인
5. 최신의 머신러닝 / 딥러닝 기술 적용
하루가 멀다하고, 새로운 머신러닝 알고리듬과 새로운 논문, 수많은 벤더들이 머신러닝 기술들을 쏟아놓습니다.
예를들어, AutoML이나 Auto Hyper Parameter tuning같은 기술을 이용하면, 머신러닝 트레이닝 과정이 매우 편리해지고 쉬워지는 것은 모두 잘 알고 있지요. 네, 다양한 머신러닝/딥러닝의 신기술을 사용하고 싶습니다. 하지만, 이걸 직접 구현하고 쓰는건 불가능에 가깝죠. 특히, 기업이 원하는 수준의 보안, 안정성, 모니터링, 대쉬보드 기능 등을 직접 구현해 맞추기는 불가능에 가깝습니다.
이런 우리의 일을 쉽게 만들어줄 최신 머신러닝 기술들을 어떻게 쉽게 가져다 사용할 수 있을까요?
6. 모델관리
머신러닝을 우리가 수행하는 이유는 이 "모델"을 잘 만들기 위해서죠. 그런데, 만들어진 모델을 어떻게 관리하시나요? 이 모델이 어느 데이터셋으로, 어느 환경에서, 어느 알고리즘으로, 어떤 하이퍼 파라미터로 만들어졌는지 알고 있으신가요?
네, 어쩌면, 모델 파일명에 이 모델에 대한 정보를 넣어 길게 작성하는 경우도 있습니다만, 부족하죠.
- 모델 메타데이터 정보 확인(사용된 데이터셋, Compute 환경, 트레이닝 실행환경, 기록/검색, 버전관리)
머신러닝 트레이닝이 완료되면 모델을 안전한 저장소에 등록하고 모델의 버전별 다양한 메타데이터 정보와 함께 저장해 관리할 수 없을까요?
7. 모델 배포의 문제
DS 조직과 어플리케이션 개발 / 어플리케이션 운영 조직의 역할과 책임이 모두 다릅니다.
모델이 생성되면, 만들어진 모델을 개발팀이 이미 만들어 둔, Restful API application으로 규격화된 방법(docker 이미지로 말아서)으로 모델을 묶어 함께 배포하거나, 유연한 기본 web app부터 대규모 서비스가 가능하도록, 운영팀이 제공하는 Kubernetes cluster로 자동 배포할 수는 없을까요?
타 조직에서 배포를 관리할 경우, 특정 권한을 가진 사용자(DevOps 파이프라인 등)만 모델 저장소에 접근 / 다운로드 후 application에 포함해 재배포 하도록 수동/자동 구성할 수 없을까요?
8. 데이터셋 엑세스 관리
데이터셋 역시 접근 제어(Access Control) 구현이 필요합니다.
DS는 전체 데이터에 대해서 접근이 가능하며, 읽고 쓰기가 가능하지만, 예를 들어, 수작업으로 라벨링을 하는 외부 업체나 다른 조직의 사람들은, 특정 디렉토리의 파일만(라벨링할 파일) 접근해 해당 디렉토리에 대해서만 읽기/쓰기가 필요할 수 있다.
이러한 데이터셋 접근제어를 POSIX 스타일 접근제어나, RBAC(role-based access control)을 어떻게 구현할 수 있을까요?
9. 데이터 보존 계획(Data Retention Plan)
Data retention plan 이 필요합니다. 예를 들어, 1년이 지난 데이터는 거의 모델 트레이닝에 재사용 될 가능성이 희박하므로, 자규칙을 이용해 자동으로, cold storage로 1년 만기된 파일을 옮기고, 3년이 지난 데이터는 완전 삭제하는 등의 정책을 회사에서 구현해야 합니다.
법적으로 개인정보가 포함된 트레이닝 데이터에 대해서 역시 해당 국가 또는 지역에서 요구하는 법령에 맞춰 retention plan을 수립해야 합니다.
이러한 기업이 요구하는 Data Regention Plan을 어떻게 구현할 수 있을까요?
10. 다양한 클라우드 리소스에 대한 키/암호 관리
보안은 기업의 최우선 고려사항입니다. 클라우드 리소스 보안도 물론입니다. 개인정보가 포함된 저장소, 머신러닝 서비스, 연결된 데이터베이스, 배포할 Kuberenets 클러스터 접근 계정 등 머신러닝 전체 과정에서 수 많은 리소스에 대한 키와 암호를 관리해야 합니다. 이 중, 하나라도 유출되면 대형 사고이며, 심지어 개발 리소스가 아닌 Stage/Production 리소스들은 개발자나 DevOps 관리자, 다른 DS들에게도 조차 노출되어서는 안됩니다.
어떻게 이런 암호나 키를 Key Vault로 관리하고 사용할 수 있을까요?
11. Monitoring과 alert / 대쉬보드
- Logging, Monitoring, Alert, Dashboard
데이터 Ingestion부터, 트레이닝 과정은 물론 / ML 어플리케이션 배포와 운영에서 발생하는 모든 로그를 기록하고, 특정 조건(심각한 오류)이 발생할 경우 alert를 보내거나, 트레이닝 완료된 모델의 metric을 이전 버전의 모델과 비교해 DS들만을 위한 dashboard에서 chart로 표시하거나, 비즈니스 팀에서 관심 많은 현재의 클라우드 사용량 정보 등은 필요에 맞게 비즈니스 팀을 위한 dashboard로 구성하고, dashboard를 각 팀, DS팀, Dev팀, 비즈니스팀 등에 맞춰 접근 제어 / 제공할 수 있을까요?
12. MLOps - 머신러닝 DevOps
기업들이 요구하는 위와 같은 일련의 ML 작업들을 데이터가 도착 할때마다, 또는 하루에 한번, 다양한 형태의 트리거를 통해 모든 작업을 DevOps 처럼, 데이터셋에서 model을 빌드하고, 배포(human approval 포함), 모니터링 까지 파이프라인으로 어떻게 자동화/효율화 할 수 있을까요?
이번 MLaaS 시리즈에서 차근차근 파헤쳐 보도록 하겠습니다.
참고링크
머신러닝을 시작하는 개발자를 위한 - (1) 머신러닝 용어정리, 분류부터 MLOps까지
머신러닝을 시작하는 개발자를 위한 - (2) 머신러닝 서비스/프레임워크/툴킷 분류 및 전체 개발 흐름
머신러닝을 시작하는 개발자를 위한 - (3) 우리 개발자가 머신러닝을 해야 하는 이유는?
머신러닝을 시작하는 개발자를 위한 - (4) 2021년의 ML Trend - MLaaS와 MLOps(Machine Learning + DevOps)
