Category: Amazon Simple Storage Services (S3)*


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 의 한국어 번역입니다.

Sprinklr의 AWS 리전간 대용량 재해 복구 구축 사례

Sprinklr에서 통합된 고객 경험 관리 플랫폼을 통해 세계에서 가장 큰 브랜드 기업들의 마케팅, 광고, 조사, 관리, 상거래를 지원합니다. Facebook, Twitter, LinkedIn 및 전 세계 22개 기타 소셜 채널과 통합된 당사 플랫폼은 수천 개의 서버를 사용하고, 페타바이트 단위의 데이터를 조사하고, 매일 수십억 건의 트랜잭션을 처리합니다. Twitter 하나만 해도 하루에 몇 억 개의 트윗을 처리해야 합니다.

매일 처리하는 엄청난 데이터 양을 고려할 때 재해 복구(Disaster Recovery, DR)는 더없이 중요한 문제입니다. 자연재해나 인재가 발생하더라도 비즈니스 연속성이 보장되어야 합니다.

대부분의 기업은 DR 대신에 고가용성(HA)을 구현하여 서비스 가동 중지 상황에 대비합니다. HA 보장을 위한 서비스 폴백 메커니즘을 갖추고 있습니다. HA 모드로 실행되는 서비스는 여러 가용 영역에서 실행되지만 동일한 지리적 리전에 속하는 호스트가 처리합니다. 그러나 이러한 접근 방식은 리전 전체가 다운된 경우에 비즈니스의 정상적인 운영을 보장하지 않습니다. DR은 250마일 이상 떨어진 다른 리전에서 복구할 수 있다는 점에서 완전히 새로운 차원을 보여 줍니다. DR 구현은 액티브/패시브 모델로, 이는 여러 리전에서 중요성이 가장 덜한 서비스를 항상 실행하지만 필요할 때 인프라의 주요 부분이 시작 및 복원됨을 뜻합니다.

당면 과제

재해 발생 시 비즈니스 운영이 중단되는 위험을 감수하고 싶지 않습니다. 고객에 대한 약속의 일환으로 튼튼한 재해 복구 프로세스를 갖춰야 합니다. 이는 어느 비즈니스에나 매우 중요합니다. 예를 들어 허리케인 샌디가 기승을 부릴 때 미국 북동부 지역에 데이터 센터가 있는 일부 회사만이 홍수로 인해 오프라인 상태가 되었습니다. 당사 DR의 경우 복구 목표 시점(RPO)이 24시간입니다. 이는 복구할 데이터가 생성된 지 24시간이 지나지 않았음을 뜻합니다. 복구 목표 시간(RTO)은 DR이 선언된 시점으로부터 복원이 완료되기까지 걸리는 시간을 뜻하며, 당사의 경우 고객 SLA에 따라 6시간~24시간입니다. 테스트를 하면서 RTO를 4시간으로 정했습니다.

재해 복구(DR)를 위한 단계

규모 파악

Sprinklr의 리전 간 재해 복구 동기화

목표를 이해하려면 서비스 유형과 그 개수를 포함하여 현재의 작업 규모를 고려해야 합니다. MongoDB, Elasticsearch, SOLR, Mesos, RDS 등 광범위한 데이터/비데이터 서비스 목록이 있습니다. 따라서 서버가 수천 개에 이르는데, ELB는 거의 100개, route53 항목 약 4,000개, 1페타바이트 이상의 기본 데이터, 그리고 RDS 인스턴스 50개 이상이 있습니다. 이러한 서비스는 모두 복원 시점에 DR 리전에서 시작되어야 합니다.

목적 달성을 위해 사용자 지정 스크립트를 작성했는데, 이 스크립트는 주로 AWS API 호출을 통해 인스턴스를 시작하고, 스냅샷을 연결하고, elb 및 경로 항목을 생성합니다.

위 그림과 같이, 관련된 모든 백업은 복원을 위해 DR 리전으로 복사됩니다.

복사할 백업 유형은 크게 세 가지입니다.

  1. EBS 스냅샷: 사용자 지정 로직을 구축하여 사용 가능한 모든 백업과 그 진행 상황 및 완료 여부를 지능적으로 추적합니다.  AWS 한도를 넘지 않고 전체 스냅샷 사본을 얻고자 노력합니다.
  2. S3 스냅샷: cross s3 동기화를 사용하며, 이는 매우 효과적으로 작동합니다. 단 몇 분만에 기본 리전에서 DR 리전으로 데이터를 복사할 수 있습니다.
  3. RDS 스냅샷: AWS RDS CopyDBSnapshot API를 사용하여 RDS 스냅샷을 복사합니다.

DR을 위한 파일럿 라이트 설정

재해 복구 미리 설정빠른 시작을 위해, 재해 복구를 위한 게이트웨이를 얻으려면 몇 가지 서비스가 실행 중이어야 합니다. VPC, 서브넷, Route53 항목을 설정하는 것도 여기에 포함됩니다. 이를 위해 사용자 지정 도구를 구축했습니다. 비슷한 CIDR 구성과 서브넷 마스킹으로 VPC를 만들고, 경로 항목의 경우 새 서브넷이 생성될 때마다 DR 리전에도 자동으로 생성되도록 합니다. 이를 위해 AWS API 호출을 통해 기본 리전의 서브넷 정보를 파악하고, 서부 리전에 해당하는 서브넷을 만들었습니다.

