[AWS] Cloud Computing

Cloud Computing

EC2

뛰어난 유연성

비용 효율성

빠른 속도

EC2는 가상화 기술을 이용하여 물리적인 서버에서 실행된다.

멀티 테넌시 - 하이퍼 바이저 기술

EC2에는 다양한 성능과 용량, OS들을 선택할 수 있다.

수직 확장이라고 한다.

Amazon EC2 작동 방식

instance를 시작하는데, instance Template를 선택 [운영체제, Application Server 또는 Application], instance로 드나드는 네트워크 트레픽을 제어할 보안사양 지정

instance에 연결하는데, 연결 방법은 여러가지가 있고 [ssh 등...], 연결 시 바로 사용 가능

Amazon EC2 instance

General Purpose

• Application Server
• Game Server
• Enterprise Application Back-end Server
• Middle Size Database

Computing Optimizaiton

• 고성능 프로세서를 활용하는 Computing 집약적인 Application에 적합
• General Purpose instance와 마찬가지로 Web Server, Application Server, Game Server 등에 사용이 가능하다.
• 하지만 좀 더 고사양의 웹서버나 컴퓨팅 파워가 많이 필요한 Application Server, Game 전용 Server에 더 적합하다.

Memory Optimization

• 대규모 데이터 센터를 처리하는 WorkLoad를 위해 빠른 성능을 제공
• Memory는 임시 Storage 영역이라고 볼 수 있는데, 여기에는 CPU가 작업을 완료하는데 필요한 모든 Data의 명령이 들어있다.
• 이걸 Load Process라고 하며, 사전 Load Process덕분에 CPU가 직접 Program에 Access 할 수 있다.
• 예를 들어 Application 실행 전에 대규모의 데이터를 미리 Load해야 한다고 가정하자. 고성능 Data Base일 수도 있고, 비정형 데이터를 실시간으로 처리해야 할 수도 있다. 이럴때, 메모리 최적화 인스턴스 사용을 고려해야 한다.

Accelerated Computer

• 하드웨어 가속 또는 Co-Processor를 사용하며, 일부 특수한 기능을 CPU보다 효율적으로 처리한다.
• 예를 들어 부동 소수점 계산, 그래픽 처리, 데이터 패턴 일치 등이 있다.

Storage Optimization

• Local Storage의 대규모 데이터 세트에 대한 순차 읽기 및 쓰기 엑세스가 많이 필요한 워크로드를 위해 설계됨
• Storage 최적화 instance가 필요한 예로는 분산 파일 시스템, 데이터 웨어 하우징 어플리케이션, 고빈도 온라인 트렌젝션 처리(OLPT) 시스템 등이 있다.
• IOPS(초당 입출력 작업 수)라는 용어는 Storage Device의 성능을 측정하는 지표인데, 스토리지 최적화 인스턴스는 지연 시간이 짧은, 임의의 IOPS를 어플리케이션에 제공하도록 설계됨

Amazon EC2 요금

1. 온디맨드 - 실행한 기간만 비용을 낸다. 인스턴스 유형과 운영체제에 따라 다르고, 선불제도 있다. 다만 이 방법은 1년 이상, 사용 패턴이 있는 워크로드에는 권장하지 않는다. 다른 방식이 비용절감 효가가 더 크기 때문이다.
2. Savings Plans - 일정 사용량을 약정하여, 1년에서 3년 동안 계약한다. 요금을 최대 72%까지 절약이 가능하다.
3. 예약 인스턴스 - 온디맨드보다 75% 저렴하다. 약정 시 일부 금액을 낸다. 온디맨드 인스턴스 사용 시, 결제 할인 옵션이다.
4. 스팟 인스턴스 - 온디맨드보다 90% 저렴하다. 워크로드 중단이 가능한 인스턴스 전용이다. 비용이 저렴한 대신에 예고없이 중단이 될 수 있다. 예를 들어 스팟 인스턴스의 수요가 늘어날 경우, 중단이 가능하다.
5. 전용 호스트 - 이 호스트의 태넌시는 다른 사람과 공유하지 않는다. 대신에 가장 비싼 옵션이다.

Amazon EC2 확장

확장성 및 탄력성

온프레미스 데이터 센터에는 문제점이 있는데 바로 워크로드의 변화에 능동적으로 대처하지 못한다는 것이다. 따라서 가장 많이 사용하는 시간을 기준으로 하드웨어를 구성해야 하는데 이는 효율적이지 못하다.

그렇다고 평균 부하에 맞추면 특정 시점에 고객 경험이 좋지 않을 것 이다.

이 부분은 궁긍적으로 온프레미스 환경에서는 해결이 불가능하다.

AWS는 이 문제를 능동적으로 프로비저닝하여 해결한다.

• 장애에 대비한다. : 장애는 언제나 발생하니 장애에 대한 설계로 무장애를 구성하라
  한 쪽에 장애가 발생하면 다른 쪽에서 서비스를 진행한다. - 중복 인스턴스
• 단일 장애가 발생하지 않도록 구성한다.

Amazon EC2 Auto Sacling

