💻STUDY/AWS SAA STUDY

[SAA] 1. 시작, IAM, EC2

coldNoodlePigeon 2024. 11. 5.

udemy 강의 기준 sec01-07까지의 내용 정리
전체 내용을 정리하기보단, 몰랐었던 내용과 정리하고 싶은 부분들을 중점으로 정리합니다
공부하면서 들었던 짧은 생각과 고민도 정리합니다
틀린 내용이 있다면 댓글로 알려주세요 감사합니다

section 01-03.

리전(Region)을 선택하는 기준?

1. 법률 준수: 해당 국가의 정부 정책(데이터 정책 등)을 준수해야함

2. 지연시간: 가까운 리전을 선택할수록 지연시간을 줄일 수 있음

3. 리전 내에 사용하고자 하는 서비스들이 있는지?: 모든 리전에서 모든 서비스들을 사용할 수 있는 것이 아니기 때문

4. 요금: 리전 마다 요금이 달라짐!

bedrock이었나.. 실습할때 몇몇개가 우리나라에서 지원이 되지 않아 다른 리전을 선택해서 핸즈온 실습을 진행했던 기억이 났다.

가용영역(AZ) = 1 data center?

아니다! 공부하면서 조금 헷갈렸는데, 각 AZ에는 하나 이상의 데이터 센터들이 존재할 수 있다.

그리고 각 AZ들은 높은 대역폭에 ultra-low latency 네트워킹으로 서로 소통할 수 있다.

글로벌 서비스 vs. 리전 한정 서비스

글로벌 서비스: IAM, Route 53, CloudFront, WAF ..
리전 한정 서비스: EC2, Lambda, .. etc

IAM이 글로벌 서비스라는 걸 자꾸 헷갈리게 되는 것 같아 기억해둬야겠다. (콘솔 접속할때 global로 뜬다! 리전 설정할 필요가 없다!)

section04. IAM

IAM은 저번주 ACC(AWS Cloud Clubs) 학교 세미나 발표에서 들었던 내용이기도 하다. 반갑기도 했으나, 생각보다 더 깊게 들어가면 들어갈수록 IAM이 어려운 것이라는 걸 알게되었다..

IAM 정책 구성 요소

version: 2012-10-17로 고정되어 있음. (정책 언어 버전 의미함)
id: 정책을 구분하는 id (선택사항)
statements: 1개 이상으로 구성되어 있음 (필수)
- sid: statement id (선택사항)
- effect: allow or deny로 접근 권한 설정
- principal: 이 정책이 적용될 계정/유저/role(역할)을 지정
- action: 정책이 허용/비허용 해주는 동작들을 명시
- resource: 어떤 리소스들에 위 action들이 적용될지 명시
- condition: 언제 정책이 적용되는지 시기나 조건을 설정(선택사항)

정책들을 통해 IAM 계정들의 권한을 설정해줄 수 있다. 사실 개발했을때 root 계정으로 모든걸 해결했었는데, 'root 계정으로만 진행하는 것은 좋지 않다!'는 것을 강사분께서 거듭 강조하셨다. 다음에 개발할때는 개발용 IAM 계정을 생성해서 진행해봐야겠다..

AWS 접근 방법들

AWS 접근 방법은 콘솔 뿐만 아니라, 다른 방법들도 존재한다. AWS CLI는 있다는 것만 알고, 사용을 안해봤었는데 다음에 기회가 된다면 한번 사용해보고 싶다.

AWS Management Console: password+MFA 로 접근
AWS Command Line Interface (CLI): access key로 접근
AWS Software Developer Kit(SDK): access key로 접근

IAM Role? IAM Policy? 차이점은?

공부하다보니 IAM 정책(policy)과 역할(role)이 계속 헷갈리는 느낌이다. role은 policy들을 포함하는 컨테이너 느낌의 개념이라고 생각하자. 또한 사용자가 아닌, AWS object들이 AWS 서비스들을 사용하기 위해 IAM Role을 지정해줌으로써 서비스에 접근할 수 있도록 해줄 수 있다. (예를 들어, ec2가 aws 서비스에 있는 어떤 읽기 작업을 수행할때, IAM Role을 사용하여 접근할 수 있도록 권한 설정이 가능하다)

IAM Security Tools- 보고서, 액세스 관리자

IAM에는 보안을 위한 다양한 도구들이 존재한다. 사실 나는 이것들을 처음 보는 것 같다.. 이번 기회에 알게되어서 다행이다.

