[ 클러스터 설정 API ]
클러스터 설정 조회
GET /_cluster/settings
클러스터 설정 업데이트
- persistent : 클러스터를 재시작해도 유지되는 영구 설정
- transient : 클러스터 재시작시 초기화되는 임시 설정
- 설정 적용 우선 순위는 transient > persistent > config/elasticsearch.yml
- persistent 설정은 모든 마스터 후보 노드의 path.data 경로 내 파일로 지정된다.
PUT /_cluster/settings
{
"persistent": {
"설정_키": "설정_값"
},
"transient": {
"설정_키": "설정_값"
}
}
[ _cat API를 통한 클러스터 관리와 모니터링 ]
GET _cat/health
클러스터의 전반적인 상태를 빠르게 조회한다. (green, yellow, red 구분)
GET _cat/indices
인덱스의 종류와 상태를 조회한다.
인덱스가 몇개의 샤드로 배치되었는지 복제본, 용량 등을 확인한다.
GET _cat/nodes
각 노드의 상태를 조회한다.
노드 역할, IP, heap 사용량 등을 확인한다.
GET _cat/shards
샤드의 상태를 조회한다.
샤드에 문서가 몇개 있는지, 크기와 배치된 노드 등을 파악한다.
GET _cat/stats
클러스터의 노드, 샤드, 인덱스에 대한 통계정보를 제공한다.
[ 인덱스 운영 전략 ]
템플릿과 명시적 매핑 활용
mapping이 자동으로 생성되는 것보단 최대한 명시적으로 mapping을 지정하는 것이 좋다.
라우팅 활용
라우팅 지정은 성능을 상승시킨다.
시계열 인덱스 이름
시계열 데이터를 색인한다면 인덱스 이름에도 시간 값을 넣는 것을 고려
예시) api-history-20250514
날짜를 기준으로 오래된 데이터를 백업하고 삭제하기 편하며
인덱스 생명 주기 등 관리적인 측면에서 편리하다.
alias
이미 존재하는 인덱스를 다른 이름으로도 가리키도록 하는 기능이다.
여러 인덱스를 하나의 이름으로 묶어 쿼리할 수 있다.
다만 여러 인덱스를 가리키는 alias는 단건 문서 조회 작업이 불가능하다.
alias 생성
POST _aliases
{
"actions": [
{
"add": {
"index": "logs-nginx-access-prod",
"alias": "logs"
},
"add": {
"index": "logs-nginx-access-prod-2",
"alias": "logs"
}
}
]
}
와일드 카드 사용
POST _aliases
{
"actions": [
{
"add": {
"index": "logs-*",
"alias": "all-logs"
}
}
]
}
ailas 삭제
POST _aliases
{
"actions": [
{
"remove": {
"index": "logs-nginx-access-prod",
"alias": "logs"
}
}
]
}
롤오버
특정 조건이 충족되면 새로운 인덱스를 생성하고 쓰기 작업을 새 인덱스로 전환하는 기능이다.
단일 인덱스가 크기가 너무 커져 성능을 저하하는 것을 막고,
시계열 데이터 저장시 특정 기간의 데이터를 구분하여 저장할 수 있다.
롤오버 조건
- max_age: 인덱스가 특정 시간 이상 됨 (예: "7d" - 7일)
- max_docs: 인덱스에 포함된 문서 수가 특정 숫자를 초과함 (예: 1,000,000)
- max_primary_shard_size: 프라이머리 샤드 크기가 특정 크기를 초과함 (예: "50gb")
- max_primary_shard_docs: 프라이머리 샤드 당 문서 수가 특정 숫자를 초과함 (예: 2,000)
롤오버 방식
- 데이터 스트림 사용
- 인덱스 별칭 사용
롤오버 요청
logs-alias가 가리키는 인덱스가 7일 이상이거나, 100만개 이상이거나, primary shardzmrlrk 50gb를 초과할 때
새 인덱스(logs-000002)로 롤오버 실행
POST /logs-alias/_rollover/logs-000002
{
"conditions": {
"max_age": "7d",
"max_docs": 1000000,
"max_primary_shard_size": "50gb"
}
}
Dry Run 테스트
롤오버를 실제로 적용하지 않고 테스트만 실행
POST /logs-alias/_rollover?dry_run
{
"conditions": {
"max_age": "7d"
}
}
reindex
reindex는 원본 인덱스 내 문서의 _source를 읽어서 대상 인덱스에 새로 색인하는 작업이다.
기본 요청
POST _reindex
{
"source": {
"index": "my-index-000001"
},
"dest": {
"index": "my-new-index-000001"
}
}
여러 인덱스에서 재인덱싱
POST _reindex
{
"source": {
"index": ["my-index-000001", "my-index-000002"]
},
"dest": {
"index": "my-new-index-000002"
}
}
쿼리를 사용한 선택적 재인덱싱
POST _reindex
{
"source": {
"index": "my-index-000001",
"query": {
"term": {
"user.id": "developer"
}
}
},
"dest": {
"index": "my-new-index-000001"
}
}
스냅샷과 복구
동작 중인 엘라스틱서치의 데이터 백업을 복구하는 데이터는 스냅샷을 사용한다.
스냅샷이 진행 중일 때는 샤드가 다른 노드로 이동하지 않는다.
스냅샷 저장소 등록
파일 시스템 저장소
- fs는 공유 파일 시스템을 저장소로 사용할 때 지정한다.
- location 경로는 사전에 elasticsearch.yml에 path.reop 설정으로 등록되어야 한다.
PUT _snapshot/my_backup
{
"type": "fs",
"settings": {
"location": "/mount/backups",
"compress": true
}
}
Amazon S3 저장소
PUT _snapshot/s3_backup
{
"type": "s3",
"settings": {
"bucket": "my-es-snapshots",
"region": "ap-northeast-2",
"client": "default"
}
}
스냅샷 생성
전체 스냅샷
PUT _snapshot/my_backup/snapshot_1
특정 인덱스만 포함하는 스냅샷
PUT _snapshot/my_backup/snapshot_2
{
"indices": "index_1,index_2*",
"ignore_unavailable": true,
"include_global_state": false
}
ignore_unavailable
- true: 존재하는 인덱스만 처리하고 존재하지 않는 인덱스는 무시합니다.
- false: (기본값) 지정한 인덱스가 하나라도 존재하지 않으면 오류를 발생시키고 전체 작업이 실패
include_global_state : 스냅샷에 클러스터 전역 상태를 포함할지 여부를 결정합니다. (기본 true)
스냅샷 상태 확인
GET _snapshot/my_backup/snapshot_1/_status
스냅샷 목록 조회
GET _snapshot/my_backup/_all
스냅샷에서 인덱스 복원
POST _snapshot/my_backup/snapshot_1/_restore
스냅샷 삭제
DELETE _snapshot/my_backup/snapshot_1
스냅샷 생명 주기 관리 (SLM)
자동화된 스냅샷 관리를 위해 스냅샷 생명 주기 관리(snapshot lifecycle management, SLM)를 사용합니다.
SLM 정책 생성
PUT _slm/policy/daily-snapshots
{
"schedule": "0 30 1 * * ?",
"name": "<daily-snap-{now/d}>",
"repository": "my_backup",
"config": {
"indices": ["*"],
"ignore_unavailable": true,
"include_global_state": true
},
"retention": {
"expire_after": "30d",
"min_count": 5,
"max_count": 50
}
}
- schedule : 스냅샷을 찍는 시간 지정 (UTC)
- name : 스냅샷 이름 지정
- repository : 스냅샷 저장소의 이름을 지정
- config.indices : 어떤 인덱스의 스냅샷을 찍을지 지정
- retention : 스냅샷 유지정책을 지정
SLM 정책 실행
POST _slm/policy/daily-snapshots/_execute
SLM 정책 확인
GET _slm/policy/daily-snapshots
인덱스 생명 주기 관리 (ILM)
Index Lifecycle Management (ILM)은 인덱스를 hot-warm-cold-frozen-delete 페이즈로 구분해서
지정한 기간이 지나면 다음 페이즈로 전환시키는 작업을 수행하는 기능이다.
이를 통해 저장 비용을 최적화하며 또한 아래와 같은 작업을 자동으로 수행할 수 있다.
- 인덱스가 특정 크기나 문서 수에 도달했을 때 새 인덱스로 전환(롤오버)
- 일별, 주별, 월별로 새 인덱스를 생성하고 이전 인덱스 보관
- 더 이상 필요하지 않은 인덱스를 삭제하여 데이터 보존 정책 적용
- 인덱스를 사용 패턴에 따라 적합한 데이터 계층으로 이동
생명주기 단계
핫(Hot) 단계
특징: 활발한 쓰기 및 조회가 이루어지는 단계
노드 배치: 성능이 가장 좋은 노드에 배치
가능한 작업:
우선순위 설정(Set Priority)
언팔로우(Unfollow)
롤오버(Rollover)
읽기 전용 설정(Read-Only)
다운샘플링(Downsample)
축소(Shrink)
강제 병합(Force Merge)
검색 가능 스냅샷(Searchable Snapshot)
웜(Warm) 단계
특징: 업데이트가 거의 없고 조회 빈도가 낮아진 단계
노드 배치: 중간 성능의 노드에 배치
가능한 작업:
우선순위 설정
언팔로우
읽기 전용 설정
다운샘플링
할당(Allocate)
마이그레이션(Migrate)
축소
강제 병합
콜드(Cold) 단계
특징: 더 이상 업데이트되지 않고 가끔 조회되는 단계
노드 배치: 저비용 스토리지 노드에 배치
가능한 작업:
우선순위 설정
언팔로우
읽기 전용 설정
다운샘플링
검색 가능 스냅샷
할당
마이그레이션
프로즌(Frozen) 단계
특징: 거의 조회되지 않는 데이터를 위한 단계
노드 배치: 가장 저비용 스토리지에 배치
가능한 작업:
언팔로우
검색 가능 스냅샷
삭제(Delete) 단계
특징: 데이터를 영구적으로 제거하는 단계
가능한 작업:
스냅샷 대기(Wait For Snapshot)
삭제(Delete)
페이즈 전환 예시
다음과 같은 시나리오로 인덱스를 자동 운영할 수 있다.
페이즈 전환에는 시간 조건을 사용하였다.
처음 hot 페이즈에서는 매일 자동으로 롤오버를 수행하고, 3일이 지난 인덱스는 warm 페이즈로 전환된다.
warm 페이즈는 읽기 전용 인덱스로 바꾸고 단일 세그먼트로 강제 병합한다.
7일지난 인덱스는 cold 페이즈로 전환되고 성능이 떨어지느 노드로 이동시킨 후 샤드 복구 우선순위를 낮춘다.
30일이 지난 인덱스는 delete 페이즈로 이동시킨다. 스냅샷으로 백업을 진행한다.
ILM 정책 생성과 적용
- 인덱스 크기가 50GB에 도달하거나 30일이 경과하면 롤오버
- 롤오버 후 2일이 지나면 warm 단계로 이동, 샤드 수를 1개로 줄이고 세그먼트 병한
- 롤오버 후 7일이 지나면 cold 단계로 이동, cold node로 이동
- 롤오버 후 30일이 지나면 인덱스 삭제
PUT _ilm/policy/metrics_policy
{
"policy": {
"phases": {
"hot": {
"actions": {
"rollover": {
"max_size": "50GB",
"max_age": "30d"
}
}
},
"warm": {
"min_age": "2d",
"actions": {
"shrink": {
"number_of_shards": 1
},
"forcemerge": {
"max_num_segments": 1
}
}
},
"cold": {
"min_age": "7d",
"actions": {
"allocate": {
"require": {
"data": "cold"
}
}
}
},
"delete": {
"min_age": "30d",
"actions": {
"delete": {}
}
}
}
}
}
[ 서킷 브레이커 ]
노드가 중단되는 문제를 발생시킬만한 무거운 작업의 수행을 미리 차단하는 역할을 한다.
- 특정 작업이 너무 많은 메모리를 사용하는 것을 방지
- JVM 힙 메모리 부족으로 인한 노드 실패 예방
- 클러스터의 안정적인 성능 저하 방지
필드 데이터 서킷 브레이커
- indices.breaker.fielddata.limit (default 40%)
- fielddata가 메모리에 올라갈 때 얼마만큼 메모리를 사용할지 예상
요청 서킷 브레이커
- Indices.breaker.request.limit (default 60%)
- 요청 하나의 데이터 구조가 메모리를 과다하게 사용하는지 계산
부모 서킷 브레이커
- 모든 서킷 브레이커의 총 메모리 사용량 제어
- indices.breaker.total.use_real_memory: true 면 indices.breaker.total.limit: 95%
- indices.breaker.total.use_real_memory: false 면 indices.breaker.total.limit: 70%
서킷 브레이커 설정
PUT /_cluster/settings
{
"persistent": {
// 부모 서킷 브레이커 설정
"indices.breaker.total.use_real_memory": true,
"indices.breaker.total.limit": "95%",
// 필드 데이터 서킷 브레이커 설정
"indices.breaker.fielddata.limit": "40%",
"indices.breaker.fielddata.overhead": 1.03,
// 요청 서킷 브레이커 설정
"indices.breaker.request.limit": "60%",
"indices.breaker.request.overhead": 1.0
}
}
- indices.breaker.total.use_real_memory는 정적 설정이므로 노드 재시작이 필요
- 다른 설정들은 동적으로 변경 가능
- 하위 브레이커들의 합(40% + 60% = 100%)이 부모 브레이커 제한(95%)을 초과하지 않도록 주의
현재 서킷 브레이커 상태 확인
GET /_nodes/stats/breaker
[ 슬로우 로그 설정 ]
검색이나 색인 작업 시 너무 오랜 시간이 소요되면 별도로 로그를 남기도록 설정한다.
성능 문제를 진단하고 최적화가 필요한 쿼리를 식별하는데 유용하다.
기본값은 어떤 설정도 되어 있지 않다.
설정 이후에 {Cluster_name}_index_search_slowlog.log 파일이 생서된다.
모든 인덱스에 대한 슬로우 로그 설정
PUT /_all/_settings
{
"index.search.slowlog.threshold.query.warn": "10s",
"index.search.slowlog.threshold.fetch.warn": "1s",
"index.indexing.slowlog.threshold.index.warn": "10s",
"index.search.slowlog.include.user": true
}
검색 슬로우 로그 예시
{
"@timestamp": "2024-12-11T22:34:22.613Z",
"elasticsearch.cluster.name": "my-cluster",
"elasticsearch.node.name": "node-1",
"elasticsearch.slowlog.id": "search-123",
"elasticsearch.slowlog.search_type": "QUERY_THEN_FETCH",
"elasticsearch.slowlog.source": "{\"query\":{\"match_all\":{}}}",
"elasticsearch.slowlog.took": "747.3micros",
"elasticsearch.slowlog.total_hits": "1000 hits",
"log.level": "WARN",
"user.name": "elastic"
}
- query: 쿼리 실행 단계의 임계값
- fetch: 결과 가져오기 단계의 임계값
- 각 단계별로 4가지 로그 레벨(warn, info, debug, trace) 설정 가능
- include.user: 사용자 정보 포함 여부
인덱싱 슬로우 로그 예시
{
"@timestamp": "2024-12-11T22:34:22.613Z",
"elasticsearch.index.name": "my-index-000001",
"elasticsearch.slowlog.source": "{\"key\":\"value\"}",
"elasticsearch.slowlog.took": "0.01ms",
"log.level": "WARN",
"user.name": "elastic"
}
- index: 문서 인덱싱 작업의 임계값
- source: 로그에 포함할 문서 소스의 최대 문자 수
- reformat: 소스 포맷팅 여부
'DataPipeline > Elasticsearch' 카테고리의 다른 글
| Elasticsearch 바이블 - 4장 검색 및 집계 API (0) | 2025.05.11 |
|---|---|
| Elasticsearch 바이블 - 3장 인덱스 설계 (0) | 2025.04.27 |
| 엘라스틱서치 바이블 - 2장 기본동작과 구조 (0) | 2025.04.15 |
| Logstash - pipelines.yml을 통한 다중 파이프라인 (0) | 2024.11.26 |
| Logstash - Json, Mutate, Roby, Date (0) | 2024.11.26 |