분산 데이터 시스템 전반에 걸친 스키마 변경 감지

화요일에는 분석 대시보드가 ​​정확했습니다. 하지만 목요일에는 고객 확보율이 23% 감소한 것으로 나타났고, 비즈니스 팀은 이를 중요한 사업적 신호로 간주하여 마케팅 예산을 재조정하고 캠페인을 일시 중단하는 등 이사회에 보고했습니다. 금요일에 데이터 엔지니어링 팀은 상위 서비스에서 데이터에 null 값을 허용하는 열이 추가된 것을 발견했습니다. registrations 6일 전의 테이블이었습니다. ETL 파이프라인은 업데이트되지 않았습니다. 인수 지표를 도출하는 계산은 새로운 null 값을 제외하는 대신 0으로 처리했습니다. 스키마 변경 알림도 전송되지 않았습니다. 오류를 발생시킬 만한 계약 위반도 없었습니다. 파이프라인은 성공적으로 실행되었고, 겉보기에는 맞는 것처럼 보이는 잘못된 수치를 출력했습니다.

스키마 드리프트는 구조적 변형을 의미하며, 값이 잘못된 데이터 품질 문제와는 달리 소스와 대상 간의 계약을 위반하는 것입니다. 모든 DDL을 제어하는 ​​중앙 DBA가 있는 모놀리식 데이터베이스 환경에서는 단일 권한자가 계약을 강제합니다. 그러나 수십 개의 독립적인 서비스가 각각 자체 데이터 저장소를 소유하고, 이벤트 스트림이 독립적으로 진화하는 Avro 스키마를 전달하며, 메인프레임 배치 작업과 클라우드 분석 플랫폼 간의 플랫 파일 인터페이스가 어느 시스템의 문서에도 존재하지 않는 암묵적인 계약을 정의하는 분산 시스템에서는 계약이 시스템의 모든 경계에 걸쳐 분산됩니다. 분산 환경에서의 스키마 드리프트는 DBA의 실수를 기다리지 않습니다. 모든 데이터 하위 소비자에 대한 완벽한 가시성 없이 개별적으로 합리적인 결정을 내리는 자율적인 팀의 정상적인 운영 과정에서 발생합니다.

스키마 드리프트란 무엇이며, 무엇이 아닌가

스키마 드리프트는 데이터 아티팩트의 구조가 변경되었지만 해당 아티팩트를 사용하는 쿼리에는 반영되지 않는 현상입니다. '소비자'에 초점을 맞춘다는 점이 스키마 드리프트와 계획된 마이그레이션을 구분하는 핵심입니다. 소스 테이블과 모든 쿼리에서 동시에 열 이름을 변경하는 것은 스키마 마이그레이션입니다. 반면, 소스 테이블에서만 열 이름을 변경하여 소비 쿼리에서 오래된 열 이름을 사용하게 되는 경우는 스키마 드리프트입니다.

데이터 파이프라인은 소스 시스템과 대상 데이터 웨어하우스 간의 신뢰 계약에 기반합니다. 이 계약은 스키마, 즉 데이터 세트를 정의하는 합의된 구조, 데이터 유형 및 열 이름으로 구성됩니다. 상위 팀에서 데이터 팀에 알리지 않고 애플리케이션 데이터베이스를 변경하면 이 계약을 위반하게 됩니다.

스키마 드리프트는 데이터 드리프트와 다릅니다. 데이터 드리프트는 안정적인 스키마 내에서 값의 통계적 분포가 변하는 것을 의미하며, 평균 순서 값이 감소하거나, null 값이 증가하거나, 범주형 분포가 변하는 등의 변화를 말합니다. 둘 다 중요한 데이터 품질 신호이지만, 탐지 방식과 근본 원인이 다릅니다. 열 이름과 데이터 유형을 모니터링하는 스키마 변경 감지 시스템은 데이터 드리프트를 감지하지 못하며, 분포 모니터링 시스템은 열 추가 및 삭제를 감지하지 못합니다.

