영구 디스크 성능 최적화


영구 디스크는 VM의 사용량이 성능 한도에 도달하기에 충분한 경우 디스크 유형 차트에 기술된 성능을 제공합니다. 성능 요구에 맞게 영구 디스크 볼륨 크기를 적절하게 조정한 후에는 워크로드 및 운영체제에 일부 조정이 필요할 수 있습니다.

다음 섹션에서는 디스크 성능에 영향을 미치는 VM 및 워크로드 특성을 설명하고, 성능 향상을 위해 조정할 수 있는 몇 가지 핵심 요소에 대해 논의합니다. 몇 가지 제안 사항과 이 제안 사항을 특정 유형의 워크로드에 적용하는 방법입니다.

디스크 성능에 영향을 미치는 요소

다음 섹션에서는 VM의 디스크 성능에 영향을 미치는 요인에 대해 설명합니다.

쓰기 처리량의 네트워크 이그레스 상한

VM에는 VM의 머신 유형에 따라 달라지는 네트워크 이그레스 상한이 있습니다.

Compute Engine은 여러 병렬 쓰기로 영구 디스크에 데이터를 저장하여 기본적으로 중복성을 보장합니다. 또한 각 쓰기 요청에는 추가 쓰기 대역폭을 사용하는 일정한 오버헤드가 있습니다.

VM 인스턴스에서 발생할 수 있는 최대 쓰기 트래픽은 네트워크 이그레스 상한을 복제 및 오버헤드가 차지하는 대역폭 배수로 나눈 값입니다.

네트워크 이그레스 상한은 범용, 컴퓨팅 최적화, 스토리지 최적화, 메모리 최적화, 가속기 최적화 머신 계열에 대한 머신 유형 테이블의 최대 이그레스 대역폭(Gbps) 열에 나열되어 있습니다.

대역폭 배수는 전체 네트워크 사용률의 약 1.16배로, 작성한 바이트의 16%가 오버헤드입니다. 리전 영구 디스크의 경우 대역폭 배수는 약 2.32배로 추가 복제 오버헤드에 해당합니다.

영구 디스크 읽기 및 쓰기 작업이 네트워크 이그레스 대역폭과 경합하는 경우 머신 유형별로 정의된 최대 네트워크 이그레스 대역폭의 60%가 영구 디스크 쓰기에 할당됩니다. 나머지 40%는 다른 모든 네트워크 이그레스 트래픽용으로 남겨집니다. 다른 네트워크 이그레스 트래픽에 대한 자세한 내용은 이그레스 대역폭을 참조하세요.

다음 예시에서는 N1 VM 인스턴스의 영구 디스크에 대한 최대 쓰기 대역폭을 계산하는 방법을 보여줍니다. 대역폭 할당은 영구 디스크에 할당된 네트워크 이그레스 대역폭의 일부입니다. 최대 쓰기 대역폭은 오버헤드를 위해 조정된 영구 디스크의 최대 쓰기 대역폭입니다.

VM vCPU 개수 네트워크 이그레스 상한(MB/초) 대역폭 할당(MB/초) 최대 쓰기 대역폭(MB/초) 전체 네트워크 사용률(MB/초)의 최대 쓰기 대역폭
1 250 150 216 129
2~7 1,250 750 1,078 647
8~15 2,000 1,200 1,724 1,034
16+ 4,000 2,400 3,448 2,069

다음 수식을 사용하여 최대 영구 디스크 대역폭을 계산할 수 있습니다.

vCPU 1개가 있는 N1 VM

네트워크 이그레스 상한은 다음과 같습니다.

2Gbps/8비트 = 0.25GB/초 = 250MB/초

전체 네트워크 사용률에서 영구 디스크 대역폭 할당은 다음과 같습니다.

초당 250MB * 0.6 = 초당 150MB

네트워크 경합이 없는 영구 디스크 최대 쓰기 대역폭은 다음과 같습니다.

  • 영역 디스크: 초당 250MB/1.16~= 초당 216MB
  • 리전 디스크: 초당 250MB/2.32~= 초당 108MB

