Fluentd + MongoDB 통합 뉴스 피드 구축(2)

 

# 5. 추가 개선 사항

# 5.1. 데이터 수집 주기와 배치 크기 기준은 어떻게 설정하면 좋을까? 

이전에 사용했던  logstash 에서도 데이터 수 증가( 버퍼 크기)의 문제로 데이터가 누락 또는 지연되었던 경험이 있습니다.

이 경우는 logstash 메모리 버퍼 증가로 해결하였지만, MongoDB 의 관점에서 해결할 수 있는 방법을 찾아 보았습니다.

 

1.인덱스 설계 

몽고DB는 대용량 데이터 처리에 강점이 있습니다. 

그럼에도 불구하고 더 많은 데이터가 들어온다고 가정하면 성능에 영향을 줄 수 있습니다.

불필요 인덱스를 제거 하고, TTL Index를 사용해 오래된 데이터를 정리할 수 있습니다.

 

2.샤딩

수평 확장: 데이터가 많이 쌓이면 단일 서버에서 처리할 수 있는 한계를 넘어서게 됩니다. 

이를 해결하기 위해 샤딩을 활용해 데이터를 여러 서버로 분산시킬 수 있습니다.

샤드 키 설계: 샤딩을 할 때 샤드 키(Shard Key)의 설계가 중요합니다.

잘못된 샤드 키를 선택하면 특정 샤드에 데이터가 집중되어 병목 현상이 발생할 수 있습니다.

3.데이터 처리량 모니터링
(1) 트랜잭션 및 쿼리 처리량

- TPS (Transactions Per Second): 시스템이 초당 얼마나 많은 트랜잭션을 처리할 수 있는지 보여줍니다.

 

(2) 데이터 읽기 및 쓰기 처리량

- Read Throughput:  단위 시간당 읽기 작업의 데이터량(예: MB/s)을 측정하여 읽기 성능을 모니터링.

- Write Throughput: 단위 시간당 쓰기 작업의 데이터량(예: MB/s)을 측정하여 쓰기 성능을 분석.

- IOPS (Input/Output Operations Per Second): 초당 수행되는 디스크 I/O 작업 수를 모니터링하여 디스크 성능 병목을 파악.

 

(3) 리소스 사용량

- CPU Usage (CPU 사용률): 특정 쿼리나 작업의 CPU 점유율

- Memory Usage (메모리 사용률): 캐시 히트 비율(Cache Hit Ratio), 사용 가능한 메모리,

- Disk I/O (디스크 입출력) : 읽기/쓰기 속도(MB/s), IOPS, 디스크 대기 시간(Latency)

- Storage Utilization (스토리지 사용률) : 사용 중인 스토리지, 남은 용량, 테이블/인덱스 크기 증가 추세.

- Network Usage (네트워크 사용량) : 네트워크 트래픽(입력/출력 속도), 패킷 손실률, 지연 시간(Latency) 

 

특히, MongoDB는 메모리 사용을 많이 하므로 꾸준히 모니터링하면서 메모리 사용량을 확보하는 것이 중요합니다.

 

# 5.2. 데이터 중복 제거 구현     

현재는 배치 형태로 5분 간격으로 데이터를 호출하여 적재하는 방식입니다.

실무에서 이런 경우는 데이터 중복 문제를 야기할 수 있습니다.

 

API  → fluentd → 몽고DB 의 최근 time 확인 → 그 시간 이후의 데이터만 필터링하는 방법을 사용합니다.

즉, Fluentd의 Filter 플러그인을 사용하여 MongoDB에서 조회한 최근 timestamp 이후의 데이터만 전달하도록 설정합니다.

# MongoDB에서 최근 시간 가져오기
<source>
  @type exec
  command mongo --quiet --eval "db.your_collection_name.find({}, {timestamp: 1}).sort({timestamp: -1}).limit(1)"
  tag mongo.latest_time
  run_interval 5m
</source>


# Fluentd 필터링
<filter input.data>
  @type record_transformer
  <record>
    latest_time ${tag_parts[1]}
  </record>
</filter>


<filter input.data>
  @type grep
  <regexp>
    key timestamp
    pattern ${latest_time}
  </regexp>
</filter>

# 삽입 
<match input.data>
  @type mongo
  host localhost
  database your_database_name
  collection your_collection_name
  id_key _id
</match>

 

# 5.3. 수집 데이터의 구조가 변했을 때?

1. 에러 처리를 위한 플러그인 도입, 오류 로그를 저장 및 확인
2. ETL 에서 ELT 형식으로 변경 가능한지 검토 후 선 적재 후 원하는 필터링을 다른 컬렉션으로 이동하는 방식을 사용 가능.

# 5.4 인덱스 추가 

author, title, desc, url, urlimage, publishedat, content 의 컬럼으로 이루어져 있을 때, 어떻게 인덱스를 설계하면 좋을까 ? 

 

# 5.5 배치 형태의 데이터 수집에서 실시간 처리로 전환한다면,
어떤 변경 사항이 필요할지?

1. 실시간 메시지 큐 플러그인 도입 ( CDC 등의 캡처 할 수있는 )
2. Stream Processing 도구 추가( Kafka 등 )
3. Write I/O 설정 증가 또는 Primary (write) - Secondary(read)  DB 분리 및 동기화
4. 필요한 데이터만 조회할 수 있도록 쿼리 최적화 

 

 

 

 

마침.