Category: 서울 리전 소식


AWS IoT Device Management 출시 – 대량 디바이스 관리 및 모니터링 서비스

AWS IoTAWS Greengrass는 IoT 디바이스 및 애플리케이션을 위한 견고한 토대와 프로그래밍 환경을 제공합니다.

IoT의 성격상, 대규모 디바이스 배포는 종종 수백 또는 수천 군데에 수백만 또는 수천만 개의 장치가 배포되는 것을 의미합니다. 이러한 규모에서 각 디바이스를 개별적으로 취급하는 것은 불가능합니다. 대량으로 또한 집합적으로 디바이스를 설정, 모니터링, 업데이트 및 최종적으로 사용 중지하면서도 다양한 배포 구성, 디바이스 모델 등을 수용하는 유연성도 유지할 수 있어야 합니다.

AWS IoT Device Management 출시
오늘 Amazon에서는 이 과제를 해결해 줄 AWS IoT Device Management를 출시합니다. 이 서비스는 제조에서 사용 중지까지 디바이스 수명 주기의 각 단계를 지원합니다. 다음은 제공되는 기능입니다.

  • 온보딩 – 제조 상태의 디바이스에서 시작하여 프로비저닝 워크플로를 제어할 수 있습니다. IoT Device Management 템플릿을 사용하여 몇 번의 클릭으로 전체 디바이스 집합을 빠르게 온보딩할 수 있습니다. 템플릿은 디바이스 인증서 및 액세스 정책에 대한 정보를 포함할 수 있습니다.
  • 조직 – 막대한 수의 디바이스를 처리하기 위해, AWS IoT Device Management는 기존 IoT Device Registry를 확장하고 사용자가 디바이스 집합의 계층 모델을 생성하고 계층을 기반으로 정책을 설정할 수 있게 해줍니다. 개별 디바이스를 찾기 위해 계층을 따라 드릴다운할 수 있습니다. 또한 디바이스 집합에 대해 다비이스 유형 또는 펌웨어 버전과 같은 속성을 쿼리할 수도 있습니다.
  • 모니터링 – 디바이스로부터 원격 측정을 사용하여 실시간 연결, 인증 및 상태 지표를 수집하며, 이들 지표는 Amazon CloudWatch에 게시됩니다. 지표를 검사하고 추가 조사를 위해 특이값의 위치를 확인할 수 있습니다. IoT Device Management는 각 디바이스 그룹에 대해 로그 수준을 구성하도록 해주며, 사용자는 모니터링을 위해 Registry 및 Jobs의 변경 이벤트를 게시할 수도 있습니다.
  • 원격 관리AWS IoT Device Management를 사용하면 디바이스를 원격으로 관리할 수 있습니다. 디바이스에 새 소프트웨어 및 펌웨어를 푸시하고, 공장 기본값으로 재설정하고, 리재부팅하고, 대량 업데이트를 원하는 속도로 설정할 수 있습니다.

AWS IoT Device Management 살펴보기
AWS IoT Device Management 콘솔이 둘러보기를 통해 서비스의 각 기능에 액세스하는 방법을 소개했습니다.

저에게는 이미 대규모의 디바이스 세트(압력 게이지)가 있습니다.

이들 게이지는 새로운 온도 기반 대량 등록 기능을 사용해 생성된 것입니다. 다음은 제가 템플릿을 생성하는 방법입니다.

게이지는 그룹으로 정리됩니다(이 경우 미국 주).

다음은 콜로라도 주에 위치한 게이지입니다.

AWS IoT 그룹 정책을 통해 특정 IoT 리소스와 그룹의 모든 멤버에 대한 작업에 대한 액세스 권한을 제어할 수 있습니다. 이 정책은 IAM 정책과 거의 동일하게 구성되며 콘솔에서 생성할 수 있습니다.

작업은 선택적으로 디바이스를 업데이트하는 데 사용됩니다. 다음은 작업을 생성하는 방법입니다.

위의 [Job type]에 표시되었듯이, 작업은 한 번만 또는 지속적으로 실행될 수 있습니다. 다음은 업데이트할 디바이스를 선택하는 방법입니다.

Lambda 함수를 사용하는 사용자 지정 권한 부여자를 생성할 수 있습니다.

이 게시물에서는 AWS IoT Device Management의 사용 방법을 자세히 보여드렸습니다. 더 자세한 사항은 AWS 관리 콘솔설명서를 참고하세요.

Jeff;

이 글은 AWS re:Invent 신규 서비스 출시 소식으로 New- AWS IoT Device Management의 한국어 번역입니다.

T2 무제한(Unlimited) 기능 – 피크에도 고성능 컴퓨팅 활용하기

2014년 여름에 T2 인스턴스에 대해 처음으로 소개하고, 대부분 IT 업무에서 지속적인 컴퓨팅 파워가 크게 요구되지 않고 가끔 더 많은 컴퓨팅이 필요할 때 사용할 수 있는 이제 버스팅 모델을 선보였습니다. T2 인스턴스는 현재 인기가 매우 높아져서 마이크로 서비스, 지연 시간이 짧은 대화형 애플리케이션, 가상 데스크톱, 빌드 및 스테이징 환경, 프로토타입 등을 호스팅하는 데 사용되고 있습니다.

신규 T2 무제한(Unlimited) 기능 출시
오늘 T2에서 제공하는 버스트 모델을 확장하여, 이제 최대한 낮은 비용으로 원하는 기간 동안 높은 CPU 성능을 유지할 수 있는 기능을 추가합니다. 사용하시려면 인스턴스를 시작할 때, 이 기능을 활성화하면 되고, 이미 실행 중인 인스턴스에 대해 이 기능을 활성화할 수도 있습니다. 24시간 동안 평균 CPU 사용률이 기준선보다 낮을 경우, 중간에 급증하는 모든 사용량이 시간당 T2 인스턴스 가격에 포함됩니다. 인스턴스가 장기간에 걸쳐 높은 CPU 사용률로 실행될 경우 소액의 시간당 요금이 청구됩니다. 예를 들어, t2.micro 인스턴스를 평균 15% 사용률(기준선보다 5% 높음)로 24시간 동안 실행할 경우 6센트(vCPU-시간당 5센트 * 1 vCPU * 5% * 24시간)의 추가 요금이 청구됩니다.

EC2 콘솔에서 T2 Unlimited 인스턴스를 시작하려면 T2 인스턴스를 선택한 다음 [T2 Unlimited] 옆에 있는 [Enable]을 클릭합니다.

T2 Standard에서 실행 중인 인스턴스를 T2 Unlimited로 전환하는 방법은 다음과 같습니다.

CPU 크레딧 계산 기준
원래 T2 인스턴스는 실행될 때마다 CPU 크레딧을 누적하였다가 최대 코어 속도로 실행할 때 CPU 크레딧을 사용합니다. 이때 크레딧 공급이 고갈되면 기준 레벨로 속도가 느려집니다. 하지만, T2 Unlimited 인스턴스에서는 하루 분량의 크레딧을 미리 빌려서 추가 버스팅을 수행할 수 있습니다. 이 값은 CloudWatch에 CPUSurplusCreditBalance라는 신규 측정치로 기록합니다. 잔여 크레딧 레벨이 하루 분량으로 증가하면 인스턴스에서는 전체 코어 성능을 계속 제공합니다. vCPU별로 시간당 $0.05(Linux) 또는 $0.096(Windows)의 요금이 청구됩니다. 청구되는 이 초과 크레딧은 새 CPUSurplusCreditsCharged 측정치에 의해 기록합니다. 지정된 시간 내에 초과 크레딧을 다 쓴 경우 한 시간 미만의 버스팅 시간에 대해 밀리초 단위로 요금이 청구됩니다. 따라서, 추가적으로 비용을 절감할 수 있습니다.

나머지 CPUSurplusCreditBalance에 대한 요금은 인스턴스를 종료하거나 T2 Standard로 구성할 때 처리됩니다. 누적된 CPUCreditBalance는 T2 Standard로 전환하는 동안 유지됩니다.

T2 Unlimited 모델은 CloudWatch 측정치를 조회하는 수고를 덜어주기 위해 설계되었지만, 원하는 경우 직접 확인해도 됩니다. 예를 들어, t2.nano의 시간의 흐름에 따른 크레딧에 대해 알아보겠습니다. 먼저 CPU 사용률이 100%로 증가하면 인스턴스에서는 5분마다 5크레딧을 소비합니다(1크레딧은 1 VCPU 분에 해당).

크레딧이 생성과 동시에 소비되고 있으므로 CPU 크레딧 잔고는 0으로 유지됩니다. 이 때, CPUSurplusCreditBalance 측정치에 의해 추적되는 초과 크레딧 잔고가 72까지 증가합니다. 이 초과 크레딧 잔고는 향후 크레딧에서 임차한 크레딧을 나타냅니다.