IAM Credentials Report(account level): 비밀번호를 변경하지 않거나, 비밀번호나 계정을 사용하지 않은 사용자들을 확인할때 유용하다
IAM Access Advisor(user-level)(IAM 액세스 관리자): 사용자가 올바른 권한을 가지고 있는지 여부를 확인 가능, 세부적으로 사용자의 접근권한을 관리할때 유용하다

section05. EC2

EC2는 웹 프로젝트를 진행하면서 몇 번 사용해봤었는데, 이번에 공부하면서 좀 더 알게 된 것들도 많은 것 같다.

EC2 User Data

EC2 User Data 스크립트 작성을 통해 bootstrap(머신이 작동할때 명령을 시작하는 것)이 가능하다. 인스턴스가 시작할때 처음 한번만 작동된다.

소프트웨어를 설치하거나, 업데이트 등 부팅작업을 자동화할 목적으로 사용한다.
참고로 sudo 명령어로 실행하기 때문에, User Data 스크립트는 root user(EC2)로 실행된다!

사실 그동안 해봤던 웹 프로젝트들은 정말 간단한 웹이어서, 자동 스크립트를 작성할 생각을 미처 못했었다. 하지만 매번 인스턴스를 새로 시작해서 스크립트 작성하고, 부팅하는 것보다 스크립트를 미리 작성해두는 것이 훨씬 편리할 것 같다. 다음에 기회가 된다면 사용해보고 싶다.

EC2 Instance 유형

사용 목적에 따라 다양한 유형의 인스턴스 타입을 선택하여 사용할 수 있다.

먼저 인스턴스 타입을 읽는 방법을 살펴보자.

예를 들어, m5.2xlarge라는 인스턴스 유형이 있다면,

m은 인스턴스 클래스
5는 세대
2xlarge는 사이즈를 의미한다. 사이즈가 클수록 CPU, 메모리의 성능이 좋다

범용 인스턴스(General Purpose)
- 다양한 워크로드에 적합
- 컴퓨팅, 네트워킹, 메모리의 균형이 잘 맞음
- 대표적인 예로 t2.micro 가 있음
컴퓨팅 최적화 인스턴스(Compute Optimized): 보통 c로 시작하는 클래스
- 컴퓨팅 집약적인 워크로드에 적합함. 고성능 프로세싱을 제공함
- 사용 예:
  - 배치 프로세싱(batch)
  - 미디어 transcoding
  - HPC
  - 머신러닝
  - 게임 서버
메모리 최적화 인스턴스(Memory Optimized): 보통 R로 시작하는 클래스
- 메모리에서 대규모 데이터를 처리할때 빠른 성능을 제공함
- 사용 예:
  - 고성능의 관계형/비관계형 데이터베이스
  - 분산 웹 스케일 캐시 스토어
  - 대규모 비정형 데이터 실시간 처리
  - BI(Business Intelligence)를 위해 최적화된 인메모리 데이터베이스
용량 최적화 인스턴스(Storage Optimized)
- 스토리지 집약적인 워크로드에 적합함. 로컬 스토리에 저장된 대규모 데이터에서 연속적인 read/write 접근이 많이 발생하는 경우 적합함
- 사용 예:
  - OLTP 시스템
  - 관계형/NoSQL 데이터베이스
  - 인메모리 데이터베이스를 위한 캐시 (Redis)
  - 데이터 웨어하우스 애플리케이션
  - 분산 파일 시스템

정리해보니 처음 들어보는 용어들도 몇 있어서 완전히 이해하는게 어렵게 느껴졌다.

security group

보안 그룹은 EC2를 사용해봤을때 만져봤었다. 보안 그룹에 대해서는 러프하게만 알고 있었고, 이번 스터디와 저번에 ACC에서 주최했던 Infrastructure camp에서 몰랐던 내용들과 헷갈렸던 내용들을 바로 잡을 수 있었다.

보안그룹은 사용해봤듯이, allow 규칙들만 포함하고 있다!
EC2 인스턴스의 방화벽이라고 생각하면 된다 - 알고 있었던 내용이다
보안 그룹은 여러개의 인스턴스들에 붙일 수 있다 - 인스턴스를 새로 만들때, 미리 만들어둔 보안그룹 규칙을 적용할 수 있었던 것을 떠올려보자
보안 그룹은 리전+VPC 조합에 제한된다! - 이건 몰랐던 내용이다.. 다른 리전으로 바꿀 필요가 있을때 새로운 보안 그룹을 설정해주자
SSH 접속을 위해 따로 분리된 보안 그룹을 만들어두는 것이 좋다 - 귀찮아서 인스턴스랑 한번에 설정해준 적이 있었는데, 기억해둬야겠다
만약 접근이 time out 되었다는 에러가 뜨면? 보안그룹이 원인!
만약 접근이 refused 되었다는 에러가 뜨면? 애플리케이션 에러 or 애플리케이션이 정상적으로 시작되지 않았다는 의미
기본값으로 인바운드는 차단되어 있고, 아웃바운드는 열려있다.

