워크로드 특성에 따른 안전하고 효율적인 Data Lake 운영 방안

AWS DATA SPECIAL WEBINAR
© 2022, Amazon Web Services, Inc. or its affiliates.
워크로드 특성에 따른
안전하고 효율적인
Data Lake 운영 방안
박성훈
Account Growth Lead
AWS

Agenda
• Data Lakes 구축의 어려움
• 확장 가능한 S3 Keyspace 설계
• 예기치 않은 사고로부터 데이터 보호
• 비용 최적화
2

Customers want more value from their data
3
Growing
exponentially
From new
sources
Increasingly
diverse
Used by
many people
Analyzed by many
applications

Building a Modern Data Strategy
Catalog
Governance
Data
Sources
People,
Apps, and
Devices
Analytics
Machine
Learning Databases
Data
Lakes
4

The benefits of scalable data lakes
5
모든 데이터를 오픈 형식으로 저장
스토리지를 컴퓨팅에서 분리
스토리지를 엑사바이트까지 비용 효율적으로 확장
분석 및 ML 엔진 선택
Catalog
Data lake

Challenges in building data lakes
Challenge #1: Data ingestion
신뢰할 수 있는 데이터 수집
파이프라인을 구축하는 것은
복잡하다 Challenge #2: Data management
S3에 데이터를 저장하고
최적화하는데 시간이 많이 걸린다
Challenge #3: Security & governance
세분화된 권한을 관리는 것이 어렵고 오류가
발생하기 쉽다
Amazon S3 AWS Lake Formation
Data Catalog
AWS Glue ETL
Amazon Athena
Amazon EMR
Amazon Redshift
Spectrum
Amazon
SageMaker
Challenge #5: Data sharing
계정 및 조직 간에 공유하는
것은 복잡하다 6
Challenge #4: Integrations
선택한 서비스나
애플리케이션을 통합하는 것이
어렵다

신뢰할 수 있는 데이터 수집
파이프라인을 구축하는 것은
복잡하다
Challenges in building data lakes
Challenge #3: Security & governance
세분화된 권한을 관리는 것이 어렵고 오류가
발생하기 쉽다
Amazon S3 AWS Lake Formation
Data Catalog
AWS Glue ETL
Amazon Athena
Amazon EMR
Amazon Redshift
Spectrum
Amazon
SageMaker
Challenge #5: Data sharing
계정 및 조직 간에 공유하는
것은 번거로운 작업이다 7
Challenge #2: Data management
S3에 데이터를 저장하고
최적화하는데 시간이 많이 걸린다
Challenge #4: Integrations
선택한 서비스나
애플리케이션을 통합하는 것이
어렵다

확장 가능한
S3 Keyspace 설계
8

Index Performance Baseline
9
Request Method All Regions
GET/HEAD 5,500
requests per second
PUT/POST/DELETE 3,500
requests per second
• 초당 요청은 인덱스 파티션 당 요청입니다.
• 접두사 수에는 제한이 없습니다.
• 503 Slow Down 오류는 요청 속도를 늦추는 주요 지표입니다.

Request rates are allocated proportionally
10
Workload
50% PUT and 50% GET
operations in a single partition
Example 1 Total TPS
(50% * 3,500) + (50% * 5,500) =
1,750 + 2,750 =
4,500 TPS Combined

Request rates are allocated proportionally
11
Workload
50% PUT and 50% GET
Example 1 Total TPS
(50% * 3,500) + (50% * 5,500) =
1,750 + 2,750 =
4,500 TPS Combined
Workload
30% PUT and 70% GET
Example 2 Total TPS
(30% * 3,500) + (70% * 5,500) =
1,050 + 3,850 =
4,900 TPS Combined

How to Increase Requests per Second
• 인덱스를 여러 파티션에 분산
• 인덱스를 분할하는 두 가지 방법
▪ Auto partitioning
➢고객의 개입 없이 S3에서 수행
➢시간이 지남에 따라 S3 워크로드가 점차 증가할 때 잘 동작
▪ Pre-partition request
➢케이스 생성을 통해 지원
➢S3 워크로드가 빠르게 증가할 때 선호
12

Auto Partitioning At Work
13

