엔지니어링

Elastic 머신 러닝의 임시 분석과 모집단 분석의 비교

By
Rich Collier

Elastic 머신 러닝을 사용하면 사용자는 두 가지 유형의 주요 오류를 발견할 수 있는데, 하나는 본질적으로 임시적인(시간 관련) 오류이며 다른 하나는 모집단 기반(다른 모든 것과 관련) 오류입니다. 하지만, 이 두 가지 유형의 차이는 무엇이며, 어떤 환경에서 어떤 유형을 더 많이 사용하게 될까요? 이 블로그에서는 보편적인 경험 법칙을 바탕으로 분석 이면의 자세한 정보, 장점, 모범 사례를 다룹니다.

먼저, 임시 오류와 모집단 기반의 오류가 무엇인지 정의해 보겠습니다. 이를 위해 몇 가지 사실을 검토해 보겠습니다.

임시 이상 징후 탐색

Elastic 머신 러닝의 기본 동작입니다. 단, 분석을 모집단 기반으로 구체적으로 정의한 경우는 예외입니다.

  • 엔터티 자체를 기준으로 시간의 흐름에 따라 엔터티 동작을 비교한 것입니다.
  • “분할”(by_field_name 또는 partition_field_name을 통해)을 활용하여 각각의 인스턴스(즉, 호스트 또는 사용자별 고유 베이스라인)에 대해 개별 베이스라인을 생성할 수 있습니다. 카디널리티가 높거나 매우 희소한 데이터 요소에는 별로 적합하지 않습니다. (예를 들어, 웹사이트 방문자의 외부 IP 주소는 희소하면서 동시에 수십만 개가 넘는 높은 카디널리티를 갖습니다.) 작업의 메모리 제한이 기본 제한보다 증가하지 않는 경우 이로 인해 성능 문제가 발생할 수 있습니다. 하지만 그러한 상황이 발생한 경우에도 모집단 분석이 보다 적합한 접근법일 가능성이 높습니다.

모집단 이상 징후 탐색

  • over_field_name이 사용될 때 또는 Kibana의 모집단 작업 마법사가 사용될 때에만 호출됩니다. over_field_name으로 선언된 필드는 모집단을 정의합니다.
  • 모집단 내 구성원의 피어 분석, 더 정확히 말하자면, 개별 엔터티와 시간에 따라 목격되는 모든 피어의 집합적 모델의 비교입니다.
  • 또한 “분할”을 활용하여(by_field_name 또는 partition_field_name을 통해) 하위 모집단을 생성합니다.
  • 개별 구성원이 동작의 집합적 모델에 기여하기 때문에 일반적으로 높은 카디널리티 또는 희소 데이터 요소에도 상당히 적합합니다.

사용 사례 예시

지금까지 어떤 방식으로 진행되었는지 파악했으므로, 이제 어떤 접근법을 선택해야 할지 결정할 수 있도록 도와주는 가상의 사용 사례에 대해 살펴보겠습니다.

내부 문서 서버에서 다운로드한 문서 수를 추적하려 한다고 가정해 보겠습니다. 그리고 문서 서버에는 회사(임직원 50,000명 이상의 대규모 기업) 내 모든 사람에게 광범위하게 적용되는 문서가 있다고 가정해 보겠습니다. 또한, 누구나 언제든 이 문서 서버에 액세스할 수 있습니다. 마지막으로, 문서 액세스가 이뤄지고 사용자가 다운로드할 때마다 문서 서버의 액세스 로그가 이를 추적한다고 가정해 봅시다.

임시 이상 징후 예시

내가 임시 이상 징후 탐색을 선택하고 다음과 같은 구조로 분석을 설계하는 경우:

    "detectors": [
      {
        "function": "count",
        "partition_field_name": "user"
      }
    ]

그런 다음, 다운로드의 용량을 각 사용자별, 이름별, 시간별로 개별적으로 추적할 것을 예상합니다. 그러므로, 사용자=”Wilma”가 일반적으로 매일 약 50개의 문서를 다운로드하는 경우(엔지니어링 부서에서 일하며 서버의 문서를 많이 사용함), Wilma가 갑자기 동작에 변화를 보이고 평소에 다운로드하는 것보다 훨씬 적거나 많게 다운로드한다면(예를 들어, 1일 5,000개 문서) 매우 이례적이라 할 수 있습니다.

