AWS가 제공하는 완전관리형 병렬 파일시스템, Amazon FSx for Lustre – 2

이전 블로그에서는 병렬 파일시스템의 기본 개념과 특징 그리고 대표적인 병렬 파일시스템인 Lustre에 대해 살펴보았습니다. 또한 AWS에서 제공하는 완전 관리형 Lustre 파일시스템인 Amazon FSx for Lustre에 대해서도 알아보았습니다.

• 병렬 파일시스템은 무엇이고 왜 필요할까?
• 지구상에서 가장 인기있는 병렬 파일시스템, Lustre 파일시스템 알아보기
• AWS가 제공하는 완전 관리형 병렬 파일시스템, Amazon FSx for Lustre – 1

이번 블로그는 시리즈의 마지막으로, Amazon FSx for Lustre에서 선택할 수 있는 스토리지 미디어 옵션, 데이터 압축을 통한 성능 및 비용 개선, Amazon S3와의 통합, AWS Re:Invent 2024를 통해 소개된 신규 기능, 모니터링 방법 등에 소개하도록 합니다.

Amazon FSx for Lustre디스크 옵션

Amazon FSx for Lustre는 그림1과 같이 총 4가지 디스크 미디어 옵션을 제공합니다. 따라서 사용자는 비용 효율적으로 파일시스템을 구성할 수 있습니다.

<그림 1. Amazon FSx for Lustre의 디스크 옵션>

그림2에서는 스루풋(throughput, 처리량) 옵션에 따른 월별 GB당 비용이 표기되어 있습니다. 절대적인 비용 관점에서는 스루풋이 높을수록 높은 비용을 지불해야 하나, 가성비 관점에서 살펴본다면 오히려 스루풋이 높을수록 가장 좋은 선택이 될 수 있다는 것을 기억할 필요가 있습니다. 따라서 성능보다는 절대적 비용이 중요한 사용자에게는 낮은 스루풋을 제공하는 HDD 옵션이 최적의 선택이며, 가성비가 중요한 사용자에게는 1,000MBps 스루풋을 지니는 퍼시스턴트2 모드의 SSD 디스크 선택을 추천합니다.

<그림 2. Amazon FSx for Lustre 스루풋에 따른 비용>

프로젝트 초기 단계에서는 정확한 스토리지 요구사항과 성능 수준을 예측하기가 어렵습니다. 따라서 테스트 단계에서는 최고 성능인 테라 바이트당 1,000MB/초의 스루풋으로 시작할 수 있습니다. 실제 운영 환경에서 이러한 고성능이 불필요하다고 판단되면, 스루풋 스케일링 기능을 활용하여 테라 바이트당 1,000MB/초에서 500MB/초 또는 250MB/초 등으로 성능을 조절할 수 있습니다. 반대로 낮은 스루풋으로 시작하여 필요에 따라 점진적으로 성능을 높이는 것도 가능합니다. 다만, 스토리지 용량의 경우에는 증설만 가능하고 축소는 불가능하다는 점에 유의해야 합니다

데이터 압축을 이용한 비용 절감 및 성능 개선

Amazon FSx for Lustre에서 제공하는 데이터 압축 기능은 스토리지 비용 절감을 위한 효과적인 옵션입니다. 이 기능은 LZ4 알고리즘을 사용하여 파일 시스템 성능에 영향을 주지 않으면서도 높은 수준의 압축률을 제공합니다. 압축된 데이터는 디스크에 쓰기 전에 자동으로 압축되고 읽을 때 자동으로 압축이 해제되며, 특히 파일 서버와 스토리지 간 전송되는 데이터양을 줄여 전체 파일 시스템 처리량을 향상시킬 수 있습니다. 무료로 제공되는 이 기능은 비용 효율성과 성능을 모두 고려하는 워크로드에 적합한 선택입니다.

<그림 3. 워크로드에 따른 Amazon FSx for Lustre 데이터 압축률>

실제로 AWS에서 직접 수행한 테스트에 따르면, 분산 컴퓨팅 환경에서 고성능 분석을 제공하는 SAS Grid의 경우 아스키(ascii)코드 테스트 파일에서 약 60~80%의 압축이 발생하기 때문에 많은 비용 절감을 얻을 수 있습니다. 반도체 EDA 워크로드의 경우에도 약 50%의 압축률을 보입니다. 그림3의 오른쪽에 있는 워크로드의 경우는 상대적으로 압축률이 떨어지는데, 이러한 이유는 이미 압축된 파일에 대해서 압축을 진행하였기 때문입니다.

