11 月 18 日週は、AWS からなんと 197 もの新サービスがリリース されました。つまり、 AWS re:Invent 2024 に近づきつつあるということです。 AWS のニュースブログチームでも、皆さんに楽しく読んでいただけるように、サービスチームによる素晴らしいリリースを紹介する re:Invent 関連の新しいブログ記事の仕上げに取りかかっています。 最も興味深いニュースは、 AWS Trainium チップ 開発の 主要なトレーニングパートナーとして、Anthropic との戦略的コラボレーションを拡大していることです。これに加えて、AWS は Anthropic の Claude モデルを Amazon Bedrock でデプロイするための主要なクラウドプロバイダーでもあります。 私たちは、このようなコラボレーションを通じて、 生成 AI テクノロジーでお客様が達成できることの限界を押し広げていきます。 11 月 18 日週のリリース AWS バンドル機能のリリースをいくつかご紹介します。 Amazon Aurora – Amazon Aurora Serverless v2 では、 0 Aurora キャパシティユニット (ACU) へのスケーリング がサポートされるようになりました。0 ACU なら、データベースが非アクティブ状態の間にコストを抑えることができます。データベースは ACU を 0.5 個ではなく、0 個までスケールダウンできるようになりました。Amazon Aurora が Amazon RDS データベースプレビュー環境の MySQL 8.0.39 および PostgreSQL 17.0 と互換性を持つようになりました。 Amazon Bedrock – Amazon Bedrock Flows (以前は Prompt Flows と呼ばれていました) の一般提供により、コードを記述しなくても、複雑な生成 AI ワークフローをすばやく構築して実行できるようになりました。Amazon Bedrock ナレッジベースでは、検索拡張生成 (RAG) アプリケーションを構築するための バイナリベクトル埋め込み がサポートされるようになりました。また、Amazon Bedrock では、基盤モデル (FM) からより高い品質の応答が得られるようにプロンプトを書き換えるための プロンプト最適化 のプレビュー版も公開されました。 AWS Amplify AI キット を使用すると、データを簡単に活用して Bedrock AI モデルからカスタマイズされた応答を取得し、チャット、会話検索、要約などの AI 機能を備えたウェブアプリを構築できます。 Amazon CloudFront – クライアントとサーバー間で HTTP/2 接続を介した双方向通信を可能にする gRPC アプリケーションを Amazon CloudFront で 使用できます。Amazon CloudFront では、VPC プライベートサブネットでホストされているアプリケーションからコンテンツを配信するための 仮想プライベートクラウド (VPC) オリジン と、世界中のすべての CloudFront エッジロケーションに接続するための専用の IP アドレスリストを提供する エニーキャスト静的 IP が導入されました。また、CloudFront Functions 内で オリジンを変更 することで、リクエストごとにオリジンサーバーを条件付きで変更または更新したり、 新しいログ設定や配信オプション を使用したりすることもできます。 Amazon CloudWatch – フィールドインデックス と ログ変換 を使用して、CloudWatch ログのログ分析を大規模に改善できます。また、CloudWatch Application Signals による 強化された検索および分析エクスペリエンス と ランタイムメトリクスのサポート を使用したり、CloudWatch Real User Monitoring (RUM) のウェブバイタルアノマリーから直接 パーセンタイル集計とシンプルなイベントベースのトラブルシューティング を使用したりすることもできます。 Amazon Cognito – パスキー、E メール、テキストメッセージを使用したサインインなど、 パスワードなしの認証 によって、アプリケーションへのユーザーアクセスを保護できます。Amazon Cognito では、お客様が会社やアプリケーションのブランディングに合わせてパーソナライズできるホスト型サインインおよびサインアップエクスペリエンス、 マネージドログイン が導入されました。Cognito は、ユーザープールの新しい機能階層である Essentials と Plus 、および開発者に焦点を当てた新しいコンソールエクスペリエンスをリリースします。詳細については、 Donnie のブログ記事 をお読みください。 Amazon Connect – 新しい 顧客プロファイルとアウトバウンドキャンペーン を使用すると、顧客のニーズが潜在的な問題となる前に積極的に対応できます。Amazon Connect Contact Lens は、 カスタムダッシュボードの作成 と、既存のダッシュボードからのウィジェットの追加または削除のサポートを開始しました。新しい Amazon Connect Email を使用して、顧客から会社のアドレスに送信された E メールや、ウェブサイトまたはモバイルアプリのウェブフォームから送信された E メールを受信して、返信することができます。 Amazon EC2 – Amazon Application Recovery Controller (ARC) の ゾーンシフトとゾーン自動シフト を使用して、Auto Scaling グループ (ASG) の EC2 インスタンスの起動を障害のあるアベイラビリティーゾーン (AZ) から遠ざけ、別の AZ で正常に動作していないアプリケーションをすばやく回復できます。Application Load Balancer (ALB) は、 HTTP リクエストとレスポンスヘッダーの変更 のサポートを開始しました。これにより、アプリケーションコードを変更しなくても、アプリケーションのトラフィックとセキュリティ状態をより細かく管理できるようになります。 AWS End User Messaging (別名 Amazon Pinpoint) – SMS および MMS チャネルを介して送信されたメッセージの フィードバックを追跡 したり、国のルール設定を上書きして個々の電話番号への メッセージを明示的にブロックまたは許可 したり、 SMS リソースのコスト配分タグ を使用してリソースに関連する各タグの支出を追跡したりできるようになりました。AWS End User Messaging は、Amazon EventBridge との統合もサポートするようになりました。 AWS Lambda – Lambda SnapStart for Python と .NET 関数 を使用すると、1 秒未満という高速の起動パフォーマンスを実現できます。AWS Lambda は、 非同期呼び出しの障害イベント送信先 として Amazon S3 をサポートするようになりました。また、Lambda を使用して構築されたサーバーレスアプリケーションのヘルスとパフォーマンスを簡単にモニタリングできる Amazon CloudWatch Application Signals のサポートも開始しました。Apache Kafka イベントソースをサブスクライブするイベントソースマッピング (ESM) で、新しい Node.js 22 ランタイム と プロビジョンドモード を使用することもできます。 Amazon OpenSearch Service – 1 つのクラスターを 1,000 個のデータノード (1,000 個のホットノードおよび/または 750 個のウォームノード) にスケールして、25 ペタバイトのデータを管理できます。Amazon OpenSearch Service では、OpenSearch の検索および分析機能を拡張するための新しいプラグイン管理オプション、 Custom Plugins が導入されました。 OpenSearch Serverless – OpenSearch SQL と OpenSearch Piped Processing Language (PPL) クエリ を使用して、既存の SQL スキルとツールを活用できます。 バイナリベクトルと FP16 圧縮 では、メモリ要件を下げてコストを削減できます。また、 ポイントインタイム (PIT) 検索 を使用して、OpenSearch Serverless の特定の瞬間に固定されたデータセットに対して複数のクエリを実行できます。 OpenSearch Ingestion – AWS Lambda を使用して OpenSearch Ingestion パイプラインでカスタム Lambda 関数を定義できるようになりました。また、 Amazon Security Lake へのセキュリティデータの書き込み のサポートが開始され、一般的なサードパーティーソースからセキュリティデータを取り込んで変換できるようになりました。 Amazon Q Business – 表形式検索 を使用して、Q Business に取り込んだドキュメントに埋め込まれたテーブルから、回答を抽出できます。再度アップロードするのではなく、 ファイルをドラッグアンドドロップ でアップロードして、最近アップロードしたファイルを新しい会話で再利用できます。Amazon Q Business では、 Smartsheet 全般、 Asana 、 Google カレンダー との統合 (プレビュー版) がサポートされるようになりました。これにより、選択したデータソースとインデックスを自動的に同期できます。Google Chrome、Mozilla Firefox、Microsoft Edge 用の Q Business ブラウザ拡張機能 を使用することもできます。 Amazon Q Developer – 表示している AWS マネジメントコンソールのページ に関連する質問を直接行うことができるため、クエリでサービスやリソースを指定する必要はありません。また、IDE で Q Developer が生成した カスタマイズ可能なチャット応答 を使用して、Q Developer をプライベートコードベースに安全に接続し、より正確なチャット応答を受信することもできます。最後に、AWS コンソールモバイルアプリの 音声入力および出力機能 を会話プロンプトと併用して、AWS アカウントのリソースを一覧表示できます。 Amazon QuickSight – Layer Map を使用して販売地域やユーザー定義リージョンなどのカスタムの地理的境界を視覚化し、 Image Component で画像を直接アップロードして、会社のロゴの追加などのさまざまな用途に使用できます。Amazon QuickSight は、既存のダッシュボードまたは分析から現在の分析に ビジュアルをインポート する機能と、プレビュー版の Highcharts Core ライブラリを使用して、カスタムのビジュアライゼーションを作成する Highcharts ビジュアル を提供します。 Amazon Redshift – Amazon EC2 インスタンス上の Confluent Managed Cloud およびセルフマネージド Apache Kafka クラスターの より幅広いストリーミングソース からデータを取り込むことができます。また、 強化されたセキュリティデフォルト からデータを取り込むこと可能です。これにより、データセキュリティのベストプラクティスを順守し、潜在的な設定ミスのリスクを軽減できます。 AWS System Manager – 新たに改善された AWS Systems Manager を使用すると、ノードを大規模に管理するために要望の多かったクロスアカウントおよびクロスリージョンのエクスペリエンスが実現します。AWS Systems Manager は、 Windows Server 2025、Ubuntu Server 24.04、Ubuntu Server 24.10 を実行するインスタンスのサポートを開始しました。 Amazon S3 – ユーザーに代わってオブジェクトを期限切れにするよう S3 Express One を設定し、S3 Express One Zone で データをオブジェクトに追加 することができます。 Mountpoint for Amazon S3 では、Amazon S3 Express One Zone を高パフォーマンスのリードキャッシュとして使用することもできます。Amazon S3 Connector for PyTorch は 分散チェックポイント (DCP) のサポートを開始し、Amazon S3 にチェックポイントを書き込む時間が短縮されました。 Amazon VPC – ネットワーク管理者およびセキュリティ管理者が VPC のインターネットトラフィックを正式にブロックできるようにする新しい一元化された宣言型コントロール、 Block Public Access (BPA) for VPC を使用できます。Amazon VPC Lattice では Amazon ECS とのネイティブ統合 の提供が開始され、コンテナ化されたアプリケーションを簡単にデプロイ、管理、スケールできるようになりました。 このブログで取り上げなかったリリースニュースはまだまだあります。詳細については、「 AWS の最新情報 」を参照してください。 AWS re:Invent でバーチャルにお会いしましょう 12 月 2 日週、私たちは米国ラスベガスで AWS の最新情報を聞き、エキスパートから学び、グローバルクラウドコミュニティとつながります。re:Invent に参加する場合は、出発前に アジェンダ 、 セッションカタログ 、 参加者ガイド を確認してください。 2024年の re:Invent に直接参加できない方のために、AWS では 基調講演とイノベーショントークをライブストリーミング するオプションもご用意しています。 オンラインパスに登録 することで、イベント後にオンデマンドの基調講演、イノベーショントーク、および厳選されたブレイクアウトセッションにアクセスできます。また、ワンクリックでイベント登録が可能で、多くの AWS ツールやサービスにアクセスできる個人アカウント、 AWS ビルダー ID にもご登録いただけます。 12 月 2 日週もどうぞお楽しみに! – Channy 原文は こちら です。

11 月 22 日、新たに改善された AWS Systems Manager をご紹介します。これにより、ノードを大規模に管理するために要望の多かったクロスアカウントおよびクロスリージョンのエクスペリエンスが実現します。 新しい System Manager エクスペリエンスでは、 Amazon Elastic Compute Cloud (EC2) インスタンス、コンテナ、他のクラウドプロバイダーの仮想マシン、オンプレミスサーバー、エッジの モノのインターネット (IoT) デバイスなど、さまざまなインフラストラクチャタイプを含むすべてのマネージドノードを一元的に可視化できます。 Systems Manager Agent (SSM Agent) がインストールされていて、Systems Manager に接続されている場合、これらは「マネージドノード」と呼ばれます。 SSM Agent が何らかの理由でノードでの動作を停止すると、Systems Manager はノードとの接続を失い、そのノードは「非マネージドノード」と呼ばれます。 新しいアップデートでは、Systems Manager を使用して非マネージドノードを簡単に検出し、トラブルシューティングすることもできます。自動診断を実行したり、スケジュールを設定したりすることも可能です。自動診断では推奨ランブックが提供され、このランブックを実行して問題を解決し、接続を再確立して再びマネージドノードにすることができます。 また、Systems Manager は Amazon Q Developer とも統合されました。Amazon Q Developer は、最も高機能な生成 AI 搭載のソフトウェア開発アシスタントです。マネージドノードに関する質問を自然言語で Amazon Q Developer に尋ねると、迅速なインサイトが得られるだけでなく、Systems Manager へのリンクが直接表示され、アクションを実行したり、さらに詳しく調べたりできます。 このリリースでは、 AWS Organizations を使用することも可能です。Systems Manager との新しい統合により、委任された管理者が組織全体のノードを一元管理できるようになりました。 これらの新機能のいくつかを実証するのに役立つ簡単な例を見てみましょう。 あなたはクラウドプラットフォームエンジニアで、組織内の Windows Server 2016 Datacenter を実行しているすべてのノードを交換することを目的とした移行計画を主導しているとします。新しい Systems Manager エクスペリエンスを使用して、計画に含める必要があるすべてのノードに関する情報をすばやく収集しましょう。 ステップ 1 – Amazon Q Developer への質問 最も簡単な出発点は、Amazon Q Developer を使用して、見つけたいものについて自然言語で尋ねることです。AWS コンソールを使用して Amazon Q チャットボットを開き、 Find all of my managed nodes running Microsoft Windows Server 2016 Datacenter in my organization と入力します。 Amazon Q はすぐに回答を返します。条件を満たすノードが 10 個あることが示され、各ノードの概要を記載したリストが表示されます。 System Manager の新しい ノードの探索 ページにリダイレクトするリンクもあり、このページで詳細を確認できます。リンクをクリックしてみましょう。 ステップ 2 – インフラストラクチャの見直し ノードの探索 ページには、組織のすべてのマネージドノードの包括的な概要が表示されます。また、結果をグループ化したりフィルタリングしたりして、すばやくアクセスできるようにするオプションが用意されています。この場合、結果は既に オペレーティングシステム名 でフィルタリングされており、 Microsoft Windows Server 2016 Datacenter を実行しているすべてのノードのリストが提供されていることがわかります。 これは素晴らしい起点となります! レポートをダウンロードしてノードを移行計画に追加し、作業を終了することもできます。ただし、このページにはマネージドノードに関する情報のみが表示されます。プランに含める必要のある非マネージドノードは存在するのでしょうか? 調べてみましょう。 ステップ 3 – 非マネージドノードの処理 メニューを開き、 ノードインサイトのレビュー ページに移動します。ここには、インサイトに富んだインタラクティブなグラフを提供するウィジェットを含むダッシュボードが表示されます。これを使用して、ノードに関する詳細情報を調べたり、アクションを実行したりできます。例えば、 マネージドノードタイプ の円グラフにはマネージドノードのタイプが表示され、 SSM Agent バージョン のグラフには、そのノードで実行されている SSM Agent のさまざまなバージョンの概要が表示されます。ウィジェットを追加したり置き換えたりして、このビューをカスタマイズすることもできます。 非マネージドノードを調査して、移行計画に追加する必要のあるノードを見逃さないようにしたいと考えています。 ノード概要 ウィジェットには、非マネージドノードが 2 つあることが明確に表示されています。これは、これらのノードに SSM Agent がインストールされていない可能性があることを示しています。その場合、手動で調査する必要があります。ただし、SSM Agent の権限またはネットワーク接続に問題があるために、Systems Manager がこれらのノードを管理したり、他のマネージドノードと同様に扱ったりできない場合もあります。新しい Systems Manager エクスペリエンスでは、SSM Agent の問題を簡単にトラブルシューティングして修正できるので、今すぐ試してみましょう。 まず、非マネージドノードが表示されているグラフの一部を選択します。これにより、ワンクリックですべての非マネージドノードの包括的な診断を開始するオプションが表示されます。これを実行してみましょう。 診断では、欠落している 仮想プライベートクラウド (VPC) エンドポイント、誤った VPC DNS 設定、SSM Agent による Systems Manager への接続を妨げている可能性のある誤ったインスタンスセキュリティグループの設定などの主要な設定を確認します。スキャンが完了すると、 誤設定された VPC エンドポイント の結果が 2 つ表示されていることがわかります。また、問題を解決するために実行できる推奨ランブックを含む、サイドパネルを開くためのリンクと、関連するドキュメントへのリンクも表示されます。 推奨ランブックの実行を選択すると、変更の詳細なプレビューが表示されます。これには、使用される入力パラメーターに加えて実行されるアクションの完全な概要、関連するステップの内訳を表示するリンク、この実行のターゲットノードが含まれます。 先に進んで [実行] を選択しましょう。これにはコストが発生する可能性があるので、実行する前に必ず確認してください。このページでは、各ノードの問題を解決するための手順を説明しているので、進捗状況を確認できます。 なるほど! 修復が完了すると、Systems Manager が 2 つのノードの SSM Agent の問題を検出して修正したことがわかります。つまり、Systems Manager はそれらのノードで実行されている SSM Agent に正常に接続して「マネージドノード」にすることができます。 これを確認するには、 ノードの探索 ページに戻って、「非マネージドノード」の数が 0 に減少していることを確認します。 これですべてのノードが管理されたので、移行計画に追加する必要があるすべてのノードのリストを作成する準備が整いました。 ステップ 4 – レポートのダウンロード ノードの検索 ページに戻ると、Microsoft Windows Server 2016 Datacenter を実行しているノードの数が 10 から 12 に増えていることがわかります。 つまり、自動診断で修正した以前は管理されていなかったノードが、実際にターゲットオペレーティングシステムを実行しているということです。 これはまさに必要としている情報なので、 レポート をダウンロードすることにします。ファイル名を指定してから、含める列など、いくつかのオプションを選択します。この場合、列名を含む行を使用した CSV ファイルをダウンロードすることにします。 これで完了です。 インフラストラクチャ全体でアップグレードが必要なノードに関する詳細情報が記載された CSV を入手できました。そして何より素晴らしいのは、 移行を進める準備ができたら、Systems Manager を使用してアップグレードを自動化することもできるということです。 まとめ Systems Manager は、コンピューティングインフラストラクチャを可視化して制御し、運用アクションを大規模に実行するための重要なツールです。新しいエクスペリエンスでは、AWS アカウント、オンプレミス、マルチクラウド環境のすべてのノードを、一元化されたダッシュボードを通じて一元的にクロスアカウント、クロスリージョンで表示できるようになりました。また、Amazon Q Developer との統合による自然言語クエリ、ワンクリックでの SSM Agent のトラブルシューティングも可能です。Systems Manager コンソールに移動し、わかりやすい指示に沿って操作することで、追加費用なしで新しいエクスペリエンスを有効にできます。 新しい Systems Manager エクスペリエンスの詳細については、 ドキュメント をご覧ください。 このエクスペリエンスの完全なビジュアルツアー については、このインタラクティブデモをご確認ください。 原文は こちら です。

Gartner は、2 つ目の Magic Quadrant for Distributed Hybrid Infrastructure (DHI) を公開しました。このレポートでは、 Amazon Web Services (AWS) が再びリーダーとして選出されています。AWS には、この DHI ポートフォリオにおいて、 AWS Outposts 、 AWS Snowball 、および AWS Local Zones という 3 つの製品を有しています。付随する Gartner の Critical Capabilities for DHI では、AWS は、ハイブリッドインフラストラクチャ管理、エッジコンピューティング、保証されたワークロード、人工知能と機械学習 (AI/ML) など、Gartner が評価した 6 つのユースケースのうち 4 つで 1 位にランキングされ、コンテナ管理のユースケースでは上位 2 社のうちの 1 社にランキングされています。 Gartner は、ベンダーが製品やサービスを効果的に提供する能力を測定する実行能力と、ベンダーの市場理解と将来の成長戦略を評価するビジョンの完全性に基づいて、10 社の DHI プロバイダーを評価しています。 2024 年の Gartner Magic Quadrant for DHI のグラフを次に示します。 Gartner は、AWS の強みを次のように認識しています: 主要なパブリッククラウドプロバイダー – AWS DHI ソリューションは、インフラストラクチャをデータセンターとエッジロケーションに拡張し、残りのプライベートクラウドインフラストラクチャからの移行も希望する AWS パブリッククラウドのお客様にとって魅力的です。 as a Service 配信 – AWS Outposts のフルマネージドインフラストラクチャの配信により、運用が簡素化され、いくつかのオンプレミスのテクノロジーとの統合を含む、インフラストラクチャ管理に対する手間のかからない単一ベンダーアプローチが可能になります。 AWS サポート – Gartner のクライアントは、AWS のワールドワイドサポートおよびサービスチームにとても満足していると報告しています。 このようにリーダーとして選出されたことは、低レイテンシー、ローカルデータ処理、データレジデンシー、またはオンプレミスの相互依存関係を伴う移行を必要とするワークロードのための、クラウドのエッジにおける当社のイノベーションを反映していると考えています。AWS では、真に一貫したクラウドエクスペリエンスを実現するために、必要とする場所がどこであっても、同じ AWS インフラストラクチャ、AWS サービス、API、ツールを提供します。 ワークロードが、 AWS リージョン 、メトロエリア (AWS Local Zones を使用)、オンプレミス (AWS Outposts を使用)、通信ネットワーク ( AWS Wavelength を使用)、またはエッジ (AWS Snow Family を使用) のいずれで実行されているかにかかわらず、すべてのアプリケーションのために同じクラウド運用モデルを標準化できます。継続的インテグレーションと継続的デプロイ (CI/CD) パイプラインの共通セットを標準化することで、デベロッパーのワークフローを合理化できます。また、IT インフラストラクチャの管理に必要な時間、リソース、運用リスク、メンテナンスのダウンタイムも削減されます。 加速されたイノベーションの例を挙げると、ML ワークロードのサポートを改善するために 最新世代の GPU 対応インスタンスを Local Zones に追加し、ロケーションの数を拡大しました。Outposts をより多くの国で利用できるようにし、Outposts でサポートされる AWS サービス ( AWS Elastic Disaster Recovery や Amazon Route 53 Resolver など) を追加して、 より容易な移行 と ディザスタリカバリ を実現し、アプリケーションの可用性を高め、パフォーマンスを改善しました。 さらに、Kubernetes コントロールプレーンとノードの両方をローカルで実行できるようにすることで、Outposts でのコンテナベースのワークロードの切断耐性を高め、マルチラック Outposts デプロイのために機能を強化しました。 詳細については、完全な 2024 年の Gartner Magic Quadrant for DHI レポート にアクセスしてください。 – Channy 原文は こちら です。 Gartner は、その調査出版物に記載されているベンダー、製品、またはサービスを推薦するものではなく、最高評価または他の認定を受けたベンダーのみを選定するようテクノロジーユーザーに助言するものでもありません。Gartner の調査出版物は、Gartner の調査組織による見解で書かれたものであり、事実を表明するものではありません。Gartner は、本調査に関して、明示または黙示を問わず、商品性または特定目的適合性に関する保証を含め、一切の保証を放棄します。 GARTNER は Gartner の登録商標およびサービスマークであり、Magic Quadrant は Gartner, Inc. および/またはその米国および他国の関連会社の登録商標であり、許可を得て使用されています。All rights reserved.

