[Study] 머신러닝 시스템 디자인 패턴 - Chapter 7

Chapter 7 - ML옵스 시스템의 End-to-End 설계

7.1 - 과제와 방법

7.1.1 머신러닝으로 해결 가능한 과제를 결정하기

• 기존 과제들 중에서 머신러닝을 사용하지 않으면 해결할 수 없는 과제를 선택한다.
  • 만약 머신러닝 시스템을 실전에 도입했는데 비용>효과라면 다른 방향으로 과제를 해결하는 것이 합리적이다.
• 그 과제를 반드시 머신러닝으로 해결해야만 하는지 생각해야 한다.
  • 바쁜 회사원이 아이와 이야기할 시간이 부족하다고 해서 머신러닝 챗봇으로 소통을 대신하도록 맡기는 것은 권장하지 않는다.

7.1.2 머신러닝으로 해결 가능한지 검토하기

• 과제를 찾았다면, 머신러닝으로 해결할 수 있을지를 생각해본다.
• 머신러닝은 많은 양의 데이터가 필요한데, 완전히 새로운 사업이라면 데이터가 존재하지 않는 경우도 있다.
  • 예를 들어 새로운 상품 추천의 경우, 상품에 관한 데이터가 존재하지 않아 추천 모델은 만들 수 없다 (콜드 스타트 문제).
• 데이터가 존재하더라도 사용 가능한 상태로 정리되어 있어야 하며, 데이터 간 관계를 정리해야 한다.

7.1.3 과제 해결 정도를 수치로 평가하기

• 머신러닝이 과제 해결에 유효하다는 것을 입증하려면 과제의 진행상황을 수치로서 평가해야 한다.
  • 생산 라인에 불량품 검지를 활용한다면: Accuracy, Precision, Recall
  • 매장의 수요예측 과제라면: MAE (평균 절대 오차), RMSE (평균 제곱근 오차)
  • 전자 상거래 사이트의 추천 시스템이라면: PR 곡선, ROC 곡선
  • 비즈니스 영역에서 사용하기 위해서는 위 지표들을 비즈니스 지표로 환산해서 이해할 필요가 있다.

• 불량품 검지를 예로 들어보자.

  

  • 기존: 사람이 직접 검지
  • 변경: 머신러닝 시스템 도입
  • 검지 인원의 인건비 > 머신러닝 시스템의 개발, 운용비용이 성립해야 한다.
  • 불량품을 놓친 것에 의한 사업 손실 > 불량품으로 오분류된 정상 제품의 총비용 같은 지표로 비즈니스를 평가할 수 있다.

7.1.4 머신러닝 시스템의 요건을 정의

• 모델을 도입하는 시스템을 선제적으로 검토해야 한다.
  • 예를 들어 웹 시스템이나 스마트폰 앱과 조합한다면 다음과 같은 과제가 있다:
    • 사용자와의 인터랙션이나 지연
    • UI/UX
    • 추론 속도
• 추론이나 배치 시스템의 속도가 느리다면 리소스의 스케일 아웃을 고려해 볼 수 있다.
  • 이때 발생하는 리소스의 비용이 머신러닝 도입으로 인한 효과에 비해 과하지 않아야 한다.
• 높은 정답률을 목표로 하는 복잡한 머신러닝 모델을 개발하는 것보다 적은 비용으로 안정되고 고속으로 추론 가능한 모델이 훨씬 도움이 되는 케이스가 많다.

7.1.5 머신러닝 모델 개발

• 시행착오를 거치면서 요건 (평가지표, 추론 속도, 안정성, 비용 등)을 만족시키는 것을 목표로 한다.
• 요건에 따라서는 완벽하지 않더라도 ‘그럭저럭’ 괜찮은 모델로 릴리즈해 효과를 보면서 계속 개발해 나갈지 판단할 수도 있다 → 시간과 예산은 한정되어 있기 때문에 어느 정도의 타협은 필요하며, 어느 수준의 모델을 어떤 타이밍에 릴리즈하거나 중지할 것인지 판단하는 것이 중요하다.

