Retrospect and Prospect

🙏
Retrospect and Prospect
Limits of Facebook Prophet
Specific purpose and applications
DB Active Session과 특정 상품의 판매 추이를 관련시켜 예측하는 데 사용하는 것은 가능한가?
DB Active Session과 Plain 상품 판매 추이만 조합하여 예측 모델을 만들어 사용하는 것은 의미가 있는 것일까?
PoC
그렇다면 우선 DB Active Session 만 갖고 예측을 해 봤을때 어느 정도 맞는지를 살펴보자
WebDB Active User Session Count 수집 및 예측
중위값을 바탕으로 공휴일 데이터 입력하여 적용한 결과
매일 02:03~02:06 사이 배치작업에 데이터는 그래프에서 안보이게 처리
Redis 정보 수집 및 예측 데이터 생성 - Data 기반 장애 이상징후 감지 PoC
Data 저장 계획: Prometheus → InfluxDB
Data 추출
Data 확인
Local 환경에 InfluxDB 실행
Local 환경에 Chronograf 실행
Data 주입
Crontab 설정
Data 적용 예정 범위
알림 설정 작용 예정 범위
Grafana 적용
Alternatives
Limits of Facebook Prophet
Specific purpose and applications
•
Time series data with patterns and seasonality
•
Strong seasonality patterns: Data with similar patterns depends on time → Login patterns, employee entry, commute patterns
•
Naver Online Payment Reference - https://d2.naver.com/helloworld/0065813
과거의 장기적인 추세를 보고 이후의 대략적인 추세를 확인하는 용도로 사용할 때 Prophet 라이브러리는 훌륭한 결과물을 보여 준다. 특히 갑작스런 데이터의 변동이 없는 상황에서는 실제 데이터와 아주 근접한 예측 결과를 보여 준다.하지만 명절이나 기타 상황에 의해 거래량이 한시적으로 하락하거나 증가하는 경우, 사업 확대 등으로 인해 전반적인 거래량 자체가 변동되는 경우 등에서는 적절한 예측 결과를 보여 주지 못하는 문제가 있다. 과거의 추세를 따라 주기 함수를 만들고 이후의 거래를 예측하는 모델의 한계 때문이다.
DB Active Session과 특정 상품의 판매 추이를 관련시켜 예측하는 데 사용하는 것은 가능한가?
고려되어야 할 Factor가 너무 많다! → 데이터 과학자 및 AI 의 영역
•
요일: 월요일에 잘 팔리던 제품이 일요일에도 잘 팔리나?
•
시간: 저녁 8시에 잘 팔리던 제품이 오전 8시에도 잘 팔리나?
•
휴일: 평일에 잘 팔리던 제품이 휴일에도 잘 팔리나?
•
외부 요인: 날씨, 계절, 사회적 이슈(마스크)에 따라 잘 팔리고 덜 팔리는데 어떻게 가중치를 둘 것 인가?
DB Active Session과 Plain 상품 판매 추이만 조합하여 예측 모델을 만들어 사용하는 것은 의미가 있는 것일까?
고려되는 Factor (사용가능)
•
요일
•
시간
•
휴일
Active Session 카운트와 주문 수량을 어떻게 조합해서 예측 데이터를 생성할 지 생각해보자 (Prophet 으로 가능한가?)
PoC
그렇다면 우선 DB Active Session 만 갖고 예측을 해 봤을때 어느 정도 맞는지를 살펴보자
•
DB Active Session 카운트수만으로 예측 데이터를 대입해보고 얼추 맞는지 PoC 해보자 
•
DB Active 시계열 데이터를 InfluxDB 에 수집한다
•
왜? 그래도 Static 한 알림 한계치를 설정해서 하는 것 보다 좀 더 Flexible 한 알림 수치를 제시해 줄 수 도 있다.
WebDB Active User Session Count 수집 및 예측
중위값을 바탕으로 공휴일 데이터 입력하여 적용한 결과
•
기존 세션수가 낮은 경우 알림을 받는 설정은 없다고 함
•
세션수를 120정도가 넘는 경우 알림을 받고 있다고 함
•
범위를 벗어나는 케이스를 살펴보자
◦
매일 새벽 2시 배치 작업시 카운트 튐
▪
Sub-Daily 옵션을 활용해서 Fitting 해보자 
▪
On/Off Seasonality 를 활용해서 Fitting 해보자
매일 02:03~02:06 사이 배치작업에 데이터는 그래프에서 안보이게 처리
•
쿼리에 조건을 추가한 이유: 예외 시간을 갖고 있는 데이터를 포함한 시리즈에 미리 넣고 Alert 에서 조건을 거는 장식은 나중에 사용 예정 (볼 수가 없으며, 필요시 수정해야하므로)
•
추후에는 여러 작업들이 있는 시간의 경우 별도 시리즈로 담고, 해당 Alert 조건에 해당 시간에는 알림 보내지 않도록 설정 하면 가능
•
애초에 배치 작업시 사용되는 세션은 제외하고 데이터를 담을 수 있는지 확인 필요 → 작업중에 잘못되는 경우도 봐야하므로 데이터 보유해야함
•
Grafana 에서는 특정 시간대에 알림을 안보내는 방식은 요청이 많았지만 아직 개발되지 않음
•
다른 방법으로, 해당 시간/분을 같은 테이블에 입력하도록 하여, query 조건에 입력함
SELECT max("qty") FROM "active_session_webdb" WHERE $timeFilter and (hour != 2 and minute < 6  and minute > 3) GROUP BY time($__interval) fill(linear)
SQL
복사
Redis 정보 수집 및 예측 데이터 생성 - Data 기반 장애 이상징후 감지 PoC
•
현재: Prometheus 로 수집되고 있는 자료를 Grafana에 연동하여 모니터링 진행중
•
Redis의 Key 카운트가 증가만 하고 줄어들지 않는 경우 장애 발생 할 수 있음 (메모리 소진)
•
Key 카운트를 보면 패턴이 보이기는 하여 적용 가능성이 보임
•
같은 Category 에서는 Load Balancing 이 되어 있는지 거의 일치하는 패턴을 보임 (작업시점을 제외하면 다른 패턴을 보이는 경우 알림을 적용 할 수 있을지도...)
•
Redis 를 바라보는 WAS의 댓수를 얼추 비슷하게 나눠놓고 사용하는 키여서 같은 카테고리의 수가 달라도 이상할 것이 없음
•
Key Count 는 제외: MC 개인화의 경우 0이여도 이상한 것이 아님, 그냥 DB 용도로 사용하여 제외
Data 저장 계획: Prometheus → InfluxDB
•
Redis 정보는 Prometheus 로 저장되어 있음
•
Prometheus 에 예측 데이터를 입히는 작업은 추천되지 않음
◦
예전 데이터, 미래 데이터를 입력하면 잘 동작하지 않는다고 들음
Data 추출
•
Prometheus RestAPI 를 사용하여 데이터를 추출
•
Python Pandas 를 통해 DataFrame 을 Merge 하여 한개의 InfluxDB에 주입
•
InfluxDB 주입시 Facebook Prophet 예측 데이터도 함께 추가 → Prometheus 와 InfluxDB 싱크 프로세스를 소량으로 자주하고, 별도 프로세스로 예측 데이터 생성 배치가 필요함
•
Prometheus 에서 추출시 시리즈당 11,000 포인트 이상 추출시 400 에러 발생 → 범위를 좁게 또는 그룹핑 해서 해야함
Data 확인
Local 환경에 InfluxDB 실행
docker run -p 8086:8086 -v influxdb:/var/lib/influxdb influxdb
Local 환경에 Chronograf 실행
docker run -it --rm -p 18888:8888 chronograf --influxdb-url=http://*.*.*.*:8086
Data 주입
Crontab 설정
•
Prometheus → InfluxDB 로 싱크는 1분 주기로 마지막 2분 간의 데이터를 주입
•
예측 데이터 생성은 30일의 데이터를 기반으로 현재 시간 + 3시간 예측 데이터를 시간단위로 10분에 시작하여 3세트(공통, 매장, 공통)의 예측 데이터를 주입 (데스크탑에서 실행시 28분정도 소요 됨)
* * * * * /home/phil/Documents/prophet/redisSync.sh >> /home/phil/Documents/prophet/log_redisSync.log 2>&1
30 * * * * /home/phil/Documents/prophet/forecastRedisKeyCount.sh >> /home/phil/Documents/prophet/log_redisForecast.log 2>&1
Bash
복사
Data 적용 예정 범위
•
Key Count: 완료
•
Client
알림 설정 작용 예정 범위
•
상하위 예측 값 벗어나는 것에 대해 알림 (경고)
•
세트로 구성된 서비스에 대해서는 두 그래프의 차이가 특정 값이상 벌어지는 경우 알림 (경고)
◦
예) 공통 1 vs 공통 2 값이 갑자기 많이 차이나는 경우 (예측범위에서 벗어나는 것으로도 커버가 될 듯)
Grafana 적용
Alternatives
Comming soon