Category: Amazon S3


Amazon Redshift Spectrum – S3 데이터에 대한 엑사바이트(Exabyte)급 질의 수행 서비스

이제 몇 번의 클릭만으로 클라우드 기반 컴퓨팅 및 스토리지 리소스를 시작할 수 있게 되었기 때문에, 이러한 리소스를 사용하여 초기 데이터에서 실행 가능한 결과로 최대한 신속하고 효율적으로 이동해야합니다.

Amazon Redshift를 사용하면 다양한 내부 및 외부 소스의 데이터를 통합하는 페타 바이트 규모의 데이터웨어 하우스를 구축 할 수 있습니다. Redshift는 대형 테이블에서 복잡한 조인(Join, 여러 조인이 수반되는 경우가 많음)을 위해 최적화되어 대규모의 소매, 재고 및 재무 데이터를 처리 할 수 ​​있습니다. 또한, Redshift 파트너가 제공하는 수많은 엔터프라이즈 비즈니스 인텔리전스 도구를 사용할 수 있습니다.

데이터웨어 하우스 운영의 가장 어려운 측면 중 하나는 지속적으로 변화하는 데이터 및 빠른 속도로 들어오는 데이터를 로드하는 것입니다. 뛰어난 쿼리 성능을 제공하기 위해 데이터웨어 하우스에 데이터를 로드하는 데에는 압축, 정규화 및 최적화 단계를 포함합니다. 이러한 단계를 자동화하고 확장 할 수는 있지만, 로드 프로세스는 여전히 오버 헤드와 복잡성을 야기하며 주요 실행 결과에 영향을 주게 됩니다.

데이터 형식은 또 다른 흥미로운 도전 과제입니다. 일부 애플리케이션은 데이터웨어 하우스 외부에서 원래 형식으로 데이터를 처리하거나, 데이터웨어 하우스에 쿼리를 실행합니다. 이 모델은 데이터를 두 번 저장해야하기 때문에 저장 비효율을 초래하며, 데이터 로드 프로세스에서 발생하는 지연으로 인해 한 가지 형식의 처리 결과가 다른 형식의 결과와 정렬되지 않을 수도 있습니다.

Amazon Redshift Spectrum 기능 출시
Amazon Redshift의 기능과 유연성을 활용하면서 데이터를 있는 그대로 처리 할 수 ​​있도록 Amazon Redshift Spectrum을 정식 공개합니다. 스펙트럼을 사용하여 Amazon Simple Storage Service (S3)에 저장된 데이터에 대한 복잡한 쿼리를 로드하거나 다른 데이터를 준비 할 필요 없이 바로 실행할 수 있습니다.

평소와 같이 데이터 소스를 생성하고 Redshift 클러스터에 쿼리를 실행하면 됩니다. 그 이면에서, Spectrum은 쿼리 단위로 수천 개의 인스턴스로 확장되므로 데이터 세트가 엑사바이트(exabyte) 이상으로 커지더라도 빠르고 일관된 성능을 보장 할 수 있습니다! S3에 저장된 데이터를 쿼리 할 수 ​​있다는 것은 Redshift 쿼리 모델 기능, 리포트 및 비즈니스 인텔리전스 도구를 자유롭게 사용하여 컴퓨팅 및 저장소를 독립적으로 확장 할 수 있다는 것을 의미합니다. 검색어는 Redshift 테이블과 S3에 저장된 모든 데이터의 조합을 참조할 수 있습니다.

쿼리를 실행하면 Redshift가 이를 구분하고 열(Column) 기반 형식과 날짜 또는 다른 키로 분할 된 데이터를 모두 활용하여, S3 읽기 데이터 양을 최소화하는 쿼리 계획을 생성합니다. 그런 다음 Redshift는 공유 풀(Pool)에서 Spectrum을 요청하고, S3 데이터를 가져와 필터링 및 집계하도록 지시합니다. 최종 처리는 Redshift 클러스터 내에서 수행되고 결과는 사용자에게 반환됩니다.

Spectrum은 S3에 저장된 데이터에서 작동하기 때문에Amazon EMRAmazon Athena와 같은 다른 AWS 서비스를 사용하여 데이터를 처리 할 수 ​​있습니다. Redshift 로컬 스토리지에 자주 질의되는 데이터가 저장되고, 나머지는 S3 차원 테이블(dimension tables)에서 팩트 테이블(fact tables)의 최신 데이터와 함께 Redshift에 존재하고, S3에는 이전 데이터가 있는 하이브리드 모델을 구현할 수도 있습니다. 높은 수준의 동시성을 구현하기 위해 동일 저장 데이터에서 여러 개의 Redshift 클러스터를 지정할 수 있습니다.

Spectrum은 CSV/TSV, Parquet, SequenceFile, RCFile을 비롯한 개방형 공통 데이터 유형을 지원합니다. 파일은 GZip 또는 Snappy를 사용하여 압축 할 수 있으며 다른 데이터 유형 및 압축 방법을 사용할 수 있습니다.

Spectrum 실행해 보기
Spectrum을 직접 경험해보기 위해 샘플 데이터 세트를 로드하고 쿼리를 실행합니다. 먼저 외부 스키마와 데이터베이스를 작성하여 시작했습니다.

그런 다음 데이터베이스 내에 외부 테이블을 만들었습니다.

간단한 쿼리를 실행하여 데이터 세트의 크기(61 억 행)에 대한 감을 얻었습니다.

그런 다음 모든 행을 처리 한 쿼리를 실행했습니다.

보시다시피, Spectrum은 약 15 초 만에 60 억 행을 처리할 수 있습니다. 클러스터 성능 메트릭을 확인한 결과 많은 쿼리를 동시에 실행하기에 충분한 CPU 성능을 갖춘 것처럼 보입니다.

정식 출시
Amazon Redshift Spectrum 는 오늘부터 사용 가능합니다.

스펙트럼 가격은 쿼리 처리 중에 S3에서 가져온 데이터의 양을 기반으로 하며 테라 바이트 당 5 달러의 요금으로 청구됩니다 (데이터 압축 및 열 기반 형식으로 저장하여 비용을 절약 할 수 있음). Redshift 클러스터를 실행하고 S3에 데이터를 저장하는 데 일반적인 요금을 지불하지만 쿼리를 실행하지 않을 때는 스펙트럼 요금이 없습니다.

Jeff;

PS – 어떤 분들은 Spectrum 과 Athena에 대한 차이에 대해 궁금하실 것입니다. 아래는 Redshift FAQ 에서 이들 서비스간의 차이에 대한 간단한 답변입니다.

Amazon Athena는 S3 데이터에 대한 임의(ad-hoc) 쿼리를 실행할 수 있는 가장 간단한 방법입니다. Athena는 서버가 없으므로 설치 또는 관리 할 인프라가 없으므로 즉시 데이터 분석을 시작할 수 있습니다. 자주 접근하는 데이터를 일관성 있고, 구조화 된 형식으로 저장해야 하는 경우 Amazon Redshift와 같은 데이터웨어 하우스를 사용해야 합니다. Amazon Redshift에 저장한 데이터는 Redshift Spectrum을 사용하여 Amazon Redshift 쿼리를 S3 전체 데이터로 확장 할 수 있습니다. 이렇게 하면 원하는 형식으로 원하는 위치에 자유롭게 데이터를 저장하고 필요할 때 처리 할 수 있습니다.

이 글은 Amazon Redshift Spectrum – Exabyte-Scale In-Place Queries of S3 Data의 한국어 번역입니다.

S3 스토리지 관리 기능 업데이트 – 스토리지 분석, 개체 태깅, 인벤토리 및 신규 통계 기능