어플리케이션의 수요에 따라 Amazon EC2 intance를 자동으로 추가하거나 제거할 수 있다.
필요에 따라 instance를 자동으로 조정하여 어플리케이션의 가용성을 효과적으로 유지할 수 있다.

• 동적 조정 : 수요 변화에 대응한다.
• 예측 조정 : 예측된 수용에 따라 적절한 수의 Amazon EC2 instance를 자동으로 예약한다.

• 수직 증가 : 실행 중인 장치에 성능을 추가하는 작업
• 수평 증가 : instance 추가 확장

고객이 급증하는 순간에 자원을 추가하고, 고객이 줄어들면 자원을 가져간다.

Auto Scaling에 설정할 수 있는 항목은 아래와 같다.

• 최소 용량 : 1 instance
• 희망 용량 : 2 -> 지정하지 않으면 최소 용량과 같다.
• 최대 용량 : 14

Elasitc Load Balancing을 사용하여 트래픽 리디렉션

트래픽 문제를 해결할 때 사용한다.

각 instance에 고객이 균일하게 오지 않을 수 있다.
이 때 고객에게 어디로 갈 지 알려주는 호스트가 있으면 좋을 것이다.

여유가 있는 instance로 요청을 보내는 것이다.

요청을 요청을 처리할 instance로 라우팅할 수 있어야 한다.

이를 Load Balancer라고 한다.

AWS에는 관련된 여러 서비스가 있다.

트래픽을 적절하게 분산하는데 있어서 우리는

• 고성능
• 비용 효율성
• 고가용성
• 자동 확장 기능

을 중요하게 생각한다.

ELB(Elastic Load Balancing)

• 리전 수준 구조인데, 개별 EC2 수준이 아니기 때문에 사용자가 고민하지 않아도 자동으로 처리량을 처리하도록 설계되어 있다.

ELB는 외부 트래픽도 처리한다.

프론트 엔드에 들어온 트래픽을 하나로 모아서, 적절하게 백엔드로 보내준다.

ELB는 Auto Scaling Group으로 들어오는 모든 웹 트래픽의 단일 접점 역할을 한다.

들어오는 트래픽의 양에 맞춰서 EC2 instance를 추가하거나 제거하므로 해당 요청을 ELB로 먼저 라우팅된다.

그 다음에 해당 요청을 여러 리소스로 분산한다.

메시징 및 대기열(queueing)

프론트 엔드와 백엔드가 적절하게 진행되지 않으면 버려지는 고객 요청이 있을 수 있다.

queueing은 이러한 고객 요청을 적절하게 대기시켜 놓치는 고객 요청이 없도록 도와준다.

소결합된 아키텍쳐 : 단일 장애로 인해 서비스가 멈추지 않음
-> 마이크로서비스 어플리케이션

밀접하게 아키텍쳐가 구성되어 있다면, 어플리케이션 A에서 어플리케이션 B로 메시지를 보내는 시스템에서 한 곳에 장애가 발생하면 전체 서비스가 멈추게 된다.
-> 모놀리식 어플리케이션

하지만 중간에 버퍼가 있다면, 한 곳이 장애가 있을 경우에 회복 될 때까지 버퍼에 메시지를 넣어두고 회복을 기다릴 수 있다.

이러한 것을 지원하는 서비스로는 Amazon SQS가 있다.

• 메시지 전송
• 메시지 저장
• 메시지 수신
• 소프트웨어 구성 요소 간
• 모든 볼륨에서

페이로드 : 메시지 내 포함된 데이터

Amazon SNS

• 게시/구독 서비스이다. topic으로 구분하며, pub/sub을 통해 메시지를 사용자에게 직접 전달 할 수 있다. - 모바일 푸시, SNS, email

추가 컴퓨팅 서비스

EC2은 확장성이나 안정성에 높은 장점이 있다.

하지만 관리 프로세스가 필요하다.

AWS에는 관리 편한 컴퓨팅 서비스가 또 있다.

서버리스 컴퓨팅

• 기본 인프라를 보거나 접속할 수 없다.

기본 환경 관리를 자동으로 처리해준다.
사용자는 어플리케이션만 신경 쓰면 된다.

AWS Lambda

• Trigger가 감지되면 코드가 실행된다.
• 람다는 15분 이내 실행 코드에 적합하다.
• 요청이 1개든 1000개든 중요하지 않다.

AWS ECS(Elastic Container Service)
AWS EKS(Elastic Kubernetics Service)

• 두 서비스 모두 컨테이너 오케스트레이션 도구이다.
• 컨테이너는 도커 컨테이너이다.
• 컨테이너는 코드 패키지이다. 가상 머신처럼 격리되서 실행된다.
• 인스턴스 뿐 아니라 클러스터를 실행, 모니터링하는 프로세스가 필요하다. 이런 부분을 지원하기 위해 이 서비스가 설계되었다.
• 두 서비스는 EC2 위에서 실행 가능하다.

AWS Fargate

• ECS와 EKS용 서버리스 컴퓨팅 서비스이다.

모듈 2 요약

• EC2 인스턴스 유형 및 요금 옵션
• EC2 Auto Scaling
• Elastic Load Balancing
• 메시징, 컨테이너 및 서비리스 컴퓨팅용 AWS 서비스