환경 분리와 배포

 

소프트웨어 개발에서는 운영 환경, Production 환경, 개발 환경, 등과 같은 내용이 나온다.

이에 대해 알아보자.

 

 

 

1. 개발 환경

 

(1) Local

개인 컴퓨터에서 개발하고, 각자의 환경을 통일시키기 위해 Docker를 사용하거나, 환경 설정 일치를 위해 requirements.txt나 poetry 등을 사용한다.

(2) Dev

Local 에서 개발한 기능을 테스트할 수 있는 환경, 즉 테스트 서버다.

(3) Staging

Production 환경에 배포하기 전에 운영하거나 보안이나 성능을 측정하는 환경이다.

(4) Production 

실제 서비스를 운영하는 환경

 

이렇게 개발 환경을 나누는 이유는 뭘까?

실제 운영중인 서비스에 장애가 발생하면 안되기 때문이다.

 

Dev = Staging =  Production 이라면?

 

소스 코드를 저장하는 순간 바로 반영될거다.

만약, 내가 의도하지 않은 저장을 할 경우 그대로 반영되는 일이 발생한다.

 

 

 

2. Git Flow

 

main >> staging >> dev >> feature/기능 이름

 

위와 같이 브랜치를 만들 수 있을거다.

 

feature 에서 기능을 만들어 PR을 한다면 그 역순으로 진행하게 될거다.

 

 

main : Production  서버

staging : Staging 서버

dev : Dev 서버

feature/기능 이름 : Local

 

 

 

3. CI/CD

(1) CI

새롭게 작성한 코드 변경사항이 Build, Test 진항한 뒤, Test Case에 통과했는지 확인한다.

지속적인 코드 품질 관리를 위해 사용한다.

만약 N 명의 개발자가 코드를 수정했다면 N번의 CI 프로세스가 수행된다.

 

(2) CD

작성한 코드가 신뢰 가능한 상태가 되면 자동으로 배포될 수 있도록 한다.

CI 이후에 CD를 진행한다.

dev, staging, main 브렌치에 Merge가 될 경우 코드가 자동으로 서버에 배포된다.

 

 

(3) 정리

CI : 빌드, 테스트 자동화

CD : 배포 자동화

 

(4) 운용

Local에서 개발하고 Main으로 Merge를 할 때 Production 서버에 코드 배포를 할 수도 있을거다.

 

개인 프로젝트에서는 서버를 많이 두지 않는 경우가 대다수다. 그 이유는 서버마다 비용이 청구되기 때문이다.

하지만 언젠가 회사나 다른 곳에서 협업을 할 것을 염두해두면 브렌치를 따로 파서 연습해두는 것도 나쁘지 않을거다.

 

 

 

4. 모델 배포 주의점

(1) Docker 이미지

• 용량이 큰 편이어서 관리가 필요하다.
• 멀티 스테이지 빌드 같은 것을 사용해서 최대한 도커 이미지의 크기를 줄여야 한다.
• 그리고 호스트 머신의 디스크 용량 관리도 필요하다.
  • 도커를 띄우면 CLI에 로그가 남는데, 이 로그들이 어딘가에 저장되고 있을거다.
  • 이걸 주기적으로 삭제해야 한다.
  • 혹은 이런 로그를 클라우드에 보낼 수도 있다.

 

(2) 모델 버저닝

• 모델 코드에 대한 확실한 버저닝이 필요하다.
• 어떤 버전이 현재 배포 중이고, 어떤 버전이 과거에 배포했는지에 대한 히스토리가 관리되어야 한다.
• 거기에 우리 모델이 롤백이 필요한 경우 어떤 버전으로 재배포해야 하는 지도 기록 해야 한다.
• 모델의 버전 별 특징도 알기 쉽게 되어 있어야 한다.

(3) 모델 아티팩트

모델 파일 같은 것을 저장할 수 있다. 이런 것들은 S3에 저장하거나 오브젝트 저장소에 저장해야 하는 것을 권장한다.

모델 버전과 아티팩트의 버전이 다른 경우도 있으므로 메타 정보도 확인해야 한다. (이를 위한 해결책이 MLflow)

적합한 파일 권한 관리 ( VM 인스턴스 , Object Storage )

- VM 인스턴스에서 pth 파일을 읽지 못한다면 정상 실행이 안될거다.

- VM인스턴스에서 Object Storage에 접근할 수 있도록 서비스 계정 만들고 설정해줘야 한다.

- Object Storage에서 다른 사용자가 버킷을 삭제하면 롤백을 할 수 없으므로 '삭제 권한'을 제어할 필요가 있다.