߅ള ঠ֥੗ ؘ੉ఠ ূ૑פয ݠन۞׬ ਬפߡझܳ ৈ೯ೞח ൤஖ೞ੉ழܳ ਤೠ ؘ੉ఠ ౱੉ "84 ਤীࢲ ,VCFSOFUFT ܳ ഝਊೞח ߨ

Disclaimer 본 슬라이드에 나오는 모든 내용은 회사와는 관련이 없으며 온전히 개인의 의견임을 미리 밝힙니다.

강연자 소개 박훈 (데이터 엔지니어) - 데이터 인프라 / 머신러닝 파이프라인 / 실험 플랫폼 - 클라우드에서 머신을 잘 굴려야 하는, 러닝머신 엔지니어 [1] https://github.com/1ambda [2] https://www.facebook.com/1ambda

ؘ੉ఠ ౱੉ ,VCFSOFUFT ܳ ࢎਊೞח ੉ਬ ݠन۞׬ ౵੉೐ۄੋ X,VCFSOFUFT ۞׬ݠन ূ૑פযо ߄ۄࠁח ݠन۞׬ CJUMZNMPQTLVCF

시작하기 전에 드리는 말씀 다음과 같은 질문을 많이 받습니다. “왜 AWS Glue 카탈로그 안 쓰고 Hive 메타스토어 쓰시나요?” “Presto 보다 GCP BigQuery 가 더 낫지 않나요?” 그러나 기술은, 특히 사내에서 수백명이 사용하는 데이터 시스템은 내 맘대로 떼고 붙일 수 있는 ‘옵션’이 아니라 ‘문화’ 입니다 인테리어를 예로 들면 - 같은 아파트라도 동과 평형에 따라 구조가 다르고 햇빛이 다른 방향에서 들어옵니다. - 구조가 같더라도 집주인의 취향에 따라 가구의 색과 배치가 달라지며 - 그 곳에 사는 구성원의 동선과 생활 방식에 따라 내용물이 달라집니다. 기술도 동일합니다 ! 이 슬라이드에서는, 온 우주에 존재하는 수 많은 기업 중 스타트업 1 곳에서의 이야기를 다룹니다. 다만 이 집에서는 노동비용을 최소화 하면서도 시스템의 운영 투명성과 확장성에 우선 순위를 두었습니다.

ؘ੉ఠ ౱੉ ,VCFSOFUFT ܳ ࢎਊೞח ੉ਬ ݠन۞׬ ౵੉೐ۄੋ X,VCFSOFUFT ۞׬ݠन ূ૑פযо ߄ۄࠁח ݠन۞׬ CJUMZNMPQTLVCF

2021 년의 Y사 데이터 팀 Infrastructure Business Infrastructure Business 비즈니스를 위한 데이터 인프라로 데이터 엔지니어 + 데이터 분석가 + 머신러닝 엔지니어 (추천, 가격 등) - [기반 시설] 배치 및 실시간 데이터 수집, 가공, 저장 및 조회를 위한 데이터 파이프라인 / ML 인프라 - [데이터 서비스] 분석 및 데이터 서비스를 위한 대고객 API / 인터널 도구 제공 - [비즈니스 확장] 비즈니스 자동화 / 최적화를 위한 모델 및 도구 제공 최근엔 AWS / GCP 외산 클라우드에서 제공하는 좋은 관리형 데이터 서비스가 많아 (EMR, MSK 등) 데이터 팀의 인프라 노동을 줄이고 동일 인력으로 데이터를 이용해 비즈니스에 기여할 수 있습니다.

데이터 인프라를 위한 AWS 컴포넌트 (간략화) 1. RDS 등 외부 저장소로부터 일 / 시간별 수집을 위해 EMR Spark 를 사용합니다. 2. Client (App / Web ) 로그 / Server 비즈니스 로그 (STDOUT) / Server 비즈니스 이벤트 (Avro, JSON Raw) 등 실시간 수집을 위해 Kinesis 및 Kafka 로 부터 데이터를 받아 EMR Spark / Flink 를 이용해 가공합니다. 3. 데이터는 용도에 따라 S3, Dynamo, Druid 등에 저장됩니다. 4. 보관된 데이터는 EMR Presto 또는 각 저장소에 직접 Visualization 도구에서 쿼리해 사용할 수 있습니다 (Redash 등) 5. 사용자 및 상품 Profile 의 경우에는 대고객 API 등에서 서비스로 내보내기 위해 직접 호출할 수 있습니다. 2021 년의 Y사 데이터 인프라 (Simplified)