그림4에서는 데이터 압축에 따른 디스크 스루풋 상승 효과를 보여주고 있습니다. 이 때 파일 서버에서 데이터를 압축한 후 디스크에 저장하기 때문에, 압축을 위해 클라이언트의 컴퓨팅 리소스를 사용하지 않는다는 점을 기억할 필요가 있습니다. 그림에서 이 서버의 네트워크 대역폭이 640MB/s 이고 디스크 스루풋은 250MB/s라 가정하겠습니다. 이 경우 클라이언트가 디스크 스토리지에 접근한다면, 직전 블로그에서 언급한 것처럼 파일시스템의 전체 스루풋은 min{네트워크 스루풋, 디스크 스루풋}에 의해 디스크 스루풋에 의존적입니다. 그러나 이 때 압축 기능을 켜서 만약 압축 비율을 2:1로 만든다면, 여전히 전체 파일시스템의 성능은 디스크 스루풋에 결정되나 디스크 스루풋은 500MB/s로 변경되어 파일시스템의 전체 스루풋은 2배가 증가됩니다. 즉, 디스크 스루풋이 압축에 의해 두배로 증가하게 됩니다.

<그림 4. 데이터 압축에 따른 디스크 스루풋 상승 효과>

파일 스트라이핑(striping) 정책

지난 블로그에서 Lustre 파일시스템의 스트라이핑 정책에 대해 설명하였습니다. 스트라이핑은 Lustre 파일시스템의 성능을 결정짓는 매우 중요한 요소 중에 하나입니다. 현재 Amazon FSx for Lustre의 스트라이핑 정책은 파일 크기에 따라 다르게 적용되며, 특히 2023년 8월 25일 이후 생성된 파일시스템에서는 4단계 진행형 파일 레이아웃(Progressive File Layout, PFL)을 기본값으로 사용합니다.

파일 크기 별 스트라이프 카운트(데이터 저장에 사용되는OST의 개수) 정책은 다음과 같습니다.

• 100MiB 미만: 스트라이프 카운트 1
• 100MiB ~ 10GiB: 스트라이프 카운트 8
• 10GiB ~ 100GiB: 스트라이프 카운트 16
• 100GiB 초과: 스트라이프 카운트 32

이 스트라이핑 정책은 자동으로 결정되기 때문에 이 정책을 직접 변경하는 것은 불가능합니다. 다만 ‘lfs setstripe’명령을 사용하여 개별 파일이나 디렉터리에 대해 특정 스트라이프 카운트를 지정할 수 있습니다.

스트라이프 크기는 파일시스템을 처음 생성할 때 지정할 수 있습니다. 기본 스트라이프 크기는 1 MiB 입니다. 이미 생성된 파일시스템의 스트라이프 크기 변경은 불가능합니다. 그럼에도 불구하고 스트라이프 크기를 변경하고 싶다면, 원하는 스트라이프 크기로 새로운 파일시스템을 생성한 후 데이터를 마이그레이션해야 합니다. 이 때 마이그레이션 된 데이터들은 새 파일시스템에서 정의된 스트라이프 크기와 레이아웃을 따르게 됩니다. 

데이터 레이크인 Amazon S3와의 긴밀한 통합

지난 블로그에서 언급한 바와 같이, Amazon FSx for Lustre의 가장 큰 특징 중에 하나가 바로 AWS의 오브젝트 스토리지인 Amazon S3와의 연동입니다. AWS 클라우드 환경에서는 기본적으로 Amazon S3가 데이터 레이크로 사용되기 때문에, 많은 AWS 클라우드 사용자들이 Amazon FSx for Lustre 서비스가 런치되기 전부터 이미 Amazon S3에 데이터를 보관해오고 있습니다. 따라서 Amazon S3에 저장된 데이터를 자연스럽게 고성능 파일시스템인 Amazon FSx for Lustre 연결하여 분석할 수 있습니다.

