How Jumio built a real-time feature store on AWS

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Jumio는 Amazon Kinesis, Apache Flink, Amazon SageMaker Feature Store와 Iceberg를 결합한 스트리밍 우선 구조로 중앙화된 실시간·오프라인 피처 저장소를 구축해 사기 탐지의 sub-100ms 요구를 충족하고 연간 약 12만 달러의 운영비를 절감했다.

📌 핵심 요약

• 기존에는 팀별 오프라인 피처 저장소로 데이터와 정의가 중복되고, Java나 Python 운영 코드로 피처를 수작업 재구현해 불일치와 버그 위험이 컸으며, 일부 이벤트는 최초 활동 후 수주가 지나서 도착했다.
• 새 플랫폼은 증가하는 피처 요청량과 카탈로그, 스키마 변경, 이벤트 시간 기반의 조건부 피처 생성, sub-100ms 제공, 과거 데이터 백필, 팀별 독립 개발을 함께 지원하도록 설계됐다.
• 실시간 경로는 Amazon Kinesis Data Streams에서 받은 이벤트를 Apache Flink로 처리해 Amazon SageMaker Feature Store의 인메모리·표준 저장소에 기록하고, 오프라인 경로는 Amazon Data Firehose, Amazon S3, Amazon EMR Serverless를 거쳐 Iceberg 테이블을 갱신한다.
• 구간별 지연과 Apache Flink 및 피처 저장소 상태를 지속적으로 측정한 결과 응답 지연은 P95 16.9ms, 읽기는 P50 8.44ms, 쓰기는 P50 18.6ms로 나타나 sub-100ms 요구를 충족했다.
• 중앙화와 배포 자동화로 수주가 걸리던 수작업 구현을 대체하고 지연 이벤트와 상위 모델 출력을 지원했으며, 인메모리 저장소 최적화를 통해 Jumio 워크로드 기준 연간 약 12만 달러를 절감했다.

🧩 주요 포인트

1. 분산된 피처 정의와 수작업 운영 구현 → 중앙화·재사용·자동화로 학습과 실시간 제공 사이의 불일치 및 개발 지연 축소.
2. Amazon Kinesis·Apache Flink 실시간 경로와 Iceberg 오프라인 경로의 병행 → 저지연 추론과 재학습·분석용 이력 데이터 요구를 동시에 수용.
3. P95 16.9ms와 연간 약 12만 달러 절감이라는 결과 → 계층형 저장의 효과를 보여주지만 다중 AWS 서비스 통합과 Apache Flink 운영 복잡성은 남는 비용 요소.

🧠 상세 정리

1. 도입 배경과 기존 문제

Jumio는 기업이 사기를 탐지하고 디지털 신뢰를 구축하도록 돕는 신원 확인 제공업체로, ML 모델이 최신 피처와 상위 모델 출력에 즉시 접근해야 하는 업무를 운영한다. 기존에는 각 팀이 자체 오프라인 피처 저장소를 관리해 같은 데이터가 중복되고 피처 정의도 서로 달라졌으며, 조직 전체에서 피처를 일관되게 재사용하기 어려웠다. 오프라인에서 학습한 피처를 Java나 Python 운영 코드로 다시 수작업 구현했기 때문에 학습 환경과 실시간 환경 사이의 불일치 및 버그 위험이 커졌고 배포에도 수주가 걸렸다. 사기 탐지는 낮은 지연을 요구하지만 필요한 피처를 즉시 제공하기 어려웠고, 일부 이벤트는 최초 활동 직후뿐 아니라 장기 검토 과정 때문에 몇 주 뒤 불규칙하게 도착했다. 이러한 문제를 함께 해결하려면 중앙에서 정의하고 여러 팀이 재사용하며 지연 이벤트까지 다룰 수 있는 실시간 피처 저장소가 필요했다.

2. 플랫폼의 다섯 가지 기술 요구

첫 번째 요구는 증가하는 피처 요청량과 피처 카탈로그를 감당하고, 기존 작업 흐름을 중단하지 않으면서 스키마를 발전시킬 수 있는 확장성이었다. 두 번째는 실제 ML 사용 사례에 필요한 조건부 피처 생성과 이벤트 시간에 따른 피처 선택을 지원하는 피처 엔지니어링 능력이었다. 세 번째는 사기 탐지 모델이 피처를 sub-100ms 안에 받아야 한다는 엄격한 지연 제약으로, 실시간 제공 계층의 핵심 성능 목표가 됐다. 네 번째는 재학습, 디버깅, 평가, 모니터링 및 과거 데이터 백필을 위해 오프라인 저장소에도 데이터를 준실시간으로 수집하는 것이었다. 마지막 요구는 백엔드·ML·데이터 엔지니어링 팀이 최소한의 조정만으로 새로운 피처를 독립적으로 도입할 수 있도록 개발부터 배포까지의 전체 생명주기를 단순화하는 것이었다.

