개요
최근 저는 AI 서버를 Google Cloud Run에 배포하며 다양한 문제를 해결해 나가고 있습니다. 이번 포스팅에서는 서버 배포 과정과 현재 해결해야 할 문제, 앞으로의 계획을 공유하려고 합니다.
서버 구성과 동작 방식
- 서버 아키텍처
- AI 서버는 Flask와 Flask-SocketIO를 기반으로 작성되었습니다.
- YOLOv5, PaddleOCR, ONNX Runtime 등의 모델을 사용하며, 모델 관리는 싱글톤 패턴을 활용한 ModelManager 클래스에서 처리합니다.
- Google Cloud Run 환경에서 동적 인스턴스 스케일링으로 부하를 처리합니다.
- 현재 동작 흐름
- 클라이언트가 서버에 접속하면, 먼저 헬스체크와 SID(Session ID)를 통해 초기 연결을 확인합니다.
- 이후, 클라이언트가 이미지를 업로드하면 서버에서 YOLO 모델로 검출한 결과를 바탕으로 OCR과 GPT 생성 작업을 수행합니다.
문제점과 개선 방안
1. Cold Start 문제
- 문제점: Google Cloud Run은 Cold Start 시 모델 로드에 시간이 오래 걸립니다.
- 해결 방안:
- UI를 개선하여 Cold Start 동안의 지연을 사용자 경험에 녹여냅니다.
- 앱 진입점에서 헬스체크 및 SID 요청을 기다리지 않고, 부트 스크린에서 바로 넘어가는 방식으로 수정합니다.
- 사용자 요청 이전에 모델 로드를 완료하도록 백그라운드에서 초기화 작업을 수행합니다.
2. Custom Splash Screen 반복
- Cold Start 지연을 줄이기 위해, Custom Splash Screen에서 2~3번 로딩 애니메이션을 반복하여 사용자가 지연을 인식하지 못하도록 설계합니다.
3. 모델 로드 전 요청 처리
- 문제점: 모델 로드가 완료되기 전에 사용자가 요청을 보낼 경우, 처리 실패가 발생할 가능성이 있습니다.
- 해결 방안:
- API 요청 시, 모델 초기화 여부를 확인하고 초기화 중일 경우 대기 상태를 반환하도록 서버 로직 수정.
- 클라이언트와의 웹소켓 연결 우선 처리: SID 및 초기화 관련 메시지만 우선 수신하며, 모델 로드는 비동기로 수행합니다.
4. SID 전달 속도 문제
- 현재는 클라이언트가 HTTP 요청마다 SID를 보내도록 설계되어 있습니다. 하지만 Cold Start 시 SID를 빠르게 받지 못하면, 초기 웹소켓 연결이 실패할 수 있습니다.
- 해결 방안:
- 웹소켓 연결 시, 클라이언트와의 세션 관리 최적화를 통해 SID를 즉시 전달.
현재 진행 상황
- Google Cloud Run에 서버 배포 완료
- 서버는 정상적으로 동작하며, 트래픽에 따라 인스턴스가 자동으로 스케일링됩니다.
- Cold Start 문제가 있지만, 서비스에는 큰 영향을 미치지 않는 수준입니다.
- 클라이언트-서버 동작 흐름 개선 작업
- 헬스체크와 SID 초기화 과정을 단순화하고, UI 개선을 통해 사용자 경험을 극대화하는 작업이 진행 중입니다.
내일의 작업 계획
- UI 개선
- 헬스체크 및 SID 수신 대기 과정을 생략하고, Custom Splash Screen으로 Cold Start 지연을 숨기도록 수정.
- 웹소켓 연결 및 모델 로드 개선
- Cold Start 시에도 웹소켓 연결과 SID 초기화를 우선 처리할 수 있도록 서버 로직 최적화.
- 모델 로드 중 요청 처리 테스트
- 클라이언트가 요청을 보낼 때, 모델 로드 여부에 따라 적절한 응답을 반환하는지 테스트.
- SID 전달 최적화
- SID 전달 속도를 높이고, 초기 연결 실패를 방지하기 위한 설계 재검토.
우려 사항
- Cold Start 시 유저 경험
- 웹소켓 연결이 지연되면 사용자가 부정적인 경험을 할 수 있으므로, 이 부분에 대한 UI와 서버 성능 개선이 중요합니다.
- 트래픽 증가에 따른 비용
- 인스턴스가 증가하며 비용이 크게 늘어날 수 있어, 배포 환경 최적화와 함께 모니터링을 강화해야 합니다.
결론
Google Cloud Run을 활용한 AI 서버 배포는 처음 경험하는 도전이지만, 점진적으로 문제를 해결해가며 안정적인 서비스를 구축하고 있습니다. 내일은 UI와 서버 최적화를 통해 한층 더 발전된 서비스를 만들어나갈 계획입니다.
마지막 한마디
배포 과정은 예상보다 훨씬 많은 문제를 포함하고 있지만, 이를 해결하는 과정이 흥미롭고 배울 점이 많습니다. 다음 글에서는 UI 작업과 최적화 작업의 결과를 공유하겠습니다.
'플러팅 AI > Flask Server' 카테고리의 다른 글
| 이미지 업로드 방식을 HTTP에서 WebSocket으로 변경한 이유 (0) | 2024.12.13 |
|---|---|
| Google Cloud Run에서 딥러닝 기반 서버 최적화: Connect 이벤트 비동기화와 Lazy Import 적용 사례 (2) | 2024.12.11 |
| OCR 엔진 교체 후에도 메모리 누수 발생 시 대처법 (1) | 2024.12.07 |
| Docker 이미지 최적화로 12GB-> 3.5GB (0) | 2024.12.06 |
| 다중 워커 간 메모리 공유 문제 해결 (0) | 2024.12.03 |