다음을 통해 공유

내보낸 기록 데이터를 호스팅할 대상 Azure 플랫폼 선택

  • 아티클

마이그레이션 프로세스 중에 내리는 중요한 결정 중 하나는 기록 데이터를 저장할 위치입니다. 이 결정을 내리려면 다양한 대상 플랫폼을 이해하고 비교할 수 있어야 합니다.

이 문서에서는 성능, 비용, 유용성 및 관리 오버헤드 측면에서 대상 플랫폼을 비교합니다.

참고 항목

이 표의 고려 사항은 기록 로그 마이그레이션에만 적용되며 장기 보존 등의 다른 시나리오에서는 적용되지 않습니다.

기본 로그/보관 ADX(Azure Data Explorer) Azure Blob Storage ADX + Azure Blob Storage
기능: • 기존 Azure Monitor 로그 환경 대부분을 저렴한 비용으로 적용합니다.
• 기본 로그는 8일 동안 보존된 후 보관 파일로 자동으로 전송됩니다(원래 보존 기간에 따라).
• 검색 작업을 사용하여 페타바이트 단위의 데이터를 검색하고 특정 이벤트를 찾습니다.
• 특정 시간 범위에 대한 심층 조사를 위해 보관 파일에서 데이터를 복원합니다. 그런 다음, 추가 분석을 위해 핫 캐시에서 데이터를 사용할 수 있습니다.		 • ADX와 Microsoft Sentinel 모두 KQL(Kusto 쿼리 언어)을 사용하여 두 플랫폼에서 데이터를 쿼리, 집계 또는 상호 연결할 수 있습니다. 예를 들어 Microsoft Azure Sentinel에서 KQL 쿼리를 실행하여 ADX에 저장된 데이터를 Log Analytics에 저장된 데이터와 연결할 수 있습니다.
• ADX를 사용하면 클러스터 크기와 구성을 강력히 제어할 수 있습니다. 예를 들어 더 큰 클러스터를 만들어 더 높은 수집 처리량을 달성하거나 비용을 제어하기 위해 더 작은 클러스터를 만들 수 있습니다.		 • Blob Storage는 대량의 비정형 데이터를 저장하는 데 최적화되어 있습니다.
• 경쟁력 있는 비용을 제공합니다.
• 조직에서 규정 준수 또는 감사 요구 사항에 부합해야 하는 경우와 같이 조직이 접근성이나 성능에 우선 순위를 두지 않는 시나리오에 적합합니다.		 • 데이터는 저렴한 비용으로 Blob Storage에 저장됩니다.
• ADX를 사용하여 Kusto 쿼리 언어에서 데이터를 쿼리하여 데이터에 쉽게 액세스할 수 있습니다. ADX를 사용하여 Azure Monitor 데이터를 쿼리하는 방법 알아보기
유용성 우수함

보관 및 검색 옵션은 사용하기 쉽고 Microsoft Sentinel 포털에서 액세스할 수 있습니다. 그러나 쿼리에 데이터를 즉시 사용할 수는 없습니다. 검색을 수행하여 데이터를 검색해야 합니다. 검색 작업은 검색하고 반환하는 데이터의 양에 따라 다소 시간이 걸릴 수 있습니다.		 적절

Microsoft Azure Sentinel의 컨텍스트에서 매우 쉽게 사용할 수 있습니다. 예를 들어 Azure 통합 문서를 사용하여 Microsoft Sentinel 및 ADX에 분산된 데이터를 시각화할 수 있습니다. ADX 프록시를 사용하여 Microsoft Sentinel 포털에서 ADX 데이터를 쿼리할 수도 있습니다.		 나쁨

과거 데이터 마이그레이션을 사용하면 수백만 개의 파일을 처리해야 할 수 있으며 데이터를 탐색하는 것은 어려운 일이 됩니다.		 보통

externaldata 연산자를 사용하는 것은 참조할 Blob이 많을 때 매우 어려운 작업이지만 외부 ADX 테이블을 사용하면 이 문제가 해소됩니다. 외부 테이블 정의는 Blob Storage 폴더 구조를 이해하고 다양한 Blob 및 폴더에 포함된 데이터를 투명하게 쿼리할 수 있도록 합니다.
관리 오버헤드: 완전 관리됨

검색 및 보관 옵션은 완전히 관리되며 관리 오버헤드를 추가하지 않습니다.		 높음

ADX는 Microsoft Sentinel 외부에 있으며 모니터링 및 유지 관리가 필요합니다.		 낮음

이 플랫폼은 유지 관리가 거의 필요하지 않지만 이 플랫폼을 선택하면 수명 주기 관리 설정과 같은 모니터링 및 구성 작업이 추가됩니다.		 중간

