本稿では株式会社NTTドコモにおいて、映像配信サービス『Lemino』の開始にあわせて配信基盤を再構築し、数百万規模の同時視聴ライブ配信を実現した取り組みについて、全4回に分けてご紹介します。この取り組みについて概要をご覧になりたい方は 導入事例ページ もご覧ください。 前回の記事は以下です。 第一回　適切なデータストアの選定とアーキテクチャの見直し 第二回　アクセスの急増に対する対応策〜キャッシュ戦略とバックエンドの保護〜 1.需要予測の難しさとキャッシュ戦略・バックエンドの保護の必要性 システムを設計するにあたり、どの程度リソースを用意するべきか、正確に推測するのは容易なことではありません。ビジネス目標に対応したスケーラビリティを確保しようとするのは通常のことですが、例えば、ある Live 配信のビジネス目標とされる視聴ユーザー数が A人だった場合、それに対応したシステムを作るには何が必要でしょうか？ まず、ビジネスの観点での需要予測を、システムを設計するのに十分な粒度に落とし込む必要があります。システムを設計するのに必要な需要予測は機能別の API ごとの最大ピークアクセスが想定されるべきです。例えば、配信開始時間があらかじめ告知されている Live の場合は、配信開始時間の数分前に視聴開始が集中することが想像できます。そうした場合には視聴開始にまつわる API を視聴ユーザー数 A人が数分間、数秒間といった短い間に実行する可能性があり、そのピークに耐える必要があります。配信開始時間が正確にわからない場合、視聴ユーザーA人はまばらにアクセス開始するかもしれません。配信の特性を踏まえて、過去の同様の配信時の実績データなどを踏まえた知見から予測していくことになります。 また、視聴開始以外の API にスパイクアクセスは必ずしもこないことも考慮すべきです。アプリケーションを初回ダウンロードしてユーザー登録をするための API はライブを見たいユーザーのなかで初回にアプリにアクセスするユーザーだけが実行する処理となり、ライブ直前に行う必要がある処理ではありません。事前にアプリをダウンロードし登録を済ませてくれたユーザーが多ければ、その API についての秒単位の需要予測は必ずしも高くないかもしれません。配信を視聴するための契約をする API やアカウントを作成するAPIについても同様です。余剰のリソースを無駄に確保しないためにも本当に高いトランザクションを捌く必要があるAPIはどれか、認識しておくことが重要です。 例）視聴ユーザー数 A人でも視聴開始のアクセス数は分散する どの API がどの程度のスパイクアクセスに耐えるべきか、需要予測を適切に行うには過去の配信時の実績ベースのデータが有用です。過去の配信時の実績データを活かす仕組みが必要になります。これまでに行ったことがない配信を実施する場合、正確に需要予測をする難易度は上がります。 需要予測を正確に行うことができれば、多くのユーザーに最適なシステムリソースでサービス提供が可能になります。しかし、需要予測は必ず当たるとはかぎりません。急にその Live 配信が話題になり、視聴数が一気に跳ね上がる可能性があります。できるだけスケーラブルに、コスト効率よくサービス提供するためにはキャッシュ戦略が必要となり、需要予測が想定を超えた場合にビジネス影響範囲を小さくするためにはバックエンドの保護が必要になります。 2.キャッシュ戦略 キャッシュを活用することはバックエンドに何度も問い合わせることをしないため、より低レイテンシーでコスト効率よく、スパイク時の影響を最小限にすることにつながります。 AWS のサービスを活用するとデータ特性に応じた複数箇所でのCacheを作成することが可能で、Lemino では以下のように使い分けしています。 Amazon CloudFront エッジロケーションというグローバルのネットワークを経由してコンテンツを配信。 応答がユーザー情報に依存しない API はCDN（Contents Delivery Network）でキャッシュすることで負荷及び応答性能を大幅に改善 例）クライアント向けの作品情報の取得 Amazon DynamoDB Accelerator (DAX) 更新頻度が少なく、アプリケーションからの読み込みアクセスが多いレコード 例）アプリケーション内での映像情報の取得 Amazon DynamoDB DynamoDB に RDS と同一のデータを持たせ、キャッシュ用途のように、ユーザーの読み込みリクエストで活用することで、高い秒間の読込み性能が必要なデータをスケーラブルに、運用負荷少なく管理 例）購入情報等 ※RDS の Reader や ElastiCache を活用することも RDS の Read 性能を上げたい場合は選択肢ですが、ライブ配信開始時のような急激なスパイク負荷を想定する場合、インスタンス追加に伴うスケールアウト完了までの時間を許容できませんでした。その点、DynamoDB のオンデマンドキャパシティモードでは、該当テーブルの以前のピーク時のトラフィックの最大 2 倍まで即座にスケールできます。RDS の Reader や ElastiCache のノードの追加が流量の増加に間に合わなかった場合のサービスへの影響と運用の手間などを考慮し、DynamoDB に一部のデータを常に同期することを選択しています。 このほかに、アプリケーション側でも、ユーザに依存せず再利用可能なデータをローカルでキャッシュすることでデータストアの負荷を抑制しています。様々な場所で可能な限りキャッシュを活用することはバックエンドの保護につながっています。 3.バックエンドの保護 需要予測の精緻化とキャッシュの活用をしても、バックエンドに対して予測を上回るリクエストがくる可能性は0にはなりません。一部の API 負荷の想定外の高まりで、バックエンドの使用率が増えることでサービス全体に影響を与えることや、配信以外の共通基盤への影響は避けなければなりません。バックエンドの許容量やボトルネックとなる API の閾値をベースに、想定を超えるリクエストについてはスロットリングするか、待機させることが必要です。現在接続しているユーザーの処理を優先し、新規接続については仮想待合室などでコントロールを行えるようにする、等の工夫によりサービス全体への影響は避け、想定外のアクセス急増にも対応できるようにしておきます。 例えば、1分間でX回処理する性能と、1秒間でX回処理する性能では、当たり前ですが、事前に用意しておくべきシステムリソースが異なります。数秒待たせるだけで、必要なシステムリソースを抑え、スパイクアクセスに耐えきれないことによるサービス障害を抑えることが可能になるケースもあります。 そのアクセスはどの程度ならユーザー体験を損ねずに待たせることが可能か、どの程度時間があればリソースを追加することができるのかも検討しつつ、スパイクアクセスがサービス全面停止に繋がらないようにする必要があります。 Lemino のサービスでは大規模なスパイクアクセスが発生する場合には契約などの一部の導線に仮想待合室を設置しています。 仮想待合室のアーキテクチャは Virtual Waiting Room を参考にスケーラビリティを改良しています。 Lemino のサービスは複数のシステムが連携して動くため、dアカウントの認証などは別の担当チームがあり、自分たちのチームだけではスケールをコントロールできないことがあります。 最後の手段として、他システムも含めたバックエンドを保護するためにスロットリングさせることも選択肢です。 4.まとめ アクセスの急増に対する対応策として、まずは需要予測を精緻化し、事前に必要となるシステムリソースを認識することが大切です。それを上回るスパイクアクセスに備えて、キャッシュ戦略とバックエンドの保護が大切であることをお伝えしました。 アクセスの急増を想定し、想定外に備えるシステムを検討中の皆様の参考にしていただければ幸いです。 著者について 株式会社NTTドコモ 第一プロダクトデザイン部 映像サービス担当　松原拓也 株式会社NTTドコモで提供している映像配信サービス『Lemino』のアーキテクト及び、バックエンドシステムのリードエンジニア、プロジェクトマネージャーを担当。 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ストラテジックインダストリー技術本部　津和崎美希 通信業界のお客様を担当するソリューション アーキテクト。普段はお客様のAWS活用を支援していますが、ObservabilityについてはAWS社内でコミュニティ活動をしています。ここ数年、動画配信等、Media Serviceのご支援にも手を広げ、幅広いAWS活用をご支援しています。

みなさん、こんにちは。パブリックセクターでビジネス開発、マイグレーションプログラム推進をしている今井です。 アマゾン ウェブ サービス ジャパン（以下、AWS）では、AWSへの大規模なシステムの移行を実現し、ひいてはお客様のデジタルトランスフォーメーションをサポートする 「 AWS ITトランスフォーメーションパッケージ（ITX） 」を2021年に、2022年には内容を強化・拡大した「 AWS ITトランスフォーメーションパッケージ2.0（ITX2.0） 」をリリースしました。2023年にはITXパッケージ2.0をより包括的に進化させた「 AWS ITトランスフォーメーションパッケージ 2023 ファミリー（ITX 2023） 」をリリースし、2021年以来多くのお客様にご活用頂き、企業のITトランスフォーメーションを支援してきました。 今回のブログでは、2024年6月にリリースした最新版の「 AWS ITトランスフォーメーションパッケージファミリー（ITX） 」の中で新たに取り入れられた、公共のお客様に向けて開発されたAWS ITトランスフォーメーションパッケージ 公共版（以下、ITX for PS）についてご紹介します。（ 最新版のITX資料ダウンロードはこちらから ） 公共領域におけるITXに対するお客様からのご要望 日本の社会において労働人口の減少や高齢化などが進行する中、デジタル技術の活用による省力化・効率化が不可欠となっています。政府はこうした課題に対応すべく、行政は勿論の事、医療・教育も含め、国民一人ひとりの暮らしを豊かにするデジタル社会の実現を目指すための政策を推進しており、クラウドの活用もそうした目的を達成するための一つの手段として検討が進められています。例えば中央省庁や地方自治体におけるクラウドの検討状況に目を向けると、クラウド・バイ・デフォルト原則のもとに、今後中央省庁において約1100の政府情報システムのクラウド移行の検討が行われ、また地方においても約1700団体が20の標準業務のクラウド移行を2025年度末までに行う方針です。 こうした状況の中、国においてはデジタル庁が「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」（以下基本方針）の中でクラウド利用のメリットを十分に享受するため、システム刷新に伴いマネージドサービスを活用したシステムのモダン化について言及するなど、スマートにクラウドを利用することを勧めています。 今後さらに公共の領域でもシステムのクラウドへの移行が行われていくことが考えられますが、クラウドのメリットを享受するために単純なクラウド移行ではなくシステムのモダン化の検討を効果的に行うことや、公共特有のNW構成といった基盤設計、各種ガイドラインへの準拠の必要性など、公共分野特有の要素に頭を悩ませるお客様の声も聞こえてきます。 今回、AWSへの大規模な移行を考える官公庁や医療、教育、NPOといった公共の分野のお客様向けに従来のITXの内容を拡張し、ITX for PSとしてリリースいたします。 ITX for PSとは？ ITX for PSでは公共領域においても求められるシステムのモダン化や公共分野特有の要素への対応を中心に、従来のITXを拡張する形で、１． システムのモダン化支援 、２． 公共専門分野支援 、３．システムをモダン化する際に鍵となる データ・生成AIの活用支援 を提供すると共に、公共分野で見られる調達のプロセスを考慮したパッケージ構成にしています。 １．システムのモダン化を進めるための支援 AWSへの移行に伴いシステムのモダン化を進めるための支援としては大きく３つのカテゴリを用意しています。移行における初期の企画・検討フェーズにおけるアセスメント支援、アセスメント後に要件の定義や仕様を検討する際に机上調査にとどまらないプロトタイプの支援やモダン化の体験をしてもらうモダン化開発支援、そして運用に入ったシステムのクラウド利用を最適化することによるコスト最適化の支援です。 システムのモダン化を進めるためには、次期システム検討の早い段階でモダン化による費用対効果の検証や、実現性の検証を行うことが重要になると考えられます。そうした検証を支援するために、次期システムの企画・移行検討のフェーズでシステムのモダン化を検討するための各種アセスメントを提供します。 運用生産性の向上など単純な利用コスト比較にとどまらないクラウド移行によるTCO分析を行う「クラウドエコノミクス」、特定業務システムのTo Beアーキテクチャーを検討してモダン計画のインプットとする「モダナイゼーションアセスメント」、移行対象システムを俯瞰的に分析しシステム特性に応じたクラウド移行パターンを推奨する「アプリケーションポートフォリオアセスメント」、マネージドなデーターベース移行を行うために必要な検証を支援する「データベースフリーダム」、システム環境を第3者機関により評価し、サードパーティーライセンスを最適化する「ライセンス評価・最適化プログラム」といった モダン化アセスメント を用意しています。 また、こうしたアセスメントを行ったうえで要件定義や仕様検討のフェーズでは、前フェーズで検討されたアーキテクチャーをもとにしたプロトタイプをAWSが開発する「プロトタイピング支援」や、実際にシステムをモダン化するパイロットプロジェクトを体験し開発チームにノウハウと成功体験を得て頂くための「体験型ワークショップ」といった、 モダン化開発支援 も提供いたします。 そしてAWSに移行したシステムに関し、運用・保守のフェーズでは、よりスマートにクラウドを活用することでコストの最適化を図るための コスト最適化支援 を提供します。 ２．公共専門の分野に関するクラウド活用支援 公共特有の要素に関するクラウド活用支援では、中央政府、自治体、教育機関、医療機関、研究機関など、公共のお客様の特有の専門知識、技術知識を持った技術チームがお客様の課題を解決支援します。また、公共のお客様の状況を踏まえたクラウド人材育成やクラウド推進組織の立ち上げに関する支援、公共調達のプロセスの中でAWSの提供するクレジット提供プログラムの活用支援といったものを提供します。 ITX for PSではシステムをクラウドに移行する際、公共分野での特有な要素に対する支援も用意しています。公共のお客様で見られる閉域網におけるネットワーク設計支援や、IaCが活用されるガバメントクラウドにおけるテンプレートの利用に対する支援、監督省庁等から出される各種ガイドラインに対応したクラウドの利用方法を検討するための支援など、 公共専門分野支援 を用意しています。 また、クラウドの活用において技術以外の要素で重要となる人材育成・組織の面に関しては、クラウドへの大規模移行に際し、組織的な準備ができているかを評価する「移行準備評価」、AWSに携わる要因のスキルギャップの特定とギャップ解消を支援する「スキルギャップ分析」、そうしたアセスメントの結果をもとに公共のお客様のクラウド推進組織（CCoE）の立ち上げ検討や人材育成の支援を行う 公共クラウド人材・組織育成支援 も提供いたします。 さらにAWSでは、移行時の経済的負担を軽減するMigration Acceleration Program（MAP）と呼ばれるAWSの利用料に対するクレジット提供プログラムを用意していますが、公共の調達プロセスの中でMAPを活用するタイミングを検討したり、分離調達の際にどのようなスキームにするとよいかといったご提案等、 公共調達におけるMAPの活用支援 も提供しております。 ３．データ・生成AIの活用支援 モダン化を含むシステムの刷新に際しては、業務改革（ビジネスプロセスリエンジニアリング、BPR）も併せて行うことがデジタル庁の基本方針の中でも推奨されています。業務改革を検討する際、システムの観点からはデータドリブンの意思決定に寄与するデータ基盤や、そのデータを用いた生成AIの活用が求められることも考えられます。 そうした状況にお応えするためにAWSの専門チームがお客様の現行データ基盤を分析し、モダナイゼーションのポイントや、To-Beアーキテクチャ案を提示する「データ基盤モダン化支援」、公共分野における生成AIの代表的なユースケースの実装支援テンプレートによる「生成AI活用検討支援」といった データ・生成AIの活用支援 を用意いたします。 ここに挙げたような支援プログラムを公共調達のサイクルの中で活用頂く事で、官公庁や医療、教育、NPOといった公共の分野のお客様は、クラウド移行を検討するための最適なプロセスを効果的に進めることができるようになります。 ITX for PSのリリースに際したお客様やパートナー様の声 デジタル庁 Chief Cloud Officer 山本教仁様 デジタル庁では、「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」の中でスマートなクラウドの利用を掲げており、マネージドサービスやIaC (Infrastructure as Code)を活用した自動化によるコスト削減等を説明しています。これら施策はガバメントクラウドの技術要件にも含まれ、採用したクラウドサービスプロバイダーにもその推進をご協力いただいています。 その中で、AWSからは、スマートなクラウド利用を支援する内容をわかりやすく1つのパッケージメニュー「ITX for PS」としてまとめていただき、提供いただきます。これを活用することで、スマートなクラウドの利用が促進され、クラウドに関するスキル育成、システム開発の短期間化や継続的な開発・改善の実現、そして、コスト削減とセキュリティの向上につながると考えてます。 日本政府のクラウド・バイ・デフォルト原則に基づいた、中央官庁および地方公共団体におけるクラウド移行の取り組みに対して、このような支援パッケージが用意されることを歓迎します。 PwCコンサルティング合同会社 執行役員 パートナー デジタルガバメント統括 林泰弘様 AWSは、デジタル庁が発足した2021年から、ガバメントクラウドやガバメントソリューションサービスの導入、自治体基盤システムの標準化および共通化を進めてこられました。これらを通じて蓄積されてきた知見、ノウハウが集約された「ITX for PS」は、中央省庁や自治体のデジタルシフトを加速するものと期待しています。PwCコンサルティングは「AWSコンサルティングパートナー」に認定されており、多くのクライアントに「ITトランスフォーメーションパッケージ」の導入を支援してきました。引き続き、AWSとともに、日本全体のデジタルシフトの推進に取り組んでいきたいと考えております。 ITX for PSの始め方 ITX for PSのご利用に向けて、入り口は2つあります。 1） Webフォーム からお問い合わせ頂く。あるいは 2）担当営業までご連絡ください。 AWSクラウドへの移行やモダナイゼーションにご関心をお持ちのお客様は、 AWSで移行とモダナイズ のページをご確認ください。AWSへの移行やモダナイゼーションに必要な情報が網羅されています。 ITX for PSにご興味をお持ちのお客様は、是非上記2つのいずれかよりAWSへお問合せください。 パブリックセクター統括本部 マイグレーション アドバイザー 今井 宏樹 パブリックセクター技術統括本部 CSM・パートナーソリューション本部 本部長 高田 智己 執行役員 パブリックセクター技術統括本部長 瀧澤 与一