초과 크레딧 잔고가 72가 되면 더 이상 크레딧을 임차할 수 없으며, 추가 CPU 사용량에 대해서는 시간이 끝날 때 청구되며 이는 CPUSurplusCreditsCharged 측정치에 의해 추적됩니다. 인스턴스에서는 5분마다 5크레딧을 소비하고 0.25크레딧을 획득합니다. 따라서 5분의 버스팅당 4.75 VCPU 분의 순수 요금이 청구됩니다.

원한다면 언제든지 T2 Standard 및 T2 Unlimited 간에 각 인스턴스를 전환할 수 있습니다. CPUSurplusCreditsCharged를 제외한 모든 크레딧 잔고는 유지되며 이월됩니다. T2 Unlimited 인스턴스는 언제든지 버스팅할 수 있으므로 새로 시작된 T2 Standard 인스턴스에 제공되는 30분 크레딧이 제공되지 않습니다. 각 AWS 계정에서 매일 초기 CPU 크레딧을 사용하여 제한된 수의 T2 Standard 인스턴스를 시작할 수 있으므로, T2 Unlimited 인스턴스는 자동 스케일링 그룹과 다수의 인스턴스를 매일 동작하는 시나리오용으로 더 적합합니다.

정식 출시
T2 Unlimited 인스턴스는 현재 미국 동부(버지니아 북부), 미국 동부(오하이오), 미국 서부(캘리포니아 북부), 미국 서부(오리건), 캐나다(중부), 남아메리카(상파울루), 아시아 태평양(싱가포르), 아시아 태평양(시드니), 아시아 태평양(도쿄), 아시아 태평양(뭄바이), 아시아 태평양(서울), EU(프랑크푸르트), EU(아일랜드)EU(런던) 리전에서 시작할 수 있습니다.

Jeff;

이 글은 AWS re:Invent 2017 신규 서비스 소식으로 T2 Unlimited – Going Beyond the Burst with High Performance 의 한국어 번역입니다.

Amazon S3 Select 및 Glacier Select – 원하는 객체 기반 데이터 질의 기능 출시

Amazon S3(Simple Storage Service)는 다양한 기업들이 사용하는 수백만 애플리케이션을 위한 대용량 데이터를 저장하며, 대부분 고객은 안전하고 지속성이 우수하며 경제적인 백업 아카이브 스토리지를 위해 Amazon Glacier를 사용하고 있습니다. S3를 사용하면 원하는 만큼 많은 객체를 저장할 수 있으며, 개별 객체의 크기는 5테라바이트까지 가능합니다. 객체 스토리지의 데이터는 일반적으로 하나의 완전한 개체로 액세스되었습니다. 즉, 5기가바이트 객체를 한 개 요청하면 5기가바이트를 모두 받게 됩니다. 이것은 객체 스토리지의 속성입니다.

오늘 Amazon S3 및 Glacier를 위한 두 가지 새로운 기능을 발표하여 새로운 데이터 분석 패러다임을 제공합니다. 표준 SQL 질의를 사용하여 여기에 저장된 객체에서 필요한 정보만 가져올 수 있는 기능입니다. 이렇게 하면 S3 또는 Glacier의 객체를 액세스하는 모든 애플리케이션 성능이 근본적으로 향상됩니다.

Amazon S3 Select 미리 보기

Amazon S3 Select는 간단한 SQL 식을 사용하여 애플리케이션이 객체에서 일부 데이터만 가져올 수 있도록 하는 서비스입니다. S3 Select를 사용하여 애플리케이션에서 필요한 데이터만 가져옴으로써, 상당한 성능 향상을 이룰 수 있습니다. 대부분의 경우 이러한 성능 향상은 최대 400%에 이릅니다.

대형 소매 기업의 개발자가 한 매장의 주간 판매 데이터를 분석해야 하는데, 매일 200개 매장 모두의 데이터가 새로운 GZIP 압축 CSV로 저장되고 있는 상황을 생각해 보십시오. S3 Select가 없으면 전체 CSV를 다운로드하여 압축을 풀고 처리하여 필요한 데이터를 가져와야 합니다. S3 Select를 사용하면, 전체 객체를 가져오는 대신 해당 매장의 데이터만 반환하는 간단한 SQL 식을 사용할 수 있습니다. 즉, 최소한의 데이터만 처리하면 되며 결과적으로 기반 애플리케이션의 성능이 향상됩니다.

Python 예제를 간단히 살펴보겠습니다.

import boto3
from s3select import ResponseHandler

class PrintingResponseHandler(ResponseHandler):
    def handle_records(self, record_data):
        print(record_data.decode('utf-8'))

handler = PrintingResponseHandler()
s3 = boto3.client('s3')
response = s3.select_object_content(
    Bucket="super-secret-reinvent-stuff",
    Key="stuff.csv",
    SelectRequest={
        'ExpressionType': 'SQL',
     'Expression': 'SELECT s._1 FROM S3Object AS s'',
        'InputSerialization': {
            'CompressionType': 'NONE',
            'CSV': {
                'FileHeaderInfo': 'IGNORE',
                'RecordDelimiter': '\n',
                'FieldDelimiter': ',',
            }
        },
        'OutputSerialization': {
            'CSV': {
                'RecordDelimiter': '\n',
                'FieldDelimiter': ',',
            }
        }
    }
)
handler.handle_response(response['Body'])

이렇게 하기 위해 S3 Select는 이진 유선 프로토콜을 사용하여 객체를 반환합니다. 현재 이를 위해서는 역직렬화를 지원하는 작은 라이브러리를 추가로 사용해야 합니다.

고객들은 S3 Select를 사용하여 모든 종류의 애플리케이션 속도를 향상시킬 수 있을 것으로 기대됩니다. 예를 들어 일부 데이터를 가져오는 이 기능은 AWS Lambda를 사용하여 만든 서버리스 애플리케이션에 특히 유용합니다. 서버리스 MapReduce 참조 아키텍처를, S3 Select를 사용하여 필요한 데이터 가져오도록 수정했을 때, 성능은 2배 향상했고 비용은 80% 감소했습니다.

또한, S3 Select 팀은 쿼리를 변경하지 않고 Amazon EMR에 대한 성능을 즉시 높일 수 있는 Presto 커넥터를 개발했습니다. S3에서 가져온 데이터의 약 99%를 필터링하는 복합 쿼리를 실행하여 이 커넥터를 테스트했습니다. S3 Select를 사용하지 않을 경우 Presto는 S3의 전체 객체를 스캔하여 필터링해야 했지만, S3 Select를 사용하면 S3 Select를 통해 쿼리에 필요한 데이터만 가져왔습니다.

[hadoop@ip-172-31-19-123 ~]$ time presto-cli --catalog hive --schema default --session hive.s3_optimized_select_enabled=false -f query.sql
"31.965496","127178","5976","70.89902","130147","6996","37.17715","138092","8678","135.49536","103926","11446","82.35177","116816","8484","67.308304","135811","10104"
 
real  0m35.910s
user  0m2.320s
sys   0m0.124s
[hadoop@ip-172-31-19-123 ~]$ time presto-cli --catalog hive --schema default --session hive.s3_optimized_select_enabled=true -f query.sql
"31.965496","127178","5976","70.89902","130147","6996","37.17715","138092","8678","135.49536","103926","11446","82.35177","116816","8484","67.308304","135811","10104"
 
real  0m6.566s
user  0m2.136s
sys   0m0.088s

S3 Select를 사용하지 않은 경우 이 쿼리는 35.9초 걸렸고, S3 Select를 사용했을 때는 6.5초밖에 걸리지 않았습니다. 5배 빠른 속도입니다.

알아둘 사항

  • S3 Select 프리뷰 버전은 GZIP으로 압축되거나 압축되지 않은 CSV 또는 JSON 파일을 지원합니다. 프리뷰 버전에서는 저장 시 암호화된 객체를 지원하지 않습니다.
  • S3 Select 프리뷰 버전은 무료입니다.
  • Amazon Athena, Amazon Redshift, Amazon EMR을 비롯하여 Cloudera, DataBricks, Hortonworks 등의 파트너들은 모두 S3 Select를 지원합니다.

Glacier Select 정식 출시

금융 서비스, 의료 등 규제가 엄격한 업종의 일부 기업에서는 SEC 규정 17a-4 또는 HIPAA 등과 같은 규정을 준수하기 위해 Amazon Glacier에 직접 데이터를 쓰고 있습니다. 많은 S3 사용자들은 더 이상 정기적으로 액세스하지 않는 데이터를 Glacier로 옮김으로써 스토리지 비용을 절약하도록 설계된 수명 주기 정책을 사용합니다. 온프레미스 테이프 라이브러리 등과 같은 기존의 아카이브 솔루션은 대부분 데이터 검색 처리량에 제한이 많아서 신속한 분석이나 처리에는 부적합합니다. 이러한 테이프 중 하나에 저장된 데이터를 사용하려면 유용한 결과를 얻기까지 몇 주씩 기다려야 할 수도 있습니다. 반면에 Glacier에 저장된 콜드 데이터는 단 몇 분만에 쉽게 쿼리할 수 있습니다.

따라서 아카이브된 데이터를 활용하여 새롭고 가능성 있는 비즈니스 가치를 창출할 수 있습니다. Glacier Select를 사용하면 표준 SQL 문을 사용하여 Glacier 객체에 대해 직접 필터링을 수행할 수 있습니다.

