SQL Server 데이터베이스 백업을 위한 S3 File Gateway 최적화

데이터베이스 백업은 S3 File Gateway의 일반적인 권장 사용 사례로, Amazon S3에 데이터베이스 백업을 저장하여 비용 효율적인 단기 및 장기 보존을 제공하며 필요에 따라 비용 스토리지 계층을 낮추는 수명 주기 기능을 제공합니다. 이 솔루션을 사용하면 SQL Server Management Studio 및 Oracle RMAN과 같은 기본 제공 도구를 사용하여 엔터프라이즈 백업 애플리케이션의 필요성을 줄일 수 있습니다.

다음 섹션에서는 수백 테라바이트의 SQL 데이터베이스 백업에 대한 최적화된 성능과 비용 효율적인 지원을 위해 S3 File Gateway 배포를 조정하는 모범 사례를 설명합니다. 각 섹션에 제공된 지침은 전체 처리량을 개선하는 데 점진적으로 기여합니다. 이러한 권장 사항은 필요하지 않으며 상호 종속적이지 않지만가 S3 File Gateway 구현을 테스트하고 조정하는 데 지원 사용하는 논리적 방식으로 선택 및 정렬되었습니다. 이러한 제안을 구현하고 테스트할 때 각 S3 File Gateway 배포는 고유하므로 결과가 다를 수 있습니다.

S3 File Gateway는 파일과 객체 간의 기본 1:1 매핑과 함께 업계 표준 NFS 또는 SMB 파일 프로토콜을 사용하여 Amazon S3 객체를 저장하고 검색할 수 있는 파일 인터페이스를 제공합니다. S3 File Gateway를 VMware, Microsoft Hyper-V 또는 Linux KVM 환경의 온프레미스 또는 AWS 클라우드에 Amazon EC2 인스턴스로 가상 머신으로 배포합니다. S3 File Gateway는 전체 엔터프라이즈 NAS 교체로 작동하도록 설계되지 않았습니다. S3 File Gateway는 파일 시스템을 에뮬레이션하지만 파일 시스템은 아닙니다. Amazon S3를 내구성 있는 백엔드 스토리지로 사용하면 각 I/O 작업에 추가 오버헤드가 발생하므로 기존 NAS 또는 파일 서버와 비교하여 S3 File Gateway 성능을 평가하는 것은 동등한 비교가 아닙니다.

SQL Server와 동일한 위치에 게이트웨이 배포

S3 File Gateway 가상 어플라이언스와 SQL 서버 간에 네트워크 지연 시간을 최소화하면서 물리적 위치에 배포하는 것이 좋습니다. 게이트웨이의 위치를 선택할 때 다음 사항을 고려하세요.

• 게이트웨이의 네트워크 지연 시간이 짧으면 SQL 서버와 같은 SMB 클라이언트의 성능을 개선하는 데 도움이 될 수 있습니다.

• S3 File Gateway는 게이트웨이와 클라이언트 간에 비해 게이트웨이와 Amazon S3 간에 더 높은 네트워크 지연 시간을 허용하도록 설계되었습니다.

• Amazon EC2에 배포된 S3 File Gateway 인스턴스의 경우 게이트웨이와 SQL 서버를 동일한 배치 그룹에 유지하는 것이 좋습니다. 자세한 내용은 Amazon Elastic Compute Cloud 사용 설명서의 Amazon EC2 인스턴스에 대한 배치 그룹을 참조하세요.

느린 디스크로 인한 병목 현상 감소

IoWaitPercent CloudWatch 지표를 모니터링하여 S3 File Gateway의 느린 스토리지 디스크로 인해 발생할 수 있는 성능 병목 현상을 식별하는 것이 좋습니다. 디스크 관련 성능 문제를 최적화하려는 경우 다음 사항을 고려하세요.

• IoWaitPercent는 CPU가 루트 또는 캐시 디스크의 응답을 기다리는 시간의 비율을 보고합니다.

• IoWaitPercent가 5~10%보다 크면 일반적으로 성능 저하 디스크로 인한 게이트웨이 성능 병목 현상을 나타냅니다. 이 지표는 가능한 0%에 가까워야 합니다. 즉, 게이트웨이가 디스크를 기다리지 않으므로 CPU 리소스를 최적화하는 데 도움이 됩니다.

