aws·2026년 6월 29일·4분 읽기큐레이션 요약

AWS 주간 요약: Amazon Connect Customer를 위한 에이전틱 CX 디자이너, EC2 AMI 워터마크, MySQL을 위한 오픈 거버넌스 등 (2026년 6월 29일) | Amazon Web Services

AWS는 기업이 긴 개발 백로그를 기다리지 않고 AI 기반 고객 경험과 운영 자동화를 구축할 수 있도록 노코드 도구와 AI 보조 기능을 확대하고 있다. 이번 주의 핵심은 Amazon Connect Customer의 Agentic CX Designer와 다양한 서비스의 AI 에이전트·자동화 기능이다. 동시에 EC2 이미지 추적, MySQL 오픈 거버넌스, 자격증 갱신 제도 등 인프라 관리와 개발자 생태계 변화도 소개됐다. ## Amazon Connect Customer의 Agentic CX Designer - 비즈니스 담당자가 직접 AI 기반 고객 경험을 설계하고 배포할 수 있는 노코드 캔버스다. - 음성 및 디지털 채널에서 다음 두 가지 AI 방식을 하나의 관리된 흐름으로 결합한다. - **Agentic AI**: 상황을 판단하고 여러 단계를 수행하는 자율형 AI - **Deterministic AI**: 정해진 규칙과 절차에 따라 일관되게 동작하는 AI - 설계부터 테스트, 시뮬레이션, 운영 배포까지의 과정을 지원해 구축 기간을 수개월에서 수주로 단축하는 것을 목표로 한다. - 프리뷰로 제공되는 **Live Sync**는 사용자가 말하거나 입력하는 내용을 바탕으로 웹·모바일 화면을 실시간으로 변경한다. - 통화 중 고객이 별도 화면을 찾지 않고도 양식을 작성할 수 있다. - 상담 내용에 맞춰 적절한 상품 페이지를 자동으로 표시할 수 있다. - 고객 경험 설계자의 역할이 개발자 중심에서 비즈니스 사용자까지 확대될 수 있다는 점이 핵심이다. ## AWS Lambda MicroVMs - 각 사용자나 작업에 VM 수준의 격리를 제공하는 새로운 서버리스 컴퓨팅 프리미티브다. - Firecracker를 기반으로 하며 빠른 시작과 재개 속도를 제공한다. - 실행 상태를 최대 8시간 동안 일시 중지했다가 다시 재개할 수 있다. - 멀티테넌트 애플리케이션에서 사용자 생성 코드나 AI가 생성한 코드를 실행할 때 유용하다. - 별도의 가상화 인프라를 관리하지 않으면서도 속도, 격리, 상태 보존을 함께 확보하는 것이 목적이다. ## EC2 AMI Watermarks와 이미지 통제 - 프라이빗 AMI에 사용자 정의 식별자를 삽입할 수 있다. - 워터마크는 AMI 복사, 리전 이동, 계정 공유를 거쳐 파생된 AMI에도 자동으로 전달된다. - **Allowed AMIs** 및 **Declarative Policies**와 함께 사용하면 승인된 이미지로만 EC2 인스턴스를 실행하도록 제한할 수 있다. - 모든 AWS 리전에서 추가 비용 없이 제공된다. - 이미지의 출처와 계보를 추적하거나, 조직의 승인 정책을 강제하는 데 활용할 수 있다. ## Outposts 셀프서비스 수명주기 관리 - AWS 콘솔, CLI, API에서 Outposts 관련 작업을 직접 수행할 수 있다. - 지원 범위에는 다음이 포함된다. - 구성 - 견적 산출 - 주문 - 구독 관리 - 갱신 - 폐기 및 해제 - 새로운 견적 도구는 실시간 비용을 수초 내 계산한다. - 주문 전에 계정 및 리전의 제약 조건을 표시해 구성 오류와 주문 지연을 줄인다. ## Kafka·OpenSearch 운영을 돕는 AI 에이전트 - **Amazon MSK AI Agent Skills** - Kiro, Claude Code, Cursor 같은 AI 코딩 도우미에 Amazon MSK 운영 지식을 제공한다. - 문제 해결, 용량 산정, 구성, 모니터링을 안내한다. - 외부 Kafka 클러스터를 MSK Express로 이전하는 작업도 지원한다. - 전문 운영 지식이 필요한 작업을 개발자가 단계적으로 수행할 수 있게 한다. - **Amazon OpenSearch Service AI-assisted migrations** - 셀프 매니지드 Solr, Elasticsearch, OpenSearch를 OpenSearch Serverless 또는 Managed Clusters로 이전하도록 돕는다. - Kiro와 Claude Code를 활용한 에이전트 기반 마이그레이션 경험을 제공한다. - Solr 환경에서는 실시간 트래픽을 캡처하고 재생하는 기능도 추가됐다. - 이전 전후 동작을 검증하고 마이그레이션 위험을 줄이는 데 초점을 둔다. ## GuardDuty의 AI 기반 보안 조사 - 프리뷰 기능으로, 보안 탐지 결과와 계정 활동을 자동 분석한다. - 최근 90일간의 관련 활동과 주변 맥락을 지식 그래프 및 위협 인텔리전스와 함께 검토한다. - 실제 위협과 정상 활동을 구분해 보안팀의 조사 부담을 줄인다. - 각 조사 결과에 다음 정보를 제공한다. - 위협 여부에 대한 처분 평가 - 신뢰도 점수 - MITRE ATT&CK 분류 - 실행 가능한 대응 권고 - 수동 분석에 걸리는 시간을 줄이고, 몇 분 안에 우선순위가 높은 대응 방향을 제시하는 것이 목표다. ## MySQL 오픈 거버넌스 - Oracle은 MySQL 프로젝트에 외부 조직이 공식적으로 참여할 수 있는 커뮤니티 거버넌스 모델을 발표했다. - 새로운 Steering Committee에 Oracle 외부 인사를 위한 4석을 마련한다. - 공개 GitHub 활동을 통해 개발 과정의 투명성과 커뮤니티 참여를 강화한다. - AWS도 위원회 의석을 보유하며, MySQL 업스트림에 수정 사항을 기여해 온 사례와 이번 변화에 대한 지지를 밝혔다. - 기업 사용자는 특정 공급업체에만 의존하지 않고 프로젝트 방향성과 개발 과정에 더 직접적으로 참여할 가능성이 커진다. ## 자격증 갱신과 개발자 지원 - 일부 AWS Associate 및 Professional 자격증은 전체 시험을 다시 치르지 않고도 갱신할 수 있다. - AWS Skill Builder의 지정 교육과 실습 랩을 완료하면 자격증을 1년 추가로 유지할 수 있다. - 현재 오픈 베타로 제공되며, 대상 자격증은 올해 후반 더 확대될 예정이다. - 2026년 All Builders Welcome Grant는 AWS re:Invent 참가 패스, 항공료, 숙박을 지원한다. - 신청 마감일은 7월 14일이며, AWS Summit과 Community Day를 통해 오프라인 네트워킹과 학습 기회도 제공된다. 실무적으로는 비즈니스 팀이 고객 경험을 직접 설계해야 한다면 Agentic CX Designer를 검토하고, 멀티테넌트 코드 실행에는 Lambda MicroVMs, AMI 거버넌스에는 Watermarks와 Allowed AMIs를 함께 검토할 만하다. 운영 측면에서는 MSK·OpenSearch 마이그레이션과 GuardDuty 조사 기능을 활용해 전문 인력 의존도와 수동 분석 시간을 줄일 수 있다.

원문 읽기(새 탭에서 열림)

mysqlAWSApache Kafka서버리스+4

line·2026년 6월 24일·6분 읽기큐레이션 요약

Flava DBaaS 딥다이브: 아키텍처부터 마이그레이션, 그리고 미래까지

