Computer >> 컴퓨터 >  >> 프로그램 작성 >> Redis

실시간 AI/ML을 위한 기능 저장소:벤치마크, 아키텍처 및 사례 연구

사기 방지 및 추천과 같은 실시간 인공 지능/머신 러닝(AI/ML) 사용 사례가 증가하고 있으며 기능 저장소는 이를 프로덕션에 성공적으로 배포하는 데 핵심적인 역할을 합니다. 인기 있는 오픈 소스 기능 스토어 Feast에 따르면 사용자가 커뮤니티 Slack에서 가장 일반적인 질문 중 하나는 다음과 같습니다. 어떻게 확장성/성능 축제는 무엇입니까?  실시간 AI/ML용 피처 스토어의 가장 중요한 특징은 온라인 스토어에서 온라인 예측이나 채점을 위한 ML 모델로의 피처 제공 속도이기 때문입니다. 성공적인 기능 저장소는 엄격한 대기 시간 요구 사항(밀리초 단위로 측정)을 일관되게(p99 생각) 대규모로(초당 최대 수백만 개의 쿼리, 기가바이트에서 테라바이트 규모의 데이터 세트 포함) 낮은 총 비용을 유지하면서 충족할 수 있습니다. 소유권과 높은 정확도.

이 게시물에서 볼 수 있듯이 온라인 기능 저장소의 선택과 기능 저장소의 아키텍처는 기능 저장소의 성능과 비용 효율성을 결정하는 데 중요한 역할을 합니다. 종종 기업이 온라인 기능 저장소를 선택하기 전에 철저한 벤치마킹을 수행하여 어떤 아키텍처 또는 온라인 기능 저장소를 선택하는 것이 가장 성능이 좋고 비용 효율적인지 확인하는 것은 놀라운 일이 아닙니다. 이 게시물에서는 실시간 AI/ML 사용 사례를 성공적으로 배포한 회사가 구축한 두 DIY 기능 저장소와 오픈 소스 및 상용 기능 저장소의 아키텍처와 벤치마크를 검토할 것입니다. 시작하겠습니다.

1. 오픈 소스 축제

먼저 벤치마킹 데이터를 살펴본 다음 Feast 오픈 소스 기능 저장소의 데이터 아키텍처를 살펴보겠습니다. Feast는 최근 다양한 온라인 스토어(Redis vs. Google Cloud DataStore vs. AWS DynamoDB)를 사용할 때 기능 제공 지연 시간을 비교하는 벤치마크를 수행했습니다. 또한 기능을 추출하기 위해 다양한 메커니즘(예:Java gRPC 서버, Python HTTP 서버, 람다 함수 등)을 사용하는 속도를 비교했습니다. 이 블로그 게시물에서 전체 벤치마크 설정과 그 결과를 찾을 수 있습니다. 결론:Feast는 Java gRPC 서버를 사용하고 Redis를 온라인 스토어로 사용할 때 가장 성능이 좋다는 것을 발견했습니다.

실시간 AI/ML을 위한 기능 저장소:벤치마크, 아키텍처 및 사례 연구

위의 다이어그램에서 온라인 모기지 회사 Better.com이 오픈 소스 Feast 기능 저장소를 사용하여 리드 스코어링 순위 시스템을 구현한 방법의 예를 볼 수 있습니다. Better.com의 수석 소프트웨어 엔지니어인 Vitaly Sergey가 발표한 것처럼 기능은 오프라인 매장(S3, Snowflake, Redshift)에서 온라인 매장(Redis)으로 구체화됩니다. 그 외에도 기능은 스트리밍 소스(Kafka 주제)에서 온라인 스토어로 수집됩니다. Feast는 최근에 현재 Redis에서만 지원되는 스트리밍 데이터 소스(일괄 데이터 소스 추가)에 대한 지원을 추가했습니다. 스트리밍 데이터 소스를 지원하는 것은 실시간 AI/ML 사용 사례에서 매우 중요합니다. 이러한 사용 사례는 최신 라이브 데이터에 의존하기 때문입니다.

