Dynamo DB

Dnamo DB는 완전관리형 NoSQL DB 서비스입니다. 이와 같이 대규모 확장이 가능한 분산형 NoSQL 데이터베이스를 관리하는 복잡한 작업은 서비스 자체에서 관리합니다. 그러므로 소프트웨어 개발자가 인프라 관리 대신 애플리케이션 구축에 집중할 수 있습니다.

NoSQL 데이터베이스는 기본적으로 확장이 가능하지만 해당 아키텍처가 정교하므로 대규모 NoSQL 클러스터를 실행하는 경우 상당한 운영 오버헤드가 발생할 수 있습니다. Dynamo DB를 사용하기 위해 고급 분산 컴퓨팅 개념을 다루는 전문가일 필요가 없습니다. 선택한 프로그래밍 언어의 SDK를 사용하여 DynamoDB의 간단한 API를 배우기만 하면 됩니다.

DynamoDB는 비용 효율적입니다. 사용하는 스토리지와 프로비저닝한 I/O 처리량에 대한 요금을 지불하면 됩니다. 이 데이터베이스는 고성능을 유지하면서 탄력적으로 확장 가능하도록 설계되었습니다. 애플리케이션의 스토리지 및 처리량 요구 사항이 낮은 경우 소량의 용량을 프로비저닝하도록 선택할 수 있습니다.

자동 크기 조정을 선택하면 필요한 I/O 처리량이 증가할 경우 사용자가 설정한 한도 내에서 추가 용량이 프로비저닝됩니다. 온디맨드 옵션을 선택하면 데이터베ㅣ스에 초당 수천 건의 동시 요청을 전송하는 수백만명의 사용자를 지원하도록 애플리케이션을 원활히 확장할 수 있습니다.

DynamoDB는 이벤트 중심의 프로그래밍과 세분화된 액세스 제어를 지원합니다.

오버헤드(Overhead)
어떤 처리를 하기 위해 들어가는 간접적인 처리 시간과 메모리 등을 말합니다. 예를들어 a작업을 단순하게 실행하는데 10초가 걸리고, 안정성을 고려하여 부가적인 처리를 한 A를 실행한 결과 15초가 걸렸다면, 오버헤드는 5초가 됩니다. 이를 개선해 A1이 처리하는 시간이 12초가 되었다면, "오버헤드가 3초 줄었다"라고 표현합니다.

SDK(Software Development Kit)
소프트웨어 개발 키드를 줄인 것으로 기본적으로 미리 작성된 코드를 뜻합니다. 여기에는 개발자가 기존 소프트웨어를 사용하여 새 애플리케이션을 구축하는 데 필요한 모든 도구가 포함됩니다. SDK에는 보통 컴파일러와 디버거, API가 있습니다. 이외에도 다양한 요소를 포함할 수 있습니다.

키-값 데이터

NoSQL DB에서는 데이터의 액세스 및 관리를 위해 다양한 데이터 모델을 사용합니다. 이러한 데이터베이스 유형은 큰 데이터 볼륨, 짧은 지연 시간, 유연한 데이터 모델이 필요한 애플리케이션에 최적화되었습니다. NoSQL 데이터베이스에서는 다른 데이터베이스의 데이터 일관성 제약 조건 일부를 완화하는 방식으로 최적화됩니다. 한 가지 일반적인 모델을 키-값 데이터 입니다.

키-값 DB는 요청한 데이터를 단일 키와 연결할 수 있는 사용 사례에 적합합니다. 예를 들어 애플리케이션의 사용자 프로파일 데이터를 키 값 DB에 저장한 후 GamerTag 값을 키로 사용할 수 있습니다. 이 경우 특정 GamerTag만 요청하면 사용자 데이터를 빠르게 검색할 수 있습니다.

DynamoDB 사용 사례

사례1

게임 제작자는 DynamoDB를 사용해 간단한 플레이어 프로파일 페이지를 지원할 수 있습니다. GamerTag를 키로 사용하여 DynamoDB에 사용자 프로파일 데이터를 저장할 수 있습니다. 프로파일 페이지가 로드될 때 애플리케이션은 GamerTag 값을 사용하여 DynamoDB에 읽기 요청을 한 번만 하면 됩니다. 그리고 새 게임이 출시되면 DynamoDB는 크기를 빠르게 조정하여 급증하는 트래픽을 지원하기에 충분한 스토리지와 처리량을 제공할 수 있습니다.