7.1.6 평가 및 효과 검증

• 모델 릴리즈 후 평가와 효과 검증이 필요하다.

  

  • 모델이 예상대로 추론 결과와 비즈니스 효과를 내고 있는지를 검증한다.
  • 사용자에 의한 지표 (클릭률이나 체류시간 등)에 영향이 있을 수 있고, 클레임이 들어올지도 모른다.
  • 사내 시스템이라면 직접 사용자와 인터뷰를 해보는 것도 좋다.
  • 머신러닝 도입에서 최악의 사태: 효과를 검증할 수 없는 (또는 검증하지 않는) 상태다.

• 이제 머신러닝 컴포넌트를 통합한 하나의 워크플로를 구현해본다. 수요 예측과 콘텐츠 업로드 서비스를 예로 들어 각 머신러닝 시스템의 구성 예시에 대해 설명한다.

7.2 수요예측 시스템

7.2.1 상황과 요건

• 서비스업에서 앞으로 일주일간의 수요를 예측하는 시스템을 생각해보자.

  

  • 전국에 수백 개의 매장을 내고 영업 중이다.
  • 각 매장에서는 동일한 서비스를 제공하고 있으며, 반드시 점원이 3명 이상 상주해야 한다.
  • 계절과 시간대, 요일에 따라 매장 방문 고객 수가 변동한다.
  • 경기 불황으로 인해 점원들의 근무 시간을 조정하여 인건비를 삭감하고 싶다.
  • 각 매장의 방문자 수를 예측해 필요한 점원의 수를 최소한으로 계획해야 한다.
• 워크플로
  • 앞으로 일주일 동안의 수요를 예측해 교대근무 계획을 세워야 한다.
  • 근무 안내를 위해 근무 시작 4일 이전에는 추론이 완료되어 있어야 한다.
    • 따라서 근무 시작 6일 전에는 추론을 실행하고, 그다음 날 (5일 전)에는 이를 바탕으로 스케줄을 완성한다.
    • 하루 정도 여우가 있기 때문에 추론에 실패하더라도 재시도할 수 있다.
• 추론기는 배치 시스템으로 구성한다.
  • 수년 전 - 최근 데이터를 이용해 전체 매장의 수요예측을 실시한다.
  • 한 번 정도의 실패를 가정해 배치 처리는 두 번 실행하고, 추론 결과를 확인하는 시간이 필요하다.
• 추론 대상의 인터벌을 설정한다.
  • 근무를 1일 단위로 짠다면 1일 단위의 방문자 수를 예측한다.
  • 시간대별 근무를 짜는 경우는 시간대별 수요를 예측해야 한다.
• 추론 결과를 평가한다.
  • 다른 모델과 비교하는 경우, 비교 대상으로 활용할 매장을 분할, 선택하고 여러 종류의 모델로 추론을 실행할 수 있도록 시스템을 개선해야 한다.

7.2.2 시스템 만들기

• 학습 데이터: 매장별 방문자 수의 시계열 데이터가 적절.
  • 각 매장별로 2일 전까지의 방문자 수 데이터가 DWH에 집계되어 이용 가능하다고 한다 (화요일에 사용할 데이터는 2일 전인 일요일까지의 방문자 수 시계열 데이터다).
• 테스트 데이터: 최근 일주일 동안의 방문자 수
• 검토 사항
  1. 매주 모델을 학습? vs. 한 번 학습한 모델을 계속 사용?
  2. 매주 학습한다면, 하이퍼파라미터나 알고리즘은 변경할 것인가?
     • 매주 모델을 학습한다면 화요일에 배치 처리를 시작해서 목요일에 수요예측을 배포할 수 있도록 기한에 유의해서 학습이 완료되어야 한다.
     • 안정적으로 학습할 수 있는 모델이면 좋겠지만, 그렇지 않다면 학습을 자주 하지 말고 평가를 보며 천천히 개선해도 좋다. - 하이퍼파라미터나 알고리즘의 변경은 엄밀하게 검토할 필요가 있다 (1주일 동안 새로운 하이퍼파라미터나 알고리즘을 얼마나 시도할 수 있을지는 모르겠지만 배치 시스템에 도입하려면 시간이 더 필요하다).