EC2 인스턴스 구매 옵션

이전에 웹 개발 프로젝트를 진행했었을 때, 비용 관련하여 이것저것 찾아봤었던 기억이 난다. 그때 겉핥기로 쓱 보기만 했었는데 여기서 다시 보게될 줄이야.. 아무튼, 다양한 옵션을 설정하여 EC2 인스턴스를 비용 효율적으로 사용할 수 있는 방법들에 대해 알아보자.

온디맨드 인스턴스(On-Demand Instances): 단기간 사용, 중단없는 워크로드 필요, 애플리케이션이 어떻게 작동할지 예측할 수 없을 때 추천
- 비용이 가장 많이 든다
- 장기적인 약정같은 것이 필요 없다
예약 인스턴스(Reserved): 특정 인스턴스 속성들을 예약해두는 인스턴스
- 1년 혹은 3년으로 예약 가능 - 기간이 길수록 더 많이 할인
- 선결제x, 부분 선결제, 모두 선결제 옵션이 있음 - 선결제를 할 수록 더 많이 할인
- 리전 단위 or 가용영역(AZ) 단위로 예약이 가능
  - 이 부분이 이해가 어려웠는데, 리전 단위로 예약한다는 것은 예를 들어, 특정 리전에서 t2.large를 예약했다면 리전 내 가용영역(AZ) 2곳에서 t2.medium을 각각 1개씩 사용할 수 있다는 의미이다
- 전환형 예약 인스턴스로 할 시, 인스턴스 클래스 타입 os 테넌시 등을 변경할 수 있다
- 사용량이 일정한 애플리케이션(ex. 데이터베이스)에 적합
절약 플랜(Saving Plan): 약정이 있고, 인스턴스 패밀리와 리전 변경이 불가능하다. 마찬가지로 오래 사용할수록 할인율이 큼
- 약정이 존재한다 (시간당 10달러, 1년 혹은 3년으로 약정)
- 만약 절약 플랜에서 설정한 사용량보다 많이 쓰면 그 부분에 대해서는 온디맨드 가격으로 책정한다
- !!설정한 인스턴스 패밀리와 리전은 변경 불가능하다!!
- 그러나 인스턴스 사이즈, OS, 테넌시 등은 자유롭게 변경 가능하다
스팟 인스턴스(Spot Instance): 가장 비용 효율적인 인스턴스. 90%까지 할인
- 가장 큰 단점은 설정한 최대 금액을 넘어가게 되면 인스턴스가 자동으로 사라지게 된다
- 따라서 데이터베이스나 중요한 작업이 필요한 것에는 적합하지 않다 -> 작업이 실패하거나 날아가도, 장애복원력이 뛰어나 괜찮은 작업들(ex. 이미지 처리, 데이터 분석, 분산 작업, 배치 작업 등)에는 괜찮은 옵션
- 최대 가격을 설정하고, 그것보다 넘어가게 될때 2분동안의 유예 시간을 준다. 그 시간 안에 인스턴스를 중지 혹은 종료시켜야한다
  - 그게 아니라면, 특정 시간(1-6시간)동안 중단없이 인스턴스가 작동되도록 보장해주는 "Spot Block"도 있다. (희귀한 경우지만 인스턴스가 다시 회수되는 경우도 있음)
- Spot Instance 중단 방법
  - spot instance request를 먼저 삭제해야한다! 그렇지 않으면, 삭제되지 않은 request가 다시 동작하여 인스턴스를 다시 시작할 수 있기 때문. (영구 요청 옵션에 해당. 일회성 요청 옵션의 경우 처음 요청하고 나서 삭제됨)
    - spot instance request는 열려있을때, 활성화되어있을때, 비활성화되어있을때 삭제가 가능하다
전용 호스트(Dedicated Hosts): 실제 물리적 서버, 가장 비싼 옵션
- 실제 물리적 서버를 특정 EC2 용량과 함께 전용 호스트로 사용 가능케 한다
- 규정이나 법률 준수가 반드시 필요한 회사, 복잡한 소프트웨어 라이센스 준수 등이 필요한 경우 사용하면 좋다
- 온디맨드, 예약 옵션이 존재
  - 온디맨드: 활성화되어 있는 호스트에 초당 비용으로 계산
  - 예약: 1년 or 3년으로 예약, 선결제x/부분 선결제/모두 선결제 옵션이 존재함
