Transit Gateway

Transit Gateway는 스포크 역할을 하는 연결된 모든 네트워크 간에 트래픽이 라우팅되는 방식을 제어하는 허브 역할을 합니다. 이 허브 및 스포크 모델은 각 네트워크에서 기타 모든 네트워크에 연결할 필요 없이 Transit Gateway에만 연결하면 되므로 관리를 크게 단순화하고 운영 비용을 크게 줄여줍니다. 새로운 VPC를 Transit Gateway에 연결하면 연결된 다른 몯느 네트워크에서 자동으로 해당 VPC를 사용할 수 있습니다.

Transit Gateway를 통한 라우팅은 3 계층에서 작동하며, 패킷은 대상 IP 주소에 따라 특정 다음 홉 연결로 전송됩니다. Transit Gateway는 Transit Gateway 라우팅 테이블을 사용하여 연결 간에 인터넷 프로토콜 버전 4(IPv4) 및 인터넷 프로토콜 버전 6(IPv6) 패킷을 라우팅합니다. 연결된 VPC 및 VPN 연결에 대한 라우팅 테이블에서 라우팅을 전파하도록 테이블을 구성합니다. Transit Gateway 라우팅 테이블에 정적 라우팅을 추가할 수 있습니다.

Transit Gateway는 VPC와 온프레미스 네트워크를 상호 연결하는 데 사용할 수 있는 네트워크 전송 허브로, 트래픽에 따라 탄력적으로 크가기 조정됩니다.

상세

네트워크 크기 조정

Transit Gateway는 클라우드 라우터 역할을 하므로 네트워크 아키텍처가 단순화됩니다. 네트워크 확장 시 증가하는 연결 관리로 인한 복잡성이 발생하지 않습니다. 글로벌 애플리케이션을 구축하는 경우 리전 간 피어링을 사용하여 Transit Gateway를 연결할 수 있습니다.

Transit Gateway Network Manager를 사용하면 중앙 콘솔에서 VPC 및 엣지 연결을 모니터링할 수 있습니다. 주요 SD-WAN(Software-Defined Wide Area Network) 디바이스와 통합되므로 TGNM를 사용하여 글로벌 네트워크에서 문제를 실별할 수 있습니다.

VPC와 Transit Gateway 간의 트래픽은 AWS의 글로벌 프라이빗 네트워크에서 유지되며 퍼블릭 인터넷에 노출되지 않습니다. Transit Gateway 리전 간 피어링은 모든 트래픽을 암호화합니다. 단일 장애 발생 지점 또는 대역폭 병목 없이 DDoS 공격을 비롯한 일반적인 공격으로부터 보호해 줍니다.

구성 요소

Transit Gateway의 중요한 두 가지 구성 요소는 연결과 라우팅 테이블입니다.

연결(Attachment)

Transit Gateway Attachment는 패킷의 원본이자 대상입니다. 다음 리소스 중 하나 이상의 Transit Gateway와 동일한 리전에 있을 경우 연결할 수 있습니다.

• VPC
• VPN 연결
• Direct Connect Gateway
• Transit Gateway Connect
• Transit Gateway 피어링 연결

VPN 연결과 Direct Connect 게이트웨이를 사용하여 온프레미스 데이터 센터를 Transit Gateway에 연결할 수 있습니다. 이를 사용하면 AWS 클라우드 내 VPC에 연결할 수 있고 하이브리드 네트워크가 생성됩니다.

Transit Gateway에는 기본 라우팅 테이블이 있으며, 다른 라우팅 테이블도 선택적으로 포함할 수 있습니다. 라우팅 테이블에는 패킷의 대상 IP 주소에 따라 다음 홉을 결정하는 동적 및 정적 경로가 포함되어 있습니다. 이러한 경로의 대상은 모든 Transit Gateway Attachment일 수 있습니다. 기본적으로 Transit Gateway Attachment는 기본 Transit Gateway 라우팅 테이블과 연결됩니다.

각 연결은 정확히 하나의 라우팅 테이블과 연결됩니다. 각 라우팅 테이블은 0개 이상의 연결과 연결될 수 있습니다.

* 연결을 연결한다는 이상할 수 있는 소리를 적어놓은 것 같지만, 명사와 동사로 구분해주시면 감사하겠습니다...

