AWS Cloud Practitioner Essentials 강의 요약 1

AWS skill builder 강의(AWS Cloud Practitioner Essentials)를 듣고 정리한 글입니다 📚

module1: amazon web service 소개

아마존웹서비스(AWS)란 클라우드 컴퓨팅 분야에서 세계 1위 점유율을 차지하고 있는 클라우드 컴퓨팅 서비스이다.

'전 세계에 분포된 데이터 센터에서 다양한 기능을 제공하는 클라우드 플랫폼'

AWS에서는 컴퓨팅, 스토리지, 네트워크 보안 도구와 같은 기본 요소에서부터 블록체인, 기계학습, 인공 지능, 로봇 개발 플랫폼 같은 복잡한 솔루션에 이르기까지 수백개의 다양한 서비스를 제공한다.

클라우드 컴퓨팅

IT 리소스를 인터넷을 통해 온디맨드로 제공하며 사용한 만큼만 비용을 제공한다

온디맨드란 사용자에게 필요한 리소스를 필요한 순간에 전달하는 것

종량 과금제

클라우드를 필요한 만큼만 사용하고 사용한 만큼만 지불한다

클라우드 컴퓨팅을 위한 배포 모델

클라우드 기반, 온프레미스, 하이브리드 등 3가지가 존재한다

• 클라우드 기반 배포
  • 애플리케이션의 모든 부분을 클라우드에서 실행한다.
  • 기존 애플리케이션을 클라우드로 마이그레이션 한다.
  • 클라우드에서 새 애플리케이션을 설계 및 빌드한다.
• 온프레미스 배포 (프라이빗 클라우드 배포)
  • 가상화 및 리소스 관리 도구를 사용하여 리소스를 배포한다.
  • 애플리케이션 관리 및 가상화 기술을 사용하여 리소스 활용도를 높인다.

    ⚠️ 온프레미스와 온프레미스 배포(프라이빗 클라우드)는 다르다
    온프레미스는 기업이 자체적으로 보유하여 운영하는 물리적인 서버(데이터센터)를 말한다. 이는 운영에 필요한 공간과 시스템이 필요하다.

    반면 프라이빗 클라우드의 경우 기업의 전용 클라우드 환경이라고 생각하면 된다. 자체 데이터 센터 소유는 유지하면서 가상화 및 클라우드 기술을 활용해 리소스를 효율적으로 관리하는 방식이다.

• 하이브리드 배포
  • 클라우드 기반 리소스를 온프레미스 인프라에 연결한다
  • 온프레미스에서 더 잘 유지 관리되는 레거시 애플이케이션은 그대로 두고 클라우드에서 실행되는 서비스를 활용한다면 이는 하이브리드 배포
  • 예시
    • 회사에서 배치 데이터 처리 및 분석을 자동화하는 클라우드 서비스를 사용하고자 한다. 그러나 해당 회사에는 온프레미스에 더 적합하고 클라우드로 마이그레이션되지 않는 여러 레거시 애플리케이션이 있다. 이 경우 하이브리드 배포를 통해 레거시 애플리케이션은 온프레미스로 유지하면서 클라우드에서 실행되는 데이터 및 분석 서비스의 이점을 활용할 수 있다.

클라우드 컴퓨팅의 이점

1. 선행 비용을 가변 비용으로 대체할 수 있다
   • 미리 투자해서 리소스를 사용하는 경우 선행 비용이 발생하지만 클라우드 컴퓨팅 접근 방식을 활용하면 사용하는 컴퓨팅 리소스에 대해서만 비용을 지불한다.
2. 데이터 센터 운영 및 유지 관리에 비용 투자가 불필요하다.
   • 해당 작업은 AWS가 대행해주기 때문이다.
3. 용량 추정이 불필요하다.
   • 애초에 필요한 용량만을 사용하므로 배포 전 미리 용량을 예측하여 비용을 지불한다거나 제한된 용량만을 사용해야하는 일이 없어진다.
4. 거대한 규모의 경제로 얻게 되는 이점
   • 고객 사용량이 누적될수록 규모 경제가 커지고, 이는 곧 종량 과금제를 통한 요금 감소(+)로 이어진다.
