▲

GN⁺: 무중단 Postgres 업그레이드

 (knock.app)
2P by neo 11달전 | favorite | 댓글 1개

Postgres 업그레이드를 위한 준비

  • 리스크 평가: 업그레이드 과정에서 발생할 수 있는 리스크 목록 작성 및 중요도에 따른 정렬.
  • 리스크 해결 방안 모색: 리스크를 완전히 제거하거나 시간에 걸쳐 분산시킬 수 있는 해결책 고려.
  • 리스크 목록 업데이트: 프로젝트 진행 중 새로운 리스크 발견 시 목록 갱신.

모니터링 및 메트릭스에 대하여

  • 시스템 모니터링: 데이터베이스와 시스템의 건강을 모니터링하기 위한 철저한 도구 사용.
  • 핵심 메트릭스 관찰: 트랜잭션 ID, CPU 사용량, 대기 세션, 쿼리 지연 시간, API 응답 지연 등 주요 메트릭스 모니터링.

Postgres 업그레이드 옵션

현장 업그레이드 (제로 다운타임 업그레이드에는 부적합)

  • 현장 업그레이드의 한계: AWS RDS에서 실행 시 데이터베이스 재부팅 필요, 데이터 양에 따라 시간 소요.

복제 기반 업그레이드

  • 복제 기반 업그레이드 선택: 점진적인 마이그레이션 단계, 실제 워크로드와 데이터로 새 데이터베이스 테스트, 업그레이드 제어력 확보.
  • 소스 및 대상 데이터베이스 설정: 복제 슬롯 설정, wal_level을 logical로 설정.

테이블 복제 방법 선택

"작은" 테이블 복제

  • 작은 테이블 복제: 간단한 추가와 구독 새로 고침으로 복제 가능.

큰, 추가 전용 테이블

  • 추가 전용 테이블 복제: copy_data 옵션을 false로 설정하여 미래 변경 사항만 복제 후, 백업에서 이전 데이터 백필.

많은 업데이트가 있는 큰 테이블

  • 업데이트가 많은 큰 테이블 복제: 테이블 크기 축소, VACUUM 실행, 테이블 파티셔닝 고려.

테이블 복제 상태 확인

  • 복제 상태 모니터링: pg_subscription_rel 시스템 테이블을 통해 복제 상태 확인, 한 번에 하나의 테이블 복제 권장.

복제 중단

  • 복제 중단 방법: 필요 시 테이블 복제 중단 및 구독 새로 고침으로 롤백 가능.

복제 슬롯 이전에 대한 주의

  • 복제 슬롯 이전 문제: 복제 슬롯의 LSN은 기본 데이터베이스에 고유하므로 새 데이터베이스로 직접 복사 불가.

마이그레이션 마무리

  • 테이블 일치성 검증: 두 데이터베이스 간 테이블 행 수 일치 확인, 필요 시 무작위 샘플링으로 데이터 일치성 검증.

애플리케이션 수준 변경

  • 데이터베이스 연결 변경: 애플리케이션을 새 데이터베이스에 연결하도록 변경, 트래픽 전환 전략 수립.

시퀀스에 대한 추가 사항

  • 시퀀스 동기화: 복제 과정에서 시퀀스 값 동기화되지 않으므로, 수동으로 시퀀스 값을 설정.

최종 점검 체크리스트

  • 최종 점검: 테이블 일치성, 구독 상태, 스키마 일치, 데이터베이스 크기, 복제본 추가, 인덱스 재구성, 성능 테스트, 리스크 평가, 스테이징 환경에서의 연습.

최종 전환

  • 최종 전환 실행: 저녁 시간대에 테이블 복제, 스테이징 환경에서 여러 번 연습 후, 최종 점검 및 플래그 전환.

