AWS Summit は世界各国で最高潮を迎えており、最近では AWS Summit Singapore が開催されました! こちらは、Developer Lounge ブースでの AWS スタッフと ASEAN コミュニティメンバーの様子です。これには、サーバーレス、 Amazon Elastic Kubernetes Service (Amazon EKS) 、セキュリティ、生成 AI などに関するライトニングトークを行う AWS コミュニティ 講演者が参加しました。 5月6日週のリリース 以下に、私の目に留まったリリースをいくつかご紹介します。もちろん、今回も興味深い生成 AI 機能が盛りだくさんです! Amazon Bedrock での Amazon Titan Text Premier の提供開始 – これは、大規模言語モデル (LLM) の Amazon Titan ファミリーに新しく追加されたモデルで、 Amazon Bedrock のナレッジベース での検索拡張生成 (RAG) や、 Amazon Bedrock のエージェント での関数呼び出しといった主要機能向けに最適化されたパフォーマンスを提供します。 Amazon Bedrock Studio パブリックレビューの開始 – Amazon Bedrock Studio は、ナレッジベース、エージェント、および ガードレール などの Amazon Bedrock の主要機能を備えたラピッドプロトタイピング環境を提供することで、生成 AI アプリケーションの開発を高速化するウェブベースのエクスペリエンスを実現します。 Agents for Amazon Bedrock がプロビジョンドスループット料金モデルのサポートを開始 – エージェント型アプリケーションがスケールするにつれて、アプリケーションにはオンデマンドの上限よりも高い入力/出力モデルスループットが必要になります。プロビジョンドスループット料金モデルにより、特定の基本モデルのモデルユニットを購入できるようになります。 Amazon Bedrock のナレッジベース内のベクトルストアとしての MongoDB Atlas の提供開始 – MongoDB Atlas ベクトルストア統合を使用することで、Amazon Bedrock 内の基盤モデル (FM) に組織のプライベートデータソースをセキュアに接続する RAG ソリューションを構築できます。 Amazon RDS for PostgreSQL が pgvector 0.7.0 をサポート – ベクトル埋め込みを保存するために オープンソースの PostgreSQL 拡張機能 を使用し、生成 AI アプリケーションに検索拡張生成 (RAG) 機能を追加することができます。このリリースには、インデックス化できるベクトルのディメンション数を増やし、インデックスサイズを縮小する機能のほか、距離計算での CPU SIMD の使用に対する追加のサポートも含まれています。 Amazon RDS Performance Insights による Amazon RDS for Oracle での Oracle Multitenant 設定のサポートも開始されました 。 新しいリージョンでの Amazon EC2 Inf2 インスタンスの提供開始 – これらのインスタンスは生成 AI ワークロード用に最適化されており、アジアパシフィック (シドニー)、欧州 (ロンドン)、欧州 (パリ)、欧州 (ストックホルム)、および南米 (サンパウロ) の各リージョンで一般提供されています。 Amazon Polly での新しい生成エンジンの一般提供開始 – Amazon Polly の生成エンジンは、Amazon Polly の最も高度なテキスト読み上げ (TTS) モデルで、現在はアメリカ英語音声が 2 つ (Ruth と Matthew)、イギリス英語音声が 1 つ (Amy) 含まれています。 AWS Amplify Gen 2 の一般提供開始 – AWS Amplify は、TypeScript を使用してフルスタックアプリケーションを構築するためのコードファーストな開発者エクスペリエンスを提供し、開発者が TypeScript でデータモデル、ビジネスロジック、および認証ルールなどのアプリケーション要件を表現できるようにします。プレビューが開始されて以来、AWS Amplify Gen 2 は、カスタムドメイン、データ管理、プルリクエスト (PR) プレビューなどの機能を備えた新しい Amplify コンソールを含めた多数の機能を追加しています。 Amazon EMR Serverless が Amazon Managed Service for Prometheuss による Apache Spark ジョブのパフォーマンスモニタリングを追加 – これは、ジョブ固有のエンジンメトリクスと、Spark のイベントタイムライン、ステージ、タスク、およびエグゼキュータに関する情報を使用して、ジョブを分析、監視、最適化できるようにします。また、 Amazon EMR Studio  の アジアパシフィック (メルボルン) およびイスラエル (テルアビブ) リージョン での提供も開始されました。 Amazon MemoryDB が IAM ポリシー向けの 2 つの新しい条件キーをローンチ – 新しい条件キーは、セキュリティを強化し、コンプライアンス要件を満たすための AWS Identity and Access Management (IAM) ポリシー、またはサービスコントロールポリシー (SCP) の作成を可能にします。また、 Amazon ElastiCache はその最小 TLS バージョンを 1.2 に更新しました 。 Amazon Lightsail がより大きなインスタンスバンドルの提供を開始 – これには、16 個の vCPU と 64 GB のメモリが含まれます。この提供により、Lightsail でウェブアプリケーションをスケールし、より多くの計算集約型量およびメモリ集約型ワークロードを実行できるようになります。 Amazon Elastic Container Registry (ECR) が GitLab Container Registry 向けのプルスルーキャッシュサポートを追加 – ECR を利用するお客様は、アップストリームレジストリをプライベート ECR レジストリ内の名前空間にマップするプルスルーキャッシュルールを作成できます。ルールが設定されると、GitLab Container Registry から ECR 経由でイメージを取得できるようになります。ECR は、キャッシュされたイメージの新しいリポジトリを自動的に作成し、イメージのアップストリームレジストリとの同期を維持します。 AWS Resilience Hub がアプリケーションレジリエンスドリフト検出機能を拡張 – この新しい機能強化は、アプリケーションの入力ソース内でのリソースの追加や削除などの変更を検出します。 AWS からの発表の完全なリストについては、「AWS の最新情報」ページをご覧ください。 その他の AWS のニュース その他の興味深いプロジェクトとブログ記事をいくつかご紹介します。 LLM を使用したゲームの構築 – Banjo Obayomi が行った、Amazon Bedrock で さまざまな LLM を使用してスーパーマリオレベル を生成する楽しい実験をご覧ください! Amazon Q を使用したトラブルシューティング – Ricardo Ferreira が、Apache Kafka、Go、および Protocol Buffers を使用しながら、 厄介なデータのシリアル化問題を解決 した方法を詳しく説明します。 Amazon Q in VS Code の使用開始 – Rohini Gaonkar による 素晴らしいステップバイステップガイド をご覧ください。このガイドでは、生成 AI を活用したコード補完チャットや生産性向上能力といった拡張機能のインストール方法を説明します。 AWS オープンソースニュースと更新 – 私の同僚である Ricardo が、AWS コミュニティからの新しいオープンソースプロジェクト、ツール、イベントなどに関する記事を書いています。最新情報については、 Ricardo のページ をご覧ください。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summits – クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントに参加しましょう。最寄りの都市でご登録ください。日程は、 バンガロール (5 月 15～16 日)、 ソウル (5 月 16～17 日)、 香港 (5 月 22 日)、 ミラノ (5 月 23 日)、 ストックホルム (6 月 4 日)、および マドリッド (6 月 5 日) です。 AWS re:Inforce – 米国ペンシルバニア州で 6 月 10～12 日に開催される AWS re:Inforce で、2 日半にわたる生成 AI 時代の没入型クラウドセキュリティ学習に参加しましょう。 AWS Community Day  – 世界中のエキスパート AWS ユーザーや業界リーダーによるテクニカルディスカッション、ワークショップ、ハンズオンラボが提供されるコミュニティ主導のカンファレンスに参加しましょう。日程は、 トルコ (5 月 18 日)、 中西部 | コロンバス (6 月 13 日)、 スリランカ (6 月 27 日)、 カメルーン (7 月 13 日)、 ナイジェリア (8 月 24 日)、 ニューヨーク (8 月 28 日) です。 今後開催されるすべての AWS 主導の対面イベントおよび仮想イベント と、 開発者向けのイベント をご覧ください。 5月13日週はここまでです。5月20日週の Weekly Roundup もお楽しみに! — Abhishek この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

日本の医療情報システムでは、 3 省 2 ガイドライン ( 厚生労働省が定めた「 医療情報システムの安全管理に関するガイドライン 」 、総務省・経済産業省が定めた「 医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン 」の総称 ) に即したシステムを構築する必要があります。 前回の 医療情報ガイドラインをクラウド上で実践する – ネットワーク編 Part 1 では、AWS の責任共有モデルに触れ、どのように医療機関等のお客様が運用の負担を軽減できるかについて紹介しました。また、医療機関等とクラウドをセキュアに接続する方法として専用線的接続や IPsec VPN を利用した拠点間接続のネットワーク構成について解説しました。 Part 2 では、拠点間接続と比較し導入が容易な、オープンなネットワークで HTTPS を利用した接続を AWS で実現する構成について解説します。ユースケースとしては、 HL7 FHIR API や DICOMweb 等の標準規格を利用した医療機関等からのデータ収集基盤へのアクセスなどが考えられます。その他にも地域医療連携システムなど、多くの医療機関との連携が必要な場面において導入ハードルの低さのメリットが活かされると考えられます。 厚生労働省ガイドラインの システム運用編 [Control] の「13. ネットワークに関する安全管理措置」では、遵守事項の⑥でオープンなネットワークにおいて、VPN を利用せず HTTPS を利用する場合の対策について以下のように述べられています。 ⑥ オープンなネットワークにおいて、IPsec による VPN 接続等を利用せず HTTPS を利用する場合、TLS のプロトコルバージョンを TLS1.3 以上に限定した上で、クライアント証明書を利用した TLS クライアント認証を実施すること。ただしシステム・サービス等の対応が困難な場合には TLS1.2 の設定によることも可能とする。その際、TLS の設定はサーバ/クライアントともに「TLS 暗号設定ガイドライン 3.0.1 版」に規定される最も安全性水準の高い「高セキュリティ型」に準じた適切な設定を行うこと。なお、SSL-VPN は利用する具体的な方法によっては偽サ ーバへの対策が不十分なものが含まれるため、使用する場合には適切な手法の選択及び必要な対策を行うこと。また、ソフトウェア型の IPsec 又は TLS1.2 以上により接続する場合、セッション間の回り込み（正規のルートではないクローズドセッションへのアクセス）等による攻撃への適切な対策を実施すること。 医療情報システムの安全管理に関するガイドライン 第 6.0 版 システム運用編 [Control] 13. ネットワークに関する安全管理措置より抜粋 オープンなネットワークを利用する際には、 TLS による通信の暗号化と TLS 相互認証 (mutual TLS: mTLS) の実施が明記されています。TLS のプロトコルバージョンを TLS 1.3 以上に限定した上で mTLS を実施すること、TLS 1.3 に制限できない場合は IPA (独立行政法人情報処理推進機構)の発行している TLS 暗号設定ガイドライン 3.0.1 版 の「高セキュリティ型」に準ずることを求めています。 TLS 暗号設定ガイドラインでは、5 章で高セキュリティ型の要求設定をまとめられています。医療情報に関わるシステム担当者はこれらのガイドラインを確認しつつ、システムを設計していく必要があります。 ここからは AWS 上で mTLS を利用したインターネットアクセスの実現方法の例を紹介いたします。 mTLS を利用したクライアント認証 本ブログでは 、mTLS を利用したクライアント認証の実現方法として Amazon API Gateway を利用した実装パターンと、 Application Load Balancer (ALB) を利用した実装パターンについてご紹介します。API Gateway は API の作成、管理、保護、監視などを簡単に行うことができるマネージド型のサービスです。ALB は アプリケーション HTTP トラフィック、HTTP 通信、Web 通信、Web サービスのロードバランシングサービスになります。 API Gateway を利用した実装パターン オープンなネットワークを利用する際に、システムのバックエンドの API を構築し、API のエンドポイントに対して医療機関等から通信を行うケースを考えます。 Amazon API Gateway は、AWS のマネージドサービスであり、シンプルな方法で RESTful API や WebSocket API を作成、デプロイ、管理するためのプラットフォームです。API Gateway を使用することでクライアントアプリケーションとバックエンドのサービスを接続し、効率的に API を作成および公開することができます。API Gateway では RESTful API として REST API と HTTP API を提供 しており、どちらも mTLS 機能が利用できます。 以下は、クライアント証明書発行から API Gateway を用いた mTLS によるアクセスまでの流れを示しています クライアント証明書は AWS Private CA や独自のプライベート CA、サードパーティの認証局の発行する証明書が利用可能です。 Amazon S3 に .pem ファイル拡張子が付いたテキストファイルである信頼ストア (トラストストア) をアップロードし、カスタムドメインの設定でトラストストアまでの S3 のパスを指定することで、API にアクセスする際の証明書の検証が可能になります。また、S3 バケットに証明書失効リスト (CRL) をアップロードし Lambda オーソライザー を実装することでクライアント証明書の失効チェックを行うことも可能です。詳細は、 How to implement client certificate revocation list checks at scale with API Gateway をご確認ください。 API Gateway では、 カスタムドメインを作成し mTLS を要求する API エンドポイント が作成可能です。 API 作成時に発行されるデフォルトエンドポイント ( xxxx.execute-api.<region>.amazonaws.com ) については 無効化する ことで、アクセス時に mTLS での接続を強制することが可能です。 詳細は、 Introducing mutual TLS authentication for Amazon API Gateway と、開発者ドキュメントの REST API の相互 TLS 認証の設定 や HTTP API の相互 TLS 認証の設定 をご確認ください。 医療情報ガイドラインに準じた構成を実現するためには TLS のバージョンを制限することも必要です。 API Gateway では、セキュリティポリシーと呼ばれる事前定義済みの最小 TLS バージョンと暗号スイートの組み合わせをご利用いただけます。 TLS 1.2 セキュリティポリシーを選択した場合、セキュリティポリシーは TLS 1.2 および TLS 1.3 トラフィックを受け入れ、TLS 1.0 トラフィックを拒否します。詳細は、 API Gateway でカスタムドメインのセキュリティポリシーを選択する をご確認ください。 Application Load Balancer を利用した実装パターン 次に、ALB を利用するパターンを考えます。 Application Load Balancer (ALB) は AWS のマネージドロードバランサーサービスの 1 つであり、ALB は、受信したトラフィックを複数のアベイラビリティーゾーンの複数のターゲット (EC2 インスタンス、コンテナ、IP アドレスなど) に自動的に分散し、アプリケーションの可用性を向上させることのできるソリューションです。ALB は第 7 層であるアプリケーションレイヤーで機能します。 2023 年 11 月 にALB における mTLS 機能がサポートされたため、マネージドサービスを利用して厚生労働省の要件に準拠したネットワークの構成をとることができるようになりました。 以下は、クライアント証明書発行から ALB を用いた mTLS によるアクセスまでの流れを示しています。 2023 年 11 月に発表された ALB における mTLS のクライアント証明書の処理方式には、信頼ストア (トラストストア) 方式とパススルー方式の 2 つの方式が存在します。 (※ クライアント証明書は X.509 v1 はサポート対象外であり、 X.509 v3 を利用してください 。) トラストストア方式では、ALB がクライアント認証の機能を担い、クライアントと ALB 間で mTLS の通信を行います。こちらの方式では、トラストストア機能により、AWS Private CA またはその他のサードパーティ CA によって生成されたルート証明書や中間証明書を含む CA バンドルを信頼するソースとしてアップロードして、クライアント証明書を検証できます。トラストストアには、CA、信頼できる証明書、およびオプションで証明書失効リスト (CRL) が含まれ、ロードバランサーはトラストストアを使用してクライアントとの相互認証 (mTLS) を行います。 パススルー方式では、クライアントから受信したすべてのクライアント証明書チェーンを、HTTP ヘッダー ( x-amzn-mtls-clientcert ヘッダ) を使用してバックエンドアプリケーションに送信します。mTLS 対応の ALB は、ハンドシェイクでクライアント証明書を取得し、TLS 接続を確立して、HTTP ヘッダーで取得したものをターゲットアプリケーションに送信します。そのため、アプリケーションは、クライアントを認証するためにクライアント証明書チェーンを検証する必要があります。利用例としては、OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens ( RFC8705 ) のように、クライアント証明書を紐付けたアクセストークンの発行など、アプリケーション側でクライアント証明書を利用する場合などが挙げられます。 ALB では、TLS 1.3 をサポートしています。ALB のセキュリティポリシーを利用することで、ワークロードを安全に保ちながら、アプリケーションサーバーのパフォーマンスの最適化を実現できます。また、 TLS 1.3 のみに利用を制御するセキュリティポリシーである ELBSecurityPolicy-TLS13-1-3-2021-06 もお選びいただくことが可能です。詳細は、 Application Load Balancer 用の HTTPS リスナーを作成する をご確認ください。 その他の実装パターン： ALB の mTLS 機能の登場以前から mTLS を利用して EC2 へ アクセスを行う際は、 NLB (Netwok Load Balancer)の TCP リスナーを利用し EC2 インスタンス内の実装で TLS を終端する方式 が利用されていました。NLB は、AWS のマネージドロードバランサーサービスの 1 つです。NLB は、トラフィックを受信し、負荷分散してバックエンドのターゲットグループに配信する役割を担います。第 4 層であるトランスポートレイヤーで機能し、高いスループットと低レイテンシの要件を満たすように設計されています。システムの要件に応じてこれらの実装パターンもご検討ください。 まとめ オープンなネットワークで設計する際は、医療機関等における導入が簡便な点がメリットとして享受できますが、一方で、クライアント証明書の配布方法や、証明書の有効期限の管理など、ハイブリッド接続と同等のセキュリティを担保するための運用設計についても考えることが重要となります。また、 AWS の提供する Web Application Firewall のサービスである、AWS WAF によるコンテンツへのアクセスを制御などと組み合わせて利用しセキュリティを高めることも重要となります。本日ご紹介した API Gateway と ALB はどちらも WAF に対応したサービスとなっております。ぜひ併せてご活用ください。 本ブログでは、オープンなネットワークで HTTPS で医療機関等から AWS への接続を実現するための構成例についてご紹介しました。API Gateway や ALB では mTLS を利用したクライアント認証を構築することが可能となります。本ブログが、読者の皆様のガイドライン対応の一助となれば幸いです。 著者について Yohei Katayama AWS Japan のパブリックセクターのソリューションアーキテクトです。主に医療機関をはじめとしたヘルスケア業界のお客様のソリューション構築の支援を行なっています。週末は登山を嗜んでいます。 Hiroaki Yoshimura AWS Japan のパブリックセクターのソリューションアーキテクトです。主に医療機関をはじめとしたヘルスケア業界のお客様のソリューション構築の支援を行なっています。週末は料理をしたり、美味しいご飯を求めて都内を歩いています。

人工知能 (AI) と機械学習 (ML) により、パーソナライズされたユーザー体験を簡単に作成できます。あなたがデジタルメディアを展開している場合、 AI/ML を使用して、個々のユーザーの関心に合わせてコンテンツを表示およびレコメンドすることができます。パーソナライズは顧客満足度を高め、ユーザーエンゲージメントを向上させ、編集およびコンテンツ作成スタッフの作業負荷を軽減できます。このブログ記事では、Amazon Web Services(AWS) の AI/ML サービスである Amazon Personalize を使用して、コンテンツをカスタマイズする方法について説明します。 パーソナライゼーションの利点 パーソナライゼーションの価値は、複数の業界で実証されています。 2021 年のマッキンゼー社の報告書 によると、71% の顧客がオンラインでパーソナライズされた体験を期待しており、自分の嗜好に基づいてコンテンツや製品をレコメンドする企業を好んでいます。パーソナライゼーションを実施した企業は、それらの活動から 10~15% の収益増加を見ました。 デジタルメディアを展開しているパブリッシャーもパーソナライゼーションから同様の恩恵を受けています。例えば、中央ヨーロッパの大手ニュースサイトは、AWS パートナーである Ring Publishing が作成したパーソナライゼーションサービス を導入しました。Ring のサービスは、ユーザーの関心に合わせてホームページをカスタマイズします。このニュースサイトは、ユーザーエンゲージメントが 30% 増加し、消費されるコンテンツの多様性が 400% 増加しました。つまり、ユーザーはサイトに長く滞在し、より幅広いコンテンツとのやり取りをしていたのです。編集者も、ホームページの管理に費やす時間が 50% 減り、新しいコンテンツの作成などの他の作業に集中できるようになりました。 Amazon Personalizeの利用 従来、パブリッシャーはユーザー体験をパーソナライズするために複雑なルールを作成していました。ユーザーが条件 A 、 B 、 C に合致した場合、コンテンツ X 、 Y 、 Z を表示するといったルールです。しかし、ルールベースのシステムは脆弱で保守が難しい傾向があります。ユーザーが実際に行動したことから学習しないためです。代わりに、プログラマーが状況の変化に対応するためにルールを手動で更新する必要があります。 Amazon Personalize のようなサービスは、より簡単でスケーラブルな方法でおすすめを行うことができます。特別なコードを書く代わりに、データセットに対して AI/ML アルゴリズム(レシピ)を実行してトレーニングし、おすすめを行えるようにします。 Amazon Personalize には、さまざまなおすすめシナリオに対応する複数のレシピが用意されています。ユーザーに表示するコンテンツをパーソナライズするには、 “User Personalization” レシピを使用できます。 図1. Amazon Personalizeとの典型的なやりとり レシピを使用するには、最初にユーザー、コンテンツアイテム、およびコンテンツとの過去のユーザーインタラクションに関するデータをインポートします。次に、通常は Amazon Simple Storage Service (Amazon S3) バケットからデータを読み取らせることで、レシピを訓練してモデルを作成します。最低でも 1,000 回のインタラクションと、それぞれ少なくとも 2 回のインタラクションを持つ 25 人のユーザーをインポートする必要があります。 この記事の執筆時点では、 Amazon Personalize は最大 1 億人のユーザーと 30 億回のインタラクション を訓練目的で考慮します。訓練データが多ければ多いほど、おすすめの精度が高くなります。ただし、訓練時間に応じて課金されるため、予算と訓練目標のバランスを取る必要があります。訓練が完了したら、モデルをキャンペーンの一部として展開し、レコメンドをリクエストできるようになります。学習、デプロイ、レコメンドリクエスト、価格設定の詳細については、 Amazon Personalize のドキュメント をご覧ください。 ニュースの速報や映画レビューなど、新しいコンテンツアイテムが公開された場合はどうなるでしょうか。アイテムが新しいため、モデルにはユーザーがそのコンテンツに興味があるかどうかを知るインタラクションデータがありません。 User Recommendations レシピはこの問題を 2 つの方法で解決しています。 1 つ目は、レシピが自動的に新しく公開されたアイテムの一定割合をおすすめに含めることで、ユーザーがそのコンテンツにどのように反応するかのデータを収集できることです。キャンペーンのセットアップ時に、おすすめに含める新しいアイテムの割合を制御できます。システムが新しいアイテムをおすすめする 2 つ目の方法は、コンテンツデータをロードする際に提供された説明、リリース日、キーワードなどのメタデータを調べることです。レシピはメタデータを使用して、新しいアイテムが以前に公開されたコンテンツとどの程度類似しているかを判断します。そして、その類似性に基づいておすすめを行うことができます。新しいアイテムや、いわゆるコールドアイテムの取り扱いについては、 こちらで詳しく説明されています 。 コンテキストとメタデータを使ってレコメンデーションを改善する ユーザー、アイテム、インタラクションに関するメタデータは、関連性の高いレコメンデーションを行う上で非常に重要です。説明やキーワードなどのメタデータが、 Amazon Personalize に新しいコンテンツをレコメンドするのに役立つことは既に説明しました。ユーザーのメタデータも、レシピがユーザーの関心事を理解するのに役立ちます。例えば、国の異なる地域の読者が特定のトピックに興味があることがわかっている場合は、ユーザーデータセットに位置情報を含めるべきです。 Amazon Personalize がユーザーにレコメンデーションを行う際、ユーザーの位置を考慮に入れます。 インタラクションデータにもメタデータを追加できます。少なくともインタラクションにはユーザーとコンテンツアイテムの識別子、およびインタラクションが発生した時刻のタイムスタンプを含める必要があります。コンテキストのメタデータも非常に価値があります。例えば、ユーザーは使用デバイスによって読書習慣が変わることがよくあります。携帯電話では、ユーザーは短いコンテンツアイテムを好む傾向があります。デスクトップやタブレットを使用する場合は、長いコンテンツを好む可能性があります。したがってインタラクションデータセットにデバイスの種類を記録しておくと、 Amazon Personalize がこの行動から学習できるようになるため良いでしょう。レコメンデーションリクエストを送信する際、ユーザーの現在のデバイスの種類をコンテキストパラメータとして含めることができます。 Amazon Personalize はそのコンテキストを応答に反映させます。重要になるかもしれないその他のコンテキスト項目には、利用可能な帯域幅、インタラクションが発生した地理的位置、あるいは天気などもあります。例えば食べ物や飲み物に関するコンテンツを出している場合、天気が暑いときは Amazon Personalize にアイスドリンクや冷たいデザートをレコメンドさせたいかもしれません。 ユーザーとコンテンツに最適なレコメンデーションを得るまで、データセットに提供するメタデータを試行錯誤し、作業を繰り返す必要があります。 メタデータとコンテキストの重要性を説明したブログ記事はこちら にあります。ユーザーがどれだけのコンテンツアイテムを閲覧し、コンテンツとどれだけ長く関わったかを示すメトリクスを追跡してください。次に、異なるメタデータオプションを比較するために A/B テストを実行できます。エンゲージメントメトリクスが改善されれば、適切なコンテキストとメタデータを提供していることがわかります。 ユーザーに興味のあるものだけを常に表示すべきか? コンテンツをパーソナライズする際、 “ filter bubbles ” や “echo chambers” を作らないよう注意する必要があります。ユーザーは興味のあるものしか見られなくなるため、新しいものを探索したり発見する能力を失ってしまいます。パーソナライズに依存するあらゆる業界でフィルターバブルが起こり得ます。ある食品配達サービスの ML エンジニアは、 ブログ投稿 で「質の高いレコメンデーションとパーソナライズを行うには、ユーザーについて既知の情報と、彼らが好むかもしれない新しいものを上手にバランスさせる必要がある」と指摘しています。 Amazon Personalize はユーザーが新しいものを探索する必要性を認識しており、レコメンデーションに「探索アイテム」を含めることができます。 User Personalization レシピには、 exploration_weight と exploration_item_age_cut_off のパラメータがあり、システムのセットアップ時に設定できます。 weight を 0 に設定すると、レコメンデーションに探索アイテムは含まれません。 1.0 に近づけるほど、より多くのアイテムが含まれます。デフォルト値は 0.3 です。 age cutoff パラメータは、探索アイテムの最大経過日数を制御します。例えば、値を 7 に設定すると、 7 日以上経過したコンテンツは探索アイテムとして含まれなくなります。 ニュースや学術出版社は、ユーザーにどの程度パーソナライズされたコンテンツを表示するかについて特に敏感です。これらのパブリッシャーは権威ある声を重視しており、専門家が選んだコンテンツを強調したがります。 2018 年、 ニューヨーク・タイムズの CTO は次のように説明 しています。「ニュースのパーソナライズについて、読者は複雑な気持ちを抱いている。判断と権威に基づいて世界を描写されたものと、自分の関心を反映したものの両方を求めている」 ニューヨーク・タイムズは、ホームページの特別な 「For You」 セクションでのみパーソナライズされたコンテンツを表示することで、編集権を維持しています。 AWS パートナーの Ring Publishing も、編集者が選んだコンテンツとパーソナライズされたコンテンツのバランスを取る同様のアプローチを採用しています。 Ring のソリューションでは、編集者がホームページの特定のブロックをパーソナライズ専用に指定できる一方、他の部分は編集者が選んだコンテンツや、編集者と AI が選んだコンテンツの混合になっています。 Amazon Personalize を使えば、パーソナライズされたアイテムと手動で選択されたアイテムを組み合わせたレコメンデーションを表示できます。 User Recommendations レシピは、 Promotions を通してこの使用例をサポートしています。まずアイテムデータセットで、編集者が選んだコンテンツをメタデータフィールドで識別します。例えば 「SELECTED」 というフィールドを作り、 「True」 または 「False」 を設定します。次にレコメンデーションを要求する際、プロモーションアイテムの割合と、作成したメタデータフィールドを選択するプロモーションフィルターを指定します。この場合、フィルター式は次のようになるでしょう。 INCLUDE ItemID where Items.SELECTED IN ("True") レコメンデーションでコンテンツアイテムを促進する詳細については、 Amazon Personalize のドキュメント をご覧ください。 まとめ このブログ記事では、 Amazon Personalize でよりよいユーザー体験を作成する方法について説明しました。デジタルメディアを展開している場合、ユーザーにコンテンツをパーソナライズすることで以下が可能になります。 ユーザーエンゲージメントの向上 スタッフの生産性向上によるコスト削減 コンテンツ消費の多様化による投資の最大化 パーソナライズには全てに対応できる解決策はありません。各パブリッシャーは、ビジネスニーズを満たすためにアプローチをカスタマイズする必要があります。新しいコンテンツと古いコンテンツをどの程度レコメンドするべきでしょうか ? 手動で選択したコンテンツと AI が選択したコンテンツをどのくらいの割合でレコメンドするべきでしょうか ? ユーザーの関心に合わせたコンテンツと新しいコンテンツの探索をどの程度奨励すべきでしょうか ? どのメタデータとコンテキストフィールドが最も関連性が高いでしょうか ? パブリッシャーは、パーソナライズをユーザーに最高の体験を提供するために、時間をかけて改善・調整を重ねる反復プロセスとして扱うべきです。 パブリッシャーとして、パーソナライズがどのように顧客満足度を高め、イノベーションにつながり、コストを削減し、効率を上げるかを決定します。 Amazon Personalize の詳細については、 サービスドキュメント をご覧いただくか、 AWS の担当者にお問い合わせください。 翻訳は ソリューションアーキテクト 紙谷が担当しました。原文は こちら です。 Demian Hess Demian Hess は AWS のシニアパートナーソリューションアーキテクトであり、デジタル出版に注力しています。出版業界で 18 年以上の経験を持ち、デミアンはデジタルアセット管理、コンテンツ管理、および NoSQL とセマンティック Web テクノロジーを使用した柔軟なメタデータスキームについて広く執筆しています。

