WATCHA에서 서로 다른 클라우드 저장소 간의 데이터 마이그레이션 시스템을 구축한 경험을 소개합니다. #Kubernetes #ArgoWorkflows안녕하세요, WATCHA Server Platform 팀에서 플랫폼 엔지니어로 일하고 있는 루카입니다.WATCHA에서 모은 데이터를 효율적으로 분석하고 활용하기 위해 기존 데이터 마이그레이션 프로세스를 개선해 새로 구축한 경험, 그중에서도 AWS DynamoDB의 데이터 마이그레이션 사례를 중심으로 소개해 보려 합니다.WATCHA에서는 다양한 데이터가 매일 생성되고 업데이트됩니다. 이들은 용도에 따라 RDB나 NoSQL 등, 데이터 성질에 맞는 데이터베이스에 저장되지만, 다양한 의사결정을 지원하기 위해서는 서로 다른 성질의 데이터들을 통합하여 분석할 필요가 있습니다. WATCHA는 Google Cloud의 강력한 데이터 분석 도구인 BigQuery를 데이터 웨어하우스로 활용하고 있습니다.데이터 통합을 위해서는 매일 업데이트되는 데이터를 BigQuery에 동기화하는 과정이 필요합니다. 이 과정은 자동화되고 안정적이어야 하며, 새로운 데이터 형태가 추가될 때 쉽게 통합할 수 있어야 합니다. 또, WATCHA의 경우 대부분의 데이터가 Google Cloud 대신 AWS에 저장되고 있기 때문에, 멀티 클라우드 환경에 대한 고려도 필요합니다. 마지막으로, 위 조건들이 충족되는 한에서 비용 효율성을 최적화해야 합니다. 기존의 데이터 마이그레이션 프로세스는 이러한 요구사항들을 온전히 충족하지 못하고 있었습니다.데이터 마이그레이션 작업은 여러 팀의 리소스가 연계되는 작업입니다. 크게 보면 각 데이터를 소유한 담당 서버 팀, 데이터를 전달하는 인프라 팀, 그리고 데이터를 사용하는 분석 팀이 있겠습니다. 기존 파이프라인은 각 팀이 오너십을 가진 영역에서 각자 작업을 수행하는 협업의 형태로 설계되어 있었습니다. 이러한 오너십의 분산은 언뜻 보기엔 크게 문제가 없게 느껴졌지만, 운영 시스템의 미성숙과 겹치자 몇 가지 문제를 야기했습니다.기존 파이프라인. 각 팀마다 작업이 할당되어 각자 순차적으로 처리합니다.대표적인 문제는 Cascading failure였습니다. 기존 프로세스에서는 팀 간 작업 완료 이벤트를 제대로 체크하지 않고 있어, 한 작업이 실패할 경우 이후 단계 작업이 모두 실패하는 상황이 발생했습니다. 이로 인해 각 팀이 운영하는 모니터링 시스템에서 중복된 실패 알림이 발생해 혼란이 생겼고, 알림이 왔는데 막상 다른 팀의 실패에서 비롯된 경우가 발생하면서 알림의 신뢰도 역시 감소하였습니다.또 다른 문제는 지속적인 운영 부하였습니다. 데이터 마이그레이션 작업은 새로운 데이터가 통합에 추가되거나, 데이터의 스키마가 변할 때 지속적으로 관리가 필요한데요, 각 팀에서 각자 관리하는 데이터가 생기면서, 작은 스키마 변경에도 여러 팀에서 각자 설정 파일을 수정하고, 다른 팀 간에 타이밍을 맞춰 변경 사항을 적용하는 등의 번거로운 처리가 필요했습니다.문제점 2. 비용 비효율성마이그레이션에 활용되는 데이터 형태에도