3. 3개 리전의 스트리밍 우선 아키텍처

Jumio는 이 구조를 미국 동부 버지니아 북부의 us-east-1, 유럽 프랑크푸르트의 eu-central-1, 아시아 태평양 싱가포르의 ap-southeast-1 등 3개 AWS 리전에 배포했다. 실시간 흐름에서는 이벤트가 Amazon Kinesis Data Streams로 들어오고, Apache Flink가 이벤트를 처리해 피처로 변환한 뒤 Amazon SageMaker Feature Store에 기록한다. 추론 단계의 ML 모델은 저장된 피처를 조회해 사기 탐지와 신원 확인 판단에 사용하며, 전체 경로는 sub-100ms 제공을 목표로 한다. 동시에 오프라인 흐름은 Amazon Data Firehose를 통해 이벤트를 Amazon S3로 전달하고, Amazon EMR 계열 처리를 거쳐 Apache Iceberg 테이블에 적재한다. 따라서 전체 아키텍처는 이벤트를 운반하고 변환하는 데이터 파이프라인, 저지연 추론을 위한 실시간 피처 저장소, 재학습과 분석을 위한 오프라인 피처 저장소라는 세 부분으로 구성된다.

4. 실시간 파이프라인과 계층형 저장

실시간 수집 경로에서 Amazon Kinesis Data Streams는 들어오는 이벤트를 받아 Apache Flink 애플리케이션에 전달하고, Flink는 데이터를 이동 중에 처리하고 보강한다. 변환된 피처는 Amazon SageMaker Feature Store에 직접 기록되며, ML 모델은 추론 시 이 저장소에서 필요한 값을 가져간다. 최근 생성되어 자주 조회되는 핫 데이터는 Amazon ElastiCache for Valkey 기반 인메모리 저장소가 담당해 낮은 읽기 지연과 비용 효율적인 쓰기를 지원한다. 조회 빈도가 낮은 콜드 데이터는 확장성과 내구성을 제공하는 표준 저장소에 유지되므로, 모든 데이터를 동일한 고비용 계층에 둘 필요가 없다. 이 계층형 구성은 인메모리 저장소의 속도와 표준 저장소의 확장성을 결합해 사기 탐지의 지연 요구와 저장 비용을 함께 조정하는 방식이다.

5. 오프라인 저장소와 지연 이벤트 처리

오프라인 피처 저장소의 준실시간 흐름에서는 Apache Flink Sink가 데이터를 Amazon Data Firehose에 쓰고, Firehose가 이를 Amazon S3로 전달한다. Amazon S3 이벤트는 AWS Lambda를 거쳐 Amazon EMR Serverless를 호출하며, EMR Serverless가 Apache Iceberg 테이블을 갱신해 학습과 분석에 사용할 이력을 만든다. 별도의 무거운 배치 변환에서는 Amazon S3 이벤트로 Amazon EMR 처리를 시작하고, 결과 피처를 Amazon SageMaker Feature Store의 콜드 데이터와 Iceberg 테이블 양쪽에 적재한다. Iceberg 데이터는 Amazon Athena, Amazon EMR 대화형 노트북과 작업, 내부 데이터세트 준비 도구에서 접근할 수 있어 재학습·디버깅·평가·모니터링 및 백필에 활용된다. 현재 구조는 최초 활동 직후부터 몇 주 뒤까지 불규칙하게 도착할 수 있는 지연 피처를 처리하지만, 제공된 본문은 처리 도식을 언급할 뿐 이벤트 순서와 충돌을 해결하는 세부 규칙까지 설명하지는 않는다.

6. 지연 및 상태 모니터링

실시간 경로에서는 Amazon Kinesis Data Streams 입력부터 Apache Flink 소비자까지, Flink 소비자부터 Sink까지, Flink Sink부터 Amazon SageMaker Feature Store까지의 지연을 각각 밀리초 단위로 측정하고 전체 구간 지연도 함께 추적한다. Amazon Managed Service for Apache Flink의 상태를 확인하기 위해 사용 시간, Kinesis Processing Unit 사용량, 마지막 체크포인트 지속 시간, CPU·메모리 사용률과 백프레셔 시간을 관찰한다. Amazon SageMaker Feature Store에서는 GET·PUT 요청량, 읽기·쓰기 지연, 타임아웃 비율과 레코드 출력 크기를 측정해 저장소의 성능과 안정성을 확인한다. 오프라인 경로에서는 Amazon Data Firehose의 입력 레코드 수, Put Records 배치 지연, Amazon S3 전달 레코드 수, 데이터 신선도와 전달 성공 여부를 추적한다. 이러한 단계별 측정은 어느 구간에서 지연이나 장애가 발생했는지 구분하고, 피처 저장소의 조용한 성능 저하가 모델 예측에 영향을 주는 상황을 방지하기 위한 운영 기반이다.

