꿈라CBT다음 <보기>의 요구에 맞는 수집 아키텍처로 가장 적절한 것은?
보기
O 사는 다음 세 가지 원천을 하나의 분석 플랫폼으로 모으려 한다.
| 원천 | 특성 | 요구 |
|---|---|---|
| ㉠ 주문 DB | 운영 중인 RDB, 일 30만 건 변경 | 운영 부하 최소화, 5분 이내 반영 |
| ㉡ 앱 이벤트 | 초당 2만 건 클릭·화면 이동 | 여러 팀이 같은 스트림을 각자 소비 |
| ㉢ 제휴사 파일 | 매일 새벽 CSV 1개 제공 | 정해진 시각 일괄 적재 |
- 1㉠~㉢ 모두 Sqoop 야간 전체 적재로 통일한다. 도구를 하나로 맞추면 운영이 단순해지고, 초당 2만 건의 이벤트도 하루치를 모아 한 번에 처리하면 충분하다.
- 2㉠은 5분 주기로 주문 테이블 전체를 반복 조회해 최신 상태를 유지하고, ㉢은 실시간성이 중요하므로 Kafka로 전환해야 한다.
- 3㉡의 이벤트는 Flume으로 수집해 특정 저장소 한 곳에 적재하면 되고, 여러 팀이 필요할 때는 그 저장소를 각자 조회하게 하면 되므로 발행-구독 구조는 불필요하다.
- 4㉠은 변경분만 가져오는 CDC로 부하를 낮추고, ㉡은 여러 소비자가 독립적으로 읽는 Kafka 발행-구독으로 수집하며, ㉢은 배치 스케줄러로 일괄 적재한다.