本記事は 2025年11月24日 に公開された「 Announcing embedded chat in Amazon Quick Suite | AWS Business Intelligence Blog 」を翻訳したものです。 本日、 Amazon Quick Suite の埋め込みチャット機能を発表します。これは、お客様のアプリケーションに直接埋め込むことができる統合された会話体験です。このリリースにより、構造化データと非構造化ナレッジを単一の会話で統合する Quick Suite のエージェント型 AI チャットを、ユーザーが既に使用しているツールに組み込むことができます。これにより、組織は会話インターフェース、オーケストレーションロジック、データアクセスレイヤーをゼロから構築することなく、アプリケーション内にインテリジェントでコンテキストに応じた回答を簡単に追加できます。 組織が AI を導入する中で、明確なパターンが見えてきています。人々は回答を得るためにツールを切り替えたくないのです。CRM、サポートコンソール、分析ポータル、社内ダッシュボードなど、その場で質問し、正確でコンテキストに応じた回答を得たいと考えています。同様に、独立系ソフトウェアベンダー（ISV）は、高度なエージェント機能を顧客向け製品に統合したいと考えています。しかし、ほとんどの会話ツールは依然として妥協を強いられます。構造化データに優れているか、ドキュメントに優れているか、分析に適しているか、ナレッジベースに適しているか、質問に答えられるか、アクションを実行できるか、のいずれかです。これらすべてを兼ね備えていることはほとんどありません。 Quick Suite の統合チャット機能は、ダッシュボード、ドキュメント、インデックス、接続されたデータを単一の会話で推論できるエージェント型 AI でこのニーズに対応します。ユーザーは KPI を参照し、ファイルから詳細を取得し、チケットから顧客フィードバックを取り込み、定義されたアクションを実行できます。これらすべてを、使い慣れたツールのチャット画面から離れることなく実行できます。埋め込み統合チャットにより、組織はこのエージェント型 AI 駆動の体験を自社の製品やポータルに直接配置でき、ユーザーにワークフローに自然に適合する強力でパーソナライズされた体験を提供できます。Quick Suite により、ユーザーは 40 以上のデータソースとの統合を備えたインテリジェントな会話エージェントをわずか数分で起動して埋め込むことができます。 この記事では、Quick Suite の埋め込み統合チャットの力を解き放ち、AI を活用したアシスタンスをワークフローに直接組み込む方法をご紹介します。 主な機能とメリット 埋め込み統合チャット機能は、以下の主要なメリットを提供します。 構造化データと非構造化データにわたる統合チャット体験 – 埋め込みチャットは、ダッシュボード、ファイル、メモ、接続されたソースなどのさまざまなデータを使用した Quick Suite のエージェント型推論をアプリケーションに組み込みます。ユーザーは自然言語で質問し、要約を探索し、インサイトを比較し、利用可能なアクションを実行できます。これらすべてが、構造化データソースと非構造化データソースにわたってシームレスに動作する 1 つの連続したフローで行えます。 使い慣れたアプリケーションとの連携 – Quick Suite は、チームのアプリケーションを会話に直接組み込みます。これらの接続を通じて、ユーザーは SharePoint や OneDrive に保存されたドキュメントを検索したり、Slack でメッセージを送信したり、Jira でタスクを作成したり、MCP を通じて有効化されたカスタム接続を使用したりできます。これらすべてをチャットから離れることなく行えます。ユーザーは、既に作業している場所で必要な情報とアクションに即座にアクセスできます。 ワンクリック埋め込み – Quick Suite を使用すると、Quick Suite インターフェースからコードをコピーしてエンタープライズアプリケーションに挿入するだけで、数分以内にチャットエージェントをアプリケーションに埋め込むことができます。 セキュリティとアクセス制御 – 埋め込みチャットはデフォルトでセキュアです。埋め込み会話体験を支えるデータは、お客様の管理下に置かれます。エージェントがアクセスできるもの（キュレーションされた Space、既存の Q インデックス、または接続されたデータソース）を選択できます。アクションも明示的にスコープが設定されており、チームは Quick Suite のエージェント型 AI の恩恵を受けながら完全なガバナンスを維持できます。 企業ブランドに合わせたカスタマイズ可能なビジュアルテーマ – Quick Suite は、組織のブランドアイデンティティを埋め込みチャット体験に直接拡張する強力なカスタマイズ機能を提供します。企業のブランドカラーで Quick Suite をカスタマイズし、プラットフォーム全体で一貫したビジュアルアイデンティティを作成できます。iframe を使用して Quick Suite チャット機能をアプリケーションに統合できるため、ウィジェットは追加の設定なしでブランドの外観と操作感をシームレスに継承します。 企業のコミュニケーションスタイルに合わせたカスタマイズ可能なトーン – Quick Suite では、すべてのインタラクションに企業独自の声を吹き込むことができます。企業のコミュニケーションスタイルと専門知識を反映したカスタム指示を持つカスタムチャットエージェントを作成し、プロフェッショナルでフォーマル、フレンドリーで会話的、または技術的で正確など、トーンを設定できます。Quick Suite では、ブランドアイデンティティに沿ったパーソナライズされたウェルカムメッセージでユーザーを迎えることができ、会話が適切なトーンで始まります。また、回答のフォーマット方法に関する具体的な指示や、ユースケースに固有の質問への回答に関するヒントを与えることもできます。 ビジュアルテーマから会話のトーン、アプリケーション統合まで、この包括的なカスタマイズにより、埋め込みチャットウィジェットは既存のアプリケーションに自然に溶け込み、ユーザーに一貫したブランド体験を提供します。 Quick Suite の埋め込みチャット機能は、 既存の Quick Suite 料金 で追加費用なしでご利用いただけます。 ソリューション概要 統合チャットを埋め込むには、 GenerateEmbedUrlForRegisteredUser または GenerateEmbedUrlForRegisteredUserWithIdentity API を使用する必要があります。アプリケーションでユーザーに表示するには、QuickSight Embedding SDK バージョン 2.11.0 以上を使用する必要があります。 前提条件 以下の前提条件を満たしていることを確認してください。 Quick Suite が有効化された AWS アカウント。Quick Suite アカウントをお持ちでない場合は、 サインアップ できます。Quick Suite 無料トライアルの開始手順については、 Amazon Quick Suite の開始方法 を参照してください。 ロールを引き受けるユーザーに権限を付与するための関連ポリシーを持つ AWS Identity and Access Management （IAM）ロール。以下はサンプルポリシーステートメントです。 { "Action": [ "quicksight:GenerateEmbedUrlForRegisteredUser" ], "Resource": "*", "Effect": "Allow" } ダッシュボードを埋め込むドメインを許可リストに追加します。これは Quick Suite コンソールの Manage Amazon Quick Suite メニューの Security / Manage domains で行えます。 統合チャットエージェントの埋め込みは、現在 Professional または Enterprise ライセンス を持つ登録ユーザーが利用できます。Quick Suite でユーザーがプロビジョニングされていることを確認してください。 チャットエージェントの作成 チャットエージェントを埋め込むには、まず Quick Suite アプリケーションでカスタムチャットエージェントを作成して設定します。カスタムチャットエージェントを構築することで、自然言語を使用してエージェントのペルソナを定義します。エージェントが誰であるか（アイデンティティと役割）、エージェントが何をするか（コア責任）、エージェントがどのようにコミュニケーションするか（トーンとスタイル）を定義します。さらに、チャットエージェントのナレッジソース（ダッシュボード、トピック、非構造化データを含む）、およびチャット体験の不可欠な部分としてエージェントがさらなるステップを実行するためのアクションと統合（Slack、Outlook、Jira など）を設定できます。チャットエージェントの作成手順については、 Amazon Quick Suite での AI 搭載チャットエージェントの作成、カスタマイズ、デプロイ を参照してください。 ワンクリックエンタープライズ埋め込み ワンクリック埋め込みを使用すると、Quick Suite から iframe に追加される静的な埋め込みコードで Quick Suite 統合チャットエージェントを埋め込むことができます。ユーザーがイントラネットエンタープライズアプリケーションでチャットエージェントにアクセスすると、Quick Suite へのサインインが求められます。以下のスクリーンショットは、埋め込みコードを取得する方法を示しています。 登録ユーザー埋め込み 登録ユーザー埋め込みを使用して統合チャットエージェントを埋め込むこともできます。登録ユーザー埋め込みでは、組織の既存のエンタープライズ認証インフラストラクチャを使用しながら、Quick Suite チャットエージェントをカスタムアプリケーションにシームレスに統合できます。ユーザーは企業の ID プロバイダーを通じて 1 回認証するだけで、追加のログインプロンプトなしでチャットエージェントにアクセスできます。さらに、各ユーザーはアクセスを許可された情報のみを表示するパーソナライズされた会話体験を受け取り、企業が必要とする堅牢なセキュリティ基準を維持します。 このセクションの以下の手順を完了して、API を使用して統合チャットエージェントを埋め込みます。 セキュアな埋め込み URL の生成 GenerateEmbedUrlForRegisteredUser または GenerateEmbedUrlForRegisteredUserWithIdentity Quick Suite API を使用して、セキュアな埋め込み URL を生成して抽出します。以下は Python コードスニペットのサンプルです。詳細な例については、 SDK ドキュメント を参照してください。 # QuickChat 体験用の埋め込み URL を生成 response = quicksight_client.generate_embed_url_for_registered_user( AwsAccountId='<ACCOUNT_ID>', # 12 桁の AWS アカウント ID UserArn='<USER_ARN>', # 登録済み QuickSight ユーザーの ARN ExperienceConfiguration={ 'QuickChat': {} # QuickChat 埋め込み体験を指定 }, AllowedDomains=[ '<URL>', # 埋め込みが許可されるドメイン ] ) # レスポンスから埋め込み URL を抽出 embed_url = response['EmbedUrl'] ExperienceConfiguration パラメータの 'QuickChat': {} は、Quick Suite チャットエージェントインターフェースを埋め込むことを指定します。 チャットインターフェースの設定 QuickSight Embedding SDK を使用して、Web アプリケーションでチャットインターフェースをレンダリングします。以下の主要な設定オプションを使用します。 frameOptions.url – 前のステップで生成したセキュアな埋め込み URL を指定します。 frameOptions.container – チャットを含む DOM 要素の CSS セレクターを指定します。 contentOptions.fixedAgentArn – 特定のカスタムチャットエージェントを埋め込むためのオプションの Amazon リソースネーム（ARN）を指定します。デフォルトは Quick Suite システムチャットエージェントです。 カスタムチャットエージェント ARN を取得するには、以下の手順を完了します。 Quick Suite コンソールで、ナビゲーションペインの Explore を選択し、 Chat agents を選択します。 Action 列で、 Chat の横にあるオプションメニューを選択し、 View chat agent details を選択します。 チャットエージェント名の横にある Copy link を選択します。 リンクは以下の URL のようになります。 https://us-east-1.quicksight.aws.amazon.com/sn/start/agents?view=6fxxxxxx-xxxx-xxxx-xxxx-xxxxxx43137d view= の後のテキストがエージェント ID です。 エージェント ARN は arn:aws:quicksight:us-east-1:<<aws-account-id>>:agent/<<agent-id>> の形式です。 以下のコードサンプルは、統合チャット体験をロードするために使用される frameOptions と contentOptions パラメータを示しています。 // iframe コンテナとサイズを設定 const frameOptions = { url: "<YOUR_EMBED_URL>", // ステップ 1 のバックエンド呼び出しからの URL container: '#experience-container', height: "700px", width: "1000px", onChange: (changeEvent, metadata) => { switch (changeEvent.eventName) { case 'FRAME_MOUNTED': { console.log("QuickChat frame successfully mounted"); break; } case 'FRAME_LOADED': { console.log("QuickChat experience loaded and ready"); break; } } }, }; // チャット固有のオプションを設定 const contentOptions = { fixedAgentArn: '<AGENT_ARN>', // オプション: 埋め込むエージェント ARN を指定 onMessage: async (messageEvent, experienceMetadata) => { switch (messageEvent.eventName) { case 'CONTENT_LOADED': { console.log("QuickChat interface initialized successfully"); break; } } } }; 実際のユースケース 実際のアプリケーション: 財務パフォーマンスダッシュボードに埋め込まれた財務分析アシスタント 架空の企業が、基盤となる財務データセットとビジネスコンテキストドキュメントの知識を持つカスタムチャットエージェント（財務分析アシスタント）を財務パフォーマンスダッシュボードに埋め込んでいます。このダッシュボードは、経営幹部、社内財務チーム、プロダクトオーナー、リージョナルマネージャー、セールスリーダーを含むビジネスリードなど、数百人の多様なユーザーがアクセスしています。 データアクセスの民主化とセルフサービス分析 チャットエージェントはトピック設定を使用して基盤となるデータセットにリンクされているため、技術に詳しくないユーザーでも独立してデータを探索できます。フィルターやパラメータに慣れていないユーザーでも、「EMEA リージョンの売上高は？」、「2024 年第 3 四半期の収益は？」、「前四半期で収益成長率が最も高かった国は？」などの自然言語で質問できます。 ビジネスユーザーは、セルフサービスダッシュボードを操作する際に、日常的にフォローアップリクエストを行います。チャットエージェントの助けを借りて、BI チームに頼ることなく、追加のデータクエリやレポートの生成を自動化できるようになりました。たとえば、エージェントに以下のような要約を生成させることで、定型的なレポート作成タスクを効率化できます。 「主要な指標とトレンドをハイライトした、経営チーム向けの月次財務サマリーを作成して」 「すべての部門にわたって、予算目標に対するパフォーマンスを比較して」 「今四半期の製品ライン別の利益率を表示して」 データからリアルタイムインサイトへ: 「どのように」と「なぜ」を理解する さらに、ダッシュボードの構造化データと企業ドキュメント（取締役会報告書、戦略メモ、市場分析）の非構造化データを組み合わせたエージェントを埋め込むことで、エンドユーザーはダッシュボードを離れたりアプリケーションを切り替えたりすることなく、データの背後にある「どのように」と「なぜ」についてリアルタイムで質問できます。収益減少チャートを見ながら、すぐに「この減少の原因は？」と質問し、表示されているデータと基盤となるドキュメントを組み合わせた回答を得ることができます。以下のような質問が考えられます。 「第 2 四半期と比較して第 3 四半期に収益が 15% 減少した理由は？」 「製品 A の利益率が今四半期 8% 低下しているのが見えます。製品戦略チームは前回の四半期レビューで何を推奨しましたか？」 「今月ソフトウェアライセンスに 45,000 ドルを計上しています。会計ポリシーマニュアルによると、これはどのように分類すべきですか？」 インサイトからリアルタイムアクションへ: 意思決定を促進する統合 埋め込みチャットエージェントがメールやチケットシステムなどの外部アプリケーションと統合されているため、財務ダッシュボードは受動的なレポートツールから、チームのワークフローシステムで直接アクションを開始および追跡できるアクティブなコマンドセンターに変わります。以下のようなユースケースが考えられます。 Slack を通じてステークホルダーにアラート – 第 4 四半期の営業費用の異常に気づいた後、財務アナリストはチャットエージェントに「この経費スパイクを要約し、このダッシュボードへのリンクを含めて財務ディレクターに Slack を送信して」と依頼できます。 Asana でフォローアップを作成 – ダッシュボードのインサイトから直接、リージョナルマネージャーは「この収益減少をレビューするための Asana タスクを国別リードに作成して。優先度を高に設定し、期限を来週金曜日にして」と言えます。 まとめ Quick Suite 埋め込みチャットのリリースは、AI を活用した会話をエンタープライズワークフロー内でよりアクセスしやすく統合されたものにするための大きな前進を表しています。このリリースは、組織が今日直面している根本的な課題、つまり使い慣れた作業環境を離れることなく強力な AI 機能にアクセスできるようにすることに対応しています。このソリューションは、エンタープライズグレードのセキュリティとブランドの外観と操作感に適応する広範なカスタマイズオプションを提供しながら、ツールの断片化という課題を解決します。自然言語クエリによるデータ探索、構造化ソースと非構造化ソースにわたるインサイトの接続、ワークフローアクションのトリガーなど、Quick Suite 埋め込みチャットはニーズに合わせて成長する包括的なソリューションを提供します。拡張されたブランディングコントロールや匿名ユーザーのサポートなどの今後の機能でプラットフォームを強化し続ける中、組織がこのテクノロジーでユーザー体験をどのように変革するかを楽しみにしています。 Quick Suite SDK と体験固有のオプションの詳細については、 GitHub リポジトリ をご覧ください。 Quick Suite コミュニティ に参加して、質問、回答、学習を行い、追加のリソースを探索してください。 著者について Salim Khan は Amazon Quick Suite のスペシャリストソリューションアーキテクトです。Salim は 16 年以上のエンタープライズビジネスインテリジェンス（BI）ソリューションの実装経験を持っています。AWS 入社前は、自動車、ヘルスケア、エンターテインメント、消費財、出版、金融サービスなどの業界バーティカルに対応する BI コンサルタントとして働いていました。企業全体でビジネスインテリジェンス、データウェアハウジング、データ統合、マスターデータ管理ソリューションを提供してきました。 Pallavi Sharma は Amazon Quick Suite のプリンシパルプロダクトマネージャーで、Quick Suite ポートフォリオ全体の埋め込みをリードしています。クラウドモダナイゼーションおよび管理ツール、ローコードプラットフォーム、AI 駆動ソリューションにわたるエンタープライズソフトウェアの構築とスケーリングで 10 年以上の経験を持っています。電気工学を専攻し、半導体業界で ASIC 設計エンジニアとしてキャリアをスタートしました。Pallavi は、組織が AI の力を解き放ち、人々の働き方を簡素化する直感的で人間中心の製品を作ることに情熱を注いでいます。 Marisa Parker は Amazon Quick Suite のシニア UX デザインマネージャーで、エンタープライズ AI 体験を構築するデザイナーチームをリードしています。10 年以上の経験を持ち、開発者ツール、クラウドプラットフォーム、エンタープライズリソースプランニングシステムのデザインチームをリードするなど、テクノロジー業界全体で AI 体験を形作ってきました。ユーザーが AI を使用して生産性を向上させ、ワークフローを効率化する直感的な体験を作ることに情熱を注いでいます。 Joy Cheng は AWS のシニアビルダーで、業界全体のエンタープライズクライアント向けの Amazon Quick Suite 実装に注力しています。Amazon Music と NBCUniversal で分析エンジニアリングおよびリーダーシップポジションを務めるなど、エンタープライズデータソリューションで 10 年以上の経験を持ち、コンサルティングポートフォリオはアフリカとアジアの米国政府および省庁向けの教育および健康イニシアチブにまで及びます。UC Irvine と UCSD のデータ分析ブートキャンプの元インストラクターとして、AI とデータ分析をすべての人がアクセスできるようにすることに情熱を注いでいます。 この記事は Kiro が翻訳を担当し、ソリューションアーキテクト の 守田 凜々佳 がレビューしました。

本記事は「 Introducing Kiro autonomous agent 」を翻訳したものです。 IDE アシスタントは、AI 開発者ツールの第一波でした。シンプルなインライン補完から始まり、チャットインターフェースへと発展し、IDE から直接マルチステップタスクを計画・実行できるエージェント型ワークフローへと進化しました。その後、CLI アシスタントが登場し、コマンドラインにも AI サポートをもたらしました。 今年の初めに、私たちはこれらの AI ワークフローに構造を与える Kiro IDE と Kiro CLI を発表しました。ローカルマシンでエージェントと直接作業するには最適なツールです。エージェント型ワークフローは進化を続けており、新しいクラスのエージェントが登場しています。それは独立して動作し、コンテキストを維持し、あらゆるやり取りから学習する最先端エージェントです。 本日、開発者とチームがソフトウェアを構築・運用する方法を変革する 3 つの新しい最先端エージェント の 1 つである、Kiro autonomous agent のプレビュー版をリリースします。 Kiro autonomous agent は、Kiro Pro、Pro+、Power プランを契約されている個人開発者向けにプレビュー版として順次展開されています。プレビュー期間中は無料で、使用量は週次制限があります。チームは早期アクセスのために ウェイトリストに参加できます 。 開発コンテキストのギャップ ほとんどの AI コーディングアシスタントでは、コンテキストを積極的に管理する必要がありますが、これは簡単ではありませんでした。設定やパターンを常に再説明したり、リポジトリにコンテキストを保存するシステムを構築したりする必要があります。そして、これらはセッションベースです。セッションを閉じると、すべてを忘れてしまいます。複数のリポジトリで作業する際は特に困難になります。各リポジトリでコンテキストを設定し、エージェントにそれぞれへのアクセスを与える必要があります。 15 のマイクロサービスで使用されている重要なライブラリをアップグレードする必要があるとしましょう。 自分で行う場合 ： 各リポジトリを開き、依存関係を更新し、破壊的変更を修正し、テストを実行し、PR を作成する必要があります。これを 15 回繰り返すと、数日分の作業になる可能性があります。 エージェント型 IDE/CLI を使用する場合 ： 手動よりは速くなります。最初のリポジトリを開き、エージェントにライブラリの更新を指示し、変更をレビューし、見落としを修正し、テストを実行し、PR を作成します。その後、リポジトリ 2 に移動して最初からやり直し。すべてのリポジトリで作業に関与し続ける必要があり、セッションを閉じるとエージェントはすべてを忘れてしまいます。 Kiro autonomous agent の場合 ： 一度説明するだけです。マルチリポジトリ作業を統一されたタスクとして扱い、影響を受けるリポジトリを特定し、各サービスがライブラリをどのように使用しているかを分析し、あなたのパターンに従ってコードを更新し、完全なテストスイートを実行し、あなたが他の作業をしている間に 15 のテスト済みプルリクエストをレビュー用に開きます。 違いは何でしょうか？ Kiro autonomous agent はセッションベースではありません。常にそこにあり、作業全体でコンテキストを維持します。エラーハンドリングについて1つの PR でフィードバックを与えると、それを記憶し、その後の変更にそのパターンを適用します。類似のアーキテクチャ決定に遭遇すると、既存の実装と設定を考慮します。コードベースを再説明したり、同じ作業を繰り返したりする必要はありません。エージェントはすでにあなたの働き方を知っており、やり取りのたびに向上していきます。 仕組み Kiro autonomous agent の展開に伴い、有料プランのユーザーは オンラインアカウント でアクセスできるようになります。チャットしたり、必要な変更や改善を説明したりして、最大 10 のタスクを同時に実行できます。エージェントは独立して作業を完了する方法を見つけ出します。 タスクを割り当てると、Kiro autonomous agent は以下のことを行います。 開発セットアップを反映した独立したサンドボックス環境を立ち上げ リポジトリをクローンしてコードベースを分析 作業を分解し、要件と受け入れ基準を定義 専門化されたサブエージェントを調整（1 つは調査と計画を担当、もう 1 つはコードを書き、検証エージェントが進行前に出力をチェック） 作業の任意の側面について不確実な場合は質問 変更と実装決定の詳細な説明とともにプルリクエストを開く 各タスクは、設定可能なネットワークアクセス、環境変数、開発環境設定を持つ独自の独立したサンドボックスで実行されます。Kiro autonomous agent は非同期で実行されるため、開発環境を適切にセットアップし、テストスイートを実行し、変更を検証するのに必要な時間を取ることができ、その間あなたは他の作業に集中できます。 Kiro autonomous agent との作業 Kiro autonomous agent とチャットして、アプローチを議論したり、質問したり、作業についてコンテキストを提供したりします。委任する準備ができたら、タスクを作成するよう依頼します。 タスク作成前 チャットを使用して異なる実装アプローチを議論し、要件や制約を明確にし、技術的決定についてエージェントの意見を求めます。エージェントはウェブ検索、以前のコードレビューからの学習、他のタスクからのコンテキストにアクセスして、情報に基づいた回答を提供します。 タスク実行中 タスクが作成されたら、チャットを続けて実装アプローチを指導したり、追加要件を提供したり、初期結果をレビューした後にエージェントにより多くの作業を依頼したりします。コメントや指導は現在のタスクの範囲を更新します。異なるタスクで作業するには、新しいチャットを開始します。 GitHub からのタスク割り当て GitHub イシューから直接作業を割り当てることもできます。任意のイシューに kiro ラベルを追加するか、コメントで /kiro に言及して、その特定のタスクを Kiro autonomous agent に割り当てます。エージェントは追加のコンテキストやフィードバックのために イシューのすべてのコメントを聞きます。 コードレビューから学習 「常に標準のエラーハンドリングパターンを使用する」や「チームの命名規則に従うことを忘れずに」などの PR フィードバックを残すと、Kiro autonomous agent はその PR を修正するだけではありません。それを記憶し、将来の作業にそれらのパターンを自動的に適用します。 作業を続けるにつれて、エージェントはあなたのコード、製品、従う標準をより良く理解し、その後のすべてのタスクを改善する知識を構築します。 安全で設定可能な実行 エージェントが実行する各タスクは、設定可能なアクセス制御を持つ独立したサンドボックスで動作します。権限、ネットワークアクセス、エージェントが触れることができるリソースを制御します。 ネットワークアクセス制御 各タスクに対して 3 つのレベルから選択できます。統合のみ（サンドボックスは GitHub プロキシのみにアクセス）、共通依存関係（npm、PyPI、Maven などのパッケージレジストリへのアクセス）、またはオープンインターネット。正確な制御のためにカスタムドメイン許可リストを定義することもできます。 MCP 統合 MCP 統合はタスク実行中に使用され、Kiro により多くのツールへのアクセスを提供します。個別のタスクのために Model Context Protocol サーバーを通じて専門ツールや独自システムを接続します。 環境変数とシークレット 個別のタスク実行中にエージェントが利用できる環境変数とシークレットを設定します。シークレットは暗号化されて保存され、ログやプルリクエストで公開されることはありません。 環境設定 エージェントはリポジトリ内の DevFiles や Dockerfiles を自動的に検出して、適切な依存関係、ビルドコマンド、ランタイム要件でサンドボックス環境を設定します。どちらも見つからない場合、エージェントはプロジェクト構造を分析してプロジェクトの環境を設定します。 チーム向け Kiro autonomous agent チームにとって、Kiro autonomous agent は全員と一緒に働く共有リソースとなり、コードベース、製品、標準の集合的理解を構築します。独立して動作する個別の AI アシスタントとは異なり、チームエージェントは仕様、議論、プルリクエストを統一されたメモリに織り込み、チーム全体をより効果的にします。 新しい決済処理機能を構築するチームを考えてみましょう。1人の開発者がコードレビューを通じてチームのエラーハンドリングパターンをエージェントに教えます。数日後、別の開発者がエージェントに返金ワークフローの実装を割り当てます。エージェントはすでにそれらのパターンを知っており、誰も標準を再説明する必要なく、機能全体で一貫性を保ちながら自動的に適用します。 より速く一緒に出荷 エージェントは複数のリポジトリとタスクで並行して開発作業を実行するため、リリースはボトルネックを減らして前進します。1人の開発者が API 再設計に集中している間、エージェントはワークフローの一部として、クライアントライブラリ、ドキュメント、統合テストの対応する更新を処理します。 スタック全体で動作 チームのリポジトリ、パイプライン、コラボレーションツール（Jira、GitHub、GitLab、Teams、Slack、Confluence）を接続して、作業が進行するにつれてエージェントがコンテキストを維持できるようにします。誰かが Confluence で仕様を更新したり、Jira チケットにコメントしたり、Slack でアプローチを議論したりすると、エージェントはそのコンテキストをタスクに組み込み、変更がチームのベストプラクティスと一致することを保証します。 チームから学習 コードレビュー、機能リクエストやバグ、アーキテクチャ決定がエージェントの理解の一部になります。文書化されたものだけでなく、チームが実際にどのように働き、どのパターンを好むかから学習します。この学習により、エージェントは一般的なコーディングが上手になるだけでなく、時間をかけて特定のチームをより良くサポートできるようになります。 チームはすばやいアクセスのために ウェイトリスト に参加できます。 Kiro autonomous agent のプレビュー版を Kiro Pro、Pro+、Power ユーザー向けに段階的に展開を開始しています。 詳細を確認 するか、 サインインして利用可能 かをチェックしてください。

