AWS Opensearch Datastream 및 ISM

이전에 FluentD, Flunt-bit를 활용해 EKS 환경에서 EFK 구조의 로깅 환경을 구축하였다. 인덱스를 날짜 별로 자동 생성되도록 fluentd에 설정하여 생성하였지만 비용과 운영을 효율적으로 관리하기 위해 인덱스를 Ultrawarm, Cold 스토리지에 저장할 필요가 생겼다. 시계열 데이터를 관리하는 일반적인 워크플로에는 롤오버 인덱스 별칭 생성, 쓰기 인덱스 정의, 백업 인덱스에 대한 공통 매핑 및 설정 정의와 같은 여러 단계가 포함되지만 Amazon OpenSearch Service의 데이터 스트림은 이러한 초기 설정 프로세스가 간소화되어있어 편리하게 구축할 수 있었다.

 

Opensearch datastream document

https://opensearch.org/docs/latest/dashboards/im-dashboards/datastream/

Data streams

 

 

 

OpenSearch에서 인덱스 대신 데이터 스트림(Data Stream)을 사용하는 주요 장점은 주로 데이터 관리와 성능 측면인 것 같다. 데이터 스트림은 시간에 따라 지속적으로 수집되는 데이터, 특히 로그나 이벤트 같은 시계열 데이터에 적합하다고 한다.

특징은 다음과 같다.

1. 자동화된 롤오버 관리:
   • 데이터 스트림은 롤오버를 통해 새 인덱스를 자동으로 생성해 관리한다. 일정한 크기나 기간이 지나면 새로운 인덱스로 데이터를 옮기고, 이전 인덱스를 보존하여 효율적으로 관리한다.
2. 효율적인 데이터 수명 주기 관리:
   • 데이터 스트림은 ISM 정책을 적용해 핫(Hot), 웜(Warm), 콜드(Cold) 영역으로 데이터를 이동시키며 효율적으로 저장소를 관리할 수 있다. 이를 통해 사용 빈도가 높은 최신 데이터를 핫 스토리지에, 오래된 데이터를 저렴한 웜 또는 콜드 스토리지로 옮겨 비용과 성능을 최적화할 수 있다.
3. 데이터 인덱스 관리를 위한 단순화된 접근:
   • 데이터 스트림은 백엔드에서 여러 개의 백킹인덱스를 다루고 있지만, 사용자 입장에서는 하나의 스트림으로 접근하게 되어 쿼리와 작업이 간소화된다. 이를 통해 인덱스가 많아져도 특정 데이터 스트림에 쉽게 쿼리할 수 있다.
4. 쓰기 성능 최적화:
   • 롤오버 시 새로운 인덱스로 쓰기가 자동으로 전환되기 때문에, 과도한 쓰기로 인해 성능 저하가 발생할 가능성을 줄인다. 특히 대량의 로그나 이벤트 데이터를 수집하는 환경에서 유용하다.
5. 인덱스 수 제한 완화:
   • 데이터 스트림을 사용하면 OpenSearch 클러스터의 인덱스 수 제한에 덜 영향을 받는다. 각 데이터 스트림이 관리하는 인덱스를 합산해도 일반적인 인덱스 수 관리보다 성능 유지가 용이하다.

 

해당 포스팅에서 Helm Charts를 활용하여 Fluent-bit, FluentD를 설치하는 과정이 있으니 이를 통해 설치하도록 한다.

Chart: fluent/fluentd-0.5.2                   

Appversion: v1.16.2

https://sh970901.tistory.com/152

쿠버네티스[EKS] EFK (Elastic, Fluent-bit, Kibana) helm 설치

 

Opensearch Datastream을 활용하기 위해 FluentD value.yaml에서 Output을 수정할 필요가 있다. 

