서버리스 솔루션 아키텍처

이기태·2024년 5월 25일

AWS

목록 보기

40/62

모바일 애플리케이션: MyTodoList

요구 사항
1) HTTP 엔드 포인트가 있는 REST API가 노출되어야 한다.
2) 서버리스 아키텍처이어야 한다.
3) 사용자가 원할 경우 스스로 데이터를 관리할 수 있게 S3에 있는 폴더와 직접 상호작용이 가능해야 한다.
4) 사용자가 관리형 서버리스 서비스로 인증할 수 있어야 한다.
5) 사용자가 할 일을 읽고 쓸 수 있지만 대부분 읽기를 많이해 관련 성능이 필요함.
6) DB계층은 확장할 수 있도록 구축해 읽기 처리량을 높어야 한다.

아키텍처 1
- 1) REST API를 사용하기 위해 API Gateway를 사용
- 2) 일반적인 서버리스 API 방식으로 API Gateway가 람다 함수를 호출해 확장을 허용하고 서버리스 인프라를 사용하도록 한다.
- 3) 람다는 DB에서 할 일을 저장하거나 읽어 내야 한다.
  서버리스이면서 확장이 잘 되는 DB는 DynamoDB이다.
- 4) 인증 계층
  Amazon Cognito같은 서버리스 기술 사용
- 동작
  모바일 클라이언트가 Cognito에 연결하고 인증하면 API Gateway는 Cognito와 함께 인증을 확인

아키텍처 2
S3 버킷에 사용자 액세스 권한을 주려면?
- 1) Cognito에 인증을 요청하는 클라이언트가 있으면 Cognito는 AWS STS를 통해 임시 자격 증명을 제공할 수 있다.
- 2) 임시 자격 증명을 클라이언트에 반환하고, 이 자격 증명은 S3 에서 파일을 저장하고 회수등의 S3에 액세스하도록 허용
  -> 오답: 'AWS 사용자 자격 증명을 모바일 클라이언트에 저장한다.'

아키텍처 3
애플리케이션 확장
패턴을 분석해보니 읽기처리량이 높음.
RCU는 많고 할 일이 많이 바뀌지는 않음.
-> 자주 편집할 필요는 없음.
즉, 읽기 처리량을 늘리면서 전체 비용을 줄여야 한다.
- 읽기 처리량을 늘리면서 비용을 줄이기
  캐싱 계층으로 DAX를 사용한다.
- 읽기를 많이 하는데 읽은 내용을 DAX 캐시에 저장
  DynamoDB의 읽기 용량 단위가 많이 필요하지 않게 되고 확장이 용이하고 비용이 준다.

다른 캐싱 방법
- 캐시에 응답을 저장할때 API Gateway 레벨에서 진행할 수 있다.
  응답이 거의 바뀌지 않으면서 API 라우트에 대한 응답을 캐시에 저장하는 경우 유용

모바일 애플리케이션: MyTodoList 정리

HTTPS, API Gateway Lambda DynamoDB를 사용한 서버리스 REST API 아키텍처 구성
임시 자격 증명 생성해 버킷에 액세스를 제공하는 STS와 Cognito를 사용
Cognito를 이용해 애플리케이션이 DynamoDB나 Lambda에 직접 접근.
DAX로 DynamoDB에서 읽은 내용을 캐시에 저장해 성능을 개선하고 비용 절감한다.
REST 요청 캐싱은 응답이 고정된 경우 API Gateway 레벨에서 가능하다.
보안은 Cognito로 가능
Cognito는 API Gateway와 직접 통합되어 있다.

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

요구 사항
1) 글로벌 스케일 아웃이 가능해야 한다.
2) 보통 블로그를 작성하는 빈도보다 읽는 빈도가 높다.
3) 대부분 정적 파일로 구성되고 일부는 동적인 REST API로 구성된다.
4) 캐시를 적용해 비용을 줄이고 응답 속도도 높이고 좋은 UX를 제공하고 싶다.
5) 블로그에 처음 방문하는 사람에게 환영 이메일을 보낸다.
6) 서버리스이고, 블로그에 업로드되는 사진은 섬네일이 생성되어야 한다.

아키텍처 1
- 콘텐츠 정적이고 글로벌을 대상으로 서빙
- 콘텐츠가 S3에 저장되어있다.
  글로벌을 대상으로 노출시켜야 한다.
  -> 전 세계 대상으로 서비스되는 CDN서비스인 CloudFront를 이용
