제퍼넷 로고

Amazon S3, Amazon OpenSearch Service 및 Amazon OpenSearch 수집을 사용한 페타바이트 규모의 로그 분석 | 아마존 웹 서비스

시간

조직에서는 엄청난 속도로 증가하는 대용량 데이터를 관리해야 하는 경우가 많습니다. 동시에 운영 비용을 최적화하여 시기적절한 통찰력을 얻기 위해 이 데이터의 가치를 활용하고 일관된 성과를 달성해야 합니다.

이러한 엄청난 데이터 증가로 인해 데이터 저장소, 데이터 웨어하우스 및 데이터 레이크 전반에 걸친 데이터 확산도 똑같이 어려워질 수 있습니다. 와 현대 데이터 아키텍처 AWS에서는 확장 가능한 데이터 레이크를 신속하게 구축할 수 있습니다. 광범위하고 심층적으로 특별히 구축된 데이터 서비스 컬렉션을 사용합니다. 통합된 데이터 액세스, 보안 및 거버넌스를 통해 규정 준수를 보장합니다. 성능 저하 없이 저렴한 비용으로 시스템을 확장합니다. 조직 경계를 넘어 데이터를 쉽게 공유하여 규모에 맞게 빠르고 민첩하게 의사결정을 내릴 수 있습니다.

다양한 사일로에서 모든 데이터를 가져와 데이터 레이크에 집계하고 해당 데이터를 기반으로 직접 분석 및 기계 학습(ML)을 수행할 수 있습니다. 또한 구조화된 데이터와 구조화되지 않은 데이터 모두를 분석하고 빠르게 통찰력을 얻기 위해 특별히 구축된 데이터 저장소에 다른 데이터를 저장할 수도 있습니다. 이러한 데이터 이동은 내부에서 외부로, 외부에서 내부로, 경계를 중심으로 이루어지거나 공유될 수 있습니다.

예를 들어, 웹 애플리케이션의 애플리케이션 로그 및 추적은 데이터 레이크에서 직접 수집될 수 있으며 해당 데이터의 일부는 일일 분석을 위해 Amazon OpenSearch Service와 같은 로그 분석 저장소로 이동할 수 있습니다. 우리는 이 개념을 다음과 같이 생각한다. 뒤집어서 데이터 이동. Amazon OpenSearch Service에 저장된 분석 및 집계된 데이터는 다시 데이터 레이크로 이동하여 애플리케이션에서 다운스트림 소비를 위한 ML 알고리즘을 실행할 수 있습니다. 우리는 이 개념을 다음과 같이 지칭합니다. 아웃사이드인 데이터 이동.

예시 사용 사례를 살펴보겠습니다. example Corp.는 소셜 콘텐츠를 전문으로 하는 선도적인 Fortune 500대 기업입니다. 하루에 약 500TB의 데이터와 추적을 생성하는 수백 개의 애플리케이션이 있으며 다음과 같은 기준이 있습니다.

  • 2일 동안 빠른 분석을 위해 로그를 사용할 수 있습니다.
  • 2일이 지나면 합리적인 SLA를 통해 분석에 사용할 수 있는 스토리지 계층에서 데이터를 사용할 수 있습니다.
  • 1주일이 지난 데이터는 콜드 스토리지에 30일 동안 보관합니다(규정 준수, 감사 등의 목적).

다음 섹션에서는 유사한 사용 사례를 해결하기 위한 세 가지 가능한 솔루션을 논의합니다.

  • Amazon OpenSearch Service의 계층형 스토리지 및 데이터 수명주기 관리
  • 다음을 사용하여 주문형 로그 수집 Amazon OpenSearch 수집
  • Amazon Simple Storage Service(Amazon S3)를 사용한 Amazon OpenSearch Service 직접 쿼리

솔루션 1: OpenSearch Service의 계층형 스토리지 및 데이터 수명 주기 관리