Transit Gateway 설정

Transit Gateway는 여러 AWS 계정에서 작동합니다. AWS Resource Access Manager를 사용하여 Transit Gateway를 다른 계정과 공유할 수 있습니다. Transit Gateway를 다른 AWS 계정과 공유하면 계정 소유자는 자신의 VPC를 Transit Gateway에 연결할 수 있습니다. 두 계정의 사용자는 언제든지 연결을 삭제할 수 있습니다.

Transit Gateway 연결은 패킷의 원본이자 대상입니다. 다음 리소스를 Transit Gateway에 연결할 수 있습니다.

• 하나 이상의 VPC
• 하나 이상의 VPN 연결
• 하나 이상의 Direct Connect Gateway
• 하나 이상의 Transit Gateway 피어링 연결

Transit Gateway 피어링 연결하는 경우 Transit  Gateway는 다른 리전에 있어야 합니다. Transit Gateway는 연결된 VPC와 VPN 연결 간의 동적 및 정적 라우팅을 지원합니다. 각 연결에 대해 경로 전파를 설정 또는 해제할 수 있습니다.

상세

Transit Gateway를 통해 모든 VPC를 연결하거나 격리할 수 있으며, 일부 VPC 끼리만 연결하는 등 다양한 연결 방법이 있습니다.

Site to Site(S2S) VPN

S2S VPN 연결에서는 VPN 터널 2개가 제공됩니다. 이러한 터널은 AWS 측의 가상 프라이빗 게이트웨이나 Transit Gateway와 온 프레미스 측의 고객 게이트웨이를 연결합니다. S2S VPN의 특징은 다음과 같습니다.

• 가상 프라이빗 게이트웨이는 S2S VPN 연결의 AWS 측에 있는 VPN 집선기입니다.
• 한 VPN 연결의 VPN 터널이 서로 다른 가용 영역에서 종료됩니다.
• 고객 게이트웨이는 AWS에서 고객이 생성하는 리소스입니다. 온프레미스 네트워크의 고객 게이트웨이 디바이스를 나타냅니다. 네트워크 관리자가 원격 네트워ㅋ에서 고객 게이트웨이 디바이스 또는 애플리케이션을 구성합니다. AWS는 고객에게 필요한 구성 정보를 제공합니다.
• 고객 게이트웨이 장치의 기능에 따라 정적 라우팅 또는 동적 라우팅을 선택합니다. 동적 라우팅 옵션은Border Gateway Protocol(BGP)를 사용하여 자동으로 경로를 탐색합니다.

고객 게이트웨이 디바이스는 트래픽을 생성하고 Internet Key Exchange) 협상 프로세스를 시작하여 S2S VPN 연결을 위한 터널을 표시해야 합니다. 고객 게이트웨이를 생성할 때 디바이스에 대한 정보를 AWS에 제공합니다.

상세

Direct Connect

Direct Connect는 표준 이터넷 광 케이블을 통해 내부 네트워크를 Direct Connect 로케이션에 연결합니다. 케이블의 한쪽 끝은 사용자의 라우터에 연결되고 다른 쪽 끝은 Direct Connect 라우터에 연결됩니다. 이러한 방식을 교차 연결이라고 합니다. 이 연결을 구성하면 네트워크 경로에서 인터넷 서비스 공급자(ISP)를 우회하여 퍼블릭 AWS 서비스 또는 VPC에 직접 가상 인터페이스를 생성할 수 있습니다.

데이터 센터에서 교차 연결 생성 프로세스를 시작하려면 Letter of Authorization and Connecting Facility Assignment(LOA-CFA)가 필요합니다.

위 예시에서는 온프레미스 데이터 센터에 고객 게이트웨이 디바이스가 있습니다. 데이터 센터에서는 라우터가 있는 고객 케이지로 트래픽이 전달됩니다. 고객 케이지는 AWS 케이지의 AWS 라우터로 트래픽을 전송합니다. AWS 클라우드에서 가상 프라입시 게이트웨이는 AWS 백본을 통해 트래픽을 수신하여 온프레미스 데이터 센터를 VPC에 연결합니다. 이 연결이 설정되면 VPC에서 경로를 생성할 수 있습니다. 그러면 온프레미스 데이터 센터와 VPC의 프라이빗 서브넷 간 트래픽 흐름이 허용됩니다.