- 클라이언트는 CloudFront의 엣지 로케이션과 통신을 한다.
  S3에게 받은 데이터를 캐시로 저장한다.

아키텍처 2
보안
- 클라이언트는 글로벌 배포를 위한 CloudFront와 상호작용 한다.
- 오리진 액세스를 제한해서 CloudFront로만 S3 버킷에 접근할 수 있도록 할 것이다.
  이를 위해 CloudFront만 인가할 수 있는 버킷 정책을 추가한다.
- S3에 바로 접근하는 사용자는 인가 받지 못하고 버킷은 보호된다.

아키텍처 3
퍼블릭 서버리스 REST API 추가
- REST HTTPS로 API Gateway와 통신
- 게이트웨이는 람다 함수를 호출
- 람다 함수는 DynamoDB에 쿼리를 날림
- 읽기가 많이 발생하므로 DAX를 캐시 레이어로 사용
- 글로벌로 서빙할 때 지역에 따른 지연을 줄이기 위해 DynamoDB의 글로벌 데이터베이스를 사용한다.

아키텍처 4
신규 사용자에게 환영 이메일 보내기
- DynamoDB에서 변경사항을 전송하기 위해 DynamoDB Stream을 이용
- 스트림은 람다 함수를 호출
  이 람다 함수는 IAM 역할을 부여 받아 SES(Simple Email Service)를 사용할 수 있게 해준다.
  SES: 이메일 발송해주는 서비스
  -> 람다 함수가 SDK를 이용해 SES가 이메일을 발송하게 한다.

아키텍처 5
이미지 업로드하면 섬네일 생성하기
- 클라이언트에서 S3 버킷으로 바로 업로드 할수도 있고
- CloudFront OAI를 이용할 수도 있다.
- 클라이언트는 사진을 ClourFront에 업로드하고 CloudFront는 사진을 S3 버킷으로 전달한다.
  이 방식을 S3 Transfer Acceleration이라 한다.
  -> 사진을 S3로 바로 올리거나
  -> S3 Transfer Acceleration을 이용하거나
- S3에 파일이 추가되면 람다 함수를 호출하게 한다.
- S3가 람다를 호출하면 람다는 섬네일을 생성하고 섬네일을 S3버킷에 넣는다(다른 버킷에 넣을 수도 있다.)
  + [참고]S3는 SQS와 SNS를 호출할수도 있다.

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

정적 콘텐츠를 ClourFront와 S3로 배포하는 아키텍처 구성
서버리스인 REST API를 연결함
API가 퍼블릭이여서 Cognito가 필요 없다.
데이터를 글로벌로 서빙하기 위해 DynamoDB 사용
(오로라 글로벌 DB를 사용할 수 있지만 이 사례가 서버리스가 아닌 프로비저닝 오로라를 사용했어야 한다.)??????
DynamoDB Stream을 활용
-> 사용자 테이블에 발생하는 변경사항을 알리는 용도 + 람다 함수 호출 용도
호출되는 람다 함수에 IAM 역할을 부여해 SES를 이용
SES: 서버리스 방식으로 이메일을 발송하기 위한 방법
S3는 이벤트 알림을 위해 SQS, SNS, 람다를 호출

마이크로서비스 아키텍처

서버리스는 아님
마이크로 서비스 아키텍처로 전환하려고 한다.
많은 서비스가 REST API를 통해 상호작용 한다.
즉, 서로 소통하는데 REST API사용한다.
마이크로 서비스의 아키텍처는 무엇이든 원하는 대로 할 수 있다.
마이크로 서비스 아키텍처를 사용하려는 이유
- 서비스 개발 수명 주기를 줄이고자 함.
- 각 서비스가 독립적으로 확장
- 코드 리포지토리를 갖추고 싶다면 마이크로서비스 아키텍처 사용하면된다.

마이크로 서비스 환경

아키텍처 1
- 사용자는 첫 HTTPS를 통해 마이크로서비스와 통신
- ELB가 ECS(Elastic Container Service)와 통신하고 난 뒤 DynamoDB와 통신
  위와 같이 아키텍처를 선택함.
  다른 방법 사용해도 상관없음
  이 예시에서 이렇게 사용함