전용 인스턴스(Dedicated Instance)
- 전용 호스트와 헷갈리기 쉬우나, 전용 인스턴스는 "내" 하드웨어에 전용 인스턴스를 실행하는 것이다.
- 같은 계정일 경우, 다른 인스턴스들이 나의 하드웨어를 공유할 수 있다
- 단점은 인스턴스 배치에 어떠한 통제권을 가지 못하게 된다
용량 예약(Capacity Reservation): 특정 온디맨드 인스턴스 "용량"을 예약
- 특정 AZ에서, 특정 기간동안 사용할 온디맨드 인스턴스의 용량을 예약 가능하다
- 하지만, 사용하고 있지 않을때도 온디맨드 가격으로 청구된다
- 약정이 필요 없고, 할인도 없다
- 지역별 예약 인스턴스 혹은 절약 플랜과 결합함으로써 할인을 받을 수 있다
- 특정 AZ 에서 단기간, 중단없는 워크로드를 사용할때 적합

예약 인스턴스와 절약 플랜과 용량 예약, 전용 호스트와 전용 인스턴스가 자주 헷갈리는 것 같아서 자주 되새김질 해주려고 한다. 이렇게나 많은 옵션들이 있었다니.. 프리티어만 사용해봐서 몰랐지, 나중에 더 많은 서비스를 개발하다보면 온디맨드가 아닌 다른 옵션들도 사용하게 되지 않을까?

Spot Fleet

처음보는 개념인데, 지금도 서비스하고 있는 건지는 잘 모르겠다. 강의 중에 강사님께서 스팟 요청이 2021년부터 지원 중지가 되었다라고 말씀하셨는데, 스팟 인스턴스와 스팟 플릿도 마찬가지로 지원 중지인건지는 좀 더 알아봐야겠다. (구글링해보니 아직 관련 AWS 문서들이 남아있고, 별말이 없는것을 보면 아직 서비스중인가?)

스팟 플릿은 스팟 인스턴스들의 세트와 온디맨드 인스턴스들(선택사항)을 사용자가 지정한 설정에 따라(가격 제한, 목표 용량) 자동으로 관리해주는 서비스다.
사용자가 지정해준 풀(pool) 종류(인스턴스 타입, OS, AZ 등),가격 제한, 목표 용량, 선택 전략 등에 따라 자동으로 항상 비용이 낮은 스팟 인스턴스 요청을 할 수 있도록 도와준다. 최대 용량, 비용을 넘게 되면 자동으로 인스턴스를 중지시킨다.

선택 전략은 4가지 정도가 있으며, priceCapacityOptimized가 가장 권장되고 있는 전략이다

LowestPrice: 가장 낮은 가격의 풀을 고르게 된다
- 가장 비용 최적이고, 단기 워크로드에 적합하다
diversifed: 풀들이 가장 많이 분산되도록 한다
- 이해가 잘 안되어서 찾아봤는데, 만약 6개의 인스턴스가 필요하고 풀이 3개가 있을때 2개 2개 2개로 인스턴스들을 분산시키도록 한다
- 이용가능성이 좋고, 장기적인 워크로드에 적합하다
capcitiyOptimized: 이용가능한 용량이 가장 많은 풀을 고르게 한다
priceCapacityOptimized(권장): 이용 가능한 용량이 가장 많은 풀들 중, 가장 가격이 낮은 풀을 고르게 한다
- 대부분의 워크로드에서 가장 권장되는 옵션이다

section06. EC2 심화 - Network, Placement Group

탄력적 IP?

그동안 인스턴스를 중지 후 시작할때마다 IP가 변경되는 것이 싫어서 탄력적 IP를 항상 사용해왔었는데, 탄력적 IP의 사용이 안좋은 구조적 결정이라는 것을 알게 되었다. 대신에 랜덤한 퍼블릭 IP 에 DNS를 붙이거나 로드밸런서를 사용하는 것이 좋다고 한다.

EC2 배치 그룹 전략

이것도 공부하면서 처음 알게된 내용이다. EC2 인스턴스들을 어떻게 배치할 것인지 3개 전략 중 하나를 선택하여 설정할 수 있다.

전략에는 cluter, spread, partition 이 있다.

