AWS 이벤트 처리 방법

Lambda + SNS & SQS

  • 이벤트가 SQS 대기열에 삽입되고 람다 서비스가 SQS 대기열을 폴링
  • 문제 발생시 다시 SQS로 추가
  • 해당 작업을 계속해서 반복한다
  • 재시도가 반복되면 DLQ(Dead Letter Queue)로 보낼 수 있다

Lambda + SQS FIFO

  • 대기열을 순서대로 처리하도록 보장
  • 한 메시지를 처리하지 못하면 순서 보장을 위해 차단이 발생하여 전체 대기열 처리가 차단됨
  • 마찬가지로 DLQ로 따로 빼서 함수가 계속 동작하도록 할 수 있다

Lambda + SNS

  • 메시지가 비동기적으로 람다에 전달
  • 처리하지 못하면 내부적으로 3번의 재시도를 한다
  • 메시지 제거 or DLQ or 람다 서비스 수준에서 SQS 대기열로 보내 처리할 수 있다

Fan out Pattern

  • 팬아웃 패턴은 다중 SQS 대기열에 데이터를 전송하는 방식
  • SDK → 다중 SQS로 직접 쏘는 건 안정성이 떨어진다 (두 번째 큐에 전송하고 앱에서 오류가 발생하면 세 번째 큐는 메시지를 받지 못한다.)
  • SNS를 추가해 SQS를 구독자로 설정한 뒤 SNS로 토픽을 전송한다

 

S3 Event 알림

  • S3 버킷이 특정 이벤트에만 반응하도록 설정할 수 있다
  • 객체 생성, 삭제, 복원, 복제본 생성시 알림을 보낼 수 있다
  • 이름별 필터링 가능
  • 사용 사례
    • 업로드 된 이미지의 썸네일을 생성하는 경우
  • s3 이벤트를 원하는 만큼 생성할 수 있다
  • 수초~수분까지 걸릴 수 있음

S3 이벤트 알림 with EventBridge

  • s3 버킷에서 일어난 모든 이벤트를 EventBridge로 전송
  • 규칙을 설정하여 18개 이상의 AWS 서비스로 전달이 가능하다.
    • JSON 규칙에 고급 필터링 옵션을 사용해서 객체 크기, 이름 등 필터링한 데이터를 이용 가능
    • 여러 대상에 이벤트를 한번에 보낼 수 있다
    • EventBridge 기능 중 아카이빙, 이벤트 리플레이, 신뢰할 수 있는 이벤트 전송

 

EventBridge에서 API Calls를 인터셉트

  • CloudTrail과 통합한다(모든 API 호출이 CloudTrail로 기록)
  • CloudTrail에서 이벤트를 생성하여 EventBridge로 보낼 수 있다

 

API Gateway - Kinesis Data Streams 통합

 

AWS의 캐싱전략

  • CloudFront
  • API Gateway도 캐싱이 가능하지만 리전서비스라서 글로벌 서비스에는 부족
  • Redis 혹은 DAX 등을 사용할 수 있을 때 ec2 혹은 람다에서 캐싱 전략을 세울 수 있다
  • s3에는 캐싱 기능이 없다
  • 뒤쪽으로 갈 수록 비용과 지연시간이 증가한다
  • 캐싱은 어느 레이어에서나 가능하다. 고민해야할 것은 애플리케이션을 어떻게 설정할지에 달린 것

 

AWS에서 IP 주소 차단

  • VPC레벨의 NACL → 차단 규칙을 만들 수 있다(IP 하나를 차단할 수도 있음)
  • ALB 보안 그룹 → 클라이언트를 허용
    • NLB의 경우 보안그룹이 없다.
  • ec2 보안그룹 → 차단 규칙을 만들 순 없고 허용 규칙만 만들 수 있다 권한이 부여된 Client만 알면 IP의 서브셋을 만들어 허용 가능
    • 만약 글로벌 앱이라면 IP를 전부 알 수 없을뿐더러 보안 그룹도 도움이 되지 않는다
  • ec2 인스턴스에서 방화벽 소프트웨어 실행(CPU 비용이 발생)
  • WAF(Web Application Firewall) → 추가 비용
    • IP주소에 대한 필터링 가능
    • 클라이언트로부터 동시에 많은 요청을 받지 않을수도 있다(요청 최대 제한)
  • CloudFront를 설치하는 경우 NACL은 더이상 도움이 되지 않는다(CloudFront 공용 IP가 전송)
    • Geo Restriction 혹은 WAF가 필요하다

 