사례 상세

사례2

전자 상거래 애플리케이션을 통해 고객에게 제품을 판매한다고 가정해보겠습니다. 이 경우 정확한 재고 표시를 위한 웹스토어가 필요합니다. 그런데 트래픽이 많은 시기와 명절 할인 행사 기간 등에는 재고를 정확하게 표시하기가 매우 어렵습니다. DynamoDB는 다양한 제품의 데이털르 추가할 수 있는 유동적인 스키마를 지원합니다. 그리고 다수의 동시 읽기와 쓰기 작업을 관리하며, 저장된 데이터의 정확도도 유지 관리합니다.

저장 데이터 암호화

RDS는 AWS KMS(Key Management Service)를 사용하여 저장 데이터 암호화를 제공합니다. AWS KMS는 암화키를 생성 및 관리하고 해당 키를 사용하여 데이터를 암화화 및 복호화하는 기능을 제공하는 관리형 서비스입니다.

모든 키는 사용자의 AWS 계정에 연결되고 사용자가 전반적인 관리를 담당합니다. KMS는 RDS 인스턴스의 기본 스토리지에 대한 무단 액세스로부터 보호하는 추가 보호 계층을 제공합니다. KMS는 업계 표준 AES-256 암호화를 사용하여 RDS 인스턴스가 실행되는 기본 호스트에 저장되는 데이터를 보호합니다.

암호화와 복호화
암호화(Encryption)는 정보를 보호하기 위해 평문을 암호문으로 변환하는 과정입니다. 복호화(Decryption)는 암호문을 평문으로 변환하는 과정입니다.

Aurora

Aurora는 엔터프라이즈급 관계형 데이터베이스입니다. 이 데이터베이스는 MySQL 및 PostgreSQL  관계형 데이터베이스와 호환됩니다. Aurora Serverless는 표준 MySQL DB보다 최대 5배 빠르고 표준 PostgreSQL DB 보다는 최대 3배 빠릅니다.

Aurora는 DB 리소스의 안정성 및 가용성을 유지하면서 불필요한 I/O 작업을 줄여 DB 비용을 절감하는 데 도움이 됩니다. 워크로드에 고가용성이 필요한 경우 Aurora를 고려할 수 있습니다. 이 DB는 6개의 데이터 복사본을 3개의 가용 영역에 복제하고 지속적으로 S3(Simple Storage Service)에 데이터를 백업합니다.

또한, 네트워크 격리, 저장 중 및 정손 중 데이터 암호화, 규정 준수 및 보장 프로그램을 지원합니다. Aurora는 RDS에 의해 관리되기 때문에 서버 프로비저닝, 소프트웨어 패치 적용, 설정, 구성  또는 백업이 필요하지 않습니다.

Aurora DB 클러스터

Aurora DB 클러스터는 하나 이상의 DB 인스턴스와 해당 DB 인스턴스에 대한 데이터를 관리하는 클러스터 볼륨으로 구성됩니다. 이러한 인스턴스는 데이터베이스의 컴픂팅 기능을 수행하며, 실제 데이터는 클러스터 볼륨에 저장됩니다.

Aurora에서는 두 가지 인스턴스 유형이 제공됩니다.

• 프라이머리 인스턴스
  읽기 및 쓰기 작업을 지원하고, 클러스터 볼륨의 모든 데이터 변경을 싱행합니다. 각 Aurora DB 클러스터마다 프라이머리 인스턴스가 하나씩 있습니다.
• Aurora 복제본
  읽기 작업만 지원합니다. 각 Aurora DB 클러스터마다 프라이머리 인스턴스 이외에 최대 15개의 Aurora 복제본을 가징 수 있습니다. 복수의 Aurora 복제본은 읽기 워크로드를 분산합니다. Aurora 복제본은 별도의 가용 영역에 배치하여 가용성을 높일 수 있습니다. 읽기 전용 복제본은 프라이머리 인스턴스와 동일한 리전에 있을 수 있습니다.

