[AWS_Builders] Container Service

컨테이너가 각곽을 받게 된 것은 빠르게 변하는 시장에서 예측할 수 없는 고객의 요구사항에 기인한다. 

이런 환경에서 우리는 더욱 빠르고, 안정적이며 효율적인 시스템 구축이 필요했다. 

 

 

이러한 환경에서 비즈니스의 목표를 달성하기 위해서는 신뢰할수 있는 인프라 환경에서 애플리케이션 개발에만 집중할 수 있어야 하며, 고객의 트래픽에 따라 유연하게 대응할 수 있어야 한다. 

그리고 무엇보다 보안에 안전해야 한다. 

이러한 목표를 이루기 위해서 컨테이너 기술이 등장하게 되었다. 

 

우리가 애플리케이션을 개발할 때 생각해보면, 우리는 우선 비즈니스 로직을 코드로 구현해야 한다. 

그리고 데이터를 저장하고 사용하기 위해 데이터베이스를 활용하며 이를 연결하기 위한 환경변수들은 설정 파일로 분리한다. 

또한 코드 개발을 위해 여러가지 라이브러리와 프레임워크를 사용하게 되며, 이렇게 개발된 코드는 런타임을 통해 빌드되고 실행된다. 

 

 

개발자분들은 자신의 로컬환경에서 열심히 개발하고, 만들어진 결과물을 자유롭게 개발환경에서 테스트한다. 

그리고 나서 프로덕션과 유사하게 만들어 놓은 스테이징 환경에 배포를 하고, 검증단게를 거친 후에 프로덕션 환경 배포를 하고 있다. 

개발 초기에는 시스템 서비스를 위한 코드량이나 라이브러리 수가 많지 않을 수 있지만, 비즈니스가 성장하고 다양한 기능이 추가되면서 각각의 환경별로 다른 버전을 갖고 있는 경우가 많으며, 이로 인해 개발자 환경에서는 잘 실행되지만 스테이징 환경과 프로덕션 환경에서 정상적으로 동작하지 않아 많은 분들이 이를 해결하기 위해 고생하신 경험이 있을 것입니다. 

 

이러한 낭비 요소를 해결하는 방법이 없을까요?

 

 

컨테이너는 선박 안에 물건을 싣는 것처럼 앞서 말씀드린 애플리케이션 코드와 여러 의존성 라이브러리 그리고 런타임 엔진까지 모두 포함합니다. 

이렇게 컨테이너는 기존에 애플리케이션 구동을 위해서 필요한 설치 매뉴얼까지도 불필요하게 됩니다. 

또한 컨테이너는 격리된 자신만의 실행환경을 갖기 때문에 다른 컨테이너의 간섭을 받지 않게 됩니다. 

 

그리고 컨테이너는 기존의 가상머신과 다르게 개별 OS를 갖고 있지 않고, 호스트 OS를 공유하며 리눅스 커널의 cgroup, namespace 기술을 활용하여 격리된 환경을 구축한다. 

컨테이너는 별도의 OS를 위한 CPU, MEM 낭비 없이 오직 여러분의 애플리케이션에만 사용할 수 있어 효과적으로 리소스를 활용할 수 있다. 

또한 모든 환경에서 컨테이너 런타임만 있으면 즉시 실행이 가능하기에 애플리케이션의 빠른 실행환경을 구축하는데 효과적입니다. 

 

 

이렇게 컨테이너는 많은 이점을 가지고 있습니다. 

모든 환경에서 일관되게 보안을 향상할 수 있고, 인프라 자원과 관리 비용을 개선하며, 뛰어난 이식성을 통해 애플리케이션을 빠르게 개발하고 배포할 수 있습니다. 

그리고 AWS에서 제공하는 다양한 관리형 컨테이너 서비스를 활용해서 자동화된 검증환경을 통해 운영 부담은 줄이면서 안정적인 서비스를 구축할 수 있습니다. 

 

 

우선 컨테이너라는 용어를 좀 나누어서 생각해 볼 필요가 있는데요

컨테이너와 컨테이너 이미지가 있습니다. 

컨테이너 이미지는 앞서 애플리케이션의 구성요소를 한 개로 묶은 파일 시스템이고, 이런 컨테이너 이미지를 사용해서 컨테이너 런타임에서 실행된 프로세스가 컨테이너이다. 

따라서 우리가 컨테이너를 생성하기 위해서는 컨테이너 이미지를 먼저 만들어야 한다. 

