From c0b7175a0a2d20e9f734843eb43c1e4cae214422 Mon Sep 17 00:00:00 2001 From: Aiden-Jeon Date: Mon, 13 Dec 2021 21:26:41 +0900 Subject: [PATCH 1/3] unify tone & manner --- README.md | 42 ++--------------- content/en/docs/introduction/_index.md | 4 +- content/en/docs/introduction/component.md | 4 +- content/en/docs/introduction/intro.md | 46 ++++++++----------- .../en/docs/introduction/why_kubernetes.md | 24 +++++----- content/en/docs/prologue/welcome.md | 16 +++++-- .../setup-components/install-components-kf.md | 10 ++-- .../install-components-mlflow.md | 2 +- .../setup-components/install-components-pg.md | 6 +-- .../install-components-seldon.md | 6 +-- .../setup-kubernetes/kubernetes-with-k3s.md | 8 ++-- 11 files changed, 69 insertions(+), 99 deletions(-) diff --git a/README.md b/README.md index 6c952c4e..001c0164 100644 --- a/README.md +++ b/README.md @@ -1,43 +1,7 @@ ## 모두의 MLOps -### How to Start -1. 필요한 node module을 설치합니다. -```text -npm install -``` +모두의 MLOps 프로젝트입니다. -2. 글 수정 및 추가를 후 ci 를 실행합니다. -```text -npm ci -``` +프로젝트에 누구던 자유롭게 기여할 수 있습니다. -3. node 클러스터를 실행 후 수정한 글이 정상적으로 나오는지 확인합니다. -```text -npm run start -``` - -### How to Contribute -#### 1. 새로운 포스트를 작성하는 경우 -새로운 포스트는 각 챕터와 포스트의 위치에 맞는 weight를 설정합니다. -- Introduction: 1xx -- Setup: 2xx -- Kubeflow: 3xx -- API Deployment: 4xx -- Help: 10xx - -#### 2. 기존의 포스트를 수정하는 경우 -기존의 포스트를 수정할 경우 Contributor에 본인의 이름을 입력합니다. -``` -contributors: ["John Doe", "Adam Smith"] -``` - -#### 3. 프로젝트에 처음 기여하는 경우 -만약 프로젝트에 처음 기여 할 경우 `content/en/contributors`에 본인의 이름의 마크다운 파일을 작성합니다. -마크다운 파일은 `john-doe`을 파일명으로 하며 다음의 내용을 작성합니다. -파일 명은 lowercase를 title은 upper camelcase를 이용해 작성합니다. -``` ---- -title: "Jonh Doe" -draft: false ---- -``` +자세한 내용은 [How to Contribute](https://mlops-for-all.github.io/docs/help/how-to-contribute/)를 참조하세요. diff --git a/content/en/docs/introduction/_index.md b/content/en/docs/introduction/_index.md index 98a85c0b..fc54e629 100644 --- a/content/en/docs/introduction/_index.md +++ b/content/en/docs/introduction/_index.md @@ -2,8 +2,8 @@ title : "Introduction" description: "Introduction to MLOps" lead: "" -# date: 2020-10-06T08:48:23+00:00 -# lastmod: 2020-10-06T08:48:23+00:00 +date: 2021-12-03 +lastmod: 2021-12-10 draft: false images: [] weight: 100 diff --git a/content/en/docs/introduction/component.md b/content/en/docs/introduction/component.md index fb4d72a1..6f238634 100644 --- a/content/en/docs/introduction/component.md +++ b/content/en/docs/introduction/component.md @@ -1,7 +1,9 @@ --- -title : "MLOps의 구성 요소" +title : "2. Components of MLOps" description: "Describe MLOps Components" lead: "" +date: 2021-12-03 +lastmod: 2021-12-10 draft: false weight: 102 contributors: ["Youngcheol Jang"] diff --git a/content/en/docs/introduction/intro.md b/content/en/docs/introduction/intro.md index cdbe6fb3..dd7f17ad 100644 --- a/content/en/docs/introduction/intro.md +++ b/content/en/docs/introduction/intro.md @@ -1,7 +1,9 @@ --- -title : "What is MLOps?" +title : "1. What is MLOps?" description: "Introduction to MLOps" lead: "" +date: 2021-12-03 +lastmod: 2021-12-13 draft: false weight: 101 contributors: ["Jongseob Jeon"] @@ -10,37 +12,27 @@ menu: parent: "introduction" --- -## 서론 - -최근 MLOps와 관련된 주제의 세미나와 글들이 많아지고 모두 MLOps의 필요성에 대해 말하고 있습니다. -그런데 MLOps란 무엇이며 이를 위해서 우리는 무엇을 공부해야 할까요? -저희 *모두의 MLOps*는 MLOps에 대해서 공부하려고 하지만 어떻게 시작해야 하는지 모르는 분들을 위한 지침서를 작성하고자 이 프로젝트를 시작하였습니다. - -MLOps는 Machine Learning Operations의 약어입니다. Operations는 도메인에 따라서 또는 상황에 따라서 필요로 하는 것이 달라진다는 뜻을 내포하고 있습니다. -특히 집필을 하는 2022년 기준으로 아직 표준이라고 불릴 수 있는 MLOps 툴이 존재하지 않습니다. 그렇기 때문에 저희가 제시하는 방법을 실제 업무에 바로 적용하기에는 힘들 수도 있습니다. -그럼에도 이 글을 통해서 많은 분들이 MLOps란 무엇이며 각자의 환경에 맞게 어떤 것이 필요한 지를 알 수 있는 첫 디딤돌이 되었으면 합니다. - ## Machine Learning Project -2012년 Alexnet 이후 CV, NLP, Tabular Data등 데이터가 존재하는 곳에서는 모두 머신러닝과 딥러닝을 도입하고자 하였습니다. -딥러닝과 머신러닝은 AI라는 단어로 묶이며 불렸고 많은 매체에서 AI의 필요성을 외쳤습니다. 그래서 무수히 만흔 기업에서 머신러닝과 딥러닝을 이용한 수 많은 프로젝트를 진행하였습니다. 그리고 어떻게 되었을까요? +2012년 Alexnet 이후 CV, NLP, Tabular Data등 데이터가 존재하는 곳에서는 모두 머신러닝과 딥러닝을 도입하고자 하였습니다. +딥러닝과 머신러닝은 AI라는 단어로 묶이며 불렸고 많은 매체에서 AI의 필요성을 외쳤습니다. 그래서 무수히 만흔 기업에서 머신러닝과 딥러닝을 이용한 수 많은 프로젝트를 진행하였습니다. 그리고 어떻게 되었을까요? 엘리먼트 AI의 음병찬 동북아 지역 총괄책임자는 [*"10개 기업에 AI 프로젝트를 시작한다면 그 중 9개는 컨셉검증(POC)만 하다 끝난다"*](https://zdnet.co.kr/view/?no=20200611062002)고 말했습니다. 이처럼 많은 프로젝트에서 머신러닝과 딥러닝은 이 문제를 풀 수 있을 것 같다는 가능성만을 보여주고 사라졌습니다. 그리고 이 시기 즈음에 [AI에게 다시 겨울](https://www.aifutures.org/2021/ai-winter-is-coming/)이 다가오고 있다는 전망들도 나오기 시작했습니다. -왜 대부분의 프로젝트가 컨셉검증(POC) 단계에서 끝났을까요? -머신러닝과 딥러닝 코드만으로는 실제 서비스를 운영할 수 없기 때문입니다. 실제 서비스 단계에서 머신러닝과 딥러닝의 코드가 차지하는 부분은 생각보다 작으며 단순히 모델만이 아니 다른 많은 부분들을 고려해야 합니다. -구글은 이런 문제를 2015년 [Hidden Technical Debt in Machine Learning Systems](https://proceedings.neurips.cc/paper/2015/file/86df7dcfd896fcaf2674f757a2463eba-Paper.pdf)에서 지적한 바 있습니다. +왜 대부분의 프로젝트가 컨셉검증(POC) 단계에서 끝났을까요? +머신러닝과 딥러닝 코드만으로는 실제 서비스를 운영할 수 없기 때문입니다. 실제 서비스 단계에서 머신러닝과 딥러닝의 코드가 차지하는 부분은 생각보다 작으며 단순히 모델만이 아니 다른 많은 부분들을 고려해야 합니다. +구글은 이런 문제를 2015년 [Hidden Technical Debt in Machine Learning Systems](https://proceedings.neurips.cc/paper/2015/file/86df7dcfd896fcaf2674f757a2463eba-Paper.pdf)에서 지적한 바 있습니다. 하지만 이 논문이 나올 때는 아직 많은 머신러닝 엔지니어들이 딥러닝과 머신러닝의 가능성을 입증하기 바쁜 시기였기 때문에, 논문이 지적하는 바에 많은 주의를 기울이지는 않았습니다. -몇 년이 지난 후 머신러닝과 딥러닝은 가능성을 입증을 해냈고 사람들은 이제 실제 서비스에 적용하고자 했습니다. +몇 년이 지난 후 머신러닝과 딥러닝은 가능성을 입증을 해냈고 사람들은 이제 실제 서비스에 적용하고자 했습니다. 그리고 많은 사람들이 실제 서비스는 쉽지 않다는 것을 깨달았습니다. **** ## Before MLOps -사람들은 우선 머신러닝과 딥러닝을 일반적인 소프트웨어와 동일한 시선으로 바라보고 기존과 같은 방식으로 운영하고자 했습니다. -일반적인 소프트웨어에서는 어떤 문제가 발생할 경우 해당 부분을 담당한 소프트웨어 엔지니어가 문제의 원인을 진단하고 이를 해결한 후 다시 배포를 하였습니다. +사람들은 우선 머신러닝과 딥러닝을 일반적인 소프트웨어와 동일한 시선으로 바라보고 기존과 같은 방식으로 운영하고자 했습니다. +일반적인 소프트웨어에서는 어떤 문제가 발생할 경우 해당 부분을 담당한 소프트웨어 엔지니어가 문제의 원인을 진단하고 이를 해결한 후 다시 배포를 하였습니다.

