내가 직접 찾아보고, 검토 후 적용을 성공적으로 마쳤다.
- 성공에 기여했던 부분
- kafka 인스턴스 생성 > m5.large로 비교적 넉넉한 리소스를 받았다. 모니터링해보니 리소스 자원은 50%밑을 유지 중이다.
- 운이 좋게도 debezium mariadb 공식지원이 되었다. 2023/12 월부터 지원하는지라 걱정이 많았지만, mysql과 동일하게 잘 된다.
- 커넥터 커스터 마이징. 의도했던 대로 debezium 전용 컬럼 추가 없이 데이터 동기화가 잘 되었다. 정규식의 소중함을 알게 되었다.
- 위기가 될 수 있었던 부분
- 처음 수집 커넥터 설정 시 테이블&로우 락에 대한 부분. 서비스가 작동하지 않는 시점에 적용했으나 걱정이 되었다. 하지만 예상대로 락은 발생하지 않았다.
- 컨슘 커넥터 설정 시 특정 테이블은 동기화 되지 않았던 문제. 수집 커넥터에 여러 테이블을 묶어 적용했을 때, 문제가 없었다. 당연히 컨슘커넥터도 여러 테이블을 묶었는데, 1개 테이블이 동기화 되지 않았다. 결국 테이블 한개당 하나씩 컨슘 커넥터를 적용해 성공했다. 관리 측면에서 후자가 더 나은 것 같긴하다.
- 카프카 인스턴스 설정이 아닌, MSK 설정으로 debezium 적용. msk가 공식적으로 지원하는 듯하나, 시행착오가 분명 존재할 것으로 예상되었다. 나중에 시간이 되면 스터디 해야겠다.
- fail Over. 일단 카프카의 포트로 헬스체크를 하기로 했다. debezium의 장점은 브로커나 커넥터가 죽었더라도 재 기동 시 성공 이후의 시점 데이터를 알아서 읽어서 처리하는 것이다.
- 서서히 알아봐도 될 부분
- 컨슘, 수집커넥터가 중복되면 동기화가 루프가 될 것 같은데, 이를 방지할 방안
- AWS msk 적용가능 여부
- kafka 주키퍼, 브로커, 커넥터를 모니터링 할 수단