本記事は2025年11月19日に公開された「 Building responsive APIs with Amazon API Gateway response streaming 」を翻訳したものです。 本日、AWS は Amazon API Gateway でレスポンスストリーミングのサポートを発表しました。これにより、レスポンスペイロードをクライアントに段階的にストリーミングすることで、REST API の応答性を大幅に向上させることができます。この新機能により、ストリーミングレスポンスを使用して、LLM 駆動アプリケーション (AI エージェントやチャットボットなど) を構築する際のユーザーエクスペリエンスを向上させたり、Web およびモバイルアプリケーションの time-to-first-byte (TTFB)パフォーマンスを改善したり、大きなファイルをストリーミングしたり、 server-sent events (SSE) などのプロトコルを使用して段階的な進捗を報告しながら長時間実行される操作を実行したりできます。 この記事では、この新機能、それが対処する課題、およびレスポンスストリーミングを使用してアプリケーションの応答性を向上させる方法について説明します。 概要 次のシナリオを考えてみましょう。 Amazon Bedrock の 基盤モデル を使用する AI 駆動のエージェントアプリケーションを実行しているとします。ユーザーは API を介してアプリケーションと対話し、詳細な回答を必要とする複雑な質問をします。レスポンスストリーミング以前は、ユーザーはプロンプトを送信し、最終的にアプリケーションのレスポンスを受け取るまで待機する必要があり、場合によっては数十秒かかることもありました。この質問と回答の間の不自然な間は、切断された不自然なエクスペリエンスを生み出していました。 新しい API Gateway レスポンスストリーミング機能により、API を介した対話がはるかに流動的で自然なものになります。アプリケーションがモデルのレスポンスの処理を開始するとすぐに、API Gateway を使用してユーザーにストリーミングで返すことができます。 次のアニメーションは、この大幅なユーザーエクスペリエンスの向上を示しています。左側のプロンプトは非ストリーミングレスポンスを使用して処理され、ユーザーは結果を受け取るまで数秒待つ必要があります。右側のプロンプトは新しい API Gateway レスポンスストリーミングを使用しており、TTFB を大幅に削減し、ユーザーエクスペリエンスを向上させています。 図1. Bedrock 基盤モデルからレスポンスを返す際の API Gateway レスポンスストリーミング有効化前（左）と有効化後（右）のユーザーエクスペリエンスの比較 ユーザーは、誰かがタイピングしているのを見るように、AI のレスポンスが単語ごとにリアルタイムで表示されるのを確認できるようになりました。この即座のフィードバックにより、アプリケーションがよりレスポンシブで魅力的に感じられ、対話全体を通じてユーザーとの接続が維持されます。さらに、レスポンスサイズの制限を心配したり、複雑な回避策を実装したりする必要はありません。ストリーミングは自動的かつ効率的に行われるため、インフラストラクチャの制約を管理するのではなく、優れたユーザーエクスペリエンスの構築に集中できます。 レスポンスストリーミングの理解 従来のリクエスト・レスポンスモデルでは、レスポンスはクライアントに送信される前に完全に計算される必要があります。これはユーザーエクスペリエンスに悪影響を及ぼす可能性があります。クライアントは、サーバー側で完全なレスポンスが生成され、ネットワーク経由で送信されるまで待つ必要があります。これは、AI エージェント、チャットボット、バーチャルアシスタント、音楽ジェネレーターなどのインタラクティブでレイテンシーに敏感なクラウドアプリケーションで特に顕著です。 図2. レスポンスは完全に生成された後にのみクライアントに返され、time-to-first-byte レイテンシーが増加します もう1つの重要なシナリオは、画像、大きなドキュメント、データセットなどの大きなレスポンスペイロードを返すことです。場合によっては、これらのペイロードが API Gateway の 10 MB のレスポンスサイズ制限またはデフォルトの統合タイムアウト制限である 29 秒を超える可能性があります。レスポンスストリーミングの開始前は、開発者は 署名付き Amazon S3 URL を使用して大きなレスポンスをダウンロードしたり、タイムアウトの増加と引き換えに低い RPS を受け入れたりすることで、これらの制限を回避していました。機能的ではありますが、これらの回避策は追加のレイテンシーとアーキテクチャの複雑さをもたらしました。 レスポンスストリーミングのサポートにより、これらの課題に対処できます。REST API を更新してストリーミングレスポンスを返すことができるようになり、ユーザーエクスペリエンスを大幅に向上させ、TTFB パフォーマンスを改善し、10 MB を超えるレスポンスペイロードサイズをサポートし、最大 15 分かかるリクエストを処理できます。 図3. レスポンスストリーミングは最初のバイトまでの時間を短縮し、ユーザーエクスペリエンスを向上させます レスポンスストリーミング機能は、すでに組織に大きなパフォーマンスをもたらしています。 「AWS チームと緊密に連携してレスポンスストリーミングを有効にすることは、Salesforce Commerce Cloud で最大の顧客に最もパフォーマンスの高いストアフロントエクスペリエンスを提供するためのロードマップを進める上で重要でした。私たちのコラボレーションは、Core Web Vital の目標を超えました。Total Blocking Time メトリクスが 98% 以上低下し、顧客がより高い収益とコンバージョン率を促進できるようになります」と、Salesforce のプロダクトマネジメント シニアディレクターである Drew Lau 氏は述べています。 レスポンスストリーミングは、任意の HTTP プロキシ統合 、 AWS Lambda 関数（プロキシ統合モードを使用）、および プライベート統合 でサポートされています。開始するには、次のセクションで説明するように、バックエンドからレスポンスをストリーミングするように API 統合を設定し、変更を有効にするために API を再デプロイします。 レスポンスストリーミングの開始 REST API のレスポンスストリーミングを有効にするには、統合設定を更新してレスポンス転送モードを STREAM に設定します。これにより、API Gateway はレスポンスバイトが利用可能になるとすぐにクライアントへのレスポンスのストリーミングを開始できます。レスポンスストリーミングを使用する場合、リクエストタイムアウトを最大 15 分まで設定できます。最初のバイトまでの時間を最適化するために、AWS はバックエンド統合もレスポンスストリーミングを実装することを強く推奨します。 次のスニペットに示すように、いくつかの異なる方法でレスポンスストリーミングを有効にできます。 API Gateway コンソールを使用して、メソッド統合を作成する際に、レスポンス転送モードで「ストリーム」を選択します。 図4. API Gateway コンソールでレスポンスストリーミングを有効にする Open API 仕様を使用してレスポンス転送モードを設定する場合： paths : /products : get : x-amazon-apigateway-integration : httpMethod : "GET" uri : "https://example.com" type : "http_proxy" timeoutInMillis : 300000 responseTransferMode : "STREAM" AWS CloudFormation などの Infrastructure as Code（IaC）フレームワークを使用してレスポンス転送モードを設定する場合、 /response-streaming-invocations Uri フラグメントに注意してください。これは、Lambda InvokeWithResponseStreaming エンドポイントを使用するように API Gateway に指示します。 MyProxyResourceMethod : Type : 'AWS::ApiGateway::Method' Properties : RestApiId : !Ref LambdaSimpleProxy ResourceId : !Ref ProxyResource HttpMethod : ANY Integration : Type : AWS_PROXY IntegrationHttpMethod : POST ResponseTransferMode : STREAM Uri : !Sub arn : aws : apigateway : $ { APIGW_REGION } : lambda : path/2021 - 11 - 15/functions/$ { FN_ARN } /response - streaming - invocations AWS CLI を使用してレスポンス転送モードを更新する場合： aws apigw update-integration \ --rest-api-id a1b2c2 \ --resource-id aaa111 \ --http-method GET \ --patch-operations "op='replace',path='/responseTransferMode',value=STREAM" \ --region us-west-2 Lambda 関数でのレスポンスストリーミングの使用 Lambda 関数をダウンストリーム統合エンドポイントとして使用する場合、Lambda 関数は ストリーミング対応 である必要があります。次の図に示すように、API Gateway は InvokeWithResponseStreaming API を使用して関数を呼び出し、Lambda プロキシ統合が必要です。詳細については、 API Gateway ドキュメント を参照してください。 図5. インタラクティブな AI アプリケーション用の Lambda 関数での API Gateway レスポンスストリーミングの使用 Lambda 関数でレスポンスストリーミングを使用する場合、API Gateway はハンドラーレスポンスストリームに次のコンポーネントが（順番に）含まれることを期待します。 JSON レスポンスメタデータ – 有効な JSON オブジェクトである必要があり、 statusCode 、 headers 、 multiValueHeaders 、および cookies フィールド（すべてオプション）のみを含めることができます。メタデータは空の文字列にすることはできません。少なくとも空の JSON オブジェクトである必要があります。 8 バイトの null 区切り文字 – 以下に示すように、組み込みの awslambda.HttpResponseStream.from() メソッドを使用すると、Lambda がこの区切り文字を自動的に追加します。このメソッドを使用しない場合は、自分で区切り文字を追加する必要があります。 レスポンスペイロード – 空にすることができます。 次のコードスニペットは、API Gateway レスポンスストリーミングと互換性があるように Lambda 関数からストリーミングレスポンスを返す方法を示しています。 export const handler = awslambda . streamifyResponse ( async ( event , responseStream , context ) => { const httpResponseMetadata = { statusCode : 200 , headers : { 'Content-Type' : 'text/plain' , 'X-Custom-Header' : 'some-value' } } ; responseStream = awslambda . HttpResponseStream . from ( responseStream , httpResponseMetadata ) ; responseStream . write ( 'hello' ) ; await new Promise ( r => setTimeout ( r , 1000 ) ) ; responseStream . write ( ' world' ) ; await new Promise ( r => setTimeout ( r , 1000 ) ) ; responseStream . write ( '!!!' ) ; responseStream . end ( ) ; } ) ; 詳細な実装ガイドラインについては、 API Gateway ドキュメント を参照してください。 HTTP プロキシ統合でのレスポンスストリーミングの使用 ダウンストリーム統合エンドポイントとして使用されるアプリケーション（たとえば、 Amazon Elastic Container Service （Amazon ECS）または Amazon Elastic Kubernetes Service （Amazon EKS）で実行されている Web サーバー）から HTTP レスポンスをストリーミングできます。この場合、 HTTP_PROXY 統合を使用し、レスポンス転送モードを STREAM として指定する必要があります（コンソール、AWS CLI、または IaC を使用）。API を変更した後、再デプロイします。 図6. HTTP サーバーアプリケーションでの API Gateway レスポンスストリーミングの使用 API Gateway がアプリケーションからストリーミングレスポンスを受信すると、HTTP ヘッダーブロックの転送が完了するまで待機します。次に、クライアントに HTTP レスポンスステータスコードとヘッダーを送信し、その後、API Gateway サービスが受信したアプリケーションからのコンテンツを送信します。ストリームが終了するまで（最大 15 分）、アプリケーションからクライアントへのレスポンスのストリーミングを続けます。 多くの一般的な API および Web アプリケーション開発フレームワークは、レスポンスストリーミングの抽象化を提供しています。次のコードスニペットは、FastAPI を使用して HTTP レスポンスストリーミングを実装する方法を示しています。 app = FastAPI ( ) async def stream_response ( ) : yield b"Hello " await asyncio . sleep ( 1 ) yield b"World " await asyncio . sleep ( 1 ) yield b"!" @app . get ( "/" ) async def main ( ) : return StreamingResponse ( stream_response ( ) , media_type = "text/plain" ) HTTP クライアントへのリアルタイムレスポンスストリーミングの追加 HTTP クライアントによって、到着したストリーミングレスポンスフラグメントを処理する方法が異なります。次のコードスニペットは、Node.js アプリケーションでストリーミングレスポンスを処理する方法を示しています。 const request = http . request ( options , ( response ) => { response . on ( 'data' , ( chunk ) => { console . log ( chunk ) ; } ) ; response . on ( 'end' , ( ) => { console . log ( 'Response complete' ) ; } ) ; } ) ; request . end ( ) ; CURL を使用する場合、 –no-buffer 引数を使用して、到着したレスポンスフラグメントを出力できます。 curl --no-buffer { URL } サンプルコード GitHub からこのサンプルプロジェクトをクローン して、API Gateway レスポンスストリーミングの動作を確認してください。README.md の手順に従って、AWS アカウントにサンプルプロジェクトをプロビジョニングします。 考慮事項 レスポンスストリーミングを有効にする前に、次の点を考慮してください。 レスポンスストリーミングは REST API で利用でき、HTTP_PROXY 統合、Lambda 統合（プロキシモード）、およびプライベート統合で使用できます。 API Gateway レスポンスストリーミングは、リージョナル、プライベート、エッジ最適化などの 任意のエンドポイントタイプ で、 カスタムドメイン名 の有無にかかわらず使用できます。 レスポンスストリーミングを使用する場合、シナリオの要件に応じて、レスポンスタイムアウトを最大 15 分まで設定できます。 リージョナルまたはプライベートエンドポイントからのすべてのストリーミングレスポンスには、5 分のアイドルタイムアウトが適用されます。エッジ最適化エンドポイントからのすべてのストリーミングレスポンスには、30 秒のアイドルタイムアウトが適用されます。 各ストリーミングレスポンス内で、最初の 10 MB のレスポンスペイロードには帯域幅制限はありません。10 MB を超えるレスポンスペイロードデータは、2 MB/秒に制限されます。 レスポンスストリーミングは、 オーソライザー 、 WAF 、 アクセス制御 、 TLS/mTLS 、 リクエストスロットリング 、および アクセスログ などの API Gateway セキュリティ機能と互換性があります。 ストリーミングレスポンスを処理する場合、次の機能はサポートされていません：VTL によるレスポンス変換、統合レスポンスキャッシング、およびコンテンツエンコーディング。 Lambda オーソライザー または Amazon Cognito ユーザープール で適切な認可を実装することにより、不正アクセスやその他の潜在的なセキュリティ脅威から API を常に保護してください。詳細については、 REST API 保護ドキュメント および API Gateway セキュリティドキュメント を参照してください。 オブザーバビリティ 実行ログ 、 アクセスログ 、 AWS X-Ray 統合、および Amazon CloudWatch メトリクスなどの既存のオブザーバビリティ機能を、API Gateway レスポンスストリーミングで引き続き使用できます。 既存の アクセスログ変数 に加えて、次の新しい変数が利用可能です。 $content.integration.responseTransferMode – 統合のレスポンス転送モード。 BUFFERED または STREAMED のいずれかです。 $context.integration.timeToAllHeaders – API Gateway が統合接続を確立してから、クライアントからすべての統合レスポンスヘッダーを受信するまでの時間。 $context.integration.timeToFirstContent – API Gateway が統合接続を確立してから、最初のコンテンツバイトを受信するまでの時間。 詳細については、 API Gateway ドキュメント を参照してください。 料金 この新機能により、ストリーミングレスポンスに対して同じ API 呼び出し料金を引き続き支払います。10 MB のレスポンスデータごとに、最も近い 10 MB に切り上げられ、1 つのリクエストとして請求されます。詳細については、 API Gateway 料金ページ を参照してください。 まとめ Amazon API Gateway の新しいレスポンスストリーミング機能により、クラウドで応答性の高い API を構築および提供する方法が強化されます。レスポンスデータが利用可能になるとすぐにストリーミングすることで、最初のバイトまでの時間のパフォーマンスを大幅に改善し、従来のペイロードサイズとタイムアウトの制限を克服できます。これは、リアルタイムの応答性を必要とする AI 駆動アプリケーション、ファイル転送、およびインタラクティブな Web エクスペリエンスに特に価値があります。 API Gateway レスポンスストリーミングの詳細については、 サービスドキュメント を参照してください。 サーバーレスアーキテクチャの構築の詳細については、 Serverless Land を参照してください。

本記事は 2025 年 12 月 2 日 に公開された「 Amazon S3 Vectors now generally available with increased scale and performance 」を翻訳したものです。 Amazon S3 Vectors がスケールとパフォーマンスを大幅に向上させて一般提供を開始しました。S3 Vectors は、ベクトルデータの保存とクエリをネイティブにサポートする初のクラウドオブジェクトストレージです。専用のベクトルデータベースソリューションと比較して、ベクトルの保存とクエリの総コストを最大 90% 削減できます。 7 月に S3 Vectors のプレビューを発表 して以来、ベクトルデータの保存とクエリにこの新機能をいかに早く採用いただいたかに感銘を受けています。わずか 4 か月余りで、25 万以上のベクトルインデックスが作成され、400 億以上のベクトルが取り込まれ、10 億以上のクエリが実行されました（11 月 28 日時点）。 単一のインデックスで最大 20 億のベクトルを保存および検索できるようになりました。これはプレビュー時のインデックスあたり 5,000 万から 40 倍の増加であり、ベクトルバケットあたり最大 20 兆のベクトルを格納できます。これにより、ベクトルデータセット全体を 1 つのインデックスに統合でき、複数の小さなインデックスにシャーディングしたり、複雑なクエリフェデレーションロジックを実装したりする必要がなくなります。 クエリパフォーマンスも最適化されました。頻度の低いクエリは引き続き 1 秒未満で結果を返し、頻度の高いクエリでは約 100 ミリ秒以下のレイテンシーを実現しています。これにより、会話型 AI やマルチエージェントワークフローなどのインタラクティブなアプリケーションに適しています。また、クエリあたり最大 100 件の検索結果を取得できるようになり（以前は 30 件）、検索拡張生成（RAG）アプリケーションにより包括的なコンテキストを提供できます。 書き込みパフォーマンスも大幅に向上し、インデックスへの単一ベクトル更新のストリーミング時に最大 1,000 PUT トランザクション/秒をサポートし、小さなバッチサイズでの書き込みスループットが大幅に向上しました。この高いスループットにより、新しいデータをすぐに検索可能にする必要があるワークロードをサポートし、小規模なデータコーパスを迅速に取り込んだり、同じインデックスに同時に書き込む多数の並行ソースを処理したりできます。 完全なサーバーレスアーキテクチャにより、インフラストラクチャのオーバーヘッドが排除されます。セットアップするインフラストラクチャやプロビジョニングするリソースはありません。ベクトルの保存とクエリに応じて使用した分だけ支払います。この AI 対応ストレージにより、初期の実験やプロトタイピングから大規模な本番デプロイメントまで、AI 開発ライフサイクル全体をサポートするために、任意の量のベクトルデータに迅速にアクセスできます。S3 Vectors は、AI エージェント、推論、セマンティック検索、RAG アプリケーション全体で本番ワークロードに必要なスケールとパフォーマンスを提供するようになりました。 プレビューで開始された 2 つの主要な統合が一般提供になりました。 S3 Vectors を Amazon Bedrock ナレッジベースのベクトルストレージエンジンとして使用できます 。特に、本番グレードのスケールとパフォーマンスで RAG アプリケーションを構築するために使用できます。さらに、 S3 Vectors と Amazon OpenSearch の統合が一般提供になりました 。これにより、OpenSearch を検索および分析機能に使用しながら、S3 Vectors をベクトルストレージレイヤーとして使用できます。 S3 Vectors は、プレビュー時の 5 つの AWS リージョンから拡大し、14 の AWS リージョンで使用できるようになりました。 使い方を見てみましょう この記事では、AWS コンソールと CLI を使用して S3 Vectors を使用する方法を説明します。 まず、S3 ベクトルバケットとインデックスを作成します。 echo "Creating S3 Vector bucket..." aws s3vectors create-vector-bucket \ --vector-bucket-name "$BUCKET_NAME" echo "Creating vector index..." aws s3vectors create-index \ --vector-bucket-name "$BUCKET_NAME" \ --index-name "$INDEX_NAME" \ --data-type "float32" \ --dimension "$DIMENSIONS" \ --distance-metric "$DISTANCE_METRIC" \ --metadata-configuration "nonFilterableMetadataKeys=AMAZON_BEDROCK_TEXT,AMAZON_BEDROCK_METADATA" ディメンションメトリクスは、ベクトルの計算に使用されるモデルのディメンションと一致する必要があります。距離メトリクスは、ベクトル間の距離を計算するアルゴリズムを示します。S3 Vectors は コサイン 距離と ユークリッド 距離をサポートしています。 コンソールを使用してバケットを作成することもできます。作成時に暗号化パラメータを設定する機能が追加されました。デフォルトでは、インデックスはバケットレベルの暗号化を使用しますが、カスタムの AWS Key Management Service (AWS KMS) キーを使用して、インデックスレベルでバケットレベルの暗号化をオーバーライドできます。 ベクトルバケットとベクトルインデックスにタグを追加することもできます。ベクトルインデックスのタグは、アクセス制御とコスト配分に役立ちます。 また、コンソールで直接 プロパティ と アクセス許可 を管理できるようになりました。 同様に、 フィルタリング不可のメタデータ を定義し、ベクトルインデックスの 暗号化 パラメータを設定します。 次に、埋め込み（ベクトル）を作成して保存します。このデモでは、私の常に手元にある AWS スタイルガイドを取り込みます。これは、AWS での投稿、技術ドキュメント、記事の書き方を説明する 800 ページのドキュメントです。 Amazon Bedrock ナレッジベース を使用して、汎用 S3 バケットに保存された PDF ドキュメントを取り込みます。Amazon Bedrock ナレッジベースはドキュメントを読み取り、チャンクと呼ばれる断片に分割します。次に、 Amazon Titan Text Embeddings モデルを使用して各チャンクの埋め込みを計算し、ベクトルとそのメタデータを新しく作成したベクトルバケットに保存します。このプロセスの詳細な手順はこの記事の範囲外ですが、 ドキュメントの手順 を参照できます。 ベクトルをクエリする際、ベクトルごとに最大 50 個のメタデータキーを保存でき、そのうち最大 10 個をフィルタリング不可としてマークできます。フィルタリング可能なメタデータキーを使用して、特定の属性に基づいてクエリ結果をフィルタリングできます。したがって、ベクトル類似性検索とメタデータ条件を組み合わせて結果を絞り込むことができます。また、より大きなコンテキスト情報のために、より多くのフィルタリング不可のメタデータを保存することもできます。Amazon Bedrock ナレッジベースはベクトルを計算して保存します。また、大きなメタデータ（元のテキストのチャンク）も追加します。このメタデータは検索可能なインデックスから除外します。 ベクトルを取り込む他の方法もあります。 S3 Vectors Embed CLI を試すことができます。これは、Amazon Bedrock を使用して埋め込みを生成し、直接コマンドで S3 Vectors に保存するのに役立つコマンドラインツールです。また、 OpenSearch のベクトルストレージエンジンとして S3 Vectors を使用 することもできます。 これでベクトルインデックスをクエリする準備ができました。「open source」の書き方について疑問があるとしましょう。ハイフン付きの「open-source」なのか、ハイフンなしの「open source」なのか？大文字を使うべきかどうか？「open source」に関連する AWS スタイルガイドの関連セクションを検索したいと思います。 # 1. Create embedding request echo '{"inputText":"Should I write open source or open-source"}' | base64 | tr -d '\n' > body_encoded.txt # 2. Compute the embeddings with Amazon Titan Embed model aws bedrock-runtime invoke-model \ --model-id amazon.titan-embed-text-v2:0 \ --body "$(cat body_encoded.txt)" \ embedding.json # Search the S3 Vectors index for similar chunks vector_array=$(cat embedding.json | jq '.embedding') && \ aws s3vectors query-vectors \ --index-arn "$S3_VECTOR_INDEX_ARN" \ --query-vector "{\"float32\": $vector_array}" \ --top-k 3 \ --return-metadata \ --return-distance | jq -r '.vectors[] | "Distance: \(.distance) | Source: \(.metadata."x-amz-bedrock-kb-source-uri" | split("/")[-1]) | Text: \(.metadata.AMAZON_BEDROCK_TEXT[0:100])..."' 最初の結果は次の JSON を示しています。 { "key": "348e0113-4521-4982-aecd-0ee786fa4d1d", "metadata": { "x-amz-bedrock-kb-data-source-id": "0SZY6GYPVS", "x-amz-bedrock-kb-source-uri": "s3://sst-aws-docs/awsstyleguide.pdf", "AMAZON_BEDROCK_METADATA": "{\"createDate\":\"2025-10-21T07:49:38Z\",\"modifiedDate\":\"2025-10-23T17:41:58Z\",\"source\":{\"sourceLocation\":\"s3://sst-aws-docs/awsstyleguide.pdf\"", "AMAZON_BEDROCK_TEXT": "[redacted] open source (adj., n.) Two words. Use open source as an adjective (for example, open source software), or as a noun (for example, the code throughout this tutorial is open source). Don't use open-source, opensource, or OpenSource. [redacted]", "x-amz-bedrock-kb-document-page-number": 98.0 }, "distance": 0.63120436668396 } AWS スタイルガイドの関連セクションが見つかりました。「open source」はハイフンなしで書く必要があります。元のドキュメントの関連する段落と提案を照合するのに役立つように、元のドキュメントのページ番号も取得されました。 もう 1 つ S3 Vectors は統合機能も拡張されました。 AWS CloudFormation を使用してベクトルリソースをデプロイおよび管理したり、 AWS PrivateLink を使用してプライベートネットワーク接続を行ったり、コスト配分とアクセス制御のためにリソースタグ付けを使用したりできるようになりました。 料金と利用可能なリージョン S3 Vectors は、プレビューからの既存の 5 つのリージョン（米国東部（オハイオ、バージニア北部）、米国西部（オレゴン）、アジアパシフィック（シドニー）、欧州（フランクフルト））に加えて、アジアパシフィック（ムンバイ、ソウル、シンガポール、東京）、カナダ（中部）、欧州（アイルランド、ロンドン、パリ、ストックホルム）が追加され、14 の AWS リージョンで利用可能になりました。 Amazon S3 Vectors の料金は 3 つの要素に基づいています。 PUT 料金 は、アップロードするベクトルの論理 GB に基づいて計算されます。各ベクトルには、論理ベクトルデータ、メタデータ、キーが含まれます。 ストレージコスト は、インデックス全体の合計論理ストレージによって決まります。 クエリ料金 には、API ごとの料金と、インデックスサイズ（フィルタリング不可のメタデータを除く）に基づく $/TB 料金が含まれます。インデックスが 100,000 ベクトルを超えてスケールすると、$/TB 料金が低くなるメリットがあります。 詳細は Amazon S3 料金ページをご覧ください 。 S3 Vectors を使い始めるには、 Amazon S3 コンソール にアクセスしてください。ベクトルインデックスを作成し、埋め込みの保存を開始し、スケーラブルな AI アプリケーションの構築を始めることができます。詳細については、 Amazon S3 ユーザーガイド または AWS CLI コマンドリファレンス をご覧ください。 これらの新機能で何を構築されるか楽しみにしています。 AWS re:Post または通常の AWS サポート連絡先 を通じてフィードバックをお寄せください。 — seb 著者について Sébastien Stormacq Seb は 80 年代半ばに初めて Commodore 64 に触れて以来、コードを書いています。情熱、熱意、顧客擁護、好奇心、創造性を独自にブレンドして、ビルダーが AWS クラウドの価値を引き出すよう刺激を与えています。彼の関心はソフトウェアアーキテクチャ、開発者ツール、モバイルコンピューティングです。何かを売り込みたい場合は、API があることを確認してください。Bluesky、X、Mastodon などで @sebsto をフォローしてください。 この記事は Kiro が翻訳を担当し、ソリューションアーキテクト の 榎本 貴之 がレビューしました。

2025 年 5 月、私たちは AWS Transform for mainframe をリリースしました。これは、メインフレームのワークロードを大規模にモダナイズするための、初のエージェント型 AI サービスです。AI 搭載のメインフレームエージェントは、モダナイゼーションの各フェーズにおける複雑でリソース集約型の作業を自動化することで、メインフレームのモダナイゼーションを加速します。COBOL、CICS、DB2、VSAM を含むレガシーメインフレームアプリケーションを最新のクラウド環境へ移行するプロセスを効率化でき、モダナイゼーションの期間を数年から数か月に短縮できます。 2025 年 12 月 1 日、 AWS Transform for mainframe において、AI 搭載の分析機能、Reimagine モダナイゼーションパターンのサポート、テスト自動化を含む強化機能を発表しました。これらの強化機能は、メインフレームのモダナイゼーションにおける 2 つの重要な課題を解決します。すなわち、単にクラウドへ移行するだけでなくアプリケーションを完全に変革する必要性と、テストに多大な時間と専門知識が求められる点です。 メインフレームのモダナイゼーションの再構想 – これは、AI を活用した新しいアプローチで、最新の設計パターンを用いるか、バッチ処理からリアルタイム機能への移行を通じて、顧客のアプリケーションアーキテクチャを完全に再構想するものです。強化されたビジネスロジック抽出機能に加え、 AWS Transform を通じた新しいデータ系統分析や自動データ辞書生成を組み合わせることで、顧客は COBOL などで書かれたモノリシックなメインフレームアプリケーションを、マイクロサービスのようなよりモダンなアーキテクチャスタイルに変革できます。 自動テスト — 顧客は、新しい自動テスト計画生成、テストデータ収集スクリプト、およびテストケース自動化スクリプトを利用できます。AWS Transform for mainframe は、データ移行、結果の検証、端末接続のための機能テストツールも提供します。これらの AI 搭載機能は連携して動作し、テストの期間を短縮するとともに、自動化によって精度を向上させます。 メインフレームのモダナイゼーションの再構想と自動化テスト機能について、さらに詳しく見てみましょう。 メインフレームのモダナイゼーションを再構想する方法 メインフレームのモダナイゼーションは、画一的なアプローチでは対応できないことを認識しています。戦術的なアプローチが既存システムの補強や維持に焦点を当てるのに対し、戦略的モダナイゼーションは、 リプラットフォーム 、 リファクター 、 リプレイス 、そして新しい 再構想 といった明確な選択肢を提供します。 再構想パターンでは、AWS Transform の AI 搭載分析がメインフレームのシステム分析と組織の知識を組み合わせ、詳細な業務・技術ドキュメントおよびアーキテクチャの推奨を作成します。これにより、重要なビジネスロジックを保持しつつ、最新のクラウドネイティブ機能を活用できます。 AWS Transform は、メインフレームのモダナイゼーションを成功させるために不可欠な、新しい高度なデータ分析機能を提供します。これには、データ系統分析や自動データ辞書生成が含まれます。これらの機能は連携して、メインフレームデータの使用方法や関係性に加え、その構造と意味を定義します。顧客はデータ全体の状況を完全に把握できるようになり、モダナイゼーションに関する意思決定を的確に行えるようになります。技術チームは、重要なビジネスロジックや関係性を維持しながら、データアーキテクチャを自信を持って再設計できます。 再構想 戦略は「ヒューマン・イン・ザ・ループ（人による検証）」の原則に従っており、AWS Transform や Kiro などのAI生成アプリケーション仕様やコードが、ドメインエキスパートによって継続的に検証されることを意味します。AIの機能と人間の判断によるこの協働アプローチにより、AI 搭載のモダナイゼーションのスピードを維持しながら、変革リスクを大幅に低減できます。 この手法には、レガシーメインフレームアプリケーションをクラウドネイティブのマイクロサービスに変換するための、3 段階の方法論があります。 既存の COBOL やジョブ 制御言語（JCL）コードからビジネスロジックやルールを抽出するリバースエンジニアリングを、AWS Transform for mainframe を使用して実施します。 マイクロサービス仕様 、モダナイズされたソースコード、Infrastructure as Code（IaC）、およびモダナイズされたデータベースを生成するフォワードエンジニアリングを行います。 生成された マイクロサービスを IaC を使用して Amazon Web Services（AWS） にデプロイし、モダナイズされたアプリケーションの機能をテストします。 マイクロサービスアーキテクチャはメインフレームのモダナイゼーションに大きな利点をもたらしますが、すべてのケースに最適な解決策であるとは限らないことを理解することが重要です。アーキテクチャパターンの選択は、システムの具体的な要件や制約によって決定されるべきです。重要なのは、現在のニーズと将来の目標の両方に合致するアーキテクチャを選択することであり、組織がクラウドネイティブ能力を成熟させるにつれて、アーキテクチャの判断が進化する可能性があることを認識することです。 柔軟なアプローチにより、自社主導の開発とパートナー主導の開発の両方をサポートします。これにより、ビジネスプロセスの整合性を維持しながら、お好みのツールをご利用いただけます。長年にわたるビジネスロジックを保持しつつ、プロジェクトリスクを低減しながら、最新のクラウドアーキテクチャの利点を享受できます。 自動化テストの実践 新しい自動化テスト機能は、リリース時に IBM z/OS メインフレームのバッチアプリケーションスタックをサポートしており、組織がより幅広いモダナイゼーションのシナリオに対応しつつ、一貫したプロセスとツールを維持できるよう支援します。 新しいメインフレーム機能は以下の通りです： テストケースの計画 — メインフレームコード、ビジネスロジック、スケジューラプランからテスト計画を作成します。 テストデータ収集スクリプトの生成 — メインフレームからテスト計画へのデータ収集用の JCL スクリプトを作成します。 テスト自動化スクリプトを生成 — ターゲットの AWS 環境で実行されるモダナイズされたアプリケーションのテストを自動化する実行スクリプトを生成します。 自動化テストを開始するには、まずワークスペースを設定し、各ユーザーに特定の役割を割り当て、ワークスペースへの参加を招待します。詳細については、AWS Transform ユーザーガイドの AWS Transform スタートガイド を参照してください。 [ ワークスペースでジョブを作成 ] を選択します。サポートされているすべての変換ジョブの種類を確認できます。この例では、メインフレーム・アプリケーションをモダナイズするために メインフレーム・モダナイゼーション の仕事を選びます。 新しいジョブが作成されたら、テスト生成のためのモダナイゼーションを開始できます。このワークフローは順次進行型で、AI エージェントの質問に対して必要な入力を提供する場所です。共同作業者を追加し、コードベースやドキュメントが保存されている Amazon Simple Storage Service（Amazon S3） バケット内のリソースの場所を指定できます。 メインフレーム銀行ケースとして、クレジットカード管理システムのサンプルアプリケーションを使用します。これには、プレゼンテーション（BMS画面）、ビジネスロジック（COBOL）、データ（VSAM/DB2）が含まれ、オンライン取引処理およびバッチジョブも含まれます。 コードの分析、ビジネスロジックの抽出、コードの分解、移行ウェーブの計画の手順を終えた後、テストケースの計画、テストデータ収集スクリプトの生成、テスト自動化スクリプトの生成など、新しい自動化テスト機能を体験できます。 新しいテストワークフローは、モダナイゼーションプロジェクトのテスト計画を作成し、テストデータ収集スクリプトを生成します。計画のステップは以下の 3 つです： テスト計画の入力を設定 – テスト計画を他のジョブファイルにリンクできます。テスト計画はメインフレームアプリケーションコードの分析に基づいて生成され、抽出されたビジネスロジック、技術ドキュメント、コード分解、スケジューラプランを使用することで、さらに詳細を任意で提供できます。 テスト計画の範囲を定義 – アプリケーションの実行フローが開始するエントリーポイントとなる特定のプログラムを定義できます。例えば、バッチジョブの JCL です。テスト計画では、各機能テストケースが特定のエントリーポイントから実行を開始するように設計されています。 テスト計画の調整 – テスト計画は順次実行されるテストケースで構成されます。テストケースの詳細ページでは、テストケースの順序を変更したり、新しいケースを追加したり、複数のケースを統合したり、1 つのケースを 2 つに分割したりできます。バッチテストケースは、スケジューラプランに従った JCL のシーケンスで構成されます。 テストデータ収集スクリプトの生成は、機能的同等性テストのためにメインフレームアプリケーションからテストデータを収集します。このステップでは、サンプルアプリケーションのさまざまなデータソース（VSAM ファイルや DB2 データベースなど）からテストデータを収集し、モダナイズされたアプリケーションのテストに使用できる JCL スクリプトを自動生成します。このステップでは、VSAM データセットからテストデータを抽出したり、DB2 テーブルからサンプルデータを照会したり、連続データセットを収集したり、データ収集ワークフローを生成する自動スクリプトを作成します。このステップを完了すると、すぐに使用できる包括的なテストデータ収集スクリプトが準備されます。 自動テストの詳細については、AWS Transform ユーザーガイドの「メインフレームアプリケーションのモダナイゼーション 」を参照してください。 今すぐご利用いただけます AWS Transform for mainframe の新機能は、2025 年 12 月 1 日より、AWS Transform for mainframe が提供されているすべての AWS リージョンで利用可能です。リージョンごとの提供状況や今後のロードマップについては、 AWS Capabilities by Region をご覧ください。 現在、評価および変換を含むコア機能を、AWS のお客様に対して無償で提供しています。詳細については、 AWS Transform の料金ページをご覧ください 。 AWS Transform コンソールでお試しください 。詳細については、 AWS Transform for mainframe 製品ページ をご覧ください。フィードバックは、 AWS re:Post for AWS Transform for mainframe または、普段ご利用の AWS サポート窓口までお送りください。 – Channy 原文は こちら です。