없을 경우 복원을 시작하기 위한 항목을 얻을 수 없는 필수 서비스를 파악합니다. 이는 인증 서버(ldap/IPA, 있는 경우), 빌드 서버 또는 모니터링 서버일 수 있습니다. 이러한 서비스는 항상 실행 중이어야 합니다. 즉 시작 및 설정한 후 어떠한 예기치 못한 상황에서도 항상 DR 리전으로 항목을 가져올 수 있도록 이러한 서비스를 계속 실행함을 뜻합니다.

또한 종속된 AWS 서비스를 사용할 수 있어야 합니다. 예를 들어 S3 버킷을 DR 리전에서 사용할 수 있어야 하고 항상 기본 리전과 동기화해야 합니다. 많은 구성, 속성 파일, 바이너리가 S3에 있기 때문에 이 단계는 중요합니다. 애플리케이션이 계속 작동되도록 하려면 DR 리전에서 이를 사용할 수 있도록 해야 합니다. 이를 위해 S3 교차 리전 복제 기능을 사용합니다. 이는 객체를 빠르고 거의 동시에 동기화하여 놀라운 작업을 수행합니다.

재해 복구 용량 계획의 그림

용량 계획

이제 규모를 고려하여 DR의 필요 용량을 알아내야 합니다.

애플리케이션 관점에서 첫 단계는 DR 리전에서 필요한 구성을 사용할 수 있는지 확인하는 것입니다. 이때 필요한 구성이란 DB별로 다른 파라미터일 수도 있고 사용자 지정된 설정 관련 파라미터일 수도 있지만, 기본적으로 애플리케이션이 작동하는 데 필요한 모든 것을 말합니다. 위 그림과 같이, 복원하는 각 파트너가 당사 DB에 저장한 속성을 토대로 다양한 서비스의 필요 용량을 파악합니다. 예를 들어 파트너 Z는 ES 클러스터 70개, MongoDB 40개, RDS 30개, SOLR 20개가 필요합니다. 다음 단계에서는 모든 서비스를 종합적으로 고려하여 특이한 것을 찾아냅니다. 파트너 간에 클러스터 DB를 공유하므로, 최초의 필요 용량에 있던 클러스터 중 일부를 실제로 다른 파트너들도 공유할 수 있기 때문입니다. 이렇게 해서 최종적인 필요 용량을 파악하고, 이를 인스턴스 유형별로 나눕니다. 위 그림과 같이 Elasticsearch 등 서비스마다 인스턴스 유형이 서로 다릅니다. 마지막으로 해당 인스턴스 유형의 총 필요 용량을 파악하는 일이 남았습니다.

첫 번째 단계가 명확해지면 ELB 및 경로 항목을 몇 개나 생성해야 하는지 알아냅니다. AWS API로 얻은 ELB 및 경로 항목 정보에 대한 메타데이터를 보유하고 있습니다. 이 정보는 서부에 항상 준비되어 있습니다. 이 방법으로 필요 용량의 정확한 수를 알아내고, 인프라를 추정합니다. 여기에는 EC2, ELB 및 경로 항목을 위한 용량 계획도 포함됩니다.

원활한 복구를 위해서는 위 단계 모두 중요하고 서로 밀접하게 관련되어 있으며, 가급적 이를 자동화하는 것이 좋습니다. 우리는 AWS API 호출을 사용한 Perl로 사용자 지정 스크립트를 작성하여 이 모든 단계를 자동화했습니다.

재해 발생 시

우선 순위 정하기

존재하는 여러 서비스 중에 가장 중요한 서비스를 기준으로 시작의 우선 순위를 정하고 서비스의 EC2 인스턴스를 시작해야 합니다. 서비스를 세 가지 세트로 나누는 것이 좋습니다. 이는 핵심적인 서비스를 쉽게 시작할 수 있도록 하기 위한 중요한 결정입니다. 우리가 피하고자 하는 주요 방해 요소는 AWS의 용량 또는 한도 문제입니다.  서비스를 나누면 API 호출 수가 적어지며, AWS가 그 시점에 보유하고 있는 티어 1 서비스에 사용 가능한 인스턴스 유형을 모두 활용할 수 있습니다. 두 번째 세트와 세 번째 세트는 다음에 시도합니다. 이러한 접근 방법의 장점은 우선 AWS API 호출을 너무 많이 사용하지 않고, 복원이 충돌하지 않는다는 것입니다. 이를 위해 다시 사용해야 할 것 같은 AWS API 호출 출력을 캐시하는 캐싱 로직을 개발했습니다. 이를 통해 API 호출 수를 50% 줄일 수 있습니다. 두 번째는 사용 가능한 용량이 대부분 가장 핵심적인 서비스에 할당된다는 점입니다.

용량에 대비한 플랜 B

당장 재해가 발생하면 원하는 인스턴스를 마음대로 시작하지 못할 수 있으므로 실행 시간 인텔리전스를 구축할 필요가 있습니다.