Glacier Select는 다른 검색 작업과 마찬가지로 수행되지만 다른 점은 초기 작업 요청에 전달할 수 있는 SelectParameters 파라미터 집합을 제공한다는 사실입니다.

다음은 간단한 예제입니다.

import boto3
glacier = boto3.client("glacier")

jobParameters = {
    "Type": "select", "ArchiveId": "ID",
    "Tier": "Expedited",
    "SelectParameters": {
        "InputSerialization": {"csv": {}},
        "ExpressionType": "SQL",
        "Expression": "SELECT * FROM archive WHERE _5='498960'",
        "OutputSerialization": {
            "csv": {}
        }
    },
    "OutputLocation": {
        "S3": {"BucketName": "glacier-select-output", "Prefix": "1"}
    }
}

glacier.initiate_job(vaultName="reInventSecrets", jobParameters=jobParameters)

알아둘 사항

Glacier Select는 모든 상용 리전에서 오늘 부터 사용할 수 있습니다. Glacier는 3가지 측정량으로 요금이 책정됩니다.

  • 스캔한 데이터량(GB)
  • 반환된 데이터량(GB)
  • Select 요청 수

각 측정량에 대한 요금은 원하는 결과 반환 속도에 따라 정해지며, 고속(1-5분), 일반(3-5시간), 대량(5-12시간)으로 구분됩니다. 곧 다가오는 2018년에 Athena는 Glacier Select를 사용하여 Glacier와 통합됩니다.

이러한 기능을 활용하여 애플리케이션 속도를 높이거나 새로운 성과를 달성하시기 바랍니다.

Randall;

이 글은 AWS re:Invent 2017 신규 서비스 소식으로 S3 Select and Glacier Select – Retrieving Subsets of Objects 의 한국어 번역입니다.

Amazon DynamoDB 업데이트 – 글로벌 테이블 및 온 디맨드 백업 기능 출시

다양한 산업 분야의 AWS 고객이 Amazon DynamoDB를 이용해 미션 크리티컬 데이터를 저장합니다. 금융 서비스, 상거래, AdTech, IoT 및 게임 애플리케이션 등은 수백 테라바이트 용량의 데이터 및 수조 개의 항목으로 구성된 개별 테이블로 초당 수백만 건의 요청을 처리하고 DynamoDB를 사용해 몇 밀리초 이내에 결과를 반환합니다.

지금부터 여러분이 좋아할 만한 강력한 새 기능 두 가지를 소개하겠습니다.

  • 글로벌 테이블 – 이제 몇 번의 클릭만으로 멀티 마스터 쓰기를 완벽하게 지원하면서 두 곳 이상의 AWS 리전에 걸쳐 자동으로 복제되는 테이블을 생성할 수 있습니다. 따라서 복제 프로세스를 관리할 필요 없이 글로벌 사용자 기반을 겨냥해 대규모로 확장되는 애플리케이션을 빠르게 구축할 수 있습니다.
  • 온 디맨드 백업 – 이제 한 번의 클릭으로 성능이나 가용성에 전혀 영향을 미치지 않으면서 DynamoDB 테이블의 전체 백업을 만들 수 있습니다. 애플리케이션은 온라인 상태를 유지하고 최고 속도로 실행됩니다. 백업은 장기 보존 및 보관에 적합하며 규정 요구 사항을 준수하는 데 도움이 될 수 있습니다.

글로벌 테이블
DynamoDB는 이미 3개 가용 영역에 걸쳐 테이블을 복제하여 내구성이 뛰어난 고가용성 스토리지를 제공합니다. 이제 글로벌 테이블을 사용하여 두 곳 이상의 AWS 리전에 걸쳐 테이블을 복제하고 몇 번의 클릭만으로 설정할 수 있습니다. 가장 까다로운 글로벌 앱의 필요에 따라 확장 가능한, 빠른 읽기 및 쓰기 성능을 얻을 수 있습니다.

기존 코드를 변경할 필요는 없습니다. 지정된 리전의 DynamoDB 엔드포인트로 쓰기 요청 및 최종적 일관된 읽기 요청을 보내기만 하면 됩니다(강력한 일관된 읽기와 관련된 쓰기는 공통 엔드포인트를 공유해야 함). 보이지는 않지만 DynamoDB가 멀티 마스터 쓰기를 구현하고 특정 항목에 대한 마지막 쓰기가 우선 적용되도록 합니다. 글로벌 테이블을 사용하면 각 항목에는 가장 최근의 쓰기 시간을 나타내는 타임스탬프 속성이 포함됩니다. 업데이트는 DynamoDB Streams를 통해 다른 리전에 비동기식으로 전파되며 일반적으로 1초 이내에 완료됩니다(새로운 ReplicationLatency 및 PendingReplicationCount 측정치를 사용하여 추적 가능).

시작 방법은 간단합니다. 일반적인 방법으로 테이블을 만든 다음, 한 번 클릭으로 추가하여 다른 리전으로의 복제를 예약합니다. 모두 동일한 이름과 키 구성(해시 및 선택적 정렬)의 빈 테이블을 가지고 시작해야 합니다. 모든 테이블은 Auto Scaling, TTL, 로컬 보조 인덱스, 글로벌 보조 인덱스, 프로비저닝된 처리량 설정 및 IAM 정책 집합도 일관되게 공유해야 합니다. 편의를 위해 새로운 글로벌 테이블에서는 Auto Scaling이 자동으로 활성화됩니다.

DynamoDB Auto Scaling을 사용하지 않을 경우 로컬 리전에서 시작되는 각 애플리케이션 쓰기에 대한 추가 시스템 쓰기 및 그룹의 모든 테이블에서의 쓰기를 수용하기에 충분한 쓰기 용량과 로컬 읽기를 처리하기에 충분한 읽기 용량을 프로비저닝해야 합니다. 시스템 쓰기는 최종 쓰기가 우선 적용되는 모델을 지원하는 데 사용됩니다.

세 개 리전에 걸쳐 있는 글로벌 테이블을 생성해보겠습니다. 일반적인 방법으로 테이블을 만든 후 [Global Tables] 탭을 클릭합니다.

DynamoDB는 테이블을 검사하여 요구 사항을 충족하는지 확인하고, 사용자에게 DynamoDB Streams를 활성화할 것을 지시합니다. 이제 [Add region]을 클릭하고 [EU (Frankfurt)]를 선택한 후 [ Continue:]를 클릭합니다.

테이블이 즉시 생성됩니다.

이 작업을 한 번 더 반복하면 세 개 AWS 리전에 걸쳐 있는 글로벌 테이블이 만들어집니다.

[EU (Ireland)]에 항목을 생성합니다.

만드는 즉시 [EU (Frankfurt)]에 표시됩니다.

교차 리전 복제 프로세스에 aws:rep:updateregion aws:rep:updatetime 속성이 추가됩니다. 애플리케이션에서 볼 수 있지만 수정해서는 안 됩니다.

글로벌 테이블은 현재 미국 동부(버지니아 북부), 미국 동부(오하이오), EU(아일랜드), EU(프랑크푸르트) 리전에서 사용할 수 있으며 2018년에 더 많은 리전이 추가될 예정입니다. 교차 리전 복제를 위한 데이터 전송 요금과 함께 읽기 용량 및 스토리지에 대한 통상적인 DynamoDB 요금을 지불하면 됩니다. 쓰기 용량은 복제된 쓰기 용량 단위로 청구됩니다.

온 디맨드 백업
이 기능은 장기 보관 및 데이터 보존에 대한 규정 요구 사항을 준수하도록 만들어졌습니다. 프로비저닝된 처리 용량을 소비하거나 애플리케이션의 응답에 영향을 주지 않고 클릭(또는 API 호출) 한 번으로 백업을 만들 수 있습니다. 백업은 내구성이 뛰어난 형태로 저장되며 새 테이블을 만드는 데 사용할 수 있습니다.

이제 DynamoDB 콘솔에 백업 섹션이 포함됩니다.

[Create backup]을 클릭하고 백업 이름을 지정하기만 하면 됩니다.

백업은 즉시 사용할 수 있습니다! 백업은 Amazon에서 관리하는 키로 암호화되며 모든 테이블 데이터, 프로비저닝된 용량 설정, 로컬 및 글로벌 보조 인덱스 설정 및 스트림이 포함됩니다. Auto Scaling 또는 TTL 설정, 태그, IAM 정책, CloudWatch 측정치 또는 CloudWatch 경보는 포함되지 않습니다.

일부 고객이 0.5페타바이트에 가까운 테이블을 가지고 있는 상황에서 이 작업이 어떻게 즉시 이루어질 수 있는지 궁금할 수 있습니다. 보이지는 않지만 DynamoDB가 전체 스냅샷을 생성하고 모든 변경 로그를 저장합니다. 백업 생성은 테이블의 현재 메타데이터와 함께 타임스탬프를 저장하는 작업만큼 간단합니다.

저의 백업입니다.

새 테이블로 복원하는 방법은 이와 같습니다.