• 다음으로 학습, 추론, 평가, 운용에 필요한 컴포넌트를 생각해 보자.

• 학습 데이터
  • 몇 년간의 수백 개 매장에 대한 시계열 데이터이므로, 용량이 매우 클 것이다.
  • 파이프라인 학습 기반으로 파라미터나 데이터를 바꿔가며 진행한다.
• 추론 실시
  • 배치 추론으로 이뤄진다.
  • 실행 시간을 고려해 필요 리소스를 스케일 아웃/스케일 인한다.
  • 클라우드나 쿠버네티스 클러스터를 사용해서 필요할 때 리소스를 할당하는 구성이다.
• 추론 결과의 평가
  • 2일 전 방문자 수를 DWH로부터 가져와서 BI 툴로 추론 결과와 함께 시각화해서 비교한다.
  • 추론 결과가 각 매장의 시간대와 날짜에 따른 방문자 수를 잘 반영하는지 측정한다.

  • A/B 테스트를 실시하고 있다면 아래와 같이 각 모델별로 결과를 시각화해 볼 필요가 있다.

    

• 운용
  • 배치의 실행과 확인, 재시도와 함께 매장에 배포를 정기적으로 실행한다.
  • 확인 작업도 일손이 필요하다 → 추론 결과를 효율적으로 보고 판단하기 위한 시각화 방법을 적극 활용한다.
  • 모델의 개선과 비교를 위해 여러 모델을 배포하는 구조와 각 모델의 추론 결과를 배포할 매장을 선정한다.

7.3 콘텐츠 업로드 서비스

7.3.1 상황과 요건

• 동물의 사진과 설명에 특화된 업로드 서비스를 예로 들어 보자.
  • 이 서비스는 자신이 촬영한 사진에 제목을 붙이고 설명을 조합해 업로드할 수 있다.
  • 서비스의 목적은 동물을 좋아하는 사용자가 동물의 모습을 즐길 수 있게 하는 것이다.
  • 그러므로 동물의 사체를 포함한 징그러운 모습은 업로드를 금지한다.
  • 동물 외 피사체나 사람도 역시 제외한다.

• 서비스 화면

  

  • 크게 2가지 화면이 준비된다.
    1. 콘텐츠 게시 화면
    2. 게시된 콘텐츠의 목록을 보는 화면
  • 콘텐츠는 시간순으로 표시되며, 사용자는 최신 콘텐츠를 위에서부터 차례로 볼 수 있다.
• 콘텐츠 태그
  • 편리하게 검색하기 위해 태그를 붙이는 기능도 있다.
  • 새끼고양이가 콘텐츠라면 ‘고양이’, ‘새끼고양이’처럼 태그 붙일 수 있다.
• 여기서는 금지 콘텐츠를 검지하는 기능을 머신러닝으로 개발하기로 한다.
  • 살아 있는 동물 외의 콘텐츠를 검지하는 것을 목표로 한다.

• 콘텐츠를 머신러닝으로 스크리닝할 수 있는 타이밍

  

  1. 사진을 선택한 시점에 검지
     • 업로드 버튼을 누르기도 전에 스크리닝을 시작하고 ‘해당 사진은 업로드할 수 없습니다’와 같이 주의를 주는 UI를 만든다.
     • 사용자가 서비스를 잘못 사용하고 있다는 느낌을 받을 수도 있다.
  2. 업로드하기 버튼을 누른 타이밍에 검지
     • 사용자가 결과를 기다리게 되므로, 지연이 길면 사용자 이탈의 요인이 될 수도 있다.
  3. 업로드 후 비동기적인 검지
     • 일단 ‘콘텐츠 업로드가 완료할 때까지 잠시 기다려 주세요’라고 화면에 표시하고, 다른 활동을 할 수 있게 한다.
     • 문제가 없으면 콘텐츠가 업로드되고, 문제가 있다고 판단되면 사용자에게 푸시 알림이나 메일로 통지한다.
     • 사용자의 화면 트랜지션이 멈추는 일은 없지만, 업로드 성공 여부를 확인하기까지 시간이 필요하다.