この記事は Ameya Paldhikar（パートナーソリューションアーキテクト）と Marc Luescher（シニアソリューションアーキテクト）によって執筆された内容を日本語化したものです。原文は「 Filter and Stream Logs from Amazon S3 Logging Buckets into Splunk Using AWS Lambda 」を参照してください。 Splunk AWS のお客様 (スタートアップ企業から大企業まで) は複数の AWS アカウントを管理しています。マルチアカウントの管理において、AWS が提供する AWS Prescriptive Guidance（AWS規範ガイダンス） に従って、一般にお客様は複数の AWS アカウントにまたがる AWS ログソース (AWS CloudTrail ログ、VPC フローログ、AWS Config ログ) を専用のログアーカイブアカウントの Amazon Simple Storage Service (Amazon S3) バケットに一元化することを一般的に選択しています。 これらの一元化された S3 バケットに保存されるログの量は、AWS アカウントの数やワークロードの規模によっては、非常に多くなる可能性があります (1 日あたり数 TB) 。S3 バケットから Splunk にログを取り込むには、通常、 Splunk add-on for AWS を使用します。これは Splunk Heavy Forwarder 上にデプロイされ、データを S3 から取り込むために独立してポーリングを行います。 これらのサーバーは、ニアリアルタイムのログの取り込みをサポートするために、ログの取り込み量の増加に応じて水平方向にスケールアウトする機能も必要です。この方法は、デプロイメントを管理するための追加のオーバーヘッドがあり、専用のインフラストラクチャを実行するためコストの増加も発生します。 Splunk の取り込みデータ量ベースのライセンスコストを最適化するため、S3 バケットからログのサブセットのみをフィルタリングして Splunk に転送したい場合も考えられます。具体例としては、VPC フローログのうちフィールド “action” == “REJECT” に合致する、拒否されたトラフィックのみを取り込むことが挙げられます。プルベースのログ取り込みアプローチでは、現時点でそれを実現する方法は提供されていません。 この記事では、 AWS Lambda を活用したプッシュメカニズムによって、一元化された Amazon S3 ログバケットから Splunk にログをフィルタリングしてストリーミングする方法を紹介します。プッシュメカニズムには、運用オーバーヘッドが低く、コストが安く、自動スケーリングが可能といった利点があります。Virtual Private Cloud (VPC) フローログで “action” フラグが “REJECT” に設定されているものをフィルタリングし、 Splunk HTTP Event Collector (HEC) エンドポイント経由で Splunk に送信するための手順とサンプルの Lambda コードを提示します。 Splunk はクラウドオペレーション、データと分析、DevOps など多くの分野でコンピテンシーを有する AWS スペシャライゼーションパートナー であり、 AWS Marketplace セラー です。大手組織では、デジタルシステムをセキュアで信頼性の高いものにするために、Splunk の統合セキュリティとオブザーバビリティプラットフォームを活用しています。 アーキテクチャ 図 1 のアーキテクチャ図は、AWS Lambda を使用して VPC フローログを Splunk に取り込むプロセスを示しています。 図 1 – AWS Lambda を使用した Splunk へのログ取り込みのアーキテクチャ 1 つまたは複数の AWS アカウントの VPC フローログは、ログアーカイブ用 AWS アカウント内の S3 ログバケットに集約されます。 S3 バケットは、バケットに保存された各オブジェクトに対して “object create” イベント通知を Amazon Simple Queue Service (SQS) キューに送信します。 Lambda 関数が作成され、関数の イベントソース として Amazon SQS が設定されます。この関数は SQS からのメッセージをバッチでポーリングし、各イベント通知の内容を読み取り、オブジェクトキーと対応する S3 バケット名を特定します。 次に、この関数は S3 バケットに “GetObject” 呼び出しを実行し、オブジェクトを取得します。Lambda 関数は、”action” フラグが “REJECT” ではないイベントをフィルタリングして除外します。 Lambda 関数は、フィルタリングされた VPC フローログを Splunk HTTP Event Collector にストリーミングします。 VPC フローログが Splunk に取り込まれ、Splunk を使用して検索可能になります。 Splunk が利用できない場合や、ログ転送中にエラーが発生した場合、Lambda 関数はそれらのイベントをバックアップ用の S3 バケットに転送します。 前提条件 次の前提条件を満たす必要があります。 VPC フローログを Amazon S3 に出力する – AWS アカウント内の S3 バケットに VPC フローログを出力するように 設定 します。 VPC フローログを取り込むための Splunk の インデックスを作成 します。 Step 1: Splunk HTTP Event Collector (HEC) の設定 まずはじめに、AWS サービスに対して Splunk へデータを転送するための設定をする前に、Splunk HEC に対してデータを受信するための設定をする必要があります。 Splunk Web にアクセスし、 Settings をクリックし、 Data inputs を選択します。 図 2 – Splunk Data inputs HTTP Event Collector を選択し、 New Token を選択します。 以下の 図 3 に示す詳細に従って新しいトークンを構成し、 Submit をクリックします。 Source Type が aws:cloudwatchlogs:vpcflow に設定されていることを確認します。 図 3 – Splunk HEC トークンの設定 トークンが作成されたら、 Global Settings を選択し、 All Tokens が有効になっていることを確認し、 Save をクリックしてください。 Step 2: Splunk の設定 次に、Splunk サーバーの props.conf 内に設定を追加して、改行、タイムスタンプ、およびフィールド抽出が正しく設定されていることを確認する必要があります。$SPLUNK_HOME/etc/system/local/ の props.conf に以下の内容をコピーしてください。これらの設定の詳細については、Splunk の props.conf のドキュメント を参照してください。 [aws:cloudwatchlogs:vpcflow] BREAK_ONLY_BEFORE_DATE = false CHARSET=UTF-8 disabled=false pulldown_type = true SHOULD_LINEMERGE=false LINE_BREAKER=\'\,(\s+) NO_BINARY_CHECK=true KV_MODE = json TIME_FORMAT = %s TIME_PREFIX = ^(?>\S+\s){10} MAX_TIMESTAMP_LOOKAHEAD = 10 # makes sure account_id is not used for timestamp ## Replace unrequired characters from the VPC Flow logs list with blank values SEDCMD-A = s/\'//g SEDCMD-B = s/\"|\,//g ## Extraction of fields within VPC Flow log events ## EXTRACT-vpcflowlog=^(?<version>2{1})\s+(?<account_id>[^\s]{7,12})\s+(?<interface_id>[^\s]+)\s+(?<src_ip>[^\s]+)\s+(?<dest_ip>[^\s]+)\s+(?<src_port>[^\s]+)\s+(?<dest_port>[^\s]+)\s+(?<protocol_code>[^\s]+)\s+(?P<packets>[^\s]+)\s+(?<bytes>[^\s]+)\s+(?<start_time>[^\s]+)\s+(?<end_time>[^\s]+)\s+(?<vpcflow_action>[^\s]+)\s+(?<log_status>[^\s]+) Step 3: イベント通知のための SQS キューの作成 新しいオブジェクト (ログファイル) が Amazon S3 バケットに保存されると、イベント通知が SQS キューに転送されます。以下の手順に従って、SQS キューを作成し、一元化された S3 バケットのイベント通知設定を行います。 AWS アカウントで Amazon SQS コンソール にアクセスし、 キューを作成 を選択します。 標準タイプ を選択し、キューの 名前 を入力します。 設定 内で、 可視性タイムアウト を 5 分 に増やし、 メッセージ保持期間 を 14 日に増やします。以下のスクリーンショットを参照してください。 図 4 – Amazon SQS の設定 キューの保存時の暗号化を有効化するには、 暗号化 を有効に設定してください。 以下のように アクセスポリシー を設定して、S3 バケットがこの SQS キューにメッセージを送信できるようにします。<> 内のプレースホルダーを環境に合わせた値に置き換えてください。 { "Version": "2012-10-17", "Id": "Queue1_Policy_UUID", "Statement": [ { "Sid": "Queue1_Send", "Effect": "Allow", "Principal": { "Service": "s3.amazonaws.com" }, "Action": "sqs:SendMessage", "Resource": "<arn_of_this_SQS>", "Condition": { "StringEquals": { "aws:SourceAccount": "<your_AWS_Account_ID>" }, "ArnLike": { "aws:SourceArn": "<arn_of_the_log_centralization_S3_bucket>" } } } ] } デッドレターキュー を有効にすると、このキューから処理されなかったメッセージが、より詳しい検査のためにデッドレターキューに転送されます。 Step 4: Amazon S3 イベント通知を SQS に送信 SQS キューが作成されたので、次の手順に沿って VPC フローログ保存用の S3 バケットを構成し、すべてのオブジェクト作成イベントの通知をキューに送信します。 Amazon S3 コンソール から、VPC フローログが集約された S3 バケットにアクセスしてください。 プロパティ タブを選択し、 イベント通知 までスクロールして、 イベント通知を作成 を選択してください。 一般的な設定 で適切な イベント名 を入力してください。 イベントタイプ の下で、 すべてのオブジェクト作成イベント を選択してください。送信先の下で SQS キュー を選択し、前の手順で作成した SQS キューを選択してください。 変更の保存 をクリックすると、構成はこのようになります。 図 5 – Amazon S3 のイベント通知 Step 5: バックアップ用の Amazon S3 バケットの作成 ここでは、AWS Lambda 関数が Splunk にデータ配信できない場合でも、フィルタリングされたデータが失われないよう、バックアップ用の S3 バケットを作成します。Lambda 関数は、Splunk への配信に失敗した場合、フィルタリングされたログをこのバケットに送信します。 このドキュメント の手順に従って S3 バケットを作成してください。 Step 6: Lambda 関数用の AWS IAM ロールの作成 AWS IAM コンソール から、 ポリシー メニューにアクセスして ポリシーの作成 を選択します。 ポリシーエディタ オプションで JSON を選択し、以下のポリシーを貼り付けます。<> 内のプレースホルダーを環境に合わせた値に置き換えてください。完了したら 次へ をクリックします。 { "Version": "2012-10-17", "Statement": [ { "Sid": "lambdaPutObject", "Effect": "Allow", "Action": "s3:PutObject", "Resource": "arn:aws:s3:::<your_backsplash_s3_name>/*" }, { "Sid": "lambdaGetObject", "Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::<your_log_centralization_s3_name>/*" }, { "Sid": "lambdaSqsActions", "Effect": "Allow", "Action": [ "sqs:ReceiveMessage", "sqs:DeleteMessage", "sqs:GetQueueAttributes" ], "Resource": "<arn_of_the_SQS_Queue>" } ] } ポリシー名 と 説明 を入力し、 ポリシーの作成 を選択します。 IAM コンソール から、 ロール にアクセスし、 ロールを作成 を選択します。 ユースケース の下で Lambda を選択し、 次へ をクリックします。 許可の追加 ページで、AWS 管理の AWSLambdaBasicExecutionRole ポリシー と、このロールの作成前に作成したカスタムポリシーを選択します。両方のポリシーを選択したら 次へ を選択します。 適切なロール名を入力し、 ロールを作成 を選択します。 Step 7: ログをフィルタリングして Splunk に送信する Lambda 関数の作成 AWS Lambda コンソール にアクセスし、 関数の作成 を選択してください。 基本的な情報 の下で、適切な 関数名 を入力し、 ランタイム では Python でサポートされている最新のランタイムを選択してください。 デフォルトの実行ロールの変更オプション を展開し、 既存のロールを使用する を選択して、前のセクションで作成したロールを選択します。 他の設定はすべて デフォルト のままにして、 関数の作成 を選択してください。 関数が作成されたら、関数内の 設定 タブを選択し、 一般設定 を編集します。 タイムアウト の値を 5 分 に変更し、 保存 をクリックしてください。 環境変数 を編集し、以下のキーと値のペアを追加してください。<> 内のプレースホルダーを、環境に基づいた適切な値に置き換えてください。環境変数を追加したら、 保存 をクリックしてください。 backup_s3 = <backsplash_Amazon_S3_bucket_name_created_in_the earlier_section> splunk_hec_token = <your_splunk_hec_token> splunk_hec_url = <your_splunk_url> :8088/services/collector/raw 関数内の コード タブを選択し、 lambda_function.py を以下の Python コードで更新してください。また、Python コードは こちらの GitHub リポジトリ 内の lambda_splunk_function.py ファイルからアクセスすることもできます。 import os import boto3 import json import gzip import urllib3 import logginglogger = logging.getLogger() logger.setLevel(logging.INFO) s3 = boto3.client('s3') splunk_hec_url = os.environ['splunk_hec_url'] splunk_hec_token = os.environ['splunk_hec_token'] s3_bucket_name = os.environ['backup_s3'] def write_to_backup_s3(data, key): data_bytes=bytes(json.dumps(data).encode()) compressed_data = gzip.compress(data_bytes) try: response = s3.put_object( Bucket = s3_bucket_name, Key = key, Body = compressed_data ) if response['ResponseMetadata']['HTTPStatusCode'] == 200: logger.info('Object written to S3 successfully') except Exception as e: logger.info(f"Error writing object to S3: {e}") return def send_to_splunk_hec(data_list): data = str(data_list)[1:-1] headers = { "Authorization": "Splunk " + splunk_hec_token } http = urllib3.PoolManager(timeout=20) try: response = http.request( "POST", splunk_hec_url, headers=headers, body=json.dumps(data) ) logger.info(f"Splunk HEC Response: {response.status} - {response.data}") return response.status except Exception as e: logger.info(f"HTTP POST error: {e}") return None def filter_data(obj): logs_to_send = [] content = gzip.decompress(obj['Body'].read()).decode('utf-8') flow_log_records = content.strip().split('\n') for record in flow_log_records: fields = record.strip().split() action = fields[12] logger.info(f"Action: {action}") if action == "REJECT": logs_to_send.append(record) logger.info(f"logs_to_send = {logs_to_send}") return logs_to_send def get_object(bucket, key): try: obj = s3.get_object(Bucket=bucket, Key=key) return obj except Exception as e: logger.info(f"Error retrieving S3 object: {e}") return None def lambda_handler(event, context): for record in event['Records']: body = record['body'] logger.info(f"received sqs message: {body}") #Parse the json message message = json.loads(body) try: #extract s3 key and bucket name from the message bucket = message['Records'][0]['s3']['bucket']['name'] s3_key = message['Records'][0]['s3']['object']['key'] #log the bucket and s3_key parameters logger.info(f"bucket: {bucket}") logger.info(f"s3 key: {s3_key}") except Exception as e: logger.info(f"Error retrieving S3 bucket name and/or object key from message: {e}") #if bucket and s3_key are not null, invoke get_object function if not (bucket or s3_key): continue obj = get_object(bucket, s3_key) if not obj: continue filtered_data = filter_data(obj) logger.info(f"filtered data = {filtered_data}") if filtered_data: status = send_to_splunk_hec(filtered_data) logger.info(f"status: {status}") if status != 200: write_to_backup_s3(filtered_data, s3_key) return 関数内の設定タブを選択し、トリガーを選択します。 トリガーを追加 をクリックし、 SQS を選択します。 SQS queue のドロップダウンから、S3 オブジェクト作成のイベント通知用に構成した SQS を選択します。 Activate trigger を選択します。他の設定はすべてデフォルトのままにして、 追加 を選択します。 Step 8: Splunk での VPC フローログの検索 Lambda 関数が作成され、SQS トリガーがアクティブ化されると、関数はすぐに VPC フローログの Splunk への転送を開始します。 Splunk のコンソール を開き、 Searching and Reporting app 内の Search tab に移動します。 次の SPL クエリを実行して、取り込まれた VPC フローログレコードを表示します。<> 内のプレースホルダーを適切な Splunk インデックス名に置き換えてください（ index = <insert_index_name> sourcetype = “aws:cloudwatchlogs:vpcflow” )。 図 6 – Splunk での VPC フローログの検索 まとめ 本記事では、AWS Lambda 関数を利用して、VPC フローログをフィルタリングして Splunk に取り込む方法について詳しく説明しました。VPC フローログを例として使用しましたが、Amazon S3 バケットに保存されている複数のログタイプに対して同様のアーキテクチャパターンの適用を検討できます。 このコード例では、プッシュベースのメカニズムを使用して、Amazon S3 に一元化された AWS やそれ以外のログを Splunk に取り込むための拡張可能なフレームワークを提供します。Lambda 関数でフィルタリングを実装することで、関心のあるログのみを取り込むことができるため、Splunk ライセンスの使用を最適化してコストを削減できます。 Splunk の詳細については、 AWS Marketplace で確認することもできます。 . . Splunk – AWS Partner Spotlight Splunk は AWS スペシャライゼーションパートナー であり、クラウドオペレーション、データと分析、DevOps など多くの分野でコンピテンシーを有しています。大手組織では、デジタルシステムをセキュアで信頼性の高いものにするために、Splunk の統合セキュリティとオブザーバビリティプラットフォームを活用しています。 Contact Splunk | Partner Overview | AWS Marketplace | Case Studies 記事を読んでいただきありがとうございました。 本記事はパートナーセールスソリューションアーキテクトの宮城康暢が翻訳しました。原文は「 Filter and Stream Logs from Amazon S3 Logging Buckets into Splunk Using AWS Lambda 」を参照してください。

