봇 감지를 위한 머신 러닝 모델 모니터링

전 세계에 걸쳐 많은 조직에서 자동화된 봇 트래픽을 선제적으로 감지하고 완화하기 위해 Cloudflare의 봇 관리를 사용합니다. 이를 위해 Cloudflare에서는 특정 HTTP 요청이 봇으로부터 오는지 여부를 예측하는 데 도움이 되는 머신 러닝 모델을 활용하고, 나아가 양성 봇과 악성 봇을 구분합니다. Cloudflare에서는 초당 5,500만 건 이상의 HTTP 요청을 처리하므로 저희 머신 러닝 모델은 Cloudflare의 규모에서 실행되어야 합니다.

저희는 봇 관리를 지원하는 모델을 지속적으로 개선하여 최신 위협 인텔리전스를 통합할 수 있도록 하고 있습니다. 이러한 반복 프로세스는 고객이 악의적인 공격자보다 한 발 앞서 나가기 위해 중요한 부분이며, 그러려면 실험, 배포, 지속적인 관찰을 위한 엄격한 프로세스가 필요합니다.

저희는 최근에 Cloudflare의 모델 교육 및 배포 프로세스에 대한 전체적인 개요를 제공하는Cloudflare의 MLOps 접근 방식에에 대한 소개를 공유했습니다. 이번 게시물에서는 모니터링과 봇 관리를 지원하는 모델을 지속적으로 평가하는 방법에 대해 자세히 알아보겠습니다.

봇 감지 모델을 출시하기 전에 Cloudflare에서는 광범위한 모델 테스트/검증 프로세스를 거쳐 감지 기능이 예상대로 작동하는지 확인합니다. 브라우저, HTTP 프로토콜, 기타 차원별로 다양한 웹 트래픽 세그먼트에서 모델 성능을 검증하여 모델이 배포된 후 예상되는 성능을 세밀하게 파악할 수 있습니다. 모든 것이 확인되면 모델을 점차적으로 프로덕션에 출시하고 봇 감지 수준을 높입니다.

모델이 프로덕션에 배포된 후에는 세부적인 수준에서 성과를 파악하기가 어려울 수 있습니다. 물론 봇 점수 분포, 챌린지 해결률 등의 결과 기반 메트릭을 살펴 볼 수는 있습니다. 이러한 정보는 유익하지만, 봇 점수나 챌린지 해결률에 변화가 생기면 "웹 트래픽의 어떤 세그먼트가 이 변화의 영향을 가장 많이 받는가? 예상했던 결과인가?"라는 질문을 여전히 하게 됩니다.

인터넷용 모델을 학습시킨다는 것은 움직이는 표적에 대해 모델을 학습시키는 것입니다. 입력이 변경되지 않는 한 누구나 정적 데이터로 모델을 학습시키고 훌륭한 결과를 얻을 수 있습니다. 새로운 위협, 브라우저, 봇이 등장하는 미래로 일반화할 수 있는 모델을 구축하는 것은 더 어려운 작업입니다. 머신 러닝 모니터링이 중요한 부분인 이유는 엄격하고 반복 가능한 프로세스를 통해 모델이 계속 일반화된다는 확신을 주기 때문입니다.

머신 러닝 모니터링 이전에는 팀에서 웹 트래픽 패턴을 분석하고 채점 결과를 모델링하여 봇 또는 사람으로 채점된 웹 요청의 비율을 추적했습니다. 이 높은 수준의 메트릭은 종합적으로 모델의 성능을 평가하는 데는 유용하지만, 특정 유형의 트래픽에서 모델이 어떻게 작동하는지에 대한 세부적인 정보는 제공하지 못했습니다. 보다 심층적인 분석을 위해서는 Chrome 브라우저의 트래픽이나 iOS를 사용하는 클라이언트와 같은 개별 트래픽 세그먼트의 성능을 조사하는 작업을 추가로 해야 합니다.

머신 러닝 모니터링을 사용하면 많은 수작업 조사 없이도 모델이 어떻게 작동하는지 높은 수준에서뿐만 아니라 훨씬 더 세분화된 방식으로도 인사이트를 얻을 수 있습니다. 모니터링은 다음과 같은 중요한 질문에 답함으로써 피드백 루프를 종결합니다. "봇 감지 모델이 프로덕션 환경에서 어떻게 작동하고 있나요?" 모니터링을 통해 배포 전 모델 검증/테스트에서 얻은 수준과 동일한 수준의 신뢰도를 얻을 수 있지만, 운영 중인 모든 모델에 적용한다는 점이 다릅니다.

모니터링의 중요성이 입증된 사용 사례에는 다음이 포함됩니다.

