メインコンテンツへスキップ

【AWSデイリーアップデート】EC2 R8gnで超高速ネットワーク!OpenSearch 3.1で生成AI検索強化

· loading · loading ·
kiitosu
著者
kiitosu
画像処理やデバイスドライバ、データ基盤構築からWebバックエンドまで、多様な領域に携わってきました。地図解析や地図アプリケーションの仕組みにも経験があり、幅広い技術を活かした開発に取り組んでいます。休日は草野球とランニングを楽しんでいます。
目次

はじめに
#

AWSの基礎力をつけるためにAWS What’s Newを毎日目を通す事を始めました。 最初は日本語訳されたものを見ていたのですが、1週間ほど遅れて訳されるようなので、英語の情報を訳して整理することにしました。

本情報が役立つ人もいるかなと思い公開します。 個人的な理解なので、実際の情報は原典をあたってください。


AWS S3 Batch Operations が AWS マネジメントコンソールでバケットまたはプレフィックスの管理を単一ステップでサポート
#

投稿日: 2025年09月15日

何ができるようになったのか
#

AWS マネジメントコンソールで S3 Batch Operations を使用する際、S3 バケット、プレフィックス、サフィックス、作成日、またはストレージクラス全体を単一のステップで指定して、その条件に一致するすべてのオブジェクトに対して操作を実行できるようになりました。

何が嬉しいのか
#

これまで個別のオブジェクトリストを指定する必要があったバッチ操作において、より広範な条件(バケット全体、特定のプレフィックスなど)を簡単に指定できるようになり、大規模なデータセットに対する操作の管理が大幅に簡素化されます。これにより、作業の効率が向上し、手動での設定ミスを減らすことができます。

これまでとどう変わるのか
#

  • これまで
    • S3 Batch Operations で操作対象のオブジェクトを指定する際、個別のオブジェクトリストを詳細に指定する必要がありました。
  • これから
    • AWS マネジメントコンソールから、バケット全体、特定のプレフィックス、サフィックス、作成日、またはストレージクラスといった広範な条件を直接指定して、それらに一致するすべてのオブジェクトに対してバッチ操作を実行できるようになります。

具体的なユースケース
#

  • ステージングバケットと本番バケット間でオブジェクトをコピーする。
  • S3 Glacier ストレージクラスからアーカイブされたバックアップを復元する。
  • 保存されたデータセットのコンテンツを検証するためにオブジェクトのチェックサムを計算する。

一般提供開始:Amazon EC2 R8gn インスタンス
#

投稿日: 2025年09月15日

何ができるようになったのか
#

AWS Graviton4 プロセッサを搭載した新しい Amazon EC2 R8gn インスタンスが一般提供開始されました。これにより、AWS Graviton3 プロセッサと比較して最大30%優れたコンピューティング性能と、ネットワーク最適化されたEC2インスタンスの中で最高の最大600 Gbpsのネットワーク帯域幅を利用できるようになりました。また、最大1,536 GiBのメモリと、Amazon Elastic Block Store (EBS) への最大60 Gbpsの帯域幅を提供し、特定のインスタンスサイズでは Elastic Fabric Adapter (EFA) ネットワーキングもサポートします。

何が嬉しいのか
#

Graviton4 プロセッサによる大幅な性能向上と、600 Gbpsという非常に高いネットワーク帯域幅により、SQLやNoSQLデータベース、インメモリデータベースといったネットワーク集約型ワークロードのパフォーマンスとスループットを劇的に向上させることができます。EFAのサポートにより、密結合クラスターで実行されるワークロード(HPCや機械学習など)のレイテンシーが低減され、クラスター全体のパフォーマンスが向上します。これにより、より大規模で要求の厳しいアプリケーションを効率的に実行できるようになります。

これまでとどう変わるのか
#

  • これまで
    • Graviton3ベースのインスタンスが最新であり、ネットワーク帯域幅やコンピューティング性能に上限がありました。
    • 非常に高いネットワーク性能やコンピューティング性能を必要とするワークロードでは、性能がボトルネックになる可能性がありました。
    • 密結合クラスターのワークロードでは、EFAが利用できるインスタンスタイプが限られていました。
  • これから
    • Graviton4ベースのR8gnインスタンスにより、Graviton3と比較して最大30%向上したコンピューティング性能と、最大600 Gbpsのネットワーク帯域幅を単一インスタンスで利用できるようになります。
    • ネットワーク集約型ワークロードや大規模なデータベース、インメモリアプリケーションのパフォーマンスとスケーラビリティが大幅に向上します。
    • EFA対応インスタンスの選択肢が増え、HPCや機械学習などの密結合ワークロードの効率的な実行が可能になります。

