컨테이너
다른 프로세스와 격리된 상태로 OS 에서 소프트웨어를 실행하는 기술
컨테이너에서 실행되는 소프트웨어는 하나의 프로세스처럼 보이지만, 내부에서 보면 각자 독립된 OS 환경을 점유하고 있는 것 처럼 보임
서버 가상화
하이퍼바이저를 이용해 CPU, 메모리, 디스크 등의 자원을 에뮬레이트하여 여러 OS 를 하나의 하드웨어를 실행하는 기술이다. 이렇게 가상으로 만드어진 하드웨어 자원을 "가상 머신" 이라고 하고 그 위에서 동작하는 OS 는 "게스트 OS" 라고 한다. 서버 가상화는 게스트 OS 별로 커널을 점유한다.
컨테이너와 가상화
컴퓨터 자원을 가상화해서 취급한다는 점에서는 같지만, 분리되는 계층과 그에 따른 점유 자원이 다르다.
서버 가상화의 경우는 가상 머신 단위로 분리되고 각 가상 머신마다 하나의 커널을 가지고 있다. 컨테이너는 각자가 컨테이너 엔진 위에 하나의 애플리케이션인 형태로 존재하며 하나의 커널을 공유한다.
컨테이너의 장점
- 환경 의존에서 해방
컨테이너는 애플리케이션의 기동에 필요한 런타임 및 라이브러리를 하나의 패키지로 묶을 수 있어서 애플리케이션의 의존 관계를 컨테이너 안에 집약할 수 있다. 때문에 환경별로 어떤 패키지를 사용해야 할지 신경 쓰지 않아도 된다. - 환경 구축 및 테스트에 필요한 시간 감소
컨테이너의 장점 중 하나는 재현성과 이동성입니다. 모든 의존 관계가 컨테이너 안에서 완결되어 로컬이나 온프레미스, 클라우드에서도 동일하게 동작하는 것을 보장받는다. 애플리케이션의 배포나 마이그레이션에 관한 업무가 단순해지고 구축도 간단해진다. - 자원 효율
서버 가상화는 가상 머신 수준에서 자원을 분리하고 게스트 OS 에서 애플리케이션이 실행된다. 때문에 게스트 OS를 작동시키기 위한 컴퓨팅 자원이 필요하다. 하지만 컨테이너는 프로세스 수준에서 분리되기 때문에 서버 가상화와 비교하면 컨테이너에서는 게스트 OS 와 하드웨어 에뮬레이터를 하지 않아도 되기 때문에 애플리케이션을 실행하기 위한 자원의 소비가 적고 프로세스 단위로 동작하기 때문에 애플리케이션의 기동도 빨라서 애플리케이션을 빠르게 배포할 수 있다.
도커
컨테이너 라이프사이클을 관리하기 위한 플랫폼, 도커를 이용하면 애플리케이션을 컨테이너 이미지로 빌드하거나 이미지 저장, 컨테이너의 기동을 간단하게 수행할 수 있다.
컨테이너의 work flow 는 대강 아래와 같다.
1. Build - 애플리케이션 소스 코드와 해당 애플리케이션이 의존하고 있는 라이브러리, 베이스 OS 를 가지고 패키징한다.
2. Ship - 빌드된 이미지 파일을 Registry 에 업로드한다.
3. Run - Registry 에 업로드 된 이미지를 가져와서(로컬, 온프레미스, 클라우드 등) 컨테이너를 실행한다.
다음은 도커에서 사용하는 기본적인 용어이다.
- DockerFile
이미지를 생성하기 위한 텍스트 파일이다. 해당 파일을 작성하여 애플리케이션에 필요한 라이브러리를 설치하거나 컨테이너의 환경 변수를 지정할 수 있다. - 이미지
컨테이너를 실행하기 위해서 빌드된 패키지 - 태그
이미지에 할당된 라벨, 이미지 버전 관리 용도로 사용된다. - 레지스트리(Registry)
이미지를 보관할 수 있는 서비스, 공개된 Public Repository(ex: DockerHub) 혹은 특정 조직 혹은 팀에서만 접근이 가능한 Private Repository(ex: AWS ECR) 로 구분된다. - 컨테이너
이미지로부터 생성된 실행 주체, 애플리케이션 및 그에 관련된 라이브러리 등을 포함한 형태로 실행된다.
컨테이너를 다루기 위한 몇 가지 도커 명령어가 있지만 그것은 내용이 너무 방대하여... 필요할 때 검색하는 방식을 취하는 편이 좋을 것 같다.
오케스트레이터
단일 컨테이너를 가동하는 것이라면 지금까지 배운 내용으로 어느 정도의 애플리케이션을 운용할 수 있다. 하지만 시스템의 규모가 커지고 여러 컨테이너를 연계해야 하는 경우라면 어떻게 해야 할까?
여러 컨테이너를 가동하기 위해서 단일 호스트가 아닌 여러 호스트로 이루어진 클러스터 구성을 해야 하고 이렇게 분산된 환경에서의 부하 분산, 다운 타임을 최소화 할 수 있는 업데이트 방법을 고려, 장애 발생시 탐지 및 복구와 같이 안정된 환경을 만들기 위해서 많은 것을 고려해야 한다.
위와 같은 과제들을 해결하기 위해서 등장한 것이 오케스트레이터 라고 하는 컨테이너 그룹을 관리하는 서비스이다.
오케스트레이터는 다음과 같은 관리를 수행할 수 있다.
- 컨테이너 배치
클러스터 구성을 전제로 신규 컨테이너를 기동한 경우 각 컨테이너가 균등하게 부하를 주도록 분산 배치하는 것이 바림직하다. - 컨테이너 부하 분산
처리량에 따라 요청을 분산하여 가용성 좋은 시스템을 만들어 성능을 높일 수 있다.
부하를 분산하기 위해 컨테이너를 같은 그룹으로 만들어 적절하게 요청을 나눠주어야 한다.
보통 오케스트레이터와 로드밸런서를 조합하여 많이 사용한다. - 컨테이너 상태 감시 및 자동 복구
컨테이너의 상태를 감시하여 이상 발생을 탐지하고 문제가 발생한 컨테이너 분리와 자동 복구를 수행할 수 있어서 유지 및 서비스를 안정적으로 가져갈 수 있다. - 컨테이너 배포
애플리케이션을 새로운 버전으로 업데이트 하는 경우 현재 서비스 중인 컨테이너를 정지하고 새로운 것으로 교체해야 한다. 오케스트레이터를 활용하면 서비스 중인 상태로 컨테이너를 교체할 수 있다.
대표적인 컨테이너 오케스트레이션 툴로 쿠버네티스(Kubernetes) 와 스웜(Swarm) 등이 존재한다.
클라우드 서비스에서는 쿠버네티스를 기반으로 한 매니지드 서비스를 제공하고 있는데 AWS EKS, GCP GKE, AZURE AKS 가 대표적인 예시이다.
컨테이너를 도입하기 전 고려사항
컨테이너, 도커, 오케스트레이터는 애플리케이션의 실행 환경 의존을 해결하는 것에서 보면 상당히 매력적인 기술이지만, 사전에 검토해야 할 사항이 몇 가지 존재한다.
- 컨테이너 전제 애플리케이션 개발 방법
클라우드에서의 컨테이너를 사용한 애플리케이션의 개발 방법론 중 하나인 Twelve-Factor App 이다. 이 방법론은 모던 애플리케이션 개발에 대한 12가지의 방법론을 정의하고 있는데 그 중 종속성과 빌드, 배포, 실행(Build, Release, Run) 등을 신경을 쓰면 클라우드 구성에 친숙해질 수 있다. - 컨테이너 설계 및 운용
컨테이너를 새로 도입하면 퍼블릭/프라이빗 저장소에 저장된 이미지들의 관리 및 보호와 같은 새로운 운용 방법등이 등장한다. 또한 빌드 -> 배포까지의 흐름과 오케스트레이션의 제어, 정의 등도 필요하다. - 개발팀 역할 분담
시스템 운용에서 인프라와 관련된 전문성이 많이 요구되기 때문에 개발팀과 인프라팀으로 나눠서 업무를 진행하는 경우를 볼 수 있다. 개발팀은 애플리케이션 개발에 주력하고 컨테이너 기술 도입을 시작으로 클라우드 네이티브 개발을 하기 시작하면 IaC (Infrastructure as Code) 를 이용한 클라우드 자원 구축과 같이 인프라팀에서도 코드를 직접 짜게되는 기회가 생긴다.
AWS 컨테이너 설계와 구축 입문 - 아라이 마사야, 우마카츠 아츠시
Twelve-Factor App - https://12factor.net/ko/