LY Corporation은 Verda와 YNW를 차세대 프라이빗 클라우드 Flava로 통합하면서, 쿠버네티스 오퍼레이터 패턴 기반의 DBaaS를 설계했습니다. Flava DBaaS는 데이터베이스 비즈니스 로직과 IaaS 제어를 분리하고, 선언적 관리·자동화·일관된 사용자 경험을 제공하는 것을 목표로 합니다. 또한 DBaaS의 역할을 신규 데이터베이스 제공에 그치지 않고, 기존 플랫폼에서 Flava로의 원활한 마이그레이션까지 확장하고 있습니다. ## 쿠버네티스 오퍼레이터 기반의 선언적 DBaaS - 사용자가 원하는 데이터베이스의 상태를 커스텀 리소스(CR)로 선언하면, 컨트롤러가 실제 상태가 선언된 상태와 일치하도록 지속적으로 조정(reconcile)합니다. - 절차를 직접 지시하는 방식보다 운영 상태를 파악하기 쉽습니다. - 커스텀 리소스의 사양과 현재 상태 비교 - 컨트롤러 로그 및 이벤트 확인 - 문제 발생 원인 추적 - 이벤트 기반 컨트롤러이므로 대규모 데이터베이스 환경에서도 효율적으로 동작할 수 있습니다. - 쿠버네티스의 CI/CD, 권한 관리, API, 모니터링 등 생태계 기능을 활용할 수 있습니다. - 구현 난이도는 높지만, 장기적인 운영과 관리에는 유리합니다. ## 인프라 오퍼레이터를 통한 IaaS 추상화 - DBaaS는 여러 VM, 스토리지, 네트워크, 도메인 등 IaaS 자원을 조합해 데이터베이스 클러스터를 구성합니다. - DBaaS가 IaaS API와 호출 절차를 직접 처리하면 다음 문제가 발생합니다. - 인프라 제어 코드가 지나치게 많아짐 - 데이터베이스 운영 로직과 인프라 로직이 뒤섞임 - DBMS별 개발자가 IaaS 세부사항까지 이해해야 함 - Flava는 IaaS 자원을 인프라 오퍼레이터가 쿠버네티스 커스텀 리소스로 추상화하도록 구성했습니다. - 예를 들어 VM 생성 시 IaaS API를 직접 호출하지 않고, 다음과 같은 속성을 선언한 `server.yaml`을 작성한 뒤 `kubectl create -f server.yaml`로 리소스를 생성합니다. - 가용 영역 - 운영체제 이미지 - vCPU·메모리 등 서버 유형 - 계층은 다음과 같이 분리됩니다. - **DBaaS**: 데이터베이스 비즈니스 로직 담당 - **인프라 오퍼레이터**: IaaS를 쿠버네티스 리소스로 추상화 - **IaaS**: 컴퓨트·네트워크·스토리지 제공 - 이 구조를 통해 여러 DBMS가 IaaS 자원을 동일한 방식으로 사용하고, DBaaS 개발자는 DBMS별 기능에 집중할 수 있습니다. ## 커스텀 리소스와 세 가지 실행 컴포넌트 Flava에서 데이터베이스 클러스터 역시 쿠버네티스 커스텀 리소스로 표현됩니다. - 커스텀 리소스에는 다음과 같은 구성이 선언됩니다. - MySQL 버전 - VM 서버 사양 - 스토리지 종류와 용량 - 복제 멤버 수 - 리소스는 YAML 형태로 etcd에 저장되며 쿠버네티스 API를 통해 생성·조회·수정·삭제할 수 있습니다. DBaaS는 커스텀 리소스를 중심으로 API 서버, 매니저, 에이전트로 나뉩니다. - **API 서버** - 사용자와 UI, IaC 도구가 호출하는 REST API를 제공합니다. - 사용자의 요청을 DBaaS 커스텀 리소스 생성·수정·삭제 작업으로 변환합니다. - **매니저** - 커스텀 리소스의 변경을 감지하는 컨트롤러입니다. - 선언된 사양과 실제 클러스터 상태가 일치하도록 VM 생성, 구성 변경, 복제 설정 등을 조정합니다. - 인프라 오퍼레이터의 커스텀 리소스를 생성해 필요한 VM과 인프라를 준비합니다. - **에이전트** - 데이터베이스가 실행되는 VM 내부에서 동작합니다. - 운영체제 명령이나 데이터베이스 명령처럼 VM 내부에서 실행해야 하는 작업을 수행합니다. - MySQL 설치, 복제 구성, 프로비저닝 등 로컬 실행이 필요한 작업을 담당합니다. 예를 들어 MySQL 클러스터 생성 요청이 들어오면 API 서버가 MySQL 커스텀 리소스를 생성하고, 매니저가 필요한 VM을 만든 뒤, 에이전트가 VM 내부에서 MySQL과 복제 구성을 완료합니다. ## DBMS 지원과 확장성 개선 - Verda와 YNW에서 제공하던 DBMS를 통합해 Flava에서 지원하는 DBMS 종류를 확대했습니다. - 기존 사용자 만족도 조사와 운영 경험을 바탕으로 기능을 추가했습니다. - 스토리지를 100GiB 단위로 구성할 수 있어 용량 조정이 유연해졌습니다. - 블록 스토리지를 사용하는 DBMS는 최대 5TiB까지 지원합니다. - 기존에는 VM 로컬 디스크 용량이 하이퍼바이저의 VM 사양에 종속됐지만, Flava는 다음을 통해 제약을 줄였습니다. - 사용자 정의 인스턴스 유형 - VM과 분리된 블록 스토리지 - 확장된 최대 스토리지 용량 - 단일 VM의 저장공간 부족으로 샤딩을 검토해야 했던 사례를 줄일 수 있습니다. - 5TiB 제한은 대부분의 사용 사례를 충족하면서 블록 스토리지 측 서버 단편화를 방지하기 위한 설계 결정입니다. ## DBMS 전반의 통일된 사용자 경험 - 모든 DBaaS 상품에 공통 아키텍처와 UI·UX를 적용했습니다. - 한 DBMS에서 익힌 관리 방식으로 다른 DBMS도 사용할 수 있습니다. - MySQL에서 서버 사양을 변경한 경험을 Redis에도 적용 - Cassandra에서 설정한 모니터링 알람 방식을 MySQL에도 적용 - DBMS마다 별도의 사용법을 학습해야 하는 부담을 줄였습니다. - 플랫폼 차원에서 프로비저닝, 고가용성, 백업·복구, 확장성, 모니터링 같은 기본 기능을 제공합니다. ## 보안 및 편의 기능 강화 - DBaaS 기본 기능으로 다음 보안 기능을 제공합니다. - **TDE(Transparent Data Encryption)**: 저장 데이터 암호화 - **TLS(Transport Layer Security)**: 전송 구간 암호화 - **Custom DB Role** - 필요한 수준의 권한을 가진 데이터베이스 사용자를 생성·관리할 수 있습니다. - 정의한 역할을 재사용할 수 있습니다. - **Database Parameter Group** - 데이터베이스 파라미터를 원하는 값으로 관리할 수 있습니다. - 설정 그룹을 여러 클러스터에 재사용할 수 있습니다. - **Restore backup** - 특정 백업을 기반으로 새 데이터베이스 클러스터를 생성합니다. - 장애 복구뿐 아니라 실제 데이터가 필요한 성능 테스트 환경 구축에도 활용할 수 있습니다. - 일부 DBMS에서 아직 제공되지 않는 기능도 향후 확대할 예정입니다. ## 마이그레이션까지 포함하는 DBaaS의 책임 - 신규 DBaaS는 데이터베이스를 생성하는 기능만 제공해서는 충분하지 않습니다. - 기존 Verda·YNW 환경의 사용자가 Flava로 쉽게 이동할 수 있도록 마이그레이션 방법까지 제공해야 합니다. - 같은 DBMS 간 마이그레이션 방식은 크게 세 가지로 소개됩니다. ### 덤프 및 복구 - 소스 데이터베이스를 백업한 뒤 목적지 데이터베이스에 복구합니다. - 구현이 가장 단순합니다. - 데이터 정합성을 보장하려면 마이그레이션 중 애플리케이션 중단이 필요합니다. ### 실시간 복제 - DBMS 자체의 복제 기능으로 소스에서 목적지로 데이터를 실시간 복제합니다. - 복제가 완료되면 페일오버해 목적지 클러스터를 새로운 프라이머리로 전환합니다. - 이후 기존 소스 데이터베이스를 제거합니다. - 애플리케이션 중단을 최소화할 수 있지만, 프라이머리 전환 시 짧은 중단이 발생할 수 있습니다. - 데이터 정합성은 사용 중인 DBMS의 복제 메커니즘에 의존합니다. ## 실용적인 결론 Flava DBaaS의 핵심은 데이터베이스를 쿠버네티스 리소스로 선언하고, 인프라 오퍼레이터·매니저·에이전트가 실제 구성을 자동으로 맞추도록 만든 점입니다. 유사한 플랫폼을 설계할 때는 DBaaS와 IaaS의 책임을 분리하고, 공통 UI·보안·백업 기능을 플랫폼 수준에서 제공하며, 신규 기능뿐 아니라 기존 시스템의 마이그레이션 경로까지 함께 설계하는 것이 중요합니다.

원문 읽기(새 탭에서 열림)

mysql쿠버네티스infrastructure-as-codedatabase-migration+4

meta·2026년 5월 12일·4분 읽기큐레이션 요약

메타급 규모에서 데이터 수집 시스템 마이그레이션하기