다음은 DynamoDB 백업과 관련하여 몇 가지 유의해야 할 사항입니다.

  • 설정 – 새 테이블을 만든 후 DynamoDB가 몇 가지 설정 작업(책상에서 점심 식사를 하는 시간이면 충분)을 수행해야 첫 번째 백업을 생성할 수 있습니다.
  • 복원 – 복원 시간은 테이블의 크기에 따라 달라지며, 30분에서 몇 시간(매우 큰 테이블의 경우)에 이릅니다.
  • 가용성 – 현재 미국 동부(버지니아 북부), 미국 동부(오하이오), 미국 서부(오레곤), EU(아일랜드) 리전에 최초로 이 새로운 기능을 선보이고 있으며, 조속한 시일 내에 계정 단위로 제공할 계획입니다.
  • 요금 – 기가바이트-월 단위로 백업 스토리지 비용을 지불하고 복원하는 데이터 양에 따라 복원이 진행됩니다.

지금 일부 리전에서 바로 사용 가능하며, 향후 계속 가능 리전이 확대될 것입니다.

Jeff;

이 글은 AWS re:Invent 2017 신규 서비스 소식으로 Amazon DynamoDB Update – Global Tables and On-Demand Backup의 한국어 번역입니다.

Amazon EC2 업데이트 – 손 쉬운 스팟 용량 접근 및 가격 변경, 인스턴스 최대 절전 기능 등

EC2 스팟 인스턴스를 통해 AWS 클라우드에서 컴퓨팅 파워를 아낄 수 있습니다. 고객들은 스팟 인스턴스 집합을 사용하여 CI/CD 환경 및 트래픽 생성기, 웹 서버 및 마이크로서비스 호스팅, 영화 렌더링을 구동하고, 많은 유형의 분석 작업을 실행합니다. 그리고 이 모든 것을 온디맨드 인스턴스와 비교하여 크게 절감된 가격으로 실행합니다.

간소화된 접근 방법
오늘은 새롭게 간소화된 스팟 인스턴스 액세스 모델을 소개하겠습니다. 다음을 통해 인스턴스를 시작할 때 스팟 용량을 사용하고 싶어하는 마음이 있을 것입니다. RunInstances 함수, run-instances 명령 또는 AWS 관리 콘솔을 통해 용량을 사용할 수 있는 동안 이행될 요청을 제출하고 싶을 것입니다. 별도의 수고 없이 인스턴스 유형에 대해 온디맨드 가격의 최대 90%를 절감한다면 동일한 예산으로 전체적인 애플리케이션 처리량을 최대 10배 늘릴 수 있는 셈입니다. 이렇게 시작한 인스턴스는 직접 종료하거나 EC2가 이를 온디맨드 사용으로 회수할 때까지 계속해서 실행될 것입니다. 이럴 경우 인스턴스가 일반적으로 2분의 경고가 주어진 다음 회수되기에 애플리케이션 내결함성에 있어 매우 적절합니다.

스팟 시장, 입찰 및 독립 실행형 비동기식 API에 대한 이해가 필요한 이전 모델과는 달리 새로운 모델은 동기식이고 온디맨드만큼 사용하기 쉽습니다. 코드와 스크립트가 인스턴스 ID를 즉시 받고, 요청이 처리 및 수락되었는지 여부를 재확인할 필요가 없습니다.

우리는 이를 최대한 명확하고 간단하게 만들었기 때문에 스팟 용량을 요청하고 사용할 많은 현재 스크립트 및 애플리케이션을 수정하기 쉬울 것으로 기대합니다. 스팟 인스턴스 예산에 대한 추가적인 통제를 행사하고자 한다면 용량 요청을 할 때 최고 가격을 지정하는 옵션이 있습니다. 스팟 용량을 사용하여 Amazon EMR, Amazon ECS 또는 AWS Batch 클러스터를 구동하거나 AWS CloudFormation 템플릿 또는 Auto Scaling 그룹을 통해 스팟 인스턴스를 시작하는 경우 어떠한 변화 없이 이 새로운 모델의 이점을 누릴 수 있습니다.

애플리케이션이 RequestSpotInstances 또는 RequestSpotFleet 를 중심으로 빌드되는 경우 어떠한 변화 없이 계속해서 작동합니다. 하지만 이제 다음 파라미터가 포함되지 않는 요청을 만들 수 있는 옵션이 있습니다. SpotPrice 파라미터입니다.

손쉬운 스팟 가격 변경
오늘 출시의 일환으로 스팟 가격의 변경 방식을 바꾸어 가격이 공급 및 수요의 장기적 추세를 기반으로 점진적으로 변하는 모델로 이동합니다. 앞서 언급한 대로 계속해서 온디맨드 가격의 평균 70~90%를 절감하고, 인스턴스가 실행 중인 기간 동안 적용되는 스팟 가격을 지불하면 됩니다. 스팟 집합 기능을 중심으로 빌드된 애플리케이션은 집합을 생성할 때 지정한 구성을 기반으로 하는 가장 비용 효율적인 풀 전체의 스팟 인스턴스 배치를 자동적으로 다양화합니다.

스팟 실행
명령줄에서 스팟 인스턴스를 시작하려면 스팟 시장을 지정하면 됩니다.

$ aws ec2 run-instances –-market Spot --image-id ami-1a2b3c4d --count 1 --instance-type c3.large 

인스턴스 최대 절전
많은 인 메모리 상태를 유지하는 워크로드를 실행한다면 이 기능이 마음에 드실 것입니다!

인스턴스가 회수될 때에도 인 메모리 상태를 저장하도록 조정하여 용량을 다시 사용할 수 있을 때 인스턴스와 인스턴스에 있는 애플리케이션이 중단된 지점에서 다시 시작하도록 할 수 있습니다. 마치 노트북을 닫았다가 다시 열어서 사용하는 것처럼 말이죠. 이 기능은 Amazon Linux, Ubuntu 또는 Windows Server를 실행하는 C3, C4, 그리고 특정 크기의 R3, R4 및 M4 인스턴스에서 작동하며, EC2 최대 절전 에이전트의 지원을 받습니다.

인 메모리 상태는 인스턴스 시작 시 별도로 확보된 공간을 사용하여 인스턴스의 루트 EBS 볼륨에 기록됩니다. 프라이빗 IP 주소와 탄력적 IP 주소 또한 중지/시작 주기에 걸쳐 유지됩니다.

Jeff;

이 글은 AWS re:Invent 2017 신규 서비스 소식으로 Amazon EC2 Update – Streamlined Access to Spot Capacity, Smooth Price Changes, Instance Hibernation의 한국어 번역입니다.

Amazon Redshift Spectrum에 대한 10가지 모범 사례

지난 4월 Amazon Redshift Spectrum 출시 이후, 이번 주에는 서울 리전에도 출시하였습니다. 이 글에서는 한국 고객 분들이 Redshift Specturm을 더 잘 활용하기 위한 10가지 모범 사례를 전달해 드립니다.

Amazon Redshift Spectrum 을 사용하면 Amazon S3에 저장된 데이터에 대해 Amazon Redshif SQL 쿼리를 실행할 수 있습니다.  즉, Amazon Redshift의 분석 기능을 데이터웨어 하우스(DW) 내 로컬 디스크에 저장된 데이터 이상으로 확장 할 수 있습니다.  시간이 많이 걸리는 추출, 전송 및 로드 (ETL) 프로세스를 거치지 않고 Amazon S3내의 “데이터  레이크(Data Lake)”에서 방대한 양의 데이터를 바로 쿼리 할 수 있으며, 정교한 쿼리 최적화를 적용하고 수천 노드의 프로세싱을 확장하여 빠른 성능을 제공합니다.이 글에서는 Amazon Redshift Spectrum에 대한 중요한 모범 사례를 몇 가지 분류를 통해 알려 드리고자 하며, 주로 Amazon Redshift 고객과의 많은 대화와 직접 진행한 프로젝트에서 나온 것들입니다.

언제 Amazon Redshift를 선택하나요?

Amazon Athena와 Amazon Redshift Spectrum를 언제 사용하는지 궁금해 하는 고객들이 있습니다.

Amazon Athena는 SQL을 사용하여 Amazon S3에 저장된 데이터에 대해 대화 형 애드훅(Ad-hoc) 쿼리를 실행하는 경우에 유용합니다. Amazon Athena의 서버리스 아키텍처는 쿼리를 수행하기 위해 클러스터를 미리 프로비저닝하지 않아도 됩니다. 각 쿼리에서 스캔 한 S3 데이터의 양에 따라 요금이 부과됩니다. 데이터를 압축, 분할 또는 컬럼 형식으로 변환하여 비용을 크게 절감하고 성능을 향상시킬 수 있으므로 Amazon Athena가 쿼리를 실행하기 위해 스캔해야 하는 데이터 양이 줄어 듭니다. JDBC를 사용하는 모든 주요 BI 도구 및 SQL 클라이언트는 Amazon Athena에서 사용할 수 있습니다. 쉬운 시각화를 위해 Amazon QuickSight를 사용할 수도 있습니다.

