Section Introduction
1.Mobile application: MyTodoList - pdf에 정리
2.Serverless application: MyBlog.com - pdf에 정리
3.Micro Services architecture
4.Software updates offloading
Micro Services architecture
마이크로서비스 아키텍처로 전환하고자 한다고 가정해보자. 많은 서비스가 REST API를 통해 직접적으로 상호작용한다.
마이크로서비스의 아키텍처는 모습과 형태가 달라 원하는 대로 할 수 있고, 서비스의 개발 수명 주기를 줄이고자 마이크로서비스 아키텍처를 사용한다. 각 서비스가 독립적으로 확장하며 코드 리포지토리를 갖추길 원한다면 마이크로서비스 아키텍처를 사용하면 된다.
example:
service 1
1.사용자는 첫 마이크로서비스와 HTTPS를 통해 통신하게 된다.
2.ELB가 ECS와 통신한 뒤 DynamoDB와 통신
3.마이크로서비스는 보통 DNS 이름이나 URL이 있다. service1.example.com을 예로 들어보자
4.정보를 얻으려면 DNS 쿼리를 Route 53에 보내 별칭 레코드를 받고 나서 서비스와 상호 작용이 가능하다.
service 2
1.전형적인 서버리스용 아키텍처 사용, 하지만 DynamoDB 대신 ElastiCache가 있다. 재미삼아 이것저것 섞어서 사용하려면 Lambda의 백엔드로 ElastiCache를 써도 괜찮다!
2.service 2는 service 1과 상호작용할 수도 있다. ELB에 람다 함수가 호출을 보내 service 1에서 정보를 얻고 응답을 생성한다.
service 3
1.ELB 사용
2.서버리스가 아니라서 Amazon EC2 오토 스케일링과 RDS DB를 사용하는 거라 전형적인 아키텍처에 해당한다.
3.EC2 인스턴스가 결정을 내리기 전에 service 2를 호출한다.
4.URL은 service3.example.com
Discussions on Micro Services
- 각 마이크로서비스를 원하는대로 설계할 수 있다.
- 동기적 패턴 (Synchronous patterns): API Gateway, 로드 밸런서
- 비동기적 패턴 (Asynchronous patterns): SQS, Kinesis, SNS, Lambda 트리거 (S3)
- ex. SQS에 메시지를 남기지만 응답을 언제 받을지 내용이 무엇인지 무슨 일이 일어날지 개의치 않음 - 비동기 패턴
- 마이크로서비스의 문제:
- 새로운 마이크로서비스를 생성할 때마다 오버헤드 발생
- 서버 밀도/사용률 최적화에 대한 문제
- 동시에 여러 버전의 여러 마이크로서비스를 실행하는 복잡성
- 여러 개별 서비스와의 통합을 위한 클라이언트 측 코드 요구 사항의 증가
- 일부 도전 문제는 서버리스 패턴을 통해 해결될 수 있다.:
- API Gateway, Lambda는 자동으로 확장되며 사용량에 따라 비용이 청구됨 → 서버 사용률 걱정 X
- API Gateway에서 API를 쉽게 복제하고 환경을 재생성할 수 있음
- API Gateway를 위한 Swagger 통합으로 클라이언트 SDK 생성 가능
Software updates offloading
EC2에서 작동하는 애플리케이션이 있고 종종 소프트웨어 업데이트를 배포한다. 소프트웨어가 새로 업데이트되면 요청을 많이 받게되고, 콘텐츠는 네트워킹을 통해 다수에게 배포되는데 이는 비용이 많이 든다.
소프트웨어 업데이트 비용과 CPU 사용량을 최적화하고 EC2에서 실행 중인 응용 프로그램을 변경하지 않고 소프트웨어 업데이트를 분산하는 방법은 무엇일까?
애플리케이션의 현 상태
- 전형적인 ELB와 ASG 개발 애플리케이션이 있는데 다중 AZ에 걸쳐 작동한다.
- M5 인스턴스는 소프트웨어 업데이트를 배포하고, 소프트웨어 업데이트 모두 EFS에 위치한다.
애플리케이션을 전세계로 확장하고 CPU 사용량을 줄이며 비용을 절감하는 방법
- CloudFront를 상위에 두면 된다! 아키텍처에는 변화가 없다!
- 엣지에서 소프트웨어 파일은 캐시에 저장된다. 업데이트 파일은 변하지 않기 때문이다. (동적이 아닌 정적이기 때문에 절대 바뀌지 않음)
- EC2 인스턴스는 서버리스가 아니지만 CloudFront는 서버리스이기 때문에 확장한다.
- ASG가 많이 확장하지 않아 EC2, 네트워크, EFS 비용을 크게 절감할 수 있다.
엣지에서 캐싱을 활용하는 정적 콘텐츠가 대부분인 경우 CloudFront가 기존 애플리케이션의 확장성을 높이고 비용을 절감하는데 용이하다!
