해당 내용은 [FastAPI] (STT 기능 API 만들기)음성인식 데이터 처리 (WAV to PCM) #1 과 이어진다.
보통 혼자 개발을 하여 따로 git 저장소에 대해서 생각을 안하였다. (그래도 .gitignore 파일을 까먹고 안올리지는 않았다.)
이번에 실수로 .gitignore을 만들지 않고 local git에 commit 했는데 갑자기 7천 개 내용이 변동 사항으로 commit 되어서 순간 당황하였다.
확인한 결과 .gitignore 을 추가하지 않았다.
보통의 경우 가상환경(venv etc...)등에 대해서 설정과 관련된 코드 부분을 함께 작업하는 모두가 공유하지는 않는다. (하더라도 버전만 맞출 것이다.)
그리하여 가상환경 전체를 push하는 것이 아닌 필요한 환경 설정의 경우 requirement.txt로 작성하고 commit하고 Push한다.
처음 local에 commit하고 실수로 main -> develop -> feat/fastapi-implementation 중 feat/fastapi-implementation 에다가 push하여 당황하였다. 하지만 일단 develop이나 main에 하지 않아서 .gitignore과 requirement.txt를 추가하여 commit push 하였다.
덕분에 커밋한 로그가 아주 난리였다.
다시 복구하였다. 결국 ... ㅠ
이후 docker 연동을 하였다.
일단 Docker란,
컨테이너 기반의 가상화 시스템이다.
컴퓨터 한 대에서 여러 운영체제를 한 번에 돌리면 서로 치여 느려짐
커널을 동일한 커널을 사용한다면 알맹이가 같다 -> 하나로 퉁치는 것은 불가능한가?
이런 고민으로 완성된 오픈소스 기술이 바로 도커임
도커를 사용한다면 독립된 운영체제를 여러 개 띄울 필요 없음
운영체제 알맹이는 통일하고 필요한 부분만 묶어 가상화 => 컨테이너 라고 함.
쉽게 내 운영체제 (mac os)위에다가 도커를 띄움. 그러면 그 안에서 컨테이너 여러 개로 나누어서 실행함.
일단 신기했다.
docker를 사용하려던 이유 중에 하나가 내가 계속 서버를 실행시키지 않아도 같이 작업하는 분이 끌어다가 쓸 수 있는 것이다.
처음에는 이 부분에 대해서 docker에 올리면 그냥 api 서버가 계속 켜져 있다고 생각했다.
지금 이해한 것으로는 API 코드를 docker에다가 올리면 같이 작업하는 분은 내 docker의 api를 pull하여 자신의 docker로 끌고 올 수 있다.
그렇게 되면 본인이 해당 api를 사용할 경우 docker에서 실행하여 동시에 작업하는 것이 가능하다. (약간 깃헙처럼 api나 다른 코드를 쉽게 관리 협업 할 수 있게 한다.)
컨테이너로 가져와서 실행시키는 API마다 웹서버가 실행할 수 있는 시스템이라고 이해하면 된다.
여기까지는 이해했다.
처음에 이해가 안된 부분이 하나 있었다. 그것은 바로 docker의 이미지라는 것이다.
내가 생각한 이미지는 그림 이미지 이런 2D 형태의 이미지였다.
도커의 이미자란,
일종의 applicaiton 포장 전송 장치이다.
파일로 어플리케이션 실행에 필요한 독립적 환경을 포함하여, 런타임 환경 구축을 위한 일종의 템플릿이다.
소스코드, 라이브러리, 종속성, 도구, 응용 프로그램, 기타 파일을 포함하는 불변 파일이다.
: 읽기 전용이다 (특정 시점의 애플리케이션과 가상 환경 구성을 나타낸다)
# Python 이미지 사용
FROM python:3.9
# 작업 디렉토리 설정
WORKDIR /app
# 필요한 패키지 설치
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
# 애플리케이션 코드 복사
COPY . .
ENV PYTHONPATH=/app
# 컨테이너 실행 시 실행할 명령어
CMD ["python", "app/connectAPI/main.py"]
이 부분은 docker에 띄워야 하는 두 가지 이미지(app / model(딥러닝)) 중 app에 해당하는 부분이다.
version: '3'
services:
api:
build: .
ports:
- "8000:8000"
volumes:
- .:/app
전체 application의 docker-compose.yml파일이다.
차이라면, Dockerfile의 경우 단일 컨테이너를 control하는 이미지라고 생각하면 된다.
그의 반하여 docker-compose.yml 파일의 경우 여러 컨테이너로 구성된 어플리케이션을 정의하고 실행하기 위한 파일이다.
일단 간단한 api를 구현하고 docker에 올려서 실행 시킨 것이 좋은 경험이었다.
하나 궁금증이 생겼다. docker-compose.yml 파일에서 여러 docker container를 관리하는 것이 가능하다면, 꼭 내가 단일 app에 단일 container로 설계하는 것이 아닌 부하가 높은 app에 대해서 여러 container를 걸어주거나, 여러 container를 교차하여 작동하게 하여 계속 실행시킬 수도 있지 않을까 라는 생각이 들었다.
확인해 본 결과
nginx라는 컨테이너를 이용해서 가능하다고 한다.
여기서 이해하면서 궁금했던 것은 nginx 또한 웹서버이고 FastAPI에서 사용하는 uvicorn 또한 웹서버이다. 그렇다면 웹 서버를 대체해서 사용한다? 왜? 라는 의문이 생겼다.
이것에 대한 결론은 uvicorn이 실행되는 웹 서버의 위치는 docker의 단일 container 위 라는 것이다.
그렇다면 nginx 웹서버는 어디서?
이 부분은 docker(FastAPI container 1~10) 실행 전에 client의 요청을 nginx container가 관리하게 된다.
이것에 대해서 docker container의 동작을 제어하는 느낌이다.
이런 식의 구현이 가능하다는 것이 놀랍다
이번 프로젝트에서는 로드 밸런싱으로 구현하는 것까지는 필요하지 않을 지 모르지만, 해볼 생각이다. 굉장히 신기하고 재밌었기 때문이다.
[프로젝트] 음성인식 프로젝트 #1 딥러닝 모델 (0) | 2025.04.17 |
---|---|
[음성인식] 3주차 강의 (월요일 수업) #3 Sampling (0) | 2025.03.21 |
[음성인식] 3주차 강의(월요일 수업) #2 Filter (0) | 2025.03.21 |
[음성인식] 3주차 정리(월요일 수업) #1 푸리에 변환 및 여러가지 (0) | 2025.03.20 |
[음성인식] 2주차 정리 - 푸리에 변환 (Fourier transform, FT) (1) | 2025.03.13 |