本記事は、 Integrate Amazon Aurora MySQL and Amazon Bedrock using SQL を翻訳したものです。翻訳はSr. Database Solutions Architectの杉山が担当しました。 組織は大量のデータをリレーショナルデータベースに保存しているため、エンドユーザーエクスペリエンスを向上させるために生成AIの基盤モデルを使ってこれらのデータセットを補強する明確な動機があります。この記事では、 Amazon Aurora Machine Learning を使用して、 Amazon Aurora MySQL互換エディション を生成AIモデルと統合する方法を探ります。Amazon BedrockとのAmazon Aurora MySQLの統合について説明し、2つのユースケースを紹介します: サービス改善のためのデータベース情報の補完 – Amazon Bedrockで生成した補足情報をAuroraデータベースに保存し、リアルタイムにアクセス可能にします 生産性の向上 – Auroraデータベースに保存された長い文書をAmazon Bedrockで要約します Amazon Aurora MySQLでMLを使用する他の方法については、「 Build a generative AI- powered agent assistance application using Amazon Aurora and Amazon SageMaker JumpStart 」を参照してください。 Solution overview 生成人工知能  (生成AI)は、会話、物語、画像、動画、音楽など、新しいコンテンツやアイデアを生成できるAIの一種です。 基盤モデル (FM)は、幅広い一般化されたラベル付けされていないデータで訓練された機械学習(ML)モデルです。これらは様々な一般的なタスクを実行できます。 大規模言語モデル (LLM)はFMの一種です。LLMは要約、テキスト生成、分類、オープンエンドの会話、情報抽出などの言語ベースのタスクに特化しています。 このソリューションは、以下の主要コンポーネントに基づいています: Amazon Aurora – Amazon Aurora は、MySQL及びPostgreSQLと互換性のあるクラウド向けのリレーショナルデータベース管理システム(RDBMS)です。Auroraは商用データベースに匹敵するパフォーマンスと可用性を、10分の1のコストで提供します。Aurora MLを使えば、従来のSQLプログラミング言語でさまざまなML アルゴリズム(MLベースの予測、生成AI、感情分析など)を呼び出すことができます。Aurora MLを使うためにMLの経験は必要ありません。Aurora MLは、Aurora とAWS ML サービスとの間で、カスタムインテグレーションを構築したりデータを移動させたりすることなく、簡単で最適化され安全な統合を提供します。AuroraはFMを含むさまざまなMLアルゴリズムのために Amazon SageMaker または Amazon Bedrock を、 感情分析 のために Amazon Comprehend を呼び出すので、アプリケーションからはこれらのサービスを直接呼び出す必要はありません。 Amazon Bedrock – Amazon Bedrockは、AI21 Labs、Anthropic、Cohere、Meta、Mistral AI、Stability AI、Amazonなどの主要AI企業から高性能の基盤モデル(FM)を1つのAPIで選択できる、完全マネージドサービスです。また、セキュリティ、プライバシー、責任あるAIが組み込まれた生成AIアプリケーションを構築するための幅広い機能セットも提供します。Amazon Bedrockは、FMを使って生成AIアプリケーションを構築およびスケーリングする簡単な方法を提供します。Amazon Bedrockはサーバーレスなので、インフラストラクチャを管理する必要がなく、既に慣れ親しんだAWS サービスを使って、安全に生成AI機能をアプリケーションに統合およびデプロイできます。 次の図は、Amazon Aurora MySQLでMLを使用する例を示しています 以下のセクションでは、Amazon Aurora MySQLからSQLクエリを使ってAmazon Bedrockをリアルタイムで呼び出す方法を実演していきます。手順概要は以下の通りです: 1. 新しいクラスターを作成 2. データベースとデータベースユーザーを作成 3. Auroraクラスターのための AWS Identity and Access Management (IAM) ロールとポリシーを作成 4. IAMロールをAuroraクラスターに割り当てる 5. Amazon Bedrockベースモデルを有効にしてAurora MLを使用 6. Amazon Bedrockにアクセスする関数を作成 Prerequisites この投稿では、 AWS管理コンソール の操作に慣れている事を前提としています。 また、AWS アカウントで以下のリソースとサービスが有効になっている必要があります: Amazon Bedrockとの統合を使用するには、Amazon Aurora MySQL 3.06.0以降のバージョンが必要です。 Aurora MySQLクラスターはカスタムDBクラスターパラメータグループを使用する必要があります。 ロールと権限を作成するには、IAMへのアクセス権が必要です。 Amazon BedrockでFMを使用するためのアクセス権が必要です。 この投稿では、 Amazon Titan Text G1 – Express (amazon.titan-text-express-v1)と Anthropic Claude 3 Haiku (anthropic.claude-3-haiku-20240307-v1:0)を使用しています。各リージョンでサポートされているModelに関しては、 Model support by AWS Region を参照してください。 MLサービスは、Aurora MySQLクラスターと同じAWS リージョン で実行されている必要があります。 Aurora MySQLクラスターの ネットワーク構成 が、Amazon Bedrockのエンドポイントへの接続を許可している必要があります。(Amazon Bedrockエンドポイントに対して https アクセスを許可) Create an Aurora MySQL cluster 最初のステップは、Aurora MySQLクラスターを作成することです。完全な手順については、「 Creating and connecting to an Aurora MySQL DB cluster 」と「 Using Amazon Aurora machine learning with Aurora MySQL 」を参照してください。この例で使用する特定の構成オプションをいくつか紹介します: Auroraコンソールで、 Amazon Bedrock をサポートしているリージョン に新しいクラスターを作成します(例: us-east-1)。 補足: 2024年5月現在、東京リージョン(ap-northeast-1)ではAnthropic Claude v3 Haikuを サポートしていません 。 エンジンオプション では、 Aurora(MySQL互換) を選択します。 エンジンバージョン は、Amazon Bedrock統合を使用するために Aurora MySQL 3.06.0 を使用します。 設定オプション では、 Auroraスタンダード または Aurora I/O最適化 のいずれかを選択します。 インスタンスの設定では、 インスタンスクラス を選択します。 Amazon Bedrockと統合するには、後でパラメータグループを変更する必要があるため このタイミングで custom DB cluster parameter group を作成し適用します。 Auroraクラスターを作成します。 クラスターがプロビジョニングされた後、Amazon Bedrockとの統合に向けてクラスターを準備するための一連のSQLコマンドを実行する必要があります。 MySQLコマンドラインクライアント を使用して、 rds_superuser_role 権限を持つユーザー( マスターユーザー など)としてAuroraクラスターにログインし以下のコードを実行します。Amazon Bedrock ML関数を使用するには、 AWS_BEDROCK_ACCESS データベースロールをユーザーに付与する必要があります。 mysql> create database bedrockdb; /*** Sample Database ***/ Query OK, 1 row affected (0.03 sec) mysql> create user `bedrock_user`@`%` identified by 'password'; /*** Sample User ***/ Query OK, 0 rows affected (0.30 sec) mysql> GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, INDEX, CREATE ROUTINE, ALTER ROUTINE, EXECUTE ON bedrockdb.* TO `bedrock_user`@`%`; Query OK, 0 rows affected (0.05 sec) mysql> GRANT AWS_BEDROCK_ACCESS TO `bedrock_user`@`%`; Query OK, 0 rows affected (0.01 sec) mysql> SHOW GRANTS FOR `bedrock_user`@`%`\G *************************** 1. row *************************** Grants for bedrock_user@%: GRANT USAGE ON *.* TO `bedrock_user`@`%` *************************** 2. row *************************** Grants for bedrock_user@%: GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER, EXECUTE, CREATE ROUTINE, ALTER ROUTINE ON `bedrockdb`.* TO `bedrock_user`@`%` *************************** 3. row *************************** Grants for bedrock_user@%: GRANT `AWS_BEDROCK_ACCESS`@`%` TO `bedrock_user`@`%` これで、データベースユーザーがAmazon Bedrockと統合する準備ができました。次に、Aurora MySQL DBクラスターにAmazon Bedrockへのアクセス権を付与する為にIAMロールを作成します。 Create an IAM role and policy for the Aurora cluster Aurora MLがAmazon Bedrockとうまく連携できるようにするには、まず Aurora クラスターがAmazon Bedrockモデルと通信できるようにするIAMポリシーを作成する必要があります。以下の手順を実行してください: IAMコンソールで、ナビゲーションペインから「 ポリシー 」を選択します。 「 ポリシーの作成 」を選択します。 「 アクセス許可を指定 」ページで、「 サービスを選択 」から「 Bedrock 」を選択します。 ポリシーエディタで、「 Bedrock 」を展開し、「 読み取り 」の下にある「 InvokeModel 」を選択して、そのアクションを許可します。 「リソース」では、「 すべて 」または「 特定 」を選択します。チームが必要とするAmazon Bedrock内のモデルにのみアクセスを許可することがベストプラクティスです。(ここではデモ用にすべてを選択しています) 「 次へ 」を選択します。 「 ポリシー名 」には、ポリシーの名前(例: AuroraBedrockInvokeModel )を入力します。 「 ポリシーの作成 」を選択します。 IAMコンソールで、ナビゲーションペインから「 ロール 」を選択します。 「 ロールの作成 」を選択します。 「 信頼されたエンティティタイプ 」では、「 AWSのサービス 」を選択します。 「サービス」または「ユースケース」では、「 RDS 」を選択します。 「 RDS – Add Role to Database 」を選択します。 「 次へ 」を選択します。 前の手順で作成したIAMポリシーを、この作成中のIAMロールに割り当てます。 「 許可ポリシー 」で、作成した「 AuroraBedrockInvokeModel 」ポリシーを検索して選択します。 「 次へ 」を選択します。 「 ロールの詳細 」セクションで、ロール名(この例では AuroraBedrockRole )と説明を入力します。 作成するIAMロールを確認し、 AuroraBedrockInvokeModel ポリシーが付与されていることを確認します。 「 ロールを作成 」を選択してロールを作成します。 Assign the IAM role to the Aurora cluster 次に、作成した AuroraBedrockRole というIAMロールをAmazon Aurora MySQLクラスターに割り当てる必要があります。以下の手順に従ってください: Amazon RDSコンソールで、Aurora MySQLクラスターの詳細ページに移動します。 「 接続とセキュリティ 」タブで、「 IAMロールの管理 」セクションを探します。 「 このクラスターに追加する IAM ロールを選択 」で、作成した AuroraBedrockRole ロールを選択。 「 ロールの追加 」を選択します。 作成したこのIAMロールのARNを、Aurora MySQLクラスターに関連付けられているカスタムDBクラスターパラメータグループの aws_default_bedrock_role パラメータに追加します。 「変更を保存」を選択して設定を保存します。 パラメータの確認は、AWS マネジメントコンソール、AWS コマンドラインインターフェイス (AWS CLI) のいずれかを使用できます。また、次の例のように MySQL クライアントツールを使用して確認することもできます: mysql> show global variables like 'aws_default%'; +-----------------------------+--------------------------------------------------+ | Variable_name | Value | +-----------------------------+--------------------------------------------------+ | aws_default_bedrock_role | arn:aws:iam::012345678910:role/AuroraBedrockRole | | aws_default_comprehend_role | | | aws_default_lambda_role | | | aws_default_s3_role | | | aws_default_sagemaker_role | | +-----------------------------+--------------------------------------------------+ 5 rows in set (0.03 sec) これでクラスターは、Amazon Bedrock 内のモデルを呼び出すことができるようになりました。 Use Aurora ML Aurora MLは、Amazon Bedrock、SageMaker、Amazon Comprehendなど、SQL コマンドを使ってAWS MLサービスと直接連携できるAuroraの機能です。 Amazon Bedrock FMsの一覧は、AWS CLIで確認する事ができます: $ aws bedrock list-foundation-models --query '*[].[modelName,modelId]' --out table ------------------------------------------------------------------------------- | ListFoundationModels | +---------------------------------+-------------------------------------------+ | Titan Text Large | amazon.titan-tg1-large | | Titan Image Generator G1 | amazon.titan-image-generator-v1:0 | | Titan Image Generator G1 | amazon.titan-image-generator-v1 | | Titan Text Embeddings v2 | amazon.titan-embed-g1-text-02 | | Titan Text G1 - Lite | amazon.titan-text-lite-v1:0:4k | | Titan Text G1 - Lite | amazon.titan-text-lite-v1 | ... | Claude | anthropic.claude-v2:1:200k | | Claude | anthropic.claude-v2:1 | | Claude | anthropic.claude-v2 | | Claude 3 Sonnet | anthropic.claude-3-sonnet-20240229-v1:0 | | Claude 3 Haiku | anthropic.claude-3-haiku-20240307-v1:0 | +---------------------------------+-------------------------------------------+ ベースモデルを使用する前に、対象のモデルが Amazon Bedrockコンソール で有効になっていることを確認してください。 有効になっていない場合は、対象の モデルへのアクセスを追加 して下さい。 これで、Aurora から直接Amazon Bedrockにアクセスできる関数を作成できるようになりました。以下の例は、 Amazon Titan Text G1 – Express と Anthropic Claude 3 Haiku モデルを使用してAmazon Bedrockを呼び出す関数を生成する方法を示しています。これらのモデルはTEXTモダリティをサポートしています。別のモデルIDを使用したい場合は、 ベースモデルID のモデルIDと、 Amazon Bedrockでサポートされているモデルのリスト を参照してください。 1. ここでは、先程作成した bedrock_user アカウントでログインします。 2. データベースを bedrockdb に切り替え、ロールを AWS_BEDROCK_ACCESS に設定した後に関数を作成します。関数の定義は GitHubリポジトリ に用意されています。 mysql> use bedrockdb Database changed mysql> SELECT CURRENT_ROLE(); +----------------+ | CURRENT_ROLE() | +----------------+ | NONE | +----------------+ 1 row in set (0.00 sec) mysql> SET ROLE AWS_BEDROCK_ACCESS; Query OK, 0 rows affected (0.00 sec) mysql> SELECT CURRENT_ROLE(); +--------------------------+ | CURRENT_ROLE() | +--------------------------+ | `AWS_BEDROCK_ACCESS`@`%` | +--------------------------+ 1 row in set (0.00 sec) 3, Amazon Titan Text G1 -Express を呼び出す関数を作成します: CREATE FUNCTION invoke_titan (request_body TEXT) RETURNS TEXT ALIAS AWS_BEDROCK_INVOKE_MODEL MODEL ID 'amazon.titan-text-express-v1' /*** model ID ***/ CONTENT_TYPE 'application/json' ACCEPT 'application/json'; 4. Anthropic Claude 3 Haiku を呼び出す関数を作成します: CREATE FUNCTION claude3_haiku (request_body TEXT) RETURNS TEXT ALIAS AWS_BEDROCK_INVOKE_MODEL MODEL ID 'anthropic.claude-3-haiku-20240307-v1:0' CONTENT_TYPE 'application/json' ACCEPT 'application/json'; 5. 「地球の陸地と海の割合は何ですか?」と質問し、Amazon Titanの関数を呼び出します: select json_unquote(json_extract(invoke_titan( '{ "inputText": "What is the proportion of land and sea on Earth?", "textGenerationConfig": { "maxTokenCount": 1024, "stopSequences": [], "temperature":0, "topP":1 } }' ),"$.results[0].outputText")) as bedrock_response\G 6. Anthropic Claude 3の関数を呼び出します: select json_unquote(json_extract(claude3_haiku( '{ "anthropic_version": "bedrock-2023-05-31", "max_tokens": 1024, "messages": [{"role": "user","content": [{"type": "text", "text": "What is the proportion of land and sea on Earth?"}]}], "temperature": 0, "top_p": 0, "top_k":1, "stop_sequences": [] }' ),"$.content[0].text")) as response_from_bedrock\G Amazon Bedrockコンソールの Amazon Bedrock プレイグラウンド で質問の出力を確認することで、レスポンスの正確性を検証できます。詳細については、「 Anthropic’s Claude 3 Haiku model is now available on Amazon Bedrock 」を参照してください。 これで、Amazon Bedrockを使用するためのAuroraクラスターの準備が完了しました。 次のセクションでは、統合されたAmazon Bedrockと既存のデータを使用する2つのユースケースを示します。 Aurora クラスターが Amazon Bedrock と通信できない場合は 、 Aurora クラスターが Amazon Bedrock と通信できるようにネットワーク構成を調整する必要があるかもしれません。この設定方法の詳細については、 Enabling network communication from Amazon Aurora MySQL to other AWS services , Create a VPC endpoint 及び Use AWS PrivateLink to set up private access to Amazon Bedrock を参照してください。 この投稿では、VPC と Amazon Bedrock 間のプライベート接続を使用するために、  bedrock-runtime endpoint  を選択しています。 Use case 1: Complement existing data with Amazon Bedrock 既存のデータをAmazon Bedrockとリンクさせることで、どのように情報を補完できるかを見てみましょう。この例では、まだデータベースにデータがないので、検証目的で新しくテーブルを作成してデータを追加します。テーブル定義は GitHubリポジトリ で提供されています。 サンプルテーブル を作成します: CREATE TABLE `t_bedrock` ( `id` int NOT NULL AUTO_INCREMENT, `country` varchar(52) NOT NULL DEFAULT '', `information` varchar(2048), `modify_user` varchar(255) NOT NULL DEFAULT (current_user()), `updated_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_update_time` (`updated_time`) ) ENGINE=InnoDB AUTO_INCREMENT=1; サンプルデータ を挿入します(これは既にデータベースに格納されている既存のデータと想定してください): insert into t_bedrock(country) values('India'),('China'),('United States'),('Indonesia'),('Brazil'),('Mexico'),('Japan'); データがテーブルに格納されていることを確認します。 テーブルからデータを取得するためのプロシージャを作成し、そのデータに対して関数を実行します。プロシージャの定義は GitHubリポジトリ で提供されています: DROP PROCEDURE IF EXISTS get_bedrock_claude3_haiku; DELIMITER // Create Procedure get_bedrock_claude3_haiku() BEGIN DECLARE done INT DEFAULT FALSE; DECLARE v_id INT; DECLARE v_country varchar(52); DECLARE cursor_bedrock CURSOR FOR SELECT id,country FROM t_bedrock order by id; DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE; OPEN cursor_bedrock; loop_cursor: LOOP FETCH cursor_bedrock INTO v_id,v_country; IF done THEN LEAVE loop_cursor; END IF; set @question = concat('\"messages\": [{\"role\": \"user\",\"content\": [{\"type\": \"text\", \"text\": \"What is the most popular food in ', v_country,' ?\"}]}]}\'),\"$.content[0].text\")) as response_from_bedrock'); set @parameter = '(\'{\"anthropic_version\": \"bedrock-2023-05-31\",\"max_tokens\": 1024,\"temperature\": 0,\"top_p\": 0, \"top_k\":1, \"stop_sequences\": [],'; set @request = concat("update t_bedrock,(select json_unquote(json_extract(claude3_haiku",@parameter,@question,") response set information = response.response_from_bedrock where id =",v_id); PREPARE update_stmt FROM @request; EXECUTE update_stmt; DEALLOCATE PREPARE update_stmt; END LOOP; CLOSE cursor_bedrock; END// DELIMITER ; 既存のテーブルからデータを取得し、対象のデータに基づいてAmazon Bedrockにリクエストを送信し、コンテンツに応じてデータを取得し、テーブルの内容を更新するプロシージャを実行します: mysql> call get_bedrock_claude3_haiku(); その結果、データに対して補完的な情報を取得できているはずです。 次の例では、異なる国々で人気の食べ物をリストアップした結果を確認しています: mysql> select * from t_bedrock limit 1\G 例えば、あなたが旅行サイトを運営していて、自身のサイト上で京都の観光スポットを参考情報として掲載したい場合、次の例のように質問内容を変更すればデータを取得できます。使用例によって必要となるデータは異なりますので、ニーズに合わせて質問をカスタマイズしてみてください: select json_unquote(json_extract(claude3_haiku( '{ "anthropic_version": "bedrock-2023-05-31", "max_tokens": 1024,"temperature": 0,"top_p": 0,"top_k":1,"stop_sequences": [], "messages": [{"role": "user","content": [{"type": "text", "text": "Please tell me 3 recommended sightseeing spots in Kyoto."}]}] }'),"$.content[0].text")) as response_from_bedrock\G Anthropic Claude 3 は、英語、スペイン語、日本語をはじめとする複数の言語をサポートしています。例えば、次のリクエストでは、京都のおすすめ観光スポット5か所を日本語で尋ねています。 select json_unquote(json_extract(claude3_haiku( '{ "anthropic_version": "bedrock-2023-05-31", "max_tokens": 1024,"temperature": 0,"top_p": 0,"top_k":1,"stop_sequences": [], "messages": [{"role": "user","content": [{"type": "text", "text": "京都でお勧めの観光地を教えて下さい"}]}] }'),"$.content[0].text")) as response_from_bedrock\G 次の例として、データベースに格納された長い文章をどのように要約するかも確認しましょう。 Use case 2: Summarize existing data with Amazon Bedrock データベースに格納された長い文章を要約するために Amazon Bedrock を使うと、読みにくさが軽減されます。要約機能を使えば、短時間で概要を把握する事ができます。さらに詳細が必要な場合は、オリジナルのデータを読むこともできます。この使用例は、製品やサービスのレビューの要約や、サポート担当者向けのケースノートの要約などに活用されています。 この使用例では、「 What’s New with AWS? 」からAWSサービスの最新リリースに関するニュースを取得し、データベースに保存します。最初に保存されたデータから製品名のみを取得する処理を行います。次に、リリースノートの要約を行います。テーブル定義は、 GitHubリポジトリ で提供されています。 次の手順を完了してください: 1. データを保存するための サンプルテーブル を作成します: CREATE TABLE `t_feed` ( `id` int NOT NULL AUTO_INCREMENT, `title` varchar(1024) DEFAULT NULL, `link` varchar(2048) DEFAULT NULL, `product` varchar(512) DEFAULT NULL, `description` text, `summary` text, -- `modify_user` varchar(255) DEFAULT (current_user()) COMMENT 'optional column', `updated_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_update_time` (`updated_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; 別のターミナルにて、次の スクリプト を実行してサンプルデータを挿入します (Python 3.7以降が必要です。”python3 feed.py”で実行できます): import pymysql import feedparser import re # if module is not installed, please install it. ex: pip install -r requirements.txt myfeed = feedparser.parse("https://aws.amazon.com/about-aws/whats-new/recent/feed/") db = pymysql.connect( host='<Aurora MySQL Writer Endpoint>', user='<user name>', password='<password>', database='<sample schema (ex: bedrockdb)>', cursorclass=pymysql.cursors.DictCursor) with db: with db.cursor() as cur: for item in myfeed['items']: title = item.title link = item.link description = re.sub(r'<[^>]+>', '', item.description).replace("'", "\\'").replace('"', '\\"').replace('\n', ' ') print (title) print (link) print (description) cur.execute("INSERT INTO t_feed (title, link, description) VALUES (%s, %s, %s)", (title, link, description)) db.commit() print ('Import rss Succesfull!') スクリプトを実行すると、ドキュメントが次のように保存されます: mysql> select count(*) from t_feed; select * from t_feed limit 1\G これで、descriptionカラムから製品名を取得し、productカラムに格納する準備ができました。 descriptionカラムから製品名のみを追加するための プロシージャ を作成します: DROP PROCEDURE IF EXISTS get_rss_product_by_bedrock_claude3_haiku; DELIMITER // CREATE PROCEDURE `get_rss_product_by_bedrock_claude3_haiku`() BEGIN DECLARE done INT DEFAULT FALSE; DECLARE v_id INT; DECLARE v_description text; DECLARE cursor_description CURSOR FOR SELECT id,description FROM t_feed order by id; DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE; OPEN cursor_description; loop_cursor: LOOP FETCH cursor_description INTO v_id,v_description; IF done THEN LEAVE loop_cursor; END IF; set @question = concat('\"messages\": [{\"role\": \"user\",\"content\": [{\"type\": \"text\", \"text\": \"Please pick up product name only from the following description. ', v_description,' ?\"}]}]}\'),\"$.content[0].text\")) as response_from_bedrock'); set @parameter = '(\'{\"anthropic_version\": \"bedrock-2023-05-31\",\"max_tokens\": 1024,\"temperature\": 0,\"top_p\": 0, \"top_k\":1, \"stop_sequences\": [],'; set @request = concat("update t_feed,(select json_unquote(json_extract(claude3_haiku",@parameter,@question,") response set product = response.response_from_bedrock where id =",v_id); PREPARE summarize_stmt FROM @request; EXECUTE summarize_stmt; DEALLOCATE PREPARE summarize_stmt; END LOOP; CLOSE cursor_description; END// DELIMITER ; Amazon Bedrockを使って、descriptionカラムから製品名を取得するためにプロシージャを実行します: mysql> call get_rss_product_by_bedrock_claude3_haiku(); プロシージャを実行した後、productカラムにデータが追加されたことを確認できます。 これにより、コンテンツをより容易に理解する事ができます。 mysql> select * from t_feed limit 1\G descriptionカラムを要約したい場合は、質問を「次の説明を200文字以内で要約してください」のようなものに変更し、更新対象のカラムをsummaryに変更する必要があります。これにより、各説明が約200文字で要約されるため、作業効率が向上します。 descriptionカラムの要約をsummaryカラムに追加するための プロシージャ を作成します: DROP PROCEDURE IF EXISTS get_rss_summary_by_bedrock_claude3_haiku; DELIMITER // CREATE PROCEDURE `get_rss_summary_by_bedrock_claude3_haiku`() BEGIN DECLARE done INT DEFAULT FALSE; DECLARE v_id INT; DECLARE v_description text; DECLARE cursor_description CURSOR FOR SELECT id,description FROM t_feed order by id; DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE; OPEN cursor_description; loop_cursor: LOOP FETCH cursor_description INTO v_id,v_description; IF done THEN LEAVE loop_cursor; END IF; set @question = concat('\"messages\": [{\"role\": \"user\",\"content\": [{\"type\": \"text\", \"text\": \"Please summarize the following description in 200 characters or less. ', v_description,' ?\"}]}]}\'),\"$.content[0].text\")) as response_from_bedrock'); set @parameter = '(\'{\"anthropic_version\": \"bedrock-2023-05-31\",\"max_tokens\": 1024,\"temperature\": 0,\"top_p\": 0, \"top_k\":1, \"stop_sequences\": [],'; set @request = concat("update t_feed,(select json_unquote(json_extract(claude3_haiku",@parameter,@question,") response set summary = response.response_from_bedrock where id =",v_id); PREPARE summarize_stmt FROM @request; EXECUTE summarize_stmt; DEALLOCATE PREPARE summarize_stmt; END LOOP; CLOSE cursor_description; END// DELIMITER ; Amazon Bedrockから要約データを取得するためにプロシージャを実行します: mysql> call get_rss_summary_by_bedrock_claude3_haiku(); プロシージャを実行した後、summaryカラムにデータが追加されたことを確認できます: mysql> select * from t_feed limit 1\G 次の例では、descriptionカラムとsummaryカラムの文字数をチェックしています: mysql> select id,description,summary,length(description),length(summary) from t_feed limit 10; group_concatを使う事で、複数のデータを組み合わせて要約を作成することも可能です。次の出力は、20行からデータを取得し、要約を作成した例です。サンプルコードは GitHubリポジトリ で提供されています。 set session group_concat_max_len = 1048576; set session aurora_ml_inference_timeout = 30000; -- If the data size is small, there is no particular need to limit it. However, if there is a large amount of data, it is limited because PREPARED STATEMENTS can cause errors. -- set @all = (select group_concat(description) from t_feed); set @all = (select group_concat(top20.description) from (select description from t_feed limit 20) top20); set @question = concat('\"messages\": [{\"role\": \"user\",\"content\": [{\"type\": \"text\", \"text\": \"Please categorize and tell me what kind of services improvement being talked about based on the following content. ', @all,' ?\"}]}]}\'),\"$.content[0].text\")) as response_from_bedrock'); set @parameter = '(\'{\"anthropic_version\": \"bedrock-2023-05-31\",\"max_tokens\": 1024,\"temperature\": 0,\"top_p\": 0, \"top_k\":1, \"stop_sequences\": [],'; set @request = concat("select json_unquote(json_extract(claude3_haiku",@parameter,@question); PREPARE select_stmt FROM @request; EXECUTE select_stmt\G DEALLOCATE PREPARE select_stmt; 日本語版の「 What’s New with AWS? 」からAWSサービスの最新リリースに関するニュースを取得する事で、Use case 2で説明したように日本語で要約を作成する事も可能です。 Considerations デモではSQLコマンドを実行すると1分以内に応答が返ってきますが、これはコンテキストの細かさや量によっても変わります。本番環境に導入する前に、この概念実証をご自身の実装に適応させることが重要です。大量の処理を行う予定の場合は、 Amazon Bedrockのクォータ と、 Amazon Bedrockの価格設定 に関しても参照することをお勧めします。 Clean up 作成したリソースを使用する必要がなくなった場合は、終了時に削除してください: データベースから不要なオブジェクトとユーザーを削除します。 Aurora MLを使用する必要がなくなったが、クラスターの使用を続ける場合は、ML関連のパラメーター( aws_default_bedrock_role )とIAMロールをクラスターから削除できます。 Amazon Bedrockにアクセスするために作成したIAMロールが不要になった場合は、削除できます。また、必要に応じてネットワーク設定を更新する必要がある場合があります。 Auroraクラスターが不要になった場合は、「 Aurora DBクラスターとDBインスタンスの削除 」の手順に従って削除してください。 Conclusion 現在の企業は、エンドユーザーエクスペリエンスや生産性の向上のために、リレーショナルデータベースに格納されているデータに 生成AI の機能を組み込みたいと考えています。この投稿では、Amazon Bedrock を使って格納されたデータに対して補完的な情報を取得する方法を実演しました。また、Amazon Bedrock との Aurora ML 統合機能を利用して、Aurora データベースに格納されたドキュメントを要約する方法も実演しました。 Aurora ML を使って SQL 関数として Amazon Bedrock 上の FMs を呼び出せる機能は、生成AI アプリケーションを構築する際に LLM の学習曲線を平滑化します。これにより、カスタム統合を構築したり、データを移動したりすることなく、Aurora と AWS ML サービスを簡単で最適化され、安全な方法で統合できます。 Aurora MLの詳細については、「 Amazon Aurora Machine Learning 」を参照してください。 Amazon Aurora MySQLにおける最新のAurora MLについては、「 Using Amazon Aurora machine learning with Aurora MySQL 」を参照してください。 コメントでフィードバックをお寄せください。 About the Authors Steve Dille は、Amazon Auroraのシニアプロダクトマネージャーです。AWSのAuroraデータベースにおけるgenerative AIの戦略とプロダクトイニシアチブを主導しています。この役割に就く前は、Auroraのパフォーマンスおよびベンチマークチームを創設し、その後Amazon Aurora Serverless v2のRDS Data APIを構築して立ち上げました。AWSには4年間在籍しています。それ以前は、NCRでソフトウェア開発者、HPでプロダクトマネージャー、Sybase(SAP)でデータウェアハウジングディレクターを務めていました。データ管理、分析、ビッグデータ分野で5件の企業買収と1件のIPOに成功した企業の執行役員としてVPまたはCMOを20年以上務めた経験があります。Steveは、UC BerkeleyでInformation and Data Scienceの修士号、シカゴ大学ブース校でMBA、ピッツバーグ大学でComputer Science/Mathの学士号を取得しています。 杉山真也 はアマゾン ウェブ サービス (AWS) でシニアデータベースソリューションアーキテクトを務めています。ハードウェアおよびデータベースソフトウェアベンダーでデータベーステクニカルコンサルタントとして10年間従事した後、インターネット企業において10年以上にわたりサイト運用、サービス開発、管理業務など様々な業務に携わってきました。現在は、主にAmazon RDSおよびAmazon Auroraを使用するMySQLとMariaDBのユーザー企業に対し、課題解決とソリューション提供のサポートを行っています。

