MLA-3.1既存のアーキテクチャと要件に基づいてデプロイインフラストラクチャを選択する。

ヒントボタン

Amazon EMR のマスターノードはクラスタ全体の YARN ResourceManager や HDFS NameNode を担うため停止するとジョブが続行できません。コアノードはデータノードとしてシャッフルデータやメタデータを保持し、タスクノードは計算専用でデータを持たないという役割分担を整理すると、どこで可用性を確保すべきか見えてきます。ジョブ再実行が許されず Amazon S3 への結果保存だけでは途中経過は守れない点を忘れず、永続データの保護を最優先に考えましょう。

夜間 6 時間だけ動かすバッチ処理でコスト削減を狙うなら Spot インスタンス は魅力的ですが、2 分前通知でいつでも回収されるリスクを正しく評価する必要があります。マスターやコアが回収されると HDFS が失われクラスタ再構築に時間がかかり、RTO 60 分を超える懸念が生じます。複数 AZ に広げても同一プールが同時に奪われる可能性は残るため、どの層をオンデマンドで残すかを慎重に設計する発想が求められます。

ワークロードのピークが 200 vCPU でも平均利用は低いケースでは、Amazon EMR Managed Scaling や Auto Scaling でタスクノードだけを Spot にし弾力的に増減させると大幅なコスト削減が可能です。一方、マスターと HDFS データノードをオンデマンドに固定すればデータ消失を防ぎつつ 60 分以内の復旧が行え、ジョブ再実行不可という制約とも両立します。可用性・データ保護・費用の三要件を俯瞰し、層ごとに購入モデルを使い分ける判断が総合的に最も合理的です。

ヒントボタン

1 秒に 2 万件 × 2 KB ＝ 約 40 MB/秒の取込帯域を逆算すると、Kinesis Data Streams は 1 シャード 1 MB/秒という公式から 40 シャード前後が必要です。Firehose は最短 60 秒バッファで遅延が生じ、Lambda は 10 シャードでは上限 10 MB/秒で帯域不足、MSK は性能十分でもブローカー保守が増えます。Streams は保持期間を 7 日へ拡張できリプレイ要件も単独で満たすため、まず取り込み層は大規模 Streams が最適かを検討してみましょう。

リアルタイム 1 秒以内の検知を目指すなら Apache Flink が持つサブ秒レイテンシが鍵です。Amazon Managed Service for Apache Flink は CloudWatch と連携してジョブを自動再起動でき、S3 へ 30 秒間隔で Checkpoint を保存すれば最大 30 秒分の巻き戻しで 2 分以内に復旧します。EMR Spark の 1 分マイクロバッチや EC2 自営 Flink は手動対応やジョブ再構築が必要になるため、この自動復旧能力の差を意識して比べてみてください。

取り込みは高スループットの Kinesis Data Streams、処理は Exactly-Once を担保する Managed Flink、状態保存は Amazon S3、監視とリカバリは CloudWatch という流れにすると、スループット・7 日リプレイ・1 秒応答・2 分自動復旧・低運用負荷という複数要件をバランス良く満たせるかどうかを総合的な視点で判断してみましょう。

ヒントボタン

Amazon SageMaker Model Registry のコレクションは、複数の Model Package Group を論理的に束ねるだけの軽量メタデータなので、既存構成を壊さずにタグやカスタムプロパティを追加するだけで Studio、Python SDK、Athena 連携の検索や一覧が可能となり、120 バージョンが数百へ増えても運用コストを最小限に抑えられます。
CloudTrail で API 呼び出し履歴を保管しつつ Model Registry の ApprovalStatus と CustomProperties を活用し、さらにコレクションを本番・検証・研究ごとに分けて IAM ポリシーを割り当てれば、レビューと承認を環境単位で独立させながら単一のモデル履歴を一元監査でき、金融分野で求められるガバナンス要件に自然に合致します。
モデル数が増えても複製やリネームを伴う運用は避け、CloudFormation や boto3 でコレクションとタグを自動生成する方式なら継続的デリバリーにも組み込みやすく、SageMaker Domain 追加や S3／Glue での再構築より移行と管理の負担が少ないため、四つの要件を俯瞰した総合判断として最も合理的なアプローチとなります。

ヒントボタン

