데이터 흐름 - AWS 권장 가이드
데이터 모으기데이터 보존데이터 마이그레이션 접근 방식

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

데이터 흐름

데이터 흐름 중점 영역에는 다음 세 가지 영역이 포함됩니다.

  • 데이터 모으기

  • 데이터 보존

  • 데이터 마이그레이션 접근 방식

데이터 모으기

데이터 수집은 Amazon OpenSearch Service 도메인으로 데이터를 가져오는 방법에 중점을 둡니다. OpenSearch에 적합한 수집 프레임워크를 선택할 때는 데이터 소스와 형식을 철저히 이해하는 것이 가장 중요합니다.

수집 설계를 생성하거나 현대화하는 방법에는 여러 가지가 있습니다. 자체 관리형 수집 파이프라인을 구축하기 위한 많은 오픈 소스 도구가 있습니다. OpenSearch Service는 Fluentd, Logstash 또는 OpenSearch Data Prepper와의 통합을 지원합니다. 이러한 도구는 대부분의 로그 분석 솔루션 개발자에게 널리 사용됩니다. 이러한 도구를 Amazon EC2 인스턴스, Amazon Elastic Kubernetes Service(Amazon EKS) 또는 온프레미스에 배포할 수 있습니다. Logstash와 Fluentd는 모두 Amazon OpenSearch Service 도메인을 출력 대상으로 지원합니다. 그러나 이를 위해서는 Fluentd 또는 Logstash 소프트웨어 버전을 최신 상태로 유지, 패치, 테스트 및 유지해야 합니다.

운영 오버헤드를 줄이기 위해 Amazon OpenSearch Service와의 통합을 지원하는 AWS 관리형 서비스 중 하나를 사용할 수 있습니다. 예를 들어 Amazon OpenSearch Ingestion은 Amazon OpenSearch Service 도메인에 실시간 로그, 지표 및 추적 데이터를 제공하는 완전 관리형 서버리스 데이터 수집기입니다. OpenSearch Ingestion을 사용하면 더 이상 Logstash 또는 Jaeger와 같은 타사 솔루션을 사용하여 OpenSearch Service 도메인으로 데이터를 수집할 필요가 없습니다. OpenSearch Ingestion으로 데이터를 보내도록 데이터 생산자를 구성합니다. 그런 다음 지정한 도메인이나 컬렉션에 데이터를 자동으로 전달합니다. 전송 전에 데이터를 변환하도록 OpenSearch Ingestion을 구성할 수도 있습니다.

또 다른 옵션은 서버리스 수집 파이프라인을 구축하는 데 도움이 되는 완전 관리형 서비스인 Amazon Data Firehose입니다. Firehose는 스트리밍 데이터를 수집, 변환 및 Amazon OpenSearch Service 도메인으로 전송하는 안전한 방법을 제공합니다. 데이터 처리량에 맞게 자동으로 확장할 수 있으며 지속적인 관리가 필요하지 않습니다. 또한 Firehose는 OpenSearch Service 도메인에 로드하기 전에 데이터를 사용 AWS Lambda, 압축 및 일괄 처리하여 수신 레코드를 변환할 수 있습니다.

관리형 서비스를 사용하면 기존 데이터 수집 파이프라인을 사용 중지하거나 현재 설정을 보강하여 운영 오버헤드를 줄일 수 있습니다.

마이그레이션 계획은 현재 수집 파이프라인이 현재 및 향후 사용 사례의 요구 사항을 충족하는지 평가하는 데 좋은 시기입니다. 자체 관리형 Elasticsearch 또는 OpenSearch 클러스터에서 마이그레이션하는 경우 수집 파이프라인은 클라이언트 라이브러리 업데이트를 최소화하면서 엔드포인트를 현재 클러스터에서 Amazon OpenSearch Service 도메인으로 전환하는 것을 지원해야 합니다.

데이터 보존