이 옵션을 사용하여 ADX 및 Azure Blob Storage를 유지 관리하고 모니터링하며, 둘 다 Microsoft Sentinel의 외부 구성 요소입니다. 경우에 따라 ADX가 종료될 수 있지만 이 옵션을 사용할 때는 추가 관리 오버헤드를 고려합니다.
성능: 중간

일반적으로 검색 작업을 사용하여 보관 내의 기본 로그와 상호 작용합니다. 이러한 검색 작업은 데이터에 대한 액세스를 유지 관리하지만 데이터에 즉시 액세스할 필요는 없는 경우에 적합합니다.		 높음에서 낮음

• ADX 클러스터의 쿼리 성능은 클러스터의 노드 수, 클러스터 가상 머신 SKU, 데이터 분할 등에 따라 달라집니다.
• 클러스터에 노드를 추가하면 추가 비용이 발생하면서 성능이 향상됩니다.
• ADX를 사용하는 경우 성능과 비용의 균형을 맞추도록 클러스터 크기를 구성하는 것이 좋습니다. 이 구성은 마이그레이션을 완료해야 하는 속도, 데이터에 액세스하는 빈도 및 예상 응답 시간을 포함하여 조직의 요구 사항에 따라 달라집니다.		 낮음

프리미엄 또는 표준의 두 가지 성능 계층을 제공합니다. 두 계층 모두 장기 스토리지를 위한 옵션이지만 표준은 비용 효율적입니다. 성능 및 확장성 제한에 대해 알아봅니다.		 낮음

데이터가 Blob Storage에 있기 때문에 성능은 해당 플랫폼에 따라 제한됩니다.
비용: 높음

비용은 다음 두 가지 구성 요소로 구성됩니다.
• 수집 비용. 기본 로그에 수집된 모든 데이터 GB에는 약 $1/GB의 Microsoft Sentinel 및 Azure Monitor 로그 수집 비용이 적용됩니다. 가격 책정 세부 정보를 참조하세요.
• 보관 비용. 보관 계층의 데이터 비용은 매월 약 $0.02/GB까지 합산됩니다. 가격 책정 세부 정보를 참조하세요.
이러한 두 비용 구성 요소 외에도 데이터에 자주 액세스해야 하는 경우 검색 작업을 통해 데이터에 액세스할 때 추가 비용이 적용됩니다.		 높음에서 낮음

• ADX는 가상 머신의 클러스터이므로 컴퓨팅, 스토리지 및 네트워킹 사용량과 ADX 태그에 따라 요금이 청구됩니다(가격 책정 세부 정보 참조). 따라서 클러스터에 더 많은 노드를 추가하고 더 많은 데이터를 저장할수록 비용은 증가합니다.
• ADX는 주문형 워크로드에 맞게 조정되는 자동 스케일링 기능도 제공합니다. 또한 ADX는 예약 인스턴스 가격 책정의 이점을 누릴 수 있습니다. Azure 가격 계산기에서 고유한 비용 계산을 실행할 수 있습니다.		 낮음

최적의 설정을 사용하면 Azure Blob Storage의 비용이 가장 낮습니다. 효율성과 비용 절감을 위해 Azure Storage 수명 주기 관리를 사용하여 이전 Blob을 더 저렴한 스토리지 계층에 자동으로 배치할 수 있습니다.		 낮음

이 경우 ADX는 프록시 역할을 하므로 클러스터가 작을 수 있습니다. 또한 데이터에 액세스할 필요가 없는 경우 클러스터가 종료될 수 있으며 데이터 액세스가 필요한 경우에만 클러스터를 시작할 수 있습니다.
데이터에 액세스하는 방법: 작업 검색 직접 KQL 쿼리 KQL externaldata 연산자 수정된 KQL 쿼리
시나리오: 간헐적 액세스

과도한 분석을 실행하거나 분석 규칙을 트리거할 필요가 없고 가끔만 데이터에 액세스해야 하는 시나리오와 관련이 있습니다.		 잦은 액세스

데이터에 자주 액세스해야 하며 클러스터 크기 조정 및 구성 방법을 제어해야 하는 시나리오와 관련이 있습니다.		 규정 준수/감사

• 대량의 비정형 데이터를 저장하는 데 최적입니다.
• 규정 준수 또는 감사 목적과 같이 데이터에 대한 빠른 액세스 또는 고성능이 필요하지 않은 시나리오와 관련이 있습니다.		 간헐적 액세스

저렴한 Azure Blob Storage를 활용하려고 하며 데이터에 비교적 빠르게 액세스하려는 시나리오와 관련이 있습니다.
복잡성: 매우 낮음 중간 낮음 높음
준비 상태 GA GA GA GA

일반적인 고려 사항

