Amazon SageMaker Feature Store introduces UpdateRecord for feature-level writes

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon SageMaker Feature Store의 UpdateRecord는 기존 레코드의 일부 피처를 원자적으로 갱신해 전체 레코드 읽기·재쓰기 부담을 줄이며, Standard 티어에서는 Standard_V2가 필요하다.

📌 핵심 요약

• 기존에는 피처 하나를 바꾸더라도 GetRecord로 전체 레코드를 읽고 값을 병합한 뒤 PutRecord로 다시 써야 했다. 이 과정은 지연과 Read Capacity Units(RCUs) 비용을 늘리고, 여러 파이프라인이 서로 다른 피처를 갱신할 때 다른 변경을 덮어쓰는 lost-update 문제를 일으킬 수 있었다.
• UpdateRecord는 요청에 포함된 피처만 기존 레코드에 원자적으로 병합하고 나머지 피처는 보존한다. 온라인 스토어에는 변경된 피처를 쓰며, 오프라인 스토어에는 전체 레코드 스냅샷을 자동 복제한다.
• UpdateRecord는 이미 존재하는 레코드만 갱신하며 upsert가 아니다. 호출당 최대 100개 피처를 지정할 수 있고, 선택적인 TtlDuration을 제공하려면 EventTime도 포함해야 한다. 오래된 EventTime은 HTTP 409로 거부되지만, 동일 시각의 허용 여부는 원문에서 ‘기존보다 이후’와 ‘기존과 같거나 이후’로 다르게 설명된다.
• Amazon DynamoDB 기반 Standard 티어는 피처 단위 쓰기를 위해 Standard_V2 형식이 필요하다. Amazon ElastiCache 기반 In-Memory 티어는 기존 피처 그룹에서도 별도 저장 형식 변경 없이 지원한다.
• 기존 Standard 피처 그룹은 Feature Processor SDK로 새 Standard_V2 그룹에 일괄 이전하거나 UpdateFeatureGroup으로 제자리 전환할 수 있다. 원문은 중단 없이 실제 쓰기가 발생한 레코드에만 이전 비용을 부과하는 제자리 전환을 대체로 권장하지만, 이 전환은 되돌릴 수 없다. IAM의 sagemaker:IsUpdateRecord와 sagemaker:UpdatableFeatures는 부분 갱신 구분과 갱신 가능한 피처 제한을 지원한다.

🧩 주요 포인트

1. 원자적 부분 병합과 전체 스냅샷 복제 → 여러 생산자가 같은 엔터티의 서로 다른 피처를 갱신하면서 온라인 변경과 오프라인 학습 데이터의 연결을 유지할 수 있다.
2. 기존 레코드·최대 100개 피처·EventTime 및 TtlDuration 제약 → 호출 조건과 시간 순서 처리의 이해가 필요하며, 동일 EventTime 허용 여부는 원문의 상충 설명 때문에 추가 확인이 필요하다.
3. Standard_V2의 비가역적 제자리 전환과 IAM 피처 제한 → 이전 방식은 중단·비용·복구 필요에 따라 선택하고, 생산자별 갱신 권한은 피처 수준으로 제한할 수 있다.

🧠 상세 정리

1. 전체 레코드 갱신 방식의 부담

Amazon SageMaker Feature Store는 모델 학습과 예측에 쓰이는 가공 데이터인 ML 피처를 저장·공유·관리하는 완전관리형 저장소이며, Feature Group은 하나 이상의 모델이 사용하는 관련 피처의 논리적 묶음이다. 기존에는 사기 점수 파이프라인이 고객의 risk_score 하나만 바꾸려 해도 GetRecord로 모든 피처를 읽고, 애플리케이션에서 새 값을 병합한 다음, PutRecord로 전체 레코드를 다시 써야 했다. 이 읽기·수정·쓰기 과정은 갱신 지연과 불필요한 읽기 용량 사용을 늘렸고, 여러 파이프라인이 같은 레코드의 서로 다른 피처를 동시에 갱신하면 한쪽 쓰기가 다른 쪽 변경을 조용히 덮어쓸 수 있었다. 원문은 이를 전형적인 lost-update 문제로 설명하며, 피처가 많은 그룹을 높은 빈도로 갱신하는 환경에서는 매번 추가되는 GetRecord의 Read Capacity Units(RCUs) 비용도 빠르게 누적된다고 지적한다.

