2.5.2 CI/CD와 무중단 배포 앞에서 언급한 것처럼 프로젝트를 배포한 이후에도 개발이 멈추지 않았는데, 변경된 코드를 서버에 적용하기 위해서는 개발환경에서 테스트를 마친 이후 깃허브에 푸쉬하고 서버에 접속핸 뒤 깃허브에서 코드를 당겨온 후 서버를 재부팅하는 과정을 반복했다. 그런데 서비스에 사용된 자연어처리 모델을 로드하는데 꽤 오랜 시간이 걸렸기 때문에 한번 수정사항을 서버에 반영하기 위해서는 최소 1 ~ 3분의 시간이 낭비되었다. 그 동안은 서버가 내려가있는 상태이기 때문에 실제 서비스에서는 이러한 일을 방지해야 할 것 같았다. 그래서 다음 프로젝트에서는 배포중 반복되는 일련의 과정을 CI/CD를 통해 해결하고 배포가 진행되는 중에도 서버가 실행되도록 하기 위해 무중단 배포를 하는 방법을 간략하게 정리하였다. CI/CD CI/CD란 지속적 통합, 지속적 배포(Continuous Integration/Continuous Deployment) 의

2.5.1 Logging 프로젝트 막바지에는 서버를 배포하여 실제 환경에서 테스트하면서 새로운 기능들을 추가하는 방식으로 개발을 이어나갔는데, 로그의 중요성을 모르고 Nginx와 Django에 로깅 설정을 하지 않고 서버를 돌렸다. 그 결과, 서비스에 접속하여 테스트를 할 때 문제가 생기면 어떤 이유로 문제가 생긴건지 알수없어 그때마다 서버를 재부팅하고 같은 문제를 발생시켜 실시간으로 로그를 모니터링하면서 디버깅을 했다. 그 때라도 로그를 남기도록 설정을 할 수 있었지만 마감기한이 코앞이라 서비스 보수 외에는 신경을 쓸 겨를이 없어 불편함을 감수하고 그대로 진행하여 프로젝트를 마무리하게 되었다. 이를 계기로 코드를 서버에 올려 배포만 하면 끝인줄 알았지만 서비스의 유지보수도 꽤 비중이 있는 작업이라는 것을 깨달아서 다음부터는 같은 실수를 하지 않기 위해 로그에 대한 내용을 정리하였다. Logging Logging이란 로그를 남기는 행위로 로그란 소프트웨어가

2.5 개선사항 두달동안 공들여 만든 프로젝트를 무사히 배포까지 마치고 도커와 도커 컴포즈를 사용하여 나름대로 체계적인 서버를 구성했다. 본문에서 다루지는 않았지만 Certbot 컨테이너를 이용하여 SSL인증 설정까지 포함하여 서버를 열었다. 하지만 배포과정에도 몇가지 아쉬웠던 점이 있어, 추후에 다른 프로젝트를 진행할 때 이 부분까지 신경써서 배포를 진행하기 위해 개선할 점들을 아래에 정리하였다. 2.5.1 Logging 2.5.1 Logging 2.5.2 CI/CD와 무중단 배포 2.5.2 CI/CD와 무중단 배포

2.4 Nginx 프로젝트를 배포하는 과정 중 가장 골치아팠던게 Nginx였다. 장고쪽 컨테이너는 Gunicorn을 통해 WAS(Web Application Server)로 만들었는데 리액트로 만든 정적파일을 어디에서 호스팅해줘야 하는지 감이 잡히지 않아 애를 먹었다. 웹서버에 대한 개념이 부족해서 지금보면 당연한 걸 이해하기까지 오랜 시간이 걸렸다. 그 당시 내가 헷갈렸던 개념들과 해결책을 아래에 정리해 보았다. 2.4.1 웹 서버와 WAS Nginx에 대해 알아보기 전에 먼저 웹 서버가 무엇인가에 대해 말하자면, > 웹 서버는 HTTP또는 HTTPS를 통해 웹 브라우저에서 요청하는 문서나 오브젝트를 전송해주는 서비스 프로그램이다 - 위키백과 라고 나와있다. 또한 웹 어플리케이션 서버에 대한 정의는 다음과 같다. > 웹 어플리케이션 서버는 웹 어플리케이션과 서버 환경을 만들어 동작시키는 기능을 제공하는 소프트웨어 프레임워크이다 - 위키백과 즉, 웹서버는 클