전체 네트워크 사용률의 영구 디스크 최대 쓰기 대역폭은 다음과 같습니다.

  • 영역 디스크: 초당 150MB/1.16~= 초당 129MB
  • 리전 디스크: 초당 150MB/2.32 ~= 초당 65MB

네트워크 이그레스 한도는 성능의 상한값을 제공합니다. 다른 요인으로 인해 이 수준 아래로 성능이 제한될 수 있습니다. 다른 성능 제약조건에 대한 자세한 내용은 다음 섹션을 참조하세요.

동시 읽기 및 쓰기

표준 영구 디스크의 경우 동시 읽기 및 쓰기는 동일한 리소스를 공유합니다. VM이 더 많은 읽기 처리량 또는 IOPS를 사용하는 경우 수행할 수 있는 쓰기 작업 수가 줄어듭니다. 반대로 쓰기 처리량이나 IOPS를 더 많이 사용하는 인스턴스는 수행할 수 있는 읽기 작업 수가 줄어듭니다.

영구 디스크 볼륨은 읽기 및 쓰기의 최대 처리량 및 IOPS 한도에 동시에 도달할 수 없습니다.

처리량 계산은 IOPS * I/O size입니다. SSD 영구 디스크에서 동시 읽기 및 쓰기 최대 처리량 한도를 활용하려면 읽기 IOPS와 쓰기 IOPS를 합한 값이 IOPS 한도를 초과하지 않는 I/O 크기를 사용하세요.

다음 표에서는 동시 읽기 및 쓰기에 대한 VM당 IOPS 한도를 보여줍니다.

표준 영구 디스크 SSD 영구 디스크(8 vCPU) SSD 영구 디스크(32개 이상 vCPU) SSD 영구 디스크(64개 이상 vCPU)
읽기 Write Read Write Read Write Read 쓰기
7,500 0 15,000 0 60,000 0 100,000 0
5,625 3,750 11,250 3,750 45,000 15,000 75,000 25,000
3,750 7,500 7,500 7,500 30,000 30,000 50,000 50,000
1875 11,250 3,750 11,250 15,000 45,000 25,000 75,000
0 15,000 0 15,000 0 60,000 0 100,000

이 표의 IOPS 수치는 8KB I/O 크기를 기준으로 합니다. 16KB와 같은 다른 I/O 크기의 경우 IOPS 수치가 다를 수 있지만 읽기/쓰기 분배는 동일합니다.

다음 표에서는 동시 읽기 및 쓰기에 대한 VM당 처리량 한도(MB/초)를 보여줍니다.

표준 영구 디스크 SSD 영구 디스크(vCPU 6~14개) SSD 영구 디스크(vCPU 16개 이상)
읽기 Write Read Write Read 쓰기
1200 0 800* 800* 1,200* 1,200*
900 100
600 200
300 300
0 400

* SSD 영구 디스크의 경우 최대 읽기 처리량과 최대 쓰기 처리량은 서로 독립적이므로 이러한 제한은 일정합니다.

논리 볼륨 크기

영구 디스크는 최대 64TiB일 수 있으며, VM 내부에서 논리 볼륨 관리를 사용하여 최대 257TiB의 단일 논리 볼륨을 만들 수 있습니다. 더 큰 볼륨 크기는 다음과 같은 방법으로 성능에 영향을 줍니다.

  • 일부 로컬 파일 시스템은 이 규모에서 제대로 작동하지 않습니다. 마운트 및 파일 시스템 검사와 같은 일반적인 작업이 예상보다 오래 걸릴 수 있습니다.
  • 영구 디스크의 최대 성능은 더 작은 크기에서 달성됩니다. 이 정도의 저장용량을 한 VM에서 완전히 읽거나 쓰려면 디스크에서 시간이 더 오래 걸립니다. 애플리케이션에서 지원하는 경우 여러 VM을 사용하여 총 시스템 처리량을 높이는 것을 고려하세요.
  • 대량의 영구 디스크 스냅샷 생성은 완료하는 데 예상보다 오랜 시간이 걸릴 수 있으며, 애플리케이션과 신중하게 조율하지 않으면 논리 볼륨이 일관성 없게 표시될 수 있습니다.