<match kubernetes.**>
   @type opensearch_data_stream
   data_stream_name "data_stream name"
   data_stream_template_name "data_stream_template_name"
   host "opensearch url"
   port 443
   path ""
   scheme "https"
   user username
   password password
   aws_auth true
   aws_region "ap-northeast-2"
   verify_es_version_at_startup false
   include_timestamp true
   include_tag_key true
   time_key @timestamp
   reload_connections true
   reconnect_on_error true
   reload_on_failure true
 </match>

 

이제 이전과 달리 인덱스 생성 규칙을 fluentd에서 관리하지 않고 datastream을 통해 로그를 전송하게 된다. 키바나 콘솔에서 확인해보면 실제로 백킹인덱스로 관리되는 것을 볼 수 있었다. 해당 인덱스에 document가 무수히 쌓이지 않기 위해 Opensearch에서 특정 규칙을 지정하여 인덱스를 Rollover하고 보관주기에 따라 warm, cold 영역으로 마이그레이션 하도록 ISM을 생성하였다. warm, cold 계층을 활용하기 위해서는 Opensearch를 생성할 때 UltraWarm 노드와 Cold Storage를 활성화해야한다.

 

데이터 스트림이 여러 개의 백킹인덱스를 다루고 있기에 당연히 샤드 수와 레플리카 수도 신중해야한다. 

샤드를 고르게 분배하려면 데이터 노드 수(또는 AZ 수)의 배수로 설정하는 것이 좋고, 레플리카 수는 AZ의 배수로 설정하는 것이 좋다.

 

 

인덱스는 샤드 단위로 데이터 노드에 저장되기 때문에 각 샤드는 하나의 데이터 노드에 할당된다. 따라서 샤드 수를 데이터 노드 수의 배수로 설정하면 샤드가 노드에 고르게 분배될 수 있어 특정 노드에 과부하가 걸리는 것을 방지한다. 또한 샤드를 고르게 분배해 두면 특정 노드에 데이터가 집중되는 것을 방지하여 쿼리나 색인 작업을 더욱 빠르게 처리할 수 있다.

 

레플리카는 샤드의 복사본으로, 원본 샤드가 장애를 겪더라도 데이터 손실을 방지하고 읽기 성능을 높인다. 레플리카 수를 가용 영역(AZ)의 배수로 설정하면 각 AZ에 최소한 하나의 레플리카가 존재하게 되어, 특정 AZ에서 장애가 발생하더라도 데이터 접근이 보장된다. 가용 영역의 배수로 레플리카를 설정할 경우, 데이터의 분산과 복구가 각 AZ에 걸쳐 효율적으로 이루어지므로 빠른 복구와 부하 분산을 통해 시스템 안정성을 높일 수 있다.

 

prod.privacy-datastream이라는 이름의 datastream에 대하여 해당 ism이 적용되도록 설정하였다.

요약하자면 하루 기준으로 rollover를 수행하고 hot_state에서 3일이 경과되면 warn_state로 이동하여 warm migration을 진행하며 8일이 지나면 cold_state로 이동하여 cold_migration을 진행하고 5년 후 삭제되도록 설정하였다. cold 영역의 데이터를 다시 읽기 위해서 다시 warm 노드로 migration이 필요하다.

