BLOG
로그 데이터에 Amazon Elasticsearch Service (Amazon ES)를 사용할 때, 일반적으로 매우 압도됩니다. Elasticsearch 및 Kibana 지식이 깊어짐에 따라 많은 매력적인 데이터 사용을 발견할 수 있습니다. 고객 기반이 확장되고 이를 처리하기 위해 인프라를 확장하면 로그 데이터가 훨씬 더 많이 생성됩니다.
여러 설계 경로를 사용하여 계속 증가하는 로그 데이터를 저장하고 분석할 수 있습니다. 예를 들어 여러 Amazon ES 도메인을 배포하여 워크로드를 여러 도메인으로 나눌 수 있습니다. 그러나 이 설계 전략은 단일 Kibana 대시보드로는 분석을 지원하지 않습니다. 또한 일부 로그 스트림에 대한 공동 테넌시(Co-tenancy)를 통해 하이브리드 방식을 취하거나, 전체 도메인 접근 방식을 취할 수도 있습니다.
결국 단일 워크로드 도메인을 사용하더라도 1PB 이상의 스토리지로 확장할 수 있습니다.
최근 Amazon ES의 대형 클러스터에 대한 지원 한도를 두 배로 늘렸습니다. 현재 저희는 기본 데이터 인스턴스 20개를 지원하며, 단일 클러스터에 최대 200개의 데이터 인스턴스가 있으며 도메인에 대한 제한적인 증가가 있습니다. 데이터 인스턴스에 대해 I3.16xlarge.elasticsearch 인스턴스를 선택하면 클러스터에 최대 3PB의 스토리지가 제공됩니다. 이러한 XL 워크로드를 성공적으로 실행하기 위한 모범 사례는 무엇입니까?
최신 버전의 Elasticsearch 실행
모든 새로운 버전의 Elasticsearch는 안정성과 성능을 향상시킵니다. 이 글이 작성되었을 때 Amazon Elasticsearch Service는 Elasticsearch 버전 6.4를 지원했습니다. 대규모 클러스터의 경우 (인플레이스 업그레이드를 사용하여) 지원되는 최신 버전의 Elasticsearch로 배포하거나 업그레이드할 것을 권장합니다.
I3 인스턴스 사용
페타바이트 규모로 확장하려면 I3을 사용해야 합니다. I3 인스턴스에는 NVMe SSD 임시 저장소가 있습니다. 대체로 I3.16xlarge.elasticsearch 인스턴스는 노드당 15.2TB의 스토리지를 갖추고 있으며, 200개 노드 도메인에서 총 3.04PB의 스토리지를 제공합니다. EBS 지원 인스턴스 유형 중 하나를 선택하면 Amazon ES에서 데이터 인스턴스당 최대 1.5TB의 EBS 볼륨을 배포할 수 있어 최대 클러스터 크기가 300TB입니다. 저희는은 항상 새로운 인스턴스 유형을 평가 및 추가하며 서비스 제한을 평가하고 변경합니다. 향후 서비스 개선으로 인해 이 글에 강조된 권장 사항이 변경될 수 있습니다.
_rollover API를 사용하여 인덱스 라이프사이클 관리
로그 분석에 Amazon Elasticsearch Service를 사용하면 인덱스를 생성하여 데이터를 파티셔닝하고 클러스터에서 해당 수명주기를 관리할 수 있습니다. 지정된 기간 동안 로그를 수집한 다음 다음 기간 동안 새 인덱스로 이동합니다. 보존 기간이 끝나면 가장 오래된 인덱스를 삭제합니다.
인덱스를 얼마나 자주 변경해야 합니까? 엄격한 규칙은 없지만 인덱스 관리를 위한 두 가지 패턴이 있습니다.
- 특정 시간 간격(보통 매일이지만 워크로드가 상당히 큰 경우, 하루에 한 번 이상 롤오버해야 합니다.) 에 롤오버기. 이러한 변경은 클러스터 외부의 수집 파이프라인에서 발생하며, 이는 대상 인덱스를 결정합니다.
- 인덱스 크기에 따라 롤오버합니다. 이 변경 사항은 클러스터 내에서 발생합니다. 별칭을 사용하여 데이터를 인덱스로 보내고 조건을 지정하는 _rollover API를 호출할 수 있습니다. Elasticsearch는 조건이 충족되면 별칭 뒤에 새 인덱스를 생성합니다. 인덱스의 크기에 따라 롤오버는 Elastic Search 버전 6.4 이상에서만 사용할 수 있습니다.
인덱스 크기별로 롤오버할 수 없는 이전 버전의 Elasticsearch의 경우, _rollover API를 호출하는 유사한 패턴을 권장하지만, 그 대안으로 인해 샤드(shard) 크기가 더 다양하기 때문에 문서 수를 트리거로 사용하는 것이 좋습니다.
_rollover API를 사용하면 인덱스 크기 또는 문서 개수로 롤오버할 때 모든 샤드(shard)가 거의 동일한 크기인지 확인할 수 있습니다. 따라서 스토리지를 균등하게 분할할 수 있는 최상의 기회가 되며, 그 결과 클러스터 내의 인스턴스 간에 컴퓨팅을 균등하게 나눌 수 있습니다.
샤드(shard) 수를 인스턴스(instance) 수로 분할하도록 설정
Amazon Elasticsearch Service 도메인의 클러스터 불안정성의 주요 원인은 샤드(shard) 사용 내의 스큐(skew)와 그에 따른 핫 노드가 스큐(skew)를 생성하기 때문입니다. Elasticsearch 맵은 수를 기준으로 인스턴스에 샤드(shard)를 표시하며, 각 인스턴스는 가능한 한 동일한 수의 샤드(shard)를 수신합니다. 샤드(shard) 수를 인스턴스 수로 분할할 수 있도록 설정한 경우 클러스터의 모든 노드에 동일한 수의 샤드(shard)가 있는지 확인합니다.
여기서 _rollover API를 통해 스토리지 스큐(skew)를 관리할 수 있습니다. 샤드(shard)가 모두 동일한 경우, 스토리지가 샤드(shard) 수를 기준으로 균일하게 배포됩니다. 스토리지가 고르게 분산되지 않으면 일부 노드의 공간이 다른 노드보다 부족해질 수 있습니다. 이렇게 되면 Elasticsearch가 해당 노드에 대한 샤드(shard) 배포를 중지하고 샤드(shard) 수 또한 왜곡되어 인스턴스에 불균일한 부하가 발생할 수 있습니다.
인덱스를 롤오버한 후 인덱스 최적화하기
로그 분석 워크로드의 경우 인덱스는 한 번 쓴 다음에는 읽기 전용입니다. 이 패턴을 활용하여 새 인덱스로 롤오버한 경우 _forcemerge API를 호출할 수 있습니다. _forcemerge는 인덱스의 세그먼트를 병합하여 Lucene 세그먼트 수를 줄입니다. 이는 쿼리를 처리하는 데 유용합니다. _shrink API를 사용하여 인덱스의 샤드(shard) 수를 줄이면 샤드(shard) 수를 관리하여 클러스터 전체에 작업을 균등하게 분산할 수 있습니다.
이러한 API는 모두 클러스터에 상당한 로드를 생성합니다. 정기적으로 _forcemerge 또는 _shrink를 호출해서는 안 됩니다. 하루 중 트래픽이 적은 시간에 이러한 호출을 예약하고 동시 호출 수를 1로 제한합니다.
마스터 노드
PB 스케일 클러스터의 경우 전용 마스터 인스턴스를 배포해야 합니다. 전용 마스터 인스턴스는 노드 수가 많은 클러스터에 필요한 안정성을 제공합니다. 전용 마스터 사용의 기본 드라이버에는 샤드(shard) 수, 노드 수, 매핑 크기 및 매핑 변경 사항이 포함됩니다. 다음 표에서는 이러한 다양한 요인의 프록시로 샤드(shard) 수를 사용하여 다른 척도의 전용 마스터 인스턴스에 대해 인스턴스 유형을 권장합니다.
| 전용 마스터 인스턴스 구성 추천 | ||
| 클러스터 크기 | 최대 샤드(shard) 수 | 인스턴스 유형 |
| < 10 data instances | 2,500 shards | C4.large.elasticsearch |
| 10 to 30 data instances | 5,000 shards | C4.xlarge.elasticsearch |
| 30 to 75 data instances | 10,000 shards | C4.2xlarge.elasticsearch |
| > 75 data instances | < 30,000 shards | R4.4xlarge.elasticsearch |
모든 Amazon ES 클러스터의 전체 샤드(shard) 수를 30,000개 미만으로 유지하는 것이 좋습니다. 그러나 모든 샤드(shard가 동일한 리소스를 사용하는 것은 아닙니다. Amazon Elasticsearch Service Domain 싸이징에 대한 이전 글에서는 활성 샤드(shard)와 비활성 샤드(shard)를 구분했습니다. 샤드(shard)는 읽기 및 쓰기 트래픽을 수신할 때 활성화됩니다. 도메인이 지원할 수 있는 활성 샤드(shard)의 수는 클러스터의 CPU 수에 따라 결정됩니다(자세한 내용은 Amazon Elasticsearch Service 도메인 싸이징에 대한 글을 참조하세요). 200노드인 I3.16XLarge.elasticsearch 클러스터의 경우 활성 샤드(shard)를 5,000개 미만으로 유지해야 합니다(다른 클러스터 작업을 위한 공간이 약간 남아 있습니다).
이전 표에서는 인스턴스에 저장된 데이터에 대한 JVM 크기(바이트)의 비율을 1:50으로 가정합니다. 또한 최대 샤드(shard) 수로 50GB를 모범 사례로 사용합니다. 워크로드에 따라 최대 100GB의 더 큰 샤드(shard) 크기로 성공할 수 있습니다.
50GB 이상의 샤드(shard)를 사용하는 경우 클러스터 메트릭이 올바르게 작동하는지 확인해야 합니다. CloudWatch 메트릭에 대한 알람을 설정해야 합니다. 샤드(shard) 수가 많은 클러스터의 경우 마스터 인스턴스의 CPU 및 JVM 사용량을 모니터링하는 것이 특히 중요합니다. 전용 마스터 CPU가 평균 80% 이상 실행 중이거나 전용 마스터 JVM 메모리 프레셔(Pressure)가 지속적으로 80%를 초과하는 경우 샤드(shard) 수를 줄입니다.
_bulk 요청 페이로드 제한
도메인을 처음 배포할 때는 _bulk 요청 페이로드 크기를 조정하는 데 시간을 투자해야 합니다. Elasticsearch 처리량은 쓰기 요청의 크기와 각 요청에 대한 후속 처리 시간 및 JVM 메모리 사용에 따라 크게 달라집니다. 경험적으로, 저희는 약 5MB를 이 조정의 좋은 출발점으로 봅니다.
PB 스케일 클러스터의 경우 대용량 크기에서 처리량이 향상되는 경우에도 대량 페이로드를 약 20MB 미만으로 유지하는 것이 좋습니다. 부피가 클수록 처리하려면 더 많은 JVM 메모리가 필요합니다. 너무 많은 대량 요청을 처리할 때 JVM heap이 부족할 수 있습니다.
결론
대규모 로그 분석 워크로드를 처리하기 위해 단일 도메인을 사용하든 여러 도메인에 분산하든 이 글에 설명된 모범 사례를 사용해야 합니다. 하지만, 저희는 모든 Elasticsearch 워크로드는 그 자체의 beast라는 경고를 드리고 싶습니다. 이 글의 권장 사항은 가이드라인이며, 마일리지도 다양합니다! 크기 조정, 샤드(shard) 전략 및 인덱스 라이프사이클 관리를 적극적으로 배포, 모니터링 및 조정해야 합니다.
원문 URL : https://aws.amazon.com/ko/blogs/database/run-a-petabyte-scale-cluster-in-amazon-elasticsearch-service/
** 메가존클라우드 TechBlog는 AWS BLOG 영문 게재글중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아서, 정기적으로 게재하고 있습니다. 추가로 번역및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달해드리도록 하겠습니다.