OpenSearch 서비스는 핫 스토리지, UltraWarm 스토리지, 콜드 스토리지라는 세 가지 통합 스토리지 계층을 지원합니다. 데이터 보존, 쿼리 대기 시간 및 예산 요구 사항에 따라 비용과 성능의 균형을 맞추는 최상의 전략을 선택할 수 있습니다. 서로 다른 스토리지 계층 간에 데이터를 마이그레이션할 수도 있습니다.

핫 스토리지는 인덱싱 및 업데이트에 사용되며 데이터에 대한 가장 빠른 액세스를 제공합니다. 핫 스토리지는 인스턴스 스토어 형태를 취하거나 아마존 엘라스틱 블록 스토어 (Amazon EBS) 볼륨은 각 노드에 연결됩니다.

UltraWarm은 쿼리 빈도가 낮고 핫 스토리지와 동일한 성능이 필요하지 않은 읽기 전용 데이터에 대해 GiB당 비용을 상당히 낮춥니다. UltraWarm 노드는 관련 캐싱 솔루션과 함께 Amazon S3를 사용하여 성능을 향상합니다.

콜드 스토리지는 자주 액세스하지 않거나 기록 데이터를 저장하는 데 최적화되어 있습니다. 콜드 스토리지를 사용하면 UltraWarm 계층에서 인덱스가 분리되어 액세스할 수 없게 됩니다. 해당 데이터를 쿼리해야 할 때 몇 초 안에 이러한 인덱스를 다시 연결할 수 있습니다.

OpenSearch Service 내의 데이터 계층에 대한 자세한 내용은 다음을 참조하세요. Amazon OpenSearch Service에서 요구 사항에 맞는 스토리지 계층을 선택하세요..

솔루션 개요

이 솔루션의 워크플로는 다음 단계로 구성됩니다.

  1. 애플리케이션에서 생성된 수신 데이터는 S3 데이터 레이크로 스트리밍됩니다.
  2. 데이터는 다음을 사용하여 Amazon OpenSearch로 수집됩니다. S3-SQS 거의 실시간 수집 S3 버킷에 설정된 알림을 통해.
  3. 2일 후에는 읽기 쿼리를 지원하기 위해 핫 데이터가 UltraWarm 스토리지로 마이그레이션됩니다.
  4. UltraWarm에서 5일이 지나면 데이터는 21일 동안 콜드 스토리지로 마이그레이션되고 모든 컴퓨팅에서 분리됩니다. 필요할 때 데이터를 UltraWarm에 다시 연결할 수 있습니다. 데이터는 21일 후에 콜드 스토리지에서 삭제됩니다.
  5. 쉬운 롤오버를 위해 일일 인덱스가 유지됩니다. ISM(인덱스 상태 관리) 정책은 2일이 지난 인덱스의 롤오버 또는 삭제를 자동화합니다.

다음은 2일 후에 데이터를 UltraWarm 계층으로 롤오버하고, 5일 후에 콜드 스토리지로 이동하고, 21일 후에 콜드 스토리지에서 삭제하는 샘플 ISM 정책입니다.

{
    "policy": {
        "description": "hot warm delete workflow",
        "default_state": "hot",
        "schema_version": 1,
        "states": [
            {
                "name": "hot",
                "actions": [
                    {
                        "rollover": {
                            "min_index_age": "2d",
                            "min_primary_shard_size": "30gb"
                        }
                    }
                ],
                "transitions": [
                    {
                        "state_name": "warm"
                    }
                ]
            },
            {
                "name": "warm",
                "actions": [
                    {
                        "replica_count": {
                            "number_of_replicas": 5
                        }
                    }
                ],
                "transitions": [
                    {
                        "state_name": "cold",
                        "conditions": {
                            "min_index_age": "5d"
                        }
                    }
                ]
            },
            {
                "name": "cold",
                "actions": [
                    {
                        "retry": {
                            "count": 5,
                            "backoff": "exponential",
                            "delay": "1h"
                        },
                        "cold_migration": {
                            "start_time": null,
                            "end_time": null,
                            "timestamp_field": "@timestamp",
                            "ignore": "none"
                        }
                    }
                ],
                "transitions": [
                    {
                        "state_name": "delete",
                        "conditions": {
                            "min_index_age": "21d"
                        }
                    }
                ]
            },
            {
                "name": "delete",
                "actions": [
                    {
                        "retry": {
                            "count": 3,
                            "backoff": "exponential",
                            "delay": "1m"
                        },
                        "cold_delete": {}
                    }
                ],
                "transitions": []
            }
        ],
        "ism_template": {
            "index_patterns": [
                "log*"
            ],
            "priority": 100
        }
    }
}

