[update] data-cache, multiple-stage, prediction-circuit-break (mercar…

…i#11) [update] data-cache, multiple-stage, prediction-circuit-break (mercari#11)
Ar-ALN · Oct 9, 2020 · ffdf09b · ffdf09b
1 parent dd74a3b
commit ffdf09b
Show file tree

Hide file tree

Showing 9 changed files with 109 additions and 175 deletions.
diff --git a/Serving-patterns/Asynchronous-pattern/design_kr.md b/Serving-patterns/Asynchronous-pattern/design_kr.md
diff --git a/Serving-patterns/Batch-pattern/design_kr.md b/Serving-patterns/Batch-pattern/design_kr.md
diff --git a/Serving-patterns/Data-cache-pattern/design_ko.md b/Serving-patterns/Data-cache-pattern/design_ko.md
@@ -0,0 +1,51 @@
+# Data cache pattern
+
+## Usecase
+- 동일하고 반복된 데이터에 대한 예측 요청이 있는 경우.
+- 캐시 키로 데이터를 식별할 수 있는 경우.
+- 데이터 검색 및 처리 속도를 높이고 싶은 경우.
+
+
+## Architecture
+Data cache pattern은 입력 데이터를 캐시합니다. 입력 데이터가 데이터베이스, 저장소 또는 디스크에 저장되어 있으면 데이터 수집 오버헤드를 줄일 수 있습니다. 
+
+<br>
+
+캐시할 데이터의 양은 비용과 사이즈의 균형에 따라 고려해야 할 수도 있습니다. 캐시 공간의 단가는 스토리지 또는 데이터베이스보다 크기가 작을수록 더 비싼 경향이 있으므로 캐시 삭제를 위한 정책을 계획하는 것을 추천합니다.
+
+<br>
+
+예측 결과가 시간에 따라 변경되면 오래된 예측으로 응답하지 않도록 이전 캐시를 지워야 합니다. 서비스 부하가 높아서 캐시 크기가 급격히 증가하는 경우 캐시 삭제 정책을 구체적으로 계획하는 것이 중요합니다. 대부분 캐시는 시간이 경과하거나 키 요청 빈도에 따라 지워집니다.
+
+<br>
+
+이 패턴에 대한 두 개의 아키텍처가 있습니다.
+
+1. 입력 데이터를 캐시합니다. 이 경우 서비스는 데이터 웨어하우스에 입력 데이터를 요청하고 병렬로 캐시하며 캐시가 존재하면 예측 요청을 진행합니다. 캐시가 존재하지 않으면 데이터를 캐시에 추가하고 예측을 요청합니다. 전처리의 부하를 줄이기 위해 전처리 후 데이터를 캐시할 수 있습니다.
+
+<br>
+
+2. 요청하기 전에 전처리 또는 캐시합니다. 이런 경우 예측 요청 전에 서비스에서 첫 데이터 생성과 함께 데이터를 캐시합니다. 데이터에 대한 예측 요청을 받으면 캐시에서 예측을 검색합니다. 대기 시간을 개선하기 위해 캐시 속도를 높이려는 경우 이 방법이 선택하는 것이 좋습니다.
+
+
+## Diagram
+### Input data cache
+![diagram1](diagram1.png)
+
+### Prepare data cache
+![diagram2](diagram2.png)
+
+
+## Pros
+- 요청을 예측 서버로 오프로드하고 성능을 향상시킵니다.
+- 빠른 응답이 가능합니다.
+
+## Cons
+- 캐시 서버 비용이 부과됩니다.
+- 캐시 삭제 정책이 필요합니다.
+
+## Needs consideration
+- 입력 데이터는 키로 식별할 수 있어야 합니다.
+- 속도, 비용, 볼륨 간의 균형을 고려해야 합니다.
+- 캐시 삭제 정책이 필요합니다.
+- 데이터 캐시 정책이 필요합니다.
diff --git a/Serving-patterns/Microservice-vertical-pattern/design_kr.md b/Serving-patterns/Microservice-vertical-pattern/design_kr.md
diff --git a/Serving-patterns/Multiple-stage-prediction-pattern/design_ko.md b/Serving-patterns/Multiple-stage-prediction-pattern/design_ko.md
@@ -0,0 +1,27 @@
+# Multiple stage prediction pattern
+
+## Usecase
+- 대화식 애플리케이션에서 머신러닝 예측을 사용할 경우.
+- 하나의 목적에 가벼운 모델과 무거운 모델이 있는 경우.
+
+## Architecture
+Multiple stage prediction pattern은 워크플로우가 여러 단계로 클라이언트에 응답하는 경우 사용할 수 있습니다. 일반적으로 머신러닝 모델은 테이블 및 숫자 데이터를 사용할 경우 가벼운 경향이 있는 반면, 이미지나 텍스트 같은 비정형 데이터는 무거운 경향이 있습니다. 일부 서비스는 사용자 경험을 개선하기 위해 더 나은 예측을 추가해 빠른 응답을 요구합니다. 웹 애플리케이션은 속도와 정확도의 균형을 유지하는 것이 중요하며, 대화형 애플리케이션은 먼저 빠른 예측을 반환한 후 다음 화면 또는 아래쪽에 더 좋은 예측을 추가하는 방법을 고려할 수 있습니다. 이 패턴은 대화형 애플리케이션에 효과적입니다.
+
+<br>
+
+이 패턴은 두 개의 예측 서버가 존재합니다. 하나는 빠른 동기식으로 응답하고 다른 하나는 나중에 비동기식으로 예측하는 서버입니다. 첫 서버는 REST 또는 GRPC 인터페이스를 사용해 무난한 정확도를 가진 예측을 빠르게 응답하는데 사용됩니다. 후자는 느리므로 비동기 대기열 또는 메세지 서비스가 유용합니다. 프러덕션 모델은 여러 형태를 사용할 경우 예를 들어 동기식 예측을 위한 수치 및 범주형 데이터, 비동기식 예측을 위한 영상과 텍스트 같이 사용될 데이터로 분리될 수 있지만, 예측 품질과 응답 속도의 요구 사항에 따라 달라집니다.
+
+
+## Diagram
+![diagram](diagram.png)
+
+
+## Pros
+- 빠르게 대응하고 그 후 더 잘 예측합니다.
+
+## Cons
+- 여러 서비스와 인터페이스가 필요합니다.
+
+## Needs consideration
+- 속도, 정확도, 유저 경험의 균형을 맞춰야 합니다.
+- 무거운 예측을 제공하는 방법에 대해 고민해야 합니다.
diff --git a/Serving-patterns/Prediction-circuit-break-pattern/design_ko.md b/Serving-patterns/Prediction-circuit-break-pattern/design_ko.md
@@ -0,0 +1,31 @@
+# Prediction circuit break pattern
+
+## Usecase
+- 예측 요청량 또는 빈도가 갑자기 증가할 가능성이 있는 경우.
+- 갑작스러운 요청에 빠르게 응답할만큼 빠르게 스케일 아웃할 수 없는 경우.
+- 100% 응답할 필요가 없는 경우.
+
+## Architecture
+캠페인이나 외부 이벤트 때문에 웹 서비스나 관련 서비스에 접속이 증가하는 경우가 있습니다. 만약 클라우드 서비스 또는 쿠버네티스를 사용한다면 요청량만큼 스케일 아웃을 할 수 있지만, 스케일 아웃 속도보다 요청량이 증가하는 속도가 더 빠른 경우가 많습니다. 특히 서버 또는 컨테이너 이미지에 모델 파일이 포함된 경우, 모델을 실행하거나 다운로드 받는데 시간이 오래 걸릴 수 있습니다. 
+
+<br>
+Prediction circuit breaker pattern은 스케일 아웃이 성공할 때까지 `complete outage`를 방지하는 아키텍처입니다. 예측 서버가 예측할 수 있을 만큼 예측하고, 특정 한계 이상으로 요청이 오면 예측을 취소합니다. 전체 중단이 최악의 경우라 생각하면 부분 중단이 합리적이라고 생각할 수 있습니다. 요청이 많으면 예측 서버가 다시 시작되어 예측 리소스가 줄어드는 경우가 자주 발생합니다. 모든 예측에 응답하기 위해 스케일 아웃이 완료될 때까지 현재 예측 서비스를 안정화해야 하고, 안정화를 위해 특정 수의 요청을 취소하는 것이 합리적입니다.
+
+<br>
+
+이 패턴의 중요한 점은 취소된 요청에 대한 대안을 세우는 것입니다. 사용자 경험 저하를 최소화하고 클라이언트 활동을 중단하지 않아야 합니다. 취소를 위한 워크플로우를 고려하는 것이 좋습니다.
+
+
+## Diagram
+![diagram](diagram.png)
+
+## Pros
+- 서비스의 완전한 중단을 피합니다.
+- 현재 리소스 가용성을 낮추지 않고 예측 서버를 확장할 수 있습니다.
+
+## Cons
+- 취소된 요청에 대한 대안이 필요합니다.
+
+## Needs consideration
+- 취소된 요청에 대한 대안 및 워크플로우.
+- circuit breaking limit은 일반적 서비스 요청 증가에 대응할 수 있을만큼 높아야 합니다.
diff --git a/Serving-patterns/Prep-pred-pattern/design_kr.md b/Serving-patterns/Prep-pred-pattern/design_kr.md
diff --git a/Serving-patterns/Synchronous-pattern/design_kr.md b/Serving-patterns/Synchronous-pattern/design_kr.md
diff --git a/Serving-patterns/Web-single-pattern/design_kr.md b/Serving-patterns/Web-single-pattern/design_kr.md