오픈소스 AI Platform인 Kubeflow를 도입 후 Pipeline 쪽 기능을 주로 사용하면서 얻은 경험, 느낀점을 적어 보려고 합니다.Kubeflow는 Kubernetes 상에서 머신러닝(ML) 워크플로우를 구축하고 배포하기 위한 오픈소스 플랫폼입니다.이름에서 알 수 있듯이, Kubeflow는 'Kubernetes'와 'TensorFlow'를 결합하여 탄생했으며,원래는 Google이 Kubernetes에서 TensorFlow 작업을 원활하게 수행할 수 있도록 개발했습니다.현재는 다양한 머신러닝 프레임워크를 지원하며, Kubeflow는 ML 모델의 개발, 훈련, 배포 및 관리에 필요한 모든 요소를 통합하여 제공합니다.Kubernetes의 이점을 머신러닝에 통합Kubeflow는 Kubernetes의 확장성, 가용성, 관리 용이성을 활용하여 ML 워크플로우를 지원합니다.Kubernetes의 컨테이너 오케스트레이션 기능을 통해 ML 작업을 효율적으로 배포하고 관리할 수 있습니다.데이터 준비, 모델 training, 하이퍼파라미터 튜닝, 모델 serving 등 머신러닝의 전체 라이프사이클을 관리하는 통합 환경을 제공합니다.이를 통해 데이터 사이언티스트, 머신러닝 엔지니어, 데이터 엔지니어들이 협력하여 효율적으로 작업할 수 있습니다.모든 환경에서 일관된 운영Kubeflow는 클라우드, 온프레미스, 하이브리드 환경에서 모두 동일하게 동작하도록 설계되었습니다.이를 통해 특정 환경에 구애받지 않고, 동일한 ML 워크플로우를 구축하고 실행할 수 있습니다.다양한 머신러닝 프레임워크와 도구를 지원하여 사용자가 원하는 구성 요소를 선택하고 확장할 수 있도록 합니다.Kubeflow의 주요 구성 요소복잡한 머신러닝 워크플로우를 정의하고 자동화하기 위한 도구입니다.파이프라인을 구성하여 데이터 전처리, 모델 훈련, 검증 및 배포 등 일련의 작업을 순서대로 실행할 수 있습니다.파이프라인은 코드로 정의되며, 다양한 컴포넌트를 재사용할 수 있어 관리와 유지 보수가 용이합니다.학습된 모델을 Kubernetes 클러스터에서 실시간으로 서빙할 수 있는 기능을 제공합니다.이는 모델을 API 엔드포인트로 노출시켜 애플리케이션에서 쉽게 사용할 수 있도록 합니다.KFServing은 스케일링, 롤백, 모니터링 등의 기능을 통해 모델 서빙을 안정적으로 관리합니다.하이퍼파라미터 튜닝 및 자동 머신러닝(AutoML)을 위한 도구입니다.Katib을 사용하면 다양한 하이퍼파라미터 조합을 자동으로 탐색하여 최적의 모델 성능을 찾을 수 있습니다.TensorFlow 및 PyTorch와 같은 특정 머신러닝 프레임워크를 Kubernetes에서 실행할 수 있도록 지원합니다.이를 통해 대규모 분산 학습이 가능해지며, 클러스터 리소스를 효율적으로 사용할 수 있습니다.Jupyter Notebooks 환경을 Kubernetes에서 호스팅하여 데이터 사이언티스트가 브라우저를 통해 데이터를 탐색하고, 모델을 개발할 수 있도록 합니다.이러한 노트북 환경은 쉽게 확장 가능하며, Kubeflow의 다른 구성 요소

