개요
Kubeflow를 통해 ML Ops 생태계를 이해하고, 전 주기 파이프라인를 구성해본다.
목표
Kubeflow와 Service Mesh의 개념을 학습하고, 어떤 관계를 가지는지 알아보자.
여정
ML Ops와 Kubeflow
ML Ops
- 프로덕션 환경에서 ML 모델을 안정적, 효율적으로 배포 및 유지 관리하는 방법론
- ML 시스템 개발(Dev)과 ML 시스템 운영(Ops)의 합성어
Kubeflow
- 머신러닝 워크플로우를 구축하고 배포하기 위한 Orchestration 플랫폼
- 쿠버네티스를 사용하는 머신러닝 도구 모음(Toolkit)
- 크게 모델 실험 → 모델 생산 의 과정으로 이루어져 있다.
Kubeflow 는 ML 관련 프레임워크, 도구, 서비스의 집합이다.
따라서, 이러한 환경을 연결하기 위해서는 Service Mesh가 필요하다.
Service Mesh와 Istio
알고 가야할 Multi-Container 디자인 패턴
Service Mesh를 이해하기 전, 알고가야할 개념이 있다.
바로 Multi-Container 디자인 패턴이다.
<대전제>
하나의 컨테이너에는 하나의 책임만 있어야 한다.
Multi-Container 디자인 패턴이란,
복잡해진 Container 기반 Cluster 환경(주로 MSA 환경)에서
단일 책임 원칙을 통해 강인한(robustic) 환경을 구축하는 디자인 패턴이다.
- Sidecar 패턴 : 서로 다른 역할을 하는 서비스는 각각의 컨테이너로 분리하는 패턴
- ex) 웹서버와 로그수집기는 각각 다른 컨테이너로 존재해야함
- Adapter 패턴 : 메인 컨테이너의 출력을 표준화시키는 Adapter 컨테이너를 두는 패턴
- ex) Metric 컨테이너
- Ambassador 패턴 : 메인 컨테이너에게 네트워크를 전담하는 Proxy 컨테이너를 두는 패턴
Service Mesh란?
Service Mesh란,
애플리케이션 트래픽을 제어하기 위해
플랫폼 레이어에 구성되는 네트워크 제어 방법이다.
Service Mesh는 Multi-Container 디자인 패턴을 적용하여 아래의 장점을 가지게 된다.
- 컨테이너 기반의 분산 아키텍쳐(ex : Kubernetes-based system)의 복잡도를 감소시켜줌 → Sidecar, Ambassador
- 대표 기능은 3가지 : 애플리케이션 트래픽 관리, 관찰 가능성(observability), 보안 → Adapter
- 구성 요소는 2가지
- 데이터 플레인(L7 프록시) : 서비스와 프록시 호출
- 컨트롤 플레인(L4 ~ L6 프록시) : 서비스 검색, TLS 인증, 메트릭 수집 등
서비스 메시는 신뢰성, 보안성, 가시성을 제공하지만
그만큼 무겁고, 트러블슈팅 구간이 증가한다.
따라서, 도입전 철저한 검토와 논의가 필요하다.
(좀 더 자세한 내용은 여기를 참조)
여기서 프록시(Proxy)라는 개념이 자주 등장하는데,
우리가 흔히 알고있는 프록시와는 역할에 일부 차이가 있다.
우리가 기존에 알고있던 프록시는 L7 계층(어플리케이션 레이어)에서 트래픽을 중계한다.
하지만, Service Mesh에서 사용하는 프록시는 더욱 다양한 역할을 할 수 있다.
이 때 사용되는 프록시가 Envoy Proxy이다.
Envoy Proxy란?
<대전제>
네트워크는 애플리케이션에 투명해야하며,
장애가 발생했을시 어디에서 문제가 발생했는지 쉽게 파악할 수 있어야 한다.
C++로 개발된 고성능 프록시 Sidecar이다.
주로 L7 기능을 하지만 L3, L4 기능도 지원한다. (자동 재시도, circuit break, 이상치 탐지 등)
자, 이제 Service Mesh를 구현한 오픈소스인 Istio에 대해 알아보자.
Istio란?
- Service Mesh를 제공하는 오픈소스
- 아래의 절차를 거쳐 트래픽을 전달한다.
1. 클라이언트가 특정 포트에 요청을 전송한다.
2. Load Balancer 는 이 포트에서 요청을 받아 워커 노드 중 하나로 포워딩한다.
3. 클러스터 내에서 해당 요청은 Istio IngressGateway Service 로 라우팅된다.
Ingress-gateway는 k8s에서 Gateway를 구현하기 위한 실제 Pod로,
Service + Deployment로 되어 있다.
4. Istio IngressGateway Service 는 이 요청을 Istio IngressGateway Pod 로 포워딩한다.
5. Istio IngressGateway Pod 는 Gateway 와VirtualService로 구성된다.
6. Gateway 는 포트, 프로토콜, 인증서와 같은 L4 ~ L6 스위치 역할을 구성한다.
7. VirtualService 는 올바른 Service를 찾기 위한 라우팅 정보를 구성한다.
8. 다시말해, Istio IngressGateway Pod 는 요청을 application Service로 라우팅한다.
9. 최종적으로, application Service 는 요청을 application Pod 에 전달한다.
한편, Istio를 사용한다고 해서 반드시 Istio gateway를 사용해야 하는 것은 아니다.
기존의 Kubernetes Ingress를 그대로 사용할 수 도 있고,
Kong 과 같은 API gateway를 사용하는 것도 가능하다.
Kubeflow에서 Service Mesh 구성
Q & A
- Kubeflow와 Airflow의 차이가 무엇인가요?
Airflow와 Kubeflow는
서로 다른 목적을 위해 만들어진 툴이기 때문에,
서로가 대안이 될 수는 없다.
(Airflow가 Kubeflow와 동일한 역할을 하려면 MLflow와 결합해야한다.)
좀 더 자세한 차이는 아래와 같다.
| Airflow | Kubeflow | |
| 형태 | DAG 기반 워크플로우 | Pipeline 기반 워크플로우 |
| 목적 | task(pipeline) orchestration | ML 학습, 실험 추적 등 ML 작업 |
| 특징 | 데이터 파이프라인, ML 모델링, 인프라 관리 등 다양한 작업 |
ML 작업에 특화 |
| 환경 | 다양한 환경에서 작업 가능 | 쿠버네티스 환경에 최적화 |
Kubeflow의 Pipeline은 각각 작업(task)이
up/downstream을 최대 하나씩밖에 가지지 못하는, 제한된 형태의 DAG 형태이다.
반면에, Airflow의 DAG는
각 task들이 서로 다른 dependency를 가지고 있다는 차이가 있다.
양측 다 DAG가 다양한 Upstream/Downstream Dependency를 가질 수 있다
마무리
이번 시간에는 본격적인 실습에 앞서
ML Ops와 Service Mesh의 개념과
앞으로도 자주 쓰이는 개념들(특히, Sidecar 프록시)에 대해 알아보았다.
다음 편에서는 ML 컨테이너 이미지를 동작할 수 있는 GPU 환경을 구성할 것이다.
참고자료
Service Mesh Architecture & Istio를 알아보자 - 호롤리한 하루 (gruuuuu.github.io)
'DevOps' 카테고리의 다른 글
| Kubeflow 라이징 - Kubeflow 설치 및 대시보드 접속 (0) | 2023.03.04 |
|---|---|
| Kubeflow 라이징 - GPU 워커노드 환경 구성 (0) | 2023.03.02 |
| CI/CD Pipeline - 클러스터에 Private 저장소 이미지 배포하기 (0) | 2023.02.23 |
| CKA 뽀개기 - Application Multi Container Issue (0) | 2023.02.21 |
| CKA 뽀개기 - Application Misconfigured (0) | 2023.02.20 |
