[AWS 교과서] 5장 - AWS 스토리지 서비스(2)

 

 

다양한 AWS 스토리지 서비스 구성하기

 

 

실습목표는 AWS의 다양한 스토리지 서비스를 직접 구성해서 사용하고, 각 스토리지 기능과 활용법을 확인해보는 것이다!

 

 

1. 실습에 필요한 기본 인프라 배포하기

 

실습에 필요한 인프라 자원은 AWS CloudFormation을 이용하여 자동으로 배포하면 된다! (과거 실습에서 진행했었음)

 

AWS 관리 콘솔에서 서비스 > 관리 및 거버너스 > CloudFormation 메뉴로 들어간 후 스택 생성을 누름

 

Amazon S3 URL에 아래 URL을 입력하고 다음을 누름

https://cloudneta-aws-book.s3.ap-northeast-2.amazonaws.com/chapter5/storagelab.yaml

 

 

 

스택 이름에 storagelab 입력하고 KeyName은 사용자 키 페어 파일 선택 후 다음

 

스택 옵션 구성은 별도의 설정 없이 다음을 누르고

 

 

storagelab 검토에서는 별도의 설정은 없으나 가장 아래쪽에 사진처럼 체크하고 전송을 누른다

 

이렇게 하면 일정 시간이 지나 스택 상태가 CREATE_COMPLETE가 되면서 인프라 배포가 정상적으로 완료된다!

 

 

이제 SSH 터미널에서 STG1, STG2로 접속하여 명령어를 하나씩 입력해보면서 EBS 스토리지 기본 정보를 확인한다

 

# STG1 SSH 터미널 접속
# df(disk free) 디스크 여유 공간 확인

df -hT /dev/xvda1

# lsblk 사용 가능한 디스크 디바이스와 마운트 포인트(해당하는 경우) 확인

lsblk

# 디바이스의 UUID 확인

blkid

# 디바이스의 탑재 지점 확인

cat /etc/fstab

 

 

 

2. EBS 스토리지를 추가로 생성한 후 사용하기

 

AWS 관리 콘솔에서 EC2 > Elasti Block Storage > 볼륨 > 볼륨 생성을 선택한다

 

 

 

설정페이지로 들어가면 다음과 같이 설정해주고 볼륨 생성을 누르면 된다

 

이제 생성된 EBS 스토리지를 EC2 인스턴스에 연결해야 한다!

 

추가된 Data 1 볼륨(available 상태인지 먼저 체크)을 체크한 후 작업 > 볼륨 연결을 선택한다

 

인스턴스(EC2-STG1), 디바이스(/dev/sdf)를 선택하여 설정한 후 볼륨 연결을 선택

 

=> Data 볼륨을 연결할 때, AZ 3의 인스턴스(STG2)가 나오지 않는 이유는 EBS 볼륨은 해당 AZ만 사용할 수 있기 때문!

 

볼륨(디스크)을 추가할 때는 일반적으로 인스턴스를 중지한 후 연결해야 하지만 핫스왑(hot swap) 기능이 있기 때문에 동작(라이브) 상태에서 자동으로 추가된 볼륨을 인식한다

 

 

인스턴스(STG1)에 추가로 연결된 EBS 볼륨을 사용하도록 설정해보자

 

# STG1 SSH 터미널 접속
# 라이브 상태에서 디바이스 추가 확인

lsblk

# 볼륨을 포맷하여 파일 시스템 생성

mkfs -t xfs /dev/xvdf

# 디렉터리를 생성한 후 마운트

mkdir /data
mount /dev/xvdf /data

# 파일을 생성한 후 확인

echo "EBS Test" > /data/memo.txt
cat /data/memo.txt

# 디바이스 확인

lsblk

df -hT /dev/xvdf

# 재부팅 이후에도 볼륨 자동 탑재를 위한 fstab 설정
# 파일 시스템 정보를 저장하고 있으며, 부팅할 때 파일 안에 구성 값으로 자동 마운트되도록 하는 정보 확인

cat /etc/fstab

# 장착할 볼륨 정보 확인

blkid

# fstab 설정 (blkid 코드 결과에서 확인한 자신의 UUID 입력 => xvdf의 UUID를 입력해야함)

echo "UUID=36d4b7ad-5f45-49ee-8cf7-7d7c2fe2f635 /data xfs defaults,nofail 0 2" >> /etc/fstab

# fstab 설정 확인

cat /etc/fstab

 

😋자동으로 마운트하는 방법

