개발자로 후회없는 삶 살기
Naver PART.팀 프로젝트 추론 서버 배포 주의점 본문
서론
11, 12 주차에는 UXR에 구축한 웹 서버와 앞으로 정식 서비스까지 사용할 추론 서버 간의 통신 규격을 정하고 여러 통신 이슈들을 대비하는 시간을 가졌습니다.
본론
- 추론 서버 배포 방식
현재 추론 서버는 GPU POOL을 사용하여 GPU Utilization을 높이는 방식으로 배포되어 있습니다.
https://hsb422.tistory.com/entry/ML-PARTGPU-%ED%92%80-%EA%B5%AC%ED%98%84%EA%B8%B0-2
웹 서버에서 3D 재구성 요청을 큐에 넣으면 가용 가능한 추론 Worker에서 추론을 수행하고 결과 PLY 파일을 클라우드 스토리지에 저장합니다. 이를 통해 큐에 있는 작업을 가져가는 시간을 최소화할 수 있고 작업이 들어온 순서대로 GPU 사용성을 극대화할 수 있습니다.
- 서버 통신 규격
웹 서버와 추론 서버 간 통신을 하기 위한 규격을 정의하였습니다. 웹 서버는 Queue에 유저 업로드 파일 경로만 적재하면 되고 Consumer인 Worker 또한 Queue와 통신하여 메시지가 있는지 체크하고 메시지에서 파일 경로를 가져와 추론을 수행합니다.
컨슈머를 실행하면 메세지가 들어올 때까지 대기하고
while문을 통해 메세지가 들어오는지 반복적으로 모니터링합니다.
웹 서버에서 이미지나 영상을 업로드하면 레디스에 모델 규격에 맞는 메시지를 입력합니다.
메시지가 들어오면 레디스에서 데이터를 추출하고
추출한 데이터를 통해 학습을 진행한 후 학습이 끝나면 ply 파일을 클라우드에 저장하고 다시 while문으로 큐를 모니터링하는 상태로 돌아갑니다.
- 이슈 사항
1. 웹 서버와 추론 서버 사이의 알림
OOM
입력 데이터 포멧 오류로 인한 학습 실패
출력물 생성이 안되는 문제
학습 과정에서는 위와 같이 다양한 오류가 발생할 수 있습니다. 처음에는 추론 서버가 PLY만 생성하면 OK 사인이라고 생각했지만, 요청을 받으면 응답도 하는 것이 통상적으로 올바르다고 생각되기에 OK 사인도 따로 보내야 한다고 생각되었습니다.
이를 레디스 stream은 기본 기능으로 제공합니다. 컨슈머가 메시지 처리를 완료하여 acknowlege 신호를 레디스에게 보내면 레디스가 메시지를 삭제합니다.
만약 일정 시간 안에 완료 메시지가 오지 않으면 처리 실패라고 인지하여 다른 컨슈머에게 메시지를 재 배포할 수 있습니다. 저는 추론 서버 환경이 stream과 맞지 않아 레디스 List를 사용하여 실패 상황에 맞는 메일 알림을 주는 것으로 이를 대체하였지만 이는 Stream의 강력한 기능입니다.
2. 추론 서버 상태 체크
1) 가용 공간
가용 공간이 부족한데 모델이 추론을 하면, 서버에 장애가 발생할 수도 있습니다. 따라서 학습 전에 추론 서버의 남은 공간을 체크하고 용량이 충분할 때만 추론하도록 하는 과정이 필요해 보입니다.
2) 네트워크 상태
분산 환경에서는 데이터를 원격으로 주고받기 때문에 메시지가 유실될 확률이 있고 따라서 다음과 같은 문제가 발생할 수 있습니다.
✅ 발생할 수 있는 문제
1) 웹 서버에 업로드는 성공했어도 추론에 실패했을 때 실패 알림을 주지 않아서 사용자는 무한정 대기
2) 메시지를 pop하는 것 조차 실패하여 메세지 유실
따라서 분산 환경에서 데이터를 주고받을 때는 접속 테스트라는 것을 하는 게 좋습니다.
private static boolean validateUrlS(String urlStr) {
try {
var url = new URL(urlStr);
var oc = (HttpURLConnection) url.openConnection();
oc.setUseCaches(false);
oc.setConnectTimeout(1000);
if (HttpStatus.OK.value() == oc.getResponseCode()) {
return true;
}
return false;
} catch (Exception e) {
log.error("url error", e);
return false;
}
}
예를 들어 파일 경로가 있다면 접근 가능하고 존재하는 파일인지 테스트하고 원격 서버에도 현재 접속 가능한 상태인지 테스트한다면 위와 같은 문제를 막을 수 있습니다.
결론
실시간 스트림 방식의 추론 서버를 운영한 경험담을 작성해 보았습니다. 실서비스에서 고려할 점이 굉장히 많음을 깨달았고 분산 추론 서버를 다뤄보는 값진 내용이었습니다.
'[대외활동] > [네이버 BoostCamp]' 카테고리의 다른 글
[최적화] 유저 트랜잭션 분석을 위한 로깅 전략 (0) | 2024.04.04 |
---|---|
Naver PART.팀 프로젝트 파일 업로드 최적화 (0) | 2024.02.10 |
Naver PART.팀 프로젝트 9, 10주차(가구 모델 리서치, 슈가 뷰어, UXR 모델 확정) (0) | 2024.02.08 |
Naver PART.팀 프로젝트 8주차(모델 세미나, 평가 지표) (0) | 2024.01.29 |
Naver PART.팀 프로젝트 6, 7주차(프로젝트 진행 방식, 주제 구체화, 타당성 분석) (0) | 2024.01.12 |