aws 정리

Huiji Kim·2023년 11월 14일
0

클라우드 컴퓨팅의 모델

어플리케이션의 구성

IaaS

  • 인프라만 제공
  • OS를 직접 설치하고 필요한 소프트웨어를 개발해서 사용
  • 즉 가상의 컴퓨터를 하나 임대하는 것과 비슷함
  • 예) AWS EC2

PaaS

  • 인프라 + OS + 기타 프로그램 실행에 필요한 부분(런타임)
  • 바로 코드만 올려서 돌릴 수 있도록 구성
  • 예) Firebase, Google App Engine

SaaS

  • 인프라 + OS + 필요한 소프트웨어가 제공됨
  • 서비스 자체를 제공
  • 다른 세팅 없이 서비스만 이용
  • 예) Gmail, DropBox, Slack, Google Docs

클라우드 컴퓨팅 배포 모델

공개형(클라우드)

  • 모든 부분이 클라우드에서 실행
  • 낮은 비용
  • 높은 확장성

혼합형(하이브리드)

  • 폐쇄형과 공개형의 혼합
  • 폐쇄형에서 공개형으로 전환되는 과도기에 사용
  • 혹은 폐쇄형의 백업으로 사용

온-프레미스(폐쇄형)

  • 높은 수준의 커스터마이징
  • 초기비용이 비쌈
  • 유지보수 비용이 비쌈
  • 높은 보안

AWS의 구조

가용영역(Availability Zone)

리전의 하부 단위

  • 하나의 리전은 반드시 2개 이상의 가용영역으로 구성

하나이상의 데이터 센터로 구성

리전간의 연결은 매우 빠른 전용 네트워크로 연결

반드시 물리적으로 일정거리 떨어져있음

  • 다만 모든 AZ는 서로 100km 이내의 거리에 위치
  • 여러 재해에 대한 대비 및 보안


user A의 AZ-A와 user B의 AZ-A는 서로 다르다.
무의식적으로 모두 AZ-A를 선택하면 AZ-A에만 트래픽이 몰리기 때문에 사용자마다 다르다.

엣지 로케이션

  • AWS의 CloudFront(CDN) 등의 여러 서비스들을 가장 빠른 속도로 제공(캐싱)하기 위한 거점
  • 전 세계에 여러 장소에 흩어져 있음

글로벌 서비스와 리전 서비스

AWS에는 서비스가 제공되는 지역의 기반에 따라 글로벌 서비스와 리전 서비스로 분류
글로벌 서비스 : 데이터 및 서비스를 전 세계의 모든 인프라가 공유

  • CloudFront
  • IAM
  • Route 53
  • WAF
    지역 서비스 : 특정 리전을 기반으로 데이터 및 서비스를 제공
  • 대부분의 서비스
  • S3
    -> S3의 경우 전 세계에서 동일하게 사용할 수 있으나 데이터 자체는 리전에 종속

AWS의 유저

루트 유저

  • 생성한 계정의 모든 권한을 자동으로 가지고 있음
  • 생성시 만든 이메일 주소로 로그인
  • 탈취당했을 때 복구가 매우 힘듦 : 사용을 자제하고 MFA 설정 필요
  • 루트 유저는 관리용으로만 이용 : 계정 설정 변경, 빌링 등
  • AWS API 호출 불가(AccessKey/SecretKey 부여 불가)

IAM User

  • IAM(Identity and Access Management) 을 통해 생성한 유저
  • 만들 때 주어진 아이디로 로그인
  • 기본 권한 없음 : 따로 권한을 부여해야 함
    - 예) 관리자 IAM User, 개발자 IAM User, 디자이너 IAM User
  • 꼭 사람이 아닌 어플리케이션 등의 가상의 주체를 대표할 수도 있음
  • AWS API 호출 가능
  • AWS의 관리를 제외한 모든 작업은 관리용 IAM User를 만들어 사용
  • 권한 부여시 루트유저와 같이 모든 권한을 가질 수 있지만 빌링 관련 권한은 루트 유저가 허용해야 함
  • 글로벌 서비스