2021 년의 Y사 데이터 인프라 w/ Kubernetes 서비스 유형에 따른 EKS - 전사 내부 도구 제공 - ML 등 대규모 데이터 처리 - 대고객 API 서비스

데이터 인프라 노동자가 마주치는 어려움 1. 데이터 팀에서 관리해야 할 컴포넌트가 점점 많아집니다. 다만 적은 노동비용을 유지하고 싶습니다 - 데이터 카탈로그 및 Redash 와 같은 Data Visualization / Exploration 도구 - Airflow 와 같은 스케쥴링 도구 및 ML 파이프라인을 위한 MLFlow, BentoML 등의 개별 컴포넌트 - 이런 모든 시스템은 시간이 지나며 코드 수정 / 버전 업그레이드 / 리소스 확장 / 모니터링 등을 요구합니다 2. EMR 은 머신 가산세 20% (EC2 비용의 약 20% 추가) 로 인해 비용이 높고 머신 추가가 느리며 Spark 버전을 선택해서 (2/3) 사용하기 어렵고, 업그레이드도 부담스럽습니다. 귀찮아서가 아닙니다! 또한 팀이 사용하는 컴퓨팅 프레임워크가 Spark 이외에도 다양합니다. 3. ML 컴퓨팅을 위한 Spark, Dask, Ray 등의 컴포넌트를 필요한 만큼 ML 엔지니어가 직접 요청하되 Scale-in 에 대한 기준과 시간을 타이트하게 가져가 최대한 큰 컴퓨팅을 적은 비용으로 지원합니다 Why Kubernetes? (1)

Why Kubernetes? (2) Kubernetes 사용시 다음과 같은 이점이 있습니다. 1. 컴포넌트의 설치와 운영이 간단해집니다. - 다만 저장소는 RDS 등 외부 시스템을 사용해서 스토리지 의존성을 낮춥니다. - 리소스 관리가 간편 해지며 Cluster Autoscaler 등 Kubernetes Addon 을 사용할 수 있습니다. - 기존에 있던 Prometheus, Grafana 등의 모니터링 인프라를 그대로 활용할 수 있습니다. 2. Spark on Kubernetes 를 활용해, EMR 을 대체할 수 있습니다 - EFS 같은 공유 스토리지에 Spark, Hadoop 등의 환경을 갖추고 자유롭게 버전을 선택할 수 있습니다 - 이렇게 갖추어진 환경은 Jupyter 뿐만 아니라 Airflow 등 스케쥴링이 실행되는 곳에서도 사용합니다 - 물리적인 비용 (EMR 가산세 20%) 도 절감할 수 있고 업그레이드 및 버전 선택에서 자유로워 집니다 3. ML 컴퓨팅을 위한 Spark, Dask, Ray 클러스터 또한 Kubernetes 위에서 실행해 쉽게 운영하고 Cluster Autoscaler 의 낮은 Scale-in Threshold 로 빠르게 회수해 타이트하게 관리할 수 있습니다

ؘ੉ఠ ౱੉ ,VCFSOFUFT ܳ ࢎਊೞח ੉ਬ ݠन۞׬ ౵੉೐ۄੋ X,VCFSOFUFT ۞׬ݠन ূ૑פযо ߄ۄࠁח ݠन۞׬ CJUMZNMPQTLVCF

머신러닝 파이프라인: Computing Infra 개별 사용자는 JupyterHub 에서 Container 를 할당 받고 격리된 리소스 환경에서 원하는 컴퓨팅 프레임워크를 선택 - Spark Local Mode/ Spark Client Mode [1] 또는 - Dask, Ray 같은 분산 처리 프레임워크를 각각 사용하거나 - 필요에 따라 Spark + Ray 등 자유롭게 섞어 사용 Spark 의 경우 다음과 같은 장점으로 자주 활용 - 데이터 로딩 및 전처리를 SQL 함수를 이용해 쉽게 가능해 - 중간 결과를 Parquet (on S3) 등으로 만들어 저장한 뒤 Dask / Ray 에서 다시 읽어서 사용 - 분산처리 가능한 모델의 경우 학습과 튜닝을 위해 원하는 만큼 Executor 를 띄워 수행 [1] Spark Client / Cluster Mode Explanation