Optimize Partition Use
2018년 7월 이전
• 접두사 앞에 해시 추가
▪ examplebucket/232a-2013-26-05-15-00-00/cust1234234/photo001.jpg
▪ examplebucket/232b-2013-26-05-15-00-00/cust1234234/photo002.jpg
…
▪ examplebucket/292a-2013-26-05-15-00-00/cust1234234/photo099.jpg
• 접두사 앞에 해시를 추가하여 요청이 여러 인덱스 파티션으로 분산
14

Optimize Partition Use
2018년 7월부터
• Keyspace에 자연명을 사용할 수 있습니다.버킷의 접두사 수에는
제한이 없습니다.
• Keyspace 설계 시, 모든 요청이 동일한 인덱스 파티션에 대해 요청을
수행하는 시나리오를 방지해야 합니다.
• 워크로드가 여러 인덱스 파티션에 걸쳐 잘 분산될 수 있는 높은
카디널리티 접두사를 사용하는 것이 중요합니다.
15

Example: Autonomous vehicles
1. 많은 계측 자동차가 중앙에 위치하고 있습니다.
2. 매일 그 자동차들은 운전을 하고 많은 데이터를
수집합니다.
3. 거의 동시에 차고지로 돌아와서 수집한 데이터를
데이터 레이크에 업로드 합니다.

17
awsexamplebucket/daily-uploads/<date>/<car>/drive-data
객체 Key 이름
버킷 이름
접두사 객체 이름

18
/daily-uploads/20220710/CAR01/drive-data
요구 사항: 3,000 PUTs/sec per car – 15,000 PUTs/sec

19
All cars get throttled
around 3,500
PUTs/sec (total)

20
All cars get throttled
around 3,500
PUTs/sec (total)
New index prefixes
are created, raising
max TPS

21
5개의 인덱스 파티션이 만들어질 때 까지 Throttle이 발생합니다.

22

23

24
S3가 접두사를 기준으로 5개의 인덱스 파티션을 만들었습니다.

25
다음 날은…

26

27

28
/daily-uploads/<date>/<car>/drive-data

29
/daily-uploads/<car>/<date>/drive-data

30
/daily-uploads/CAR01/20220711/drive-data

31

S3 Requests
32
GET s3://mybucket/flight_info/*
mybucket Prefix : flight_info
Client
Sequential read

S3 Requests on Amazon EMR
33
여러 컨테이너가 동시에 단일 접두사에 읽기 요청을 보냅니다.
mybucket Prefix : flight_info
EMR Core/Task Nodes
Read in parallel

S3 Requests on Amazon EMR
34
중복도가 낮은 접두사를 추가하여 요청을 여러 인덱스 파티션으로 분산
mybucket
flight_info/US
EMR Core/Task Nodes
flight_info/EU
Read in parallel

How does S3 automatically scale request rates?
35
BucketName/prefix:
mybucket/flight_info/US/
mybucket/flight_info/EU/
mubucket/ …
3,500 PUT tps
5,500 GET tps
mybucket

36
BucketName/prefix:
mubucket/ …
mybucket
1st Partition
2nd Partition
3,500 PUT tps
5,500 GET tps
3,500 PUT tps
5,500 GET tps
/…
/flight_info

37
BucketName/prefix:
mubucket/ …
mybucket
1st Partition
2nd Partition
3rd Partition
3,500 PUT tps
5,500 GET tps
3,500 PUT tps
5,500 GET tps
3,500 PUT tps
5,500 GET tps
3,500 PUT tps
5,500 GET tps
/flight_info
/…
/US
/EU
/…

예기치 않은 사고로부터
데이터 보호
38

Amazon S3 Versioning
39
Key = cat.jpg
PUT
• 버전 관리를 사용하는 버킷에 객체를
PUT할 때 비 최신 버전은 덮어쓰지
않습니다.
• 실수로 객체를 덮어쓰거나 삭제하는 것을
방지하고, 객체의 이전 버전을 검색할 수
있습니다.
• 더 이상 최신 버전이 아닌 객체를
S3 Lifecycle로 이전하거나 삭제할 수
있습니다.
Key = cat.jpg
Version ID = 2
Key = cat.jpg
Version ID = 1

