섹션 29: 더 많은 솔루션 아키텍처

AWS의 이벤트 처리

1. 첫 번째 SQS와 Lambda 사용
   • 이벤트가 SQS 대기열에 삽입
   • Lambda 서비스가 SQS 대기열을 polling
   • 문제가 발생하면 해당 메시지를 다시 SQS 대기열에 입력하고 폴링을 재시도
     • 다섯 번의 재시도 후에는 데드 레터 대기열(DLQ)로 보내도록 SQS 설정 가능
2. 두 번째 SQS FIFO와 Lambda 사용
   • SQS FIFO에서 문제가 생기면 전체 대기열 처리가 차단되기때문에 DLQ를 구성해서 함수가 계속 동작하도록 가능
3. 세 번째 SNS와 Lambda 사용
   • SNS에서 비동기식으로 Lambda에 전송
   • Lambda 함수는 처리하지 못하는 메시지가 발생시 내부적으로 재시도
   • 총 세번까지 하고 처리 안되면 제거하거나 DLQ로 보내도록 구성이 가능
     • 아니면 SQS 대기열로 보내서 나중에 다시 처리 할 수도 있다.
4. 팬 아웃 패턴
   • 다중 SQS 대기열에 데이터를 전송하는 방식
   • 자동으로 SNS 서비스가 해당 메시지를 SQS 대기열에 팬아웃하는 것
     • 애플리케이션이 오류로 종료돼도 메시지를 전달 받을 수 있음
   • AWS에서 자주 보이는 설계 패턴

5. S3 이벤트 알림
   • S3 버킷이 특정 이벤트에만 반응하도록 설정이 가능
   • S3 이벤트를 SNS, SQS, Lambda 함수로 보낼 수 있다.
   • 하지만 보통 수초 내로 전송되고 가끔 몇 분 이상이 소요 될 수도 있음
   • 그래서 세 가지 통합 방법으로 효율적으로 할 수 있다.
   • 첫 번째 Amazon EventBridge
     • S3 버킷에서 일어난 모든 이벤트를 EventBridge로 전송하는 방법
     • EventBridge를 사용하는 이유는 메타데이터, 객체 크기, 이름 등으로 필터링 가능
       • 여러 대상에 이벤트를 한번에 보낼 수 있음
   • 두 번째 Amazon EventBridge + CloudTrail
     • API 호출을 CloudTrail에 로그가 되니 로그를 EventBridge의 이벤트를 트리거
     • 경보를 생성하여 Amazon SNS에 전송이 가능
   • 세 번째 API Gateway 등을 이용하는 AWS 외부 이벤트
     • API Gateway가 Kinesis Data Stream에 전송
     • Kinesis Data Stream이 Kinesis Data Firehose로 이동
     • Kinesis Data Firehose에서 S3에 저장

AWS의 캐싱 전략

• CloudFront(Edge)에서 캐싱을한다.
  • 사용자와 최대한 가까이에서 캐싱을 한다는 뜻
  • TTL에 대해 균형이 필요
• API Gateway도 캐싱이 가능
  • 리전 서비스라서 캐시를 사용하면 캐시도 리전에 묶이게 된다.
• DynamoDB가 있을 경우 Redis, Memcached, DAX 등을 사용해서 캐시 사용
• S3에는 캐싱 기능이 없다.
• 밑의 사진에 뒤로 갈수록 비용과 지연시간이 늘어난다.

AWS에서 IP 주소 차단

• NACL: VPC 레벨에서 첫 번째 방어선
• ALB IP 주소 차단
  • Client => NACL => ALB => EC2
  • ALB로 부터 오는 트래픽을 EC2 사설 서브넷에 배포
  • ALB에 보안 그룹에 클라이언트 허용
• NLB IP 주소 차단
  • Client => NACL => NLB => EC2
  • 네트워크 로드 밸런서를 위한 보안 그룹이 없기에 트래픽이 지나감
  • IP를 새로 만드는 클라이언트는 EC2 인스턴스가 사설 IP를 사용하는 사설 서브넷에 있어도 EC2 인스턴스로 갈 수 있음
• ALB + WAF IP 주소 차단
  • Client => NACL => ALB+WAF => EC2
  • IP 주소에 대한 복잡한 필터링이 가능하며 규칙을 만들어서 많은 요청을 막을 수 있음