[3] Ray Github [4] Uber Engineering - Elastic Distributed Training with XGBoost on Ray (2021. 07) 머신러닝 파이프라인: Computing Infra (Uber Case) 스크린샷 1 < Notebook 내에서 원하는 만큼 Ray 리소스를 요청 > 스크린샷 2 < Spark 전처리 후 중간 저장 뒤 Ray 로 학습 및 튜닝 분산처리>

머신러닝 파이프라인: Computing Infra (Spark) Notebook 내에서 커스텀 유틸리티를 통해 Spark 실행 모드 / 환경설정 등 Kubernetes 를 위한 옵션 설정

머신러닝 파이프라인: Computing Infra (Spark) 사용자 필요에 따라 Local Mode (단일 머신 모드) / Client Mode (분산 처리) 모드 사용

머신러닝 파이프라인: Computing Infra (Spark Issue 1) Spark on Kubernetes 사용시 다음과 같은 문제점들이 발생할 수 있습니다. 1. Executor 내 Shuffle 로 Disk 과다 사용시 성능 저하 또는 OOM 이 발생합니다 (eks-spark-benchmark) - EKS Node 의 메모리를 tmpfs 로 (emptyDir.medium) 사용이 가능하나 그날의 데이터 특성에 따라 Executor 의 Shuffle 사이즈가 다를 수 있고 이로 인해 Node 메모리 할당을 정규화 할 수 없고 복잡해지므로 Executor Pod 마다 Volume Mount 를 사용합니다. (Spark Docs – Using Kubernetes Volume) < Skew 로 인해 특정 Executor 에 데이터가 몰려 반복적으로 Executor 가 강제 종료 (OOM) 된 경우 >

머신러닝 파이프라인: Computing Infra (Spark Issue 2) 2. Executor Pod 할당이 최대 수 분 까지 지연될 수 있습니다 - Cluster AutoScaler 의 ASG Desired 값 증가 > EC2 생성 및 EKS Node Ready > Docker Image 다운로드 - ‘scheduler.maxRegisteredResourcesWaitingTime’, ‘scheduler.minRegisteredResourcesRatio ‘ 옵션을 통해 Spark Task 실행 전 대기시간을 조절 가능 (Spark Scheduler Configuration) < Executor 3 이 추가되기 전에 Spark Task 가 실행된 경우 (좌측) >

머신러닝 파이프라인: Computing Infra (Spark Issue 3) 3. PySpark 와 Dask, Ray 등 프레임워크를 섞어 쓰는 경우 Python 영역에서 OOM 이 발생할 수 있습니다. - Python 메모리 영역은 Spark 기준으로 Off-heap 이므로 memoryOverheadRatio 값을 낮게 잡을 경우 Dask, Ray 등 Python 영역의 메모리 과다사용으로 OOM 이 발생할 수 있습니다. – 따라서 전처리 후 Notebook 에서 Spark Session 을 내려서 메모리를 확보하거나, Pod 초기화 시간이 더 걸리더라도 Python 라이브러리를 이용한 프로세싱 전용 Dag 을 분리해 작업을 안전하게 진행할 수 있습니다. < Spark Memory 영역 – Decoding Memory in Spark >

머신러닝 파이프라인: Computing Infra (Spark Issue 4) 4. ML 엔지니어가 ‘의도한’ 메모리 요청량보다 과다하게 Pod 메모리가 할당 될 수 있습니다. - ‘spark.kubernetes.memoryOverheadFactor’ (default=0.1, 10%) 값만큼 요청한 Executor 메모리에 더해 Pod 이 생성됩니다. 예를 들어 executorMemory = 120Gib 로 요청하고 memoryOverheadFactor 값을 설정하지 않으면 12 GiB (10%) 만큼 더해 132 GiB 의 Pod 이 생성됩니다. - 또한 EC2 의 경우 기재된 사이즈 만큼 EKS 에서 Pod 리소스로 사용할 수 없습니다. 예를 들어 r5.8xlarge 의 경우 인스턴스 스펙은 256 GiB 지만 실제 할당 가능한 리소스는 246 GiB 정도입니다. - Kubernetes 에서는 GB, GiB 로 모두 할당 가능하나 JVM (Spark) 은 GiB 단위로 메모리를 관리합니다. 따라서 Spark 초기화 유틸리티를 통해 이러한 복잡함을 숨기고 리소스 관리를 용이하게 할 수 있습니다.

