MongoDB로 대용량 데이터 마이그레이션

26억개의 상품 이미지의 불필요한 이미지 중복 저장 방지와 성인 이미지 검출, 이미지 사용처 확인 등 다양한 기능을 최적화해 사용하기 위해 이미지의 고유 ID와 크기, 색상 정보, 성인 이미지 점수 등 여러 정보를 MySQL에 저장해 관리
MySQL의 70% 이상을 이미지 관련 테이블, 스키마 변경시 시스템이 멈추는 hang up 상황 발생 등, DB에 영향을 미침

Kafka 생태계와 ETL 데이터를 적극 활용하는 방법을 사용해서 MySQL에서 MongoDB로의 마이그레이션
- 샤딩(sharding)을 이용한 확장이 자유로워 신규 이미지가 대규모로 유입돼도 쉽게 대응할 수 있다.
- 서비스를 최적화하기 위해 이미지 정보를 추가하는 일이 발생하는데 스키마리스(schemaless) 특성이 있어서 스키마 변경에 부담이 없다.
통합 커머스 검색에서는 누락된 이미지 재처리와 성인 이미지 점수 계산 등을 수행하는 다양한 배치 잡을 수행하고 데이터를 분석하기 위해 매일 Hadoop 기반의 사내 빅데이터 분석 플랫폼인 IU를 기반으로 ETL 작업을 진행
Hive-to-Kafka를 사용해 Spark SQL로 Hive 테이블을 조회한 결과를 JSON 형태의 Kafka 메시지로 만듬
Kafka의 메시지 압축 기능을 활용
- 높은 압축률을 달성하려면 적은 양의 메시지보다 많은 양의 메시지를 압축하는 것이 효율적
- batch.size (한 번에 전송할 수 있는 배치 크기의 상한선, default 16384 byte) & linger.ms (batch.size만큼 데이터가 모이기까지의 대기시간, default 0ms)
- linger.ms를 늘리는 것이 메시지 압축 면에서 효율적 (3000ms로 변경)

LZ77: 중복된 문자열 패턴을 찾고, 그 위치와 길이를 참조하는 방식으로 데이터를 압축 ("ABABABAB" -> "AB")
허프만 코딩: 나타나는 빈도에 따라 비트 길이를 달리하여 데이터를 추가로 압축. 자주 등장하는 문자는 짧은 비트로, 드물게 등장하는 문자는 긴 비트로 표현
Gzip: DEFLATE 알고리즘(LZ77 + 허프만 코딩), Snappy: only LZ77, Lz4: 속도가 DEFLATE에 비해 최대 10배

ETL 메시지를 MongoDB에 저장할 때 긴 시간이 걸린다면 뒤에 이어지는 CDC 기반 마이그레이션 작업에서 처리할 메시지양이 많아지고 Kafka 리소스 사용량도 많아짐.
쿠버네티스의 리소스는 충분해서 처리량을 높이기 위해 토픽의 파티션을 늘리고 그에 맞게 파드를 실행할 수 있음.
문제는 '어떻게 MongoDB가 이 높은 처리량을 감당할 수 있도록 만들까?'

MongoDB의 샤드는 Chunk라는 논리적 단위의 집합으로 구성됨