Translate lifecycle-patterns (#3)

* translate lifecycle patterns part * nits * Update Lifecycle-patterns/Train-then-serve-pattern/design_ko.md Co-authored-by: Sung Yun Byeon <[email protected]> * Update Lifecycle-patterns/Train-then-serve-pattern/design_ko.md Co-authored-by: Sung Yun Byeon <[email protected]> * Update Lifecycle-patterns/Train-then-serve-pattern/design_ko.md Co-authored-by: Sung Yun Byeon <[email protected]> * Update Lifecycle-patterns/Train-then-serve-pattern/design_ko.md Co-authored-by: Sung Yun Byeon <[email protected]> * Update Lifecycle-patterns/Training-to-serving-pattern/design_ko.md Co-authored-by: Sung Yun Byeon <[email protected]> * Update Lifecycle-patterns/Training-to-serving-pattern/design_ko.md Co-authored-by: Sung Yun Byeon <[email protected]> * Update Lifecycle-patterns/Training-to-serving-pattern/design_ko.md Co-authored-by: Sung Yun Byeon <[email protected]> * Update Lifecycle-patterns/Training-to-serving-pattern/design_ko.md Co-authored-by: Sung Yun Byeon <[email protected]> * Update Lifecycle-patterns/Training-to-serving-pattern/design_ko.md Co-authored-by: Sung Yun Byeon <[email protected]> * Update Lifecycle-patterns/Train-then-serve-pattern/design_ko.md Co-authored-by: Sung Yun Byeon <[email protected]> * Update Lifecycle-patterns/Train-then-serve-pattern/design_ko.md Co-authored-by: Sung Yun Byeon <[email protected]> * Update Lifecycle-patterns/Training-to-serving-pattern/design_ko.md Co-authored-by: Sung Yun Byeon <[email protected]> * Update Lifecycle-patterns/Training-to-serving-pattern/design_ko.md Co-authored-by: Sung Yun Byeon <[email protected]> * Update Lifecycle-patterns/Training-to-serving-pattern/design_ko.md Co-authored-by: Sung Yun Byeon <[email protected]> * Update Lifecycle-patterns/Training-to-serving-pattern/design_ko.md Co-authored-by: Sung Yun Byeon <[email protected]> * fix spaces Co-authored-by: Sung Yun Byeon <[email protected]>
mercari · Jun 25, 2020 · 2ae6e59 · 2ae6e59
1 parent 4770d51
commit 2ae6e59
Show file tree

Hide file tree

Showing 3 changed files with 78 additions and 0 deletions.
diff --git a/Lifecycle-patterns/README_ko.md b/Lifecycle-patterns/README_ko.md
@@ -0,0 +1,5 @@
+# Lifecycle patterns
+
+- [Train-then-serve pattern](./Train-then-serve-pattern/design_ko.md)
+
+- [Training-to-serving pattern](./Training-to-serving-pattern/design_ko.md)
diff --git a/Lifecycle-patterns/Train-then-serve-pattern/design_ko.md b/Lifecycle-patterns/Train-then-serve-pattern/design_ko.md
@@ -0,0 +1,34 @@
+# Train-then-serve pattern
+
+## Usecase
+- 머신 러닝 모델부터 실제 운영까지 전체 워크플로우를 디자인하는 경우.
+- 학습과 릴리즈를 각각 다른 워크플로우로 분리할 때. 
+- 모델의 릴리즈 품질을 수동으로 평가할 때. 
+- 실제 운영 환경에서 모델을 평가할 때. 
+
+## Architecture
+학습과 서빙을 연결하는 워크플로우를 설계할 때, 학습 패턴과 서빙 패턴을 조합하는 구성을 할 수 있습니다. 평가가 끝난 학습된 모델을 수동으로 릴리즈를 할 때, 여러 패턴을 조합한 train-then-serve 패턴을 사용할 수 있습니다. 이 워크플로우에서는 사람에 의한 평가가 들어가기 때문에, 자주 모델 릴리즈를 하려면 적합하지 않은 구조이지만, 모델과 시스템의 품질을 확실히 보장할 수 있습니다. 
+ <br>
+ 학습과 서빙을 연결하기 위해 [model load pattern](../../Operation-patterns/Model-load-pattern/design_ko.md)이나 [model-in-image pattern](../../Operation-patterns/Model-in-image-pattern/design_ko.md)을 사용할 수 있습니다. 이는 모델과 예측 서버 관리하는 방법에 따라 결정할 수 있습니다. 현재 서버에서 변경 없이 모델을 업데이트하려면 [model load pattern](../../Operation-patterns/Model-load-pattern/design_ko.md)을, 전체 서버를 업데이트해야 한다면  [model-in-image pattern](../../Operation-patterns/Model-in-image-pattern/design_ko.md)을 선택할 수 있습니다. 
+ <br>
+실제 운영 환경에서는 프록시 환경 변수 수정으로 운영 중인 모델의 예측 동작을 업데이트 할 수 있는 [parameter-based serving pattern](../../Operation-patterns/Parameter-based-serving-pattern/design_ko.md)이 효과적일 수도 있습니다. 서비스 관리 측면에서 [prediction log pattern](../../Operation-patterns/Prediction-log-pattern/design_ko.md)과 [prediction monitoring pattern](../../Operation-patterns/Prediction-monitoring-pattern/design_ko.md)은 반드시 사용되어야 합니다. 
+<br>
+서빙 패턴과 QA 패턴을 선택하는 것은 운영 요건에 따라 달라질 수 있지만, 결국 여러 패턴의 조합이 될 것이라 생각합니다. 아래 그림은 [web single pattern](../../Serving-patterns/Web-single-pattern/design_ko.md)과  [online AB testing pattern](../../QA-patterns/Online-ab-test-pattern/design_ko.md)의 조합을 표현한 다이어그램입니다. 로그들은 DWH(Data Ware House)에 기록되어 모델 개선과 재학습에 사용됩니다. 
+<br>
+학습과 서빙 단계 분리의 장점은 릴리즈 전에 모델을 평가할 수 있다는 것입니다. 만약 릴리즈 전 테스트 데이터셋 기반의 평가가 충분하지 않다 생각되거나 수동 품질 보증이 필요한 경우 이 구성을 생각해 볼 수 있습니다. 또한, 이 패턴은 학습 및 서빙을 구분함으로써 학습 파이프라인의 장애가 서빙 시스템과 릴리즈에 직접적인 영향을 끼치지 않아 서비스 가용성을 강화시켜줍니다. 하지만 모델을 실시간 혹은 자주 업데이트해야 하는 경우는 적합하지 않습니다. 
+
+## Diagram
+![diagram](diagram.png)
+
+
+## Pros
+- 릴리즈 전 수동으로 모델을 평가합니다.
+- 워크플로우와 학습 및 릴리즈 장애를 분리할 수 있습니다. 
+
+## Cons
+- 자동화가 되지 않습니다.
+
+## Needs consideration
+- 학습 패턴과, QA 패턴, 서빙 패턴 조합 방법. 
+- 모델 릴리즈 기준.
+- 모델 릴리즈 빈도. 
diff --git a/Lifecycle-patterns/Training-to-serving-pattern/design_ko.md b/Lifecycle-patterns/Training-to-serving-pattern/design_ko.md
@@ -0,0 +1,39 @@
+# Training-to-serving pattern
+
+## Usecase
+- 머신 러닝 모델부터 실제 운영까지 전체 워크플로우를 디자인하는 경우. 
+- 학습 직후 모델을 출시할 경우.
+- 모델을 실제 운영 환경까지 자동으로 배포할 경우. 
+- 모델을 안정적으로 학습할 수 있을 경우.
+- 모델을 자주 업데이트해야 할 경우.
+
+## Architecture
+학습과 서빙을 연결하는 워크플로우를 설계할 때, 학습 패턴과 서빙 패턴을 조합하는 구성을 할 수 있습니다. 학습 파이프라인과 함께 모델을 계속해서 배포해야 하는 경우, 이 패턴을 사용할 수 있습니다. 이 패턴은 학습 파이프라인이 완료되면 자동으로 릴리즈하여 모델 서버를 구축할 수 있습니다. 모델이 자주 업데이트되고 수동 평가가 어려울 경우, 적합한 패턴입니다. 
+<br>
+학습 파이프라인으로는 [batch training pattern](../../Training-patterns/Batch-training-pattern/design_ko.md)이나 [pipeline training pattern](../../Training-patterns/Pipeline-training-pattern/design_ko.md)을 선택할 수 있습니다. [parameter and architecture search pattern](../../Training-patterns/Parameter-and-architecture-search-pattern/design_ko.md)은 학습 모델의 품질이 안정적이라고 할 수 없기 때문에 이 패턴과 적합하지 않은 경우가 많습니다. 
+<br>
+[model load pattern](../../Operation-patterns/Model-load-pattern/design_ko.md)이나 [model-in-image pattern](../../Operation-patterns/Model-in-image-pattern/design_ko.md)을 사용하여 학습과 서빙을 연결할 수 있는데, 원하는 모델과 예측 서버 관리 방법에 따라 결정할 수 있습니다. 현재 서버에서 변경 없이 모델을 업데이트하려면 [model load pattern](../../Operation-patterns/Model-load-pattern/design_ko.md)을, 모든 서버를 업데이트하려면 [model-in-image pattern](../../Operation-patterns/Model-in-image-pattern/design_ko.md)을 선택할 수 있습니다. 
+<br>
+서빙할 때는 [microservice horizontal pattern](../../Serving-patterns/Microservice-horizontal-pattern/design_ko.md)을 사용하는 것이 좋습니다. 이 패턴은 새로운 예측 서버를 다른 서버와 병렬로 배치하고, 프록시를 통해 서비스 검색하여 예측 서버들과 연결해 줍니다. 
+<br>
+서비스 관리 관점에서 [prediction log pattern](../../Operation-patterns/Prediction-log-pattern/design_ko.md)과 [prediction monitoring pattern](../../Operation-patterns/Prediction-monitoring-pattern/design_ko.md) 사용은 필수입니다. 
+<br>
+이 패턴에서는 학습 후 자동으로 모델을 릴리즈하고 실제 서비스에 투입될 수 있습니다. 
+하지만, 반드시 학습과 평가가 안정적이고 학습 파이프라인이 안정적으로 가동되어야 합니다. 학습 모델이 불안정한 경우 오히려 이 패턴은 위험할 수 있습니다. 학습 파이프라인이 불안정한 경우, 전체 워크플로우가 모두 불안정해질 수 있습니다. 또, 실제 운영 환경에 있는 모든 모델을 항상 가동해 둘 필요가 있는지 검토해보아야 합니다. 만약 모델이 필요하지 않은 경우(예를 들어 오래되거나, 성능이 저하된 경우), 해당 모델을 서비스에서 제외시켜야 합니다. 일정 기간이 경과하면 자동으로 예측 서버에서 제외하는 운영 방식이라면 간단하겠지만, 서비스의 목적에 따라 사용되고 있는 모델이 제거될 우려가 있습니다. 대신, 모델을 계속 평가하는 파이프라인을 개발하고 운영한다면 운영은 좀 더 복잡해지겠지만 사용 중인 모델을 제거하는 위험은 줄일 수 있습니다. 
+
+## Diagram
+![diagram](diagram.png)
+
+
+## Pros
+- 학습 후 바로 서비스에 릴리즈가 가능합니다. 
+- 릴리즈를 자주 할 수 있습니다. 
+
+## Cons
+- 학습 파이프라인, 자동 릴리즈, 서비스 디스커버리 등을 개발해야 합니다.
+- 모델 학습 결과가 불안정할 경우 이 패턴은 부적합합니다. 
+
+
+## Needs consideration
+- 모델 학습 안정화, 파이프라인 자동화, 각 단계별 서비스 수준이 요구됩니다. 
+- 서비스 디스커버리와 불필요한 모델 제거 정책이 필요합니다.