만약, 대용량의 구조화 된 데이터 집합에 대해서는 Amazon Redshift를 사용하는 것이 좋습니다. Redshift Spectrum은 원하는 형식으로 원하는 위치에 자유롭게 데이터를 저장할 수 있게 해주며, 필요시 언제든지 처리 할 수 ​​있으며, 클러스터 확장에 대해 걱정할 필요가 없습니다. 이를 통해 스토리지를 분리하고 계산할 수 있으므로 각 스토리지를 독립적으로 확장 할 수 있습니다. 동일한 Amazon S3 데이터 레이크에 대해 여러 개의 Amazon Redshift 클러스터를 실행하여 대량으로 동시성을 구현할 수도 있습니다. 즉, 자동으로 수천 개의 인스턴스로 확장되기 때문에, 쿼리가 테라 바이트, 페타 바이트 또는 엑사 바이트를 처리하든 상관없이 신속하게 실행됩니다. 이를 염두하시고 판단하시면 됩니다.

모범 사례 테스트 환경 설정

Amazon Redshift Spectrum을 시작하기 위한 전제 조건 및 단계에 대한 정보는 Redshift Spectrum 시작하기 문서를 참조하십시오.

모든 데이터 세트를 사용하여 테스트를 수행하여, 이 글에서 설명한 모범 사례를 검증 할 수 있습니다. 한 가지 중요한 요구 사항은 가장 큰 테이블의 S3 파일이 CSV 형식, 분할 Parquet, 비분할 Parquet 형식 등 세 가지 데이터 형식이어야 합니다. 한 파일 형식에서 다른 파일 형식으로 변환하는 방법은 아래 방법을 참고하시기 바랍니다.

외부 스키마 만들기
Amazon Athena 데이터 카탈로그를 메타 데이터 저장소로 사용하고, 다음과 같이 “spectrum”이라는 외부 스키마를 만듭니다.

create external schema spectrum 
from data catalog 
database 'spectrumdb' 
iam_role 'arn:aws:iam::<AWS_ACCOUNT_ID>:role/aod-redshift-role'
create external database if not exists;

Redshift 클러스터와 Amazon S3의 데이터 파일은 동일한 AWS 리전에 있어야합니다. Redshift 클러스터에는 Amazon Athena의 외부 데이터 카탈로그 및 Amazon S3의 데이터 파일에 액세스 할 수 있는 권한이 필요합니다. 클러스터에 연결된 AWS Identity and Access Management (IAM) 역할 (예 : aod-redshift-role)을 참조하여 해당 권한을 제공합니다. 자세한 내용은 Amazon Redshift 용 IAM 역할 만들기를 참조하십시오.

외부 테이블 정의
Partwise Parquet 파일을 사용하는 Amazon Redshift Spectrum 외부 테이블과 CSV 파일을 사용하는 다른 외부 테이블은 다음과 같이 정의됩니다.

CREATE  external table spectrum.LINEITEM_PART_PARQ ( 
 L_ORDERKEY BIGINT,
 L_PARTKEY BIGINT,
 L_SUPPKEY BIGINT,
 L_LINENUMBER INT,
 L_QUANTITY DECIMAL(12,2),
 L_EXTENDEDPRICE DECIMAL(12,2),
 L_DISCOUNT DECIMAL(12,2),
 L_TAX DECIMAL(12,2),
 L_RETURNFLAG VARCHAR(128),
 L_LINESTATUS VARCHAR(128),
 L_COMMITDATE VARCHAR(128),
 L_RECEIPTDATE VARCHAR(128),
 L_SHIPINSTRUCT VARCHAR(128),
 L_SHIPMODE VARCHAR(128),
 L_COMMENT VARCHAR(128))
partitioned by (L_SHIPDATE VARCHAR(128))
stored as PARQUET
location 's3://<your-bucket>/<xyz>/lineitem_partition/'
;

CREATE  external table spectrum.LINEITEM_CSV ( 
 L_ORDERKEY BIGINT,
 L_PARTKEY INT,
 L_SUPPKEY INT,
 L_LINENUMBER INT,
 L_QUANTITY DECIMAL(12,2),
 L_EXTENDEDPRICE DECIMAL(12,2),
 L_DISCOUNT DECIMAL(12,2),
 L_TAX DECIMAL(12,2),
 L_RETURNFLAG VARCHAR(128),
 L_LINESTATUS VARCHAR(128),
 L_SHIPDATE VARCHAR(128) ,
 L_COMMITDATE VARCHAR(128),
 L_RECEIPTDATE VARCHAR(128),
 L_SHIPINSTRUCT VARCHAR(128),
 L_SHIPMODE VARCHAR(128),
 L_COMMENT VARCHAR(128))
row format delimited
fields terminated by '|'
stored as textfile
location 's3://<your-bucket>/<xyz>/lineitem_csv/'

데이터 쿼리
요약하면, Amazon Redshift Spectrum은 외부 테이블을 사용하여 Amazon S3에 저장된 데이터를 쿼리합니다. 다른 Amazon Redshift 테이블과 동일한 SELECT 구문을 사용하여 외부 테이블을 쿼리 할 수 있습니다. 다만, 읽기 전용이므로 외부 테이블에 쓸 수 없습니다.

먼저 외부 데이터베이스를 참조하는 외부 스키마를 작성합니다. 외부 스키마는 Amazon Athena 데이터 카탈로그 또는 Amazon EMR과 같은 Apache Hive 메타 스토어에 있을 수 있습니다. 그런 다음 외부 스키마를 사용하여 Amazon Redshift에서 외부 테이블을 생성합니다. 테이블을 생성하고 Amazon Redshift로 읽어 올 필요 없이 테이블 이름 앞에 스키마 이름을 붙임으로써 SELECT 문에서 외부 테이블을 참조하면 됩니다.

외부 스키마는 외부 데이터 카탈로그의 데이터베이스를 참조합니다. 이를 위해서는 클러스터를 대신하여 Amazon S3 및 Amazon Athena에 액세스 할 수 있는 권한을 부여하는 IAM 역할이 필요합니다.

Amazon Redshift Spectrum을 사용하여 테스트를 수행하려면, 다음 두 가지 쿼리를 시작하는 것이 좋습니다.

QUERY 1:

SELECT l_returnflag,
       l_linestatus,
       sum(l_quantity) as sum_qty,
       sum(l_extendedprice) as sum_base_price,
       sum(l_extendedprice*(1-l_discount)) as sum_disc_price,
       sum(l_extendedprice*(1-l_discount)*(1+l_tax)) as sum_charge,
       avg(l_quantity) as avg_qty,
       avg(l_extendedprice) as avg_price,
       avg(l_discount) as avg_disc,
       count(*) as count_order
FROM lineitem
WHERE l_shipdate <= '1998-09-01'
GROUP BY l_returnflag, l_linestatus
ORDER BY l_returnflag, l_linestatus;

이 쿼리에는 하나의 테이블 만 포함되며 Amazon Redshift Spectrum 레이어에서 제공하는 추가 처리 성능을 강조 표시하는 데 사용할 수 있습니다.

QUERY 2:

SELECT  l_orderkey,
       sum(l_extendedprice * (1 - l_discount)) as revenue,
       o_orderdate,
       o_shippriority
FROM	customer, orders, lineitem
WHERE	c_mktsegment = 'BUILDING'
       AND c_custkey = o_custkey
       AND l_orderkey = o_orderkey
       AND o_orderdate < date '1995-03-15'
       AND l_shipdate > date '1995-03-15'
GROUP BY l_orderkey, o_orderdate, o_shippriority
ORDER BY revenue desc, o_orderdate
LIMIT 20;

이 쿼리에는 3 개의 테이블이 결합되어 Amazon Redshift Spectrum의 성능과 기본 Amazon Redshift의 성능을 비교하는 데 매우 유용합니다.

동시성 모범 사례

아래 모범 사례는 Amazon Redshift Spectrum을 사용하여 동시 작업 부하 성능을 최적화하는 데 도움이됩니다.

1. 스캔 집약적인 동시 작업 부하 향상
Amazon Redshift Spectrum은 클러스터와 독립적 인 전용 Amazon Redshift 서버에 있습니다. 조건부 필터링 및 집계와 같은 많은 컴퓨팅 집약적인 작업을 Redshift Spectrum에서 처리하기 때문에, 쿼리를 위한 클러스터 처리 용량을 훨씬 적게 사용합니다. 또한 Amazon Redshift Spectrum은 지능적으로 확장되기 때문에 쿼리 요구를 기반으로 잠재적으로 수천 개의 인스턴스를 사용하여 대규모 병렬 처리 (MPP)를 활용할 수 있습니다. 동시 스캔 및 / 또는 집약적 인 작업 부하의 일부 사용 사례의 경우 Amazon Redshift Spectrum이 평균 Amazon Redshift보다 우수한 성능을 보입니다.