• 봇 점수 이상 징후 조사: 고객이 머신 러닝의 긍정 오류/부정 오류 점수를 보고하고 감지 하위 집합에서 더 광범위한 문제가 의심되는 경우, 모니터링이 답을 찾는 데 도움이 될 수 있습니다. 엔지니어는 Cloudflare의 글로벌 모니터링 대시보드에서 인사이트를 찾거나 특정 데이터 세트의 성능에 집중할 수 있습니다.

• 모든 모델 예측 또는 요청 필드 모니터링: 모니터링 서비스는 유연하며 웹 요청 데이터베이스에 저장된 모든 요청 아티팩트에 대한 통합 가시성 계층을 추가할 수 있습니다. 모델 예측이나 관심 있는 결과가 요청 로그와 함께 저장되어 있으면 이를 모니터링할 수 있습니다. 저희는 엔지니어링 팀과 협력하여 모든 결과를 모니터링할 수 있습니다.

• 새 모델 배포: 새로운 모델 버전을 점진적으로 배포하여 궁극적으로 Cloudflare의 글로벌 웹 트래픽 전체에서 실행되도록 확대합니다. 그 과정에서 새 모델을 다음 릴리스 단계에 배포하기 전에 일련의 점검을 거칩니다. 모니터링을 통해 각 배포 단계에서 세분화된 트래픽 세그먼트에 대해 최신 모델과 이전 버전을 비교할 수 있으므로 롤아웃을 진행할 때 확신을 가질 수 있습니다.

이 프로세스는 실지 검증 데이터 세트에서 시작됩니다. 이는 사람이 생성했거나 봇이 생성한 것으로 알려진 트래픽 데이터 세트에 적절하고 정확하게 레이블이 지정된 데이터 세트입니다. 모델에서 특정 요청을 봇 트래픽으로 식별하는 경우, 실지 검증 레이블이 해당 요청이 사람으로부터 발생했음을 나타내면 모델이 요청을 잘못 분류한 것이며, 그 반대의 경우도 마찬가지입니다. 트래픽을 봇 또는 사람으로 분류하는 이러한 종류의 레이블이 지정된 데이터는 애초에 감지 학습을 위해 모델에 학습된 데이터입니다.

학습 시점에 수집된 데이터 세트를 통해 해당 스냅샷에 대한 학습된 모델의 성능을 적시에 평가할 수 있습니다. 저희가 프로덕션 환경에서 모델 성능을 지속적으로 평가하기를 원하므로, 봇 점수와 비교할 수 있는 실시간 레이블이 지정된 데이터도 확보해야 합니다. 웹 요청이 특정 행위자로부터 온 것이 확실할 때 이러한 목적으로 레이블이 지정된 데이터 세트를 생성할 수 있습니다. 예를 들어 ,휴리스틱 엔진은 신뢰도가 높은 레이블이 지정된 데이터의 하나의 소스입니다. 신뢰할 수 있는 레이블이 지정된 데이터의 다른 소스에는 고객 피드백 및 공격 패턴 연구가 포함됩니다.

웹 요청에 대한 모델의 봇 점수를 최근 레이블이 지정된 데이터 세트와 직접 비교하여 모델 성능을 판단할 수 있습니다. 시간 경과에 따른 모델 점수를 평가할 때 사과 대 사과 비교를 하기 위해서는 일관성이 가장 중요합니다. 데이터 자체는 다르지만, 샘플링 기간 간에 방법론, 조건, 필터는 동일하게 유지해야 합니다. 이 프로세스를 자동화하여 실시간으로 레이블이 지정된 데이터 세트를 생성하여 모델 성능을 최신 상태로 파악할 수 있습니다.

봇 트래픽으로 리에블이 지정된 특정 데이터 세트에서 정확도가 갑자기 떨어졌다고 가정해 보겠습니다. 이는 감지가 잘못되어 봇을 사람 트래픽으로 잘못 채점하고 있다는 의미입니다. 점수 누락의 원인이 되는 트래픽의 정확한 하위 집합을 파악하고 싶을 것입니다. 이 하위 집합은 최신 Chrome 브라우저에서 발생하는 트래픽인가요, 아니면 특정 자율 시스템 번호에서 발생하는 트래픽인가요?

이 의문에 답하기 위해 성능 모니터링에서는 관심 있는 차원(예: 브라우저 유형, 자율 시스템 번호)에 초점을 맞춘 데이터 세트에 적용되는 필터인 전문화를 사용합니다. 데이터 세트에 대한 전문화를 통해 트래픽이 어떻게 점수가 매겨졌어야 하는지에 대한 예상치와 누락의 원인이 되는 정확한 차원에 대한 인사이트를 모두 얻을 수 있습니다.