추가 생성된 볼륨은 재부팅할 때 자동으로 마운트되지 않아 매번 마운트 작업을 수행해야 한다

다라서 자동으로 마운트하는 작업은 필요할 때 사용하면 매우 유용!

자동 마운트 설정

설정파일 : /etc/fstab

/dev/xvdb1    /data    xfx    defaults    0    0

띄어쓰기 기준 순서대로 장치명, 마운트 위치, 파일시스템, 속성(default는 읽기, 쓰기, 실행 등 작업 가능),
덤프 사용 여부, 파일 시스템 체크 여부를 나타낸다

 

3. EBS 스토리지 볼륨 크기를 변경하고 스냅샷 기능 확인하기

 

EBS 볼륨 크기 변경하기

 

서버를 운영할 때 로그 파일을 저장하면서 문제가 발생할 수 있는데, 저장 공간 대부분을 로그 파일이 차지해서 특정 서비스 접근이 차단되어 장애로 이어지는 경우이다

 

=> 하지만 EBS 스토리지는 서버를 운영할 때 저장 공간 크기를 탄력적으로 조정하기 때문에 이런 서비스 장애에 대처할 수 있다

 

이번 실습에서는 장애 조치 상황이 아닌 EBS가 어떻게 탄력적으로 크기를 조정할 수 있는지 정도만 알아보자

 

우선, 인스턴스 STG1의 루트 볼륨을 확장하고 볼륨 유형을 변경한다

 

AWS 관리 콘솔에서 EC2 > EBS > 볼륨을 선택한 후

 

EC2-STG1_Root_Volume을 체크하고 작업 > 볼륨 수정을 선택하여 설정을 변경한다

 

 

설정 후 동작 상태에서 다시 설정을 변경할 수 있는데, 3~10분 정도 시간이 소요된다

 

이렇게 수정을 할 수 있다

 

볼륨 최적화를 시작하면 파일 시스템 크기를 조정할 수 있으므로 

파티션 조정 -> 파일 시스템 조정 순서로 파일 시스템을 확장한다

 

# STG1 SSH 터미널 접속
# 현재 루트
# 볼륨 상태 확인

lsblk

df -hT /dev/xvda1

# growpart 명령어로 파티션 확장(파티션 조정)

growpart /dev/xvda 1

# 변경된 루트 볼륨 파티션 상태 확인

lsblk

# xfs_growfs 명령어로 볼륨의 파일 시스템 확장(파일 시스템 조정)

xfs_growfs -d /

# 변경된 루트 볼륨의 파일 시스템 상태 확인

df -hT /dev/xvda1

 

 

EBS 스냅샷 기능 확인하기

 

앞서 실습으로 EBS 크기를 탄력적으로 변경하여 데이터 저장 크기를 조정할 수 있다는 것을 확인했다!

 

하지만 지속적으로 크기를 확장하기는 쉽지 않으므로 백업으로 데이터를 분산 저장해야 한다

 

=> 이런 백업을 EBS에서는 스냅샷 기능으로 제공한다

 

 

실습을 위해 가상 파일을 10G 크기로 만들어서 테스트 한다

 

# STG1 SSH 터미널 접속
# 가상 파일 생성 후 확인

fallocate -l 10G /home/10G.dummy
df -hT /dev/xvda1

 

 

이제 인스턴스 STG1의 루트 볼륨을 스냅샷으로 백업해보자

 

EC2 > EBS > 볼륨에서 EC2-STG1_Root_Volume에 체크하고 작업 > 스냅샷 생성을 차례로 선택한다

 

스냅샷 생성 페이지에서 설명에 FirstSnapshot을 입력하고 스냅샷 생성을 누른다

 

 

EC2 > EBS > 스냅샷에 들어가 진행사항을 확인해본다

(최초 백업은 볼륨 전체 백업이므로 다소 시간이 소요됨)

 

 

스냅샷 기능은 증분 백업하므로 실습을 위한 가상 파일을 추가로 생성해서 확인해본다!

 

# STG1 SSH 터미널 접속
# 가상 파일을 생성한 후 확인

fallocate -l 5G /home/5G.dummy
df -hT /dev/xvda1

 

AWS 관리 콘솔에서 EC2 > EBS > 볼륨 메뉴를 차례로 선택하고

EC2-STG1_Root_Volume에 체크하고 작업 > 스냅샷 생성을 차례로 선택한다

 

