1. 대량 데이터 처리의 중요성
Elasticsearch는 대량의 데이터를 빠르게 검색하고 분석할 수 있는 분산형 검색 엔진이지만, 적절한 데이터 처리 전략이 없으면 성능 저하와 클러스터 불안정이 발생할 수 있다. 특히 데이터 삽입(Bulk Insert), 데이터 파티셔닝, 시간 기반 인덱싱과 같은 전략을 활용하면 효율적인 데이터 처리가 가능하다.
2. 대량 데이터 삽입(Bulk Insert)
Elasticsearch는 개별 문서를 하나씩 삽입하는 방식보다 **벌크 API(Bulk API)**를 활용하여 여러 개의 문서를 한 번에 삽입하는 것이 훨씬 효율적이다.
(1) Bulk API 활용
Bulk API는 한 번의 요청으로 여러 개의 문서를 삽입할 수 있도록 설계되었다. 이를 활용하면 네트워크 오버헤드를 줄이고, 인덱싱 성능을 극대화할 수 있다.
예제 코드 (Python Elasticsearch 라이브러리 사용)
from elasticsearch import Elasticsearch, helpers
es = Elasticsearch(["http://localhost:9200"]) # Elasticsearch 클러스터 연결
# 샘플 데이터 생성
data = [
{"_index": "test-index", "_id": i, "_source": {"name": f"User {i}", "age": i % 50}}
for i in range(100000)
]
# Bulk API를 이용한 데이터 삽입
helpers.bulk(es, data)
(2) Bulk Insert 시 고려해야 할 사항
- 배치 크기 조절: 너무 큰 배치는 클러스터 부하를 초래할 수 있으므로, 적절한 크기(예: 5,000~10,000 문서)를 설정
- CPU 및 메모리 부하 관리: 백그라운드에서 데이터를 점진적으로 삽입
- 리프레시 간격 조정: refresh_interval을 조절하여 인덱싱 성능 향상 (refresh_interval=-1 설정 후 일괄 삽입 후 복원)
설정 예제
PUT test-index/_settings
{
"index": {
"refresh_interval": "-1"
}
}
벌크 삽입 후 복원
PUT test-index/_settings
{
"index": {
"refresh_interval": "1s"
}
}
3. 데이터 파티셔닝 (Shard & Index Design)
Elasticsearch는 샤딩(Sharding)과 인덱스 설계(Index Design)를 적절히 설정하면 대량 데이터 처리를 더욱 효율적으로 할 수 있다.
(1) 샤드 개수 조정
샤드는 Elasticsearch에서 데이터를 저장하는 기본 단위이며, 클러스터 성능에 큰 영향을 미친다.
- 샤드 개수는 데이터 크기와 노드 수를 고려하여 설정
- 너무 많은 샤드는 관리 오버헤드를 증가시킴
- 샤드 크기는 10GB~50GB 정도가 적절함
샤드 개수 계산 공식
샤드 개수 = 예상 데이터 크기(GB) / 50GB
예를 들어, 예상 데이터 크기가 500GB이면, 샤드 개수는 500GB / 50GB = 10개
(2) 인덱스 설계 전략
- 수직 파티셔닝: 서로 다른 유형의 데이터를 별도의 인덱스로 나누어 저장 (예: 로그 데이터, 사용자 데이터 분리)
- 수평 파티셔닝: 동일한 유형의 데이터를 여러 개의 샤드에 분산 저장하여 부하 분산
- Alias 활용: 여러 개의 인덱스를 가상으로 하나의 인덱스로 취급하여 데이터 검색 시 유연성 증가
Alias 예제
POST _aliases
{
"actions": [
{
"add": {
"index": "log-2023-*",
"alias": "logs"
}
}
]
}
4. 시간 기반 인덱싱(Time-Based Indexing)
대량의 데이터를 처리할 때, 시간 단위로 인덱스를 생성하여 관리하는 방식이 유용하다. 특히 로그 데이터, IoT 데이터, 이벤트 스트리밍 데이터에서 많이 활용된다. 다만 스프링과 같이 사용하는 경우 Alias로 관리할 필요가 있다.
(1) 시간 기반 인덱스 설계
- 일일 인덱스 (daily index): logs-YYYY-MM-DD
- 주간 인덱스 (weekly index): logs-YYYY-WW
- 월간 인덱스 (monthly index): logs-YYYY-MM
예제: ELK 스택에서 로그 관리할 경우
PUT logs-2024-03-01
{
"settings": {
"number_of_shards": 3,
"number_of_replicas": 1
}
}
(2) ILM (Index Lifecycle Management) 적용
시간이 지나면 데이터를 자동으로 이동시키는 정책을 설정하여 저장 비용을 절감할 수 있다.
ILM 정책 예제
PUT _ilm/policy/logs_policy
{
"policy": {
"phases": {
"hot": {
"actions": {
"rollover": {
"max_size": "50GB",
"max_age": "7d"
}
}
},
"warm": {
"actions": {
"allocate": {
"include": { "_tier_preference": "warm" }
}
}
},
"cold": {
"actions": {
"allocate": {
"include": { "_tier_preference": "cold" }
}
}
}
}
}
}
5. 결론
- 대량 데이터 삽입 시 Bulk API를 활용하여 네트워크 부하를 줄이고 성능을 극대화
- 샤드 개수와 인덱스 설계를 최적화하여 데이터 처리 성능을 개선
- ILM을 도입하여 오래된 데이터를 자동으로 관리하고 저장 비용 절감
'트러블슈팅&기술선택' 카테고리의 다른 글
| Kafka 메시지 순서 보장 및 중복 메시지 처리 문제 (0) | 2025.03.20 |
|---|---|
| Kafka를 선택한 이유: Redis PUB/SUB, RabbitMQ와의 비교 (0) | 2025.03.20 |
| Elasticsearch 클러스터 구성 및 운영 전략 (0) | 2025.03.20 |
| Elasticsearch의 클러스터링 적용 이유 (0) | 2025.03.19 |
| Elasticsearch의 실제 검색 속도 테스트 (0) | 2025.03.19 |
