17탄-5.현대적 애플리케이션을 위한 컴퓨팅 인프라
<1> 아키텍처의 진화
<2> 컨테이너와 서버리스 차이점
<3> 컨테이너 선택의 이유
<4> 이벤트 기반 컴퓨팅을 위한 AWS Lambda
<5> ECS/EKS 활용하는 경우 (EC2)
<6> Fargate를 활용하는 경우
<7> 람다를 활용하는 경우
<1> 아키텍처의 진화
1
모놀리틱에서 마이크로 서비스로 진화
모놀리틱?
모든 기능
변경의 높은 영향
새로운 기술 채택 어려움
마이크로 서비스?
단일 기능
독립적 배포
변경 시 적은 영향
적합한 기술 선택
2
컴퓨팅 환경은 변화?
비즈니스 로직에 더 빠르게 대응할 수 있는 컴퓨팅으로 변화하고 있다.
물리 머신 -> 가상 머신 -> 컨테이너 -> 서버 리스 (람다, 파 게이트)
<2> 컨테이너와 서버리스 차이점
1
컨테이너?
컴퓨팅 지향적
인프라를 보다 쉽게 관리
인프라의 사용량 기반 가격
ECS, EKS
2
서버리스?
이벤트 지향적
인프라 관리 필요가 없다.
요청 기반 가격
람다
3
현실적으로 컨테이너와 람다를 조합해서 사용한다. 80%
<3> 컨테이너 선택의 이유
1
이식성
커뮤니티 지원
2
일반적인 컨테이너, 관리 편리성 ECS
구축 및 구축 시간 단축
3
쿠버 네티스의 강력한 오픈소스 지원은 EKS
4
AWS Fargate?
서버 관리 요소가 없음
사용한 리소스에 대해서만 비용 지불
컴퓨팅 용량 계획 불필요
EKS , ECS 모두 지원
5
AWS App Runner?
컨테이너화 된 웹 앱 및 API 실행
6
샘플 마이크로 서비스 아키텍처?
Cloudfront -- API Gateway----ALB -----AWS Fargate -------Aurora DB , DynamoDB
7
콘텐츠 관리 시스템 아키텍처?
ALB----ECS or EKS ------------- EFS
8
컨테이너로 전환 사례?
회사 : Vanguard
2,500개의 애플리케이션
20PB의 데이터, 5,000명의 기술 인력, 무장애 목표
DEVOPS, 마이크로 서비스 , CI/CD
ECS와 Fargate 선택
<4> 이벤트 기반 컴퓨팅을 위한 AWS Lambda
1
람다 선택의 이유?
애플리케이션 및 기능을 신속하게 시장에 출시하고 싶은 요구
운영이 아닌 코드에 집중
기존 인스턴스 운영 환경과 컨터이너 플랫폼의 제한 없음
2
서버리스의 의미?
인프라 관리 기능 없음
부하에 따른 자동 스케일링
사용량에 따른 비용 지불
고가용성과 보안을 AWS에서 제공
3
AWS 람다는?
이벤트 기반 서버리스 컴퓨팅.
기존에 꺼진 상태
이벤트가 발생되면 람다는 사용 중인 상태로 변경된다.
4
서버 리스 웹 애플리케이션 아키텍처?
APIGateway------ 람다---------다이나모 디비
<5> ECS/EKS 활용하는 경우 (EC2)
15분 이상 실행시간이 긴 컴퓨팅 작업
1초 미만의 지연시간으로 요청 즉시 실행해야 하는 경우
상태 저장 애플리케이션
GPU 등 특수 하드웨어 지원이 필요한 경우
윈도즈 컨테이너 또는. NET 환경
<6> Fargate를 활용하는 경우
15분 이상 실행시간이 긴 컴퓨팅 작업
예측 가능한 스케일링 또는 서비스 시작 시 지연 시간 허용
GPU 등 특수 하드웨어 지원이 필요 없는 경우
<7> 람다를 활용하는 경우
이벤트에 대한 처리
부하를 예측하기 어려운 경우
경량 애플리케이션 중심의 상태 비저장 컴퓨팅
IT 운영을 간소화하려는 경우
서비스 실행 시간이 15분 이내의 경우
서비스 메모리 10GB 이하의 경우
다음은
https://brunch.co.kr/@topasvga/2706
https://brunch.co.kr/@topasvga/2699
감사합니다.
