[EBS] AWS CLI를 이용한 EBS 생성 / GP3 업그레이드 / 퍼포먼스 테스트
목차
Step 1. CLI 명령어를 통한 AWS EBS GP2 볼륨타입을 생성 및 확인
Step 2. 파일시스템 생성 및 특정 디렉토리 마운트
Step 3. Gp2에서 GP3 업그레이드
Step 4. FIO 유틸리티를 이용한 퍼포먼스 테스트
Step 1 CLI 명령어를 통한 AWS EBS GP2 볼륨타입을 생성 및 확인
1-1. AWS CLI 명령어를 통해 EBS 목록 출력
aws ec2 describe-volumes
1-2. 태그 값을 통한 볼륨 필터링
aws ec2 describe-volumes --query 'Volumes[?not_null(Tags[?Value==`jonghyun.lee`].Value)]'
※ 신규 UI환경에서 EC2 생성시 Resource_Type에 Volumes도 체크를 해주어야 EBS Volume에도 태그가 추가된다. (예전 UI 환경에서는 EC2 태그에 따라 EBS 태그도 같이 저장되었던 것으로 기억하는데 이제는 독립적으로 태그 설정을 할 수 있도록 개편되었다.)
1-3. Attach 할 인스턴스와 같은 가용영역에 EBS GP2 2Gb 볼륨 생성
aws ec2 create-volume --size 2 --volume-type gp2 --availability-zone ap-northeast-2a
1-4. 적당한 시간이 지난 후 AWS CLI 명령어를 통해 available 상태인 볼륨을 확인해보자.
(현재 계정에는 1개의 EBS 볼륨을 추가했기에 Available 상태인 EBS는 1개만 보인다.)
aws ec2 describe-volumes --filters "Name=status,Values=available"
(선택사항) 환경변수 저장
해당 고유 리소스 identifier에 대하여 반복작업이 계속된다면 환경변수로 설정하면 효율성을 높일 수 있다.
1-5. CLI 명령어를 통해 생성한 EBS GP2 볼륨을 EC2에 Attach 시켜보자.
aws ec2 attach-volume \\
--instance-id $INSTANCE_ID \\
--volume-id $VOLUME_ID \\
--device /dev/sdf
콘솔에서 확인했을 때 지정한 EC2에 Attach 되었음을 확인할 수 있다.
EC2 생성 시 EBS 마운트 디렉토리를 설정하는 이유
AWS EBS 볼륨을 생성하는 단계에서 EC2에 마운트할 디렉터리를 설정을 하는데, 이 과정에서 AWS EBS마운트 디렉토리(OS)와 고유한 EBS Volume ID가 1:1 맵핑이 된다.
이는 스토리지 서비스(EBS)와 EC2(OS)가 논리적인 연결을 생성하기 위함이다.
Step 2. 파일시스템 생성 및 특정 디렉토리 마운트
2-1. lsblk 명령어를 이용하여 현재 available 상태인 block device를 확인해보자.
[root@test ~]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 8G 0 disk
└─xvda1 202:1 0 8G 0 part /
xvdf 202:80 0 2G 0 disk
step 1-5에서 분명히 /dev/sdf 경로로 저장을 하였음에도 불구하고 Instance 내부에서 확인했을 때는 /dev/xvdf로 확인이 된다. 이는 Block device의 "xen-blkfront" 드라이버가 sda,sdb ... 를 xvda, xvdb.... 로 mapping을 시키기에 그렇다고 한다.
/dev/sda 및 /dev/sdf 는 그저 symbolic link임을 확인할 수 있다.
2-2. file, df 명령어를 통해 새롭게 생성한 EBS 정보를 확인해보자.
마운트된 파일시스템에서 신규 추가한 EBS 볼륨을 확인할 수 없다.
2-3. xfs 파일시스템 생성 및 /data 디렉토리로 마운트
운영체제가 파티션 영역을 인식 할 수 있도록 (운영체제만이 알 수 있도록) 파일 시스템을 만들어줘야 한다.
파일시스템에는 여러 타입이 존재한다. 여기서는 xfs 타입으로 파일시스템을 생성하였다.
# xfs 타입으로 파일시스템 생성
# /dev/xvdf 볼륨을 xfs type으로 파일시스템 생성
[root@test ~]# mkfs -t xfs /dev/xvdf
meta-data=/dev/xvdf isize=512 agcount=4, agsize=131072 blks
= sectsz=512 attr=2, projid32bit=1
= crc=1 finobt=1, sparse=0
data = bsize=4096 blocks=524288, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=1
log =internal log bsize=4096 blocks=2560, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
# /data 마운트포인트 생성
# 마운트 = 디스크 파티션을 특정한 위치(디렉토리)에 연결시켜주는 과정
[root@test ~] mkdir /data
# /dev/xvdf 의 SSD 파티션을 /data 마운트 포인트(디렉토리)에 마운트(=연결)
[root@test ~] mount /dev/xvdf /data
2-4. 마운트 확인
Step 3. EBS GP2 볼륨 GP3로 업그레이드하기
(Remind) Step 1-5에서 CLI 명령어를 통해 신규 생성된 EBS GP2 볼륨을 EC2에 Attach 시켰다.
#EC2에 볼륨 추가
aws ec2 attach-volume \\
--instance-id $INSTANCE_ID \\
--volume-id $VOLUME_ID \\
--device /dev/sdf
#볼륨 ID 확인 (볼륨 생성 시 환경변수로 등록했었음)
echo VOLUME_ID=$VOLUME_ID
>> VOLUME_ID=vol-0ec3d0ca67015344f
3-1. AWS CLI 명령어를 통해 GP2 타입에서 GP3로 업그레이드를 진행해보자.
#볼륨 타입 gp3 타입으로 변경
aws ec2 modify-volume \
--volume-id $VOLUME_ID \
--volume-type gp3
3-2. GP3 업그레이드 확인
# 최신 생성시간 순서대로 계정내 EBS 볼륨 나열
aws ec2 describe-volumes \
--query 'Volumes[::-1]'
EC2 콘솔에서도 신규 생성 볼륨타입이 gp3 타입으로 변경되었음을 확인할 수 있다.
Step 4. GP3 타입 EBS 볼륨 퍼포먼스 테스트
기본적으로 gp3 볼륨 유형은 볼륨 크기와 관계없이 3,000 IOPS 및 125 MiB/s Thourghput 기준 성능을 제공한다.
더 높은 성능을 원한다면 설정을 통해 기준성능 이상으로 더 높일 수 있다.
※ 단, 추가 비용이 발생하며, 최대 16,000 IOPS 및 1,000MiB/s 까지 확장이 가능하다.
새로운 기능 – Amazon EBS gp3 볼륨을 통해 용량과 별도로 성능을 프로비저닝 | Amazon Web Services
Amazon Elastic Block Store(EBS)는 크기와 상관없이 처리량 및 트랜잭션 집약적 워크로드를 모두 처리할 수 있도록 Amazon EC2 인스턴스와 함께 사용하도록 설계되어 사용하기 쉬운 고성능 블록 스토리지
aws.amazon.com
4-1. 신규 생성한 GP3 볼륨에 대해 퍼포먼스 테스트를 진행해보자.
성능 요구사항을 충족하는지 확인하기 위해 퍼포먼스 테스트를 실시한다.
퍼포먼스 테스트 툴은 FIO(Flexible I/O Tester)을 이용할 것이며 설치를 진행해보자.
(※ FIO는 특정 워크로드를 테스트하고자 만들어진 유틸리티이다.)
sudo yum install -y fio
4-2. fio 유틸리티를 이용하여 I/O 벤치마크를 실행해보자. 신규 생성한 EBS 볼륨은 /data 디렉토리에 마운트를 하였다.
# 테스트할 마운트 경로 이동
cd /data
# fio 테스트 파일 저장경로 설정
TEST_DIR=/data/fiotest
sudo mkdir -p $TEST_DIR
아래 해당 설정은 60초동안 /data 볼륨 디렉토리에 대하여 fio 유틸리티가 I/O 벤치마킹을 실행할 것이다.
파라미터 종류가 너무 많기에, 아래 매뉴얼 사이트에서 각 속성값들이 어떤 의의를 지니는지 확인할 수 있다.
fio(1): flexible I/O tester - Linux man page
fio(1) - Linux man page Name fio - flexible I/O tester Synopsis fio [options] [jobfile]... Description fio is a tool that will spawn a number of threads or processes doing a particular type of I/O action as specified by the user. The typical use of fio is
linux.die.net
아래 설정값은 I/O 블록 크기를 16k로 설정하고 I/O depth를 64 이상으로 설정한 상태로 IOPS를 테스트한다.
# IOPS 퍼포먼스 측정 설정 파라미터
sudo fio \
--directory=$TEST_DIR \
--ioengine=psync \
--name fio_test_file \
--direct=1 \
--rw=randwrite \
--bs=16k \
--size=100M \
--numjobs=8 \
--time_based \
--runtime=60 \
--group_reporting \
--norandommap
짧게 60초동안 테스트를 진행하였지만, IOPS가 3,110 으로 3000을 상회하는 결과값을 확인할 수 있다.
더 정밀한 성능 검증을 위해 30분 이상으로 steady하게 3,000 IOPS가 나오는지 확인도 중요하다. 그렇기에 이번엔 설정값을 30분으로 두고 재실험을 진행하였다.
# IOPS 퍼포먼스 측정 설정 파라미터
sudo fio \
--directory=$TEST_DIR \
--ioengine=psync \
--name fio_test_file \
--direct=1 \
--rw=randwrite \
--bs=16k \
--size=100M \
--numjobs=8 \
--time_based \
--runtime=30m \
--group_reporting \
--norandommap
30분으로 테스트를 진행하였고 3,061 IOPS로 3,000 IOPS 성능 지표를 확인할 수 있었다.