Meta는 수 페타바이트 규모의 소셜 그래프 데이터를 매일 MySQL에서 데이터 웨어하우스로 수집하는 시스템을 기존 고객 소유 파이프라인에서 단순한 자체 관리형 아키텍처로 전환했다. 이 과정에서 수천 개 작업을 단계적으로 검증하고, 데이터 품질·지연 시간·리소스 사용량을 비교하며 안전하게 마이그레이션했다. 섀도 작업, 리버스 섀도, 자동화된 데이터 품질 분석, 신속한 롤백 체계를 통해 전체 워크로드를 성공적으로 이전하고 레거시 시스템을 폐기했다. ## 대규모 데이터 수집 시스템 개편 배경 - Meta의 소셜 그래프는 세계 최대 규모의 MySQL 환경 중 하나에서 운영된다. - 데이터 수집 시스템은 매일 수 페타바이트의 데이터를 증분 방식으로 데이터 웨어하우스에 적재한다. - 적재된 데이터는 다음과 같은 용도로 활용된다. - 분석 및 리포팅 - 머신러닝 모델 학습 - 제품 개발 - 사내 의사결정 및 데이터 기반 서비스 - 기존 시스템은 소규모에서는 효과적이었지만, 규모가 커지면서 엄격해진 데이터 적재 시간 요구사항을 안정적으로 충족하기 어려워졌다. - 이에 따라 고객 팀이 직접 운영하던 파이프라인을 단순한 자체 관리형 데이터 웨어하우스 서비스로 대체했다. ## 마이그레이션 성공 기준 각 작업은 다음 조건을 충족해야 다음 단계로 진행됐다. - **데이터 품질 일치** - 기존 시스템과 신규 시스템의 행 개수를 비교했다. - 데이터 체크섬을 비교해 두 시스템의 결과가 완전히 일치하는지 검증했다. - **적재 지연 시간 개선** - 신규 시스템의 데이터 적재 지연 시간이 기존보다 개선되거나 최소한 동등해야 했다. - **리소스 사용량 개선** - 컴퓨팅 및 스토리지 사용량이 기존보다 줄어들거나 최소한 비슷해야 했다. - **핵심 테이블 추가 기준** - 중요 테이블은 해당 데이터를 사용하는 팀들과 별도의 마이그레이션 조건을 합의했다. ## 1단계: 섀도 단계 - 사전 운영 환경에 신규 시스템 기반의 섀도 작업을 생성했다. - 섀도 작업은 운영 작업과 동일한 실제 데이터를 읽지만, 별도의 섀도 테이블에 결과를 기록했다. - 실제 운영 데이터와 동작을 사용하므로 다음과 같은 문제를 사전에 발견할 수 있었다. - 데이터 변환 오류 - 특수한 데이터 패턴에서 발생하는 예외 - 신규 시스템의 리소스 부족 - 운영 테이블과 섀도 테이블의 행 개수 및 체크섬을 지속적으로 비교했다. - 불일치가 발생하면 원인을 조사하고 사전 운영 환경에 수정 사항을 배포한 뒤 재검증했다. - 동시에 섀도 작업의 컴퓨팅·스토리지 사용량을 측정해 운영 환경에 충분한 자원이 있는지 확인했다. - 기준을 통과한 작업은 운영 환경에서도 안정적으로 실행되는지 추가로 검증했다. ## 2단계: 리버스 섀도 단계 - 신규 시스템의 섀도 작업이 운영 테이블에 데이터를 기록하도록 전환했다. - 기존 시스템의 운영 작업은 섀도 테이블에 데이터를 기록하게 했다. - 이로써 신규 시스템이 실제 운영 작업이 되고, 기존 시스템은 비교용 섀도 작업으로 역할이 바뀌었다. - 이 방식의 장점은 다음과 같다. - 전환 이후에도 기존 시스템과 신규 시스템의 결과를 계속 비교할 수 있다. - 데이터 불일치가 발견되면 기존 작업을 다시 구성하지 않고 즉시 되돌릴 수 있다. - 신규 시스템이 실제 운영 환경에서 지속적으로 안정적인지 확인할 수 있다. ## 3단계: 마이그레이션 정리 - 두 시스템의 결과를 계속 비교하면서 불일치 여부를 감시했다. - 문제가 발견되지 않으면 기존 시스템에서 실행 중인 섀도 작업을 제거했다. - 이후 신규 시스템이 운영 작업으로서 데이터 적재를 계속 수행하며 마이그레이션이 완료됐다. ## 자동화된 데이터 품질 분석 도구 - 각 섀도 테이블 파티션과 대응하는 운영 테이블 파티션을 읽어 행 개수와 체크섬을 비교했다. - 불일치 내역은 Meta의 실시간 데이터 분석 시스템인 Scuba에 기록했다. - 매시간 Scuba 로그를 분석해 불일치를 일으킨 실제 예시 행을 찾았다. - 원인 분석에 필요한 상세 디버깅 정보도 다시 Scuba에 기록했다. - 이를 통해 엔지니어는 다음을 빠르게 판단할 수 있었다. - 불일치의 근본 원인 - 이미 알려진 문제인지 여부 - 해당 문제가 수정 진행 중인지 여부 - 이 도구는 마이그레이션 이후에도 릴리스 검증 과정에서 계속 사용되고 있다. ## CDC 기반 구조와 롤백 문제 - 기존 시스템과 신규 시스템 모두 CDC(Change Data Capture)를 사용해 변경분을 대상 테이블에 증분 반영했다. - 각 작업은 다음 테이블을 관리한다. - 소스 데이터베이스의 전체 덤프를 저장하는 내부 테이블 - 소스 변경 사항을 저장하는 델타 테이블 - 데이터 소비자가 사용하는 대상 테이블 - 작업 엔터티, 테이블 이름, 스키마 등의 메타데이터는 중앙 관리 서비스가 관리했다. - CDC에서는 이전에 적재된 데이터가 이후 데이터 생성에 다시 사용된다. - 따라서 과거 데이터에 문제가 있으면 해당 문제가 신규 적재 데이터로 계속 전파될 수 있다. - 마이그레이션 후 문제가 발생하면 잘못된 데이터가 계속 확산되는 것을 막기 위해 신속한 롤백이 필요했다. ## 조기 신호와 신속한 롤백 - 데이터 소비자가 문제를 발견할 때까지 기다리지 않고, 리버스 섀도 단계에서 두 시스템의 결과를 지속적으로 비교했다. - 이를 통해 마이그레이션 성공 여부에 대한 조기 신호를 확보했다. - 문제가 발견되면 기존 시스템이 이미 섀도 작업으로 실행 중이므로 빠르게 이전 상태로 되돌릴 수 있었다. - 마이그레이션 작업을 처음부터 다시 생성하거나 재구성하지 않아도 된다는 점이 롤백 위험을 줄였다. 대규모 데이터 시스템을 이전할 때는 한 번에 전환하기보다, 실제 데이터 기반의 섀도 실행과 양방향 역할 전환을 통해 검증하는 방식이 안전하다. 특히 행 개수·체크섬·지연 시간·리소스 사용량을 자동 비교하고, 문제가 생겼을 때 즉시 롤백할 수 있는 구조를 마이그레이션 설계에 포함하는 것이 중요하다.

원문 읽기(새 탭에서 열림)

mysql머신러닝data-ingestionchange-data-capture+3

toss·2026년 4월 23일원문

StarRocks 운영기: Resource Group으로 멀티테넌트 워크로드 격리하기 (새 탭에서 열림)

토스는 서비스 조회와 대규모 분석 쿼리를 하나의 플랫폼에서 처리하기 위해 StarRocks를 실시간 OLAP 엔진으로 도입하고, 다양한 워크로드가 공존하는 환경에서 리소스 그룹(Resource Group)을 통해 안정적인 운영 체계를 구축했습니다. 특히 CPU 우선순위 설정과 전용 코어 할당 방식을 전략적으로 선택하여, 대규모 배치 작업이 진행되는 중에도 서비스 쿼리의 응답 속도(SLA)를 일관되게 유지하는 최적의 격리 구조를 설계했습니다. **비즈니스 중요도에 따른 워크로드 분류** * 워크로드의 성격에 따라 서비스 쿼리, 서버 배치, 대규모 적재·백필, 모니터링·사용자 도구 순으로 우선순위를 정의했습니다. * 실시간 응답이 필수적인 서비스 쿼리는 가장 먼저 보호하고, 클러스터 전체에 부하를 줄 수 있는 대규모 적재나 단순 모니터링 조회는 하위 순위나 상한선을 두어 관리합니다. **가중치 기반의 유연한 리소스 분배 (cpu_weight)** * CPU 경합이 발생할 때 설정된 비율에 따라 리소스를 분배하는 방식으로, Linux CFS(Completely Fair Scheduler)와 유사한 자체 스케줄링 메커니즘을 사용합니다. * 리소스가 여유로울 때는 다른 그룹의 남는 자원을 빌려 쓸 수 있어(Borrowing), 일반적인 멀티테넌트 환경에서 리소스 효율성을 극대화하는 기본 설정으로 활용됩니다. * 내부적으로 파이프라인 드라이버가 100ms 타임 슬라이스 단위로 양보하며 동작하므로, 중요도가 높은 그룹이 더 많은 CPU 시간을 확보하게 됩니다. **물리적 코어 예약을 통한 배타적 격리 (exclusive_cpu_cores)** * 높은 SLA가 요구되는 특정 서비스의 경우, 물리적 코어를 전용으로 예약하여 다른 워크로드의 간섭을 완전히 차단합니다. * 이 설정은 단순히 논리적 할당에 그치지 않고, `pthread_setaffinity_np`를 통해 스레드를 코어에 바인딩하며 쿼리 실행을 위한 3벌의 ThreadPool(Driver, Scan, ConnectorScan)을 별도로 생성합니다. * 공유 리소스 풀과의 경합이 원천적으로 제거되므로, 헤비 배치 작업과 서비스 조회가 겹치는 상황에서도 응답 시간이 튀는 현상을 방지할 수 있습니다. **토스쇼핑 사례를 통한 단계적 최적화** * 초기에는 `cpu_weight` 조정을 통해 서비스 계정에 높은 우선순위를 부여했으나, 대규모 배치 작업 시 서비스 응답 속도가 불안정해지는 한계가 있었습니다. * 이를 해결하기 위해 서비스 전용 리소스 그룹에 `exclusive_cpu_cores`를 적용하여 물리적인 리소스 벽을 세웠습니다. * 결과적으로 분당 1,500건 이상의 서비스 요청이 발생하는 구간에서도 배치 작업의 영향 없이 안정적인 레이턴시를 확보하는 데 성공했습니다. **정교한 쿼리 매칭을 위한 Classifier 설계** * `user`, `role`, `query_type`, `db` 등의 속성을 기반으로 쿼리를 적절한 리소스 그룹에 할당하는 Classifier 규칙을 수립했습니다. * 운영 안정성을 위해 가급적 `user` 또는 `db` 단위로 그룹을 묶는 패턴을 권장하며, 이를 통해 특정 서비스나 배치 주체가 정해진 리소스 범위 내에서만 동작하도록 강제합니다. * CPU 제어 외에도 `mem_limit`과 `concurrency_limit`을 병행 설정하여 풀 스캔 쿼리의 메모리 독점이나 과도한 동시 접속으로 인한 클러스터 마비를 방지합니다. **실용적인 운영 제언** 가장 효율적인 운영 전략은 기본적으로 `cpu_weight`를 사용하여 리소스 효율을 높이되, 실시간 서비스와 같이 지연 시간에 민감한 워크로드에 한해서만 `exclusive_cpu_cores`를 단계적으로 도입하는 것입니다. 또한 리소스 그룹 설정 시 실제 물리 코어 수와 워크로드 간의 의존 관계를 면밀히 검토해야 예상치 못한 성능 저하를 막을 수 있습니다.

