AWS 기본 과정 -1 리뷰 및 추가 키 페어 추가 설명
키 페어를 카피해간 사람은 어떻게 알아내나? 키 페어 방어하는 방법? 키 페어 관리하는 방법을 알아야 하는데...
키페어를 가져간 사람을 모를 경우 어떻게 방어할 수 있는지?
복구하는 아이디어는 어제 알려주시긴 했다.
키 페어는 AWS에서 자동적으로 만들어짐
키 페어는 패스워드 없이 가져가서 사용하면 되는데
-> 키 페어를 생성할 때 패스워드를 생성하는 방법이 있다
키 페어 주인이 맞는지 확인하는 작업.
이 것은 AWS에서 제공하는 기능이 아니다. 직접 키 페어를 생성하는 것이 좋다.
리눅스/macOS에서는 Sshkeygen이라는 프로그램을 사용하여 키를 생성할 수 있음.
윈도우의 경우? puttygen 이용
타원 함수를 가지고 암호화 키를 생성하게 됨
저장은 public, private key 둘 다 해주자.
EC2 대시보드에 들어가면 키 페어 카테고리가 존재하는데, 이 곳에 저장되는 키 페어는 public key이다.
내가 만든 키 페어를 가져올 수 있다.
작업 > 키 페어 가져오기
Passphrase for key라는 문구가 뜨면서 내가 직접 설정한 값을 입력해줘야만 리눅스에 접속할 수 있다.
******************** puttygen으로 만든 키 페어를 mac, cli나 리눅스에서 접속하면 에러가 날 수도 있다... why?
key-pair
1024, 2048, 4096 비트의 rsa 키를 생성할 수 있음
+ 나중에 할 것: 웹 서버 설치해서 로드 밸런서 테스트를 할 것!!!
EC2가 프로비저닝되면 접속해서 웹 서버를 설치할 수 있음.
근데 윈도우를 사용하기 위해서는 다양한 기본 작업을 해줘야 함. -> 그런데 이걸 매번 인스턴스를 생성할 때마다 할 순 없음. -> AMI 만들어서 저장해둘 수 있음. -> 그런데 내가 무언가 빼먹은 작업이 있을 경우 어떻게 해야 하나?
AMI는 한 번 만들어지면 그대로 고정되어 버린다.
부트스트랩이라는 유저 데이터를 사용.
부트스트래핑: 외부 작용 없이 특정 스크립트가 스스로 실행되도록 기능. EC2가 처음 생성되고 부팅될 때 딱 한 번 실행된다.
** 그래서 auto scaling을 사용할 때 가장 애매하다... 처음 생성될 때만 시작하는 것이니까. 트래픽에 따라 생성되고 사라지는 특징 때문에 애매해짐.
메타 데이터란?
- ip 정보, 리전 정보 등이 전부 들어가 있다. 인스턴스에 접속할 때, 메타 데이터를 참조하여 자신의 ip 정보를 불러올 수 있다.
169.254.169.254에 접속하면 메타 데이터를 확인할 수 있다.
> curl http://169.254.169.254/latest/meta-data/
프로그래머들에게는 메타 데이터가 굉장히 중요함. 메타 데이터에서 정보를 다 확인할 수 있다.
-> 해킹당하면 전부 확인할 수 있다.... 보안상 문제가 있음!!!!! 아무나 이 ip에 접속하여 정보 열어봄. 그래서
현재 버전 2가 나왔음. IMDSv2
-> 현재는 이 메타 데이터 ip에 접근하지 못하게 막아두는 기능이 생김. 세션 방식으로 변경
접근하기 위해서는 어쩐다? 토큰을 이용해야 한다.
** 이게 매일 기능이 바뀌게 되니, 문서를 항상항상 잘 읽어야 한다!!!
시작 템플릿이란 것으로 생성. 2년 전에 새로 만들어진 기능.
시작 템플릿은 이미지를 동적으로 저장이 가능하다. = 수정이 가능한 이미지
리눅스 부팅이 다 끝난 후 수행하는 프로그램 : cloud init
리눅스 부팅이 다 끝난 후 수행하는 프로그램 : ec2 launch
yum install httpd
systemctl start httpd
인바운드 규칙 설정
user data 입력
#!/bin/bash
yum install -y httpd [or nginx]
systemctl start httpd
systemctl enable httpd
* zip 파일 다운 받아서 압축 해제하는 방법
wget http://~*.zip
unzip *.zip
웹 서버를 설치해줘~하는 powershell script
<powershell>
# Install Web
Import-module servermanager
install-windowsfeature web-server, web-server
install-windowsfeature web-mgmt-tools
</powershell>
유저 데이터에 입력한 내용을 부팅 시 실행하게 함 -> 동적(dynamic) 설정
현재 60초 단위로 과금이 되고 있다. 윈도우즈는 1시간 단위였는데 올해는 60초로 바뀌었다.
7월부터 RHEL은 가상 cpu 사용량을 시간당 -> vpc 사용량을 초당으로 바뀜
결론: 몇 몇 오픈 소스 리눅스는 초당으로 변경되었지만, 다른 리눅스들은 여전히 시간당 과금이다.
Tag
간단하게 말하면 꼬리표
수많은 EC2 인스턴스 중 필요한 것만을 찾아내기 위해 tag를 이용할 수 있다.
태그도 굉장히 중요함!!! 태그는 많고 상세할 수록 좋아
어떤 직급의 누구가 사용하는가?, 운영체제의 종류는? 프로젝트 이름은? 부서는 어디인지? 등
태그를 상세하고 많이 적어두면 검색을 할 때 필터링이 가능해진다.
특정 조건을 가진 인스턴스들을 모아 정책을 만들거나, 백업을 한 번에 하거나, 권한 설정 또한 가능한다.
리소스 앤 태그라는 기능?...도 있다....
전세계에 있는 모든 것들을 불러오거나 사용할 수 있다.
Amazon Linux 2 vs Amazon Linux 2022
아마존 리눅스 쓰는 이유는...? 무엇?
얘는 속도가 빠르다. 그리고 작고 가벼움. 경량화.
Linux 2는 옛날 버전!
이후 2022, 2023이 나왔음. centos 기반으로 만들어짐.
버전이 계속 바뀌긴 하지만 한 버전 당 5년간 유지해주기 때문에 지원이 끝나갈 때쯤 다른 버전으로 변경하라고 알려준다.
근데 만약 온프레미스에서 레드햇 리눅스를 사용하고, EC2 인스턴스는 아마존 리눅스를 사용하고 있다면 마이그레이션하기 힘들 것이다...
그래서 AWS는 리눅스를 온프레미스 환경에 설치할 수 있도록 아마존 리눅스 파일을 다운받을 수 있도록 업로드해두었다.
간편하게 다운로드 받아서 아마존 리눅스를 이용할 수도 있다.
EBS(Elastic Block Store)
EBS는 프로비저닝된 만큼 과금이 된다는 것을 알아야 한다!
웬만한 데이터는 C 드라이브에 저장하지 말라고 추천하는 이유는?
이 공간에는 OS만 저장했으면 좋겠다.
OS가 아닌 다른 데이터도 함께 저장하면 스냅샷(백업)을 뜰 때도 오래 걸리고 과금도 더 많이 된다.
그래서 보통은 D 드라이브에 데이터를 저장하는 것을 추천
D 드라이브는? 결국 디스크이다.
용량이 적은 만큼 속도는 줄어들게 된다.
AWS에서는 디스크에 제한을 다 걸어놨다.
서버가 느린 이유? 네트워크 문제인가? t2 타입을 써서 cpu가 문제인 건지? 그리고 디스크 관련해서인지
AWS는 정확한 속도는 제공돼있지 않다... 낮음, 낮음에서 중간과 같은 어정쩡하게 보여주고 있음.
시스템 성능이 어떤지 파악하기 위해서는 1. 네트워크, 2. cpu, 3. 디스크를 확인해야 한다.
스토리지같은 경우는 만질 일이 없어서 어려울 수 있음.
파일이 온전히 다 다운로드 되어야 열람할 수 있는 것은 파일 스토리지
하드디스크(EBS)는 블록단위로 저장하고 읽고 쓴다.
동영상을 저장할 때, 실제 하드디스크에는 512mb로 쪼개진 블록이 하나씩 저장되는 형태이다.
* 2010년 이후는 4k 블록으로 저장되고 있다.
블록 단위 특징: 포맷, OS 설치 가능.
파일 단위 특징: 포맷, OS 설치 불가능. 모든 파일이 다 다운받아야지만 저장됨 1GB짜리 영상을 200MB만 저장이 되면 실행할 수 없는 것처럼.
오브젝트 단위 특징:
오브젝트란? 파일 + 메타 데이터(파일이 가지고 있는 모든 정보, 속성)
* 메타 데이터를 3MB까지 저장할 수 있음!
저장할 것이 너무 많아서 제일 느리지만 프로그래밍할 수 있다는 특징이 존재.
조건을 다양하게 넣을 수 있음. ex. A가 접속할 때만 이 프로그램을 실행할 수 있도록 해주세요.
메타 데이터를 직접 추가할 수도 있고, 이미 존재하는 메타 데이터로 그냥 프로그래밍해도 됨
* pre-singed-url (S3 기능)
-> 클릭만 하면 60분 동안 이용할 수 있음
그런데 S3는 기본 사용 과금 + 검색, 다운로드, 업로드 등 기타 추가 작업도 과금
=> 비싸 죽는다.
AMI를 사용할 때 블록 스토리지를 사용하는 것이 좋음.
왜? Os 설치니 수정이니 관리니 뭐니 편리.
블록 스토리지의 한계는 있음. 네트워크 성능에 따라 느릴 수도 있다.
클라우드에서 제공하는 최대 디스크 크기는 16TB.
*** 백업 아주 중요함... 백업을 잘 해두세요...
AWS의 백업
스냅샷
!!용어 주의해야 하는 부분!!
대부분 스냅샷은 백업이라고 생각할 것인데, 일단 백업 방법도 다 다를 것이고 특히 Azure의 스냅샷은 초기화해버리는 기능의 용어로 사용 중.
EBS에서 사용하는 스냅샷이란 결국 무엇인지?
윈도우의 경우 특정 시점의 특정 상태를 저장하게 됨. 이후 증분 저장
리눅스 같은 경우 하드디스크를 늘렸다라고 하면 해줘야할 작업이 있음.
-> 리눅스에 디스크를 늘리면 fstab을 수정해서 디렉터리를 연결해 마운트해주는 작업. < 하드 디스크 연결 완료
클라우드에서는 디렉터리로 마운트가 잘 되지 않음... fstab 파일을 수정해주면 되는데 UUID값을 넣어야 함. 특정 값 하나를 콕 찝어서 연결해줘야 한다.
웹 페이지를 변경했을 때 다른 인스턴스에도 똑같이 변경되어야 한다.
어떤 방법으로 해야할까?
웹 페이지를 NAS에 저장. 그리고 모든 인스턴스의 홈 디렉터리를 NAS에 연결한다. 근데 하드 디스크는 못써. EBS 탈락!
오브젝트 스토리지는 프로그래밍되어 있기 때문에 접근이 어려움 오브젝트 스토리지도 탈락
이런 경우는 파일 스토리지를 사용해야 한다. (EFS)
파일 스토리지의 장점! 공동 작업을 할 때 멀티 연결이 가능해진다.
블록 스토리지
- 인스턴스 스토어: 임시 블록 스토어. 스냅샷 기능이 없다. 왜 쓰냐? 빠른 속도로 저장할 때 사용. nvme 수준
- Amazon EBS: 영구 블록 스토어(Persistent Block Level Storage). 스냅샷 기능 존재. AZ 서비스 수준. 같은 AZ안에 넣어둬야 함께 사용할 수 있음. 프로비저닝한 항목에 대한 요금만 지불 = 저장한 만큼이 아니고 만든 만큼 전부 지불
ex. ec2를 2a, EBS를 2c에 등록해뒀을 경우, 둘은 연결이 불가
EBS 볼륨 유형 2가지
1. SSD 지원 볼륨 : default. 근데 정말 일반 ssd와 같은 성능을 보이는지는...?ㅠㅠ
2. HDD 지원 볼륨
* 서버는 구매해서 만들 때 필수적으로 RAID를 설정하도록 되어있다.
RAID는 컨트롤러라는 칩이 존재.
하드 디스크 1, 2를 하나처럼 사용해라 => RAID 1 (미러링)
그럼 EC2는 RAID를 잡아야 할까?
EC2는 RAID 안 해도 된다. EBS에서 망가질 것을 대비하기 위해 이미 3개 정도의 하드 디스크를 복사해둔다. 눈으로 보이지 않아 모를 뿐.
EBS는 내구성을 보장하고 있다.
하지만 써야하는 경우는 분명히 있다.
=> EBS는 속도 제약이 있기 때문에 RAID 0, 5를 쓰는 방법 밖에 없다.
현재 나온 gp3 볼륨은 빠르고 성능이 좋긴 한데 돈을 더 내야 한다.
* AFR(연간 장애율)
일반 하드 디스크와 기업용 하드 디스크는 내구성이나 용량 자체가 다름.
EBS 볼륨은 0.1~0.2% AFR을 보인다. 복제가 여러번 되어 있기 때문에 장애율이 낮은 편임.
단일 EC2에 여러 EBS(하드디스크)를 꽂아 사용하는 것이 가능.
EBS 볼륨은 넣었다 뺐다 가능하다.
* HPC(슈퍼컴퓨터)는 니트로 서비스를 이용하는데, 이것은 여러 인스턴스에 하나의 하드디스크(EBS 볼륨) 넣기 가능
EC2 직렬 콘솔은 니트로 시스템만 사용 가능하기 때문에 일반 EC2 인스턴스는 사용이 불가능함
SSD는 파일 크기가 작다면 작은 파일이 많다면? SSD를 사용하는 것이 좋음 ex. DB server
파일 크기(동영상 등)가 크다면 Throughput optimized HDD가 좋다
- GP2: 성능을 높이려면 용량도 높였어야 함.
- GP3: 성능과 용량을 각자 높일 수 있지만 최대 초당 입출력 처리량 16k. * 집에서 보통 사용하는 것들이 98k 정도.
- 프로비저닝된 SSD: 최대 64k까지 가능.
이걸 빠르다고 할 수 있나?
리눅스를 서버에서 사용하는 이유는 웹 서버 때문이다. 웹 서버만 관리하고 나머지는 윈도우 서버
웹 서버는 왜 리눅스를 쓰나? -> Centos는 무료고 웹 서버만 올려두면 된다. 간단하고 안정적임.
EBS Snapshot
클라우드에서도 다른 백업 솔루션을 써도 되는데 굳이 스냅샷을 쓰는 이유는 무엇일까?
볼륨을 스냅샷 떠서 이미지로 만든다.
이미지 및 템플릿 > 이미지 생성: 존재하는 스냅샷을 이용해 이미지로 만드는 것.
스냅샷을 만들려면 스냅샷 > 볼륨 생성 해서 만들 수도 있음.
스냅샷을 만들 때 볼륨, 인스턴스를 스냅샷으로 만들 수 있다.
인스턴스를 스냅샷 뜨면 어떻게 될까?
인스턴스가 가진 정보를 한꺼번에 다 백업된다.
운영체제와 다른 서비스를 모두 포함한 정보가 전부 패키지처럼 저장.
만약 볼륨만 스냅샷으로 생성하면? 일부분만 스냅샷으로 저장됨
예를 들면 C 드라이브, D 드라이브만 저장되는 것.
Windows C 드라이브 스냅샷 생성
인스턴스 실행 중에 스냅샷을 생성하면 접속이 끊길까?
데이터가 계속 변화하는 상태에서 스냅샷을 찍으면 그 순간을 스냅샷으로 생성할 수 있을까?
결론 : 운영 도중에 사용할 수 있다.
하지만, 트래픽이 많이 들어오거나 성능이 너무 대단하면 조금 버거울 수 있다. 그래서 접속을 종료하고 스냅샷을 생성하는 것이 권장사항이다.
스냅샷이 생성되면 스냅샷 생성, 복사, 삭제, 스냅샷 볼륨 생성(Volume 생성), 스냅샷 이미지 생성(AMI 생성) 등의 다양한 기능을 이용할 수 있다.
스냅샷을 이용해서 2가지를 생성할 수 있다.
1. 볼륨 생성
2. 이미지 생성
볼륨으로 만들 때와 이미지를 만들 때의 상황은 무엇이 다를까?
볼륨으로 만들어 꽂기 vs AMI 생성해서 인스턴스 새로 생성
D 드라이브에 중요한 데이터 넣고 스냅샷 생성
얘로 AMI 만들면 OS 없어서 부팅이 X
OS까지 백업하고 싶으면 AMI로 생성, 데이터만 백업하고 싶다면 볼륨으로 생성
AMI를 생성하기 위해서는 스냅샷이 필요하다.
생성한 스냅샷을 이미지로 생성하는 것이 AMI
스냅샷을 이용해 AMI로 만들었다.
이 AMI를 만들었으니 스냅샷은 삭제해도 되지 않나? -> 안 됨.
안 되는 이유는 무엇일까?
-> 스냅샷으로 생성한 AMI는 같은 저장 공간을 사용 중이기 때문에 스냅샷을 삭제하기 위해서는 AMI를 삭제해야 한다. AMI 등록 취소를 통해 AMI를 삭제할 수 있다.
!!! 스냅샷이 단순히 백업용은 아니다. !!!
스냅샷과 AMI를 공유할 수 있다.
공유 계정을 등록하면 된다. 권한 설정 > 계정 ID 등록
스냅샷을 복제하여 다른 리전에도 받아올 수 있다.
<스냅샷 사용 용도>
1. 백업
2. 공유
3. 다른 리전에서 사용