1つ目のヒント: モデルのバージョン管理や承認ワークフローをネイティブに備え、学習後に登録したモデルパッケージのステータスを Approved へ切り替えるだけで本番ロールバックができるのは SageMaker Model Registry だけです。ECR や S3 はオブジェクト保管が主目的なのでメタデータや承認を自前で管理する必要があります。また Registry はバックエンドの S3 を透過的に利用するため追加コピーが発生せず、データサイエンティストが管理するアカウントと推論を行う本番アカウントのどちらからも同一アーティファクトを参照できます。

2つ目のヒント: クロスアカウント運用ではリソースポリシーで Model Registry を共有し、受け取り側の CI/CD ロールに DescribeModelPackage と CreateEndpoint など最小権限を与える方法が推奨です。これにより本番アカウントは CodePipeline や CodeBuild を使って承認済みバージョンのみを自動取得し、Blue/Green を用いた SageMaker エンドポイントの UpdateEndpoint で 5 分以内の巻き戻しと 50 ms 以内のリアルタイム推論を両立できます。

3つ目のヒント: 学習後にコンテナごと ECR へプッシュする、S3 にファイルを置きタグで承認を模倣する、Neo で最適化後に各アカウントへ個別コピーする、といった方法も実装は可能ですが手運用や複製が増えてヒューマンエラーや監査コストを招きやすいです。Registry を中心に据えれば承認、共有、ロールバックの全要件を IAM とポリシー設定だけで統制できるため、要件を俯瞰した総合判断では最もシンプルでベストプラクティスに合致します。

ヒントボタン

平常時は 1 秒あたり 5 リクエスト未満なのに毎晩 10 分間だけ 400 rps に跳ね上がるというワークロードでは、Amazon SageMaker で常時インスタンスを維持するとアイドル料金が無駄になります。Auto Scaling や Amazon ECS Fargate でもタスク起動と ALB ヘルスチェックに数分かかり、セール開始直後から p95 80 ms を守るのは困難です。さらに待機中も課金が発生し、長期的な運用コスト削減の妨げとなる点を念頭に置きましょう。

SageMaker Serverless Inference はゼロから自動スケールしつつ、予測できるスパイクには「プロビジョンド並列処理」を予約してコールドスタートを排除できます。タイムセール 10 分前に 400 並列をスケジュールし、終わったら 0 へ戻せば必要時間だけ課金され、CPU ベースでも p95 80 ms 以内を維持しやすくなります。EC2 のパッチ適用やサーバ運用も不要なため、運用負荷を大きく抑えられます。

可用性 99.9%、RPO/RTO=0 の要求はマネージドで高信頼な Amazon SageMaker がカバーします。GPU が不要な TensorFlow 2.x モデルは事前に配置した Amazon S3 からワンクリックでロードでき、データ損失リスクもありません。短時間バースト、厳しいレイテンシ、サーバ管理不要、費用最小化という複数要件を俯瞰すると、予約型スケールを備えたサーバレス推論方式が総合的に最も整合します。

ヒントボタン

推論に35秒かかる大型TensorFlow GPUモデルを常時リアルタイムで待ち受けさせると、ml.g4dn.xlargeをピーク外も起動し続ける必要があり月額コストが膨らみます。SageMaker 非同期推論ならInitialInstanceCountを0にでき、要求はキューに蓄積されS3に結果を保存、リクエスト側にはすぐステータスを返すのでクライアントタイムアウト120秒を回避可能です。さらにApproximateBacklogSizePerInstance>100を閾値にg4dnを最大4台までAuto Scalingさせればピーク時の0.42req/sにも余裕で追従し、平常時はシャットダウンされるためコストを大幅に圧縮できます。

同じワークロードをSageMaker サーバーレスエンドポイントに置き換えると、現状CPUのみサポートでメモリ上限2048MBのため4GBモデルがロードできず、ColdStartや推論時間が増大して120秒SLAを超える懸念があります。ml.c5.largeへElastic Inferenceを付与する案も、GPUビルドのTensorFlowモデルには適用できずメモリ帯域が不足します。EventBridgeで1時間ごとにバッチ変換を回す設計はジョブ起動待ちと一括処理で最悪60分＋αかかりオンライン用途に不適です。ハードウェア制約・レイテンシ・キューイングを総合するとGPU対応の非同期推論が最も実装容易で信頼性が高いです。