오늘은 Amazon S3의 새로운 네 가지 기능에 대해 소개합니다. 먼저 저장 내용과 사용량 및 사용 방법을 손쉽게 볼 수 있으며, 이를 통해 S3 스토리지 클래스 선택을 위한 근거 데이터로 의사 결정을 할 수 있습니다. 이는 몇 개의 저장 개체나 수백만개를 가지고 있는 고객 모두에게 유용할 것입니다.

  • S3 분석 기능 – 개체 저장소 및 검색 패턴을 분석하고 그 결과를 사용하여 가장 적합한 저장소 클래스를 선택할 수 있습니다. S3 콘솔 내에서 분석 결과를 살펴보거나, 선호하는 BI 도구에 분석 결과를 보내 심층적으로 분석할 수 있습니다. 어느 방법을 사용하든 스토리지 패턴을 깊이 이해하고, 이에 대한 활용 방식을 파악할 수 있습니다.
  • S3 개체 태그 지정 – 여러 개의 키-값 페어(태그)를 각각 S3 객체와 연결할 수 있으며 언제든지 변경할 수 있습니다. 태그를 통해 접근 관리 및 제어, S3 수명 주기 정책 설정, S3 분석 사용자 정의 및 CloudWatch 메트릭 필터링에 사용할 수 있습니다. 버킷을 데이터 레이크(Datalake)로 생각하고 태그를 사용하여 객체 분류를 만들 수 있습니다. 이는 버킷과 접두사를 사용하는 것보다 유연하며 객체의 이름을 바꾸거나 이동하거나 복사하지 않고도 의미있는 스타일을 변경할 수 있습니다.
  • S3 인벤토리 – S3 인벤토리를 사용하여 비즈니스 워크 플로우와 대규모 데이터 작업 속도를 높일 수 있습니다. 이 기능은 일별 또는 주 단위로 버킷 전부 또는 일부(접두사로 식별) 내용에 대해 CSV 파일 형식으로 제공 받을 수 있습다.
  • S3 CloudWatch Metrics – 13 가지 새로운 Amazon CloudWatch 메트릭을 모니터링하고 알림을 줌으로써 S3 기반 애플리케이션의 성능을 향상시킬 수 있습니다.

이제 각각에 대해 좀 더 자세히 알아보겠습니다.

S3 분석 기능
S3 사용자는 Standard, Standard – Infrequent Access, Glacier라는 세 가지 스토리지 클래스 중에서 선택할 수 있으며, S3의 개체 수명 주기 관리 기능을 사용하여 개체 삭제 혹은 클래스 간 전환 시점을 정할 수 있습니다.

S3 Analytics 기능은 Standard 혹은 Standard – Infrequent Access 하나를 선택하기 위해 필요한 정보를 제공합니다. 많은 고객이 단일 버킷에 여러 가지 유형 또는 정보를 저장해서 처리하기 때문에, 버킷 내 객체의 하위 집합 (공통 접두사 또는 태그 값으로 정의 됨)에서 분석을 실행할 수 있습니다. 각 서브 세트는 필터로 정의됩니다. 각 버킷에는 최대 1000 개의 필터를 만들 수 있습니다. 아래는 버킷의 필터 사용 예입니다.

다음은 www 접두어가 붙은 객체를 분석하는 간단한 필터를 정의하는 방법입니다.

대신 태그 이름과 값으로 필터링 선택도 할 수 있습니다. typepage라는 태그가있는 객체를 분석하는 방법은 다음과 같습니다.

각 필터는 원하는 수의 태그와 함께 최대 하나의 접두사를 가질 수 있습니다. 매일 파일로 분석을 내보내도록 선택할 수도 있습니다.

하나 이상의 필터가 설치되면 분석이 매일 실행되므로 필터를 클릭하기 만하면 분석 결과를 볼 수 있습니다. 예를 들어, Archival 필터를 클릭하면 다음과 같이 표시됩니다.

분석 결과를 보면 새로운 사실을 많이 알 수 있습니다.

  • 127 일 동안  30 일보다 오래된 대부분의 객체의 접근 횟수는 낮습니다. 이러한 개체를 다른 클래스의 저장소로 전환하는 개체 생명 주기 규칙을 만들어 비용을 절약 할 수 있습니다.
  • 이 시점에서 내 스토리지 대다수 (6.39 PB)는 표준 스토리지에 있습니다. 아주 작은 부분 (3.24GB)이 Standard – Access Control에 저장되어 있습니다 (실제 버킷에는 많은 데이터가 없습니다!) S3 팀은 제 계정에 일부 테스트 측정 항목을 로드 할 정도로 친절했습니다.)
  • 127 일간의 분석 기간 동안 표준 저장 공간의 16 %에서 30 %가 하루 단위로 검색되었습니다.
  • 30-45일, 45-60일, 60-90일, 90-180일 및 180 일 이상 개체는 낮은 빈도로 접근되며, Standard – Infrequent Access에 저장하는 게 적합합니다.

AWS 콘솔, CLI 또는 S3 API를 통해 스토리지 클래스 분석을 설정할 수 있습니다. 자세한 내용은 S3 Storage Class Analysis를 읽으십시오.

S3 개체 태깅
태그 기능은 기존 위치 기반 S3 객체 관리 모델 (버킷 및 접두어)에 객체가 나타내는 것을 기반으로 저장소를 관리하는 기능을 보완합니다. 예를 들어, 부서 이름으로 개체에 태그를 지정한 다음 태그를 기반으로 접근 권한을 부여하는 IAM 정책을 구성 할 수 있습니다. 이는 단순히 태그를 변경하여 변경 사항을 적용하는 기능을 포함하여 많은 유연성을 제공합니다.

개체 수명 주기의 어느 부분에서나 개체를 만들거나 업데이트하거나 삭제할 수 있습니다. 태그는 IAM 정책, S3 수명 주기 정책 및 위에서 설명한 Storage Analytics 필터에서 참조 할 수 있습니다. 각 객체는 최대 10 개의 태그를 가질 수 있으며, 객체의 각 버전에는 고유 한 태그 집합이 있습니다. 태그를 사용하여 라이프 사이클 정책을 통해 개체의 만료를 관리하고 특정 태그 주위의 활동을 반영하는 CloudWatch 메트릭을 설정할 수 있습니다.

각 개체의 속성 페이지에는 현재 태그 집합이 표시되며 편집 할 수 있습니다.

또한, CLI 또는 S3 API를 통해 태그를 설정할 수 있습니다. 이 두 가지 방법 중 하나를 사용할 때는 항상 전체 태그 세트의 관점에서 작업해야 합니다. 예를 들어, 개체에 네 개의 태그가 있고 다섯 번째 태그를 추가하려면 현재 세트를 읽고 새 세트를 추가 한 다음 전체 세트를 업데이트해야 합니다.

태그는 Cross-Region Replication를 통해 영역간에 복제 될 수 있지만 원본 측의 IAM 정책은 s3:GetObjectVersionTaggings3:ReplicateTags 동작을 활성화해야 합니다.

태그는 한 달에 10,000 태그 당 $ 0.01의 비용이 듭니다. 태그 추가 또는 업데이트 요청 (PUT 및 GET)은 기본 요금으로 청구됩니다.

자세한 내용은 S3 객체 태깅을 참조하십시오.

S3 인벤토리
S3의 LIST 작업은 동기식이며, 한 번에 최대 1000 개의 개체를 반환합니다. 두 번째 LIST를 시작하는 데 사용할 수 있는 키와 함께 첫 번째 개체가 있는 곳을 선택합니다. 작은 크기의 버킷과 단일 스레드 프로그램에서 잘 작동하지만 개체가 많이 저장된 큰 버킷 또는 여러 스레드와 함께 사용하는 것은 어려울 수 있습니다.

많은 AWS 고객이 수천 또는 수억 개의 개체를 하나의 버킷에 저장하고 있으며, 이러한 버킷은 대개 워크 플로의 일환으로 매일 또는 매주 처리합니다.