스키마 드리프트가 항상 해로운 것은 아닙니다. 시간 경과에 따른 드리프트 심각도를 추적하면 활발한 개발 주기(양성 드리프트)와 불안정성(심각한 드리프트)을 구분하는 데 도움이 됩니다. 하위 호환성을 유지하면서 테이블에 null 허용 열을 추가하는 것은 스키마 드리프트에 해당합니다. 스키마는 변경되었지만 새 열을 무시하는 소비자에게는 문제가 발생하지 않을 수 있습니다. 드리프트를 양성 또는 심각한 것으로 분류하려면 하위 소비자와 그들이 변경 사항을 처리하는 방식을 이해해야 합니다.

스키마 드리프트의 네 가지 유형

분산 데이터 시스템은 서로 다른 감지 메커니즘이 필요한 네 가지 차원에서 스키마 변화를 일으킵니다.

유형 1: 구조적 변위

물리적 스키마 정의 변경 사항에는 열 추가, 열 삭제, 열 이름 변경, 데이터 유형 변경, 제약 조건 추가 또는 삭제, 테이블 추가 및 삭제 등이 포함됩니다. 이는 스키마 드리프트의 가장 눈에 띄는 형태이며, 관찰 도구에서 가장 일반적으로 다루는 유형입니다. 데이터베이스 INFORMATION_SCHEMA 쿼리, 스키마 레지스트리 비교, 마이그레이션 도구 감사 로그를 통해 연결된 시스템의 구조적 드리프트를 효과적으로 포착할 수 있습니다.

탐지 방식: 기준선과의 스키마 스냅샷 비교; INFORMATION_SCHEMA 폴링; 스키마 레지스트리 버전 비교.

유형 2: 의미 변화

기존 필드의 정의는 변경하지 않고 필드의 의미만 변경합니다. 열 이름은 다음과 같습니다. status 이전에 값을 포함했던 ACTIVE, INACTIVE, PENDING 현재 값을 포함합니다 1, 2, 3 생성 서비스가 열거형을 변경했기 때문입니다. 스키마, 열 이름, 데이터 유형, null 허용 제약 조건은 변경되지 않았습니다. 의미론적 계약이 깨졌습니다. 문자열 상태 값을 파싱하던 소비자는 이제 로직에서 처리할 수 없는 정수 값을 받게 됩니다.

의미 변화와 맥락 변화는 비교적 최근에 논의되기 시작한 주제이며, 인공지능 프로그램 실패의 주요 원인으로 점점 더 큰 비중을 차지하고 있음에도 불구하고 제대로 모니터링되지 않고 있습니다. 의미 변화는 구조적 신호를 생성하지 않기 때문에 자동으로 감지하기가 가장 어렵습니다. 이를 감지하려면 값 분포 모니터링(알려진 값과 알려지지 않은 값의 비율 변화)이나 명시적인 계약 테스트가 필요합니다.

탐지: 값 분포 모니터링; 허용 값 유효성 검사 규칙; 특정 유효 값을 검증하는 계약 테스트.

유형 3: 형식 편차

구조적으로 변경되지 않은 필드 내 값의 인코딩 또는 형식이 변경되었습니다. 이전에는 UTC ISO 8601 문자열을 포함했던 타임스탬프 필드가 이제 유닉스 에포크 정수를 포함합니다. 이전에는 소수점 금액을 포함했던 통화 필드가 이제 센트 단위의 정수 금액을 포함합니다. 해당 열은 존재하며, 데이터 유형은 새 값에 대해 여전히 유효하지만 구문 분석 규칙이 변경되었습니다.

포맷 드리프트는 특히 분산 시스템의 경계에서 흔히 발생하는데, 한 서비스가 다른 서비스에서 역직렬화하는 형식을 다른 형식으로 직렬화하는 경우와, 레거시 시스템과 최신 시스템의 경계에서 COBOL 프로그램이 하위 ETL 프로세스가 의존하는 특정 바이트 위치 규칙에 따라 플랫 파일을 작성하는 경우에 발생합니다.

탐지: 값 범위 및 패턴에 대한 통계적 프로파일링; 특정 필드에 대한 형식 유효성 검사 규칙; 경계 일치 테스트.

유형 4: 계약 변경

