AWS Technical Essentials #2

컨테이너

AWS는 광범위한 컴퓨팅 제품을 통해 작업에 적합한 도구를 선택할 수 있는 유연성을 제공한다. 컴퓨팅의 3가지 주요 범주는 가상 머신(VM), 컨테이너, 서버리스인데, 모든 목적에 부합하는 컴퓨팅 서비스란 존재하지 않는다. 그렇기에 우리는 우리의 요구 사항에 맞춰 적합한 서비스를 선택해야 한다.

그러기 위한 핵심은 각 옵션이 무엇을 제공하는지 이해하는 것일 테다. 그러면 사용 사례에 적합한 클라우드 아키텍처를 구축할 수 있는 것이다. 컨테이너는 웹 애플리케이션, 리프트 앤 시프트 마이그레이션, 분산 애플리케이션, 개발, 테스트 및 프로덕션 환경의 간소화 등 다양한 워크로드를 호스팅할 수 있다다.

 

컨테이너는 한 컴퓨팅 환경에서 다른 컴퓨팅 환경으로 이동할 때 안정적으로 실행되도록 하는 문제를 비롯하여, 기존 컴퓨팅의 문제에 대한 해결책으로 사용된다. 컨테이너는 코드 및 해당 종속성을 패키징하는 표준화된 단위다. 이 패키지는 모든 플랫폼에서 안정적으로 실행되도록 설계되었다. 이유는, 컨테이너는 자체 독립 환경을 만들기 때문이다. 컨테이너를 사용하면 워크로드를 한 곳에서 다른 곳으로 옮길 수 있다. 그러니까 개발 환경에서 프로덕션 환경으로, 온프레미스 환경에서 클라우드로 말이다.

컨테이너화 플랫폼의 한 가지 대표적인 예시가 Docker인데, Docker는 네트워킹 및 스토리지를 포함하여 컨테이너 격리에 필요한 전체 운영 체제 스택의 관리를 단순화하는 인기 있는 컨테이너 런타임이다. Docker는 고객이 컨테이너를 생성, 패키징, 배포 및 실행하도록 지원한다.

 

VM과 컨테이너의 차이점

 

컨테이너는 컨테이너가 존재하는 호스트와 동일한 운영 체제와 커널을 공유한다. 그러나 가상 머신은 자체적으로 운영 체제를 포함하고 있다. 각 가상 머신은 운영 체제의 복사본을 유지 관리해야 하므로 리소스가 낭비되는 것이다.

그에 비하면, 컨테이너는 더 가볍다. 컨테이너는 더 빠르게, 거의 즉각적으로 가동된다. I/O 버스트 시 빠르게 확장해야 하는 애플리케이션을 설계할 때는 이 가동 시간의 차이가 매우 중요할 것이다.

 

그러니까 컨테이너는 빠른 속도를 제공하는 것에 특화되어 있고, 가상 머신은 운영 체제의 완전한 기능과 패키지 설치, 전용 커널 등의 더 많은 리소스를 제공하는 데에 이점이 있는 것이다.

 

컨테이너 오케스트레이션

AWS에서는 EC2 인스턴스에서 컨테이너를 실행할 수 있다. 예를 들어, 대규모 인스턴스 하나를 실행하면서 그 안에서 몇 개의 컨테이너를 실행할 수 있는 것이다. 하나의 인스턴스를 실행하는 것은 복잡하지 않지만, 고가용성 및 확장성은 부족할 것이다. 그래서 대부분의 기업과 조직에서는 몇 개의 가용 영역에 있는 여러 EC2 인스턴스에서 많은 컨테이너를 실행한다.

 

대규모로 컴퓨팅을 관리하려고 한다면, 인스턴스에 컨테이너를 배치하는 방법, 컨테이너가 실패할 경우 발생하는 상황, 인스턴스가 실패할 경우 발생하는 상황, 컨테이너의 배포를 모니터링하는 방법 등을 고려해야 할 것이다.

 