우선 순위가 두 번째나 세 번째인 서비스를 할 때쯤이면 사용 가능한 용량을 다 써버렸을 수도 있습니다. 따라서, 용량 한도를 이미 늘렸습니다. 그러나 어떤 인스턴스 유형은 DR 시점에 AWS에서 사용하지 못할 수 있고, 이로 인해 전체 DR 작업이 위험에 빠질 가능성이 있습니다.

이러한 위험을 완화하기 위해 플랜 B를 수립했습니다. 플랜 B가 준비되고 자동화를 통해 인텔리전스를 구축하여 동일한 패밀리의 다른 인스턴스 유형을 시작합니다. 이 인텔리전스를 구축하기 위해 AWS CloudWatch를 사용합니다. AWS CloudWatch 측정치의 정보를 사용하여 기본 리전의 인스턴스 사용량을 분석합니다. 이를 통해 현재 인스턴스 패밀리 및 유형을 사용할 수 없는 경우에 사용할 수 있는 인스턴스 패밀리 및 유형을 알아낼 수 있습니다. 다시 말해 r3.xlarge 인스턴스 유형을 사용하는 특정 서비스를 예로 들면, CloudWatch 측정치 덕분에 이 서비스가 사용하고 시작해 볼 수 있는 다음 인스턴스 유형을 정하기 위한 모든 정보를 확인할 수 있습니다.

새 인스턴스 유형을 결정하고 나면 인스턴스 개수를 계산해야 합니다. 예를 들어 r3.2xlarge에서 r3.xlarge로 한 단계 아래로 가면 용량을 두 배로 늘려야 할 수 있으며, 한 단계 위로 가면 용량을 절반으로 줄여야 할 수 있습니다. 따라서 실행 시 이를 계산해야 합니다.

다른 AWS 서비스 복원 및 시작

ELB, Route 등 EC2 이외의 서비스 시작이 이제 트리거됩니다. 기본 리전의 S3에서 동기화된 메타데이터를 사용하여 이러한 서비스를 불러옵니다. 메타데이터 정보에는 이 서비스를 시작하는 데 필요한 정보가 들어 있습니다. ELB의 경우 ELB 유형(내부 또는 외부), 인증서 정보, 연결된 서브넷, 연결된 인스턴스입니다. 경로 항목의 경우 DNS 레코드 유형과 그 값입니다.

구성을 위해 EC2 인스턴스 정보가 필요할 수 있으므로 EC2를 시작한 후 이를 시작합니다. 예를 들어 경로 항목에는 EC2 인스턴스의 퍼블릭 IP 주소 정보가 필요할 수 있습니다.

애플리케이션 복원

위 단계를 실행했으면 절반은 온 것입니다. AWS에서 리소스를 가져왔고 애플리케이션 요구 사항에 따라 이를 구성할 수 있었기 때문입니다. AWS에서 얻고자 하는 필요 용량이 대부분 처리되었습니다. 나머지는 주로 애플리케이션 및 로직과 관련이 있습니다. 코드베이스를 사용할 수 있게 준비해 두는 것과 필요 시 DR 리전에 바로 빌드를 배포할 수 있도록 하는 것도 여기에 포함됩니다.

직면한 문제 및 수정

위 모델을 구현한 후 API 호출과 관련된 몇 가지 문제에 직면했습니다. 복원 규모로 인해 엄청난 수의 API 호출이 발생했고, AWS에서는 이를 조정했습니다. API에서 보내는 막대한 정보를 캐시하기 위해 인텔리전트 캐싱 시스템을 개발했습니다. 그 결과 AWS API 호출이 처음의 4분의 1로 줄었습니다.

이 블로그 게시물에서 DR 프로세스의 계획 방식에 대한 아이디어를 얻으시기 바랍니다. DR 계획을 수립하고 주기적으로 테스트하는 것은 자연재해나 인재 발생 시 비즈니스 운영이 중단되지 않도록 하는 데 매우 중요합니다. 자세히 알아보려면 Sprinklr 웹 사이트를 방문하십시오.

이 글은 소셜 미디어 통합 관리 서비스인 Sprinklr의 책임 설계자인Senthilkumar Ramaswamy와 DevOps 책임 엔지니어 Rakesh Pillai가 작성한 AWS Startup 블로그의 Large scale disaster recovery using AWS regions의 한국어 번역입니다.

Amazon S3 및 AWS Glue를 이용한 데이터 레이크 구축하기

데이터 레이크(Data Lake)는 다양한 유형의 대량 데이터를 처리해야 하는 과제를 해결하는 데이터 저장 및 분석 방법으로서 점차 인기를 얻고 있습니다. 데이터 레이크를 사용하면 모든 데이터(정형 및 비정형)를 중앙 집중식 리포지토리 한 곳에 저장할 수 있습니다. 데이터를 있는 그대로 저장할 수 있으므로 데이터를 사전 정의된 스키마로 변환할 필요가 없습니다.

많은 기업들은 데이터 레이크에서 Amazon S3를 사용하는 데 따르는 이점을 잘 알고 있습니다. 예를 들어, 스토리지를 컴퓨팅과 분리한 상태에서 오픈 데이터 형식을 지원하는 Amazon S3는 매우 내구력 있는 경제적 객체 시작점으로서 모든 AWS 분석 서비스와 연동됩니다. Amazon S3는 데이터 레이크의 토대이지만, 다른 서비스를 추가하여 업무상 필요에 맞게 데이터 레이크를 조정할 수 있습니다. AWS를 기반으로 데이터 레이크를 구축하는 방법에 대한 자세한 내용은 데이터 레이크란 소개를 참조하십시오.

