Amazon CloudWatch Contributor Insights로 간소화된 시계열 데이터 분석하기

Amazon CloudWatch Contributor Insights로 간소화된 시계열 데이터 분석하기

여러 로그 데이터와 로그 스트림을 조사해야 하는 경우, 실시간으로 분석하고 진단하는 작업은 어렵고 시간이 많이 듭니다.  최근 정식 출시된 Amazon CloudWatch Contributor Insights는 CloudWatch Logs의 시계열 데이터를 가장 많이 차지하는 상위 N개 항목을 간편하게 분석할 수 있도록 하는 새로운 기능으로, 시스템 및 애플리케이션 성능에 영향을 미치는 사용자나 항목을 대규모로, 실시간으로 파악하는 데 유용합니다.

따라서 운영 문제가 발생했을 때 운영 문제를 유발하는 주된 원인과 영향을 가장 많이 미치는 사용자 또는 항목을 보다 효과적으로 파악할 수 있으므로 시간이 절약됩니다. 또한 Amazon CloudWatch Contributor Insights를 통해 특이값, 성능 병목 현상, 우수 고객 또는 가장 많이 사용된 리소스와 같은 정보를 한눈에 쉽게 파악할 수 있으므로 시스템 및 비즈니스 최적화 상태를 지속적으로 분석하는 데에도 도움이 됩니다. Amazon CloudWatch Contributor Insights는 Logs 외에 Metrics와 Alarms를 비롯한 CloudWatch 포트폴리오의 다른 제품에도 사용할 수 있습니다.

Amazon CloudWatch Contributor Insights는 JSON 또는 CLF(Common Log Format) 형식의 구조화된 로그를 분석할 수 있습니다. 로그 데이터는 Amazon Elastic Compute Cloud(EC2) 인스턴스, AWS CloudTrail, Amazon Route 53, Apache Access and Error Logs, Amazon Virtual Private Cloud(VPC) Flow Logs, AWS Lambda Logs, Amazon API Gateway Logs에서 수집할 수 있습니다. 또한 CloudWatch에 직접 게시된 구조화된 로그를 사용하거나 CloudWatch 에이전트를 사용할 수 있습니다. Amazon CloudWatch Contributor Insights는 이러한 로그 이벤트를 실시간으로 평가하여 데이터 세트에서 가장 큰 비율을 차지하는 항목과 고유 항목의 수를 보여 주는 보고서를 표시합니다.

이러한 항목은 CloudWatch Logs에 로그 필드로 포함되어 있는 차원을 기준으로 한 집계 지표입니다. Amazon Virtual Private Cloud Flow Logs의 account-id 또는 interface-id나 다른 사용자 지정 차원 세트를 예로 들 수 있습니다. 사용자가 설정한 맞춤형 기준에 따라 항목 데이터를 정렬하고 필터링할 수 있습니다. Amazon CloudWatch Contributor Insights에서 수집된 보고서 데이터를 CloudWatch 대시보드에 표시하고 CloudWatch 지표와 함께 그래프로 작성하고 CloudWatch 경보에 추가할 수 있습니다. 예를 들어 고객은 2개의 Amazon CloudWatch Contributor Insights 보고서에 있는 값을 오류로 인해 영향을 받은 고객의 비율을 보여 주는 단일 지표의 그래프로 작성하고 이 비율이 사전 정의된 임계값을 벗어날 경우 경고하는 경보를 구성할 수 있습니다.

Amazon CloudWatch Contributor Insights 시작하기
Amazon CloudWatch Contributor Insights를 사용하려면 규칙을 하나 이상 정의하기만 하면 됩니다. 규칙은 CloudWatch Logs에서 보고된 지표에 대해 추출할 컨텍스트 데이터를 정의하는 데이터 조각입니다. 특정 지표에 가장 많이 기여하는 항목을 식별하는 규칙을 구성하려면 세 가지 데이터 항목을 제공하면 됩니다. 즉, 하나 이상의 로그 그룹, 가장 많이 기여하는 항목을 평가하는 대상 차원, 가장 많이 기여하는 항목의 범위를 좁히는 필터를 제공해야 합니다. 이를 위해 Amazon CloudWatch 콘솔 대시보드로 이동하여 왼쪽 탐색 링크에서 [Contributor Insights]를 선택합니다. 그러면 Amazon CloudWatch Contributor Insights 홈으로 이동합니다. 여기에서 [시작하려면 규칙 생성]을 클릭합니다.