모든 MPP 시스템에서 가장 자원이 많이 드는 과정이 바로 데이터 로딩 프로세스입니다. 이는 컴퓨팅 뿐 아니라 MVCC (Multiversion Concurrency Control)를 통해 테이블을 잠그는 것과 같은 능동적인 분석 쿼리와 경쟁하기 때문입니다. 그러나, Amazon Redshift Spectrum을 사용하여 Amazon S3에 작성한 새 외부 파일에 파일을 추가 한 다음 메타 데이터를 새 파티션으로 포함하도록 업데이트하면 Amazon Redshift 클러스터에서 이러한 부하가 제거됩니다. 이것은 동시성에 즉각적이고 직접적인 긍정적 영향을 주게 됩니다.

2. 다수 Redshift 온 디멘드 클러스터를 통한 동시성 확장
Redshift Spectrum은 Amazon S3에 데이터를 저장합니다. Amazon S3에 여러 Amazon Redshift 클러스터에서 접근하여 동시 작업 로드 성능을 향상 시킵니다. 일반적인 Redshift 고객은 업무 패턴과 관련 없이 많은 동시적 쿼리 작업 부하를 가지게 되는데,  Redshift Spectrum 이 나오기 전에는 동시성을 처리하기 위해 스냅샷을 복원하여 여러 개의 “읽기 전용”  클러스터를 만들어 두어야 했습니다. 이 접근법의 문제점은 수 테라 바이트의 데이터가 있는 DW의 경우 복원 프로세스가 오래 걸릴 수 있어 데이터 대기 시간 문제가 발생한다는 것입니다.

Amazon Redshift Spectrum을 사용하면 가장 큰 테이블을 Amazon S3로 옮길 수 있으며, 각 Amazon Redshift 클러스터는 로컬 디스크에 적은 양의 데이터만 보관합니다. 데이터 양이 줄어들기 때문에 까다로운 쿼리 작업 부하를 처리하기 위한 “읽기 전용” 클러스터를 생성 및 복원하는 것이 훨씬 빠릅니다 (그림 1 참조). 비용을 줄이려면 이러한 “온-디멘드” 클러스터를 작업후 바로 종료하면 됩니다.

그림 1:  다중 읽기 전용 Amazon Redshift 클러스터에서 Redshift Spectrum 공유하기

Amazon Redshift 고객은 pgbouncer-rr을 사용하여, 여러 Redshift 클러스터를 배포 할 때 클라이언트 쿼리 라우팅을 단순화하고 제어하여 동시성을 확장할 수 있습니다. 자세한 내용은 Amazon Redshift 및 PostgreSQL을위한 pgbouncer-rr 소개 : Query Routing and Rewrite (영문)를 참조하십시오.

스토리지 모범 사례

스토리지 최적화 고려 사항에서는 모든 단계에서 I/O 워크로드를 줄이는 것이 좋습니다. 이는 각 스토리지 블록에 더 많은 레코드를 맞추기 위해 압축을 사용하고 데이터 파티셔닝을 지원하는 형식을 사용하여 컬럼 기반 파일 형식을 사용해야 합니다. Amazon Redshift Spectrum에서 지원되는 파일 형식으로는 CSV, TSV, Parquet, Sequence 및 RCFile이 있습니다.

추가적인 최적화 방법은 압축을 사용하는 것입니다. 현재 Amazon Redshift Spectrum은 Gzip, Snappy 및 BZ2를 지원합니다.

3. 성능 향상과 비용 절감을 위해 Apache Parquet 파일 사용

Apache Parquet은 데이터 처리 프레임 워크, 데이터 모델 또는 프로그래밍 언어의 선택 여부와 상관없이 Apache Hadoop의 모든 프로젝트에서 사용할 수 있는 컬럼 형식 저장소 형식입니다. 자세한 내용은 Apache Parquet 정보 페이지를 참조하십시오.

Redshift Spectrum은 S3에서 쿼리에 필요한 파일의 컬럼(Column)만을 읽으며, 쿼리 당 S3에서 스캔되는 데이터의 양에 따라 요금을 부과합니다. 따라서, Parquet 형식의 데이터는 컬럼 형식으로만 저장하므로,  스캔 중에 불필요한 데이터를 제거 할 수 있습니다. 예를 들어, CSV 텍스트 파일과 Parquet 파티션 파일 간의 쿼리 성능 차이를 비교하면 바로 알 수 있습니다. 여러 가지 테스트 결과에 따르면 파티션 된 Parquet 파일은 성능이 빠르고 비용 효율적입니다.

SVL_S3QUERY_SUMMARY를 사용하면 분할 된 Parquet 파일을 사용하는 쿼리에 대한 흥미로운 S3 측정값에 대한 통찰력을 얻을 수 있습니다.

select * from SVL_S3QUERY_SUMMARY where query=<Query-ID>;

s3_scanned_rowss3query_returned_rows 등 두 가지 측정 항목에  주의하십시오. CSV 파일과 비교할 때 최종 처리를 위해 Redshift Spectrum에서 Redshift 네이티브로 반환 되는 데이터의 양이 엄청나게 줄어들 것입니다.

4. 자주 사용하는 칼럼에 대한 Parquet 파일 분할

최적의 파티션 칼럼을 정할 때는 아래 사항을 고려하시기 바랍니다.

  • 공통 필터로 사용되는 칼럼을 선택합니다.
  • 과도하게 세분화 된 파티션은 스캔 시간이 증가될 수 있으나, 파티션 정리에 도움이 되고 S3에서 스캔 한 데이터의 양을 줄일 수 있습니다.
  • 실제 성능은 파일 배치, 쿼리 패턴, 파일 크기 분포, 파티션에 있는 파일 수, 적합한 파티션 수 등에 따라 달라질 수 있습니다.
  • 칼럼을 분할 할 때, 데이터가 잘 분할되고 있는지 모니터링하시기 바랍니다.
  • 파일 크기 분포가 가능한 한 균일해야 합니다. 즉, 한 개의 1GB 파일과 6 개의 256MB 파일보다는 256MB Parquet 파일 10 개로 처리하는 것이 좋습니다.

파티션 정리 (partition pruning)의 이점을 살펴보려면, Parquet 형식을 사용하여 두 개의 외부 테이블을 작성하는 것을 고려해야 합니다. 하나의 테이블은 파티션하지 않고, 다른 파티션은 일별로 분할합니다.

파티션한 테이블 스캔은 파티션 하지 않은 테이블보다 2~4 배 빠릅니다.

“파티션 정리”가 유효한 지 알아보려면, SQL을 사용하여 파티션 정리의 효율성을 분석 할 수 있습니다. 쿼리가 몇 개의 파티션에만 적용하여, 실제 예상대로 작동하는지 확인할 수 있습니다.

SELECT query,
	segment,
	max(assigned_partitions) as total_partitions,
	max(qualified_partitions) as qualified_partitions 
FROM svl_s3partition 
WHERE query=<Query-ID>
GROUP BY 1,2;

클러스터 설정 모범 사례

5. 올바른 클러스터 구성으로 Redshift Spectrum 성능 최적화

Amazon Redshift Spectrum 쿼리에는 두 가지의 Amazon S3 요청 병렬 처리 방식이 있습니다.

  • 쿼리 수준 (슬라이스 쿼리 당 최대 10 개) 숫자는 실행 중인 동시 쿼리 수에 따라 상이함
  • S3 스캔에 사용되는 스레드 수에 따른 작업

노드 수준 (노드에서 실행되는 모든 S3 쿼리, 노드 유형에 따라 상이함)노드 인스턴스 타입에 따라 상이함
간단한 계산 방법은 다음과 같습니다. “총 파일 수 <= 쿼리당 병렬 처리 수 (예 : 10) * 총 슬라이스 수” 일 때, 더 많은 노드를 가진 클러스터를 만들어도 성능이 향상되지 않을 수 있습니다. 좋은 방법은 Amazon Redshift Spectrum 테이블에 있는 파일 수를 확인하는 것입니다. 그리고, 특정 클러스터 크기 (슬라이스 관점에서)까지 추세를 측정하여 클러스터 노드 수가 증가하는 경우에도 성능이 더 이상 올라가지 않을 때를 확인합니다. Amazon Redshift 클러스터의 최적의 크기 (주어진 노드 유형에 대한)는 더 이상의 성능 향상을 얻을 수 없는 지점입니다.

쿼리 성능 모범 사례

몇 가지 간단한 기술을 사용하여 Amazon S3에서의 쿼리 성능을 향상시킬 수 있습니다.

6.  신속하게 스캔 및 집계가 필요한 쿼리에 주로 활용하기
Query 1과 같은 조인(Join)이 없는 특정 쿼리에서 성능은 일반적으로 검색 속도와 같은 물리적 I/O 비용에 의해 좌우됩니다. 이러한 쿼리의 경우, Redshift Spectrum이 Redshift보다 빠를 수 있습니다. 반면에 쿼리 2와 같이 여러 테이블 조인이 포함될 경우, 로컬 스토리지를 사용하는 매우 최적화 된 네이티브 Redshift 테이블이 훨씬 성능이 좋습니다.

