VAR-As-A-Service는 MLOps 접근 방식으로, 통계 모델과 기계 학습 모델 배포 파이프라인의 통합 및 재사용을 위한 것입니다. 이는 다양한 통계 및 기계 학습 모델, 기존 DAG 도구를 사용하여 구현된 데이터 파이프라인, 클라우드 기반 및 대체 온프레미스 솔루션을 사용하는 스토리지 서비스와 관련된 실험을 나타내는 일련의 기사 중 두 번째입니다. 이 기사에서는 기계 학습 모델에도 적용 가능하고 사용되는 접근 방식으로 모델 파일 스토리지에 중점을 둡니다. 구현된 스토리지는 AWS S3 호환 객체 스토리지 서비스로서의 MinIO를 기반으로 합니다. 또한 이 기사에서는 대체 스토리지 솔루션에 대한 개요를 제공하고 객체 기반 스토리지의 이점을 강조합니다.
시리즈의 첫 번째 기사(시계열 분석: VARMAX-As-A-Service)는 수학적 모델로서의 통계 및 기계 학습 모델을 비교하고, statsmodels라는 Python 라이브러리를 사용하여 경제 예측을 위한 VARMAX 기반 통계 모델의 종단 간 구현을 제공합니다. 모델은 Python Flask와 Apache 웹 서버를 사용하여 REST 서비스로 배포되며, 도커 컨테이너에 패키징됩니다. 애플리케이션의 고수준 아키텍처는 다음 그림에 도시되어 있습니다.
모델은 pickle 파일로 직렬화되어 REST 서비스 패키지의 일부로 웹 서버에 배포됩니다. 그러나 실제 프로젝트에서 모델은 버전 관리되며 메타데이터 정보와 함께 보안이 유지되며 훈련 실험은 기록되어 재현 가능하게 유지되어야 합니다. 또한 구조적 관점에서 애플리케이션과 함께 파일 시스템에 모델을 저장하는 것은 단일 책임 원칙에 어긋납니다. 좋은 예는 마이크로서비스 기반 아키텍처입니다. 모델 서비스를 수평으로 확장하면 모든 마이크로서비스 인스턴스마다 물리적인 pickle 파일의 자체 버전이 모든 서비스 인스턴스에 복제됩니다. 이는 또한 모델의 여러 버전을 지원하려면 REST 서비스와 그 인프라를 새로 배포하고 재배포해야 한다는 것을 의미합니다. 이 기사의 목표는 모델을 웹 서비스 인프라에서 분리하고 다양한 버전의 모델로 웹 서비스 로직의 재사용을 가능하게 하는 것입니다.
구현에 들어가기 전에, 통계 모델과 그 프로젝트에서 사용된 VAR 모델에 대해 몇 마디를 해보겠습니다. 통계 모델은 수학적 모델이며, 기계 학습 모델도 마찬가지입니다. 둘 사이의 차이에 대한 자세한 내용은 시리즈의 첫 번째 기사에서 확인할 수 있습니다. 통계 모델은 일반적으로 하나 이상의 확률 변수와 다른 비확률 변수 사이의 수학적 관계로 지정됩니다. 벡터 자기회귀 (VAR)는 시간에 따라 변하는 여러 양들 사이의 관계를 포착하기 위해 사용되는 통계 모델입니다. VAR 모델은 다변량 시계열을 허용하여 단일 변수 자기회귀 모델(AR)을 일반화합니다. 제시된 프로젝트에서는 두 변수에 대한 예측을 수행하도록 모델을 훈련시킵니다. VAR 모델은 경제학과 자연 과학에서 자주 사용됩니다. 일반적으로 모델은 프로젝트에서 Python 라이브러리 statsmodels 뒤에 숨겨진 방정식 시스템으로 표현됩니다.
VAR 모델 서비스 애플리케이션의 아키텍처는 다음 그림에 도시되어 있습니다.
VAR 런타임 구성 요소는 사용자로부터 전송된 매개변수를 기반으로 실제 모델 실행을 나타냅니다. 이는 REST 인터페이스를 통해 MinIO 서비스에 연결하여 모델을 로드하고 예측을 실행합니다. 첫 번째 문서의 솔루션과 비교할 때, 어플리케이션 시작 시 VARMAX 모델이 로드되고 역직렬화되는 것과는 달리, VAR 모델은 예측이 트리거될 때마다 MinIO 서버에서 읽힙니다. 이로 인해 추가적인 로딩 및 역직렬화 시간이 발생하지만, 매 실행마다 배포된 모델의 최신 버전을 갖는 이점도 있습니다. 또한, 이는 모델의 동적 버전 관리를 가능하게 하여 외부 시스템과 최종 사용자에게 자동으로 접근 가능하게 합니다. 이는 후반부 문서에서 보여줄 것입니다. 로딩 오버헤드로 인해 선택한 스토리지 서비스의 성능이 매우 중요하다는 점에 유의하세요.
그러나 왜 MinIO와 일반적으로 객체 기반 스토리지일까요?
MinIO는 쿠버네티스 배포를 위한 기본 지원을 제공하는 고성능 객체 스토리지 솔루션으로, 아마존 웹 서비스 S3와 호환되는 API를 제공하며 모든 핵심 S3 기능을 지원합니다. 제시된 프로젝트에서 MinIO는 단일 MinIO 서버와 단일 드라이브 또는 스토리지 볼륨으로 구성된 Standalone Mode에 있으며, Linux에서 Docker Compose를 사용합니다. 확장된 개발 또는 프로덕션 환경의 경우 Deploy MinIO in Distributed Mode라는 기사에서 설명하는 분산 모드를 선택할 수 있습니다.
자세한 설명은 여기와 여기에서 찾을 수 있지만, 몇 가지 스토리지 대안에 대해 간단히 살펴보겠습니다.
- 로컬/분산 파일 저장: 로컬 파일 저장은 첫 번째 문서에서 구현된 솔루션으로, 가장 간단한 옵션입니다. 계산과 저장이 동일한 시스템에서 이루어집니다. PoC 단계나 단일 버전의 모델을 지원하는 매우 단순한 모델에 적합합니다. 로컬 파일 시스템은 저장 용량이 제한적이며, 훈련 데이터 세트와 같은 추가 메타데이터를 저장하고자 할 때 더 큰 데이터 세트에는 적합하지 않습니다. 복제나 자동 확장이 없으므로 로컬 파일 시스템은 가용성, 신뢰성, 확장 가능한 방식으로 작동할 수 없습니다. 수평 확장을 위해 배포되는 각 서비스는 모델의 자체 복사본을 가지고 있습니다. 또한 로컬 저장소의 보안은 호스트 시스템의 보안과 같습니다. 로컬 파일 저장소의 대안으로는 NAS(네트워크 첨부 저장소), SAN(스토리지 영역 네트워크), 분산 파일 시스템(하둡 분산 파일 시스템(HDFS), 구글 파일 시스템(GFS), 아마존 엘라스틱 파일 시스템(EFS), 애저 파일)이 있습니다. 로컬 파일 시스템에 비해 이러한 솔루션은 가용성, 확장성, 회복력을 갖추고 있지만 복잡성이 증가하는 비용이 수반됩니다.
- 관계형 데이터베이스: 모델의 이진 직렬화로 인해 관계형 데이터베이스는 테이블 열에서 모델의 blob 또는 이진 저장소를 제공하는 옵션을 제공합니다. 소프트웨어 개발자와 많은 데이터 과학자들은 관계형 데이터베이스에 익숙하기 때문에 해당 솔루션은 간단합니다. 모델 버전은 추가 메타데이터와 함께 별도의 테이블 행으로 저장될 수 있으며 데이터베이스에서 쉽게 읽을 수 있습니다. 단점은 더 많은 저장 공간이 필요하고 이는 백업에 영향을 준다는 것입니다. 데이터베이스에 많은 양의 이진 데이터가 있으면 성능에도 영향을 미칠 수 있습니다. 또한 관계형 데이터베이스는 데이터 구조에 대한 일부 제약 조건을 부과하므로 CSV 파일, 이미지 및 JSON 파일과 같은 비정형 데이터와 같은 모델 메타데이터를 저장하는 것이 복잡해질 수 있습니다.
- 객체 스토리지: 객체 스토리지는 꽤 오래 전부터 존재했지만, 아마존이 2006년에 Simple Storage Service (S3)를 통해 처음으로 AWS 서비스로 제공하면서 혁신을 일으켰다. 현대의 객체 스토리지는 클라우드에 원래부터 내장되어 있으며, 다른 클라우드들도 곧 자체 제품을 시장에 출시했다. 마이크로소프트는 Azure Blob Storage를 제공하고, 구글은 Google Cloud Storage 서비스를 갖추고 있다. S3 API는 개발자들이 클라우드의 스토리지와 상호작용하기 위한 사실상의 표준이며, 퍼블릭 클라우드, 프라이빗 클라우드 및 프라이빗 온프레미스 솔루션을 위한 S3 호환 스토리지를 제공하는 여러 회사가 있다. 객체 스토어의 위치에 관계없이 RESTful 인터페이스를 통해 액세스된다. 객체 스토리지는 디렉토리, 폴더 및 기타 복잡한 계층적 구조의 필요성을 제거하지만, 끊임없이 변경되는 동적 데이터에는 적합하지 않다. 객체를 수정하려면 전체 객체를 다시 작성해야 하지만, 직렬화된 모델과 모델의 메타데이터를 저장하기에는 좋은 선택이다.
A summary of the main benefits of object storage are:
- 거대한 확장성: 객체 스토리지의 크기는 기본적으로 무한하므로, 단순히 새 장치를 추가함으로써 데이터를 엑사바이트까지 확장할 수 있다. 객체 스토리지 솔루션은 분산 클러스터로 실행될 때 최고의 성능을 발휘한다.
- 복잡성 감소: 데이터는 평면 구조에 저장된다. 복잡한 트리나 파티션(폴더나 디렉토리 없음)의 부재로 인해 파일을 검색하는 것이 더 쉬워진다. 정확한 위치를 알 필요가 없기 때문이다.
- 검색 가능성: 메타데이터는 객체의 일부로서, 별도의 애플리케이션 없이도 쉽게 검색하고 탐색할 수 있게 해줍니다. 사용자는 소비, 비용, 자동 삭제, 보존 및 계층화에 대한 정책과 같은 속성과 정보로 객체에 태그를 지정할 수 있습니다. 기본 스토리지의 평면 주소 공간(모든 객체가 하나의 버킷에만 있고 버킷 안에 버킷이 없음) 덕분에, 객체 스토어는 수십억 개의 객체 중에서도 빠르게 객체를 찾을 수 있습니다.
- 내구성: 객체 스토리지는 자동으로 데이터를 복제하고 여러 장치 및 지리적 위치에 저장할 수 있습니다. 이는 중단으로부터 보호하고 데이터 손실로부터 안전하게 하며 재해 복구 전략을 지원하는 데 도움이 될 수 있습니다.
- 단순성: REST API를 사용하여 모델을 저장하고 검색하는 것은 거의 학습 곡선이 없으며 마이크로서비스 기반 아키텍처에 통합하기에 자연스러운 선택입니다.
이제 VAR 모델을 서비스로 구현하고 MinIO와의 통합을 살펴볼 때입니다. 제시된 솔루션의 배포는 Docker 및 Docker Compose를 사용하여 단순화됩니다. 전체 프로젝트의 구성은 다음과 같습니다:
첫 번째 기사에서와 마찬가지로, 모델 준비는 특정 var_model.py라는 이름의 Python 스크립트로 작성되어 있으며, 이 스크립트는 GitHub 저장소에 위치해 있습니다:
- 데이터 로드
- 데이터를 훈련 및 테스트 데이터셋으로 분할
- 내생변수 준비
- 최적의 모델 파라미터 p 찾기(각 변수의 첫 p 라그를 회귀 예측변수로 사용)
- 최적의 매개변수로 모델 인스턴스화
- 인스턴스화된 모델을 pickle 파일로 직렬화
- pickle 파일을 MinIO 버킷에 버전화된 객체로 저장
이러한 단계들은 최신 데이터로 새 모델 버전을 훈련시킬 필요에 따라 트리거되는 워크플로우 엔진(예: Apache Airflow)에서 작업으로 구현될 수도 있습니다.DAG와 MLOps에서의 응용 사례는 다른 기사에서 다룰 예정입니다.
var_model.py에서 구현된 마지막 단계는 S3에 있는 버킷에 pickle 파일로 직렬화된 모델을 저장하는 것입니다. 객체 스토리지의 평면 구조 때문에 선택된 형식은 다음과 같습니다:
<버킷 이름>/<파일_이름>
그러나 파일 이름의 경우, 계층적 구조를 모방하기 위해 순방향 슬래시를 사용할 수 있으며, 빠른 선형 검색의 장점을 유지합니다. VAR 모델을 저장하는 규칙은 다음과 같습니다:
models/var/0_0_1/model.pkl
여기서 버킷 이름은 models, 파일 이름은 var/0_0_1/model.pkl이며 MinIO UI에서는 다음과 같이 보입니다:
이는 다양한 유형의 모델 및 모델 버전을 구조화하는 매우 편리한 방법이면서도 평면 파일 저장소의 성능과 단순성을 유지합니다.
모델 버전 관리는 모델 이름의 일부로 구현됩니다. MinIO는 파일 버전 관리도 제공하지만, 여기서 선택한 접근 방식에는 몇 가지 이점이 있습니다:
- 스냅샷 버전 지원 및 덮어쓰기
- 의미 버전 관리 사용 (제한 사항 때문에 점이 ‘_’로 대체됨)
- 버전 관리 전략에 대한 더 큰 제어 권한
- 특정 버전 관리 기능에 대한 기본 저장 메커니즘의 분리
모델이 배포되면 Flask를 사용하여 REST 서비스로 노출하고 docker-compose를 사용하여 MinIO 및 Apache 웹 서버를 실행하여 배포합니다. Docker 이미지 및 모델 코드는 전용 GitHub 저장소에서 찾을 수 있습니다.
마지막으로, 애플리케이션을 실행하는 데 필요한 단계는 다음과 같습니다:
- 애플리케이션 배포:
docker-compose up -d - 모델 준비 알고리즘 실행:
python var_model.py(MinIO 서비스가 실행 중이어야 함) - 모델이 배포되었는지 확인: http://127.0.0.1:9101/browser
- 모델 테스트:
http://127.0.0.1:80/apidocs
프로젝트 배포 후, Swagger API는 <host>:<port>/apidocs (예: 127.0.0.1:80/apidocs)를 통해 접근 가능합니다. VAR 모델에 대한 하나의 엔드포인트가 다른 두 개의 엔드포인트와 함께 VARMAX 모델을 노출합니다:
내부적으로 서비스는 MinIO 서비스에서 로드된 디셈라이징된 모델 피클 파일을 사용합니다:
요청은 다음과 같이 초기화된 모델에 전송됩니다:
제시된 프로젝트는 단계별로 추가 기능과 함께 확장할 수 있는 단순화된 VAR 모델 워크플로입니다:
- 표준 직렬화 형식을 탐색하고 피클을 대체 솔루션으로 교체
- Kibana 또는 Apache Superset과 같은 시계열 데이터 시각화 도구 통합
- 시계열 데이터를 Prometheus, TimescaleDB, InfluxDB 또는 S3와 같은 객체 스토리지와 같은 시계열 데이터베이스에 저장
- 데이터 로딩 및 데이터 전처리 단계를 포함하여 파이프라인 확장
- 파이프라인의 일부로 메트릭 보고서 포함
- Apache Airflow 또는 AWS Step Functions 또는 Gitlab 또는 GitHub와 같은 더 표준적인 도구를 사용하여 파이프라인 구현
- 통계 모델과 머신 러닝 모델의 성능과 정확성을 비교합니다
- 인프라스트럭처-애스 코드를 포함하여 종단 간 클라우드 통합 솔루션을 구현합니다
- 다른 통계 및 ML 모델을 서비스로 노출합니다
- 모델의 버전 관리와 실제 저장 메커니즘을 추상화하는 모델 저장 API를 구현하고, 모델 메타데이터와 학습 데이터를 저장합니다
이러한 미래의 개선 사항은 차후 기사와 프로젝트의 초점이 될 것입니다. 이 기사의 목표는 S3 호환 저장 서비스 API를 통합하고 버전이 관리되는 모델을 저장할 수 있게 하는 것입니다. 해당 기능은 곧 별도의 라이브러리로 추출될 예정입니다. 제시된 종단 간 인프라 솔루션은 프로덕션에 배포하고 시간이 지남에 따라 CI/CD 프로세스의 일부로 개선될 수 있으며, MinIO의 분산 배포 옵션 또는 AWS S3로 대체하여 사용할 수 있습니다.
Source:
https://dzone.com/articles/time-series-analysis-var-model-as-a-service