5. 속도 및 민첩성 향상
   • 빠르게 애플리케이션을 배포할 수 있다. 만약 온프레미스 방식이었다면 필요한 새 리소스를 확보하는 데 몇 주가 걸렸을 수도 있다.
6. 몇 분 만에 전 세계에 배포
   • AWS의 글로벌 서비스를 이용한다면 매우 빠르게 전 세계 배포가 가능하다
     • 즉, 다른 지역에 위치한 고객도 지연 시간을 최소화하면서 애플리케이션에 액세스 할 수 있다.

module2: 클라우드 컴퓨팅

EC2 (Elastic Compute Cloud)

EC2는 가상화된 서버에 엑세스하는 데 사용하는 서비스이다.
AWS는 이미 서버를 구입하여 필요한 제반 작업을 마쳤기 때문에 EC2를 통해 필요할 때만 용량의 일정 부분을 마음껏 사용할 수 있다.

사용은 단지 사용자가 원하는 EC2 인스턴스를 요청하기만 하면 되며, 또한 손쉽게 중단하거나 종료할 수 있다. 이때 중단하거나 종료된 인스턴스를 제외하고 실행 중인 인스턴스의 비용만 청구된다. 이를 온디맨드로 프로비저닝한다고 얘기한다.

EC2를 프로비저닝할 땐 OS 종류를 선택하고 네트워킹 측면을 제어하는 등 원하는 방식으로 조합해 비즈니스에 필요한 다양한 애플리케이션을 가동할 수 있다.

EC2 내부 구조

AWS가 관리하고 있는 물리적 호스트 시스템이 존재하며, 이 위에 EC2 인스턴스를 가동시킨다. 이 때 여러 인스턴스를 가동시킬 수 있으며 인스턴스들끼리는 호스트의 리소스를 공유해서 사용하게 된다. 이러한 방식을 가상머신이라고 한다.

하이퍼바이저 - 호스트 머신에서 실행되며 가상 머신끼리 서로 물리적인 리소스를 공유하도록 책임을 지는 소프트웨어

멀티 테넌시 - 여러 가상머신이 기본적인 하드웨어를 공유하는 것

여기서 언급되는 하이퍼바이저는

• 멀티테넌시 조정을 책임지고
• 가상머신을 서로 분리해주는

크게 2가지 역할을 수행한다.

즉, (1) 가상 머신끼리 HW 리소스를 공유하지만, (2)서로를 전혀 인식하지 못하므로 안정성을 높일 수 있다.

EC2의 이점

• 몇 분이면 EC2 인스턴스를 프로비저닝하고 시작할 수 있다

  프로비저닝 - 사용자의 요구에 맞게 시스템 자원을 할당, 배치, 배포해 두었다가 필요 시 시스템을 즉시 사용할 수 있는 상태로 미리 준비해 두는 것

• 워크로드 실행을 완료했다면 인스턴스 사용을 중지할 수 있다

  워크로드 - 주어진 기간에 시스템에 의해 실행되어야 할 작업의 할당량 또는 비즈니스 가치를 창출하는 리소스 및 코드 모음

• 인스턴스가 실행 중일 때 사용한 컴퓨팅 시간에 대해서만 비용을 지불하고 인스턴스가 중지 또는 종료된 상태에서는 비용을 지불하지 않는다
• 필요한 서버 용량에 대해서만 비용을 지불하므로 비용을 절감할 수 있다

EC2 작동 방식

시작

• 인스턴스를 시작한다. 기본 구성 인스턴스가 포함되어 있는 템플릿을 선택하여 시작한다
• 이 때 OS, 애플리케이션 서버, 인스턴스 유형 등을 선택할 수 있다
• 또한 인스턴스로 들어오고 나가는 네트워크 트래픽을 제어할 보안 설정을 지정한다 (인바운드 아웃바운드 규칙을 말하는 듯)

연결

• 프로그램 또는 애플리케이션을 인스턴스에 연결한다.

사용

