SageMaker Auto Scalingが直面する、AWS CDKでオーケストレーションすべきデプロイ制約
AWSは、スケーリング登録が残った状態で失敗するエンドポイント更新に対応する、SageMaker自動スケーリングの回避策を公開した。このアプローチでは、クラウドインフラをコードで定義するフレームワークであるAWS CDKを用い、本来は手動介入を要する変更を連携させる。その意義は、望ましいインフラを宣言するだけでは、そこへ到達するために必要な手順を常に表現できるわけではないという隔たりを埋める点にある。
10月23日の投稿では、エンドポイント更新の前にスケーリング登録を一時的に解除し、その後に復元する再利用可能なコンストラクト、すなわちパッケージ化されたインフラコンポーネントを説明している。テンプレートからリソースをプロビジョニングするサービスであるAWS CloudFormationが、引き続きデプロイを担う。カスタムリソース、つまりアプリケーション固有のプロビジョニングロジックを実行する拡張機能が、その更新を前後する移行を処理する。
プラットフォームエンジニアにとって中心となる対立は、宣言型設定と運用上の手順制御の間にある。テンプレートはエンドポイントとスケーリング設定を正しく記述できても、両者の関係によって更新が妨げられる可能性がある。AWSの例はその関係をデプロイワークフローへ組み込むが、チームには依然として復旧、キャパシティ、責任分担を評価する必要がある。
SageMakerの自動スケーリングが、設定と実行の間の隔たりを浮き彫りにする
この変更は、SageMakerにおける根本的な更新制約の撤廃ではなく、公開されたオーケストレーションパターンである。
AWSのコンサルタントであるLauren Eterno氏は、endpoint update constructでこのアプローチを説明している。これは、エンドポイント変更の前後にカスタムのプロビジョニング手順を配置することで、ネイティブのスケーリングリソースを置き換えるものだ。AWSによれば、これによりエンドポイント設定とスケーリングパラメータを単一のデプロイ内で変更できる。
この違いは重要である。スケーリングがエンドポイント更新を妨げるという一般論には補足が必要だからだ。SageMakerのendpoint update rulesでは、モデルが登録されたままの場合に失敗するケースとして、インスタンスタイプの変更を明示している。一方、すでにスケーリング用に設定されているバリアントのモデル変更は認められている。バリアントとは、エンドポイント内のモデル提供設定を指す。
この例外により、この発表を過度に広く解釈することは避けられる。すべてのモデルリリースでスケーリング登録を解除する必要があると、チームは想定すべきではない。問うべきなのは、どのリソースプロパティが変わるのか、またその変更が文書化された制約に抵触するかどうかである。デプロイ戦略も、その区別に従うべきだ。
たとえば、あるレコメンデーションサービスがモデルを別のインスタンスタイプへ移行する仮想的なケースを考えてみよう。モデル自体は変わらないかもしれないが、インフラ更新はスケーリング登録によって保護された境界をまたぐ。新しいエンドポイント設定だけを確認するエンジニアは、この前提条件を見落とす可能性がある。
したがって、この例が扱うのはライフサイクルの問題、すなわちリソースの作成、更新、削除に必要な順序付きの移行である。別のスケーリングアルゴリズムを導入するものではない。その価値は、デプロイプロセスが前提条件を理解できるよう、既存の操作を調整する点にある。
これは、このニュースを評価する際に有用な境界線となる。新しいコンストラクトは、インフラ変更を再現可能かつ復旧可能にするかどうかで判断すべきだ。推論品質の向上、モデル実行の高速化、スケーリング効率の改善といった主張には、別途証拠が必要となる。
この公開は、独自の回避策を保守するチームにとって具体的なレビュー対象も生む。エラーメッセージだけから推論するのではなく、AWSが作成した参照実装と自らのスクリプトを比較できる。ただし、それによって参照実装があらゆる本番環境に自動的に適するわけではない。
直近の影響を受けるのは、有効なテンプレートが有効な更新経路を保証すると想定しているリリースプロセスを持つチームだ。この例は、経路自体もレビューに値する理由を示している。望ましい状態と移行時の振る舞いは、同じエンジニアリング上の議論に含める必要がある。
プラットフォームチームは手動介入の結果を引き継ぐ
意図したスケーリング動作が復元されていなければ、エンドポイント変更が成功していても不完全である。
最も大きな運用上の懸念は、インフラ設定と実行時の振る舞いとの隔たりにある。エンドポイントはリクエストに応答できても、所有者が期待するスケーリング構成を欠いている可能性がある。アプリケーションの応答だけに焦点を当てたリリースレビューでは、インフラが需要変動に備えられていることを確認できない。
AWSは、手動での登録解除により、スケーリングが存在しないままになるか、その後のリソース更新が失敗するシナリオを説明している。これらの例は異なる問題を示す。目に見えるデプロイ失敗には即座の対応が求められる一方、スケーリングの欠落は、アプリケーションが依然として応答するかを中心にしたレビューでは見逃される可能性がある。
オンコール担当のエンジニアはいずれの場合でもその結果を引き継ぐ。どの変更が完了し、どのリソースが存在し、次のデプロイで何が試行されるのかを誰かが判断しなければならない。共有記録がなければ、復旧プロセスは通常のリリースワークフロー外で実行された操作を再構築することに依存する。
プラットフォームチームにとって、これはツールの問題であると同時に責任分担の問題でもある。アプリケーション開発者はモデルの振る舞いを担い、インフラエンジニアはデプロイ制御を担う場合がある。両方にまたがるワークフローには、どちらのグループだけでも満たせない、明確な完了の定義が必要となる。
その定義には、提供設定と意図されたキャパシティ制御を含めるべきだ。また、登録とポリシーの関連付けを区別する必要もある。キャパシティを変更できるよう登録されたリソースであるスケーラブルターゲットと、そのスケーリングポリシーは、最終状態を構成する関連しつつも別個の要素である。
実務上の含意は、より広範なリリース受け入れ確認である。チームは、エンドポイントが意図した設定を使用していることと、そのキャパシティ制御が承認済みの変更と一致していることを確認すべきだ。アプリケーションの健全性は引き続き必要だが、それは別の問いに答えるものである。
これは、ハードウェア変更に改訂されたスケーリング設定が伴う場合に特に重要となる。その場合、リリースはリクエストの実行方法と、その後のキャパシティの応答方法の両方を変更する。いずれかを単独でレビューすると、その相互作用は検証されないままとなる。
再利用可能なコンポーネントは、この責任を集約できる。すべてのアプリケーションチームに手順を覚えさせるのではなく、プラットフォームチームが共通実装を保守できる。その利点は、明確な責任者と文書化された復旧プロセスを備えた、保守対象のインフラとしてコンポーネントを扱うことにかかっている。
ドキュメントには、コマンドだけでなく意思決定も残す必要がある。後のインシデントを調査するエンジニアは、一時的な登録解除がなぜ存在するのか、どの前提がそれを正当化するのかを知る必要がある。検索可能なengineering knowledge baseは、そうした判断をデプロイ証跡とともに保持できる。
ビジネス上の含意は、リリースの予測可能性にある。定期的に専門家の介入を必要とするインフラ変更は、影響を受けるデプロイごとに調整作業を課す。その手順をコードへ取り込むことは、その作業を減らす方法となり得る。ただし、障害が運用担当者にとって理解可能であり続けることが前提だ。
この留保は、有用な自動化と隠れた複雑性を分ける。目標は、自らの状態を明確に説明できるデプロイであるべきだ。手動コマンドを関数へ移すだけでは、その結果は保証されない。
コンストラクトが順序と準備完了を明示する
この仕組みは、順序付けられた依存関係の連鎖と、各前提条件が実際に利用可能になったことを確認するチェックを組み合わせる。
sample implementationは、定義された順序に従う。すなわち、スケーリングの登録解除、エンドポイント更新、ターゲット登録、ポリシーの関連付けである。登録段階では、エンドポイントが準備完了の稼働状態であるInServiceに到達するまで待機する。ポリシー段階では、登録済みターゲットを照会できるようになるまで待機する。
これらのチェックは異なる境界に対応している。エンドポイントは登録の準備ができている必要があり、登録はポリシーを関連付ける前に可視化されなければならない。受理されたリクエストがあればすべての依存操作を進められると仮定するよりも、これらの条件を分けて扱う方がワークフローを確認しやすい。
サポート対象リソースのキャパシティを調整するAWSのサービスであるApplication Auto Scalingも、この可視性の隔たりを文書化している。同サービスの登録APIは、結果整合性、すなわち成功した変更が後続のリクエストに現れるまで時間がかかる可能性について警告している。そのため、準備完了の確認は文書化された挙動への対応となる。
このサンプルは、操作の開始と完了確認を分離するパターンである非同期完了を採用している。CDKプロバイダーフレームワークは、成功するかタイムアウトに達するまで、完了ハンドラーを繰り返し呼び出す。これにより、待機全体を単一の関数呼び出しに縛らずに済む。
参照実装では、30秒ごとにチェックを行うよう設定している。ターゲット登録には最大1時間、ポリシーの関連付けには15分を許容する。これらの値は実装における待機上限を示すものであり、約束されたデプロイ所要時間や、一般的な本番環境の性能に関する証拠ではない。
設定トリガーも同様に重要である。関連する設定を表す値であるConfigHashプロパティは、エンドポイントまたはスケーリング設定が変わると変化する。これによりCloudFormationには処理すべき変更済みカスタムリソースプロパティが渡され、オーケストレーションが更新に再び組み込まれる。
ここで、このパターンは依存関係の順序付けを超える。順序ルールだけでは、変更のないカスタムリソースが再実行されるわけではない。ワークフローには、実行する理由と、実行開始後に強制される順序の両方が必要となる。
より広範なCDKの挙動は、custom resource frameworkに示されている。CloudFormationはプロバイダーにライフサイクルイベントを送信し、このフレームワークは時間を要する操作に対する完了チェックをサポートする。また、ハンドラーでエラーが発生した場合や待機期間が満了した場合には、失敗も報告する。
レビュー担当者にとって、これらは別々の責務である。設定トリガーは、いつ作業が必要かを決める。依存関係は、いつ作業を開始できるかを決める。完了チェックは、いつ後続の作業を進められるかを決める。その後、復旧ロジックは、これらの境界の間で進行が止まった場合に何が起こるかを扱う必要がある。
その結果として得られる設計は、リクエストを順に送信し、即時に準備が整うと仮定するデプロイスクリプトよりも明示的である。ただし、明示性を正しさの証明と混同すべきではない。参照実装は、チームが自らの運用要件に照らして評価できる、検証可能な仕組みを提供する。
マネージド推論でもデプロイの調整責任は運用者に残る
より広い比較が扱うのは、どのベンダーが自動スケーリングを提供するかではなく、プラットフォームがライフサイクル責任をどのように公開するかである。
Google Cloudも、デプロイ済み予測モデル向けの設定可能なスケーリングを文書化している。inference autoscaling settingsには、モデルを提供する実行中のコピーであるレプリカの最小数と最大数が含まれる。このドキュメントは、サポート対象の構成において、デプロイの成功と完全なキャパシティ準備完了も区別している。
この比較は、ベンダーの優劣を示すことなく文脈を提供するものです。設定が似ているからといって、更新制限、障害処理、デプロイのセマンティクスが同一であることを意味しません。AWSの例は、別のプラットフォームがあらゆる類似の調整問題を回避できると主張する根拠にはなりません。
エンタープライズの購入担当者にとって、有用な比較はスケーリングの有無にとどまりません。ハードウェアの変更がキャパシティ制御にどう影響するか、準備完了状態がどのように報告されるか、障害後に誰が設定を復元するかを確認すべきです。こうした問いは、製品の機能とそれを運用するために必要な作業を結び付けます。
同じ区別はAWS環境内にも当てはまります。CDKでインフラストラクチャを定義すれば、開発者にはプログラミングインターフェースが提供されますが、結果として行われるデプロイはCloudFormationの挙動に従います。リソースを記述するための言語は、サービスレベルの前提条件をなくすものではありません。
このため、この例は特定の実装を超えて注目に値します。インフラストラクチャコードの中で、運用上の依存関係を可視化しているからです。これにより、そうでなければリリースノート、スクリプト、個人の経験に分散したままとなり得る一連の手順を、レビュー担当者が確認できる場所が生まれます。
また、更新可用性とスケーリング可用性の間には境界があります。SageMakerのエンドポイント更新APIは、以前のフリートを廃止しながら新しいフリートへトラフィックを移行することを説明しています。このサービング移行自体は、意図したスケーリングポリシーが復元されたことを示すものではありません。
したがって、チームはリクエストのサービングとキャパシティ管理について、それぞれ別の受け入れ条件を定義できます。アプリケーションは変更を通じて正常な状態を維持すべきであり、デプロイは意図したスケーリング制御が存在する状態で完了すべきです。どちらの条件も、もう一方の代わりにはなりません。
この分離はインシデント分析も改善します。リクエストが失敗した場合、エンジニアはサービング移行を調査できます。キャパシティが需要に追従しなくなった場合は、スケーリング状態を確認できます。こうした結果を区別するデプロイ記録は、対応者により明確な出発点を与えます。
推論インフラストラクチャを標準化する組織にとっての選択は、この調整を共通コンポーネントに取り込むかどうかです。代替案は、同じライフサイクル上の境界を理解する責任を各チームに委ねることです。共有コンポーネントは一貫性をもたらす一方で、保守責任も集中させます。
このトレードオフには意図的なオーナーが必要です。誰かがコンポーネントの変更をレビューし、既存デプロイとの互換性を維持し、その前提が適合しなくなった時期を判断しなければなりません。再利用性が組織的な価値を生むのは、保守モデルも同様に再利用可能な場合に限られます。
登録解除により、復旧は設計の一部となる
ターゲットの復元は必要ですが、本番環境での受け入れでは、登録解除によって削除されるすべての要素を対象にしなければなりません。
deregistration APIでは、スケーラブルターゲットを削除すると、関連するスケーリングポリシーとスケジュールされたアクションも削除されると説明されています。スケジュールされたアクションは、指定した時刻に実施するよう設定されたキャパシティ変更です。このため、意図が一時的なものであっても、登録解除は破壊的なライフサイクル操作となります。
この挙動は、既存エンドポイントに関する即時の互換性の問いを生みます。組織がスケジュールされたアクションや追加ポリシーを使用している場合、レビュー担当者はそれらの設定がどのように戻るのかを確認すべきです。選択したメトリクス値に向けてキャパシティを調整するターゲット追跡ポリシーが存在しても、その問いへの答えにはなりません。
サンプルで文書化された手順は、ターゲットの登録と設定済みポリシーのアタッチに重点を置いています。チームは、エンドポイントにすでにアタッチされているすべてのスケーリング構成が検出され、再構築されると推測すべきではありません。より広範な復元要件には、明示的な調査と検証が必要です。
スケーリングの空白期間にも注意が必要です。登録を削除してもエンドポイント自体が削除されたことにはなりませんが、以前の自動キャパシティ制御は失われます。運用担当者は、その間にサービングフリートがどの程度の需要を処理する必要があるかを評価すべきです。
これはワークロード固有の評価です。安定した社内サービスと、予測不能な需要に直面する公開アプリケーションでは、受け入れ条件が異なります。このリファレンスは、いずれのケースについても許容可能な中断時間を裏付ける測定済みの証拠を示していません。
ハードウェア変更後のキャパシティ設定には、別途レビューが必要です。以前のポリシー設定を維持しても、それが異なるインスタンスタイプに引き続き適切であることは示されません。チームは、復元を運用上の成功と見なす前に、代表的な需要の下で得られる挙動を評価すべきです。
障害テストは移行の境界に従って行うべきです。レビュー担当者は、エンドポイント更新の失敗、登録の失敗、ポリシーアタッチの失敗を確認すべきです。それぞれが、実際の状態と復旧に必要なアクションについて異なる問いを残します。
ロールバック、すなわち障害後に以前の設定へ戻していくプロセスは、順方向のデプロイと同等の注意を要します。カスタムリソースは、そのハンドラーを通じてこのライフサイクルに参加します。その存在は、部分的に完了したすべての操作が確実にクリーンに元へ戻ることを保証するものではありません。
CDKのドキュメントでは、基盤となるアクションが技術的には成功していても、リソース操作が失敗する場合があることが明示されています。この区別はログを解釈する際に重要です。報告されたエラーがあれば、アクションが実行されなかったと誰かが判断する前に、実際のリソース状態を確認すべきです。
リソースIDもまたレビュー対象です。CloudFormationは、プロバイダーの物理リソースIDを使用して、更新と置換を区別します。サンプルを変更するチームは、ID形式やクリーンアップロジックを変更する前に、その挙動を理解しておくべきです。
これらの懸念は、このアプローチを無効にするものではありません。責任を持って採用するために必要な証拠を定義するものです。オーケストレーションコンポーネントは、障害状態を可視化し、復旧に十分なコンテキストを保持し、意図した結果が存在する前に完了を報告しないようにすべきです。
利用可能な公開資料は技術的なウォークスルーであり、独立した信頼性調査ではありません。本番採用、インシデントの測定可能な削減、普遍的な復旧保証を立証するものでもありません。その最大の貢献は、運用担当者が自ら再構築するのではなくテストできる、明示的な設計を提示している点です。
次に必要な証拠は、更新、復旧、ネイティブサポートから得られるべきである
最も有用なシグナルは、自動化に関する広範な主張ではなく、観測可能なエンジニアリング上の結果です。
最初のシグナルは、スケーリングがその後に復元された、再現可能な設定更新です。今後数か月にわたり、採用者はハードウェア変更とスケーリング設定変更の両方を対象とする証拠を探すべきです。成功の反復は、このコンポーネントが意図した依存関係を一貫して捉えているという根拠を強めるでしょう。
証拠は、単にデプロイコマンドが完了したことではなく、最終状態を説明すべきです。レビュー担当者には、エンドポイントが意図した設定で実行されていること、および期待されるターゲットとポリシーが存在することの確認が必要です。サービングが正常なままであっても、復元が欠けていれば、このパターンの実用的価値は損なわれます。
次のシグナルは、注入された障害下での挙動が文書化されていることです。説得力のある評価では、ワークフローがどこで停止したか、何がアクティブなまま残ったか、復旧がどのように進行したかを特定します。明確な復旧の証拠は、初回デプロイの成功がもう一つ増えるよりも、信頼性を強めます。
逆に、文書化されていないコンソール操作を必要とする障害は、未完了の運用作業を示すことになります。それは自動化されたシーケンシングの価値を失わせるものではありませんが、採用判断は変わります。チームは、その残された作業をリリースプロセスに織り込む必要があります。
最後のシグナルは、ネイティブなライフサイクルサポートの進展です。エンドポイント更新とスケーリング登録に影響する変更について、SageMaker、CloudFormation、CDKのドキュメントを確認してください。前提となるシーケンスをネイティブで処理できるようになれば、アプリケーションで維持するオーケストレーションの必要性は低下します。
そのようなサポートが登場するまで、このリファレンスはプラットフォームエンジニアリングの意思決定に具体的な基盤を提供します。復元を別個の運用担当者タスクとして扱うのではなく、SageMakerのオートスケーリングをエンドポイントのデプロイライフサイクルに組み込みます。その採用の根拠は、この明示的なワークフローが実行環境で予測どおりに動作するかどうかにあります。
このコンストラクトを検討するチームは、更新履歴とスケーリング構成が把握されているエンドポイントから始めてください。生成されたインフラストラクチャをレビューし、登録解除によって削除されるすべての構成を特定し、復旧の所有者を割り当てます。その後、採用を拡大する前に、代表的な更新と制御された障害を実行してください。将来のリリースがコードだけでなくその理由も引き継げるよう、得られた証拠をコンポーネントの運用ドキュメントとともに保管してください。リリースレビューで問うべきことは具体的です。エンドポイントの変更後、チームはサービング、スケーリング、復旧の挙動がすべて要件に適合していると確認できるでしょうか。この基準を用いてSageMakerオートスケーリングのオーケストレーションを評価し、デプロイの証拠にその答えを求めてください。