本投稿は、 Sagar Desarda と Yutaka Oka、Tomoya Kudo による記事 「 Trust goes both ways: Amazon CloudFront now supports viewer mTLS 」を翻訳したものです。 本日より、 Amazon CloudFront はエンドユーザーから CloudFront への相互 TLS 認証 (mTLS) をサポートし、高度に分散された機密性の高いアプリケーションのセキュリティを強化します。現代のアーキテクチャでは、クライアント・サーバー間の通信を保護するには標準的な TLS 以上のものが必要であり、mTLS は相互の認証を強制することでこのモデルを拡張します。これにより、データが交換される前にクライアントとサーバーの両方が互いの身元を検証することが保証されます。さらに、この新機能はプロトコルレベルできめ細かなアクセス制御と ID 検証を強制し、規制環境における監査とコンプライアンスを合理化します。 CloudFront を活用したアプリケーションにおける mTLS のメリット mTLS は、サーバーとクライアント両者がデジタル証明書を提示して検証することを要求することで、セキュリティのレイヤーを追加し、相互の認証を実現します。その結果、mTLS は現在、ID 保証、暗号化通信、規制コンプライアンスがビジネスの信頼の基盤となる業界全体で広く採用されています。暗号化による ID 証明を提供し、認証情報ベースの攻撃を防ぎ、分散システム全体でゼロトラストの原則を強制します。主な業界のユースケースには以下が含まれます： 金融サービス： 銀行、決済ゲートウェイ、信頼できる第三者機関 (TTP) との API トランザクションを保護するために、PCI DSS や PSD2 などのフレームワークによって一定のセキュリティ要件が義務付けられています。金融取引プラットフォームは、市場データや取引執行エンドポイントへのアクセスを許可する前に、mTLS を使用してブローカーやパートナー機関を認証することで、セキュリティを強化できます。 IoT および接続デバイス： コネクテッドカー、センサーなどのデバイスがクラウドにテレメトリデータを送信する前に認証し、なりすましデバイスやデータ注入から保護します。 エンタープライズアプリケーション： 社内のマイクロサービス間、または企業システムと HR、給与、分析などの SaaS プラットフォーム間で認証と暗号化を強制し、ラテラルムーブメントや不正なデータアクセスのリスクを軽減します。 ヘルスケア： EHR システム、医療機器、および機密の患者データを交換する API を認証することにより、HIPAA に準拠して保護対象医療情報（PHI）を保護します。 通信およびメディア： エッジノードとオリジンサーバー間の制御およびコンテンツ配信チャネルを保護し、信頼できるインフラストラクチャコンポーネントのみがライブまたはオンデマンドのメディアトラフィックを交換できるようにします。 これらの多様で厳格なセキュリティニーズを満たすため、CloudFront は mTLS をサポートしました。組織はこれを使用して、リクエストがオリジンに到達する前に、エッジで直接アプリケーションやデバイス、サービスなどのクライアントを認証できます。この機能は、mTLS 保護をサービス間トラフィックからユーザー向けシナリオに拡張し、企業が最小限のレイテンシでグローバルにクライアント証明書検証を強制できるようにします。CloudFront mTLS は CloudFront Trust Store とシームレスに統合されるため、お客様は AWS Private Certificate Authority を使用するか、独自の CA を利用し、きめ細かな認証ポリシーを実装して証明書のプロビジョニングを自動化し、運用の複雑さを追加することなくコンプライアンスを達成できます。 はじめに CloudFront ディストリビューションの mTLS 認証を実装するには、まずプライベート認証局を設定し、クライアント証明書を作成します。設定には、ルート認証局と中間認証局の公開鍵証明書を PEM ファイル形式で準備する必要があります。そして、この証明書ファイルを Amazon S3 バケットにアップロードする必要があります。これは認証プロセスで使用されるトラストストアのソースとして機能します。 この例では、OpenSSL を使用してプライベート認証局及びクライアント証明書を作成する方法を示します。または、フルマネージドサービスである AWS Certificate Manager Private CA を使用してこのプロセスを効率化することもできます。詳細については、AWS Private CA の ドキュメント を確認してください。 1.プライベート CA の秘密鍵と証明書を生成します。 # CA 秘密鍵を生成 openssl genrsa -out Root_CA.key 4096 # CA 証明書を作成 openssl req -new -x509 -days 3650 -key Root_CA.key -out Root_CA.pem 1-a. 証明書作成プロセス中に、証明書の識別名（DN）フィールドの情報を提供するよう求められます。 1-b. オプションとして、ルートCAによって署名された中間認証局を作成できます。CloudFront は、mTLS 認証用のルート証明書を含む、最大 4 階層の証明書チェーンをサポートします。ルート CA と中間 CA 証明書を単一の PEM バンドル（CA バンドル）に結合する必要があります。cat コマンドを使用して CA バンドルファイルを作成します。 # CA バンドルを作成 cat Root_CA.pem Intermediate_CA.pem > Trust_store_bundle.pem 2. CA 階層を確立した後、クライアント証明書の秘密鍵と証明書署名要求（CSR）を生成します。 # クライアント証明書の秘密鍵を生成 openssl genrsa -out my_client.key 2048 # CSR を作成 openssl req -new -key my_client.key -out my_client.csr 2-a. クライアント証明書のサブジェクト名、地域、組織、組織単位のプロパティを入力します。オプションのパスワードチャレンジは空のままにしてください。 3. 以前に作成したルート CA を使用してクライアント証明書に署名します。 # ルート CA でクライアント CSR に署名 openssl x509 -req \ -in my_client.csr \ -CA Root_CA.pem \ -CAkey Root_CA.key \ -set_serial 01 \ -out my_client.pem \ -days 3650 \ -sha256 4. これらの手順を完了すると、ディレクトリに次のファイルが存在するはずです。 ファイル 説明 Root_CA.key ルート CA プライベートキー Root_CA.pem または Trust_store_bundle.pem CA バンドル my_client.csr クライアント証明書の署名リクエスト my_client.key クライアント証明書のプライベートキー my_client.pem クライアント証明書 トラストストアの設定 このセクションでは、トラストストアの設定方法について説明します。 前提条件 認証局からのルート CA 証明書または CA バンドル（PEM ファイル）を S3 バケットにアップロードしておく必要があります。（前のセクションを完了した場合は、S3 バケットにアップロードする必要がある Root_CA.pem ファイルをすでに作成しているはずです。） 1. CloudFront コンソールで、左側のメニューの Security の下にある Trust Store を選択します。Create trust store を選択します。 図1: CloudFront トラストストア 2. このページで S3 バケットの場所を指定します。Create trust store を押下します。CA バンドルは読み取られ、CloudFront トラストストアに保存されます 図2: トラストストアの作成 3. トラストストアが作成されると、コンソールはトラストストアの詳細ページに移動します。このページから、 Associate to distribution ボタンを押下して、トラストストアをディストリビューションに関連付けることができます。 図3: トラストストア作成成功 4. このページで、トラストストアを関連付けるディストリビューションを選択できます。 図4: トラストストアを Amazon CloudFront ディストリビューションに関連付け または、次のセクション（図 5 ） のディストリビューション設定からトラストストアを関連付けることもできます。 ディストリビューションの設定 前提条件 対象の CloudFront ディストリビューションのビューワープロトコルが HTTPS only になっている必要があります。 1. ビューワー mTLS 認証を有効にするには、ディストリビューション設定に移動し、Viewer mutual authentication (mTLS) 設定を On に切り替えます。 図5: CloudFront ディストリビューションで mTLS を有効にする 2. ユースケースに適した mTLS パラメータを選択します。 Mode CloudFrontの mTLS は、すべてのクライアントが有効な証明書を要求する Required モードと、同じディストリビューションで mTLS クライアントと非 mTLS クライアントの両方を受け入れて、無効な証明書は拒否する形の混合した認証を同時に可能にする Optional モードを選択可能です。 Trust store ビューワー mTLS 認証を有効にした後、以前に作成したトラストストアを選択して、ディストリビューションに関連付けます。 以下、2つのオプションパラメータがあり、両方ともデフォルトでは False です： Ignore certificate expiration date ： これが true の場合、クライアント証明書チェーン内の 1 つ以上の証明書が X509 の期限の検証をパスしない場合（現在時刻が NotBefore より前または NotAfter より後）でも、CloudFront はビューワーからの接続を受け入れます。X509 証明書の他の要素の検証は引き続き適用されます。クライアント証明書は、CA バンドル内の信頼できる証明書チェーンで署名されている必要があります。 Advertise trust store CA names ： これが true の場合、CloudFront はディストリビューションが受け入れる認証局名のリストをビューワーにアドバタイズします。これは、トラストストアにある証明書識別名（DN）のリストです。 Connection function（オプション） ： Connection function は、ビューワー mTLS のオプションの拡張機能です。mTLS ハンドシェイクプロセスの一部としてカスタム検証を実行できるため、クラアイアンと証明書情報をもとに、接続を許可、拒否、またはログに記録できます。後のセクションで、CloudFrontディストリビューション内で Connection function を使用する方法の例を示します。 CloudFront ビューワー証明書ヘッダー CloudFront は、クライアント証明書から情報を抽出し、HTTP ヘッダーとしてビューワーリクエストに追加できます。これらのヘッダーをキャッシュキーの一部として使用したり、オリジンサーバーに転送することができます。また、CloudFront Functionsまたは Lambda@Edge でビューワーリクエストを処理する際に、これらのヘッダーを読み取ることもできます。 利用可能な CloudFront ビューワー証明書ヘッダーは次のとおりです： CloudFront-Viewer-Cert-Serial-Number （証明書のシリアル番号） CloudFront-Viewer-Cert-Issuer （証明書発行者の識別名） CloudFront-Viewer-Cert-Subject （サブジェクト識別名） CloudFront-Viewer-Cert-Validity （証明書の有効期限 – 開始と終了の ISO8601 形式の日付） CloudFront-Viewer-Cert-PEM （URL エンコードされた PEM 形式のリーフ証明書） CloudFront-Viewer-Cert-Present（証明書が存在する場合 1、存在しない場合 0、 Require mode では常に１） CloudFront-Viewer-Cert-SHA256（クライアント証明書の SHA256 ハッシュ） 詳細については、 Viewer mTLS headers for cache policies and forwarded to origin を参照してください。 mTLS 認証のテスト mTLS 設定をテストするには、curl でクライアント証明書を使用します。 curl --key my_client.key \ --cert my_client.pem \ https://dxxxxxxxxxxxxx.cloudfront.net –key：クライアントの秘密鍵ファイルを指定します。 –cert：クライアントの証明書ファイルを指定します。 dxxxxxxxxxxxxx.cloudfront.netを、mTLS が有効になっている実際の CloudFront ディストリビューションドメイン名に置き換えます。 以下は、成功シナリオと拒否シナリオの例です: 1. 認証成功の例（有効なクライアント証明書を使用）： HTTP/2 200 content-type: text/html; charset=UTF-8 content-length:xxx date: xxx ... 2. 認証拒否の例（無効または欠落している証明書を使用）： * Request completely sent off * Closing connection * Recv failure: Connection reset by peer * Send failure: Broken pipe curl: (16) Recv failure: Connection reset by peer 次の図は CloudFront での mTLS 認証の全体的なプロセスを示しています。 図6 : CloudFront の mTLS 認証のプロセス CA バンドルを S3 バケットにアップロードします。 トラストストアを作成し、CA 証明書バンドルへの Amazon S3 パスを提供します。 クライアントが CloudFrontとの TLS セッションを開始します。TLS ハンドシェイク中に、クライアントは TLS 証明書を提示します。 CloudFrontはクライアント証明書を検証し、mTLS セッションが確立されます。 4-a. オプションで、TLS ハンドシェイクをトリガーに Connection function を実行できます。クライアント証明書から情報を抽出し、カスタムロジックに基づいて無効な証明書を持つクライアントからの接続を拒否できます。 オプションで、ビューワーリクエストエッジ関数をトリガーして、CloudFront functions を実行できます。 cloudfront-viewer-cert ヘッダーを通じてクライアント証明書から情報を抽出できます。 オリジンリクエストポリシーで cloudfront-viewer-cert ヘッダーを有効にすると、CloudFront はクライアント証明書の情報をオリジンサーバーに転送します。ヘッダーは、設定されたオリジンリクエストポリシーに従って送信されます。 CloudFront は、証明書ベースの検証を実装するために、Connection Function（ TLS ハンドシェイク中に実行）とビューワーリクエストエッジ関数（ハンドシェイク完了後に実行）を使って、カスタム認証とセキュリティ制御を可能にします。詳細については、CloudFront Viewer mTLS の ドキュメント を参照してください。 Connection Logs による監視 CloudFrontは、TLS ハンドシェイクに関する詳細な情報をキャプチャする Connection Logs を生成します。 Connection Logs の使用例： mTLS 対応ディストリビューションの監視とトラブルシューティング 成功した mTLS ハンドシェイクとクライアント証明書の追跡 失敗した mTLS ハンドシェイクの可視化 さらに、Connection Functions を使用すると、Connection Logs にカスタムログデータを追加できます。カスタムデータを追加するには、Connection Functions の接続オブジェクトで使用可能な logCustomData ヘルパーメソッドを使用します。 connectionLogCustomData フィールドに最大 800 バイトの有効な UTF-8 文字列をログに記録できます。 既存のアクセスログと同様に、CloudFront は CloudWatch vended logs を通じてConnection Logs を配信し、次の機能を提供します： Connection Logs をCloudWatch Logs、Amazon Data Firehose、Amazon S3に送信 JSON、w3c、Parquet（Amazon S3のみ）などの他の出力ログファイル形式を選択可能 各 mTLS 接続は、CloudFront ログタイプ（Connection ログ、Standard ログ、Realtime ログ）全体で記録される一意の識別子 connectionId を生成します。この統一された識別子を使用して、Connection logs とアクセスログ全体でアクセスパターンを調査および関連付けることができます。例えば、 connectionId を使用して特定のリクエストをトレースすることで、トラブルシューティングと分析がより効率的になります。詳細については、 Observability using connection logs を参照してください。 Connection Functions と CloudFront KeyValueStore を使用した証明書失効検証 mTLS 認証では、証明書が有効期間内であっても、盗難や侵害により証明書が失効する可能性があります。CloudFront Connection Functions とCloudFront KeyValueStore を組み合わせることで、リアルタイムの証明書失効チェックを実装できます。 CloudFront KeyValueStore の準備 まず、失効した証明書のシリアル番号を保存する KeyValueStore を作成します。 1. CloudFrontコンソールで、左側のメニューの Functions を選択します。次に、上部の KeyValueStores タブを開き、Create KeyValueStore を選択します。 図7: KeyValueStore の作成 2. KeyValueStore の名前を入力し、 Create を押下します。必要に応じて Amazon S3 からデータをインポートすることもできます。 3. 作成した KeyValueStore を選択し、キー値ペアの下の編集を選択して、失効した証明書のシリアル番号を入力します。 図8: シリアル番号の入力 4. Save changes を押下してエントリを保存します。 Connection Function の作成 クライアント証明書のシリアル番号をチェックする Connection function を作成します。 1. CloudFront コンソールで、左側のメニューの F unctions を選択します。次に、上部の Connection Functions タブを選択し、 Create connection function を選択します。 2. 関数の名前を入力し、 Create を押下します。 図9: Connection function の作成 3. Associated KeyValueStore の下で、 Associate existing KeyValueStore を選択し、先ほど作成した KeyValueStore を関連付けます。 図10: KeyValueStore の関連づけ 4. 次のコードを Function Code に貼り付け、 Save Change ボタンを押下します。 import cf from 'cloudfront'; async function connectionHandler(connection) { const kvsHandle = cf.kvs(); // 証明書のシリアル番号を取得 const serialNumber = connection.clientCertificate.certificates.leaf.serialNumber.replace(/:/g, ""); // KVS で失効ステータスをチェック const isRevoked = await kvsHandle.exists(serialNumber); if (isRevoked) { // 失効した証明書の接続を拒否 connection.logCustomData(`Revoked certificate: ${serialNumber}`); console.log(`Denying connection for revoked certificate: ${serialNumber}`); return connection.deny(); } // 有効な証明書の接続を許可 connection.logCustomData(`Valid certificate: ${serialNumber}`); console.log(`Allowing connection for valid certificate: ${serialNumber}`); return connection.allow(); } 5. Test タブで、作成した関数をテストできます。証明書情報と KeyValueStore に追加したシリアル番号を入力します。次に、 Test function を選択して、証明書が適切に失効することを確認します。 図11: 関数のテスト 6. Publish タブで、 Publish connection function を押下します。 7. Associated distributions の下で、 Add association を選択し、関数を関連付けるディストリビューションを選択して、 Associate を押下します。 テストと検証 失効した証明書でテストして、接続が拒否されることを確認します： # 失効した証明書でテスト（接続は拒否されるはずです） # 注：実際のCloudFrontディストリビューションドメインに置き換えてください curl --key revoked_client.key \ --cert revoked_client.pem \ https://dxxxxxxxxxxxxx.cloudfront.net # 有効な証明書でテスト（接続は許可されるはずです） curl --key valid_client.key \ --cert valid_client.pem \ https://dxxxxxxxxxxxxx.cloudfront.net まとめ インターネット上のセキュリティは常に信頼にかかっています。mTLS を使用することで、すべての接続の前に相互に検証されます。Amazon CloudFront を通じてビューワー mTLS を使用して、グローバル規模でデプロイおよび運用できるようになりました。速度を落とすことなく、アプリケーションと通信できるユーザーまたはデバイスを正確に決定できます。 AWSドキュメント をチェックして、エッジに mTLS 認証を導入する方法を確認し、ぜひ CloudFront ディストリビューションで mTLS をご利用ください。 著者について Sagar Desarda Sagar Desardaは、データ、分析、Gen AI ISV 向けのテクニカルアカウントマネージャー（TAM）およびビジネス開発（BD）組織の責任者です。Sagarのチームは、お客様と協力して AWS アーキテクチャを最適化し、ビジネスクリティカルなアプリケーションのシームレスな運用を確保し、採用を加速し、北米全体で市場投入の成功を推進します。さらに、Sagar は Edge Networking Services Specialist US チームのリーダーとして、新規ビジネスの成長を推進し、技術的なエンゲージメントを促進し、顧客向けの出版物を執筆しています。 Tomoya Kudo Tomoya Kudo は、東京を拠点とするプロトタイピングエンジニアです。彼の主な焦点は、ベストプラクティスに基づいたソリューションを提案し、プロジェクトの成功を確実にするためのプロトタイプを開発することで、お客様の成功を支援することです。 Yutaka Oka Yutaka Oka は、東京を拠点とするシニアエッジスペシャリストソリューションアーキテクトです。彼の主な焦点は、AWS Edge Services を使用してコンテンツ配信を最適化および保護することでお客様を支援することです。

技術的負債は、今日のエンタープライズ開発チームが直面する最も根強い課題の一つです。調査によると、企業は本来であれば新たな機能拡張に充てられるはずの IT 予算の 20％を、技術的負債への対応に費やしています。レガシーフレームワークのアップグレード、新しいランタイムバージョンへの移行、古いコードパターンのリファクタリングなど、こうした不可欠ながら反復的な作業は、本来であればイノベーションに充てられる貴重な開発者の時間を消費してしまいます。 2025 年 12 月 1 日、組織が大規模なモダナイゼーションに取り組む方法を根本的に変える新しいエージェント AWS Transform Custom を発表できたことをうれしく思います。このインテリジェントエージェントは、Java、Node.js、Python のアップグレード向けにあらかじめ用意された変換機能と、独自の変換を定義できる柔軟性を組み合わせています。特定の変換パターンを学習し、それをコードベース全体にわたって自動化することで、AWS Transform Custom を利用するお客様は、実行時間を最大 80% 削減したケースもあり、開発者はよりイノベーションに集中できるようになります。 ドキュメント、自然言語での説明、コードサンプルを利用して、独自の変換を定義できます。その後、サービスはこれらの特定パターンを数百から数千のリポジトリにわたり一貫して適用し、明示的なフィードバックだけでなく、変換プロジェクト内で開発者が行う手動修正といった暗黙的なシグナルも取り込みながら、その精度を高めていきます。 AWS Transform Custom は、さまざまなモダナイゼーションのニーズに対応できるよう、CLI と Web の両方のインターフェースを提供しています。CLI を利用すると、自然言語での対話を通じて変換を定義し、ローカルのコードベースに対してインタラクティブまたは自律的に実行できます。また、コードモダナイゼーションのパイプラインやワークフローに統合することもでき、機械駆動の自動化に最適です。一方、Web インターフェースは包括的なキャンペーン管理機能を提供し、チームが複数のリポジトリにわたる変換の進捗を大規模に追跡・調整できるよう支援します。 言語およびフレームワークのモダナイゼーション AWS Transform は、追加情報を提供する必要なくランタイムのアップグレードをサポートします。単に必要な構文の変更だけでなく、新しいバージョンに伴う微妙な動作の違いや最適化の機会も理解しています。同じインテリジェントなアプローチは、Node.js、Python、Java のランタイムアップグレードにも適用され、さらに x86 プロセッサから AWS Graviton へのワークロード移行など、インフラレベルの移行にも拡張されます。 また、フレームワークのモダナイゼーションも高度にサポートします。組織が Spring Boot アプリケーションを最新の機能やセキュリティパッチに対応させる必要がある場合、AWS Transform Custom は単にバージョン番号を更新するだけでなく、依存関係の変更、設定の更新、API の変更が連鎖的に及ぼす影響まで理解します。 Angular から React への移行のような大規模な変化に直面しているチームに対しても、AWS Transform Custom は、コンポーネントの変換パターン、状態管理の変換、ルーティングロジックの変換など、移行を成功させるためのパターンを学習できます。 インフラおよびエンタープライズ規模の変革 クラウド環境ではサービスが常に進化しているため、API や SDK の変化に対応する課題は特に深刻になります。AWS Transform Custom は、Java、Python、JavaScript など、企業で使用される幅広いプログラミング言語における AWS SDK の更新をサポートします。このサービスは、API 変更の機械的な側面だけでなく、新しい SDK バージョンで利用可能なベストプラクティスや最適化の機会も把握しています。 コードとしてのインフラストラクチャ の変換は、特に組織がさまざまなツール戦略を評価する際に、もう一つの重要な機能です。標準化を目的として AWS Cloud Development Kit (AWS CDK) のテンプレートを Terraform に変換する場合や、新しいサービス機能に対応するために AWS CloudFormation の設定を更新する場合でも、AWS Transform Custom はこれらのツールの宣言的な性質を理解し、インフラ定義の意図と構造を維持できます。 これらの一般的なシナリオに加え、AWS Transform カスタムは、長年の開発で蓄積された組織固有のコードパターンにも優れた対応力を発揮します。すべての企業には、それぞれ独自のアーキテクチャ規約、ユーティリティライブラリ、コーディング標準があり、これらは時間とともに進化させる必要があります。これらのカスタムパターンを学習し、体系的にリファクタリングを支援することで、組織の知見とベストプラクティスがアプリケーションポートフォリオ全体に一貫して適用されるようにします。 AWS Transform カスタムは、エンタープライズ開発のワークフローを考慮して設計されており、センターオブエクセレンスチームやシステムインテグレーターが組織全体の変換を定義・実行できる一方で、アプリケーション開発者は変換されたコードのレビューや統合に専念できます。その後、DevOps エンジニアは、既存の継続的インテグレーション・継続的デリバリー（CI/CD）パイプラインやソース管理システムとの統合を設定できます。また、 AWS Lambda 関数に特に有用な Java、Node.js、Python のランタイム更新向けの事前構築済み変換や、チームがすぐに活用できるよう AWS SDK のモダナイゼーション向け変換も含まれています。 開始方法 AWS Transform は、事前構築済みおよびカスタムの変換機能を通じて、複雑なコード変換を管理可能にします。まずは、既存の変換を利用してよくあるモダナイゼーションの課題に対応する方法を見てみましょう。今回は、ランタイムのサポート終了（EOL）に伴う AWS Lambda 関数のアップグレードです。 この例では、Python 3.8 がサポート終了（EOL）となりセキュリティ更新が提供されなくなったため、Python 3.8 の Lambda 関数を Python 3.13 に移行する方法を示します。このデモでは CLI を使用しますが、Web インターフェースの強力なキャンペーン管理機能もぜひ試してみてください。 まず、 atx custom def list コマンドを使用して、利用可能な変換定義を確認します。必要に応じて、コマンドを直接実行する代わりに atx と入力するだけで、会話型インターフェースからこの機能にアクセスすることもできます。 このコマンドは、AWS 管理のデフォルト変換に加え、組織内でユーザーが作成した既存のカスタム変換も含め、利用可能なすべての変換を表示します。AWS 管理の変換は AWS/ プレフィックスで識別され、AWS によって管理および更新されていることを示します。結果には、Java ランタイムのモダナイゼーション向けの AWS/java-version-upgrade、Python の AWS SDK 利用更新向けの AWS/python-boto2-to-boto3-migration、Node.js ランタイム更新向けの AWS/nodejs-version-upgrade など、いくつかのオプションが表示されます。 Python 3.8 から 3.13 への移行には、AWS/python-version-upgrade 変換を使用します。 移行は、 atx custom def exec コマンドを使用して実行します。コマンドおよびそのすべてのオプションの詳細については、 ドキュメント を参照してください。ここでは、変換名を指定して自分のプロジェクトリポジトリに対して実行します。検証のために、pytest を追加してユニットテストを実行します。さらに重要な点として、– configuration 入力の additionalPlanContext セクションを使用して、アップグレード先の Python バージョンを指定します。参考までに、デモ用のコマンドはこちらです（わかりやすいように複数行に分けてインデントしています）： atx custom def exec -p /mnt/c/Users/vasudeve/Documents/Work/Projects/ATX/lambda/todoapilambda -n AWS/python-version-upgrade -C "pytest" --configuration "additionalPlanContext=アップグレード先の Python バージョンは Python 3.13" -x-t その後、AWS Transform が移行プロセスを開始します。このツールは Lambda 関数コードを分析し、Python 3.8 固有のパターンを特定し、Python 3.13 互換性のために必要な変更を自動的に適用します。これには、非推奨機能の構文の更新、インポート文の修正、バージョン特有の動作の調整が含まれます。 実行後、AWS Transform は包括的なサマリーを提供します。内容には、requirements.txt の依存関係が Python 3.13 対応のパッケージバージョンに更新された報告、非推奨構文が現在の等価表現に置き換えられた事例、AWS Lambda デプロイ用のランタイム設定の更新メモ、移行を検証するための推奨テストケースなどが含まれます。また、移行の成功を証明する証拠も提供されます。 移行後のコードはローカルブランチに存在するため、内容を確認して問題なければマージできます。あるいは、フィードバックを継続的に提供して何度も反復し、移行が完全に完了し、自分の期待に沿ったものになるまで調整することも可能です。 この自動化プロセスにより、通常であれば数時間かかる手作業が、コード品質を維持しながら新しい Python ランタイムとの互換性を保つ、効率的で一貫したアップグレードに変わります。 新しいカスタム変換の作成 AWS 管理の変換は一般的なシナリオに効果的に対応しますが、組織固有のニーズに合わせたカスタム変換を作成することも可能です。AWS Transform が組織固有の要件からどのように学習するかを確認するために、カスタム変換の作成方法を見てみましょう。 atx と入力して atx cli を初期化し、プロセスを開始します。 最初に尋ねられるのは、既存の変換を使用するか、新しい変換を作成するかです。私は新しい変換を作成することを選択します。ここから先は、すべてのやり取りがコマンドではなく自然言語で行われる点に注目してください。 新しいもの と入力しましたが、 新しいものを作成したい と入力しても、まったく同じように理解されます。 その後、どのような変換を行いたいかについて、さらに情報を提供するよう求められます。このデモでは Angular アプリケーションを移行するため、 Angular 16から19へのアプリケーション 移行 と入力します。すると、CLI がこの種類の移行に利用可能なすべての変換を検索します。私の場合、チームですでにいくつかの Angular 移行が作成され利用可能になっているため、それらが表示されます。ただし、Angular 16 から 19 への移行という私の具体的な要求に完全に一致するものはないと警告されます。次に、一覧に表示されている既存の変換のいずれかを選択するか、カスタム変換を作成するかを尋ねられます。 自然言語を使い続け、 create a new one と入力して、カスタム変換を作成することを選択します。繰り返しになりますが、自分の意図を明確に示していれば、この表現はどのようなバリエーションでも構いません。続いて、変換プランをカスタマイズするのに役立つドキュメント、サンプルコード、移行ガイドなどがあるかどうかを含め、いくつかの質問がされます。 このデモでは、AWS Transform が提供する適切なデフォルトのみを利用します。これらの 詳細はわかりません と入力します。ベストプラクティスに従ってください。 と入力すると、CLI から、Angular 16 から Angular 19 への移行のための包括的なトランスフォーメーション定義を作成する旨の応答があります。もちろん、私は事前学習済みのデータを利用して、ベストプラクティスに基づく結果を生成しました。通常通り、この段階では可能な限り多くの情報や関連データを提供することが、より良い結果を得るための推奨事項です。ただし、すべてのデータを事前に揃えておく必要はありません。カスタム変換定義の作成プロセスを進める中で、いつでもデータを追加で提供できます。 変換定義はマークアップファイルとして生成され、サマリーとともに、プレマイグレーション準備、処理と分割、静的依存関係分析、特定の変換ルールの検索と適用、段階的な移行と反復的検証などのフェーズごとに論理的にグループ化された包括的な実装手順のシーケンスが含まれます。 興味深いことに、AWS Transform は問題を最小限に抑えるために、直接 16 から 19 へ移行するのではなく、アプリケーションを段階的に 17 → 18 → 19 へ移行するステップを作成するというベストプラクティスを選択しています。 プランには、各フェーズを確実に完了できることを確認するためのさまざまなテストおよび検証の段階が含まれている点に注意してください。最後には、最終検証フェーズも含まれており、移行を成功として受け入れるためにアプリケーションのすべての側面に対して実施される包括的なテストの終了基準がリスト化されています。 変換定義が作成された後、AWS Transform は次に何を行いたいかを尋ねます。変換定義を確認または修正することができ、このプロセスを何度でも繰り返して、納得のいく定義に仕上げることができます。この変換定義をすでに Angular コードベースに適用することも選択できます。ただし、まずはこの変換を自分だけでなくチームメンバーも利用できるようにして、将来再利用できるようにしたいと思います。そこで、私はこの変換をレジストリに公開するためにオプション 4 を選択します。 このカスタム変換には名前と目的の説明が必要で、ユーザーがレジストリを閲覧する際に表示されます。AWS Transform はこれらをコンテキストから自動的に抽出し、先に進む前に変更したいかどうかを尋ねてくれます。デフォルトの Angular-16から19への移行 は妥当で目的も明確に示されているため、提案を受け入れ、 はい、良さそうです と答えて公開することにしました。 変換定義が作成され公開されたので、任意のコードリポジトリに対して何度でも使用して実行できます。それでは、この変換を Angular 16 で書かれたプロジェクトのコードリポジトリに適用してみましょう。続くプロンプトでオプション 1 を選択すると、CLI は移行したいアプリケーションのファイルシステム上のパスと、必要に応じて使用するビルドコマンドの入力を求めます。 情報を提供すると、AWS Transform はコードベースを解析し、先ほど作成した定義に基づいて、詳細な段階的変換プランを作成します。処理が完了すると、このコードベースに作成した変換定義を適用するための詳細な移行プランを含む JSON ファイルが作成されます。変換定義の作成プロセスと同様に、このプランも必要に応じて確認・反復することができ、フィードバックを提供したり、特定の要件に合わせて調整したりできます。 プランを承認する準備ができたら、自然言語で AWS Transform に対して移行プロセスを開始できることを伝えられます。 よさそうだ と入力して次に進むと、シェル上でプランの実行状況を確認しながら、コードベースに段階的に変更が加えられていきます。 所要時間はアプリケーションの複雑さによって異なります。私の場合、完了するまでに数分かかりました。完了すると、変換のサマリーと、プランの最終検証フェーズに含まれていた各終了基準のステータス、さらに報告されたステータスを裏付けるすべての証拠が提供されます。たとえば、「 アプリケーションビルド — プロダクション 」の基準は合格と記載されており、提供された証拠には、段階的な Git コミット、プロダクションビルドの完了にかかった時間、バンドルサイズ、ビルド出力メッセージ、作成されたすべての出力ファイルの詳細などが含まれています。 まとめ AWS Transform は、組織がコードのモダナイゼーションや技術的負債に取り組む方法における根本的な変化を示しています。このサービスは、かつてはチームごとに分散していた作業を統合されたインテリジェントな機能に変換し、ナレッジサイロを解消するとともに、ベストプラクティスや組織の知識を組織全体でスケーラブルな資産として活用できるようにします。これにより、モダナイゼーションの取り組みを加速させるとともに、開発者は反復的な保守やモダナイゼーション作業に時間を費やすのではなく、イノベーションやビジネス価値の創出により多くの時間を割けるようになります。 知っておくべきこと AWS Transform カスタム は、現在一般提供されています。最初の変換キャンペーンを開始するには はじめにガイド を参照するか、カスタム変換定義の設定方法について詳しく知るには ドキュメント をご覧ください。 原文は こちら です。