本記事は 2024年2月2日に公開された ” Monitor embedding drift for LLMs deployed from Amazon SageMaker JumpStart ” を翻訳したものです。 生成 AI のワークロードで最も有用なアプリケーションパターンの 1 つが Retrieval Augmented Generation (RAG) パターンです。 RAG パターンでは、入力プロンプトに関連する参照コンテンツを探すために、埋め込みベクトル (テキスト文字列の数値表現) に対して類似検索を実行します。埋め込みはテキストの情報内容を捉え、自然言語処理 (NLP) モデルが言語を数値的に処理できるようにします。埋め込みは浮動小数点ベクトルであるため、3 つの重要な質問を用いて分析することができます。参照データは時間とともに変化するか、ユーザーが尋ねる質問は時間とともに変化するか、そして最後に、参照データが尋ねられている質問をどの程度カバーできているかです。 この記事では、埋め込みベクトル分析とドリフト検出の注意点について学びます。埋め込みは一般的な自然言語処理モデルと特に生成 AI ソリューションにおいて重要な入力データとなるため、時間の経過とともに埋め込みが変化 (ドリフト) するかどうかを測定する方法が必要です。このポストでは、 Amazon SageMaker JumpStart からデプロイされた大規模言語モデル (LLM) を用いてクラスタリング手法によりベクトル埋め込みのドリフトを検出する例を示します。また、後述するエンドツーエンドのサンプルアプリケーションを使用するか、あるいはその一部のみを使用して、これらの概念を実際に体験することができます。 RAG の概要 RAG パターン では、PDF ドキュメント、Wiki 記事、通話の書き起こしなどの外部ソースから知識を検索し、その知識を使って LLM に送られる指示のプロンプトを補強できます。これにより、LLM は応答を生成するときに、より関連性の高い情報を参照できます。例えば、LLM にチョコチップクッキーの作り方を尋ねた場合、自分のレシピライブラリから情報を含めることができます。このパターンでは、レシピのテキストが埋め込みモデルを使って埋め込みベクトルに変換され、ベクトルデータベースに保存されます。入力された質問も埋め込みベクトルに変換され、入力された質問と、類似検索で見つかった参照データが、LLM へのプロンプトに含められます。 埋め込みベクトルが生成される仕組みとそのベクトルについてドリフト分析を実行する方法について、詳しく確認していきましょう。 埋め込みベクトルの分析 埋め込みベクトルは、データの数値表現であり、これらのベクトルを分析することで、参照データの洞察が得られます。この洞察は、後にドリフトの兆候を検出するのに利用できます。埋め込みベクトルは、n 次元空間内の項目を表し、n は大きな値になることが多いです。例えば、この記事で使用されている GPT-J 6B モデルは、4096 次元のベクトルを生成します。ドリフトを測定するために、アプリケーションが参照データと入力プロンプトの両方の埋め込みベクトルをキャプチャすると仮定します。 まず主成分分析 (PCA) を使って次元削減を行います。PCA はデータの変動の大部分を残しつつ次元数を減らそうとします。この場合、分散の 95 % を保持する次元数を見つけることで、2 標準偏差の範囲内にあるものがすべて取り込まれるはずです。 次に、K-Means 法を用いてクラスタ中心の集合を同定します。K-Means 法は、各クラスタが密集している、またはまとまりが高くなるようにデータポイントをグループ化し、クラスタ間の距離が可能な限り遠くなるように試みます。 次の図に示されるクラスタリング出力に基づいて、以下の情報を計算します。 95 % の分散を説明する PCA の次元数 各クラスター中心点 (重心) の位置 さらに、次の図に示すように、各クラスタでサンプルの割合が高いか低いかを確認します。 最後に、この分析を使って以下の値を計算します。 慣性 (inertia)  – 慣性は、クラスタ中心への 2 乗距離の和で、K-Means でデータがどの程度うまくクラスタリングされたかを測るものです。 シルエットスコア (silhouette score)  – シルエットスコアは、クラスタ内の一貫性を検証する尺度で、-1 から 1 の範囲の値をとります。1 に近い値は、クラスタ内のデータポイントが同じクラスタの他のポイントに近く、別のクラスタのポイントから離れていることを意味します。クラスタ内外の集まり具合の指標の視覚的な表現が次の図に示されています。 これらの情報を定期的にキャプチャすれば、参照データとプロンプトの埋め込みスナップショットを得ることができます。この情報をから埋め込みのドリフトの兆候を分析できます。 埋め込みドリフトの検出 参照データの埋め込みとプロンプトの埋め込みを含むデータのスナップショットを通して、定期的に、クラスタリング情報を比較できます。まず、分散の 95 % を説明するのに必要な次元数、慣性、クラスタリングジョブのシルエットスコアを比較できます。次の表に示すように、ベースラインと比較して、最新の埋め込みのスナップショットでは分散を説明するのに 39 次元多くの次元が必要となり、データがより分散していることを示しています。慣性も上がっており、サンプルがクラスタ中心からより離れた位置にあることを示しています。さらに、シルエットスコアが下がっているため、クラスタが明確に定義されていないことを意味しています。プロンプトデータの場合、これはシステムに入ってくる質問の種類がより多くのトピックに及ぶためかもしれません。 次に、次の図では、各クラスターのサンプル割合がどのように経時的に変化したかを確認できます。これにより、新しい参照データが以前のデータとほぼ同様なのか、新しい領域をカバーしているのかがわかります。 最後に、クラスター中心が移動しているかを見ることで、クラスター内の情報がドリフトしているかを確認できます。次の表で示されています。 質問の対象となる参照データの範囲 参照データと受け付けた質問がどの程度整合しているかを評価することもできます。これを行うには、各プロンプトの埋め込みベクトルを参照データのクラスタに割り当てます。次に、各プロンプトからそのクラスタの中心までの距離を計算し、その平均、中央値、標準偏差を求めます。この情報を保存し、時間の経過に伴ってどのように変化するかを確認できます。 次の図は、プロンプトの埋め込みと参照データの中心間の距離を時間の経過とともに分析した例を示しています。 ご覧のとおり、プロンプトの埋め込みと参照データの中心の平均距離、中央値距離、標準偏差距離の統計は、最初のベースラインから最新のスナップショットにかけて減少しています。距離値そのものの意味を解釈するのは難しいものの、トレンドを使って参照データと質問の間の内容の類似性が時間とともに良くなっているのか悪くなっているのかを判断できます。 サンプルアプリケーション 前のセクションで説明した実験結果を収集するために、SageMaker JumpStart からデプロイされた RAG パターンに使われるモデルを使用して、RAG パターンを実装するサンプルアプリケーションを構築しました。 このモデルは、 Amazon SageMaker のリアルタイムエンドポイントでホストされています。 アプリケーションには以下の 3 つのコアコンポーネントがあります。 プロンプトをキャプチャするユーザーインターフェイスと、LangChain を使った RAG オーケストレーション層を含む対話型フローを使用しています。 データ処理フローは、PDF ドキュメントからデータを抽出し、 Amazon OpenSearch Service に保存される埋め込みを作成します。また、これらをアプリケーションの最終的な埋め込み偏差分析コンポーネントでも使用しています。 埋め込みは Amazon Kinesis Data Firehose 経由で Amazon Simple Storage Service (Amazon S3) でキャプチャされ、 AWS Glue の抽出、変換、ロード (ETL) ジョブと Jupyter ノートブックの組み合わせを実行して、埋め込み分析を行います。 次の図は、エンドツーエンドのアーキテクチャを示しています。 完全なサンプルコードは GitHub で公開されています。 提供されているコードは 2 つの異なるパターンで用意されています。 Streamlit フロントエンドを持つフルスタックのサンプルアプリケーション – Amazon Elastic Container Service (Amazon ECS) と AWS Fargate で実行される LangChain を使った RAG の連携層と Streamlit を使ったユーザーインターフェースを持つ、エンドツーエンドのアプリケーションを提供します。 バックエンドアプリケーション – フルアプリケーションスタックをデプロイしたくない場合は、 AWS Cloud Development Kit (AWS CDK) スタックのバックエンドのみをデプロイし、提供された Jupyter ノートブックを使って LangChain を使った Retrieval Augmented Generation (RAG) の連携を実行することができます。 提供されたパターンを作成するには、以下のセクションで説明されている複数の前提条件があり、まず生成モデルとテキストエンベディングモデルをデプロイした後、追加の前提条件に移ります。 SageMaker JumpStart によるモデルのデプロイ 両方のパターンでは、埋め込みモデルと生成モデルをデプロイすることを前提としています。このために、SageMaker JumpStart から 2 つのモデルをデプロイします。最初のモデル GPT-J 6B は埋め込み モデルとして使用し、2 つ目の Falcon-40b はテキスト生成に使用します。 これらのモデルは、 AWS マネジメントコンソール 、 Amazon SageMaker Studio 、またはプログラムによって SageMaker JumpStart からデプロイできます。詳細については、 JumpStart 基盤モデルの使用方法 を参照してください。デプロイを簡素化するために、SageMaker JumpStart によって自動的に作成されたノートブックから派生した 提供されているノートブック を使うことができます。このノートブックは、SageMaker JumpStart の ML ハブからモデルを取得し、2 つの別々の SageMaker リアルタイムエンドポイントとしてデプロイします。 サンプルノートブックには、クリーンアップ用のセクションもありますが、そのセクションは実行しないでください。実行すると今デプロイしたばかりのエンドポイントが削除されます。このハンズオンチュートリアルの最後に、クリーンアップを完了させます。 エンドポイントのデプロイが正常に完了したことを確認したら、サンプルアプリケーション全体をデプロイする準備が整います。ただし、バックエンドと分析用のノートブックのみを探索したい場合は、次のセクションで説明するように、そちらだけをデプロイすることもできます。 オプション 1: バックエンドアプリケーションのみのデプロイ このパターンでは、バックエンド ソリューションのみを展開し、Jupyter ノートブックを使ってソリューションと対話できます。UI の部分を構築したくない場合に、このパターンを使用します。 前提条件 次の前提条件を満たしている必要があります。 SageMaker JumpStart を使ってモデルエンドポイントのデプロイ – 上記で説明したように、SageMaker JumpStart を使用してモデルを SageMaker リアルタイムエンドポイントをデプロイします。 デプロイ時のパラメーター設定 – 次の情報を設定します。 テキストモデルエンドポイント名 – SageMaker JumpStart で展開したテキスト生成モデルのエンドポイント名 埋め込みモデルエンドポイント名 – SageMaker JumpStart で展開した埋め込みモデルのエンドポイント名 AWS CDK を使用したリソースのデプロイ 前のセクションで示したデプロイパラメータを使用して、AWS CDK スタックをデプロイしてください。AWS CDK のインストールについて詳しくは、 AWS CDK の概要 を参照してください。 AWS CDK のデプロイに使用するワークステーションで Docker がインストールされ、実行されていることを確認してください。詳しくは Get Docker を参照してください。 $ cd pattern1-rag/cdk $ cdk deploy BackendStack --exclusively -c textModelEndpointName=<Enter the SageMaker Endpoint Name for the Text generation model> \ -c embeddingsModelEndpointName=<Enter the SageMaker Endpoint Name for the Text embeddings model> または、  pattern1-rag/cdk ディレクトリの cdk.context.json というファイルにコンテキスト値を入力し、 cdk deploy BackendStack --exclusively を実行することもできます。 デプロイ時に、ノートブックを実行するために必要な情報が出力されます。次のセクションに示されているように、質問と回答をする前に参照ドキュメントの埋め込みを行う必要があります。 参照ドキュメントの埋め込み この RAG アプローチでは、まず参照ドキュメントをテキストエンベディングモデルで埋め込み、ベクトルデータベースに格納します。 このソリューションでは、PDF ドキュメントを取り込むパイプラインが構築されています。 Amazon Elastic Compute Cloud (Amazon EC2) インスタンスが作成され、そのインスタンスに Amazon Elastic File System (Amazon EFS) のファイルシステムがマウントされ、PDF ドキュメントを保存するための環境が構築されています。 AWS DataSync タスクが 1 時間ごとに実行され、EFS ファイルシステムパスで見つかった PDF ドキュメントを取得し、テキスト埋め込み処理用の S3 バケットにアップロードします。このプロセスは参照ドキュメントを埋め込み、その埋め込みを OpenSearch Service に保存します。また、後の分析のために、Kinesis Data Firehose を通じて埋め込みアーカイブを S3 バケットに保存します。 参照ドキュメントを取り込むには、次の手順を実行します。 作成したサンプルの EC2 インスタンス ID (AWS CDK の出力から JumpHostId の値を参照) を取得し、 AWS Systems Manager の機能である Session Manager を使用して接続してください。手順については、 AWS Systems Manager Session Manager を使用して Linux インスタンスに接続する を参照してください。 EFS ファイルシステムがマウントされているディレクトリ /mnt/efs/fs1 に移って、まず mkdir ingest を実行して ingest というフォルダを作成します。次に cd ingest を実行して作成したフォルダに移動します。 $ cd /mnt/efs/fs1 $ mkdir ingest & cd ingest ingest ディレクトリに参照する PDF ドキュメントを追加します。 DataSync タスクは、この埋め込みプロセスを開始するために、このディレクトリ内のすべてのファイルを Amazon S3 にアップロードするように設定されています。 DataSync タスクは 1 時間おきにスケジュールされて実行されます。オプションで、タスクを手動で開始して、追加した PDF ドキュメントの埋め込みプロセスを即座に開始することもできます。 タスクを開始するには、AWS CDK の出力から DataSyncTaskID のタスク ID を特定し、 デフォルト設定でタスクを開始 してください。 埋め込み作成後は、次のセクションで示すように Jupyter ノートブックから RAG の質問に答えることができます。 Jupyter Notebook を使った質問と回答 次の手順を完了してください。 AWS CDK の出力 NotebookInstanceName から SageMaker ノートブックインスタンス名を取得し、SageMaker コンソールから Jupyter Lab に接続します。 ディレクトリ fmops/full-stack/pattern1-rag/notebooks/ に移動します。 ノートブックインスタンス内でノートブック query-llm.ipynb を開き、実行して RAG を使って質問と回答を行います。 ノートブックでは conda_python3 カーネルを使用するようにしてください。 このパターンは、フルスタックアプリケーションに必要な追加の前提条件をプロビジョニングする必要なく、バックエンドのソリューションを検討するのに役立ちます。次のセクションでは、生成 AI アプリケーションとの対話用のユーザー インターフェイスを提供するため、フロントエンド部分も含めたフルスタック アプリケーションの実装について説明します。 オプション 2: Streamlit フロントエンドのフルスタックサンプルアプリケーションのデプロイ この手法により、質問と応答のユーザーフロントエンドインターフェイスを備えたソリューションをデプロイできます。 前提条件 サンプルアプリケーションをデプロイするには、次の前提条件を満たす必要があります。 SageMaker JumpStart を使ってモデルエンドポイントのデプロイ  – 提供されたノートブックを使用して、前のセクションで説明されているように、SageMaker JumpStart を使用してモデルを SageMaker リアルタイムエンドポイントにデプロイします。 Amazon Route 53 ホストゾーン – このソリューションで使用するために、 Amazon Route 53 の パブリックホストゾーン を作成します。または、 example.com のように既存の Route 53 パブリックホストゾーンを使用することもできます。 AWS Certificate Manager 証明書 – Route 53 ホストゾーンドメイン名および適用対象のサブドメイン ( example.com および *.example.com など) 用に、 AWS Certificate Manager (ACM) の TLS 証明書をプロビジョニングします。手順については、 パブリック証明書のリクエスト を参照してください。この証明書は、 Amazon CloudFront およびロードバランサーのオリジンにおける HTTPS を構成するために使用されます。 デプロイ時のパラメーター設定  – 次の情報を設定します。 フロントエンドアプリケーションのカスタムドメイン名 – フロントエンドのサンプルアプリケーションにアクセスするためのカスタムドメイン名です。指定されたドメイン名は、フロントエンド CloudFront ディストリビューションを参照する Route 53 DNS レコードの作成に使用されます。たとえば、 app.example.com です。 ロードバランサーのオリジンとなるカスタムドメイン名 – CloudFront ディストリビューションのロードバランサーオリジン用のカスタムドメイン名です。指定されたドメイン名は、オリジンロードバランサーを参照する Route 53 DNS レコードの作成に使用されます。たとえば、 app-lb.example.com です。 Route 53 ホストゾーン ID – 指定されたカスタムドメイン名をホストする Route 53 ホストゾーン ID です。たとえば、 ZXXXXXXXXYYYYYYYYY です。 Route 53 ホストゾーン名 – 指定されたカスタムドメイン名をホストする Route 53 ホストゾーン名です。たとえば、 example.com です。 ACM 証明書 ARN – 指定されたカスタムドメイン名で使用される ACM 証明書の ARN です。 テキストモデルエンドポイント名 – SageMaker JumpStart でデプロイされたテキスト生成モデルのエンドポイント名です。 埋め込みモデルエンドポイント名 – SageMaker JumpStart でデプロイされた埋め込みモデルのエンドポイント名です。 AWS CDK を使用したリソースのデプロイ 前提条件でメモした展開パラメータを使用して、AWS CDK スタックをデプロイしてください。詳細については、 AWS CDK の使用開始 を参照してください。 Docker が AWS CDK のデプロイに使用されるワークステーションにインストールされており、実行中であることを確認してください。 $ cd pattern1-rag/cdk $ cdk deploy --all -c appCustomDomainName=<Enter Custom Domain Name to be used for Frontend App> \ -c loadBalancerOriginCustomDomainName=<Enter Custom Domain Name to be used for Load Balancer Origin> \ -c customDomainRoute53HostedZoneID=<Enter Route53 Hosted Zone ID for the Custom Domain being used> \ -c customDomainRoute53HostedZoneName=<Enter Route53 Hostedzone Name> \ -c customDomainCertificateArn=<Enter ACM Certificate ARN for Custom Domains provided> \ -c textModelEndpointName=<Enter the SageMaker Endpoint Name for the Text generation model> \ -c embeddingsModelEndpointName=<Enter the SageMaker Endpoint Name for the Text embeddings model> 上の例のコードでは、-c は入力時に指定するコンテキスト情報を表しています。もしくは、 pattern1-rag/cdk ディレクトリにある cdk.context.json ファイルにコンテキスト情報を記述し、 cdk deploy --all を実行することもできます。 bin/cdk.ts ファイルでリージョンを指定していることに注意してください。ALB アクセスログを設定するには、リージョンを指定する必要があります。デプロイする前に、このリージョンを変更することができます。 デプロイ時に、Streamlit アプリケーションにアクセスする URL が出力されます。次のセクションで説明するように、質問に対して回答できるようにする前に、参照ドキュメントを組み込む必要があります。 参照ドキュメントの埋め込み RAG アプローチでは、まず PDF ドキュメントをテキスト埋め込みモデルで処理を行い、ベクトルデータベースに保存します。このソリューションでは、PDF ドキュメントを取り込むためのパイプラインが構築されています。 初回デプロイオプションで説明したように、PDF ドキュメントの取り込み用に EC2 インスタンスが作成され、PDF ドキュメントを保存するために EFS ファイルシステムが EC2 インスタンスにマウントされています。1 時間ごとに DataSync タスクが実行され、EFS ファイルシステムパス内の PDF ドキュメントを取得して、テキスト埋め込みプロセスを開始するために S3 バケットにアップロードされます。このプロセスは参照ドキュメントに埋め込みを行い、埋め込みを OpenSearch Service に保存します。また、後の分析のために、Kinesis Data Firehose を介して埋め込みデータのアーカイブを S3 バケットに保存します。 参照ドキュメントを取り込むには、次の手順を実行してください。 作成された EC2 インスタンスのサンプル ID を取得 (AWS CDK の出力 JumpHostId を参照) し、Session Manager を使って接続します。 EFS ファイルシステムがマウントされている /mnt/efs/fs1 ディレクトリに移動し、 ingest というフォルダを作成します。 $ cd /mnt/efs/fs1 $ mkdir ingest && cd ingest ingest ディレクトリに、参照する PDF ドキュメントを追加します。 DataSync タスクは、このディレクトリ内のすべてのファイルを Amazon S3 にアップロードするよう設定されており、これによって埋め込み処理が開始されます。 DataSync タスクは 1 時間ごとに実行されます。追加した PDF ドキュメントの埋め込み処理を即座に開始したい場合は、手動でタスクを開始することもできます。 4. タスクを開始するには、AWS CDK 出力の DataSyncTaskID からタスク ID を特定し、 デフォルトでタスクを開始 します。 質問と回答 参照ドキュメントが埋め込まれた後、Streamlit アプリケーションにアクセスする URL にアクセスすることで、RAG の質問と回答をスタートできます。 Amazon Cognito 認証レイヤーが使用されているため、アプリケーションにはじめてアクセスする際は AWS CDK によってデプロイされた Amazon Cognito ユーザープール (ユーザープール名は AWS CDK の出力を参照) でユーザーアカウントを作成する必要があります。Amazon Cognito ユーザーを作成するための手順については、 AWS マネジメントコンソールで新規ユーザーを作成する を参照してください。 埋め込みドリフトの分析 このセクションでは、参照スデータ埋め込みとプロンプト埋め込みのベースラインを最初に作成してから、時間の経過とともにその埋め込みのスナップショットを作成することで、ドリフト分析を実行する方法を説明します。これにより、ベースラインの埋め込みとスナップショットの埋め込みを比較できます。 参照データとプロンプトの基準となる埋め込みベクトルの作成 参照データの埋め込み表現のベースラインを作成するには、AWS Glue コンソールを開き、ETL ジョブ embedding-drift-analysis を選択します。次のように ETL ジョブのパラメーターを設定し、ジョブを実行してください。 --job_type を BASELINE に設定します。 --out_table を参照埋め込みデータ用の Amazon DynamoDB テーブルに設定します。(テーブル名は AWS CDK 出力の DriftTableReference を参照してください。) --centroid_table を参照の重心データ用の DynamoDB テーブルに設定します。(テーブル名は AWS CDK 出力の CentroidTableReference を参照してください。) --data_path を S3 バケットとプレフィックスに設定します。例: s3:// <バケット名で置換> /embeddingarchive/ (バケット名は AWS CDK 出力の BucketName を参照してください。) 同様に、ETL ジョブ embedding-drift-analysis を使用して、プロンプト文章のベースラインの特徴ベクトルを作成します。ETL ジョブのパラメータを次のように設定してジョブを実行します。 --job_type を BASELINE に設定する --out_table をプロンプト文データの DynamoDB テーブルに設定する (テーブル名は AWS CDK の出力 DriftTablePromptsName を参照) --centroid_table をプロンプト分類データの DynamoDB テーブルに設定する (テーブル名は AWS CDK の出力 CentroidTablePrompts を参照) --data_path を S3 バケットのプレフィックスに設定する 例: s3:// <バケット名で置換> /promptarchive/ (バケット名は AWS CDK の出力 BucketName を参照) 参照データとプロンプトの埋め込みスナップショットの作成 OpenSearch Service に追加情報を取り込んだ後、ETL ジョブ embedding-drift-analysis を再実行して、参照データのベクトルのスナップショットを作成します。前のセクションで示したように、参照データのベクトルを作成するために実行した ETL ジョブと同じパラメータを使用しますが、 --job_type パラメータを SNAPSHOT に設定する点が異なります。 同様に、プロンプトの埋め込みスナップショットを取得するには、ETL ジョブ embedding-drift-analysis を再実行します。前のセクションで示したプロンプトの埋め込みベースラインを作成するために実行した ETL ジョブと同じパラメータを使用しますが、 --job_type パラメータを SNAPSHOT に設定することを除きます。 ベースラインとスナップショットの比較 参照データとプロンプトについて、埋め込みベースラインとスナップショットを比較するには、提供されたノートブック pattern1-rag/notebooks/drift-analysis.ipynb を使用します。 参照データやプロンプトの埋め込みベクトルの比較を行うには、各ノートブックの実行ごとに、ノートブックの DynamoDB テーブル名の変数 ( tbl と c_tbl ) を、適切な DynamoDB テーブルに変更してください。 ノートブックの変数 tbl は、適切なドリフトテーブル名に変更する必要があります。ノートブックでこの変数を設定する場所の例を以下に示します。 テーブル名は以下のように取得できます。 参照埋め込みデータについては、AWS CDK の出力 DriftTableReference からドリフトテーブルの名前を取得します プロンプト埋め込みデータについては、AWS CDK の出力 DriftTablePromptsName からドリフトテーブルの名前を取得します また、ノートブックの変数 c_tbl は適切な重心テーブル名に変更する必要があります。ノートブック内でこの変数を構成する場所の例を以下に示します。 以下のようにしてテーブル名を取得できます。 参照埋め込みデータとは、参照するデータセットを埋め込んだデータのことです。AWS CDK の出力 CentroidTableReference から、参照データセットが格納されたテーブル名を取得します。 プロンプト埋め込みデータとは、質問文(プロンプト)を埋め込んだデータのことです。AWS CDK の出力 CentroidTablePrompts から、プロンプトが埋め込まれたデータが格納されたテーブル名を取得します。 プロンプト文と参照データの類似度分析 まず、AWS Glue ジョブ embedding-distance-analysis を実行します。このジョブは、参照データの埋め込みに対する K-Means 評価からどのクラスターに各プロンプトが属するかを見つけます。次に、各プロンプトが対応するクラスター中心までの距離の平均値、中央値、標準偏差を計算します。 pattern1-rag/notebooks/distance-analysis.ipynb ノートブックを実行すると、時間の経過に伴う距離メトリクスのトレンドを確認できます。これにより、プロンプト埋め込みベクトルの距離分布の全体的なトレンドを把握できます。 ノートブック pattern1-rag/notebooks/prompt-distance-outliers.ipynb では、外れ値を検出する AWS Glue ノートブックです。これは参照データとは無関係のプロンプトが増えていないか特定するのに役立ちます。 類似スコアのモニタリング OpenSearch Service から得られるすべての類似スコアは、 rag 名前空間の下にある Amazon CloudWatch にログ記録されます。 RAG_Scores ダッシュボードは、平均スコアおよび取り込まれたスコアの合計数を表示します。 クリーンアップ 必要以上の料金が発生しないように、作成したすべてのリソースを削除します。 デプロイした SageMaker モデルの削除 デプロイされた SageMaker JumpStart (Amazon の機械学習モデルを素早く構築・デプロイできるサービス) のモデルを削除したい場合は、 提供されている例のノートブック のクリーンアップセクションを参照するか、 Amazon SageMaker (AWS の機械学習サービス) のコンソール上でモデルを削除 することができます。 AWS CDK リソースの削除 cdk.context.json ファイルにパラメータを入力した場合は、次のように内容を消去してください。 $ cd pattern1-rag/cdk $ cdk destroy --all コマンド ライン上でパラメータを入力し、バックエンド アプリケーション (バックエンド AWS CDK スタック) のみをデプロイした場合、次のように削除してください。 $ cd pattern1-rag/cdk $ cdk destroy --all -c textModelEndpointName=<Enter the SageMaker Endpoint Name for the Text generation model> \ -c embeddingsModelEndpointName=<Enter the SageMaker Endpoint Name for the Text embeddings model> コマンドラインでパラメータを入力し、フロントエンドとバックエンド AWS CDK スタック全体をデプロイした場合は、次のように削除します。 $ cd pattern1-rag/cdk $ cdk destroy --all -c appCustomDomainName=<Enter Custom Domain Name to be used for Frontend App> \ -c loadBalancerOriginCustomDomainName=<Enter Custom Domain Name to be used for Load Balancer Origin> \ -c customDomainRoute53HostedZoneID=<Enter Route53 Hosted Zone ID for the Custom Domain being used> \ -c customDomainRoute53HostedZoneName=<Enter Route53 Hostedzone Name> \ -c customDomainCertificateArn=<Enter ACM Certificate ARN for Custom Domains provided> \ -c textModelEndpointName=<Enter the SageMaker Endpoint Name for the Text generation model> \ -c embeddingsModelEndpointName=<Enter the SageMaker Endpoint Name for the Text embeddings model> まとめ この記事では、生成 AI の RAG パターンにおける参照データとプロンプトの両方でベクトル埋め込みを取得するアプリケーションの実例を示しました。参照データやプロンプトでドリフトが発生しているかどうかを判断するためのクラスタリング分析の実行方法と、参照データがユーザーの質問の種類をどの程度カバーしているかを示しました。ドリフトを検出できれば、環境が変化し、モデルが最適化されていない新しい入力を受け取っていることを示す兆候となります。これにより、変化する入力に対する現在のモデルの積極的な評価が可能になります。

はじめに 全米消防協会は、毎年 100 万件を超える火災を記録しています。これらの火災は、米国における都市の安全を脅かす最大の危険のひとつと位置づけられています。現在、消防署は主に在宅用の煙探知機、火災通報ボックス、および電話による通報といった従来の火災検知システムによる警報に頼っています。しかしこれらのシステムでは、火災の範囲、規模、場所などの追加情報が不足する可能性があります。モノのインターネット (IoT) は、都市のインフラを合理化し、火災を事前に検知し、公共の安全性を向上させるための重要な技術です。 火災関連の事故を減らし、迅速かつ効果的に火災に対応するため、IoT センサーと高度なデータ分析 (機械学習など) を統合することができます。環境条件と煙レベルを監視する IoT デバイスは、ほぼリアルタイムでデータをクラウドに送信でき、そこでさらに処理が行われ、潜在的な火災の危険性が特定されます。そうすることにより、事態が悪化する前に実用的な対策を講じることができます。 このブログ記事では、早期警告システムを緊急時対応者に構築するためのデータを接続、収集、活用するにあたり、AWS のサービス群をどのように使用するかを学びます。全体のシステムアーキテクチャについて説明し、データを収集するセンサーやデバイス、AWS IoT サービスを使ったデータ処理と分析、 Amazon SageMaker を使ったローコードな ML モデルによる火災予測についても見ていきます。 全体アーキテクチャ このソリューションでは、 AWS IoT Core &nbsp;を使用して、温度、気圧、ガス、湿度、風速、土壌湿度などさまざまなセンサーからデータを大規模にクラウドに安全に取り込みます。使用する IoT デバイスのタイプに応じて、 AWS IoT SDK &nbsp;は、AWS IoT Core とデバイスを安全に接続し、認証するために必要なライブラリと API を提供します。 ただし、一部のデバイスは Wi-Fi やセルラーネットワークが途切れ途切れになるところに配置される可能性があります。そのような場合、 AWS IoT Core for Amazon Sidewalk &nbsp;（注記：2024/06時点で日本国内ではサービス未提供）が優位性を発揮します。 Amazon Sidewalk は、互換性のある Amazon Echo や Ring デバイスなどの Amazon Sidewalk Gateway を使用し、IoT エンドポイントデバイスにクラウド接続を提供するセキュアなコミュニティネットワークです。Amazon Sidewalk は、Bluetooth Low Energy を使った近距離通信と、900MHz の周波数で LoRa および FSK 無線プロトコルを使った長距離通信により、家の中や外でも低帯域幅の長距離接続を実現します。IoT デバイスは、Sidewalk Gateway を介して AWS IoT Core と安全に対話でき、データの発行やコントロールメッセージの受信ができます。この統合により、IoT デバイスの全体的な接続性と機能性が強化されます。Amazon Sidewalk は、接続性のギャップを埋めることで、スマートシティの実装において AWS IoT Core の範囲を広げ、遠隔の地域でも本当に市内全域をカバーするネットワークを可能にします。この通信範囲の拡大により、IoT とエッジコンピューティングがスマートシティのインフラ内でより効果的で信頼性の高いものになります。 AWS IoT Rules Engine &nbsp;は、ストリーミングデータを分析および処理し、AWS IoT Core に到着するメッセージを下流の AWS サービスにルーティングできるようにします。受信データに基づいて条件を指定するルールを作成できます。IoT デバイスからのメッセージがルールの条件に一致すると、ルールエンジンがアクションをトリガーします。このソリューションでは、このアクションによってメッセージが&nbsp; Amazon Simple Notification Service (Amazon SNS) に転送され、指定された通信チャンネルで対応チームに通知されます。 受信データは Amazon Timestream にもルーティングされ、ニアリアルタイムの監視のために保存されます。Amazon Timestream は高速、スケーラブル、完全マネージド型の時系列データベースで、時系列データの保存と分析を簡単に行えます。Timestream の目的別クエリエンジンを使えば、データの場所を指定することなく、最新のデータと過去のデータにアクセスして分析できます。AWS IoT で定義されたルールにより、着信メッセージからのデータが Timestream に直接投入され、AWS IoT Core が SQL リファレンスを使って結果のアクションを解析します。 Amazon Managed Grafana &nbsp;を使用して、何百万ものリアルタイムイベントを監視および分析する動的なダッシュボードを通じて、即座にインサイトを得ることができます。Amazon Managed Grafana は、 Amazon Timestream と統合されたフルマネージドで、安全なデータ可視化サービスです。Amazon Managed Grafana を使用すると、複数のソースからの遠隔測定データを即座に照会、相関、可視化できます。Amazon&nbsp;Timestream と&nbsp;Amazon Managed Grafana&nbsp;を使用すると、ダッシュボードからほぼリアルタイムのインサイトを導き出す運用ダッシュボードを構築し、何百万ものイベントを分析して監視し、警告することができます。これらのダッシュボードは、ステークホルダーや対応チームに、センサーのメトリクスや異常検知に関する即時の可視性を提供します。また、スマートシティ内の火災につながる潜在的な脅威の早期発見にも役立ちます。 長期的な分析と履歴参照のために、すべての生のセンサーデータは Amazon Simple Storage Service (Amazon S3) のデータレイクに配信されます。これは、ストリーミングデータをキャプチャ、変換、ロードする Amazon Data Firehose に渡されます。Amazon S3 に過去データを保存することは、このシステムの機能を高める上で重要な役割を果たします。これがマシンラーニングモデル開発の基盤となり、 Amazon SageMaker によって支援されます。SageMaker を利用すれば、この過去のデータセットを使って効率的にマシンラーニングモデルをトレーニングできます。過去データからのインサイトで強化されたこれらのモデルには、火災リスクを含む環境条件を正確に予測する能力があります。 Amazon Athena を使えば、これらのインサイトを直感的に分析・可視化でき、データ主導の意思決定が容易になります。Athena はサーバーレスかつインタラクティブなクエリサービスで、Amazon S3 に保存されたデータを分析し、結果を Amazon QuickSight で可視化できます。Amazon QuickSight はこの高度なデータを活用し、インタラクティブで分かりやすいダッシュボードを生成します。 ニアリアルタイムの監視、予測分析、高度な可視化を組み合わせることで、変化する環境条件に対して積極的に対応できます。この積極的な対応により、潜在的な脅威の迅速な検知と、タイムリーな緊急対応が可能になります。 他のユースケース 上記のアーキテクチャは、スマートシティにおける火災に関するセンサーデータを収集、分析、表示するための柔軟な基盤として機能します。このアーキテクチャは、山火事のような環境問題への対処にも応用できます。山火事は、人里離れた森林から発生し、郊外や都市部まで到達することが多くあります。森林地帯、公園、緑地帯、都市と山林の境界などで IoT センサーを使用することで、都市は火災を早期に発見し、封じ込めることができます。 このアーキテクチャは火災検知以外にも応用できます。交通、廃棄物管理、エネルギー使用、洪水リスク、大気の質を監視することで、スマートシティの運営を最適化することができます。このアーキテクチャの核となる機能は、センサーデータを市当局、緊急対応者、市民にとって有用な情報に変換し、都市をより安全で住みやすく、持続可能なものにすることにあります。 まとめ このブログでは、スマートシティ向けのスケーラブルな早期火災検知システムを設計するためのリファレンスアーキテクチャについて説明しました。AWS IoT を活用することで、このソリューションは市内の数千ものセンサーからのデータ取り込みと、ほぼリアルタイムの検知および警報をサポートします。このようなデータ取り込みにより、迅速な対応、事前の被害軽減、最適なリソース配分が可能になります。このアーキテクチャの汎用性により、交通管理、大気汚染監視、洪水予測などの他のIoTユースケースにも適用できます。最先端のテクノロジーと賢明な都市設計を組み合わせることで、都市は市民にとってより強靭で安全なものになる大きな一歩を踏み出せるでしょう。 この記事は Ahmed Alkhazraji, Ankur Dang, Marouane Hail&nbsp;によって書かれた Early Fire Detection Design Model for Smart Cities: Using AWS IoT and ML Technologies の日本語訳です。翻訳は、プロフェッショナルサービス本部 IoT コンサルタントの 宮本 篤 が担当しました。 著者について Ahmed Alkhazraji は、AWS で AI/ML および汎用 AI に注力するシニアソリューションアーキテクトです。革新的なソリューションを構築することと、AWS 導入の初期段階にあるお客様とともに働くことに情熱を注いでいます。仕事の合間には、ハイキング、サッカー、旅行を楽しんでいます。 Ankur Dang は Amazon Web Services(AWS) でソリューションアーキテクトを務めています。テクノロジーに情熱を注ぎ、お客様の問題解決とアプリケーションのモダナイゼーションの支援に取り組んでいます。特に AWS IoT サービスを活用したシステム設計に興味があり、モノのインターネット (IoT) ソリューションに熱心に取り組んでいます。仕事以外では、航空宇宙の進歩を研究したり、ドローン写真でユニークな空撮を楽しむなど、趣味を追求しています。 Marouane Hail は、クラウドオペレーションを専門とするソリューションアーキテクトです。お客様のために安全かつスケーラブルなソリューションを構築することに情熱を注いでいます。仕事以外では、サッカーをするのが好きで、テクノロジーについても学習を続けています。 以下のAWS リソースも併せてご確認ください。 [1] Tutorial: Connecting a device to AWS IoT Core by using the AWS IoT Device SDK [2] Tutorial: Connecting Sidewalk devices to AWS IoT Core for Amazon Sidewalk [3] Tutorial: AWS IoT Rule to Send an Amazon SNS notification [4] Tutorial: AWS IoT Rule to send incoming data to Amazon Timestream [5] Tutorial: Visualize your time series data and create alerts using Grafana [6] Blog: Ingesting enriched IoT data into Amazon S3 using Amazon Kinesis Data Firehose [7] Blog: Analyze and visualize nested JSON data with Amazon Athena and Amazon QuickSight <!-- '"` -->

