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·보안·백업 기능을 플랫폼 수준에서 제공하며, 신규 기능뿐 아니라 기존 시스템의 마이그레이션 경로까지 함께 설계하는 것이 중요합니다.

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

database-migration쿠버네티스infrastructure-as-codemysql+4

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

AI 지원 리팩토링을 활용해 실시간 라우팅 시스템을 마이그레이션한 방법

Datadog은 Stream Router의 기존 FoundationDB 기반 KV 모델이 트랜잭션 크기와 데이터 증가에 따른 한계에 도달하자, 운영 중단 없이 PostgreSQL·DuckDB 기반의 관계형 구조로 전환했습니다. 이 과정에서 Claude와 Cursor를 활용했지만, AI가 자율적으로 코드를 작성한 것이 아니라 사람이 새 스키마와 기존 구현, 실패 테스트를 제공하고 테스트 결과로 검증하는 방식으로 사용했습니다. 핵심 결론은 AI가 대규모 마이그레이션을 크게 가속할 수 있지만, 데이터 모델 설계와 안전성 판단은 여전히 사람의 전문성이 필요하다는 것입니다. ## Stream Router의 역할과 기존 아키텍처 - Datadog은 하루 100조 개가 넘는 이벤트를 처리하며, 각 메트릭 데이터를 올바른 Kafka 클러스터·토픽·파티션으로 라우팅해야 합니다. - Stream Router는 Kafka 메시지를 직접 생산하거나 소비하지 않고, 다른 서비스가 사용할 라우팅 결정을 관리하는 제어 평면 서비스입니다. - 라우팅 정보는 다음과 같은 용도로 사용됩니다. - Producer가 데이터를 기록할 위치 결정 - Querier가 데이터를 읽을 위치 결정 - 시간에 따른 데이터 위치 이력 관리 - 기존 구조는 쓰기와 읽기를 분리한 Eventually Consistent 아키텍처였습니다. - 쓰기 경로: FoundationDB의 키-값 모델 사용 - 읽기 경로: 주기적으로 생성된 스냅샷을 RocksDB와 메모리 데이터베이스에 적재 - Producer와 Querier는 쓰기 경로에 직접 접근하지 않음 ## 설정 파일에서 중앙 제어 평면으로의 발전 - 2016년에는 몇 줄짜리 설정 파일을 모든 서비스에 배포해 라우팅을 관리했습니다. - 인프라와 고객 규모가 커지면서 설정 파일이 수천 줄로 증가했고, 수동 편집과 배포가 운영 부담이 되었습니다. - Stream Router 도입 후에는 다음과 같이 개선되었습니다. - 설정 파일 대신 gRPC API로 라우팅 변경 - 자동화된 오케스트레이션 - 점진적이고 자동화된 롤아웃 - 고가용성과 장애 내성을 고려한 읽기·쓰기 분리 ## KV 모델의 확장 한계 - 라우팅 데이터는 단순한 키-값 목록이 아니라 서로 연결된 관계형 데이터였습니다. - Route는 특정 Kafka Stream을 참조 - Route는 Sharding Strategy를 참조 - Rule은 Route를 참조하고 활성화 시점과 적용 방식을 결정 - 기존 KV 구조에서는 데이터베이스가 제공해야 할 관계 검증을 애플리케이션이 직접 수행해야 했습니다. - 수만 개의 레코드를 Pod 프로세스로 가져옴 - 애플리케이션 내부에서 관계형 데이터베이스처럼 조인과 일관성 검사를 수행 - 데이터와 변경 규모가 커지면서 FoundationDB 트랜잭션 크기 제한에 걸리는 작업이 발생했습니다. - FoundationDB를 PostgreSQL로 단순 교체하는 방안도 해결책이 되지 못했습니다. - 기존 KV 접근 패턴을 그대로 유지하면 수천 번의 순차적인 데이터베이스 왕복이 필요 - 일부 작업은 약 45분이 걸릴 것으로 예상 - 따라서 병목의 원인은 특정 데이터베이스가 아니라, KV에 맞춰진 데이터 모델과 애플리케이션 로직 자체였습니다. ## 관계형 스키마로 재설계 - 팀은 AI를 사용하기 전에 도메인 관계를 직접 분석하고 새 스키마를 설계했습니다. - 관계형 구조에서는 다음 관계를 외래 키로 명시합니다. - Streams와 Sharding Strategies → Routes - Routes → Rules - 기존 애플리케이션 코드가 수동으로 복원하던 관계를 데이터베이스가 직접 표현하고 검증할 수 있게 되었습니다. - 쓰기 경로에는 PostgreSQL을 선택했습니다. - 관계형 의미론 지원 - 트랜잭션 처리 - Datadog의 자체 관리형 PostgreSQL 플랫폼 활용 가능 - 읽기 경로에는 DuckDB를 선택했습니다. - 스냅샷 기반 읽기 계층에 적합한 임베디드 데이터베이스 - 배열 컬럼을 기본 지원 - PostgreSQL과 유사한 SQL 문법 - PostgreSQL과 DuckDB 사이에서 쿼리 로직을 공유할 수 있음 - SQLite도 검토했지만 배열 컬럼을 기본 지원하지 않아 적합하지 않았습니다. ## AI를 활용한 테스트 중심 리팩터링 - Claude와 Cursor는 코드를 독립적으로 생성하도록 맡기지 않았습니다. - 각 메서드마다 사람이 다음 정보를 제공했습니다. - 기존 구현 - 새 데이터베이스 스키마 - 현재 실패하는 테스트 - AI는 이를 바탕으로 첫 번째 구현을 만들었고, 테스트가 코드의 정확성을 검증했습니다. - 이 방식의 장점은 다음과 같습니다. - 전체 마이그레이션을 한 번에 생성하지 않고 메서드 단위로 분할 - 실패 테스트가 요구사항과 오류를 구체적으로 제시 - 생성 코드가 실제 동작과 데이터 관계를 만족하는지 즉시 확인 - 사람이 설계와 판단을 담당하고 AI는 반복적인 변환 작업을 가속 ## 안전한 마이그레이션을 가능하게 한 조건 - 마이그레이션이 성공할 수 있었던 기반은 AI보다 기존 시스템의 구조와 개발 프로세스였습니다. - 특히 저장소 계층이 `Controller`라는 내부 인터페이스 뒤에 모듈화되어 있었습니다. - 이러한 추상화 덕분에 저장 엔진과 구현을 교체하더라도 상위 계층의 변경 범위를 줄일 수 있었습니다. - 글의 제공된 부분은 안전성을 뒷받침한 요소를 설명하는 도중 끝나므로, 이후 테스트 전략이나 실제 전환 절차의 상세 내용은 포함되어 있지 않습니다. 결국 AI는 관계형 스키마를 설계하거나 운영 위험을 판단하는 도구라기보다, 명확한 설계와 테스트가 준비된 상태에서 반복적인 코드 변환을 빠르게 수행하는 도구로 활용하는 것이 적절합니다. 대규모 운영 시스템에서는 먼저 데이터 모델과 인터페이스를 사람이 설계하고, 작은 단위의 실패 테스트를 기준으로 AI 생성 코드를 검증하는 방식을 추천할 수 있습니다.

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