本記事は 2025 年 11 月 20 日に公開された “ Multi-key support for Global Secondary Index in Amazon DynamoDB ” を翻訳したものです。 Amazon DynamoDB は、 グローバルセカンダリインデックス (GSI) の複合キーで最大 8 つの属性 をサポートするようになりました。これで、GSIの一部としてアイテムを識別するために最大4つのパーティションキーと4つのソートキーを指定できるようになり、複数の次元に及ぶ大規模なデータにクエリできるようになります。 Amazon DynamoDB は、サーバーレスでフルマネージドの分散型 NoSQL データベースであり、あらゆるスケールで 1 桁ミリ秒のパフォーマンスを実現します。DynamoDB の主要な機能の 1 つは、 スキーマの柔軟性 です。 プライマリキー 以外はすべてオプションです。パーティションキー (PK) と、オプションでソートキー (SK) を持つシンプルなテーブルから始めることができます。どちらも文字列属性として定義すれば、すぐにデータモデルの構築を開始できます。 アプリケーションでは、カーディナリティを高めるためにパーティションキーに複数の属性を使用する必要がある場合があります。同様に、ソートキーでもデータの書き込みやクエリ時に、データのフィルタリング方法に柔軟性を持たせるために複数の属性が必要になることがあります。例えば、ステータスと日付でトランザクションを取得したり、読み取りタイプとタイムスタンプの両方でフィルタリングしたセンサーの読み取り値を取得するアクセスパターンが必要な場合、ソートキーに 2 つの属性を使用することでアプリケーションの効率が大幅に向上します。このような場合、これまでは創意工夫が必要で、アプリケーション側で 属性を結合 して 2 つ以上の属性の複合キーを作成する必要がありました。 この記事では、複合キーの追加属性サポートを備えたグローバルセカンダリインデックスを使用して、同様のデータモデルをより効率的に設計する方法を紹介し、複雑さを軽減した DynamoDB データモデルの例を提供します。 パーティションキーとソートキーの理解 パーティションキーはクエリにおける既知の要素を表し、基本的には user_id 、 account_id 、 sensor_id 、 player_id などのデータ取得時に使用する識別子です。この情報がなければ、テーブル内のアイテムを効率的に検索することが難しくなります。ソートキーは、同じパーティションキーを共有するアイテムに関する質問に答えを提供します。例えば、「 このアカウント の日付別トランザクションを検索する 」や「 このデバイス のセンサー読み取り値とアラームを時系列で表示する 」、「 この顧客のショッピングカート にはどのアイテムが入っているか？ 」といった質問です。 新しい GSI が最大 4 つのパーティションキーと 4 つのソートキーをサポートするようになったことで、多次元クエリへのアプローチが変わります。この機能を使用することで、開発者による回避策が不要になり、DynamoDB のパフォーマンスを維持しながら、柔軟性がさらに向上します。 主要な概念 DynamoDB テーブルは 2 つの概念を中心に構築されています: パーティションキーは、データの格納場所を決定するメイン識別子 です。これはアクセスパターンにおける「既知の要素」を表します。パーティションキーは、 Query API などの効率的な API 操作では必ず指定する必要があります。 ソートキー は、関連するアイテムをまとめて格納し、範囲操作を使用して効率的にクエリするためのオプション属性です。ソートキーを使用すると、1 対多のリレーションシップが可能になり、 アイテムコレクション （同じパーティションキーを持つアイテム）が生成されます。 ソートキーには、 エンティティタイプ 、 ステータス 、ISO8601 形式の タイムスタンプ など、異なるエンティティタイプを組み合わせることができます。これらを # 文字で連結し、ソートキー条件を活用して特定のクエリを取得できます。顧客 C#1A2B3C から情報を取得する例を見てみましょう。 すべての注文を取得するには、ソートキー条件として BEGINS_WITH ORDER# を使用します。 PENDING の注文のみを取得したい場合は、探しているステータスを含めたソートキー条件として BEGINS_WITH ORDER#PENDING を使用することもできます。 最後に、2 つの日付の間にある保留中の注文をすべて取得したい場合は、ソートキー条件として BETWEEN ORDER#PENDING#2025-11-01 AND ORDER#PENDING#2025-11-04 を使用します。より詳細な情報を提供するたびに、より小さなデータのサブセットを取得できることに注目してください。 データモデルを設計する際、パーティションキーは「何を探しているのか？」または「主要なものは何か？」という問いに答えます。言い換えれば、データを特定するために 必ず知っておくべき 情報です。ソートキーは「探しているものの、どの側面が欲しいのか？」または「絞り込むのに役立つ詳細は何か？」という問いに答えます。言い換えれば、 データをどのように整理しフィルタリングするか？ ということです。 例: 顧客 1A2B3C のショッピングカートでは、どのアイテムがアクティブですか？ 必須情報 は 顧客 1A2B3C です。これが探している主要な情報です。どの顧客に属しているかがわからなければ、ショッピングカートのアイテムを見つけることはできません。 ここでは ショッピングカート内のアクティブなアイテム で フィルタリングしてみましょう 。ショッピングカート内のアイテムを ACTIVE ステータスで整理し、さらに一意性のために SKU を追加します。 次の表は、顧客 1A2B3C の 3 つのショッピングカートアイテムを含むサンプルデータモデルを示しています。 パーティションキー ソートキー status sku date C#1A2B3C CART#S#ACTIVE#SKU#123ABC ACTIVE 123ABC 2025-11-04T10:00:00 C#1A2B3C CART#S#ACTIVE#SKU#234BCD ACTIVE 234BCD 2025-11-04T10:05:00 C#1A2B3C CART#S#SAVED#SKU#345CDE SAVED 345CDE 2025-11-04T10:08:00 ソートキーの複数の属性にまたがるクエリが必要な場合、一般的なパターンは結合し複合ソートキーにすることでした。例えば: PK: C#1A2B3C SK: ORDER#PENDING#2024-11-01T10:30:00Z グローバルセカンダリインデックスにおける拡張複合キーの紹介 グローバルセカンダリインデックスは複数属性キーをサポートしており、複数の属性からパーティションキーとソートキーを構成できます。各属性は独自のデータ型 (文字列、数値、バイナリ) を維持し、柔軟なクエリ機能を提供します。GSI は スパース であり、複合キーのいずれかのコンポーネントが欠落している場合、単一キーの GSI と同様にアイテムはインデックス化されません。 複数のパーティションキー : 最大 4 つの属性をパーティションキーとして組み合わせることができます（例: テナント、顧客、部門）。 複数のソートキー : 特定のクエリパターンに対応する最大 4 つのソートキー属性を定義できます。 ネイティブデータ型: 各属性は元の型を保持し、文字列への変換や連結は不要です。 効率的なクエリ : データを再構築することなく、より具体的な属性の組み合わせでクエリを実行できます。 シンプルな シャーディング 手法 : 2 つ以上のパーティションキーを使用して、 ホットパーティション のリスクを軽減します。インテリジェントなシャーディング手法を実装し、データモデル内の情報を活用してトラフィックを分散させることで解決できます。 以下のクエリパターンがサポートされています: クエリには、すべてのパーティションキー属性に対する等価条件 ( = ) が必要です。 ソートキー条件はオプションであり、等価条件 ( = ) を使用して最大 4 つの属性を指定できます。 範囲条件 ( < 、 > 、 <= 、 >= 、 BETWEEN 、 BEGINS_WITH ) は、最後のソートキー属性でのみサポートされています。 クエリでソートキーをスキップすることはできません。例えば、すべてのパーティションキーと 1 番目と 3 番目のソートキーのみを指定するクエリはサポートされていません。 ソートキーは左から右へ部分的に指定できます。例えば、最初のソートキーのみ、または最初と 2 番目のソートキーのみを指定するクエリはサポートされています。 アプリケーションの複雑さを軽減しながら、DynamoDB と同等のパフォーマンスを維持できます。 複合キーの仕組み GSI の拡張複合キーの動作を確認するために、完全な例を見ていきましょう。 シナリオ 1: 注文ダッシュボード 注文を追跡するシステムを構築しています。このシステムには以下の要件があります： システムは注文 ID で注文を追跡し、ステータスとメタデータを更新します。 ユーザーは、ステータス (ACTIVE、PENDING、COMPLETED) と金額のしきい値を組み合わせて注文を検索できます。例えば、11 月 4 日の $100 を超える ACTIVE な注文などです。 ベーステーブルの設計 シナリオ 1 の 2 つのアクセスパターンのうち、ユーザーに関連しないものは 1 つだけです。注文追跡システムをベーステーブルとして使用します。注文が最も基本的な情報単位であるため、システムをスケールさせることができます。 必須情報 は order_id です。 order_id がなければ、テーブル全体を スキャン する必要があります。他のアクセスパターンで注文を日付順に整理するために、生成時刻でソート可能な K-sortable unique identifier (KSUID) を使用します。 この例では注文 ID に対するクエリが含まれていないため、ソートキーは必要ありません。次の表は、顧客 1A2B3C の 3 つの注文を含むサンプルデータモデルを示しています。 パーティションキー order_id customer_id order_date amount status acc_type org_id KSUID1 C#1A2B3C 2025-11-04 200 ACTIVE A OMEGA KSUID2 C#1A2B3C 2025-11-04 145 PENDING A OMEGA KSUID3 C#1A2B3C 2025-11-04 110 PENDING B BRAVO Base Table: Orders Partition Key: order_id Attributes: customer_id, status, order_date, amount, acc_type and org_id 複合キー GSI 設計 ダッシュボードクエリ用に、 customer_id をパーティションキーとし、 status 、 order_date 、 amount で構成されるソートキーを持つ GSI を作成します。不等式はソートキー属性の最後に配置する必要があるため、 amount を最後に配置することで、範囲クエリを使用して価格のしきい値でフィルタリングできます。 必須情報 は 顧客 1A2B3C です。どの顧客に属するかを知らなければ、注文を見つけることはできません。 データをどのように整理してフィルタリングすればよいでしょうか？ 特定の日付のアクティブな注文で、$100 を超えるもの で整理およびフィルタリングする必要があります。ステータスと日付を使用した複合キーを使用することで、この顧客の注文を取得できます。 以下の表は、顧客 1A2B3C の 3 つの注文を含むサンプルデータモデルを示しています： GSI PK GSI SK customer_id status order_date amount order_id acc_type org_id C#1A2B3C ACTIVE 2025-11-04 200 KSUID1 A OMEGA C#1A2B3C PENDING 2025-11-04 145 KSUID2 A OMEGA C#1A2B3C PENDING 2025-11-04 110 KSUID3 B BRAVO GSI: OrdersByStatusDateAmount Partition Key: customer_id Sort Key 1: status (equality condition) Sort Key 2: order_date (equality condition) Sort Key 3: amount (range condition) 以下の AWS CLI コマンドでは、顧客 1A2B3C の注文を取得します。 aws dynamodb query \ --table-name orders-table \ --index-name OrdersByStatusDateAmount \ --key-condition-expression "customer_id = :cust" \ --expression-attribute-values '{ ":cust": {"S": "1A2B3C"} }' { "Items": [ { "org_id": {"S": "OMEGA"}, "order_date": {"S": "2025-11-04"}, "status": {"S": "ACTIVE"}, "acc_type": {"S": "A"}, "customer_id": {"S": "1A2B3C"}, "amount": {"N": "200"}, "order_id": {"S": "KSUID1"} }, { "org_id": {"S": "BRAVO"}, "order_date": {"S": "2025-11-04"}, "status": {"S": "PENDING"}, "acc_type": {"S": "B"}, "customer_id": {"S": "1A2B3C"}, "amount": {"N": "110"}, "order_id": {"S": "KSUID3"} }, { "org_id": {"S": "OMEGA"}, "order_date": {"S": "2025-11-04"}, "status": {"S": "PENDING"}, "acc_type": {"S": "A"}, "customer_id": {"S": "1A2B3C"}, "amount": {"N": "145"}, "order_id": {"S": "KSUID2"} } ], "Count": 3, "ScannedCount": 3, "ConsumedCapacity": null } 以下の AWS CLI コマンドは、顧客 1A2B3C の PENDING ステータスの注文をクエリします: aws dynamodb query \ --table-name orders-table \ --index-name OrdersByStatusDateAmount \ --key-condition-expression "customer_id = :cust AND #status = :status" \ --expression-attribute-names '{"#status": "status"}' \ --expression-attribute-values '{ ":cust": {"S": "1A2B3C"}, ":status": {"S": "PENDING"} }' 以下の AWS CLI コマンドは、11 月 4 日に PENDING ステータスとなっている顧客 1A2B3C の注文を取得します： aws dynamodb query \ --table-name orders-table \ --index-name OrdersByStatusDateAmount \ --key-condition-expression "customer_id = :cust AND #status = :status AND order_date = :date" \ --expression-attribute-names '{"#status": "status"}' \ --expression-attribute-values '{ ":cust": {"S": "1A2B3C"}, ":status": {"S": "PENDING"}, ":date": {"S": "2025-11-04"} }' 以下の AWS CLI コマンドは、顧客 1A2B3C の注文のうち、11 月 4 日に PENDING ステータスで金額が 100 ドルを超えるものをクエリします。 aws dynamodb query \ --table-name orders-table \ --index-name OrdersByStatusDateAmount \ --key-condition-expression "customer_id = :cust AND #status = :status AND order_date = :date AND amount > :min_amount" \ --expression-attribute-names '{"#status": "status"}' \ --expression-attribute-values '{ ":cust": {"S": "1A2B3C"}, ":status": {"S": "PENDING"}, ":date": {"S": "2025-11-04"}, ":min_amount": {"N": "100"} }' シナリオ 2: 進化 – トラフィックの増加 このソリューションが成功し、最大規模のエンタープライズ顧客が 1 秒あたり 500 回を超えるレートで注文ステータスをプッシュするようになったと想像してください。要件は変わらず、ユーザーは一定の金額しきい値内でステータスごとに注文をクエリする必要があります。 この大規模なエンタープライズ顧客の導入により、 ホットパーティション が発生する可能性に直面しています。ベーステーブルで 1 つの注文ステータスを NEW から ACTIVE に更新すると、1 WCU を消費する単一の書き込み操作が使用されます。GSI では、NEW ステータスを削除するために 1 つ、ACTIVE に設定するためにもう 1 つ、合計 2 WCU を消費し、 仮想パーティションあたり 1000 WCU の制限 に近づきます。 幸いなことに、status 属性をシャーディングキーとして使用できます。5 つの異なるステータスがあると仮定すると、スループットを最大 5 倍に増加させることができます。パーティションキーを customer_id と status、ソートキーを order_date と amount とする新しい GSI を作成します。 GSI PK GSI SK customer_id status order_date amount order_id acc_type org_id C#1A2B3C ACTIVE 2025-11-04 200 KSUID1 A OMEGA C#1A2B3C PENDING 2025-11-04 145 KSUID2 A OMEGA C#1A2B3C PENDING 2025-11-04 110 KSUID3 B BRAVO GSI: OrdersByOrgAccountStatus Partition Key 1: customer_id Partition Key 2: status Sort Key 2: order_date (equality condition) Sort Key 3: amount (range condition) 複数属性の複合キーを使用する際のベストプラクティス まずクエリパターンを設計してください。GSI を作成する前に、最も頻繁に使用される上位 3 〜 5 つのクエリパターンを特定し、その頻度とパフォーマンス要件を把握します。ベーステーブルの構造は一意性を確保するように設計し、GSI を使用して複合キーパターンを最適化することで、最も一般的なクエリを効率的に処理できるようにします。複合キー GSI を使用すれば、データモデル全体を再構築するのではなく、異なるキーの組み合わせでインデックスを追加することで、新しい要件に対応できます。 キーの順序は慎重に選択してください。GSI の属性の順序は、実行できるクエリに直接影響します。4 つのパーティションキーと 4 つのソートキーを使用する必要はありません。3 つのパーティションキーと 2 つのソートキー、1 つのパーティションキーと 3 つのソートキー、その他の構成など、アクセスパターンに合った組み合わせを選択してください。 複合キー GSI の最も強力な側面の 1 つは、ネイティブデータ型のサポートです。タイムスタンプ、数量、数値比較には Number 型を使用して、適切なソートと数学演算を可能にします。アクティブ/非アクティブや有効/無効などのバイナリ状態には Boolean フラグを使用します。型固有の操作のメリットが失われるため、必要でない限り値を文字列に変換することは避けてください。 最初からスケールを考慮して計画してください。コストを削減するために、指定したキー属性に値を持つ項目のみをインデックス化する スパースインデックス を可能な限り設計してください。プロジェクションタイプは戦略的に選択してください。柔軟性を重視する場合は ALL を、ストレージコストを削減する場合は KEYS_ONLY を、必要な属性のみを射影する場合は INCLUDE を使用します。ベーステーブルに Time to Live (TTL) 戦略を実装して、レコードサイズを長期的に管理し、無制限な増加を防止してください。 まとめと次のステップ この記事では、複合キー GSI の使い方を学びました。この新しい DynamoDB の機能により、属性を連結するような回避策を使用することなく、異なるデータ型や属性をクエリできます。この機能は、標準の GSI ストレージ、スループット、機能以外の追加コストなしで、すべての DynamoDB テーブルで利用可能です。DynamoDB のデータモデルをシンプルにする準備はできましたか？以下の手順に従ってください： クエリパターンを特定する : 現在連結されたソートキーを使用しているクエリを確認します GSI を設計する : データ階層に基づいて、属性をパーティションキーとソートキーの位置にマッピングします。 徹底的にテストする : テストテーブルを作成し、想定される負荷の下でクエリパターンが期待どおりに動作することを検証します。 本番環境にデプロイする : 本番テーブルに新しい GSI を追加し、アプリケーションコードを更新します パフォーマンスを監視する : CloudWatch で GSI のメトリクスを追跡し、必要に応じて最適化します クリーンアップする : GSI で使用されているレガシーの複合属性を削除します。 詳細な実装ガイダンスについては、 DynamoDB でグローバルセカンダリインデックスを使用する方法 と データモデリングのベストプラクティス を参照してください。 この記事の翻訳は Solutions Architect の堤 勇人が担当しました。 著者について Esteban Serna Esteban は、AWSのプリンシパルDynamoDBスペシャリストソリューションアーキテクトで、16年の経験を持つデータベース愛好家です。コンタクトセンターインフラの展開からNoSQLに魅了されるまで、Estebanの歩みは分散コンピューティングの専門化へと導きました。仕事に情熱を持つEstebanは、自身の知識を他者と共有することほど好きなことはありません。

本記事は 2025 年 11 月 20 日に公開された “ Accelerating data modeling accuracy with the Amazon DynamoDB Data Model Validation Tool ” を翻訳したものです。 Introducing the Amazon DynamoDB data modeling MCP tool では、 Amazon DynamoDB Model Context Protocol (MCP) サーバー を発表しました。これは、DynamoDB 固有のツールを Amazon Q Developer 、 Kiro 、Cursor などの AI 搭載アシスタントに接続します。MCP サーバーを使用すると、自然言語を通じて DynamoDB データモデルを設計でき、dynamodb_requirements.md や dynamodb_data_model.md などの構造化されたアーティファクトを生成できます。 Raising the bar on Amazon DynamoDB data modeling では、データモデリングプロンプト自体の品質、要件の収集効率、アクセスパターンの推論、スケーラブルな設計の生成を測定する自動評価フレームワークを紹介しました。このフレームワークは、 Amazon Bedrock 、 DSPy 、 Strands Agents で構築されており、DynamoDB モデリングツールが提供するガイダンスを継続的に改善するのに役立ちます。 2025年11月20日、MCP サーバーの新しいコンポーネントである Amazon DynamoDB Data Model Validation Tool を発表します。この検証ツールは、生成、評価、実行の間のループを閉じるものです。検証ツールは、生成されたデータモデルを Amazon DynamoDB local に対して自動的にテストし、すべてのアクセスパターンが意図したとおりに動作するまで反復的に改善します。 静的な設計から自己検証モデルへ データモデリングは本質的に反復的なプロセスです。従来、開発者はスキーマを手動でデプロイし、テストスクリプトを記述し、結果を分析することでデータモデルを検証していましたが、このプロセスは時間がかかり、一貫性に欠けていました。Data Model Validation Tool は、このサイクルをエンドツーエンドで自動化します。 まず、DynamoDB MCP サーバーは、自然言語または自動データベース分析を通じてデータモデルの設計を支援し、アプリケーションのアクセスパターンに沿ったスキーマを生成します。新しい Data Model Validation Tool は、DynamoDB local を自動的に起動し、読み取りおよび書き込み操作を実行して、各アクセスパターンが期待通りに動作することを確認することで、このプロセスを拡張します。 これにより、エージェントが完全に有効になるまでモデルを改良できるような、生成と検証の反復ループが作成されます。たとえば、パーティションキーの不整合によってクエリが不完全な結果を返すなどのテストが失敗した場合、バリデーターは問題を記録し、スキーマの影響を受けた部分を再生成し、テストを再実行します。このプロセスは、アクセスパターンが正常に合格するまで続きます。 次の図は、選択したエージェントフレームワークを通じて MCP サーバーとどのように対話するかを示しています。 DynamoDB データモデルの設計を支援するようエージェントに依頼すると、エージェントは DynamoDB Model Context Protocol (MCP) サーバーを呼び出します。サーバーは、自然言語での会話か、データモデリング要件を自動的に推測する Database Source Analyzer ツールのいずれかを選択するよう案内します。 このツールは、アプリケーションのアクセスパターンを捉え、スケーラブルでコスト効率の高い設計に整理した DynamoDB データモデルを生成します。 次に、エージェントはデータモデルを検証するかどうかを尋ねます。「はい」を選択すると、Data Model Validation Tool が呼び出されます。 バリデーターは以下のステップを実行します。 DynamoDB local を使用してローカル DynamoDB 環境を起動します。 dynamodb_data_model.json という名前の JSON ファイルを生成します。このファイルには、設計を検証するために必要なアクション (作成するテーブル、テストするアクセスパターン、実行する対応する CLI コマンド) がリストされています。 テーブルとインデックスをローカルに作成し、サンプルデータを挿入します。 dynamodb_data_model.json ファイルに記録された期待される読み取りおよび書き込み操作を実行します。 レスポンスを検証し、各アクセスパターンが正しく効率的に動作することを確認します。 検証ステップが失敗した場合、フィードバックループが自動的にデータモデルを更新し、アクセスパターンが合格するまでテストを再実行します。完了すると、ツールは更新されたモデルと、検証プロセスを要約した validation_result.md ファイルを出力します。 例: 高トラフィックの取引アプリの検証 次の例は、 Deals App の検証結果を示しています。これは、数百万人のユーザーにサービスを提供し、フラッシュセール中に大規模なファンアウトイベントを処理するモバイルファーストシステムです。MCP データモデリングツールがスキーマを生成した後、バリデーターは自動的に DynamoDB local を起動し、次のようなシミュレーション操作を実行します。 カテゴリとブランドで取引を閲覧する 閲覧数で取引の人気を追跡する フォローしているカテゴリの通知を書き込む バリデーターが「GetUserFeed」クエリでエラーが発生したことを検出すると、問題を特定し、関連するインデックスを再生成して、アクセスパターンを再テストします。数分以内に、機能テスト済みで、パフォーマンスを考慮し、DynamoDB のベストプラクティスに沿った、検証済みのデータモデルが完成します。以下は、Amazon Q CLI を使用した検証ツールの出力例です ## Validation Results Summary Status: ⚠ 75% Success (3 out of 4 patterns working) ✔ Query: GetDealById – passed ✔ Query: GetDealByCategory – passed ✔ Query: GetDealByBrand – passed ✖ Query: GetUserFeed – failed Root Cause: missing GSI on followed_categories The Fix: I need to update the JSON file with corrected commands. Let me do that now ## Re-validation Results All 4 access patterns are now working correctly: ✔ Query: GetDealById – passed ✔ Query: GetDealByCategory – passed ✔ Query: GetDealByBrand – passed ✔ Query: GetUserFeed – passed Your DynamoDB model is ready and validated at 100% effectiveness! サンプル検証出力 検証が完了すると、 dynamodb_data_model.json ファイルが作成され、検証テストから得られた主要な発見がハイライトされます。このケースでは、 Deals App データモデルは、テストされたアクセスパターン全体で 100% の成功率を達成し、設計が準備完了であることを確認しました。 # DynamoDB Data Model Validation Report **Overall Status:** ✅ PASSED **Success Rate:** 100% (4 out of 4 patterns successful) ## Access Pattern Results ### Pattern 1: Get deal by ID **Operation:** GetItem **Status:** ✅ Success ```json { "deal_id": "deal_001", "brand": "TechPro", "category": "Electronics", "title": "50% off Bluetooth Headphones", "status": "ACTIVE" } まとめ Amazon DynamoDB Data Model Validation Tool は、生成、評価、検証のループを完結させます。このツールを使用することで、データモデルが見た目だけでなく、実際に正しく動作することを測定可能な形で確信できます。 自然言語モデリングと実行可能な検証により、開発者は DynamoDB スキーマをこれまで以上に速く設計、テスト、改良できるようになりました。これらのツールを使用して DynamoDB 設計ワークフローを加速させる方法や、MCP 環境が進化し続ける中でのフィードバックを共有していただけることを楽しみにしています。 詳細については、 DynamoDB MCP サーバーの GitHub リポジトリ を参照し、検証ツールがワークフローにどのように統合されるかをご確認ください。 この記事の翻訳は Solutions Architect の堤 勇人が担当しました。 著者について Lee Hannigan Lee Hannigan は、アイルランドのドニゴールを拠点とするシニアDynamoDBデータベースエンジニアです。彼は分散システムに関する豊富な専門知識を持ち、ビッグデータおよび分析技術における強固な基盤を有しています。彼の役割において、リーはDynamoDBのパフォーマンス、スケーラビリティ、信頼性の向上に注力しながら、顧客や社内チームがその機能を最大限に活用できるよう支援しています。