데이터 소스의 가용성, 최신성 또는 용량 보장 방식의 변경. 소스 시스템은 이전에는 매일 오전 3시(UTC)까지 데이터 세트를 제공했지만, 이제는 오전 6시까지 제공함으로써 오전 3시 기준의 최신성을 전제로 했던 하위 프로세스에 조용히 문제를 일으키고 있습니다. 소스 시스템은 이전에는 하루 최소 1,000개의 레코드를 보장했지만, 트래픽이 적은 기간에는 그보다 적은 레코드가 제공됩니다. 이러한 변경 사항들은 구조적인 의미의 스키마 변경은 아니지만, 데이터 생산자와 소비자 간의 계약을 위반하는 것입니다.

감지 기능: 신선도 모니터링; 용량 이상 감지; SLA 기반 알림.

분산 시스템이 문제를 악화시키는 이유는 무엇일까요?

단일 데이터베이스와 단일 애플리케이션 팀으로 구성된 모놀리식 시스템에서는 스키마 변경이 통제된 이벤트로 이루어집니다. DBA가 마이그레이션을 작성하고, 개발자가 쿼리를 업데이트하고, 변경 사항이 함께 배포됩니다. 스키마 드리프트의 위험은 존재하지만, 단일 관리팀의 범위 내에서 제한됩니다.

분산 시스템은 단일 권한 체계를 없애줍니다. 각 서비스는 자체 데이터를 소유하며, 각 팀은 스키마 결정을 독립적으로 내립니다. 각 서비스 데이터의 소비자는 해당 팀이 직접적으로 파악하기 어려운 경우가 많으며, 특히 데이터 플랫폼, 분석 파이프라인 또는 제품 팀이 적극적으로 유지 관리하지 않는 기존 통합 지점인 경우에는 더욱 그렇습니다.

Distributed Schema Drift Propagation Path:

Order Service          Kafka Topic           Analytics Pipeline
┌─────────────────┐   ┌───────────────┐    ┌──────────────────────┐
│ orders table    │──>│ order.created │───>│ orders_fact table    │
│ + coupon_id     │   │ Avro schema   │    │ (missing coupon_id)  │
│   (new column)  │   │ v1 still used │    │ pipeline runs fine   │
│                 │   │               │    │ coupon data silently  │
│                 │   │               │    │ dropped              │
└─────────────────┘   └───────────────┘    └──────────────────────┘

                           ▼
                   BI Dashboard
                ┌──────────────────┐
                │ coupon_revenue   │
                │ always = $0      │
                │ (no error shown) │
                └──────────────────┘

이 다이어그램은 전파 패턴을 보여줍니다. 주문 서비스 팀이 추가합니다. coupon_id 데이터베이스에 추가합니다. 또한 Kafka 이벤트 스키마를 업데이트하여 다음을 포함하도록 합니다. coupon_id분석 파이프라인이 해당 데이터를 사용하려면 업데이트되어야 합니다. Kafka 스키마가 여전히 버전 1인 경우 해당 필드는 파이프라인에 도달하지 않습니다. 파이프라인은 업데이트되었지만 BI 대시보드 모델이 새로 고쳐지지 않으면 해당 필드는 데이터 웨어하우스에는 존재하지만 보고서에는 나타나지 않습니다. 이러한 드리프트는 네 가지 경계 중 어느 지점에서든 데이터 손실을 초래할 수 있으며, 각 경계마다 서로 다른 감지 메커니즘이 필요합니다.

파이프라인 오류, 오래된 대시보드, 스키마 변경, 불완전한 데이터 세트는 현대 기업 데이터 환경에서 주요 운영 위험 요소가 되었습니다. 최신 데이터 스택은 기존 환경보다 오류 발생 속도가 훨씬 빠르며, 변환 오류, 최신성 유지 실패, 데이터 손상 등이 파이프라인 전반에 걸쳐 팀이 수동으로 문제를 감지하기 훨씬 전에 확산됩니다.

분산 환경에서 스키마 변경이 비용이 많이 드는 이유는 바로 "조용한" 특성 때문입니다. 예외를 발생시키는 오류는 감지되어 수정되지만, 잘못된 수치를 조용히 생성하는 변경 사항은 해당 수치를 기반으로 한 비즈니스 결정으로 인해 가시적인 결과가 나타날 때까지 감지되지 않습니다.