具体的なユースケース
#

  • SQLおよびNoSQLデータベース
  • インメモリデータベース
  • ネットワーク集約型ワークロード
  • ハイパフォーマンスコンピューティング (HPC)
  • 機械学習 (ML) ワークロード
  • 大規模なデータ分析アプリケーション

Amazon Managed Service for Prometheus が 11 の追加 AWS リージョンで利用可能に
#

投稿日: 2025年09月15日

何ができるようになったのか
#

Amazon Managed Service for Prometheus が、アジアパシフィック (ジャカルタ)、アジアパシフィック (ハイデラバード)、アジアパシフィック (大阪)、アジアパシフィック (メルボルン)、アジアパシフィック (台北)、カナダ西部 (カルガリー)、欧州 (スペイン)、イスラエル (テルアビブ)、メキシコ (中央)、中東 (バーレーン)、米国西部 (北カリフォルニア) の 11 の追加 AWS リージョンで利用可能になりました。

何が嬉しいのか
#

より多くの地域で、フルマネージドな Prometheus 互換のモニタリングサービスを利用できるようになります。これにより、運用メトリクスを大規模に簡単に監視し、アラートを設定することが可能になります。顧客は単一のワークスペースに最大 10 億のアクティブメトリクスを送信でき、アカウントごとに複数のワークスペースを作成できます。

これまでとどう変わるのか
#

  • これまで
    • Amazon Managed Service for Prometheus が利用できるリージョンが限られていました。
  • これから
    • 11 の新しいリージョンでサービスが提供されるようになり、より広範な地理的地域で Prometheus ベースのモニタリングソリューションをデプロイおよび管理できるようになります。

具体的なユースケース
#

  • 新たに追加されたリージョンで、Prometheus を使用してアプリケーションやインフラストラクチャの運用メトリクスを大規模に監視し、アラートを設定する。
  • グローバルに展開するアプリケーションのモニタリング基盤を、より多くのAWSリージョンで統一的に構築する。

Amazon BedrockでカスタムMeta Llamaモデルのオンデマンドデプロイメントを発表
#

投稿日: 2025年09月15日

何ができるようになったのか
#

Amazon Bedrockで、ファインチューニングまたは蒸留されたカスタムMeta Llama 3.3モデルに対して、オンデマンドデプロイメントオプションが利用可能になりました。2025年9月15日以降にカスタマイズされたモデルが対象となります。

何が嬉しいのか
#

事前にプロビジョニングされたコンピューティングリソースを必要とせずに、リアルタイムでリクエストを処理できるようになるため、コストを削減できます。常時稼働のインフラストラクチャが不要になり、使用した分だけ料金を支払う形になります。

これまでとどう変わるのか
#

  • これまで
    • カスタムMeta Llamaモデルを使用する場合、事前にコンピューティングリソースをプロビジョニングする必要があり、使用状況に関わらずコストが発生する可能性がありました。
  • これから
    • オンデマンドデプロイメントにより、リクエストがあったときにのみリソースがプロビジョニングされ、使用した分だけ料金を支払うことで、コスト効率が向上します。

具体的なユースケース
#

  • ユーザーからのリクエストに応じてカスタムLlamaモデルを動的に利用するアプリケーション。
  • 開発環境やテスト環境で、モデルを常時稼働させる必要がない場合。
  • ピーク時とアイドル時の差が大きい、変動の激しいワークロードを持つ生成AIアプリケーション。

AWS Organizations がメンバーアカウントの「アカウント状態情報」を提供するようになりました
#

投稿日: 2025年09月15日

何ができるようになったのか
#

AWS Organizations コンソールおよびAPI (DescribeAccount, ListAccounts, ListAccountsForParent) に新しい State フィールドが追加され、AWSアカウントのライフサイクルに関する可視性が向上しました。これにより、AWSによる停止を示す「SUSPENDED」、閉鎖リクエスト中の「PENDING_CLOSURE」、90日間の復元期間中のアカウントを示す「CLOSED」など、より詳細なアカウント状態情報を確認できるようになりました。

何が嬉しいのか
#

アカウントの現在の状態をより詳細に把握できるようになるため、AWSアカウントのライフサイクル管理がより正確かつ効率的に行えるようになります。これにより、アカウントの運用状況をより深く理解し、適切な対応を迅速に取ることが可能になります。