예를 들어 Better.com의 리드 스코어링 사용 사례에서 새로운 리드가 하루 종일 지속적으로 수집됩니다. 기능은 다양한 소스에서 제공되며 엔터티(리드)와 점수를 매기는 데 사용되는 기능은 모두 항상 업데이트되므로 리드의 순위가 매겨지고 순위가 다시 매겨집니다. 새 리드가 있는 즉시 모델이 이를 수집하고 점수를 매깁니다. 온라인 상점에 수집되는 동시에 우리는 곧 순위를 다시 매길 수 있습니다. Better.com 리드는 48시간 후에 만료되며, 이는 TTL(Time to Live)을 48시간으로 설정하여 엔터티(리드)를 만료하고 48시간 후에 기능 벡터를 연결하여 Redis 온라인 스토어에서 구현됩니다. 따라서 기능 저장소는 자동으로 정리되며 귀중한 온라인 저장소를 차지하는 오래된 엔터티나 기능이 없습니다.

Feast의 또 다른 흥미로운 구현은 Microsoft Azure Feature Store입니다. 여기에서 그 아키텍처를 볼 수 있습니다. 대기 시간이 짧은 실시간 AI/ML 사용 사례에 최적화된 Azure 클라우드에서 실행되며 Azure 데이터 및 AI 에코시스템으로의 통합은 물론 일괄 및 스트리밍 소스를 모두 지원합니다. 기능은 배치 원본(Azure Synapse Serverless SQL, Azure Storage/ADLS)과 스트리밍 원본(Azure Event Hub) 모두의 온라인 스토어에서 수집됩니다. Azure에 이미 배포되었거나 Azure 에코시스템에 익숙한 경우 그렇다면 이 기능 저장소가 귀하에게 적합할 수 있습니다. 온라인 스토어의 경우 Azure Cache for Redis를 사용하고, Azure Redis의 엔터프라이즈 계층에는 Active-Active 지역 복제를 포함하여 최대 99.999%의 가용성으로 전 세계적으로 분산된 캐시를 생성합니다. 또한 엔터프라이즈 플래시 계층을 사용하여 인메모리(DRAM) 및 플래시 메모리(NVMe 또는 SSD)를 모두 사용하여 데이터를 저장하는 계층형 메모리 아키텍처에서 Redis를 실행하면 추가 비용 절감을 달성할 수 있습니다.

2. Wix DIY 기능 저장소 – MLOps 플랫폼의 초석

다음은 실시간 AI/ML 사용 사례를 구현하기 위한 다른 아키텍처입니다. 인기 있는 웹사이트 구축 플랫폼 Wix의 기능 저장소 아키텍처입니다. 추천, 이탈 및 프리미엄 예측, 순위, 스팸 분류기와 같은 실시간 사용 사례에 사용됩니다. Wix는 2억 명이 넘는 등록 사용자에게 서비스를 제공하며, 그 중 특정 시간에 '활성 사용자'는 극히 일부에 불과합니다. 이것은 기능 저장소가 구현되는 방식에 큰 영향을 미쳤습니다. 살펴보겠습니다.

아래 정보는 Ran Romano가 Wix에서 ML 엔지니어링을 이끌 때 제공한 TechTalk 프레젠테이션을 기반으로 합니다. Wix 기능 저장소에 저장된 데이터의 90% 이상이 클릭스트림이며 ML 모델은 웹사이트 또는 사용자별로 트리거됩니다. Ran은 실시간 사용 사례의 경우 대기 시간이 큰 문제라고 설명합니다. 또한 일부 프로덕션 사용 사례의 경우 밀리초 이내에 기능 벡터를 추출해야 합니다.

실시간 AI/ML을 위한 기능 저장소:벤치마크, 아키텍처 및 사례 연구