머신러닝 파이프라인: Notebook Infra Jupyter 에서 만들어진 Notebook 은 EFS 에 저장됩니다. 1. Airflow 에서 Notebook Operator 를 통해 Jupyter Notebook 을 스케쥴링 할 수 있습니다. 2. EFS 에 존재하는 Spark 등 환경 설정을 이용해 Notebook 코드를 수정 없이 바로 실행할 수 있습니다 3. 이 때, 실행되는 Notebook 은 Airflow Task Pod (Airflow Kubernetes Executor 사용시) 이므로, Dag 에서 리소스를 조절할 수 있는 유틸리티를 제공합니다. 4. Spark 를 실행하는 Dag 에서 의존성이 있는 데이터를 기다리기 위해 Airflow S3 Key Sensor 를 사용할 수 있습니다. 다만 작업자는 S3 경로가 아니라 테이블 단위로 사용하므로, S3 Sensor 를 Wrapping 한 TableSensor 를 제공하면 사용이 편리합니다.

머신러닝 파이프라인: Notebook Operator for Airflow Notebook Operator 샘플 코드 (간략화) Papermill 을 이용하면, Notebook (.ipynb 확장자) 파일을 Airflow 에서 스케쥴링 할 수 있습니다. 1. EFS 내 Notebook 파일은 변경될 수 있으므로, S3 에 업로드 후 S3 에 있는 복제본을 실행합니다. 2. Airflow Papermill Operator 를 수정해 팀이나 회사에 맞는 Notebook Operator 를 제공합니다. 3. 결과 노트북을 Notebook Viewer (jnotebook_reader) 가 바라보는 S3 / EFS 에 저장하고 Slack 등 알림을 보냅니다.

머신러닝 파이프라인: Spark Client Operator for Airflow Scala Spark 를 사용할 경우, Papermill 을 이용할 수 없으므로 별도의 SparkClientOpeator 를 제공합니다. 1. EFS 에 Spark / Hadoop / Java 등의 환경을 구비해 놓을 경우 Docker Image 가 매우 가벼워지고 의존성이 분리되므로 매번 빌드할 필요가 없어 관리가 편해집니다. 2. Apache Toree 를 Jupyter Scala Kernel 로 사용하는 경우 ‘.scala’ 파일 Import 가 불가능하므로 Scala Spark 초기화 코드를 간소화하기 위해 유틸리티를 프로젝트로 SBT 빌드해 Spark Jar 경로에 추가합니다. Scala Implicit 를 언어 기능을 활용하면 Spark 초기화 코드 및 데이터 로딩 함수를 편리하게끔 제공할 수 있습니다.

머신러닝 파이프라인: Spark Client Operator for Airflow 3. KubernetesPodOperator 또는 SparkSubmitOperator 를 사용할 경우 Spark Cluster Mode 처럼 동작해 Airflow Pod 에서 Spark Driver Pod 의 정상 동작 여부 확인 및 모니터링이 어려워집니다. - 따라서 Airflow Worker 컨테이너 이미지에서 EFS 내 Spark / Hadoop / JVM 등 환경을 읽어 Scala Spark 를 Client 모드로 Submit 할 수 있도록 하여 Airflow Worker Pod = Spark Driver 처럼 사용할 수 있습니다 Papermill 로 실행되는 Notebook 내 PySpark 와 유사하게 Scala Spark 도 Airflow Worker 에서 Client 모드로 Submit 하여 사용