課題はスループット1500件/2h、応答120秒、月500USD以下、運用負荷最小という複合条件です。ml.g4dn.xlargeを用いる非同期エンドポイントは1台あたり約0.5USD/時で、ピーク時に4台×2hでも4USD程度、月間見積もりはインターバル起動を含めても上限内に収まります。SageMakerがメトリクス収集・リトライ・モデルモニタリング・S3入出力までフルマネージド化してくれるため、人手によるスケジューラー構築やAPI管理が不要です。可用性・コスト・レイテンシを俯瞰した総合判断として、この構成が各要件を最もバランス良く満たします。

ヒントボタン

PyTorch で学習した今回のモデルは GPU が不要で 2 vCPU・8GiB あれば十分という条件なので、SageMaker の汎用 CPU インスタンス ml.m5.large を選ぶのが最も費用対効果に優れます。GPU を備えた ml.g4dn 系やメモリを多く積んだ構成は余剰リソースが発生し、Savings Plans を使ってもアイドル時に無駄な固定費が残ります。ml.m5.large は 1 台で毎秒 50～100 推論を捌ける目安があり、40ms の平均レイテンシーや P95 100ms をキープしたままピーク 600rps に対応するには最大 10 台で充分な余裕が得られます。

曜日ごとのアクセス変動に追従するには SageMaker を Application Auto Scaling と組み合わせ、CloudWatch の InvocationsPerInstance をターゲットメトリクスに設定するのが王道です。1 分間あたり 50 リクエストを閾値とすれば、負荷が増えると自動で ml.m5.large が水平スケールし、アイドル時は最小キャパシティ 1 台に縮退してコストを圧縮できます。CPUUtilization や同時実行数を指標にするとスケール判断が遅れやすくキュー待ちが発生し、リアルタイム SLA に求められる低レイテンシーを守りにくくなる点に注意してください。

SageMaker リアルタイムエンドポイントを ml.m5.large で最小 1 最大 10 に設定し、InvocationsPerInstance 50 で制御する構成は、CPU 前提というハード要件、40ms 平均／100ms P95 のレイテンシー、ピーク 600rps 処理、アイドル時コスト最小化という複数の要求を同時に満たせる総合的に最適なアプローチとなります。

ヒントボタン

既存の Amazon SageMaker エンドポイントに届いたリクエストを本番モデルだけで処理し返却した後、同じ入力を非同期で新モデルにも送る「シャドウバリアント」の仕組みを使うと、EndpointConfig の更新だけで実装でき、実ユーザの応答時間は本番モデルの p95 45 ms のままなので SLA 50 ms を超えにくく、リアルタイムトラフィックで品質とレイテンシを安全に比較できます。

Amazon SageMaker が自動的に ProductionVariant と ShadowVariant の InferenceLatency や ModelLatency を Amazon CloudWatch と CloudWatch Logs に出力してくれるため、追加コードなしで同一入力に対する推論値とレイテンシ差を可視化できます。Metric Math や Alarm を組み合わせれば基準外を即座に検知でき、モデル v2 の評価を継続するか否かを迅速に判断できます。

CloudWatch Alarm がしきい値超過を検知したら SageMaker UpdateEndpoint で影だけを削除すれば ml.c5.4xlarge×4 のインスタンス料金をすぐ止められます。Route 53 によるトラフィック分割や Batch Transform のバッチ推論を使わず、ほぼ既存構成のままリアルタイム比較とコスト最小化を両立できる点を俯瞰すると、このデプロイ方式が複数要件を最もバランス良く満たすと総合判断できます。

ヒントボタン

SageMaker にはリアルタイム推論、非同期推論、バッチ変換という 3 形態がありますが、取引ログ 1 行ごとに InvokeEndpoint を 1,000 万回呼ぶとネットワーク往復が律速になり、1 行 100 ms では理論上 4 時間に収まりません。S3 に置いたファイルを一括で読み込み、複数の CPU インスタンスに並列分散して処理し、終了と同時にリソースを自動解放できる方式を思い出してみてください。

