최근 운영 중인 Elasticsearch 클러스터에서 아침에 계속 알림이 울려됬다.
디스크 용량을 85% 이상치로 잡았는데, 계속 알림이 오고 있었다.
Duration
0 min
impacted entity (Target)
data-prd-es-09-data
condition
DISK USAGES - 85%
policy
DataPlatform System Policy
Issue name (Threshold)
Disk Used % > 85.0 for at least 2 minutes on 'data-prd-es-09-data'
해당 es는 데이터 서버가 4대로 구성되어 있다. 그중에서 9번에만 남은 용량이 없는것
샤드 수는 절반인데, 디스크는 다른 노드와 비슷하거나 더 높다.
| 노드 | 샤드수 | 디스크 사용률 | 디스크 남은 용량 |
| g-06 | 1767 | 71% | 142GB |
| g-07 | 1767 | 73% | 132GB |
| g-08 | 1768 | 80% | 94GB |
| g-09 | 950 | 89% | 75GB |
1. 확인
샤드가 한 노드로 몰릴 때 흔히 의심하는 부분은 다음과 같다.
- rebalance가 꺼져 있는지
- allocation이 제한되어 있는지
- disk watermark 때문에 이동이 막혔는지
- 특정 노드가 exclude 되었는지
GET _cluster/settings?include_defaults=true
결과값에는 딱히 이상이 없었다.
- rebalance = all
- allocation = all
- disk watermark도 여유 있음
- max_shards_per_node도 충분
- exclude 설정도 없음
그냥 용량과 샤드 수에 따라 분배를 했어야 하는데, 밸런스 있게 저장하다보니, 과하게 큰 샤드들을 하필 9번 서버가 다 맡은거
2. 조치
샤드 크기 순으로 정렬
GET _cat/shards?v&h=index,shard,prirep,store,node&s=store:desc
위의 쿼리로 확인해 보니 node=g-09에 큰 샤드가 몰려 있었다.
3. 해결
g-09에 몰린 ‘대형 샤드’를 다른 데이터 노드로 옮기면 된다.
예를 들어 app_log-2025.11.26 인덱스의 0번 샤드를 g-09에서 g-07로 보내고 싶다면 다음 쿼리를 실행하면 된다.
POST /_cluster/reroute
{
"commands": [
{
"move": {
"index": "app_log-2025.11.26",
"shard": 0,
"from_node": "data-prd-es-09-data",
"to_node": "data-prd-es-07-data"
}
}
]
}
2~3개만 이동해도 바로 노드 간 용량 균형이 잡힌다.
Elasticsearch는 샤드 수 기준으로만 자동 분산을 맞추기 때문에 샤드 크기 불균형은 생각보다 자주 발생한다.
모니터링할 때 샤드 수뿐 아니라 샤드 사이즈 분포도 같이 보지 않으면 이렇게 고생한다..ㅜㅡㅜ
'Database > elastic search' 카테고리의 다른 글
| elastic search heap memory 확보하기 (0) | 2025.11.29 |
|---|---|
| [es] monitoring 설정 (0) | 2025.11.07 |
| [es] ILM + rollover 설정 (0) | 2025.11.05 |
| elastic search ingest (0) | 2025.09.02 |
| illegal argument exception (1) | 2025.07.25 |