[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을 시키기에 그렇다고 한다.

https://stackoverflow.com/questions/12102551/ec2-ebs-device-id-confusion-dev-sdf-vs-dev-xvdf

 

/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

 

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

 

아래 설정값은 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초 벤치마킹 테스트 결과

 

짧게 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 성능 지표를 확인할 수 있었다.

---

Reference

• https://docs.aws.amazon.com/ko_kr/cli/latest/userguide/cli-usage-filter.html
• https://cloud.google.com/compute/docs/disks/benchmarking-pd-performance?hl=ko