OpenSearch / UltraWarm / Cold Storage

OpenSearch 는 실시간 어플리케이션 모니터링, 로그 분석 및 웹 사이트 검색에 유용한 오픈 소스이다. 데이터 수집, 보안, 검색, 집계, 확인, 분석 등이 쉽게 가능하다. 기존의 Elasticsearch / Kibana 가 라이센스를 변경하면서 오픈 소스로서의 업데이트를 중단하자, AWS 가 마지막 오픈 소스 버전(Elasticsearch 7.10.2 및 Kibana 7.10.2) 을 Apache License, Version 2.0(ALv2) 하에서 릴리스하여 관리/업데이트 하는 중이다. Elasticsearch / Kibana 는 AWS 에서 OpenSearch / OpenSearch Dashboard 라는 이름으로 변경되었으며, 기존의 Apache Lucene 검색 라이브러리도 동일하게 사용한다.

 

 

OpenSearch 도메인 생성

 

도메인 생성시, 인스턴스 유형, 인스턴스 수, 스토리지 할당 등을 지정할 수 있다.

• Multi-AZ 를 사용하는 경우, 전용 프라이머리 노드가 활성화 되어 있으며, 프로덕션 도메인의 경우 3개의 노드를 권장한다. (가동 중지를 막기 위해 3개의 노드를 구성한다.)
• Multi-AZ 의 수에 맞게, 데이터 노드도 각각 배치 되어야 한다. AZ 를 2개 사용한다면 2의 배수로 설정해야 한다. (전용 프라이머리 노드와 인스턴스 패밀리를 동일하게 묶는 것 추천)

기타 나머지 부분들은 설정 항목마다 잘 설명되어 있다. 어느 정도 사용해 보고 적당하다 싶으면 RI 를 설정한다.

 

 

OpenSearch 의 장애

 

흔히 OpenSearch 에서의 장애라 함은, 클러스터 상태에 빨간 불이 켜지거나, 클러스터 쓰기 상태에 빨간 불이 켜지는 것을 말한다. 주로 트래픽을 감당하지 못하고 JVM 메모리가 부족하거나 공간이 부족해진 경우가 대부분이 었는데, 상황에 맞게 EBS 볼륨을 늘리거나, 오래된 index 들을 삭제하면서 버텨왔다. 하지만 index 도 특정기간 이상 보관해야 하기 때문에 지울 수 없게 됐고, 트래픽도 극에 달하니 다른 방법을 모색해야 했다.

 

Warning : VM 메모리 압력이 80%를 초과했습니다. 30분 동안 92%를 초과하면 클러스터에 대한 모든 쓰기 작업이 차단됩니다. 클러스터 안정성을 최적화하려면 클러스터에 대한 트래픽을 줄이거나 도메인을 확장하세요. 자세한 내용은 https://docs.aws.amazon.com/opensearch-service/latest/developerguide/monitoring-events.html#monitoring-events-high-jvm을(를) 참조하세요.

 

 

UltraWarm / Cold Storage 활용

 

OpenSearch 에서는 오래된 데이터의 분리 보관을 위해 UltraWarm / Cold Storage 라는 대안을 제공한다. (이 대안은 읽기 전용이므로 Warm Index 에 쓰기를 시도하면 에러가 발생한다.)

 

• 데이터 노드 (hot) : 읽기 속도가 빠르지만 고비용
• UltraWarm : 읽기 속도는 보통이나, 데이터 노드보다 90% 저렴 (스토리지 + S3 캐싱)
• Cold Storage : 읽기 속도는 느리나, UltraWarm보다 더 저렴 (S3 사용)

 

hot / warm / cold 이 3가지 영역으로 데이터를  분리 보관할 수 있는데, 기본적으로는 저장되는 데이터 노드의 공간이 hot 영역이다. 데이터를 분리하지 않은 채 계속 쌓인다면, 검색시 부하도 많이 걸리고, 저장 공간도 부족해 지고, JVM 메모리도 부족해 진다. 이 때는 인스턴스 사양을 높이더라도 데이터 역시 지속적으로 늘어나기 때문에 시간이 지나면 또 똑같은 에러를 만나게 될 것이다. 그에 대한 조치로는 데이터를 삭제하던지, 분리 하던지 하는 방법이 있는데, 바로 warm 이나 cold 영역으로 데이터를 분리하는 것이다. 이 영역들은 데이터 노드가 아닌 S3 를 활용하며, 검색이 조금 느리긴 하지만 저렴하다(?) 고 한다. 

 

6개월 정도 써 본 결과, warm 나 cold index 검색 속도가 특별히 느리다는 체감을 하지는 못했다. 일단 스토리지 안정성에 대해서는 대만족이다. 문제는 많이 쓰든 적게 쓰든, UltraWarm 데이터 노드 기본 사양 자체가 비싸다...

 

또한 데이터 분리에 대한 정책도 나름대로 잘 정해야 한다. 나의 경우, 모든 인덱스들을 매달 분리하였고, 실제 검색에 자주 사용하는 hot 에 2달 보관, 나머지는 cold 로 보냈다.(참고로 현재 데이터 보관 정책은 기본적인 데이터는 1년, 로그인 관련 데이터는 2년, 계정관련 데이터는 5년 보관이다.) warm 과 cold 모두 사용해 보니 속도 면에서는 거의 체감하기 힘든 수준으로 비슷했고, 가격은 cold가 더 싸다고 하니 cold 를 사용했지만, 위에 말한 대로 UltraWarm 인스턴스 자체가 비싸다...ㅋ

 

아래처럼 매달 새로운 index (server1_dev_2401, ...) 를 만들고 index_pattern (server1_dev_*, ...) 으로 조회하고 있었다.

 

server1_dev_2401
server1_dev_2402
server1_dev_2403
...
server1_prod_2401
server1_prod_2402
server1_prod_2403
...

 

 

 

 

1. 클러스터에서 UltraWarm / Cold Storage 활성화 체크

 

 

 

2. OpenSearch Dashboard 에서 Index State Management (ISM) 정책 생성

 

아래 정책은 63일 뒤에 UltraWarm 스토리지로 이동하며, 365일 뒤에 인덱스를 삭제하는 스크립트이다. 새로 생성되는 Index 들도 ism_template 에 매칭된다면 해당 정책이 적용된다.

{
  "policy": {
    "description": "Move indices to warm storage after 60 days and delete after 1 year",
    "default_state": "hot",
    "states": [
      {
        "name": "hot",
        "actions": [],
        "transitions": [
          {
            "state_name": "warm",
            "conditions": {
              "min_index_age": "63d"
            }
          }
        ]
      },
      {
        "name": "warm",
        "actions": [
          {
            "warm_migration": {}
          }
        ],
        "transitions": [
          {
            "state_name": "delete",
            "conditions": {
              "min_index_age": "365d"
            }
          }
        ]
      },
      {
        "name": "delete",
        "actions": [
          {
            "delete": {}
          }
        ],
        "transitions": []
      }
    ],
    "ism_template": [
      {
        "index_patterns": ["server1_*", "server2_*"],
        "priority": 100
      }
    ]
  }
}

 

 

3. 정책 적용할 index 선택 및 적용 / 확인

 

 

4. 모니터링