greg.ss 클라우드에 관심 있지만 시간이 없어 AWS re:Invent 2024를 살펴보지 못하셨나요? 그렇다면 직접 미국까지 다녀온 제이코와 아리가 보고 듣고 정리한 이 글을 추천드려요!shine.by 클라우드 컴퓨팅에 관심 있는 누구나 놓칠 수 없는 AWS re:Invent 2024의 최신 기술들을 쉽고 명확하게 접할 수 있는 글입니다. 앞으로의 개발 방향성에 대한 영감을 얻고 싶다면, 이 글을 통해 최신 기술 트렌드를 확인해 보세요!안녕하세요. 카카오페이 크레딧클랜에서 대출 플랫폼을 개발하는 제이코, 마케팅테크팀에서 프로모션 플랫폼을 개발하는 아리입니다. 저희는 카카오페이 기술 직군을 대표하여, 2024년 12월 2일부터 6일까지 미국 라스베이거스에서 열린 AWS re:Invent 2024에 다녀왔습니다.이번 행사에서는 생성형 AI 서비스인 Amazon Q, 맞춤형 AI 모델 구축을 지원하는 Amazon Bedrock, 분산형 데이터베이스인 Amazon Aurora DSQL, 대규모 데이터 분석을 위한 Amazon S3 Tables 등 다양한 기술이 소개되었습니다. 이 중에서, 제이코는 Amazon Aurora DSQL을 다룹니다. Amazon Aurora DSQL은 Multi-Region 및 Active-Active 기능을 지원하며 무제한 확장성과 높은 가용성을 제공하는 서버리스 분산형 SQL 데이터베이스입니다. 아리는 Amazon S3 Tables를 다룹니다. Amazon S3 Tables는 테이블 버킷을 이용한 새로운 데이터 관리 솔루션으로, 표 형식 데이터에 최적화된 Apache Iceberg 기반의 완전 관리형 테이블 형식 스토리지를 제공합니다.AWS re:Invent는 매년 클라우드 기술의 최신 트렌드를 한눈에 살펴볼 수 있는 중요한 행사입니다. 이번 글에서는 특히 Amazon Aurora DSQL과 Amaon S3 Tables와 같은 혁신적인 데이터베이스 기술을 다루는 만큼, 데이터베이스 관리와 데이터 분석에 관심 있는 분들에게 유익한 정보가 되길 바랍니다. 먼저, Amazon Aurora DSQL에 대해 살펴보겠습니다.안녕하세요, 카카오페이 크레딧클랜의 제이코입니다. 이번 AWS re:Invent 2024에서는 Amazon Aurora DSQL이 새롭게 소개되었습니다. Amazon Aurora DSQL은 사실상 무제한의 확장성과 높은 가용성을 제공하며 인프라 관리가 필요 없는 서버리스 분산 SQL 데이터베이스입니다. 이제부터, Amazon Aurora DSQL이 등장한 배경과 핵심 특징, 구성 요소 및 활용 방법에 대해 자세히 살펴보겠습니다.Amazon Aurora DSQL의 주요 특징을 살펴보기 전에, 먼저 이 기술이 등장하게 된 배경부터 살펴보겠습니다.AWS는 2014년에 Amazon Aurora를 출시했습니다. Amazon Aurora는 MySQL 및 PostgreSQL과 완벽하게 호환되면서 MySQL보다 5배, PostgreSQL보다 3배 높은 처리량을 제공합니다. 또한, 기존 상용 데이터베이스 대비 1/1

안녕하세요, SRE팀에 DBA로 새로 합류한 브라우니입니다.AWS Service에 여러 서비스가 있지만 그 중에서도 여러 서비스에 활용할 수 있는 주제를 다뤄보고자 합니다. 그래서 선택한 주제는 AWS에서 제공하는 Aurora Serverless v2입니다. Aurora Serverless v2는 Aurora MySQL 호환 버전 및 PostgreSQL 호환 버전에 사용할 수 있습니다. 본 포스팅에서는 명칭의 혼선을 없애기 위해 Aurora Serverless(Aurora Serverless Mysql v2)와 Aurora MySQL(기존 Aurora MySQL)로 지칭하겠습니다. Aurora Serverless 에 대한 간략한 소개와 더불어 Aurora MySQL과 대조를 해 보고, 그 중 주목할만한 점에 대해 성능 위주로 공유하고자 합니다.참조 : Aurora Serverless v2 사용하기 — Amazon AuroraAmazon AuroraAurora Serverless의 개요 및 주요 특징Aurora Serverless란?Aurora Serverless는 Aurora MySQL에 대한 온디맨드 방식의 자동 크기 구성을 할 수 있게 해주는 AWS 서비스입니다. 기존에는 Aurora MySQL을 관리하려면 새로운 부하 상황을 미리 예상하여 증설해야만 했었습니다. 하지만, Aurora Serverless 는 애플리케이션 요구 사항에 따라 데이터베이스가 자동으로 확장/축소됩니다. 또한, 사용하지 않는 리소스에 대해서는 요금을 지불하지 않고 Aurora의 고가용성, 확장성을 그대로 활용할 수 있으며, 빠른 속도로 이용할 수 있습니다. 즉, 트래픽을 예측할 수 없을 때 적절한 구성으로 볼 수 있습니다Aurora Serverless는 v1, v2로 버전이 나뉘어져 있습니다. 그리고 Aurora MySQL은 v1,v2,v3가 있는데, 현재는 Aurora MySQL v3에서 Aurora Serverless v1 사용은 불가합니다.참조 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV1.html#Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV1.amyAurora Serverless에선 ACU(Aurora Capacity Unit)라는 단위를 이용하여 Resource를 정하게 됩니다. 0.5 ~ 128 ACU까지 범위를 정할 수 있으며 최소단위 ACU로 초당 과금됩니다. 1 ACU= 대략 적으로 2GB Memory + CPU + Network 의 조합으로 이루어집니다. ACU는 ServerlessDatabaseCapacity와 ACUUtilization, 두 가지 지표를 통해 손쉽게 확인할 수 있습니다.참조 : Aurora Serverless v2의 성능 및 크기 조정 — Amazon AuroraScale Up / Down에 따라