<그림 5. Amazon S3에 저장된 데이터를 Amazon FSx for Lustre를 이용하여 분석>

 Amazon FSx for Lustre는 한 개 이상의 Amazon S3 버킷과 연동이 가능하며, 파일시스템의 구성이 완료되면 이와 연동되는 버킷에 존재하는 오브젝트들의 메타데이터를 자동으로 파일시스템으로 가져오게 됩니다. 즉 파일시스템과 연동되는Amazon S3 버킷 내의 오브젝트들이 파일시스템내에서 일반 파일처럼 표시됩니다. 그림6에서 file1/2/3/4.text 라는 4개의 오브젝트는, 파일시스템에서 메타데이터 형태로 모두 확인이 가능합니다.

즉, 실제 데이터는 아직까지 Amazon S3에 저장되어 있으며, lazy load 기능을 이용하여 실제 특정 데이터에 대한 요청이 있을 경우에만 선택적으로 파일시스템으로 전송합니다. 따라서 파일시스템내의 데이터 양을 최소화 시키게 됩니다. 분산 트레이닝이나 엔지니어링 시뮬레이션과 같이 대량의 데이터를 처리 및 분석해야 하는 경우, 대량의 데이터를 모두 파일시스템에 적재할 필요가 사라지기 때문에 이러한 lazy load 기능을 통해 작업 시간을 단축시킬 수 있으며 비용 절감이 가능해 집니다.

<그림 6. Amazon FSx for Lustre와 Amazon S3의 연동>

lazy load 기능을 이용할 경우 파일에 처음 접근할 때 Amazon S3에서 데이터를 가져오는 방식인 반면, pre load 기능을 사용하면 사용자가 필요한 파일이나 디렉토리를 미리 로드할 수 있어 초기 접근 시의 지연 시간을 제거할 수 있습니다. 이 기능은 지연 시간에 민감한 애플리케이션을 실행하거나 성능 최적화가 요구되는 경우 사용할 수 있습니다.

또한 특정 버킷 내에 파일 추가와 같은 업데이트가 발생하는 경우에도 자동으로, 연동되는 파일시스템에 반영됩니다. 또한 반대로, 파일시스템의 파일에 대한 업데이트가 발생하는 경우에도, 자동 내보내기 및 수동 동기화 옵션을 통해 변경 사항을 연동되는 Amazon S3 버킷에 내보내기가 가능합니다. 그림6에서 관련된 내용을 확인할 수 있습니다.

AWS Re:Invent 2024를 통해 소개된 Amazon FSx for Lustre 신규 기능

성능에 초점이 맞춰진 파일시스템 답게, 2024 Re:Invent에서도 성능 관점에서 크게 2가지 기능이 추가되었습니다.

우선 Elastic Fabric Adapter (EFA)를 지원하는 Amazon FSx for Lustre 퍼시스턴트2 파일 시스템을 생성할 수 있게 되었습니다. 이를 통해 EFA를 지원하는 클라이언트 인스턴스의 네트워크 성능이 향상되었습니다. Amazon FSx for Lustre에서 이 기능이 도입되기 전에는 기존 TCP 네트워킹만 사용 가능했기 때문에, 개별 클라이언트 인스턴스의 스루풋은 100Gbps로 제한되었습니다. 그러나 EFA 기능이 도입됨으로써 그림7과 같이 단일 클라이언트에서 최대 700 Gbps의 네트워크 대역폭을 달성할 수 있게 되었으며, 여러 클라이언트로 확장할 경우 성능이 기하급수적으로 증가하게 됩니다.

<그림 7. EFA 및 GDS 기능 추가로 인한 Amazon FSx for Lustre 대역폭의 획기적 향상>

또한 EFA를 기반으로 그림8과 같이 파일시스템과 클라이언트인 EC2 인스턴스 GPU 메모리 간의 직접적인 데이터 전송을 가능하게 하는 기술인 GPU Direct Storage(GDS) 기능이 새로 출시되었습니다. 이를 통해 P5 GPU 인스턴스와 NVIDIA CUDA를 사용할 경우, 최대 1,200Gbps의 스루풋을 제공할 수 있게 됩니다. 참고로 기존의 경우에는 그림8과 같이, 왼쪽의 파일시스템에서 오른쪽의 호스트 메모리(CPU RAM)로 첫번째 데이터 복사가 이루어진 후, 다시 호스트 메모리에서 GPU 메모리로 복사가 이루어졌습니다.

<그림 8. GPU Direct Storage 개념>