IAM 소개

사용자

  • 실제 AWS를 사용하는 사람 혹은 어플리케이션을 의미

그룹

  • 사용자의 집합
  • 그룹에 속한 사용자는 그룹에 부여된 권한을 행사

정책(Policy)

  • 사용자와 그룹, 역할이 무엇을 할 수 있는지에 관한 문서
  • JSON 형식으로 정의

역할(Role)

  • AWS 리소스에 부여하여 AWS 리소스가 무엇을 할 수 있는지를 정의
  • 혹은 다른 사용자가 역할을 부여 받아 사용
  • 다른 자격에 대해서 신뢰관계를 구축 가능
  • 역할을 바꾸어 가며 서비스를 사용 가능

가상화와 클라우드

들어가기 전에

운영체제 : 시스템 하드웨워 자원과 소프트웨어 자원을 운영 관리하는 프로그램
- 예) Windows, Linux, MacOS, Android

특권명령 : 시스템 요소드로가 소통할 수 있는 명령 (OS만 가능)
- OS는 특권명령 때문에 하나의 하드웨어 시스템당 하나밖에 돌아갈 수 없음
- 일반 프로그램은 특권 명령이 필요없기 때문에 많은 프로그램을 동시에 수행 가능

가상화가 나타나기 전까지는 하나의 하드웨어 시스템은 하나의 OS만 실행이 가능했음
- 즉 일반적인 컴퓨터처럼 직접 OS가 하드웨어에 설ㅊ된 상태(Bare-Metal))로만 운영 가능했었음

1세대 - 완전 가상화(Fully Emulated)

  • 모든 시스템 요소가 에뮬레이터 안에서 돌아감
  • 즉 CPU, 하드디스크, 마더보드 등 모든 요소를 에뮬레이터로 구현하여 OS와 연동
  • 엄청나게 느림

2세대 - Paravirtualization

  • GuestOS는 하이퍼바이저와 통신
  • 하이퍼바이저 : OS와 하드웨어 사이에 존재하는 일종의 가상화 매니저
  • 속도의 향상
  • 몇몇 요소의 경우 여전히 에뮬레이터 필요 = 느림

3세대 - Hardware Virtual Machine(HVM)

  • 하드웨어가 직접 가상화를 지원
  • 직접 GuestOS가 하드웨어와 통신 = 빠른 속도(near bare-metal)
AWS 클라우드 환경에서 리소스를 작은 단위로 빠르게 구성할 수 있는 원동력은 가상화
즉 AWS에서 사용자마다 컴퓨터를 할당해 주는 것이 아닌 이미 구축된 가상화 가능한 서버의 한 부분을 할당해주는 것

EC2 기초

EC2의 특성

초 단위 온디맨드 가격 모델

  • 온디맨드 모델에서는 가격이 초 단위로 결정
  • 서비스 요금을 미리 약정하거나 선입금이 필요 없음

빠른 구축 속도와 확장성

  • 몇분이면 전세계에 인스턴스 수백여대를 구축 가능

다양한 구성방법 지원

  • 머신러닝, 웹서버, 게임서버, 이미지처리 등 다양한 용도에 최적화된 서버 구성 가능
  • 다양한 과금 모델 사용 가능

여러 AWS 서비스와 연동

  • 오토스케일링, Elastic Load Balancer, CloudWatch

EC2의 구성

인스턴스

  • 클라우드에서 사용하는 가상 서버로 CPU, 메모리, 그래픽 카드 등 연산을 위한 하드웨어를 담당

EBS

  • Elastic Block Storage의 줄임말로 클라우드에서 사용하는 가상 하드디스크

AMI

  • EC2 인스턴스를 실행하기 위한 정보를 담고있는 이미지

보안그룹

  • 가상의 방화벽

EC2의 가격 모델

EC2의 가격 정책

