ML 런타임과 워크스페이스 구조

Databricks Certified Machine Learning Associate는 채점 문항 48개 중 38%가 「Databricks Machine Learning」 영역입니다. 이 영역은 알고리즘을 묻는 자리가 아니라 Databricks라는 판 위에서 머신러닝 작업을 어떻게 배치하는가를 묻는 자리입니다. 클러스터를 잘못 고르면 라이브러리가 아예 없고, 단일 노드에 Spark ML을 올리면 병렬이 안 되고, 노트북에만 코드를 두면 일정 실행이 안 됩니다. 첫 노트는 그 판의 모양을 그립니다.

런타임 두 갈래

Databricks Runtime(DBR)은 클러스터에 깔려 돌아가는 소프트웨어 묶음의 이름입니다. Apache Spark, Delta Lake, 자바·스칼라·파이썬 런타임과 그 위의 라이브러리들이 버전으로 묶여 있고, 클러스터를 만들 때 하나를 고릅니다.

여기에 Databricks Runtime for Machine Learning(줄여서 ML 런타임)이 따로 있습니다. 표준 런타임의 모든 것을 그대로 담고 그 위에 머신러닝 라이브러리를 미리 깔아 둔 판입니다. 미리 깔린 것 중 시험이 이름으로 묻는 것은 이 넷입니다.

여기에 PyTorch·TensorFlow 같은 딥러닝 프레임워크와 피처 엔지니어링 클라이언트가 함께 들어 있고, GPU를 쓰는 클러스터를 위한 GPU 판이 따로 있습니다. 표준 런타임에서 import mlflow를 하면 없습니다. 「노트북에서 scikit-learn을 못 찾는다」는 시나리오의 첫 번째 답은 %pip install이 아니라 클러스터를 ML 런타임으로 다시 만드는 것입니다.

런타임 버전을 고르는 기준도 문항이 됩니다. LTS(Long Term Support)가 붙은 버전은 지원 기간이 길어 오래 도는 운영 작업에 맞고, 최신 버전은 새 기능이 먼저 들어오지만 지원 기간이 짧습니다. 그래서 「이 파이프라인은 앞으로 몇 달간 매일 돈다」는 조건이 붙으면 LTS 쪽입니다.

노드를 하나 둘 것인가 여럿 둘 것인가

클러스터는 드라이버(driver) 하나와 워커(worker) 여럿으로 이뤄집니다. 드라이버는 코드를 받아 작업을 쪼개고, 워커는 쪼개진 조각을 나눠 실행합니다.

단일 노드 클러스터는 워커가 없고 드라이버 한 대만 있는 클러스터입니다. Spark는 로컬 모드로 돌고, 실질적으로는 한 대짜리 머신입니다. 멀티 노드 클러스터는 드라이버에 워커가 붙어 데이터와 계산이 여러 대에 나뉩니다.

가르는 질문은 하나입니다 — 쓰려는 라이브러리가 분산되는가.

세 번째 줄이 헷갈리는 자리입니다. 모델 자체는 한 대에서 돌아도 탐색은 병렬이 됩니다. scikit-learn 모델 하나는 워커 한 대가 통째로 학습하고, 서로 다른 하이퍼파라미터 조합을 워커들이 나눠 맡습니다. 그래서 「scikit-learn을 쓰니 단일 노드」는 성급한 답입니다.

반대 방향의 함정도 있습니다. 데이터가 수십 MB인데 멀티 노드를 띄우면 네트워크로 데이터를 나르는 비용만 늘고 빨라지지 않습니다. 데이터 크기와 라이브러리를 함께 보고 고릅니다.

노트북에서 Git 폴더로, 그리고 Jobs로

작업 흐름은 세 칸으로 이어집니다.

1. 노트북(Notebook)에서 탐색하고 모델을 만듭니다. 셀 단위로 돌아가고 결과가 바로 보이는 대화형 자리입니다.
2. Repos(지금 화면 이름은 Git 폴더)로 그 노트북을 Git 저장소에 묶습니다. 워크스페이스 안에서 브랜치를 만들고 커밋·풀을 할 수 있어, 코드 검토와 버전 관리가 노트북에도 그대로 붙습니다.
3. Jobs로 일정과 순서를 겁니다. 여러 작업(task)을 의존 관계로 잇고, 각 작업이 어느 클러스터에서 돌지, 언제 돌지, 실패하면 몇 번 다시 시도할지를 정합니다.