Direct Connect 로케이션에서 해당 로케이션과 연결된 리전의 AWS에 액세스할 수 있습니다. 퍼블릭 리전 또는 AWS GovCloud(미국)의 단일 연결을 사용하여 다른 모든 퍼블릭 리전 의 퍼블릭 AWS 서비스에 액세스할 수 있습니다.

Dircet Connect 로케이션에서 Direct Connect를 사용하기 위해 네트워크가 다음 조건 중 하나를 만족해야 합니다.

• 네트워크가 기존 Direct Connect 로케이션과 공동 배치되어 있습니다.
• Direct Connect 파트너와 협렵합니다.
• 독립 서비스 공급자와  협력하여 Direct Connect에 연결합니다.

상세

요금

1. Direct Connect 요금 정책 시에 사용되는 요인

• 용량
  네트워크 연결을 통해 데이터를 전송할 수 있는 최대 속도입니다. AWS Direct Connect 연결의 용량은 초당 Mbps 또는 초당 Gbps 단위로 측정됩니다.
• 포트 시간
  AWS 사용을 위해 포트가 프로비저닝되는 시간을 측정한 값입니다. AWS Direct Connect 위치 내에 있는 AWS Direct Connect 제공 파트너의 네트워킹 장비에서 측정한 값일 수도 있습니다. 포트를 통해 전달되는 데이터가 없어도 포트 시간 요금은 부과됩니다. 포트 시간 요금은 연결 유형(전용/호스트 연결)에 따라 결정됩니다.
• 데이터 송신(DTO)
  AWS Direct Connect를 통해 AWS 외부의 대상 위치로 전송되는 네트워크 트래픽의 누적 양을 지칭합니다. DTO 요금은 GB 단위로 부과됩니다. 그리고 용량 측정값과는 달리 DTO는 전송되는 데이터의 '속도'가 아닌 '양'입니다. DTO 계산 시 정확한 요금은 사용 중인 Direct Connect 로케이션과 리전에 따라 달라집니다.

2. Site to Site VPN 요금 정책

사용하는 연결의 시간당 연결 요금이 부과되며 Direct Connect와 마찬가지로 DTO 요금도 부과됩니다. S2S 사용 시 처음 데이터 전송 100GB는 무료입니다.

Direct Connect 요금 / S2S VPN

선택 기준

하이브리드 연결 요구를 가장 효율적으로 충족하는 제품을 선택하는 것이 좋습니다. 사용 사레에 따라 S2S VPN이나 Direct Connect 중 하나 또는 두 가지를 모두 선택할 수 있습니다.

1. S2S VPN (최대 전송 속도 1.25Gbps)

• 온 프레미스 네트워크와 VPC 간의 네트워크 연결을 빠르게 설정하는 방법이 필요한 경우
• 가용 예산이 많지 않은 경우
• 전송 데이터를 암호화해야 하는 경우

2. Direct Connect (연결 옵션 1/10/100 Gbps)

• AWS S2S VPN에서 제공할 수 있는 것보다 빠른 연결 옵션이 필요한 경우
• Direct Connect를 지원하는 공동 배치를 이미 사 용중인 경우
• 네트워크 성능을 예측할 수 있어야 하는 경우

VPC 피어링

비즈니스 또는 아키텍처 규모가 충분히 커지게 되면 보안 또는 아키텍처 측면의 필요를 위해 또는 단지 단순성을 위해 논리적 요소를 분리해야 합니다.

VPC 피어링 연결은 두 VPC 간에 일대일 관계입니다. 두 VPC 간에 하나의 피어링 리소스만 가질 수 있습니다. 소유한 각 VPC에 대해 여러 VPC 피어링 연결을 생성할 수 있습니다.

VPC 피어링 관련 제한 사항 및 규칙은 다음과 같습니다.

• VPC 당 사용할 수 있는 활성 및 보류 VPC 피어링 연결의 수에는 제한이 있습니다.
• 동일한 2개의 VPC 간에는 하나의 VPC 피어링 연결만 생성할 수 있습니다.
• VPC 피어링 연결에서 MTU(최대 전송 단위)는 1,500 byte 입니다.