S3 인벤토리를 사용하면 모든 버킷에 대한 일일 또는 주간 인벤토리 보고서를 받을 수 있습니다. 접두어를 사용하여 보고서를 필터링하거나 크기, 저장소 클래스 및 복제 상태와 같은 선택적 필드를 포함할 수 있습니다. 이 보고서는 계정의 S3 버킷 또는 적절한 권한 설정을 사용하여 다른 계정으로 보낼 수 있습니다.

다음은 www로 시작하는 모든 객체에 대해 WebStuff라는 일일 인벤토리 보고서를 요청하는 방법입니다.

또한, 최종 버킷 (jbarr-s3-inventory)에 쓰는 S3 권한을 부여해야 합니다. 다음은 제가 사용한 IAM 정책입니다 (더 자세한 것은 Granting Permission for Amazon S3 Inventory and Amazon S3 Analytics 을 참고하시기 바랍니다.)

인벤토리 메커니즘은 매니페스트, 매니페스트의 체크섬 및 데이터 파일 등 세 가지 파일을 만듭니다. 매니페스트는 체크섬과 함께 데이터 파일의 위치를 ​​포함합니다.

{
   "sourceBucket":"jbarr-public",
   "destinationBucket":"arn:aws:s3:::jbarr-s3-inventory",
   "version":"2016-11-30",
   "fileFormat":"CSV",
   "fileSchema":"Bucket, Key, Size, LastModifiedDate, ETag, StorageClass",
   "files":[
      {
         "key":"jbarr-public/DailyInventory/data/cf1da322-f52b-4c61-802a-b5c14f4f32e2.csv.gz",
         "size":2270,
         "MD5checksum":"be6d0eb3f9c4f497fe40658baa5a2e7c"
      }
   ]
}

압축을 푼 데이터 파일의 모습은 다음과 같습니다.

인벤토리 보고서를 사용하여 일별 또는 주간 처리 워크 플로우를 공급하는 경우, S3 Notifications을 확인 하시기 바랍니다. 체크섬 파일은 다른 두 파일 뒤에 쓰여 지므로 안전하게 이 파일을 사용하여 움직이는 파일을 사용할 수 있습니다. 또한, 수명 주기 정책을 사용하여 시간이 지남에 따라 축적되는 인벤토리 파일 컬렉션을 관리하는 것을 잊지 마십시오.

추가 보너스로 매일 또는 매주 보고서를 사용하면 여러 LIST 작업과 비교할 때 최대 50 %까지 절약 할 수 있습니다. 이 기능에 대한 자세한 내용은 S3 Storage Inventory를 참조하십시오.

S3 CloudWatch 통계 보기
S3는 이제 CloudWatch에 스토리지, 개체 요청 및 데이터 전송량 통계 등을 게시 할 수 있습니다. 스토리지 통계치는 매일 보고되며 추가 비용 없이 제공됩니다. 개체 요청 및 데이터 전송량은 1 분 간격으로 (일부 처리 지연 후) 사용할 수 있으며, 표준 CloudWatch 요금으로 청구됩니다. S3 애널리틱스의 경우와 마찬가지로 CloudWatch 측정 항목은 전체 버킷 또는 접두어 또는 태그를 통해 선택한 하위 집합에 대해 수집 및 보고 될 수 있습니다.

전체 측정 항목은 다음과 같습니다.

Storage Requests Data Transfer
  • Bucket Size Bytes
  • Number Of Objects
  • GET
  • LIST
  • PUT
  • POST
  • DELETE
  • ALL
  • HEAD
  • 4xx Errors
  • 5xx Errors
  • Total Request Latency
  • First Byte Latency
  • Bytes Uploaded
  • Bytes Downloaded

위의 측정 항목은 S3 및 CloudWatch 콘솔에서 사용할 수 있습니다. 아래  기존 버킷 S3 Console에서 총 요청 대기 시간은 다음과 같습니다.

View in CloudWatch를 클릭하고 원하는 측정 항목에 대한 CloudWatch 알람을 설정할 수 있습니다. 아래는 버킷이 100MB 이상으로 커지면 알림을 받고자 하는 경우입니다.

더 자세한 것은 How Do I Configure Request Metrics for an S3 Bucket?을 참고하시기 바랍니다.

정식 출시
본 기능은 작년 말부터 사용할 수 있습니다. 참고로 Amazon S3 관리 콘솔 역시 새로운 디자인으로 업데이트 되었습니다.  새로운 디자인에 대한 사항은 Introduction to the New Amazon S3 Console 에서 동영상으로 확인할 수 있습니다.

Jeff;

이 글은 S3 Storage Management Update – Analytics, Object Tagging, Inventory, and Metrics의 한국어 번역입니다.

AWS 스토리지 업데이트 – S3 및 Glacier 가격 인하 및 Glacier 추가 추출 옵션

2006년 Amazon S3 공개를 통해 “사용한 만큼 지불한다”는 비용 모델과 함께 1GB당 월 15센트의 가격 체계를 처음 공개하였습니다. 10년 동안 처음 가격에서 80% 인하 되어 글로벌 전체 리전에 적용되었습니다. 또한, 정적 웹 호스팅, VPC 연동, IPv6 지원, S3 Infrequent Access 옵션 등의 기능을 추가했습니다.

많은 AWS 고객이 법적 혹은 업무 규정에 따라 중요한 데이터를 지속적으로 보관해야 하는 요구 사항에 맞추어 2012년 Glacier를 공개하고, 데이터 생명 주기에 따라 저장 및 백업 방법을 선택할 수 있게 되었습니다.

이를 기반으로 오늘 S3 표준 스토리지와 Glacier 스토리지의 가격 인하 소식과 Glacier의 새로운 데이터 추출 옵션을 소개합니다.

S3 및 Glacier 가격 할인
AWS 고객들은 이미 잘 알고 있듯이 지속적으로 인프라 비용을 절감하고, 이를 고객에게 돌려 드리는 AWS 가격 인하를 지속하고 있습니다. 아래와 같이 2016년 12월 1일 부터 Amazon S3의 표준 스토리지에 대해 GB당 가격을 리전 마다 인하합니다. 12월 영수증에 자동으로 인하된 가격에 따라 비용이 낮아져서 반영됩니다.

리전 별 0-50 TB
($ / GB / 월)
51 – 500 TB
($ / GB / 월)
500+ TB
($ / GB / 월)
  • US East (Northern Virginia)
  • US East (Ohio)
  • US West (Oregon)
  • EU (Ireland)

(할인 폭 23.33% – 23.64%)

$0.0230 $0.0220 $0.0210
  • US West (Northern California)

(할인 폭 20.53% – 21.21%)

$0.0260 $0.0250 $0.0240
  • EU (Frankfurt)

(할인 폭 24.24% – 24.38%)

$0.0245 $0.0235 $0.0225
  • Asia Pacific (Singapore)
  • Asia Pacific (Tokyo)
  • Asia Pacific (Sydney)
  • Asia Pacific (Seoul)
  • Asia Pacific (Bombay)

(할인 폭 16.36% – 28.13%)

$0.0250 $0.0240 $0.0230

위의 표에서 보시다시피 6개의 요금 범위를 3개로 단순화 시켰습니다. 또한, Glacier 스토리지에 대해서도 가격 인하를 단행하여, 서울 및 도쿄 리전의 경우, 월별 $0.0050로 기존 $0.007과 비교했을 때 28% 인하하였습니다. (이는 2012년 처음 서비스 공개 시 $0.010를 30% 인하한 후 두 번째입니다.)

리전 별 GB당 저장 요금
  • US East (Northern VA)
  • US West (Oregon)
  • US East (Ohio)
  • EU (Dublin)
$0.0040
  • EU (Frankfurt)
$0.0045
  • US West (Northern CA)
  • APAC (Tokyo)
  • APAC (Sydney)
  • APAC (Seoul)
  • APAC (Bombay)
  • China (Beijing)