• Storage Gateway 콘솔의 모니터링 탭에서 확인하거나 지표IoWaitPercent가 특정 임계값을 초과하면 자동으로 알리도록 권장 CloudWatch 경보를 구성할 수 있습니다. 자세한 내용은 게이트웨이에 대한 권장 CloudWatch 경보 생성을 참조하세요.

• 를 최소화하려면 게이트웨이의 루트 및 캐시 디스크에 NVMe 또는 SSD를 사용하는 것이 좋습니다IoWaitPercent.

CPU, RAM 및 캐시 디스크에 대한 S3 File Gateway 가상 머신 리소스 할당 조정

S3 File Gateway의 처리량을 최적화하려는 경우 CPU, RAM 및 캐시 디스크를 포함하여 게이트웨이 VM에 충분한 리소스를 할당하는 것이 중요합니다. CPU 4CPUs, 16GB RAM 및 150GB 캐시 스토리지의 최소 가상 리소스 요구 사항은 일반적으로 소규모 워크로드에만 적합합니다. 대규모 워크로드에 가상 리소스를 할당할 때는 다음을 권장합니다.

• S3 File Gateway에서 생성되는 일반적인 CPUs 사용량에 따라 할당된 CPU 수를 16~48개로 늘립니다. UserCpuPercent 지표를 사용하여 CPU 사용량을 모니터링할 수 있습니다. 자세한 내용은 게이트웨이 지표 이해를 참조하세요.

• 할당된 RAM을 32~64GB로 늘립니다.

  참고

  S3 File Gateway는 64GB를 초과하는 RAM을 사용할 수 없습니다.

• 루트 디스크 및 캐시 디스크에 NVMe 또는 SSD를 사용하고 게이트웨이에 쓰려는 최대 작업 데이터 세트에 맞게 캐시 디스크의 크기를 조정합니다. 자세한 내용은 공식 Amazon Web Services YouTube 채널의 S3 File Gateway 캐시 크기 조정 모범 사례를 참조하세요.

• 하나의 대용량 디스크를 사용하는 대신 게이트웨이에 최소 4개의 가상 캐시 디스크를 추가합니다. 여러 가상 디스크는 동일한 기본 물리적 디스크를 공유하더라도 성능을 향상시킬 수 있지만, 가상 디스크가 서로 다른 기본 물리적 디스크에 있는 경우 일반적으로 성능이 향상됩니다.

  예를 들어 12TB의 캐시를 배포하려는 경우 다음 구성 중 하나를 사용할 수 있습니다.

  • 3TB 캐시 디스크 4개

  • 1.5TB 캐시 디스크 8개

  • 12 x 1TB 캐시 디스크

  이를 통해 성능 외에도 시간이 지남에 따라 가상 머신을 보다 효율적으로 관리할 수 있습니다. 워크로드가 변경되면 게이트웨이 무결성을 유지하기 위해 각 개별 가상 디스크의 원래 크기를 유지하면서 캐시 디스크 수와 전체 캐시 용량을 점진적으로 늘릴 수 있습니다.

  자세한 내용은 로컬 디스크 스토리지 용량 결정을 참조하세요.

S3 File Gateway를 Amazon EC2 인스턴스로 배포할 때는 다음 사항을 고려하세요.

• 선택한 인스턴스 유형은 게이트웨이 성능에 상당한 영향을 미칠 수 있습니다. Amazon EC2는 S3 File Gateway 인스턴스에 대한 리소스 할당을 조정할 수 있는 광범위한 유연성을 제공합니다.

• S3 File Gateway에 권장되는 Amazon EC2 인스턴스 유형은 Amazon EC2 인스턴스 유형에 대한 요구 사항을 참조하세요.