다중 VPC 피어링 연결

위 예시에서 A와 B, B와 C가 피어링 되어있습니다. 이러한 피어링이 A와 C가 통신할 수 있다는 의미는 아닙니다. 피어로 명시적으로 설정되지 않는 한 기본적으로 VPC 피어링은 A가 C에 연결하도록 허용하지 않습니다. 서로 통신할 수 있는 VPC는 고객이 제어합니다.

소유한 각 VPC에 대해 여러 개의 VPC 피어링 연결을 생성할 수 있지만, 전이적 피어링 관계는 지원되지 않습니다. 직접 피어링 되지 않은 VPC와는 피어링 관계를 갖지 않습니다. 자체 VPC 간의 VPC 피어링 연결, 또는 단일 리전 내에 있는 다른 AWS 계정에서 VPC와의 VPC 피어링 연결을 만들 수 있습니다.

이점

VPC 피어링을 사용해 여러 VPC를 연결하는 경우 다음과 같은 이점이 있습니다.

• 인터넷 게이트웨이 또는 가상 게이트웨이를 우회할 수 있습니다. VPC 피어링을 사용하면 환경 내에 다른 가상 어플라이언스가 필요 없이 둘 이상의 네트워크를 빠르게 연결할 수 있습니다.
• 고가용성 연결을 사용할 수 있습니다. VPC 피어링 연결은 기본적으로 중복됩니다. AWS에서 연결을 관리합니다.
• 대역폭 병목 현상을 방지할 수 있습니다. 모든 리전 간 트래픽은 암호화되며 단일 장애 지점 또는 대역폭 제한이 없습니다. 트래픽은 항상 글로벌 AWS 백본에서 유지되며 퍼블릭 인터넷을 통해 전송되지 않습니다. 이러한 구성 방식으로 인해 흔히 발생하는 공격과 DDoS(Distributed Denial-of-Servuce) 공격 등의 위협이 줄어듭니다.
• 프라이빗 IP 주소를 사용해 트래픽을 전송할 수 있습니다. VPC 피어링 트래픽은 프라이빗 IP 공간 내에 유지됩니다.

예시

위 예시에서는 각 VPC와 공유할 수 있는 공유 서비스 VPC가 있습니다. 이 VPC를 사용해 리소스가 App1, 2 VPC 각각에 있는 서비스에 연결할 수 있습니다.

뿐만 아니라 다른 리전에 있는 VPC와의 VPC 피어링 연결이 표시되어 있는데, 리전 간 VPC 피어링을 사용하면 서로 다른 리전에서 실행되는 VPC 리소스가 프라이빗 IP 주소를 사용하여 서로 통신할 수 있습니다. 리전 간에 트래픽을 전송하기 위해 게이트웨이, VPN 연결 또는 별도의 물리적 하드웨어를 사용할 필요가 없습니다.

VPC 피어링을 사용하여 각 VPC를 조직 내의 다른 모든 VPC에 연결하면 풀 메시 네트워크 디자인을 생성할 수 있습니다.

이 아키텍처에서 각 VPC는 통신이 승인된 각 VPC와 일대일 연결이 있어야 합니다. 이 요구 사항이 적용되는 이유는 각 VPC 피어링 연결이 성격상 전이적이지 않고 네트워크 트래픽이 피어링 연결 간에 전달되도록 허용하지 않기 때문입니다.

예를 들어 A가 C와 피어링되고, C가 E와 피어링된 경우 패킷을 A에서 C를 경유해 E로 라우팅할 수 없습니다. 패킷을 A와 E 사에이서 직접 라우팅하려면 두 VPC 간에 별도 VPC 피어링 연결을 생성해야 합니다.

필요한 연결 수는 잠재적 장애 지점 수 및 모니터링 요구 사항에 직접적인 영향을 미칩니다. 필요한 연결이 적을수록 모니터링해야 하는 연결이 줄어들고 잠재적 장애 지점이 감소합니다. 네트워킹 환경을 확장해야 하는 경우 다른 옵션을 고려해야 합니다.

VPC 엔트포인트

VPC 엔드포인트를 사용하지 않으면 VPC는 인터넷 게이트웨이 및 NAT 게이트웨이 또는 퍼블릭 IP 주소가 있어야 VPC 외부에서 서버리스 서비스에 액세스할 수 있습니다.