40
Key = cat.jpg
• 버전 관리를 사용하는 버킷에 객체를
PUT할 때 비 최신 버전은 덮어쓰지
않습니다.
• 실수로 객체를 덮어쓰거나 삭제하는 것을
방지하고, 객체의 이전 버전을 검색할 수
있습니다.
• 더 이상 최신 버전이 아닌 객체를
S3 Lifecycle로 이전하거나 삭제할 수
있습니다.
Key = cat.jpg
Version ID = 2
Key = cat.jpg
Version ID = 1
Key = cat.jpg
Version ID = 2
Key = cat.jpg
Version ID = 1
DELETE
Delete Marker

41

S3 Replication
42
Source
Destination • 버킷 간에 객체를 복제하는 탄력적이고
저렴한 완전 관리형 기능입니다.
• 복제할 위치와 방법을 구성할 수 있는
다양한 기능을 통해 유연성을 제공합니다.
• 복제 규칙이 구성되면 원본 버킷의 객체와
메타데이터를 자동으로 복제합니다.

US East US East
Flexible replication
43
Same Region
동일한 AWS 리전 내에서 복제
Cross-Region
다른 AWS 리전으로 복제
Multiple destinations
여러 대상 버킷에 복제
US East US West
Account A
Cross-account
서로 다른 AWS 계정 간 복제

AWS Backup for S3
44
• AWS 서비스 및 하이브리드 워크로드의 데이터
보호를 중앙 집중화하고 자동화 정책을
기반으로 대규모 데이터 보호를 간편하고 비용
효율적으로 수행할 수 있는 완전 관리형
서비스입니다.
• 클릭 한 번으로 Amazon S3에 저장된
애플리케이션 데이터를 특정 시점으로 쉽게
복원할 수 있습니다.
• 데이터 보호에 대한 규정 준수 또는 비즈니스
정책을 지원하는 데 도움이 됩니다.

AWS Backup for S3
용어 의미
RPO(Recovery Point Objective) 복구 시점 목표
RTO(Recovery Time Objective) 복구에 걸리는 시간 목표
스냅샷(Snapshot) 특정 시점의 데이터 상태
스냅샷 백업(Snapshot Backup) 특정 시점 만을 백업하기 때문에 복원도 해당 시점으로만 가능
연속 백업(Continuous Backup)
첫 번째 전체 백업 (Full Backup) 후 지속적으로 증분 백업을
수행하므로 복원할 수 있는 시점이 광범위
PiTR(Point-in-Time-Recovery) 지정한 특정 시간으로 복구. 지속적 백업으로 가능
백업 용어 정리

AWS Backup for S3
46

AWS Backup for S3
47

AWS Backup for S3
48

S3 Lifecycle
49
Lifecycle Configuration을 사용하여
• 데이터를 보다 비용 효율적인 스토리지
클래스로 이동
• 객체 사용 기간에 따라 만료시켜 시간에
따른 스토리지 지출 관리
데이터를 보다 비용 효율적인 스토리지 클래스로 이동

S3 Lifecycle
50
더 이상 보존할 필요가 없는 데이터 세트의 자동 삭제
Lifecycle Configuration을 사용하여
• 각 객체의 Noncurrent Versions 삭제
• 만료된 객체의 Delete Markers 삭제
• Incomplete Multipart-Uploads 삭제

S3 Lifecycle
51
더 이상 보존할 필요가 없는 데이터 세트의 자동 삭제

Amazon S3 Object Lock
52
S3 Object Lock을 사용하여 객체를 write once, read many(WORM)
모델을 사용하여 저장
거버넌스 모드 규정 준수 모드
• 특별한 권한이 없는 한 사용자는
객체 버전을 덮어쓰거나
삭제하거나 잠금 설정을 변경할
수 없음
• 필요에 따라 일부 사용자에게
보관 설정을 변경하거나 객체를
삭제할 수 있는 권한을 부여할
수 있음
• 보호된 객체 버전은 AWS
계정의 루트 사용자를 포함한
어떤 사용자도 덮어쓰거나
삭제할 수 없음
• 객체를 잠그면 보관 모드를
변경할 수 없으며 보관 기간을
줄일 수 없음