고려

UltraWarm은 정교한 캐싱 기술을 사용하여 자주 액세스하지 않는 데이터에 대한 쿼리를 가능하게 합니다. 데이터 액세스가 자주 발생하지 않지만 이 액세스가 가능하려면 UltraWarm 노드의 컴퓨팅이 항상 실행되어야 합니다.

PB 규모로 작동할 때 오류의 영향을 받는 영역을 줄이려면 계층형 스토리지를 사용할 때 구현을 여러 OpenSearch 서비스 도메인으로 분해하는 것이 좋습니다.

다음 두 패턴은 장기 실행 컴퓨팅의 필요성을 제거하고 필요할 때 데이터를 가져오거나 데이터가 있는 곳에서 직접 쿼리하는 주문형 기술을 설명합니다.

솔루션 2: OpenSearch 수집을 통해 요청 시 로그 데이터 수집

OpenSearch Ingestion은 OpenSearch Service 도메인에 실시간 로그 및 추적 데이터를 제공하는 완전 관리형 데이터 수집기입니다. OpenSearch 수집은 오픈 소스 데이터 수집기에 의해 구동됩니다. 데이터 준비자. Data Prepper는 오픈소스 OpenSearch 프로젝트.

OpenSearch Ingestion을 사용하면 다운스트림 분석 및 시각화를 위해 데이터를 필터링, 강화, 변환 및 전달할 수 있습니다. OpenSearch 수집으로 데이터를 보내도록 데이터 생산자를 구성합니다. 지정한 도메인이나 컬렉션에 데이터를 자동으로 전달합니다. 데이터를 전달하기 전에 데이터를 변환하도록 OpenSearch 수집을 구성할 수도 있습니다. OpenSearch 수집은 서버리스이므로 인프라 확장, 수집 플릿 운영, 소프트웨어 패치 또는 업데이트에 대해 걱정할 필요가 없습니다.

Amazon S3를 소스로 사용하여 OpenSearch 수집으로 데이터를 처리할 수 있는 방법에는 두 가지가 있습니다. 첫 번째 옵션은 S3-SQS 처리입니다. 파일이 S3에 작성된 후 거의 실시간으로 파일을 검색해야 하는 경우 S3-SQS 처리를 사용할 수 있습니다. 그것은 아마존 단순 대기열 서비스 (Amazon S3) 수신하는 대기열 S3 이벤트 알림. 처리할 버킷 내에서 객체가 저장되거나 수정될 때마다 이벤트가 발생하도록 S3 버킷을 구성할 수 있습니다.

또는 일회성 또는 반복 예약 검사를 사용하여 S3 버킷의 데이터를 일괄 처리할 수 있습니다. 예약된 스캔을 설정하려면 모든 S3 버킷에 적용되는 스캔 수준 또는 버킷 수준의 일정으로 파이프라인을 구성하십시오. 일회성 검사 또는 일괄 처리를 위한 반복 검사로 예약 검사를 구성할 수 있습니다.

OpenSearch 수집에 대한 포괄적인 개요는 다음을 참조하세요. Amazon OpenSearch 수집. Data Prepper 오픈 소스 프로젝트에 대한 자세한 내용을 보려면 다음을 방문하세요. 데이터 준비자.