두번째로 Amazon FSx for Lustre의 메타데이터 IOPS 관리 방식이 크게 개선되었습니다. Amazon FSx for Lustre에서의 메타데이터란, 파일 생성, 파일 삭제, 디렉토리 내용 나열, 권한 얻기 등을 위해 사용되는 데이터를 의미합니다. 이제 스토리지 용량과 독립적으로 메타데이터 IOPS를 프로비저닝할 수 있으며, 기존 대비 최대 15배까지 증가시킬 수 있게 되었습니다. 이전에는 대부분의 Lustre 파일 시스템 사용 사례에서 메타데이터 IOPS가 전체 시스템 성능에 큰 영향을 미치지 않았기 때문에, Amazon FSx for Lustre의 메타데이터 IOPS는 스토리지 용량에 따라 자동으로 결정되었습니다. 하지만 최근에는 소규모 파일을 다루는 워크로드가 증가하면서 메타데이터 성능이 중요한 사용 사례가 늘어나고 있습니다. 이러한 변화에 대응하여 새로운 메타데이터 IOPS 관리 방식이 도입되었습니다. 기존의 스토리지 용량에 따라 메타데이터 IOPS가 자동으로 조정되는 자동 모드 방식을 유지하는 것도 가능하며, 새롭게 추가된 사용자 프로비저닝 모드에서는 사용자가 직접 메타데이터 IOPS를 지정할 수 있습니다. 특히 사용자 프로비저닝 모드는 메타데이터 성능이 중요한 워크로드에서 전체 파일 시스템의 성능을 크게 향상시킬 수 있는 유용한 기능입니다. 

Amazon FSx for Lustre의 모니터링

Amazon FSx for Lustre의 모니터링은 여러 AWS 서비스를 통해 종합적으로 수행할 수 있습니다. 대표적으로 Amazon CloudWatch를 통해 파일 시스템의 주요 메트릭(metric)을 모니터링할 수 있으며, 이는 네트워크 I/O, 스토리지 서버 성능, 메타데이터 작업, 스토리지 용량 등을 포함합니다. 6가지의 다양한 상세 지표를 이용하여 좀 더 세밀한 모니터링이 가능하며, 1분 간격으로 Amazon FSx for Lustre가 지표 데이터를 Amazon CloudWatch로 전송합니다. 단 추가 비용이 발생할 수 있습니다.

Amazon CloudWatch를 이용한 모니터링의 주요 메트릭 카테고리는 다음과 같습니다.

• 네트워크 I/O 메트릭: 클라이언트와 파일 시스템 간의 활동 측정
• 오브젝트 스토리지 서버 메트릭: OSS 네트워크 처리량 및 디스크 처리량 활용도 측정
• 오브젝트 스토리지 타겟 메트릭: OST 디스크 처리량 및 IOPS 활용도 측정
• 메타데이터 메트릭: MDS CPU 사용률, MDT IOPS 사용률 및 클라이언트 메타데이터 작업 측정
• 스토리지 용량 메트릭: 스토리지 용량 활용도 측정
• S3 데이터 리포지토리 메트릭: 가져오기 및 내보내기 대기 중인 메시지의 보존 기간 측정

두번째로 Amazon FSx for Lustre의 콘솔에서 파일 시스템 대시보드의 ‘모니터링 및 성능’ 패널에서 직접 성능 지표를 확인할 수 있습니다. 특히 파일 시스템의 건강 상태와 성능을 실시간으로 확인할 수 있으며, 이는 추가 비용 없이 모든 AWS 상업용 리전에서 사용 가능합니다. 단 제한된 대시보드 커스터마이징만 가능합니다. 그림9는 Amazon FSx for Lustre의 콘솔에서 특정 파일시스템의 성능 모니터링에 대한 요약 화면을 보여주고 있습니다.

<그림 9. Amazon FSx for Lustre 콘솔 화면에서의 특정 파일시스템에 대한 모니터링 Summary>

Amazon FSx for Lustre를 사용하는 방법

