KFP Version2 뭐가 바뀌냐?

• 리얼 요약 : more meta data, more control

요약

• 더 깔끔한 데코레이터 형식
• more meta data(=Data Management)
  • KFP 버전2 업그레이드에서는 MLMD 스토어로 , 로그(커스텀포함)를 저장한다.
  • machine learning pipeline에 의해 생성된 모든 데이터와 그것이 어떻게 computing되었는지 쉽게 추적할 수 있게 한다!!!!!!
  • MLMD 강화된 표현을 위한 UI 변경
• more control
  • 컴파일러를 더 멍청하게, 그리고 런타임 주입을 강화하는 형태로, argo yaml 에서 독립할 수 있는, runtime 으로 주입시키는 형태로 가려고 한다. (argo yaml 에서의 한계를 느껴서 컴파일러에 제약을 두고 런타임에 초점을 두려합니다. )
  • KFP를 re-architecture해서 런타임 동작을 더 많이 제어할 수 있도록 하는 것은 KFP의 장기적인 목표를 달성하는 데 이상적이라 생각되어 이 파트가 생긴듯한데, 아직 핵심 기능이다! argo 랑 우리랑 다르다! 할 레벨은 아닌 거같아요.
• Be backward compatible with KFP v1
  • 하위 호환성을 가진다.
  • 기존 피처에 대해 , 쉽게 업그레이드 가능하고, 양립 가능하게 두고 싶었다.

이것이 될 것같습니다. 라고 2023/07/02 일 적습니다.

새로운 용어들이 많아서 날잡아서 봐야지 봐야지했는데 아직 제 마음으로는 기대한거... 아까운거같아요,, 아까워!!! 아까워!! 남들이 극찬하면,, 그제서야 마음이 바뀌려나요,, 아직 제눈엔 에어팟 콩나물 당시의 윙? 왜? 느낌입니다.

참고문헌은 이렇게 됩니다.

• kfp v2 version 발표 : https://docs.google.com/presentation/d/1HzMwtI2QN67xQp2lSxmuXhitEsukLB7mvZx4KAPub3A/edit#slide=id.gb4a3fac3a8_7_2017
• 실제 kfp v2 system design
• https://docs.google.com/document/d/1fHU29oScMEKPttDA1Th1ibImAKsFVVt2Ynr4ZME05i0/edit#heading=h.j4rlx69s50vy
• 도큐먼트 :
  • https://www.kubeflow.org/docs/components/pipelines/sdk/v2/
  • SDK changes
    • https://github.com/kubeflow/pipelines/tree/master/sdk/python/kfp/v2

키워드 정리