Amazon Timestream for LiveAnalytics は、高速でスケーラブルなサーバーレス時系列データベースであり、1 日に数兆件のイベントを簡単かつコスト効率よく保存および分析する事ができます。Timestream for LiveAnalytics は、数億の IoT デバイス、産業機器の監視や、ゲームセッション、ストリーミングビデオセッション、金融、ログ分析などのユースケースに使用できます。Timestream for LiveAnalytics を使用すると、高可用性を実現しながら、1 分あたり数十ギガバイトの時系列データを取り込み、数秒でテラバイトの時系列データに対する SQL クエリを実行できます。 現在、様々な組織が、時間に敏感なデータのリアルタイムの洞察を提供することで、競争上の優位性を獲得しようとしていますが、データストリームを使用したリアルタイムデータの取り込みをサポートし、それを Timestream for LiveAnalytics で処理して保存するデータパイプラインが必要となります。時系列データをサポートしている AWS ソースから Timestream for LiveAnalytics に転送するには、Apache Flink アダプターなどのすぐに使えるアダプター、またはカスタマイズされた専用のコードが必要になる場合がありました。 時系列データの取り込みを簡素化する為、 Amazon EventBridge Pipes と Timestream for LiveAnalytics の統合機能が今回使えるようになりました。EventBridge Pipes を使用して、 Amazon DynamoDB 、 Amazon Kinesis Data Streams 、 Amazon MQ 、 Amazon Simple Queue Service (Amazon SQS) などのさまざまなソースから Timestream for LiveAnalytics にデータを取り込めるようになりました。本リリースにより、Timestream for LiveAnalytics にデータを取り込むための、柔軟なローコード・ノーコード (LCNC) 構成ベースのソリューションが利用可能となります。 EventBridge Pipes は、サポートされている ソース と ターゲット 間のポイントツーポイント統合を目的としており、高度な 変換 、 エンリッチメント 、 フィルター 処理をサポートしています。EventBridge Pipes は、イベント駆動型アーキテクチャを開発する際の専門知識と統合コードの必要性を軽減し、企業のアプリケーション間の一貫性を促進します。 本投稿では、Timestream for LiveAnalytics が Kinesis Data Streams からデータを取り込めるように EventBridge Pipes を設定する方法を紹介します。 ソリューションの概要 以下の図は、EventBridge Pipes を利用して Kinesis Data Streams からデータを取り込む為のアーキテクチャを示しています。EventBridge Pipes がサポートしているその他の統合を調べるには、 Amazon EventBridge Pipes sources を参照してください。 次の JSON でサンプル車両データを生成し、 Amazon Kinesis Data Generator (KDG) を使用して Kinesis Data Streams にストリーミングします。 Kinesis Data Streams から Timestream for LiveAnalytics にデータを取り込むためのパイプを以下で設定していきます。 { "connectionTime": "{{date.now("YYYY-MM-DD HH:mm:ss.SSS")}}", "vehicle_id": "CAR_{{random.number({"min":1, "max":100})}}", "driver_id": "USER_{{random.number({"min":1, "max":1000})}}", "engine_status": "{{random.number({"min":0, "max":1})}}", "miles": "{{random.number({"min":0, "max":1000})}}.0" } 前提 本投稿では、 データベース VehicleMetricsDB と テーブル VehicleMetrics を作成しました。カーディナリティの高い列を持ち、テーブルのクエリで述語として頻繁に使用されるディメンションに基づいてパーティションキーを選択することをお勧めします。これにより、データがパーティション間で均等に分散され、パフォーマンスに関する問題を回避する事ができます。本投稿では、 顧客定義のパーティションキー として vehicle_id を持つ車両から生成されたデータを使います。またデータストリーム vehicle-metrics-stream についても 作成 しました。 注意: このソリューションでは、アカウントにコストが発生する AWS リソースが作成されます。本投稿の一部として作成したリソースは、完了したら必ず削除して下さい。 EventBridge pipe を作成する EventBridge Pipes のコンソール画面を開く Create pipe を選択 Pipe name として作成するパイプ名を指定する Description として説明を入力する (オプション) Build pipe タブの Source に Kinesis を選択し、適切なストリームを選択する Additional setting で要件に応じて、 バッチサイズや多重度の値 を設定する On partial batch item failure – AUTOMATIC_BISECT を選択する事を推奨します。各バッチは自動的に半分に分割され、すべてのレコードが処理されるか、失敗したメッセージのみがバッチ内に残るまで、半分ずつ再試行されます。 Batch size – デフォルトの 100 を選択しましょう。尚、Amazon SQS がソースの場合は最大のバッチサイズは 10 になります。 Build pipe タブの Target を選択 このデモでは、 フィルタリング と エンリッチメント のオプションは必要ないため、ターゲットを直接設定しますが、要件に基づいてフィルタリングとエンリッチメントの適用を選択できます。エンリッチメントレイヤーを追加すると、 さまざまなサービスがさまざまなレベルのバッチ処理をサポート します。 Details の Target service で、ターゲットとして Timestream for LiveAnalytics を選択し、対象のデータベースとテーブルを選択します。 データが有効な JSON の場合、入力テンプレートまたはターゲットパラメーターの JSON パスは コンテンツを直接参照 できます。たとえば、 &lt;$.data.someKey&gt; を使用して変数を参照できます。 Time field type には、$.data.connectionTime をデフォルトの 時間 として TIMESTAMP_FORMAT ( yyyy-MM-dd HH:mm:ss.SSS ) を使用します。要件によっては、 EPOCH 形式も選択できます。 Version value を指定する事で、最新の値を使用してデータポイントを 更新 できます。各 Kinesis レコードには、 ApproximateArrivalTimestamp という値が含まれており、ストリームがレコードを正常に受信して保存したときに設定されます。本投稿では、更新を処理するためにバージョン値を $.data.approximateArrivalTimestamp に設定しました。そのため、最新の ApproximateArrivalTimestamp でメジャーが変更され、同じディメンションと時間の値が更新されます。 次のステップでは、Timestream for LiveAnalytics のデータモデル ( ディメンション、メジャー、メジャー名 、および必要な列の データ型 ) を構成します。この構成では、ビジュアルビルダーまたは JSON エディターのいずれかを使用できます。 データモデリングのベストプラクティス に従う事で、効果的なデータモデリングを実現します。 JSON エディター を利用して以下の情報を提供します DimensionValue (ディメンジョン)として、 vehicle_id と driver_id を使います。 MeasureValue (メジャー)としては、マイル数と engine_status を使います。 MultiMeasureName (メジャー名) には、’metric’ という固定値を使用します。要件に基づいて特定のソース列をメジャー名として選択できますが、 8,192 個の個別の値 を超えないようにしてください。 { "DimensionMappings": [ { "DimensionValue": "$.data.vehicle_id", "DimensionValueType": "VARCHAR", "DimensionName": "vehicle_id" }, { "DimensionValue": "$.data.driver_id", "DimensionValueType": "VARCHAR", "DimensionName": "driver_id" } ], "MultiMeasureMappings": [ { "MultiMeasureName": "metric", "MultiMeasureAttributeMappings": [ { "MeasureValue": "$.data.miles", "MeasureValueType": "DOUBLE", "MultiMeasureAttributeName": "miles" }, { "MeasureValue": "$.data.engine_status", "MeasureValueType": "BIGINT", "MultiMeasureAttributeName": "engine_status" } ] } ] } Visual Builder を使用してデータモデルをセットアップすることもできます。以下のスクリーンショットは、Visual Builder を使ったディメンションの設定例です。 MULTI_MEASURE_NAME と MULTI_MEASURE_VALUE に対しても同様に設定することができます。 これで、パイプの詳細設定 (アクセス許可、再試行ポリシー、 Amazon CloudWatch logs) ができるようになりました。 Pipe settings タブの Permission セクションで、新しい AWS Identity and Access Management (IAM) ロールを定義するか、既存のロールを使用できます。初めてパイプを作成する場合は、 Create a new role for specific resource を選択します。 Kinesis データストリームまたは DynamoDB ストリームをパイプのソースとして指定した場合は、オプションで再試行ポリシーとデッドレターキュー (DLQ) を設定できます。指定した保存期間より古いレコードを破棄し、失敗した場合の再試行回数を指定できます。 Retry policy では、 イベントの最大経過時間 として、少なくとも 30 分以上を使用することが推奨されます。このデモでは、30 分に設定したため、30 分より古いレコードは処理されず、DLQ に直接移動されます。 Retry attempts は 10 回に設定します。これは、一時的な問題に対処するための推奨値です。永続的な問題の場合は、再試行後にレコードが DLQ に移動され、残りのストリームのブロックが解除されます。 設定ミスによるデータ損失を避けるために、パイプの DLQ を構成することを強くお勧めします。 DLQ で Kinesis イベントのシーケンス番号を参照してレコードを修正し、Timestream に再送信できます。 DLQ を有効にするには、以下の Dead-letter queue の箇所を ON とし、使用するキューまたはトピックを選択します。このデモでは、Amazon SQS を使用し、同じ AWS アカウントと AWS リージョン内のキューを選択します。 Log destination で、ログレコードの配信先を選択します。ここでは、 CloudWatch Logs を選択します。 Log level では、EventBridge がログレコードに含める 情報のレベル を選択します。デフォルトでは、 ERROR ログレベルが選択されています。ここでは、詳細を確認できるように、 Log Level を ERROR から INFO に変更します。 ターゲットが Timestream for LiveAnalytics の場合は、 include execution data オプションを選択することをお勧めします。これにより、EventBridge はイベントのペイロード情報、サービスの要求／応答情報をログレコードに含めることができます。 EventBridge Pipes の実行データは、トラブルシューティングとデバッグに役立ちます。ペイロードフィールドには、バッチに含まれる各イベントの実際のコンテンツが含まれているため、個々のイベントを特定のパイプ実行に関連付けることができます。ただし、受信データには機密情報が含まれている可能性があり、このオプションを有効にすると、実際のイベントデータが選択したすべての宛先に記録されるため、データの機密性に基づいて正しい決定を下すようにしてください。 Create pipe を選択してパイプを作成します。 EventBridge コンソールで作成した特定のパイプに移動し、パイプが Running 状態になるまで待ちます。 ソリューションの検証 サンプルアーキテクチャの箇所で説明したように、KDG を使用してデータをストリーミングしました。この取り込みを検証するには、 Amazon Timestream for LiveAnalytics のクエリエディター を開き、次の SQL クエリを実行します。 SELECT * FROM "VehicleMetricsDB"."VehicleMetrics" limit 5 以下はクエリの結果を示しています。 要件に応じて、Timestream のクエリ言語を使用して様々な クエリ を実行できます。 考慮事項 AWS Command Line Interface (CLI) (AWS CLI)、 AWS CloudFormation 、 AWS Cloud Development Kit (AWS CDK) を使用して、EventBridge Pipes のパイプを作成することもできます。 また、 CloudWatch メトリクス を使用して、取り込みの進行状況の監視が可能で、EventBridge コンソールの Monitoring タブでは呼び出しと失敗を視覚化できます。トラブルシューティングについては、 Log Amazon EventBridge Pipes を参照してください。 クリーンアップ 料金の発生を回避するには、 AWS マネジメントコンソール を使用して、このデモの為に作成したリソースを削除します。 Timestream のコンソールで Timestream のデータベースとテーブルを削除 します。 EventBrdige のコンソールで作成したパイプを選択して削除します。 Kinesis Data Streams のコンソールで作成したストリームを削除します。 CloudFormation コンソールで、KDG 用に作成した CloudFormation スタックを削除 します。 結論 本投稿では、EventBridge Pipes を統合して Kinesis Data Streams からデータを Timstream for LiveAnalytics に取り込む方法を説明しました。この新しい統合は、時系列データの取り込みを簡素化するのに役立ちます。 詳細については、次のリソースを参照してください。 Amazon EventBridge Pipes error handling and troubleshooting Data Modeling Best Practices to Unlock the Value of your Time-series Data Monitoring Amazon Kinesis Data Streams 本投稿へのフィードバックについては、 Amazon Timestream の AWS re:Post に送信して下さい。 翻訳はテクニカルアカウントマネージャーの西原が担当しました。原文は こちら をご覧下さい。

本ブログは、AI inside 株式会社と Amazon Web Services Japan が共同で執筆しました。 AI inside 株式会社 は、生成AI・LLM や自律型 AI をはじめとした最先端テクノロジーの研究開発と社会実装を行うテックカンパニーです。AI エージェント「Heylix」や AI-OCR サービス「DX Suite」に加え、それらを支える AI インフラ「AnyData」と「AI inside Cube」を、政府機関・地方公共団体・民間企業へ広く提供しています。提供する AI サービスは既に、5 万人を超えるお客様に累計 72 億回以上ご利用いただいています。 直面していたビジネス上の課題 AI inside が提供する「 DX Suite 」は、これまで手入力で行っていた帳票のデジタル化を効率的に実現する AI-OCR サービスです。多くのお客様にご利用頂いていますが、OCR 対象の書類はフォーマットが統一されていない非定型帳票も多く、フォーマット毎に AI モデルの学習が必要となるケースがあり、その対応には約 2000 万円というコストと 1 ヵ月以上の時間が発生するというビジネス上の課題がありました。 この課題を解決するために、LLM を活用した「 学習不要であらゆる帳表の読み取りを実現する機能 」の実装を進めていました。本機能を「DX Suite」を利用するユーザーに提供するためには、精度・スループット・人件費含むコスト最適化に加え、エンタープライズのお客様が望む高い水準のセキュリティを満たす LLM 環境が必要でした。 ソリューション Amazon Bedrock は、単一の API を介して AI21 Labs、Anthropic、Cohere、Meta、Mistral AI、Stability AI、および Amazon といった大手 AI 企業からの高性能な基盤モデルを選択できるフルマネージドサービスです。セキュリティ、プライバシー、責任ある AI を備えた生成 AI アプリケーションを構築するために必要な幅広い機能を提供します。 AI inside は Amazon Bedrock を活用することで、精度・スループット・コストにおいて他社モデルと同等以上の水準を確保しながら、Amazon Bedrock の特徴である豊富なモデルのラインナップや最新モデルへの対応などの高い柔軟性を獲得しました。 また、セキュリティの観点からも Amazon Bedrock を採用することによってメリットがありました。「DX Suite」は Amazon Elastic Kubernetes Service (Amazon EKS) 上で稼働しており、 AWS PrivateLink を活用することで AWS 内に閉じられたネットワークで Amazon Bedrock を利用することが可能です。また Amazon Bedrock は入力情報やトレーニングに使用するデータを学習しないため、推論データの追加学習が行われないセキュアな LLM 環境を実装できます。 導入効果 AI モデルの学習に必要だった約 2000 万円の費用と 1 ヵ月以上の時間が不要になり、「DX Suite」サービス開始から 7 年間で 13 種類だった非定型帳票プリセットが、わずか 3 ヵ月で 1000 種類を超えました。また Amazon Bedrock を活用した LLM 環境を実装することによって、エンタープライズレベルの顧客が求める水準でのサービス提供が出来るようになりました。 まとめ Amazon Bedrock を活用した LLM 環境の実装によって、安価かつ短期間での多様な帳票フォーマットへの対応を実現し、エンタープライズレベルの顧客が求める水準でのサービス提供が出来るようになりました。 AI inside では、生成AIエージェント「Heylix」などの新サービスにおいても AWS の先進的なテクノロジーを活用し、高付加価値かつセキュアなサービス提供を目指します。

みなさん、こんにちは！製造業のお客様を中心に技術支援を行っているソリューションアーキテクトの山田です。 Anthropic の Claude 3.5 Sonnet が発表され、バージニアリージョンの Amazon Bedrock にてご利用頂けるようになりました。 Claude 3.5 Sonnet は Claude 3 Opus よりも高いベンチマークスコアを記録する高い能力を発揮すると同時に、Opus よりも 80 %安価に、2 倍の動作速度でご利用頂けるとされています。 Claude 3.5 Sonnet は、学部レベルの専門知識 (MMLU)、大学院レベルのエキスパート推論 (GPQA)、数学の問題解決 (MATH) などの新しい業界ベンチマークを記録しました。 このブログでは、製造業で設計開発業務に取り組まれている R&amp;D (Research and Development：研究開発) エンジニアの方を想定ユーザーとして設定させていただき、大学レベルの専門知識が問われる工学的な問題を解く際に、Claude 3.5 Sonnet を活用するポイントについて解説させていただきます。 設計開発業務において工学的な問題を解く際の課題 例えば機械の設計を行う際、この形状で強度的に問題はないかや、適切に放熱できているかなどを計算して確認する業務は頻繁に生じます。その際、機械4大力学と言われる「機械力学」「材料力学」「熱力学」「流体力学」といった専門知識を駆使して、問題の事象を捉えてモデル化し、計算を行うことになりますが、範囲が広く難解なため、何も頼らないで自分の頭だけで解けるケースはそう多くありません。大学の教科書を参照したり、該当分野に詳しい同僚に教えを請うたりしながら解いていくことになります。 しかし、問題は複雑で様々な要素が絡んでいることも多く、教科書の中の該当する箇所を問題から逆引きして見つけ出すことは難しかったり、時間がかかったりします。該当分野に詳しい同僚に教えを請う場合でも、相談にあたって時間を取ってしまいますし、専門分野が細分化されているような問題の場合は複数人に相談する必要がでてきてしまいます。 そこで、冒頭に紹介した、学部レベルの専門知識など様々な新しい業界ベンチマークを記録した Claude 3.5 Sonnet の出番です。高いベンチマークスコアを記録したからといって、万能で全ての問題を解けるというわけではないのですが、本ブログではそういった不完全な部分もある AI との向き合い方のコツについても解説させていただきます。 Claude 3.5 Sonnet を活用した問題解決の実践 Amazon Bedrock で Claude 3.5 Sonnet のような基盤モデルを有効化して、チャットのやり取りを行うための準備手順については、こちらの Amazon Bedrockの生成系AIテクノロジーを活用して設計開発業務を進化させよう というブログをご参照ください。 今回は以下のような大学レベルの流体力学の問題に直面したエンジニアのシナリオで、 プロンプト を打ち込み、どのような回答が返ってくるかを見てみます。 【プロンプト】 あなたは熟練の機械設計エンジニアです。以下の問題を解いてください。 水平に置かれた内径 d1 =20cmの管が内径 d2 = 10 cm の菅に滑らかに接続されています。内径 d1 の管内を空気が毎分 4.71 m^3 の流量で流れています。接続部の内径 d1 側における圧力 p1 は 2.00 気圧でした。接続部の内径 d2 側における流速と圧力を教えてください。ただし、摩擦による損失を無視し、空気の密度を 1.23 kg / m^3とします。 Step by Step で考えてください。 最終的に、正しい計算ができたかの自信度合いを10段階で評価して提示してください。 【Claude 3.5 Sonnet からの回答】 はい、この問題を Step by Step で解いていきましょう。 Step 1 : 与えられた情報を整理します。 – d1 = 20 cm = 0.2 m – d2 = 10 cm = 0.1 m – Q (流量) = 4.71 m³/min = 0.0785 m³/s – p1 = 2.00 気圧 = 202,650 Pa (1気圧 = 101,325 Pa) – ρ (空気密度) = 1.23 kg/m³ Step 2 : d1 側の流速 v1 を計算します。 A1 = π(d1/2)² = π(0.2/2)² = 0.0314 m² v1 = Q/A1 = 0.0785/0.0314 = 2.5 m/s Step 3 : 連続の式を使用して d2 側の流速 v2 を計算します。 A1v1 = A2v2 v2 = (A1/A2)v1 = (d1/d2)²v1 = (0.2/0.1)² × 2.5 = 10 m/s Step 4 : ベルヌーイの定理を適用します。 p1 + (1/2)ρv1² = p2 + (1/2)ρv2² Step 5 : p2 を解きます。 p2 = p1 + (1/2)ρv1² – (1/2)ρv2² &nbsp; &nbsp;= 202,650 + (1/2)×1.23×2.5² – (1/2)×1.23×10² &nbsp; &nbsp;= 202,650 + 3.84375 – 61.5 &nbsp; &nbsp;= 202,592.34375 Pa ≈ 1.9994 気圧 結果: – d2 側の流速: v2 = 10 m/s – d2 側の圧力: p2 ≈ 1.9994 気圧 自信度評価: 9/10 この計算は基本的な流体力学の原理に基づいており、与えられた条件下で正確であると考えられます。ただし、実際の状況では摩擦や乱流の影響があるため、完全に現実を反映しているわけではありません。そのため、10点満点ではなく9点としました。 チャットやり取りの内容解説 まず Claude 3.5 Sonnet からの回答は正解です（人間の専門家が検証しました。Claude 3.5 Sonnet が最後に言及している通り摩擦や乱流の影響などの細かい要素を無視した場合においてです）。論理立て、計算結果、いずれも流石のベンチマークスコアを感じさせる品質でした。 プロンプトには、良い回答を返してもらうための工夫として、「あなたは熟練の機械設計エンジニアです」や「Step by Stepで考えてください」といった表現が盛り込まれています。こういった Claude へプロンプトを書く際のコツについては こちら もご参照ください。 特に、「最終的に、正しい計算ができたかの自信度合いを10段階で評価して提示してください」といったような、自信度合いを問うことは、こういった難解な質問を投げかける際には重要になります。例えば以下のような簡単な質問だとどのような回答が返ってくるかを見てみましょう。 【プロンプト】 5 × 10 + 3 – 4 = ? Step by Stepで考えてください。 最終的に、正しい計算ができたかの自信度合いを10段階で評価して提示してください。 【Claude 3.5 Sonnet からの回答】 分かりました。ステップバイステップで解説し、最後に自信度合いを10段階で評価します。 &nbsp; ステップ 1 : 5 * 10 を計算します 5 * 10 = 50 ステップ 2 : 50 に 3 を足します 50 + 3 = 53 ステップ 3 : 53 から 4 を引きます 53 – 4 = 49 したがって、最終的な答えは 5 * 10 + 3 – 4 = 49 となります。 自信度合い: 10/10 この計算は非常に基本的なものなので、確信を持って正しい答えが出せたと思います。ステップバイステップで丁寧に解いたので、間違いはないはずです。 このような簡単な質問だと満点の10点で回答を返してくれました。しかし問題が難解になるほど、間違えてしまう可能性も増してきます。 そういった100%の正解が返せない場合においても、今回の流体力学の問題の例のように、自信度合いを聞いて、完全に正しいとは限らないと認識した上で、Step by Step でどのように論理立てて問題を解こうとしているかを参考にして思考の検討材料とすることは有益になると考えます。 学校の試験問題などとは異なり、現実の物理現象を扱う工学的な問題では正しい回答はどこにも存在しないケースが多々あります。手掛かりとなる参考情報を素早く与えてくれるだけで、役立つ存在となってくれることでしょう。 まとめ Claude 3.5 Sonnet は今回のケースにおいて、大学レベルの流体力学の問題を正しく解くことができました。問題が難解になるほど、間違えてしまう可能性も増してきますが、完全に正しいとは限らないと認識した上で、参考にできる情報を検討材料としてうまく活用することで、設計開発業務に役立てられるイメージを掴んでいただきました。 著者プロフィール 山田 航司&nbsp;(Koji Yamada @yamadakj) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 製造業のお客様を中心にクラウド活用の技術支援を担当しています。好きな AWS のサービスは Amazon Bedrock です。 愛読書は「大富豪トランプのでっかく考えて、でっかく儲けろ」です。