SageMaker バッチ変換ジョブは Spot インスタンス指定でコストを抑えつつ、ジョブレベルの自動リトライで途中失敗にも耐えられるため RPO ゼロを維持できます。さらに VPC エンドポイントを介して暗号化 S3 に入出力でき、ジョブ完了後に EC2 資源を即時解放するためアイドル課金が発生しません。RTO 四時間という厳格な SLA を守るうえで、このネイティブリトライ機能を活用するかどうかが鍵になります。

GPU 不要・同一 VPC 内での暗号化 S3 入出力・4 時間以内完了・完了後の完全停止・自動リトライという複数条件を並べて比較すると、リアルタイムや非同期エンドポイントを常設する構成より、Spot でスケールアウトできるバッチ変換が性能、コスト、運用の三面でバランス良く要件を満たすという総合判断に至るはずです。

ヒントボタン

ml.p4d は Elastic Fabric Adapter を有効にすると OS バイパスで 10µs 台のレイテンシと 100 Gbps 超のスループットが得られますが、この性能を引き出すにはクラスター型プレースメントグループと同一 Availability Zone への集約が前提です。同一 AZ のプライベートサブネットに 16 ノードをまとめればネットワーク経路が最短化され、Gradient AllReduce などの集団通信を 100µs 未満で処理でき、SageMaker Training を 2 時間以内に完了しやすくなります。

FSx for Lustre は S3 からの自動インポート後にメタデータをローカル保持し、POSIX I/O で数十µs のアクセスと数百 GB/s の総スループットを実現します。InputMode=Pipe で S3 を直接読む場合は VPC エンドポイント経由でも帯域が数百 MB/s、レイテンシがミリ秒級となり、3 GB/s×16 台の要求には届きません。さらにクロス AZ や VPC ピアリングを挟むと Lustre の高速性が損なわれるため、ストレージと計算を同じ AZ 内に配置することが高性能設計の鍵となります。

可用性を高めるマルチ AZ 構成や細かな VPC 分割は一見魅力的ですが、HPC ワークロードでは帯域とレイテンシが最優先事項です。今回は ml.p4d が求める 3 GB/s・100µs という厳しいネットワーク要件、FSx for Lustre のローカル性、SageMaker 分散アルゴリズムが EFA とプレースメントグループを前提に最適化されている点を俯瞰し、パフォーマンス・コスト・セキュリティを複合的に見極める総合判断が求められます。

ヒントボタン

ライブ講義を視聴者へほぼ同時に届けるには、音声ストリームを即時に取り込める Amazon Kinesis Video Streams と、数百ミリ秒単位で字幕を返す Amazon Transcribe ストリーミング API の組み合わせが鍵です。16 kHz PCM を直接扱え、容量は自動拡張、SLA やパッチもマネージドに任せられるため、2 秒以内という厳しい遅延要件と「数日で本番導入」を同時に満たしやすくなります。

生成された英語字幕を複数言語へ瞬時に変換するなら、待ち行列を挟まず AWS Lambda から Amazon Translate リアルタイム API を呼び出す設計が適しています。数百ミリ秒で 3 言語同時翻訳でき、バッチ API のようなファイル待ちがありません。出力を Amazon CloudFront で世界に配信すれば 5 万同時接続もエッジが吸収し、オリジン負荷と遅延を大幅に抑えつつ従量課金でコストも最小化できます。

GPU 搭載の Amazon EC2 で独自 PyTorch ASR を走らせたり、Amazon SageMaker で Hugging Face モデルを調整する方法はモデル開発やスケール設計が避けられず、「独自モデル開発なし」という条件に合致しません。また Amazon Polly は Text-to-Speech、AWS Glue はバッチ ETL 用でリアルタイム字幕とは用途が異なります。ストリーミング対応のマネージドサービスと Edge 配信を組み合わせ、2 秒以内・5 万同時視聴・短期構築という複数要件を俯瞰して満たせる案を選ぶのが総合的に最も合理的な判断となります。

ヒントボタン