• 인스턴스에 연결했다면 바로 사용이 가능하다. 명령을 실행해서 SW를 설피하고 스토리지를 추가하고 파일 복사 및 정리 등의 작업을 수행할 수 있다.

EC2 인스턴스 유형

인스턴스 유형은 다양한 작업에 최적화 되어있다. 커피숍을 예를 들면,
계산원은 메모리 최적화 인스턴스이며 바리스타는 컴퓨팅 최적화 인스턴스 일것이다. 라떼아트직원의 경우 엑셀러레이티크 컴퓨팅 인스턴스를 가리킨다고 볼 수 있겠다.

• 범용 인스턴스
  • 컴퓨팅, 메모리, 네트워킹 리소스를 균형있게 제공한다.
  • 예시 유형
    • 애플리케이션 서버, 게임 서버, 엔터프라이드 애플리케이션용 백엔드 서버, 중소규모 데이터베이스
• 컴퓨팅 최적화 인스턴스
  • 예시 유형
    • 고성능 프로세서를 활용하는 컴퓨팅 집약적 애플리케이션
• 메모리 최적화 인스턴스
  • 대규모 데이터 집합을 '처리'하는 워크로드에 적합하다
  • 예시 유형
    - 고성능 데이터베이스 또는 방대한 양의 비정형 데이터의 실시간 처리가 필요한 워크로드
• 액셀러레이티드 컴퓨팅 인스턴스
  • 데이터 처리를 가속화할 수 있다
  • 예시 유형
    • 부동 소수점 수 계산, 그래픽 처리, 데이터 패턴 일치
    • 그래픽 애플리케이션, 게임 스트리밍, 애플리케이션 스트리밍
• 스토리지 최적화 인스턴스
  • IOPS 요구 사항이 높은 애플리케이션에 적합하다

    초당 입출력 작업수(IOPS) - 스토리지 디바이스 성능을 측정하는 지표

  • 예시 유형
    • DB 입출력이 많은 애플리케이션 (데이터 웨어하우스 등)

EC2 요금 옵션

• 온디맨드
  • 중단 불가능한 불규칙한 단기 워크로드가 있는 애플리케이션에 적합하다
  • 선결제 비용이나 최소 약정은 적용되지 않는다
  • 인스턴스가 중지될 때까지 계속 실행되며 사용한 컴퓨팅 시간에 대해서만 비용을 지불한다
  • 1년 이상 지속되는 워크로드에는 권장하지 않음 -> 예약 인스턴스 옵션을 추천
  • 예시
    • 애플리케이션 개발 및 데트스와 예측할 수 없는 사용 패턴이 있는 애플리케이션
• 예약 인스턴스
  • 온디맨드 인스턴스를 사용할 때 적용되는 결제 할인 옵션이다. 1년 또는 3년 약정으로 구입할 수 있으며 표준예약 인스턴스와 컨버터블 예약 인스턴스가 있다
  • 표준 예약 인스턴스
    • 적합한 유형
      • 안정적인 애플리케이션에 필요한 EC2 인스턴스 유형 및 크기, 리전 등을 알고 있는 경우에 적합하다
    • 아래의 자격 요건을 명시해야한다
      • 인스턴스 유형 및 크기 ex. m5.xlarge
      • 플랫폼 설명(OS) ex. Window Server or Red Hat Linux
      • 테넌시 : 기본 테넌시 또는 전용 테넌시
    • 예약 인스턴스의 가용 영역을 지정할 수 있고 이를 지정하면 EC2 용량이 예약된다. 그러면 필요할 때 원하는 양의 EC2 인스턴스를 사용할 수 있다
  • 컨버터블 예약 인스턴스
    • 적합한 유형
      • EC2 인스턴스를 여러 가용 영역 또는 다양한 인스턴스 유형에서 실행해야 하는 경우 컨버터블 예약 인스턴스가 적합하다
      • 유연성이 필요한 경우 더 큰 할인 혜택을 받기 때문이다
  • 예약 인스턴스 약정 기간이 종료되더라도 EC2 인스턴스를 중단 없이 계속 사용할 수 있다. 하지만 다음 중 하나를 수행 할 때까지는 온디맨드 요금이 부관된다
    • 인스턴스 종료
    • 인스턴스 속성과 일치하는 새 예약 인스턴스 구입