솔루션 개요

우리는 다음과 같은 주요 구성요소로 아키텍처 패턴을 제시합니다.

  • 애플리케이션 로그는 데이터 레이크로 스트리밍되어 OpenSearch 수집을 사용하여 거의 실시간으로 OpenSearch 서비스에 핫 데이터를 공급하는 데 도움이 됩니다. S3-SQS 처리.
  • OpenSearch 서비스 내의 ISM 정책은 인덱스 롤오버 또는 삭제를 처리합니다. ISM 정책을 사용하면 인덱스 수명, 인덱스 크기 또는 문서 수의 변화에 ​​따라 이러한 주기적인 관리 작업을 트리거하여 자동화할 수 있습니다. 예를 들어, 2일 후에 인덱스를 읽기 전용 상태로 이동하고 3일의 설정된 기간 후에 삭제하는 정책을 정의할 수 있습니다.
  • S3 데이터 레이크의 콜드 데이터는 OpenSearch Ingestion을 통해 OpenSearch Service에서 요청 시 소비될 수 있습니다. 예약된 스캔.

다음 다이어그램은 솔루션 아키텍처를 보여줍니다.

워크 플로우에는 다음 단계가 포함됩니다.

  1. 애플리케이션에서 생성된 수신 데이터는 S3 데이터 레이크로 스트리밍됩니다.
  2. 현재 데이터는 S3 버킷에 설정된 알림을 통해 거의 실시간으로 S3-SQS 수집을 사용하여 OpenSearch 서비스로 수집됩니다.
  3. 쉬운 롤오버를 위해 일일 인덱스가 유지됩니다. ISM 정책은 2일이 지난 색인의 롤오버 또는 삭제를 자동화합니다.
  4. 2일이 지난 데이터 분석을 요청했는데 해당 데이터가 UltraWarm 계층에 없는 경우 특정 기간 사이에 Amazon S3의 일회성 스캔 기능을 사용하여 데이터가 수집됩니다.

예를 들어, 현재 날짜가 10년 2024월 6일이고 분석을 위해 특정 간격으로 2024년 3월 XNUMX일의 데이터가 필요한 경우 다음과 같이 YAML 구성에서 Amazon SXNUMX 스캔을 사용하여 OpenSearch 수집 파이프라인을 생성할 수 있습니다. start_timeend_time 버킷의 객체를 언제 검사할지 지정하려면 다음을 수행하세요.

version: "2"
ondemand-ingest-pipeline:
  source:
    s3:
      codec:
        newline:
      compression: "gzip"
      scan:
        start_time: 2023-12-28T01:00:00
        end_time: 2023-12-31T09:00:00
        buckets:
          - bucket:
              name: <bucket-name>
      aws:
        region: "us-east-1"
        sts_role_arn: "arn:aws:iam::<acct num>:role/PipelineRole"
    
    acknowledgments: true
  processor:
    - parse_json:
    - date:
        from_time_received: true
        destination: "@timestamp"           
  sink:
    - opensearch:                  
        index: "logs_ondemand_20231231"
        hosts: [ "https://search-XXXX-domain-XXXXXXXXXX.us-east-1.es.amazonaws.com" ]
        aws:                  
          sts_role_arn: "arn:aws:iam::<acct num>:role/PipelineRole"
          region: "us-east-1"

고려

압축을 활용하세요

Amazon S3의 데이터를 압축하면 전체 데이터 공간이 줄어들고 상당한 비용 절감 효과를 얻을 수 있습니다. 예를 들어 매월 15PB의 원시 JSON 애플리케이션 로그를 생성하는 경우 GZIP과 같은 압축 메커니즘을 사용하면 크기를 약 1PB 이하로 줄여 상당한 비용 절감 효과를 얻을 수 있습니다.

가능하면 파이프라인을 중지하세요.

