はじめに
AWSの基礎力をつけるためにAWS What's Newを毎日目を通す事を始めました。
最初は日本語訳されたものを見ていたのですが、1週間ほど遅れて訳されるようなので、英語の情報を訳して整理することにしました。
本情報が役立つ人もいるかなと思い公開します。
個人的な理解なので、実際の情報は原典をあたってください。
Amazon SageMaker HyperPod が継続的プロビジョニングをサポートし、クラスター運用を強化
投稿日: 2025年8月8日
何ができるようになったのか
Amazon SageMaker HyperPod が継続的プロビジョニングを新たに提供します。これにより、大規模な AI/ML ワークロードを実行するエンタープライズ顧客向けの柔軟性と効率性が向上します。継続的プロビジョニングにより、トレーニングジョブは利用可能なインスタンスで即座に開始でき、バックグラウンドで残りの容量が自動的にプロビジョニングされます。ノードのプロビジョニングに失敗した場合でも、バックグラウンドでリトライし、手動介入なしにクラスターが確実に目的のスケールに到達します。また、ノードの独立したスケーリング、パッチ適用、異なるインスタンスグループの同時調整などの並行操作が可能になり、効率が向上します。強化されたイベント駆動型アーキテクチャは、新しい Events API を通じて包括的なリアルタイム可視性を提供し、完全な運用履歴により、迅速なトラブルシューティングとより良い意思決定を可能にします。
何が嬉しいのか
これにより、顧客はトレーニング時間の短縮と、動的なワークロード全体でのリソース利用率の最大化を実現できます。これらの機能により、顧客は運用上の俊敏性の向上、リソース利用率の向上、クラスター運用における可視性の強化を達成でき、AI/ML チームはインフラストラクチャ管理ではなくイノベーションに集中できるようになります。
これまでとどう変わるのか
-
これまで
- 大規模な AI/ML ワークロードのトレーニング開始、シームレスなスケーリング、運用を中断しないメンテナンス、クラスター運用に関する詳細な可視性が必要でした。
- 動的な推論ワークロードの管理には、頻繁に変化するキャパシティニーズに対応する必要があり、運用上の俊敏性が成功の鍵でした。
- ノードプロビジョニングの失敗時には手動介入が必要でした。
-
これから
- トレーニングジョブは即座に開始でき、バックグラウンドで残りの容量が自動的にプロビジョニングされます。
- ノードプロビジョニングの失敗時に自動リトライが行われ、手動介入なしにクラスターが確実に目的のスケールに到達します。
- ノードのスケーリング、パッチ適用、インスタンスグループの調整などを同時に行うことができ、効率が向上します。
- Events API を通じて包括的なリアルタイム可視性が提供され、迅速なトラブルシューティングと意思決定が可能になります。
具体的なユースケース
- 大規模な AI/ML ワークロードのトレーニングを迅速に開始したい場合。
- ワークロードの需要に応じてシームレスにスケールする必要がある場合。
- 運用を中断することなく、クラスターのメンテナンスを実施したい場合。
- クラスター運用に関する詳細な可視性を確保したい場合。
- キャパシティニーズが頻繁に変化する動的な推論ワークロードを効率的に管理したい場合。
「Amazon Sagemaker Hyperpod」はあらかじめSageMakerの分散トレーニングライブラリが設定されているクラスタを使って、トレーニングデータとモデルをすべてのノードに分割して並列処理し、クラスタの計算およびネットワークインフラをフルに活用することができます。追加のフレームワーク、デバッグツール、最適化ライブラリをインストールすることで、トレーニング環境をさらにカスタマイズすることができます。
https://dev.classmethod.jp/articles/breaking-sagemaker-hyperpod/
Amazon ECSコンソールがAmazon CloudWatch Logs Live Tailによるリアルタイムログ分析をサポート
投稿日: 2025年8月8日
何ができるようになったのか
Amazon ECSコンソールがAmazon CloudWatch Logs Live Tailとネイティブに統合され、ECSコンソール内で直接リアルタイムのログストリーミングが可能になりました。
何が嬉しいのか
これまでECSコンソールとCloudWatchコンソールを行き来する必要があったリアルタイムのログ分析が、ECSコンソール内で完結するため、ワークフローが中断されません。これにより、コンテナ化されたアプリケーションの監視やトラブルシューティングを、より迅速かつ効率的に行うことができます。
これまでとどう変わるのか
-
これまで
- リアルタイムのログを確認するためには、ECSコンソールからCloudWatchコンソールへ画面を切り替える必要がありました。
-
これから
- ECSコンソールのログタブから直接CloudWatch Logs Live Tailを起動できます。Live Tailパネルはコンソール内を移動しても表示され続けるため、他の運用メトリクスを確認しながらログを監視することが可能です。
具体的なユースケース
- アプリケーションの問題をトラブルシューティングする際のリアルタイムログ分析
- デプロイの失敗原因を調査するためのログ確認
- コンテナのヘルスチェックと継続的な監視
Amazon CloudWatch RUM が追加の AWS リージョンで一般提供開始
投稿日: 2025年8月8日
何ができるようになったのか
Amazon CloudWatch RUM が、アジアパシフィック (タイ) およびメキシコ (中央) の AWS リージョンで利用可能になりました。これにより、リアルユーザーが体験するウェブアプリケーションのパフォーマンスと、クライアントサイドのエラーデータをリアルタイムで収集・監視できます。
何が嬉しいのか
CloudWatch RUM は、ページ読み込みステップ、Core Web Vitals、JavaScript および HTTP エラーに関する異常を含む、ウェブアプリケーションのパフォーマンスに関するキュレーションされたダッシュボードを提供します。これにより、さまざまな地理的位置、ブラウザ、デバイスを横断してアプリケーションのパフォーマンスを把握し、問題を迅速に特定・解決できます。また、CloudWatch Application Signals と統合されているため、クライアントサイドのデータと API のパフォーマンスメトリクス(サービスオペレーション、依存関係など)を相関させて、根本原因を特定することが容易になります。
これまでとどう変わるのか
-
これまで
- リアルタイムのログを確認するためには、ECSコンソールからCloudWatchコンソールへ画面を切り替える必要がありました。
-
これから
- CloudWatch RUM が追加のリージョンで利用可能になったことで、より多くの地域でアプリケーションの監視とトラブルシューティングが容易になります。
具体的なユースケース
- 実際のユーザーが体験するウェブアプリケーションのパフォーマンスを監視する。
- クライアントサイドのデータと API のパフォーマンスメトリクスを相関させて、問題をトラブルシューティングする。
- ページ読み込みステップ、Core Web Vitals、JavaScript および HTTP エラーの異常に対してアラートを受け取る。
Amazon GameLift Streams が Proton 9 ランタイムをリリースし、サービス制限を緩和
投稿日: 2025年8月7日
何ができるようになったのか
Amazon GameLift Streamsは、新しいランタイム環境であるProton 9をリリースし、すべてのお客様のデフォルトのサービス制限を引き上げました。これにより、ゲーム開発者はAWSから様々なデバイスのプレイヤーにゲームをストリーミングできるようになります。
何が嬉しいのか
Proton 9は、WindowsのゲームやアプリケーションをLinuxシステムで実行できるようにするProton互換性レイヤーの大幅なアップデートです。これにより、より幅広いWindowsタイトルとの互換性とパフォーマンスが向上し、ゲーム開発者はAmazon GameLift Streams上でゲームを展開する際の柔軟性と選択肢が増え、異なるプラットフォームのより多くの視聴者にリーチできる可能性があります。
これまでとどう変わるのか
-
これまで
- WindowsゲームをLinuxベースのストリーミング環境で実行するには、互換性の問題やパフォーマンスの最適化が必要でした。
-
これから
- Proton 9の導入により、より多くのWindowsゲームが追加の作業なしにLinux上でスムーズに動作するようになります。
- サービス制限の緩和により、より大規模なゲームストリーミングが可能になります。
具体的なユースケース
- Windows向けに開発されたゲームを、追加の開発コストをかけずに様々なデバイス(Linuxベースのクライアントなど)にストリーミング配信したい場合。
- より多くの同時接続プレイヤーに対応するために、ストリーミングサービスのキャパシティを増やしたい場合。
Amazon SageMaker lakehouse アーキテクチャが Apache Iceberg テーブルの最適化設定を自動化
投稿日: 2025年8月8日
何ができるようになったのか
Amazon SageMakerのレイクハウスアーキテクチャが、Amazon S3に保存されたApache Icebergテーブルの最適化設定をカタログレベルで自動化するようになりました。
何が嬉しいのか
これまでテーブルごとに手動で更新する必要があった最適化設定が、一度のデータカタログ設定で新しいIcebergテーブルに対して自動的に有効になります。データカタログは、小さなファイルの圧縮、不要になったスナップショットや参照されていないファイルの削除を継続的に行うことでテーブルを最適化し、ストレージコストの抑制とクエリの高速化を実現します。
これまでとどう変わるのか
-
これまで
- Icebergテーブルの最適化は、テーブルごとに個別に設定を更新する必要がありました。
-
これから
- 一度のデータカタログ設定で、新しく作成または更新されたテーブルの最適化が自動的に行われます。
- 小さなファイルの圧縮、スナップショットの有効期限切れ、参照されていないデータのクリーンアップなどが継続的に実行されます。
具体的なユースケース
- Amazon S3上のApache Icebergテーブルのストレージコストを最適化したい場合。
- クエリパフォーマンスを向上させたい場合。
- データカタログの設定を簡素化したい場合。
さいごに
Amazon ECSコンソールがAmazon CloudWatch Logs Live Tailによるリアルタイムログ分析をサポートしたのは地味な変更ですが、便利ですね。