Azure Monitor 로그(Log Analytics) 작업 영역 디자인
Azure Monitor는 로그 데이터를 Azure Monitor 로그(Log Analytics) 작업 영역에 저장합니다. 작업 영역은 데이터 스토리지의 관리 경계 또는 지리적 위치 역할을 하는 Azure 리소스입니다. 작업 영역은 데이터를 수집하고 집계하는 컨테이너이기도 합니다.
Azure 구독에서 하나 이상의 작업 영역을 배포할 수 있지만 초기 배포가 Microsoft 지침을 따르도록 하기 위해 이해해야 하는 몇 가지 고려 사항이 있습니다. 작업 영역은 조직의 요구 사항을 충족하는 비용 효율적이고 관리 가능하며 스케일링 가능한 배포를 제공해야 합니다.
Azure Monitor 로그 작업 영역에 대해 알아야 할 사항
Azure Monitor 로그 작업 영역의 다음 특성을 검토하고 Tailwind Traders에 대한 모니터링 솔루션에 기여할 수 있는 방법을 고려합니다.
작업 영역에서는 Microsoft 권장 디자인 전략에 따라 서로 다른 사용자에게 액세스 권한을 부여하여 데이터를 격리할 수 있습니다.
Azure Monitor 로그 작업 영역의 데이터는 테이블로 구성됩니다. 각 테이블은 다른 종류의 데이터를 저장하며 데이터를 생성하는 리소스에 따라 고유한 속성 집합을 가집니다. 대부분의 데이터 원본은 Azure Monitor 로그 작업 영역의 자체 테이블에 씁니다.
작업 영역을 사용하면 관리 경계 또는 지리적 위치에 따라 가격 책정 계층, 보존 및 데이터 제한과 같은 설정을 구성할 수 있습니다.
Azure RBAC(Azure 역할 기반 액세스 제어)를 사용하면 작업 영역의 모니터링 데이터 작업에 필요한 액세스 권한만 사용자와 그룹에 부여할 수 있습니다. 단일 작업 영역을 사용하여 모든 리소스에서 사용하도록 설정된 수집된 데이터를 저장하는 IT 조직 운영 모델에 맞출 수 있습니다.
작업 영역은 물리적 클러스터에서 호스팅됩니다. 기본적으로 시스템은 이러한 클러스터를 만들고 관리합니다. 시스템에서 하루에 500GB 이상의 데이터를 수집하는 경우 작업 영역에 대해 더 높은 제어 및 더 빠른 수집 속도를 지원하는 고유한 전용 클러스터를 만들 수 있습니다.
Azure Monitor 로그 작업 영역을 사용할 때 고려해야 할 사항
이제 Tailwind Traders 아키텍처에서 Azure Monitor 로그 작업 영역을 사용하여 디자인하기 위한 고려 사항을 검토할 준비가 되었습니다.
액세스 제어 전략을 고려합니다. Tailwind Traders 조직에서 사용할 작업 영역 수를 계획할 때 다음과 같은 잠재적 요구 사항을 고려합니다.
- 조직이 글로벌 회사인가요? 데이터 주권 또는 규정 준수 상의 이유로 특정 지역에 저장된 로그 데이터가 필요한가요?
- 아키텍처에서 Azure를 사용하나요? 작업 영역을 자신이 관리하는 Azure 리소스와 같은 지역에 두어서 아웃바운드 데이터 전송 요금을 피하고 싶은가요?
- 시스템에서 여러 부서 또는 비즈니스 그룹을 지원하나요? 각 그룹은 자체 데이터에만 액세스하고 다른 그룹의 데이터에는 액세스하지 않아야 합니다. 또한 통합된 부서 간 보기 또는 비즈니스 그룹 보기에 대한 비즈니스 요구 사항은 없습니다.
배포 모델 옵션을 고려합니다. 대부분의 IT 조직은 아키텍처에 중앙 집중식, 분산형 또는 하이브리드 모델을 사용합니다. 이러한 일반적인 작업 영역 배포 모델과 이러한 모델이 Tailwind Traders 조직에서 어떻게 작동할지를 고려합니다.
배포 설명 중앙 집중형 모든 로그는 중앙 작업 영역에 저장되고 단일 팀에서 관리합니다. Azure Monitor는 팀당 차별화된 액세스를 제공합니다. 이 시나리오에서는 로그를 관리하고, 리소스 간에 검색하고, 상호 연결하는 것이 쉽습니다. 작업 영역은 구독의 여러 리소스에서 수집된 데이터의 양에 따라 크게 증가할 수 있습니다. 다른 사용자에 대한 액세스 제어를 유지하기 위한 추가 관리 오버헤드가 필요합니다. 이 모델을 허브 및 스포크라고 합니다. 탈중앙화 각 팀에는 소유하고 관리하는 리소스 그룹에 자체 작업 영역이 만들어집니다. 로그 데이터는 리소스별로 분리됩니다. 이 시나리오에서는 작업 영역을 안전하게 유지할 수 있으며, 액세스 제어는 리소스 액세스와 일치합니다. 이 모듈의 단점은 로그를 상호 연결하기 어려울 수 있다는 것입니다. 많은 리소스에 대한 광범위한 보기가 필요한 사용자는 의미 있는 방식으로 데이터를 분석할 수 없습니다. 하이브리드 하이브리드 접근 방식은 보안 감사 규정 준수 요구 사항으로 인해 복잡할 수 있습니다. 많은 조직에서 두 배포 모델을 동시에 구현합니다. 하이브리드 디자인은 일반적으로 로그 범위에 차이가 있는 복잡하고, 비용이 많이 들며, 유지 관리하기가 어려운 구성으로 이어집니다. 액세스 모드를 고려합니다. 사용자가 Azure Monitor 로그 작업 영역에 액세스하는 방법을 계획하고 액세스할 수 있는 데이터 범위를 정의합니다. Tailwind Traders 사용자에게는 데이터에 액세스하기 위한 두 가지 옵션이 있습니다.
액세스 모드 Description 작업 영역-컨텍스트 사용자는 권한이 있는 작업 영역의 모든 로그를 검토할 수 있습니다. 쿼리 범위는 작업 영역의 모든 테이블에 있는 모든 데이터로 지정됩니다. Azure Portal의 Azure Monitor 메뉴에서 로그를 선택하여 작업 영역을 범위로 사용하여 로그에 액세스합니다. 리소스-컨텍스트 사용자는 특정 리소스, 리소스 그룹 또는 구독에 대한 작업 영역에 액세스합니다. Azure Portal의 리소스 메뉴에서 로그를 선택하면 액세스 권한이 있는 모든 테이블의 리소스에 대한 로그만 볼 수 있습니다. 쿼리 범위는 해당 리소스와 연결된 데이터로만 지정됩니다. 또한 이 모드는 세분화된 Azure RBAC를 사용하도록 설정합니다. Azure RBAC 및 작업 영역을 고려합니다. 작업 영역 연결에 따라 어떤 사용자가 어떤 리소스에 액세스할 수 있는지를 제어합니다. Azure Virtual Machines에서 호스트되는 Tailwind Traders 인프라 서비스를 담당하는 팀에 액세스 권한을 부여할 수 있습니다. 이 팀에 가상 머신에서 생성된 로그에 대해서만 액세스 권한을 부여할 수 있습니다. 이 접근법은 새로운 리소스 컨텍스트 로그 모델을 따릅니다. 이 모델의 기준은 Azure 리소스에서 내보내는 모든 로그 레코드에 대한 것이며, 이 리소스에 자동으로 연결됩니다. 로그는 리소스에 따라 범위 지정 및 Azure RBAC를 따르는 중앙 작업 영역으로 전달됩니다.
스케일링 및 수집 볼륨 속도 제한을 고려합니다. Azure Monitor는 점점 더 빠른 속도로 매월 페타바이트 단위의 데이터를 보내는 수천 명의 고객에게 서비스를 제공하는 대규모 데이터 서비스입니다. 작업 영역은 스토리지 공간에 제한되지 않으며 페타바이트 단위의 데이터까지 확장할 수 있습니다. 스케일링으로 인해 작업 영역을 분할할 필요가 없습니다.
권장 사항
모니터링 및 로깅 솔루션에서 Azure Monitor 로그 작업 영역 및 액세스 제어를 구현하기 위한 옵션을 고려할 때 이러한 권장 사항을 검토하세요. 이 시나리오에서는 IT 조직의 구독에 있는 단일 작업 영역에 권장되는 디자인을 보여 줍니다.
작업 영역은 데이터 주권 또는 규정 준수에 의해 제한되지 않습니다. 리소스가 배포된 지역에 매핑할 필요가 없습니다. 조직의 보안 및 IT 관리 팀은 Azure 액세스 관리와의 향상된 통합 및 더 안전한 액세스 제어를 활용할 수 있습니다.
Application Insights 및 가상 머신 인사이트와 같은 모든 리소스, 모니터링 솔루션 및 인사이트는 수집된 로그 데이터를 IT 조직의 중앙 집중식 공유 작업 영역으로 전달하도록 구성됩니다. 서로 다른 팀에서 유지 관리하는 지원 인프라 및 앱의 로그 데이터도 중앙 집중식 공유 작업 영역으로 전송됩니다.
각 팀의 사용자에게는 액세스 권한이 부여된 리소스의 로그에 대한 액세스 권한이 부여됩니다.
작업 영역 아키텍처를 배포한 후 Azure Policy를 사용하여 Azure 리소스에 동일한 모델을 적용할 수 있습니다. 정책을 정의하고 Azure 리소스에 대한 준수를 보장할 수 있으므로 모든 리소스 로그를 특정 작업 영역으로 보냅니다. Azure 가상 머신 또는 가상 머신 확장 집합을 사용하면 작업 영역 준수를 평가하고 결과를 보고하거나, 준수하지 않는 경우에는 수정하도록 사용자 지정하는 기존 정책을 사용할 수 있습니다.