On-Demans

  • 실행하는 인스턴스에 따라 시간 또는 초당 컴퓨팅 파워로 측정된 가격을 지불
  • 약정은 필요 없음
  • 장기적인 수요 예측이 힘들거나 유연하게 EC2를 사용하고 싶을 때
  • 한번 써보고 싶을 때

Spot Instance

  • 경매 형식으로 시장에 남는 인스턴스를 저렴하게 구매해서 쓰는 방식
  • 최대 90% 정도 저렴
  • 단 언제 도로 내주어야 할지 모름
  • 시작 종료가 자유롭거나 추가적인 컴퓨팅 파워가 필요한 경우

예약 인스턴스(Reserved Instance-RI)

  • 미리 일정 기간(1~3년) 약정해서 쓰는 방식
  • 최대 75% 정도 저렴
  • 수요 예측이 확실할 때
  • 총 비용을 절감하기 위해 어느정도 기간의 약정이 가능한 사용자

전용 호스트(Dedicated)

  • 실제 물리적인 서버를 임대하는 방식
  • 라이센스 이슈(Windows Server 등)
  • 규정에 따라 필요한 경우
  • 퍼포먼스 이슈 (CPU Steal 등)

인스턴스 유형

각 인스턴스 별로 사용 목적에 따라 최적화

타입

EC2의 구성

EBS

- 가상 하드 드라이브
- EC2 인스턴스가 종료되어도 계속 유지 가능
- 인스턴스 정지 후 재기동 가능
- 하나의 EBS를 여러 EC2 정착 가능
- 루트 볼륨으로 사용 시 EC2가 종료되면 같이 삭제 됨
	- 단 설정을 통해 EBS만 따로 존속 가능
- EC2와 같은 가용영역 존재
- EC2와 네트워크로 연결되어 있음

EBS 종류

Snapshot

- 특정 시간에 EBS 상태의 저장본
- 필요시 스냅샷을 통해 특정 시간의 EBS를 복구 가능
- S3에 보관(증분식 저장)

AMI

- EC2 인스턴스를 실행하기 위해 필요한 정보를 모은 단위
- AMI를 사용하여 EC2를 복제하거나 다른 리전 -> 계정으로 전달 가능
- 스냅샷을 기반으로 AMI 구성 가능

EC2의 생명주기

중지

  • 중지 중에는 인스턴스 요금 미청구
  • EBS, EIP 요금은 청구
  • 중지 후 재시작 시 퍼블릭 ip qusrud

재부팅

  • 퍼블릭 IP 변동 없음

최대 절전 모드

  • 메모리 내용을 보존해서 재시작시 중단지점에서 시작할 수 있는 정지모드

오토 스케일링

AWS Auto Scailing

목표

정확한 수의 EC2 인스턴스를 보유하도록 보장
- 그룹의 최소 인스턴스 숫자 및 최대 인스턴스 숫자
	- 최소 숫자 이하로 내려가지 않도록 인스턴스 숫자를 유지 (인스턴스 추가)
    - 최대 숫자 이상 늘어나지 않도록 인스턴스 숫자 유지 (인스턴스 삭제)
- 다양한 스케일링 정책 적용 가능
	- 예) CPU의 부하에 따라 인스턴스 크기를 늘리기
가용영역에 인스턴스가 골고루 분산될 수 있도록 인스턴스를 분배

오토스케일링의 구성

시작 구성/시작 템플릿 : 무엇을 실행시킬 것인가?

  • EC2 타입, 사이즈
  • AMI
  • 보안그룹, Key, IAM
  • 유저 데이터

모니터링 : 언제 실행시킬 것인가? + 상태 확인

  • 예) CPU 점유율이 일정 %을 넘어섰을 때 추가로 실행 or
    2개 이상이 필요한 스택에서 EC2 하나가 죽었을 때
  • CloudWatch, ELB와 연계

설정 : 얼마나 어떻게 실행시킬 것인가?

  • 최대/최소/원하는 인스턴스 숫자
  • ELB와 연동 등

