LOCOMOTE THE WORLD
Published on

MINILAB | HELLO SKATING 1차 개발 후기

HELLO SKATING 사이트 개발 일지 - 1차 오픈

피겨스케이팅, 한 층 더 즐겁게 즐기기

Background

지난 2월, 2022 베이징 올림픽에서 특정 국가 제외 상당히 박한 점수로 석연치 않은 판정으로 Motion estimation 모델로 prediction을 한 적이 있었다. 상당히 많은 국내 팬분들이 웹사이트를 만드는 것을 희망하셨고, 현재 석사 과정으로 바쁜 시간을 쪼개서 만들게 되었다.

사실 대학원 입학하기 전에 별다른 취직이 안되면 피겨인들을 위한 앱 개발로 창업을 희망하였으나, 인생은 어찌될지 모르기에 대학원에 입성하게 되었다(?). 다른 스포츠에 비해 일정 관련해서 정리된것도 없고 KSU사이트에 들어가면 그렇게 난장판이 없다.. 하ㅏㅎ

여하튼 대회 일정에 관해서는 2차 오픈 때 애기하고 1차 오픈 때는 2월에 jupyter notebook으로 간단하게 만들었던 기능들을 서비스화하는 것을 목표로 개발을 시작하게 되었다.

사실 요즘 너무.. 번아웃 왔고 내 분야에 대해 현타가 조금 와서 좀 더 개발자스럽게 집중할 수 있는 무언가를 하게 되었다.

Preliminary

원래는 귀찮아서 그냥 jupyter notebook 그대로 웹 어플리케이션 만들어주는 걸로 하려다가 뭔가.. 나만의 사이트를 운영하고 싶어서 노선을 바꿨다.

사실 나는 작년 초만해도 html을 1도 모르는 인간이었는데 어쩌다보니 데이터 크롤링하면서 대충 문법이 익혀지고 2021년 모종의 사건들로 react를 2달 안에 능숙하게 쓰게 되었다. 비슷하게 현재 1년 질질 끄는 사이드 프로젝트도 react native를 써서 그런지 react 프레임워크 쓰는데 크게 문제는 없어서 React framework를 쓰게 되었다. 문제는 백엔드인데.. 백엔드는 잘모르겠지만 대충 크게 3가지로 나눌 수 있을 것 같다.

  • 본인 워크스테이션을 구비해서 따로 자가 서버를 둔다
  • AWS같은 클라우드 서버에 백엔드 구축하고 서버리스 형태로 구현한다.
  • 간단하게 구현할 수 있음 Flask로 동적 사이트 연동이 가능하게 한다..?(사실 Flask가 쉬워서 쓰려다가서 어떻게 연결하지 싶어서 철회)

물론 나는 워크스테이션 살 돈이 없는 게 당연하고.. 1인 기업을 운영하지 않는 이상 필요 없을 것 같아서 프리티어로 AWS 서버리스로 해보자라고 해서 선택했다.

사실 tensorflow 같이 무거운 라이브러리는 써보지 않아서 잘 모르겠는데, 일단은 그나마 조금이나마 써본 Aws를 선택하게 되었다.

그래서 여튼.. 쓰게 된 주요 기능들은:

  • Front-end: React framework v6
  • Back-end: Python3.8, Docker, AWS as serverless - lambda, s3,

Front End

확실히 프론트엔드는 꾸준히 공부해야하는 분야가 맞는 것 같다. 분명 주소 라우터 잘 설정했는데.. 알고보니 내가 자주 쓰던 2년전 방식은 더 이상 쓰지 않는 것이었고(HashRouter) 요즘 동적 사이트를 위해 BrowserRouter와 같이 사용해서 새로운걸 익히는 계기가 된 것 같다. 라고는 하지만 나는 프론트엔드직으로 갈 생각은 없다..ㅋㅋ

그것 빼고는 생각보다 금방 만들었다. 필요한 것만 넣어 서 한 2일 안에 바짝 만들었다.

원래는 협업 의사가 있었던 UI 디자이너 분에게 디자인 맡기려고 했는데, 성질 급해서 내멋대로 만들었다.

Back End

