Method to test whether the original and migrated data are identical

[yunkon-kim]

Note

It will be a long-term task

(회의록) 데이터 마이그레이션 관련, 데이터 무결성 테스트 메커니즘이 어떻게 되는지?

• 원본과 마이그레이션 된 데이터 간에 동일한지 여부 테스트 방안
• (Action Item) 요소/기준 파악 및 공유

[heedaeshin]

• 내부적으로 검토중이며, 해당 내용은 v0.3.0 릴리즈 이후로 진행하도록 하겠습니다.

[heedaeshin]

Note

It will be a long-term task

(회의록) 데이터 마이그레이션 관련, 데이터 무결성 테스트 메커니즘이 어떻게 되는지?

• 원본과 마이그레이션 된 데이터 간에 동일한지 여부 테스트 방안
• (Action Item) 요소/기준 파악 및 공유

데이터 무결성 관하여 문의 드립니다.

• 데이터 무결성 관련으로 이슈난 사례에 관한 자료나 링크 부탁드립니다.

[yunkon-kim]

@heedaeshin

데이터 백업 및 복구, 마이그레이션 관점에서 볼 때 이슈가 없도록 만들기 위한 기본 기능일 것 같습니다 ^^:;

급하게 추진되어야 할 사안은 아니니 데이터 백업 및 복구, 마이그레이션 기술을 개발하시면서 관련 자료 조사 및 (안)을 마련하셔서 공유/제안해 주시기 바랍니다.

[yunkon-kim]

@heedaeshin

아직 공유된 바가 없어 Reopen하였습니다. 조사하신 자료가 있으시거나 추진(안)을 마련하셨으면 공유해 주시기 바랍니다.

[heedaeshin]

@yunkon-kim

데이터 무결성 추진 방안

1. 오브젝트 스토리지 (Object Storage)

• TCP 전송 기반 활용

  • 파일 전송 시 TCP의 무결성 보장을 이용하여 개별 파일 단위 데이터 무결성 확보.

• 오류 처리

  • TCP 전송 실패 시에만 오류를 기록하고 재시도를 수행.

• 재시도 전략 최적화

  • 반복적인 재시도로 인한 시스템 부담을 줄이기 위해 지수 백오프(Exponential Backoff) 전략 적용.

• 로그 상세화

  • 실패한 요청에 대한 상세 로그를 기록하여 원인 분석을 용이하게 함.
    • 실패한 요청 내용, 에러 메시지, 재시도 횟수 등을 포함.

• 전송 상태 모니터링

  • 실시간 전송 상태 모니터링 및 대시보드를 통해 실패 상황을 신속하게 인지.

• 전송 재개 구현

  • 실패 지점부터 전송을 재개하는 로직 구현.
  • 샘플링 기법을 활용하여 무결성을 직접 비교하고, 검증 후 작업 재개.

• 무결성 추가 검증 옵션

  • 파일의 체크섬(예: SHA-256)을 생성하여 전송 후 무결성 검증 추가.
  • 중요한 데이터인 경우 Hash 값 교차 검증

---

2. 관계형 데이터베이스 (RDB)

• 트랜잭션 활용

  • 데이터의 무결성을 보장하기 위해 트랜잭션 사용.

• DDL 명령어 우선 실행

  • 데이터 정의 언어(DDL) 명령어를 다른 작업보다 먼저 실행.

• DDL 명령어의 트랜잭션 처리

  • 일부 RDBMS에서는 DDL 명령어가 트랜잭션 내에서 실행되지 않거나 자동 커밋될 수 있음.
    • 예: PostgreSQL에서는 CREATE DATABASE 명령어를 트랜잭션 블록 내에서 실행할 수 없음.
  • RDBMS별로 DDL과 트랜잭션의 동작 방식을 확인하고, 필요 시 DDL과 DML 작업을 분리하여 처리.

• 오류 처리

  • 트랜잭션 실패 시 롤백 수행.
  • 최대 3회까지 자동 재시도하고, 재시도 후에도 실패 시 오류를 기록.

• 재시도 전략 최적화

  • 시스템 부담을 줄이기 위해 지수 백오프 전략 적용.

• 로그 상세화

  • 실패한 트랜잭션에 대한 상세 로그를 기록하여 원인 분석을 용이하게 함.
    • 실패한 쿼리, 에러 메시지, 재시도 횟수 등을 포함.

• 전송 상태 모니터링

  • 실시간 전송 상태 모니터링 및 대시보드를 통해 실패 상황을 신속하게 인지.

• 전송 재개 구현

  • 실패 지점부터 전송을 재개하는 로직 구현.
  • 덤프나 샘플링 기법을 활용하여 무결성을 직접 비교하고, 검증 후 작업 재개.

• 무결성 추가 검증 옵션

  • 트랜잭션 성공 후 데이터의 정합성을 추가로 검증.
  • 중요한 데이터에 대한 무결성 검사 및 데이터 타입 일관성 확인.
  • Schema 이관 옵션
    • Index, Constraints, Procedures. Function, Trigger, View, Sequences, Users, ...etc

---

3. 비관계형 데이터베이스 (NRDB)