このブログは、6月20日と21日に開催された&nbsp;AWS Summit Japan&nbsp;における IoT 関連出展を紹介するものです。「プロダクト IoT 編」と「インダストリアル IoT 編」の二部構成で、今回は「インダストリアル IoT 編」についてお伝えします。（プロダクト IoT 編の記事は こちら です） 今年の AWS Summit Japan では、インダストリアル関連の IoT サービスを活用した多数のブース出展やセッションが行われました。どのコンテンツも、設備からのデータ取得だけでなく、取得したデータを様々なシーンで活用する方法を示しており、現場の課題解決に役立つ実用的な内容となっていました。ブース内で来場者との活発な質疑を交わす場面も多く見られ、実用フェーズに進んでいることが感じられました。このブログはインダストリアル IoT 編として、展示やセッションの一部をご紹介します。 カスタマーセッション 東海旅客鉄道株式会社 基調講演：ビルダーとテクノロジーが加速する次のイノベーション Breakout Session ： リニア中央新幹線における設備 IoT 化に向けて～データドリブンによる徹底的な省人化の実現～ 東海旅客鉄道株式会社のリニア開発本部では、リニア中央新幹線の運営に向けてデータ分析プラットフォームを構築しています。山梨リニア実験線での「保守用車リアルタイム状態監視」と「開閉器動作音による異常検知」の2テーマについて、 AWS プロトタイピングプログラムを活用した取り組みを、基調講演とブレイクアウトセッションの２回にわたりご紹介いただきました。 IoT サービスを活用したデータドリブン運営に向けたステップがよくわかり、リニア中央新幹線開通への期待感がますます高まる内容となっていました。 基調講演： 東海旅客鉄道株式会社 中央新幹線推進本部 リニア開発本部 副本部長&nbsp;水津 亨 氏（ オンデマンド配信 ） Breakout Session：東海旅客鉄道株式会社 中央新幹線推進本部 リニア開発本部&nbsp;宮本 真樹 氏 と藤原 海渡 氏（ オンデマンド配信 ）　 株式会社 竹中工務店、日本タタ・コンサルタンシー・サービシズ株式会社 「建設デジタルプラットフォーム」によるデジタルデータと最新技術活用の取組み&nbsp; 日本タタ・コンサルタンシー・サービシズ株式会社 長谷川 隆一 氏と、株式会社 竹中工務店 デジタル室 先進デジタル技術グループ グループ長 丘本 道彦 氏により「「建設デジタルプラットフォーム」によるデジタルデータと最新技術活用の取組み&nbsp;」というタイトルで発表頂きました。 Building4.0 の取り組みとして、 AWS IoT TwinMaker を活用したデジタルツインの検証内容について、「作業進捗管理」や「 IoT デバイスと連携した熱中症対策」などの具体例を元にご紹介いただきました。建設事業のデジタル変革が目指すビジョンがよくわかる内容となっていました。詳細は こちらの資料 をご覧ください。 AWSセッション AWS IoT SiteWise を活用したスマート工場の実現&nbsp; アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 IoT スペシャリスト ソリューションアーキテクトの新澤 雅治がプレゼンテーションを行いました。主に製造業のお客様に向けて、スマート工場の実現に向けた手段を整理し 、 AWS IoT SiteWise の re:Invent 2023 で発表された新機能を含む具体的な活用方法を、お客様事例を交えて紹介しました。また、食品工場における生成AIアシスタントのデモにより、生成AIがどのように生産効率を向上させるかをご紹介しました。詳細は オンデマンド配信 をご覧ください。 物流業におけるデジタルツイン構築の勘所&nbsp; アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 エンタープライズ技術本部 ソリューションアーキテクトの戸塚 智哉がプレゼンテーションを行いました。デジタルツインは現実世界をデジタル空間に再現し、リアルタイムな監視やシミュレーションを可能にする技術ですが、現実世界のデータをどのようにクラウドで扱うのか、物流倉庫などの利用シーンをベースに、 AWS IoT サービスを使ったデザインパターンをご紹介しました。また、生成 AI と合わせることでより効果的なデジタルツインの実現についても勘所もご紹介しました。詳細は オンデマンド配信 をご覧ください。 再エネ時代のエネルギーシフトに向けたエネルギー基盤を支える AWS サービスの活用 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 エネルギー&amp;ユーティリティ部 ソリューションアーキテクト の 岩下 高志朗 がプレゼンテーションを行いました。 グローバルウォーミング、カーボンニュートラルは世界中の国々、企業が取り組んでいる社会テーマとなっております。この来るべき再エネ時代は小規模の分散電源が大量に配置されるため、再エネ発電設備の最適化、電力需要供給のバランス調整、送配電設備の拡充計画などが重要となってきます。このようなニーズに対して、必要な業務機能群を整理し、そのような領域で活用できる AWS サービスの紹介と活用例を紹介しました。 詳細は オンデマンド配信 をご覧ください。 展示ブース 東海旅客鉄道株式会社/東海交通機械株式会社 AWS Village での東海旅客鉄道株式会社/東海交通機械株式会社様の共同ブースでは、 IoT を活用した鉄道機械設備のリモートモニタリングの展示が行われていました。設備が古く遠隔監視ができない機械や設備に対して、改修工事が不要な可搬式の電流センサー、温度センサーなどを設置し、 AWS IoT Greengrass を使って Amazon S3 へのデータ収集、 Amazon QuickSight による可視化を行うことで、遠隔地にある機械や設備のデータを事務所内で確認できることが実機とともに展示・紹介されていました。その他、 IoT で収集したデータを予兆保全につなげる事例など、鉄道機械設備における AWS の実活用事例が紹介されていました。 &nbsp;AWS 展示：クラウドで進化する鉄道機械保守 AWS Village の鉄道業向け AWS ブースでは、 IoT を使った鉄道機械設備管理システムのデモが行われていました。このデモでは、架空の駅の改札機やエレベーターなどを模擬した設備データを AWS IoT SiteWise で収集し、そのデータを基にしたアラーム監視や保全方法のリコメンドを Amazon Bedrock から受ける場面が再現されていました。また、遠隔地にある複数の駅のデータを構造化して保存し、横断的に可視化するダッシュボードなどがデモされており、クラウド利用の価値を実感できる内容となっていました。 &nbsp;AWS 展示：スマート X サステナビリティ ビル管理&nbsp; AWS&nbsp; IoT サービスを活用したスマート サステナビリティビル管理&nbsp;「サステナビリティを意識したミニチュア倉庫のデモを作ってみた !」 AWS IoT を活用し、持続可能性のソリューションライブラリの一つである 「Guidance for Smart and Sustainable Buildings on AWS」 を参考に、可視化したデータから省エネルギー化の洞察を得て、電力、費用及び温室効果ガス ( GHG ) 排出量の削減を実現するソリューションの実装例のデモを展示致しました。 「サステナビリティを意識したミニチュア倉庫のデモを作ってみた !」 でもご紹介している、 Amazon の倉庫を模したミニチュアモデルおいて、室温や空気の質をデータに基づいて適切に管理することで省エネルギーにつながる過程をご紹介しました。 AWS 展示：小さく早く始める効率化 – 製造現場の IoT データをパートナーとともに　 小さく早く製造 DX を実現 スマート工場の様々なユースケースをミニチュア工場を使って表現したデモが展示されました。 PLC のデータを AWS IoT SiteWise に集約し、構造的にデータを保持することで、他の様々なソリューションが活用しやすくなっています。工場内のオペレータ向けの稼働可視化ダッシュボードだけでなく、 Salesforce Field Service やパトライトの ネットワーク制御信号灯 などの AWS パートナーソリューションを活用したアーキテクチャも紹介されました。また、 4M 変化点情報を生成 AI の元データとして使用することで、生成AI の効果を発揮できる可能性についても提示しました。 AWS 展示：小さく早く始める効率化 – 製造業の課題に挑む AI ソリューション 工場における「外観検査モデル立ち上げ」と「生産設備のリアルタイム監視と障害対応」の2つのユースケースを、生成 AI を用いて効率化するデモを展示しました。このデモでは、外観検査の機械学習モデル作成に必要な学習画像を準備できないという課題を、生成 AI を用いて画像生成することで解決しています。また、チャットに対して設備状態を問い合わせると、リアルタイムな設備の使用状況や設備の仕様やプログラム、障害対応手順に基づいて生成AIを用いたレスポンスを受けることができています。生成 AI を用いることで、生産現場のさらなる効率化の可能性を見ることができました。 東京ガス 株式会社 東京ガス 株式会社 のブースでは、 OT データをクラウドに集約し、最適制御や予知保全などのデータ活用を可能にするソリューションが展示されていました。当社が提供する国内トップシェアの SCADA ソフトである JoywatcherSuite と JoyCloudConnect に、 AWS IoT Core との MQTT 通信機能をプラグインすることで実現しています。 AWS 専用の接続設定があらかじめ準備されているため、短時間で AWS との接続が完了します。プラントデータのクラウド接続方法がわからずに悩んでいるユーザーにとって、有効な選択肢となりそうです。 アイレット株式会社 アイレット株式会社のブースでは、本物の6軸ロボットを使用した生産状況可視化とトラブル分析の効率化を実現するデモが展示されていました。 AWS IoT SiteWise の稼働データと Kinesis Video Streams のカメラ映像を 1 枚のダッシュボードで統合的に表示し、異常が検知された前後の映像を自動で記録することで、後で遡って原因分析を行うことができます。トラブル発生前後の動画とデータを使って原因分析を行うことで、復旧までの時間短縮につながります。トラブルの原因究明に多くの時間をかけているユーザーにとって有効なソリューションとなりそうです。 富士ソフト株式会社 富士ソフト株式会社のブースでは、カメラ映像と IoT データを組み合わせた、クラウド型設備管理ソリューションのデモが展示されていました。現場の３次元画像と IoT データを統合したダッシュボードでAmazon Bedrockにより、自然言語で会話的に設備についての質問ができます。「エラーが一番多い場所に移動したい」、「ナースコールが鳴っている場所に移動したい」、「○○センサーの単位は？」など、日本語による会話で設備の現在の状態について問い合わせたり、見たい場所に移動することができます。まさにデジタルツインを体現したデモとなっていました。また、森田 和明氏による著書、 AWSの生成AIサービスを体系的に解説した入門書として&nbsp; Amazon Bedrock 生成AIアプリ開発入門 [AWS深掘りガイド] &nbsp; も出版されています。 スマート工場のための収集・可視化・分析 SCSK株式会社 SCSK 株式会社では、製造現場の可視化・分析のためのソリューション“Duetics（デュエティクス）“を工場を模した模型に接続して展示されていました。AWSでも同じ模型を使ってデモをしていますが、こちらの展示では PLC を国内でシェアの高い三菱電機製に交換したり、クラウド側での大規模な分析ソリューションと接続し、日本のお客様にスマート工場のデータ収集・可視化・分析をすぐにでも導入できるような内容となっていました。 オムロン株式会社: 汎用性の高い技術で構築された IoT 端末可視化 オムロン株式会社のブースでは、 IoT の可視化環境をテンプレート化することにより、様々なお客様にむけた環境構築を効率的に進められるというご紹介をされていました。これによりビル管理や、加工機械等の工場の装置を遠隔監視する仕組みを多数のお客様に提供されています。工場等において、OT ネットワークとの接続が難しい場合にはセルラー回線と組み合わせたり、ビル等の工場以外では、オムロン株式会社独自のセンサーと通信モジュールを組み合わせた最適なソリューションを提供するというセンサーメーカーならではの展示をされていました。 AWS:&nbsp; AIによるプラント保守 – 生成AI・映像・音声と外付けセンサーによるプラント保守支援&nbsp; この展示では、プラント管理における技術継承を題材に、プラントを模した流体回路にセンサーを設置して AWS IoT Core で情報収集し、異常を発生させ、機器のエラー番号からのトラブルシュートを生成AIで行うデモを展示しました。 PLC から受け取ったエラーコードをもとに、過去の報告書から Bedrockが「想定される原因」「過去の対応策」「推奨作業事項」を提示しており、シアター形式で行われて大人気を博しました。詳細は こちらのブログ からご覧いただけます。 AWS: 小さく早く始める効率化 – Software Defined Factory システムインテグレータや、企業内の DX 部門は、工場の DX 化のための OT へのアクセスが簡単ではなく、一方で早く完成イメージを提示し活動を推進したいというジレンマを抱えています。この展示では、OT に見立てたクラウド上の仮想ネットワーク ( Amazon VPC ) 上で、機器をシミュレートするプログラムを動かし、AWS CDK を使って OT とクラウドのソリューション構築を自動化することで、OT にアクセスする前に可視化ソリューションを構築するアプローチを提示しました。 まとめ AWS Summit Japan 2024のインダストリアルIoTのコンテンツは、データの可視化だけでなく、デジタルツインや生産性向上など、IoTが実際の業務に直結する段階に進んでいることが感じられました。また、新しい流れとして、IoT と生成 AI を組み合わせたソリューションのアイデアも多く出展されており、今後のさらなる発展が楽しみです。AWS では、今後も IoT の可能性とビジネスを追求するカスタマの支援を加速していきます！ 著者 山本 直志 Industry Specialist Solutions Architect 製造業のワークロードを担当する Specialist SA として、お客様が AWS クラウドを活用し、今までにないソリューションを提供するお手伝いをしています。 新澤　雅治 IoT Specialist Solutions Architect 製造業、 IT ベンダーを経て AWS に 入社。現在は IoT スペシャリストソリューションアーキテクトとして、主に製造業のお客様のIndustrial IoT 関連案件の支援に携わる。

お客様から Amazon Elastic Container Service (Amazon ECS) に AWS CodeDeploy を使用して ブルー/グリーン デプロイを実装するための支援がしばしば求められます。 お客様のユースケースは通常、クロスリージョンおよびクロスアカウント間でのデプロイシナリオが含まれます。 これらの要件だけでも十分に難しいのですが、さらに CodeDeploy を使用する際には特定の設計上の決定が必要となります。 具体的には CodeDeploy の設定方法、CodeDeploy リソース (アプリケーションやデプロイグループなど) の作成時期と方法、アカウントとリージョンの任意の組み合わせにデプロイできるコードの書き方が含まれます。 本日は、そうした設計上の決定について詳細に説明し、 CDK Pipelines を使用してアカウントとリージョンをまたぐシナリオで Amazon ECS へサービスをデプロイする self-mutation パイプラインを実装する方法について説明します。このブログ記事では、 AWS Cloud Development Kit (AWS CDK) を使用したクラウドインフラストラクチャの開発とデプロイのための ベストプラクティス に従っている Java 製の デモアプリケーション も紹介します。記事中で言及されるコードはデモアプリケーションの実装です。 パイプラインの概要 CDK Pipelines は、さまざまな デプロイエンジン でパイプラインを構築するために使用されるコンストラクトライブラリです。 クロスリージョンやクロスアカウントのパイプラインを実装する際に、開発者やインフラストラクチャエンジニアが解決する必要がある実装の詳細を抽象化しています。 例えば、クロスリージョンのシナリオでは、 AWS CloudFormation はターゲットリージョンに複製されたアーティファクトを必要とします。 そのため、 AWS Key Management Service (AWS KMS) キー、 Amazon Simple Storage Service (Amazon S3) バケット、ポリシーをセカンダリリージョンに作成する必要があり、リージョン間でアーティファクトを移動できるようになります。 また、クロスアカウントのシナリオでは、CodeDeploy は構成ファイルの暗号化に使用される KMS キーへのアクセス権を持つクロスアカウントロールを必要とします。 これらはお客様が手作業で対処したくないものの一例です。 AWS CodeDeploy は、さまざまなシナリオでアプリケーションのデプロイを自動化するデプロイサービスです。Amazon EC2 インスタンス、オンプレミスインスタンス、 Lambda 関数、または Amazon ECS サービスにデプロイします。 AWS Identity and Access Management (AWS IAM) と統合して、アプリケーションをデプロイする際のアクセス制御を実装できます。 ブルー/グリーン型のデプロイでは、Amazon CloudWatch Alarms を使ってデプロイのロールバックを自動化できます。 CDK Pipelines は、AWS CloudFormation のデプロイを自動化するように設計されました。 AWS CDK を使用すると、これらの CloudFormation デプロイでは、インスタンスやコンテナへのアプリケーションのデプロイを含めることができます。 ただし、一部のお客様は、アプリケーションのデプロイに CodeDeploy を使用することを好みます。 この AWS ブログ記事では、CloudFormation ではなく CodeDeploy を使用した CDK Pipelines のデプロイを紹介します。 設計上の考慮事項 この記事では、CodeDeploy を使用してサービスをアカウント (シングルアカウントまたはクロスアカウント) およびリージョン (シングルリージョンまたはクロスリージョン) の任意の組み合わせにデプロイするための、さまざまなユースケースに CDK Pipelines を活用することを検討します。 具体的には、以下の 4 つの問題を解決する必要があります。 CodeDeploy の設定 CodeDeploy を使ってブルー/グリーンデプロイタイプを実装するための最も一般的なオプションは、 AWS::CodeDeployBlueGreen マクロ を使うか、CodeDeploy コンストラクトを使うことです。この記事では後者の方法を採用します。同じ問題をカスタムリソースを使って解決しているお客様もいますが、この方法はカスタムリソースを使わない柔軟な方法です。パイプラインは実行のたびにコンテナを Amazon Elastic Container Registry (ECR) にプッシュし、タグを作成します。CodeDeploy はその情報をコンテナのデプロイに使います。 ここで推奨したいのは、AWS CDK クラウドアセンブリをスキャンし、リポジトリとタグ情報を取得するためにパイプラインアクションを作成することです。同じアクションで CodeDeploy 設定ファイルの作成を行うこともできます。CodeDeploy を設定するには、 appspec.yaml 、 taskdef.json 、 imageDetail.json の 3 つの設定ファイルが必要です。 このパイプラインアクションは、CodeDeploy デプロイアクションの前に実行する必要があります。 appspec.yaml と taskdef.json のテンプレートファイルを作成し、 次のスクリプト をパイプライン内で実行することで3つの設定ファイルを作成することができます。 ## #!/bin/sh # # AWS CodeDeploy の設定を行うアクション # template-appspec.yaml と template-taskdef.json を元に環境に応じた設定ファイルを作成します # # Account = The Account Id # AppName = Name of the application # StageName = Name of the stage # Region = Name of the region (us-east-1, us-east-2) # PipelineId = Id of the pipeline # ServiceName = Name of the service. It will be used to define the role and the task definition name # # Primary output directory is codedeploy/. All the 3 files created (appspec.json, imageDetail.json and # taskDef.json) will be located inside the codedeploy/ directory # ## Account=$1 Region=$2 AppName=$3 StageName=$4 PipelineId=$5 ServiceName=$6 repo_name=$(cat assembly*$PipelineId-$StageName/*.assets.json | jq -r '.dockerImages[] | .destinations[] | .repositoryName' | head -1) tag_name=$(cat assembly*$PipelineId-$StageName/*.assets.json | jq -r '.dockerImages | to_entries[0].key') echo ${repo_name} echo ${tag_name} printf '{"ImageURI":"%s"}' "$Account.dkr.ecr.$Region.amazonaws.com/${repo_name}:${tag_name}" &gt; codedeploy/imageDetail.json sed 's#APPLICATION#'$AppName'#g' codedeploy/template-appspec.yaml &gt; codedeploy/appspec.yaml sed 's#APPLICATION#'$AppName'#g' codedeploy/template-taskdef.json | sed 's#TASK_EXEC_ROLE#arn:aws:iam::'$Account':role/'$ServiceName'#g' | sed 's#fargate-task-definition#'$ServiceName'#g' &gt; codedeploy/taskdef.json cat codedeploy/appspec.yaml cat codedeploy/taskdef.json cat codedeploy/imageDetail.json ツールチェーンの利用 効果的な戦略は、パイプラインをツールチェーンにカプセル化して、さまざまなアカウントやリージョンへのデプロイ方法を抽象化することです。これにより、パイプラインの作成方法、CodeDeploy の設定方法、および別のアカウントやリージョンへの展開方法など、実装の詳細を切り離すことができます。パイプラインを作成するには、 デモアプリケーション 内の Toolchain スタックをデプロイします。これは必要に応じて別の環境を追加できるようになっています。要件によってはコンポーネントごとに異なる Stage や Wave を反映するように、パイプラインをカスタマイズする必要があります。より詳細な情報は、 安全なハンズオフデプロイの自動化 とその リファレンス実装 を参照してください。 Toolchain スタックは、Java 用 CDK 全体で使われている Builder パターンに従っています。これは、1 つの文で複雑なオブジェクトを作成できる便利な機能です。 Toolchain.Builder.create(app, Constants.APP_NAME+"Toolchain") .stackProperties(StackProps.builder() .env(Environment.builder() .account(Demo.TOOLCHAIN_ACCOUNT) .region(Demo.TOOLCHAIN_REGION) .build()) .build()) .setGitRepo(Demo.CODECOMMIT_REPO) .setGitBranch(Demo.CODECOMMIT_BRANCH) .addStage( "UAT", EcsDeploymentConfig.CANARY_10_PERCENT_5_MINUTES, Environment.builder() .account(Demo.SERVICE_ACCOUNT) .region(Demo.SERVICE_REGION) .build()) .build(); 上記では、CDパイプラインが TOOLCHAIN_ACCOUNT と TOOLCHAIN_REGION で作成されています。 このパイプラインには、Apache Maven を使ってソースコードをビルドし、Java アーカイブ (JAR) を作成するステージが実装されています。 その後、パイプラインは JAR ファイルを含む Docker イメージを作成します。 UAT ステージでは、 CANARY_10_PERCENT_5_MINUTES のデプロイ設定を使用して、サービスを SERVICE_ACCOUNT と SERVICE_REGION にデプロイします。 つまり、最初に 10% のトラフィックが新しいアプリケーションに移行され、残りの 90 % が 5 分後にデプロイされます。 追加のデプロイステージを作成するには、 ステージ名 、CodeDeploy の デプロイ設定 、そしてサービスをデプロイすべき 環境 が必要です。先に述べたように、このパイプラインはデフォルトで自身を変更する Self-mutation パイプラインです。たとえば、 Prod ステージを追加するには、 Toolchain オブジェクトを作成する CDK コードを更新し、この変更をコードリポジトリに送信します。パイプラインが実行され、 UAT ステージの後に Prod ステージが追加されてパイプライン自身が更新されます。次に示すのは、新しい Prod ステージを追加するコードです。新しいステージは UAT 環境と同じアカウントおよびリージョンにデプロイされます。 ... .addStage( "Prod", EcsDeploymentConfig.CANARY_10_PERCENT_5_MINUTES, Environment.builder() .account(Demo.SERVICE_ACCOUNT) .region(Demo.SERVICE_REGION) .build()) .build(); 上記の文では、 Prod ステージが CodeDeploy の デプロイ構成 CANARY_10_PERCENT_5_MINUTES を使用して、新しいバージョンのサービスをデプロイします。 つまり、最初に 10 % のトラフィックが新しいバージョンのアプリケーションに移行され、5 分後に残りのトラフィックが新しいバージョンに移行されるということです。 ビジネスアプリケーションの分離と管理のベストプラクティスについては、 複数のアカウントを使用した AWS 環境の構成 ホワイトペーパーを参照してください。 一部のお客様は、このアプローチに興味を持たれ、アプリケーション開発チームへの抽象化されたソリューションとして提供することを決定するかもしれません。 その場合、そのようなパイプラインを構築するコンストラクトを作成することをお勧めします。コンストラクトを使うと、さらにカスタマイズできます。 例えば、品質保証を促進するステージや、災害復旧シナリオでサービスをデプロイするステージなどです。 この実装では、ツールチェーンスタックと、各デプロイステージ用のスタックを作成します。たとえば、 UAT という単一のデプロイステージでツールチェーンが作成された場合を考えましょう。 正常に実行されると、次の画像のように DemoToolchain および DemoService-UAT スタックが作成されます。 CodeDeploy アプリケーションとデプロイグループ CodeDeploy の構成には、アプリケーションとデプロイグループが必要です。ユースケースによっては、ツールチェーン (パイプライン) と同じアカウントあるいは別のアカウントでこれらを作成する必要があります。パイプラインには、ブルー/グリーンデプロイを実行する CodeDeploy デプロイアクションが含まれています。 私の推奨は、CodeDeploy アプリケーションとデプロイグループをサービススタックの一部として作成することです。 このアプローチにより、CodeDeploy アプリケーションとデプロイグループのライフサイクルを関連するサービススタックインスタンスと合わせることができます。 CodePipeline を使うと、存在しない CodeDeploy アプリケーションとデプロイグループを参照する CodeDeploy デプロイアクションを作成できます。 これにより、以下のアプローチを実装できます。 ツールチェーンスタックは、存在しない CodeDeploy アプリケーションとデプロイグループを参照するデプロイアクションでパイプラインをデプロイします パイプラインが実行されると、まず関連する CodeDeploy アプリケーションとデプロイグループを作成するサービススタックがデプロイされます 次のパイプラインアクションでデプロイアクションが実行されます。パイプラインがデプロイアクションを実行する段階では、必要な CodeDeploy アプリケーションとデプロイグループが（前のステップで作成されたため）存在しています。 以下は、(最初は存在しない) CodeDeploy アプリケーションおよびデプロイグループを参照するパイプラインコードです。 private IEcsDeploymentGroup referenceCodeDeployDeploymentGroup( final Environment env, final String serviceName, final IEcsDeploymentConfig ecsDeploymentConfig, final String stageName) { IEcsApplication codeDeployApp = EcsApplication.fromEcsApplicationArn( this, Constants.APP_NAME + "EcsCodeDeployApp-"+ stageName, Arn.format(ArnComponents.builder() .arnFormat(ArnFormat.COLON_RESOURCE_NAME) .partition("aws") .region(env.getRegion()) .service("codedeploy") .account(env.getAccount()) .resource("application") .resourceName(serviceName) .build())); IEcsDeploymentGroup deploymentGroup = EcsDeploymentGroup.fromEcsDeploymentGroupAttributes( this, Constants.APP_NAME + "-EcsCodeDeployDG-"+ stageName, EcsDeploymentGroupAttributes.builder() .deploymentGroupName(serviceName) .application(codeDeployApp) .deploymentConfig(ecsDeploymentConfig) .build()); return deploymentGroup ; } これを機能させるには、パイプラインで CodeDeploy デプロイアクションを作成するときと、サービススタック (Amazon ECS インフラストラクチャがデプロイされている) で CodeDeploy アプリケーションとデプロイグループを作成するときで、同じアプリケーション名とデプロイグループ名の値を使用する必要があります。 このアプローチが必要な理由はサービススタック内で作成したリソースを参照して CodeDeply デプロイアクションを設定すると循環依存エラーが発生するためです。 以下は、サービススタックコンストラクト ID を使用して CodeDeploy アプリケーションとデプロイグループに名前を付けるコードです。 パイプラインで CodeDeploy デプロイアクションを作成する際に使用したのと同じ名前をサービススタックのコンストラクト ID に設定しています。 // configure AWS CodeDeploy Application and DeploymentGroup EcsApplication app = EcsApplication.Builder.create(this, "BlueGreenApplication") .applicationName(id) .build(); EcsDeploymentGroup.Builder.create(this, "BlueGreenDeploymentGroup") .deploymentGroupName(id) .application(app) .service(albService.getService()) .role(createCodeDeployExecutionRole(id)) .blueGreenDeploymentConfig(EcsBlueGreenDeploymentConfig.builder() .blueTargetGroup(albService.getTargetGroup()) .greenTargetGroup(tgGreen) .listener(albService.getListener()) .testListener(listenerGreen) .terminationWaitTime(Duration.minutes(15)) .build()) .deploymentConfig(deploymentConfig) .build(); CDK Pipelines のロールと権限 CDK Pipelines は、さまざまなシナリオ (リージョンやアカウントなど) においてデプロイを実行するためのロールとアクセス許可を作成します。 CodeDeploy を別のアカウントで実行する際、CDK Pipelines はクロスアカウントのサポートスタックをデプロイします。このサポートスタックは、CodeDeploy アクションのためのパイプラインアクションロールを作成します。 このクロスアカウントのサポートスタックは JSON ファイルに定義されており、対象アカウントの AWS CDK の Assets バケットにアップロードする必要があります。 パイプラインで self-mutation 機能が有効 (デフォルト) の場合、UpdatePipeline ステージでは cdk deploy を実行し、パイプラインへの変更をデプロイします。 クロスアカウントのシナリオでは、このデプロイにはクロスアカウントのサポートスタックのデプロイ/更新も含まれます。 このため、UpdatePipeline ステージの SelfMutate アクションは、リモートアカウントで CDK の ファイル公開 と デプロイ のロールを引き受ける必要があります。 UpdatePipeline ステージを実行する AWS CodeBuild プロジェクトに関連付けられている IAM ロールには、デフォルトではこれらのアクセス許可がありません。 CDK Pipelines は、クロスアカウントスタックに必要なアクセス許可の情報は AWS CDK アプリの合成が終わった後でしか利用できないため、これらのアクセス許可を自動的に付与することはできません。その時点では、パイプラインのアクセス許可がすでにロックされています。 したがって、クロスアカウントのシナリオでは、ツールチェーンがパイプラインの UpdatePipeline ステージのアクセス許可を拡張して、 ファイル公開 と デプロイ のロールを含める必要があります。 クロスアカウント環境では、これらのアクセス許可を手動で UpdatePipeline ステージに追加することが可能です。そのためには、 Toolchain スタックを使用して、このような実装の詳細を隠すことができます。最終的には、以下のようなメソッドを使用して、不足しているアクセス許可を追加できます。パイプライン内の各異なるステージとアカウントのマッピングについて、ターゲットアカウントがパイプラインがデプロイされているアカウントと異なるかどうかを検証します。条件を満たした場合は、UpdatePipeline ステージに対して、ターゲットアカウントの CDK ブートストラップロールを引き受ける権限を付与する必要があります (キー aws-cdk:bootstrap-role で、タグ値は file-publishing または deploy )。以下の例は、UpdatePipeline ステージにアクセス許可を追加する方法を示しています。 private void grantUpdatePipelineCrossAccoutPermissions(Map stageNameEnvironment) { if (! stageNameEnvironment.isEmpty()) { this.pipeline.buildPipeline(); for (String stage : stageNameEnvironment.keySet()) { HashMap condition = new HashMap&lt;&gt;(); condition.put( "iam:ResourceTag/aws-cdk:bootstrap-role", new String[] {"file-publishing", "deploy"}); pipeline.getSelfMutationProject() .getRole() .addToPrincipalPolicy(PolicyStatement.Builder.create() .actions(Arrays.asList("sts:AssumeRole")) .effect(Effect.ALLOW) .resources(Arrays.asList("arn:*:iam::" + stageNameEnvironment.get(stage).getAccount() + ":role/*")) .conditions(new HashMap() {{ put("ForAnyValue:StringEquals", condition); }}) .build()); } } } デプロイステージ UAT という単一のデプロイステージがあるパイプラインを考えてみましょう。 UAT ステージでは DemoService をデプロイします。それには 4 つのアクション: DemoService-UAT (準備とデプロイ)、ConfigureBlueGreenDeploy 、そして Deploy が必要です。 DemoService-UAT.Deploy アクションは ECS リソースと CodeDeploy アプリケーションとデプロイグループを作成します。ConfigureBlueGreenDeploy アクションは CDK クラウドアセンブリ から ECR リポジトリやコンテナイメージのタグ情報を読み取ります。パイプラインはこの情報をデプロイアクションに送り、CodeDeploy を使ったデプロイが開始されます。 ソリューションの概要 利便性のため、これらすべての課題を解決し、リファレンス実装として使える Java アプリケーション を作成しました。 このアプリケーションのデプロイは、アカウントやリージョンでのすべてのデプロイシナリオで同じ 5 つのステップに従い、次の設計に表されているシナリオも含まれます。 結論 この投稿では、アカウントとリージョンの様々な組み合わせで CodeDeploy を使用して Amazon ECS にサービスをデプロイするパイプラインを作成する際に伴う課題を特定、説明、解決しました。 また、これらの推奨事項を実装するデモアプリケーションを紹介しました。 サンプルコードを拡張して、自動テスト、自動デプロイロールバック、障害復旧など、より複雑なシナリオを実装できます。 あなたの変革の旅がうまくいくことを願っています。 Luiz Decaro Luiz は、アマゾンウェブサービス (AWS) のプリンシパルソリューションアーキテクトです。彼は金融サービス業界のお客様がクラウドで成功できるよう支援することに重点を置いています。Luiz はソフトウェアエンジニアリングの修士号を取得しており、2005 年に最初の継続的デプロイパイプラインを立ち上げました。 本記事は、 Luiz Decaro による “Blue/Green deployments using AWS CDK Pipelines and AWS CodeDeploy” を翻訳したものです。翻訳はソリューションアーキテクトの平川 大樹が担当しました。

