간단한 리마인드

 

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

 

컨테이너의 미래는 어떻게 될까? 출처 maritime NZ

 

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

 

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

이전에 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 기술에 대해 잘 모르는 대표들도 컨테이너로 배포하라는 말은 어디서 듣고와서 입에 달고 살지 않을까 싶다.

 

Container 와 전혀 무관한 사진이다.

 

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

 

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

 

 

 

 

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

끄적끄적 생각 끝. 

 

쿠버네티스는 조타수를 뜻하는 그리스어다.

 

 

 

 

Brief Intro

간단하게 쿠버네티스는, 컨테이너 런타임 활용에 대한 서비스를 지원하는 오케스트레이션 플랫폼이다.

 

컨테이너 기술이 새로운 국면을 맞이하게된 시점으로 돌아가보자.

 

당시에는 배포 가능한 애플리케이션 구성 요소의 수가 많아지고 있었고, 이에 따라 앱의 모든 구성 요소의 관리가 점점 어려워지는 바람에 구글은 골머리를 썩고 있었다.

하이퍼바이저가 적용된 베어메탈에서 여러 개의 앱을 띄운다고 생각해보자.

( 하이퍼 바이저는 physical server 즉 베어 메탈로 하여금 리소스를 분배하여 가상 머신을 만들고 실행 시킬수 있도록 해주는 프로세서라고 생각하면 된다.) 

 

첫 번째 방법으로는, 서비스마다 VM 을 띄우는 것 (모든 마이크로서비스가 한 개의 VM에 집약되어 관리되는 모놀리스 방식) , 두 번째 방법으로는 VM 이 아닌 리눅스 '컨테이너' 를 활용하여 리눅스 커널단에서 직접적인 배포 라는 두 가지 옵션이 있을 것이다.

 

전자의 경우 도커와 컨테이너가 유행하기 이전까지 전형적인 앱 배포 방식이었다. 배포해야 할 서비스의 수가 늘어날 수록 리소스 관리 측면에 있어서 어려움이 있을 수 밖에 없는 것은 당연한 일이었다.  이에 반해, 이동성과 리소스 효율성이 뛰어났던 컨테이너의 경우 최신 클라우드 네이티브 애플리케이션의 컴퓨팅 단위가 되었다. 

 

 

Details

왜? 라는 질문을 했다면... 좋은 자세다. 굿.

 

 

리눅스 컨테이너 - 컨테이너를 활용하였을 때 VM 을 통한 배포보다 리소스 효율성과 이동성이 뛰어난 이유는 무엇일까?

 

 

 

컨테이너 기술이 가상 머신 (VM)을 통한 애플리케이션 배포보다 우수한 이유는 크게 다섯 가지 측면에서 나타난다.

 

이동성 (Portability)

컨테이너는 응용 프로그램과 필요한 모든 종속성을 패키지로 묶어 이식성이 뛰어나다. 컨테이너는 호스트 시스템의 운영체제와 상관없이 동일한 환경에서 실행될 수 있으며, 개발 환경과 프로덕션 환경 간에 쉽게 이동할 수 있다. 컨테이너는 하나의 패키지다. 앱을 run 하기 위한 명령, meta-data가 모두 포함된 하나의 패키지 덩어리이기 때문에 어떠한 앱을 다른 워크 노드에서 띄우는데 문제가 전혀 없다. ( run app A on B node, -> run app B on C node (o) ) 

 

리소스 효율성 (Resource Efficiency)

가상 머신은 전체 운영체제를 가상화하고 별도의 커널을 사용하기 때문에 무겁고, 높은 오버헤드가 발생한다. 반면, 컨테이너는 호스트 시스템의 커널을 공유하므로 가벼우면서도 빠르게 시작되고 중지될 수 있다. 이로써 더 적은 메모리와 디스크 공간을 사용하며, 빠른 배포와 확장이 가능하다. (반대로 생각하면? 별도의 커널이나 OS설정이 필요한 애플리케이션의 경우 컨테이너를 활용할 수 없다)

 

시스템 관리 용이성 (Management Ease)

컨테이너는 이미지로서 애플리케이션 및 종속성을 패키징하므로, 관리 및 배포가 훨씬 간단하다. 이는 개발, 테스트, 그리고 프로덕션 환경에서 일관성 있는 운영을 가능케 한다.

 

자동화와 스케일링 (Automation and Scaling)