계층별 탐지 접근 방식

스키마 변경 감지에는 분산 시스템의 각 계층마다 서로 다른 도구와 기술이 필요합니다.

데이터베이스 및 웨어하우스 계층

가장 성숙한 탐지 계층입니다. 모든 주요 데이터베이스 및 데이터 웨어하우스의 INFORMATION_SCHEMA 테이블은 쿼리 가능한 메타데이터 스냅샷을 제공합니다.

SQL

-- Detect structural schema changes since a baseline snapshot
-- Run daily; alert when new differences appear

WITH current_schema AS (
    SELECT
        table_name,
        column_name,
        data_type,
        is_nullable,
        column_default,
        ordinal_position
    FROM information_schema.columns
    WHERE table_schema = 'production'
),
baseline AS (
    -- Previous snapshot stored in schema_baseline table
    SELECT * FROM schema_monitoring.schema_baseline
    WHERE snapshot_date = CURRENT_DATE - 1
)
SELECT
    'ADDED'   AS change_type,
    c.table_name,
    c.column_name,
    c.data_type,
    CURRENT_DATE AS detected_date
FROM current_schema c
LEFT JOIN baseline b
    ON c.table_name = b.table_name
    AND c.column_name = b.column_name
WHERE b.column_name IS NULL

UNION ALL

SELECT
    'REMOVED' AS change_type,
    b.table_name,
    b.column_name,
    b.data_type,
    CURRENT_DATE
FROM baseline b
LEFT JOIN current_schema c
    ON b.table_name = c.table_name
    AND b.column_name = c.column_name
WHERE c.column_name IS NULL

UNION ALL

SELECT
    'TYPE_CHANGED' AS change_type,
    c.table_name,
    c.column_name,
    c.data_type || ' (was: ' || b.data_type || ')' AS data_type,
    CURRENT_DATE
FROM current_schema c
JOIN baseline b
    ON c.table_name = b.table_name
    AND c.column_name = b.column_name
WHERE c.data_type <> b.data_type;

이러한 패턴을 자동화하는 도구: dbt 스키마 테스트, Great Expectations 열 기대치, Monte Carlo 테이블 상태 모니터링, Acceldata 스키마 드리프트 모니터링.

이벤트 스트리밍 레이어

Kafka 토픽은 스키마 레지스트리(Confluent Schema Registry, AWS Glue Schema Registry, Apicurio)를 사용하여 Avro, Protobuf 및 JSON 스키마의 진화를 관리합니다. 레지스트리는 게시 시점에 호환성 규칙을 적용합니다.

얌

# Confluent Schema Registry: compatibility rule configuration
# Applied per topic; enforces at producer registration time

compatibility:
  BACKWARD:
    # New schema can read data written with old schema
    # Safe: consumers can be updated after producers
    allows: add_optional_fields, remove_fields_with_defaults
    blocks: rename_fields, change_types, add_required_fields

  FORWARD:
    # Old schema can read data written with new schema
    # Safe: consumers can be deployed before producers
    allows: add_required_fields, rename_with_aliases
    blocks: remove_fields_used_by_consumers

  FULL:
    # Both backward and forward compatible
    # Strictest: ensures zero-downtime evolution
    allows: add_optional_fields_with_defaults
    blocks: everything_else

스키마 레지스트리는 의미 변화를 방지하지 못합니다. 이름과 유형은 변경되지 않았지만 의미가 바뀐 필드도 호환성 검사를 통과할 수 있습니다. 의미 유효성 검사를 위해서는 계약 테스트(Pact, AsyncAPI 테스트)가 필요합니다.

API 계층

API 스키마 변경을 감지하는 데는 크게 네 가지 접근 방식이 있습니다. 사양 간 비교, 사양과 실제 변경 사항 모니터링, 실제 변경 사항 모니터링, 그리고 트래픽 기반 감지입니다. 이 분야에서 가장 혼란스러운 부분은 서로 다른 접근 방식을 사용하는 도구들을 비교하는 데서 비롯됩니다.