VPC 엔드포인트는 VPC와 지원되는 AWS 서비스 간의 신뢰할 수 있는 경로를 제공합니다. 그러므로 인터넷 게이트웨이, NAT 디바이스, VPN 연결 또는 AWS Driect Connect 연결이 필요하지 않습니다. VPC의 인스턴스는 서비스의 리소스와 통신하는 데 퍼블릭 IP 주소를 필요로 하지 않습니다.

엔트포인트는 가상 디바이스로, 수평으로 크기가 조정되는 고가용성 중복 VPC 구성 요소입니다. 네트워크 트래픽에 가용성 위험이나 대역폭 제약 없이 VPC의 인스턴스와 서비스 간에 통신할 수 있습니다.

게이트웨이 및 인터페이스 VPC 엔드포인트

게이트웨이 VPC 엔드포인트와 인터페이스 VPC 엔드포인트는 AWS 백본을 통해 서비스에 액세스하는 데 도움이 됩니다.

1. 게이트웨이 엔드포인트
   게이트웨이 VPC 엔드포인트(게이트웨이 엔드포인트)는 라우팅 테이블에 있는 경우의 대상으로 고객이 지정하는 게이트웨이입니다. 게이트웨이 엔드포인트는 지원되는 AWS 서비스로 전송되는 트래픽의 대상입니다. AWS 서비스에는 S3 및 DynamoDB가 지원됩니다.
   
   
2. 인터페이스 엔드포인트
   인터페이스 VPC 엔드포인트는 서브넷의 IP 주소 범위에 속하는 프라이빗 IP 주소가 있는 탄력적 네트워크 인터페이스입니다. 네트워크 인터페이스는 지원되는 서비스로 전송되는 트래픽의 진입점 역할을 합니다.

게이트웨이 엔드포인트

게이트웨이 VPC 엔드포인트를 S3 및 DynamoDB로 향하는 트래픽의 라우팅 테이블의 대상으로 지정합니다. 게이트웨이 엔드포인트 용에 따른 추가 요금은 없습니다. 데이터 전송 및 리소스 사용량에 대한 표준 요금이  그대로 적용됩니다.

위 예시에서 퍼블릭 서브넷의 인스턴스 A는 인터넷 게이트웨이를 통해 S3와 통신합니다. 인스턴스 A에는 VPC의 로컬 대상에 대한 경로가 있습니다. 인스턴스 B는 고유한 게이트웨이 엔드포인트를 사용하여 S3 버킷 및 DynamoDB 테이블과 통신합니다. 

프라이빗 라우팅 테이블은 경로를 사용하여 각 게이트웨이 엔드포인트를 통해 S3 및 DynamoDB 요청을 전송합니다. 라우팅 테이블은 접두삿 목록을 사용하여 각 서비스의 대상을 특정 리전으로 지정합니다.

상세

인터페이스 엔드포인트

인터페이스 VPC 엔드포인트를 사용하면 서비스가 VPC 내에 포함되어 있는 것처럼 VPC를 서비스에 프라이빗 방식으로 연결할 수 있습니다. 인터페이스 엔드포인트가 생성되면  VPC에서 라우팅 테이블 변경 없이 트래픽이 새 엔드포인트로 전달됩니다.

위 예시에 나와 있는 리전에서는 에제 VPC 외부에 Systems manager가 있습니다. 예제 VPC에는 퍼블릭 서브넷과 프라이빗 서브넷이 있으며, 각 서브넷에는 EC2 인스턴스가 있습니다. Systems Manager 트래픽은 프라이빗 서브넷의 탄력적 네트워크 인터페이스로 전송됩니다.

상세

ECS(Elastic Container Service)

ECS는 Docker 컨테이너를 지원하는 확장성이 뛰어난 컨테이너 관리 서비스입니다. ECS는 컨테이너화된 애플리케이션의 크기 조정, 유지 관리 및 연결을 관리합니다.

ECS를 사용하면 ECS 태스크를 시작하는 ECS 서비스를 생성할 수 있습니다. ECS 태스크는 하나 이상의 컨테이너 이미지를 사용할 수 있습니다. ECS 서비스는 애플리케이션의 수요를 충족하도록 실행 중인 태스크 수를 조정합니다.

