투두리스트 앱
요구사항
- 서버리스 아키텍처
- 관리형 서버리스 서비스를 통해 사용자 인증
- HTTPS 엔드포인트를 가진 REST API를 노출
- 사용자들은 대부분 읽기를 많이함
- 데이터베이스 레이어는 스케일링이 가능해야 하고 읽기 처리량이 매우 높아야 함
- 원하는 경우 사용자가 S3에서 자신의 폴더와 직접 상호작용하여 데이터 관리
아키텍트
👉🏻 아마존 API 게이트웨이, 람다, DAX(읽기 캐시), 다이나모DB, 코그니토(인증)
블로그
요구사항
- 주로 읽기 작업이 많음
- 대부분 정적 파일로 구성
- 동적 REST API로 구성
- 캐시를 적용해서 비용 절감 및 응답 속도 향상
- 블로그를 처음 방문하는 사람에게 메일 전송
- 서버리스로 구현
- 블로그에 업로드되는 사진의 썸네일 생성
- 콘텐츠는 정적이고 S3에 저장되어 있으며 글로벌을 대상으로 서빙해야 함
아키텍트
- CloudFront: 클라이언트 인터랙트
- CloudFront OAC: 클라이언트로부터 받은 사진을 썸네일로 만들어 S3로 전송 (S3 Transfer Acceleration)
- S3버킷: 오리진 액세스를 제한하여 CloudFront에서만 접근할 수 있도록 함
- 아마존 API 게이트웨이
- 람다
- DAX: 읽기 캐시
- 다이나모DB
- SES: 다이나모 DB 스트림으로 람다호출하여 Simple Email Service 사용
마이크로 서비스 아키텍처
요구사항
- 서비스들끼리 소통은 REST API를 사용
- 서비스 개발 수명 주기를 줄이고자 함
- 서비스가 독립적으로 확장, 코드 리포지토리를 갖추길 원함
아키텍트
각 서비스끼리 호출 가능.
- Route53: DNS 쿼리. 보통 마이크로 서비스는 DNS이름이나 URL이 존재.
서비스 1:
- ELB: 유저와 HTTPS로 통신
- ECS: ELB와 연결됨. 컨테이너 사용.
- 다이나모DB
서비스 2:
- API Gateway
- Lambda
- ElastiCache
서비스 3:
- ELB
- EC2 ASG
- RDS
마이크로 서비스의 패턴
동기식 패턴
다른 마이크로서비스를 명시적으로 호출한다.
API Gateway와 로드밸런서는 다른 마이크로서비스에 HTTPS호출을 보내기에 적합하다.
비동기식 패턴
S3처럼 SQS, Kinesis, SNS Lambda에 트리거로 작용하는 경우
요청을 보내고 응답을 언제 받을지 내용이 뭔지, 무슨 일이 일어날지 개의치 않는다.
마이크로 서비스의 문제
새로운 마이크로 서비스를 생성할 때마다 오버헤드가 발생한다.
서버 밀도나 사용률을 최적화하는 데 어려움을 겪기도 한다.
여러 버전의 마이크로서비스를 동시에 가동하려면 복잡하다.
여러 서비스와 통합하려다 클라이언트 코드 요구사항이 급증하기도 한다.
이런 문제는 서버리스 패턴으로 어느 정도 해결된다. API Gateway나 Lambda는 자동으로 확장된다.
API Gateway에서 API를 쉽게 복제하고 재생산하며 Swagger 통합으로 클라이언트 SDK 생성이 가능하다.
소프트웨어 업데이트 오프로딩(offloading)
소프트웨어 업데이트 오프로딩이란, EC2에서 실행되는 애플리케이션이 소프트웨어 업데이트를 배포할 때 발생하는 네트워크 비용과 CPU 사용률을 줄이는 방법이다.
보통 소프트웨어 업데이트가 배포되면 많은 사용자가 이를 다운로드하면서 네트워크 비용이 증가하고, EC2 인스턴스의 부하도 커진다. 이를 해결하기 위해 애플리케이션을 변경하거나 아키텍처를 다시 설계하는 대신, CloudFront를 활용하는 방법이 있다.
CloudFront를 EC2와 Amazon EFS 앞단에 두면, 소프트웨어 업데이트 파일이 엣지에서 캐싱되어 배포된다. 업데이트 파일은 정적 콘텐츠이므로 캐싱이 가능하며, 이를 통해 EC2와 네트워크, EFS 비용을 절감할 수 있다. 또한, ASG의 확장이 줄어들어 EC2 인스턴스의 CPU 부담도 감소한다.
결과적으로, CloudFront를 활용하면 기존 애플리케이션의 확장성을 높이고 비용을 절감할 수 있다. 특히, 정적 콘텐츠를 많이 다루는 경우 CloudFront의 캐싱 기능이 매우 효과적이다.