7. 기술 선택의 장단점

Amazon SageMaker Feature Store는 ML 피처에 특화된 관리형 서비스이므로 인프라 운영 부담을 줄이고 모델 개발에 집중할 수 있으며, 인메모리 저장소와 표준 저장소를 함께 제공한다는 장점이 있다. 반면 저장 계층을 적절히 최적화하지 않으면 비용이 문제가 될 수 있으므로, 핫 데이터와 콜드 데이터를 구분하는 설계가 중요하다. Apache Flink는 대량 스트리밍과 복잡한 이벤트 논리를 처리해 트래픽 급증 중에도 빠른 사기 탐지를 지원하지만, 배치 처리 프레임워크보다 학습 곡선이 높고 애플리케이션 운영도 복잡하다. Amazon Kinesis, Amazon S3, Amazon Data Firehose, AWS Lambda, Amazon EMR Serverless, AWS Glue Data Catalog와 AWS Lake Formation을 조합하면 높은 확장성·신뢰성·보안 기능을 얻을 수 있지만, 서비스 간 통합과 최적 설정 및 비용 관리에는 깊은 AWS 전문성이 필요하다.

8. 측정 결과, 비용 효과와 운영 원칙

측정된 응답 지연은 P95 16.9ms로 Jumio의 sub-100ms 사기 탐지 SLA를 충족했으며, 읽기 지연은 P50 8.44ms, 쓰기 지연은 P50 18.6ms로 나타났다. 현재 구조는 팀별로 분산됐던 피처 정의를 중앙화하고 수주가 걸리던 수작업 운영 구현을 자동화된 통합 배포로 대체했으며, 과거에 제한적이었던 상위 모델 출력에도 실시간으로 접근할 수 있게 했다. Amazon SageMaker Feature Store의 인메모리 저장소를 최적화한 결과 기존의 분산 피처 저장소와 비교해 Jumio 워크로드 기준 연간 약 12만 달러의 운영비가 절감됐다. 구현 경험에서 도출한 다섯 원칙은 스트리밍 우선 설계, 중앙화된 피처 정의, 인메모리·표준 저장소의 계층화, 지연과 상태의 지속적 모니터링, 백엔드·ML·데이터 엔지니어링 팀의 협업이다. 이 구조는 모델 개발 가속, 정의 일관성에 따른 정확도 개선, 운영비 절감, 더 빠르고 안정적인 신원 확인, 새로운 피처 배포 민첩성을 제공하며 저지연 예측이 필요한 사기 탐지와 추천 등의 사례에 적용 가능한 패턴으로 제시됐다.

🧾 핵심 주장 / 시사점

• Jumio 사례에서 피처 저장소의 핵심 가치는 단순한 데이터 저장보다 피처 정의, 실시간 변환, 오프라인 학습 데이터와 운영 배포를 하나의 일관된 흐름으로 연결한 데 있다.
• Amazon SageMaker Feature Store의 인메모리·표준 계층과 Iceberg 오프라인 저장을 병행한 구조는 sub-100ms 추론, 장기 이력 보존, 재학습과 비용 최적화가 서로 다른 저장 전략을 요구한다는 점을 보여준다.
• P95 16.9ms와 연간 약 12만 달러 절감은 구조의 성과를 수치로 입증하지만, Apache Flink의 학습·운영 난도와 여러 AWS 서비스의 통합 복잡성은 별도로 관리해야 할 상충 요소다.

✅ 액션 아이템

• Amazon Kinesis와 Apache Flink를 연결하는 스트리밍 우선 실시간 피처 경로의 적용 가능성 검토.
• Amazon SageMaker Feature Store의 인메모리·표준 계층과 Iceberg 오프라인 저장을 기준으로 sub-100ms·재학습·비용 요구 간 균형 평가.
• P95 16.9ms, P50 읽기 8.44ms, P50 쓰기 18.6ms와 연간 약 12만 달러 절감치를 성능·비용 비교 기준으로 활용.

❓ 열린 질문

• Amazon SageMaker Feature Store는 피처 요청량과 카탈로그가 증가해도 sub-100ms 제약을 안정적으로 유지할 수 있는가?
• Apache Flink와 Iceberg의 병렬 경로는 수주 뒤 도착하는 이벤트에도 실시간·오프라인 피처의 일관성을 어떻게 유지하는가?
• 연간 약 12만 달러의 절감 효과는 여러 AWS 서비스의 통합 복잡성과 전문성 요구를 감안해도 다른 워크로드에서 유지되는가?