Infra/cloud

[AFOS] 2주차 컴퓨팅 서비스

미니문92 2021. 7. 9. 03:25

1. AWS 글로벌 인프라

글로벌 인프라 : https://aws.amazon.com/ko/about-aws/global-infrastructure/

  • 25개 리전, 81개 가용 영역, 230개이상의 POP 운영
  • 각각의 리전은 이중화된 100G케이블(해저 광케이블)로 연결, 암호화 되어 전달

AWS 글로벌 인프라 맵 : https://aws.amazon.com/ko/about-aws/global-infrastructure/regions_az/

대륙별, 국가별로 데이터 센터를 두는 이유
- 운영 주체 구분
- 거리에 따른 지연
- 법적 규제 및 데이터 거버넌스
- 리전 내에서 사용 가능한 서비스

 

초창기 아마존의 고민 -> 가용 영역 개념 출발

Latency - 패킷을 전송하는 곳에서부터 전달받는 곳까지 이동하는 데 걸리는 시간
  • 전파 지연(Propagation delay) : 송신측 -> 수신측으로 이동하는데 필요한 시간, 총 이동거리 대비 신호가 이동하는 속도로 측정
  • 빛의 속도 : 299,792,458m/s
  • 대부분의 사람들은 시스템에서 1~200ms 지연을 감지하고 300ms이상시 '느리다'고 인식
  • AWS AZ 배치 기준 : 재해 극복과 지연의 trade-off => Goldilocks Zone
  • 레이턴시 극복을 위해 글로벌 서비스의 경우 대륙별 지역 서버 배치

 

AWS 리전 간 레이턴시 확인 : https://www.cloudping.co/grid

사용자 브라우저와 리전 간 레이턴시 확인 : https://www.cloudping.info/



 

2. AWS 리전 & 가용영역 & 엣지

리전(Region)

 

  • 해당 지리적인 영역 내에서 격리되고 물리적으로 분리된 여러 개의 가용 영역(AZ) 의 모음
  • 최소 2개의 가용 영역으로 구성되고 최대 6개의 가용영역으로 구성된 리전도 있음

 


가용영역(Available Zone)

 

  • 한 개 이상의 데이터 센터들의 모음. 각 센터는 광통신 전용망으로 연결
  • 각각의 다른 가용영역의 장애로부터 격리될 수 있음
  • 자연 재해 도는 단층선에 문제가 발생할 수 있는 곳은 AWS에서 가용영역 분리
  • 가용 영역과 외부(인터넷) 연결을 위한 이중화된 트랜짓 센터가 있음
  • 트랜짓 센터는 AWS 글로벌 백본 네트워크에 연결, 엣지 POP을 통해서 CDN 등 서비스

 

 

  • AWS 사용자는 서비스 구성시 여러 가용 영역에 분산하여 처리할 수 있도록 구성 권장

 

가용 영역(AZ)가 장애가 날수 있다 없다? 
-> AWS 도쿄 리전 AZ 장애
관련 기사 링크 :
https://www.itdaily.kr/news/articleView.html?idxno=201880
https://zdnet.co.kr/view/?no=20190824090716
http://www.bloter.net/archives/532039
https://marsettler.com/server-fault/2021-02-21-cookierun-kingdom-server-faultaws/
https://www.clien.net/service/board/news/15905971

 

엣지(Edge)

 

  • 외부 인터넷과 AWS 글로벌 네트워크망과 연결하는 별도의 센터
  • 엣지 로케이션과 리전별 엣지 캐시로 구성되며, CloudFront와 같은 CDN 서비스의 데이터 캐시 기능을 제공

 



 

3. EC2 소개

 

AWS 컴퓨팅 서비스 범주

 

 


EC2란

 

  • Amazon Elastic Compute Cloud
  • 확장 가능 컴퓨팅 용량 제공
  • 가상 서버(=인스턴스 Instance)를 구축하고 보안 및 네트워크 구성, 스토리지 관리 가능
  • 요구사항, 갑작스런 인기 즈앧 등 변동 사항에 따라 신속하게 규모 확장, 축소 가능