마이크로서비스 아키텍처에서 내부 서비스 API의 경우, 소비자 주도 계약 테스트(Pact)가 가장 신뢰할 수 있는 접근 방식입니다. 각 소비자는 생산자에게 요구하는 계약을 명시하고, 해당 계약은 CI 환경에서 생산자의 구현과 비교하여 검증되며, 소비자의 계약을 위반하는 변경 사항이 발생하면 배포 전에 생산자의 테스트 스위트가 실패하게 됩니다.

기존 시스템 경계: 드리프트가 보이지 않게 되는 지점

위에 설명된 모든 탐지 접근 방식은 쿼리 가능한 인터페이스(INFORMATION_SCHEMA, 스키마 레지스트리, OpenAPI 사양)를 통해 스키마 메타데이터를 노출하는 시스템에서 작동합니다. 그러나 기존 메인프레임 시스템과 최신 데이터 플랫폼의 경계에서는 이러한 인터페이스가 존재하지 않습니다.

클라우드 ETL 파이프라인에서 사용할 플랫 파일을 매일 밤 생성하는 COBOL 프로그램은 파일 디스크립터(FD) 항목과 출력 로직에 암묵적인 스키마를 정의합니다. 플랫 파일의 "스키마", 즉 바이트 위치, 데이터 유형, COMP-3 팩형 십진수 필드 및 REDEFINES 구조체는 최신 관찰 도구가 쿼리할 수 있는 레지스트리나 메타데이터 저장소가 아닌 COBOL 소스 코드에 존재합니다.

코볼

      *> This FD entry IS the schema contract for the nightly extract
      *> Any change here constitutes schema drift for the downstream ETL
       FD  CUSTOMER-EXTRACT-FILE
           LABEL RECORDS ARE STANDARD
           RECORD CONTAINS 350 CHARACTERS.
       01  CUSTOMER-EXTRACT-REC.
           05  CUST-ID          PIC 9(10).        *> Bytes 1-10
           05  CUST-NAME        PIC X(40).        *> Bytes 11-50
           05  CUST-BALANCE     PIC S9(11)V99 COMP-3. *> Bytes 51-57 (packed)
           05  CUST-STATUS-CD   PIC X(2).         *> Bytes 58-59
           05  CUST-OPEN-DATE   PIC 9(8).         *> Bytes 60-67: YYYYMMDD
           05  FILLER           PIC X(283).       *> Bytes 68-350

COBOL 팀이 변경되는 경우 CUST-BALANCE 에 PIC S9(11)V99 COMP-3 에 PIC S9(13)V99 COMP-3더 큰 잔액 값을 처리하기 위해 두 자리 정밀도를 추가하면서 해당 필드는 팩형 십진수 형식으로 7바이트에서 8바이트로 확장됩니다. 50번째 바이트 이후의 모든 필드는 한 자리씩 이동합니다. ETL 파이프라인이 읽는 플랫 파일에서 CUST-BALANCE 이후의 모든 필드는 이제 잘못된 바이트 위치에 있습니다. ETL 파이프라인은 오류를 발생시키지 않고 51~57번째 바이트를 CUST-BALANCE로 읽고 다음 바이트(이제 CUST-BALANCE의 확장된 표현의 첫 번째 바이트)를 CUST-STATUS-CD의 일부로 해석합니다. 파이프라인은 실행됩니다. 숫자는 잘못되었지만 스키마 변경 경고는 발생하지 않습니다.

이는 기업 환경에서 가장 위험한 유형의 스키마 변경입니다. 레거시 시스템의 구조적 변경이 감지 메커니즘 없이 플랫 파일 인터페이스를 통해 조용히 전파되는 현상입니다.

기존 경계의 변동을 특히 위험하게 만드는 세 가지 특징은 다음과 같습니다.

해당 스키마는 관찰 도구에서 보이지 않습니다. Monte Carlo는 VSAM 파일에 연결할 수 없고, Acceldata는 파일 디스크립터(FD) 항목을 조회할 수 없습니다. 변경 사항을 감지하는 유일한 방법은 COBOL 소스 코드를 이전 버전과 비교하는 것인데, 이는 데이터 모니터링 작업이 아닌 코드 분석 작업입니다.

변경 사항은 조용히 전파됩니다. 플랫 파일 인터페이스는 레코드 구조의 유효성을 검사하지 않고 바이트를 읽습니다. 바이트 레이아웃이 변경되면 오류가 아닌 잘못된 값이 생성됩니다.