6 月 20 日と 21 日の二日間にかけて、3 万を超えるオンサイト来場者とともに、今年の AWS Summit Japan は大盛況のうちに幕を閉じました。この二日間にわたり、150 以上のセッションと 250 以上のブース展示が行われ、AWS の最前線がここに集結しました。IoT が多岐にわたる産業に根ざし、実用的なフェーズに進む中で、今年は IoT と生成 AI を活用した革新的なソリューションも次々と試みられました。今年は実に30を超える IoT 関連のセッションと展示が行われましたが、その中のいくつかを IoT プロダクト編とインダストリアル IoT 編の二部構成にて、会場で感じた熱気とともにハイライトをお伝えしていきたいと思います。 セッション 『たまごっち』シリーズの進化と、AWS IoT で築いた『Tamagotchi Uni』でつながる世界 株式会社バンダイ トイ事業部 チーフ 坂本 大祐 氏 世代を超えて愛される「たまごっち」シリーズ初の Wi-Fi 搭載機種『 Tamagotchi Uni 』について、①複雑さの排除、②セキュアな接続、③大規模スケーリングのためにどのように AWS IoT を活用したかについて解説いただきました。特にグローバルで販売する大量のたまごっちへのデータ配信に時間がかかるという課題について、AWS IoT Core のダイナミックグループ機能を使ってそれを克服し、すべてのユーザーに公平に最新コンテンツを楽しんでもらうことに成功するストーリーは多くの観衆を引き込んでいました。詳細は オンデマンド配信 、また「 大規模台数のたまごっちへ AWS IoT Jobs で高速かつ高効率にファームウェアを配信する方法 」も合わせてご覧ください。 小規模体制でも開発できた電動車椅子の自動運転サービス～ AWS IoT 、サーバレスのクラウド活用～ WHILL 株式会社 CTO 福田 慧人 氏 近距離モビリティにおける自動運転のチャレンジを AWS IoT とサーバレスを活用して小規模体制かつ短期間で実現した事例を発表いただきました。交通ルールのない世界中の空港や美術館等で歩行者と同じ空間であらゆるシーンを想定して自律走行た実現においては、機体同士の最適なデマンドプランと経路設計、エレベーターシステムとの連携、そして利用者や管理者とのコミュニケーションを一つの統合された「自動運転サービス」システムとして実現しなければなりませんでした。小規模体制ながらも、AWS サーバレスをフル活用して短期間で機能開発されました。その中で特に注目すべきは機体の位置やセンサー情報をAWS IoT を介してAWSに集約し、リアルタイムに世界各国で動いている機体の自律走行を実現した点でした。今後は WHILL OS にも注力され、モビリティ分野へのエコシステムの形成を強化される方針も伺いました。詳細は オンデマンド配信 をご覧ください。 トヨタにおける車両データ利活用と社会インフラ支援への取り組み トヨタ自動車株式会社 デジタルソフト開発センター 社会システム PF 開発部 データ活用推進室 データサービス開発 Ｇ デジタル変革推進室（兼務） 新事業企画部 事業統括室（兼務) グループ長　坪田 沙弥香 氏 街を走行するトヨタの車両からは、日々様々なデータが AWS 上の構築されたコネクティッドデータプラットフォームにアップロードされており、このデータを活用した様々な取組みやサービス事例をご紹介いただきました。少し先の未来を見て、車両情報、映像を使って消防車両の到着を助ける実証実験例をご紹介いただき、「お客様の笑顔のために、あなたの車が誰かを助ける、誰かの車があなたを助ける」社会に向けたトヨタの取り組み大変印象的でした。ここでも AWS の生成 AI の活用検討の状況や Amazon Location Service の活用をご紹介いただいています。詳細は オンデマンド配信 をご覧ください！ SDV 時代のデータ駆動型自動車開発を支えるクラウド技術および生成 AI の適用性 日産自動車 株式会社 R&amp;D データサイエンスグループ Deputy General Manager 俵道 大輔 氏 Assistant Manager　葉 俊廷 氏 自動車における先進技術の研究・開発では、膨大なデータの活用が車両の性能改善や新機能の開発に貢献します。日産自動車株式会社は Engineering Workbench という開発環境により AWS IoT などによってクラウドに集約したデータを提供することで高度な実験を可能にし開発の効率性を高めています。さらに、生成 AI の活用やその評価により SDV 時代におけるデータ駆動型の自動車開発のアプローチを提案されていました。セッションは オンデマンド配信 でご覧いただけます。 KDDI のロボットプラットフォームにおける 開発の裏側 アイレット株式会社 執行役員 / アジャイル事業部事業部長 平野 健介 氏 KDDI 株式会社 先端技術統括本部 先端技術企画本部 ビジネス企画室 企画 1G グループリーダー 田中 政晃 氏 配送、見回り、清掃などのさまざまな利用シーンで活躍するロボット。多様なロボットをメーカーを問わず一元管理するロボットプラットフォームの開発において AWS IoT を活用した事例を紹介いただきました。ロボットの操作には AWS IoT Core が使用されていています。具体的には、ロボット認証のための証明書を手動でのキッティングする手間をなくす、プラットフォームからロボットに指示を出す、常時ロボットの情報を取得するなどの目的で活用いただいています。 展示ブース DMM オンクレ 合同会社 DMM.com 本物の500 台のクレーンゲームを 24 時間 365 日オンラインで楽しむことのできる DMM オンクレ 。オンラインでのクレーン操作には Amazon Kinesis Video Stream の WebRTC を活用した映像転送によりリアルタイム性と映像品質を確保されています。またクレーン毎に複数の制御用 IoT 機器が使われており、その管理や監視のために AWS IoT Core が活用されていたり、「人気のあるクレーンは？」などのゲームデータの解析には Amazon QuickSight を使うなどマネージドサービスをフルに活かした構成になっています。 Amazon Kinesis Video Streams 対応モジュール型カメラ i-PRO株式会社・富士ソフト株式会社 富士ソフト株式会社のブースでは、先日 Amazon Kinesis Video Streams へのデバイス認証(Device Qualification Program)対応が完了したばかりの i-PRO 株式会社のモジュール型カメラ moduca が展示されていました。小型の筐体・レンズ、通信ユニットを自由に組み替えが可能で、Amazon で購入可能な入手性を活かして、ソリューションの新規開発を高速化するカメラです。ブースでは、富士ソフト株式会社のデジタルツインとの接続と、エッジ AI 機能を用いたリアルタイム人物検知やモザイキングのデモを実施していました。 IoT Station 株式会社ゼネックコミュニケーション IoT Station では、AWS IoT Coreや自社開発のIFを利用することで異なる種類のセンサーや通信規格でも1つのダッシュボードに集約できます。IoTシステムにはいろいろなユースケースがありますが、様々な業種・業務課題に対応したテンプレート(Can-D)を利用することにより、開発期間を削減し、スピーディーなDX化が可能になっています。 スマートフィットネス: IoT を活用した生成 AI トレーナー AWS 展示 インストラクターのポーズと体験者のポーズを比較して、類似度を判定するというデモアプリケーションの展示。エッジのカメラで人の骨格情報を抽出して、それをAWS IoT Core を経由してAmazon BedRock の Claude3 へ送ることで判定します。判定結果の表示は IoT デバイス（マイコン）とも連携されており、デバイスと Web アプリを AWS IoT Core でリアルタイムかつシームレスに繋いでいました。ポーズの類似度を競うゲーム仕立てになっており、多くの来場者を楽しませていました。 生成AIが見守る!? 作業員の健康管理システムのデモ AWS 展示 ウェアラブルな IoT デバイスによってさまざまな環境下での作業者の心拍数や血中酸素濃度を取得し、また、温湿度などの室内の情報を測定するというデモを展示。取得されたデータは生成AIにより状況を判断させた内容とともにダッシュボードにて確認できるという、いろんな現場で活用できそうな内容になっていました。 生成 AI 車両データのリアルタイム分析デモ AWS 展示 目の前のサーキットを走るレース用ミニカーから回転数、スピード。サーキットの路面状況などのセンサーデータを AWS IoT Core や AWS IoT SiteWise を駆使して収集し、その場で分析するデモを行っていました。収集、分析、可視化での AWS サービス活用、さらに生成 AI によって作られたアナウンス、レースに勝つヒントやレース状況がドライバーに対して音声で読み上げられています。AWS らしく必要なブロックがうまく組み合わされて表現されているデモで興味深いものでした。 コネクテッドビークル AI解析による運転体験の最適化 AWS 展示 車から上がってくるセンサーデータとカメラ画像から路面状況把握し、AI 解析を通じて、ほぼリアルタイムに車のセッティングが自動で変わる世界をめざした HL Mando の MiCOSA の中で、AWS IoT FleetWise とその新機能である Vision System Data がどのように活用されているかをご紹介していました。車メーカーだけでなく、物流会社や保険会社など多くの業種の方がどのように AWS が車のデータ収集、活用に利用されているのか興味を持って聞かれてました。 仮想化で組み込みソフト開発・改善の高速化 AWS展示 スマートな製品の提供においては顧客ニーズを理解していち早く市場に製品を投入し、出荷後も DevOps の考え方により改善し続けることが重要です。そのための障害となっていた組み込みソフトウェア開発を含む DevOps 化の展示を行いました。空調機のコントローラーを題材に、ユーザーの機能利用状況を監視するダッシュボードを契機に、組み込みソフトウェアをクラウドでビルド・テストしAWS IoT Greengrass を介して更新する流れをデモとして提示しました。詳細は このブログ から参照可能です。 生成AIによるカメラ映像からの危険判別 AWS展示 製造現場などでの危険を検知するために、監視カメラの映像をクラウドに送って生成AIにより分析するデモを展示しました。カメラ映像はエッジの PC を介して Amazon Kinesis Video Streams によりライブ配信され、また画像フレームを Amazon Bedrock に入れ状況の記述や危険判定を行います。生成 AI の持つ汎用性により専用のモデル開発不要で様々な危険な状況に対応でき、マルチモーダルの生成 AI の可能性を感じさせるデモでした。展示資料は このブログ から入手可能です。 新価格体験を実現する次世代自販機 AWS展示 このデモでは、AWS のサービスを活用し、動的に価格を変動させる新しい自動販売機の体験を展示しました。自販機に内蔵されたコントローラに AWS IoT GreenGrass を搭載し、温度、商品の在庫状況、カメラによる混雑状況を考慮し、動的に商品の価格を変更（ダイナミックプライシング）するデモを紹介しました。自動販売機の商品展示用の液晶パネルも、購入ボタンも、AWS IoT Greengrass が搭載されたコントローラが制御し、AWS IoT Core 経由でリアルタイムで価格判定用の値と価格の変動を大画面のダッシュボードで表示し、お客さんに新しい体験を実感していただきました。 まとめ IoT のさまざまなユースケースが、会場の各所で見られた AWS Summit Japan 2024 でした。IoT がいかに多様な形で進化しているかを如実に示す機会だったと思います。また、新しい流れとして、IoT と生成 AI をさまざまな形で組み合わせたソリューションのアイデアも注目を集めており、これからの新しい流れになりそうで楽しみです。AWS では、今後も IoT の可能性とビジネスを追求するカスタマの支援を加速していきます！ 著者 山本 直志 – Industry Solutions Architect (MFG) 製造業のワークロードを担当する Specialist SA として、お客様が AWS クラウドを活用し、今までにないソリューションを提供するお手伝いをしています。 真保 安憲 – IoT Sales Specialist 日本のIoT事業開発を担当しています。AWS IoTでモノとクラウドをつなぐだけでなく、人と人もつないで、皆様のIoT実現を一緒に進めるお手伝いをさせていただいています。 井上 昌幸 – IoT Specialist Solutions Architect Internet of Things と Robotics 界隈で面白い事を探しながら、今日もこつこつリアルな世界とクラウドを繋いでいます。とっておきのアイデアを AWS と一緒にカタチにしましょう。

本稿では株式会社NTTドコモ（以下、docomo）において、映像配信サービス『Lemino』の開始にあわせて配信基盤を再構築し、同時視聴ユーザが数百万規模のライブ配信を実現した取り組みについて、全4回に分けてご紹介します。この取り組みについて概要をご覧になりたい方は 導入事例ページ もご覧ください。 第一回　適切なデータストアの選定とアーキテクチャの見直し 1.はじめに docomoの『Lemino』は、2015 年から提供していた『dTV』をリニューアルする形で誕生した映像配信サービスです。 既存システムにとらわれず、新機能を素早く提供するとともに大規模なライブ配信を実現するために、データストアを改めて選定し、全てのアーキテクチャを見直しました。 dTV では目標需要を満たす設備が構成上の制約で準備できませんでしたが、Lemino では需要予測に応え、なおかつ低コストに配信可能になっています。 2.旧システムでのスケーリングの阻害要因 複数のアプリケーションでデータベースを共有すると、密結合が生じ、パフォーマンスの問題が発生する可能性があります。 以前の dTV のシステムでは、データベースは Amazon Aurora PostgreSQL をシャーディングせずに 1 クラスタで、すべてのアプリケーションで共有し、密結合の状態で使用していました。ただし、dTV のシステムは数百万規模の同時視聴のような大規模なライブ配信の要件が無かったため、Amazon Aurora PostgreSQL 1クラスタでも十分運用できていました。 Amazon Aurora 自体は Lemino でも活用していて、一般的な RDBMS を使いたいユースケースにマッチしています。データベース管理タスクをマネージドに提供してくれるため、データベースの管理作業が楽になります。 一方で、大規模なライブ配信の際にコンピュート（ Amazon EC2 ）の台数を数千にまで増やすことを検討・検証した際、PostgreSQL へのコネクション数増加によるリソース逼迫とトランザクション管理が課題になり、スケーラビリティを阻害する要因になっていました。 Cache や Read Replica の利用、RDS Proxy の活用による接続プーリング等、Amazon Aurora PostgreSQL のままで改善可能なことは検討しましたが、ライブ配信は開演時に急激にアクセスが来るうえに、セッションやデバイスの管理のために書き込み処理が避けられなかったため、どうしても急激なトランザクション増加に耐えられるように Writer のインスタンスのサイズを事前に大きくしておかなければなりませんでした。Writer のインスタンスのサイズは無限に大きくできるわけではありませんし、Writer インスタンスを変更するためにサービスの瞬断を伴う運用作業が必要になり、ユーザー影響が少ない時間帯に作業する労力がかかりました。常に Amazon Aurora PostgreSQL のインスタンスを大きなサイズにしておくことは費用の観点から難しく、作業は停止が許容されるメンテナンス時間帯で終わらせなければなりません。Amazon Aurora PostgreSQL に接続するコンピュートの数が増えれば増えるほど、DBを大きいものに変更した後にフロント側のコンピュートをスケールアウトするための時間がかかるようになり、予定していた時間の中で、想定数のコンピュートを起動し終えることは現実的ではありませんでした。 また、機能面のスケーラビリティも課題でした。Lemino は視聴ユーザーに合わせて広告型無料配信 / 月額有料配信 / PPV 配信など、様々な形態で提供し、感情検索やスタンプ、コミュニケーション機能などの機能拡張も実施が決定していました。このようなサービス追加は密結合なシステムでは影響範囲が大きくなるため困難でした。アプリケーションの更新時や故障時の影響を小さくするために、サービス分割を見直すことは必要不可欠でした。 図1.dTVのアーキテクチャ概要 3.Leminoでの設計方針 性能面・機能面のスケーラビリティを向上するために、RDBMS 以外のデータベースも含め、機能ごとに最適なデータストアを選定しました。既存のアプリケーションから、映像配信に必要となる基本機能とその画面遷移を検討、配信時にアクセス数が増える導線を確認し、どの機能がどのような API でデータにアクセスするかを整理して、書き込み・読み込み負荷を推測し、どこでコントロールできるかを確認していきます。 その上でデータストアを選定していきますが、その際、以下のような Step で検討しています。 Step1 データ取得時の検索条件およびリレーションの要否 アプリケーションがデータを取得する際の検索条件およびリレーションの要否を整理します。どのようなクエリが必要なのか、Primary Key 検索だけでデータアクセス要件が満たせるのか、もしくは複数のカラムまたは複数テーブルを結合した検索が必要かを検討します。 Step2 アクセス機能と負荷 どの機能が使われるとどのデータにアクセスするか、書き込み・読み込みを分けてそれぞれの想定負荷を検討します。 Step3 アクセスレコードの分散 特定のレコードにアクセス集中する場合は、どの程度キャッシュが活用できるのかを検討します。 図2. Lemino のデータストア選定検討サンプル この検討は Step1 から 3 までを実施して終了にはなりません。実際は、アプリケーションに対してユーザーがどのような導線でアクセスしてくるか、ユーザのdアカウントログイン有無や利用デバイスにより、API のアクセス数そのものが大きく変わります。ライブ配信などによるスパイクアクセス時の最大負荷を計算し、実際に負荷をかけて検証していくなかで、このデータストア選定、テーブル設計で問題ないか確認し、ボトルネックを洗い出しておくことが重要です。 4.Leminoで主に利用しているデータストア Lemino のシステムは映像そのものを配信する部分や dアカウントログイン、月額サービス契約導線やクレジットカード決済など様々なサービスで構成されていますので、ここで紹介するデータストアはあくまで Web やモバイルのアプリケーションのバックエンドで利用している一例です。AWSのマネージドサービスを活用することで、データベースそのものの学習コストは少なく済み、複数種類のデータベースを併用しても問題なく運用できています。 Amazon DynamoDB あらゆる規模で一桁ミリ秒のパフォーマンスを実現する、サーバーレス NoSQL フルマネージドデータベース。秒間数十万の高い読書き性能が必要、かつ、PK でのクエリでほとんどの要件が満たせるデータを管理。 ※ 各種セッション情報、および、ユーザーデータを管理 ※ 特定レコードに負荷が集中する場合は DynamoDB Accelerator (DAX) を利用 Amazon OpenSearch Service リアルタイム検索のスケールアウトをマネージドに実現できるマネージドサービス。高い読込み性能が必要で、かつ、複数のキーで検索が必要なデータを管理。 ※ コンテンツデータやエモートラインなど、検索用データを管理 Amazon Aurora PostgreSQL PostgreSQL との完全な互換性を持ち、グローバル規模で活用されている高パフォーマンスと可用性を実現する RDBMS のマネージドサービス。 複数テーブルを結合したトランザクション管理が必要なデータを管理 ※ ログイン済みの会員データ、月額契約・購入情報、集計用アーカイブを管理 図3. Lemino のアーキテクチャ概要 5.まとめ 第一回の事例では、パフォーマンスと機能面のスケーラビリティを確保するために Lemino の開発で実施した、適切なデータストアの選定とアーキテクチャの見直し方法をご紹介しました。 スパイクアクセスに耐え、アジリティ向上を目指してリアーキテクトを検討中の皆様の参考にしていただければ幸いです。 著者について 株式会社NTTドコモ 第一プロダクトデザイン部 映像サービス担当　松原拓也 株式会社NTTドコモで提供している映像配信サービス『Lemino』のアーキテクト及び、バックエンドシステムのリードエンジニア、プロジェクトマネージャーを担当。 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ストラテジックインダストリー技術本部　津和﨑美希 通信業界のお客様を担当するソリューション アーキテクト。普段は通信業界のお客様の AWS活用 を支援していますが、Observability については AWS 社内でコミュニティ活動をしています。ここ数年、動画配信等、Media Service のご支援にも手を広げるなど、幅広い AWS 活用をご支援しています。