데이터 레이크를 사용하는 데 따른 주요 과제 중 하나는 데이터를 찾고 스키마와 데이터 형식을 이해하는 것이므로 Amazon은 최근에 AWS Glue를 도입했습니다. AWS Glue를 사용하면 데이터의 구조와 형식을 검색하여 Amazon S3 데이터 레이크로부터 신속하게 비즈니스 통찰을 이끌어 내는 데 필요한 시간과 노력을 획기적으로 줄일 수 있습니다. 이 서비스는 자동으로 Amazon S3 데이터를 크롤링하여 데이터 형식을 식별한 후 다른 AWS 분석 서비스에 사용할 스키마를 제안합니다.

이 게시물에서는 AWS Glue를 사용하여 Amazon S3에서 데이터를 크롤링하고 다른 AWS 제품군에서 사용 가능한 메타데이터 저장소를 구축하는 과정을 안내합니다.

AWS Glue 기능

AWS Glue는 까다롭고 시간이 많이 소요되는 데이터 검색, 변환, 작업 일정 조정 등과 같은 작업은 간소화 및 자동화하는 종합 관리형 데이터 카탈로그 및 ETL(추출, 변환, 로드) 서비스입니다. AWS Glue는 데이터 소스를 크롤링하고 CSV, Apache Parquet, JSON 등을 비롯한 널리 사용되는 데이터 형식과 데이터 유형에 대해 사전 구축된 분류자를 사용하여 데이터 카탈로그를 생성합니다.

AWS Glue는 최신 데이터 아키텍처의 핵심 구성 요소인 Amazon S3, Amazon RDS, Amazon Athena, Amazon RedshiftAmazon Redshift Spectrum과 통합되어 있으므로 데이터 이동과 관리를 원활하게 조율할 수 있습니다.

AWS Glue 데이터 카탈로그는 Apache Hive 메타스토어와 호환되며 Hive, Presto, Apache Spark, Apache Pig 등 널리 사용되는 도구를 지원합니다. 또한 Amazon Athena, Amazon EMR 및 Amazon Redshift Spectrum과 직접 통합됩니다.

이와 함께 AWS Glue 데이터 카탈로그는 사용 편의성과 데이터 관리 기능을 지원하기 위해 다음과 같은 확장을 제공합니다.

  • 검색을 통해 데이터 찾기
  • 분류를 통해 파일 식별 및 구문 분석
  • 버전 관리를 통해 변화하는 스키마 관리

자세한 내용은 AWS Glue 제품 세부 정보를 참조하십시오.

Amazon S3 데이터 레이크

AWS Glue는 Amazon S3 데이터 레이크의 필수 구성 요소이며, 최신 데이터 분석을 위한 데이터 카탈로그 및 변환 서비스를 제공합니다.

이전 그림에는 다양한 분석 사용 사례에 대한 데이터가 준비되어 있습니다. 처음에는 변경 불가능한 원본 형식으로 데이터를 수집합니다. 그런 다음 데이터를 변환하고 보강하여 각 사용 사례에 유용하게 만들 수 있습니다. 이 예에서는 원시 CSV 파일을 Amazon Athena에서 사용할 수 있는 Apache Parquet으로 변환합니다. Amazon Athena에서 변환된 데이터를 사용하여 성능을 높이고 비용을 절감할 수 있습니다.

또한 다른 데이터 세트와 결합하는 방식으로 데이터를 보강하여 추가적인 통찰력을 얻을 수 있습니다. AWS Glue 크롤러는 작업 트리거 또는 사전 정의된 일정에 따라 데이터 단계별로 테이블을 생성합니다. 이 예에서는 AWS Lambda 함수를 사용하여 원시 데이터 S3 버킷에 새 파일이 추가될 때마다 ETL 프로세스를 트리거합니다. 이 테이블을 사용하면 Amazon Athena, Amazon Redshift Spectrum 및 Amazon EMR에서 표준 SQL 또는 Apache Hive를 사용하여 모든 단계의 데이터를 쿼리할 수 있습니다. 이 구성은 민첩한 비즈니스 인텔리전스를 제공하여 다양한 데이터로부터 빠르고 쉽게 비즈니스 가치를 창출하는 인기 설계 패턴입니다.

직접 실습하기

이 연습에서는 데이터베이스 정의, Amazon S3 버킷에서 데이터를 탐색하도록 크롤러 구성, 테이블 생성, Parquet으로 CSV 파일 변환, Parquet 데이터에 대한 테이블 생성, Amazon Athena를 사용하여 데이터 쿼리 등과 같은 작업을 연습합니다.

데이터 검색

AWS Management Console에 로그인하고 AWS Glue 콘솔을 엽니다. [Analytics] 섹션에서 AWS Glue를 찾을 수 있습니다. AWS Glue는 현재 미국 동부(버지니아), 미국 동부(오하이오) 및 미국 서부(오레곤) 지역에서 사용 가능합니다. 다른 AWS 지역이 수시로 추가됩니다.