OpenSearch 수집은 파이프라인에 설정된 최소 및 최대 OCU 사이에서 자동으로 확장됩니다. 파이프라인 구성에 언급된 지정된 기간 동안 파이프라인이 Amazon S3 스캔을 완료한 후 파이프라인은 최소 OCU에서 지속적인 모니터링을 위해 계속 실행됩니다.

새 객체가 생성될 것으로 예상되지 않는 과거 기간에 대한 주문형 수집의 경우 다음과 같은 지원되는 파이프라인 측정항목을 사용하는 것이 좋습니다. recordsOut.count 만드는 방법 아마존 클라우드 워치 파이프라인을 중지할 수 있는 경보. 지원되는 측정항목 목록은 다음을 참조하세요. 파이프라인 측정항목 모니터링.

CloudWatch 경보는 CloudWatch 지표가 일정 시간 동안 지정된 값을 초과하면 작업을 수행합니다. 예를 들어 모니터링을 원할 수 있습니다. recordsOut.count 요청을 시작하려면 0분 이상 5이어야 합니다. 파이프라인을 중지하다 를 통해 AWS 명령 줄 인터페이스 (AWS CLI) 또는 API.

솔루션 3: Amazon S3를 사용한 OpenSearch Service 직접 쿼리

Amazon S3를 사용한 OpenSearch Service 직접 쿼리(미리 보기) 서비스 간 전환 없이 Amazon S3 및 S3 데이터 레이크의 운영 로그를 쿼리하는 새로운 방법입니다. 이제 클라우드 개체 저장소에서 자주 쿼리되지 않는 데이터를 분석하는 동시에 OpenSearch Service의 운영 분석 및 시각화 기능을 사용할 수 있습니다.

Amazon S3를 사용한 OpenSearch Service 직접 쿼리는 다음을 제공합니다. 제로 ETL 통합 운영 데이터를 직접 쿼리할 수 있게 하여 데이터 복제 또는 여러 분석 도구 관리로 인한 운영 복잡성을 줄이고 비용과 실행 시간을 줄입니다. 이 제로 ETL 통합은 사전 정의된 대시보드를 포함한 다양한 로그 유형 템플릿을 활용하고 해당 로그 유형에 맞게 데이터 가속화를 구성할 수 있는 OpenSearch Service 내에서 구성 가능합니다. 템플릿에는 다음이 포함됩니다. VPC 흐름 로그, 탄력적로드 밸런싱 로그, NGINX 로그 및 가속에는 인덱스 건너뛰기, 구체화된 뷰 및 적용 인덱스가 포함됩니다.

Amazon S3를 통한 OpenSearch Service 직접 쿼리를 사용하면 보안 포렌식 및 위협 분석에 중요한 복잡한 쿼리를 수행하고 여러 데이터 소스에 걸쳐 데이터를 상호 연관시킬 수 있으므로 팀이 서비스 가동 중지 시간 및 보안 이벤트를 조사하는 데 도움이 됩니다. 통합을 생성한 후 OpenSearch 대시보드 또는 OpenSearch API에서 직접 데이터 쿼리를 시작할 수 있습니다. 연결을 감사하여 확장 가능하고 비용 효율적이며 안전한 방식으로 설정되었는지 확인할 수 있습니다.

OpenSearch Service에서 Amazon S3로의 직접 쿼리는 다음 내에서 Spark 테이블을 사용합니다. AWS 접착제 데이터 카탈로그. AWS Glue 메타데이터 카탈로그에 테이블을 분류한 후 OpenSearch 대시보드를 통해 S3 데이터 레이크의 데이터에 대해 직접 쿼리를 실행할 수 있습니다.

솔루션 개요

다음 다이어그램은 솔루션 아키텍처를 보여줍니다.