こんにちは、ソリューションアーキテクトの金澤（ @ketancho ）です。 今年もあっという間に半分が終わってしまい、7月に入ってしまいましたが皆さまいかがお過ごしですか？私は年始に掲げた目標のうち、このままだと達成できなそうなものが幾つかあるので、いよいよアクセルベタ踏みで頑張らなければと思っています。毎日コツコツやっていきたいものです。 さて、「今年の目標」と書きましたが、2024 年の目標として「AWS を使い始める」や「AWS 力を上げていきたい」を掲げた方、あるいは身近な方でそれを掲げられている方はいらっしゃいませんでしょうか？そのような皆さまにおすすめなイベント AWS Builders Online Series が今月 7/18(木) に開催されます。 &gt;&gt; AWS Builders Online Series のお申し込みはこちらから Builders Online はどんなイベント？ AWS Builders Online Series は、初心者を対象とした AWS の基礎を幅広く学ぶことができるオンラインイベントです。「初学者を対象とした」と書きましたが、既に AWS をご利用のお客様も、最新情報を取り入れ基礎から解説いたしますので、これまで触れたことのないサービスのキャッチアップにもってこいだと考えています。 今回の Buiilders Onilne では、AWS 基礎、生成 AI、モダンアプリケーション開発の 3 つのテーマにフォーカスし、ゼロから学べるよう構成いたしました。デモを交えた分かりやすい説明により、すぐに実践に役立つ知識を習得していただきます。本イベントは、全てのセッションがライブ配信され、リアルタイムで皆様の質問に回答します。 最初のテーマは、AWS 基礎「90 分で学ぶ！AWS 超入門 2024」 今週から3週に渡り、この3つのテーマごとに Builders Online の見どころをリレー形式で紹介していこうと思います。まずは、 AWS 基礎 「90 分で学ぶ！AWS 超入門 2024」 の3つのセッションについて紹介いたします！ 「AWS 基礎」テーマで想定している参加者の方々 冒頭で少し触れたようなこれから AWS を活用していきたいという方や、一部のサービスは使ったことがあるものの他にも基本的なサービスについてもっと詳しくなりたい！という方をペルソナとしてセッションを考えています。例えば、4月から IT エンジニアになられた方をお迎えする最初の Builders Online シリーズになりますので、その皆さまの「AWS はじめの1歩」となるような内容にしたいと考えています。 また、ご自身のチームメンバーの方や組織の方にもっと AWS をキャッチアップしてほしい！という方にもおすすめです。そのような方にご紹介いただくのもありがたいですし、「AWS 基礎」の内容を社内用にアレンジして、社内勉強会の題材にしていただくような使い方もできるかもしれません。AWS には現在 240 を超えるサービスがありますが、後述するように「AWS 基礎」テーマでは、10以内に収まる数のサービスに絞ってお届けすることを考えています。まずはスモールスタートのための時間となるような3セッションを考えています。 「AWS 基礎」テーマで予定している内容 「90 分で学ぶ！AWS 超入門 2024」は、下記の3部作で構成しようと考えています。 09:40 – 10:10 BOS-01: 90分で学ぶ！AWS 超入門 2024 #1 – さぁ！AWS をはじめよう！ 概要: AWS のメリットや価値をお伝えしつつ、AWS アカウントを作成し、実際に手を動かすことができる環境を用意します。安全に AWS 環境を使っていくための基本のキについてもお伝えします。（学べるサービス: アカウント作成, IAM） 10:20 – 10:50 BOS-02: 90分で学ぶ！AWS 超入門 2024 #2 – さぁ！AWS を使ってみよう！ 概要：最初の30分で作成したアカウントを使って、AWS サービスを実際に使っていきます。Amazon EC2 や Amazon VPC といった AWS を使っていく上でまず最初に理解したいサービスについて、実践形式でお伝えしていきます。（学べるサービス：Amazon VPC, Amazon EC2） 11:00 – 11:30 BOS-03: 90分で学ぶ！AWS 超入門 2024 #3 – さぁ！AWS を活用しよう！ 概要：最後の30分は AWS を使っていく上でご理解いただきたい、「マネージドサービスの利点」と「単一障害点をなくす設計を心がける」をテーマに送ります。ここまでの構築をよりよく変更しながら、AWS のメリットを享受できる考え方を持ち帰っていただきます。（学べるサービス：Amazon RDS, ELB, WordPress, 口頭のみ（RDS MultiAZ, Auto Scaling）） 90分のうち、いわゆる資料を使った座学のパートは極力少なくし、その分視覚的にイメージしやすいデモやホワイトボーディングの割合を増やせるように検討しています。このような登壇でホワイトボーディングをするのは初めてで、私にとってもチャレンジになりますが、少しでも学びに繋がる時間にできればと考えています。 今後の AWS の学び方にも触れられればと考えておりますので、これらのセッションで皆さまの AWS ジャーニーのはじめの一歩を踏み出していただければ幸いです。 まとめ 7/18 に開催される AWS Builders Online Series の紹介と、午前中に行う最初のテーマである AWS 基礎 「90 分で学ぶ！AWS 超入門 2024」 の概要についてお伝えいたしました。今回の Builders Online は 「生成 AI 実践入門」「モダンアプリケーション開発の基礎」 という後続のテーマもございます。これらについては、来週以降またこちらの AWS 公式ブログからご案内させていただきますので、楽しみにお待ちいただければと思います。 それでは、当日皆さまにお会いできることを楽しみにしています！ &gt;&gt; AWS Builders Online Series のお申し込みはこちらから このブログの著者 金澤 圭 (Kei Kanazawa) @ketancho サーバーレスが好きなソリューションアーキテクト。業種業界問わず、お客様のプロダクト開発をサポートさせていただいています。楽しく学べるコンテンツを考えるのが好きで、「 AWS Hands-on for Beginners 」、「 AWS ドリル連載@builders.flash 」といった企画・連載に携わっています。好きなサービスは AWS Lambda で、好きな休日の過ごし方は子どもたちと川の字になって昼寝をすること、家族と国内の津々浦々な場所に旅行に行くことです。

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 Amazon Bedrock では様々な基盤モデルを選択して利用することができ、新しいモデルが登場したらそれに乗り換えることも容易です。様々なモデルが用意されていますが、Amazon Bedrockでは利用できない、用途に特化したモデルを利用したいという場合もあるでしょう。その場合は Amazon SageMaker が提供する推論エンドポイントの機能を利用するのがベストな選択肢となります。こういったユースケースでよく目にするのが「日本語に特化したモデルを使いたい」というもので、SageMakerでも容易に利用できるモデルが日々登場しつつあります。 Amazon SageMaker JumpStart で ELYZA の日本語 LLM をワンクリックデプロイ AWS Marketplace に初掲載の日本語 LLM ! オルツの LHTM-OPT を利用する手順解説 これらの記事は、ELYZA株式会社さんと株式会社オルツさんの、日本語に特化したモデルを紹介するものです。いずれもSageMakerにデプロイする事で容易に利用できますので、ぜひ一度紹介記事を眺めてみてください。「こんなパターンもあるんだ」という気づきになると思います。 それでは、6 月 24 日週の生成AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ: 株式会社サルソニード様、生成AIで法律関係オウンドメディアの生地作成を効率化 株式会社サルソニード様 は、Webマーケティングのワンストップソリューションを提供していらっしゃいます。サルソニード様のマーケターの方は、マーケティング業務だけでなく記事の執筆やWebサイトの制作も担当していますが、業務拡大に増員が追いつかずリソース不足の状況が発生していました。これを解決するために生成AIによる業務効率化基盤の構築を検討していましたが、1名のエンジニアで社内システムや外部向けサービスの開発・運用を実施しており、業務効率化基盤の開発に手を付けることが困難でした。この2つの問題を解決するために、AWSの GenU(Generative AI Use Cases JP) を利用し、 Amazon Bedrock と Amazon Kendra によるRAGチャット環境を構築することとしました。これによって記事のリライト時間を70%削減し、マーケターの方がマーケティング業務に注力できるようになったとともに、会社公認の生成AIツールを提供する事でシャドーITの利用を防止することに成功しています。 AWS生成AI国内事例ブログ: 株式会社ココペリ様、ビジネスマッチングのためのニーズ認識に生成AIを適用 株式会社ココペリ様 は、 中小企業DX支援プラットフォーム「Big Advance」 を提供していらっしゃいます。Big Advanceでは様々な機能を提供していますが、そのひとつに企業同士のビジネスマッチング機能があります。ビジネスマッチングにはどういった需要があるかを示す「ニーズ」を作成することが必要ですが、それを容易にするために生成AIによる自動生成機能の導入を考え、検証を開始しました。Big Advanceに登録された企業情報やWebページなどを入力データとし、Amazon Bedrockを介したAnthropic Claude 2.1によるニーズ生成を行う作戦です。その結果、テストケースの97.9%が利用可能な出力であることを社内の評価で確認しています。現在この機能は社内利用を開始しているとのことですが、ワークフローを洗練させたうえでプロダクトへの機能実装を計画しているそうです。ココペリ様は、生成AIのユースケース策定にAWSの ML Enablement Workshop をご活用いただきました。このワークショップはプロダクトにAI/MLを適用し価値を高めるためのユースケースを特定し、ロードマップの策定を支援するものです。 コンテンツは公開 されていますので、ぜひご覧ください。 ブログ記事「Amazon Bedrockによる予知保全の強化」を公開 AWS IoT SiteWise 、 Amazon Lookout for Equipment 、 Amazon Bedrock を組み合わせて産業機器の予知保全業務を高度化する方法の一例を紹介するブログ記事を公開しました。この例では、AWS IoT SiteWiseで設備からのデータ収集と可視化を、Amazon Lookout for Equipmentで異常の検知を、Amazon Bedrockで作業者へのガイドを提供するという使い方をしています。機器の保守・保全の効率化は社会の様々な場所で課題になっていますので、その解決のヒントになるのではないでしょうか。 ブログ記事「【開催報告】生成 AI で教育を加速 ! 最新トレンドと実践ガイド(2024/05/29)」を公開 AWSでは5/29に 「生成AIで教育を加速！最新トレンドと実践ガイド」 というウェブセミナーを開催しました。教育分野では、生成AIの活用方法に関する疑問や、導入障壁をどう乗り越えるかが課題になっており、そこにフォーカスしたコンテンツになっています。動画や資料へのリンクもありますのでぜひご覧ください。 サービスアップデート Amazon Q in Connectがリアルタイムに順を追ったガイドを提供可能に Amazon Q in Connectで、オペレータの方に対して順を追った(ステップバイステップの)ガイドをリアルタイムで生成できるようになりました。お客様とのリアルタイムの会話に基づいて意図を理解し、ガイドを提供する事で顧客対応の時間短縮や品質向上が期待できます。 Knowledge Bases for Amazon Bedrockで可観測性を向上させるログを取得可能に フルマネージドなRAG(Retrieval-Augmented Generation, 検索拡張生成)機能を提供するKnowledge Bases for Amazon Bedrockでドキュメント取り込みに関する可観測性を向上させるログ情報を出力できるようになりました。RAGの基本的なアイデアとしては、データベースに社内ドキュメントなどの知識の源となる情報を取り込んでおき、生成AIの応答時にそれを活用するというものです。従って、データベースに情報が取り込まれているかどうかは重要なポイントになりますが、これまでは全体的な統計情報だけが参照できましたが、Retrieve APIとRetrieveAndGenerate APIを利用することで、ドキュメントがいつ取り込まれ利用可能になるかを取得し、明確に判断が行えるようになります。 Amazon BedrockでAI21 LabのJamba-Instructモデルが利用可能に Amazon Bedrockにおける基盤モデルの選択肢がさらに拡充され、AI21 LabのJamba-Instructをご利用頂けるようになりました。このモデルはユーザからの指示に適切に対応することに最適化されており、自由な対話に基づいて文脈を理解し、その指示に従って様々なタスクを実行することを得意とします。256Kのコンテキストウィンドウに対応しており、通話中のQ&amp;Aの記録や文書の要点整理はもちろん、調査・分析などのタスクについても高い性能を発揮します。 ブログ記事 もぜひご一読を。 AWS Blu Insightsを発表 機械学習と生成AIによってメインフレームワークロードのモダナイズを支援する新機能、AWS Blu Insightsを発表いたしました。AWS Blu Insightsは、Amazon Bedrockで稼働する生成AIモデルやAmazon Translateをはじめとする機械学習サービスを活用し、プログラムコードとファイルの説明の自動生成、メインフレームで利用されるプログラミング言語からの変換、プロジェクトに関する自然言語による問い合わせなどを容易に実現します。詳細については ドキュメント をご覧ください。 EvolutionaryScaleのESM3 1.4BモデルがAWSで利用可能に Amazon SageMaker JumpStartとAWS HealthOmicsでEvolutionaryScaleが提供するESM3 1.4Bモデルをご利用頂けるようになりました。ESM3は生物学の領域に向けて、新しいタンパク質を生成するモデルで、地球上の38億年に及ぶ進化の過程で発生した数十億種類のタンパク質配列を利用してトレーニングされています。これによって指定された配列、構造、機能的制約に基づいてタンパク質配列を生成することができます。日本語の ブログ記事 も出ていますのであわせてご確認ください。 AWS ParallelCluster 3.10がリリースされTerraformとAmazon Linux 2023をサポート AWS ParallelCluster 3.10がリリースされました。ParallelClusterはオープンソースのクラスター管理ツールで、HPC用途やAI/MLワークロードを実行するためにも利用されています。Terraformへの対応により、他のリソースを自動構築する仕組みと同様に、クラスタを構築・管理可能です。今回のリリースではSlurmとの連携やEC2 Spot Instanceに関する新しいリソース割り当て戦略も利用可能になっています。 Amazon SageMaker Studioのユーザ体験をカスタマイズ可能に Amazon SageMaker Studioは、機械学習の開発ステップのすべてに対応できる統合開発環境です。今回、管理者がユーザに提供するSageMaker Studioにおいてツールやアプリケーションなどの表示・非表示を制御し、より開発者にとって使いやすい環境を提供できるようになりました。 Amazon SageMaker Model Registryがクロスアカウントのモデル共有に対応 Amazon SageMaker Model RegistryがAWS Resource Access Managerと統合され、AWSアカウントをまたいだ機械学習モデルの共有や検出が可能になりました。複数のAWSアカウントを利用している環境において、アカウントをまたがった開発・構築作業が容易になります。 著者について 小林 正人(Masato Kobayashi) 2013年からAWS Japanのソリューションアーキテクト(SA)として、お客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援してきました。2024年からは特定のお客様を担当するチームを離れ、技術領域やサービスを担当するスペシャリストSAチームをリードする役割に変わりました。好きな温泉の泉質は、酸性-カルシウム-硫酸塩泉です。

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週も 週刊AWS をお届けします。 先週もお知らせしましたように AWS Summit Japan の各セッションについて、 オンデマンド配信 が始まっています。 7/5 まで動画閲覧や資料ダウンロードができますので、ぜひ活用ください。 AWS Summit に参加されて、これから AWS にトライしてみたい！と思った方も多いのではと思います。そのようなAWS入門者のためのオンラインイベントが 7 月 18 日（木）に開催されます。今回はトラックを1つだけにして、最初から順番に見ていただけると、「AWS 基礎」「生成 AI」「モダンアプリケーション開発」まで順に学べるように構成しています。ぜひご参加ください。 – AWS Builders Online Series – AWS クラウドの基本をゼロから学ぶ それでは、先週の主なアップデートについて振り返っていきましょう。とても発表が多い週だったので、できるだけ説明はシンプルにして分量を抑えているので、詳細はリンクされたWhats newやドキュメントを参照してください。 2024年6月24日週の主要なアップデート 6/24(月) Knowledge Bases for Amazon Bedrock now offers observability logs – AWS Knowledge Bases for Amazon Bedrock で CloudWatch、S3、Firehose Stream へログ配信を行うことができるようになり、オブザーバビリティを実現できるようになりました。Knowledge Bases for Amazon Bedrock はフルマネージドの Retrieval-Augmented Generation (RAG) 機能で、これにより、基盤モデル (FM) を社内のデータソースに接続し、より適切で正確な回答を提供できます。 6/25(火) Amazon ElastiCache supports M7g and R7g Graviton3-based nodes in additional AWS regions – AWS Amazon ElastiCache は Graviton3 ベースの M7g および R7g ノードファミリーをサポートしました。Redis 用 ElastiCache を R7g.4XLarge ノードで実行した場合、R6g.4XLarge で実行する場合と比較して、スループットが最大 28% 向上し、レイテンシー(P99)が最大で 21% 短縮します。また、各ノードのネットワーク帯域幅が最大 25% 高くなります。すでに東京リージョンでも利用可能です。 AWS CodeBuild supports Arm-based workloads using AWS Graviton3 – AWS AWS CodeBuild は、ソースコードのコンパイル、テストの実行、デプロイ準備が整ったソフトウェアパッケージの作成を行う、完全マネージド型の継続的インテグレーションサービスです。この AWS CodeBuild で、Arm ベースのワークロードを AWS Graviton3 上で実行できるようになりました。これによりこれまでの Graviton2 と比較してパフォーマンスが最大 25% 向上します。また、Graviton3 では、同等の EC2 インスタンスと同じパフォーマンスで消費電力が最大 60% 削減されるため二酸化炭素排出量の削減も実現可能です。CodeBuild の Arm サポートの詳細については、 こちらのドキュメントをご覧ください 。すでに東京リージョンでも利用可能です。 Amazon CodeCatalyst now supports GitLab.com source code repositories – AWS Amazon CodeCatalyst は、プロジェクトで GitLab.com でホストされているソースコードリポジトリの使用をサポートするようになりました。GitLab.comを含む3rd パーティー環境への拡張方法は こちらのドキュメント をご覧ください。 Amazon Time Sync Service expands microsecond-accurate time to 27 EC2 instance types – AWS Amazon Time Sync サービスでは、 27 種類の追加 Amazon Elastic Compute Cloud (Amazon EC2) インスタンスタイプでマイクロ秒以内の時刻同期がサポートされるようになりました。今回の拡張により、マイクロ秒精度の時間を使用する Amazon Time Sync は、米国東部 (バージニア北部) と東京リージョンの R7g、C7i、M7i、R7i、R7i、C7a、M7g、C7gd、R7gd、M7gd、M7gd インスタンスタイプで利用可能になりました。他の AWS リージョンにもサポートを拡大していく予定です。詳細は こちらのドキュメントをご覧ください 。 6/26(水) EventBridge Scheduler adds more universal targets including Amazon Bedrock – AWS Amazon EventBridge Scheduler に 650 以上の APIオペレーションを含むユニバーサルターゲットが追加されました。これにより、Amazon Bedrock を含めた合計7,000以上のAPIオペレーションに対応しました。Amazon EventBridge Scheduler はタスクを作成、実行、管理できるサーバーレススケジューラーサービスです。 ユニバーサルターゲットについてはこちらのドキュメントを参照 してください。 AWS CloudShell now supports Amazon Virtual Private Cloud (VPC) – AWS AWS CloudShell で Amazon VPC のサポートが一般提供開始(GA)になりました。これにより、 VPC 内に CloudShell 環境を作成できるようになるため、追加のネットワーク設定を必要とせずに、VPC 内の他のリソースと同じサブネット内で CloudShell を利用可能です。 Amazon Managed Service for Apache Flink now supports system-rollback – AWS Amazon Managed Service for Apache Flink でシステムロールバック機能が提供されるようになりました。コードまたは設定にエラーがあった場合に、Flink ジョブの送信中にアプリケーションを以前の実行中のアプリケーションバージョンに自動的に戻すことが可能になります。設定方法については こちらのドキュメントを参照してください 。 6/27(木) Amazon IVS Real-Time Streaming now supports up to 25,000 viewers – AWS Amazon IVS リアルタイムストリーミング機能のサブスクライバー制限を、AWS リージョンのステージごとに最大 25,000 人に引き上げることが可能になりました（これまでは10,000人でした）。これにより以前の倍以上のオーディエンスにライブストリーミングでリーチできるようになりました。 PostgreSQL 17 Beta 2 is now available in Amazon RDS Database Preview Environment – AWS Amazon RDS for PostgreSQL 17 beta 2 が Amazon RDS Database Preview Environment で利用可能になりました。RDS Database Preview Environment は本番用ではなく、事前に新しいバージョンを検証可能にするための環境です。今回の発表により、RDS for PostgreSQL 17 のプレリリースを評価できるようになりました。 Amazon Managed Service for Apache Flink now supports Apache Flink 1.19 – AWS Amazon Managed Service for Apache Flink が Apache Flink 1.19 ランタイムをサポートしました。このバージョンには、ステート TTL 設定、セッションウィンドウサポート、 Python 3.11 サポート、ジョブの再開とチェックポイントのためのトレースレポーターなどが含まれています。旧バージョンのランタイムからはインプレースバージョンアップグレードが可能です。 Amazon DataZone introduces API-driven, OpenLineage-compatible data lineage visualization in preview – AWS Amazon DataZone でデータリネージ(Data Linage)機能がプレビューとして利用可能になりました。 OpenLineage 対応システムから、または API を通じてのリネージイベントを視覚化することが可能で、データソースから利用（コンシューム）までのデータの動きを追跡可能になります。詳細は こちらのBlogポストをご覧ください 。 Amazon QuickSight simplifies building pixel-perfect reports with Repeating Sections – AWS Amazon QuickSight で、ピクセルパーフェクトレポートにセクションの繰り返し機能が追加されました。データソースの 1 つ以上のディメンションの値に基づいて自動的にレポートセクションを繰り返し自動生成するように設定可能です（例えばディメンジョン＝県で、繰り返しを設定すると、47都道府県毎のセクションが生成されます）。この機能の解説は Amazon QuickSight – Visualization Basics (Japanese) ハンズオン に今後追加予定です（現在作成中）。 Announcing Amazon WorkSpaces Pools, a new feature of Amazon WorkSpaces – AWS VDIサービスの Amazon WorkSpaces に新しく、Amazon WorkSpaces Pools が提供されるようになりました。これはユーザーグループ間で仮想デスクトップのリソースプールを共有することで、コスト最適化に役立ちます。詳細は こちらのBlogポスト をご覧ください。WorkSpaces Poolリリースに合わせ、これまでの WorkSpaces は WorkSpaces Personal と呼ぶように変更になりました。 AWS Blu Insights accelerates migrations with new AI capabilities – AWS AWS Blu Insights がアナウンスされました。これはAWSのメインフレームのモダナイゼーション支援のための統合サービスです。Amazon Bedrockで稼働する生成AIモデルやAwsの機械学習サービスを活用し、プログラムコードとファイルの説明の自動生成、プログラミング言語の変換、自然言語による問い合わせなどを実現する機能が提供されます。詳細については ドキュメントをご覧ください 。 6/28(金) Amazon EventBridge Pipes now supports AWS PrivateLink – AWS Amazon EventBridge Pipes が AWS PrivateLink をサポートするようになりました。これにより、パブリックインターネットを経由せずに Amazon VPC 内のプライベートサブネットから EventBridge Pipe にアクセスできるようになりました。 AWS CodeBuild build timeout limit increased to 36 hours – AWS AWS CodeBuild でこれまでは最大8時間だったビルドのタイムアウト設定が拡張され、最大 36 時間に延長できるようになりました。 Amazon WorkSpaces introduces support for Red Hat Enterprise Linux – AWS Amazon WorkSpaces Personal で既存の Ubuntu Desktop、Amazon Linux 2、Microsoft Windows に加えて Red Hat Enterprise Linux が選択可能になりました。WorkSpaces Personal 上の Red Hat Enterprise Linux は、AWS 中国リージョンを除き、WorkSpaces Personal が利用可能なすべての AWS リージョンでご利用いただけます。 料金についてはこちらのページ を確認してください。 それでは、また来週！ 著者について 下佐粉 昭(Akira Shimosako) @simosako 2015年より AWS Japan のソリューションアーキテクトとして、主に製造業・金融業のお客様に対し、クラウド活用の技術支援を行ってきました。その後、アナリティクス領域を専門とする部門に異動し、現在はデータレイク・データウェアハウスを専門としてお客様のデータをクラウドで活用することを支援しています。少年時代は 8 Bit パソコンと共に育ったため、その時代の本やアイテムを見かけると、ついつい買ってしまいます。

