EBS 스냅샷
인스턴스 스토어
AWS EFS
1교시
- AWS 코어 서비스
1. 클라우드에 데이터 저장
1.1. 객체 저장하기 : S3와 S3 Glacier
-> aws cli를 활용하여 S3 버킷 생성, 파일 업로드
-> SDK를 활용하여 애플리케이션과 S3 통합
-> S3에 정적 웹 사이트 호스팅
-> S3 Glacier 사용
1.2. 하드 드라이브에 데이터 저장 : EBS와 인스턴스 스토어
1.3. 관계형 DB 사용하기 : RDS
1.4. NoSQL DB 서비스 프로그래밍 : DynamoDB
2. 고가용성 아키텍처 설계
3. 인프라 디커플링
4. 장애 허용 시스템 아키텍처 설계
어제 마지막에 했던 EBS가 NAS 유형의 스토리지다.
연결을 해제했다가 다시 연결하면 내부 파일이 그대로 있는 것을 확인했다 = EC2에 종속적이지 않다는 것.
인스턴스도 스냅샷 기능을 사용할 수 있다. 이게 AMI다.
인스턴스에 Node.js, Apache, 웹 App 등을 설치하고 스냅숏을 찍은 것이 AMI
1.2.4.
EBS 볼륨은 99.9999%의 가용성을 제공하지만, 그래도 사용자는 수시로 백업을 만들어야 한다.
(데이터 유실의 확률은 없지만)
다행히도 EBS는 EBS 스냅샷이라는 편리한 EBS 볼륨 백업 방법을 제공한다.
스냅숏은 S3에 저장되는 블록 레벨 증분 백업이다.
-> 5GB 볼륨 크기를 사용하고 데이터를 1GB만큼 사용한다면, 첫 번째 스냅숏의 크기는 1GB
스냅숏 실습 : 어제 받은 EBS.yml 파일로 CloudFormation 스택 생성
-> EC2 인스턴스 하나와 볼륨 2개가 생성된다.
인스턴스에 연결된 5GB, 8GB 볼륨이 있고, 이 5GB 볼륨의 스냅숏을 찍고 연결 해제.
-> 이 스냅샷 백업을 복구하려면 스냅숏을 볼륨으로 바꿔서 연결해야 한다.
-> 정상 상태일 시점에 찍은 스냅샷이니 복구하면 정상 상태로 복구된다.
우선 5GB 볼륨의 볼륨 ID를 복사해 놓는다.
EBS는 가용 영역별로 나누어져 있다. EC2 인스턴스가 가용 영역 a에 있다면, 동일한 가용 영역에 있는 EBS만을 인스턴스에 부착할 수 있다.
인스턴스로 SSH 접속 > fdsik -l로 확인 > mkfs -t ext4 /dev/xvdf (파일 시스템 부여) > mkdir /mnt/volume (마운트 포인트 생성) > mount /dev/xvdf /mnt/volume/ (볼륨을 마운트 포인트에 마운트) > df -h로 확인
1.2.5.
스냅샷 작업 시점에 디스크가 Flush 되지 않은(볼륨에 완전히 쓰이지 않고 캐시에 남아있는) 쓰기가 문제를 일으킬 수 있다.
"fsfreeze -f [마운트 포인트]" 실행 후 스냅샷 실행 > 스냅숏이 진행 도중일 때 "fsfreeze -u [마운트 포인트]" 실행 > 스냅샷이 완성될 때까지 대기
터미널에서 프리징 걸어놓고 > 콘솔에 있는 볼륨 체크 > 작업 > 스냅숏 생성 > 스냅숏 이름 작성 후 스냅숏 생성 > 터미널에서 프리징 풀어주기
2교시
스냅샷이 찍혔으면 마운트 해제 > 스냅숏 탭으로 가서 스냅숏 체크 후 작업 > 볼륨 생성
> 가용 영역 확인하고 볼륨 생성
이제 볼륨 탭으로 가보면 새로운 볼륨이 생겼다
(볼륨 ID 잘 구분해서 진행할 것)
> 기존 5GB 볼륨 체크 > 작업 > 볼륨 해제
> 새로 생긴 볼륨 체크 > 작업 > 볼륨 연결 > 인스턴스 선택, 디바이스명 작성 > 연결
이제 인스턴스 세부 정보의 스토리지 탭으로 이동 > 연결된 볼륨의 ID 확인
인스턴스 터미널에서 다시 마운트(mount /dev/xvdf /mnt/volume/)
> 내부를 보면 이전에 만들었던 파일들이 그대로 있다.
- 실습
ec2-user 홈 디렉터리에 snapshot 디렉터리 생성 > 홈 디렉터리 안에 snapshot-test.txt 파일 생성, yum update, yum install -y httpd, systemctl enable --now httpd 실행 > 8GB EBS의 스냅숏 찍기(프리징 주의) > 인스턴스 중지 > 인스턴스에서 EBS 8GB 분리 > 스냅숏을 볼륨으로 만들고 인스턴스에 연결 > 인스턴스를 재가동해서 이전과 동일한지 확인
※ 마운트 포인트는 df -h로 확인
실습 끝. 일단 스택 파일 삭제 > 수동으로 생성했던 볼륨과 스냅샷 삭제
3교시
1.2.6. 인스턴스 스토어
https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/InstanceStorage.html
-> 일반 인스턴스에는 사용 불가. 고성능 인스턴스에만 부착 가능.
인스턴스 스토어는 일반 하드 디스크와 같이 블록 레벨 스토리지다. EBS보다는 비용이 적게 든다.
인스턴스 스토어는 EC2 인스턴스의 일부고, 인스턴스가 실행 중일 때만 사용.
-> 인스턴스를 중지/종료하면 데이터도 사라진다.
따라서 인스턴스 스토어의 비용은 따로 지불하지 않고 EC2 인스턴스 가격에 포함된다.
* 인스턴스 타입
범용 인스턴스 타입 : m4.medium ~ m4.2xlarge
컴퓨터 최적화 타입 : c4.large ~ c4.8xlarge
메모리 최적화 타입 : r4.large ~ r4.8xlarge
GPU 최적화 타입 : g2.xlarge ~ g2.8xlarge
스토리지 최적화 타입 : i3.xlarge ~ i3.8xlarge
고밀도 스토리지 최적화 타입 : d2.xlarge ~ d2.8xlarge
https://aws.amazon.com/ko/ec2/instance-types/
인스턴스 유형이 변경된 경우가 많다. 아래 링크 참고.
https://aws.amazon.com/ko/ec2/previous-generation/
EC2 인스턴스 생성 : 인스턴스 유형을 c5d.large로 선택, 가용 영역 a, 퍼블릭 주소 할당
-> 스토리지 추가 단계에서 선택한 볼륨을 볼 수 있다.
인스턴스 생성 후 접속 > fdisk -l 실행해서 확인 > 2개 하드디스크가 보인다
인스턴스의 스토리지 탭에서 보면 1개밖에 안 보인다 + 볼륨에서도 1개밖에 안보인다
4교시
인스턴스를 생성할 때 수동으로 추가하거나, 통째로 AMI로 만들던가.
인스턴스를 이미지로 만들기 + 이미지로 만들 때 인스턴스 스토어 추가하기
인스턴스 체크 > 작업 > 이미지 및 템플릿 > 이미지 생성 > 이름 작성, 볼륨 추가(Instance Store 0, 디바이스는 아무거나) > 이미지 생성
이미지 > AMI로 가보면 생성되고 있다.
S3 | EBS | 인스턴스 스토어 | |
일반적인 경우 | 사용자 업로드를 저장하는 애플리케이션에 통합 | 블록 레벨 스토어를 필요로 하는 기존의 DB 또는 애플리케이션을 위한 저장 | 임시 저장 공간 고성능 스토리지 |
자원 독립 여부 | Yes | Yes | No |
파일 시스템 여부 | No | Yes | Yes |
유지 보수 비용 | 불필요 | 약간 | 중간 |
AMI가 만들어졌으니 기존에 만든 인스턴스는 삭제하고
인스턴스 생성 > AMI 선택 시 '나의 AMI'로 가서 거기 있는 내가 만든 AMI 선택 > 똑같이 인스턴스 유형에서 c5d.large 추가 > 생성
이제 생성한 인스턴스로 접속하면 이미지 생성 전에 했던 작업은 남아 있지만 마운트는 풀려 있다
-> 그 안에 있던 데이터도 날아갔다.
삭제 : 인스턴스 종료 후 AMI는 등록 취소
AWS 서비스는 완전 관리형과 사용자 관리형이 있는데, EBS는 전자에 속한다.
NFS를 AWS로 구성할 것이다. NFS 서버와 클라이언트 모두 EC2 인스턴스로 구성
-> 이걸 간단하게 구성하는 서비스가 AWS EFS
5교시
오전에 한 실습 내용이 남아있으면 비용이 발생하니 반드시 삭제할 것.
- AWS로 NFS 구축
-> 서버와 클라이언트를 하나하나 EC2로 구축하면 세밀한 설정은 가능하겠지만, 번거롭다.
-> AWS EFS를 사용하면 편리하다
EBS처럼 NAS 기능이 아니라 네트워크 공간에 있는 스토리지
NFS 역할을 할 EFS 서버, 클라이언트 역할을 할 EC2 인스턴스
AWS Fargate : 완전 관리형 서버리스 서비스
일단 NFS 서버를 구성해 보자.
EFS > 파일 시스템 생성 > 이름 작성, VPC 선택, 가용성 및 내구성은 '리전' 선택 > 생성
상세 정보의 네트워크 탭에서 가용 영역별로 접속할 수 있는 IP 주소를 볼 수 있다.
생성된 파일 시스템의 ID 복사해놓기
EC2 인스턴스 2개 생성 후 접속
-> 각각 보안 그룹에 NFS 규칙(2049 포트) 추가
인스턴스에 NFS 패키지 설치(nfs-utils)
마운트 포인트용 디렉터리 생성 : mkdir /mnt/nfs
마운트 포인트에 NFS 연결 : mount -t nfs [해당 인스턴스가 있는 가용 영역에 해당하는 NFS의 IP 주소]:/ [마운트 포인트]
영구 설정하려면 /etc/fstab 들어가서 하단에 내용 추가
[마운트 걸 장치명]:/ [마운트 포인트] nfs rw 0 0
추가
수업 시간에 연결이 안되길래 나중에 다시 해봤다.
-> 보안 그룹 문제. EC2 인스턴스 뿐만 아니라 EFS에도 보안 그룹이 있다.
-> 기본값으로 기본 보안 그룹에 연결되어 있었는데, 여기에는 NFS 개방 규칙이 없었다.
-> 추가해주니 성공적으로 작동했다.
요약
- 블록 레벨 스토리지는 EC2 인스턴스와 조합해야 사용할 수 있다.
접근할 때 운영체제가 필요하기 때문.
- EBS 볼륨은 네트워크를 통해 EC2 인스턴스에 연결된다.
인스턴스 유형에 따라 네트워크 연결의 대역폭이 달라진다.
- EBS 스냅숏은 S3에 EBS 볼륨을 백업할 수 있는 좋은 방법이다.
S3가 블록 레벨 증분 방식을 사용하기 때문이다.
- 인스턴스 스토어는 EC2 인스턴스의 일부이며, 빠르고 저렴하다.
하지만 EC2 인스턴스가 중지되거나 종료되면 내부에 있는 모든 데이터가 유실된다.
- NFS나 Amazon EFS 서버를 활용하여 여러 EC2 인스턴스 사이에 파일을 공유할 수 있다.
6교시
1.3. 관계형 데이터베이스 사용하기 : RDS
- RDS로 관계형 DB 시작하고 초기화하기
- DB 스냅샷 생성 및 복원
- 고가용성 DB 구성하기
- DB 성능 튜닝
- DB 모니터링
강사님 교무회의로 이번 수업은 넘어갔다.
7교시
RDS 사용 시 원하는 DBMS를 선택해서 구성할 수 있다.
관계형 DB는 구조화된 데이터를 저장하고 질의하는 실질적 표준이다.
많은 앱이 MySQL, OracleDB, MSSQL, PostgreSQL과 같은 관계형 DB 시스템 위에서 돌아간다.
일반적으로 관계형 DB는 데이터 일관성에 초점을 두어 ACID(Atomicity, Consistency, Isolation, Durability)을 준수하며, DB Transaction을 보증한다.
회계 등의 업무에서 계정/거래와 같은 구조화된 데이터를 저장하거나 조회하는 일 등이 관계형 DB가 처리하는 작업.
- AWS에서 관계형 DB를 사용하는 방법은 2가지다.
1. EC2 인스턴스에 사용자가 직접 관리하는 관계형 DB 서버를 설치/운영
2. AWS가 제공하는 관계형 DB 관리 서비스인 AWS RDS를 사용
- AWS Aurora
AWS에서 직접 만들어 제공하는 DB 엔진.
오로라는 MySQL과 호환되면서 더 낮은 비용으로 더 나은 가용성 성능을 제공
- 서비스 비용 : RDS > EC2 DBMS
- 총 소유 비용(운영 비용) : RDS < EC2 DBMS
- 품질 : RDS는 AWS가 관리/EC2 DBMS는 자체 팀을 구성해서 관리를 직접 수행
- 유연성
RDS는 원하는 DB 시스템과 대부분의 구성 매개변수를 선택할 수 있다(유연성이 높은 편).
EC2 DBMS는 더욱 높은 유연성을 가지고 있다.
8교시
강사님께 받은 파일로 스택 생성... 하는데 에러 발생으로 시간이 꽤 지났다.
어쨌거나 해결하고 진행... 하려다 못하고 끝.
내일 다시
5교시 EFS로 NFS 구성하는 실습 다시 보기. 왜 안되지?
'교육' 카테고리의 다른 글
[68일 차] 21.10.29 : DevOps 9 (0) | 2021.10.29 |
---|---|
[67일 차] 21.10.28 : DevOps 8 (0) | 2021.10.28 |
[65일 차] 21.10.26 : DevOps 6 (0) | 2021.10.26 |
[64일 차] 21.10.25 : DevOps 5 (0) | 2021.10.25 |
[63일 차] 21.10.22 : DevOps 4 (0) | 2021.10.22 |
댓글