本記事は 2025年11月26日 に公開された「 How Octus achieved 85% infrastructure cost reduction with zero downtime migration to Amazon OpenSearch Service | AWS Big Data Blog 」を翻訳したものです。 データ量が指数関数的に増加し続ける中、ミッションクリティカルなワークロードが求める高いパフォーマンスと信頼性を維持しながら、検索インフラストラクチャのコストを最適化するプレッシャーが高まっています。多くの企業は、運用オーバーヘッドが大きく、効率的なスケーリングを制限する複雑で高コストな検索システムを管理しています。検索システム間の移行が必要な場合、この課題はさらに深刻になります。従来、移行には大幅なダウンタイム、複雑なデータ同期、ビジネス運用への大きな影響が伴います。エンタープライズアプリケーションは、カスタマーエクスペリエンス、ビジネスインテリジェンス、運用継続性に影響を与えるサービス中断を許容できません。移行戦略は、移行プロセス全体を通じてゼロダウンタイムを維持し、完全なデータ整合性を確保しながら、コスト最適化と運用改善を実現する必要があります。 2013年に設立された Octus （旧 Reorg）は、世界をリードするバイサイド企業、投資銀行、法律事務所、アドバイザリー企業向けの重要なクレジットインテリジェンスおよびデータプロバイダーです。比類のない人間の専門知識を実績のあるテクノロジー、データ、AI ツールで補完することで、Octus は金融業界全体で決定的なアクションを促す強力なインサイトを提供しています。 この記事では、Octus が Elastic Cloud で実行していた Elasticsearch ワークロードを Amazon OpenSearch Service に移行した方法を紹介します。複数のシステムを管理する状態から、OpenSearch Service を活用したコスト効率の高いソリューションへの移行の道のりをたどります。また、移行を成功させたアーキテクチャの選択と実装戦略を共有します。その結果、移行中もサービスの可用性を中断することなく、パフォーマンスの向上とコスト効率の改善を実現しました。 戦略的要件 Amazon OpenSearch Service への移行を選択した理由となるいくつかの要件を特定しました： コスト効率 ：OpenSearch Service の 料金モデル により、パフォーマンスを損なうことなくクラウド支出を最適化できました。 迅速なサポート ：AWS は問題解決を加速し、信頼性を高める、信頼できる高品質なサポートを提供しました。 一貫した信頼性 ：OpenSearch Service は最大 99.99% の SLA を提供し、Octus のミッションクリティカルなワークロードに必要な信頼性を確保しています。 クエリダウンタイムなしのシームレスな移行 ： Migration Assistant for Amazon OpenSearch Service により、移行中もクエリの可用性を中断することなく移行パスを提供し、ビジネス継続性を確保しました。 運用の簡素化 ：AWS への統合により、高いセキュリティ基準を維持しながらインフラストラクチャの複雑さを軽減しました。 ソリューション概要 Migration Assistant for Amazon OpenSearch Service は、Elasticsearch から OpenSearch Service への移行を支援するツールスイートを提供します。Octus は移行に以下の機能を使用しました： メタデータ移行： このツールにより、Octus は多様なマッピングと設定を持つ数十のインデックスを移行できました。タイムスタンプメタデータとの後方互換性の問題が特定された際、Migration Assistant ツールに直接統合されたカスタム JavaScript 変換を適用し、インデックス全体のマッピングを自動的に調整して互換性を確保しました。 履歴データ移行： Octus は Reindex-from-Snapshot を使用して、ソースクラスターのポイントインタイムスナップショットから履歴ドキュメントを移行しました。スナップショットは Amazon Simple Storage Service （Amazon S3）に保存されているため、ソースクラスターに影響を与えることなくこのプロセスをスケーリングできました。Reindex-from-Snapshot により、移行中にシャーディングスキームを調整し、ターゲットでのクラスターパフォーマンスを最適化することもできました。 ライブトラフィックリプレイ： バックフィルが完了すると、Octus は Migration Assistant の Traffic Replayer を使用して、キャプチャされたライブトラフィック（Traffic Capture Proxy から）を OpenSearch Service 互換性のために必要なリクエスト変換とともにターゲットクラスターに送信しました。その結果、ターゲットクラスターにはソースクラスターのドキュメントが含まれ、更新がリアルタイムで実行されました。 以下の図は、この移行の実装アーキテクチャ図を示しています。 図 1 – 移行ステップを含む Migration Assistant アーキテクチャ Migration Assistant for Amazon OpenSearch Service の詳細については、 AWS ソリューション のホームページをご覧ください。 図の各ノードは、移行プロセスの以下のステップに対応しています： クライアントトラフィックは既存のクラスターに送信されます。 キャプチャプロキシを備えた Application Load Balancer がトラフィックをソースに中継しながら、データを Amazon Managed Streaming for Apache Kafka （Amazon MSK）にレプリケートします。 移行コンソールを使用して、ポイントインタイムスナップショットを取得します。スナップショットが完了すると、Metadata Migration Tool を使用してターゲットクラスターにインデックス、テンプレート、コンポーネントテンプレート、エイリアスを確立します。継続的なトラフィックキャプチャが行われている状態で、Reindex-from-Snapshot がソースからデータを移行します。 Reindex-from-Snapshot が完了すると、キャプチャされたトラフィックが Amazon MSK から Traffic Replayer によってターゲットクラスターにリプレイされます。 ソースクラスターとターゲットクラスターに送信されたトラフィックのパフォーマンスと動作を、ログとメトリクスを確認して比較します。 ターゲットクラスターの機能が期待どおりであることを確認した後、クライアントを新しいターゲットにリダイレクトします。 完全な移行と最適化の道のり Octus の Elastic Cloud から Amazon OpenSearch Service への移行は、コア移行作業とその後の最適化フェーズの両方を包含しています。目標は、検索インフラストラクチャ、アプリケーション、データを Elastic Cloud から新しい OpenSearch Service ドメインに最小限の中断で正常に移行し、実際の使用データに基づいてパフォーマンスとコストを継続的に最適化することでした。 Octus は社内のカスタムインフラストラクチャフレームワーク（インフラストラクチャ自動化のための内部ツール）を使用して、ターゲットの OpenSearch Service 1.3 ドメインを構築、デプロイ、監視し、移行の堅固な基盤を確立しました。このアプローチにより、フルマネージドの AWS サービスに移行しながら、使い慣れた内部プロセスを活用できました。OpenSearch Service を使用する際のセキュリティベストプラクティスの実装については、 AWS ドキュメント を参照してください。 移行前の最適化 移行を開始する前に、Octus は移行プロセスを効率化するためにソース Elasticsearch クラスターで最適化作業を実施しました。これには、時間の経過とともに蓄積された未使用のインデックスの削除や、移行期間を不必要に延長しストレージ転送コストを増加させる大きなドキュメントの削除が含まれます。これらの準備ステップにより、移行が必要なデータ量が大幅に削減され、全体的な移行の複雑さが最小化され、Migration Assistant ツールをより効率的に使用できるようになりました。 技術的制約とバージョンの考慮事項 移行には、技術的アプローチに影響を与える特定のバージョン互換性の課題がありました。ソース Elasticsearch クラスターはバージョン 7.17 で実行されており、Python クライアントアプリケーションも Elasticsearch 7.17 互換性に制約されていました。移行をサポートするために、チームは Reindex-from-Snapshot を使用しました。これにより、既存のスナップショットから新しい OpenSearch Service クラスターにデータを再インデックスすることで、クロスシステム移行が可能になります。RFS は古いバージョンの Lucene で作成されたインデックスも書き換えるため、最新バージョンの OpenSearch Service への将来のアップグレードが簡素化されます。OpenSearch 1 または 2 への移行を評価しながら、Octus はクライアント側の変更を最小限に抑え、移行の複雑さを軽減するためにターゲットとして OpenSearch 1.3 を選択し、後でより簡単にアップグレードできるようにしました。 バージョンの選択は特に R アプリケーション環境に影響を与えました。R 言語（統計計算とデータ分析のための オープンソースプログラミング言語 ）にはネイティブの OpenSearch 1.3 クライアントサポートがなかったためです。この制約により、Octus は ropensci/elastic ライブラリを使用して新しい OpenSearch Service ドメインと統合するカスタムクライアントソリューションを開発する必要がありました。Python 環境も同様の課題を呈し、Elasticsearch 7.17 クライアントの制約により、移行アプローチを慎重に検討する必要がありました。これらのクライアント互換性の懸念は、従来のスナップショットベースの方法よりも Migration Assistant ツールを選択した要因の 1 つでした。Migration Assistant は、移行中のバージョン固有のクライアントインタラクションの管理をより適切にサポートしていたためです。 今後、Octus はアプリケーションスタックの進化とクライアントライブラリサポートの成熟に伴い、新しい OpenSearch バージョンへのアップグレードを計画しており、この移行で達成した安定性を維持しながら、最新の機能とパフォーマンス改善を活用できるようにします。 複数言語にわたるアプリケーションのモダナイゼーション アプリケーションの変更は、複数のプログラミング環境にわたる重要な技術的取り組みでした： レガシー PHP システム（5.6 および Laravel 4.2）： Octus は OpenSearch リクエストでのマッピングタイプの非推奨を処理しました。これらのマッピングタイプの指定はサポートされていないためです。elasticsearch コネクタライブラリをユーザー名/パスワード認証で引き続き使用しました。 モダン PHP アプリケーション（8.1 および Laravel 9）： これらはより包括的な変更を受け、elasticsearch/elasticsearch ライブラリを opensearch-project/opensearch-php クライアントに置き換え、IAM 認証を活用してクラスターに接続しました。 Python 環境： Django フレームワーク 2.1、3.2、5.2 を使用するバージョン 3.8、3.10、3.11、3.13 にまたがるアプリケーションは、elasticsearch ライブラリを opensearch-py に置き換え、IAM 認証に移行する必要がありました。 R アプリケーション： R 4.5.1 アプリケーションでは、Octus は互換性を確保するためにカスタムライブラリ ropensci/elastic を利用しました。 トラフィックルーティングと強化されたモニタリング 移行を促進するために、Octus は既存のクライアントをリダイレクトして、Migration Assistant の Traffic Capture Proxy を介してソースクラスターにリクエストをルーティングし、ライブトラフィックからターゲットクラスターにデータを移行しました。 このプロセス中に、モニタリングインフラストラクチャは大幅に強化されました。Octus のオブザーバビリティインフラストラクチャは、クラスターマネージャーとデータノード、ネットワーク、データストレージ、セキュリティと IAM アクセスを含む OpenSearch Service クラスターの全体的な健全性を監視します。また、アプリケーションのインデックス作成と検索パフォーマンスも監視します。これにより、ログとメトリクスが Datadog に直接送信されるため、別個のモニタリングクラスターの必要性がなくなり、オブザーバビリティが大幅に向上しました。Datadog モニターは Infrastructure-as-Code を使用して定義され、インフラストラクチャフレームワークにシームレスに統合されました。 カットオーバーと初期結果 Site Reliability Engineering チームはリリースを綿密に計画し、システムアプリケーションのダウンタイムなし、データ損失ゼロで Elasticsearch から OpenSearch Service への移行と Elasticsearch クライアントから OpenSearch Service クライアントへのカットオーバーを成功させました。初期移行フェーズでは、ゼロダウンタイム、データ損失なし、インフラストラクチャとモニタリングの完全な Infrastructure-as-Code 実装、強化されたオブザーバビリティなどの運用上のメリットを達成しながら、 52% のコスト削減 を実現しました。 移行後の最適化 移行後、Octus は新しい OpenSearch Service セットアップの本番環境およびその他の環境からの運用データに基づいて包括的な最適化を実施しました。この実際の使用データは、実際のリソース消費に関する貴重なインサイトを提供し、さらなるクラスターのリサイズに関する情報に基づいた意思決定を可能にしました。 使用メトリクスの分析と戦略的なリサイズにより、Octus はクラスターサイズを運用ニーズにより正確に合わせ、支出を最小限に抑えながら継続的なパフォーマンスを促進しました。この最適化フェーズでは、元の Elastic Cloud コストと比較して追加で 33% のコスト削減 を達成し、一貫した最適なパフォーマンスを維持しながら、合計削減率を 85% にしました。 運用モニタリング Octus は Datadog を使用して検索とインデックス作成のレイテンシーの両方を監視し、Amazon OpenSearch Service クラスターのパフォーマンスをリアルタイムで可視化しています。以下のスクリーンショットは、カスタム Datadog ダッシュボードが OpenSearch Service クラスターのライブビューを提供する方法を示しています。この可視化は、取り込みプロセスの概要と詳細なインサイトの両方を提供し、ストレージとドキュメント数を理解するのに役立ちます。ダッシュボードの下半分は、個々のノードの健全性とパフォーマンスメトリクス（読み取りと書き込みのレイテンシー、スループット、IOPS など）の時系列ビューを表示します。 図 2 – Datadog ダッシュボード 移行のオブザーバビリティ Migration Assistant for Amazon OpenSearch Service は、移行の進捗を観察および検証するためのいくつかのダッシュボードを提供します。これらのオブザーバビリティ機能を使用することで、お客様はバックフィルとライブキャプチャおよびリプレイの進捗の両方を追跡でき、本番ワークロードをターゲットクラスターに切り替える前に信頼性を確保できます。以下のグラフは Octus の移行の例で、約 4TB のデータが約 9 時間（08:00 から 17:00）で移行されました。 図 3 – ディスク使用量によるバックフィル進捗 図 4 – 検索可能なドキュメントによるバックフィル進捗 バックフィルが完了すると、キャプチャされたトラフィックがリプレイされ、ソースクラスターとターゲットクラスター間の継続的なアクティビティが同期されます。 バックフィルが完了した時点（約 17:00）で、ターゲットクラスターはソースより約 467 分遅れていました。リプレイプロセスは、キャプチャされたトラフィックをソースで最初に取り込まれた速度よりも速い速度で処理することで、この遅延を急速に削減しました。 図 5 – バックフィル完了後のリプレイ遅延 遅延時間が 0 に達すると、ターゲットクラスターは完全に同期され、本番トラフィックを安全に再ルーティングできました。Octus は最終的な切り替えを行う前に、数日間ターゲットでリプレイされたトラフィックを観察することを選択しました。 卓越性の達成 Octus の Amazon OpenSearch Service への移行は、顕著な成果をもたらしました： スケーラビリティ – Octus は 3 つの環境で Q&A に利用可能なドキュメント数をほぼ 2 倍に増やし、数週間ではなく数日で実現しました。オートスケーリングルールとコントロールを備えた AWS Fargate を使用した Amazon Elastic Container Service （Amazon ECS）の使用により、ピーク使用時間中のサービスの弾力的なスケーラビリティを実現しています。 コスト削減 – Elastic Cloud から OpenSearch Service に移行することで、Octus の月間インフラストラクチャコストは 85% 削減されました。 検索パフォーマンスの向上 – Octus は移行中も一貫したレスポンスタイムを維持し、レイテンシーへの悪影響はなく、クエリスループットと全体的な検索パフォーマンスが 20% 向上しました。 ゼロダウンタイム – Octus は移行中のダウンタイムがゼロで、アプリケーション全体で 100% のアップタイムを達成しました。 運用オーバーヘッドの削減 – 移行後、Octus の DevOps および SRE チームはメンテナンス負担とオーバーヘッドが 30% 削減されました。1 つのシステムを使用するようになったため、SOC2 コンプライアンスのサポートも簡単になりました。 タイムラインの短縮 – 移行全体が予定より早く完了し、計画から完全な完了まで 1 四半期未満で実現しました。 「Elastic Cloud から Amazon OpenSearch Service への移行は、サードパーティへの依存を最小限に抑え、Octus のシステムインフラストラクチャの信頼性を強化するという、より広範な戦略の重要な要素でした。Migration Assistant for Amazon OpenSearch Service により、データ損失ゼロ、ユーザーへのダウンタイムほぼゼロでシームレスな移行を実行できました。」– Vishal Saxena 氏、CTO、Octus まとめ この記事では、Octus が Migration Assistant for OpenSearch Service を使用して Elasticsearch ワークロードを Elastic Cloud から Amazon OpenSearch Service に正常に移行し、ゼロダウンタイムと大幅な運用改善を達成した方法を紹介しました。 Migration Assistant for OpenSearch Service は、包括的なツールスイートを通じてこの複雑な移行をサポートしました。Metadata Migration 機能は、多様なマッピングと設定を持つ数十のインデックスを移行し、カスタム JavaScript 変換で後方互換性の問題を処理しました。Reindex-from-Snapshot は、ソースクラスターに影響を与えることなくポイントインタイムスナップショットから履歴ドキュメントを移行し、パフォーマンス向上のためにシャーディングスキームも最適化しました。Live Traffic Replay により、移行プロセス全体を通じてターゲットクラスターがリアルタイム更新と同期された状態を維持しました。 移行は複数の側面で大きな成果をもたらしました。Octus は月間インフラストラクチャコストを 85% 削減しながら、3 つの環境で検索可能なドキュメント数をほぼ 2 倍に増やしました。検索パフォーマンスはクエリスループットが 20% 向上し、一貫したレスポンスタイムでレイテンシーへの悪影響はありませんでした。移行はアプリケーション全体でゼロダウンタイムと 100% のアップタイムを維持し、DevOps および SRE チームはメンテナンス負担と運用オーバーヘッドが 30% 削減されました。移行全体は 1 四半期未満で予定より早く完了しました。 Migration Assistant for OpenSearch Service の詳細と同様の成果を達成する方法については、 AWS ソリューション のホームページをご覧ください。 Octus にアクセスして、厳密に検証されたインテリジェンスを迅速に提供し、クレジットライフサイクル全体の専門家に完全な全体像を提供する方法をご覧ください。 LinkedIn と X で Octus をフォローしてください。 著者について Harmandeep Sethi は Octus の SRE エンジニアリングおよびインフラストラクチャフレームワーク責任者で、大規模システムの実装において高パフォーマンスチームをリードしてきた約 10 年の経験があります。オブザーバビリティ、レジリエンスエンジニアリング、インフラストラクチャフレームワークによる運用プロセスの自動化のベストプラクティスを推進することで、Octus の検索エンジンインフラストラクチャとサービスの変革とモダナイゼーションに重要な役割を果たしてきました。 Serhii Shevchenko は Octus の Site Reliability Engineer です。ソフトウェア開発と Site Reliability Engineering で合計 9 年の経験があり、システムの信頼性とパフォーマンスの向上に専門性を持っています。Elasticsearch Cloud から AWS OpenSearch への会社の重要な移行において、アプリケーション側の主要な開発者でした。彼の計画は、クライアント向けダウンタイムゼロで移行を実行する上で重要な役割を果たしました。 Govind Bajaj は Octus の Senior Site Reliability Engineer で、高パフォーマンスのエンジニアリングチームと重要なシステムをサポートするスケーラブルなインフラストラクチャの設計と実装を専門としています。8 年以上の経験を持ち、複雑な問題を分解して実用的で適切に設計されたソリューションに変えることに優れており、安全で観測可能でレジリエントなプラットフォームの構築に強い焦点を当てています。 Virendra Shinde は Octus の Platform 責任者で、クラウドインフラストラクチャ、Site Reliability、Octus 製品スイートを支えるコアフレームワークを統括しています。Octus に入社する前は、Grayscale Investments で 2 年間、投資家ポータルとデータ API をゼロから構築しました。それ以前は、Blackstone で 8 年間、複数の開発チームをリードしました。メリーランド大学で情報管理の修士号を取得しています。 Brian Presley は OpenSearch の Software Development Manager で、OpenSearch Migrations と OpenSearch Serverless の背後にあるチームをリードし、スケーラブルで影響力の高い検索および分析ソリューションを構築しています。 Andre Kurait は AWS の Software Development Engineer II で、テキサス州オースティンを拠点としています。現在、Migration Assistant for Amazon OpenSearch Service に取り組んでいます。Amazon OpenSearch に参加する前は、Amazon Health Services で働いていました。余暇には、旅行、料理、教会のスポーツリーグでのプレーを楽しんでいます。カンザス大学でコンピューターサイエンスと数学の理学士号を取得しています。 Vaibhav Sabharwal は AWS の Senior Solutions Architect で、ニューヨークを拠点としています。新しいクラウドテクノロジーの学習と、お客様のクラウド導入戦略の構築、革新的なソリューションの設計、運用の卓越性の推進を支援することに情熱を持っています。AWS の Financial Services および Storage Technical Field Communities のメンバーとして、業界内の協力的な取り組みに積極的に貢献しています。 この記事は Kiro が翻訳を担当し、ソリューションアーキテクト の 榎本 貴之 がレビューしました。

本記事は 2025年12月2日 に公開された「 Amazon OpenSearch Service improves vector database performance and cost with GPU acceleration and auto-optimization 」を翻訳したものです。 本日、 Amazon OpenSearch Service において、サーバーレス GPU アクセラレーションとベクトルインデックスの自動最適化を発表しました。これにより、大規模なベクトルデータベースをより高速かつ低コストで構築でき、検索品質、速度、コストの最適なトレードオフを実現するようにベクトルインデックスを自動的に最適化できます。 本日発表された新機能は以下のとおりです。 GPU アクセラレーション – GPU アクセラレーションを使用しない場合と比較して、最大 10 倍高速にベクトルデータベースを構築でき、インデックス作成コストを 4 分の 1 に削減できます。また、10 億規模のベクトルデータベースを 1 時間以内に作成できます。コスト削減と速度の大幅な向上により、市場投入までの時間、イノベーションの速度、大規模なベクトル検索の導入において優位性を得ることができます。 自動最適化 – ベクトルの専門知識がなくても、ベクトルフィールドの検索レイテンシー、品質、メモリ要件の最適なバランスを見つけることができます。この最適化により、デフォルトのインデックス設定と比較して、コスト削減と再現率の向上を実現できます。手動でのインデックスチューニングには数週間かかることがあります。 これらの機能を使用して、OpenSearch Service 上でベクトルデータベースをより高速かつコスト効率よく構築できます。生成 AI アプリケーション、製品カタログやナレッジベースの検索などに活用できます。GPU アクセラレーションと自動最適化は、新しい OpenSearch ドメインまたはコレクションを作成するとき、および既存のドメインまたはコレクションを更新するときに有効にできます。 それでは、仕組みを見ていきましょう！ ベクトルインデックスの GPU アクセラレーション OpenSearch Service ドメインまたはサーバーレスコレクションで GPU アクセラレーションを有効にすると、OpenSearch Service はベクトルインデックス作成ワークロードを高速化する機会を自動的に検出します。このアクセラレーションにより、OpenSearch Service ドメインまたはサーバーレスコレクション内のベクトルデータ構造の構築が高速化されます。 GPU インスタンスをプロビジョニングしたり、使用状況を管理したり、アイドル時間に対して支払ったりする必要はありません。OpenSearch Service は、アクセラレーションされたワークロードをアカウント内のドメインまたはコレクションの Amazon Virtual Private Cloud (Amazon VPC) に安全に分離します。OpenSearch Compute Units (OCU) – Vector Acceleration の料金を通じて、実際の処理に対してのみ支払います。 GPU アクセラレーションを有効にするには、 OpenSearch Service コンソール に移動し、OpenSearch Service ドメインまたはサーバーレスコレクションを作成または更新するときに、 Advanced features セクションで Enable GPU Acceleration を選択します。 以下の AWS Command Line Interface (AWS CLI) コマンドを使用して、既存の OpenSearch Service ドメインで GPU アクセラレーションを有効にできます。 $ aws opensearch update-domain-config \ --domain-name my-domain \ --aiml-options '{"ServerlessVectorAcceleration": {"Enabled": true}}' GPU 処理用に最適化されたベクトルインデックスを作成できます。この例のインデックスは、 index.knn.remote_index_build.enabled を有効にすることで、テキスト埋め込み用の 768 次元ベクトルを格納します。 PUT my-vector-index { "settings": { "index.knn": true, "index.knn.remote_index_build.enabled": true }, "mappings": { "properties": { "vector_field": { "type": "knn_vector", "dimension": 768, }, "text": { "type": "text" } } } } これで、標準の OpenSearch Service オペレーションを使用して、bulk API でベクトルデータを追加し、インデックスを最適化できます。GPU アクセラレーションは、インデックス作成と force-merge オペレーションに自動的に適用されます。 POST my-vector-index/_bulk {"index": {"_id": "1"}} {"vector_field": [0.1, 0.2, 0.3, ...], "text": "Sample document 1"} {"index": {"_id": "2"}} {"vector_field": [0.4, 0.5, 0.6, ...], "text": "Sample document 2"} インデックス構築のベンチマークを実行したところ、GPU アクセラレーションによる速度向上は 6.4 倍から 13.8 倍の範囲でした。今後の投稿で、さらなるベンチマークと詳細をお届けする予定です。 詳細については、Amazon OpenSearch Service デベロッパーガイドの「 GPU acceleration for vector indexing 」を参照してください。 ベクトルデータベースの自動最適化 新しいベクトル取り込み機能を使用して、 Amazon Simple Storage Service (Amazon S3) からドキュメントを取り込み、ベクトル埋め込みを生成し、インデックスを自動的に最適化し、大規模なベクトルインデックスを数分で構築できます。取り込み中に、自動最適化は OpenSearch Service ドメインまたはサーバーレスコレクションのベクトルフィールドとインデックスに基づいて推奨事項を生成します。これらの推奨事項のいずれかを選択して、手動でマッピングを設定する代わりに、ベクトルデータセットをすばやく取り込んでインデックスを作成できます。 開始するには、 OpenSearch Service コンソール の左側のナビゲーションペインにある Ingestion メニューの下の Vector ingestion を選択します。 以下の手順で新しいベクトル取り込みジョブを作成できます。 データセットの準備 – S3 バケットに OpenSearch Service parquet ドキュメントを準備し、宛先としてドメインまたはコレクションを選択します。 インデックスの設定と最適化の自動化 – ベクトルフィールドを自動最適化するか、手動で設定します。 取り込みとインデックス作成の高速化 – OpenSearch Ingestion パイプラインを使用して、Amazon S3 から OpenSearch Service にデータをロードします。大規模なベクトルインデックスを最大 10 倍高速に、4 分の 1 のコストで構築できます。 ステップ 2 では、自動最適化ベクトルフィールドを使用してベクトルインデックスを設定します。自動最適化は現在、1 つのベクトルフィールドに制限されています。自動最適化ジョブが完了した後に、追加のインデックスマッピングを入力できます。 ベクトルフィールドの最適化設定は、ユースケースによって異なります。たとえば、高い検索品質（再現率）が必要で、より高速な応答が不要な場合は、 Latency requirements (p90) で Modest を選択し、 Acceptable search quality (recall) で 0.9 以上を選択します。ジョブを作成すると、ベクトルデータの取り込みとベクトルインデックスの自動最適化が開始されます。処理時間はベクトルの次元数によって異なります。 詳細については、OpenSearch Service デベロッパーガイドの「 Auto-optimize vector index 」を参照してください。 提供開始 Amazon OpenSearch Service の GPU アクセラレーションは、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、欧州 (アイルランド) リージョンで利用可能になりました。OpenSearch Service の自動最適化は、米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (ムンバイ)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、欧州 (フランクフルト)、欧州 (アイルランド) リージョンで利用可能になりました。 OpenSearch Service は、ベクトルデータベースのインデックス作成に使用された OCU – Vector Acceleration に対してのみ別途課金されます。詳細については、 OpenSearch Service の料金ページ をご覧ください。 ぜひお試しいただき、 AWS re:Post for Amazon OpenSearch Service または通常の AWS サポート窓口を通じてフィードバックをお寄せください。 — Channy 著者について Channy Yun (윤석찬) は、AWS News Blog のリードブロガーであり、AWS Cloud のプリンシパルデベロッパーアドボケイトです。オープンウェブの愛好家であり、根っからのブロガーとして、コミュニティ主導の学習とテクノロジーの共有を大切にしています。 この記事は Kiro が翻訳を担当し、ソリューションアーキテクト の 榎本 貴之 がレビューしました。

本記事は 2025年11月21日 に公開された「 Introducing Cluster Insights: Unified monitoring dashboard for Amazon OpenSearch Service clusters | AWS Big Data Blog 」を翻訳したものです。 Amazon OpenSearch Service クラスターは、CloudWatch や Amazon OpenSearch Service コンソールを通じてアクセスできる豊富な運用メトリクスを提供し、効果的なパフォーマンスモニタリングとアラート作成をサポートします。しかし、クラスター内の回復力やパフォーマンスの課題を特定することは困難な場合があります。リソースを大量に消費するクエリを特定したり、パフォーマンス低下の傾向を把握したりするプロセスには時間がかかることがあります。 これらの課題に対処するため、私たちは Cluster Insights をリリースしました。これは、厳選されたインサイトと実行可能な緩和手順を提供する統合ダッシュボードです。このダッシュボードは、ノード、インデックス、シャードレベルの詳細なメトリクスを表示し、最高の回復力と可用性を維持するためのセキュリティと回復力のベストプラクティスの簡潔なサマリーを提供します。 このブログでは、主要な機能とメトリクスを含む Cluster Insights のセットアップと使用方法について説明します。最後まで読むと、Cluster Insights を使用して OpenSearch Service クラスター内のパフォーマンスと回復力の問題を認識し、対処する方法を理解できるようになります。 Cluster Insights の使用開始 Cluster Insights は、OpenSearch バージョン 2.17 以降を実行している OpenSearch Service ユーザーに追加料金なしで利用できます。Cluster Insights にアクセスするには、OpenSearch ドメインの管理者レベルの権限が必要です。Cluster Insights は OpenSearch UI からのみ利用できます。OpenSearch UI は、複数のデータソースのサポート、ダッシュボードエクスペリエンスのゼロダウンタイムアップグレード、効果的なチームコラボレーションのためのキュレーションされたワークスペースを提供します。まず、データソース（クラスター）を OpenSearch UI アプリケーションに関連付ける必要があります。詳細な手順は ユーザーガイド に記載されています。OpenSearch UI コンソールのエクスペリエンスは、以下のスクリーンショットのようになります。 OpenSearch UI アプリケーションを使用して Cluster Insights にアクセスするには： Amazon OpenSearch Service コンソールで、OpenSearch UI (Dashboards) に移動し、Application URL を選択して OpenSearch UI アプリケーションにアクセスします。 OpenSearch UI アプリケーションで、左下隅の設定アイコンを選択し、 Data administration を選択します。 Data administration overview ページ、または左側のナビゲーションの Manage data の下で、 Cluster insights を選択します。 Cluster Insights の概要 Cluster insights – Overview は、接続されているすべての OpenSearch ドメインの健全性とインサイトを表示するランディングページとして機能します。5 つのセクションで構成されています： Current cluster status – クラスターの健全性ステータス（Green、Yellow、Red）をドーナツチャートで表示します。 Insights trend – 過去 30 日間の問題パターンを追跡し、新たな問題の特定と解決の進捗状況の追跡に役立ちます。この傾向分析は、運用変更の影響を監視したり、繰り返し発生する問題をトラブルシューティングしたりする際に特に価値があります。 Current open insights – クラスター全体で現在アクティブなインサイトの数と重大度の内訳を表示します。 OpenSearch service clusters – 健全性ステータス、インサイト数、ノード、シャード、アクティブなクエリなどの重要な統計情報とともに、すべてのドメインを一覧表示します。 Top insights by severity – 即座に対応が必要な問題を優先順位付けします。各インサイトには明確な説明と具体的な推奨事項が付属しており、複雑なモニタリングデータを実行可能なタスクに変換します。この優先順位付けされたビューにより、チームはシャードサイズの問題、ディスク容量の問題、パフォーマンスのボトルネックなど、重要な問題に最初に集中できます。 これらのセクションを組み合わせることで、OpenSearch Service インフラストラクチャの包括的なビューが提供され、単一のダッシュボードからクラスターの健全性を評価し、傾向を特定し、重要な問題に対処できます。 クラスターの健全性 Cluster insights – Overview ページの OpenSearch ドメインから特定のクラスターを選択すると、健全性ステータス、アクティブなインサイト、パフォーマンスメトリクスを含むクラスター固有の詳細が表示されます。概要セクションには、シャード、ノード、インデックスの数、合計ドキュメントサイズなどの重要なメトリクスとともにクラスターの健全性が表示されます。また、回復力とセキュリティの領域全体でドメインが従っている設定のベストプラクティスを確認することもできます。 下部のセクションには、現在の問題の詳細なビューを提示する実行可能なインサイトのテーブルが含まれています。このテーブルはランディングページのインサイトを反映していますが、選択したクラスターに影響を与える問題に特化しています。ディスク容量不足やシャード数の問題などの重大度の高い問題や、クラスターのパフォーマンスに影響を与える可能性のある中程度の重大度の懸念事項を確認できます。 各インサイトエントリはインタラクティブな要素として機能します。問題を選択すると、根本原因の特定と具体的な修復手順を含む詳細な分析が表示されます。テーブルには、生成タイムスタンプ、重大度レベル、推奨事項の数、現在のステータスなどの重要なメタデータが含まれているため、ユーザーは問題を効果的に優先順位付けして対処できます。 インサイトの詳細 すべてのインサイトは、詳細な分析と実行可能な推奨事項を提供します。 Shard Count インサイトを例にとると、選択すると問題の包括的な内訳が表示されます。OpenSearch クラスターが JVM ヒープサイズに基づいてノードで許可されているシャード数を超過していることと、影響を受けるリソースの詳細なリストが表示されます。 詳細ビューには、影響を受ける各ノードとインデックスを正確に特定するリソースマップが含まれており、ノード ID、シャード数、問題の原因となっているインデックスなどの重要な情報が表示されます。 推奨事項は 2 つのレベルで整理されています。クラスターレベルの推奨事項は、クラスターのスケーリングやグローバルシャード割り当て設定の調整など、全体的なアーキテクチャの改善に対処します。インデックスレベルの推奨事項は、個々のインデックスに対する具体的なアクションを提供します。たとえば、アイドル状態のシャードを UltraWarm ストレージに移動する提案が表示される場合があります。これらは、過去 10 日間に検索またはインデックス作成操作がなく、少なくとも 5 日以上経過しているシャードであり、アクティブなシャード数を減らすためにウォームストレージに移動する理想的な候補です。このガイダンスはすべて Cluster Insights インターフェース内で直接利用でき、異なるツールやコンソール間を切り替える必要がありません。 Node、Index、Shard、Query ビュー クラスターの健全性の横で、特定のクラスターの Node、Index、Shard、Query の詳細を確認できます。これらのビューは、リソース（CPU、メモリ、ディスク）使用率、検索およびインデックスのレイテンシーなどの重要なメトリクスを表示します。 Node ビュー Node view タブは、クラスター全体の個々のノードのパフォーマンスの包括的なビューを提供します。このテーブルには、全体的なノードの健全性を示すヒートスコア、リソース使用率（CPU、メモリ、ディスク）、検索およびインデックスのレイテンシーとレート、各ノードで実行されている上位 N 個のシャードとクエリを表示するクイックリンクなど、各ノードの重要なメトリクスが表示されます。 このビューは、リソース使用率が高いノードやパフォーマンスが低下しているノードを特定するのに役立ちます。ノード ID をクリックして各ノードをさらに詳しく調べ、時間の経過に伴うリソース使用量の傾向を示す詳細な時間ベースのメトリクスを表示できます。さらに、上位 N 個のシャードリンクをクリックすると、選択したノードで実行されているシャードのみを表示するように自動的にフィルタリングされた Shard View に直接移動でき、パフォーマンスの問題の原因となっている特定のシャードを特定できます。 Index ビュー Index view タブは、インデックスレベルで集計されたパフォーマンスメトリクスを表示します。各インデックスについて、ドキュメント数とストレージサイズ、検索のレイテンシーとレート、インデックスのレイテンシーとレート、インデックスに影響を与える上位 N 個のクエリへのアクセスを監視できます。この視点は、どのインデックスがクラスターの負荷を引き起こしているかを理解し、インデックス設定レベルでの最適化の機会を特定するのに役立ちます。 Shard ビュー Shard view タブは、個々のシャードのメトリクスを表示することで、クラスターパフォーマンスの最も詳細なビューを提供します。各行には、シャード ID と割り当てられたノード、インデックスの関連付けとリソースプレッシャーメトリクス（CPU、メモリ）、シャードごとの検索およびインデックスのレイテンシーが表示されます。この詳細なビューにより、パフォーマンスの問題を引き起こしている特定のシャードを特定し、シャード配置の不均衡を識別し、ターゲットを絞った修復アクションを実行できます。 Query ビュー Cluster insights ページの Query view は、すべてのクエリの実行統計、CPU とメモリの使用量、完了の進捗状況を分解するライブダッシュボードを提供します。これにより、最大のリソース消費を引き起こしているクエリ（上位 N 個のクエリ）を監視できます。ノード、インデックス、ユーザー別の分布を示す直感的なドーナツチャートとスコアボードにより、このインターフェースはオペレーターがパフォーマンスのボトルネックと重いワークロードを迅速に特定し、ターゲットを絞った最適化と自信を持ったスケーリングの決定をサポートします。 Query insights Cluster insights に加えて、Query insights を使用して、Expand、Query、Fetch フェーズ全体で実行されている正確なクエリとレイテンシーを表示することもできます。これにより、検索開発者がクエリをさらに微調整するための貴重なインサイトが得られます。 まとめ Cluster Insights は、OpenSearch Service クラスター管理を事後対応型のトラブルシューティングからプロアクティブな最適化へと変革します。ヒートスコアを備えた統合ダッシュボードと、安定性、回復力、セキュリティの柱全体にわたるベストプラクティスを提供することで、アカウントレベルで検索インフラストラクチャの可視性を提供します。 実行可能な推奨事項とステップバイステップの修復ガイダンスにより、あらゆる経験レベルのユーザーがシャードの不均衡やリソースのボトルネックなどの複雑な問題を効果的に解決できます。 Query insights との統合により、リソース消費パターンのリアルタイムの可視性が提供され、チームは詳細なプロファイリングとレイテンシー分析を通じてパフォーマンスに重要なクエリを特定して最適化できます。 詳細については、 AWS OpenSearch Service ユーザーガイド を参照してください。 著者について Siddhant Gupta は、AWS のシニアプロダクトマネージャー（テクニカル）で、OpenSearch の AI イノベーションをリードしています。技術的な専門知識に関係なく、高度な AI 機能を顧客がアクセスしやすく実用的なものにすることに注力しています。彼の仕事は、最先端の AI テクノロジーをスケーラブルでユーザーフレンドリーなソリューションにシームレスに統合することに重点を置いています。 Varunsrivathsa Venkatesha は、AWS のソフトウェア開発マネージャーで、Intelligent Domain Management チームをリードしています。Amazon OpenSearch Service のモニタリングおよびリカバリサービスに注力し、これらのサービスを活用して顧客にシームレスなドメイン管理エクスペリエンスを提供しています。 Gagandeep Juneja は、AWS のシニアソフトウェア開発エンジニアで、OpenSearch に取り組んでいます。 Jinhwan Hyon は、韓国ソウルを拠点とする AWS のスペシャリストソリューションアーキテクトで、Amazon OpenSearch Service に注力しています。データと分析に関心があり、顧客が AI をデータ戦略に統合するのを支援することに情熱を持っています。特に生成 AI とインテリジェントエージェントに魅了されており、これらのテクノロジーが意思決定を革新し、複雑なビジネス課題を解決する方法を探求しています。 この記事は Kiro が翻訳を担当し、ソリューションアーキテクト の 榎本 貴之 がレビューしました。

