3月21日より、パッケージリポジトリの管理者は、新しい AWS CodeArtifact パッケージグループ設定機能を使用して、複数のパッケージの設定を 1 か所で管理できるようになりました。パッケージグループを使用すると、内部のデベロッパーによって、またはアップストリームリポジトリから、パッケージが更新される方法を定義できます。内部のデベロッパーによるパッケージの公開を許可またはブロックしたり、パッケージのグループについてのアップストリームの更新を許可またはブロックしたりできるようになりました。 CodeArtifact は、組織がアプリケーション開発に使用されるソフトウェアパッケージを安全に保存および共有することを容易にする、フルマネージドパッケージリポジトリサービスです。CodeArtifact は、 NuGet 、 Maven 、 Gradle 、 npm 、 yarn 、 pip 、 twine 、および Swift Package Manager などの人気のビルドツールやパッケージマネージャーで使用できます。 CodeArtifact は、 npmjs.com 、 maven.org 、 pypi.org などのパブリックリポジトリからのパッケージのオンデマンドインポートをサポートしています。これにより、組織のデベロッパーは、唯一の信頼できるソースである CodeArtifact リポジトリからすべてのパッケージを取得できるようになります。 シンプルなアプリケーションには通常、数十のパッケージが含まれています。大規模なエンタープライズアプリケーションには、何百もの依存関係が存在する場合があります。これらのパッケージは、ネットワークアクセス、暗号化機能、データ形式の操作などの一般的なプログラミングの課題を解決するコードを提供することで、デベロッパーが開発とテストのプロセスをスピードアップするのに役立ちます。これらのパッケージは、組織内の他のチームによって作成されたり、サードパーティーによって保守されたりする場合があります (例: オープンソースプロジェクト)。 サプライチェーン攻撃のリスクを最小限に抑えるために、一部の組織では、内部リポジトリで使用可能なパッケージと、これらのパッケージの更新を承認されたデベロッパーを手動で精査します。リポジトリ内のパッケージを更新するには 3 つの方法があります。組織内の選択されたデベロッパーがパッケージの更新をプッシュする場合があります。これは通常、組織の内部パッケージを使用する場合に当てはまります。パッケージはアップストリームリポジトリからインポートされる場合もあります。アップストリームリポジトリは、承認されたパッケージの全社的なソースや、人気のオープンソースパッケージを提供する外部パブリックリポジトリなど、別の CodeArtifact リポジトリである場合があります。 デベロッパーにパッケージを公開するさまざまな方法を示す図を以下に示します。 リポジトリを管理する場合、パッケージをダウンロードおよび更新する方法を定義することが重要です。例えば、外部のアップストリームリポジトリからのパッケージのインストールや更新を許可すると、組織は タイポスクワッティング 攻撃や 依存関係の混乱 攻撃にさらされます。有名なパッケージの悪意のあるバージョンを、わずかに異なる名前で公開しようとしている不正行為者を想像してみてください。悪意のあるパッケージは、 coffee-script ではなく、「f」が 1 つだけ含まれた cofee-script であるとします。 アップストリーム外部リポジトリからの取得を許可するようにリポジトリが設定されている場合、深夜まで働いている、集中力を欠いたデベロッパーが、 npm install coffee-script ではなく、 npm install cofee-script と入力してしまえばおしまいです。 CodeArtifact は、パッケージを更新する 3 つの可能な方法として 3 つの許可を定義します。管理者は、内部の publish コマンド、内部のアップストリームリポジトリ、または外部のアップストリームリポジトリからのインストールと更新を allow または block できます。 これまで、リポジトリ管理者はこれらの重要なセキュリティ設定をパッケージごとに管理する必要がありました。本日の更新により、リポジトリ管理者はパッケージのグループのために、これらの 3 つのセキュリティパラメータを一度に定義できるようになりました。パッケージは、そのタイプ、名前空間、および名前によって識別されます。この新しい機能は、リポジトリレベルではなくドメインレベルで動作します。これにより、管理者はドメイン内のすべてのリポジトリでパッケージグループのルールを適用できます。すべてのリポジトリで パッケージオリジンコントロール の設定を保守する必要はありません。 仕組みの詳細 私が CodeArtifact を利用して内部パッケージリポジトリを管理しており、私の組織によって精査済みの AWS SDK for Python ( boto3 とも呼ばれます) のバージョンのみを配布したいと考えているとします。 AWS マネジメントコンソール で CodeArtifact のページに移動し、精査済みのパッケージを内部のデベロッパーに提供する python-aws リポジトリを作成します。 これにより、作成したリポジトリに加えてステージングリポジトリが作成されます。 pypi からの外部パッケージは、まず pypi-store 内部リポジトリにステージングされます。ここで私は、 python-aws リポジトリに提供する前にこれらのパッケージを検証します。ここは、デベロッパーがこれらのパッケージをダウンロードするために接続する場所です。 デフォルトでは、デベロッパーが CodeArtifact に対して認証し、 pip install boto3 と入力すると、CodeArtifact はパブリック　 pypi リポジトリからパッケージをダウンロードし、それらを pypi-store にステージングして、 python-aws にコピーします。 ここで、CodeArtifact がアップストリームの外部 pypi リポジトリからパッケージの更新を取得するのをブロックしたいと考えているとします。 python-aws には、 pypi-store 内部リポジトリから私が承認したパッケージのみを提供してもらいたいと考えています。 本日リリースした新機能により、この設定をパッケージのグループに適用できるようになりました。自分のドメインに移動し、 [パッケージグループ] タブを選択します。その後、 [パッケージグループを作成] ボタンを選択します。 [パッケージグループの定義] を入力します。この式は、このグループにどのパッケージが含まれるのかを定義します。パッケージは、パッケージ形式、オプションの名前空間、名前という 3 つのコンポーネントの組み合わせを使用して識別されます。 許可された各組み合わせで使用できるパターンの例をいくつか次に示します: すべてのパッケージ形式: /* 特定のパッケージ形式: /npm/* パッケージ形式と名前空間のプレフィックス: /maven/com.amazon~ パッケージ形式と名前空間: /npm/aws-amplify/* パッケージ形式、名前空間、名前のプレフィックス: /npm/aws-amplify/ui~ パッケージの形式、名前空間、名前: /maven/org.apache.logging.log4j/log4j-core$ あらゆる可能性を知るために、 ドキュメント をぜひお読みください。 この例では、Python パッケージには名前空間の概念がありません。また、グループには pypi からの boto3 で始まる名前を持つすべてのパッケージが含まれるようにしたいと考えています。そのため、 /pypi//boto3~ と記述します。 その後、パッケージグループのセキュリティパラメータを定義します。この例では、組織のデベロッパーが更新を公開することを望んでいません。また、CodeArtifact が外部アップストリームリポジトリから新しいバージョンを取得することも望んでいません。内部ステージングディレクトリからのパッケージ更新のみを承認したいと考えています。 [親グループから継承] のすべてのチェックボックスをオフにします。 [公開] と [外部アップストリーム] で [ブロック] を選択します。 [内部アップストリーム] の [許可] をそのままにします。その後、 [パッケージグループを作成] を選択します。 一度定義すると、デベロッパーは、 python-aws リポジトリで承認されているものとは異なるパッケージバージョンをインストールできなくなります。デベロッパーとして別のバージョンの boto3 パッケージをインストールしようとすると、エラーメッセージが表示されます。これは、 boto3 パッケージの新しいバージョンがアップストリームステージングリポジトリでは使用できず、外部アップストリームリポジトリからパッケージやパッケージの更新を取得できないようにする block ルールがあるためであり、想定内のことです。 同様に、管理者が依存関係置換攻撃から組織を保護したいと考えているとします。すべての内部 Python パッケージの名前は会社名 ( mycompany ) で始まります。管理者は、 mycompany で始まる pypi.org パッケージからデベロッパーが誤ってダウンロードするのをブロックしたいと考えています。 管理者は、 /pypi//mycompany~ のパターンで、 publish=allow 、 external upstream=block 、 internal upstream=block を使用してルールを作成します。この設定では、内部のデベロッパーまたは CI/CD パイプラインはこれらのパッケージを公開できますが、CodeArtifact は、 mycompany.foo や mycompany.bar など、 mycompany で始まるパッケージを pypi.org からインポートしません。これにより、これらのパッケージに対する依存関係置換攻撃が防止されます。 パッケージグループは、 CodeArtifact が利用可能なすべての AWS リージョン で追加料金なしでご利用いただけます。これは、パッケージとパッケージの更新を内部リポジトリに配置する方法をより適切に制御するのに役立ちます。また、 タイポスクワッティング や 依存関係の混乱 など、さまざまなサプライチェーン攻撃を防ぐのにも役立ちます。これは、CodeArtifact リポジトリを作成および管理するために、Infrastructure as Code (IaC) ツールに今すぐ追加できる追加設定の 1 つです。 今すぐ最初のパッケージグループを設定しましょう 。 — seb 原文は こちら です。

本記事は、「 Event Recap: AWS news from Mobile World Congress 2024 」（2024年3月6日公開）を翻訳したものです。 Mobile World Congress (MWC) 2024 は、10 万人以上の出席者、2,700 社以上の出展者、スポンサー、パートナー、そして1,100 人のスピーカーとリーダーが参加しました。AI、収益化のオポチュニティ、およびクラウドが通信業界にもたらす変革などのトピックが深く議論されました。 「このイベントは、将来を展望し、AI、5G、API が新しい可能性をを示します。 GSMA Open Gateway のような共同イニシアチブを感謝します。」と GSMA のジェネラルディレクターである Mats Granryd は述べました。 AWS は、生成 AI、Network API、5G、Network Transformation などのトピックで、多数のお客様とパートナーのアナウンスメントを発表しました。20 以上の AWS デモを通じて、通信領域の変革、産業のデジタル化、消費者体験の改善におけるる AWS のイノベーションを見ることができました。AWS Recap ビデオをご覧ください。 MWC 2024 での AWS のハイライトをお届けします。 生成 AI は everywhere 通信事業者は、コストと効率の合理化、より良いユーザーエンゲージメント、革新的な新サービスを推進するために、人工知能（AI）、機械学習（ML）、生成 AI を期待しています。エンタープライズグレードのセキュリティとプライバシー、他種類の基盤モデル（LLM）の選択権、データファーストのアプローチ、パフォーマンスが高くコストが低いインフラストラクチャ、これら生成 AI によるイノベーションを加速するための要素を AWS が提供し、通信事業者から信頼を得られています。 MWC 2024 では、AI に焦点を当てたセッションが 40 以上あります。生成 AI は私たちが生きる、働く、そしてコミュニケーションする方法を変えようとしています。 BT グループ は、 Amazon Q のコーディングコンパニオン（ Amazon CodeWhisperer ）を活用し、ソフトウェアエンジニアに生成 AI コーディングアシスタンスを提供したと発表しました。このソリューションは既に、BT グループのアクティブユーザーごとに 1日あたり 15-20 のコード提案を提供しており、プラットフォームを使用するソフトウェアエンジニアによる受入率は 37% です。これは、生成 AI が提供できる価値、効率、およびサポートの素晴らしい例です。 Tele2 は、Internet of Things（IoT）ユーザーサポートソリューションに Amazon Bedrock を活用していると発表しました。このソリューションは AWS サービスを活用し、Tele2 IoT のユーザーサポートエージェントが複数のチャネルにわたる IoT ユーザーの問い合わせに対して、より迅速で詳細な回答に役立ちます。 Network API への関心は史上最高 Application Programming Interfaces（API）を受け入れることは、通信事業者が将来に備えた組織への変革の中心です。McKinsey は、Network API の市場が今後 5〜7 年間で、通信とエッジコンピューティングに関連して、通信事業者に約 100〜300 億ドルの収益をもたらす可能性があると推定しています。さらに API 自体から追加で 10〜30 億ドルの収益が生み出される可能性があります。 GSMA Open Gateway イニシアチブは、AWS を含む 21 のモバイルネットワークオペレーターとクラウドプロバイダーの支援を受けて、MWC 2023 で発表されました。それ以来、Open Gateway は 47 のオペレーターに拡大し、APIがネットワークのユニークな特性を公開することを利用して、革新的なユースケースやアプリケーションを構築したい開発者を引き付けています。 MWC 2024 に向けて、AWS は Verizon、Telefónica、T-Mobile、Orange、Liberty Global を含む世界中の通信事業者と協力して、 AWS 開発者に対し通信事業者のネットワーク API を提供する と発表しました。AWS 開発者は既に 240 以上の AWS サービスの数千の AWS API を使用していますが、ネットワーク API を活用しながら、 AWS Marketplace を通じてより多くの開発者やユーザーにお届けできます。多くのアプリケーションがAWS 上でテレコ API を活用して金融サービス、ゲーム、没入型体験を提供しています。採用が進むにつれて、世界中でより多くのオペレーターと協業していく予定です。 5G Future Forum（5GFF） のメンバーである Telstra、Verizon、Vodafone、Rogers、America Movil、KT、および Bell Canada は、AWS との協力のもと、エッジコンピューティング（MEC）インフラストラクチャ統合およびアプリケーションを促進するために、通信事業者とクラウドプロバイダー間の双方向 API の役割を定義するホワイトペーパーを発表しました。 Vonage は、新しいソリューションの提供を加速するために AWS とのコラボレーションを発表しました。詐欺対策ソリューションを最初のソリューションとして提供します。AWS の生成 AI サービスは、ソリューションの詐欺検出能力を強化し、モバイル詐欺から自身をより効果的に保護しつつユーザー体験を改善することを可能にします。 通信業界におけるネットワーク変革 世界中の通信事業者は、クラウドの経済性、拡張性、および俊敏性を活用してネットワークを変革し、より重要なことにフォーカスすることができます。これには、通信事業者のコアネットワークの変革、投資の収益化、産業のデジタル化、消費者体験の改善、レジリエンスとセキュリティの向上が含まれます。 8,900 万人以上の加入者を持つ日本の主要なモバイルオペレーターである NTT DOCOMO は、日本全国で 5G オープン無線アクセスネットワーク（RAN）の商業展開に AWS を選びました。DOCOMO は、コンテナ管理ソフトウェアである Amazon Elastic Kubernetes Service Anywhere を 5G オープン RAN に展開し、自動化されたクラスタ管理ツールを使用することによってネットワークオペレーションを簡素化します。そして、AWSは、NTT DOCOMO のハイブリッドクラウド環境での 5G コアの開発を支援しています。 TELUS は、Samsung Electronics および AWS との新しいコラボレーションを発表しました。北米でローミングのアーキテクチャを進化させる最初の通信事業者になることを目指して、海外旅行のユーザーにより高い信頼性と高速のローミングサービスを提供します。一方、欧州では、スイスの通信事業者である Sunrise Business が、スイスの中小企業のクラウド化を加速するために AWS と協力していると発表しました。 ラテンアメリカでは、 Beyond ONE / Virgin Mobile が、地域の通信セクターにおける成長とイノベーションを推進するために AWS と協力していると発表しました。Virgin Mobile は、 AWS Regions と AWS Outposts および AWS Local Zones を含む AWS ハイブリッドクラウド技術の組み合わせを使用して、Beyond One スタックをモダナイズし、地域におけるクラウド採用とデジタル変革における重要な一歩を記します。 以下で他の発表についてもご覧ください。 Women in Tech AWSはテクノロジー分野における多様性を推進し、女性のテクノロジー分野でのキャリアを支援しています。 GSMA によると、MWC 2024 は 26% の女性参加者が参加し、1,100 人のスピーカーのうち 40% が女性でした。今年、AWS はテレコム業界における女性が直面する機会と課題についてのパネルディスカッションを主催し、AWS エグゼクティブレセプション中にテレコムエコシステム全体にわたる多様性へのコミットメントを強化しました。 デモ 今回の MWC 2024 では、AWS は 3つの主要なテーマを通じて、20 以上のデモを展示しました。 1/ 通信事業の変革 このエリアのデモは、CSP のネットワーククラウド化（RAN、Core、IMS、OSS/BSS など）のジャーニーにフォーカスします。統合的な自動化、オーケストレーション、および生成型 AI ツールチェーンの活用により、新たな成長機会の創出、OPEXの削減、持続可能性の向上、およびレジリエンスの強化を実現しています。reCap のビデオをご覧ください： 例として、Samsung Cloud RAN は、Amazon Bedrock および Anthropic Claude v2 とともに Amazon Bedrock Agents を使用して、AIを用いた RAN 設定チューニングを実現し、最大 25% のパフォーマンス向上を達成できました。 2/ 産業のデジタル化 このエリアのデモでは、AWS がいかに通信事業者を支援し、医療、製造、旅行およびホスピタリティ、金融サービスなどの産業をデジタル化しているのかを示しています。これは、プライベートネットワークソリューション、Network API、パブリック MEC などの通信サービスの革新、ビジネスモデルの革新を通じて実現しています。reCap のビデオをご覧ください： AWS、Accenture、および Verizon は協力し、製造業で 5G の価値を示すために、オンプレミス 5G およびプライベートモバイルエッジコンピューティング（MEC）を展開しました。AWS は Jabil の製造施設で、組み立てラインの異なる場所でのライブストリームカメラの映像を、 AWS Snowball Edge に転送し、コンピュータビジョンのモデルで処理される新しいソリューションを展開しました。このソリューションは、組み立てラインの不良ユニットの誤検出率を 95% 削減しました。 3/ 消費者体験の改善 このエリアのデモは、AWS が通信事業者および ISV と共同開発しているいくつかの革新的なソリューションを紹介しています。これらのソリューションは面白く、スマートで、パーソナライズされた消費者体験につながります。 私たちの SmartHome+ デモでは、TELUS との協力により、AWS 生成 AI、 AWS IoT Core 、および Alexa Voice Services を活用しています。このデモは、TELUS が消費者とのインタラクションを変革し、高度な接続性とAIの時代においてスマートソリューションを拡大していることを示しています。 MWC 2024 に参加しましたか？ AWS for Telecom をフォローしていただければ、今年のイベントのハイライトや、最新のニュースをチェックすることができます。 Mobile World Congress 2025 でお待ちしております！ MWC 2024 における AWS の発表 概要 AWSは、AI-RAN Alliance への参加を発表しました。 AI-RAN Alliance はモバイル通信技術にAIを統合し、無線アクセスネットワーク（RAN）技術とモバイルネットワークを進化させることを目的とした新しい協業イニシアチブになります。 Canonical は、AWS との協業を拡大し、Amazon EKS Anywhere のユーザーが オープン RAN の商用展開で使用するリアルタイム Ubuntu をサポートすることを発表しました。 Unmanned Life は、Liberty Global および AWS とのデジタルトランスフォーメーションにおける GSMA Foundry Excellence Award を受賞しました。受賞したユースケースは、アントワープ港での U-Security の展開であり、Liberty Global の Telenet を通じたドローン接続のためのスライスされた 5G ネットワークと、AWS Snowball Edge デバイスを介したエッジでの AI コンピュータビジョン分析を活用しています。 生成 AI Amdocs は AWS と協業して新しいソリューションを開発しました。Amazon Bedrock でホストされる Anthropic の Claude モデルは、ネットワークデータと Amdocs のアルゴリズムによって生成された洞察にアクセスし、情報の抽出、要約、データのリアルタイム集約などのタスクを実行します。 BT グループ は、Amazon Q のコーディングコンパニオン（CodeWhisperer）を展開し、ソフトウェアエンジニアに生成 AI コーディング支援を提供したと発表しました。このソリューションは既に、BT グループのアクティブユーザーごとに 1日あたり 15-20 のコード提案を提供しており、プラットフォームを使用するソフトウェアエンジニアによる受入率は 37% になります。最初の4ヶ月間で Amazon Q によって生成されたコードは 100,000 行を超えており、退屈で繰り返しの多い時間のかかる作業の約 12% を自動化しています。BTグループは現在、ビジネス全体で 1,200 人のエンジニアにこのソリューションを広げています。 CelcomDigi は、AWS とのコラボレーションを発表しました。Amazon Bedrock を利用し、従業員が生成 AI ソリューションの実験、革新、実装するための AI サンドボックスを設立します。これには、人事、カスタマーサービス、法務、財務など、CelcomDigi の運用プラットフォームに統合される可能性のあるユースケースが含まれます。 Maxis は、マレーシアのエンタープライズ顧客向けの生成 AI および 5G ユースケースの分野で、イノベーションを加速するための新しい AWS とのコラボレーションを発表しました。Maxis はこれにより、AWS の先進的な機械学習機能を活用し、AI モデルを大規模に構築、トレーニング、およびデプロイして、人工知能の可能性を繰り広げていきます。 MYCOM OSI は、Amazon Bedrockを使用して構築された新しい生成 AI ベースのエキスパートアプリケーションコンセプト、Experience Assurance and Analytics (EAA) GenAie を発表しました。これは、CSP のフロントラインの運用チームとビジネスチームが複雑なネットワークおよびサービスの問題を支援します。データを民主化し、運用コストを削減し、顧客体験を改善することを可能にします。 Snowflake は、AWS と協力して通信分野を変革し、技術的な業務クエリの解決を数日から数分に短縮していることを発表しました。AWS は Snowflake と協力して GenTwin を構築しました。これは、プライベート5G、Amazon Bedrock を活用した生成 AI、および AWS IoT TwinMaker を活用したデジタルツインの組み合わせで、革新的なネットワークオペレーションソリューションです。業界に前例のない効率化、自動化、および適応性を提供し、ネットワーク運用に変革的な時代の幕開けを告げています。 Tele2 は、Amazon Bedrock を活用した IoT ユーザーサポートソリューションを立ち上げると発表しました。このソリューションは AWS サービス活用し、2023 年末の Tele2 IoT Talks でユーザーに披露されました。これにより、Tele2 IoT のユーザーサポートエージェントは、複数のチャネルにわたる IoT ユーザーの問い合わせに対して、より迅速で詳細な回答を提供できるようになります。 ネットワーク変革 AWS は、Verizon、Telefónica、T-Mobile、Orange、Liberty Global などの通信事業者と共に、 AWS の開発者に対し通信事業者の Network API を提供する と発表しました。AWS 開発者は既に 240 以上の AWS サービスの数千の AWS API を使用しており、これにより開発者は通信事業者の API にもアクセスし、AWS Marketplace を通じてより多くの開発者やユーザーにサービスをお届けします。 Beyond ONE/Virgin Mobile は、地域の通信分野における成長とイノベーションを推進するために AWS との協業を発表しました。Virgin Mobile は、AWS Regions と AWS Outposts および AWS Local Zones を含む AWS のハイブリッドクラウドソリューションの組み合わせを使用して、Beyond One スタックをモダナイズし、地域におけるクラウド採用とデジタル変革における重要な一歩を記します。 BICS は、AWS と協力して新しいクラウドベースのローミングサービスを立ち上げ、国内外で旅行している際に、より速く、より信頼性の高いインターネットアクセスを提供し、モバイルローミング体験を向上させます。BICS は、そのローミング接続プラットフォームを AWS のグローバルインフラストラクチャに移行することにより、従来の国際モバイルローミングサービスよりも最大 5倍 速くローミングインターネット接続を提供することができます。 Casa Systems は、無線と有線の融合（wireless wireline convergence: WWC）における画期的な取り組みを発表しました。Casa の仮想 5G コアの制御プレーン機能を AWS Region に展開し、Casa の仮想化アクセスゲートウェイ機能（AGF）と 5G コアのユーザープレーン機能をプライベートクラウドで展開しました。この取り組みは、通信におけるクラウドネイティブネットワークソリューションの成長を示しています。 Clear Mobitel と NEC Corporation は、AWS 上に構築された NEC の最先端の 5G スタンドアローン（SA）クラウドネイティブコアネットワークソリューションの英国での展開に成功したと発表しました。 Finetwork は、エンドユーザーに対してファイバー、TV、モバイルサービスを含むトリプルプレイオプションをより柔軟で費用効果の高い方法で提供できるようにするために、Amdocs を選び、コアビジネスシステムを変革します。AWS 活用した Amdocs AI ベースの Digital Brands Suite as a Service は、Finetwork のオファリングを強化し、エンドユーザーによりシンプルなデジタルカスタマーエクスペリエンスを提供することを可能にします。 8,900 万人以上の加入者を持つ日本の主要なモバイルオペレーターである NTT DOCOMO は、日本全国で 5G オープン無線アクセスネットワーク（RAN）の商用展開に AWS を選びました。DOCOMO は、コンテナ管理ソフトウェアである Amazon Elastic Kubernetes Service Anywhere を 5G オープン RAN に展開し、自動化されたクラスタ管理ツールを使用することによってネットワークオペレーションを簡素化します。そして、AWSは、NTT DOCOMO のハイブリッドクラウド環境での 5G コアの開発を支援しています。 NTT DOCOMO は、NEC、AWS、および Red Hat、Qualcomm、Hewlett Packard Enterprise、Dell Technologies の組み合わせによるさらなるオプションを追加したと発表しました。 NTT DOCOMO & OREX は、AWS が OREX パートナーグループに参加したと発表しました。コンテナ管理ソフトウェア、オートメーションフレームワーク、およびオープン RAN ライフサイクル管理を含むエンドツーエンドの オープン RAN クラウドプラットフォームソリューションを提供します。 Omantel は、オマーンのためのソブリンクラウドを作成するために AWS との協力を発表しました。この戦略的関係の目標は、特にオマーンの政府機関や規制産業におけるデータ所在地とセキュリティ要件に対処することです。Omantel は、AWS と協力してクラウドセンターオブエクセレンス（CCoE）を立ち上げ、オマーンの組織がクラウドへの移行を成功させるためのトレーニング、エネーブルメント、およびサポートを提供します。さらに、AWS は Omantel がデジタル変革を追求する際の優先クラウドプロバイダーとなります。 Qvantel は、Etisalat Misr by e& と契約し、AWS Outposts 上で実行される Qvantel Flex BSS ソリューションを実装して、Etisalat BSS のデジタル変革を支援します。 Red Hat は、通信サービスプロバイダーがハイブリッドクラウドで 5G の採用と展開を加速し、管理を容易にするためのコラボレーションを発表しました。Tech Mahindra の Multi-mode Companion Cloud with Red Hat OpenShift は、AWS 上で実行され、RAN、エッジコンピューティング、トランスポート、5Gコアにまたがる複数のハイブリッドクラウドでのネットワークユースケースをサポートします。 Samsung は、AWS との画期的なコラボレーションを通じて 5G イノベーションを牽引します。仮想化ネットワークの未来を垣間見せ、次世代サービスと機能のさまざまな要求を満たすための革新的な道と改善された能力を提供しています。 Sateliot は、Kongsberg Satellite Services (KSAT) 商用ネットワークである KSATlite を介して、5G サービスメッセージング接続を達成したと発表しました。AWS を使用して、Sateliot は完全に仮想化されたクラウドネイティブの 5G コアを Narrowband (NB)-IoT Non-Terrestrial Networks (NTN) 用に構築し、Sateliot のエンドツーエンドサービスをサポートする柔軟で低コストで超スケーラブルなナローバンドソリューションを提供します。 スイスの通信事業者の Sunrise Business は、スイスの中小企業のクラウド化を加速するために AWS との協業を発表しました。Sunrise Business のユーザーは事前定義済みのモジュール化の製品パッケージからベネフィットを得られます。この製品パッケージは、中小企業の要件に合わせてクラウドと通信機能を提供します。この新サービスは、Amazon Simple Storage Service (Amazon S3)、Amazon Elastic Compute Cloud (Amazon EC2)、および AWS Storage Gateway などの AWS サービスをベースに構築されています。 Telstra は、AWS および Nokia との世界初のコラボレーションで、Nokia の IP マルチメディアサブシステム（IMS）のハイブリッドネットワークアーキテクチャの耐久性検証を発表しました。この IMS 検証では、特にネットワークの信頼性、耐久性、およびユーザー体験の向上を目指した AWS との長期的な戦略関係に基づいています。 TELUS は、Samsung Electronics および AWS との新しいコラボレーションを発表し、北米で初めてローミングのアーキテクチャを進化させます。海外旅行中のユーザーにより高い信頼性と高速なネットワークを提供する通信事業者になることを目指します。TELUS は、仮想化されたローミングゲートウェイを使用し、世界中の AWS リージョン内に自社のネットワークを収容することができます。これにより、トラフィックはカナダを経由する必要はなく、TELUS のネットワークを収容している最も近い AWS リージョンに直接ルーティングされ、モバイルサービスの速度と応答性が大幅に向上します。 Verizon Business と Audi AG は新しいパートナーシップを発表しました。ドイツのノイシュタットにある Audi 自動車の試験トラックで最先端のプライベートワイヤレスネットワークと技術テスト環境を構築します。Audi の試験トラックは、5G および LTE のデュアルモジュラープライベートワイヤレスプラットフォーム（Nokia）、プライベートマルチアクセスエッジコンピュート（MEC）機能（AWS）、リアルタイムビデオおよびデータ伝送技術（Smart Mobile Labs）、C-V2X 通信、および音声、データ、自動運転、安全性などをカバーするモバイル/自動車アプリケーションで実装されます。 Vodafone Ireland は、AWS 上の Celfocus BSP の成功展開を発表しました。プロジェクトの主な目的は、AWS が選ばれたクラウドプロバイダーとして、クラウドへの移行における可用性、耐久性、スケーラビリティの要件を確保し、将来の BSP ロードマップへの展開の入り口になります。 Vonage は、AWS とのコラボレーションを発表し、新しいソリューションの提供を加速します。最初のソリューションは、詐欺対策ソリューションであり、AWS の生成 AI サービスを活用することにより、詐欺検出機能を強化します。ユーザーがモバイル詐欺から自身をよりよく保護しつつユーザー体験を改善することを可能にします。 ネットワーク収益化 2degrees は、MVNO およびデジタルブランド市場への卸売ビジネスをモダナイズ化するために Totogi を選択しました。これは、ユーザー、コミュニティ、および環境への 2degrees の継続的なコミットメントの一環であり、MVNO ブランドを繁栄させるための software-defined offering になります。Totogi が選ばれた理由として、Totogi の Charging-as-a-Service（CaaS）は、AWS の AI サービスの Amazon Bedrock および機械学習（ML）サービスの Amazon SageMaker を使用して構築され、迅速なオンボーディングとMVNO ユーザーに対する効率的なサービスを提供できます。 5G Future Forum（5GFF） のメンバーである Telstra、Verizon、Vodafone、Rogers、America Movil、KT、および Bell Canada は、AWS との協力のもと、エッジコンピューティング（MEC）インフラストラクチャ統合およびアプリケーションを促進するために、通信事業者とクラウドプロバイダー間の双方向 API の役割を定義するホワイトペーパーを発表しました。 DigitalRoute、Intraway Symphonica、および Totogi は、Trektel のもとに 、AWS と協力してモバイル仮想ネットワークオペレーター（MVNO）in-a-box ソリューションを導入しています。業界の go-to-market の能力強化が狙いとなります。 Ericsson は、Wipro と協力し、AWS 上で ODIDO の Billing インフラストラクチャのモダナイズ化と発表しました。ODIDO のモバイル仮想ネットワークオファリング（MVNO）である Ben の全加入者が、AWS上でホストされる Ericsson Billing への移行に成功しました。 Intel は、AWS との継続的な連携により、ユーザーがバーティカルマーケットにおけるプライベートネットワークの加速を支援すると発表しました。最新の事例として、Integrated Private Wireless（IPW）on AWS プログラムのシステムインテグレーターとして Amdocs が追加されました。このプログラムを通じて、AWS のユーザーは、エンドツーエンドの Amdocs Mobile Private Network（MPN）サービスにアクセスし、Intel® Xeon® プロセッサが入る AWS Outposts サーバー上に構築されたインフラストラクチャを利用することが可能になります。 Liberty Global は、AWSとの協力で、Network-as-a-Service（NaaS）フレームワークを作成すると発表しました。開発者がイノベーションのために、NaaS を通じて、Liberty Global の固定およびモバイルネットワークにアクセスできます。Liberty Global の通信ネットワークと AWS のグローバルクラウドインフラストラクチャおよび既存の開発者エコシステムの組み合わせを活用して、NaaS ならではの魅力的なユースケースを開発することを目指しています。 著者について Chivas Nambiar Chivas Nambiar は、アマゾン ウェブ サービス (AWS) の Global Telecom Business Unit のゼネラルマネージャーです。 彼は、通信事業者、ネットワーク機器プロバイダー、ISV がクラウドに移行してビジネス変革を支援する世界規模のチームを率いています。 彼のチームは、クラウドの積極的な導入を推進し、コスト削減を実現し、ビジネスの俊敏性を高め、イノベーションを加速し、世界中のさまざまな通信ドメインにわたって新しいビジネスチャンスを創出してきました。 Chivas は熟練なエンジニアでありながら、チームを構築し、顧客やパートナーと協力してイノベーションを加速することに情熱を注いでおり、電気通信業界の変革に専念しています。 2020 年に AWS に入社する前は、Verizon Communications 社で通信業界に 17 年間勤務しました。彼の最後の役職では、クラウドおよびプラットフォーム エンジニアリングの担当エグゼクティブ ディレクターとして、Verizon の広範な IT およびネットワーク システム ポートフォリオから 1,000 を超えるビジネス クリティカルなアプリケーションをパブリック クラウドに移行する取り組みを主導しました。 以前の職務では、Chivas はグローバルな 24 時間年中無休の運用チームと、Voice Over IP (VoIP) および Wi-Fi 製品の開発と実装に取り組むエンジニアリング チームを運営していました。 Chivas は仕事がないときは、水が大好きな子どもについていくために水泳を習い、大家族の集まりのためにグリルを楽しんでいます。 翻訳はソリューションアーキテクトの陳誠が担当しました。

みなさん、こんにちは！製造業のお客様を中心に技術支援を行っているソリューションアーキテクトの山田です。 このブログでは、昨年末のAWS re:Invent 2023 で発表された新機能・Knowledge Bases for Amazon Bedrock を活用して、設計開発や研究における特許検索を効率化する方法について解説します。 はじめに　過去の関連ブログ 前々回、 こちらのブログ で、AWS の生成系 AI サービス・ Amazon Bedrock の Claude v2 ( by Anthropic 社) モデルを指定して、 Playgrounds のチャット機能を手軽に使用し、設計開発ドキュメントを効率的に作成する方法について解説しました。 前回、 こちらのブログ で、Amazon Bedrock の Stable Diffusion XL v0.8 ( by Stability AI 社) モデルを指定して、 Playgrounds の画像生成機能を手軽に使用し、新規プロダクト開発において意匠を文章から作るような、企画構想を充実させる方法について解説しました。 Knowledge Bases for Amazon Bedrock について Knowledge Bases for Amazon Bedrock を使用すると、 Amazon Bedrock 内から 基盤モデル をデータソースに接続して 検索拡張生成 (RAG) を行うことができます。 RAG は、プライベートデータの使用と基盤モデルを組み合わせた技術です。仕組みを理解するために、 Amazon Bedrock のチャット機能 と比較します。まずチャット機能のイメージ図です。 次に、Knowledge bases for Amazon Bedrock （RAG）のイメージ図です。 上のレーンの流れを説明します。①データソースから②ドキュメントを管理しやすいチャンク（通常2〜8語程度からなる意味を形成する塊）に分割し、③ Embedding （埋め込み：テキストを言語モデルが処理しやすい数値ベクトル表現に変換する）を生成し、④埋め込みを ベクトルDB に格納します。 下のレーンでは、水色の箇所が通常のチャット機能と共通する部分になりますが、⑤ユーザーの問い合わせに対して上のレーンと同様に Embedding を生成し、⑥ベクトル DB と照らし合わせて似たドキュメントを検索した上で、検索結果を加味して Text モデルが回答生成し、ユーザーに回答します。 これによって、例えばデータソースを社内ストレージに指定することで世に出ていない自社固有の回答をセキュアに生成したり、または外部の信頼できる知識ベースから事実を検索して、最新の正確な情報に基づいて回答を生成することが可能になります。 Knowledge Bases for Amazon Bedrock を使用することで、RAGの機能がコード不要で、Amazon Bedrock のマネージドな機能で簡単に実現でき、エージェントの構築時間を短縮できます。また、ナレッジベースを追加することで、プライベートデータを活用できるようにモデルを継続的にトレーニングしたりする必要がなくなるため、費用対効果も向上します。 なお、本ブログの内容は2024年3月21日時点の内容に基づいて執筆しています。執筆段階では東京リージョンにおいては Knowledge Bases for Amazon Bedrock は利用できません。 現時点で Knowledge Bases for Amazon Bedrock が利用できる北米のバージニア北部リージョンで試行を行います。また、 Amazon Bedrock は日々進化しており、執筆段階ではできなかったことも、ブログを読んでいただいた時点ではできるようになっている場合もありますのでご注意ください。 取り組む内容 今回のテーマは設計開発における特許検索です。特許を検索する際の主な課題は以下のようなものがあります。 特許の内容は一見難解であることが多いため、解釈が難しい 新規発明案に対して、既に類似の特許が出願されているかを調べるのが困難 こういった課題に対して、Knowledge Bases for Amazon Bedrock を活用して、特許データが保管されているデータソースを対象として RAG を実行することで解決を試みましょう。 Knowledge Bases for Amazon Bedrock のデータソースは現状、 Amazon S3 が指定できるようになっています。Amazon S3 に検索対象のデータを保管しますが、例えばもし世の中に存在する全ての特許ファイルを保管してしまうと、データ保存コストやベクトル DB を作成するコストが大幅に上がってしまうため、例えば関連する大きなテーマで絞り込むなどして、RAG を行う目的に応じて適切な特許ファイルを保管するようにしましょう。 Knowledge Bases for Amazon Bedrock の使用にあたって発生する料金については以下関連サービスの料金ページをご参照ください。 Amazon Bedrock Amazon S3 Amazon OpenSearch Serverless 今回はサンプル題材として、筆者が過去に発明した以下の特許3件を対象に、Bedrock で実現した RAG の仕組みに取り込みます。PDF ファイルをダウンロードして Amazon S3 に保存 します。 JP2013174393A JP2013174394A JP2014194291A 実行方法 まずマネジメントコンソール上部の検索バーで、「bedrock」などと打ち込んでいただくと、 Amazon Bedrock が候補に表示されます。クリックしてサービス画面に移行してください。 サービス画面に移行すると、画面左に オーケストレーション という項目が表示されます（※初回アクセス時はペーンが表示されておらず「Get started」ボタンを押す必要がある場合があります）ので、配下にある ナレッジベース 機能にアクセスしてみましょう。これが Knowledge Bases for Amazon Bedrock になります。 ここからページ下部にあるオレンジ色の「ナレッジベースを作成」をクリックします。 まずナレッジベース名を入力します。識別しやすい名前をつけてください。 画面下部にある IAM 許可については、「新しいサービスロールを作成して使用」を選択します。サービスロール名は自動的に付与されたもので構いません。 「次へ」を押すと、データソース設定ステップに進みます。 ここではデータソース名を入力します。ナレッジベース名のときと同様、識別しやすい名前をつけてください。 また、RAG のデータソースとなる S3 の URI を指定します。今回のサンプル題材である特許 PDF 3ファイルが保存された S3 バケットのURIを指定します。PDF ファイルを S3 バケットに保存する方法はこちらをご参照 ください。なお、Knowledge Bases for Amazon Bedrock は 次のファイル形式 をサポートしています。 「次へ」を押すと、埋め込みモデルの選択画面に進みます。埋め込みモデルは、RAG のイメージ図のところで説明した Embedding モデルに相当します。ここでは、Amazon が提供する Titan Embeddings G1 – Text モデルを選択します。このモデルは、テキスト検索や、テキスト間のセマンティック類似性の測定、クラスタリングなどのユースケースに活用ができ、日本語もサポートされています。 画面下のほうにあるベクトルデータベースについては、「新しいベクトルストアをクイック作成」を選択します。 「次へ」を押すと、確認して作成ステップに進みます。これまでのステップでの設定をあらためて確認し、一番下にあるオレンジ色の「ナレッジベースを作成」ボタンを押すと、ベクトルデータベース作成、ナレッジベース作成が自動的に開始されます。作成が完了したら、「同期」ボタンを押します。データソースの同期が完了するまでに要する時間はデータ量によりますが、今回のような サンプル題材 PDF 3ファイルの場合は、筆者のネットワーク環境では数秒ですぐに完了しました。 今後、例えばデータソース内の PDF ファイルが新たに100個追加された場合など、更新があったときは同様にデータ同期を実施すると RAG のデータソースが都度更新されることになります。 データソース同期が完了すると、ナレッジベースをテストすることができます。画面右側にあるオレンジ色の「モデルを選択」をクリックします。ここでいうモデルは、 RAG のイメージ図のところで説明した Text モデルに相当します。 候補として提示された基盤モデルの中から選択しますが、ここでは Anthropic 社の Claude の中で最新バージョンの v 2.1 モデルを指定します。 わずかこれだけの前準備で Knowledge Bases for Amazon Bedrock が使用可能な状態になりました。 特許検索における課題への対応 それでは、特許検索における以下課題にどのように対応できるかを見ていきましょう。 課題1 「特許の内容は一見難解であることが多いため、解釈が難しい」 今回のサンプル題材の3つはいずれも極低温冷凍機という一般の方には馴染みが薄いプロダクトを対象としています。その中の一つ、たとえば、 JP2013174393A の文章を見てみますと、馴染みが薄い方には文意を読み取るのが難しいかもしれません。発明者の私ですら正直理解するのが困難です。 そこで、Bedrockに対して以下のような質問を投げてみましょう。以下画像のメッセージ入力欄に質問を書き、オレンジ色の実行ボタンを押します。 Bedrockへの質問「特許JP2013174393Aについて。この特許はどのような内容で、どのような点に新規性、進歩性があるのか、中学生にもわかる言葉で簡潔に説明してください。」 すると、以下画像の紫枠のように、回答を返してくれました。 極低温冷凍機がどういう原理で動作しているかや、特許要件として重要な要素である新規性・進歩性は「弾性手段」を設けてモータ負荷を軽減する工夫を取ったところにあるということが簡潔に要約されました。 また、回答文の中に[1]、[2]といったリンクが付いています。[1]、[2]は回答の元になった文書を指しており、これによって、ファイル内の広範囲に及ぶ情報の中のどの箇所を根拠として回答したかが明らかになり、ユーザーは回答の信頼性を簡単に確認できます。 課題2 「新規発明案に対して、既に類似の特許が出願されているかを調べるのが困難」 自分の思いついた発明内容は既に他人によっても発明されており、特許取得されていたというのはよくあるケースです。手戻りの無駄が発生することを防ぐために、以下のようなRAGを使って類似特許を確認する事前確認を取りましょう。 例えば、極低温冷凍機に関する以下のような発案をした場合です。 Bedrockへの質問「モーターの回転運動を往復運動に変換するネジ螺合駆動形式の極低温冷凍機を発案しました。これによって従来の形式よりも機構部分の部品点数が少なくコストが低くできます。これと内容が重複する既存特許はデータソースの中にありますか？」 これに対しても課題1のときと同様の形式で以下回答を返してくれました。 Bedrockからの回答「はい、データソースの中に本発明と内容が重複する既存特許があります。[1] [2] [3] [4] [5] 特許文献1から5は、モーターの回転運動を螺合機構(ネジ機構)によってディスプレーサの往復運動に変換する極低温冷凍機に関するものであり、本発明と同様に機構部分の部品点数が少なくコストが低減できることが記載されています。[6] [7] [8] [9] [10] 」 これはデータソース内にある JP2013174394A という特許を指します。 このような形で、概要のような曖昧な文章からでも類似特許を検索でき、重複を指摘してくれます。今回はサンプル題材3ファイルをデータソースに保存しただけですが、データが膨大になるほどより効果を発揮します。 ただし、プロンプト（質問文の書き方）によっては似たような特許が存在するにも関わらず検索されない場合もあります。プロンプトが望ましい形で書かれていた場合であっても、 出願するにあたっての判断のためには弁理士など専門家によるチェックを依頼することを推奨します。 また、今回のような利用方法をする場合には、著作権など法的な問題がないことをご確認のうえ実施いただきますようお願いします。 まとめ いかがでしょうか。今回は特許検索を題材としましたが、取り扱った二つの課題解決応用以外にも、データソース内にある特許を組み合わせて新たな発明を検討するような使い方をするなど、他にも様々な活用アイデアが考えられると思います。 また、特許検索以外にも、社内文書をデータソースにした RAG は多種多様なユースケースが考えられます。例えば、自社製品の設計過去トラブル集をデータソースとし、新規製品の設計を行うに当たって困っている検討箇所があった場合に、注意すべき点を問いかけて、該当する過去の失敗事例やその解決策を提示してもらう、などが考えられます。 新機能の Knowledge Bases for Amazon Bedrock を活用して、少ない前準備で手軽に RAG を実施し、業務を効率化させていきましょう。 著者プロフィール 山田 航司  (Koji Yamada @yamadakj) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 製造業のお客様を中心にクラウド活用の技術支援を担当しています。好きな AWS のサービスは Amazon Transcribe です。 愛読書は「大富豪トランプのでっかく考えて、でっかく儲けろ」です。

こんにちは！アマゾンウェブサービスジャパン合同会社で製造業のお客様を支援しているシニア事業開発マネージャーの川又です。 2024 年 3 月 14 日に製造業向けオンラインセミナー「データ活用による製造業のトランスフォーメーション」を開催いたしました。セミナーの開催報告として、ご紹介した内容や、当日の資料・収録動画などを公開いたします。 はじめに 今回のセミナーは、製造業の皆様や、製造業のお客様を持つパートナーの皆様から、よくご要望をいただく、「製造業におけるデータ活用やお客様での事例」を単にプレゼンテーションでご紹介するだけではなく、実際に視聴者の皆さまにより具体的にイメージを持っていただけるようデモも交えながらお伝えさせていただきました。それぞれのセッションの内容を本ブログと動画でお届けいたします。 オープニングセッション：製造業におけるデータジャーニーとベストプラクティス 登壇者: AWS エンタープライズ技術本部 ハイテク・製造・自動車産業グループ 製造第一ソリューション部・部長 河村 聖悟 資料リンク 私達の暮らしの中では、天気や交通状況など、日常生活の様々な場面でデータに基づいた判断が行われています。製造現場においてもデータの力を活用できれば、生産効率・最適化など多くのメリットがありますが、現場には課題が山積みです。デジタル化されていない情報が多数存在して、可視化は部分的であり、オペレーションが分断されているなどの課題が挙げられます。課題対策の指針として「製造業におけるデータジャーニー」というロードマップをご紹介します。 製造業におけるデータジャーニー 「製造業におけるデータジャーニー」は、データ運用の成熟度によって4つのエリアに分かれています。エリア1は「局所的なリアルタイムの可視化」、エリア2は「全社的な可視性」、エリア3は「予測的オペレーション」、エリア4は「コスト最適化オペレーション」です。必ずしもすべてのエリアを順番に進む必要はなく、現在の成熟度から次のステップを知ることが重要です。 エリア１：局所的なリアルタイムの可視化 エリア 1「局所的なリアルタイムの可視性」では、パイロット施設や重要要素を特定し、優先ワークロードにソリューションやダッシュボードを導入します。既存設備からデータを取り出すことが重要で、現場ノウハウから生産管理者への情報伝達を円滑にします。大きな投資は不要ですが、全体最適化を見据えたロードマップを意識しつつ、将来的な展開を見越した取り組みが求められます。 エリア２：全社的な可視性 エリア 2「全社的な可視性」では、全社的なデータレイク戦略の構築が求められます。企業全体のデータレイクと OT / IT 接続戦略が必要不可欠です。リアルタイムなデータは、意味のあるコンテキストを持った状態での可視化が分析に必要であり、優先順位を付けたユースケースについて、丁寧に複数の場所で段階的に実施していくことが重要です。現場にとってインセンティブが少ないため、中期的な視点で各現場・部門との調整を行い、PoC を実施して小さな成功体験を積み重ねていく必要があります。 エリア３：予測的オペレーション エリア 3「予測的オペレーション」では、アナリティクスや AI、機械学習を活用して工場の財務計画や生産能力計画でリソースの最適化を図ります。過去のデータだけでなく、仮説に基づいた予測を行う仕組みが必要不可欠です。標準のモデルなどを活用した予測データ・グラフから新たな気づきを得ることで、これまでにない観点や改善や、判定条件を設ける事で機械同士の連携や自動化が可能になり、フィードバックループを作り出せます。現場では手戻りや重複作業の削減、多品種少量生産への対応など、エリア3のメリットを享受できるようになります。 エリア４：コスト最適化オペレーション エリア 4「コスト最適化オペレーション」では、企業がビジネスプロセス全体を最適化する能力を獲得します。アナリティクスに基づく最適化がモデルと意思決定プロセスに統合されることで、真のコスト削減と、統一されたインターフェイスにより工場・工程を横断した全体最適化が実現できます。設計・デザイン・スマートファクトリー・スマートプロダクトがデータでつながり、製品やプロセスの継続的な改善につながります。エリア4に至るには、企業全体のデータ統合と、新しいデータ駆動型の企業運営モデルへの関係者全員のコミットメントが必須条件となります。 モダンデータ戦略の成功要因としての３本の柱 製造におけるデータジャーニーを支える大切な3つの柱をご紹介します。1 つ目は「マインドセット」の柱です。データドリブンなカルチャーを取り入れてデータ活用を進めるためには、意識改革が不可欠であり、経営層からの強いコミットメントが求められます。2 つ目は「人材とプロセス」の柱です。イノベーションを最も促進できる組織構造・役割・プロセスを定義してコミュニケーションを密にし、データ活用の舞台・教育体制を提供することを指します。最後に「テクノロジー」の柱があります。パフォーマンス、費用対効果、安全性、スケーラビリティに優れた、クラウドデータアーキテクチャの活用に代表されます。これら 3 つの柱が、データ活用を企業文化に根付かせる鍵となります。 製造業における AWS の幅広いケイパビリティ 講演の中では、製造業のデータジャーニーを力強くサポートする AWS の幅広いサービスとケイパビリティをご紹介しました。AWS は、工場のエッジ、オンプレミス、既存システムとの連携を強くサポートします。エッジでは、エンドツーエンドのセキュリティ、開発、デプロイ、管理の機能を提供します。様々なデータフォーマット・転送形式に対応したデータ収集機能や、柔軟なデータレイクのインフラ、データ管理に関するセキュリティ、アクセス権限管理機能を提供しています。目的別のデータベース、豊富な分析手段、機械学習のツール、リアルタイム分析の可視化機能が、データジャーニーのジャンプスタートを可能にします。 製造におけるデータジャーニーでは誰もが主役 データジャーニーを推進するには、経営層、生産管理者、現場の全ての関係者がコミットし、同じ歩幅でなくとも、同じ方向を向いて小さな一歩を踏み出す必要があることをお伝えしました。完全なデータ利活用は一朝一夕にはできませんが、クラウドの力を借りてすぐに開始可能であり、製造業のデータ活用の可能性を身近に感じていただけたら嬉しいです。AWS は、お客様とともに製造業のデータジャーニーを歩んでいく所存です。 ここからは、製造業におけるデータジャーニーのいくつかのエリアについて、詳細な説明やデモをご紹介します。 デモ１：業務改善につながる生産関連データ活用 登壇者: AWS ソリューションアーキテクト 山田 航司 資料リンク このセッションでは、データジャーニーのフェーズ1「ローカライズされたリアルタイムの可視性」における、既存の設備からデータを取り出す方法がイメージできるように、ミニチュアスマートファクトリーデモをご覧いただきました。スマートファクトリーデモでは、受注に応じた加工を施して出荷する 「多品種少量の受注生産品」の生産ストーリーを設定しました。 このような複雑化したオペレーションに生じやすい課題として、「人手に頼った生産によりヒューマンエラーが起こりやすくなる」や「生産の不安定化」といった課題が挙げられます。対応策として、設備装置から発生するデータを AWS IoT SiteWise や AWS IoT Core に集め、生産稼働状況をニアリアルタイムで可視化することで、異常やイレギュラーが発生してからアクションに移るまでの時間を短縮し、稼働率を高める方法をご説明しました。 既存設備を新しい機能をもった設備に入れ替える必要はなく、PLC などまずはできるところから可視化していくが重要であり、ミニチュア工場の中のどの部分が既存設備にあたるかや、 AWS IoT Greengrass をインストールした産業用 PC を新規で設置すれば生産データ活用のためにクラウドにデータを送れるようになることをビジュアルで解説しました。 デモ２：予測的オペレーションを実現する AWS Supply Chain 登壇者: AWS ソリューションアーキテクト 水野 貴博 資料リンク このセッションでは、サプライチェーン領域においてデータジャーニーのフェーズ3「予測的オペレーション」を実現する AWS Supply Chain をご紹介しました。サプライチェーンの領域では、エンタープライズリソースプランニング (ERP)、倉庫管理システム (WMS)、注文管理システム (OMS)、輸送管理システム (TMS) など、システムがサイロ化されているケースが多く、サプライチェーンのデータを統合し、エンドツーエンドのプロセスの可視化を実現し、予測的なオペレーションを実現することが難しいとされてきました。 AWS Supply Chain は、サプライチェーンデータレイクによる統合データ管理を提供し、既存のプロセスを最適化することができます。統合されたデータを活用し、予測精度の向上、過剰在庫の削減、サイクルタイムの短縮を可能にします。 AWS Supply Chain の「データ取込み」「在庫可視化」「デマンドプランニング」そして、2024 年にリリースされたばかりの「サプライプランニング」「N – Tier 可視化」について、デモを交えてご紹介しました。最後に 2024 年後半リリース予定の生成 AI アシスタント「Amazon Q」をご紹介しました。自然言語インターフェースによるサプライチェーンデータに対して「何が」「なぜ」「もし～だったら」という問い合わせを行う様子をご覧頂きました。 デモ３：クラウドネイティブ BI Amazon QuickSight 登壇者: AWS ソリューションアーキテクト 岩根 義忠 資料リンク このセッションでは、データジャーニーのフェーズ2「全社的な可視性」に至ることの価値と、その一例としてのデモをご覧いただきました。データドリブンな意思決定を一貫した KPI に基づいて素早く行えるようになると、意思決定サイクルが組織の各階層で頻繁になり、結果として組織・工場のアジリティを高めることができます。 こうしたアジリティを高めるための、一貫した KPI に基づくデータドリブンな意思決定の一例として、 Amazon QuickSight を用いた製造ダッシュボードのデモをご紹介しました。また、BI ツールによる可視化や分析レポートのために必要とされる専門知識のハードルを下げ、「データ分析の民主化」を成し遂げるために、自然言語による直感的なダッシュボード作成や、ダッシュボードから得られる洞察を自然言語でレポート化できる Amazon Q in QuickSight (Preview) によるダッシュボード作成とレポート作成のデモをご紹介しました。 部門や工程の壁を超えたクラウドへのデータ集約と、強力な可視化ツール、生成AIの組み合わせにより、「現場に可視化のパワーを与える」ことが可能となり、さらに次の段階の「予測的オペレーション」に向け、改善活動の志向が全体最適に向かうことが期待されます。 終わりに 本セミナーでは、 製造業におけるデータジャーニーとベストプラクティスをご紹介するプレゼンテーションから、工場の可視化‐複数工場の現在の稼働状況を遠隔地から把握するデモ、サプライチェーンに関わるデータ活用とデモ、製造現場のデータ活用における思想設計やユースケース設定に立ち戻ったデータ活用推進のアイディアやデモや AWS の提供する新機能活用などを通して、AWS がご支援する製造業におけるデータ活用を紹介しました。 本ブログは、事業開発マネージャーの川又俊一、ソリューションアーキテクトの 河村聖悟、山田航司、水野貴博 、岩根義忠が執筆しました。

こんにちは。ソリューションアーキテクト (以下 SA) の津和崎です。 2023 年 11月 7日に「AWS Media Road Show 2023 – AWSメディアサービスを使ったコンテンツ配信の最前線」と題したイベントを開催しました。AWS Media Serviceの最新情報をAWS Elemental R&DのProduct Managerが直接解説するLoft Eventです。ご参加いただきました皆様には、改めて御礼申し上げます。 当日の様子と実施内容 セッションの紹介 MediaLive/MediaConnect最新動向 AWS Elemental R&D Head of Product, Live Services Mike Cronk 資料ダウンロード クラウドベースのライブ制作と UHD OTTストリーミングによって、業界をリードする品質・拡張性・回復力をどのように実現しAWSユーザーのお客様が収益を最大化しているか、Paramount Global、National Hockey League（NHL）、ロレックス・パリ・マスターズ（テニストーナメント）、Sky Sports、PGAツアー、Stan. の事例を紹介し、数多くのスポーツやイベント会場からクラウドを活用してライブ制作する利点を紹介しています。多くのVODサービスで最高品質がUHDにシフトするなかで、エンコードに必要な分散処理の課題を解決するMediaLiveの内部的改善、エンコーダーまでのMediaConnectを活用した伝送、パッケージング・配信まで、クラウドをフル活用したアーキテクチャをご紹介しています。Media Live/Media Connectは現在、東京・大阪リージョンでの展開も進んでおり、コンテンツを国外に出すことなく2つのリージョンによるDRが実現できます。 MediaTailor Channel Assembly最新動向 AWS Elemental R&D Senior Prod Manager Phil Harrison 資料ダウンロード Live・VOD問わずパーソナライズされた広告挿入およびチャネルアセンブリを可能にするAWS Elemental MediaTailor について、本セッションではVODとLive to VODへの広告挿入についての基本機能の紹介と利点、ユースケース、それがどのような技術で動いているかをご紹介し、Case StudyとしてSeven West Mediaでの活用事例をご紹介しています。Media Tailorで広告挿入する場合のレファレンスとして、手動でスケジュールしたタイミングで広告を挿入するアーキテクチャ・AIによるユーザーごとにパーソナライズされた広告挿入に対応できるアーキテクチャをそれぞれ紹介し、直近の機能リリース（Liveソースへの対応・Channel Assemblyで迅速なスケジュール更新等）についても紹介しています。 MediaTailor SSAI (Server Side Ad Insertion)最新動向 AWS Elemental R&D Senior Product Manager Peter Henning 資料ダウンロード AWS Elemental MediaTailorにてサーバーサイド広告挿入をする場合のアーキテクチャとして、ライブ・VODそれぞれに対しての広告挿入のレファレンスアーキテクチャを紹介し、広告のトランスコーディングやレポート、オブザーバビリティ、AWS 以外の多様なAdサーバーへの対応、大阪リージョンの対応など深掘りして機能の紹介をしています。 特に、オーバーレイ広告についてはPeacockの事例・IBCにてデモが行われたスクィーズ/フレーム広告などもご紹介し、コンテンツと合成された形で広告を表示し、視聴者は広告中もコンテンツを見続ける視聴体験が可能になる利点・機能をご紹介しています。加えて、マニュフェストによるCreative IDシグナリングにより、広告再生のコントロールをどのようにして実現するか、HLS インタースティシャルへの対応予定についても詳しく紹介しています。 MediaConvert最新動向 AWS Elemental R&D Principal Product Manager Max Denton 資料ダウンロード AWS Elemental MediaConvertを活用したトランスコーディングについて、東京に加え大阪リージョンでも活用できるようになった状況やSony LIV・Slackでの活用事例をご紹介しております。 最新機能の紹介としては、取得できるメトリクスの追加や動画の品質を向上するための機能として、圧縮効率の向上・AI Human Vision System を使用した知覚できないほどの微細なノイズの除去・シャープネスの調整機能など、 Bandwidthを低く保ったまま動画品質を向上させる方法を紹介しております。トランスコードのためのワークフローを改善する機能として、ビデオソースの置き換え機能、コンテナ・オーディオ・キャプションはそのままでビデオエッセンスのみをパススルーできる「トランスマックス」機能、出力先のS3 Tierを変更できる機能など、さまざまな変更に対応している点を詳しく紹介しています。 まとめ 今回は、U.S.から来日したMedia サービスのProduct ManagerよりAWS メディアサービスを使ったコンテンツ配信の最新情報をご紹介いたしました。本イベントが、より高品質でスケーラブルな配信がより短期間に数多く、収益性も伴う形で実現するためのきっかけになれば幸いです。 AWS のサービスを利用することをご検討いただいているお客様がいらっしゃいましたら、無料で個別相談会を開催しておりますので、 こちらのリンク からぜひお申し込みください。 技術統括本部 エンタープライズ技術本部 ソリューションアーキテクト 津和崎美希

3月18日週はストレージの話題からお届けします。 3月11日週、 Amazon Simple Storage Service (Amazon S3) の 18 年にわたるイノベーションを祝うイベントが AWS Pi Day 2024 で開催されました。Amazon S3 のマスコットである Buckets も参加して、非常に楽しいイベントとなりました。 4 時間にわたるライブストリームでは、ユーモアを交えながら、 PartyRock を使用した パイのレシピ 、デモ、コード、そして生成 AI と Amazon S3 に関するディスカッションが紹介されました。 AWS Pi Day 2024 — 2024 年 3 月 14 日の Twitch ライブストリーム ライブストリームを見逃した場合は、 録画 を見ることができます。今週、 community.aws の AWS Pi Day 2024 に関する投稿 も更新して、ショーのメモとセッションクリップを追加する予定です。 3月11日週のリリース 私が注目したいくつかのリリースをご紹介します。 Anthropic の Claude 3 Haiku モデルが Amazon Bedrock で利用可能に — 最近、 Anthropic が基盤モデル (FM) の Claude 3 ファミリー (Claude 3 Haiku、Claude 3 Sonnet、Claude 3 Opus) を発表しました。このファミリーの中で最も高速でコンパクトな Claude 3 Haiku が Amazon Bedrock で利用できるようになりました。詳細については、 Channy の投稿 を参照してください。さらに、同僚の Mike が、 Amazon Bedrock での Haiku の使用を開始する方法を紹介する動画 を community.aws で公開しています。 AWS CloudFormation で最大 40% 速くスタックを作成  — AWS CloudFormation の CONFIGURATION_COMPLETE という新しいイベントでスタックを最大 40% 速く作成できるようになりました。このイベントを使用すると、CloudFormation はスタック内の依存リソースの並行作成を開始し、プロセス全体がスピードアップします。この新しいイベントでは、リソースの一貫性チェックが不要なシナリオでも、ユーザーはスタック作成プロセスをより細かく制御することもできます。詳細については、 この AWS DevOps ブログ記事 を参照してください。 Amazon SageMaker Canvas がモデルレジストリ統合を拡張 — SageMaker Canvas のモデルレジストリ統合が拡張され、時系列予測モデルに加えて、 SageMaker JumpStart で微調整されたモデルが含まれるようになりました。ユーザーは、これらのモデルをワンクリックで SageMaker モデルレジストリに登録できるようになりました。この機能強化により、モデルレジストリの統合が、リグレッション/分類表モデルや CV/NLP モデルなど、Canvas でサポートされているすべての問題タイプに拡張されます。その結果、機械学習 (ML) モデルの本番環境へのデプロイが効率化されます。 詳細については、デベロッパーガイドを参照してください。 AWS のお知らせの詳細なリストについては、「AWS の最新情報」ページをご覧ください。 AWS のその他のニュース 興味深いと思われるその他のニュース記事、オープンソースプロジェクト、Twitch ショーを紹介します。 Build On Generative AI — 生成 AI のすべてを網羅する人気の ウィークリー Twitch ショー のシーズン 3 が盛り上がりを見せています。 私の同僚の Tiffany と Darko が、毎週月曜日 9:00 US PT のストリーミングで生成 AI のさまざまな側面についてディスカッションし、ゲストスピーカーのデモを紹介しています。 今日のエピソード では、ゲストの Martyn Kilbryde が、Amazon Bedrock を使用して JIRA エージェントを構築する方法を紹介しています。 ショーのノートとエピソードの完全なリストについては、community.aws をチェックしてください 。 PyTorch 用の Amazon S3 コネクタ — PyTorch Lightning のユーザーは、 PyTorch 用 の Amazon S3 コネクタ を使用してモデルチェックポイントを Amazon S3 に直接保存できるようになりました。PyTorch 用の Amazon S3 コネクタを使用すると、Connector for than writing to Amazon Elastic Compute Cloud (Amazon EC2) インスタンスストレージに書き込むよりも 40% 速く PyTorch Lightning モデルチェックポイントを保存できます。PyTorch Lightning トレーニングジョブから Amazon S3 でチェックポイントを直接保存、読み込み、削除することも可能になりました。  GitHub のオープンソースプロジェクトをチェックしてください。 AWS のオープンソースに関するニュースと最新情報 — 私の同僚である Ricardo が、AWS コミュニティの新しいオープンソースプロジェクト、ツール、およびデモに焦点を当てた Open Source Newsletter を毎週 執筆しています。 近日開催される AWS イベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 AWS at NVIDIA GTC 2024 — NVIDIA GTC 2024 開発者カンファレンスが今週 (3 月 18 日～21 日) にカリフォルニア州サンノゼで開催されます。お近くの方は、ブース #708 の AWS で生成 AI のデモを確認し、ブース内のシアターで生成 AI、ロボティクス、アドバンストコンピューティングの最新製品について、AWS、AWS パートナー、エキスパートのお客様からインスピレーションを得てください。  AWS セッションをチェックして、1 対 1 のミーティングをリクエストしてください。 AWS Summit — AWS Summit シーズンの到来です! 最初の開催地である パリ (4 月 3 日) を皮切りに、 アムステルダム (4 月 9 日)、 シドニー (4 月 10 日～11 日)、 ロンドン (4 月 24 日)、 ベルリン (5 月 15 日～16 日)、そして ソウル (5 月 16 日～17 日) での開催が予定されています。AWS Summit は、クラウドコンピューティングコミュニティが一堂に集まって交流し、コラボレートして、AWS について学ぶことができる無料のオンラインおよび対面イベントです。 AWS re:Inforce — ペンシルバニア州フィラデルフィアで開始される AWS re:Inforce (6 月 10 日～12 日) にご参加ください。AWS re:Inforce は、AWS セキュリティソリューション、クラウドセキュリティ、コンプライアンス、アイデンティティに焦点を当てた学習カンファレンスです。セキュリティツールを構築している AWS チームとつながり、AWS のお客様のセキュリティジャーニーについて学ぶことができます。 近日開催されるすべての対面イベントと仮想イベントを閲覧することができます。 今週はここまでです。3月25日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください。 –  Antje この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

3月14日は AWS Pi Day です ! 太平洋標準時の午後 1 時から始まる Twitch のライブ配信にご参加ください 。 18 年前のこの日、西海岸のある小売企業が オブジェクトストレージサービスを開始し 、 Amazon Simple Storage Service (Amazon S3) を世界に発表しました。世界中の企業のデータ管理方法が変わるとは思いもしませんでした。2024 年に進むと、 現代のビジネスはすべてデータビジネスです 。私たちは、 データがどのようにしてデジタルトランスフォーメーションを推進するのに役立つか 、そして 生成人工知能 (AI) がどのようにしてビジネスに予想外の有益な新しい機会をもたらすのかについて、数え切れないほどの時間を費やしてきました。私たちの対話は進化し、差別化された生成 AI アプリケーションの作成において、独自のデータがどのような役割を果たすかについての議論を取り入れるようになりました。 Amazon S3 は、実質的にどんなユースケースにも対応できる 350 兆以上のオブジェクトとエクサバイト規模のデータを保存し、1 秒あたり平均 1 億回以上のリクエストを処理していることから、皆様の生成 AI の旅の出発点になる可能性があります。しかし、最も重要なのはデータの量や保存場所ではなく、その品質です。質が高いデータでモデル応答の精度と信頼性を向上させることができます。 最高データ責任者 (CDO) を対象とした最近の調査では 、CDO のほぼ半数 (46%) が、生成 AI の実施における最大の課題の 1 つがデータ品質だと考えています。 今年の AWS Pi Day では、Amazon S3 の誕生日にあたり、データレイクから高性能ストレージまで、 AWS Storage がどのようにデータ戦略を変革し、生成 AI プロジェクトの出発点となるかを観察していきます。 このライブオンラインイベントは、 AWS Innovate: Generative AI + Data edition の終了直後の本日 (2024 年 3 月 14 日) 午後 1 時 (太平洋標準時) に始まります。 Twitch の AWS OnAir チャンネル でライブ配信され、AWS の専門家による 4 時間の新しい教育コンテンツが取り上げられます。データと既存のデータアーキテクチャを使用してカスタマイズされた生成 AI アプリケーションを構築および監査する方法を学ぶだけでなく、最新の AWS ストレージイノベーションについても学ぶことができます。通常通り、このショーでは実践的なデモは満載、皆様がこれらのテクノロジーを直ちに使い始める方法を実際に見ることができます。 生成 AI のデータ 消費者活動、ビジネス分析、IoT センサー、コールセンターの記録、地理空間データ、メディアコンテンツ、またその他の要因によるデータは驚異的な速度で増加しています。このようなデータの増加は、生成 AI のすさまじい成長の原動力です。基盤モデル (FM) は、インターネットからのペタバイト規模のウェブページデータを含むオープンリポジトリである Common Crawl などのソースから提供される大量のデータセットに基づいてトレーニングされます。FM からの応答をさらにカスタマイズするために、組織はより小規模なプライベートデータセットを使用しています。これらのカスタマイズされたモデルは、次に、更に多くの生成 AI アプリケーションを促進し、お客様とのインタラクションを通じて、データフライホイールのためにさらに多くのデータを生成します。 業界、ユースケース、地域に関係なく、今すぐ始められるデータイニシアティブは 3 つあります。 まず、 既存のデータを使用して AI システムを差別化します 。ほとんどの組織の基盤は大量のデータです。このデータを使用して、特定のニーズに合わせて基盤モデルをカスタマイズおよびパーソナライズできます。パーソナライゼーション技術には、構造化されたデータが必要なものもあれば、そうでないものもあります。その他には、ラベル付きのデータまたは未加工データが必要なものもあります。 Amazon Bedrock と Amazon SageMaker には、さまざまな既存の基盤モデルを微調整または事前トレーニングするための複数の解決策が用意されています。また、お客様や協力者のために ビジネスのエキスパートである Amazon Q をデプロイし、 すぐに使用可能な 43 のサポートされるデータソース 内の 1 つ以上を標的として指定することも可能です。 しかし、AI 利用の拡大に役立つ新しいデータインフラストラクチャの構築は望んでいないでしょう。生成 AI は、既存のアプリケーションと同じように組織のデータを消費します。 その次に、 既存のデータアーキテクチャとデータパイプラインを生成 AI と連携させ 、データアクセス、コンプライアンス、およびガバナンスに関する既存のルールを引き続き遵守することを望んでいます。当社のお客様は、AWS に 1,000,000 を超えるデータレイクをデプロイしていました。データレイク、Amazon S3、および既存のデータベースは、生成 AI アプリケーションを構築するための優れた出発点です。 検索拡張生成 (RAG) をサポートするために、複数のデータベースシステムでベクターストレージと検索へのサポートを追加しました。 Amazon OpenSearch Service は論理的な出発点かもしれません。ただし、 pgvector を PostgreSQL 用の Amazon Aurora 、および PostgreSQL 用の Amazon Relational Database Service (Amazon RDS) と一緒に使用することもできます。また最近、 Amazon MemoryDB for Redis 、 Amazon Neptune 、 Amazon DocumentDB (MongoDB 互換) 用の ベクターストレージと検索 を発表しました。 また、現在既に導入されているデータパイプラインを再利用または拡張することも可能です。皆様の多くは、 Amazon Managed Streaming for Apache Kafka (Amazon MSK) 、 Amazon Managed Service for Apache Flink 、 Amazon Kinesis などの AWS ストリーミングテクノロジーを使用して、伝統的な機械学習 (ML) や AI でリアルタイムのデータ準備を行っています。これらのワークフローを拡張してデータの変更を捕捉して、ベクトルデータベースの更新によりほぼリアルタイムで大規模言語モデル (LLM) に変更を反映させたり、MSK のネイティブストリーミングインジェストを用いて Amazon OpenSearch Service にナレッジベースの変更を反映させたり、 Amazon Kinesis Data Firehose を通じて Amazon S3 の統合データストリームで微調整データセットを更新したりすることができます。 LLM のトレーニングにおいて、スピードが重要です。データパイプラインは、トレーニングクラスター内の多くのノードにデータをフィードできる必要があります。Amazon S3 にデータレイクを持つお客様は、パフォーマンス要件を満たすために、 Amazon S3 Express One Zone のようなオブジェクトストレージクラスや、 Amazon FSx for Lustre のようなファイルストレージサービスを利用しています。 FSx for Lustre は緊密な統合を実現し、使い慣れた高性能ファイルインターフェイスを利用することで、オブジェクトデータ処理の高速化を可能にします。 幸いなことに、データインフラストラクチャが AWS サービスで構築されている場合、生成 AI のデータを拡張する方向に既に大きな進歩を遂げました。 第 3 に、 自分自身の最高の監査人にならなければなりません。 すべてのデータ組織には、生成 AI のために定められた規制、コンプライアンス、コンテンツ管理に対して、事前に備える必要があります。トレーニングやカスタマイズにどのデータセットが使用されているか、また、モデルがどのように意思決定を行ったかを知っておく必要があります。生成 AI のような急速に変化している分野では、未来を予測する必要があります。AI システムをスケールする間、完全に自動化されている方法ですぐにそれを実行する必要があります。 データアーキテクチャでは、 AWS CloudTrail 、 Amazon DataZone 、 Amazon CloudWatch 、 OpenSearch など、さまざまな AWS サービスを監査に使用され、データ使用量が管理および監視されています。これは AI システムへ簡単に拡張できます。生成 AI に AWS Managed Services を使用している場合は、組み込まれたデータの透明性を高める機能を利用できます。CloudTrail サポート付きの生成 AI 機能を発表するのは、企業からのお客様には、AI システムの監査証跡を持つことがいかに重要であるかを理解しているからです。Amazon Q でデータソースを作成すると、そのデータソースは CloudTrail に記録されます。CloudTrail イベントを使用して、 Amazon CodeWhisperer によって作られた API コールをリストで表示することもできます。 Amazon Bedrock には 80 を超える CloudTrail イベントがあり、これらを使用してファンデーションモデルの使用方法を監査するのが可能です。 前回の AWS re:Invent カンファレンスでは 、 Amazon Bedrock 向けのガードレール についても紹介しました。これにより、避けるべきトピックを指定できます。また、 Bedrock は、制限されたカテゴリーに該当する質問に対し、承認済みの回答のみをユーザーに提供します リリースされたばかりの新機能 Pi Day は、AWS ストレージとデータサービスの革新を祝う機会でもあります。ここでは、今回発表された新機能の一部を紹介します。 PyTorch 用 Amazon S3 コネクタ は今、 PyTorch Lightning のモデルチェックポイントを Amazon S3 に直接保存することをサポートするようになりました。モデルチェックポイントは通常、トレーニングジョブを一時停止する必要があるため、チェックポイントの保存に必要な時間は、エンドツーエンドのモデルトレーニング時間を直接に影響します。PyTorch Lightning はオープンソースのフレームワークで、PyTorch で行われるトレーニングやチェックポイントの作成にレベルの高いインターフェースを提供します。 この新しい統合の詳細については、「最新情報」の投稿を参照してください 。 Amazon S3 on Outposts 認証キャッシュ – この新機能は、Amazon S3 のアイデンティティ認証および承認データをローカルの Outposts ラックに安全にキャッシュすることで、リクエストのたびに親 AWS リージョンへの往復する必要をなくして、ネットワークでの往復によって生じるレイテンシーの変動を減少します。 Amazon S3 on Outposts 認証キャッシュの詳細については、「最新情報」の投稿 、および AWS ストレージブログチャネルで発表されたこの新規投稿を参照してください 。 Mountpoint for Amazon S3 Container Storage Interface (CSI) ドライバー は Bottlerocket で使用できます。Bottlerocket は Linux に基づき、コンテナーのホストを目的とするオープンソースの無料オペレーティングシステムです。 Mountpoint for Amazon S3 に基づいて構築された CSI ドライバーは、 Amazon Elastic Kubernetes Service (Amazon EKS) と自己管理型 Kubernetes クラスター内のコンテナによって、S3 バケットをアクセス可能なボリュームとして表示します。これにより、アプリケーションがファイルシステムインターフェイスを介して S3 オブジェクトにアクセスできるため、アプリケーションコードを変更せずに高い集計スループットを実現します。 「最新情報」の投稿には、Bottlerocket 用の CSI ドライバーに関する詳細が記載されています 。 Amazon Elastic File System (Amazon EFS) は、ファイルシステムあたりのスループットを 2 倍向上させました。当社は Elastic Throughput の制限について 、読み取りオペレーションでは最大 20 GB/秒、書き込みでは最大 5 GB/秒までに引き上げました。つまり、機械学習、ゲノミクス、データ分析アプリケーションなど、スループットをさらに重視するワークロードに EFS を使用できるようになりました。 EFS でのスループットの向上についての詳細は、「最新情報」の投稿を参照してください 。 今月初めに実行した重要な変更は、他にもあります。 Amazon S3 Express One Zone ストレージ クラスと Amazon SageMaker の統合 – トレーニングデータ、チェックポイント、およびモデルアウトプットの読み込み時間を短縮することで、Amazon SageMaker モデルのトレーニングを加速できるようになります。 この新しい統合の詳細については、「新機能」の投稿を参照してください 。 Amazon FSx for NetApp ONTAP は、ファイルシステムあたりの最大スループットキャパシティを 2 倍 (36 GB/秒から 72 GB/秒まで) に増加し、ONTAP のデータ管理機能をさらに幅広いパフォーマンスを重視するワークロードに使用できるようになりました。 Amazon FSx for NetApp ONTAP の詳細については、「最新情報」の投稿を参照してください 。 ライブ配信中に期待できること 本日において開催された 4 時間のライブショーでは、これらの新機能のいくつかについて説明する予定です。私の同僚の Darko さんが、AWS の専門家を多数招いて実践的なデモンストレーションを行います。皆様が生成 AI プロジェクトでデータを活用する方法を探すのに手伝いをします。こちらは当日のスケジュールです。すべての時間は太平洋標準時 (PT) タイムゾーン (GMT-8) で表記されます。 既存のデータアーキテクチャを生成 AI までに拡張 (午後 1 時～午後 2 時)。 AWS のデータレイク上で分析を行っているなら、生成 AI のためのデータ戦略に向けて、既に大きく前進していると言えます。 生成 AI のコンピューティングへのデータパスを加速 (午後 2 時～午後 3 時)。 モデルトレーニングと推論のコンピューティングデータパスには、速度が大事です。それを実現するさまざまな方法をご覧ください。 RAG と微調整でカスタマイズ (午後 3 時～午後 4 時)。 基本的な基盤モデルをカスタマイズする最新の技術をご覧ください。 GenAI の最高のオーディターになりましょう (午後 4 時～午後 5 時)。 コンプライアンスの目標を達成するために、既存の AWS サービスを活用しましょう。 AWS Pi Day ライブストリーム に今すぐご参加ください。 お会いできるのを願っています! — seb 原文は こちら です。

このブログ記事は、AWS エンタープライズサポート担当テクニカルアカウントマネージャーの Tanya Pahuja と Sumit Bhardwaj 、および AWS シニアソリューションアーキテクトの Karan Desai によって書かれました。 消費者向けのウェブサイトやモバイルアプリでは、ユーザーの画面にコンテンツが読み込まれるスピードが、ユーザーのブラウジング体験やビジネスの成功に直接影響します。コンテンツの読み込みに時間がかかると、ユーザーはトランザクションを完了する前にページを放棄する可能性があり、収益に影響します。 Amazon CloudFront のようなコンテンツ配信ネットワーク（CDN）を利用すれば、データ、動画、アプリケーション、API を低遅延かつ高速で世界中のユーザーに安全に配信し、ウェブサイトのパフォーマンスを向上させることができます。HTML 、画像、スタイルシート、JavaScript ファイルなどのウェブサイトの静的コンテンツは、CloudFront の エッジロケーション やリージョン別エッジキャッシュにキャッシュされたコピーから提供できます。新しく更新されたコンテンツや API コールなど、キャッシュできない動的コンテンツは、CloudFront によってオリジンサーバーからフェッチされ、 AWS グローバルネットワーク を使用して高速かつ最適化された経路で配信されます。 パフォーマンスを向上させるには、CloudFront ディストリビューションを設定することで、ウェブサイトのトラフィックが CloudFront のグローバルに分散されたエッジネットワーク経由で配信されるように設定するだけです。CloudFront を使用してコンテンツを配信するように設定したら、ウェブサイトのパフォーマンスを監視して、得られるメリットを理解し、パフォーマンスをさらに最適化するために設定を変更する必要があるかどうかを確認する必要があります。この投稿では、 Amazon CloudWatch Real User Monitoring (RUM) を使用してウェブサイトのパフォーマンスを監視し、CloudFront を使用してコンテンツを配信した場合と使用しない場合のユーザーエクスペリエンスの違いに関する洞察を得る方法を紹介します。 CloudFront に対する模擬モニタリングとリアルユーザーモニタリング（RUM） 通常、ウェブサイトのパフォーマンスを測定するために、2 つの異なるタイプのモニタリングを使用することができます。 模擬モニタリング： ユーザーのウェブサイトへのジャーニーとインタラクションのシミュレーションを使用して、ウェブサイトのパフォーマンスを監視する方法です。これは、地域、ネットワーク、デバイス、およびブラウザなどの変数が事前に決定され、変更されない制御された環境で行われます。外部変数を制御することは、バックエンドのインフラおよびアプリケーション側にパフォーマンスのボトルネックが存在する場所を理解し、パフォーマンスの問題の原因を特定するのに役立ちます。しかし、これは必ずしもユーザーが実世界で経験することを表すものではありません。 リアルユーザーモニタリング： パッシブ・モニタリングの一種で、実際のユーザーとウェブサイトとのやり取りを分析するものです。通常、アプリケーション内にコードの一部を挿入することで、ユーザーのブラウジング体験に影響を与えることなく、クライアントやブラウザからのフィードバックを収集します。これにより、顧客がウェブサイトとどのようにやり取りしているか、また、特定のデバイス、ブラウザ、およびネットワーク上でのウェブサイトのパフォーマンスに関する顧客の経験について洞察することができます。 アーキテクチャー概要 まず、 Application Load Balancer（ALB） の背後にある Amazon Elastic Compute Cloud（Amazon EC2） インスタンス上にウェブアプリケーションをデプロイすることから始めます。既存のウェブアプリケーションを使用するか、この チュートリアル に従ってサンプルの 3 層ウェブアプリケーションをデプロイすることができます。公開 ALB エンドポイント URL を使って、ブラウザからこのウェブサイトにアクセスします。これは CloudFront を実装する前のユーザーのベースライン体験を表しています。 十分なデータが得られたら、このディストリビューションの「オリジン」として先ほど使用したのと同じ ALB を指す CloudFront ディストリビューション を構成します。CloudFront は各ディストリビューションに一意のドメイン名を提供します。それでは、ブラウザからウェブサイトにアクセスしますが、今回は CloudFront の URL を使用します。これは CloudFront が実装された後のユーザーエクスペリエンスを表しています。2 つのテストから取得したデータを比較することで、コンテンツ配信のために CloudFront を使用することでユーザーが得られるパフォーマンスの向上を理解することができます。次の図はテストのアーキテクチャーを示しています。 図 1：ソリューションのアーキテクチャー図 CloudFront に対する CloudWatch モニタリング RUM の利用に入る前に、CloudWatch と直接統合されている CloudFront の運用メトリクスを調べることができます。これらのメトリクスは CloudWatch コンソール で利用でき、追加コスト無しで利用できます。以下のスクリーンショットにあるように、CloudFront ディストリビューションによって提供された HTTP リクエストの数、ユーザーによってダウンロードおよびアップロードされたバイト数、4XX および 5XX エラーの数を監視することができます。また、CloudFront ディストリビューションのキャッシュヒット率や、キャッシュされていないコンテンツを提供する際のオリジンレイテンシなど、追加コストで追加のメトリクスをオンにすることもできます。 図 2：CloudWatch 上の CloudFront モニタリングメトリクス このデータは、ウェブサイトの健全性を判断したり、ウェブサイトへのユーザートラフィックの概要を把握したりするのに役立ちます。しかし、ウェブサイトのパフォーマンスに関するユーザー・エクスペリエンスについての洞察は得られません。そこで RUM を活用します。 RUM を使ってウェブサイトのパフォーマンスを検証する 次に、同じウェブアプリケーションの RUM を使って計測しましょう。このためには、まず CloudWatch RUM でアプリケーションモニター を作成し、それによって生成された コードスニペット を、パフォーマンスをモニターしたいウェブサイトの HTML ページに挿入する必要があります。※CloudWatch RUM のアプリケーションモニターはドメイン毎に作成します。CloudFront 独自のドメインを使用して比較を行う場合は、CloudFront を使用する場合と使用しない場合でドメインが異なることがあります。その場合は検証を行う毎にコードスニペットをドメイン毎に入れ替えて検証してください。 1) CloudFront を使用しない場合の RUM CloudWatch RUM ウェブクライアントを埋め込みスクリプトとしてインストールするには、RUM ウェブクライアント設定コードスニペットをアプリケーションの <head> 要素内、他の <script> タグの上に貼り付ける必要があることに注意してください。 図 3：HTML ページに挿入された CloudWatch RUM スクリプトの例 パフォーマンスタブには、ページのロード時間やユーザーが遭遇したエラーなど、ウェブページのバイタルサインが表示されます。バイタルサインは 3 つのレベル ([Positive] (良好)、[Tolerable] (許容範囲)、[Frustrating] (不良)) に分けられます。 図 4：ページのロード時間を示す CloudWatch Performance タブ また、ユーザーのブラウザ上でウェブページを完全にロードするために必要な各ステップにかかる時間も確認できます。これには、初期接続の確立にかかる時間、SSL ハンドシェイク、コンテンツの最初のバイトをロードする時間、完全なロード時間などが含まれます。 図 5：ウェブページの読み込みにかかる各ステップの時間の内訳の例 この図の例では、この特定のユーザーがウェブページをロードするのにかかる平均時間は 764ms で、最初の接続に 278ms、最初のバイトに 280ms かかっていることがわかります。これをベースラインとして、CloudFront を使って同じウェブページを配信したときのパフォーマンスを比較することができます。 2) CloudFront を使用する場合の RUM AWS コンソールで先ほど作成した CloudFront ディストリビューションにアクセスし、CloudFront ドメインの URL を取得することができます。そして、ブラウザでこの URL を使ってウェブサイトにアクセスすることができます。これで再びCloudWatch RUM に新しいデータポイントが送信され、CloudFront を使用してコンテンツが配信されたときのユーザーエクスペリエンスが表示されます。パフォーマンスメトリクスを再び見てみましょう。 図 6: CloudFront を使用した場合のページのロード時間を示す CloudWatch Performance タブ 図 7：CloudFrontを使用したウェブページのロードにかかる各ステップの時間の内訳 先の例では、同じユーザーがウェブページをロードするのにかかった時間の合計が 447ms になったことがわかります。最初の接続には 17.5ms しかかかっていません。ALB の前に CloudFront をデプロイすることで、ページのロード時間がほぼ 40% 短縮され、ユーザーエクスペリエンスが向上していることがわかります。 CloudWatch RUM は、CloudFront を使用して配信されるウェブサイトについて、いくつかの追加の洞察を提供します。以下のスクリーンショットに見られるように、異なる地域のユーザーに対するウェブサイトのパフォーマンスを確認し、どのユーザーが良いエクスペリエンスを得ているか、またはページのロード時間が長いためにフラストレーションのたまるエクスペリエンスを得ているかを比較することができます。 図 8：CloudWatch RUM が提供する、ユーザーの地理的位置によるページロードパフォーマンスの例 また、以下のスクリーンショットのように、異なるブラウザやデバイスタイプを使用してウェブサイトにアクセスしたユーザーの閲覧体験の詳細を取得することもできます。 図 9：CloudWatch RUMが提供する、ユーザーのブラウザ別のページロードパフォーマンスの例 さらに、以下のスクリーンショットに見られるように、RUM が監視しているすべてのイベントのオリジナルログエントリや、ウェブサイトをナビゲートするユーザージャーニーにアクセスすることができます。 図 10 : クラウドウォッチ RUM の raw イベントログの例 また、以下のスクリーンショットのように、ランディングページからウェブサイト、その後のインタラクションまでのユーザージャーニー全体を追跡することもできます。 図 11 : CloudWatch RUM を使用してトラッキングされたユーザージャーニーの例 まとめ この投稿では、RUM を使用してエンドユーザーのウェブサイトのパフォーマンスに関する洞察を得る方法と、CloudFront を活用することで得られる改善を監視する方法について学びました。このデータが得られれば、アプリケーションのどの部分をさらに最適化すればユーザーエクスペリエンスが向上するかを特定でき、 CloudFront が提供する様々な機能 を設定することでウェブサイトのパフォーマンスをさらに向上させることができます。 本記事は、「 Prepare and run performance tests for Amazon Cloudfront with Real User Monitoring 」と題された記事の翻訳となります。 翻訳は Solutions Architect の長谷川 純也が担当しました。

IBM Db2は、ミッションクリティカルなシステムで信頼されているデータベースとして知られています。最近では、そのポテンシャルをクラウドでさらに活かそうとする企業が増えています。そこで、クラウドでのDb2活用方法とオンプレミスからのスムーズな移行戦略を解説する特別オンラインセミナーを企画いたしました。 本セミナーは、AWSをこれから始める方を対象に、初歩から専門知識まで段階的に解説します。 最初のセッションでは、AWSの概要、そしてAWSがどのようにしてリレーショナルデータベースの運用課題（パフォーマンス、運用効率、コスト効率、可用性、災害復旧）を解決できるかをご紹介します。 続いて、AWSのマネージドデータベースサービスであるAmazon RDS for Db2に焦点を当て、オンプレミス環境からクラウドへの移行がもたらす変化とそのメリットを、具体的かつ詳細に解説します。さらに、AWSへの移行プロセスを、実践的なステップに分けてご説明し、参加者の皆様が直面するかもしれない疑問や課題に対する答えを提供します。 AWSの基礎からAmazon RDS for Db2の活用法、効率的な移行プロセスまでを網羅し、参加者の皆様が直面する疑問や不安を解消する内容を2時間のセミナーにコンパクトにまとめました。 Db2のクラウド活用を始めるための貴重な洞察を得る絶好の機会です。ぜひお申し込みください！ 4月11日(木) オンラインセミナー 「IBM Db2 の試算を AWS で活用する」アジェンダ 時間 セッション 10:00 – 10:35 リレーショナルデータベースの課題と AWS による解決 Amazon RDS for Db2 の紹介を行う前に、AWS の特徴及び AWS が性能や運用、コスト最適化、および可用性と DR などリレーショナルデータベースにつきまとう課題をどのように解決できるか説明します。IBM Db2 に関する知識があっても AWS に関して知識が足りない、という方には欠かせないこの後のセッションを理解する上での AWS の前提知識について短時間で学ぶことができます。 AWS 技術統括本部 エンタープライズ技術本部 シニアソリューションアーキテクト 野間 愛一郎 10:35 – 11:15 Amazon RDS for Db2 紹介 AWS が提供するマネージド型のデータベースサービスである Amazon RDS for Db2 に関して Amazon RDS の基本から説明します。RDSの概要や特徴といった基本から説明しますので、Amazon RDS についての知識がなくとも Amazon RDS for Db2 のメリットや特徴を短時間で学ぶことができます。加えて、オンプレミスの IBM Db2 との違いについても説明します。 AWS サービス & テクノロジー事業統括本部 Data & AI ソリューション本部 シニアアナリティクススペシャリストソリューションアーキテクト 下佐粉 昭 11:15 – 12:00 AWS へのマイグレーション方法と支援サービス AWS ではお客様が移行先のデータベースを選択するために Database Freedom Workshop を提供しています。お客様環境の Db2 のアセスメントを含むこのプログラムでは、アセスメント結果を基に適切な移行先を決定する上でのガイドを提供します。今回のセッションでは、この Database Freedom Workshop の紹介のみならず、パートナー各社の移行支援サービスや、実際に移行を行ったお客様の事例紹介を通じて、現在利用している Db2 の今後に関して誰に相談すればいいのか、AWS からどのような支援が提供されるのか、どのようなステップで検討を進めればよいのかを学ぶことができます。 AWS データ事業本部 スペシャリストソリューション本部 シニアデータベーススペシャリストソリューションアーキテクト 矢木 覚 ※当日の進行により、時間割が若干変更となる場合がございます。 参加費：無料 参加登録： こちらのページよりお申し込みください スピーカー紹介 スピーカーはオンプレミスのDb2利用経験のあるAWSメンバーが担当します。 野間 愛一郎 AWS 技術統括本部 エンタープライズ技術本部 シニアソリューションアーキテクト 主に製造業のお客様を担当するソリューションアーキテクトとして活動。お客様の多種多様な要件に合わせてAWS上にソリューションを構成するため幅広く技術支援を行っている。前職ではIBM Db2の製品担当として大規模データベースやミッションクリティカルシステムを支援、データベースコミュニティの立ち上げなどにも貢献した。 下佐粉 昭 AWS サービス & テクノロジー事業統括本部 Data & AI ソリューション本部 シニアアナリティクススペシャリストソリューションアーキテクト 前職では、IBM Db2のプリセールスエンジニアとして活動。著書に「即戦力のDB2管理術」。 現職ではソリューションアーキテクトとしてRDS for Db2の技術支援をお客様・パートナーに提供している。 矢木 覚 AWS データ事業本部 スペシャリストソリューション本部 シニアデータベーススペシャリストソリューションアーキテクト 前職では、Oracle Databaseのプリセールスエンジニアとして活動。商用データベースに関する多数のwebコンテンツを作成。現職ではソリューションアーキテクトとしてRDS for Oracle, RDS for Db2を担当。 今回のウェビナー完了後、開催レポート及びQ＆Aは Amazon Web Servicesブログ に掲載予定となります。

AWS Config は、AWS アカウント内または AWS Organizations 全体の AWS リソースの設定変更を追跡するサービスです。AWS Config は設定レコーダーを使用してリソースの変更を検出し、それらを設定項目 (CI) として追跡します。クラウドインフラストラクチャの複雑さが増すにつれ、CI の数は指数関数的に増加しています。ワークロードは、短い間隔でリソースを作成、更新、削除することが必要であり、従来の静的なものではなく動的なものになりつつあります。過去には、設定レコーダーは継続的な記録のみをサポートしており、本番環境でない場合でも、追跡対象のリソースへの変更が発生したタイミングでそれをすべてキャプチャしていました。 この度、AWS Config の定期的な記録機能の提供を発表できることを大変嬉しく思います。この新機能により、設定レコーダーの記録頻度を日次に設定することが可能になりました。これまでの継続的な記録や設定項目の更新に代わり、過去 24 時間で変更があった場合に、リソースの最新の状態を表す設定項目が記録されるようになります。24 時間の周期内で、そのリソースタイプの定期的な記録が有効になっているリソースを作成および削除した場合は、設定項目は生成されません。定期的な記録を使用することで、すべてのリソースタイプのデフォルトの記録頻度を日次にしつつ、特定のリソースタイプをカスタマイズする設定が可能です。または、リソースタイプごとに設定することもできます。これにより、コンプライアンスやセキュリティ上の重要なリソースタイプの場合は従来の継続的な記録を使用して連続的に追跡し、本番以外のアカウント内の Amazon EC2 インスタンスなどは日次で定期的に追跡するように指定することが可能です。 定期的な記録のメリットには以下が含まれます: コスト効率 : 日次での記録により構成変更の記録頻度が下がることで、関連コストを削減できます。定期的な記録は継続的な記録とは異なる課金体系であることに注意が必要です。詳細は AWS Config の料金ページ をご確認ください。 混乱の最小化 : 定期的な記録による日次での記録は、過去 24 時間で変更があった際に設定項目が記録されるため、通知の頻度を下げてアラート疲れの回避に適した情報フローを提供します。 リソースタイプに対して定期的な記録または継続的な記録を使用するかどうかの決定にあたっては、セキュリティとコンプライアンスの要件を考慮することが重要です。リソースタイプのリアルタイムモニタリングや詳細な分析が必要な場合は、継続的な記録を使用することをおすすめします。詳細は 記録頻度 のページをご覧ください。 この投稿では、AWS Config の定期的な記録を開始する方法を紹介します。既存の設定レコーダーを AWS コンソールで更新して、継続的な記録ではなく定期的な記録を利用するようにします。さらに、AWS コンソールでカスタマイズ可能なオーバーライドを使用した定期的な記録のデモも行います。次に、 AWS CLI を使用して、定期的な記録用に設定レコーダーを設定する例を紹介します。AWS Config を初めて設定する場合は、 ワンクリックセットアップ から開始してください。 AWS Config での定期的な記録の設定 既存の AWS Config ユーザーが、特定のリソースタイプで定期的な記録を利用するように設定レコーダーの設定を更新したいシナリオについて説明します。デフォルトでは、記録範囲内のすべてのリソースタイプは、定期的な記録を明示的に選択しない限り、継続的な記録が採用されます。 設定レコーダーの記録方法における記録戦略には次の 2 つのオプションがあります: カスタマイズ可能なオーバーライドのあるすべてのリソースタイプ : AWS Config はオーバーライドの設定で 記録から除外 に指定したリソースタイプを除く、すべての現在および将来のサポートされているリソースタイプの設定変更を記録します。AWS Config の設定レコーダーを初めて設定する場合、これがデフォルトのオプションです。 特定のリソースタイプ : AWS Config は、指定したリソースタイプの設定変更のみを記録します。リソースタイプの記録を停止することを選択した場合でも、すでに記録されている設定項目は変更されません。 既存の設定レコーダーを定期的な記録に変更するには、次の手順を参照してください。 AWS Config コンソール に移動します。 ナビゲーションペインで、 設定 を選択します。 編集 を選択します。現在の記録戦略に応じて、ステップ 4 の「カスタマイズ可能なオーバーライドのあるすべてのリソースタイプの場合」またはステップ 5 の「特定のリソースタイプの場合」に進んでください。 記録戦略として カスタマイズ可能なオーバーライドのあるすべてのリソースタイプ が設定されている場合は以下のとおりです。 すべての現在および将来のリソースのデフォルトの記録頻度として、 継続的な記録 または 日次記録 を選択できます。デフォルトの記録頻度は継続的な記録に設定されています。 特定の リソースタイプ の記録頻度を変更したり、特定のリソースタイプを 記録から除外 に指定するために、任意のオーバーライドを追加できます。 注意 : グローバルリソースタイプの IAM リソースタイプを除外するには、このバンドルタイプをリストから選択し、記録から除外することを選択してください。バンドルの詳細については、AWS Config 記録方法の 設定 を参照してください。 図 1 AWS Config 記録方法 – カスタマイズ可能なオーバーライドのあるすべてのリソースタイプ 現在、 特定のリソースタイプ が記録戦略として設定されている場合は以下のとおりです。 ドロップダウンを使用して、記録するリソースタイプを追加または削除できます。 頻度では、リソースタイプごとに 連続 または 日次 を選択できます。 図 2 AWS Config 記録方法 – 特定のリソースタイプ 記録戦略を更新したら、 保存 を選択してください。 設定 の下部で、更新された設定レコーダーの設定を確認できます。 図 3 AWS Config 設定 AWS CLI を使用した既存の設定レコーダーの更新 このセクションでは、 AWS CLI を使用した定期的な記録の設定 の例をいくつか示します。 前提条件 AWS CLI を使用して既存の設定レコーダーを更新するには、既存の設定レコーダーの roleARN と name の情報が必要です。 describe-configuration-recorders コマンドを使用して、現在の設定レコーダーの name と roleARN を調べることができます。 $ aws configservice describe-configuration-recorders { "ConfigurationRecorders": [ { "roleARN": "arn:aws:iam::123456789012:role/config-role", "name": "default" } ] } すべてのリソースタイプへの定期的な記録の適用 put-configuration-recorder コマンドを使用して、設定レコーダーに設定を行うことができます。この例では、更新対象のレコーダーを識別するために、前提条件のステップでメモした設定レコーダーの name と roleARN を指定しています。 recording-group をすべてのサポートされているリソースに設定し、すべてのグローバルリソースタイプを true に設定しています。最後に、 recording-mode において記録頻度として recordingFrequency を DAILY に設定しています。 すべてのリソースタイプに定期的な記録を適用するには、ターミナルに以下のコマンドを入力します。 注意 : name と roleARN の値を、ご利用する AWS Config の設定レコーダーの値に置き換えてください。 aws configservice put-configuration-recorder --configuration-recorder name= default ,roleARN= arn:aws:iam::123456789012:role/config-role --recording-group allSupported=true,includeGlobalResourceTypes=true --recording-mode recordingFrequency=DAILY カスタマイズ可能なオーバーライドのあるすべてのリソースタイプを使用した定期的な記録の適用 すべてのリソースタイプに対して継続的な記録を行いたいが、カスタマイズ可能なオーバーライドを使用して特定のリソースタイプを定期的に記録したい場合は、 recording-mode オプションを使用する際に JSON ファイルを利用して設定することができます。 注意 : name と roleARN の値を、ご利用する AWS Config の設定レコーダーの値に置き換えてください。 aws configservice put-configuration-recorder --configuration-recorder name= default ,roleARN= arn:aws:iam::123456789012:role/config-role --recording-group allSupported=true,includeGlobalResourceTypes=true -- recording-mode file://recordingMode.json 以下は recording-mode で指定している JSON ファイル file://recordingMode.json の例です。 { "RecordingFrequency": "CONTINUOUS", "RecordingModeOverrides": [ { "RecordingFrequency": "DAILY", "ResourceTypes": [ "AWS::EC2::Instance", "AWS::DynamoDB::Table" ] } ] } JSON の例では、 RecordingFrequency が CONTINUOUS に設定され、継続的な記録がすべてのリソースタイプに指定されていることがわかります。しかし、EC2 インスタンスと DynamoDB テーブルの 2 つに関してはオーバーライドが定義されていて、定期的な記録が指定されています。 RecordingModeOverrides を利用することで、どのリソースタイプを継続的な記録の対象外とするか指定することが可能です。 コマンドオプションの詳細については、 AWS CLI コマンドリファレンス を参照してください。 まとめ このブログ記事では、AWS Config の定期的な記録を使用して、日次でリソースの最新の構成変更をキャプチャする方法について学びました。これにより、AWS Config によって検出される変更の数を削減できます。次に、AWS マネジメントコンソールと AWS CLI を使用して定期的な記録を設定する方法を学びました。AWS Config の設定レコーダーの詳細については、 設定レコーダーの管理 を参照してください。 著者について Abraham Musa Abraham は AWS の Cloud Foundations チームの Cloud Operations Specialist Solutions Architect でニューヨークを拠点に働いています。彼は AWS Control Tower、AWS Organizations、AWS Service Catalog や AWS Config に詳しいです。Abraham は元軍人で旅行が好きです。 Megan Velez Rivera Megan は公共領域のお客様を支援している Solutions Architect です。12 年以上の米国政府との協働経験から、Megan はお客様に複雑なクラウドインフラストラクチャの設計、実装、支援を行っています。彼女はお客様のクラウドオペレーションとオブザーバビリティ向上にも熱心に取り組んでいます。 Chris Sordan Chris はニューヨークを拠点にする Solutions Architect です。彼はエンタープライズのお客様に対し、設計上のベストプラクティスを使用してお客様の AWS 利用促進を支援しています。彼は革新的なソリューションを通じてお客様の技術的な目標を達成することに喜びを感じています。彼はジャズやスポーツイベントに参加することが趣味です。 Craig Edwards Craig Edwards はボストンを拠点とする AWS の Cloud Foundations チームと働く Cloud Operations Specialist Solutions Architect です。彼は AWS Config、AWS CloudTrail、AWS Audit Manager や AWS Systems Manager に詳しいです。Craig は元軍人で、父で、自転車に乗ることが好きです。 原文は こちら です。翻訳は SA 桂井が行いました。

NFTにおける画像生成 NFT(Non-Fungible Token)市場では、プログラムによって自動生成されたデジタルアート作品が多数取引されています。これらの作品はジェネラティブアートと呼ばれ、アルゴリズムを用いて無数のバリエーションの作品を生成することができます。 代表的な手法として、CryptoKittiesのようにキャラクターのパーツ(体、目、耳、尾など)を予め用意し、それらをランダムに組み合わせることで新しいキャラクターを生成する方法があります。この方法ではアーティストがルールを決めた上で、そのルールに基づいてさまざまなバリエーションの新しい画像をプログラムで作り出すことができます。最近では、DALL・EやStable Diffusionなどの生成AIを活用し、テキストのプロンプトからNFT用の画像を自動生成する試みも増えています。 NFT(Non-Fungible Token)は1点モノのデジタルアートであることが多く、多数のNFTを作成する場合は素材となる多様な画像が必要です。しかしアーティストにとって多数の画像を手作業で作成することは大きな負担です。 そこで注目されているのが、生成AIを活用した自動画像生成です。 本記事では、生成AIを使ったNFT用の大量画像生成の方法を解説します。 生成AIが持つ創造性を活用することで、効率的かつ魅力的なバリエーション豊かなNFT用の画像生成が期待できます。 Amazon Bedrockを用いたNFT用の画像生成 NFT用の向けに大量の画像を効率よく生成する手法としてお勧めするのが、Amazon Web Services が提供する Amazon Bedrock の生成AIを使用する方法です。 Amazon Bedrockはクラウド上で動作する生成AIの基盤モデルで、大規模言語モデルや画像生成モデルをAPI通じて呼び出せます。基盤モデルに対してテキストのプロンプトを入力することで高品質な画像を生成してくれます。NFT用の場合、コンセプトなどのテキストを入力することで、作品の世界観を反映した多様なバリエーション画像を大量生成できます。 Amazon BedrockとStable Diffusionを使用して生成した画像 Amazon Bedrockを使ってNFT用の画像を生成するには、まずコンセプトとなる入力画像を用意します。作品のイメージを決め、その世界観や構成を示した代表的な画像です。 この入力画像をbase64形式にエンコードし、テキスト形式のプロンプトと合わせてAmazon Bedrockに入力することで、画像の持つ特徴を生成AIに伝えられます。その結果、入力画像の世界観や構図を保ちつつ、プロンプトで指定した要素を含んだ新しい画像を生成できます。 AWS Step Functions Distributed MapとAmazon Bedrockを使用した大量生成 AWS Step FunctionsのDistributed Mapを使うと、Amazon Bedrockによる画像生成を並列で実行できます。これにより大量のバリエーション画像を効率的に生成できます。ただし、Amazon Bedrockにクオータの制限があるため、並列実行数は低めに設定しましょう。 Distributed Mapは、CSVやJSON等で定義された入力データを並列のブランチに分割して処理し、結果をまとめる機能です。NFT用画像を生成する場合、入力値であるプロンプト定義をJSON形式で事前に用意しておきます。プロンプト定義はプログラムを用いて、例えば「髪型をショートカットにする」「髪色を金色にする」「背景色を金屏風にする」などさまざまな要素を事前に用意し、乱数に基づいて選択すると思いもよらない組み合わせができて面白いかもしれません。 このようにプロンプトとAWS Step FunctionsとAmazon Bedrockを組み合わせることで、大量のバリエーションに富んだNFT用の画像を効率よく生成できます。 AWS Step Functionsに渡す入力値の例です. 使用する生成AIのモデルや入力画像を保存しているAmazon Simple Storage Service(Amazon S3)の情報も一緒に渡します。 id や rank といった情報を生成AIのseed値に変換して用いることでバリエーションを増やすこともできます。 [ { "id":"A1", "rank":"nomal","inputBucketName":"111122223333-aa-example-1-input-image-bucket", "inputKeyName":"image.jpeg", "model":"stability.stable-diffusion-xl-v0", "prompt":"hair color is brown, backglound color is white" }, { "id":"A2", "rank":"vip","inputBucketName":"111122223333-aa-example-1-input-image-bucket", "inputKeyName":"image.jpeg", "model":"stability.stable-diffusion-xl-v0", "prompt":"hair color is gold, backglound color is red" }, ] 大量に生成する場合、再現性を確保するためにプロンプトの管理や保存が必要となります。また、並列実行数の制御やエラーハンドリングなど、細かな制御を実装する必要が出てきます。AWS Step Functionsの Distributed Map を使用することで、プロンプトや入力値等のパラメータの管理は事前に作成したJSONファイルに、並列実行数の制御やエラーハンドリングはAWS Step Functionsに任せることができるため、エンジニアが実装する箇所を減らすことができます。 サンプルコード aws-samplesの nft-image-generator でサンプルコードを公開しています。これを使用することにより、AWS Step FunctionsとAmazon Bedrockを組み合わせたNFT用画像生成の仕組みを体験することができます。 環境構築の方法や使用方法についてはGithubのドキュメントを参照してください。 実際に生成した画像 冒頭で作成した画像を入力画像として使用し、複数のバリエーションを生成しました。キャラクターのイメージやコンセプト、世界観などを維持しながら、髪色や髪型、メガネの色や形などが少しずつ異なる画像に仕上がったと思います。 Amazon Bedrockを使用して入力画像をベースに生成した画像 まとめ NFT用の画像生成には、生成AIを活用することで効率的に多様なバリエーションを作り出すことができます。 今回使用したアセットはaws-samplesのnft-image-generatorで公開しています。NFT用の画像生成についてチャレンジしたい方はご活用ください。 深津 颯騎 Amazon Web Service JapanのBlockchain Prototyping Engineer. Blockchain, Web3に関わるお客様を中心に技術支援を行っています。

はじめに AWS CloudFormation を利用するお客様から、リソースプロビジョニングの内部処理や、 AWS マネジメントコンソール や AWS Command Line Interface(AWS CLI) と比べてリソースまたはスタックのプロビジョニングに時間がかかる理由について質問をいただくことがあります。 そこで、この記事ではCloudFormation におけるリソースのプロビジョニングに影響する様々な要因について述べます。記事では特に、 CloudFormation やその他のInfrastructure as Code (IaC) ツールが信頼性の高いデプロイを確実に行うためのリソースの安定化について詳しく説明します。 また、CloudFormation スタックのデプロイ時間を最大 40 % 短縮し、新しい CONFIGURATION_COMPLETE ステータスを通じてリソースのプロビジョニングの可視性を高める、新しい楽観的な安定化方式についても紹介します。 AWS CloudFormation は、テンプレートファイルで AWS リソースやサードパーティリソースをモデル化できる IaC サービスです。CloudFormation スタックを作成することで、AWS CLI、マネジメントコンソール、 AWS SAM を介して手動で、または AWS CodePipeline を介して自動的にテンプレートで定義したリソースをプロビジョニングし、ライフサイクルを管理できます (CLI と SAM も活用可能)。あるいは Git sync を介して自動化することも可能です。 また、 AWS Cloud Development Kit (AWS CDK) を使用して、使い慣れたプログラミング言語でクラウドインフラストラクチャを定義し、CloudFormation 経由でプロビジョニングすることも可能です。または、 AWS Application Composer を活用して、アプリケーションアーキテクチャを設計、依存関係を可視化し、CloudFormation スタックを作成するためのテンプレートを生成することもできます。 CloudFormation スタックのデプロイ AWS CloudFormation を使用したコンテナ化されたアプリケーションのデプロイを確認して、CloudFormation のリソースプロビジョニングを理解しましょう。 図 1. ECSサービスをデプロイするためのサンプルアーキテクチャ コンテナ化されたアプリケーションをデプロイするには、 Amazon ECS サービスを作成する必要があります。 ECS サービスを設定するには、ECS クラスター、 Amazon ECR リポジトリ、タスク定義、セキュリティグループやサブネットなどの関連する Amazon VPC インフラストラクチャが最初に存在する必要があります。 インフラストラクチャとアプリケーションのデプロイの両方を AWS CloudFormation で管理したいため、最初に以下を含む CloudFormation テンプレートを定義します。 ECS クラスターリソース ( AWS::ECS::Cluster )、タスク定義 ( AWS::ECS::TaskDefinition )、ECR リポジトリ ( AWS::ECR::Repository )、サブネット ( AWS::EC2::Subnet ) やセキュリティグループ ( AWS::EC2::SecurityGroup ) などの必要な VPC リソース。 そして最終的に ECS サービス ( AWS::ECS::Service ) 自体です。 このテンプレートを使用して CloudFormation スタックを作成すると、ECS サービス ( AWS::ECS::Service ) は、他のリソースの作成が完了するのを待つため最後に作成されます。このように、リソースには依存関係があります。 リソースの依存関係: CloudFormation では、リソースが先に作成される他のリソースと依存関係を持つことがあります。リソースの依存関係には 2 種類あります。 暗黙的: CloudFormation は、リソースが別のリソースを参照するために 組み込み関数 を使用する場合、依存関係を自動的に推測します。これらの暗黙の依存関係により、リソースが適切な順序で作成されます。 明示的: 依存関係は、 DependsOn 属性を使用してテンプレートに明示的に定義することができます。これにより、リソースの作成順序を調整できます。 次のテンプレートスニペットでは、ECS サービスの依存関係を依存関係グラフで可視化しています: テンプレートスニペット: ECSService: DependsOn: [PublicRoute] #明示的な依存関係 Type: 'AWS::ECS::Service' Properties: ServiceName: cfn-service Cluster: ! Ref ECSCluster #暗黙的な依存関係 DesiredCount: 2 LaunchType: FARGATE NetworkConfiguration: AwsvpcConfiguration: AssignPublicIp: ENABLED SecurityGroups: - ! Ref SecurityGroup #暗黙的な依存関係 Subnets: - ! Ref PublicSubnet #暗黙的な依存関係 TaskDefinition: ! Ref TaskDefinition #暗黙的な依存関係 依存関係グラフ: 図 2. コンテナ化されたアプリケーションのCloudFormationにおける依存関係グラフ 注: 上図の VPC リソースには、PublicSubnet ( AWS::EC2::Subnet )、SecurityGroup ( AWS::EC2::SecurityGroup )、PublicRoute ( AWS::EC2::Route ) が含まれています。 上のテンプレートスニペットでは、ECS サービス ( AWS::ECS::Service ) リソースは、DependsOn 属性を使用して PublicRoute リソースに対する明示的な依存関係を持っています。 ECS サービスには、ECSCluster、SecurityGroup、PublicSubnet、TaskDefinition リソースに対する暗黙的な依存関係もあります。 明示的な DependsOn がなくても、CloudFormation はこれらのリソースが ECS サービスから参照される前に作成される必要があるとわかります。これはサービスが Ref 組み込み関数を使用してこれらのリソースを参照しているためです。 テンプレートファイルの定義に基づいて CloudFormation がリソースを特定の順序で作成する方法を理解したので、これらのリソースをプロビジョニングするのにかかる時間を見てみましょう。 リソースプロビジョニング時間: CloudFormation がスタックをプロビジョニングするための総時間は、テンプレートで定義された各リソースを作成するのにかかる時間に依存します。リソースごとのプロビジョニング時間は、次のいくつかの時間要素によって決まります。 エンジン時間: CloudFormation エンジン時間とは、リソースに関連するデータの読み取りと保存にサービスが費やした時間を指します。これには、CloudFormation テンプレートの解析と解釈の時間、 Fn::GetAtt や Ref などの 組み込み関数 の解決にかかる時間が含まれます。 リソース作成時間: リソースを作成し構成するために AWS サービスが実際に必要とする時間です。これは、サービスがプロビジョニングするリソースの種類によって異なります。 リソース安定化時間: リソースが作成された後、利用可能な状態に達するまでに必要な時間です。 リソース安定化とは AWS リソースをプロビジョニングする際、CloudFormation は基盤となるサービスに必要な API 呼び出しを行い、リソースを作成します。作成後、CloudFormation はリソース安定化プロセスとして、リソースがトラフィックを処理する準備ができていることを確認するための最終的なチェックを実行します。例えば、アプリケーションで ECS サービスを作成した場合、作成完了直後 (作成時) にサービスをすぐに利用できるわけではありません。CloudFormation は、ECS サービスのリソースに特化した追加の検証チェックを実行することで、ECS サービスが利用可能であることを確認します。リソース安定化は CloudFormation に限った話ではなく、あらゆる IaC ツールで、ある程度の対応が必要になります。 安定化基準と安定化タイムアウト CloudFormation がリソースを CREATE_COMPLETE とマークするためには、そのリソースが 特定の安定化基準を満たす必要があります。この確認により、リソースが作成されただけでなく、使用可能な状態であることが検証されます。 リソースが許容される安定化タイムアウト期間内に、安定化基準を満たせない場合、CloudFormation はリソースの状態を CREATE_FAILED としてマークし、オペレーションをロールバックします。 安定化の基準とタイムアウトは、CloudFormation でサポートされている各 AWS リソースごとに、サービスによって独自に定義されており、リソースの作成と更新のワークフローの両方に適用されます。 AWS CloudFormation と AWS CLI によるリソースのプロビジョニング 次に、 AWS CLI を使って同様の ECS サービスを作成します。 以前 CloudFormation で作成したタスク定義、ECS クラスター、VPC リソースを使って、次の AWS CLI コマンドを実行すると ECS サービスをデプロイできます。 コマンド: aws ecs create-service \     --cluster CFNCluster \     --service-name service-cli \     --task-definition task-definition-cfn:1 \     --desired-count 2 \     --launch-type FARGATE \     --network-configuration "awsvpcConfiguration ={ subnets = [subnet-xxx],securityGroups = [sg-yyy],assignPublicIp = ENABLED }" \     --region us-east-1 以下の出力結果は、上記のコマンドによってECS サービスが正常に作成され、ステータスが ACTIVE になっていることを示しています。 図 3. ECSサービスに対するコマンド実行結果 しかし、ECS コンソールに移動しサービスを確認すると、タスクは Pending 状態のままで、アプリケーションにアクセスできません。 図 4. ECSコンソールの表示 サービスが安定した状態に至るのを待ってから、アプリケーションにアクセスする必要があります。 図 5. ECSサービスのイベント AWS CloudFormation を使用して同じ ECS サービスを作成する場合、リソースがスタックの CREATE_COMPLETE ステータスに達すると、すぐにサービスにアクセスできます。この確実な可用性は、CloudFormation のリソース安定化プロセスによるものです。 ECS サービスを初期作成した後、CloudFormation は待機し、サービスが安定するまでECS の DescribeServices API アクションを継続的に呼び出します。 ECS サービスがチェックに合格して使用準備が整ったら、そのときはじめて CloudFormation がスタックのリソース状態を CREATE_COMPLETE とマークします。 このような作成と安定化のオーケストレーションにより、遅延なくサービスにアクセスできるようになります。 次の出力は、 CloudFormation が安定化の間に DescribeServices API 呼び出しを行っていることを示す AWS CloudTrail のイベント履歴です。 図 6. AWS CloudTrailのイベント履歴 CloudFormationは、リソース安定化の処理を行うことで、リソース作成後のカスタムステータスチェックや可用性のポーリングロジックの実装に伴う余分なコーディング作業と複雑さを避けることが出来ます。この機能が無いと、AWS CLIやAPIなどのツールを使って、すべてのインフラストラクチャとアプリケーションリソースに対して追加のロジックを開発する必要があります。CloudFormationに組み込まれた安定化オーケストレーションを使えば、テンプレートを一度デプロイするだけで、作成後にサービスが完全に準備できていることを信頼できるため、アプリケーション機能の開発に集中できます。 安定化戦略の進化 CloudFormation の安定化戦略では、リソース作成と安定化プロセスが連動しているため、リソースのプロビジョニングが完了したと見なされるのは、安定化が完了した場合のみです。 従来の安定化戦略 相互に依存関係のないリソースについては、CloudFormation は同時並行でプロビジョニングを開始します。しかし、あるリソースが他のリソースに依存している場合、CloudFormation は依存先リソースのプロビジョニング操作が完全に終了するまで待ってから、依存リソースのプロビジョニングを開始します。 図 7. CloudFormationの従来の安定化戦略 上の図は、AWS CloudFormation を使用してデプロイする一部の ECS アプリケーションリソースのデプロイを示しています。Task Definition (AWS::ECS::TaskDefinition) リソースは ECR Repository (AWS::ECR::Repository) リソースに依存しています。また、ECS Service (AWS::ECS:Service) リソースは Task Definition と ECS Cluster (AWS::ECS::Cluster) の両方のリソースに依存しています。ECS Cluster リソースには依存関係は定義されていません。CloudFormation は ECR Repository と ECS Cluster リソースの作成を並列で開始します。その後、Task Definition リソースのプロビジョニングを開始する前に、ECR Repository が整合性チェックを完了するのを待ちます。同様に、ECS Service リソースの作成は、Task Definition と ECS Cluster リソースが作成され、準備ができた後にのみ開始されます。この順次的なアプローチは安全性と安定性を確保しますが、遅延が発生します。CloudFormation は厳密に依存するリソースを順番に 1 つずつデプロイするため、全体のスタックのデプロイが遅くなります。相互に依存するリソースの数が増えると、全体のスタックデプロイ時間が長くなり、ボトルネックが発生し、スタック全体の操作が遅くなります。 新しい楽観的な安定化戦略 スタックのプロビジョニング時間とデプロイのパフォーマンスを改善するため、AWS CloudFormation は最近、新しい楽観的な安定化戦略を導入しました。 この戦略により、お客様のスタックデプロイ時間を最大40%短縮できます。依存リソースを並列に作成できるようになり、これによりデプロイ速度が大幅に向上します。 図 8. CloudFormationの新しい楽観的な安定化戦略 上の図は、過去の戦略で説明した同じ 4 つのリソースのデプロイを示しています。Task Definition (AWS::ECS::TaskDefinition) リソースは ECR Repository (AWS::ECR::Repository) リソースに依存し、ECS Service (AWS::ECS::Service) リソースは Task Definition と ECS Cluster (AWS::ECS::Cluster) の両方のリソースに依存しています。 ECS Cluster リソースには依存関係の定義がありません。 CloudFormation は、ECR Repository と ECS Cluster リソースの作成を並列で開始します。 その後、ECR Repository が安定化するのを待たずに、ECR Repository の作成が完了したら Task Definition の作成を開始します。 同様にECS Service リソースの作成は、Task Definition と ECS Cluster の作成が完了した後に開始されます。 この変更は、すべてのリソースが依存リソースの安定化を待つ必要がないためです。 もしTask Definition または ECS Cluster リソースの安定化が完了していないことで ECS Service のプロビジョニングが失敗した場合は、CloudFormation がその依存関係の安定化を待ってから、ECS Service の作成を再試行します。 図 9. CloudFormationの新しい安定化戦略での再試行 暗黙的な依存関係を持つリソースの作成ワークフローでは、この依存リソースの並列作成と自動再試行機能により、従来の直列リソースプロビジョニング戦略に比べてデプロイ時間が短縮されます。 なお明示的な依存関係を持つリソースについては、CloudFormation が従来の戦略を利用してリソースをデプロイします。 リソースプロビジョニングの可視性向上 CloudFormation スタックを作成するとき、リソースのプロビジョニングに時間がかかり、IN_PROGRESS 状態が継続しているように見える場合があります。これは、CloudFormation がリソースの安定化を待機しているためです。 リソースのプロビジョニング状況の可視性を改善するために、CloudFormation は新しい CONFIGURATION_COMPLETE イベントを導入しました。 このイベントは、作成ワークフローの中でリソースの作成または設定が完了したが、安定化プロセスがまだ進行中のときに、個々のリソースレベルと全体のスタックレベルの両方で発行されます。 図 10. ECSアプリケーションのCloudFormationスタックイベント 上の図は、ECSApplication という名前の ECS アプリケーションの CloudFormation スタックについて、スタックイベントの出力結果を示しています。 イベントを下から上へ確認してみましょう。 10:46:08 UTC-0600 – ECSService (AWS::ECS::Service) リソースの作成が開始されました。 10:46:09 UTC-0600 – ECSService はステータスタブで CREATE_IN_PROGRESS ステータス、詳細ステータスタブで CONFIGURATION_COMPLETE ステータスとなり、リソースが正常に作成され、整合性チェックが開始されました。 10:46:09 UTC-0600 – スタック ECSApplication はステータスタブで CREATE_IN_PROGRESS ステータス、詳細ステータスタブで CONFIGURATION_COMPLETE ステータスとなり、ECSApplication スタック内のすべてのリソースが正常に作成され、安定化処理が行われていることを意味します。 このスタックレベルの CONFIGURATION_COMPLETE ステータスは、スタックの概要タブでも表示できます。 図 11. ECSApplicationスタックの概要 10:47:09 UTC-0600 – ECSService のステータスタブに CREATE_COMPLETE ステータスが表示されており、サービスが作成され、整合性チェックが完了したことを意味します。 10:47:10 UTC-0600 – ECSApplication のステータスタブに CREATE_COMPLETE ステータスが表示されており、すべてのリソースが正常に作成され、整合性チェックが完了したことを意味します。 結論: この記事では、CloudFormationがリソースをデプロイする方法と、スタックおよびそのリソースの作成に影響する様々な時間要因について理解を深めていただけたと思います。また、リソース安定化のために CloudFormation が内部で行っていることと、可用性の高い本番インフラストラクチャのデプロイメントで、リソースを安全かつ確実にプロビジョニングする方法について詳しく見てきました。最後に、スタックのデプロイ時間を短縮し、リソースのプロビジョニングの可視性を向上させる新しい楽観的な安定化戦略についても解説しました。 本記事は、Bhavani Kanneganti と Idriss Laouali Abdou による How we sped up AWS CloudFormation deployments with optimistic stabilization を翻訳したものです。翻訳はソリューションアーキテクトの木村友則 ( @tkimurz ) が担当しました。

製造業の様々なお客様は、デジタル変革のジャーニーのそれぞれに異なる段階にあるため、変革プロセスにどのように取り組むかについても異なった志向を持っています。 製造業のお客様はデジタル変革を加速するため、データから洞察を引き出しビジネス成果を実現することに注目してますが、こうしたことは、データレイク、IoT(モノのインターネット)、機械学習(ML)、人工知能(AI)などのテクノロジーによって、これまでになく簡単になりました。製造業のお客様は、データから洞察を引き出し、ビジネス成果を実現することで、デジタル変革を加速したいと考えています。さらに、生成AI、デジタルツイン、デジタルエンジニアリングなどのテクノロジーは、昨今、製造業界を席巻しています。 このブログでは、2024 年の製造業イノベーションの 3 つのトレンドである、生成 AI、デジタルツイン、デジタルエンジニアリングと、これらのテクノロジーをクラウドで活用することが、製造業のお客様のイノベーションを推進するのにどう役立つかを紹介します。 １：製造業における生成AI Precedence Research によると、2032 年までに製造業界で AI に費やされる金額は 684 億ドルに達すると推定されています。これは今後 9 年間で約 33.5 %の投資の増加に相当します。このような投資の増加には、企業全体で生成 AI 技術が採用されつつあることが影響しています。生成 AI は、製造企業がより効率的に事業を運営できるようにし、製品開発と生産を加速し、設備の寿命を延ばし、装置のダウンタイムを短縮し、生産設備の効率を向上させます。例えば製造業における 3 つの一般的な生成 AI アプリケーションには、設備マニュアルや各種社内文書の要約、自然言語による製品検索、設備の異常の解決などがあります。 設備マニュアルや各種社内文書の要約 Retrieval Augmented Generation(RAG) などの技術を使用することで、企業は社内文書や設備マニュアルへのアクセスを大規模言語モデル(LLM)に提供できるようになり、従業員が会社の方針、設備の構成、故障の解決手順に関する情報をより迅速に見つけるのに役立ち、生産性が向上します。 さらにRAG は、これまで手動で作成されていたドキュメントを企業の内部情報を使用して自動的に作成する機能を提供します。 従業員はさまざまなコンテキストにわたる質問をすることができます。 たとえば、「溶接機の空気圧ゲージが壊れました。どう修理したらよいでしょうか?」という質問は、溶接機のマニュアルから生成した修理手順の説明を返します。 「次の 20 個の製品の部品表(BOM)を生成してください」というリクエストを入力すると、内部データベースから各製品の価格が引用されたBOMが生成されます。「近々休暇があるのですが、会社の有給休暇の方針は何ですか?」と言えば、企業の文書を元にした回答が得られます。 このRAGアプリケーションは、1 週間以内にセットアップでき、生産性にすぐに良い影響を与えるため、企業が最初に実施するケースであることが多いです。 このソリューションを構築するための例となるアーキテクチャは、 AWS ソリューションライブラリ の Generative AI Application Builder on AWS ソリューションの「Text Use Case」セクションにあります。ビジネスとテクニカルなユースケースのために検証されたソリューションとガイダンスです。訳者補足：日本語で利用可能ですぐにデプロイできるリソースとして、 Generative AI Usecases JP があります。 自然言語による製品検索 自然言語による製品検索を使うと、企業の従業員や顧客が、会社の製品に関する情報を検索できるようになり、顧客体験が向上し、一度の検索で正しい製品を見つけることができます。「2010 年型のダッジ・チャージャーを持っています。取り付け労力が最も低く、現在在庫がある部品で馬力を上げるにはどうしたらいいですか?」「X 冷蔵庫を持っています。どのような間仕切りが中に収まりますか?」「配電盤 X 用の遮断器が必要です。現在の在庫にはどのようなものがありますか?」といった質問に、今ではすぐに答えることができます。この情報へのアクセス向上により、製品の返品率が下がり、顧客一人ひとりのニーズに合った最適な製品を受け取れるため、製品の評価が上がる傾向があります。情報が様々な場所に保存されている場合、LangChain などのツールやライブラリを使用して、様々なソースから情報をクエリすることができます。詳細なソリューションは、AWS Machine Learning ブログの投稿「 Reinventing the data experience: Use generative AI and modern data architecture to unlock insights. 」で見つけることができます。 設備の異常の解決 最近では、設備をモニタリングするためにセンサーを使用している製造企業は、エラーをより迅速に修復し、ダウンタイムを短縮するために生成 AI を利用し始めています。 センサーが設備のエラーを予測または検出した場合、エラーメッセージが LLM に送信され、LLM は設備の保守マニュアルにアクセスできるようにし、エラーを修正または防止するために必要な手順を生成し、この情報をオンサイトのエンジニアに送信して修復を促します。 ダウンタイムの短縮により、すべての製造プロセスが予定通りに進行し、顧客への出荷遅延の影響を最小化します。 設備の異常の解決ソリューションは、マニュアル要約ソリューションと同様のアーキテクチャを利用する一方で、デバイスをクラウドに簡単かつ安全に接続できるサービスである AWS IoT Core も利用します。 ２：デジタル設計による製品開発の効率化 現代の製品設計には、高度なデータ保存、コンピューティング、コラボレーションが必要です。多くの製造企業が、研究開発コストの削減、市場投入までの時間短縮、生産効率の最適化、サステナビリティ目標の達成、新たな収益源の創出のために、デジタルエンジニアリングの活用を検討しています。AWSのお客様がデジタルエンジニアリングを活用している主な 4 つの分野は、計算機援用工学(CAE)、製品データおよび製品ライフサイクル管理(PLM)、コンピュータ支援設計(CAD)、電子設計自動化(EDA)です。 計算機援用工学(CAE) CAE は、製品設計の改善や幅広い産業分野における工学的問題の解決を支援する目的で、コンピューターソフトウェアを使用して性能をシミュレーションします。 CAE が対応するプロセスには、製品、プロセス、製造装置のシミュレーション、検証、最適化が含まれます。 製造業のお客様は、ますます複雑な設計や検証における課題に直面しています。 製造や設計で使用されるアプリケーションには、数値流体力学(CFD)、有限要素法(FEM)、電磁気および熱シミュレーション、設計最適化/ジェネレーティブデザイン設計、衝突/マルチフィジックス/マルチボディシミュレーションなどがあります。 これらの問題を解決し、ユースケースをサポートするために、多くのお客様は、 AWS Batch などのAWSサービスの助けを借りて、AWS クラウドでコンピューティングを大規模に利用しています。AWS Batch は、あらゆる規模のバッチ処理・MLモデルトレーニング・分析を提供し、 AWS ParallelCluster は、AWS上に高性能コンピューティング(HPC)クラスタを簡単にデプロイ・管理できるオープンソースのクラスタ管理ツールです。たとえば、主要な医薬品の製造販売企業である Amgen は、これらのソリューションを通じて、計算流体力学シミュレーションを実行するためのプラットフォームを提供し、科学者・エンジニアの利用とデータの量の大幅な急増を目の当たりにしました。 Amgen のプリンシパルデータエンジニア(情報システム部のシニアマネージャー)の Justin Porth と、Amgen の情報システム部のディレクターである Venki Anantharam は、「このイニシアチブの一環として Amgen の HPC の能力向上は、情報システム整備計画と設計標準に完全に合致したものです 」と述べています。CAE の AWS ソリューションの詳細については、AWSソリューションライブラリの Scale-Out Computing on AWS ソリューションをご覧ください。 製品ライフサイクル管理(PLM) PLM は、製品開発に関連するコスト、時間を削減し、リスクを低減するのに役立ちます。AWS 上の製品ライフサイクル管理(PLM)ソリューションは、可用性性とコンプライアンスの要件を満たしながら、PLM パフォーマンスを向上させ、データサイロ化を脱却するのに役立ちます。製造業のお客様は、この分野でしばしば3つの大きな課題に直面します。性能・拡張性、データの不適合、グローバルでの協働です。 これらの課題を解決するために AWS ソリューションを利用する顧客は、次のようなメリットが期待できます。(1)意図せぬ開発工程の繰り返しを避け、市場投入までの時間を改善する。(2)イノベーションや検証のためのエンジニアリングに費やす時間が短縮される。(3)作業のやり直しを減らして品質が向上する。 Rivian の CIO である Madhavi Isanaka は、「AWS とパートナーシップを結ぶことで、Rivian は ITではなく、持続可能な製品データとライフサイクル管理、デリバリーに集中できるようになりました。そして私たちは AWS上では、重要な開発アプリケーションをオンプレミスよりも高速で実行しています。Elements は 56 %高速、Siemens は 35 %高速、Ansys は 20 %高速です」と述べています。 PLM を効率化するために AWS サービスの利用を開始するには、AWS ソリューションライブラリの PLM ソリューション をご覧ください。 コンピュータ支援設計(CAD) コンピュータ支援設計(CAD) とは、コンピュータを使用して設計情報の作成、変更、分析、最適化を支援することです。製造業の顧客は、リモートワークが研究開発者や研究開発チームの恒久的なソリューションになったことで、協調作業に関する課題が増加し、設計がますます複雑になる問題に直面することがよくあります。同時に、産業界の顧客は、製品をより速く市場に出すプレッシャーにさらされ、設計の再利用性を高めながらコストを削減する必要があります。 研究開発チームが新製品の導入に伴うコスト、時間を減らし、リスクを低減するのを助けるために、多くのお客様が Amazon AppStream 2.0 のようなアプリケーションストリーミング、 Amazon WorkSpaces のようなデスクトップのストリーミングの AWS マネージドサービスを使用しています。AppSteam2.0 は、アプリケーションへの安全で信頼できるスケーラブルなアクセスをどの場所からでも提供します。また、WorkSpaces は、あらゆる設計者のための包括的な機能を持ち、永続的に利用可能な仮想デスクトップです。 Onshape の技術運用担当副社長の John Rousseau は、「Onshapeは2013年からAWSを使用してCADサービスを提供してきました。その間ずっと、AWS を選択したことを疑ったことは一度もありません。AWSのサービスのグローバルな信頼性により、私のチームは Onshape の顧客体験の改善に集中することができます。AWSの セキュリティインフラとツールは、顧客のデータを保護するのに大いに役立ちます」詳細は、AWS ソリューションライブラリの エンジニアリングデザインアプリケーションとデスクトップのソリューション をご覧ください。 電子設計自動化(EDA) 電子設計自動化(EDA) は、集積回路やプリント回路基板などの電子システムを設計するためのソフトウェアツールのカテゴリーです。ますます複雑化するチップとシステム・オン・チップ(SoC)製品は、より大きな処理能力、メモリ、ストレージを必要としています。これは HPC の必需であることを意味します。AWS クラウド上に導入された EDA は、半導体サプライチェーン全体にまたがったこうした課題に対処するのに役立っています。 Arm のデザインイネーブルメント担当副社長 Philippe Moyer は、「AWS を使用することで、EDA ワークロード特性分析の実行時間は数ヶ月から数週間に短縮された」と述べています。 AWS 上の EDA ソリューションの詳細については、AWS ソリューションライブラリの ハイテクエレクトロニクスと半導体のソリューション をご覧ください。 3：デジタルツインによるパフォーマンスの最適化 製造業の顧客がイノベーションを起こしているもう 1 つの方法は、デジタルツインを使用して製造環境をモデル化することです。デジタルツインへの投資は引き続き増加しています。 MarketsandMarkets のレポートによると、デジタルツインの市場規模は 2023 年から 2028 年の間に年率61.3%で成長し、最終的には 1,101 億ドルの価値になると予測されています。これは、組織が運用効率の向上、ダウンタイムの削減、メンテナンスの改善などの可能性を認識しているため、製造業を含むさまざまな業種におけるデジタルツインの採用が増加していることを示してしています。 デジタルツインは、実世界の装置をその機能、特徴、動作とともに仮想環境でデジタル的に再現します。これは、リアルタイムで収集したスマートセンサーからのデータを使用して、物体の動作をシミュレートし、運用を監視することによって実現されます。デジタルツインは、個々の機械、生産ライン、エンドツーエンドの製造環境を再現できます。ユーザーはこれらの環境とのやりとりがリアルタイムで可能です。対象をリアルタイムでデジタル的にモデリングすることで、ビジネス価値を引き出す機会が開かれます。例えば、予測機能、パフォーマンスの微調整、遠隔監視とチューニング、効率性の向上などが含まれます。 製造業の企業は、イノベーションを推進し、運用能力を強化するためにデジタルツインに投資しています。例えば、 Siemens はデジタルツイン技術の可能性を認識し、その開発に多額の資金を注いでいます。物理的な設備のデジタル上の複製を作成することで、Siemens はその資産のパフォーマンスをシミュレートおよび最適化でき、品質と効率の向上につながります。例えば、 General Electric(GE) は、風力タービンのデジタルツインを使用しています。この技術は、予知保全機能とリアルタイムのパフォーマンス監視を実現しています。風速、発電量、温度、コンポーネントのストレスなどの情報が継続的に収集され、ほぼどこからでも監視できます。これにより、風の条件に基づく発電量など、さまざまなシナリオを関連チームが検討できるようになり、現場のエンジニアがタービンをより効率的に操作できるようになります。また、タービンと風車の群の生産性の追跡、予知保全の実施も容易になります。Siemens や GE による注目すべきこのような投資は、デジタルツインが製造業における運用上の優秀性を推進する戦略的ツールとして活用する重要性が高まっていることを浮き彫りにしています。 設計から生産準備までのプロセス最適化 データを連続的に取得することで、パフォーマンスと効率に関連するツール、在庫、データに関するリアルタイムに近い洞察を提供します。 最新のデータを手元に置くことで、ユーザーはパフォーマンスを最適化するのに役立つ意思決定を迅速に下すことができます。 これはまた、問題がより早く検出され、対処されることを意味します。その結果、設備と生産ラインのダウンタイムを短縮できます。 さらに、最新のデータにアクセスできることで、企業はリスクをより適切に評価し、より良い情報に基づいた運用上の意思決定を下すことができます。 例えば、上述のように、GE は 物理センサーからAWS 上でのデータの収集と分析を容易にするために、風力タービンのデジタルツインを使用しています。これにより、タービンの運用をリアルタイムに近い状態で分析して効率を上げることができます。 デジタルツインは「もし起こったら」というシナリオを実行し、出力、効率、ビジネスの結果にかかわるKPI の変更をモデル化するためにも使用できます。 GE は、発電出力に風がどのように影響するかなど、さまざまな「もしも」シナリオを検討するためにデジタルツインを使用しています。これにより、エンジニアはタービンをより効率的に運用できます。 例えば、今日の自動車業界では、新しい車の開発はほとんどが仮想環境で行われており、多くの企業がプロトタイプのデジタルツインを使用して設計を精緻化しています。ツインは通常、車のソフトウェア、機構、電装、物理的な動作を含む車両全体を対象とします。このモデリングにより、実際の部品を製造する前に、開発の各段階で問題を特定し、不具合の可能性を発見するシミュレーションや検証が可能になります。 たとえば物質の振る舞い、空気の流れ、熱の発生と蓄積を最適化することで、車の 3D データを使用して物理的な動作を模倣できます。 この方法を適用することで、企業は原寸大の試作車の数を減らすことができ、時間と費用を節約できます。 加えて、異なる分野の個人が同じプロジェクトで同時に作業できるようになり、異なる製品バージョンの構成が簡略化されます。 最後に、必要な設備を選択し、生産セルをデジタルで設計することで、すべての部品が製造セルでどのように組み合わさるかをシミュレートできます。 予知保全 デジタルツインは、機器のパフォーマンスに関するリアルタイムに近い洞察を提供することにより、製造業における設備保全を革新しており、コストのかかるダウンタイムを防ぐための予防保全を促進しています。 物理的な設備の仮想レプリカを作成することにより、企業は設備の運用を監視して、悪化する前に問題を特定し、操業の中断を最小限に抑えるために最適な時期にメンテナンスをスケジュールすることができます。 この予知保全アプローチは、設備の寿命を延ばすだけでなく、全体的な保守コストを削減して、運用効率と生産性を向上させます。 遠隔監視 デジタルツインは、遠隔監視を容易にします。これにより、製造業の企業は世界のほぼあらゆるところから資産を監視できるようになります。リアルタイムに近いデータの収集と分析により、企業は機器のパフォーマンスを評価し、非効率な箇所を特定し、生産プロセスを最適化するためにデータドリブンな意思決定を行うことができます。 さらに、リモートモニタリングにより、チームは問題に迅速に対応するツールを手に入れ、現地での調査の必要性を減らし、製造現場の全体的な安全性を向上させます。 結果として、デジタルツインを用いた予知保全とリモートモニタリングの採用が大幅に増加しており、企業はこのテクノロジーによる大幅なコスト削減と運用上のメリットを認識しています。 化学メーカーの INVISTA は、 AWS IoT TwinMaker を使用して製造環境をリモートで監視しています。INVISTA のオペレーション・トランスフォーメーション担当副社長 Jerry Grunewald は、「INVISTA は AWS IoT TwinMaker を利用して、複数の分散した場所の工場フロアからの運用に伴う通知と警告に、現地作業員が効率的に対処できるようにしています。 AWS IoT TwinMaker を使用することで、製造運用のデジタルツインを早く簡単に構築して、現地作業員に資産と運用データの統合ビューを提供できます。 このようにすることで、INVISTA の運用は、変革努力の結果としての『コネクテッドワーカー』のビジョンに向けて大きな進歩を遂げています。 たとえば、現地作業員は機器の異常の原因を特定し、適切な修正措置を特定することができます」 AWS IoT TwinMaker により、既存のデータソースを使用して、物理的な環境の仮想表現を作成できるため、お客様はデジタルツインのメリットを活用できます。 結論 製造業のイノベーションは、生成AI、デジタルツイン、デジタルエンジニアリングなどの技術の進歩によって加速しています。企業は、より速く効率的な製品開発、運用効率の向上、コストとリスクの削減などのメリットを享受しています。これらの分野への投資と採用は引き続き増加し続けていますが、製造企業はこれらのテクノロジーを活用して、業務をさらに革新させていくでしょう。全体として、製造業はクラウドを活用したイノベーションによって生産性、サステナビリティ、競争優位性を推進することができるのです。 AWS が製造業のお客様のイノベーションをどのように支援しているかをもっと知りたい場合は、AWS ソリューションライブラリの 製造および産業向けソリューション をご覧ください。また、これらのトレンドの実装にご興味がある場合は、AWS アカウントチームにお問い合わせください。 この投稿は「 Three trends in manufacturing innovation for 2024 」をAWS Japan SAの河村 聖悟、岩根 義忠が翻訳しました。 著者紹介 Brendan Jenkins Brendan Jenkins はソリューションアーキテクトであり、AWS の大企業のお客様を対象に、技術的なガイダンスを提供し、お客様のビジネス目標の達成を支援しています。専門は DevOps と機械学習テクノロジーです。 Andrew Walko Andrew Walko は AWS のソリューションアーキテクトで、自動車および製造業界の企業顧客を担当しています。データ分析、機械学習、人工知能の経験を持つ Andrew は、データを活用して顧客がビジネスを近代化できるよう支援しています Kait Healy Kait Healy は AWS のソリューションアーキテクトです。彼女は製造企業のお客様との連携を専門としており、主要なビジネス成果を促進するための機械学習と人工知能ソリューションの構築経験があります。 Michel Ngando Michel Ngando はソリューションアーキテクトであり、AWS の大企業のお客様を支援して技術ガイダンスを提供し、ビジネス目標の達成を支援しています。  

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週も 週刊AWS をお届けします。 2週前から、 週刊AWS のOGP（SNSでシェアされたときや、ブログ一覧画面で表示される写真）がメンバー4名のものに更新されているのに気づいていただけたでしょうか？去年の夏ごろから4名体制になっていたのですが、先日ようやく4名で写真を撮ることができました。色々な面白い（？）OGPを用意していますので、こちらもお楽しみに。 さて、以前にQuickSightのコミュニティサイトで 日本語でディスカッションできるタグができたこと はお知らせしましたが、合わせてQLS(QuickSight Learning Series)と呼ばれる新機能等を解説するオンライン勉強会も日本語版が提供されることになりました。4月にその第一回が開催されます。QuickSightを利用中の方はぜひチェックしてみてください。 – QLS:新機能とデモ：バックアップとリストア機能でアセットを効率的に管理する それでは、先週の主なアップデートについて振り返っていきましょう。 2024年3月11日週の主要なアップデート 3/11(月) Amazon RDS for Db2 expands support for X2iedn instances in additional regions Amazon RDS for Db2 で X2iedn インスタンスが利用可能なリージョンが拡大され、東京・大阪両リージョンでも利用可能になりました。X2iednは高いコンピューティング能力(最大128 vCPU)、大容量メモリ(最大4 TB)、高いストレージスループット(最大256K IOPS)、32:1のメモリ対vCPU比を提供するように設計された、大規模DB用途に向いたインスタンスです。 Amazon Verified Permissions increases default quotas for authorization APIs Amazon Verified Permissions で、IsAuthorized APIとIsAuthorizedWithToken APIのデフォルトの処理能力クオーター(TPS)が30から200に引き上げられました。これらのAPIは名前の通りユーザーの認証とアクションの承認するために呼び出されるもので、より大規模な環境でも利用しやすくなりました。 CloudWatch Container Insights now delivers observability for NVIDIA GPUs on EKS Amazon CloudWatch Container Insights with Enhanced Observability for EKS がクラスター上のNVIDIA GPUに対して、observability (観測性)を提供するようになりました。この機能はCloudWatch Observability Add-on をクラスター上に導入することで利用可能です。これにより、GPU利用率やメモリの使用率の観測が容易になり、分散トレーニング時にリソースが効率的に利用されているかを確認しやすくなります。 Experience up to 40% faster stack creation with AWS CloudFormation AWS CloudFormation でスタック作成のスピードが最大40%速くなる改善が行われました。これまでスタックのイベントとしては CREATE_IN_PROGRESS と CREATE_COMPLETE のみでしたが、新たに CONFIGURATION_COMPLETE が導入されました。これはAWSサービスとの整合性チェックが完了するのを待ち始めたことを表すものですが、これを利用して CREATE_COMPLETE を待たずに依存するリソースのプロビジョニングを開始することができるようになりました。これにより待ち時間が減り、スタック作成が高速化されます。 3/12(火) Operationalize forecasting models and Fine-tuned FMs with SageMaker Canvas Amazon SageMaker Canvas と SageMaker Model Registry との統合が拡張され、時系列予測モデルと SageMaker JumpStart を利用したファインチューニングされた基盤モデル(FM)を利用するよう拡張されました。これによりワンクリックで、Amazon SageMaker Canvas で構築されたこれらの ML モデルを SageMaker Model Registry 登録することができ、本番環境へのデプロイを簡素化します。 AWS Backup now supports restore testing for Amazon Elastic Block Store (EBS) Snapshots Archive AWS Backup が Amazon EBS Snapshotからのリストアのテストをサポートしました。これにより、AWS Backup でバックアップ対象のAWSリソースに対し、容易にリストアのテストをしたり、テストの自動化が可能になります。 3/13(水) Amazon S3 Connector for PyTorch now supports writing checkpoints with PyTorch Lightning Amazon S3 Connector for PyTorch で、PyTorch Lightning モデルのチェックポイントをAmazon S3に直接保存することをサポートしました。これによりトレーニングジョブのコストとパフォーマンスを改善します。PyTorch Lightningは、PyTorchによるトレーニングのためのハイレベルなインターフェースを提供するOSSのフレームワークです。これまでのように、Amazon EC2インスタンスストレージにいったん保存する方式よりも最大40%高速になることが期待できます。 Amazon EFS now supports up to 20 GiB/s of throughput Amazon Elastic File System（Amazon EFS）は、フルマネージドのNFSサービスです。今回ファイルシステムあたりのスループットを、読みとりを最大 20 GiB/sに、書き込みを最大 5 GiB/sにそれぞれ性能向上させました（以前はそれぞれ10 GiB/sと、3 GiB/sでした）。先日、 EFSの機能解説動画と資料が公開された ので、こちらも合わせてご覧ください。 3/14(木) Anthropic’s Claude 3 Haiku Model now available on Amazon Bedrock Anthropic の基盤モデル(FM)である Claude 3 Haiku が Amazon Bedrock で利用可能になりました。Claude 3 ファミリー（Claude 3 Opus、Claude 3 Sonnet、Claude 3 Haiku）は、Anthropic の次世代の最先端モデルであり、その中でも Haiku は高速なレスポンスを提供するのが特徴です。詳細は こちらのブログをご覧ください 。これにより、Cloud 3 ファミリーのうち、SonnetとHaikuがBedrock上で利用可能になりました。なおOpusも近日の提供開始が予告されています。 Application Load Balancer enables configuring HTTP client keepalive duration Application Load Balancer (ALB)で、クライアントとロードバランサー間の通信における HTTP Client Keepalive の時間を設定できるようになりました。HTTP Client keepaliveはALBがクライアントとのHTTP接続を維持する最大時間を指定するもので、最小60秒から最大7日間の値を設定できるようになりました（デフォルトは3600秒です）。 3/15(金) Amazon Timestream for InfluxDB is now generally available Amazon Timestream for InfluxDB が一般提供開始(GA)になりました。東京リージョンでもすでに利用可能です。フルマネージドのInfluxDBサービスであり、InfluxData社とAWSとのパートナーシップにより実現しました。また、これまでのAmazon Timestreamは、Timestream for LiveAnalyticsという名前になり、InfluxDBと平行して選択可能になっています。詳細は こちらのブログをご覧ください 。 Amazon CloudWatch Synthetics now supports 30-day historical data on canary runs Amazon CloudWatch Synthetis はWeb アプリケーションやAPI を簡単に監視できるようにするサービスで、エンドポイントの継続的なテストを実現します。今回そのテスト(Canary run)の結果を履歴として最大30日間保存可能に拡張しました（以前は最大7日間でした。この履歴には実行時のスクリーンショット、HARファイル、ログファイルなどが含まれます。 最後に2つ紹介させてください。1つ目は株式会社明治が、30年基幹システムで使ってきたメインフレームのワークロードをAWSにマイグレーションしたという事例です。 AWS Mainframe Modernization というメインフレームのモダナイゼーションを支援するための仕組みを活用されたもので、食品業界だけでなく、多くの日本企業に参考になる事例ではないかと思います。 – 株式会社 明治、老朽化した基幹システムをクラウドで近代化　AWS Mainframe Modernizationを活用した日本国内初のお客様に もう1つは、IBM Db2 をAWSにマイグレーションを検討される方向けのオンラインセミナーです。私も久しぶりにセミナー講師をやる予定です。オンプレミス上でDb2を利用している方はぜひご参加ください。AWSの基本的な部分からご説明する内容になっています。4月11日午前10時～12時の予定です。 – IBM Db2 の資産を AWS で活用する ~ Amazon RDS for Db2 の概要とマイグレーション支援サービス ~ それでは、また来週！ ソリューションアーキテクト 下佐粉 昭 (X/twitter – @simosako )

この投稿はアクセンチュア株式会社 テクノロジーコンサルティング本部所属の金　敬源氏と、マネージャー 竹内 誠一 氏に、Amazon Connect と Amazon Bedrock を活用したチャットボット構成におけるタイムアウトの制約とその回避策について寄稿いただいたものです。 はじめに このブログでは、Amazon Connect と Amazon Bedrock を活用したチャットボットの構成におけるタイムアウトの制約とその回避案について紹介します。 以下は、このブログの構成です： 背景 チャットボット構成と制約 タイムアウト回避のアプローチ タイムアウトの回避策 結論 背景 あるクライアントから、「Amazon Bedrock を活用してチャットボット回答の作成・メンテナンスの手間を減らしたい」「Amazon Bedrock の回答に納得できない場合はコンタクトセンターのオペレータとリアルタイムでチャットしたい」という要件をいただき、新たなチャットボットのプロトタイプを作成しました。 このプロトタイプの特徴は以下の通りです: Amazon Bedrock を活用してチャットボット回答の作成・メンテナンスの手間削減 検索拡張生成 (RAG、Retrieval Augmented Generation) と呼ばれる手法を採用 データストア として Amazon Kendra を活用 Amazon Bedrock のモデルとして Anthropic Claude 2 を活用 Amazon Bedrock の回答に納得できない場合はコンタクトセンターのオペレータとリアルタイムでチャット コンタクトセンター・ソリューションとして Amazon Connect を活用 チャットボットからオペレータへの引き継ぎを Amazon Connect のコンタクトフローで実装 データストアとして Amazon Kendra を採用した検索拡張生成(RAG)である点が大きな特徴ですが、その技術的な要点についてはこちらの AWS ブログを始めとして多くの解説記事がありますので、本ブログでは省略します。 [ 高精度な生成系 AI アプリケーションを Amazon Kendra、LangChain、大規模言語モデルを使って作る ] このプロトタイプではチャットボットの応答のタイムアウトが課題となったのですが、Amazon Connect 固有の制約によるものなので一般にはあまり知られていないと思います。本ブログではこの課題と回避策に焦点をあてて私たちの知見を紹介します。 チャットボットの構成と制約 今回のチャットボットのアーキテクチャは以下の通りです。 図1. Amazon Connect と Amazon Bedrock を活用したチャットボットのアーキテクチャ（タイムアウト回避策実装前） 質問者からの入力テキストは一旦 Amazon Connect が受信し、状況に応じてチャットボットやオペレータに転送します。Amazon Connect では、電話やチャットの着信があった時、その処理の流れを定義するコンタクトフローがあります。コンタクトフローのブロックの1つに「顧客の入力を取得する」があり、入力テキストを受け取って条件によって Amazon Lex や他のブロックに分岐することができます。 ただし、このブロックの Amazon Lex 呼び出しには、 「Amazon Connect の機能仕様」の「チャットの機能仕様」 に記述されているように、Amazon Connect から Amazon Lex チャットを呼び出した場合には、6秒以内に応答がないとタイムアウトになる、という制約があります。 この制約は、上限緩和の申請をしても変更することができません。ただし、これはチャット限定の制約で、電話から音声で呼び出された場合には該当しません。ちなみに今回のコンタクトフローでは、「顧客の入力を取得する」ブロックがタイムアウトを検知するとエラーに分岐され、「切断」ブロックに遷移し、チャット UI に”Chat has ended!”を返してフローを終了します。 図2. タイムアウト検知時のチャット UI 画面 （Amazon Connect のチャットウィジェットを使用） タイムアウト回避のアプローチ FAQ を検索して結果を応答するという従来型のチャットボットであれば、6秒というタイムアウトは厳しい制約ではありません。しかし、大規模言語モデルを使った Amazon Bedrock のようなサービスは応答時間が6秒を超えることがあるため、Amazon Connect チャットから呼び出す場合にはタイムアウトも想定して設計する必要があります。 このタイムアウトの回避策として、2つのアプローチを考えられます。 6秒以内に回答を生成できるようにAmazon Kendra と Amazon Bedrock を最適化 Amazon Lex は Amazon Bedrock を呼び出したら直ちに「顧客の入力を取得する」ブロックにリターンし、非同期の処理で Amazon Bedrock の応答をチャット UI に送付 チャットボットの場合、質問内容、つまり Amazon Bedrock に引き渡されるプロンプトのチューニングがしづらく、1は PoV (Proof of Value) の期間内に実現できない可能性が高いと判断し、今回は2を追求することにしました。 タイムアウトの回避策 以下は、2つ目の方法のアーキテクチャを示しています。 図3. タイムアウト回避策実装後のチャットボットのアーキテクチャ 最初のアーキテクチャと同様に、質問者の入力をコンタクトフローの「顧客の入力を取得する」ブロックにて受け取り、Amazon Lex に送信します。Amazon Lex から呼び出された AWS Lambda 関数(以下、Lambda 関数)は、別の Lambda 関数を非同期に呼び出し、「AI 検索中」のメッセージを返して、直ちに終了します。これにより「顧客の入力を取得する」ブロックのタイムアウトを回避します。 非同期に呼び出された Lambda 関数は、質問者の入力で Amazon Kendra を検索し、質問と検索結果を Amazon Bedrock に渡して回答文を生成させ、生成した回答文を Amazon DynamoDB に保存します。 この仕組みにより、タイムアウトの制約を回避しながら Amazon Bedrock を呼び出すことができるようになりました。 次に、Amazon DynamoDB に保存された回答文をチャット UI に届ける仕組みを説明します。上図のループの部分に Amazon Connect が Lambda 関数を介して回答文を入手していることを示しましたが、仕組みの大部分は Amazon Connect のコンタクトフローで実装されているので、ここからはコンタクトフローを参照しながら説明することにします。 非同期に実行する処理の完了を検知したい時の常とう手段として、「処理完了時にイベントを発行させる方法」と、「定期的に処理の状態をチェックする方法」がありますが、今回は後者を採用しました。前者はイベントを発行する仕組みと受け取る仕組みが必要で、Amazon DynamoDB はテーブル更新時に Amazon EventBridge イベントを発行できるのですが、コンタクトフロー側にこのイベントを受け取る手段がありませんでした。 後者の方式はコンタクトフローでも簡単に実装できます。以下に今回実装した仕組みを紹介します。 まずコンタクトフローを示します。 図4. タイムアウト回避策を実装した Amazon Connect コンタクトフロー 次に、このコンタクトフローの処理の流れを順に説明します。 1.「顧客の入力を取得する」ブロック 質問者からの入力を受け取り、Amazon Lex を内部で呼び出します。Amazon Lex は Amazon Bedrock の応答を待たずにリターンするので、タイムアウトすることはありません。Amazon Lex から正常応答を受け取ったら２に遷移します。 2.「待機」ブロック 2～5でループを構成し、そのループを1秒間隔で20回繰り返すことにしました。その1秒間隔をここで定義しています。 3.「AWS Lambda 関数を呼び出す」ブロック Amazon DynamoDB に保存された回答文を取りに行く Lambda 関数を呼び出します。 4.「コンタクト属性を確認する」ブロック 3の Lambda 関数の戻り値を確認し、条件分岐します。「回答文待機中」の場合は5に遷移し、「回答文有」の場合は6-Bに遷移します。 5.「ループ」ブロック ループ回数をカウントして条件分岐します。回数上限は20としました（最大100でセット可能）。ループ回数が20回に到達するまでは2に遷移し、20回に到達したら6-Aに遷移します。 6-A.「プロンプトの再生」ブロック チャット UI への応答にタイムアウトメッセージをセットして1に戻ります。 6-B.「プロンプトの再生」ブロック チャット UI への応答に、Amazon DynamoDB から Lambda 関数経由で 受け取った回答文をセットして、1に戻ります。 チャットボットの実行例 最後に、今回紹介した方法を組み込んだチャットボットの実行例を紹介します。質問をチャット UI に入力すると、Amazon Connect コンタクトフローが Lambda 関数を呼び出し、Lambda 関数が Amazon Kendra の検索とジェネレーティブ AI による回答文の生成を実行し、ループしながら待機していたコンタクトフローが回答文を受け取って、タイムアウトすることなくチャット UI に回答文を表示できました。Amazon Kendra にはあらかじめ本ブログのドラフトが保存してあり、これを要約したものが回答文として生成されました。 図5. タイムアウトを回避して応答を返した時のチャット UI 画面 （Amazon Connect のチャットウィジェットを使用） 結論 本ブログでは、Amazon Connect のチャットボットから Amazon Bedrock を呼び出す場合に、Amazon Lex 呼び出しが6秒でタイムアウトするという制約が課題になることを指摘し、Lambda 関数の非同期化とコンタクトフローの工夫による現実的なタイムアウト回避策を提示しました。一般的にはチャットボットを実装する際にわざわざ Amazon Connect を経由させたりしませんが、コンタクトセンターのオムニチャネル戦略構想では電話とチャットの併用はよくあることですし、電話やチャットへの自動応答への期待も Amazon Bedrock の普及により益々高まっています。 今後の新たなモデルの登場・サービスの改善により今回指摘した制約が回避できるようになる可能性も期待していますが、今回あげたケースのようにタイムアウトの可能性が排除できない時には、本ブログで紹介した方法が参考になれば幸いです。 著者について 金　敬源 アクセンチュア株式会社　テクノロジーコンサルティング本部 インテリジェントクラウド アンド インフラストラクチャー グループ所属 竹内 誠一 アクセンチュア株式会社 マネジャー　テクノロジーコンサルティング本部 インテリジェントクラウド アンド インフラストラクチャー グループ所属

セキュリティは AWS 、そしてすべてのお客様にとって最優先事項です。ＡＷＳではセキュリティに特化した教育型のカンファレンスである AWS re:Inforce を開催し、お客様とともにセキュリティを学びセキュリティの文化を広める場を提供しています。2024年は、6月10日～12日にペンシルベニア州フィラデルフィアで開催されますが、本カンファレンスの登録開始とともに 日本語の紹介ページが開設されました のでご案内です。 AWS re:Inforce とは 「AWS re:Inforce」は、 AWS のセキュリティソリューション、クラウドセキュリティ、コンプライアンス、アイデンティティに特化したグローバルな学習型カンファレンスです。 AWS セキュリティのエキスパートやパートナーとともに、最先端のセキュリティ情報を短時間で効率的に収集できます。 2024年は、会場をペンシルベニア州フィラデルフィアに移し、開催期間も2日半に拡大し、コンテンツをさらに充実いたしました。最新情報の共有やクラウドセキュリティやコンプライアンスに関する学びの場を提供するとともに、コミュニティのさらなる拡大を図ります。 re:Inforce に参加することで、 AWS のセキュリティサービスとソリューションを使用したクラウドセキュリティの改善方法を、より深く、より包括的に理解することができます。また、 AWS のエキスパートから、より安全なシステムの構築方法を学び、組織のセキュリティ体制を改善するための実用的なソリューションを得ることが可能です。また、日本のお客様が、初心者から熟練者まで、参加者がより学習に集中できる環境を提供するために、公認ツアーを用意しています。ツアーに関しては こちらのページから確認 いただければ幸いです。  見どころ：基調講演や様々なセッション AWS の CISO (最高情報セキュリティ責任者) である Chris Betz が、クラウドセキュリティの最新動向や AWS のセキュリティカルチャーについて、また AWS がどのように生成AI のセキュリティに対する対策を行なっているかについて知見を共有します。AWS re:Inforce は、 AWS イベントの中で最も幅広いレベルのセキュリティに関する学習型セッションとコンテンツを提供しており、様々な形式のセッションを幅広く用意しています。ぜひ会場でご参加ください。 見どころ：生成AIにおけるセキュリティ AWS re:Inforce 2024 のコンテンツは、セキュリティ専門家が生成AI時代の課題と需要に備えることができるように設計されています。どのトラックやセッションタイプを選択しても、セキュリティの視点を通して生成AIについて学ぶことができます。AWS上の生成AIのパワーを安全に活用するための実践的なソリューションをご覧ください。AIワークロードのデータ保護、基盤モデル（FM）とAIアプリケーションの制御とガードレールの実装、セキュリティ運用とインシデント対応を強化するための生成AIの活用に関する洞察を得ることで、生成AIの旅を安全に加速することができます。 All Builders Welcome Grant AWSは、次世代の技術リーダーを育成することに専念しています。 All Builders Welcome Grant は、現状とクラウドの未来とのギャップを埋め、代表とアクセスに関する針を動かし、技術において代表的でないグループが含まれる環境を構築します。本プログラムの助成金には、re:Inforce 2024に参加するためのフルカンファレンスパス、ペンシルバニア州フィラデルフィアまでの航空券、3泊分のホテル宿泊費が含まれます。参加者は、2日半に及ぶre:Inforceのコンテンツやアクティビティに参加できるほか、ウェルカムイベント、基調講演の指定席、ミートアップ、AWSセキュリティリーダーとのメンタリングイベントなど、学習、キャリア成長、コミュニティ形成の機会を創出するようデザインされたプログラムを利用できます。 募集は現在開始 されており、2024年4月1日（月）午後5時（米国東部時間）に締め切られます。詳細については、 All Builders Welcome Grant の利用規約 をご覧ください。 セキュリティは技術者だけではなく経営幹部や監査、またサイバーセキュリティに関連する公共部門の担当者など、多くの皆様にとっての関心事項となります。このような機会を通じて、安全なサイバー空間の実現を一緒にご支援できれば幸いです。 この記事は セキュリティ アシュアランス本部 本部長 松本照吾が担当しました。

InfluxDB を Amazon Timestream のデータベース エンジンとして使用できるようになりました。本サポートにより、InfluxDB や、時系列データを収集するオープンソース Telegraf エージェント等のオープンソース API を使用して、ほぼリアルタイムの時系列アプリケーションを簡単に実行できるようになります。 Timestream では、Timestream for LiveAnalytics と Timestream for InfluxDB の 2 つのデータベースエンジンを選択できるようになりました。 ほぼリアルタイムの時系列クエリまたは InfluxDB の特定の機能 (Flux クエリ等) が必要なユースケースの場合は、InfluxDB エンジンの Timestream を使用する必要があります。 もう 1 つのオプションは、LiveAnalytics エンジンの既存の Timestream です。これは、1 分あたり数十ギガバイトを超える時系列データを取り込み、ペタバイトの時系列データに対して SQL クエリを数秒で実行するような場合に適しています。 Timestream の InfluxDB サポートにより、最適なパフォーマンスと可用性が得られるように自動的に構成されたマネージドインスタンスを使用できます。また、InfluxDB データベースのマルチアベイラビリティゾーン構成を取る事で、復元力を高めることができます。 InfluxDB の Timestream と LiveAnalytics の Timestream は相互に補完し、時系列データの低レイテンシおよび大規模な取り込みを実現します。 Timestream for InfluxDB を開始 早速始めてみましょう。 まず、InfluxDB インスタンスを作成しましょう。 Amazon Timestream コンソールを開き、 InfluxDB databases に移動して、 Create Influx database を選択します。 次のページで、InfluxDB インスタンスの database credentials を指定します。 また、 Instance configuration でインスタンスクラスを指定し、ニーズに合わせてストレージのタイプとボリュームも指定します。 次のパートでは、マルチ AZ デプロイメントを選択可能です。この設定により、別のアベイラビリティーゾーンにあるスタンバイデータベースにデータが同期的にレプリケートされます。もしも、障害が検出された場合、Timestream for InfluxDB はデータを失うことなくスタンバイインスタンスに自動的にフェイルオーバーします。 次に、 Connectivity configuration で InfluxDB インスタンスに接続する方法を構成します。ここでは、ネットワークタイプ、VPC、サブネット、データベースポートを定義します。また、パブリックサブネットを指定し、 InfluxDB インスタンスの public access を Publicly Accessible と設定する事も可能で、Amazon Timestream がパブリック IP アドレスを InfluxDB インスタンスに割り当てることができます。もしも、このオプションを選択する場合は、InfluxDB インスタンスを保護するための適切なセキュリティ対策が講じられていることを確認してください。 このデモでは、InfluxDB インスタンスを Not publicly accessible に設定した為、このセクションで定義した VPC とサブネットを介してのみアクセス可能となります。 データベース接続を構成したら、データベースのパラメーターグループとログ配信設定を定義します。 Parameter group では、InfluxDB データベースに使用する特定の構成可能なパラメーターを定義できます。 log delivery settings では、システムログをエクスポートする Amazon Simple Storage Service (Amazon S3) バケットを定義することもできます。 Amazon S3 バケットに必要な AWS Identity and Access Management (IAM) ポリシーの詳細については こちら を参照してください。 設定が完了したら、 Create Influx database を選択します。 InfluxDB インスタンスが作成されると、詳細ページで内容を確認できます。 InfluxDB インスタンスを作成すると、InfluxDB ユーザー インターフェイス (UI) にアクセス可能です。 InfluxDB をパブリックにアクセスできるように構成すると、 InfluxDB UI を選択してコンソールを使用して UI にアクセスできます。セットアップに示されているように、今回は InfluxDB インスタンスをパブリックにアクセスできないように構成しました。この場合、InfluxDB インスタンスと同じ VPC 内の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを介して SSH トンネリングを使用して InfluxDB UI にアクセスする必要があります。 詳細ページの URL エンドポイントを使用して、InfluxDB UI に移動し、作成時に設定したユーザー名とパスワードを使用します。 InfluxDB UI で、InfluxDB インスタンスと対話するためのトークンを作成できるようになりました。 Influx CLI を使用してトークンを作成することもできます。トークンを作成する前に、InfluxDB インスタンスと対話するための設定を行います。以下は、設定するサンプルコマンドです。 influx config create --config-name demo \ --host-url https://<TIMESTREAM for INFLUX DB ENDPOINT> \ --org demo-org --username-password [USERNAME] \ --active InfluxDB の設定後、オペレーター、オールアクセス、または読み取り/書き込みトークンを作成できるようになりました。以下は、定義した組織内のすべてのリソースにアクセス許可を付与するためのトークンを作成する例です。 influx auth create --org demo-org --all-access 対象のユースケースで必要なトークンがあれば、Influx CLI、Telegraf エージェント、 InfluxDB クライアントライブラリ 等のツールを使ってデータ取り込みを開始出来ます。ここでは Influx CLI を使ってサンプルのホームセンサーデータをラインプロトコル形式で書き込みます。これは、 InfluxDB ドキュメントページ からも参照出来ます。 influx write \ --bucket demo-bucket \ --precision s " home,room=Living\ Room temp=21.1,hum=35.9,co=0i 1641024000 home,room=Kitchen temp=21.0,hum=35.9,co=0i 1641024000 home,room=Living\ Room temp=21.4,hum=35.9,co=0i 1641027600 home,room=Kitchen temp=23.0,hum=36.2,co=0i 1641027600 home,room=Living\ Room temp=21.8,hum=36.0,co=0i 1641031200 home,room=Kitchen temp=22.7,hum=36.1,co=0i 1641031200 home,room=Living\ Room temp=22.2,hum=36.0,co=0i 1641034800 home,room=Kitchen temp=22.4,hum=36.0,co=0i 1641034800 home,room=Living\ Room temp=22.2,hum=35.9,co=0i 1641038400 home,room=Kitchen temp=22.5,hum=36.0,co=0i 1641038400 home,room=Living\ Room temp=22.4,hum=36.0,co=0i 1641042000 home,room=Kitchen temp=22.8,hum=36.5,co=1i 1641042000 home,room=Living\ Room temp=22.3,hum=36.1,co=0i 1641045600 home,room=Kitchen temp=22.8,hum=36.3,co=1i 1641045600 home,room=Living\ Room temp=22.3,hum=36.1,co=1i 1641049200 home,room=Kitchen temp=22.7,hum=36.2,co=3i 1641049200 home,room=Living\ Room temp=22.4,hum=36.0,co=4i 1641052800 home,room=Kitchen temp=22.4,hum=36.0,co=7i 1641052800 home,room=Living\ Room temp=22.6,hum=35.9,co=5i 1641056400 home,room=Kitchen temp=22.7,hum=36.0,co=9i 1641056400 home,room=Living\ Room temp=22.8,hum=36.2,co=9i 1641060000 home,room=Kitchen temp=23.3,hum=36.9,co=18i 1641060000 home,room=Living\ Room temp=22.5,hum=36.3,co=14i 1641063600 home,room=Kitchen temp=23.1,hum=36.6,co=22i 1641063600 home,room=Living\ Room temp=22.2,hum=36.4,co=17i 1641067200 home,room=Kitchen temp=22.7,hum=36.5,co=26i 1641067200 " 最後に、InfluxDB UI を使用してデータをクエリしてみましょう。 InfluxDB UI の Data Explorer ページに移動し、簡単な Flux スクリプトを作成して、 Submit を選択します。 Timestream for InfluxDB を使用すると、既存のツールを引き続き使用してデータベースと対話しながら、InfluxDB を利用したアプリケーションの開発が容易になります。マルチ AZ 構成を利用すると、基盤となるインフラストラクチャを気にすることなく、InfluxDB データの可用性を高めることが可能です。 AWS と InfluxDB のパートナーシップ Amazon Timestream for InfluxDB の一般提供開始を祝って、InfluxData の創設者兼最高技術責任者である Paul Dix がこのパートナーシップについて次のように述べています。 “オープンソースの未来はパブリッククラウドによって推進され、シンプルなエントリポイントと実用的なユーザーエクスペリエンスを通じて広範なコミュニティに浸透しています。Amazon Timestream for InfluxDB はそのビジョンを具現化したものです。AWS とのパートナーシップにより、InfluxDB が時系列データに関するリアルタイムの洞察を実現する力を倍増するツールとなり、開発者が AWS 上で時系列ワークロードを構築および拡張が簡単に実現出来ます。” 知っておくべき事 その他の追加情報を以下に示します。 利用可能な AWS リージョン – オハイオ、バージニア北部、オレゴン、ムンバイ、シンガポール、シドニー、東京、フランクフルト、アイルランド、ストックホルムリージョンで利用できます 移行シナリオ – 自身で運用されている InfluxDB インスタンスから移行するには、既存の InfluxDB データベースから Timestream for InfluxDB にバックアップを復元するだけです。既存の Timestream LiveAnalytics エンジンから InfluxDB 用の Timestream に移行する必要がある場合は、Amazon S3 を利用できます。さまざまなユースケースにおいて移行を実施する方法の詳細については、「 Migrating data from self-managed InfluxDB to Timestream for InfluxDB 」ページを参照してください。 サポート対象バージョン – Timestream for InfluxDB は現在、InfluxDB のオープンソース 2.7.5 バージョンをサポートしています。 利用料 – 料金の詳細については、 Amazon Timestream pricing をご覧ください。 デモ – Timestream for InfluxDB の動作を確認するには、同僚の Derek が作成したこの デモ をご覧ください。 Timestream for InfluxDB を使用して、ミリ秒の応答時間を持つ時系列アプリケーションとダッシュボードの構築をします。詳細については、 Amazon Timestream for InfluxDB ページをご覧ください。 翻訳はテクニカルアカウントマネージャーの西原が担当しました。原文は こちら をご覧下さい。

3月4日週、Anthropic は Claude 3 基礎モデルファミリー を発表しました。このファミリーには、ほぼ瞬時の応答性を実現する最速かつ最もコンパクトな Claude 3 Haiku 、スキルとスピードの理想的なバランスを実現した Claude 3 Sonnet 、および高度に複雑なタスクでトップレベルのパフォーマンスを実現する高度なインテリジェンスを備えた Claude 3 Opus という 3 つのモデルが含まれています。AWS はまた、 Amazon Bedrock での Claude 3 Sonnet の一般提供の開始 も発表しました。 本日は、 Claude 3 Haiku が Amazon Bedrock で利用可能になったことをお知らせします。Claude 3 Haiku 基盤モデルは、Claude 3 ファミリーの中で最速かつ最もコンパクトなモデルであり、ほぼ瞬時の応答性と、人間の対話を模倣したシームレスな生成人工知能 (AI) エクスペリエンスを実現するように設計されています。例えば、チャートやグラフを含む arXiv のデータ密度の高い研究論文 (～10,000 トークン) を 3 秒以内に読み取ることができます。 Claude 3 Haiku が Amazon Bedrock で利用可能になったことで、迅速かつ正確な目標パフォーマンスを必要とする企業向けに、ほぼ瞬時に応答する生成 AI アプリケーションを構築できます。Sonnet や Opus と同様、Haiku は画像からテキストに変換するためのビジョン機能を備えているほか、英語のほかにも複数の言語を理解でき、200k コンテキストウィンドウでの高い操作性を誇っています。 Claude 3 Haiku のユースケース Claude 3 Haiku は、インテリジェンスカテゴリの他のモデルよりも賢く、高速で、より手頃な料金でご利用いただけます。単純なクエリやリクエストに対して、比類のない速度で応答します。高速で、高い操縦性を備えているため、人間のやり取りをシームレスに模倣する AI エクスペリエンスを生み出すことができます。 Claude 3 Haiku のユースケースを以下にいくつか示します。 顧客とのやり取り: ライブでのやり取りや翻訳における迅速かつ正確なサポート コンテンツモデレーション: 危険な行為や顧客のリクエストを把握 コスト削減タスク: 最適化された物流、在庫管理、非構造化データからの知識の迅速な抽出 Claude 3 Haiku の特徴や機能の詳細については、AWS ドキュメントの「 Amazon Bedrock での Anthropic Claude 」および「 Anthropic Claude モデル 」にアクセスしてください。 Claude 3 Haiku の動作 Anthropic モデルを初めて使用する場合は、 Amazon Bedrock コンソール に移動し、左下のペインで [モデルアクセス] を選択します。 Claude 3 Haiku へのアクセスを別途リクエストします。 コンソールで Claude 3 Haiku をテストするには、左側のメニューペインの [プレイグラウンド] で [テキスト] または [チャット] を選択します。その後、 [モデルを選択] を選択し、カテゴリとして [Anthropic] を選択して、モデルとして [Claude 3 Haiku] を選択します。 Claude プロンプトの例をさらにテストするには、 [例をロード] を選択します。引用を含む高度な質疑応答、デザインブリーフィングの作成、英語以外のコンテンツの生成など、Claude 3 Haiku に固有の例を表示および実行できます。 [比較モード] では、顧客の質問に対応するためのパーソナライズされた E メール応答を生成するサンプルプロンプトを使用して、Claude 3 Haiku と Claude 2.1 モデルの速度とインテリジェンスを比較することもできます。 また、 [API リクエストを表示] を選択すると、 AWS コマンドラインインターフェイス (AWS CLI) や AWS SDK でコードサンプルを使用してモデルにアクセスすることもできます。AWS CLI コマンドのサンプルを次に示します。 aws bedrock-runtime invoke-model \ --model-id anthropic.claude-3-haiku-20240307-v1:0 \ --body "{\"messages\":[{\"role\":\"user\",\"content\":[{\"type\":\"text\",\"text\":\"Write the test case for uploading the image to Amazon S3 bucket\\nCertainly! Here's an example of a test case for uploading an image to an Amazon S3 bucket using a testing framework like JUnit or TestNG for Java:\\n\\n...."}]}],\"anthropic_version\":\"bedrock-2023-05-31\",\"max_tokens\":2000}" \ --cli-binary-format raw-in-base64-out \ --region us-east-1 \ invoke-model-output.txt Claude 3 で API リクエストを実行するには、新しい Anthropic Claude Messages API 形式 を使用します。これにより、画像処理などのより複雑なやり取りが可能になります。 Anthropic Claude Text Completions API を使用する場合は、 Text Completions API からアップグレード する必要があります。 画像ファイルを記述する Message API リクエストを送信するサンプル Python コードを次に示します。 def call_claude_haiku(base64_string): prompt_config = { "anthropic_version": "bedrock-2023-05-31", "max_tokens": 4096, "messages": [ { "role": "user", "content": [ { "type": "image", "source": { "type": "base64", "media_type": "image/png", "data": base64_string, }, }, {"type": "text", "text": "Provide a caption for this image"}, ], } ], } body = json.dumps(prompt_config) modelId = "anthropic.claude-3-haiku-20240307-v1:0" accept = "application/json" contentType = "application/json" response = bedrock_runtime.invoke_model( body=body, modelId=modelId, accept=accept, contentType=contentType ) response_body = json.loads(response.get("body").read()) results = response_body.get("content")[0].get("text") return results Claude 3 でのサンプルコードの詳細については、Community.aws の「 Get Started with Claude 3 on Amazon Bedrock 」、「 Diagrams to CDK/Terraform using Claude 3 on Amazon Bedrock 」、および「 Cricket Match Winner Prediction with Amazon Bedrock’s Anthropic Claude 3 Sonnet 」をご覧ください。 今すぐご利用いただけます Claude 3 Haiku は現在、米国西部 (オレゴン) リージョンで利用可能であり、さらに多くのリージョンで間もなく利用可能になる予定です。今後の更新については、 リージョンの詳細なリスト をご確認ください。 Claude 3 Haiku は最もコスト効率の高い選択肢です。例えば、Claude 3 Haiku は、Claude Instant と比較して、1,000 入力/出力トークンあたりの料金が最大 68% 低く、より高いレベルのインテリジェンスを備えています。詳細については、「 Amazon Bedrock の料金 」をご覧ください。 Amazon Bedrock コンソール で Claude 3 Haiku を今すぐお試しいただき、 AWS re:Post for Amazon Bedrock まで、または通常の AWS サポートの連絡先を通じて、フィードバックをお寄せください。 – Channy 原文は こちら です。

Amazon Transcribe は、アプリケーションに音声認識機能を簡単に追加できる、フルマネージドの自動音声認識 (Automatic Speech Recognition; ASR) サービスです。この度、数十億パラメータから構成される次世代の音声基盤モデルに基づいた、 100 言語 以上に対応する音声認識システムを発表できることを嬉しく思います。この記事では、このシステムのメリット、企業がそれをどのように活用しているか、そして利用開始方法を紹介します。また、本記事の下部には音声認識結果の例も記載しています。 Amazon Transcribe の音声基盤モデルは、自己教師あり (self-supervised) アルゴリズムを用いて学習されています。これにより、人間の音声の普遍的なパターンを言語やアクセントを越えて学習できます。本モデルは 1 億時間以上、100 言語以上のラベルなし音声データを使用して学習されています。言語間の学習データのバランスを取るように最適化された学習方法を用いているため、従来対応できていなかった言語でも高い精度が得られます。 Carbyne は、緊急通報対応者のための、クラウドベースでミッションクリティカルなコンタクトセンターソリューションを開発するソフトウェア会社です。Carbyne のミッションは緊急対応者による救命の支援であり、言語の壁がその妨げになってはいけません。このミッション達成のため、Carbyne では Amazon Transcribe を以下の通りに活用しています: 「AI を活用している Carbyne ライブオーディオ翻訳は、家庭で英語以外の言語を話す 6,800 万人のアメリカ人と、年間最大 7,900 万人の外国人観光客の緊急対応の改善に直接役立つことを目的としています。Amazon Transcribe の新しい多言語基盤モデルに基づく音声認識機能を利用することで、Carbyne は 誰もが等しく大切な存在である という理念のもと、生命救助の緊急サービスをより多くの人々に提供できるようになるでしょう。」 – Alex Dizengof, Carbyne 共同設立者兼 CTO Amazon Transcribe の音声基盤モデルを活用することで、ほとんどの言語において認識精度が 20%-50% 向上しました。また、電話音声は認識の難易度が高くデータが不足しがちな領域ですが、こちらでも 30%-70% の精度向上を実現しました。大幅に向上した認識精度に加え、この大規模音声認識モデルは、句読点や大文字小文字をより正確に認識できるので、書き起こしの可読性も向上させます。生成 AI の登場により、数千もの企業が Amazon Transcribe を利用して、音声コンテンツから豊富なインサイトを引き出しています。精度が向上し 100 言語以上のサポートを実現した Amazon Transcribe を利用することで、このようなあらゆるユースケースで良い効果が期待できます。バッチモードで Amazon Transcribe を利用している全ての既存および新規のお客様は、API エンドポイントや入力パラメータを変更することなく、音声基盤モデルに基づく音声認識を利用できます。 新しい音声認識システムは、100 以上の全言語において、使いやすい利用形態、カスタマイズ性、ユーザーの安全性、プライバシーなどの主要な機能を提供します。句読点の自動付与、カスタム辞書、自動言語識別、話者識別、単語レベルの信頼度スコア表示、カスタム辞書フィルタなどもこれらの機能に含まれます。異なるアクセント、ノイズ環境、音響条件への対応の拡大により、より正確な文字起こしができるようになり、音声認識技術をお客様のアプリケーションに効率的に導入できます。 さまざまなアクセントやノイズ条件下での Amazon Transcribe の精度向上、対応言語の拡大、付加価値をもたらす機能の充実により、数千もの企業が音声コンテンツからのインサイトを抽出し、音声やビデオコンテンツの可視性や見つけやすさを向上できます。例えば、コンタクトセンターは顧客との通話を文字起こししてインサイトを得た上で、顧客満足度やエージェントの生産性向上に活用しています。また、コンテンツ制作者やメディア配信事業者は、Amazon Transcribe による自動字幕作成を利用してコンテンツのアクセシビリティを向上させています。 Amazon Transcribe の利用開始方法 AWS コマンドラインインターフェース (AWS CLI)、 AWS マネジメントコンソール 、および AWS SDK を使用してバッチ文字起こしを行うことができます。従来と同じ StartTranscriptionJob API を使用して、コードやパラメータの変更をすることなく、性能が強化された自動音声認識モデルを利用できます。AWS CLI とコンソールの使用方法の詳細については、 AWS CLI による文字起こし と AWS マネジメントコンソールでの文字起こし をそれぞれ参照してください。 最初のステップは、メディアファイルを Amazon Simple Storage Service (Amazon S3) バケットにアップロードすることです。S3 は、あらゆる量のデータをどこからでも保存および取得するために構築されたオブジェクトストレージサービスです。S3 は極めて低コストで、業界をリードする耐久性、可用性、パフォーマンス、セキュリティ、ほぼ無制限のスケーラビリティを提供します。書き起こしを独自の S3 バケットに保存するか、Amazon Transcribe に安全なデフォルトのバケットを使用させるか選択できます。S3 バケットの使用方法の詳細については、 Amazon S3 バケットの作成、設定、操作 をご覧ください。 音声認識の出力結果 Amazon Transcribe の出力は JSON 形式です。書き起こしの結果は、テキスト形式とアイテム形式の 2 つの異なる形式で出力されます。API エンドポイントや入力パラメータに違いはありません。 テキスト形式は、まとまったテキストとして書き起こしを提供します。一方で、アイテム形式は時系列で順序付けされた 1 つ以上の書き起こしアイテムの形式で、各アイテムごとの追加のメタデータとともに提供されます。書き起こし結果のファイルではこれらの 2 つの形式が両方出力されます。 書き起こしジョブの作成時に選択するオプションに応じて、Amazon Transcribe は書き起こしを作成します。次の出力結果を参照してください: { "jobName": "2x-speakers_2x-channels", "accountId": "************", "results": { "transcripts": [ { "transcript": "Hi, welcome." } ], "speaker_labels": [ { "channel_label": "ch_0", "speakers": 2, "segments": [ ] }, { "channel_label": "ch_1", "speakers": 2, "segments": [ ] } ], "channel_labels": { "channels": [ ], "number_of_channels": 2 }, "items": [ ], "segments": [ ] }, "status": "COMPLETED" } 各項目の説明は以下の通りです。 書き起こし – transcripts 要素で表され、書き起こしのテキスト形式のみが含まれます。複数話者、マルチチャネルの場合は、すべての書き起こしが 1 つのブロックとして連結されています。 話者 – speaker_labels 要素で表され、話者ごとにグループ化された書き起こしのテキスト形式とアイテム化された形式が含まれます。この項目は、 話者識別 (Speaker partitioning/diarization) 機能 が有効になっている場合にのみ利用できます。 チャネル – channel_labels 要素で表され、チャネルごとにグループ化された書き起こしのテキスト形式とアイテム化された形式が含まれます。この機能は、 マルチチャネル機能 が有効になっている場合にのみ利用できます。 アイテム – items 要素で表され、書き起こしのアイテム化された形式のみが含まれます。複数話者、マルチチャネルの場合は、アイテムには話者やチャネルを示す追加のプロパティが含まれます。 セグメント – segments 要素で表され、書き起こしのテキスト形式とアイテム化された形式が含まれます。代替書き起こしのまとまりでグループ化されており、代替文字起こし機能が有効になっている場合に限りこの機能が利用できます。 訳註: 例えば日本語の書き起こしデータ ( transcripts ) は以下のように出力されます。( こちら の動画の 1:55- 以降) えではですね、あ、こんにちは。ではですね。あの私の方からま、今回のイベントのですね。あのジェネラルセッションということで、あのAWS、こんなこと考えてますとか、ま、こんなことができますっていうですね、概要をご紹介させていただいて、後続のですね。あのより深掘りをする楽しいセッションに繋いでいくというお話をしていきたいなという風に思っていますので、よろしくお願いいたします。あ、よろしくお願いします。はいえーではですね。まもしかしたらご存じない方もいらっしゃるかもしれないので、ま、そもそもAWSって何ぞやって話をですね、ちょっとだけしたいなという風に思っています。で、AWSまアマゾンウェブサービスということで、ま、アマゾンの仲間の一員ということになるんですけれども、あのアマゾンとですねま、AWSえ、我々はですねま、地球上で最もお客様を大切にする企業でありたいという風に考えています。で、アマゾンのビジネスモデルなんですけれども、あのより多くのお客様にですね、満足をいただくとで、そうすると、さらにたくさんのお客様がいらっしゃって。で、その場を使ってですね、ビジネスをやりたい人も増えるだろうと。そうすると、品揃えが増えて満足につながるよね。ま、これをぐるぐる回しましょうっていうところが一つと。あと、あのだんだん大きくなってくるにつれて、まオペレーションのコストとかも発生してくると思うんですけれども。ま、それを低コストでですね、回していくことで、え？お客様にですねえ、低価格という形で還元をするということをアマゾン全体では考えていて。で、AWSもですね、あの、その同じ考え方が、あの息づいているサービスということになっています。 まとめ AWS では、お客様のために絶えずイノベーションを起こしています。Amazon Transcribe の対応言語を 100 言語以上に拡張することで、多様な言語背景を持つユーザーへのサービス提供が可能になりました。これはアクセシビリティの向上や、世界規模でのコミュニケーションと情報交換の新たな機会の創出にも繋がります。この投稿で議論した機能の詳細は、 機能紹介ページ と 新機能のお知らせ (What’s new) をご覧ください。 本記事の執筆者紹介 Sumit Kumar は AWS の 言語系 AI サービスチームでプリンシパルプロダクトマネージャーを務めています。様々な分野において 10 年のプロダクトマネジメントの経験があり、AI/ML に情熱を持っています。趣味は旅行と、クリケットやローンテニスです。 Vivek Singh は AWS の 言語系 AI サービスチームでプロダクトマネジメントのシニアマネージャーを務めており、Amazon Transcribe 製品チームのリーダーです。AWS に入社する前は、コンシューマーペイメントや小売など、Amazon の他の組織でプロダクトマネジメントを行っていました。Vivek はシアトルに住んでいて、趣味はランニングやハイキングです。 本記事の翻訳は Solutions Architect 安藤が担当しました。原文は こちら です。

MYCOM OSI このブログは 2023 年 12 月 4 日に Dirk Michel（MYCOM OSI, SVP SaaS and Digital Technology）、Josh Hart（Senior Solutions Architect）、Chris Williams（Solutions Architect）によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 “Kubernetes 上のデータ”は、パフォーマンス、回復力、信頼性、総所有コスト（TCO）を最適化する、クラウドネイティブなマイクロサービスベースのソフトウェアソリューションを構築するために不可欠な、急速に進化する革新的分野です。Kubernetes アプリケーションの多くは、ブロックストレージ、共有ファイルシステム、オブジェクトストレージなどの永続ストレージとデータサービスへのアクセスを必要とします。 このブログでは、 MYCOM OSI が Amazon FSx for NetApp ONTAP を採用することで、どのようにコストパフォーマンスを改善したかについて説明します。また、大規模で複雑な通信事業者の通信ネットワークについて品質やパフォーマンスを監視するための、アシュアランスデータセットの処理を最適化するソリューションを特定するために、ストレージオプションをどのように評価したかを探ります。 MYCOM OSI はデジタル時代の通信サービスプロバイダー（CSP）向けに保証、自動化、分析の Software-as-a-Service （SaaS）アプリケーションを提供する AWS Specialization Partner です。 MYCOM OSI の アシュアランス・クラウド・サービス （ACS）は、重要なネットワーク・パフォーマンス、障害、サービス品質の管理を提供します。このサービスは、SaaS モデルおよび自社クラウド（BYOC）モデルのあらゆる領域において、ハイブリッド、物理、および仮想化ネットワークに対して、AI および ML技術を活用した自動化された包括的なアシュアランスをサポートしています。 データマネジメントの課題 通信事業者のアシュアランスデータセットは大きく、時には 10～100 テラバイト（TB）単位になります。昨今の通信ネットワークを構成する機器やネットワーク機能は、様々なプロトコルやフォーマットで大量のテレメトリデータを送信します。アシュアランスアプリケーションはこのデータストリームを取り込みます。このデータストリームは通常、情報量の多い時系列数値データ、イベントデータ、ログフォーマットデータ、設定データで構成されています。 通信事業者は、受信するアシュアランスデータストリームのほぼリアルタイムの性質を利用して、監視センターとオペレーションセンター内で、時間的制約のあるトリアージとインシデント対応活動に情報を提供しています。また通信事業者では、受信データを長期にわたって保持・蓄積し、ネットワーク分析や ML ワークロードに不可欠な貴重な履歴データリポジトリを構築します。 重要なことは、多くの時間的制約のあるアシュアランスのユースケースは、中程度の範囲の履歴データへの低レイテンシーアクセスに依存していることです。また、より長い範囲の履歴データは、ネットワークのキャパシティプランニングやエンタープライズ・リソース・プランニング（ERP）など、他の領域における意思決定のためのバッチプロセスを駆動します。 ペタバイト（PB）スケールのデータセットは、高品質、高粒度である可能性がありますが、多大なコストがかかるため、扱うのが難しいです。主なコスト要因のひとつはストレージであり、特に大規模なアクセスネットワークと長期間のデータ保持を必要とする通信事業者にとっては尚更です。データセットのサイズが大きくなるにつれて、必要なストレージ容量を取得、維持し、低レイテンシのパフォーマンス要件を満たすためのコストは大幅に増大します。 直接的なストレージリソースのコストに加え、システムや AWS のアベイラビリティゾーン（AZ）間で大規模なデータセットを転送したりアクセスしたりするのにもコストがかかります。このような大量のデータをネットワーク経由で移動させる場合、高い帯域幅が要求されることが多く、データ転送コストが高くなる可能性があります。 MYCOM OSI のクラウドベースの SaaS ソリューションは、Kubernetes 上にマイクロサービスアプリケーションとしてデプロイされ、数値データストアにはネットワークファイルシステム（NFS）ストレージを多用しています。 Amazon Elastic Kubernetes Service （Amazon EKS）はコアコンピュートプラットフォームであり、AWS 上の Kubernetes クラスタとシームレスに動作するように特別に設計された複数のストレージオプションを提供しています。 EKS の NFS ストレージのオプションとして長年人気があるのは、 Amazon Elastic File System （Amazon EFS）です。Amazon EFS は、完全に管理され、弾力性があり、可用性が高く、スケーラブルな NFS ファイルシステムサービスです。その弾力性とサーバーレス実装により、Amazon EFS はファイルシステムを自動的に拡大・縮小するため、キャパシティプランニングを行う必要はありません。 EFS のインテリジェント階層化機能はもう一つの重要な側面であり、アクセスパターンに基づいて EFS Standard と EFS Infrequent Access のストレージクラス間で動的にファイルを移動させます。 Amazon EKS チームは、Kubernetes コンテナストレージインターフェースのアドオンである EFS CSI Driver を提供しており、EKS が Amazon EFS ファイルシステムと効率的かつ安全に統合し、ライフサイクルを管理できるようにしています。ワーカーノードや AZ に分散された Kubernetes Pod は、EFS によってバックアップされた RWM（Read-Write-Many）永続ボリューム（PV）を同時に使用することができます。 MYCOM OSI のクラウドベースの SaaS ソリューションは、下図に示すように EFS を広範囲に使用しています。 図1 – Kubernetes の永続ボリュームに Amazon EFS を使用したアーキテクチャ。 通信事業者の顧客は、より広範なアシュアランスとテレメトリデータリポジトリを構築し、履歴データをより長く保持しようとしているため、増大する NFS ストレージの使用量について対策する必要性が明らかになりました。その結果、データ効率化機能をアプリケーション側で実装することを避けるために、 Amazon FSx ポートフォリオを評価するイニシアティブが生まれました。 さらに、このイニシアチブは、さまざまな可用性構成を検討する機会にもなりました。そのため、チームは代替のマネージド NFS ストレージソリューションの検討を開始しました。 提案されたソリューション 初期の決断の一つは、マネージド NFS ファイルシステムを求めてAmazon FSx ファミリーにフォーカスすることでした。Amazon FSx は時間の経過とともに拡張され、FSx for ONTAP のような新しいマネージドファイルシステムのサポートが開始されました。MYCOM OSI クラウド開発チームは FSx for ONTAP を使用した経験があり、パフォーマンスと効率性に特に焦点を当て、様々な側面から実装を評価し始めました。 評価された主な機能は以下の通りです： 柔軟なパフォーマンス構成オプション ： スループットキャパシティと IOPS を個別にプロビジョニングすることで、MYCOM OSI はデータ取り込み速度を最大 260% 高速化。 データ圧縮と重複排除機能 ： これらの機能により、MYCOM OSI はストレージ要件を平均 80% 削減。 “プライマリストレージ“と”キャパシティプールストレージ“の二つのストレージ階層 ： データアクセスパターンに基づいてデータをより低コストのストレージメディアに移動させることで、コスト効率を向上。 スナップショットベースのバックアップやリストアなどのデータ保護機能 ： AWS Backup で NFS ファイルシステムからバックアップを取ったりリストアを開始したりするのは、コストと時間がかかる。この課題をスナップショットで回避することで、データ損失やアプリケーションの障害時に迅速かつ効率的なリカバリが可能。 次の図は、ハイレベルの構成図です： 図2 – Kubernetes の永続ボリュームに Amazon FSx を使用したアーキテクチャ チームは、複数のストレージオプションをサポートし、必要に応じて個々の顧客のニーズに基づいた実装の選択肢を提供したいと考えていました。 通信事業者の顧客には様々な形態や規模があり、万能なソリューションが存在することは稀です。SaaS ソリューションの一部として柔軟なストレージソリューションオプションをサポートすることで、MYCOM OSI は大規模な履歴データセットを持つ顧客に最高の価値を提供することができました。 結果 初期の検証フェーズの一環として、チームはファイルシステムボリュームのライフサイクルを管理する FSx for ONTAP 提供の Kubernetes CSI Driver をレビューしました。FSx for ONTAP は、Kubernetes クラスタ内で永続ボリューム（PV）と永続ボリュームクレーム（PVC）のシームレスな統合を可能にします。 発生した課題： FSx for ONTAP は、 AstraTrident CSI Driver for Kubernetes の使用を推奨しています。このドライバには NFS ライブラリが含まれておらず、実際、関連する NFS ライブラリが Kubernetes ワーカーノードで利用可能であることを前提としています。これは、 BottlerocketOS のような最新のコンテナに最適化された Linux オペレーティングシステムでは必ずしも利用できるとはいえません。これらは専用に構築され、軽量で、セキュリティが強化されており、NFS ライブラリも含まれていません。 MYCOM チームと AWS ソリューションアーキテクトは協力して代替の CSI ドライバを特定し、標準の nfs-csi-driver と FSx for ONTAP の互換性を検証しました。チームは BottlerocketOS と FSx for ONTAP のセキュリティ上の利点をストレージソリューションとして利用することを決めました。 パフォーマンス ファイルシステムのパフォーマンス検証作業は、MYCOM OSI ラボのテストハーネス上で実行され、ストレージ効率化機能を有効にした FSx for ONTAP ファイルシステムを採用した SaaS テナント環境を使用しました。 選択されたベンチマークは、二つの特定領域を検証：ファイルシステムに書き込み優位の負荷を与えるデータ取り込みパフォーマンスと、読み取りに集約されるデータ分析パフォーマンスです。結果は以下のように、両方のベンチマークで改善が見られました。 ベンチマークタイプ ベンチマーク種類 ベンチマーク結果 データ取り込み 1B のレコード変換と書き込み 110% – 260% 高速化 データ分析 1B のレコード読み取りと計算 10% – 23% 高速化 この結果は、FSx for ONTAP を導入したパターンでは、十分に低いレイテンシが実現されることを示します。 効率性 このソリューションの費用対効果を検証するためには、データ圧縮率を証明する必要がありました。通常、FSx for ONTAP のコンパクト化、圧縮、重複排除機能を使用した場合、AWS はストレージ容量を 65% 削減できることを確認しています。 複数のテストを実施した結果、システム側で圧縮を行わない NFS ファイルシステムと比較して、ストレージ容量が平均 80% 削減されました。非圧縮ファイルシステムサイズと圧縮ファイルシステムサイズの差は約 10TB/2TB で、圧縮率は 5:1 となりました。達成される圧縮率はさまざまで、データセットの構成や疎性（スパース性）などの複数の要因によって異なります。 ベンチマークタイプ ベンチマーク種類 ベンチマーク結果 データセットタイプ1 合成された通信事業データセット 85% 圧縮 データセットタイプ2 合成された通信事業データセット 75% 圧縮 可用性 FSx for ONTAP のもう一つの特徴は、AZ 間接続性です： アクティブストレージシステムは、どのアベイラビリティゾーンからでも分散アプリケーションによってアクセスできます。これは EFS One Zone の場合とは異なり、EFS One Zone のデプロイメントは、それが存在する同じ AZ 内からのみ EFS CSI ドライバによってマウント可能です。 マルチ AZ の EKS トポロジーを維持するには、EFS ファイルシステムを複数の AZ に分散する EFS Standard で展開する必要があります。これは、回復力と可用性を高めますが、コストの増加というトレードオフを伴います。 FSx for ONTAP では、single-AZ 展開タイプのファイルシステムは、どのアベイラビリティゾーンからでも NFS でマウント可能です。これは、EKS クラスタが可用性と標準の展開テンプレートを維持する一方で、NFS ストレージは可用性を下げて提供されることを意味します。これは、オンプレミスとクラウドを比較する場合など、クラウド移行プロジェクトにとって重要です。詳細については、ブログ記事 Amazon FSx for NetApp ONTAP のシングルアベイラビリティーゾーン デプロイメント利用による VMware Cloud on AWS のストレージコストの削減 を参照してください。 クラウドへの移行をめぐる話題は、コストから始まることがあります。そのため、同等の条件で比較することが重要になります。オンプレミスにマルチサイトレプリケーションがない場合、One Zone ファイルシステムがそれに相当します。もう一つの重要な考慮点は、特定のアプリケーションの要件です。ここでのトレードオフ対象は、可用性、コスト、持続可能性です。 One Zone の導入パターンでストレージの容量を削減すれば、基盤となるインフラが削減されるため、ソリューションのカーボンフットプリントも削減されます。 まとめ MYCOM OSI は、データ集約的な通信事業者のアシュアランスにおいてストレージソリューションを進化させ、顧客固有のニーズに最適なストレージソリューションを採用することができました。進化したストレージアーキテクチャは、特に大規模な履歴データセットを持つ通信事業者の顧客にとって、パフォーマンスの向上とコスト削減を同時に実現しました。Amazon EFS と Amazon FSx for ONTAP の両方をサポートすることで、適切な業務に適切なツールを選択する柔軟性を提供します。 MYCOM OSI は、一貫した SaaS アーキテクチャを維持するための標準的なパターンセットを提供しながらも、特定の要件を満たす柔軟なテナントオプションを提供する能力を高めました。MYCOM OSI は、通信事業者の顧客全体の過去のデータサイズと可用性要件を評価することで、その顧客ベースに対して可能な限り最高のコストパフォーマンスと投資収益率（ROI）を提供することができました。 通信事業者は、MYCOM OSI のアシュアランスクラウドサービス（ACS）プラットフォームのようなクラウドネイティブな SaaS ソリューションを採用することで、アシュアランスアプリケーションの総所有コスト（TCO）を改善することができます。 翻訳はネットアップ合同会社の榎本様、監修はエンタープライズサポートの岡田が担当しました。 . . MYCOM OSI – AWS Partner Spotlight MYCOM OSI は、デジタル時代の通信サービスプロバイダ向けにアシュアランス、オートメーション、アナリティクスの SaaS アプリケーションを提供する AWS パートナーです。 MYCOM OSIへのお問い合わせ | Partner 概要