애플리케이션을 위한 전용 인프라를 갖춘 ECS 클러스터를 생성합니다. AWS Fargate에서 관리하는 서버리스 인프라에서 태스크 및 서비스를 실행할 수 있습니다. 인프라를 더 효과적으로 제어하려는 경우 EC2 인스턴스의 클러스터에서 태스크 및 서비스를 관리할 수 있습니다. EC2 인스턴스를 클러스터에 추가하거나 클러스터에서 제거하여 클러스터의 EC2 호스팅 용량 크기를 조절할 수 있습니다.

ECS를 사용하면 클러스터 관리 및 구성 관리 시스템을 직접 운영하거나 관리 인프라의 크기 조정에 대해 걱정할 필요가 없습니다.

기능

ECS는 다음과 같은 기능을 제공합니다.

1. 완전관리형
   ECS는 완전관리형 서비스이므로 컨트롤 플레인, 노드 또는 추가 기능을 관리할 필요가 없습니다. 그러므로 팀이 환경 관리가 아닌 애플리케이션 구축 작업만 중점적으로 수행할 수 있습니다.
   
   
2. 서비스 검색
   ECS에서는 서비스 검색이 지원됩니다. 서비스 검색 기능을 사용하면 도메인 이름 시스템(DNS) 이름에 ECS 서비스를 등록할 수 있습니다. 예를 들어 "backend" 서비스는 backend.example 등의 프라이빗 DNS 네임스페이스에 등록하고 "frontend" 서비스는 frontend.example과 함께 등록할 수 있습니다. 그런 다음 이러한 서비스를 구성하여 동일한 VPC내에서 서로 검색할 수 있습니다. 서비스 검색을 사용하면 마이크로서비스 구성 요소가 생성 및 종료될 때 자동으로 검색되어 네임스페이스에 추가됩니다.
   
   
3. AWS 통합
   ECS는 다음과 같은 여러 AWS 서비스와 통합할 수 있습니다.
   • ECR
     컨테이너화된 애플리케이션이 원활하게 컨테이너 이미지에 액세스하여 해당 이미지를 실행할 수 있습니다.
   • IAM(Identity Access managemen)
     각 컨테이너에 세분화된 권한을 배정할 수 있습니다. 그러면 애플리케이션 구축 시에 컨테이너를 높은 수준의 격리가 가능합니다.
   • CloudWatch Logs 및 Container Insights
     컨테이너화된 애플리케이션과 인스턴스의 로그를 한 곳에서 편리하게 확인할 수 있습니다.
4. 유연한 호스팅 옵션
   ECS에서는 EC2, 그리고 AWS Fargate를 통한 서버리스 호스팅을 모두 사용할 수 있습니다. 리소스 요구 사항, 격리 정책 및 가용성 요구 사항에 따라 클러스터 전체에 컨테이너 배치를 예약할 수  있습니다.
   
   
5. 개발 워크플로
   ECS는 지속적 통합/지속적 배포(CI/CD)를 지원합니다. Docker 컨테이너 기반 마이크로서비스 아키텍처에서는 일반적인 프로세스입니다. 다음 작업을 수행하는 CI/CD 파이프라인을 생성할 수 있습니다.
   • 소스 코드 리포지토리의 변경 사항 모니터링
   • 해당 소스에서 새 Docker 이미지 구축
   • ECR, Docker Hub 등의 이미지 리포지토리에 이미지 푸시
   • 애플리케이션에서 새 이미지를 사용하도록 ECS 서비스 업데이트

상세

EKS(Elastic Kubernetes Service)

Kubernetes(이하 K8s)는 컨테이너화된 애플리케이션을 대규모로 배포하고 관리하는 데 사용할 수 있는 오픈 소스 소프트웨어입니다. K8s는 EC2 컴퓨팅 인스턴스의 클러스터를 관리하고 배포, 유지 관리 및 스케일링의 프로세스를 통해 이러한 인스턴스에서 컨테이너를 실행합니다. K8s를 사용하면 온프레미스나 클라우드에서 동일한 도구들을 사용하여 원하는 유형의 컨테이너화된 애플리케이션을 실행할 수 있습니다.

