AWS ElasticSearch Service 운영 및 장애발생 해결

AWS ElasticSearch를 사용하여 application 사용자의 행동을 분석하고 있다. pipeline은 pinpoint -> kinesis firehose -> elasticsearch 으로 구성하여 사용하고 있다.

 

사용자가 많지 않아 test용도로 ElasticSearch를 6개월 동안 t2.small.elasticsearch 인스턴스를 사용했다. 다른 설정을 변경하지 않고 AWS에서 제공하는 기본설정으로 사용했다. 기존에는 VPC안에 ElasticSearch를 설정하는 경우 Kinesis Firehose를 ES와 연결할 수 없었다. Kinesis Firehose를 사용하기 위해 public ElasticSearch로 구성하고 특정 ip만 접근가능하도록 SecurityGroup을 구성했다.

 

VPC Elasticsearch에 Kinesis Firehose를 연결할 수 있도록 2020년 4월에 업데이트 되었다.
Amazon Kinesis Data Firehose, Amazon Virtual Private Cloud(VPC)에서 Amazon Elasticsearch Service 도메인으로 스트리밍 데이터 전송 지원 추가

문제점

 

Kinesis Firehose 설정은 Index rotation을 하루에 한번으로 설정하여 매일 하나의 index가 생성되도록 했다. ElasticSearch를 기본 설정으로 사용하는 경우 index 1개당 10개의 shard(Primary Shard 5개와 Replica Shard 5개)가 생긴다. 6개월간 문제없이 동작하였으니 6 * 30 * 10 = 1800 개 정도의 shard가 생겼다. 데이터량이 얼마되지 않아 일정 주기로 index를 제거하는 로직을 구성하지 않았다.

문제는 node당 shard가 1000개로 제한되어 있는 것이었다. node를 2개 사용하고 있어 2000개 정도의 shard가 생성된 이후 ElasticSearch의 status가 red로 변경되고 스냅샷에도 문제가 생겼다.

 

Elasticsearch 7.x 이상에서는 노드당 샤드 수가 1,000개로 제한되며, cluster.max_shards_per_node 설정을 사용해 제한을 조정할 수 있다.

해결방법

1. Index rotation 주기를 하루에 한번에서 한달주기로 변경하고 인덱스당 샤드는 4개(Primary Shard 2개와 Replica Shard 2개)로 설정했다. 샤드 크기는 10–50GiB 사이로 유지하는 것이 좋다. Index rotation 주기에 의해 한달에 1개의 index가 생성되고 한달에 4개의 샤드가 생성된다. 한달동안 적제되는 데이터가 10GiB 이하이지만 지속적으로 사용자가 증가하고 있어 충분한 공간을 확보하기 위해 Primary Shard를 2개 사용했다. Primary Shard를 2개를 사용하여 월 100 GiB(하나의 shard에서 50GiB까지 받는다고 생각)까지 적제되는 데이터를 문제 없이 받을 수 있을 것이다.

# template 변경 query
# "{index}"에는 "test*" *를 사용하여 설정할 수 있다.
# firehose에서 prefix를 test를 설정하고 Index rotation를 하루로 설정하면 test-YYYY-MM-DD로 index가 생성된다. "{index}"를 test*로 설정하면 새로 생성되는 index에 template가 적용된다.

PUT _template/template1
{
  "template": "{index}",
  "settings": {
    "index" : {
      "number_of_shards": 2,
      "number_of_replicas": 0
    }
  }
}

tenplate는 index가 create되는 시점에만 적용된다. 기존에 존재하는 index는 template에 적용되지 않는다.

 

2. Index Lifecycle Management 사용하여 index 관리한다. Index lifecycle에는 4가지 상태가 있고 이에 따라 index를 관리할 수 있다. 상태에 따라 특정 node에 index를 할당할 수 있도록 설정이 가능하다.

 

Life cycle에 따라 성능이 다른 node에 index를 할당하는 경우 aws ElasitcSearch UltraWarm을 확인해보는 것이 좋다.
https://docs.aws.amazon.com/ko_kr/elasticsearch-service/latest/developerguide/ultrawarm.html

 

Index Lifecycle Management 정책을 사용하여 index가 특정 시간이 지나면 삭제될 수 있도록 구성한다. Hot 상태에서 특정 조건에 rollover되면 특정 시간 동안 저장하고 index를 삭제하는 정책을 사용힌다.

VPC ElasticSearch를 사용하는 경우 고려사항

 

Public ElasticSearch를 VPC ElasticSearch로 변경하게 되었다. Public ElasticSearch를 VPC ElasticSearch로 config 수정으로 변경할 수 없다. 변경을 위해서는 새 ElasticSearch domian을 생성하고 migration을 진행해야한다.

Kinesis Firehose와 VPC ElasicSearch를 연결 설정 시 힘들었던 부분은 SecurityGroup설정이다. VPC ElasicSearch SecurityGroup의 inbound의 443 port에 Kinesis Firehose의 SecurityGroup을 설정해야한다. Kinesis Firehose SecurityGroup의 outbound에는 443 port가 VPC ElasicSearch SecurityGroup으로 보낼 수 있도록 설정한다. 더 자세한 내용은 아래 링크에서 확인가능하다.

 

Ingest streaming data into Amazon Elasticsearch Service within the privacy of your VPC with Amazon Kinesis Data Firehose | AWS Big Data Blog

 

Public ElasticSearch를 사용할 때는 kibana에 특정 ip만 접근가능하도록 설정하고 사용했다. 하지만 VPC ElasticSearch를 사용하는 경우 추가 설정이 필요하다. VPC안에 있는 도메인에 대한 Kibana에 접근하려면 사용자가 VPC에 접근할 수 있어야 한다. VPN 또는 관리 네트워크 연결 또는 프록시 서버 사용이 필요할 수 있다.

 

Kibana 액세스- Amazon Elasticsearch Service
Amazon Cognito 인증으로 Kibana에 액세스하기 위해 SSH 터널 사용

 

Public 도메인과 비교하면, VPC 도메인은 ElasticSearch 콘솔에 더 적은 정보를 표시된다. Cluster health 탭에는 샤드 정보가 포함되지 않으며 Indices 탭은 표시되지 않는다. index나 Cluster 정보를 확인하기 위해서는 Kibana 또는 직접 ElasticSearch에 query를 하여 확인해야한다.

 

#index 확인 query
GET _cat/indices?v&s=index 

Reference

• Configure a lifecycle policy | Elasticsearch Reference 7.8 | Elastic
• 인덱스 수명 주기 관리를 통해 Elasticsearch에서 Hot-Warm-Cold 아키텍처 구현 | Elastic Blog
• Split index API | Elasticsearch Reference 7.8 | Elastic