Aurora 클러스터 볼륨은 여러 가용 영역에 걸쳐 있는 가상 데이터베이스 스토리지 볼륨입니다.  각 가용 영역에는 DB 클러스터 데이터의 복사본이 있습니다. 클러스터 볼륨의 스토리지는 스토리지 노드 수백 개에 복제됩니다. Aurora에서 클러스터 볼륨은 DB 클러스터의 Aurora 복제본과 프라이머리 인스턴스의 단일 논리 볼륨으로 제공됩니다. 클러스터 볼륨에서 쓰기 작업을 수행하면 100밀리초 이내에 Aurora 복제본에서 해당 내용을 확인할 수 있는 경우가 많습니다.

PostgreSQL 및 MySQL용 Aurora Serverless v2

Aurora Serverless v2는 Aurora의 온디맨드 자동 크기 조정을 위한 구성입니다. 이는 워크로드를 모니터링하고 데이터베이스 용량을 조정하는 프로세스를 자동화하는 데 도움이 됩니다. 용량은 애플리케이션 수요에 따라 자동으로 조정됩니다. DB 클러스터에서 사용하는 리소스 요금만 청구되므로, 예산을 준수하는 데 도움이 되며 사용하지 않는 컴퓨터 리소스 요금을 부담할 필요가 없습니다.

또한, 이를 사용하면 DB가 자동으로 애플리케이션의 피크로드를 충족하도록 용량을 늘리고 활동 급증 시간이 끝나면 다시 용량을 줄입니다. Aurora Serverless v2를 사용하면 피크 또는 평균 용량에 따라 프로비저닝할 필요가 없습니다. 가장 많은 워크로드를 처리하는 용량 상한을 지정하면 해당 용량은 필요하기 전에는 사용되지 않습니다.

최소 용량도 설정할 수 있습니다. Aurora Serverless v2 DB 인스턴스의 크기 조정 속도는 현재 용량에 따라 달라집니다. 현재 용량이 클수록 빠르게 확장됩니다. DB 인스턴스의 용량을 단시간 내에 매우 크게 확장해야 하는 경우에는 크기 조정 속도가 요구 사항을 충족하는 값으로 최소 용량을 설정할 수 있습니다. 이 유형의 자동화는 다중 테넌트 DB, 분산 DB, 개발 및 테스트 시스템, 매우 중요하지만 예측 불가능한 워크로드가 있는 기타 환경에서 특히 유용합니다.

RDS 기능

RDS는 클라우드에서 관계형 데이터베이스를 설치, 운영 및 크기 조정을 할 수 있게 해주는 웹 서비스입니다. 이 서비스는 비용 효율적이고 크기 조정이 가능한 데이터베이스 용량을 제공해 주는 동시에 시간 소모적인 데이터베이스 관리 태스크도 처리해줍니다.

이는 Aurora, PostgreSQL, MySQL, MariaDB, Oracle Database, MS SQL Server 등 선택할 수 있는 6개의 친숙한 데이터베이스 엔진을 제공합니다. 그러므로 기존 데이터베이스에서 이미 사용하고 있는 코드, 애플리케이션 및 도구를 대부분 RDS에서 사용할 수 있습니다.

또한, 자동으로 데이터베이스 소프트웨어를 패치하고 데이터베이스를 백업합니다. 백업을 사용자가 정의한 보존 기간 동안 저장하고 특정 시점으로 복구 기능을 제공합니다. 한 번의 API 호출로 관계형 DB 인스턴스와 연결된 컴퓨팅 리소스 또는 스토리지 용량을 유연하게 스케일링하는 이점을 누릴 수 있습니다.

RDS 다중 AZ 배포

RDS는 다중 AZ 배포를 통해 데이터베이스 인스턴스의 가용성 및 내구성을 높여 주므로 프로덕션 데이터베이스 워크로드에 적합합니다. 다중 AZ DB 인스턴스를 프로비저닝하는 경우 RDS에서 다른 가용 영역에 있는 대기 인스턴스에 데이터를 동기식으로 복제합니다.

프로비저닝은  IT 인프라를 생성하고 설정하는 프로세스로, 다양한 리소스에 대한 사용자 및 시스템 액세스를 관리하는 데 필요한 단계를 포함합니다. 프로비저닝은 서버, 애플리케이션, 네트워크 구성, 스토리지, 엣지 기기 등을 배포하는 과정에서 초기 단계에 해당 합니다.

