Amazon SageMaker Feature Store에 부분 업데이트 도입

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

Amazon SageMaker Feature Store에 추가된 UpdateRecord는 단일 feature를 바꾸기 위해 전체 레코드를 읽고 다시 쓰던 방식을 없애고, 요청에 담긴 feature만 기존 레코드에 원자적으로 병합합니다. 변경하지 않은 값은 그대로 유지되며 EventTime 순서 검사를 통해 오래된 요청을 HTTP 409로 거부하고, 온라인 저장소의 변경과 함께 오프라인 저장소에는 전체 레코드 스냅샷을 복제합니다. Standard 계층에서는 feature-level writes를 지원하는 Standard_V2가 필요하고, 기존 Standard Feature Group은 새 그룹으로 일괄 이전하거나 UpdateFeatureGroup으로 무중단 전환할 수 있습니다. 이 방식은 여러 파이프라인이 같은 레코드의 서로 다른 feature를 갱신하는 환경에서 추가 읽기 비용과 갱신 손실 위험을 줄이며, IAM 조건 키로 변경 가능한 feature 범위도 제한합니다.

섹션별 상세

기존 Amazon SageMaker Feature Store에서는 risk_score처럼 feature 하나만 바꾸려 해도 GetRecord로 전체 레코드를 읽고 애플리케이션에서 새 값을 병합한 뒤 PutRecord로 전체 내용을 다시 저장해야 했습니다. 이 read-modify-write 흐름은 업데이트마다 추가 읽기 지연과 RCU 사용을 발생시키고, 서로 다른 파이프라인이 동시에 저장하면 한쪽 변경이 다른 쪽 전체 레코드에 덮어써지는 갱신 손실을 만들 수 있었습니다. 특히 feature 수와 갱신 빈도가 큰 환경에서는 처리 비용과 동시성 문제가 함께 커졌습니다.

Amazon SageMaker Feature Store 서비스가 UpdateRecord로 변경된 feature만 Online Store에 원자적으로 기록하고, 전체 레코드 스냅샷을 Offline Store에 전달하는 흐름도입니다. — Diagram다이어그램은 Client App이 risk_score, page_views 같은 부분 feature를 UpdateRecord로 보내면 Feature Store 서비스가 IAM 검증과 EventTime 검사를 거쳐 변경된 값만 Online Store에 기록하는 구조를 보여줍니다. 동시에 Offline Store에는 전체 레코드 스냅샷이 추가되며, clickstream·purchases·scoring 파이프라인이 서로 조정하거나 잠금을 사용하지 않고 각자 담당 feature를 갱신하는 다중 파이프라인 구성이 표현되어 있습니다.

UpdateRecord는 변경하려는 feature만 요청으로 받아 기존 레코드에 원자적으로 병합하므로, 요청에 없는 값은 그대로 보존합니다. 서비스는 IAM 권한을 확인하고 EventTime 순서를 검사한 뒤 온라인 저장소에는 변경된 feature만 기록하며, 레코드가 이미 존재해야 하므로 생성 작업에는 PutRecord가 필요합니다. 한 번의 호출에 최대 100개 feature를 지정할 수 있어 clickstream, purchases, scoring처럼 서로 다른 파이프라인이 자신이 소유한 값만 같은 레코드에 기록할 수 있습니다.

json

POST /FeatureGroup/{FeatureGroupName}/Record {
  "RecordIdentifierValueAsString": "user_123",
  "Features": [
    {
      "FeatureName": "risk_score",
      "ValueAsString": "0.87"
    },
    {
      "FeatureName": "last_login",
      "ValueAsString": "2026-07-21T08:15:00Z"
    }
  ],
  "TtlDuration": { // optional
    "Unit": "Days",
    "Value": 30
  }
}

기존 레코드에서 risk_score와 last_login만 갱신하고 레코드별 TTL을 30일로 설정하는 UpdateRecord 요청입니다.

Standard 계층에서 feature-level writes를 사용하려면 기존 DynamoDB 기반 저장 형식과 별도인 Standard_V2를 Feature Group 생성 시 지정해야 합니다. 반면 Amazon ElastiCache 기반 In-Memory 계층은 새 저장 형식 없이 기존 Feature Group에서 기능을 사용할 수 있습니다. Standard_V2로 전환하는 방법은 Feature Processor SDK로 새 그룹에 전체 데이터를 옮기는 방식과 UpdateFeatureGroup으로 기존 그룹을 제자리에서 전환하는 방식이며, 후자는 무중단 상태에서 실제로 기록되는 레코드에 대해서만 이전 비용이 발생하지만 되돌릴 수 없습니다.

python

import boto3
sm = boto3.client("sagemaker")
sm.create_feature_group(
    FeatureGroupName="user-profile-fg",
    RecordIdentifierFeatureName="user_id",
    EventTimeFeatureName="event_time",
    OnlineStoreConfig={
        "EnableOnlineStore": True,
        "StorageType": "Standard_V2" # enables feature-level writes
    },
    FeatureDefinitions=[
        {"FeatureName": "user_id", "FeatureType": "String"},
        {"FeatureName": "event_time", "FeatureType": "String"},
        {"FeatureName": "risk_score", "FeatureType": "Fractional"},
        {"FeatureName": "last_login", "FeatureType": "String"},
        {"FeatureName": "balance", "FeatureType": "Fractional"},
    ],
)