Amazon FSx for Lustre를 사용하는 방법은 여러 가지가 존재합니다. 첫번째로 HPC 클러스터 구성 요소로서 Amazon FSx for Lustre를 사용하고자 한다면, 기본적으로 AWS ParallelCluster 사용을 적극 추천합니다. AWS ParallelCluster를 통해 편리하게 스토리지 배포 및 관리가 가능합니다. 아래 YAML 기반의 코드에서는 AWS ParallelCluster를 이용하여 퍼시스턴트2 모드, 스루풋은 1,000 MB/s/TiB, 스토리지 용량은 7.2 TiB를 갖는 Lustre파일시스템을 구성한 샘플 코드를 보여주고 있습니다. 이 코드에서는 파일시스템이 Amazon S3의 특정 버킷인 sangman 버킷과 연동되는 것도 확인할 수 있습니다.

SharedStorage:
  - MountDir: /fsx
    Name: fsxlustre
    StorageType: FsxLustre
    FsxLustreSettings:
      StorageCapacity: 7200
      DeploymentType: PERSISTENT_2
      StorageType: SSD
      PerUnitStorageThroughput: 1000  # 최대 처리량으로 설정
      DataRepositoryAssociation:
        AutoImportPolicy: NEW
        ImportPath: s3://sangman
        ExportPath: s3://sangman

이외에도 AWS 콘솔을 통해 직접 생성하는 것도 가능하며, AWS CLI , AWS CloudFormation, Terraform 등을 통해 생성하는 것도 가능합니다. 단 개별 방법은 사용 환경과 요구사항에 따라 선택할 수 있으며, 자동화나 인프라 관리 방식에 따라 적절한 방법을 선택하면 됩니다.

Amazon FSx for Lustre의 제약 사항

마지막으로 Amazon FSx for Lustre의 제약 사항에 대해 알아보도록 하겠습니다. 다음과 같은 몇 가지 주의 사항들이 존재합니다.

운영 체제 제약: 리눅스 환경에서만 사용 가능합니다. 클라이언트의 OS가 윈도우라면 기본적으로 사용이 불가합니다. 다만 지난 블로그에서 언급되었던 전문 MSP(Managed Service Provider)의 도움을 받을 경우, 별도의 중간 게이트웨이 구축을 통해 윈도우 OS에서도 사용 가능합니다.

스토리지 용량 제약: 스토리지 용량을 임의로 설정하는 것이 불가능합니다. SSD 기반 파일시스템의 경우 최소 1.2TiB부터 시작하며 2.4TiB 단위로만 증가가 가능합니다. HDD 기반 파일시스템의 경우 최소 6TiB부터 시작해야 합니다.

가용성 제약: 단일 AZ에서만 배포가 가능하기 때문에 여러 가용영역에 걸친 배포는 불가능합니다.

맺음말

병렬 파일시스템과 Lustre는 고도의 전문성이 요구되는 복잡한 스토리지 기술입니다. 지금까지 4회에 걸쳐 병렬 파일시스템의 개념부터 AWS가 제공하는 완전 관리형 병렬파일시스템인 Amazon FSx for Lustre에 대해 소개하였습니다. AWS 환경에서 분산 트레이닝이나 엔지니어링 시뮬레이션을 수행할 때, 대부분의 사용자들은 성능이 뛰어나다는 이야기를 듣고 단순히 Amazon FSx for Lustre를 선택했을 것입니다. 하지만 온프레미스 환경에서 이러한 고성능을 유지하기 위해서 때로는 수만 개의 클라이언트 노드와 수백 페타바이트의 스토리지를 관리하는 복잡한 메커니즘의 구성과 전문적인 운영이 필수적입니다.

Lustre 관련 업무 경험을 바탕으로 볼 때, Amazon FSx for Lustre는 이러한 복잡성을 완전히 제거하고 단 몇 분 만에 고성능 파일시스템을 구축할 수 있게 해주는 혁신적인 서비스입니다. 이는 AWS의 ‘Customer Obsession’이라는 고객 중심 문화를 가장 잘 보여주는 대표적인 서비스이며, 개인적으로는 200여 개가 넘는 AWS 서비스 중에서도 Amazon FSx for Lustre를 가장 주목할 만한 상위 3개 서비스 중 하나로 꼽는 이유이기도 합니다.

특히 스타트업부터 대기업까지, 병렬 스토리지에 대한 전문 인력 유무와 관계없이 세계에서 가장 인기 있는 고성능 병렬 파일시스템을 손쉽게 사용할 수 있게 되었다는 점에서, FSx for Lustre는 기술의 민주화를 실현한 대표적인 AWS 클라우드 서비스라 할 수 있습니다.