머신러닝 파이프라인: TableSensor for Airflow < Airflow Dag 내에서 Notebook 을 실행하기 전 의존성 데이터를 체크하고 Notebook 실행 후에도 결과 데이터를 체크하는 Graph View > Airflow 에서 현재 Dag 이 의존하고있는 데이터를 체크하기 위해 S3 Key Sensor 를 사용할 수 있습니다. 그러나 일반적으로는 Table 형태로 데이터를 사용하므로 Table 이름으로 데이터를 체크할 수 있도록 유틸리티를 제공하면 편리합니다. 1. Hive Metastore 등 사용하는 메타스토어에서 테이블과 S3 경로를 매핑하는 데이터를 주기적으로 빌드 합니다. 2. BaseSensorOperator 를 상속받아 TableSensor 를 만들어 필요한 파라미터를 받도록 제공합니다 3. 테이블마다 파티션 형태가 다를 수 있으므로 유연한 형태로 파라미터를 설계하고, Dag 에 따라 다수의 테이블을 의존할 수 있으므로 테이블과 파티션을 배열 형태로 받는 것도 고려합니다. 4. Task Slot 을 차지할 수 있으므로 Airflow Sensor 의 기본 옵션을 reschedule = true 로 둘 수 있습니다.

머신러닝 파이프라인: Model / Serving Infra Notebook 에서 모델을 개발하며 다음의 과정을 거칩니다 1. 모델의 파라미터, 퍼포먼스, 결과 파일 등을 MLFlow 에 기록합니다. 기록된 데이터를 이용해 어떤 모델이 좋았는지 비교할 수 있습니다. 2. MLFlow 의 중립적인 형식으로 모델을 저장할 경우 BentoML 에서 모델을 불러오는 것이 가능합니다. 3. BentoML 에서 MLFlow 모델을 이용해 API 를 생성 한 뒤 Docker Image 로 만들어 Registry 에 등록합니다 4. 등록한 Docker Image 를 Kubernetes 위에 배포할 수 있습니다. (좌측 스크린샷 내에서는 생략) 5. 로컬 개발 및 실 데이터를 이용한 검증 등을 위해 Local / Jupyter 에서 MLFlow / BentoML 을 사용할 수 있으므로 Python 프로젝트와 Mock 데이터, 유틸리티 함수를 포함하는 Helper 를 만들어 놓으면 생산성을 높일 수 있습니다.

머신러닝 파이프라인: Model Tracking (MLFlow) MLFlow 를 이용하면 모델의 파라미터, 퍼포먼스, 결과 파일 등을 기록하고 비교할 수 있습니다. 1. MLFlow 함수를 Wrapping 한 커스텀 라이브러리를 제공해 Tracking / Model 저장 등을 편리하게 제공해 생산성을 높일 수 있습니다. (ML 엔지니어 / jireh.bak) 2. MLFlow 는 Keras, Pytorch, Scikit-Learn, Tensorflow, Spark MLlib, XGBoost, LightGBM, Catboost, FastAI 등 다양한 모델을 지원하고 필요시 Custom Python Function 도 모델로 사용할 수 있습니다. [1] MLFlow Tracking [2] MLFlow Models Flavors

머신러닝 파이프라인: Model Artifact (BentoML) BentoML [1] 을 이용하면 모델을 API 로 만들 수 있습니다. 1. MLFlow 에서 저장한 모델을 BentoML 에서 사용할 수 있습니다. [2] 2. BentoML 함수를 Wrapping 한 커스텀 라이브러리를 제공해 생산성을 높일 수 있습니다. (ML 엔지니어 / jireh.bak) 3. BentoML UI 로 부터 Artifact 를 다운받아 압축을 풀고 제공되는 Dockerfile 을 통해 API 컨테이너 이미지를 생성하고, ECR 등에 업로드 하는 스크립트를 제공해 CI / CD 파이프라인 이외에 ML 엔지니어가 필요시 직접 개발 환경 등에 작업중인 이미지를 테스트할 수 있도록 돕습니다. 4. BentoML 에서 Kubernetes, KFServing, KubeFlow 등 에 대한 직접적인 배포를 지원하지만[3], 사내 또는 팀 내 Pod, Ingress 등에 대한 정책이 있으므로 컨테이너 이미지화 해 직접 배포하는 편이 낫습니다. [1] BentoML Docs - Core Concept [2] BentoML Docs – Loading MLFlow Models [3] BentoML Docs – Deployment Guide