$0.0050
  • GovCloud
$0.0060

이러한 낮은 가격은 고객 여러분께서 저희 스토리지 서비스를 신뢰해 주셔서 수 조(兆)개의 객체를 저장해 주신 결과입니다.  새로운 기능을 추가 할 때마다 얻은 고객 피드백을 바탕으로 클라우드 스토리지 플랫폼의 진정한 가치는 빠르고 꾸준하게 발전하고 있습니다. 고객 여러분의 피드백을 기반으로 새로운 기능을 출시하는 것에 대해 매우 만족하고 있다고 말해 주시기도 합니다.

신규 Glacier 추출 옵션
많은 AWS 고객 여러분께서 Amazon Glacier를 계층형 스토리지 아키텍처 저장용 구성 요소로 사용합니다. Glacier는 데이터를 처리 및 가치를 추출하기 대용량 클라우드 기반 컴퓨팅 성능을 사용하면서도 규정 준수 요구 사항 (조직 또는 규정)을 충족 할 수 있도록 합니다.

오늘 우리는 Glacier에 저장한 데이터를 위한 두 가지 새로운 검색 옵션을 추가합니다. 비용을 조금 더 내고 데이터 검색을 신속하게 처리하거나 속도가 중요하지 않을 경우 추출 비용을 낮출 수 있습니다. Glacier는 저장한 데이터의 양과 추출한 데이터 속도에 기초하여 가격 모델을 가지고 있습니다. 하지만, 이를 고객에게 쉽게 설명하기 어려운 부분이 있어서, 이를 GB 기반의 데이터 추출 비용 방식으로 대체합니다.

미디어 및 엔터테인먼트 고객사 예를 들어 TV 동영상 저장 같은 경우, 필요 시 빠르게 파일을 찾아야 할 필요가 있습니다. 또한 헬스케어 분야에서도 특정 상황에서 메디컬 영상이나 게놈 데이터를 빠르게 받아야 합니다.  또는, 어떤 고객은 시간과 상관 없이 5-12시간 이내에 데이터를 완벽하게 다시 얻을 수 있기만 하면 되기도 합니다.

여러분의 요구 사항에 맞추어 아래 3가지 데이터 추출 옵션을 선택하실 수 있습니다. (원래 비율 기반의 추출 모델은 더 이상 유효하지 않습니다.)

표준(Standard) : Glacier가 이미 제공하고 있던 것의 새로운 이름입니다. 데이터를 몇 시간(대개 3-5시간)에 GB당 $0.01 가격으로 매 1,000회 요청 당 $0.05 입니다.

신속(Expedited) : 빠른 시간 내에 데이터를 추출 할 수 있는 신규 옵션으로  1- 5 분 내에 데이터 추출 가능합니다. 만약 Glacier에서 100TB 이상을 저장하면서 자주 꺼내게 되신다면, 현재 모델이 최상의 조건입니다. (만약 그 이하라면, S3의 Infrequent Access storage class 가 최적의 선택입니다.) 추출 요금은 GB당 $0.03 이고 요청당 $0.01 입니다.

대량(Bulk) : 추출 시간이 그렇게 중요하지 않는 일반적인 경우에 해당되며, 평균 5-12시간 정도가 걸리고 가격은 GB당 $0.0025 per GB (표준 대비 75% 저렴함) 및 1,000회 요청당   $0.025입니다. 대량 추출은 대용량 데이터를 하루 내에 꺼내야 할 때 최적의 모델입니다.

특정 옵션을 선택하기 곤란할 때, InitiateJob 요청을 하면 먼저 표준 방식으로 시작된 후, 작업 상황을 보면서 새로운 추출 모델로 바뀌게 됩니다.  더 자세한 사항은  Glacier FAQ의 데이터 추출 방식 을 참고하시기 바랍니다.
– Jeff;

이 글은 AWS Storage Update – S3 & Glacier Price Reductions + Additional Retrieval Options for Glacier의 한국어 요약본입니다.

Amazon Aurora 업데이트 – Lambda Function 호출 및 S3 데이터 읽기 지원

AWS 서비스들은 그 자체만으로도 훌륭하지만, 서로 결합함으로써 더욱 다양한 서비스를 만들 수 있습니다. 저희의 서비스 모델은 각 서비스를 선택하여 학습하여 경험을 쌓은 다음, 다른 서비스와 결합 및 확장하는 레고블럭을 조립하는 것 같은 방식입니다. 이를 통해 각 서비스를 다양하게 활용할 기회와 함께 고객의 요구에 따라 서비스 로드맵에 반영할 수 있습니다.

오늘은 이와 관련하여 MySQL 호환 관계형 데이터베이스 서비스인 Amazon Aurora에 두 가지 기능을 추가합니다.

  • Lambda 함수 호출 – Amazon Aurora 데이터베이스의 스토어드 프로시저(stored procedures)에서 AWS Lambda 함수를 호출 할 수 있습니다.
  • S3 데이터 읽기 – Amazon Simple Storage Service (S3) 버킷에 저장된 데이터를 Amazon Aurora 데이터베이스에서 읽을 수 있습니다.

위의 두 가지 기능은 다른 AWS 서비스를 연계하기 위해 Amazon Aurora에 적절한 권한을 부여해야합니다. IAM 정책(Policy) 및 IAM 역할(Role)을 만들고, 그 역할을 Amazon Aurora 데이터베이스 클러스터에 부여합니다. 자세한 단계는Authorizing Amazon Aurora to Access Other AWS Services On Your Behalf를 참조하십시오.

Lambda 함수 통합
관계형 데이터베이스 트리거(trigger)와 스토어드 프로시저를 함께 사용하여 본 기능을 수행할 수 있습니다. 트리거는 특정 테이블 작업 전후에 수행 할 수 있습니다. 예를 들어, Amazon Aurora는 MySQL과 호환성이 있기 때문에 INSERT, UPDATE, DELETE 작업에 트리거를 지원합니다. 스토어드 프로시저는 트리거에 대한 응답에서 실행 가능한 스크립트입니다.

Lambda 함수를 스토어드 프로시저를 사용하여, Aurora 데이터베이스와 다른 AWS 서비스를 묶을 수 있습니다. Amazon Simple Email Service (SES)를 이용하여 이메일을 보내거나 Amazon Simple Notification Service (SNS)를 이용해 알림을 보내고, Amazon CloudWatch에 사용자 정의 통계를 추가하거나, Amazon DynamoDB 테이블을 업데이트할 수 있습니다.

그 외에도 복잡한 ETL 작업 또는 워크 플로우, 데이터베이스 테이블에 대한 감사, 성능 모니터링 및 분석 등의 용도로도 사용할 수 있습니다.

스토어드 프로시저에서 mysql_lambda_async 프로시저를 호출 하면 됩니다. 이 프로시저는 비동기적으로 주어진 Lambda 함수를 실행하기 위해 함수 실행 완료를 기다리지 않고 처리를 종료합니다. Lambda 함수에 이용하는 AWS 서비스 및 자원에 대한 권한을 부여해야합니다.

자세한 내용은 Invoking a Lambda Function from an Amazon Aurora DB Cluster를 참조하십시오.

S3 데이터 읽기

또한, AWS의 주요서비스인 Amazon S3 버킷에 저장된 데이터를 직접 Aurora에 가져올 수 있게 되었습니다 (지금까지는 한 번 EC2 인스턴스에 다운로드 한 후 가져와야했습니다.)

Amazon Aurora 클러스터에서 접근 가능하면, AWS 어느 리전에 데이터가 배치되어 있어도 읽기 가능합니다. 형식은 텍스트 또는 XML 형식을 지원합니다.