함께 구매하면 좋은 상품이에요! - 장바구니 추천 개발기 2부안녕하세요. 컬리 데이터서비스개발팀에서 일하고 있는 백엔드 개발자 최재형, 김수지, 데이터 엔지니어 이상협, ML 엔지니어 구국원입니다. 이전 글에서는 장바구니 추천 모델을 개발하는 과정에서 고민한 내용을 설명드렸습니다. 그리고 이러한 고민 끝에 만들어진 모델의 부가가치를 실제 컬리의 엔드 유저에게 전달하기 위해서 실시간 서빙 아키텍처를 구축할 필요가 있있었습니다. 그 과정에서 역시나 많은 고민과 시행착오가 있었고, 현재 구축한 아키텍처에 기반하여 성공적으로 실시간 서빙을 수행하고 있습니다. 따라서 본 글에서는 컬리가 어떻게 실시간 서빙 아키텍처를 구축하고 운영하고 있는지를 공유 드리고자합니다. 추천 모델을 실시간으로 서빙하기 위한 아키텍처를 나타내 보았습니다. 이 아키텍쳐에 대해서 간단하게 말씀드리면, 추천 모델 API는 AWS와 GCP의 시스템을 활용하였고 그 중 AWS의 EKS 클러스터에서 대부분의 추천 모델 관련 작업이 이루어졌습니다. 학습과 분석에 필요한 데이터는 BigQuery에 적재되어 있고, 운영시 중요하게 모니터링 해야할 부분들은 Datadog과 Slack을 활용해 감지하고 알럿을 보냅니다. 이 아키텍쳐를 서비스 API, 모델 API, MLOps, 모니터링, 배포 과정 파트로 나눠서 각각의 구성 요소들의 세부사항들을 설명드리겠습니다. 서비스 API는 모델 API 앞단에서 컬리 백엔드의 트래픽을 받아 냅니다. 서비스 API는 유저에게 더 좋은 추천 서비스를 제공하고, 추후 서비스의 확장성을 확보하기 위해 구축하였으며 다음과 같은 기능을 수행합니다.특히 모든 분석과 모니터링은 정확한 로깅에서 시작하기 때문에 로깅은 서비스 API의 가장 중요한 요소라고 할 수 있습니다. 서비스 API에는 팀내에서 자체 구축한 로깅 모듈을 활용하고 있는데, 이 모듈을 통해서 API에서 발생한 로그들을 파일 형태로 내립니다. 그 후 생성된 로그 파일을 기 구축된 로깅시스템을 통해 Kafka 토픽으로 전송하고 카프카 토픽에 쌓인 메시지는 Nifi를 활용해 실시간으로 빅쿼리로 적재됩니다. 위 과정을 수행하기 위해 필요한 Kafka나 Nifi와 같은 데이터 연동 인프라는 기존에 저희 팀에서 구축해서 운영 중인 상황이었기 때문에 이를 그대로 활용할 수 있었습니다. 그 결과, 현재 빅쿼리에서 거의 실시간에 가까운 로그를 확인할 수 있습니다.모델 API를 구축하기 위해서는 먼저 서빙 프레임워크를 선정해야 했습니다. 서빙에 사용되는 오픈 소스들은 각자의 장단점이 명확하기 때문에 결국 저희 상황에 맞는 프레임워크를 선정하는 것이 중요했습니다. 여러 후보들을 비교 했는데, 최종적으로는 BentoML과 TorchServe를 후보로 두고 의사결정 하였습니다. 먼저, BentoML은 사용 편의성이 높아서 컬리의 다른 ML API를 서빙하는데 활용하고 있었고 운영 하면서 축적된 노하우가 있었기 때문에 후보로 선정하였습니다. 그리고 Torchserve는 Pytorch 모델을 서빙할 수 있는 프레임워크인데, 마침 개발된 모델이 Pytorch 기반이기도 하고 준수한 성능 보일 것으로 예상해서 후보로 선정하였습니다.그리고 최종 선택을 위해 각 서빙 프레임워크로 랩핑한 API를 띄워보고 성능 테스트를 진행하였습니다. 성능 테스트는 Locust를 활용하였고, 아래와 같은 그래프를 확인 할 수 있었습니다.대략적인 비교를 해보고자 세부적인 튜닝 없이 진행하였는데, 응답 시간 측면에서 torchserve가 더 좋은 지표를 보여주었습니다. 따라서 최종적으로 서빙 프레임워크로 Torchserve를 활용하기로 했고, 성능 최적화를 위한 세부적인 튜닝을 진행하였습니다.Torchserve를 튜닝하는 최종 목표는 낮은 응답시간(지연시간)을 달성하는 것이었습니다. 이를 위해 Torchserve 공식 문서나 관련 아티클을 참고하여 몇 가지의 속성들과 인프라적 튜닝 포인트를 확인 했습니다. 그 내용들은 다음과 같습니다.정리하면, 낮은 지연시간을 달성하기 위해선 부차적인 옵션 설정보다는 CPU Clock Speed가 중요한 특성이라는 것을 경험적으로 확인했습니다. 그 이유는 TorchServe는 요청을 들어온 순서대로 Queue에 넣고 FIFO 방식으로 처리하는 방식으로 구현되어 있으므로 선행하는 요청을 빠르게 처리하는 것이 전체 성능 향상에 가장 큰 영향을 미치기 때문입니다. 다시 말해, 높은 CPU Clock Speed를 확보하는 것이 결국 낮은 응답시간을 달성하는 핵심 요인이라는 것이므로 최종적으로는 CPU �Clock에 특화된 인스턴스 중에서 더 우수한 성능을 보이는 인스턴스를 선정하여 API를 배포하였습니다.ML 모델 API는 일반적인 애플리케이션과는 다르게 배포가 자주 일어날 수 있습니다. 왜냐하면 API가 운영되고 있는 중에 모델은 빈번하게 업데이트가 발생하기 마련이고, 이를 반영하여 새 모델로 API를 변경해줘야 하기 때문입니다. 이렇게 새 버전으로 배포하는 중에 다운타임이 발생하게 된다면 서비스 품질에 큰 영향을 줄 수 있기 때문에 무중단 배포가 필요합니다. 일반적으로 Kubernetes가 제공하는 Rolling Update, Blue/Green, Canary 등의 배포 전략을 활용하면 이론적으로는 무중단 배포가 되는게 맞지만, 실제로 배포 테스트를 해보았을 때 다운타임이 일부 발생하는 것을 확인되었습니다.이런 중단이 발생하는 주된 이유는 EKS외에 AWS의 다른 서비스들을 활용하는 것, 그리고 Gracefulshutdown이 적용되지 않았기 때문입니다. AWS EKS에서 애플리케이션이 트래픽을 받기 위해서는 Ingress를 생성하면서 AWS의 Application Load Balancer(이하 ALB)를 활용하게 되는데 이 때 ALB Ingress의 TargetGroup의 연결이 끊어지고 새로 연결되는 과정에서 다운타임이 발생할 수 있습니다.ALB가 생성된 후에 TargetGroup이 정상적으로 연결이 되면 그 시점부터 트래픽은 정상적으로 들어오게 됩니다. 하지만 모델의 업데이트로 새 버전의 pod가 생성되었고 이 pod로 트래픽을 보내려고 한다면, 기존의