2. UpdateRecord의 원자적 병합과 저장 흐름

UpdateRecord는 변경하려는 피처만 전달하면 서비스가 기존 레코드에 원자적으로 병합하는 API로, 요청에 포함되지 않은 피처는 그대로 보존한다. 클라이언트가 부분 갱신 요청을 보내면 Feature Store는 AWS Identity and Access Management(IAM) 권한을 검증하고, EventTime 순서를 확인해 오래된 쓰기를 거부한 뒤 병합을 수행한다. 온라인 스토어에는 변경된 피처만 단일 작업으로 기록하고, 동시에 전체 레코드 스냅샷을 오프라인 스토어에 자동 복제해 학습 데이터의 정확성을 유지한다. 원문은 클릭스트림·구매·점수 계산 파이프라인이 같은 레코드에서 각자 담당하는 피처를 독립적으로 쓸 수 있으며, 이러한 서로 다른 피처 갱신에는 파이프라인 사이의 조정이 필요하지 않다고 설명한다.

3. 요청 구성과 기존 레코드 제약

요청은 POST /FeatureGroup/{FeatureGroupName}/Record 형태이며, FeatureGroupName으로 대상 그룹을 지정하고 RecordIdentifierValueAsString으로 갱신할 레코드의 기본 키를 전달한다. 대상 레코드는 이미 존재해야 하므로 UpdateRecord는 없는 레코드를 생성하는 upsert가 아니며, Features에는 설정할 피처 값을 하나 이상, 호출당 최대 100개까지 넣을 수 있다. 원문의 예시는 user_123 레코드에 risk_score 값 0.87과 last_login 값 2026-07-21T08:15:00Z를 전달하고, 선택 항목인 TtlDuration으로 30일을 지정하는 요청을 제시한다. TtlDuration은 레코드별 TTL을 설정하거나 덮어쓰는 데 사용하지만 이를 제공할 때는 EventTime도 포함해야 하므로, 예시 코드만으로는 그 추가 조건까지 충족한 요청을 확인할 수 없다. 요청 설명에서는 EventTime을 Features에 넣어 갱신할 수 있고 기존 시각보다 이후여야 하며, 그렇지 않으면 전체 호출이 HTTP 409로 거부된다고 서술한다.

4. Standard_V2 도입과 티어별 지원 조건

Feature Store의 온라인 스토어는 Amazon DynamoDB를 사용하는 Standard 티어와 Amazon ElastiCache(Redis OSS)를 사용하는 In-Memory 티어를 제공해 왔다. 새로 도입된 Standard_V2는 Standard 티어의 다른 직렬화 형식으로, 피처 단위 쓰기 같은 추가 기능을 지원하며 Standard 티어에서 UpdateRecord를 사용하려면 이 형식이 필요하다. 신규 피처 그룹은 생성 시 OnlineStoreConfig의 EnableOnlineStore를 True로 설정하고 StorageType을 Standard_V2로 지정해 해당 형식을 선택할 수 있다. 원문의 생성 예시는 user-profile-fg에 user_id, event_time, risk_score, last_login, balance를 정의하며, 레코드 식별자와 이벤트 시간에 사용할 피처도 지정한다. 반면 In-Memory 티어에는 새로운 저장 형식이 필요하지 않으며, 기존의 모든 In-Memory 피처 그룹에서 피처 단위 쓰기를 바로 사용할 수 있다고 설명한다.

5. 기존 Standard 그룹의 두 가지 이전 전략