mysql데이터베이스 설계hadoopstarrocks+4

cloudflare·2026년 4월 16일원문

PlanetScale + Workers로 Postgres 및 MySQL 데이터베이스 배포하기 (새 탭에서 열림)

Cloudflare와 PlanetScale의 파트너십 강화를 통해 이제 Cloudflare Workers 사용자는 Postgres 및 MySQL 데이터베이스를 Cloudflare 대시보드 내에서 직접 생성하고 관리할 수 있게 되었습니다. 데이터베이스 사용료는 Cloudflare 계정으로 통합 청구되며, Cloudflare 스타트업 프로그램 크레딧이나 약정된 지불액(Committed Spend) 또한 PlanetScale 데이터베이스 결제에 활용 가능합니다. 이를 통해 개발자들은 별도의 인프라 관리 부담 없이 강력한 관계형 데이터베이스를 Cloudflare 생태계 안에서 완벽하게 통합하여 사용할 수 있습니다. **Cloudflare 대시보드를 통한 데이터베이스 통합 관리** - 사용자는 Cloudflare 대시보드 및 API를 통해 PlanetScale의 Postgres와 MySQL 데이터베이스를 즉시 배포할 수 있습니다. - 데이터베이스 사용 비용이 Cloudflare 청구서에 통합되어 단일한 결제 시스템으로 관리되므로, 셀프 서비스 및 엔터프라이즈 고객의 운영 효율성이 높아집니다. - pgvector와 같은 확장 기능을 지원하는 Postgres와 대규모 확장성을 제공하는 Vitess 기반 MySQL을 선택하여 애플리케이션 요구사항에 맞게 구성할 수 있습니다. **Hyperdrive를 활용한 고성능 연결 환경** - Cloudflare의 데이터베이스 연결 서비스인 Hyperdrive가 기본 통합되어 PlanetScale 데이터베이스와 Workers를 효율적으로 연결합니다. - Hyperdrive는 데이터베이스 커넥션 풀링(Connection Pooling)과 쿼리 캐싱을 자동으로 수행하여 쿼리 성능과 안정성을 대폭 향상합니다. - 개발자는 `wrangler.jsonc` 설정 파일에 간단한 바인딩 정보를 추가하고, 표준 Postgres 클라이언트(예: `pg` 라이브러리)를 사용하여 즉시 SQL 쿼리를 실행할 수 있습니다. **Smart Placement를 이용한 네트워크 지연 시간 단축** - Workers의 'Placement' 힌트 기능을 사용하여, Worker가 PlanetScale 데이터베이스와 가장 가까운 Cloudflare 데이터 센터에서 실행되도록 설정할 수 있습니다. - 기본적으로 Workers는 사용자 위치에서 실행되지만, 중앙 집중식 데이터베이스를 사용할 때는 DB 서버 근처에서 실행되도록 조정함으로써 네트워크 레이턴시를 획기적으로 줄일 수 있습니다. - 향후에는 데이터베이스 위치에 따라 자동으로 실행 위치를 최적화하여 지연 시간을 한 자릿수 밀리초(ms) 단위로 단축하는 기능이 제공될 예정입니다. 현재 Cloudflare 대시보드에서 PlanetScale 데이터베이스를 바로 연결하여 사용할 수 있으며, 다음 달부터는 Cloudflare를 통한 통합 결제가 정식으로 시작됩니다. 고성능 풀스택 애플리케이션 구축을 고려 중이라면, 전 세계 어디서나 빠른 응답 속도를 보장하는 Cloudflare Workers와 PlanetScale의 결합을 적극 활용해 보시기 바랍니다.

mysql데이터베이스 설계cloudflarePostgreSQL+3

line·2026년 2월 13일원문

슬로우 쿼리 해결기: 함수형 인덱스로 비트 연산 쿼리 최적화하기 (새 탭에서 열림)

LINE VOOM 서비스는 헤비 유저의 프로필 조회 시 비트 연산 조건으로 인해 발생하는 30초 이상의 슬로우 쿼리 문제를 해결하기 위해 MySQL 8.0.13의 함수형 인덱스(functional index)를 도입했습니다. 기존의 비트 연산 조건은 인덱스를 무력화하여 수십만 건의 데이터를 풀 스캔하게 만들었으나, 연산 결과를 인덱싱하고 이를 10진수 동등 비교 쿼리로 전환함으로써 스캔 범위를 3% 수준으로 대폭 축소했습니다. 이 과정에서 무중단 인덱스 생성과 점진적 롤아웃을 통해 운영 안정성을 확보하며 시스템 성능을 성공적으로 최적화했습니다. ### 비트 연산 조건에 의한 성능 저하 원인 * LINE VOOM의 포스트 메타데이터 테이블은 `category_flag`와 `access_flag`라는 `bit(64)` 타입 컬럼에 서비스 상태 정보를 압축 저장합니다. * 특정 상태를 필터링하기 위해 `category_flag & 0x0100`과 같은 비트 연산을 사용했는데, 이는 인덱스에 저장된 원본 값이 아닌 연산 결과를 조건으로 활용하므로 기존 인덱스를 타지 못합니다. * 결과적으로 특정 사용자의 모든 포스트를 일일이 순회하며 연산을 수행해야 했고, 포스트가 수십만 건에 달하는 헤비 유저의 경우 쿼리 타임아웃이 빈번하게 발생했습니다. ### 함수형 인덱스를 활용한 최적화 설계 * MySQL 8.0.13에서 도입된 함수형 인덱스는 표현식의 결과를 가상 컬럼 형태로 저장하고 인덱싱하는 기능을 제공합니다. * 팀은 `user_id`와 비트 연산 표현식을 결합한 복합 인덱스 `idx_user_premium_searchable (user_id, (category_flag & 0x0100), (access_flag & 0x0001))`를 설계했습니다. * 이 방식은 기존 테이블 스키마를 크게 변경하지 않으면서도 특정 비트 패턴에 대해 즉각적인 인덱스 조회를 가능하게 합니다. ### 인덱스 활성화를 위한 쿼리 튜닝 및 검증 * 개발 환경 테스트 결과, 단순히 비트 연산을 포함하는 것만으로는 인덱스가 작동하지 않는 것을 확인했습니다. * 인덱스를 타기 위해서는 쿼리의 표현식이 인덱스 정의와 완벽히 일치해야 하며, 특히 비트 연산 결과를 **10진수 값으로 동등 비교**(`= 256`)했을 때만 인덱스가 정상적으로 적용되었습니다. * 최적화 후 스캔 행 수가 805건에서 31건으로 줄어드는 등 극적인 성능 향상을 보였으며, 인덱스 용량 증가(약 24%)는 운영 환경에서 수용 가능한 수준으로 판단되었습니다. ### 운영 환경 적용 및 시행착오 해결 * **무중단 인덱스 생성**: DBA 팀과 협업하여 Online DDL 방식을 사용함으로써 서비스 중단 없이 수십 개의 테이블에 인덱스를 추가했습니다. * **복제 지연 대응**: 인덱스 생성 중 발생한 마스터-슬레이브 복제 지연으로 인해 최신 글이 보이지 않는 이슈가 발생했으나, 캐시 만료 시간을 단축하여 사용자 불편을 최소화했습니다. * **논리 오류 방지**: 비트 연산을 동등 비교로 바꿀 때 OR 조건과 AND 조건의 의미 차이로 인한 버그를 발견했습니다. 이를 방지하기 위해 동적 설정을 활용해 샤드별로 쿼리를 점진적으로 적용하며 안전하게 검증을 마쳤습니다. 비트 연산과 같이 컬럼 가공이 필요한 조건을 상시로 사용해야 한다면, MySQL의 함수형 인덱스는 스키마 변경 부담을 최소화하면서 성능을 극대화할 수 있는 강력한 도구입니다. 다만, 인덱스가 적용되는 정확한 표현식(10진수 비교 등)을 사전에 검증하고, 대규모 테이블 작업 시 발생할 수 있는 복제 지연과 논리적 조건 변화를 세심하게 모니터링하는 것이 중요합니다.

