Solution Architect
EC2
ASG의 최소 용량을 2로 선택하는 경우 항상 2개의 EC2 인스턴스를 실행하게 된다. 이 때 2개의 인스턴스를 예약하는 형태로 추가적인 비용을 절감할 수 있다.
새로운 인스턴스가 시작될 때 일시적이거나 온디맨드로 사용하거나, 비용을 줄이기 위해 인스턴스가 종료될 수도 있지만 스팟 인스턴스를 사용할 수도 있다.
다중 AZ에서 구성된 ELB의 Stickness 기능을 이용하면 한 사용자의 요청은 하나의 동일한 인스턴스로 전달된다.
EBS 볼륨은 특정 AZ에만 저장되므로 동일 AZ의 EC2 인스턴스에만 접근 가능하다. 따라서 여러 AZ에서 접근하려면, EFS를 사용해야 한다.
Golden AMI를 이용해 애플리케이션과 OS 종속성 등 모든 것을 사전에 설치해둔 후 새 EC2 인스턴스가 빠르게 구동될 수 있도록 한다.
데이터베이스 URL과 비밀번호 등 가벼운 데이터를 가져올 때에는 EC2 사용자 데이터를 사용하여 부트스트래핑을 활용할 수 있다.
RDS, EBS는 스냅샷을 기반으로 데이터를 가져올 수 있다.
로드밸런서, ASG, RDS, ElastiCache를 다중 AZ에 두어야 한다. Route53은 기본적으로 고가용성을 제공한다.
이벤트 처리
IP 주소 차단
매우 중요한데 왜냐하면 클라이언트에서 요청이 와서
애플리케이션에 도달하기까지 과정이 어떻게 진행되는지 실제로 잘 이해하고 싶기 때문이죠
때로는 악의적인 행위자가 될 수 있는 IP 주소를 클라이언트로부터 차단해야 할 필요가 있을 수 있습니다
우리 애플리케이션에 액세스하려고 할 수도 있습니다
그래서 우리는 방어선을 알고자 합니다
그러면 보안 그룹이 설정된 VPC 내의 EC2 인스턴스가 있고 해당 인스턴스에 공용 IP가 있는
매우 간단한 솔루션 아키텍처부터 시작해 보겠습니다
따라서 공개적으로 액세스할 수 있겠죠
클라이언트는 이러한 방식으로 우리의 EC2 인스턴스에 접근하게 됩니다
해당 클라이언트를 차단하고 싶다고 가정해 보겠습니다
첫 번째 방어선은 VPC 수준에서 설정된 네트워크 ACL입니다
이 네트워크 ACL에서 이 클라이언트 IP 주소에 대한 거부 규칙을 설정할 수 있습니다
매우 간단하고, 매우 빠르고, 매우 저렴합니다
그러면 클라이언트가 차단됩니다
그러면 EC2 인스턴스의 보안 그룹에서는 거부 규칙을 설정할 수 없습니다
허용 규칙만 가질 수 있습니다
승인된 클라이언트의 하위 집합만이 EC2 인스턴스에 액세스할 수 있다면
보안 그룹에서 EC2 인스턴스로 접근을 허용할 IP 주소의 하위 집합만 정의하는 것이 좋습니다
그러나 애플리케이션이 글로벌인 경우 애플리케이션에 액세스할 모든 IP 주소를 알 수 없습니다
그래서 여기 보안 그룹은 큰 도움이 되지 않을 것입니다
마지막으로, EC2 인스턴스 내에서 선택적으로 방화벽 소프트웨어를 실행하여
소프트웨어 내에서 클라이언트의 요청을 차단할 수 있습니다
이제, 요청이 이미 EC2 인스턴스에 도달한 경우
해당 요청은 처리되어야 하며 이로 인해 CPU 비용이 발생할 것입니다
이는 매우 간단한 사용 사례이지만 보안 그룹과 호스트 방화벽 간의 차이점을 이렇게 확인했습니다
이제 한 단계 더 나아가 보겠습니다
Application Load Balancer(ALB)를 도입합니다
이 ALB는 다시 말해 우리의 VPC 내에 정의됩니다
아직 EC2 인스턴스가 있습니다
하지만 지금은 두 개의 보안 그룹이 있습니다
ALB 보안 그룹과 EC2 보안 그룹이 있습니다
따라서 이 경우 이 아키텍처에서는 로드 밸런서가 클라이언트와 EC2 사이에 있게 되며
이를 통해 연결 종료라는 작업을 수행합니다
따라서 클라이언트는 실제로 ALB에 연결되며, 그러면 연결이 종료되고
ALB에서 EC2 인스턴스로 새로운 연결이 시작됩니다
이 경우, EC2 보안 그룹은 ALB의 보안 그룹을 허용하도록 구성되어야 합니다
왜냐하면 EC2 인스턴스가 사설 서브넷에 배포되어 사설 IP를 가지면
인스턴스가 보는 트래픽의 소스는 클라이언트가 아니라 ALB에서 나오기 때문입니다
따라서 보안 그룹 관점에서는 ALB의 보안 그룹만을 허용하고
이쪽에서는 안전을 확보할 수 있습니다
이제 보안 그룹의 ALB입니다
ALB의 보안 그룹입니다
우리는 클라이언트를 허용해야 합니다
그리고 다시 말해, IP 범위를 알고 있는 경우 보안 그룹을 구성할 수 있습니다
글로벌 애플리케이션이라면 모두 허용해야 합니다
그리고 우리의 방어선은 네트워크 ACL 수준이 될 것입니다
네, 이 내용은 이해가 되고 이미 알고 있어야 할 내용이죠
네트워크 로드 밸런서의 경우 유사한 방식으로
보안 그룹을 네트워크 로드 밸런서에 연결하고 보안 그룹을 EC2 인스턴스에 연결합니다
네트워크 로드 밸런서에서 EC2 보안 그룹으로의 트래픽과
클라이언트에서 NLB 보안 그룹으로의 트래픽이 허용되도록 규칙을 설정하고 그 과정에서 트래픽을 제어하도록 합니다
이제 애플리케이션 밸런서로 돌아가서 트래픽을 더 많이 필터링할 수 있는 방법을 살펴보겠습니다
IP를 거부하기 위해 할 수 있는 방법은 WAF나 웹 애플리케이션 방화벽을 설치하는 것입니다
이 WAF는 부가 서비스이자 방화벽 서비스이기 때문에 조금 더 비쌀 것입니다
하지만 IP 주소에 대한 복잡한 필터링을 수행할 수 있습니다
그리고 클라이언트로부터 동시에 많은 요청이 들어오지 않도록 규칙을 설정할 수 있습니다
따라서 ALB의 보안에 대해 제어 권한이 강화됩니다
따라서 WAF는 클라이언트와 ALB 사이에 있는 서비스가 아닙니다
우리가 ALB에 설치한 서비스입니다
그리고 우리는 여러 가지 규칙을 정의할 수 있습니다
그래서 이것은 또 하나의 방어선이 됩니다
마찬가지로 ALB 앞에 클라우드 프론트(CloudFront)를 사용하는 경우 그것은 VPC 외부에 위치합니다
따라서 ALB는 엣지 위치에서 오는 클라우드 프론트의 모든 공용 IPS를 허용해야 합니다
그리고 온라인에 목록이 있습니다
그게 다입니다
따라서 ALB에서는 클라이언트 IP를 볼 수 없습니다
표시되는 것은 클라우드 프론트의 공용 IP입니다
따라서 여기 VPC 경계에 위치한 네트워크 ACL은
클라이언트 IP 주소를 차단하는 데 도움이 되지 않기 때문에 전혀 도움이 되지 않습니다
이 경우 클라우드 프론트에서 클라이언트를 차단하려면 두 가지 방법이 있습니다
우리가 어떤 나라의 공격을 받았다고 가정해 봅시다
그렇다면 클라우드 프론트의 지리적 제한 기능을 사용하여 특정 국가에서의 접근을 차단하거나
특정 IP가 문제를 일으키는 경우 WAF, 즉 웹 애플리케이션 방화벽을 사용하여
이전과 마찬가지로 IP 주소 필터링을 수행할 수 있습니다
하지만 보시다시피 현재의 아키텍처를 기반으로 IP 주소를 차단하는 다양한 방어선을 갖추고 있습니다
이 모든 요소를 종합하면 모든 것이 명확하게 이해됩니다
네트워크 관점에서 어떤 일이 발생하는지, 보안 그룹을 어떻게 올바르게 구성하는지
IP 주소 필터링을 어디에 설정해야 하는지를 정확하게 다이어그램을 통해 보여 주는 것은 정말 좋다고 생각합니다
이 강의가 잘 이해됐으면 좋겠습니다
HPC
바로 고성능 컴퓨팅 혹은 HPC라고 합니다
클라우드는 고성능 컴퓨팅을
실행하기에 최적입니다 왜 그럴까요?
많은 리소스를 즉각적으로 생성할 수 있기 때문입니다
그리고 리소스를 추가해서
결과 추출 시간을 단축할 수 있죠 또 사용량만큼만 비용을 지불하면 되죠
작업이 끝나고 나면 전체 인프라를 제거해서
요금이 청구되지 않게 할 수 있습니다
즉 필요에 따라 컴퓨팅을 수행하는 수많은 인스턴스를 가질 수 있고
작업이 완료되면 사용량만큼만 비용을 지불한다는 겁니다
이런 게 클라우드의 바람직한 사용 사례라고 할 수 있죠
AWS에서도 이렇게 하기를 점점 더 권장하고 있습니다
언제 이런 HPC가 필요할까요?
유전체학이나 컴퓨터화학 금융 위험 모델링, 기상 예측
머신 러닝, 딥 러닝 자율 주행 등에 필요하죠
그러면 HPC의 작업을 돕는 AWS 서비스는 무엇이 있을까요?
첫 번째는 데이터 관리 방식과
AWS로 데이터를 전송하는 방법에 관한 겁니다
먼저 AWS Direct Connect는
초당 GB의 속도로 프라이빗 보안 네트워크를 통해
클라우드로 데이터를 전송해요
자세히 배운 내용이죠
Snowball과 Snowmobile도 있어요
물리적 라우팅을 통해 클라우드로 PB 단위 데이터를 옮길 때 사용하고
주로 대용량 전송에 아주 적합하죠
DataSync의 경우 DataSync 에이전트를 설치해
대용량의 데이터를 전송합니다
온프레미스, NFS, SMB 시스템에서 S3, EFS나 Windows용 FSx로 전송하죠
좋아요, 넘어갑시다
HPC의 컴퓨팅과 네트워킹은 어떨까요? 아주 중요한 부분입니다
당연하겠지만 EC2 인스턴스가 있겠죠
실행하려는 작업에 따라 CPU나 GPU에
최적화된 인스턴스가 있습니다
또한 스팟 인스턴스나 스팟 플릿(Fleet)을 사용해
비용을 크게 절약하고 수행하는 계산을 기반으로
플릿을 오토 스케일링할 수 있습니다
그리고 EC2 인스턴스가 서로 통신해야 하거나
분배된 형태로 동작할 경우
클러스터 유형의 EC2 배치 그룹을 사용하면
최고의 네트워크 성능을 발휘하죠
이 예시에서는 짧은 지연 시간의 10Gbps 네트워크가 될 겁니다
클러스터 배치 그룹의 경우 랙(Rack)이 전부 같습니다
모두 같은 AZ에 있는 거죠
그러면 EC2 인스턴스의 성능을 더 향상하는 방법은 무엇일까요?
EC2 Enhanced Networking입니다 또한 SR-IOV라고도 하는데
더 넓은 대역폭이 제공되고 더 높은 PPS
즉 초당 패킷이 높아지며 지연 시간이 짧아집니다
EC2 Enhanced Networking은 어떻게 구현할까요??
최근에 가장 흔히 쓰이는 방법은
Elastic Network Adapter(ENA)입니다
네트워크 속도를 100Gbps까지 올려주죠
시험에 나오니 꼭 알아두세요
ENA를 사용하는 게 한 가지 방법으로
대역폭과 초당 패킷을 증가시키며 지연 시간을 줄여줍니다
두 번째는 아주 복잡한 방법인데요 Intel의 82599VF라는 걸 사용해
최대 10Gbps까지 빨라집니다 오래된 ENA죠
이 서비스를 설명하는 이유는 시험에 나올 수도 있기 때문이죠
시험에서 보면 뭔지는 알아야죠
ENA와 Intel 모두 여러분의 인스턴스에서
EC2 Enhanced Networking을 이용할 수 있게 합니다
더 나아가서 Elastic Fabric Adapter(EFA)를 사용해도 됩니다
HPC, 고성능 컴퓨팅을 위해 개선된 ENA인데요
Linux에서만 사용 가능합니다
노드 간 소통이나 밀집된 워크 로드 처리에 좋아요
분산 계산과 같은 경우입니다
그 이유는 ENA가 사용하는 게 Message Passing Interface(MPI) 표준이거든요
그리고 이 표준은 Linux OS를 우회하여
안정적이고 지연시간이 더 짧은 송신을 보장합니다
따라서 Linux 인스턴스가 있고
많은 워크로드를 처리해야 할 경우에는
EFA를 사용하면 OS를 우회하여 보다 높은 네트워크 성능을 제공할 수 있죠
그러니 시험 문제에서
흔히 물어보는 것이 바로 ENA와
EFA와 ENI 등의 차이점입니다
지금 짚고 넘어가는 게 좋겠죠
이 개념들에 대해서는 정확히 알고 계셔야 합니다
이렇게 데이터를 전송했고 또 컴퓨팅하고
네트워크까지 구성했는데 데이터는 어떻게 저장하죠?
몇 가지 방법이 있는데 인스턴스가 연결된 스토리지를 사용하는 방법이 있습니다
EBS의 경우 io2 Block Express로 256,000IOPS까지 확장합니다
인스턴스 스토어의 경우
수백만의 IOPS로 확장해요 EC2와 연결되어 하드웨어에 있고
지연 시간이 짧지만 인스턴스가 망가지면 손상될 수 있습니다
Amazon S3 등의 네트워크 스토리지를 써도 되죠
대용량 블롭 데이터를 저장할 때 사용합니다
파일 시스템 말고 큰 객체 저장을 위한 겁니다
EFS를 사용하면 IOPS가 파일 시스템의
전체 크기에 따라 확장됩니다
프로비저닝된 IOPS 모드를 써서 EFS에서 높은 IOPS를 얻기도 해요
앞서 HPC 전용 파일 시스템이 있었는데요
FSx for Lustre라고 합니다 Lustre는 Linux와 Cluster용이고
HPC에 최적화되어 수백만의 IOPS를 제공하며
백엔드에서 S3로 제공됩니다
이렇게 다양한 방법이 있습니다
마지막으로 자동화 및 오케스트레이션은 어떨까요?
먼저 AWS Batch를 사용하면
이름에서도 알 수 있듯
다중 노드 병렬 작업을 수행할 수 있고
여러 EC2 인스턴스에 걸쳐 작업할 수 있어요
AWS Batch를 사용하면 작업 예약과
AWS Batch 서비스로 관리되어 EC2 인스턴스 실행이 쉬워집니다
때문에 AWS Batch는 HPC에서 많이 선택하는 방법이죠
AWS ParallelCluster는 오픈 소스 클러스터 관리 도구로
HPC를 AWS에 배포합니다
텍스트 파일로 구성해서 AWS로 배포하는 겁니다
그리고 VPC와 서브넷 및 클러스터 타입과
인스턴스 타입 생성을 자동화합니다
이 역시 시험에 나오는 내용으로
AWS ParallelCluster는 EFA와 함께 사용해요
클러스터 상에서 EFA를 활성화하는 매개변수가
텍스트 파일에 있기 때문입니다 따라서 네트워크 성능이 향상되고
HPC 클러스터를 구현할 수 있죠
HPC가 시험에 점점 많이 출제되는 경향이 있는데요
단일 서비스가 아니라 여러 옵션과 서비스의 결합이에요
AWS에서 컴퓨팅 성능을 최대화하려면
이 내용을 잘 이해하고 계셔야겠죠
Last updated