このたび、弊社ではデータ活用によるビジネス変革を体感するワークショップを開催する運びとなりました。本ワークショップでは、テクノロジーに留まらず、データが拓くビジネスインサイトとイノベーションの可能性を体感いただけます。プログラミング初心者の方も、ユーザーフレンドリーなツールを使えば問題なくご参加いただけます。 データ活用によるビジネス変革の新たな可能性に関心をお持ちの皆様は、是非この機会をご活用くださいますよう、心よりお待ち申し上げております。 【イベント概要】 Amazon QuickSightの生成AI/BI最新情報を提供、AIストラテジーの可能性を最大化するデータガバナンスについても紹介し、ノーコード/ローコードで構築したMLモデルを活用できる最新の AI 技術と、ビジネスインテリジェンスの実践的な活用方法を学習していただくワークショップを開催いたします。 【アジェンダ】 データアナリスト、データサイエンティスト、データエンジニアの皆様に最適なセミナーです。全8回のデータレクチャとデモを通して、実践的なデータ戦略の立案プロセスを体得いただけます。   10:00 AM – 10:15 AM オープニング 10:15 AM – 10:45 AM AI時代におけるデータガバナンス戦略 10:45 AM – 11:15 AM QuickSight GenBI最新情報とデモ 11:15 AM – 11:35 AM Amazon Q for Businessのご紹介 11:35 AM – 12:05 AM ローコード/ノーコード ML: ビジネスインパクト & AWS ストラテジー 12:05 PM – 13:15 PM ランチタイム 13:15 PM – 14:15 PM Lab 1 Canvas 初期セットアップとGenBIでビジュアル作成 14:15 PM – 15:30 PM Lab 2 Build an ML Model in Amazon SageMaker Canvas & Send it to Amazon QuickSight Lab 3 Add Predictions from SageMaker Canvas Model to Amazon Quicksight 15:30 PM – 15:45 PM Coffee Break 15:45 PM – 16:30 PM Lab 4 Create Dashboard using Prediction and & GenBI Q&A and Stories 16:30 PM – 16:45 PM クロージング ※ハンズオン実習には、個人用ノートPCをご持参ください。 ※本イベントの内容は、状況次第で変更となる場合がございます。あらかじめご了承くださいますよう、お願い申し上げます。   【申込方法】 AWS担当営業までご連絡ください。   【担当講師】 Wakana Vilquin-Sakashita　(AWS シニアソリューションアーキテクト) 大薗 純平　(AWS シニアソリューションアーキテクト) 溝渕 匡　(AWS ソリューションアーキテクト) 本島 久義 (AWS AWS Bigdataコンサルタント) 飯塚 将太 (AWS ソリューションアーキテクト) 井形 健太郎　(AWS 事業開発マネージャー) 松山 航平  (AWS 事業開発マネージャー) 本イベント「ノーコード機械学習&生成AI/BIで加速するデータ活用」に関するご質問がございましたら、AWS チームまでお問い合わせください。

2021 年に ASUG と Pillir が行った研究では、最も重要な SAP カスタムコードの保守費用は年間平均 80 万ドルでした。 組織の 37 % では、これが年間 IT 予算の最大半分を占めていました。 同時に、SAP ユーザーの 91 % がミッションクリティカルなビジネスプロセスの実行を SAP カスタムコードに大きく依存していました。 SAP のアップグレードやモダナイゼーションプロジェクトのたびに、カスタムコードの維持費用は指数関数的に増加しています。 そこで SAP は Clean Core という導入アプローチを推奨しています。これは、SAP S/4HANA コアを標準のままにし、SAP Business Transformation Platform (SAP BTP)や AWS ネイティブクラウドサービスなどの補完的なサービスで機能を拡張する手法です。 クリーンコアアプローチを実現するには、お客様やパートナー様が SAP BTP と AWS Cloud Services の機能を理解し、両者の長所から恩恵を受けられる方法を把握する必要があります。 このブログでは、トレーニングコース「 Build Resilient Applications on SAP BTP with Amazon Web Services 」について紹介し、概要を説明します。 SAP と AWS が共同で実施するこのコースは、両社の戦略的な連携の一環として、受講者に両社の強みを最大限に生かすための知識を提供することを目的としています。トレーニングを通して、クリーンコアアプローチを円滑に実装でき、受講者は両社の利点を簡単に活用できるようになります。 SAP と AWS は 15 年以上にわたり協力して顧客のためにイノベーションを続けています。その継続的なイノベーションの成果が、最近の発表である SAP HANA Cloud が AWS Graviton をサポートした ことです。 戦略的パートナーシップの焦点の 1 つは、 SAP S/4HANA と RISE with SAP および SAP BTP on AWS の採用を加速させることです。 この戦略的パートナーシップによって、SAP BTP と AWS を組み合わせることで、お客様やパートナーに対してイノベーションを起こし、価値を創出するための、それぞれ独自の強みや専門知識、リソースがもたらされます。 図 1 – AWS for SAP BTP フレームワーク フレームワークは次のとおりです。 AWS が SAP Business Technology Platform にもたらすユニークな差別化価値の集合。 アプリケーション開発、自動化、インテグレーション、データと分析、人工知能などの SAP BTP の柱に基づく協調アーキテクチャの集まり。 これらのアーキテクチャが実践でどのように機能するかを示す現実のユースケースの例。 SAP BTP 上に AWS で回復力のあるアプリケーションを構築 Amazon Web Services （ AWS ）と共同で、SAP BTP 上の堅牢なアプリケーションを構築する方法を学ぶ無料コース「 Build Resilient Applications on SAP BTP with Amazon Web Services 」のリリースを発表しました。このコースは、SAP が提供する学習プラットフォーム openSAP で提供されています。 openSAP には 250 万人以上の登録ユーザがおり、ハッソー・プラットナー工科大学によって運営されています。 このトレーニングは、実践的なアプリケーションを提示し、共同革新フレームワークをプロジェクトに効果的に実装できるようにすることで、SAP BTP と AWS サービスの導入を加速することを目的としています。顧客とパートナーに対するイノベーションと付加価値の創造を推進しています。このトレーニングに参加することで、これらのイノベーションをデプロイする実践的な知見を得ることができ、常に進化する技術的環境を確実に理解して、SAP と AWS の優れた技術の特徴を備えたソリューションを提供できるよう十分な準備ができます。 この講座は 5 週間にわたり、SAP BTP と AWS の共同イノベーションの議論をサポートします。 講座には、SAP と AWS が共同で作成した 23 のビデオ録画、16 個のデモ、12 の演習問題が含まれています。 この講座は、アプリケーション開発者、コンサルタント、クラウドソリューションアーキテクト、エンタープライズアーキテクト、クラウドアーキテクチャと開発に興味がある方を広く対象とします。 特に SAP システムやサービスを統合したい AWS エコシステムのユーザには有益です。 このコースはグローバルにアクセスでき、コンテンツは英語で提供されますが、字幕はドイツ語、フランス語、スペイン語など複数の言語が用意されています。 誰でも受講できるよう前提条件は設けていませんが、ハンズオン演習では基本的なプログラミング知識が推奨されます。 コース内には次のようなリファレンスアーキテクチャの例が含まれています。 自動在庫補充通知 : S/4HANA の在庫管理と Amazon AppFlow や SNS などの AWS サービスを組み合わせて、効率的なサプライチェーン運用を実現します。 図 2 — 自動在庫補充通知、リファレンスアーキテクチャ イベント駆動型統合アーキテクチャ: SAP BTP を インダストリー 4.0 のシナリオ に活用し、SAP-AWS 統合の多様性を示しています。 図 3 – イベント駆動型統合アーキテクチャ、リファレンスアーキテクチャ 個人向けの利点: SAP BTP と AWS の深い知識 スキルの向上と資格取得 最新のトレンドを追うこと 競争力の獲得 パートナーのメリット: 競争優位性 (その分野のエキスパートとしての地位) 無料の研修で運営コストを削減 柔軟なペースでの自習学習 定期的にコース内容を更新して継続学習を可能にする コミュニティとネットワーキングの機会 SAP BTP と AWS の専門知識を今日から身につけましょう！ SAP と AWS がイノベーションを続ける中で、このコースは、プロフェッショナルがこれらの企業が提供する技術のスキルと理解を深めるための貴重な機会となります。知識を広げたいか、仕事で活用したいかにかかわらず、このコースは非常に有用なリソースです。 この学びと革新の旅路にご参加ください。そして、私たちで一緒に未来を築いていきましょう！ 「 Build Resilient Applications on SAP BTP with Amazon Web Services 」のコースを今すぐ申し込んでください。 SAP on AWS ディスカッションへの参加 お客様のアカウントチームと AWS サポート の他に、AWS は re:Post サイト で公開の質問とアンサーのフォーラムを提供しています。 SAP on AWS ソリューションアーキテクトチームは、 SAP on AWS のディスカッショントピックを随時監視し、回答できる質問があれば回答して皆さまをサポートしています。 質問がサポート関連でない場合は、 re:Post のディスカッションに参加してコミュニティ知識ベースに投稿することをご検討ください。 クレジット openSAP トレーニングコース「 Build Resilient Applications on SAP BTP with Amazon Web Services 」は、SAP と AWS の専門家の共同作業の成果です。 以下のメンバーに寄与いただき、感謝いたします。Anirban Majumdar、PVN PavanKumar、Weikun Liu、Sivakumar N、Uma Anbazhagan、MadanKumar Pichamuthu、Marc Huber、Praveen Kumar Padegal、Mahesh Palavalli、Shanthakumar Krishnaswamy、Harutyun Ter-Minasyan、Piyush Gakhar、Lalit Mohan Sharma、Divya Mary、Ajit Kumar Panda、Ferry Mulyadi、Diego Lombardini、Himanshu Salathia、Venkat Tatavarthy、Krishnakumar Ramadoss 翻訳は Partner SA 松本が担当しました。原文は こちら です。

エグゼクティブおよびそのチームに実行可能で客観的な洞察を提供する企業である Gartner が  2024 Gartner Magic Quadrant for Global Industrial IoT Platforms を発表しました。 Amazon Web Services (AWS) は、実行力と洞察力を評価され、リーダーに位置付けられました。 このポジショニングは、AWS パートナーおよび顧客がアプリケーションを構築し、パフォーマンス、生産性、効率性の向上を実現できる、AWSの産業分野における広範囲で深い機能力が反映されていると考えています。 過去 5 年間 AWS は産業顧客とパートナーに代わって革新を続け、SCADA やヒストリアン (データ収集システム) などのレガシーシステムに加え、機器やマシンからのデータ解放だけでなく、IoT (モノのインターネット) 接続、エッジコンピューティング、ビッグデータ、高度な分析の統合によってデジタルトランスフォーメーションを支援してきました。 自動化ベンダー、産業システムインテグレーター、独立系ソフトウェアベンダーなどの AWS パートナーとの協業により、製造、エネルギー、公益事業、運輸・物流など、さまざまな分野の特殊ユースケース向けにアプリケーションやソリューションを提供できるようになりました。 最後に、 AWS IoT SiteWise や AWS IoT TwinMaker などのサービスが、持続可能な運用、資産の寿命延長、品質と歩留まりの向上のために、最新の産業データアーキテクチャと可視化ツールを提供してきました。 “ We ’ re honored to be recognized by Gartner and believe it ’ s due to the progress we ’ ve made in this space. We ’ re fortunate to be working with the leading automation providers, industrial systems integrators, independent software vendors, and industrial customers who help us solve these common edge-to-cloud industrial data management problems every day, ” Michael MacKenzie, General Manager for AWS Industrial IoT & Edge reflects. 本日、シーメンス、フォルクスワーゲングループ、キャリア、TC エナジー、ボッシュ、BP、GE、トヨタ、インビスタ、ジョンディアなどの AWS の産業向けお客様とパートナー は、AWS を利用して、操業を変革させる安全で信頼性の高いスケーラブルな産業データ基盤へのアクセスを得ています。 Gartner の報告書は、ビジネスに適した Industrial IoT ソリューションを評価する際の洞察に富んだ指針を提供します。 2024 Gartner Magic Quadrant for Global Industrial IoT Platforms レポートの 無料コピーはこちら からアクセスしてください。 この図表は、Gartner 社によって作成された大規模な調査レポートの一部として公開されたものであり、レポート全体の文脈の中で評価されるべきものです。Gartner 社のレポートは AWS から要求すれば入手できます。 GARTNERはGartnerの登録商標およびサービスマークであり、Magic Quadrantは米国およびその他の国におけるGartner, Inc.またはその関連会社の登録商標です。本文書ではこれらの商標を許可を得て使用しています。すべての権利は留保されています。Gartnerはその調査出版物に記載されたベンダー、製品またはサービスを推奨するものではなく、技術ユーザーに最高格付けまたは他の指定を受けたベンダーのみを選択するよう助言するものではありません。Gartnerの調査出版物は、Gartnerリサーチ組織の意見であり、事実の表明と解釈されるべきではありません。Gartnerは、本調査に関して、商品性または特定の目的への適合性を含む、明示的または黙示的を問わず、一切の保証を否認します。 この記事は AWS recognized as a Leader in 2024 Gartner Magic Quadrant for Global Industrial IoT Platforms の日本語訳です。Prototyping Solutions Architect の市川 純が翻訳しました。

背景 お客様は常に、SAP システムにおけるコア業務プロセスの運用上の卓越性と回復力の向上を求めています。それを達成するには、SAP 環境の統合モニタリング/オブザーバビリティダッシュボードが必要になり、そこで問題を関連付け、問題がデータベース、アプリケーションサーバー、プレゼンテーション、ネットワーク層 (インターネット接続を含む) のいずれにあるかを理解できる必要があります。 AWS は Amazon CloudWatch Application Insights for SAP HANA 、 CloudWatch Application Insights for SAP NetWeaver 、 CloudWatch Real User Monitoring 、 AWS Network Manager 、 Compute Optimizer 、および CloudWatch Internet Monitor を通じて、エンドツーエンドのオブザーバビリティを提供しています。 これらの監視機能が組み合わされると、次のことができるようになります。 SAP システムの根本原因分析を包括的に提供し、MTTR (平均復旧時間) を日単位から時間単位 (場合によっては分単位) に短縮する。 SAP ユーザーの SAP システムが障害に陥る前に、プロアクティブに警告を行えるようにする。 SAP システムのキャパシティ予測と計画を行い、顧客が重要なビジネスプロセスをサポートするために適切なサイズにする必要があるリソースを把握できるようにする。 SAP アーキテクチャ 層 SAP ERP または S/4HANA システムは一般に、次のように 3 層アーキテクチャで展開されています。 これにより、システムの動作を理解し、AWS 上で設計が適切なシステムであることを効率的かつ効果的に監視できます。 図 1. オブザーバビリティをサポートする SAP アーキテクチャレイヤーと AWS サービス プレゼンテーション層には、エンドユーザーが作業を行うためのグラフィカルインターフェースを提供できるシステムが含まれています。 プレゼンテーション層は、クライアント層とも呼ばれ、ユーザーが SAP システムと対話するレイヤーです。 SAP ユーザーとの対話には、SAPGUI (デスクトップにインストールされるクライアントアプリ) や SAP Fiori (デスクトップ、タブレット、モバイル端末で動作する HTML5 クライアント) が利用されます。 アプリケーション層には、SAP システムのアプリケーションロジックを実行するサーバーが含まれます。 SAP アプリケーションプログラム (ABAP) はアプリケーション層で実行されます。 アプリケーション層は、プレゼンテーション層とデータベース層の中間層として機能します。 アプリケーション層で、SAP ディスパッチャが作業負荷を異なる作業プロセスに分散させます。 データベース層には、SAP システムのアプリケーションロジックを実行するために必要なデータを格納するサーバーが含まれます。 データストアには、マスターデータ、業務データ、設定、ABAP プログラムが含まれます。 例: SAP HANA、Oracle、Microsoft SQL Server、IBM Db2、SAP ASE などです。 SAP で重要なビジネス プロセスを効率的かつ効果的に実行するためには、これらのさまざまな層がボトルネックやトラブルなく協調して動作する必要があります。これが、リアクティブな問題のトラブルシューティングをプロアクティブなシステム管理に切り替え、ビジネス ユーザーに多大な損失をもたらす事業の中断やダウンタイムを防ぐために、すべての SAP 層における可観測性が非常に重要である理由です。 SAP on AWS の監視機能 上記で説明した SAP のアーキテクチャ層に基づいて、AWS は以下のサービスを開発しました。 これらのサービスにより、AWS 上の SAP システムのエンド ツー エンド可視化が可能になり、従来の受け身の管理から一歩進んで積極的に管理できるようになります。 これにより、ビジネス上の重要なプロセスを支える高い回復力が得られます。 CloudWatch Application Insights は、Amazon EC2 インスタンスを使用するアプリケーション、および SAP システムをサポートする その他のアプリケーションリソース を監視するのに役立ちます。 ビジネスアプリケーションデータを SAP HANA データベースに保存する場合、 このチュートリアル および このブログ でさらに詳しく知ることができます。SAP ASE データベースを使用する場合は、 このチュートリアル でさらに詳しく知ることができます。 アプリケーションロジックを実行する SAP NetWeaver アプリケーションの場合は、 このチュートリアル および このブログ でさらに詳しく知ることができます。 CloudWatch Real User Monitoring (RUM) は、CloudWatch のデジタル体験監視の一部で、クライアント側のアプリケーション動作に関するリアルタイムデータを提供します。これにより、アプリケーション開発者と DevOps エンジニアは、さまざまな潜在的な問題を迅速に特定してデバッグできるため、平均修復時間 (MTTR) を短縮し、SAP システムの使用におけるユーザー体験を向上させることができます。詳しくは このブログ を参照してください。 CloudWatch Internet Monitor は、AWS 上にホストされた SAP アプリケーションとモバイル作業者との間のインターネットの問題がパフォーマンスと可用性に与える影響を可視化します。 AWS Network Manager は、ビジネスクリティカルな SAP システムをサポートするための、AWS 上のネットワークの管理と監視を支援するツールと機能を提供します。Network Manager により、接続管理、ネットワーク監視とトラブルシューティング、IP 管理、ネットワークセキュリティとガバナンスを容易に行えます。 AWS Cloud WAN は、管理型の広域ネットワーキング (WAN) サービスで、クラウドとオンプレミス環境全体で実行されるリソースを接続する統一的なグローバルネットワークを構築、管理、監視することができます。 インフラストラクチャ パフォーマンスにより、指定した期間の AWS リージョン間、およびアベイラビリティー ゾーン間やゾーン内のネットワーク レイテンシをリアルタイムに近い状態で取得できます。 AWS Global Networks for Transit Gateways により、1 つ以上のグローバル ネットワークを作成し、AWS アカウント、リージョン、オンプレミスロケーション全体にわたってそれらのグローバル ネットワークを集中管理できます。 AWS Compute Optimizer は、AWS リソースの構成と使用率メトリクスを分析します。CloudWatch Application Insights for SAP HANA と SAP NetWeaver を組み合わせると、Compute Optimizer がリソースが最適であるかどうかを報告し、SAP ワークロードのコストを削減してパフォーマンスを向上させるための最適化推奨事項を生成することができます。 SAP ワークロードに適用できるそれぞれのサービスについて、次回のブログシリーズでより詳しく説明します。ご期待ください。 事例 それでは、AWS 上の SAP システムを監視する際に、上記すべてがどのように SAP のお客様を支援するかという使用例を見ていきましょう。 図 2. モバイルユーザが、インターネットから SAP Fiori Launchpad にアクセスする際の遅さを報告した使用ケース 以下のような方法で、根本原因分析 (RCA) を実行することをお勧めします: CloudWatch RUM を使えば、ユーザーの操作、ユーザーの位置情報、ユーザーが体感するパフォーマンス、そしてモバイルデバイスでエラーが発生していないかを確認できます。 CloudWatch Internet Monitor を使えば、ユーザーの近隣で時期を同じくしてインターネットサービスプロバイダーの接続問題が発生しているかどうか、ユーザーの体験に影響を与えている可能性がないかを確認できます。 Application Load Balancer の CloudWatch メトリクス を確認すれば、インターネット接続側の Application Load Balancer で異常状態や応答時間の遅延が検知されていないかどうかがわかります。 SAP Web Dispatcher では、 CloudWatch for EC2 Metrics を使って EC2 インスタンスの全体的な健全性を確認し、CPU、RAM、ストレージなどにボトルネックや問題がないかを確認することができます。 SAP Application Servers では、 CloudWatch Application Insights for SAP NetWeaver を使って可用性、フロントエンドのレスポンス時間、検出された問題、ASCS/ERS の ペースメーカー HA メトリクスなどの主要なメトリクスを確認することができます。 SAP HANA Database レイヤーでは、 CloudWatch Application Insights for SAP HANA を使って、メモリ不足状況、ディスク容量不足状況、ディスクの書き込みキュー長などの主要メトリクスを確認することができます。 ネットワークレベルでは、 AWS Network Manager を使って、アベイラビリティゾーン間 (たとえばアプリケーションサーバーとデータベースサーバー間の複数 AZ 間の遅延測定など) でネットワーク上の問題がないかを確認したい場合があります。 最後に、AWS Compute Optimizer を使用して容量分析を行い、コンポーネント (SAP Web Dispatcher、アプリケーションサーバー、HANA データベースなど) がサイジングされる必要があるかどうかを確認できます。 サイズが小さすぎる場合、CPU、RAM、ディスク、I/O の使用率が継続的に高くなり、パフォーマンスが低下します。 サイズが大きすぎる場合、CPU、RAM、ディスク、I/O の使用率が継続的に低くなります。 AWS Compute Optimizer の推奨事項は、 SAP 認定インスタンスタイプ に合わせて調整する必要があることにご注意ください。 上記の RCA プロセスは、AWS 上の SAP 向けのエンド to エンドの観測性を実現するための、AWS のさまざまなサービスと機能を活用する例です。統合ダッシュボードにカスタマイズして、より迅速に分析したり、 CloudWatch Alarms を使用して通知を生成したりするのも可能です。また、 Amazon EventBridge と統合 することで、予測メンテナンスを実施したり、エラー状況が発生する前に自己修復メカニズムを作成するなど、プロアクティブなモニタリングを行えます。 まとめ SAP ワークロードの動作を理解し、ビジネス上の重要なプロセスを実行する際に、SAP システムを使用してユーザーがどのような経験をしているかを知ることは非常に重要です。 高性能で回復力の高いシステムは、ユーザーの生産性を高め、イノベーションと付加価値活動に時間を使えるようになるでしょう。 CloudWatch App Insight for SAP HANA と SAP NetWeaver、CloudWatch Internet Monitor、AWS Network Manager、AWS Compute Optimizer などの様々な AWS Observability サービスを利用して、プロアクティブな管理と SAP ワークロードの近代化を実現できます。 SAP on AWS、Amazon CloudWatch Application Insights、Amazon CloudWatch Real User Monitoring、AWS Network Manager、AWS Compute Optimizer の詳細は、 AWS 製品ドキュメント をご覧ください。 クレジット 私は以下のチームメンバーの貢献に感謝したいと思います: Ambarish Satarkar、Ashish Tak、Derek Ewell、Mohit Biyani、Wong Whye Loong、Vijay Sitaram、Sriram Sabesan、Ramkrishna Borhade、Somckit Khemmanivanh、および Spencer Martenson。 翻訳はPartner SA 松本が担当しました。原文は こちら です。