단일 VM 인스턴스에 연결된 여러 디스크

VM에 연결된 디스크가 여러 개일 때 디스크의 성능 한도는 디스크가 동일한 유형인지 또는 다른 유형인지에 따라 다릅니다.

동일한 유형의 여러 디스크

동일한 유형의 여러 디스크가 동일 모드(예: 읽기/쓰기)로 VM 인스턴스에 연결된 경우 성능 한도는 해당 디스크들을 합친 크기의 단일 디스크에 적용되는 한도와 동일합니다. 모든 디스크를 100% 사용한다면 상대적 디스크 크기에 관계없이 집계 성능 한도가 디스크 간에 균등하게 분할됩니다.

예를 들어 200GB pd-standard 디스크와 1,000GB pd-standard 디스크가 있다고 가정해 보겠습니다. 1,000GB 디스크를 사용하지 않으면 200GB 디스크가 1,200GB 표준 디스크의 성능 한도에 도달할 수 있습니다. 두 디스크를 모두 100% 사용하면 각 디스크는 600GB pd-standard 디스크의 성능 한도를 갖습니다(1,200GB/2개 디스크 = 600GB 디스크).

다양한 유형의 여러 디스크

VM에 다른 유형의 디스크를 연결할 경우 최대 가능한 성능은 VM이 지원하는 초고속 디스크의 성능 한도입니다. 연결된 디스크의 누적 성능은 VM이 지원하는 초고속 디스크의 성능 한도를 초과하지 않습니다.

IOPS 또는 처리량 기준의 워크로드에 맞게 디스크 최적화

성능 권장사항은 IOPS 또는 처리량을 최대화할지에 따라 다릅니다.

IOPS 기준의 작업 부하

SQL 또는 NoSQL에 관계없이 데이터베이스는 데이터에 대한 임의 액세스 사용 패턴을 갖고 있습니다. Google은 IOPS를 기준으로 한 워크로드에 다음 값을 권장합니다.

  • 각 400~800 IOPS에 대한 I/O 큐 깊이 1, 대규모 볼륨에서 최대 한도 64

  • 임의 읽기 IOPS 2,000당 사용 가능한 CPU 1개 및 임의 쓰기 IOPS 2,500당 사용 가능한 CPU 1개

  • VM 머신 유형에 사용할 수 있는 경우 프로비저닝된 IOPS를 변경할 수 있는 Google Cloud Hyperdisk Extreme 디스크를 사용합니다.

MongoDB, Apache Cassandra, 기타 데이터베이스 애플리케이션의 권장사항 문서에서는 일반적으로 낮은 미리 읽기 값이 권장됩니다.

처리량 기준의 워크로드

