이 아키텍처는 온라인 서비스와 오프라인 교육 문제를 엄격하게 분리하는 이중 저장소 패턴을 사용합니다. 온라인 계층은 각 지역 내 NVMe 기반 인스턴스에 배포된 Redis Cluster를 사용하며, Envoy Proxy를 통해 로컬 로드 밸런싱 및 TLS 종료를 수행합니다. 기능 업데이트는 불변의 변경 로그 역할을 하는 Apache Kafka를 통해 흐르며, Debezium CDC 커넥터가 운영 데이터베이스에서의 변화를 포착하여 지역 Redis 소비자에게 스트리밍합니다.
오프라인 저장소의 경우, 역사적 기능은 S3의 Apache Iceberg 테이블에 압축되어 시간 여행 쿼리와 Apache Spark를 통한 효율적인 배치 처리 기능을 제공합니다. 백필 중 일관성은 벡터 클럭 버전 관리로 달성되며, 각 기능 값은 논리적 타임스탬프를 가지고, Redis Lua 스크립트는 순서가 뒤바뀐 쓰기를 거부하여 원자적인 비교 및 교환 작업을 수행하여 제공 경로가 부분 백필 상태를 관찰하지 않도록 보장합니다.
드리프트 감지는 Prometheus 히스토그램을 활용하며, Apache Flink 작업을 통해 기능 분포에 대한 실시간 통계 분석을 수행합니다. KL-발산 또는 군집 안정성 지수가 임계치를 초과할 경우, Flink는 Argo Workflows를 트리거하여 크로스 지역 모델 재훈련 및 카나리 배포를 조율합니다.
다국적 핀테크 기업은 AWS, Azure 및 온프레미스 데이터 센터 전반에 걸쳐 실시간 사기 탐지 기능이 필요했습니다. 중요한 과제는 사용자 거래 속도와 같은 롤링 집계 기능을 제공하여 추론 엔드포인트에 5ms 미만의 지연으로 제공하는 것이었습니다. 그들 기존의 PostgreSQL 읽기 복제본은 피크 부하 중에 200ms를 초과하는 복제 지연에 시달려, 사기 점수 모델이 오래된 데이터로 작동하고 협조 공격을 놓치게 만들었습니다.
해결책 1: 글로벌 액티브-액티브 데이터베이스 CockroachDB 또는 Google Spanner를 배포함으로써 직렬화 가능한 격리 상태와 자동 글로벌 복제를 약속했습니다. 이 접근 방식은 일관성 문제를 없앴지만, Paxos 합의 오버헤드로 인해 지역 간 쓰기 지연이 100ms를 초과하는 문제를 발생시켰습니다. 새로운 거래의 즉각적인 가시성을 요구하는 고속 기능에는 이 지연이 수용할 수 없는 수준이었습니다. 게다가 운영비용은 읽기 처리량에 따라 제곱적으로 증가하여 밀리초 수준의 제공 요건에 경제적으로 불가능했습니다.
해결책 2: 지역 캐시와 최종 일관성 각 지역마다 독립적인 Redis 클러스터를 구현하고 Kafka MirrorMaker를 통한 비동기 복제를 제공하여 뛰어난 읽기 성능과 선형 확장성을 제공했습니다. 그러나 이는 데이터 과학자가 데이터 품질 문제를 수정하기 위해 역사적 기능을 재계산할 때 백필 작업 중에 중요한 일관성 취약점을 발생시켰습니다. 엄격한 버전 관리 보장이 없으면 시스템이 오래된 집계와 신선한 집계를 동시에 서비스하게 되어 모델 추론 왜곡과 정당한 거래를 잘못 표시하는 잘못된 위험 점수로 이어졌습니다.
해결책 3: 벡터 클럭을 이용한 계층 캐싱(선택됨) 핫 계층으로 Redis를 사용하고 불변의 진실 출처로 Kafka를 사용하는 계층 시스템을 설계했습니다. 각 기능 값은 수집 파이프라인에서 유래한 벡터 클록 타임스탬프를 가지고 있습니다. 백필 중에 Spark 작업이 S3에 기록하면서 버전이 있는 이벤트를 Kafka에 방출했습니다. 지역 소비자는 Redis Lua 스크립트를 사용하여 업데이트를 적용하고, 서버 측 벡터 클럭 비교를 수행하여 순서가 뒤바뀐 쓰기를 원자적으로 거부하고 더 새 버전을 수락했습니다. 드리프트 감지를 위해 기능 분포를 Prometheus 히스토그램을 통해 계측하고, 실시간 통계 비교를 위해 Flink에 공급했습니다.
그 결과, P99 제공 지연을 전 세계적으로 1.2ms로 줄였고, 백필 동안 일관성 위반을 제거했으며, 자동 드리프트 트리거 기반 재훈련 파이프라인을 통해 모델 쇠퇴 사건을 94% 줄였습니다.
온라인 서비스 계층이 계속 사용 가능해야 하는 상황에서 대량 역사적 기능 백필 중에 캐시 오염을 어떻게 방지합니까?
많은 후보자들이 백필 동안 서비스를 일시 중지하거나 캐시와 데이터베이스에 걸친 분산 거래를 사용하는 것을 제안합니다. 올바른 접근 방식은 논리적 타임스탬프와 섀도우 키스페이스를 구현합니다. 백필 데이터는 점진적으로 증가하는 버전 ID로 구성된 별도의 Kafka 주제를 통해 흐릅니다. 온라인 서비스 클러스터는 두 개의 Redis 키스페이스(“현재” 및 “스테이징”)를 유지합니다. 백필은 스테이징을 채우고 현재로부터 읽기를 제공합니다. 완료 시, 원자적인 Redis RENAME 작업이 마이크로초 내에 키스페이스를 바꿉니다. 또는 대안으로, 애플리케이션 계층에서는 두 키스페이스를 쿼리하고 더 높은 버전의 값을 선택합니다. 이는 제로 다운타임을 보장하며 복잡한 조정 프로토콜 없이 부분 백필 상태의 서비스를 방지합니다.
온라인 및 오프라인 기능 저장소 간의 관계를 규율할 일관성 모델은 무엇이며, 왜 강한 일관성이 대규모에서는 실패합니까?
후보자들은 종종 Redis와 S3를 아우르는 ACID 거래를 잘못 주장합니다. 오프라인 저장소는 처리량과 배치 불변성을 최적화하고, 온라인 저장소는 저지연 포인트 읽기를 최적화합니다. 강한 일관성은 합의 오버헤드를 요구하여 제공 경로에서 용납할 수 없는 지연을 초래합니다. 대신, 제한된 신선도를 보장하는 최종 일관성을 채택합니다. Kafka 로그 압축을 사용하여 보존 기반 조정 창을 통해 온라인 저장소가 정의된 시간 경계 내에서 오프라인 저장소 상태와 일치하도록 보장합니다. 더 엄격한 보장이 필요한 기능의 경우, 온라인 쓰기 확인이 Kafka 커밋 확인을 기다리도록 하는 쓰기 투과 캐싱을 구현하여 다른 기능에 대해 높은 처리량을 유지하면서 약간 높은 지연을 수용하도록 합니다.
모델의 A/B 테스트 중에 동일한 원시 데이터의 비호환 변환이 필요한 경우 기능 버전 관리는 어떻게 처리합니까?
일반적인 오류는 모델 아티팩트만 버전 관리하고 기능 스키마 발전을 무시하여 훈련-서비스 왜곡을 초래합니다. 해결책은 DataHub 또는 Apache Atlas를 사용하여 기능 네임스페이스와 계보 추적을 구현하는 것입니다. 각 기능 변환은 의미적 버전을 받습니다. 기능 저장소는 접두사 키를 사용하여 Redis에서 여러 버전을 동시에 유지합니다. 모델 서비스 구성은 Consul 또는 etcd를 통해 필요한 기능 버전을 지정합니다. 그림자에서 프로덕션으로 모델을 승격할 때 오케스트레이션 계층은 트래픽 전환 전에 Kafka의 역사적 리플레이를 사용하여 새로운 기능 버전을 위한 캐시를 미리 따뜻하게 합니다. 이는 실험 집단 간 데이터 누수나 콜드 스타트 지연 스파이크 없이 비호환 기능 계산을 사용하는 A/B 테스트를 허용합니다.