파급 효과는 광범위합니다. 300개의 프로그램에서 포함된 COBOL 카피북은 300개의 프로그램이 공유하는 스키마입니다. DDL ALTER TABLE과 같은 카피북 변경은 300개 프로그램 모두에 동시에 영향을 미치며, 이 300개 프로그램 중 어느 하나라도 생성한 데이터 세트를 사용하는 모든 하위 프로그램은 변경 사항을 그대로 물려받게 됩니다.

스키마 계약: 일반적으로 암묵적인 것을 형식화하기

스키마 드리프트에 대한 구조적 해결책은 암묵적인 계약을 명시적으로 만드는 것입니다. 즉, 변경이 발생한 후에 문제가 생기는 것이 아니라, 변경이 이루어지기 전에 스키마가 무엇인지, 누가 스키마에 의존하는지, 그리고 어떤 변경이 허용되는지를 정의하는 것입니다.

계약 계층	관할 범위	도구	기존 시스템과 동일
데이터베이스 DDL	테이블 구조, 컬럼 유형, 제약 조건	리퀴베이스, 플라이웨이, 아틀라스	DB2 DDL 마이그레이션 스크립트
이벤트 스키마	Kafka/이벤트 스트림 구조	컨플루언트 스키마 레지스트리, 아피쿠리오	해당 없음 (플랫 파일에는 레지스트리가 없습니다)
API 계약	REST/gRPC 인터페이스 기대 사항	오픈 API, 팩트, 비동기 API	해당 사항 없음 (파일 인터페이스에 대한 사양이 없습니다)
데이터 품질	가치 분포, 신선도, 용량	위대한 기대, dbt 테스트	해당 사항 없음 (기본 테스트 프레임워크 없음)
파일 형식 계약	플랫 파일 바이트 레이아웃, 필드 위치	COBOL FD 항목(진실의 원천)	사본 버전 관리

기존 항목의 해당 열에 있는 "카피북 버전 관리" 항목은 COBOL 스키마 진화를 관리하는 실질적인 메커니즘입니다. 즉, 카피북을 변경 승인 프로세스가 있는 버전 관리 아티팩트로 취급하고, 각 카피북이 포함된 프로그램 목록을 유지 관리하며, 카피북 수정이 승인되기 전에 영향 분석을 요구하는 것입니다.

교재 변경 승인 워크플로:

1. 개발자가 변경 사항을 제안합니다. CUSTMSTR.CPY
2. 영향 분석은 다음을 포함하는 모든 프로그램을 식별합니다. CUSTMSTR.CPY (정적 분석)
3. 해당 프로그램에서 생성되는 모든 플랫 파일은 스키마 변경 이벤트로 식별됩니다.
4. 해당 플랫 파일을 사용하는 모든 하위 사용자에게 알림이 전송됩니다.
5. 새로운 레이아웃에 대한 소비자 검증 테스트가 진행됩니다.
6. 해당 변경 사항은 모든 소비자가 호환성을 확인한 경우에만 승인됩니다.

이 워크플로는 기본 스키마 레지스트리가 존재하지 않는 COBOL 계층에 적용되는 스키마 레지스트리 호환성 강제 패턴을 반영합니다.

분산 스키마 드리프트 모니터링 아키텍처

완벽한 스키마 드리프트 모니터링 아키텍처는 모든 시스템 계층에 걸쳐 네 가지 유형의 드리프트를 모두 포괄합니다.

스키마 스냅샷 데이터베이스. 모든 테이블의 INFORMATION_SCHEMA 메타데이터, 등록된 모든 이벤트 스키마 버전, 모든 API 사양 버전, 그리고 (레거시 시스템의 경우) 모든 카피북 버전의 스냅샷을 매일 저장합니다. 이 스냅샷 데이터베이스는 현재 상태를 비교하는 기준선 역할을 합니다.

