AWS Storage Gateway Service의 파일 게이트웨이 구성에 대한 개요 및 모범 사례
본 문서는 총 2부로 구성되어 있으며 이 글은 2부입니다.
파일 게이트웨이 버킷 인벤토리
목록 작업을 수행 할 때 대기 시간과 Amazon S3 작업 수를 줄이기 위해 파일 게이트웨이는 최근에 나열된 모든 객체의 레코드가 포함 된 로컬 버킷 인벤토리를 저장합니다. 파일 공유 클라이언트가 처음으로 파일 공유의 일부를 나열 할 때 버킷 인벤토리는 주문형으로 채워집니다. 파일 게이트웨이는 게이트웨이 자체가 클라이언트를 대신하여 수정, 삭제 또는 새 객체를 생성 할 때만 인벤토리 레코드를 업데이트합니다. 파일 게이트웨이는 동일한 Amazon S3 버킷과 연결된 보조 게이트웨이 또는 파일 게이트웨이 외부의 다른 Amazon S3 API 호출에 의해 NFS 또는 SMB 파일 공유 버킷의 객체 변경 사항을 감지 할 수 없습니다.
Amazon S3 객체를 파일 공유 외부에서 수정하고 파일 게이트웨이에서 인식해야하는 경우 (예 : Amazon EMR 또는 기타 AWS 서비스에서 변경 한 경우) RefreshCache API 호출 또는 RefreshCache AWS 명령 줄을 사용하여 버킷 인벤토리를 새로 고쳐야합니다. RefreshCache는 수동으로 호출하거나 CloudWatch 이벤트를 사용하여 자동화하거나 보조 게이트웨이를 사용하여 파일 공유에 파일을 쓴 후에 NotifyWhenUploaded API 호출을 사용하여 트리거 할 수 있습니다. 보조 게이트웨이가 작성한 파일이 S3에 업로드되면 Storage Gateway Upload Notification Event라는 CloudWatch 알림이 트리거됩니다. 이 이벤트의 대상은 기본 게이트웨이에이 변경 사항을 알리기 위해 RefreshCache를 호출하는 Lambda 함수일 수 있습니다.
RefreshCache는 파일 게이트웨이의 버킷 인벤토리에서 기존 레코드를 다시 인벤토리합니다. 알려진 오브젝트의 변경 사항을 지정된 공유에 액세스하는 파일 공유 클라이언트와 통신합니다.
1. 보조 게이트웨이 또는 외부 소스에서 생성된 개체입니다.
2. 파일 게이트웨이 장치 공유에서 RefreshCache API가 호출되었습니다.
3. 이물질은 파일 게이트웨이 버킷 인벤토리에 반영되고 클라이언트가 액세스할 수 있습니다.
여러 Contributor와의 버킷 공유
둘 이상의 파일 게이트웨이 공유가 단일 Amazon S3 버킷과 연결되어 있거나 다른 Amazon S3 지원 애플리케이션과 함께 하나 이상의 파일 게이트웨이가 단일 버킷을 수정하는 시나리오와 같이보다 복잡한 아키텍처를 배포 할 경우, 참고 해당 파일 게이트웨이는 파일 게이트웨이에서 객체 잠금 또는 파일 일관성을 지원하지 않습니다.
파일 게이트웨이는 다른 파일 게이트웨이를 감지 할 수 없으므로 동일한 Amazon S3 버킷으로 둘 이상의 파일 게이트웨이 공유를 사용하는 솔루션을 설계 및 배포 할 때는 주의해야합니다. 동일한 Amazon S3 버킷과 연관된 파일 게이트웨이는 다음 상황에서만 버킷의 컨텐츠에 대한 새로운 변경 사항을 감지합니다.
1. 파일 게이트웨이는 연결된 Amazon S3 버킷에 대한 변경 사항을 인식하고 공유에 파일 쓰기를 완료 한 후 NotifyWhenUploaded API를 호출하여 다른 게이트웨이 및 애플리케이션에 알릴 수 있습니다.
2. 파일 게이트웨이는 영향을 받는 개체가 해당 특정 파일 게이트웨이에서 쿼리하지 않은 폴더 (또는 접두사)에 있을 때 다른 파일 게이트웨이에 의해 개체에 대한 변경 사항을 인식합니다.
3. 파일 게이트웨이는 RefreshCache API가 실행 된 후 다른 제공자가 수행 한 관련 Amazon S3 버킷 (버킷 공유)의 변경 사항을 인식합니다.
공통 Amazon S3 버킷이 있는 여러 게이트웨이를 배포 할 때는 파일 게이트웨이 공유에서 읽기 전용 마운트 옵션을 사용하는 것이 좋습니다. 쓰기 충돌을 피하는 가장 간단한 방법은 한 명의 작성자와 여러 명의 독자만 있는 아키텍처를 설계하는 것입니다. 여러 작성자가 필요한 경우 각 게이트웨이에 액세스하는 클라이언트는 공유 Amazon S3 버킷의 동일한 객체에 쓰지 않도록 엄격하게 제어해야 합니다.
여러 파일 게이트웨이가 동일한 Amazon S3 버킷의 동일한 객체에 액세스하는 경우 다른 파일 게이트웨이의 변경 사항을 인식해야하는 파일 게이트웨이 공유에서 RefreshCache API를 호출해야 합니다. 이 작업을 더욱 최적화하고 실행하는 데 걸리는 시간을 줄이려면 공유의 특정 폴더 (재귀 적으로 또는 그렇지 않음)에서 RefreshCache API를 호출 할 수 있습니다.
1. 클라이언트가 새 파일을 만들고 파일 게이트웨이 # 1이 S3에 개체를 업로드합니다.
2. 고객이 파일 게이트웨이 # 1의 파일 공유에서 NotifyWhenUploaded API를 호출합니다.
3. CloudWatch 이벤트 (1 단계 완료시 생성)는 파일 게이트웨이 # 2에서 재 인벤토리를 시작하기 위해 RefreshCache API 호출을 시작합니다.
4. 파일 게이트웨이 # 2는 새로 작성된 객체를 클라이언트에 제공합니다.
Amazon S3 및 파일 게이트웨이
파일 게이트웨이는 Amazon S3 버킷을 사용하여 개별 게이트웨이에서 생성 된 각 마운트 지점 (공유)에 스토리지를 제공합니다. Amazon S3 버킷을 사용하는 경우 마운트 포인트는 무제한 용량, 저장된 객체의 99.999999999 % 내구성 및 소비 기반 요금 모델을 제공합니다.
AWS Storage Gateway를 통해 Amazon S3에 저장된 데이터 비용은 게이트웨이가 위치한 리전 및 스토리지 클래스를 기반으로 합니다. 지정된 마운트 지점은 마운트 지점을 생성 할 때 선택한 초기 구성에 따라 Amazon S3 Standard, Amazon S3 Standard — IA 또는 Amazon S3 One Zone — IA 스토리지에 직접 데이터를 씁니다. 이 스토리지 클래스는 모두 동일한 내구성을 제공합니다. 그러나 Amazon S3 Standard — IA와 Amazon S3 One Zone — IA는 요금 모델이 다르고 가용성이 낮으며 (즉 99.99 %와 비교하여 99.9 %) 액세스 빈도가 낮은 객체에 적합한 솔루션입니다. Amazon S3 Standard — IA 및 Amazon S3 One Zone — IA의 요금은 30 일 이상 존재하고 객체 당 128KB보다 큰 객체에 이상적입니다.
Amazon S3 스토리지 클래스의 가격 차이에 대한 자세한 내용은 Amazon S3 요금 페이지를 참조하십시오.
비용 최적화를 위해 Amazon S3 객체 수명주기 관리 사용
Amazon S3는 많은 스토리지 클래스를 제공합니다. 현재 AWS Storage Gateway 파일 게이트웨이는 기본적으로 S3 Standard, S3 Standard — Infrequent Access 및 S3 One Zone — IA를 기본적으로 지원합니다. Amazon S3 수명주기 정책은 스토리지 계층 전체의 데이터 관리를 자동화합니다. 개체의 연령에 따라 개체를 만료 할 수도 있습니다.
스토리지 클래스간에 데이터를 전환하기 위해 수명주기 정책이 전체 Amazon S3 버킷에 적용되며, 이는 스토리지 게이트웨이의 단일 마운트 지점을 반영합니다. 수명주기 정책은 파일 게이트웨이의 호스트 된 마운트 지점 내의 폴더를 반영하는 특정 접두사에도 적용될 수 있습니다. 수명주기 정책 전환 조건은 생성 날짜 또는 선택적으로 객체 태그 키 값 쌍을 기반으로합니다. 태깅에 대한 자세한 내용은 Amazon S3 개발자 안내서의 객체 태깅을 참조하십시오.
예를 들어, 가장 간단한 구현의 수명주기 정책은 지정된 Amazon S3 버킷의 모든 객체를 Amazon S3 Standard에서 Amazon S3 Standard — IA로, 마지막으로 데이터 수명에 따라 Amazon S3 Glacier로 이동합니다. 즉, 파일 게이트웨이로 생성 된 파일은 Amazon S3 버킷에 객체로 저장되고 콘텐츠가 오래 될수록 보다 경제적 인 스토리지 클래스로 자동 전환 될 수 있습니다.
파일 게이트웨이를 사용하여 S3 Standard-IA 또는 S3 One Zone-Zone-IA에 데이터를 저장하거나 간헐적인 스토리지 클래스의 데이터에 액세스하는 경우 AWS Storage Gateway 사용자 가이드의 스토리지 클래스 사용을 참조하여 게이트웨이가 NFS/SMB(파일 기반) 업로드 간에 중재하여 개체를 업데이트하거나 액세스하는 방법을 알아봅니다.
Amazon S3 Glacier로 객체 전환
수명주기 정책을 사용하여 마이그레이션 된 파일은 NFS 파일 읽기 / 쓰기 작업에 즉시 사용할 수 있습니다. NFS 파일이 파일 게이트웨이에 나열되면 Amazon S3 Glacier로 전환 된 객체가 표시됩니다. 그러나 API 또는 Amazon S3 콘솔을 사용하여 S3 스토리지 클래스로 복원하지 않으면 읽을 수 없습니다.
Amazon S3 Glacier에 객체로 저장된 파일을 읽으려고하면 클라이언트에서 읽기 작업을 시도하는 읽기 I / O 오류가 발생합니다. 따라서 수명주기를 사용하여 AWS Storage Gateway 환경의 NFS / SMB 클라이언트에서 즉시 액세스 할 필요가없는 파일 콘텐츠에 대해서만 파일을 Amazon S3 Glacier 객체로 전환하는 것이 좋습니다.
AWS 리전 간 Amazon S3 객체 복제
Amazon S3 교차 리전 복제 (CRR)를 파일 게이트웨이 아키텍처와 결합하여 두 개의 개별 AWS 리전에서 두 개의 Amazon S3 버킷에 객체를 저장할 수 있습니다. CRR은 인적 오류 방지, 악의적 파괴 방지 또는 원격 AWS 리전의 클라이언트 대기 시간 최소화와 같은 다양한 사용 사례에 사용됩니다. 파일 게이트웨이 아키텍처에 CRR을 추가하는 것은 파일 게이트웨이와 함께 기본 Amazon S3 도구 및 기능을 사용하는 방법의 한 예일뿐입니다.
Amazon S3 객체 버전 관리 사용
Amazon S3 Object Versioning과 함께 파일 게이트웨이를 사용하여 여러 버전의 파일이 수정 될 때이를 저장할 수 있습니다. 게이트웨이를 사용하여 이전 버전의 오브젝트에 액세스해야하는 경우 먼저 S3에서 이전 버전으로 복원 해야 합니다. 게이트웨이에이 복원을 알리려면 RefreshCache 조작도 사용해야합니다. 파일 공유에 Amazon S3 버전 버킷 사용에 대한 자세한 내용은 AWS Storage Gateway 사용 설명서의 파일 시스템에 표시되는 내용에 객체 버전 관리가 영향을 줄 수 있음을 참조하십시오.
WORM (Write Once Read Many) 데이터에 파일 게이트웨이 사용
WORM 스토리지를 사용해야하는 규정 요구 사항이 있는 환경에서 파일 게이트웨이를 사용하여 데이터를 저장하고 액세스 할 수도 있습니다. 이 경우 파일 공유 용 스토리지로 S3 Object Lock이 활성화 된 버킷을 선택하십시오. 파일 공유 클라이언트를 통해 파일 수정 또는 이름 변경이 있는 경우 파일 게이트웨이는 이전 버전에 영향을 주지 않고 새 버전의 오브젝트를 작성하므로 원래 잠긴 버전은 변경되지 않습니다. AWS Storage Gateway 사용 설명서의 Amazon S3 Object Lock과 함께 파일 게이트웨이 사용을 참조하십시오.
File Gateway Use Cases
다음 시나리오는 클라우드 계층 및 백업 아키텍처에서 파일 게이트웨이를 사용하는 방법을 보여줍니다.
클라우드 계층화
스토리지 리소스가 용량에 도달하는 온 프레미스 환경에서 더 차가운 데이터를 파일 게이트웨이로 마이그레이션하면 기존 스토리지 온 프레미스의 수명을 연장하고 추가 스토리지 하드웨어 및 데이터 센터 리소스에 대한 자본 지출의 필요성을 줄일 수 있습니다. 기존 스토리지 환경에 파일 게이트웨이를 추가 할 때 온 프레미스 애플리케이션은 Amazon S3 스토리지 내구성, 소비 기반 요금 및 가상 무한 규모를 활용하면서 NFS 또는 SMB를 통해 최근에 액세스 한 데이터에 대한 짧은 대기 시간 액세스를 보장 할 수 있습니다.
기본 호스트 OS 도구 또는 NFS 또는 SMB와 같은 표준 파일 프로토콜과 통합되는 타사 도구를 사용하여 데이터를 계층화 할 수 있습니다.
하이브리드 클라우드 백업
파일 게이트웨이는 지원되는 AWS 리전에 저장된 최대 5TiB 크기의 Amazon S3 객체를 생성하는 대기 시간이 짧은 NFS / SMB 인터페이스를 제공합니다. 따라서 NFS 또는 SMB를 사용할 수 있는 백업 솔루션에 이상적인 하이브리드 대상입니다. Amazon S3 스토리지 클래스를 혼합하여 사용하면 데이터가 저비용, 내구성이 뛰어난 클라우드 스토리지에 저장되고 복원 가능성이 감소함에 따라 점차적으로 저비용 스토리지에 자동으로 계층화 됩니다. 그림 10은 백업을 1 년 동안 보존해야한다고 가정하는 아키텍처 예를 보여줍니다. 30 일 후에는 복원 가능성이 드물게 발생하며 60 일 후에는 매우 드물게 됩니다.
이 솔루션에서는 처음 30 일 동안 백업의 초기 위치로 Amazon S3 Standard를 사용합니다. 백업 소프트웨어 또는 스크립트는 백업을 파일 공유에, 바람직하게는 멀티 메가 바이트 이상의 파일 형식으로 기록합니다. 더 큰 파일은 더 적은 전환이 필요하므로 스토리지 비용 절감 및 수명주기 전환 비용을 포함하여 엔드 투 엔드 솔루션에서 더 나은 비용 최적화를 제공합니다.
30 일이 지나면 백업이 Amazon S3 Glacier로 전환됩니다. 여기서는 처음 작성된 이후 1 년이 지날 때까지 유지되며, 이 시점에서 삭제됩니다.
1. 클라이언트는 NFS 또는 SMB를 통해 파일 게이트웨이에 백업을 씁니다.
2. 예상되는 백업보다 크기가 큰 파일 게이트웨이 캐시.
3. S3 Standard에 저장된 초기 백업.
4. 30 일 후에 백업이 S3 Standard-IA로 전환 됩니다.
5. 60 일 후에 백업이 S3 Glacier로 전환됩니다.
이 유형의 솔루션에서 파일 게이트웨이 캐시의 크기를 조정할 때는 백업 프로세스 자체를 이해하십시오. 한 가지 방법은 전체 백업을 포함 할 수 있을 정도로 캐시의 크기를 크게 하는 것입니다. 이렇게 하면 해당 백업의 복원이 WAN (Wide-Area Network) 링크보다 훨씬 빠르게 캐시에서 직접 가져올 수 있습니다.
백업 솔루션이 진행중인 백업을 작성하기 전에 기존 백업을 읽어 백업 파일을 통합하는 소프트웨어를 사용하는 경우이 구성을 캐시 크기에 포함시킵니다. 이러한 유형의 작업 중에 로컬 캐시에서 읽으면 비용이 절감되고 지속적인 백업 작업의 전반적인 성능이 향상되기 때문입니다.
위에서 지정한 두 경우 모두 AWS DataSync를 사용하여 온 프레미스 데이터 스토어에서 클라우드로 데이터를 전송할 수 있습니다. 여기에서 파일 게이트웨이를 사용하여 데이터에 대한 액세스를 유지할 수 있습니다.
결론
AWS Storage Gateway의 파일 게이트웨이 구성은 프라이빗 데이터 센터와 Amazon S3 스토리지간에 데이터를 브리지하는 간단한 방법을 제공합니다. 파일 게이트웨이를 통해 클라우드 마이그레이션, 클라우드 계층화 및 하이브리드 클라우드 백업을 위한 하이브리드 아키텍처를 사용할 수 있습니다.
난독 화없이 표준 파일 스토리지 프로토콜과 Amazon S3 API간에 변환 계층을 제공 할 수 있는 파일 게이트웨이 기능은 데이터가 기본 형식으로 유지 되어야하고 온 프레미스 및 AWS 클라우드 모두에서 사용할 수 있는 아키텍처에 이상적입니다.
AWS Storage Gateway 서비스에 대한 자세한 내용은 AWS Storage Gateway를 참조하십시오.
빌드업웍스에서 AWS 무료 컨설팅을 진행합니다.
AWS에 대하여 궁금하신 내용이 있으시거나, 도입을 검토 중이시라면 편하게 신청해주세요.
[ 고지 사항 (Disclaimer) ]
본 컨텐츠는 고객의 편의를 위하여 AWS 서비스 설명을 위해 제작, 제공된 것입니다. 만약 AWS 사이트와 컨텐츠 상에서 차이나 불일치가 있을 경우 AWS 사이트 (AWS.amazon.com)가 우선합니다. 또한 AWS 사이트 상에서 한글 번역문과 영어 원문에 차이나 불일치가 있을 경우(번역의 지체로 인한 경우 등 포함), 영어 원문이 우선합니다.
본 문서는 File Gateway for Hybrid Cloud Storage Architectures(2019년, 영문) 내용에 기반하여 작성 되었습니다.
이 문서는 정보 제공의 목적으로만 제공됩니다. 본 문서의 발행일 당시 AWS의 현재 제품 오퍼링 및 실행방법 등을 설명하며, 예고 없이 변경될 수 있습니다. 고객은 본 문서에 포함된 정보나 AWS 제품 또는 서비스의 사용을 독립적으로 평가할 책임이 있으며, 각 정보 및 제품은 명시적이든 묵시적이든 어떠한 종류의 보증 없이 “있는 그대로” 제공됩니다. 본 문서는 AWS, 그 자회사, 공급업체 또는 라이선스 제공자로부터 어떠한 보증, 표현, 계약 약속, 조건 또는 보장을 구성하지 않습니다. 고객에 대한 AWS의 책임 및 의무는 AWS 계약에 의해 관리되며 본 문서는 AWS와 고객 사이의 어떠한 계약에도 속하지 않으며 계약을 변경하지도 않습니다.
© 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.