Cluster
- 하나의 AZ 안, 하나의 하드웨어에 여러개의 EC2 인스턴스들이 클러스터로 위치함
- 지연시간이 매우 짧고, 처리량이 많은 네트워크가 필요한 애플리케이션에 적합함 (ex. 빠르게 수행해야하는 빅데이터 작업)
- 장점: 매우 빠른 네트워크
- 단점: AZ 하나가 문제가 생기면, 그 안에 있는 모든 EC2 인스턴스들도 fail하게 됨
Spread(분산 배치 그룹)
- 여러 가용 영역(AZ)에 걸쳐 있을 수 있음
- 인스턴스들이 각각 모두 다른 하드웨어에 위치하게 됨
- AZ당 최대 7개의 인스턴스들 배치 가능함에 유의!
- 실패 위험을 최소화할 수 있음
- 높은 가용성이 필요한 애플리케이션, 서로의 실패 위험성을 격리시켜야하는 중요한 애플리케이션에 경우에 적합
Partition(분할 배치 그룹)
- 마찬가지로 동일 리전 내 여러 가용 영역(AZ)에 걸쳐 있을 수 있음
- 수백개의 인스턴스들 배치 가능, 그러나 AZ당 최대 7개의 파티션들이 가능하다
- 파티션 하나를 하나의 하드웨어 랙(rack)이라고 생각하면 좋다
- 파티션 내에는 여러개의 인스턴스들이 위치할 수 있음
- 파티션에 있는 인스턴스들은 다른 파티션에 위치한 인스턴스들과 위험을 공유하지 않음
  - 만약 파티션 하나가 fail하면 그 안에 있는 여러 인스턴스들은 fail하나, 다른 파티션에 있는 인스턴스들은 안전하다
- EC2 인스턴스들은 어떤 파티션에 위치했는지를 파악하기 위한 메타데이터 접근이 가능함
- HDFS, HBase, Cassandra, Kafka와 같이 파티션을 인식하는 big data application들에 적합함

spread 배치 그룹과 partition 배치 그룹이 헷갈린다. 둘 다 여러 가용 영역에 걸쳐 있을 수 있으나 파티션 배치 그룹의 경우 파티션 하나에 여러개의 인스턴스가 들어갈 수 있고, AZ당 최대 7개의 파티션이 가능한 반면에, spread의 경우 모든 인스턴스들이 각각 모두 다른 하드웨어 랙에 위치하도록 하고 AZ 당 최대 7개의 인스턴스들이 가능하다는 차이를 기억해두면 좋을 것 같다.

ENI(Elastic Network Interface) 탄력적 네트워크 인터페이스

이건 또 뭐지? 하면서 새롭게 알게 된 내용이다. 이래도 되나 싶지만 이제라도 알았으니 다행이다. ENI는 VPC 내 가상 네트워크 카드를 나타내는 단위라고 보면 될 것 같다.

ENI는 다음과 같은 것들을 설정해줄 수 있다.

기본 private IPv4, 1개 이상의 보조 IPv4
사설 IPv4 당 탄력적 IP 설정 가능(선택사항)
1개의 퍼블릭 IPv4
1개 이상의 보안 그룹
MAC 주소

여기서 기억할 점은, 장애 조치를 위해 ENI를 다른 인스턴스로 옮겨 붙일 수 있다는 점이다. 이러면 장애가 발생했을때 IP주소를 바꿀 필요 없이 ENI를 쉽게 옮겨서 백업 인스턴스에서 돌릴 수 있는 것. 또한, ENI는 특정 AZ에 바인딩되어 있다는 점을 기억해야한다.

EC2 Hibernate(절전 모드)

절전 모드는 in memory(RAM)의 상태를 보존시킬 수 있는 기능이다. 보통 인스턴스를 부팅하게 되면 RAM에 부팅을 올리고 하는 시간이 소요되게 되는데, 절전 모드를 활용하면 이 시간을 줄임으로써 인스턴스 부팅 속도를 더 빠르게 할 수 있다. 즉, RAM 상태를 보존함으로써 OS가 중단되거나 재시작되지 않는 것이다.

절전 모드로 인스턴스를 중지하게 되면, RAM에 있던 내용들을 root EBS volume에 작성하게 된다. 절전 모드를 사용할때 유의할점들은 아래와 같다.

1. 루트 볼륨의 크기가 RAM의 내용들을 저장하기에 충분해야함

2. 루트 볼륨은 암호화되어야함

3. 루트 볼륨은 EBS여야만 함 (instance store는 안됨)

4. 온디맨드, 예약 인스턴스, 스팟 인스턴스에서만 가능함

5. RAM의 크기는 150기가보다 작아야함

6. bare metal instance(가상화 계층 없이 직접 하드웨어에 접근할 수 있는 것)은 지원하지 않음

7. 인스턴스는 60일 이상 절전모드 상태에 있을 수 없음

