서지간 유사도 측정 API 배포

프로젝트 목표: 입력 받은 서지(도서) 정보와 검색 엔진을 이용해 나온 서지들과의 유사도를 반환하는 API 개발 및 수요 업체 온프레미스에 배포

기간: 2022년 10월 ~ 2022년 12월

구성원: 모델 파인튜닝 및 추론 모듈 개발 (1명), API 개발 및 배포 (본인)

구조

---

API 개발

1. FastAPI 사용: 빠른 속도, 사용하기 쉬움

2. 검색 엔진은 수요 업체에서 제공해준 자바 패키지를 사용:

- 딥러닝 모델로 추론이 필요한 상황이라 파이썬을 사용해야하므로 자바 패키지를 파이썬에서 사용이 가능하도록  도와주는 JPype 모듈 사용

3. 3개의 엔드포인트 구현:

- /health (GET): API 상태 체크

- /rank (POST): 검색 엔진 이용을 사용하지 않고 서지 정보와 검색 엔진 결과 N개를 비교 후 TOP N 반환  (클라이언트에서 검색 엔진을 사용 후 서버에게 서지 정보와 검색 엔진 결과를 주며 유사도 비교를 요청)

- /rank-with-engine (POST): 검색 엔진 이용을 사용하여 서지 정보와 검색 엔진 결과를 비교 후 TOP 10 반환 (클라이언트에서 검색 엔진을 사용하지 않고 서버에게 서지 정보만 주며 유사도 비교를 요청)

4. API 서버는 각각 하나의 GPU를 할당하여 모델을 구동

---

배포

1. 도커 이미지로 빌드 (베이스 이미지: pytorch/pytorch:1.12.1-cuda11.3-cudnn8-runtime)

2. 수요 업체 서버는 각 48GiB 메모리를 가지는 총 4개의 GPU가 장착되어 있어 각 GPU에 모델 17개를 구동하기로 결정

3. docker compose의 replicas를 사용하여 API 컨테이너 scale-out: api-0~api-3가 각각 17개씩 생성 (api 번호는 컨테이너가 사용하는 GPU 번호와 같으며 GPU 번호는 env 파일을 통해 전달받음)

4. nginx를 이용하여 로드 밸런싱:

- 외부에서 8000 포트를 통해 들어오는 요청을 api-0~3의 8000 포트로 전달

- 8000 포트로 들어온 요청은 다시 docker compose가 로드 밸런싱 후 replicas 중 하나의 API 컨테이너에게 전달

- 로드 밸런싱 알고리즘은 roundrobin 사용

5. API 컨테이너로부터 발생되는 로그는 fluentd로 수집 후 로그 파일로 저장:

- 저장된 로그를 기반으로 summary.csv를 생성하는 파이썬 스케줄러 구현

- summary.csv: API 호출 횟수, 호출 성공 횟수, 호출 실패 횟수 및 이유, 초당 호출 횟수, 평균 반환 시간을 하루마다 기록

컨테이너 구조

---

결과

1. 수요 업체에서 최대로 API를 많이 사용한 날 기준: 초당 203회 호출, 호출 당 평균 200ms 소요

2. 서지정보 구축기간 감소 (수요 업체로부터 전달 받은 내용)

2-1. 6주 → 1주, 하루당: 100만 건 구축 → 850만 건 구축, 한 건당: 1초 → 0.09초

---

보완이 필요한 점

1. 도커 이미지를 빌드 할 때 베이스 이미지를 torch 이미지로 사용하니 이미지 크기가 매우 무거워짐 --> 베이스 이미지를 cuda 이미지로 사용하고 multi-stage builds를 이용하여 빌드 예정

2. 수요 업체 측에서 현재 상황을 모니터링 할 수 있는 웹이 있으면 좋겠다고 하였는데 해당 요구사항을 만족시키기 위한 노력이 부족했음 (GPU 모니터링은 nvitop, API 결과 요약은 파이썬 스케줄러가 생성해주는 csv파일로 대체함) --> prometheus와 grafana를 이용하여 시각화 예정

2-1. 조사가 필요한 부분:

- 여러 컨테이너에서 배출하는 metric을 하나의 prometheus 컨테이너에서 수집할 수 있는지 (API 서버가 구동되는 컨테이너만큼 prometheus 컨테이너가 필요한건지)

- replica로 생성된 컨테이너들이 python prometheus client 라이브러리를 사용하여 metric을 배출할 수 있는지