기존 Standard 피처 그룹을 Standard_V2로 이전할 때는 중단 민감도, 이전 시점의 통제 필요, 되돌리기 가능성을 기준으로 두 전략을 선택할 수 있다. 전략 A는 Feature Processor SDK로 기존 그룹의 레코드를 읽어 새 Standard_V2 그룹에 다시 적재하는 방식으로, 기존 그룹을 유지하므로 이전 시점을 통제하고 옛 그룹으로 되돌아가기 쉽다. 다만 관리형 이전 작업이 필요하고 전체 데이터의 읽기·쓰기 비용을 먼저 부담해야 하며, 애플리케이션 클라이언트가 새 피처 그룹 이름을 사용하도록 바꿔야 한다. 전략 B는 UpdateFeatureGroup에서 OnlineStoreConfig.StorageType을 Standard_V2로 지정해 기존 그룹을 제자리 전환하고, 이후 PutRecord 또는 BatchWriteRecord가 기록하는 레코드의 내부 형식을 바꾼다. 원문은 이 방식이 중단 없이 진행되고 실제로 쓰기가 발생한 레코드에만 이전 비용이 부과되며, 그룹 이름과 API 엔드포인트가 유지돼 기존 애플리케이션 코드를 보존한다고 설명한다. 그러나 제자리 전환은 되돌릴 수 없고 다시 쓰이지 않는 레코드는 기존 형식에 남으므로, 대체로 전략 B를 권장하면서 완전히 되돌릴 수 있는 이전이나 그룹 이름·구조 변경이 필요한 경우에는 전략 A를 제안한다.

6. EventTime 순서 보장과 설명의 불일치

원문은 UpdateRecord가 PutRecord와 같은 EventTime 기반 순서 처리를 지원해, 오래되거나 순서가 뒤바뀐 이벤트가 더 최신 데이터를 덮어쓰는 것을 막는다고 설명한다. 별도의 EventTime 절에서는 요청 시각이 현재 레코드의 EventTime과 같거나 이후이면 갱신을 적용하고, 이전이면 409 ConflictException으로 거부한다고 서술한다. 이는 앞선 요청 설명에서 기존 EventTime보다 반드시 이후여야 한다고 한 내용과 동일 시각의 처리 조건이 일치하지 않으므로, 제공된 자료만으로 어느 조건이 정확한지 확정할 수 없다. EventTime을 생략한 요청은 기존 EventTime을 유지하면서 새 피처 변경을 적용한다고 설명하며, 원문은 이를 서로 다른 피처를 담당하고 하나의 이벤트 시계를 공유하지 않는 다중 파이프라인 구조에 적합한 방식으로 제시한다.

7. 스트리밍 갱신·신규 피처 채우기·오류 수정

스트리밍 피처 갱신 사례에서는 클릭스트림 파이프라인이 몇 초마다 page_views와 session_duration을 보내고, 야간 배치 파이프라인이 lifetime_value와 customer_segment를 갱신한다. UpdateRecord를 사용하면 각 파이프라인이 담당하는 피처만 같은 핵심 레코드에 제출할 수 있어, 원문은 조정이나 변경 손실 없이 서로 다른 갱신 주기를 처리할 수 있다고 설명한다. 신규 피처 채우기 사례는 기존 피처 그룹의 기반 테이블 스키마에 preferred_language와 notification_opt_in을 추가한 뒤, 전체 레코드를 다시 쓰는 대신 새 필드 값만 전달해 기존 피처 값을 보존하는 방식이다. 대규모 오류 수정 사례에서는 데이터 품질 작업이 50,000개 레코드의 customer_segment가 잘못 분류됐음을 발견한 상황을 제시한다. 이 경우 UpdateRecord로 각 레코드의 해당 필드만 수정해 다른 피처 값을 훼손할 위험 없이 수천 개 레코드에 걸친 정정을 수행할 수 있다고 설명한다.

8. 고빈도 갱신과 다중 생산자 엔터티 모델