이러한 절전 모드는 오래 실행되어야하는 프로세싱, 빠른 재부팅 속도가 필요할때, RAM 상태 저장이 필요한 경우에 적합한 기능이다.

EC2에 절전 모드가 있다는 사실을 대강은 알고 있었는데, 한번도 활용을 해본 적은 없었다. 오래 실행해야하는 프로세싱 등이 필요할때 정말 유용한 기능으로 보인다.

section07. EC2 Storage

EBS Volume & EBS Snapshot

EC2를 사용해보면 거의 웬만하면 알게되는 EBS 볼륨이다.

EBS 볼륨은 하드웨어 드라이브가 아닌, "네트워크" 드라이브다. 따라서 네트워크를 통해 통신하기 때문에, 약간의 지연시간이 발생할 수 밖에 없다.

당연하게도, AZ에 종속이 된다. 모든 EBS가 항상 반드시 EC2 인스턴스에 연결되어있을 필요는 없고, EBS를 다른 인스턴스에 연결도 가능하다. 인스턴스가 종료되어도 EBS에 있는 데이터는 저장될수 있다. 그런데 내 기억으로는, 인스턴스가 종료되면 루트 볼륨이 삭제되었었는데 이는 디폴트로 인스턴스가 종료되면 EBS 루트 볼륨은 자동으로 삭제된다는 설정이 체크되어있기 때문이다. 마찬가지로 콘솔과 CLI를 통해 설정 변경이 가능하니 기억해두자! (디폴트로 루트 볼륨 이외에 다른 추가 연결된 EBS 볼륨들은 삭제되지 않는다. 이도 마찬가지로 설정 변경 가능하다.)

마찬가지로 저장소이기 때문에, 용량을 미리 결정하고 그에 따라 비용을 지불한다.

EBS 스냅샷은 특정 시점의 EBS 볼륨의 백업본을 말한다. 스냅샷을 만들때 반드시 인스턴스에서 볼륨을 분리할 필요는 없지만, 분리하는 것을 권장한다고 한다. 아마 안전성을 위해서가 아닐까? 이건 몰랐는데, 특정 AZ에 제한되는 것이 아니라, 스냅샷은 AZ와 리전에 상관없이 복사할 수 있다! 이건 몰랐던 사실이다. 당연히 저장소 관련이라 국한될줄 알았는데.. 기억해둬야겠다.

EBS 스냅샷에는 3가지 특성들이 존재한다. 원하는 옵션에 맞게 사용하면 된다.

EBS Snapshot Archive
- archive tier라고 하는 75%정도 더 저렴하게 스냅샷을 옮기는 것이 가능하다
- 그러나 복구 시간이 24-72시간 정도로 길다는 것이 단점
Recycle Bin for EBS Snapshots
- 휴지통 보관 기간은 1일에서 1년까지 설정이 가능하다
- 실수로 삭제한 스냅샷을 보관할 수 있도록 한다
Fast Snapshot Restore (FSR)
- 지연시간 없이 빠르게 복구해주지만, 이를 위해 강제로 스냅샷을 초기화한다
- 스냅샷의 크기가 엄청 크거나, 인스턴스를 빠르게 초기화하는 것이 필요할때 사용하는 것이 좋다
- 제일 비싼 옵션이다

나만의 AMI 만들기

AMI(Amazon Machine Image)를 AWS에서 제공하는 public AMI 말고도 나만의 커스텀 AMI를 사용할 수 있다는 사실! 알고계셨나요? 나만의 AMI를 만들어두면 나한테 필요한 설정, 소프트웨어, OS, 모니터링 등을 미리 추가함으로써 더 빠른 부팅과 설정 시간을 아낄 수 있다. AMI는 특정 리전에서 위해 만들어지나, 다른 리전으로 복사도 가능하다. 그러면 이제 커스텀 AMI를 어떻게 만드는지 순서를 알아보자.

EC2 인스턴스 생성 후 시작, 그리고 커스텀마이즈를 진행한다
EC2 인스턴스를 "중지"해야한다! 데이터 무결성 확보를 위해서이다.
AMI를 만든다. 이때 EBS 스냅샷도 만들어지게 된다
내가 만든 AMI들로부터 새로운 다른 인스턴스들을 시작할 수 있게 된다

2번 항목을 잊을 것 같아서 따로 정리해보았다.

EBS volume vs. EC2 Instance Store

EBS 볼륨은 네트워크 드라이브이기 때문에, 더 높은 성능이 필요할때는 제한이 있다. 그래서 더 높은 성능이 필요할땐 EC2 인스턴스 스토어라는 고성능 하드웨어 디스크를 사용한다.