그리고 컨테이너 오케스트레이션 서비스가 이런 조정 작업을 처리할 수 있다. AWS는 Amazon ECS  Amazon EKS를 통해 컨테이너 오케스트레이션 서비스를 제공한다.

 

Amazon ECS로 컨테이너 관리

Amazon ECS는 새로운 컨테이너를 가동하는 데 도움이 되는 엔드 투 엔드 컨테이너 오케스트레이션 서비스다. Amazon ECS를 사용하면 서비스 내에서 개별 태스크나 여러 태스크를 실행하는 데 사용하는 태스크 정의에서 컨테이너가 정의된다. 그리고 AWS Fargate라는 다른 AWS 서비스에서 관리되는 서버리스 인프라에서 태스크와 서비스를 실행할 수 있는 옵션이 주어진다. 또한, 인프라의 보다 효과적 제어를 위해 사용자가 관리하는 EC2 인스턴스의 클러스터에서 태스크와 서비스를 실행할 수도 있다.

 

Amazon EC2 인스턴스의 클러스터에서 컨테이너를 실행하고 관리함으로써 더 많은 제어 권한을 가지는 방법을 선택하면, EC2 인스턴스에 Amazon ECS 컨테이너 에이전트를 설치해야 한다. 근데 이 컨테이너 에이전트가 설치된 EC2 인스턴스를 컨테이너 인스턴스라고 하는 경우가 많은데, 이 컨테이너 에이전트는 오픈 소스이며 클러스터 관리 세부 정보에 대한 Amazon ECS 서비스와의 통신을 담당한다. Linux와 Windows AMI 모두에서 에이전트를 실행할 수 있다. 

Amazon ECS 컨테이너 인스턴스가 실행되면, 컨테이너 시작 및 중지, 클러스터 상태 확인, 확장 및 축소, 클러스터 전체에서 컨테이너 배치 예약, 권한 할당, 가용성 요구 사항 충족 등의 작업을 수행할 수 있다.

 

애플리케이션이 ECS에서 실행되도록 준비하려면 태스크 정의를 생성해야 한다. 태스크 정의는 하나 이상의 컨테이너를 설명하는 JSON 형식의 텍스트 파일인데, 태스크 정의는 CPU, 메모리, 포트, 이미지, 스토리지, 네트워킹 정보 등 컨테이너를 실행하는 데 필요한 리소스를 설명하는 청사진과 유사하다고 할 수 있다.

 

Amazon EKS에서 Kubernetes 사용

Kubernetes는 컨테이너화된 워크로드 및 서비스를 관리하기 위한 이동 가능하고 확장 가능한 오픈 소스 플랫폼이다. 소프트웨어 개발과 운영을 통합하도록 설계된 Kubernetes는 빠르게 성장하는 에코시스템을 형성함으로써 많은 사용자의 픽을 받고 있다. 나도 이거 때문에 지금 프로젝트에서 얼마나 고생인지 모른다..

Kubernetes를 이미 사용하고 있다면 Amazon EKS를 사용하여 AWS 클라우드에서 워크로드를 오케스트레이션할 수 있다. Amazon EKS는 자체 Kubernetes 제어 플레인 또는 작업자 노드를 설치하고 운영하고 유지 관리할 필요 없이 AWS에서 Kubernetes를 실행하는 데 사용할 수 있는 관리형 서비스다. Amazon EKS는 개념상 Amazon ECS와 유사하지만, 다음과 같은 차이점이 있다. 그다지 중요한 내용은 아니다.

① Amazon ECS에서는 컨테이너를 실행하는 머신이 EC2 인스턴스이며, 이 인스턴스에 ECS 에이전트가 설치되어 있고, 컨테이너를 실행하고 관리하도록 구성되어 있다. 이 인스턴스를 컨테이너 인스턴스라고 하는 것이다. Amazon EKS에서는 컨테이너를 실행하는 머신을 작업자 노드 또는 Kubernetes 노드라고 부른다. 

② ECS 컨테이너는 태스크라고 부르는 반면, EKS 컨테이너는 파드라고 부른다.