本記事は、2024年4月16日に公開された Why Fugaku, Japan’s fastest supercomputer, went virtual on AWS を翻訳したものです。翻訳は Solutions Architectの佐々木が担当しました。 日本の富士山（富岳） 世界で最も有名な山頂の1つに登ろうとするとき、最初に山へのアクセスのしやすさを考える人は少ないかもしれません。富士山はその高さと裾野が広いことで有名ですが、国によって登山道が整備されているため、初心者のハイカーでも時間をかけずに登ることができます。現在、世界最速のスーパーコンピューターの1つである「 富岳 」の開発者たちは、このスーパーコンピュータを アマゾンウェブサービス（AWS） クラウドでもアクセスできるようにしようと取り組んでいます。日本の多くの人に親しまれている名前をもつ「富岳」は、日本政府の国家プロジェクトとして、日本の 理化学研究所計算科学センター（R-CCS） が 富士通 と共同で開発したスーパーコンピューターです。 「富岳は富士山の別名です。スーパーコンピューターを「 富岳」と名付けたのは、富士山が日本で最高峰だからです。同時に、裾野が非常に広く、より多くの人々が「富岳」をより広い社会問題のために使ってほしいという私たちの願いとちょうど一致しています。」と、R-CCSの松岡聡センター長は述べています。 基礎科学から実生活へもたらすインパクトまで スーパーコンピューターは、最新のノートパソコンの100万倍の計算能力を備えています。「富岳」は16万ノードと800万の中央処理装置（CPU）コアを備えた巨大なスーパーコンピューターです。「富岳」は2021年3月に完成し、本格的に運用を開始して以来、社会のニーズに応えて多くの分野で利用されてきました。 新型コロナウイルス感染症（COVID-19）のパンデミックの間、ウイルスの飛沫がどのように拡散するかを「富岳」を使って詳細にシミュレーションしました。その他の例としては、薬剤候補の探索、経済的および社会的影響の予測、次世代太陽電池、洋上風力発電、線状降水帯予測、心臓シミュレーターなどがあります。 スーパーコンピューターを支えるスーパーリーダーシップ AWS re:Invent 2023に登壇された　　松岡センター長 AWS re:Invent 2023で松岡センター長は「バーチャル富岳：AWS上にオリジナルの環境を再現」というセッションに登壇しました。 「富岳」を語るには松岡センター長の話を欠かすことができません。松岡センター長は、2018年4月にR-CCSのセンター長に着任され、スーパーコンピューターの開発を指揮しました。「富岳」の民主化と、果てしない社会的課題への実践的アプリケーションの普及を支えた先駆者です。 「富士山は標高が高いにもかかわらず、道路や登山道の手入れが行き届いているので、誰にとっても登りやすいです。これは、世界で最も使いやすいスーパーコンピューターである「富岳」の理想的な姿です。「富岳」はイノベーションサイクルをはるかに速くするでしょう」と松岡センター長は述べます。 AWS による仮想化 クラウドで科学を進めるにはリーダーシップが必要です。松岡センター長によると、オンプレミスで稼働する「富岳」は「利用率は95％で常にフル稼働の状態です」。AWS クラウドを使用することで、「富岳」 はより優れた計算能力と影響力を活用できます。「これらの科学的成果が広まり、実際に社会に影響を与えるためには、この16万ノードのマシンを構築するだけでは十分とは言えません。「富岳」の価値は、ハードウェアだけでなく、アプリケーションを含むソフトウェアソリューションでもあります。だからこそ、私たちはAWSと協力して富岳アプリケーションをAWSクラウドに拡張しました」と松岡センター長は言います。「「富岳」のスーパーコンピューティング環境をクラウドに直接移すことでアプリケーションをクラウドで利用できるようになり、単一のシステムで動かすよりもはるかに大きな影響をもたらしました。」 AWSとのコラボレーションにより、「富岳」の環境をAWS上に複製し利用できる「バーチャル富岳」が誕生しました。「バーチャル富岳」は、スーパーコンピューター用に開発されたソフトウェアをそのままAWSクラウド上で実行する方法を提供します。 AWSにおける「バーチャル富岳」は、企業が秘密にしておきたい最先端の研究に簡単に使用できるため、利用範囲を広げることができます。たとえば、創薬や材料開発に使用される分子動力学ソフトウェアである GENESIS は、2023 年 12 月に AWS で利用できるようになりました。特に、2023年に実施された概念実証（PoC）では、複雑な計算やシミュレーションにおいて、AWS上の「バーチャル富岳」はオンプレミスの結果より2倍速いことが証明されました。 科学ワークフローへの道を開く 「今日の科学は、ワークフローのさまざまな要素の集合です。科学者がカスタマイズしたワークフローを簡単に構築できるプラットフォームの必要性は、ますます高まっています。そのため科学インフラにAWSが不可欠です」と松岡センター長は言います。「これらのハイパースケールノードはAWSの可能性をさらに広げることにもなります。イノベーションのサイクルを早めるために、私たちが協業できる領域はまだたくさんあります」と彼は付け加えました。 「富岳」はただのスーパーコンピューターではありません。それは科学のブレイクスルーのための触媒であり、計算の力を社会の進歩の最前線にもたらすものなのです。そして旅はなおも続いていきます。 関連記事 RMIT 大学の研究者が AWS ベースの HPC プラットフォームを活用して、 分子構造を 100 倍速く視覚化した方法 をご覧ください。 さらに、日本のお客様向けの参考情報として、先日開催されたAWS Summit Japan において理化学研究所 計算科学研究センター 運用技術部門 部門長の庄司様に ヴァーチャル富岳がめざすもの -スパコンとクラウドの幸せな関係- というセッションで登壇いただき、「バーチャル富岳」の取り組みについてご説明いただきました。こちらも合わせてご覧ください。 執筆者 Carl Ward カールは、アジア太平洋地域および日本地域のアマゾンウェブサービス（AWS）ワールドワイドパブリックセクターチームのディレクターです。 Ushio Usami 宇佐見は、日本のアマゾンウェブサービス（AWS）のワールドワイド公共部門のカントリーリーダーです。

競争の激しい産業分野では、ダウンタイムを最小限に抑えることが財務的な成功に不可欠です。課題は、事業環境内のさまざまなシステムに分散している複雑なデータを管理することにあります。高度な分析なしでは、問題を特定して解決することは困難です。 産業装置のオペレーターは、問題を診断して手順に従うために、しばしばマニュアルを参照することに時間を費やします。自動化によってこのプロセスは合理化できます。重要なのは、異常を早期に発見し、トラブルシューティングの指示を迅速に提供することです。 Amazon Web Services (AWS) はこうした業務の改善をより簡単にするのに役立ちます。 AWS IoT SiteWise 、 Amazon Lookout for Equipment と、 Amazon Bedrock はパワフルな組み合わせです。AWS IoT SiteWise は、工場やプラントの設備からの時系列データを大規模に収集して可視化します。Amazon Lookout for Equipment は機械学習を使用して微細な異常を検出し、コストのかかるダウンタイムを防ぎます。Amazon Bedrock はオペレーターに対して、検出された異常に対処するための手順を対話的に提供します。この 3 つのサービスが連携して産業設備からのデータを処理し、異常を検出し、効率的なトラブルシューティングの手順を提供します。オペレーターは、問題を迅速に解決し、ダウンタイムを最小限に抑え、業務効率を高めるための力を手にできます。 この技術ブログでは、AWS IoT SiteWise、Amazon Lookout for Equipment、Amazon Bedrock の統合による高度な産業分析システムの構成について説明します。焦点は、発生する機器の故障の検出、関連マニュアルの取得、包括的なメンテナンス計画の作成です。目標は、稼働時間を最大化し、生産性を高め、コストを削減し、工場やプラントの運営効率を飛躍的に高めることです。 ソリューションの概要 ここで説明する産業分析ソリューションでは、 AWS IoT Greengrass と AWS IoT SiteWise を使用して、工場の設備から時系列データを大規模に収集して可視化します。AWS IoT Greengrass により、IoT（モノのインターネット）デバイスや産業用デバイスは、データが生成された場所の近くでデータを収集して分析し、ローカルイベントに自律的に対応し、ローカルネットワーク上の他のデバイスとセキュアに通信することができます。このソリューションでは、 AWS IoT SiteWise Edge ゲートウェイが産業機器と AWS IoT SiteWise の間の仲介役を果たします。AWS IoT SiteWise Edge ゲートウェイソフトウェアは、AWS IoT Greengrass を実行できるどのデバイスにもデプロイできます。 AWS IoT SiteWise では、AWS IoT SiteWise アセットモデル (テンプレート) とアセットを使用して産業機器とプロセスをモデル化できます。さらに、産業分析ソリューションはこれらの設備間の関係を定義し、国際自動制御学会 (ISA) の ISA-95 に基づいてアセットの階層を構築します。 図 1. アーキテクチャ概要 このソリューションでは、AWS IoT SiteWise と Amazon Lookout for Equipment とを統合して用いています。これにより、ユーザーは機械学習に関する深い技術的知見を必要とせずに多変量を要因とする異常を検出できます。Amazon Lookout for Equipment では、機器あたり最大 300 個のセンサーからのデータを使用し、自動化された機械学習 (AutoML) を使用して最適なモデルをトレーニングできます。使用できる機器の例としては、コンプレッサー、ポンプ、モーター、ボイラー、ロボット、コンピューター数値制御 (CNC) マシンなどがあります。 Amazon Bedrock は、検知された異常に対処するようオペレーターに指示することで対応します。Amazon Bedrock は業界をリードする AI 企業の多様な基盤モデルを提供するフルマネージド型サービスで、セキュリティ、プライバシー、責任ある AI プラクティスに重点を置いた生成 AI アプリケーションを構築する機能を提供します。 この産業分析ソリューションでは Amazon Titan を使用しています。Amazon Titan は、AWS が作成し、大規模なデータセットで事前にトレーニングされた Amazon Bedrock 独自のモデルファミリーです。このソリューションでは、Amazon Titan Text Embeddings モデルを利用して、手順書を含むナレッジベースに記載された、事象の種類、前提条件、根本原因、解決手順、およびアプリケーションに関連する運用情報などから埋め込み (セマンティックベクトル) を生成します。 Anthropic の Claude ファミリーのように、Amazon Bedrock を通じて利用できる AI モデルは、ベクターデータベース内のコンテキストと異常検知結果から、適切な応答を作成します。これらの応答には、トラブルシューティングの手順、追加の詳細の確認、作業メモの追加、システムの問題に関するユーザーへの警告などが含まれます。このソリューションには、システムの運用状況を追跡できる統合異常検知ダッシュボードが含まれており、ソリューションの信頼性が向上します。 チュートリアル:異常検出と知識主導型メンテナンス 異常検知 図 2.異常検知 AWS IoT SiteWise ゲートウェイは、OPC 統合アーキテクチャ (OPC UA) サーバーなどのデータソースに接続して、工場現場からリアルタイムデータを取得します。AWS IoT Greengrass コンポーネントを搭載したゲートウェイソフトウェアは、このプロセスを簡単に実現できるようにします。その後、AWS IoT SiteWise は AWS IoT Greengrass ゲートウェイからこのデータを受け取ります。AWS IoT SiteWise Monitor を使用すると、工場の診断データをリアルタイムでモニタリングできます。収集されたデータは、分析の一貫性を保つために正規化されます。Amazon Lookout for Equipment は、設定時に提供された履歴データから構築されたモデルを使用して、リアルタイムデータを分析することで異常を検知します。異常が見つかると、Amazon Lookout for Equipment は AWS Lambda の自動処理を開始し、Amazon Bedrock に詳細なプロンプトを生成します。このシームレスなフローにより、産業環境における効率的なデータ処理、分析、対応が可能になります。 静的な知識をベースとしたメンテナンスプランの生成 図 3.静的な知識をベースとしたメンテナンスプランの生成 マニュアルと手順書で構成されるドキュメントは、オブジェクトストレージサービスである Amazon Simple Storage Service (Amazon S3) のバケットに格納されています。ワークフローでは、デジタルドキュメントには Amazon Bedrock (Amazon Titan モデル) を使用し、ドキュメント内のテキスト、手書き、およびレイアウト要素の処理には Amazon Textract を使用します。Amazon Lookout for Equipment によって異常が検出されると、AWS Lambda 関数が起動して、Amazon Titan を使って作成したベクトルデータを元に検索した文書をコンテキストとして含んだプロンプトが作成されます。その後、このプロンプトは Amazon Bedrock に転送され、Bedrock がドキュメントの内容にアクセスできるようになります。Amazon Bedrock に転送されたドキュメントの内容は、Amazon Lookout for Equipment によって生成されたアラートと組み合わされて、Amazon Bedrock に送信されます。その後、書式整形されたカスタムのメンテナンス計画が生成されます。最後のステップでは、AWS Lambda 関数が Amazon Simple Notification Service (Amazon SNS – フルマネージド型の Pub/Sub 型メッセージングサービス) を通じてカスタムメンテナンスプランを送信し、後で参照できるように Amazon S3 バケットにアーカイブします。 訳者注記：ここで説明されているのは一般的に 検索拡張生成(RAG) と呼ばれるテクニックです 結論 利益率が低い業界では、計画外のダウンタイムや業務の非効率化を防ぐことが急務です。このブログ記事では、AWS IoT SiteWise、Amazon Lookout for Equipment、Amazon Bedrock の統合が、このニーズを満たすのにどのように役立つかを学びました。 Amazon IoT SiteWise と Amazon IoT Greengrass は、IIoT エッジゲートウェイからデータを収集して変換することにより、総合的な洞察を提供します。Amazon Lookout for Equipment の機械学習は、異常を早期に検出し、コスト増につながる操業停止を回避するのに役立ちます。Amazon Bedrock は、組織の知識を活用して解決プロセスを自動化し、ユーザーに合わせたトラブルシューティングガイドを提供します。データの取り込みから異常の検出、メンテナンスの処方まで、このインテリジェントなループにより、新たな問題に迅速に対処できるようになり、ダウンタイムを減らし、関連コストを大幅に削減できます。 工場やプラントにおけるこれらの AWS サービスの統合について、デモンストレーションをご覧になりたい場合や、より深く掘り下げてみたいという場合は、AWSの担当者にコンタクトいただくか、 Webフォームからお問い合わせください 。私たちは、お客様がこれらのテクノロジーを活用し、生産業務の運用にプラスの変化をもたらすお手伝いをします。 この投稿は「 Empowering predictive maintenance with Amazon Bedrock 」を AWS Japan SA の岩根 義忠が翻訳しました。 Roberto Catalano Roberto は、スイスを拠点とする AWS のソリューションアーキテクトです。コンサルティング、クラウドコンピューティング、ソリューションアーキテクチャ、サイバーセキュリティで 6 年以上の専門知識を持つ彼は、熱心なテクノロジー愛好家です。彼の実践的な知識は、サイバーセキュリティ、ネットワーキング、IoT の導入など、さまざまな分野に及びます。 Luca Perrozzi Luca は、スイスを拠点とする AWS のソリューションアーキテクトです。AWS でのイノベーションのトピック、特にデータ分析と人工知能の分野に注力しています。Luca は素粒子物理学の博士号を持ち、リサーチサイエンティストおよびソフトウェアエンジニアとして 15 年の実務経験があります。

Amazon Simple Queue Service (Amazon SQS) は、いくつかのパブリックベータを経て 2006 年に ローンチ されました。20 年近く経った今でも、このフルマネージドサービスはマイクロサービス、分散システム、サーバーレスアプリケーションの基本的な構成要素であり、ピーク時には毎秒 1 億件を超えるメッセージを処理しています。 より良い方法は常に存在するので、パフォーマンス、セキュリティ、内部効率などを改善する方法の模索が続いています。AWS では、何かを改善できる可能性のある方法が見つかった場合、既存の動作を維持するように注意し、結果を比較できるように新しいシステムと古いシステムを並行して実行することがあります。 6月26日は、 Amazon SQS が最近どのように改善され、レイテンシーの削減、フリートキャパシティの増強、スケーラビリティの限界の緩和、そして消費電力の削減が実現したかをお伝えします。 SQS の改善 多くの AWS のサービスと同様に、 Amazon SQS は内部マイクロサービスのコレクションを使用して実装されます。6月26日は、そのうちの 2 つにフォーカスします。 お客様のフロントエンド – お客様が操作するフロントエンドは、 CreateQueue や SendMessage などの API コールの受け入れ、認証、承認を行います。次に、各リクエストをストレージバックエンドにルーティングします。 ストレージバックエンド – この内部マイクロサービスは、標準 (非FIFO) キューに送信されたメッセージを永続化する役割を果たします。セルベースのモデルでは、セル内の各クラスターに複数のホストが含まれ、各カスタマーキューは 1 つまたは複数のクラスターに割り当てられ、各クラスターは多数のキューを処理します。 接続 — 新旧の比較 元の実装では、これらの 2 つのサービス間でリクエストごとに 1 つの接続を使用していました。各フロントエンドは多数のホストに接続しなければならないので、接続プールを使用する必要があることに加えて、オープンな接続の数が最終的に制限されるリスクもありました。このような問題はシンプルにハードウェアを増強してスケールアウトすることで解決できますが、それが常に最善の方法であるとは限りません。現在の瞬間 (「スケーラビリティの崖」) を先送りするだけではリソースを効率的に使用することにはなりません。 Amazon SQS チームは、いくつかの長期的なソリューションを慎重に検討した結果、お客様のフロントエンドとストレージバックエンドの間における独自の新しいバイナリフレーミングプロトコルを開発しました。このプロトコルは、128 ビットの ID とチェックサムを使用して 1 つの接続で複数の要求と応答を多重化し、クロストークを防ぎます。 サーバー側の暗号化 は、キューデータへの不正アクセスに対する保護をさらに強化します。 望ましい結果 新しいプロトコルは今年初めに実用化され、この記事を執筆している時点で 744 兆 9 千億件のリクエストが処理されました。スケーラビリティの壁は解消され、この新しいプロトコルを他の方法で機能させる方法が既に模索されています。 パフォーマンス面では、新しいプロトコルによりデータプレーンのレイテンシが平均で 11% 減少し、P90 マークで 17.4% 削減されました。この変更は、SQS 自体のパフォーマンスを向上させるだけでなく、SQS を基盤とするサービスにもメリットをもたらします。例えば、 Amazon Simple Notification Service (Amazon SNS) を介して送信されるメッセージは、配信される前の「内部滞在」時間が 10% 短縮されました。最後に、プロトコルの変更により、SQS ホストの既存のフリート (X86 と Graviton を利用したインスタンスの混合) は、以前よりも 17.8% 多くのリクエストを処理できるようになりました。 その他の情報 Amazon SQS の実装の裏側はいががでしたか。コメント欄でお知らせください。他に共有できるストーリーが見つかるかもしれません。 – Jeff ; 原文は こちら です。

エージェントは、優れた顧客体験を提供する上で重要な役割を果たします。パフォーマンスの高いコンタクトセンターでは、エージェントはいわば超人的な存在です。つまり、エージェントは顧客を把握し、情報を把握し、問題を即座に解決します。そのような対応を通して、顧客が大切にされていると感じ、ロイヤルティを維持できます。また エージェントはコンタクトセンターの運営コストの 70% 以上を占めており 、そのためエージェントの業務を改善することは、単にサービスの向上に繋がるだけでなく、収益にも大きな影響を及ぼします。 顧客がエージェントに連絡する時点では、顧客はすでに多くのことを自分で試しています。解決策を探したり、ウェブサイトを訪れたり、チャットボットに話しかけたりしたうえで、最終的に人間のエージェントと話をしています。ですからこの段階で顧客が求めているのは、自分が経験してきたことを理解し、共感を持ちつつ、効率的に問題を解決してくれる存在です。このようなサービスこそが、顧客があなたの会社にロイヤリティをもち続けさせます。 では、どうすればエージェントの仕事が楽になり、カスタマーサービスを改善できるのでしょうか。このブログ記事では、 Amazon Connect の エージェントワークスペース にサードパーティのアプリケーションを統合することで、エージェントの効率とカスタマーエクスペリエンスがどのように大幅に向上するか詳しく説明します。ウェブアプリケーションをエージェントワークスペースに直接埋め込み、 Amazon Connect SDK を活用してシームレスな統合を実現するためのいくつかの重要な概念を説明し、いくつかのユースケースを紹介します。最後には、この設定がどのようにエージェントの作業をよりスマートにし、顧客によりスムーズな体験をもたらし、コンタクトセンターをより効率的に運営するのに役立つかがわかるでしょう。 主要な概念 Amazon Connect はシームレスで、すぐに使用できるコンタクトセンターソリューションであり、かつ、ビジネス固有のニーズに合わせて柔軟にカスタマイズできます。Amazon Connect のサードパーティアプリケーションサポートを利用する際に留意すべき重要な概念がいくつかあります。 エージェントワークスペース Amazon Connect エージェントワークスペース は Amazon Connect 用のウェブベースのエージェントデスクトップアプリケーションです。顧客の課題に対応するための様々な機能が統合されており、それらを単一のユーザーインターフェイス (UI) で提供します。これにより、エージェントは問題をより早く解決し、カスタマーエクスペリエンスを向上させることができます。エージェントワークスペース内では、エージェントは Amazon Connect Customer Profiles 、 Amazon Connect Cases 、 Amazon Q in Connect などの Amazon Connect 機能に、他のアプリケーションや画面に移動することなくアクセスできます。 Amazon Connect におけるサードパーティーアプリケーション Amazon Connect のサードパーティアプリケーションサポートが提供開始されたことで、エージェントが顧客の問題処理に使用されるすべてのツールと情報 (請求や注文など) に単一の UI でアクセスできるようにし、エージェントの効率と生産性をさらに高めることができます。これにより、Amazon Connect のネイティブ機能を活用しながら、業務に不可欠な既存のアプリケーション、ツール、ユーティリティも活用できます。すでに使用していて投資したアプリケーションを組み込むことができるため、既存の効果的な機能を置き換えることなく、エージェント体験を最新化できます。対象となるサードパーティアプリケーションには、インターネット経由でアクセス可能な URL を介してインラインフレーム (iframe) として埋め込むことができる Web アプリケーションが含まれます。さらに、新しいアプリケーションを追加したり、権限を制御したりできるので、エージェントは数回クリックするだけでツールにアクセスできるようになります。 Amazon Connect SDK Amazon Connect のサードパーティアプリケーションサポートは、エージェントが操作する UI を単純化または統合するだけではありません。この機能により、アプリケーションが他の Amazon Connect 機能を操作したり、連携したりできるようになり、問い合わせのオーケストレーションと自動化が可能になります。 Amazon Connect SDK を使用すると、顧客の名前、アカウント ID など、関連するコンテキストと問い合わせ属性をアプリケーションに渡すことができます。サポートされている各イベント（エージェント、コンタクト、ユーザー）に応じて、アプリケーションは個々の顧客に対応できるようになり、アプリケーション内の関連する画面や操作に直接移動できるため、エージェントがリクエストを検索、検索、処理するのにかかる時間を短縮できます。エージェントが同時問い合わせを処理する場合、エージェントワークスペースではこのコンテキストを維持し、アプリケーション内の顧客ごとに適切な情報を表示できるため、エージェントはパーソナライズされたエクスペリエンスを提供でき、手作業によるミスを防ぐことができます。 エージェントはどのようにサードパーティーアプリケーションを利用できるのか? 使用するサードパーティアプリケーションに関係なく、エージェントがそれらを利用して顧客との対話を強化する方法はさまざまです。エージェントは Amazon Connect エージェントワークスペース内からこれらのアプリケーションに直接移動できるため、顧客のニーズに対応するために必要なツールをいつでもすぐに使用できます。エージェントは、最も頻繁に使用するアプリケーションをエージェントワークスペースにピン留めすることもできます。簡単にアクセスできるアプリケーションを含むようにワークスペースをカスタマイズすることで、エージェントはよりパーソナライズされた、効果的な作業環境を構築できます。 ナビゲーションやパーソナライゼーションだけでなく、サードパーティアプリケーションを ステップバイステップガイド に直接埋め込んで、コンタクトフローイベントやエージェントアクションに動的に対応することもできます。これにより、管理者は、事前定義された条件に基づいて、顧客とのやり取りの適切なタイミングで適切なアプリケーションを提示できるようになります。たとえば、ステップバイステップガイドを表示したく、サードパーティアプリケーションの既存のツールも含める場合は、 ノーコード UI ビルダー 内の「アプリケーション」コンポーネントを使用できます。 サードパーティーアプリケーションの使用例 サードパーティアプリケーションを使用することで、組織に最も影響を与える分野に集中できます。エージェントが日常的に使用する主要なアプリケーションをエージェントワークスペースに統合することで、カスタムワークスペースを構築して管理しなくても業務を合理化できます。これにより、開発者は保守ではなくイノベーションに集中できるようになります。 アプリケーションの例を考えてみましょう。顧客が注文についてエージェントに連絡したとします。既存の注文追跡アプリケーションをエージェントワークスペースに直接統合すると、エージェントは別のウィンドウで開かずに注文の状況を即座に確認できます。この統合により、エージェントはワークスペースを離れることなく顧客の注文を効率的に管理できます。さらに、Amazon Connect SDK を利用することで、このプロセスをさらに改善できます。SDK を使用すると、エージェントが対応している連絡先に関連するイベントにアプリケーションが自動的に反応できるようになります。たとえば、連絡先属性から取得した注文番号などの特定のパラメーターを使用して注文の検索を開始できるため、エージェントが実行する必要のあるクリック数を減らすことができます。このアプローチは、エージェントが顧客をよりよく支援できるようになるだけでなく、全体的な顧客体験を向上させ、満足度の向上にも貢献します。ボイスメールアプリケーション、メモアプリケーション、企業ポータル、エージェント用の指標ダッシュボードなど、他の例も検討してください。 推奨事項とベストプラクティス エージェントワークスペースでサードパーティアプリケーションのサポートを有効にする場合は、アプリケーションの適切なセキュリティ対策、対応可能なイベント、アクセシビリティ、一貫したテーマの適用を検討して、エージェントにシームレスなエクスペリエンスを提供するようにしてください。 推奨事項とベストプラクティス を確認して、詳細をご覧ください。 お客様の声 「私たちのクライアントである Arbonne は、Amazon Connect とエージェントワークスペースでエージェントの生産性とカスタマーエクスペリエンスを向上させたいと考えていました。」と、大手 AI コンサルティングおよび AWS と Salesforce の　ISV パートナーである Neuraflash のコンタクトセンタービジネスユニット担当 SVP である John Heater は語ります。「組み込みのサードパーティアプリケーション統合機能により、機密性の高いディスカッション中に通話録音を一時停止したり、エージェントが Arbonne の製品カタログに簡単にアクセスして効率的なケース管理を行ったり、顧客のインシデント履歴を表示して個別のサポートを行ったりするなど、個別のユースケースに対応できました。さらに、Amazon Connect のケース、顧客プロフィール、ステップバイステップガイドのおかげで、コンタクトセンターのエージェントはより良く、より効率的なサービスを提供できるようになりました。」 結論 Amazon Connect エージェントワークスペースのサードパーティアプリケーションサポートにより、エージェントが日常的に使用するツールを統合すると同時に、問い合わせのコンテキストデータでツールを強化することで、エージェントのエクスペリエンスを向上させることができます。Amazon Connect とアプリケーションの間で顧客データがシームレスに渡されるため、エージェントは顧客の話を聞いたり支援したりする時間を増やすことができます。顧客に同じことを繰り返してもらうことなく、よりパーソナライズされた情報に基づいたサービスを提供できます。アプリケーションとの緊密な統合により、既存の投資を活用して既存の技術スタックを基盤としながら、お客様固有のビジネス要件に合わせてコンタクトフローをさらにカスタマイズできます。 リソース Amazon Connect で初めてのサードパーティアプリケーションの構築を始めたいですか? この サードパーティアプリケーションワークショップ を実施して、Amazon Connect のイベントと連動してパーソナライズされた、動的で状況に応じたエクスペリエンスを提供するサンプルアプリケーションを構築、デプロイ、テストする方法について詳しく学んでください。 どのアプリが市場で提供されていて、どのアプリが AWS によって精査されているかを知りたいですか? さまざまなサードパーティーインテグレーションを構築してサポートするには、パートナーが不可欠です。このローンチの一環として、 Amazon Connect Service Ready のソフトウェアパートナーである Joulica 、 Operata 、 SequenceShift 、および TechSee は、統合機能があらかじめ組み込まれています。さらに、 Neuraflash や Consilium などのいくつかの Amazon Connect サービスデリバリーパートナーもサードパーティ統合を提供しています。これらのパートナーとその統合の詳細については、 Amazon Connect パートナーのページ をご覧ください。 エージェントワークスペースのサードパーティアプリケーションについて詳しく知りたいですか? サードパーティアプリケーションの導入方法については、 Amazon Connect 管理者ガイド で詳細をご覧ください。 アプリケーションを Amazon Connect SDK と統合したいと考えている開発者ですか? アプリケーション内のコンタクトセンターで発生したイベントにアクセスして連携する方法については、 エージェントワークスペース開発者ガイド で詳細をご覧ください。 筆者紹介 Freddy Jimenez (代名詞 he/him) は、イリノイ州シカゴを拠点とする Amazon Connect を専門とする AWS のシニアソリューションアーキテクトです。さまざまな業界のお客様と協力して、Amazon Connect を活用してカスタマーエクスペリエンスに変革をもたらしています。彼はコンタクトセンターの技術分野の深い専門知識を持ち、運用や専門サービスの経験も豊富です。フレディは、走ったり、旅行を通じて新しい目的地を見つけたり、ミニチュアゴールデンドゥードルとのひとときを大切にすることに喜びを見出しています。 Alex Schrameyer (代名詞 he/him) は、インディアナ州インディアナポリスに拠点を置く AWS のエージェントエクスペリエンス担当ワールドワイドソリューションアーキテクトリードです。卓越したエージェント体験こそが優れたカスタマーサービスの基礎であると考え、エージェントが優れた能力を発揮し、お客様に喜んでもらえる環境を作ることに重点を置いています。アレックスは世界中を旅するのが好きで、あなたの地元の野球場やテーマパークでも見かけるかもしれません。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

