서버 관리의 변천사

서버 관리를 위한 프로세스 

ㆍ문서화

: 프로그램 설치 방법 및 환경 설정을 문서화

: OS 및 버전의 차이로 인한 문제 발생 위험

 

ㆍ설정 관리 도구

: Chef, Puppet, Ansible 등의 설정 관리 도구를 활용한 자동화 시스템 구축

: 사용자 대신 관리도구가 서버에 명령을 내리는 방식

: 서버 관리자는 설정 관리 도구에 필요한 설정을 미리 정의

: 설정관리 도구에 대한 학습이 필요하며 설정이 복잡해질 경우 복잡성이 커짐

> 참조 (https://2mukee.tistory.com/81)

 

ㆍ가상 머신

: 물리적인 서버에 여러 개의 가상머신을 구동

: 가상머신 하나에 하나의 APP 구동시 충돌 위험성 감소

: Virtualbox 및 VM Ware등의 특정 벤더에 대한 종속성 발생

: 높은 리소스 사용률로 인한 성능 저하

 

ㆍ컨테이너

: 가상 머신을 경량화한 가상 환경 도구

: 가상 머신의 장점을 가지면서 낮은 리소스 사용률을 가짐

: 실행 환경의 공유가 쉬우며 재사용성이 높음

> 참조 (https://2mukee.tistory.com/79)

 

 

 

컨테이너

: 가상 머신 보다 더욱 효율적인 리소스 사용

: 컨테이너 이미지 파일을 통한 용이한 배포와 롤백

: 언어나 프레임워크에 상관없이 애플리케이션 구동 가능

: 특정 클라우드 벤더에 종속적이지 않음

 

 

 

컨테이너를 도입한 개발 프로세스 

ㆍCode

: 개발자가 코드를 작성

 

ㆍBuild

: 작성한 코드를 바탕으로 도커 이미지 생성

 

ㆍShip

: 생성된 도커 이미지를 이미지 저장소에 저장

: DockerHub, AWS ECR, Google Cloud GCR 등..

 

ㆍRun

: 이미지 저장소에서 받은 이미지를 컨테이너로 실행

 

 

 

컨테이너의 문제점

ㆍ배포(Deployment)의 문제점

: Run을 하기 위해서는 모든 서버에 접속 필요

: 유휴 자원 관리를 위한 리소스 관리 필요

: 새롭게 배포된 애플리케이션 장애 발생시 롤백에 대한 신속한 대처 난해

 

ㆍ서비스 검색의 문제점

: 프록시 서버를 통해 내부 서비스 접근하는 Micro Service의 경우 빈번하게 발생

: 부하 발생으로 인해 스케일 아웃을 할 때 로드 밸런서 등의 설정 필요

 

ㆍ서비스 노출의 문제점

: 새롭게 서비스가 추가될 때 마다 프록시 서버 설정 추가 필요

 

ㆍ서비스 장애, 부하, 모니터링의 문제점

: 장애가 발생한 컨테이너의 로그를 보고 직접 다시 실행하는 작업 필요

: 예상치 못한 부하에 대한 늦은 대응

 

 

 

컨테이너 오케스트레이션 

: 복잡한 컨테이너 환경을 효과적으로 관리

: 서버 관리자의 역할을 대신 수행하는 도구

 

 

컨테이너 오케스트레이션의 기능

ㆍ클러스터

: Master Node를 두어 컨테이너들을 관리

: 클러스터 내부의 활발한 네트워킹

: 클러스터 내 컨테이너가 많아질때 Node Scale을 통해 관리

 

ㆍ상태 관리

: 컨테이너의 상태를 정의하는 것으로 별도의 명령 없이 컨테이너의 상태를 유지

: 장애로 인한 상태 변동시 설정된 상태를 유지하기 위한 명령 자동 실행

 

ㆍ배포 관리

: 유휴 리소스를 관리하여 새로운 컨테이너 생성시 애플리케이션을 알맞은 서버에 배치

 

ㆍ배포 버전 관리

: 배포 시 중앙에서 자동 배포 

: 중앙에서 롤백 관리

 

ㆍ서비스 등록 및 조회

: 새로운 서비스 추가 시 해당 서비스에 대한 설정을 자동으로 추가

: 프록시 서버와 설정 저장소를 연동

 

ㆍ볼륨 스토리지

: 각 컨테이너 별 볼륨 관리를 추상적인 레벨에서 수행

 

 

 

컨테이너 오케스트레이션 종류

ㆍKubernetes

ㆍDocker Swarm

ㆍMesos

ㆍMarathon

ㆍNomad

ㆍRancher

ㆍDeis

 

 

 

 

 

 

Refference

Kubernetes - 컨테이너 오케스트레이션 (Container Orchestration) 이란?