▲

GN⁺: 11초의 다운타임으로 PostgreSQL 데이터베이스를 마이그레이션 완료

 (gds.blog.gov.uk)
2P by neo 10달전 | favorite | 댓글 1개

PostgreSQL 데이터베이스 마이그레이션 방법

  • GOV.UK Notify는 현재 사용 중인 PaaS가 폐지됨에 따라 모든 인프라를 자체 AWS 계정으로 이전 중임.
  • 이 글에서는 PostgreSQL 데이터베이스를 최소한의 다운타임으로 마이그레이션한 방법을 설명함.

데이터베이스 마이그레이션

  • PaaS에서 제공하는 AWS RDS PostgreSQL 데이터베이스를 사용하고 있으며, 이를 자체 AWS 계정의 새 데이터베이스로 이전해야 함.
  • 새로운 PostgreSQL 데이터베이스를 설정하고 모든 앱이 새 데이터베이스와 통신하도록 하는 것이 주요 과제임.

소스 데이터베이스에 대한 추가 정보

  • 소스 데이터베이스는 약 400GB 크기이며, 1.3억 개의 행, 85개의 테이블, 185개의 인덱스, 120개의 외래 키를 가지고 있음.
  • 평일에는 초당 약 1,000건의 삽입 또는 업데이트가 이루어지며, GOV.UK Notify는 매일 수백만 개의 중요하고 시기적절한 알림을 전송함.

AWS 데이터베이스 마이그레이션 서비스

  • AWS 데이터베이스 마이그레이션 서비스(DMS)를 사용하여 소스 데이터베이스에서 타겟 데이터베이스로 데이터를 전송함.
  • DMS는 '전체 로드' 작업을 통해 특정 시점까지의 모든 데이터를 복사하고, 복제 모드에서는 소스 데이터베이스의 모든 새로운 트랜잭션이 타겟 데이터베이스에 반영되도록 함.

데이터베이스 마이그레이션 과정

DMS 인스턴스 설정

  • 소스 AWS 계정에서 DMS 인스턴스를 생성하고, 소스 및 타겟 데이터베이스 모두에 접근할 수 있는 PostgreSQL 자격 증명을 부여함.

타겟 데이터베이스 설정

  • 자체 AWS 계정에 타겟 RDS 인스턴스를 생성하고, PostgreSQL 버전을 15로 업그레이드함.
  • pg_dump를 사용하여 소스 데이터베이스 스키마를 덤프하고, 타겟 데이터베이스에 테이블 선언을 적용함.

전체 로드

  • 타겟 데이터베이스에 테이블을 생성한 후, DMS 전체 로드 작업을 시작하여 약 6시간 만에 완료함.
  • 전체 로드 작업이 완료된 후, 인덱스와 키 제약 조건을 추가함.

복제

  • 전체 로드 작업이 완료된 후, DMS 지속적인 복제(변경 데이터 캡처) 작업을 시작하여 소스 데이터베이스와 타겟 데이터베이스를 동기화함.

트래픽 마이그레이션 준비

  • 앱이 소스 데이터베이스와의 통신을 중단하고 타겟 데이터베이스와 통신하도록 하는 과정을 계획함.

소스 데이터베이스로의 트래픽 중단

  • 스크립트를 사용하여 소스 데이터베이스로의 모든 트래픽을 중단함.

복제 확인

  • 타겟 데이터베이스가 완전히 동기화되었는지 확인함.

트래픽의 원활한 전환

  • 앱이 데이터베이스에 연결하기 위해 필요한 위치, 사용자 이름, 비밀번호를 환경 변수에 제공하고, DNS 변경을 통해 빠르게 데이터베이스를 전환함.

마이그레이션 당일 발생한 사항

  • 마이그레이션 스크립트를 성공적으로 실행하여 앱이 소스 데이터베이스와의 통신을 중단하고 새 타겟 데이터베이스와 통신하도록 함.
  • 마이그레이션 중 약 11초의 짧은 다운타임이 발생함.

배운 점

  • DMS를 사용한 이유는 GOV.UK PaaS에서 잘 지원되었기 때문이며, AWS의 지원도 받을 수 있었음.
  • 향후 PostgreSQL 간 데이터베이스 마이그레이션을 수행할 경우, pglogical과 같은 다른 도구를 시도하는 데 더 많은 시간을 투자할 것임.

GOV.UK Notify의 AWS로의 마이그레이션 다음 단계

  • 데이터베이스 마이그레이션이 완료된 후, 앱을 AWS Elastic Container Service(ECS)로 이전할 예정임.