mysql데이터베이스 설계cachingsharding+4

kakao·2026년 2월 8일·4분 읽기큐레이션 요약

잃어버린 리포트를 찾아서: 카카오 메시징 시스템의 경쟁 조건 문제와 안티 패턴 제거 과정

KIMS의 메시지 상태가 `SENT`에 멈춘 원인은 벤더사의 전송 결과 리포트가 메시지 레코드의 DB 커밋보다 먼저 도착하는 경쟁 조건이었다. 특히 응답이 빠른 특정 벤더와, 과금 후처리로 트랜잭션이 길어진 유료 메시지에서 문제가 집중되었으며, 전체 메시지의 약 0.02%에서 발생했다. 트랜잭션 범위를 줄이고 각 보장의 필요성을 재검토하는 과정에서, 불필요한 장기 트랜잭션과 외부 이벤트 발행을 분리해야 한다는 결론에 도달했다. ### KIMS 메시지 처리 구조 - KIMS는 카카오 내부 서비스용 SMS 전송 플랫폼으로, 하루 약 100만 건을 처리한다. - 다수의 IDC와 MSA 컴포넌트, 여러 외부 SMS 벤더로 구성되어 있다. - 기본 흐름은 다음과 같다. - API Server가 품질 지표를 기준으로 벤더를 선택한다. - 벤더 호출 후 메시지를 `SENT` 상태로 DB에 기록한다. - 벤더가 전송 결과 리포트를 전달한다. - Report Server가 메시지를 `REPORTED` 상태로 갱신한다. - 각 단계가 비동기적으로 분리되어 있어, 처리 순서가 뒤집힐 가능성이 존재했다. ### `SENT` 상태에 멈춘 메시지 - 일부 메시지가 리포트를 수신했음에도 `REPORTED`로 갱신되지 않았다. - Report Server 로그에는 벤더 리포트 수신 기록이 남아 있었다. - 즉, 리포트가 네트워크에서 유실된 것이 아니라 DB 반영 전에 폐기된 상황이었다. - 문제가 전체 메시지가 아닌 약 0.02%에서만 발생해 재현과 원인 분석이 어려웠다. ### 빠른 벤더와 긴 트랜잭션이 만든 경쟁 조건 - 리포트 누락은 특정 벤더로 전송된 메시지에서 집중적으로 발생했다. - 해당 벤더는 API 호출 후 평균 약 20ms, 문제 사례에서는 약 8ms 만에 리포트를 보냈다. - 반면 API Server는 벤더 호출 이후 후처리와 DB 영속화를 진행하고 있었다. - 유료 메시지는 과금 이벤트 발행 로직까지 하나의 `@Transactional` 범위에 포함되어 트랜잭션이 더 오래 유지됐다. - 결과적으로 처리 순서가 다음처럼 역전될 수 있었다. - API Server가 벤더 호출 - 과금 후처리와 이벤트 발행 수행 - 벤더가 리포트 전송 - Report Server가 상태 갱신 시도 - 아직 메시지 레코드가 DB에 없어 리포트가 유효하지 않은 것으로 판단되어 Drop - API Server가 뒤늦게 메시지를 DB에 저장 - 메시지의 초기 상태를 기록하는 Write 경로와 리포트를 읽어 상태를 갱신하는 Read 경로가 같은 시점에 교차하면서 Race Condition이 발생했다. ### 트랜잭션 범위 줄이기 - 기존 트랜잭션에는 DB 상태 변경뿐 아니라 Kafka 이벤트 발행 등 비즈니스 로직도 포함되어 있었다. - 이로 인해 Long-lived Transaction이 발생하고 DB Commit 시점이 지연됐다. - 과금 이벤트 발행을 `@Async`, `@TransactionalEventListener` 기반으로 분리해 커밋 이후 별도 스레드에서 실행하도록 변경했다. - 트랜잭션 책임을 상태 변경과 DB 영속화까지로 제한했다. - 평균 커밋 시점이 약 10ms 앞당겨졌고, 리포트 누락도 눈에 띄게 감소했다. - 외부 이벤트 발행 실패 때문에 DB 트랜잭션 전체가 롤백되는 Dual-write 문제도 완화됐다. - 외부 시스템으로 보내는 이벤트는 DB 트랜잭션과 본질적으로 동시에 롤백할 수 없으므로, 트랜잭션 내부에 무리하게 포함하는 방식은 부적절했다. ### 트랜잭션 보장의 필요성 재검토 글은 단순히 트랜잭션을 짧게 만드는 데서 그치지 않고, 해당 업무에 트랜잭션 자체가 필요한지 질문한다. MySQL의 `REPEATABLE READ`에서 제공되는 보장을 세 가지로 나누어 검토했다. - **원자성** - 여러 쓰기 작업 중 일부만 성공하는 상황을 막고 전체를 롤백하는 기능이다. - 해당 로직의 DB 쓰기는 사실상 단일 작업이었다. - 여러 테이블이나 레코드에 걸친 원자성이 필요하지 않다면 트랜잭션의 Abortability는 필수적이지 않을 수 있다. - **읽기 격리** - 라우팅 벤더 정보와 실시간 품질 지표를 조회하고 있었다. - 품질 지표는 분 단위로 갱신되며, 1분 전 데이터가 사용되어도 문제가 없었다. - 서로 독립적인 메타데이터를 조회하므로 동일한 스냅샷에서 읽어야 할 필요도 크지 않았다. - **쓰기 격리** - 변경 내용을 커밋 전까지 다른 트랜잭션에 노출하지 않는 보장이다. - JPA/Hibernate의 Dirty Checking에서는 변경 사항이 먼저 Persistence Context의 1차 캐시에 반영되고, 실제 DB Write는 트랜잭션 종료 시점까지 지연될 수 있다. - 이 지연이 리포트 처리보다 DB 저장이 늦어지는 직접적인 원인이 되었다. ### 실용적인 설계 교훈 - 외부 시스템의 응답 시간이 매우 짧을 수 있다는 전제에서 비동기 흐름을 설계해야 한다. - “호출 후 DB 저장”처럼 순서를 가정한 구조는 벤더별 응답 편차 때문에 경쟁 조건을 만들 수 있다. - 트랜잭션에는 반드시 원자적으로 처리해야 하는 DB 작업만 포함하고, 이벤트 발행·외부 API 호출·긴 후처리는 분리하는 것이 좋다. - 트랜잭션의 원자성·읽기 격리·쓰기 격리가 실제 비즈니스 요구사항인지 각각 검토해야 한다. - 리포트 처리에서는 아직 원본 메시지가 저장되지 않은 경우를 단순 Drop하지 말고, 재시도·지연 큐·Transactional Outbox 같은 보완책을 함께 고려해야 한다.

원문 읽기(새 탭에서 열림)

mysqlApache Kafka분산 시스템race-condition+4

pinterest·2026년 2월 5일원문

Pinterest의 차세대 DB 인 (새 탭에서 열림)

Pinterest는 기존의 파편화된 배치 기반 DB 적재 시스템을 개선하기 위해 Iceberg와 CDC(Change Data Capture) 기술을 결합한 통합 프레임워크를 구축했습니다. 이 시스템은 데이터 지연 시간을 24시간 이상에서 수 분 단위로 단축하고, 변경된 데이터만 처리하는 방식으로 인프라 비용을 획기적으로 절감했습니다. 이를 통해 분석, 머신러닝, 규정 준수 등 현대적인 데이터 요구사항에 기민하게 대응할 수 있는 고성능 데이터 생태계를 마련했습니다. ### 통합 CDC 프레임워크의 계층 구조 * **CDC 레이어**: Debezium 및 TiCDC를 활용해 MySQL, TiDB, KVStore의 변경 사항을 1초 미만의 지연 시간으로 포착하여 Kafka에 기록합니다. * **스트리밍 레이어**: Flink 작업이 Kafka의 이벤트를 실시간으로 처리하여 S3에 위치한 'CDC Iceberg 테이블'에 추가 전용(Append-only) 방식으로 저장합니다. * **배치 레이어**: Spark 작업이 주기적으로(15~60분) CDC 테이블의 최신 변경 사항을 읽어 `Merge Into` 구문을 통해 최종 'Base Iceberg 테이블'에 업서트(Upsert)를 수행합니다. * **부트스트랩 및 유지보수**: 초기 데이터 로드를 위한 전용 파이프라인과 소형 파일 압축(Compaction) 및 스냅샷 만료 관리를 위한 유지보수 작업을 포함합니다. ### CDC 테이블과 베이스 테이블의 이원화 관리 * **CDC 테이블**: 모든 변경 이력을 담은 시계열 원장으로, 5분 미만의 지연 시간을 유지하며 원천 데이터의 변경 로그를 보존합니다. * **베이스 테이블**: 온라인 DB의 현재 상태를 그대로 반영하는 스냅샷 테이블입니다. CDC 테이블로부터 최신 레코드를 추출하여 정합성을 맞춥니다. * **동기화 로직**: `ROW_NUMBER()` 함수를 활용해 기본 키(PK)별로 가장 최신 업데이트(최근 타임스탬프 및 GTID 기준)를 식별한 후, 삭제 유형은 제거하고 나머지는 업데이트 또는 삽입합니다. ### 성능 및 비용 최적화 전략 * **Merge-on-Read (MOR) 방식 채택**: Copy-on-Write(COW) 방식은 업데이트 시 대규모 파일을 다시 작성해야 하므로 스토리지와 계산 비용이 높습니다. Pinterest는 비용 효율성을 극대화하기 위해 MOR 방식을 표준 전략으로 선택했습니다. * **기본 키 해시 버킷팅(Bucketing)**: 베이스 테이블을 PK의 해시값(예: `bucket(100, id)`)으로 파티셔닝하여 Spark가 업서트 작업을 병렬로 효율적으로 처리할 수 있도록 설계했습니다. * **증분 처리 효율성**: 매일 전체 테이블을 덤프하던 방식에서 변경된 데이터(통상 5% 미만)만 처리하는 방식으로 전환하여 연산 리소스 낭비를 차단했습니다. 방대한 양의 데이터베이스를 데이터 레이크로 통합할 때는 Iceberg의 `Merge Into` 기능을 활용한 증분 업데이트가 필수적입니다. 특히 읽기 성능과 쓰기 비용 사이의 균형을 위해 MOR 전략을 사용하고, 쓰기 병목을 해소하기 위해 기본 키 기반의 버킷팅을 적용하는 것이 실무적으로 매우 효과적인 접근임을 보여줍니다.

