배경
지난 글에서 로컬 환경에서 플라스크를 사용하여 파이토치로 된 모델 파일을 동작시켜 보았다. 이번 글에선 EC2 위에서 플라스크를 동작시켜 보겠다. 개발하던 중 마주했던 문제들도 다룰 예정이다.
개발
1. EC2 인스턴스 생성 및 기본 세팅
2. git 또는 scp(ssh 프로토콜 기반 서버간 파일 전송 명령어)를 사용하여 파일 업로드
github는 100 MiB보다 큰 파일을 올릴 수 없기 때문에, 모델 파일의 경우는 scp 명령어를 사용해 EC2에 전송했다.모델 파일의 크기가 347.5 MiB였다,,,
$ scp {파일 경로} {호스트 이름}:/home/ubuntu(scp 파일 전송은 위와 같이 하면 된다. ~/.ssh/config (Mac, Linux 기준) 파일에 EC2 호스트를 저장해두면 호스트 이름으로 편하게 전송할 수 있다.)
3. 가상환경 세팅 및 라이브러리 설치
가상환경의 경우 로컬에서 했던 것과 동일하게 진행하였고
라이브러리 설치는 로컬에서 requirements.txt에 사용한 라이브러리를 저장했기 때문에
$ pip install -r requirements.txt
명령어로 설치한다.
4. app.py 파일 실행
⛔️ERROR⛔️
[403] rate limit exceeded 에러
https://github.com/pytorch/vision/issues/4156
env.
EC2 Linux Ubuntu 20.04
torch 1.13.0
torchvision 0.14.0
EC2 인스턴스를 생성할 때 Linux Ubuntu 20.04 버전을 사용했는데 app.py 파일을 실행하니 "rate limit exceeded" 에러가 발생했다. 위의 torch github 채널에도 올라와 있는 이슈로 Ubuntu 20.04와 torch의 여러 버전이 connection 에러를 발생시키는 것 같다. 모델을 로딩하는 과정에서 생기는 오류인 것으로 보이는데 이슈에 댓글을 남긴 사람들의 로컬 컴퓨터 환경이 인스턴스의 우분투 버전과 동일하게 20.04 버전이었다. 나는 torch.hub를 사용하지 않았기 때문에 hub가 원인은 아니었고 우분투 버전을 22.04로 변경하니 문제 없이 동작하였다.
5. 도메인 연결 및 테스트
선호하는 도메인 사이트에서 도메인을 연결하고 postman으로 테스트를 진행하였다.
⛔️PROBLEM⛔️
모델을 업데이트 할 일이 있었는데, 업데이트 후 테스트를 해보던 중 점점 결과를 받아오는 속도가 느려지는 문제가 있었다. 기존에 1초 안으로 결과를 냈지만 8초, 10초 이상 소요되었다. 프로젝트 성격상 적어도 2초 안으로는 응답을 줘야했다... 🥲 프론트와 스프링 모두와 연결 시킨 이후라서 통합 테스트를 진행하던 중 발견된 문제라서 어디가 문제일지 하나씩 뜯어보았다. 클라이언트 --> 스프링 --> 플라스크, 이 경로로 이미지가 전송되는데 서버간 통신이나 api 호출에 있어서는 부하가 올 수 있을만 한 것이 없었고 실제로 테스트 해보니 이미지 전송 및 결과 반환에는 300ms 아래로 시간이 소요되었다. 따라서 EC2 환경에서 문제가 있다고 생각하였다.
리눅스 명령어 htop을 사용하여 플라스크를 실행할 때 시스템 사용량을 살펴보았다. EC2 프리티어 t2.micro를 사용하고 있었기 때문에 제공되는 메모리는 1GiB였다.
메모리를 805MiB를 사용하고 있으며 이전에 할당했던 스왑 메모리도 사용되고 있음을 확인할 수 있다.
스왑 파일을 이용하여 RAM 메모리가 부족할 때 스왑 메모리로 해결할 수 있지만 스왑 파일은 HDD에 위치하기 때문에 RAM 보다 속도가 훨씬 느릴 수밖에 없다. 크기가 큰 모델을 빠르게 동작시켜야 할 때는 스왑 메모리가 해결책이 될 수 없었다...
클라이언트에서 이미지를 전달 받아서 집중 여부를 확인하는 과정이 2초 안에 수행되어야 했기 때문에 RAM의 크기를 늘리는 방법을 사용했다. 물론 모델을 경량화 하거나 그 외의 방법이 있을 수도 있겠지만 프로젝트 지원금이 있었기 때문에 t2.medium으로 인스턴스를 변경하여 4GiB의 메모리를 사용하였다.
모델은 동일했고 EC2 인스턴스만 변경하였다. 플라스크 실행 기준 메모리를 1.69 GiB 사용하고 있다. t2 micro였을 때는 RAM에서 메모리가 부족하여 swap 메모리와 같은 디스크에서 동작시켜왔음을 알 수 있다.
메모리 크기를 늘려 성능 개선을 확인하였다.
정리
EC2 환경에서 플라스크를 동작시켜보았다.
모델을 동작시킬 때는 많은 리소스를 사용하기 때문에 주의해야겠다.
'백엔드 > model serving' 카테고리의 다른 글
| PyTorch 모델 서빙 (2) - Flask 모델 서빙 (3) | 2024.01.02 |
|---|---|
| PyTorch 모델 서빙 (1) - 여러 방법들 (1) | 2024.01.02 |