• 여기서는 3번을 선택한다.
  • 콘텐츠 업로드 후 1시간 이내로 통지를 보낼 것을 서비스 수준의 목표로 삼고, 그 이상 걸리는 콘텐츠가 생기면 운용상 장애로 정의한다.

• 사진 업로드 수나 빈도는 시간대와 요일에 따라 차이가 있다.

  

  • 평일에는 저녁-밤 시간대에 업로드가 많겠지만, 휴일에는 낮-밤에 걸쳐 골고루 업로드될 것이다.
  • TV에서 동물 관련 프로그램이 방송되는 날은 방송 후 업로드 수가 증가할지도 모른다.
  • 장기적으로는 신규 사용자가 유입되어 업로드 수가 완만하게 증가할 것이다.
  • 업로드 수에 따라 스케일 아웃/스케일 인하는 시스템이 필요하다.
• 검지 대상
  1. 동물 이외의 콘텐츠 (사람도 제외)
  2. 동물은 맞지만 사체인 경우거나 콘텐츠가 징그러운 경우
     • 분류 판단은 매우 어렵다. (죽은 듯 잠든 동물이 사체인지 아닌지 판단하는 것은 어렵다)
     • 우선은 사람의 얼굴이 찍혀 있는 콘텐츠 업로드를 금지하는 것부터 시작해보자.
• 추론기 성능 평가
  1. 시간당 추론 가능한 콘텐츠 수
  2. 머신러닝 모델의 정확도
• 머신러닝 모델의 정확도를 판단할 때 아래와 같은 지표를 사용할 수 있다.
  • 업로드가 완료된 콘텐츠 중 사람의 얼굴이 찍혀버린 콘텐츠의 비율 (위음성)
  • 업로드 금지로 판정된 콘텐츠 가운데 실제로는 사람의 얼굴이 찍히지 않은 콘텐츠의 비율 (위양성)

• 위 두 가지는 트레이드오프 (trade-off) 관계에 있다.

  

  • 전자를 우선하면 (놓침 방지) 사용자가 겪는 업로드 금지 횟수가 늘어나 사용자 이탈로 이어질 수 있다.
  • 후자를 우선하면 (개입 방지) 업로드 서비스의 치안이 악화되고, 동물과 무관한 콘텐츠가 증가할 것이다.
• 사실은 머신러닝의 추론 정확도를 측정하는 방법이 선행되어야 한다.
  • 놓침 방지나 개입 방지를 꾀한다 해도 어쨌든 사람의 얼굴이 찍힌 콘텐츠의 개수를 모른다면 비율도 계산할 수 없기 때문이다.
  • 콘텐츠 수가 적으면 사람이 확인하겠지만 (샘플링 등), 규모가 커지면 비율 계산이 현실적으로 불가능해진다.
• 타협안으로 후자를 선택한다.

7.3.2 모델과 시스템

• 검지 구현 방법
  • 이미지 분류나 객체 인식으로 구현이 가능하다.
  • 일반적으로 이미지 분류보다 객체 인식이 연산량이 크고 느리다.
  • 객체 인식의 학습이 이미지 분류 학습보다 느리기도 하다.

  • 데이터를 만들 때도 이미지 분류라면 사람 얼굴이 찍힌 사진을 모으는 것으로 그치지만, 객체 인식에서는 얼굴의 위치를 특정해야 한다.

    

  • 신속하게 만들어야 한다면 이미지 분류가 적절하고, 시간을 투자하더라도 좋은 시스템을 만들고 싶다면 객체 인식에 집중하는 것이 좋다.
  • 여기서는 일단 이미지 분류를 가동시킨 후 운영상 문제가 생길 것 같다면 객체 인식을 추가한다.