모니터링 시스템은 통합 플랫폼인 _Endeavor_에서 실행됩니다. 이 플랫폼은 모델 학습 및 검증, 모델 해석 가능성, 봇 감지를 실행하는 서버에 대한 최신 정보 제공 등 봇 관련 머신 러닝의 모든 측면을 처리하기 위해 구축되었습니다. 모니터링은 데이터 세트를 가져오기 위한 모니터링 쿼리 렌더링, 성능 메트릭 계산, 메트릭 저장 등 몇 가지 작업으로 나눌 수 있습니다. Endeavour는 워크플로우 실행 엔진인 Airflow를 사용하므로, kubernetes 클러스터와 GPU 위에서 모니터링 작업을 실행하고 Postgres 및 ClickHouse 데이터베이스에 액세스할  수 있습니다.

모니터링 쿼리는 ClickHouse 웹 요청 데이터베이스에 "현재 머신 러닝 점수는 어떻게 보이나요?" 라고 묻는 단순한 SQL 쿼리입니다. 이 쿼리는 데이터 세트와 전문화 조건을 추가하면 더 정확해져서 "이 알려진 (비)자동화된 트래픽 세트에 대해, 머신 러닝 점수는 이러한 관심 차원을 따라 어떻게 보이나요?"라는 더 정밀한 질문을 할 수 있습니다.

저희 시스템에서 학습 및 검증을 위한 데이터 세트는 SQL 쿼리를 사용하여 결정됩니다. SQL 쿼리는 휴리스틱 엔진에서 봇으로 플래그가 지정된 트래픽과 같은 요청 트래픽의 세그먼트를 캡처하도록 맞춤화됩니다. 모델 모니터링의 경우 저희는 이러한 쿼리를 조정하여 정확도와 같은 성능 메트릭을 측정하고 시간 범위를 지속적으로 업데이트하여 최신 모델 성능을 측정합니다. 학습 및 검증에 사용되는 각 데이터 세트에 대해 모델 성능에 대한 실시간 인사이트를 생성하는 모니터링 쿼리를 생성할 수 있습니다.

렌더링된 모니터링 쿼리가 준비되면 웹 요청 데이터베이스에서 봇 점수 분포를 가져올 수 있습니다. MetricsComputer는 봇 점수 분포를 입력으로 받아 구성 가능한 시간 간격에 걸쳐 정확도와 같은 관련 성능 메트릭을 생성합니다.

관심 있는 모든 메트릭에 따라 모델 성능을 평가할 수 있습니다. MetricInterface는 성능 메트릭에 대한 청사진 역할을 하는 Python 인터페이스입니다. 새로 추가된 모든 메트릭은 MetricsComputer에서 계산을 수행하는 방법을 정의하는 인터페이스의 compute_metric 메서드만 구현하면 됩니다.

각 모니터링 실행 후에는 데이터 세트, 모델 버전, 전문화 값별로 성능 메트릭을 ml_performance ClickHouse 테이블에 저장합니다. 메트릭을 미리 계산하면 데이터 보존 기간이 길어지므로 시간이 지남에 따라 모델 버전이나 관심 있는 차원별로 모델 성능을 검토할 수 있습니다. 중요한 점은 ml_performance 테이블에 각 메트릭을 계산하는 데 사용된 점수 분포도 저장되므로 필요에 따라 새로 추가된 성능 메트릭을 다시 채울 수 있다는 것입니다.

메트릭 계산은 GPU에서 실행되는 endeavour-worker 인스턴스 간에 부하가 분산됩니다. 시스템 관점에서 보면, airflow-scheduler는 모니터링 작업을 Redis Queue에 추가하고 각 GPU에서 실행 중인 Airflow Celery workers는 처리를 위해 대기열에서 작업을 가져옵니다. 애드혹 모델 트레이닝 워크로드만 실행하는 것이 아니라 지속해서 GPU로 구동되는 프로덕션 서비스의 이점을 누릴 수 있습니다. 그 결과로 모니터링 서비스는 다양한 Endeavour 구성 요소가 GPU에서 제대로 작동하는지 확인하는 상태 점검 역할을 합니다. 이를 통해 GPU가 항상 업데이트되고 모델 학습/검증 작업을 실행할 준비가 되어 있는지 확인할 수 있습니다.

Cloudflare에서 머신 러닝 모니터링을 사용하는 방법을 더 잘 설명하기 위해 몇 가지 최근 사례를 살펴보겠습니다.

모니터링 시스템을 처음 배포했을 때, 저희는 HTTP/3을 사용하는 웹 트래픽에서 모델이 제대로 작동하지 않는다는 이상 징후를 빠르게 발견했습니다. 당시에는 웹에서 HTTP/3 사용이 거의 보이지 않았고, 운영 중인 기본 모델은 HTTP/3 트래픽에 대해 학습되지 않았기 때문에 봇 점수가 부정확하게 나왔습니다. 다행히도 또 다른 봇 감지 계층인 휴리스틱 엔진에서는 여전히 HTTP/3을 사용하는 봇을 정확하게 찾아내고 있었으므로 고객들은 여전히 보호를 받을 수 있었습니다.

