Elasticsearch 비용 절약하기

아무것도 모르는 상태라서 Elasitcsearch Cloud를 사용했지만 규모가 커지면서 비용이 많이 발생하기 시작했습니다. 규모가 커지면서 비용문제가 지속되었고 비용을 줄이기 위해 조치했던 내용을 정리해보았습니다. 

Elasticsearch Cloud에서 AWS Self Managed로 Migration

처음 Elasticsearch를 구성할 때는 Cloud를 사용하여 구성했습니다. 빠르게 production에 적용을 진행해야해서 Elasticsearch Cloud를 사용하여 운영을 시작했습니다. Elasticsearch Cloud를 사용할 때는 Elasticsearch Cloud에서 자동으로 진행되는 것들이 많았습니다. version upgrade나 설정 변경 시 자동으로 rolling update를 진행하여 클릭만 하면 되었습니다. AWS Self Managed로 운영하면서 이렇게 자동으로 진행되는 것을 하나하나 수동으로 진행해야한다는 사실을 알게되었습니다. Elasticsearch를 운영하면서 시간이 오래 걸리는 작업이 상당히 많다는 것을 알게되었습니다. 가능하다면 운영에 대한 준비를 많이 해야 시간을 절약할 수 있습니다.

 

데이터가 많아지면서 비용이 정말 빠르게 증가했고 Elasticsearch 운영 비용을 절약하기 위해 AWS에 EC2위에 Elasticsearch Cluster 구성을 진행했습니다. 데이터 Migration을 진행은 Elasticsearch Snapshot을 활용하여 Migration을 진행했습니다. Migration을 진행할때 CCR, CCS를 활용하는 방법도 확인해보았지만 License가 필요한 부분이 있어서 사용하지 못했고 Snapshot만을 활용했습니다.

 

> snapshot을 활용한 migration 진행 시 꼭 호환되는 Elasticsearch version을 확인해야 합니다. 

https://www.elastic.co/guide/en/elasticsearch/reference/current/snapshot-restore.html#snapshot-index-compatibility

Instance Type 선택 시 비용 고려사항

Elasticsearch Cluster를 AWS EC2로 Migration을 진행하면서 가장 고민했던 부분은 AWS EC2 Type을 선택하는 것이었습니다. EC2를 기본적으로 선택하면 EBS 최적화 인스턴스를 사용할 것입니다. EBS 최적화 인스턴스 선택하기 전에 EC2 Instance Storage를 지원하는 instance type을 사용하는 것을 고려해봐야한다. EC2 Instance Storage는 EC2 인스턴스에 직접 연결된 스토리지입니다. DB와 같은 장비를 구성할 때 IOS를 많이 사용하는 경우가 많지만 EBS를 사용하는 경우 IOS 추가적으로 구성하면 비용이 발생합니다. EC2 Instance Storage를 사용하는 매우 빠른 I/O 성능을 제공하여 IOS에 대한 추가적인 비용 발생을 고려하지 않아도 됩니다. 단점은 instace stop시 데이터가 사라진다는 것입니다. EC2 Instance Storage를 사용하는 경우 장애상황을 대비하여 HA를 구성해야하며, 가능하다면 추가적인 replica shard를 구성하여 운영하는 해야합니다.

 

2개의 tier로 Lifecycle 정책을 분리하여 관리하고 있습니다. tier에 따라서 EC2 Instance Storage를 선택하여 사용하고 있습니다. Hot tier의 경우 indexing을 담당하고 가장 많은 access를 보장하도록 구성했습니다. SSD EC2 Instance Storage인 i4i type을 선택하여 hot tier를 구성했습니다. warm는 과거 데이터를 저장하여 hot tier에 비해 access가 적었고 HDD EC2 Instance Storage인 d2 type을 사용하여 구성했습니다. i4i 장비는 2년 동안 hardware retirement event가 한 번도 발생하지 않았습니다. 하지만 d2 type의 장비의 경우 1년에 2번에서 3번은 발생하는 것으로 보입니다. ap-northeast-2에서는 d2 type이 부족한 현상이 발생하여서 d2 type 선택 시 주의해야합니다.

 

Instance Type 선택 시 추가적인 고려해야할 사항들은 아래 정리해보았습니다.

* he exact number of shards per 1 GB of memory depends on the use case, with the best practice of 1 GB of memory for every 20 shards on disk.

* There are no hard limits on shard size, but experience shows that shards between 10GB and 50GB typically work well for logs and time series data. You may be able to use larger shards depending on your network and use case.

* 적당한 Heap메모리는 전체 메모리의 절반 정도 수준에서 전체 메모리가 크다면 32GB보다 작은 값으로 설정합니다.

Data Transfer 비용도 고려해야합니다.

AWS에서 Elasticsearch Cluster를 운영하면서 데이터가 수백 TB가 넘어가면서 Data Transfer 비용이 무시 못할 비용이 발생하게 되었습니다. AWS에서는 동일한 리전 내 동일 가용 영역(AZ) 내에서의 데이터 전송은 무료이지만 같은 region이라도 다른 가용 영역(AZ) data가 이동하면 비용이 발생합니다.

Elasticsearch Cluster를 같은 AZ에 구성할 수 없어서 여러 AZ에 걸쳐서 shard를 배치시킵니다. Search query 요청이 들어오면 Elasticsearch의 동작 방식이 분산되어 있는 데이터를 찾기 위해서는 여러 node에 데이터를 query하고 해당 데이터를 반환하도록 구성되어 있습니다. 

 

https://medium.com/@musabdogan/elasticsearchs-distributed-search-query-and-fetch-phases-df869d35f4b3

Elasticsearch’s Distributed Search: Query and Fetch Phases

 

1. Data Transfer를 줄이기 위해서는 한 번에 search query에 참여하는 shard의 개수를 줄일 수 있도록 구성합니다. 

2. Data Transfer간 전송되는 데이터 사이즈를 줄이기 위해서 compression 설정을 합니다. 

3. Search 요청 시 _source를 지정하여 필요한 데이터만 반환하도록 합니다.

4. threshold rebalancing을 줄입니다.