학부시절 네트워크나 데이터베이스 과목을 듣지 않기도 했고 오픈소스 관련 과목을 소홀하게 들어서 관련 지식이 거의 없다.. ㅋㅋㅋ 내가 아는 한 유저들이 요청하면 서버에서 그게 데이터베이스 건 gateway를 통해서 데이터를 주는 뭐 그런 거로 알고 있다. 아님말구

백엔드는 크게 container image를 통해서 lambda function을 구축하거나 serverless 를 통해서 function을 만드는 두 가지 방법을 익혔다. 다만 container image는 docker 사전 지식과 코드를 aws 상에서는 안 보인다는 점이 단점 아닌 단점이지만, serverless에 비해서는 오류가 덜 ? 나는 편이라 container image를 사용하였다. 이제 이 함수를 외부를 어떻게 빼냐가 문제인데..

여하튼 상대적으로 프론트엔드보다 삽질이 많아서 삽질 연대기를 남겨보았다.

삽질 연대기

  1. AWS lambda와 layer

aws 내장 파이썬 라이브러리 외 외부 라이브러리를 사용하고 싶으면 별도로 layer에 라이브러리를 올려야 한다. 수작업으로 layer 올리는게 생각보다 번거롭기도 하고 메모리 제한으로 ARN layer이란걸 도움받았다. 단점은.. 최신 라이브러리가 아닐 수 있다는 것..?? 뭐 여하튼 유용하게 쓰는 중..

수작업으로 올리는 방법은 해당 링크 참고.

  1. 무거운 라이브러리와 layer

위에서 서술했듯 lambda는 250MB의 메모리 제한을 가지고 있다. /tmp라고 임시 저장하는 곳을따로 파서 500MB까지 쓸 수는 있으나 (대충 아래 lambda function에 추가하면 된다.)

sys.path.append("/tmp")

BUT.. tensorflow 2.0와 같이 쌉 무거운 라이브러리는 lambda layer에 올리는 것은 불가능하다.. 모델을 훈련하는 입장이라면 sagemaker라고 해서 따로 구독료 내고 사용하는 것이 맞지만 나는 prediction 기능만 사용할 것이라서 나와같은 사람이 없을까 싶어서 하루 종일 검색했다 ㅠㅠ

찾아본 바로는 npm을 이용한 serverless와 docker를 이용하여 AWS에 올리는 것 같은데 serverless에는 template으로 aws-python-docker로 생성이 가능한 것 같다.

윈도우에서는 docker 관련 에러가 해결이 안되어서 우분투 환경으로 옮겼다. tflite이 그렇게나 문제여서 참.. 고생도 많이 했다. 결론은 tensorflow는 무거워서 lite를 쓰는 걸 권하는 것 같고, 나야 prediction만 사용해서 일단은 올려보기로 한다.

이런식으로 테스트를 거친다음 도커를 이용해서 컨테이지 이미지를 토대로 lambda 함수를 만들었다.

정리하자면 간단하게 이 리포 참고해서 만들어보고 ML bookcamp 요 정보와 추합해서 container image를 구축하고 돌려보았다.. 결국 Dockerfile 맞게 설정하는데 거의 삽질한 것 같다

FROM public.ecr.aws/lambda/python:3.8
WORKDIR ${LAMBDA_TASK_ROOT}
COPY app.py app.py
COPY requirements.txt requirements.txt
RUN python3.8 -m pip install --upgrade pip
RUN python3.8 -m pip install -r requirements.txt
CMD ["app.handler"]

아 근데 내가 사용하는 모델은 tflite가 안된다고 해서 tensorflow로 올렸는데 해당 도커 파일로 잘 올렸다. 도커로 이용하는 방법 외에는 없는 듯 싶다.

sudo $(aws ecr get-login --no-include-email)

  1. API Gateway

안타깝게도 내 기능은 1분 30초에서 내지는 2분의 처리 시간이 필요한데, API gateway는 기다려주지 않아.. ㅠㅠ 30초가 최대이고 2022년 현재까지 29초가 고정인 것 같다.

그래서 다른 방법이 없나 찾아본 결과 뭔가 찾긴했는데.. 과금 폭탄이 될 것 같아 예의주시하고 있다..

인터넷에 찾아본 결과 SQS 를 만들어서 대기 큐를 만들어 호출하거나 로드 밸런서 (ALB, ELB)를 만들면 제한없이 호출할 수 있다고는 하는데, single function url로도 호출이 가능하다고 한다.