@@ -54,17 +46,17 @@ MLOps는 Machine Learning Operations의 약어입니다. Operations는 도메인

-머신러닝 엔지니어와 소프트웨어 엔지니어들은 **모델(*Network 구조와 Weights 가 담긴 파일*)** 을 매개체로 서로 소통했습니다. -머신러닝 엔지니어들은 DB에서 직접 쿼리를 이용해 데이터를 다운로드 받고 모델을 학습 후, 학습된 모델을 소프트웨어 엔지니어에게 전달하였습니다. +머신러닝 엔지니어와 소프트웨어 엔지니어들은 **모델(*Network 구조와 Weights 가 담긴 파일*)** 을 매개체로 서로 소통했습니다. +머신러닝 엔지니어들은 DB에서 직접 쿼리를 이용해 데이터를 다운로드 받고 모델을 학습 후, 학습된 모델을 소프트웨어 엔지니어에게 전달하였습니다. 그러면 소프트웨어 엔지니어는 전달받은 모델을 로드한 뒤, 정해진 추론(inference) 함수를 제공하는 API Server 를 만들어 배포하였습니다. 이 과정에서 소프트웨어 엔지니어는 머신러닝 엔지니어에게 정해진 형식에 맞춰서 구현할 것을 요청합니다. 예를 들면 OS, 파이썬 버전, 사용한 패키지, 클래스 구조 등을 포함합니다. -소프트웨어 엔지니어와 머신러닝 엔지니어는 서로 어떤 환경에서 작업을 하는지 알지 못하기 때문에 소통의 과정에서 미리 약속한 형식에서 하나라도 어긋난다면 배포와 성능 재현의 문제가 발생합니다. +소프트웨어 엔지니어와 머신러닝 엔지니어는 서로 어떤 환경에서 작업을 하는지 알지 못하기 때문에 소통의 과정에서 미리 약속한 형식에서 하나라도 어긋난다면 배포와 성능 재현의 문제가 발생합니다. 예를 들어서 개발 환경에서는 동작했던 코드가 실행 환경에서는 동작하지 않는다던지, 개발 환경에서과 동일한 성능이 재현되지 않는 문제가 발생하게 됩니다. -또한 Data Shift와 같이 학습에 사용된 데이터와 다른 데이터가 들어왔을 때 모델의 성능이 감소하는 문제가 생겼습니다. -일반적인 소프트웨어에서 문제를 해결하는 방법과 비슷하게 모델을 담당한 머신러닝 엔지니어들이 모델 성능 하락의 원인을 찾고 이를 개선한 새로운 모델을 배포했습니다. +또한 Data Shift와 같이 학습에 사용된 데이터와 다른 데이터가 들어왔을 때 모델의 성능이 감소하는 문제가 생겼습니다. +일반적인 소프트웨어에서 문제를 해결하는 방법과 비슷하게 모델을 담당한 머신러닝 엔지니어들이 모델 성능 하락의 원인을 찾고 이를 개선한 새로운 모델을 배포했습니다. 일반적인 경우 최신 데이터를 추가적으로 반영하여 모델을 재학습하는 것만으로도 모델의 성능의 하락을 개선할 수 있었기 때문에, 머신러닝 엔지니어들은 주기적으로 모델을 재학습해서 배포하였습니다. ## After MLOps @@ -77,11 +69,11 @@ MLOps에서는 파이프라인을 이용해 서로 소통합니다. 여기서 ### Continuous Integration & Deployment -머신러닝 엔지니어는 데이터를 다운로드 받고, 전처리를 수행하며, 모델을 생성하기까지의 모든 과정을 파이프라인의 형태로 작성하여 소프트웨어 엔지니어에게 전달하고, 소프트웨어 엔지니어는 전달받은 파이프라인에서 생성된 모델을 배포합니다. +머신러닝 엔지니어는 데이터를 다운로드 받고, 전처리를 수행하며, 모델을 생성하기까지의 모든 과정을 파이프라인의 형태로 작성하여 소프트웨어 엔지니어에게 전달하고, 소프트웨어 엔지니어는 전달받은 파이프라인에서 생성된 모델을 배포합니다. 머신러닝 엔지니어와 소프트웨어 엔지니어는 같은 파이프라인을 사용하기 때문에 언제 어디서나 동일한 성능의 모델을 빌드하고 배포하는 것을 보장할 수 있게 됩니다. ### Continuous Training -머신러닝 모델은 녹이 습니다. 이 말인 즉슨 한 번 학습되어 뛰어난 성능을 보였던 모델이라고 하더라도, 시간이 지남에 따라 성능이 저하되는 현상이 있다는 말입니다. 모델의 성능이 저하되는 근본적인 이유는 데이터의 분포가 변화하기 때문입니다. -데이터의 분포는 왜 변할까요? 데이터의 분포가 변화하는 이유로는 데이터의 모분포를 모르기 때문일수도 있고 현실에서 얻어지는 데이터의 특성은 변화할 수 있기 때문입니다. +머신러닝 모델은 녹이 습니다. 이 말인 즉슨 한 번 학습되어 뛰어난 성능을 보였던 모델이라고 하더라도, 시간이 지남에 따라 성능이 저하되는 현상이 있다는 말입니다. 모델의 성능이 저하되는 근본적인 이유는 데이터의 분포가 변화하기 때문입니다. +데이터의 분포는 왜 변할까요? 데이터의 분포가 변화하는 이유로는 데이터의 모분포를 모르기 때문일수도 있고 현실에서 얻어지는 데이터의 특성은 변화할 수 있기 때문입니다. 이 때문에 최신 데이터를 이용해 모델을 재학습하여 모델의 성능을 다시 끌어올리는 작업이 필요하게 되었고, 머신러닝 엔지니어가 항상 이 작업을 반복하기보다는 파이프라인을 통해서 자동화를 할 수 있습니다. diff --git a/content/en/docs/introduction/why_kubernetes.md b/content/en/docs/introduction/why_kubernetes.md index 28bb8e87..983e6662 100644 --- a/content/en/docs/introduction/why_kubernetes.md +++ b/content/en/docs/introduction/why_kubernetes.md @@ -1,7 +1,9 @@ --- -title : "Why Kuberntes?" +title : "3. Why Kuberntes?" description: "Reason for using k8s in MLOps" lead: "" +date: 2021-12-03 +lastmod: 2021-12-10 draft: false weight: 103 contributors: ["Jaeyeon Kim"] @@ -14,8 +16,8 @@ menu: 그렇다면 MLOps를 이야기할 때, 쿠버네티스(Kubernetes)라는 단어가 항상 함께 들리는 이유가 무엇일까요? -성공적인 MLOps 시스템을 구축하기 위해서는 [MLOps의 구성요소]({{< relref "docs/introduction/component.md" >}}) 에서 설명한 것처럼 다양한 구성 요소들이 필요하지만, 각각의 구성 요소들이 유기적으로 운영되기 위해서는 인프라 레벨에서 수많은 이슈들을 해결해야 합니다. -간단하게는 수많은 머신러닝 모델의 학습 요청을 순차적으로 실행 하는 것, 다른 작업 공간에서도 동일한 실행 환경을 보장해야 하는 것, 배포된 서비스에 장애가 생겼을 때 빠르게 대응해야 하는 것 등의 이슈 등을 생각해볼 수 있습니다. +성공적인 MLOps 시스템을 구축하기 위해서는 [MLOps의 구성요소]({{< relref "docs/introduction/component.md" >}}) 에서 설명한 것처럼 다양한 구성 요소들이 필요하지만, 각각의 구성 요소들이 유기적으로 운영되기 위해서는 인프라 레벨에서 수많은 이슈들을 해결해야 합니다. +간단하게는 수많은 머신러닝 모델의 학습 요청을 순차적으로 실행 하는 것, 다른 작업 공간에서도 동일한 실행 환경을 보장해야 하는 것, 배포된 서비스에 장애가 생겼을 때 빠르게 대응해야 하는 것 등의 이슈 등을 생각해볼 수 있습니다. 여기서 컨테이너(Container)와 컨테이너 오케스트레이션 시스템(Container Orchestration System)의 필요성이 등장합니다. 쿠버네티스와 같은 컨테이너 오케스트레이션 시스템을 도입하면 실행 환경의 격리와 관리를 효율적으로 수행할 수 있습니다. 컨테이너 오케스트레이션 시스템을 도입한다면, 머신러닝 모델을 개발하고 배포하는 과정에서 다수의 개발자가 소수의 클러스터를 공유하면서 *'1번 클러스터 사용 중이신가요?', 'GPU 사용 중이던 제 프로세스 누가 죽였나요?', '누가 클러스터에 x 패키지 업데이트 했나요?'* 와 같은 상황을 방지할 수 있습니다. @@ -26,12 +28,12 @@ menu: > 컨테이너란 : 애플리케이션의 표준화된 이식 가능한 패키징 -그런데 왜 머신러닝에서 컨테이너가 필요할까요? 머신러닝 모델들은 운영체제나 Python 실행 환경, 패키지 버전 등에 따라 다르게 동작할 수 있습니다. +그런데 왜 머신러닝에서 컨테이너가 필요할까요? 머신러닝 모델들은 운영체제나 Python 실행 환경, 패키지 버전 등에 따라 다르게 동작할 수 있습니다. 이를 방지하기 위해서 머신러닝에 사용된 소스코드와 함께 종속적인 실행 환경 전체를 **하나로 묶어서(패키징해서)** 공유하고 실행하는 데 활용할 수 있는 기술이 컨테이너라이제이션(Containerization) 기술입니다. -이렇게 패키징된 형태를 컨테이너 이미지라고 부르며, 컨테이너 이미지를 공유함으로써 사용자들은 어떤 시스템에서든 동일한 실행 결과를 보장할 수 있게 됩니다. +이렇게 패키징된 형태를 컨테이너 이미지라고 부르며, 컨테이너 이미지를 공유함으로써 사용자들은 어떤 시스템에서든 동일한 실행 결과를 보장할 수 있게 됩니다. 즉, 단순히 Jupyter Notebook 파일이나, 모델의 소스코드와 requirements.txt 파일을 공유하는 것이 아닌, 모든 실행 환경이 담긴 컨테이너 이미지를 공유한다면 *"제 노트북에서는 잘 되는데요?"* 와 같은 상황을 피할 수 있습니다. -컨테이너를 처음 접하시는 분들이 흔히 하시는 오해 중 하나는 "**컨테이너 == 도커**"라고 받아들이는 것입니다. +컨테이너를 처음 접하시는 분들이 흔히 하시는 오해 중 하나는 "**컨테이너 == 도커**"라고 받아들이는 것입니다. 도커는 컨테이너와 동일한 의미를 지니는 개념이 아니라, 컨테이너를 띄우거나, 컨테이너 이미지를 만들고 공유하는 것과 같이 컨테이너를 보다 쉽고 유연하게 사용할 수 있는 기능을 제공해주는 도구입니다. 정리하자면 컨테이너는 가상화 기술이고, 도커는 가상화 기술의 구현체라고 말할 수 있습니다. 다만, 도커는 여러 컨테이너 가상화 도구 중에서 쉬운 사용성과 높은 효율성을 바탕으로 가장 빠르게 성장하여 대세가 되었기에 컨테이너하면 도커라는 이미지가 자동으로 떠오르게 되었습니다. 이렇게 컨테이너와 도커 생태계가 대세가 되기까지는 다양한 이유가 있지만, 기술적으로 자세한 이야기는 *모두의 MLOps*의 범위를 넘어서기 때문에 다루지는 않겠습니다. @@ -42,15 +44,15 @@ menu: 그렇다면 컨테이너 오케스트레이션 시스템은 무엇일까요? **오케스트레이션**이라는 단어에서 추측해 볼 수 있듯이, 수많은 컨테이너들이 있을 때 컨테이너들이 서로 조화롭게 구동될 수 있도록 지휘하는 시스템에 비유할 수 있습니다. -컨테이너를 도입이 되면 서비스는 컨테이너의 형태로 사용자들에게 제공됩니다. 이 때 관리해야 할 컨테이너의 수가 적다면 운영 담당자 한 명이서도 충분히 모든 상황에 대응할 수 있습니다. +컨테이너를 도입이 되면 서비스는 컨테이너의 형태로 사용자들에게 제공됩니다. 이 때 관리해야 할 컨테이너의 수가 적다면 운영 담당자 한 명이서도 충분히 모든 상황에 대응할 수 있습니다. 하지만, 수 백 개 이상의 컨테이너가 수 십 대 이상의 클러스터에서 구동되고 있고 장애를 일으키지 않고 항상 정상 동작해야 한다면, 모든 서비스의 정상 동작 여부를 담당자 한 명이 파악하고 이슈에 대응하는 것은 불가능에 가깝습니다. -예를 들면, 모든 서비스가 정상적으로 동작하고 있는지를 계속해서 모니터링(Monitoring)해야 합니다. -만약, 특정 서비스가 장애를 일으켰다면 여러 컨테이너들의 로그를 확인해가며 문제를 파악해야 합니다. +예를 들면, 모든 서비스가 정상적으로 동작하고 있는지를 계속해서 모니터링(Monitoring)해야 합니다. +만약, 특정 서비스가 장애를 일으켰다면 여러 컨테이너들의 로그를 확인해가며 문제를 파악해야 합니다. 또한 특정 클러스터나 특정 컨테이너에 작업이 몰리지 않도록 스케줄링(Scheduling)하고 로드 밸런싱(Load Balancing)하며, 스케일링(Scaling)하는 등의 수많은 작업을 담당해야 합니다. -이렇게 수많은 컨테이너들의 상태를 지속적으로 관리하고 운영하는 과정을 조금이나마 쉽게, 자동으로 할 수 있는 기능을 제공해주는 소프트웨어가 바로 컨테이너 오케스트레이션 시스템입니다. +이렇게 수많은 컨테이너들의 상태를 지속적으로 관리하고 운영하는 과정을 조금이나마 쉽게, 자동으로 할 수 있는 기능을 제공해주는 소프트웨어가 바로 컨테이너 오케스트레이션 시스템입니다. -머신러닝에서는 어떻게 쓰일 수 있을까요? +머신러닝에서는 어떻게 쓰일 수 있을까요? 예를 들어서 GPU를 필요로 하는 딥러닝 학습 코드가 패키징된 컨테이너는 사용 가능한 GPU가 있는 클러스터에서 수행하고, 많은 메모리를 필요로 하는 데이터 전처리 코드가 패키징된 컨테이너는 메모리의 여유가 많은 클러스터에서 수행하고, 학습 중에 클러스터에 문제가 생기면 자동으로 동일한 컨테이너를 다른 클러스터로 이동시키고 다시 학습을 진행하는 등의 작업을 사람이 일일히 수행하지 않고, 자동으로 관리하는 시스템을 개발한 뒤 맡기는 것입니다. 집필을 하는 2022년을 기준으로 쿠버네티스는 컨테이너 오케스트레이션 시스템의 사실상의 표준(De facto standard)입니다. diff --git a/content/en/docs/prologue/welcome.md b/content/en/docs/prologue/welcome.md index 546026f6..64d473be 100644 --- a/content/en/docs/prologue/welcome.md +++ b/content/en/docs/prologue/welcome.md @@ -1,9 +1,9 @@ --- -title : "Welcome!" +title : "Welcome to MLOps for ALL!" description: "Introduction to MLOps" lead: "" -# date: 2020-10-06T08:48:23+00:00 -# lastmod: 2020-10-06T08:48:23+00:00 +date: 2021-12-03 +lastmod: 2021-12-13 draft: false images: [] weight: 1 @@ -11,3 +11,13 @@ menu: docs: parent: "prologue" --- + +## 모두의 MLOps + +최근 MLOps와 관련된 주제의 세미나와 글들이 많아지고 모두 MLOps의 필요성에 대해 말하고 있습니다. +그런데 MLOps란 무엇이며 이를 위해서 우리는 무엇을 공부해야 할까요? +저희 *모두의 MLOps*는 MLOps에 대해서 공부하려고 하지만 어떻게 시작해야 하는지 모르는 분들을 위한 지침서를 작성하고자 이 프로젝트를 시작하였습니다. + +MLOps는 Machine Learning Operations의 약어입니다. Operations는 도메인에 따라서 또는 상황에 따라서 필요로 하는 것이 달라진다는 뜻을 내포하고 있습니다. +특히 집필을 하는 2022년 기준으로 아직 표준이라고 불릴 수 있는 MLOps 툴이 존재하지 않습니다. 그렇기 때문에 저희가 제시하는 방법을 실제 업무에 바로 적용하기에는 힘들 수도 있습니다. +그럼에도 이 글을 통해서 많은 분들이 MLOps란 무엇이며 각자의 환경에 맞게 어떤 것이 필요한 지를 알 수 있는 첫 디딤돌이 되었으면 합니다. diff --git a/content/en/docs/setup-components/install-components-kf.md b/content/en/docs/setup-components/install-components-kf.md index 0f4995a7..40fadadf 100644 --- a/content/en/docs/setup-components/install-components-kf.md +++ b/content/en/docs/setup-components/install-components-kf.md @@ -1,5 +1,5 @@ --- -title : "Kubeflow" +title : "1. Kubeflow" description: "구성요소 설치 - Kubeflow" date: 2021-12-13 lastmod: 2021-12-13 @@ -25,8 +25,8 @@ cd manifests ## 각 구성요소별 설치 -kubeflow/manifests Repository 에 각 구성요소별 설치 커맨드가 적혀져 있지만, 설치하며 발생할 수 있는 이슈 혹은 정상적으로 설치되었는지 확인할 수 있는 방법 등이 적혀져있지 않아 처음 설치하는 경우 어려움을 겪는 경우가 많습니다. -따라서, 각 구성요소별로 정상적으로 설치되었는지 확인하는 방법을 함께 작성합니다. +kubeflow/manifests Repository 에 각 구성요소별 설치 커맨드가 적혀져 있지만, 설치하며 발생할 수 있는 이슈 혹은 정상적으로 설치되었는지 확인할 수 있는 방법 등이 적혀져있지 않아 처음 설치하는 경우 어려움을 겪는 경우가 많습니다. +따라서, 각 구성요소별로 정상적으로 설치되었는지 확인하는 방법을 함께 작성합니다. 또한, 본 문서에서는 **모두의 MLOps** 에서 다루지 않는 구성요소인 Knative, KFServing, MPI Operator 의 설치는 리소스의 효율적 사용을 위해 따로 설치하지 않습니다. @@ -61,7 +61,7 @@ kustomize build common/cert-manager/kubeflow-issuer/base | kubectl apply -f - - cert-manager-webhook 이슈 - cert-manager-webhook deployment 가 Running 이 아닌 경우, 다음과 비슷한 에러가 발생하며 kubeflow-issuer가 설치되지 않을 수 있음에 주의하기시 바랍니다. + cert-manager-webhook deployment 가 Running 이 아닌 경우, 다음과 비슷한 에러가 발생하며 kubeflow-issuer가 설치되지 않을 수 있음에 주의하기시 바랍니다. 해당 에러가 발생한 경우, cert-manager 의 3 개의 pod 가 모두 Running 이 되는 것을 확인한 이후 다시 명령어를 수행하시기 바랍니다. ```text @@ -242,7 +242,7 @@ kustomize build apps/pipeline/upstream/env/platform-agnostic-multi-user | kubect 따라서 경우에 따라 다음과 비슷한 에러가 발생할 수 있습니다. ```text -"error: unable to recognize "STDIN": no matches for kind "CompositeController" in version "metacontroller.k8s.io/v1alpha1"" +"error: unable to recognize "STDIN": no matches for kind "CompositeController" in version "metacontroller.k8s.io/v1alpha1"" ``` 위와 비슷한 에러가 발생한다면, 10 초 정도 기다린 뒤 다시 위의 명령을 수행합니다. diff --git a/content/en/docs/setup-components/install-components-mlflow.md b/content/en/docs/setup-components/install-components-mlflow.md index 3a08bbfe..c2c9abee 100644 --- a/content/en/docs/setup-components/install-components-mlflow.md +++ b/content/en/docs/setup-components/install-components-mlflow.md @@ -1,5 +1,5 @@ --- -title : "MLFlow" +title : "2. MLFlow" description: "구성요소 설치 - MLFlow" date: 2021-12-13 lastmod: 2021-12-13 diff --git a/content/en/docs/setup-components/install-components-pg.md b/content/en/docs/setup-components/install-components-pg.md index 2f51c571..02f2ac7d 100644 --- a/content/en/docs/setup-components/install-components-pg.md +++ b/content/en/docs/setup-components/install-components-pg.md @@ -1,5 +1,5 @@ --- -title : "Prometheus & Grafana" +title : "3. Prometheus & Grafana" description: "구성요소 설치 - Prometheus & Grafana" date: 2021-12-13 lastmod: 2021-12-13 @@ -14,8 +14,8 @@ images: [] ## Prometheus & Grafana -프로메테우스(Prometheus) 와 그라파나(Grafana) 는 모니터링을 위한 도구입니다. -안정적인 서비스 운영을 위해서는 서비스와 서비스가 운영되고 있는 인프라의 상태를 지속적으로 관찰하고, 관찰한 메트릭을 바탕으로 문제가 생길 경우 빠르게 대응해야 합니다. +프로메테우스(Prometheus) 와 그라파나(Grafana) 는 모니터링을 위한 도구입니다. +안정적인 서비스 운영을 위해서는 서비스와 서비스가 운영되고 있는 인프라의 상태를 지속적으로 관찰하고, 관찰한 메트릭을 바탕으로 문제가 생길 경우 빠르게 대응해야 합니다. 이러한 모니터링을 효율적으로 수행하기 위한 많은 도구 중 *모두의 MLOps*에서는 오픈소스인 프로메테우스와 그라파나를 사용할 예정입니다. 보다 자세한 내용은 [Prometheus 공식 문서](https://prometheus.io/docs/introduction/overview/), [Grafana 공식 문서](https://grafana.com/docs/)를 확인해주시기 바랍니다. diff --git a/content/en/docs/setup-components/install-components-seldon.md b/content/en/docs/setup-components/install-components-seldon.md index ad5273e4..93dbd66b 100644 --- a/content/en/docs/setup-components/install-components-seldon.md +++ b/content/en/docs/setup-components/install-components-seldon.md @@ -1,5 +1,5 @@ --- -title : "Seldon-Core" +title : "4. Seldon-Core" description: "구성요소 설치 - Seldon-Core" date: 2021-12-13 lastmod: 2021-12-13 @@ -14,12 +14,12 @@ images: [] ## Seldon-Core -Seldon-Core는 쿠버네티스 환경에 수많은 머신러닝 모델을 배포하고 관리할 수 있는 오픈소스 프레임워크 중 하나입니다. +Seldon-Core는 쿠버네티스 환경에 수많은 머신러닝 모델을 배포하고 관리할 수 있는 오픈소스 프레임워크 중 하나입니다. 보다 자세한 내용은 Seldon-Core 의 공식 [제품 설명 페이지](https://www.seldon.io/tech/products/core/) 와 [깃헙](https://github.com/SeldonIO/seldon-core) 그리고 API Deployment 파트를 참고해주시기 바랍니다. ## Selon-Core 설치 -Seldon-Core를 사용하기 위해서는 쿠버네티스의 인그레스(Ingress)를 담당하는 Ambassador 와 Istio 와 같은 [모듈이 필요합니다](https://docs.seldon.io/projects/seldon-core/en/latest/workflow/install.html). +Seldon-Core를 사용하기 위해서는 쿠버네티스의 인그레스(Ingress)를 담당하는 Ambassador 와 Istio 와 같은 [모듈이 필요합니다](https://docs.seldon.io/projects/seldon-core/en/latest/workflow/install.html). Seldon-Core 에서는 Ambassador 와 Istio 만을 공식적으로 지원하며, *모두의 MLOps*에서는 Ambassador를 사용해 Seldon-core를 사용하므로 Ambassador를 설치하겠습니다. ### Ambassador - Helm Repository 추가 diff --git a/content/en/docs/setup-kubernetes/kubernetes-with-k3s.md b/content/en/docs/setup-kubernetes/kubernetes-with-k3s.md index 7f7cd0bc..a92f972b 100644 --- a/content/en/docs/setup-kubernetes/kubernetes-with-k3s.md +++ b/content/en/docs/setup-kubernetes/kubernetes-with-k3s.md @@ -12,11 +12,12 @@ menu: images: [] --- -**해당 과정은 클러스터로 사용하는 데스크탑에서 진행됩니다.** -로컬과 클러스터가 분리된 경우 꼭 클러스터에서 설치되도록 확인해 주세요. - ## 1. Prerequisite +쿠버네티스 클러스터를 구축하기에 앞서, 필요한 구성요소들을 **클러스터에** 설치합니다. + +[Setup Prerequisite]({{< relref "docs/setup-kubernetes/setup-pre-requisite.md" >}})을 참고하여 Kubernetes를 설치하기 전에 필요한 요소들을 **클러스터에** 설치해 주시기 바랍니다. + k3s 에서는 기본값으로 containerd를 백엔드로 이용해 설치합니다. 하지만 저희는 GPU를 사용하기 위해서 docker를 백엔드로 사용해야 하기 때문에 `--docker` 옵션을 통해 백엔드를 docker로 설치하겠습니다. @@ -44,7 +45,6 @@ sudo chown mrx:mrx .kube/config 이제 클러스터에서 설정한 kubeconfig를 로컬로 이동합니다. 로컬에서는 경로를 `~/.kube/config`로 설정합니다. -정상적으로 작동하는지 확인합니다. ## 4. 쿠버네티스 기본 모듈 설치 From 8e15f6ab58142a9287d8e517ab56b2d5ff4e6b4b Mon Sep 17 00:00:00 2001 From: Jongseob Jeon Date: Mon, 13 Dec 2021 21:35:50 +0900 Subject: [PATCH 2/3] Apply suggestions from code review --- content/en/docs/introduction/intro.md | 32 +++++++++---------- .../en/docs/introduction/why_kubernetes.md | 20 ++++++------ .../setup-components/install-components-kf.md | 8 ++--- .../setup-components/install-components-pg.md | 4 +-- .../install-components-seldon.md | 4 +-- 5 files changed, 34 insertions(+), 34 deletions(-) diff --git a/content/en/docs/introduction/intro.md b/content/en/docs/introduction/intro.md index dd7f17ad..ff0dc892 100644 --- a/content/en/docs/introduction/intro.md +++ b/content/en/docs/introduction/intro.md @@ -14,25 +14,25 @@ menu: ## Machine Learning Project -2012년 Alexnet 이후 CV, NLP, Tabular Data등 데이터가 존재하는 곳에서는 모두 머신러닝과 딥러닝을 도입하고자 하였습니다. -딥러닝과 머신러닝은 AI라는 단어로 묶이며 불렸고 많은 매체에서 AI의 필요성을 외쳤습니다. 그래서 무수히 만흔 기업에서 머신러닝과 딥러닝을 이용한 수 많은 프로젝트를 진행하였습니다. 그리고 어떻게 되었을까요? +2012년 Alexnet 이후 CV, NLP, Tabular Data등 데이터가 존재하는 곳에서는 모두 머신러닝과 딥러닝을 도입하고자 하였습니다. +딥러닝과 머신러닝은 AI라는 단어로 묶이며 불렸고 많은 매체에서 AI의 필요성을 외쳤습니다. 그래서 무수히 만흔 기업에서 머신러닝과 딥러닝을 이용한 수 많은 프로젝트를 진행하였습니다. 그리고 어떻게 되었을까요? 엘리먼트 AI의 음병찬 동북아 지역 총괄책임자는 [*"10개 기업에 AI 프로젝트를 시작한다면 그 중 9개는 컨셉검증(POC)만 하다 끝난다"*](https://zdnet.co.kr/view/?no=20200611062002)고 말했습니다. 이처럼 많은 프로젝트에서 머신러닝과 딥러닝은 이 문제를 풀 수 있을 것 같다는 가능성만을 보여주고 사라졌습니다. 그리고 이 시기 즈음에 [AI에게 다시 겨울](https://www.aifutures.org/2021/ai-winter-is-coming/)이 다가오고 있다는 전망들도 나오기 시작했습니다. -왜 대부분의 프로젝트가 컨셉검증(POC) 단계에서 끝났을까요? -머신러닝과 딥러닝 코드만으로는 실제 서비스를 운영할 수 없기 때문입니다. 실제 서비스 단계에서 머신러닝과 딥러닝의 코드가 차지하는 부분은 생각보다 작으며 단순히 모델만이 아니 다른 많은 부분들을 고려해야 합니다. -구글은 이런 문제를 2015년 [Hidden Technical Debt in Machine Learning Systems](https://proceedings.neurips.cc/paper/2015/file/86df7dcfd896fcaf2674f757a2463eba-Paper.pdf)에서 지적한 바 있습니다. +왜 대부분의 프로젝트가 컨셉검증(POC) 단계에서 끝났을까요? +머신러닝과 딥러닝 코드만으로는 실제 서비스를 운영할 수 없기 때문입니다. 실제 서비스 단계에서 머신러닝과 딥러닝의 코드가 차지하는 부분은 생각보다 작으며 단순히 모델만이 아니 다른 많은 부분들을 고려해야 합니다. +구글은 이런 문제를 2015년 [Hidden Technical Debt in Machine Learning Systems](https://proceedings.neurips.cc/paper/2015/file/86df7dcfd896fcaf2674f757a2463eba-Paper.pdf)에서 지적한 바 있습니다. 하지만 이 논문이 나올 때는 아직 많은 머신러닝 엔지니어들이 딥러닝과 머신러닝의 가능성을 입증하기 바쁜 시기였기 때문에, 논문이 지적하는 바에 많은 주의를 기울이지는 않았습니다. -몇 년이 지난 후 머신러닝과 딥러닝은 가능성을 입증을 해냈고 사람들은 이제 실제 서비스에 적용하고자 했습니다. +몇 년이 지난 후 머신러닝과 딥러닝은 가능성을 입증을 해냈고 사람들은 이제 실제 서비스에 적용하고자 했습니다. 그리고 많은 사람들이 실제 서비스는 쉽지 않다는 것을 깨달았습니다. **** ## Before MLOps -사람들은 우선 머신러닝과 딥러닝을 일반적인 소프트웨어와 동일한 시선으로 바라보고 기존과 같은 방식으로 운영하고자 했습니다. -일반적인 소프트웨어에서는 어떤 문제가 발생할 경우 해당 부분을 담당한 소프트웨어 엔지니어가 문제의 원인을 진단하고 이를 해결한 후 다시 배포를 하였습니다. +사람들은 우선 머신러닝과 딥러닝을 일반적인 소프트웨어와 동일한 시선으로 바라보고 기존과 같은 방식으로 운영하고자 했습니다. +일반적인 소프트웨어에서는 어떤 문제가 발생할 경우 해당 부분을 담당한 소프트웨어 엔지니어가 문제의 원인을 진단하고 이를 해결한 후 다시 배포를 하였습니다.

