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

일일 백업은 안정적인 데이터 관리의 핵심이며, 특히 Elasticsearch와 같은 미션 크리티컬 분산 시스템의 경우 더욱 중요합니다. Elasticsearch는 복제를 통해 고가용성을 제공하지만, 운영 오류, 데이터 손상 및 치명적인 시스템 장애로부터 보호하기 위해서는 신뢰할 수 있는 스냅샷 전략이 필수적입니다.

이 가이드는 Elasticsearch 스냅샷 및 복원 API를 사용하여 견고하고 자동화된 일일 스냅샷 백업을 구현하기 위한 모범 사례를 상세히 설명하며, Snapshot Lifecycle Management(SLM)를 통한 자동화, Index Lifecycle Management(ILM)와의 통합, 그리고 정기적인 복원 테스트의 중요한 필요성에 중점을 둡니다.

Elasticsearch 스냅샷 메커니즘 이해

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

스냅샷은 두 가지 주요 구성 요소를 캡처합니다:
1. 인덱스 데이터: 선택한 인덱스의 실제 Lucene 세그먼트.
2. 클러스터 상태: 메타데이터, 영구 설정, 인덱스 템플릿, 파이프라인 및 역할.

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

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

리포지토리 유형

리포지토리 유형	설명	최적 사용 사례	요구 사항
`fs` (공유 파일 시스템)	모든 마스터 및 데이터 노드에서 접근 가능한 로컬 또는 네트워크 마운트 드라이브.	소규모 클러스터, 빠른 로컬 백업.	`elasticsearch.yml` (`path.repo`)에 등록해야 합니다.
`s3`, `azure`, `gcs`	클라우드 저장소 서비스 (모든 노드에 해당 플러그인 설치 필요).	프로덕션 환경, 재해 복구.	플러그인 설치 및 적절한 IAM/서비스 주체 자격 증명.

예시: S3 리포지토리 등록

프로덕션 환경에서는 내구성 및 오프사이트 복구를 위해 클라우드 스토리지를 강력히 권장합니다. 리포지토리 플러그인(예: repository-s3)을 설치한 다음, 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을 사용한 일일 자동화 구현

수동 스냅샷은 일회성 작업에 허용될 수 있지만, 일상적인 일일 백업은 Snapshot Lifecycle Management (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 * * ?는 매일 오전 01:30에 실행됩니다). 사용량이 적은 시간에 예약하십시오.
include_global_state: false: 일일 데이터 백업의 경우, 복원 중 의도치 않은 상태 롤백을 방지하기 위해 클러스터 상태를 제외하는 것이 종종 최선입니다.
retention: 정리 스케줄을 정의합니다. 위 예시는 스냅샷을 30일 동안 보존하며, 최소 5개에서 최대 30개가 유지되도록 합니다.

SLM 모니터링

정책이 성공적으로 실행되는지 확인하기 위해 정기적으로 상태를 확인하십시오.

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

3. Index Lifecycle Management (ILM)과 통합

대규모 시계열 데이터(예: 로그)의 경우, Index Lifecycle Management (ILM)은 인덱스 생성부터 삭제까지 관리합니다. 일일 스냅샷은 장기 아카이빙을 위해 ILM과 통합되어야 합니다.

ILM 및 데이터 티어링

인덱스가 영구적으로 삭제되거나 리소스 집약적인 콜드/프로즌 티어로 이동되기 직전에 스냅샷을 찍는 것이 모범 사례입니다. ILM 정책의 삭제 단계에 스냅샷 작업을 직접 포함시킬 수 있습니다.

정책 단계 정의: ILM 정책에서 단계(예: delete)를 생성합니다.
스냅샷 작업 추가: 리포지토리와 스냅샷 이름 패턴을 지정합니다.

...
"delete": {
  "min_age": "90d",
  "actions": {
    "forcemerge": {},
    "shrink": {},
    "rollover": {},
    "delete": {
      "snapshot": {
        "repository": "my_longterm_archive_repo",
        "name": "ilm-archive-{{index}}"
      }
    }
  }
}
...

이는 90일보다 오래된 데이터가 클러스터에서 인덱스가 제거되기 전에 아카이브되도록 보장하여, 값비싼 기본 저장소에 방대한 양의 오래된 데이터를 보존할 필요 없이 규정 준수 요구 사항을 충족시킵니다.

4. 복원 테스트 모범 사례

입증된 복구 전략이 없다면 백업 루틴은 불완전합니다. 데이터 무결성을 검증하고 RTO(Recovery Time Objective) 목표를 달성하기 위해 복원 프로세스를 정기적으로 테스트해야 합니다.

복원 테스트 환경

절대 프로덕션 클러스터에 직접 복원하지 마십시오. 프로덕션 환경을 모방하는 전용 스테이징 또는 테스트 환경(동일한 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 /restored-logstash-2024-05-01/_count

5. 보안 및 성능 고려 사항

보안

리포지토리 접근: Elasticsearch가 리포지토리(예: S3 자격 증명)에 접근하는 데 사용하는 자격 증명이 최소 권한 원칙을 준수하는지 확인하십시오. 즉, 스냅샷 프로세스 중에는 쓰기 접근 권한만, 복원 중에는 읽기 접근 권한만 가져야 합니다.
암호화: 서버 측 암호화(SSE-S3 또는 SSE-KMS)가 활성화된 보안 리포지토리(예: S3)를 활용하십시오.

성능 스로틀링

스냅샷은 I/O 집약적일 수 있습니다. 기본적으로 Elasticsearch는 동시 세그먼트 업로드를 제한합니다. 예약된 스냅샷 기간 동안 성능 저하가 발생하는 경우, 스로틀링 설정을 조정할 수 있습니다(단, 너무 관대하게 설정하지 마십시오).

PUT /_cluster/settings
{
  "persistent": {
    "indices.recovery.max_bytes_per_sec": "100mb", 
    "snapshot.max_bytes_per_sec": "100mb"
  }
}

경고: max_bytes_per_sec를 너무 높게 늘리면 클라이언트 쿼리 및 인덱싱 작업에 대한 클러스터 응답성에 부정적인 영향을 미칠 수 있습니다.

일일 백업 워크플로 요약

견고한 리포지토리 구성: 프로덕션 환경에서는 클라우드 저장소(S3/Azure/GCS)를 사용하십시오.
SLM 정책 정의: SLM을 사용하여 스냅샷을 예약하고(예: 매일 오전 1:30), 적절한 보존 규칙이 설정되었는지 확인하십시오.
ILM 통합(해당하는 경우): ILM을 사용하여 오래된 인덱스를 삭제하기 전에 장기 리포지토리에 아카이브하십시오.
상태 모니터링: _slm/policy 및 _slm/status API를 통해 SLM 정책 실행을 정기적으로 확인하십시오.
복구 테스트: 분기별 또는 반기별로 격리된 환경에서 전체 복원을 수행하여 RTO 준비 상태를 검증하십시오.