• 학습할 모델 선정
  • 업로드 후 1시간 이내에 추론해서 결과를 반환해야 하므로, 모델의 부하 내성이나 스케일러빌리티를 고려해야 한다.
  • Peak 업로드 수가 평소의 2배 정도라고 가정한다.
  • Peak 부하로 2시간 동안 추론기로 요청을 계속 보내 1시간 이내로 추론할 수 있는지를 검증한다.
  • 요청의 10% 이상의 양이 1시간 이상 큐에 정체된다면 해당 모델은 사용할 수 없다고 판단 내린다.
• 비용 고려
  • 무한정 스케일 아웃하면 많은 요청을 처리할 수 있겠지만 비용이 많아진다.
  • 월 150만 원 정도를 한도로 설정하고, 이에 맞춰 리소스를 한정한다.
  • 이 예산으로는 GPU를 사용하지 못할 것이므로 CPU를 적극 활용한다.
• 릴리즈를 위한 평가
  • 추론 성능 평가 지표에 근거하여 모델을 평가한다.
  • 테스트 데이터로 최근 1주간의 업로드 콘텐츠를 사용하며 (열심히 분류해 놓는다), 다음과 같이 평가한다.
    1. 업로드 가능한 콘텐츠와 금지 콘텐츠를 정확하게 분류한 비율 (Accuracy)
    2. 실제 금지 콘텐츠를 금지 콘텐츠로 추론한 것의 비율 (Recall)
    3. 모델이 금지 콘텐츠로 추론한 콘텐츠 중에서 실제 금지 콘텐츠의 비율 (Precision)
    4. 모델이 금지 콘텐츠로 추론한 콘텐츠 수가 1주일 안에 운영자가 체크할 수 있는 범위에 들 것
  • 1, 2, 3번은 일반적으로 쓰이는 지표들이다.
  • 4번은 지금 논의하는 서비스에 특화된 지표이다.
  • 운영자가 미처 체크하지 못한 것을 금지 콘텐츠로 추론하는 일은 피해야 한다.
  • 인원과 시간을 무한정 늘릴 수 없으니, 같은 금지 콘텐츠를 반복해서 업로드하는 경우에 대한 조치도 고려한다.

7.3.3 머신러닝 활용하기

• 이제 실제 시스템에 도입할 수 있게 되었다.

  

• 모델 패턴
  • 모델을 교체할 가능성도 있기 때문에 추론기는 모델 로드 패턴 (3.5절)으로 릴리즈한다 (모델 교체가 간편해야 한다).
• 추론 시스템 패턴
  • 비동기적으로도 추론할 수 있기 때문에 비동기 추론 패턴 (4.4절)을 사용할 수 있다.
  • 병렬 마이크로서비스 패턴 (4.8절)으로 중간에 프락시를 준비하고 여러 모델로 추론하는 방법도 있다.
  • 모델의 정확도를 지속적으로 평가하기 위해서는 추론 로그 패턴 (5.2절)과 추론 감시 패턴 (5.3절)을 도입한다.
• 금지라고 추론한 콘텐츠는 사람이 직접 체크한다.
  • 체크 결과를 향후 지도학습 데이터로 활용해 모델의 약점을 보강해 나간다.
  • 추가 데이터로 모델을 재학습했다면, 섀도 A/B 테스트 패턴 (6.5절)과 온라인 A/B 테스트 패턴 (6.6절)으로 모델을 평가한다.
  • 다른 알고리즘의 모델을 신규로 개발한 경우라면 병렬 마이크로서비스 패턴을 응용해 여러 모델로 추론하고 그 결과를 집약시키는 것도 가능하다.

7.3.4 ML옵스