• 활성 S3 File Gateway를 호스팅하는 Amazon EC2 인스턴스 유형을 변경할 수 있습니다. 이를 통해 Amazon EC2 하드웨어 생성 및 리소스 할당을 쉽게 조정하여 이상적인 price-to-performance 비율을 찾을 수 있습니다. 인스턴스 유형을 변경하려면 Amazon EC2 콘솔에서 다음 절차를 사용합니다.

  1. Amazon EC2 인스턴스를 중지합니다.

  2. Amazon EC2 인스턴스 유형을 변경합니다.

  3. Amazon EC2 인스턴스의 전원을 켭니다.

  참고

  S3 File Gateway를 호스팅하는 인스턴스를 중지하면 파일 공유 액세스가 일시적으로 중단됩니다. 필요한 경우 유지 관리 기간을 예약해야 합니다.

• Amazon EC2 인스턴스의 price-to-performance 비율은 지불한 가격으로 얻을 수 있는 컴퓨팅 성능을 나타냅니다. 일반적으로 최신 세대 Amazon EC2 인스턴스는 이전 세대에 비해 비교적 저렴한 비용으로 최신 하드웨어와 향상된 성능을 갖춘 최상의 price-to-performance 비율을 제공합니다. 인스턴스 유형, 리전 및 사용 패턴과 같은 요소는이 비율에 영향을 미치므로 비용 효율성을 최적화하려면 특정 워크로드에 적합한 인스턴스를 선택하는 것이 중요합니다.

S3 File Gateway의 보안 수준을 조정하여 SMB 클라이언트 처리량 개선

SMBv3 프로토콜은 SMB 서명과 SMB 암호화를 모두 허용하며, 성능 및 보안에 일부 장단점이 있습니다. 처리량을 최적화하기 위해 게이트웨이의 SMB 보안 수준을 조정하여 클라이언트 연결에 적용되는 보안 기능을 지정할 수 있습니다. 자세한 내용은 게이트웨이의 보안 수준 설정을 참조하세요.

SMB 보안 수준을 조정할 때 다음 사항을 고려하세요.

• S3 File Gateway의 기본 보안 수준은 암호화 적용입니다. 이 설정은 게이트웨이 파일 공유에 대한 SMB 클라이언트 연결에 암호화와 서명을 모두 적용합니다. 즉, 클라이언트에서 게이트웨이로의 모든 트래픽이 암호화됩니다. 이 설정은 게이트웨이에서 로의 트래픽에는 영향을 주지 않으며 AWS,이 트래픽은 항상 암호화됩니다.

  게이트웨이는 암호화된 각 클라이언트 연결을 단일 vCPU로 제한합니다. 예를 들어 암호화된 클라이언트가 1개뿐인 경우 게이트웨이에 4개 이상의 vCPU가 할당되더라도 해당 클라이언트는 1vCPUs로만 제한됩니다. 따라서 단일 클라이언트에서 S3 File Gateway로의 암호화된 연결에 대한 처리량은 일반적으로 40~60MB/s 사이에서 병목 현상이 발생합니다.

• 보안 요구 사항이 보다 완화된 태세를 허용하는 경우 보안 수준을 클라이언트 협상으로 변경할 수 있습니다. 그러면 SMB 암호화가 비활성화되고 SMB 서명만 적용됩니다. 이 설정을 사용하면 게이트웨이에 대한 클라이언트 연결이 여러 vCPUs 활용할 수 있으므로 일반적으로 처리량 성능이 향상됩니다.

  참고

  S3 File Gateway의 SMB 보안 수준을 변경한 후에는 파일 공유 상태가 Storage Gateway 콘솔에서 업데이트 중에서 사용 가능으로 변경될 때까지 기다린 다음 새 설정이 적용되도록 SMB 클라이언트를 연결 해제했다가 다시 연결해야 합니다.

SQL 백업을 여러 파일로 분할하여 SMB 클라이언트 처리량 개선

• 단일 SQL 서버에서 순차적으로 쓰는 작업은 단일 스레드 작업이므로 한 번에 하나의 SQL 서버만 파일을 쓰는 S3 File Gateway를 사용하면 최대 처리량 성능을 달성하기 어렵습니다. 대신 각 SQL 서버의 여러 스레드를 사용하여 여러 파일을 병렬로 쓰고 여러 SQL 서버를 S3 File Gateway에 동시에 사용하여 게이트웨이 처리량을 극대화하는 것이 좋습니다. SQL 백업을 사용하면 백업을 여러 파일로 분할하면 각 파일이 별도의 스레드를 활용하여 S3 File Gateway 파일 공유에 여러 파일을 동시에 쓸 수 있습니다. 스레드가 많을수록 게이트웨이 제한까지 더 많은 처리량을 달성할 수 있습니다.