7.  조건절(Predicate) 푸시 다운으로 S3 쿼리 성능 향상
Amazon Redshift Spectrum 수준 (S3 스캔, 프로젝션, 필터링 및 집계)에서 수행되는 처리는 개별 Amazon Redshift 클러스터와는 독립적이고, Redshift 클러스터의 리소스를 사용하지 않습니다.

따라서, Redshift Spectrum 에서 푸시 다운 할 수 있는 특정 SQL 작업이 있습니다. 가능한 한 이를 활용하고 싶다면, 다음 몇 가지 예를 참고하시기 바랍니다.

  • GROUP BY 절 및 일부 문자열 함수
  • LIKE와 같은 조건부 조건 및 패턴 일치 조건
  • COUNT, SUM, AVG, MIN, MAX 및 기타 많은 공통 집계 함수
  • regex_replace 및 기타 많은 함수

DISTINCTORDER BY와 같은 특정 SQL 작업은Redshift Spectrum으로 푸시 다운 될 수 없기 때문에 Redshift에서 수행해야 합니다. 가능한 경우 사용을 최소화하거나 사용하지 않아야 합니다.

다음 두 가지 쿼리를 사용하여 테스트를 수행하면 큰 차이가 있음을 알 수 있습니다.

Select MIN(L_SHIPDATE), MAX(L_SHIPDATE), count(*)
	from spectrum.LINEITEM_NPART_PARQ;
Select MIN(DATE(L_SHIPDATE)), MAX(DATE(L_SHIPDATE)), count(*)
        from spectrum.LINEITEM_NPART_PARQ;

자연 스럽게 왜 그런지 의문이 듭니다.첫 번째 쿼리에서는 S3 Aggregate가 Redshift Spectrum으로 푸시되고, 집계 된 결과만 최종 처리를 위해 Amazon Redshift로 반환됩니다.

반면에 두 번째 쿼리를 면밀히 살펴보면 Redshift Spectrum이 DATE를 일반 데이터 형식 또는 DATE 변환 함수로 지원하지 않았기 때문에 Redshift Spectrum 계층에서 S3 집계가 없음을 알 수 있습니다. 결과적으로 이 쿼리는 S3에서 대용량 데이터를 Redshift로 직접 가져와 변환 및 처리를 해야합니다.

또 다른 대안적인 방법은 두 SQL 문에 대한 SVL_S3QUERY_SUMMARY 시스템 뷰 (s3query_returned_rows 컬럼)에 대해 쿼리하는 것입니다. Redshift Spectrum에서 Redshift로 반환되는 행(row)수에서 큰 차이가 있다는 점을 알게 될 것입니다.

8. DISTINCT를 GROUP BY로 바꾸기

GROUP BY, MIN/MAX/COUNT 등과 같은 특정 SQL 연산자는 Redshift Spectrum 계층으로 푸시 다운 할 수 있습니다. 다만, DISTINCT 및  ORDER BY와 같은 다른 SQL 연산자는 푸시 다운 할 수 없습니다. 일반적으로 Redshift Spectrum을 지원하는 강력한 인프라 때문에 푸시 다운 할 수 있는 모든 작업의 성능이 Redshift 대비 향상됩니다.

예를 들어, 다음 두 기능적으로 동일한 SQL 문을 테스트해보시기 바랍니다.

SELECT DISTINCT l_returnflag,
        l_linestatus 
FROM 	spectrum.LINEITEM_PART_PARQ 
WHERE 	EXTRACT(YEAR from l_shipdate::DATE) BETWEEN '1995' AND  '1998' 
ORDER BY l_returnflag, l_linestatus
;

SELECT l_returnflag,l_linestatus 
FROM 	spectrum.LINEITEM_PART_PARQ 
WHERE EXTRACT(YEAR from l_shipdate::DATE) BETWEEN '1995' AND  '1998' 
GROUP BY l_returnflag, l_linestatus 
ORDER BY l_returnflag, l_linestatus
;

DISTINCT로 인해 첫 번째 쿼리에 푸시 다운은 없습니다. 대신 Amazon Redshift에 다량의 행(row)이 반환 및 정렬됨으로서 중복을 제거합니다. 두 번째 쿼리에서 S3 HashAggregate 는 Redshift Spectrum으로 푸시됩니다. 여기서는 대부분 무거운 작업 및 집계를 수행합니다. SVL_S3QUERY_SUMMARY에 대한 질의 계획상 차이점을 확인할수 있습니다.

여기서 우리는 가능하면 SQL 문에서 “DISTINCT“를 “GROUP BY“로 대체하면 좋다는 사실을 알 수 있습니다.

테이블 대체에 대한 모범 사례

아래 간단한 지침은 최고의 성능을 위해 테이블을 저장할 최적의 위치를 결정하는 데 도움을 줄 것입니다.

9. S3에 큰 팩트 테이블을 넣고 Redshift에 다른 팩트 테이블 두기

3 개의 테이블 조인이 있는 Query 2를 생각해 보겠습니다. 자연스럽게 세개의 테이블 모두가 S3에서 분할 된 Parquet 파일로 되어 있는 경우 어떻게 될까요? 일반적으로 Amazon Redshift에서 세 개의 테이블 모두 사용하는 것보다 성능이 좋을까요 아니면 나쁠까요?

조인(Join) 최적화 된 Amazon Redshift 테이블 세트 (적절한 분배 및 정렬 키 포함)가  Redshift Spectrum보다 성능면에서 뛰어 납니다. Redshift Spectrum 외부 테이블은 통계를 지원하지 않습니다. 데이터베이스 엔진은 추론 또는 간단한 행 수를 사용하여 조인 순서를 결정합니다. 어떤 경우에는 이것이 최적의 방법이 아닐 수 있습니다. AWS의 권장 사항은 Amazon S3에 가장 큰 팩트 테이블만 넣고,  중간 혹은 작은 크기의 테이블은 edshift에 남겨 두는 것입니다. 이렇게 하면 최적화 프로그램을 가장 효과적으로 활용할 수 있습니다.

최근에 CREATE EXTERNAL TABLEALTER TABLE 명령에서 TABLE PROPERTIES 절을 사용하여 테이블 통계 (numRows)를 설정하는 지원을 추가했습니다. 이를 활용하여 테이블의 정확한 행 번호를 설정하고, 최적의 쿼리 실행 계획을 생성하도록 프로그램에 지시 할 수 있습니다. 자세한 내용은 Amazon Redshift 설명서의 CREATE EXTERNAL TABLE을 참조하십시오.

적어도 세 개의 외부 테이블을 포함하는 추가 쿼리를 정의하고, 올바른 조인 순서 (Explain을 활용 가능)를 사용하여 실행하도록 요청합니다. Amazon Redshift Spectrum을 사용하여 여러 개의 외부 테이블을 절대 결합해서는 안된다는 결론을 성급히 내리지 않도록 하기 위함입니다.

10. 자주 조인하는 대형 테이블을 S3에 넣을 때 조심하기

Amazon Redshift는 Query 2처럼 보이는 질의에 대해서 Redshift Spectrum에서는 많은 동시성 레벨에서 거의 3 배 이상 높은 성능을 보일 수 있습니다. Query 1과 Query 2의 차이점은 Query 1에서 하나의 테이블에 대한 집계 연산만, Query2에서는 비교적 큰 세 개의 테이블 조인 된다는 점입니다.

좀 더 명확하게 말하자면, 성능 차이의 주요 원인은 Amazon Redshift에서 조인이 실행 되기 때문입니다. 조인하는 모든 데이터는 먼저 S3에서 로드되어 Amazon Redshift 클러스터의 개별 슬라이스로 즉시 배포되어야 합니다. 따라서 Amazon Redshift 로컬 스토리지에 접근할 때 보다 Redshift Spectrum을 사용하면 지연 시간이 현저하게 길어집니다.

따라서 조인을 자주하는 서 너개의 테이블이 Amazon Redshift에 있고, 이들 쿼리 작업 부하가 엄격한 SLA의 영향을 받는 경우, 이들은 Amazon S3에 두지 않는 것이 나을 수 있습니다.

마무리

이 글은 Amazon Redshift Spectrum의 성능을 향상시키는 몇 가지 중요한 모범 사례를 설명하였습니다. 각 경우는 특이하기 때문에 모범 사례에 맞는 권장되는 특정 상황에 적용에 대한 테스트를 직접해야 합니다. 질문이나 제안 사항이 있으시거나, Amazon Redshift 클러스터 최적화에 대한 추가 지원이 필요하면 AWS  기술팀에 문의하십시오.

이 글은 AWS 프로페셔널 서비스팀의 빅데이터 컨설턴트로 있는 Po Hong 박사와 Peter Dalton 컨설턴트가 작성하였으며, AWS 빅데이터 블로그의 10 Best Practices for Amazon Redshift Spectrum의 한국어 번역입니다.

Amazon Polly 서울 리전 출시 및 한국어 여성 ‘서연(Seoyeon)’ 음성 공개

 Amazon Polly는 고급 딥 러닝 기술을 사용하여 실제 사람 목소리처럼 음성을 합성하는 텍스트 음성 변환 서비스입니다. 텍스트를 다양한 언어로 수십 개의 생생한 음성이 제공되므로 여러 국가에서 적합한 음성을 선택하여 음성 지원 애플리케이션을 개발할 수 있습니다.