500GB の取引ログを毎晩オンプレ Oracle から S3 に吸い上げ、6 時までに特徴量を作成したい場合、Spark ベースでサーバーレスに自動スケールする AWS Glue を用い、Glue ワークフローで依存関係・再試行・失敗通知を統合管理し、完了イベントを EventBridge で SageMaker Pipelines に渡す構成にすると運用が大幅に簡素化でき、深夜帯でもクラスターの起動や停止を気にせずに済みます。
金融データは列が追加されることが多いため、DynamicFrame や Glue のスキーマレジストリのようにスキーマ進化を許容する抽象化を使えば、Parquet 形式で追加列を自動認識しコードの再デプロイなしで変換が続行でき、さらにジョブブックマークで増分部分だけを取り込むことで 500GB の夜間バッチでも処理時間とコストを最小化できます。
EMR や AWS Batch で同様の Spark 処理を組むことも可能ですが、コンテナイメージ更新やクラスターライフサイクル管理が発生し、スキーマ変化に備えたメタストア調整や再デプロイも必要になるため、サーバーレスでワークフローとメタデータを一体管理できる Glue を中心に据えたアーキテクチャが再試行・通知・自動トリガーまでを包括的に満たし、最も低い運用負荷で要件を総合的にカバーします。

ヒントボタン

SageMaker では 1 つの EndpointConfig に複数の ProductionVariant を置き、InitialInstanceCount と VariantWeight を個別設定することで 90:10 などの比率分散が自動化できます。追加のロードバランサやクライアント改修は不要で、InvokeEndpoint は同じ URL を呼ぶだけです。InvocationsPerVariant や ModelLatency など詳細メトリクスが CloudWatch に自動送信されるため、バリアント単位のダッシュボード作成も容易です。

異常時に数秒で切り戻すなら、Amazon SageMaker UpdateEndpoint API を使い Weight を 0 に変更する方法が最短です。エンドポイント自体は再作成しないため起動待ち時間がなく、Route 53 や Application Load Balancer を触る必要もありません。CloudWatch Alarm を併用すれば 5XXError や P95 Latency を閾値に自動で Weight を変更する運用も組み込めます。

今回求められるのは①リアルタイム SLA の維持、②10% カナリアで実レスポンスを返す、③Variant 単位で Invocations／Latency／Error を監視、④追加ルーティング装置なし、⑤即時ロールバックの五点です。これらを全て満たす唯一の手段は、SageMaker のマルチ ProductionVariant と CloudWatch メトリクスを活用し、Weight だけでトラフィックを制御するアプローチだと俯瞰的に判断できます。

ヒントボタン

毎日 4 TB を取り込み 30 分で継続学習するには高速 GPU と広帯域が不可欠です。SageMaker Distributed Data Parallel で ml.p4d.24xlarge を 4 台束ねれば A100×32 と 400 Gbps ネットワークで効率よくスケールでき、Spot Training と Checkpoint で運用コストと RTO に備えられます。公式 PyTorch コンテナは requirements.txt だけで独自 C++ 拡張をビルドできるため Docker メンテナンスをほぼ省力化できます。

1,000 TPS・P95 50 ms の GPU 推論を本番で維持しながら即時ロールバックしたい場合、学習と同じイメージを SageMaker リアルタイムエンドポイントにデプロイし g5.xlarge を Auto Scaling する構成が扱いやすいです。ProductionVariant を 2 系統並べればワンクリックでブルー/グリーン切替ができ、CloudWatch ログとメトリクスによりスループットやレイテンシを詳細に観測できます。

EC2 や ECS、EMR PySpark、Lambda などへ分散して実装する方法もありますが、Horovod の手動設定や GPU ドライバ管理、ALB／CodeDeploy の連係調整など追加運用が増え、30 分の復旧目標と 50 ms レイテンシを安定して維持する難易度が高まります。マネージドな分散学習とリアルタイム推論を同一サービスで完結させ、可観測性・コスト最適化・ロールバック性を同時に満たす構成を総合的に選ぶ視点がカギとなります。

ヒントボタン

60 ミリ秒以内の応答を保証するには、SageMaker リアルタイムエンドポイントを GPU 搭載 ml.g4dn.xlarge でウォーム状態に保つことが前提となります。ResNet50 は 1 台あたり約 100 RPS を処理できるため、平常 50 RPS でも冗長性を見込み最低 2 台を常時稼働させる設計が望ましいです。
ピーク時 800 RPS では理論上 8 台が必要ですが、起動に約 5 分かかるため CloudWatch InvocationsPerInstance などをトリガに早めの Auto Scaling を行い、上限を少し余裕の 10 台程度にしておけばスケールアウト遅延によるレイテンシ悪化を抑えられます。
GPU を使えない SageMaker サーバーレスやキューイング型の非同期推論は今回の P95 60 ms SLA に適合せず、固定台数だけではコストが膨らみますので、リアルタイムエンドポイントを最小 2 台で維持し需要に応じて動的に拡張する構成が要件全体を俯瞰した最適解となります。