- 마이크로 서비스는 보통 DNS 이름이나 URL이 있다.
  여기서는 service1.example.com을 예시로 든다.
  정보를 얻기 위해 DNS 쿼리를 Route 53에 보내 별칭 레코드를 받고 서비스와 상호작용이 가능하다.
아키텍처 2
- 두 번째 서비스를 만든다.
- 전형적인 서버리스용 아키텍처 사용
  DynamoDB대신 ElastiCache 사용(ElastiCache대신 람다의 백엔드 ElastiCache 사용해도 된다.)
두 번째 마이크로서비스는 첫 번째 서비스와 상호작용 할 수도 있다.
- 람다 함수가 ELB에 호출을 보내 첫 마이크로서비스에서 정보를 얻고 응답을 생성
아키텍처 3
- ELB를 사용하는 세 번째 마이크로서비스를 만든다.
- 이 서비스는 서버리스가 아니라 EC2 오토 스케일링과 Amazon RDS DB를 사용한 전형적인 아키텍처 사용
  EC2 인스턴스가 결정을 내리기 전에 두 번째 마이크로서비스를 호출해야 할 수도 있다.
  여기서의 URL은 service3.example.com이다.

마이크로서비스 아키텍처 정리

각 마이크로서비스는 원하는 대로 설계할 수 있다.
마이크로서비스에는 두 가지의 패턴이 있다.
- 동기식 패턴
  다른 마이크로서비스를 명시적으로 호출
  그래서 API Gateway와 로드 밸런서는 다른 마이크로서비스에 HTTPS 호출을 보내기 적합하다.
- 비동기식 패턴
  S3 처럼 SQS, Kinesis, SNS, Lambda에 트리거로 작용하는 경우
  EX: SQS에 메시지를 남기지만 응답을 언제 받을지 내용이 무엇인지 무슨 일이 일어날지 개의치 않음.
마이크로서비스의 문제
- 새로운 마이크로서비스를 생성할 때마다 오버헤드가 발생한다.
- 서버 밀도나 사용률을 최적화하는 데 어려움을 겪는다.
- 여러 버전의 마이크로서비스를 동시에 가동하려면 복잡하다.
- 여러 서비스와 통합하려다 클라이언트 코드 요구사항이 급증할 수도 있다.
위 문제들은 서버리스 패턴으로 어느 정도 해결 될 수 있다.
EX: API Gateway나 Lambda는 자동으로 확장한다.
API Gateway에서 API를 쉽게 복제하고 재생산
API Gateway를 위한 Swagger 통합으로 클라이언트 SDK 생성이 가능하다.

-> 마이크로서비스는 AWS를 사용해 원하는대로 설계함.

소프트웨어 업데이트 오프로딩

EC2에서 작동하는 애플리케이션이 있고 종종 소프트웨어 업데이트를 배포한다.
컴퓨터에서 패치를 다운로드해 EC2에 설치하는 상황을 생각해보자.
소프트웨어가 새로 업데이트되면 요청을 많이 받게 된다.
그래서 콘텐츠는 네트워킹을 통해 다수에게 배포하는데 비용이 많이 든다.
애플리케이션을 변경하거나 아키텍팅을 다시 하는 일 없이 비용과 CPU를 최적화하고 싶을때 어떤 방법이 있을까

애플리케이션의 현재 상태

전형적인 ELB와 ASG 개발 애플리케이션이 있다.
다중 AZ에 걸쳐 작동
M5 인스턴스는 소프트웨어 업데이트를 배포한다.
소프트웨어 업데이트 모두 Amazon EFS에 위치한다 가정하자.
이 상태를 어떻게 전 세계로 확장하고 CPU 사용률을 줄이면서 비용을 절감할까?

-> CloudFront를 상위에 두면 된다.

왜 CloudFront일까?

1) 아키텍처에는 변화가 없다.
2) 엣지에서 소프트웨어 업데이트 파일은 캐시에 저장된다.
-> 업데이트 파일은 변하지 않기 때문(동적이 아니라 정적인 파일이다.)
3) EC2 인스턴스는 서버리스가 아니지만 CloudFront는 서버리스이기 떄문에 확장 가능하다.
-> ASG가 많이 확장하지 않아 EC2와 네트워크, EFS 비용을 크게 절감하게 된다.
-> 그리고 가용성도 확보할 수 있다.