マルチプレイヤーオンラインバトルアリーナ（MOBA）ゲーム “Predecessor” の開発に取り組む Omeda Studios の開発者の献身さは、いくら強調してもしすぎることはありません。スタジオが正式に設立されたのは 2020 年ですが、そのコアチームは 2018 年からこのゲームを開発してきました。ファンによって、ファンのために作られた “Predecessor” は、2016 年から 2018 年にかけて Epic Games が開発した MOBA ゲーム “Paragon” の遺産から生まれました。”Paragon” の終了後、 Epic Games は Unreal Engine の無料使用のために “Paragon” のすべてのアセットを自由に使用できるように公開しました。Omeda は 2021 年末に PC で “Predecessor” の最初のビルドを有料早期アクセスとしてリリースし、その後 2022 年 4 月に無料オンラインテストとしてリリースしました。16 ヶ月間ライブゲームを運営した後、 Omeda Studios は Amazon Web Services (AWS) の専用ゲームサーバー管理サービスである Amazon GameLift を使用して Pragma にバックエンドを移行しました。この変更は、最新リリースの前に実装され、クロスプラットフォームで無料プレイを可能にしました。 Omeda Studios のライブプロダクションおよびゲームオペレーションのシニアマネージャーである Jon Sredl 氏は次のように述べています。「AWS はゲーム業界のゴールドスタンダードで、 GameLift を選択するのは簡単な決断でした。私たちが必要とするサーバータイプを必要な地域で提供してくれますし、プレイヤーの利益を最大化するキャパシティも備えています。プレイヤーにとって最大の変化は、社内で構築した Pragma ベースのマッチメーカーを GameLift と接続できるようになったことで、マッチメイキング体験の品質が向上したことです。GameLift のサーバーオーケストレーションに独自のマッチメーカーを柔軟に導入できるようになり、プレイヤーに高品質な体験を提供出来るようになりました。」 ブラックボックスからクリアボックスへ Omeda Studios は当初から “Predecessor” の試合をホストするために AWS インスタンスを使用していましたが、サーバーの管理やメンテナンスを全面的に請け負う外部のゲームサーバサービスを利用していました。チームはゲームのクロスプラットフォーム展開の準備をしながら、小規模ながら熱心なプレイヤーを維持することに初期の開発努力を集中させました。そして、2023 年後半に、ゲームのバックエンドをより制御するために GameLift と Pragma を採用しました。以前のゲームサーバーホスティングサービスとは異なり、このアプローチにより、Omeda Studios は比較的小規模なチームでも、ゲームの最新リリースを加速し、開発者に明確なオブザーバビリティを提供できるようになりました。 Sredl 氏は次のように述べています。「オブザーバビリティは私たちにとって大きなチャレンジでした。なぜなら、以前のゲームサーバーホスティングソリューションはブラックボックスに近かったのですが、GameLift はより細かい制御が可能なクリアボックスを提供してくれます。また、開発者にどれだけうまく機能しているかを見せることができます。そして、このようなタイトなスケジュールでも GameLift を採用することで機能を実現できると分かっていました。」 GameLift と Pragma の連携 これまでで最大規模の “Predecessor” ローンチを前に、Omeda Studios はソリューションインテグレーターであり AWS パートナーでもある Code Wizards に、GameLift と Pragma の接続を構築するよう依頼しました。Omeda チームと協力して、Code Wizards はシステム同士が通信できるようにするフレームワークを設計し実装しました。その際、Amazon GameLift のエンジニアリングチームは、リアルタイムで Slack のやりとりに参加し、両チームと協力して課題に対するタイムリーな解決策を見出すなど、迅速かつタイトなスケジュールへの対応を支援しました。 今回の実装は “Predecessor” に向けにカスタマイズしたものでしたが、わずか数ヶ月でライブゲームを新しいバックエンドとゲームサーバーオーケストレーションに移行したい開発者も、同様に GameLift と Pragma を活用し、 GameLift エンジニアリングチームと CodeWizards 開発チームの専門知識を利用することで、同様の結果を達成できる可能性があります。 「Code Wizards は事実上、私たちのコア開発チームの一部であり、AWS チームは私たちの成功に非常に重要な役割を果たしました。素晴らしいコラボレーションでした。このパートをこれほど短期間で完了できたことは、Pragma 移行の他の部分に取り組むために非常に重要でした。」と Sredl 氏は述べています。 現在、Pragma は “Predecessor” のバックエンドのマッチメイキングを管理しており、マッチメイキングはカスタムコードを通じて処理されています。プレイヤーがグループにマッチングされると、GameLift に通知が送られ、指定されたリージョンでサーバーが起動します。これにより、マッチングされたグループの各プレイヤーが同じ高品質な体験を楽しめることが保証されます。“Predecessor” はオンラインでのみ利用可能であり、練習モードを含むすべてのゲームプレイが GameLift を通じてルーティングされます。 “Predecessor” のマイルストーンを追跡 2022 年 4 月の Epic Games Store とオンラインゲームプラットフォーム Steam での無料オンラインテストの成功を受けて、スタジオは 2022年 12月 に PC 向けの無料 “Predecessor” アーリーアクセスを開始しました。2023 年末には、 PlayStation 4 (PS4) と PlayStation 5 (PS5) 向けにクローズドベータ版として提供されるようになりました。そして、ゲームの新しいバックエンドは 2024 年 3 月 5 日にデビューしました。 2024 年 3 月 28 日、”Predecessor” は無料プレイ (F2P) モデルで公開され、Amazon GameLift と Pragma を活用することで、Epic Games Store、Steam、PS4、PS5、Xbox Series X、Xbox Series S におけるグローバルなクロスプラットフォームプレイに対応しました。プレイヤーは依然として、ユニークなゲーム内アイテムや通貨を含むアーリーアクセスバンドルを購入できますが、ゲーム自体は無料でプレイできます。最新のリリースによってゲームがより多くのプレイヤーからアクセスしやすくなったため、チームはトラフィックが急増しても、プレイヤーに高品質な体験を確実に提供できるようにする必要がありました。 「私たちが最初に実現したいのは、誰もが良い時間を過ごしているということです。そして、私たちはその基準を間違いなく大きく超えました。わずか数ヶ月の間に、このサービスのライブ移行を実現するために、社内の開発チーム全体で前例のない努力が行われました。そして、GameLift と Pragma のコンポーネントはすべてシームレスに機能しています。」と Sredl 氏は共有してくれました。「プレイヤーの人口がこれまでで最大規模になりましたが、まだまだ成長し続けているのです。これは非常にエキサイティングです。私たちはこの勢いを維持することを目指しており、多くの大きな新機能やゲームモードを開発中です。」 負荷テストの重要性 “Paragon” との関連性から、“Predecessor” は発足以来、熱心なファンからの強い注目を集めてきました。そのため、このゲームは常に大規模のプレイヤーをサポートする必要がありました。2021 年の初回オンラインテストでは、週末で 68,000 人のプレイヤーが 1,100 万分間のプレイを記録し、その後の新リリースごとに需要は増加し続けています。ゲームの無料プレイ (F2P) のリリースに先立ち、チームは需要のピーク時でもプレイヤーが最適な体験を楽しめるよう、広範な負荷テストを実施しました。スタジオは Pragma で最大 200,000 人の同時接続プレイヤー、GameLift では最大 500,000 人のプレイヤーを想定して負荷テストを行いました。 「私たちは過去 2 ヶ月間ほぼ継続的に負荷テストを実施してきました。テストを実行し、結果を分析し、必要に応じてサービスに調整や変更を加え、次のテストの準備をするというサイクルを繰り返してきました。しかし、バックエンドとサーバー管理システム全体を入れ替えてから、過去最大のプレイヤーを対象に無料プレイを開始するまでの期間が短かったのです。最高品質のシステムを構築するだけでなく、それを徹底的にテストすることが不可欠でした。」と Sredl 氏は述べました。「ありがたいことに、ローンチはスムーズに進み、バックエンドは非常に安定しています。負荷テストは極めて重要で、事前に問題を発見し対処するのに役立ちました。」 “Predecessor” はグローバルにプレイヤーが存在しています。現在、4 つの主要な AWS リージョン（北米に 2 つ、ヨーロッパに 1 つ、アジア太平洋に 1 つ）で稼働しています。Omeda チームはより多くのリージョンにゲームを簡単に拡張でき、健全なマッチメイキングとローカライゼーションによって、プレイヤーに高品質な体験を提供することができます。同時に、GameLift のオートスケーリング機能により、ゲームの無料プレイモードの人気が高まるにつれて増加するプレイヤーベースに合わせて、より簡単にスケールが可能になりました。 将来のリリースに備えて Omeda Studios が “Predecessor” のバックエンドとシステムのコードベースの両方を所有するようになったことで、ファンのために新機能をより迅速に開発し実装できるようになりました。チームは、既存の製品にコードを組み込む方法を心配することなく、すぐにアイデアをテストできます。コミュニティ主導の企業として、この新たに獲得した俊敏性は “Predecessor” の究極のビジョンを実現する上で極めて重要です。 「長期的には、私たちはただ最高に面白く、魅力的で、楽しい体験を作りたいだけなので、迅速にプロトタイプを作成できるようになったことは非常に大きな意味を持ちます。“Predecessor” は “Paragon” の夢と理想に基づいて構築されたゲームであり、現在の目標は、プレイヤー体験と品質の基準をどこまで高められるかを探ることです」と Sredl 氏は述べました。「また、AWS のようなパートナーとさらに協力し、独立系デベロッパーとしてどのように世界クラスの AAA ゲームを構築できるかも検討しています。現在の立ち位置と将来に向けて構築する機会に、これ以上ない喜びを感じています。」 最後にアドバイス 自社のバックエンド開発している開発者に対して、Sredl 氏はまずプレイヤー体験を考慮し、そこから逆算してインフラストラクチャを決定することを推奨しています。彼は次のように結論づけました。「プレイヤーが気にするのは、ゲームにフォーカスできるかどうかです。そのためには、開発の観点から適切なレイテンシーとサーバーパフォーマンスが必要となります。スケーラビリティはあらゆる段階で重要であり、常に高い品質基準を設定することも同様です。私たちにとって、それは GameLift を使用することを意味しました。私たちは AWS の品質を知っており、長期にわたって AWS のマシンで運用してきたので、パートナーシップを拡大することは本当に理にかなっていました。」 Amazon GameLift のページ では、このテクノロジーと、その予測的なサーバースケーリング、エンタープライズ級のセキュリティ、マッチメイキングが、開発者に世界で最も要求の厳しいゲームの構築とスケーリングを可能にし、発売日の不確実性を取り除く方法について詳しく紹介しています。 この記事は Omeda Studios swaps out ‘Predecessor’ backend in less than five months using Amazon GameLift and Pragma を翻訳したものです。翻訳はソリューションアーキテクトの山本が担当しました。

6月20日より、Rust 開発者は、 AWS CodeArtifact 上にライブラリ (Rust の クレート ) を保存してアクセスできるようになりました。 開発を加速するために、今日のソフトウェア開発は事前に記述されたコードパッケージに大きく依存しています。1 つのアプリケーションにつき数百にも上ることがあるこれらのパッケージは、一般的なプログラミングタスクに使用でき、社内で作成するか、外部ソースから入手することができます。これらのパッケージは開発をスピードアップするのに大いに役立ちますが、その使用は組織にとって法的な懸念とセキュリティ上の懸念という2つの主な課題をもたらします。 法的な面では、組織はこれらのサードパーティ製パッケージと互換性のあるライセンスを保有していること、および知的財産権を侵害していないことを確認する必要があります。もう 1 つのリスクであるセキュリティの面では、パッケージの脆弱性が悪用されてアプリケーションが侵害される可能性があります。既知の戦術であるサプライチェーン攻撃では、一般的なオープンソースプロジェクトに脆弱性が注入されます。 このような課題に対処するために、組織はプライベートパッケージリポジトリを設定できます。これらのリポジトリには、セキュリティチームと法務チームによって精査された事前承認済みパッケージが保存されるため、法的またはセキュリティ上のリスクが軽減されます。ここで CodeArtifact を活用します。 AWS CodeArtifact は、アプリケーション開発で使用されるソフトウェアパッケージを安全に保存、公開、共有するために設計された完全マネージド型のアーティファクトリポジトリサービスです。 npm 、 PyPI 、 Maven 、 NuGet 、 SwiftPM 、 Rubygem などの一般的なパッケージマネージャーと形式がサポートされるので、既存の開発ワークフローに簡単に統合できます。アクセスを制御することでセキュリティを強化し、チーム間のコラボレーションを促進することができます。CodeArtifact では、 AWS Identity and Access Management (IAM) および継続的インテグレーションと継続的デプロイ (CI/CD) ツールとの統合によって一貫した安全で効率的なソフトウェア開発ライフサイクルを維持できます。 Rust &nbsp;は、 Stack Overflow の開発者向け年次アンケート において、「最も望まれるプログラミング言語」としてチャートのトップにランクインし、80% の開発者が翌年もこの言語を再び使用したいと回答しています。Rust の人気の高まりは、C++ などのシステム言語のパフォーマンスおよびメモリの安全性と信頼性の高い同時実行コードの記述を容易にする機能を組み合わせることができることに起因します。さらに、豊富なエコシステムとコミュニティコラボレーションに重点を置く Rust は、高性能システムやアプリケーションを開発する開発者にとって魅力的な選択肢です。 Rust の開発者は、公式のパッケージマネージャーである Cargo を利用してパッケージの依存関係を管理しています。Cargo を使用すると、事前に記述されたクレート (ライブラリ) の検索、ダウンロード、プロジェクトへの統合のプロセスが簡単になります。手動での依存関係管理が不要になり、時間を節約できるだけでなく、互換性とセキュリティも保証されます。Cargo の堅牢な依存関係解決システムは、異なるクレートバージョン間の潜在的な競合に対処します。また、多くのクレートは厳選されたレジストリからのものであるため、開発者にとって、コードの品質と安全性に関する懸念が大きく削減されます。このような効率性と信頼性へのフォーカスにより、Cargo は Rust アプリケーションを構築するための不可欠なツールとなっています。 クレート用の CodeArtifact リポジトリを作成する このデモでは、 AWS コマンドラインインターフェイス (AWS CLI) と AWS マネジメントコンソール を使用して 2 つのリポジトリを作成します。最初のリポジトリは、公式の crates.io リポジトリからパブリックパッケージをダウンロードするように設定します。2 番目のリポジトリは、最初のリポジトリからのみパッケージをダウンロードするように設定します。このデュアルリポジトリ構成は、リポジトリと外部接続を管理するための推奨方法です。 外部接続の管理に関する CodeArtifact のドキュメント を参照してください。ドキュメントからの引用を紹介します。 「特定のパブリックリポジトリへの外部接続については、ドメインごとに 1 つのリポジトリを用意することをお勧めします。他のリポジトリをパブリックリポジトリに接続するには、外部接続のリポジトリをアップストリームとして追加します」。 次の図は、このセットアップを示しています。 ドメインとリポジトリは、コマンドラインまたはコンソールから作成できます。ここでは、コマンドラインを選択します。シェルターミナルで次のように入力します。 CODEARTIFACT_DOMAIN=stormacq-test # 内部向けのリポジトリ crates-io-store を作成します aws codeartifact create-repository \ --domain $CODEARTIFACT_DOMAIN \ --repository crates-io-store # 内部向けリポジトリ crates-io-store をパブリックの crates-io に関連付けます aws codeartifact associate-external-connection \ --domain $CODEARTIFACT_DOMAIN \ --repository crates-io-store \ --external-connection public:crates-io # 2 番目の内部向けリポジトリ cargo-repo を作成します # 先に作成したアップストリームの crates-io-store に接続します aws codeartifact create-repository \ --domain $CODEARTIFACT_DOMAIN \ --repository cargo-repo \ --upstreams '{"repositoryName":"crates-io-store"}' 次に、作成した内部リポジトリ ( cargo-repo ) からローカルマシンでクレートを取得します。 パブリックの crates.io ではなく、内部リポジトリからライブラリを取得するように cargo を設定します。そのためには、 config.toml ファイルを作成して CodeArtifact の内部リポジトリをポイントします。 # 最初にリポジトリの URI を取得します REPO_ENDPOINT=$(aws codeartifact get-repository-endpoint \ --domain $CODEARTIFACT_DOMAIN \ --repository cargo-repo \ --format cargo \ --output text) # この段階では、REPO_ENDPOINT は https://stormacq-test-012345678912.d.codeartifact.us-west-2.amazonaws.com/cargo/cargo-repo/ です # 次に、Cargo 設定ファイルを作成します cat &lt;&lt; EOF &gt; ~/.cargo/config.toml [registries.cargo-repo] index = "sparse+$REPO_ENDPOINT" credential-provider = "cargo:token-from-stdout aws codeartifact get-authorization-token --domain $CODEARTIFACT_DOMAIN --query authorizationToken --output text" [registry] default = "cargo-repo" [source.crates-io] replace-with = "cargo-repo" EOF 設定ファイルを作成すると、2 つの環境変数が置き換えられることに注意してください。 cargo の設定では環境変数がサポートされません。 これ以降、このマシンで cargo を呼び出してクレートを追加するたびに、 cargo は内部 cargo-repo リポジトリと通信するための承認トークンを CodeArtifact から取得します。使用したコマンドでのパッケージの読み取り / 公開のアクセス許可に加えて、 get-authorization-token CodeArtifact API を呼び出す IAM 権限 が必要です。このセットアップを継続的インテグレーション (CI) パイプラインのビルドマシンから実行する場合、そのための適切な権限がビルドマシンに必要です。 このセットアップをテストして、ローカルプロジェクトにクレートを追加できるようになりました。 $ cargo add regex Updating `codeartifact` index Adding regex v1.10.4 to dependencies Features: + perf + perf-backtrack + perf-cache + perf-dfa + perf-inline + perf-literal + perf-onepass + std + unicode + unicode-age + unicode-bool + unicode-case + unicode-gencat + unicode-perl + unicode-script + unicode-segment - logging - pattern - perf-dfa-full - unstable - use_std Updating `cargo-repo` index # プロジェクトをビルドして、クレートのダウンロードをトリガーします。 $ cargo build Downloaded memchr v2.7.2 (registry `cargo-repo`) Downloaded regex-syntax v0.8.3 (registry `cargo-repo`) Downloaded regex v1.10.4 (registry `cargo-repo`) Downloaded aho-corasick v1.1.3 (registry `cargo-repo`) Downloaded regex-automata v0.4.6 (registry `cargo-repo`) Downloaded 5 crates (1.5 MB) in 1.99s Compiling memchr v2.7.2 (registry `cargo-repo`) Compiling regex-syntax v0.8.3 (registry `cargo-repo`) Compiling aho-corasick v1.1.3 (registry `cargo-repo`) Compiling regex-automata v0.4.6 (registry `cargo-repo`) Compiling regex v1.10.4 (registry `cargo-repo`) Compiling hello_world v0.1.0 (/home/ec2-user/hello_world) Finished `dev` profile [unoptimized + debuginfo] target(s) in 16.60s CodeArtifact がアップストリームのパブリックリポジトリからクレートとその依存関係をダウンロードしたことを確認します。CodeArtifact コンソールに接続し、作成したいずれかのリポジトリで利用可能なパッケージのリストを確認します。この段階では、2 つのリポジトリのパッケージリストは同じであるはずです。 プライベートパッケージをリポジトリに公開する アップストリームリンクが意図した通りに機能することが確認できたので、プライベートパッケージを cargo-repo リポジトリに公開して、組織内の他のチームが利用できるようにします。 通常通り、標準の Rust ツール cargo を使用します。その前に、プロジェクトファイルを git リポジトリに追加してコミットします。 $ git add . &amp;&amp; git commit -m "initial commit" 5 files changed, 1855 insertions(+) create mode 100644 .gitignore create mode 100644 Cargo.lock create mode 100644 Cargo.toml create mode 100644 commands.sh create mode 100644 src/main.rs $ cargo publish Updating `codeartifact` index Packaging hello_world v0.1.0 (/home/ec2-user/hello_world) Updating crates.io index Updating `codeartifact` index Verifying hello_world v0.1.0 (/home/ec2-user/hello_world) Compiling libc v0.2.155 ... (redacted for brevity) .... Compiling hello_world v0.1.0 (/home/ec2-user/hello_world/target/package/hello_world-0.1.0) Finished `dev` profile [unoptimized + debuginfo] target(s) in 1m 03s Packaged 5 files, 44.1KiB (11.5KiB compressed) Uploading hello_world v0.1.0 (/home/ec2-user/hello_world) Uploaded hello_world v0.1.0 to registry `cargo-repo` note: waiting for `hello_world v0.1.0` to be available at registry `cargo-repo`. You may press ctrl-c to skip waiting; the crate should be available shortly. Published hello_world v0.1.0 at registry `cargo-repo` 最後に、コンソールを使用して hello_world クレートが cargo-repo で使用できるようになったことを確認します。 料金と利用可能なリージョン 現在、Rust ライブラリは、 CodeArtifact を利用できる 13 の AWS リージョン に保存できます。Rust パッケージの追加料金は発生しません。課金対象となるのは、ストレージ (月あたりの GB で測定)、リクエスト数、インターネットまたは他の AWS リージョンに転送されるデータの 3 つです。同じリージョンの AWS サービスへのデータ転送に対しては料金が発生しないので、 Amazon Elastic Compute Cloud (Amazon EC2) &nbsp;や AWS CodeBuild などで継続的インテグレーションと継続的デリバリー (CI/CD) のジョブを実行しても CodeArtifact のデータ転送の料金は発生しません。いつものように、詳細については 料金ページ をご確認ください。 Rust アプリケーションを構築してプライベートクレートを CodeArtifact にアップロードしてみてください。 — seb 原文は こちら です。