텍스트 형식의 데이터를 가져 오기 위해서는, LOAD DATA FROM S3 명령을 이용합니다. 이 명령은 MySQL의 LOAD DATA INFILE과 거의 같은 옵션을 지원합니다. 그리고, 압축 데이터는 현재 지원하지 않습니다. 특정 행이나 필드 구분자와 문자 집합 설정이 가능하고, 지정한 행과 열 수를 무시하고 통합 할 수 있습니다.

XML 형식 데이터를 가져 오기 위해 새로운 LOAD XML from S3

Xml
<row column1="value1" column2="value2" />
...
<row column1="value1" column2="value2" />

또는 아래와 같습니다.

Xml
<row>
  <column1>value1</column1>
  <column2>value2</column2>
</row>
...

또는 아래와 같습니다.

Xml
<row>
  <field name="column1">value1</field>
  <field name="column2">value2</field>
</row>
...

더 자세한 사항은 Loading Data Into a DB Cluster From Text Files in an Amazon S3 Bucket 문서를 참고하십시오.

정식 출시
본 신규 기능은 오늘부터 이용하실 수 있습니다! 추가로 요금이 부과되지 않지만, 일반적인 Amazon Aurora, Lambda, S3 요금이 발생합니다.

Jeff;

이 글은 Amazon Aurora Update – Call Lambda Functions From Stored Procedures; Load Data From S3의 한국어 번역입니다.

IPv6 지원 업데이트 – CloudFront, WAF 및 S3 Transfer Acceleration

최근 Amazon S3 IPv6 지원 발표 이후, 이번에는 Amazon CloudFront, Amazon S3 Transfer AccelerationAWS WAF와 60개가 넘는 모든 CloudFront 엣지 로케이션에서도 IPv6 지원이 이용 가능합니다. AWS는 모든 자율 시스템 네트워크(ASN)에서 IPv6를 활성화하기 위한 단계적 마이그레이션 프로세스를 오늘부터 시작하고, 앞으로 몇 주에 걸쳐 모든 네트워크에서 확장 할 예정입니다.

CloudFront IPv6 지원
이제 각 Amazon CloudFront 배포 버전마다 IPv6 지원을 활성화 할 수 있습니다. IPv6을 사용하여, CloudFront 엣지 로케이션에 연결하는 방문자와 네트워크는 자동으로 IPv6 콘텐츠를 가져옵니다. IPv4를 사용하여 연결하는 경우, 예전처럼 작동합니다. 오리진(Origin) 서버 연결은 IPv4를 사용합니다.

새로 만든 배포 게시 지점은 자동으로 IPv6을 사용합니다. 기존 게시 지점을 변경하려면, Enable IPv6를 선택합니다. 이것은 콘솔 또는 CloudFront API에서 설정할 수 있습니다.

새로운 기능의 중요 사항은 아래를 참조하십시오.

  • 별칭 레코드(Alias Records) – 게시 지점에서 IPv6 지원을 활성화하면, DNS 항목은 AAAA 레코드를 포함해서 업데이트 합니다. Amazon Route 53과 별칭 레코드를 사용하여, 배포 도메인 전체 또는 일부를 가르키고 있는 경우, 그 도메인에 AAAA 별칭을 추가 해야합니다.
  • 로그 파일(Log Files) – CloudFront 접속 로그를 사용하는 경우, IPv6 주소가 c-ip 필드에 표시되므로, 로그 처리 시스템이 이를 처리할 수 있도록 해야 합니다.
  • 신뢰할 수 있는 서명(Trusted Signers) – 신뢰할 수 있는 서명 및 IP 주소 화이트 리스트를 함께 사용하는 경우, IP 허용 목록과 실제 내용 IPv4/IPv6 배포를 갖추는 신뢰된 서명과 각 URL의 IPv4 제한 배포 지점을 사용할 것을 적극 권장합니다. 이 모델에서는 IPv4 주소를 사용하여 전송 한 서명 요청에 서명한 것으로, 콘텐츠 요청이 화이트리스트에 실려 있지 않은 다른 IPv6 주소에서 주어진 같은 문제를 해결 할 수 있습니다.
  • CloudFormation – CloudFormation 지원을 준비 중 이번 출시에서는 CloudFormation 템플릿에서 만든 배포판에서 IPv6를 사용할 수 없습니다. 기존 스택을 업데이트 할 때, 스택에서 참조 배포판 설정 변경은 없습니다.
  • AWS WAF – AWS WAF와 CloudFront를 함께 사용하는 경우 IPv6 주소의 화이트리스트 또는 블랙리스트에 연결 되도록, WebACL과 IP 규칙 세트를 업데이트 해야합니다.
  • Forwarded 헤더 (Forwarded Headers) – 배포 지점에서 IPv6를 사용하는 경우, X-Forwarded-For 헤더에 IPv6 주소가 포함합니다. 오리진(Origin)이 형식 헤더를 처리 할 수 ​​있는지 확인하십시오.

자세한 내용은 IPv6 Support for Amazon CloudFront를 참고하십시오.

AWS WAF IPv6 지원
AWS WAF는 애플리케이션 레이어에서 발생하는 공격으로부터 응용 프로그램을 보호합니다. (자세한 사항은 AWS WAF 신규 서비스를 참고하십시오.)

AWS WAF가 IPv4 또는 IPv6 주소를 통해 요청을 검사 할 수 있습니다. IPv6와 일치하는 웹 접근 목록(ACL)을 만들 수 있습니다. 자세한 내용은 Working with IP Match Conditions를 참조하십시오.

기존 WAF 기능은 모든 IPv6 지원 성능에 보이는 변화는 없습니다. IPv6는 WAF가 수집 되어 표시한 샘플 요청으로 표시됩니다.

S3 Transfer Acceleration IPv6 지원
Amazon S3 전송 가속 기능이 IPv6를 지원하게 되었습니다. (자세한 내용은 AWS 스토리지 업데이트 – Amazon S3 Transfer Acceleration 참조). 업로드에 사용할 수 있는 이중 스택 엔드 포인트에 쉽게 전환 할 수 있습니다. 다음과 같이 변경 하면됩니다.

https://BUCKET.s3-accelerate.amazonaws.com

에서

https://BUCKET.s3-accelerate.dualstack.amazonaws.com

클라이언트 객체 생성 및 듀얼 스택 전송의 활성화를 가능하게 하는 AWS SDK for Java 사용 코드는 다음과 같습니다.

Java
AmazonS3Client s3 = new AmazonS3Client();
s3.setS3ClientOptions(S3ClientOptions.builder().enableDualstack().setAccelerateModeEnabled(true).build());

대부분 응용 프로그램과 네트워크 스택은 자동으로 IPv6 사용을 선호하는 경향이 있기 때문에 더 이상의 설정은 필요하지 않습니다. IPv6 주소와 함께 사용하기에 기능 동작에 문제가 없는지 확인하기 위해 패킷 IAM 정책을 검토하는 것이 좋습니다. 자세한 내용은 IPv6를 사용하여 Amazon S3에 요청 전송을 참조하십시오.

테스트를 잊지 마세요!
AWS 리전에 IPv6 연결에 제한이 있거나 존재하지 않는 경우, 대신 IPv4를 사용합니다. 이전에 블로그에서도 언급했지만, IPv6를 지원하도록 클라이언트 시스템을 구성 할 수 있습니다. 그러나, 이 경우 IPv6 패킷을 인터넷에 라우팅 설정하지 않은 네트워크에 연결해야 합니다. 이러한 이유에서 IPv6로 전환하기 전에 응용 프로그램 수준에서 네트워크 수행 지점 간 연결 테스트를 수행하는 것이 좋습니다.

Jeff;

이 글은 IPv6 Support Update – CloudFront, WAF, and S3 Transfer Acceleration의 한국어 버전입니다.

Amazon S3, IPv6 주소 지원 시작