③ Amazon ECS는 AWS 네이티브 기술에서 실행된다. 반면, Amazon EKS는 Kubernetes에서 실행된다. 

Kubernetes에서 컨테이너를 실행 중이고 단순성, 고가용성, 인프라에 대한 세분화된 제어를 제공할 수 있는 고급 오케스트레이션 솔루션을 원한다면 Amazon EKS가 적합한 도구가 될 수 있을 것이다.

 

서버리스

Amazon EC2에서 코드를 실행하면 AWS가 물리적인 하드웨어를 책임진다. 게스트 운영 체제, 보안 및 패치 적용, 네트워킹, 보안, 크기 조정 같은 논리적 제어는 우리가 책임져야 한다.

우리는 Amazon ECS와 Amazon EKS에서 컨테이너를 실행하고 관리하여 더 많은 제어 권한을 갖도록 선택할 수 있는데, 그렇게 하면 AWS는 여전히 컨테이너 관리의 더 많은 부분, 그러니까 예를 들면, EC2 인스턴스에 컨테이너를 배포하고 컨테이너 클러스터를 관리하는 부분을 책임지게 될 것이다. 그러나 Amazon EC2에서 Amazon ECS와 Amazon EKS를 실행하면 내가 여전히 기본 EC2 인스턴스를 유지 관리해야 할 것이다.

이런 부담스러븐 작업을 제거할 방법이 있을까? 그렇다면 서버리스인 것이다.

 

서버리스 컴퓨팅을 사용하면 가용성을 보장하고, 크기를 조정하고, 서버를 관리하는 데 시간을 할애하는 대신 애플리케이션을 차별화하는 작업에 시간을 할애할 수 있다. 서버리스를 쉽게 요약하면 다음과 같다.

 

① 이름 그대로, 프로비저닝하거나 관리할 서버가 없다.
② 사용량에 따라 크기가 조정된다.
③ 유휴 리소스에 대해서는 비용을 지불하지 않는다.
④ 가용성 및 내결함성이 내장되어 있다.

 

AWS Fargate를 통한 서버리스

 

Fargate는 EC2 인스턴스를 추상화하므로 우리가 기본 컴퓨팅 인프라를 관리할 필요가 없다. 그런데 Fargate를 사용하면 동일한 Amazon ECS 개념, API, AWS 통합을 모두 사용할 수 있다. Fargate는 IAM 및 Amazon VPC와 네이티브 통합을 지원한다. Amazon VPC와의 네이티브 통합을 통해 네트워크 내에서 Fargate 컨테이너를 시작하고 애플리케이션에 대한 연결을 제어할 수 있는 것이다.

 

AWS Fargate는 컨테이너용으로 특별히 구축된 서버리스 컴퓨팅 엔진인데, AWS Fargate가 인프라를 관리하고 크기를 조정하므로 개발자는 가장 잘할 수 있는 애플리케이션 개발 작업에 집중할 수 있다. 이런 장점은 적절한 양의 컴퓨팅을 할당하기 때문에 가능한 것이다. EC2 인스턴스, 클러스터 용량, 크기 조정을 선택하고 관리할 필요가 없어지는 것이다. 또한, Fargate는 Amazon ECS 및 Amazon EKS 아키텍처를 모두 지원하며, 워크로드 격리와 향상된 보안을 제공하도록 설계되었다.

 

AWS Lambda를 통한 서버리스

EC2 인스턴스 또는 컨테이너를 하나도 관리하지 않고 워크로드와 애플리케이션을 배포하고 싶다면? Lambda를 사용하면 된다.

 

Lambda를 사용하면 서버를 프로비저닝하거나 관리할 필요 없이 코드를 실행할 수 있다. 사실상 거의 모든 유형의 애플리케이션 또는 백엔드 서비스에 대해 코드를 실행할 수도 있다. 예를 들면 데이터 처리, 실시간 스트림 처리, 기계 학습, WebSockets, IoT 백엔드, 모바일 백엔드, 직원 디렉터리 애플리케이션과 같은 웹 애플리케이션에 대해 코드를 실행할 수 있는 것이다.

