Amazon Aurora 는 엔터프라이즈급의 가용성과 성능을 제공합니다. 실제 적용에서 Aurora성능 개선을 위해 무엇을 해야하는지, 그에 따른 모범 사례는 무엇이 있는지 본 세션에서 살펴봅니다. 또한 AWS Lambda 및 Amazon S3 와 같은 AWS의 다양한 서비스와 통합하는 최근 기능들에 대하여 상세하게 살펴보고 한국 고객들이 Aurora를 도입 및 마이그레이션한 사례를 통해 어떻게 마이그레이션에 접근해야 하는지를 살펴봅니다.
연사: 구승모, 아마존 웹서비스 솔루션즈 아키텍트
Internal Architecture of Amazon Aurora (Level 400) - 발표자: 정달영, APAC RDS Speci...Amazon Web Services Korea
ccAmazon Aurora 데이터베이스는 클라우드용으로 구축된 관계형 데이터베이스입니다. Aurora는 상용 데이터베이스의 성능과 가용성, 그리고 오픈소스 데이터베이스의 단순성과 비용 효율성을 모두 제공합니다. 이 세션은 Aurora의 고급 사용자들을 위한 세션으로써 Aurora의 내부 구조와 성능 최적화에 대해 알아봅니다.
데이터 분석가를 위한 신규 분석 서비스 - 김기영, AWS 분석 솔루션즈 아키텍트 / 변규현, 당근마켓 소프트웨어 엔지니어 :: AWS r...Amazon Web Services Korea
AWS re:Invent에서는 다양한 고객들의 요구에 맞추어 새로운 분석 및 서버리스 서비스가 대거 출시되었습니다. 본 강연에서는 새롭게 출시된 핵심 분석 기능들과 함께, 누구나 손쉽게 사용할 수 있는 AWS의 분석 서버리스와 On-demand 기능들에 대한 심층적인 정보를 확인하실 수 있습니다.
최근 국내와 글로벌 서비스에서 MongoDB를 사용하는 사례가 급증하고 있습니다. 다만 전통적인 RDBMS에 비해, 아직 지식과 경험의 축적이 적게 되어 있어 손쉬운 접근과 트러블 슈팅등에 문제가 있는 것도 사실입니다. 이 세션에서는 MongoDB 와 AWS의 DocumentDB의 Architecure를 간단히 살펴보고 MongoDB 및 DocumentDB의 비교를 진행하며 특히 MongoDB와 DocumentDB를 사용할때 주의해야할 중요 포인트에 대해서 알아봅니다.
최근 국내에도 글로벌 서비스나 급성장하는 웹 서비스를 쉽게 볼 수 있습니다. 초기에 RDBMS로 시작된 서비스들은 규모가 성장함에 따라 샤딩과 NoSQL의 선택의 기로에 서게 됩니다. Amazon DynamoDB는 모든 스케일에서 사용할 수 있는 완전 관리형 Key-Value NoSQL 데이터베이스이지만 여전히 Key Design은 가장 어려운 영역 중 하나입니다. 이 세션에서는 대규모 서비스의 키 디자인 방법을 알아봅니다.
본 세션에서는 Amazon의 관리형 데이터베이스 서비스(RDS) 중 기존 상용데이터베이스의 5배 성능 및 1/10 가격으로도 확장성을 보장하는 Aurora에 대한 소개 및 사용법 그리고 기존의 DB에서의 마이그레이션 방법에 대해 소개해드립니다. 10월 리인벤트를 통해 동경 리전에 Aurora를 사용가능하게 되었습니다.
OpenSearch는 배포형 오픈 소스 검색과 분석 제품군으로 실시간 애플리케이션 모니터링, 로그 분석 및 웹 사이트 검색과 같이 다양한 사용 사례에 사용됩니다. OpenSearch는 데이터 탐색을 쉽게 도와주는 통합 시각화 도구 OpenSearch와 함께 뛰어난 확장성을 지닌 시스템을 제공하여 대량 데이터 볼륨에 빠르게 액세스 및 응답합니다. 이 세션에서는 실제 동작 구조에 대한 설명을 바탕으로 최적화를 하기 위한 방법과 운영상에 발생할 수 있는 이슈에 대해서 알아봅니다.
Internal Architecture of Amazon Aurora (Level 400) - 발표자: 정달영, APAC RDS Speci...Amazon Web Services Korea
ccAmazon Aurora 데이터베이스는 클라우드용으로 구축된 관계형 데이터베이스입니다. Aurora는 상용 데이터베이스의 성능과 가용성, 그리고 오픈소스 데이터베이스의 단순성과 비용 효율성을 모두 제공합니다. 이 세션은 Aurora의 고급 사용자들을 위한 세션으로써 Aurora의 내부 구조와 성능 최적화에 대해 알아봅니다.
데이터 분석가를 위한 신규 분석 서비스 - 김기영, AWS 분석 솔루션즈 아키텍트 / 변규현, 당근마켓 소프트웨어 엔지니어 :: AWS r...Amazon Web Services Korea
AWS re:Invent에서는 다양한 고객들의 요구에 맞추어 새로운 분석 및 서버리스 서비스가 대거 출시되었습니다. 본 강연에서는 새롭게 출시된 핵심 분석 기능들과 함께, 누구나 손쉽게 사용할 수 있는 AWS의 분석 서버리스와 On-demand 기능들에 대한 심층적인 정보를 확인하실 수 있습니다.
최근 국내와 글로벌 서비스에서 MongoDB를 사용하는 사례가 급증하고 있습니다. 다만 전통적인 RDBMS에 비해, 아직 지식과 경험의 축적이 적게 되어 있어 손쉬운 접근과 트러블 슈팅등에 문제가 있는 것도 사실입니다. 이 세션에서는 MongoDB 와 AWS의 DocumentDB의 Architecure를 간단히 살펴보고 MongoDB 및 DocumentDB의 비교를 진행하며 특히 MongoDB와 DocumentDB를 사용할때 주의해야할 중요 포인트에 대해서 알아봅니다.
최근 국내에도 글로벌 서비스나 급성장하는 웹 서비스를 쉽게 볼 수 있습니다. 초기에 RDBMS로 시작된 서비스들은 규모가 성장함에 따라 샤딩과 NoSQL의 선택의 기로에 서게 됩니다. Amazon DynamoDB는 모든 스케일에서 사용할 수 있는 완전 관리형 Key-Value NoSQL 데이터베이스이지만 여전히 Key Design은 가장 어려운 영역 중 하나입니다. 이 세션에서는 대규모 서비스의 키 디자인 방법을 알아봅니다.
본 세션에서는 Amazon의 관리형 데이터베이스 서비스(RDS) 중 기존 상용데이터베이스의 5배 성능 및 1/10 가격으로도 확장성을 보장하는 Aurora에 대한 소개 및 사용법 그리고 기존의 DB에서의 마이그레이션 방법에 대해 소개해드립니다. 10월 리인벤트를 통해 동경 리전에 Aurora를 사용가능하게 되었습니다.
OpenSearch는 배포형 오픈 소스 검색과 분석 제품군으로 실시간 애플리케이션 모니터링, 로그 분석 및 웹 사이트 검색과 같이 다양한 사용 사례에 사용됩니다. OpenSearch는 데이터 탐색을 쉽게 도와주는 통합 시각화 도구 OpenSearch와 함께 뛰어난 확장성을 지닌 시스템을 제공하여 대량 데이터 볼륨에 빠르게 액세스 및 응답합니다. 이 세션에서는 실제 동작 구조에 대한 설명을 바탕으로 최적화를 하기 위한 방법과 운영상에 발생할 수 있는 이슈에 대해서 알아봅니다.
Amazon OpenSearch - Use Cases, Security/Observability, Serverless and Enhance...Amazon Web Services Korea
로그 및 지표 데이터를 쉽게 가져오고, OpenSearch 검색 API를 사용하고, OpenSearch 대시보드를 사용하여 시각화를 구축하는 등 Amazon OpenSearch의 새로운 기능과 기능에 대해 자세히 알아보십시오. 애플리케이션 문제를 디버깅할 수 있는 OpenSearch의 Observability 기능에 대해 알아보세요. Amazon OpenSearch Service를 통해 인프라 관리에 대해 걱정하지 않고 검색 또는 모니터링 문제에 집중할 수 있는 방법을 알아보십시오.
아름답고 유연한 데이터 파이프라인 구축을 위한 Amazon Managed Workflow for Apache Airflow - 유다니엘 A...Amazon Web Services Korea
Apache Airflow는 복잡한 데이터 처리 파이프라인의 전체적인 프로세스를 자동화하기 위한 워크플로우 관리 플랫폼이며 오픈 소스 커뮤니티에서 활발하게 기여하고 있는 top-level 프로젝트 입니다. AWS는 최근에 Amazon Managed Workflow for Apache Airflow (MWAA) 서비스를 정식 출시하였고, 본 강연에서는 Apache Airflow 및 MWAA를 소개하고 어떻게 AWS 서비스와 연동하여 데이터 처리 워크플로우를 구축할 수 있는지 데모를 통해 알려 드립니다.
대용량 데이터베이스의 클라우드 네이티브 DB로 전환 시 확인해야 하는 체크 포인트-김지훈, AWS Database Specialist SA...Amazon Web Services Korea
고객사 A는 하루 30억 트랜잭션과 연 750TB의 데이터베이스를 온프레미스 환경에서 상용 데이터베이스를 이용하여 운영 중입니다. 또한 매일 대용량의 배치가 발생하고 실시간으로 대량의 조회가 발생하는 미션 크리티컬 시스템입니다. 고객사 A와 함께 클라우드 환경에서 동일한 워크로드의 수행이 가능한지 여부를 검증하는 Feasiblity Pilot 프로젝트를 진행하였고 여기서의 레슨런을 공유합니다. 마이그레이션 도중 고객 IT팀은 On-premise 운영 모델에서 클라우드 운영 모델로 전환되어야 합니다. 전환 도중에 ITIL을 클라우드, 애자일, DevOps 기반 역량과 프로세스에 매핑해야 합니다. 해당 세션에서는 클라우드 운영 모델로 원활한 전환을 도와주는 CEE (Cloud Enablement Engine)의 작동 원리 및 적용 방식을 살펴보고자 합니다.
Introducing Amazon Aurora with PostgreSQL Compatibility - AWS Online Tech TalksAmazon Web Services
Learning Objectives:
- Learn about optimizing relational databases for the cloud
- Learn about Amazon Aurora scalability and high availability
- Learn about Amazon Aurora compatibility with PostgreSQL
(SDD407) Amazon DynamoDB: Data Modeling and Scaling Best Practices | AWS re:I...Amazon Web Services
Amazon DynamoDB is a fully managed, highly scalable distributed database service. In this technical talk, we show you how to use DynamoDB to build high-scale applications like social gaming, chat, and voting. We show you how to use building blocks such as secondary indexes, conditional writes, consistent reads, and batch operations to build the higher-level functionality such as multi-item atomic writes and join queries. We also discuss best practices such as index projections, item sharding, and parallel scan for maximum scalability.
효율적인 빅데이터 분석 및 처리를 위한 Glue, EMR 활용 - 김태현 솔루션즈 아키텍트, AWS :: AWS Summit Seoul 2019Amazon Web Services Korea
효율적인 빅데이터 분석 및 처리를 위한 Glue, EMR 활용
김태현 솔루션즈 아키텍트, AWS
AWS에서는 Big Data 분석 및 처리를 위해 분석 목적에 맞는 다양한 Big Data Framework 서비스를 지원합니다. 이 세션에서는 시간이 지날수록 증가하는 데이터의 분석 및 처리를 위해 사용되는 AWS Glue와 Amazon EMR 같은 AWS Big Data Framework의 내부구조를 살펴보고 머신러닝을 포함한 다양한 분석 및 ETL을 위해 효율적으로 사용할 수 있는 방법들을 소개합니다.
Oracle DB를 AWS로 이관하는 방법들 - 서호석 클라우드 사업부/컨설팅팀 이사, 영우디지탈 :: AWS Summit Seoul 2021Amazon Web Services Korea
Oracle DBMS 는 국내 대기업에서 압도적으로 가장 많이 사용하는 DB 로, 이 세션에서는 Oracle DB 를 AWS 로 이관하는 방법들에 대하여 살펴보겠습니다. 환경에 따라 Oracle DB 를 이관하는 어떤 방법들이 있는지 알아보며, AWS DMS(Database Migration Service) 를 사용하여 효과적으로 이관할수 있는 방법을 소개합니다. Oracle DB 를 클라우드 환경으로 이관할 때 유의해야할 포인트들에 대해 함께 공유합니다.
AWS의 CDN 서비스인 CloudFront의 가속 및 DDoS 방어 소개
# CloudFront 장점
- 수퍼 PoP: AWS 클라우드 구축/운영 Know-How 가 담긴 고성능/대용량 아키텍쳐
* 국내 최대 Capacity / 가장 빠르게 성장하는 글로벌 CDN 서비스
- Single-Service: (캐싱, 다이나믹 가속, HTTPS, AWS Shield Standard 등) 동일 가격 체계로 제공
- AWS Backbone 전용망: Edge <=> Origin 가속
- 인라인 DDoS 방어: Shield Standard & Advance
- AWS 서비스 연동성
Amazon OpenSearch - Use Cases, Security/Observability, Serverless and Enhance...Amazon Web Services Korea
로그 및 지표 데이터를 쉽게 가져오고, OpenSearch 검색 API를 사용하고, OpenSearch 대시보드를 사용하여 시각화를 구축하는 등 Amazon OpenSearch의 새로운 기능과 기능에 대해 자세히 알아보십시오. 애플리케이션 문제를 디버깅할 수 있는 OpenSearch의 Observability 기능에 대해 알아보세요. Amazon OpenSearch Service를 통해 인프라 관리에 대해 걱정하지 않고 검색 또는 모니터링 문제에 집중할 수 있는 방법을 알아보십시오.
아름답고 유연한 데이터 파이프라인 구축을 위한 Amazon Managed Workflow for Apache Airflow - 유다니엘 A...Amazon Web Services Korea
Apache Airflow는 복잡한 데이터 처리 파이프라인의 전체적인 프로세스를 자동화하기 위한 워크플로우 관리 플랫폼이며 오픈 소스 커뮤니티에서 활발하게 기여하고 있는 top-level 프로젝트 입니다. AWS는 최근에 Amazon Managed Workflow for Apache Airflow (MWAA) 서비스를 정식 출시하였고, 본 강연에서는 Apache Airflow 및 MWAA를 소개하고 어떻게 AWS 서비스와 연동하여 데이터 처리 워크플로우를 구축할 수 있는지 데모를 통해 알려 드립니다.
대용량 데이터베이스의 클라우드 네이티브 DB로 전환 시 확인해야 하는 체크 포인트-김지훈, AWS Database Specialist SA...Amazon Web Services Korea
고객사 A는 하루 30억 트랜잭션과 연 750TB의 데이터베이스를 온프레미스 환경에서 상용 데이터베이스를 이용하여 운영 중입니다. 또한 매일 대용량의 배치가 발생하고 실시간으로 대량의 조회가 발생하는 미션 크리티컬 시스템입니다. 고객사 A와 함께 클라우드 환경에서 동일한 워크로드의 수행이 가능한지 여부를 검증하는 Feasiblity Pilot 프로젝트를 진행하였고 여기서의 레슨런을 공유합니다. 마이그레이션 도중 고객 IT팀은 On-premise 운영 모델에서 클라우드 운영 모델로 전환되어야 합니다. 전환 도중에 ITIL을 클라우드, 애자일, DevOps 기반 역량과 프로세스에 매핑해야 합니다. 해당 세션에서는 클라우드 운영 모델로 원활한 전환을 도와주는 CEE (Cloud Enablement Engine)의 작동 원리 및 적용 방식을 살펴보고자 합니다.
Introducing Amazon Aurora with PostgreSQL Compatibility - AWS Online Tech TalksAmazon Web Services
Learning Objectives:
- Learn about optimizing relational databases for the cloud
- Learn about Amazon Aurora scalability and high availability
- Learn about Amazon Aurora compatibility with PostgreSQL
(SDD407) Amazon DynamoDB: Data Modeling and Scaling Best Practices | AWS re:I...Amazon Web Services
Amazon DynamoDB is a fully managed, highly scalable distributed database service. In this technical talk, we show you how to use DynamoDB to build high-scale applications like social gaming, chat, and voting. We show you how to use building blocks such as secondary indexes, conditional writes, consistent reads, and batch operations to build the higher-level functionality such as multi-item atomic writes and join queries. We also discuss best practices such as index projections, item sharding, and parallel scan for maximum scalability.
효율적인 빅데이터 분석 및 처리를 위한 Glue, EMR 활용 - 김태현 솔루션즈 아키텍트, AWS :: AWS Summit Seoul 2019Amazon Web Services Korea
효율적인 빅데이터 분석 및 처리를 위한 Glue, EMR 활용
김태현 솔루션즈 아키텍트, AWS
AWS에서는 Big Data 분석 및 처리를 위해 분석 목적에 맞는 다양한 Big Data Framework 서비스를 지원합니다. 이 세션에서는 시간이 지날수록 증가하는 데이터의 분석 및 처리를 위해 사용되는 AWS Glue와 Amazon EMR 같은 AWS Big Data Framework의 내부구조를 살펴보고 머신러닝을 포함한 다양한 분석 및 ETL을 위해 효율적으로 사용할 수 있는 방법들을 소개합니다.
Oracle DB를 AWS로 이관하는 방법들 - 서호석 클라우드 사업부/컨설팅팀 이사, 영우디지탈 :: AWS Summit Seoul 2021Amazon Web Services Korea
Oracle DBMS 는 국내 대기업에서 압도적으로 가장 많이 사용하는 DB 로, 이 세션에서는 Oracle DB 를 AWS 로 이관하는 방법들에 대하여 살펴보겠습니다. 환경에 따라 Oracle DB 를 이관하는 어떤 방법들이 있는지 알아보며, AWS DMS(Database Migration Service) 를 사용하여 효과적으로 이관할수 있는 방법을 소개합니다. Oracle DB 를 클라우드 환경으로 이관할 때 유의해야할 포인트들에 대해 함께 공유합니다.
AWS의 CDN 서비스인 CloudFront의 가속 및 DDoS 방어 소개
# CloudFront 장점
- 수퍼 PoP: AWS 클라우드 구축/운영 Know-How 가 담긴 고성능/대용량 아키텍쳐
* 국내 최대 Capacity / 가장 빠르게 성장하는 글로벌 CDN 서비스
- Single-Service: (캐싱, 다이나믹 가속, HTTPS, AWS Shield Standard 등) 동일 가격 체계로 제공
- AWS Backbone 전용망: Edge <=> Origin 가속
- 인라인 DDoS 방어: Shield Standard & Advance
- AWS 서비스 연동성
AWS에서는 애플리케이션의 목적과 특징에 맞는 다양한 클라우드 기반 데이터베이스 선택 옵션을 제공합니다. 본 세션에서는 클라우드 DB 서비스를 간단히 알아보고, 그 중에서도 DB 서버 및 클러스터 관리 및 운영에 대한 걱정이 전혀 없는 서버리스(Serverless) DB 서비스인 Amazon Aurora Serverless와 DynamoDB에 대해 자세히 알아봅니다. DB 관리 및 운영 등의 번거러운 작업은 AWS에 맡기고, 비지니스 로직에 필요한 데이터 모델 구성 및 쿼리 최적화 등에 집중하여 시장에 요구에 따른 비지니스에 민첩한 서비스를 만드는 방법을 알아 봅니다.
스폰서 발표 세션 | Zero-risk 엔터프라이즈 클라우드 스토리지
조순현 부장, Zadara
Zadara는 엔터프라이즈 스토리지입니다. 모든 데이터 유형, 모든 프로토콜을 클라우드 상에서 제공합니다. 클라우드 스토리지 사용에 있어 기술 위험, 운영 위험 및 재정적 위험을 Zadatra 스토리지를 통해 제거하는 방안을 제시합니다.
게임 서비스를 위한 AWS상의 고성능 SQL 데이터베이스 구성 (이정훈 솔루션즈 아키텍트, AWS) :: Gaming on AWS 2018Amazon Web Services Korea
게임 서비스를 위한 AWS상의 고성능 SQL 데이터베이스 구성
게임 서비스 아키텍처에서 관계형 데이터베이스는 핵심 컴포넌트이며 또한 전체 서비스의 성능 병목 지점이 되곤 합니다. 이 세션에서는 AWS 상에서 게임 서비스를 구현할 때, 기존 물리환경에서의 DB 성능과 동일하거나 더 높은 성능을 얻을 수 있는 구성을 설명 드리며, MS SQL 구성의 성능 데모를 시연하고자 합니다.
사례로 알아보는 Database Migration Service : 데이터베이스 및 데이터 이관, 통합, 분리, 분석의 도구 - 발표자: ...Amazon Web Services Korea
Database Migration Service(DMS)는 RDBMS 이외에도 다양한 데이터베이스 이관을 지원합니다. 실제 고객사 사례를 통해 DMS가 데이터베이스 이관, 통합, 분리를 수행하는 데 어떻게 활용되는지 알아보고, 동시에 데이터 분석을 위한 데이터 수집(Data Ingest)에도 어떤 역할을 하는지 살펴보겠습니다.
Amazon Elasticache - Fully managed, Redis & Memcached Compatible Service (Lev...Amazon Web Services Korea
Amazon ElastiCache는 Redis 및 MemCached와 호환되는 완전관리형 서비스로서 현대적 애플리케이션의 성능을 최적의 비용으로 실시간으로 개선해 줍니다. ElastiCache의 Best Practice를 통해 최적의 성능과 서비스 최적화 방법에 대해 알아봅니다.
[Keynote] 슬기로운 AWS 데이터베이스 선택하기 - 발표자: 강민석, Korea Database SA Manager, WWSO, A...Amazon Web Services Korea
오랫동안 관계형 데이터베이스가 가장 많이 사용되었으며 거의 모든 애플리케이션에서 널리 사용되었습니다. 따라서 애플리케이션 아키텍처에서 데이터베이스를 선택하기가 더 쉬웠지만, 구축할 수 있는 애플리케이션의 유형이 제한적이었습니다. 관계형 데이터베이스는 스위스 군용 칼과 같아서 많은 일을 할 수 있지만 특정 업무에는 완벽하게 적합하지는 않습니다. 클라우드 컴퓨팅의 등장으로 경제적인 방식으로 더욱 탄력적이고 확장 가능한 애플리케이션을 구축할 수 있게 되면서 기술적으로 가능한 일이 달라졌습니다. 이러한 변화는 전용 데이터베이스의 부상으로 이어졌습니다. 개발자는 더 이상 기본 관계형 데이터베이스를 사용할 필요가 없습니다. 개발자는 애플리케이션의 요구 사항을 신중하게 고려하고 이러한 요구 사항에 맞는 데이터베이스를 선택할 수 있습니다.
Demystify Streaming on AWS - 발표자: 이종혁, Sr Analytics Specialist, WWSO, AWS :::...Amazon Web Services Korea
실시간 분석은 AWS 고객의 사용 사례가 점점 늘어나고 있습니다. 이 세션에 참여하여 스트리밍 데이터 기술이 어떻게 데이터를 즉시 분석하고, 시스템 간에 데이터를 실시간으로 이동하고, 실행 가능한 통찰력을 더 빠르게 얻을 수 있는지 알아보십시오. 일반적인 스트리밍 데이터 사용 사례, 비즈니스에서 실시간 분석을 쉽게 활성화하는 단계, AWS가 Amazon Kinesis와 같은 AWS 스트리밍 데이터 서비스를 사용하도록 지원하는 방법을 다룹니다.
Amazon EMR - Enhancements on Cost/Performance, Serverless - 발표자: 김기영, Sr Anal...Amazon Web Services Korea
Amazon EMR은 Apache Spark, Hive, Presto, Trino, HBase 및 Flink와 같은 오픈 소스 프레임워크를 사용하여 분석 애플리케이션을 쉽게 실행할 수 있는 관리형 서비스를 제공합니다. Spark 및 Presto용 Amazon EMR 런타임에는 오픈 소스 Apache Spark 및 Presto에 비해 두 배 이상의 성능 향상을 제공하는 최적화 기능이 포함되어 있습니다. Amazon EMR Serverless는 Amazon EMR의 새로운 배포 옵션이지만 데이터 엔지니어와 분석가는 클라우드에서 페타바이트 규모의 데이터 분석을 쉽고 비용 효율적으로 실행할 수 있습니다. 이 세션에 참여하여 개념, 설계 패턴, 라이브 데모를 사용하여 Amazon EMR/EMR 서버리스를 살펴보고 Spark 및 Hive 워크로드, Amazon EMR 스튜디오 및 Amazon SageMaker Studio와의 Amazon EMR 통합을 실행하는 것이 얼마나 쉬운지 알아보십시오.
Enabling Agility with Data Governance - 발표자: 김성연, Analytics Specialist, WWSO,...Amazon Web Services Korea
데이터 거버넌스는 전체 프로세스에서 데이터를 관리하여 데이터의 정확성과 완전성을 보장하고 필요한 사람들이 데이터에 액세스할 수 있도록 하는 프로세스입니다. 이 세션에 참여하여 AWS가 어떻게 분석 서비스 전반에서 데이터 준비 및 통합부터 데이터 액세스, 데이터 품질 및 메타데이터 관리에 이르기까지 포괄적인 데이터 거버넌스를 제공하는지 알아보십시오. AWS에서의 스트리밍에 대해 자세히 알아보십시오.
Amazon Redshift Deep Dive - Serverless, Streaming, ML, Auto Copy (New feature...Amazon Web Services Korea
이 세션에 참여하여 Amazon Redshift의 새로운 기능을 자세히 살펴보십시오. Amazon Data Sharing, Amazon Redshift Serverless, Redshift Streaming, Redshift ML 및 자동 복사 등에 대한 자세한 내용과 데모를 통해 Amazon Redshift의 새로운 기능을 알고 싶은 사용자에게 적합합니다.
From Insights to Action, How to build and maintain a Data Driven Organization...Amazon Web Services Korea
데이터는 혁신과 변혁의 토대입니다. 비즈니스 혁신을 이끄는 혁신은 특정 시점의 전략이나 솔루션이 아니라 성장을 위한 반복적이고 집단적인 계획입니다. 혁신에 이러한 접근 방식을 채택하는 기업은 전략과 비즈니스 문화에서 데이터를 기반으로 하는 경우가 많습니다. 이러한 접근 방식을 개발하려면 리더가 데이터를 조직의 자산처럼 취급하고 조직이 더 나은 비즈니스 성과를 위해 데이터를 활용할 수 있도록 권한을 부여해야 합니다. AWS와 Amazon이 어떻게 데이터와 분석을 활용하여 확장 가능한 비즈니스 효율성을 창출하고 고객의 가장 복잡한 문제를 해결하는 메커니즘을 개발했는지 알아보십시오.
[Keynote] Accelerating Business Outcomes with AWS Data - 발표자: Saeed Gharadagh...Amazon Web Services Korea
데이터는 최종 소비자의 성공에 초점을 맞춘 디지털 혁신에서 중추적인 역할을 하고 있습니다. 모든 기업들은 데이터를 자산으로 사용하여 사례 제공을 추진하고 까다로운 결과를 해결하고 있습니다. AWS 클라우드 기술과 분석 솔루션의 강력한 성능을 통해 고객은 혁신 여정을 가속화할 수 있습니다. 이 세션에서는 기업 고객들이 클라우드에서 데이터의 힘을 활용하여 혁신 목표를 달성하고 필요한 결과를 제공하는 방법에 대해 다룹니다.
LG전자 - Amazon Aurora 및 RDS 블루/그린 배포를 이용한 데이터베이스 업그레이드 안정성 확보 - 발표자: 이은경 책임, L...Amazon Web Services Korea
LG ThinQ는 LG전자의 가전제품과 서비스를 아우르는 플랫폼 브랜드로서 앱 하나로 간편한 컨트롤, 똑똑한 케어, 스마트한 쇼핑까지 한번에 가능한 플랫폼입니다. ThinQ 플랫폼은 글로벌 서비스로 제공되고 있어, 작업 시간을 최소화하고, 서비스의 영향을 최소화 할 필요가 있었습니다. 따라서 DB 버전 업그레이드 작업 시 애플리케이션 배포가 필요없는 Blue/Green Deployment 방식은 최선의 선택이 되었습니다.
KB국민카드 - 클라우드 기반 분석 플랫폼 혁신 여정 - 발표자: 박창용 과장, 데이터전략본부, AI혁신부, KB카드│강병억, Soluti...Amazon Web Services Korea
온프레미스 분석 플랫폼에는 자원 증설 비용, 자원 관리 비용, 신규 자원 도입 및 환경 설정의 리드타임 등 다양한 측면에서의 한계가 존재합니다. 이에 KB국민카드에서는 기존 분석 플랫폼의 한계를 극복함과 동시에 시너지를 낼 수 있는 클라우드 기반 분석 플랫폼을 설계 및 도입하였습니다. 본 사례 소개는 KB국민카드의 데이터 혁신 여정과 노하우를 소개합니다.
SK Telecom - 망관리 프로젝트 TANGO의 오픈소스 데이터베이스 전환 여정 - 발표자 : 박승전, Project Manager, ...Amazon Web Services Korea
SK Telecom의 망관리 프로젝트인 TANGO에서는 오라클을 기반으로 시스템을 구축하여 운영해 왔습니다. 하지만 늘어나는 사용자와 데이터로 인해 유연하고 비용 효율적인 인프라가 필요하게 되었고, 이에 클라우드 도입을 검토 및 실행에 옮기게 되었습니다. TANGO 프로젝트의 클라우드 도입을 위한 검토부터 준비, 실행 및 이를 통해 얻게 된 교훈과 향후 계획에 대해 소개합니다.
코리안리 - 데이터 분석 플랫폼 구축 여정, 그 시작과 과제 - 발표자: 김석기 그룹장, 데이터비즈니스센터, 메가존클라우드 ::: AWS ...Amazon Web Services Korea
2022년 코리안리는 핵심업무시스템(기간계/정보계 시스템)을 AWS 클라우드로 전환하는 사업과 AWS 클라우드 기반에서 손익분석을 위한 어플리케이션 구축 사업을 동시에 진행하고 있었습니다. 이에 따라 클라우드 전환 이후 시스템 간 상호운용성과 호환성을갖춘 데이터 분석 플랫폼 또한 필요하게 되었습니다. 코리안리 IT 환경에 적합한 플랫폼 선정을 위하여 AWS Native Analytics Platform, 3rd Party Analytics Platform (클라우데라, 데이터브릭스)과의 PoC를 진행하고, 최종적으로 AWS Native Analytics Platform 으로 확정하였습니다. 코리안리는 메가존클라우드와 함께 2022년 10월부터 4개월(구축 3개월, 안정화 및 교육 1개월) 동안 AWS 기반 데이터 분석 플랫폼을 구축하고 활용 범위를 지속적으로 확대하고 있습니다.
LG 이노텍 - Amazon Redshift Serverless를 활용한 데이터 분석 플랫폼 혁신 과정 - 발표자: 유재상 선임, LG이노...Amazon Web Services Korea
LG 이노텍은 세계 시장을 선도하는 글로벌 소재·부품기업으로, Amazon Redshift 을 데이터 분석 플랫폼의 핵심 서비스로 활용하고 있습니다.지속적인 데이터 증가와 업무 확대에 따른 유연한 아키텍처 개선의 필요성에 대처하기 위해, 2022년에 AWS 에서 발표된 Redshift Serverless 를 활용한, 비용 최적화된 아키텍처 개선 과정의 실사례를 엿볼수 있는 기회가 됩니다.
[Keynote] Data Driven Organizations with AWS Data - 발표자: Agnes Panosian, Head...Amazon Web Services Korea
데이터는 모든 애플리케이션, 프로세스 및 비즈니스 의사 결정의 중심에 있습니다. 데이터는 거의 모든 조직의 디지털 트랜스포메이션의 초석입니다. 데이터는 새로운 경험을 촉진하고 혁신을 이끌어내는 통찰력으로 이어집니다. 전체 조직을 위한 데이터의 가치를 실현하는 전략을 구축하는 것은 쉽고 간단한 여정이 아닙니다. 이 세션에서는 데이터 기반 조직화를 위한 모범 사례와 그 여정에서 AWS가 어떻게 도움을 드릴 수 있는지를 다룹니다.
Amazon Neptune은 확장성과 가용성을 제공하도록 설계된 서버리스 데이터 그래프 데이터베이스입니다. 본 세션에서는 Neptune 서버리스를 통해 한의학 컨텐츠내용 및 상품 상세 데이터를 통해 그래프 DB를 구축하고 상품 추천 구현 사례를 살펴봅니다.
ECK(Elasticsearch Cloud on Kubernetes)는 쿠버네티스 환경에서 Elastic 제품을 배포하고 관리할 수 있는 오퍼레이터입니다. 본 세션에서는 Amazon EKS 환경에서 ECK를 사용한 검색 엔진 플랫폼 구축 사례 및 개발팀과 인프라팀 간 협업 과정을 공유합니다.
ChatGPT를 비롯한 거대 언어 모델(LLM) 기반 생성 AI를 통해 다양한 활용 사례가 나오고 있습니다. 본 세션에서는 생성 AI 모델의 임베딩벡터에 대해 알아보고 이를 통해 손쉽게 서버리스 텍스트 및 이미지 추천 검색을 구현하는 방법을 소개합니다. OpenAI의 GPT3 API 및 Amazon SageMaker JumpStart를 통해 올린 EleutherAI 모델 기반으로 한국어 추천 및 검색 애플리케이션을 구현한 사례를 살펴봅니다.
4. Amazon Aurora?
• 오픈 소스 호환 관계형 데이터베이스
• MySQL, PostgreSQL
• 상용 데이터베이스의 성능과 가용성 제공
• 오픈소스 데이터베이스의 비용 효율성과 간단함
5. 기존의 관계형 DBMS를 재구성
• SQL+TRANX를 스토리지와 분리:
로깅 및 스토리지를 스케일-아웃 가
능한 스토리지 서비스로 전환
• 서비스 내부에 Amazon EC2, VPC,
DynamoDB, SWF 및 Route 53 등
다른 AWS 서비스들 사용
• 연속적인 백업을 위한 Amazon S
3 와 통합으로 99.999999999% 내
구성 제공
Control PlaneData Plane
Amazon
DynamoDB
Amazon SWF
Amazon Route
53
Logging + Storage
SQL
Transactions
Caching
Amazon S3
1
2
3
6. 스케일 아웃 가능한 분산 스토리지
데이터베이스용으로 설계된 로그 구조
기반의 분산형 스토리지 시스템
3개의 가용영역에 걸친 수백개 이상의
스토리지 노드로 스트라이핑
총 6개의 복제본 유지 (각각의 가용 영
역에 2개의 복제)
Master Replica Replica Replica
Availability
Zone 1
Shared storage volume
Availability
Zone 2
Availability
Zone 3
Storage nodes with SSDs
SQL
Transactions
Caching
SQL
Transactions
Caching
SQL
Transactions
Caching
7. Aurora is used by:
2/3 of top 100 AWS customers
8 of top 10 gaming customers
Aurora 사용 고객
AWS 역사상 가장 빠르게 성장하는 서비스
8. 누가 왜 Aurora로 옮겨오는가?
기존의 상용 DBMS 사용 고객
기존의 MySQL 사용 고객
최대 5배 빠른 성능
최대 60%의 비용 절감
애플리케이션 변경 없이 쉽게 마이그레이션
라이선스 비용 없이 1/10의 운용 비용
클라우드와 유기적인 결합
고성능과 가용성
마이그레이션 도구와 서비스 지원
10. WRITE PERFORMANCE READ PERFORMANCE
MySQL SysBench results
R3.8XL: 32 cores / 244 GB RAM
RDS MySQL에 비해 5배의 성능
Based on industry standard benchmarks
0
25,000
50,000
75,000
100,000
125,000
150,000
0
100,000
200,000
300,000
400,000
500,000
600,000
700,000
Aurora MySQL 5.6 MySQL 5.7
11. Aurora의 확장성
With user connection With number of tables
With database size - SYSBENCH With database size - TPCC
Connections
Amazon Auro
ra
RDS MySQL
w/ 30K IOPS
50 40,000 10,000
500 71,000 21,000
5,000 110,000 13,000
Tables
Amazon Aur
ora
MySQL
I2.8XL
local SSD
RDS MySQL
w/ 30K IOPS
(single AZ)
10 60,000 18,000 25,000
100 66,000 19,000 23,000
1,000 64,000 7,000 8,000
10,000 54,000 4,000 5,000
8x
U P T O
F A S T E R
11x
U P T O
F A S T E R
DB Size
Amazon Auro
ra
RDS MySQL
w/ 30K IOPS
1GB 107,000 8,400
10GB 107,000 2,400
100GB 101,000 1,500
1TB 26,000 1,200
DB Size Amazon Aurora
RDS MySQL
w/ 30K IOPS
80GB 12,582 585
800GB 9,406 69
21x
U P T O
F A S T E R
136x
U P T O
F A S T E R
12. 실제 데이터 – 게임 워크로드
Aurora vs. RDS MySQL – r3.4XL
Aurora 3X faster on r3.4xlarge
13. BINLOG DATA DOUBLE-WRITELOG FRM FILES
T Y P E O F WR I T E
MYSQL WITH STANDBY
EBS 볼륨에 쓰기 수행 - EBS 는 미러에 쓰기 수행, 둘 다 종료
시 ACK
스탠바이 인스턴스에 쓰기 복제
IO FLOW
1, 3, 4 단계는 순차 및 동기
응답 속도 및 지터(Jitter) 가 증대
각 사용자 오퍼레이션을 위한 다양한 쓰기 작업들은 두 번
쓰기
OBSERVATIONS
780K 트랜잭션
1백만 TX 당 7,388K I/Os (미러 및 스탠바이 제외)
TX 당 평균 7.4 I/Os
PERFORMANCE
30분 SysBench 쓰기-전용 워크로드, 100 GB 데이터 셋, RDS SingleAZ, 30K PIOPS
EBS 미러EBS 미러
AZ 1 AZ 2
Amazon S3
EBS
Amazon Elastic
Block Store (EBS)
프라이머리
인스턴스
스탠바이
인스턴스
1
2
3
4
5
RDS MySQL I/O 트래픽
14. AZ 1 AZ 3
프라이머리
인스턴스
Amazon S3
AZ 2
복제
인스턴스
AMAZON AURORA
비동기
4/6 쿼럼
분산 쓰기
BINLOG DATA DOUBLE-WRITELOG FRM FILES
T Y P E O F WR I T E
30분 SysBench 쓰기-전용 워크로드, 100 GB 데이터 셋
IO FLOW
오직 Redo 로그 레코드만 쓰기, 모든 단계는 비동기화
데이터 블록 쓰기 없음 (체크포인트, 캐시 대체 등)
6X 로그 쓰기 향상, 9X 네트워크 트래픽 감소
네트워크 및 스토리지 응답속도 증가에 내구성
OBSERVATIONS
27,378K 트랜잭션 35X 향상
1백만 TX 당 950K I/Os (6X amplification) 7.7X 감소
PERFORMANCE
Redo 로그 레코드 전송 – LSN(Log Sequence Number)에
의해 전체 순서화
독립적인 캐시 프로세스에 업데이트
스토리지 노드에 전송 후 쓰기 수행
Aurora I/O 트래픽
15. LOG 레코드
프라이머리
인스턴스
INCOMING QUEUE
스토리지 노드
S3 백업
1
2
3
4
5
6
7
8
업데이트
큐
ACK
핫 로그
데이터
블록
POINT IN TIME
SNAPSHOT
GC
SCRUB
COALESCE
SORT
GROUP
PEER-TO-PEER GOSSIP동료
스토리지
노드
모든 단계는 비동기 수행
1단계 및 2단계만 응답속도에 영향 주는 경로
입력 큐는 MySQL 대비 46X 미만 (unamplified, per node)
응답속도-중심 오퍼레이션에 적합
디스크 공간을 스파이크에 대응하기 위한 버퍼로 사용
OBSERVATIONS
IO FLOW
① 로그 레코드 수신 후 인-메모리 큐에 추가
② 업데이트 큐에 로그 레코드 보존하고 바로 ACK 해줌
③ 레코드 구성(grouping) 및 로그의 간극 파악
④ 동료 스토리지 노드와 통신하여 간극 동기화
⑤ 로그 레코드를 신규 데이터 블록 버전으로 통합
⑥ 주기적으로 로그 및 신규 블록 버전을 S3로 전송
⑦ 주기적으로 기존 버전의 블록에 가비지 콜렉션 수행
⑧ 주기적으로 블록에 대한 CRC 검증
Aurora I/O 트래픽 – 스토리지 계층
16. 비동기 그룹 커밋
• TRADITIONAL APPROACH
Read
Write
Commit
Read
Read
T1
Commit (T1)
Commit (T2)
Commit (T3)
LSN 10
LSN 12
LSN 22
LSN 50
LSN 30
LSN 34
LSN 41
LSN 47
LSN 20
LSN 49
Commit (T4)
Commit (T5)
Commit (T6)
Commit (T7)
Commit (T8)
LSN GROWTH
Durable LSN at head node
COMMIT QUEUE
Pending commits in LSN order
TIME
GROUP
COMMIT
TRANSACTIONS
Read
Write
Commit
Read
Read
T1
Read
Write
Commit
Read
Read
Tn
AMAZON AURORA
디스크에 쓰기 위한 로그 레코드의 버퍼 관리
쓰기 작업을 위한 버퍼 풀(Full) 또는 타임아웃 발생 시 쓰기 작업
수행
쓰기 비율이 낮을 때 첫번째 쓰기에 응답속도 페널티
첫번째 쓰기에 I/O 요청.
개별 쓰기는 6개 스토리지 노드 중 4개 쓰기 ACK 시 처리
(내구성을 위한 쿼럼 구성)
비동기식 트랜잭션 처리로 성능 및 효율성 제공
17. Aurora I/O 트래픽 – 읽기 복제
• Logical: SQL 문을 복제에 적용
• 쓰기 부하는 양쪽 노드에서 유사
• 별도 스토리지
• 마스터 및 복제 사이에 데이터 차이 존재
페이지 캐시
업데이트
Aurora 마스터
30% 읽기
70% 쓰기
Aurora 복제
100% 신규 읽기
공유 Multi-AZ 스토리지
MySQL 마스터
30% 읽기
70% 쓰기
MySQL 복제
30% 신규 읽기
70% 쓰기
싱글-스레드
BINLOG 전송
데이터 볼륨 데이터 볼륨
Physical: 마스터에서 복제로 redo를 전송
복제는 스토리지를 공유
쓰기 수행 없음
캐시된 페이지는 Redo 적용
MYSQL READ SCALING AMAZON AURORA READ SCALING
18. • 다중 스레드풀과 멀티플렉싱을 통한 처리
• 커널 영역의 epoll() 통한 latch-free 이벤트 큐 입력
• 스레드 풀 크기 동적 조정
• 5000+ 동시 클라이언트 세션을 r3.8xl에서 처리
적응형 스레드풀
표준 MySQL— 접속 당 스레드
접속 수 증가에 확장되지 않음
MySQL EE — 접속은 스레드 그룹에 할당
스레드 블로킹 되는 경우에 효율 저하
CLIENTCONNECTION
CLIENTCONNECTION
LATCH FREE
TASK QUEUE
epoll()
MYSQL THREAD MODEL AURORA THREAD MODEL
19. Scan
Delete
Aurora 잠금(lock) 관리
SQL 레벨에서의 락 개념은 MySQL과 같음
내부적으로는 Lock-chain에 동시 접근 가능하도록 수정됨
각각의 Lock-chain 내에서도 다수의 읽기 가능
내부적으로 Lock-free 자료 구조 적극 활용을 통한 Deadlock 방지
Scan
Delete
Insert
Scan Scan
Insert
Delete
Scan
Insert
Insert
MySQL lock manager Aurora lock manager
많은 동시 세션들 지원을 위해 최적화 높은 업데이트 출력량(throughput)
20. Cached 데이터 읽기 성능 개선
• Catalog concurrency: 데이터 딕셔너리 동기
화와 캐시 퇴거(eviction)를 개선
• NUMA 인식 스케줄러: Aurora scheduler는 이
제 NUMA를 고려함. 멀티 소켓 인스턴스의 확
장성에 도움
• 읽기 뷰(Read views): 읽기 뷰 생성시 잠금 없
는 (latch-free) 동시성 읽기 알고리즘을 이용함
0
100
200
300
400
500
600
700
MySQL 5.6 MySQL 5.7 Aurora
2015
Aurora
2016
In thousands of read requests/sec
* R3.8xlarge instance, <1GB dataset using Sysbench
25% 출력량 증가
21. • Smart scheduler: Aurora 스케줄러가 스레드
를 처리할 때, I/O heavy 인가 CPU heavy 인가
에 따라 동적 할당
• Smart selector: Aurora는 카피된 스토리지 노
드중 가장 성능이 좋은 것을 자동 선택함으로
써 읽기 지연을 감소시킴
• 논리적 선행읽기(LRA): B트리 안에서 페이지
를 순서대로 메모리에 prefetch 함으로써 읽기
I/O를 줄임
Non-cached 데이터 읽기 성능 개선
0
20
40
60
80
100
120
MySQL 5.6 MySQL 5.7 Aurora
2015
Aurora
2016
In thousands of requests/sec
* R3.8xlarge instance, 1TB dataset using Sysbench
10% 출력량 증가
22. Primary Key 정렬로 배치 삽입 가속: 인덱
스 경유하지 않고 커서 포지션을 캐싱함으로써
동작
데이터 패턴에 따라 동적으로 스스로 기
능을 끄거나 켬
트리를 따라 내려가는 동안 Lock을 획득
하기 위한 경합을 피함
모든 INSERT 구문에서 작동
• LOAD INFILE
• INSERT INTO SELECT
• INSERT INTO REPLACE
• Multi-value 삽입시
배치 삽입(Insert) 성능 향상
Index
R4 R5R2 R3R0 R1 R6 R7 R8
Index
Root
Index
R4 R5R2 R3R0 R1 R6 R7 R8
Index
Root
MySQL: B-tree 루트로부터 시작 인서트 최종까지 경유
Aurora: 인덱스 경유를 피함
23. 더 빠른 인덱스 빌드
MySQL 5.6은 Linux의 선행읽기(read ahead)
적용: 이 방식은 결국 B트리내의 블록별
주소를 요구
Aurora는 B트리 안의 위치에 기반한 미리
가져온(prefetch) 블록을 스캔하며, 이는 블록
주소를 요구하지 않음
Aurora는 B트리의 Leaf 블록을 먼저 빌드하고
Branch를 빌드함
• 빌드중 트리 분할 없음
• 각각의 페이지는 한번씩만 터치
• 페이지당 하나의 로그 레코드
2-4X better than MySQL 5.6 or MySQL 5.7
0
2
4
6
8
10
12
r3.large on
10GB dataset
r3.8xlarge on
10GB dataset
r3.8xlarge on
100GB dataset
Hours
RDS MySQL 5.6 RDS MySQL 5.7 Aurora 2016
24. 공간 인덱스
• 공간 데이터 저장의 필요성
• 예: “병원으로부터 1KM내의 모든 사람을 찾아라"
• 공간 데이터는 다중 차원(multi-dimensional)
• B-Tree 인덱스는 단차원(one-dimensional)
• Aurora 공간 데이터 타입 지원 (point/polygon)
• GEOMETRY 데이터 타입 지원 (from MySQL 5.6)
• 원래 이런 타입의 공간 데이터는 인덱스 불가
• 두 가지 가능한 방법
• 공간 데이터를 위한 접근 방법 특화 (예: R-Tree)
• 다중 차원의 공간 데이터를 B-Tree 단차원 공간으로 맵핑할
수 있는 메커니즘 적용 (Z-index)
A
B
A A
A A
A A A
B
B
B
B
B
A COVERS B
COVEREDBY A
A CONTAINS B
INSIDE A
A TOUCH B
TOUCH A
A OVERLAPBDYINTERSECT B
OVERLAPBDYINTERSECT A
A OVERLAPBDYDISJOINT B
OVERLAPBDYDISJOINT A
A EQUAL B
EQUAL A
A DISJOINT B
DISJOINT A
A COVERS B
ON A
25. Aurora에서의 공간 인덱스
Z-index used in Aurora
R-Tree의 문제
• 잘 균형 잡혀있을 때 효율적
• 사각형이 중첩되거나 빈 공간을 덮으면 안됨
• 시간이 지남에 따라 악화
• 재 인덱싱 비용이 높음
R-Tree used in MySQL 5.7
Z-index (z-order-curve)
• 저장, 인덱싱에 기본적인 B-Tree 사용
• 공간을 차원적으로 순서화해서 곡선 형태로 표현
• 데이터 지역성(locality) 보존: 캐시 친화적
27. Full Table 복사: 인덱스 재구성 (수시간 이상 소요)
DML을 위한 임시 공간 필요
DDL은 DML 스루풋에 큰 영향을 줌
DML을 통한 변경시 테이블 단위의 잠금(lock) 걸림
메타데이터 테이블에 변경 항목을 기록을 통한 버저닝:
변경 사항을 차례대로 읽어와서 적용
Modify-On-Write 적용을 통한 실제 데이터 변경시에
스키마 적용
현재는 테이블 끝에 NULLable 컬럼 추가 지원
(곧) 다른 타입의 컬럼 추가 지원, 컬럼 드랍 및 순서 바
꿈, 데이터 타입 변경 지원
Index
LeafLeafLeaf Leaf
Index
Root
table name operation column-name time-stamp
Table 1
Table 2
Table 3
add-col
add-col
add-col
column-abc
column-qpr
column-xyz
t1
t2
t3
MySQL Amazon Aurora
Online DDL: Aurora vs MySQL
28. On r3.large
On r3.8xlarge
Aurora MySQL 5.6 MySQL 5.7
10GB table 0.27 sec 3,960 sec 1,600 sec
50GB table 0.25 sec 23,400 sec 5,040 sec
100GB table 0.26 sec 53,460 sec 9,720 sec
Aurora MySQL 5.6 MySQL 5.7
10GB table 0.06 sec 900 sec 1,080 sec
50GB table 0.08 sec 4,680 sec 5,040 sec
100GB table 0.15 sec 14,400 sec 9,720 sec
Online DDL 성능
https://aws.amazon.com/blogs/database/amazon-aurora-under-the-hood-fast-ddl/
30. 스토리지 자가 치유 및 장애 내구성
• 자동 장애 감지, 복제, 복구
• 2개의 복제 및 1개 가용 영역 장애는 읽기 및 쓰기 가용성에 영향 없음
• 3개의 복제 장애에도 읽기 가용성에 영향 없음
SQL
Transaction
AZ 1 AZ 2 AZ 3
Caching
SQL
Transaction
AZ 1 AZ 2 AZ 3
Caching
Read and write availabilityRead availability
31. Aurora의 스토리지 백업 및 복구
• 자동 백업(Automated Backup)
• RDS는 백업을 자동으로 생성
• 신규 DB 인스턴스에 자동으로 활성화
• 백업 보관 기간(Backup Retention Period)
동안 데이터 보관 (1~35일)
• 연속 및 증분 백업
• 백업 중 성능 영향 없음
• 스냅샷 (DB Snapshots)
• 사용자가 생성한 백업
• 원하는 주기로 백업
• 백업 보관 기간 이상 보관
• 어느 시점으로도 복구 가능
32. Aurora의 스토리지 백업 및 복구
• 복구 (Restore)
• 백업 또는 스냅샷으로부터 신규 Aurora D
B 클러스터 생성
• 백업 보관 주기 내 어느 시점으로든 복구
• Latest Restorable Time : 보통 5분 이내
• Earliest Restorable Time : 백업 보관 주기
• Aurora Backup은 연속, 증분 백업으로 복
구 시간 향상을 위해 빈번한 스냅샷 생성
을 할 필요 없음
33. Aurora의 인스턴스 자동 Fail-over
• 읽기 복제 있는 경우
• 기존 복제를 새 기본 인스턴스로 승격
• failover 대상 인스턴스 우선 순위 지정 가능
• DB 클러스터 엔드포인트 유지하며, 신규 기
본 인스턴스로 DNS 레코드 변경
• 일반적으로 1분 이내에 완료
AZ 1
Primary
instance
Replica
instance
Replica
instance
Replica
instance
Shared Multi-AZ Storage
Automatic
Failover to
Replica
Instance
AZ 1
Primary
instance
Primary
instance
Shared Multi-AZ Storage
Create new
primary
Instance
Aurora Replica가 있는 경우 Aurora Replica가 없는 경우
읽기 복제 없는 경우
• 동일 가용 영역에 새 DB 인스턴스 생성 시도
• 생성 불가 시 다른 가용 영역에 신규 DB
인스턴스 생성 시도
• 일반적으로 15분 이내에 완료
AZ 3AZ 2AZ 3AZ 2
Primary
instance
34. 신속한 크래시 복구
• 최종 체크포인트 이후 로그 재생 필요
• MySQL은 싱글-쓰레드 동작 및 다량의
디스크 억세스 필요
• 스토리지 수준에서 redo 레코드를 on-
demand로 재생
• 병렬, 분산, 비동기
• 기존 데이터베이스 • Amazon Aurora
Checkpointed Data Redo Log
Crash at T0 requires
a re-application of the
SQL in the redo log since
last checkpoint
T0 T0
Crash at T0 will result in redo
logs being applied to each segment
on demand, in parallel, asynchronously
35. 독립적인 캐시 유지
• 데이터베이스 프로세스와 캐시
의 분리
• 데이터베이스 재기동 이벤트 시
에도 캐시 웜(warm) 상태 유지
• 전체 캐시 활성화가 신속
• 즉각적인 크래시 복구 + 캐시 유
지 = 빠르고 손쉬운 DB 장애 복
구
SQL
Transactions
Caching
SQL
Transactions
Caching
SQL
Transactions
Caching
Caching process is outside the DB process
and remains warm across a database restart.
36. 보다 신속하고 예측 가능한 Fail-over
App
RunningFailure Detection DNS Propagation
Recovery Recovery
DB
Failure
MYSQL
App
Running
Failure Detection DNS Propagation
Recovery
DB
Failure
AURORA WITH MARIADB DRIVER
1 5 – 2 0 초
3 – 2 0 초
38. SQL로 장애 시뮬레이션 지원
• To cause the failure of a component at the database node:
ALTER SYSTEM CRASH [{INSTANCE | DISPATCHER | NODE}]
• To simulate the failure of disks:
ALTER SYSTEM SIMULATE percent_failure DISK failure_type IN
[DISK index | NODE index] FOR INTERVAL interval
• To simulate the failure of networking:
ALTER SYSTEM SIMULATE percent_failure NETWORK failure_type
[TO {ALL | read_replica | availability_zone}] FOR INTERVAL interval
41. 데이터 복사: 원본 테이블의 데이터를 대상 테이블로 복사
변경 데이터 증분 복사 (CDC): 원본 데이터의 변경 사항은 테이블이
복사되는 동안 따로 버퍼링. 테이블 복사가 완료되면 버퍼링 되어 있던 변경
데이터를 대상에 적용. 추가 변경 사항은 작업이 종료될때까지 계속 적용됨AWS Database
Migration Service
AWS Schema
Conversion Tool
Oracle, SQL Server로 부터의 마이그레이션
SCT 평가 보고서: 원본 데이터베이스를 분석하고 권장되는 대상 엔진 및
자동/수동 변환 정보를 제공
코드 브라우저 및 권장 엔진: 수동 편집이 필요한 곳을 강조 표시하고
아키텍처 및 디자인 지침을 제공
43. DMS를 통한 데이터 마이그레이션
Replication
Instance
Oracle /
SQL Server Aurora
Change logs
Data pages
스냅샷 전송, 라이브 복제, 부트스트랩
이후 라이브 복제 중에서 선택
기존 테이블을 덮어 쓰거나 추가할
것인지 선택
테이블 복제시 병렬 처리 정도 선택
(기본값은 8)
원본과 대상 사이에서의 테이블간 맵핑
생성
마이그레이션 시작후 진행 상황 관찰
• 복제 역할을 하는 인스턴스가 생성되어 데이터를 복제
• 인스턴스상의 각 프로세스는 하나의 전체 테이블을 로드
• 재시작시 중단된 곳부터 계속 됨
44. AWS 서비스 연동 기능 활용
Lambda
S3
IAM
CloudWatch
Aurora 스토어드 프로시저로 부터 Lambda 호출 가능
S3에 스냅샷 백업 및 복원 가능
DBMS 접근 제어에 IAM role 사용 가능
시스템 메트릭 및 감사 로그를 CloudWatch에 전송 가능
46. import logging
logger = logging.getLogger()
logger.setLevel(logging.INFO)
def lambda_handler(event, context):
logger.info('I am from Aurora')
return 'Hello World!'
47. mysql> use auroraworkshop;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with –A
mysql> DROP PROCEDURE IF EXISTS InvokeLambda;
Query OK, 0 rows affected, 1 warning (0.02 sec)
mysql> DELIMITER ;;
mysql> CREATE PROCEDURE InvokeLambda() LANGUAGE SQL
-> BEGIN CALL mysql.lambda_async('arn:aws:lambda:us-east-1:549632206553:function:func-aurora-test','');
-> END ;;
Query OK, 0 rows affected (0.01 sec)
mysql> DELIMITER ;
mysql> call InvokeLambda();
Query OK, 0 rows affected (0.10 sec)
mysql> call InvokeLambda();
Query OK, 0 rows affected (0.07 sec)
mysql> call InvokeLambda();
Query OK, 0 rows affected (0.07 sec)
48.
49. 고급 모니터링 활용
50+ 개 이상의 시스템/OS 메트릭 | 정렬된 process list 뷰 제공 | 1–60 초단위 측정값 제공
메트릭에 알람 설정 | CloudWatch Logs 연동 | 3rd-party 도구 연동 지원
ALARM
50. 읽기 복제본 활용
Master
Read
Replica
Read
Replica
Read
Replica
Shared distributed storage volume
Reader end-point
읽기 부하 분산을 통하여 애플리케이션 성능 향상 및
고가용성 제공
복제본은 일반적으로 몇 분 내에 생성, 삭제, 확장
할 수 있음
다수의 읽기 복제본에 대해 부하 분산되는 공용
엔드포인트 제공으로 애플리케이션 수정이
필요하지 않음
스토리지 노드 공유로 복제 지연 시간이 아주 낮음
(10ms 이내)
최대 15개까지의 (Failover로) 승격 가능한 읽기
복제본을 통한 고가용성 확보
51. 리전간 읽기 복제본 활용
• 리전 단위 재난시 타 리전의
복제본으로부터 빠른 복구
• 다른 지역의 고객에 데이터를
가까이 배치하여 최적화된 애
플리케이션 경험 제공
• 타 지역의 복제본을 마스터로
승격함으로써 마이그레이션
가능
52. 느린 쿼리 찾기: 로깅
파라미터 편집을 통해 느린 쿼리
로깅
• Slow_query_log : 로깅 활성화 여부
• Long_query_time : 느린 쿼리의
성능 기준
• Log_queries_not_using_indexes :
인덱스 미 사용 쿼리에 대한 로깅
여부
53. 인덱스를 활용 여부에 대한 판단
• EXPLAIN “쿼리”
• Select_type : DERIVED, UNCACHEABLE SUBQUERY, DEPENDENT SUBQUERY
• Type : ALL, index
• Key : 의도한 내용인지 확인
• Row : 결과에 비해 매우 큰 값이 아닌지 확인 Index 활용 여부 및 Key 값과 같이 확인
• Extra : Distinct, Using Index, Using index for group-by
주요 고려 사항
54. 쿼리 수행 최적화
• 인덱스 활용
• 조인 쿼리 힌트 제공
• ANALYZE TABLE ‘TABLE NAME’
• 대량의 데이터 변화 및 스키마 변경시 ANALYZE 자동 수행
55. 성능 모범 사례 정리
기존의 SQL레벨의 RDBMS 성능 향상 방식은 여전히 동일
가능한 동시접속 사용을 높임
Aurora 출력량은 커넥션 갯수에 따라 증가
읽기 확장을 적극 활용
리드 복제의 지연이 극히 낮음, 여러 읽기 분산으로 전체 성능 향상
파라미터 튜닝
기존의 모든 MySQL파라미터를 Aurora에 적용할 필요 없음
기본 Aurora 파라미터는 충분히 최적화
퍼포먼스 비교
개별 지표(CPU, IOPS, IO throughput)에 너무 의존하 말 것
어플리케이션 측에서의 실제 성능 확인
기타
CloudWatch 메트릭 참고
56. 비용 절감 사례: Aurora의 비용 체계
단순한 비용 모델
라이선스 없음
최소 요금 없음
• 사용한 부분에 대해서만 비용 지불
예약 인스턴스 요금
• 1년 예약인스턴스 시 최대 44%
• 3년 예약인스턴스 시 최대 63%
인스턴스 vCPU 메모리 시간당 요금
db.r3.large 2 15.25 $0.29
db.r3.xlarge 4 30.5 $0.58
db.r3.2xlarge 8 61 $1.16
db.r3.4xlarge 16 122 $2.32
db.r3.8xlarge 32 244 $4.64
스토리지 요금 $0.100 월별 GB당
I/O 요금 $0.200 요청 100만 건당
* Virginia 지역 기준
57. 소유 비용: Aurora vs. MySQL
MySQL 구성 시간 당 비용
프라이머리
r3.8xl
스탠바이
r3.8xl
복제
r3.8xl
복제
r3.8xl
스토리지
6TB/10K PIOPS
스토리지
6TB/10K PIOPS
스토리지
6TB/5K PIOPS
스토리지
6TB/5K PIOPS
$3.78/hr
$3.78/hr
$3.78/hr $3.78/hr
$2,42/hr
$2,42/hr $2,42/hr
인스턴스 비용 : $15.12 / hr
스토리지 비용 : $8.30 / hr
총 비용 : $23.42 / hr
$2,42/hr
58. 소유 비용: Aurora vs. MySQL
Aurora 구성 시간 당 비용
프라이머리
r3.8xl
복제
r3.8xl
복제
r3.8xl
스토리지 / 6 TB
$4.64 / hr $4.64 / hr $4.64 / hr
$4.43 / hr
21.6%
Savings
대기 중인 스탠바이 인스턴스 없음
단일 공유 볼륨
PIOPS 없음 – I/O 사용량 만큼 지불
전반적인 IOPS 비용 감소
인스턴스 비용 : $13.92 / hr
스토리지 비용 : $4.43 / hr
총 비용 : $18.35 / hr
59. Aurora 구성을 통한 추가 비용 절감
프라이머리
r3.8xl
r3.4xl
복제
r3.8xl
r3.4xl
복제
r3.8xl
r3.4xl
스토리지 / 6 TB
$2.32 / hr $2.32 / hr $2.32 / hr
$4.43 / hr
51.3%
Savings
더 작은 인스턴스 사용 가능
Pay-as-you-go 스토리지
인스턴스 비용 : $6.96 / hr
스토리지 비용 : $4.43 / hr
총 비용 : $11.39 / hr
60. MariaDB server audit plugin Aurora native audit support
• We can sustain over 500K events/sec
Create event string
DDL
DML
Query
DCL
Connect
Write
to File
DDL
DML
Query
DCL
Connect
Create event string
Create event string
Create event string
Create event string
Create event string
Latch-free
queue
Write to File
Write to File
Write to File
MySQL 5.7 Aurora
Audit Off 95K 615K 6.47x
Audit On 33K 525K 15.9x
Sysbench Select-only Workload on 8xlarge Instance
Aurora 고급 감사 기능
62. Oracle과 가장 호환성이 높은 오픈 소스 데이터베이스
20 년간 활발히 개발 중
혁신 친화적인 오픈소스 라이센스
회사가 아니라 재단에 의해 소유됨
높은 성능
객체 지향과 ANSI-SQL:2008 호환
오픈 소스중에서 가장 뛰어난 공간정보 기능 보유
12가지 언어로 스토어드 프로시저 지원
Java, Perl, Python, Ruby, Tcl, C/C++, PL/pgSQL 등
AWS Schema Conversion Tool을 사용해서 Oracle로 부터
PostgreSQL 전환에 있어서 가장 높은 자동 전환률
PostgreSQL 개요
Open Source Initiative
63. PostgreSQL vs. Oracle
Property PostgreSQL Oracle
Schema & Pre-defined Data Types Yes Yes
Secondary Indexes Yes Yes
SQL Yes Yes
API Framework C, ADO.NET, JDBC, ODBC ODP.NET, Oracle Call Interface (OCI),
JDBC, and ODBC
Triggers Yes Yes
Partitioning Can be achieved using extensions Yes
Replication Master-Slave Master-Slave and Master-Master
MapReduce APIs No No
Foreign Keys Yes Yes
Transactions ACID ACID
In-Memory No Yes
XML Support No Yes
Reporting Reporting Available Yes
Spatial PostGIS Yes
64. PostgreSQL vs. SQL Server
Property PostgreSQL SQL Server
Schema & Pre-defined Data Types Yes Yes
Secondary Indexes Yes Yes
SQL Yes Yes
API Framework C, ADO.NET, JDBC, ODBC OLE DB, Tabular Data Stream (TDS), ADO.
NET, JDBC, ODBC
Triggers Yes Yes
Partitioning Can be achieved using extensions Yes
Replication Master-Slave Master-Slave
MapReduce APIs No No
Foreign Keys Yes Yes
Transactions ACID ACID
In-Memory No Yes
XML Support No Yes
Reporting Reporting Available Yes
Spatial PostGIS Yes
65. • PostgreSQL
성능 측정을 위한 시스템 구성
• Amazon Aurora
AZ 1
EBS EBS EBS
45,000 total IOPS
AZ 1 AZ 2 AZ 3
Amazon S3
m4.16xlarge
database
instance
Storage
Node
Storage
Node
Storage
Node
Storage
Node
Storage
Node
Storage
Node
c4.8xlarge
client
driver
m4.16xlarge
database
instance
c4.8xlarge
client
driver
ext4 filesystem
m4.16xlarge (64 VCPU, 256GiB), c4.8xlarge (36 VCPU, 60GiB)
69. 더 빠른 응답 시간
SysBench oltp(write-only) 23GiB workload with 250 tables and 300,000 initial rows per table. 10-minute warmup.
70. 더욱 일관성있는 출력(Throughput)
PgBench “tpcb-like” workload at scale 2000. Amazon Aurora was run with 1280 clients. PostgreSQL was run with
512 clients (the concurrency at which it delivered the best overall throughput)
71. 데이터 용량이 증가할수록 더 빠름
SysBench oltp(write-only) – 10GiB with 250 tables & 150,000 rows and 100GiB with 250 tables & 1,500,000 rows
75,666
27,491
112,390
82,714
0
20,000
40,000
60,000
80,000
100,000
120,000
10GB 100GB
writes/sec
SysBench Test Size
SysBench write-only
PostgreSQL Amazon Aurora
72. 더 빠른 크래시 리커버리
SysBench oltp(write-only) 10GiB workload with 250 tables & 150,000 rows
즉각 복원이 가능한 트랜잭션 기반의 스토리지 시스템!
74. 직접 사용해보기
• Amazon Aurora for PostgreSQL 업데이트
• https://aws.amazon.com/ko/blogs/korea/amazon-aurora-update-p
ostgresql-compatibility/
• 테스트를 위한 프리뷰 신청
• https://pages.awscloud.com/amazon-aurora-with-postgresql-comp
atibility-preview-form.html
77. Samsung Members
Schema Migration 사례
Community DB Schema Migration
배경
- Community 버전 Upgrade 에 따른 대규모 Schema 변경.
목표
- 별도 스크립트 작성 없이 SQL Query 만으로 Migration.
- Migration 작업이 서비스에 영향을 주지 않아야 함.
- 모든 사용자의 클라이언트가 업데이트 완료 될 때 까지 두 버전 모두 동작 해야 함.
결과
- 서비스 중단 및 지연 없이 대규모 Schema 변경이 포함된 Version Upgrade 작업 진행.
78. Samsung Members
Schema Migration 사례
Community DB Schema Migration
V 1.0
V 1.0(Replication) +
V 2.0 (Master)
V 1.0
V 2.0
V 1.0 API
V 2.0 API
V1.0 WA
S
V2.0 WA
S
Replication 증분 Migration
Batch
전체 Migration
1.0 -> 2.0
79. Samsung Members
Schema Migration 사례
적용 방법
1. Binlog 보관 기간 설정 (7일)
> CALL mysql.rds_set_configuration ('binlog retention hours', 168);
2. Master Cluster에 복제 사용자 생성.
> CREATE USER ‘repl_user’@’%’ IDENTIFIED BY ‘yourpassword’;
> GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO ‘repl_user’@’%’ IDENTIFIED BY
‘yourpassword’;
3. Master의 Binlog file 및 position 확인 (메모)
> SHOW MASTER STATUS;
TIP. 특히 Binlog File 명은 향우 Slave 에서 Replication 활성화 할 때 사용
4. Master의 Snapshot으로 부터 신규 Instance 생성
80. Samsung Members
Schema Migration 사례
적용 방법 (계속)
5. Slave Cluster에서 복제를 시작할 Binlog 파일 및 position 확인.
> SHOW MASTER STAUTS;
TIP. SHOW MASTER STAUTS 의 결과에 Master Instance에서 메모한 파일 명이 보이지 않으면
> SHOW BINARY LOGS;
6. Slave Cluster에서 복제 활성화
> CALL mysql.rds_set_external_master
('your master end-point', 3306, 'repl_user', '‘yourpassword’', 'mysql-bin-changelog.000036', 110382596, 0);
> CALL mysql.rds_start_replication;
7. 복제 모니터링
> SHOW SLAVE STATUS;
Second_Behind_Master = 0
8. New (2.0) Schema 생성
TIP. 증분 Migration 되는 데이터와, 2.0으로 바로 Insert 되는 데이터의 Key 중복을 피하기 위해
PK (Auto increment) 시작 값을 1.0 대비 충분히 크게 하면 좋음.
9. 1.0 -> 2.0 Migration 수행
81. Samsung Members
Region 이전 사례
Aurora Region 이전
배경
- Members 전체 인프라의 Region 이동.
목표.
- DB 이전 도중 예외 상황 발생 가능성 최소화.
- DB 이전에 걸리는 시간 최소화로 서비스 중단 시간 단축.
- 가능한 부분은 최대한 사전에 작업.
방법.
- Aurora Cross Region Replica 활용.
Region A Region B
Region C
82. Samsung Members
Region 이전 사례
Aurora Region 이전
방법
- Cross Region Replica 생성
(Region 이동 작업 이전에 미리 생성.)
- 트래픽 차단
- 차단 확인 후 Replica를 Master로 승격
- Route53에서 DNS 변경
결과
- DB Region 이전에 걸린 시간 10분 이내.
(Replica의 Master 승격 시간)
- 간단한 방법으로 모든 준비를 사전에.
- 실제 이전 작업시점엔 클릭 몇 번으로 작업 완료 From Region To Region