RESOURCES

인생의 많은 부분이 그러하듯이, 선택의 폭이 넓어질수록 결정을 내리는 일은 더 어려워집니다. 클라우드에서 워크로그를 실행하면 몇 가지 의사결정이 더 쉬워지지만, 이것으로는 모든 의사결정을 처리할 순 없습니다. 따라서 클라우드를 위한 최적의 아키텍처를 선택하는 과정이 반드시 필요합니다. 이러한 결정은 사용자에게 가장 적합한 AWS 서비스, 리소스 또는 구성에 더 중점을 둡니다.

 

이제 Amazon FSx for Lustre는 영구 파일 시스템을 갖추고 있으므로, 얼마만큼의 단위당 처리량 설정이 부하에 가장 적합한 지 궁금해 하시는 분들이 많으실 겁니다. 하여 오늘 메가존 테크블로그에서는 Lustre-50 파일 시스템의 FSX가 어떻게 작동하는지를 공유해 드리겠습니다. 본 예제에서는 읽기 및 쓰기 작업을 통해 다른 파일 시스템 구성 요소를 테스트하기 위해 일반적으로 사용되는 파일 시스템 벤치마킹 애플리케이션인 IOR을 사용할 예정입니다. 이를 통해 50개의 영구 파일 시스템이 기존 파일 시스템의 단위당 처리량 값을 훨씬 뛰어 넘고 얼마나 높은 처리량을 달성하는지 깨닫게 되실 겁니다.

 

FSx for Lustre의 영구 파일 시스템에 대해 잘 모르신다면 AWS의 최신 블로그 글을 한번 확인해 주시길 바랍니다.

 

 

파일 시스템 성능 향상의 원리

스크래치 또는 영구 FSx for Lustre 파일 시스템을 생성할 때 파일 시스템의 총 스토리지 용량을 선택해야 합니다. 파일 시스템이 지원할 수 있는 처리량은 스토리지 용량에 비례합니다. 스크래치 배포형 파일 시스템의 경우 단위당 처리량은 스토리지 용량의 TiB당 200MB/s로, 쉽게 결정할 수 없는 스토리지 용량입니다. 영구 배포형 파일 시스템의 경우 스토리지 용량의 TiB당 50MB/s(영구-50), 100MB/s(영구-100) , 200MB/s(persistent-200) 중에서 선택할 수 있습니다. 이러한 각 단위당 처리량 옵션은 가격대가 다르지만 예산 및 성능 요구사항에 가장 적합한 처리량 수준을 선택할 수 있도록 유연성을 제공합니다.

 

파일 시스템의 전체 처리량에 기여하는 구성 요소는 네트워크 처리량, 메모리 내 캐시, 디스크 처리량 이렇게 세가지 입니다.

Amazon FSx for Lustre 사용자 가이드의 performance(성능) 항목에는 모든 배포 유형 파일 시스템에 대한 디스크, 메모리 내 캐시 및 네트워크 처리량을 잘 나타낸 표가 있습니다. 다음(표 1)은 그 중 영구 파일 시스템에 대한 처리량과 캐싱 정보를 보여주는 표입니다..

Network throughput (MB/s per TiB of file system storage provisioned)		Memory for caching (GiB per TiB of file system storage provisioned)	Disk throughput (MB/s per TiB of file system storage provisioned)
	Baseline	Variable		Baseline	Burst
PERSISTENT-50	250	Up to 1300	2.2	50	Up to 240
PERSISTENT-100	500	Up to 1300	4.4	100	Up to 240
PERSISTENT-200	750	Up to 1300	8.8	200	Up to 240

 

표 1 – FSx for Lustre 영구 파일 시스템 성능

 

파일 시스템의 단위당 처리량을 선택하면 해당 파일 시스템에서 사용할 수 있는 기준 디스크 처리량이 선택됩니다. 이는 일반적으로 파일 시스템에서 가장 느리게 수행되는 구성 요소입니다. 버스트 디스크 처리량, 메모리 내 캐시, 파일 시스템의 기준 및 가변 네트워크 성능을 통해 기본 디스크 처리량보다 훨씬 높은 처리 속도로 작동할 수 있습니다. 따라서 실제 선택한 단위당 처리량보다 훨씬 더 많은 처리량에 액세스할 수 있습니다.

 

 

