논문이나 환경셜정이 되어있는 프로젝트에서는 기능 설계 및 성능 측정 시 최고, 평균, 최저의 성능을 위주로 구분한다. 하지만 이는 환경이 이미 제대로 돌아갈 때는 상정한 것이기에 실제 production 레벨에서는 문제가 될 수 있다. 고로 항상 fault를 생각해야한다.
예를 들어 api를 사용한다고 가정해보자. api인자에 원하는 날짜만큼의 데이터를 입력하고 받아와 테스트하는데, 해당 api역시 오류가 날 수 있다. 사람의 실수, 화재, 데이터 누락, 점검, 연휴 등 다양한 edge case가 존재한다. 이를 해결하기 위해서 recovery로직이 필요할 수 있지만 제일 좋은 것은 해당 fault가 발생했을 때 수동으로 데이터를 수정하는 것 보다 기다리면 해결되는 방법이 제일 좋다.
어떻게 할 수 있을까? api로 데이터를 가져올 때 기간의 window를 딱 맞게 설정하는 것이 이상적으로는 효율적이지만, 일부러 기간 window를 일정부분 겹치게 설정하고 중복 데이터를 거르는 방식을 사용하는 것이다. 그렇다면 웬만한 fault를 해결할 수 있으며, 나아가 장기간 문제가 될 때에도 window 상수를 조절하여 쉽게 문제를 해결할 수 있다.
이제 4학년!!!