database-migration데이터베이스 설계PostgreSQLApache Kafka+4

slack·2026년 3월 19일·3분 읽기큐레이션 요약

슬랙이 알림 기능을 어떻게 다시 만들었나 📣

Slack은 알림이 많아서가 아니라 사용자가 알림 설정을 이해하고 통제하기 어려워서 “소음”을 느낀다고 진단했다. 이에 데스크톱과 모바일의 서로 다른 설정 체계를 하나의 모델로 통합하고, 활동 알림과 푸시 알림을 분리했다. 레거시 호환성과 롤백 가능성을 고려한 읽기 시점 마이그레이션, 자동 저장, 클라이언트 간 상태 동기화를 통해 더 예측 가능하고 차분한 알림 경험을 구축했다. ## 알림 소음의 근본 원인 - Slack에서 알림 과부하는 고객 불만의 주요 원인이며, 고객 경험 관련 문의의 상위 3개 요인에 포함됐다. - 참여한 채널 수가 많을수록 사용자는 알림 동작을 더 혼란스럽고 압도적으로 느꼈다. - 문제는 단순히 알림의 양이 아니라, 여러 해에 걸쳐 누적된 레거시 아키텍처에도 있었다. - 데스크톱과 모바일이 서로 다른 선호도 모델을 사용했다. - 모바일의 `nothing`과 데스크톱의 `Off`가 같은 의미가 아니었다. - 설정을 바꿔도 실제 결과를 예측하기 어려웠다. - 알림 대상과 전달 방식이 강하게 결합되어 있었다. - 푸시 알림을 줄이면 인앱 활동 확인까지 포기해야 했다. - 클라이언트 간 설정 동기화가 불안정해 데스크톱과 모바일에서 서로 다른 알림이 발생하거나 설정을 반복해야 했다. - 고급 기능이 여러 메뉴에 흩어져 있어 파워 유저도 전체 설정 구조를 파악하기 어려웠다. ## 하나의 알림 모델로 통합 Slack은 UI만 개편하지 않고 알림의 동작 방식 자체를 재설계했다. - 채널 알림을 세 가지 선택지로 단순화했다. - 모든 새 게시물 - 멘션 - 음소거 - 데스크톱과 모바일의 푸시 알림을 독립적인 켜기/끄기 옵션으로 통합했다. - 모바일에도 “모든 읽지 않은 항목 배지 표시” 같은 고급 제어 기능을 제공했다. - 데스크톱과 모바일의 전역 설정 구조와 문구를 일관되게 정비했다. - 단순화된 선호도 로직을 사용해 여러 클라이언트에서 동일한 상태를 유지하도록 개선했다. ## 선호도 데이터 마이그레이션 기존에는 데스크톱과 모바일 설정이 각각 알림 대상과 푸시 전달을 함께 결정했다. ```text 기존 desktop: everything | mentions | nothing mobile: everything | mentions | nothing ``` 새 모델에서는 활동과 푸시를 분리했다. ```text 변경 후 desktop: everything | mentions desktop_push_enabled: true | false mobile: everything | mentions | nothing ``` - 데스크톱의 `desktop_push_enabled`를 새로 도입해 푸시 알림만 별도로 제어했다. - 기존 사용자의 데이터베이스 값을 일괄적으로 직접 변경하지 않았다. - 잘못된 마이그레이션이나 롤백 문제를 피하기 위한 선택이다. - 새 설정을 기존 값에 기반해 백필했다. - 읽기 시점에 레거시 `Off`를 새로운 의미의 `Mentions + 푸시 비활성화`로 해석했다. - 사용자는 기존과 동일한 경험을 유지하면서도 새로운 분리형 알림 구조를 사용할 수 있었다. - 결과적으로 인앱 배지와 활동 알림은 계속 확인할 수 있고, 실제 방해가 되는 푸시만 별도로 끌 수 있게 됐다. ## 자동 저장과 “무엇을 받을지”와 “어떻게 받을지”의 분리 기존 알림 모달은 변경할 때마다 사용자가 `Save` 버튼을 눌러야 했다. - 저장을 잊으면 설정이 적용되지 않아 사용자가 알림 시스템이 고장 났다고 오해할 수 있었다. - 새 모달은 자동 저장을 적용해 변경 즉시 설정이 반영된다. - 알림 설정을 다음 두 축으로 분리했다. - 어떤 활동을 받을 것인가 - 어떤 방식으로 전달받을 것인가 - 예를 들어 모든 활동을 인앱에서 확인하되, 푸시는 멘션에 대해서만 받는 구성이 가능해졌다. - 데스크톱과 모바일 UI에는 재사용 가능한 React 컴포넌트를 활용해 일관성을 높였다. - 기존 모바일 전용 레거시 UI 코드도 대체해 플랫폼별 동작 차이를 줄였다. ## 크로스플랫폼 일관성 - 프로젝트는 수백 개의 댓글이 달린 기술 논의와 제품·디자인·프론트엔드·백엔드·모바일 팀 간 조율을 필요로 했다. - 핵심 목표는 단순히 같은 화면을 만드는 것이 아니라, 어떤 클라이언트에서 설정해도 동일한 상태와 의미를 갖게 하는 것이었다. - 이 구조를 통해 사용자는 데스크톱에서 바꾼 설정이 모바일에서 다르게 동작하는 문제를 덜 겪게 됐다. Slack의 접근 방식은 알림을 무조건 줄이는 대신, 활동 알림과 푸시 알림을 분리하고 설정 의미를 명확히 하는 데 초점을 둔다. 비슷한 시스템을 설계할 때도 레거시 값을 즉시 덮어쓰기보다 읽기 시점 호환성, 점진적 백필, 독립적인 설정 축, 자동 저장을 활용하는 것이 안전하고 사용자 혼란도 줄일 수 있다.

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

