liebert

간단한 리마인드

일반적인 개념보다 앞으로의 방향이 어떻게 되어갈 것인지에 대하여 궁금하여 조금 더 공부를 해보고자 한다. 

컨테이너는 어플리케이션, 라이브러리, 설정 등을 하나의 단일한 패키지로 묶어 격리된 환경에서 실행하는 방식을 채택하고 있다. 기본적으로 컨테이너는 가상화 기술의 일종으로, 가상머신과 비슷한 목적을 가지고 있지만 그 실행 방식과 효율성 면에서 큰 차이를 보인다.

효율성면에서 큰 차이를 보인다-? 

이전에 VM 을 앱 배포에 채택하였던 구글 조상들의 고충은 뭐였을까.

가상머신은 운영체제와 함께 동작하는 풀 스택의 가상 환경을 제공하는데, 이로 인해 무겁고 느리게 동작하는 단점이 있었다. 반면에 컨테이너는 호스트 운영체제의 리소스를 효율적으로 활용하면서도 격리된 환경을 제공하여 가볍게 동작할 수 있도록 고안되었다. 아래 정리된 컨테이너의 장점을 보면 더 이해가 갈 것이다.

• 격리(Isolation): 컨테이너는 각각이 독립된 환경에서 동작하기 때문에 한 컨테이너의 변화가 다른 컨테이너에 영향을 미치지 않습니다. 이는 애플리케이션 간 충돌을 방지하고 보다 안정적인 운영을 가능하게 한다.
  예시: 서로 다른 버전의 어플리케이션을 동시에 실행하거나 특정 환경에서의 실험을 위해 격리된 컨테이너를 사용할 수 있다.
• 가상화(Virtualization): 컨테이너는 가상머신과 유사한 가상화 환경을 제공하지만, 가볍고 빠르게 실행됩니다. 이는 높은 성능과 빠른 배포를 가능케 하며, 여러 컨테이너를 동시에 실행할 수 있다.
  예시: 빠른 확장이 필요한 경우, 컨테이너를 사용하여 더 빠르게 새로운 인스턴스를 추가하고 활용할 수 있다.
• 이식성(Portability):
• 컨테이너는 실행 환경과 상관없이 동일하게 작동하므로, 개발 환경에서 테스트한 애플리케이션을 프로덕션 환경에 그대로 배포할 수 있다.
  예시: 로컬 환경에서 애플리케이션을 개발하고, 동일한 컨테이너 이미지를 사용하여 클라우드나 다른 서버에 배포할 수 있다.
• 자동화(Automation):
• Docker와 같은 컨테이너 도구는 애플리케이션 빌드, 배포, 확장 등을 자동화하여 개발 및 운영 효율을 높인다.
  예시: 코드 수정 시 자동으로 빌드되고, 업데이트된 애플리케이션이 자동으로 배포되는 등의 작업이 자동으로 이루어진다.
• 관리 및 오케스트레이션(Management and Orchestration):
• 컨테이너 오케스트레이션 도구들은 여러 컨테이너를 효과적으로 관리하고 확장하는 데 사용된다.
  예시: Kubernetes는 컨테이너를 클러스터로 구성하여 효과적으로 관리하고, 필요에 따라 자동으로 확장하거나 축소할 수 있다.

이제 궁금했던 점으로.

컨테이너의 향후 방향은 어떻게 진행 되어가고 있을까?

AI 및 자동화의 통합 : 사실 이 문제는 컨테이너 뿐 아니라 클라우드 관리 전반에 걸쳐 영향을 미치지 싶다. 솔직히 말하면 개발이고 운영이고 인프라고 생태계 전체를 송두리째 바꿔놓을 것 같다.

나는 node 베이스의 개발자로 AI 에 대해 잘은 모른다.

web2vec을 활용한 python 엔진을 몇 차례 돌려 보았던 정도. 그래도 open-ai 에서 베타로 출시한 assistant 와 다양한 feature 들, 그리고 open-ai 의 최신 엔진은 나올때마다 계속해서 물고 뜯고 적용해보고 있다.

( 무지막지한 회사 프로젝트의 연속 덕분이다 )

그래봤자 까막눈 수준, 이러한 내가 보았을때도 open-ai 는 확실히 말도 안되는 데이터의 양과 AI 성능을 보여준다. hugging face 를 비롯하여 open source 로 git에 올라오는 엔진들의 수준에 비하면 그냥 경이로울 정도의 격차라고 생각한다. 일반인들이 생각하는 AI 현실화는 더 가속화되지 않을까 싶다. 실제로 open-ai 엄청나게 써대고 있으니까 더 빨라지지 않을까.

다중 클라우드 및 하이브리드 클라우드 지원 : 기업들은 고객 요구 사항 및 비용 효율성 등을 고려하여 여러 클라우드 환경을 동시에 활용하거나, 하이브리드 클라우드 환경을 적용하려는 경향이 있다. 컨테이너는 환경 간 이식성이 뛰어나기 때문에 다중 클라우드 및 하이브리드 클라우드에서의 활용이 강조되어가고 있는 추세이다.

이미지 업로드 = 리소스 절감 이 공식처럼 되어버렸다.

아마 IT 기술에 대해 잘 모르는 대표들도 컨테이너로 배포하라는 말은 어디서 듣고와서 입에 달고 살지 않을까 싶다.