데이터 수집 및 저장을 계획할 때는 데이터 보존을 계획하고 합의해야 합니다. 로그 분석 사용 사례의 경우 과거 데이터를 사용 중지하기 위해 도메인 내에 올바른 정책을 생성하는 것이 중요합니다. 기존 온프레미스 및 클라우드 VM 기반 아키텍처에서 이동할 때 모든 데이터 노드에 특정 유형의 인스턴스를 사용할 수 있습니다. 데이터 노드는 CPU, 메모리 및 스토리지 프로파일이 동일합니다. 대부분의 고객은 고속 인덱싱 요구 사항에 맞게 처리량이 높은 스토리지를 구성합니다. 이 단일 스토리지 프로파일 아키텍처를 핫 노드 전용 아키텍처 또는 핫 전용이라고 합니다. 핫 전용 아키텍처는 스토리지를 컴퓨팅과 결합하므로 스토리지 요구 사항이 증가하면 컴퓨팅 노드를 추가해야 합니다.

컴퓨팅에서 스토리지를 분리하기 위해 Amazon OpenSearch Service는 UltraWarm 스토리지 계층을 제공합니다. UltraWarm은 기존 데이터 노드보다 더 많은 양의 데이터를 수용할 수 있는 노드를 제공하여 Amazon OpenSearch Service에 읽기 전용 데이터를 저장하는 비용 효율적인 방법을 제공합니다.

계획 중에 데이터 보존 및 처리 요구 사항을 결정합니다. 기존 솔루션의 비용을 줄이려면 UltraWarm 티어를 활용하세요. 데이터의 보존 요구 사항을 식별합니다. 그런 다음 인덱스 상태 관리 정책을 생성하여 데이터를 핫에서 웜으로 이동하거나 필요하지 않은 경우 도메인에서 자동으로 데이터를 삭제합니다. 또한 도메인에 스토리지가 부족하지 않도록 하는 데도 도움이 됩니다.

데이터 마이그레이션 접근 방식

계획 단계에서는 특정 데이터 마이그레이션 접근 방식을 결정하는 것이 중요합니다. 데이터 마이그레이션 접근 방식에 따라 현재 데이터 스토어에 있는 데이터를 갭 없이 대상 스토어로 이동하는 방법이 결정됩니다. 이러한 접근 방식에 대한 절차 세부 정보는 접근 방식을 구현하는 4단계 - 데이터 마이그레이션 섹션에서 다룹니다.

이 섹션에서는 Elasticsearch 또는 OpenSearch 클러스터를 Amazon OpenSearch Service로 마이그레이션하는 데 사용할 수 있는 다양한 방법과 패턴을 다룹니다. 패턴을 선택할 때 다음 요소 목록을 고려하세요(전체는 아님).

  • 기존 자체 관리형 클러스터에서 데이터를 복사할지 아니면 원본 데이터 소스(로그 파일, 제품 카탈로그 데이터베이스)에서 다시 빌드할지 여부

  • 소스 Elasticsearch 또는 OpenSearch 클러스터와 대상 Amazon OpenSearch Service 도메인의 버전 호환성

  • Elasticsearch 또는 OpenSearch 클러스터에 종속된 애플리케이션 및 서비스

  • 마이그레이션에 사용 가능한 기간

  • 기존 환경의 인덱싱된 데이터 볼륨

스냅샷에서 빌드

스냅샷은 자체 관리형 Elasticsearch 클러스터에서 Amazon OpenSearch Service로 마이그레이션하는 가장 인기 있는 방법입니다. 스냅샷은 Amazon S3와 같은 내구성 있는 스토리지 서비스를 사용하여 OpenSearch 또는 Elasticsearch 데이터를 백업하는 방법을 제공합니다. 이 접근 방식을 사용하면 현재 Elasticsearch 또는 OpenSearch 환경의 스냅샷을 생성하여 대상 Amazon OpenSearch Service 환경에서 복원할 수 있습니다. 스냅샷을 복원한 후 애플리케이션이 새 환경을 가리키도록 할 수 있습니다. 이는 다음과 같은 상황에서 더 빠른 솔루션입니다.

  • 소스와 대상이 호환됩니다.

  • 기존 클러스터에는 많은 양의 인덱싱된 데이터가 포함되어 있으므로 재인덱싱하는 데 시간이 많이 걸릴 수 있습니다.

  • 소스 데이터는 재인덱싱에 사용할 수 없습니다.