Hadoop 작업과 같은 스트리밍 작업은 빠른 순차적 읽기가 유용하며, I/O 크기가 클수록 스트리밍 성능이 향상될 수 있습니다.

  • 크기가 256KB 이상인 I/O를 사용합니다.

  • VM 머신 유형에 사용할 수 있는 경우 프로비저닝된 처리량을 변경할 수 있는 Hyperdisk Throughput 디스크를 사용합니다.

  • 표준 영구 디스크의 경우 가능하면 8개 이상의 병렬 순차 I/O 스트림을 사용합니다. 표준 영구 디스크는 물리적 HDD 하드 드라이브와 비슷한 순차 디스크 액세스에 맞춰 I/O 성능을 최적화하도록 설계되었습니다.

  • 큰 디스크에서 합리적인 수준의 일시적 데이터 지역성에 맞게 애플리케이션을 최적화합니다.

    애플리케이션이 장시간에 걸쳐 디스크의 여러 부분에 분산되어 있는 데이터에 액세스할 경우(vCPU당 수백 GB), 최적의 IOPS를 얻을 수 없습니다. 최상의 성능을 위해서는 디스크 단편화, 디스크에서 액세스되는 부분의 임의성과 같은 요소들을 고려해서 일시적인 데이터 지역성에 맞게 최적화해야 합니다.

  • SSD 영구 디스크의 경우 운영체제에서 I/O 스케줄러가 특정 요구를 충족하도록 구성되었는지 확인합니다.

    Linux 기반 시스템에서는 I/O 스케줄러가 none으로 설정되었는지 확인합니다. 이 I/O 스케줄러는 요청 순서를 변경하지 않으며 빠른 무작위 I/O 기기에 적합합니다.

    1. 명령줄에서 Linux 머신에서 사용하는 I/O 일정을 확인합니다.

      cat /sys/block/sda/queue/scheduler
      

      출력은 다음과 비슷합니다.

      [mq-deadline] none
      

      현재 활성 상태인 I/O 스케줄러는 대괄호([])로 표시됩니다.

    2. I/O 스케줄러가 none으로 설정되지 않은 경우 다음 단계 중 하나를 수행합니다.

      • 기본 I/O 스케줄러를 none으로 변경하려면 GRUB 구성 파일의 GRUB_CMDLINE_LINUX 항목에서 elevator=none을 설정합니다. 일반적으로 이 파일은 /etc/default/grub에 있으나 일부 오래된 배포판의 경우 다른 디렉터리에 위치할 수도 있습니다.
      GRUB_CMDLINE_LINUX="elevator=none vconsole.keymap=us console=ttyS0,38400n8 vconsole.font=latarcyrheb-sun16
      

      GRUB 구성 파일을 업데이트한 후에는 Compute Engine에서 부팅될 수 있도록 시스템에서 부트로더를 구성합니다.

      • 또는 런타임에 I/O 스케줄러를 변경할 수 있습니다.
      echo 'none' > sudo /sys/block/sda/queue/scheduler
      

      이 방법을 사용하면 재부팅 시 시스템이 기본 I/O 스케줄러로 다시 전환됩니다. cat 명령어를 다시 실행하여 I/O 스케줄러를 확인합니다.

디스크 성능을 향상시킬 수 있는 워크로드 변경사항

특정 워크로드 동작은 연결된 디스크에서 I/O 작업 성능을 향상시킬 수 있습니다.

높은 I/O 큐 깊이 사용

영구 디스크는 네트워크 연결 기기이므로 로컬 SSD 디스크와 같은 로컬 연결 디스크보다 지연 시간이 깁니다. 매우 높은 IOPS와 처리량을 제공할 수 있지만 충분한 I/O 요청이 동시에 수행되도록 해야 합니다. 동시에 수행되는 I/O 요청 수를 I/O 큐 깊이라고 합니다.

아래 표에는 특정 성능 수준을 달성하기 위한 권장 I/O 큐 깊이가 나와 있습니다. 아래 표에서는 보수적인 권장사항을 보여주기 위해 일반적인 지연 시간을 약간 과대추정했습니다. 이 예시에서는 16KB의 I/O 크기를 사용한다고 가정합니다.

큰 I/O 크기를 사용하여 충분한 I/O 생성

  • 큰 I/O 크기 사용

    IOPS 한도와 지연 시간이 애플리케이션 성능에 병목 현상을 일으키지 않도록 크기가 최소 256KB 이상인 I/O를 사용합니다.

    분산 파일 시스템 애플리케이션에는 큰 스트라이프 크기를 사용합니다. 큰 스트라이프 크기(예: 4MB 이상)를 사용하는 임의 I/O 워크로드는 워크로드가 여러 순차 스트림 디스크 액세스를 유사하게 모방하므로 표준 영구 디스크에서 뛰어난 성능을 발휘합니다.

  • 애플리케이션이 충분한 I/O를 생성 중인지 확인

    애플리케이션이 디스크의 IOPS 및 처리량 한도를 최대한 활용할 수 있을 만큼 충분한 I/O를 생성하는지 확인합니다. 워크로드 I/O 패턴에 대해 자세히 알아보려면 Cloud Monitoring에서 영구 디스크 사용량 및 성능 측정항목을 검토하세요.

  • I/O를 생성하는 인스턴스에서 사용 가능한 CPU가 충분한지 확인

    VM 인스턴스에서 CPU가 부족하면 앞서 설명한 IOPS를 앱이 관리할 수 없습니다. 예상 트래픽의 2,000~2,500 IOPS당 사용 가능한 CPU가 1개씩 있는 것이 좋습니다.