Amazon S3 Object Lock
53
S3 Object Lock을 사용하여 객체를 write once, read many(WORM)
모델을 사용하여 저장
거버넌스 모드 규정 준수 모드
• 특별한 권한이 없는 한 사용자는
객체 버전을 덮어쓰거나
삭제하거나 잠금 설정을 변경할
수 없음
• 필요에 따라 일부 사용자에게
보관 설정을 변경하거나 객체를
삭제할 수 있는 권한을 부여할 수
있음
• 보호된 객체 버전은 AWS
계정의 루트 사용자를 포함한
어떤 사용자도 덮어쓰거나
삭제할 수 없음
• 객체를 잠그면 보관 모드를
변경할 수 없으며 보관 기간을
줄일 수 없음
Object Lock은 고정된 시간 동안 또는 무기한으로
객체의 삭제 또는 덮어쓰기를 방지하는 데 도움이 될 수
있지만 데이터 레이크 데이터 스토어로 사용되는 S3
버킷에 적용하는 것은 아주 신중히 고려해야 합니다.

비용 최적화
54

S3 Intelligent-Tiering Storage Class
55
• 세 가지 액세스 계층 간에 자동으로 객체 이동
• 클라우드에서 가장 낮은 스토리지 비용을
실현하기 위한 비동기식 아카이빙 옵션
• 성능 영향, 운영 오버헤드, 수명주기 비용 또는
검색 비용 없음
• 99.9% 의 가용성과 99.999999999% 의
내구성을 제공하도록 설계

Frequent
Access tier
Infrequent
Access tier
Archive
Instant
Access tier
+30 days +60 days
S3 Intelligent-Tiering automatically optimizes cost in
three access tiers
새로 추가된 Archive Instant
Access Tier로 최대 68%
비용할인

Use S3 Intelligent-Tiering by default for data with
unknown or changing access patterns
Milliseconds access (automatic) Minutes to hours (optional)
Frequent
Access tier
Infrequent
Access tier
Archive
Instant
Access tier
Deep
Archive
Access tier
Archive
Access tier

Considerations for using S3 Intelligent-Tiering Storage
Class
58
• Amazon EMR에서 Hive, Spark, 그리고 Presto
와 같은 오픈 소스 프레임워크
▪ 작업 대상에 Archive Access Tier에 있는 객체가
있는 경우 작업 실패
• Amazon Athena와 Amazon Redshift Spectrum
▪ Query는 오류 없이 결과 값을 반환하지만 Archive
Access Tier에 있는 객체들은 건너뜁니다. 따라서,
예상과 다른 결과 값을 얻을 수 있으므로 Archive
Access Tier 사용 시 주의 필요

Amazon S3 Storage Lens overview
59
• 조직 차원의 가시성
• 29개의 스토리지 사용량 및 활동 지표
• 리전, 스토리지 클래스, 버킷 및 접두사별로
드릴다운
• 비용 효율성 및 데이터 보호 모범 사례를 위한
권장 사항
• 통합된 S3 콘솔 경험

Example Insights from S3 Storage Lens
60
S3 Storage Lens를 사용하여 계정 또는 전체 AWS 조직에서 % noncurrent
version bytes 및 % incomplete MPU bytes를 확인할 수 있습니다.

Takeaways
61

Takeaways
62
워크로드의 I/O 패턴을
고려한 Keyspace 설계

Takeaways
63
S3가 제공하는 기능들과
AWS Backup을 활용한
데이터 보호

Takeaways
64
S3 스토리지 클래스와
분석 도구를 활용한 비용
최적화
S3가 제공하는 기능들과
AWS Backup을 활용한
데이터 보호

Thank you!
박성훈

워크로드 특성에 따른 안전하고 효율적인 Data Lake 운영 방안

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 워크로드 특성에 따른 안전하고 효율적인 Data Lake 운영 방안

Similar to 워크로드 특성에 따른 안전하고 효율적인 Data Lake 운영 방안 (20)

More from Amazon Web Services Korea

More from Amazon Web Services Korea (20)

워크로드 특성에 따른 안전하고 효율적인 Data Lake 운영 방안