• SQL Server는 단일 백업 작업 중에 동시에 여러 파일에 대한 쓰기를 지원합니다. 예를 들어 T-SQL 명령 또는 SQL Server Management Studio(SSMS)를 사용하여 여러 파일 대상을 지정할 수 있습니다. 각 파일은 별도의 스레드를 사용하여 SQL 서버에서 게이트웨이 파일 공유로 데이터를 전송합니다. 이 접근 방식을 사용하면 I/O 처리량이 향상되어 백업 속도와 효율성이 크게 향상될 수 있습니다.

SQL Server 백업을 구성할 때 다음 사항을 고려하세요.

• SQL Server 관리자는 백업을 여러 파일로 분할하여 백업 시간을 최적화하고 대규모 데이터베이스 백업을 보다 효과적으로 관리할 수 있습니다.

• 사용되는 파일 수는 서버의 스토리지 구성 및 성능 요구 사항에 따라 달라집니다. 대규모 데이터베이스의 경우 백업을 각각 10GB~20GB의 작은 여러 파일로 나누는 것이 좋습니다.

• SQL Server가 백업 중에 쓸 수 있는 파일 수에는 엄격한 제한이 없지만 스토리지 아키텍처 및 네트워크 대역폭과 같은 실용적인 고려 사항이이 선택을 안내해야 합니다.

자세한 내용은 다음을 참조하세요.

• 여러 파일에 기록하여 SQL Server를 43~67% 더 빠르게 백업

• File Gateway를 사용하여 SQL Server 백업을 Amazon S3에 쉽게 저장할 수 있습니다

SMB 제한 시간 설정을 늘려 대용량 파일 복사 실패 방지

S3 File Gateway가 대용량 SQL 백업 파일을 SMB 파일 공유에 복사하는 경우 SMB 클라이언트 연결은 장기간 후에 시간 초과될 수 있습니다. 파일 크기와 게이트웨이의 쓰기 속도에 따라 SQL Server SMB 클라이언트의 SMB 세션 제한 시간 설정을 20분 이상으로 확장하는 것이 좋습니다. 기본값은 300초 또는 5분입니다. 자세한 내용은 게이트웨이 백업 작업이 실패하거나 게이트웨이에 쓸 때 오류가 있음을 참조하세요.

Amazon S3 업로더 스레드 수 증가

기본적으로 S3 File Gateway는 Amazon S3 데이터 업로드를 위해 8개의 스레드를 열어 대부분의 일반적인 배포에 충분한 업로드 용량을 제공합니다. 그러나 게이트웨이가 표준 8 스레드 용량으로 Amazon S3에 업로드할 수 있는 것보다 높은 속도로 SQL 서버로부터 데이터를 수신할 수 있으며, 이로 인해 로컬 캐시가 스토리지 한도에 도달할 수 있습니다.

특정 상황에서는 게이트웨이의 Amazon S3 업로드 스레드 풀 수를 8개에서 40개로 지원 늘릴 수 있으므로 더 많은 데이터를 병렬로 업로드할 수 있습니다. 대역폭 및 배포와 관련된 기타 요인에 따라 업로드 성능이 크게 향상되고 워크로드를 지원하는 데 필요한 캐시 스토리지 양을 줄이는 데 도움이 될 수 있습니다.

CachePercentDirty CloudWatch 지표를 사용하여 Amazon S3에 아직 업로드되지 않은 로컬 게이트웨이 캐시 디스크에 저장된 데이터의 양을 모니터링하고 지원 에 문의하여 업로드 스레드 풀 수를 늘리면 S3 File Gateway의 처리량이 향상될 수 있는지 확인하는 것이 좋습니다. 자세한 내용은 게이트웨이 지표 이해를 참조하세요.

참고

이 설정은 추가 게이트웨이 CPU 리소스를 사용합니다. 게이트웨이 CPU 사용량을 모니터링하고 필요한 경우 할당된 CPU 리소스를 늘리는 것이 좋습니다.