원시 데이터는 AWS의 Parquet 파일에 S3 버킷에 저장되며 사업부(예:'편집자', '레스토랑', '예약' 등)와 날짜별로 분할됩니다. Wix ML 플랫폼보다 수년 앞서 데이터 분석가가 사용하는 Wix 데이터 플랫폼의 일부입니다. 일일 빌드에서 Spark를 사용한 일괄 처리, SQL(몇 분에서 몇 시간 소요)은 모든 사용자의 기록 기능을 S3에서 추출하고 사용자가 피벗 및 집계한 다음 오프라인 저장소(Apache Hbase)에 수집합니다. 이것은 '사용자'별로 사용자 기록 조회를 훨씬 빠르게 제공합니다. 시스템이 사용자가 현재 활성 상태임을 감지하면 '워밍업' 프로세스가 트리거되고 해당 사용자의 기능이 활성 사용자의 사용자 기록만 보유하므로 오프라인 상점보다 훨씬 작은 온라인 상점(Redis)에 로드됩니다. 이 '워밍업' 프로세스는 몇 초가 걸릴 수 있습니다. 마지막으로 온라인 기능 저장소의 기능은 사용자(Apache Storm 사용)로부터 오는 각 이벤트마다 스트리밍 소스에서 직접 신선한 실시간 실시간 데이터를 사용하여 지속적으로 업데이트됩니다.

이 유형의 아키텍처는 Feast 아키텍처에 비해 쓰기 대 읽기 비율이 낮습니다. 이는 모든 사용자에 대한 기능이 아닌 온라인 상점에 활성 사용자에 대한 기능만 저장하기 때문에 구체화 및 온라인 저장 측면에서 매우 효율적입니다. 활성 사용자는 Wix에 등록된 모든 사용자의 작은 부분을 차지하기 때문에 이는 엄청난 비용 절감을 의미합니다. 그러나 여기에는 대가가 따릅니다. 온라인 상점에서 기능을 검색하는 것은 매우 빠르지만 밀리초 이내에 기능이 이미 온라인 상점에 있는 경우에만 가능합니다. 경쟁 조건으로 인해 워밍업 프로세스는 몇 초가 걸리기 때문에 사용자가 활성화될 때 관련 기능을 로드하기에 충분히 빠르지 않습니다. 따라서 해당 사용자에 대한 점수 또는 예측은 실패합니다. 사용 사례가 중요한 흐름의 일부가 아니거나 거래 승인 또는 사기 방지와 같은 미션 크리티컬한 사용 사례의 경우라면 괜찮습니다. 이러한 유형의 아키텍처는 특정 시간에 소수의 사용자만 활성 사용자인 Wix에만 해당됩니다.

3. 상업 기능 저장소 Tecton

이제 상업용 엔터프라이즈 기능 저장소 Tecton의 아키텍처를 살펴보겠습니다. 아래 다이어그램에서 볼 수 있듯이 Tecton은 일괄 데이터 소스 및 스트리밍 데이터 소스 외에도 '즉시 사용 가능한' 실시간 데이터 소스도 지원합니다. 이는 '실시간 기능이라고도 합니다. ' 또는 '실시간' 변환. 실시간 특징은 추론 요청 시에만 계산할 수 있습니다. 예를 들어 의심되는 트랜잭션의 크기와 마지막 트랜잭션 크기의 차이입니다. 따라서 위의 오픈 소스 Feast가 있는 Better.com의 경우 Better.com은 자체적으로 실시간 기능 지원을 개발했습니다. Tecton 기능 저장소를 사용하면 기능 저장소에서 이미 기본적으로 지원하므로 구현하기가 더 쉽습니다. Feast 및 Wix 기능 저장소와 마찬가지로 Tecton은 레지스트리에 기능을 정의하여 논리적 정의가 오프라인 및 온라인 저장소 모두에 대해 한 번 정의되도록 합니다. 이렇게 하면 프로덕션 환경에서도 ML 모델의 높은 정확도를 보장하기 위해 훈련 제공 왜곡이 크게 줄어듭니다.

실시간 AI/ML을 위한 기능 저장소:벤치마크, 아키텍처 및 사례 연구