GN⁺의 의견:

  • 이 글에서 가장 중요한 것은 GOV.UK Notify 팀이 AWS 데이터베이스 마이그레이션 서비스(DMS)를 사용하여 PostgreSQL 데이터베이스를 성공적으로 이전했다는 점임.
  • 이 글은 데이터베이스 마이그레이션을 계획하는 기술 전문가들에게 실제 사례를 통한 유용한 지침을 제공함.
  • 마이그레이션 과정에서 발생할 수 있는 다운타임을 최소화하는 방법과 데이터 일관성을 유지하는 전략에 대한 통찰력을 제공하여, 비슷한 상황에 직면한 다른 조직이나 개인들에게 도움이 될 수 있음.
▲
neo 10달전  [-]
Hacker News 의견

  • 정부가 AWS를 사용하는 이유에 대해 의문을 제기하며, 공공 부문 클라우드를 구축하거나 온프레미스(on-prem) 접근 방식을 채택해 장기적으로 세금 낭비를 줄일 수 있다고 주장함.

    "정부가 AWS를 사용하는 것에 대해 의문이 있음. 공공 부문 클라우드 구축이나 온프레미스 접근 방식이 장기적으로 세금을 절약할 수 있을 것."

  • AWS RDS 블루-그린 배포를 사용하여 약 20초의 다운타임으로 데이터베이스 마이그레이션을 성공적으로 수행했다고 경험을 공유함.

    "AWS RDS 블루-그린 배포를 통해 약 20초의 다운타임으로 데이터베이스 마이그레이션을 성공적으로 수행한 경험 공유."

  • PostgreSQL 쿼리를 일시 중지하는 다양한 방법을 언급하며, 복제가 따라잡을 때까지 쿼리를 지연시키는 방법으로 다운타임을 줄일 수 있다고 설명함.

    "PostgreSQL 쿼리를 일시 중지하여 복제가 따라잡을 때까지 지연시키는 방법으로 다운타임을 줄일 수 있음."

  • 자체 호스팅된 PostgreSQL 데이터베이스를 버전 12에서 16으로 마이그레이션하는 과정을 설명하고, 예상치 못한 문제로 인해 다운타임이 약 30분 발생했다고 공유함.

    "PostgreSQL 데이터베이스를 버전 12에서 16으로 마이그레이션하는 과정에서 예상치 못한 문제로 인해 약 30분의 다운타임 발생."

  • AWS 데이터 마이그레이션 서비스를 사용하여 11초의 다운타임을 감수하고 DNS 항목을 교체하는 것이 복잡성을 피하는 방법이라고 언급함.

    "AWS 데이터 마이그레이션 서비스 사용과 DNS 항목 교체로 11초의 다운타임을 감수하는 것이 복잡성을 피하는 방법."

  • 긴 실행 시간을 가진 쿼리가 저다운타임 마이그레이션의 적이라고 지적하며, 이러한 쿼리를 처리하는 방법에 대한 어려움을 설명함.

    "긴 실행 시간을 가진 쿼리가 저다운타임 마이그레이션의 어려움을 초래함."

  • PostgreSQL 14에서 16으로의 마이그레이션 과정을 공유하며, 다음 번에는 AWS 블루-그린 배포를 사용하여 다운타임을 피할 계획이라고 언급함.

    "PostgreSQL 14에서 16으로의 마이그레이션 과정 공유 및 다음 번에는 AWS 블루-그린 배포를 사용할 계획."

  • AWS Route53의 DNS 레코드를 사용하여 데이터베이스 마이그레이션 스크립트가 DNS 가중치를 업데이트하고 1초의 TTL이 만료되기를 기다리는 방법을 설명함.

    "AWS Route53의 DNS 레코드를 활용하여 데이터베이스 마이그레이션 스크립트가 DNS 가중치를 업데이트하고 TTL 만료를 기다리는 방법 설명."

  • Amazon이 '정부-서비스' 제품을 출시할 것을 기대하는 농담을 함.

    "Amazon이 '정부-서비스' 제품을 출시하기를 기대하는 농담."

  • AWS DMS를 사용하여 AWS RDS MySQL에서 RDS PostgreSQL로 데이터셋을 마이그레이션하는 경험을 공유하고, 스키마 변환 도구 사용을 권장하지 않음.

    "AWS DMS를 사용한 AWS RDS MySQL에서 RDS PostgreSQL로의 데이터셋 마이그레이션 경험 공유 및 스키마 변환 도구 사용 비권장."

답변달기