CloudWatch Logs로 로그를 전송하는 다양한 서비스의 샘플 규칙 라이브러리에서 규칙을 선택하면 간편하게 시작할 수 있습니다. 위의 이미지를 보면 현재 Amazon API Gateway, Amazon Route 53 Query Logs, Amazon Virtual Private Cloud Flow Logs, 컨테이너 서비스의 로그용으로 다양한 샘플 규칙이 제공되는 것을 알 수 있습니다. 또는 이 게시물의 나머지 부분에서 하는 것처럼 규칙을 직접 정의할 수도 있습니다.

구조화된 로그 데이터를 JSON 형식으로 CloudWatch Logs에 직접 게시하는 애플리케이션을 배포했다고 가정해 보겠습니다. 이 애플리케이션에는 2개의 API 버전이 있으며, 하나는 일정 기간 이상 사용되어 안정된 것으로 간주되고 다른 하나는 이제 막 고객에게 롤아웃되기 시작했습니다. 새 API를 대상으로 한 새 버전을 받은 고객 중에 오류가 발생한 고객이 있는지, 얼마나 많은 오류가 트리거되었는지 최대한 빠른 시점에 알고 싶습니다. 안정적인 API 버전은 특정 로그 그룹에 로그 데이터를 전송하고 새 API 버전은 다른 그룹을 사용합니다. 따라서 여러 로그 그룹을 모니터링해야 합니다. 이는 버전에 관계없이 오류가 발생하는 고객이 있는지도 파악하려는 의도입니다.

규칙을 정의하고, API에서 발생하는 500개의 오류를 보고하며, 계정 ID, HTTP 메서드 및 리소스 경로를 차원으로 사용하는 이 JSON이 아래에 나와 있습니다.

{
  "Schema": {
    "Name": "CloudWatchLogRule",
    "Version": 1
  },
  "AggregateOn": "Count",
  "Contribution": {
    "Filters": [
      {
        "Match": "$.status",
        "EqualTo": 500
      }
    ],
    "Keys": [
      "$.accountId",
      "$.httpMethod",
      "$.resourcePath"
    ]
  },
  "LogFormat": "JSON",
  "LogGroupNames": [
    "MyApplicationLogsV*"
  ]
}

[마법사] 탭을 사용하거나 위의 JSON을 [구문] 탭의 [규칙 본문] 필드에 붙여 넣어 규칙을 설정할 수 있습니다. 위의 JSON이 있지만, [마법사] 탭을 사용하는 방법도 이 게시물에서 보여 드리겠습니다. 작성된 필드는 아래에 나와 있습니다. 로그 그룹을 선택할 때는 드롭다운에서 선택하거나(로그 그룹이 이미 있는 경우), [일치하는 접두사로 선택] 옵션에 와일드카드 구문을 사용(예: MyApplicationLogsV*)하여 선택할 수 있습니다.

[생성]을 클릭하면 새 규칙이 저장되고 즉시 새 규칙에 따라 데이터가 처리 및 분석됩니다(비활성 상태로 생성하도록 선택하지 않은 경우). Amazon CloudWatch Contributor Insights는 규칙이 활성화된 후부터 생성되는 새 로그 데이터를 처리합니다. 기록 검사는 실행하지 않으므로 미래에 발생할 것으로 예상되는 운영 시나리오에 대한 규칙을 만들어야 합니다.

규칙이 준비되었으므로 이제 로그 데이터를 생성할 차례입니다. 로그 데이터를 생성하기 위해 AWS Tools for PowerShell을 사용하여 작성한 스크립트로 몇몇 고객이 배포된 애플리케이션을 호출하는 상황을 시뮬레이트합니다. 해당 고객 중 소수를 선택해(소위 운이 없는 고객) HTTP POST 요청 시 무작위로 실패하는 새로운 API 버전으로 리디렉션합니다. 이전 API 버전을 사용하는 고객은 항상 성공합니다. 아래에는 5,000회 반복 실행되는 이 스크립트가 나와 있습니다. CloudWatch Logs에 사용되는 cmdlet은 이름에 CWL이 포함된 cmdlet입니다(예: Write-CWLLogEvent).

# 임의의 고객 ID를 설정하고 그중 1/3을 운이 없는 고객, 즉
# 잘못된 API 업데이트가 배포되어 임의의 오류를 경험하게 될 ID로 선택
$allCustomerIds = @( 1..15 | % { Get-Random })
$faultingIds = $allCustomerIds | Get-Random -Count 5

