안녕하세요. MANVSCLOUD 김수현입니다.
클라우드를 사용하다보면 데이터의 확장성과 유연성을 극대화할 수 있는 여러 서비스를 경험하게 됩니다. 우리는 서버를 운영할 때 스토리지 사용량을 Cloud Insight 설정을 통해 모니터링 알림을 받고 수동으로 정리할 파일이 있는지 서버에 접속하여 확인합니다.
정리할 파일이 없다면 스토리지 확장 작업을 진행하는 것이 일반적입니다.
하지만 정리할 파일이 없이 데이터가 지속적으로 쌓이는 구조에서는 이런 수동적인 작업이 번거로울 뿐만 아니라 모니터링 알림을 놓치는 경우 서비스 장애로 이어질 수 있습니다.
이 글에서는 추가로 연결한 볼륨에 대해 자동으로 Block Storage와 서버 내 파티션까지 확장하고 알림을 받을 수 있는 방법을 공유하고자 합니다. 이 포스팅을 통해 스토리지 관리 영역까지 자동화하여 더 이상 수동 작업에 시간을 낭비하지 않길 바랍니다.
Hands On Lab
간단하게 Hands On 형식으로 큰 흐름을 설명하고자 합니다.
만약 환경이 다르다면 환경에 맞고 어느정도 수정하거나 응용하면 되겠습니다.
- Hands On 환경
OS : Ubuntu 22.04
Hypervisor : KVM
root@ubuntu-storage:~# parted GNU Parted 3.4 Using /dev/vdb Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) print Model: Virtio Block Device (virtblk) Disk /dev/vdb: 1503GB Sector size (logical/physical): 512B/512B Partition Table: loop Disk Flags: Number Start End Size File system Flags 1 0.00B 1503GB 1503GB ext4
먼저 제가 준비한 환경은 Ubuntu 환경이며 서버의 Hypervisor는 KVM입니다.
또한 KVM Hypervisor에서 사용되는 추가 스토리지는 2TB를 초과하여 16TB까지 지원하기때문에 parted 명령어를 이용하여 Disklabel type을 gpt로 설정한 케이스입니다.
parted 및 mkfs, mount까지의 과정은 구글링을 진행하면 너무나도 자료가 잘 나와있고 아주 기본적인 내용이므로 이 포스팅에서는 생략하도록 하겠습니다.
따라서 이 Hands On Lab에서는 아래와 같이 구성되어 /dev/vdb의 사이즈를 자동 확장하는 과정을 보여줄 것입니다.
root@ubuntu-storage:~# df -h /dev/vdb Filesystem Size Used Avail Use% Mounted on /dev/vdb 1.4T 1001G 311G 77% /test
- NCLOUD CLI
NCLOUD CLI 다운로드 : https://cli.ncloud-docs.com/docs/guide-clichange
사전에 CLI가 설치되어 있어야하며, CLI가 잘 작동되도록 미리 세팅을 해두어야합니다.
아래는 CLI 설치 및 셋팅 예시입니다.
cd /root wget -O CLI.zip https://www.ncloud.com/api/support/download/files/cli/CLI_1.1.19_20240321.zip unzip CLI.zip mv CLI_* CLI sed -i 's#./jre8/bin/java#/root/CLI/cli_linux/jre8/bin/java#g' /root/CLI/cli_linux/ncloud sed -i 's#./lib/ncloud-api-cli-1.1.19-SNAPSHOT-jar-with-dependencies.jar#/root/CLI/cli_linux/lib/ncloud-api-cli-1.1.19-SNAPSHOT-jar-with-dependencies.jar#g' /root/CLI/cli_linux/ncloud ln -s /root/CLI/cli_linux/ncloud /usr/bin/ncloud
- Sub Account – Roles

우리가 파티션 확장을 하기 위해서는 앞서 네이버 클라우드 콘솔에 접속하여 서버에 연결된 추가 스토리지에 대해서 스토리지 용량을 확장해주는 작업이 진행됩니다. CLI를 설치한 이유가 이 부분을 자동화하기 위함이라 스토리지 확장에 대한 권한을 가지고 있어야합니다.
Sub Account의 Roles를 사용한다면 Access Key를 굳이 사용할 필요가 없으므로 Roles을 생성하고 [역할 적용 대상]에 서버를 추가해준 뒤 [정책]에서 Block Storage 용량을 수정할 수 있는 권한을 부여합니다.