ハノーバーメッセ 2024 で紹介された革新的な技術に触れ、産業製造分野の大きな流れの一部として新たな学びと顧客やパートナーとの出会いに満ちた１週間を経て、私は大きな活力を得ました。このブログ記事では、ハノーバーメッセ 2024 の出展ブース、プレゼンテーション、そして会話の中で中心となった上位 3 つのトレンドについて触れ、デジタル化、AI/ML、グリーンエネルギーソリューションが大きな注目を集めましたが、サステナビリティが産業製造分野でそれらを大きく上回る製造業のメガトレンドとなりました。この記事では、すべてのトレンドを要約した上で、サステナビリティを主要なイノベーション課題として検討します。 ハノーバーメッセ 2024 のトップ 3 トレンド Industry 4.0、デジタル化、生成 AI 製造業務とサプライチェーンの継続的なデジタル化は、依然として主要な優先事項です。 ハノーバーメッセの出展者は、データ分析、自動化、クラウドコンピューティング、人工知能、機械学習、その他のデジタルテクノロジーを活用して、生産性、効率性、可視性を向上させ、プロセスの変革を促進するソリューションを展示しました。 ユースケースは、予知保全、品質管理、サプライチェーンの最適化など多岐にわたりました。 AI/ML の組み合わさった Industry 4.0 原則の進歩 は、企業がこれらの機能をどのように活用してプロセスを変革し、さまざまな産業領域のデータから貴重な洞察を引き出すことができるかを浮き彫りにしています。 生成 AI は今回も顧客の関心の的になりましたが、そのユースケース、技術の進歩、セキュリティ、責任ある生成 AI に関する会話は、これまでのイベントや議論と同様でした。 生成 AI はホットトピックとして大きな注目を集めましたが、サプライチェーン管理における生成 AI の利用可能性について、過去のイベントと比べて根本的に新しいことや今までと異なることはありませんでした。 AI/ML を活用してサプライチェーン領域における可視性を高め、プロセスを最適化し、データ主導の意思決定を可能にする、というおなじみのテーマを中心に議論が展開されました。 期待されるメリットへの関心は依然として高く、多くの企業が今後 12 か月で生成 AI を採用する計画を表明しています。 このトピックについては、今後のブログで詳しく説明します。 エネルギー管理と再生可能エネルギーソリューション サステナビリティは核心的な話題の一つで、出展者はエネルギー管理システム、つまり消費量を削減し、効率を高め、水素や燃料電池などの再生可能エネルギー源を施設や事業に統合するためのソリューションにスポットライトを当てました。 水素 + 燃料電池に特化した展示エリアでは、500 社を超える出展者が、エミッションフリーでカーボンニュートラルな生産を実現するために極めて重要な技術を展示しました。 この新たに登場したサステナブルなエネルギー分野は、世界がエネルギーの使用量を最適化し、環境への影響を最小限に抑える代替手段に移行する中で、互いの相乗効果と強い勢いを示しました。 サステナビリティイノベーション サステナビリティへの関心は、ハノーバーメッセ 2024 で最大のトレンドであり、最も広まったメッセージでした。 さまざまな分野の出展者が、環境への影響を最小限に抑え、環境に配慮したビジネスモデルを最優先する革新的な製品を展示していました。 この強い関心は、企業が規制対応の義務と消費者からの要求によってサステナビリティを経営上の必須事項として認識するようになったことを浮き彫りにしました。 同時に、コスト効率の向上、リスク軽減、ブランド評価の向上、環境責任への取り組みを通じて、競争上の優位性を獲得する機会でもあります。 出展内容は、持続可能なソリューションや取り組みを幅広く網羅していました。 主要な分野には、産業製造プロセスと車両の電動化と再生可能エネルギーの統合がありました。 多くの出展者が、事業全体のエネルギー消費量を削減し効率を高めるように設計されたエネルギー管理システムに展示しました。 製品設計において材料の再利用、リサイクル、廃棄物の最小化に重点をおくことにより、循環型経済の基本的な原理は具体化されました。 物流と輸送ネットワーク全体で排出量を削減するための重要な手段としてサプライチェーンの最適化は浮上しました。 新しい製造プロセスは、非効率性を排除し、副産物を最小限に抑え、資源生産性を最適化することで業務を変革することを目指しました。 業界のリーダーが野心的で長期的なカーボンニュートラル目標を設定したことは、サステナビリティへの取り組みの真剣さを浮き彫りにしました。 イベント全体を通して、環境問題には深い切迫感がありました。 これらの技術の進歩が互いに強調し、資源生産性と生態系の持続可能性を高めながら、排出量を増やさずに産業を成長させる後押しをしました。 最先端の企業・組織は、環境に配慮した慣行がコストの削減、リスクの軽減、ブランド価値の向上、規制や社会的要請への積極的な取り組みを通じてどのようにビジネス価値を生み出すかを例示しました。 AWS Supply Chain によるサステナビリティの実現 AWS Supply Chain は、複数階層にわたるサプライチェーンネットワーク全体で持続可能な変革を推進し、サステナビリティへの取り組みを追求する組織を支援する魅力的なソリューションを提供します。 Sustainability の機能により、企業がサプライヤーやパートナーから重要なサステナビリティデータやコンプライアンス成果物を要求し、収集し、監査する方法を一元化します。 この一元化されたアプローチにより、スコープ 1（直接排出）、スコープ 2（購入エネルギーからの間接排出）、スコープ 3（その他すべての間接排出）の炭素排出量などの主要指標に関する透明性が高まります。 また、製品安全文書、輸入許可、有害物質の開示などを通じて、環境基準への遵守状況を追跡できます。 AWS Supply Chain Sustainability は、このデータ収集プロセスを合理化することで、組織が一貫して環境への影響を評価し、サステナビリティの目標を確実に遵守し、環境、社会、ガバナンス (ESG) の報告要件をより効率的かつ透明に満たすことを可能にします。 主要な機能は、設定可能なリマインダーを使用して自動的にサプライヤーのデータ要求を行い、さまざまな書式の情報提供文書アップロードを可能にし、サプライヤーからのすべての回答を安全で監査可能なリポジトリに一元化したり、さまざまなレベルで二酸化炭素排出量データを集約して可視化したりできます。また、まもなく機械学習を利用して文書を自動的に解析および分析できるようになります。 企業がサステナビリティを戦略的課題として優先する中、AWS Supply Chain は、広い範囲のサプライチェーンデータを収集し、環境への影響を定量化し、排出量と廃棄物を削減するための測定可能な取り組みを推進するためのスケーラブルな方法を提供します。 このようなエンドツーエンドのサプライチェーンの透明性は、環境と社会に責任のあるビジネス慣行に向けた世界的な動きに加わる組織にとって重要です。 まとめ 持続可能な未来への道のりには、産業エコシステム全体にわたる変革的なソリューションが必要です。 ハノーバーメッセ 2024 では、サステナビリティがメガトレンドであると同時に、次の産業革命における主要なイノベーションの源泉でもあることが紹介されました。 デジタル化、AI、エネルギー管理、水素技術など、出展者は環境への影響を最小限に抑えながら資源の生産性を最大化するための驚くべきイノベーションを披露しました。 カーボンニュートラルの目標を達成するには、サプライチェーン全体にわたるシステム変革と企業間の協力が必要です。 AWS Supply Chain は、排出量への影響に関するデータ収集や測定の能力、透明性を向上させることで、組織がサステナビリティへの取組みを強化できるようにします。 企業がサステナビリティを戦略的な必須課題として受け入れるにつれて、テクノロジーはサステナビリティへの取り組みを世界規模で加速させるための原動力となるでしょう。 AWS Supply Chain にアクセスして、サステナビリティ機能の詳細を確認し、利用を開始してください。 <!-- '"` --> 本ブログはソリューションアーキテクトの水野 貴博が翻訳しました。原文は こちら 。 <!-- '"` --> 著者について Diego Pantoja-Navajas は AWS Supply Chain の Vice President で、ビジネスアプリケーションのビジョンの策定と実現を担当しています。彼と彼のチームは、サプライチェーンの機能を根本的に考え直し、世界で初めての継続的に改善するサプライチェーン管理システムを市場に提供することに注力しています。彼は顧客の成功に情熱を注ぎ、SaaS、クラウド、AI/ML テクノロジーを活用して、サプライチェーン、e コマース、フルフィルメントに関連するビジネスの問題を解決するための高度に使いやすく知的な B2B エンタープライズソフトウェアソリューションを構築しています。Diego はジョージア工科大学の優等卒業生で、MIT の人工知能・機械学習のエグゼクティブエデュケーションコースを修了しています。また、IESE ビジネススクール、ミシガン大学ロス・ビジネススクールとのパートナーシップのもと、リーダーシップコースにも参加しています。彼は南フロリダに家族と暮らしており、顧客のビジネスの成功をさらに推進する革新的な製品やソリューションを学ぶことを常に喜んでいます。

本日、 AWS Amplify Gen 2 での新しいチームコラボレーションワークフローを発表できることを喜ばしく思います。 私たちは、チームコラボレーションを次の 3 つの方法で改善しました。1/ 開発ライフサイクルをより高速で強力にする、2/ プラットフォームのコア機能を改善する、3/ Amplify を既存のデプロイ環境に柔軟に統合できるようにする、の3つです。これにより、Amplify を使って、アーリーステージのスタートアップのチームでも大企業のチームでも、フルスタックアプリを簡単にデプロイできるようにしました。 このブログでは、最新版の Amplify が提供する、さまざまなチームのワークフローと開発環境の改善点について詳しく説明します。最新の Amplify について詳細を学びたい場合や、サンプルコードをなぞってみたい場合は、最初に フルスタック TypeScript : AWS Amplify を再び紹介 を確認してから、このライフサイクル改善に関する記事を読み進めてください。 開発プロセス Amplify には、開発体験を向上させる 3 つの新機能があります。アプリ作成プロセス中の反復をスピードアップするための開発者ごとのクラウド環境サンドボックス、シークレット管理、さらに AWS Cloud Development Kit (AWS CDK) 統合による、より柔軟なカスタマイズ機能です。 開発者ごとのクラウドサンドボックス Amplify を使っているすべてのチームが、新しい 1 人 1 人のデベロッパー用のサンドボックス環境の恩恵を受けられます。ローカル開発専用のクラウドサンドボックス環境では、開発中に利用できる、本番環境に忠実な AWS バックエンドがデプロイされます。これによりバックエンドロジックのイテレーションを素早く回せるようになります。コードを保存するたびに、変更したコードに基づいてサンドボックスが必要なクラウドリソースを再デプロイします。たとえば、Amplify データスキーマを更新すると、サンドボックスが自動的にデータベースを変更し、アプリでロジックをテストできるようになります。各開発者は独立したサンドボックス環境で作業するため、素早いイテレーションを重ねても他の開発者の環境に影響を与えることはありません。次の図では、4 人のデベロッパーが、お互いの環境を乱すことなく、独立してフルスタック機能での作業ができています。 サンドボックスを実行するのに必要なことは、Amplify Gen 2 アプリを開き、ターミナルで次のコマンドを実行するだけです。 cd my-app npx ampx sandbox クラウドのサンドボックスは一時的なものです。開発が終了したら、そのサンドボックスを破棄し、次に必要になったら新しいサンドボックスを作成してください! AWS CDK との統合 ビジネス要件が変化していくにつれて、開発者は Amplify に組み込みで用意されているユースケースを超えるユースケースを追加する必要が生じるかもしれません。最新の Amplify は AWS CDK 上に構築されており、カスタムリソースの追加や Amplify が利用するリソースのオーバーライドがシームレスに行えるようになりました。例えば、開発者は AWS CDK を使って Redis キャッシュを接続したり、カスタムセキュリティルールを実装したり、AWS Fargate 上にコンテナをデプロイしたり、AI/ML 用に Amazon Bedrock に接続したりできます。AWS CDK のコードで定義されたインフラストラクチャは、すべての git push で Amplify アプリのバックエンドとともにデプロイされます。つまり、Amplify の使いやすさと単純さを活かしつつ、ビジネス要件の進化に合わせて、必要なリソースを追加していけます。 カスタムの削除ポリシーを Amplify でプロビジョニングされた認証インスタンスに設定したい場合は、例えば backend.ts ファイルに次のコードを追加することができます。 import { defineBackend } from '@aws-amplify/backend'; import { auth } from './auth/resource'; import { UserPool } from 'aws-cdk-lib/aws-cognito'; import { RemovalPolicy } from 'aws-cdk-lib'; const backend = defineBackend({ auth }); const userPool = backend.auth.resources.userPool as UserPool ; userPool.applyRemovalPolicy(RemovalPolicy.RETAIN_ON_UPDATE_OR_DELETE); シークレットの管理 Amplify Gen 2 は、シークレットと環境変数の中央集中管理機能を提供しています。シークレットにより、アプリケーションが必要とするソーシャル サインインキー、関数の環境変数、関数のシークレット、その他の機密データなどの環境固有の値を、環境を超えて安全に構成できます。これらのシークレットは、すべてのデプロイ済みブランチだけでなく、特定のブランチにもスコープを設定できます。たとえば、ローカルのサンドボックスでもシークレットを設定できます。 npx ampx sandbox secret set fb-client-id ? Enter secret value: ### Done ! &gt; npx ampx sandbox secret set fb-client-secret ? Enter secret value: ### Done ! 本番環境では、コンソールから入力します。 これだけで、コードからシークレットにアクセスできるようになります！ import { defineAuth, secret } from "@aws-amplify/backend"; export const auth = defineAuth({ loginWith: { email: true, externalProviders: { facebook: { clientId: secret("fb-client-id"), clientSecret: secret("fb-client-secret"), }, }, }, }); デプロイ Amplify には、どんな開発ワークフローを採用しているかに関わらず、チーム全員で開発したアプリを本番環境にデプロイできる新機能があります。Git flow、GitHub/プルリクエストフロー、トランクベース デプロイメントの 3 つの異なるデプロイ戦略の Amplify のワークフローを見ていきましょう。また、リポジトリと秘密情報の管理に関する新機能についても説明します。 Git flow Git flow とは、2 つの主要なブランチ: プロダクションリリース用の main ブランチと機能統合用の develop ブランチを利用するブランチモデルです。開発者は develop ブランチから feature ブランチを作成し、完了後に develop に再びマージします。そして、定期的に develop を main にマージしてリリースを行います。また、 hotfix と release 用の専用ブランチも導入し、並行して開発している内容を構造的に管理する方法を提供しています。 Amplify の CI/CD システムは、このワークフローと非常に良く機能するように設計されています。すべての Amplify コードとそれに伴うバックエンドおよびクラウドロジックが TypeScript コード内に記述されるため、Git ブランチにはフロントエンドとバックエンドを両方デプロイするのに必要なすべてのソースコードが含まれています。そして、 main および dev ブランチ用のデプロイ環境を持つことができます。 フルスタック機能ブランチの自動デプロイ Amplify コンソールでは、 * や feature/* などのブランチパターンを定義し、そのパターンに一致するブランチを Amplify に自動デプロイできます。dev から prod への変更の移行は、 dev から prod ブランチにマージするだけで簡単に行えます。 ‘Automatically disconnect branches’ チェックボックスをオンにすると、リポジトリから Git ブランチを削除したときに、Amplify からそのブランチが自動的に切断されます。 カスタムサブドメインの自動設定 カスタムドメインを設定したら、自動デプロイされた開発中の機能ブランチや Pull Request 用のプレビュー環境に覚えやすいサブドメインがほしくなるかもしれません。Amplify で指定したパターンに基づきサブドメインを作成するように設定できます。 GitHub/プルリクエストフロー 別のよく使われるアプローチは、プロダクションのための 1 つの main ブランチを持ち、開発者はそれぞれ、機能をプロダクションに統合するためにフォークを作成し、そのフォークから main ブランチへのプルリクエストを作成することです。このシナリオでは、お客様は Amplify に単一の main ブランチをデプロイし、プルリクエストプレビューを有効にすることで、一時的なプルリクエストデプロイインスタンスを作成しています。 プルリクエストがオープンされると、Amplify は自動的にフルスタックのプルリクエスト用ブランチをデプロイします。これは Amplify 上で一時的な環境で、 https://pr-#.mydomain.com でアクセスできます。 プルリクエストがマージされると、フルスタックのプルリクエストプレビューブランチ全体が破棄されます。 トランクベース開発 トランクベース開発は別のソフトウェア開発戦略で、すべての開発者が単一の共有トランク(または main ブランチ)を作業元とし、変更をトランクへ頻繁に統合します。 トランクへの継続的な統合とコラボレーションは、マージの競合のリスクを減らし、フィードバックのサイクルを早くすることができます。トランクベース開発では、開発者が短期間の機能ブランチを切り出し、できるだけ早くトランクにマージし、パイプラインステージによる自動テストに頼って、コードベースの安定性を確保します。 複数のアカウントにまたがる AWS デプロイ Amplify は直接パイプラインやステージベースのワークフローを提供していませんが、お客様は AWS CodePipeline や Amazon CodeCatalyst などの自身の CI/CD パイプラインを使用して、パイプラインベースのワークフローでフルスタックアプリケーションをデプロイできるようになりました。Amplifyで Amazon CodeCatalystと併用する際にトランクベースの戦略に従うには、 このチュートリアル に従ってください。 モノレポとマルチリポジトリ Amplify は様々なリポジトリ構成に対応しています。Amplify は、Nx や yarn workspace のようなモノレポツールと 統合 されており、単一のリポジトリで複数のアプリケーションを管理できるようにします。フロントエンドとバックエンドのチームが別々の場合、Amplify はフロントエンドとバックエンドのコードベースで 別々のリポジトリ の利用を可能にします。 次のステップ このブログ記事では、チームが Amplify を活用して、規模に関わらずフルスタックアプリケーションを開発およびデプロイする方法を紹介しました。 クイックスタートチュートリアル に従って Amplify を始めましょう! 本記事は、 New in AWS Amplify: Expanded Fullstack Deployment Capabilities for Teams of All Sizes を翻訳したものです。翻訳は Solutions Architect の 髙柴 が担当しました。

みなさん、こんにちは。ソリューションアーキテクトの杉山です。 今週も 週刊AWS をお届けします。 What’s New にお知らせが無く先週の 週刊AWS で紹介が出来なかったのですが、注目度が高いため冒頭に紹介させてください。Amazon Bedrock 関連の 3 機能が東京リージョンで提供を開始しました。RAG 機能の実装を支援する Knowledge bases for Amazon Bedrock、幅広いユースケースや複雑なタスクの実行をサポートする Agents for Amazon Bedrock、責任ある AI のためにセーフガードの仕組みを導入できる Guardrails for Amazon Bedrock の 3 つが提供されています。生成 AI でより本格的で複雑なことを実現しようと思った際に、これらの機能を使って実現の手間を低減できます。ぜひ東京リージョンでもご利用ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2024年5月6日週の主要なアップデート 5/6(月) AWS Amplify Gen 2 is now generally available AWS Amplify Gen 2 の一般提供を開始しました。Gen 2 は、コードファーストの開発体験がコンセプトとなっており、フロントエンドエンジニアが利用する TypeScript 言語をそのまま活用して、認証バックエンド、データバックエンド、ストレージバックエンドなどの構成を表現し、構築が出来ます。元々の Gen 1 Amplify ではバックエンド環境を構築するときに、Amplify CLI を利用して構築しており、使い方の学習や、実現できる内容を理解するハードルがありました。Gen 2 は、TypeScript でコードを基にバックエンドを表現できるようになり、IDE 上の IntelliSense 自動補完機能を活用しながら、プログラマに馴染みのある手法で開発がやりやすくなりました。新たに Amplify を利用する場合は、Gen 2 の利用をおすすめします。Gen 1 を利用している場合は、Gen 2 へ移行ツールが、今後利用できる予定となっています。それまでは、引き続き現在の Gen 1 をご利用ください。 詳細はこちらのブログ を参照ください。Gen2 と Gen1 の機能比較は、 こちらの Document を参照ください。 Amazon RDS for Oracle now supports April 2024 Release Update Amazon RDS for Oracle で、19c、21c を対象にした 2024 年 4 月のリリースアップデート (RU) を提供しました。パッチ適用やバグ修正などが盛り込まれております。リリースアップデートの詳細は、 RDS for Oracle のリリースノート をご覧ください。自動マイナーバージョンアップグレード (AmVU) オプションが有効になっている場合、お客様の DB インスタンスは、6〜8週間で最新の四半期 RU にアップグレードされます。これらのアップグレードはメンテナンスウィンドウ中に行われます。 5/7(火) Announcing Amazon Bedrock Studio preview Amazon Bedrock Studio のプレビューを開始しました。Bedrock Studio は Knowledge Bases、Agents、Guardrails なども活用しながら、Generative AI のプロトタイプを開発するウェブベースの開発環境です。生成 AI アプリケーションの開発スピードを加速できるメリットがあります。Knowledge Bases や Agents を活用して、会社内のデータや外部の API と連携しながら生成 AI を利用する環境をすぐに構築し、使い勝手を確かめながら導入効果の測定などにご活用いただけます。また、会社の ID 認証基盤 (例 : Microsoft Entra ID, Google Workspace など) を使って Bedrock Studio へアクセスを提供でき、AWS マネジメントコンソールへ権限付与なしにご利用いただけるため、組織内の展開がやりやすくなる仕組みがあります。詳細は こちらのブログ を参照ください。 Agents for Amazon Bedrock now supports Provisioned Throughput pricing model Agents for Amazon Bedrock で Provisioned Throughput のサポートを開始しました。Provisioned Throughput は、トークンを処理するリソースを事前に準備することで、一定の保証されたスループットを提供するものです。通常のオンデマンド利用の際には、決められた上限が設定されており、使い方によってはスロットリングエラーが発生する場合があります。今回発表した Provisioned Throughput を使うことで事前に必要なリソースが確保でき、エラーの発生を抑えることが可能になります。 料金の詳細はこちら を参照ください。 Amazon Titan Text Premier is now available in Amazon Bedrock Amazon Bedrock で、新たに Amazon Titan Text Premier モデルを提供開始しました。Amazon Titan Text Premier は、高度で高性能、かつコストパフォーマンスに優れた LLM で、エンタープライズグレードのテキスト生成アプリケーションに最適な性能を発揮するよう設計されています。個人的に注目しているのが、高性能なモデルに加えて Token あたりのコストが安価な点です。1,000 input token あたり$0.0005、1,000 output token あたり $0.0015 となっており、比較的安価な料金帯となっています。現在のところ、日本語は明確なサポートとしては含まれておりませんが、「日本語で回答して」といったリクエストを行うと、日本語の回答が得られることもありました。バージニア北部リージョンでご利用いただけます。ベンチマーク結果や利用方法を含めた詳細は こちらのブログ を参照ください。 Announcing a larger instance bundle for Amazon Lightsail Amazon Lightsail で、16 vCPU と 64 GB メモリの大きなインスタンスバンドルが新たに提供されるようになりました。高性能インスタンスバンドルは、大きな負荷の増加に対処できる能力が必要な一般的なワークロードに最適です。この新しいバンドルを使えば、ウェブおよびアプリケーションサーバー、大規模データベース、仮想デスクトップ、バッチ処理、エンタープライズアプリケーションなどを実行できます。Linux オペレーティングシステム (OS) で利用可能です。Windows ベースのものは提供していません。 5/8(水) Amazon SageMaker now integrates with Amazon DataZone to help unify governance across data and ML assets Amazon SageMaker と Amazon DataZone の統合が提供されるようになりました。DataZone は、組織内に存在するデータの意味を解説する管理機能、検索を行い欲しいデータを探索するデータカタログ機能、セキュリティを意識したデータ共有機能などがあります。アップデートで、SageMaker Studio の画面から DataZone 上で管理されているデータを検索し利用する機能が追加されました。機械学習エンジニアがデータを使ってモデルを作成していく際に、どんなデータが組織内に存在しているか簡単に把握できるようになり、試行錯誤に伴うデータ探索の時間を削減できるようになりました。また、機会学習エンジニアが作成したモデルや特徴量データをカタログに公開することもできるようになり、作成した成果物を組織内に共有し、互いのコラボレーションがやりやすくなる機能があります。詳細は こちらのブログ をご参照ください。 New Generative Engine with three synthetic English Polly voices テキストデータから音声を合成する際に利用できる Amazon Polly で、表現力豊な 3 つの Generative エンジンを追加しました。今回のアップデートで、アメリカ英語音声としてルースとマシュー、イギリス英語音声としてエイミーが追加されました。AWS マネジメントコンソールで簡単に試してみると、英語のアクセントなどがとてもネイティブ感があり、クリアなサウンドに聞こえました (聞き分けられるほどの英語スキルはないですが…)。新しい 3 音声は、バージニア北部リージョンでご利用いただけます。 5/9(木) Amazon Cognito introduces tiered pricing for machine-to-machine (M2M) usage Amazon Cognito で、マシン間認証 (Machine-to-Machine) の価格設定を導入しました。従来あるユーザーベースの価格設定は、変更ありません。マシン間認証とは、ユーザー (人間) による操作ではなく、システム間やアプリケーション間の認証連携の際に適用されるものです。具体的には、Amazon Cognito でアプリクライアントのクレデンシャルを発行し、それを連携したいシステム側で利用することで、新しい料金体系が適用されます。新しい料金体系は、アプリクライアントごとの毎月課金と、アクセストークンの発行数による従量課金となります。詳細は こちらの「Machine-to-machine authorization」タブ をご確認ください。 Amazon QuickSight launches SPICE capacity auto-purchase API Amazon QuickSight で SPICE 容量の自動購入 API を新たに追加しました。以前は、QuickSight のウェブコンソール画面から、SPICE 自動購入を手動で ON にする作業が必要でした。この API 追加によって、AWS SDK や AWS CLI などを使ってプログラム側から自動的に自動購入を ON に指定できるようになり、シームレスな環境作成が実現できます。 5/10(金) Amazon RDS for PostgreSQL supports pgvector 0.7.0 Amazon RDS for PostgreSQL で、データベースにベクトルデータを保存する用途などに利用できる pgvector 0.7.0 をサポートしました。pgvector 0.7.0 では、新たにベクトルデータを保存するためのデータ型として、halfvec が追加されました。これは、いままで 32 ビットでベクトルデータを保存していたことに対して、半分の 16 ビットで保存できるようになり、データキャッシュなどを行う際のメモリ使用量を半分でき、コストパフォーマンスを改善できるうれしさがあります。また、halfvec は新たにベクトルデータを格納する際の index build time を早くできる特性をもっており、より高速な利用を期待できます。生成 AI の Embedding や、自然言語処理、画像認識などの分野で役立つアップデートとなります。利用できるバージョンの制限があり、PostgreSQL 16.3、15.7、14.12、13.15、12.19 のバージョンで実行可能です。 2024 年度の AWS Summit Japan が 6 月 20 日(木)、21 日(金)に開催されます。 事前登録サイト が公開されたため、ぜひ忘れないうちに登録とカレンダーの予約をお願いします。基調講演、150 を越えるセッション、250 を越える EXPO コンテンツが体験できます。また、QuizKnock が AWS Summit 内で、クイズ大会やミニステージに登壇していただける予定になっております。こちらもぜひお立ち寄りください。 それでは、また来週お会いしましょう！ ソリューションアーキテクト 杉山 卓 (twitter – @sugimount )