오프라인 스토어, 온라인 스토어 및 벤치마킹 선택과 관련하여 오프라인 기능 스토어의 경우 Tecton은 S3를 지원하고 온라인 스토어의 경우 Tecton은 이제 고객에게 DynamoDB와 Redis Enterprise Cloud 중에서 선택할 수 있는 기회를 제공합니다. 최근 프레젠테이션에서 Tecton CTO Kevin Stumpf는 회사가 최근에 수행한 벤치마크를 기반으로 온라인 기능 저장소를 선택하는 방법에 대한 팁을 제공했습니다. 대기 시간과 처리량을 벤치마킹하는 것 외에도 Tecton은 온라인 상점의 비용도 벤치마킹했습니다. 이것이 왜 중요한가? 처리량이 높거나 대기 시간이 짧은 사용 사례의 경우 온라인 상점 비용이 크고 전체 MLOps 플랫폼의 총 소유 비용에서 상당한 부분을 차지할 수 있으므로 비용 절감 효과는 상당할 수 있습니다.

Tecton 벤치마킹의 결론은 Tecton 사용자에게 일반적인 높은 처리량 사용 사례의 경우 Redis Enterprise가 DynamoDB에 비해 3배 더 빠르고 동시에 14배 저렴하다는 것입니다.

그래서 당신이 물을 수 있는 캐치는 무엇입니까? 사용 사례가 하나뿐이고 처리량이 높거나 일정하지 않고 엄격한 지연 요구 사항이 없는 경우 DynamoDB를 사용할 수 있습니다. 여기에서 Tecton 벤치마크의 전체 세부정보와 결과를 확인할 수 있습니다.

4. 상업용 기능 스토어 Qwak을 사용하는 Lightricks

다음은 기능 저장소 아키텍처의 또 다른 예입니다. 이것은 상용 기능 스토어 Qwak을 기반으로 하는 Lightricks에서 사용합니다. Lightricks는 특히 셀카 편집 앱인 Facetune으로 유명한 동영상 및 이미지 편집 모바일 앱을 개발하는 유니콘 회사입니다. 추천 시스템에 기능 저장소를 사용합니다.

실시간 AI/ML을 위한 기능 저장소:벤치마크, 아키텍처 및 사례 연구

위의 다이어그램에서 볼 수 있듯이 Tecton과 같이 Qwak 기능 저장소는 일괄, 스트리밍 및 실시간 기능의 세 가지 유형의 기능 소스를 지원합니다.

Qwak 기능 저장소에서 기능 저장소로의 구체화는 오프라인 저장소(S3의 Parquet 파일 사용)와 온라인 저장소(Redis 사용) 모두에 대한 원시 데이터 소스에서 직접 수행된다는 점에 유의하는 것이 중요합니다. 이것은 온라인 스토어의 구체화가 일괄 소스에 대한 오프라인 스토어에서 온라인 스토어로 수행되는 Wix, Feast 또는 Tecton의 기능 스토어 예와 다릅니다. 이것은 기능의 변환 로직이 훈련 및 제공 흐름 전반에 걸쳐 통합될 뿐만 아니라(위의 Feast, Wix 및 Tecton의 기능 저장소와 같이) 실제 변환 또는 기능 계산이 균일하게 수행되어 더 감소한다는 이점이 있습니다. 훈련 서빙 스큐. 원시 데이터에서 직접 오프라인 및 온라인을 위한 통합 데이터 파이프라인을 보유하면 생산 중에 더 높은 정확도를 보장할 수 있습니다. 이 프레젠테이션에서 Qwak의 기능 저장소 아키텍처 및 구성 요소에 대한 자세한 정보를 찾을 수 있습니다.

요약

이 게시물에서 우리는 실시간 AI/ML을 위한 여러 기능 저장소의 벤치마크 및 아키텍처의 주요 하이라이트를 검토했습니다. 첫 번째는 오픈 소스 피스트(Open Source Feast), 두 번째 DIY Wix 기능 스토어, 세 번째는 Tecton, 네 번째는 Qwak입니다. 우리는 또한 어떤 온라인 상점이 가장 성능이 좋고 비용 효율적인지 알아보기 위해 이들 회사가 수행한 몇 가지 벤치마크의 하이라이트를 검토했습니다. 또한 온라인 상점에서 기능을 추출하는 데 사용할 메커니즘 또는 기능 서버를 탐색했습니다. 아키텍처, 지원되는 기능 유형 및 선택한 구성 요소에 따라 기능 저장소의 성능과 비용에 상당한 차이가 있음을 확인했습니다.

원래 에 게시됨 KDnuggets .