또한, 이전에 언급된 고려 사항처럼 머신 러닝에서 추적할 것으로 예상되는 개별 사용자 수를 파악하고 있어야 합니다. 50,000명의 고유 사용자의 경우, 우리가 머신 러닝 작업에 대한 메모리 제한을 증가시킨다면 관리가 가능할 것입니다. 하지만 사용자가 매일 문서를 일관된 수준으로 다운로드하지 않을 수도 있음을 명심해야 합니다. 따라서 사용자의 활동은 매우 희소할 수도 있습니다. 이들은 오늘 어느 정도 다운로드한 후에 지금부터 몇 달 동안 다시 다운로드하지 않을 수도 있습니다. 사용자별로 일관성 있는 관찰 결과가 없다면 사용자별로 정확한 베이스라인을 설정하기는 어렵습니다.

하지만 가장 중요한 것은, 새로운 사람(사용자=“Fred”)이 와서 하루에 5,000개의 문서를 다운로드하고 그 이후에는 다운로드하지 않는다면 어떻습니까? 비정상적인 일인가요? Fred는 내부자 위협입니까? 아니면 어떤 데이터 유출 맬웨어가 Fred의 로그인 정보를 이용해서 여러 문서를 훔쳐 회사 외부로 전송하려고 한 것입니까? 임시 이상 징후 탐색을 통해 분석한 경우, 답은 확실하지 않습니다. 우리는 Fred에게 이것이 비정상적인 일인지 제대로 알 수 없습니다. 그와 관련하여 비교할 만한 대상이 될 자료가 없기 때문입니다(표본이 하나에 불과함).

모집단 이상 징후 예시

또는, 다음과 같은 모집단 이상 징후 탐색을 활용해 문제를 해결한다면:

    "detectors": [
      {
        "function": "count",
        "over_field_name": "user"
      }
    ]

다음과 같은 일을 이룰 수 있습니다.

  • 총체적으로, 사용자가 사용자에 대한 일반적인 다운로드 수의 집합적 모델을 구축하기 위해 각 bucket_span(이 사례의 경우 하루) 이내에 제공하는 것은 무엇이든 사용할 수 있습니다.
  • 각 일자에 나타난 각 사용자를 집합적 모델과 비교합니다.

현재, Wilma와 그녀가 속한 집단의 대부분은 하루에 10~75개의 문서를 다운로드하며 일반적인 사용의 전체 “집합적” 모델은 해당 범위에 포함됩니다. 어느 날, Fred가 방문하여 5,000개의 문서를 다운로드하는 경우, Fred가 Wilma와 그녀가 속한 집단 전체와 비교되기 때문에 이상 행동에 해당할 것입니다. Fred는 이상값으로 강조되어 나타날 것입니다.

하지만 주요점이 있습니다. Wilma가 Fred 대신 5,000개의 문서를 다운로드하는 경우에도, Wilma는 변칙적인 이상값으로 지정될 것입니다. 평소에 다운로드하는 것보다 많이 다운로드해서라기보다는, 시간이 흐르면서 그녀와 그녀가 속한 집단이 수립해 온 “일반적” 사용 모델에 비해 더 많이 다운로드했기 때문입니다.

요점은, 이 상황에서 Wilma는 임시 또는 모집단 탐색 선택 여부에 관계없이 이상값으로 강조되어 나타날 것이지만, 이 사례의 경우 모집단 접근이 보다 유연한 방식입니다. 왜냐하면:

  1. 희소 데이터에 덜 영향받기 때문입니다.
  2. 여러 사용자가 많이 사용할 때 더 효율적이고, 메모리 지향적이기 때문입니다(사용자별 개별 모델이 필요하지 않기 때문).
  3. 이력이 적거나 존재하지 않는 Fred 같은 이상값을 찾아내기 때문입니다.
  4. Wilma의 행동이 집합적 동작에 벗어나는 수준까지 크게 변화하는 경우 이상값으로 간주합니다.

추가 정보: 모집단 분석을 수행하는 경우, 모집단을 가능한 동종으로 구축하는 것이 좋습니다. 달리 말하면 사용자 유형(엔지니어 대 인사과 직원)별로 주요 클러스터가 있는 경우, 사용자를 여러 별도 집단으로 분할하고 두 가지 개별적인 분석을 실시하는 것이, 두 분석이 합쳐질 것을 예상하는 것보다 효과적일 것입니다.

마지막으로 유의할 점은, 사전에 배제하기로 한 모집단의 구성원이 있는 경우 입력 데이터 필터링 또는 결과를 필터링하는 규칙을 사용하여 필터링하는 것을 고려해볼 수 있습니다.

두 가지 접근법을 비교하는 데 이 설명이 도움이 되었기를 바랍니다. 데이터에 머신 러닝을 적용하려는 경우 Elastic Stack을 다운로드하고 30일 시험판 라이선스를 실행하거나 Elastic Cloud 무료 시험판을 시작해 보세요.