製造業、特に化学、素材や製薬の事業では自社製品の新しい用途の発見が新規市場の開拓に欠かせません 。 富士フイルム がフィルムで培った抗酸化機能を化粧品に転用した事例 、 森下仁丹がバイオカプセルの技術をレアメタルの回収に転用した事例 は自社製品の可能性を広げた好例といえます。しかし、可能性を感じる一方で新しい用途の発見に困難を感じているお客様が多いと思います。テクノポートのアンケートに基づくと、 用途開発を行っている企業の 84.5% が自社だけで有望な用途を発見するのは限界 と回答しています。多様な新製品の登場や脱炭素の市場動向など、製品と求められる性能は多様であり、膨大な情報から自社製品の適合可能性を発見し育てるのは容易ではありません。先ほど挙げた富士フイルムでも、化粧品への応用可能性を発見してから成功を収めるまで長い期間を要しています。 近年の生成 AI は新規用途の発見にどのように役立つでしょうか ? 生成 AI は高い文章処理能力を持つため、膨大な情報から有望な用途を検出するのに利用できると期待できます。実際、 三井化学では生成 AI を用途の探索に活用していますし 、 日本ガイシでは基盤モデルを活用した新規用途探索の高精度化と高速化の実証実験を開始しています 。三井化学では事業部門の 1 テーマにつき 500 万件以上の特許やニュース、ソーシャルメディアといった外部情報と、三井化学固有の辞書を入力に使用しています。日本ガイシでは、 Stockmark が開発した最新の特許や論文、ニュースなどの外部情報を学習したモデル と日本ガイシが保有する特許や論文などの社内外文書を使用しています。これらの事例から、生成 AI の活用においては外部の情報と内部の情報の 2 つが必要なことがわかります。富士フイルムであれば抗酸化作用、森下仁丹であれば被膜技術に関する社内の文書や特許、論文が「内部の情報」にあたるでしょう。これを外部の特許やニュース、ソーシャルメディアなどと突合させることで有用な新規用途を見つける流れになります。 生成 AI で「外部の情報」と「内部の情報」を突合し、新規用途を発見するにはどんな手法があるでしょう? 三井化学のように、外部と内部それぞれの情報をもとに生成 AI を含む機械学習モデルに判断させるか、日本ガイシのように「すでに専門知識を学習した」モデルに情報を与え判断させる 2 つのアプローチが考えられます。少し専門的な用語になりますが、前者の代表的な手法はモデルに対する外部知識の挿入 (Retrieval Augmented Generation: RAG) 、後者の代表的な手法はモデルの追加学習 (Fine Tuning / Continuous Pretraining) と呼ばれます。前者と後者は、移動するときに配車サービスを使用するか車を買うかに似ています。配車サービスでは車を持つ必要がないように、前者は特別なモデルを必要としない点がメリットです。一方で、必要な知識や情報すべてを生成 AI へ入力しないといけないため入力長が長くなり対応できるモデルが限られる、また料金が高額になるデメリットがあります。移動距離が長くなるほど高額かつ高級な車にしなければらならないイメージです。車を買ってしまえば自由にどこへでも行けるように、後者は初期費用が必要なもののモデルを構築してしまえば入力は短く済み自由にカスタマイズできます。それぞれにメリットとデメリットがありますが、今回は後者の手法を紹介します。というのも、 1 日にチェックするべき情報一つ一つに対し各製品の各特性の応用可能性を分析するなら、必要なリクエスト数は情報・製品・特性の掛け算になり膨れ上がります。この場合、単純にコストがかかるだけでなくモデルの利用制限に抵触する可能性があります。例えば、&nbsp;Amazon Bedrock で Claude (Sonnet) を利用する場合、 1 分間当たりリクエスト可能な数は 500 という制限があります 。そのため、一時的にコストがかかっても内部の情報に精通したモデルを構築し、外部の情報を判断してもらうことはメリットがあると考えています。「内部の情報」は「外部の情報」に比べて変化が緩やかで特化型のモデルを作っても時代遅れになりにくい点もポイントです。 AWS で「内部の情報」を学習した生成 AI モデルを使い「外部の情報」から用途を見つけるにはどうしたらよいでしょうか? エンジニアの方向けに、アーキテクチャーの構成例を示します。 自社のオンプレミス環境から用途検索を行うアプリケーション (Amazon ECS) へのアクセスを行う想定です。「内部の情報」を学習したモデルは、 Hugging Face 上で公開されている Stockmark が開発したビジネスに関連するオープンな情報や特許などで学習した基盤モデル を AWS DataSync で取得した社内文書で追加学習して構築しています。 Stockmark のモデルはまだ未対応ですが、 Amazon SageMaker JumpStart に掲載済みのモデルであれば Amazon S3 にデータを配置し画面からボタンを押す、 API を呼ぶだけで学習を起動できます 。 このような構成を取ることで、セキュアかつ高効率に用途の探索ができます。学習したモデルは、 SageMaker real-time endpoint でホスティングしています。 2024 年 5 月の段階で Amazon Bedrock の Custom model import 機能 が Preview となり、本機能を利用すれば他のモデルと同様に API 形式でモデル呼び出すことも可能です。 「外部の情報」の検索には Amazon Kendra を利用しています。 Amazon Kendra はマネージドな検索サービスで、内部の情報同様 AWS DataSync で取得した外部の情報の検索に使用しています。検索結果をホスティングした追加学習済みのモデルに送り、分析結果をアプリケーションに返却します。 先にご紹介した日本ガイシの実証実験では Stockmark と本構成に近い取り組みをしており、 Stockmark 独自モデルを追加学習し日本ガイシ固有のモデルを検証することがアナウンスされています 。海外では Bloomberg が金融文書で学習させたモデルを発表している通り、 自社のドメイン、さらには自社固有の製品情報を学習させることで 自社ビジネスのパートナーとなるようなモデルを構築する試みが様々な会社で進んでいます 。基盤モデルの開発に取り組むリコーでは、 企業独自の AI モデルを簡単に作成できるサービスの提供も始めています 。自社ビジネスパートナーとなるようなモデルに対しては、商談前や会議中といったリアルタイムな応答が求められる場で使われることもあるでしょう。自社固有のモデルを AWS 環境内でホスティングすることで、応答速度や利用制限といった外部の制約に縛られることなく業務を加速でき、秘中の秘である自社の製品情報を学習したモデルをセキュアに利用することができます。 本記事では、生成 AI により新規用途の発見を加速させる手法をご紹介しました。 外部と内部の情報を生成 AI に入力し分析させる方法と、自社ドメインの知識を学習したモデルを利用する方法の 2 つを紹介し、後者の可能性と AWS で実装するためのアーキテクチャー例をご紹介しました。自社独自のモデルの構築というと非常に高度なスキルと金額、何より時間がかかると思われるかもしれません。しかし、 Stockmark がオープンソースでモデルを公開しているように、高性能かつ日本語に特化したモデルの入手は容易になっており、ゼロから学習する必要はなくなりつつあります。 AWS では Amazon SageMaker JumpStart に掲載済みのオープンソースのモデルであれば容易に追加学習できますし、掲載されていないモデルも基盤モデルの学習・推論に特化した AWS Trainium / AWS Inferentia という自社設計の機械学習アクセラレーターを用いることでコスト効率よく、短期間で学習を完了できます。 2023 年に LLM 開発支援プログラムに参加されたお客様には 3 日で学習を完了された例もあります。 AWS Trainium / AWS Inferentia の詳細は 「 AWS Trainium を活用した日本語大規模言語モデルの分散学習と AWS Inferentia2 上での推論環境構築 」をぜひご参照ください。もちろん、前者のアプローチを試したい場合であっても Amazon Bedrock を通じて Claude など日本語でも ChatGPT / GPT-4 同等の性能を持つモデルを利用しすぐにアプリケーションを実装することができます。 どんなアプローチをしたい場合であっても最適なサービスを提供できる品ぞろえが AWS をご活用いただくメリットです。 久保 隆宏 (Takahiro Kubo) は AWS Japan の機械学習領域のデベロッパーリレーションを担当しており、「機械学習をするなら AWS 」と感じて頂くべくコンテンツの作成とフィードバックの収集による AWS サービスの改善を行っています。 尾原 颯 (Ohara, Soh)&nbsp;は AWS Japan にて主にヘルスケア系スタートアップに対して技術支援をしています。好きなサービスは Amazon SageMaker と Amazon HealthLake です。 &nbsp;

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 皆さんもお気づきだとおもいますが、AWSでは生成AIに注力しています。AWSは「お客様からのフィードバックにもとづいてサービス開発をおこなう」ということを昔から大切にしてきました。最近AWSが生成AIに力を入れているのは、まさにこの理由からです。私自身、常日頃いろいろなお客様と会話をするわけですが、生成AIに興味を持っていない方はほぼいない、といっても過言ではない状況ですから、AWSの注力ぶりは個人的には頷ける印象を持っています。 これから先も、たくさんのニュースやサービスアップデートが出てくるでしょう。ところが、あるお客様から「アップデートが多すぎて把握しきれない」というコメントを頂きました。と、いうことでお客様の声にお答えして新しいブログシリーズ、週刊生成AI with AWSを始めてみようと思います。 週刊AWS のように、毎週月曜日をメドに先週分のニュースやサービスアップデートをコンパクトにまとめてお伝えします。週刊AWSと同じトピックを取り上げることもあると思いますが、大切な情報が漏れるよりは重複したほうが良いという考え方で、カブリはOKというポリシーにしたいと思います。 それでは、5 月 6 日週の生成AI with AWS界隈のニュースをお届けしていきましょう。 さまざまなニュース Amazon Qの一般利用開始に際して、Andy JassyがXにコメントをポスト Andy JassyはAWSを立ち上げた当事者で、現在はAmazon全体のCEOを務めています。Andyはポストの中で、Amazon Qは企業のデータ活用とソフトウェア開発の加速を目的とした生成AI搭載アシスタントで、開発者や従業員の方々が「大変だけれども競争力につながらない作業」に費やす時間を大幅に削減することを目指しているとコメントしています。すでにAmazon Qを利用しているお客様の名前についてもご紹介していますので、ぜひ原文をごらんください。 Adam SelipskyもAmazon Qの一般利用開始についてXにポスト AWSのCEOであるAdam SelipskyもAmazon Qの一般利用開始についてポストしています。Amazon Qは、その名前を持った様々なプロダクトから構成されているのですが、全体感をざっくりと把握するにはAdamのポストを見ていただくのがおすすめです。短い文章で良い具合にまとまっています。 Werner VogelsがブログでAIによる会議の議事録取得アーキテクチャを紹介 WernerはAmazonのCTOです。彼は All Things Distributed というブログを運営しているのですが、そのブログにAIの技術を利用して、会議中の会話をテキストに書き起こし、要約を出力する仕組みを構築する方法を紹介する記事が投稿されました。会議の音声データをAmazon S3にアップロードすると、Amazon Transcribeでテキストへの書き起こしを行い、Amazon Bedrockの経由でClaude 3 Sonnetに要約させ、その結果をS3に書き戻すという具合です。ブログの後半ではAmazon Qを試してみた感想も掲載されていますので、ぜひご一読を。 サービスアップデート 新モデルAmazon Titan Text PremierがAmazon Bedrockから利用可能に Amazonが開発・提要する基盤モデルであるAmazon Titanファミリーに新たな仲間が加わりました。大規模言語モデル(LLM)のAmazon Titan Text Premierです。Titan Text Premierは要約、テキスト生成、分類、Q&amp;A、情報抽出などテキストに関する多彩なタスクをサポートし、Knowledge Bases for Amazon Bedrockによる検索拡張生成(RAG)アーキテクチャでの利用や、Agents for Amazon Bedrockによる複数ステップを順序立てて実行する処理に最適化されています。Bedrockのフルマネージドな仕組みで動きますので、お客様はBedrockのAPIを呼び出す方法だけ学習すれば、デプロイや管理運用の手間なくTitan Text Premierをご利用いただけます。 ブログ記事 も公開されています。デモ動画や性能評価の結果も掲載されています。 生成AIアプリケーション開発のためのWebインタフェース、Amazon Bedrock Studioをプレビュー提供開始 複数の開発者の方が協力しながら生成AIアプリケーションを開発するためのWebインタフェース、Amazon Bedrock Studioのプレビュー提供を開始しました。シングルサインオン(SSO)に対応していますので、組織内のIDを利用してログインすることができます。Bedrock Studioは、Knowledge BasesやAgents、Guardrailsなどを利用したプロトタイプを素早く開発できる環境を提供します。Bedrock Studio自体は無料でご利用頂くことができ、Bedrockをご利用いただいた料金だけが発生します。詳細については ブログ をぜひ。画面ショットが沢山あるので、イメージを掴みやすくなっています。 Agents for Amazon Bedrockがプロビジョンドスループット料金モデルに対応 Amazon Bedrockにはオンデマンドと、プロビジョンドスループットの料金モデルが用意されています。オンデマンドは入出力トークン数に基づく従量課金、プロビジョンドスループットは単位時間あたりに処理できる入出力トークン数のスループットを確保し固定金額を支払うモデルと考えてください（ 料金体系はこちら ）。今回、新たにAgents for Amazon Bedrockでもプロビジョンドスループットの料金モデルをご利用いただけるようになりました。 Amazon SageMaker NotebooksがG6インスタンスをサポート Amazon SageMaker Studioは機械学習開発の作業をエンドツーエンドでサポートする、Webベースの統合開発環境です。SageMaker NotebooksはSageMaker Studioの一部として提供されるフルマネージドなJupyterLab環境で、開発やデータ操作などのNotebookを利用した作業を素早く実行可能です。今回、SageMaker NotebooksのインスタンスとしてAmazon EC2 G6インスタンスが利用できるようになりました。G6は最大8つのNVIDIA L4 Tensor Core GPU(24GBメモリ)と、第3世代のAMD EPYCプロセッサを搭載しており、G4dnインスタンスと比較してディープラーニング用途で最大2倍の性能を発揮します。 Amazon SageMakerとAmzon DataZoneが統合され、データとML資産の統合管理が容易に Amazon DataZoneは組織内のデータを素早くカタログ化・発見・共有・管理するためのデータ管理サービスです。Amazon SageMakerと統合が行われたことによって、機械学習プロジェクトの管理者は、DataZoneを利用してプロジェクト関係者間の成果・データの共有や、アクセス許可の管理を実行できるようになりました。また、機械学習エンジニアやデータサイエンティストの方にとっては、利用可能なデータを発見して、機械学習で利用することがこれまでよりも簡単に実行できるようになるメリットがあります。 ソリューションアーキテクト 小林 正人 (twitter – @maccho_j )

AWS Amplify は、Gen 2 における Function の一般提供を発表できることを喜ばしく思います。Amplify Functions は TypeScript を使って定義、作成、使用されます。これらは、カスタムクエリやミューテーションのハンドラーであっても、認証リソースのトリガーであっても構いません。Amplify Functions の実態は、 AWS Lambda によって提供されていますが、Amplify を使えばアプリと同じコードベースや言語でサーバーレス関数をデプロイできます。関数はさまざまなユースケースで使用されますが、多くの場合、リソースの動作を拡張または変更してアプリ向けのカスタマイズされたユーザーエクスペリエンスを構築します。 Amplify Gen 2 では、リソースは resource ファイル (つまり resource.ts ) で定義されていますが、Function も対応する handler ファイル (つまり handler.ts ) で作成されます。Function を使用すると、ファイルを保存するたびにソースコードをホットスワップすることで、素早く反復処理を行えます。TypeScript ベースのリソース定義、TypeScript ベースの handler から始めると、リソースまたは handler ファイルを保存するたびに、 esbuild を使ってソースコードがバンドルされ、数秒で再デプロイされます。 Amplify Functions では、各 Function 用に tsconfig.json やビルドプロセスを書く必要はありません。 必要最小限のリソース定義とハンドラーを作成し、デプロイするだけです。 Functions 最大の利点は、ほとんどあらゆるリソースで使えることです! Amplify Functions で最も頻繁に使われるユースケースの一例は次のとおりです。 Amplify でネイティブサポートされていないリソース (例えば AI/ML 向けの Amazon Bedrock) に接続する ユーザー情報をユーザープロファイルデータレコードにリンクするなど、Amplify の既定の認証フローを変更する ストレージバケットにアイテムがアップロードされた際にイベントを実行する (例えば画像のリサイズ) データリソースに対するカスタムクエリやミューテーションのためのリゾルバーを作成する ここでは、Amplify アプリ内の カスタム AWS リソースとして Amazon Bedrock と対話する関数を構築し、カーソルルームに保存された画像に基づいて俳句を生成します。 この関数は、カスタムクエリのハンドラーとしてデータリソースにアタッチされます。 TypeScript を用いた関数リソースの定義 Amplify Functions を使い始めるには、リソース定義が必要です。 // amplify/functions/generateHaiku/resource.ts import { defineFunction } from "@aws-amplify/backend" export const generateHakiu = defineFunction({ name: "generateHaiku", }) そして対応する ハンドラー ( handler.ts ) ファイルは次のようになります: // amplify/functions/generateHaiku/handler.ts export const handler = async () =&gt; {} 個人用のクラウドサンドボックス が動作していれば、ハンドラーファイルを保存するとすぐに、最初の関数のデプロイが開始され、数秒以内にデプロイが完了します。 Amplify リソースとの関数の利用 関数がストレージリソースから画像を 読み取る ためには、アクセス権を付与する必要があります。Amplify リソースへのアクセス権は共通の言語で付与され、Amplify は IAM の用語をストレージの read や Auth の addUserToGroup のようなリソースに適した言葉に単純化します。関数のリソース定義を使って、ストレージリソースの room/ パスへのアクセス権を許可しましょう。 import { defineStorage } from "@aws-amplify/backend"; import { generateHaiku } from "../functions/generateHaiku/resource"; export const storage = defineStorage({ name: 'gen2-multi-cursor-demo-app', access: allow =&gt; ({ 'room/*': [ allow.authenticated.to(['get', 'write', 'delete']), allow.guest.to(['get', 'write', 'delete']), // grant the "generateHaiku" function "read" access allow.resource(generateHaiku).to(['read']) ] }) }); カスタムクエリのリゾルバーとしても Function を利用できます。前に作成したリソース定義を使って、カスタムクエリを作成します。 // amplify/data/resource.ts import { type ClientSchema, a, defineData } from '@aws-amplify/backend'; import { generateHaiku } from '../functions/generateHaiku/resource'; const schema = a.schema({ // ... generateHaiku: a.mutation() // specify a "roomId" argument .arguments({ roomId: a.string() }) // we'll return the Haiku as a string .returns(a.ref('Haiku')) // authorize using an API key .authorization(allow =&gt; [allow.authenticated()]) // specify the "generateHaiku" function we just created .handler(a.handler.function(generateHaiku)) }).authorization((allow) =&gt; [allow.authenticated()]); // ... これにより、生成された Data クライアントを使用して、Function を型安全な方法で呼び出すこともできます。クエリが client.queries.generateHaiku() で呼び出されると、Function が実行され、Storage リソースから読み取れるようになります。 任意の AWS サービスでの関数の利用 Amplify は AWS Cloud Development Kit (CDK) の上に構築されているため、Amplify が一級のサポートを提供していない AWS サービスとやり取りする必要がある場合は、CDK を使用して Amplify が生成したリソースを拡張または変更できます。 たとえば、Amplify リソースからデータを使用して別の AWS サービス、Amazon Bedrock と通信するための関数を構築します。 // amplify/backend.ts import { Stack } from "aws-cdk-lib/core" import { Effect, PolicyStatement } from "aws-cdk-lib/aws-iam" import { defineBackend } from "@aws-amplify/backend" import { auth } from "./auth/resource" import { data } from "./data/resource" import { storage } from "./storage/resource" import { AMAZON_BEDROCK_MODEL_ID, generateHaiku } from "./functions/generateHaiku/resource" /** * @see https://docs.amplify.aws/react/build-a-backend/ to add storage, functions, and more */ const backend = defineBackend({ auth, data, storage, generateHaiku, }) // ... // access the "generateHaiku" function from your defined backend const generateHaikuFunction = backend.generateHaiku.resources.lambda // use built-in CDK construct methods to extend the Function's role generateHaikuFunction.addToRolePolicy( new PolicyStatement({ effect: Effect.ALLOW, actions: ["bedrock:InvokeModel"], resources: [ `arn:aws:bedrock:${ Stack.of(generateHaikuFunction).region }::foundation-model/${AMAZON_BEDROCK_MODEL_ID}`, ], }) ) TypeScript サポートの拡張 Amplify Functions の定義方法と他のリソースへの接続方法を見てきたところで、次は Amplify が TypeScript を使った Functions の作成体験をどのように向上させているかを見ていきましょう。 環境変数への型指定 Amplify は環境変数について、型の絞り込まれた参照を生成します。環境変数が明示的に宣言されている場合は、関数で生成される env 参照で利用可能になります。例えば、使用する Amazon Bedrock モデル (モデルの詳細は AWS の Amazon Bedrock ドキュメント を参照) を指定する場合は以下のようになります。 // amplify/functions/generateHaiku/resource.ts import { defineFunction } from "@aws-amplify/backend"; export const AMAZON_BEDROCK_MODEL_ID = "anthropic.claude-3-haiku-20240307-v1:0"; export const generateHaiku = defineFunction({ name: "generateHaiku", environment: { AMAZON_BEDROCK_MODEL_ID, }, }); この環境変数は、 environment のキーを使って env で利用できるようになります。 // amplify/functions/generateHaiku/handler.ts import { env } from "$amplify/env/generateHaiku" console.log(env.AMAZON_BEDROCK_MODEL_ID) または、ストレージなどの他のリソースへのアクセスを指定した場合は、Amplify がそのリソースのメタデータ (Amazon S3 バケット名など) への参照を作成します。 // amplify/functions/generateHaiku/handler.ts import { env } from "$amplify/env/generateHaiku" console.log(env.GEN_2_MULTI_CURSOR_DEMO_APP_BUCKET_NAME) 型付きハンドラ関数 関数をカスタムクエリやミューテーションのリゾルバーとして割り当てる場合、Amplify は Function のハンドラー用の型を特別に提供します。 // amplify/functions/generateHaiku/handler.ts import { env } from "$amplify/env/generateHaiku" import { type Schema } from "../../data/resource" // use the prebuilt handler type from your Schema type Handler = Schema["generateHaiku"]["functionHandler"] export const handler: Handler = async (event) =&gt; { // arguments are typed based on the query definition const { roomId } = event.arguments // to satisfy the handler's "returnType" requirement, return the Haiku return { content: "", roomId, } } 事前設定済みの TypeScript ビルド create-amplify で Amplify アプリを作成すると、Amplify は最新の設定を含む TypeScript プロジェクト設定ファイルをスキャフォールディングし、 esbuild を使用して Functions をバンドルします。 ファンクションのエントリポイントごとに個別の設定を心配する必要はありません。また、ビルドスクリプトも不要です。 esbuild と最新の TypeScript プロジェクト設定を使用することで、Amplify は他のモジュールからの TypeScript ファイルのインポートを可能にします。 モノレポの環境では、これによりビジネスロジックをモジューラー化し、パッケージの TypeScript を JavaScript にコンパイルする必要がなくなるため、Functions 間で再利用できます。 関数内のシークレット Amplify Funcsions は、Lambda 関数と他のAWSサービスに依存した環境変数を定義する際の複雑性と、AWS SDKが実行時にシークレット値を解決するためのお決まりの記述を不要にします。 シークレットは、個人の Cloud 環境インスタンスで使用する場合は CLI で作成されるか、 ブランチデプロイの場合は Amplify コンソールで作成されます 。 Amplify Sandbox では、CLI を使用してシークレットが設定されます。 npx ampx sandbox secret set MY_SECRET Secrets は次に、 secret() を使って関数の environment にバインドできます。 // amplify/functions/generateHaiku/resource.ts import { defineFunction, secret } from "@aws-amplify/backend" export const generateHakiu = defineFunction({ name: "generateHaiku", environment: { MY_SECRET: secret("MY_SECRET") }, }) そして環境変数と同様に利用できます。 // amplify/functions/generateHaiku/handler.ts import { env } from "$amplify/env/generateHaiku" console.log(env.MY_SECRET) Get Started Today! これまでに以下のことを説明しました。 Amplify Functions の定義方法 カスタムクエリやミューテーションのリゾルバとして Amplify Functions を使う方法 Amplify Functions に他の Amplify リソースへのアクセスを許可する方法 Amplify Functions に任意の AWS サービスへのアクセスを許可する方法 Amplify Functions での環境変数とシークレットの使用方法 Amplify Functions のハンドラの型付けや、その他の TypeScript の機能の使い方 これらの機能が実際の設定でどのように組み合わされているかを確認するには、 day-3 ブランチのサンプルアプリ を参照してください。 今すぐ Amplify Functions を使い始めるには、 npm create amplify@latest を実行し、 Amplify Functions のドキュメント を参照して詳細を確認してください! 本記事は、 Amplify Functions: Create serverless functions using TypeScript, powered by AWS Lambda を翻訳したものです。翻訳は Solutions Architect の 吉村 が担当しました。

本記事は、 Amazon Personalize launches new recipes supporting larger item catalogs with lower latency を翻訳したものです。翻訳は Solutions Architect の小川翔が担当しました。 パーソナライズされた顧客体験は、今日のユーザーを惹きつけるために不可欠です。しかし、ユーザーの行動の変化に適応する本当にパーソナライズされた体験を提供することは、チャレンジングかつ時間のかかるものです。 Amazon Personalize を使えば、機械学習の専門知識がなくても簡単に Amazon が使用しているものと同じ機械学習テクノロジーを使って、ウェブサイト、アプリ、メールなどをパーソナライズできます。Amazon Personalize が提供する レシピ (特定のユースケース用のアルゴリズム) を使えば、商品やコンテンツのおすすめ、パーソナライズされた並べ替えなど様々なパーソナライズを実現できます。 2024/5/2、Amazon Personalize の2つの高度なレシピ、 User-Personalization-v2 と Personalized-Ranking-v2 の一般提供を発表できることを嬉しく思います。これらのレシピは 最新の Transformer アーキテクチャ に基づいており、より大規模な商品カタログに対応しながら低レイテンシーを実現しています。 この投稿では、新機能の概要を説明し、モデルの学習プロセスとユーザーへの推薦方法をご案内します。 新レシピのメリット 新しいレシピでは、スケーラビリティ、レイテンシー、モデルのパフォーマンス、機能性が強化されています。 高いスケーラビリティ – 新しいレシピでは最大 5 百万アイテムのカタログと 30 億件のユーザーとアイテムのインタラクションデータを用いた学習が可能になり、大規模カタログや何十億もの利用イベントがあるプラットフォームでの適用が可能になりました。 レイテンシーの短縮 – 大規模データセットの場合でも、推論時間と学習時間が短縮されたことで、エンドユーザーの待ち時間を削減できます。 パフォーマンスの最適化 – Amazon Personalize でのテストでは、v2 レシピがレコメンデーションの精度を最大 9 % 高め、レコメンデーションのカバレッジを最大 1.8 倍にする結果が出ています。カバレッジが高いということは、Amazon Personalize がカタログの多くのアイテムを推薦できるということです。 推論レスポンスにアイテムメタデータを返す – 新しいレシピではアイテムメタデータがデフォルトで追加料金なしで有効化されているので、ジャンル、説明、入手可能性など、メタデータを推論レスポンスに含めることができます。これにより追加作業なしにユーザーインターフェースでレコメンデーションを充実させることができます。Amazon Personalize を生成 AI と組み合わせる場合は、メタデータをプロンプトに取り入れることもできます。大規模言語モデルに豊富な文脈を提供することで、商品属性を深く理解しより関連性の高いコンテンツを生成することができるようになります。 高度な自動化されたオペレーション &nbsp;– 新しいレシピはモデルの学習とチューニングのオーバーヘッドを削減するように設計されています。例えば、Amazon Personalize はトレーニング設定の単純化と、カスタムモデルの最適な設定を内部的に自動選択します。 ソリューションの概要 User-Personalization-v2 および Personalized-Ranking-v2 レシピを使用するには、まず Amazon Personalize のリソースをセットアップする必要があります。データセットグループを作成し、データをインポートして、ソリューションバージョンを作成し、キャンペーンをデプロイしてください。詳細な手順については、 Getting Started をご覧ください。 この投稿では、キャンペーンをデプロイするために Amazon Personalize コンソールを使った方法に沿ってご案内します。代わりに SDK を使ってソリューション全体を構築することもできます。また、非同期のバッチフローを使って一括で推薦を取得することもできます。ここでは、 MovieLens 公開データセット と User-Personalization-v2 レシピを使って、ワークフローを説明します。 データセットの準備 次の手順でデータセットを準備してください: データセットグループを作成 します。各データセットグループには、最大 3 つのデータセット (ユーザー、アイテム、インタラクション) を含めることができ、 User-Personalization-v2 および Personalized-Ranking-v2 ではインタラクションデータセットは必須です。 スキーマ を使用して、インタラクションデータセットを作成します。 Amazon Simple Storage Service (Amazon S3) から、 インタラクションデータを Amazon Personalize にインポート します。 モデルの学習 データセットのインポートジョブが完了したら、トレーニングの前にデータを分析できます。Amazon Personalize の Data analysis 機能では、データに関する統計情報と、トレーニングの要件を満たしてレコメンデーションを改善するためのアクションを確認できます。 これで、モデルを学習する準備が整いました。次にモデルを学習する手順を示します。 Amazon Personalize コンソールで、ナビゲーションメニューから Dataset groups を選択します。 作成したデータセットグループを選択します。 Create solutions を選びます。 Solution name には、ソリューション名を入力します。 Solution type では、 Item recommendation を選びます。 Recipe では、新しい aws-user-personalization-v2 のレシピを選びます。 Training configuration セクションで、 Automatic training では Turn on を選択します。これにより、定期的なトレーニングでモデルの有効性を維持することができます。 Hyperparameter configuration で、 Apply recency bias （最新データへの重み付け） を選択します。これにより、モデルがインタラクションデータセットの最新のアイテムインタラクションデータにより重みを置くようになります。 &nbsp;Create solution を選びます。 Automatic training を有効にした場合、Amazon Personalize は最初のソリューションバージョンを自動的に作成します。ソリューションバージョンとは、トレーニングされた ML モデルのことを指します。ソリューションバージョンが作成されると、Amazon Personalize はレシピとトレーニング設定に基づいて、ソリューションバージョンに紐づくモデルをトレーニングします。ソリューションバージョンの作成を開始するまでに最大で 1 時間かかります。 ナビゲーションペインの Custom resources で、 Campaigns を選択してください。 Create campaign を選択してください。 キャンペーンは、学習済みモデル (ソリューションバージョン) をデプロイして、リアルタイムの推薦を生成します。v2 レシピで学習したソリューションで作成されたキャンペーンでは、推薦結果にアイテムのメタデータを含めるオプトインが自動的にオンになります。推論リクエストの際にメタデータ列を選択できます。 キャンペーンの詳細を入力してキャンペーンを作成します。 推薦情報を取得する キャンペーンの作成または更新後、ユーザーが最も関心を示すと思われる順に、アイテムの推薦リストを取得できます。 キャンペーンを選択し、 View details を選びます。 Test campaign results セクションで、ユーザー ID を入力し、 Get recommendations を選択します。 次の表は、ユーザーに対する推薦結果です。推薦された商品、関連スコア、商品メタデータ (タイトルとジャンル) が含まれています。 これで、User-Personalization-v2 をウェブサイトやアプリに組み込んで、顧客一人ひとりに合わせた体験を提供できる準備ができました。 クリーンアップ この投稿に従って作成した、アカウント内の不要なリソースは必ず削除してください。キャンペーン、データセット、データセットグループは、Amazon Personalize コンソールまたは Python SDK を使用して削除できます。 まとめ Amazon Personalize の新しい2つのレシピ（ User-Personalization-v2 と Personalized-Ranking-v2 ）はレシピは、大規模なアイテムカタログに対応し、レイテンシの削減、パフォーマンスの最適化により、パーソナライズを次のレベルに引き上げます。Amazon Personalize の詳細は、 Amazon Personalize 開発者ガイド を参照してください。 著者について Jingwen Hu は AWS AI/ML の Amazon Personalize チームでシニアテクニカルプロダクトマネージャーとして働いています。余暇には旅行と現地の食べ物を探索するのを楽しんでいます。 Daniel Foley は Amazon Personalize のシニアプロダクトマネージャーです。人工知能を活用してお客様の最大の課題を解決するアプリケーションの構築に取り組んでいます。仕事の合間には、熱心なスキーヤーとハイカーでもあります。 Pranesh Anubhav は、Amazon Personalize のシニアソフトウェアエンジニアです。顧客に対するスケーラブルな機械学習システムの設計に情熱を持っています。仕事以外では、サッカーをするのが大好きで、レアル・マドリードの熱心な追随者です。 Tianmin Liu は、Amazon Personalize のシニアソフトウェアエンジニアです。様々な機械学習アルゴリズムを用いて、大規模な推薦システムの開発に従事しています。余暇時間は、ビデオゲームをプレイしたり、スポーツを観戦したり、ピアノを弾くことが好きです。 Abhishek Mangal は、Amazon Personalize のソフトウェアエンジニアです。様々な機械学習アルゴリズムを使って大規模な推薦システムの開発に携わっています。余暇にはアニメを視聴することが好きで、ワンピースが最近の物語として最高傑作であると考えています。 Yifei Ma は、AWSAILabs のシニアアプライドサイエンティストであり、レコメンダーシステムに従事しています。彼の研究興味は、能動学習、生成モデル、時系列解析、オンライン意思決定にあります。仕事以外では、航空機愛好家です。 Hao Ding は、AWS AI Labsのシニアアプライドサイエンティストであり、Amazon Personalizeのレコメンデーションシステムの進化に取り組んでいます。彼の研究関心は、レコメンデーション基盤モデル、ベイズ深層学習、大規模言語モデル、およびそれらのレコメンデーションへの応用にあります。 Rishabh Agrawal は、&nbsp;AWS の AI サービスに携わるシニアソフトウェアエンジニアです。余暇には、ハイキング、旅行、読書を楽しんでいます。