당근 ML 인프라팀에서는 머신러닝 모델을 효과적으로 다양한 서비스에 적용하기 위해 노력하고 있어요.이전 블로그 글(Kubeflow 파이프라인 운용하기)에서 언급했던 것처럼 당근마켓은 Google Kubernetes Engine(GKE)에서 Kubeflow Pipeline(KFP)을 설치해 적극 활용하고 있었는데요. 2023년 초기부터 Vertex AI Pipelines를 도입하고, 마이그레이션 해왔어요. 그리고 지난 10월에 드디어 전체 파이프라인을 Vertex AI Pipelines에 모두 옮기면서 KFP 및 이를 운영하기 위한 GKE 자원을 모두 제거했어요.이번 글에서는 당근이 어떻게 TFX와 함께 Vertex AI Pipelines를 활용하고 있는지 공유해 보려 해요.Vertex AI PipelinesVertex AI Pipelines는 머신러닝 파이프라인을 Serverless 방식으로 관리 및 실행할 수 있는 Google Cloud Platform 제품이에요. ML 워크플로우에 필요한 데이터 전처리, 모델 훈련 / 평가, 배포 등등 머신러닝 프로젝트가 밟아야 하는 여러 단계를 Vertex AI 및 GCP 제품들로 구성하고, 자동화할 수 있어요.출처: https://cloud.google.com/vertex-ai/docs/start/introduction-unified-platform2024년 1월 기준으로 Vertex AI Pipelines는 아래 두 가지 인터페이스를 지원하고 있어요.Kubeflow Pipelines(KFP) SDKTensorFlow Extended(TFX) SDK기존에 잘 활용하고 있던 TFX SDK를 Vertex AI Pipelines와 함께 사용 중이에요.Managed Service인 Vertex AI 도입 이후 Kubernetes Cluster 운영 또한 필요하지 않아요. 그 때문에 운영보다 ML 워크플로우에 필요한 요소들을 개발하는 데 집중할 수 있어요.TensorFlow ExtendedTFX는 프로덕션 머신러닝 파이프라인을 위한 end-to-end 플랫폼이에요. 2019년에 완전히 오픈소스화되었고, 컴포넌트 단위로 ML 워크플로우를 개발한 후 여러 환경(Apache Beam, Dataflow, Kubeflow, Airflow) 등에서 실행 가능해요. 물론 데이터 수집/변환, 학습, 배포 등을 위해 잘 작성된 컴포넌트도 같이 제공되고 있어요.TFX에 대한 좀 더 자세한 사항은 이전 블로그 글(TFX와 함께 머신러닝 파이프라인 개발하기)을 참고해 주세요.생산성 및 편의성머신러닝 모델이 실제 환경에서 잘 동작하려면 모니터링, 신뢰도와 유효성 검사 등 프로덕션 레벨의 요구사항을 잘 만족해야 해요. 이를 위해 TensorFlow Extended(TFX)를 적극 활용하고 있지만, TFX에서 제공하기 힘든 당근에서 필요로 하는 요구사항에 대해서는 ML 인프라팀이 나서야 해요.당근은 각 서비스 조직이 정형화된 ML 인프라/MLOps 모듈들을 개발하는 데에 시간을 쏟지 않고, 담당하시는 서비스에 필요한 개발에 집중하길