Standard 계층에서 feature-level writes를 활성화한 Standard_V2 Feature Group을 생성합니다.

EventTime을 요청에 포함하면 기존 값보다 늦거나 같은 시각의 업데이트만 반영되고, 더 이른 값은 HTTP 409 ConflictException으로 거부됩니다. EventTime을 생략하면 기존 EventTime은 유지한 채 지정한 feature만 갱신할 수 있어 서로 다른 파이프라인이 하나의 이벤트 시계를 공유하지 않아도 됩니다. TtlDuration을 지정하려면 EventTime도 함께 보내야 하며, UpdateRecord는 upsert가 아니므로 대상 레코드가 먼저 생성되어 있어야 합니다.

python

import boto3
sm = boto3.client("sagemaker")
sm.update_feature_group(
    FeatureGroupName="my-existing-fg",
    OnlineStoreConfig={"StorageType": "Standard_V2"}
)

기존 Standard Feature Group의 온라인 저장 형식을 Standard_V2로 전환합니다.

UpdateRecord는 오프라인 저장소로 전체 레코드 스냅샷을 자동 복제해 학습 데이터와 이력 분석에 필요한 상태를 유지합니다. IAM의 sagemaker:IsUpdateRecord와 sagemaker:UpdatableFeatures 조건 키를 사용하면 부분 업데이트만 허용하면서 age, score, last_activity처럼 지정한 feature만 변경하게 만들 수 있고, 기존 PutRecord 거부 정책은 UpdateRecord도 함께 차단합니다. 따라서 새 feature를 수만 건의 레코드에 추가하거나 잘못 분류된 customer_segment를 보정하고, 카드 승인마다 transaction_velocity만 갱신하는 작업에서 전체 레코드 재작성과 사용자 정의 compaction을 줄일 수 있습니다.

용어 해설

읽기-수정-쓰기(Read-Modify-Write): — 기존 레코드를 먼저 읽은 뒤 애플리케이션에서 값을 병합하고 전체 레코드를 다시 저장하는 처리 방식입니다. 단일 필드만 바꿔도 전체 데이터를 읽고 쓰므로 지연과 읽기 용량 사용량이 늘어나며, 여러 파이프라인이 동시에 다른 필드를 갱신하면 한쪽 변경이 다른 쪽에 덮어써질 수 있습니다.
갱신 손실(Lost Update): — 동시에 수행된 두 변경 중 나중에 저장된 전체 레코드가 먼저 저장된 변경을 덮어써 결과적으로 한쪽 갱신이 사라지는 문제입니다. 각 작업이 최신 레코드를 읽고 전체 내용을 다시 쓰는 구조에서 발생하며, UpdateRecord의 원자적 부분 병합은 서로 다른 필드를 갱신하는 작업 간 충돌을 줄입니다.
EventTime 순서 보장(EventTime Ordering): — 레코드에 포함된 EventTime을 기준으로 최신 이벤트만 저장하는 처리 규칙입니다. 요청의 EventTime이 기존 값보다 이전이면 HTTP 409 ConflictException으로 전체 업데이트를 거부하고, 더 늦거나 같은 시간이면 변경을 반영해 오래된 이벤트가 최신 데이터를 덮어쓰는 일을 막습니다.
시간 기반 만료(TTL): — 레코드가 일정 시간이 지난 뒤 만료되도록 설정하는 보존 기간입니다. UpdateRecord에서는 TtlDuration으로 레코드별 TTL을 설정하거나 덮어쓸 수 있지만, 이 값을 요청에 포함하려면 EventTime도 함께 보내야 합니다.
IAM 조건 키(IAM Condition Key): — AWS Identity and Access Management 정책에서 요청의 속성을 기준으로 권한 범위를 세밀하게 제한하는 정책 조건입니다. sagemaker:IsUpdateRecord로 부분 업데이트 여부를 구분하고 sagemaker:UpdatableFeatures로 주체가 변경할 수 있는 feature 이름을 제한할 수 있습니다.

기술

Amazon SageMaker Feature Store
UpdateRecord
Amazon DynamoDB
Amazon ElastiCache
Redis OSS
Feature Processor SDK
boto3
AWS Identity and Access Management
UpdateFeatureGroup
PutRecord
GetRecord
BatchWriteRecord

활용 사례

실시간 clickstream과 야간 batch 파이프라인의 feature 병합
기존 Feature Group에 새 feature를 추가하는 backfilling
대규모 데이터 품질 오류 보정
카드 승인마다 transaction_velocity를 갱신하는 fraud detection
여러 팀과 ETL 작업이 하나의 기업 엔터티 Feature Group에 기록하는 다중 producer 구조
IAM으로 비민감 feature만 부분 업데이트

Amazon SageMaker Feature Store에 부분 업데이트 도입

TL;DR

섹션별 상세

용어 해설

기술

활용 사례

관련 토론

댓글

관련 기사

Jumio의 AWS 실시간 Feature Store 구축

MLflow 모델 등록과 SageMaker 거버넌스 자동화

SageMaker SDK v3로 모델 코드 바로 실행

Databricks Feature Store의 200ms 실시간 피처

SageMaker HyperPod에서 Ray 분산 작업 통합