AWS、SageMaker AIエンドポイント更新と自動スケーリングの連携をCDKで自動化する手法を公開

要点

• 米Amazon Web Services（AWS）は、Amazon SageMaker AIのリアルタイムエンドポイント構成を変更する際、オートスケーリングが原因でデプロイが失敗する課題の解決手法を解説した。

• 従来はエンドポイント更新前にスケーリング登録の解除が必要であり、手動対応を行うとCloudFormationの追跡不能やロールバック失敗によるスタック破損が生じていた。

• 今回示された手法では、AWS CDK（Cloud Development Kit）のカスタムリソースと依存関係制御を活用し、単一デプロイ内で登録解除・更新・再登録を一連のフローとして自動化する。

• 標準のオートスケーリングリソースを3つのカスタムリソースに置き換えることで、手動介入を行わずに安全なインフラ更新を実現できるとしている。

• 米Amazon Web Services（AWS）は2026年10月23日（現地時間）、機械学習プラットフォーム「Amazon SageMaker AI」において、推論エンドポイントの構成更新とオートスケーリングの再設定をAWS CDKで一括オーケストレーション（統合制御）する実装手法を同社公式MLブログで公開した。

• 同社によると、インフラをコードで管理するIaCツールを用いた際、エンドポイントの設定変更時に生じていたデプロイエラーやスタック破損を、CDKコンストラクトとカスタムリソースの組み合わせによって手動作業なしで解消できるという。

エンドポイント更新とオートスケーリングが引き起こすデプロイの課題

SageMaker AIのリアルタイムエンドポイントでは、運用中に利用するインスタンスタイプやインスタンス数、環境変数を変更するニーズが頻繁に生じる。しかし、AWS CloudFormation（インフラをテンプレートで定義・自動構築するサービス）やAWS CDK（一般的なプログラミング言語でクラウドインフラを定義できるフレームワーク）を経由してこれらを更新しようとすると、デプロイが途中で失敗する仕様上の制約が存在していた。

SageMaker AI側では、エンドポイント構成を更新する前に、AWS Application Auto Scalingのスケーラブルターゲット（スケーリングの対象として登録されたリソース設定）をあらかじめ登録解除しておく必要がある。一方で、ユーザーがスケーラブルターゲットを解除してしまうと、CloudFormation側はApplication Auto Scalingリソースの状態を正常に追跡できなくなるというジレンマを抱えていた。

手動対応時に生じる3つの障害パターン

公式ブログでは、この問題に対して手動で対処しようとした場合に発生する具体的な3つの失敗パターンが紹介されている。

1つ目は、オートスケーリングが登録された状態のままエンドポイント構成を変更してデプロイを試みるケースだ。CloudFormationが更新を開始した直後に、SageMaker AIが「スケーラブルターゲットを事前に登録解除する必要がある」というエラーを返し、CloudFormationがオートスケーリングリソースの処理に到達する前に更新全体が拒絶される。

2つ目は、管理者がAWS CLI（コマンドラインインターフェース）を用いて手動でターゲットを登録解除した後に、エンドポイント構成のみを変更して再デプロイを行うケースである。この場合、デプロイ処理自体は正常終了するものの、CloudFormationテンプレート上のスケーリング設定値に変更がないため、CloudFormationはターゲットの再登録やスケーリングポリシーの再適用を行わない。その結果、何のエラー通知もないまま、エンドポイントがオートスケーリングされない状態で稼働し続けるという潜在的な障害に陥る。

3つ目は、手動で登録解除した後に、オートスケーリングのパラメータも変更して再デプロイを行うケースだ。CloudFormationはすでに手動で削除されて存在しないScalableTargetリソースを更新しようとしてエラーを起こす。さらに、この失敗時には自動ロールバック処理も「UPDATE_ROLLBACK_FAILED」となって失敗し、CloudFormationスタックが破損状態のまま停止するため、復旧にはコンソールからの手動介入が必須になってしまうという。

CDKコンストラクトとカスタムリソースによる自動制御フロー

AWSはこれらの問題を抜本的に解決するため、再利用可能なCDKコンストラクトを用い、標準のCloudFormationリソース（AWS::ApplicationAutoScaling::ScalableTarget および AWS::ApplicationAutoScaling::ScalingPolicy）を3つのカスタムリソース（標準機能では対応できない処理を独自ロジックで実行する拡張リソース）へ置き換える設計を提示した。

この構成では、CDKの依存関係制御メソッドである node.add_dependency を活用し、エンドポイント更新の前後で登録解除と再登録を厳密な順序で実行させる。具体的な処理シーケンスは以下の3段階で構成される。

まず第1段階として、登録解除用のカスタムリソースがエンドポイント更新処理の開始前にスケーラブルターゲットを削除する。初回のデプロイ時にはターゲットがまだ存在しないが、ハンドラー側でエラーを安全に処理してデプロイを継続する設計となっている。

第2段階では、CDKの標準管理下でエンドポイントリソース本体の更新が行われ、新しいインスタンスタイプや設定への切り替えが安全に実行される。

最後に第3段階として、エンドポイントの準備完了を待機した上で、別のカスタムリソースがスケーラブルターゲットの再登録を行い、スケーリングポリシーを確実に再適用する。

このアプローチにより、開発者は1回のデプロイコマンドを実行するだけで、手動操作を一切挟むことなく、エンドポイントの構成変更とオートスケーリングの再設定を安全に完了できるようになるとしている。