本稿は、2024 年 11 月 18 日に IBM &amp; Red Hat on AWS Blog で公開された “ Live Migration of Virtual Machines (VMs) with OpenShift Virtualization on ROSA and Amazon FSx for NetApp ONTAP ” を翻訳したものです。 私たちは、既存のパラダイムに挑戦する革新的なテクノロジーに度々直面します。アップストリームの KubeVirt プロジェクトをベースに構築された OpenShift Virtualization は、まさにそのような技術の一つです。 OpenShift Virtualization により、組織は従来の仮想マシン (VM) とコンテナ化されたアプリケーションを統一されたプラットフォーム上で同時に実行できます。これは特に、完全な刷新なしでモダナイゼーションを必要とするレガシーアプリケーションを持つ企業にとって価値があります。Kubernetes をコントロールプレーンとして使用することで、スケーラビリティ、自己修復、一貫した管理といった大きな利点が得られます。すでに OpenShift に投資している組織にとって、この統合は既存のツールとワークフローを活用できるため、運用が簡素化されます。これはまた、クラウドを活用してワークロードを Amazon Web Service (AWS) に移行し、その後クラウド上でビジネスをさらにモダナイズするお客様にとっても魅力的です。OpenShift Virtualization は VM を AWS に移行し、OpenShift と AWS のネイティブサービスを使用して進化させるためのリフト＆シフトアプローチを提供します。 OpenShift Virtualization は、追加のライセンスやサブスクリション費用なしで OpenShift に含まれています。AWS では、マネージドOpenShift である Red Hat OpenShift Service on AWS (ROSA) 上で実行でき、VM とコンテナ化されたアプリケーションを管理するためのオーケストレーション機能を活用できます。この統合により、チームは VM とコンテナの両方に対して同じ管理ツールとプラクティスを使用でき、運用の効率化と合理化が図れます。 コンテナオーケストレーターで VM を実行するアプローチは、アプリケーションを展開する際の柔軟性の増大するニーズに対応しています。組織は、別々のインフラストラクチャ環境を管理する必要なく、特定のワークロードの要件に基づいて VM とコンテナの両方を実行できます。 Amazon FSx for NetApp ONTAP は、ONTAP の一般的なデータアクセスと管理機能を備えた、AWS 上のフルマネージドの共有ストレージを提供します。FSx for ONTAP では、顧客アカウント内にストレージコンピュートノードまたは接続ストレージを追加する必要があります。ストレージのスケーリングと回復性は、顧客アカウントにエンドポイントのみが表示されるサービスチームアカウント内で実現されます。これにより、基盤となるインフラコストと、回復性を実現するための アベイラビリティゾーン （AZ）間のデータ転送コストが削減されます。FSx for ONTAP は、NetApp Trident をストレージオーケストレーターとして使用することで、OpenShift 上で実行されるアプリケーションや VM で利用できます。 ソリューションの概要 以下では、FSx for ONTAP を ROSA クラスターのデフォルト StorageClass として設定し、その後 FSx for ONTAP ストレージをボリュームとして利用するVMを作成する方法について見ていきます。また、ゲスト認証情報を使用して VM に接続する方法と、VM を現在のノードから新しいノードへライブマイグレーションを実行する方法についても説明します。 前提条件: AWS アカウント Red Hat アカウント ROSA クラスターの作成とアクセスのための 適切な権限 を持つ IAM ユーザー AWS CLI ROSA CLI OpenShift コマンドラインインターフェース (oc) Helm のインストール (ベアメタルのワーカーノードが 2 つ以上ある環境) ROSA クラスターにインストールされた OpenShift Virtualization 以下の図は、複数の AZ にデプロイされた ROSA Hosted Control Plane（HCP）クラスターを示しています。ROSA クラスターでは、コントロールプレーン（マスター）ノードはサービスチーム内にあります。一部のワーカーノードは OpenShift Virtualization をサポートするためにメタルインスタンスタイプとなっています。FSx for ONTAP ファイルシステムは同じ VPC 内にデプロイされています。NetApp Trident プロビジョナーは ROSA クラスターにインストールされており、この VPC のすべてのサブネットがファイルシステムに接続できるようになっています。OpenShift Virtualization は、OpenShift OperatorHub からオペレーターを使用してインストールされています。 ROSA と FSx for ONTAP のアーキテクチャ Trident CSI ドライバーのセットアップ デフォルトの StorageClass が trident-csi に設定されていることを確認してください。 次の yaml ファイルが StorageClass の作成に使用されました。 apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: trident-csi provisioner: csi.trident.netapp.io parameters: backendType: "ontap-nas" fsType: "ext4" allowVolumeExpansion: True reclaimPolicy: Retain 新しい OpenShift StorageClass StorageClassを作成する前に、以下の yaml ファイルがシークレットと ontap-nas ドライバーを使用したバックエンドオブジェクトの作成に使用されました。 apiVersion: v1 kind: Secret metadata: name: backend-fsx-ontap-nas-secret namespace: trident type: Opaque stringData: username: vsadmin password: apiVersion: trident.netapp.io/v1 kind: TridentBackendConfig metadata: name: backend-fsx-ontap-nas namespace: trident spec: version: 1 backendName: fsx-ontap storageDriverName: ontap-nas managementLIF: dataLIF: svm: credentials: name: backend-fsx-ontap-nas-secret デフォルトの VolumeSnapShotClasses が以下のように設定されていることを確認してください 以下の yaml ファイルが VolumeSnapshotClass の作成に使用されました kind: VolumeSnapshotClass metadata: name: fsx-snapclass driver: csi.trident.netapp.io deletionPolicy: Delete ボリュームスナップショットクラス デフォルト値が設定されていない場合、コンソールまたはコマンドラインから以下のように設定できます oc patch storageclass trident-csi -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class": "true"}}}' oc patch VolumeSnapshotClasses fsx-snapclass -p '{"metadata": {"annotations": {"snapshot.storage.kubernetes.io/is-default-class": "true"}}}' OpenShift Virtualization でテンプレートから仮想マシンを作成する テンプレートから VM を作成するには Web コンソールを使用します。 ステップ 1: Red Hat OpenShift Virtualization コンソールから、VM を作成します。クラスター上で利用可能なテンプレートを使って VM を作成できます。 テンプレートから VM を作成 ステップ 2: VM のオペレーティングシステムを選択します。 この一覧から Fedora VM テンプレートを選択しています。 VM テンプレートの選択 ステップ 3: VM の詳細設定: VM に名前を付けた後、 Customize Virtual Machine をクリックします。 Disks タブを選択し、 Add disks をクリックします。ディスクの名前を変更し（分かりやすい意味のある名前を推奨）、StorageClass に trident-csi が選択されていることを確認します。 Save をクリックします。 Create VirtualMachine をクリックします。 VM の設定 ステップ 4: VM に接続されるストレージの定義: VM ストレージ ステップ 5: 前のステップで作成した StorageClass を使用して共有ストレージを追加します: FSx for ONTAP ストレージを VM に追加 数分後、VM は実行状態になります。 VM ステータス 接続されたストレージの確認: ストレージの確認を行います。まずディスクを確認し、次にファイルシステムを確認します。VM のファイルシステムには、パーティション、ファイルシステムの種類、マウントポイントが表示されます。 ディスク ファイルシステム VM 用に 2 つの PersistentVolumeClaim (PVC) が作成されます。1 つはブートディスク用、もう 1 つはホットプラグディスク用です。 PersistentVolumeClaim (PVC) PersistentVolumeClaim (PVC) の詳細を見ると、ボリュームは Trident-CSI ドライバによって提供されている事、そして shared または ReadWriteMany として設定されている事がわかります。 PersistentVolumeClaim (PVC) の詳細 VM の OS 内部から確認してみましょう。 ステップ 7: Web コンソールを開く ボタンをクリックして VM に接続し、 Guest の資格情報を使ってログインします。 VM コンソールを開く ステップ 8: 次に、使用されているディスク容量を確認し、ファイルシステム上にテストファイルを作成します。 df dd if=/dev/urandom of=random.dat bs=1M count=10240 df df コマンドの出力 仮想マシンのライブマイグレーション ライブマイグレーションとは、実行中の VM を、通常の運用を中断したり、ダウンタイムを発生させたり、エンドユーザーに悪影響を与えたりすることなく、あるホストから別のホストに移動するプロセスを指します。ライブマイグレーションは仮想化における重要な進歩と考えられています。実行中の OS、メモリ、ストレージ、ネットワーク接続を含む VM 全体を、現在のノードから移行先に移動することができます。 以下では、VM を現在のノードから新しいノードへライブマイグレーションする方法を見ていきます。FSx for ONTAP を介した共有ストレージのおかげで、VM が実行されている OpenShift ノードや AZ に関係なく、データにアクセスすることができます。 ステップ 9: 3 つのドットメニューの下にある Migrate をクリックします。 VM マイグレーション Overview タブから、マイグレーションが成功したことがわかります。 VM マイグレーション完了のステータス マイグレーション後のストレージの確認 再度、 VirtualMachines タブから VM に接続し、VM OS 内からストレージの状態を確認するコマンドを実行します。 df ls ストレージの確認 VM が新しいノードで実行されているにもかかわらず、ストレージ、ファイルシステム、およびボリュームクレームを確認すると、これらの項目はすべて変更されていないことがわかります。 結論: OpenShift Virtualization と FSx for ONTAP を組み合わせることで、ハイブリッド環境の最適化を目指す組織にとって強力なソリューションが実現します。OpenShift Virtualization により、ユーザーは統一された Kubernetes プラットフォーム内で VM とコンテナ化されたアプリケーションの両方を管理でき、運用効率と柔軟性が向上します。一方、FSx for ONTAP は、OpenShift とシームレスに統合される、スケーラブルで高性能なストレージを提供し、データへの容易なアクセスと保護を確保します。 この組み合わせにより、企業はレガシーワークロードを効率的に管理しながら、アプリケーションのモダナイゼーションを進めることができます。単一の環境で多様なワークロードを実行できることで、チームは運用を効率化し、複雑さを軽減し、リソースの利用効率を向上させることができます。OpenShift Virtualization と FSx for ONTAP は、今日のダイナミックな企業環境の要求に応える堅牢なインフラストラクチャを提供し、イノベーションと成長を可能にします。 Trident の詳細については、 NetApp Trident ドキュメント を参照してください。NetApp ソリューションドキュメントの Red Hat OpenShift Virtualization セクション で補足情報と ビデオ を確認できます。 <!-- '"` --> Ryan Niksch Ryan Niksch は、アプリケーションプラットフォーム、ハイブリッドアプリケーションソリューション、およびモダナイゼーションに焦点を当てたパートナーソリューションアーキテクトです。Ryanは人生で様々な役割を経験してきており、物事を改善することへの情熱と、自分が関わったものを見つけた時よりも少しでも良い状態で残したいという願いを持っています。 Banumathy Sundhar Banumathy Sundhar はテクニカルマーケティングエンジニアとしての現在の役割と、テクノロジーイネーブルメント専門家としての過去の役割において、プラットフォームと製品の普及促進、技術分野の深い探求、ライブまたは録画デモの提供、情報共有、ブログやライブ・バーチャルのセッションを通じた教育とスキルアップを行ってきました。ハイブリッドクラウド環境において、OpenShift クラスターと統合された NetApp 製品によるソリューションの技術的検証を顧客向けに提供してきました。前職では、ハンズオンラボを中心としたコンテンツ、技術プレゼンテーション、認定試験準備セッション、カンファレンスやインストラクターサミットでのラボセッションなど、技術トピックに関する幅広いトレーニングを開発・提供してきました。 Mayur Shetty Mayur Shetty は、Red Hat のグローバルパートナーおよびアライアンス組織のシニアソリューションアーキテクトです。業界での経験は約20年に及び、 4 年間在籍した Red Hat では、OpenStack Tiger チームのメンバーとしても活動してきました。それ以前は、Seagate Technology でシニアソリューションアーキテクトとして、OpenStack Swift、Ceph、その他のオブジェクトストレージソフトウェアを活用したソリューションを推進していました。また、IBM では ISV エンジニアリングをリードし、Oracle データベース、IBM システムおよびストレージに関するソリューションの開発に携わりました。Sun Cluster ソフトウェアの開発や、Sun Microsystems の ISV エンジニアリングチームでも活動してきました。 翻訳はパートナーソリューションアーキテクト 豊田が担当し、監修はネットアップ合同会社の藤原様に協力頂きました。原文は こちら です。

本ブログは、 味の素食品株式会社 と Amazon Web Services Japan が共同で執筆しました。 味の素食品株式会社は半世紀以上にわたり、安全・安心な製品を提供するクノール食品株式会社、味の素グループの包装を主軸とした高い技術力を持つ味の素パッケージング株式会社、「ほんだし®」や「Cook Do®」といった製品を生産する味の素株式会社の食品生産部門を一つにし、味の素グループ国内最大規模の生産会社として、2019 年 4 月 1 日に誕生しました。 同社では製品の写真から自動で賞味期限を読み取る機能を実装しました。これにより、工程管理における賞味期限印字の正誤確認 (指図通りの賞味期限を印字しているか) の作業品質の向上と作業負荷軽減を実現しています。この機能を実現するための Amazon Rekognition をはじめとしたサービスを活用した事例を紹介いたします。 &nbsp; 課題 「賞味期限」や「消費期限」は、国内製品においては食品表示基準第 3 条、業務用加工食品は食品表示基準第 10 条により表示を義務付けられており、誤った表示や表示なし製品が外部流通 (外部倉庫や小売店または店頭) に並ぶと法令達反となり、大規模なクレームや製品回収に繋がる加工食品業におけるもっとも重要な品質管理点のひとつです。 賞味期限印字の照合は印字検査装置による全数検査を実施していますが、そもそも印字する賞味期限が指図された正しい賞味期限と一致しているかどうかは人の目でしか確認ができていない状況でした。人間の認知エラー撲滅は困難であり、作業者の目視検査支援によるより一層の作業品質の向上が必要でした。 ソリューション 味の素食品株式会社では作業品質向上や標準化を目的とした包装業務用の電子帳票アプリケーションを開発しており、このアプリケーションとモバイル端末のカメラを用いた実装を検討しました。 製品に印字される賞味期限のフォントや文字列は製品 SKU や生産ラインごとに異なり、生産ライン上で高速に印字される賞味期限は文字の形状が多少変化することもあります。そのため、一般的な画像検査で用いられるパターンマッチング型の画像照合機能を、複数の工場間で標準化された電子帳票アプリケーションに構築しようとすると、画像照合アプリケーション側に数千もの字体を登録する必要があり運用が現実的ではありませんでした。 そこで、味の素食品株式会社では以下のように Amazon Rekognition の TextDetection を用いて、現場担当者が持つモバイル端末で撮影した写真から賞味期限を判別するアプローチを採用しました。本システムは以下構成で、インフラストラクチャの管理、運用負荷の少ないマネージドサービスで構成されています。 本機能の流れは以下です。 クライアントから Amazon CloudFront 経由で Amazon S3 上にある Web アプリケーションコンテンツを取得 製品の写真を撮り、画像をアップロード 画像は Amazon CloudFront 経由で Amazon S3 に保存されオブジェクトキーが確定 賞味期限識別の API をオブジェクトキーを引数に呼び出し AWS Lambda を起動 オブジェクトキーを引数に Amazon Rekognition を起動 Amazon S3 から画像を取得し文字識別 Amazon Rekognition の識別結果を処理して Amazon S3 に保存 賞味期限文字列をクライアントに返却 なお、上記「9. 賞味期限文字列をクライアントに返却」については Amazon Rekognition が画像から抽出する文字群から”賞味期限と想定される文字列”を抜き出す処理が必要となるため (賞味期限の表記方法は “YYYY/MM/DD”、”MM.DD.YYYY” などの表記方法が認められています) 正規表現によるマッチングを AWS Lambda 側で行い識別精度を高める工夫をしています。 また、読み取り精度に加えてレスポンスタイムの評価も技術検証中に実施しました。 工場のネットワーク帯域という制限がある中で、Amazon Rekognition の識別に要する時間、また AWS Lambda の起動に要する時間 (特にコールドスタートになるタイミング) によって作業性を悪化させてしまうという懸念がありました。この懸念に対しては、求める目標値をすり合わせし、確実な目標値達成を確認するために、AWS のソリューションアーキテクトからサンプルコードを提供し、検証をご支援しました。結果的に、レスポンスタイムについても不満無く、導入していただくことができました。 Amazon Rekognition を組み込んだ電子帳票画面 照合 NG 時には画像のポップアップが表示されたのち (画像左) 照合 NG 部分が赤字で強調表示されて作業者に確認を促す (画像右) 導入効果 Amazon Rekognition の TextDetection を用いることで、フォントや文字の形状変化に左右されずに照合が可能となりました。検証段階では目標水準の読取精度を達成し、人の作業をサポートする品質を満たしていました。また、OCR ソフトでの読取が難しかった低解像度の IJP (インクジェットプリンタ) の文字も高精度に読み込むことができました。 1.5 mm × 2.5 mm の IJP 文字を高精度に読込可能 さらに、機能が API 化されているため、AWS 上に構築した電子帳票アプリへの組み込みが容易であったことも採用のポイントです。API の利用は 1 日に 100 回程度であり、組み込みの OCR ソフトを購入するよりもコストパフォーマンスが高いというメリットもありました。 製品に印字された賞味期限を Amazon Rekognition で読み取り、印字するべき賞味期限との照合をサポートすることで、人が見落としてしまうような賞味期限の設定間違いに対する照合品質が向上しました。また、読取文字列をテキストデータとして記録することで、記録の検索性も向上しました。 今後の展望 Amazon Rekognition で読み取れるフォントが想像以上に幅広であり、食品の製造業務で課題となっている食品原材料の荷姿外装からの使用期限の読み取りへの活用も検討中です。味の素食品株式会社は、今後も AI やクラウドサービスの活用を推進し、食品業界におけるイノベーションを続けます。 ソリューションアーキテクト 長谷川 大

本投稿は 2024 年 11 月 18 日に AWS Machine Learning Blog に投稿された Build cost-effective RAG applications with Binary Embeddings in Amazon Titan Text Embeddings V2, Amazon OpenSearch Serverless, and Amazon Bedrock Knowledge Bases &nbsp;を翻訳したものです。 本日、 Amazon Bedrock Knowledge Bases と Amazon OpenSearch Serverless における Amazon Titan Text Embeddings V2 用のバイナリ埋め込みの提供開始を発表できることを嬉しく思います。Amazon Bedrock でのバイナリ埋め込みと OpenSearch Serverless でのバイナリベクトルストアのサポートにより、Amazon Bedrock Knowledge Bases でバイナリ埋め込みとバイナリベクトルストアを使用した Retrieval Augmented Generation (RAG) アプリケーションを構築し、メモリ使用量と全体的なコストを削減することができます。 Amazon Bedrock は、主要な AI 企業が提供する様々な高性能な 基盤モデル (foundation models – FMs) にアクセスして使用するための単一の API を提供する完全マネージド型サービスです。Amazon Bedrock は、セキュリティ、プライバシー、責任ある AI を備えた 生成 AI アプリケーションを構築するための幅広い機能も提供します。Amazon Bedrock Knowledge Bases を使用することで、FM やエージェントは RAG のために企業の非公開データソースから文脈的な情報を取得することができます。RAG は、基盤モデルがより関連性が高く、正確で、カスタマイズされた応答を提供するために役立ちます。 Amazon Titan Text Embeddings モデルは、ドキュメント、段落、文章の意味的表現を生成します。Amazon Titan Text Embeddings は、テキスト本文を入力として受け取り、1,024 (デフォルト)、512、または 256 次元のベクトルを生成します。Amazon Titan Text Embeddings は、高速な検索向けの、低レイテンシを重視したエンドポイントの呼び出し (検索ステップ中での利用を推奨) と、高速なインデックス作成のための、スループットを重視したバッチジョブを通じて利用可能です。Binary Embeddings により、Amazon Titan Text Embeddings V2 は、データを各次元ごとに単一のバイナリ桁 (0 または 1) としてエンコードした、バイナリベクトルとして表現します。このバイナリ表現により、高次元のデータは、格納と計算においてより効率的な形式に変換されます。 Amazon OpenSearch Serverless は、Amazon OpenSearch Service の serverless デプロイメントオプションです。OpenSearch Serverless は、k-nearest neighbor (kNN) プラグインを使用してインタラクティブなログ分析、リアルタイムアプリケーションモニタリング、Web サイト検索、およびベクトル検索を簡単に実行できる完全マネージド型サービスです。exact および approximate nearest-neighbor アルゴリズムと、複数のストレージおよびマッチングエンジンをサポートしています。基盤となるインフラストラクチャを管理することなく、最新の機械学習 (ML) を活用した検索体験、生成 AI アプリケーション、および分析ワークロードを簡単に構築することができます。 OpenSearch Serverless kNN プラグインは、32 ビット浮動小数点ベクトル (FP32) に加えて、16 ビット (FP16) およびバイナリベクトルをサポートするようになりました。kNN ベクターフィールドタイプを binary に設定することで、Amazon Titan Text Embeddings V2 によって生成されたバイナリベクトルを低コストで保存できます。ベクトルは PUT および GET API を使用して OpenSearch Serverless に保存・検索が可能です。 この投稿では、Amazon Titan Text Embedings、Amazon Bedrock Knowledge Bases、および OpenSearch Serverless 全体にわたる新しいバイナリベクトルサポートの利点をまとめ、開始方法に関する情報を紹介します。以下の図は、Amazon Bedrock Knowledge Bases と Amazon OpenSearch Serverless を使用した概略的なアーキテクチャ図です。 OpenSearch Serverless と Amazon Bedrock Knowledge Bases において、検索品質の低下を最小限に抑えつつ、レイテンシーを短縮し、ストレージコストとメモリ要件を削減することができます。 私たちはバイナリ埋め込みを用いて、Massive Text Embedding Benchmark (MTEB) retrieval data set を実行しました。retrieval data set においては、ストレージを削減しつつ、レイテンシーを 1/25 に短縮する効果がみられました。バイナリ埋め込みは、最大精度 (float32) 埋め込みを使用した結果に対して、再ランキングありで 98.5%、再ランキングなしで 97% の正確性を維持しました。end-to-end RAG ベンチマークにおいては、Amazon Titan Text Embeddings V2 のバイナリ埋め込みは、最大精度埋め込みと比較して、再ランキングありで 99.1%、再ランキングなしで 98.6% の正確性を維持しました。お客様の環境でも、Amazon OpenSearch Serverless と Amazon Titan Text Embeddings V2 のバイナリ埋め込みを使用して、独自にベンチマークを実施することをお勧めします。 Hierarchical Navigable Small Worlds（HNSW）アルゴリズムにおいてバイナリベクトルを使用した OpenSearch Serverless のベンチマークでは、検索用の OpenSearch Computing Units (OCUs) が 50% 削減され、ユーザーのコスト削減につながることが明らかになりました。バイナリインデックスの活用により、検索時間が大幅に短縮されました。従来の検索方法は、リソースを大量に消費する可能性のある L2 距離やコサイン距離などの計算集約的な計算に依存することが多いですが、Amazon OpenSearch Serverless のバイナリインデックスは、より効率的なアプローチであるハミング距離を使用して検索を実行します。 以下のセクションでは、Amazon Titan Text Embeddings での バイナリ埋め込み、ベクトルエンジンにおけるバイナリベクトル (および FP16) と、 Amazon Bedrock Knowledge Bases での binary embedding オプションの使用方法について説明します。Amazon Bedrock Knowledge Bases の詳細については、「 ナレッジベースは、Amazon Bedrock でフルマネージド型の RAG エクスペリエンスを提供するようになりました 」をご覧ください。 Amazon Titan Text Embeddings V2 で Binary Embeddings を生成する Amazon Titan Text Embeddings V2 は現在バイナリ埋め込みをサポートしており、100 以上の言語のテキストサポートを備え、異なる次元サイズ (1024、512、256) における検索性能と精度が最適化されています。デフォルトでは、Amazon Titan Text Embeddings モデルは Floating Point 32 bit (FP32) 精度で埋め込みを生成します。1024 次元の FP32 埋め込みベクトルを使用することで、より良い精度を達成できますが、検索ユースケースではストレージ要件と関連コストも増大します。 コードでバイナリ埋め込みを生成するには、 Amazon Titan Text Embeddings V2 への invoke_model API リクエストに適切な embeddingTypes パラメータを追加します。 import json import boto3 import numpy as np rt_client = boto3.client("bedrock-runtime") response = rt_client.invoke_model(modelId="amazon.titan-embed-text-v2:0", body=json.dumps( { "inputText":"What is Amazon Bedrock?", "embeddingTypes": ["binary","float"] }))['body'].read() embedding = np.array(json.loads(response)["embeddingsByType"]["binary"], dtype=np.int8) 上記のリクエストのように、バイナリ埋め込みのみ、またはバイナリと fp32 の両方の埋め込みを要求することができます。得られる埋め込みは、以下のような 1024 の要素からなるバイナリベクトルです。 array([0, 1, 1, ..., 0, 0, 0], dtype=int8) 詳細とサンプルコードについては、 Amazon Titan Embeddings Text を参照してください。 Binary Vector Embeddings で Amazon Bedrock Knowledge Bases を設定する Amazon Bedrock Knowledge Bases を使用して、1 行もコードを書かずに、Amazon Titan Text Embeddings V2 の Binary Embeddings と Amazon OpenSearch Serverless のバイナリベクトルおよび Floating Point 16 bit (FP16) を利用することができます。以下の手順に従って作業を行ってください。 Amazon Bedrock コンソール で knowledge base を作成します。名前と説明を含む knowledge base の詳細を入力し、関連する AWS Identity and Access Management &nbsp;(IAM)権限を持つ新規または既存のサービスロールを作成または使用します。サービスロールの作成については、 Service roles を参照してください。 Choose data source で、以下のスクリーンショットのように Amazon S3 を選択します。 Next を選択します。 データソースを設定します。名前と説明を入力します。ソース S3 URI を定義します。 Chunking and parsing configurations で、 Default を選択します。続行するには Next を選択します。 埋め込みモデルを選択して knowledge base のセットアップを完了します。このチュートリアルでは、Titan Text Embedding v2 を選択します。 Embeddings type で Binary vector embeddings を選択します。 Vector dimensions で 1024 を選択します。 Quick Create a New Vector Store を選択します。このオプションは、binary データ型をサポートする新しい Amazon OpenSearch Serverless ストアを設定します。 作成後に knowledge base の詳細を確認して、データソースの同期ステータスを監視できます。同期が完了したら、knowledge base をテストして基盤モデルの応答を確認できます。 まとめ この投稿で説明したように、バイナリ埋め込みは Amazon Bedrock で利用可能な Amazon Titan Text Embeddings V2 モデルのオプションであり、OpenSearch Serverless のバイナリベクトルストアも利用できます。これらの機能により、Amazon Bedrock と OpenSearch Serverless のメモリとディスク需要が大幅に削減され、RAG ソリューションの OCU が少なくなります。また、パフォーマンスが向上し、レイテンシーも改善されますが、full float データ型 (FP32) を使用した場合と比較して結果の精度にある程度の影響があります。精度の低下は最小限ですが、アプリケーションに適しているかどうかを判断する必要があります。具体的な利点は、データ量、検索トラフィック、ストレージ要件などの要因によって異なりますが、この投稿で説明した例は潜在的な価値を示しています。 Amazon Open Search Serverless、Amazon Bedrock Knowledge Bases、および Amazon Titan Text Embeddings v2 でのバイナリ埋め込みサポートは、既にこれらのサービスが提供されている全ての AWS リージョン で本日から利用可能です。詳細と今後の更新については Region list をご確認ください。Amazon Knowledge Bases の詳細については、 Amazon Bedrock Knowledge Bases 製品ページをご覧ください。Amazon Titan Text Embeddings の詳細については、 Amazon Titan in Amazon Bedrock をご覧ください。Amazon OpenSearch Serverless の詳細については、 Amazon OpenSearch Serverless 製品ページをご覧ください。価格の詳細については、 Amazon Bedrock の料金 &nbsp;ページをご確認ください。 今すぐ Amazon Bedrock コンソールで新機能をお試しください。Amazon Bedrock に関するフィードバックは AWS re:Post または通常の AWS の連絡先を通じてフィードバックを送信してください。また、 community.aws で生成 AI ビルダーコミュニティにもご参加ください。 著者について Shreyas Subramanian はプリンシパルデータサイエンティストです。生成 AIと深層学習を用いた AWS サービスの活用による、お客様の事業課題を解決支援を行っています。大規模な最適化と ML、ML と強化学習を用いた最適化タスクの加速といった分野の経験を持っています。 Ron Widha は、Amazon Bedrock Knowledge Bases のシニアソフトウェア開発マネージャーです。簡単に拡張可能な RAG アプリケーションを構築できるよう、お客様を支援しています Satish Nandi は、Amazon OpenSearch Service のシニアプロダクトマネージャーです。OpenSearch Serverless に注力しており、ネットワーキング、セキュリティ、AI/ML の分野で長年の経験を持っています。コンピューターサイエンスの学士号とアントレプレナーシップの MBA を取得しています。余暇は、飛行機や ハンググライダーの操縦、バイクに乗ることを楽しんでいます。 Vamshi Vijay Nakkirtha は、OpenSearch Project と Amazon OpenSearch Service に従事しているシニアソフトウェア開発マネージャーです。主な関心事は分散システムです。

この記事は Optimize compute resources on Amazon ECS with Predictive Scaling (記事公開日 : 2024 年 11 月 21 日) の翻訳です。 導入 Amazon Elastic Container Service (Amazon ECS) は、AWS と深く統合され、簡単に利用可能なコンテナオーケストレーションサービスです。Amazon ECS は、あらゆる規模のコンテナアプリケーションのデプロイと管理を効率化します。Amazon ECS のリソースを効率的に管理する上で重要な機能の 1 つに、 サービスオートスケーリング があります。この機能を利用すると、 ECS サービス のタスク数を自動的に調整し、アプリケーションの需要の変化に効率的に対応することができます。 Amazon ECS と Application Auto Scaling の統合により、ターゲット追跡ポリシーまたはステップスケーリングポリシーを使用して、 Amazon CloudWatch メトリクスに基づく ECS サービスのオートスケーリングを設定できます。例えば、平均 CPU 使用率やターゲットあたりのリクエスト数、あるいはキューの深さなどの自分で設定した カスタムメトリクス に基づいてタスク数を自動で増減させることができます。また、スケジュールスケーリングを使用すると、予測可能なトラフィックパターンに対して、特定の時間にタスク数を増減させるプロアクティブなスケーリングを実現できます。 本日、Amazon ECS サービスオートスケーリングの新しいスケーリングポリシーである「 予測スケーリング 」を発表できることを嬉しく思います。このポリシーは、高度な機械学習 (ML) アルゴリズムを用いて需要の急増を予測するように設計されています。予測スケーリングでは、予測に基づいて前もってタスク数を増加させることでアプリケーションの可用性と応答性を向上させると同時に、過剰なプロビジョニングを削減することでコスト削減を実現します。このポリシーはターゲット追跡ポリシーやステップスケーリングポリシーと併用可能なため、リアルタイムの情報と過去のパターンの両方に基づいて、アプリケーションをスケールできます。この記事では、予測スケーリングの概要を説明し、この機能が役立つ場面や実際に予測スケーリングを設定する手順について解説します。 Amazon ECS における予測スケーリング ECS サービスのスケーリングにおいて、ターゲット追跡ポリシーとステップスケーリングポリシーは効果的ですが、これらは需要の変化を検出した後に動作するリアクティブなポリシーです。このことは、通常、緩やかな需要の変化に対しては大きな問題になりません。しかし、早朝の業務開始時のスパイクのように需要が急激に変化する場合、このようなリアクティブなスケーリングでは、スケーリングアクションが開始され、最適なキャパシティを確保するまでに時間がかかる可能性があります。初期化に時間がかかるアプリケーションの場合には、この時間がさらに長引く可能性があり、需要が急激に変化した際、一時的なパフォーマンス低下を引き起こす可能性があります。 その対策として、一部の利用者は、使用量のメトリクスに対して理想的な値よりも低い閾値を設定し、タスクをオーバープロビジョニングしています。これにより、トラフィックの急増に対応するためのタスクを余分に確保し、スケールアウト時の遅延を相殺します。また、利用者の中には、スケジュールスケーリングを使用して、予測される需要パターンに基づいたスケーリングを手動で設定している方もいます。しかし、スケジュールスケーリングを効果的に活用するには、トラフィックパターンとそれに対応するためのタスク数を手動で特定する必要があります。また、時間の経過とともにトラフィックパターンは変化するため、スケーリングの設定を定期的に調整する必要があります。そのため、実際の需要に対してリソースを最適化し、パフォーマンスの向上と運用コストの削減を実現するために、より効率的かつプロアクティブなスケーリングソリューションが必要とされています。 予測スケーリングを利用することで、需要の急増を予測して、前もってアプリケーションをスケールできるようになります。このアプローチにより、需要が増加する前に、新しいタスクを初期化するための時間を確保できます。予測スケーリングでは、高度な機械学習アルゴリズムを用いて、数百万のデータポイントからアプリケーション固有の需要パターンを継続的に学習することで、時間とともに、より正確な予測とカスタマイズされたスケーリング体験を提供します。このソリューションは、他のリアクティブなスケーリングポリシーと並行して機能するため、予測した需要変化とリアルタイムのメトリクスの両方を考慮した、より高い可用性を実現します。また、予測スケーリングは、予測に基づいたスケールインを実施しません。これは、予期せず需要が急増した際にも、必要なキャパシティを維持するのに役立ちます。スケールインについては、リアクティブなスケーリングポリシーまたはスケジュールスケーリングを利用してください。具体的には、Amazon ECS で予測スケーリングを使用する場合、以下のようなシナリオが想定されます。 複数のスケーリングポリシー (予測スケーリングとターゲット追跡スケーリングなど) を有効化した場合、それぞれが独立して必要なタスク数を見積もります。それぞれの見積もりの最大値が、最終的なタスクの必要数になります。 現在のタスク数が予測したタスクの必要数よりも少ない場合には、Amazon ECS はこれらの値が等しくなるように ECS サービスをスケールアウトします。 現在のタスク数が予測したタスクの必要数を上回っている場合には、Amazon ECS はサービスをスケールインしません。これは、実際に必要な値よりも少ない値を予測した場合にスケールインするのを防ぎ、常に必要なキャパシティを確保できるようにするためです。予測スケーリングと (ターゲット追跡ポリシーなどの) リアクティブなスケーリングポリシーの両方が、現在のタスク数よりも少ない値を見積もった場合にのみ、ECS サービスはスケールインします。 予測したタスクの必要数が、ECS サービスオートスケーリングにおけるタスクの最大数を上回っていて、かつこの上限を無視するオプションを選択している場合、ECS サービスオートスケーリングはその上限を超えてタスクを追加できます。この上限を無視するオプションを選択していない場合には、ECS サービスオートスケーリングは、これらの範囲を超えてスケールすることはありません。 予測スケーリングに関する推奨事項 予測スケーリングは、一貫したパターンに基づいて需要が急激に変化するアプリケーションに最適です。これには、ユーザーが特定の時間に利用開始することで急激なスパイクが発生するような日次や週次のパターンを持つユーザー向けのアプリケーションや、業務時間のパターンに従うような CI/CD ツールなどの社内アプリケーションが含まれます。リアクティブなスケーリングポリシーは、このような急激なスパイクに対して、通常、何回かに分けてスケーリングアクションを実行するため、最適なキャパシティを確保するまでに時間がかかります。この時間は、ロードバランサーへのタスクの登録やアプリケーションの起動、またデータレプリケーションなどの初期化ステップによって、さらに長引く可能性があります。また、予測スケーリングは、リアクティブなスケーリングポリシーが不適切なタイミングでスケールインしようとした際のセーフティネットとしても機能します。例えば、リアクティブなスケーリングポリシーが唯一考慮するリアルタイムのメトリクスは、差し迫った需要の急増を反映していなかったり、デプロイメントや障害などの影響を受けている可能性があります。具体的なユースケースを探るために、以下の例を考えてみましょう。 ワークロードは周期的なトラフィックパターンに従い、業務時間中はリソース使用量が増加し、夕方や週末には使用量が減少するという特徴を持つとします。このようなワークロードでは、予測スケーリングを用いてベースラインを設定することで、機械学習アルゴリズムを使用して過去のパターンを認識し、リソースをプロアクティブに管理できます。加えて、急激なスパイクに対しては、リアクティブなポリシーを併用して対処することが推奨されます。 ワークロードは、2 時間毎などの特定の時間感覚でオン/オフを繰り返すとします。このベースラインはスケジュールスケーリングで管理できますが、定期実行されるジョブの設定を定期的に分析し、スケーリングの設定を手動で調整する必要があります。予測スケーリングを使用すると、このプロセスを自動化し、手作業の必要性を減らし、適切な間隔で効率的なスケーリングを実現できます。 また、初期化に時間がかかるワークロードでは、リアクティブな方法で需要の変化に対応するのが難しくなります。初期化の時間は、特に営業日の業務開始時のような需要の急増において、最適化なキャパシティを確保するまでの時間に遅延をもたらします。また、大量の依存関係や静的なアセットを持つアプリケーションでは、これらの初期化の時間はさらに長引くことが想定されます。特定の時間パターンを示し、長い初期化プロセスを持つアプリケーションの場合には、予測スケーリングを設定することで、需要の変化に迅速に対応することが可能になります。 予測スケーリングの利用方法 予測スケーリングは、現在のオートスケーリングの動作を邪魔することなく利用開始できます。予測スケーリングポリシーには、「予測のみ」と「予測およびスケール」の 2 つのモードがあります。「予測のみ」モードでは、キャパシティの予測を生成するものの、実際にはスケーリングを実施しないため、普段の需要パターンを正確に予測できているか確認することができます。このモードは、本番環境の既存のスケーリング動作に影響を与えないため、予測スケーリングを初めて利用する際に最適です。 さらに、「予測のみ」モードで複数のポリシー (異なるメトリクスやターゲット値に基づいたポリシーなど) を作成することで、異なる設定を比較することができます。予測の精度を確認した後は、アプリケーションに最適なポリシーを選択して、「予測およびスケール」モードに移行できます。このモードに移行すると、予測スケーリングは積極的にスケーリングに関する意思決定を行い、予測される需要のスパイクに対して効果的に対応できるようになります。 ウォークスルー このセクションでは、これまで説明した予測スケーリングについて、その設定と構築に必要な手順を詳細に説明します。新しい ECS サービスを使用する場合は、予測を生成するために少なくとも 24 時間分のデータが必要です。また、予測の精度はデータが多いほど向上するため、理想的には 2 週間分のデータがあると望ましいです。 予測スケーリングや ECS サービスオートスケーリングを使用する前に、適切な使用量メトリクスとターゲット値を確認してください。例えば、計算負荷の高いアプリケーションであれば、CPU 使用率などが候補になります。最適な設定を見つけるには、ステージング環境で負荷試験を実施するのが良いでしょう。詳細は、 Amazon ECS 開発者ガイド を参考にしてください。すでにターゲット追跡またはステップスケーリングを設定している場合は、予測スケーリングにも同じメトリクスを使用してください。また、メトリクスのターゲット値を調整することで、パフォーマンスとコストのバランスを制御します。「予測のみ」モードを使用することで、現在の構成に影響を与えることなく、設定を調整できます。 1. ECS コンソールでは、新しく導入された「サービスの自動スケーリング (Service auto scaling)」タブを使用して、ECS サービスのスケーリングポリシーを確認、設定できるようになりました。ECS サービスの作成時にオートスケーリングを設定していない場合は、このタブからオートスケーリングを有効化できます。このウォークスルーでは、すでにターゲット追跡ポリシーを CPU 使用率 (60%) に対して有効化していると仮定して、そこに予測スケーリングを設定する方法を確認します。まず、「スケーリングポリシーを作成 (Create scaling policy)」をクリックし、予測スケーリングポリシーを作成しましょう。 図 1 : ECS サービスのオートスケーリング設定画面 2. 以下の設定例では、ECS サービスの事前定義済みのメトリクスである (平均) CPU 使用率を選択しています。追加設定の「起動前のキャパシティ (Pre-launch capacity)」から SchedulingBufferTime 属性を 600 秒に設定することで、スケールアウトアクションを (1 時間単位で) 予測した時刻の 10 分前に開始するように設定できます。 図 2 : 予測スケーリングの作成 最初は「予測のみ」モードを選択することをオススメします。これにより、実際に利用開始する前に、予測の精度と適合性を評価できます。 図 3 :「予測のみ」モードと「予測とスケール」モード 注 : 予測スケーリングは、ECS サービスの作成/更新画面からは設定できません。予測スケーリングを設定するには、ECS サービスを作成後、サービスの「サービスの自動スケーリング (Service auto scaling)」タブを使用してください。 3. 「予測のみ」モードで少なくとも 2 つのポリシーを持つことで、異なるメトリクス値を使用するポリシーを比較評価できます。ステップ 2 に戻って、異なるメトリクス値で予測スケーリングを設定してみましょう。例えば、以下のように複数のポリシーを設定できます。 図 4 : 複数の予測スケーリングポリシーの設定 4. ポリシーを作成すると、予測スケーリングは最大 14 日間の過去データを分析し、この先の 48 時間に対して 1 時間単位で予測を生成します。これらの予測は、6 時間ごとに CloudWatch の新しいデータで更新され、時間とともに精度が向上します。 5. 一定時間が経過すると、「レコメンデーション」タブでは、予測スケーリングポリシーに関する推奨事項が表示されます。ここでは、そのポリシーを使用することによるコストと可用性への影響を確認できます。これらの分析は、オートスケーリングの設定を最適化するのに役立ちます。また、すべてのポリシーが「予測のみ」モードで存在する場合、より高い可用性を低いコストで実現するポリシーに対して、「最適 (Best prediction)」タグが付与されます。「最適」としてタグ付けされたポリシーを、そのまま「予測およびスケール」モードに移行させることができます。 注 : 予測スケーリングの予測と推奨事項にアクセスするには、追加の IAM 権限 ( application-autoscaling:GetPredictiveScalingForecast ) が必要です。 図 5 : 予測スケーリングポリシーに関する推奨事項 6. 「チャートを表示 (View chart)」をクリックすると、実際のデータと予測値を比較して、予測モデルの精度を評価することができます。 図 6 : 予測スケーリングの実測値と予測値 (左 : 負荷、右 : キャパシティ) 7. 以下の ECS コンソール画面の例のように、予測スケーリングと動的なスケーリング (ターゲット追跡) ポリシーを組み合わせることで、ECS サービスを効果的にスケールできます。予測スケーリングはベースラインのキャパシティとして利用され、動的なスケーリングは現在の使用状況に基づいて追加のキャパシティを調整します。Amazon ECS は、スケジュールスケーリングを除いたすべてのポリシーが推奨するタスク数をそれぞれ計算し、その最大値をもとにスケーリングを実施します。 図 7 : 予測スケーリングと動的なスケーリングを組み合わせた設定 8. 「スケーリングアクティビティ (Scaling activity)」セクションでは、過去のスケーリングに関する詳細なビューが提供され、スケーリングポリシーの動作に関する洞察を得ることができます。 図 8 : ECS サービスのスケーリングアクティビティ一覧 まとめ 新しく導入された予測スケーリングは、リアクティブなスケーリングと組み合わせることで、予測した需要変化とリアルタイムのメトリクスに対応して、必要な数のタスクを確実に実行できるように機能します。これにより、可用性と応答性の高いアプリケーションを構築しながら、リソースを効率的に使用してコストを最適化できます。 予測スケーリングを利用開始する際は、まずは「予測のみ」モードを有効化して、実際にはスケーリングを行わず、予測したキャパシティについて可視化するところから始めましょう。これをもとに、適切なメトリクスを検討し、適切なターゲット値を調整することで、予測スケーリングポリシーを改善します。準備が完了したタイミングで「予測およびスケール」モードに移行し、予測したキャパシティに基づいて、ECS サービスをプロアクティブにスケールさせることができます。 この機能についてさらに詳しく知りたい方は、 Amazon ECS 開発者ガイドの予測スケーリングに関するセクション を参照してください。Amazon ECS コンソール、AWS SDK、または AWS CLI を使用して、ECS サービスの予測スケーリングを設定できます。 AWS コンテナサービスロードマップ にて、皆様からのフィードバックや提案をお待ちしています。

AWS re:Invent 2024 のカウントダウンが始まりました。2024年12月2日月曜日より、5日間にわたる恒例のイベントが米国ネバダ州ラスベガスで開幕します。 re:Invent 2024 では、AWS のリーダーによる 基調講演 が行われ、最新のクラウドと生成 AI（人工知能）のイノベーションが紹介されます。参加者は、テクノロジーのデモンストレーション、顧客およびパートナーによる セッション 、ゲーム化された学習イベントなど、盛りだくさんの Expo フロアを堪能することができます。 また、2024年12月2日午後7時（PST）からの「 Visionaries in the Stadium kick-off event 」や、2024年12月5日午後7時30分（PST）からの「 re:Play party 」など、ネットワーキングの機会も数多く用意されています。 AWS for Games の多彩なプログラムは、ゲーム業界における最大のトレンドや課題について活発な議論を促すように企画されています。セッションでは、Roblox、Riot Games、PUBG Studios、Epic Games、Supercell、Zynga、Hard Rock Digital などの AWS for Games のお客様が AWS サービスを活用してゲームやビジネスを拡張し、進化させている方法について詳しく説明します。 ゲーム業界のプロフェッショナルは、ベネチアンホテルの展示会場にある「AWS for Industries Pavilion」（580ブース）を訪れ、ゲームの未来を形作る AI ツールやその他のテクノロジーを実際に体験することができます。AWS for Games に関する多数のセッション、チョークトーク、ワークショップが予定されているため、私たちのチームでは、 re:Invent に参加するゲーム業界のお客様向けの厳選ガイド をまとめました。 これには、12月2日午後1時30分（PST）に開催される イノベーションセッション 「 MAE203-INT: Reinventing Entertainment 」も含まれます。このセッションは、AWS の Media &amp; Entertainment (M&amp;E), Games, and Sports のゼネラルマネージャーである Samira Panah Bakhtiar が担当します。 以下に、時系列順のハイライトとなるプログラムの一覧を記載します。また、まだの方は今すぐ AWS re:Invent に登録 してください。セッションタイトルの前に GAM と記載されているものは、AWS for Games re:Invent トラックの一部であることを示しています。 2024年12月2日(月曜日)&nbsp; (以下全て太平洋標準時(PST)で表記) 注目すべき講演者には、Riot Games Sr. Principal Software Engineer の Brian Miller 氏、Zynga Principal Software Engineer の Chris Vodak 氏および Engineering Manager の Ardrian Hardjono 氏、Supercell Sr. Cloud Governance Engineer の Toni Syvanen 氏、Epic Games Technical Director の Mattias Jansson 氏などが含まれます。AWS のエキスパートがリードするチョークトーク、ワークショップ、セッションでは、AI の活用による開発者の生産性向上やプレイヤー体験の改善など、さまざまなトピックを取り上げます。 9:00 AM – 10:00 AM: GAM307 : Effortless game launches: How League of Legends runs at scale on AWS 10:00 AM – 11:00 AM: GAM 305 : How generative AI can boost developer productivity &amp; player experience 10:30 AM – 11:30 AM: GAM308 : How Star Wars: Hunters got to the next level with Amazon GameLift 12:30 PM – 2:30 PM: GAM301-R : Build a scalable cross-platform multiplayer game backend on AWS 1:00 PM – 2:00 PM: GAM309 : How Supercell’s newest game launched with tens of millions of players 1:30 PM – 2:30 PM: GAM304-R/304-R1 : Cloud game development toolkit 1:30 PM – 2:30 PM: MAE203-INT : Reinventing Entertainment 2:30 PM – 3:30 PM: DAT336-S : How Hard Rock Digital built a multi-region sportsbook with CockroachDB (sponsored by CockroachDB) 2024年12月3日(火曜日)&nbsp;&nbsp; 以下のおすすめセッションのプログラムのハイライトでは、幅広いトピックを取り上げ、Epic Games の Technical Director である Mattias Jansson 氏と Roblox の Principal ML Engineer である Denis Goupil 氏によるプレゼンテーションが予定されています。また、AWS for Games のチョークトークでは、フルマネージドのグローバルゲームサーバーホスティングソリューションである Amazon GameLift の機能、アーキテクチャパターン、ベストプラクティスについて学ぶことができます。 10:30 AM -10:50 AM : GAM312: Scaling GPU infrastructure and using LLMs for Roblox’s metaverse 11:30 AM – 12:30 PM : CDN308: Amazon CloudFront: Enhancing web performance one HTTP request at a time 1:30 PM – 2:30 PM : GAM302-R: Host multiplayer games on Amazon GameLift with containers and anywhere 2:30 PM – 3:30 PM : DEV332: From chatbots to gamebots: Exploring AI’s potential in video games 3:00 PM – 4:00 PM : CMP338: Generative AI-enabled 3D avatar assistants on AWS 4:00 PM – 5:00 PM : CMP342: Scaling 3D content creation with open-source technologies 4:30 PM – 5:30 PM : GAM306: Scaling Epic’s Unreal Engine on AWS with Linux containers 2024年12月4日(水曜日)&nbsp;&nbsp; Roblox の Sr.Technical Director である Ivan Marcin 氏が、Amazon Bedrock を使用したマルチモーダルエージェントの構築方法を参加者に紹介する画期的なセッションを再び開催します。ゲームのプロフェッショナルは、ゲームのコンセプトストーリーボードの構築に生成AIを利用する方法を学ぶワークショップにも参加できます。 8:30 AM – 9:30 AM : GAM310: Scaling generative AI models for millions of users in Roblox 12:30 PM – 2:30 PM : GAM 303: Upgrade your game storyboards with multimodal prompt chaining 1:30 PM – 2:30 PM : GAM302-R1: Host multiplayer games on Amazon GameLift with containers and anywhere 2:30 PM – 3:30 PM : HYB307: Delivering low-latency applications at the edge 2024年12月5日(木曜日)&nbsp;&nbsp; 木曜日のプレゼンテーションでは、AWS Game Backend Framework の使い方を説明し、AWS アーキテクチャを進化させて、世界中で何百万人もの同時ゲームユーザーに対応する方法を紹介します。 11:30 AM – 12:30 PM: ANT344: Cost-effective data processing with Amazon EMR 12:30 PM – 2:30 PM: GAM301-R1: Build a scalable cross-platform multiplayer game backend on AWS 3:30 PM – 4:30 PM:&nbsp; GAM311: The evolution story of game architecture: PUBG: Battlegrounds, Krafton iOS または Android で AWS Events アプリをダウンロードすると、re:Invent で展示されるすべてのプログラム、ワークショップ、サービスを調べたり、重要なセッションの最新情報を入手したり、イベントを検索したりすることができます。 イベントまでの最新情報は、 AWS for Games ブログ および AWS for Games on LinkedIn をご覧ください。ラスベガスでお会いできることを楽しみにしています！ この記事は Level up game development insights at AWS re:Invent 2024 を翻訳したものです。翻訳はソリューションアーキテクトの鷲見が担当しました。

こんにちは。AWS マーケティング統括本部です。 2024 年 10 月 31 日、AWS AI Day が開催されました。本イベントでは、生成 AI の実用化に興味があるビジネス、テック、デベロッパーの皆様を対象に、生成 AI の実用化に向けた AWS の技術動向、お客様による活用事例の取り組みが紹介されました。会場またはオンラインでご参加いただいた皆様に改めて御礼申し上げます。 当日のセッション動画および資料が公開されておりますので、是非学習にお役立てください。（当日のタイムテーブル） アーカイブは こちら 基調講演 基調講演では、AWS が提供する生成 AI サービスの概要と支援、それらを活用して業務で実活用するためのアプリケーション構築方法について、生成 AI ジャーニーの各フェーズ(ユースケース選定、モデル選択、責任ある AI、カスタマイズ、アプリ運用)に沿って、AWS 安田、大渕が紹介しました。お客様事例では、三井物産株式会社 稲垣氏より生成 AI を活用した入札業務の効率化、株式会社Poetics 山崎氏より商談内容の記録と解析への活用について詳しく紹介があり、どちらの事例でも業務作業時間が大幅に削減できたことが強調されていました。また、Anthropic Frances 氏、Meta Hamid 氏も登壇し、最適なモデルサイズやオープンソースとしてのモデル提供の意義などについて語られました。 ビジネスリーダー向けトラック 本トラックでは、生成 AI の企業活用と、その際の課題解決や責任ある AI 実現に向けた取り組みについて 3 つのセッションが行われました。西日本電信電話株式会社 中井氏からは、グループ社員 3 万人に AI アシスタントを導入した取り組みについて、導入時の課題や工夫、ユーザーの反応などが紹介されました。株式会社ペライチ 安井氏からは、AI による Web ページ自動生成サービスの提供と、それによる中小企業のデジタル化への課題を解決する取り組みについて紹介がありました。最後に、AWS セキュリティエキスパートである吉田と保里が、生成 AI のセキュリティ対策と倫理的な利用について、各国の規制動向や AWS サービスで実践している責任ある AI について紹介しました。 テクニカルリーダー、デベロッパー向けトラック 本トラックでは、生成 AI を PoC の次のステップに進めるにはどうしたら良いか、をテーマに 3 つのセッションが行われました。AWS 石見からは、コンテンツ審査を題材とした生成 AI をプロダクトに実装する際の考慮点と具体的な対策(LLMと従来の棲み分け、精度改善、コスト最適化、可用性・スループット、速度、LLMOps)について解説がありました。株式会社セゾンテクノロジー 有馬氏、石原氏からは、自社サービスに関する AI アシスタントを Generative AI Use Cases JP(GenU) を活用して構築した事例が紹介されました。既存の高精度 RAG システムの活用や Amazon CloudWatch Dashboard を用いた対話分析ダッシュボード、情報の最新化方法など、様々な工夫が紹介されました。最後に、AWS 片山からは生成 AI アプリケーション開発におけるセキュリティ・コンプライアンスについて、 生成 AI Security Scoping Matrix や OWASP を元にした具体的な対策方法を説明しました。 SaaS 企業、デベロッパー向けトラック 本トラックでは、「SaaS における生成 AI 実装を DiveDeep する」をテーマに、AWS SA からの3つのエキスパートレベルのセッションとお客様による事例セッションが行われました。AWS 赤澤からは、マルチテナント環境下における生成 AI 活用のデザインパターンについてご紹介をしました。AWS 深見からは、RAG における検索基盤にフォーカスし、マルチテナントでの利用に必要な権限分離とユースケースごとの精度指標の考え方についてご説明をしました。AWS 松﨑からは、LLM 特有の脅威と実際の SaaS アプリケーション運用において、技術者が AWS サービスをはじめとした技術でどのような防御が可能かの紹介を行いました。最後に、国内 SaaS ベンダーによる生成 AI 実践事例として、株式会社Works Human Intelligence VP of Technology 加藤 文章 氏から大企業向け SaaS での生成 AI 活用において現実的にできることと課題についてご紹介いただくとともに、株式会社エクサウィザーズ 取締役 坂根 裕 氏から、生成 AI 応用システムのアーキテクチャと表現力をテーマに、デモを交えてセッションを実施いただきました。 [特別企画①] AWS Japan 生成 AI ハッカソン 決勝戦 本ハッカソンは「生成AIを活用して会社の仕事をもっと楽しく、楽に」をテーマに、3週間という限られた時間の中でゼロからアプリ開発を行いました。参加したのは選考を経て最終予選に参加した12組、40名。Amazon Bedrockを使用して開発された興味深い 12 個のアプリが誕生しました。業務効率を大幅に向上させるもの、上司と部下、同僚などの社員どうしのコミュニケーションを円滑化するもの、スキル向上を実現するものなど、その内容はさまざまですが、どれもが使いたくなる「楽しさ」を持っているのが特長です。どれもレベルが高く拮抗し、審査員のみなさんを悩ませましたが、決勝に進出する３組として * 楽しく学べる生成 AI システム「AI Tech Talkers」（アーベルソフト） * 求職者に寄り添い、転職エージェントの工数を削減する「AI 面接エージェントサービス」（パソナPDT） * クリップボードで AI 活用！「Ctrl + Cat」（チーム：mirAI Innovation Center（仮）） が選出されました。 これら 3 組が戦う決勝戦には QuizKnock 伊沢氏、鶴崎氏 がナビゲーターとして登場（お二人は最終予選でも審査員として全発表をつぶさに聞いています）。盛り上がる中にも緊張感のただようステージでは、各組がそれぞれに与えられた持ち時間 4 分間のプレゼンに全力をぶつけます。 見事優勝を勝ちとったのは「mirAI Innovation Center(仮）」（大日本印刷株式会社）の「Ctrl+Cat」。知りたいことをクリップボードに貼り付けて問い合わせるだけで、猫のキャラクターが楽しく教えてくれて、知識が蓄積されていくともに成長するAIアプリです。3週間でこの完成度はすばらしく、審査員の皆さんをうならせていました。 ◯ 緊急企画のお知らせ – 12/17（火）ハッカソン Meetup 開催 このたび、これらの上位入賞作品の技術的な深堀を行うミートアップ「AWS Japan 生成 AI ハッカソン Developer Meetup」を AWS 目黒オフィスにて開催します。優勝作品、準優勝作品を始め、詳細の紹介、デモなどを通じてこれらの作品がどのように作られているのかがわかる貴重な機会です。ぜひご参加ください！ 参加登録は こちら から [特別企画②] グローバルモデルプロバイダから学ぶ 本企画では、Anthropic、Meta の技術者に講演いただき、各社のモデルの特徴や最新情報をお話しいただきました。Anthropic Jason 氏による講演では、Claude 3.5 Sonnet(upgraded) モデルについて Computer Use 機能など詳細を説明し、活用事例や今後のロードマップについても触れました。また、Claude に対する皆様のフィードバックが Anthropic の研究開発にとって重要であることを強調しました。Meta Hamid 氏による講演では、Meta の AI 戦略として、オープンソースで提供する意義について、提供開発者がモデルを自由にトレーニングやファインチューニング、変更できる点などを強調しました。その上で、Llama モデルと Llama Stack の概要、選定すべき理由、Llama 3.2 の新機能などについて説明しました。また、PyTorch と Llama モデルの各種連携について詳細に説明しました。 [特別企画③] AWS ジャパン 生成 AI 実用化推進プログラム 本トラックでは、2024 年 7 月に発表した「 生成 AI 実用化推進プログラム 」をテーマに、プログラムの進捗と参加企業の取り組みについて発表を行いました。このプログラムは生成 AI を活用してビジネス課題を解決することを支援するもので、モデル開発と既存モデル活用の両方をサポートし、戦略策定から本番環境での活用まで支援を提供、総額 1,000 万 USドル規模の AWS クレジットを投資する取り組みです。AWS パートナーとの連携により実用化を加速します。 AWS の小林より、当初想定の50 社を超えた60 社以上がプログラムに参加していること、11月 15 日開催の「Generative AI Frontier Meetup」イベント、プログラムの申し込み期限延長が発表されました。プログラムのモデル利用者参加企業として株式会社テックウェイ 執行役員 滝沢雅広氏、キヤノン IT ソリューションズ株式会社 R&amp;D 本部言語処理技術部 蔵満琢麻氏、モデル開発者から株式会社野村総合研究所 生産革新センター AI ソリューション推進部 エキスパート研究員 岡田智靖氏の 3 名をお迎えし、各社の取り組みについてご紹介いただきました。当初 2024 年 11 月 22 日としていた締め切りが、好評につき 2025 年 2 月 14 日まで延長されましたのでぜひご登録ください。 展示コーナー 展示コーナーでは生成 AI を本番環境で活用されている 100 を超えるお客様の事例や、様々なユースケースを利用できるアプリケーションの GenU、生成 AI 実用化推進プログラムの概要など、7 つの展示を行いました。セッション終了後にも多くの方にお立ち寄りいただき、セッションで触れた内容の詳細や、生成 AI の実装について AWS 社員と会話し、それぞれの生成 AI ジャーニーについて理解を深めていただけました。展示コーナーで展示したコンテンツの一部は以下からアクセスいただけます。 日本の生成 AI 事例集 AWS ジャパン生成 AI 実用化推進プログラム GenU AI/ML に関する新しい AWS 認定 AWS Certified AI Practitioner AWS Certified Machine Learning Engineer – Associate その他参考サイト AWS ジャパン生成 AI 活用支援サイト

Amazon Relational Database Service (Amazon RDS) for SQL Server が、 Amazon Elastic Block Store (Amazon EBS) io2 Block Express ボリュームをサポートするようになりました。これらのボリュームは、高性能、高スループット、そして一貫して低レイテンシーを必要とするあらゆる重要なデータベースワークロードに対応するように設計されています。 io2 Block Express ボリューム は、99.999% の耐久性、最大 64 TiB のストレージ、最大 4,000 MiB/s のスループット、最も要求の厳しいデータベースニーズに対して最大 256,000 の Provisioned IOPS をサポートしており、EBS io1 ボリュームと同じ価格で提供されます。 この投稿では、Amazon RDS for SQL Server DB インスタンスで io2 Block Express ボリュームを使用するためのベストプラクティスを共有します。 io2 Block Express ボリュームを使用した適切な RDS DB インスタンスクラスの選択 RDS DB インスタンスのパフォーマンスは、インスタンスタイプとストレージタイプの組み合わせによって決まります。したがって、RDS DB インスタンスレベルと EBS ボリュームレベルの両方で適用される最大 IOPS とスループットの制限を知ることが重要です。高パフォーマンスなワークロードの場合は、 プロビジョンド IOPS SSD ストレージ (io2) と高性能の DB インスタンスクラスタイプ (X2iedn、R6i、R5b など) を組み合わせることをお勧めします。負荷の低いワークロードの場合は、 汎用インスタンスクラスタイプ (m5i/m6i) とストレージ (gp2/gp3) で十分かもしれません。 ワークロードに最適な組み合わせを決めるには、次の手順を実行してください。 アプリケーションのワークロードの IOPS とスループット要件を特定します。 CPU、メモリー、ネットワークパフォーマンス要件を満たす適切な RDS DB インスタンスクラスを選択します。 IOPS とスループット要件に基づいて、汎用ストレージまたはプロビジョニングされた IOPS ストレージのいずれかの適切なストレージタイプを選択します。 次の図は、IOPS スループット、およびキャパシティの要件に基づいて RDS DB インスタンスストレージの決定ツリーを示しています。 次のいずれかの条件が当てはまる場合は、io2 ボリュームを選択する必要があります。 アプリケーションには高い IOPS (16,000 IOPS 以上) が必要 一貫したパフォーマンスを実現するため、低レイテンシと高スループット (1,000 MiB/s 以上) が必要 ストレージ容量の要件は 16 TiB を超えている アプリケーションには高い耐久性と可用性 (99.999% の耐久性 SLA) が必要 ミッションクリティカルなデータベースまたは高パフォーマンスが持続的に必要なアプリケーションを実行している AWS リージョンでの io2 Block Express ボリュームの可用性を確認するには、この ドキュメント を参照してください。 io2 Block Express ボリュームの組み合わせのパフォーマンスは、選択した RDS DB インスタンスクラスとサイズによって異なります。次の表は、サポートされているさまざまな RDS インスタンスクラスにおける最大の RDS DB インスタンスサイズと、対応する io2 Block Express のパフォーマンス制限を示しています。 DB Instance Class Max throughput limit (MiB) Max IOPS limit (16 KiB I/O) Max DB instance size X2iedn 10,000 260,000 db.x2iedn.32xlarge R5b 7,500 260,000 db.r5b.24xlarge R6i/M6i 5,000 160,000 db.r6i.32xlarge R5d/M5d/Z1d 2,375 80,000 db.r5d.24xlarge db.m5d.24xlarge db.z1d.12xlarge R5/M5 2,375 80,000 db.r5.24xlarge db.m5.24xlarge Amazon RDS for SQL Server でサポートされている DB インスタンスクラスについては、「 Microsoft SQL Server の DB インスタンスクラスサポート 」を参照してください。サポートされているインスタンスレベルのベースラインスループット、最大 IOPS、最大スループットの詳細については、「 Amazon EBS 最適化インスタンス 」を参照してください。 サポートされているインスタンスとボリュームの組み合わせについては、AWS のアップデートと機能強化により制限が変更される可能性があるため、常に最新の AWS ドキュメントを参照してください。 SQL Server データベースの io2 Block Express ボリュームを使用した Amazon RDS への移行 io2 Block Express ボリュームを使用する RDS for SQL Server DB インスタンスへの移行プロセスは、gp2、gp3、io1 などの他のボリュームとよく似ています。主な違いは、io2 ボリュームでは、最大 64 TiB の大規模なデータベースワークロードを移行できることです。オンプレミスまたは Amazon Elastic Compute Cloud (Amazon EC2) インスタンス上で実行されている SQL Server データベースを Amazon RDS for SQL Server に移行する最も一般的な方法は、 Amazon Simple Storage Service (Amazon S3) を使用した SQL Server ネイティブのバックアップと復元です。詳細については、「 Amazon S3 を使用したバックアップと復元 」を参照してください。 大規模なデータベースの復元は時間がかかるプロセスです。しかし、フル \ 差分 \ ログバックアップ戦略を使用することで、カットオーバー時間を短縮できます。さらに、バックアップ圧縮と複数のバックアップファイルを使用すれば、バックアップと復元のパフォーマンスが向上します ( 詳細は、 Amazon RDS for SQL Server のネイティブバックアップと復元のパフォーマンスの改善 を参照 )。復元パフォーマンスを改善するには、RDS DB インスタンスのネットワークと EBS の帯域幅使用状況を監視することが重要です。ボトルネックが発生した場合は、インスタンスサイズを拡張するか、追加のストレージ IOPS とスループットをプロビジョニングして、より速く復元を完了させることを検討してください。 Amazon RDS for SQL Server の Volume タイプを io2 Block Express に変更 Amazon RDS for SQL Serverでは、汎用 (gp2/gp3) とプロビジョンド IOPS (io1/io2) ボリュームを切り替えることができ、パフォーマンス要件の変化に合わせて柔軟に対応できます。ボリュームタイプを切り替えることで、アプリケーションの要求に応じてコストとパフォーマンスのバランスを取ることができます。 AWS マネジメントコンソール または AWS コマンドラインインターフェイス (AWS CLI) を使用して、RDS for Server インスタンスのストレージタイプを gp2、gp3、io1 から io2 Block Express に変更できます。 ただし、io2 ボリュームを使用する場合は、1 つ重要な点を考慮する必要があります。io2 ボリュームを使用し、ストレージサイズが 16 TiB を超える場合、gp2、gp3、または io1 に戻すことはできません。このシナリオで gp2、gp3、または io1 に戻すには、gp2、gp3、または io1 ボリュームを持つ新しいインスタンスを作成し、SQL Server のネイティブバックアップとリストアを使用してデータベースを移行する必要があります。既存の RDS for SQLServer インスタンスのボリュームタイプを変更する際の技術的な詳細と手順については、「 Amazon RDS DBインスタンスのストレージを使用する 」を参照してください。 大規模な io2 ボリュームを使用した自動バックアップの管理 最初の RDS DB スナップショットは、DB インスタンスのストレージボリュームの完全なバックアップを取得します。同じインスタンスでの後続のバックアップは増分 DB スナップショットになり、最新のバックアップ以降に変更されたデータのみを保存します。ほとんどの場合、DB インスタンスの日次バックアップは迅速に完了します。これは、日次バックアップが増分であるためです。ただし、自動バックアップが無効になっていて、大量の作業負荷があるか、数日間バックアップが行われていない特定の状況では、増分 DB スナップショットに蓄積されたデータのために、次のバックアップの完了に長時間を要する可能性があります。データ変更量が 64 TiB に達すると、バックアッププロセスには最大 4 日かかる可能性があります。この間、インスタンスは完全に機能し利用可能な状態が維持されますが、インスタンスタイプの変更やシングル AZ から マルチ AZ への変換などのインスタンスレベルの変更は制限されます。 大規模なデータベースの長時間実行される DB スナップショットのリスクを軽減するには、次の手順を実行できます。 RDS DB インスタンスの 自動バックアップ を常に有効にしておくことを検討してください。これにより、最後の DB スナップショットからデータの増分変更が長期間蓄積することがなくなります。 大規模な RDS DB インスタンスの日次自動バックアップスナップショットの完了には時間がかかる場合があります。そのため、バックアップ保持期間を少なくとも 7 日間に設定することをお勧めします。これにより、次のバックアップウィンドウを逃した場合でも、DB インスタンスのバックアップが利用可能になり、ポイントインタイムリカバリ (PITR) が可能になります。 マルチ AZ インスタンスの場合、1 〜 2 か月ごとに計画的な手動フェイルオーバーを実行することをお勧めします。この予防措置により、マルチデプロイメントの健全性が維持され、予期しないフェイルオーバー後に発生する可能性のある長いバックアップ時間を回避できます。予期しないフェイルオーバーが発生した場合に、新しいプライマリがキャッチアップする必要があり、長いバックアップ時間が発生するリスクを最小限に抑えます。定期的にフェイルオーバーを実行することで、プロセスが円滑かつ効率的であることが確認でき、フェイルオーバー戦略を検証し、高可用性設定に自信を持つことができます。 自動バックアップ時間と手動スナップショットを使用した PITR の最適化 大量のデータロード直後に手動でスナップショットを取ることで、次の自動バックアップが最後のスナップショット以降の変更のみをキャプチャするだけで済むようになります。この予防措置により、その後の自動バックアップに必要な時間が大幅に短縮されます。これは、バックアップする必要があるデータ量が最小限に抑えられるためです。全体のバックアップ時間を短縮することで、ピーク時の RDS インスタンスのパフォーマンスと可用性を維持することができます。手動スナップショットの作成手順の詳細については、「 シングル AZ DB インスタンスの DB スナップショットの作成 」を参照してください。 さらに、この方法により PITR (Point In Time Recovery) のパフォーマンスも向上することがわかっています。 PITR 機能を使用 すれば、SQL Server インスタンスを EBS io2 Block Express ボリュームに特定の時点まで復元することができます。 DBスナップショットからの復元 コンソール、AWS CLI、または Amazon RDS API を使用して DB スナップショットから RDS DB インスタンスを復元 できます。復元された DB インスタンスのステータスが使用可能になると、すぐに使用を開始できます。ただし、復元された DB インスタンスはバックグラウンドでデータの読み込みを続けます。このプロセスは遅延ロードと呼ばれます。 まだロードされていないデータにアクセスした場合、DB インスタンスは即座に Amazon S3 から要求されたデータをダウンロードし、その後バックグラウンドで残りのデータのロードを続行します。この遅延ロード処理中は、ボリュームが Amazon S3 から完全に再ハイドレートされるまで、レイテンシの上昇とパフォーマンスへの影響が発生する可能性があります。 遅延ロードとフルテーブルスキャン (SELECT *など) のような回避策の詳細については、「 DB スナップショットからの復元 」を参照してください。 大規模なボリュームでストレージを拡張するための計画的なメンテナンス時間枠を設定 ストレージ容量を拡張する必要がある場合は、既存の DB インスタンスのストレージを拡張できます。これは Amazon RDS コンソール、Amazon RDS API、または AWS CLI を使用して行うことができます。ただし、ストレージのスケーリング中に Amazon EBS がストレージの最適化を行う ため、ボリュームのサイズによっては長時間かかる可能性があります。そのため、ストレージのスケーリングは計画されたメンテナンスウィンドウ中に手動で実行し、自動ストレージスケーリング操作の頻度を最小限に抑えることをお勧めします。 Amazon RDS 上の SQL Server の大規模な読み取りレプリカの最適化 プライマリインスタンスの負荷状況によっては、 Amazon RDS の SQL Server のリードレプリカ の作成に時間がかかる場合があります。大量の作業負荷が予想される場合は、リードレプリカの作成前に手動でスナップショットを取得することをお勧めします。この予防措置により、リードレプリカの作成に必要な時間を最小限に抑えることができます。 シングル AZ DB インスタンスをマルチ AZ DB インスタンスに変換 io2 Block Express を使用している RDS for SQL Server インスタンスをシングル AZ から マルチ AZ に変換できます。シングル AZ インスタンスをマルチ AZ インスタンスに変換するのに必要な時間は、RDS DB インスタンスのプライマリノードの負荷によって異なります。大量の作業負荷が予想される場合は、作業負荷が完了した後に手動でスナップショットを取ることをお勧めします。これにより、マルチ AZ に変換する前に増分 DB スナップショットが最新の状態になり、変換時間が最小限に抑えられます。 結論 IOPS とストレージの比率の制限、および IOPS とスループットのスケーリング方法を理解することで、パフォーマンス要件に合わせて io2 Block Express ボリュームを使用した RDS for SQL Server インスタンスのサイズを適切に設定できます。 AWS Nitro System インスタンスは、最大 IOPS とスループットの能力が高くなっています。 SQL Server インスタンスで大規模な io2 ボリュームを使用する場合は、次のことをお勧めします。 自動バックアップを有効にしたままにしておき、移行中でも DB スナップショットが 20TiB を超えないようにしてください。 バックアップが数日かかる可能性があるため、バックアップ保持期間を最低 7 日に設定して、十分な DB スナップショット履歴が確保できるようにしてください。 大量の作業負荷の後に DB スナップショットを手動で取得し、自動の日次バックアップでキャプチャされるインクリメンタル DB スナップショットのサイズを最小限に抑えてください。 大量の作業負荷がある場合のマルチ AZ の構成では、計画外のフェイルオーバー後に非常に大きなスナップショットが発生するのを避けるため、1 〜 2 か月ごとにフェイルオーバーを実行してください。 DB スナップショットから復元した後は、他のボリュームタイプと同様に、アプリケーションスクリプトを実行して ハイドレーション (遅延ロード) を迅速化してください。 スケジューリングされたメンテナンスウィンドウ中に手動でストレージのスケーリングを行い、64TiB ボリュームの最適化には長い時間がかかるため、自動ストレージスケーリング操作の頻度を最小限に抑えてください。 これらの推奨事項に従うことで、EBS io2 Block Express ボリュームを使用して大容量の RDS for SQL Server インスタンスのパフォーマンス、バックアップ、メンテナンスを効果的に管理および最適化できます。本番環境で使用する前に、io2 Block Express ボリュームを使用した RDS for SQL Server DB インスタンス上の SQL Server ワークロードに対して、徹底的なパフォーマンステストとベンチマークを実施することを強くお勧めします。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。 著者について Sudhir Amin は、Amazon Web Services のシニアソリューションアーキテクトです。ニューヨークを拠点に、さまざまな業界のお客様にアーキテクチャガイダンスと技術支援を提供し、クラウド導入を加速させています。彼はスヌーカーの大ファンで、ボクシングや UFC などの格闘技も好きです。また、世界で最も雄大な動物を間近で見られる、豊かな野生動物の生息地がある国々を旅行するのが大好きです。 Toby Xu は、Amazon Web Services の RDS チームでシニアプロダクトマネージャーを務めています。AWS に入社する前は、Oracle と Informatica でソリューションアーキテクトチームを率いていました。16 年以上にわたりデータベースとミドルウェア技術に携わってきた経験から、この分野に関する豊富な知識を有しており、ソフトウェアエンジニアリングの修士号を持っています。彼はクラウド技術に興味があり、革新的なソリューションを活用してお客様の目標達成を支援することに尽力しています。 Swarndeep Singh は、AWS のシニアソリューションアーキテクトです。彼は Amazon RDS チームで働き、商用データベースエンジンと SQL Server を専門としています。彼は　Amazon RDS での技術的課題に取り組むことを楽しみ、AWS のお客様と協力してカスタマイズされたソリューションを構築し、チームメイトと知識を共有することに注力しています。

はじめに 現在の経済環境では、コスト最適化が多くの企業の主要な優先事項となっています。企業が SAP を新規に導入、または最新バージョンに更新する際、SAP が実行される AWS サービスのコストを最適化できれば、その分のリソースを他のイノベーションに振り向けることができます。このブログでは、 SAP Lens for the AWS Well-Architected Framework のベストプラクティスを活用して、SAP ワークロードのコストと運用を最適化するためのインサイトと戦略を共有しています。 前提 開始する前に、目標を明確に設定し、総コストを算出し、 SAP on AWS 参考コストガイド を確認する必要があります。 SAP ワークロードが実行されているすべてのアカウントで、 AWS コストエクスプローラ を実行します。SAP で一般的に高コストとなるサービスは、 Amazon Elastic Compute Cloud (Amazon EC2) 、 Amazon Elastic Block Store (Amazon EBS) 、 Amazon Simple Storage Service (Amazon S3) 、Amazon EBS スナップショット、 Amazon Elastic File Store (Amazon EFS) などです。本ブログではこれらのサービスの最適化とコスト削減のベストプラクティスと指針を示します。 Amazon EC2 Amazon EC2 から始めましょう。SAP ワークロードで Amazon EC2 インスタンスを選択する場合は、必ず SAP 認定 Amazon EC2 インスタンス 上で SAP NetWeaver と SAP HANA インスタンスを実行してください。 #1 ワークロードに最適なインスタンスサイズの選択 ワークロードに最適なインスタンスサイズの選択 とは、ワークロードのパフォーマンスと容量の要件を満たす最小限のコストのインスタンスタイプとサイズを選択するプロセスです。 Amazon EC2 インスタンスのサイズ変更は、ビジネスピークと四半期末期間を含めた過去 3 か月間の実際の使用状況に基づいて行う必要があります。そのためには、 Amazon CloudWatch と SAP Early Watch Alert を使用して使用状況分析を行います。 AWS Compute Optimizer の拡張インフラストラクチャメトリクス機能を有効にすると、Amazon CloudWatch のデータ 3 か月分を利用して推奨事項を生成できます。(デフォルトでは、AWS Compute Optimizer は Amazon CloudWatch のメトリクス履歴を最大 14 日間保存し、それを使って推奨事項を生成します。) 推奨事項の精度を上げるため、SAP EarlyWatch Alert レポートと比較してください。 分析に基づき、実行中のインスタンスを適切な SAP 認定 NetWeaver または HANA インスタンスに置き換えてください。 注 : Compute Optimizer は一般に信頼できますが、SAP ワークロードに対して最適でない推奨を行う場合がたまにあります。特にアイドルの SAP アプリケーションサーバーの場合に発生する可能性があります。これは、Compute Optimizer がワーク プロセスによって使用される予約済みメモリを考慮していないためです。そのため、Compute Optimizer の推奨を SAP 認定 インスタンスと照合して最適なパフォーマンスであることを確認することをお勧めします。 #2 SavingsPlans を活用する SavingsPlans は柔軟な価格モデルを提供し、1 年間または 3 年間の時間ベースの課金コミットメントと引き換えに、オンデマンド価格と比較して最大 72 % の料金削減が可能です。 オンデマンドで実行中の Amazon EC2 インスタンスが存在するかを確認し、ワークロードとインスタンスの使用状況が安定している場合は、 SavingsPlans に追加してください (例: 3 年間の前払い SavingsPlans を利用すれば、バージニア北部でオンデマンドの u-3tb1 Linux インスタンスよりも 60 % 以上安価になります)。 AWS Trusted Advisor と AWS Cost Explorer は、現在の SavingsPlans の利用状況と推奨事項を示します。 予測可能なワークロードのオンデマンドコストを避けるために、これを定期的 (月に 1 回程度) に見直す必要があります。 #3 Amazon EC2 インスタンスファミリの標準化でディスカウントを最大化 インスタンスファミリの標準化によって、利用率を最大化し、予約管理に関連する作業負荷を最小化します。 SAP で認定されている Amazon EC2 インスタンスファミリーとタイプは多数あります。コストを最適化するには、インスタンスファミリーとタイプを標準化する必要があります。例えば、小規模インスタンス (ASCS、SCS、WebDispatcher など) には Amazon EC2 C6i または最新世代を、SAP アプリケーションサーバーには Amazon EC2 M6i または最新世代を、1TB 未満の HANA データベースインスタンスには Amazon EC2 R6i または最新世代を使用してください。 #4 非本番用の Amazon EC2 インスタンスの開始 &amp; 停止を自動化する 開発環境、トレーニング環境、サンドボックス環境、プロジェクト関連のインスタンスは、稼働時間の要件が低い (1 日数時間のみ、または特定の日付のみ) 場合や、プロジェクトサイクルでの役割が短期間のみである可能性がありますので、これらのインスタンスに予約インスタンスを購入するのは費用対効果が低くなる恐れがあります。この場合、稼働時間の要件に基づいてコストを削減するために、 AWS Systems Manager または SAP Landscape Management を使用し、インスタンスの開始・停止をスケジューリングすることができます。 非本番の SAP ワークロード インスタンスの起動と停止を自動化することで、AWS コストを削減できます。 必要な時だけインスタンスを動作させれば、使われていないインスタンスに支払う必要がなくなります。 #5 最新世代の Amazon EC2 インスタンスへの移行 新しい世代のインスタンスタイプに移行することで、SAP ワークロードの価格性能を改善できます。 理由は、新しい世代のインスタンスでは SAPS が高く、価格が低いためです。 その結果、同等の性能を実現するために、インスタンスの台数やサイズを少なくできるかもしれません。 または、同じサイズの最新世代のインスタンスタイプに変更することで、ワークロードの増加に対応できます。 たとえば、m5 ファミリから m6i ファミリに移行すれば、インスタンスタイプ、OS、リージョンによっては、CPU が最大 15 % 高速、メモリ帯域幅が最大 20 % 高速、ネットワーク帯域幅が 25 ~ 100 % 高速になります。 #6 使用されていない オンデマンド キャパシティ予約 (ODCR) を解除する オンデマンド キャパシティ予約を利用すると、任意の期間、特定のアベイラビリティーゾーンで Amazon EC2 インスタンスのコンピューティングリソースを確保できます。 特定のインスタンスタイプを使った SavingsPlans で ODCR (オンデマンド キャパシティ予約)を作成した場合、Amazon EC2 インスタンスを利用できるようにするためです。インスタンスのサイズ変更、Amazon EC2 インスタンスファミリーの標準化、または別のインスタンスタイプへの移行後は、既存の ODCR をキャンセルし、適切なサイズのインスタンスの新しい ODCR を作成する必要があります。たとえば、u-3tb1.56xlarge から r6i.32xlarge にインスタンスを変更する場合、前の ODCR をキャンセルし、r6i.32xlarge の新しい ODCR を作成する必要があります。 未使用の ODCR を定期的にチェックするプロセスを実装してください。 #7 RTO と RPO に応じて、 AWS Elastic Disaster Recovery を使用して DR アーキテクチャを最適化 AWS Elastic Disaster Recovery (AWS DRS) を使用すれば、組織は新しい災害復旧プランを AWS に素早く簡単に実装したり、既存の災害復旧プランを AWS に移行することができます。 ソースシステムをステージングエリアのレプリケーションサーバーにレプリケーションすることで、低コストのストレージ、共有サーバー、最小限の計算リソースを使用することにより、継続したレプリケーションを維持しながら、災害復旧コストを最適化できます。 必要な RTO および RPO が達成できる場合は、AWS DRS ( SAP アプリケーションサーバーとデータベース に該当する場合) を、アクティブ・アクティブではなくディザスターリカバリー (DR) に活用してください。 RTO と RPO のオプションが異なる場合は、 SAP on AWS システムの復旧性 を管理するための他のデザインパターンを評価することを検討してください。 #8 クラウドの柔軟性を活かして、必要に応じて一時的なシステムを構築する AWS Launch Wizard は、SAP HANA などのサードパーティのアプリケーションに必要な AWS リソースをサイジング、構成、デプロイするための手順付きのウィザードです。 必要に応じて、AWS Launch Wizard を使って Amazon Machine Image (AMI) (サポートされている OS バージョン向けのセキュリティ強化プロセスで構築されたもの) から一時的なシステム (SAP HANA ベース) を構築し、そのシステムを稼働したままにしたり、シャットダウンするのではなく利用してください。インスタンスをシャットダウンしている場合でも、ストレージコストが発生するためです。 また、 AWS Service Catalog のプロダクト を AWS Launch Wizard で作成できます。 これにより、AWS Launch Wizard 内で事前に定義された SAP アーキテクチャを直接プロビジョニングできるため、チームは時間を節約できます。 Amazon EBS (Elastic Block Store) の概要 SAP HANA Tailored Data Center Integration (TDI) の要件を満たすには、EC2 インスタンスで SAP HANA を実行する際の最低限の構成として、必ず SAP HANA on AWS の 認定ストレージ構成 を使用してください。 これにより、最適なパフォーマンスを実現し、SAP のストレージ KPI を満たすことができます。 #1 最新の Amazon EBS ボリュームタイプを使用する GP2 から GP3 ボリュームタイプに Amazon EBS ボリュームを移行すると、コストを最大 20 % 節約できます。 #2 IO2 よりも Amazon EBS GP3 ボリュームタイプを使用する Amazon CloudWatch から Amazon EBS IO2 ボリュームの IOPS 使用量をチェックしてください。 IOPS の使用率が 16,000 を下回る場合は、ボリュームを IO2 から GP3 に移行することを検討してください。 また、16,000 IOPS の制限をバイパスし、より高い IOPS およびスループットを実現するために、 GP3 ボリュームのストライピング を検討することもできます。 注意: プロビジョンド IOPS SSD (IO2) ボリュームタイプは、サブミリ秒のレイテンシー、高い IOPS、スループット、高い耐久性 (99.999 %) が必要なミッションクリティカルなワークロードに使用してください。 #3 使用されていないAmazon EBSボリュームを削除してAWSのコストをコントロールする AWS コンソールで切り離された Amazon EBS ボリュームを確認し、今後使用する予定がない場合は削除してください。 切り離されたボリュームは、「終了時に削除」のフラグがない状態で起動された終了した Amazon EC2 インスタンスから残されている可能性があります。 #4 AWS Backup または AWS Backup Agent を使用して直接 AWS S3 ストレージにデータベースをバックアップする AWS Backup または AWS Backup Agent を使って、データベースのバックアップとリストアを直接 AWS S3 に対して行えます (anyDB と SAP HANA の高可用性環境の場合)。 こちら の手順に従って設定してください。 EC2 上の SAP HANA では、 AWS Backup * および AWS Backint Agent for SAP HANA が利用可能です。 Oracle on EC2: Oracle Secure Backup (OSB) モジュール を利用してください。 Symantec Advanced Solutions (Symantec 高度ソリューション) データベース: AWS File Gateway を使用して、データを非同期的に転送します。 これにより、(Amazon EFS または Amazon EBS のいずれかで) バックアップを保持するための一時保存用のストレージコストを避けることができます。 #5 データベース以外のボリュームの EBS スナップショットを最適化する Amazon EBS ボリュームや Amazon EC2 インスタンスを含む、さまざまな AWS リソースのバックアップ、リストア、およびポリシーベースの保持を行うための集中管理型サービスである AWS Backup を使用してください。 データベースサーバー: ルートボリュームとバイナリボリュームのスナップショットを有効にします データとログのボリュームのスナップショットを無効にしますが、データベースのバックアップ (データベースツールを使用) が適切に行われている必要があります アドホックのデータおよびログボリュームのスナップショットを AWS Backup と併用すれば、大規模データベースのシステムリフレッシュを迅速化できます SAP アプリケーションサーバー: ルートボリュームとバイナリボリューム (/usr/sap) のスナップショットを有効にします Amazon S3 #1 データベースのバックアップスケジュールと保持期間を改善する (AWS Backup Agent を使ってバックアップを S3 に取る場合) プロダクション、ステージング、プレプロダクション、品質管理、開発、サンドボックス、プロジェクト環境ごとに、フルバックアップとインクリメンタルバックアップを組み合わせたバックアップスケジュールを設定します。 このスケジュールは、各環境での復旧ニーズと、復旧に必要なデータの新しさ・タイムリーさを考慮し、適切な保持期間に基づくものにしてください。 たとえば、30 日のデータ保持期間がある開発環境やサンドボックス環境では、月次の完全バックアップと週次の増分バックアップで十分です。また、必要に応じて、これらの環境を本番環境やその他の環境のバックアップからリストアすることができます。 #2 Amazon S3 でライフサイクルポリシーを有効化する Amazon S3 分析 – ストレージクラス分析 を利用し、ストレージアクセスパターンを分析して、適切なデータを適切なストレージクラス(上記で特定の保持期間を設定したクラス)に移行するタイミングを判断します。 環境ごとのリカバリー要件とデータ保持期間に基づいて、ライフサイクルポリシーを設定してください。例えば、本番環境のバックアップは 5-7 日間は Amazon S3 Standard に格納し、その後、5 日以上前のバックアップの復元の必要性が非常に低い場合は、Amazon S3 Glacier または Amazon S3 Glacier Deep Archive で 6 か月保持するなど、低コストの格納先に移行します。 #3 バックアップのバージョン管理を無効にする バックアップのバージョン管理を無効にし、セキュリティのために マルチファクター認証による削除 または vault ロック を有効にします。 #4 DR リージョンに低コストストレージを採用 ビジネス継続および災害復旧 (BC/DR) のため Amazon S3 クロスリージョンレプリケーション (CRR) が有効な場合、復旧時間目標 (RTO) および復旧ポイント目標 (RPO) に応じて、災害復旧 (DR) リージョンに Amazon S3 Glacier や Amazon S3 Glacier Deep Archive などの低コストストレージを採用してください。 #4 インターフェイスまたはアーカイブファイルの保存には Amazon EBS や Amazon EFS ではなく、Amazon S3 を活用する ライフサイクルポリシーとバージョン管理を実装することで、インターフェイスまたはアーカイブファイルの保存に Amazon S3 を活用してコストを削減できます。 AWS SDK for SAP ABAP を使えば、SAP ABAP プログラムから Amazon S3 のファイルにアクセスできます。 #5 Amazon S3 の AWS Private Link AWS Private Link は、VPC (Virtual Private Cloud)、サポートされている AWS サービス、オンプレミスのネットワークの間でプライベート接続を提供し、トラフィックをパブリックインターネットに露出させません。 これは Amazon VPC エンドポイント を利用して実現されます。 Amazon EC2 と Amazon S3 間の接続を確立するための 接続先 を設定します。 これにより、データ転送に AWS バックボーンネットワークを使用し、インターネット出口料金を回避できます。 接続先はそれ自体と接続先がアクセスを提供するリソースのリソースポリシーで保護できます。 ゲートウェイエンドポイント を使用すると、VPC 用のインターネットゲートウェイや NAT デバイスを必要とせずに VPC から Amazon S3 にアクセスでき、追加料金はかかりません。 #6 Amazon S3 を定期的に、また大規模プロジェクト後に整理する SAP のインストールとアップグレードでは、データベース、カーネル、プロファイル、SUM ディレクトリ、SAP ソフトウェアファイルの一時的バックアップを保存するために多くの Amazon S3 ストレージ容量が必要になります。 ライフサイクルポリシーを有効にして保持期間を設定するか、プロジェクト完了後に Amazon S3 バケットを整理するタスクをプロジェクト計画に組み込んでください。 Amazon EFS の利用 Amazon EFS は、サーバー間で共有する必要があるファイルシステムである SAP の “/usr/sap/trans”、”/sapmnt”、その他のファイルシステムに利用できます。 https://docs.aws.amazon.com/efs/latest/ug/lifecycle-management-efs.html #1 未割り当ての Amazon EFS を確認する 未割り当ての Amazon EFS があれば、中身を確認したうえで削除してください。 #2 ライフサイクルポリシーを有効にする Amazon EFS ライフサイクル管理 を使用して、/usr/sap/trans、SARA がアクセスするアーカイブ、SOX 関連ファイル、SAP ソフトウェア、SAP のインストールとアップグレードツール、バックアップなどの SAP のファイルストレージの経済的な管理を行うことができます。 Amazon EFS の Intelligent Tiering は、ワークロードのファイルアクセス状況を監視し、ファイルシステムの Infrequent Access (IA) ストレージクラスへのファイルを自動的に移行させるように設計されています。 #3 Amazon EFS を定期的にクリーンアップし、大規模なプロジェクトが完了した後にも行う SAP のインストールやアップグレードには、SAP ソフトウェアファイルや Software Provisioning Manager、Software Update manager などの SAP ツールを保存するために大量の Amazon EFS ストレージが必要になります。 結論 SAP と AWS のベストプラクティスに従って、SAP ワークロードのコストを最適化することは不可欠ですが、顧客にとっては難しい課題となります。 AWS Trusted Advisor や AWS Cost Explorer などの AWS サービスを利用すれば、SAP ワークロードのコストを分析・モニタリングしたり、Amazon S3 や Amazon EFS のライフサイクルポリシーや、SAP 向けに認定されたインスタンス種別やストレージ種別を確認したりできます。これらは、コスト最適化に重要となる分野です。 AWS コスト配分タグ を活用すれば、AWS のコストを細かいレベルで追跡して高額となる要因を特定することができます。 予算超過を防ぐ ためのプロセスとガバナンスを整備してください。 次のステップ 毎四半期 (または必要に応じて) 、 SAP Lens レビュー を AWS Well-Architected ツール (AWS WA ツール) で自助型のコスト最適化の観点から実施してください。AWS WA ツールの実行では、AWS テクニカルアカウントマネージャー (TAM) またはアカウントチームに支援を求めてください。 クラウドリソース管理サービス を実装し、コスト最適化を継続的に監視および改善してください。 ご質問やご確認事項がある場合は、AWS サポートまでお問い合わせください。また、分析中は AWS テクニカルアカウントマネージャー (TAM) または AWS ソリューションアーキテクトにご相談ください。 翻訳は Partner SA 松本が担当しました。原文は こちら です。

こんにちは ! テクニカルインストラクターの室橋です。気持ちの上ではまだゴールデンウィークぐらいのつもりで生活していたのですが、いつの間にかもう年末が近くなってきてしまいました。今年も残りわずかですね。体調に気を付けつつ、年末まで頑張りましょう！ AWS Cloud Quest の「Serverless Developer」ロールが日本語化されました ! AWS クラウドをゲームベースで学習できるコンテンツである「 AWS Cloud Quest (以下 Cloud Quest)」はご利用いただいておりますでしょうか ? Cloud Quest は 「ゲーム内でストーリーに沿って出題されるソリューション構築に関する課題を、実際の AWS のアカウントを使用しながら解いていく、RPG テイストのコンテンツ」 です。学習に使用する AWS アカウントは、ゲーム内で用意されるものを一時的に使用できるため、サービスの使用料金などは気にせず、学習に集中してご利用いただけます。「Cloud Quest をまだ知らないよ」という方は、 こちらのブログ にて詳しくご案内しておりますので、是非ご確認ください。 Cloud Quest の中には、様々なカテゴリ (ロール) の課題が含まれているのですが、 この度、ご要望の声が多かった「 Serverless Developer 」ロールについて日本語対応を行いました。 Serverless Developer ロールには 24 の課題 (一部他ロールと重複する課題もあります) が用意されており、AWS Lambda や Amazon API Gateway をはじめとしたサービスを組み合わせながらソリューションを構築可能です。「今までサーバーレスの学習には手を出しづらかった」と言われる方も、この機会に是非チャレンジしていただければと思います。 AWS Cloud Quest Serverless Develpoer ロールの課題画面より さて、この度日本語化された Serverless Developer ロールの課題と、その中で触れられるサービスについて、一覧を掲載いたします。 ※ 2024 年 11 月 20 日現在、Cloud Quest 内の情報をそのまま掲載します。今後課題やサービスについては変更される可能性もあります。 課題名 主な学習内容 クラウドコンピューティングの基本 Amazon S3 クラウド、はじめの一歩 AWS, Amazon EC2 コンピューティングの基礎 Amazon EC2 クラウドのコスト見積り Amazon EC2, Cloud Economics ネットワークの概念 Amazon EC2, Amazon VPC リレーショナルデータベースの実装 Amazon Relational Database Service (RDS) セキュリティのコアコンセプト AWS Identity and Access Management (IAM), Amazon Relational Database Service (RDS), Amazon EC2 リソースモニタリング Amazon CloudWatch, Amazon EC2 クラウド上のファイルシステム Amazon EC2, Amazon Elastic File System サーバーレス基盤 AWS Lambda RESTful API のデプロイ Amazon API Gateway, AWS Lambda API とデータベース Amazon API Gateway, AWS Lambda, Amazon DynamoDB シングルページアプリケーション AWS Lambda, Amazon DynamoDB, Amazon API Gateway, Amazon S3, Amazon CloudWatch クラウド開発環境のセットアップ Amazon S3, Amazon SageMaker Amazon Q Developer を使用した迅速なアプリケーション構築 Amazon CodeWhisperer, Amazon S3, AWS Lambda サーバーレスアプリケーションのテンプレート化 SAM, AWS CloudFormation, AWS Cloud9 NoSQL データベースの設計 Amazon DynamoDB, Amazon EC2 トリガー – データの集約 Amazon DynamoDB, AWS Lambda サーバーレスアプリケーションの統合 AWS Lambda, Amazon SQS データの並列処理 Amazon SNS, AWS Lambda, Amazon CloudWatch Gen AI を使用して画像認識システムを構築 AWS Lambda, AWS Cloud9, Amazon CodeWhisperer サーバーレスワークフローのオーケストレーション Amazon Rekognition, AWS Lambda, Amazon DynamoDB, Amazon Comprehend, AWS Step Functions API の段階的デプロイ Amazon API Gateway, AWS Lambda, SAM, AWS Cloud9, AWS CodeDeploy 継続的デリバリーパイプライン AWS CodePipeline, AWS CodeCommit, AWS CodeBuild, AWS CloudFormation, AWS Cloud9 興味のある内容が見つかりましたら、是非 Skill Builder のページ にアクセスして、Cloud Quest の Serverless Developer ロール (要サブスクリプション) にチャレンジしてみてください。「いきなりサブスクリプションは敷居が高い」と思われる方には、 無料でプレイ可能な Cloud Practitioner ロール もご用意しておりますので、まずは無料で学習を始めてみてください ! Skill Builder 自体への登録は無料で、AWS アカウントをお持ちでない方も登録、利用が可能です 。 その他、サーバーレス関連コースを多数ご用意しております AWS Skill Builder では、上記の AWS Cloud Quest 以外にも、Serverless 関連のコースを多数ご用意しております。下記にいくつか関連コースをピックアップしてみましたが、その他にも様々なコースをご用意しております。皆様の知りたい内容やニーズに合ったトレーニングを探して、是非知識を深めてみてください。 ■動画コンテンツ: Getting into the Serverless Mindset (Japanese) この 20 分ほどのコースでは、サーバーレスアーキテクチャとアプリケーションの構築に役立つサーバーレスコンセプトのキーについて説明します。 サーバーレスコンピューティングとそのイベント駆動型の指向によって、アプリケーション開発、タスクの並列化、および環境管理をどのように実行するのかを学びます。本コースは無料で登録、受講が可能です。 ■動画コンテンツ: Introduction to Serverless Development (Japanese) このコースでは、サーバーレスアプリケーションの開発を開始するのに役立つ重要なサーバーレスコンセプトについて説明します。サーバーベースの開発で既に使用されている開発のベストプラクティスが、サーバーレス開発にどのように適用されるか、およびサーバーレスアプリケーション開発用に開発プロセスを調整する方法を学びます。本コースも無料で登録、受講が可能です。 ■学習プラン: Serverless Learning Plan (Japanese) Learning Plan (学習プラン) には、特定のロールまたはソリューション向けのトレーニングコンテンツがまとめられています。この学習プランは「開発者が AWS でサーバーレスソリューションを設計するのを支援すること」を目的としています。このプランに含まれるトレーニングでは、サーバーについて意識することなくアプリケーションを構築、実行する方法を説明します。 ■セルフペースラボ: Introduction to AWS Lambda (Japanese) AWS Lambda は、イベントに応じてコードを実行し、コンピューティングリソースを自動的に管理するコンピューティングサービスです。このサービスを使用すると、新しい情報にすばやく対応するアプリケーションを簡単に構築できます。このセルフペースラボでは、イベント駆動型の環境で Lambda 関数を作成するために必要なステップを説明します。このラボの所要時間は約 45 分で、Skill Builder のサブスクリプション登録によりご利用いただけます。 ■セルフペースラボ: Event Driven Architecture with Amazon API Gateway, Amazon EventBridge and AWS Lambda (Japanese) このセルフペースラボでは API Gateway、EventBridge、Lambda を使用してイベント駆動型のサーバーレスアーキテクチャを構築します。サーバーレスアーキテクチャは、インフラストラクチャを管理することなく、アプリケーションとサービスを構築、実行するための手法です。こちらのラボも所要時間は約 45 分で、Skill Builder のサブスクリプション登録によりご利用いただけます。 ■試験準備コース: Exam Prep Standard Course: AWS Certified Developer – Associate (DVA-C02) (Japanese) AWS Certified Developer – Associate (DVA-C02) 試験では、AWS クラウドベースのアプリケーションの開発、テスト、デプロイ、デバッグについて、受験者の習熟度を検証します。このコースでは、試験のトピックの分野と、試験の準備方法を学びます。本コースは無料でご利用いただくことが可能ですが、ハンズオンラボや公式模擬試験を含むコース全体については、 Exam Prep Enhanced Course: AWS Certified Developer – Associate (DVA-C02) をご覧ください。 AWS Skill Builder にまだ慣れていない方は … AWS Skill Builder の利用自体が初めて且つ「コースの効率良い探し方を知りたい」という場合は、 AWS Skill Builder Learner Guide という学習者用のガイドもご用意しております。Skill Builder の操作方法や、利用可能な様々なタイプのトレーニングについてご紹介しておりますので、利用が初めての方はご参照ください。 さて、今年も残すところあとわずかとなりました。是非今年の締めくくりに！来年の学習開始に！ AWS Skill Builder や AWS Cloud Quest を使ってクラウドの学習をお楽しみください。

本記事は 2024 年 10 月 14 日に公開された “ Improving Utility customer experience and field service efficiency using generative AI ” を翻訳したものです。 導入 公益事業者は、私たちの家庭、企業、地域社会に不可欠なサービスを提供しています。世界のデジタル化、電化、資源の制約がますます進む中、彼らは前例のない課題に直面しています。 3 つの主要な課題が浮上しています。 インフラのモダナイズと拡張: 公益事業者は、グリーンエネルギー源を組み込み、廃棄物を削減し、環境への影響を最小限に抑えながら、増大する需要に応える持続可能なインフラに投資する必要があります。 現場業務の最適化: 競争の激しい市場では、リソースを最適化し、コストを管理する必要性が最も重要になっています。これには、高度なテクノロジーを使用してデータ収集、データ分析、計画、自動化を改善し、合理化して効率を向上させるための新しいアプローチが必要です。 顧客エクスペリエンスの変革: 公益事業者は、デジタル チャネルを通じてパーソナライズされたサービス、直感的なインターフェイス、リアルタイムのフィードバックを提供し、より応答性と効果を高めることで、進化する顧客の期待に適応する必要があります。 このような変化と複雑さを背景に、公益事業者は業務効率、顧客満足度、規制順守の間の微妙なバランスを管理しながらイノベーションを起こすというプレッシャーが増大しています。 顧客体験とフィールドサービス体験の向上 公益事業者が直面している継続的な課題の 1 つは、リソース計画と現場業務 (これには計画、監督、請負業者のワークフローが含まれます) の効率を向上させながら、優れた顧客サービスを提供することにあります。インフラの老朽化、資産の場所の分散性、異常気象などの環境要因により、従来のワークフローに改善が求められています。その結果、公益事業者はパフォーマンスの期待を満たすのに苦労することがよくあります。これに、一方ではテクノロジーに精通した現代の顧客の期待の高まり、もう一方では熟練した現場労働者の不足が加わり、私たちは厳しい嵐のような状況に直面しています。 公益事業者がどれだけ効率的に顧客サービスを提供できるかを測定する重要な指標は、問題解決または新しいサービス要求に平均して必要な訪問回数 (いわゆるトラックロール数) を分析することです。 First-Time-Fix-Rate (FTFR) は、企業が最初の訪問でジョブを完了する能力を把握するためによく使用される指標です。残念ながら、ほとんどの組織は FTFR を 80% レベルに維持するのに苦労しています。これは、トラックロールの最大 20% が潜在的に回避可能であることを意味します。このような避けるべき訪問は、二酸化炭素排出量の大幅な増加は言うまでもなく、顧客満足度スコアに悪影響を及ぼし、さらなるコストと生産性の損失につながる可能性があります。 非同期ワークフローと生成 AI の使用 革新的な AI を活用したビデオ ワークフロー ソリューションの大手プロバイダーである Vyntelligence (Vyn®) は、最前線の活動の複雑さに取り組むための新しいアプローチを開発しました。この投稿では、Vyntelligence ソリューションが非同期オーディオビジュアル キャプチャ、ガイド付きワークフロー、高度な生成 AI、およびコンピューター ビジョン (CV) テクノロジーをどのように組み合わせて、顧客エクスペリエンスを変革し、現場業務を合理化するかを検討します。 Vyn のアプローチの中心には、重要な洞察があります。公共事業などの物理インフラを管理する組織では、不確実な状況によって最前線の活動が妨げられることがよくあります。こうした組織にとって計画は不可欠ですが、その有効性は、その基礎となるデータと、複雑なワークロードや状況に適応する従業員の能力によって決まります。したがって、これらの課題に対処するための戦略は、人材の有効活用とデータの強化に重点を置く必要があります。 Vyn SmartVideoNotes® テクノロジーは、公益事業者がモバイル ワークフローを簡単に導入できるようにすることで、計画された作業と実際の作業の間のギャップを埋め、顧客、現場担当者、請負業者が作業前、作業中、作業後に詳細なコンテキスト情報を取得できるようにします。非同期のガイド付きビデオ ワークフローにより、関係者は、リアルタイムの同期対話やアクティブなインターネット接続を必要とせず、標準化された直感的な方法で自分のペースでタスクやプロセスに貢献できます。この柔軟なアプローチにより、効率的なコラボレーションが可能になり、情報不足、スケジュールの矛盾、リソースの制約、地理的障壁によって引き起こされるボトルネックが軽減されます。次に、構造化されたビデオ、および関連する音声データとユーザー入力データが Vyn ソリューション上で非同期的に分析および処理され、タイムリーな洞察と状況認識が提供され、より適切な意思決定と所要時間の短縮が促進されます。 ケーススタディ 顧客が新しいヒートポンプの設置または水漏れの修理を必要とするシナリオを想像してください。従来は、連絡先の電話番号に電話し、状況をよりよく理解するために時間のかかる込み入った質問に案内されることで連絡を開始していました。そして、これらの応答は、場所とタスクに関する十分なコンテキスト情報なしで技術者を派遣することになります。技術者の準備に役立つデータの不足がもたらす、適切な部品の欠如、作業範囲の誤解、サイトへのアクセスの問題などにより、5 ～ 10% の作業で複数回の訪問が必要になります。一部の公益事業者は、見積もりや作業範囲を準備するために複雑なコンテキスト データが必要なサービス リクエストに対して、公益事業者の技術者または営業担当者による作業前/設置前調査の訪問をスケジュールすることで、この問題に対処しています。このアプローチは、技術者が適切に準備され、効率的に作業を完了するために必要な知識を備えていることを確認するのに役立ちますが、訪問回数が多くなります。 　図 1: Vyn を使用した強化されたカスタマー エクスペリエンスとフィールド サービス ワークフロー Vyn® カスタマー セルフサービス ソリューション は、顧客と現場チームの負担を同様に軽減するように設計されています。顧客は、携帯電話で (ユーティリティのアプリ上で、またはアプリを使用しない Web キャプチャ メカニズムを通じて) ユーティリティから最前線のサービス リクエストを行うことができます。この合理化されたアプローチにより、運用チームと計画チームはダッシュボードでリクエストをリアルタイムに把握できるようになり、当面の問題を包括的に理解できるようになります。これにより、サービス リクエストを 360 度把握できるようになり、派遣前に訪問や次善のアクションを適切にカスタマイズできるようになります。 実際の視覚データに基づいて構築された CV モデルを使用することにより、Vyn ソリューションは、緊急性、複雑さ、問題の種類などの重要な側面に基づいてサービス リクエストにフラグを付け、スコアを付けることができます。さらに、生成 AI により、顧客の要求の口頭説明をすぐに要約することができ、言及された重要な問題、一般的な次のステップ、顧客の緊急性などの有用な洞察を抽出できます。 Vyn® Field Service Proof-of-Work ソリューションを使用すると、現場担当者は、工事前、工事中、工事後の構造化されたビデオ ワークフローをキャプチャして、どのように現場を特定し、作業範囲を設定し、公益事業者の求める品質と安全基準に応じてタスクの完了を証明するかを示すことができます。単一のフレームワーク内で、公益事業者は複数の目的を達成できます。 労働者が規制および安全手順に従っていることを確認する 品質保証 (QA) プロセスを迅速化および自動化する 作業後に再度 QA を訪問する必要がなく、作業が満足に完了したという証拠に基づいて請負業者に迅速に支払う 公益事業者は、経験の浅い現場作業員をリモートで監督し、訓練するために経験豊富な専門家をより適切に活用できるように、従業員を再編成することもできます。最前線での作業中に詳細なビデオ メモや現場のニュアンスを記録できる Vyn ソリューションの機能により、組織は従業員の専門知識を収集し、検索可能なタグ付きビデオの Vyn® データベース上にナレッジ マネジメント機能を構築することが可能になります。 ソリューションアーキテクチャ Vyn は、信頼性が高く、スケーラブルで安全な Software-as-a-Service (SaaS) ソリューションであり、さまざまなクラウドネイティブでサーバーレスのアマゾン ウェブ サービス (AWS) を使用して、インテリジェントなマルチメディア データのキャプチャ、消費、分析を行います。 Vyn ソリューションは、従来の機械学習 (ML) モデルと新しい大規模言語モデル (LLM) を組み合わせて使用し、正確なフィールド評価と予測を生成します。 ガイド付きビデオプロセス エンドユーザーは、ウィザードに似たガイド付きビデオ プロセスに取り組み、コンテキスト固有の質問をし、ビデオを録画し、画像をキャプチャし、必要に応じて定性的および定量的データも取得します。このインタラクティブなプロセスにより、ユーザーの応答、ビデオ コンテンツ、音声録音、および関連するメタデータをカプセル化する「SmartVideoNote®」 (SVN) が作成されます。 サーバーレス予測パイプライン Vyn の人工知能 (AI) 機能の中核は、サーバーレス予測パイプラインです。このパイプラインは SVN を入力として受け入れ、統合分析に基づいて包括的な評価を提供します。次に、個々のコンポーネントとワークフローを詳しく調べます。 ガイド付きプロセスを使用して新しい SVN が記録されると、業界をリードするスケーラビリティ、データ可用性、セキュリティ、パフォーマンスを備えた AWS オブジェクト ストレージ サービスを使用して、組織固有の Amazon S3 バケットに保存されます。 S3 バケットでは暗号化がデフォルトで有効に設定されており、アップロードされたオブジェクトは AWS Key Management Service ( AWS KMS ) を使用して保存時に自動的に暗号化されます。 Vyn は、Bring Your Own Bucket (BYOB) 統合パターンを使用します。顧客ごとに、予測パイプラインによるさらなる処理のために SVN およびその他の関連データを保存する S3 バケットが登録されます。 新しい SVN が登録された S3 バケットの 1 つに到着すると、Configurator Lambda 関数がトリガーされ、Vyn 設定に基づいて入力 SVN を処理するワークフローが決定されます。これにより、実行時のコンテキストとワークフローに基づいて、受信 SVN に関連するモデルと構成を選択する際の高いレベルの柔軟性が提供されます。 図 2: Vyn サーバーレス予測パイプライン Vyn は AWS Step Functions を 使用して、ML パイプラインのステートマシンとして知られる高度なワークフローを定義して実行します。特定のステートマシンが開始されると、 AWS Lambda 関数と Amazon Elastic Container Service ( Amazon ECS ) タスクの両方を含む一連のステップが順次または並列で実行されます。 ML モデル推論 これらの Vyn ワークフローには、次の ML 機能が含まれています。 LLM 推論: Lambda 関数を使用して、 Amazon Bedrock API を通じて LLM を呼び出し、主要な AI スタートアップ企業や AWS による高性能基盤モデルにアクセスします。これにより、堅牢なセキュリティ、コンプライアンス、プライバシー、責任ある AI 実践を備えた最先端の生成 AI 機能に確実にアクセスできるようになります。 Amazon Bedrock は、ISO、SOC、GDPR などの一般的なコンプライアンス標準の対象にもなっています。 従来の ML 推論: Amazon ECS タスクは、コンピューター ビジョン用の ResNet-50/YOLO や他の自然言語処理タスク用の BERT/Sentence Transformers などの従来の ML モデルを呼び出すために使用されます。 モデル推論がどのように機能するかを説明するために、消費者が自宅または敷地からの水漏れを報告するシナリオを考えてみましょう。従来の CV モデルは、現場で水溜まりの兆候を自動的に検出し、漏水の原因が敷地内の水道メーターなのか、それとも別の水源なのかを特定できました。これらのモデルは、水漏れが敷地内で発生しているか、敷地外で発生しているかを識別することもできます。これを補完するものとして、Amazon Bedrock API を通じてアクセスされる生成 AI モデルでレポートをさらに分析し、問題の重大度と緊急性を評価することができます。次に、これらのモデルは、消費者のレポートで提供された特定の詳細とコンテキストを考慮して、修理ジョブに適切な優先レベルを推奨できます。 Amazon ECS タスクと Lambda 関数は、その出力 (証拠フレームなど) を「生成データ」と呼ばれる専用の S3 バケットに保存します。このバケットは、SVN 識別子によって一意に識別されます。 出力処理とバックエンド処理 ワークフロー内のステップが完了すると、実行中のステートマシンはさまざまなモデル出力を結合し、単一のメッセージとして Amazon Simple Queue Service ( Amazon SQS ) キューに入れます。 Vyn AI 予測パイプラインは、バックエンド パイプラインによってサポートされています。このバックエンド パイプラインは、これらの SQS メッセージを処理し、Vyn 製品によって提供されるマルチメディア アーティファクト、ワークフローの詳細、コラボレーション、およびダッシュボード機能の側面を処理する役割を果たします。 結論 公益事業部門は、リソース計画と現場運営の効率を高めながら、優れた顧客サービスを提供するという重大な課題に直面しています。従来のワークフローは、老朽化したインフラストラクチャ、分散した資産の場所、環境要因によってストレスを受けており、遅延、誤解、フラストレーションを引き起こしています。 これらのハードルを克服するために、Vyntelligence は AWS の堅牢な基盤上で生成 AI および CV テクノロジーを使用した探索的アプローチを開発しました。 Vyn® ソリューションは、従来の ML モデルと最先端の LLM を組み合わせることで、正確で状況に応じた洞察を提供し、組織が顧客満足度、現場の生産性、そして最終的にはエンドツーエンドのエクスペリエンスを向上できるようにします。 行動喚起 Vyntelligence SmartVideoNotes® テクノロジーとソリューションについて詳しく知りたい場合は、 そのサイトにアクセスしてください 。AWS がエネルギーおよび公益事業の変革にどのように役立つかについて詳しく知りたい場合は、 エネルギーおよび公益事業の AWS についてお読みください。 本稿は、ソリューションアーキテクトの橋井 雄介が翻訳しました。原文は “Improving Utility customer experience and field service efficiency using generative AI” を参照してください。 Mayank Sharma Mayank Sharma は、企業の作業保証のためのビデオ インテリジェンス プラットフォームである Vyntelligence の最高データ責任者です。この役割では、顧客が品質、効率、安全性、持続可能性に関するビジネス成果を実現できるよう支援することに重点を置き、データ、製品、ソリューション戦略を推進する責任を負っています。彼は、データ分析、機械学習、プロセス最適化の専門知識を持つ経験豊富な技術者です。以前は、IBM TJ Watson Research Center の研究スタッフ メンバー、および Raymond James のデータ サイエンス部門責任者/技術担当副社長を務めていました。彼はデリー工科大学の技術学士号と、スタンフォード大学の博士号を取得しています。彼は研究者として広く出版しており、20 件の特許を取得しています。 Arun Anand Arun Anand は、ヒューストン地域に拠点を置くアマゾン ウェブ サービスのシニア パートナー ソリューション アーキテクトです。彼はエンタープライズ アプリケーションの設計と開発において 25 年以上の経験があります。彼は、エネルギーおよび公共事業セグメントの AWS パートナーと協力して、新規および既存のソリューションに対するアーキテクチャとベストプラクティスの推奨事項を提供しています。仕事以外では、アルンは読書、散歩、友人や家族のためにカクテルを作ることを楽しんでいます。 Mohit Mehta Mohit Mehta は、ロンドンを拠点とするスケールアップ企業 Vyntelligence のテクノロジー リーダーであり、AI 部門を率いています。彼はテクノロジーを活用してビジネス変革を推進し、AI 分野で影響力のあるソリューションを作成することに情熱を注いでいます。 Vyntelligence は、機械学習と生成 AI を活用して、現場およびサービスの専門家に対してニュアンスを含んだデータ駆動型の洞察を提供します。 Mohit は、数学、コンピューター サイエンスの上級学位、および経営革新と戦略の博士号を取得しています。

生成系人工知能 (AI) アシスタントである Amazon Q Developer は、AWS でのアプリケーション開発を加速するのに役立ちます。 Amazon Q を統合開発環境 (IDE) で使用する場合、ソフトウェア開発を支援します。 Amazon Q では、コードに関するチャット、インラインコード補完、新しいコードの生成、コードのセキュリティ脆弱性スキャン、言語の更新、デバッグ、最適化などのコードのアップグレードや改善を行うことができます。 Amazon DynamoDB は、大規模環境で 1 桁ミリ秒単位のパフォーマンスを実現するサーバーレス NoSQL データベースサービスです。 DynamoDB は、 AWS マネジメントコンソール またはプログラムで操作できます。 プログラムで作業する場合の一般的なアプローチは、 AWS CloudFormation や AWS Cloud Development Kit (AWS CDK) などの infrastructure as code (IaC) ツールを使用してテーブルを管理し、プログラミング言語 SDK を使用してテーブルにデータを読み書きする方法です。 Amazon Q はこれら両方を支援して、開発のスピードを向上させます。 本記事では、IaC を使用して DynamoDB テーブルを作成し、 Python and Boto3 を使用してテーブルに対して作成、読み取り、更新、削除 (CRUD) オペレーションを実行します (本記事の最後には、JavaScript と Java に関するその他の注意点も記載しています)。 Amazon Q がこれらのタスクの開発速度をどのように向上させるかを説明します。 (本記事は 2024/09/12に投稿された Faster development with Amazon DynamoDB and Amazon Q Developer を翻訳した記事です。) Amazon Q とのやり取り 今回のデモンストレーションでは、 Amazon Q Developer プラグインを IDE にインストール しました。 Amazon Q とやりとりする方法は次の 2 つです。 IDE の チャットパネル 。テキストバーに自然言語のリクエストを入力し、その応答を評価します。 IDE での インライン候補 。 編集中のソースコードファイルに自然言語コメントを追加し、Amazon Q が提供する提案を評価します。 Amazon Q で使用されるすべてのプロンプトが用意されているため、さらに詳しく説明できます。 生成 AI アシスタントは非決定的です。この演習を自分で繰り返しても、例と同じ出力が得られない場合がありますが、Amazon Q は引き続き有益であると確信しています。 自分で書いたコード (提案された Amazon Q コードも含む) の所有権はお客様にあります。 コードの提案を受け入れる前に必ず確認レビューを行う必要があります。また、コードが意図したとおりに動作するように編集が必要がある場合もあります。 DynamoDB テーブルの作成 AWS CloudFormation を使用してソリューションを作成していますが、このプロセスは AWS Serverless Application Model (SAM) CLI または AWS CDK でも機能します。 YAML CloudFormation テンプレートに DynamoDB テーブルを作成します。 このテーブルには、IoT デバイスからの温度値が格納されます。 Amazon Q に IDE のチャットパネルでこれを生成するように依頼しています。 チャットのリクエストと応答は、次のスクリーンショットに示されています。 推奨されたコードは理想的ですが、テーブルに IotDynamoDBTable という名前を付ける要件を忘れていました。 チャットパネルは会話形式で、以前のやりとりを記憶しているので、この追加要件を依頼できます。 提供されたソリューションは私たちが望むものなので、IDE のテキストファイルにコピーして受け入れます。 これにより、CloudFormation YAML を生成する時間を節約できました。 テキストファイルは好きなように編集できます。 global secondary index (GSI) や stream を追加するなどしてテーブルをさらに拡張したい場合は、次の 2 つの方法のいずれかを使用できます。 Amazon Q チャットパネルで会話を続ける テキストファイルにコメントを追加してAmazon Q からインラインレスポンスを受け取る この例では、Amazon Q がインライン候補を提供できるように、コメントを追加して、テキストファイルに既にある内容を拡張してみます。 提案が良ければ、受け入れて続けることができます。 このやりとりは次のアニメーションで確認できます。 CRUD オペレーションの実行 このセクションでは、Amazon Q の助けを借りて DynamoDB テーブルで CRUD オペレーションを実行する例を紹介します。 Create AWS Lambda 関数で実行されるコードのサンプルを作成し、イベントからすべてのレコードを読み取って DynamoDB テーブルに書き込みます。 イベントのレコードは Amazon Simple Queue Service (Amazon SQS) キューから生成されました。 チャットパネルに戻って始めましょう。 リクエストには、イベントの記録に関する詳細は記載されていませんでした。 この詳細がないため、Amazon Q は提案を作成しましたが、私たちが望んでいたものとはまったく異なります。 繰り返しますが、次の 2 つの選択肢があります。 チャットパネルで会話を続け、リクエストを明確にする コードをテキストエディターにコピーし、手動で変更を加える 変更が簡単なため、2番目のオプションを選択しました。 結果は次のスクリーンショットに示されています。 この修正を含めても、Amazon Q でこの関数を作成するほうが、手動で作成した場合よりも早くなります。 Read 今度は、テーブルから項目を読み込むようにコードを拡張します。 deviceId と readingTime の値がわかっているので、プライマリキーを使用して直接検索できます。 必要なものを説明するコメントを Lambda 関数コードに追加し、Amazon Q に推奨コードを提供させます。 これは次のアニメーションで確認できます。 Amazon Q の提案を受け入れました。 これには、更新する必要のあるプレースホルダー、つまり deviceID の値が含まれています。 これは簡単な変更で、テーブルから項目を読み込む方法を調べるために IDE を離れる必要はありませんでした。 Update 繰り返しになりますが、あるアイテムの deviceId と readingTime の値がわかっているので、それを更新したいと考えています。温度の値が 150 より大きい場合に限り、 badReading という値に true という属性を追加します。 テキストファイルにコメントを追加し、Amazon Q にサンプルを提供させます。 これは次のアニメーションで確認できます。 提案には更新用のプレースホルダーが含まれています。 これは間違いなく時間の節約になります。特に、この操作のドキュメントや例を調べる必要がある場合はなおさらです。 提案を受け入れ、 deviceId の値を更新して完成させます。 Delete 削除したい deviceId と readingTime の値がわかっています。 このリクエストをさらに詳しく説明するために、この操作が消費した容量と、削除前のアイテムの状態を返すように操作する必要があります。 テキストファイルにコメントを追加し、Amazon Q にサンプルを提供させます。 この結果は次のスクリーンショットで確認できます。 サンプルを受け入れ、プレースホルダーを更新してコードを完成させます。 クエリ操作の実行 DynamoDB クエリ オペレーションは非常に強力です。1 回のオペレーションで、パーティションキー値は同じでソートキー値が異なる一連の項目を取得したり、キー以外の属性でフィルタリングしたり、ソートしたり、制限したりできます。 これらは、これまで見てきた CRUD 操作よりも実装が複雑です。 この例では、特定の deviceId で昨日発生した温度測定値が 10 ～ 20 度のすべてのアイテムを返すクエリを実行したいと考えています。 対象となるのは、その条件を満たす最新の 5 つのアイテムだけです。 Amazon Q には、すばやく反復処理できる複数のサンプルが用意されています。 仕事を続けるための基盤として、最も良いと感じるものを選びます。 これは次のスクリーンショットで確認できます。 KeyConditionExpression は正しいですが、 readingTime には定数値があります。 これを手動で改善するか、コメントを改善して再試行するか、問題を分解して Amazon Q に1つずつ解決してもらうことができます。 ヒントとして、 time モジュールと datetime モジュールのインポートをファイルの先頭に追加します（Amazon Q はインポートステートメントをコンテキストとして重視しており、それらを使用する提案を優先します）。 次に、問題を分解し、Amazon Q に問題を解決させます。 次のスクリーンショットの各コメントは、Amazon Q に解決を依頼した問題の一部であり、そのコードが選択された提案です。 次のコメントを書く前に、Amazon Q に問題を解決させます。 JavaScript と Java を使った作業 JavaScript を使った実験から、開発者のエクスペリエンスはこの記事ですでに示したPythonのものとほぼ同じであることがわかりました。 SDK を使用して DynamoDB を操作するには、 v1 (非推奨)、 v2 、 拡張クライアント など、複数のアプローチがあるため、Java のエクスペリエンスは少し変わりやすくなります。 Amazon Q では、プロジェクト内の既存のコードを、どのアプローチを使用するかのコンテキストとして使用します。 既存のプロジェクトを変更する場合、他のプロジェクトと同じアプローチでサンプルを受け取る可能性があります。 プロジェクトが新しい場合は、現在編集中のファイルの先頭に関連する import ステートメントを追加することで、最初の提案でどのアプローチを使用するかを強く決定できます。 チャットパネルとインラインの両方が、これらのインポートステートメントをコンテキストとして使用します。 以下は、2 つの SDK オプションのインポート例です。 v2 — import software.amazon.awssdk.services.dynamodb.* 拡張クライアント — import software.amazon.awssdk.enhanced.dynamodb.mapper.annotations.* 追加のサポートコードの生成 完全に機能するソリューションを構築するには、追加のサポートコードが必要です。 たとえば、CloudFormation テンプレートには Lambda 関数と関連する AWS Identity and Access Management (IAM) role が必要です。 Amazon Q を使用してこのコードを生成することもできます。 Amazon Q が DynamoDB の運用にどのように役立つかに焦点を当ててきましたが、私たちの経験から言うと、Amazon Q はこれらのリソース (およびその他) を生成する際の時間の節約にも非常に効果的です。 結論 この投稿では、IaC を使用して DynamoDB テーブルを作成し、Amazon Q を使用して CRUD オペレーションを実行する方法を示しました。Amazon Q では、ニーズに応じて自然言語で表現されたサンプルコードを提供することで、DynamoDB を使用する際の時間を節約できます。 提案に少し変更を加えたり、大きくて複雑なリクエストを小さく分割したりすることで、Amazon Q の支援なしにコードを書く場合よりも速く動作するコードを作成できます。 Amazon Q は、計画からメンテナンスまで、ソフトウェア開発ライフサイクル全体をサポートできます。 Amazon Q が各段階でどのようにサポートできるかについては、「 Accelerate your Software Development Lifecycle with Amazon Q 」を参照してください。 Amazon Q の詳細については、 Amazon Q Developer Guide を参照してください。 また、 Best Practices for Prompt Engineering with Amazon CodeWhisperer | AWS… 　でプロンプト (Amazon Q が提案を生成するために使用する自然言語のコメント) をベストプラクティスに合わせる方法を学ぶこともできます。 DynamoDB の詳細については、 Amazon DynamoDB Developer Guide を参照してください。 作者情報 Chris Gillespie は英国を拠点とするシニアソリューションアーキテクトです。 彼は仕事のほとんどを、変化の速い「born in cloud」の顧客と過ごしています。 仕事以外では、家族との時間を充実させ、体調を整えるよう努めています。

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 11 月 15 日に、「生成AI Frontier Meet Up」というイベントを開催しました。このイベントは「AWSジャパン生成AI実用化推進プログラム」の一環として開催したもので、様々な課題を独自のモデル開発によって解決しようとするお客様、公開モデルを利用することで解決しようとするお客様の両方に登壇をいただき、取り組みの概要や現在のチャレンジについて共有をいただきました。また、このイベントには経済産業省が展開するGENIAC(Generative AI Accelerator Challenge)に採択された企業の方もお招きし、同様に取り組みの内容を共有いただいています。 開催概要とレポートをブログにまとめています ので、ぜひご覧ください。 「 AWSジャパン生成AI実用化推進プログラム 」のお申し込みも引き続き募集しています。締め切りを延長し11月22日までとしていましたが、多くのお客様から「もっと時間がほしい」というご相談をいただいています。お客様の熱い声にお応えする形で、2025 年 2 月 14 日まで申し込み締め切りを延長することにしました。3月末までに開発完了するというスケジュール感は同じですので、興味のある方はお早めにお知らせくださいね。 それでは、11 月 18 日週の生成AI with AWS界隈のニュースを見ていくのですが、さすがre:Invent直前ということもありすごい物量です。でもこれはまだ序の口。re:Invent期間中は（まだ私も知らないのですが、きっと）すごいアップデートが生成AI関係はもちろん、それ以外にも発表される見込みです。ぜひ AWS Blackbelt Online Seminer re:Invent特集号 で、一気にキャッチアップしてください。今年はYoutubeの仕組みを使って登録不要でご覧いただけますが、「通知を受け取る」をクリックしてお見逃しないようにご注意を。 さまざまなニュース AmazonとAnthropicの戦略的コラボレーションの深化を発表 昨年9月に発表したAmazonとAnthropicの戦略的コラボレーションですが、今回これをさらに深めるという発表を行いました。これに伴ってAmazonはAnthropicに追加で40億米ドルの投資を行い、AnthropicはAmazonをPrimary Training partnerと位置づけて最大規模の基盤モデルをAWS Trainiumを利用してトレーニング・デプロイするという計画が発表されています。詳細についてはぜひリンク先でご確認ください。 ブログ記事「 Amazon Bedrock Agents を使用して堅牢な生成 AI アプリケーションを構築するためのベストプラクティス」を公開 この記事では、Amazon Bedrock Agentsを利用して生成AIアプリケーションを構築するためのベストプラクティスを解説します。生成AIアプリケーションにおいて注目されているのがエージェントです。解決のために複数のステップが必要な複雑なタスクを処理できるようにするものですが、それを開発するためにはいくつかの留意点があります。この記事ではエージェントの開発のために必要なポイントを解説していますので、ぜひご覧ください。(2部構成になっています。 第2部はこちら ) ブログ記事「臨床生成 AI ワークフローの AWS Step Functions による オーケストレーション」を公開 生成AI技術の応用が期待されている分野のひとつとして、医療分野があります。生成AIを活用することで患者さんによりよいケアを提供したり、臨床業務を効率化することが期待されています。このブログ記事では、臨床現場で利用する生成AIアプリケーションをAWS Step Functionsによるオーケストレーション機能を利用して開発する方法について解説しています。 サービスアップデート – 生成AIを組み込んだ構築済みアプリケーション AWS Management ConsoleにおけるAmazon Q Developerでコンテキストを考慮した応答が可能に AWS Management ConsoleにはAmazon Q Developerが組み込まれており、ユーザはいつでもAIアシスタントに質問することが可能です。今回、このAmazon Q Developerの機能が強化され、現在表示しているページに基づいて、コンテキストに応じた応答を返せるようになりました。つまり、ユーザの関心事により適した応答が得られるようになったということですので、ぜひ一度試してみてください。 Amazon Q Businessがドキュメントに埋め込まれた表の情報に基づく回答に対応 Amazon Q Businessがドキュメントに埋め込まれた表(テーブル)に含まれる情報からの回答をサポートしました。ドキュメントには価格表や製品仕様表など、表形式で重要なデータが表現されている場合があります。今回のアップデートにより、Amazon Q Businessが表の情報を適切に収集・整理して、ユーザからの問い合わせの回答に利用できるようになりました。 Amazon Q Businessがユーザ対応において過去にアップロードされたファイルの再利用に対応 Amazon Q Businessでは、ユーザの求めに応じてアップロードされたファイルの要約や回答を行うことが可能です。今回のアップデートで、過去にアップロードしたファイルを新しい会話セッションの中で再利用できるようになりました。あるやりとりが完結した後に、改めて同じファイルに対して質問する場合に再度アップロードすることなく、AIアシスタントとの対話を開始することが可能です。 Amazon Q Businessのブラウザ拡張機能が利用可能に Amazon Q Businessのブラウザ拡張機能が利用できるようになりました。Google Chrome, Mozilla Firefox, Microsoft Edgeが対象になっており、Webページの要約やコンテンツに対する質問など、大規模言語モデルの活用をブラウザ内から直接実行できるようになります。 Amazon Q BusinessでGoogle Calnederとのインテグレーション機能のプレビューを開始 Amazon Q BusinessでGoogleカレンダーへのコネクタが利用できるようになりました。今回のアップデートによって、従来からサポートされていたGoogleドライブやGmailに加えてカレンダーについてもAmazon Q Businessでカバーできるようになりました。 Amazon Q BusinessでAsanaとのインテグレーション機能のプレビューを開始 Amazon Q BusinessでAsanaへのコネクタを利用できるようになりました。ご存じの方も多いかもしれませんが、Asanaはエンタープライズ企業で多く利用されるタスク管理プラットフォームで、Amazon Q BusinessがAsanaのデータについてもインデックス化して、プロジェクトのコンテキストに基づいた質問への回答や要約の生成が可能になります。 Amazon Q BusinessのSmartsheet向けコネクタが一般利用開始に Amazon Q BusinessでSmartsheetと連携するためのコネクタが一般利用開始になりました。Smartsheetは作業管理プラットフォームで、このコネクタを利用することでAmazon Q BusinessがSmartsheetで管理されるプロジェクトやタスクに関する情報に基づいて応答できるようになります。 Amazon Q Developer in AWS Chatbotが一般利用開始に Amazon Q Developer in AWS Chatbotが一般利用開始になりました。この機能を利用するとSlackやMicrosoft TeamsでAWSリソースに関する質問に回答できます。例えば、「@aws show ec2 instances running state in us-east1(us-east1で稼働中のEC2インスタンスを表示してください)」といったクエリを、チャットツールの中で実行して結果を得ることができます。 Amazon Q Developer Chat Customizationsが一般利用開始に Amazon Q Developerのチャットカスタマイズ機能が一般利用開始になりました。Amazon Q Developerをプライベートなコードベースと安全に接続することにより、組織内のAPIやライブラリ、クラス、メソッドなどを考慮したより適切な応答を得ることができるようになります。 AWS App Studioが一般利用開始に AWS App Studioが一般利用開始になりました。生成AIの技術を活用することによって、自然言語で必要なビジネスロジックやUIを指示するとApp Studioがそれを解釈してアプリケーションを作成することができるサービスです。Amazon S3やAmazon AuroraをはじめとするAWSのサービスや、SalesforceやZendeskなどと連携するコネクタも用意されており外部とのデータ連携も容易に実現できるのもポイントです。 AWS Console Mobile AppでAmazon QによるAWS Account Resource chatが利用可能に AWS Console Mobile AppでもAmazon Q Developerが提供するアカウントのリソースに関するチャット機能がご利用いただけるようになりました。デバイスの音声入出機能と組み合わせて利用することも可能です。モバイルアプリから利用する場合、Amaozn Qはモバイルデバイスでも見やすい形式でデータを出力するようになっていますので、ぜひ試してみてください。 サービスアップデート – アプリケーション開発のためのツール Amazon Bedrockのプロンプト最適化機能のプレビューを開始 Amazon Bedrockのプロンプト最適化機能のプレビュー開始を発表しました。基盤モデルから適切な応答を得るためには、適切なプロンプトを与えることが必要です。プロンプトは利用するモデルごとにベストプラクティスやガイドラインが用意されており、最良の結果をえるにはそれに従う必要があります。Bedrockのプロンプト最適化機能は、利用する基盤モデルの種類に応じてプロンプトを書き換えることでモデルに応じた最適化を実行します。元のプロンプトと最適化後のものは容易に比較することができ、アプリケーションで再利用できるように保存することが可能です。 Amazon BedrockのTitan Text EmbeddingsがBinary Embeddingsに対応 Amazon Titan Text Embeddings v2がBinary Embeddingsをサポートしました。Titan Text Embeddingsは入力されたデータを1,024/512/256次元のベクトル値に変換します。ベクトル値を構成する各次元のデータを小数ではなく0/1のバイナリで表現することでデータ量を削減することで、検索拡張生成(RAG)をはじめとする生成AIアプリケーションで利用されるベクトルデータベースへの負荷を軽減し、コスト効率の向上が期待できます。 Amazon Bedrock Knowledge BasesがBinary Bector EmbeddingsによるRAGをサポート Amazon Bedrock Knowledge BasesでTitan Text Embeddings V2とCohere Embedを利用したバイナリの埋め込み形式データを利用して、RAGを構築できるようになりました。特に大規模なユースケースにおいて、ストレージ効率や応答速度、スケーラビリティの向上によるメリットが期待できる選択肢となります。 Amazon Bedrock Flowsが一般利用開始になり2つの機能追加を発表 Amazon Bedrock Flows(Prompt Flowsから名前が変わりました)が一般利用開始になるとともに、2つの重要な機能追加が行われました。Amazon Bedrock Flowsを利用すると基盤モデルを中心とし、プロンプトやエージェント、ナレッジベースなど様々なAWSサービスが関与する生成AIワークフローをビジュアルビルダーで素早く開発できます。今回の機能追加でGuardrailsによる保護と、追跡可能性の強化が行われています。詳細は ブログ記事 をご確認ください。 Amazon Bedrock Model Evaluationがソウルのリージョンでもご利用可能に Amazon Bedrockのモデル評価機能がアジアパシフィック(ソウル)のリージョンでもご利用いただけるようになりました。 サービスアップデート – 生成AI開発のためのインフラストラクチャー Amazon EC2 G6eインスタンスが東京リージョンでも利用可能に Amazon EC2 G6eインスタンスが東京・フランクフルト・スペインのリージョンでご利用いただけるようになりました。G6eはNVIDIA L40S Tensor Core GPUを搭載し、G5と比較して2.5倍の性能を発揮するとともに、P4dと比較して20%安価に推論ワークロードを実行可能です。 サービスアップデート – その他関連アップデート Amazon OpenSearch Serverlessがコスト節約を可能にするBinary VectorとFP16をサポート Amazon OpenSerach Serverlessでメモリ要求量を減らすことで費用の節約につながる、Binary vectorとFP16をサポートしました。費用の節約と同時にレイテンシーの削減も期待できます。生成AIを組み込んだアプリケーションではベクトルデータベースを必要とするケースがありますが、蓄積する情報量が多くなればなるほどベクトルデータベースの費用が増加します。検索精度とのトレードオフな部分はありますが、この機能を利用することで用途に応じてコストと精度のバランスを調整することが可能になるのがポイントです。 Amazon OpenSearch ServiceのベクトルエンジンがUltraWarmをサポート Amazon OpenSearch ServiceのUltraWarmは、大量のデータを削除することなくアクセス可能な状態でコスト効率高く保存するためのウォームストレージです。今回、k-NNインデックスのデータをUltraWarmに保存できるようになりました。ウォームストレージは通常の(ホットな)ストレージと比較してパフォーマンスは落ちますが保管コストが大幅に安価になるので、頻繁に使わない(でも保存しておいて必要に応じて即時アクセスしたい)データを格納するのに最適です。 AWS Glueで生成AIによるApache Sparkのアップグレード機能をプレビュー開始 AWS Glueはサーバレスなデータ統合サービスでいわゆるETL処理を容易に実行することができます。ETLジョブはSparkを利用して実行することも可能なのですが、今回新たに生成AIの技術を活用して古いバージョンのSparkジョブを自動的に最新バージョン向けにアップグレードできるようになりました。 AWS Glueで生成AIによるApache Sparkのトラブルシュート機能をプレビュー開始 AWS GlueでApache SparkによるETLジョブに対して、生成AIを活用してトラブルシュートを行う機能が利用できるようになりました。Sparkジョブで発生した問題の原因分析と、解決のための推奨事項を自動的に提示することで、問題解決を加速します。 AWS AmplifyのAI Kit for Amazon Bedrockを発表 AWS Amplify AI Kit for Amazon Bedrockを発表しました。これは開発者の方が、チャットや会話型検索、要約などの機能を備えたアプリケーションを素早く開発できるようにする仕組みです。JavaScript, TypeScritと、React, Node.jsなどの知識があれば機械学習に関する専門知識がなくとも、アプリケーションにAIベースのエクスペリエンスを容易に追加することができます。 AWS re:Post PrivateがAmazon Bedrockとインテグレーションされコンテキストにそった知識を組織内に展開可能に AWS re:Post Privateは、AWSに関する情報やQ&amp;Aが可能なコミュニティサイトのプライベート版です。今回このre:Post PrivateがAmazon Bedrockとインテグレーションされました。組織内の情報とAWSに関するナレッジを重ね合わせて、組織ごとのルールや慣習をふまえた回答を生成するようになるため、組織内の知見の有効活用にもつながることが期待できます。 著者について 小林 正人(Masato Kobayashi) 2013年からAWS Japanのソリューションアーキテクト(SA)として、お客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援してきました。2024年からは特定のお客様を担当するチームを離れ、技術領域やサービスを担当するスペシャリストSAチームをリードする役割に変わりました。好きな温泉の泉質は、酸性-カルシウム-硫酸塩泉です。

みなさん、こんにちは。ソリューションアーキテクトの杉山です。今週も 週刊AWS をお届けします。 AWS re:Invent 2024 が近づくにつれて、注目の大型アップデートが続々と発表されています。同時に、実用的な機能追加やサービス改善も数多く行われています。今回は数が多いため、各アップデートについて要点を絞って簡潔に紹介させていただきます。また、生成 AI に関するアップデートは、基本的には 週刊生成AI with AWS で取り上げていますので、こちらもご覧ください。本番の re:Invent でどのような発表があるのか、今から非常に楽しみですね。re:Invent はオンラインの視聴が可能なので、ぜひ こちら から登録のうえご視聴ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2024年11月18日週の主要なアップデート 11/18(月) Amazon ECS で VPC Lattice を利用した接続をサポート&nbsp; Amazon ECS で VPC Lattice を利用した接続をサポートしました。ALB を経由することなく、ECS サービスを VPC Lattice のターゲットグループに直接関連付けることができるようになりました。詳細は こちらのブログ をご確認ください。 AWS Lambda が Python と .NET で SnapStart をサポート AWS Lambda で、Python および .NET のマネージドランタイムを使用する関数で Lambda SnapStart を利用できるようになりました。遅延に敏感なアプリケーションでは、コールドスタートとして知られる起動時間の遅延がユーザー体験に影響を出してしまう場合があります。Lambda SnapStart は、事前に初期化された実行環境のスナップショットをキャッシュすることで、起動にかかる時間を短縮できます。 Amazon DynamoDB、属性ベースのアクセス制御の一般提供を発表 DynamoDB のテーブルとインデックスに対する属性ベースのアクセス制御 (ABAC) をサポートしました。ABAC は、ユーザー、ロール、および AWS リソースに付加されたタグに基づいてアクセス権限を定義できます。これまでプレビューだったものが、一般提供となった形です。 AWS IoT SiteWise、新しい生成 AI 搭載の産業用アシスタントを提供開始 AWS IoT SiteWise は、産業用機器データの大規模な収集、整理、監視を簡素化するマネージドサービスです。IoT SiteWise に、生成 AI が搭載されたアシスタント機能が追加され、自然言語による問い合わせができるようになりました。「アラームが出ているアセットは何か？」や「風力タービンの RPM が低い問題を修正するにはどうすればよいか？」といった自然言語で質問ができるようになり、蓄積データの分析が簡単にできるようになります。 Amazon Aurora MySQL 3.08 (MySQL 8.0.39互換) が一般提供開始 Amazon Aurora で MySQL 3.08 (MySQL 8.0.39 互換) をサポートしました。複数のセキュリティ強化とバグ修正に加えて、大量のテーブルを処理する際のデータベースの可用性が向上し、redo ログやインデックス処理に関連する InnoDB の問題を軽減する機能強化が含まれています。 11/19(火) Amazon OpenSearch Serverless が Binary Vector と FP16 によるコスト削減機能をサポート Amazon OpenSearch Serverless で、メモリの使用容量を削減し、OCU コスト低減に役立つ、Binary Vector と FP16 をサポートしました。データをメモリ上で扱う際に、バイナリ形式や 16 ビット浮動小数点といった形式でデータを保持でき、従来の 32 ビット浮動小数点と比べて、必要なメモリリソースの削減を可能とする仕組みです。 Amazon VPC で Block Public Access (BPA) を提供開始 VPC で Block Public Access を提供開始しました。これは、ネットワークおよびセキュリティ管理者が VPC のインターネットトラフィックを確実にブロックできる、新しい集中型の宣言的制御機能です。VPC BPA は他のすべての設定より優先され、組織のセキュリティとガバナンスポリシーに準拠して、VPC リソースがインターネットアクセスから保護されることを保証します。詳細は こちらのブログ をご覧ください。 Amazon ECS でソフトウェアバージョンの一貫性に関する動作を無効に設定可能 Amazon ECS は、ECS サービスを新規作成や更新した際に、コンテナイメージタグをイメージダイジェスト (SHA256 ハッシュ) で解決します。この動作により、サービス内のすべてのタスクで同一のイメージを利用することを保証します。今回のアップデートで、この動作を無効化できるようになりました。コンテナイメージタグに Latest を指定して、順次最新のイメージを利用する、そういったユースケースに対応しやすくなりました。 Amazon EFS がクロスアカウントレプリケーションに対応 Amazon EFS が、AWS アカウント間のクロスアカウントレプリケーションに対応しました。EFS レプリケーションを使用することで、別の AWS アカウントの指定した AWS リージョンに、ファイルシステムの最新のレプリカをコピーできます。 Amazon Bedrock の Titan Text Embeddings V2 モデルでバイナリ埋め込みをサポート Amazon Bedrock で提供されている Titan Text Embeddings V2 が、バイナリ埋め込みをサポートしました。通常の埋め込みでは、1,024（デフォルト）、512、256 次元のベクトルとして表現されます。バイナリ埋め込みでは、各次元を単一のバイナリ値（0 または 1）にエンコードされた Binary Vector としてデータを持ちます。これによりメモリやストレージといったリソースを削減できます。このアップデートは、Binary Vector をサポートした OpenSearch Serverless や Knowledge Bases と組み合わせた利用も可能です。 Amazon OpenSearch Serverless で point in time search をサポート Amazon OpenSearch Serverless で point in time search をサポートしました。特定の時点で固定されたデータセットに対して複数のクエリを実行できるようになりました。データが変更され続けている場合でも一貫した検索結果を維持することができ、深いページ切換えや複数のクエリにわたって、データの表示を保持するアプリケーションに特に有用です。 AWS Glue でエンタープライズアプリケーション向けに 19 のネイティブコネクタを追加 AWS Glue で、新たに 19 個のコネクタが追加されました。Facebook Ads、Google Ads、Google Analytics 4、Google Sheets、Hubspot、Instagram Ads、Intercom、Jira Cloud、Marketo、Oracle NetSuite、SAP OData、Salesforce Marketing Cloud、Salesforce Marketing Cloud Account Engagement、ServiceNow、Slack、Snapchat Ads、Stripe、Zendesk、Zoho CRM のコネクタが追加されました。 Amazon OpenSearch Service でディスク最適化ベクトルエンジンが利用可能に Amazon OpenSearch Service のバージョン 2.17 で、検索アプリケーションを 3 分の 1 のコストで実行できるようになる、ディスクモードを提供開始しました。バイナリ量子化などの技術を使用してインデックスが圧縮され、比較的少ないメモリの環境の動作に最適化されます。 11/20(水) Amazon CloudFront で VPC オリジンをサポート Amazon CloudFront は、VPC のプライベートサブネットでホストされているアプリケーションからコンテンツを配信できる新機能、Virtual Private Cloud (VPC) オリジンをサポートしました。お客様は ALB、NLB、EC2 インスタンスをプライベートサブネットに配置し、CloudFront ディストリビューションを通じてアクセスを提供できます。 ALB と NLB の Load Balancer Capacity Unit 予約機能をサポート ALB と NLB が、既存のトラフィックパターンに基づく自動スケーリング機能に加えて、ロードバランサーの最小容量を事前に設定できる Load Balancer Capacity Unit (LCU) 予約機能をサポートしました。突然の高トラフィックなスパイクが予想される際に、事前にそのスパイクに対応できるリソースを用意したい場合などにご利用いただけます。 Amazon ECS で平均復旧時間を短縮する AZ リバランシングをサポート Amazon ECS は、Fargate および EC2 環境において、AZ 間のリバランシング機能をサポートしました。これまで、AZ レベルの障害による影響を最小限に抑えるため、タスクは複数の AZ に分散して配置されていました。しかし、AZ の停止などのインフラストラクチャーイベントにより、AZ 間でタスクの配置バランスに偏りが出ている場合がありました。新しい AZ リバランシング機能により、タスクの配置を自動的に AZ 間で再分配することが可能となり、アプリケーションの高可用性をより維持できるようになりました。 Amazon RDS や Amazon Aurora で AWS Advanced NodeJS Driver が一般提供開始&nbsp; RDS と Aurora の PostgreSQL、MySQL 互換のデータベースクラスターで、AWS Advanced NodeJS Driver が一般提供開始になりました。より高速なスイッチオーバーとフェイルオーバー、IAM 認証の提供、Federated Authentication 機能、といった特徴があります。 Amazon Aurora Serverless v2 がゼロキャパシティへのスケーリングをサポート Amazon Aurora Serverless v2 が、0 Aurora Capacity Units (ACUs) へのスケーリングをサポートするようになりました。この新機能により、データベース接続のアクティビティがない期間が続いた後、データベースが自動的に一時停止するようになり、コストの削減が可能です。 Amazon OpenSearch Serverless で SQL API をサポート Amazon OpenSearch Serverless で、REST API、Java Database Connectivity (JDBC)、およびコマンドラインインターフェース (CLI) を通じて、OpenSearch SQL と OpenSearch Piped Processing Language (PPL) を使用したデータのクエリが可能になりました。 Amazon CloudFront で gRPC 配信をサポート開始 Amazon CloudFront で gRPC アプリケーションの配信をサポートしました。gRPC で構築されたアプリケーションは、効率的な双方向ストリーミングや、 Protocol Buffers と呼ばれるバイナリメッセージフォーマットを使用でき、レイテンシーを改善できるメリットがあります。 Amazon RDS Blue/Green Deployments がストレージボリュームの縮小をサポート Amazon RDS Blue/Green Deployments で、RDS データベースインスタンスのストレージボリュームを縮小できるようになりました。RDS のインスタンスは直接ストレージの容量を縮小することはできないので、新規にストレージが小さい RDS インスタンスを作成してデータ移行を行うことがありました。これを、Blue/Green Deployment で実行できるようになり、作業負担を軽減できるメリットがあります。Amazon RDS for PostgreSQL メジャーバージョン 12 以上、RDS for MySQL メジャーバージョン 5.7 以上、Amazon RDS for MariaDB メジャーバージョン 10.4 以上で利用できます。 Amazon CloudFront がアクセスログの新しいログ形式と出力先をサポート CloudFront アクセスログを、新たに 2 つの出力先 (Amazon CloudWatch Logs と Amazon Data Firehose) に直接配信できるようになりました。また、JSON や Apache Parquet といったログ出力形式を選択できるようになりました。さらに、S3 に配信されるログの自動パーティション分割の有効化、特定のログフィールドの選択、ログに含まれるフィールドの順序設定が直接可能になりました。 AWS DMS で EC2 上で動かしているデータベースを RDS へ自動移行する機能をサポート Amazon RDS コンソールの 1-click move to managed 機能を使用することで、Amazon EC2 サーバー上で実行されているデータベースを、マネージド型の Amazon RDS または Aurora データベースに自動移行できるようになりました。 Amazon CloudFront が Anycast Static IP をサポート開始 Amazon CloudFront が Anycast Static IP をサポートし、世界中の CloudFront エッジロケーションへアクセスする際に、専用の静的な IP アドレスリストを利用できます。通常、CloudFront はトラフィックの処理に動的な IP アドレスを使用しますが、Anycast Static IP を利用することで、ワークロード用の専用の静的 IP アドレスリストを利用できます。Anycast Static IP を利用すると、 追加で $3000 の月額料金 が発生します。 11/21(木) Amazon ECS サービスの予測スケーリングのサポート Amazon ECS で予測スケーリングをサポートしました。高度な機械学習アルゴリズムを活用して Amazon ECS サービスを需要の急増に先立って事前にスケーリングすることで、過剰なプロビジョニングのコストを削減しながら、アプリケーションのパフォーマンスや可用性を向上できます。 Amazon API Gateway がプライベート REST API のカスタムドメイン名をサポート Amazon API Gateway で、private.example.com のような独自の DNS 名を使用して、プライベート REST API を設定できるようになりました。 Amazon Polly が新たに 7 個の generative voice をサポート Amazon Polly が新たに 7 個の generative voice をサポートしました。2 つの女性音声 (インド英語、イタリア語) と 5 つの新しい男性音声 (米国スペイン語、メキシコスペイン語、ヨーロッパスペイン語、ドイツ語、フランス語) が追加されました。 AWS Management Console のビジュアルアップデートをプレビュー AWS Management Console で見た目が新しくなるビジュアルアップデートのプレビューを開始しました。現在は一部のサービスで提供されており、今後すべてのサービスに拡張される予定です。 Amazon EC2 で G6e インスタンスが東京を含む追加のリージョンで利用可能 NVIDIA L40S Tensor Core GPU を搭載した Amazon EC2 G6e インスタンスが Asia Pacific (Tokyo) および Europe (Frankfurt, Spain) リージョンで利用可能になりました。G6e インスタンスは、幅広い機械学習および空間コンピューティングのユースケースに使用できます。 11/22(金) Amazon QuickSight で Highcharts ビジュアルのプレビュー開始 Amazon QuickSight は、Highcharts Core ライブラリを使用してカスタムビジュアライゼーションを作成できる Highcharts ビジュアルを提供開始しました。この新機能により、QuickSight の標準チャートで表現しきれないことが表現できるようになり、例えば、サンバーストチャート、ネットワークグラフ、3D チャートなど、独自のチャートを作成できるようになりました。詳細は、 こちらのブログ や Highcharts のデモサイト をご覧ください。Highcharts のサンプルがいくつか確認いただけます。 Amazon QuickSight でフォントカスタマイズが可能に Amazon QuickSight で、Analysis 全体に対する、フォントのカスタマイズが可能になりました。フォントサイズ、フォントファミリー、色、太字、斜体、下線などを設定できます。 Amazon QuickSight がイメージコンポーネントの提供開始 Amazon QuickSight がイメージコンポーネントの提供を開始しました。ダッシュボード、分析、レポート、ストーリーに画像をアップロードできるようになりました。企業ロゴやブランディング、背景画像などの用途で利用が可能です。 AWS Lambda で Node.js 22 をサポート AWS Lambda が Node.js 22 を使用したサーバーレスアプリケーションの作成をサポートしました。マネージド型ランタイム、コンテナベースイメージの両方で利用可能です。Node.js 22 は Node.js の最新の長期サポート (LTS) リリースであり、2027 年 4 月までセキュリティとバグ修正のサポートが提供される予定です。 Amazon Connect Email を提供開始 Amazon Connect Email を提供開始しました。Amazon Connect Email を使用すると、ビジネスアドレスに顧客から送信されたメール、またはウェブサイトやモバイルアプリのウェブフォームを通じて送信されたメールを受信し、応答することができます。 AWS Outposts における EC2 インスタンスストアを使用した静的安定性の提供 AWS Outposts は、EC2 インスタンスストアを使用した Amazon EC2 インスタンスの静的安定性を提供します。Outposts は通常、AWS リージョンに接続された状態で実行されますが、新しい静的安定性機能により、AWS リージョンへの接続が利用できない場合でも、EC2 インスタンスストアを使用する EC2 インスタンス上で実行されているワークロードは電源障害から復旧できます。 AWS Step Functions が変数とJSONata データ変換のサポート Step Functions で、変数と、JSONata データ変換の 2 つの新機能をサポートしました。変数機能により、開発者はとあるステートで変数にデータを割り当て、後続のステートでその変数を参照できます。JSONata は、JSON データのための軽量なクエリおよび変換を行う言語です。例えば、Step Functions の中で、ユーザーから入力されたメールアドレスを、正規表現を使って正しい形式か確認する Lambda 関数があるとします。これを JSONata のクエリーで実現でき、Lambda 関数を置き換えることが可能です。詳細は こちらのブログ をご参照ください。 Amazon Cognito でパスワードレス認証をサポート Amazon Cognito で、パスキー、メール、テキストメッセージを含むパスワードレス認証によってアプリケーションへのユーザーアクセスを保護できるようになりました。例えば、ユーザーがパスキーでログインを選択した場合、Apple MacBook の Touch ID や PC の Windows Hello 顔認証などの組み込み認証機能を使用してログインできます。 クロスゾーン有効化をした Application Load Balancer が zonal shift と zonal autoshift をサポート クロスゾーン有効化をした ALB が、zonal shift と zonal autoshift をサポートしました。クロスゾーン有効化は、複数の AZ を利用している環境で一般的な設定です。この機能のアップデートにより、お客様はクロスゾーンが無効化されたロードバランサーと同様に、障害が発生した際、AZ からトラフィックを移動できるようになりました。 Amazon Cognito がリッチなブランディングをサポートする Managed Login を提供開始 Amazon Cognito が Managed Login を提供開始しました。いままで提供されていた Hosted UI の改良版となり、サインアップやサインインのための新しい Web 画面、多要素認証、レスポンシブデザインなどに加えて、Managed Login の画面を外観をカスタマイズできるブランディングデザイナーが提供されています。また、日本語のローカライズも提供されており、日本のお客様に便利にご利用いただけます。また、料金の Tier として、Lite、Essentials、Plus と分けられ、利用する機能に合わせて最適な Tier を選択できるようになりました。詳細は こちらのブログ や ドキュメント をご参照ください。 Amazon EC2 Auto Scaling が高応答性のスケーリングポリシーを導入 EC2 の Auto Scaling の Target Tracking Policy で、1 分未満の間隔で公開されている、秒レベルのデータポイントを持つ高解像度 Cloud Watch メトリクスをサポートしました。最小 10 秒の間隔でメトリクスをモニタリングするように設定でき、従来と比べてより素早いスケーリングが可能になります。バージニア、オレゴン、シンガポールアイルランドリージョンで利用可能です。詳細は こちらのドキュメント をご参照ください。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です

AWS re:Invent 2024 が間近に迫っています。 Amazon Connect チームは 12月2日から6日までラスベガスで世界中のお客様をお迎えできることを楽しみにしています。AWS や他のお客様からの話を聞いたり、刺激的なブレイクアウトセッション、チョークトーク、ビルダーズセッション、ワークショップに参加して実践的な学びを得ることができます。コンタクトセンターとカスタマーエクスペリエンス戦略をどのように変革できるかの参考にしていただくため、 アジェンダを作成するためのガイド をご用意しました。 re:Invent 基調講演 での発表に加えて、お薦めしたいセッションをご紹介します： BIZ221-INT | Innovation Talk | Generative AI for customer service (カスタマーサービスのための生成 AI) 12月2日 (月) | 10:30 AM – 11:30 AM PST (最新の日時情報は ライブカタログ を参照) 生成 AI は顧客とのやり取りに革命をもたらし、自動化、コスト効率、応答性の新時代の到来を告げると期待されています。しかし、この変革を実現するには、人、プロセス、テクノロジーを調和させる総合的なアプローチが必要です。お客様の成功事例と AWS の最新イノベーションのデモを通じて、Amazon Connect の Vice President である Pasquale DeMaio から、カスタマーサービスにおける生成 AI の運用に関する洞察をお話します。これから始める場合でも、すでに着手している場合でも、このトークを通じて顧客とのやり取りやエージェントエクスペリエンスなどに AI の変革力を活用するための知識とツールをご紹介します。 スピーカー： Pasquale DeMaio ,&nbsp;Vice President &amp; General Manager of Amazon Connect, AWS BIZ213 | Breakout Session | How Amazon.com powers customer-obsessed service with Amazon Connect (Amazon.com が Amazon Connect で顧客志向のサービスを実現する方法) 12月4日 (水) | 2:30 PM – 3:30 PM PST (最新の日時情報は ライブカタログ を参照) Amazon.comでは、顧客第一主義を貫くことがカスタマーサービスのあらゆるやり取りを通じて信頼を得るための鍵となります。このセッションでは、Amazon Connect の最大の世界規模の顧客であるAmazon カスタマーサービスが、Amazon Connect を使用して顧客とのやり取りを年間数十億件にまで拡大し、便利でパーソナライズされた顧客体験をどのように提供しているかを学びます。世界中の複雑な顧客サポートニーズに包括的に対応するカスタマーサービスを強化するために、Amazon がどのように生成 AI に投資しているかを聞くことができます。 スピーカー： John Chao , Director, Customer Engagement, Amazon.com Customer Service Jeff Christenson , Sr Manager, Customer Engagement, Amazon.com Customer Service Lauren Dickerson ,&nbsp;Manager, Worldwide Specialist for Amazon Connect, AWS BIZ218 | Breakout Session | How Frontdoor, Inc. boosts agent productivity with Amazon Connect (Frontdoor, Inc. が Amazon Connect でエージェントの生産性を向上させる方法) 12月3日 (火) | 4:00 PM – 5:00 PM PST (最新の日時情報は ライブカタログ を参照) コンタクトセンターのエージェントはカスタマーサービスの提供に欠かせない存在です。AWS と米国最大の住宅保証プロバイダーである Frontdoor, Inc. から、Amazon Connect の統合された生成 AI 搭載ワークスペースを使用してエージェントを強化し、生産性を向上させる方法についてお話します。このワークスペースは、エージェントが顧客にパーソナライズされたサービスを提供するために必要な機能を提供します。複雑な顧客の問い合わせに対するエージェントの対応を改善し、どんなエージェントでも最高のエージェントにする方法について、新しいアイデアを得ることができます。 スピーカー： Scott Brown , SVP Customer Experience, Frontdoor Trevor Bloking ,&nbsp;Sr Manager, Product Management for Amazon Connect, AWS 全てのセッションリストについては、re:Invent の カスタマーエクスペリエンスガイド をダウンロードしてください。 カスタマーエクスペリエンスレセプションにご参加ください 12月3日 (火) に The Bellagio の Mayfair Supper Club で開催されるカスタマーエクスペリエンスレセプションにご参加いただくと、AWS のコンタクトセンターエキスパートや他のお客様と交流する機会が得られます。一日の終わりにお立ち寄りいただき、美味しい軽食、楽しいカクテル、ライブエンターテイメント、そして CX を中心とした魅力的なディスカッションをお楽しみください。 ご登録はまだ間に合います！re:Invent 2024 でお会いできるのを楽しみにしています。 翻訳は Amazon Connect スペシャリストソリューションアーキテクト清水が担当しました。原文は こちら です。

高エネルギー加速器研究機構（以下、KEK）は、クライオ電子顕微鏡(Cryo-EM)の単粒子解析法に関わるコンピューティング環境の最適化の研究をAWSを利用して実施されています。今回この取り組みが英国科学誌 Nature の姉妹紙である Communications Biology に論文として掲載されました。これに関連する KEK プレスリリースは こちら となります。KEK と AWS は研究DX加速のため連携強化を 2022年に発表 しており、今回の論文掲載はその成果の一つとなります。この論文では、GoToCloud の全体アーキテクチャだけでなく、単粒子解析の各ステップでのCPUおよびGPU搭載インスタンスでの性能評価や、セキュリティ上の考慮点についても述べられており、GoToCloud の利用者だけでなくクラウド上で同様の解析を行う方々にとって参考になる内容です。 Cryo-EM は、膜タンパク質を含む多くの創薬のターゲットとなる物質（タンパク質などの生体高分子）の3D構造を原子分解能で可視化するために広く用いられている手法です。しかしながら構造ベースの創薬(SBDD：Structure-Based Drug Design)に必要なスループットが達成されておらず、検出器の技術や画像取得方法の急速な進歩により、データ解析が大きなボトルネックとなっていました。KEK は Cryo-EM における高度なデータ解析と管理のためにクラウドコンピューティングベースのプラットフォームである「GoToCloud」プロジェクトを実施しています。各処理ステップごとに最適な並列計算を選択することで、コンピューティングリソースを最適化し、スループットを高めつつ、コストの最適化を行うことができます。GoToCloud では、インスタンスの選択などを含めた並列処理設定や必要な目標分解能が、処理時間とコストパフォーマンスに大きな影響を与えることが実証されています。Cryo-EM SBDD を加速する有望なプラットフォームの1つとして GoToCloud の利用があげられます。 KEK の GoToCloud 環境では、AWS ParallelCluster を利用しています。この AWS ParallelCluster はハイパフォーマンスコンピューティング(HPC)のクラスタ環境を構築、構成、管理ができるもので、必要に応じてコンピューティングリソースを増減させて効率的に使うことが可能です。この GoToCloud 環境では、AWS上で複雑な処理環境の構築とセットアップの手順を自動化し3つの手順にまで簡略化しています。Cryo-EM 単粒子解析用のソフトウェアの実行を、各ステップごとに最適なインスタンス(主に GPU 搭載の有無)で行うため、RELION（Cryo-EM 構造解析のためのソフトウェアパッケージ） の実行ファイルを複数種類用意して利用しています。これまで解析環境の準備や運用に課題があり個別の解析環境を持つことが出来なかったユーザにとって、この GoToCloud 環境を使うことで、データ処理ソフトウェアの保守や最適化など技術的な面を気にすることなく、データ解析作業に集中できるようになります。Cryo-EM 施設側でセットアップした環境を個別のユーザが利用、各ユーザ自身のAWSアカウントに GoToCloud 環境を構築して利用のどちらの形も可能となっており、既に製薬企業や他の研究機関でもご活用いただいております。 図 GoToCloud 構成図(KEK公開事例より) KEK は継続して各ステップごとに最適なインスタンスタイプの割り出しやスポットインスタンスを利用したトータルコスト削減、処理時間の削減に取り組んでいます。またクラウドサービスを有効的に活用することで、GoToCloud において Cryo-EM 単粒子解析をサポートするより高度なシステムへの拡張を目指しています。複数の Cryo-EM 施設をインターネットを介してクラウドに接続する IoT化や、機械学習などを用いたアルゴリズムの開発など高度な自動化を進めていく予定です。このように AWS を利用していただくことで、解析環境を柔軟に構築、利用ができ、コスト最適化をしながら、AWS の様々なサービスと組み合わせていただくことで、システムの機能拡張の取り組みをさらに加速していただくことが可能となります。 アマゾン ウェブ サービス ジャパン合同会社 常務執行役員 パブリックセクター統括本部長 宇佐見 潮は、次のように述べています。「AWS は、これまでにも高エネルギー加速器研究機構とは HPC（ハイパフォーマンスコンピューティング）分野において深く連携を図ってきました。今回の「GoToCloud」プロジェクトは飽くなき探求心が生んだ成果だと考えております。クラウドコンピューティングの可能性を最大限に生かし、研究開発の新たな地平を切り開く取り組みを支援できることを大変光栄に思います。AWS はその架け橋となることで、日本の研究分野における無限の可能性に貢献していきます。」 ■ KEKプレスリリース : 　 「クラウドコンピューティング環境の活用で加速する タンパク質立体構造に基づく新しい創薬デザイン！ ～「GoToCloud プラットフォーム」の開発～」 ・ 高エネルギー加速器研究機構について 高エネルギー加速器研究機構 (KEK) は、電子や陽子などを加速する粒子加速器と呼ばれる装置を使う加速器科学の世界的拠点の一つです。国内外の研究者と共同研究を行うとともに、共同利用の場を提供する大学共同利用機関法人として、素粒子、原子核の謎の探究や物質、生命現象の理解に取り組んでいます。ノーベル賞との関わりも深く、ここで行われた実験による成果で、物理学賞と化学賞が生まれています。前身の旧文部省高エネルギー物理学研究所は 1971 年に創設され、現在、茨城県つくば市と東海村に拠点を持っています。詳細については以下の URL をご覧ください。 https://www.kek.jp/ ・クライオ電子顕微鏡 (Cryo-EM)について 精製したタンパク質などの生体高分子を溶かした液体を急速に凍らせ、液体窒素で-200℃ぐらいの低温に保ったまま、透過型電子顕微鏡（TEM）を用いて撮影した 2D 画像から、コンピューターによる画像処理で生体高分子の立体構造を決定します（この技術を開発した 3 名は 2017 年、ノーベル化学賞を共同受賞しています）。タンパク質は、電子顕微鏡内部の高真空にさらされると干からびて形が変わってしまいますが、薄い氷の中に閉じ込めて保護・固定して観察します。歴史の長いX線によるタンパク質の構造解析では、良質な結晶が必須で作成する負担が大きいですが、Cryo-EM ではその必要がないため、結晶化が困難な巨大なタンパク質やその複合体の構造解析に力を発揮しています。ただ氷の中のタンパク質の向きはまちまちであるため、別々に撮影した膨大な数の 2D 画像からそれぞれのタンパク質粒子像の三次元的な撮影方向を推定することでうまく重ね合わせて立体構造を再現する複雑な計算をしなければなりません。そのため、膨大な計算資源が必要になります。 【日本の高等教育機関および研究機関向け お問合せ窓口】 AWSのご相談全般に関しては「aws-jpps-er@amazon.com」までご連絡ください。。 ＊ ＊ ＊ ＊ 本記事は、パブリックセクターシニアソリューションアーキテクト櫻田が執筆しました。

本稿は、2024 年 6 月 14 日に公開された “ Improve your industrial operations with cloud-based SCADA systems ” を翻訳したものです。 導入 現代の産業現場では、毎分数千から数百万のデータポイントが生成されるのが一般的です。産業分野やエネルギー分野で IIoT (Industrial Internet of Things) の利用が増加するにつれ、生成されるデータ量はさらに増加すると予想されています。 エネルギーおよび公共事業分野では、SCADA (監視制御およびデータ収集) システムが、地理的に広く分散したシステムを中央拠点からほぼリアルタイムで監視するのに有用です。産業用制御システムやその他の運用技術 (ICS/OT) は現場に設置され、データ通信ネットワークを介して SCADA システムに接続されています。SCADA は効率性と生産性を向上させ、コストと無駄を削減し、分散したシステムに対するより広範な制御を提供します。 SCADA システムは重要な運用をほぼリアルタイムで行うため、24 時間 365 日利用可能で稼働していることが期待されます。従来、SCADA システムはオンプレミスシステムとして設計され、外部ネットワークとの接続なしに産業およびエネルギープロセスを安全かつ確実に運用するためのものでした。しかし、ビジネスの俊敏性を高め、運用を改善し、コストを削減するために、SCADA などの OT システムはビジネスネットワークやクラウドインフラストラクチャにより統合されるようになってきています。 クラウドベースの SCADA システムには、高価なサーバーハードウェアやソフトウェアをオンプレミスで設置・維持する必要性を減らし、産業データをいつでもどこでも利用可能にするなど、いくつかの利点があります。クラウドベースの SCADA システムは、IIoT やインダストリー 4.0 において、プロセスや運用を改善するために必要な自動化、データ収集、分析、アナリティクス、機械学習、接続性を提供するため、ますます重要になっています。クラウドベースの SCADA システムにより、顧客はデータにより簡単にアクセスでき、クラウドサービスを使用して大規模にデータを管理・分析することができます。 クラウドベースの SCADA システムは多くの利点を提供する一方で、外部ネットワークやクラウドサービスへの依存度が高まることによる可用性、安全性、セキュリティ、およびパフォーマンスに関する新たな課題も生じます。このブログでは、クラウドベースの SCADA システムの一般的なユースケースとアーキテクチャ、そして Amazon Web Services (AWS) 上でのクラウドベース SCADA システムのベストプラクティスについて議論します。 エネルギーおよび公共事業分野では、クラウドベースの SCADA システムが特に注目されています。これは、エネルギーおよび公共事業の運用が地理的に分散しており、時には遠隔地に位置しているためです。これらの産業の事業者は、自社のサイトを全体的に把握する必要がありますが、通常、遠隔地に SCADA システムを運用するための専門の OT チームは配置されていません。クラウドベースの SCADA システムを導入することで、中央拠点にいる少人数のチームで大規模かつ分散した運用を行うことが可能になります。 &nbsp; クラウドベースの SCADA システムのためのアーキテクチャーパターン 1. クラウドデータ統合と複合サイトビュー クラウドベース SCADA システムの導入を始める最適な方法の一つは、クラウド上でのマルチサイトデータの可視化と分析です。このシナリオでは、各サイトで主要な SCADA システムをオンプレミスで運用し続けながら、クラウドを使用して複数サイトにわたるデータの統合、民主化、分析、可視化を行います。このアプローチにより、クラウドサービスやアプリケーションとの統合が容易になり、通常オンプレミスでは利用できない他のユースケースを安全かつスケーラブルな方法で実現することができます。このプロセスは「オープンループ」操作と呼ばれることが多く、オンプレミスの SCADA からクラウドへの一方向の通信が行われます。多くの場合、エッジゲートウェイを介して行われ、クラウドから産業用オートメーションおよび制御システム (IACS) へコマンドを送り返すことはありません。すべての制御機能はローカルのオンプレミス SCADA システムによって実行されます。(以下の図 1 を参照) 図 1. クラウドデータの統合と複数サイトビューのアーキテクチャ このソリューションでは、エッジで AWS サービスを使用します。例えば、 AWS IoT SiteWise Edge (オンプレミスで産業機器データを収集、処理、監視するためのサービス) や、 CirrusLink MQTT module などのサードパーティソリューションを利用して、データを AWS IoT Core (デバイスをクラウドに簡単かつ安全に接続するサービス) や AWS IoT SiteWise (産業機器データを大規模に収集、保存、整理、監視するマネージドサービス) に送信します。データが取り込まれると、 AWS IoT Rules Engine (デバイスが AWS サービスと対話する能力を提供) を使用して、ペイロードを他の AWS サービスにルーティングし、データレイクに保存できます。最終的に、ユーザーは他の AWS サービスを組み込んで、ダッシュボードの作成、機械学習 (ML) モデルの実行、監視と可観測性の提供を行うことができます。 2. AWS 上のIgnition® by Inductive Automation SCADA Ignition は Inductive Automation が提供する SCADA システム向けの統合ソフトウェアプラットフォームです。 Inductive Automation パートナーソリューション は、AWS パートナーである Inductive Automation のソリューションである Ignition を AWS クラウドにデプロイします。このパートナーソリューションは、SCADA アプリケーションの可用性、パフォーマンス、可観測性、および回復力を向上させます。Amazon EC2 Linux インスタンス上で Ignition のスタンドアロンおよびクラスターデプロイメントオプションを提供します。両オプションとも、セキュリティ、ネットワークゲートウェイ接続、データベース接続のベストプラクティスに基づいて設計され、安全で高可用性を備えています。 このデプロイメントアプローチでは、AWS が基盤となるインフラストラクチャを管理し、顧客がローカル環境と AWS クラウド環境の両方で SCADA システムとアプリケーションを構築、運用、保護、維持するための安全で信頼性の高いプラットフォームを提供します。顧客は Inductive Automation の永続ライセンスを使用でき、消費した AWS サービスに対してのみ支払いを行います。 これは、Ignition を実行するために必要な AWS リソース (データベース、ネットワーキング、 Amazon EC2 インスタンスなど) のセットアップ、設定、管理が、利用者の責任であることを意味します。Amazon EC2 は、クラウド内の安全で拡張性の高いコンピューティング能力を提供し、事実上あらゆるワークロードに対応します。パートナーソリューションはより多くの制御と柔軟性を提供しますが、より多くの IT 専門知識も必要とします。 スタンドアロンデプロイメントは少数のクライアントに適していますが、クラスターアーキテクチャは Application Load Balancer (高度なリクエストルーティングを備えた HTTP および HTTPS トラフィックのロードバランサー) を含み、バックエンドとフロントエンドのゲートウェイを分離することで、パフォーマンスを向上させる層を追加し、クライアントトラフィックをより効率的に管理できます。 スタンドアロンアーキテクチャでは、パートナーソリューションは以下のコンポーネントをデプロイします (以下の図 2 を参照)： 2 つのアベイラビリティーゾーンにまたがる高可用性アーキテクチャ AWS の セキュリティベストプラクティス に従って、パブリックサブネットとプライベートサブネットで構成された仮想プライベートクラウド (VPC) AWS およびオンプレミスのリソースとアプリケーションを監視・観察するための Amazon CloudWatch 、および CloudWatch アラームがトリガーされたときに通知するための完全マネージドメッセージングサービスである Amazon Simple Notification Service (Amazon SNS) パブリックサブネットには以下が配置されます： プライベートサブネット内のリソースがアウトバウンドインターネットアクセスを可能にするマネージドネットワークアドレス変換 (NAT) ゲートウェイ プライベートサブネット内の Amazon EC2 インスタンスとクラウド向けに構築されたリレーショナルデータベース管理システム (RDBMS) であるAmazon Aurora へのセキュアシェルアクセス (SSH) を可能にする Linux 踏み台サーバー&nbsp; 2 つの別々のアベイラビリティーゾーンにある一次および二次 Ignition ゲートウェイ プライベートサブネットには以下が配置されます： 書き込み操作をサポートするプライマリ Amazon Aurora データベース 読み取り操作をサポートするレプリカデータベース 図 2. Ignition のスタンドアロンデプロイメントアーキテクチャ クラスターアーキテクチャでは、パートナーソリューションは同様のコンポーネントをデプロイしますが、バックエンドとフロントエンドのゲートウェイを分離してクライアントワークロードをフロントエンドサーバーに振り分けることで、Ignition ゲートウェイのパフォーマンスを向上させます。これをサポートするために、クラスターデプロイメントでは Amazon SSL 証明書 で構成された Application Load Balancer も作成され、プライベートサブネット内の Ignition のフロントエンドサーバーにトラフィックをルーティングします。(図 3 を参照) 図 3. Ignitionのクラスターデプロイメントアーキテクチャ Ignition のデプロイメントガイドの詳細については、Ignition の デプロイメントガイド を参照してください。 3. AWS Outposts 上のIgnition Inductive Automation の Ignition® は、 AWS Outposts 上にデプロイすることができます。AWS Outposts は、ローカルデバイスと SCADA システム間で超低レイテンシーと高帯域幅を必要とする顧客向けに、AWS インフラストラクチャとサービスを事実上あらゆるオンプレミスまたはエッジロケーションに提供する、完全管理型ソリューションのファミリーです。AWS Outposts 上の Ignition を使用することで、顧客はネイティブ AWS API を持つ完全管理型インフラストラクチャの利点を得ることができます。AWS Outposts を使用しない顧客は、SCADA ソリューションを実行するためのハードウェアとソフトウェアスタックを調達、管理、サポート、セキュア化、維持する必要があります。 AWS Outposts は、オンプレミス環境と AWS クラウドを橋渡ししたい組織にとって価値ある解決策を提供し、クラウドコンピューティングの利点を活用しながら、ローカルリソースへの制御と低レイテンシーアクセスを維持することを支援します。特に、オンプレミスとクラウドベースのリソースの組み合わせが必要なハイブリッドクラウドシナリオで有用です。 AWS Outposts は、コンピューティング、ストレージ、ネットワーキングコンポーネントを含む AWS インフラストラクチャハードウェアで構成され、物理的にお客様のサイトに配置されます。AWS Outposts は、専用の高速接続を通じて最寄りの AWS リージョン に接続されます。この接続は、AWS への専用ネットワーク接続を作成するために使用される AWS Direct Connect か、オンプレミスネットワークとリモートワーカーをクラウドに接続するために使用される AWS Virtual Private Network (AWS VPN) を使用して確立されます。どちらのサービスを使用するかは、要件とネットワーク設定によって異なります： AWS Direct Connect は、AWS Outposts と AWS リージョン間の専用かつプライベートなネットワーク接続を提供します。低レイテンシー、高スループットの接続を提供し、AWS サービスへの一貫性のある信頼性の高いアクセスが必要なシナリオに適しています。&nbsp; AWS VPN は、パブリックインターネット経由で安全な VPN 接続を確立するのに役立ちます。AWS Outposts と AWS リージョン間の暗号化された通信を提供します。AWS Direct Connect と比較してわずかに高いレイテンシーがある可能性がありますが、より柔軟でコスト効率の高いオプションです。 AWS Outposts 上の Ignition には、多くのアーキテクチャオプションが利用可能です： 標準アーキテクチャ 冗長性を備えた標準アーキテクチャ スケールアウトアーキテクチャ 冗長性を備えたスケールアウトアーキテクチャ Ignition の最も一般的なアーキテクチャは、総所有コストに最適化された、管理が容易なリレーショナル・データベース・サービスである Amazon Relational Database Service (AmazonRDS） に接続された単一のオンプレミス Ignition サーバー、PLC、クライアントで構成されます。 別の一般的な Ignition アーキテクチャは、SQL データベース (Amazon RDS)、PLC、およびクライアントに接続された単一のオンプレミス Ignition サーバー (冗長サーバーを含む) で構成されています。 スケールアウトアーキテクチャは、複数の Ignition ゲートウェイをリンクして分散型システムを形成します。Ignition の入出力 (I/O) をフロントエンドから簡単に分離し、それぞれを独立して拡張することができます。 冗長性を備えたスケールアウト・アーキテクチャーは、複数の Ignition ゲートウェイ (冗長サーバー付き) をリンクして分散型システムを形成します。Ignition の I/O とフロントエンドを簡単に分離し、それぞれを独立して拡張することができます。 AWS Outposts 上の Ignition は、組織が AWS インフラストラクチャとサービスをオンプレミスで使用しながら、環境を AWS クラウドに安全に接続し、データ分析、予知保全、機械学習の分野への旅を始めるのに役立ちます。(図 4 を参照) 図 4. AWS Outposts と AWS IoT Service を利用したオンプレミス Ignition との統合 4. Ignition Cloud Edition Ignition Cloud Edition は、AWS 上でホストされる Ignition プラットフォームのクラウド版です。Ignition Cloud Edition では、ソフトウェアが AWS 上でホストされ、ユーザーは基盤となるインフラストラクチャを管理する必要なしにアクセスできます。これにより、ユーザーの運用負担が軽減され、代わりに Ignition プラットフォームの設定と使用に集中できます。Ignition Cloud Edition では、ユーザーはソフトウェアの設定、バックアップ、アップグレードを担当します。 Ignition Cloud Edition は従量制モデルを提供し、すでにインストールされライセンスされたモジュールのバンドルが付属しています。各モジュールの使用料を支払う代わりに、Ignition Cloud Edition の使用量に応じて支払います。産業機器接続用のドライバーは含まれていませんが、Ignition Cloud Edition には MQTT と Gateway Network 機能が含まれており、標準の Ignition または Ignition Edge インストールとの接続が可能です。そのため、オンプレミスデータを簡単にクラウドに拡張し、様々なクラウドサービスと接続できます。 Ignition Cloud Edition には、Ignition Core モジュール (Perspective、Reporting、SQL Bridge、OPC UA、Enterprise Administration Module (EAM)、Tag Historian、Alarm Notification) が付属しています。また、Web Development、Twilio Notification、Voice Notification モジュール、および Cirrus Link Solutions の MQTT Engine、MQTT Distributor、MQTT Transmission モジュールも含まれています。MongoDB Module というクラウドコネクターモジュールも含まれており、Ignition Cloud Edition ユーザーは新しいクラウドコネクターモジュールが利用可能になると入手できます。 Ignition Cloud Edition を使用することで、顧客は高価なサーバーを購入・管理する必要がなく、ストレージ、機械学習、分析などのクラウドサービスをより簡単に利用できます。 クラウドベース SCADA の課題、セキュリティ上の考慮事項、および推奨事項 クラウドベース SCADA の採用は、集中データ管理の改善、資本および運用・保守費用の削減、セキュリティの向上をもたらす可能性がありますが、クラウドで SCADA を実装することには固有のリスクがあります。顧客はここで説明する新たなリスクをいくつか考慮する必要があります。 クラウドベース SCADA は、ネットワーク接続とクラウドサービスの可用性とパフォーマンスなどのリスクをもたらします。インターネットに依存する場合は、ネットワークの遅延を考慮する必要があります。 クラウドベースの SCADA システムは外部ネットワークとクラウドサービスとの依存を生じさせることもあり、リスクを最小限に抑え、軽減するには、慎重な検証が必要です。さらに、一部の産業およびエネルギー用途には適していますが、すべてに適しているわけではなく、リスク評価、適切なソリューション設計、構成、継続的な監視が必要です。 クラウドベース SCADA システムのセキュリティ推奨事項 サイバーセキュリティリスク評価 ：リスク、ギャップ、脆弱性を完全に理解し、積極的に管理できるようにするため、サイバーセキュリティリスク評価を実施します。 ネットワークセグメンテーション ：産業用非武装地帯 (IDMZ) を確立し、ファイアウォールと一方向ゲートウェイを使用してゾーン間のトラフィックを制御します。 クラウドへの安全なネットワーク接続 ：ネットワークトラフィックをプライベートかつ暗号化して保持します。パブリックインターネットを使用する場合、トラフィックは暗号化する必要があります。 OT およびクラウド運用の可視性と監視 ：OT、IIoT、クラウド全体にセキュリティ監査および監視メカニズムを展開し、セキュリティアラートを中央で管理します。 多層防御 (DiD) 戦略 ：セキュリティポリシー、認証と認可、ファイアウォール制御、パッチ管理、マイクロネットワークセグメンテーション、冗長通信ネットワーク、グレースフルデグラデーション、バックアップと復旧手順などの DiD アプローチを適用します。 SCADA ベンダーの推奨事項 ： Ignition Security Hardening Guide など、SCADA ベンダーのセキュリティガイダンスに従います。 セキュリティ標準 ： ISA/IEC 62443 などの IACS セキュリティ標準に従います。これらの標準は、 IIoT とクラウドサービス の使用をサポートするように進化しており、一般的な IT システムのセキュリティに関する確立された標準 (例： ISO/IEC 27000 シリーズ ) に基づいています。 グローバル OT/IT ネットワークの保護 ：複数のリモートサイトを複数のエッジ構成でクラウドに接続する際は、 この AWS ガイダンス に従います。 加えて、 IIoT ソリューションのための 10 のセキュリティゴールデンルール で説明されている AWS の多層セキュリティアプローチと、 製造 OT のための AWS セキュリティベストプラクティス に従ってください。 結論 このブログでは、AWS におけるクラウドベース SCADA システムの複数の設計考慮事項と使用方法を紹介しました。現代の産業システムが進化し、より大量のデータを生成し、自動化レベルが向上するにつれて、産業界はクラウド SCADA が提供する最新の SCADA アプローチから恩恵を受けることができます。可用性、レイテンシー、パフォーマンス、セキュリティ要件に対応するクラウドベース SCADA ソリューションを設計し、ネットワークのダウンタイムや障害に備えたバックアッププランと緊急措置を用意してください。AWS は、クラウドベース SCADA のための幅広いサービス、ガイダンス、ソリューションを提供しており、クラウドコンピューティングの利点を享受しながら、ニーズに最適なソリューションを選択することができます。 エネルギーおよび公共事業分野におけるクラウドベース SCADA システムの使用は、運用効率の向上、ほぼリアルタイムの監視、シームレスな統合をもたらします。その拡張性は変化する需要に適応し、リソースを最適化してダウンタイムを最小限に抑えます。強化されたサイバーセキュリティは重要インフラの保護を改善します。クラウドベース SCADA の採用は、業界のダイナミックで相互接続された環境を乗り切るために不可欠です。 本稿は、ソリューションアーキテクトの林 隆太郎が翻訳しました。原文は “ Improve your industrial operations with cloud-based SCADA systems ” を参照してください。 Ryan Dsouza Ryan Dsouza は、AWSのプリンシパル産業用 IoT (IIoT) セキュリティソリューションアーキテクトです。ニューヨーク市を拠点とし、顧客が AWS の幅広い機能を活用して、より安全で拡張性が高く革新的な IIoT ソリューションを設計、開発、運用し、測定可能なビジネス成果を達成できるよう支援しています。Ryan は、デジタルプラットフォーム、スマート製造、エネルギー管理、ビルおよび産業オートメーション、OT/IIoT セキュリティなど、多様な産業分野で 25 年以上の経験を持っています。すべての接続デバイスにセキュリティをもたらし、すべての人にとってより良く、より安全で、より回復力のある世界を構築するチャンピオンになることに情熱を注いでいます。AWS に入社する前は、Accenture、SIEMENS、General Electric、IBM、AECOM で働き、顧客のデジタルトランスフォーメーションに貢献していました。 Oscar Salcedo Oscar Salcedo は、AWS の IoT およびロボティクス専門ソリューションアーキテクトです。スマート製造、産業オートメーション、ビルオートメーション、および多様な産業における IT/OT システムで 20 年以上の経験を持っています。AWS の深さと幅広さを活用して、スケーラブルで革新的なソリューションを設計・開発し、顧客に測定可能なビジネス成果をもたらしています。

11 月 21日、 AWS CloudTrail Lake の新しいアップデートを発表できたことを嬉しく思います。AWS CloudTrail Lake は、監査、セキュリティ調査、運用上のトラブルシューティングのために、 AWS CloudTrail で記録されたイベントの集約、不変の保存、クエリに使用できるマネージド型データレイクです。 CloudTrail Lake の新しいアップデートは以下のとおりです。 CloudTrail イベントのフィルタリングオプションの強化 イベントデータストアのクロスアカウント共有 生成 AI 自然言語クエリ生成の一般的利用可能性 AI を活用したクエリ結果の要約機能のプレビュー AI を活用したインサイトを含む高レベルの概要ダッシュボード (AI を活用したインサイトはプレビュー中)、さまざまなユースケースに対応する 14 種類の事前作成済みダッシュボード、定期的な更新を伴うカスタムダッシュボードの作成機能など、包括的なダッシュボード機能 新機能を1つずつ見ていきましょう。 イベントデータストアに取り込まれた CloudTrail イベントのフィルタリングオプションが強化されました イベントフィルタリング機能の強化により、どの CloudTrail イベントがイベントデータストアに取り込まれるかをより細かく制御できるようになりました。これらの強化されたフィルタリングオプションにより、AWS アクティビティデータをより厳密に制御できるようになり、セキュリティ、コンプライアンス、運用調査の効率と精度が向上します。さらに、新しいフィルタリングオプションを使用すると、最も関連性の高いイベントデータのみを CloudTrail Lake イベントデータストアに取り込むことができるため、分析ワークフローのコストを削減できます。 eventSource 、 eventType 、 eventName 、 userIdentity.arn 、 sessionCredentialFromConsole などの属性に基づいて、管理イベントとデータイベントの両方をフィルタリングできます。 AWS CloudTrail コンソール に移動し、ナビゲーションペインの Lake の下の [ イベントデータストア ] を選択します。[ イベントデータストアの作成 ] を選択します。最初のステップでは、[ イベントデータストア名 ] フィールドに名前を入力します。このデモでは、他のフィールドはデフォルトのままにします。ニーズに合った価格設定とリテンションオプションを選択できます。次のステップでは、 CloudTrail イベントの下の [ 管理イベント ] と [ データイベント ] を選択します。必要なすべてのオプションを CloudTrail イベント に含めることができます。また、取り込みオプションを選択することもできます。 Ingest イベント を選択すると、作成時にインジェストが開始されます。イベントデータストアがイベントを取り込むのを停止するために、 Ingest イベント オプションの選択を解除したい場合があります。たとえば、トレイルイベントをイベントデータストアにコピーしていて、イベントデータストアに今後のイベントを収集させたくない場合があります。組織内のすべてのアカウントで統合を有効にするか、イベントデータストアに現在のリージョンのみを含めるかを選択することもできます。 次の例は、AWS サービスによって開始された管理イベントを除外する、すぐに使えるフィルタリング用のテンプレートを示しています。 管理イベント の下で [ 高度なイベントコレクション ] を選択します。[ ログセレクターテンプレート ] ドロップダウンから [ AWS サービス開始イベントを除外 ] を選択します。 JSON ビュー を展開して、フィルターが実際にどのように適用されるかを確認することもできます。 次の例では、 データイベント の下に、特定のユーザーによって開始された DynamoDB データイベントを含めるフィルターを作成しています。これにより、IAM プリンシパルに基づいてイベントをログに記録できます。 リソースタイプ として DynamoDB を選択しました。 ログセレクターテンプレート として [ カスタム ] を選択します。 アドバンストイベントセレクター で、 フィールド として userIdentity.arn を選択し、 オペレーター として [ 同等 ] を選択します。 ユーザーの ARN を 値 として入力します。最後のステップで [ 次へ ] を選択し、[ イベントデータストアの作成 ] を選択します。 これで、取り込まれた CloudTrail データをきめ細かく制御できるイベントデータストアができました。 このフィルタリングオプションの拡張セットにより、セキュリティ、コンプライアンス、および運用上のニーズに最も関連性の高いイベントのみをより選択的にキャプチャできるようになります。 イベントデータストアのクロスアカウント共有 イベントデータストアのクロスアカウント共有機能を使用して、組織内の共同分析を強化できます。リソースベースポリシー (RBP) を通じて、選択した AWS プリンシパルとイベントデータストアを安全に共有できます。この機能により、権限のあるエンティティは、作成されたのと同じ AWS リージョン内の共有イベントデータストアにクエリを実行できます。 この機能を使用するには、 AWS CloudTrail コンソール に移動し、ナビゲーションペインの Lake の下の [ イベントデータストア ] を選択します。リストからイベントデータストアを選択し、その詳細ページに移動します。[ リソースポリシー ] セクションで [ 編集 ] を選択します。次のポリシー例には、アカウント 111111111111、222222222222、333333333333 のルートユーザーが、アカウント ID 999999999999 が所有するイベントデータストアでクエリを実行し、クエリ結果を取得することを許可するステートメントが含まれています。[ 変更を保存 ] を選択してポリシーを保存します。 CloudTrail Lake での生成 AI を活用した自然言語クエリ生成が一般利用できるようになりました 6 月に、CloudTrail Lake 向けのこの機能を プレビュー 版として発表しました。今回の発表により、自然言語の質問を使用して SQL クエリを生成し、SQL の技術的な専門知識がなくても、AWS アクティビティログ (管理、データ、ネットワークアクティビティイベントのみ) を簡単に調べて分析できます。この機能では、生成 AI を使用して自然言語の質問を、CloudTrail Lake コンソールで直接実行できる、すぐに使用できる SQL クエリに変換します。これにより、イベントデータストアを探索し、エラー数、使用頻度の高いサービス、エラーの原因などの情報を取得するプロセスが簡素化されます。この機能には、 AWS コマンドラインインターフェイス (AWS CLI) からもアクセスできるため、コマンドライン操作を好むユーザーにさらに柔軟に対応できます。 プレビューブログ投稿 では、CloudTrail Lake の自然言語クエリ生成機能の使用を開始する方法を段階的に説明しています。 CloudTrail Lake 生成 AI を活用したクエリ結果の要約機能のプレビュー 自然言語クエリ生成機能を基盤として、AWS アカウントアクティビティの分析プロセスをさらに簡略化するために、AI を活用した新しいクエリ結果要約機能をプレビューで導入します。この機能を使用すると、クエリ結果のキーポイントを自然言語で自動的に要約することで、AWS アクティビティログ (管理、データ、ネットワークアクティビティイベントのみ) から貴重な洞察を簡単に抽出でき、情報を理解するのに必要な時間と労力を削減できます。 この機能を試すには、 AWS CloudTrail コンソール に移動し、ナビゲーションペインの Lake で [ クエリ ] を選択します。CloudTrail Lake クエリのイベントデータストアを、 [Event data store] (イベントデータストア) のドロップダウンリストから選択します。集計は、クエリが手動で作成されたものか、生成 AI によって生成されたものかに関係なく使用できます。この例では、自然言語クエリ生成機能を使用します。 クエリジェネレーター では、自然言語を使用して [プロンプト] フィールドに次のプロンプトを入力します。 過去 1 か月間に各サービスで記録されたエラーの数と、各エラーの原因は何でしたか? 次に、 [Generate query] (クエリを生成) を選択します。次の SQL クエリが自動的に生成されます。 SELECT eventsource, errorcode, errormessage, count(*) as errorcount a0****** から WHERE eventtime &gt;= '2024-10-14 00:00:00' AND eventtime &lt;= '2024-11-14 23:59:59' AND ( errorcode IS NOT NULL OR errormessage IS NOT NULL ) GROUP BY 1, 2, 3 ORDER BY 4 DESC; [Run] (実行) を選択して結果を得ます。集計機能を使用するには、[ クエリ結果 ] タブの [ 結果の要約 ] を選択します。CloudTrail はクエリ結果を自動的に分析し、重要な洞察を自然言語で要約します。要約できるクエリ結果には、1 か月あたり 3 MB の割り当てがあることに注意してください。 この新しい要約機能により、主要な調査結果の有意義な要約が自動的に生成されるため、AWS アクティビティデータを理解する時間と労力を節約できます。 包括的なダッシュボード機能 最後に、AWS 環境全体の可視性と分析を強化する CloudTrail Lake の新しいダッシュボード機能について説明します。 1 つ目は ハイライト ダッシュボードで、CloudTrail Lake 管理でキャプチャされたデータと、イベントデータストアに保存されたデータイベントの概要を簡単に確認できます。このダッシュボードでは、API コールの失敗回数が多い回数、ログイン試行の失敗回数の傾向、リソース作成の急増など、重要なインサイトを簡単に特定して把握できます。データ内の異常や異常な傾向を明らかにします。 AWS CloudTrail コンソール に移動し、ナビゲーションペインの Lake の下の [ ダッシュボード ] を選択して、 ハイライト ダッシュボードを確認します。まず、[ 同意してハイライトを有効にする ]を選んでハイライトダッシュボードを有効にします。 データが入力されたら、ハイライトダッシュボードをチェックします。 新しいダッシュボード機能に 2 つ目に追加されたのは、14 種類の組み込みダッシュボードのスイートです。これらのダッシュボードは、さまざまなペルソナやユースケース向けに設計されています。たとえば、セキュリティに重点を置いたダッシュボードは、上位のアクセス拒否イベント、コンソールログイン試行の失敗、多要素認証 (MFA) を無効にしたユーザーなど、主要なセキュリティ指標を追跡および分析するのに役立ちます。また、運用監視用の既定のダッシュボードもあり、スロットリングエラーのある上位APIやエラーのある上位ユーザーなど、エラーや可用性の問題の傾向が強調表示されます。Amazon EC2 や Amazon DynamoDB などの特定の AWS サービスに焦点を当てたダッシュボードを使用することもできます。これらのダッシュボードは、特定のサービス環境におけるセキュリティリスクや運用上の問題を特定するのに役立ちます。 独自のダッシュボードを作成し、必要に応じて更新スケジュールを設定できます。このレベルのカスタマイズにより、CloudTrail Lake 分析機能を AWS 環境全体の正確なモニタリングや調査のニーズに合わせて調整できます。 マネージドとカスタムダッシュボード に切り替えて、カスタムダッシュボードとビルド済みダッシュボードを確認します。 私は、IAM アクティビティ全体を観察するために、 IAM アクティビティダッシュボード 構築済みダッシュボードを選択します。[ 新しいダッシュボードとして保存 ] を選択して、このダッシュボードをカスタマイズできます。 カスタムダッシュボードを最初から作成するには、ナビゲーションペインの [ Lake ] の [ ダッシュボード ] に移動し、[ 独自のダッシュボードを作成 ] を選択します。[ ダッシュボード の名前を入力 ] フィールドに名前を入力し、[ 権限 ] でイベントデータストアを選択して、イベントを視覚化します。&nbsp;次に、[ ダッシュボードを作成 ] を選択します。 これで、ダッシュボードにウィジェットを追加できます。ダッシュボードは複数の方法で柔軟にカスタマイズできます。[ サンプルウィジェットの追加 ] を使用して事前に作成されたサンプルウィジェットのリストから選択するか、[ 新しいウィジェットの作成 ] を使用して独自のカスタムウィジェットを作成できます。ウィジェットごとに、折れ線グラフ、棒グラフ、またはデータを最もよく表すその他のオプションなど、好みの視覚化のタイプを選択できます。 今すぐご利用いただけます AWS CloudTrail Lake の新機能は、包括的な監査ロギングおよび分析ソリューションの提供における大きな進歩を表しています。これらの機能強化により、より深い理解を得てより迅速に調査を実施できるようになり、AWS 環境全体にわたる予防的な監視とより迅速なインシデント処理が可能になります。 米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (ムンバイ)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、欧州 (ロンドン) の AWS リージョン の CloudTrail Lake で、生成 AI を活用した自然言語クエリ生成 の使用を開始できるようになりました。 CloudTrail Lake の生成 AI を利用したクエリ結果の 要約機能 は、米国東部 (バージニア北部)、米国西部 (オレゴン)、およびアジアパシフィック (東京) リージョンでプレビュー版として利用できます。 強化されたフィルタリングオプション 、 イベントデータストアと ダッシュボード のクロスアカウント共有は、 CloudTrail Lake が利用可能 なすべてのリージョンで利用できます。ただし、Highlights ダッシュボードの生成 AI による要約機能は、米国東部 (バージニア北部)、米国西部 (オレゴン)、およびアジアパシフィック (東京) リージョンでのみ利用できます。 クエリを実行すると、CloudTrail Lake のクエリ料金が発生します。料金の詳細については、 AWS CloudTrail の料金表 をご覧ください。 – Esra 原文は こちら です。