물론 sqs나 gateway, load balencer 이런 것들은 별도로 비용이 호출된다고 하니 주의할 것..

여하튼 single function url 로 호출하면서 invoke 형식도 다르다고 해서 그에 맞게끔 container image를 다시 만들어서 업데이트했다. base64가 꼬이는게 참 고역이었는데 5일내내 고생한 보람이 있는 것 같다 ㅎㅎ

  1. Frontend-Backend 뿌리기

처음 파이썬으로 request test 한것과 javascript로 request test하는 와중 부르는 형식이 좀 달라서 좀 고생했다. 고생을 거의 Backend에서 하는 구만..

  • python 은 event["body"]로 데이터를 받는다고 했을 때 string으로 받아버리고 아주 이상한 형태로 받게 된다. data 파라미터로 넘기면서 이상해진 것 같다.
  • javascript로 넘겨받을 때는 json으로 잘 넘겨받는 걸 확인

function url로 단순하게 불렀다. 왜냐하면.. 시간 감당 못하고 api gateway cors 어쩌구랑 타임아웃 겪기 싫어서 ㅇㅇ. 보안 문제가 걱정되는데, 차차 beta 테스트 하면서 보완해야겠다.

  1. Sports DB 추가

무료 버전의 Sportds DB api를 이용하여 국제 피겨스케이팅 대회 캘린더를 만들어보았다. 다만 호출할 때마다 가격이 책정이 되어서 아예 local에서 호출해서 DB를 json화 시켜서 올리는 좀.. 구닥다리 방식을 이용하였다. 결국 내쪽에서 업데이트 하지 않으면 소용없어서 비효율적인 방법이다.

  1. 또 하나의 난관, lambda 자체론 이미지 넣기엔 부족하다. 결국 API Gateway..

lambda로 이미지를 base64를 호환해서 보낼 때 502 메세지가 계속해서 뜨게 되는데 이는 lambda를 통해서 바로 호출하게 될 경우, 100kb 내 이미지만 된다는 것이다.. 띠용.. 결국에는 gif 이미지는 생략해버리고 결과만이라도 출력하길 바랬음..

그런데 하다보니 API gateway는 timeout 제한으로 나 같은 경우 timeout 때문에 api gateway를 하지 않는다는게 생각이 났다..

대부분 503 error로 Service unavailable은 이에 해당하므로 다시 lambda에서 다시 호출받고 입력시 100kb 미만으로 줄이는 방법으로 택했다.

Wrap up & Conclusion

결론적으로 tensorflow 1.4와 파이썬 3.8을 성공적으로 AWS에 올려 모델로 하여금 estimation하는데 성공하였다. 하지만, cost면에서 매우 비효율적이라고 느꼈고, 다른 대안을 찾아보는 것이 좋을 것 같다는 결론을 내렸다. 또한 잘못된 이미지 입력과 같은 예외상황을 고려하지 않고 만들다보니, aws에 문제가 생기지 않을까라는 걱정도 하게 되었다. 현재 Beta로 내놓은 사이트는 10월 이후에는 폐쇄하였고, 사람마다 착지 지점이 다른 이미지로 이용한 estimation에는 한계가 있음을 고려하여 새로운 AI 개발에 포커싱을 맞추었다. Beta 버전에서 이미지를 입력으로 이용한 이유는 현재 monocular video를 이용한 estimation이 frame rate가 따라주지 않아서 였는데, 최근 연구로 속도가 빠른 영상을 캡쳐할 수 있는 연구가 나와서 아마.. 영상을 이용한 judge ai과 착지 지점을 supervised learning으로 훈련하면 어느 정도 성과가 나오지 않을까 예측한다.. 여튼 프로젝트를 통해 배운 것과 결론은 아래와 같다!

  • tensorflow를 AWS에 올려서 model estimation을 할 수 있음!
  • React를 이용하여 모바일 웹사이트를 간단하게 만들 수 있게 되었다!
  • Judge AI에서 이미지를 입력받는 것은 아무래도 비효율적이라고 생각하여 영상을 입력받는 방법으로 다시 개발을 하는 것으로 결정하였다. (그게 언제일지 모르겠지만..)
Authors
Discuss on Thread • View on GitHub