안녕하세요. 왓챠 ML팀에서 머신러닝 엔지니어로 일하고 있는 찰스입니다.지난 글에서는 왓챠 추천 시스템을 컨테이너 환경으로 이전하면서 발생했던 여러 고민들을 어떻게 해결했는지 살펴보았습니다. 그 이후 왓챠 ML 팀에서는 왓챠와 왓챠피디아에 사용하는 추천 모델을 다양한 요구 조건에 맞춰 고도화했고, 다뤄야 하는 모델과 데이터가 지속적으로 늘어나게 되었습니다. 이러한 환경 변화에 발맞추어 분산되어 있는 데이터를 통합하여 관리하고 다양한 모델 학습 과정을 최적화하며 학습된 모델을 서비스에 효율적으로 반영하고 모니터링할 수 있는 MLOps에 대한 필요성을 느끼게 되었습니다. 이 글에서는 왓챠 추천 시스템에 MLOps를 어떻게 적용했는지 살펴보고 그 과정에서 발생한 여러 고민들을 어떻게 해결했는지 적어보고자 합니다.들어가기 앞서이 글에서는 MLOps를 적용하면서 있었던 고민과 개선점을 주로 다룰 예정이기 때문에 각 서비스의 설정 과정이나 상세한 기술 이야기를 다루지 않습니다.왓챠 추천 서비스의 MLOps 도입이라는 큰 주제를 하나의 글로 작성하기에는 적합하지 않아 두 개의 글로 나누어 작성할 예정입니다. 이번 글에서는 추천 모델 학습을 위한 ML 파이프라인 및 실험 환경 구축이라는 주제를 다루고, 다음 글에서는 학습된 추천 모델을 서비스에 반영하기 위한 추론 서버 개발이라는 주제로 이야기할 예정입니다.왓챠 추천 서비스는 쿠버네티스(Kubernetes) 내 여러 오브젝트와 Public Cloud 서비스인 AWS(Amazon Web Service)의 다양한 서비스를 활용합니다. 이 글에서는 여러 AWS 서비스와 쿠버네티스 오브젝트가 언급될 예정이고, 독자도 이에 대한 기본 지식이 어느 정도 있다고 가정합니다.MLOps란?최근 ML 분야에 모델 아키텍처나 학습 패러다임의 발전이 거듭되면서 각기 다른 학습 파이프라인을 갖는 다양한 모델을 쉽고 빠르게 서비스하기 위한 방법과 도구가 필요해졌습니다. MLOps는 이러한 필요성을 기반으로 데이터 수집부터 데이터 전처리, 모델 학습 및 평가, 모델 서빙 및 모니터링에 이르는 일련의 과정을 엔드 투 엔드 파이프라인으로 자동화하여 효율적인 모델 개발 및 운영을 도와줍니다.또한, ML팀과 DevOps팀 간의 불필요한 커뮤니케이션 비용을 최소화하고 나아가서는 ML팀이 직접 그들의 모델을 직접 관리하고 운영 및 모니터링할 수 있도록 합니다. 이러한 MLOps 도입을 위해 필요한 여러 컴포넌트를 간단히 살펴보도록 하겠습니다.a. 머신러닝 파이프라인머신러닝 파이프라인(ML Pipeline)은 실 서비스 환경에서 학습한 모델을 서비스에 적용하기까지 일련의 과정을 파이프라인으로 구성하는 것을 말합니다. 머신러닝 파이프라인은 다음과 같은 작업에 대해 자동화가 필요합니다.데이터 수집다양한 원천 데이터로부터 필요한 데이터를 수집할 수 있어야 합니다.2. 데이터 처리수집한 데이터를 모델이 요구하는 형태로 가공할 수 있어야 합니다.불필요한 데이터나 이상치를 제거할 수 있어야 합니다.필요하다면, Feature store를 활용하여 학습