• EC2 Instance Savings Plans
  • 특정 인스턴스 패밀리 및 리전에 대해 1년 또는 3년 기간 동안 시간 당 지출 약정을 할 경우 EC2 인스턴스 비용을 할인한다
  • 약정 사용량까지는 할인된 요금이 청구되며 약정을 초과한 사용량에 대해서는 일반 온디맨드 요금이 청구된다.
  • 적합한 유형
    • EC2 사용량에 유연성이 필요한 경우에 적합하다
• 스팟 인스턴스
  • 적합한 유형
    • 시작 및 종료 시간이 자유롭거나 중단을 견딜 수 있는 워크로드에 적합하다
  • 스팟 인스턴스는 미사용 EC2 용량을 사용한다.
    • 예를 들어 고객 설문 조사 데이터 처리를 하는 백그라운드 작업은 필요에 따라 시작 및 중지할 수 있습니다. 전반적인 비즈니스 운영에는 영향을 주지 않고 처리 작업을 시작하고 중지하고자 할 때 스팟 요청을 하여 EC2 용량을 사용할 수 있는 경우 스팟 인스턴스가 시작된다. 하지만 사용할 수 있는 용량이 없다면 요청이 성공하지 못한다. 이는 예기치 않은 인스턴스 중단이 발생할 수 있으므로 해당 작업에 더 적합한 다른 EC2 인스턴스 유형을 선택해야한다
• 전용 호스트
  • 사용자 전용의 EC2 인스턴스 용량을 갖춘 물리적 서버
  • 가장 비용이 많이 드는 옵션이다.

EC2의 크기 조정

확장성을 위해서는 필요한 리소스만으로 시작하고 확장 및 축소를 통해 수요 변화에 자동으로 대응하도록 아키텍처를 설계해야 한다. 이러한 프로세스가 자동으로 수행되기 위해 Amazon EC2 Auto Scaling 서비스를 사용할 수 있다.

Amazon EC2 Auto Scaling을 사용하면 변화하는 애플리케이션 수요에 따라 인스턴스를 자동으로 추가하거나 제거할 수 있다. 이를 통해 애플리케이션 가용성을 효과적으로 유지할 수 있다. 해당 서비스는 2가지 접근 방식을 사용한다.

• 동적 조정 - 수요 변화에 대응한다
• 예측 조정 - 예측된 수요에 따라 적절한 수의 인스턴스를 자동으로 예약한다.
  
  위 사진의 예시를 통해 Auto Scaling을 진행할 때 그룹의 크기를 옵션에 따라 설정하는 법에 알아보자
• 최소 용량 - Auto Scaling 그룹을 생성한 직후 시작되는 EC2 인스턴스의 수
• 희망 용량 - 해당 옵션의 default는 최소용량의 크기이다
• 최대 용량 - 최대로 확장할 수 있는 인스턴스의 개수를 제한할 수 있다.

💰 이런 방식을 통해 비용을 줄이면서도 최상의 고객 경험을 제공하는 비용 효율적인 아키텍처를 갖출 수 있다

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

확장성을 위해선 EC2 Auto Scaling 서비스를 사용할 수 있지만 대규모 트래픽들을 어느 인스턴스로 라우팅해야 할지 즉, 시스템의 트래픽을 적절하게 분산하기 위해서는 Elastic Load Balancing 서비스가 필요하다.

로드 밸런서 - 요청을 받은 다음 처리할 인스턴스로 라우팅하는 애플리케이션

ELB와 EC2 Auto Scaling은 별도의 서비스이지만 서로 연동해서 EC2에서 실행되는 애플리케이션이 뛰어난 성능과 가용성을 제공하도록 돕는다.

보통의 트래픽 수준일 때 기존 Auto Scaling 그룹의 인스턴스로 충분히 서비스 가능하며 ELB를 통해 로드밸런싱을 한다.