=> 스냅샷 생성 페이지에서 전과 동일하게 설명에 SecondSnapshot을 입력한 후 스냅샷 생성을 누른다

 

 

EC2 > EBS > 스냅샷 메뉴에서 진행 상황을 확인한다
(증분 백업은 변경된 볼륨만 백업하므로 빠르게 진행됨)

 

 

 

EFS 스토리지 생성하고 사용하기

 

현재 실습의 구성을 살펴보면 각 AZ별로 인스턴스(STG)에 웹 서비스가 동작하고 있다

 

가용 영역별 인스턴스가 파일 공유 스토리지를 사용하면 동일한 웹 콘텐츠의 웹 서비스를 제공하는 효과를 얻을 수 있다

 

=> 이번에는 웹 서비스에 사용되는 루트 역할의 디렉터리를 EFS 스토리지로 마운트하고 다른 AZ에서도 같은 스토리지를 공유해 보자

 

 

AWS 관리 콘솔의 서비스 > 스토리지 > EFS > 파일 시스템 에서 파일 시스템 생성 > 사용자 지정을 선택한다

 

 

다음과 같이 설정해주고 나머지는 건드리지 않고 생성을 누른다!

 

이제 다시 파일 시스템 메뉴로 돌아가 EFS 스토리지가 생성되었는지 확인한다

(파일 시스템 ID는 SSH 터미널에서 바로 사용할 예정!)

 

생성된 EFS 네트워크 인터페이스가 하나 이상인 이유는 EFS를 생성할 때 리전을 선택하여 VPC 내 가용 AZ별로 각각 생성되기 때문이다

 

 

인스턴스 STG1에 생성된 EFS를 사용하도록 연결해보자

 

# STG1 SSH 터미널 접속

# 현재 리전별 웹 서버 동작 확인 (STG1)

curl localhost

# 현재 리전별 웹 서버 동작 확인 (STG2)

curl localhost

# efs 디렉터리 생성

mkdir /var/www/html/efs

# 자신의 EFS ID 확인 후 마운트 

EFS=fs-0458339af31a60450(자신의-EFS-ID) # 변수 지정, 반드시 자신의 파일 시스템 ID 확인 후 입력
mount -t efs -o tls $EFS:/ /var/www/html/efs

# EFS 마운트한 곳에 파일 생성 후 확인

echo "<html><h1>Hello from Amazon EFS</h1></html>" > /var/www/html/efs/index.html
curl localhost/efs/

# EFS Size 확인 - 사용자는 표시된 용량과 상관없이 실제 사용한 용량만큼 비용 지불

df -hT |grep efs

# EFS DNS 주소를 조회할 때 표시되는 IP는 각 AZ에 속한 인터페이스 IP 주소 (dig +short 자신의-EFS-ID.efs.ap-northeast-2.amazonaws.com)

dig +short $EFS.efs.ap-northeast-2.amazonaws.com

 

이번에는 인스턴스 STG2에 생성된 EFS를 사용하도록 연결해보자

 

# STG2 SSH 터미널 접속
# efs 디렉터리 생성

mkdir /var/www/html/efs

# 자신의 EFS ID 확인 후 마운트(mount -t efs -o tls 자신의-EFS-ID:/ /var/www/html/efs)

EFS=fs-0458339af31a60450(자신의-EFS-ID) # 변수 지정, 반드시 자신의 파일 시스템 ID 확인 후 입력
mount -t efs -o tls $EFS:/ /var/www/html/efs

# EFS 마운트 확인

curl localhost/efs/

# EFS Size 확인 - 사용자는 표시된 용량에 상관없이 실제 사용한 용량만큼 비용 지불

df -hT |grep efs

# EFS DNS 주소를 조회할 때 표시되는 IP는 각 AZ에 속한 인터페이스 IP 주소(dig +short 자신의-EFS-ID.efs.ap-northeast-2.amazonaws.com)

dig +short $EFS.efs.ap-northeast-2.amazonaws.com

 

 

EFS 주소를 조회할 때 다른 IP로 표시되는 이유는 'EFS는 AZ당 하나의 Mount Target(네트워크 인터페이스)을 사용'하기 때문이다

 

 

EFS를 이용하여 각 인스턴스의 파일을 공유함

 

=> 각 인스턴스의 SSH 터미널에 맞는 명령어를 잘 입력해야 한다

 

# STG1 SSH 터미널 접속
# 인스턴스 STG1에서 파일 생성

for i in {1..100}; do touch /var/www/html/efs/deleteme.$i; done;