本記事は 2025年11月11日 に公開された「 Introducing the Amazon OpenSearch Lens for the AWS Well-Architected Framework | AWS Big Data Blog 」を翻訳したものです。 今年初め、AWS は AWS Well-Architected ホワイトペーパーである Amazon OpenSearch Service レンズ をリリースしました。AWS Well-Architected フレームワークは、アーキテクチャを評価し、スケーラブルな設計を実装するための一貫したアプローチを提供します。このフレームワークを使用して、Amazon OpenSearch Service レンズは AWS Well-Architected レビューを実施し、OpenSearch Service デプロイメントの技術的リスクを評価・特定する方法を概説しています。 この記事では、Amazon OpenSearch Service レンズを使用して、OpenSearch Service ワークロードをアーキテクチャのベストプラクティスに照らして評価する方法を紹介します。 AWS Well-Architected フレームワークの理解 AWS では、適切に設計されたクラウド環境は、ビジネス成果の達成を支援するための基盤となります。AWS Well-Architected フレームワークは、AWS がさまざまな業界の組織と協力して得た集合的な経験を、アーキテクチャを評価し、時間とともにスケールする設計を実装するための構造化されたアプローチとして凝縮したものです。AWS Well-Architected フレームワークは、運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、持続可能性の 6 つの柱で構成されています。このフレームワークを使用することで、クラウドアーキテクト、システムビルダー、エンジニア、開発者は、アプリケーションとワークロードのための安全で高性能、回復力があり、効率的なインフラストラクチャを構築できます。 OpenSearch Service レンズ OpenSearch Service レンズは、Amazon OpenSearch Service をクラウドネイティブなアプローチで使用するための、お客様実証済みの設計原則とベストプラクティスのコレクションです。これらの推奨事項は、AWS がお客様、AWS パートナー、コミュニティ、および AWS OpenSearch テクニカルスペシャリストコミュニティから収集した知見に基づいています。 OpenSearch Service レンズは AWS Well-Architected フレームワークを拡張し、Amazon OpenSearch ワークロードに固有の重要なアーキテクチャ上の質問に対処するのに役立ちます。例えば： 最適なパフォーマンスのために Amazon OpenSearch Service ドメインをどのようにサイジングおよび設定しますか？ コストとアクセシビリティのバランスを取るために、どのようなデータ保持およびライフサイクル管理戦略が役立ちますか？ 検索機能を維持しながら機密データを保護するセキュリティコントロールをどのように実装しますか？ データ量が増加しても信頼性の高い検索エクスペリエンスを確保するための運用プラクティスは何ですか？ OpenSearch Service レンズは、モノのインターネット（IoT）、ゲーム、人工知能（AI）と機械学習（ML）、SAP、サーバーレステクノロジーなどの専門的なワークロードに焦点を当てた AWS Well-Architected レンズのコレクションに加わります。 このレンズは、評価と改善のための最も一般的な領域のいくつかを強調しています。AWS Well-Architected フレームワークの 6 つの柱全体にわたって整合し、洞察を提供するように設計されています： 運用上の優秀性 は、ビジネス価値を提供するためのシステムの実行と監視、およびプロセスと手順の継続的な改善に焦点を当てています。このトピックには、開発をサポートしワークロードを効果的に実行する能力、運用に関する洞察を得ること、およびビジネス価値を提供するためのサポートプロセスの継続的な改善が含まれます。 セキュリティ は、データとシステムの保護に焦点を当てています。これは、ユーザーとアプリケーションのための きめ細かなアクセス制御 の実装、暗号化とネットワーク制御によるドメインアクセスの保護、脆弱性の検出と軽減、潜在的な攻撃対象領域の削減、および機密データの保護に対処します。 信頼性 は、エンドユーザー環境が期待どおりに正しく一貫して動作することを確保することに焦点を当てています。このトピックには、自動災害復旧メカニズムの実装、高可用性のための マルチアベイラビリティーゾーンデプロイメント の設計、需要に応じた ドメイン容量のスケーリング 、および人的エラーを削減するための運用タスクの自動化が含まれます。また、 バックアップとリストア戦略の実装 、クラスター状態の管理、およびサービスのパフォーマンスと可用性を維持するための監視とアラートの設定もカバーしています。 パフォーマンス効率 は、Amazon OpenSearch Service リソースの効果的な使用に焦点を当てています。これには、ワークロード要件に基づいた適切なインスタンスタイプとストレージオプションの選択、パフォーマンス監視と最適化戦略の実装、および運用オーバーヘッドを削減するための OpenSearch Service 機能の使用が含まれます。また、ドメイン設定のチューニング、データインデックスパターンの管理、およびコスト効率を維持しながら最高のパフォーマンスを達成するための検索と分析クエリの最適化もカバーしています。 コスト最適化 は、費用の効果的な管理に焦点を当てています。このトピックでは、ワークロードごとにドメイン費用を追跡するためのコスト配分タグの実装、ニーズに基づいた適切なインスタンスタイプとストレージオプションの選択、および予測可能なワークロードのためのリザーブドインスタンスなどのコスト効率の高い支払いオプションの選択に対処します。また、アクセス頻度の低いデータのための UltraWarm およびコールドストレージ階層の使用、ストレージコストを管理するためのインデックスライフサイクルポリシーの実装、およびドメインの適正サイズ化とパフォーマンス対コスト比の最適化のための使用パターンの監視もカバーしています。 持続可能性 は、クラウドワークロードの実行による環境への影響を最小限に抑えることに焦点を当てています。OpenSearch のトピックでは、効率的なドメインサイジング戦略の実装、パフォーマンス対エネルギー比が最も優れたインスタンスタイプの選択、およびアクティブなコンピューティングフットプリントを削減するための保持ポリシーの最適化と異なるストレージ階層の使用に対処します。 このレンズを Amazon OpenSearch Service ワークロードに適用することで、一般的なアーキテクチャ原則を超えて、検索と分析の実装の特性に対処する洞察を得ることができます。OpenSearch Service レンズは、新しい Amazon OpenSearch Service アーキテクチャの設計や既存のデプロイメントの最適化において、AWS のベストプラクティスに沿ったアーキテクチャ上の意思決定を行うための一貫したフレームワークを提供します。 OpenSearch レンズの使用開始 Amazon OpenSearch Service レンズを使い始めるには、AWS Well-Architected フレームワークの 6 つの柱（運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、持続可能性）を確認してください。 次に、AWS マネジメントコンソールにサインインし、 AWS Well-Architected Tool を開きます。カスタムレンズに移動し、Amazon OpenSearch Service レンズをインポートします。レンズをインポートした後、専門的なアンケートを使用して OpenSearch Service ワークロードをベストプラクティスに照らして評価でき、アンケートを完了すると、洞察に富んだフィードバックを得ることができます。 次に、チームとアーキテクチャレビューを計画し、レンズの基準を使用して Amazon OpenSearch Service ドメインを評価します。うまく機能している点とデプロイメントを改善できる点を含め、評価結果を文書化します。Amazon OpenSearch Service レンズの質問を理解するためのヘルプについては、 レンズのドキュメント を参照してください。 AWS サポートプラン をお持ちの場合は、アーキテクチャレビューのサポートをリクエストできます。OpenSearch Service レンズの質問は、知識をテストするためではなく、アーキテクチャ上の意思決定をガイドすることを目的としています。各質問の背後にあるアーキテクチャ原則を理解することに焦点を当ててください。評価を完了したら、ワークロードのパフォーマンス、データの耐久性、およびコスト効率に影響を与える可能性のある発見事項に対処する優先順位付けされた改善計画を作成します。これらの改善の実装についてのヘルプが必要な場合は、AWS プロフェッショナルサービスまたは Amazon OpenSearch Service を専門とする AWS パートナーと協力できます。 まとめと次のステップ Amazon OpenSearch Service レンズは、ビジネス要件に沿った適切に設計された検索と分析ワークロードを構築するための実用的なガイダンスを提供します。AWS Well-Architected Tool にアクセスし、このレンズを OpenSearch Service ドメインに適用することから始めてください。アーキテクチャレビューを開発プロセスの定期的な一部にしてください。他の人が OpenSearch Service の実装を改善するのに役立つよう、AWS コミュニティと経験を共有することを検討してください。 AWS Well-Architected レンズの詳細については、 AWS Well-Architected Tool ユーザーガイド を参照してください。この専門的なガイダンスをアーキテクチャレビューに組み込み、AWS 上の検索と分析ワークロードの継続的な改善を推進するために使用することをお勧めします。 AWS は、新しいサービス機能とアーキテクチャのベストプラクティスを反映するために、Amazon OpenSearch Service レンズを定期的に更新しています。これらの更新により、アーキテクチャの卓越性を維持しながら、Amazon OpenSearch Service の最新の改善を活用できます。 お客様の成功事例や追加リソースを含む Amazon OpenSearch Service の詳細については、 Amazon OpenSearch Service ページをご覧ください。 著者について Muslim Abu-Taha は、アラブ首長国連邦ドバイを拠点とする Amazon OpenSearch のシニアワールドワイドスペシャリストソリューションアーキテクトです。ヨーロッパ、中東、アフリカのお客様と協力し、AWS OpenSearch ワークロードの導入とスケーリングをサポートしています。 Shih-Yong Wang は、台湾の AWS のソリューションアーキテクトです。20 年以上の IT 専門知識を活用して、さまざまな業界のお客様を支援しています。AWS サービスを戦略的に活用することで、ビジネス価値を促進し、イノベーションの無限の機会を創出するお手伝いをしています。 貢献者 著者は、この新しい AWS Well-Architected フレームワーク用 OpenSearch レンズの開発に貴重な協力をいただいた以下の方々に感謝いたします：Muslim Abu-Taha（Amazon OpenSearch シニアワールドワイドスペシャリストソリューションアーキテクト）、Shih-Yong Wang（ソリューションアーキテクチャマネージャー）、Ankush Agarwal（ソリューションアーキテクト）、Jun-Tin Yeh（クラウド最適化サクセスソリューションアーキテクト）。 また、技術レビューに貢献いただいた以下の方々にも感謝いたします：Cedric Pelvet（プリンシパル OpenSearch ソリューションアーキテクト）、Hajer Bouafif（シニア OpenSearch ソリューションアーキテクト）、Francisco Losada（OpenSearch ソリューションアーキテクト）、Bharav Patel（OpenSearch ソリューションアーキテクト）、Praveen Prasad（シニアスペシャリストテクニカルアカウントマネージャー）。 この記事は Kiro が翻訳を担当し、ソリューションアーキテクトの榎本 貴之がレビューしました。

本記事は 2025年10月28日 に公開された「 Amazon Kinesis Data Streams now supports 10x larger record sizes: Simplifying real-time data processing | AWS Big Data Blog 」を翻訳したものです。 Amazon Kinesis Data Streams で、レコードサイズの上限が従来の 10 倍となる 10MiB までサポートされるようになりました。この機能強化により、既存の Kinesis Data Streams API をそのまま使用しながら、断続的に発生する大きなデータペイロードをデータストリームに送信できるようになりました。また、 PutRecords リクエストの最大サイズも 5MiB から 10MiB に 2 倍に拡大され、IoT 分析、変更データキャプチャ（CDC）、生成 AI ワークロードにおけるデータパイプラインの簡素化と運用オーバーヘッドの削減が実現します。 この記事では、Amazon Kinesis Data Streams の大規模レコードサポートについて、主なユースケース、最大レコードサイズの設定、スロットリングの考慮事項、最適なパフォーマンスのためのベストプラクティスを解説します。 実際のユースケース データ量の増加とユースケースの進化に伴い、ストリーミングワークロードでより大きなレコードサイズをサポートする需要が高まっています。従来、1MiB を超えるレコードを処理する必要がある場合、以下の 2 つの選択肢がありました。 プロデューサーアプリケーションで大きなレコードを複数の小さなレコードに分割し、コンシューマーアプリケーションで再構成する 大きなレコードを Amazon Simple Storage Service (Amazon S3) に保存し、メタデータのみを Kinesis Data Streams 経由で送信する これらのアプローチは有用ですが、データパイプラインに複雑さを加え、追加のコードが必要となり、運用オーバーヘッドが増加し、特に断続的に大きなレコードをストリーミングする必要がある場合にエラー処理やデバッグが複雑になります。 この機能強化により、さまざまな業界やユースケースで断続的なデータペイロードを扱うお客様の使いやすさが向上し、運用オーバーヘッドが削減されます。IoT 分析の分野では、コネクテッドカーや産業機器が生成するセンサーテレメトリデータの量が増加しており、個々のテレメトリレコードのサイズが従来の Kinesis の 1MiB 制限を超えることがあります。これにより、お客様は大きなレコードを複数の小さなレコードに分割したり、大きなレコードを別途保存してメタデータのみを Kinesis 経由で送信するなど、複雑な回避策を実装する必要がありました。同様に、データベースの変更データキャプチャ（CDC）パイプラインでは、特に一括操作やスキーマ変更時に大きなトランザクションレコードが生成されることがあります。機械学習と生成 AI の分野では、より豊富な特徴セットや音声・画像などのマルチモーダルデータタイプをサポートするために、より大きなペイロードの取り込みが求められるようになっています。Kinesis のレコードサイズ制限が 1MiB から 10MiB に引き上げられたことで、これらの複雑な回避策の必要性が軽減され、IoT、CDC、高度な分析のユースケースにおけるデータパイプラインの簡素化と運用オーバーヘッドの削減が実現します。お客様は、使い慣れた Kinesis API を使用して、これらの断続的な大規模データレコードをより簡単に取り込み、処理できるようになりました。 仕組み より大きなレコードの処理を開始するには： AWS コンソール、AWS CLI、または AWS SDK を使用して、ストリームの最大レコードサイズ制限（ maxRecordSize ）を更新します。 プロデューサーでは引き続き同じ PutRecord および PutRecords API を使用します。 コンシューマーでは引き続き同じ GetRecords または SubscribeToShard API を使用します。 ストリームは数秒間 Updating ステータスになった後、より大きなレコードを取り込む準備が整います。 使用開始 Kinesis Data Streams でより大きなレコードの処理を開始するには、AWS マネジメントコンソール、CLI、または SDK を使用して最大レコードサイズを更新できます。 AWS マネジメントコンソールでの手順： Kinesis Data Streams コンソールに移動します。 ストリームを選択し、 設定 タブを選択します。 最大レコードサイズ の横にある 編集 を選択します。 希望する最大レコードサイズ（最大 10MiB）を設定します。 変更を保存します。 注意： この設定は、この Kinesis データストリームの最大レコードサイズのみを調整します。この制限を引き上げる前に、すべてのダウンストリームアプリケーションがより大きなレコードを処理できることを確認してください。 Kinesis Client Library（バージョン 2.x 以降）、 Amazon Data Firehose から Amazon S3 への配信、 AWS Lambda など、一般的なコンシューマーのほとんどは 1MiB を超えるレコードの処理をサポートしています。詳細については、 大規模レコードに関する Amazon Kinesis Data Streams のドキュメント を参照してください。 AWS CLI を使用してこの設定を更新することもできます： aws kinesis update-max-record-size \ --stream-arn <stream-arn> \ --max-record-size-in-ki-b 5000 または AWS SDK を使用する場合： import boto3 client = boto3.client('kinesis') response = client.update_max_record_size( StreamARN='arn:aws:kinesis:us-west-2:123456789012:stream/my-stream', MaxRecordSizeInKiB=5000 ) スロットリングと最適なパフォーマンスのためのベストプラクティス 大規模レコードのサポートにおいても、個々のシャードのスループット制限（書き込み 1MiB/秒、読み取り 2MiB/秒）は変更されません。大規模レコードを扱うために、スロットリングの仕組みを理解しましょう。ストリーム内の各シャードは 1MiB/秒のスループット容量を持っています。大規模レコードに対応するため、各シャードは一時的に最大 10MiB/秒までバーストし、最終的には平均 1MiB/秒に収束します。この動作を視覚化するために、各シャードが 1MiB/秒で補充される 容量タンク を持っていると考えてください。大きなレコード（例えば 10MiB のレコード）を送信した後、タンクはすぐに補充を開始し、容量が利用可能になるにつれて小さなレコードを送信できるようになります。大規模レコードをサポートするこの容量は、ストリームに継続的に補充されます。補充速度は、大規模レコードのサイズ、ベースラインレコードのサイズ、全体的なトラフィックパターン、選択したパーティションキー戦略によって異なります。大規模レコードを処理する際、各シャードはバースト容量を活用してこれらの大きなペイロードを処理しながら、ベースライントラフィックの処理を継続します。 Kinesis Data Streams が異なる割合の大規模レコードをどのように処理するかを説明するために、簡単なテストの結果を見てみましょう。テスト構成として、オンデマンドストリーム（デフォルトで 4 シャード）に 1 秒あたり 50 レコードの速度でデータを送信するプロデューサーを設定しました。ベースラインレコードは 10KiB、大規模レコードは 2MiB です。大規模レコードの割合を総ストリームトラフィックの 1% から 5% まで段階的に増加させる複数のテストケースと、大規模レコードを含まないベースラインケースを実施しました。一貫したテスト条件を確保するため、大規模レコードを時間的に均等に分散させました。例えば、1% のシナリオでは、100 件のベースラインレコードごとに 1 件の大規模レコードを送信しました。以下のグラフは結果を示しています： グラフでは、水平方向の注釈がスロットリング発生のピークを示しています。青い線で表されるベースラインシナリオでは、スロットリングイベントは最小限です。大規模レコードの割合が 1% から 5% に増加するにつれて、ストリームがデータをスロットリングする頻度が増加し、2% と 5% のシナリオ間でスロットリングイベントが顕著に加速しています。このテストは、Kinesis Data Streams が増加する大規模レコードの割合をどのように管理するかを示しています。 最適なパフォーマンスのために、大規模レコードを総レコード数の 1〜2% に維持することをお勧めします。本番環境では、実際のストリーム動作は、ベースラインレコードのサイズ、大規模レコードのサイズ、大規模レコードがストリームに出現する頻度という 3 つの主要な要因に基づいて異なります。特定の動作を判断するために、実際の需要パターンでテストすることをお勧めします。 オンデマンドストリームでは、シャードあたりの受信トラフィックが 500 KB/秒を超えると、15 分以内にシャードが分割されます。親シャードのハッシュキー値は子シャードに均等に再分配されます。Kinesis はストリームを自動的にスケーリングしてシャード数を増やし、採用されているパーティションキー戦略に応じて大規模レコードをより多くのシャードに分散できるようにします。 大規模レコードで最適なパフォーマンスを得るために： ランダムなパーティションキー戦略を使用して、大規模レコードをシャード間で均等に分散させます。 プロデューサーアプリケーションにバックオフとリトライロジックを実装します。 シャードレベルのメトリクスを監視して、潜在的なボトルネックを特定します。 大規模レコードを継続的にストリーミングする必要がある場合は、Amazon S3 を使用してペイロードを保存し、メタデータ参照のみをストリームに送信することを検討してください。詳細については、 Amazon Kinesis Data Streams での大規模レコードの処理 を参照してください。 まとめ Amazon Kinesis Data Streams で、レコードサイズの上限が従来の 1MiB から 10 倍の 10MiB までサポートされるようになりました。この機能強化により、複雑な回避策が不要になり、IoT 分析、変更データキャプチャ、AI/ML ワークロードのデータパイプラインが簡素化されます。既存の Kinesis Data Streams API をコード変更なしでそのまま使用でき、断続的な大規模ペイロードの処理における柔軟性が向上します。 最適なパフォーマンスのために、大規模レコードを総レコード数の 1〜2% に維持することをお勧めします。 大規模レコードで最良の結果を得るには、均等に分散されたパーティションキー戦略を実装してレコードをシャード間で均等に分散させ、プロデューサーアプリケーションにバックオフとリトライロジックを含め、シャードレベルのメトリクスを監視して潜在的なボトルネックを特定してください。 最大レコードサイズを引き上げる前に、すべてのダウンストリームアプリケーションとコンシューマーがより大きなレコードを処理できることを確認してください。 この機能を活用して、より強力で効率的なストリーミングアプリケーションを構築されることを楽しみにしています。詳細については、 Amazon Kinesis Data Streams のドキュメント をご覧ください。 著者について Sumant Nemmani は Amazon Kinesis Data Streams のプロダクトマネージャーです。お客様から学ぶことに情熱を持ち、AWS で価値を引き出すお手伝いをすることを楽しんでいます。仕事以外では、バンド Project Mishram で音楽を作ったり、旅行中に歴史や食べ物を探索したり、テクノロジーや歴史に関する長編ポッドキャストを聴いたりしています。 Umesh Chaudhari は AWS のシニアストリーミングソリューションアーキテクトです。お客様と協力してリアルタイムデータ処理システムの設計と構築を行っています。データ分析システムのアーキテクチャ設計、設計、開発を含むソフトウェアエンジニアリングの豊富な経験を持っています。仕事以外では、旅行やテクノロジートレンドのフォローを楽しんでいます。 Pratik Patel はシニアテクニカルアカウントマネージャーであり、ストリーミング分析のスペシャリストです。AWS のお客様と協力し、ベストプラクティスを使用したソリューションの計画と構築を支援する継続的なサポートと技術ガイダンスを提供し、お客様の AWS 環境を運用上健全に保つことに積極的に取り組んでいます。 この記事は Kiro が翻訳を担当し、ソリューションアーキテクト の 榎本 貴之 がレビューしました。

本記事は 2025年11月10日 に公開された「 Amazon MSK Express brokers now support Intelligent Rebalancing for 180 times faster operation performance | AWS Big Data Blog 」を翻訳したものです。 本日より、 Amazon Managed Streaming for Apache Kafka (Amazon MSK) Provisioned クラスターで Express ブローカー を使用するすべての新規クラスターで、追加料金なしで Intelligent Rebalancing がサポートされます。この新機能により、Apache Kafka クラスターのスケールアップまたはスケールダウン時に自動的なパーティションバランシング操作を実行できます。Intelligent Rebalancing は、Express ブローカーを使用する Amazon MSK クラスターの Kafka リソースを最適にリバランスすることで、キャパシティ使用率を最大化し、パフォーマンスを向上させます。これにより、パーティションを個別に管理したり、サードパーティツールを使用したりする必要がなくなります。Amazon MSK Express ブローカーの Intelligent Rebalancing は、Standard ブローカーと比較して最大 180 倍高速にこれらの操作を実行します。 Amazon MSK Express ブローカーは、使いやすさ、クラス最高の価格性能比、予測可能な可用性を実現するために Apache Kafka を再設計し、 2024年11月 にリリースしました。Amazon MSK Express ブローカーは、Apache Kafka を実行する Standard ブローカーと比較して、ブローカーあたり最大 3 倍のスループットを提供し、最大 20 倍高速にスケールし、復旧時間を 90% 短縮するように設計されています。リリース以降、Amazon MSK Express ブローカーを 追加の AWS リージョン やインスタンスタイプに拡大し、最近では Express ブローカーあたりのパーティション数を 5 倍に増加 し、パーティションに制約されるワークロードの価格性能比を最大 50% 向上させました。 Intelligent Rebalancing により、Amazon MSK Express ブローカークラスターは、クラスターパフォーマンスを最大化するためのインテリジェントな Amazon MSK のデフォルト設定に基づいて、リソースの不均衡や過負荷を継続的に監視されます。必要に応じて、クライアントがデータを生成および消費するためのクラスターの可用性に影響を与えることなく、ブローカーが効率的にスケールされます。お客様は、クラスター管理操作を簡素化しながら、Express ブローカー向け Amazon MSK Provisioned クラスターのスケーリングとパフォーマンスのメリットを最大限に活用できるようになりました。 この記事では、Intelligent Rebalancing 機能を紹介し、操作パフォーマンスを向上させる仕組みの例を示します。 Intelligent Rebalancing を使用するタイミング Intelligent Rebalancing により、Amazon MSK Express ブローカーは、追加のツールや設定を必要とせずに、Kafka クラスターを管理およびスケールするための完全に自動化されたソリューションを提供するようになりました。Intelligent Rebalancing は、すべての新しい Amazon MSK Express ブローカークラスターでデフォルトで有効になっているため、常に有効にしておくことをお勧めします。Intelligent Rebalancing は、Amazon MSK のベストプラクティスを使用して、以下の状況で自動リバランシングをトリガーします。 クラスターのスケールインとスケールアウト : お客様が Amazon MSK Express ブローカークラスターにブローカーを 追加 または 削除 すると、Intelligent Rebalancing は自動的にパーティションを再分散し、ブローカー間でリソース使用率のバランスを取ります。これにより、クラスターは最高のパフォーマンスで動作し続け、単一の更新操作でスケールインとスケールアウトが可能になります。 定常状態のリバランシング : 通常の運用中でも、Intelligent Rebalancing は Amazon MSK Express ブローカークラスターを継続的に監視し、リソースの不均衡やホットスポットを検出するとリバランシングをトリガーします。たとえば、パーティションの不均等な分散や偏ったトラフィックパターンにより特定のブローカーが過負荷になった場合、Intelligent Rebalancing は自動的にパーティションを使用率の低いブローカーに移動してバランスを回復します。 Intelligent Rebalancing の使用方法 Intelligent Rebalancing の威力を示すために、Amazon MSK Express ブローカークラスターでいくつかのテストを実行してみましょう。 スケーリングテスト : まず、3 つのブローカーを持つ Amazon MSK Express ブローカークラスターを作成します。次に、ワークロードの急激な増加をシミュレートするために、クラスターを 6 つのブローカーに急速にスケールアップし、その後 3 つのブローカーに戻します。 Intelligent Rebalancing が有効になっていると、パーティションのリバランシングが 5〜10 分以内に完了し、クラスターがパフォーマンスを低下させることなく増加したスループットを維持できることがわかります。 RebalanceInProgress メトリクスを使用して、現在および過去のリバランシング操作を追跡できます。下の画像では、このリバランシング中にプロデューサー側のクライアントが影響を受けていないことも確認できます。 次に、トラフィックの大部分を単一のブローカーに向けることで、クラスターに不均衡を作成します。Intelligent Rebalancing がこの不均衡を数分以内に検出し、自動的にパーティションを再分散して、クラスターを最適な状態に復元することがわかります。 Intelligent Rebalancing 機能はホットスポットを検出し、影響を受けたパーティションを他のブローカーに自動的に再分散して、リソース使用率を最適化します。Intelligent Rebalancing がなければ、リソースの不均衡は持続し、パフォーマンスの問題やお客様による手動介入の必要性につながる可能性があります。 これらのテストは、Amazon MSK Express ブローカーの Intelligent Rebalancing により、さまざまなワークロード条件下でも一貫して高いパフォーマンスを維持しながら、Kafka クラスターをシームレスにスケールできることを示しています。 まとめ Express ブローカーを使用する Amazon MSK Provisioned クラスター向けの Intelligent Rebalancing は、今後数週間にわたって Amazon MSK Express ブローカーがサポートされているすべての AWS リージョン で展開されています。この機能は、Express ブローカーを使用するすべての新しい Amazon MSK Provisioned クラスターで追加料金なしで自動的に有効になります。 開始するには、Amazon MSK コンソールにアクセスしてください。詳細については、 Amazon MSK デベロッパーガイド を参照してください。 著者について Swapna Bandla は、AWS のシニアストリーミングソリューションアーキテクトです。リアルタイムデータ処理と分析に関する深い理解を持ち、AWS Well-Architected のベストプラクティスに沿ったスケーラブルでクラウドネイティブなソリューションの設計においてお客様をサポートしています。Swapna は、組織がデータの可能性を最大限に引き出してビジネス価値を創出することを支援することに情熱を注いでいます。仕事以外では、家族との時間を大切にしています。 Masudur Rahaman Sayem は、AWS のストリーミングデータアーキテクトで、IT 業界で 25 年以上の経験があります。世界中の AWS のお客様と協力して、複雑なビジネス課題に対応する高度なデータストリーミングソリューションを設計・実装しています。分散アーキテクチャに強い関心と情熱を持ち、インターネット規模のエンタープライズグレードソリューションの設計に活かしています。 Shakhi Hali は、AWS の Amazon Managed Streaming for Apache Kafka (Amazon MSK) のプリンシパルプロダクトマネージャーです。お客様がリアルタイムデータからビジネス価値を生み出すことを支援することに情熱を注いでいます。MSK に参加する前は、Amazon S3 のプロダクトマネージャーでした。余暇には、旅行、料理、家族との時間を楽しんでいます。 この記事は Kiro が翻訳を担当し、ソリューションアーキテクト の 榎本 貴之 がレビューしました。