AWS Amplify を使用したファイルストレージの新しい体験をご紹介できることを喜ばしく思います。 この強力なストレージソリューションは、 Amazon Simple Storage Service (Amazon S3) と簡単に統合でき、Amplify のフルスタック TypeScript 開発者体験を通じて、開発者がファイル構造をより詳細に制御し、柔軟に設定できるようになります。経験豊富な開発者でも、これから始める初心者の方でも、Amplify Storage ならクラウドベースのファイル保管を直感的に管理でき、アプリケーションの要件に応じて確実に実装できます。 本日、AWS Amplify Storage におけるフルスタック TypeScript エクスペリエンスを発表します。Amplify Storage を使うことで、以下のことが可能になります。 5 行に満たないコードでストレージバケットを定義 パスベースのアクセス許可を構成 Amplify のゼロコンフィグ UI コンポーネントとクライアントライブラリを使用して、ストレージバックエンドからファイルのアップロードとダウンロード Amplify コンソールの新しくデザインされたファイルブラウザを使用して、ファイルとフォルダを管理 先週、新しい開発者体験である Amplify Gen 2 が一般提供されました。ストレージ以外のこのリリースについて詳しく知りたい方は、 フルスタック TypeScript : AWS Amplify を再び紹介 をお読みください。 Amazon S3 上に構築された、簡素化された新しいストレージインターフェイス Amplify Storage の機能をより深く理解するため、コードサンプルを用いて説明します。このブログ記事で紹介されている Storage 機能の実働サンプルは こちらのソーシャルルームデモアプリ を参照してください。 5 行未満のコードでストレージバケットをデプロイ Amplify Gen2 で注目すべき機能の 1 つが、TypeScript ベースのバックエンド構築体験です。これにより、わずか数行のコードでストレージリソースを構成および管理できます。さらに、サンドボックス環境でストレージ機能を即座にテストできるため、チームの全開発者が独立して反復処理を行えます。 バックエンド構成にストレージを追加するには、新しいフォルダ amplify/storage と、 amplify/storage/ の下に resource.ts ファイルを作成します。 ストレージバックエンドを定義するには、 defineStorage 関数を使用して、ストレージリソースの分かりやすい名前を指定します。この名前はストレージリソースを簡単に識別するエイリアスとして機能しますが、実際に作成される S3 バケットには、アプリケーションの個別かつセキュアなストレージ場所を確保するために、一意の識別子が付加されることに注意が必要です。 下記のコードは、新しく作成された amplify/storage/resource.ts ファイルに記述されます。ここでは、ストレージバックエンドオブジェクトを定義し、ストレージリソースに「gen2-multi-cursor-demo-app」という名前を付けています。 import { defineStorage } from "@ aws-amplify/backend"; export const storage = defineStorage({ name: 'gen2-multi-cursor-demo-app' }) }); 次に、このストレージオブジェクトを amplify/backend.ts ファイルのバックエンド定義に含めます。 これで backend.ts ファイルは次のようになるはずです。 import { defineBackend } from '@ aws-amplify/backend'; import { auth } from './auth/resource'; import { data } from './data/resource'; import { storage } from './storage/resource'; const backend = defineBackend({ auth, data, storage }); ストレージリソースを定義すると、サンドボックス環境はその変更をすぐに認識し、ローカル開発用のストレージリソースのデプロイを開始します。このシームレスな統合により、ローカル開発環境ですぐに強力なクラウドストレージ機能を活用できます。 ストレージバックエンドのパスベースアクセス許可のカスタマイズ Amplify Storage では、ストレージリソースへのアクセス管理を細かく制御できます。ゲストユーザー、認証済みユーザー、所有者、ユーザーグループ、さらには関数まで、さまざまなユーザーロールに対して個々のファイルパスへの細かなアクセス許可を定義でき、特定の要件に合わせることができます。デモアプリでは、サインイン済みのユーザーが各ルームで画像をアップロードできるようにします。また、サインインしていない「ゲストユーザー」はアップロードされた画像を閲覧できるようにします。この機能を実現するには、ストレージリソースに特定のアクセス制御を定義する必要があります。目的のアクセス権限は次のとおりです。 ゲストユーザーは読み取り専用アクセスを持ち、アップロードされた画像を閲覧できるようにします。 認証済み (サインイン済み)のユーザーは、フルアクセス権を持ち、新しい画像のアップロード、既存の画像の閲覧、必要に応じてすべての画像の削除ができるようにします。 上記の規則に基づいて、アクセス定義は次のようになります。 import { defineStorage } from "@ aws-amplify/backend"; export const storage = defineStorage({ name: 'gen2-multi-cursor-demo-app', access: allow =&gt; ({ 'room/*': [ allow.guest.to(['get']), allow.authenticated.to(['get', 'write', 'delete']) ] }) }); ストレージリソースでは、デフォルト拒否 (deny-by-default) ポリシーを導入していることに注意が必要です。これにより、 amplify/storage/resource.ts ファイルを通して明示的にアクセスが許可されない限り、ユーザーがストレージリソース内のあらゆるファイルパスやディレクトリにアクセスできません。この原則に従うことで、アクセス権限を厳密に管理し、潜在的な脆弱性を最小限に抑えられます。 さらに、ユーザーグループに全アクセス権を付与することもできます。この例では、管理者ユーザーにストレージリソースへの完全なアクセス権を付与したい場合、まず認証バックエンド( amplify/auth/resource.ts ファイル)でユーザーグループを作成する必要があります。このグループリソースを「admin」と命名します。 amplify/auth/resource.ts ファイルは次のようになります。 import { defineAuth } from '@ aws-amplify/backend'; export const auth = defineAuth({ loginWith: { email: true }, groups: ['admin'] }); このグループへのアクセスは、 amplify/storage/resource.ts ファイル内で個別に指定できるようになりました。 export const storage = defineStorage({ name: 'gen2-multi-cursor-demo-app', access: (allow) =&gt; ({ 'room/*': [ allow.guest.to(['get']), allow.authenticated.to(['get', 'write', 'delete']), allow.groups(['admin']).to(['read', 'write', 'delete']) ] }) }); ストレージバックエンド定義にアクセス認証機能を組み込むための詳細については、 こちらの包括的なドキュメントを参照してください 。 Amplify の UI とクライアントライブラリによるファイルのアップロードとダウンロード Amplify の UI コンポーネント Storage Image と Storage Manager を使用して、画像表示やファイルアップロードの機能を数分で実装したり、 Amplify ライブラリ でファイル管理機能をさらにカスタマイズして、アプリの要件を満たすことができます。クライアント API の新しい path パラメータを使用すると、カスタム定義されたストレージ構造やアクセス権限を利用できます。 デモアプリを拡張する前に、ターミナルウィンドウで npx ampx sandbox を実行していることを確認してください。このクラウドサンドボックスを使用すると、構成されたストレージバックエンドに対してアプリをテストできます。 ストレージバックエンドを設定したので、次はこの新機能とやり取りするようアプリを更新する時間です。 フルスタック TypeScript : AWS Amplify を再び紹介 で紹介したデモアプリを使います。また、 サンプルリポジトリ (branch: day 1) からクローンすることもできます。 Amplify Storage の uploadData API を使って、画像を設定済みのストレージバックエンドにアップロードします。アップロードした画像の一時 URL (プライベートファイルへのセキュアなアクセスを提供する一時的な URL)を取得するため、 getUrl API も使用し、画像を表示できるようにします。 次のコードサンプルでは、 getUrl と uploadData API の使用例を確認できます。データモデルの更新を含む残りのコードサンプルについては、 PictureManager.tsx を参照してください。 import { getUrl, uploadData } from "aws-amplify/storage"; // ... // getUrl API const imageUrls = ( await Promise.all( pictures.map(async (item) =&gt; await getUrl({ path: item.path })) ) ).map((item) =&gt; item.url.toString()); // ... // uploadData API const result = await uploadData({ path: `room/${ roomId }/${ file.name } `, data: file, }).result ; 次に、ユーザーがアップロードした画像を消去して、リフレッシュできるようにする方法を実装します。これには、Amplify Storage の remove API を使用します。 await Promise.all(pictures.map((item) =&gt; remove({ path: item.path }))); 注意 : このデモアプリケーションの完全な動作サンプルについては、 Amplify Social Room サンプルアプリ (ブランチ: day 2) を参照してください。以下のように、部屋ごとに画像のアップロードとクリアができます。 コミットした変更内容は git push でワーキングブランチにプッシュします。バックエンド側の変更はすべて、Amplify のCI/CD ワークフローの一環として自動的にデプロイされます。ビルドが完了すれば、更新内容をチームで共有できるURL にアクセスできます！ Amplify コンソールでストレージファイルブラウザを再設計 これらの新しいストレージ機能を補完するため、Amplify コンソールにストレージリソースのコンテンツを管理する専用のタブが追加されました。デプロイされたアプリをテストすると、このインターフェースでストレージリソースの更新状況を確認できます。ファイルやフォルダを簡単に追加、移動、削除できるので、オンデマンドでストレージリソースを整理、管理できます。ユーザーフレンドリーなコンソール環境から直接管理できます。 まとめ おめでとうございます！ Amplify Gen 2 の最新のバックエンド構築と保管機能を使って、完全に機能するアプリの実装とデプロイが完了しました！これからも新しい Amplify の機能を次々と公開していく予定ですので、引き続き最新情報に注目してください！ Amplify はオープンソースプロジェクトであり、高いパフォーマンスでスケーラブルなアプリを構築するために、どのように支援できるかコミュニティからのフィードバックを常に歓迎しています。 Discord サーバー での議論に参加したり、各種の GitHub プロジェクト で機能リクエストやバグを報告したりすることで、お客様からのご意見をお聞かせください。Amplify の詳細を知り、構築を始めるには、 ドキュメントガイド をご覧ください。 この記事は、 Amplify Storage: Now with fullstack TypeScript, powered by Amazon S3 を翻訳したものです。翻訳はソリューションアーキテクトの 髙柴元 が担当致しました。

AWS は re:Invent 2023 で Amazon CloudWatch Application Signals を発表しました。これは Java アプリケーションの健全性をモニタリングして理解するための新機能です。本日、Application Signals が Python アプリケーション のサポートを開始したことをお知らせします。 Application Signals を有効化することで、コード変更なしで Python アプリケーションに AWS Distro for OpenTelemetry (ADOT) を導入できるようになります。これにより、Python を使って開発されたライブラリやフレームワークの主要なメトリクスとトレースを収集できます。カスタムコードの作成やダッシュボードの作成なしに、運用上の健全性の優先順位付けやパフォーマンス目標のモニタリングが可能になります。 このブログ記事では、Amazon EKS クラスター上でデプロイされた Python アプリケーションに Application Signals をシームレスに統合する方法について詳しく説明します。具体的には、 Django フレームワークで開発された Python アプリケーションと、 psycopg2 、 boto3 、 requests などの人気のあるライブラリを使用したアプリケーションをモニタリングすることに焦点を当てます。その後、Application Signals コンソールを使用して、アプリケーションの稼働状況を可視化します。 ソリューションの概要 以下に、このソリューションの詳細な技術的な概要を示します。 デモアプリケーションは Spring Cloud と Django フレームワークで構築されており、各サービスは Eureka discovery-service に登録されます。 アプリケーションコードは G itHub リポジトリ にあります。 insurances と billing の 2 つのサービスは Django フレームワークで記述されており、 Django REST フレームワークを通じて API を公開し、requests ライブラリを使用して外部サービスを呼び出しています。 サービスは psycopg2 を使用して Amazon RDS for PostgreSQL とやり取りし、 boto3 ライブラリを使用して AWS DynamoDB に請求情報を格納しています。 図 1: デモアプリケーションで使用される Python のライブラリとフレームワーク 図 2 に示すリソースを Terraform でデプロイします。CloudWatch エージェントと Fluent Bit をデーモンセットとしてデプロイし、 Amazon CloudWatch Observability EKS アドオン を使用します。これらのコンポーネントは、メトリクス、ログ、トレースを管理します。 図 2: ソリューションアーキテクチャ 前提条件 1. 有効な AWS アカウントを準備してください 2. AWS Command Line Interface (AWS CLI) バージョン 2 をインストールしてください 3. AWS CLI の資格情報を設定してください 4. Terraform をインストールしてください 5. Kubectl をインストールしてください 6. Docker をインストールしてください 解決策の手順解説 Application Signals の有効化 アカウントの Application Signals を有効化する手順 に従ってください。 Terraform を使用したアプリケーションのデプロイ 以下のコマンドを実行して、Terraform を使用してアプリケーションをデプロイするために必要な 環境変数を設定 し、バックエンドとして Amazon S3 バケットを設定 します。 export AWS_REGION = aws s3 mb s3://tfstate-$(uuidgen | tr A-Z a-z) export TFSTATE_KEY = application-signals/demo-applications export TFSTATE_BUCKET =$(aws s3 ls --output text | awk '{ print $ 3 }' | grep tfstate-) export TFSTATE_REGION =$ AWS_REGION export TF_VAR_cluster_name = app-signals-demo export TF_VAR_cloudwatch_observability_addon_version = v1.5.1-eksbuild.1 次に、 アプリケーションリポジトリをクローン し、 Terraform を使用してインフラストラクチャをデプロイ します。リソースのプロビジョニングに成功するまで 15 ～ 20 分かかります。 git clone https://github.com/aws-observability/application-signals-demo cd application-signals-demo/terraform/eks terraform init -backend-config ="bucket =${ TFSTATE_BUCKET }" -backend-config ="key =${ TFSTATE_KEY }" -backend-config ="region =${ TFSTATE_REGION }" terraform apply --auto-approve kubectl の設定 次のコマンドを実行して、 kubeconfig ファイルを更新し、 Amazon EKS Cluster エンドポイントをローカルに追加 してください。 aws eks update-kubeconfig --name $ TF_VAR_cluster_name --region $ AWS_REGION --alias $ TF_VAR_cluster_name Kubernetes リソースのアノテーションを使ったデプロイ Python アプリケーションで Application Signals を有効にするには、クラスターのマニフェスト YAML に instrumentation.opentelemetry.io/inject-python: 'true' というアノテーションを追加する必要があります。このアノテーションを追加すると、アプリケーションが自動的にインストルメント化され、メトリクス、トレース、ログを Application Signals に送信するようになります。 spec: replicas: 1 selector: matchLabels: io.kompose.service: billing-service-python template: metadata: labels: io.kompose.service: billing-service-python annotations: instrumentation.opentelemetry.io/inject-python: 'true' /demo-app/k8s/ の下にある デプロイ用の YAML ファイルには、必要なアノテーションが含まれています。以下のコマンドを実行してすべてのリソースをデプロイします。まず、アプリケーションをコンパイル、Docker イメージを作成し、リモートの ECR (Amazon Elastic Container Registry) の Docker リポジトリにプッシュしてから、EKS クラスターにデプロイします。 cd ../.. ./mvnw clean install -P buildDocker export ACCOUNT = `aws sts get-caller-identity | jq .Account -r` export REGION =$ AWS_REGION ./push-ecr.sh ./scripts/eks/appsignals/tf-deploy-k8s-res.sh デプロイの結果の検証 アプリケーションリソースが 正常にデプロイされたことを確認 するため、以下のコマンドを実行してください。ステータスが Running のポッドのリストが表示されるはずです。 kubectl get pods #Output NAME READY STATUS RESTARTS AGE admin-server-java-5c57ddcb46-t4b9l 1/1 Running 0 7m1s billing-service-python-6bf9766cfc-5g67s 1/1 Running 0 6m52s config-server-58d94894-dzdhz 1/1 Running 0 6m47s customers-service-java-69c5d75cc9-5hwrw 1/1 Running 0 6m42s customers-service-java-69c5d75cc9-tfrts 1/1 Running 0 6m43s discovery-server-d6bff754f-xgrxv 1/1 Running 0 6m36s insurance-service-python-6745799b9b-4hdxc 1/1 Running 0 6m33s pet-clinic-frontend-java-5696d89cd8-cpvj2 1/1 Running 0 6m56s pet-clinic-frontend-java-5696d89cd8-mlggq 1/1 Running 0 6m56s vets-service-java-5b6969b8d6-cfvsb 1/1 Running 0 6m29s visits-service-java-85b9c5c45-p57m5 1/1 Running 0 6m25s visits-service-java-85b9c5c45-vwkht 1/1 Running 0 6m25s visits-service-java-85b9c5c45-vx6gj 1/1 Running 0 6m25s 次に、以下のコマンドを実行して アプリケーションにアクセスするための URL を取得してください。ウェブブラウザでその URL を開き、 アプリケーションを体験することができます 。URL が有効になるまで 2～3 分かかる場合があります。 echo "http://$(kubectl get ingress -o json --output jsonpath ='{.items[0].status.loadBalancer.ingress[0].hostname }')" CloudWatch Canary を作成し、トラフィックを生成する 次に、以下のスクリプトを実行して Canary を作成 します。このスクリプトは 10 分間実行され、アプリケーションのトラフィックを生成します。 endpoint =$(kubectl get ingress -o json --output jsonpath ='{.items[0].status.loadBalancer.ingress[0].hostname }') cd scripts/eks/appsignals/ ./create-canaries.sh $ AWS_REGION create $ endpoint CloudWatch Application Signals を使用したアプリケーションの可視化 CloudWatch コンソール に移動し、左側のナビゲーションペインの Application Signals セクションにある サービス &nbsp;を選択します。 サービスダッシュボード CloudWatch Application Signals は、初期状態で追加のセットアップを必要とせずに、 サービス ダッシュボードからサービスの一覧を自動的に作成します。この統合されたアプリケーション中心のビューは、ユーザーがサービスとどのように対話しているかを全体的に把握するのに役立ちます。パフォーマンスの異常が発生した場合、この機能を使ってトラブルの切り分けをすることができます。 図 3: サービスダッシュボード 詳細なサービス情報と依存関係 サービス詳細ページには、Application Signals 機能を使用しているサービスについて、サービスの概要、オペレーション、依存関係、Canary、クライアントからの要求が表示されます。 このページを表示するには、 CloudWatch コンソール を開き、左側のナビゲーションペインの Application Signals セクションにある Services を選択します。そして、 Services テーブルまたは Top service &nbsp;あるいは依存関係テーブルから、 任意のサービス名を選択 してください。 図 4 に示すように、 Service Overview セクションでは、サービスを構成するコンポーネントを要約し、トラブルシューティングが必要な問題を特定するための重要なパフォーマンスメトリクスをハイライトしています。 図 4: Service Overview Service operations タブに移動し、オペレーションを選択、メトリクスチャートの特定の時間ポイントをクリックすると、選択したポイントに関連する相関トレース、主要な要因、アプリケーションログを含むペインが開きます。 図 5: Service operations トレース ID をクリックすると、トレースの詳細ページに移動します。そこではこのトレース ID に関連するすべてのアップストリーム及びダウンストリームのサービスが、AWS X-ray トレースマップに表示されます。 図 6: サービスオペレーションメトリクスと関連付けられたトレースを可視化 Top Contributors セクションでは、 Call Volume、Availability、Average Latency、Errors と Faults のメトリックを、インフラストラクチャコンポーネント別に直接表示します。 Application Logs タブでは、関連するアプリケーションログを表示するための Logs Insights クエリを確認できます。 図 7: Top Contributors と Application Logs 数クリックすると相関のあるトレースが表示されます。これにより、手動でトレースを別々に照会することなく問題の根本原因を理解できます。 サービスマップ サービスマップを表示するには、 CloudWatch コンソール を開き、左側のナビゲーションペインにある Application Signals セクションの Service Map を選択して 図 8 に示されているように、 billing-service-python のサービスノードを選択すると、それらのサービス間の接続およびサービスの依存関係ノードを確認できます。これにより、アプリケーションのトポロジーと実行フローを理解しやすくなります。サービスの運用と開発が別組織の場合に特に有用です。 図 8: サービスマップを使ってアプリケーショントポロジーを表示 サービスレベル目標 (SLOs) Application Signals を使用して、最も重要なビジネス オペレーションのサービス レベル目標 (SLO) を定義します。これらのサービスの SLO を定義すると、SLO ダッシュボードでそれらを監視できるようになり、最も重要なオペレーションの概要を素早く把握できます。SLO の条件には、レイテンシ、可用性、CloudWatch メトリクスが含まれ、包括的な監視機能を提供します。 PetClinic アプリケーションの SLO 作成 の手順に従って、 SLO を作成 してください。 図 9: サービスレベル目標 (SLO) を作成し可視化する クリーンアップ 注意: アプリケーションを正常に削除するには、前に定義した 環境変数の値 が必要です。 料金の発生を停止するには、次のコマンドを実行してアプリケーションをクリーンアップしてください。所要時間は 15 ～ 20 分です。 cd ../../.. ./scripts/eks/appsignals/create-canaries.sh $ AWS_REGION delete kubectl delete -f ./scripts/eks/appsignals/sample-app/alb-ingress/petclinic-ingress.yaml cd ./terraform/eks terraform destroy --auto-approve 結論 このブログでは、Amazon EKS クラスター上で実行されている Python アプリケーションを、コード変更を行うことなくシームレスに計装するための CloudWatch Application Signals の活用方法について説明しました。この強力な機能により、アプリケーションサービスのゴールデンメトリクス (リクエスト数、可用性、レイテンシー、障害、エラー) とトレースを簡単に収集でき、監視とトラブルシューティングが容易になります 。 さらに、Application Signals が提供する既製のダッシュボードを使うことで、アプリケーションサービスの全体の活動状況と運用の健全性をどのように視覚化できるかを説明しました。これらのダッシュボードを活用することで、主要なパフォーマンスメトリクスにすばやくアクセスし、トレースと関連付けて、根本的な問題を数クリックで簡単に特定して対処できます。次のステップとして、お客様の環境で Application Signals を試してみることをお勧めします。 CloudWatch Application Signals のドキュメント を参照して、さらに詳しい情報を確認するか、 One Observability Workshop の CloudWatch Application Signals のユースケース を体験してみてください。 著者について Yagr Xu Yagr は、AWS の Senior Solutions Architect で、IT 業界での経験は 15 年以上です。ソフトウェア開発者、データエンジニア、そしてソリューションアーキテクトとして従事してきました。モダンなクラウドアーキテクチャの設計と複雑な技術的課題の解決のために顧客との協働を楽しんでいます。仕事の合間には、アイスホッケー、サッカー、バスケットボール、バドミントンなどのスポーツに情熱を注いでいます。 Jay Joshi Jay は、AWS の Senior Cloud Support Engineer で、Amazon CloudWatch と Route 53 を専門としています。モニタリングとオブザーバビリティを活用してシステムを強化する顧客のサポートに情熱を注いでいます。プライベートでは、アニメを観ることと家族と時間を過ごすことが好きです。LinkedIn: /jayjoshi31 本記事は、 Monitor Python apps with Amazon CloudWatch Application Signals (Preview) を翻訳したものです。翻訳はテクニカルアカウントマネージャーの日平が担当しました。