오늘 부터 Amazon S3 버킷에 “dual-stack” 엔드포인트를 통해 IPv6 주소를 제공합니다. DNS 조회를 할 경우, “A” 레코드에 대해서는 IPv4, “AAAA” 레코드에 대하서는 IPv6 주소를 반환합니다. 클라이언트 환경에 따라, 자동적으로 AAA 주소를 선호해서 IPv6 주소로 연결하게 됩니다.

IPv6f를 통한 S3 접근하기
IPv6로 S3내 콘텐츠에 접근하기 위해서는 아래와 같이 듀얼 스택 엔드포인트로 접근해야 합니다.

http://BUCKET.s3.dualstack.REGION.amazonaws.com

또는

http://s3.dualstack.REGION.amazonaws.com/BUCKET

만약 AWS Command Line Interface (CLI)이나 AWS Tools for Windows PowerShell를 사용하는 경우, --enabledualstack 플래그를 추가합면 됩니다.

현재 AWS SDKs의 경우, use_dualstack_endpoint 설정을 지원하도록 업데이트 하는 중이며, 다음 주에는 추가될 것으로 예상합니다. 향후 세부적인 사항은 SDK 가이드 문서를 참고하시기 바랍니다.

알아두시면 좋은 점
아래 사항은 IPv6로 유연하게 전환하기 위해 알아두시면 좋은 점들입니다.

  • 버킷 및 IAM 정책 – 만약 IP 주소 기반으로 접근 제어를 하고 있다면, 신규 엔드 포인트로 바꾸기 전에IPv6 주소를 추가해야 합니다. 그렇지 않으면, 클라이언트 동작에 문제가 생겨서 AWS 자원 접근이 안될 수 있습니다. 접근 정책을 기존의 IPv4 기반에 IPv6 주소로 함께 대응할 필요가 있습니다.
  • IPv6 연결성 – 네트워크 스택이 IPv6를 선호하기 때문에 특정 상태에서 연결 이슈가 발생 할 수 있습니다. 예를 들어, IPv6가 설정된 클라이언트가 IPv6 패킷을 라우팅하지 못하는 라우터에 연결되는 경우 등 듀얼 스택 엔드포인트를 적용하기 전에 이 부분에 대한 테스트가 필요합니다.
  • 로그 정보 – 접속 로그에는 IPv4 혹은 IPv6 주소가 기재됩니다. 내부 혹은 서드파티 도구로 로그를 분석하는 경우, IPv6 주소를 인지할 수 있도록 변경해야 합니다.
  • S3 기능 지원 – IPv6 지원은 웹 사이트 호스팅, S3 전송 가속 기능 및 BitTorrent 접근 기능을 제외한 모든 S3 기능에 적용됩니다.
  • 리전 지원 – IPv6 지원은 AWS GovCloud (US)을 포함한 모든 AWS 리전에서 사용 가능하며, China (Beijing) 리전에서는 지원하지 않습니다.

Jeff;

이 글은 Now Available – IPv6 Support for Amazon S3의 한국어 요약본으로 AWS Summit 뉴욕 행사에서 신규로 발표된 소식입니다.

Amazon ElastiCache 업데이트 – Redis 스냅샷 S3에 저장하기

Amazon ElastiCache는 인기있는 오픈 소스 인메모리 캐시 엔진인 MemcachedRedis를 지원하고 있습니다. Memcached는 느린 하드 디스크 기반 데이터베이스의 쿼리 결과를 빠르게 캐싱할 수 있으며, Redis는 빠르고 영구적인 키-밸류 데이터를 저장할 수 있는 데이터 저장소입니다. Redis는 복제본을 사용하여 고가용성으로 장애를 극복하고, 구조적 데이터 값을 지원합니다.

오늘 Redis 사용자 여러분께 흥미롭고 주목할 만한 새로운 기능을 출시합니다. 실행 중인 Redis 캐시 클러스터의 스냅 샷을 만드는 것은 이미 가능합니다. 스냅샷은 영구적 백업이나 새로운 캐시 클러스터를 만드는 데 사용할 수 있습니다. 다시 한번 캐시 클러스터에서 스냅샷을 만드는 방법을 살펴 보겠습니다.

이제 Redis 스냅샷을 S3 버킷으로 내보낼 수 있습니다. S3 버킷은 스냅샷과 동일한 리전에 존재하고, ElastiCache에 적절한 IAM 권한 (List, Upload / Delete, View 권한)을 부여해야합니다. 이 기능은 아래 사용 사례에 적합합니다.

  • 재해 복구 – 스냅샷을 다른 리전으로 복사 저장
  • 데이터 분석 – S3 스냅샷 데이터에서 사용 상황 분석 가능
  • 데이터 배포 – 다른 리전에 스냅샷을 통해 새로운 Redis 캐시 클러스터 구축

스냅샷 내보내기
스냅샷을 내보내려면, 스냅샷을 선택하고 Copy Snapshot을 클릭하십시오.

버킷의 권한을 확인하십시오. (자세한 내용은 Exporting Your Snapshot을 참고하세요.)

원하는 대상 S3 버킷명과 스냅샷 이름을 정합니다.

ElastiCache는 스냅 샷을 내 지정된 S3 버킷에 스냅 샷을 저장합니다 :

파일은 표준 Redis RDB file로 저장할 수 있습니다.

또한, 응용 프로그램 등의 코드나 코맨드 라인 모드에서 비슷한 작업을 수행 할 수 있습니다. 대상 S3 버킷을 지정하고 프로그램 코드에서 호출하는 경우 CopySnapshot 명령 줄에서 copy-snapshot 명령을 사용하십시오.

이 기능은 바로 이용 가능하며, 오늘부터 사용할 수 있습니다! 내보내기에는 요금은 들지 않고 일반 S3 스토리지 요금만 부과됩니다.

Jeff;

이 글은 Amazon ElastiCache Update – Export Redis Snapshots to Amazon S3의 한국어 번역입니다.

AWS 스토리지 업데이트 – Amazon S3 전송 가속 기능 및 대용량 SnowBall 지원

AWS 개발팀들은 어떻게 하면 기존 환경의 데이터를 더 빠르고 간단하게 클라우드로 이전하 수 있을지 많은 고민과 더불어 신규 기능을 구현해 왔습니다. 우리는 초기 부터 Amazon S3에 기본적인 PUT 동작을 시작으로 멀티 파트 업로드을 추가했고, 여러분이 직접 외장 하드 디스크 전달하면 처리해 주는 것으로 부터 시작해서 좀 더 쉽게 이러한 기능을 제공하기 위해 AWS Import/Export Snowball 서비스를 작년 AWS re:Invent 에서 출시하였습니다. ( 더 자세한 것은 AWS Import/Export Snowball – 전용 스토리지로 1주일에 1페타바이트 전송하기 참고)

오늘 AWS는 Amazon S3로 부터 Snowball  서비스에 이르기 까지 데이터 마이그레이션을 좀 더 편리하고 빠르고 할 수 있는 중요한 신규 기능 몇 가지를 출시합니다.

Amazon S3 전송 가속화 – Amazon S3로 데이터를 전송할 때, AWS의 엣지 인프라의 네트워크 프로토콜을 최적화 하여 전송 속도를 높이는 기능입니다. 국가 내에서 전송할 때 최소 50%에서 최대 500%까지의 전송 속도 증가를 가져왔으며, 경우에 따라 더 빠른 속도를 제공할 수 있게 되었습니다.

대용량 Snowballs 리전 적용 추가 – 신규 대용량 스노우볼 장치 (80 테라바이트)를 선 보이면서 2개의 미국 내 리전 및 2개의 국제 리전에 출시합니다.