database-migrationReactstate-managementcross-platform-development+1

netflix·2026년 2월 12일원문

RDS Postgres에서 Aurora Postgres로의 마 (새 탭에서 열림)

넷플릭스는 기능성, 성능 및 총소유비용(TCO)을 종합적으로 검토한 결과, 사내 관계형 데이터베이스 표준을 Amazon Aurora PostgreSQL로 전환하기로 결정했습니다. 약 400개에 달하는 기존 RDS PostgreSQL 클러스터를 효율적으로 이전하기 위해 넷플릭스는 가동 중지 시간을 최소화하고 데이터 무결성을 보장하는 자동화된 셀프 서비스 마이그레이션 워크플로우를 구축했습니다. 이를 통해 개별 서비스 팀은 운영 부담 없이 클라우드 네이티브 아키텍처의 확장성과 고가용성 이점을 누릴 수 있게 되었습니다. ### Aurora PostgreSQL 표준화 배경 * **높은 호환성:** 내부 분석 결과, 기존 관계형 데이터베이스에서 실행되는 애플리케이션의 95% 이상이 Aurora PostgreSQL 환경에서 원활하게 지원됨을 확인했습니다. * **클라우드 네이티브 이점:** 전통적인 단일 노드 PostgreSQL에 비해 확장성, 고가용성 및 탄력성 측면에서 Aurora의 분산 아키텍처가 월등한 우위를 점하고 있습니다. * **생태계 및 로드맵:** 강력한 커뮤니티 지원을 받는 PostgreSQL의 오픈 생태계와 대규모 글로벌 분산 애플리케이션에 최적화된 Aurora의 기능 로드맵이 결정적인 요인이 되었습니다. ### 대규모 마이그레이션의 운영 및 기술적 과제 * **운영의 규모 가변성:** 400개에 가까운 클러스터를 수동으로 이전하는 것은 인적 오류의 위험이 크고 운영 팀에 과도한 부담을 주므로, 자동화된 셀프 서비스 방식이 필수적이었습니다. * **데이터 무결성 및 가동 중지 최소화:** '제로 데이터 손실'을 보장하는 동시에, 서비스 신뢰도에 영향을 주지 않도록 쓰기 트래픽을 중단하고 전환하는 시간을 극도로 짧게 유지해야 합니다. * **제어 권한의 한계:** 플랫폼 팀은 데이터베이스를 관리하지만 클라이언트 애플리케이션의 동작(쓰기 일시 중단 등)을 직접 제어할 수 없으며, 보안상 사용자 데이터베이스의 자격 증명(Credentials)에 직접 접근하지 않고 마이그레이션을 수행해야 하는 제약이 있습니다. * **생태계 패리티 유지:** 핵심 데이터뿐만 아니라 파라미터 그룹, 읽기 전용 복제본(Read Replica), 복제 슬롯 등 연관된 모든 구성 요소를 동일하게 이전해야 성능 저하를 방지할 수 있습니다. ### AWS 권장 마이그레이션 기법의 활용 * **스냅샷 기반 마이그레이션:** RDS PostgreSQL의 수동 스냅샷을 생성하여 Aurora로 변환하는 방식으로, 구조는 단순하지만 스냅샷 생성부터 완료 시까지 쓰기 트래픽을 중단해야 하므로 가동 중지 시간이 길다는 단점이 있습니다. * **Aurora 읽기 전용 복제본 기반 마이그레이션:** 기존 RDS를 소스로 하는 Aurora 읽기 복제본을 생성하여 비동기 복제를 수행합니다. 복제 지연(Lag)이 충분히 낮아졌을 때 짧은 순간만 트래픽을 중단하고 복제본을 승격(Promote)시키므로, 스냅샷 방식보다 가동 중지 시간을 현저히 줄일 수 있습니다. ### 성공적인 전환을 위한 전략적 결론 대규모 데이터베이스 마이그레이션은 단순한 데이터 복사를 넘어 복제, 정지(Quiescence), 검증, 전환의 정교한 조율이 필요합니다. 넷플릭스의 사례처럼 데이터베이스 전문가가 아닌 서비스 담당자도 쉽고 안전하게 마이그레이션을 수행할 수 있도록 자동화된 컨트롤 플레인을 구축하는 것이 대규모 인프라 현대화의 핵심입니다. 특히 가동 중지 시간에 민감한 서비스라면 AWS의 읽기 전용 복제본 승격 방식을 자동화 워크플로우에 통합하는 것이 가장 권장되는 접근법입니다.