안녕하세요. SpoonRadio Buisiness Platform 팀에서 Billing 도메인 관련 백엔드 업무를 담당하고 있는 Eunice(손 윤)입니다. AWS Summit Seoul 2024에 참석할 수 있는 기회가 주어졌습니다.AWS Summit에 처음 참여라 설레는 마음으로 참가하게되었습니다. 참가 등록 데스크를 거쳐서 기조연설을 시작으로, 미리 들으려고 표시해 두었던 강연을 들으러 바쁘게 움직였습니다.가장 인상깊었던 강연은 채널톡 스타트업 기술 성장기: RDBMS에서 NoSQL로의 전환 이었습니다. 해당 강연의 내용을 소개해 드리고자 합니다.RDBS에서 NoSQL로의 마이그레이션을 하게 된 동기와 원인DynamoDB와 SQS의 장점과 활용 방안배경 설명채널코퍼레이션는 서비스 성장에 따라 트래픽 증가는 필연적으로 예전보다 더 많은 트래픽을 유발할 거라고 판단하였습니다. 간단한 대응 방법으로 RDS인스턴스 타입 스케일업(Scale-up)을 생각하였으나, 결과적으로 NoSQL을 도입하기로 합니다. 그에 따라, 아래 네 가지의 문제 해결이 필요했습니다.오버 프로비저닝으로 인한 비용 비효율 문제: 스파이크 트래픽의 피크(peak) 트래픽에 맞춰 RDS 인스턴스 사이즈를 선택해야 하기 때문에 비용 비효율이 예측됨.테이블 간 부하 전파 문제: 특정 테이블들의 부하가 RDS 인스턴스 전체에 영향을 끼쳐 전체 서비스에 장애를 우려함.NoSQL로의 오퍼레이션 대체 가능 여부: 특히 여러 채팅 방의 안 읽은 메시지 개수 합을 구하는 문제와 같은 특수한 작업.PostgreSQL에서 DynamoDB로의 데이터 마이그레이션 전략.DynamoDB를 선택한 이유위의 네 가지 문제 해결과 동시에 다음 세 가지 주요 이유로 DynamoDB를 선택했습니다.이벤트 소싱: 데이터베이스의 변경 사항을 쉽게 다른 서비스로 이벤트 소싱할 수 있어야 함.AWS 서비스들과의 연동: 기존 AWS 서비스들과의 풍부한 연동.ACID 트랜잭션 지원: 트랜잭션 지원 필요.이러한 요구 사항을 고려했을 때, AWS DynamoDB는 규모에 상관없이 빠르고 유연한 완전 관리형 NoSQL 데이터베이스 서비스로 적합Spike 트래픽 처리스파이크 트래픽 비용 비효율 문제 같은 경우에는 이전 처리량이 동일한 30분 이내에 2배에 해당하는 피크 트래픽을 동시에 수용할 수 있는 온디맨드 모드가 있고, 평소에는 내가 설정한 만큼 사용하다가 오토 스케일링에 의해서 유연하게 처리량을 조절해 주는 프로비저닝 모드가 있는데, 이 두 가지 모드 중에 적절하게 선택하여 DynamoDB를 선택한 것만으로 간단히 해결할 수 있었다고 합니다.1. 온디맨드온디맨드 용량 모드를 사용하는 DynamoDB 테이블은 애플리케이션의 트래픽 볼륨에 따라 자동으로 조정됩니다. 온디맨드 용량 모드의 테이블은 이전 피크 트래픽의 최대 2배 용량을 즉시 수용합니다.2. 프로비저닝애플리케이션 트래픽이 예측 가능한 경우트래픽이 일관되거나 점진적으로 변화하는 애플리케이션을 실행할 경우 애플리케이션에 필요한 초당 읽기 및 쓰기 횟수를 지정합니다. Auto Scaling을 사용하여 트래픽 변경에 따라 테이블의 프로비저닝된 용량을 자동으로 조정할 수 있습니다.온디맨드 모드의 기존 테이블은 언제든지 프로비저닝된 용량 모드로 전환할 수 있습니다. 하지만 온디맨드로의 전환을 나타내는 마지막 타임스탬프가 발생한 지 24시간이 지난 후에야 다시 온디맨드 모드로 전환할 수 있습니다.Spike 트래픽과 SQS채널톡은 외부로부터의 여러 서비스 요청에 대한 로그를 기록하고 있다고 합니다. 이 로그를 DynamoDB에 기록한다면, 갑자기 많은 로그 record를 추가되어 DynamoDB의 ProvisionedThroughput을 넘어서 문제가 발생이 있었습니다. 따라서, Spike 트래픽이 발생할 경우 Amazon SQS를 이용해서 서비스 요청 로그를 버퍼링하고, Amazon SQS에서 일정한 속도로 로그를 읽어서 DynamoDB나 RDS와 같은 저장소에 저장하는 아키텍처를 설계하였다고 합니다.채널톡의 Amazon SQS를 이용한 효율적인 Spike 트래픽 처리 방법PostgreSQL 오페레이션을 DynamoDB로 처리 과정이 외에도 기존 PostgreSQL을 통한 안읽음 표시 오페레이션을 DynamoDB를 통해 어떻게 처리했는 지 등에 대한 내용들 또한 공유해주었습니다.설명을 돕기위한 채널톡 채팅의 주요 요소기존에는 PostgreSQL을 사용했기 때문에 ChatBadge는 원자적 연산을 사용했고, ManagerBadge는 ChatBadge들의 합을 구하면 됐었습니다. 하지만 DynamoDB에서 기존과 같은 방식으로 구현한다면 채팅 방이 많은 사용자는 ManagerBadge를 계산하는 속도가 점점 느려질 것으로 예측하였습니다. 이 문제를 해결하기 위해 DynamoDB 트랜잭션을 통해 어떻게 핸들링하였는 지 공유해 주셨습니다.DynamoDB table 예시특정 채팅 방에서 메시지가 작성되면, 작성자를 제외한 각 참여자에겐 다음과 같은 오퍼레이션이 수행됩니다.참여자의 ChatBadge를 증가시키는 UpdateItem을 생성합니다.참여자의 ManagerBadge를 증가시키는 UpdateItem을 생성합니다.두 개의 UpdateItem 오퍼레이션을 TransactWriteItems API를 사용해 처리합니다.이를 통해, ChatBadge들의 합은 ManagerBadge가 됨을 보장하였고, 또한, 동시에 다량의 메시지가 발생하여아래 그림에서 보시는 바와 같이 충돌이 발생했을 때는 exponential backoff retry 전략을 활용하며, DynamoDB 트랜잭션은 ClientRequestToken 파라메터를 사용하는 경우 멱등성을 지원하기 때문에 연결 시간 초과 등의 문제로 동일 요청이 여러 번 제출된 경우에도 10분 이내라면 정확하게 ChatBadge와 ManagerBadge를 관리하였습니다.참여자의 ManagerBadge를 증가시키는 UpdateItem을 생성합니다.두 개의 UpdateItem 오퍼레이션을 TransactWriteItems API를 사용해 처리합니다.이를 통해, ChatBadg

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