유의할점이라면, 이는 인스턴스가 중지되면 삭제되기 때문에 임시 저장소로만 사용하는 것이 좋다. 보통 버퍼, 캐시, 스크래치 데이터, 임시 저장소로 사용하는 것이 좋다.

EBS 볼륨 유형

돈이 없는 학생인지라 프리티어 볼륨 타입만 사용했었는데, 이번에 공부하면서 다른 볼륨 유형들을 알 수 있게 되었다. EBS 볼륨 유형은 6개 정도 존재하며 처리량, 사이즈, IOPS(초당 입출력 작업수) 에 따라 달라진다.

너무 세세하게 다 외우기에는 비효율적일 것 같아서, 몇가지 기억해둘만한 것들을 기록해둘 것이다. (만약 덤프 문제를 풀다가 기억해야할 것들이 추가로 생긴다면, 덧붙이도록 하겠다)

gp2/gp3 (SSD): boot 볼륨 사용 가능
- gp3가 최신 세대 볼륨. 볼륨의 크기와 상관없이 독립적으로 IOPS를 늘릴 수 있음! (gp2는 볼륨의 크기와 IOPS가 연결되어 있으므로 독립적으로 하나만 늘리는게 불가능함)
io1/io2 Block Express (Provisiond IOPS(PIOPS) SSD) : boot 볼륨 사용 가능. 지속적인 IOPS 성능이 필요한 경우와 데이터베이스 워크로드에 적합.
- io1은 독립적으로 PIOPS를 늘릴 수 있으나, io2는 불가능
- EBS 다중 연결을 지원함 (단, 같은 AZ에 있는 인스턴스들 최대 16개까지만 연결이 가능하며 클러스터 인식이 가능한 파일 시스템을 사용해야만 한다)
  - 다중연결을 하면 하나의 EBS에 여러개의 인스턴스들이 연결되어 동시에 읽고 쓰기 작업을 수행할 수 있게 된다
  - 따라서 동시에 쓰기 작업들을 관리해야하거나 클러스터링된 리눅스 애플리케이션(ex. Teradata) 와 같이 높은 가용성이 필요한 애플리케이션 사용시 적합하다
st1 (HDD): boot 볼륨 사용 불가능. 처리량 최적화됨.
sc1 (HDD): boot 볼륨 사용 불가능. 가장 저렴함. 자주 접근하지 않는 경우에 적합.

EBS 암호화

EBS 암호화는 지연시간에 최소한의 영향을 준다. 즉 암호화한다고 해서 지연시간이 크게 느려지는 것은 아니니 걱정하지말자. 암호화되지 않은 EBS 볼륨에서 생성한 스냅샷은 암호화되지 않기 때문에, 스냅샷을 암호화하기 위해서는 copy 스냅샷을 통해 암호화 후, 암호화한 스냅샷으로부터 볼륨을 생성함으로써 암호화된 EBS 볼륨을 가질 수 있게 된다.

EFS(Elastic File System)

한번에 많은 EC2 인스턴스들에 마운트될 수 있는 관리형 NFS(Network File System)이며, EBS 다중연결은 특정 리전(AZ) 내에 있는 인스턴스들에만 다중 연결이 가능한 반면 EFS는 여러 AZ에 걸쳐 연결이 가능하다. scale 조정이 매우 자유로우며(자동적으로 조절됨) 처음에 사용량을 미리 결정하고 사용하지 않아도 된다. 따라서 높은 가용성을 지원해준다. 그러나 가격이 비싸고(gp2의 3배 가격), 사용량만큼 가격을 지불한다.

하지만 EFS는 POSIX라는 리눅스 기반 파일 시스템을 사용하고, 리눅스 기반의 AMI을 지원한다. 즉, 윈도우는 사용이 어렵다는 의미이다.

또한 NFSv4라는 프로토콜을 내부적으로 사용하며, 보안 그룹을 사용하여 NFS 통제 관리가 가능하다.

가격이 비싸지만, 다양한 스토리지 계층 설정을 통해 비용을 절감할 수 있다. 스토리지 클래스 설명 전에, 먼저 performance(성능) 모드와 throughput(처리량) 모드에 대해서 알아보자.

performance mode: 2가지 존재. EFS 생성 시 설정해줌.
- General Purpose(디폴트): 지연시간에 민감한 웹 서버, CMS 등의 서비스일때 사용한다
  - 후술한 throughput mode 모두가 선택할 수 있는 옵션
- Max I/O: 지연시간이 높으나, 처리량이 많고, 병렬을 지원해준다. 빅데이터, 미디어 처리에 종종 사용된다
  - bursting mode는 선택할 수 없는 옵션이다