Amazon S3 전송 가속화
AWS 엣지 로케이션은 50여개가 넘는 지역별 콘텐츠 배포 네트워크입니다. 주로 Amazon CloudFront 를 통한 콘텐츠 전송 및 Amazon Route 53에서의 빠른 DNS 응답을 제공하는 용도로 사용해 왔습니다. 오늘 부터, 엣지 로케이션을 통해 Amazon S3 데이터 업로드 가속 기능을 추가합니다. 이를 통해 대륙간 데이터 이동을 할 때 이점을 얻게 되며, 대용량 객체 및 콘텐츠 업로드 시 빠른 인터넷 속도를 얻을 수 있습니다.

엣지 네트워크는 여러분의 데스크톱 및 기존 데이터 센터 환경에서 원하는 S3 버킷의 연결 가교가 됩니다. 관리 콘솔에서 전송 가속화 기능을 추가한 후, 버킷의 엔드 포인트를 BUCKET_NAME.s3-accelerate.amazonaws.com으로 설정하여 전송하면 됩니다. 별다른 추가 설정은 필요 없으며, 이를 통해 TCP 연결은 자동으로 가장 빠른 AWS 엣지 로케이션으로 연결되게 됩니다. 전송 가속화를 통해 S3에 데이터가 업로드 되면 AWS가 관리하는 백본 네트워크에서 최적화된 네트워크 프로토콜과 지속적인 엣지와 연결 등을 지원하게 됩니다.

저의 버킷에서 한번 직접 해보겠습니다. ( 버킷명: jbarr-public):

Transfer Acceleration을 설정 한 후, 원래 버킷 엔드 포인트는 https://jbarr-public.s3.amazonaws.com/ 이지만,  이를 https://jbarr-public.s3-accelerate.amazonaws.com/ 로 바꾸기면 하면 됩니다. 가속 다운로드에서도 같은 URL을 사용할 수 있습니다.

네트워크 설정이 시간마다 혹은 엣지마다 달라질 수 있기 때문에, 전송 가속 기능이 업로드 성능을 높이는지에 대해 신경쓰기만 하면 됩니다. 전송 가속도 기능은 기가 바이트당 $0.04 이며, 추가로 미리 내어야 하는 비용은 없습니다.

Amazon S3 전송 가속화 속도 테스트 비교 를 통해 이 기능이 얼마나 도움이 되는지 확인하실 수 있습니다. (참고로 제가 위치한 시애틀에서 서울 리전에서 일반 S3 업로드 속도 대비 822%의 속도 증가가 있는 것을 보실 수 있습니다.)

여러분이 보시다시피, 내가 위치한 지역과 가까운 리전과 타겟 사이의 거리에 따라 업로드 성능은 더 빨라지고 있는 것을 보실 수 있습니다.

본 기능에 대한 좀 더 자세한 사항은 Getting Started with Amazon S3 Transfer Acceleration in을 참고하시기 바라며, 오늘 부터 베이징 리전 및 AWS GovCloud (US)를 제외한 모든 리전에서 사용 가능합니다.

대용량 Snowballs 리전 적용 추가
많은 AWS 고객이 AWS Import/Export Snowball을 통해 대용량 데이터를 AWS 클라우드로 이전하고 있습니다. 아래는 GE Oil & Gas에서 스노우볼 기기를 통해 활용하는 사진입니다.

Ben Wilson (CTO of GE Oil & Gas)는 LinkedIn에 아래와 같은 글을 올렸습니다.

“PIGs 와 Snowballs –천국의 조합!! AWS Snowball 25 TB 파이프라인 PIG 데이터를 AWS에서 관리하게 되었습니다.  GE PIG 데이터를 이제 쉽게 가져올 수 있게 되었고, 이러한 AWS 신규 기능을 사용해 보는 것은 늘 즐거운 일입니다!”

오늘 부터 AWS Snowball은 아래 리전에서 사용 가능합니다: AWS GovCloud (US), US West (Northern California), Europe (Ireland), Asia Pacific (Sydney). 앞으로 서울 리전을 포함해서 향후 계속해서 지원을 추가할 예정입니다.

기존 Snowball  장치인 50테라 바이트 용량의 경우도 그대로 지원하기 때문에  US East (Northern Virginia), US West (Oregon), US West (Northern California), 및 AWS GovCloud (US) 리리전에서 원하는 용량을 선택할 수 있습니다.  Europe (Ireland)Asia Pacific (Sydney) 리전에서는 80테라바이트 기기를 사용할 수 있습니다. 아래 화면에서 원하는 장치를 선택 가능합니다. 

좀 더 자세한 사항은 Snowball FAQ  및 Snowball Developer Guide를 참고하시기 바랍니다.

Jeff;

이 글은 AWS Storage Update – Amazon S3 Transfer Acceleration + Larger Snowballs in More Regions의 한국어 번역입니다.

Amazon Kinesis 업데이트 – Amazon Elasticsearch Service 통합, 샤드 통계 및 시간 기반 반복 기능

Amazon Kinesis는 대용량 스트리밍 데이터를 클라우드에서 손쉽게 처리할 수 있도록 도와 줍니다.

Amazon Kinesis 플랫폼은 3개의 서비스로 구성되어 있습니다: Kinesis Streams은 개발자가 자신의 스트리밍 데이터 처리 애플리케이션을 구현할 수 있습니다; Kinesis Firehose를 통해 스트리밍 데이터를 저장하고 분석하기 위해 AWS에 저장하는 기능에 초점을 맞추었습니다; Kinesis Analytics 를 통해 스트리밍 데이터를 표준 SQL을 통해 분석 할 수 있습니다.

많은 AWS 고객이 스트리밍 데이터를 실시간으로 수집 · 처리하는 방식으로 Kinesis Streams와 Kinesis Firehose을 이용​​하고 있습니다. 이는 완전 관리 서비스이기 때문에 사용 편의성을 높아 스트리밍 데이터 처리를 위한 인프라를 직접 관리하는 대신 응용 프로그램에 개발하는 시간에 투자를 할 수 있다는 장점이 있습니다.

오늘 Amazon Kinesis Streams와 Kinesis Firehose 관한 3개의 새로운 기능을 신규 발표합니다.

  • Elasticsearch 통합– Amazon Kinesis Firehose는 Amazon Elasticsearch Service에 스트리밍 데이터를 전달할 수 있습니다..
  • 강화된 모니터링 수치 제공– Amazon Kinesis는 샤드 단위 메트릭을 CloudWatch로 매 분당 보낼 수 있습니다.
  • 유연성 확보– Amazon Kinesis에서 시간 기반의 반복자를 이용하여 레코드를 수신 할 수 있습니다.

Amazon Elasticsearch Service 통합
Elasticsearch
는 인기있는 오픈 소스 검색 · 분석 엔진입니다. Amazon Elasticsearch Service는 AWS 클라우드에서 Elasticsearch를 손 쉽게 설치하고, 높은 확장성을 가지고 운영할 수 있는  관리 서비스입니다.  오늘 부터 Kinesis Firehose 데이터 스트림을 Amazon Elasticsearch Service 클러스터에 배포 할 수 있게되었습니다. 이 새로운 기능은 서버의 로그 및 클릭 스트림, 소셜 미디어 트래픽 등으로 인덱스를 생성하고 분석 할 수 있습니다.

전송 받은 레코드 (Elasticsearch 문서)는 지정한 설정에 따라 Kinesis Firehose에서 버퍼링 된 후,여러 문서를 동시에 인덱스를 만들 수 있도록 벌크 요청을 사용하여 자동으로 클러스터를 추가합니다. 또한, 데이터는 Firehose로 전송하기 전에 UTF-8로 인코딩 된 단일 JSON 개체에 두어야 합니다. (관련 정보는 Amazon Kinesis Agent Update – New Data Preprocessing Feature를 참조하십시오).

이제 AWS 관리 콘솔을 통한 설정 방법을 알아보겠습니다. 대상(Amazon Elasticsearch Service)를 선택하고 전송 스트림의 이름을 입력합니다. Elasticsearch 도메인 (livedata 예제)을 선택 인덱스로 지정하고, 인덱스 주기(없음, 시간별, 매일, 매주, 매월)를 선택합니다. 또한, 모든 문서 또는 실패한 문서의 백업을받을 S3 버킷을 지정합니다 :