EKS는 준수 인증을 받은 관리형 Kubernetes 서비스입니다. EKS는 고가용성의 안전한 클러스터를 제공하는 데 도움이 되며 패치 적용, 노드 프로비저닝 및 업데이트와 같은 주요 태스크를 자동화합니다. 이외에도 다음과 같은 기능들이 있습니다.

• 대규모로 애플리케이션 실행 - 복잡한 컨테이너형 애플리케이션을 정의하고 서버 클러스터 전체에서 대구모로 실행할 수 있습니다.
• 애플리케이션을 원활하게 이전 - 컨테이너화된 애플리케이션을 로컬 개발 시스템에서 클라우드의 프로덕션 이전할 수 있습니다.
• 어디서든 실행 - 가용성 및 확장성이 뛰어난 K8s 클러스터를 실행할 수 있습니다.

상세

EKS 솔루션

EKS는 자체 K8s 클러스터를 설치 및 운영할 필요 없이 AWS에서 K8s를 쉽게 실행할 수 있도록 해주는 관리형 서비스입니다. EKS를 사용하면 AWS에서 고가용성 서비스 및 업그레이드를 사용자 대신 관리합니다. EKS는 세 가용 영역에서 3개의 K8s관리자를 실행합니다. EKS는 비정상 관리자를 탐지하여 교체하고 관리자에 대한 버전 업그레이드 및 패치를 자동으로 실행합니다. 또한, EKS는 다양한 AWS 서비스와 통합되어 애플리케이션에 확장성과 보안을 제공합니다.

EKS는 최신 버전의 오픈 소스 K8s 소프트웨어를 실행하므로, K8s 커뮤니티의 기존 플러그인과 도구를 모두 사용할 수 있습니다. EKS에서 실행되는 애플리케이션은 모든 표준 K8s 환경에서 실행되는 애플리케이션과 완벽하게 호환됩니다. 애플리케이션 실행 위치에 관계없이 호환성이 보장됩니다.

Fargate

Fargate는 서버 또는 클러스터를 관리할 필요 없이 컨테이너를 실행하는 데 사용할 수 있는 ECS와 EKS를 위한 기술입니다. Fargate를 사용하면 더 이상 컨테이너를 실행하기 위해 VM 클러스터를 프로비저닝 및 구성하고 크기를 조정할 필요가 없습니다. 따라서 서버 유형을 선택하거나, 클러스터 크기 조정 시점을 결정하거나, 클러스터 패킹을 최적화할 필요가 없습니다.

Fargate에서는 서버 또는 클러스터에 대해 고민하거나 상호 작용할 필요가 없습니다. Fargate를 사용하면 애플리케이션을 실행하는 인프라의 관리 대신 애플리케이션 설계 및 구축에 집중할 수 있습니다.

컨테이너 서비스 선택 기준

AWS에 관리형 컨테이너 솔루션을 배포하려면 오케스트레이션 도구와 시작 유형을 선택해야 합니다.

컨테이너화된 애플리케이션 관리

• ECS에서는 수동 구성 작업은 줄이면서 다른 AWS 서비스와 더 쉽게 통합할 수 있는 관리형 솔루션을 제공합니다.
• EKS에서는 자체 K8s 클러스터를 설치 및 운영할 필요 없이 AWS 클라우드 또는 온프레미스에서 K8s 애플리케이션을 유동적으로 시작 및 실행하고 크기를 조정할 수 있습니다. 이 옵션은 오픈 소스 도구를 사용하는 조직에 적합합니다. EKS를 사용하려면 구성을 추가로 수행해야 하지만 환경을 더욱 잘 제어할 수 있습니다.

컨테이너 호스팅

• EC2에서 컨테이너를 호스트하려면 구성을 추가로 수행해야 합니다. 그러나 컨테이너를 호스트하는 데 사용하는 리소스를 더욱 자세하게 제어할 수 있습니다. 또한 EC2에서는 더욱 비용 효율적으로 컨테이너를 호스트할 수 있습니다.
• Fargate에서 컨테이너를 호스팅할 때는 서버리스 기술을 사용하는 자율 컨테이너 운영 기능이 제공됩니다. 그러믈 ㅗ구성, 패치 적용 및 보안관련 작업에 소요되는 시간을 줄일 수 있습니다.

AWS에서 컨테이너 실행