EC2 제공기능

 

  • 인스턴스 : 가상 컴퓨팅 환경
  • Amazon Machine Image(AMI): 서버에 필요한 운영체제와 여러 소프트웨어들이 적절히 구성된 상태로 제공되는 템플릿
  • 인스턴스 유형(Types): 인스턴스를 위한 CPU, 메모리, 스토리지, 네트워킹 용량의 여러 가지 구성 제공
  • 키 페어를 사용하여 인스턴스 로그인 정보 보호(AWS는 퍼블릭 키를 저장하고 사용자는 개인 키를 안전한 장소에 보관하는 방식)
  • 인스턴스 스토어 볼륨: 임시 데이터를 저장하는 스토리지 볼륨으로 인스턴스 중단, 최대 절전 모드로 전환 또는 종료 시 삭제됨
  • Amazon Elastic Block Store(Amazon EBS), 즉 Amazon EBS 볼륨을 사용해 영구 스토리지 볼륨에 데이터 저장
  • 인스턴스와 Amazon EBS 볼륨 등의 리소스를 다른 물리적 장소에서 액세스할 수 있는 리전 및 가용 영역
  • 보안 그룹을 사용해 인스턴스에 연결할 수 있는 프로토콜, 포트, 소스 IP 범위를 지정하는 방화벽 기능
  • 탄력적 IP 주소(EIP): 동적 클라우드 컴퓨팅을 위한 고정 IPv4 주소
  • 태그: 사용자가 생성하여 Amazon EC2 리소스에 할당할 수 있는 메타데이터
  • AWS 클라우드에서는 논리적으로 격리되어 있지만 원할 때마다 고객의 네트워크와 간편히 연결할 수 있는 가상 네트워크인 Virtual Private Clouds(VPC)  

 

인스턴스 유형

 

  • 인스턴스를 시작할 때 지정하는 인스턴스 유형에 따라 인스턴스에 사용되는 호스트 컴퓨터의 하드웨어가 결정
  • 각 인스턴스 유형은 서로 다른 컴퓨팅, 메모리, 스토리지 용량을 제공하는데, 이 용량에 따라 서로 다른 인스턴스 패밀리로 분류
  • 인스턴스에서 실행하려는 애플리케이션 또는 소프트웨어의 요구 사항에 따라 인스턴스 유형을 선택
  • Amazon EC2에서는 실제로 사용되는 하드웨어에 관계없이 각 인스턴스에 일정하고 예측 가능한 CPU 용량을 제공

 

인스턴스 구입 옵션

 

  • 온디맨드 인스턴스 - 시작하는 인스턴스에 대한 비용을 초 단위로 지불
  • Savings Plans – 1년 또는 3년 기간 동안 시간당 USD로 일관된 컴퓨팅 사용량을 약정하여 Amazon EC2 비용 절감 가능
  • 예약 인스턴스(RI) – 1년 또는 3년 기간 동안 인스턴스 유형 또는 지역을 포함해 일관된 인스턴스 구성을 약정하여 Amazon EC2 비용을 절감 가능
  • 스팟 인스턴스 – 미사용 EC2 인스턴스를 요청하여 Amazon EC2 비용을 대폭 줄일 수 있음
  • 전용 호스트 - 인스턴스 실행을 전담하는 실제 호스트 비용을 지불하며, 기존의 소켓, 코어 또는 VM 소프트웨어별 라이선스를 가져와 비용을 절감
  • 전용 인스턴스 - 단일 테넌트 하드웨어에서 실행되는 인스턴스 비용을 시간 단위로 지불
  • 용량 예약 – 원하는 기간 동안 특정 가용 영역의 EC2 인스턴스에 대해 용량을 예약

 

AMI

 

  • Amazon 머신 이미지(AMI)는 소프트웨어 구성이 기재된 템플릿(예: 운영 체제, 애플리케이션 서버, 애플리케이션)
  • AMI에서 인스턴스를 바로 시작할 수 있고, 이 인스턴스는 AMI의 사본으로, 클라우드에서 실행되는 가상 서버
  • 한 AMI로 여러 인스턴스를 실행 가능


 

EC2 인스턴스 수명 주기

 

https://zetawiki.com/wiki/%EC%95%84%EB%A7%88%EC%A1%B4_EC2_%EC%9D%B8%EC%8A%A4%ED%84%B4%EC%8A%A4_%EC%88%98%EB%AA%85%EC%A3%BC%EA%B8%B0

 


EC2 스토리지

 

  • Amazon EC2는 고객의 상황에 맞춰 유연하고 비용대비 효율적이며 사용이 쉬운 데이터 스토리지 옵션 제공
  • 각 옵션은 성능과 내구성이 조합되어 고유하게 구성. 이러한 스토리지 옵션은 독립적으로 또는 요구 사항에 맞춰 조합하여 사용

제공되는 스토리지 옵션

 

 

 


EBS 볼륨 유형

 

  • Amazon EBS는 다음의 볼륨 유형을 제공하고 이러한 볼륨 유형은 성능 특성과 가격이 다르므로 애플리케이션의 필요에 맞게 스토리지 성능과 비용을 조정 가능
  • SSD(Solid-State Drive) — 주요 성능 특성이 IOPS인 작은 I/O 크기의 읽기/쓰기 작업을 자주 처리하는 트랜잭션 워크로드에 최적화
    • 범용 SSD — 가격과 성능 간의 균형을 제공. 대부분의 워크로드에 이 볼륨을 사용
    • 프로비저닝된 IOPS SSD — 지연 시간이 짧거나 처리량이 많은 미션 크리티컬 워크로드에 적합한 고성능을 제공
  • HDD(Hard Disk Drive) — 주요 성능 특성이 처리량인 대규모 스트리밍 워크로드에 최적화
    • 처리량에 최적화된 HDD — 자주 액세스하는 처리량 집약적 워크로드에 적합한 저비용 HDD
    • Cold HDD — 자주 액세스하지 않는 워크로드에 적합한 가장 저렴한 HDD
  • 이전 세대 — 데이터를 자주 액세스하지 않고 성능이 중요하지 않은 소규모 데이터 세트가 있는 워크로드에 사용할 수 있는 하드 디스크 드라이브
    • 이전 세대 사용은 비권장하며, 범용 SSD(gp2 및 gp3) 또는 기타 현재 볼륨 유형 사용을 고려할 것을 권장