database-migration데이터베이스 설계PostgreSQLAWS+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를 교체해야 할 때, 코드 수정을 최소화하면서도 서비스 안정성을 최우선으로 고려하는 개발자들에게 실무적인 가이드라인을 제공합니다. 특히 트랜잭션 동기화와 프록시 패턴을 활용한 중앙 집중식 제어는 복잡한 시스템 마이그레이션의 위험 부담을 낮추는 핵심 기술 요소입니다.

database-migrationmysqlzero-downtime-migrationjpa+4

airbnb·2025년 9월 24일원문

에어비앤비의 차세대 (새 탭에서 열림)

에어비앤비는 기존의 키-값(Key-Value) 저장소인 Mussel v1의 운영 복잡성과 확장성 한계를 극복하기 위해, NewSQL 백엔드 기반의 Mussel v2로 아키텍처를 전면 재설계했습니다. 새로운 시스템은 쿠버네티스 네이티브 환경에서 대규모 벌크 로드와 실시간 스트리밍 처리를 동시에 지원하며, 한 자릿수 밀리초 단위의 읽기 성능을 안정적으로 제공합니다. 결과적으로 에어비앤비는 데이터 일관성 제어권 확보와 비용 투명성 강화는 물론, 미션 크리티컬한 서비스들을 중단 없이 성공적으로 마이그레이션하는 성과를 거두었습니다. ### v1의 한계와 재설계 배경 * **운영 복잡성:** EC2와 Chef 스크립트에 의존했던 v1은 노드 확장이나 교체에 수 시간이 소요되었으나, v2는 쿠버네티스 매니페스트를 통한 자동화로 이를 수 분 이내로 단축했습니다. * **데이터 핫스팟:** 정적 해시 파티셔닝(Static Hash Partitioning) 방식은 특정 노드에 부하가 쏠리는 문제를 야기했으나, v2는 동적 범위 샤딩(Dynamic Range Sharding)을 도입하여 100TB 이상의 테이블에서도 안정적인 지연 시간을 유지합니다. * **가시성 부족:** 리소스 사용량이 불투명했던 과거와 달리, v2는 네임스페이스별 테넌시 관리와 쿼터 할당, 대시보드를 통해 비용 통제력을 높였습니다. ### Mussel v2의 핵심 아키텍처 * **Dispatcher:** 상태가 없는(Stateless) 쿠버네티스 서비스로, 클라이언트의 API 호출을 백엔드 쿼리로 변환하며 이중 쓰기(Dual-write)와 섀도우 리드(Shadow-read)를 관리합니다. * **이벤트 기반 쓰기:** 모든 쓰기 작업은 내구성을 위해 Kafka에 먼저 기록된 후 Replayer를 통해 백엔드에 반영되어, 트래픽 급증을 유연하게 흡수하고 일관성을 보장합니다. * **읽기 최적화:** 논리적 테이블 매핑을 통해 포인트 룩업, 범위 쿼리, 접두사 쿼리를 최적화하며, 지연 시간을 줄이기 위해 로컬 복제본으로부터의 읽기(Stale Read) 기능을 제공합니다. ### 벌크 로드 및 데이터 만료(TTL) 시스템 * **고성능 인입:** S3에 업로드된 대규모 데이터를 쿠버네티스 워커 플릿이 병렬로 처리하여 기존 테이블에 병합하거나 교체하는 벌크 로드 프로세스를 최적화했습니다. * **토폴로지 인지형 TTL:** 데이터 범위를 서브 태스크로 나누어 병렬로 스캔하고 삭제하는 서비스를 도입하여, 대규모 데이터셋에서도 라이브 쿼리에 영향을 주지 않고 효율적으로 스토리지를 관리합니다. ### 무중단 마이그레이션 전략 * **Blue/Green 방식 적용:** 기존 v1에 CDC(Change Data Capture) 기능이 부족했음에도 불구하고, Kafka 스트림을 활용한 맞춤형 파이프라인을 구축해 v1과 v2 간의 최종 일관성을 유지했습니다. * **단계적 전환:** 모든 트래픽을 v1으로 보내는 단계부터 v2에서 성능을 검증하는 섀도우 단계, v2를 주 저장소로 사용하는 리버스 단계를 거쳐 최종 컷오버(Cutover)를 진행했습니다. * **안정성 장치:** 테이블 단위로 마이그레이션을 수행하고 자동 서킷 브레이커와 즉시 롤백 로직을 구현하여, 데이터 손실이나 서비스 중단 없이 100개 이상의 유스케이스를 이전했습니다. 성공적인 저장소 엔진 교체는 단순히 성능 향상에 그치지 않고, 운영 자동화와 유연한 확장성을 통해 비즈니스 요구사항에 기민하게 대응할 수 있는 기반을 마련해 줍니다. 특히 대규모 데이터 마이그레이션 시 Kafka를 중간 매개체로 활용하고 단계별 검증 과정을 거치는 전략은 시스템 안정성을 확보하는 데 필수적인 요소입니다.

database-migration쿠버네티스Apache Kafkaapache-airflow+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와 같은 도구를 적극 활용하여 고가용성 운영 체계를 구축하는 것이 중요합니다.

database-migration데이터베이스 설계grpcmysql+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 클러스터 운영이 필요한 조직에 강력히 추천되는 솔루션입니다.

database-migrationmysqldatabase-shardinghigh-availability+4