오늘부터 Amazon Polly를 서울 리전에서 사용 가능합니다. 또한, 한국어 여성 ‘서연(Seoyeon)’음성을 공개합니다.

Amazon Polly의 종량 요금제, 변환 문자당 저렴한 비용, 무제한 재생은 거의 모든 애플리케이션에서 음성 합성을 구현하는 비용 효과적인 방법을 제공합니다. 이전에 재생된 오디오를 재생할 때마다 로열티를 요구하거나 요금을 부과하는 다른 솔루션과 달리, Amazon Polly는 추가 요금 없이 무제한 재생을 허용합니다. 이러한 무료 재생은 오프라인 사용까지 확대됩니다. MP3 및 OGG와 같은 다양한 표준 형식으로 음성 파일을 생성하여 오프라인 재생 전용으로 휴대폰 또는 사물 인터넷(IoT) 디바이스와 같은 디바이스에 저장할 수 있습니다.

실제 같은 음성과 대화 사용자 경험을 제공하기 위해서는 일관되게 빠른 응답 시간이 요구됩니다. Amazon Polly API로 긴 텍스트를 전송하더라도 Amazon Polly API가 오디오를 스트림으로 애플리케이션으로 반환하므로 즉시 음성을 재생할 수 있습니다.

아래 샘플 코드에 대한 음성 파일을 확인해 보실 수 있습니다.


from boto3 import client
polly = client("polly", region_name="ap-northeast-2")
response = polly.synthesize_speech(
        Text="안녕하세요. 제 이름은 서연이에요! 저는 새내기 아마존 폴리 음성 비서입니다. 텍스트를 입력하시면 읽어드릴께요.",
        OutputFormat="mp3",
        VoiceId="Seoyeon")

특히, 음성 합성 애플리케이션을 위한 Speech Synthesis Markup Language(SSML), W3C 표준, XML 기반 마크업 언어를 지원하고 표현, 강조 및 억양을 위한 일반 SSML 태그를 지원합니다. 이러한 유연성은 청중의 관심을 끌 수 있는 생생한 음성을 생성하는 데 도움이 됩니다.

아래 샘플 코드에 대한 음성 파일을 확인해 보실 수 있습니다.


<speak>
   오늘의 <prosody rate="x-slow">날씨를 전해 드리겠습니다</prosody>. 
   현재, 전국이 구름이 많은 가운데 일부 중부 지역과 전북에는 <prosody volume="x-loud">눈이 날리거나</prosody><break time="1s"/> <prosody pitch="x-high">빗방울이 떨어지는 곳이 있습니다.
   </prosody>. 서울의 경우 북부 지역을 중심으로 <amazon:effect name="whispered"><prosody rate="-10%">눈이 날리고 있으나,</prosody></amazon:effect> 공식적인 첫눈으로 기록되지는 않습니다.
</speak>

자세한 내용은 SSML 태그에 대한 Amazon Polly 설명서를 참조하십시오.

Amazon Polly는 월 5백만자 까지 무료로 제공됩니다. 그 이상의 경우, 한 자당 $0.000004 per 또는 제작된 오디오 분당 $0.004로 과금 됩니다.  일반적인 한국어 뉴스 기사 (2,500자)의 경우, $0.01 (11원) 정도로 매우 저렴합니다. 예를 들어, 영어로 된 Adventures of Huckleberry Finn이라는 책 원문 전체는 약$2.4 정도 됩니다. 더 자세한 것은 Polly 요금 정보를 참고하세요.

이제 Amazon Polly를 통해 뉴스 및 전자책 리더, 게임, 전자 학습 플랫폼, 시각 장애가 있는 사람을 위한 접근성 애플리케이션, 빠르게 성장하는 사물 인터넷(IoT) 세그먼트 등과 같은 모바일 애플리케이션이 등 다양한 한국어 지원에 활용하실 수 있습니다. Amazon Polly에 대한 더 자세한 사항은 제품 페이지기술 문서를 참고하시기 바랍니다.

윤석찬(Channy);

Amazon Athena, 서울 리전 출시

오늘 Amazon Athena 서비스가 서울 리전에 출시되었습니다. Amazon Athena는 표준 SQL을 사용해 Amazon S3에 저장된 데이터를 간편하게 분석할 수 있는 대화식 쿼리 서비스로서, 서버리스 기반 서비스이므로 관리할 인프라가 없으며 실행한 쿼리에 대해서만 비용을 지불하는 데이터 분석 서비스입니다.

Amazon Athena 서비스에 대한 자료 모음입니다.

좀 더 자세한 것은 기술 문서를 참고하세요.

윤석찬 (Channy);

AWS 관리 콘솔 한국어 홈페이지 공개

오늘 부터 AWS 관리 콘솔 홈페이지 한국어 지원을 시작합니다. 영어, 프랑스어, 일본어, 중국어에 이어 다섯번째로 한국 고객 및 개발자들이 좀 더 편리하고 이해하기 쉬운 콘솔을 제공하게 됩니다.


현재 90여개가 넘는 AWS 서비스 중 Amazon EC2, Amazon S3Amazon RDS 등 40여개가 넘는 각 서비스 콘솔 역시 한국어로 제공하고 있습니다. 서비스별 한국어 지원은 더욱 늘어날 예정이며, AWS를 처음 쓰는 사용자 및 영문 사용자가 어려운 분들을 위해 한국어 지원을 늘려갈 예정입니다. 각 서비스별 한국어 기술 문서 역시 지속적으로 업데이트 되고 있습니다.

만약 여전히 영어로 콘솔을 사용하시고 싶은 분은, 홈페이지 맨 하단으로 내리시면 언어를 선택할 수 있는 메뉴가 나옵니다. 여기서 언어를 “English“를 선택하시면, 영어 콘솔을 활용하실 수 있습니다.

저희는 여러분의 피드백을 통해 한국어 지원을 계속 강화하고 있습니다. 사용 중 콘솔에 대한 의견이 있으시분은 “의견(Feedback)” 메뉴를 통해 보내 주시면 좀 더 나은 서비스에 큰 도움이 될 것입니다.

본 블로그 뿐만 아니라 공식 Twitter페이스북 페이지 같은 소셜 미디어와 발표 자료동영상을 비롯 앞으로 한국 고객을 위한 다양한 고객 지원에 더욱 노력하고자 하니,  많은 성원 부탁 드립니다.

– AWS 코리아 마케팅팀;

Amazon EC2 Container Registry(ECR), 서울 리전 출시

지난 주 Amazon ECS 서비스 서울 리전 출시 이후, 오늘 Amazon EC2 Container Registry(ECR) 서비스도 서울 리전에 출시 합니다.

Amazon ECR 서비스는 콘테이너 기반 서비스 개발자가 Docker 콘테이너 이미지를 손쉽게 저장, 관리 및 배포할 수 있게 해주는 완전관리형 Docker 콘테이너 레지스트리입니다. Amazon ECR은 Amazon EC2 Container Service(ECS)와 통합되어 개발에서 프로덕션까지의 워크플로를 간소화할 수 있을 뿐 아니라 자체 컨테이너 레지스트리를 운영하거나 기본 인프라 확장에 대해 걱정할 필요가 없습니다.

또한, 콘테이너 이미지를 가용성과 확장성이 뛰어난 인프라에 호스팅하여 애플리케이션을 위해 콘테이너를 안정적으로 배포할 수 있습니다. 또한, AWS Identity and Access Management(IAM)와 통합되어 각 리포지토리에 대한 리소스 수준의 제어를 제공합니다.

Amazon ECS/ECR  출시에 맞추어 아래와 같이 온라인 세미나를 준비하였습니다. 관심 있는 분들의 많은 참여를 바랍니다.

기술 기초 | Amazon ECS/ECR 활용하여 마이크로서비스 구성하기
연사: 김기완 AWS 솔루션즈 아키텍트
일시: 2017년 11월 1일 (수) 오전 10:00 – 오전 11:30

콘테이너를 활용하여 마이크로서비스를 구성할 때는 효과적으로 콘테이너 및 서비스를 관리할 수 있는 방법이 필요합니다. 본 세션에서는 유연하게 콘테이너 환경을 관리/모니터링 할 수 있는 Amazon EC2 Container Service 및 EC2 Container Registry를 소개합니다. 아울러 Amazon ECS/ECR 환경에서 효과적인 자원 및 로그 관리, 마이크로서비스 관리에 대해서 자세히 살펴봅니다.

지금 등록하기

Amazon ECR에는 리포지토리에 저장한 콘테이너 이미지 데이터와 인터넷으로 전송한 데이터 양에 대한 요금만 지불합니다. 프리티어 고객은 1년간 500MB 데이터 저장 용량에 대해서 무료입니다. 더 상세한 것은 서울 리전에 대한 ECR 요금표를 참고하시기 바랍니다.

더 자세한 사항은 Amazon ECR 서비스 제품 페이지설명서블로그를 참조하십시오.

윤석찬 (Channy);