RDS 환경을 단일 AZ에서 다중 AZ로 변경하여 배포할 수 있습니다. 각 가용 영역은 물리적으로 분리된 독립적인 인프라에서 실행되며 높은 안정성을 제공하도록 설계되었습니다.

다중 AZ 장애 조치

프라이머리 인스턴스에 장애가 발생한 경우 RDS는 대기 인스턴스로 자동 장애 조치를 수행합니다.

위 예시에서 각 가용 영역 내의 EC2 인스턴스 2개는 가용 영역 하나의 프라이머리 데이터베이스에 연결되어 있습니다. 대기 데이터베이스는 다른 가용 영역에서 호스트 됩니다. 프라이머리 데이터베이스에서 장애가 발생하면 RDS는 세컨더리 데이터베이스를 프라이머리로 승격합니다. 그러면 세컨더리 데이터베이스가 프라이머리 데이터베이스 엔드포인트가 되므로 EC2 인스턴스가 새 프라이머리 데이터 베이스를 사용하여 트래픽 전송을 다시 시작할 수 있습니다. 그와 동시에 새 대기 데이터베이스가 다른 가용 영역에 생성됩니다.

읽기 전용 복제본

RDS를 사용하면 데이터베이스의 읽기 전용 복제본을 생성할 수 있습니다. Amazon에서 자동으로 이러한 복제본을 프라이머리 데이터베이스 인스턴스와 동기화 합니다. 읽기 전용 복제본은 RDS for Aurora, MariaDB, PostgreSQL, Oracle, MS SQL Server에서 사용할 수 있습니다. 읽기 복제본 사용 시에는 다음과 같은 태스크를 수행할 수 있습니다.

읽기 전용 복제본 사용 시에는 다음과 같은 태스크를 수행할 수 있습니다.

• 추가 읽기 용량으로 프라이머리 노드에 대한 부하를 해소할 수 있습니다.
• 여러 AWS 리전에서 데이터를 애플리케이션에 더 가까이 배치할 수 있습니다.
• 프라이머리 DB 인스턴스에 장애가 발생하는 경우 재해 복구(DR) 솔루션으로 읽기 전용 복제본을 독립 실행형 인스턴스로 승격할 수 있습니다.

프라이머리 DB가 읽기 요청으로 오버로드되지 않도록 읽기 전용 복제본을 추가하여 읽기 워크로드를 처리할 수 있습니다. DB 엔진에 따라 읽기 전용 복제본을 프라이머리 DB와 다른 리전에 배치할 수도 있습니다. 이러한 배치 방식을 사용하면 읽기 전용 복제본을 특정 로케이션에 더 가까이 배치할 수 있습니다.

고가용성을 위해 원본 DB를 다중 AZ로 구성하고 읽기 확장성을 위해 단일 AZ에서는 읽기 전용 복제본을 다중 AZ 및 DR 대상으로 설정할 수도 있습니다. 읽기 전용 복제본을 독립형 데이터베이스로 승격하면 읽기 전용 복제본이 여러 가용 영역으로 복제됩니다.

읽기 전용 복제본 상세

관계형 데이터베이스와 비관계형 데이터베이스

수십 년간 애플리케이션 개발에 주로 사용되어 온 데이터 모델은 관계형 데이터 모델입니다. 이 모델은 Oracle, IBM DB2, SQL Server, MySQL, PostgreSQL 등의 관계형 데이터베이스에 사용되고 있습니다. 2000년대 중반 말에 이르러 다른 데이터 모델들이 채택되고 사용되는 형상이 눈에 띄기 시작했습니다.

이러한 새로운 데이터베이스와 데이터 모델 클래스를 차별화하고 분류하기 위해 NoSQL이라는 용어가 만들어졌습니다. 흔히 NoSQL이란 용어는 비관계형 데이터베이스와 같은 의미로 사용됩니다.

