본 글은 유튜브 채널 44BITS에서 제작 한 영상을 요약 정리 한 것입니다.
아래 이미지를 클릭하시면 영상으로 이동합니다.

서버 관리의 변천사

서버를 관리한다는 것

• 서버의 상태를 관리하기 위한 노력 : 서버가 문제 없도록, 서버가 죽지 않도록 관리
• 서버 관리자들의 고충 : 알 수 없이 발생하는 장애, 원치 않는 시간의 장애

관리를 쉽게 하기 위한 노력

문서화

• 프로그램 설치 방법을 화면 하나 하나 캡쳐를 해서 매뉴얼 작성
• 아무리 잘 만든 문서라도 문제는 발생 : 업데이트가 안되거나 환경의 차이(OS, 버전 등...)로 인한 문제 발생

설정 관리 도구 활용

• Chef, Puppet, Ansible 과 같은 설정 관리 도구를 활용하여 자동화
• 사용자가 서버에 직접 명령을 내리지 않고, 관리 도구가 대신 명령을 내리는 방식
• 서버 관리자는 설정 관리 도구에 필요한 설정을 미리 정의해 놓으면 됨
• 전 보다는 편해졌지만 문제는 발생
  • 설정 관리 도구 학습 필요
  • 설정이 복잡해 질수록 설정 관리 도구의 사용 또한 복잡해 짐
  • 예: 각각의 어플리케이션에서 서로 다른 자바 (또는 노드) 버전을 사용하는 경우. 별도의 경로 설정 등이 필요

가상 머신

• 서버 하나에 가상 머신 여러 개를 띄워서 사용
• 가상 머신 하나를 오직 하나의 APP만 사용하면 충돌의 위험이 사라짐
• 클라우드 환경이 떠오르면서, 클라우드 환경과 맞지 않는 부분이 발생
  • 특정 벤더에 종속 (VirtualBox, VMWare 등...)
  • 멀티 클라우드를 사용하게 될 경우 사용이 어려움
• 태생적으로 속도가 느림

도커 컨테이너

• 도커가 설치 되어 있는 곳이라면 어디에서든 동작
• 가상 머신처럼 속도가 느리지도 않음
• 사용하기도 쉬움
• 대부분의 서버 관리자들이 환영

도커의 등장

컨테이너의 특징

• 가상 머신과 비교하여 컨테이너 생성이 쉽고 리소스(CPU, Memory) 사용이 효율적
• 컨테이너 이미지를 이용한 배포와 롤백이 간단
• 언어나 프레임워크에 상관 없이 어플리케이션을 동일한 방식으로 관리
• 개발, 테스팅, 운영 환경은 물론 로컬 PC, 클라우드까지 거의 동일한 환경을 구축
• 특정 클라우드 벤더에 종속적이지 않음

컨테이너화 (Containerization)

• 기존에 복잡하게 설치해서 사용하던 것들이 도커 컨테이너를 올리기만 하면 사용 할 수 있게 됨
• 예: MySQL, Redis, RabbitMQ, Jekins, WordPress 등...
• 한 번 컨테이너 사용에 맛을 들이면, 모든 것을 컨테이너화 하고 싶은 욕구가 생김

도커로 인해 확립 된 개발 프로세스

• Code : 개발자가 코드를 작성
• Build : 작성한 코드를 바탕으로 도커 이미지 생성
• Ship : 생성 된 도커 이미지를 이미지 저장소에 저장 (Docker Hub, AWS ECR, Google Cloud GCR 등...)
• Run : 이미지 저장소에서 받은 이미지를 컨테이너로 실행

도커 컨테이너 사용의 증가

• 어떤 언어, 프레임워크인지 상관 없이 생성 된 도커 이미지만 있으면 동일하게 동작 시킬 수 있음
• 모든 어플리케이션들을 컨테이너화하기 시작 함
• 점점 관리해야 될 컨테이너가 증가
• 편해지긴 했지만, 여전히 관리해야 될 포인트가 지속적으로 늘어남

도커 그 이후

배포(Deployment)의 문제점