이 솔루션은 다음과 같은 주요 구성 요소로 구성됩니다.

  • 당일의 핫 데이터는 OpenSearch Ingestion S3-SQS 처리 기능을 사용하는 이벤트 중심 아키텍처 패턴을 통해 OpenSearch 서비스 도메인으로 스트림 처리됩니다.
  • 핫 데이터 수명주기는 일일 인덱스에 연결된 ISM 정책을 통해 관리됩니다.
  • 콜드 데이터는 Amazon S3 버킷에 있으며 분할 및 카탈로그화되어 있습니다.

다음 스크린샷은 샘플을 보여줍니다. http_logs AWS Glue 메타데이터 카탈로그에 등록된 테이블입니다. 자세한 단계는 다음을 참조하세요. AWS Glue의 데이터 카탈로그 및 크롤러.

데이터 소스를 생성하기 전에 버전 2.11 이상의 OpenSearch Service 도메인과 적절한 AWS Glue 데이터 카탈로그의 대상 S3 테이블이 있어야 합니다. AWS 자격 증명 및 액세스 관리 (IAM) 권한. IAM은 원하는 S3 버킷에 액세스해야 하며 AWS Glue 데이터 카탈로그에 대한 읽기 및 쓰기 액세스 권한이 있어야 합니다. 다음은 OpenSearch Service를 통해 AWS Glue 데이터 카탈로그에 액세스할 수 있는 적절한 권한이 있는 샘플 역할 및 신뢰 정책입니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "directquery.opensearchservice.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

다음은 Amazon S3 및 AWS Glue에 액세스할 수 있는 샘플 사용자 지정 정책입니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Statement1",
            "Effect": "Allow",
            "Action": "es:ESHttp*",
            "Resource": "arn:aws:es:*:<acct_num>:domain/*"
        },
        {
            "Sid": "Statement2",
            "Effect": "Allow",
            "Action": [
                "s3:Get*",
                "s3:List*",
                "s3:Put*",
                "s3:Describe*"
            ],
            "Resource": [
                "arn:aws:s3:::<bucket-name>",
                "arn:aws:s3:::<bucket-name>/*"
            ]
        },
        {
            "Sid": "GlueCreateAndReadDataCatalog",
            "Effect": "Allow",
            "Action": [
                "glue:GetDatabase",
                "glue:CreateDatabase",
                "glue:GetDatabases",
                "glue:CreateTable",
                "glue:GetTable",
                "glue:UpdateTable",
                "glue:DeleteTable",
                "glue:GetTables",
                "glue:GetPartition",
                "glue:GetPartitions",
                "glue:CreatePartition",
                "glue:BatchCreatePartition",
                "glue:GetUserDefinedFunctions"
            ],
            "Resource": [
                "arn:aws:glue:us-east-1:<acct_num>:catalog",
                "arn:aws:glue:us-east-1:<acct_num>:database/*",
                "arn:aws:glue:us-east-1:<acct_num>:table/*"
            ]
        }
    ]
}

OpenSearch Service 콘솔에서 새 데이터 소스를 생성하려면 새 데이터 소스의 이름을 제공하고 데이터 소스 유형을 다음과 같이 지정합니다. AWS Glue 데이터 카탈로그가 포함된 Amazon S3을 클릭하고 데이터 소스에 대한 IAM 역할을 선택합니다.

데이터 소스를 생성한 후 도메인의 OpenSearch 대시보드로 이동하여 액세스 제어를 구성하고, 테이블을 정의하고, 인기 있는 로그 유형에 대한 로그 유형 기반 대시보드를 설정하고, 데이터를 쿼리하는 데 사용할 수 있습니다.

테이블을 설정한 후 OpenSearch 대시보드를 통해 S3 데이터 레이크의 데이터를 쿼리할 수 있습니다. 다음에 대해 샘플 SQL 쿼리를 실행할 수 있습니다. http_logs 다음 스크린샷에 표시된 것처럼 AWS Glue 데이터 카탈로그 테이블에서 생성한 테이블입니다.

모범 사례

필요한 데이터만 수집