머신러닝 파이프라인: Model Deployment Strategy (1) (A) Model 을 API 에 임베딩하고 Wrapper API 가 호출 [1] Operate Large-volume Machine Learning Models on AWS (B) Wrapper API 에서 모델 파일 로딩 후 서빙 Wrapper API 는 로깅 또는 A/B 테스팅 등 인프라 Layer 의 기능을 제공하며 모델이 요구하는 파라미터를 (상품 정보 등) 다른 저장소로부터 얻어와 모델에 입력 값으로 전달

머신러닝 파이프라인: Model Deployment Strategy (2) (A) Model 을 API 에 임베딩하고 Wrapper API 가 호출 - 모델 Artifact가 Model API 에 포함되어 변경시 Model API 재배포 발생 - A/B 테스팅 등 실험 / 로깅 등을 위한 Wrapper API 가 모델 Artifact 를 직접 로딩하지 않으므로 언어 및 프레임워크 선택에서 자유로움 - Wrapper API 는 모델 Artifact 가 요구하는 파라미터를 (상품 / 실시간 재고 및 가격 등) 전달하고 Model API 는 단순 추론 및 계산만 수행 - Model API 가 Wrapper API 내에 Endpoint 로 존재하는 것이 아니라 별도로 배포되므로 모니터링 등 가시성에서 이점을 얻으나 - Model API 가 많아질 경우 관리가 번잡해지며 AWS LB Controller (ALB) 는 2.2.4 기준으로 Rewrite 를 지원하지 않아 Sub-domain 이용 (B) Wrapper API 에서 모델 파일 로딩 후 서빙 - 모델 Artifact 와 Wrapper API 의 Life Cycle 분리로 인해 원하는 때에 모델 Artifact 를 배포할 수 있으며 서빙 API 가 영향을 받지 않음 - Wrapper API 내에 모델 Artifact 를 위한 API 가 Endpoint 로 존재하며 EFS 등 네트워크 스토리지에서 주기적으로 또는 매뉴얼로 읽어서 사용 - Wrapper API 는 모델 Artifact 를 로딩하기 위해 언어가 (Python) 제약될 수 있으며, 이로 인해 기존에 사용하던 팀 내 API 언어를 사용하지 않고 유틸리티를 (e.g 실시간 상품 메타 조회) 사용할 수 없으므로 노동 비용 발생 - Wrapper API 가 다수가 될 경우, LB 뒤에 있는 모든 Pod 에 대해 특정 모델을 다시 로딩하는 Operation 작업을 배포의 형태로 사용

머신러닝 파이프라인: Model Deployment Strategy (3) 모델 배포와 관련된 몇 가지 생각할 거리 Q1. 데이터는 매일 변경되므로, 학습과 튜닝을 다시 진행해, 성능이 더 좋다면, 일 배치로 또는 시간별 배치로 배포하는게 맞을까? Q2. 모델이 비즈니스와 강하게 연결되어 있는 경우 (가격 등) 변화에 따라 영향을 받는 정책 담당자가 수용할 수 있는 범위 내에서 모델의 성능이 변화할까? Q3. 모델이 시간의 흐름에 대해 비교적 강건하다면, 배포 빈도가 적어도 괜찮은가? 이 모델이 시간에 민감하다면, 구 버전 모델의 응답을 같이 내보내되 시간에 따라 점진적으로 비율을 조정할 수 있을까? 자주 배포하는 모델이, 자주 변경되는 모델이 시스템 관점에서 정말 좋을까? 1.3%p 의 “평균적인” 성능 향상을 위해 개별 상품의 담당자들이 받는 영향은 얼마나 클까?

머신러닝 파이프라인: Summary 요약하면, 1. 사용자는 원하는 수준의 리소스를 선택해 Jupyter Container 를 할당 받을 수 있습니다. 2. Dask / Spark / Ray 과 같은 컴퓨팅 프레임워크를 사용해 분산처리를 할 수 있고 필요하다면 Spark Local Mode/ Python 단일 머신 라이브러리 등을 이용해 분산처리 되지 않는 알고리즘을 수행할 수 있습니다. 3. 이 과정에서 모델의 파라미터 및 퍼포먼스는 MLFlow 에 기록되며, 모델 또한 다른 시스템에서 꺼내 쓸 수 있는 일반화된 형태로 MLFlow 에 저장합니다. 4. 만든 Notebook 은 EFS 와 같은 공유 저장소에 기록되며, Python 코드로 옮기거나 등의 추가 작업 없이 Airflow 에서 Notebook Operator 를 통해 즉시 실행 및 스케쥴링이 가능합니다. 5. 만든 모델을 MLFlow 에서 꺼내, BentoML 라이브러리를 이용해 Docker Registry 에 올린 후 배포해 API 로 만들 수 있습니다.