• ALB + CloudFront WAF IP 주소 차단
  • Client => CloudFront+WAF => ALB => EC2
  • 클라이언트 IP를 알 수 없음, CloudFront 공용 IP만 알 수 있다.
  • CloudFront로 부터 클라이언트를 막을려면 국가 차단, WAF나 웹 애플리케이션 방화벽을 사용

AWS의 고성능 컴퓨팅(HPC)

• 첫 번째 데이터 관리 방식, AWS로 데이터를 전송하는 방법
  • AWS 다이렉트 커넥트
    • 초당 GB의 속도로 프라이빗 보안 네트워크로 클라우트로 데이터 전송
  • Snowball, Snowmobile
    • 물리적 라우팅을 통해 클라우드로 PB단위 데이터를 옮길 때 사용
  • DataSync
    • DataSync 에이전트를 설치해 대용량의 데이터 전송
    • 온프레미스, NFS, SMB => S3, EFS, Windows FSx로 전송
• EC2 인스턴스 성능을 향상하는 방법
  • SR-IOV (EC2 Enhanced Nwtworking)
    • 더 넓은 대역폭 제공
    • 더 높은 PPS (초당 패킷), 지연시간이 짧아짐
  • 구현 하는 방법
    • Elastic Network Adapter (ENA)
      • 네트워크 속도를 100Gbps까지 올려 줌
    • Intel의 82599VF
      • 최대 10Gbps까지 빨라짐, 오래된 ENA
    • Elastic Fabric Adapter (EFA)
      • Linux에서만 사용 가능
      • 노드 간 소통, 밀집된 워크 로드 처리에 좋음
      • MPI 표준 Linux OS를 우회
• 데이터를 어떻게 저장하는지?
  • 인스턴스 저장소
    • EBS
      • io2 Block Express로 256,000 IOPS까지 확장
    • 인스턴스 스토어
      • 수백만의 IOPS로 확장, EC2와 연결되어 하드웨어에 있고 지연시간 짧음
      • 인스턴스가 망가지면 손상될 수 있음
  • 네트워크 저장소
    • S3
      • 대용량 블롭 데이터 저장 시 사용
      • 큰 객체 저장을 위한 것
    • EFS
      • IOPS가 파일 시스템의 전체 크기에 따라 확장
      • 프로비저닝된 IOPS 모드를 써서 EFS에서 높은 IOPS를 얻기도 함
    • FSx for Lustre
      • Linux와 Cluster용
      • HPC에 최적화되어 수백만의 IOPS를 제공
      • 백엔드에서 S3로 제공
• 자동화 및 오케스트레이션
  • AWS Batch
    • 다중 노드 병렬 작업 수행
    • 여러 EC2 인스턴스에 걸쳐 작업 가능
    • HPC에서 많이 선택
  • AWS ParallelCluster
    • 오픈 소스 클러스터 관리 도구
    • 텍스트 파일로 구성해서 AWS로 배포
    • VPC와 서브넷 및 클러스터 타입과 인스턴스 타입 생성 자동화

EC2 인스턴스 고가용성

첫번째

• 대기중인 EC2 인스턴스를 만들고
• CloudWatch Event에서 알람을 통해 Lambda 함수에서 탄력적 IP를 분리하고
• 대기중인 EC2 인스턴스에 연결
  

두번째

• ASG를 사용해서 개수를 1개로 하고 탄력적 IP는 태그에 기반해 연결
• 첫번째 가용영역의 인스턴스가 종료가 되면 ASG에서 두번째 가용영역의 인스턴스를 자동으로 생성함
• 두번째 가용영역의 인스턴스가 EC2 사용자 데이터 스크립트를 실행하고 탄력적 IP를 연결
• 다른 CloudWatch, Events가 필요가 없는 아키텍처

세번째

• 위와 똑같지만 ASG에 실행 이벤트 수명 주기 후크를 사용하여서 EBS 볼륨에서 스냅샷을 얻는 스크립트를 생성을 하면은
• EBS 스냅샷을 기반해 올바른 가용영역에 EBS 볼륨을 생성이 됨
• EC2 사용자는 이것만 확인 후 탄력적 IP를 직접적으로 연결