【要約】SageMaker Feature StoreのBatchWriteRecordを実測 — 呼び出し25分の1で5.7倍高速 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者がSageMaker Feature Storeを用いて大量の特徴量を更新する際、従来のPutRecord APIでは以下の課題に直面していた。
- ・1リクエストにつき1レコードしか扱えず、API呼び出し回数が膨大になる。
- ・オンラインストアのレコードを一覧する手段がなく、棚卸しが困難である。
- ・In-Memory tierにおいて、識別子を別途管理しないと状態把握ができない。
// Approach
筆者が、新しく追加された2つのAPIの仕様と性能を、EC2環境を用いた実機検証によって明らかにした。
- ・BatchWriteRecordによる呼び出し回数、所要時間、消費WRUの比較。
- ・エラー発生時の挙動（部分成功、全件失敗、例外の有無）の分類。
- ・TTL（有効期限）の優先順位と、ExpiresAtの計算起点の検証。
- ・ListRecordsのページング性能と、並行更新時の整合性の確認。
// Result
実装者がBatchWriteRecordを採用することで、API呼び出し回数は25分の1に削減され、シリアル実行時の所要時間は5.7倍高速化した。
- ・API呼び出し回数：25分の1（400回 → 16回）に削減。
- ・所要時間（シリアル）：5.7倍高速（82.3%短縮）。
- ・課金（WRU）：変化なし（レコードサイズに依存するため）。
- ・損益分岐点：1リクエストあたり2レコード以上。
Senior Engineer Insight
> スループット向上には極めて有効だが、単純な置き換えは危険だ。特に「エラーがHTTP 200で返る」点や「型不正で全件失敗する」点は、既存の例外処理を無効化する。また、課金は減らないため、コスト削減目的の採用は誤りだ。監視設計（CloudWatchメトリクス）の変更も必須となる。並列化が難しいLambda等の環境では、実装を単純に保ったまま高い性能を得られるため、採用価値は高い。