mysqlApache Kafkaapache-sparkapache-iceberg+4

naver·2026년 1월 22일원문

스마트스토어센터 Oracle에서 MySQL로의 무중단 전환기 (새 탭에서 열림)

네이버 스마트스토어센터는 비즈니스 성장에 따른 Oracle DBMS의 리소스 경합과 라이선스 비용 문제를 해결하기 위해 오픈소스인 MySQL로의 무중단 마이그레이션을 단행했습니다. 10년 이상의 레거시 시스템을 안정적으로 전환하기 위해 '이중 쓰기(Dual Write)' 전략을 채택했으며, 이를 통해 데이터 손실 없는 실시간 동기화와 즉각적인 롤백 가능성을 확보했습니다. 결과적으로 서비스 중단 없이 DB 환경을 성공적으로 전환하며 운영 효율성을 높였습니다. ### 이중 쓰기(Dual Write)를 통한 무중단 전환 전략 * **3단계 전환 프로세스**: 전환 전에는 Oracle을 메인으로 사용하며 MySQL에 백그라운드 쓰기를 수행하고, 데이터 마이그레이션 후에는 MySQL을 메인으로 전환하되 Oracle에 백그라운드 쓰기를 지속하여 정합성을 유지합니다. * **롤백 안정성 확보**: 신규 시스템 배포 후 치명적인 성능 저하나 장애가 발생하더라도, Oracle에 실시간으로 데이터가 쌓이고 있으므로 별도의 복구 작업 없이 즉시 이전 환경으로 복구가 가능합니다. ### JPA 환경에서의 기술적 대응 * **Proxy DataSource 활용**: `datasource-proxy` 라이브러리를 사용하여 Oracle에서 수행되는 쿼리를 가로챈 뒤 MySQL DataSource에서도 동일하게 실행하는 구조를 구축했습니다. * **트랜잭션 분리 및 동기화**: MySQL 쿼리 실패가 메인 트랜잭션(Oracle)에 영향을 주지 않도록 `TransactionSynchronizationManager`를 사용했습니다. Oracle 커밋이 성공한 시점(`afterCommit`)에 모아둔 MySQL 쿼리를 일괄 실행하여 정합성을 맞춥니다. * **엔티티 및 PK 전략 변경**: Oracle의 Sequence 전략을 MySQL의 Identity(Auto-increment)로 변경하고, `columnDefinition` 설정을 통해 Oracle의 VARCHAR2, CLOB 등을 MySQL의 TEXT, LONGTEXT 타입에 맞게 조정했습니다. ### MyBatis 기반의 중앙 집중형 이중 쓰기 구현 * **SqlSession Proxy 적용**: 수천 개의 비즈니스 로직을 수정하는 대신, MyBatis의 `SqlSession`을 프록시로 감싸 쓰기 작업(CUD)이 발생할 때 Oracle과 MySQL 쿼리를 동시에 호출하도록 구현했습니다. * **DBMS별 쿼리 매핑**: Oracle과 MySQL의 SQL 문법 차이를 해결하기 위해 별도의 MySQL용 쿼리 파일을 작성하고, 실행 시점에 Query ID에 접두사(예: `mysql.`)를 붙여 적절한 쿼리를 찾아 실행하는 방식을 사용했습니다. ### 데이터 정합성 검증 및 최종 전환 * **배치 기반 검증**: 두 DB 간의 레코드 카운트와 데이터 해시값을 주기적으로 비교하는 배치 프로그램을 운영하여 미세한 데이터 불일치를 식별하고 수정했습니다. * **기능 토글을 이용한 전환**: ZooKeeper 등을 활용한 설정 변경만으로 메인 DB(Read/Write 주체)를 즉시 교체할 수 있는 환경을 구성하여 배포 없이 안정적으로 전환을 완료했습니다. 이와 같은 전략은 대규모 레거시 시스템에서 DB를 교체해야 할 때, 코드 수정을 최소화하면서도 서비스 안정성을 최우선으로 고려하는 개발자들에게 실무적인 가이드라인을 제공합니다. 특히 트랜잭션 동기화와 프록시 패턴을 활용한 중앙 집중식 제어는 복잡한 시스템 마이그레이션의 위험 부담을 낮추는 핵심 기술 요소입니다.

mysqldatabase-migrationzero-downtime-migrationjpa+4

toss·2025년 11월 30일원문

레거시 결제 원장을 확장 가능한 시스템으로 (새 탭에서 열림)

토스페이먼츠는 20년 된 레거시 결제 원장의 구조적 한계와 도메인 간 강한 결합을 해결하기 위해 MySQL 기반의 신규 원장 시스템을 구축했습니다. 데이터 불변성을 보장하는 INSERT-only 원칙과 이벤트 기반 아키텍처를 도입하여 복합 결제 지원 등 비즈니스 확장성을 확보했습니다. 이 과정에서 발생한 데이터 불일치와 타임아웃 문제를 해결하며 시스템의 자가 회복 능력을 강화하고 안정적인 운영 환경을 마련했습니다. ### 레거시 원장 시스템의 한계와 과제 - **데이터 구조의 불일치:** 결제수단별로 테이블 구조가 다르고, 동일한 성격의 데이터가 서로 다른 테이블에 저장되어 유지보수와 온보딩에 큰 비용이 발생했습니다. - **도메인 간 강한 결합:** 결제, 정산, 회계 등 여러 서비스가 하나의 원장 테이블과 컬럼을 공유하여, 작은 기능 수정 시에도 전사적인 영향도 분석이 필요했습니다. - **구조적 확장성 부족:** 결제와 결제수단이 1:1 관계로 묶여 있어, 더치페이나 복합 결제(카드+포인트)와 같은 현대적인 결제 시나리오를 지원할 수 없었습니다. ### 신규 원장 설계의 3가지 전략 - **데이터 불변성과 일관성:** 모든 승인 내역을 공통 테이블(`approve`)에 저장하고, 수정 대신 INSERT-only 방식을 채택하여 데이터의 정합성을 높이고 데드락을 방지했습니다. - **이벤트 기반의 도메인 분리:** 각 도메인이 직접 DB를 조회하는 대신 Kafka 이벤트를 구독하여 데이터를 처리하게 함으로써 도메인 간 의존성을 제거했습니다. - **결제와 승인 개념의 분리:** '결제'는 주문의 상태를, '승인'은 실제 결제수단의 실행을 의미하도록 분리하여 하나의 결제에 여러 승인 수단이 연결될 수 있는 유연한 구조를 만들었습니다. ### 무중단 마이그레이션 및 정합성 검증 - **비동기 점진적 적재:** 실서비스 장애를 방지하기 위해 기존 원장에 먼저 저장한 후, 신규 원장에는 별도의 ThreadPool을 통한 비동기 방식으로 데이터를 적재했습니다. - **검증 배치 운영:** 비동기 적재 중 발생할 수 있는 누락을 방지하기 위해, 매 5분마다 Read-Only DB를 기반으로 기존 원장과 신규 원장의 데이터를 비교하고 보정하는 배치를 실행했습니다. - **고성능 이관 작업:** 수억 건의 데이터 이관을 위해 Bulk Insert를 도입하고, 네트워크 지연 최소화를 위해 마이그레이션 서버를 DB와 동일한 가용 영역(AZ)에 배치했습니다. ### 운영 중 장애 대응과 시스템 고도화 - **쿼리 최적화:** 옵티마이저의 판단 오류로 발생한 풀 스캔(Full Scan) 문제를 인덱스 힌트(Index Hint) 추가와 롤백 시스템을 통해 빠르게 해결했습니다. - **타임아웃 및 정합성 관리:** MSA 구조에서 서버 간 타임아웃 설정을 일치시키고, 외부 원천사와의 상태 불일치를 해결하기 위한 망취소(Network Cancellation) 로직을 강화했습니다. - **이벤트 처리의 신뢰성:** 아웃박스(Outbox) 패턴과 로그 기반 복구를 통해 이벤트 누락을 방지하고, 헤더에 멱등키를 포함해 중복 이벤트 처리 문제를 해결했습니다. 신규 시스템으로의 전환은 단순한 DB 교체가 아니라 시스템의 지속 가능성을 확보하는 과정입니다. 초기 설계의 완벽함보다 중요한 것은 운영 중 발생하는 예외 상황에 시스템이 스스로 대응하고 회복할 수 있는 '자가 회복 구조'를 갖추는 것이며, 이를 위해 데이터 보정 배치와 로깅 시스템 같은 안전장치를 반드시 고려해야 합니다.