데이터를 검색하려면 먼저 데이터베이스를 추가해야 합니다. 데이터베이스는 다수의 테이블로 구성된 집합입니다.

  1. 콘솔에서 [Add database]를 선택합니다. [Database name]에 nycitytaxi를 입력하고 [Create]를 선택합니다.
  2. 탐색 창에서 [ Tables]를 선택합니다. 테이블은 열 이름, 데이터 유형 정의, 데이터 세트에 대한 기타 메타데이터로 구성됩니다.
  3. nycitytaxi 데이터베이스에 테이블을 추가합니다. 크롤러를 사용하거나 수동으로 테이블을 추가할 수 있습니다. 크롤러는 데이터 스토어에 연결하여 분류자의 우선 순위 지정 목록을 통해 데이터의 스키마를 결정하는 프로그램입니다. AWS Glue는 CSV, JSON, Avro 등과 같은 일반 파일 형식에 대한 분류자를 제공합니다. grok 패턴을 사용하여 고유한 분류자를 작성할 수도 있습니다.
  4. 크롤러를 추가하려면 데이터 원본을 입력합니다(Amazon S3 버킷 즉, s3://aws-bigdata-blog/artifacts/glue-data-lake/data/). 이 S3 버킷에는 2017년 1월 한 달 동안의 녹색 택시에 대한 모든 승차 정보로 구성된 데이터 파일이 포함되어 있습니다.
  5. [Next]를 선택합니다.
  6. [IAM role]에 대한 드롭다운 목록에서 기본 역할 AWSGlueServiceRoleDefault를 선택합니다.
  7. [Frequency]에서 [Run on demand]를 선택합니다. 크롤러를 온디맨드로 실행하거나 일정에 따라 실행하도록 설정할 수 있습니다.
  8. [Database]에서 nycitytaxi를 선택합니다. 적절한 방법을 선택하려면 AWS Glue에서 스키마 변경을 처리하는 방법을 잘 알고 있어야 합니다. 이 예에서는 테이블을 변경 사항으로 업데이트합니다. 스키마 변경에 대한 자세한 내용은 AWS Glue 개발자 안내서에서 크롤러를 사용하여 테이블 카탈로그 작성을 참조하십시오.
  9. 단계를 검토하고 [Finish]를 선택합니다. 크롤러를 실행할 준비가 되었습니다. [Run it now]를 선택합니다.

    크롤러가 종료되면 테이블 한 개가 추가되었습니다.
  10. 왼쪽 탐색 창에서 [Tables]를 선택한 다음 [data]를 선택합니다. 이 화면에서는 스키마, 속성 및 기타 중요한 정보를 비롯한 테이블에 대해 설명합니다.

CSV에서 Parquet 형식으로 데이터 변환

이제 CSV에서 Parquet로 데이터를 변환하는 작업을 구성하여 실행할 수 있습니다. Parquet는 Amazon Athena 및 Amazon Redshift Spectrum과 같은 AWS 분석 서비스에 적합한 컬럼 형식입니다.

  1. 왼쪽 탐색 창에서 [ETL]을 선택하고 [Jobs]를 선택한 다음 [Add job]을 선택합니다.
  2. [Name]에 nytaxi-csv-parquet를 입력합니다.
  3. [IAM role]에서 AWSGlueServiceRoleDefault를 선택합니다.
  4. [This job runs]에서 [A proposed script generated by AWS Glue]를 선택합니다.
  5. 스크립트를 저장할 고유한 Amazon S3 경로를 제공합니다.
  6. 임시 디렉터리에 대한 고유한 Amazon S3 디렉터리를 제공합니다.
  7. [Next]를 선택합니다.
  8. 데이터 원본에서 [data]를 선택합니다.
  9. [Create tables in your data target]을 선택합니다.
  10. [Parquet]를 형식으로 선택합니다.
  11. 결과를 저장할 새 위치(기존 객체가 없는 새 접두사 위치)를 선택합니다.
  12. 스키마 매핑을 확인하고 [Finish]를 선택합니다.
  13. 작업을 확인합니다. 이 화면에서는 전체 작업 보기를 제공하며 작업을 편집, 저장 및 실행할 수 있습니다. AWS Glue에서 이 스크립트를 생성했습니다. 필요한 경우 스크립트를 직접 생성할 수 있습니다.
  14. [Save]를 선택한 다음 [Run job]을 선택합니다.

Parquet 테이블 및 크롤러 추가

작업이 완료되면 크롤러를 사용하여 Parquet 데이터에 대한 새 테이블을 추가합니다.

  1. [Crawler name]에 nytaxiparquet를 입력합니다.
  2. S3를 [Data store]로 선택합니다.
  3. [ETL]에서 선택한 Amazon S3 경로 포함
  4. [IAM role]에서 AWSGlueServiceRoleDefault를 선택합니다.
  5. [Database]에 대해 nycitytaxi를 선택합니다.
  6. [Frequency]에서 [Run on demand]를 선택합니다.

크롤러가 완료되면 nycitytaxi 데이터베이스에 두 개의 테이블이 있습니다. 즉, 원시 CSV 데이터용 테이블 한 개와 변환된 Parquet 테이블 한 개가 있습니다.

Amazon Athena를 사용하여 데이터 분석

Amazon Athena는 표준 SQL을 사용해 Amazon S3에 저장된 데이터를 간편하게 분석할 수 있는 대화식 쿼리 서비스입니다. Athena를 사용하여 CSV 데이터를 쿼리할 수 있습니다. 하지만 Parquet 파일 형식을 사용하면 데이터를 쿼리하는 데 필요한 시간과 비용을 획기적으로 줄일 수 있습니다. 자세한 내용은 Analyzing Data in Amazon S3 using Amazon Athena 블로그 게시물을 참조하십시오.

AWS Glue를 Amazon Athena와 함께 사용하려면 Athena 데이터 카탈로그를 AWS Glue 데이터 카탈로그로 업그레이드해야 합니다. Athena 데이터 카탈로그를 업그레이드하는 방법에 대한 자세한 내용은 이 단계별 지침을 참조하십시오.

    1. Athena용 AWS Management Console을 엽니다. 쿼리 편집기에 nycitytaxi의 두 테이블이 표시됩니다.

표준 SQL을 사용하여 데이터를 쿼리할 수 있습니다.

  1. nytaxigreenparquet를 선택합니다.
  2. 유형 "nycitytaxi"에서 *를 선택합니다."data" limit 10;
  3. [Run Query]를 선택합니다.

마무리

이 게시물에서는 AWS Glue 및 Amazon S3를 사용하여 데이터 레이크의 기초를 얼마나 쉽게 구축할 수 있는지를 보여 줍니다. AWS Glue를 사용하여 Amazon S3에서 데이터를 크롤링하고 Apache Hive 호환 메타데이터 저장소를 구축하면 AWS 분석 서비스와 주요 Hadoop 에코시스템 도구를 통해 메타데이터를 사용할 수 있습니다. 이 AWS 서비스 조합은 강력하고 간편하며 비즈니스 통찰을 더 빠르게 얻을 수 있도록 해줍니다.

자세한 내용은 다음 블로그 게시물을 참조하십시오.

작성자 소개

Gordon Heinrich는 글로벌 SI(Systems Integrator)로 활동 중인 솔루션 아키텍트이며, 파트너 및 고객과 협력하여 데이터 레이크를 구축하고 AWS 분석 서비스를 사용하는 데 유용한 설계 지침을 제공합니다. 여가 시간에는 가족과 함께 시간을 보내거나 콜로라도에서 스키, 하이킹, 산악 자전거 등을 즐깁니다.

이 글은 AWS BigData 블로그의 Build a Data Lake Foundation with AWS Glue and Amazon S3의 한국어 버전입니다.

Amazon S3 신규 기본 암호화 및 보안 기능 업데이트

지난 2006년 S3를 발표했을 때, “각 블록은 ACL(액세스 제어 목록)로 보호되기 때문에 개발자가 원한다면 데이터를 프라이빗 데이터로 유지해도 되고, 읽을 수 있는 데이터로 공유해도 되고, 읽고 쓸 수 있는 데이터로 공유해도 된다”라고 알려드렸습니다.

접근 권한 부여를 위한 ACL과 프라이빗 버킷을 적용했던 바로 그 첫 번째 모델부터 우리는 필요에 따라 고객 및 파트너와 데이터를 공유하는 동시에 데이터를 안전하게 보호할 수 있는 도구를 제공하겠다는 목표를 가지고 버킷 정책, 서버 액세스 로깅, 버전 관리, API 로깅, 교차 리전 복제, 그리고 클라이언트서버 측 암호화 옵션 등의 지원을 추가해 왔습니다. 이와 함께 대규모 콘텐츠 검색, 분류 및 보호 도구인 Amazon Macie를 출시하여 인공 지능과 기계 학습의 장점도 가져왔습니다.

그리고 오늘, 드디어 S3에 다음 다섯 가지의 암호화 및 보안 기능을 새로 추가합니다.

  • 기본 암호화 – 이제 암호화되지 않은 객체를 거부하는 버킷 정책을 구성하지 않고도 버킷의 모든 객체를 암호화된 형식으로 저장하게 할 수 있습니다.
  • 권한 확인 – S3 콘솔에서는 공개 액세스가 가능한 각 S3 버킷 옆에 눈에 잘 띄는 표시가 나타납니다.
  • 교차 리전 복제 ACL 덮어쓰기 – AWS 계정 간에 객체를 복제할 때, 대상 계정에 대한 모든 액세스 권한을 제공하는 새 ACL을 해당 객체로 가져오도록 지정할 수 있습니다.
  • KMS를 사용한 교차 리전 복제 – 이제 AWS Key Management Service(KMS)로 관리하는 키를 사용해 암호화된 객체를 복제할 수 있습니다.
  • 세부 인벤토리 보고서 – 이제 S3 인벤토리 보고서에 각 객체의 암호화 상태도 표시됩니다. 또한 이 보고서 자체도 암호화가 가능합니다.

그럼 각 기능을 자세히 살펴보겠습니다.

기본 암호화
S3 객체를 위한 서버 측 암호화 옵션에는 S3 관리 키를 사용하는 SSE-S3, AWS KMS 관리 키를 사용하는 SSE-KMS, 사용자 관리 키를 사용하는 SSE-C, 이렇게 세 가지가 있습니다. 특히 유휴 상태에서도 반드시 암호화해야 한다는 규정 준수 요건을 충족해야 하는 고객을 비롯하여 일부 고객들은 새로 저장하는 모든 객체를 버킷 정책으로 암호화해 왔습니다. 이렇게 하면 요건을 준수하는 데 도움이 되기는 하지만, 암호화되지 않은 객체의 저장을 거부하는 것만으로는 완벽한 솔루션이라 할 수 없습니다.

이제 버킷 암호화 구성을 설치하여 버킷의 모든 객체를 암호화된 형태로 저장하도록 강제할 수 있습니다. 즉, 암호화되지 않은 객체가 S3에 입력되면 이 구성에 따라 암호화 사용을 지시하고, 해당 버킷에 지정된 암호화 옵션을 사용해 그 객체를 암호화하게 됩니다(PUT 요청으로 다른 옵션도 지정 가능).

다음은 버킷을 새로 만들 때 S3 콘솔을 사용하여 이 기능을 활성화하는 방법입니다. 평상시처럼 버킷의 이름을 입력하고 [Next]를 클릭합니다. 그런 다음 아래로 스크롤하여 [Default encryption]을 클릭합니다.

원하는 옵션을 선택하고 [Save]를 클릭합니다(AWS-KMS를 선택하면 KMS 키도 지정해야 함).

PUT 버킷 암호화 기능을 호출해서 이와 같이 변경할 수도 있습니다. 이 경우에는 SSE 알고리즘(SSE-S3 또는 SSE-KMS)을 지정해야 하고, 선택적으로 KMS 키를 참조할 수 있습니다.

이 기능을 구현할 때는 다음을 염두에 두십시오.

SigV4 – S3 REST API를 통해 버킷 정책에 액세스하려면 SigV4로 서명하고 SSL 연결을 이용해야 합니다.

버킷 정책 업데이트 – 암호화되지 않은 객체를 거부하는 기존의 버킷 정책을 살펴본 다음 주의해서 수정해야 합니다.

대량 사용 – SSE-KMS를 사용하고 초당 수백에서 수천 개의 객체를 업로드하는 경우, 암호화 및 암호 해독 작업에 대한 KMS 제한에 걸릴 수 있습니다. 이 경우 다음과 같이 지원 사례를 제출해 한도를 높여 달라고 요청하기만 하면 됩니다.

교차 리전 복제 – 암호화되지 않은 객체는 대상 버킷의 구성에 따라 암호화됩니다. 이렇게 암호화된 객체는 그 상태로 유지됩니다.

권한 확인
버킷 정책, 버킷 ACL 및 객체 ACL를 조합하면 버킷과 버킷 내 객체에 대한 액세스를 매우 세밀하게 제어할 수 있습니다. 사용자의 정책과 ACL을 합쳐 원하는 효과를 얻을 수 있도록 하기 위해, AWS는 최근 S3 버킷 보호를 위한 관리형 구성 규칙을 선보였습니다. 게시물에서 언급했듯이, 이러한 규칙에는 자동 형식 추론을 사용하기 위한 기술이 들어가 있습니다.

이제 바로 그 기본 기술을 사용하여 버킷 정책 및 ACL을 변경하자마자 그 효과를 확인할 수 있습니다. 퍼블릭 액세스를 위해 버킷을 여는 즉시 이러한 효과가 확인되기 때문에 자신 있게 변경할 수 있습니다.

다음은 S3 콘솔 기본 페이지의 모양입니다(편의상 액세스 열 기준으로 정렬).

버킷 중 하나로 들어가 살펴보면 퍼블릭 표시기도 나와 있습니다.

또한 어떤 권한 요소(ACL, 버킷 정책 또는 둘 다)가 퍼블릭 액세스를 지원하고 있는지도 확인할 수 있습니다.

교차 리전 복제 ACL 덮어쓰기
고객들은 흔히 미션 크리티컬 객체 및 데이터를 다른 AWS 계정의 대상 버킷으로 복사할 때 S3의 교차 리전 복제를 사용합니다. 이 복제 프로세스는 객체를 복사하는 한편 객체 ACL 및 그 객체와 연결된 모든 태그를 복사합니다.

여기에 전송 중 ACL를 교체하여 대상 버킷의 소유자에게 모든 액세스 권한을 부여할 수 있도록 함으로써 이 기능을 더욱 유용하게 만들었습니다. 이러한 변경 덕분에 소스 및 대상 데이터의 소유권을 AWS 계정 간에 나눌 수 있고, 이를 토대로 원본 객체와 그 복제본에 대한 소유권 스택을 별도로 관리할 수 있습니다.

복제 설정 시 이 기능을 활성화하려면 계정 ID 및 버킷 이름을 지정한 다음 [Save]를 클릭하여 다른 계정과 다른 리전에 있는 대상 버킷을 선택합니다.

그런 다음 [Change object ownership…]을 클릭합니다.

또한 대상 계정의 대상 버킷에 대한 키 정책을 보다 쉽게 설정할 수 있도록 했습니다. 따라서 계정에 로그인하여 원하는 버킷을 찾은 다음, [Management] 및 [Replication]을 차례로 클릭하고 [More] 메뉴에서 [Receive objects…]를 선택하기만 하면 됩니다.

소스 계정 ID를 입력하고, 버전 관리를 활성화하고, 정책을 살펴보고 적용한 다음 [Done]을 클릭합니다.

KMS를 사용한 교차 리전 복제
SSE-KMS로 암호화한 객체를 리전 간에 복제하는 데는 흥미로운 문제가 있는데, 오늘은 이 문제를 다루고자 합니다. KMS 키는 특정 리전에 고유한 키이기 때문에 암호화된 객체를 복제만 해서는 효과가 없습니다.

이제 교차 리전 복제를 설정할 때 대상 키를 선택할 수 있습니다. 복제 프로세스 중 암호화된 객체는 SSL 연결을 통해 대상으로 복제됩니다. 이어서 대상에서는 복제 구성에 지정된 KMS 마스터 키로 데이터 키를 암호화합니다. 이때 객체는 원래의 암호화된 형태를 끝까지 유지하며, 실제로 달라지는 것은 키가 들어 있는 봉투뿐입니다.

아래 그림은 복제 규칙을 설정할 때 이 기능을 활성화하는 방법을 보여줍니다.

단, 앞서 언급한 것처럼 이 기능을 많이 사용하려면 먼저 KMS 한도 증가를 요청해야 할 수 있습니다.

세부 인벤토리 보고서
마지막으로 역시 중요한 기능이라면, 이제 각 객체의 암호화 상태에 대한 정보를 담은 일별 또는 주별 S3 인벤토리 보고서를 요청할 수 있습니다.

보시다시피 보고서에 대한 SSE-S3 또는 SSE-KMS 암호화를 요청할 수도 있습니다.

정식 출시
모든 기능을 바로 사용할 수 있습니다! 이러한 기능은 무료로 제공되지만 KMS 호출, S3 스토리지, S3 요청 및 리전 간 데이터 전송에는 일반 요금이 청구됩니다.

Jeff;

이 글은 New Amazon S3 Encryption & Security Features의 한국어 버전입니다.

AWS Config 업데이트 – S3 버킷 보안을 위한 두 가지 관리 규칙 추가

AWS Config는 AWS  자원 상태와 그 사이 관계를 계속 모니터링 하는 서비스입니다. 각 서비스 자원을 선택한 다음, 자원에 영향을 주는 구성 변경 타임 라인을 볼 수 있습니다 (자세한 내용은 AWS Config와 AWS 자원 관계 추적을 참조하십시오).

AWS Config rules은 AWS Config의 “관리형” 컬렉션과 사용자가 직접 작성한 사용자 정의 규칙을 지원하는 강력한 규칙 시스템으로 확장합니다 (AWS Config Rules – 클라우드 리소스에 대한 동적 컴플라이언스 검사 등 참조). ). Config Rules (AWS Lambda 함수)은 AWS 자원의 이상적인 상태를 나타냅니다. 함수는 구성 변경이 감지 될 때, 호출되며 표준 규정 준수 여부를 확인합니다.

