[Reliable Machine Learning] Chapter1. Introduction
이 글은 <Reliable Machine Learning, Cathy Chen, Niall Richard Murphy, Kranti Parisa, D. Sculley, Todd Underwood> 1장 Introduction을 참고하여 작성했습니다.
Chapter 1. Introduction
ML 애플리케이션도 Life cycle이 있습니다. 이번 장에서는 ML 애플리케이션이 어떤 Life cycle을 갖는지, 각 Stage 마다 어떤 일들을 수행하는지 살펴보겠습니다.
1. Data Collection and Analysis
데이터 수집 및 분석 단계입니다. 이 단계에서는 수집된 데이터를 분석하며 현상을 이해하고 풀고자 하는 문제를 정의합니다. 풀어야 하는 문제가 이미 정해져 있다면, 그에 필요한 데이터를 수집하고 분석하며 현상에 대한 이해를 높이는 시간도 이에 포함됩니다.
2. Data Management
데이터 관리 단계입니다. 이 부분에 대해서 다루어야 하는 이야기가 정말 많아 Chapter2, 4, 10에 나눠 다시 자세히 이야기를 나눠보겠습니다.
3. ML Training Pipelines
이제 잘 모은 데이터로 ML 학습 파이프라인을 구축할 수 있습니다. 학습 파이프라인을 구축하는 본 단계에서는 데이터를 처리하고 모델을 학습시켜 줍니다.
사실 학습에 성공하긴 쉽지 않습니다. 만약 학습이 잘 되지 않는다면 아래 사항을 점검해 보길 권해드립니다.
- 데이터가 부족해서 학습에 실패했나.
- 데이터가 모두 올바르게 포매팅되었나.
- 데이터 파싱이나 ML 알고리즘에 버그가 있을까.
- 파이프라인이나 모델 설정을 올바르게 했나.
- 메모리나 Compuatation 리소스 부족으로 학습이 안 되었나.
ML 모델 학습은 조용히 실패(Fail Silently)하는 경우도 많습니다. 조용히 실패하지 않기 위해, ML 애플리케이션을 위한 모니터링 시스템은 어떻게 구축해야 하는지는 Chapter 7, 9에서 살펴보겠습니다.
끝으로 ML 모델은 자동으로 생성될 수 있도록 스크립트를 만들어 두어야 합니다. 그리고 모델 설정과 실행 방법에 대한 자세한 정보를 문서로 남겨두는 것도 필수입니다. 스크립트와 문서가 없어 훗날 해당 모델 다시 구성하지 못하는 불상사가 일어나지 않도록, 귀찮아도 문서와 자동화 스크립트는 신경 써주길 바랍니다.
4. Build and Validate Applications
다음은 학습된 모델을 실제 애플리케이션에 적용하는 단계입니다. 이 단계에서는 아래 사항을 결정해야 합니다.
1. 기존 시스템이 모델에 쿼리를 언제 보낼 것인가
2. 추론된 결과를 토대로 시스템은 어떤 행동을 할 것인가
3. 기대 효과
예를 들어, 쇼핑몰 애플리케이션에 같이 구매하면 좋은 상품 추천 모델을 적용해 본다면, 아래와 같이 구성할 수 있습니다.
1. 상품 구매 페이지 진입 시, 해당 상품과 같이 구매하면 좋은 상품 목록 추천
2. 추천 상품 목록을 하단에 리스트로 노출
3. 추천 상품 추가 구입으로 인한 매출 상승 기대
이때, ML 모델이 얼마나 의미 있는지 데이터를 반드시 남겨두어야 합니다. 위 예시를 다시 살펴보면, 고객에게 어떤 품목들을 추천해 줬고, 어떤 추천 상품이 구매로 이어졌는지 데이터를 남겨두어야 합니다. 이를 잘 작성해 두었다면, 우리는 다음 단계에서 로그 데이터를 기반으로 모델의 성능을 검증하고 개선이 필요한 부분을 찾을 수 있습니다.
5. Quality and Performance Evaluation
다음은 모델의 성능을 평가하는 단계입니다. 다양한 모델 평가 방법에 대해서는 Chapter5에서 자세히 다룰 예정입니다.
그전에 모델을 평가하기 위해 ML 서비스를 어떻게 론칭할 것인가, 론칭 방식 3가지를 알아보겠습니다.
1. Dark Launch
다크 론칭은 모델의 결과를 확인하고 기록하는 것까지는 실제 애플리케이션에 적용하지만, ML 서비스가 기존 시스템 방식에 영향을 주지 않도록 제한하는 론칭 방식입니다.
- 장점: 미성숙한 모델로 인해 문제가 발생하지 않도록 방지할 수 있다.
- 단점: 모델의 성능을 정확하게 하기는 어렵다
2. Live Launch
라이브 론칭은 다크 론칭과 다르게 실제 애플리케이션에 온전히 적용하는 형태를 의미합니다.
- 장점: 신뢰도 높은 모델 성능 결과를 얻을 수 있다
- 단점: 사용자에게 아직 성능 확인되지 않은 ML 서비스가 그대로 노출된다
3. 중간 단계
다크 론칭과 라이브 론칭의 중간 단계로, 일부 사용자에게만 ML 서비스를 노출하는 방식입니다.
- 장점 1: 신뢰성 높은 테스트 결과를 수집할 수 있다.
- 장점 2: ML 서비스 문제 발생 시, 그 영향을 최소화할 수 있다.
- 단점: 충분한 양의 테스트 데이터를 모으는 데 오래 걸릴 수 있다.
6. Defining and Measuring SLOs
모델 성능 외에도 확인해야 할 것이 하나 더 있습니다. SLO(Service Level Objective)라는 것인데, 쉽게 이야기하자면, 서비스로서 만족시켜야 하는 스펙을 정하고 이를 만족하는지 확인해야 합니다. ML 서비스의 경우 어떤 값을 SLO로 사용하는지 간단하게 살펴보겠습니다.
모델 서빙 관련 SLOs
- 정확도: 모델이 제공하는 예측이 실제 데이터와 얼마나 일치하는지를 측정합니다.
- 응답 시간: 모델이 예측을 제공하기까지 걸리는 시간을 제한 시간 내에 유지해야 할 수 있습니다.
- 오류율: 모델이 잘못된 예측을 얼마나 자주 하느냐를 측정합니다.
- 처리량: 모델이 일정 시간 내에 처리할 수 있는 요청의 양을 정량화합니다.
모델 트레이닝 관련 SLOs
- 트레이닝 시간: 새로운 모델을 훈련하는 데 소요되는 시간을 제한 시간 내에 완료해야 할 수 있습니다.
- 트레이닝 정확도: 훈련 데이터에 대해 모델이 얼마나 정확하게 적합되는지를 측정합니다.
- 데이터 처리량: 훈련 데이터를 얼마나 빠르게 처리할 수 있는지를 평가합니다.
애플리케이션 관련 SLOs
- 추천 시스템의 클릭 스루율: 모델이 생성하는 추천이 얼마나 많은 사용자에게 클릭되는지를 측정합니다.
- 검색 결과의 정확도: 모델이 검색 결과를 얼마나 잘 랭크하는지를 평가합니다.
관련된 더 자세한 내용은 Chapter 9에서 더 자세히 다룰 예정입니다.
7. Launch
모든 검사를 마쳤다면, 드디어 ML 서비스를 론칭할 시간이 왔습니다.
안정적으로 서비스를 운영하려면, 모니터링, 배포 제어, 롤백 정책 등 고려해야 할 것이 꽤 많습니다.
일반적인 서비스에 대해서 안정적인 서비스 운영을 위해 필요한 정보들은 <Site Reliability Engineering: How Google Runs Production Systems>를 참고해 주세요.
여기서도 ML 서비스를 안정적으로 운영하기 위해 필요한 중요 내용을 짚어보자면,
모델도 코드처럼
모델도 코드와 마찬가지로 실제 서비스에 큰 영향을 주며, 잘못된 모델의 경우 ML 서비스의 사용자 경험을 크게 저해할 수 있습니다. 간혹 코드 주말 배포는 막아두는 반면, 모델 주말 배포는 허용하는 회사들이 있는데, 모델 또한 코드와 동일한 정책을 따르도록 하는 것이 좋습니다.
배포는 천천히
배포는 작게 시작하는 것이 좋습니다. 예를 들어, 일부 사용자에게만 새로운 기능이 노출되도록 한 후에 점차 노출되는 범위를 넓혀가는 것이 안전합니다. 이를 통해, 새로운 기능으로 인한 문제의 영향이 온사방에 퍼지지 않도록 미연에 방지할 수 있습니다.
변경은 작게
데이터 변경은 사소한 것일지어도 어그러진 데이터가 ML 서비스 전체를 망가뜨릴 수 있습니다. 그렇기 때문에 ML 쪽은 특히나 변경은 작게 작게 만드는 것을 권장합니다.
데이터 레이어는 따로 배포해라
예를 들어, 코드 변경과 테이블 형상 변경이 필요한 기능을 개발하는 중이라고 해볼게요. 이 두 작업을 한 번에 진행하고 배포하다 문제가 생겼다면, Rollback을 하겠지만, 이때 대게 코드만 Roll back 됩니다. 결국 코드와 맞지 않은 형상의 테이블로 인해 Rollback 후에도 서비스는 정상화되기 어려울 수 있습니다. 이러한 상황을 막기 위해서라도 데이터 레이어 변경과 코드 변경은 따로 진행하는 것이 좋습니다.
SLO 팔로우업은 필수
출시된 서비스가 이전 단계에서 만족한 SLO를 여전히 잘 만족하고 있는지 계속 팔로우 업할 수 있는 환경이 필요합니다.
배포 잘 되었는지 확인
배포하고 난 후에는 서비스가 원하는 대로 잘 돌아가는지, 문제가 어디서 새롭게 발생하고 있진 않은지 꼭 확인하자.
8. Monitoring and Feedback Loops
이제 서비스를 모니터링하고 피드백을 통해 나아갈 부분을 찾을 수 있습니다. 이 때 모니터링하면 좋은 수치는 아래와 같습니다.
Health Check
ML 시스템도 시스템이기에 Health Check는 필수입니다. 프로세스가 모두 잘 실행되고 있는지 모니터링하는 시스템이 필요합니다.
Model Health
ML 시스템의 경우, 새로운 모델의 크기가 적절한지, 모델이 잘 로드되어 있는지 등과 같이 모델에 대한 Health Check 가 추가로 필요합니다.
Model Quality
모델 품질을 확인할 수 있도록 구축해두어야 합니다. 여기서 모델 품질은 모델의 정확도를 나타낼 수도 있고, 추천 모델이라고 한다면, 얼마나 사용자가 모델의 추천을 받아들였는지에 대한 지표도 모델 품질의 일부로 활용할 수 있습니다.
End of Loop
지금까지 ML 애플리케이션의 Life Cycle을 살펴보았습니다. 앞으로 이어지는 내용에서는 각 파트별로 엔지니어가 고려해야 하는 부분들을 더욱더 자세히 살펴보겠습니다.