그리고 버퍼의 크기를 지정하고 S3 버킷에 전송되는 데이터의 압축 및 암호화 옵션을 선택합니다. 필요에 따라 로깅을 사용하고 IAM 역할을 선택합니다 :

1분 정도 이후에 스트림이 준비 됩니다 :

I can view the delivery metrics in the Console:

스트리밍 데이터가 Elasticsearch에 도달 한 후에는 Kibana와  Elasticsearch 쿼리 언어에 의해 데이터 시각화를 할 수 있습니다.

즉, 통합을 통해 여러분의 스트리밍 데이터를 수집하고 Elasticsearch에 전달 하기 위한 처리 방법은 매우 간단합니다. 더 이상 코드를 작성하거나 자체 데이터 수집 도구를 만들 필요가 없습니다.

샤드 기반 통계 모니터링
모든 Kinesis 스트림은 하나 이상의 샤드로 구성되어 있으며, 모든 샤드는 일정량의 읽기 · 쓰기의 용량을 가지고 있습니다. 필요에 따라 스트림에 샤드를 추가하면 스트림의 용량은 증가합니다.

여러분은 각 샤드의 성능을 파악하기위한 목적으로 샤드 단위의 통계 기능을 활성화 할 수 있게되었습니다. 샤드 당 6개의 메트릭이 있습니다. 각 통계는 1 분에 한 번 보고되고, 일반 통계 단위의 CloudWatch 요금이 부과됩니다.  이러한 신규 기능은 특정 샤드에 부하가 편중되지 않았는지, 다른 샤드와 비교하여 확인하거나 스트리밍 데이터의 전송 파이프 라인을 통해 비효율적 인 부분을 발견 및 변경할 수 있게 됩니다. 

아래에는 새로이 측정되는 수치입니다.

IncomingBytes샤드로 PUT이 성공한 바이트 수.

IncomingRecords샤드로 PUT이 성공한 레코드.

IteratorAgeMilliseconds샤드에 대한 GetRecords 호출이 취소 된 마지막 레코드의 체류 시간 (밀리 초). 값이 0 인 경우, 읽은 레코드가 완전히 스트림에 붙어 있다는 것을 의미합니다.

OutgoingBytes샤드에서받은 바이트 수.

OutgoingRecords샤드에서받은 레코드 수.

ReadProvisionedThroughputExceeded – 매초 5 회 또는 2MB를 초과한 GetRecords 호출 수.

WriteProvisionedThroughputExceeded – 매 초 1000 기록 또는 1MB를 초과한 레코드의 수.

EnableEnhancedMetrics 를 호출하는 것으로  활성화 할 수 있습니다. 평소처럼, 일정 기간 동안 집계를 위해 CloudWatch API를 사용할 수 있습니다.

시간 기반 반복 기능
어떤 샤드에 GetShardIterator를 호출 시작점으로 지정하고, 반복 기능을 작성하여 애플리케이션에서 Kinesis 스트림 데이터를 읽을 수 있습니다. 기존의 시작점 선택 (시퀀스 번호 시퀀스 번호 뒤에 가장 오래된 기록, 가장 새로운 레코드)에 추가로 타임 스탬프를 지정할 수 있게되었습니다. 지정한 값 (UNIX 시간 형식)은 읽고 처리하려고하는 가장 오래된 레코드의 타임 스탬프를 나타냅니다.

Jeff;

이 글은 Amazon Kinesis Update – Amazon Elasticsearch Service Integration, Shard-Level Metrics, Time-Based Iterators의 한국어 번역입니다.

Amazon S3 VPC 엔드포인트, 서울 리전 지원 시작

지난해 5월 11일 Amazon Virtual Private CloudAmazon Simple Storage Service (S3)를 보다 편리하게 이용하기 위해 출시된 “Amazon S3용 VPC 엔드포인트”를 소개합니다. 오늘 부터 Asia-Pacific (Seoul) 리전에서 사용 가능 합니다.

Amazon S3는 안전하고 내구성 높은 확장 가능한 객체 스토리지 서비스입니다. Amazon VPC에서 클라우드 내부에 논리적으로 분리 된 영역을 확보하고 여기에 고객이 정의하는 가상 사설 네트워크를 만들어 서비스 할 수 있습니다.

VPC를 만들 때 보안 그룹액세스 제어 목록(ACLs) 에 의해 인바운드 및 아웃 바운드 트래픽을 제어 할 수 있습니다. 지금까지 EC2 인스턴스에서 공용 리소스에 액세스하려는 경우 인터넷 게이트웨이 또는 일부 NAT 인스턴스를 이용해야했습니다.

S3용 VPC Endpoint
VPC 엔드 포인트라는 개념을 통해 VPC에서 S3로 접근이 가능해집니다. VPC 엔드 포인트는 간단한 설정, 높은 신뢰성, 게이트웨이 및 NAT 인스턴스를 필요로하지 않는 안전한 S3 연결을 제공합니다.

개별 서브넷에서 실행중인 EC2 인스턴스는 동일한 리전에 있는 S3 버킷 객체 API 접근을 제어 할 수 있습니다. S3 버킷 정책을 이용​​하여, 어떤 VPC 또는 VPC 엔드 포인트에 접근하는 방법을 설정할 수 있습니다.

VPC Endpoint 생성 및 사용
VPC Endpoint는 AWS 관리 콘솔, AWS 명령어 모드 (CLI), AWS 윈도 파워셀 도구, and the VPC API를 활용할 수 있습니다. 이 글에서는 콘솔에서 새 엔드 포인트를 작성해 보도록 하겠습니다. 콘솔에서 VPC 대시 보드를 열고 리전을 선택하십시오. 네비게이션 바의 “Endpoints”항목을 클릭하십시오.

이미 여러 VPC 엔드 포인트가있는 경우이 목록에 표시됩니다.

“Create EndPoint”를 클릭하여 VPC를 선택하고, 필요한 경우 접근 정책을 변경하십시오.

VPC 엔드 포인트 접근 정책은 신뢰하지 못하는 S3 버킷에 대한 통신 허가 및 금지를 설정 할 수 있습니다. (기본적으로 모든 S3 버킷에 통신 할 수 있습니다.) 또한, 특정 VPC 또는 VPC 엔드 포인트로 부터 통신을 제어 할 수 있습니다. 이러한 접근 정책은 "aws:SourceVpc" 또는 "aws:SourceVpce" 조건으로 만들어 집니다. (자세한 내용은 기술 문서를 참조하십시오.)

위의 스크린 샷에서 볼 수 있듯, 앞으로 다른 AWS 서비스 VPC 엔드포인트도 만들 수 있습니다.

그리고, VPC 엔드 포인트에 대한 접근 허용 VPC 서브넷을 지정합니다.

위의 스크린샷에서 보시다시피 VPC 엔드포인트를 만들 때, 서브넷의 공용 IP 주소에 의한 S3와의 통신이 약간 단절되므로 주의하시기 바랍니다.

VPC 엔드 포인트를 작성하면, S3 공용 엔드 포인트와 DNS 이름은 제대로 작동합니다. VPC 엔드 포인트는 단순히 EC2에서 S3로 통신 경로를 변경하는 것입니다.

서울 리전 기능 추가
Amazon S3의 VPC 엔드포인트 지원은 2015년 5월 11일 정식 출시 되었으며, 오늘 부터 서울 리전에서도 사용 가능합니다. 좀 더 자세한 것은 VPC 엔드포인트 기술 문서를 참고하세요.

이 글은 New – VPC Endpoint for Amazon S3Introducing Amazon VPC Endpoints for Amazon S3 in South America (Sao Paulo) and Asia Pacific (Seoul)를 편집하였습니다.