SK플래닛의 Planet AD 는 리워드 광고 플랫폼으로 현재 시럽, OK 캐쉬백, 오락, T 멤버십 등에 광고를 제공하고 있습니다. 2023년 4월에 처음 서비스를 시작하여 이제 1년을 맞이하고 있습니다. 1년 동안 서비스를 운영하면서 팀원들이 맞닥뜨린 여러 사례들과 문제 해결을 위해 어떤 노력들을 하였는지 사례를 중심으로 말씀드리고자 합니다.Planet AD 는 여러 AWS 서비스를 사용하고 있습니다. Amazon EKS 에서 여러 서비스를 운영하고 있으며, 광고 할당에는 Opensearch, DMP 타겟팅에는 DynamoDB, 데이터베이스는 Aurora MySQL 을 사용하고 있습니다. 이처럼 다양한 AWS 서비스를 사용하다 보면 비용 절감이라는 주제를 빠트릴 수 없으므로, 서비스 안정화와 비용 절감이라는 두 가지의 주제로 말씀드리고자 합니다.Planet AD 는 Amazon EKS(Elastic Kubernetes Service)에서 서비스를 운영하고 있습니다. EKS에서 서비스를 운영 할 때 중요한 부분 중 하나는 부하에 따른 Autoscaling인데요, Planet AD 에서도 CPU/RAM 사용량으로 Autoscaling 설정을 해놨습니다. 그런데 트래픽이 집중되는 시간에 Node 가 새로 생성이 되었는데, IP 가 부족하여 Node 생성이 Pending 되는 현상이 발생했습니다.이와 같은 현상은 EKS Node의 기본 설정을 사용하게 될 경우 발생할 수 있습니다. EKS Node는 보다 빠른 Pod 생성을 위해서 Pod 에 할당 가능한 IP를 Warm pool 로 구성하여 유지하게 됩니다. Warm pool 에 있는 IP 는 실제 Pod 에 할당되어 있지 않더라도 사용중인 IP 로 간주합니다. Warm pool 에 할당되는 IP 수는 Node의 ENI (Elastic Network Interface) 수에 따라서 결정되고, ENI 수는 Node 타입(인스턴스 타입)으로 결정됩니다. 예를 들어서 m5.4xlarge의 경우 최대 8개의 ENI 가 붙을 수 있고 각 인터페이스 당 30개의 IP 주소가 할당 될 수 있습니다. 즉 Node에서 Warm pool 에 할당하는 IP 가 30개라고 했을때, Pod가 10개만 생성이 된다면 나머지 20개의 IP는 실제 사용하지 않지만 사용중으로 취급되어 낭비되는 IP 가 생기게 됩니다.Pod 에 IP가 할당되는 과정즉, 많은 수의 Node 가 스케일 아웃 되면서 기본 값으로 Warm Pool 에 할당 될 IP가 부족하여 Node 가 생성되지 않았던 것이었습니다. 따라서 낭비되는 IP 가 없도록 Warm Pool 설정의 변경이 필요합니다. Planet AD에서 변경한 설정 값은 아래와 같습니다.• WARM_ENI_TARGET : WARM IP POOL 을 유지 하기 위한 추가 ENI 의 수• MINIMUM_IP_TARGET : Node 생성 시 Pod에 할당하기 위해 확보해야 하는 최소의 IP 수의 기본값은 1인데, 이는 기본 ENI외의 추가 ENI 1개에서도 Warm Pool 을 유지한다는