mysql데이터베이스 설계Apache Kafka마이크로서비스+4

naver·2025년 11월 17일원문

6개월 만에 연간 수십조를 처리하는 DB CDC 복제 도구 무중단/무장애 교체하기 (새 탭에서 열림)

네이버페이는 차세대 아키텍처 개편 프로젝트인 'Plasma'의 최종 단계로, 연간 수십조 원의 거래 데이터를 처리하는 DB CDC 복제 도구인 'ergate'를 성공적으로 개발하여 무중단 교체했습니다. 기존의 복제 도구(mig-data)가 가진 유지보수의 어려움과 스키마 변경 시의 제약 사항을 해결하기 위해 Apache Flink와 Spring Framework를 조합한 새로운 구조를 도입했으며, 이를 통해 확장성과 성능을 동시에 확보했습니다. 결과적으로 백엔드 개발자가 직접 운영 가능한 내재화된 시스템을 구축하고, 대규모 트래픽 환경에서도 1초 이내의 복제 지연 시간과 강력한 데이터 정합성을 보장하게 되었습니다. ### 레거시 복제 도구의 한계와 교체 배경 * **유지보수 및 내재화 필요성:** 기존 도구인 `mig-data`는 DB 코어 개발 경험이 있는 인원이 순수 Java로 작성하여 일반 백엔드 개발자가 유지보수하거나 기능을 확장하기에 진입 장벽이 높았습니다. * **엄격한 복제 제약:** 양방향 복제를 지원하기 위해 설계된 로직 탓에 단일 레코드의 복제 실패가 전체 복제 지연으로 이어졌으며, 데이터 무결성 확인을 위한 복잡한 제약이 존재했습니다. * **스키마 변경의 경직성:** 반드시 Target DB에 칼럼을 먼저 추가해야 하는 순서 의존성이 있어, 작업 순서가 어긋날 경우 복제가 중단되는 장애가 빈번했습니다. * **복구 프로세스의 부재:** 장애 발생 시 복구를 수행할 수 있는 인원과 방법이 제한적이어서 운영 효율성이 낮았습니다. ### Apache Flink와 Spring을 결합한 기술 아키텍처 * **프레임워크 선정:** 저지연·대용량 처리에 최적화된 **Apache Flink(Java 17)**를 복제 및 검증 엔진으로 채택하고, 복잡한 비즈니스 로직과 복구 프로세스는 익숙한 **Spring Framework(Kotlin)**로 이원화하여 구현했습니다. * **Kubernetes 세션 모드 활용:** 12개에 달하는 복제 및 검증 Job을 효율적으로 관리하기 위해 세션 모드를 선택했습니다. 이를 통해 하나의 Job Manager UI에서 모든 상태를 모니터링하고 배포 시간을 단축했습니다. * **Kafka 기반 비동기 처리:** nBase-T의 binlog를 읽어 Kafka로 발행하는 `nbase-cdc`를 소스로 활용하여 데이터 유실 없는 파이프라인을 구축했습니다. ### 데이터 정합성을 위한 검증 및 복구 시스템 * **지연 컨슈밍 검증(Verifier):** 복제 토픽을 2분 정도 지연하여 읽어 들이는 방식으로 Target DB에 데이터가 반영될 시간을 확보한 뒤 정합성을 체크합니다. * **2단계 검증 로직:** 1차 검증 실패 시, 실시간 변경으로 인한 오탐인지 확인하기 위해 Source DB를 직접 재조회하여 Target과 비교하는 보완 로직을 수행합니다. * **자동화된 복구 흐름:** 일시적인 오류는 5분 후 자동으로 복구하는 '순단 자동 복구'와 배치 기반의 '장애 자동 복구', 그리고 관리자 UI를 통한 '수동 복구' 체계를 갖추어 데이터 불일치 제로를 지향합니다. ### DDL 독립성 및 성능 개선 결과 * **스키마 캐싱 전략:** `SqlParameterSource`와 캐싱된 쿼리를 이용해 Source와 Target의 칼럼 추가 순서에 상관없이 복제가 가능하도록 개선했습니다. Target에 없는 칼럼은 무시하고, 있는 칼럼만 선별적으로 반영하여 운영 편의성을 극대화했습니다. * **성능 최적화:** 기존 대비 10배 이상의 QPS를 처리할 수 있는 구조를 설계했으며, CDC 이벤트 발행 후 최종 복제 완료까지 1초 이내의 지연 시간을 달성했습니다. * **모니터링 강화:** 복제 주체(ergate_yn)와 Source 커밋 시간(rpc_time)을 전용 칼럼으로 추가하여 데이터의 이력을 추적할 수 있는 가시성을 확보했습니다. 성공적인 DB 복제 도구 전환을 위해서는 단순히 성능이 좋은 엔진을 선택하는 것을 넘어, **운영 주체인 개발자가 익숙한 기술 스택을 적재적소에 배치**하는 것이 중요합니다. 스트림 처리는 Flink에 맡기고 복잡한 복구 로직은 Spring으로 분리한 ergate의 사례처럼, 도구의 장점을 극대화하면서도 유지보수성을 놓치지 않는 아키텍처 설계가 대규모 금융 플랫폼의 안정성을 뒷받침합니다.

mysql쿠버네티스Apache KafkaKotlin+4

line·2025년 8월 1일원문

일 평균 30억 건을 처리하는 결제 시스템의 DB를 Vitess로 교체하기 - 2. 개발 및 운영기 (새 탭에서 열림)

LINE Billing Platform 팀은 일 평균 30억 건의 요청을 처리하는 대규모 결제 시스템을 운영하기 위해 기존 Nbase-T에서 Vitess로 성공적인 데이터베이스 마이그레이션을 수행했습니다. 이 글에서는 성능 문제와 개발 편의성을 고려해 gRPC 대신 MySQL 프로토콜을 선택한 과정과 효율적인 데이터 처리를 위한 샤딩 전략을 상세히 다룹니다. 또한 VTOrc와 Prometheus를 활용한 자동 복구 및 모니터링 체계를 구축하여 분산 데이터베이스 환경에서도 높은 안정성을 확보한 실무 노하우를 공유합니다. ### 프로토콜 선정 및 개발 환경 구축 * VTGate는 gRPC와 MySQL 프로토콜을 모두 지원하지만, gRPC 사용 시 `http2: frame too large` 에러와 CPU 오버헤드가 발생하여 최종적으로 MySQL 프로토콜을 채택했습니다. * Java 클라이언트 사용 시 gRPC 프로토콜은 쿼리 결과를 객체로 변환하는 과정이 번거롭고 Vitess 측에서도 현재 MySQL 프로토콜 사용을 권장하고 있습니다. * 익숙한 MySQL 프로토콜을 사용함으로써 기존 개발 경험을 유지하면서도 Vitess의 샤딩 기능을 안정적으로 활용할 수 있게 되었습니다. ### 키스페이스 설계 및 데이터 처리 방식 * 시스템은 크게 두 개의 키스페이스로 분리되어 있습니다. '글로벌 키스페이스'는 단일 샤드로 구성되어 자동 증가(Auto-increment)하는 샤딩 키를 관리합니다. * 실제 데이터가 저장되는 '서비스 키스페이스'는 N개의 샤드로 분산되어 있으며, 코인 잔액 및 충전/사용 내역 등의 데이터를 저장합니다. * 서비스 키스페이스는 'Hash Vindex'를 사용하여 데이터를 균등하게 분산하며, 애플리케이션이 쿼리에 샤딩 키를 포함하면 VTGate가 해당 샤드를 자동으로 특정해 효율적인 요청 처리가 가능합니다. ### MySQL 호환성 및 주요 기능 활용 * 트랜잭션 격리 수준은 단일 샤드일 경우 `REPEATABLE READ`, 다중 샤드일 경우 `READ COMMITTED`가 적용됩니다. * Vitess는 MySQL 프로토콜을 지원하지만 일부 쿼리 제약 사항이 존재하므로, `unsupported_cases.json`을 통해 사전에 호환성을 확인해야 합니다. * 분산 샤드 간 트랜잭션을 지원하는 'Two-Phase Commit(2PC)' 기능과 쿼리 실행 계획을 분석하는 'VEXPLAIN/VTEXPLAIN' 등을 통해 분산 환경의 제약을 보완하고 있습니다. ### 안정적인 운영을 위한 모니터링 및 장애 복구 * 자동 복구 도구인 'VTOrc'를 도입하여 토폴로지 서버와 VTTablet의 데이터를 기반으로 문제를 자동 감지하고 복구합니다. * Prometheus를 통해 VTOrc의 지표(Metrics)를 수집하며, 장애 발생 시 이메일과 Slack으로 알람이 전달되도록 구성했습니다. * VTAdmin 웹 UI를 활용해 복구 내역을 시각적으로 확인하고, `tablet_alias`를 통해 문제가 발생한 MySQL 노드를 즉각적으로 식별하여 운영 효율성을 높였습니다. 대규모 분산 환경에서 Vitess를 도입할 때는 성능과 유지보수를 위해 gRPC보다는 MySQL 프로토콜 사용을 우선적으로 고려하는 것이 좋습니다. 또한 단일 샤드와 다중 샤드 간의 트랜잭션 격리 수준 차이 및 쿼리 제약 사항을 면밀히 검토하여 애플리케이션 로직을 설계해야 하며, VTOrc와 같은 도구를 적극 활용하여 고가용성 운영 체계를 구축하는 것이 중요합니다.

