AWSはエンドポイント更新時の登録解除と再登録を自動化する構成を示しました。手動解除後に設定が戻らない問題や、ロールバック失敗を扱います。 推論基盤の更新成功だけでは運用機能の復旧を保証できません。依存順序と更新後のスケーリング状態を確認することが焦点です。 推論エンドポイントの更新で起きる管理のずれ AWSは10月23日、SageMaker AIのエンドポイントと自動スケーリングをCDKで更新する手法を公開しました。インスタンス種別などを変更する際は、先にスケーリング対象の登録解除が必要です。しかし手動で解除すると、CloudFormationが管理する定義と実態がずれることがあります。再配布に成功しても自動スケーリングが戻らない場合や、存在しないリソースの更新で失敗する場合を説明しています。後者はロールバックも失敗し、手動の復旧が必要になる可能性があります。記事は、この依存関係を再利用できるCDKの部品へまとめます。推論モデルの機能追加ではなく、継続的な更新を安定して行うための運用上の実装資料です。 3つのカスタムリソースで順番を制御 構成では、通常のスケーリング対象と方針の定義を3つのカスタムリソースへ置き換えます。更新前に対象を解除し、CDKがエンドポイントを更新した後、稼働状態を待って再登録します。その登録が参照可能になってから方針を適用します。CDKの依存関係を明示することで順序を保証します。設定の変更をハッシュ値で検知し、エンドポイントかスケーリングの値が変われば処理全体を動かします。非同期の完了確認には、CDKの仕組みが生成するLambdaとStep Functionsも使います。実際の配布物はカスタムリソースだけではない点に注意が必要です。リアルタイム推論をIaCで管理し、インスタンスや環境変数を定期的に更新するチームに関係します。既存スタックへの取り込みと検証方法も示しています。 成功の判定をスケーリング復旧まで広げる 導入時は、スタックの配布が成功したかだけでなく、対象と方針が復旧したかを確認することが論点になります。更新中に自動調整が外れる時間や、失敗時にどこまで戻るかも試す必要があります。追加される関数や状態機械には権限、ログ、運用上の費用が伴います。部品を取り込む前に、自社の管理方式と衝突しないかを確認する進め方が考えられます。設定ハッシュへ必要な値を含めないと、変更があっても再処理が起きない可能性があります。担当者が手作業で回避策を行った場合の復旧手順も残すべきです。記事は参照実装であり、既存の構成すべてを自動修復するサービスではありません。試験用のエンドポイントで、通常更新と故障時の状態を観察し、本番の変更手順へ組み込むことが安全な運用につながると見られます。登録状態の確認は、更新のたびに繰り返す必要があります。