- 프로젝트명: 분리위키 모델 서빙 API 서버 구축
- 프로젝트 기간: 2024.03 ~ 2024.11
- 목적 및 배경:
- 분리배출 가이드 제공 서비스인 "분리위키"를 지원하기 위해,
- 재활용 분리수거 이미지 및 문장을 분류하는 모델을 안정적으로 서빙하는 API 서버를 구축
- S3에 저장된 최신 모델을 자동 로드하여 예측 성능을 지속적으로 유지하는 것을 목표로 함
| 분류 | 기술 목록 |
|---|---|
| 개발 언어 및 환경 | Python 3.10, Docker, Docker Compose |
| 웹 프레임워크 | FastAPI |
| 모델 서빙 및 학습 | Transformers (KcBERT), Ultralytics YOLOv8, TensorBoard |
| 클라우드 서비스 | AWS S3 (모델 저장 및 로딩) |
| 로깅 및 기타 도구 | loguru, boto3 |
- FastAPI의
lifespan이벤트를 활용하여 서버 시작 시 모델 로드 로직 실행 - S3에서
latest_model.yaml을 다운로드하여 YOLO, KcBERT 모델의 경로 확인 후.pt모델 파일 자동 다운로드 - 다운로드한 모델은 각각
YoloModel,KcBertModel클래스를 통해 메모리에 로딩 latest_model.yaml이 없거나 S3 접근이 실패할 경우를 대비하여 로컬 기본 모델 경로도 지정
| API Endpoint | Method | 설명 |
|---|---|---|
/kcbert/prediction |
POST | 입력된 문장에 대한 혐오 표현 분류 결과 반환 |
/yolo/prediction |
POST | 업로드된 이미지 내 재활용품 객체 탐지 및 분류 결과 반환 |
- 서빙 성능 저하 문제
KoBERT와 YOLOv8 모델을 프리티어 EC2 환경에서 서빙하는 과정에서, 응답 시간이 지나치게 지연되는 문제가 발생함. 시연 환경에서는ngrok을 사용하여 로컬 서버를 외부에 노출하는 방식으로 대체하였지만 바람직한 방법이 아님
-
모델 로딩 구조 설계의 중요성 인지
최초에는 서버 기동 시점에만 S3에서 모델을 불러오는 구조로 설계하였기 때문에,
새로운 모델이 학습되더라도 서버를 재기동하지 않으면 반영되지 않는 문제가 발생함.
해당 경험을 통해, 서버 재기동 없이도 최신 모델을 반영하려면 외부에서 직접 API를 호출하는 방식이 더욱 유연하고 효과적이라는 점을 깨달음. -
시각화 및 로그 관리 구조의 개선 필요성 체감
TensorBoard와 로그 디렉터리 구조를 구성할 당시, 사전 지식 없이 주먹구구식으로 기술을 도입해 디렉터리나 로그 네이밍이 일관되지 않았고, 그로 인해 실험 결과 추적이 어려웠음.
이는 초기 설계에 대한 이해 부족과 촉박한 데드라인의 영향이 컸으며,
이후에는 기술을 충분히 학습하고 구조적으로 설계한 후 도입하는 것이 중요하다는 점을 깊이 인식하게 됨.