ؘ੉ఠ ౱੉ ,VCFSOFUFT ܳ ࢎਊೞח ੉ਬ ݠन۞׬ ౵੉೐ۄੋ X,VCFSOFUFT ۞׬ݠन ূ૑פযо ߄ۄࠁח ݠन۞׬ CJUMZNMPQTLVCF

Disclaimer 데이터 엔지니어가 바라보는 머신러닝과 파이프라인에 대한 관점

러닝머신 Rule 1. 머신러닝이란 무엇인가? (1) 기존 비즈니스에서, 모델은 도대체 무슨 일을 하는가? - 사람이 직접 하기 힘든 영역을 대체합니다. - 예를 들어, 너무 많은 노동력이 들어가거나 / 암묵적 지식으로 이루어진 작업을 (가격 최적화 등) - 수치를 통해 ‘검증’ 하고, 특질을 ‘시각화‘ 하여 이해 관계자의 해석을 도우며 비즈니스를 ‘객관화’ 합니다. 따라서 기존 비즈니스에서 모델이 하는 일은 본질적으로 비즈니스 정책 자동화 에 가깝습니다.

중요한 비즈니스를 (가격 책정 등) 모델이 자동화 할 수 있다면 - 수 많은 이해 관계자와 엮이게 됩니다. 그리고 수 많은 회의도 - 해당 비즈니스가 회사의 메인이며 수익과 크게 관련 있다면, 모델의 급진적인 ‘평균’ 성능 향상 보다 개별 상품 또는 상품 묶음 단위에 (카테고리 등) 대한 안정적인 결과물이 더 중요할 수 있습니다. 이로 인해 궁극적으로는 지역 / 시간 / 카테고리 등 잘게 찢어진 형태로 모델이 운영될 수 있으며 인프라 노동자는 모델의 해석과 리포팅 등을 돕기 위한 시스템을 준비해야 할 수 있습니다. - 리포트를 위한 서비스를 직접 개발하는 대신 - 개별 카테고리 / 일자 등 파라미터를 Papermill 로 넘기고 Notebook 을 실행한 뒤 결과를 Viewer 로 공유하거나, Notebook to HTML 을 통해 사이트 임베딩 또는 이메일 등으로 전송할 수 있습니다. 러닝머신 Rule 1. 머신러닝이란 무엇인가? (2) 중요하지 않은 시점엔 무엇을 해도 문제가 되지 않습니다. 그러나 정말 중요한 시스템을 바꾸기 위해서는 많은 노력이 듭니다.

러닝머신 Rule 2. 저금리 시대 클라우드와 노동 비용 (1) [1] Uber Engineering - Challenges and Opportunities to Dramatically Reduce the Cost of Uber’s Big Data (2021. 08) [2] Uber Engineering - Cost-Efficient Open Source Big Data Platform at Uber (2021. 08) [3] Uber Engineering - Building Scalable Streaming Pipelines for Near Real-Time Features (2021. 08) 클라우드의 관리형 서비스는 보이지 않는 비용이 있습니다. 변동금리 대출 상품과 같이, 저금리 대출 초기에는 편리함을 느끼다가 금리, 즉 규모가 올라가는 순간 많은 문제들이 생깁니다. - 작은 타입의 인스턴스와 달리 큰 규모의 인스턴스 (8xlarge 이상) 는 할당되지 않는 경우가 생깁니다 - PG 라이센스 등의 이유로 센터 (IDC) 로 내려가면 Glue, Athena 와 같은 클라우드 서비스가 아니라 HMS, Presto 등 오픈소스 / 네트워크 기반의 접근제어 시스템을 사용해야 할 수 있습니다. - 관리형 서비스의 경우 필요에 의한 커스터마이징이 불가능한 경우가 많습니다. 따라서 단순히 관리형 서비스가 당장 편하다는 이유로 도입하기 보다는, 현재 사용하고 있는 기술과 유사한 스택으로 이루어진 더 큰 규모의 회사 사례를 통해 데이터 시스템의 확장성이나 비용 절감, 생산성 개선 등 다양한 힌트를 얻을 수 있습니다