mysql데이터베이스 설계grpcdatabase-migration+4

line·2025년 6월 18일원문

일 평균 30억 건을 처리하는 결제 시스템의 DB를 Vitess로 교체하기 - 1. 솔루션 선정기 (새 탭에서 열림)

LINE 결제 플랫폼 팀은 라이선스 비용 절감과 시스템 확장성 확보를 위해 기존 Nbase-T 시스템을 오픈소스 데이터베이스 클러스터링 솔루션인 Vitess로 마이그레이션하기로 결정했습니다. Apache ShardingSphere, TiDB 등 다양한 분산 DB 솔루션을 대상으로 성능과 운영 편의성을 비교 분석한 결과, 대규모 트래픽 환경에서 검증된 안정성과 고가용성을 제공하는 Vitess가 최종 후보로 선정되었습니다. 이번 과정은 결제 시스템이라는 특수성에 맞춰 서비스 중단 없는 전환과 물리 서버 환경에서의 최적화 가능성을 검증하는 데 주력했습니다. ### 후보 솔루션별 특징 및 제외 사유 * **Apache ShardingSphere**: 프락시(Proxy)와 JDBC 레이어 방식을 모두 지원하여 유연한 아키텍처 구성이 가능하지만, 데이터가 각 샤드에 고르게 분배되지 않을 경우 리샤딩(리밸런싱) 기능을 직접 구현해야 한다는 치명적인 단점이 있어 후보에서 제외되었습니다. * **TiDB**: MySQL 호환 분산 SQL DB로, SQL 계층(TiDB), 메타데이터 관리(PD), 행/열 기반 저장소(TiKV/TiFlash)로 분리된 구조를 가집니다. 샤딩키 설정 없이도 데이터를 자동 리밸런싱하여 운영 비용을 낮출 수 있다는 장점이 있어 유력한 후보로 PoC를 진행했습니다. * **Vitess**: YouTube에서 개발된 CNCF 프로젝트로, 샤딩 기술을 통해 수평 확장을 지원하며 베어 메탈 환경 설치가 가능해 결제 시스템에 필요한 높은 수준의 안정성을 확보할 수 있습니다. ### Vitess의 구조적 장점과 컴포넌트 역할 * **VTGate**: 클라이언트의 쿼리를 적절한 샤드로 라우팅하고 분산 트랜잭션을 처리하며, 애플리케이션에는 단일 DB처럼 보이도록 추상화 레이어를 제공합니다. * **VTTablet 및 VTorc**: 각 MySQL 인스턴스 앞에 위치하여 쿼리 실행과 복제를 관리하며, VTorc를 통해 장애 발생 시 자동으로 장애 조치(Failover)를 수행하여 고가용성을 유지합니다. * **토폴로지 서버**: ZooKeeper나 etcd를 활용해 클러스터의 구성 정보와 노드 상태를 중앙에서 관리함으로써 분산 환경의 일관성을 보장합니다. ### PoC를 통한 성능 및 운영 환경 검증 * **환경 일치화**: 실제 결제 시스템과 동일한 사양의 장비와 테이블 구조를 설정하여 Nbase-T, Vitess, TiDB 간의 성능 비교를 수행했습니다. * **성능 테스트 결과**: 순수 성능(TPS 및 CPU 효율) 관점에서는 기존 Nbase-T가 가장 우수했으나, Vitess 역시 대규모 요청 상황에서 안정적인 리소스 처리 능력을 보여주었습니다. * **유연한 설정**: Vitess는 필요에 따라 조회와 입력을 프라이머리와 레플리카로 분리하는 기능을 지원하며, 모든 DB 노드에 일괄적인 DDL 수행이 가능하여 관리 효율성이 높음을 확인했습니다. 결제와 같이 높은 신뢰성이 요구되는 시스템을 마이그레이션할 때는 단순한 쿼리 처리 성능뿐만 아니라 자동 장애 복구(Failover) 능력과 데이터 리샤딩의 용이성을 우선적으로 고려해야 합니다. Vitess는 글로벌 대형 서비스들에서 이미 안정성이 검증되었고, 베어 메탈 환경에서도 유연한 최적화가 가능하므로 대규모 MySQL 클러스터 운영이 필요한 조직에 강력히 추천되는 솔루션입니다.

mysqldatabase-migrationdatabase-shardinghigh-availability+4

datadog·2024년 5월 21일원문

엔지니어링 부문 VP 스포트라이트: 이보 디미트로프 (새 탭에서 열림)

데이터독(Datadog)의 엔지니어링 VP 이보 디미트로프(Ivo Dimitrov)는 30년 이상의 경력을 가진 베테랑으로서, 고성능 저수준 시스템 개발자에서 대규모 분산 시스템을 총괄하는 리더로 성장해 온 인물입니다. 그는 마이크로소프트와 링크드인에서 쌓은 대규모 스토리지 인프라 구축 경험을 바탕으로, 현재 데이터독에서 메트릭과 이벤트 플랫폼의 기술적 혁신을 이끌고 있습니다. 기술적 깊이와 조직적 비전 사이의 균형을 강조하는 그의 여정은 복잡한 데이터 시스템을 다루는 엔지니어와 관리자들에게 중요한 통찰을 제공합니다. ### 저수준 시스템 개발에서 엔지니어링 리더십으로의 전환 * 전기 공학 전공 중 실시간 운영체제(RTOS) 커널 기여를 통해 소프트웨어 개발에 입문했으며, 이후 10년간 C/C++ 기반의 고성능 시스템 프로그래밍에 집중했습니다. * 마이크로소프트의 Azure Blob Storage 초기 팀에서 근무하던 중 조직 개편을 계기로 관리직을 맡게 되었으며, 현장에서의 실무 교육과 멘토링을 통해 리더십 역량을 쌓았습니다. * 자신의 업무에만 집중하는 단계를 넘어 타인의 성장을 촉진하고 조직 간의 경계를 조율하는 '오너십(Ownership)'의 가치를 발견하며 매니지먼트의 매력을 느꼈습니다. ### 대규모 분산 스토리지 플랫폼 구축 경험 * 링크드인 재직 당시, 현재까지 전체 데이터셋의 95% 이상을 처리하는 독점 키-값(Key-Value) 저장소인 'Espresso'를 초기 단계에서 성숙한 플랫폼으로 성장시켰습니다. * 파생 데이터 서빙을 위한 'Venice', 오픈소스 블록 스토리지인 'Ambry', 클러스터 관리자인 'Helix' 등 인터넷 규모의 스토리지 인프라 프로젝트들을 주도했습니다. * 이러한 경험을 통해 대규모 레거시 환경의 제약에서 벗어나, 기술적 위험을 감수하고 빠르게 혁신할 수 있는 문화적 유연성의 중요성을 깨달았습니다. ### 데이터독의 분산 데이터 시스템과 기술적 지향점 * 현재 데이터독에서 메트릭(Metrics), 이벤트(Events), 로그 및 트레이스 등 반정형 데이터를 처리하는 분산 데이터 시스템 조직을 총괄하고 있습니다. * 온라인 분석 워크로드에 최적화된 특수 메인 메모리 데이터베이스인 'Driveline'을 통해 시계열 데이터 처리의 효율성을 극대화하고 있습니다. * 서로 다른 도메인별 API를 통합하는 '교차 플랫폼 쿼리(Cross-Platform Queries)' 팀을 운영하여, 고객과 엔지니어 모두가 통일된 인터페이스로 데이터에 접근할 수 있도록 추상화 계층을 구축 중입니다. * 전체 쿼리의 80% 이상을 차지하는 알람(Alerts) 플랫폼을 메트릭 및 이벤트 플랫폼과 통합하여 시스템의 일관성을 높이고 있습니다. **실용적인 제언** 개인 기여자(IC)에서 관리자로 전환할 때는 기술적 전문성을 포기하는 것이 아니라, 그 전문성을 바탕으로 조직의 비전을 설계하고 팀원들이 역량을 발휘할 수 있는 환경을 조성하는 데 집중해야 합니다. 특히 데이터독의 사례처럼 쿠버네티스(Kubernetes) 기반의 현대적 인프라와 실험을 장려하는 문화를 결합할 때, 기술적 부채를 최소화하면서도 폭발적인 성장을 뒷받침하는 시스템을 구축할 수 있습니다.

mysql데이터베이스 설계쿠버네티스PostgreSQL+4