관계형 데이터베이스는 서로 간에 사전 정의된 관계가 있는 데이터 항목의 모음입니다. 이들 항목은 열과 행으로 이루어진 테이블 집합으로 굿어됩니다. 테이블의 각 열은 특정 종류의 데이터를 수록하며 필드는 속성의 실제 값을 저장합니다. 테이블의 행은 한 객체 또는 엔터티와 관계된 값의 모음을 나타냅니다. 이 데이터는 데이터베이스 테이블 자체를 재구성하지 않고도 여러 가지 방법으로 액세스 할 수 있습니다.

NoSQL은 가용성과 확장성이 뛰어나며 높은 성능을 유지하도록 최적화된 비 관계형 데이터베이스 시스템을 설명하는 데 사용되는 용어입니다. NoSQL 데이터베이스는 키 값 페어 또는 문서 스토리지 같은 데이터 관리에 관계형 모델 대신 대처 모델을 사용합니다.

관계형 DB / NoSQL

기능이 각기 다른 여러 유형의 데이터베이스가 있지만, 다음 표에서는 SQL DB와 NoSQL DB의 몇 가지 차이점에 대해 보여줍니다.

관리형 서비스와 비관리형 서비스

클라우드에서 리소스를 구축할 때는 클라우드를 제어해야 하는 수준, 그리고 해당 리소스를 관리하는 데 사용할 수 있는 보유 중인 리소스를 고려해야합니다.

예를 들어 클라우드에서 데이터베이스를 실행할 때는 Amazon EC2(Amazon Elastic Compute Cloud) 인스턴스에 설치할 수도 있고, Amazon RDS 등의 관계형 데이터베이스 옵션을 선택할 수도 있습니다.

• EC2 인스턴스에 데이터베이스를 설치하면 하드웨어를 제외한 데이터베이스의 모든 측면을 완벽하게 제어할 수 있습니다. 하지만 이처럼 제어 가능 수준이 높아지므로 관리를 위한 전문 지식과 리소스가 더 많이 필요합니다.
• 관리형 데이터베이스 서비스를 사용 시에는 획일적인 데이터베이스 관리 업무를 수행할 필요가 없습니다.

AWS가 관리하는 데이터베이스는 고가용성, 확장성 및 백업을 위한 시스템을 제공합니다. 스케일링, 고가용성, 데이터베이스 백업, 데이터베이스 소프트웨어 패치, 데이터베이스 소프트웨어 설치, OS 패치를 사용하도록 선택할 수 있습니다. 일반적으로 사용자는 데이터베이스 계층이 애플리케이션과 최대한 잘 연동하도록 애플리케이션 최적화만 책임집니다.

AWS 데이터 마이그레이션 도구

사용할 도구를 선택하기 전에 다음 정보를 파악해야 합니다.

• 데이터를 이동하려는 위치
• 데이터 이동 관련 사용 사례
• 이동하려는 데이터의 유형
• 사용 가능한 네트워크 리소스

AWS는 데이터 집합(파일, 데이터베이스, 머신 이미지, 블록 볼륨 또는 테이프 백업)을 마이그레이션하는 데 사용할 수 있는 다양한 서비스와 AWS Pratner 도구를 제공합니다. 이 모듈에서는 다음 도구에 대해 알아봅시다.

1. AWS Storage Gateway
   AWS 스토리지를 온프레미스에 간단하게 도입할 수 있도록 해줍니다. Storage Gateway를 사용하면 온프레미스 애플리케이션을 AWS 스토리지에 원활하게 연결하여 확장할 수 있습니다. Storage Gateway는 SMB(Server Message Block), NFS(Network File Sharing), iSCSI(Internet Small Computer Interface) 등의 여러 파일 전송 프로토콜을 지원합니다.
   
   
2. AWS DataSync
   온프레미스 스토리지와 S3, EFS, 또는 FSx for Windows File Server 간에 데이터를 원활하게 이동할 수 있는 데이터 전송 서비스입니다.
   
   
3. AWS Transfer Family
   보안 쉘 파일 전송 프로토콜(SFTP)을 사용하여 S3에서 파일을 전송 및 수신할 수 있습니다.
   
   
4. AWS Snow Family
   물리적 보안 전송용으로 설계된 엣지 컴퓨팅, 데이터 마이그레이션 또는 엣지 스토리지 디바이스 그룹입니다.
   
   

자세한 내용

AWS Storage Gateway

