이벤트 처리

AWS에서의 이벤트 처리 및 다양한 처리 방법

1. SQS와 Lambda 사용

• 작동 방식: 이벤트가 SQS 대기열에 삽입되고, Lambda 함수가 대기열을 폴링하여 처리한다. 문제가 발생하면 메시지는 SQS로 다시 삽입되고 재시도한다.
• 메시지가 반복적으로 실패할 경우, 5번의 재시도 후 데드 레터 대기열(DLQ)로 전송되도록 설정할 수 있다.

2. SQS FIFO와 Lambda 사용

• 작동 방식: FIFO(선입선출) 대기열에서는 메시지가 도착한 순서대로 처리된다. Lambda는 순차적으로 메시지를 처리한다.
• 제약점: 한 메시지가 처리되지 않으면 전체 대기열이 차단된다. 이 경우에도 데드 레터 대기열(DLQ)을 사용하여 메시지를 처리할 수 있다.

3. SNS와 Lambda 사용

• 작동 방식: SNS를 통해 메시지를 Lambda로 비동기적으로 전달한다. Lambda는 처리하지 못하는 매세지가 발생하더라도 내부적으로만 재시도를 총 3번 까지 수행하고, 처리하지 못한 메시지는 DLQ로 전송하거나 SQS 대기열로 보낼 수 있다.

4. 팬아웃 패턴 (Fan-Out Pattern)

• 작동 방식: SNS 주제를 사용하여 하나의 메시지를 여러 SQS 대기열로 팬아웃한다. SNS 주제에 메시지를 전송하면 모든 구독자에게 전달된다.
• 기본적으로 애플리케이션에서 메시지를 여러 대기열로 직접 전달하는 방식은 안정성이 떨어지며, 메시지가 전달되지 않으면 전체 처리 흐름이 중단될 수 있다. SNS를 중간에 두면 안정성이 개선된다.

5. S3 이벤트 알림

• 작동 방식: Amazon S3에서 객체 생성, 삭제 등 이벤트가 발생하면(객체 이름별로 필터링도 가능) 이를 SNS, SQS, 또는 Lambda로 전송하여 알림을 받을 수 있다.
• 제약점: 이벤트 알림은 보통 수초 이내에 전송되지만, 경우에 따라 몇 분이 소요될 수 있어 실시간 처리에 지연이 발생할 수 있다.

6. Amazon EventBridge 사용

• 작동 방식: S3 버킷의 이벤트를 EventBridge로 전송하고, 이를 규칙에 맞게 여러 AWS 서비스로 전달한다. JSON 필터링을 통해 메타데이터, 객체 크기 등으로 이벤트를 세밀하게 필터링할 수 있다.

7. CloudTrail과 EventBridge 통합

• 작동 방식: CloudTrail의 로그 이벤트를 EventBridge로 트리거하여, API 호출에 따른 이벤트를 처리한다. 예를 들어, DynamoDB 테이블 삭제 이벤트를 감지하여 경고를 SNS로 전송할 수 있다.

8. 외부 이벤트 처리 (API Gateway + Kinesis)

• 작동 방식: API Gateway에 클라이언트가 요청을 보내면, 이 요청이 Kinesis Data Stream으로 전송된다. 이후 Kinesis Data Firehose를 통해 최종적으로 S3에 저장된다.

---

캐싱 전략

주요 캐싱 서비스

• CloudFront: 엣지 캐싱을 통해 사용자가 최대한 가까운 위치에서 데이터를 빠르게 받게 된다. 하지만 백엔드에서 변화가 있거나 캐시된 데이터가 오래될 수 있어 TTL(Time-To-Live)을 설정해 캐시 유효성을 관리한다.
• API Gateway: 리전에서 캐시를 지원하기 때문에 CloudFront와 함께 사용할 필요가 없다. 클라이언트와 API Gateway 간에 네트워크가 형성되며, 캐시는 리전에 묶여서 해당 리전 내에서 빠른 응답을 제공한다. CloudFront 없이 API Gateway에서 직접 캐싱을 사용할 수 있다.
• App logic(EC2/Lambda): 데이터베이스 접근을 줄이기 위해 Redis, Memcached, DAX와 같은 캐시를 사용할 수 있다. 반복적인 쿼리나 복잡한 쿼리 결과를 캐시하여 앱 논리에서 쉽게 접근할 수 있게 한다. 이를 통해 데이터베이스의 압력을 줄이고 읽기 용량을 늘린다.