# STG2 SSH 터미널 접속
# 인스턴스 STG2에서 파일 생성

ls /var/www/html/efs

...

# 인스턴스 STG2에서 생성된 파일 삭제

rm -rf /var/www/html/efs/deleteme*.*

# STG1 SSH 터미널 접속
# 인스턴스 STG1에서 삭제된 파일 확인

ls /var/www/html/efs

 

여기까지 인스턴스 간 공유 스토리지를 이용하여 동일한 파일 정보를 확인해 보았다

 

이처럼 EFS 스토리지는 여러 가용 영역에 걸쳐 실행되는 웹 서비스에 정적 및 동적 콘텐츠를 공유하고, 새로운 파일이나 변경된 콘텐츠를 즉시 반영하여 사용해야 할 때 매우 유용하다

 

 

Public S3 스토리지로 외부 접근 확인하기

 

S3는 객체 스토리지 서비스로, 설정에 따라 OS 없이 자체적인 웹 서버로 사용되거나 API 방식을 이용한 데이터 백업 및 공유를 할 수 있다

 

=> 이번 실습에서는 공개된 S3 스토리지를 만들고 외부에서 접근을 이용한 정적 웹 서버로 사용되는 환경을 만들어보자

 

 

AWS 관리 콘솔의 서비스 > 스토리지 > S3 > 버킷에서 버킷 만들기를 눌러 버킷을 생성한다

 

 

설정 화면이 뜨면 사진과 같이 설정을 해준다

(언급하지 않은 부분은 기본값을 유지)

 

버킷 이름은 고유해야 하며, 버킷 이름 지정 규칙을 따라야한다!

 

생성된 버킷을 선택한 후 업로드 > 파일 추가를 누르고, 임의의 테스트용 이미지 파일을 선택한 후 업로드를 누른다

 

=> 업로드 된 파일을 선택하면 객체 개요에서  객체 URL을 확인할 수 있다

 

 

그런데 객체 URL로 웹에 접근해보면 파일 정보가 표시되지 않는 것을 볼 수 있다

 

=> 버킷에 업로드된 파일은 기본적으로 외부에서 접근하는 것이 차단되어 있기 때문!

 

 

외부에서 접근한 후 사용하려면 설정이 추가로 필요하다

 

업로드된 파일을 선택한 후 작업 > ACL을 사용해 퍼블릭으로 설정 > 퍼블릭으로 설정을 선택하고 다시 확인해보면

 

 

이렇게 잘 접근이 됩니다!

 

인스턴스 STG1에 웹 접근을 할 때 S3 스토리지에 업로드된 파일을 사용하도록 웹 서버의 index.html 파일을 설정해줘야 한다!

 

# STG1 SSH 터미널 접속
# 인스턴스 STG1에서 index.html 파일 생성

cat <<EOF>> /var/www/html/index.html
<html>
<body>
<h1>CloundNeta S3 Storage<br>
// 앞서 업로드한 테스트 파일 객체 주소 입력
<img src="https://cloudneta-jungyo.s3.ap-northeast-2.amazonaws.com/%EC%8A%A4%ED%81%AC%EB%A6%B0%EC%83%B7+2023-10-30+162447.png">
</body>
</html>
EOF

# index.html 파일 생성 확인

cat /var/www/html/index.html
..(생략)..

 

이제 인스턴스 STG1 웹 서버에 접근해서 표시되는 사진이 S3에 업로드한 파일임을 확인해보자!

 

 

=> 잘 보이는걸 확인할 수 있다!

 

이제 객체마다 추가 설정 없이도 외부에서 접근하면 자동으로 사용할 수 있도록 설정해보자

 

앞서 생성한 버킷을 선택하고 권한 탭을 클릭한다.

버킷 정책에서 편집을 누른 후 밑의 정책을 추가하고 변경 사항 저장을 선택한다

 

# S3의 보안 정책을 이용하여 외부 접근을 허용하는 설정

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Sid": "PublicReadGetObject",
			"Effect": "Allow",
			"Principal": "*",
			"Action": "s3:GetObject",
			"Resource": "arn:aws:s3:::cloudneta-jungyo/*"
		}
	]
}

 