# 로그 그룹 설정
$group1 = 'MyApplicationLogsV1'
$group2 = 'MyApplicationLogsV2'
$stream = "MyApplicationLogStream"

# 로그 스트림에 쓸 때 시퀀싱 토큰을 지정해야 함
$group1Sequence = $null
$group2Sequence = $null

$group1, $group2 | % {
    if (!(Get-CWLLogGroup -LogGroupName $_)) {
        New-CWLLogGroup -LogGroupName $_
        New-CWLLogStream -LogGroupName $_ -LogStreamName $stream
    } else {
        # 로그 그룹 및 스트림이 있는 경우 시퀀스 토큰을 다음 예상 값으로
        # 시드해야 함
        $logstream = Get-CWLLogStream -LogGroupName $_ -LogStreamName $stream
        $token = $logstream.UploadSequenceToken
        if ($_ -eq $group1) {
            $group1Sequence = $token
        } else {
            $group2Sequence = $token
        }
    }
}

# 일부 고객에게 임의의 오류가 발생한 로그 데이터를 생성하여
1..5000 | % {

    Write-Host "Log event iteration $_" # 진행 상태를 확인할 수 있도록 함

    $customerId = Get-Random $allCustomerIds

    # 먼저 v1이라는 사용자 또는 v2 api 중 무엇으로 할지 선택
    $useV2Api = ((Get-Random) % 2 -eq 1)
    if ($useV2Api) {
        $resourcePath = '/api/v2/some/resource/path/'
        $targetLogGroup = $group2
        $nextToken = $group2Sequence
    } else {
        $resourcePath = '/api/v1/some/resource/path/'
        $targetLogGroup = $group1
        $nextToken = $group1Sequence
    }

    # 이제 오류 발생 여부 선택. 모든 API 경로에 있는 모든 고객에 대해
    # GET 요청 성공. 일부 고객의 경우 v2 API에 대한 POST 요청이
    # 실패함
    $status = 200
    $errorMessage = ''
    if ((Get-Random) % 2 -eq 0) {
        $httpMethod = "GET"
    } else {
        $httpMethod = "POST"
        if ($useV2Api -And $faultingIds.Contains($customerId)) {
            $status = 500
            $errorMessage = 'Uh-oh, something went wrong...'
        }
    }

    # 이벤트를 작성하고 다음 이벤트의 시퀀스 토큰 수집
    $nextToken = Write-CWLLogEvent -LogGroupName $targetLogGroup -LogStreamName $stream -SequenceToken $nextToken -LogEvent @{
        TimeStamp = [DateTime]::UtcNow
        Message = (ConvertTo-Json -Compress -InputObject @{
            requestId = [Guid]::NewGuid().ToString("D")
            httpMethod = $httpMethod
            resourcePath = $resourcePath
            status = $status
            protocol = "HTTP/1.1"
            accountId = $customerId
            errorMessage = $errorMessage
        })
    }

    if ($targetLogGroup -eq $group1) {
        $group1Sequence = $nextToken
    } else {
        $group2Sequence = $nextToken
    }

    Start-Sleep -Seconds 0.25
}

규칙이 활성화된 상태로 스크립트 실행을 시작하면 그래프에 실패가 표시되기 시작합니다. 아래는 스크립트를 실행한 지 몇 분 지난 후의 스냅샷입니다. 시뮬레이트된 고객 중 일부에게서 새로운 v2 API에 대한 HTTP POST 요청 문제가 발생하는 것을 확인할 수 있습니다.

이제 [규칙] 패널의 [작업] 풀다운에서 이 보고서를 바탕으로 오류의 영향을 받은 고객의 비율을 보여 주는 단일 지표를 생성할 수 있습니다. 그런 다음 이 비율이 사전 정의된 임계값을 벗어날 경우 경고하는 경보를 구성할 수 있습니다.

여기서 설명하는 샘플 시나리오에서는 이 경보를 이용하여 해당 경보가 발생할 경우 새 API의 롤아웃을 중지하여 다른 고객에게 피해가 확산되지 않도록 방지하면서 오류가 증가한 원인에 대한 조사를 수행할 수 있습니다. 지표와 경보를 설정하는 방법은 사용 설명서에서 참조할 수 있습니다.

이제 중국과 GovCloud를 비롯한 모든 상용 AWS 리전에서 Amazon CloudWatch Contributor Insights를 사용할 수 있습니다.

— Steve

Source: Amazon CloudWatch Contributor Insights로 간소화된 시계열 데이터 분석하기