자동화를 생활화합시다. — Online DDL 테스트 자동화 이야기안녕하세요, 여기어때컴퍼니 SRE팀 인턴 제이드입니다.오늘은 제가 여기어때컴퍼니에 인턴으로 합류하게 된 이후에 진행했던 주요 프로젝트 중 하나인 ‘온라인 DDL 테스트 자동화 프로젝트’에 대해 이야기하려고 합니다.본격적으로 프로젝트를 소개하기에 앞서, 온라인 DDL이라는 개념이 익숙하지 않으신 분들을 위해 간단히 개념부터 설명드리겠습니다.출처: Chat GPT 제작 이미지온라인 DDL이란?온라인 DDL(Online Data Definition Language)은 데이터베이스의 테이블 구조를 변경하거나, 인덱스를 추가하거나 삭제하거나, 컬럼을 수정하는 작업을 서비스 중단 없이 수행할 수 있는 방식입니다. 이러한 기능은 24시간 운영되는 서비스에서 데이터베이스 작업으로 인한 다운 타임을 방지하기 위해 필수적입니다. 참고로 저희가 사용하는 Amazon Aurora MySQL에서는 온라인 DDL이 기본적으로 활성화되어 있어, 스키마 변경 작업 시 적절한 알고리즘을 자동으로 선택해줍니다.온라인 DDL 작업을 실행하기 위해서는 작업 방식에 따라 Instant, Inplace, Copy라는 세 가지 알고리즘 중 하나가 사용됩니다. 이 알고리즘들은 각각 작업 시간과 데이터베이스 리소스 소모 측면에서 차이를 보이며, 작업 성격에 따라 적합한 방식이 선택됩니다.Instant 알고리즘은 테이블의 메타데이터만 수정하여 작업을 완료하는 방식입니다. 데이터 자체에는 전혀 영향을 주지 않기 때문에 가장 빠르고 리소스를 거의 사용하지 않습니다. 메타데이터는 테이블의 구조나 속성을 정의하는 정보로, 테이블 이름, 열의 정보, 기본값 등이 포함됩니다. 예를 들어, 테이블에 새로운 열(column)을 추가하거나 열의 기본값을 변경하는 작업이 Instant 알고리즘으로 처리됩니다. 데이터 복사가 없기 때문에 테이블 락이 발생하지 않으며, 서비스에 미치는 영향도 없습니다.Inplace 알고리즘은 기존 데이터를 복사하지 않고, 데이터를 유지한 상태에서 작업을 수행합니다. 예를 들어, 테이블에 새로운 열을 추가하되 기존 데이터에 기본값을 적용하거나 열의 데이터 타입을 변경하지 않는 작업이 해당됩니다. 데이터 복사가 없기 때문에 Copy 알고리즘보다 리소스를 적게 사용하며, 작업 도중 일부 락이 발생할 수 있지만 테이블 전체가 잠기지는 않아 서비스에 미치는 영향이 최소화됩니다. Inplace 알고리즘은 작업 성능과 안정성을 동시에 고려해야 하는 경우에 적합한 방식입니다.Copy 알고리즘은 원본 데이터를 새로운 테이블로 복사한 후, 변경 사항을 적용하는 방식으로 동작합니다. 작업 완료 후 기존 테이블은 삭제되고 새로 복사된 테이블이 원본 테이블을 대체하게 됩니다. 이 과정은 데이터의 양에 따라 시간이 오래 걸리고, 스토리지와 I/O 리소스를 많이 사용하게 됩니다. 특히, 대량의 데이터나 트래픽이 많은 환경에서는 성능 저하가 발생할 수 있으므로 신중하게 사용해야 합니다. Copy 알고리즘은 데이터 구조와 내용에 모두