로드밸런싱

- 다수의 서비스에 트래픽을 분산 시켜주는 서비스
- Health Check : 직접 트래픽을 발생시켜 Instance가 살아있는지 체크
- Auto Scailing과 연동 가능
- 여러 가용영역에 분산 가능
- 지속적으로 IP 주소가 바뀌며 IP 고정 불가능 : 항상 도메인 기반으로 사용

ELB의 종류

Application Load Balancer

- 똑똑한 녀석
- 트래픽을 모니터링 하여 라우팅 가능
- 예) image.sample.com -> 이미지 서버로, web.sample.com -> 웹서버로 트래픽 분산

Network Load Balancer

- 빠른 녀석
- TCP 기반 빠른 트래픽 분산
- EIP 할당 가능

Classic Load Balancer

- 옛날 녀석
- 예전에 사용되던 타입으로 잘 사용되지 않음

Gateway Load Balancer

- 먼저 트래픽 체크하는 녀석
- 가상 어플라이언스 배포/확장 관리를 위한 서비스

대상그룹(Target Group)

LB가 라우팅 할 대상의 집합

구성

-(3+1가지 종류)
    - Instance
    - IP(private)
    - Lambda
    - ALB
    
-프로토콜(HTTP, HTTPS, gRPC 등)

- 기타 설정
	- 트래픽 분산 알고리즘, 고정 세션

실습내용

alb의 타겟 그룹으로 ec2-1, ec2-1 지정
ec2-1가 죽으면 auto scailing group이 ec2-1을 살려준다.
하지만 ec2-1안의 서비스가 제대로 동작하지 않으면 (502 Bad gateway)
alb의 타겟그룹의 헬스체크는 fail이 뜨지만 자동으로 복구되진 않는다.

이 때 auto scailing group에서 상태체크에서 elb도 체크한다.
그러면 elb의 헬스체크가 죽어있으면 다시 띄워주므로
ec2-1이 죽거나, 내부 서비스가 제대로 돌아가지 않을 때 정상 복구를 시켜줄 수 있다.

고가용성 : 자동으로 장애 복구

EFS

EFS

- NFS 기반 공유 스토리지 서비스(NFSv4)
	- 따로 용량을 지정할 필요 없이 사용한 만큼 용량이 증가(EBS는 미리 크기를 지정해야 함)
- 페타바이트 단위까지 확장 가능
- 몇천개의 동시 접속 유지 가능
- 데이터는 여러 AZ에 나누어 분산 저장
- 쓰기 후 읽기 일관성
- Private Service : AWS에서 접속 불가능
	- VPN, Direct Connect
- 각 가용영역에 Mount Target을 두고 각각의 가용영역에서 해당 Mount Target으로 접근
- Linux Only

Amazon EFS 퍼포먼스 모드

General Purpose

  • 가장 보편적인 모드
  • 거의 대부분의 경우 사용 권장

MAX IO

  • 매우 높은 IOPS가 필요한 경우
  • 빅데이터, 미디어 처리 등

Amazon EFS Throughput 모드

Bursting Troughput

  • 낮은 Throughput 일 때 크레딧을 모아서 높은 Throughput일 때 사용
  • EC2 T타입과 비슷한 개념

Provisioned Throughput

  • 미리 지정한 만큼의 Throughput을 미리 확보해두고 사용

Amazon EFS 스토리지 클래스

EFS Standard

  • 3개 이상의 가용영역에 보관

EFS Standard-IA

  • 3개 이상의 가용영역에 보관
  • 조금 저렴한 비용 대신 데이터를 가져올 때 비용 발생

EFS One Zone

  • 하나의 가용영역에 보관
  • 저장된 가용영역의 상황에 영향을 받을 수 있음

EFS One Zone

  • 저장된 가용영역의 상황에 영향을 받을 수 있음
  • 데이터를 가져올 때 비용 발생(가장 저렴)

Amazon FSx

