Elasticsearch 일일 백업 및 복원 작업 모범 사례

일일 백업은 복제본으로 해결할 수 없는 오류(실수로 인한 삭제, 잘못된 매핑, 손상된 데이터, 실패한 업그레이드, 전체 클러스터 손실)로부터 Elasticsearch 클러스터를 보호합니다. 복제본은 가용성을 높이는 데 도움이 되지만, 알려진 정상 복사본으로 되돌릴 수 있게 해주는 것은 스냅샷입니다.

Elasticsearch 일일 백업 및 복원 작업에 대한 이러한 모범 사례는 리포지토리 설정, 스냅샷 수명 주기 관리(SLM), 복원 테스트, 그리고 인덱스 수명 주기 관리(ILM)가 적용되는 부분을 다룹니다.

Elasticsearch 스냅샷 메커니즘 이해

Elasticsearch 스냅샷은 단순한 파일 복사본이 아닙니다. Lucene 인덱스의 내부 구조를 활용하는 증분식입니다. 즉, 초기 전체 스냅샷 이후의 후속 스냅샷은 마지막으로 성공한 스냅샷 이후 변경된 데이터 세그먼트만 저장하므로 시간과 스토리지 측면에서 매우 효율적입니다.

스냅샷은 두 가지 주요 구성 요소를 캡처합니다.

인덱스 데이터: 선택한 인덱스의 실제 Lucene 세그먼트입니다.
클러스터 상태: 메타데이터, 영구 설정, 인덱스 템플릿, 파이프라인 및 역할입니다.

1. 스냅샷 리포지토리 설정

스냅샷을 생성하기 전에 리포지토리(스냅샷 파일이 저장될 안전한 위치)를 등록해야 합니다. 리포지토리 선택은 내구성과 복구 속도에 매우 중요합니다.

리포지토리 유형

리포지토리 유형	설명	가장 적합한 경우	요구 사항
`fs` (공유 파일 시스템)	모든 마스터 및 데이터 노드에서 액세스할 수 있는 로컬 또는 네트워크 마운트 드라이브입니다.	소규모 클러스터, 빠른 로컬 백업.	`elasticsearch.yml`(`path.repo`)에 등록되어야 합니다.
`s3`, `azure`, `gcs`	클라우드 스토리지 서비스입니다. 일부 배포판 및 버전에서는 이러한 리포지토리 유형을 번들로 제공합니다. 다른 경우에는 모든 노드에 일치하는 리포지토리 플러그인을 설치해야 합니다.	프로덕션 환경, 재해 복구.	버전에 적합한 리포지토리 지원 및 적절한 IAM/서비스 주체 자격 증명이 필요합니다.

예: S3 리포지토리 등록

프로덕션 환경의 경우 내구성과 오프사이트 복구를 위해 클라우드 스토리지가 일반적으로 더 나은 선택입니다. Elasticsearch 버전에 대한 리포지토리 지원을 확인하고, 자격 증명을 안전하게 구성한 다음, API를 통해 리포지토리를 등록하세요.

PUT /_snapshot/my_s3_daily_repo
{
  "type": "s3",
  "settings": {
    "bucket": "es-backup-bucket-name",
    "region": "us-east-1",
    "base_path": "daily_snapshots/production",
    "compress": true
  }
}

팁: 구성된 버킷 또는 파일 시스템 경로가 안전하고, (공급자가 지원하는 경우) 변경 불가능하며, 백업 전용으로 사용되는지 확인하세요.

2. SLM을 사용한 일일 자동화 구현

수동 스냅샷은 일회성 작업에는 적합하지만, 일상적인 일일 백업은 스냅샷 수명 주기 관리(SLM)를 사용하여 반드시 자동화해야 합니다. SLM은 일정, 보존 정책 및 스냅샷 관리를 정의하도록 특별히 설계된 Elasticsearch 내의 기본 메커니즘입니다.

SLM 정책 정의

일반적인 일일 정책은 일정, 포함(또는 제외)할 인덱스 및 스냅샷 보존 기간을 정의합니다.