Aurora/RDS 전문가의 GCP Cloud SQL 이전기우당탕탕 Cloud DB 이전기새로운 도약을 위한 모험은 항상 과제와 함께합니다. 저에게 Aurora MySQL/RDS for MySQL 전문가로서의 경험이 GCP라는 새로운 cloud platform 운영에 대한 도전으로 다시 다가왔습니다. 이번 글에서는 public cloud 간의 이전 과정을 우당탕탕 Cloud DB 이전기 로 공유하여 public cloud 간 이전 혹은 on-premise와 public cloud 간 이전을 고민하는 개발자들에게 조금이나마 도움을 주고자 합니다.1. 목표AWS에서 GCP로의 크게 4가지 주요 DB 작업을 목표로 가지고 진행하게 했습니다.Aurora MySQL/RDS for MySQL/DynamoDB GCP Cloud SQL for MySQL 이전{1 DB : n Application} Architecture {1 DB: 1 Application} Architecture전환(DEV 환경)service 안정성 향상과 Cost 절감을 위한 query, schema 및 index 최적화MySQL version upgrade이 모든 작업은 service downtime(10분 이내) 및 이전 비용 최소화라는 기본 목표 위에 설정했습니다. 실제로는 2분 내외의 service downtime이 예상되었으나 초보 GCP 운영을 생각하여 속도 조절을 위한 buffer 시간을 추가했습니다.특히 3번의 경우는 AWS에 선 적용 후 migration을 할 것인지 아니면 migration target(GCP)에만 적용할 것인지를 두고, 내부 논의를 하였고, 큰 작업에 대한 Aurora MySQL/RDS for MySQL의 temporary disk size 이슈와 현재의 query 를 검토하고 query, index 및 schema 변경에도 문제가 발생하지 않을 것이라는 자신감(?) 으로 후자를 선택하여 진행했습니다. 이 부분은 개발사마다의 환경(query 형태, DB spec, DB 구성 등)이 다를 수 있어 각 회사에 맞게 판단하시면 좋겠습니다.2. 사전 검토우리의 궁극적인 목표는 service downtime 및 이전 비용을 최소화하고, 이전 후에 장애가 없도록 하는 것이었습니다. 여기에, instance spec을 down scale하고, 개발자들의 투입 리소스를 최소화하는 것도 필요했습니다. 이를 위해 크게 5가지의 내용으로 검토했습니다.검토 전에 먼저 DB의 현재 상황을 파악하기 위해 제일 먼저 DB 실시간 모니터링 환경(grafana+victoriaMetrics+mysql/rds exporter)을 구축한 후, 아래의 검토 사항을 진행했습니다.Step 1: 실행 query검토service 실행 query를 분석하기 위해 general.log 를 이용해 실행 query를 추출하고 pt-query-digest 등등의 query generator를 통해 실행 query및 query 수행량 등을 파악합니다.Step 2: schema 및 DB parameter 검토주요 parameter 설정의 미설정 또는 오설정 여부 판단 및 schema type의 과설정 또는 오설정 판단 등등의 부하를 감소 시킬 수 있는 요소를 파악합니다.Step 3: replica 구축 소요 시간 검토6일 이내에 replication 구축이 완료되고 sync가 시작되어야 한다는 전제 조건을 만족해야 합니다.사용 비용이 발생하는 solution(GCP Cloud Datastream / AWS DMS)을 사용하지 않기 위해 검토해야 합니다.mysql export 시간 측정dump file 전송시간 측정mysql import 시간 측정Sync complete 시간 측정Step 4: version 차이에 따른 영향 검토Aurora MySQL 2.x는 MySQL 5.7.x 기반이기 때문에 MySQL 8.0.2x 와의 parameter및 optimizer 차이에 따른 영향도를 검토해야 합니다.Step 5: 사용 DB 종류의 단일화Aurora MySQL/RDS for MySQL/DynamoDB Cloud SQL for MySQL3. 검토 결과Step 1: 실행 query검토 결과query 실행량이 너무 많음. 예를 들어 SELECT 1 과 같은 query는 단일 query로는 부하가 되지 않으나, 모이면 부하가 됩니다. 또, join은 부하가 크다라는 오해가 있어 join을 사용하지 않고 각각 실행하는 경우 오히려 더 부하가 됩니다.single index가 많음. 이로 인해 scan량이 많고, 정렬이 늘어나게 됩니다.e.g)SELECT * FROM my_item WHERE user_id='test' AND expired_time > now() ORDER BY expired_time;의 index가ALTER TABLE my_item ADD KEY ix_userid_expiredtime(user_id, expired_time);가 아닌ALTER TABLE my_item ADD KEY ix_userid(user_id);ALTER TABLE my_item ADD KEY ix_expiredtime(expired_time);로 생성되어 있다.특히 admin site의 filter 조건 대응을 위해 column별 data 분포도와는 상관없이 모든 filter 항목별로 각각 single index를 생성한 경우도 있어 이 부분에 대한 검토가 필요했습니다.3. or query가 많음. 아래 예제 query에서는 expired_time에 대해 NULL 대신 default값(ex.9999 12 31)을 주어지면 or를 제거할 수 있습니다. 제거하지 않는다면 optimizer에 따라 expired_time index를 활용할 수 없게 됩니다.e.g)SELECT * FROM my_item WHERE id = 1 AND (expired_time > now() OR expired_time IS NULL); 4. order by single-index-column desc limit xx query로 인한 오동작 수행 query가 다수 존재함.(MySQL O