Elasticsearch에 Trim이 되어 있나요?

By
Dimitrios Liappis

2018년 6월 9일 : 이 블로그 포스트에는 셧다운 방지를 위해 trim을 하지 말아야 하는 경우에 대한 내용이 업데이트 되었습니다.

Elasticsearch에 Trim이 되어있나요?

Elastic은 Elasticsearch의 성능 벤치마크를 정기적으로 수행하며, 그 결과를 공개하고 있습니다. 다음의 결과를 보면 반복적인 성능 저하 패턴이 관찰되는 것을 볼 수 있습니다.

recurring-elasticsearch-slowness

위 그림에서 2016년 9월 26일에 최고치였던 성능이 점차 감소하다 2016년 10월 3일에 다시 회복했고, 다시 지속적으로 감소하다 2016년 10월 10일에 회복했습니다. 패턴이 파악 되시나요?

| 날짜 | 요일 | | ---- | --------------- | | 2016년 9월 26일 | 월요일 | | 2016년 10월 3일 | 월요일 | | 2016년 10월 10일 | 월요일 |

원인 도출을 위해 끊임없이 주기적으로 되풀이되는 수많은 요인들을 파고드는 대신, 저희는 운영 체제 레벨의 정기적인 주간 작업들을 살펴보기 시작했습니다. 벤치마크 실행 환경은 베어 메탈 서버에 Ubuntu 16.04가 설치되어 있고 소프트웨어 RAID-0 구성의 SSD 2개를 사용합니다.

다음은 Ubuntu Server 16.04 LTS 기반 VM의 cron.weekly 의 내용입니다. fstrim 작업에 주시하세요.

vagrant@ubuntu1604vbox:/etc/cron.weekly$ ls
fstrim  man-db

TRIM이란 무엇인가요?

Wikipedia 자료 인용:

운영 체제는 trim 명령 (ATA 명령 세트의 TRIM, SCSI 명령 세트의 UNMAP) 을 통해 더 이상 사용되지 않아 내부적으로 지워도 되는 데이터 블록이 어느 것인지 솔리드 스테이트 드라이브(SSD)에 알려줍니다.

SSD 드라이브는 플래시(NAND) 메모리 셀 그룹들로 이루어져 있습니다. 기존 자기 디스크와는 다음과 같은 3가지 주요 차이점이 있어 SSD 드라이브에 영향을 미칠 수 있습니다.

  1. 한 번의 작업으로 메모리 셀을 덮어쓸 수 없습니다. 새 데이터로 대체하려면 먼저 기존 데이터를 삭제해야 합니다.
  2. 메모리 셀이 지원하는 프로그램/삭제 횟수가 제한되어 있습니다.
  3. 메모리 셀이 페이지와 블록으로 구성되어 있어, SSD 드라이브는 전체 블록 단위의 삭제만 가능합니다!

이러한 제약으로 인해 제조업체가 가비지 수집(Garbage Collection) 기능을 구현해야만 했는데, 이는 데이터가 있는 페이지를 사용 가능한 다른 블록에 복사한후에 기존의 데이터 페이지와 삭제 표시된 페이지가 모두 포함된 블록을 비우도록 되어 있습니다. 따라서 SSD 드라이브는 내부적으로 쓰기 작업을 위해 OS가 명시적으로 생성한 것보다 많은 IO를 생성하며, 이를 쓰기 증폭(Write amplification)현상이라고 합니다.

OS가 파일 삭제 요청을 받을 때 파일 시스템은 메타데이터만 업데이트하고 실제 데이터가 포함된 디스크 주소는 삭제하지 않습니다. 따라서 GC 실행 중에 SSD 드라이브의 쓰기 증폭 현상이 더욱 심해집니다. 이 문제의 해결을 위해 OS는 TRIM 명령을 내려 SSD 드라이브가 삭제된 데이터를 인식하도록 합니다. 여기에는 다음 두 가지 이점이 있습니다.

  • GC 실행 중에 (OS가 이미 삭제한 데이터의) 불필요한 이동 방지
  • 사용 가능한 공간이 늘어나 GC 효율성이 향상됨

실제 사용에 미치는 영향?

파일 시스템이 삭제된 파일 정보를 SSD 드라이브에 전달하면 SSD 드라이브의 작동 속도가 빨라집니다. Ubuntu에서 fstrim crontab 프로세스가 하는 일이 바로 이것입니다.

실제로 큰 차이를 만들어 낼까요?

물론입니다! 2016년 10월 17일 이후 fstrim cronjob을 일일 일정에 포함하고 나자 그래프가 조기에 안정화되었습니다.

elasticsearch-performance-after-trim

아래에 TRIM의 실행 없이 다른 (PMC) 벤치마크를 10회 연속 실시하자 나타나게 된 악영향을 볼 수 있습니다. 해당 파일 시스템에는 벤치마크 시작 전에 한 번만 TRIM 작업이 수행되었습니다.

ten-rally-benchmark-iterations-notrim

trim 을 실행하지 말아야 하는 경우가 있나요?

(예를 들면) 벤치마크 실행 전에 디스크를 trim 하는 것은 의미가 있지만, 운영 환경에서는 함부로 실행하면 안되는 경우도 있습니다.

얼마나 오래 전에 디스크를 trim 했었는지에 따라, trim이 진행되는 동안 디스크 성능이 저하되고 완료되기 까지 시간이 오래 걸릴 수 있습니다.

  • Elastic Cloud Enterprise (ECE) 사용 중에는, 긴 trim 의 반환 시간 때문에 중에 컨트롤 플레인이 불안정해질 수 있습니다. 결과적으로 ECE 디스크를 수동으로 트리밍하지 않는 것을 권장합니다.
  • 다른 제품의 경우, 트래픽이 낮은 기간에만 실행을 예약하거나, 시스템이 계속 과도하게 사용중이라면 trim을 완전히 사용하지 않도록 설정하는 것이 좋습니다.

주의 사항

CentOS-7에서는 fstrim.service 및 관련된 systemd timer가 기본적으로 비활성화되어 있습니다. 따라서 이 서비스를 활성화하고 기본 타이머 스케줄도 재설정해야 합니다.

LVM을 사용하고 크기 조정 작업을 자주 수행하는 경우에는 issue_discards 에서 /etc/lvm/lvm.conf 를 1로 설정해야 합니다. dm-crypt Linux 암호화 계층을 사용하는 경우에는 또한 특별 처리가 필요합니다. lvm/dm-crypt 에서 TRIM을 구성하는 방법은 ArchLinux wiki 페이지에서 확인할 수 있습니다.

TRIM 문제는 SSD 디스크의 직접 액세스 기능을 제공하는 경우 클라우드 인스턴스에도 영향을 미칩니다. 일부 Amazon 인스턴스의 Instance Store-Backed Linux AMI가 이러한 경우입니다.

결론

Elasticsearch는 IO를 많이 사용하는 애플리케이션입니다. SSD 저장 장치에서 실행할 경우, TRIM이 활성화되어 있는지 확인해야 하며, 부하에 따라 TRIM 작업 주기를 조정해야 합니다. 그러면 성능을 대폭 향상시킬 수 있습니다!