AWS에 관리형 컨테이너 솔루션을 배포하려면 다음 구성 요소를 선택하고 구성해야 합니다.

1. 레지스트리
   컨테이너화된 애플리케이션을 개발할 대는 컨테이너를 실행하는 데 필요한 모든 항목이 포함된 컨테이너 이미지를 구축합니다. 이러한 항목으로는 애플리케이션 코드, 런타임, 시스템 도구, 시스템 라이브러리, 설정 등이 포함됩니다. 그런 다음 버전 제어를 위해 이미지를 리포지토리에 푸시하고 해당 이미지를 리포지토리에서 끌어와 컨테이너를 배포합니다. 레지스트리는 리포지토리 모음입니다.
   
   AWS는 다른 AWS 서비스와 통합을 지원하는 컨테이너 이미지 레지스트리로 ECR을 제공합니다.
   
   
2. 오케스트레이션 도구
   컨테이너 오케스트레이션 도구를 사용하여 컨테이너화된 애플리케이션을 규모에 맞게 관리할 수 있습니다. 오케스트레이션 도구는 컨테이너의 크기 조정, 네트워킹 및 유지 관리 작업을 관리합니다. 컨테이너 시작 및 종료 관리, 컨테이너 상태 모니터링, 업데이트 배포 및 장애 조치 및 복구 관리에 도움이 됩니다.
   
   • EKS
     AWS에서 Kubernetes 컨테이너 오케스트레이션 소프트웨어를 실행하는 데 사용할 수 있는 관리형 서비스입니다. 구성을 추가로 제어해야 하는 경우 이 옵션을 선택할 수 있습니다.
   • ECS
     컨테이너 배포 보다는 관리된 모델을 제공하는 관리형 컨테이너 오케스트레이션 서비스입니다. ECS에서는 기타 AWS 서비스와의 통합 기능도 추가로 제공됩니다.
     
     
3. 컨테이너 호스팅
   오케스트레이션 도구가 컨테이너를 호스트하는 데 사용하도록 할 컴퓨팅 리소스를 결정해야 합니다. 이러한 리소스를 컨테이너의 시작 유형이라고도 합니다.
   • EC2를 선택하여 다양한 인스턴스 유형에서 컨테이너를 시작할 수 있습니다. 수요가 변경되면 컨테이너를 호스트하는 데 사용되는 EC2 인스턴스 수를 확장 및 축소할 수 있습니다. 이 방법은 비용 효율성이 우수하며, 인스턴스 유형을 더욱 효과적으로 제어할 수 있습니다.
   • Fargate는 컨테이너를 지원하기 위해 CPU 및 메모리 리소스를 자동으로 할당하는 서버리스 호스팅 서비스입니다. Fargate 사용 시에는 기본 컴퓨팅 리소스를 프로비저닝하거나 관리할 필요가 없습니다.

ECR(Elastic Container Registry)

ECR은 관리형 Docker 컨테이너 레지스트리입니다. 컨테이너 이미지리를 ECR로 푸시한 후 이미지를 끌어와서 컨테이너를 시작할 수 있습니다. ECR을 사용하면 컨테이너 이미지에 대한 압축, 암호화 및 제어할 수 있습니다. 또한 버전 관리 및 이미지 태그도 관리할 수 있습니다. 각 AWS 계정에 ECR 프라이빗 레지스트리가 제공됩니다. 레지스트리에 리포지토리를 하나 이상 생성한 후 리포지토리에 이미지를 저장할 수 있습니다.

위 예시에서는 컨테이너를 사용하여 모놀리스 포럼 애플리케이션을 마이크로서비스로 리팩터링합니다. 리팩터링에서는 코드를 사용자 서비스, 주제 서비스 및 메시지 서비스와 같은 개별 캡슐화된 서비스로 분할합니다. 이러한 각 서비스에 대해 컨테이너 이미지를 구축하면 독립적으로 시작, 업데이트 및 종료할 수 있습니다. 이 예에서는 각 서비스의 컨테이너 이미지가 각 이미지의 여러 버전을 저장하는 자체 리포지토리로 푸시됩니다. 오케스트레이션 서비스는 필요에 따라 이러한 컨테이너 이미지를 끌어와 새 컨테이너를 배포할 수 있습니다.