섹션 20: 서버리스 솔루션 아키텍처 토론

모바일 애플리케이션: MyTodoList

• 서버 목표
  • HTTPS 엔드 포인트가 있는 REST API 노출
  • 서버리스 아키텍쳐
  • 사용자가 원하면 스스로 데이터 관리
    • S3에 있는 폴더와 직접 상호작용
    • 사용자가 관리형 서버리스 서비스 인증 필요
  • 읽기를 많이하니 관련 성능에 대해 최적화 필요
  • 데이터베이스 계층은 확장 가능하게, 읽기 처리량 향상 필요
• 솔루션 아키텍처
  • Amazon API Gateway
    
    • HTTPS 엔드 포인트 REST API 노출
    • 람다 함수 호출 (invoke)
  • Lambda
    • 서버리스 인프라 사용
    • DynamoDB에 query 전달
  • DynamoDB
  • Amazon Cognito
    • 서버리스 인증 계층
    • API Gateway는 Cognito와 함께 인증을 확인함
    • 인증을 요청하는 모바일 클라이언트에게
      AWS STS를 통해서
      임시 자격 증명을 제공 후 모바일 클라이언트에게 반환
    • 임시 자격 증명을 모바일 클라이언트에게 저장하는건 올바른 방법이 아님
  • S3
    • 임시 자격 증명이 있을경우에
    • 파일을 저장하고 회수 할 수 있음
  • DynamoDB DAX
    • 읽기 처리량을 늘리면서 비용을 낮출려면
    • DynmaoDB에 캐싱 레이어를 추가 해주는 것
  • 보안
    • 전부 Cognito로 가능
    • Cognito는 API Gateway와 직접 통합되어 있음

서버리스 웹사이트: MyBlog.com

• 서버 목표
  • 캐시 적용
    • 응답속도 상승, 비용 절감 
  • 서버리스로 구현
  • 첫 방문자에게 이메일 전달
  • 블로그 업로드시 섬네일 생성
  • 콘텐츠는 동적이고 글로벌을 대상으로 전달
• 솔루션 아키텍처
  • Amazon S3
  • Amazon CloudFront
    • OAC (Origin Access Control)으로 제한
      CloudFront로만 S3 버킷 접근
      • S3 버킷 정책에 추가
  • Amazon API Gateway
    • REST HTTPS로 게이트웨이 통신
    • Lambda 호출 (invoke)
  • AWS Lambda
    • Dynamo DB에 Query / Read가 많이 발생하니 캐시 레이어 추가
  • DAX Caching layer
    
    • Lambda에 Query, Read 전달
  • Dynamo DB Global Tables
    
    • 한 리전이 아닌 글로벌로 서빙을 해야하니 전역 테이블로 사용
  • 사용자에게 이메일 보내는 아키텍처
    • DynamoDB Stream
      Stream이 람다 호출 (invoke)
      • Lambda (IAM Role)
        IAM 역할을 부여 받아서
        AWS SDK를 이용해서 SES가 이메일 발송하게 전달 
        • Amazon SES (Simple Email Service)
          사용자에게 이메일 전달
  • 이미지 업로드시 섬네일 생성
    • S3에 바로 업로드를 할 수도 있고
    • S3 Transfer Acceleration을 사용 할 수도 있음
      • CloudFront에 업로드 하면은 S3 버킷으로 전달하는 방식
    • 업로드를 하였으면 S3에 람다 함수 호출
      • 람다는 섬네일을 생성함
      • 생성한 섬네일은 S3 버킷에 넣는데, 다른 버킷에 넣을 수도 있음
      • S3에서 SQS나 SNS도 호출 할 수 있어서 다른 서비스에도 전달이 가능

마이크로서비스 아키텍처

• 정확한 서버리스는 아님
• 많은 서비스가 REST API를 통해 상호작용 하는 방식
• 마이크로 서비스의 아키텍처는 모습과 형태가 달라 원하는 대로 할 수 있음
• 각 서비스가 독립적으로 확장 및 코드 리포지토리를 갖출려면 MSA를 사용

• 두 번째 마이크로서비스가 첫 번째 서비스와 상호작용 할 수 있음
• 세 번째도 두 번째에게 상호작용 가능
• 마이크로 서비스에는 두 가지 패턴이 존재
  • 동기식 패턴
    • 다른 마이크로서비스 명시적으로 호출
  • 비동기식 패턴
    • S3처럼 SQS, Kinesis, SNS, Lambda에 트리거로 작용하는 경우
    • 예시) SQS에 메시지를 남기지만 응답을 언제 받을지 내용이 뭔지 상관 안써도 됨
• 마이크로 서비스 단점
  • 새로운 마이크로서비스 생성 시 오버헤드가 발생
    • 서버 밀도, 사용률 최적화에 어려움
  • 여러 버전의 마이크로서비스를 동시에 가동하는것도 복잡함
  • 하지만 서버리스 패턴으로 어느 정도 해결 됨
    • API Gateway, Lambda는 자동으로 확장함
      사용량만큼 돈만 내면 됨

소프트웨어 업데이트 배포

• EC2에서 작동하는 애플리케이션이 종종 소프트웨어 업데이트를 배포
• 컴퓨터에서 패치를 다운로드해 EC2에 설치하는 상황
• 소프트웨어가 새로 업데이트 되면 요청을 많이 받음
• 다수에게 배포 할 때 비용이 많이 드는데
• 애플리케이션을 변경하거나 아키텍팅을 다시 하는 일 없이
• 비용과 CPU를 최적화 하는 쉬운 방법이 있음
  • CloudFront를 상위에 두면 됨
  • 엣지에서 소프트웨어 업데이트 파일을 캐시에 저장
  • 업데이트 파일은 변하지 않기 때문에 매우 취적화됨
  • 서버리스여서 자동으로 확장함
• CloudFront가 기존 애플리케이션의 확장성을 높이고
• 비용을 절감하는데 용이함
• 즉 캐싱을 활용하는 정적 콘텐츠는 엣지 CloudFront를 활용하자