그림에서 보시는 것과 같이 우분투 기반의 파이썬 애플리케이션을 실행하기 위해서 작성된 Dockerfile를 확인할 수 있다. 

그리고 간단하게 docker build 명령어를 사용해서 컨테이너 이미지를 생성할 수 있다. 

 

여기서 tip

컨테이너 이미지는 각각의 레이어로 구성된 파일시스템이며 이미지가 작을수록 빠르게 컨테이너를 실행할 수 있고, 리소스 자원도 효율적으로 사용할 수 있다. 

따라서 컨테이너 이미지를 사용할 때는 Dockerfile 상단에 FROM 절에 선언하는 base 이미지를 Alpine, Slim과 같은 작은 이미지를 사용하는 것을 추천한다. 

RUN 명령어는 && 연산자를 사용하여 불필요한 이미지 레이어를 만들지 않도록 하는 것이 효과적이다. 

또한 이미지 생성에 불필요한 라이브러리가 포함되지 않도록, 멀티스테이지 빌드를 활용하여 빌드할 때만 필요한 라이브러리를 제거하고, 애플리케이션 실행에 필요한 라이브러리만 포함할 수 있도록 작성하는 것이 컨테이너 이미지 사이즐르 줄이는데 효과적이다. 

 

 

이렇게 생성된 컨테이너 이미지를 컨테이너 레지스트리에 저장이 필요하다. 

컨테이너 이미지 저장소로 안전한 Amazon ECR을 사용한다. 

 

Amazon ECR은 완전 관리형 컨테이너 이미지 저장소이며 이미지가 저장되면 무료로 제공해 드리는 스캔 기능을 통해서 OS레벨의 CVE취약점을 진단할 수 있다. 

 

 

 

이렇게 생성된 컨테이너 이미지를 배포하고 실행할 수 있다. 

이제 우리는 컨테이너를 실행하는 환경인 AWS 클라우드 컨테이너 서비스에 대해서 살펴보도록 하자.

 

 

우선 컨테이너를 실행하고 운영할 수 있는 컨테이너 관리 서비스가 있으며, 서버의 구동 방식에 따라 여러분들의 환경에서 컨테이너를 직접 운영할 수 있는 서버 방식, 컨테이너가 실행되는 인프라 영역을 AWS에 맡기는 서버리스 방식이 있다. 

 

그럼 애플리케이션, 서비스의 요구사항과 워크로드에 가장 적합한 AWS 컨테이너 서비스를 선택하는 방법을 알아보겠습니다. 

 

 

처음부터 대규모의 컨테이너 서비스를 이용할 필요는 없다. 

애플리케이션, 서비스 특성과 제공하는 규모에 따라서 컨테이너 관리 서비스를 선택하면 되는데, 컨테이너 관리 서비스를 직접 구축하는 것 대신에 AWS 완전 관리형 서비스를 활용해서 운영 부담을 줄이고, 애플리케이션 개발에 집중해서 여러분의 서비스를 차별화 하시는 것을 추천한다. 

 

 

 

먼저 서비스를 제공하는 규모가 상대적으로 적으며, 단일 컨테이너를 사용하시는 경우에는 Lightsail과 Beanstalk 서비스를 추천한다. 

 

 

Lightsail은 컨테이너를 배포할 수 있는 기능이 추가되어 컨테이너 이미지를 추가하거나 설정할 수 있다. 

그리고 nginx, redis 서버가 기본적으로 포함되어 웹 애플리케이션을 즉시 배포할 수 있다. 

 

우리가 개발하고 운영하는 컨테이너의 수가 적고 관리할 서버, 인스턴스가 적은 경우에는 관리자가 직접 서버를 생성하고 컨테이너를 직접 실행해서 관리할 수가 있다. 

하지만, 

 

하지만, 애플리케이션, 서비스의 규모가 커지게 되면서 사용자가 많아지고 서비스 기능이 추가된다면 그에 비례하여 컨테이너 수도 증가하게 된다. 

그럼, 기존의 서버만 갖고 컨테이너를 운영하기 어려운 상황이 발생하게 된다.

 

 

컨테이너 수가 증가하게 되면 그 수에 비례하여 컨테이너를 실행하기 위한 서버 수도 증가하게 된다. 