Lambda는 가용성이 높은 컴퓨팅 인프라에서 코드를 실행하며 사용자가 관리할 필요가 없다. Lambda에서 지원하는 언어 중 하나로 소스 코드만 업로드하면 높은 가용성으로 코드를 실행하고 크기를 조정하는 데 필요한 모든 것을 Lambda가 처리한다. 물론, 관리해야 할 서버도 없다. 1초보다 작은 단위로 요금이 측정되고 일관적인 성능을 발휘하며, 지속적으로 크기가 조정되기도 한다.

 

Amazon VPC

Virtual Private Cloud(VPC)는 데이터 센터의 기존 네트워크와 유사하게 AWS 클라우드에서 생성하는 격리된 네트워크다. Amazon VPC를 생성할 때 3개의 주요 요소를 선택해야 한다.

① VPC의 이름 ② VPC가 상주할 리전 : VPC는 선택한 리전의 모든 가용 영역에 걸쳐 있다.③ CIDR 표기법으로 표기한 VPC의 IP 범위 : 이 범위가 네트워크의 크기를 결정한다. 각 VPC에는 최대 5개의 CIDR이 있을 수 있다. 기본 범위 1개, IPv4의 보조 범위 4개로 말이다.

 

AWS는 이 정보를 사용하여 네트워크 및 해당 네트워크에 대한 IP 주소를 프로비저닝한다.

 

서브넷 생성

VPC를 생성한 후에는 네트워크 내부에서 서브넷을 생성해야 한다. 서브넷은 기본 네트워크 내부의 소규모 네트워크 또는 기존 온프레미스 네트워크의 가상 로컬 영역 네트워크(VLAN)로 간주된다. 온프레미스 네트워크에서 서브넷의 일반적인 사용 사례는 네트워크 트래픽을 격리 또는 최적화하는 것이다. AWS에서 서브넷은 리소스에 고가용성과 연결성 옵션을 제공하는 데 사용되는데, 인터넷에 연결되어야 하는 리소스에는 퍼블릭 서브넷을 사용하고, 인터넷에 연결되지 않는 리소스에는 프라이빗 서브넷을 사용해야 한다.

서브넷을 생성할 때는 다음 사항을 지정해야 한다.
① 서브넷이 상주할 VPC
② 서브넷이 상주할 가용 영역
③ 서브넷의 IPv4 CIDR 블록

 

서브넷을 생성할 때 고가용성을 염두에 두어야 한다. 중복성과 내결함성을 유지하기 위해 2개의 가용 영역에 구성된 서브넷을 2개 이상 생성하는 것이다. 

 

예약된 IP

AWS에서 VPC를 적절하게 구성하기 위해 AWS는 각 서브넷에 5개의 IP 주소를 예약한다. 이러한 IP 주소는 라우팅, 도메인 이름 시스템(DNS) 및 네트워크 관리에 사용된다.

예를 들어 IP 범위가 10.0.0.0/22인 VPC가 있다면, 이 VPC에는 총 1,024개의 IP 주소가 포함된다. 이 VPC는 동일한 크기의 서브넷 4개로 나뉘며, 각 서브넷에는 256개의 IP 주소가 포함되는 /24 IP 범위가 할당된다. AWS에서 5개를 예약하므로 각 IP 범위에서 251개의 IP 주소만 사용할 수 있을 것이다.

 

5개의 예약된 IP 주소는 네트워크 설계 방식에 영향을 줄 수 있다. 클라우드를 처음 사용하는 경우 일반적으로 IP 범위가 /16인 VPC를 만들고 IP 범위가 /24인 서브넷을 만드는 데서 출발할 것이다. 그리고 그렇게 하면 VPC 및 서브넷 수준 모두에서 사용할 수 있는 IP 주소가 다수 제공된다.

 

게이트웨이