파일 기반 워크로드는 일반적으로 급증하여 짧은 기간 동안 높은 수준의 처리량을 보이지만 장기간에는 낮은 수준의 처리량을 보입니다. 이러한 유형의 워크로드는 FSx for Lustre의 버스트 모델에 적합합니다. 워크로드가 더 일관적일 경우 필요에 맞게 단위당 영구 처리량을 선택하십시오. 이 경우에도 필요할 때 버스트 처리량을 사용할 수 있다는 점을 참고하시기 바랍니다.

 

하지만 여기까지의 정보로는 처리량 수준을 표준 이상으로 끌어올릴 수 있는 작업이 어떻게 무엇인지 일어나는지 알 수 없습니다.

 

 

테스트 실행

그럼 영구-50 파일 시스템이 어떻게 기준을 뛰어 넘어 급증할 수 있는지를 알려드리겠습니다.

첫 번째로 2.4TiB 영구-50 파일 시스템을 만듭니다. 표 1의 값을 기준으로 이러한 영구 파일 시스템에서 사용할 수 있는 처리량 및 메모리 내 캐시는 아래의 표(표 2)와 같습니다.

 

.4-TiB storage capacity	Network throughput (MB/s)		In-memory cache (GiB)	Disk throughput (MB/s)
	Baseline	Variable		Baseline	Burst
PERSISTENT-50	586	3047	5.28	117	563
PERSISTENT-100	1172	3047	10.56	234	563
PERSISTENT-200	1758	3047	21.12	469	563

 

표 2 –  2.4-TiB 파일 시스템의  Sx for Lustre 영구 파일 시스템 성능

 

두 번째로, 최신 Amazon Linux 2 AMI를 사용해 4개의 m5n8xlarge 인스턴스를 만듭니다. 이 인스턴스 유형은 가변성이 없는 네트워크 성능으로 이제 실행할 테스트에 영향을 미치지 않기 때문에 선택하였습니다. EC2 인스턴스에서 파일 시스템에 이르기까지 일관된 네트워크 성능이 필요합니다.

 

 

다음은 사용자 데이터 스크립트의 예입니다. 최신 AWS CLI, Lustre 클라이언트, IOR, 몇 개의 패키지를 설치하고 2.4TiB 영구 파일 시스템을 /fsx로 마운트합니다. 이 스크립트는 파일 시스템의 스트라이프 수 또는 크기를 변경하지 않으므로 모든 테스트에서 기본 Lustre 스트라이프 구성인 1개의 스트라이프와 1,048,576바이트의 스트라이프 크기를 사용합니다.

 

 

#cloud-config

repo_update: true

repo_upgrade: all

 

runcmd:

– curl “https://s3.amazonaws.com/aws-cli/awscli-bundle.zip” -o “awscli-bundle.zip”

– unzip awscli-bundle.zip

– ./awscli-bundle/install -i /usr/local/aws -b /usr/local/bin/aws

– sudo export PATH=/usr/local/bin:$PATH

 

– amazon-linux-extras install -y epel lustre2.10

– yum groupinstall -y “Development Tools”

– yum install -y fpart parallel tree nload git libaio-devel openmpi openmpi-devel

 

– cd /home/ec2-user

– git clone https://github.com/hpc/ior.git

– export PATH=$PATH:/usr/lib64/openmpi/bin

– export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib64/openmpi/lib/

– cd ior

– ./bootstrap

– ./configure

– make

– sudo cp src/ior /usr/local/bin

– cd /home/ec2-user

 

– filesystem_id=

– mount_point=/fsx

– availability_zone=$(curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone)

– region=${availability_zone:0:-1}