지금까지 사용 가능한 대상 플랫폼에 대해 자세히 알아보았으므로 이러한 주요 요소를 검토하여 결정을 마무리합니다.

수집된 로그 사용

조직에서 수집된 로그를 사용하여 수집 플랫폼 선택을 안내하는 방법을 정의합니다.

다음 세 가지 일반적인 시나리오를 고려합니다.

  • 조직은 규정 준수 또는 감사 목적으로만 로그를 유지해야 합니다. 이 경우 조직에서는 데이터에 거의 액세스하지 않습니다. 조직에서 데이터에 액세스하더라도 고성능 또는 사용 편의성은 우선 순위가 아닙니다.
  • 조직에서는 팀이 로그에 쉽고 빠르게 액세스할 수 있도록 로그를 유지해야 합니다.
  • 조직에서는 팀이 때때로 로그에 액세스할 수 있도록 로그를 유지해야 합니다. 성능 및 사용 편의성은 2순위입니다.

이러한 각 시나리오에 적합한 플랫폼을 이해하려면 플랫폼 비교를 참조하세요.

마이그레이션 속도

일부 시나리오에서는 엄격한 최종 기한을 충족해야 할 수 있습니다. 예를 들어 조직은 라이선스 만료 이벤트로 인해 이전 SIEM에서 긴급하게 전환해야 할 수 있습니다.

마이그레이션 속도를 결정하는 구성 요소 및 요소를 검토합니다.

데이터 원본

데이터 원본은 일반적으로 로컬 파일 시스템 또는 클라우드 스토리지(예: S3)입니다. 서버의 스토리지 성능은 디스크 기술(SSD 및 HDD), IO 요청의 특성 및 각 요청의 크기와 같은 여러 요인에 따라 달라집니다.

예를 들어 Azure 가상 머신 성능 범위는 더 작은 VM SKU의 초당 30MB에서 NVMe(NVMe) 디스크를 사용하는 스토리지 최적화 SKU의 초당 20GB까지입니다. 높은 스토리지 성능을 위해 Azure VM을 디자인하는 방법을 알아봅니다. 대부분의 개념을 온-프레미스 서버에도 적용할 수 있습니다.

컴퓨팅 기능

경우에 따라 디스크에서 데이터를 신속하게 복사할 수 있더라도 컴퓨팅 성능은 복사 프로세스의 병목 상태입니다. 이러한 경우 다음 스케일링 옵션 중 하나를 선택할 수 있습니다.

  • 세로로 스케일링. CPU를 더 추가하여 단일 서버의 성능을 높이거나 CPU 속도를 높입니다.
  • 가로로 스케일링. 서버를 더 추가하면 복사 프로세스의 병렬 처리가 증가합니다.

대상 플랫폼

이 섹션에서 설명하는 대상 플랫폼마다 성능 프로필이 다릅니다.

  • Azure Monitor 기본 로그. 기본적으로 기본 로그는 분당 약 1GB의 속도로 Azure Monitor로 푸시할 수 있습니다. 이 속도를 사용하면 하루에 약 1.5TB 또는 매월 43TB를 수집할 수 있습니다.
  • Azure Data Explorer. 수집 성능은 프로비저닝하는 클러스터의 크기와 적용하는 일괄 처리 설정에 따라 달라집니다. 성능 및 모니터링을 비롯한 수집 모범 사례에 대해 알아봅니다.
  • Azure Blob Storage. Azure Blob Storage 계정의 성능은 파일의 수와 크기, 작업 크기, 동시성 등에 따라 크게 달라질 수 있습니다. Microsoft Azure Storage로 AzCopy 성능을 최적화하는 방법을 알아봅니다.

데이터 양

데이터 양은 마이그레이션 프로세스 기간에 영향을 주는 주요 요소입니다. 따라서 데이터 집합에 따라 환경을 설정하는 방법을 고려해야 합니다.

마이그레이션의 최소 기간과 병목 상태가 발생할 수 있는 위치를 확인하려면 데이터 양과 대상 플랫폼의 수집 속도를 고려합니다. 예를 들어 초당 1GB를 수집할 수 있는 대상 플랫폼을 선택하고 100TB를 마이그레이션해야 합니다. 이 경우 마이그레이션에는 최소 100,000GB에 초당 1GB 속도를 곱한 시간이 소요됩니다. 결과를 3600으로 나누면 27시간이 됩니다. 이 계산은 로컬 디스크, 네트워크 및 가상 머신과 같은 파이프라인의 나머지 구성 요소가 초당 1GB 속도로 작동할 수 있는 경우 적절합니다.

다음 단계

이 문서에서는 QRadar에서 Microsoft Sentinel로 마이그레이션 규칙을 매핑하는 방법을 알아보았습니다.

데이터 수집 도구 선택