추가 고려 사항은 4단계 - 데이터 마이그레이션 섹션의 스냅샷 고려 사항을 참조하세요.

소스에서 빌드

이 접근 방식은 현재 Elasticsearch 또는 OpenSearch 클러스터에서 데이터를 이동하지 않을 것임을 의미합니다. 대신 로그 또는 제품 카탈로그 소스에서 대상 Amazon OpenSearch Service 도메인으로 직접 데이터를 다시 로드합니다. 이는 일반적으로 기존 데이터 수집 파이프라인을 약간 변경하여 수행됩니다. 로그 분석 사용 사례에서 소스에서 빌드하려면 소스의 기록 로그를 새 OpenSearch Service 환경으로 다시 로드해야 할 수도 있습니다. 검색 사용 사례의 경우 전체 제품 카탈로그와 콘텐츠를 새 Amazon OpenSearch Service 도메인에 다시 로드해야 할 수 있습니다. 이 접근 방식은 다음 시나리오에서 잘 작동합니다.

  • 소스 및 대상 환경 버전은 스냅샷 복원과 호환되지 않습니다.

  • 마이그레이션의 일환으로 대상 환경에서 데이터 모델을 변경하려고 합니다.

  • 업그레이드 롤링을 방지하기 위해 최신 버전의 Amazon OpenSearch Service로 이동하고 한 번에 주요 변경 사항을 해결하려고 합니다. 비교적 오래된 버전(5.x 이하)의 Elasticsearch를 자체 관리하는 경우이 방법이 좋습니다.

  • 인덱싱 전략을 변경할 수 있습니다. 예를 들어 매일 롤오버하는 대신 새 환경에서 매월 롤오버할 수 있습니다.

소스에서 빌드하는 옵션에 대한 자세한 내용은 2를 참조하세요. 4단계 - 데이터 마이그레이션 섹션의 소스에서 빌드.

기존 Elasticsearch 또는 OpenSearch 환경에서 원격으로 재인덱스

이 접근 방식은 Amazon OpenSearch Service의 원격 재인덱스 API를 사용합니다. 원격 재인덱스를 사용하면 기존 온프레미스 또는 클라우드 기반 Elasticsearch 또는 OpenSearch 클러스터에서 Amazon OpenSearch Service 도메인으로 직접 데이터를 복사할 수 있습니다. 대상 환경으로 전환할 때까지 두 환경 위치 간에 데이터를 동기화된 상태로 유지할 수 있는 자동화를 구축할 수 있습니다.

오픈 소스 데이터 마이그레이션 도구 사용

기존 Elasticsearch 환경에서 대상 Amazon OpenSearch 환경으로 데이터를 마이그레이션하는 데 사용할 수 있는 여러 오픈 소스 도구가 있습니다. 이러한 예 중 하나는 Logstash 유틸리티입니다. Logstash 유틸리티를 사용하여 Elasticsearch 또는 OpenSearch 클러스터에서 데이터를 추출하여 Amazon OpenSearch Service 도메인에 복사할 수 있습니다.

모든 옵션을 평가하고 가장 익숙한 옵션을 선택하는 것이 좋습니다. 선택한 접근 방식이 어리석지 않은지 확인하려면 PoC 단계에서 모든 도구와 자동화를 테스트합니다. 이러한 접근 방식을 구현하는 방법에 대한 자세한 내용과 step-by-step 지침은 4단계 - 데이터 마이그레이션 섹션을 참조하세요.