키워드 : IR, MLMD (https://github.com/google/ml-metadata), CUJ

• KFP IR == v2 버전의 full-feature KFP pipeline spec
• MLMD :
  • ML Metadata (MLMD) is a library for recording and retrieving metadata associated with ML developer and data scientist workflows.
• CUJ
  • CUJ는 Critical User Journey의 약자입니다. 새로운 코어 CUJ는 KFP v2의 가장 기본적인 CUJ 추가 사항입니다. ui 가 좀 바뀐다고 하네요.

MLMD 는 그럼 v1때는 지원 안했었나요?

• v1 버전 kfp 에서는metadata-writer 가 파이프라인 status 를 확인하고, MLMD 에 적용하는 addon 이었지만, metadat-writer 가 파이프라인 수행과 비동기였어서, MLMD 에 순서대로 로깅된다는 보장이 없었습니다. 그래서 v1 + metatdata-writer 은 race condition 에 빠질 수있는 위험이 있었다 하네요.

아키텍처의 변화

v1 아키텍처

v2 아키텍처

v1과비교했을때, 이제는 MLMD, 보다 "watch", 바라보게 되어있는 구조인데요,

KFP pipeline 라이프사이클 흐름은 - 사용자 written DSL에서 Kubernetes에서 실행되는 것까지 - 이렇게 된다.

1. 사용자는 KFP/TFX DSL을 이용하여 파이프라인을 작성합니다.
2. 사용자는 해당 SDK를 사용하여 DSL로 파이프라인을 파이프라인 spec(jsonpb 형식)으로 컴파일합니다.
3. 사용자는 UI/API를 통해 파이프라인 사양을 KFP 서비스에 업로드합니다.
4. KFP 서비스의 백엔드 컴파일러는 파이프라인 사양을 argo 워크플로우 사양(또는 tekton 파이프라인 사양)으로 컴파일합니다
5. KFP 서비스는 Kubernetes API 서버에 argoworkflow spec을 submit합니다
6. Argo workflow controller는 argo workflow를 감시하고 운영합니다. 실제 사용자 컨테이너를 실행하는 Pod를 만듭니다.
7. Pod는 아티팩트를 object store에서 로드/저장하고 아티팩트 메타데이터를 MLMD 저장소에 기록합니다.
8. Argo workflow controller는 Pod를 watch하고 workflow custom resource status field에서 argo workflow status를 업데이트합니다.
9. Persistence Agent는 argo workflow status를 보고 KFP 서비스에 다시 보고합니다.
10. KFP 서비스는 KFP DB에 상태를 기록합니다.
11. 사용자는 KFP DB의 데이터를 읽어주는 KFP 서비스에서 파이프라인 실행 상태에 액세스합니다.

이런식으로 바뀝니다.

이러한 단계의 대부분은 여전히 KFP v1과 매우 유사합니다.
주요 변경 사항은 KFP/TFX SDK가 사용자 DSL을 v2의 파이프라인 사양으로 컴파일하지만 DSL은 v1의 argo 워크플로우 사양으로 직접 컴파일된다는 것입니다.

New Core CUJs

• CUJ : Critical User Journey
• Machine Learning Metadata (MLMD)와의 네이티브 통합이 v2 에서의 핵심이였던 것과 마찬가지로, UI 에서도 MLMD 표현에 힘을 준 것을 확인할 수 있습니다. 이렇게 run 을 수행했을때, 아티팩트 ui 가 확인할수 있습니다.
• https://www.kubeflow.org/docs/components/pipelines/v1/sdk-v2/run-comparison/
•  
• 
• 
•  

moving from smart compiler to smart runtime

• v1에서 KFP 컴파일러는 매우 "스마트"하며, 모든 KFP 파이프라인 의미를 아르고 워크플로우(예: 매개 변수/아티팩트를 아르고 매개 변수/아티팩트로 변환)으로 표현하는 방법을 알고 있었지만, v2에서 KFP 컴파일러는 "멍청이"가 되고, 오직 다음과 같은 것만 책임집니다.
  • 스케줄링 : scheduling KFP tasks in the right order
  • input 제대로 넣어주기 : inject KFP runtime into KFP tasks with related KFP pipeline spec as input

Special KFP runtime은 standalone Pods 혹은 entrypoint로 스펙에 주입되어, life cycle 과 data passing 에 동적으로 이용됩니다.

이게 중요한 이유가, "스마트 컴파일러"는 argo 지원 기능만 구현할 수 있지만, "스마트 런타임"은 우리가 원하는 모든 것을 구현할 수 있기때문에, 런타임동작에 control 권한을 높였습니다.

아래 다이어그램은 개념적 KFP 작업이 드라이버로부터 입력을 받고 게시자에 결과를 게시하는 방법을 보여줍니다.

• Driver: MLMD에서 필요한 정보를 읽고 캐싱을 결정한 후 [podSpecPatch](https://argoproj.github.io/argo/fields/ #workflowtemplatespec)을 반환하여 실행자에게 적용합니다(다음 섹션의 podSpecPatch 설명).
• Executor: 명령 및 인수를 사용하여 사용자 지정 이미지를 실행하는 사용자 컨테이너입니다.
• Publisher: 실행자에서 읽은 MLMD 메타데이터를 MLMD에 게시합니다. 게시자는 정적으로 컴파일된 바둑 바이너리에 내장되어 있으며 실행자 포드의 진입점으로 주입됩니다.

SDK 의 변화는?

Metadata, Simplified Component Authoring

Current State

Three Versions of the KFP SDK

현재는 SDK 에 3버전이 있는데요, 특징은 이렇습니다.

• v1
  • argo YAML 을 생산하는 레거시 모드.
  • IR 에서 metadata-based 편리함을 느끼는 것이 불가능
• v2-compatible
  • argo yaml 생성하는 것은 동일하지만,
  • init container 를 도입해 , v2 컴포넌트를 실행할 수 있고, MLMD 에 메타데이터를 recording 할수 있습니다.
• v2 :
  • IR 을 생산하고, MLMD 에 메타데이터를 recorging 할수 있습니다.

Lots of incompatibilities(불일치)

각각의 SDK 가 모두 서로 호환이 되는 것이 아닌 각각의 차이가 있는 상황입니다.

• v1 only : 각각의 feature 가 1 container 이고, input , output 이 필수가 아닙니다.
• v1 and v2-compatible only:
  • IR 을 지원하지 않는다. (예. Init_container, sidecar 를 pipeline step 에 넣는 것이 불가능함)
• v2 and v2-compatible only:
  • v2 Python-based components fall under this category
• v2 only:
  • Advanced metadata features such as Importer and Resolver.

Streamlined Component Authoring

• 좀 더 깔끔해진 component decorator형태입니다. 이전에는 python component 를 위해 다양한 컴포넌트 데코레이터를 이용했다면,
• 이제는 통일된 형태인 @Component annotations을 이용해 다양한 타입들의 컴포넌트 제작을 지원합니다.
•  

create_component_from_func둘 func_to_container_op다 KFP SDK v1에서 가벼운 Python 함수 기반 구성 요소를 만드는 데 사용됩니다.

두 기능 모두 KFP SDK v2에서 제거되었습니다.

 

Continued Support for YAML components

여전히 load_component_from_url 로 YAML based components를 불러 올 수 있습니다.


migrate v1 to v2

https://www.kubeflow.org/docs/components/pipelines/v2/migration/

해당 문서에 잘 나와있습니다. 문서를 참고하시는 것도 좋을 것같아요!