# Amazon ECS 네트워킹 모범 사례
현대적 애플리케이션은 일반적으로 서로 통신하는 여러 분산 구성 요소로 구축됩니다. 예를 들어, 모바일 또는 웹 애플리케이션은 API 엔드포인트와 통신할 수 있으며, API는 인터넷을 통해 통신하는 여러 마이크로서비스를 통해 구동될 수 있습니다.
애플리케이션을 인터넷에 연결하는 모범 사례에 대한 자세한 내용은 [Amazon ECS 애플리케이션을 인터넷에 연결](networking-outbound.md) 섹션을 참조하세요.
인터넷에서 Amazon ECS로 인바운드 연결을 수신하는 모범 사례에 대한 자세한 내용은 [인터넷에서 Amazon ECS로의 인바운드 연결을 수신하는 모범 사례](networking-inbound.md) 섹션을 참조하세요.
Amazon ECS를 다른 AWS 서비스에 연결하는 모범 사례에 대한 자세한 내용은 [VPC 내에서 Amazon ECS를 AWS 서비스에 연결하는 모범 사례](networking-connecting-vpc.md) 섹션을 참조하세요.
VPC 내 서비스에 연결하는 모범 사례에 대한 자세한 내용은 [VPC에서 Amazon ECS 서비스를 연결하는 모범 사례](networking-connecting-services.md) 섹션을 참조하세요.
AWS 계정 및 VPC 간 네트워킹 서비스의 모범 사례에 대한 자세한 내용은 [AWS 계정 및 VPC 간의 Amazon ECS 서비스 네트워킹을 위한 모범 사례](networking-connecting-services-crossaccount.md) 섹션을 참조하세요.
네트워킹 문제 해결을 위한 서비스의 모범 사례에 대한 자세한 내용은 [Amazon ECS 네트워킹 문제 해결을 위한 AWS 서비스](networking-troubleshooting.md) 섹션을 참조하세요.
# Amazon ECS 애플리케이션을 인터넷에 연결
대부분의 컨테이너화된 애플리케이션에는 인터넷에 대한 아웃바운드 액세스가 필요한 구성 요소가 최소한 몇 개 있습니다. 예를 들어 모바일 앱의 백엔드에는 푸시 알림에 대해 아웃바운드 액세스가 필요합니다.
Amazon Virtual Private Cloud에는 VPC와 인터넷 간의 통신을 용이하게 하는 두 가지 기본 방법이 있습니다.
## 퍼블릭 서브넷 및 인터넷 게이트웨이
![\[인터넷 게이트웨이에 연결된 퍼블릭 서브넷의 아키텍처를 보여주는 다이어그램.\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/images/public-network.png)
인터넷 게이트웨이로 라우팅되는 퍼블릭 서브넷을 사용하는 경우 컨테이너화된 애플리케이션을 퍼블릭 서브넷의 VPC 내부 호스트에서 실행할 수 있습니다. 컨테이너를 실행하는 호스트에는 퍼블릭 IP 주소가 할당됩니다. 이 퍼블릭 IP 주소는 인터넷에서 라우팅할 수 있습니다. 자세한 내용은 *Amazon VPC 사용 설명서*의 [인터넷 게이트웨이](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html)를 참조하세요.
이 네트워크 아키텍처는 애플리케이션을 실행하는 호스트와 인터넷상의 다른 호스트 간 직접 통신을 용이하게 합니다. 통신은 양방향으로 이루어집니다. 즉, 인터넷상의 다른 호스트에 아웃바운드 연결을 설정할 수 있을 뿐만 아니라 인터넷상의 다른 호스트가 해당 호스트에 연결을 시도할 수도 있습니다. 따라서 보안 그룹 및 방화벽 규칙에 주의해야 합니다. 그러면 인터넷상의 다른 호스트는 사용자가 열고 싶지 않은 연결을 열 수 없습니다.
예를 들어, 애플리케이션이 Amazon EC2에서 실행되는 경우 SSH 액세스를 위한 포트 22가 열려 있지 않아야 합니다. 그렇지 않으면 인스턴스가 인터넷의 악성 봇으로부터 지속적인 SSH 연결 시도를 받을 수 있습니다. 이 봇은 퍼블릭 IP 주소를 트롤링합니다. 악성 봇이 열린 SSH 포트를 찾으면 암호를 무차별 입력하여 인스턴스에 액세스하려고 시도합니다. 이 때문에 많은 조직에서는 퍼블릭 서브넷의 사용을 제한하고 전부는 아니더라도 대부분의 리소스를 프라이빗 서브넷 내에 두는 방식을 선호합니다.
네트워킹에 퍼블릭 서브넷을 사용하는 방식은 많은 양의 대역폭이나 최소 지연 시간이 필요한 퍼블릭 애플리케이션에 적합합니다. 적용 가능한 사용 사례로, 비디오 스트리밍 및 게임 서비스가 포함됩니다.
이 네트워킹 접근 방식은 Amazon EC2에서 Amazon ECS를 사용하는 경우 및 AWS Fargate에서 사용하는 경우 모두 지원됩니다.
+ Amazon EC2 - 퍼블릭 서브넷에서 EC2 인스턴스를 시작할 수 있습니다. Amazon ECS는 이러한 EC2 인스턴스를 클러스터 용량으로 사용하며, 인스턴스에서 실행되는 모든 컨테이너는 아웃바운드 네트워킹을 위해 호스트의 기본 퍼블릭 IP 주소를 사용할 수 있습니다. `host` 및 `bridge` 네트워크 모드 모두에 적용됩니다. 그러나 `awsvpc` 네트워크 모드는 퍼블릭 IP 주소를 사용하는 작업 ENI를 제공하지 않습니다. 따라서 인터넷 게이트웨이를 직접 사용할 수 없습니다.
+ Fargate - Amazon ECS 서비스를 생성할 때 서비스의 네트워킹 구성에 대한 퍼블릭 서브넷을 지정하고 **퍼블릭 IP 주소 할당** 옵션을 사용합니다. 각 Fargate 작업은 퍼블릭 서브넷에서 네트워크로 연결되며 인터넷과 직접 통신하기 위한 자체 퍼블릭 IP 주소를 가지고 있습니다.
## 프라이빗 서브넷 및 NAT 게이트웨이
![\[NAT 게이트웨이에 연결된 프라이빗 서브넷의 아키텍처를 보여주는 다이어그램.\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/images/private-network.png)
프라이빗 서브넷 및 NAT 게이트웨이를 사용하는 경우 프라이빗 서브넷에 있는 호스트에서 컨테이너화된 애플리케이션을 실행할 수 있습니다. 따라서 이 호스트에는 VPC 내에서 라우팅할 수 있지만 인터넷에서 라우팅할 수 없는 프라이빗 IP 주소가 있습니다. 즉, VPC 내의 다른 호스트는 프라이빗 IP 주소를 사용하여 호스트에 연결할 수 있지만 인터넷상의 다른 호스트는 호스트와 인바운드 통신을 할 수 없습니다.
프라이빗 서브넷에서는 Network Address Translation(NAT) 게이트웨이를 사용하여 프라이빗 서브넷 내부의 호스트를 인터넷에 연결할 수 있습니다. 인터넷상의 호스트는 퍼블릭 서브넷 내에 있는 NAT 게이트웨이의 퍼블릭 IP 주소에서 시작하는 인바운드 연결을 수신합니다. NAT 게이트웨이는 인터넷과 프라이빗 서비스 사이에서 브리지 역할을 합니다. 이 구성은 인터넷에서 공격자가 직접 액세스하지 못하도록 VPC를 보호하므로 보안상의 이유로 종종 선호됩니다. 자세한 내용은 *Amazon VPC 사용 설명서*의 [NAT 게이트웨이](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) 섹션을 참조하세요.
이 프라이빗 네트워킹 접근 방식은 컨테이너를 외부 직접 액세스로부터 보호하려는 시나리오에 적합합니다. 적용 가능한 시나리오로, 사용자 데이터와 암호를 저장하는 결제 처리 시스템 또는 컨테이너가 포함됩니다. 계정에서 NAT 게이트웨이 생성 및 사용에 대한 요금이 청구됩니다. NAT 게이트웨이 시간당 사용 요금 및 데이터 처리 요금도 적용됩니다. 이중화를 위해 각 가용 영역에 하나의 NAT 게이트웨이가 있어야 합니다. 이렇게 하면 단일 가용 영역의 가용성이 손실되어도 아웃바운드 연결이 손상되지 않습니다. 따라서 워크로드가 적은 경우 프라이빗 서브넷 및 NAT 게이트웨이를 사용하는 것이 더 비용 효율적일 수 있습니다.
이 네트워킹 접근 방식은 Amazon EC2에서 Amazon ECS를 사용하는 경우 및 AWS Fargate에서 사용하는 경우 모두 지원됩니다.
+ Amazon EC2 - 프라이빗 서브넷에서 EC2 인스턴스를 시작할 수 있습니다. 이러한 EC2 호스트에서 실행되는 컨테이너는 기본 호스트 네트워킹을 사용하며 아웃바운드 요청은 NAT 게이트웨이를 통과합니다.
+ Fargate - Amazon ECS 서비스를 생성할 때 서비스의 네트워킹 구성에 대한 프라이빗 서브넷을 지정하고 **퍼블릭 IP 주소 할당** 옵션을 사용하지 않습니다. 각 Fargate 작업은 프라이빗 서브넷에서 호스팅됩니다. 아웃바운드 트래픽은 해당 프라이빗 서브넷에 연결한 모든 NAT 게이트웨이를 통해 라우팅됩니다.
# 인터넷에서 Amazon ECS로의 인바운드 연결을 수신하는 모범 사례
퍼블릭 서비스를 실행하는 경우 인터넷의 인바운드 트래픽을 수락해야 합니다. 예를 들어 퍼블릭 웹 사이트는 브라우저의 인바운드 HTTP 요청을 수락해야 합니다. 이 경우 인터넷의 다른 호스트도 애플리케이션 호스트에 대한 인바운드 연결을 시작해야 합니다.
이 문제에 대한 한 가지 접근 방식은 퍼블릭 IP 주소를 사용하는 퍼블릭 서브넷에 있는 호스트에서 컨테이너를 시작하는 것입니다. 그러나 대규모 애플리케이션에는 권장되지 않습니다. 이러한 경우에는 인터넷 및 애플리케이션 사이에 확장 가능한 입력 레이어를 배치하는 것이 더 좋습니다. 이 접근 방식에서는 이 섹션에 나열된 모든 AWS 서비스를 입력으로 사용할 수 있습니다.
## Application Load Balancer
Application Load Balancer는 애플리케이션 계층에서 작동합니다. 이는 개방형 시스템 상호 연결(OSI) 모델의 일곱 번째 계층입니다. 따라서 Application Load Balancer는 퍼블릭 HTTP 서비스에 적합합니다. 웹 사이트 또는 HTTP REST API가 있는 경우 Application Load Balancer는 이 워크로드에 적합한 로드 밸런서입니다. 자세한 내용은 *Application Load Balancer 사용 설명서*의 [What is an Application Load Balancer?](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)를 참조하세요.
![\[Application Load Balancer를 사용하는 네트워크의 아키텍처를 보여주는 다이어그램.\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/images/alb-ingress.png)
이 아키텍처에서는 퍼블릭 서브넷에 Application Load Balancer를 생성하여 퍼블릭 IP 주소를 사용하고 인터넷의 인바운드 연결을 수신할 수 있습니다. Application Load Balancer에서 인바운드 연결 또는 특히 HTTP 요청을 수신하면 프라이빗 IP 주소를 사용하여 애플리케이션에 대한 연결을 엽니다. 그런 다음, 내부 연결을 통해 요청을 전달합니다.
Application Load Balancer의 장점은 다음과 같습니다.
+ SSL/TLS 종료 - Application Load Balancer는 클라이언트와의 통신을 위한 보안 HTTPS 통신 및 인증서를 유지할 수 있습니다. 선택적으로 로드 밸런서 수준에서 SSL 연결을 종료할 수 있으므로 애플리케이션에서 인증서를 처리할 필요가 없습니다.
+ 고급 라우팅 - Application Load Balancer는 여러 DNS 호스트 이름을 보유할 수 있습니다. 또한 호스트 이름이나 요청 경로와 같은 지표를 기반으로 수신 HTTP 요청을 다른 대상으로 전송하는 고급 라우팅 기능도 지원합니다. 즉, 단일 Application Load Balancer를 여러 내부 서비스 또는 REST API의 여러 경로에 있는 마이크로서비스의 입력으로도 사용할 수 있습니다.
+ gRPC 지원 및 웹 소켓 - Application Load Balancer는 HTTP 외에도 다양한 기능을 처리할 수 있습니다. 또한 HTTP/2 지원을 통해 gRPC 및 웹 소켓 기반 서비스를 로드 밸런싱할 수 있습니다.
+ 보안 - Application Load Balancer는 악성 트래픽으로부터 애플리케이션을 보호하는 데 도움이 됩니다. 여기에는 HTTP 동기화 해제 완화와 같은 기능이 포함되어 있으며, AWS 웹 애플리케이션 방화벽(AWS WAF)과 통합됩니다. AWS WAF에서는 SQL 명령어 삽입 또는 크로스 사이트 스크립팅과 같은 공격 패턴을 포함할 수 있는 악성 트래픽도 필터링할 수 있습니다.
## Network Load Balancer
Network Load Balancer는 오픈 시스템 상호 연결(OSI) 모델의 네 번째 계층에서 작동합니다. 비 HTTP 프로토콜 또는 종단 간 암호화가 필요한 시나리오에 적합하지만, Application Load Balancer에서 제공하는 동일한 HTTP 특정 기능을 제공하지는 않습니다. 따라서 Network Load Balancer는 HTTP를 사용하지 않는 애플리케이션에 가장 적합합니다. 자세한 내용은 *Network Load Balancer 사용 설명서*의 [Network Load Balancer란?](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html)을 참조하세요.
![\[Network Load Balancer를 사용하는 네트워크의 아키텍처를 보여주는 다이어그램.\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/images/nlbingress.png)
Network Load Balancer가 입력으로 사용되는 경우 Application Load Balancer와 유사하게 작동합니다. 퍼블릭 서브넷에서 생성되고 인터넷에서 액세스할 수 있는 퍼블릭 IP 주소를 사용하기 때문입니다. 그러면 Network Load Balancer는 컨테이너를 실행하는 호스트의 프라이빗 IP 주소에 대한 연결을 열고 퍼블릭 측에서 프라이빗 측으로 패킷을 전송합니다.
**Network Load Balancer 기능**
Network Load Balancer는 네트워킹 스택의 하위 수준에서 작동하기 때문에 Application Load Balancer와 동일한 기능 세트를 제공하지 않습니다. 하지만 다음과 같은 중요한 기능이 있습니다.
+ 종단 간 암호화 - Network Load Balancer는 OSI 모델의 네 번째 계층에서 작동하므로 패킷 콘텐츠를 읽지 않습니다. 따라서 종단 간 암호화가 필요한 로드 밸런싱 통신에 적합합니다.
+ TLS 암호화 - Network Load Balancer는 종단 간 암호화 외에도 TLS 연결을 종료할 수 있습니다. 따라서 백엔드 애플리케이션에서 자체 TLS를 구현할 필요가 없습니다.
+ UDP 지원 - Network Load Balancer는 OSI 모델의 네 번째 계층에서 작동하므로 TCP 이외의 비 HTTP 워크로드 및 프로토콜에 적합합니다.
**연결 닫기**
Network Load Balancer는 OSI 모델의 상위 계층에서 애플리케이션 프로토콜을 관찰하지 않으므로 해당 프로토콜에서 클라이언트에 닫기 메시지를 보낼 수 없습니다. Application Load Balancer와 달리, 이러한 연결은 애플리케이션이 닫아야 합니다. 아니면 작업이 중지되거나 교체될 때 네 번째 계층 연결을 닫도록 Network Load Balancer를 구성할 수 있습니다. [Network Load Balancer 설명서](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html#deregistration-delay)의 Network Load Balancer 대상 그룹에 대한 연결 종료 설정을 참조하세요.
Network Load Balancer에서 네 번째 계층의 연결을 닫으면 클라이언트가 원하지 않는 오류 메시지를 처리하지 않는 경우 클라이언트에 해당 메시지가 표시될 수 있습니다. 권장 클라이언트 구성에 대한 자세한 정보는 [Builders' Library](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter)를 참조하세요.
연결을 종료하는 방법은 애플리케이션마다 다르지만, Network Load Balancer 대상 등록 취소 지연이 클라이언트 연결 제한 시간보다 길도록 보장하는 한 가지 방법이 있습니다. 이전 작업이 모든 클라이언트를 천천히 드레이닝하는 동안, 클라이언트에서 먼저 제한 시간이 초과되고 Network Load Balancer를 통해 다음 작업에 정상적으로 다시 연결합니다. Network Load Balancer 대상 등록 취소 지연에 대한 자세한 내용은 [Network Load Balancer 설명서](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html#deregistration-delay)를 참조하세요.
## Amazon API Gateway HTTP API
Amazon API Gateway는 요청 볼륨이 갑자기 증가하거나 요청 볼륨이 적은 HTTP 애플리케이션에 적합합니다. 자세한 내용은 *API Gateway 개발자 안내서*의 [What is Amazon API Gateway?](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html)를 참조하세요.
![\[API Gateway를 사용하는 네트워크의 아키텍처를 보여주는 다이어그램.\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/images/apigateway-ingress.png)
Application Load Balancer 및 Network Load Balancer의 요금 모델에는 로드 밸런서에서 수신 연결을 항상 수락하도록 유지하는 시간당 요금이 포함되어 있습니다. 반면, API Gateway는 각 요청에 대해 개별적으로 요금을 청구합니다. 따라서 요청이 들어오지 않으면 요금이 부과되지 않습니다. 트래픽 부하가 높은 경우 Application Load Balancer 또는 Network Load Balancer는 API Gateway보다 저렴한 요청당 요금으로 더 많은 양의 요청을 처리할 수 있습니다. 하지만 전반적으로 요청 수가 적거나 일정 기간 트래픽이 적은 경우 사용률이 낮은 로드 밸런서를 유지 관리하기 위해 시간당 요금을 지불하는 것보다 API Gateway를 사용하는 누적 요금이 더 비용 효율적입니다. 또한 API Gateway는 API 응답을 캐싱할 수 있으므로 백엔드 요청 비율이 낮아질 수 있습니다.
API Gateway는 VPC 링크를 사용하여 작동합니다. 이를 통해 AWS 관리형 서비스에서 프라이빗 IP 주소를 사용해 VPC의 프라이빗 서브넷 내에 있는 호스트에 연결할 수 있습니다. Amazon ECS 서비스 검색에서 관리하는 AWS Cloud Map 서비스 검색 레코드를 살펴봄으로써 이러한 프라이빗 IP 주소를 감지할 수 있습니다.
API Gateway에서 지원하는 기능은 다음과 같습니다.
+ API Gateway 작업은 로드 밸런서와 비슷하지만, API 관리와 관련된 고유한 추가 기능이 있습니다.
+ API Gateway에서는 클라이언트 권한 부여, 사용 계층, 요청 및 응답 수정과 관련된 추가 기능을 제공합니다. 자세한 내용은 [Amazon API Gateway 기능](https://aws.amazon.com//api-gateway/features/)을 참조하세요.
+ API Gateway는 엣지, 리전 및 프라이빗 API 게이트웨이 엔드포인트를 지원할 수 있습니다. 엣지 엔드포인트는 관리형 CloudFront 배포를 통해 사용할 수 있습니다. 리전 엔드포인트 및 프라이빗 엔드포인트는 모두 리전에 로컬로 존재합니다.
+ SSL/TLS 종료
+ 다양한 HTTP 경로를 다양한 백엔드 마이크로서비스로 라우팅
위의 기능 외에도 API Gateway는 API를 무단 사용으로부터 보호하기 위해 사용할 수 있는 사용자 지정 Lambda 권한 부여자 사용을 지원합니다. 자세한 내용은 [Field Notes: Serverless Container-based APIs with Amazon ECS and Amazon API Gateway](https://aws.amazon.com/blogs/architecture/field-notes-serverless-container-based-apis-with-amazon-ecs-and-amazon-api-gateway/)를 참조하세요.
# VPC 내에서 Amazon ECS를 AWS 서비스에 연결하는 모범 사례
Amazon ECS가 올바르게 동작하려면 각 호스트에서 실행되는 Amazon ECS 컨테이너 에이전트가 Amazon ECS 컨트롤 플레인과 통신해야 합니다. Amazon ECR에 컨테이너 이미지를 저장하는 경우 Amazon EC2 호스트는 Amazon ECR 서비스 엔드포인트 및 이미지 레이어가 저장된 Amazon S3와 통신해야 합니다. DynamoDB에 저장된 데이터를 유지하는 등 컨테이너화된 애플리케이션에 다른 AWS 서비스를 사용하는 경우 이러한 서비스에도 필요한 네트워킹 지원이 있는지 다시 한 번 확인하세요.
## NAT 게이트웨이
Amazon ECS 태스크가 다른 AWS 서비스에 액세스할 수 있도록 보장하는 가장 쉬운 방법은 NAT 게이트웨이를 사용하는 것입니다. 이 방법에 대한 자세한 내용은 [프라이빗 서브넷 및 NAT 게이트웨이](networking-outbound.md#networking-private-subnet) 섹션을 참조하세요.
![\[NAT 게이트웨이를 사용하는 네트워크의 아키텍처를 보여주는 다이어그램.\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/images/natgateway.png)
이 접근 방식을 사용하면 다음과 같은 단점이 있습니다.
+ NAT 게이트웨이가 통신할 수 있는 대상을 제한할 수 없습니다. 또한 백엔드 계층이 VPC의 모든 아웃바운드 통신을 중단하지 않으면서 통신할 수 있는 대상을 제한할 수 없습니다.
+ NAT 게이트웨이는 통과하는 데이터 GB당 요금을 부과합니다. 다음 작업에 NAT 게이트웨이를 사용하는 경우 대역폭 GB당 요금이 부과됩니다.
+ Amazon S3에서 대용량 파일 다운로드
+ DynamoDB에서 대량의 데이터베이스 쿼리 수행
+ Amazon ECR에서 이미지 가져오기
또한 NAT 게이트웨이는 5Gbps의 대역폭을 지원하며 최대 45Gbps까지 자동 확장합니다. 단일 NAT 게이트웨이를 통해 라우팅하는 경우 매우 높은 대역폭 연결이 필요한 애플리케이션에 네트워킹 제약 조건이 발생할 수 있습니다. 해결 방법은 워크로드를 여러 서브넷으로 나누고 각 서브넷에 고유한 NAT 게이트웨이를 제공하는 것입니다.
## AWS PrivateLink
AWS PrivateLink는 트래픽을 퍼블릭 인터넷에 노출시키지 않고 VPC, AWS 서비스, 온프레미스 네트워크 간에서 프라이빗 연결을 제공합니다.
VPC 엔드포인트에서는 VPC와 지원되는 AWS 서비스 및 VPC 엔드포인트 서비스 간에 프라이빗 연결을 사용할 수 있습니다. VPC와 기타 서비스 간의 트래픽은 Amazon 네트워크를 벗어나지 않습니다. VPC 엔드포인트에는 인터넷 게이트웨이, 가상 프라이빗 게이트웨이, NAT 디바이스, VPN 연결 또는 Direct Connect 연결이 필요하지 않습니다. VPC의 Amazon EC2 인스턴스는 서비스의 리소스와 통신하는 데 퍼블릭 IP 주소를 필요로 하지 않습니다.
다음 다이어그램에서는 인터넷 게이트웨이 대신 VPC 엔드포인트를 사용할 때 AWS 서비스와의 통신이 작동하는 방식을 보여줍니다. AWS PrivateLink는 서브넷 내부에 탄력적 네트워크 인터페이스(ENI)를 프로비저닝하고, VPC 라우팅 규칙을 사용하여 ENI를 통해 서비스 호스트 이름에 대한 모든 통신을 대상 AWS 서비스로 직접 전송합니다. 이 트래픽은 더 이상 NAT 게이트웨이 또는 인터넷 게이트웨이를 사용할 필요가 없습니다.
![\[AWS PrivateLink를 사용하는 네트워크의 아키텍처를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/images/endpointaccess-multiple.png)
다음은 Amazon ECS 서비스와 함께 사용되는 몇 가지 일반적인 VPC 엔드포인트의 예입니다.
+ [Amazon S3에 대한 게이트웨이 엔드포인트](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html)
+ [DynamoDB VPC 엔드포인트](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/vpc-endpoints-dynamodb.html)
+ [Amazon ECS VPC 엔드포인트](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/vpc-endpoints.html)
+ [Amazon ECR VPC 엔드포인트](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html)
다른 많은 AWS 서비스가 VPC 엔드포인트를 지원합니다. 사용량이 매우 많은 AWS 서비스가 있는 경우 해당 서비스와 관련된 설명서와 해당 트래픽에 대한 VPC 엔드포인트를 생성하는 방법을 살펴봐야 합니다.
# VPC에서 Amazon ECS 서비스를 연결하는 모범 사례
VPC에서 Amazon ECS 태스크를 사용할 경우 모놀리식 애플리케이션을 별도의 부분으로 분할하여 안전한 환경에서 독립적으로 배포하고 확장할 수 있습니다. 이 아키텍처를 서비스 지향 아키텍처(SOA) 또는 마이크로서비스라고 합니다. 하지만 VPC 내부와 외부 모두에서 이러한 모든 부분이 서로 통신할 수 있는지 확인하는 것이 어려울 수 있습니다. 원활한 통신을 보장하는 방법에는 여러 가지가 있지만 각각 장단점이 있습니다.
## Service Connect 사용
서비스 검색, 연결 및 트래픽 모니터링을 위한 Amazon ECS 구성을 제공하는 Service Connect를 사용하는 것이 좋습니다. Service Connect를 사용하면 애플리케이션에서 짧은 이름과 표준 포트를 사용하여 동일한 리전에 있는 여러 VCP에 있는 항목을 포함하여 동일한 클러스터, 다른 클러스터의 서비스에 연결할 수 있습니다. 자세한 내용은 [Amazon ECS Service Connect](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-connect.html)를 참조하세요.
Service Connect를 사용하면 Amazon ECS가 서비스 검색의 모든 부분을 관리합니다. 즉, 검색할 수 있는 이름을 생성하고, 작업이 시작 및 중지될 때 각 작업에 대한 항목을 동적으로 관리하며, 이름을 검색하도록 구성된 각 작업에서 에이전트를 실행할 수 있습니다. 애플리케이션은 DNS 이름에 대한 표준 기능을 사용하고 연결을 설정하여 이름을 조회할 수 있습니다. 애플리케이션이 이미 이 작업을 수행하는 경우 Service Connect를 사용하기 위해 애플리케이션을 수정할 필요가 없습니다.
![\[Service Connect를 사용하는 네트워크의 아키텍처를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/images/serviceconnect.png)
**변경 사항은 배포 중에만 발생**
각 서비스 및 작업 정의 내에 전체 구성을 제공합니다. Amazon ECS는 각 서비스 배포에서 이 구성의 변경 내용을 관리하여 배포의 모든 작업이 동일한 방식으로 작동하도록 합니다. 예를 들어, 서비스 검색으로 DNS에서 흔히 발생하는 문제는 마이그레이션 제어와 관련됩니다. 새 교체 IP 주소를 가리키도록 DNS 이름을 변경하는 경우 모든 클라이언트가 새 서비스를 사용하기 시작하는 데 최대 TTL 시간이 걸릴 수 있습니다. Service Connect를 사용하면 클라이언트 배포에서 클라이언트 작업을 교체하여 구성을 업데이트합니다. 다른 배포와 동일한 방식으로 Service Connect 변경 내용에 영향을 주도록 배포 회로 차단기 및 기타 배포 구성을 구성할 수 있습니다.
## 서비스 검색 사용
서비스 간 통신의 또 다른 접근 방식으로, 서비스 검색을 사용하는 직접 통신이 있습니다. 이 접근 방식에서는 Amazon ECS와의 AWS Cloud Map 서비스 검색 통합을 사용할 수 있습니다. Amazon ECS는 서비스 검색을 사용하여 시작된 작업 목록을 AWS Cloud Map과 동기화합니다. 이 제품에서는 해당 특정 서비스에서 하나 이상 작업에 대한 내부 IP 주소로 확인되는 DNS 호스트 이름을 유지 관리합니다. Amazon VPC의 다른 서비스는 이 DNS 호스트 이름을 사용하여 내부 IP 주소를 통해 다른 컨테이너로 직접 트래픽을 보낼 수 있습니다. 자세한 내용은 [서비스 검색](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-discovery.html)을 참조하세요.
![\[서비스 검색을 사용하는 네트워크의 아키텍처를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/images/servicediscovery.png)
이전 다이어그램에는 세 가지 서비스가 있습니다. `service-a-local`에는 컨테이너가 하나 있고 컨테이너가 두 개 있는 `service-b-local`과 통신합니다. `service-b-local`도 컨테이너가 하나 있는 `service-c-local`과 통신해야 합니다. 세 서비스 모두에서 각 컨테이너는 AWS Cloud Map의 내부 DNS 이름을 사용하여 통신이 필요한 다운스트림 서비스의 컨테이너 내부 IP 주소를 찾을 수 있습니다.
서비스 간 통신에 대한 이러한 접근 방식은 지연 시간을 줄여줍니다. 컨테이너 사이에 추가 구성 요소가 없기 때문에 언뜻 보기에도 간단합니다. 트래픽은 한 컨테이너에서 다른 컨테이너로 직접 이동합니다.
이 접근 방식은 각 작업의 IP 주소가 고유한 `awsvpc` 네트워크 모드를 사용할 때 적합합니다. 대부분의 소프트웨어는 IP 주소로 직접 확인되는 DNS `A` 레코드 사용만 지원합니다. `awsvpc` 네트워크 모드를 사용하는 경우 각 작업의 IP 주소는 `A` 레코드입니다. 하지만 `bridge` 네트워크 모드를 사용하는 경우 여러 컨테이너가 동일한 IP 주소를 공유할 수 있습니다. 또한 동적 포트 매핑으로 해당 단일 IP 주소에서 컨테이너에 포트 번호가 무작위로 할당됩니다. 이 경우 `A` 레코드는 더 이상 서비스 검색에 충분하지 않습니다. 또한 `SRV` 레코드를 사용해야 합니다. 이 유형의 레코드는 IP 주소와 포트 번호를 모두 추적할 수 있지만 애플리케이션을 적절하게 구성해야 합니다. 사용하는 일부 사전 구축된 애플리케이션은 `SRV` 레코드를 지원하지 않을 수 있습니다.
`awsvpc` 네트워크 모드의 또 다른 이점은 각 서비스에 대해 고유한 보안 그룹이 보유한다는 점입니다. 해당 서비스와 통신해야 하는 특정 업스트림 서비스의 수신 연결만 허용하도록 이 보안 그룹을 구성할 수 있습니다.
서비스 검색을 사용하는 서비스 간 직접 통신의 주된 단점은 재시도 및 연결 실패 처리를 위해 추가 로직을 구현해야 한다는 점입니다. DNS 레코드에는 캐싱되는 시간을 제어하는 TTL(Time To Live) 기간이 있습니다. 애플리케이션이 최신 버전의 DNS 레코드를 선택할 수 있도록 DNS 레코드를 업데이트하고 캐시가 만료되기까지 어느 정도 시간이 걸립니다. 따라서 애플리케이션이 DNS 레코드를 확인할 때 더 이상 존재하지 않는 다른 컨테이너를 가리킬 수 있습니다. 애플리케이션은 재시도를 처리하고 잘못된 백엔드를 무시할 수 있는 로직을 포함해야 합니다.
## 내부 로드 밸런서 사용
서비스 간 통신에 대한 또 다른 접근 방식은 내부 로드 밸런서를 사용하는 것입니다. 내부 로드 밸런서는 VPC 내부에만 존재하며 VPC 내부의 서비스에만 액세스할 수 있습니다.
![\[내부 로드 밸런서를 사용하는 네트워크의 아키텍처를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/images/loadbalancer-internal.png)
로드 밸런서는 각 서브넷에 중복 리소스를 배포하여 고가용성을 유지합니다. `serviceA`의 컨테이너가 `serviceB`의 컨테이너와 통신해야 하는 경우 로드 밸런서에 대한 연결을 엽니다. 그러면 로드 밸런서가 `service B`의 컨테이너에 대한 연결을 엽니다. 로드 밸런서는 각 서비스 간의 모든 연결을 관리하는 중앙 위치의 역할을 합니다.
`serviceB`의 컨테이너가 중지되면 로드 밸런서가 해당 컨테이너를 풀에서 제거할 수 있습니다. 또한 로드 밸런서는 풀의 각 다운스트림 대상에 대해 상태 확인을 수행하여 잘못된 대상이 다시 정상 상태가 될 때까지 풀에서 자동으로 제거할 수 있습니다. 애플리케이션은 더 이상 다운스트림 컨테이너가 몇 개 있는지 알 필요가 없습니다. 단순히 로드 밸런서에 대한 연결을 열면 됩니다.
이 접근 방식은 모든 네트워크 모드에서 이점이 있습니다. 로드 밸런서는 `awsvpc` 네트워크 모드를 사용할 때는 태스크 IP 주소를 추적하고 `bridge` 네트워크 모드를 사용할 때는 더 복잡한 IP 주소 및 포트 조합을 추적할 수 있습니다. 로드 밸런서는 모든 IP 주소 및 포트 조합 간에 트래픽을 균등하게 분배합니다. 이는 여러 컨테이너가 실제로 동일한 Amazon EC2 인스턴스에서 호스팅되고 포트만 다른 경우에도 마찬가지입니다.
이 접근 방식의 한 가지 단점은 비용입니다. 고가용성을 보장하려면 로드 밸런서의 각 가용 영역에 리소스가 있어야 합니다. 따라서 로드 밸런서에 대한 비용과 로드 밸런서를 통과하는 트래픽 양에 대한 비용을 계산하는 오버헤드 때문에 추가 비용이 발생합니다.
하지만 여러 서비스가 로드 밸런서를 공유하도록 하면 오버헤드 비용을 줄일 수 있습니다. 특히 Application Load Balancer를 사용하는 REST 서비스에 적합합니다. 서로 다른 서비스로 트래픽을 라우팅하는 경로 기반 라우팅 규칙을 생성할 수 있습니다. 예를 들어, `/api/user/*` 규칙은 `user` 서비스의 일부인 컨테이너로 라우팅하고 `/api/order/*` 규칙은 연관된 `order` 서비스로 라우팅할 수 있습니다. 이 접근 방식을 사용하면 Application Load Balancer 하나에 대해서만 비용을 지불하고 API에 대해 하나의 일관된 URL을 갖게 됩니다. 하지만 백엔드의 다양한 마이크로서비스로 트래픽을 분산시킬 수 있습니다.
# AWS 계정 및 VPC 간의 Amazon ECS 서비스 네트워킹을 위한 모범 사례
여러 팀과 부서가 있는 조직에 속한 경우 공유 AWS 계정 내의 개별 VPC나 여러 개인 AWS 계정과 연결된 VPC에 서비스를 독립적으로 배포할 가능성이 높습니다. 어떤 방식으로 서비스를 배포하든 VPC 간에 트래픽을 라우팅할 수 있도록 네트워킹 구성 요소를 보완하는 것이 좋습니다. 이를 위해 여러 AWS 서비스를 사용하여 기존 네트워킹 구성 요소를 보완할 수 있습니다.
+ AWS Transit Gateway - 먼저 이 네트워킹 서비스를 고려해야 합니다. 이 서비스는 Amazon VPC, AWS 계정 및 온프레미스 네트워크 간의 연결을 라우팅하기 위한 중앙 허브 역할을 합니다. 자세한 내용은 *Amazon VPC Transit Gateways 설명서*의 [전송 게이트웨이란 무엇입니까?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)를 참조하세요.
+ Amazon VPC 및 VPN 지원 - 이 서비스를 사용하여 사이트 간 VPN 연결을 생성하여 온프레미스 네트워크를 VPC에 연결할 수 있습니다. 자세한 내용은 *AWS Site-to-Site VPN 사용 설명서*의 [AWS Site-to-Site VPN이란?](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html)을 참조하세요.
+ Amazon VPC - Amazon VPC 피어링을 사용하면 동일한 계정 내에서 또는 여러 계정 간에서 여러 VPC를 연결할 수 있습니다. 자세한 내용은 *Amazon VPC 피어링 가이드*의 [VPC 피어링이란?](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html) 섹션을 참조하세요.
+ 공유 VPC - 여러 AWS 계정 간에서 VPC 및 VPC 서브넷을 사용할 수 있습니다. 자세한 내용은 Amazon VPC 사용 설명서의 [공유 VPC 작업](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html)을 참조하세요.**
# Amazon ECS 네트워킹 문제 해결을 위한 AWS 서비스
다음과 같은 서비스와 기능을 사용하면 네트워크 및 서비스 구성에 대한 통찰력을 얻을 수 있습니다. 이 정보를 사용하여 네트워킹 문제를 해결하고 서비스 최적화를 개선할 수 있습니다.
## CloudWatch Container Insights
CloudWatch Container Insights는 컨테이너 애플리케이션 및 마이크로서비스의 지표 및 로그를 수집하고 종합하며 요약합니다. 이러한 지표에는 CPU, 메모리, 디스크, 네트워크 같은 리소스 사용률이 포함됩니다. 지표는 CloudWatch 자동 대시보드에서 사용할 수 있습니다. 자세한 정보는 *Amazon CloudWatch 사용 설명서*의 [Amazon ECS에서 Container Insights 설정](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/deploy-container-insights-ECS.html)을 참조하세요.
## AWS X-Ray
AWS X-Ray는 애플리케이션이 수행하는 네트워크 요청에 대한 정보를 수집하는 데 사용할 수 있는 추적 서비스입니다. SDK를 사용하여 애플리케이션을 계측하고 서비스 간, 서비스와 AWS 서비스 엔드포인트 간 트래픽의 타이밍과 응답 코드를 캡처할 수 있습니다. 자세한 내용은 *AWS X-Ray 개발자 가이드*의 [AWS X-Ray이란 무엇입니까?](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)를 참조하세요.
또한 서비스가 다른 서비스와 네트워킹을 구성하는 방식을 AWS X-Ray 그래프로 살펴볼 수 있습니다. 이 기능을 사용하여 각 서비스 간 링크가 작동하는 방식에 대한 집계 통계를 탐색할 수도 있습니다. 마지막으로, 특정 트랜잭션을 자세히 살펴보고 네트워크 호출을 나타내는 세그먼트가 해당 특정 트랜잭션과 어떻게 연결되어 있는지 확인할 수 있습니다.
이러한 기능을 사용하여 네트워킹 병목 현상이 있는지 또는 네트워크 내의 특정 서비스가 예상과 다르게 작동하는지 파악할 수 있습니다.
## VPC 흐름 로그
Amazon VPC 흐름 로그를 사용하여 네트워크 성능을 분석하고 연결 문제를 디버깅할 수 있습니다. VPC 흐름 로그를 활성화하면 VPC 내의 모든 연결 로그를 캡처할 수 있습니다. 여기에는 Elastic Load Balancing, Amazon RDS, NAT 게이트웨이 및 사용 중인 기타 주요 AWS 서비스와 관련된 네트워킹 인터페이스 연결이 포함됩니다. 자세한 내용은 *Amazon VPC 사용 설명서*의 [VPC 흐름 로그](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)를 참조하세요.
## 네트워크 튜닝 팁
네트워킹을 개선하기 위해 세밀하게 튜닝할 수 있는 몇 가지 설정이 있습니다.
### nofile ulimit
애플리케이션에서 트래픽이 많고 다수의 동시 연결을 처리해야 한다고 예상되는 경우 허용된 파일 수에 대한 시스템 할당량을 고려해야 합니다. 열려 있는 네트워크 소켓이 많은 경우 각 소켓을 파일 설명자로 표시해야 합니다. 파일 설명자 할당량이 너무 낮으면 네트워크 소켓이 제한됩니다. 이로 인해 연결에 실패하거나 오류가 발생합니다. Amazon ECS 태스크 정의에서 파일 수에 대한 컨테이너별 할당량을 업데이트할 수 있습니다. Amazon EC2(AWS Fargate 대신)에서 실행 중인 경우 기본 Amazon EC2 인스턴스에서 이러한 할당량을 조정해야 할 수도 있습니다.
### sysctl net
튜닝 가능한 설정의 또 다른 범주는 `sysctl` net 설정입니다. 구체적인 설정은 사용 중인 Linux 배포판을 참조해야 합니다. 이러한 설정 중 많은 수가 읽기 및 쓰기 버퍼의 크기를 조정합니다. 많은 수의 컨테이너를 포함하는 대규모 Amazon EC2 인스턴스를 실행하는 일부 상황에서 이 기능이 유용할 수 있습니다.