인프런 커뮤니티 질문&답변
작성한 질문수
커넥트를 이용한 데이터 마이그레이션 질문드립니다
작성
·
537
·
수정됨
0
안녕하세요, 양질의 강의 항상 감사드립니다!
다름이 아니라 현재 실무에서 스프링 배치를 이용해서 데이터를 DB to DB 로 마이그레이션하는 업무가 있는데 이를 강의에서 배운 카프카 커넥트를 활용하면 좋을것 같아서 고민중인데 잘 안풀리는 부분이 있어 질문드립니다
데이터 가공문제
DB to DB 로 이관시 가장 좋은것은 커넥트만 써서 코드개발없이 마이그레이션 해버리는 것이 좋을것같은데 막상 실제 마이그레이션 할 때는 source 에서 퍼온 데이터를 sink 시 몇몇 컬럼은 데이터 가공하거나 없어지는 등 가공에 약간 손을 봐야하는 경우가 종종 있어서 이런 케이스에 대해 어떻게 해결을 해야할 지 고민입니다.
고민을 해봤을 때 해결방안으로는 streams api 를 껴서 아래와 같은 아키텍쳐로 해결하는 방법이 있을 것 같은데요
source -> topic -> kafka stream api 등을 통해 데이터 가공 후 topic 전송 -> sink
커스텀 sink 나 source 커넥터 개발
어느 방법이나 결국 추가개발이 필요한건 매한가지라 현재 배치로 개발해놓은 구조를 커넥트를 이용하도록 바꿨을 때 이점이 명확하게 안보여서 좀 고민입니다...
데이터 마이그레이션 후 검증문제
실무에서 배치로 마이그레이션 후 원본데이터가 있는 source db 와 마이그레이션 한 sink db 간에 건수비교 등 데이터 이관이 잘 되었는지 대사비교를 진행하는데요, 카프카 커넥트로 전환한다고 해도 이러한 대사비교는 여전히 필요하지 않을까 싶은데 실무에서 카프카 커넥트를 활용할 때 이러한 검증 문제를 어떻게 해결하는지 궁금합니다
카프카 커넥트를 실무에서 활용한 경험이 없다보니.... 강사님이라면 이러한 문제에 직면했을때 어떤 생각을 가지실 지 궁금합니다!
감사합니다:)
답변 1
1
안녕하십니까,
Kafka Connect는 실시간으로 DB와 DB간을 연동하는데 매우 뛰어난 기능을 제공하지만, DB to DB의 초기 이관 용도로는 적합하지 않습니다.
특히 전체 데이터가 크다면 DB to DB로 초기 이관 시 Kafka Connect를 사용하는 방식을 권장하고 싶지는 않습니다. 예를 들어 Source DB가 100GB 이상의 데이터라면 Source DB에서 Kafka Topic으로 이동하고 다시 Target DB로 이동하는데 배치로 데이터를 이관하는 것 보다 더 많은 시간이 걸릴 수 있습니다. 데이터가 20GB 이하 정도라면 초기 이관 시 Kafka Connect를 테스트 해볼 수는 있습니다.
Kafka Connect를 이관에 사용하는 경우는 주로 Source DB를 Down 시키지 않는 상태에서 Target DB로 이관할 때 사용할 수는 있는데, 이는 이관에 대한 매우 전문적인 기술이 필요한 사항입니다.
그럼에도 불구하고 Kafka Connect를 이관에 사용하고자 한다면, Sink(Target) DB로 입력되는 데이터의 변경이 있을 경우 아래와 같은 사항을 고려해 볼 수 있습니다.
2-1. 이관 후에도 Source DB와 Sink DB를 계속 연동할 예정이라면 SMT를 이용하면 좋을 것 같습니다. SMT 로 변경이 어려운 로직이라면 말씀하신 Streams API를 사용하는 것도 좋은데, Streams API 보다는 KSQLDB가 좀더 사용하기 쉽습니다.
2-2. 단지 이관용으로만 Connect를 사용한다면, 데이터 변경은 Connect로 하지 말고, 이관 후에 Target DB에서 일괄 변경하는 것이 더 좋다고 생각합니다.
Kafka Connect를 이관에 사용하면 장점은 검증에 대한 부담이 적다는 것입니다. redo log 파일 레벨로 데이터가 이관되기 때문에 정합성은 보장이 될 것입니다. 하지만 데이터 이관에서 데이터 검증은 중요하며 반드시 수행되어야 하는 프로세스 입니다. 때문에 redo log 레벨로 데이터를 복제해서 이관하더라도 중요 테이블의 검증은 반드시 수행되어야 합니다.
감사합니다.