비즈니스 요구 사항을 토대로 작업하고 필요한 올바른 데이터 세트를 설정하세요. 시끄러운 데이터 수집을 방지하고 선별, 샘플링 또는 집계된 데이터만 수집할 수 있는지 평가하세요. 이렇게 정리되고 선별된 데이터 세트를 사용하면 이 데이터를 수집하는 데 필요한 컴퓨팅 및 스토리지 리소스를 최적화하는 데 도움이 됩니다.

수집 전 데이터 크기 줄이기

데이터 수집 파이프라인을 설계할 때 압축, 필터링, 집계와 같은 전략을 사용하여 수집된 데이터의 크기를 줄이세요. 이렇게 하면 더 작은 크기의 데이터를 네트워크를 통해 전송하고 데이터 계층에 저장할 수 있습니다.

결론

이 게시물에서는 최신 데이터 아키텍처에서 OpenSearch Service를 사용하여 페타바이트 규모의 로그 분석을 지원하는 솔루션에 대해 논의했습니다. OpenSearch Service 도메인에 로그를 전달하기 위한 서버리스 수집 파이프라인을 생성하고, ISM 정책을 통해 인덱스를 관리하고, OpenSearch 수집 사용을 시작하기 위한 IAM 권한을 구성하고, 데이터 레이크의 데이터에 대한 파이프라인 구성을 생성하는 방법을 배웠습니다. 또한 Amazon S3 기능(미리 보기)을 통해 OpenSearch Service 직접 쿼리를 설정하고 사용하여 데이터 레이크에서 데이터를 쿼리하는 방법도 배웠습니다.

OpenSearch Service를 대규모로 사용할 때 워크로드에 적합한 아키텍처 패턴을 선택하려면 시간에 따른 성능, 대기 시간, 비용 및 데이터 볼륨 증가를 고려하여 올바른 결정을 내리세요.

  • 핫 데이터에 대한 빠른 액세스가 필요하고 읽기 전용 데이터용 UltraWarm 노드를 사용하여 비용과 성능의 균형을 맞추려는 경우 인덱스 상태 관리 정책과 함께 계층형 스토리지 아키텍처를 사용하세요.
  • 핫 노드에 보관되지 않은 데이터를 쿼리하기 위해 수집 대기 시간을 허용할 수 있는 경우 OpenSearch Service에 대한 데이터의 주문형 수집을 사용합니다. Amazon S3에서 압축된 데이터를 사용하고 주문형 데이터를 OpenSearch Service로 수집하면 상당한 비용 절감 효과를 얻을 수 있습니다.
  • OpenSearch Service의 풍부한 분석 및 시각화 기능을 사용하여 Amazon S3에서 작업 로그를 직접 분석하려는 경우 S3 기능을 통한 직접 쿼리를 사용하십시오.

다음 단계로 다음을 참조하세요. Amazon OpenSearch 개발자 안내서 엔터프라이즈 애플리케이션을 위한 확장 가능한 관측 가능성 솔루션을 구축하는 데 사용할 수 있는 로그 및 메트릭 파이프라인을 탐색합니다.


저자에 관하여

자가디시 쿠마르(Jag) Amazon OpenSearch Service에 중점을 두고 있는 AWS의 수석 전문가 솔루션 아키텍트입니다. 그는 데이터 아키텍처에 깊은 열정을 갖고 있으며 고객이 AWS에서 대규모 분석 솔루션을 구축하도록 돕습니다.


무투 피차이마니
Amazon OpenSearch Service의 수석 전문 솔루션 설계자입니다. 그는 대규모 검색 애플리케이션과 솔루션을 구축합니다. Muthu는 네트워킹 및 보안 주제에 관심이 있으며 텍사스주 오스틴에 거주하고 있습니다.


샘 셀반
Amazon OpenSearch Service의 수석 전문 솔루션 설계자입니다.

spot_img

최신 인텔리전스

spot_img