Amazon EC2 크기 조정
AWS는 온프레미스에서 제공하지 못하는 답을 준다.
매일 매시간의 수요에 맞는 워크로드를 프로비저닝 할 수 있게 해준다.
확장성과 탄력성
필요한 리소스만으로 시작하고 확장 및 축소를 통해 수요 변화에 자동으로 대응하도록 아키텍처 설계
👉🏻 필요한 리소스에 대해서만 비용을 지불
Amazon EC2 Auto Scaling
변화하는 애플리케이션 수요에 따라 Amazon EC2 인스턴스를 자동으로 추가하거나 제거
이를 통해 애플리케이션 가용성을 효과적으로 유지할 수 있다
- 동적 조정 - 수요 변화에 대응
- 예측 조정 - 예측된 수요에 따라 적절한 수의 Amazon EC2 인스턴스를 자동으로 예약
사용하는 인스턴스에 대해서만 비용을 지불하면 된다!
Auto Scaling 그룹의 크기를 구성할 때 최소 Amazon EC2 인스턴스 하나 이상이 항상 실행 중이어야 한다.
최소 용량
Auto Scaling 그룹을 생성한 직후 시작되는 Amazon EC2 인스턴스의 수
희망 용량
애플리케이션을 실행하려면 최소 하나의 Amazon EC2 인스턴스가 필요하더라도 희망용량을 2개로 설정할 수 있다
만일 지정하지 않는다면 기본적으로 최소 용량으로 설정된다
최대 용량
수요 증가에 대응하여 확장하도록 Auto Scaling 그룹을 구성하되 Amazon EC2 인스턴스 수를 최대 4개로 제한할 수 있다
Elastic Load Balancing을 사용하여 트래픽 리디렉션
같은 목적을 수행하는 EC2 인스턴스가 여러 개 있을 때 요청이 들어오면 요청들이 어떻게 EC2 인스턴스에 가야 할까? 인스턴스 전체에 최대한 워크로드를 균일하게 분산하는 것이 베스트일 것이다.
EC2 인스턴스 전체에 워크로드를 균일하게 분산하기 위해서는 라우팅할 방법이 필요하다. 이 방법이 바로 로드 밸런싱이다.
로드 밸런싱
로드 밸런서 → 요청을 받은 다음 처리할 인스턴스로 라우팅하는 애플리케이션, AWS에서 효율적으로 작동하는 다양한 로드 밸런서 제품이 있다
로드 밸런서는 Auto Scaling 그룹으로 들어오는 모든 웹 트래픽의 단일 접점 역할을 한다.
들어오는 트래픽의 양에 맞춰 Amazon EC2 인스턴스를 추가하거나 제거하므로 이러한 요청이 로드 밸런서로 먼저 라우팅된다. 그 다음 요청을 처리할 여러 리소스로 분산된다.
- 고성능
- 비용 효율성
- 고가용성
- 자동 확장 가능
EC2 인스턴스가 여러 개인 경우 ELB는 워크로드를 여러 인스턴스에 분산한다. 때문에 한 인스턴스가 대량으로 워크로드를 처리할 필요가 없다.
Elastic Load Balancing (ELB)
들어오는 애플리케이션 트래픽을 Amazon EC2 인스턴스와 같은 여러 리소스에 자동으로 분산하는 AWS 서비스이다.
로드 밸런싱의 획일적인 작업 부담을 처리할 목적으로 제작되었다
✓ 리전 수준 구조
→ 개별 EC2 인스턴스가 아닌 리전 수준에서 실행되기 때문에 사용자가 추가로 작업하지 않아도 자동으로 고가용 서비스가 된다
✓ 자동 확장
→ 트래픽이 증가하면 시간당 비용 변경 없이 추가 처리량을 처리하도록 설계
EC2 플릿이 자동으로 확장되면 각 인스턴스가 온라인 상태가 될 때마다 Auto Scaling 서비스는 Elastic Load Bala ncing에 인스턴스가 트래픽을 처리할 준비가 되었음을 알린 후 꺼진다
플릿이 축소되면 ELB는 먼저 모든 신규 트래픽을 중지한 후 기존 요청이 완료될 때까지 기다린 다음 비운다 이 작업이 끝나면 Auto Scaling 엔진은 기존 고객에 대한 중단을 유발하지 않고도 인스턴스를 종료할 수 있다
백엔드 트래픽의 혼란을 해결할 때도 ELB를 사용한다.
👉🏻 EBL는 대기 중인 요청이 가장 적은 백엔드로 트래픽을 보낸다.
백엔드 규모 조정 시 새 인스턴스가 준비되면 ELB에게 트래픽을 수신하여 작업 하라는 지시를 내린다. 프런트엔드는 실행 중인 백엔드 인스턴스의 수를 모르며 신경 쓰지도 않는다. 이것이 진정한 분리된 아키텍처이다.
수요가 적은 기간
수요가 많은 기간
메시징 및 대기열
시스템에 일종의 버퍼나 대기열을 도입하면 프로세스를 개선할 수 있다.
✳️ 메시지를 완충 기억 장치에 배치한다는 개념을 메시징 혹은 대기열이라고 한다.
모놀리식 애플리케이션 및 마이크로서비스
애플리케이션의 구성 요소 = 데이터베이스, 서버, 사용자 인터페이스, 비즈니스 로직 등
밀결합된 아키텍처
애플리케이션이 다른 애플리케이션과 직접 소통하는 것(메시징)을 밀결합된 상태라고 한다.
👉🏻 구성 요소 하나가 고장이 나거나 변경되면 다른 구성 요소나 심지어는 시스템 전체에 문제가 발생한다.
마이크로서비스
애플리케이션 구성 요소가 소결합
소결합된 아키텍처
더 안정적인 아키텍처로, 특정 구성 요소에 장애가 발생하더라도 장애가 구성 요소 안에 격리되기 때문에 전체 시스템 장애로 확장되지 않는다
✳️ 애플리케이션과 애플리케이션 사이에 버퍼를 도입하여 메시지를 주고 받는다
Amazon Simple Notification Service(Amazon SNS)
게시 및 구독 서비스
메시지를 서비스에 전달하는 데 사용하며, 게시자는 Amazon SNS 주제를 사용하여 구독자에게 메시지를 게시한다.
게시/구독 (Pub/Sub)
사용자는 메시지 를 전달하는 채널인 SNS 주제를 만들 수 있다. → 주제에 대한 구독자를 구성한다. → 최종적으로 구독자에게 메시지를 게시한다.
구독자는 웹 서버, 이메일 주소, AWS Lambda 함수, HTTPS 혹은 HTTP 웹 후크와 같은 엔드포인트도 등 그 밖의 여러 옵션이 될 수 있다.
SMS와 이메일을 사용하여 알림을 최종 사용자에게 전달할 수 있다.
Amazon Simple Queue Service(Amazon SQS)
메시지 대기열 서비스
규모에 상관없이 소프트웨어 구성 요소 간에 메시지를 전송, 저장, 수신할 수 있다.
페이로드 - 메시지에 포함된 데이터
SQS 대기열은 메시지가 처리되기 전까지 배치되는 곳으로, AWS는 사용자가 이러한 대기열을 호스팅할 수 있도록 기본 인프라를 관리한다.
✓ 다중화가 내재되어 있기 때문에 메시지를 잃어버리거나 서비스가 중단되지 않는다.
✓ 사용자 또는 서비스는 대기열에서 메시지를 검색하여 처리한 후 대기열에서 삭제한다.
추가 컴퓨팅 서비스
EC2를 사용하면 사용자가 시간에 따라 인스턴스 플릿을 직접 설정하고 관리해야 한다.
- 인스턴스(가상 서버)를 프로비저닝
- 사용자 코드를 업로드
- 애플리케이션이 실행되는 동안 계속해서 인스턴스 관리
온프레미스 호스팅만큼 많은 관리가 필요하지는 않지만 여전히 관리 프로세스가 필요하다. 이보다 더 관리가 편한 다른 컴퓨팅 서비스는 없을까?
서버리스 컴퓨팅
서버리스 - 애플리케이션을 호스팅하는 기본 인프라나 인스턴스를 마치 서버가 없는 것처럼 관리할 필요가 없다는 뜻
필요한 프로비저닝, 규모 조정, 고가용성 및 유지 관리와 관련한 모든 기본적인 환경 관리를 AWS가 대신 처리해준다. → 사용자는 애플리케이션만 신경 쓰면 됨!
AWS Lambda
서버리스 컴퓨팅 옵션 중에 대표적인 서비스
사용자가 코드를 Lambda 함수라는 곳에 업로드할 수 있게 도와주는 서비스
AWS Lambda 작동 방식
✳️ 트리거 구성 → Lambda 함수에서 서비스가 트리거를 기다림 → 트리거 감지 → 코드가 관리형 환경에서 자동으로 실행
💁🏻♀️ 자동으로 규모가 조절, 가용성이 높음, 환경 내 모든 유지 관리를 AWS가 수행함
하지만 Lambda는 코드를 15분 미만으로 실행하도록 설계되었기 때문에 딥 러닝 같은 장기 실행 프로세스에는 적합하지 않다.
👉🏻 웹 서비스의 백엔드나 요청 처리, 백엔드 비용 보고 처리 서비스 처럼 15분이 걸리지 않는 빠른 처리에 적합!
컨테이너
Docker → 운영 체제 수준에서의 가상화 사용하여 컨테이너에 소프트웨어 제공
컨테이너: 애플리케이션과 애플리케이션에서 실행해야 하는 모든 구성을 모아 놓은 코드 패키지
컨테이너 오케스트레이션
컨테이너는 EC2 인스턴스에서 실행되고, 가상 머신을 작동하는 방식과 굉장히 비슷하게 서로 격리되어 실행 된다. 하지만, 이 경우 호스트가 EC2 인스턴스가 된다.
AWS에서 Docker 컨테이너를 사용할 때는 단일 EC2 인스턴스 뿐만 아니라 클러스터라고 하는 인스턴스 모음에서도 실행되는 컨테이너도 시작, 중지, 재시작, 모니터링하는 프로세스가 필요하다. 👉🏻 이 어려운 작업을 컨테이너 오케스트레이션이 수행한다. (컨테이너 관리 지원)
Amazon Elastic Container Service(Amazon ECS)
자체 컨테이너 오케스트레이션 소프트웨어를 관리하는 번거로움 없이도 컨테이너화 된 애플리케이션을 대규모로 실행하는 데 도움이 되도록 설계
Amazon Elastic Kubernetes Service(Amazon EKS)
비슷한 작업을 수행하지만 다른 도구와 다른 기능을 사용
ECS, EKS 모두 EC2 인스턴스에서 실행한다
AWS Fargate
ECS 또는 EKS용 서버리스 컴퓨팅 플랫폼
기본 OS에 액세스할 필요 없거나 EC2 인스턴스를 직접 컨트롤하면서 컨테이너를 호스팅하지 않아도 되는 경우에는 AWS Fargate라는 컴퓨팅 플랫폼 사용
정리
| 요구사항 | 컴퓨팅 서비스 |
|---|---|
| 기존의 애플리케이션을 호스팅하고자 하고 Linux나 Windows같은 기본 운영 체제에 대한 완전한 액세스를 원한다 | EC2 |
| 단기적인 실행 함수나 서비스 지향 또는 이벤트 기반 애플리케이션을 호스팅하고자 하는데 기본 환경은 관리하고 싶지 않음 | AWS Lambda |
| Docker 컨테이너 기반 워크로드 실행 → ECS 혹은 EKS 중 택 1 | 사용자가 관리하는 Amazon EC2에서 실행 혹은 AWS Fartigate(사용자 관리 x)에서 실행(서버리스) |