고빈도 갱신 사례에서 사기 탐지 시스템은 카드 결제가 발생할 때마다 transaction_velocity를 받으며, UpdateRecord는 바뀐 단일 피처만 기록해 대규모 환경의 전체 레코드 쓰기 부담을 없애는 방식으로 제시된다. 기업 규모의 다중 생산자 사례에서는 고객·보험 계약·차량 같은 비즈니스 엔터티 유형마다 하나의 피처 그룹을 두고, 수백만 레코드와 수백 개 피처를 여러 팀이 함께 관리한다. 배치 ETL 작업, 스트리밍 분석, 실시간 점수 계산 엔진이 같은 레코드에 기여하는 기존 방식에서는 각 생산자가 전체 레코드를 읽고 자신의 값을 넣어 다시 쓰면서 압축 작업, 경쟁 조건, 월별 읽기·쓰기 비용이 발생한다. 원문은 UpdateRecord로 각 생산자가 자기 피처만 원자적으로 기록하면 이러한 전체 레코드 병합 부담을 줄이고, 별도의 사용자 정의 압축 솔루션도 필요 없어진다고 주장한다.

9. IAM을 통한 피처별 갱신 권한

UpdateRecord는 IAM과 통합되며, 원문은 누가 어떤 피처를 갱신할 수 있는지 제어하기 위한 두 가지 새 조건 키를 소개한다. Bool 형식인 sagemaker:IsUpdateRecord는 부분 갱신 작업과 전체 PutRecord 쓰기를 구분하고, ArrayOfString 형식인 sagemaker:UpdatableFeatures는 주체가 갱신할 수 있는 피처 이름을 제한한다. 제시된 정책 예시는 user-profile-fg 리소스에 대한 sagemaker:PutRecord 동작을 허용하되, sagemaker:IsUpdateRecord가 true이고 갱신 피처가 age, score, last_activity 범위에 속하도록 ForAllValues:StringEquals 조건을 설정한다. 원문은 이를 비민감 피처만 갱신하도록 허용하는 예시로 제시하지만, 정책 이후의 설명 문장이 중간에서 끊겨 있어 그 뒤에 이어질 추가 조건이나 설명은 확인할 수 없다.

🧾 핵심 주장 / 시사점

• UpdateRecord의 핵심 효과는 쓰기 요청의 크기뿐 아니라, 서로 다른 피처를 담당하는 생산자들이 전체 레코드의 읽기·병합·재쓰기를 공유하면서 생기던 변경 손실 문제를 줄이는 데 있다.
• Standard_V2의 제자리 전환은 중단과 초기 이전 비용 부담을 줄이지만, 되돌릴 수 없고 다시 쓰이지 않는 레코드는 기존 형식에 남는다는 점에서 일괄 이전과 다른 선택 기준을 갖는다.
• EventTime을 생략하면 공통 이벤트 시계가 없는 파이프라인도 기존 시각을 유지하며 피처를 갱신할 수 있지만, EventTime을 제공하는 경우 동일 시각의 허용 여부는 원문의 상충 설명으로 인해 확정하기 어렵다.

✅ 액션 아이템

• Standard_V2 이전 방식은 중단·비용·되돌리기 필요를 기준으로 Feature Processor SDK와 UpdateFeatureGroup의 조건을 비교해 선택한다.
• UpdateRecord 적용 시 기존 레코드·최대 100개 피처·TtlDuration의 EventTime 요구를 반영하고, 동일 EventTime의 허용 여부를 확인한다.
• 생산자별 갱신 권한을 sagemaker:IsUpdateRecord와 sagemaker:UpdatableFeatures로 제한하는 방안을 검토한다.

❓ 열린 질문

• UpdateRecord는 기존 레코드와 동일한 EventTime을 제공한 갱신을 허용하는가?
• Standard_V2 이전에서 되돌리기 가능성이 필요한가, 아니면 중단 없는 UpdateFeatureGroup 제자리 전환을 선택할 수 있는가?
• 각 생산자가 갱신할 수 있는 피처를 sagemaker:UpdatableFeatures로 어떤 범위까지 제한할 것인가?