이번 글에서 다룰 MLOps 라이프사이클은 앞으로 할 실습 내내 계속 나오는 흐름이다. 그래서 이 흐름에 나오는 개념들은 제대로 이해하고 넘어가야 한다. 단계마다 하나씩 꼼꼼히 짚어 나가 보자.1. MLOps 라이프사이클ML 프로젝트는 문제를 정하고, 데이터를 모아 분석하고, 모델을 학습시켜 평가한 뒤, 배포해서 지켜보는 순서로 돈다. 이 흐름을 MLOps 라이프사이클(수명주기)이라고 부른다. 크게 모델을 만드는 실험 단계(문제 정의부터 모델 평가까지)와, 만든 모델을 서비스에 올려 지켜보는 운영 단계(배포와 모니터링)로 나뉜다.예시: 신분증 종류를 알아보는 모델 이 글에서는 신분증 사진을 보고 주민등록증, 운전면허증, 여권 중 무엇인지 알아보는 모델을 예로 든다. 스터디 실습에서도 신분증을 다룬다. M..

CloudNet@ 가시다님의 MLOps 스터디에서 「머신러닝 플랫폼 엔지니어링」을 공부하며 정리한 글이다.들어가며요즘은 업무 대부분을 AI와 함께 한다. 코드를 짜고 문서를 쓰고 장애 원인을 찾을 때도 AI에게 먼저 물어본다. 내가 하던 일 중 일부는 이미 AI가 대신하고 있고, 앞으로는 일상에서도 업무에서도 AI와 떼려야 뗄 수 없을 것 같다. 그러다 보니 AI를 더 잘 쓰려면 모델이 안에서 어떻게 만들어지고 운영되는지도 알아야겠다는 생각이 들었다. 모델을 만들고 운영하는 과정을 다루는 분야가 MLOps다. 찾아보니 DevOps와 생각보다 가깝다. 자동화, CI/CD, 모니터링 같은 DevOps의 방식을 ML에 가져온 것이고, 이 스터디에서 쓰는 ML 도구도 대부분 Kubernetes 위에서 돌린다. ..

1. EKS Auto Mode란EKS Auto Mode는 컨트롤 플레인뿐 아니라 데이터 플레인까지 AWS가 관리하는 EKS 운영 모드다. 2024년 12월 1일 re:Invent 2024에서 GA로 발표됐고, 쿠버네티스 1.29 이상 클러스터에서 쓸 수 있다. EKS를 운영해 본 사람이라면 "컨트롤 플레인만 매니지드"라는 표현이 충분하지 않다고 느낀 경험이 있을 것이다. 컨트롤 플레인 아래에는 운영자가 직접 챙겨야 할 영역이 두텁게 쌓여 있다. 노드 그룹 운영, OS 패치, Karpenter Helm 차트 관리, VPC CNI와 CoreDNS와 EBS CSI 데몬셋, AWS Load Balancer Controller 설치와 IRSA 매핑, 보안 패치 주기마다의 노드 교체 같은 일이다. Auto Mode..

AWS 워크샵 EKS Upgrades(catalog.workshops.aws/eks-upgrades) 환경을 제공해주셔서 그대로 따라가며 정리한다. 워크샵은 1.30 → 1.31 한 단계 인플레이스 업그레이드를 컨트롤 플레인 → 애드온 → 4가지 노드 타입 순으로 수행한다.1. 개요1.1 EKS 업그레이드의 책임 분담EKS 업그레이드에서 가장 먼저 잡고 가야 하는 개념은 공동 책임 모델이다. 컨트롤 플레인 컴포넌트(API Server · etcd · Scheduler · Controller Manager)는 AWS의 관리 VPC에서 동작하며, 그 가용성·백업·패치·고가용성 토폴로지는 모두 AWS가 보장한다. 반면 그 위에서 동작하는 데이터 플레인(워커 노드, kubelet, kube-proxy, CNI,..

1. 개요이번 AEWS4 6주차는 감사하게도, Amazon EKS 기반 확장 가능한 멀티 테넌트 SaaS 플랫폼 구축이라는 AWS 워크샵 환경을 제공해주셔서 워크샵 내용을 정리해본다.GitOps 기반으로 SaaS 플랫폼을 구축하는 워크샵이며, 기존에는 ArgoCD 도구만 사용해봤던 입장에서 이번에는 FluxCD를 다뤄본다.2. 워크샵 실습 아키텍처실습에 사용되는 대표적인 도구들이다.도구카테고리역할Giteaself-hosted GitGitOps의 단일 진실 원천(Single Source of Truth)Flux v2GitOps 컨트롤러Git → cluster reconciliation. 본 워크샵의 메인 GitOps 엔진TF-ControllerFlux 생태계 IaC 컨트롤러Terraform CRD를 K8s..

1. 같은 에러, 다른 원인IRSA는 한 번 잘 세팅해 두면 거의 신경 쓸 일이 없다. 문제는 "한 번 잘 세팅해 두면"이라는 전제다. 클러스터를 새로 만들거나 ServiceAccount를 옮기거나 IAM Role을 재생성하는 순간 IRSA는 조용히 깨진다. 겉으로 Pod는 정상 기동하고 readiness probe도 통과한다. 그런데 AWS API 호출만 실패한다. 로그에는 다음과 같은 메시지가 반복된다.An error occurred (AccessDenied) when calling the AssumeRoleWithWebIdentityoperation: Not authorized to perform sts:AssumeRoleWithWebIdentity에러 메시지만 보면 모든 사례가 같아 보인다. 하지..

1. Pod에서 AWS API를 호출하면 무슨 일이 생기나컨테이너 안에 AWS Access Key를 넣는 건 위험하다. 이미지가 유출되면 키도 같이 나간다. 그렇다고 노드의 IAM Role을 그대로 쓰면 모든 Pod가 동일한 권한을 갖게 된다. 개발팀이 원하는 건 "런타임에서 자격증명이 자동으로 주입되면서도 Pod 단위로 최소 권한이 적용되는 것"이다.1.1 노드 IAM Role 공유의 문제서비스 어카운트를 마운트하지 않은 Pod를 하나 만들어 보자.cat 로그를 확인하면 AccessDenied가 뜬다.kubectl logs eks-iam-test1# An error occurred (AccessDenied) when calling the ListBuckets operation: Access Denie..

EKS에서 워크로드를 운영하려면 두 가지를 결정해야 한다. 어디서 실행할 것인가(컴퓨팅)와 얼마나 실행할 것인가(오토스케일링). 3주차에서는 관리형 노드 그룹으로 컴퓨팅 옵션을 살펴보고 HPA부터 Karpenter까지 여러 스케일링 방법을 실습한다.0. 실습 환경 구성Terraform으로 EKS 클러스터를 배포한다. 이번 실습 환경의 변경점은 k8s 1.35 버전 사용과 워커노드 Private Subnet 배치, SSM 접속 지원이다. add-on으로 metrics-server와 external-dns가 포함되어 있다.# 코드 다운로드git clone https://github.com/gasida/aews.gitcd aews/3w# IAM Policy 파일 작성curl -o aws_lb_controlle..