– mount_name=$(aws fsx describe-file-systems –file-system-ids ${filesystem_id} –query ‘FileSystems[*].LustreConfiguration.MountName’ –output text –region ${region})

– mkdir -p ${mount_point}

– echo “${filesystem_id}.fsx.${region}.amazonaws.com:/${mount_name} ${mount_point} lustre defaults,noatime,flock,_netdev 0 0” >> /etc/fstab

– mount -a -t lustre

– chown ec2-user:ec2-user ${mount_point}

 

세 번째로, 4개의 인스턴스에서 모두 512 GiB의 데이터를 영구-50 파일 시스템에 병렬로 연속적으로 쓰는 IOR 스크립트를 실행합니다. 다음은 IOR 쓰기 스크립트의 예입니다. 클라이언트 EC2 인스턴스의 캐시를 무시하고 인스턴스당 8개의 쓰레드를 사용합니다.

 

# IOR – write test

instance_id=$(curl -s http://169.254.169.254/latest/meta-data/instance-id)

mpirun –npernode 8 –oversubscribe ior –posix.odirect -t 1m -b 1m -s 16384 -g -v -w -i 100 -F -k -D 0 -o /fsx/ior-${instance_id}.bin

 

아래의 스크린 샷은 Amazon CloudWatch 파일 시스템의 총 처리량을 그래프로 보여 줍니다. 짧은 시간 동안 IOR 쓰기 테스트는 파일 시스템의 버스트 및 가변 처리량을 사용하며 전체 처리량은 일관적인 604MB/s입니다. 나머지 테스트의 경우 기본 처리량이 117MB/s인 persistent-50 파일 시스템에서 149MB/s를 얻습니다. 위의 표 2를 참조하여 이론적 숫자와 비교해 결과를 확인합니다.

 

 

네 번째로, 버스트 크레딧이 보충되기를 기다리는 대신 방금 테스트한 것과 동일한 2.4TiB 영구-50 파일 시스템을 새로 만들어 4개의 EC2 인스턴스에 모두 마운트합니다. 5분 남짓 소요되므로 금방 다음 테스트로 넘어갈 수 있습니다. 한 인스턴스에서 총 64 GiB의 데이터를 8개의 8-GiB 파일로 생성하는 IOR 스크립트를 실행합니다. 그런 다음 4개의 인스턴스 모두 인스턴스당 8개의 스레드를 사용하여 이러한 파일에서 지속적으로 읽는 IOR 스크립트를 실행합니다. 다음은 IOR 스크립트의 예입니다.

 

# IOR – write test from one instance

mpirun –npernode 8 –oversubscribe ior –posix.odirect -t 1m -b 1m -s 8192 -g -v -w -i 1 -F -k -D 0 -o /fsx/ior.bin

 

# IOR – read test from all instances

mpirun –npernode 8 –oversubscribe ior –posix.odirect -t 1m -b 1m -s 8192 -g -r -i 10000 -F -k -D 60 -o /fsx/ior.bin

 

다음 그래프는 이 읽기 테스트의 총 처리량을 보여 줍니다. 다시 말씀드리자면, 짧은 시간 동안 IOR 읽기 테스트는 파일 시스템의 버스트 및 가변 처리량을 사용하며, 처리량은 638MB/s로 일관됩니다. 테스트의 나머지 기간 동안 기본 처리량이 117MB/s인 영구-50 파일 시스템에서 153MB/s를 얻습니다. 위의 표 2를 참조하여 이 결과가 이론적 숫자와 어떻게 비교되는지 확인해 보십시오.

 

 

다섯 번째로, 다시 한 번 새로운 2.4-TiB 파일 시스템을 생성하여 전체 버스트 기능으로 시작합니다. 파일 시스템의 네트워크 성능만 테스트하여 IOR를 사용하여 메모리 내 캐시에 완전히 상주할 수 있는 데이터 집합을 만듭니다. 한 EC2 인스턴스에서 총 5.28 GiB의 데이터를 포함하는 675-MiB 파일 8개를 생성합니다. 그런 다음 4개의 인스턴스 모두에서 인스턴스당 8개의 스레드를 사용하여 이러한 파일에서 읽는 IOR 스크립트를 실행합니다. 이 스크립트를 포함한 모든 IOR 스크립트는 posix.odirect 플래그를 사용하여 EC2 인스턴스의 로컬 캐시를 바이패스합니다. 따라서 모든 I/O 요청이 파일 시스템에서 네트워크를 통해 전송됩니다. 다음은 IOR 스크립트의 예입니다.

 

# IOR – write test from one instance

mpirun –npernode 8 –oversubscribe ior –posix.odirect -t 1m -b 1m -s 675 -g -v -w -i 1 -F -k -D 0 -o /fsx/ior.bin

 

# IOR – read test from all instances

mpirun –npernode 8 –oversubscribe ior –posix.odirect -t 1m -b 1m -g -r -i 2000000 -F -k -D 0 -z -o /fsx/ior.bin

 

결과는 놀라웠습니다.

파일 시스템은 짧은 시간 동안 일관된 3170MB/s의 가변 네트워크 처리량을 제공했고, 그 후 625MB/s의 기본 네트워크 처리량을 지속적으로 제공했습니다.

 

워크로드가 캐싱용으로 지정된 메모리보다 훨씬 클 수 있습니다. 그러나 워크로드의 일부는 이 메모리 내 캐시와 이러한 파일 시스템의 높은 가변적 네트워크 처리량을 활용할 수 있어야 합니다.

 

 

 

결과 분석

스토리지 용량이 TiB당 50MB/s로 제한되지 않도록 하십시오. 이러한 영구 50 파일 시스템은 놀라운 효과를 제공할 수 있습니다. 이러한 테스트의 결과는 쓰기, 읽기, 인메모리 캐시 읽기 테스트에서 파일 시스템의 단위 처리량보다 각각 5.15배, 5.44배, 27.05배 빠르게 파일 시스템을 버스트할 수 있었다는 것을 보여줍니다. 버스트하지 않는 수치도 27.34%, 30.77%, 434.19%로 쓰기, 읽기 및 메모리 내 캐시 읽기 테스트의 단위 처리량 기준치보다 상당히 높았습니다.

 

파일 시스템 처리량은 파일 시스템의 스토리지 용량에 비례하므로 일반적으로 필요한 총 스토리지 용량 또는 스토리지 처리량 단위당 다른 용량에 따라 필요한 총 처리량 중 큰 값을 기준으로 파일 시스템의 크기를 조정할 것을 권장합니다. POC 환경에서 작업량을 테스트하여 영구-50 파일 시스템을 사용해 실행할 수 있는지 확인하십시오. I/O 패턴에 따라 실제로 얻는 처리량은 파일 시스템을 생성할 때 선택하는 처리량보다 훨씬 클 수 있다는 점을 알아두시기 바랍니다.

 

 

 

글을 마치며…

다음번에는 FSx for Lustre 파일 시스템을 생성한 후 포인터를 스토리지 라디오 버튼 단위당 처리량 앞 뒤로 이동해 보시고, 영구 50 파일 시스템을 사용하여 계산하고 테스트해 보십시오. 아마 깜짝 놀라실 겁니다.

이러한 테스트 진행을 영상을 통해 확인하시려면 FSx Lustre FSx Lustre Resources 페이지의 “Amazon FSx for Lustre: Persistent Storage Overview” 영상을 시청해 주십시오. Amazon FSx for Lustre의 영구 파일 시스템에 대한 추가 정보를 확인하고 싶으시다면 Amazon FSx for Lustre의 웹 사이트를 방문하시거나 사용 설명서를 참고해 주시기 바랍니다.

원문URL : https://aws.amazon.com/ko/blogs/storage/persistent-50-packs-a-punch/

** 메가존 클라우드 TechBlog는 AWS BLOG 영문 게재 글 중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아서, 정기적으로 게재하고 있습니다. 추가로 번역 및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS 페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달해드리도록 하겠습니다.