@@ -46,17 +46,17 @@ menu:

-머신러닝 엔지니어와 소프트웨어 엔지니어들은 **모델(*Network 구조와 Weights 가 담긴 파일*)** 을 매개체로 서로 소통했습니다. -머신러닝 엔지니어들은 DB에서 직접 쿼리를 이용해 데이터를 다운로드 받고 모델을 학습 후, 학습된 모델을 소프트웨어 엔지니어에게 전달하였습니다. +머신러닝 엔지니어와 소프트웨어 엔지니어들은 **모델(*Network 구조와 Weights 가 담긴 파일*)** 을 매개체로 서로 소통했습니다. +머신러닝 엔지니어들은 DB에서 직접 쿼리를 이용해 데이터를 다운로드 받고 모델을 학습 후, 학습된 모델을 소프트웨어 엔지니어에게 전달하였습니다. 그러면 소프트웨어 엔지니어는 전달받은 모델을 로드한 뒤, 정해진 추론(inference) 함수를 제공하는 API Server 를 만들어 배포하였습니다. 이 과정에서 소프트웨어 엔지니어는 머신러닝 엔지니어에게 정해진 형식에 맞춰서 구현할 것을 요청합니다. 예를 들면 OS, 파이썬 버전, 사용한 패키지, 클래스 구조 등을 포함합니다. -소프트웨어 엔지니어와 머신러닝 엔지니어는 서로 어떤 환경에서 작업을 하는지 알지 못하기 때문에 소통의 과정에서 미리 약속한 형식에서 하나라도 어긋난다면 배포와 성능 재현의 문제가 발생합니다. +소프트웨어 엔지니어와 머신러닝 엔지니어는 서로 어떤 환경에서 작업을 하는지 알지 못하기 때문에 소통의 과정에서 미리 약속한 형식에서 하나라도 어긋난다면 배포와 성능 재현의 문제가 발생합니다. 예를 들어서 개발 환경에서는 동작했던 코드가 실행 환경에서는 동작하지 않는다던지, 개발 환경에서과 동일한 성능이 재현되지 않는 문제가 발생하게 됩니다. -또한 Data Shift와 같이 학습에 사용된 데이터와 다른 데이터가 들어왔을 때 모델의 성능이 감소하는 문제가 생겼습니다. -일반적인 소프트웨어에서 문제를 해결하는 방법과 비슷하게 모델을 담당한 머신러닝 엔지니어들이 모델 성능 하락의 원인을 찾고 이를 개선한 새로운 모델을 배포했습니다. +또한 Data Shift와 같이 학습에 사용된 데이터와 다른 데이터가 들어왔을 때 모델의 성능이 감소하는 문제가 생겼습니다. +일반적인 소프트웨어에서 문제를 해결하는 방법과 비슷하게 모델을 담당한 머신러닝 엔지니어들이 모델 성능 하락의 원인을 찾고 이를 개선한 새로운 모델을 배포했습니다. 일반적인 경우 최신 데이터를 추가적으로 반영하여 모델을 재학습하는 것만으로도 모델의 성능의 하락을 개선할 수 있었기 때문에, 머신러닝 엔지니어들은 주기적으로 모델을 재학습해서 배포하였습니다. ## After MLOps @@ -69,11 +69,11 @@ MLOps에서는 파이프라인을 이용해 서로 소통합니다. 여기서 ### Continuous Integration & Deployment -머신러닝 엔지니어는 데이터를 다운로드 받고, 전처리를 수행하며, 모델을 생성하기까지의 모든 과정을 파이프라인의 형태로 작성하여 소프트웨어 엔지니어에게 전달하고, 소프트웨어 엔지니어는 전달받은 파이프라인에서 생성된 모델을 배포합니다. +머신러닝 엔지니어는 데이터를 다운로드 받고, 전처리를 수행하며, 모델을 생성하기까지의 모든 과정을 파이프라인의 형태로 작성하여 소프트웨어 엔지니어에게 전달하고, 소프트웨어 엔지니어는 전달받은 파이프라인에서 생성된 모델을 배포합니다. 머신러닝 엔지니어와 소프트웨어 엔지니어는 같은 파이프라인을 사용하기 때문에 언제 어디서나 동일한 성능의 모델을 빌드하고 배포하는 것을 보장할 수 있게 됩니다. ### Continuous Training -머신러닝 모델은 녹이 습니다. 이 말인 즉슨 한 번 학습되어 뛰어난 성능을 보였던 모델이라고 하더라도, 시간이 지남에 따라 성능이 저하되는 현상이 있다는 말입니다. 모델의 성능이 저하되는 근본적인 이유는 데이터의 분포가 변화하기 때문입니다. -데이터의 분포는 왜 변할까요? 데이터의 분포가 변화하는 이유로는 데이터의 모분포를 모르기 때문일수도 있고 현실에서 얻어지는 데이터의 특성은 변화할 수 있기 때문입니다. +머신러닝 모델은 녹이 습니다. 이 말인 즉슨 한 번 학습되어 뛰어난 성능을 보였던 모델이라고 하더라도, 시간이 지남에 따라 성능이 저하되는 현상이 있다는 말입니다. 모델의 성능이 저하되는 근본적인 이유는 데이터의 분포가 변화하기 때문입니다. +데이터의 분포는 왜 변할까요? 데이터의 분포가 변화하는 이유로는 데이터의 모분포를 모르기 때문일수도 있고 현실에서 얻어지는 데이터의 특성은 변화할 수 있기 때문입니다. 이 때문에 최신 데이터를 이용해 모델을 재학습하여 모델의 성능을 다시 끌어올리는 작업이 필요하게 되었고, 머신러닝 엔지니어가 항상 이 작업을 반복하기보다는 파이프라인을 통해서 자동화를 할 수 있습니다. diff --git a/content/en/docs/introduction/why_kubernetes.md b/content/en/docs/introduction/why_kubernetes.md index 983e6662..99215084 100644 --- a/content/en/docs/introduction/why_kubernetes.md +++ b/content/en/docs/introduction/why_kubernetes.md @@ -16,8 +16,8 @@ menu: 그렇다면 MLOps를 이야기할 때, 쿠버네티스(Kubernetes)라는 단어가 항상 함께 들리는 이유가 무엇일까요? -성공적인 MLOps 시스템을 구축하기 위해서는 [MLOps의 구성요소]({{< relref "docs/introduction/component.md" >}}) 에서 설명한 것처럼 다양한 구성 요소들이 필요하지만, 각각의 구성 요소들이 유기적으로 운영되기 위해서는 인프라 레벨에서 수많은 이슈들을 해결해야 합니다. -간단하게는 수많은 머신러닝 모델의 학습 요청을 순차적으로 실행 하는 것, 다른 작업 공간에서도 동일한 실행 환경을 보장해야 하는 것, 배포된 서비스에 장애가 생겼을 때 빠르게 대응해야 하는 것 등의 이슈 등을 생각해볼 수 있습니다. +성공적인 MLOps 시스템을 구축하기 위해서는 [MLOps의 구성요소]({{< relref "docs/introduction/component.md" >}}) 에서 설명한 것처럼 다양한 구성 요소들이 필요하지만, 각각의 구성 요소들이 유기적으로 운영되기 위해서는 인프라 레벨에서 수많은 이슈들을 해결해야 합니다. +간단하게는 수많은 머신러닝 모델의 학습 요청을 순차적으로 실행 하는 것, 다른 작업 공간에서도 동일한 실행 환경을 보장해야 하는 것, 배포된 서비스에 장애가 생겼을 때 빠르게 대응해야 하는 것 등의 이슈 등을 생각해볼 수 있습니다. 여기서 컨테이너(Container)와 컨테이너 오케스트레이션 시스템(Container Orchestration System)의 필요성이 등장합니다. 쿠버네티스와 같은 컨테이너 오케스트레이션 시스템을 도입하면 실행 환경의 격리와 관리를 효율적으로 수행할 수 있습니다. 컨테이너 오케스트레이션 시스템을 도입한다면, 머신러닝 모델을 개발하고 배포하는 과정에서 다수의 개발자가 소수의 클러스터를 공유하면서 *'1번 클러스터 사용 중이신가요?', 'GPU 사용 중이던 제 프로세스 누가 죽였나요?', '누가 클러스터에 x 패키지 업데이트 했나요?'* 와 같은 상황을 방지할 수 있습니다. @@ -28,12 +28,12 @@ menu: > 컨테이너란 : 애플리케이션의 표준화된 이식 가능한 패키징 -그런데 왜 머신러닝에서 컨테이너가 필요할까요? 머신러닝 모델들은 운영체제나 Python 실행 환경, 패키지 버전 등에 따라 다르게 동작할 수 있습니다. +그런데 왜 머신러닝에서 컨테이너가 필요할까요? 머신러닝 모델들은 운영체제나 Python 실행 환경, 패키지 버전 등에 따라 다르게 동작할 수 있습니다. 이를 방지하기 위해서 머신러닝에 사용된 소스코드와 함께 종속적인 실행 환경 전체를 **하나로 묶어서(패키징해서)** 공유하고 실행하는 데 활용할 수 있는 기술이 컨테이너라이제이션(Containerization) 기술입니다. -이렇게 패키징된 형태를 컨테이너 이미지라고 부르며, 컨테이너 이미지를 공유함으로써 사용자들은 어떤 시스템에서든 동일한 실행 결과를 보장할 수 있게 됩니다. +이렇게 패키징된 형태를 컨테이너 이미지라고 부르며, 컨테이너 이미지를 공유함으로써 사용자들은 어떤 시스템에서든 동일한 실행 결과를 보장할 수 있게 됩니다. 즉, 단순히 Jupyter Notebook 파일이나, 모델의 소스코드와 requirements.txt 파일을 공유하는 것이 아닌, 모든 실행 환경이 담긴 컨테이너 이미지를 공유한다면 *"제 노트북에서는 잘 되는데요?"* 와 같은 상황을 피할 수 있습니다. -컨테이너를 처음 접하시는 분들이 흔히 하시는 오해 중 하나는 "**컨테이너 == 도커**"라고 받아들이는 것입니다. +컨테이너를 처음 접하시는 분들이 흔히 하시는 오해 중 하나는 "**컨테이너 == 도커**"라고 받아들이는 것입니다. 도커는 컨테이너와 동일한 의미를 지니는 개념이 아니라, 컨테이너를 띄우거나, 컨테이너 이미지를 만들고 공유하는 것과 같이 컨테이너를 보다 쉽고 유연하게 사용할 수 있는 기능을 제공해주는 도구입니다. 정리하자면 컨테이너는 가상화 기술이고, 도커는 가상화 기술의 구현체라고 말할 수 있습니다. 다만, 도커는 여러 컨테이너 가상화 도구 중에서 쉬운 사용성과 높은 효율성을 바탕으로 가장 빠르게 성장하여 대세가 되었기에 컨테이너하면 도커라는 이미지가 자동으로 떠오르게 되었습니다. 이렇게 컨테이너와 도커 생태계가 대세가 되기까지는 다양한 이유가 있지만, 기술적으로 자세한 이야기는 *모두의 MLOps*의 범위를 넘어서기 때문에 다루지는 않겠습니다. @@ -44,15 +44,15 @@ menu: 그렇다면 컨테이너 오케스트레이션 시스템은 무엇일까요? **오케스트레이션**이라는 단어에서 추측해 볼 수 있듯이, 수많은 컨테이너들이 있을 때 컨테이너들이 서로 조화롭게 구동될 수 있도록 지휘하는 시스템에 비유할 수 있습니다. -컨테이너를 도입이 되면 서비스는 컨테이너의 형태로 사용자들에게 제공됩니다. 이 때 관리해야 할 컨테이너의 수가 적다면 운영 담당자 한 명이서도 충분히 모든 상황에 대응할 수 있습니다. +컨테이너를 도입이 되면 서비스는 컨테이너의 형태로 사용자들에게 제공됩니다. 이 때 관리해야 할 컨테이너의 수가 적다면 운영 담당자 한 명이서도 충분히 모든 상황에 대응할 수 있습니다. 하지만, 수 백 개 이상의 컨테이너가 수 십 대 이상의 클러스터에서 구동되고 있고 장애를 일으키지 않고 항상 정상 동작해야 한다면, 모든 서비스의 정상 동작 여부를 담당자 한 명이 파악하고 이슈에 대응하는 것은 불가능에 가깝습니다. -예를 들면, 모든 서비스가 정상적으로 동작하고 있는지를 계속해서 모니터링(Monitoring)해야 합니다. -만약, 특정 서비스가 장애를 일으켰다면 여러 컨테이너들의 로그를 확인해가며 문제를 파악해야 합니다. +예를 들면, 모든 서비스가 정상적으로 동작하고 있는지를 계속해서 모니터링(Monitoring)해야 합니다. +만약, 특정 서비스가 장애를 일으켰다면 여러 컨테이너들의 로그를 확인해가며 문제를 파악해야 합니다. 또한 특정 클러스터나 특정 컨테이너에 작업이 몰리지 않도록 스케줄링(Scheduling)하고 로드 밸런싱(Load Balancing)하며, 스케일링(Scaling)하는 등의 수많은 작업을 담당해야 합니다. -이렇게 수많은 컨테이너들의 상태를 지속적으로 관리하고 운영하는 과정을 조금이나마 쉽게, 자동으로 할 수 있는 기능을 제공해주는 소프트웨어가 바로 컨테이너 오케스트레이션 시스템입니다. +이렇게 수많은 컨테이너들의 상태를 지속적으로 관리하고 운영하는 과정을 조금이나마 쉽게, 자동으로 할 수 있는 기능을 제공해주는 소프트웨어가 바로 컨테이너 오케스트레이션 시스템입니다. -머신러닝에서는 어떻게 쓰일 수 있을까요? +머신러닝에서는 어떻게 쓰일 수 있을까요? 예를 들어서 GPU를 필요로 하는 딥러닝 학습 코드가 패키징된 컨테이너는 사용 가능한 GPU가 있는 클러스터에서 수행하고, 많은 메모리를 필요로 하는 데이터 전처리 코드가 패키징된 컨테이너는 메모리의 여유가 많은 클러스터에서 수행하고, 학습 중에 클러스터에 문제가 생기면 자동으로 동일한 컨테이너를 다른 클러스터로 이동시키고 다시 학습을 진행하는 등의 작업을 사람이 일일히 수행하지 않고, 자동으로 관리하는 시스템을 개발한 뒤 맡기는 것입니다. 집필을 하는 2022년을 기준으로 쿠버네티스는 컨테이너 오케스트레이션 시스템의 사실상의 표준(De facto standard)입니다. diff --git a/content/en/docs/setup-components/install-components-kf.md b/content/en/docs/setup-components/install-components-kf.md index 40fadadf..5d9bf6fc 100644 --- a/content/en/docs/setup-components/install-components-kf.md +++ b/content/en/docs/setup-components/install-components-kf.md @@ -25,8 +25,8 @@ cd manifests ## 각 구성요소별 설치 -kubeflow/manifests Repository 에 각 구성요소별 설치 커맨드가 적혀져 있지만, 설치하며 발생할 수 있는 이슈 혹은 정상적으로 설치되었는지 확인할 수 있는 방법 등이 적혀져있지 않아 처음 설치하는 경우 어려움을 겪는 경우가 많습니다. -따라서, 각 구성요소별로 정상적으로 설치되었는지 확인하는 방법을 함께 작성합니다. +kubeflow/manifests Repository 에 각 구성요소별 설치 커맨드가 적혀져 있지만, 설치하며 발생할 수 있는 이슈 혹은 정상적으로 설치되었는지 확인할 수 있는 방법 등이 적혀져있지 않아 처음 설치하는 경우 어려움을 겪는 경우가 많습니다. +따라서, 각 구성요소별로 정상적으로 설치되었는지 확인하는 방법을 함께 작성합니다. 또한, 본 문서에서는 **모두의 MLOps** 에서 다루지 않는 구성요소인 Knative, KFServing, MPI Operator 의 설치는 리소스의 효율적 사용을 위해 따로 설치하지 않습니다. @@ -61,7 +61,7 @@ kustomize build common/cert-manager/kubeflow-issuer/base | kubectl apply -f - - cert-manager-webhook 이슈 - cert-manager-webhook deployment 가 Running 이 아닌 경우, 다음과 비슷한 에러가 발생하며 kubeflow-issuer가 설치되지 않을 수 있음에 주의하기시 바랍니다. + cert-manager-webhook deployment 가 Running 이 아닌 경우, 다음과 비슷한 에러가 발생하며 kubeflow-issuer가 설치되지 않을 수 있음에 주의하기시 바랍니다. 해당 에러가 발생한 경우, cert-manager 의 3 개의 pod 가 모두 Running 이 되는 것을 확인한 이후 다시 명령어를 수행하시기 바랍니다. ```text @@ -242,7 +242,7 @@ kustomize build apps/pipeline/upstream/env/platform-agnostic-multi-user | kubect 따라서 경우에 따라 다음과 비슷한 에러가 발생할 수 있습니다. ```text -"error: unable to recognize "STDIN": no matches for kind "CompositeController" in version "metacontroller.k8s.io/v1alpha1"" +"error: unable to recognize "STDIN": no matches for kind "CompositeController" in version "metacontroller.k8s.io/v1alpha1"" ``` 위와 비슷한 에러가 발생한다면, 10 초 정도 기다린 뒤 다시 위의 명령을 수행합니다. diff --git a/content/en/docs/setup-components/install-components-pg.md b/content/en/docs/setup-components/install-components-pg.md index 02f2ac7d..fdf9d1b4 100644 --- a/content/en/docs/setup-components/install-components-pg.md +++ b/content/en/docs/setup-components/install-components-pg.md @@ -14,8 +14,8 @@ images: [] ## Prometheus & Grafana -프로메테우스(Prometheus) 와 그라파나(Grafana) 는 모니터링을 위한 도구입니다. -안정적인 서비스 운영을 위해서는 서비스와 서비스가 운영되고 있는 인프라의 상태를 지속적으로 관찰하고, 관찰한 메트릭을 바탕으로 문제가 생길 경우 빠르게 대응해야 합니다. +프로메테우스(Prometheus) 와 그라파나(Grafana) 는 모니터링을 위한 도구입니다. +안정적인 서비스 운영을 위해서는 서비스와 서비스가 운영되고 있는 인프라의 상태를 지속적으로 관찰하고, 관찰한 메트릭을 바탕으로 문제가 생길 경우 빠르게 대응해야 합니다. 이러한 모니터링을 효율적으로 수행하기 위한 많은 도구 중 *모두의 MLOps*에서는 오픈소스인 프로메테우스와 그라파나를 사용할 예정입니다. 보다 자세한 내용은 [Prometheus 공식 문서](https://prometheus.io/docs/introduction/overview/), [Grafana 공식 문서](https://grafana.com/docs/)를 확인해주시기 바랍니다. diff --git a/content/en/docs/setup-components/install-components-seldon.md b/content/en/docs/setup-components/install-components-seldon.md index 93dbd66b..705809f5 100644 --- a/content/en/docs/setup-components/install-components-seldon.md +++ b/content/en/docs/setup-components/install-components-seldon.md @@ -14,12 +14,12 @@ images: [] ## Seldon-Core -Seldon-Core는 쿠버네티스 환경에 수많은 머신러닝 모델을 배포하고 관리할 수 있는 오픈소스 프레임워크 중 하나입니다. +Seldon-Core는 쿠버네티스 환경에 수많은 머신러닝 모델을 배포하고 관리할 수 있는 오픈소스 프레임워크 중 하나입니다. 보다 자세한 내용은 Seldon-Core 의 공식 [제품 설명 페이지](https://www.seldon.io/tech/products/core/) 와 [깃헙](https://github.com/SeldonIO/seldon-core) 그리고 API Deployment 파트를 참고해주시기 바랍니다. ## Selon-Core 설치 -Seldon-Core를 사용하기 위해서는 쿠버네티스의 인그레스(Ingress)를 담당하는 Ambassador 와 Istio 와 같은 [모듈이 필요합니다](https://docs.seldon.io/projects/seldon-core/en/latest/workflow/install.html). +Seldon-Core를 사용하기 위해서는 쿠버네티스의 인그레스(Ingress)를 담당하는 Ambassador 와 Istio 와 같은 [모듈이 필요합니다](https://docs.seldon.io/projects/seldon-core/en/latest/workflow/install.html). Seldon-Core 에서는 Ambassador 와 Istio 만을 공식적으로 지원하며, *모두의 MLOps*에서는 Ambassador를 사용해 Seldon-core를 사용하므로 Ambassador를 설치하겠습니다. ### Ambassador - Helm Repository 추가 From 80838668cf63363720a1dadfc538c8f352515331 Mon Sep 17 00:00:00 2001 From: Aiden-Jeon Date: Mon, 13 Dec 2021 21:36:14 +0900 Subject: [PATCH 3/3] remove trim trailing space --- .pre-commit-config.yaml | 1 - 1 file changed, 1 deletion(-) diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml index 06fb8665..893853f5 100644 --- a/.pre-commit-config.yaml +++ b/.pre-commit-config.yaml @@ -4,7 +4,6 @@ repos: - repo: https://github.com/pre-commit/pre-commit-hooks rev: v2.5.0 hooks: - - id: trailing-whitespace - id: end-of-file-fixer - id: mixed-line-ending - id: check-added-large-files