2025 年の 5 月、.NET アプリケーションを大規模にモダナイズするための初のエージェント型 AI サービスである AWS Transform for .NET の一般提供開始を発表しました。サービスの早期導入期間中に、貴重なフィードバックをいただきました。その中で、.NET アプリケーションのモダナイズに加えて、SQL Server や従来の UI フレームワークもモダナイズしたいというご要望があることがわかりました。お客様のアプリケーションは通常、プレゼンテーション層、アプリケーション層、データベース層の三層アーキテクチャに従っており、これらすべての層を統合的に変換できる包括的なソリューションが求められています。 2025 年 12 月 1 日、皆様からのフィードバックをもとに、Windows アプリケーションスタック全体の複雑で煩雑なモダナイズ作業を軽減する AWS Transform for フルスタック Windows モダナイズ を発表できたことを嬉しく思います。これにより、アプリケーションやデータベースの依存関係を特定し、集中管理された環境を通じて統合的にモダナイゼーションを行えるようになりました。 AWS Transform は、アプリケーション、UI、データベース、デプロイメント層におけるフルスタック Windows モダナイゼーションを最大で 5 倍高速化します。.NET Framework アプリケーションをクロスプラットフォーム対応の .NET に移行するだけでなく、SQL Server データベースを Amazon Aurora PostgreSQL-Compatible Edition に移行し、インテリジェントなストアドプロシージャの変換や依存するアプリケーションコードのリファクタリングも行います。検証およびテストのために、AWS Transform はアプリケーションを Amazon Elastic Compute Cloud (Amazon EC2) の Linux 環境や Amazon Elastic Container Service (Amazon ECS) にデプロイし、運用環境での利用に向けてカスタマイズ可能な AWS CloudFormation テンプレートやデプロイ設定を提供します。AWS Transform には、ASP.NET Web Forms の UI を Blazor にモダナイズする機能も追加されています。 まだまだ紹介する内容は多いため、本投稿では、フルスタック Windows モダナイゼーションにおける AWS Transform の各層の機能を初めてご紹介します。 フルスタック Windows モダナイゼーションの変換ジョブを作成する AWS Transform は、ソースコードリポジトリやデータベースサーバーに接続し、アプリケーションおよびデータベースの依存関係を分析した上で、モダナイゼーションのウェーブを作成し、各ウェーブごとにフルスタック変換をオーケストレーションします。 AWS Transform を始めるには、まず AWS Transform 入門ユーザーガイド に記載されているオンボーディング手順を完了します。オンボーディングが完了したら、自分の認証情報を使って AWS Transform コンソールにサインインし、フルスタック Windows モダナイゼーション用のジョブを作成します。 ジョブを作成した後、 事前準備 を完了します。次に、 AWS Transform が Amazon EC2 および Amazon Relational Database Service (Amazon RDS) 上で稼働する SQL Server データベースに安全にアクセスできるよう、データベースコネクタを設定します。このコネクタは、同じ SQL Server インスタンス内の複数のデータベースに接続できます。 次に、 ソースコードリポジトリに接続する ためのコネクタを設定します。 さらに、変換後のアプリケーションを AWS Transform にデプロイさせるかどうかを選択することもできます。 はい を選択し、アプリケーションをデプロイするためのターゲット AWS アカウント ID と AWS リージョンを指定します。デプロイのオプションは後から設定することも可能です。 コネクタの設定が完了すると、AWS Transform はリソースに接続し、IAM ロール、ネットワーク設定、および関連する AWS リソースを検証して確認します。 検証が正常に完了すると、AWS Transform はデータベースとそれに関連するソースコードリポジトリを検出します。関連コンポーネントをまとめて変換するために、データベースとアプリケーション間の依存関係を特定し、ウェーブを作成します。この分析に基づき、AWS Transform はウェーブ方式の変換プランを作成します。 データベースおよび依存するアプリケーションを評価する 評価のために、AWS Transform が検出したデータベースとソースコードリポジトリを確認し、コードリポジトリに適切なブランチを選択します。AWS Transform はこれらのデータベースとソースコードリポジトリをスキャンし、各データベースとそれに依存する .NET アプリケーション、さらに変換の複雑性のリストを提示します。 モダナイゼーションの対象となるデータベースとリポジトリを選択します。AWS Transform はこれらの選択内容を分析し、詳細なウェーブプランを含む包括的な SQL モダナイゼーション評価レポート を生成します。提案されたモダナイゼーションプランを確認するために、レポートをダウンロードします。レポートには、エグゼクティブサマリー、ウェーブプラン、データベースとコードリポジトリ間の依存関係、そして複雑性分析が含まれています。 大規模なウェーブ変換 AWS Transform が生成するウェーブプランは、各ウェーブごとに 4 つのステップで構成されています。最初のステップでは、SQL Server のスキーマを PostgreSQL に変換します。次に、データを移行します。3 つ目のステップでは、依存する .NET アプリケーションコードを PostgreSQL に対応するよう変換します。最後に、アプリケーションをテスト用にデプロイします。 SQL Server のスキーマを変換する前に、新しい PostgreSQL データベースを作成するか、既存のデータベースをターゲットとして選択できます。 ソースデータベースとターゲットデータベースを選択すると、AWS Transform はレビュー用の変換レポートを生成します。AWS Transform は、テーブル、インデックス、制約、ストアドプロシージャを含む SQL Server スキーマを PostgreSQL 互換の構造に変換します。 AWS Transform が自動で変換できないスキーマについては、 AWS Database Migration Service (AWS DMS) コンソールで手動で対応できます。あるいは、お好みの SQL エディタで修正し、ターゲットデータベースインスタンスを更新することもできます。 スキーマ変換が完了した後、データ移行を進めるかどうかを選択できます。このステップは任意です。AWS Transform は、SQL Server インスタンスから PostgreSQL データベースインスタンスへのデータ移行に AWS DMS を使用します。データ移行は、すべての変換作業完了後に実施することも、テストデータをターゲットデータベースにロードして作業することも可能です。 次のステップはコード変換です。AWS Transform が変換後のコードアーティファクトをアップロードするターゲットブランチを指定します。AWS Transform は、変換後の PostgreSQL データベースに対応するようにコードベースを更新します。 今回のリリースでは、フルスタック Windows モダナイゼーション向けの AWS Transform は、.NET 6 以降のコードベースのみをサポートしています。.NET Framework 3.1 以降のコードベースについては、まず AWS Transform for .NET を使用してクロスプラットフォーム対応の .NET に移行します。この点については、次のセクションで詳しく説明します。 変換が完了すると、ソースブランチとターゲットブランチ、およびそれぞれのコード変換ステータスを確認できます。変換レポートをダウンロードして確認することもできます。 UI 層を含む .NET Framework アプリケーションのモダナイゼーション 2025 年 12 月 1 日リリースする主な機能の一つは、UI フレームワークを ASP.NET Web Forms から Blazor にモダナイズする機能です。これは、既存のモデル・ビュー・コントローラー（MVC）Razor ビューを ASP.NET Core Razor ビューにモダナイズするサポートに追加された機能です。 前述の通り、レガシー .NET Framework のアプリケーションがある場合は、引き続き AWS Transform for .NET を使用してクロスプラットフォーム対応の .NET に移行します。ASP.NET Web Forms 上で構築されたレガシーアプリケーションについて、AWS Transform はバックエンドコードの移行に加え、UI 層を Blazor にモダナイズします。 AWS Transform for .NET は、ASP.NET Web Forms プロジェクトを ASP.NET Core 上の Blazor に変換し、ASP.NET Web サイトの Linux への移行を容易にします。AWS Transform for .NET では、AWS Transform Web コンソールと Visual Studio 拡張機能の両方で、UI 近代化機能がデフォルトで有効になっています。 近代化プロセスにおいて、AWS Transform は ASPX ページ、ASCX カスタムコントロール、およびコードビハインドファイルの変換を処理し、これらを Web アセンブリではなくサーバーサイド Blazor コンポーネントとして実装します。変換の過程で、次のプロジェクトおよびファイルの変更が行われます: から へ 説明 *.aspx、*.ascx *.razor .aspx ページと .ascx カスタムコントロールは .razor ファイルになります Web.config appsettings.json Web.config の設定は appsettings.json の設定になります Global.asax Program.cs Global.asax のコードは Program.cs のコードになります *.master *layout.razor マスターファイルは layout.razor ファイルになります AWS Transform for .NET のその他の新機能 UI の移植に加えて、AWS Transform for .NET は、より多くの変換機能のサポートと開発者体験の向上を追加しました。これらの新機能には、以下が含まれます： .NET 10 および .NET Standard への移行 – AWS Transform は、2025 年 11 月 11 日にリリースされた最新の長期サポート（LTS）版である .NET 10 への移行をサポートする ようになりました。また、すべての .NET 実装で共通する API 群の正式な仕様である .NET Standard へのクラスライブラリの移植もサポートします。さらに、AWS Transform は現在、Visual Studio 2026 向けの AWS Toolkit で利用可能です。 編集可能な変換レポート – 評価が完了した後、特定の要件や好みに応じて変換プランを表示およびカスタマイズできるようになりました。たとえば、パッケージの置き換えの詳細を更新することができます。 リアルタイムの変換更新と推定残り時間 – コードベースの規模や複雑さに応じて、AWS Transform が移行を完了するまでに時間がかかる場合があります。変換の進行状況と推定残り時間をリアルタイムで追跡できるようになりました。 次のステップのマークダウン — 変換が完了した後、AWS Transform は移行を完了するための残りのタスクを記載した次のステップ用のマークダウンファイルを生成するようになりました。これを改訂プランとして使用し、AWS Transform で変換を再実行したり、AI コードコンパニオンを使って移行を完了したりすることができます。 知っておくべきこと その他に知っておくべきことは以下の通りです： AWS リージョン – フルスタック Windows モダナイゼーション向けの AWS Transform は、現在、米国東部（バージニア北部） リージョン で一般提供されています。リージョンごとの提供状況や今後のロードマップについては、 AWS Capabilities by Region をご覧ください。 料金 – 現在、AWS Transform の Windows モダナイゼーション機能には 追加料金はかかりません 。AWS Transform の出力を使用して AWS アカウントで作成または引き続き使用するリソースは、それぞれの標準料金に従って課金されます。制限やクォータについては、 AWS Transform ユーザーガイド を参照してください。 サポートされる SQL Server バージョン – AWS Transform は、SQL Server 2008 R2 から 2022 までのすべてのエディション（Express、Standard、Enterprise）への変換をサポートしています。SQL Server は、AWS Transform と同じリージョンの Amazon RDS または Amazon EC2 上でホストされている必要があります。 サポートされる Entity Framework バージョン – AWS Transform は、Entity Framework 6.3 から 6.5 および Entity Framework Core 1.0 から 8.0 のモダナイゼーションをサポートしています。 はじめに – はじめるには、AWS Transform for フルスタック Windows モダナイゼーション ユーザーガイド をご覧ください。 – Prasad 原文は こちら です。

2025 年 11 月 30 日、 AWS Lambda マネージドインスタンスを発表しました。これは、サーバーレスの運用の簡単さを維持しながら、 Amazon Elastic Compute Cloud（Amazon EC2) 上で AWS Lambda 関数を実行できる新機能です。この強化機能は、重要な顧客ニーズに対応しています。すなわち、サーバーレス開発体験を損なうことなく、特殊なコンピューティングオプションにアクセスし、定常ワークロードのコストを最適化できるようにするものです。 Lambda はインフラ管理を不要にしますが、一部のワークロードでは特定の CPU アーキテクチャなどの特殊なハードウェアや、Amazon EC2 の購入契約によるコスト最適化が必要となる場合があります。このジレンマにより、多くのチームは必要なコンピュートオプションや料金モデルにアクセスするためだけにインフラ管理を自ら行い、Lambda のサーバーレスの利点を犠牲にせざるを得なくなっています。これにより、多くの場合、アーキテクチャの大幅な変更や運用責任の増大につながります。 Lambda マネージドインスタンス Lambda マネージドインスタンスを使用すると、Lambda 関数を EC2 インスタンス上でどのように実行するかを定義できます。 Amazon Web Services（AWS） が、アカウント内のこれらのインスタンスのセットアップと管理を行います。最新世代の Amazon EC2 インスタンスにアクセスでき、AWS がインスタンスのライフサイクル管理、OS パッチ適用、ロードバランシング、オートスケーリングなど、すべての運用の複雑さを管理します。これにより、データ集約型アプリケーション向けの高帯域幅ネットワークなど、特定のワークロード要件に最適化されたコンピュートプロファイルを選択でき、Amazon EC2 インフラの管理という運用負荷を負う必要がありません。 各実行環境は、一度に 1 つのリクエストだけでなく、複数のリクエストを処理できます。これにより、各呼び出しごとに別々の実行環境を立ち上げるのではなく、コードが複数の同時リクエストでリソースを効率的に共有できるため、コンピュート消費を大幅に削減できます。Lambda マネージドインスタンスでは、 Compute Savings Plans や リザーブドインスタンス などの Amazon EC2 コミットメントベースの料金モデルを利用でき、 Amazon EC2 オンデマンド料金 より最大 72 % 割引を受けられます。これは、従来の Lambda プログラミングモデルを維持しながら、安定したワークロードに対して大幅なコスト削減を提供します。 試してみましょう Lambda マネージドインスタンスを試すには、 まずキャパシティプロバイダーを作成する必要があります 。次の画像に示すように、ナビゲーションペインの その他のリソース の下にこれらを作成するための新しいタブがあります。 キャパシティプロバイダーを作成するには、 仮想プライベートクラウド (VPC) 、サブネット設定、およびセキュリティグループを指定します。キャパシティプロバイダーの設定を使うことで、Lambda に対してインスタンスをどこにプロビジョニングして管理するかを指定することもできます。 含めたい、または除外したい EC2 インスタンスタイプを指定することもできますし、高い多様性を確保するためにすべてのインスタンスタイプを含めることも選択できます。さらに、最大 vCPU 数やオートスケーリングの利用可否、CPU ポリシーの使用など、オートスケーリングに関連するいくつかの制御項目を指定することもできます。 キャパシティプロバイダーの設定が完了したら、新しい Lambda 関数を作成する際に、その Amazon リソースネーム (ARN) を使って選択できます。ここでは、希望するメモリ割り当てとメモリ対 vCPU の比率も選択できます。 Lambda マネージドインスタンスでの作業 基本設定を確認したので、Lambda マネージドインスタンスの仕組みをさらに詳しく見ていきましょう。この機能では、EC2 インスタンスを Lambda コンソール 、 AWS コマンドラインインターフェイス (AWS CLI) 、または AWS CloudFormation 、 AWS サーバーレスアプリケーションモデル (AWS SAM) 、 AWS Cloud Development Kit (AWS CDK) 、 Terraform などのコードとしての Infrastructure as Code (IaC) ツールを使用して設定したキャパシティプロバイダーに編成します。各キャパシティプロバイダーは、インスタンスタイプ、ネットワーク構成、スケーリングパラメータなど、必要なコンピューティング特性を定義します。 キャパシティプロバイダーを作成する際には、ワークロードの要件に合わせて最新世代の EC2 インスタンスから選択できます。コスト最適化された汎用コンピューティングには、優れた価格性能を発揮する AWS Graviton4 ベースのインスタンスを選択できます。どのインスタンスタイプを選ぶか迷った場合、AWS Lambda は関数の設定に基づき、パフォーマンスとコストのバランスが取れた最適化済みのデフォルトを提供します。 キャパシティプロバイダーを作成した後は、簡単な設定変更を通じて Lambda 関数をそれに紐付けることができます。関数を紐付ける前に、マルチコンカレンシー環境で問題を引き起こす可能性のあるプログラミングパターンについてコードを確認する必要があります。例えば、リクエストごとに一意でないファイルパスへの読み書きや、呼び出し間で共有されるメモリ空間や変数の使用などです。 Lambda はリクエストをインスタンス上の事前プロビジョニング済み実行環境に自動的にルーティングするため、初回リクエストのレイテンシに影響するコールドスタートを排除します。各実行環境はマルチコンカレンシー機能を通じて複数の同時リクエストを処理できるため、関数全体でのリソース利用率を最大化できます。トラフィック増加時に追加のキャパシティが必要になると、AWS は数十秒以内に新しいインスタンスを自動的に起動し、キャパシティプロバイダーに追加します。キャパシティプロバイダーはデフォルトで最大 50% のトラフィックスパイクをスケーリングなしで吸収できますが、組み込みのサーキットブレーカーが極端なトラフィック急増時にコンピューティングリソースを保護します。キャパシティプロバイダーが最大プロビジョニング容量に達し、追加キャパシティがまだ立ち上げ中の場合、リクエストを一時的に 429 ステータスコードで制限します。 このプロセス全体を通じて、運用およびアーキテクチャのモデルはサーバーレスのままです。AWS は、インスタンスのプロビジョニング、OS パッチ適用、セキュリティ更新、インスタンス間のロードバランシング、需要に応じた自動スケーリングを管理します。AWS は、オペレーティングシステムおよびランタイムコンポーネントに対してセキュリティパッチやバグ修正を自動的に適用し、稼働中のアプリケーションに影響を与えることはほとんどありません。さらに、インスタンスの最大稼働期間は 14 日に設定されており、業界のセキュリティおよびコンプライアンス基準に準拠しています。オートスケーリングポリシーの作成、ロードバランサーの設定、インスタンスのライフサイクル管理は自分で行う必要はなく、関数コード、イベントソースの統合、 AWS Identity and Access Management (AWS IAM) 権限、 Amazon CloudWatch での監視はそのまま維持されます。 今すぐご利用いただけます Lambda マネージドインスタンスは、Lambda コンソール、AWS CLI、または AWS SDK を通じて、2025 年 11 月 30 日から利用を開始できます。この機能は、米国東部（バージニア北部）、米国東部（オハイオ）、米国西部（オレゴン）、アジアパシフィック（東京）、および欧州（アイルランド）リージョンで利用可能です。リージョンごとの提供状況や今後のロードマップについては、 AWS Capabilities by Region をご覧ください。詳細は、 AWS Lambda ドキュメント をご覧ください。 Lambda マネージドインスタンスの料金は、3 つの要素で構成されています。まず、通常の Lambda リクエスト料金として、100 万回の呼び出しごとに 0.20 米ドルを支払います。次に、プロビジョニングされたコンピューティング容量に対して、通常の Amazon EC2 インスタンス料金が課金されます。Compute Savings Plans やリザーブドインスタンスを含む既存の Amazon EC2 料金契約をこれらのインスタンス料金に適用することで、安定稼働するワークロードのコストを削減できます。最後に、インスタンスの運用管理を AWS が行う費用として、EC2 オンデマンドインスタンス料金を基に計算される 15% のコンピューティング管理手数料が課金されます。従来の Lambda 関数とは異なり、リクエストごとの実行時間に対して個別に課金されることはありません。マルチコンカレンシー機能は、リクエスト処理に必要な合計コンピューティング時間を削減することで、さらにコストを最適化するのに役立ちます。 初期リリースでは、最新バージョンの Node.js、Java、.NET、Python ランタイムがサポートされており、今後他の言語も対応予定です。この機能は、関数のバージョニング、エイリアス、 AWS Cloud Watch Lambda Insights 、 AWS AppConfig エクステンション、AWS SAM や AWS CDK などのデプロイツールを含む既存の Lambda ワークフローと統合されます。既存の Lambda 関数は、関数コードを変更せずに Lambda マネージドインスタンスに移行できます（マルチコンカレンシー対応のスレッドセーフであることが確認されている場合）。これにより、専用コンピューティングやコスト最適化の恩恵を受けるワークロードでも、この機能を簡単に導入できます。 Lambda マネージドインスタンスは、Lambda の機能を大幅に拡張するものであり、サーバーレスの運用モデルを維持しながら、より幅広いワークロードを実行できます。高トラフィックアプリケーションのコスト最適化や、Graviton4 など最新プロセッサアーキテクチャへのアクセスなど、いずれの場合でも、この新機能は運用の複雑さを増すことなく必要な柔軟性を提供します。Lambda マネージドインスタンスで皆さんがどのようなものを構築するのか、とても楽しみにしています。 原文は こちら です。

はじめに このブログシリーズの Part 1 では、SAP Content Serverを使用しているお客様が、Amazon S3をドキュメントストアとして活用して、コスト効率が高く、堅牢でスケーラブルなドキュメント管理ソリューションを構築する方法を探求しました。このブログシリーズの第2部では、高可用性(HA)を実装することで、お客様がAmazon S3上の SAP Content Server の信頼性を向上させる方法を共有します。 SAP Content Serverにおける高可用性が重要な理由 Uptime Instituteの「2025 Annual Outage Analysis Report」 によると、組織の54%が最近の重大な障害で10万ドル以上のコストが発生したと報告しており、20%は1インシデントあたり100万ドルを超えるコストを経験しています。この中断は組織全体に波及し、注文処理、カスタマーサービス業務、コンプライアンス要件に影響を与えます。ミッションクリティカルなSAPワークロードを実行している組織にとって、SAP Content Serverはドキュメント管理業務のバックボーンを形成します。 ビジネスプロセスが購買発注書、請求書、契約書、規制文書への即座のアクセスに依存している場合、SAP Content Serverへの中断はビジネス運営に影響を与える可能性があります。したがって、SAP Content Serverが高可用性で構成され、潜在的なハードウェア、ソフトウェア、またはネットワーク障害にもかかわらず運用可能でアクセス可能な状態を維持することが非常に重要です。 提案アーキテクチャ このブログシリーズの Part 1 では、SAP Content Serverに保存されたコンテンツのファイルシステムとして Amazon S3 File Gateway を設定する方法を説明しました。コンテンツリポジトリを作成し、SAP ERPがコンテンツリポジトリにアクセスできるように構成しました。さらに、SAP MaxDBからAmazon S3へのコンテンツ移行のステップバイステップガイドを提供しました。 S3 File Gatewayサービスには 99.9%の可用性SLA があり、これは月間最大 43分 の計画外ダウンタイムに相当します。この提案されたHAソリューションは、組織がこの可用性SLAを必要とする場合にのみ必要です。このHAソリューションを使用できる3つの異なるシナリオを、以下の図1、2、3に示します。 図1: RISE with SAP on AWSに接続された高可用性SAP Content Server 図2: オンプレミスSAP ERPサーバーに接続されたAWS上の高可用性SAP Content Server 図3: AWSネイティブSAP ERPサーバーを使用した高可用性SAP Content Server 提案ソリューション 図1では、ソリューションアーキテクチャは、RISE with SAPがNetwork Load Balancer (NLB)を介してSAP Content Serverを通じてS3 File Gatewayに接続するHA設計を実装しています。NLBは、SAP Content Serverからプライマリ S3 File Gatewayインスタンスへのリクエストを効率的にルーティングし、S3バケットに接続されたローカルファイル共有を通じてドキュメントにアクセスします。このアーキテクチャは、S3 File Gatewayエンドポイント用のDomain Name Service (DNS)名を持つNLBを活用し、シームレスなフェイルオーバー機能を確保します。フェイルオーバーが発生すると、NLBは自動的にセカンダリアベイラビリティゾーン(AZ)のアクティブなS3 File Gatewayにトラフィックをリダイレクトし、業務の中断なくビジネスドキュメントへの継続的なアクセスを維持します。 以下は、2つの別々のS3 File Gatewayをインストールおよび構成し、同一のファイル共有を作成し、 Git 上のカスタムpacemakerリソーススクリプトを通じて高可用性を確保するためのステップバイステップガイドです。 カスタムリソースは、NLBターゲットグループ内のS3 File Gatewayファイル共有を管理するためのpacemakerリソースエージェントを実装します。これは、異なるAZ間のインスタンス間で自動的にフェイルオーバーすることにより、S3 File Gatewayの高可用性を提供するように設計されています。このアーキテクチャは、 Overlay IPアドレス を使用する代わりに、NLBのネイティブターゲットグループ機能を活用して、2つのAZ間でS3 File Gatewayインスタンスに直接トラフィックをリダイレクトします。 ステップ1: 2つのS3 File Gatewayをインストールおよび構成 異なるAZに 2つの別々のS3 File Gatewayをインストールおよび構成 することから始めます。このセットアップにより、冗長性が確保され、データアクセシビリティが向上します。両方のゲートウェイがS3バケットにマッピングされていることを確認してください。 図4: 2つのS3 File Gatewayの構成 ステップ2: 同一のファイル共有を作成 次に、同じS3バケットを指す 同一のファイル共有を作成 します。このプロセスにより、両方のAmazon S3 File Gatewayが同じデータにシームレスにアクセスできるようになります。これらのファイル共有の権限が、アプリケーションからのアクセスを許可するように正しく設定されていることを確認してください。 図5: S3 File Gatewayをファイル共有に向ける SAP Content Serverへのエントリポイントとして NLB が必要です。NLBの構成を以下に示します。 図6: NLBの作成 図7: NLBターゲットグループの作成 NLBと関連するターゲットグループの作成については、この ドキュメント を参照してください。 ステップ3: NLB DNS名を使用してNFS共有をマウント NLB DNS名を使用してSAP Content ServerにNFS共有をマウント します。このアプローチにより、クライアントに単一のアクセスポイントが提供され、接続が簡素化され、フォールトトレランスが向上します。NLBが両方のS3 File Gatewayにリクエストを転送するように構成されていることを確認してください。 図8: SAP Content Server内のAmazon S3 File Gatewayマウントポイント ステップ4: 高可用性クラスターフレームワークソフトウェア( SLES / RedHat )を構成 この Git に従ってpacemakerクラスターを構成します。クラスターが正常に構成されたら、「pcs status」を介してクラスターステータスを確認します: 図9: SAP Content Server HAクラスターステータスの確認 ステップ5: EC2 Auto Recoveryを有効化 最後に、インスタンスの EC2 Auto Recoveryを有効化 します(新しく作成されたEC2インスタンスではデフォルトで有効になっていることに注意してください)。この機能は、システム障害が検出されたときにインスタンスを自動的に回復し、ノードがそれぞれのAZで利用可能な状態を維持します。Amazon CloudWatchアラームを構成して、インスタンスのヘルスを監視し、必要に応じて回復アクションをトリガーします。 これらの手順に従うことで、高可用性プラクティスを活用した回復力のあるストレージソリューションを確立し、異なるAZ間で重要なデータへの継続的なアクセスを確保できます。 ステップ6: テスト フェイルオーバー前: トランザクションME22N(購買発注変更)を例として、PDFドキュメントを添付できます。 図10: ME22NによるPDF添付 図11: S3にアップロードされたPDFドキュメント SAP Content Serverのセカンダリノードへのフェイルオーバーは、いくつかの方法でトリガーできます。 AWS Fault Injection Simulator (FIS)は、AWSワークロードで制御された障害注入実験を実行することにより高可用性(HA)テストを自動化する完全マネージド型サービスを提供し、実際の障害が発生する前にアプリケーションの回復力を検証し、災害復旧手順の弱点を特定できます。システム管理者は、現在のアクティブノードで「pcs node standby」や「pcs resource move」などのpacemakerクラスターコマンドを使用してプロセスを開始できます。 あるいは、現在のSAP Content Serverノードで/usr/sapマウントのI/Oを無効にする(例: 「umount」経由)などの障害条件を導入することで、フェイルオーバーを手動で調整またはシミュレートできます。フェイルオーバー中、両方のS3 File Gatewayインスタンスは動作し続けますが、NLBターゲットグループの登録が変更され、セカンダリFile Gatewayインスタンスにトラフィックが向けられます。このアーキテクチャは、NLBが新しくアクティブになったS3 File Gatewayインスタンスにトラフィックをリダイレクトするため、ビジネス運営の中断なくドキュメント管理システムへの継続的なアクセスを維持しながら、シームレスな移行を保証します。 図12: 中断検出後、クラスターステータスはプライマリノードが停止していることを示しています クラスターリソースはセカンダリノードで起動しています: 図13: プライマリノードが停止した後、セカンダリノードがクラスターによって起動されています Content ServerがS3 File Gatewayと共にセカンダリノードで正常にフェイルオーバーすると、図14のように表示されます。 図14: セカンダリノードが正常に起動したことを示すクラスターステータス 以前のプライマリホストでは、S3 File Gatewayがマウントされなくなっていることがわかります。 図15: 以前のプライマリノードでS3 File Gatewayマウントポイントがマウントされなくなりました 新しいプライマリホスト(セカンダリノード)では、S3 File Gatewayがマウントされていることがわかります。 図16: 新しいプライマリノードにマウントされたS3 File Gatewayマウントポイント 最後に、フェイルオーバー後にトランザクションME22Nを介してSAP購買発注添付ファイルの確認を繰り返し、失われていないこと、およびSAP ERPから引き続きアクセスできることを確認します。 図17: フェイルオーバー後のME22NでのPDF添付ファイルの表示 SAP Content ServerのHAにおけるS3とEFSの考慮事項 AWS上でSAP Content Serverをアーキテクトする際、Amazon EFSとS3 File Gatewayの選択には、それぞれの明確な強みを慎重に検討する必要があります。両方のソリューションが高い耐久性とクロスリージョン機能を提供しますが、S3 File Gatewayベースのアーキテクチャは、主にS3の強力なバージョニング機能を通じて際立っています。これはデータ保護にとって重要な利点です。このバージョニング機能により、誤って削除または破損したファイルのポイントインタイムリカバリが可能になります。これは、ファイルの削除または破損が即座に永続的になるEFSベースのソリューションでは利用できない機能です。両方のサービスがコスト最適化のためのインテリジェントなデータ階層化と同様のクロスリージョンDR機能を提供するようになりましたが、S3のバージョニングは本質的に組み込みのバックアップメカニズムを提供し、別個のバックアップソリューションを維持する複雑さとコストを削減します。データリカバリとバージョン管理が重要な要件である組織、特にドキュメントの以前のバージョンを復元する機能が不可欠なコンプライアンス重視の環境では、S3 File Gatewayアーキテクチャがより包括的なデータ保護戦略を提供します。最終的な選択は特定のビジネス要件に依存しますが、S3 File Gatewayは、高可用性とパフォーマンスと並んで、きめ細かなデータリカバリ機能を優先する組織にとって特に魅力的です。 コスト見積もり このブログシリーズの Part 1 では、S3 File Gatewayの2つのコスト見積もりについて説明しました。1つ目の例はContent Serverデータベースサイズが500GBの場合、2つ目の例は5TBのデータベースの場合です。これらの価格見積もりをHAを含めるように拡張すると: SAP Content Server EC2インスタンス(r7i.xlarge)の数を1から2に増やす EBSストレージボリューム(100GB)の数を1から2に増やす S3 File Gatewayの数を1から2に増やす NLBを追加 表1: 価格比較 シナリオ HAなし HAあり 5TBデータベース $542 $656 500GBデータベース $124 $239 AWS Calculator リンク 1a , 1b , 2a , 2b HAを使用した5TBデータベースの場合、コストは$542から$656に増加します。同様に、HAを使用した500GBデータベースの場合、$124から$239に増加し、HAの追加がコストを大幅に増加させないことを示しています。 上記のコストにはオペレーティングシステム関連のサブスクリプションは含まれていないことに注意してください。これらは、 SUSE Linux Enterprise Server for SAP Applications や Red Hat Enterprise Linux for SAP などのAWS Marketplaceで確認できます。 結論 S3 File Gatewayを使用したSAP Content Serverの高可用性ソリューションの実装は、AWS Well-Architected Frameworkの 信頼性の柱 で言及されているように、運用の回復力を維持し、ビジネス継続性を確保することを目指す組織にとって不可欠です。概説された手順に従うことで—複数のS3 File Gatewayのインストールと構成、同一のファイル共有の作成、NLBの利用、Git内のpacemaker用カスタムリソーススクリプトの利用、EC2 Auto Recoveryの有効化—企業は、潜在的な中断に耐える堅牢でスケーラブルなアーキテクチャを作成できます。 システムパフォーマンスと回復力を管理するプロアクティブなアプローチは、ダウンタイムに関連するリスクを軽減するだけでなく、厳格なサービスレベル契約もサポートします。AWSのインフラストラクチャを活用することで、組織はデータの耐久性とアクセシビリティを確保しながら、ドキュメント管理機能を強化できます。インフラストラクチャの進化に伴ってシステムのフォールトトレランスを維持し、災害復旧メカニズムが効果的であることを検証するために、スケジュールされたダウンタイム中に AWS FIS を使用してHAテストを定期的にスケジュールし、自動化することをお勧めします。 企業がクラウド環境への移行を進める中、これらのHAプラクティスの採用は、重要なSAPワークロードを保護し、デジタル時代における運用効率を推進する上で極めて重要になります。適切にアーキテクトされたHAソリューションに投資することで、組織は現代のITランドスケープの複雑さを自信を持ってナビゲートし、SAPシステムが利用可能でパフォーマンスの高い状態を維持できるようにします。 SAP on AWSディスカッションに参加 お客様のアカウントチームとAWSサポートチャネルに加えて、お客様は re:Post – AWSコミュニティのための再構想されたQ&Aエクスペリエンス – を活用できます。AWS for SAP Solution Architectureチームは、お客様とパートナーを支援するために回答できる議論や質問について、AWS for SAPトピックを定期的に監視しています。質問がサポート関連でない場合は、re:Postでのディスカッションに参加し、コミュニティナレッジベースに追加することを検討してください。 謝辞 このブログへの貢献について、Ferry Mulyadi、Derek Ewell、Spencer Martensonに感謝します。 本ブログはAmazon Q Developer CLIによる機械翻訳を行い、パートナーSA松本がレビューしました。原文は こちら です。