위와 같이 트래픽이 급격히 늘어가 새로운 인스턴스가 추가되면 ELB에게 작업하라는 지시를 보내어 ELB-Auto Acaling 간 연동을 시작하게 된다.

로드밸런서는 외부 트래픽 말고 내부 트래픽에서도 사용될 수 있다.

예시로 프론트 서버를 담당하는 주문 계층 과 백엔드 서버를 담당하는 생산 계층 이 있다고 가정할 때 아래와 같이 ELB 서비스를 사용할 수 있다.

여기서 ELB는 백엔드 트래픽 혼란을 해결하기 위해 사용한다.
ELB는 리전구조의 단일 URL로 각 프론트엔드 인스턴스에 사용되며 대기중 요청이 가장 적은 백엔드로 트래픽을 보낸다.

위 구조에서 프론트엔드는 실행중인 백엔드 인스턴스의 개수를 알지 못하며 신경쓰지도 않는다. 이는 진정 분리된 아키텍처라고 말할 수 있다.

메시징 및 대기열

☕️ 커피숍에서 계산원이 주문받은 주문서를 바리스타에게 직접 건네준다고 생각해보자. 만약 바리스타가 너무 바쁘다거나 잠시 자리를 비운다면 계산원은 주문서를 전달하기 위해 한없이 기다리게 될 뿐만 아니라 다음 고객을 응대하는 데에도 시간이 오래 걸릴 것이다.

이런 상황을 개선하기 위해 직접 주문서를 전달하지 않고 주문판 같은 일종의 버터에 주문을 게시한다면 어떻게 될까? 바리스타가 현재 너무 바쁘거나 잠시 자리를 비우더라도 주문판에 적혀진 주문 내역을 보고 이어서 커피를 만들어 낼 수 있을 것이다.

이렇게 메시지를 완충 기억 장치에 배치한다는 개념을 메시징 혹은 대기열 이라고 한다.

메시징 대기열을 도입하면 소결합된 상태로 아키텍처를 구상할 수 있다

밀결합된 아키텍처 - 구성 요소 하나가 고장이 나거나 변경되면 다른 구성 요소나 심지어 시스템 전체에 문제가 발생한다 (ex. 모놀리스 애플리케이션)

소결합된 아키텍처 - 특정 구성 요소에 장애가 발생하더라도 장애가 구성 요소 안에 격리 되기 때문에 전체 시스템 장애로 확장되지 않는다. (ex. 마이크로서비스)

즉 메시징 대기열을 도입하여 소결합된 아키텍처를 구상한다면, 각 구성 요소는 서로의 상태와 상관없이 안전하게 대기열에 메시지를 보관해두고 꺼내 쓸 수 있다.

이와 관련된 AWS 서비스로는 Amazon Simple Queue Service (SQS) 와 Amazon Simple notificatoin Service (SNS) 가 있다.

Amazon Simple Queue Service (SQS)를 이용하면

• 구성 요소 간 메시지 전송, 저장, 수신이 가능하고
• 다중화가 내재되어 있어 메시지를 잃어버리거나 서비스가 중단될 염려가 없다.
• SQS 대기열 - 메시지가 처리되기 전까지 배치되는 곳
  

---

Amazon Simple notification Service (SNS)를 이용하면

• 메시지를 서비스에 전달하는 데 사용한다는 점에서 SQS와 비슷하지만
• 알림을 최종 사용자에게도 전송 할 수 있다.
• pub(게시)-sub(구독) 구조
  • 메시지를 전달하는 채널인 SNS 주제를 만들고 이에 대한 구독자를 구성하여 구독자들에게 최종적으로 메시지를 게시한다.
  • 구독자 대상 - SQS 대기열, AWS lambda gkatn, HTTPS, HTTP 웹 후크
• 모바일 푸시, SMS와 이메일을 사용해 알림을 최종 사용자에게 전달 할 수 있다
• 단일 주제 또는 여러 주제를 게시할 수 있다.
  

추가 컴퓨팅 서비스

1. 서버리스 컴퓨팅의 개념