I/O 과부하를 최대 스팬으로 제한

스팬은 물리적 디스크 하나에 있는 논리적 블록 주소의 연속 범위를 나타냅니다. I/O 과부하를 특정 최대 스팬으로 제한되면 최대 성능을 달성합니다. 최대 스팬은 다음 표에 나열된 대로 디스크가 연결된 VM의 머신 유형에 따라 다릅니다.

머신 유형 권장 최대 스팬
  • m2-megamem-416
  • C2D VM
25TB
다른 모든 머신 유형 50TB

개별 영구 디스크의 용량을 합친 결과가 50TB 이하인 스팬은 성능을 계산할 때 단일 50TB 스팬과 동일하게 간주될 수 있습니다.

디스크 성능 향상을 위한 운영체제 변경

경우에 따라 운영체제 수준에서 기능을 사용 또는 사용 중지하거나 연결된 디스크를 구성하여 특정 방식으로 디스크 성능을 개선할 수 있습니다.

Linux에서 ext3 파일 시스템 사용 금지

Linux VM에서 ext3 파일 시스템을 사용하면 쓰기 부하가 높을 때 성능이 매우 떨어질 수 있습니다. 가능한 경우 ext4를 사용합니다. ext4 파일 시스템 드라이버는 ext3/ext2와 하위 호환되며 ext3 파일 시스템 마운트를 지원합니다. ext4 파일 시스템은 대부분의 Linux 운영체제에서 기본값입니다.

ext4로 마이그레이션할 수 없는 경우 해결 방법으로 data=journal 마운트 옵션을 사용하여 ext3 파일 시스템을 마운트할 수 있습니다. 이렇게 하면 쓰기 처리량 비용으로 쓰기 IOPS가 향상됩니다. ext4로 마이그레이션하면 일부 벤치마크에서 최대 7배까지 향상될 수 있습니다.

지연 초기화 중지 및 DISCARD 명령어 사용

영구 디스크에서는 블록이 더 이상 사용되지 않을 때 운영체제가 디스크에 이를 알릴 수 있게 해주는 DISCARD 또는 TRIM 명령어가 지원됩니다. DISCARD 지원을 통해서는 운영체제가 블록을 제로로 만드는 비용 없이 디스크 블록을 더 이상 필요하지 않은 것으로 표시할 수 있습니다.

대부분의 Linux 운영체제에서는 VM에 영구 디스크를 마운트할 때 삭제 작업을 사용 설정합니다. Windows Server 2012 R2 VM에서는 영구 디스크를 마운트할 때 기본적으로 삭제 작업을 사용 설정합니다.

삭제 작업을 사용하도록 설정하면 일반적인 런타임 성능이 향상되며, 처음 마운트될 때 디스크의 성능이 크게 향상될 수 있습니다. 전체 디스크 볼륨을 포맷하기 위해서는 시간이 오래 걸릴 수 있으므로 지연 포맷을 사용하는 것이 일반적입니다. 지연 포맷의 단점은 볼륨이 마운트되는 최초에 비용이 자주 지불된다는 것입니다. 지연 초기화를 중지하고 삭제 작업을 사용 설정하면 포맷 및 마운트 작업을 빠르게 수행할 수 있습니다.

  • 다음 매개변수를 mkfs.ext4로 전달하여 디스크를 포맷할 때 지연 초기화를 중지하고 삭제 작업을 사용 설정합니다.

    -E lazy_itable_init=0,lazy_journal_init=0,discard
    

    lazy_journal_init=0 매개변수는 CentOS 6 또는 RHEL 6 이미지를 사용하는 인스턴스에서는 작동하지 않습니다. 이러한 운영체제를 사용하는 VM의 경우 해당 매개변수 없이 영구 디스크를 포맷합니다.

    -E lazy_itable_init=0,discard
    
  • 다음 플래그를 mount 명령어에 전달하여 디스크를 마운트할 때 삭제 작업을 사용 설정합니다.

    -o discard
    