온프레미스 소프트웨어 어플라이언스를 클라우드 기반 스토리지와 연결해 주는 AWS Storage Gateway에서는 온프레미스IT 환경과 AWS 스토리지 인프라 간에 데이터 보안 기능을 원활하게 통합할 수 있습니다. 지연 시간이 짧은 Storage Gateway 어플라이언스를 통해 클라우드 데이터에 액세스할 수 있습니다.

이 서비스를 사용하여 AWS 클라우드에 데이터를 저장하면 비용 효율적인 확장 가능 스토리지에서 데이터 보안을 유지할 수 있습니다. Storage Gateway는 IAM, AWS KMS, AWS CloudTrail 및 Amazon CloudWatch와 동합되는 파일 기반, 볼륨 기반 및 테이프 기반 스토리지 솔루션을 제공합니다.

Storage Gateway 유형

사용자의 워크로드에 가장 적합한 Storage Gateway 유형을 선택하야 합니다. 유형의 종류는 다음과 같습니다.

1. S3 File Gateway는 S3에 파일을 객체로 저장하는 데 사용할 수 있는 파일 인터페이스를 제공합니다. 업계 표준 NFS 및 SMB 파일 프로토콜을 사용할 수 있습니다. 그러면 데이터 센터나 EC2에서 NFS 및 SMB를 통해 파일에 액세스할 수도 있고, S3에서 NFS 및 SMB를 통해 파일에 액세스할 수도 있고, S3에서 해당 파일(객체)에 직접 액세스할 수도 있습니다.
   
   
2. FSx File Gateway에서는 신뢰성이 우수한 확장 가능 완전관리형 파일 공유에 온프레미스에서 빠르게(지연 시간이 짧음) 액세스할 수 있습니다. 이 Gateway는 업계 표준 SMB 프로토콜을 사용합니다. 전체 NTFS 지원, 섀도우 복사본, ACL 등의 Microsoft Windows 기능을 활용하여 FSx에서 파일 데이터를 저장 및 액세스할 수 있습니다.
   
   
3. Tape Gateway는 온프레미스 백업 애플리케이션용으로 가상 테이프 드라이브의 iSCSI 기반 가상 테이프 라이브러리(VTL) 및 가상 미디어 체인저를 제공합니다. Tape Gateway는 S3에 가상 테이프를 저장하고 새 테이프를 자동으로 생성하므로 테이프 관리와 AWS로의 전환을 간편하게 진행할 수 있습니다.
   
   
4. Volume Gateway는 iSCSI 프로토콜을 사용하여 애플리케이션의 블록 스토리지 볼륨을 제공합니다. 이러한 볼륨에 기록된 데이터를 볼륨의 특정 시점 스냅샷으로 비동기 백업한 다음 EBS 스냅샷으로 클라우드에 저장할 수 있습니다. 이 Gateway는 서비스의 스냅샷 스케줄러나 AWS Backup 서비스를 사용하여 온프레미스 Volume Gateway 볼륨을 백업할 수 있습니다.

Storage Gateway 아키텍처

Storage Gateway 어플라이언스에서는 다음 프로토콜을 사용하여 로컬 데이터에 연결할 수 있습니다.

• NFS 또는 SMB(파일)
• iSCSI(볼륨)
• iSCSI VTL(테이프)

Storage Gateway 어플라이언스는 S3 File Gateway, FSx File Gateway, Tape Gateway, Volume Gateway의 4개 모드 중 하나로 실행됩니다. Storage Gateway를 사용해 AWS로 이동한 데이터는 Storage Gateway 관리형 서비스를 통해 다음 대상 위치로 전송할 수 있습니다.

• S3(S3 File Gateway, Tape Gateway)
• S3 Glacier(S3 File Gateway, Tape Gateway)
• FSx for Windows File Server(FSx File Gateway)
• EBS(Volume Gateway)

AWS Backup을 사용하여 Volume Gateway에 볼륨 스냅샷을 예약할 수 있습니다.

AWS DataSync