2.3 Docker 앞에서 언급한 것처럼 이번 프로젝트에서는 한 인스턴스 안에 두개의 서버를 올려야 했기 때문에 환경을 구분하기 위해 도커를 사용했다. 2.3.1 Docker Docker란 컨테이너 기반 오픈소스 가상화 플랫폼으로 각 프로세스를 격리된 공간(컨테이너)으로 나누어 관리할 수 있도록 도와주는 툴이다. 도커의 역할은 가상머신과 비슷하지만 구현 방법에 있어서 가상머신처럼 OS를 가상화하지 않고 프로세스를 격리하는 방법을 통해 더 가볍게 가상화를 구현하였다. 도커를 사용하기 위해 알아야 하는 가장 중요한 개념은 컨테이너와 이미지이다. 이미지 : 도커 이미지란 쉽게 말해 컨테이너를 찍어내는 틀로 컨테이너의 환경과 구성정보에 대한 내용이 담겨져있는 파일이다. Dockerfile을 빌드하여 만들거나 Docker Hub에서 이미지파일을 받을 수 있다. 컨테이너 : 도커 이미지를 통해 생성된 실제 인스턴스로 프로세스를 독립된 환경에서 실행하기

2.2 AWS 이번 프로젝트의 배포에는 AWS환경이 사용되었다. AWS를 사용한 이유는 가장 보편화되어있는 클라우드 서비스이기도 하고, 처음 서비스를 배포하는 입장에서 참고할만한 자료가 많았기 때문에 AWS환경을 선택하게 되었다. 2.2.1 RDS 배포과정에서 가장 먼저 한 작업은 데이터베이스를 원격으로 올린 것이다. 집과 학교를 오가며 개발을 하다보니 데스크탑과 노트북에서 각각 로컬환경으로 개발을 진행하게 되었는데, 두 환경에서 로컬 데이터베이스를 사용하여 개발을 진행하다보니 데스크탑에서 노트북으로, 노트북에서 데스크탑으로 이동할 때마다 DB에 저장된 데이터가 달라 같은 작업을 여러번 하게 되어서 불편했다. 그래서 먼저 AWS를 통해 배포를 하기로 결정하고 RDS에 원격 데이터베이스를 구축하여 여러 로컬환경에서 같은 DB에 접속할 수 있도록 구성하였다. RDS에서 원격 데이터베이스를 생성하고 이를 장고 프로젝트에 연동하기 위해서는 settings.py의 DATABASE

2.1 배포과정 프로젝트 마무리단계에서 본격적으로 웹 서비스를 배포하는 방법에 대해 찾아보기 시작했다. 웹을 다루는 첫 프로젝트였기 때문에 역시 배포해본 경험이라고는 전무했기 때문에 배포가 구체적으로 어떤 행위인지 이해하는 것부터가 난관이었다. 구글과 유튜브를 닥치는대로 찾아가며 어렴풋이 배포가 무엇인지, 웹서버는 무엇이고 WAS는 무엇인지, 백엔드와 프론트엔드가 어떻게 소통하는지 등 몰랐던 것들을 알게되고 잘못 알고있었던 내용들도 고쳐가면서 결국 그럴듯하게 서버를 구성하였다. 아래는 이번 프로젝트의 서비스 구조도이다. 서비스 구조 설명을 하자면 전체적으로는 AWS환경을 사용하여 서비스를 배포하였고, 데이터베이스 서버는 RDS에, API서버는 EC2인스턴스에 올려 구축하였다. 정적파일을 호스팅해주는 웹서