러닝머신 Rule 2. 저금리 시대 클라우드와 노동 비용 (2) 클라우드 서비스는 본질적으로, 당장의 편리함을 얻고자 물리 비용을 지불해 노동 비용을 줄이는 방법입니다. 다만 미래에는 노동을 넣어 물리 비용으로 교환하는 시점이 오거나, 큰 청구서가 올 수 있으므로 쉽게 교체할 수 있는 한도 내에서 적절히 관리형 서비스를 선택하는 편이 낫습니다. - 물리 비용 절감을 위해 Spot 인스턴스 사용시 머신 타입을 다양하게 Override 해야하고, VPC 내 존 별로 지원되지 않는 타입이 있을 수 있으므로 존별로 타입을 (c5n, m5a) 세팅해 추가적인 노동 비용이 들어갈 수 있습니다. 설정 및 업그레이드 등을 고려하면 노동 비용은 2배 이상에 가깝습니다 - 머신 업타임 (특히 EKS 등 클러스터류의 서비스) 을 줄이기 위해 ASG Warm-pool 등을 사용할 수 있으나 머신 타입 Override 가 불가능하고 EBS 등 고정 자산에 대한 비용을 지불해야 합니다.

러닝머신 Rule 3. 정책과 생산성 사이 그 어딘가 (1) 과도한 커스터마이징이나 추가 레이어는 생산성에 해가 될 수 있습니다. - 예를 들어, Kubernetes 커맨드를 전혀 사용할 수 없는 Hunbernetes ! 등 커스터마이징의 본래 목적은 사내 ‘정책’ 으로 인한 복잡도를 단순화하며 동시에 사내 사용자의 요청의 응대 및 피드백을 바탕으로 편의성을 제공하는 것입니다. - 커스터마이징을 위해서는 ‘담당자’ (물리 노동 인력) 이 필요하며 - 오픈소스를 감싼 도구는 ‘사내’ 에만 존재하므로 문제 해결을 위한 지식을 인터넷에서 찾기가 어렵습니다. - 문제 발생시 담당자가 필요하거나 사용자가 직접 해결할 수 없는 경우에는 시간이 다소 걸릴 수 있습니다. 따라서 24/7 담당자를 할당할 수 없거나 인프라 대신 비즈니스에 집중하고자 할 경우엔 오픈소스나 클라우드에 덧댄 레이어를 지양해 시스템의 운영 투명성을 높일 수 있습니다.

가능하면 ‘정책’ 을 최소화 하고 추상화된 레이어를 줄여 도구와 지식을 최대한 ‘투명’ 하게 구축해 ‘담당자 본인’ 을 거치지 않고도 많은 업무를 할 수 있게 하는 편이 낫습니다. ’정책’ 은 사람을 대상으로 시행하기에 사용자들의 기술 숙련도를 고려치 않고는 이야기를 할 수 없습니다. - 예로, 데이터 엔지니어는 Git 이 익숙하나 다른 도메인에서 건너 온 (금융, 건설 등) ML 엔지니어는 그렇지 않을 수 있습니다. 따라서 Production Airflow 는 Git Sync 여도 Stage Airflow 는 EFS 를 사용하는 등 사용자를 고려할 필요가 있습니다. - 사용자의 기술도 (그리고 팀도 !) 시간이 따라 성장하기에 처음부터 복잡하거나 사용하기 까다로운 시스템을 도입할 필요가 전혀 없습니다. 어떤 것들은 시간이 해결해 주기 때문입니다. 러닝머신 Rule 3. 정책과 생산성 사이 그 어딘가 (2) 인프라 노동자가 도입하는 모든 도구는 ‘문화’ 를 구성합니다. 회사 내 수백명의 사용자가 데이터로 어떻게 일할지를 결정합니다.

хࢎ೤פ׮ ޙ੄ IPPOQBSL BNCB!HNBJMDPN 5IBOLTUP!%*@"-- CJUMZNMPQTLVCF