AWS RDS 블루그린 배포 전 점검사항

은경·2024년 5월 8일

[AWS] RDS

목록 보기
4/5

🚀블루그린 배포 전 점검 사항 정리

💡 그린 생성 전


  • 신규 8.0버전에 적용할 파라미터 그룹을 미리 생성
    • SQL mode : NO_AUTO_CREATE_USER , ONLY_FULL_GROUP_BY 삭제
    • time zone : 기본값이 UTC로 설정된다고 함 → Asia/Seoul 적용 및 확인
    • 그 외 slow_query_log 등 기존 적용된 파라미터 그룹은 그대로 적용 할 예정
  • 인스턴스 수정 → 블루그린 생성
  • mysql 엔진 버전 8.0.3.6으로 변경
  • 파라미터 그룹을 신규로 생성한 파라미터 그룹으로 변경
  • 나머지 설정은 기존 인스턴스와 동일하게 설정

💡 블루/그린 전환하기 전


  • 그린 생성 시 default RDS CA 인증서가 최신버전으로 설정됨
    • 기존 서버가 구버전 rds-ca-2019을 사용하고 있으므로 인스턴스 수정에서 구 버전으로 변경
  • 모든 DB 인스턴스의 상태가 Available인지 확인.
  • 전환 시간대 확인
    • 전환 중 DB 쓰기가 차단되므로 블루 환경에서 트래픽이 가장 적고, batch 까지 고려한 시간대
  • 그린 환경의 Primary 인스턴스의 상태가 정상이고, 복제를 잘 수행하고 있는지 확인
  • 데이터 적재가 완료되었는지 확인. lazy loading을 막기 위해서는 → full scan
  • 중요한 워크로드의 경우 전환하기 전에 백업 DB 인스턴스를 프로비저닝하는 것이 좋음
  • 네트워크 및 클라이언트 구성으로 인해 DNS 캐시 TTL(Time-to-Live)이 RDS DNS 영역의 기본값인 5초 이상으로 늘어나지 않도록 해야 함 → 그렇지 않으면 애플리케이션은 전환 후에도 쓰기 트래픽을 블루 환경으로 전송하기 때문
  • DB 인스턴스에 다수의 연결이 있는 경우 전환하기 전에 애플리케이션에 필요한 최소한의 개수로 연결을 수동으로 줄이는 것이 좋음.
  • CloudWatch 지표 확인
    • ReplicaLag - 그린 환경의 현재 복제 지연을 식별. 가동 중지 시간을 줄이기 위해서 이 값이 0에 가까운지 확인
    • DatabaseConnections - 블루/그린 배포의 작업 수준을 예측하고 전환하기 전에 값이 배포에 적합한 수준인지 확인. 성능 개선 도우미가 활성화되어 있을 시 → DBLoad가 더 정확함
  • Deplyment 에서 수정 → 전환 버튼 클릭

💡 전환 후


  • 테스트 후 DB old 버전은 삭제 할 것 (비용 발생)
    • 스냅샷 생성되므로 스냅샷도 삭제 요망
  • 버전 업 총 소요 시간 체크

🚀 상용 DB에 적용 하기 전 점검사항

💡 시간적 조건


  • 서버 트래픽 및 데이터베이스에 I/O 작업이 적게 일어나는 시간
  • 서버에 돌고 있는 Scheduler 시간대와 겹치지 않는 시간
  • DB 엔진 업그레이드 후 이슈 발생 시 대응이 가능한 시간 및 날짜

💡 확인 할 수 있는 지표


  • CloudWatch 를 이용해 네트워크 트래픽 정보 확인
    • NetworkReceiveThroughput(DB 인스턴스 수신 네트워크 트래픽)
    • NetworkTransmitThroughput(DB 인스턴스 송신 네트워크 트래픽)
    • WritelOPS (초당 평균 디스크 쓰기 I/O 작업 수)
    • DBLoad (데이터베이스 활성 세션 수)
  • 기존 서버에 api call 수를 카운터 하는 API가 존재하므로 해당 API를 활용해 테이블 호출량 통계를 확인

💡 순단


  • 비교적 오래걸리는 사전작업(ex: green 데이터베이스 생성)은 전날 미리 셋팅 및 완료
    • 신규버전 DB 생성에 걸리는 시간: 약 50분
  • 당일 업데이트 시 신규DB ↔ 구DB 전환
    • 스테이징 환경 테스트 결과 데이터베이스 전환에 걸리는 시간 → 약 6분(메인 인스턴스 및 읽기전용 복제본 2개가 있으며 각 2분)
    • 읽기 불가 시간 : 거의 없음
    • 쓰기 불가 시간 : 약 2분 ~ 1분 또는 1분 이하
    • downtime 이 1분 이하로 발생하며 그동안 데이터베이스에 쓰기 작업이 불가능 하기 때문에 데이터 유실 가능성이 거의 없음.
profile
Python 서버 개발자

0개의 댓글