24.03.06
한꺼번에 전체적인 개발 기획에 관한 이야기를 들어서 머릿속에 제대로 정리가 되지 않았기에, 다시 한 번 정리하면서 생각하자.
내일부턴 아이패드가 필요할 것 같다.. 도식화 시급..
우리 서비스가 받는 요청은 종류가 나뉘니 이것을 고려해주세요.
user task의 경우에는 말 그대로 유저가 trigger가 되어 발생하는 이벤트로, 유저들이 우리 서비스를 이용하기 위하여 웹사이트에 접속. 거기에서 필요한 기능을 이용하기 위해 특정 api를 호출하는 버튼을 눌렀을 때 서버에 전달되는 요청이다.
User Task의 특징은 task 자체의 크기가 크지 않을 가능성이 높다는 점이다. (절대 간과하면 안된다. 유저도 한 번의 많은 요청을 보낼 수 있다. 하지만 높은 확률로 한 번에 보낼 수 있는 요청을 제한을 하지 않을까.) 그리고 언제 요청이 발생할 지 예측 할 수 없다.
batch task의 경우에는 유저들이 서비스를 웹에서 이용하는 것이 아닌 우리에게 직접적으로 offer가 들어와서 처리해주는 task이다.
Batch Task의 특징은 task 자체가 클 가능성이 높다. (나중에 아마 웹에 리소스를 많이 잡아 먹어야 하는 task의 경우에는 Batch job으로 따로 연락을 하라고 하는 등의 공지와 연락수단을 주지않을까. 그래야 새로운 사람들이 계속 서비스를 접하더라도 매번 우리에게 큰 작업에 대해서는 어떻게 처리해야하는 지 묻지 않을 것이니) 그리고 이 task의 경우에는 개발자가 직접 실행하는 task 이기에 언제 시작할지 알 수 있고, 시작 순간과 machine등 환경에 대한 설정을 우리가 직접 할 수 있다.
서비스는 User Task의 우선도가 높다고 판단하고 scheduling을 진행할 예정. 나의 생각은 과장을 조금 보태면 원래 3시간 걸리던 연산이 3시간 5분이 될 때 느끼는 불만감보다 키보드 클릭처럼 누르자마자 바로 반응이 와야하는 작업이 5초, 10초 이상걸릴 때 서비스에 대한 화가 더 많이 날 것 같다라는 측면에서, 그리고 Batch task로 우리에게 넘겨주는 작업의 경우에는 우리가 얼마나 걸릴거다, 언제 시작하고 지금 이런 상황이다, 이런식으로 소통하기가 더 간편하지만 웹에서 직접 서버에 요청을 보내야 하는 경우에는 사실상 개발자와 소통하는 것이 아닌 개발자가 만들어둔 인터페이스를 이용해서 굳이 개발자와 소통할 필요 없게 해둔 구조이기에 그에 따라 필요없는 소통을 없애는 방향으로 서비스를 만드는 것이 옳다고 생각한다. 이를 위해서는 유저가 보낸 요청은 빠르게 처리하는 게 좋다고 생각하기에 User Task의 우선도가 높다는 것을 인정.
우선은 STT만 고려해서 Flow를 생각하는데, 추후에는 이를 비단 STT에만 적용하는 것이 아닌 영상 분석에 관련한 서비스와 모두 연결할 것을 자세하게 고려해주세요.
<aside> 💡 내가 주요 포인트로 생각하고 있는 부분
모든 서버는 NAS를 mnt해놓았을 것이고, 해당 NAS에 영상이 저장되며 분석한 내용도 여기에 저장될 것이다. 그럼 영상은 한 번만 NAS에 전송해 저장을 해두면 된다.“Task”의 시작점은 여기부터이다.
“영상을 업로드 했으니 분석을 시작해주세요”