- Shell Script
제가 사용한 Shell Script 예시는 아래와 같습니다.
- 스토리지 사용률 확인: 먼저
df -h /dev/vdb명령어를 사용하여/dev/vdb볼륨의 사용률을 확인합니다. 사용률이 80%를 초과하는 경우 스토리지 확장 절차를 시작합니다. - 인스턴스 정보와 스토리지 정보 확인: 스크립트는 메타 데이터를 통해 서버의
instanceNo를 얻고ncloud cli를 사용하여 해당 서버에 마운트된 Block Storage의 정보를 확인합니다. 이를 통해 Block Storage Number와 현재 크기를 얻습니다. - 스토리지 확장: 확인된 정보를 바탕으로 사전에 정의된
Add_Capacity값만큼 스토리지의 용량을 늘립니다. 이후 시스템이 변경을 인식할 수 있도록 10초간 대기합니다. - 파티션 확장:
resize2fs명령어를 사용하여 파일 시스템의 크기를 조정합니다. 이 작업은 스토리지의 물리적 확장 후 실제 사용 가능한 공간을 늘리기 위해 필요합니다. 추가로 30초간 대기한 후 다시/dev/vdb의 사용률을 확인합니다. - 결과 알림: 최종 사용률이 80% 미만이 되었다면 성공적으로 확장된 것으로 간주하고 이를 Slack을 통해 알림으로 전송합니다. 만약 80% 이상을 유지한다면 자동 증설에 실패했음을 알리는 메시지를 보냅니다.
#!/bin/bash
#####################################################################################################
VDB="/dev/vdb"
webhook_url='SLACK_WEBHOOK_URL'
Add_Capacity=100
#####################################################################################################
hostname=$(hostname)
usage=$(df -h $VDB | awk 'NR==2 {print $5}' | sed 's/%//')
if [ "$usage" -ge 80 ]; then
echo "Disk usage is $usage%, which is above 80%. Proceeding with storage expansion."
InstanceNo=$(curl http://169.254.169.254/latest/meta-data/serverInstanceNo)
blockStorageInfo=$(ncloud vserver getBlockStorageInstanceList | jq -r --arg InstanceNo "$InstanceNo" --arg VDB "$VDB" '
.getBlockStorageInstanceListResponse.blockStorageInstanceList[] |
select(.serverInstanceNo == $InstanceNo and .deviceName == $VDB) |
{blockStorageInstanceNo, blockStorageSize: (.blockStorageSize / (1024 * 1024 * 1024))}
')
blockStorageInstanceNo=$(echo "$blockStorageInfo" | jq -r '.blockStorageInstanceNo')
blockStorageSize=$(echo "$blockStorageInfo" | jq -r '.blockStorageSize')
NewblockStorageSize=$(echo "$blockStorageSize + $Add_Capacity" | bc)
ncloud vserver changeBlockStorageInstance --blockStorageInstanceNo $blockStorageInstanceNo --blockStorageSize $NewblockStorageSize
sleep 10
resize2fs $VDB
sleep 30
new_usage=$(df -h $VDB | awk 'NR==2 {print $5}' | sed 's/%//')
if [ "$new_usage" -ge 80 ]; then
message="디스크 자동 증설에 실패하였습니다."
else
message="$hostname의 $VDB 파티션이 $blockStorageSize(GB)에서 $NewblockStorageSize(GB)으로 자동 증설이 정상적으로 완료되었습니다."
fi
curl -X POST -H 'Content-type: application/json' --data "{\"text\":\"${message}\"}" $webhook_url
fi
이 스크립트를 정상적으로 실행하기 위해 jq가 사전에 설치되어 있어야합니다.
ex) apt install jq
또한 아래 변수들은 사전에 변경하고 사용할 수 있습니다.
VDB=”/dev/vdb” // 자동 증설이 필요한 파티션
webhook_url=’SLACK_WEBHOOK_URL’ // 알림을 받을 Slack WebHook URL
Add_Capacity=100 // 자동 증설되기 원하는 용량(GB)

Personal Comments
지금까지 스토리지 자동 확장 방법을 공유드렸습니다. 자동화를 통해 서버의 용량 관리를 보다 효율적으로 수행할 수 있으며, 데이터 증가에 따른 서비스 장애를 예방할 수 있습니다. 하지만 이러한 자동화 접근법을 적용하기 전에 몇 가지 중요한 사항을 고려해야 합니다.
자동 확장은 유용하지만 볼륨을 축소할 때는 주의해야 합니다. 파일 시스템과 블록 스토리지의 데이터 저장 방식을 이해하면 왜 축소가 위험한지 명확해집니다. 데이터는 파일 시스템 내에서 블록 단위로 저장됩니다. 각 블록은 하나 이상의 섹터로 구성되며 파일은 하나 또는 여러 블록에 걸쳐 저장됩니다. 볼륨을 축소할 때 사용 중인 데이터 블록이 잘못 삭제될 위험이 있으며 이는 파일의 일부 또는 전체 데이터 손실로 이어질 수 있습니다. 따라서 자동 확장을 적용하기 전에 이미 늘어난 볼륨을 비용으로 이어지고 다시 볼륨을 축소하는 것은 리스크로 이어질 수 있으므로 현재 환경이 이러한 자동화에 적합한지 판단하는 것이 중요합니다.
또한 이를 적용한다고 하더라도 운영 서버에 바로 적용하기 전에 별도의 테스트 서버를 생성하여 더미 파일을 이용한 확장 테스트를 충분히 진행해보시는 것을 권장합니다.
긴 글 읽어주셔서 감사합니다.
