Studyjam 6) Production ML Systems - Train & Serving 디자인 방법

이전 포스트에서는 ML 시스템의 전반적인 구조에 대해서 알아보았다면,

이런 구조를 디자인(선택)하는 관점들에 대해서 알아보도록 하겠습니다.

1) Training & Serving Design Decisions

먼저, Training과 Serving 컴포넌트를 디자인 하는 방식은 각각 두 가지가 있습니다.

이런 디자인 방법을 알고 있다면, 상황에 따라서 적절한 패러다임을 선택할 수 있을 것입니다.

1-1. Training Decisions : Static vs Dynamic Training

dynamic training은 데이터를 지속적으로 추가해서 모델을 튜닝해야 할 때 사용합니다.

대신에,

• 구현하기 어렵습니다.
  • model monitoring
  • model rollback
  • data quarantine : 데이터를 8비트씩 쪼개서 처리속도를 빠르게 하는 장면
• 유지보수가 힘듭니다 : 새로운 데이터가 우리 데이터 처리 로직과 호환되는지 점검해야함.

때문에 우리 로직을 상황에 맞게 잘 선택해야 합니다.

예시를 들어보겠습니다

• Voice to text

  • Global model -> 오프라인에서 훈련 가능, Static
  • Personalized model -> 빠른 갱신 필요, Dynamic,

• Shopping ad conversion rate

  • ad conversion rate란?

    광고를 클릭해서 특정 액션(구매, 가입, 전환)을 취한 비율

  • 그렇지만, conversion은 즉각적으로 일어나는 것이 아니기 때문에 dynamic training보다는 static이 낫다는 입장입니다.

1-2. Reference architecture for training

• Static training

  

  모델이 한번 훈련됨 => ML 엔진을 통하여 배포되는 간단한 구조!

• Dynamic training

  먼저, Cloud Function이 필요합니다.

  

  Cloud function은 비동기적인 training을 지원하는 녀석이며,

  비동기적으로 트레이닝을 하고, 새로운 모델을 덮어씌워줍니다.

  (물론 파일을 가지고 오기 위해서 웹의 trigger과 데이터를 연결시켜주는 User trigger도 필요합니다.)

  그 외에도 Cloud Dataflow 과 같은 컴포넌트도 필요합니다.

  다음과 같은 Cloud Dataflow pipeline을 통해서 연속적으로 끊기지 않고 모델을 학습시켜줄 수 있습니다.

  전체적인 Dynamic training 구조는 다음과 같습니다.

  

1-3. Serving Decisions : Static vs Dynamic

이제는 Serving 컴포넌트를 디자인하는 방법입니다.

앞선 포스트에서, Serving이란 유저의 요청에 따른 예측값을 반환해주는

것이라고 할 수 있습니다.

모델을 서빙하는 방식에도 역시 두 가지가 있습니다.

유저에 대한 latency를 줄이기 위해서 적절한 방법을 선택해야겠지요.

Static serving은 Offline inference라고도 불립니다.

그러니까, 유저가 요청할 수 있는 경우의 수를 전부 계산해놓은 테이블을 만들고,

유저의 요청이 들어오면 사실 모델을 작동시키는게 아니라, 테이블에서 값만 빼내서 보여주는 것이죠.

그에 반해 Dynamic serving은 Online inference라고 불리는데요,

On-demand하게, 즉 유저가 요청이 들어올 때 마다 모델을 직접 작동시켜서 예측값을 반환해주는 것입니다.

이에 따른 장단점도 예측해볼 수 있습니다.

• Static serving : 속도 빠름 but, 모든 경우의 수를 계산해야 하므로 경우의 수가 많다면 Storage Cost가 높아질 수 있음.

• Dynamic serving : 모델을 직접 작동하기 때문에 속도가 느립니다. 이는 웹사이트에서는 꽤나 심각할 수 있겠지요.

  => 그렇기 때문에 이런 식으로 Serving을 위한 layer를 설계하는 글도 있습니다. (참고만 하세요!)

그러면 어떤 방식이 더 효율적일까요?

다음 두 가지 개념이 사용됩니다.

• Cardinality : 가능한 모든 경우의 수

  • 경우의 수가 적다면 그냥 테이블 쓰는게 편하지만,

    가능한 경우의 수가 무한하다면… 얘기가 달라지겠죠?

• Peakedness : distribution of the prediction workload 이 균형잡혀있는가?

  • Peakedness가 높다는게 무슨 뜻일까요?

    ex) 이전 문장으로부터 다음 단어를 도출하는 모델

    => 상위 단어의 사용 빈도가 훨씬 높기 때문에 우리 prediction의 분포는 굉장히 상위 단어에 쏠려(peak)있을 것입니다.

만약 Cardinality도 높고 Peakedness도 높다면,

자주 도출되는 prediction만 테이블로 만들어 놓고(Static), 그 테이블 안에 없다면 모델을 활용(Dynamic)하는 방식도 생각해 볼 수 있습니다.

그것이 Hybrid 방식입니다.

1-4. Reference architecture for serving

• Static serving

  Static serving은 사실상 Online으로 작동하지 않으므로 batch prediction job으로 바꾸고, 그에 따른 Table만 작성하면 됩니다.

  

• Dynamic serving

  Dynamic serving은 그냥.. 우리가 상식적으로 생각하는 방식과 동일합니다..

  Client가 보낸 인풋에서, 모델을 통해서 예측값을 도출합니다.