이 세 칸이 시험에서 곧바로 문항이 되는 이유는, 「매일 밤 재학습」 같은 요구가 나오면 답이 노트북이 아니라 Jobs이기 때문입니다. 노트북은 사람이 열어야 돌고, Jobs는 사람이 없어도 돕니다.

없는 라이브러리를 더할 때

ML 런타임에도 없는 것을 써야 하는 날이 옵니다. 더하는 자리가 둘이고, 미치는 범위가 다릅니다.

• 노트북 범위 설치는 노트북 안에서 %pip install을 돌리는 것입니다. 그 노트북에만 붙고, 셀을 돌리면 파이썬 인터프리터가 다시 뜹니다.
• 클러스터 라이브러리는 클러스터 설정에 등록하는 것입니다. 그 클러스터에 붙은 모든 노트북과 Job에 적용되고 클러스터가 뜰 때 함께 설치됩니다.

가르는 기준은 「누가 이것을 쓰는가」입니다. 혼자 실험하는 동안은 노트북 범위가 편하고, Job으로 매일 도는 파이프라인이 그 라이브러리에 의존한다면 클러스터 라이브러리로 못 박아야 합니다. 노트북 범위 설치는 Job이 새 클러스터를 띄울 때 함께 살아나지 않습니다.

%pip install imbalanced-learn==0.12.3
dbutils.library.restartPython()

%pip은 반드시 노트북 맨 위 셀에 두는 것이 안전합니다. 인터프리터가 다시 뜨면서 그 위에서 만든 변수가 사라지기 때문입니다.

코드를 올릴 것인가 모델을 올릴 것인가

MLOps는 개발·스테이징·운영 세 환경을 두고 그 사이로 무엇을 옮길지를 정하는 일입니다. 옮기는 것이 둘 중 하나입니다.

• 모델 승격(deploy models): 개발 환경에서 학습한 모델 파일을 스테이징·운영으로 옮깁니다.
• 코드 승격(deploy code): 학습 코드를 옮기고, 모델은 각 환경에서 그 환경의 데이터로 다시 학습합니다.

Databricks가 권하는 기본은 코드 승격입니다. 운영 데이터에 접근할 수 있는 곳은 운영 환경뿐인 경우가 많고, 코드가 Git으로 검토·버전 관리되는 대상이라 감사에도 맞기 때문입니다. 모델 승격은 학습 비용이 아주 크거나 운영 환경에서 학습을 돌릴 수 없을 때 고릅니다.

여기서 세 칸이 각각 무엇을 담는지가 정해집니다. 개발 환경은 사람이 노트북을 열고 만드는 자리이고, 스테이징은 코드가 합쳐질 때 테스트가 도는 자리이며, 운영은 Job이 정해진 시각에 학습하고 배포하는 자리입니다. 그래서 개발에서 잘 돌던 노트북이 운영에서 깨지는 가장 흔한 이유가 「그 클러스터에만 손으로 깔아 둔 라이브러리」입니다. 바로 위 절의 갈래가 이 자리에서 값을 합니다.

어느 쪽이든 환경 사이를 잇는 것은 Unity Catalog입니다. 데이터도 모델도 카탈로그 이름으로 갈리고 권한도 거기서 나옵니다. 그 이야기는 다음 노트에서 이어집니다.

연습 문제

1. 새 클러스터에서 import mlflow가 ModuleNotFoundError로 실패합니다. 가장 먼저 확인할 것은?
   ① 워커 수가 충분한지
   ② 클러스터가 ML 런타임으로 만들어졌는지
   ③ 노트북 언어가 Python인지
   ④ Unity Catalog 권한이 있는지

   ②. MLflow는 ML 런타임에 미리 깔려 있고 표준 런타임에는 없습니다. 노드 수나 권한과는 무관한 증상입니다.
2. 단일 노드 클러스터에 대한 설명으로 옳은 것을 둘 고르시오.
   ① 드라이버만 있고 워커가 없다
   ② Spark API를 아예 쓸 수 없다
   ③ 한 대 메모리에 들어가는 데이터로 scikit-learn을 학습할 때 알맞다
   ④ SparkTrials로 탐색을 병렬화할 때 알맞다
   ⑤ 큰 Delta 테이블의 분산 집계에 알맞다

   ①과 ③. Spark는 로컬 모드로 돌기 때문에 ②는 틀립니다. ④와 ⑤는 워커가 있어야 이득이 나는 자리라 멀티 노드입니다.