• 이미지 분류를 이용한 검지 시스템을 2개월 정도 운용했다. 금지 콘텐츠의 업로드 수는 줄었으나, 다음과 같은 새로운 과제가 발생하고 있다고 한다.
  1. 금지가 아님에도 금지 판정을 받은 콘텐츠를 업로드한 사용자의 클레임.
  2. 사람의 얼굴이 작게 나온 사진은 높은 빈도로 간과되고 있음.
  3. 사람의 얼굴이 같이 찍혔지만, 업로드를 원한다는 사용자의 요망.
• 1이 발생하는 원인에는 여러 가지가 있겠지만, 운영자가 부족해 사람에 의한 스크리닝에서 간과되었을 가능성이 있다.
  • 심야나 연휴 중에는 금지 콘텐츠의 전수 체크가 늦어지니 지연이 생긴다.
  • 해결책으로는 운영자 수를 늘리거나, ‘기다리게 해서 죄송합니다’와 같은 알림을 넣을 수 있다.
  • 모델을 개선해 클레임 수를 줄일 수도 있다.
• 2는 이미지 분류 모델에 관한 과제다.
  • 이미지 자체의 분류를 실행하고 있기 때문에 작은 피사체까지 판별하지는 못할 가능성이 있다.
  • 객체 인식을 도입하면 해결이 가능할지도 모른다.
  • 7.3.2절의 절차대로 객체 인식 모델을 사용할 수 있는지 판단한다.
  • 도입하게 되었다면, 현행 모델과 비교하기 위해 A/B 테스트 (6.5, 6.6절)로 평가한다.
  • 이미지 분류와 객체 인식으로 검지할 수 있는 콘텐츠의 경향이 달라 상호 보완해야만 한다면, 병렬 마이크로서비스 패턴 (4.8절)을 가동시켜야 한다.
  • 이미지 분류 후 한 번 더 체크하기 위한 수단으로 객체 인식을 실행하는 경우는 직렬 마이크로서비스 패턴 (4.7절) 또는 시간차 추론 패턴 (4.9절)이 유효하다.
  • 아주 작은 얼굴이라 서비스에 지장이 없다고 판단된다면 이미지 분류 모델을 계속 사용해도 될 것 같다 (특히 객체 인식 모델 도입에 필요한 리소스가 과다한 경우).
• 3에 관해서는 사용자의 심리를 이해하려는 노력이 필요하다.
  • 사람이 함께 찍힌 동물의 사진을 허가해준다면 지금까지 만들어 온 금지 콘텐츠 검지 시스템은 더 이상 필요하지 않다.
  • 개인 정보 보호의 관점에서 사람의 얼굴을 내보내지 않기로 결정했다면, 보조로 사람의 얼굴에 자동으로 모자이크를 넣는 기능을 제공하는 것을 검토할 수 있다 (모자이크 도입과 관련된 절차는 이번 장에서 설명한 바와 같다).

  • 여러 기능의 가치와 비즈니스 효과를 저울질해 서비스 지표를 명확하게 정의하고, 사용자 테스트를 거듭하면서 머신러닝을 포함한 프로덕트를 릴리즈하고 개선하도록 한다.

    

• ML옵스란 결국 머신러닝을 실제 시스템에서 효과적으로 활용하기 위한 개발과 운용에 대한 방법론이며, 머신러닝을 사용해 성공적으로 프로덕트를 이끌기 위한 조직 및 비즈니스에 관한 설계다.
  • 머신러닝으로 모델을 만들어 API로 가동시키는 것에 그쳐서는 안 된다.
  • 목표: 릴리즈 → 과제와 클레임에 지속적으로 대처 → 사용자 만족을 위한 피드백 (이 루프를 반복)
  • 목표를 실현하기 위해서는 프로덕트나 비즈니스를 어째서 유지해야 하는지, 왜 머신러닝을 통한 기능이 필요한지 등 끝까지 의문을 품는 자세를 가져야 한다.
  • 확률적이고 불완전한 머신러닝을 사용하는 방법이나 상황과 함께 더욱 좋은 방향으로 바꿔 나가려는 노력이 필요하다.