これまでとどう変わるのか
#

  • これまで
    • 既存の Status フィールドが提供されていましたが、アカウントの状態に関する情報がより大まかでした。
  • これから
    • 新しい State フィールドが導入され、「SUSPENDED」「PENDING_CLOSURE」「CLOSED」といった、より詳細で粒度の高いアカウント状態情報が提供されます。既存の Status フィールドは2026年9月9日以降に完全に非推奨となるため、それまでに State フィールドへの移行が必要です。

具体的なユースケース
#

  • アカウント自動プロビジョニングパイプラインを使用している顧客が、アカウントの正確な状態(例:停止中、閉鎖処理中)に基づいて自動化されたアクション(例:リソースのクリーンアップ、通知)を実行する。
  • セキュリティおよびコンプライアンスチームが、組織内のアカウントの状態を詳細に監視し、ポリシー違反や異常な状態を早期に特定する。
  • AWSアカウントのライフサイクル管理ツールやスクリプトを開発しているユーザーが、より正確なアカウント状態情報に基づいて処理を分岐させる。

Amazon SageMaker HyperPod が Slurm クラスター向けヘルスモニタリングエージェントのサポートを発表
#

投稿日: 2025年09月15日

何ができるようになったのか
#

Amazon SageMaker HyperPodが、Slurmクラスター向けにヘルスモニタリングエージェントの一般提供を開始しました。このエージェントは、GPUまたはTrainiumベースのノードで継続的に動作し、応答しないGPUやNVLinkエラーカウンターなどのハードウェア問題をパッシブに監視します。障害が検出されると、ノードを異常とマークし、自動的に再起動または正常なノードに置き換えることで、トレーニングジョブを中断なく実行し続けることができます。また、Slurmクラスターで利用可能なジョブの自動再開機能と連携して障害を処理し、一時的な問題(GPUドライバーの問題など)の場合には簡単なコマンドでノードを再起動することも可能です。

何が嬉しいのか
#

この機能により、大規模な機械学習ワークロード(LLM、拡散モデル、基盤モデルなど)を数週間にわたって中断なくトレーニングできるようになります。手動での介入なしに、ハードウェア障害から自動的に回復し、ジョブが最後に保存されたチェックポイントから続行されるため、トレーニングの中断による時間とコストの損失を大幅に削減できます。Amazon EKSでオーケストレーションされたHyperPodクラスターと同様の回復力のある環境がSlurmクラスターでも利用可能になり、MLチームはより効率的に作業を進めることができます。

これまでとどう変わるのか
#

  • これまで
    • Slurmクラスターで大規模なMLワークロードを実行中にハードウェア障害が発生した場合、手動での介入が必要となり、ジョブが中断される可能性がありました。
    • 異常なノードの特定と交換に時間がかかり、トレーニングの進行が遅れたり、最初からやり直す必要が生じたりすることがありました。
    • 中断による時間とコストの損失が課題となっていました。
  • これから
    • ヘルスモニタリングエージェントがハードウェアの問題を自動的に検出し、異常なノードを再起動または正常なノードに置き換えます。
    • Slurmの自動再開機能と連携し、ジョブは最後に保存されたチェックポイントから続行されるため、中断が最小限に抑えられます。
    • 手動介入なしで、大規模モデルのトレーニングを長期間にわたって安定して実行できるようになり、時間とコストを節約できます。

具体的なユースケース
#

  • 大規模言語モデル(LLM)、拡散モデル、基盤モデル(FM)などの最先端モデルを数週間にわたってトレーニングする際、ハードウェア障害による中断を最小限に抑えたい場合。
  • GPUやTrainiumベースのノードで構成されたSlurmクラスターで、MLワークロードの安定性と回復力を向上させたい場合。
  • MLトレーニングジョブの運用コストと時間を削減し、手動での障害対応を減らしたいMLエンジニアや研究者。

Amazon Connect Casesがケースリストビューでの日付範囲フィルターをサポート
#

投稿日: 2025年09月15日

何ができるようになったのか
#

Amazon Connect Casesが、ケースリストビューで日付範囲によるフィルタリングをサポートするようになりました。

何が嬉しいのか
#

コンタクトセンターの管理者やエージェントが、ケースのワークロードをより効率的に管理できるようになります。これにより、必要な情報を素早く見つけ出し、対応の優先順位付けやレポート作成が容易になります。

これまでとどう変わるのか
#

  • これまで
    • ケースリストビューで日付範囲を指定してケースをフィルタリングする機能が直接提供されていなかったため、特定の期間のケースを特定するのに手間がかかる場合がありました。
  • これから
    • 作成日や最終更新日などの日付範囲を指定してケースをフィルタリングできるようになり、より柔軟かつ迅速にケースを検索・管理できるようになります。