그럼에도 불구하고 이 결과에 따라 다음 모델 반복을 위해 개선해야 할 핵심 영역이 식별되었습니다. 그리고 저희는 개선 작업을 했습니다. 다음 번에 반복된 모델에서는 이전 모델 버전에 비해 3.5배 이상 높은 정확도로 봇과 사람이 시작한 HTTP/3 웹 요청을 일관되게 구분할 수 있었습니다. 더 많은 데이터 세트와 전문화를 지원함에 따라 모델 학습 중에 성능을 개선할 수 있는 특정 브라우저, OS, 기타 차원을 발견할 수 있습니다.

전 세계 100여 개국에 분산된 데이터 센터에서 실행되는 머신 러닝을 글로벌 규모로 배포하는 것은 쉽지 않은 일입니다. 모든 일이 항상 계획대로 진행되지는 않습니다.

몇 년 전, 머신 러닝 기반 봇 감지 기능에 대한 업데이트를 배포한 후 긍정 오류 봇 감지(일부 정상 트래픽을 봇 트래픽으로 잘못 분류하는 것)가 증가했습니다. 모니터링 시스템에서는 대부분 비자동화된 트래픽이 예상되는 주거지 ASN의 성능 저하가 빠르게 나타났습니다.

위 그래프에서 배포는 1~3"계층"의 세 가지 색상으로 표시되어 있습니다. 소프트웨어 배포는 계층 3 코로케이션 센터에서 시작하여 점차 계층 1로 올라가므로 그 영향은 동일한 패턴을 따릅니다.

동시에 전역 네트워크에 소프트웨어 릴리스가 배포되고 있었지만, 이것이 성능 저하의 원인인지는 알 수 없었습니다. 저희는 단계적 배포를 통해 글로벌 트래픽에 도달하기 전에 한 번에 한 데이터센터의 소프트웨어를 한 번에 업데이트합니다. 모니터링 대시보드에서 이 정확한 배포 패턴에 따른 성능 저하가 나타났고, 해당 릴리스가 가장 큰 데이터센터에 도달하기 시작했습니다.

모니터링 대시보드를 보면 소프트웨어 업데이트 이후의 패턴이 명확하게 나타났습니다. 저희는 대부분의 데이터센터에 업데이트가 적용되기 전에 변경 사항을 되돌리고 정상적인 머신 러닝 봇 감지 성능을 복원했습니다. 모니터링을 통해 성능 이상 징후를 포착하고 근본 원인을 파헤쳐 신속하게 조치를 취할 수 있습니다.

저희는 모델과 배포를 모니터링하고 제어할 수 있다는 점에서 많은 가치를 확인했고, 다른 사람들도 같은 문제를 겪고 있을 것이라는 사실을 깨달았습니다. 앞으로 몇 달 동안 사람들이 AI 앱과 모델을 더 잘 관찰하고 제어할 수 있도록 도와주는 프록시인 AI Gateway 에 더 많은 첨단 기능을 구축할 예정입니다. AI Gateway를 사용하면 봇 감지 모델에 대해 수행하던 것과 동일한 배포, 모니터링, 최적화 전략을 하나의 통합 제어판에서 수행할 수 있습니다. 내부적으로 이러한 새로운 기능을 사용하게 되어 기쁘지만, 누구나 AI 또는 머신 러닝 모델을 배포, 테스트, 모니터링, 개선할 수 있도록 일반 공개를 하게 되어 더욱 기대가 큽니다.

오늘날 머신 러닝 모니터링은 새로운 모델을 출시할 때 성능 문제를 조사하고 성능을 모니터링하는 데 도움이 되며, 이는 이제 시작에 불과합니다!

올해는 봇 감지를 위한 머신 러닝 모델 반복을 가속화하여 그 어느 때보다 더 빠르게 향상된 감지 기능을 제공할 예정입니다. 빠르고 안전하게 배포하려면 모니터링이 핵심입니다. 모델 성능에 기반한 알림을 추가하게 되어 기쁩니다. 이제 모델 성능이 예상 범위를 벗어날 경우 자동으로 알림을 받을 수 있습니다.

Workers AI 출시와 함께 최근 100여 개의 도시에 GPU를 배치하여 전 세계적으로 컴퓨팅 리소스를 강화했습니다. 이 새로운 인프라를 통해 모델 반복 프로세스를 개선하여 더욱 강력한 봇 감지 기능을 갖춘 새로운 최첨단 모델을 탐색할 수 있게 되었습니다. GPU에서 모델을 실행하면 사용자에게 더 가까운 곳에서 추론을 수행하여 모델 성능과 대기 시간을 개선할 수 있습니다. 새로운 GPU 컴퓨팅을 봇 감지 모델에도 활용할 수 있게 되어 기대가 큽니다.