• 모든 서버에 직접 접속해서 docker stop, run을 실행 해줘야 함
• 모니터링 시스템 구축 등을 통해서 유휴 자원을 관리하며 도커 컨테이너가 실행 될 수 있는 리소스 관리가 필요
• 새롭게 배포 된 어플리케이션에 장애가 발생하여 롤백 시 신속하게 대처하기 힘듦

서비스 검색의 문제점

• 프록시 서버를 통해서 내부의 서비스에 접근할 때
• 부하 발생으로 인해 스케일 아웃을 해야 하는 경우 로드 밸런서 설정 등의 작업이 필요
• 마이크로 서비스의 경우 이러한 경우가 더욱 빈번하게 발생

서비스 노출의 문제점

• 프록시 서버를 통해서 내부의 서비스에 접근할 때
• 새롭게 서비스가 추가 될 때 마다 프록시 서버 설정 추가가 필요
• 서비스 검색의 문제점과 유사

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

• 장애가 발생한 컨테이너의 로그를 보고 직접 다시 실행하는 작업 필요
• 예상치 못한 시간에 발생한 부하에 대한 대응이 늦을 수 있음

컨테이너 오케스트레이션의 등장

• 이런 문제점들을 해결하기 위해 등장한 도구가 바로 컨테이너 오케스트레이션

컨테이너 오케스트레이션(Container Orchestration)

정의

• 복잡한 컨테이너 환경을 효과적으로 관리하기 위한 도구
• 서버 관리자의 역할을 대신 할 프로그램을 만드는 도구

특징 - 요구사항

클러스터 (Cluster)

• 중앙 제어 (master-node)
  • 기존에는 서버 관리자가 각 서버 스펙, 리소스 상태, 어플리케이션 구동 등을 체크
  • 관리해야 되는 컨테이너가 많아지면서 물리적인 관리 보다는 추상화 된 클러스터로 관리
  • 클러스터 관리를 위한 마스터 노드를 두고 마스터 노드가 클러스터에 명령을 내리는 방식
  • 관리자는 마스터 노드를 관리하는 것 만으로 클러스터를 관리할 수 있어야 함
• 네트워킹
  • 클러스터 내에서는 가상 네트워킹 등을 통해 노드 간에 네트워킹이 원활하게 이뤄져야 함
• 노드 스케일
  • 클러스터 내에 컨테이너가 무한히 증가 하더라도 관리가 가능해야 함

상태 (State) 관리

• 원하는 상태(예: 컨테이너 수량)를 설정하는 것 만으로 별도의 명령 없이 해당 상태로 변경될 수 있어야 함
• 장애로 인해 상태가 변경 된 경우 설정 된 상태를 유지하기 위한 명령이 자동 실행되어야 함

배포 관리 (Scheduling)

• 유휴 리소스를 관리하여 새로운 컨테이너 생성 시 알맞은 서버에 배치 시킬 수 있어야 함
• 추가 리소스가 필요 한 경우 리소스를 할당하여 컨테이너를 배치 시킬 수 있어야 함

배포 버전관리 (Rollout / Rollback)

• 배포 시 개별 배포가 아닌 중앙에서 자동 배포가 진행될 수 있어야 함
• 롤백의 경우에도 중앙에서 관리하며 일괄적으로 롤백이 진행될 수 있어야 함

서비스 등록 및 조회 (Service Discovery)

• 새로운 서비스가 추가 된 경우 자동으로 해당 서비스에 대한 설정이 추가 되어야 함
• 프록시 서버는 설정 저장소를 바라보며 설정이 변경 된 경우 프로세스 재시작을 통해 새 설정을 반영해야 됨

볼륨 스토리지 (Volume)

• 각 컨테이너 별 볼륨 관리를 추상적인 레벨에서 손쉽게 관리할 수 있어야 함

컨테이너 오케스트케이션의 구현체

• DEIS, RANCHER, MESOS, MARATHON, Nomad, Docker SWARM, Kubernetes
• 다양한 컨테이너 오케스트케이션 도구들의 춘추 전국 시대
• 그 중에서 Kubernetes가 de facto standard 처럼 치고 나오게 됨

참고

• Youtube - 44BITS | [초보를 위한 쿠버네티스 안내서] 컨테이너 오케스트레이션이란?