CloudFront -> API GateWay -> Redis,Memcached,DAX 순으로 뒤로 갈수록 비용과 지연 시간이 늘어난다.

캐싱 전략 적용 예시

• 정적 콘텐츠: CloudFront를 사용하여 클라이언트와 가까운 위치에서 데이터를 캐시한다. CloudFront는 S3에서 데이터를 소싱하여 빠른 응답을 제공할 수 있다.
• 동적 콘텐츠: 애플리케이션 논리와 데이터베이스 간의 캐시를 사용하여 성능을 최적화한다. 자주 발생하는 쿼리 결과를 캐시하여 데이터베이스를 히트하는 것을 방지한다.

---

네트워크와 보안

• 클라이언트가 애플리케이션에 접근할 때 여러 보안 계층을 통해 트래픽을 필터링할 수 있다.
• 악의적인 행위자가 될 수 있는 IP 주소를 차단하려는 경우, 여러 가지 보안 메커니즘을 사용할 수 있다. 여러가지 방어선을 알아보자.

VPC 수준에서의 네트워크 ACL

• 네트워크 ACL은 VPC 수준에서 설정되어 클라이언트 IP 주소를 차단할 수 있다.
• 매우 간단하고 저렴하게 구현할 수 있으며, 트래픽을 거부하는 규칙을 설정할 수 있다.

EC2 보안 그룹

• EC2 보안 그룹은 연결을 허용하는 규칙만 설정할 수 있으며, IP 주소를 차단할 수 없다.
• 보안 그룹은 EC2 인스턴스로의 접근을 특정 IP 범위로 제한하는 데 사용된다.
• 애플리케이션이 글로벌인 경우 애플리케이션에 액세스할 모든 IP 주소를 알 수 없어 보안 그룹은 큰 도움이 되지 않을 것이다.

호스트 방화벽

• EC2 인스턴스 내에서 선택적으로 호스트 방화벽 소프트웨어를 실행하여, 클라이언트의 요청을 차단할 수 있다.
• 요청이 이미 EC2 인스턴스에 도달한 후에는 CPU 비용이 발생하며, 이를 통해 요청을 처리하고 차단할 수 있다.

Application Load Balancer(ALB)

• ALB는 EC2 인스턴스와 클라이언트 간의 연결을 종료하고, 새로 연결된 요청을 EC2 인스턴스로 전달한다.
• EC2의 보안 그룹에서 ALB의 보안 그룹으로부터 온 인바운드 트래픽만을 허용하도록 설정한다.
• 글로벌 애플리케이션에서는 ALB가 모든 클라이언트의 IP를 받아들이고, 허용할 IP 범위를 알고 있는 경우 ALB의 보안 그룹을 통해 허용할 IP 주소를 설정한다.

WAF (웹 애플리케이션 방화벽)

• WAF를 사용하여 ALB에 대한 IP 주소 필터링 및 복잡한 요청 제한을 설정할 수 있다.
• WAF는 클라이언트와 ALB 사이에 있는게 아닌 우리가 ALB에 설치한 서비스이다. 복잡한 보안 규칙을 정의할 수 있다.
• WAF를 사용하면 IP 차단, 특정 요청 제한 등을 할 수 있다.
• 부가 서비스이자 방화벽 서비스이기 때문에 조금 더 비싸다.

CloudFront와 ALB

• CloudFront가 ALB 앞에 위치할 경우, 그것은 VPC 외부에 위치한다. 따라서 ALB는 엣지 위치에서 오는 클라우드 프론트의 모든 공용 IPS를 허용해야 한다.(온라인에 목록이 있음)
• CloudFront에서 오는 클라이언트의 IP 주소는 ALB에서 볼 수 없다.
• 이 경우, CloudFront의 지리적 제한 기능이나 WAF를 사용하여 클라이언트 IP를 차단할 수 있다.