서버리스 컨테이너 활용의 확대 : 서버리스 컨테이너 기술은 더욱 진화하여, 애플리케이션의 작은 부분들을 빠르게 실행하고 관리하는 데에 더 큰 중요성을 갖게 될 것으로 예상된다고 한다. 마이크로 서비스 단위로 계속해서 쪼개지는 것이다. 사실 현재에도 잘 설계된 서비스들은 사용하는 양에 따라 리소스가 조정되고 매니징되고 컨테이너 별로 잘 나뉘어져 있다. 더 쪼갤 필요성이 없다는 것이다.

service 의 단위를 마냥 쪼개는 것이 효율적이지는 않을 것이다. 리소스는 절감되지만 사람은 살려달라고 소리를 지르게 되지 않을까. 그걸 모니터링 하는 건 결국 휴먼이니까. - 다만, AI가 적용된다면 이것 또한 새로운 이야기일 것이다. 그때는 Container 개념이 아니라 AWS의 Lambda 와 더 가까워지겠지..

컨테이너에 대한 리마인드,

끄적끄적 생각 끝. 

3. Backend 배포하기

배포에는 두 가지 라이브러리를 사용할 예정이다. 

App containerize 에는 docker, 그리고 node process management 에는 PM2.

구조적으로 보면 VM 내에 backend 와 frontend 두개의 레퍼지토리가 있고, 이 위에 도커가 존재하며 back container / front container 각각을 컨테이너로 분리한다. pm2 는 back container 내에 프로세스 매니징 툴로 이식 된다.

(1) PM2 node process manager 적용

npm 으로 pm2 를 먼저 설치한 후 ecosystem.config.js 파일 내에 module config 를 작성해준다. 온라인에 찾으면 많은 예시들이 있을 것이다. 어려울 부분이 없으니 차근차근 작성한 후 local 에서 node를 pm2 로 실행시켜보자.

pm2 start ecosystem.config.js 
pm2 status 
pm2 restart 0 / 1 / 2 ...
pm2 logs 0 / 1 / 2 ...

 PM2 status 를 확인해보면 두 개의 클러스터가 돌고 있는 것을 확인할 수 있다.

클러스터를 두 개로 한 이유는, 한개의 클러스터가 모종의 이유로 멈춰버렸을 시 pm2 가 두 번째의 클러스터를 돌리도록 하기 위함이다. 

서버의 부하가 심할 일도 없고, 어떠한 이유로도 멈출 가능성은 많지 않지만 prod 에 적용될 몇 가지 테스트를 진행하기 위해  클러스터를 두가지로 분리해주었다. 나중에 부하 테스트로 첫 번째 cluster를 강제로 멈춰볼 생각이다. 

(2) Docker - containerize

Server / Source managing 이 끝났으니 backend app 을 컨테이너화 시켜야 한다. 

VM 에 docker 설치를 진행한 후, nest-app root directory 에 Dockerfile을 생성해준다. Dockerfile은 도커 명령어를 실행시키기 위한 package.json 에 가깝다고 보면 좋을 것 같다. 

docker-compose.yml 파일로 config 를 푸시하는 과정도 있는데 그 과정은 따로 정리하기로 하고 일단 컨테이너화부터 시켜보자.

지금은 당장 docker-compose.yml이 필요하지 않다. 

pm2 를 사용하여 node process를 관리하고 있으므로 

Dockerfile 도 아래와 같이 작성해주면 된다.

일반적으로 document에서 제시하는 Dockerfile format 과 다른점은 pm2-runtime 을 cmd로 사용하고 있다는 점이고, 이를 위해 npm install -g -pm2 를 먼저 실행시켰다.

package.json 에 pm2 가 잘 들어가 있는 것을 확인하였는데, npm install 시에 왜 제대로 설치되지 않는 것인지 이유를 잘 모르겠다. 꼭 -g 명령어로 전역 설정을 해주어야 제대로 돌아가더라. 해당 내용도 왜그런지 찾아봐야겠다.

무튼간에 WorkDir /var/app으로 맞춰두었고, 나 같은 경우 ecosystem.config.js 파일을 root directory 에서 관리하는 것이 아니라 환경에 따라 세 가지로 분류하여 관리하였기 때문에,  CMD 내에 정확한 ecosystem.config.js 위치를 적어주었다.

Dockerfile 작성이 끝나면 container 를 생성해주자. 

// docker container 생성. -t 는 태그. tag 는 optional이니까 굳이 안넣어도 되긴하다. 
sudo docker build . -t your-app-name:tag

// docker container run 명령어. 
// -d 는 detached : container를 background에서 실행시키고, 터미널은 다른 커맨드 실행을 위하여 해당 컨테이너에서 분리.
// -p 는 port : host port는 앞에 오고, container port는 뒤에 온다.  
sudo docker container run -d -p 4040:4040 your-app-name

sudo docker ps
sudo docker stop CONTAINER_ID
sudo docker images
sudo docker rm CONTAINER_ID (컨테이너 삭제 - stop 이후 사용)
sudo docker rmi IMAGES_ID --force (이미지 삭제 - container stop 되어야 삭제 가능)\

// pm2 process monitoring
sudo docker exec -it {컨테이너이름} pm2 list

// 실행중인 pm2 로그 확인
sudo docker exec -it {컨테이너이름} pm2 log {pm2 list 중 하나. ex) nest-app}

최상단에 위치한 명령어 부터 실행시켜보며 container 가 생성되었는지와 running status, 그리고 pm2 를 통한 container 내의 node process monitoring 까지 진행해본후 디버깅 과정을 마무리하면 백엔드 배포는 끝났다고 보면 된다.