• 트랜잭션 활용

  • 데이터의 무결성을 보장하기 위해 트랜잭션 사용.
  • 비관계형 DB는 RDB와 다른 무결성 보장 메커니즘을 가질 수 있음.
    • 예: MongoDB는 트랜잭션을 지원하지만 RDBMS보다 제한적임.

• DDL 명령어 우선 실행

  • 데이터 정의 언어(DDL) 명령어를 다른 작업보다 먼저 실행.

• 오류 처리

  • 트랜잭션 실패 시 롤백 수행.
  • 최대 3회까지 자동 재시도하고, 재시도 후에도 실패 시 오류를 기록.

• 재시도 전략 최적화

  • 시스템 부담을 줄이기 위해 지수 백오프 전략 적용.

• 로그 상세화

  • 실패한 트랜잭션에 대한 상세 로그를 기록하여 원인 분석을 용이하게 함.
    • 실패한 쿼리, 에러 메시지, 재시도 횟수 등을 포함.

• 전송 상태 모니터링

  • 실시간 전송 상태 모니터링 및 대시보드를 통해 실패 상황을 신속하게 인지.

• 전송 재개 구현

  • 실패 지점부터 전송을 재개하는 로직 구현.
  • 덤프나 샘플링 기법을 활용하여 무결성을 직접 비교하고, 검증 후 작업 재개.

• 무결성 추가 검증 옵션

  • 트랜잭션 성공 후 데이터의 정합성을 추가로 검증.
  • 중요한 데이터에 대한 무결성 검사 수행.

---

추가 고려 사항:

• CSP 기능 활용 시 고려사항:

  • 보안 및 규정 준수: CSP의 기능을 활용, 필수: 데이터 보안과 규정 준수를 확인 및 경고 필요
  • 비용 효율성: CSP 서비스는 사용량에 따라 비용이 발생 예산을 고려

• 레플리카 및 클러스터링의 활용 가능성:

  • 데이터 일관성 유지: 레플리카를 통해 데이터 이관 중, 소스 데이터베이스의 변경 사항 반영 가능
  • 다운타임 최소화: 클러스터링을 통해 서비스 중단 없이 데이터 이관 진행 가능

[yunkon-kim]

@heedaeshin

본 내용은 추진 스케줄을 조정하면 좋겠다는 의견이 공유되었습니다. 지난 회의 내용 참고하셔서 추진해 주시면 될 것 같습니다.

그리고, 공유해주신 내용인 데이터 자체의 무결성을 확인하는 것과는 조금 다르다는 생각이 들어 의견을 남겨 놓습니다. "안정적인 절차/프로토콜을 사용하기 때문에 데이터가 무결할 것"이라는 접근법(?) 으로 보입니다. 추후 진행하실 때 관련해서 살펴봐 주시면 좋을 것 같습니다.

[heedaeshin]

@yunkon-kim
위의 글에는

무중단 DB 대상
무결성을 보증하는 프로토콜에
의존한 간접적인 방법론과
중단 DB 대상
DB 전체 덤프 후 전체 혹은 샘플링 비교 검증하는
직접적인 방법론이 포함되어 있습니다

중단 DB 대상으로는 직관적으로
소스DB 덤프파일과 타겟DB 덤프파일 비교하는게 가장 합리적입니다.
체크섬을 이용할수 있지만 부분 비교에 불과하고
특히 스키마 비교가 안되어 데이터 무결성은 부분 보장하지만 DB 무결성은 보장되지 않습니다.
그럼 덤프파일을 전체 비교해야하는데
옵션으로 해쉬값 부분 샘플하여 비교할 예정입니다.

---

개인적으로는 고도화 되기전에
메세징 시스템을 넣는게 좋지 않을까 생각됩니다.
kafka, NATS, NSQ
프로젝트 관련성은 NATS가 제일 높다고 생각합니다.

data-manager 인터페이스에서의 차이가 있지
코어한 기능들의 요구 사항은 볼수록 위의 시스템을 추구하고 지향하지 않나 보고 있습니다.

[yunkon-kim]

@heedaeshin

자세히 설명해 주셔서 감사합니다.
우선순위가 낮아보여서 말씀드렸었는데, 괜한 말씀드린 것 같습니다 ^^;;

추가로, 제안해주신 메시징 시스템이나 통신 프로토콜의 필요성은 제일 잘 알고 계실 것 같습니다.
다만, 외부 공개SW 도입은 커뮤니티 차원의 검토 및 결정이 필요한 사항입니다.
따라서, 도입을 위한 라이선스 검증, 타당성 검증, PoC 등을 수행해보시고 협의 회의를 추진해 주시면 좋을 것 같습니다.

참고 - 검증/PoC는 간단히 진행하시는 것을 제안 드립니다. 도입이 불가 할 수도 있습니다 ;;

개인적으로는 고도화 되기전에
메세징 시스템을 넣는게 좋지 않을까 생각됩니다.
kafka, NATS, NSQ
프로젝트 관련성은 NATS가 제일 높다고 생각합니다.

data-manager 인터페이스에서의 차이가 있지
코어한 기능들의 요구 사항은 볼수록 위의 시스템을 추구하고 지향하지 않나 보고 있습니다.

(별도의 Issue를 생성해 놓겠습니다.)