コンテナ化されたアプリケーションを監視するには、正確性と効率性が求められます。アプリケーションの規模が大きくなるにつれて、アプリケーションとインフラストラクチャのメトリクスを収集して要約することは困難になります。この課題に対処する方法の 1 つは、AWS が提供するネイティブのモニタリングツール Amazon CloudWatch Container Insights を使用することです。 Amazon CloudWatch Container Insights は、お客様がAmazon Elastic Kubernetes Service クラスター (Amazon EKS) 上で実行されるアプリケーションからメトリクスとログを収集、集計、および要約するのに役立ちます。2023 年 11 月 6 日、AWS は、コンテナレベルの詳細な正常性、パフォーマンス、ステータスメトリクスを収集し、コントロールプレーンのメトリクスも収集する Container Insights の拡張バージョン をアナウンスしました。さらに 2024 年 4 月 10 日、AWS はAmazon EKS の Windows ワークロード向けに Amazon CloudWatch Container Insights の提供を開始しました。 お客様は、 container_cpu_utilization 、 pod_cpu_requested 、 pod_cpu_limit などのメトリクスを Windows アプリケーション用に収集できるようになりました。アウトオブボックスのパフォーマンスメトリクススダッシュボードを使用して、アプリケーションの健全性を理解し、Amazon EKS 上のコンテナ化された Windows アプリケーションの問題を効率的にデバッグできます。CloudWatch Container Insights は、 埋め込みメトリクス形式 を使用してメトリクスデータをパフォーマンスログイベントとして収集します。このデータから、Amazon CloudWatch は、クラスター、ノード、ポッド、サービスレベルで CloudWatch メトリクスとして集約メトリクスを作成します。Container Insights が収集するメトリクスは、CloudWatch の自動ダッシュボードで利用できます。メトリクススの収集は CloudWatch Agent が行い、ログの収集は Fluent Bit が行います。CloudWatch Agent と Fluent Bit の両コンポーネントは、 Amazon CloudWatch Observability EKS Add-on を有効にするときとデプロイされます。 本記事では、Amazon EKS Windows クラスターに Container Insights を有効化するプロセスを説明します。 Amazon EKS Windows クラスターの Container Insights のセットアップ 前提条件 AWS アカウント Kubectl eksctl AWS Command Line Interface (AWS CLI) v2 AWS CLI の認証情報が設定済み Amazon EKS Windows クラスターの作成 まず、Amazon EKS Windows クラスターの作成から始めましょう。クラスターをセットアップする最も簡単な方法は、Amazon EKS の公式 CLI ツールである eksctl を使用することです。以下のコマンドは、 eks-windows-ci という名前のクラスターを作成し、クラスターに 2 つの Linux ノードを追加します。現在、Windows ノードとポッド ネットワーキングをサポートするには、少なくとも 1 つの Linux ノードが必要です。ただし、この例では、高可用性を実現するために 2 つの Linux ノードを指定しています。 この記事を書いている時点で、サポートされている Amazon EKS の最新バージョンは 1.29 であり、サポート対象の Amazon EKS バージョンならどれを選んでも構いません。 eksctl create cluster \ --name eks-windows-ci \ --version 1.29 \ --nodegroup-name linux-ng \ --node-type m5.large \ --region us-east-1 \ --nodes 2 \ --nodes-min 1 \ --nodes-max 3 \ --node-ami-family AmazonLinux2 \ --disable-pod-imds 次に、クラスターにいくつかの Windows ノードを追加する必要があります。eksctl を使用してクラスターを作成した場合は、以下のコマンドで実行できます。別のクラスターで作業する場合は、 ドキュメント を参照して、Windows ノードグループの作成方法とクラスターへの接続方法を確認してください。 利用するリージョンで最新の Windows AMI ID を確認するには、AWS Systems Manager Parameter Store を照会します。手順については、 Amazon EKS ドキュメント をご覧ください。 eksctl create nodegroup \ --region us-east-1 \ --cluster eks-windows-ci \ --name windows-ng \ --node-type m5.large \ --nodes-min 2 \ --node-ami-family WindowsServer2022FullContainer \ --disable-pod-imds 次に、 Amazon VPC IP Address Manager (IPAM) を有効にするために amazon-vpc-cni configmap を変更しましょう。 cat &lt;&lt; EOF &gt; amazon-vpc-cni.yaml --- apiVersion: v1 kind: ConfigMap metadata: name: amazon-vpc-cni namespace: kube-system data: enable-windows-ipam: "true" --- EOF kubectl apply -f amazon-vpc-cni.yaml クラスターが起動して実行中であることを確認するために、kubectl コマンドを使用しましょう。 nht-admin:~/environment $ kubectl get nodes -o wide NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME ip-192-168-10-132.ec2.internal Ready &lt;none&gt; 2d11h v1.28.5-eks-5e0fdde 192.168.10.132 107.23.236.165 Windows Server 2022 Datacenter 10.0.20348.2227 containerd://1.6.18 ip-192-168-14-178.ec2.internal Ready &lt;none&gt; 2d v1.28.5-eks-5e0fdde 192.168.14.178 54.80.175.223 Windows Server 2022 Datacenter 10.0.20348.2227 containerd://1.6.18 ip-192-168-29-193.ec2.internal Ready &lt;none&gt; 2d11h v1.28.5-eks-5e0fdde 192.168.29.193 3.90.176.199 Amazon Linux 2 5.10.205-195.807.amzn2.x86_64 containerd://1.7.11 ip-192-168-33-121.ec2.internal Ready &lt;none&gt; 2d11h v1.28.5-eks-5e0fdde 192.168.33.121 18.207.151.28 Amazon Linux 2 5.10.205-195.807.amzn2.x86_64 containerd://1.7.11 ip-192-168-46-41.ec2.internal Ready &lt;none&gt; 2d11h v1.28.5-eks-5e0fdde 192.168.46.41 52.90.145.146 Windows Server 2022 Datacenter 10.0.20348.2227 containerd://1.6.18 Amazon CloudWatch Observability EKS アドオンのインストール Container Insights を有効にする最も簡単な方法は、 Amazon CloudWatch Observability EKS アドオン をデプロイすることです。Amazon CloudWatch Observability EKS アドオンは、CloudWatch エージェントと Fluent-bit エージェントを Amazon EKS クラスターにインストールします。Amazon CloudWatch Observability EKS アドオンを利用することで、デフォルトでAmazon EKSに対する Container Insights の拡張されたオブザーバビリティと CloudWatch Application Signals が有効になります。なお、CloudWatch Application signals は現在 Windows ではサポートされていません。このアドオンを使用すると、Amazon EKS クラスターからインフラストラクチャに関するメトリクス、アプリケーションパフォーマンスに関するテレメトリデータ、コンテナのログを収集できます。Fluent Bit がクラスターからコンテナログを CloudWatch Logs に送信します。これにより、コンテナからのアプリケーションとシステムログを把握できます。Amazon EKS アドオンを使用するには、クラスターのワーカーノードで使用される IAM ロールに必要な IAM 権限を設定します。Windows ワーカーノードの場合は、インスタンスロールに IAM ポリシーを関連付けます。 my-windows-worker-node-role を Windows ノードグループの IAM ロールに置き換えてください。 aws iam attach-role-policy --role-name &lt;&lt;my-windows-worker-node-role&gt;&gt; --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy aws eks create-addon --cluster-name eks-windows-ci --addon-name eks-pod-identity-agent --addon-version v1.1.0-eksbuild.1 --configuration-values $'nodeSelector: \n \"kubernetes.io/os\": \"linux\"' --resolve-conflicts OVERWRITE Linux ワーカーノードでは、 EKS Pod Identities アドオン を利用します。 EKS アドオンをデプロイしましょう。EKS Pod Identity エージェントのデーモンセットは Linux ノードでのみデプロイされるように nodeSelector を設定していることに注目してください。この記事の執筆時点では、EKS Pod Identity エージェントは Windows ワーカーノードでサポートされていませんでした。nodeSelector を指定することで、デーモンセットが Windows ワーカーノードにデプロイされないようにしています。 aws eks create-addon --cluster-name eks-windows-ci --addon-name eks-pod-identity-agent --addon-version v1.1.0-eksbuild.1 --configuration-values $'nodeSelector: \n \"kubernetes.io/os\": \"linux\"' --resolve-conflicts OVERWRITE eksctl create podidentityassociation --cluster eks-windows-ci --namespace amazon-cloudwatch --service-account-name cloudwatch-agent --role-name eks-cw-role --permission-policy-arns arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy --region us-east-1 次に、以下のように Amazon CloudWatch Observability アドオンをインストールしてください。 aws eks create-addon --cluster-name eks-windows-ci --addon-name amazon-cloudwatch-observability Amazon CloudWatch Container Insights は、お客様の EKS クラスターで有効になります。簡単にオンボーディングできるように、EKS コンソールでクラスターを選択し、アドオンタブを表示することで同じアドオンが使用できます。拡張されたメトリクスとログが CloudWatch コンソール に出てくるようになります。以下のコマンドを使って、CloudWatch Container Insights が正常にデプロイされたことを確認しましょう。 $ kubectl get pods -n amazon-cloudwatch NAME READY STATUS RESTARTS AGE amazon-cloudwatch-observability-controller-manager-6d5954fcttgw 1/1 Running 0 44h cloudwatch-agent-9fvj6 1/1 Running 0 44h cloudwatch-agent-cfzmb 1/1 Running 0 44h cloudwatch-agent-windows-fmlbt 1/1 Running 0 44h cloudwatch-agent-windows-g298d 1/1 Running 0 44h cloudwatch-agent-windows-pw9pl 1/1 Running 0 44h fluent-bit-ctls2 1/1 Running 0 44h fluent-bit-windows-5t57v 1/1 Running 5 (44h ago) 44h fluent-bit-windows-6qhm4 1/1 Running 8 (43h ago) 44h fluent-bit-windows-mcdrm 1/1 Running 6 (19h ago) 44h fluent-bit-wmgp6 1/1 Running 0 44h 注: Windows では、 pod_network_rx_bytes や pod_network_tx_bytes などのネットワークメトリクスは、ホスト OS のコンテナでは収集されません。 CloudWatch のロググループコンソールでも、Fluent Bit エージェントがログの送信を開始したことを確認しましょう。以下のロググループに Windows EC2 インスタンスが表示されるはずです。 CloudWatch ロググループのコンソール サンプルアプリケーションをデプロイして、CloudWatch Container Insights ダッシュボードを確認します。 Container Insights が提供する様々なダッシュボードを理解するため、Windows アプリケーションのサンプルをデプロイしましょう。このアプリケーションは、基本的な Windows IIS サーバを実行します。 cat &lt;&lt; EOF &gt; windows-workloads.yaml --- apiVersion: apps/v1 kind: Deployment metadata: name: multiple-containers namespace: multiple-containers spec: selector: matchLabels: app: multiple-containers tier: backend track: stable replicas: 1 template: metadata: labels: app: multiple-containers tier: backend track: stable spec: containers: - name: multiple-containers-container-1 image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2022 command: - powershell.exe - -command - " ping -t google.com " - name: multiple-containers-container-2 image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2022 command: - powershell.exe - -command - " ping -t amazon.com " nodeSelector: kubernetes.io/os: windows --- apiVersion: apps/v1 kind: Deployment metadata: name: standard-2022-deployment spec: selector: matchLabels: app: standard-2022-deployment tier: backend track: stable replicas: 1 template: metadata: labels: app: standard-2022-deployment tier: backend track: stable spec: containers: - name: standard-2022-deployment image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2022 command: - powershell.exe - -command - " ping -t google.com " nodeSelector: kubernetes.io/os: windows --- apiVersion: apps/v1 kind: Deployment metadata: name: deployment-web-service namespace: web-service spec: selector: matchLabels: app: deployment-web-service tier: backend track: stable replicas: 1 template: metadata: labels: app: deployment-web-service tier: backend track: stable spec: containers: - name: deployment-web-service image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2022 command: - powershell.exe - -command - | Add-WindowsFeature Web-Server; Invoke-WebRequest -UseBasicParsing -Uri 'https://dotnetbinaries.blob.core.windows.net/servicemonitor/2.0.1.6/ServiceMonitor.exe' -OutFile 'C:\ServiceMonitor.exe'; echo '&lt;html&gt;&lt;body&gt;&lt;br/&gt;&lt;br/&gt;&lt;H1&gt;Windows Container Workshop - Windows LTSC2019!!!&lt;/H1&gt;&lt;/body&gt;&lt;/html&gt;' &gt; C:\inetpub\wwwroot\iisstart.htm; C:\ServiceMonitor.exe 'w3svc'; nodeSelector: kubernetes.io/os: windows --- apiVersion: v1 kind: Service metadata: name: standard-2022-service namespace: web-service spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: app: deployment-web-service tier: backend track: stable sessionAffinity: None type: LoadBalancer --- EOF kubectl apply -f windows-workloads.yaml 一度デプロイすると、AWS コンソールから、拡張された Container Insights ページが以下のように表示され、クラスター、kube-state、コントロールプレーンのメトリクスの概要が示されます。Container Insights ダッシュボードには、クラスターのステータスとアラームが表示されます。CPU とメモリの使用量が高いリソースを素早く特定するために、事前に設定されたしきい値を用いて、パフォーマンスへの影響を避けるための積極的な対応を可能にします。 Container Insights の Overview さらに、CPU やメモリ使用率などの重要なメトリクスについて、クラスター、ノード、ワークロード、ポッド、コンテナの上位 10 件を確認できます。コンテナレベルまでの情報を提供できることで、Site Reliability Engineer (SRE) がパフォーマンスの問題を特定する平均時間を短縮できます。 トップ 10 リスト クラスター名をクリックすると、パフォーマンスモニタリングダッシュボードが開き、パフォーマンスを分析するための各種ビューが表示されます。表示されるビューには以下のようなものがあります。 クラスター全体のリソース使用率の概要を示すクラスター全体のパフォーマンスダッシュボードビュー 個別のノードレベルのメトリクスを可視化するノード パフォーマンスビュー CPU、メモリ、ネットワークなどのポッド単位のメトリクスに焦点を当てたポッドパフォーマンスビュー 個々のコンテナの使用率メトリクスを詳細に確認できるコンテナのパフォーマンスビュー 例えば、クラスター全体のパフォーマンスダッシュボードから見て全体像をとらえることができます。さまざまなビューを切り替えることで、クラスターからノード、ポッド、コンテナへと徐々に絞り込み、根本原因を見つけることができます。 パフォーマンスダッシュボード マルチテナント環境では、ノイジーネイバー事象を回避するため、各アプリケーションのパフォーマンスを理解することが重要です。そのような場合、の概要ダッシュボードを使用すると、リソースを多く消費しているアプリケーションを簡単に特定し、予防措置をとることができます。以下のダッシュボードは、複数コンテナ名前空間における「名前空間の概要」が表示されており、リソース使用状況の全体像を提供しています。 Namespaceのパフォーマンスダッシュボード Amazon CloudWatch Container Insights のサービスダッシュボードでは、Kubernetes サービスの Pod のコンテナインスタンスの CPU、メモリ、ネットワークパフォーマンスのメトリクスが提供されます。これらのインサイトを活用することで、リソース使用量を最適化したり、コンテナ化されたサービスの問題をより的確に特定できるようになります。 パフォーマンスメトリクスダッシュボードでは、CPU、メモリ、ネットワーク使用率などの主要メトリクスを使用して、アプリケーションの健全性の概要を示します。このダッシュボードは CloudWatch メトリクスと CloudWatch ロググループと統合されているため、ダッシュボードのパネルの 3 つのドットをクリックし、「ログを表示」を選択するだけで、問題の原因を調査できます。Log Insights には事前に用意されたクエリがあり、ログデータを分析してインサイトを得ることができます。 サービスのパフォーマンスダッシュボード メトリクスビューを選択して、対応するメトリクスに移動し、アクションの列の下にある「アラームを作成する」を選択すると、指定したしきい値を超えた際に通知を送ることができます。このダッシュボードは、pod_cpu_utilization メトリクスを使用して、Amazon EKS サービス 「standard-2022-service」 のアラーム作成プロセスを示しています。 メトリクスコンソール アラームの作成 収集されたすべてのメトリクスは、ContainerInsights 名前空間の下で利用可能です。特定のメトリクスに対してアラームを作成したい場合は、この名前空間を使用してメトリクスにアクセスし、対応するアラームを作成できます。 CloudWatch 名前空間における Container Insights クリーンアップ リソースを削除するには、次のコマンドを実行してください。 eksctl delete cluster --name eks-windows-ci 結論 この記事では、Amazon EKS Windows クラスターの Container Insights を有効にするプロセスを紹介しました。数回クリックするだけで、コントロールプレーンとデータプレーンの両方の詳細なメトリクスを収集できます。すぐに使えるダッシュボードを使用して、Windowsワークロードのパフォーマンスの問題を特定するまでの時間と解決にかかる平均時間を短縮できます。Amazon EKSクラスター上で拡張された CloudWatch Container Insights を有効にして、Amazon EKSクラスター上で実行されている Windows ワークロードのトラブルシューティングを効率的に開始するには、 このリンク を使用してください。 著者について Vikram Venkataraman Vikram Venkataraman は、Amazon Web Servicesの Principal Specialist Solutions Architect です。顧客がコンテナ化されたワークロードのモダナイズ、スケーリング、ベストプラクティスの採用を支援しています。彼は Observability に情熱を傾けており、Amazon Managed Service for Prometheus、Amazon Managed Grafana、AWS Distro for Open Telemetry などのオープンソースの AWS Observability サービスに焦点を当てています。 Kulwant Singh Kulwant Singh は Amazon Web Services の Software Development Engineer で、コンテナや Kubernetes などのコンテナオーケストレーターと仕事をしています。 翻訳はテクニカルアカウントマネージャーの日平が担当しました。原文は こちら です。

高速でパーソナライズされた体験を提供するために、Web アプリケーションの構築とレンダリング方法は、長年にわたって大きく進化してきました。その過程で、Web アプリケーションを構築する開発者の役割も、この進化を反映して変化してきました。本記事では、フルスタックの Web 開発の進化過程と、急速に変化する Web アプリケーションエコシステムやユーザーのニーズに対し、開発者が AWS Amplify を使って適応する方法について説明します。 Server-Side Rendering の黎明期 1990 年代とインターネットの初期段階では、Web アプリケーションは主にサーバー側でレンダリングされるアプリケーションでした。これは、HTML ファイルがサーバーに格納され、ブラウザクライアントがダウンロードする静的コンテンツからはじまりました。動的なコンテンツを提供するために、開発者はサーバープログラミング言語 (ASP、Java、PHP、Ruby など) を使って HTML をレンダリングするようになりました。これによって、アプリケーションをユーザーごとに動的に変化させることができるようになりました。アプリケーションは、データベースからデータを取得し、エンドユーザー向けにカスタマイズした状態でそのデータを提供できるようになりました。アプリケーションのユーザー数が増加するにつれ、パフォーマンスが課題となりました。ユーザーは、すべてのインタラクションにおいてページ全体のリロードが必要となったため、ユーザー体験が低下しました。加えて、開発者はサーバーに関連する運用、セキュリティ、スケーラビリティなども管理する必要がありました。 Client-Side Rendering (CSR) と Single Page Application (SPA) の台頭 2000 年代には、 Asynchronous JavaScript and XML (AJAX) と呼ばれるクライアントサイドレンダリングの基礎となるアプローチが登場しました。これにより、ページのリロードなしでデータを非同期に取得できるようになりました。2010 年代中頃には、より高速でパーソナライズされた Web 体験の探求が続きました。それにより、React や Vue などの JavaScript ベースのフレームワークが登場しました。これらのフレームワークは、 Single Page Application (SPA) を構築する革新的なアプローチを導入しました。 従来のマルチページアプリケーションでは、ユーザーの操作ごとにサーバーが新しいページ全体を送信する必要がありましたが、SPA ではユーザーインターフェイスコンポーネントを最初にロードし、その後ユーザーがアプリケーションと対話するときに動的にコンテンツを表示します。これにより、ユーザーの操作がより効率的でシームレスになりました。 このアプローチは、アプリケーションをより効率的に管理する方法を示しました。ここでは、フロントエンドはバックエンドから切り離されています。さらに、エッジ・コンピューティングの進歩を活用し、 コンテンツ・デリバリー・ネットワーク (CDN) にデプロイすることで、インフラストラクチャを管理することなくスケーリングし、グローバルトラフィックへの対応を向上させることができます。 Server-Side Rendering (SSR) の再浮上 Client-Side Rendering はユーザ体験を向上させましたが、いくつかの課題が生じました。 まず、初期レンダリングでコンテンツを取得してからクライアントサイドでレンダリングするため、動的コンテンツの描画に時間がかかるようになりました。さらに、初期レンダリングが空の HTML になるため、コンテンツがなく検索エンジンに最適化されないことがあります。 その結果、機能強化されたサーバー側のアプローチが新しく登場しました。まず、Static Site Generations (SSG) です。ビルド時に静的コンテンツを生成します。静的ファイルは CDN から提供できるため、アプリケーションのグローバルトラフィック処理能力も向上します。次に、Server-Side Rendering (SSR) がアプリケーションで再び使われるようになり、ユーザーのリクエスト時にコンテンツを生成します。これにより、最新の状態に更新された個別のコンテンツを高速に提供できます。これらのアプローチは、 サーバーレスコンピューティング の登場により恩恵を受けています。サーバーレスコンピューティングを使えば、基盤となるインフラストラクチャを心配することなくコードを実行できます。 フルスタックフレームワークの台頭 Client-Side Renderingと Server-Side Rendering にはそれぞれ長所と短所があることをお話ししました。そのため、顧客にとって最高の体験を提供するにはどう構築すべきか判断するのは難しくなります。結果として、開発者はこれらのレンダリングアプローチの利点を活かせるフレームワークを多く利用するようになっています。今日では、 Next.js (React を使用するアプリケーション向け) や Nuxt (Vue.js を使用するアプリケーション向け) などのフルスタックフレームワークは、データフェッチ、レンダリング、キャッシングについてそれぞれの考えに基づいたアプローチを提供しています。これらは単一のコードベースで対応できるので、複数のスタックやデプロイが必要なケースの大変さが軽減されます。例えば、以下のようなものがあります。 Next.js API ルート は、 /api/ フォルダ内に関数を置くだけで、直感的に公開 API を作成できます。 Next.js App Router および React Server Component (RSC) では、 use client と use server という指示を使用して、コンポーネントをレンダリングする場所を指定できます。 イテレーションの速度と、変化するお客様のニーズに適応することが成功の鍵となります。 フルスタックフレームワークの台頭により、開発者はコードを書くことから優れた製品を作ることへと、継続的にフォーカスする点をを移していくことができます。 AWS Amplify : フルスタックの Web、モバイル、AI アプリを構築するために必要な全て フレームワークに加えて、開発者はニーズに応じた適切なクラウド インフラストラクチャにイテレーションとデプロイを簡単に行えるプラットフォームが必要です。 AWS Amplify は、AWS のクラウドバックエンドに接続するための使いやすいライブラリとホスティング プラットフォームを提供します。これには API、ストレージ、認証が含まれます。アプリケーションが成長すると、Amplify は AWS Cloud Development Kit (CDK) で定義されたインフラストラクチャでの拡張性を提供します。Amplify を使えば、開発者は深いクラウド専門知識なしにアプリケーションを数百万人のユーザーにスケールアップできます。Amplify は、Next.js や Nuxt などの一般的なフレームワークに対して ゼロコンフィグデプロイ をサポートし、Amazon S3、Amazon CloudFront、AWS Lambda 全体にわたるデプロイを処理します。 re:Invent 2023 で、AWS Amplify は Gen 2 の開発者体験のパブリックプレビューを発表しました。これは現在 一般提供 されています。開発者コミュニティからのフィードバックを受け入れた変更により、より迅速なイテレーションと自信を持ったリリースが可能になりました。これには、CLI ツールの面倒さを避ける コードファーストの開発者体験 と、 Amazon Q Developer のようなサービスからの AI アシスタンスが含まれています。 また、ローカルテストを通じて素早くイテレーションできるパーソナルクラウドサンドボックスや、フロントエンドとバックエンドの両方を 1 か所で管理できるファイルベースの規約などの機能も含まれています。 生成 AI 時代への進化 生成 AI の進化に伴い、開発者は高速なユーザー体験の実現という再び 新たな課題 に直面しています。まず、生成 AI の基盤モデルは応答に長い時間がかかる可能性があるため、非同期や streaming パターンを検討する必要があります。さらに、ユーザーの会話履歴のようなメモリを管理する必要が出てくる可能性があります。これらの課題はモダンなフレームワークやプラットフォームの重要性を示しています。 AWS Amplify の各機能を活用することで、お客様に魅力的なエクスペリエンスを提供するための機能を統合し、適応できるようになります。ここでは Amplify が&nbsp; AWS AppSync とデータベースや API への非同期のクエリを提供する、マネージド GraphQL サービスと、主要な基盤モデルへの API アクセスを提供する Amazon Bedrock を活用しています。詳しくは、この フルスタックアプリケーションのサンプル を参照してください。 まとめ 本記事では、Web でのアプリケーション開発の進化について学びました。まず Server-Side アプリケーション、 Client -Side アプリケーションの起源に立ち返り、その後の Server-Side アプローチの適応について掘り下げました。フルスタックフレームワークを使ってクラウドでアプリケーションを構築・スケーリングする方法、サーバーレス、エッジコンピューティング、そして生成 AI などの新しいテクノロジーを活用する方法を探りました。最終的にはこの進化により、高速で、個人に最適化された、AI 駆動のユーザー体験を構築できるようになります。 まずは、 AWS Amplify の新しいコードファーストの開発者体験 でフルスタックの Web アプリケーションを構築してみましょう。 本記事は、「 The evolution of full-stack development with AWS Amplify 」を翻訳したものです。 著者について Daniel Wirjo Daniel is a Solutions Architect at AWS, focused on FinTech and SaaS startups. As a former startup CTO, he enjoys collaborating with founders and engineering leaders to drive growth and innovation on AWS. Outside of work, Daniel enjoys taking walks with a coffee in hand, appreciating nature, and learning new ideas. Fred Hoskyns Fred Hoskyns is a Senior Enterprise Account Manager at AWS. Having worked in both commercial and technical roles at AWS, he partners with enterprises on their cloud and technology strategy. Beyond this, he is passionate about helping people move into technology roles, and providing developers with the latest tools to enhance their productivity. 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を中心に技術支援を行っています。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。