AWS 서버리스 솔루션 아키텍쳐

서버리스 아키텍쳐

MyTodoList 모바일 애플리케이션

• HTTPS 엔드포인트가 있는 REST API가 노출되어야한다
• 서버리스 아키텍쳐
• 유저는 자신의 S3 폴더와 직접적인 상호작용이 가능해야한다
• 관리형 서버리스 서비스로 인증 가능해야한다
• 사용자가 할 일을 읽고 쓰지만 읽기가 많으니 읽기 처리량을 늘려야한다

classic한 서버리스 아키텍쳐

S3 상호작용을 위한 인증 절차

AWS 사용자 자격증명을 모바일 클라이언트에 저장하지 않는다

S3 - Cognito - STS를 활용한다

모바일앱의 읽기처리량은 늘리고 전체적인 비용은 줄이기

DAX를 통한 캐싱 레이어를 갖는다.

서버리스 아키텍쳐로 확장이 용이해진다.

이 외에도 API Gateway로 캐시값을 진행할 수 있다.

서버리스 웹사이트 MyBlog.com

• 글로벌 스케일 아웃이 가능해야한다
• 읽는 빈도가 쓰이는 것보다 높다
• 대부분 정적 파일로 구성되고 REST API로 구성
• 캐시를 적용해서 비용 절감 및 UX 향상
• 블로그 이미지는 섬네일이 생성되어야한다

정적인 컨텐츠를 글로벌하게 배포

이후 CloudFront에서만 접근할 수있도록 버킷 정책을 설정한다

이후 DynamoDB를 글로벌하게 설정할 수 있다(비용 고려)

이미지를 넣지 않았지만 SES를 통한 환영 이메일 발송 기능또한 구현할 수 있다

썸네일 이미지 저장하기

S3 Transfer Acceleration을 통한 업/다운로드를 빠르게 진행할 수 있고 이후 람다함수를 사용해 기존에 있던 S3 버킷 혹은 새로운 S3 버킷으로 저장할 수 있다.

Micro Services Architecture

• 많은 서비스가 REST API를 통해 소통
• 각각의 서비스 아키텍쳐는 모습과 형태가 매우 달라 원하는 대로 설정 가능
• 서비스 개발 수명 주기를 줄이기 위함이며, 서비스가 독립적으로 확장하며 각각의 코드 리포지토리를 사용하기 원한다면 Micro Services Architecture를 사용한다
• 동기식 패턴
  • API Gateway , Load Balancer
• 비동기식 패턴
  • SQS, Kinesis, Lambda triggers, SNS
• 마이크로 서비스의 문제
  • 새로운 마이크로 서비스를 생성할 때 오버헤드
  • 서버 밀도나 사용률 최적화하는데 어려움을 겪는다
  • 여러 버전의 마이크로 서비스를 동시에 가동하려면 어렵다
  • 여러 서비스와 통합하려다 클라이언트 코드 요구사항이 급증할 수도 있다
• 서버리스 패턴으로 어느정도 상쇄가 가능
  • 자동화 + 쉬운 API 복제, 재생산 가능 + Client SDK를 통한 통합

서비스

1. ECS(Docker Container)를 사용한 서비스 방식
2. 서버리스 구성 방식
3. 오토 스케일링을 활용한 클래식한 방식

서비스별로 구성이 다르다

• 두 번째 마이크로 서비스는 첫 번째 서비스의 로드밸런서로 요청을 보내 두 번째 서비스에서 응답을 생성가능
• 세 번째 서비스의 오토스케일링을 결정하는데 두 번째 서비스의 지표를 통해 가능하다

Software updates offloading

• EC2에서 업데이트를 위해 소프트웨어를 다운받고 설치하는 과정은 매우 반복적이다
• 소프트웨어가 새로 업데이트 되면 사용자로부터 업데이트를 위한 요청을 많이 받게 된다. 이때 콘텐츠는 네트워킹을 통해 다수에게 배포되기 위한 많은 비용을 필요로 한다

Classic

CloudFront를 통한 확장의 장점

• 아키텍쳐 변경이 필요없다
• 업데이트 파일 캐싱 가능한데 업데이트파일은 정적인 파일이기 때문
• EC2 인스턴스는 서버리스가 아니라 확장이 어렵지만 CloudFront는 서버리스라 확장 쉬움
• CloudFront가 있기 때문에 ASG가 많은 확장을 하지 않아 더 비싼 자원(EFS, EC2 네트워크 비용)을 줄일 수 있다
• 가용성, 확장성, 비용 절감 등을 이룰 수 있다

엣지에서 캐싱을 활용하는 정적 콘텐츠가 많을 경우 사용가능하며 상당히 절약할 수 있는 플랜