具体的なユースケース
#

  • 月次レポートのために過去30日間に作成されたケースをフィルタリングする。
  • 最近のアクティビティを監視するために過去24時間以内に変更されたケースを表示する。
  • SLA違反を防ぐために、今後2日以内にSLA違反の可能性があるケースを特定する。

Amazon OpenSearch Service が OpenSearch バージョン 3.1 をサポート開始
#

投稿日: 2025年09月15日

何ができるようになったのか
#

Amazon OpenSearch Service で OpenSearch バージョン 3.1 を実行できるようになりました。これにより、検索の関連性とパフォーマンスが向上し、生成AIワークロード向けのベクトル駆動型アプリケーションの開発を簡素化する機能が導入されました。具体的には以下の機能が利用可能になりました。

  • Lucene 10 の導入により、最適化されたベクトルフィールドインデックス作成が可能になり、インデックス作成時間の短縮とインデックスサイズの削減が実現。
  • CPUとストレージ効率を向上させるスパースインデックス作成。
  • メモリ使用量を削減するベクトル量子化。
  • ログ分析および時系列ワークロードに恩恵をもたらすレンジクエリパフォーマンスの向上。
  • 高カーディナリティ集計のレイテンシー削減。
  • 実験を通じて検索品質を評価および最適化するための統合ツールである新しい Search Relevance Workbench の提供。
  • ベクトル検索機能の改善:
    • Zスコア正規化により、外れ値や異なるスコアスケールの影響を軽減し、ハイブリッド検索の信頼性が向上。
    • メモリ最適化検索により、Faissエンジンがインデックスファイルをメモリマップし、オペレーティングシステムのファイルキャッシュを使用して検索リクエストを処理することで効率的に動作。

何が嬉しいのか
#

OpenSearch 3.1の利用により、検索アプリケーションの全体的なパフォーマンスと効率が大幅に向上します。特に、生成AIワークロードの需要が高まる中で、ベクトル検索機能の強化は開発者にとって大きなメリットとなります。インデックス作成の高速化、リソース使用量の削減、クエリの応答性向上により、よりコスト効率が高く、高性能な検索ソリューションを構築できるようになります。また、Search Relevance Workbenchの導入により、検索品質の継続的な改善が容易になり、ユーザーエクスペリエンスの向上に直結します。

これまでとどう変わるのか
#

  • これまで
    • OpenSearch 3.1で導入された検索関連性、パフォーマンス、生成AIワークロード向け機能、インデックス効率化、クエリ性能向上、集計レイテンシー削減、検索品質評価ツール、強化されたベクトル検索機能などが利用できませんでした。
    • 特に、大規模なベクトル検索や生成AIアプリケーションの開発において、効率性や機能面で制約がありました。
  • これから
    • OpenSearch 3.1の最新機能群をAmazon OpenSearch Service上で利用できるようになり、検索アプリケーションの性能、効率、開発の柔軟性が大幅に向上します。
    • 生成AIワークロード向けのベクトル駆動型アプリケーションをより効率的かつ高性能に構築・運用できるようになります。
    • 検索品質の評価と最適化が容易になり、継続的な改善サイクルを確立できます。

具体的なユースケース
#

  • 生成AIワークロード向けに、高性能でメモリ効率の良いベクトル検索機能を活用したセマンティック検索やレコメンデーションシステムの構築。
  • 大量のログデータや時系列データを扱うアプリケーションにおいて、レンジクエリのパフォーマンス向上による高速なデータ分析と可視化。
  • eコマースサイトやコンテンツプラットフォームで、Search Relevance Workbenchを使用して検索結果の関連性を継続的に評価・改善し、ユーザー満足度を向上。
  • ハイブリッド検索(キーワード検索とベクトル検索の組み合わせ)の信頼性を高め、より正確で包括的な検索結果を提供する必要があるアプリケーション。
  • 大規模なインデックスを持つシステムで、インデックス作成時間の短縮とストレージコストの削減を実現。
Reply by Email

関連記事

【AWSデイリーアップデート】RDS ProxyがIAM認証をフルサポート!MacインスタンスもM4世代へ
· loading · loading
【AWSデイリーアップデート】CloudTrailがAIと対話可能に!LocalStackのVS Code連携も
· loading · loading
【AWSデイリーアップデート】Connectエージェントがタスク手動選択可能に!Q in ConnectでLLMも直接選択
· loading · loading