변경 감지 파이프라인. 스냅샷 데이터베이스를 대상으로 매일 비교 작업이 실행되어 모니터링되는 모든 계층에서 추가, 삭제, 데이터 유형 변경 및 제약 조건 변경을 감지합니다. 심각도가 높은 변경 사항, 하위 호환성이 없는 데이터 유형 변경, 열 삭제, 필수 필드 추가는 즉시 알림을 발생시킵니다. 심각도가 낮은 변경 사항, null 허용 열 추가, 인덱스 변경은 권고 알림을 생성합니다.

소비자 영향 레지스트리. 모든 스키마 아티팩트를 알려진 소비자와 연결하는 카탈로그입니다. 어떤 파이프라인이 어떤 테이블에서 데이터를 읽는지, 어떤 서비스가 어떤 Kafka 토픽을 사용하는지, 어떤 ETL 작업이 어떤 플랫 파일을 처리하는지 등을 기록합니다. 스키마 변경이 감지되면 소비자 영향 레지스트리는 영향 범위, 영향을 받는 소비자 수, 그리고 가장 중요한 소비자를 파악합니다.

계약 테스트 스위트. 생산자 스키마에 대한 소비자 가정을 검증하는 자동화된 테스트입니다. 데이터 생성 서비스를 사용하는 모든 배포에서 실행됩니다. 등록된 소비자가 의존하는 계약이 위반될 경우 배포를 실패 처리합니다.

레거시 경계 모니터링. 메인프레임 시스템의 경우, 버전 관리되는 카피북 비교, JCL 데이터셋 정의 모니터링, 그리고 생성 프로그램의 함수 파일(FD) 항목에 정의된 스키마에 대한 플랫 파일 형식 유효성 검사가 포함됩니다. 이 계층은 데이터 모니터링보다는 코드 분석을 필요로 하며, 하위 시스템 사용자에게 스키마 변경을 초래하는 COBOL 소스 코드의 변경 사항을 감지합니다.

정기적인 모니터링은 많은 팀이 생각하는 것보다 훨씬 중요합니다. Acceldata의 정기적인 드리프트 분석 지침에서는 안정적인 기준선과의 자동 비교를 주간 또는 격주 주기로 수행할 것을 권장하며, 오류 발생 후 임시 점검을 기다리는 것은 불충분하다고 명시적으로 지적합니다. 특히 레거시 경계 모니터링의 경우, 모니터링 주기는 COBOL 배포 일정과 일치해야 합니다. 프로덕션 환경에 카피북 릴리스가 발생하면 다음 정기 비교를 기다리지 않고 즉시 스키마 영향 분석을 수행해야 합니다.

방법 SMART TS XL 기존 환경에서 발생하는 스키마 변경 문제를 해결합니다.

SMART TS XL 이 솔루션은 최신 관찰 도구가 작동하지 않는 레거시 시스템 경계, 즉 가장 위험한 스키마 변경이 감지되지 않는 계층에서의 탐지 격차를 해결합니다.

정적 코드 분석 기능은 모든 COBOL 함수 필드 항목, COPY 멤버 및 SELECT 절을 구문 분석하여 레거시 환경의 모든 스키마 아티팩트에 대한 구조화된 표현을 생성합니다. 이 분석을 배포 전후의 두 버전의 코드베이스에 대해 실행하면 차이점이 레거시 스키마 변경 로그로 구성됩니다. 즉, 어떤 카피북이 변경되었는지, 어떤 필드 정의가 변경되었는지, 배포 전후의 레이아웃이 어떻게 달라졌는지 등을 파악할 수 있습니다. 이는 COBOL 계층에 적용된 스키마 스냅샷 비교입니다.

애플리케이션 종속성 매핑은 레거시 스키마에 대한 소비자 영향 레지스트리를 제공합니다. 즉, 어떤 프로그램이 각 카피북을 포함하는지, 어떤 프로그램이 어떤 플랫 파일 데이터 세트를 생성하는지, 어떤 JCL 작업이 어떤 프로그램을 호출하는지 등을 파악합니다. 스키마 변경 로그에서 수정된 카피북이 식별되면 종속성 맵은 즉시 소비자 목록, 해당 카피북을 포함하는 모든 프로그램, 그리고 이러한 프로그램들이 생성하는 모든 다운스트림 플랫 파일을 생성합니다. 이는 카피북 변경이 위험도가 낮은 내부 수정인지, 아니면 수백 개의 프로그램과 수십 개의 다운스트림 소비자에 영향을 미치는 고위험 이벤트인지를 판단하는 데 사용되는 파급 효과 범위 계산 방식입니다.