PUT /_slm/policy/daily_archive_policy
{
  "schedule": "0 30 1 * * ?", 
  "name": "<daily-{{now/d}}>",
  "repository": "my_s3_daily_repo",
  "config": {
    "indices": ["logstash-*", "application-metrics-*"],
    "ignore_unavailable": true,
    "include_global_state": false 
  },
  "retention": {
    "expire_after": "30d", 
    "min_count": 5, 
    "max_count": 30 
  }
}

주요 SLM 구성 사항:

schedule: Quartz cron 구문을 사용합니다(예: 0 30 1 * * ?는 매일 오전 1시 30분에 실행). 사용량이 적은 시간에 예약하세요.
include_global_state: false: 일일 데이터 백업의 경우 복원 중 실수로 인한 상태 롤백을 방지하기 위해 클러스터 상태를 제외하는 것이 가장 좋은 경우가 많습니다.
retention: 정리 일정을 정의합니다. 위의 예는 스냅샷을 30일 동안 보관하며 최소 5개, 최대 30개를 유지합니다.

SLM 모니터링

정책이 성공적으로 실행되고 있는지 정기적으로 확인하세요.

GET /_slm/status
GET /_slm/policy/daily_archive_policy

3. 인덱스 수명 주기 관리(ILM)와 통합

로그 및 메트릭과 같은 대규모 시계열 데이터의 경우 인덱스 수명 주기 관리(ILM)가 생성부터 삭제까지 인덱스를 관리합니다. ILM이 일일 SLM 스냅샷을 대체하는 것은 아니지만, 완료된 스냅샷 정책과 삭제를 조정하는 데 도움이 될 수 있습니다.

ILM 및 데이터 계층화

ILM이 오래된 인덱스를 삭제하기 전에 삭제 단계에서 SLM 정책이 실행될 때까지 기다리도록 할 수 있습니다. 이렇게 하면 인덱스가 클러스터에서 제거되기 전에 일일 또는 장기 스냅샷 정책이 데이터를 캡처할 기회를 얻을 수 있습니다.

관련 인덱스 패턴을 스냅샷하는 SLM 정책을 만듭니다.
wait_for_snapshot을 사용하여 ILM 삭제 단계에서 해당 SLM 정책을 참조합니다.

...
"delete": {
  "min_age": "90d",
  "actions": {
    "wait_for_snapshot": {
      "policy": "daily_archive_policy"
    },
    "delete": {}
  }
}
...

이렇게 하면 ILM이 인덱스를 삭제하기 전에 지정된 SLM 정책의 성공적인 스냅샷을 기다립니다. 데이터 스트림을 사용하는 경우 스테이징에서 수명 주기 흐름을 테스트하여 스냅샷 정책이 적용되는 백킹 인덱스를 확인하세요.

목표가 오래된 검색 가능 데이터를 삭제하는 대신 더 저렴한 스토리지에 보관하는 것이라면 콜드 또는 프로즌 단계에서 검색 가능한 스냅샷 작업을 살펴보세요. 이는 일반 재해 복구 스냅샷과는 다른 패턴입니다.

...
"cold": {
  "min_age": "30d",
  "actions": {
    "searchable_snapshot": {
      "snapshot_repository": "my_s3_daily_repo"
    }
  }
}
...

목표당 하나의 수명 주기 패턴을 사용하세요. SLM은 복구 가능한 백업, 삭제 전 wait_for_snapshot, 더 저렴한 비용으로 검색 액세스가 필요할 때 검색 가능한 스냅샷을 사용하세요.

4. 복원 테스트 모범 사례

입증된 복구 전략 없이는 백업 루틴이 완료되지 않습니다. 데이터 무결성을 검증하고 복구 시간 목표(RTO)를 충족하려면 정기적으로 복원 프로세스를 테스트해야 합니다.

복원 테스트 환경

라이브 프로덕션 클러스터에서 직접 복원을 테스트하지 마십시오. 호환되는 Elasticsearch 버전을 실행하고 복원된 샤드를 위한 충분한 디스크 공간이 있는 전용 스테이징 또는 테스트 환경을 사용하세요.
빈도: 최소 분기별로 또는 주요 업그레이드/구성 변경 후에 복원을 테스트하세요.