FSx for Windows File Server

  • EFS의 윈도우즈 버전
  • SMB 프로토콜을 활용
  • Microsoft AD와 통합 등의 관리 기능 사용 가능
  • Linux, MacOS 등의 다른 OS에서도 활용 가능

FSx for Lustre

  • 리눅스를 위한 고성능 병렬 스토리지 시스템
  • 온프레미스에서도 접근 가능

사설 IP(Private IP)

사설 IP

  • 한정된 IP 주소를 최대한 활용하기 위해 IP 주소를 분할하고자 만든 개념
    - IPv4 기준으로 최대 IP 갯수는 43억개
  • 사설망
    - 사설망 내부에는 외부 인터넷 망으로 통신이 불가능한 사설 IP로 구성
    • 외부로 통신할 때는 통신 가능한 공인 IP로 나누어 사용
    • 보통 하나의 망에는 사설 IP를 부여받은 기기들과 NAT 기능을 갖춘 Gateway로 구성

NAT

사설 IP가 공용 IP로 통신할 수 있도록 주소를 변환해주는 방법

Dynamic NAT

  • 1개의 사설 IP를 가용 가능한 공인 IP로 연결
  • 공인 IP 그룹(NAT Pool)에서 현재 사용 가능한 IP를 가져와서 연결

Static NAT

  • 하나의 사설 IP를 고정된 하나의 공인 IP로 연결
  • AWS Internet Gateway가 사용하는 방식

PAT(Port Address Translation)

  • 많은 사설 IP를 하나의 공인 IP로 연결

CIDR(Classless Inter Domain Routing)

CIDR

  • IP는 주소의 영역ㅇㄹ 여러 네트워크 영역으로 나누기 위해 IP를 묶는 방식
  • 여러개의 사설망을 구축하기 위해 망을 나누는 방법

CIDR Block

  • IP 주소의 집합

CIDR Notation

  • CIDR Block을 표시하기 위한 방법
  • 네트워크 주소와 호스트 주소로 구성

192, 168, 2는 네트워크 주소(고정)
0은 호스트 주소(변동)

네트워크 비트 : 24
호스트 주소 : 32 - 24 = 8
즉 2^8 = 256개의 IP 주소 보유
192.168.2.0 ~ 192.168.2.255 까지 256개 주소를 의미

VPC

VPC의 구성요소

  • 서브넷
  • 인터넷 게이트웨이
  • NACL/보안그룹
  • 라우트 테이블
  • NAT Instance / NAT Gateway
  • Bastion Host
  • VPC Endpoint

서브넷

  • 네트워크 안의 네트워크
  • 큰 네트워크를 잘게 쪼갠 단이
  • 일정 IP 주소의 범위를 보유

퍼블릭 서브넷

  • 외부에서 인터넷을 통해 연결할 수 있는 서브넷
  • 인터넷 게이트웨이를 통해 외부의 인터넷과 연결되어 있음
  • 안에 위치한 인스턴스에 퍼블릭 IP 부여 가능
  • 웹서버, 어플리케이션 서버 등 유저에게 노출되이야 하는 인프라

프라이빗 서브넷

  • 외부에서 인터넷을 통해 연결할 수 없는 서브넷
  • 외부 인터넷으로 경로가 없음
  • 퍼블릭 IP 부여 불가능
  • 데이터베이스, 로직 서버 등 외부에 노출 될 필요가 없는 인프라

인터넷 게이트웨이

  • VPC가 외부의 인터넷과 통신할 수 있도록 경로를 만들어주는 리소스
  • 기본적으로 확장성과 고가용성이 확보되어 있음
  • IPv4, IPv6 지원
    - IPv4의 경우 NAT 역할
  • Route Table에서 경로 설정 후에 접근 가능
  • 무료