영향 분석 기능은 영향 범위를 구조화된 수정 범위로 변환합니다. 종속성 맵에서 식별된 각 소비자에 대해 새 스키마를 수용하기 위해 필요한 변경 사항과 해당 변경 사항을 적용해야 하는 순서를 파악합니다. 기존 시스템에서 최신 시스템으로 전환하는 경계 소비자, 즉 COBOL 프로그램에서 생성된 플랫 파일을 읽는 ETL 파이프라인의 경우, 영향 분석을 통해 ETL 파이프라인의 열 매핑 구성을 업데이트하여 반영해야 하는 특정 필드 위치 변경 및 데이터 유형 변경 사항을 식별합니다.

엔터프라이즈 검색 기능을 통해 스키마 아티팩트 검색이 가능합니다. 특정 바이트 위치의 필드를 읽는 모든 프로그램(레이아웃 변경의 영향을 받는 소비자 식별), 특정 필드를 정의하는 모든 카피북(버전 관리 및 변경 제어가 필요한 스키마 아티팩트 식별), 특정 데이터 세트에 출력을 생성하는 모든 프로그램(스키마 변경 시 소비자 알림을 트리거해야 하는 생산자 식별) 등을 검색할 수 있습니다. 이 검색 기능은 사전 예방적 스키마 관리 워크플로와 스키마 변경 후 사후 조사 모두를 지원합니다.

관리하는 조직의 경우 레거시 현대화 메인프레임 데이터를 최신 플랫폼으로 마이그레이션하는 것을 포함하는 프로그램, SMART TS XL스키마 분석은 마이그레이션 도구에 필요한 소스 스키마 문서를 제공하며, 데이터가 실제로 무엇인지 정의하는 완전하고 최신의 함수 파일 항목 정의 및 카피북 구조를 포함합니다. 이는 최초 마이그레이션 사양이 작성되었을 당시의 데이터 상태만이 아닙니다.

아무도 작성하지 않은 계약도 여전히 계약이다

분산 시스템에서 스키마 드리프트는 새로운 문제가 아닙니다. 이는 오래된 문제이며, 분산 아키텍처로 인해 해결하기가 더욱 어려워졌습니다. 단일 시스템에서 스키마 계약을 강제했던 중앙 DBA, 단일 애플리케이션 팀, 통합된 코드베이스와 같은 권한이 수십 개의 독립적인 서비스에 분산되어 있기 때문입니다. 각 서비스는 하위 시스템 전체에 대한 완전한 가시성 없이 개별적으로 합리적인 결정을 내립니다.

해결책은 스키마에 대한 권한을 다시 중앙집권화하는 것이 아닙니다. 암묵적인 계약을 명시적으로 만들고, 현재 상태를 기준선과 비교할 수 있는 시스템에 등록하고, 변경 사항이 도입되는 경계에서 호환성 규칙을 적용하고, 변경 사항이 전파되는 경계에서 위반 사항을 모니터링하는 것입니다. 최신 시스템의 경우 이를 위한 도구가 존재하며 빠르게 개선되고 있습니다. 하지만 최신 플랫폼과 접하는 레거시 시스템의 경우, 도구 격차가 심각하며, 클라우드 ETL 파이프라인의 스키마 계약인 플랫 파일 형식은 이를 정의하는 COBOL 소스 코드를 분석하고 스키마 아티팩트로 버전 관리하지 않는 한 모든 최신 관찰 도구에서 인식되지 않습니다.

고객 확보율이 23% 감소했다고 표시한 대시보드는 수신한 데이터 자체에는 오류가 없었습니다. 문제는 데이터의 의미를 잘못 해석했다는 것입니다. 데이터의 의미를 정의하는 스키마가 계약이 등록되지 않고 모니터링 대상이 아닌 경계선에서 변경되었기 때문입니다. 분산 시스템, 레거시 시스템이든 최신 시스템이든, 바로 그 경계선이 스키마 변경 감지 프로그램이 도달해야 할 지점입니다.