はじめに SAP Content Serverは、さまざまな形式とタイプの大量の電子ドキュメントをSAPデータとともに保存およびアーカイブするために設計されたスタンドアロンシステムです。これらのドキュメントは、SAP MaxDBなどのデータベースまたはSAP Content Serverの基盤となるファイルシステムに保存できます。SAP Content Serverに保存される電子ドキュメントの一般的な例には、販売請求書、発注書、給与明細、電子メールなどがあります。SAP Content Serverは、整理されアクセスしやすいデータを確保する集中型ドキュメント管理を提供します。SAP ECCまたはSAP S/4HANAアプリケーションとのシームレスな統合により、ビジネスプロセスが強化され、企業が法的および規制要件を満たすことができます。暗号化とアクセス制御により、堅牢なデータセキュリティを提供します。 MaxDBを使用したSAP Content Serverを使用しているお客様は、管理する追加のデータベースインスタンス、長時間のデータベースバックアップ、増加するストレージコスト、セキュリティ上の懸念など、潜在的な課題と複雑さに直面しています。このブログでは、MaxDBに代わるストレージメカニズムを提供し、 Amazon Simple Storage Service (S3) File Gateway でSAP Content Serverを使用する方法を紹介します。MaxDB上で実行されている既存のSAP Content ServerをAmazon S3 File Gatewayに移行するための段階的なプロセスをご案内します。 Amazon S3 File Gatewayは Amazon S3 に基づいており、99.999999999%（イレブンナイン）のデータ耐久性と、特定の年におけるオブジェクトの99.99%の可用性を提供します。バックアップ、レプリケーション、リカバリなどの機能により簡単なデータ管理を提供し、暗号化とアクセス制御によりデータセキュリティを確保します。他のAWSサービスと統合してワークフローを強化し、データのバージョニングとライフサイクル管理によりコスト最適化を実現できます。たとえば、お客様は法的要件により、SAPの財務データを7年間保存する必要がある場合があります。Amazon S3のグローバルなアクセシビリティ、高い耐久性、ディザスタリカバリオプションにより、SAP Content Serverストレージのモダナイゼーションに魅力的なソリューションとなっています。 前提条件 開始する前に、以下を確認してください： AWSアカウント：Amazon S3 File GatewayサービスをプロビジョニングするためのAWSアカウント SAPシステム：SAP ERP（S/4HANAまたはECC）（例：RISE with SAPまたはBring Your Own License）またはオンプレミス SAPインストールメディア： SAP Content Serverインストールメディア へのアクセス 基本知識：AWSサービスと基本的なSAP管理に関する知識 提案されるアーキテクチャ ほとんどのお客様のシナリオをカバーする3つのアーキテクチャオプションがあります。 図1は、AWS上でSAP RISEを実行しているお客様を示しています。SAP Content Serverはお客様のAWSアカウントにプロビジョニングされ、 AWS Transit Gateway （または Virtual Private Cloud (VPC) Peering ）を介してSAP RISE AWSアカウントに接続されます。 図1：AWS上のRISE with SAPのソリューションアーキテクチャ 図2は、SAP Content Serverを含むオンプレミスのSAPシステムを使用したハイブリッドモデルを示しています。SAP Content Serverは Amazon S3 File Gateway に接続され、オンプレミスのSAP Content Serverアプリケーションをシームレスに接続して、Amazon S3に保存されたコンテンツリポジトリを保存およびアクセスします。 Amazon File Gatewayサービスを含む仮想マシンがオンプレミスにプロビジョニングされ、 ローカルディスクキャッシュ として機能し、Amazon S3に保存されたオブジェクトの取得パフォーマンスを向上させます。 図2：ハイブリッドモデル（オンプレミスとAWS）のソリューションアーキテクチャ AWS上でSAPをネイティブに実行している（BYOL）お客様の場合、図3に示すように、SAP Content ServerをSAPシステムと同じAWSアカウントにプロビジョニングできます。 図3：AWS上でSAPを実行する（BYOL）ためのソリューションアーキテクチャ 設定手順 AWS環境のセットアップ AWS上でSAP Content Serverをセットアップするには、以下の手順に従ってください。 Amazon S3 File Gatewayの設定 ブログ Connect Amazon S3 File Gateway using AWS PrivateLink for Amazon S3 に従ってAmazon S3 File Gatewayを作成します Amazon S3 File Gatewayが作成されたら、図4のスクリーンショットに従って、ファイルシステムマウントポイント「/content_server」としてマウントします さらに、図2のハイブリッドモデルデプロイメントの場合、Amazon S3 File Gatewayはキャッシュストレージを使用して、最近アクセスされたデータへの低レイテンシーアクセスを提供します。キャッシュストレージは、Amazon S3へのアップロード待ちのデータのオンプレミス永続ストアとして機能します。キャッシュストレージのサイズを決定するには、AWSドキュメント Managing local disks for your gateway を参照してください 図4：ファイルシステム SAP Content Server Amazon EC2インスタンスでのセキュリティグループの設定 インバウンドルール：ベストプラクティスとして、SAPのヘルプドキュメント TCP/IP Ports of All SAP Products に記載されているTCP/IPポートを介して、ソースSAPアプリケーションサーバーのみがSAP Content Serverと通信できるようにします SAP Content Serverのインストールと設定 SAP Note 2786364 に従ってSAP Content Serverをインストールします（SAPサポートポータルへのアクセスが必要です） トランザクションOAC0を介してSAP ERPシステムでコンテンツリポジトリを作成します SAPシステムにログインします。トランザクションコードOAC0を入力します Content Repositories画面で、New Entriesボタンをクリックします リポジトリ属性を定義します： Repository：コンテンツリポジトリの一意の名前を入力します（例：Z_STORAGE_GATEWAY） Description：リポジトリの意味のある説明を入力します（例：Z_STORAGE_GATEWAY） Document Area：適切なドキュメント領域を選択します。通常、ARCHIVEまたはGENERALまたはDMS Storage Type：SAP Content Serverを使用している場合は、HTTP Content Serverを選択します Version No：コンテンツサーバーのバージョン番号を入力します（例：0047） Content Serverの詳細を指定します： HTTP Server：SAP Content ServerのURLを入力します（例：http://<server_name>:1090/sapcs） HTTPS Server：HTTPSを使用する場合は、図6を参照してください 図5：HTTP設定のサンプル 図6：HTTPS設定のサンプル 設定を保存します： Saveボタンをクリックしてエントリを保存します 設定を保存するためのプロンプトを確認します 接続をテストします： リポジトリが設定されたら、接続をテストします コンテンツリポジトリを選択し、Content Server Checkボタンをクリックします Content Serverへの接続が成功したことを確認します トランザクションCSADMINを介して、新しいContent Serverリポジトリを指すようにSAP ERPを設定します 前の手順で作成したContent Repository「Z_STORAGE_GATEWAY」を選択します 図7：Amazon S3 File Gatewayコンテンツリポジトリの選択 リポジトリ設定を更新します： 表1：SAP Content Serverパラメータ 図8：Amazon S3 File Gatewayを指すようにリポジトリ設定を更新 設定を保存し、緑色の信号灯に従ってSAP Content Serverが正常に実行されていることを確認します 図9：「running」状態のContent Server Content Serverのテスト – ME22N SAPのトランザクションME22Nは、発注書を変更するために使用されます。これは、購買管理（MM）モジュールの不可欠な部分であり、ユーザーが調達プロセスのために既存の発注書を変更できるようにします。 ME22Nトランザクションでファイルを添付できるようにするには、トランザクションOAC3を介して「Links for Content Repositories」設定を維持する必要があります。この例では、Object Type「BUS2012」とDocument Type「PDF」のエントリがContent Repository ID「Z_STORAGE_GATEWAY」を指している必要があります。 図10〜12に示すように、発注書の1つにPDFファイルを添付し、このファイルをAmazon S3バケットで確認しましょう。 ME22Nで、既存のPOを編集し、create attachmentをクリックして、図10および11に示すようにPDFドキュメントをアップロードします。 図10：トランザクションME22Nでの添付ファイルの作成 図11：添付ファイルが正常に作成されました SAP Content Serverにアップロードされたドキュメントが、Amazon S3バケットに表示されます： 図12：SAP Content ServerドキュメントがアップロードされたAmazon S3バケット 移行手順 MaxDBを使用したSAP Content Serverをファイルシステムに移行するには、以下の一般的な手順に従います： カスタムZプログラム（Z_DOC_COPYおよびZ_MIGRATE_ARCHIVELINK）によるドキュメントの移行 これらのレポートを使用する利点は、カットオーバーまで定期的に移行を実行できることです Z_DOC_COPY（SAP Note 2774469） このレポートは、ソースコンテンツサーバーから添付ファイルをコピーし、選択したドキュメントタイプまたはコンテンツ全体を1つずつターゲットサーバーにコピーするために使用できます。また、このレポートはソースとターゲット間の添付ファイルのリストを比較するため、レポートはいつでも再実行/再開できます SE38を実行し、レポートZ_DOC_COPYを実行します 以下の入力を行い、executeをクリックします Destination Repository: Source Repository: Document List: 図13：Z_DOC_COPY Z_MIGRATE_ARCHIVELINK（SAP Note 1043676） このレポートは、リンクベースのソースコンテンツサーバーからターゲットへの添付ファイルのコピーに使用できます。このレポートは、リンクテーブルエントリを変更し、ターゲットリポジトリで新しく生成されたIDを更新します SE38を実行し、レポートZ_MIGRATE_ARCHIVELINKを実行します 以下の入力を行い、適切なボックスをチェックしてExecuteをクリックします OLD_ARC: <古いContent ServerリポジトリID> NEW_ORC: <新しいContent ServerリポジトリID> 図14：Z_MIGRATE_ARCHIVELINK 検証とテスト すべてのドキュメントが正常に移行され、アクセス可能であることを確認します 新しいContent Serverが期待どおりに機能することを確認するために、徹底的なテストを実行します ドキュメントの整合性とアクセス許可を確認します （Content Server 7.53、SAP Note 2888195）レポートRSCMSTH0、RSCMSTH1、RSCMSTH2を実行して、コンテンツリポジトリが一貫性があり健全であることを検証します 新しいContent Serverへの切り替え： トランザクションコードOAC3を介して、新しいファイルシステムベースのContent Serverを指すようにSAP設定を更新します 移行後の問題について、システムを注意深く監視します 移行後のクリーンアップ： 不要になった場合は、古いMaxDBセットアップをクリーンアップします すべてのバックアップとディザスタリカバリ手順が、新しいContent Server設定を含むように更新されていることを確認します バックアップとリカバリ AWS Backup を使用して、SAP Content Serverコンポーネントの適切なバックアップとリカバリ戦略を提供できます： SAP Content ServerがインストールされたAmazon EC2インスタンス Amazon S3 File Gatewayアプライアンス Content Serverデータを保存するAmazon S3バケット SAP Content ServerデータはAmazon S3バケットに保存されていますが、潜在的なアプリケーションレベルの破損を防ぐために、その内容をバックアップすることは依然として重要です。 詳細については、SAP lens Well-Architected Frameworkドキュメントのベストプラクティス Establish a method for consistent recovery of business data および Establish a method for recovering configuration data を参照してください。 MaxDBとAmazon S3 File Gatewayの比較 表2は、MaxDBとAmazon S3 File Gateway間の総所有コスト（TCO）の比較を示しています。 表2：MaxDB vs. Amazon S3 File Gatewayの比較 **コスト比較は、500GB（ calculatorリンク ）と5TB（ calculatorリンク ）の2つのデータベースサイズで、以下の前提条件で行われました： SAP認定Amazon EC2インスタンス（r7i.large、2 CPU、16GB RAM）にインストールされたSAP Content Server ストレージ オペレーティングシステムとSAPバイナリ用の100GB gp3ストレージ MaxDB：それぞれ600GBおよび5.5TB gp3ストレージ MaxDB：30日間の保持期間を持つ毎日のデータベースバックアップ、 Amazon S3 Standard – Infrequent Access に保存 Amazon S3 File Gateway：ファイルシステムストレージ用に500GBおよび5TB（MaxDBデータベースサイズと同等） Amazon S3 File Gateway：AWS Backupによる30日間の保持期間を持つ継続的なバックアップ AWSシンガポールリージョンでのワークロード 要約すると、コンテンツリポジトリとしてAmazon S3 File Gatewayを使用すると、運用の複雑さとコストが大幅に削減され、信頼性とセキュリティが向上します。 まとめ このブログ投稿では、SAP Content Serverに統合されたファイルシステムとしてAmazon S3 File Gatewayをセットアップする方法について説明しました。その中にコンテンツリポジトリを作成し、コンテンツリポジトリにアクセスするようにSAPシステムを設定しました。さらに、MaxDBからAmazon S3 File Gatewayへのコンテンツ移行のステップバイステップガイドを提供しました。 Amazon S3 File Gatewayでサポートされるファイルシステムセットアップを使用してAWS上にSAP Content Serverをデプロイすることで、SAP環境でのドキュメント管理のための費用対効果が高く、堅牢でスケーラブルなソリューションを提供できます。AWSサービスを活用することで、高可用性、データ耐久性、効率的なパフォーマンスを確保できます。このガイドで概説されている手順に従って、組織のニーズに合わせた独自のSAP Content ServerをAWS上にセットアップしてください。 SAP Content Serverで高可用性を実装したい場合は、ブログ「 Amazon S3によるHA対応の持続可能で耐久性の高いSAPドキュメントおよびデータアーカイブ – Part2 」を参照してください。 AWS for SAPブログ で詳細を読み、AWS上でSAPランドスケープをモダナイゼーションする方法についてのインスピレーションを得てください。 謝辞 このブログへの貢献に対して、Ferry MulyadiとDerek Ewellに感謝します。 本ブログはAmazon Q Developer CLIによる機械翻訳を行い、パートナーSA松本がレビューしました。原文は こちら です。

Amazon CloudWatch Internet Monitor for SAP Applications は、インターネット接続に関するリアルタイムのインサイトを提供し、企業が問題をトラブルシューティングし、ネットワークパフォーマンスを最適化するのを支援します。 はじめに これは、AWS上のSAPエンドツーエンド・オブザーバビリティに関するブログシリーズのパート3です。 このシリーズの以前のブログ投稿では、AWS上でホストされるSAPシステムのオブザーバビリティの重要性を探求してきました。 Part 1 では、SAPの3層アーキテクチャを紹介し、Amazon CloudWatch Application Insights、CloudWatch RUM、AWS Network Managerなどのサービスが、プロアクティブな監視、迅速なトラブルシューティング、キャパシティプランニングをどのようにサポートするかを示しました。 Part 2 では、SAPネットワークレイテンシー監視に焦点を当て、AWS Network ManagerやNIPINGなどのツール、およびグローバル接続のためのGlobal AcceleratorやCloudFrontなどのソリューションを紹介しました。 これらの基盤の上に、このブログでは、リモートでアクセスされるSAPアプリケーションの信頼性の高いインターネット接続を確保することに焦点を当て、ハイブリッドワーク環境によってもたらされる課題に対処します。AWS上のSAPシステムの信頼性と効率性を維持するために、ネットワークパフォーマンスを監視および最適化する戦略を強調します。 歴史的に、SAPアプリケーションは企業ネットワーク経由でアクセスされていました。しかし、現在では企業の58%が、ユーザーがリモートオフィス、モバイルデバイス、ハイブリッドワーク環境からインターネット経由でFioriなどのSAPアプリケーションにアクセスできるようにしており、企業ネットワークのみのアクセスから移行しています。この移行により、信頼性の高いネットワーク接続を確保する上で新たな課題が生じています。ネットワーク接続は、SAPアプリケーションのパフォーマンスと信頼性に直接影響するため、継続的な監視と最適化が必要です。 AWSは、 Amazon CloudWatch Internet Monitor を使用してこれらの課題に対処します。SAPアプリケーションにとって、ネットワーク接続の監視と管理は、システムの可用性を維持し、応答性の高いユーザーエクスペリエンスを確保する上で重要な側面です。以下の図1に示すように、主要なインターネット障害とSAPクライアントロケーションへの影響は、Internet Monitorダッシュボードで視覚化できます。 図1: Internet Weather Map – このマップは主要なインターネット障害とクライアントロケーションへの影響を表示します。 Amazon CloudWatch Internet Monitorの理解 Amazon CloudWatch Internet Monitorは、既存のAmazon CloudWatchサービスの拡張機能であり、AWSリソースとアプリケーションの監視に使用されます。CloudWatch Internet Monitorは、AWSリソースのインターネット接続の監視に特化しており、ユーザーがAWS環境とインターネット間のネットワークパフォーマンスを視覚化するのに役立ちます。これにより、企業はネットワークレイテンシーとパケット損失を測定でき、アプリケーションとサービスのアクセシビリティと応答性に影響を与える問題を特定できます。 Amazon CloudWatch Internet Monitorの主要なコンポーネントには以下が含まれます: Monitor: Amazon CloudWatch Internet Monitorは、単一のアプリケーション用のリソースで構成され、インターネットパフォーマンスの表示とヘルスアラートの受信を可能にします。これには、定義されたロケーション(都市)と、Amazon Virtual Private Cloud (VPC)、Network Load Balancer、Amazon WorkSpacesディレクトリ、Amazon CloudFrontディストリビューションなどの監視対象リソースが含まれます。これらのリソースは、監視とインターネットパフォーマンス測定の公開の範囲を確立します。 図2: CloudWatch Internet Monitorの概要 – ヘルスイベント、メトリクス、設定オプションを表示するAmazon CloudWatch Internet Monitorインターフェースの概要。 Metrics: Amazon CloudWatch Internet Monitorは、パフォーマンス、可用性、ラウンドトリップタイム、スループットを含む、CloudWatch用の集約メトリクスを生成します。これらのメトリクスは、カスタム名前空間「 AWS/InternetMonitor 」の下のCloudWatch Metricsで表示でき、アプリケーションへのグローバルトラフィックと各AWSリージョンをカバーします。 Internet measurements: Amazon CloudWatch Internet Monitorは、5分ごとにCloudWatch Logsに測定値を公開します。これらの測定値は、アカウント内の上位500の都市ネットワークをカバーします。これには、特定のVPC、Load Balancer、CloudFrontディストリビューション、またはWorkspacesディレクトリのパフォーマンススコア、可用性スコア、転送バイト数、ラウンドトリップタイムが含まれます。オプションで、データをAmazon S3に保存できます。これらの測定値の例を図3に示します。 図3: Internet Measurements Graph – 指定された期間にわたるレイテンシー、パケット損失、スループットなどのインターネットパフォーマンスメトリクスを示すグラフ。 Health event: Amazon CloudWatch Internet Monitorは、世界中のネットワークレイテンシーの増加など、アプリケーションに影響を与える問題を警告するヘルスイベントを生成します。AWSのグローバルインフラストラクチャ全体の履歴データを使用して、影響を計算し、事前設定されたしきい値に基づいてイベントを作成します。ヘルスイベントは、影響を受けた都市ネットワークの詳細を示し、CloudWatchまたはAWS SDK/CLI経由で表示できます。 Performance and availability scores: Amazon CloudWatch Internet Monitorのパフォーマンススコアと可用性スコアは、パフォーマンスまたは可用性の低下の影響を受けていないトラフィックの推定パーセンテージを表します。これらのスコアは、推定ベースラインと比較して分析されたデータに基づいて計算されます。たとえば、パフォーマンススコアが99%の場合、トラフィックの1%のみがパフォーマンス低下を経験していることを示します。可用性スコアも同様に、指定されたトラフィックの中断のないサービスを反映します。この例を図2に示します。 Round-trip time (RTT): クライアントリクエストが応答を受信するまでの時間を測定します。クライアントロケーション全体で集約され、各ロケーションからのトラフィック量によって重み付けされます。この例を図4に示します。 図4: Round-Trip Time (RTT) Graph – 時間の経過に伴う異なるパーセンタイル(P95、P90、P50)でのクライアントリクエストのラウンドトリップタイムを示すグラフ。 Amazon CloudWatch Internet MonitorがSAPにとって重要な理由 SAPアプリケーションはミッションクリティカルであり、信頼性の高いネットワーク接続に依存しています。CloudWatch Internet Monitorにより、SAPチームは接続を検出、トラブルシューティング、改善でき、エンドユーザーのダウンタイムを最小限に抑えることができます。 Amazon CloudWatch Internet Monitorは、以下の主要な機能とメリットを提供します: 可視性: インターネット接続のリアルタイム監視により、ネットワーク問題を迅速に特定して対処し、SAPシステムのダウンタイムを削減します。 トラブルシューティング: 詳細なフローログへのアクセスにより、SAPワークロードに影響を与えるネットワークパフォーマンス問題の根本原因分析が加速されます。 地理的インサイト: 複数のリージョンからの接続を監視し、ユーザー固有またはロケーションベースの問題にプロアクティブに対応できます。 パフォーマンス最適化: レイテンシー、パケット損失、ジッターに関する実用的なメトリクスにより、SAPアプリケーションのパフォーマンスを向上させるための手動調整が可能になります。 セキュリティ: 疑わしいトラフィックと不正アクセスを検出し、SAP環境のセキュリティを強化します。 スケーラビリティ: SAPワークロードの成長に合わせて監視を簡単にスケールし、パフォーマンスを一貫して保ちます。 AWS統合: CloudWatch AlarmsおよびAWS Lambdaとシームレスに接続し、自動通知と修復を実現します。 SAPでAmazon CloudWatch Internet Monitorを活用するためのベストプラクティス SAP環境でAmazon CloudWatch Internet Monitorのメリットを最大化するには、以下のベストプラクティスの実装を検討してください: VPC Flow Logsを有効化: すべてのSAPインターフェース(SAP FioriフロントエンドとHANAバックエンド間など)の詳細なネットワークトラフィックをキャプチャします。ログを使用して、輻輳、設定ミス、または不正アクセスを特定し、必要に応じてルーティングまたはセキュリティを微調整します。 関連するメトリクスを定義: 主要なKPI(レイテンシー、パケット損失、スループット、可用性)のCloudWatchメトリクスを設定します。たとえば、エンドユーザーからSAPシステムへのレイテンシーを監視し、アラートと迅速なトラブルシューティングをトリガーする実用的なしきい値を設定します。 アラームとアラートを設定: 重要なSAPトラフィック(パケット損失>1%またはレイテンシー>100msなど)のカスタムアラームを作成します。これらのアラームは、チームがSAPプロセスに影響を与える中断を迅速に検出して解決するのに役立ちます。 ダッシュボードを活用: SAPネットワークヘルスを視覚化するダッシュボードを構築し、SAPコンポーネント全体のレイテンシー、パケット損失、スループットなどのメトリクスを組み合わせます。スパイクや障害が検出されたら迅速に対応します。 ログを定期的にレビュー: CloudWatch Internet Monitorログを定期的に分析して、トレンドとボトルネック(ピークSAPアクティビティ中の定期的なレイテンシースパイクなど)を確認します。調査結果を使用して、帯域幅とロードバランシングを最適化します。 ネットワークルートを最適化: ログとメトリクスからのインサイトに基づいて、ルートと帯域幅の割り当てを改善します。SAPワークロードに影響を与える永続的またはグローバルな接続問題には、AWS Direct ConnectやGlobal Acceleratorなどのソリューションを検討してください。 AWS Health Eventsと統合: CloudWatch Internet MonitorをAWS Healthとリンクして、関連するAWSインシデントや計画メンテナンスに関するプロアクティブな通知を取得し、事前にSAPワークロードの再ルーティングまたは保護を可能にします。 SAP監視の開始 CloudWatch Internet Monitorの機能を活用するには、以下の手順に従ってSAPアプリケーションのインターネット接続を監視します: ステップ1: インターネット接続を備えたAWS上で実行されるSAPシステム 最初のステップとして、AWS上のSAPシステムがインターネットアクセシビリティのためのパブリックエンドポイントを持っていることを確認します。SAP Web Dispatcherをエントリポイントとして使用して、リクエストをアプリケーションサーバーにルーティングします。Web DispatcherをApplication Load Balancer (ALB)の背後に配置して、パフォーマンスと可用性を向上させるためにトラフィックを分散します。ALBの前にAWS Web Application Firewall (WAF)を設定して、SQLインジェクションやXSSなどの一般的なWeb攻撃から保護します。 ステップ2: CloudWatchに移動 AWSアカウントにログインしたら、AWS Management Consoleに移動します。AWSサービス検索バーで「CloudWatch」を検索するか、サービスメニューの「Management & Governance」の下で見つけます。 図5: CloudWatchサービスを表示するAWS Management Consoleの検索結果。 ステップ3: CloudWatch Internet Monitorを有効化 CloudWatch Internet MonitorはAmazon CloudWatchの機能であり、すべてのAWSリージョンでデフォルトで有効になっています。有効にするための特定のアクションを実行する必要はありません。ただし、Internet Monitorを最大限に活用するには、監視したいVPCのVPC Flow Logsを有効にする必要があります。 ステップ4: VPC Flow Logsを有効化(オプションですが推奨) AWSリソースとインターネット間のインターネットトラフィックに関する詳細なインサイトを取得するには、VPC Flow Logsを有効にします。これらのログは、VPC内のネットワークインターフェースとの間のIPトラフィックに関する情報をキャプチャします。このデータは、インターネットトラフィックパターンの監視と分析に不可欠です。 VPC Flow Logsを有効にするには: AWS Management Consoleに移動し、「VPC」サービスに移動します。 左側のナビゲーションペインから「Your VPCs」を選択します。 監視したいVPCを選択し、「Actions」ボタンをクリックします。 ドロップダウンメニューから「Create Flow Log」を選択します。 図6: Actionsメニューを使用して選択したVPCのフローログを作成するプロセスを示すAWS VPCダッシュボード。 ログの宛先(CloudWatch Logs)、IAMロール、必要に応じてフィルターを含むFlow Log設定を構成します。ログに記録したい適切なトラフィックタイプを選択してください。 図7: 既存のフローログと選択したVPCの新しいフローログを作成するオプションを表示するAWS VPCコンソール。 典型的なSAP環境でログに記録することを検討すべき一般的なトラフィックタイプは次のとおりです: SAPアプリケーショントラフィック: Fiori/GUIクライアントとバックエンドSAPサーバー間のトラフィックをログに記録して、レイテンシー、パケット損失、ユーザーの中断を監視します。 データベーストラフィック: SAPアプリサーバーとHANAまたは他のデータベース間のログを記録して、リアルタイムトランザクションに影響を与える問題をキャッチします。 統合トラフィック: SAP PI/POと外部またはサードパーティシステム間のフローを監視して、失敗した統合をトラブルシューティングします。 外部アクセス: インターネット経由でSAPへの着信接続(Fiori、VPN)をログに記録して、パフォーマンス、セキュリティ、または不正アクセスの問題を発見します。 セキュリティグループトラフィック: SAP Web/データベースサーバー間のログを記録して、設定ミスや不正アクセスを検出します。 ステップ5: CloudWatch Internet Monitorにアクセス CloudWatch Internet Monitorにアクセスするには、以下の手順に従います: AWS Management Consoleで、「Management & Governance」セクションの「CloudWatch」をクリックします。 CloudWatchダッシュボードで、左側のペインの「Network Monitoring」セクションに移動します。 「Internet Monitors」をクリックします。 図8: CloudWatch Dashboard – メトリクスとアラームを含むInternet Monitorセクションを強調表示したAmazon CloudWatchダッシュボードのスクリーンショット。 ステップ6: Internet Monitorメトリクスを探索 Internet Monitorダッシュボードでは、AWSリソースのインターネット接続とパフォーマンスに関連するメトリクスが表示されます。これらのメトリクスには、インターネットゲートウェイ、VPCエンドポイント、NATゲートウェイなどに関連するデータが含まれます。 ステップ7: CloudWatch Internet Monitorダッシュボードを作成 CloudWatchコンソールに入ったら、SAPアプリケーションのインターネット接続とパフォーマンスメトリクスを視覚化するカスタムダッシュボードを作成できます。 カスタムダッシュボードを作成するには: CloudWatchナビゲーションペインの「Dashboards」をクリックします。 「Create Dashboard」を選択します。 ダッシュボードに名前を付けて、「Create Dashboard」をクリックします。 関連するメトリクスを表示するためにダッシュボードにウィジェットを追加します。VPC Flow Logs、インターネットゲートウェイ、エンドポイント、その他のネットワーク関連パラメータに関連するメトリクスを含めることができます。 図9: Create Custom Dashboard – SAPアプリケーションの特定のメトリクスとデータポイントを視覚化するためにAmazon CloudWatchでカスタムダッシュボードを作成する手順。 ダッシュボードの例: Fioriアプリのパフォーマンス: Fioriアプリに影響を与えるレイテンシーとパケット損失を監視します。例: Fioriサーバーとバックエンド間のレイテンシーを視覚化して、速度低下を検出します。 SAP HANAデータベースサーバーの接続: SAP HANAデータベースサーバーへのインターネット接続を監視します。例: アプリケーションサーバーとHANA間のパケット損失を追跡して、パフォーマンスの問題を確認します。 外部統合: SAP PI/POの接続を監視します。例: SAPと外部システム(CRM)間のトラフィックを視覚化して、スムーズな統合を確保します。 ステップ8: アラームとアラートを設定 SAPパフォーマンスの問題を迅速に検出して対処するためにCloudWatchアラームを設定します。ネットワークレイテンシー(200ms)、パケット損失(1%)、統合可用性(99%)、TCP接続時間(500ms)、バックエンドスループット(50 Mbps)、HTTP応答時間(3秒)、バックエンドエラー(1分あたり5回以上)などの主要なメトリクスのしきい値を設定します。しきい値を超えると、CloudWatchは通知を送信したり、自動応答をトリガーしたりできます。 アラームを作成するには: CloudWatchで「Alarms」を選択し、次に「Create Alarm」を選択します。 メトリクスを選択し、条件を設定し、アクションを定義します。 アラームをアクティブ化して監視を開始します。 図10: Set Up Alarms and Alerting – Amazon CloudWatchで特定のSAPアプリケーション要件に基づいてカスタムアラームとアラートしきい値を設定する手順。 アラームの例: ネットワークレイテンシー: レイテンシーがしきい値(例: 200ms)を超えた場合にアラートします。例: Fioriアプリのレイテンシーが200msを超えた場合に通知します。 SAP HANAデータベースサーバーのパケット損失: パケット損失が設定されたパーセンテージを超えた場合にアラームします。例: SAPサーバーとHANA間のパケット損失が1%を超えた場合にアラートをトリガーします。 統合の失敗: SAP PI/POの中断に対してアラートします。例: 統合トラフィックが低下した場合に通知し、同期の問題を示します。 ステップ9: 監視と最適化 SAPアプリケーションの長期的なパフォーマンスと可用性を確保するために、チームはInternet Monitorによって生成されたダッシュボードとアラートを組織の全体的な運用ヘルスレビュープロセスに組み込む必要があります。これには以下が含まれます: 運用レビューへのダッシュボードの組み込み 所有権とSLAの定義 継続的改善のためのトレンド分析 自動化とエスカレーション 応答のシミュレーションとテスト CloudWatch Internet Monitorのインサイトを運用化することで、組織はリアクティブなトラブルシューティングからプロアクティブなネットワークガバナンスに移行し、ダウンタイムを削減し、SAPワークロードをより効果的にサポートできます。 SAP監視の価格 CloudWatch Internet Monitorは、コスト効率の高い従量課金制の価格モデルを提供し、実際の使用量に基づいてSAPインフラストラクチャを監視できます。価格は2つの主要なコンポーネントに分かれています: 監視対象のSAPリソース これは、アプリケーションサーバー、データベース、その他の主要コンポーネントなどのSAPリソースの数に基づいています。各リソースに対して1時間あたりの料金が発生します。 都市ネットワークごとの料金 都市ネットワークごとの料金は、監視される都市ネットワークの数に依存します。最初の100の都市ネットワークは基本価格に含まれており、追加の都市ネットワークは別途請求されます。 CloudWatch LogsとMetricsの料金 監視サービスの一部として、診断ログがトラフィック量による上位の都市ネットワーク(最大500の都市ネットワーク)のCloudWatch Logsに公開されます。これらのログに対して、使用量に基づいてCloudWatch Logsの料金が発生します。 CW Internet Monitorの価格の詳細については、以下を参照してください – https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-InternetMonitor.pricing.html 次のステップ: SAPアプリケーションおよび関連シナリオでInternet Monitorを活用することに興味のあるユーザーは、以下のリソースを探索できます: Internet Monitorドキュメント は、セットアップ、ユースケース、ヘルスイベント通知や地理的インサイトなどの機能に関する詳細なガイダンスを提供します。 Introducing Amazon CloudWatch Internet Monitor や Utilizing CloudWatch Internet Monitor with Amazon WorkSpaces Personal などのAWSブログは、アプリケーションヘルスの監視とユーザーエクスペリエンスの最適化のための実用的な例と統合のヒントを提供します。 結論: Amazon CloudWatch Internet Monitorは、SAPチームにインターネット接続とパフォーマンスに関するほぼリアルタイムの可視性を提供し、組織がネットワーク問題をプロアクティブに解決し、AWS上のSAPワークロードの最適な運用を維持できるようにします。 本ブログはAmazon Q Developer CLIによる機械翻訳を行い、パートナーSA松本がレビューしました。原文は こちら です。