throughput mode: 3가지 존재
- bursting mode: 스토리지 용량에 따라 추가적인 처리량을 좀 더 얻는 형태
- provisioned mode: 스토리지 용량에 상관없이 처리량을 설정할 수 있음
- elastic mode: 사용하는 워크로드에 따라 자동적으로 처리량 조절이 가능. 보통 예측할 수 없는 워크로드일때 사용한다.

그러면 이 매우 비싼 EFS를 어떤 클래스를 선택함으로써 절약할 수 있을까? storage tier들과 가용성+지속성 옵션들이 존재한다. 먼저 storage tier들은 다음과 같은 것들이 있다.

standard : 자주 액세스되는 파일들인 경우
EFS-IA: 데이터를 저장하는데는 비용이 적지만, 검색할때 비용이 많이 듬
archive : 자주 접근하지 않는 데이터들을 저장. 50%정도 저렴함
lifecycle policies: 라이프사이클 정책들을 정의함으로써, 며칠후에 어떤 파일들을 어떤 스토리지 계층으로 이동할지 결정이 가능하다

다음은 가용성과 지속성 옵션들이다.

standard: 다중 AZ에 걸칠 수 있다. production 워크로드에 적합하다.
one-zone: 단일 AZ에만 사용한다. 개발환경에서 적합하며, 백업은 디폴트로 활성화되어 있다. EFS-IA와 호환이 가능해 조합으로 사용할 수 있다.

이렇게 스토리지 계층에 따라 파일을 이동하고 저장함으로써 90%정도 비용 절약이 가능해진다. 값비싼 EFS를 사용한다면 꼭 기억해두자.

EBS vs. EFS vs. EC2 Instance Store

EBS

하드웨어가 아닌 네트워크 드라이브다. 네트워크를 통해 통신하므로 약간의 지연시간이 발생한다
다중연결을 지원하는 io1/io2 볼륨이 아닌 이상, 하나의 EBS는 하나의 인스턴스에만 연결할 수 있다
AZ에 종속되어 있다
만약, 다른 AZ로 EBS 볼륨을 옮기고 싶다면 스냅샷을 생성하여 이 스냅샷을 복구함으로써 다른 AZ로 옮길 수 있다
- EBS 백업은 I/O를 필요로 하기 때문에 만약 현재 트래픽이 몰린 상황일때는 백업을 자제해야한다
루트 EBS 볼륨은 인스턴스가 종료시, 디폴트로 같이 종료되고 삭제된다. 이는 설정에서 설정을 바꿀 수 있다.

EFS

네트워크 파일 시스템이다.
속도가 느리지만, 높은 가용성을 제공해준다
미리 용량을 결정하고 사용하지 않아도 되고 사용량에 따라 비용을 지불하기만 하면 된다
EBS와 달리, 여러 AZ에 걸쳐서 수백개의 인스턴스들과 연결이 가능하다. 하지만 비싸기 때문에 스토리지 계층 설정을 통해 비용을 절감하는 것이 좋다.
리눅스 기반의 인스턴스들만 사용이 가능하다.
웹사이트 파일들(wordpress)를 공유할 수 있다

EC2 Instance store

EC2 인스턴스에 물리적으로 연결되어 있는 스토어이다. 따라서 속도가 빠르고 고성능이다.
EC2가 중지되면 삭제되기 때문에 주로 버퍼, 캐시, 스크래치 데이터, 임시 저장소 등으로 사용한다
높은 IOPS가 필요한 경우, 인스턴스 스토어 사용이 좋다!

정리하다보니 글이 꽤 길어졌다. 그동안 클라우드 지식을 겉핥기 수준으로 맛보거나, ACC라는 클라우드 동아리에서 발표를 준비할때만 공부를 해왔었는데 이번에 자격증 공부를 하면서 클라우드 지식을 더욱 더 넓힐 수 있게된 것 같다. 몰랐던 사실들도 많았고, 내가 잘못 알고 있었던 내용들도 많아서 공부할때마다 놀라움(?)의 연속을 느끼는 중이다.

특히 IAM 루트 계정으로만 모든 개발 환경을 만들었던 나 자신에 대한 반성을 하며.. (다음부턴 그러지 말자!) 글을 마무리하도록 하겠다.

그럼 안녕!

'💻STUDY > AWS SAA STUDY' 카테고리의 다른 글

[SAA] 3. Route53 (0)	2024.12.05
[SAA] 2. 로드 밸런싱, RDS와 Aurora, ElastiCache (1)	2024.11.21
[SAA] 00. AWS SAA 스터디 시작 (2)	2024.11.03