VPC에서 인터넷 연결을 활성화하려면 인터넷 게이트웨이를 생성해야 한다. 게이트웨이는 모뎀과 비슷한 느낌이다. 모뎀이 컴퓨터를 인터넷에 연결하는 것처럼 인터넷 게이트웨이는 VPC를 인터넷에 연결하는 것이다. 때로 다운되거나 오프라인으로 전환되는 모뎀과 달리, 인터넷 게이트웨이는 가용성과 확장성이 뛰어나다는 이점이 있다

가상 프라이빗 게이트웨이의 경우, VPC를 다른 프라이빗 네트워크에 연결한다. 가상 프라이빗 게이트웨이를 생성하여 VPC에 연결할 때 게이트웨이가 연결의 AWS 측에서 앵커 역할을 한다. 연결의 다른 쪽에서는 고객 게이트웨이를 나머지 프라이빗 네트워크에 연결해야 한다. 고객 게이트웨이 디바이스는 연결을 위해 고객 측에 설치된 물리적 디바이스 또는 소프트웨어 애플리케이션이다. 두 게이트웨이가 모두 있으면 양측 사이에 암호화된 가상 프라이빗 네트워크(VPN) 연결을 설정할 수 있다.

 

AWS Direct Connect

온프레미스 데이터 센터와 Amazon VPC 간에 물리적 보안 연결을 설정하려는 경우, AWS Direct Connect를 사용할 수 있다. AWS Direct Connect를 사용하면 표준 이더넷 광섬유 케이블을 통해 고객의 내부 네트워크가 AWS Direct Connect 위치에 연결된다. 이 연결을 사용하여 퍼블릭 AWS 서비스 또는 고객의 VPC에 직접 가상 인터페이스를 생성할 수 있는 것이다.

 

기본 라우팅 테이블

VPC를 생성할 때 AWS는 기본 라우팅 테이블이라는 라우팅 테이블을 생성한다. 라우팅 테이블은 네트워크 트래픽이 전달되는 위치를 결정하는 데 사용되는 라우팅이라는 규칙 집합을 포함한다. 서브넷을 포함하여 새 VPC를 생성할 경우, AWS는 우리가 해당 서브넷 간에 트래픽을 전송하기를 원하는 것이라고 받아들이게 된다. 따라서 기본 라우팅 테이블의 기본 구성은 로컬 네트워크의 모든 서브넷 간의 트래픽을 허용하는 것이다. 이때, 다음 규칙이 기본 라우팅 테이블에 적용된다.

① 기본 라우팅 테이블은 삭제할 수 없다.
② 게이트웨이 라우팅 테이블을 기본 라우팅 테이블로 설정할 수 없다.
③ 기본 라우팅 테이블을 사용자 지정 서브넷 라우팅 테이블로 교체할 수 있다.
④ 기본 라우팅 테이블에서 라우팅을 추가, 제거, 수정할 수 있다.
⑤ 서브넷이 기본 라우팅 테이블과 암시적으로 연결되어 있더라도 명시적으로 연결할 수 있다.

 

사용자 지정 라우팅 테이블

기본 라우팅 테이블은 명시적 라우팅 테이블 연결이 없는 서브넷이 암시적으로 사용한다. 그러나 트래픽이 VPC 외부의 리소스에 액세스하도록 서브넷별로 다른 라우팅을 제공하고 싶을 수도 있지 않은가? 예를 들어, 애플리케이션이 프런트엔드와 데이터베이스로 구성되었다면 리소스에 대해 별도의 서브넷을 생성하고 각기 다른 라우팅을 제공할 수 있다.

사용자 지정 라우팅 테이블을 서브넷과 연결하면 서브넷이 기본 라우팅 테이블 대신 사용자 지정 라우팅 테이블을 사용한다. 생성하는 각 사용자 지정 라우팅 테이블에는 이미 로컬 라우팅이 포함되어 VPC 내의 모든 리소스와 서브넷 간에 통신 흐름을 허용한다. 새로운 각 서브넷을 사용자 지정 라우팅 테이블과 명시적으로 연결하고, 기본 라우팅 테이블은 원래의 기본 상태로 두어 VPC를 보호할 수 있다.