자동 캐시 새로 고침 끄기

자동 캐시 새로 고침 기능을 사용하면 S3 File Gateway가 메타데이터를 자동으로 새로 고칠 수 있으므로 게이트웨이를 통하지 않고 Amazon S3 버킷에 직접 작성하여 파일 세트에 대한 사용자 또는 애플리케이션의 변경 사항을 캡처할 수 있습니다. 자세한 내용은 Amazon S3 버킷 객체 캐시 새로 고침을 참조하세요.

게이트웨이 처리량을 최적화하려면 Amazon S3 버킷에 대한 모든 읽기 및 쓰기가 S3 File Gateway를 통해 수행되는 배포에서이 기능을 끄는 것이 좋습니다.

자동 캐시 새로 고침을 구성할 때는 다음 사항을 고려하세요.

• 배포의 사용자 또는 애플리케이션이 가끔 Amazon S3에 직접 쓰기 때문에 자동 캐시 새로 고침을 사용해야 하는 경우 비즈니스 요구 사항에 여전히 실용적인 새로 고침 사이의 가능한 가장 긴 시간 간격을 구성하는 것이 좋습니다. 캐시 새로 고침 간격이 길수록 디렉터리를 검색하거나 파일을 수정할 때 게이트웨이가 수행해야 하는 메타데이터 작업 수를 줄일 수 있습니다.

  예를 들어 워크로드에 대해 허용 가능한 경우 자동 캐시 새로 고침을 5분이 아닌 24시간으로 설정합니다.

• 최소 시간 간격은 5분입니다. 최대 간격은 30일입니다.

• 매우 짧은 캐시 새로 고침 간격을 설정하도록 선택한 경우 SQL 서버의 디렉터리 브라우징 환경을 테스트하는 것이 좋습니다. 게이트웨이 캐시를 새로 고치는 데 걸리는 시간은 Amazon S3 버킷의 파일 및 하위 디렉터리 수에 따라 크게 증가할 수 있습니다.

워크로드를 지원하기 위해 여러 게이트웨이 배포

Storage Gateway는 워크로드를 여러 게이트웨이로 분할하여 수백 개의 SQL 데이터베이스, 여러 SQL Server 및 수백 테라바이트의 백업 데이터가 있는 대규모 환경에서 SQL 백업을 지원할 수 있습니다.

여러 게이트웨이 및 SQL 서버를 사용하여 배포를 계획할 때는 다음 사항을 고려하세요.

• 단일 게이트웨이는 일반적으로 충분한 하드웨어 리소스와 대역폭으로 하루에 최대 20TB를 업로드할 수 있습니다. Amazon S3 업로더 스레드 수를 늘려 하루에 최대 40TB까지이 제한을 늘릴 수 있습니다.

• proof-of-concept 테스트를 수행하여 성능을 측정하고 배포의 모든 변수를 고려하는 것이 좋습니다. SQL 백업 워크로드의 최대 처리량을 결정한 후 요구 사항에 맞게 게이트웨이 수를 조정할 수 있습니다.

• 시간이 지남에 따라 데이터베이스 수와 데이터베이스 크기가 증가할 수 있으므로 확장을 염두에 두고 솔루션을 설계하는 것이 좋습니다. 증가하는 워크로드를 계속 확장하고 지원하기 위해 필요에 따라 추가 게이트웨이를 배포할 수 있습니다.

데이터베이스 백업 워크로드를 위한 추가 리소스

• 를 사용하여 SQL Server 백업을 Amazon S3에 저장 AWS Storage Gateway

• File Gateway를 사용하여 SQL Server 백업을 Amazon S3에 쉽게 저장할 수 있습니다

• AWS Storage Gateway 를 사용하여 Amazon S3에 Oracle 데이터베이스 백업 저장

• 대규모로 Amazon S3에 Oracle 데이터베이스 백업

• 를 사용하여 SAP ASE 데이터베이스를 Amazon S3에 통합 AWS Storage Gateway

• 한 AWS 히어로가 클라우드 내 백업 AWS Storage Gateway 에 사용하는 방법

• S3 File Gateway 캐시 크기 조정 모범 사례