데이터 전송 관련 수동 테스크를 수행하면 마이그레이션 속도가 느려지고 IT 운영 부담이 증가할 수 있습니다. DataSync를 사용하면 온프레미스 스토리지와 S3, EFS 또는 FSx for Windows File Server 간에 대량의 데이터를 원활하게 이동할 수 있습니다. 전송되는 데이터는 기본적으로 TSL 1.2를 사용하여 암호화됩니다. DataSync는 스크립팅 복사 작업, 전송 일정 수립 및 모니터링, 데이터 유효성 검사, 네트워크 활용도 최적화를 자동으로 처리합니다.

SMB 기반 데이터 저장소 및 콘텐츠 리포지토리를 파일 서버 및 NAS 어레이에서 분석을 위해 S3 및 EFS로 이동함에 따라 온프레미스 스토리지 인프라를 줄입니다.

DataSync는 여러 공유 파일 시스템에 연결해 여러 태스크를 실행할 수 있는 단일 소프트웨어 에이전트로 배포됩니다. 이 소프트웨어 에이전트는 일반적으로 가상 인스턴스를 통해 온프레미스에 배포되어 광역 네트워크(WAN)를 통한 AWS로의 데이터 전송을 처리합니다. 그리고 AWS 측에서는 에이전트가 DataSync 서비스 인프라에 연결됩니다. DataSync는 서비스이므로 고객이 클라우드에서 인프라를 설정하거나 유지 관리할 필요가 없습니다. 콘솔에서 직접 DataSync 구성을 관리하면 됩니다.

AWS Snow 패밀리 서비스 모델

1. AWS Snowcone은 견고하고 안전하며, 전통적인 데이터 센터의 외부에서 사용할 수 있도록 특별히 설계되었습니다. 크기가 작은 덕분에 좁은 공간이나 휴대성이 요구되고 네트워크 연결을 신뢰할 수 없는 상황에서 효과적으로 사용할 수 있습니다.
   
   
2.  Snowball Edge는 데이터 전송을 위해 코드를 작성하거나 하드웨어를 구매할 필요가 없는 페타바이트 규모의 데이터 전송 옵션입니다. 콘솔에서 작업을 생성하기만 하면 Snowball 어플라이언스가 고객에게 배송됩니다. 어플라이언스를 로컬네트워크에 연결하고 파일을 어플라이언스로 직접 전송합니다. 디바이스를 반환할 준비가 되면 E lnk 배송 레이블이 반환 주소로 자동으로 업데이트 됩니다. 그러므로 디바이스가 올바른 AWS 시설로 배송됩니다.
   
   
3. Snowball Edge Optimized는 원격의 외진 환경 또는 네트워크 연결이 끊기거나 열악한 환경에서 추가 컴퓨팅, 메모리 및 스토리지 기능이 필요한 엣지 처리 사용 사례에 적합합니다.

EFS(Elastic File System)

EFS는 Linux 기반 워크로드를 AWS 클라우드 서비스와 온프레미스 리소스에서 사용할 수 있도록 확장 가능하며 탄력적인 파일 시스템을 제공합니다.

파일 시스템을 생성하여 EC2 인스턴스에 탑재한 다음 해당 파일 시스템에서 데이터를 읽고 쓸 수 있습니다. EFS 파일 시스템을 NFS(Network File System) 버전 4.0 및 4.1(NFSv4) 프로토콜을 통해 VPC에 탑재할 수 있습니다. 스토리지 용량 필요가 증가함에 따라 파일 시스템을 확장하기 위해 조치할 필요가 없습니다.

VPC의 여러 EC2 인스턴스에서 동시에 EFS 파일 시스템에 액세스할 수 있으므로 단일 연결을 넘어 확장되는 애플리케이션이 파일 시스템에 액세스할 수 있습니다.

EFS 파일 시스템은 AWS 리전 내에서 데이터를 중복 저장하므로 우수한 가용성과 내구성이 보장됩니다. 파일 시스템의 가용성 및 내구성을 고려하여 다음과 같은 스토리지 등급을 선택할 수 있습니다.