ヒントボタン

ピーク1,000req/s・P99 25msという超低レイテンシは、SageMaker リアルタイムエンドポイントが常駐プロセスでコールドスタートを避け、Auto Scaling で事前ウォームしたインスタンスを10台まで動的に確保する構成が最も現実的です。Lambda や非同期推論は S3 書込みや起動遅延が入りやすく、安定して25ms未満を維持しづらい点を思い出してください。

推論データを90日間残し週次で品質ドリフトを検知しSlackへ送る流れは、SageMaker Data Capture で入力・出力を100% S3 保管し、Model Quality Monitor をスケジュールしてメトリクスを CloudWatch と SNS へ渡すだけで実現できます。この機能が無い環境では自前でログ収集や集計バッチを組む必要があり、追加コード最小化という条件から外れがちです。

平均100req/sの平常時は最小1台でコストを抑え、リリース時は Blue/Green デプロイで無停止ロールバックを行えるよう、MinCapacity=1 の Auto Scaling とバージョン管理機能を備えた SageMaker が適合します。サーバーレスや固定台数ではどこかの要件が欠けやすく、サービス群を横断して複数要件を俯瞰した総合判断で選択すると最適解が導けます。

ヒントボタン

500TBのゲノム画像を100台のml.p4d.24xlargeで同時処理するには、各インスタンスへ2Gbps超の帯域を連続供給できる並列ファイルシステムが不可欠です。Amazon S3を直接読む方式はプレフィックス帯域制限やTLSオーバーヘッドで伸びにくいため、1TiB当たり最大200MB/sを水平方向に積み上げられるAmazon FSx for Lustreを前段に置き、POSIX互換の高速マウントを行う設計がHPCの定石となります。

FSx for LustreのS3リンクでは自動インポートが有効になり、ジョブ開始時にaws s3 cpやDataSyncで全量コピーする待ち時間をゼロにできます。さらに自動エクスポートで学習中に更新されたファイルがS3へシームレスに書き戻され、自動リリースによって転送完了後ただちにLustre側ブロックが解放されるため、ジョブ終了直後にストレージコストを最小化できる点が要件に合致します。

総合的に見ると、数百GB/sまでスケールするScratch 2タイプのAmazon FSx for LustreをSageMakerの分散学習にマウントし、S3リンクの自動インポート・エクスポート・リリースを組み合わせる構成が、事前コピーなし・高スループット・自動書き戻し・即時容量解放という複数要件を同時に満たす最適なアプローチと言えるでしょう。

ヒントボタン

アカウントが異なる VPC 間で Amazon SageMaker から Amazon Redshift へプライベートに接続する方法としては VPC ピアリング、Transit Gateway、PrivateLink などがあります。CIDR 重複を気にせずルートやセキュリティグループの調整を最小化したい場合、Interface 型 VPC エンドポイントサービスを公開し相手がエンドポイントを作成する方式が運用を簡潔にし、通信は AWS バックボーン内のみで完結し NAT やインターネットを排除できます。

医療系ワークロードで PHI を扱うときはインターネット経由や NAT ゲートウェイを介したトラフィックが監査要件に抵触しやすいです。PrivateLink は ENI を介し相手 VPC にプライベート IP を付与するため、リージョン内で閉じた通信となりデータ転送料も VPC 内通信扱いです。毎時 100 並列 SELECT といった高並列アクセスでも ENI が水平にスケールし、SageMaker 側の実装変更がほぼ不要なのも利点です。

列レベル権限をアカウント A で一元管理するには Amazon Redshift RA3 と AWS Lake Formation の統合が有効で、IAM ロール経由でクロスアカウント利用者に細粒度許可を配布できます。Data Sharing は共有先で権限が分散し、VPC ピアリングはネットワーク連携のみで追加機構が必要です。転送料・運用工数・権限制御を総合的に比較すると Interface エンドポイントと Lake Formation を組み合わせる案が最も要件を満たします。