WAF(Web Application Firewall) 설정은 Amazon CloudFront, Application Load Balancer (ALB), API Gateway 에서 사용 가능하다.

• CloudFront의 공용 IP는 ALB로 전달되며, 이로 인해 ALB에서 클라이언트의 실제 IP를 볼 수 없으므로 추가적인 필터링을 CloudFront에서 해야 한다.

---

고성능 컴퓨팅(High Performance Computing, HPC)

HPC가 클라우드에서 최적인 이유

• 즉각적인 리소스 생성: 클라우드에서는 필요한 만큼의 리소스를 즉시 생성할 수 있다.
• 리소스 확장: 작업량에 따라 추가 리소스를 더하여 결과 추출 시간을 단축할 수 있다.
• 비용 절감: 사용한 리소스만큼만 비용을 지불하며, 작업 후 리소스를 제거하여 요금이 발생하지 않도록 할 수 있다.

HPC의 활용 분야

• 유전체학, 컴퓨터화학, 금융 위험 모델링, 기상 예측, 머신 러닝, 딥 러닝, 자율 주행 등에서 필요하다.

HPC를 지원하는 AWS 서비스

• 데이터 전송:

  • AWS Direct Connect: 초당 GB 속도로 프라이빗 보안 네트워크를 통해 클라우드로 데이터를 전송한다.
  • Snowball/Snowmobile: 대용량 데이터를 물리적으로 클라우드로 이동시킨다.
  • DataSync: 온프레미스 시스템에서 AWS 서비스로 대용량 데이터를 전송한다.

• 컴퓨팅과 네트워킹:

  • EC2 인스턴스: CPU나 GPU에 최적화된 인스턴스를 사용하여 HPC 작업을 처리할 수 있다.
  • 스팟 인스턴스: 비용을 절감할 수 있으며, 오토 스케일링으로 계산 리소스를 효율적으로 관리할 수 있다.
  • 클러스터 배치 그룹: EC2 인스턴스가 서로 통신해야 하거나 분배된 형태로 동작할 경우 클러스터 유형의 EC2 배치 그룹을 사용하면 최고의 네트워크 성능을 발휘한다. 클러스터 배치 그룹의 경우 랙(Rack)이 전부 같다. 모두 같은 AZ에 있는 것이다.
  • ⭐EC2 Enhanced Networking(SR-IOV): 대역폭을 증가시키고 지연 시간을 줄여주는 기술이다.
    • 구현 방법 1. Elastic Network Adapter(ENA)를 사용해 네트워크 속도를 100Gbps까지 올려준다.
    • 구현 방법 2. Intel의 82599VF를 사용해 최대 10Gbps까지 빨라진다. 오래된 ENA.
  • ⭐Elastic Fabric Adapter (EFA): HPC와 분산 계산을 위한 개선된 ENA로 고성능 네트워킹 장치이다. Linux에서만 사용 가능하고 노드 간 소통이나 밀집된 워크 로드 처리에 좋다. ENA가 사용하는 게 Message Passing Interface(MPI)표준이다. 이 표준은 Linux OS를 우회하여 안정적이고 지연시간이 더 짧은 송신을 보장한다.

• 스토리지 옵션:

  • EBS (Elastic Block Store): io2 Block Express로 최대 256,000 IOPS까지 확장 가능하다.
  • 인스턴스 스토어: 수백만 IOPS로 확장할 수 있지만 인스턴스가 종료되면 데이터가 손실될 수 있다.
  • Amazon S3: 대용량 블롭 데이터를 저장하는 데 사용된다.
  • EFS (Elastic File System): 파일 시스템의 크기에 따라 IOPS가 확장된다. 프로비저닝된 IOPS 모드를 써서 EFS에서 높은 IOPS를 얻기도 한다.
  • FSx for Lustre: HPC에 최적화된 파일 시스템으로 수백만의 IOPS를 제공하며 백엔드에서 S3로 제공된다.