복원 실행

복원은 특정 인덱스 또는 전체 클러스터 상태를 대상으로 할 수 있습니다.

1단계: 스냅샷 세부 정보 가져오기

복원해야 하는 스냅샷 이름을 식별합니다.

GET /_snapshot/my_s3_daily_repo/_all

2단계: 복원 작업 실행

특정 인덱스를 복원하려면 indices 매개변수를 사용하세요. 특히 테스트 환경에서 활성 인덱스와의 충돌을 피하기 위해 복원 중에 인덱스 이름을 바꾸는 것이 필요한 경우가 많습니다.

POST /_snapshot/my_s3_daily_repo/snapshot_20240501/_restore
{
  "indices": ["logstash-2024-05-01"],
  "rename_pattern": "(.+)",
  "rename_replacement": "restored-$1",
  "include_aliases": false
}

복원 성공 확인

복원 후 샤드 상태와 문서 수를 확인하세요. 개수 일치도 유용하지만 애플리케이션이 의존하는 샘플 쿼리도 실행하세요.

GET /_cluster/health/restored-logstash-2024-05-01?wait_for_status=green&timeout=60s
GET /restored-logstash-2024-05-01/_count

5. 보안 및 성능 고려 사항

보안

리포지토리 액세스: Elasticsearch가 리포지토리에 액세스하는 데 사용하는 자격 증명이 리포지토리 경로에 대해 최소 권한을 따르는지 확인하세요. 실제로 스냅샷 관리는 특히 보존 정책이 오래된 스냅샷을 삭제할 때 소유한 객체에 대한 읽기, 쓰기, 나열 및 삭제 권한이 필요합니다.
암호화: 서버 측 암호화(SSE-S3 또는 SSE-KMS)가 활성화된 보안 리포지토리(예: S3)를 활용하세요.

성능 제한

스냅샷은 I/O 집약적일 수 있습니다. 스냅샷 기간 동안 성능 저하가 발견되면 리포지토리 수준에서 스냅샷 트래픽을 제한하세요. 많은 리포지토리 유형의 경우 리포지토리를 등록하거나 업데이트할 때 관련 설정은 max_snapshot_bytes_per_sec 및 max_restore_bytes_per_sec입니다.

PUT /_snapshot/my_s3_daily_repo
{
  "type": "s3",
  "settings": {
    "bucket": "es-backup-bucket-name",
    "region": "us-east-1",
    "base_path": "daily_snapshots/production",
    "max_snapshot_bytes_per_sec": "100mb",
    "max_restore_bytes_per_sec": "100mb"
  }
}

indices.recovery.max_bytes_per_sec는 피어 및 스냅샷 복구 트래픽을 제어하므로 샤드 복구에 미치는 영향을 이해한 경우에만 조정하세요. 가능하면 스냅샷 일정을 최대 인덱싱 및 검색 시간대 밖으로 유지하세요.

일일 백업 워크플로

내구성 있는 리포지토리 구성: 프로덕션 환경에는 클라우드 스토리지(S3/Azure/GCS)를 사용하세요.
SLM 정책 정의: SLM을 사용하여 스냅샷 일정(예: 매일 오전 1시 30분)을 예약하고 적절한 보존 규칙을 설정합니다.
ILM 조정(해당하는 경우): 삭제 전 wait_for_snapshot을 사용하거나 저렴한 검색 가능한 기록을 위해 검색 가능한 스냅샷을 사용하세요.
상태 모니터링: _slm/policy 및 _slm/status API를 통해 SLM 정책 실행을 정기적으로 확인합니다.
복구 테스트: 분기별 또는 반기별로 격리된 환경에서 전체 복원을 수행하여 RTO 준비 상태를 검증합니다.

유용한 백업은 복원할 수 있는 백업입니다. 일일 SLM 정책을 간단하게 유지하고, 실패를 모니터링하고, 팀이 장애 발생 전에 정확한 단계를 알 수 있을 만큼 자주 복구 훈련을 예약하세요.