• Standard 스토리지 등급을 선택하면 AWS 리전의 모든 가용 영역에 파일 시스템 데이터와 메타 데이터를 중복 저장하는 파일 시스템이 생성됩니다. AWS 리전의 각 가용 영역에 탑재 대상을 생성할 수도 있습니다. Standard 스토리지 등급에서는 최고 수준의 가용성과 내구성을 제공합니다.
• One Zone 스토리지 등급을 선택하면 단일 가용 영역 내에 파일 시스템 데이터와 메타 데이터를 저장하는 파일 시스템이 생성됩니다. One Zone 스토리지 등급을 사용하는 파일 시스템은 탑재 대상을 하나만 포함할 수 있습니다. 이 탑재 대상은 파일 시스템이 생성된 가용 영역에 있습니다.

EFS 이점

EFS에서 제공하는 공유 영구 계층에서는 상태 저장 애플리케이션이 탄력적으로 확장 및 축소를 수행할 수 있습니다. DevOps, 웹 서비스, 웹 콘텐츠 시스템, 미디어 처리, 기계 학습, 분석, 검색 인덱스, 상태 저장 마이크로 서비스 애플리케이션 등을 예로 들 수 있습니다. EFS는 페타바이트급 파일 시스템을 지원할 수 있으며, 파일 시스템 용량이 늘어나면 파일 시스템 처리량도 높아집니다.

EFS는 서버리스 방식이므로 인프라나 용량을  프로비저닝 또는 관리할 필요가 없습니다. 유형에 관계없이 최대 수만 개의 동시 클라이언트가 EFS 파일 시스템을 공유할 수 있습니다. 이러한 클라이언트는 기존 EC2 인스턴스일 수도 있고 셀프 매니지드 클러스터 중 하나에서 싱행되는 컨테이너일 수도 있습니다.

클라이언트는 AWS 컨테이너 서비스인 ECS(Elastic Container Service), EKS(Elastic Kubernetes Service), Fargate 중 하나에서 실행될 수도 있고 Lambda에서 실행되는 서버리스 함수에서 실행될 수도 있습니다.

EFS를 사용하면 공유 파일 스토리지의 총 소유 비용을 줄일 수 있습니다. 여러 가용 영역에 복제하지 않아도 되는 데이터는 EFS One Zone을 선택하면 스토리지 비용을 절약할 수 있습니다. 매일 액세스하지 않는 파일용 스토리지 등급인 EFS Standarrd-IA(EFS Standard-Infrequent Access)는 이러한 파일의 비용 측면에서 최적화된 가격과 성능을 제공합니다.

EFS 크기 조정 및 자동화 기능을 사용하면 관리 비용을 절약할 수 있으며 실제 사용한 만큼만 요금을 지불하면 됩니다.

FSx

FSx 사용 시에는 다양한 기능을 제공하는 고성능 파일 시스템을 빠르게 시작하고 실행할 수 있습니다. 이 서비스에서는 4개 파일 시스템 중 선택할 수 있습니다. 사용법을 가장 잘 알고 있는 파일 시스템을 선택할 수도 있고 요구에 맞는 기능 세트, 성능 프로파일, 데이터 관리 기능을 제공하는 파일 시스템을 선택할 수도 있습니다.

1. FSx for Windows File  Server
   네이티브 Windows 파일 시스템이 지원하지 않는 완전관리형 Microsoft Windows 파일 서버를 제공합니다. Windows Server에 구축되는 FSx에서는 데이터 중복 제거, 최종 사용자 파일 복원, Microsoft Active Directory와 같은 광범위한 관리 기능을 제공합니다.
   
   
2. FSx for Lustre
   비용 효율적인 고성능 스토리지를 제공하는 완전관리형 서비스입니다. Amazon Linux, Amazon Linux 2, Red Hat Enterprise Linux(RHEL), CentOS, SUSE Linux, Ubuntu 등의 널리 상요되는 대다수 Linux 기반 AMI와 호환됩니다.
3. FSx for NETapp ONTAP
   AWS 클라우드에서 완전관리형 공유 스토리지를 제공합니다. 해당 스토리지에는 ONTAP에서 많이 사용되는 데이터 액세스 및 관리 기능이 포함되어 있습니다.
   
   
4. FSx for OpenZFS
   완전 관리형 공유 파일 스토리지를 제공합니다. OpenZFS 파일 시스템을 기반으로 구축된 이 스토리지는 AWS Graviton 프로세서 패밀리를 통해 구동되며, NFS 프로토콜(v3, v4, v4.1, v4.2)을 통해 액세스 가능합니다.

자세한 내용