5.4 분석과 리포팅 격리
보고서의 데이터 기준에 따라 분석 환경의 준비 방식이 달라집니다. 기준은 월말 확정 데이터일 수도, 조회 직전까지 들어온 데이터일 수도 있습니다. 동일한 데이터에서 여러 가정을 비교하려면 기준점을 고정해야 합니다. 운영의 최신 변경을 계속 반영하는 리포트는 데이터 도착 경로와 지연을 관리해야 합니다. 이 장에서는 최신성 요구를 먼저 명시하도록 제안합니다. 이를 기준으로 clone과 지속 복제 중 검증 대상을 정합니다.
분석 query를 다른 endpoint로 보내는 것만으로는 검증이 충분하지 않습니다. 운영 영향과 보고서의 최신성을 함께 검증해야 합니다. 실행 자원, 공유 스토리지, 기준 데이터, 사용자에게 표시하는 시각을 확인합니다. 제품 동작과 공개 사례는 운영 설계 제안과 구분합니다. 선택 절차, 부하 시험, 최신성 표시, 수명 정책은 이 장의 운영 설계 제안입니다.
적용 계층과 제품
고정 시점 clone과 지속 복제
Aurora clone은 원본과 변경되지 않은 page를 공유합니다. 별도 volume의 논리적 상태도 제공합니다. 이를 고정된 기준 데이터의 분석 환경으로 검토합니다. Neon의 page 버전 기반 branch도 시나리오별 환경을 준비하는 후보입니다. Replica는 원본을 계속 추종하고, clone은 분기 이후 독립적으로 사용합니다. 요구 조건이 다르므로 생성 이름만 보고 대체 관계로 분류하지 않습니다.
PostgreSQL의 standby는 WAL을 받아 운영 변경을 반영하는 지속 복제 경로입니다. 최신 데이터가 필요한 분석에는 이런 경로나 별도의 동기화 구성을 검토합니다. 최신성이 필요하다는 요구만으로 허용 지연을 정하기는 어렵습니다. 업무 담당자와 허용할 데이터 지연을 먼저 정의하도록 제안합니다. 지연이 기준을 벗어났을 때 표시할 상태와 조회 허용 여부도 함께 정합니다.
Snowflake clone은 metadata와 데이터 참조를 공유하는 객체 복제 경로입니다. 과거 시점 clone에는 Time Travel의 보존 조건이 적용됩니다. Database나 schema를 clone할 때 권한과 외부 참조의 처리 규칙은 서로 다릅니다. 따라서 분석 환경을 준비할 때는 대상 객체와 권한, 외부 연결을 확인합니다. PostgreSQL cluster 전체의 실행 환경과 동일한 복제 단위로 설명하지 않습니다.
고정 사본을 주기적으로 교체하는 구성은 연속적인 변경 추종과 구별해 기록하도록 제안합니다. 보고서별 데이터 기준점과 교체 주기를 관리합니다. 같은 보고서를 다시 실행할 때 이전 기준점이 필요한지도 확인합니다. Replica의 최신 결과를 요구하는 화면은 별도 요구로 문서화합니다. 특정 기준점의 결과를 재현해야 하는 화면도 구분해 문서화합니다.
공개 고객 사례의 해석
ketteQ는 사용자별 분석 시나리오에 Neon branch를 제공합니다. 이를 여러 시나리오의 결과를 비교하는 데 활용합니다. 고객 인터뷰를 포함한 공급사 자료이므로 신뢰도는 보통입니다. 시나리오 분석이라는 실제 제품 기능의 근거로 사용합니다. 공개된 시나리오 수를 범용 분석 성능이나 지속 복제 처리량으로 해석하지 않습니다. ketteQ 사례
Zendesk는 Aurora PostgreSQL 업그레이드 중 ETL 쓰기를 일시 중단했습니다. 고객의 리포팅 읽기는 clone으로 우회했습니다. 업그레이드와 성능 확인 후 읽기를 원래 환경으로 돌리고 쓰기를 재개하는 절차입니다. AWS 고객 사례이며 신뢰도는 보통입니다. 이 절차에는 쓰기 중단이 포함됩니다. 일반적인 무중단 전환이나 지속적인 최신 데이터 제공 사례로 확대하지 않습니다. Zendesk 사례
두 사례를 적용할 때도 목적을 분리합니다. 시나리오 분석은 같은 기준에서 가정을 바꾸어 비교할 요구를 검토합니다. 리포팅 우회는 정해진 작업 시간 동안 데이터 갱신 중단을 허용하는지부터 확인합니다. 고객의 실제 TTL과 quota가 공개되지 않은 부분은 미확인으로 유지합니다. 뒤에서 제시하는 정책을 고객사의 운영 사실로 붙이지 않습니다.
운영 DB에 주는 부하
읽기 실행과 공유 저장소
분석 query의 실행 부하는 분석 compute와 저장소 읽기로 나누어 측정하도록 제안합니다. 운영 query의 응답 시간도 같은 구간에 기록합니다. 동시 분석 수를 늘렸을 때의 변화를 비교합니다. 별도 compute를 할당했다는 사실만으로 공유 스토리지 경합이 없다고 판정하지 않습니다. 시험 결과에는 자원 공유 여부와 확인하지 못한 경계를 명시합니다.
데이터를 변경하지 않는 분석 환경도 저장량을 확인해야 합니다. Aurora는 원본 또는 clone의 쓰기로 새로운 page 공간이 필요할 가능성을 설명합니다. 부모가 변경되어도 오래된 분석 기준점을 계속 보존하는 경우가 있습니다. 이때는 공유 관계에 따른 공간 사용을 확인해야 합니다. 분석 계정이 읽기 전용이어도 추가 저장량을 항상 0으로 비용 계획에 적지 않습니다.
Snowflake에서는 clone의 보존 수명과 query 실행 자원 사용을 함께 관리하도록 제안합니다. 객체 준비와 warehouse에서의 분석 실행을 별도 비용 항목으로 기록합니다. 실제 데이터 공유량을 청구량과 동일하게 취급하지 않고 서비스의 사용량 지표를 대조합니다. 분석 완료 후에는 결과만 보존할지 결정합니다. 같은 기준점에서 재실행하려면 사본도 보존할지 정합니다.
Neon의 compute와 데이터, 복구 이력을 구분하는 비용 항목은 비용 모델 노트에 연결합니다. 이 장에서는 단가와 플랜별 한도를 반복하지 않습니다. 분석 실행 기간과 기준점 보존 기간을 별도로 기록하는 원칙만 적용합니다. 예산에는 실제 사용할 생성 모드와 보존 조건을 명시합니다.
최신성 확보와 갱신 비용
외부 운영 DB에서 기준 데이터를 수집하는 구성은 수집 읽기와 전송량을 추가로 기록합니다. 지속 복제 경로에서는 WAL 전송과 재생, 지연을 관찰합니다. Replication slot을 사용한다면 보존 상태도 점검합니다. 고정 시점 clone에 원본 추종용 WAL이 자동으로 계속 전달된다고 가정하지 않습니다. 갱신 기능을 별도로 구성했다면 그 구성과 책임자를 기록합니다.
고정 사본을 반복 생성하는 설계에는 준비 시간과 이전 사본의 보존 기간을 포함합니다. 새 사본의 생성 시작 시각, 데이터 기준 시각, 조회 사용 시작 시각을 구분하도록 제안합니다. 교체 주기만 보고 실제 데이터 나이를 계산하지 않습니다. 이전 사본을 사용하는 조회가 남아 있다면 해당 조회의 종료와 정리 시점을 추적합니다.
흔한 실패
최신성의 잘못된 표시
보고서 생성 시각을 데이터 기준 시각으로 표시하는 상황을 실패 가설로 둡니다. 오늘 만든 보고서라도 데이터는 과거 기준점의 것일 수 있습니다. 이때는 두 시각을 나누어 표시하도록 제안합니다. 데이터 갱신 없이 화면만 다시 로드했을 때도 최신 상태 표시를 시험합니다. 이 경우 표시가 그대로 유지되는지 확인합니다. 사용자가 내려받은 결과에도 같은 기준점을 남깁니다.
Replica의 지연을 관찰하지 않은 채 항상 최신이라는 문구를 사용하는 경우도 점검합니다. 조회 시각과 확인한 반영 상태를 구별해 기록합니다. 최신성을 확인하지 못한 동안은 미확인 상태로 표시하는 정책을 제안합니다. 지연 상태의 결과를 업무에 사용할지 중단할지는 담당자가 정한 허용 기준으로 판단합니다. 확인되지 않은 시간을 추정해 정상 상태로 표시하지 않습니다.
서로 다른 기준점의 시나리오를 같은 데이터의 가정 비교로 제시하는 경우도 시험합니다. 결과마다 기준 데이터 ID와 사용한 가정을 붙입니다. 비교 화면에서 공통 기준점인지 확인하도록 설계합니다. 분석 중 새 운영 데이터를 반영했다면 새 시나리오로 기록하도록 제안합니다. 기준 데이터 변경과 가정 변경을 한 번의 수정으로 묶지 않습니다.
우회 조건과 권한의 누락
Zendesk 절차를 일반 서비스에 적용할 때는 쓰기 중단 조건을 먼저 확인합니다. 같은 방식을 제안하려면 정해진 구간 동안 대상 데이터의 모든 쓰기 경로를 통제해야 합니다. 데이터 갱신이 멈춘 상태의 보고서 제공도 업무에서 허용해야 합니다. 쓰기가 계속되는 서비스를 단순 clone으로 우회한 뒤 최신성까지 보장한다고 설명하지 않습니다. 중단하지 못한 쓰기가 있다면 해당 절차의 적용을 보류합니다.
읽기용 화면이 쓰기 가능한 환경에 연결되는 상황도 실패 시험에 포함합니다. 분석용 조회 계정과 시나리오 변경 계정을 구분합니다. 각 계정으로 허용 범위를 벗어난 작업을 시도해 확인하는 정책을 제안합니다. Snowflake의 clone 권한은 객체 종류에 따라 차이가 있습니다. 따라서 원본 권한이 전부 복제됐다고 가정하지 않습니다. 결과의 반출 권한과 외부 참조도 별도 확인 대상으로 둡니다.
운영 정책 제안
선택과 최신성 표시
분석 요청서에는 데이터 기준점 고정 여부와 허용 지연을 적도록 제안합니다. 시나리오 쓰기 필요 여부와 결과 재현 기간도 적습니다. 특정 시점에서 결과를 비교할 작업은 clone을 우선 검증합니다. 최신 변경을 계속 받아야 하는 작업은 replica나 동기화 경로를 검증합니다. 둘 다 필요하면 최신 상태의 조회와 고정 시나리오 실행을 구분하는 구성을 검토합니다.
최신성 표시는 결과 생성 시각, 원본 데이터 기준 시각, 마지막 갱신 확인 시각으로 나눕니다. 모든 필드를 서비스가 자동 제공한다고 가정하지 않고 수집 가능한 근거를 정합니다. 고정 사본은 기준점 고정 상태를 표시합니다. 지속 복제는 확인한 반영 상태와 지연을 표시합니다. 시각에는 시간대를 붙이고, 확인되지 않은 값에는 미확인이라는 상태를 사용합니다.
예를 들어 월말 분석 결과에는 기준 데이터가 확정된 시각과 결과를 계산한 시각을 각각 적습니다. 나중에 같은 기준점으로 다시 계산했다면 계산 시각만 달라졌음을 보여 줍니다. 시나리오 입력을 수정했다면 입력 버전도 바꿉니다. 이런 표시 방식은 이 장의 제안입니다. ketteQ가 실제로 사용하는 화면 규칙이라는 뜻은 아닙니다.
수명과 query 예산
명명은 analysis-업무-기준시점을 제안합니다. 원본 ID, 기준 데이터 ID, 작업 소유자, 분석 목적, 만료 시각을 별도 기록으로 관리합니다. 사용자가 바꾼 가정은 시나리오 ID와 입력 버전으로 추적합니다. 표시명에 모든 조건을 압축하지 않고, 보고서에서 관련 기록을 찾아가도록 연결합니다.
조회 전용 보고서는 읽기 권한을 기본으로 설정하도록 제안합니다. 시나리오 변경이 필요한 작업에만 쓰기 범위를 부여합니다. Query 예산은 동시 실행 수, 실행 시간, compute 사용량을 나누어 정합니다. 대형 분석을 여러 개 실행할 때는 운영 영향과 저장소 여유를 관찰합니다. 정한 기준을 초과하면 신규 실행을 대기시키거나 중단하도록 구성합니다.
TTL은 작업 종료와 재현 요구에 맞춰 정합니다. 결과 자료의 보존 기간과 실행 환경의 보존 기간을 별도로 관리합니다. Snowflake에서는 warehouse 실행과 clone 보존을 함께 점검합니다. 만료 예외에는 책임자, 보존 사유, 종료일을 기록합니다. 다시 사용할 가능성만으로 모든 분석 환경을 계속 유지하는 규칙은 두지 않도록 제안합니다.
리포팅 우회 작업은 쓰기 중단 확인, clone 준비, 읽기 대상 변경 순서로 계획하도록 제안합니다. 이어서 원본 작업, 복귀 검증, 쓰기 재개를 계획합니다. 각 단계의 진행 조건과 실패 시 대상을 기록합니다. 데이터 갱신 중단을 언제부터 사용자에게 표시할지도 정합니다. 읽기 복귀와 쓰기 재개는 각각 확인합니다. 작업 종료 후 실제 데이터 갱신이 정상인지 검증합니다.
도식
다음은 최신성 요구에 따른 선택 절차 제안입니다. 고정 시점 경로와 지속 복제 경로 모두 실행 자원과 운영 영향을 검증합니다. Clone 경로의 기준 시점 표시는 생성 작업이 끝난 시각과 구분합니다.
보고서 사용자는 마지막 표시 단계에서 결과의 데이터 기준을 확인합니다. 운영자는 복제 지연이나 기준점의 보존 상태를 별도로 관찰합니다. 작업 종료 시 이 두 기록을 연결합니다. 결과에 표시한 최신성과 실제 제공한 데이터의 상태가 일치하는지 확인합니다.