• 자동화 및 오케스트레이션:

  • AWS Batch: 다중 노드 병렬 작업을 수행하며, 여러 EC2 인스턴스를 활용한 작업 관리가 용이하다.
  • AWS ParallelCluster: 오픈 소스 클러스터 관리 도구로 HPC를 텍스트 파일로 구성해서 AWS에 배포한다. VPC, 서브넷, 인스턴스 타입을 자동화하여 HPC 클러스터를 구성한다. 네트워크 성능을 향상시키기 위해 EFA와 함께 사용한다. 클러스터 상에서 EFA를 활성화하는 매개변수가 텍스트 파일에 있기 때문이다.

---

EC2 인스턴스 가용성 높이기

EC2 인스턴스 한 개의 가용성을 높이는 방법을 알아보자

기본 EC2 인스턴스 가용성 문제

• EC2 인스턴스는 기본적으로 하나의 가용 영역에서 실행된다. 이로 인해 단일 장애 지점(Single Point of Failure, SPOF)이 존재한다. 이를 해결하려면 여러 방법을 사용하여 가용성을 높일 수 있다.

탄력적 IP와 대기 인스턴스 활용

• EC2 인스턴스에 탄력적 IP를 연결하여 사용자가 웹 서버에 액세스할 수 있도록 한다. 웹 서버에 문제가 발생하면 대기 인스턴스가 활성화되어 장애 조치(Failover)가 이루어지도록 한다.
• CloudWatch Events와 경보를 설정하여 인스턴스의 상태를 모니터링하고, 문제가 발생하면 람다 함수를 통해 자동으로 대기 인스턴스를 탄력적IP와 연결해 활성화한다.

오토 스케일링 그룹(ASG) 활용

• 오토 스케일링 그룹(ASG)을 사용해서 인스턴스의 최솟값과 최댓값, 적정값을 모두 1로 설정하고 두 개의 가용 영역에 지정한다. EC2 인스턴스가 실행될 때 User Data에서 탄력적 IP주소를 태그에 기반해서 연결한다. 그럼 ASG는 상태 이상인인스턴스를 종료시키고 탄력적 IP주소는 해제된다. 자동으로 다른 가용 영역에 새 인스턴스를 생성하여 서비스를 제공하고 생성된 인스턴스에서 User Data를 실행하면서 탄력적 IP주소와 연결된다.
• 이 과정에서 탄력적 IP를 새 인스턴스에 연결하여 CloudWatch 알람과 람다 함수 없이도 장애조치가 취해진다.
• EC2 인스턴스가 탄력적 IP 주소를 연결하기 위해 API를 직접적으로 호출할 때 해당 인스턴스가 탄력적 IP 주소를 연결하기 위해 API를 호출할 수 있는 인스턴스 Role이 있는지 확인한다.

ASG + EBS 볼륨을 통한 데이터 고가용성

• EC2 인스턴스를 데이터베이스로 사용할 경우 인스턴스가 종료될 때 ASG의 수명 주기 후크를 사용해 EBS 볼륨에서 스냅샷을 얻는 스크립트를 생성할 수 있다. 이 스냅샷을 다른 가용 영역에 복사하여 새로운 인스턴스를 생성한다.

  ASG 수명주기후크: ASG 그룹 내의 EC2의 특정 이벤트가 발생할 때 이를 지연시키고 사용자 정의 작업(스크립트 실행, 데이터 백업 등)을 수행할 수 있도록 한다.

  ASG에서 EC2 인스턴스는 아래와 같은 상태를 거친다.
  Pending → (생성 중)
  InService → (정상적으로 실행됨)
  Terminating → (종료 중)
  Terminated → (완전히 종료됨)
  수명 주기 후크를 사용하면 Pending(생성 중) 또는 Terminating(종료 중) 단계에서 트리거되어 특정 작업을 수행할 수 있다.

• EC2 인스턴스가 종료되자마자 스냅샷이 발동되기 때문에 EBS 볼륨에 문제가 생겼다는 것을 알 수 있다.
• EBS 스냅샷을 올바르게 태그하고 ASG는 새로 EC2 인스턴스를 생성하고 태그를 통해 EBS볼륨과 새로 생성된 대체 EC2 인스턴스를 연결시킬 것이다.
• 대체 EC2 인스턴스에 EBS 볼륨을 연결하면 EC2 사용자는 이것만 확인하고 탄력적 IP를 직접적으로 연결한다.