AWS의 고성능 컴퓨팅(HPC - High Performance Computing)

  • 클라우드는 고성능 컴퓨팅을 실행하기에 최적
    • 많은 리소스를 즉각적으로 생성 가능
    • 리소스 추가도 쉽고 사용한 만큼만 지불가능
  • 필요에 따라 필요한 만큼 가질 수 있다
  • 기상 예측, 머신 러닝, 딥러니 자율주행등

 

HPC를 돕는 AWS 서비스 - 데이터 관리 방식과 전송

  • Direct Connect - 초당 GB의 속도로 프라이빗 보안 네트워크를 통해 대용량 데이터 전송 가능
  • 스노우볼 & 스노우모바일 - 대용량 전송
  • AWS DataSync - 대용량 데이터 전송 (온프레미스, NFS, SMB s3, EFS, Windows FSx

 

HPC를 돕는 AWS 서비스 - Compute & Networking

  • ec2 인스턴스
    • cpu, gpu, 메모리 최적화
    • 스팟인스턴스
  • 클러스터 유형의 ec2 배치그룹 - 최고의 네트워크 성능을 가질 수 있다

 

인스턴스의 성능향상

  • ec2 Enhanced Networking → SR-IOV
    • 더 높은 대역폭과 적은 지연시간
    • Elastic Network Adapter(ENA) 100Gbps까지 올려준다
      • 대역폭과 초당 패킷을 증가
    • Intel의 82599VF를 사용 - 레거시
      • 오래된 ENA이다
  • Elastic Fabric Adapter(EFA)
    • 고성능 컴퓨팅을 위한 개선된 ENA
    • 리눅스에서만 동적
    • 노드간 소통 밀집된 워크로드에서 유용(분산 계산)
    • Message Passing Interface(MPI) 표준을 사용
      • 리눅스 OS를 우회하여 안정적이고 더 짧은 송신을 보장
    • 리눅스 인스턴스 + 많은 워크로드 처리 + EFA → 높은 네트워크 성능 보장

ENA - EFA - ENI 차이점을 물어보곤 한다

 

Storage

  • Instance-attached storage
    • EBS
    • instance store - 수백만 IOPS까지확장 망가지면 데이터 손상 가능성
  • Network Storage
    • s3
    • EFS
    • FSx for Lustre - HPC 전용 파일 시스템 → 백엔드에서 s3로 제공된다

 

Automation and Orchestration

  • AWS Batch - 다중노드병렬 작업 → 작업 예약과 ec2 인스턴스 실행이 쉬워짐
  • AWS Parallel Cluster - 오픈소스 클러스터 관리 도구 HPC를 AWS에 배포
    • 텍스트파일로 구성해서 AWS로 배포
    • VPC와 서브넷 및 클러스터 타입, 인스턴스 타입 자동화
    • EFA와 함께 사용한다 - 클러스터에서 EFA를 활성화하는 매개변수가 텍스트파일에 있다 (네트워크 향상 가능)

 

HPC는 단일 서비스가 아닌 여러 서비스의 집합 따라서 AWS의 컴퓨팅 성능을 최대화하려면 위 내용들을 잘 알고있어야함

 

 

EC2 인스턴스 고가용성

인스턴스는 기본적으로 하나의 AZ에서 실행되기 때문에 설정을 만져줘야한다

  • CloudWatch Event

 

  • ASG를 활용한 고가용성(탄력적 IP를 적용하기 위한 ec2 인스턴스 Role이 있어야한다)

'TIL > AWS' 카테고리의 다른 글

AWS 백서  (0) 2023.06.20
기타 AWS 서비스  (0) 2023.06.19
AWS 재해복구와 마이그레이션  (1) 2023.06.17
AWS 네트워킹 - VPC  (0) 2023.06.17
AWS 보안 및 암호화  (0) 2023.06.11
복사했습니다!