5.2 마이그레이션과 성능 리허설
Migration이 작은 시험 DB에서 성공했다는 결과만으로 운영 적용 시간을 정하기는 어렵습니다. 운영 규모의 데이터에서 확인할 항목을 먼저 정합니다. 변경 전후는 같은 조건에서 비교해야 합니다. 이 장에서는 검증 결과를 항목별로 구분하는 시험 설계를 제안합니다. 실행 가능성, 실행 계획, 처리 시간, lock 대기, 저장량을 각각 검증합니다. 단일 성공 표시만으로 모든 운영 위험을 검토했다고 판단하지 않습니다.
GitLab의 DBLab 파이프라인과 Joe bot은 이런 검증을 개발과 운영 절차에 연결한 공개 사례입니다. Zendesk의 Aurora clone 활용도 같은 목적의 공개 사례입니다. 각 사례가 확인하는 범위를 소개한 뒤, DBA가 자체 환경에 적용할 시험 절차를 구성합니다. 부하 측정 항목과 실행 순서, 중단 기준은 이 장의 제안입니다. 고객사의 비공개 운영 정책을 재구성한 내용은 아닙니다.
적용 계층과 제품
GitLab의 파이프라인과 Joe bot
GitLab은 DBLab을 운영 규모 데이터의 query와 migration 검증에 사용합니다. Migration 테스트는 MR의 작업에서 별도 파이프라인을 시작하고 결과를 MR에 연결합니다. 공식 개발 문서는 테스트 상태가 성공해야 머지가 가능하다고 설명합니다. 실행 권한과 불필요한 실행 제한도 명시합니다. 고객 자체 운영 문서이므로 사례 신뢰도는 높음입니다. GitLab의 모든 CI 작업이 DBLab을 사용한다는 의미는 아닙니다. Migration pipeline
Joe bot은 복제한 운영 데이터에서 query를 실행하는 경로입니다. 실행 시간과 buffer 정보도 확인합니다. GitLab 문서에는 clone에서 schema 변경을 시험한 뒤 실행 계획을 비교하는 절차도 있습니다. 기준 데이터에는 갱신 지연이 있으므로 현재 운영 상태와 같은 시점으로 가정하지 않습니다. 이 사례도 고객 자체 문서에 근거하며 신뢰도는 높음입니다. Database Lab과 Joe bot
두 경로의 사용 목적을 나누는 구성을 제안합니다. MR 파이프라인에는 변경 파일과 판정 결과를 연결합니다. 탐색적인 query 튜닝에는 실험별 실행 계획과 입력 조건을 남깁니다. 개발자가 찾은 인덱스나 query 수정안이 배포 대상이 되면 공식 시험 절차를 다시 거칩니다. 이때 해당 migration을 시험합니다. 탐색 중 얻은 빠른 실행 결과만으로 운영 적용을 승인하지 않습니다.
수집 사본과 관리형 clone
DBLab은 파일시스템 또는 볼륨 계층의 사본을 활용하는 경로입니다. 4.0의 명명된 branch는 snapshot을 가리키며, SQL에 접속하는 clone과 구분합니다. 원본의 PostgreSQL major version에 맞는 이미지가 필요합니다. extension 바이너리의 준비 조건도 확인해야 합니다. 설치와 clone 사용의 구체적인 예제는 DBLab Engine 노트에 있습니다. 여기서는 설치 명령을 반복하지 않습니다.
Aurora clone은 전용 스토리지에서 변경되지 않은 page를 공유합니다. Zendesk는 fast clone에서 운영 query를 재생했습니다. 재생 결과로 버전, 파라미터, 인스턴스 구성을 비교했습니다. AWS가 공개한 고객 운영 사례입니다. 사례 조사 원본의 분류에 따라 신뢰도는 보통으로 표시합니다. 모든 workload에서 같은 개선 폭을 얻는다는 근거로 이 사례를 사용하지 않습니다. Zendesk 사례
Neon 환경에서는 리허설에 데이터 포함 branch를 사용하는 방안을 검토합니다. 생성과 migration 실행, schema 확인의 상세는 Schema Migration 리허설에 연결합니다. 제품별 명령 통일은 이 장의 적용 범위에 포함하지 않습니다. 원본 수집 방식과 시험 환경의 조건을 함께 남겨 결과를 다시 해석하도록 구성합니다.
운영 DB에 주는 부하
초기 수집과 갱신 경로
원본 수집과 clone 생성을 분리해 측정하는 방식을 제안합니다. 외부 PostgreSQL에서 기준 데이터를 준비할 때는 원본 읽기량과 네트워크 전송량을 기록합니다. 수집 소요 시간과 갱신 지연도 기록합니다. 물리 수집은 해당 시점의 page 상태와 통계를 보존하는 데 유리합니다. 다만 실행 계획과 시간이 같다는 보장은 아닙니다. 설정, 버전, hardware, 동시 부하를 결과의 조건으로 남깁니다.
WAL 기반 갱신을 사용한다면 실제 수집 경로에 replication slot이 있는지 확인합니다. Slot을 사용한다면 보존량과 전송 지연을 별도로 관찰합니다. 고정 시점 clone 생성만으로 원본에 clone 수만큼 slot이 추가된다고 계산하지 않습니다. 구성도에는 원본과 수집 사본 사이의 연결을 표시합니다. 수집 사본과 시험 clone 사이의 연결은 따로 표시합니다.
갱신 작업과 대형 리허설을 같은 시간대에 실행할지도 시험 계획에 포함합니다. 수집 중 운영 응답 시간이 정한 기준을 벗어나는 경우에 대비한 정책을 제안합니다. 이 경우 신규 수집을 중단하거나 일정을 조정합니다. 임계값은 평소 부하와 서비스 목표로 정합니다. 다른 고객의 사례에서 임의의 수치를 가져오지 않습니다. 수집 실패 후에는 마지막 성공 시점과 현재 기준 데이터의 나이를 함께 표시합니다.
시험 실행과 변경 공간
Clone 내부에서는 인덱스 생성, 대량 변경, 테이블 재작성의 읽기와 쓰기를 관찰합니다. 시험 중 저장 공간을 예측할 때는 CoW의 초기 공유 효과 외에 변경 공간도 고려합니다. Aurora는 원본과 clone 어느 쪽의 쓰기든 새로운 page 공간이 필요할 가능성을 설명합니다. DBLab에서도 대량 재작성은 변경 공간을 늘립니다. 다만 모든 업그레이드가 전체 데이터를 다시 쓰는 작업이라고 일반화하지 않습니다.
Query 비교에는 cold 실행과 반복 실행의 결과를 분리해 기록하는 방식을 제안합니다. 먼저 compute 크기, 캐시 준비 방법, 파라미터, 동시 세션 수를 같게 맞춰 비교합니다. 이후에는 운영을 대표하는 동시 부하를 추가합니다. 두 시험의 목적과 조건이 다르므로 결과도 따로 판정합니다. 저장소를 공유하는 구성의 경합은 compute 분리 여부만으로 결론 내리지 않습니다.
흔한 실패
비교 조건의 누락
오래된 기준 데이터와 최신 migration을 결합하는 상황을 실패 가설로 둡니다. 데이터의 총량과 함께 변경 대상 테이블, 주요 값의 분포를 확인하는 절차를 제안합니다. 기준 시점 이후의 schema 변경 여부도 확인합니다. 필요한 데이터 상태가 누락된 경우에는 테스트 통과 대신 적용 범위 제한을 기록합니다. 갱신을 수행했다면 이전 실험과 다른 기준점임을 명시합니다.
빈 환경에서 DDL만 실행한 결과로 운영 lock 경합을 판단하는 상황도 검증 대상입니다. 업무 query가 함께 실행되는 시험을 별도로 구성합니다. 이 시험에서 대기 시간과 실패 조건을 관찰합니다. 반대로 여러 조건을 동시에 바꾸어 원인을 구별하지 못하는 실험도 피합니다. 인스턴스 크기, 버전, 파라미터 중 무엇을 바꿨는지 실험마다 명시하는 방식을 제안합니다.
Migration의 성공과 데이터 검증을 구분합니다. 변경한 schema, migration 이력, 영향을 받은 데이터의 검증 결과를 별도로 기록합니다. 작업이 성공으로 종료됐지만 기대한 행 범위가 달라진 경우도 사전 시험에 넣습니다. 구체적인 업무 불변 조건은 서비스 담당자와 정합니다. 단순 행 수 비교만으로 정상 여부를 판정하지 않는 구성을 제안합니다.
재실행과 결과 보존
한 clone에 여러 실험을 누적한 뒤 원본 상태의 결과로 해석하는 경우를 점검합니다. 실험 시작 전 이전 인덱스나 데이터 변경이 남았는지 확인합니다. 독립 비교가 필요하면 같은 기준점에서 새 clone을 준비합니다. 최신 원본으로 갱신한 clone을 과거 실험의 재실행이라고 표시하지 않습니다. 데이터 기준점을 바꿨다는 사실을 결과 제목과 기록에 남깁니다.
시험 실패 직후 환경부터 삭제해 조사 자료를 잃는 상황도 시험합니다. 필요한 로그와 실행 계획, 자원 변화, 실패한 migration 식별자를 먼저 보존하도록 제안합니다. 모든 실패 환경을 무기한 유지하는 대신 조사에 필요한 보존 범위를 구분합니다. 재접속 조사가 필요한지, 결과 자료만으로 검토 가능한지 판단합니다. 연결 자격증명과 실제 운영 데이터가 보고서에 불필요하게 포함되는지도 확인합니다.
운영 정책 제안
운영 규모 데이터의 시험 설계
첫 단계에서는 검증 질문을 정합니다. 예를 들어 특정 migration의 운영 적용 가능 여부를 하나의 실험으로 작성합니다. query 수정 전후의 비교는 별도 실험으로 작성합니다. 대상 데이터의 기준 시점과 코드 commit을 고정합니다. 생성 요청 완료부터 SQL 접속 준비까지의 시간은 별도로 측정합니다. 데이터 접근 권한과 시험용 endpoint를 확인한 뒤 변경 작업을 시작하도록 제안합니다.
다음 단계에서는 무변경 기준 실행과 후보 변경 실행을 비교합니다. 같은 query 입력, compute, 파라미터, 캐시 준비 조건을 사용합니다. 입력 분포를 바꾸는 시험은 다른 실험 번호로 관리합니다. 단일 query의 실행 계획을 확인한 뒤 동시 workload 시험으로 확장합니다. 운영 부하를 재현하지 못한 항목은 보고서에 누락 조건으로 표시합니다.
Migration 시험에는 적용 순서와 checksum을 기록합니다. 실패 후 재실행, 중단 후 조사, 되돌리기 절차도 별도 항목으로 검토합니다. Clone에서 성공한 변경은 운영 배포 절차로 연결합니다. 이때 검토한 migration 파일을 실행합니다. 시험 중 임의로 추가한 SQL이 있다면 파일에 반영합니다. 반영한 파일은 다시 시험한 뒤 승인 대상으로 삼습니다.
기록 항목과 수명
명명은 migration-릴리스-작업번호와 perf-작업번호-실험번호를 제안합니다. 한 작업에서 여러 후보를 시험한다면 실험 번호를 새로 부여하고 공통 기준점으로 묶습니다. 원본 ID, 기준 시각, clone ID, PostgreSQL 버전을 결과와 함께 보관합니다. extension, compute 크기, 파라미터, 캐시 상태, 실행 입력도 함께 보관합니다. 표시명만 보고 시험 조건을 복원하려 하지 않습니다.
실행 기록에는 migration checksum, 시작과 종료 시각, 실행 시간을 포함하도록 제안합니다. lock 대기, 오류, 실행 계획, buffer 정보, 저장량 변화도 포함합니다. 원본 수집 지표와 clone의 실행 지표를 구분합니다. PostgreSQL이 보고한 객체 크기와 스토리지 사용량, 서비스 청구량도 별개 항목으로 둡니다. 각 숫자에 수집한 대상과 시간 범위를 표시합니다.
TTL은 릴리스 종료와 결과 검토 일정에 맞춰 정합니다. 결과 보존 기간과 clone 보존 기간은 따로 설정합니다. 대형 인덱스 생성이나 재작성의 동시 실행 수에는 quota를 둡니다. 중단 기준에는 원본 서비스 영향, 수집 지연, 시험 저장 공간의 여유를 포함합니다. DBA가 결과를 검토할 때 통과 여부를 배포 기록에 남기도록 제안합니다. 운영에서 추가로 관찰할 조건도 함께 남깁니다.
도식
다음은 원본 수집과 시험 실행 경로를 분리한 구성 제안입니다. 점선으로 연결한 저장소는 자원 공유 여부를 확인할 경계입니다. 모든 제품이 같은 저장소를 사용한다는 뜻은 아닙니다. 운영 적용 화살표는 검토한 migration이나 query 수정안의 배포를 나타냅니다.
리허설 결과에는 이 그림에서 실제로 사용한 수집 경로를 표시합니다. 공유 스토리지 여부를 확인하지 못했다면 미확인으로 남깁니다. 해당 조건을 보완한 뒤 성능 비교의 적용 범위를 결정합니다. 운영 적용 기록에는 승인 당시의 보고서와 변경 파일을 함께 연결합니다.