보안그룹

  • NACL(Network Access Control List)와 함께 방화벽의 역할을 하는 서비스
  • Port 허용
    - 기본적으로 모든 포트는 비활성화
    - 선택적으로 트래픽이 지나갈 수 있는 Port와 Source를 설정 가능
    • Deny는 불가능 -> NACL로 가능함
  • 인스턴스 단위
    - 하나의 인스턴스에 하나 이상의 sg 설정 가능
    • NACL의 경우 서브넷 단위
  • Stateful

네트워크 ACL

  • 보안그룹처럼 방화벽 역할을 담당
  • 서브넷 단위
  • 포트 및 아이피를 직접 Deny
  • 포트의 허용과 거부 가능
  • 보안 그룹과 다르게 들어오고 나가는 것을 모두 체크
    (보안그룹은 들어오는 것만 체크)

NAT Gateway / NAT Instance

  • private 인스턴스가 외부의 인터넷과 통신하기 위한 통로
  • NAT 인스턴스는 단일 EC2 인스턴스
  • NAT Gateway는 AWS에서 제공하는 서비스
  • 모두 서브넷 단위(퍼블릭 서브넷에 있어야 함)

Bastion Host

  • Private 인스턴스에 접근하기 위한 EC2 인스턴스
  • 퍼블릭 서브넷에 존재해야 함

Amazon S3

Amazon S3

객체 스토리지 서비스
- 파일 보관만 가능 <- > EBS, EFS
- 애플리케이션 설치 불가능

글로벌 서비스 단, 데이터는 리전에 저장

무제한 용량
- 하나의 객체는 0byte ~ 5TB

버킷이란?

  • s3의 저장공간을 구분하는 단위
  • 디렉토리/폴더와 같은 개념
  • 버킷이름은 전세계에서 고유 값 : 리전에 관계 없이 중복된 이름이 존재할 수 없음

S3 객체의 구성

  • Ownser
  • Key
  • Value
  • Version ID
  • Metadata
  • ACL
  • Torrents

S3의 내구성

  • 최소 3개의 가용영역에 데이터를 분산 저장
  • 99.99999999999% 내구성
  • 99.9% SLA 가용성
    내구성 : 잃어버리지 않는 것
    가용성 : 원할 때 쓸 수 있는 것

S3 보안 설정

  • S3 모든 버킷은 새로 생성시 기본적으로 Private
  • 보안 설정은 객체 단위와 버킷 단위로 구성
    Bucket Policy : 버킷 단위
    ACL : 객체 단위
  • MFA를 활용해 객체 삭제 방지 가능
  • 액세스 로그 생성 및 전송 가능

S3 정적 호스팅

Static Contents

  • 서버에 저장된 파일이 모든 사용자에게 동일하게 전달되는 컨텐츠
  • 매번 서버에 요청할 필요 없이 캐싱 가능
  • html/js 등으로 구성
  • 예) 이미지, 글, 뉴스 등

Dynamic Contents

  • 시간, 사용자, 입력 등에 따라 내용이 변경되는 컨텐츠
  • 매번 서버에 요청하여 내용을 구성하고 전달받아야 함
  • php, jsp, asp.net 등으로 서버 처리
  • 예) 로그인이 필요한 내용, 게시판, 댓글 등

Amazon S3 Static Hosting

  • S3을 사용해서 정적 웹 컨텐트를 호스팅하는 기능
  • 별도의 서버 없이 웹사이트 호스팅 가능
  • 고가용성/장애 내구성을 확보
  • 사용사례) 대규모 접속이 예상되는 사전 예약 페이지, 홍보 페이지, 회사 웹사이트 등
  • 실전에서는 CloudFront와 연동하여 주로 사용

CloudFront

  • 일반적으로 HTTPS 프로토콜 구현을 위해서는 CloudFront 와 연동 필요
    ACM을 통한 SSL 키 관리가 가장 편함
    보통 Public Hosting의 활성화 대신 그대로 Private 모드로 두고 OAI/OAC 등을 활용해서 보안 강화

아키텍처

profile
새로 학습하는 내용을 기록합니다. \n 예전 주소 : https://blog.naver.com/gmlwl0720

0개의 댓글