EBS 스냅샷

 

  • 지정 시간 스냅샷을 만들어 Amazon S3에 Amazon EBS 볼륨의 데이터를 백업. 그러면 스냅샷을 만드는 데 필요한 시간이 최소화되며 데이터를 복제하지 않으므로 스토리지 비용 절약 가능
  • 스냅샷을 기반으로 EBS 볼륨을 생성하는 경우, 새 볼륨은 해당 스냅샷을 생성하는 데 사용된 원본 볼륨과 정확히 일치
  • 각 스냅샷에는 (스냅샷을 만든 시점의) 데이터를 새 EBS 볼륨에 복원하는 데 필요한 모든 정보 포함
  • 스냅샷은 증분식 백업이어서 마지막 스냅샷 이후 변경된 디바이스의 블록만이 저장
  • 자세한 내용 - Amazon EBS 스냅샷 생성

http://en.clouddesignpattern.org/index.php/CDP:Snapshot_Pattern

  • 증분식 스냅샷 작동방식
    • 아래 다이어그램에서 볼륨 1은 세 가지 시점에 표시 이 각 세 가지 볼륨 상태에 대한 스냅샷 생성
      • 상태 1의 볼륨에는 10GiB의 데이터가 있습니다. 스냅 A는 이 볼륨의 첫 번째 스냅샷이므로 10GiB 데이터 전체를 복사해야 합니다.
      • 상태 2의 볼륨에는 여전히 10GiB의 데이터가 있지만 4GiB가 변경되었습니다. 스냅 B는 스냅 A를 만든 후 변경된 4GiB만 복사하고 저장해야 합니다.
        • 스냅 A에 이미 복사되어 저장된 변경되지 않은 나머지 6GiB 데이터는 (다시) 복사되는 것이 아니라 스냅 B에서 참조됩니다. 이는 파선 모양 화살표로 표시됩니다.
      • 상태 3에서는 2GiB의 데이터가 볼륨에 추가되어 총 12GiB가 되었습니다. 스냅 C는 스냅 B를 만든 후 추가된 2GiB를 복사해야 합니다.
        • 파선 모양 화살표로 표시되었듯이 스냅 C는 스냅 B에 저장된 4GiB의 데이터 및 스냅 A에 저장된 6GiB의 데이터를 참조합니다.
      • 이 세 스냅샷에 필요한 총 스토리지는 16GiB

볼륨의 여러 스냅샷 간의 관계


Cloudwatch 모니터링

 

  • Amazon CloudWatch는 Amazon Web Services(AWS) 리소스와 AWS에서 실시간으로 실행 중인 애플리케이션을 모니터링
  • 지표를 감시해 알림을 보내거나 임계값을 위반한 경우 모니터링 중인 리소스를 자동으로 변경하는 경보를 생성
  • CloudWatch 로 인스턴스 모니터링 - 링크
  • Amazon EC2는 기본적으로 측정치 데이터를 5분 동안 CloudWatch에 전송
  • 사용가능한 지표 - 링크
    • CPUUtilization : 인스턴스에서 현재 사용 중인 할당된 EC2 컴퓨팅 유닛(ECU)의 비율(%)
      • The percentage of allocated EC2 compute units that are currently in use on the instance.

 

인스턴스 시작 시 명령 실행(User Data - shell 스크립트) - 링크

 

  • Amazon EC2에서 인스턴스를 시작할 때 사용자 데이터를 인스턴스에 전달하여 일반적인 구성 작업을 자동으로 수행하는 데 사용
  • Amazon EC2에 shell 스크립트  cloud-init 명령이라는 두 가지 유형의 사용자 데이터를 전달 가능

 

 

Shell 스크립트

  • 기본적으로 사용자 데이터 스크립트 및 cloud-init 명령은 최초로 인스턴스를 시작할 때만 실행
  • 사용자 데이터 shell 스크립트는 #! 문자 및 스크립트를 읽을 인터프리터의 경로(일반적으로 /bin/bash))로 시작
  • 사용자 데이터로 입력된 스크립트는 root 사용자 권한으로 실행되므로 스크립트에 sudo 명령을 사용 X
#!/bin/bash
yum update -y https
systemctl start httpd
systemctl enable httpd