GN⁺의 의견

  • 중요성: Knock은 제로 다운타임으로 Postgres 11.9에서 15.3으로 업그레이드하는 복잡한 과정을 성공적으로 수행함. 이는 데이터베이스 관리와 서비스 가용성에 중요한 이정표를 제시함.
  • 흥미로움: 복제 기반 업그레이드 접근법은 데이터베이스 관리자들에게 새로운 데이터베이스로의 부드러운 전환을 가능하게 하며, 이는 기술 커뮤니티에 큰 관심을 끌 수 있음.
  • 재미: Knock의 업그레이드 과정은 체계적인 리스크 관리와 문제 해결 과정을 통해 복잡한 기술적 도전을 극복하는 모범 사례를 보여줌.
▲
neo 11달전  [-]
Hacker News 의견

  • 대용량 테이블을 복사하는 것보다 더 나은 방법이 존재함.

    • 복제 슬롯 생성, 스냅샷 취득, 새 인스턴스로 스냅샷 복원, LSN 진행, 복제 시작으로 논리적 복제본을 만들 수 있음.
    • Instacart의 기사가 이 과정을 설명하고 있음.
    • 기사에 작은 오류가 있을 수 있지만, TB 크기 인스턴스를 업그레이드하는 데 여러 번 성공적으로 사용함.

  • 여기서 제시된 접근법은 흥미롭고 잘 문서화되어 있지만, "현대 고객은 100% 가용성을 기대한다"는 문장에 동의하지 않음.

    • 고객이나 공급자로서의 경험에 따르면, 가용성보다 일관성이 훨씬 중요함.
    • 벤더가 다운타임을 공지할 때 데이터를 신중하게 다루고 있다는 신호로 받아들여 안도감을 느낌.

  • AWS가 이제 블루-그린 배포를 지원함.

  • 대부분의 문제를 자동화하는 도구를 작성함.

    • 도구는 GitHub에서 공유되며, 피드백이나 아이디어를 통해 확장할 수 있음.

  • hava.io에서 AWS RDS PostgreSQL 11.13에서 15.5로 마이그레이션 중임.

    • pglogical을 사용한 단방향 복제 방식을 선택함.
    • 이 방식은 빠르지 않지만, 점진적으로 데이터베이스를 새 인스턴스로 복제하는 데 몇 일이 걸릴 수 있음.
    • 스토리지 유형과 크기를 변경하는 더 많은 자유를 제공함.

  • 어떠한 다운타임도 Knock 서비스에는 받아들일 수 없다는 주장에 의문을 표함.

    • 복잡한 시스템은 사고와 다운타임이 발생함.
    • 사전에 공지된 15분 다운타임은 대부분의 SaaS 비즈니스에 문제가 되지 않음.
    • 엔지니어링 시간을 제품 개발이나 개발 팀의 속도 향상에 투자하는 것이 사용자에게 더 만족을 줄 수 있음.
    • 데이터베이스 마이그레이션에서 "적은 다운타임"과 "제로 다운타임" 마이그레이션을 만드는 데 드는 작업량 차이가 큼.

  • 백업에서 복제를 초기화할 수 없다는 것에 놀람.

    • 기존 안정적인 DB 내용을 새 서버로 스트리밍하는 번거로움을 줄일 수 있었을 것임.
    • "제로 다운타임"이라고 하지만, 실제로는 새 서버로 전환하는 몇 초간의 다운타임이 있음.
    • 일관성 유지 방법에 대한 세부 사항이 누락됨.
    • 롤백 옵션에 대한 언급이 없으며, 대규모 데이터에 대한 일회성 이전 작업을 수행할 때는 항상 이전 단계로 되돌릴 계획이 필요함.

  • 데이터베이스 자격증명만 입력하면 제로 다운타임으로 Postgres 업데이트를 수행하는 올인원 도구에 관심이 있는지 물음.

  • 시퀀스 사용에 대한 것이 흥미로움.

    • 시퀀스 대신 주로 순차적 UUID나 HiLo 알고리즘을 사용함.

  • 분산 시스템에서 발생하는 문제는 적절한 sleep(1000)으로 해결할 수 있음을 농담으로 표현함.

    • Postgres는 DBA에게 친숙하지 않은 시스템이지만, 예전보다는 나아짐.
답변달기