약 30 개의 관리 규칙에 접근할 수 있으며, 예를 들어 EC2 인스턴스 및 관련 리소스를 확인하는 몇 가지 규칙은 다음과 같습니다.

두 가지 신규 규칙
오늘은 S3 버킷 보안을 유지하는 데 도움이되는 두 개의 새로운 관리 규칙을 추가하고 있습니다. 클릭 한 번으로 이러한 규칙을 활성화 할 수 있습니다. 새로운 규칙은 다음과 같습니다.

s3-bucket-public-write-prohibited – 전역 쓰기 접근을 허용하는 버킷을 자동으로 식별합니다. 이 구성을 의도적으로 만들지 않는 이유는 권한이 없는 사용자가 악성 콘텐트를 버킷에 추가하고 기존 콘텐트를 삭제 (덮어 쓰기) 할 수 있습니다.  이 규칙은 계정의 모든 버킷을 검사합니다.

s3-bucket-public-read-prohibited – 전역 읽기 접근 허용하는 버킷을 자동으로 식별합니다. 그러면, 웹 사이트 및 문서를 포함하여 공개적으로 사용할 수 있는 콘텐츠의 플래그가 지정됩니다. 이 규칙은 계정의 모든 버킷을 검사합니다.

기존 규칙과 마찬가지로 새 규칙은 일정에 따라 또는 Config가 감지 한 변경 사항에 따라 실행될 수 있습니다. 모든 규칙의 준수 상태를 한 눈에 볼 수 있습니다.

각 규정 준수 평가는 밀리 세컨드 단위로 실행됩니다. 100 개의 버킷으로 계정을 검색하는 데 1 분도 안 걸립니다. 대부분의 경우, NP 완료 문제를 다항식 시간에 처리 할 수 있는 최첨단 제약 해결 기법을 사용하는 추론 엔진에 의해 규칙이 평가됩니다 (NP 대 P 문제 참조). 이 작업은 AWS 내부의 개발 부분 중 하나로서 아래의 re:Invent  Automated Formal Reasoning About AWS Systems 발표 자료를 참고하시기 바랍니다.

정식 출시
새로운 규칙은 현재 사용할 수 있으며 오늘부터 사용할 수 있습니다. 다른 규칙과 마찬가지로 한 달에 규칙 당 2 달러로 책정됩니다.

Jeff;

이 글은 AWS Config Update – New Managed Rules to Secure S3 Buckets의 한국어 번역입니다.