또한, 고객의 요구사항을 빠르게 반영하고 배포하기 위해서 마이크로 서비스 아키텍처를 적용한다면, 각 마이크로 서비스마다 컨테이너를 실행하고 관리해야 할 것이며, 각각의 마이크로 서비스에 대한 네트워킹, 트래픽 밸런싱에 대한 운영이 필요하다. 

 

우리는 많은 서버 중에서 컨테이너를 어디에 배치해야 하고, 내부-외부 통신은 어떻게 구성해야 할까?

그리고 사용자 트래픽을 효율적으로 분산하고, 스케일링에 대한 고민도 필요하다. 

그리고 개발자들은 신규 애플리케이션이 다른 서비스에 영향이 없도록 배포를 하고 싶고, 운영자는 혹시 버전에 이슈가 있을 경우 즉시 롤백을 하고 싶습니다. 

그리고 운영자는 서비스 규모가 커지게 되면서 많은 서버, 다수의 컨테이너 관리를 수동으로 하기에는 너무 어렵다. 

 

이러한 요구사항을 해결하기 위해서 우리는 컨테이너 오케스트레이션 도구가 필요하게 되었다. 

 

컨테이너 오케스트레이션은, 오케스트라 연주에서 지휘자가 연주자들을 이끌어 조화로운 연주를 하는 것처럼,

우리의 애플리케이션, 컨테이너를 여러 서버들에 배포하고 관리를 자동화해 준다. 

 

클러스터와 컨테이너의 상태를 관리자가 원하는 대로 조정해 주는 컨트롤 플레인과, 

실제 애플리케이션, 서비스가 동작되고 컨테이너가 실행되는 영역인 데이터 플레인으로 구성되어 있다. 

 

AWS에서는 대표적으로 컨테이너 오케스트레이션을 제공하는 두 개의 서비스가 있다. 

가장 간편하지만 강력한 Amazon ECS와 오픈소스 쿠버네티스를 업스트림 버전으로 제공해서 유연하게 사용할 수 있는 Amazon EKS가 있다. 

 

이제 Amazon ECS, Amazon EKS 서비스에 대해서 살펴보자.

 

Amazon ECS의 가장 큰 장점은 강력하면서 심플하다는 것이다. 

Amazon ECS는 AWS에서 컨테이너화된 애플리케이션을 쉽게 배포하고 유연하게 확장할 수 있도록 지원하는 완전 관리형 컨테이너 오케스트레이션 서비스이다. 

또한 Amazon ECS는 AWS의 다양한 컨테이너 기반의 서비스에서도 실제로 사용되고 있다. 

그리고 AWS 서비스들과 긴밀하게 통합되어 사용할 수 있어 대규모 컨테이너를 운영할 때 많은 장점을 제공하고 있다. 

 

 

Amazon ECS 클러스터는 AWS 콘솔에서 몇 번의 버튼 클릭만으로 쉽게 생성할 수 있으며, 

또한 CloudFormation와 같은 코드로 생성하고 관리할 수 있다. 

 

여러분들의 애플리케이션이 실행되는 데이터 플레인을 구성하는 방식으로는 Amazon EC2 인스턴스 방식과 AWS Fargate 서버리스 방식이 있다. 

EC2 인스턴스는 여러분의 VPC 환경에서 생성되어 직접 운영과 관리를 할 수 있고, 

AWS Fargate는 AWS가 관리하는 인스턴스에 생성되어 컨테이너가 실행된다. 

 

따라서 우리는 Fargate를 이용하면 관리할 서버가 없기 때문에 편리하게 서비스를 구축하고 효율적으로 운영할 수 있다. 

 

 

Amazon ECS 구성요소는 ECS 클러스터와 ECS 서비스 그리고 ECS Task로 구성되어 있다. 

각각의 구성 요소들을 하나씩 살펴보자. 

 

우선 클러스터는 ECS의 작업, Task가 실행되는 논리적인 그룹이다.

태스크는 애플리케이션을 구성하는 하나 이상의 컨테이너로 구성되며, JSON 형식의 작업 정의 텍스트 파일을 통해서 생성할 수 있다. 

ECS 서비스는 ECS 클러스터에서 원하는 수의 태스크를 동시에 실행하고 유지할 수 있다. 

혹시 태스크가 어떤 이유로든 실패하거나 중지하면 Amazon ECS 서비스 스케줄러가 작업 정의에 따라 다른 인스턴스를 시작하는 방식으로 작동된다. 

 

이로써 서비스는 원하는 수의 태스크를 유지할 수 있다.