영구 디스크는 삭제 작업이 사용 설정된 상태에서 잘 작동합니다. 하지만 선택적으로 삭제 작업을 사용하는 것 외에 추가로 fstrim을 주기적으로 실행할 수 있습니다. 삭제 작업을 사용하지 않을 경우에는 부팅 디스크의 스냅샷을 만들기 전에 fstrim을 실행합니다. 파일 시스템을 자르면 더 작은 스냅샷 이미지를 만들어서 스냅샷 저장 비용을 줄일 수 있습니다.

미리 읽기 값 조정

I/O 성능을 높이기 위해 운영체제에서는 파일 읽기가 요청될 때 후속 데이터도 읽기가 요청될 가능성이 있다는 가정에 따라 요청된 것보다 많은 양의 파일을 메모리로 읽어들이는 미리 읽기와 같은 기법이 사용됩니다. 미리 읽기 양이 늘어날수록 처리량이 늘어나지만 메모리 및 IOPS 효율이 낮아집니다. 미리 읽기 양이 줄어들면 IOPS가 높아지지만 처리량이 줄어듭니다.

Linux 시스템의 경우 blockdev 명령어를 사용하여 미리 읽기 값을 가져오고 설정할 수 있습니다.

$ sudo blockdev --getra /dev/DEVICE_ID
$ sudo blockdev --setra VALUE /dev/DEVICE_ID

미리 읽기 값은 <desired_readahead_bytes>/512바이트입니다.

예를 들어 미리 읽기를 8MB로 지정할 경우, 8MB는 8,388,608바이트(8 * 1024 * 1024)입니다.

8388608 bytes / 512 bytes = 16384

blockdev를 16384로 설정합니다.

$ sudo blockdev --setra 16384 /dev/DEVICE_ID

VM 수정 또는 새 VM 만들기

연결된 디스크에서 얻을 수 있는 성능에 영향을 미칠 수 있는 각 VM 머신 유형과 관련된 제한이 있습니다. 이러한 제한은 다음과 같습니다.

  • 사용 가능한 vCPU 수가 증가하면 영구 디스크 성능이 향상됩니다.
  • 하이퍼디스크는 일부 머신 유형에서 지원되지 않습니다.
  • 네트워크 이그레스 요율은 사용 가능한 vCPU 수가 증가하면 증가합니다.

사용 가능한 CPU가 있는지 확인

영구 디스크에 대해 읽기 및 쓰기를 하려면 VM에서 CPU 주기를 사용할 수 있어야 합니다. 매우 높고 일관성 있는 IOPS 수준을 달성하려면 I/O 처리를 위해 사용 가능한 CPU가 필요합니다.

VM에서 사용할 수 있는 vCPU 수를 늘리려면 새 VM을 만들거나 VM 인스턴스의 머신 유형을 수정하면 됩니다.

새 기능을 얻기 위해 새 VM 만들기

최신 디스크 유형은 일부 머신 시리즈 또는 머신 유형에서 지원되지 않습니다. 하이퍼디스크는 워크로드에 더 높은 IOPS 또는 처리량을 제공하지만 현재 몇 가지 머신 시리즈에서만 사용할 수 있으며 vCPU 64개 이상이 필요합니다.

새 VM 머신 시리즈는 일반적으로 이전 CPU보다 우수한 성능을 제공할 수 있는 최신 CPU에서 실행됩니다. 또한 최신 CPU는 Advanced Matrix Extensions(AMX) 또는 Intel Advanced Vector Extensions(AVX-512)와 같은 워크로드 성능을 향상시키는 추가 기능을 지원할 수 있습니다.

다음 단계