MLOPs 시리즈는 플러스제로 에서 사용중인 MLOPs 기술들과 MLOPs를 사용하여 데이터의 관리와 AI 알고리즘의 빠른 실험, 그리고 최종적으로는 AI의 Micro-service화 까지 다룰 예정입니다.
이번 1편에서는 플러스제로에서 사용중인 ML(머신러닝) / DL(딥러닝) 기술 스택과 데이터 관리에 대한 내용을 소개합니다.
MLOPs란 용어는 ML과 OP(운영)을 의미하는 Operation의 계념이 합쳐진 단어입니다. 개발자 분들과 협업을 해보신 경험이 있다면 개발자 분들께서 말씀하시던 DevOps와 비슷한 의미로 받아들이실 수 있습니다.
최근 데이터 중심의 인공지능이 강조되면서, 데이터와 ML 알고리즘의 관리 측면이 더 강조되고, 데이터와 알고리즘의 실험을 통한 결과를 실제 서비스로 빠르게 배포가 가능하도록 하는 파이프라인이 강조되고 있습니다.
실제로 과거 ML을 적용하는 프로젝트의 80~90%는 실패하였다는 리포트도 있습니다. 전 세계적으로 가장 많은 데이터를 확보하고 있는 기업 중에 하나인 Google은 “왜 ML프로젝트가 실패 하였을까?” 라는 질문에 답을 찾기 위해 많은 연구를 하고 있으며, 다양한 이유 중에서, ML프로젝트 이후 유지 보수와 관련된 내용이 큰 영향을 주었습니다.
Google외 에도 많은 기업들이 MLOPs에 대한 이론을 확립하고 적용하기 위해 노력하고 있습니다.
앞서 말씀드렸듯, 이번 1편에서는 플러스제로 에서 사용 중인 MLOPs 기술 스택과 데이터 관리에 대해서 소개합니다.
Google에서 제시한 13개의 컴포넌트들 중에서 1편에서는 4개의 컴포넌트와 부가적인 내용을 살펴보겠습니다.
- Configuration
- Data Collection
- Automation
- +개발 인프라 및 사용 기술 스택
1. Configuration
플러스제로 에서는 ML 시스템의 설정과 소스코드의 설정은 YAML 또는 Json파일로 관리를 합니다. 추가적으로 Data 설정과, ai-model의 설정을 분리하여 관리하고 있습니다.
인프라와 관련해서는 Terraform을 사용하여 infrastructure as code를 적용 하려 하고 있습니다. 그러나 현재 연구팀에서는 고성능 컴퓨팅이 가능한 자원이 한정적이고, 연구팀 내부의 인프라는 Terraform을 사용할 정도로 거대해지지 않아, 도커만으로도 충분히 활용 할 수 있어, 개발이 완료된 프로젝트에 대해서는 컨테이너화를 통해서 Docker-Compose를 사용하여 인프라를 관리하고 있습니다.
서비스와 관련해서는 컨테이너화된 서비스를 도커 컴포즈를 통하여 테스트 용도로 사용하고 있습니다. 추후에는 컨테이너의 배포와 스케일링이 용이한 쿠버네티스 (k8s)의 사용을 고려하고 있으며 해당 인프라는 Cloud 서비스의 완전관리형 쿠버네틱스 (GKS, EKS) 서비스를 사용하여 배포할 예정입니다.
아마, ML과 MLOPs에 관심있으신 분들은 컨테이너간의 오케스트레이션은 어떻게 진행하고 있는지 질문을 주실 것 같습니다. 자세한 내용은 3번 Automation에서 살펴보실수 있습니다.
2. Data Collection
플러스제로 에서 연구 및 개발 중인 다양한 내용 중에서 ML과 관련된 프로젝트의 데이터는 자연어 데이터와 Google Analytics를 활용한 웹페이지 로그 데이터를 볼 수 있습니다. 이번 시리즈에서는 자연어 데이터 (텍스트 데이터)에 초점을 맞추었습니다.
외부 데이터는 다양한 원천 소스를 사용하고 있습니다. 마케팅과 관련된 내용과 트렌드에 대한 데이터는 API와 크롤러를 통해 수집하고 있습니다. 수집되는 데이터는 원천 소스마다 상이하여 정형화 하기에 어려움이 있어 NoSQL 데이터베이스를 활용하여 데이터를 저장하고 있습니다. 추후에 데이터를 사용하기 위해 최소한의 규제를 가지고 Collection과 Document를 디자인 하였습니다.
데이터 수집을 위한 소스코드는 내부 Repository에 저장되며, master 브랜치에 변경이 일어났을시에 컨테이너 빌드 및 푸시를 진행합니다.
연구팀의 Configuration에 맞추어 데이터 수집을 위한 설정은 YAML파일을 통해 소스코드가 구동됩니다.
다양한 원천소스에서 데이터를 확보하려면, 각 원천소스에 해당하는 Configuration.YAML을 통해 구동합니다.
추가적으로 원천 데이터의 효율적인 관리를 위해서 NoSQL에서 각 그룹별로 데이터베이스를 개별로 관리합니다.
데이터 수집이 구동할 때에는, 해당 원천소스에 해당하는 데이터베이스를 우선 조회하여, 데이터의 중복을 최소화 하였습니다. 추후 ML알고리즘의 학습시, 몇 줄의 코드로 해당 내용을 제거 할 수도 있겠지만, 플러스제로 연구팀에서는 데이터의 수집 과정에서도 좋은 데이터가 쌓이기를 지향하고 있기에 데이터를 더욱 정교하게 수집하려 노력하고 있습니다.
3. Automation
MLOPs의 자동화는 DevOps의 CI/CD (지속 통합, 지속 배포)와 비슷한 개념으로 받아들여집니다. 하지만 MLOPs에서는 CI / CD 뿐만 아니라, CT (지속 학습) 라는 내용이 추가 됩니다. 또한 자동화를 통하여 우발적으로 발생 할 수 있는 개발자의 Human-Error를 최소화 하는 것을 추구합니다. 플러스제로의 연구팀은, CI (Continuous Integration)를 통한 협업 개발 통합과 CD (Continuous Delivery & Deployment)를 통한 개발 코드 배포, 그리고 CT (Continuous Training)를 통하여 AI 알고리즘의 지속 학습을 통한 성능 저하 방지를 자동화 합니다. 물론 해당 내용은 MLOPs 컴포넌트중 Monitoring과도 연관이 있지만, 해당 내용은 추후에 소개드리겠습니다.
소스코드의 구동은 워크플로우 툴로 많이 사용하는 Airflow를 사용하였습니다. Airflow를 사용하는 이유는 추후 연구팀의 인프라가 커짐에 따라 쿠버네티스 (k8s)로의 변경을 하여도, 빠르게 적용이 가능하고, 이전 동작하는 Task가 데이터 파이프라인과 밀접한 관련이 있어서 확장성을 고려하여 선택하였습니다. Airflow DAG를 통하여 데이터의 수집, 정제, AI학습, 검증, 배포와 같은 작업들을 자동화하여 CT를 적용하고 있습니다.
Conclude
이렇게 플러스제로의 연구팀에서는 데이터 중심적인 생각과 함께 효율적인 AI를 개발하여 플러스제로의 파트너에게 0을 더합니다.