🌈 Kurly만의 MLOps 구축하기 - 초석 다지기

MLOps는 최근 많은 회사들이 관심을 가지고 있는 분야입니다. 개념을 다루는 글은 많이 있으나, 이제 실무를 어떻게 하는지 궁금해집니다. 이번에 공유드린 글은 컬리에서 MLOps 구축하는 과정을 담은 글입니다. MLOps 중 처음으로 GPU 사용 환경에 대한 글입니다 ✨️ 추천드리고 싶은 분 - 회사의 MLOps 케이스가 궁금하신 분 - 쿠버네티스 기반에서 GPU를 사용하는 Use Case가 궁금하신 분 🎁 요약 Karpenter - AWS에서 만들고 운영중인 오픈소스 - 쿠버네티스의 워커 노드 오토 스케일링을 담당하는 오픈소스 - 불필요한 Worker Node를 정리하는 기능도 존재함 - AWS EKS는 ASG(Auto Scaling Group)와 Launch Template을 사용해 worker node를 그룹핑해 Node Group으로 관리하는 기능을 제공함 가상 케이스(AWS EKS의 동작 방식) - 쿠버네티스에서 현재 노드 내에 Pod이 가득찼고, 더 배포할 수 없는 상황 - 새로운 pod 생성 요청이 들어옴 - kube-scheduler는 신규 pod을 배치할 노드를 선정함 => 노드 선정 전까진 Pod이 Pending 상태 - 노드 선정에 실패하면 Node Group의 ASG 값 중 Desired Capacity를 하나 늘리고 워커 노드 개수를 증가시킴 - AWS는 ASG에 의해 desired capacity 값을 읽어 EC2 워커 노드를 배포함 Karpenter의 동작 방식 - Cloud Provider와 무관하게 동작 - Karpenter는 신규 Pod의 상태를 확인하고 필요하면 워커노드의 배포와 삭제를 직접 수행함. kube-scheduler를 대신해 pod을 특정 워커노드로 바인딩하는 요청도 수행함 - 위에 가상 케이스를 동일하게 적용하면, 어떤 타입에 배포할지는 Karpenter의 Custom Resource인 Provisioner에 의해 결정됨 - Provisioner에 의해 새 노드가 배포된 후 Read 상태가 되면 직접 Pod을 새로운 워커 노드에 배포될 수 있도록 바인딩 요청함 AWS EKS와 Karpenter의 차이점 - Karpenter는 Auto Scaling 할 때 직접 처리하고, CA는 Cloud Provider가 제공하는 기능을 연계해 더 오래 걸림 Karpenter의 주요 개념 - Watching : unschedulable한 Pod을 계속 확인함 - Evaluating : 스케줄링에 제약이 없는지 확인 - Provisioning : 요구사항에 맞는 노드에 Pod을 배포 - Removing : 더 이상 노드가 없으면 삭제 Provisioner - Custom Resource에 대해 작성된 내용 - 제약사항이나 노드가 필요없다고 판단할 설정, timeout 등을 설정함 Karpenter GPU 세팅 팁 - NVDP : Nvidia device plugin for Kubernetes를 설치해야 함 (데몬 셋에 설치) - Deprovisioning - 1. Affinity -> Label을 활용 - Deprovisioning - 2. Consolidation -> KArpenter의 CRD 버전 업그레이드 필요