컨테이너 오케스트레이션 도구들 (예: Kubernetes, Docker Swarm)을 활용하면 컨테이너를 자동으로 배포하고 관리할 수 있다. 이는 애플리케이션의 자동 확장과 고가용성을 쉽게 구현할 수 있게 한다. ( 간단하게 말하면, 컨테이너와 관련된 여러 툴들이 이미 많이 있기 때문에 직접 VM 안에서 배포를 위해 이것저것 만지지 않아도 된다는 뜻이다)

 

개발자와 운영팀 간 협업 (DevOps Collaboration)

컨테이너는 애플리케이션과 인프라스트럭처를 분리함으로써 개발자와 운영팀 간의 협업을 강화한다. 개발자는 애플리케이션을 개발하고 패키징하고, 운영팀은 컨테이너를 관리하고 배포하는 데 중점을 둘 수 있다.

 

다른 모종의 이유들도 많겠지만, 위의 큼지막한 다섯 가지 이유만으로도 컨테이너 기술은 현대의 애플리케이션 배포 관리에서 매우 인기 있는 선택지가 되었다 정도 알고 있으면 좋을 것 같다.

 

Linux / Kubernetes 와 관련된 디테일은 차차 공부하며 정리하도록 하고, 내일은 Container와 뗄레야 뗄 수 없는 Docker 에 대해서 잠깐 정리하고 지나가고자 한다. 

 

 

- 배포 환경 : Azure Portal

- DNS : Gabia

- Backend Server : Nest.js, Pm2 (process manager), Docker (App Isolator), ACI (Container Hub)

- Database : MongoDB 

- Frontend : Next.js 

 

1. VM 생성하기

 

 

앱을 배포하기 위해서 자체 서버를 돌리지 않는 이상, 당연히 VM이 필요하다.

마이크로소프트가 제공하는 에저의 클라우딩 서비스를 공부하는 중이기도 하고, 마침 회사에서도 B2B 솔루션을 메인잡으로 하고 있기에 Azure Portal 을 이용하여 VM을 생성하였다. 개인 소영업과 스타트업의 경우에는 AWS를 더많이 사용하는 추세인 듯 하다. 반대로 90%의 Industry Giant들은 MS가 제공하는 애저를 사용한다.

 

 

(1) Azure Portal -> Resource 만들기 -> 가상머신 만들기 

 

 

 

VM 에 필요한 리소스와 가용성, Cloud server location 등은 필요에 따라 맞춰주면 된다. 이미지의 경우 테스트를 위해 Ubuntu Server 중 가장 저렴한 것으로 설정했다.

 

 

아래는 가상머신 만들기의 기본 사항 탭이다. 그 중 관리자 계정 파트는 나중에 VM 에 접근 할 Auth를 설정하는 곳이라고 보면된다.

나와 같은 경우는 인증 형식을 암호로 체크하였다. 직관적이고 익숙한게 좋아서..

 

 

 

 

사용자 이름에는 본인이 사용하고 싶은 이름, 암호에는 본인이 사용하고 싶은 암호를 넣으면 된다. 

이 부분은 나중에 vm 접근 시에 당신이 만든 VM의 "ssh"+ "publicIP" + "-l" + "yourID" 순으로 터미널에 입력된다. 

그 이후에 터미널에서 묻는 query 에 설정한 password 를 입력하면 vm 으로 접근이 된다. 

 

방금 설명한 내용은 아래 참고하면 된다.

 

password 입력시에 안보인다고 쫄지 마시고, 끝까지 잘 입력 후 enter 누르시길.

 

 

(2) 디스크 설정 -> 네트워킹 설정 -> 관리 -> 모니터링 -> 고급

 

나머지는 건드릴 만한 내용이 솔직히 없다. 네트워킹과 같은 경우 인바운드 포트를 눌러보면 HTTP, HTTPS 가 나오는데 이 둘에도 체크를 해주자. 태그 탭에 이르면, VM 에 붙이고 싶은 이름과 값을 입력해주면 된다. 결론적으로 의무적으로 건드릴 부분은 기본사항 / 네트워킹 / 태그 / 검토 + 만들기 정도이다. (나머지는 필요에 의해서.)

 

 

왠만하면 부하 분산 옵션에 Load Balancer 도 체크해주자. 알아서 부하 분산을 체크하고 모니터링 해주는 Azure 자체 서비스다.

 

 

 

VM 생성이 잘 되었고 access 에도 문제가 없다면 docker 를 통한 app containerize 차례다.

아니다 그 이전에 nginx 로 DNS 먼저 잡아보자

'Deployment > Guide' 카테고리의 다른 글

Deployment 3 - Backend (Nest.js)  (0) 2023.10.30
Deployment 2 - DNS / NGINX  (0) 2023.10.30

+ Recent posts