3. 데이터가 8GB이고 pyspark.ml의 GBTClassifier로 학습합니다. 알맞은 클러스터 구성은?
   ① 단일 노드, 표준 런타임
   ② 단일 노드, ML 런타임
   ③ 멀티 노드, 표준 런타임
   ④ 멀티 노드, ML 런타임

   ④. Spark ML은 워커에 나눠 학습하므로 멀티 노드가 필요하고, MLflow로 기록하고 모델을 다루려면 ML 런타임이 필요합니다.
4. 매일 02:00에 전처리 노트북을 돌리고 성공하면 학습 노트북을 잇달아 돌리려 합니다. 알맞은 것은?
   ① 노트북에 time.sleep을 넣고 열어 둔다
   ② 두 노트북을 Job의 두 작업으로 만들고 의존 관계와 일정을 건다
   ③ 두 노트북을 Git 폴더에 커밋한다
   ④ 클러스터를 자동 종료 없음으로 바꾼다

   ②. 일정과 작업 사이 순서는 Jobs가 맡습니다. ③은 버전 관리이지 실행이 아닙니다.
5. 앞으로 1년간 매일 도는 운영 파이프라인의 런타임 버전을 고릅니다. 가장 알맞은 근거는?
   ① 가장 최근에 나온 버전이 항상 빠르다
   ② LTS 버전이 지원 기간이 길어 오래 도는 작업에 맞다
   ③ 버전은 클러스터마다 달라도 결과가 같다
   ④ 베타 런타임이 라이브러리가 더 많다

   ②. LTS는 지원 기간을 길게 잡은 버전이라 자주 갈아 끼우지 않아도 되는 자리에 맞습니다.
6. 코드 승격(deploy code) 방식에 해당하는 설명은?
   ① 개발 환경에서 만든 모델 파일을 운영으로 복사한다
   ② 학습 코드를 운영으로 옮기고 운영 데이터로 다시 학습한다
   ③ 운영 모델을 개발 환경으로 내려받아 검증한다
   ④ 세 환경이 같은 모델 하나를 공유한다

   ②. Databricks가 기본으로 권하는 방식이고, 운영 데이터에 접근할 수 있는 곳이 운영 환경뿐일 때 자연스럽게 따라옵니다.
7. Hyperopt로 scikit-learn 모델의 하이퍼파라미터 40조합을 탐색합니다. 데이터는 200MB입니다. 옳은 판단은?
   ① 단일 머신 라이브러리이므로 단일 노드가 유일한 선택이다
   ② SparkTrials를 쓰면 조합을 워커들이 나눠 맡으므로 멀티 노드가 유리하다
   ③ 데이터가 작으므로 병렬화 이득이 전혀 없다
   ④ 표준 런타임으로 충분하다

   ②. 모델 하나는 워커 한 대가 통째로 학습하고, 서로 다른 조합이 병렬로 돕니다. Hyperopt도 ML 런타임에 들어 있습니다.
8. 노트북에서 %pip install로 깔아 쓴 라이브러리가 있습니다. 같은 노트북을 매일 도는 Job으로 걸었더니 그 Job만 ModuleNotFoundError로 실패합니다. 가장 알맞은 처방은?
   ① Job의 재시도 횟수를 늘린다
   ② 그 라이브러리를 클러스터 라이브러리로 등록한다
   ③ 노트북을 Git 폴더로 옮긴다
   ④ 런타임을 최신 버전으로 올린다

   ②. 노트북 범위 설치는 그 노트북 세션에만 붙습니다. Job이 쓰는 클러스터에 항상 있어야 하는 의존성은 클러스터 라이브러리로 등록합니다. 참고로 %pip 셀 자체를 노트북 맨 위에 두면 Job에서도 매번 설치되지만, 실행 시간이 늘고 버전이 흔들릴 수 있어 운영에서는 ②를 씁니다.

세 문장으로 줄이면 이렇습니다. 라이브러리가 런타임을 정하고, 분산 여부가 노드 수를 정하고, 자동 실행이 Jobs를 정합니다. 이 영역의 시나리오 문항은 대부분 이 셋 중 하나를 묻는 것을 다른 말로 바꿔 놓은 것입니다.