{
    "id": "prd-privacy-ism-policy",
    "seqNo": 24706,
    "primaryTerm": 1,
    "policy": {
        "policy_id": "prd-privacy-ism-policy",
        "description": "prd-privacy-ism-policy",
        "last_updated_time": 1729848400036,
        "schema_version": 21,
        "error_notification": null,
        "default_state": "hot_state",
        "states": [
            {
                "name": "hot_state",
                "actions": [
                    {
                        "retry": {
                            "count": 3,
                            "backoff": "exponential",
                            "delay": "1m"
                        },
                        "rollover": {
                            "min_doc_count": 500,
                            "min_index_age": "1d",
                            "copy_alias": false
                        }
                    }
                ],
                "transitions": [
                    {
                        "state_name": "warm_state",
                        "conditions": {
                            "min_index_age": "3d"
                        }
                    }
                ]
            },
            {
                "name": "warm_state",
                "actions": [
                    {
                        "retry": {
                            "count": 3,
                            "backoff": "exponential",
                            "delay": "1m"
                        },
                        "warm_migration": {}
                    }
                ],
                "transitions": [
                    {
                        "state_name": "cold_state",
                        "conditions": {
                            "min_index_age": "8d"
                        }
                    }
                ]
            },
            {
                "name": "cold_state",
                "actions": [
                    {
                        "retry": {
                            "count": 3,
                            "backoff": "exponential",
                            "delay": "1m"
                        },
                        "cold_migration": {
                            "start_time": null,
                            "end_time": null,
                            "timestamp_field": "@timestamp",
                            "ignore": "none"
                        }
                    }
                ],
                "transitions": [
                    {
                        "state_name": "delete_state",
                        "conditions": {
                            "min_index_age": "1825d"
                        }
                    }
                ]
            },
            {
                "name": "delete_state",
                "actions": [
                    {
                        "retry": {
                            "count": 3,
                            "backoff": "exponential",
                            "delay": "1m"
                        },
                        "cold_delete": {}
                    }
                ],
                "transitions": []
            }
        ],
        "ism_template": [
            {
                "index_patterns": [
                    "prod.privacy-datastream"
                ],
                "priority": 5,
                "last_updated_time": 1729842131186
            }
        ]
    }
}

 

 

각 영역은 다음과 같은 특징이 있다.

 

Hot 영역 

• 주 용도: 최신 데이터 저장
• 특징:
  • 가장 활발하게 쓰기, 읽기, 업데이트가 일어나는 영역으로, 성능이 중요한 데이터가 저장된다.
  • 보통 SSD와 같은 고성능 스토리지를 사용하며 CPU와 메모리 리소스가 충분히 할당된다.
  • 빠른 검색 속도와 실시간 분석이 필요한 로그, 트랜잭션 데이터, 이벤트와 같은 최근 데이터를 처리한다.
• 주요 사례: 로그 모니터링 시스템에서 1일~1주일 간의 데이터, 데이터 수집 파이프라인에서 가장 최근에 수집된 시계열 데이터.

Warm 영역

• 주 용도: 접근 빈도가 낮아진 중기 보존 데이터
• 특징:
  • 핫 영역보다 접근 빈도가 낮지만 여전히 분석에 필요할 수 있는 데이터가 저장된다.
  • 비교적 낮은 비용의 스토리지와 중간 수준의 성능을 제공하는 인스턴스에 배치된다.
  • 데이터는 거의 업데이트되지 않고 검색 용도로만 사용되므로, 주기적으로 인덱스를 롤오버하고 데이터 수명을 관리하는 데 적합하다.
• 주요 사례: 최근 몇 달 간의 로그 데이터 또는 월간 보고서와 같이 자주 사용하지는 않지만 종종 필요한 데이터.

Cold 영역

• 주 용도: 장기 보존 및 가끔 조회되는 데이터
• 특징:
  • 저장 비용이 가장 낮은 스토리지에 배치되며, 매우 드문 검색이 예상되는 데이터가 저장된다.
  • 성능은 낮지만 필요할 때만 접근할 수 있는 경제적인 옵션으로, 일반적으로 아카이브 형태의 데이터를 처리한다.
  • 거의 읽기 요청이 없고, 업데이트나 실시간 검색이 필요 없는 데이터가 적합하다.
• 주요 사례: 1년 이상 된 로그 또는 감사 데이터, 규정 준수를 위해 보관해야 하는 장기 데이터.

각 스토리지 옵션에 대해서 하기 내용을 확인하면 더 도움이 될 것 같다.

 

https://aws.amazon.com/ko/blogs/tech/opensearch-sizing/

동작 방식과 함께 알아보는 최적의 Amazon OpenSearch Service 사이징 | Amazon Web Services

 

관련 영상은 하기 링크를 참고

https://www.youtube.com/watch?v=e9GpbaT18Mk&t=1624s