Resource 부분에서 자신의 버킷 ARN 뒤에 /* 를 붙여 버킷내의 모든 객체에도 권한을 부여해준다

 

 

 

=> 설정한 후 생성된 버킷에 '퍼블릭 액세스 가능' 문구를 확인한다

 

버킷 메뉴로 돌아와서 데스트용 이미지 파일을 새롭게 업로드한 후
객체 URL을 클릭해보면 외부에서 별다른 설정 없이 접근할 수 있다!

 

 

 

 

Private S3 스토리지의 제한된 접근 및 데이터 백업하기

 

이번 실습에서는 S3 스토리지를 관리 콘솔이 아닌 AWS CLI에서 만들어 VPC 내부에서만 접근해서 사용할 수 있도록 Private S3 버킷을 생성해보자!

 

실습에 필요한 CLI와 S3 접근에 따른 IAM 권한은 실습 환경에 사용된 CloudFormation으로 이미 설치 및 적용되어 있다

 

 

AWS CLI를 이용하여 Private S3 버킷을 생성한 후 사용할 수 있게 다음과 같이 설정한다

 

# STG1 SSH 터미널 접속
# 기존 S3 조회

aws s3 ls

# S3 버킷 생성(aws s3 mb s3://자신의 고유한 BUCKET_NAME) - 버킷 생성 후 S3 웹 콘솔에서 확인

aws s3 mb s3://cloudneta-jungyo-s3-private

# 버킷 이름을 변수에 지정(MyS3=버킷)

MyS3=cloudneta-jungyo-s3-private

# 파일 생성 후 S3에 업로드

echo "111" > /var/www/html/111.txt
aws s3 cp /var/www/html/111.txt s3://$MyS3
aws s3 ls s3://$MyS3

# 웹 디렉터리(하위 포함)를 S3 버킷에 업로드(수동 백업) 후 확인

aws s3 sync --delete /var/www/html s3://$MyS3
aws s3 ls s3://$MyS3 --recursive

 

다음 코드를 입력하여 파일을 업로드하고 버킷을 조회한 후 로그를 확인한다

(확인 후에는 ctrl+c 를 눌러 빠져나옴)

 

# STG1 SSH 터미널 접속
# crontab 내용 추가

cat <<EOF>> /etc/crontab
*/1 * * * * root aws s3 sync -delete /var/www/html s3://$MyS3
EOF

# crontab 내용 확인

cat /etc/crontab
...(생략)...

# 적용 및 추가 파일 생성

systemctl restart crond
echo "222" > /var/www/html/222.txt
echo "333" > /var/www/html/333.txt

# 실시간 버킷 조회 후 로그 확인

while true; do aws s3 ls s3://$MyS3; date; echo "---[S3 ls]---"; sleep 3; done
tail -f /var/log/cron

 

생성된 Private S3 버킷은 일반적으로 외부 접근이 불가능하지만 Pre-sign URL 기능을 이용하여 특정한 사용자에게 제한된 시간 동안 외부 접근을 허용할 수 있다

 

# STG1 SSH 터미널 접속
# 테스트 파일 생성 후 S3에 업로드

echo "presigned test" > /var/www/html/presigned.txt
aws s3 cp /var/www/html/presigned.txt s3://$MyS3

# 객체 URL로 직접 접근을 불가하나 Pre-sign URL 생성

aws s3 presign s3://$MyS3/presinged.txt --expires-in 120

 

 

위의 코드 마지막줄에서 생성된 Pre-sign URL로 웹에서 접근할 수 있는지 확인한다 (120초 정도 소요)

 

이렇게 5장 실습이 끝났다!

 

이제 실습할 때 생성한 모든 자원을 삭제해보자

 

1. 서비스 > EC2 > EBS > 스냅샷 메뉴로 들어가 모든 스냅샷을 체크한 후 작업 > 스냅샷 삭제를 선택한다

 

 

2. EC2 > EBS > 볼륨 메뉴로 들어가고 Data1 을 체크한 후 작업 > 볼륨 분리를 선택한다 (5분 ~ 10분)

 

=> Data1 을 체크한 후 작업 > 볼륨 삭제를 선택한다

 

3. 서비스 > EFS > 파일 시스템 메뉴로 들어간 후 생성한 파일 시스템을 선택하고 삭제를 누른다

 

 

4. 서비스 > S3 > 버킷 메뉴로 들어가서 생성한 버킷을 선택한 후 오른쪽 위에 있는 비어있음을 누른다

 

=> 다시 버킷을 선택하고 삭제를 누르면 됨

 

5. 서비스 > CloudFormation > 스택 메뉴에서 storagelab 스택을 선택한 후 삭제를 누른다

 

 

 

😉이렇게 해서 5장이 끝났습니다🤭