서버리스라는 용어는 코드가 서버에서 실행되지만 이러한 서버를 프로비저닝하거나 관리할 필요가 없다는 뜻이다. 이를 사용하면 서버를 유지 관리하는 대신 새로운 제품과 기능을 혁신하는 데 더 집중할 수 있다.

2. AWS Lambda 서비스

서버리스 컴퓨팅용 AWS 서비스이다. 서버를 프로비저닝하거나 관리할 필요 없이 코드를 실행할 수 있다.또한 사용한 컴퓨팅 시간에 대해서만 비용을 지불할 수 있어 비용 효율적이다.

📷 예를 들어 간단한 Lambda 함수로 업로드되는 이미지의 크기를 AWS 클라우드에 맞춰 자동으로 조정하는 함수가 있다면 새 이미지를 업로드할 때 함수가 트리거 되며 작동 방식(순서)는 아래와 같다.

1. 코드를 lambda에 업로드한다.
2. AWS 서비스, 모바일 애플리케이션 또는 HTTP 엔드포인트와 같은 이벤트 소스에서 트리거되도록 코드를 설정한다.
3. Lambda는 트리거된 경우에만 코드를 실행한다.
4. 사용한 컴퓨팅 시간에 대해서만 요금을 지불한다.

EC2 외의 컴퓨팅 서비스를 살펴보자

서버리스 - 기본 인프라를 보거나 액세스할 수 없음 (AWS가 대신 처리) 그렇다면 사용자는 애플리케이션만 신경쓰면 됨

람다에 코드를 올림.
람다함수에서는 서비스가 트리거에 되기를 기다림 -> 가용성이 높음 환경 유지 관리를 모두 ㅣambda에서 사용함

코드가 15분 미만으로 설계되도록 구성됨 따라서 딥러닝 같은 장기 시스템에는 적합하지 않음
웹 서비스 백엔드 처리가 필요할 때 필요함.

그렇다면 스프링을 람다에도 올릴 수 있는 것인가?

기본 환경에 엑세스해야하지만 효율성이 높아지는 경우 AWS elastic elastic kubernated
컨테이너 오케스트레이션 도구
컨테이너-도커
도커- OS 수준의 가상화
컨테이너- 코드 패키지
EC2 - 서버 가상화 (도커와 비슷함)
호스트가 EC2

3. 컨테이너 개념

컨테이너는 애플리케이션의 코드와 종속성을 하나의 객체로 패키징하는 표준 방식을 제공한다. 보안성, 신뢰성, 확장성 요구사항이 매우 중요한 프로세스 및 워크플로우에도 컨테이너를 사용한다.

4. AWS ECS / AWS EKS / AWS Fargate

• Amazon Elastic Container Service (ECS)
  • AWS에서 컨테이너식 애플리케이션을 실행하고 확장할 수 있는 고성능 컨테이너 관리 시스템이다.
  • Dokcer 컨테이너를 지원한다

    Docker - 애플리케이션을 신속하게 구축, 테스트, 배포할 수 있는 소트프웨어 플랫폼

  • ECS는 API 호출을 통해 Docker 지원 애플리케이션을 시작 및 중지할 수 있다.
• Amazon Elastic Kubernetes Servise (EKS)
  • AWS에서 kubernetes를 실행하는 데 사용할 수 있는 완전 관리형 서비스

    Kubenetes - 컨테이너식 애플리케이션을 대규모로 배포하고 관리하는 데 사용할 수 있는 오픈 소스 소프트웨어

• AWS Fargate
  • 컨테이너용 서버리스 컴퓨팅 엔진
  • Amazon ECS와 Amazon EKS에서 작동한다
  • EC2 위에 ECS, EKS를 올리지 않고 Fargate에 올리면 서버리스 컨테이너 아키텍처를 구상할 수 있다는 뜻 같다.

Docker vs Container
도커는 한 개의 컨테이너를 관리하는데 최적화 되어있고, 쿠버네티스는 여러 개의 컨테이너를 서비스 단위로 관리하는 데 최적화 되어있다.
이 글을 참고해보면 좋을 것 같다.