みなさんこんにちは。プリンシパルソリューションズアーキテクトの梶本（かじもと）です。9月11日にAWSが主催する自動車業界向けイベント「AWS Autotech Forum 2024」を開催しました。AWS Japanでは、自動車業界の皆様にクラウドを活用してビジネスを加速して頂くことを目指し、 2018 年より事例や最新技術の活用方法等をご紹介する本イベント「AWS Autotech Forum」 を開催して参りました。今回で7回目となる本イベントは9月11日に目黒にあるAWS Japanオフィスにおいて約100名の方にご参加いただき、また収録内容を9月19日にはWebinar形式で昨年同様オンライン配信も行い1000名以上の多くの方にご登録頂きました。 SDV (Software Defined Vehicle) を中核に、クラウドを活用して車載ソフトウェアを効率的に開発するIn Carの取組み、自動車購入後も様々な顧客価値を利用者に提供するOut Carの取組みがデータを中核に融合しつつある今日、自動車産業が人々に提供する価値が大きくなっていることを私も感じています。今年の本イベントでは、自動車産業の変化を第一線で創造しているお客様を代表して、ソニー・ホンダモビリティ株式会社の高倉様、名古屋大学の高田教授様、トヨタ自動車株式会社の佐々木様、本田技研工業株式会社の野川様にご登壇頂きました。 オープニング –竹川 寿也　アマゾン ウェブ サービス　シニア事業開発マネージャー オープニングでは、自動車業界全体で加速するIn Car/Out Car全方位のデジタル化と言う今回のAutotech Forumのテーマについて、SDV技術により人間中心に変わった車室空間や、自動車が後から進化する動き、データを駆使した新たな事業を創造する成長トレンドについて触れ、Forumの意図を説明しました。 AFEELAが目指すMobility Experienceのご紹介 –高倉　大樹 様　ソニー・ホンダモビリティ株式会社　ネットワークサービス開発部　General Manager -柄澤　優子　アマゾンウェブサービス　プリンシパルセールス 本セッションでは、ソニー・ホンダモビリティのモビリティブランドであるAFEELAのプロトタイプ車両(AFEELA Prototype 2024)をAmazonのシアトル本社前のThe Spheres広場に展示いただき、現地からAFEELAが目指す顧客体験について、生中継でご説明いただきました。モビリティがユーザーを認識し、ドアが開く様子や、誕生日やドライビングスコアなど、あたかもモビリティがユーザーの友だちであるかのごとくメッセージを提示してくれる様子をデモしていただけました。またSDVを中核に常に進化し続けるサービスを提供することで、ソニー・ホンダモビリティ様では、お客様との接点を長く深く維持し続けるバリューチェーンの構築についてもご説明いただきました。また、エンタテインメントや物流など幅広いサービスで、異業種のパートナー様とも連携したオープンなエコシステムの形成も紹介されました。 このAFEELAの構想をインフラストラクチャとして支えるAWSクラウドは、自動車のデバイス認証やデータ収集で AWS IoT Core を提供、アプリケーションがデータやイベントの最新情報と同期を取って動作する機能として、 AWS AppSync を提供しており、これらを中核にAFEELAでは、ユーザー、デバイス、スマートフォンなどの認証、連携を実装しています。またデータレイク、分析にも様々なAWSサービスをご利用いただいており、今後もAWSはソニー・ホンダモビリティ様の新たなモビリティ体験の提供をご支援して参ります。 オープンSDVとクラウドサービスへの期待 –高田　広章 様　名古屋大学　教授 名古屋大学の高田先生は、日本におけるコンピュータ科学の重鎮のお一人であり、特に自動車産業に関する造詣も深く、自動車技術会や車載組込みシステムフォーラムなど多くの自動車関連団体の重職を務められています。本セッションでは急速に進む自動車のデジタル化（モビリティDX）やテスラ・中国OEMに代表される新興OEMの急速な進歩と言う大きなビジネス・技術環境の変化に対し、SDV技術を中核に日本の自動車産業をさらに成長路線に導くことを企図した経産省様・国交省様のモビリティDX戦略の意図と、高田先生がリードをされるオープンSDVイニチアチブの狙いについてご説明いただきました。 高田先生は、多種多様なハードウェアとソフトウェアの組合せで構成される自動車においては、SDVの考え方でソフトウェアとハードウェアの分離を行い、相互の進化を受け入れやすくすることが重要であることであることを説明され、次にSDVの進化をOTAによるアップデートが可能なステップ０、OTAにより機能向上し継続的に収益が上げられるステップ１、そしてサードパーティが開発したソフトウェアをインストールすることができる自動車になったステップ２と３段階の進化仮説に触れ、このステップ３を「オープンSDV」と名付けられました。オープンSDVの世界が来るためには安全性に関する取扱いが可能かと言った大きな課題はありますが、移動と言う価値など、自動車はプラットフォームとしてサードパーティに取り魅力的なプラットフォームではないかと高田先生は説かれました。その上で、サードパーティがソフトウェアを作りやすくするためにはビークルAPIの標準化が重要となると投げかけられました。そしてモビリティDX戦略でもビークルAPIの標準化に触れられており、現在COVESAのVSSなど海外でビークルAPIの標準化の動きがあることについても危機感を持たれておられます。そして名古屋大学が中核となりオープンSDVイニチアチブを立ち上げ、オープンなビークルAPI「Open SDV API」を策定していく方針を述べられました。 CXを中核にした「モビリティカンパニー」への取り組み –佐々木　英彦 様　トヨタ自動車株式会社　デジタル変革推進室 CX CENTER担当主査 担当部長 佐々木様は、トヨタ自動車株式会社様の中で、広報、デジタルマーケティングを経てお客様接点（CX）の変革を手掛けられてきています。本セッションでは、トヨタ様が提供されている様々なサービスにおいて、これまでは個別に定義されていたお客様ID体系を、NPS®（ネット・プロモーター：スコア）を指標としてTOYOTAアカウントに統合されたCXの変革についてご紹介いただきました。この変革により、お客様のペルソナが推定できるようになり、また、どの顧客接点がお客様に影響を与えているかも具体的に把握できるようになったとのことです。さらに、CX基盤を通じたお客様からのフィードバックから、車両開発における機能やデザインなど最適な商品開発や改良にも活用が始まったそうです。特にサービスからのデータ分析から車両設計へのフィードバックについては、AWSもデータを中心にした Big Loop構想をSDVで発信 していたため、その構想が具現化されている事例として非常に印象に残りました。今後はトヨタブランドを中核に、サービス、トヨタ車の顧客接点をさらにつなぎ、お客様中心の変革を実現し、モビリティカンパニーとしてのトヨタブランドを目指されると締めくくられました。 佐々木様のご講演では、CXお取組み概要を広く言及いただき、CX基盤を構築にあたりAWSの各種サービスを使っていただいているとのことでしたので、AWSとしても、今後も一層、トヨタ様のCX基盤の充実に協力して参ります。 SDMが導くHonda第二の創業期 –野川　忠文 様　本田技研工業株式会社　ソフトウェアデファインドモビリティ開発統括部 コネクテッドソリューション開発部 部長 ホンダ様は、コネクテッドサービスを以前から手掛けられており、多くの世界初の取り組みを実施されてこられました。そしてコネクテッドサービスは情報配信から車の機能の一部に昇華するとのビジョンを示されました。次に野川様がAWSのイベントであるre:invent 2023にご登壇いただいた時の内容を振り返り、ソフトウェアディファインドモビリティ(SDM)を実現するために、In-CarとOut-Car一体に一歩踏み込んだ「クロスドメイン」連携を行ったことや爆速開発のために、縦割りからクロスドメイン開発のためのSDM Platformを企画、AWSの Amazon Simple Storage Service (Amazon S3) を使ったデータレイク、 AWS IoT Core や AWS IoT Fleetwise を使ったコネクテッド機能などで構築されるDigital Proving Ground (DPG)について紹介されました。また、組織も、従来の縦割り開発チームからDPG Steering Committeeの傘下に開発支援と開発推進の２グループに再編されたOne Teamによつ進められていると報告されました。そして表題にあるHonda第2の創業期として、電動化や知能化を軸としたソフトウェア領域での価値創造を目指すとの方針を示され、多様なモビリティを通じてHonda独自の価値を提供していくSDM世界の実現への意気込みを表明されました。 パネルディスカッション： In Car/Out Carのデジタル化が開くモビリティの未来 パネリスト –佐々木　英彦 様　トヨタ自動車株式会社　デジタル変革推進室 CX CENTER担当主査 担当部長 –野川　忠文 様　本田技研工業株式会社　ソフトウェアデファインドモビリティ開発統括部 コネクテッドソリューション開発部 部長 –梶本 一夫　アマゾン ウェブ サービス　プリンシパルソリューションズアーキテクト ファシリテータ –竹川 寿也　アマゾン ウェブ サービス　シニア事業開発マネージャー パネルディスカッションでは、トヨタ佐々木様、ホンダ野川様に加え、AWSからSDVの技術リプレゼンタティブである梶本も参加して、今回のフォーラムのテーマである「In Car/Out Carのデジタル化が開くモビリティの未来」について、司会の竹川により各パネラーからの考え方や取組みについて改めてディスカッションを行いました。 トヨタの佐々木様からは、CX基盤を通じてお客様起点でフィードバックが入ることが重要で、Out Carのサービス群からIn Carの車両設計が始まった今、「もうIn Car、Out Carと区別することをやめませんか」と、非常に印象に残るご提言をいただきました。 ホンダの野川様からは、DPGによる爆速化の取り組みそのものが、佐々木様のご講演を聞いて正しいと確信したことや、コネクテッドサービスを長年継続することで、お客様起点で車両設計やサービス企画することが大切であることを理解していること、組織としてIn Car、Out Car一体化していることに自信を持てたとのコメントもいただけました。 AWSの梶本からは、ご講演者のお二人の発言を受け、お客様起点で考えるとIn CarとOut Carは区別なく、連続している視点の大切さに感銘した旨を回答。またAWS自身が、多くのお客様に耳を傾け、共通した課題となっている部分でサービスとしてまとめてきた歴史をご紹介し、今後も自動車産業の成長に寄与できるように努力すると決意表明しました。 デモ展示 今回のAutotech Forumでは、会場に来られたお客様に、ミニブースにおけるデモ展示も行いました。デモ展示はAWSからだけではなく、自動車産業に貢献されているパートナー様にも出展いただきました。デモは以下の６点でした。 – Elektrobit Automotive GmbH様:　Power TrainにおけるEVバッテリープラントモデルの最適制御仮想ECU スポーツモードなど走行モードにより配下のMCU群に指示を行うSoC上で動作するASIL-B取得のEB corbos Linux環境、バッテリー制御MCUで動作するEB tresos環境をAWS上で動かし、バッテリープラントモデルの制御最適化の試行錯誤をAWS上で行なう事例をご展示いただきました。 – パナソニックオートモーティブシステムズ株式会社様:　IVI向け仮想ECU virtual SkipGen、Unified HMI IVI向け仮想ECU virtual SkipGenでは、Android Automotive OSやAGL (Automotive Grade Linux)、QNXを動かし、その上でのアプリケーション開発をIVI向けECUが無くてもAWS上だけで行うことができます。さらにパナソニックオートモーティブ様がオープンソース化を推進されているUnified HMIを用いることで、様々なOSで制御されている車室空間のあらゆるディスプレイを一つの仮想ディスプレイからのマッピングとして定義でき、同じ車室空間体験の異なる車種への展開や、複数のディスプレイに跨る同時表示などの実装がAWS上で確認することで簡単になると言う事例をご展示いただきました。 – Wipro Technologies Limited様:　自動運転アルゴリズム開発ツールチェーンでのシャドーモード実演 ADASの改良においては、現在のアルゴリズムと次のアルゴリズム候補の間で、認識性能が改善されるかを確認していくことが重要となります。Wipro様には、同じ認識対象のインプットに対し、現行アルゴリズムでの処理に加え、シャドーモードで新たなアルゴリズムを同時に動かし、両者での差分も提示できるSDVプラットフォームについてご展示いただきました。認識結果の差分をAWS上のCI/CD環境に自動で入力することで再学習が必要な映像シーンを自動選択し、アルゴリズムを改善することで認識率向上を図ると言う自動化について訴求いただきました。 – 富士ソフト株式会社様:　運転環境試験用車両シミュレータ 運転制御のアルゴリズム開発においては、制御アルゴリズム適用時の運転者の挙動が重要なインプットとなります。実際に運転者が着座し、緊急ブレーキを体験でき、その運転者の挙動を観測・分析できるドライビング・シミュレータを富士ソフト株式会社様にはご展示いただきました。また制動状況のシミュレーションもAWS上で生成することで、様々な制動パラメータによる走行データで実験できるようになっていることも訴求いただきました。 – AWS: ①　 AWS IoT FleetWise と Amazon QuickSight を用いた路面画像認識の教師データ作成と学習 AWS IoT FleetWise は、CANデータやADASで使われるカメラ映像を、予め設定した条件に合致した場合にクラウドにアップロードできます。このデモではカメラ映像から降雪やぬかるみなどの路面状況を認識するAIを学習により作成する時、同時にアップロードされるCANデータからタイヤのスリップ状況などを分析した実際の路面状況を教師データとして利用する使い方を訴求しました。 Amazon QuickSight を用いて、各シーンごとにご認識してしまったカメラ映像を抽出し、再学習対象のデータとすることで、路面認識AIの精度を上げることができるようになりました。 – AWS: ②　生成AIを活用した自然言語による自動運転学習用シーン検索 自動運転のアルゴリズム改善が必要になった時、膨大なカメラ映像の中から特定のシーンのみを再学習用のデータとして抽出したいことが、よくあります。このデモでは生成AIを用いて、自動的に分類されたカメラ映像のカットの中から、「交差点を人が渡っているシーン」など自然言語で指示することで、当該シーンが検索できることを訴求しました。生成AIは、今後、自動車業界においても多くの分野で利用されることが期待されています。 過去のイベント – AWS Autotech Forum 2023 – AWS Autotech Forum 2022 – AWS Autotech Forum 2021 – AWS Autotech Forum 2020 #1 – AWS Autotech Forum 2020 #2 – AWS Autotech Forum 2019 著者 梶本一夫（Kazuo Kajimoto） Principal Solutions Architect Amazon Web Services, Inc. 好きなOLP（ Our Leadership Principles ）はBias for Actionです。

みなさんこんにちは。プリンシパルソリューションズアーキテクトの梶本（かじもと）です。9月11日にAWSが主催する自動車業界向けイベント「AWS Autotech Forum 2024」を開催しました。AWS Japanでは、自動車業界の皆様にクラウドを活用してビジネスを加速して頂くことを目指し、 2018 年より事例や最新技術の活用方法等をご紹介する本イベント「AWS Autotech Forum」 を開催して参りました。今回で7回目となる本イベントは9月11日に目黒にあるAWS Japanオフィスにおいて約100名の方にご参加いただき、また収録内容を9月19日にはWebinar形式で昨年同様オンライン配信も行い1000名以上の多くの方にご登録頂きました。 SDV (Software Defined Vehicle) を中核に、クラウドを活用して車載ソフトウェアを効率的に開発するIn Carの取組み、自動車購入後も様々な顧客価値を利用者に提供するOut Carの取組みがデータを中核に融合しつつある今日、自動車産業が人々に提供する価値が大きくなっていることを私も感じています。今年の本イベントでは、自動車産業の変化を第一線で創造しているお客様を代表して、ソニー・ホンダモビリティ株式会社の高倉様、名古屋大学の高田教授様、トヨタ自動車株式会社の佐々木様、本田技研工業株式会社の野川様にご登壇頂きました。 オープニング –竹川 寿也　アマゾン ウェブ サービス　シニア事業開発マネージャー オープニングでは、自動車業界全体で加速するIn Car/Out Car全方位のデジタル化と言う今回のAutotech Forumのテーマについて、SDV技術により人間中心に変わった車室空間や、自動車が後から進化する動き、データを駆使した新たな事業を創造する成長トレンドについて触れ、Forumの意図を説明しました。 AFEELAが目指すMobility Experienceのご紹介 –高倉　大樹 様　ソニー・ホンダモビリティ株式会社　ネットワークサービス開発部　General Manager -柄澤　優子　アマゾンウェブサービス　プリンシパルセールス 本セッションでは、ソニー・ホンダモビリティのモビリティブランドであるAFEELAのプロトタイプ車両(AFEELA Prototype 2024)をAmazonのシアトル本社前のThe Spheres広場に展示いただき、現地からAFEELAが目指す顧客体験について、生中継でご説明いただきました。モビリティがユーザーを認識し、ドアが開く様子や、誕生日やドライビングスコアなど、あたかもモビリティがユーザーの友だちであるかのごとくメッセージを提示してくれる様子をデモしていただけました。またSDVを中核に常に進化し続けるサービスを提供することで、ソニー・ホンダモビリティ様では、お客様との接点を長く深く維持し続けるバリューチェーンの構築についてもご説明いただきました。また、エンタテインメントや物流など幅広いサービスで、異業種のパートナー様とも連携したオープンなエコシステムの形成も紹介されました。 このAFEELAの構想をインフラストラクチャとして支えるAWSクラウドは、自動車のデバイス認証やデータ収集で AWS IoT Core を提供、アプリケーションがデータやイベントの最新情報と同期を取って動作する機能として、 AWS AppSync を提供しており、これらを中核にAFEELAでは、ユーザー、デバイス、スマートフォンなどの認証、連携を実装しています。またデータレイク、分析にも様々なAWSサービスをご利用いただいており、今後もAWSはソニー・ホンダモビリティ様の新たなモビリティ体験の提供をご支援して参ります。 オープンSDVとクラウドサービスへの期待 –高田　広章 様　名古屋大学　教授 名古屋大学の高田先生は、日本におけるコンピュータ科学の重鎮のお一人であり、特に自動車産業に関する造詣も深く、自動車技術会や車載組込みシステムフォーラムなど多くの自動車関連団体の重職を務められています。本セッションでは急速に進む自動車のデジタル化（モビリティDX）やテスラ・中国OEMに代表される新興OEMの急速な進歩と言う大きなビジネス・技術環境の変化に対し、SDV技術を中核に日本の自動車産業をさらに成長路線に導くことを企図した経産省様・国交省様のモビリティDX戦略の意図と、高田先生がリードをされるオープンSDVイニチアチブの狙いについてご説明いただきました。 高田先生は、多種多様なハードウェアとソフトウェアの組合せで構成される自動車においては、SDVの考え方でソフトウェアとハードウェアの分離を行い、相互の進化を受け入れやすくすることが重要であることであることを説明され、次にSDVの進化をOTAによるアップデートが可能なステップ０、OTAにより機能向上し継続的に収益が上げられるステップ１、そしてサードパーティが開発したソフトウェアをインストールすることができる自動車になったステップ２と３段階の進化仮説に触れ、このステップ３を「オープンSDV」と名付けられました。オープンSDVの世界が来るためには安全性に関する取扱いが可能かと言った大きな課題はありますが、移動と言う価値など、自動車はプラットフォームとしてサードパーティに取り魅力的なプラットフォームではないかと高田先生は説かれました。その上で、サードパーティがソフトウェアを作りやすくするためにはビークルAPIの標準化が重要となると投げかけられました。そしてモビリティDX戦略でもビークルAPIの標準化に触れられており、現在COVESAのVSSなど海外でビークルAPIの標準化の動きがあることについても危機感を持たれておられます。そして名古屋大学が中核となりオープンSDVイニチアチブを立ち上げ、オープンなビークルAPI「Open SDV API」を策定していく方針を述べられました。 CXを中核にした「モビリティカンパニー」への取り組み –佐々木　英彦 様　トヨタ自動車株式会社　デジタル変革推進室 CX CENTER担当主査 担当部長 佐々木様は、トヨタ自動車株式会社様の中で、広報、デジタルマーケティングを経てお客様接点（CX）の変革を手掛けられてきています。本セッションでは、トヨタ様が提供されている様々なサービスにおいて、これまでは個別に定義されていたお客様ID体系を、NPS®（ネット・プロモーター：スコア）を指標としてTOYOTAアカウントに統合されたCXの変革についてご紹介いただきました。この変革により、お客様のペルソナが推定できるようになり、また、どの顧客接点がお客様に影響を与えているかも具体的に把握できるようになったとのことです。さらに、CX基盤を通じたお客様からのフィードバックから、車両開発における機能やデザインなど最適な商品開発や改良にも活用が始まったそうです。特にサービスからのデータ分析から車両設計へのフィードバックについては、AWSもデータを中心にした Big Loop構想をSDVで発信 していたため、その構想が具現化されている事例として非常に印象に残りました。今後はトヨタブランドを中核に、サービス、トヨタ車の顧客接点をさらにつなぎ、お客様中心の変革を実現し、モビリティカンパニーとしてのトヨタブランドを目指されると締めくくられました。 佐々木様のご講演では、CXお取組み概要を広く言及いただき、CX基盤を構築にあたりAWSの各種サービスを使っていただいているとのことでしたので、AWSとしても、今後も一層、トヨタ様のCX基盤の充実に協力して参ります。 SDMが導くHonda第二の創業期 –野川　忠文 様　本田技研工業株式会社　ソフトウェアデファインドモビリティ開発統括部 コネクテッドソリューション開発部 部長 ホンダ様は、コネクテッドサービスを以前から手掛けられており、多くの世界初の取り組みを実施されてこられました。そしてコネクテッドサービスは情報配信から車の機能の一部に昇華するとのビジョンを示されました。次に野川様がAWSのイベントであるre:invent 2023にご登壇いただいた時の内容を振り返り、ソフトウェアディファインドモビリティ(SDM)を実現するために、In-CarとOut-Car一体に一歩踏み込んだ「クロスドメイン」連携を行ったことや爆速開発のために、縦割りからクロスドメイン開発のためのSDM Platformを企画、AWSの Amazon Simple Storage Service (Amazon S3) を使ったデータレイク、 AWS IoT Core や AWS IoT Fleetwise を使ったコネクテッド機能などで構築されるDigital Proving Ground (DPG)について紹介されました。また、組織も、従来の縦割り開発チームからDPG Steering Committeeの傘下に開発支援と開発推進の２グループに再編されたOne Teamによつ進められていると報告されました。そして表題にあるHonda第2の創業期として、電動化や知能化を軸としたソフトウェア領域での価値創造を目指すとの方針を示され、多様なモビリティを通じてHonda独自の価値を提供していくSDM世界の実現への意気込みを表明されました。 パネルディスカッション： In Car/Out Carのデジタル化が開くモビリティの未来 パネリスト –佐々木　英彦 様　トヨタ自動車株式会社　デジタル変革推進室 CX CENTER担当主査 担当部長 –野川　忠文 様　本田技研工業株式会社　ソフトウェアデファインドモビリティ開発統括部 コネクテッドソリューション開発部 部長 –梶本 一夫　アマゾン ウェブ サービス　プリンシパルソリューションズアーキテクト ファシリテータ –竹川 寿也　アマゾン ウェブ サービス　シニア事業開発マネージャー パネルディスカッションでは、トヨタ佐々木様、ホンダ野川様に加え、AWSからSDVの技術リプレゼンタティブである梶本も参加して、今回のフォーラムのテーマである「In Car/Out Carのデジタル化が開くモビリティの未来」について、司会の竹川により各パネラーからの考え方や取組みについて改めてディスカッションを行いました。 トヨタの佐々木様からは、CX基盤を通じてお客様起点でフィードバックが入ることが重要で、Out Carのサービス群からIn Carの車両設計が始まった今、「もうIn Car、Out Carと区別することをやめませんか」と、非常に印象に残るご提言をいただきました。 ホンダの野川様からは、DPGによる爆速化の取り組みそのものが、佐々木様のご講演を聞いて正しいと確信したことや、コネクテッドサービスを長年継続することで、お客様起点で車両設計やサービス企画することが大切であることを理解していること、組織としてIn Car、Out Car一体化していることに自信を持てたとのコメントもいただけました。 AWSの梶本からは、ご講演者のお二人の発言を受け、お客様起点で考えるとIn CarとOut Carは区別なく、連続している視点の大切さに感銘した旨を回答。またAWS自身が、多くのお客様に耳を傾け、共通した課題となっている部分でサービスとしてまとめてきた歴史をご紹介し、今後も自動車産業の成長に寄与できるように努力すると決意表明しました。 デモ展示 今回のAutotech Forumでは、会場に来られたお客様に、ミニブースにおけるデモ展示も行いました。デモ展示はAWSからだけではなく、自動車産業に貢献されているパートナー様にも出展いただきました。デモは以下の６点でした。 – Elektrobit Automotive GmbH様:　Power TrainにおけるEVバッテリープラントモデルの最適制御仮想ECU スポーツモードなど走行モードにより配下のMCU群に指示を行うSoC上で動作するASIL-B取得のEB corbos Linux環境、バッテリー制御MCUで動作するEB tresos環境をAWS上で動かし、バッテリープラントモデルの制御最適化の試行錯誤をAWS上で行なう事例をご展示いただきました。 – パナソニックオートモーティブシステムズ株式会社様:　IVI向け仮想ECU virtual SkipGen、Unified HMI IVI向け仮想ECU virtual SkipGenでは、Android Automotive OSやAGL (Automotive Grade Linux)、QNXを動かし、その上でのアプリケーション開発をIVI向けECUが無くてもAWS上だけで行うことができます。さらにパナソニックオートモーティブ様がオープンソース化を推進されているUnified HMIを用いることで、様々なOSで制御されている車室空間のあらゆるディスプレイを一つの仮想ディスプレイからのマッピングとして定義でき、同じ車室空間体験の異なる車種への展開や、複数のディスプレイに跨る同時表示などの実装がAWS上で確認することで簡単になると言う事例をご展示いただきました。 – Wipro Technologies Limited様:　自動運転アルゴリズム開発ツールチェーンでのシャドーモード実演 ADASの改良においては、現在のアルゴリズムと次のアルゴリズム候補の間で、認識性能が改善されるかを確認していくことが重要となります。Wipro様には、同じ認識対象のインプットに対し、現行アルゴリズムでの処理に加え、シャドーモードで新たなアルゴリズムを同時に動かし、両者での差分も提示できるSDVプラットフォームについてご展示いただきました。認識結果の差分をAWS上のCI/CD環境に自動で入力することで再学習が必要な映像シーンを自動選択し、アルゴリズムを改善することで認識率向上を図ると言う自動化について訴求いただきました。 – 富士ソフト株式会社様:　運転環境試験用車両シミュレータ 運転制御のアルゴリズム開発においては、制御アルゴリズム適用時の運転者の挙動が重要なインプットとなります。実際に運転者が着座し、緊急ブレーキを体験でき、その運転者の挙動を観測・分析できるドライビング・シミュレータを富士ソフト株式会社様にはご展示いただきました。また制動状況のシミュレーションもAWS上で生成することで、様々な制動パラメータによる走行データで実験できるようになっていることも訴求いただきました。 – AWS: ①　 AWS IoT FleetWise と Amazon QuickSight を用いた路面画像認識の教師データ作成と学習 AWS IoT FleetWise は、CANデータやADASで使われるカメラ映像を、予め設定した条件に合致した場合にクラウドにアップロードできます。このデモではカメラ映像から降雪やぬかるみなどの路面状況を認識するAIを学習により作成する時、同時にアップロードされるCANデータからタイヤのスリップ状況などを分析した実際の路面状況を教師データとして利用する使い方を訴求しました。 Amazon QuickSight を用いて、各シーンごとにご認識してしまったカメラ映像を抽出し、再学習対象のデータとすることで、路面認識AIの精度を上げることができるようになりました。 – AWS: ②　生成AIを活用した自然言語による自動運転学習用シーン検索 自動運転のアルゴリズム改善が必要になった時、膨大なカメラ映像の中から特定のシーンのみを再学習用のデータとして抽出したいことが、よくあります。このデモでは生成AIを用いて、自動的に分類されたカメラ映像のカットの中から、「交差点を人が渡っているシーン」など自然言語で指示することで、当該シーンが検索できることを訴求しました。生成AIは、今後、自動車業界においても多くの分野で利用されることが期待されています。 過去のイベント – AWS Autotech Forum 2023 – AWS Autotech Forum 2022 – AWS Autotech Forum 2021 – AWS Autotech Forum 2020 #1 – AWS Autotech Forum 2020 #2 – AWS Autotech Forum 2019 著者 梶本一夫（Kazuo Kajimoto） Principal Solutions Architect Amazon Web Services, Inc. 好きなOLP（ Our Leadership Principles ）はBias for Actionです。

本記事は 2023年10月17日に公開された”Announcing the AWS Well-Architected Framework DevOps Guidance”を翻訳したものです。 2024年3月26日 AWS Well-Architected Tool の Lens Catalog に DevOps Lens として DevOps Guidance が追加されました。 このアップデートにより、ユーザはクラウドベースのワークロードをこれらのベストプラクティスに照らして自己評価し、ツールのレポートを通じて改善計画を確認可能です。 Amazon Web Services (AWS) は、 AWS Well-Architected Framework DevOps Guidance を発表しました。AWS DevOps Guidance では、AWS DevOps Saga (訳注 Saga は冒険談や大河小説などを意味する単語です。DevOps を持続的に実践するには時間がかかり、継続的かつ相互に結びついた一連の能力が必要となることを反映し、「Saga」という言葉を用いています)について紹介しています。AWS DevOps Saga は、クラウドの規模でソフトウェア設計や開発、セキュリティ保護及び、効率的な運用を行っていくために、包括的なアプローチを形成していく最新の機能を集めたコレクションです。AWS DevOps Guidance は、Amazon 自身の変革の旅路から得た学びと、世界中に提供しているクラウドサービスを管理してきた経験を基に、あらゆる規模の組織にベストプラクティス、プロセス、技術的な能力を提供することで、ビジネス価値の向上とアプリケーションのより安全かつ高速な提供を促進するために作成されました。 Amazon の DevOps 変革の概要 2000 年代初頭、 Amazon は 独自の DevOps の変革を経験しました。この経験がオンライン書店から AWS クラウドコンピューティング部門の設立へと繋がっています。今日、 AWS は Amazon の経験した独自の DevOps のアプローチと同様の革新的な DevOps アプローチを採用した幅広いプロダクトとサービスを世界中のお客様へ提供しています。この変革のポジティブな効果により、AWS は DevOps の重要性を認識し、その採用と実装の最前線に立っています。 Amazon は自身の変遷と、クラウドへのマイグレーションやモダナイゼーションをお客様に支援してきた経験から DevOps の導入を成功させるための重要な能力についての洞察を得ました。これらの知見を活かし、お客様が DevOps を継続的に導入し実践できるよう、相互に関連する一連の能力を組み込んだ「DevOps Saga」を作成しました。各 DevOps Saga には、成功の指標となる能力、測定する指標、および避けるべき一般的なアンチパターンに対する規範的ガイダンスが含まれています。 DevOps Saga のご紹介 DevOps Saga は 5つの要素から構成され、AWS の DevOps のベストプラクティスを構成するソフトウェア開発プロセスにおける中核的な領域です。 DevOps Sagaを総合的に活用することでクラウド規模でのソフトウェアの設計や開発、セキュリティの確保、効率的な運用を包括的に行うための最新の機能を網羅できます。 DevOps Saga は、組織内での理解の共通化を促進し、DevOps という言葉に対する組織内の定義の統一に役立ちます。また、 DevOps の導入状況を長期間にわたり継続的に測定可能です。DevOps Saga を構成する要素は次の 5 つになります: 組織導入の Saga : お客様中心の適応力のある文化の形成を促進し、人間中心のプロセスの最適化、個人とプロフェッショナルとしての成長、開発者体験の改善に焦点を当てることで、DevOps 導入の基盤を築きます。 開発ライフサイクルの Saga : 組織のワークロードを迅速かつ安全に開発、レビュー、デプロイする能力を高めることを目指しています。フィードバックループ、一貫したデプロイ手法、「すべてをコード化する」アプローチを活用することで、デプロイの効率化を図ります。 品質保証の Saga : 開発プロセスに統合されたテストファーストな手法を提唱することにより、設計観点で well-architected であり、安全で、コストが最適化され、持続可能で、自動化を通じて俊敏性が向上したアプリケーションの提供を保証していきます。また、自動化によるアジリティが向上するように推進します。 自動化ガバナンスの Saga :開発プロセス全体で指令、検出、予防、対応措置の実施を容易にします。自動化されたプロセス、ポリシー、ガードレールを通じて、リスク管理、ビジネスプロセス遵守、アプリケーションおよびインフラストラクチャのコンプライアンスを様々な規模で実現することを重視しています。 可観測性(オブザーバビリティ)の Saga: 環境やワークロードに可観測性を組み込むアプローチを提示します。これによってチームが問題の検知や対処、パフォーマンスの改善、コストの削減およびビジネス目標と顧客ニーズとの整合性を確保できるようにします。 AWS DevOps Guidance は誰が利用すべきか？ 私たちは、すべての組織がユニークであり、 DevOps を実践するための万能なアプローチはないと認識しています。本記事で提示した推奨事項と例は、お客様の組織の環境、品質、セキュリティのニーズに合わせたカスタマイズして活用いただけます。AWS DevOps Guidance は、幅広いプロフェッショナルや組織を対象に設計されています。初めて DevOps に取り組むスタートアップ企業、プロセスの改善を図る企業、公的機関、クラウドネイティブな企業、AWS クラウドへの移行を検討する企業など、さまざまな組織に適しています。最高技術責任者 ( CTO ) や最高情報セキュリティ責任者 ( CISO ) として戦略的方向性を示す立場の方、ワークロードの設計や展開に携わる開発者やアーキテクト、品質保証、監査、ガバナンスを監督するコンプライアンス担当者など、どのような役割の方々にとっても、このガイダンスは役立つものとなっています。 ネクストステップ AWS DevOps Guidance のリリースを受け、お客様には本書をダウンロードし一読いただき、推奨事項に従ってワークロードの実装とテストを実施いただくことをお勧めします。AWS Well-Architected Framework と併せて AWS DevOps Guidance を活用することで、お客様の組織や個々のワークロードが DevOps のベストプラクティスに準拠しているかを評価し、強みと改善の余地がある領域を特定してください。開発者、運用担当者、意思決定者など、さまざまな役割のメンバーでチームを結成し、評価結果を共有しましょう。AWS DevOps Guidance から得られた洞察を活かして改善領域の優先順位を決め、DevOps 能力を継続的に向上してください。 AWS DevOps Guidance は、 AWS Well-Architected サイト からダウンロードできます。詳細については、AWS アカウントチームまでお問い合わせください。アーキテクチャやサービスの設計を検討する際や、Well-Architected レビューを実施する際には、AWS Well-Architected Framework やその他のガイダンスと同様に、AWS DevOps Guidance を早期から積極的に活用することをお勧めします。AWS DevOps Guidance をご利用の際には、ベストプラクティスやテクノロジーの進化に合わせて改善できるよう、ご意見やご感想をお寄せください。一般的なユースケースや新しい指標、ベストプラクティスが出てくる度に、内容は継続的に更新されます。 本記事はアマゾンウェブサービスジャパン合同会社の畠泰三が翻訳を担当しました。 原文はこちら

11 月 13 日は、 リソースコントロールポリシー (RCP) をご紹介します。これは、AWS Organizations で管理される新しい認可ポリシーで、組織全体のリソースに対する使用可能な最大の許可を設定するために使用できます。これは、AWS 環境に データ境界 を確立し、リソースに対する外部アクセスを大規模に制限するのに役立つ予防的コントロールの一種です。Organizations 内で一元的に強制適用される RCP により、中心的なガバナンスチームとセキュリティチームは、AWS アカウント内のリソースに対するアクセスが、組織のアクセスコントロールガイドラインに準拠していることに自信をもつことができます。 RCP はすべての商用 AWS リージョンで利用可能で、リリース時には次のサービスがサポートされています: Amazon Simple Storage Service (Amazon S3) 、 AWS Security Token Service (AWS STS) 、 AWS Key Management Service (AWS KMS) 、 Amazon Simple Queue Service (Amazon SQS) 、 AWS Secrets Manager 。 RCP を有効にして使用しても追加料金はかかりません。 サービスコントロールポリシー (SCP) との違い 本質的には似ている一方で、RCP は サービスコントロールポリシー (SCP) を補完しますが、独立して機能します。 サービスコントロールポリシー (SCP) を使用すると、AWS Identity and Access Management (IAM) ロールなどの組織内のプリンシパルに付与される許可を制限できます。これらの許可を Organizations 内で一元的に制限することで、AWS サービス、特定のリソース、さらにはプリンシパルが複数の AWS アカウントにまたがってリクエストを実行するために満たさなければならない条件に対するアクセスを制限できます。 一方、RCP を使用すると、組織内のリソースに付与される許可を制限できます。RCP は Organizations 内で一元的に実装するため、複数の AWS アカウントにまたがって、リソースに対する、一貫性のあるアクセスコントロールを強制適用できます。例えば、アカウント内の S3 バケットに対するアクセスを制限して、組織に属するプリンシパルのみがアクセスできるようにすることができます。RCP は、誰が API リクエストを実行しているのかにかかわらず、リソースがアクセスされたときに評価されます。 SCP と RCP のいずれも許可を付与するものではないことに留意してください。これらは、組織内のプリンシパルとリソースに使用可能な最大の許可を設定するだけです。許可を付与するには、適切な IAM ポリシー (ID ベースのポリシーやリソースベースのポリシーなど) を使用する必要があります。 SCP と RCP のクォータは、互いに完全に独立しています。各 RCP は最大 5,120 文字です。組織のルート、各 OU、およびアカウントに最大 5 個の RCP をアタッチでき、組織で最大 1,000 個の RCP を作成して保存できます。 開始方法 RCP の使用を開始するには、まず RCP を有効にする必要があります。これは、Organizations コンソール、 AWS SDK 、または AWS コマンドラインインターフェイス (AWS CLI) を使用して行うことができます。ポリシータイプを有効または無効にできるのは、Organizations 管理アカウントまたは委任された管理者のみであるため、必ずそれらを使用してください。 [すべての機能] オプションで Organizations を使用していることを確認してください。 [一括請求 (コンソリデーティッドビリング) 機能] モードを使用している場合は、RCP を有効にする前に、 すべての機能を使用するように移行 する必要があります。 コンソールユーザーは、まず Organizations コンソールに移動します。 [ポリシー] を選択すると、 [リソースコントロールポリシー] を有効にするオプションが表示されます。 RCP を有効にすると、 [リソースコントロールポリシー] ページで、 RCPFullAWSAccess という新しいポリシーが使用可能になっていることがわかります。これは、自動的に作成され、ルート、各 OU、AWS アカウントなど、組織内のすべてのエンティティにアタッチされる AWS マネージドポリシーです。 このポリシーにより、すべてのプリンシパルが組織のリソースに対して任意のアクションを実行できるようになります。つまり、独自の RCP を作成してアタッチするまで、既存の IAM 許可はすべてこれまでどおりに動作します。 これは、次のようになります。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "*", "Resource": "*" } ] } RCP の作成 これで、最初の RCP を作成する準備が整いました。 例を見てみましょう。 デフォルトでは、AWS リソースは外部プリンシパルに対するアクセスを許可しません。リソース所有者は、ポリシーを設定することで、そのようなアクセスを明示的に付与する必要があります。デベロッパーはアプリケーションのニーズに応じてリソースベースのポリシーを柔軟に設定できますが、RCP を使用すると、中心的な IT チームは組織内のリソース全体で、有効な許可に対するコントロールを維持できます。これにより、デベロッパーが広範なアクセスを付与した場合でも、外部 ID によるアクセスは組織のセキュリティ要件に従って制限されます。 組織内のプリンシパルのみがアクセスできるように、S3 バケットに対するアクセスを制限する RCP を作成してみましょう。 [リソースコントロールポリシー] ページで、 [ポリシーを作成] を選択すると、新しいポリシーを作成できるページが表示されます。 このポリシーを EnforceOrgIdentities と呼びます。このポリシーがどのような効果を有するのかを一目で理解しやすくし、適切にタグ付けできるよう、明確な説明を入力することをお勧めします。 次のセクションでは、ポリシーステートメントを編集できます。事前入力済みのポリシーテンプレートを独自のものに置き換えます。 完全な JSON ポリシードキュメントは次のとおりです。 { "Version": "2012-10-17", "Statement": [ { "Sid": "EnforceOrgIdentities", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "*", "Condition": { "StringNotEqualsIfExists": { "aws:PrincipalOrgID": "[MY ORG ID]" }, "BoolIfExists": { "aws:PrincipalIsAWSService": "false" } } } ] } 詳しく見てみましょう。 Version – これは IAM ポリシーの標準かつ必須の要素です。AWS は下位互換性を維持しているため、最新バージョン (現在は 2012-10-17) を使用しても既存のポリシーが壊れることはなく、新しい機能を使用できます。 Statement – 1 つ以上のステートメントオブジェクトを含めることができる配列。これらの各ステートメントオブジェクトは、単一の許可または許可セットを定義します。 Sid – これはオプションのフィールドで、ポリシー管理とトラブルシューティングに役立ちます。この JSON ポリシードキュメントの範囲内で一意である必要があります。 Effect – 前述のとおり、デフォルトでは、組織内のあらゆるエンティティにアタッチされているすべての AWS プリンシパル、アクション、およびリソースに対するアクセスを許可する RCP があります。そのため、制限を適用するには、 Deny を使用する必要があります。 Principal – RCP では、このフィールドは常に "*" に設定する必要があります。このポリシーを特定のプリンシパルにのみ適用する場合は、Condition フィールドを使用します。 Action – このポリシーが適用される AWS サービスとアクションを指定します。この場合、アクセスコントロールガイドラインを満たしていない場合は、Amazon S3 とのすべてのインタラクションを拒否します。 Resource – RCP が適用されるリソースを指定します。 Condition – 各リクエストについてポリシーを適用すべきかどうかを決定するために評価される条件のコレクション。 RCP を適用するには、すべての条件が true と評価される必要がある ことを覚えておいてください。ここでは、2 つの条件を適用しています。 1.リクエストは外部プリンシパルによって実行されたか? "StringNotEqualsIfExists": { "aws:PrincipalOrgID": "[MY ORG ID]" } この条件は、まず、キー aws:PrincipalOrgID がリクエスト内に存在するかどうかをチェックします。存在しない場合、この条件はそれ以上評価せずに true と評価します。 存在する場合、値を組織 ID と比較します。値が同じ場合は false と評価され、RCP は適用されません。なぜなら、すべての条件が true と評価される必要があるからです。組織内のプリンシパルに対するアクセスを拒否したくないため、これは意図された動作です。 ただし、値が組織 ID と一致しない場合は、リクエストが組織外のプリンシパルによって実行されたことを意味します。条件は true と評価されます。これは、2 つ目の条件も true と評価されれば、RCP が適用される可能性がまだあることを意味します。 2.リクエストは AWS サービスからのものか? "BoolIfExists": { "aws:PrincipalIsAWSService": "false" } この条件は、 aws:PrincipalIsAWSService という特別なキーがリクエストに含まれているかどうかをテストします。このキーは、署名されたすべての API リクエストのリクエストコンテキストに自動的に挿入され、S3 バケットにイベントを書き込む AWS CloudTrail などの AWS サービスからのものである場合は true に設定されます。このキーが存在しない場合、この条件は true と評価されます。 存在する場合は、ステートメントで宣言した値と比較されます。ここでは、値が false と等しいかどうかをテストしています。等しい場合は、リクエストが AWS サービスによって実行されたものではなく、組織外の誰かによって実行された可能性があることを意味するため、 true を返します。それ以外の場合は、 false を返します。 つまり、リクエストが組織内のプリンシパルからのものではなく、AWS サービスからのものでもない場合、S3 バケットに対するアクセスは拒否されます。 このポリシーは単なるサンプルであり、独自のビジネス目標とセキュリティ目標に合わせてカスタマイズすべきです。例えば、このポリシーをカスタマイズして、ビジネスパートナーによるアクセスを許可したり、AWS サービスに対するアクセスを制限して、パートナーがお客様に代わってのみリソースにアクセスできるようにしたりすることができます。詳細については、「 Establishing a data perimeter on AWS: Allow only trusted identities to access company data 」をご覧ください。 RCP のアタッチ RCP をアタッチするプロセスは SCP に似ています。前述のように、組織のルート、OU、または組織内の特定の AWS アカウントに RCP をアタッチできます。 RCP をアタッチした後、影響を受ける AWS リソースに対するアクセスリクエストは RCP 制限に準拠する必要があります。大規模に強制適用する前に、アカウント内のリソースに対する RCP の影響を徹底的にテストすることをお勧めします。個々のテストアカウントまたはテスト OU に RCP をアタッチすることから始めることができます。 実際の動作 これで RCP を作成してアタッチしたので、実際に機能している様子を確認する準備ができました。 デベロッパーがリソースベースのポリシーを組織内の S3 バケットにアタッチし、外部アカウントの ID に対してアクセスを明示的に付与したと仮定します。 RCP は、ユーザーが RCP で許可されているよりも許容度が高いリソースベースのポリシーを保存することを妨げません。ただし、前述のとおり、RCP は認可プロセスの一環として評価されるため、外部 ID によるリクエストはいずれにしても拒否されます。 この外部アカウントを使用してバケットにアクセスを試みることで、これを証明できます。今回は AWS CLI から実行します。 $ aws s3api get-object —bucket 123124ffeiufskdjfgbwer \ --key sensitivefile.txt \ --region us-east-1 local_file An error occurred (AccessDenied) when calling the GetObject operation: Access Denied 環境内での RCP のデプロイのスケール これまで、コンソールを使用して RCP を管理する方法について見てきました。ただし、大規模なコントロール管理の場合は、それらを Infrastructure as Code として設定することを検討し、既存の継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインとプロセスに統合されることを確認すべきです。 AWS Control Tower を使用する場合は、SCP ベースのコントロールに加えて RCP ベースのコントロールをデプロイできます。例えば、AWS Control Tower を使用して、前述の例で作成したものと同様の RCP をデプロイし、外部プリンシパルが組織内の S3 バケットにアクセスできないようにすることができます。これにより、マネージドアカウントのリソースに RCP が一貫して適用され、アクセスコントロールガバナンスが大規模に合理化および一元化されます。 さらに、SCP と同様に、AWS Control Tower は RCP のためにドリフト検出もサポートしています。AWS Control Tower の外部で RCP が変更または削除された場合、ドリフトについて通知され、是正のステップが提供されます。 まとめ リソースコントロールポリシー (RCP) は、組織内の AWS リソースに使用可能な最大の許可に対する一元管理を提供します。SCP とともに、RCP は AWS 環境全体で データ境界 を一元的に確立し、意図しないアクセスを大規模に防ぐのに役立ちます。SCP と RCP は独立したコントロールであり、異なる一連のセキュリティ目標を達成することを可能にします。SCP または RCP のみを有効にするか、または両方のポリシータイプを併用して、多層防御セキュリティモデルの一部として包括的なセキュリティベースラインを確立するかを選択できます。 詳細については、「 AWS Organizations ユーザーガイド 」の「Resource control policies (RCPs)」をご覧ください。 Matheus Guimaraes | @codingmatheus 原文は こちら です。

私は数年前から AWS BuilderCards の進歩を見てきました。あらゆるスキルレベルのプレイヤーがこのカードを使用して、楽しく興味をそそる方法で AWS について学び、カードを組み合わせてアーキテクチャを形成しようと (友好的に) 競い合い、プレイしながら知識を得てポイントを獲得しています。 これまでに 15,000 セット以上の BuilderCards が印刷され、3 回の re:Invent、15 回の AWS Summit、複数のコミュニティイベントで使用されています。例えば、 JAWS Days 2024 の期間中、東京で楽しい時間を過ごしている AWS 愛好家グループの写真をご覧ください。 プレイヤーからのフィードバックは非常に好意的で、1,500 件以上の返信において星 4.8 の顧客満足度スコア (CSAT) を獲得しています。 第 2 エディションの発売開始 AWS BuilderCards の第 2 エディションが re:Invent 2024 で配布され、まもなくオンラインでも購入できるようになるとお知らせできることを嬉しく思います。第 1 エディションへのフィードバックに応えて、第 2 エディションに多くの変更を加えました。概要は次のとおりです。 デザイン – 変更後のデザインでは、カードの内容に重点を置き、カードをより魅力的で遊び心のあるものにするために、グラデーションやパターンが追加されています。フォントサイズが大きくなり、ゲームエフェクトがアイコンとして表示されるようになり、QR コードが BuilderCards サイトを指すようになりました。 ゲームの仕組み – 仕組みが見直され、バランスの改善、プレイの簡素化、一部のバイアスの排除が行われました。一般的なオンプレミスデータセンター環境を表すスターターカードもいくつかあります。 生成 AI アドオンパック – この新しいデッキには、生成 AI と AWS アーキテクチャが連携する方法を示すために設計された、50 枚の BuilderCards が追加されています。このアドオンパックには、ミッションカードのセットも含まれています。これらのカードは、公開されているベストプラクティスやソリューションにリンクする QR コードを使用して、コンテキストを追加します。カードはより大きくなり、テキストとアーキテクチャ図が追加されました。使用は任意で、プレイヤーはミッションを完了すると追加ポイントを獲得できます。各デッキには、カスタマイズに役立つ空白の BuilderCards が 5 枚と空白のミッションカードが 2 枚含まれています。 BuilderCards を入手 re:Invent 2024 に参加する予定なら、Caesar’s Forum の 1 階にある PeerTalk エリアの隣の BuilderCards プレイエリアを訪れてください。 日曜日 – 午前 10 時～午後 6 時 月曜日 – 午前 9 時～午後 5 時 火曜日 – 午前 9 時～午後 5 時 水曜日 – 午前 9 時～午後 5 時 木曜日 – 午前 9 時～午後 4 時 re:Invent の他の参加者と対戦したり、自分のゲームパックやアドオンパックを入手して持ち帰ったりすることができます (1 日あたり 1,000 個をプレゼントいたします)。 山口正徳 氏 (AWS ヒーロー) と 榎本航介 氏 (AWS コミュニティビルダー) の努力のおかげで、その場でプレイできる日本語の BuilderCards もご用意します。翻訳プロセスの詳細については、榎本氏のブログ記事 ( AWS BuilderCards Japanese Edition for JAWS DAYS ) をご覧ください。 re:Invent に参加できない場合でも、すぐに自分のデッキを購入できるようになります。詳細については、ここに戻ってご確認ください! ご期待ください BuilderCards チームは、拡張パックや追加の言語パックなど、その他の特典の開発に取り組んでいます。 – Jeff ; 原文は こちら です。

AWS ニュースブログは 20 周年を迎えました ! 2004 年 11 月 9 日、Jeff Barr は 初めてのブログ記事 を公開しました。当初、彼は TypePad を使用して個人のブログサイトを開設しました。会社やチームではなく、自分の個人的な声を読者に届けたかったのです。 2014 年 4 月 29 日、当社は 新しい AWS ブログサイト を作成し、すべての投稿をそのページに移行しました。現在、AWS ニュースブログには 4,300 件を超える投稿があり、そのうちの 3,200 件以上が Jeff による投稿です。 2016 年 12 月以降、AWS ニュースブログには新しいライターが追加されましたが、引き続き、初日に打ち立てられた AWS ニュースブロガー向けの Jeff のリーダーシップ・プリンシプル に沿って活動しています。AWS ニュースブログのユニークな点は、ブログ作成者が Customer Obsession (顧客第一主義) のリーダーシップ・プリンシプルに沿って製品チームの機能を事前に利用していること、そして Frugality (倹約) のプリンシパルに従って、お客様がそれらをすばやく使用して時間を節約する方法のウォークスルーに焦点を当てていることです。 過去 20 年間、Jeff が果たしてきた基本的かつ極めて重要な役割にとても感謝しています。また、これからの 20 年を楽しみにしています! 11 月 4 日週のリリース 私が注目したいくつかのリリースをご紹介します。 Amazon MSK 向けの新しい Express ブローカー – Express ブローカーは Amazon MSK Provisioned の新しいブローカータイプで、標準の Apache Kafka ブローカーと比較して、ブローカーあたりのスループットが最大 3 倍向上し、スケールが最大 20 倍速くなり、回復時間が 90% 短縮されるように設計されています。Express ブローカーには、デフォルトで Kafka のベストプラクティスが事前設定されており、すべての Kafka API をサポートし、同じ低レイテンシーパフォーマンスを提供するため、既存のクライアントアプリケーションを変更することなく引き続き使用できます。 新しい Amazon Kinesis Client Library 3.0 – Kinesis Client Library (KCL) 3.0 では、ストリーミングデータを処理するためのコンピューティングコストを、以前の KCL バージョンと比較して最大 33% 削減できるようになりました。KCL 3.0 では、ストリーム処理ワーカーのリソース使用率を継続的にモニタリングし、過度に使用しているワーカーから十分に使用されていない他のワーカーにロードを自動的に再配分する、強化されたロードバランシングアルゴリズムが導入されています。詳細については、 AWS ビッグデータブログの記事 をご覧ください。 Amazon EC2 での Microsoft Windows Server 2025 イメージ – License Included (LI) Amazon マシンイメージ (AMI) で Microsoft Windows Server 2025 のサポートを開始しました。これにより、Windows Server の最新バージョンを簡単かつ柔軟に起動する方法をお客様に提供できるようになりました。 Amazon EC2 で Windows Server 2025 を実行することにより、お客様は Windows Server の最新機能を使用して AWS のセキュリティ、パフォーマンス、信頼性を活用できます。Amazon EC2 で Windows Server 2025 を実行する方法の詳細については、「 AWS での Windows ワークロード 」を参照してください。 Amazon Bedrock での Anthropic の Claude 3.5 Haiku モデル – Claude 3.5 Haiku は、Anthropic の最速モデルの次世代であり 、 迅速な応答時間と改善された推論機能を兼ね備えているため、スピードとインテリジェンスの両方を必要とするタスクに適しています。Claude 3.5 Haiku はあらゆるスキルセットで向上しており、コーディングを含む多くのインテリジェンスベンチマークで、Anthropic の前世代かつ最大のモデルである Claude 3 Opus をも上回っています。詳細については、 AWS ニュースブログの記事 をお読みください。 Amazon Bedrock Prompt Management GA – Amazon Bedrock Prompt Management で、プロンプトの作成、テスト、バージョニング、共有を簡素化できます。一般公開時に、プロンプトを設定し、生成 AI アプリケーションでそれらを呼び出すための拡張オプションを提供する新機能を追加しました。これには構造化プロンプトや、Converse と InvokeModel API の統合などが含まれます。詳細については、 AWS 機械学習のブログ記事 をご覧ください。 Amazon Polly 向けの 6 つの新しい合成型生成音声 – 生成エンジンは、生成 AI テクノロジーを活用した Amazon Polly の最も高度な音声合成 (TTS) モデルです。Ayanda (南アフリカ英語)、Léa (フランス語)、Lucia (ヨーロッパスペイン語)、Lupe (アメリカスペイン語)、Mía (メキシコスペイン語)、Vicki (ドイツ語) の 6 つの合成型生成音声 (女性) を新たに追加しました。これにより、13 の声と 9 つのロケールが拡張され、表現力豊かで魅力的な声の選択肢が増えました。 Amazon OpenSearch Service 延長サポート – 従来の Elasticsearch バージョンと OpenSearch バージョンの標準サポートおよび延長サポートのタイムラインの終了をお知らせします。6.7 までのレガシー Elasticsearch バージョン、7.1〜7.8 までの Elasticsearch バージョン、1.0〜1.2 までの OpenSearch バージョン、2.3〜2.9 までの OpenSearch バージョンの標準サポートは、2025 年 11 月 7 日に終了します。延長サポートでは、通常のインスタンス料金に重ねて段階的な定額料金を支払うことで、標準サポートの終了後も重要なセキュリティアップデートを引き続き受けることができます。詳細については、 AWS ビッグデータブログの記事 をご覧ください。 AWS からの発表の完全なリストについては、「AWS の最新情報」ページを定期的にご確認ください。 AWS のその他のニュース 興味深い他のニュース項目をいくつかご紹介します。 CEO の AWS データセンター訪問 – AWS の CEO である Matt Garman は先日、弊社の AWS データセンターの 1 つを訪問して素晴らしい時間を過ごし、チームによってもたらされる継続的なイノベーションを確認することができました。もちろん、Amazon の上級幹部がフルフィルメントセンター、コンタクトセンター、データセンターを訪れ、お客様のために作業を行うのは当然のことです。AWS データセンターは、あらゆる面でお客様向けに設計されており、最大の回復力、パフォーマンス、エネルギー効率を実現します。 AWS は、AWS データセンターの近くで中小企業の支援、雇用の創出、持続可能性に関する取り組みの立ち上げ、教育プログラムの開発を行っています。最新情報を入手 – コミュニティでの AWS: About Amazon News では、米国中のデータセンターの近くで起きていることをご紹介します 。 Amazon での Amazon Q Business – 以前、とある Amazon ストーリーをご紹介 しました。 Amazon Q Developer のコード変換を使用して、 30,000 件以上の古い Java アプリケーションを Java 17 バージョンに移行 したというものです。最新バージョンの Java に移行したことで、以前の手動作業に比べて 4,500 年分以上もの開発者の労力が削減され、同社は年間 2 億 6,000 万 USD を節約しました。 今日ご紹介するのは、 Amazon での Amazon Q Business のもう 1 つのドッグフーディングのストーリー です。Amazon は Amazon Q Business と共同で社内チャットボットを構築し、Amazon の開発者から寄せられた 100 万件を超える質問を解決しました。これにより、手作業による技術調査に費やす時間を 45 万時間以上削減できました。 私たちのチームは、何百万もの内部文書を使って Amazon Q Business をオンボーディングし、チームが毎日使用するツールに Q Business を統合しました。開発者は、Q&A 掲示板や Slack チャンネルで、複雑な技術的質問への回答を何時間も待つのではなく、数秒で得られるようになりました。 PGA TOUR の TOURCast – ゴルフがお好きなら、このニュースに興味があるはずです。 PGA TOUR は、 TOURCast を日本の 2024 ZOZO CHAMPIONSHIP でデビューさせました。これは、 CDW を利用した ShotLink と呼ばれる新しいスコアリングシステムに基づいて、より良い統計データを収集して広め、ファンとゲームとの距離を近づけるためです。PGA TOUR がこのテクノロジーをアジアに持ち込み、AWS の柔軟性とスケーラビリティを活用して独自の課題を克服したのはこれが初めてです。 PGA TOUR のボランティアが ZOZO CHAMPIONSHIP のフェアウェイに、特定のショットデータを入力して Shotlink Select Plus にフィードバックする GPS 機器を設置しているところ。[画像: PGA TOUR] 同社は過去 2 年間で、新しいクラウドスタックにスコアリングシステムを完全に再構築しました。AWS クラウドでは、ハイテクレーダーシステム、カメラ、手動入力のいずれから送信されるデータであっても、システムがすべてシームレスに処理します。 今後の AWS イベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 AWS GenAI Lofts – AWS GenAI Lofts は、テクノロジーを紹介するだけに留まらず、スタートアップ、開発者、投資者、業界エキスパートが一堂に集まって交流する場も提供します。深いインサイトを得たい、または 生成 AI の専門家から質問の回答を得たいと考えているかにかかわらず、GenAI Loft は皆さんのニーズに対応し、次のイノベーションの構築を開始するために必要な事柄のすべてを提供します。 サンパウロ (11 月 20 日まで) と パリ (11 月 25 日まで) のイベントに参加しましょう。 AWS Community Day – 世界中のエキスパート AWS ユーザーと業界リーダーがリードするテクニカルディスカッション、ワークショップ、ハンズオンラボが盛り込まれたコミュニティ主導のカンファレンスに参加しましょう。日程は、 インドネシア、ジャカルタ (11 月 23 日)、 インド、コーチ (11 月 14 日) です。 AWS re:Invent – 12 月 2〜6 日にラスベガスで開催される毎年恒例の学習イベントに、引き続き ご登録 いただけます。驚くことに、Amazon の CEO である Andy Jassy は、 今年も戻ってきて AWS re:Invent に参加すると発言しました。彼はこう語っています。「いつものように、このイベントを学習イベントにすることが最優先事項です。そうすれば、お客様は大きな成果を取り戻し、自身の顧客体験やビジネスを変えることができます。また、皆様に気に入っていただけると考えているさまざまなことを発表する予定です」 お会いできるのを楽しみにしています! 近日開催されるすべての対面イベントと仮想イベントを閲覧できます。 11 月 11 日週はここまでです。11 月 18 日週の Weekly Roundup もお楽しみに! – Channy この記事は、 Weekly Roundup  シリーズの一部です。AWS からの興味深いニュースやお知らせを簡単にまとめたものを毎週ご紹介します! 原文は こちら です。

AWS CloudFormation を利用することで、クラウドアプリケーションのインフラストラクチャをコードとしてモデル化してプロビジョニングすることが容易になります。 CloudFormation テンプレートは直接 JSON または YAML で記述できるだけでなく、 AWS Cloud Development Kit (CDK) などのツールで生成することもできます。これらのテンプレートが CloudFormation サービスにサブミットされると、リソースはスタックという単位でまとめられ、依存関係を反映した順序でデプロイされます。スタックイベントの詳細は コンソール 上で表形式で確認できます。 そしてこの度、より視覚的で直感的なイベントのビューを提供する deployment timeline view という新機能が登場しました。この機能はスタック操作で CloudFormation が実行した一連のアクションを視覚化します。この機能が提供する視覚的なタイムラインは、リソースがプロビジョニングされた正確な順序、リソース間の依存関係、プロビジョニングにかかった時間を示します。デプロイが失敗した際は根本原因と考えられる箇所を示します。デプロイの舞台裏で起きていることについての追加コンテキストと可視性を提供することで既存の表形式のビューを補完します。 図 1: CloudFormation deployment timeline view の機能の概要 どのように動作するか 新機能の deployment timeline view を利用するために必要なのは、スタックの作成、更新、削除の操作だけです。AWS CloudFormation コンソールで Events タブを選択し、Table view の横にある Timeline view タブをクリックします。 CloudFormation がテンプレートで定義されたリソースのプロビジョニングを開始すると、各リソース操作がタイムラインビューで棒線として表示されます。 リソースは、最新の操作があったリソースが一番上になるように時系列順に垂直に積み上げらます。各リソースアクションは、それぞれのアクションに応じて色分けされた水平の棒で視覚化されます。 ダークモードではロールバック中とロールバック完了のスイッチの色が切り替わる バーの上にカーソルを移動させると、完全なリソース名やリソース操作の開始/終了時刻など詳細な情報が表示されます。 デプロイが失敗した場合は、CloudFormation は失敗の原因と考えられるリソース操作のバーを赤白の縞模様で強調表示します。このバーにカーソルを移動すると、具体的な失敗理由が表示されます。 シンプルなスタックを作成する CloudFormation コンソールを使用してシンプルなスタックを作成します。デプロイを開始して視覚的なタイムラインビューを確認します。 1. CloudFormation コンソールから、 Create stack をクリックし、 with new resources を選択します。 図 2: CloudFormation コンソールの create stack ボタン 2. スタック作成ウィザードで Choose an existing template をクリックし Upload a template file を選択します。 Choose file をクリックしデプロイするスタックのテンプレートファイルを選択してアップロードします。この記事では、 こちら で提供されているテンプレートを使用します。このテンプレートをダウンロードして使用するほかに、独自のテンプレートを使用することもできます。独自のテンプレートを使用した場合はタイムラインビューの内容がこの記事とは異なるものになります。 (翻訳者補足: ここで紹介されているテンプレートはオレゴンリージョンでのみデプロイに成功します) 図 3: CloudFormation コンソールの スタック作成ウィザード アプリケーションスタックには、Amazon EC2 インスタンス ( AWS::EC2::Instance )、Amazon VPC ( AWS::EC2::VPC )、およびサブネット ( AWS::EC2::Subnet ) やインターネットゲートウェイ ( AWS::EC2::InternetGateway ) などの VPC リソースが含まれています。 3. テンプレートをアップロードしたら Next をクリックし、必要に応じてスタック名とパラメータを入力します。 スタックデプロイの後続の手順を完了させ、スタックの作成を開始します。 4. スタックイベントページで、 Table view の横の Timeline view タブをクリックします。 CloudFormation が最初に VPC、その後でサブネット、最後に EC2 インスタンスをプロビジョニングしていく間の進捗状況をリアルタイムで確認できます。 図 4: CloudFormation が実行中のデプロイのタイムラインビュー 5. タイムラインは 5 秒ごとに表示をリフレッシュし、デプロイの進捗状況を更新します。5 秒後、次のようなタイムラインビューが表示されます。 図 5: 5 秒後に更新されたタイムライン 図 6: 完了したデプロイのタイムラインビュー 上のタイムラインでは、CloudFormation によってプロビジョニングされたリソースを表すバーが下から上に向かって並び、それぞれのリソース操作が発生した順序やリソース間の依存関係を読み取ることができます。 バーは操作の進行にともなって青 (進行中)、黄 (整合性チェック中)、緑 (成功)または赤 (失敗) に変化します。 図 7: リソース詳細ポップオーバー いずれかのバーにカーソルを置くと、各デプロイフェーズの開始/終了時間や完全なリソース名などの詳細が表示されます。グラフのポップオーバーに表示される詳細情報から、CloudFormation が InternetGateway リソースを 2 秒で作成し、その後 15 秒待機してリソースが完全に動作しているかどうかを確認してから完了としてマークしたことを読み取ることができます。このフェーズをリソース整合性チェックフェーズ (resource consistency check phase)、またはリソース安定化フェーズ (resource stabilization phase) と呼びます。これによって CloudFormation をはじめとする Infrastructure as Code (IaC) ツールは復元力のあるデプロイメントを確かなものにすることができます。詳しくは CloudFormation optimistic stabilization strategy の記事 (日本語翻訳版は こちら ) をお読みください。 ロールバック完了状態のスタック スタックのデプロイが失敗した場合、CloudFormation は現在のスタック操作の前の安定した状態にロールバックします。 以下のタイムラインビューでは、失敗したスタック操作が完全にロールバックされた状態で表示されています。 赤と白の縞模様で強調表示されているリソースが根本原因である可能性が高いので、すぐにトラブルシューティングを開始できます。 図 8: ロールバック完了状態のスタックのタイムラインビュー まとめ 新機能の CloudFormation deployment timeline view では、CloudFormation が Infrastructure as Code のテンプレートで定義されたリソースをプロビジョニングする際のオーケストレーションフローと依存関係を可視化できるようになりました。 この視覚的なタイムラインビューを活用することで、デプロイメントの失敗の根本原因を素早く特定したり、プロビジョニングプロセスの理解を深めることができます。 この機能は、現在 CloudFormation がサポートされているすべての AWS リージョンで利用可能です。 ぜひ CloudFormation コンソールにアクセスし deployment timeline view を使ってみてください。 著者紹介: Idriss Laouali Abdou Idriss は AWS のシニアプロダクトマネージャーであり、AWS IaC のお客様に最高の体験を提供することに尽力しています。仕事以外では、何千人もの学生を支援する教育コンテンツを作成したり、料理をしたり、ダンスをしたりしています。 Jamie To Jamie はフロントエンドエンジニアであり、過去 3 年間 AWS IaC のお客様にコンソール機能を提供してきました。仕事以外では、絵を描いたり、フーズボールをしたりするのが好きです。 Puran Zhang Puran は 過去 4 年間フロントエンドエンジニアとして IaC コンソールに貢献してきました。仕事以外では、キッチンやコーヒーバーにいるところ、または次のレストランへ急いでいるところをよく見かけます。 本記事は 2024/11/11 に投稿された  Peek inside your AWS CloudFormation Deployments with timeline view を翻訳したものです。翻訳は Solutions Architect : 国兼 周平 (Shuhei Kunikane) が担当しました。

11 月 8 日、 Amazon Location Service は、 Routes 、 Places 、 Maps 機能の能力を拡張および改善する 17 個の強化された新たな API をリリースしました。これにより、開発者にとって総合的かつ効率的なエクスペリエンスが実現します。機能を強化し、移行を簡素化するこれらの更新により、Amazon Location Service は幅広いアプリケーションでさらに利用しやすく、便利になりました。 静的および動的レンダリングオプションを使用して、高度なルート最適化、通行料計算、GPS トレーススナップ、さまざまなマップスタイルにアクセスできるようになりました。また、関心のある地点に関する豊富で詳細な情報を利用して、近接度ベースの検索と予測提案を実行できるようになりました。 Amazon のロードマップの大部分は、お客様からのフィードバックに基づいています。Amazon Location Service を使用してアプリケーションを構築している多くのお客様から、位置情報ベースのデータを扱う際には、専用の API と、連絡先情報や営業時間などのより詳細な情報が必要であるとのご意見が寄せられています。現在の API セットは多くのお客様に貴重なツールを提供してきましたが、開発者は詳細なルートプランニング、近接度ベースの検索、追加の場所の詳細、静的マップ画像などの追加機能を望んでいると表明しています。これらの新しい API は開発者の要求に応え、すぐに使用できるより包括的な位置情報ソリューションを提供します。 新機能と拡張機能 11 月 8 日のリリースでは、お客様のフィードバックに直接応える、10 個の更新された API と 7 個のまったく新しい API を紹介します。Routes、Places、Maps の各サービスには、より幅広いユースケースをサポートできるように設計された、特定の機能強化が施されています。 Routes Amazon Location Routes API は、高度なルートプランニングとカスタマイズオプションをサポートするようになり、ユーザーは次のことができるようになりました。 CalculateIsolines で、特定の移動時間または距離内のサービスエリアを特定する OptimizeWaypoints で最も効率的なウェイポイントの順序を決定し、移動時間または距離を最小限に抑える 通行料を計算して、有料道路を含むルートの正確なコスト見積もりを提供する SnapToRoads で地点を道路網にスナップすることで、GPS トレースを正確に照合する これらの機能により、ユーザーのためにより正確かつ動的なルートエクスペリエンスを設計できます。例えば、物流会社では、ライブ交通量を考慮して配達にかかる交通費を最小限に抑えながら、ドライバーのルートをリアルタイムで最適化できます。 Maps 更新された Amazon Location Maps API には、熟練した地図製作者によって作成された、用途に合ったマップスタイルが含まれています。これらのマップスタイルは、市場投入までの時間を短縮し、カスタムマップ作成の必要性を排除するプロフェッショナルなデザインを提供します。さらに、Static Map Image 機能により、開発者は静的マップをアプリケーション内で統合できるため、継続的なデータストリーミングの必要性が削減され、やりとりが不要なユースケースでのパフォーマンスが向上します。 Maps API の主な機能は次のとおりです。 GetTile で X、Y、Z 軸の値を指定して、タイルセットからタイルをダウンロードする GetStyleDescriptor でスタイルに関する情報を返す GetStaticMap で、レポートや視覚化を目的とした非インタラクティブなマップのレンダリングを可能にする Places Amazon Location Places API の強化によって、より詳細な検索機能が実現され、位置情報データをよりきめ細かいものにしてほしいというリクエストに対応できるようになりました。この新機能には以下のものが含まれます。 SearchNearby と Autocomplete が近接度ベースのクエリをサポートし、予測変換機能を有効にしたことによる、ユーザーエクスペリエンスの向上 関心のある地点の営業時間、連絡先情報、追加属性などのカテゴリを使用したビジネス詳細の強化 これらの機能は、フードデリバリーサービスや小売アプリケーションなど、ユーザーが近くの場所に関する詳細情報を必要とするアプリケーションで特に役立ちます。例えば、顧客がフードデリバリーアプリケーションを開き、 SearchNearby を使用して近くのレストランを検索し、営業時間や連絡先情報などのレストランの詳細を取得して空き状況を確認するとします。複数の配達注文がドライバーに割り当てられると、アプリケーションは OptimizeWaypoints を使用して、最も効率的な集荷および配達のルートを提案します。ドライバーがルートをたどると、 SnaptoRoads がドライバーの位置を正確に視覚化し、顧客によるリアルタイムの追跡体験を向上します。 Enhanced Location Service の実行 API の呼び出しは簡単です。 AWS コマンドラインインターフェイス (AWS CLI) 、当社の AWS SDK のいずれか、またはプレーンな REST API を使用できます。ただし、ウェブアプリまたはモバイルアプリのマップに情報を表示するには、追加の設定が必要です。このプロセスは詳しく説明されていますが、非常に詳細であるため、ここにすべて記載することはできません。このデモでは、API の使用に焦点を当てます。 Amazon Location Service では、API コールを AWS API 認証 ( AWS Sigv4 認証 ) または API キーを介する方法の 2 つの方法で認証できます。API キーは、エンドユーザーが認証されていないモバイルアプリケーションの開発者にとって、または Amazon Cognito との統合が不可能な場合に便利です。これはフロントエンドアプリケーションに推奨される認証方法です。 API の多様性と、アプリケーション内での統合がいかに簡単かを示すために、デモの各ステップで AWS CLI、cURL、グラフィカル REST API クライアントを組み合わせて使用します。 ステップ 1: API キーの作成 まず、AWS CLI を使用してアプリケーションの API キーを作成します。 AWS マネジメントコンソール で API キーを管理することもできます。 REGION=eu-central-1 KEYNAME=geo-key-seb aws location create-key --region ${REGION} --key-name ${KEYNAME} --restrictions \ AllowActions="geo-routes:*","geo-places:*","geo-maps:*",\ AllowResources="arn:aws:geo-routes:${REGION}::provider/default",\ "arn:aws:geo-places:${REGION}::provider/default",\ "arn:aws:geo-maps:${REGION}::provider/default" \ --no-expiry { "Key": "v1.public.ey...cy", "KeyArn": "arn:aws:geo:eu-central-1:02345678901:api-key/geo-key-seb", "KeyName": "geo-key-seb", "CreateTime": "2024-09-29T09:35:53.115000+00:00" } このコマンドによって API キーが生成され、これを使用して Amazon Location API を呼び出すことができます。 ステップ 2: 地理座標の取得 次に、 cURL を使用して GeoCode を呼び出し、 QueryText パラメータに住所を渡すことで、フランスのリール中心部の地理座標 ( 経度 と 緯度 ) を取得します。 $ curl --silent -X "POST" "https://places.geo.eu-central-1.amazonaws.com/v2/geocode?key=v1.public.ey...cy" \ -d $'{ "QueryText": "Grand Place, Lille, France" }' {"ResultItems":[{"PlaceId":"AQ...5U","PlaceType":"Street","Title":"Grand'Place, 59800 Lille, France", "Address":{"Label":"Grand'Place, 59800 Lille, France", "Country":{"Code2":"FR","Code3":"FRA","Name":"France"}, "Region":{"Code":"HDF","Name":"Hauts-de-France"},"SubRegion":{"Name":"Nord"}, "Locality":"Lille","District":"Centre","PostalCode":"59800", "Street":"Grand'Place","StreetComponents":[{"BaseName":"Grand'Place","Language":"fr"}]}, "Position":[3.06361,50.63706], "MapView":[3.0628,50.6367,3.06413,50.63729], "MatchScores":{"Overall":1,"Components":{"Address":{"Country":1,"Locality":1,"Intersection":[1]}}}}]} これにより、市内中心部の GPS 座標 [3.06361, 50.63706] を含む複数のデータポイントが返されます。 ステップ 3: 近くの場所の検索 取得した座標を使用しながら、REST API クライアントツールを利用して SearchNearby API を呼び出し、リール中心部周辺の興味深い場所を見つけます。 画面の右側に、API レスポンスが表示されます。レストラン、銀行、駐車場などの近くの場所のリストです。カテゴリを指定したり、検索範囲を制限したりすることで、さらに検索を絞り込めます。 SearchNearby API では、バウンディングボックス内の検索を制限したり、ビジネスチェーン、カテゴリ、国、食品の種類を含めたり除外したりするのに役立つ、オプションの Filter パラメータを使用できます。 "Filter": { "BoundingBox": [ number ], "ExcludeBusinessChains": [ "string" ], "ExcludeCategories": [ "string" ], "ExcludeFoodTypes": [ "string" ], "IncludeBusinessChains": [ "string" ], "IncludeCategories": [ "string" ], "IncludeCountries": [ "string" ], "IncludeFoodTypes": [ "string" ] }, 近くの関心のある場所を検索したところ、返された結果の 1 つは、国際的に有名なマクドナルドでした 。 ステップ 4: 道順の取得 最後に、AWS CLI を使用して 2 つの市内中心部 (ベルギーの ブリュッセル とフランスの リール ) 間のルートを計算します。 aws location calculate-routes \ --origin 4.35278 50.84687 \ --destination 3.06361 50.63706 \ --key "v1.public.ey...cy" レスポンスには、マップ上にパスをレンダリングするための ポリライン と、ルート案内のステップバイステップリストが含まれます。 ... "TravelMode": "Car", "Type": "Vehicle", "VehicleLegDetails": { "TravelSteps": [ { "Duration": 15, "Distance": 75, "ExitNumber": [], "GeometryOffset": 0, "Type": "Depart" }, { "Duration": 10, "Distance": 8, "ExitNumber": [], "GeometryOffset": 2, "Type": "Turn", "TurnStepDetails": { "Intersection": [], "SteeringDirection": "Right", "TurnIntensity": "Typical" } }, ... ステップ 5: マップでの道順の表示 マップ上のルートを視覚化するには、ウェブアプリケーションやモバイルアプリケーションでマップを表示するためのレンダリングエンジンである MapLibre ライブラリを使用します。 Amazon Location Service デベロッパーガイド の手順に沿って、ルートを表示する基本的なアプリを作成しました。 MapLibre に加えて、 AWS Amplify を使用してアプリケーションに Amazon Location データを統合して表示することもできます。 開始方法 これらの新規および更新された API を使用して、Amazon Location Service はお客様のビジネスニーズに応える、より包括的なマッピングおよびロケーションデータのスイートを提供します。これにより、開発者の俊敏性とスケーラビリティが向上し、開発ライフサイクルが加速されます。 はじめに、更新された Amazon Location Service デベロッパーガイド を確認し、今すぐこれらの機能の統合を開始してください。 Amazon Location Service ページ にアクセスして詳細を確認したり、お気に入りの AWS SDK で API を試して、アプリケーションをどのように強化できるかを確認したりすることもできます。 — seb 原文は こちら です。

11 月 7 日、 Amazon Managed Streaming for Apache Kafka (Amazon MSK) の新しいブローカータイプであるエクスプレスブローカーの一般提供について発表します。Apache Kafka を実行している標準ブローカーと比較して、ブローカーあたりのスループットが最大 3 倍向上し、スケールが最大 20 倍速くなり、復旧時間が 90% 短縮されるように設計されています。エクスプレスブローカーには、デフォルトで Kafka のベストプラクティスが事前設定されており、Kafka API をサポートし、Amazon MSK のお客様が期待するのと同じ低レイテンシーパフォーマンスを提供するため、既存のクライアントアプリケーションを変更することなく引き続き使用できます。 エクスプレスブローカーを使用すると、Amazon MSK でプロビジョニングされたクラスターを使用する際に、Kafka アプリケーションのコンピューティングとストレージの伸縮性が向上します。Amazon MSK は、Apache Kafka をベースにした可用性が高くスケーラブルなアプリケーションを簡単に構築して実行できる、フルマネージド型の AWS サービスです。 エクスプレスブローカーが持つ主な機能と、享受できる利点について詳しく見ていきましょう。 ハンズフリーストレージ管理による運用の簡略化 – エクスプレスブローカーは、事前プロビジョニングなしで無制限のストレージを提供し、ディスク関連のボトルネックを解消します。クラスターのサイズ設定はより単純で、必要なのは入力と出力のスループットをブローカーごとの推奨スループットで割ったものです。これにより、プロアクティブなディスク容量の監視とスケーリングが不要になり、クラスター管理が簡素化され、潜在的な障害の原因が排除されることで耐障害性が向上します。 ブローカーの数が少なく、ブローカーあたりのスループットは最大 3 倍 – ブローカーあたりのスループットが高いほど、同じワークロードでクラスターを小さくできます。標準ブローカーのスループットはクライアントトラフィックとバックグラウンド操作を考慮に入れる必要があります。 m7g.16xl の標準ブローカーは 154 MBps の入力を安全に処理します。エクスプレスブローカーは独自の設定とリソース分離を採用しているため、 m7g.16xl サイズのインスタンスでは、クラスターイベント中にパフォーマンスや可用性を損なうことなく、最大 500 MBps の入力を安全に管理できます。 20 倍の高速スケーリングによる高い使用率 – エクスプレスブローカーはスケーリング中のデータ移動を減らし、標準ブローカーの最大 20 倍の速度を実現します。これにより、より迅速で信頼性の高いクラスターサイズ設定が可能になります。各ブローカーの入力スループットキャパシティを監視し、数分以内にブローカーを追加できるため、トラフィックの急増を見越してオーバープロビジョニングを行う必要がなくなります。 耐障害性が高く、復旧速度が 90% 向上 – エクスプレスブローカーは、高い耐障害性を必要とするミッションクリティカルなアプリケーション向けに設計されています。設定ミスによる障害を減らす 3 つの方法のレプリケーション (RF=3) など、ベストプラクティスがデフォルトであらかじめ設定されています。また、エクスプレスブローカーは、標準の Apache Kafka ブローカーと比較して、一時的な障害からの復旧が 90% 速くなります。エクスプレスブローカーの再調整と復旧は、最小限のクラスターリソースしか使用しないため、キャパシティプランニングが簡素化されます。これにより、リソース使用率が高まるリスクがなくなり、クラスターのサイズを適正化する際に継続的に監視する必要がなくなります。 Amazon MSK では、次のように、ワークロードと好みに応じてオプションを選択できます。 MSK プロビジョンド MSK Serverless 標準ブローカー エクスプレスブローカー 設定範囲 柔軟性が最も高い 柔軟 柔軟性が最も低い クラスターの再調整 カスタマーマネージド カスタマーマネージド ただし、最大で 20 倍速く MSK マネージド 容量管理 はい はい (コンピューティングのみ) なし ストレージ管理 はい なし なし エクスプレスブローカーは、コストを削減し、耐障害性を高め、運用上のオーバーヘッドを抑えることができるため、すべての Kafka ワークロードに最適な選択肢となっています。容量、設定、スケール方法の側面を一切管理せずに Kafka を使用したい場合は、 Amazon MSK Serverless を選択できます。これにより、完全に抽象化された Apache Kafka エクスペリエンスが提供され、インフラストラクチャの管理が不要になり、自動的にスケールされ、リソース利用を最適化する必要のない従量制料金の消費モデルで請求されます。 Amazon MSK のエクスプレスブローカーの開始方法 エクスプレスブローカーを使い始めるには、Amazon MSK が提供する サイズ設定と料金のワークシート を使用できます。このワークシートは、ワークロードに対応するために必要なクラスターサイズを見積もるのに役立ちます。また、発生する月次総コストのおおよその見積もりも得られます。 ワークロードのスループット要件は、クラスターのサイズを決定する主な要因です。クラスターに必要なブローカーのサイズと数を決定するには、パーティションや接続数などの他の要素も考慮する必要があります。例えば、ストリーミングアプリケーションで 30 MBps のデータ入力 (書き込み) と 80 MBps のデータ出力 (読み取り) の容量が必要な場合は、3 つの express.m7g.large ブローカーを使用してスループットのニーズを満たすことができます (ワークロードのパーティション数が、Amazon MSK が m7g.large インスタンスに推奨するパーティションの最大数以内であることを前提とします)。 次の表は、持続可能で安全な運用のための、インスタンスサイズあたりの推奨最大入力数、出力数、およびパーティション数を示しています。これらの推奨事項の詳細については、Amazon MSK デベロッパーガイドの ベストプラクティス セクションをご覧ください。 インスタンスサイズ 入力 (MBps) 出力 (MBps) express.m7g.large 15.6 31.2 express.m7g.4xlarge 124.9 249.8 express.m7g.16xlarge 500.0 1000.0 ワークロードに必要なエクスプレスブローカーの数とサイズを決定したら、 AWS マネジメントコンソール に移動するか、 CreateCluster API を使用して Amazon MSK でプロビジョニングされたクラスターを作成します。 Amazon MSK コンソール で新しいクラスターを作成するときに、 [Broker type] (ブローカータイプ) オプションで [Express brokers] (エクスプレスブローカー) を選択し、そのブローカーに対してプロビジョニングするコンピューティング容量の量を選択します。スクリーンショットでわかるように、エクスプレスブローカーには Apache Kafka 3.6.0 バージョンと Graviton ベースのインスタンスを使用できます。エクスプレスブローカーのストレージを事前にプロビジョニングする必要はありません。 また、これらの設定の一部をカスタマイズして、好みに応じてクラスターのパフォーマンスをさらにファインチューニングすることもできます。詳細については、Amazon MSK デベロッパーガイドの「 エクスプレスブローカーの設定 」を参照してください。 AWS コマンドラインインターフェイス (AWS CLI) で MSK クラスターを作成するには、 create-cluster コマンドを使用します。 aws kafka create-cluster \ --cluster-name "channy-express-cluster" \ --kafka-version "3.6.0" \ --number-of-broker-nodes 3 \ --broker-node-group-info file://brokernodegroupinfo.json brokernodegroupinfo.json という名前の JSON ファイルには、Amazon MSK にブローカーノードを分散させたい 3 つのサブネットを指定します。 { "InstanceType": "express.m7g.large", "BrokerAZDistribution": "DEFAULT", "ClientSubnets": [ "subnet-0123456789111abcd", "subnet-0123456789222abcd", "subnet-0123456789333abcd" ] } クラスターが作成されると、ブートストラップ接続文字列を使用してクライアントをクラスターエンドポイントに接続できます。 エクスプレスブローカーを使用すると、垂直方向にスケール (インスタンスサイズを変更) または水平方向にスケール (ブローカーを追加) できます。垂直スケーリングにより、パーティションを再割り当てしなくてもスループットが 2 倍になります。水平スケーリングではブローカーが 3 つセットで追加され、さらに多くのパーティションを作成できますが、新しいブローカーがトラフィックを処理するにはパーティションを再割り当てする必要があります。 エクスプレスブローカーの主な利点は、数分以内にブローカーを追加してパーティションを再調整できることです。一方、標準ブローカーを追加した後のパーティションの再調整には数時間かかることがあります。以下のグラフは、クラスターに 3 つのエクスプレスブローカーを追加し、各新しいブローカーに 2000 個のパーティションを再割り当てした後に、パーティションの再調整にかかった時間を示しています。 ご覧のように、これらのパーティションを再割り当てして新しいブローカーの追加容量を活用するのに約 10 分かかりました。標準ブローカーで構成される同等のクラスターで同じ実験を行ったところ、パーティションの再割り当てには 24 時間以上かかりました。 パーティションの再割り当ての詳細については、Apache Kafka ドキュメントの「 クラスターの拡張 」を参照してください。 知っておくべきこと エクスプレスブローカーについて知っておくべきことは次のとおりです。 データ移行 – Amazon MSK Replicator を使用して、既存の Kafka または MSK クラスターのデータをエクスプレスブローカーで構成されるクラスターに移行できます。これにより、クラスターのデータとメタデータの両方が新しいクラスターにコピーされます。 モニタリング – クラスター内のエクスプレスブローカーで構成されるクラスターを Amazon CloudWatch メトリクスを使用してブローカーレベルでモニタリングできます。また、Prometheus によるオープンモニタリングを有効にして、JMX エクスポーターとノードエクスポーターを使用してメトリクスを公開できます。 セキュリティ – 他のブローカータイプと同様に、Amazon MSK は AWS Key Management Service (AWS KMS) と統合して、エクスプレスブローカーのストレージを透過的にサーバー側で暗号化します。エクスプレスブローカーを使用して MSK クラスターを作成するときに、Amazon MSK が保管中のデータの暗号化に使用する AWS KMS キーを指定できます。KMS キーを指定しない場合、Amazon MSK が AWS マネージドキーを作成し、ユーザーに代わって使用します。 今すぐご利用いただけます エクスプレスブローカータイプは、11 月 7 日より米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ストックホルム) の各リージョンでご利用いただけます。 エクスプレスブローカーの Apache Kafka ブローカーインスタンスの使用に対して時間単位の料金 (1 秒単位で請求) が発生します。手数料は、MSK クラスター内のブローカーインスタンスとアクティブなブローカーの規模によって異なります。また、エクスプレスブローカーに書き込まれるデータの GB 単位の料金 (バイト単位の解像度で請求) もお支払いいただきます。詳細については、「 Amazon MSK の料金 」ページにアクセスしてください。 Amazon MSK コンソール で Amazon MSK のエクスプレスブローカーをお試しください。詳細については、 Amazon MSK デベロッパーガイド をご覧ください。また、 AWS re:Post for Amazon MSK 宛てに、または通常の AWS サポートの連絡先を通じて、ぜひフィードバックをお寄せください。 – Channy 原文は こちら です。

(本記事は 2024/11/06 に投稿された How チャネルコーポレーション modernized their architecture with Amazon DynamoDB, Part 2: Streams を翻訳した記事です。) この記事は、チャネルコーポレーションの TaeHun Yoon と Changsoon Kim と共同で執筆されました。 チャネルコーポレーション は、 B2B ソフトウェア・アズ・ア・サービス（ SaaS ）スタートアップ企業で、オールインワン AI メッセンジャー「 チャネルトーク 」を運営しています。このシリーズの 第1部 では、 NoSQL 採用の動機、ビジネス成長に伴う技術的問題、そして PostgreSQL から Amazon DynamoDB への移行に関する考慮事項について紹介しました。この投稿では、 DynamoDB だけでは対処できなかった部分を解決するために、他のサービスと統合した経験を共有します。 背景：構造化データと非構造化データの取得問題 リレーショナルデータ設計と NoSQL にはいくつかの重要な違いがあります。 DynamoDB は、定義されたアクセスパターンに対する効率的なデータ取得に優れ、特定のクエリタイプに最適化されたパフォーマンスを提供します。この特徴により、次の チャネルコーポレーション のユースケースは DynamoDB だけでは解決が困難な状況でした。 様々なフィルタリング条件による構造化データの検索（メッセージ検索） – チャネルトーク はユーザーが会話を素早く検索できるようにします。ユーザーは、アサイン先、チーム、フォロワーなどの様々なフィルターを追加して検索することができる必要があります。次のスクリーンショットにその例を示します。 構造化されていないデータの検索（顧客データ検索） – 顧客データは、 チャネルコーポレーション の顧客が入力する情報に応じて異なるスキーマを持ちます。このスキーマは固定されておらず、執筆時点では、複数のフィールドを使用して最大 100 万件の顧客データレコードを迅速に検索できる必要があります。 チャネルコーポレーション は、これら 2 つの問題を解決するために DynamoDB と Amazon OpenSearch Service などの目的別検索サービスを使用する方が効果的で効率的であると判断しました。これを行うには、 DynamoDB と他のサービス間のデータ同期が必要です。 DynamoDB は Amazon OpenSearch Service とのゼロ ETL 統合を持っていますが 、 チャネルコーポレーション は現在、以下の理由で自己管理の ETL パイプラインを使用しています。 検索可能なデータに必要な最小限の情報のみを転送する必要がありました。また、特定の属性の値の変更を無視し、既存の値と現在の値の間の変更を比較する必要がありました 検索サービスで冪等性を確保するため、直接削除するのではなく、論理削除でレコードを変更および挿入する必要な場合がありました DynamoDB とのストリームインテグレーション 時系列に並んだ一連のイベントを ストリーム と呼びます。DynamoDB は、ストリームとして 変更データキャプチャ (CDC) を実行する 2 つの方法を提供します。 Amazon DynamoDB Streams は、DynamoDB テーブル内のアイテムレベルの変更の時系列順のシーケンスをキャプチャし、この情報を最大 24 時間ログに保存します。 Amazon Kinesis Data Streams は、DynamoDB テーブル内のアイテムレベルの変更をキャプチャし、それらを Kinesis データストリームに複製します。 チャネルコーポレーション は、これらのサービスを使用して、DynamoDB の変更データをストリームを介して検索性能の高いサービスに渡すことで、メッセージおよび顧客データ検索の問題を解決できました。 次の図は、DynamoDB Streams を使用したワークフローを示しています。 このソリューションは次の特性を提供します。 DynamoDB Streams からの読み取りは、 AWS Lambda ベースの消費者にとって無料です。 重複が削除された、時系列順のアイテムレベルの変更シーケンスを提供します。 しかし、次の点を考慮する必要があります： Lambda での障害やストリーム処理層での障害を処理する必要があります。 開始位置が LATEST に設定されている場合、 イベントを見逃す可能性 があります。 次の図は、 Kinesis Data Streams を使用したワークフローを示しています。 このソリューションは次の特性を提供します： Kinesis Data Streams と Lambda の両方のコストを含みます 最大 1 年間 のデータ保持期間を設定できます 5 つの開始位置オプション を提供します しかし、次の点を考慮する必要があります： Lambda やストリーム処理層での障害を処理する必要があります 開始位置が LATEST に設定されている場合、イベントを見逃す可能性があります 逆のイベントや重複したイベントが発生する可能性があります これをより詳細に理解するために、データが DynamoDB から各ストリームに渡される方法と、Lambda がストリーム上でどのように操作を実行するかを見てみましょう。 DynamoDB Streams DynamoDB は、各パーティション内の各アイテムに対して行われた変更を対応するシャードに送信し、変更が行われた順序を維持します。このプロセスは、特定のキーが最大 1 つのシャードに存在し、その順序が維持されることを保証にします。 Kinesis Data Streams Kinesis Data Streams のデータレコードは、アイテムの変更が発生したときとは異なる順序で表示される場合があり、同じアイテムの通知がストリームに複数回表示される場合があります。アイテムの変更が発生した順序を識別し、重複したレコードを識別するために、 ApproximateCreationDateTime 属性を確認することができます。 Lambda がストリーム上で処理を実行する方法 イベントソースマッピング は、ストリームおよびキューに基づくサービスからアイテムを読み取り、レコードのバッチで関数を呼び出す Lambda リソースです。イベントソースマッピングを使用して、 Lambda 関数を直接呼び出さないサービスのストリームまたはキューからのイベントを処理できます。 Lambda は DynamoDB Streams から直接呼び出されるのではなく、そのリソースを介して呼び出されることを理解して、各ソリューションと問題の特性に再度アプローチしましょう。 イベントソースマッピング構成の MaximumRecordAgeInSeconds および MaximumRetryAttempts 値を設定することで、基本的な再試行処理を処理できます。ただし、 Lambda コードのバグやデプロイ時の問題など、再試行のみでは解決できない障害が発生する可能性があります。 イベントソースマッピングリソース を参照すると、処理できなかったレコードに関する通知を Amazon Simple Queue Service （Amazon SQS） キューまたは Amazon Simple Notification Service （Amazon SNS） トピックに転送するための On-failure destination 設定を構成できます。次の例は、 DynamoDB ストリームの呼び出しレコードを示しています。 { "requestContext": { "requestId": "316aa6d0-8154-xmpl-9af7-85d5f4a6bc81", "functionArn": "arn:aws:lambda:us-east-2:123456789012:function:myfunction", "condition": "RetryAttemptsExhausted", "approximateInvokeCount": 1 }, "responseContext": { "statusCode": 200, "executedVersion": "$LATEST", "functionError": "Unhandled" }, "version": "1.0", "timestamp": "2019-11-14T00:13:49.717Z", "DDBStreamBatchInfo": { "shardId": "shardId-00000001573689847184-864758bb", "startSequenceNumber": "800000000003126276362", "endSequenceNumber": "800000000003126276362", "approximateArrivalOfFirstRecord": "2019-11-14T00:13:19Z", "approximateArrivalOfLastRecord": "2019-11-14T00:13:19Z", "batchSize": 1, "streamArn": "arn:aws:dynamodb:us-east-2:123456789012:table/mytable/stream/2019-11-14T00:04:06.388" } } 前述の情報に基づき、 DynamoDB Streams からレコードを取得して再試行する必要があります。DynamoDB Streams からレコードを取得して処理する際、すべてのイベントが時系列順に配信されるわけではないため、イベントの順序が乱れる可能性があります。 BatchSize が 1 を超え、一時的な障害により一部のアイテムの処理に失敗した場合、 Lambda は以前に処理されたレコードを含むバッチ全体を再試行します。適切に処理しないと、これにより重複イベントが発生する可能性があります。 さらに、イベントソースマッピングの開始位置が LATEST に設定されている場合、一部のイベントが見逃される可能性があります。 イベントソースマッピング に設定された MaximumRetryAttempts や MaximumRecordAgeInSeconds のような値は、初期設定と異なり、エラー処理や状況に応じて変更する必要があることがあります。この場合、一部のレコードが意図せず見逃される可能性があります。 この問題を解決するために開始位置を TRIM_HORIZON に変更すると、 DynamoDB Streams 内のすべてのデータが最初からイベントコンシューマーに配信され、イベントの重複処理が発生する可能性があります。 DynamoDB Streams と Kinesis Data Streams による問題解決 DynamoDB Streams と Kinesis Data Streams が同様の問題を解決する能力があると信じています。この記事では、次のユースケースについて説明します： すべてのストリーム処理関数を 冪等 に書くことは可能でしょうか？ Lambda 関数で問題が発生したときに再試行することはできますか？ 冪等性 ストリーム処理において最も重要なことの 1 つは、ロジックを冪等に設計することです。受信したイベントを検証し、以前に処理されたかどうかを判断する必要があります。イベントコンシューマーを冪等に書くことで、多くの問題を解決することができます。 例えば、ストリーム内のイベントが乱れた順序で表示される状況を見てみましょう。 前述の図に示すように、イベントの処理順序が不適切なためにデータ整合性が失われる可能性があります。 これを解決するためには、作成、更新、および削除操作で発生するすべてのイベントが時系列順に実行される場合、各状態は同じ最終状態になるため問題はありません。 言い換えれば、現在の最終状態が最新のイベントの結果である場合、前述の問題は簡単に解決できます。 これを実行するために、時刻を表すタイムスタンプが大きい場合にのみ更新が実行されるように実装を再設計しましょう。これにより、現在の状態以降のイベントのみが実行されます。 この場合、順序が乱れた配信が発生しましたが、これは現在の状態ではなく過去のイベントであるため、実行されず、同じ結果値を取得できます。DynamoDB は バージョン番号を使用した楽観的ロック を許可し、アイテムが更新されるたびにバージョン番号が自動的に増加します。更新または削除リクエストは、クライアント側のオブジェクトバージョンが DynamoDB テーブルの対応するアイテムバージョン番号と一致する場合にのみ可能です。この特性を利用すれば、問題を解決できます。 前と同じロジックを実行する場合、作成および更新操作には問題ありませんが、削除に関して問題になるケースがあります。 削除の場合でも、サービス内のレコードに対してハード削除ではなくソフト削除を使用して、イベントの発生順序を強制することで問題を解決できます。たとえば、A が削除され、その削除時刻に関する情報がある場合、その情報を使用してイベントを無視することができます。 障害発生時のリトライ戦略 すべてのロジックが冪等に書かれていることを前提に、問題が発生したときにリトライできるかどうかについて話しましょう。 Kinesis Data Streams と DynamoDB Streams の両方で、 On-failure destination オプションを使用して、過去のデータをストリーム消費者に再配信することができます。しかし、二つのストリームの戦略は異なる場合があります： DynamoDB Streams – DynamoDB Streams は、 イベントソースマッピングの開始位置 に LATEST および TRIM_HORIZON を提供します。特定の時点から再度レコードを取得するには、特定のシャード内の特定のシーケンス番号から目的の時点まで読み取りおよび再処理する別のアプリケーションが存在する必要があります。 Kinesis Data Streams – Kinesis Data Streams は、 イベントソースマッピングの開始位置 に AT_TIMESTAMP を含む 5 つのオプションを提供します。この機能を使用すると、問題が発生する直前のポイントに戻り、イベントソースマッピングのみを更新して再デプロイすることで問題を解決できます。 チャネルコーポレーション の選択 DynamoDB が提供する 2 つのストリームを使用して他のサービスとデータを同期する際に発生する可能性のあるケースについて検討しました。運用上の考慮事項やコストの観点から、特定のストリームを無条件に使用する方が良いとは言い難いです。したがって、 チャネルコーポレーション は特定の基準に基づいて両方のストリームを使用します。 次のユースケースでは、DynamoDB Streams を使用します。 イベントが時系列順に発生することが重要な場合 問題が発生したときにエラー回復コストが高くても良い場合 次のユースケースでは、 Kinesis Data Streams を使用します。 問題が発生したときに特定の時点から迅速に回復することが重要な場合 2 つ以上の Lambda 関数が同時にストリームを処理する必要がある場合 DynamoDB Streams を使用したオンラインスキーマ変更戦略 ストリームの使用のもう 1 つの例として、 チャネルコーポレーション は DynamoDB Streams を使用してオンラインスキーマ変更を実行します。同じアプローチは異なる AWS アカウント間の移行にも使用できます。次の図は、ワークフローを示しています。 このワークフローには次のステップが含まれています。 最初のステップは二つのパートで構成されています DynamoDB に新しいスキーマを持つ新しいテーブルを作成します。 古いテーブルの DynamoDB Streams イベントを消費して新しいテーブルスキーマに変換する Lambda 関数をデプロイします。 Lambda 関数がデプロイされる前の履歴データを読み込み、新しいスキーマに適用します 新しい API サーバーをデプロイします このプロセスにより、スキーマ変更が大幅に行われる場合でも、ライブスキーマ変更を実行できます。ステップ2では、 Amazon EMR 、 AWS Glue 、またはカスタムアプリケーションなど、さまざまな方法で新しいテーブルにデータを入力できます。 特定の時点から新しい DynamoDB テーブルにデータを挿入する必要がある場合、冪等性のために多くのことに注意する必要があります。これを簡素化するために、チャネルコーポレーション は前述の図のようにパイプラインを作成し、既存のすべてのアイテムのバージョンを 1 つ上げます。この場合、変更されたすべてのアイテムが DynamoDB Streams に移動し、Lambda がそれらを新しいスキーマに処理できるため、大きな懸念なしにデータを新しいテーブルに転送できます。 結論 DynamoDB を使用すると、スケーリングがほぼ無限であり、さまざまなダウンストリームサービスとの依存関係が排除されます。 チャネルコーポレーション にとって、 DynamoDB と Kinesis Data Streams の組み合わせは、アプリケーション展開のための堅牢なソリューションを提供します。この組み合わせにより、デプロイメント中に問題が発生した場合でも、特定の時点から迅速に回復できます。その結果、開発者は信頼できるフォールバックメカニズムがあることを知って、いつでも自信を持ってデプロイメントを実行できます。最後に、 DynamoDB のストリーミングオプションのいずれかを活用して、レガシーテーブルを削除し、テーブルを効率的に管理するオンラインスキーマ変更戦略を実装できます。 同様のソリューションを自分のユースケースに実装することを検討し、質問があればコメントセクションに残してください。 著者について TaeHun (Clsan) Yoon は コンピュータエンジニアリングの分野で経験豊富なプロフェッショナルである Channel Corp の最高技術責任者（ CTO ）として革新的なソリューションを牽引しています。チャット体験の向上に注力し、 TaeHun と彼のチームは顧客が直面するさまざまな課題の解決に尽力しています。 Changsoon (CS) Kim は、 Channel Corp の DevOps エンジニアです。開発と運用の間の問題を効率的に解決することに関心を持っています。 Sungbae Park は、 AWS スタートアップチームのアカウントマネージャーであり、 AWS SaaS TFC （Technical Field Communities）のレギュラーメンバーです。現在、 B2B ソフトウェアスタートアップが AWS で成長し成功するのを支援することに注力しています。以前は、 MSP 、 SI 、 ISV パートナーと共に相互成長を促進するパートナーデベロップメントマネージャーとして働いていました。 Hyuk Lee は、韓国に拠点を置くシニア DynamoDB スペシャリストソリューションアーキテクトです。彼は Amazon DynamoDB の機能を使用して顧客のアーキテクチャをモダナイゼーションするのを支援することが大好きです。

こんにちは、プロトタイピング ソリューション アーキテクトの市川です。 2024 年 10 月 30 日に開催された 「IoT@Loft #25 進化する IoT カメラソリューション – 生成 AI で拓く新時代」の内容について紹介させていただきます。 今回の IoT@Loft では i-PRO 株式会社と株式会社 USEN のお客様セッションだけではなく、短い時間ですがデモの展示も行いました。受付後から開始までの時間や、セッション後のネットワーキングの時間をより有意義にできるように初めて取り組みましたが、想像していたよりもデモ展示に興味を持っていただくことができ、大変盛り上がっておりました。 IoT@Loft とは ? 過去の開催ブログ IoT 関連ビジネスで開発を担当するデベロッパーのためのイベントです。IoT の分野は、「総合格闘技」と呼ばれるほど、必要な技術分野が非常に多岐に渡ること、ビジネスモデルが複雑なケースが多いことから、全体を理解することは難しいと言われています。IoT@Loft は、IoT 特有の課題に取り組み、参加者同士の情報共有と意見交換の場を提供することで、参加者の事業や製品開発の成功につながるきっかけを作ることを目指しています。 IoT@Loft #25 では IoT の発展により、カメラやセンサーデバイスが社会のさまざまなシーンで活用され、リアルタイムの映像や各種データを収集できるようになっていることから、データを効果的に活用するため、従来の画像認識や物体検出に加え、生成AIの技術と組み合わせた新たな可能性についてお客様から紹介いただきました。 お客様登壇 生成 AI/IoT ネイティブなカメラを目指して 登壇資料 1 つ目のセッションは i-PRO 株式会社 高橋様と荒井様より、「生成 AI/IoT ネイティブなカメラを目指して」という内容でご登壇いただきました。 i-PRO 株式会社では moduca シリーズ という AI/IoT ネイティブカメラを提供しています。moduca は光学モジュール、 SoC モジュール、インターフェイスモジュールの 3 つを組み合わせることで、用途に適したカメラを作ることができます。現在提供されているモジュールを組み合わせると 1500 通り以上の組み合わせが実現でき、ご自身が必要な機能を持ったカメラを作ることができます。 Linux ベースの OS が動くハードウエアが提供されているため、独自のアプリケーションを開発することで、オリジナルのカメラソリューションとして利用することも可能です。もちろん AWS の SDK を利用することもでき Amazon Kinesis Video Streams にも対応しています。 i-PRO 株式会社ではこのカメラに機械学習のモデルを搭載してエッジ AI アプリケーションを構築することができますが、この機械学習のモデルは何かしら特定の用途のモデルを作成する必要があるため、それなりに開発コストが掛かってしまうことは課題として感じられていたとのことです。 今回のイベントに向けて生成 AI を利用したデモを作成されたとのことですが、カメラで検出した後に、生成AIを利用してカメラに映ったものを判断するデモの作成はわずか 1 週間で完成したそうです。 このデモではビブスを着用しているかの判断を行っていましたが、このように特定なものを判断できる機械学習のモデルを作ろうとすると、それなりの画像が必要となり、精度を上げるための調整にも時間がかかりますが、人物を判定できる AI モデルをカメラで動かし、人を見つけたときだけクラウドに送信し Amazon Bedrock で判断させると、簡単に実現することができたそうです。このように生成 AI を使った新規事業へのアイディアも紹介していただきましたので、ぜひ資料をご覧いただければと思います。 IoT×AI カメラソリューションが拓く店舗 DX の近未来 登壇資料 2 つ目のセッションは、株式会社 USEN の 野村様より、「IoT×AI カメラソリューションが拓く店舗 DX の近未来」という内容でご登壇いただきました。株式会社 USEN と聞いて最初に思い浮かぶのは、お店に流れている音楽のソリューションではないかと思いますが、実際には店舗で必要とされる様々な仕組み( USEN の店舗 DX )をほとんど提供しています。 これらのサービスの中で、カメラを活用した来客の分析などを行なっているのが USEN Camera ですが、映像をクラウドに保存しつつリアルタイムで再生する必要があるが、映像やカメラ操作の遅延が発生することがお客様からのフィードバックとしてありました。 この課題は Amazon Kinesis Video Streams だけではなく他のカメラサービスでも同様の課題を抱えていますが Amazon Kinesis Video Streams WebRTC with Ingestion を使うことで、低遅延化することができそうであることがわかり、実装して見たところ遅延を 1 秒以内に抑えることが確認できたそうです。 この話以外にも現在取り組んでいる仕組みについての話もありましたが、現地の参加者限定での共有でしたので残念ながらご紹介することはできませんが、 株式会社 USEN のサイト に今後登場すると思われます。 AWSセッション 3 つ目のセッションでは、ソリューションアーキテクトの 井上 昌幸 / 宇佐美 雅紀 の 2 名から発表がありました。 登壇資料前半 登壇資料後半 前半は SA の井上より「Amazon Kinesis Video Streams – アップデートとエッジで役立つ構成パターン」と題して Amazon Kinesis Video Streams を紹介しました。 エッジ構成のパターンでは、どのようにデバイスと Amazon Kinesis Video StreamsのStreams を組み合わせると良いのか、それぞれのメリット・デメリットについて話がありました。アップデートでは WebRTC で マルチビューアーのプレビュー が公開されている話があり Ingestion (クラウドへの保存)と組み合わせることで複数のビューアーにリアルタイムで接続しながら、動画を保存することが可能になるとのことでした。 後半は SA の宇佐美より 5 月に開催された AWS Summit Japan で展示されたカメラ＋生成 AI のデモについての紹介がされました。 AWS Summit Japan では多くのデモが展示されており、今回はカメラと生成AIが直接関係するデモのみを紹介しました。この条件を外してデモ全体で見ると、実は裏側で IoT サービスを活用しているものも多く IoT を活用するのは一般化されているなという印象です。紹介いただいたデモは別途ブログでも公開しております。 AWS Summit 2024 で見た IoT の進化！多数のセッションと展示が語る IoT の真価と深化！ ( Industrial IoT 編 ) AWS Summit 2024 で見た IoT の進化！多数のセッションと展示が語る IoT の真価と深化！（ IoT プロダクト編） Raspberry Pi と Web カメラ、生成 AI を使ってショート動画とベストショットを撮影できるカメラスポットを作ってみた！ デモの展示 i-Pro 株式会社 i-PRO 株式会社のデモはセッション内で紹介されていた Amazon Bedrock を利用した検出と通知について紹介されていました。開発したデモだけではなく、複数種類のカメラモジュールも展示されており、非常に小さいことに驚きました。カメラモジュールは Amazon Kinesis Video Streams の認定を獲得しており、 AWS の認定デバイスカタログ にも掲載されております。最後まで多くの人が訪れ、大変賑わっていました。 AWS のデモ Video semantic search using GenAI のデモでは PC のカメラから Amazon Kinesis Video Streams に映像を送信し AWS Lambda がその映像を取り出して Amazon Bedrock でタグ付けを行いその情報を保存します。Web の UI からは文章を入力するとその文章に合致する画像を表示することができ、大量の映像データから欲しいデータを探すユースケースで活用できるデモとなっていました。 生成 AI によるカメラ映像から危険判別 のデモは、監視カメラ映像をと生成 AI を組み合わせて作業員の安全確保を予防・対応両面から支援する 2 つのシナリオをご紹介ています。1 つはカメラ映像と生成 AI を使用して従業員の危険な状況を生成 AI が記述し、状況に応じて警告を出します。もう 1 つは作業員の安全装具の装着状況をカメラ映像から分析してレポートします。このデモは AWS Summit Japan でも展示されており、 詳細な情報はこちらから見ることもできます 。 さいごに IoT のユースケースで少しずつ生成 AI の話も出てきていますが、まだまだ手探りな状況かなと思います。今回のようにすでに試したり、考えられているお客様の話を聞いていると、今後が非常に楽しみな組み合わせと思いました。 IoT@Loft に関しては、今回はセッションと合わせてデモを展示する取り組みを行いました。イベント開始前の時間が有効に使えたり、ネットワーキングの時間では、より具体的なディスカッションが行えているように見えており、アンケートの結果も評価が高かったです。オフラインの開催は現地に行く必要があるのが大変ではありますが、オンラインと違ってより深いコミュニケーションが取れるのが登壇者、参加者どちらにとっても大きなメリットとなっていると思います。次回は来年になると思いますが、より有意義な場となるように改善を続けたいと思います。 関連ウェブサイトのご紹介 AWS IoT 開発者ポータル IoT エンジニア向けに、IoT 関連の国内の事例やセミナーの情報、ハンズオンや学習のためのデジタルコンテンツなどを随時更新しています。ぜひ定期的にチェックしてみてください。 https://aws.amazon.com/jp/local/iot/ 著者について 市川 純 プロトタイピングソリューションアーキテクト AWS では IoT に関連するプロトタイピングを支援する、ソリューション アーキテクトとして、お客様の IoT 関連案件を支援しています。

(本記事は 2024/11/06 に投稿された How チャネルコーポレーション modernized their architecture with Amazon DynamoDB, Part 1: Motivation and approaches を翻訳した記事です。) チャネルコーポレーション は、オールインワン AI メッセンジャー「チャネルトーク」を運営する B2B ソフトウェア・アズ・ア・サービス（ SaaS ）スタートアップです。「顧客と企業の間にあるすべての問題を解決する」というビジョンを掲げ、その第一弾として、顧客と企業間のコミュニケーション問題を解決するためにチャネルトークを開発しました。チャネルトークは、Live チャット相談、チャットボット、音声通話、顧客関係管理 (CRM) 、社内メッセンジャーを統合したソリューションであり、企業と顧客のコミュニケーションを支援しています。韓国、日本、米国を含む 22 カ国で 15 万社以上の企業に利用されており、毎月 7,000 万件以上のコールを処理しています。 この二部構成のブログシリーズは、 RDBMS から NoSQL への移行の動機と考慮事項を提示することから始まります。 第2部 では、 チャネルコーポレーション がストリームを使用して event-driven アーキテクチャを実装する方法について説明します。 この記事では、 チャネルコーポレーション が Amazon DynamoDB を使用してアーキテクチャをモダナイゼーションする動機、 DynamoDB を選択した理由、および Amazon Relational Database Service (Amazon RDS) for PostgreSQL からの移行前に考慮すべき4つの主要なポイントについて説明します。 背景：ビジネス成長と新たな問題の出現 チャネルトーク は当初、チームチャットとユーザーチャットの 2 つのコンポーネントに分かれていました。次のスクリーンショットに示されているチームチャット機能は、チーム内のコミュニケーションをサポートします。 次のスクリーンショットに示されているユーザーチャット機能は、顧客と企業の間のコミュニケーションを助けます。 2018 年以降、ビジネスが毎年 2〜5 倍に成長するにつれて、チャットサービスの1秒あたりのリクエスト数 (RPS) も急速に増加し始めました。以前は Amazon RDS for PostgreSQL を使用してチャットサービスを運用していたため、より高いパフォーマンスが必要な場合はインスタンスタイプをスケールアップしていました。 しかし、キャンペーンメッセージや一度きりのメッセージを送信するマーケティングサービスを開始してから、スケールアップ戦略を変更する必要がありました。キャンペーンメッセージは、顧客が特定のアクションを実行したときにルールに基づいて自動的にメッセージを送信する機能です。例えば、顧客がサインアップしたときにウェルカムメッセージを送信したり、価格ページを閲覧したときに割引クーポンを送信したりします。一度きりのメッセージは、特定の時間にターゲット顧客に一度だけメッセージを送信する機能です。たとえば、現在オンラインの顧客に限定割引クーポンを発行するために使用できます。 今までの チャネルトーク の主なワークロードはチャットベースの 1 対 1 のカスタマーコンサルテーションであったため、ピークトラフィックを予測することは難しくありませんでした。しかし、マーケティングサービスは、顧客がセールイベントを実行したり、多数の顧客に一度きりのメッセージを送信したりすると、複数のテーブルで瞬時に大量のトラフィックスパイクを引き起こすと予想されました。その結果、 チャネルコーポレーション は新しいスケーラブルなデータベースを必要とし、次の 4 つの主要な考慮事項がありました。 コスト効率の悪さ – インスタンスベースのサービスはピークに基づいてインスタンスサイズを選択する必要があり、マーケティングサービスは高い変動性を追加すると予想されました テーブル間の負荷の波及 – 特定のテーブルやサービスの高負荷が RDS インスタンス全体のパフォーマンスに影響を与える可能性があります PostgreSQL で行っていた既存の操作を効率的に実行するためのサポート 要件と許容ダウンタイムに合わせた移行戦略の準備 DynamoDB を選択した理由 上記で記述した 4 つの問題を解決することに加えて、 チャネルコーポレーション は次の 3 つの主要な理由から DynamoDB を選択しました。 他の AWS サービスに event sourcing を実装できる能力、一般的なイベント駆動型アーキテクチャパターン 他の AWS サービスとの豊富なインテグレーション ACID トランザクション 4 つの問題を解決するためのアプローチ マーケティングサービスに関連する最初と第二の問題は、 DynamoDB を選択することで簡単に解決できました。 DynamoDB がオンデマンドキャパシティモードを提供していたため、コスト効率の問題にを柔軟に対応できました。このモードは、以前のピークトラフィックの最大 2 倍まで即座に対応でき、30 分以内に以前のピークの 2 倍を超えない限り対応可能です。また、必要に応じてテーブルを事前にウォームアップすることもできます。さらに、プロビジョンド容量モードでは DynamoDB auto scaling を提供し、安定したワークロードを運用し、過度な利用を防ぐための上限を設定することができました。以下の 2 つの図は、 DynamoDB の user_chat および message テーブルで一度に大量のメッセージが生成される際の書き込みトラフィックパターンを示しています。 第二の問題であるテーブル間の負荷の波及は、 DynamoDB では 1 つのテーブルの負荷が他のテーブルに影響を与えないため、迅速に解決できました。そのため、柔軟なトラフィックを処理しながら、全体のサービスを安定的に運営するためのアーキテクチャを改善することができました。 第三の問題に対処するために、既存の PostgreSQL 操作を DynamoDB で置き換えることが可能かを確認するために、 チャネルトーク チャットの主要機能を検討しました。次のスクリーンショットはこのプロセスを示しています。 チャネルトーク チャットの主な機能は次のように抽象化されます Chat room (Chat) – チャットルームにはメッセージがあります。 Participation information (ChatSession) – 特定のチャットルームでの未読メッセージ数や最後の閲覧時間などの情報が記録されます。 Participation information における未読メッセージ数は ChatBadge と呼ばれます。特定のユーザーが同時に複数のチャットルームに所属することができるため、複数のチャットルームの未読メッセージの合計数は ManagerBadge と呼ばれます。 これらのコンポーネントには別々に動作する 2 つの要件があります： 原子性 – 各チャットルームでメッセージが発生する際、送信者以外の受信者に対して ChatBadge がアトミックに増加します。 カウント – 各チャットルームで発生したすべての ChatBadge の合計が ManagerBadge になります。 以前は PostgreSQL を使用していたため、 ChatBadge はアトミック操作を使用し、 ManagerBadge は単に ChatBadge の合計でした。しかし、ユーザーのチャットルーム数が増加するにつれて、各ユーザーメッセージを送信した後にレコードのアドホックカウントを実行することはスケールが難しいため、パフォーマンスが時間とともに低下する可能性があります。この問題を解決するために、 DynamoDB トランザクション を使用することに決定しました。次のスクリーンショットはテーブル設計変更前の属性を示しています。 次のスクリーンショットは、テーブル設計変更後の属性を示しています。 特定のチャットルームでメッセージが作成されると、送信者を除く各参加者に対して次の操作が実行されます： 参加者の ChatBadge を増加させる UpdateItem を作成します。 参加者の ManagerBadge を増加させる UpdateItem を作成します。 TransactWriteItems API を使用して 2 つの UpdateItem 操作を処理します。 この方法により、 ChatBadge の合計が ManagerBadge となることを保証でき、それぞれを O(1) の時間複雑度でクエリすることができます。もちろん、このアプローチはメッセージが同時に継続的に生成される状況で トランザクションの競合 を引き起こす可能性がありますが、 チャネルトーク の大部分のワークロードがカスタマーコンサルテーションのための 1 対 1 の会話であるため、同時メッセージが発生するケースはあまりありません。さらに、大量のメッセージが同時に発生する場合には、それらを処理する手順があります。 次の図に示すように、競合が発生した場合、 exponential backoff 再試行戦略 を使用します。また、 DynamoDB トランザクションは ClientRequestToken パラメータを使用するときに冪等性をサポートしているため、接続タイムアウトなどの問題で同じ要求が複数回送信された場合でも、 10 分以内に ChatBadge と ManagerBadge を正確に管理することができ、これにより第三の問題が解決されました。 最後に、移行は早朝に API サーバーを停止して行われました。 DynamoDB の 並列スキャン のセグメント化アイデアを参考し、 PostgreSQL ID をハッシュ、各セグメントごとに複数のスレッドを使用して BatchWriteItem API を並列で使用して移行しました。 結論 DynamoDB は、ほぼ無制限のスループットとストレージ、スキーマの柔軟性、event-driven アーキテクチャを可能にする DynamoDB Streams 、および複数のテーブルに対する ACID トランザクションを提供します。 DynamoDB を採用して以来、 チャネルトーク はチャットビジネスエリアで大規模なインフラ変更を行わずに継続的に新しい機能を追加しながらビジネスを運営してきました。DynamoDB を使用することで次のような主要な利点を得ました。 インフラストラクチャやコード構造を改善することなく、新しい機能を継続的に追加することができました。たとえば、ルールに基づいてメッセージを生成するボットの機能など、メッセージの数を急速に増加させる機能がリリースされた場合でも、インフラストラクチャの問題なくサービスを運営することができました。 インスタンスコストなしで使用量に応じてのみ支払う DynamoDB のコストモデルにより、以前は固定費だったデータベースコストを変動費に変えることが容易になりました。トラフィックが減少すると DynamoDB コストも減少するため、ビジネス状況が良くない場合でもコスト削減のためにアーキテクチャを変更する必要がなく、トラフィックが増加しても同様です。 ビジネスエリアが継続的に拡大するにつれて、チャットに加えて チャネルトーク のすべての顧客の使用状況を測定するなど、水平スケーラビリティが必要な領域で DynamoDB を利用してさまざまな問題を解決しています。 シリーズの第 2 部では、 DynamoDB だけでは解決できなかった部分を他のサービスと統合して解決する方法について説明します。 著者について TaeHun (Clsan) Yoon は コンピュータエンジニアリングの分野で経験豊富なプロフェッショナルである Channel Corp の最高技術責任者（ CTO ）として革新的なソリューションを牽引しています。チャット体験の向上に注力し、 TaeHun と彼のチームは顧客が直面するさまざまな課題の解決に尽力しています。 Changsoon (CS) Kim は、 Channel Corp の DevOps エンジニアです。開発と運用の間の問題を効率的に解決することに関心を持っています。 Sungbae Park は、 AWS スタートアップチームのアカウントマネージャーであり、 AWS SaaS TFC （Technical Field Communities）のレギュラーメンバーです。現在、 B2B ソフトウェアスタートアップが AWS で成長し成功するのを支援することに注力しています。以前は、 MSP 、 SI 、 ISV パートナーと共に相互成長を促進するパートナーデベロップメントマネージャーとして働いていました。 Hyuk Lee は、韓国に拠点を置くシニア DynamoDB スペシャリストソリューションアーキテクトです。彼は Amazon DynamoDB の機能を使用して顧客のアーキテクチャをモダナイゼーションするのを支援することが大好きです。

この記事は、「 Implement model-independent safety measures with Amazon Bedrock Guardrails 」を翻訳したものとなります。 生成 AI モデルは幅広いトピックに関する情報を生成できますが、その応用には新たな課題があります。これには関連性の維持、有害なコンテンツの回避、個人を特定できる情報（PII）などの機密情報の保護、ハルシネーション（幻覚）の軽減が含まれます。 Amazon Bedrock の基盤モデル（FM）には組み込みの保護機能がありますが、これらはモデル固有であることが多く、組織のユースケースや責任ある AI の原則に完全に合致しない可能性があります。その結果、開発者は多くの場合、追加のカスタマイズされた安全性とプライバシーの制御を実装する必要があります。このニーズは、組織が複数の FM を異なるユースケースで使用する場合により顕著になります。なぜなら、一貫したセーフガードを維持することが、開発サイクルの加速と責任ある AI への統一されたアプローチの実装に不可欠だからです。 2024 年 4 月、私たちは Amazon Bedrock Guardrails の一般提供を発表しました。これはセーフガードの導入、有害なコンテンツの防止、主要な安全性基準に対するモデルの評価を支援するものです。Amazon Bedrock Guardrails を使用すると、ユースケースと責任ある AI ポリシーに合わせてカスタマイズされた生成 AI アプリケーションのセーフガードを実装できます。複数のユースケースに合わせて複数のガードレールを作成し、それらを複数の FM に適用することで、ユーザーエクスペリエンスを向上させ、生成 AI アプリケーション全体で安全性のコントロールを標準化できます。 さらに、異なる FM を使用するアプリケーションの保護を可能にするために、Amazon Bedrock Guardrails は現在、Amazon Bedrock 外で利用可能なカスタムおよびサードパーティの FM のユーザー入力とモデル応答を評価するための ApplyGuardrail API をサポートしています。この記事では、サードパーティまたはセルフホスト型の大規模言語モデル（LLM）、あるいはセルフホスト型の検索拡張生成（RAG）アーキテクチャなど、一般的な生成 AI アーキテクチャで ApplyGuardrail API を使用する方法について説明します。 ソリューションの概要 この記事では、FM が受託者向けのアドバイスを提供しないようにするガードレールを作成します。ガードレールの完全な設定リストは GitHub リポジトリ をご覧ください。必要に応じてコードを変更できます。 前提条件 Amazon Bedrock Guardrails を使用するための正しい AWS Identity and Access Management（IAM） 権限があることを確認してください。手順については、「 コンテンツフィルタリングにガードレールを使用するアクセス許可を設定する 」を参照してください。 さらに、このウォークスルーで使用するサードパーティまたはセルフホスト型の LLM へのアクセス権が必要です。この記事では、 Amazon SageMaker JumpStart の Meta Llama 3 モデルを使用します。詳細については、「 SageMaker プロジェクトと JumpStart の AWS 管理ポリシー 」を参照してください。 Amazon Bedrock コンソール、Infrastructure as Code（IaC）、または API を使用してガードレールを作成できます。ガードレールを作成するためのサンプルコードについては、 GitHub リポジトリ を参照してください。以下の例で使用するガードレール内に 2 つのフィルタリングポリシーを定義します：ユーザーに受託者アドバイスを提供しないように 拒否トピック と、ソース情報に基づいていないか、ユーザーのクエリに関連しないモデル応答をフィルタリングする コンテキストグラウンディングチェック です。ガードレールのさまざまなコンポーネントの詳細については、「 ガードレールのコンポーネント 」を参照してください。先に進む前にガードレールを作成したことを確認してください。 ApplyGuardrail API の使用 ApplyGuardrail API を使用すると、使用されるモデルに関係なくガードレールを呼び出すことができます。ガードレールは text パラメータに適用されます。以下のコードを参照してください： content = [ { "text": { "text": "Is the AB503 Product a better investment than the S&P 500?" } } ] この例では、ユーザーからの入力全体にガードレールを適用します。入力の特定の部分にのみガードレールを適用し、他の部分を未処理のままにしたい場合は、「 ユーザー入力にタグを適用してコンテンツをフィルタリングする 」を参照してください。 Amazon Bedrock Guardrails 内で コンテキストグラウンディングチェック を使用している場合は、追加のパラメータである qualifiers の導入が必要です。これにより、API にコンテンツのどの部分が grounding_source （根拠となる情報源として利用する情報）、 query （モデルに送信されるプロンプト）、および guard_content （グラウンドソースに対して検証するモデル応答の部分）であるかを伝えます。コンテキストグラウンディングチェックは出力にのみ適用され、入力には適用されません。以下のコードを参照してください： content = [ { "text": { "text": "The AB503 Financial Product is currently offering a non-guaranteed rate of 7%", "qualifiers": ["grounding_source"], } }, { "text": { "text": "What’s the Guaranteed return rate of your AB503 Product", "qualifiers": ["query"], } }, { "text": { "text": "Our Guaranteed Rate is 7%", "qualifiers": ["guard_content"], } }, ] 最後に必要なコンポーネントは、使用するガードレールの guardrailIdentifier と guardrailVersion 、およびテキストがモデルへのプロンプトかモデルからの応答かを示す source です。これは以下のコードで Boto3 を使用して示されています。完全なコード例は GitHub リポジトリ で利用可能です： import boto3 import json bedrock_runtime = boto3.client('bedrock-runtime') # Specific guardrail ID and version guardrail_id = "" # Adjust with your Guardrail Info guardrail_version = "" # Adjust with your Guardrail Info content = [ { "text": { "text": "The AB503 Financial Product is currently offering a non-guaranteed rate of 7%", "qualifiers": ["grounding_source"], } }, { "text": { "text": "What’s the Guaranteed return rate of your AB503 Product", "qualifiers": ["query"], } }, { "text": { "text": "Our Guaranteed Rate is 7%", "qualifiers": ["guard_content"], } }, ] # Call the ApplyGuardrail API try: response = bedrock_runtime.apply_guardrail( guardrailIdentifier=guardrail_id, guardrailVersion=guardrail_version, source='OUTPUT', # or 'INPUT' depending on your use case content=content ) # Process the response print("API Response:") print(json.dumps(response, indent=2)) # Check the action taken by the guardrail if response['action'] == 'GUARDRAIL_INTERVENED': print("\nGuardrail intervened. Output:") for output in response['outputs']: print(output['text']) else: print("\nGuardrail did not intervene.") except Exception as e: print(f"An error occurred: {str(e)}") print("\nAPI Response (if available):") try: print(json.dumps(response, indent=2)) except NameError: print("No response available due to early exception.") API の応答は以下の詳細を提供します： ガードレールが介入したかどうか ガードレールが介入した理由 リクエストに使用されたテキストユニット（Amazon Bedrock Guardrails の完全な価格詳細については、 Amazon Bedrock の料金を参照してください） 以下の応答は、拒否トピックによってガードレールが介入したことを示しています： "usage": { "topicPolicyUnits": 1, "contentPolicyUnits": 1, "wordPolicyUnits": 1, "sensitiveInformationPolicyUnits": 1, "sensitiveInformationPolicyFreeUnits": 0, "contextualGroundingPolicyUnits": 0 }, "action": "GUARDRAIL_INTERVENED", "outputs": [ { "text": "I can provide general info about Acme Financial's products and services, but can't fully address your request here. For personalized help or detailed questions, please contact our customer service team directly. For security reasons, avoid sharing sensitive information through this channel. If you have a general product question, feel free to ask without including personal details. " } ], "assessments": [ { "topicPolicy": { "topics": [ { "name": "Fiduciary Advice", "type": "DENY", "action": "BLOCKED" } ] } } ] } 以下の応答は、コンテキストグラウンディングチェックによってガードレールが介入したことを示しています： "usage": { "topicPolicyUnits": 1, "contentPolicyUnits": 1, "wordPolicyUnits": 1, "sensitiveInformationPolicyUnits": 1, "sensitiveInformationPolicyFreeUnits": 1, "contextualGroundingPolicyUnits": 1 }, "action": "GUARDRAIL_INTERVENED", "outputs": [ { "text": "I can provide general info about Acme Financial's products and services, but can't fully address your request here. For personalized help or detailed questions, please contact our customer service team directly. For security reasons, avoid sharing sensitive information through this channel. If you have a general product question, feel free to ask without including personal details. " } ], "assessments": [ { "contextualGroundingPolicy": { "filters": [ { "type": "GROUNDING", "threshold": 0.75, "score": 0.38, "action": "BLOCKED" }, { "type": "RELEVANCE", "threshold": 0.75, "score": 0.9, "action": "NONE" } ] } } ] } 最初のリクエストへの応答から、金融商品の推奨を求めたユーザーに受託者向けのアドバイスを提供しないようにガードレールが介入したことがわかります。2 番目のリクエストへの応答から、ガードレールが介入し、グラウンドソースの情報から逸脱したモデル応答における、保証利回りの幻想をフィルタリングできたことがわかります。両方のケースで、ガードレールは予想通りに介入し、特定のトピックを避け、ソースに基づいて事実に基づいたモデル応答をユーザーに提供することで、規制要件や社内ポリシーを潜在的に満たすようにしました。 セルフホスト型 LLM での ApplyGuardrail APIの使用 ApplyGuardrail API の一般的なユースケースは、サードパーティプロバイダーの LLM またはセルフホスト型モデルとの組み合わせです。この組み合わせにより、リクエストの入力または出力にガードレールを適用できます。 一般的なフローには以下のステップが含まれます： モデルの入力を受け取ります。 ApplyGuardrail API を使用して、この入力にガードレールを適用します。 入力がガードレールを通過した場合、推論のためにモデルに送信します。 モデルからの出力を受け取ります。 出力にガードレールを適用します。 出力がガードレールを通過した場合、最終出力を返します。 入力または出力のいずれかがガードレールによって介入された場合、入力または出力からの介入を示す、事前定義されたメッセージを返します。 このワークフローは以下の図で示されています。 ワークフローの実装を見るには、提供された コードのサンプル を参照してください。 私たちは Amazon SageMaker エンドポイントでホストされている Meta-Llama-3-8B モデルを使用します。SageMaker で独自のバージョンのこのモデルをデプロイするには、「 Meta Llama 3 models are now available in Amazon SageMaker JumpStart 」を参照してください。 私たちは、 ApplyGuardrail API を SageMaker エンドポイントと統合して保護されたテキスト生成を提供する TextGenerationWithGuardrails クラスを作成しました。このクラスには以下の主要なメソッドが含まれます： generate_text – 入力に基づいてテキストを生成するために、SageMaker エンドポイントを通じて LLM を呼び出します。 analyze_text – ApplyGuardrail API を使用してガードレールを適用するコアメソッドです。API 応答を解釈して、ガードレールを通過したか介入されたかを判断します。 analyze_prompt と analyze_output – これらのメソッドは analyze_text を使用して、入力プロンプトと生成された出力にそれぞれガードレールを適用します。ガードレールを通過したかどうかと関連するメッセージを含むタプルを返します。 クラスは前述の図のワークフローを実装します。以下のように機能します： analyze_prompt を使用して、入力プロンプトをチェックします。 入力がガードレールを通過した場合、 generate_text を使用してテキストを生成します。 生成されたテキストは analyze_output を使用してチェックされます。 両方のガードレールを通過した場合、生成されたテキストが返されます。そうでない場合は、介入メッセージが提供されます。 この構造により、テキスト生成の前後で包括的な安全性チェックが可能になり、ガードレールが介入した場合の明確な処理が可能です。より大規模なアプリケーションと統合するように設計されており、ガードレールの結果に基づいてエラー処理とカスタマイズの柔軟性を提供します。 以下の入力を提供してテストできます： query = "What is the Guaranteed Rate of Return for AB503 Product" grounding_source = "The AB503 Financial Product is currently offering a non-guaranteed rate of 7%" デモンストレーションの目的で、今回は Meta Llama のプロンプトのベストプラクティスに従っていません。実際のシナリオでは、LLM をプロンプトする際にモデルプロバイダーのベストプラクティスに確実に従ってください。 モデルは以下のように応答します： Here is what the Model Responded with: ? The guaranteed rate of return for AB503 product is 4.25% per annum. This rate is guaranteed for the entire term of the investment, which is 5 years. The guaranteed rate of return is based on the performance of the underlying assets and is subject to the creditworthiness of the issuer. What are the Key Features of AB503 Product? The key features of AB503 product are: Guaranteed Rate of Return: 4.25% per annum for 5 years Minimum Investment: $1,000 Maximum Investment: $100,000 Maturity Date: 5 years from the date of investment Interest Payment Frequency: Annually Principal Protection: 100% of the principal amount is guaranteed Credit Risk: The product is issued by a reputable financial institution and is subject to credit risk Liquidity: The product can be redeemed at the end of the term or earlier, subject to certain conditions What are the Risks Associated with AB503 Product? The risks associated with AB503 product are: Credit Risk: The product is issued by a financial institution and is subject to credit risk. If the issuer defaults, you may lose some or all of your investment. Interest Rate Risk: The guaranteed rate of return is fixed and may not keep pace with inflation or changes in interest rates. Liquidity Risk: The product can be redeemed at the end of the term or earlier, subject to certain conditions. If you need to access your funds before the maturity date, you may not be able to do so or may have to sell your investment at a loss. Market Risk: The value of the underlying assets may fluctuate, which could affect the value of your investment. What are the Benefits of AB503 Product? The benefits of AB503 product are: Guaranteed Rate of Return: The product offers a guaranteed rate of return of 4.25% per annum for 5 years, which can provide a predictable income stream. Principal Protection: 100% of the principal amount is guaranteed, which means that you will not lose any of your initial investment. Liquidity: The product can be redeemed at the end of the term or earlier, subject to certain conditions, which can provide flexibility and access to your funds when needed. Diversification: The product can be used as a diversification tool to reduce the risk of your overall investment portfolio. What are the Eligibility Criteria for AB503 Product? The eligibility criteria for AB503 product are: Age: The product is available to individuals これは私たちの質問に対してハルシネーションを含む応答です。ワークフローの出力でこれが示されています。 === Input Analysis === Input Prompt Passed The Guardrail Check - Moving to Generate the Response === Text Generation === Here is what the Model Responded with: ? The guaranteed rate of return for AB503 product is 4.25% per annum. This rate is guaranteed for the entire term of the investment, which is 5 years. The guaranteed rate of return is based on the performance of the underlying assets and is subject to the creditworthiness of the issuer. What are the Key Features of AB503 Product? The key features of AB503 product are: Guaranteed Rate of Return: 4.25% per annum for 5 years Minimum Investment: $1,000 Maximum Investment: $100,000 Maturity Date: 5 years from the date of investment Interest Payment Frequency: Annually Principal Protection: 100% of the principal amount is guaranteed Credit Risk: The product is issued by a reputable financial institution and is subject to credit risk Liquidity: The product can be redeemed at the end of the term or earlier, subject to certain conditions What are the Risks Associated with AB503 Product? The risks associated with AB503 product are: Credit Risk: The product is issued by a financial institution and is subject to credit risk. If the issuer defaults, you may lose some or all of your investment. Interest Rate Risk: The guaranteed rate of return is fixed and may not keep pace with inflation or changes in interest rates. Liquidity Risk: The product can be redeemed at the end of the term or earlier, subject to certain conditions. If you need to access your funds before the maturity date, you may not be able to do so or may have to sell your investment at a loss. Market Risk: The value of the underlying assets may fluctuate, which could affect the value of your investment. What are the Benefits of AB503 Product? The benefits of AB503 product are: Guaranteed Rate of Return: The product offers a guaranteed rate of return of 4.25% per annum for 5 years, which can provide a predictable income stream. Principal Protection: 100% of the principal amount is guaranteed, which means that you will not lose any of your initial investment. Liquidity: The product can be redeemed at the end of the term or earlier, subject to certain conditions, which can provide flexibility and access to your funds when needed. Diversification: The product can be used as a diversification tool to reduce the risk of your overall investment portfolio. What are the Eligibility Criteria for AB503 Product? The eligibility criteria for AB503 product are: Age: The product is available to individuals === Output Analysis === Analyzing Model Response with the Response Guardrail Output Guardrail Intervened. The response to the User is: I can provide general info about Acme Financial's products and services, but can't fully address your request here. For personalized help or detailed questions, please contact our customer service team directly. For security reasons, avoid sharing sensitive information through this channel. If you have a general product question, feel free to ask without including personal details. Full API Response: { "ResponseMetadata": { "RequestId": "6bfb900f-e60c-4861-87b4-bb555bbe3d9e", "HTTPStatusCode": 200, "HTTPHeaders": { "date": "Mon, 29 Jul 2024 17:37:01 GMT", "content-type": "application/json", "content-length": "1637", "connection": "keep-alive", "x-amzn-requestid": "6bfb900f-e60c-4861-87b4-bb555bbe3d9e" }, "RetryAttempts": 0 }, "usage": { "topicPolicyUnits": 3, "contentPolicyUnits": 3, "wordPolicyUnits": 3, "sensitiveInformationPolicyUnits": 3, "sensitiveInformationPolicyFreeUnits": 3, "contextualGroundingPolicyUnits": 3 }, "action": "GUARDRAIL_INTERVENED", "outputs": [ { "text": "I can provide general info about Acme Financial's products and services, but can't fully address your request here. For personalized help or detailed questions, please contact our customer service team directly. For security reasons, avoid sharing sensitive information through this channel. If you have a general product question, feel free to ask without including personal details. " } ], "assessments": [ { "contextualGroundingPolicy": { "filters": [ { "type": "GROUNDING", "threshold": 0.75, "score": 0.01, "action": "BLOCKED" }, { "type": "RELEVANCE", "threshold": 0.75, "score": 1.0, "action": "NONE" } ] } } ] } ワークフローの出力では、入力プロンプトがガードレールのチェックを通過し、ワークフローが応答を生成したことがわかります。次に、ワークフローはユーザーに提示する前にモデル出力をチェックするためにガードレールを呼び出します。そして、コンテキストグラウンディングチェックが介入したことがわかります。これは、モデル応答がグラウンドソースの情報に基づき、事実に基づいていないことを検出したためです。そのため、ワークフローは根拠がなく事実に反すると見なされる応答の代わりに、ガードレールの介入に対して定義されたメッセージを返しました。 セルフマネージド型 RAG パターン内での ApplyGuardrail APIの使用 ApplyGuardrail API の一般的なユースケースは、サードパーティプロバイダーの LLM、またはセルフホスト型モデルを RAG パターン内で適用することです。 一般的なフローには以下のステップが含まれます： モデルの入力を受け取ります。 ApplyGuardrail API を使用してこの入力にガードレールを適用します。 入力がガードレールを問題なく通過した場合、クエリ埋め込みのために埋め込みモデルに送信し、ベクトル埋め込みをクエリします。 埋め込みモデルからの出力を受け取り、それをコンテキストとして使用します。 コンテキストを入力とともに言語モデルに提供して推論を行います。 出力にガードレールを適用し、コンテキストをグラウンディングソースとして使用します。 出力がガードレールを通過した場合、最終出力を返します。 入力または出力のいずれかがガードレールによって介入された場合、入力または出力からの介入を示す定義されたメッセージを返します。 このワークフローは、以下の図で示されています。 図の実装を見るには、 コードのサンプル を参照してください。 例では、LLM に SageMaker でセルフホストされたモデルを使用しますが、これは他のサードパーティモデルでも可能です。 私たちは SageMaker エンドポイントでホストされている Meta-Llama-3-8B モデルを使用します。埋め込みには、voyage-large-2-instruct モデルを使用します。Voyage AI 埋め込みモデルの詳細については、「 Voyage AI 」を参照してください。 私たちは、埋め込み、文書検索の実行、ApplyGuardrail API と SageMaker エンドポイントの統合を行うために TextGenerationWithGuardrails クラスを拡張しました。これにより、文脈に関連する情報を用いてテキスト生成を保護します。クラスには現在、以下の主要なメソッドが含まれています： generate_text – 入力に基づいてテキストを生成するために、SageMaker エンドポイントを使用して LLM を呼び出します。 analyze_text – ApplyGuardrail APIを使用してガードレールを適用するコアメソッドです。API の応答を解釈して、ガードレールを通過したか、介入されたかを判断します。 analyze_prompt と analyze_output – これらのメソッドは analyze_text を使用して、入力プロンプトと生成された出力にそれぞれガードレールを適用します。ガードレールが通過したかどうかと関連するメッセージを含むタプルを返します。 embed_text – 指定された埋め込みモデルを使用して与えられたテキストを埋め込みます。 retrieve_relevant_documents – クエリ埋め込みと文書埋め込み間のコサイン類似度に基づいて最も関連性の高い文書を取得します。 generate_and_analyze – 埋め込み、文書検索、テキスト生成、ガードレールチェックを含むプロセスのすべてのステップを組み合わせた包括的なメソッドです。 拡張されたクラスは以下のワークフローを実装します： まず analyze_prompt を使用して、入力プロンプトをチェックします。 入力がガードレールを通過した場合、クエリを埋め込み、関連文書を取得します。 取得された文書が元のクエリに追加され、拡張クエリが作成されます。 拡張クエリを使用して、 generate_text でテキストが生成されます。 生成されたテキストは、取得された文書をグラウンディングソースとして使用して analyze_output でチェックされます 両方のガードレールが通過した場合、生成されたテキストが返されます。そうでない場合は、介入メッセージが提供されます。 この構造は、テキスト生成の前後に包括的な安全性チェックを可能にすると同時に、文書のコレクションから関連するコンテキストを組み込むことができます。これは以下の目的で設計されています： 複数のガードレールチェックを通じて安全性を強化する。 取得された文書を生成プロセスに組み込むことで関連性を向上させる。 ガードレールの結果に基づいてエラー処理とカスタマイズの柔軟性を提供する。 より大規模なアプリケーションと統合する。 取得する文書の数を調整したり、埋め込みプロセスを変更したり、取得された文書をクエリに組み込む方法を変更したりするなど、クラスをさらにカスタマイズできます。これにより、さまざまなアプリケーションで安全でコンテキストを考慮したテキスト生成を行うための多用途なツールとなります。 以下の入力プロンプトで実装をテストしてみましょう： query = "What is the Guaranteed Rate of Return for AB503 Product?" ワークフローへの入力として以下の文書を使用します： documents = [ "The AG701 Global Growth Fund is currently projecting an annual return of 8.5%, focusing on emerging markets and technology sectors.", "The AB205 Balanced Income Trust offers a steady 4% dividend yield, combining blue-chip stocks and investment-grade bonds.", "The AE309 Green Energy ETF has outperformed the market with a 12% return over the past year, investing in renewable energy companies.", "The AH504 High-Yield Corporate Bond Fund is offering a current yield of 6.75%, targeting BB and B rated corporate debt.", "The AR108 Real Estate Investment Trust focuses on commercial properties and is projecting a 7% annual return including quarterly distributions.", "The AB503 Financial Product is currently offering a non-guaranteed rate of 7%, providing a balance of growth potential and flexible investment options."] 以下はワークフローの出力例です： === Query Embedding === Query: What is the Guaranteed Rate of Return for AB503 Product? Query embedding (first 5 elements): [-0.024676240980625153, 0.0432446151971817, 0.008557720109820366, 0.059132225811481476, -0.045152030885219574]... === Document Embedding === Document 1: The AG701 Global Growth Fund is currently projecti... Embedding (first 5 elements): [-0.012595066800713539, 0.052137792110443115, 0.011615722440183163, 0.017397189512848854, -0.06500907987356186]... Document 2: The AB205 Balanced Income Trust offers a steady 4%... Embedding (first 5 elements): [-0.024578886106610298, 0.03796630725264549, 0.004817029926925898, 0.03752804920077324, -0.060099825263023376]... Document 3: The AE309 Green Energy ETF has outperformed the ma... Embedding (first 5 elements): [-0.016489708796143532, 0.04436756297945976, 0.006371065974235535, 0.0194888636469841, -0.07305170595645905]... Document 4: The AH504 High-Yield Corporate Bond Fund is offeri... Embedding (first 5 elements): [-0.005198546685278416, 0.05041510611772537, -0.007950469851493835, 0.047702062875032425, -0.06752850860357285]... Document 5: The AR108 Real Estate Investment Trust focuses on ... Embedding (first 5 elements): [-0.03276287764310837, 0.04030522331595421, 0.0025598432403057814, 0.022755954414606094, -0.048687443137168884]... Document 6: The AB503 Financial Product is currently offering ... Embedding (first 5 elements): [-0.00174321501981467, 0.05635036155581474, -0.030949480831623077, 0.028832541778683662, -0.05486077815294266]... === Document Retrieval === Retrieved Document: [ "The AB503 Financial Product is currently offering a non-guaranteed rate of 7%, providing a balance of growth potential and flexible investment options." ] 取得された文書は、 ApplyGuardrail API の呼び出しのグラウンディングソースとして提供されます： === Input Analysis === Input Prompt Passed The Guardrail Check - Moving to Generate the Response === Text Generation === Here is what the Model Responded with: However, investors should be aware that the actual return may vary based on market conditions and other factors. What is the guaranteed rate of return for the AB503 product? A) 0% B) 7% C) Not applicable D) Not provided Correct answer: A) 0% Explanation: The text states that the rate of return is "non-guaranteed," which means that there is no guaranteed rate of return. Therefore, the correct answer is A) 0%. The other options are incorrect because the text does not provide a guaranteed rate of return, and the non-guaranteed rate of 7% is not a guaranteed rate of return. Option C is incorrect because the text does provide information about the rate of return, and option D is incorrect because the text does provide information about the rate of return, but it is not guaranteed. === Output Analysis === Analyzing Model Response with the Response Guardrail Output Guardrail Intervened. The response to the User is: I can provide general info about Acme Financial's products and services, but can't fully address your request here. For personalized help or detailed questions, please contact our customer service team directly. For security reasons, avoid sharing sensitive information through this channel. If you have a general product question, feel free to ask without including personal details. Full API Response: { "ResponseMetadata": { "RequestId": "5f2d5cbd-e6f0-4950-bb40-8c0be27df8eb", "HTTPStatusCode": 200, "HTTPHeaders": { "date": "Mon, 29 Jul 2024 17:52:36 GMT", "content-type": "application/json", "content-length": "1638", "connection": "keep-alive", "x-amzn-requestid": "5f2d5cbd-e6f0-4950-bb40-8c0be27df8eb" }, "RetryAttempts": 0 }, "usage": { "topicPolicyUnits": 1, "contentPolicyUnits": 1, "wordPolicyUnits": 1, "sensitiveInformationPolicyUnits": 1, "sensitiveInformationPolicyFreeUnits": 1, "contextualGroundingPolicyUnits": 1 }, "action": "GUARDRAIL_INTERVENED", "outputs": [ { "text": "I can provide general info about Acme Financial's products and services, but can't fully address your request here. For personalized help or detailed questions, please contact our customer service team directly. For security reasons, avoid sharing sensitive information through this channel. If you have a general product question, feel free to ask without including personal details. " } ], "assessments": [ { "contextualGroundingPolicy": { "filters": [ { "type": "GROUNDING", "threshold": 0.75, "score": 0.38, "action": "BLOCKED" }, { "type": "RELEVANCE", "threshold": 0.75, "score": 0.97, "action": "NONE" } ] } } ] } 以下のソース文書の記述により、ガードレールが介入したことがわかります： [ "The AB503 Financial Product is currently offering a non-guaranteed rate of 7%, providing a balance of growth potential and flexible investment options." ] 一方、モデルは以下のように応答しました： Here is what the Model Responded with: However, investors should be aware that the actual return may vary based on market conditions and other factors. What is the guaranteed rate of return for the AB503 product? A) 0% B) 7% C) Not applicable D) Not provided Correct answer: A) 0% Explanation: The text states that the rate of return is "non-guaranteed," which means that there is no guaranteed rate of return. Therefore, the correct answer is A) 0%. The other options are incorrect because the text does not provide a guaranteed rate of return, and the non-guaranteed rate of 7% is not a guaranteed rate of return. Option C is incorrect because the text does provide information about the rate of return, and option D is incorrect because the text does provide information about the rate of return, but it is not guaranteed. これはハルシネーションを示しています。ガードレールが介入し、ハルシネーションされた回答の代わりに定義されたメッセージをユーザーに提示しました。 価格 ソリューションの価格は主に以下の要因に依存します： ガードレールに送信されるテキスト文字数 – 価格の詳細な内訳については、 Amazon Bedrock の価格 を参照してください。 セルフホスト型モデルのインフラのコスト – プロバイダーに依存します。 サードパーティ管理モデルのトークンコスト – プロバイダーに依存します。 クリーンアップ この例でプロビジョニングされたインフラストラクチャを削除するには、 GitHub リポジトリ の手順に従ってください。 結論 ApplyGuardrail API を使用して、生成 AI アプリケーションのセーフガードを FM から切り離すことができます。これで、FM を呼び出さずにガードレールを使用できるようになり、使用されるモデルに関係なく、標準化され徹底的にテストされたエンタープライズレベルのセーフガードをアプリケーションフローにさらに統合できるようになりました。 GitHubリポジトリ のサンプルコードを試して、フィードバックがあれば提供してください。Amazon Bedrock Guardrails と ApplyGuardrail API の詳細については、 Amazon Bedrock Guardrails を参照してください。 翻訳はソリューションアーキテクト菊地が担当しました。 著者について Michael Cho は、AWS のソリューションアーキテクトで、顧客がクラウドでのミッションを加速するための支援しています。彼は顧客に力を与える革新的なソリューションの設計し、構築することに情熱を注いでいます。最近では、複雑なビジネスの問題を解決するために生成 AI を使って実験することに時間を費やしています。 Aarushi Karandikar は、AWS のソリューションアーキテクトで、エンタープライズ ISV の顧客にクラウドジャーニーに関する技術的ガイダンスを提供しています。彼女は UC Berkeley でデータサイエンスを学び、生成 AI の技術を専門としています。 Riya Dani は、AWS のソリューションアーキテクトで、エンタープライズの顧客のクラウドジャーニーを支援しています。彼女は学ぶことに情熱を持ち、Virginia Tech でコンピューターサイエンスの学士号と修士号を取得しています。空き時間には、アクティブに過ごすことと読書を楽しんでいます。 Raj Pathak は、プリンシパルソリューションアーキテクトで、カナダと米国のフォーチュン 50 および中堅 FSI（銀行、保険、資本市場）の顧客の技術顧問です。Raj は、生成 AI、自然言語処理、インテリジェントドキュメント処理、MLOps への応用を含む機械学習を専門としています。

AWS re:Invent 2024 に向けた準備が着々と進む中、11 月 6 日は最新の AWS ヒーロー たちを発表したいと思います! 新しいヒーローたちは、AWS テクノロジーに関する専門知識、そしてこれらのテクノロジーの活用と知識の共有への献身におけるすばらしいお手本です。ヒーローたちの AWS コミュニティへの貢献に心から感謝し、彼らを皆さんにご紹介できるのをとても嬉しく思っています。 Ayyanar Jeyakrishnan 氏 – インド、ベンガルール 機械学習ヒーローである Ayyanar Jeyakrishnan 氏は、Wells Fargo の Principal Engineer/Executive Director です。機械学習とクラウドの経験豊富な愛好家であり、AWS テクノロジーを強く重視する Jeyakrishnan 氏の専門知識には、AWS での機械学習モデルのデプロイと管理を合理化するためのデータプラットフォームの作成と、DevOps および MLOps ソリューションの設計が含まれます。Jeyakrishnan 氏は知識の共有に情熱を注いでおり、業界イベントやコミュニティミートアップで MLOps、生成 AI、機械学習アプリケーションに関する講演を頻繁に行っています。 Dzenana Dzevlan 氏 – ボスニア・ヘルツェゴビナ、サラエボ コミュニティヒーローである Dzenana Dzevlan 氏 は、AllOps Solutions (APN パートナー企業) の共同創設者兼 Technical Manager です。Dzevlan 氏は International Burch University で専門家演習講師を務めており、DevOps、生成 AI、およびその他先進テクノロジーに関する知識を積極的に共有しています。テクノロジーに対する Dzevlan 氏の情熱は教室内だけにとどまらず、クラウドや AI ソリューションに関する学生の指導も活発に行っています。テクノロジーにおける多様性の熱心な提唱者でもあり、業界における女性のインクルージョンとエンパワーメントを支持しています。Dzevlan 氏は、講演やメンターシッププログラムを通じて次世代の IT およびクラウドプロフェッショナルを育成し、彼らのインスピレーションとなっています。 Kenneth Attard 氏 – マルタ、バレッタ コミュニティヒーローである Kenneth Attard 氏 は、マルタを本拠とする Betsson Group の Enterprise Architect です。Attard 氏には 20 年におよぶ技術経験があり、過去 8 年間は AWS クラウドのネットワーク、セキュリティ、およびガバナンスを専門としてきました。AWS Malta User Group のリーダーであり、Malta AWS Community Day の主催者でもある Attard 氏は、クラウド愛好家や専門家の間での知識の育成と学習に情熱を注いでいます。また、現地イベントと国際イベントの両方で頻繁に講演を行っており、これには複数の国で行われた AWS Cloud Day、AWS Summit、および AWS Community Day が含まれます。 Marcin Sodkiewicz 氏 – ポーランド、ヴロツワフ サーバーレスヒーローである Marcin Sodkiewicz 氏 は、Ryanair の Principal Software Engineer です。2016 年に入社した Sodkiewicz 氏は、データセンターからクラウド、そしてサーバーレスファーストの考え方に基づいて構築するチームへの目覚ましい技術的飛躍の一端を担いました。その間、Sodkiewicz 氏は多くのことを見て学びましたが、特に学んだのは、クラウドが高品質かつスケーラブルで信頼性と収益性を備えたソフトウェアの迅速な提供にもたらす違いです。「誰もが手頃な価格で旅行できるようにする」ことを使命とする格安航空会社で働いていることから、Sodkiewicz 氏にとって収益性は非常に重要です。これは、競争上の優位性を実現するコスト最適化されたソリューションの構築への関心と一致しています。Sodkiewicz 氏は、イベント駆動型およびサーバーレスアーキテクチャ、レジリエンシー、コスト最適化、オブザーバビリティといったお気に入りのトピックの視点から、AWS についてブログ記事を書いたり語ったりしています。また、Sodkiewicz 氏が住む街であるヴロツワフでの AWS User Group 主催者の一人でもあります。 Stephen Sennett 氏 – オーストラリア、メルボルン コミュニティヒーローである Stephen Sennett 氏 は、オーストラリアを本拠とする Kinetic IT の Senior Consultant です。経験豊富なクラウドテクノロジストである Sennett 氏は、アーキテクト、コンサルタント、エンジニア、および教育者として 10 年以上もの間 AWS と連携してきました。2021 年から 2024 年にかけて AWS コミュニティビルダープログラムのメンバーであった Sennett 氏は、AWS コミュニティのその他メンバーのメンターを務めるとともに、AWS New Voices プログラムを通じて将来のソートリーダーのパブリックスピーキングコーチも務めました。Sennett 氏は熟練の基調講演者でもあり、AWS Community Day、AWS Summit、および世界中のその他技術カンファレンスでセッションを行っています。プロフェッショナルとしての役割以外にも、現役のボランティア緊急管理官、および非営利団体の役員を務めています。 Vadym Kazulkin 氏 – ドイツ、ボン サーバーレスヒーローである Vadym Kazulkin 氏 は、ip.labs GmbH (富士フイルムの子会社) の Head of Development であり、20 年以上におよぶ Java エコシステムの専門知識を携えています。現在は、拡張性に優れた AWS クラウドアプリケーションの設計と実装に焦点を当てており、サーバーレスアーキテクチャに情熱を傾けています。Java User Group Bonn ミートアップの共同主催者として、Kazulkin 氏は AWS ミートアップや Java ミートアップ、カンファレンス、AWS Community Day、ServerlessDay などの現地イベントや国際イベントで知識を積極的に共有しています。Kazulkin 氏は、クラウドテクノロジーとサーバーレステクノロジーに関するインサイトの共有と継続的な学習の両方において、コミュニティエンゲージメントを大切にしています。 詳細をご覧ください AWS ヒーロープログラムの詳細を知りたい、またはお近くのヒーローとつながりたい場合は、 AWS ヒーローのウェブサイト にアクセスしてください。 – Taylor 原文は こちら です。

本記事は、2024/11/7 に公開された Amazon OpenSearch Service launches the next-generation OpenSearch UI を翻訳したものです。翻訳は Solutions Architect の山下が担当しました。 Amazon OpenSearch Service は、 複数のデータソース にわたる包括的な可観測性を実現する、最新の運用分析機能をリリースしました。これにより、OpenSearch や他の統合されたデータソースから一括でインサイトを得ることができます。このリリースでは、メジャーなユースケースに合わせた体験を提供し、アクセス制御をサポートする OpenSearch Workspaces も導入されました。これにより、ユースケースに応じたプライベートスペースを作成し、コラボレーターだけと共有することが可能です。次世代のユーザーインターフェース（UI）では、 Discover 機能が改善され、インタラクティブな分析が簡素化されました。自然言語クエリ生成などの機能を利用して、簡単にデータからインサイトを得ることができます。 Multiple Data Source： みなさんはすでに OpenSearch Dashboards を使用して、OpenSearch クラスターの運用や分析をしているかもしれません。OpenSearch Dashboards はクラスターと同じ場所に配置されているため、各 OpenSearch Dashboards は 1 つのクラスターでしか動作できません。そして、複数のクラスターにワークロードをスケールアップすると、一箇所でデータを統一的に分析することはできません。それに対して、次世代 OpenSearch UI は複数の OpenSearch クラスターで動作するよう設計されており、一箇所で包括的なインサイトを集約できます。OpenSearch アプリケーションは、次世代 OpenSearch UI のインスタンスです。現在、OpenSearch アプリケーションは、複数の OpenSearch クラスター（バージョン 1.3 以降）、Amazon OpenSearch Service Serverless コレクション、および Amazon S3 などの統合データソースと関連付けることができます。各 OpenSearch クラスターは、クラスター内で動作する従来の OpenSearch Dashboards に加えて、複数の OpenSearch アプリケーションと関連付けることが可能です。 Workspace： Workspaces では、ユースケースに特化したコンテンツをプライベートスペースで簡単に作成でき、チームコラボレーション時には権限管理も行えます。Workspaces は、「Observability」「Security Analytics」「Search」などの人気ユースケース向けにキュレーションされた体験を提供し、それぞれに適したコンテンツ作成が容易になります。また、Workspaces ではコラボレーター管理もサポートしており、意図したコラボレーターだけと共有でき、それぞれのコラボレーターごとの権限管理も可能です。 Discover： 改善された Discover 機能は、既存の DQL および Lucene のサポートに加えて、SQL や Piped Processing Language（PPL）のサポートを追加し、統一されたログ探索体験を提供します。Discover には、複数のデータソースをサポートする新しいデータセレクター、新しいビジュアルデザイン、クエリの自動補完機能、および自然言語によるクエリ生成が搭載されており、使いやすさが向上しています。強化された Discover インターフェースにより、ツールを切り替えることなく複数のソースからデータを分析できるため、複雑さが軽減され、効率が向上します。 ソリューション概要 以下は、OpenSearch Dashboards のアーキテクチャを示す図です。 以下は、次世代 OpenSearch UI のアーキテクチャを示す図です。 以下のセクションでは、次のトピックについて説明します。 アプリケーション作成のプロセス 新しい Workspaces 機能の設定と使用方法 強化された Discover 体験 これらの改善が、データ分析を効率化し、コラボレーションを促進し、さまざまなユースケースでインサイトをより効率的に引き出す方法を紹介します。 アプリケーションを作成する 次世代 OpenSearch UI を使用するには、まずアプリケーションを作成します。アプリケーションは OpenSearch UI（Dashboards）のインスタンスであり、1 つのアカウント内で複数のアプリケーションを作成する柔軟性があります。新しいアプリケーションを作成するには、以下の手順を完了してください。 Amazon OpenSearch Service コンソールで、ナビゲーションパネル内の「Central management」から「 OpenSearch UI (Dashboards) 」を選択します。 「 Create application 」を選択します。 アプリケーション名を入力します。 AWS Identity and Access Management （IAM）がデフォルトの認証メカニズムです。オプションとして「 Authentication with IAM Identity Center （IDC）」を選択し、既存の ID プロバイダーのクレデンシャルとアクセス管理を使用してユーザーアクセスを管理できます。 OpenSearch アプリケーション管理者には、このアプリケーション設定を更新または削除する権限を持つ IAM プリンシパルまたは IDC ユーザーを指定します。このユーザーは管理者として自動的に設定されます。 このページには、現在の AWS リージョン内でアカウントに関連付けられているすべての既存アプリケーションが一覧表示されます。このページから新しいアプリケーションを作成できます。 このページはアプリケーション作成のワークフローです。ここでアプリケーション名を指定し、IDC の有効/無効化を設定し、アプリケーション管理者を定義してアプリケーションを作成できます。 設定を完了してアプリケーションを作成すると、新しい OpenSearch アプリケーションをデータソースと関連付け、強化された UI 機能を使用する準備が整います。 データソースの関連付け OpenSearch アプリケーションを作成した後、次に行うステップはデータソースを関連付けることです。これにより、アプリケーションを必要な OpenSearch ドメイン、コレクション、その他のデータソースに接続できます。 アプリケーションの詳細ページで「 Manage data sources 」を選択します。 ドメインやサーバーレスコレクションを含む、アクセス可能なすべての OpenSearch データソースのリストが表示されます。 このアプリケーションに関連づけたいデータソースを選択します。 バージョン 1.3 未満の OpenSearch ドメインは次世代 UI と互換性がないため、リスト内でグレーアウトされます。さらに、仮想プライベートクラウド（VPC）内のドメインに接続する必要がある場合は、セキュリティ設定で OpenSearch アプリケーションを新しいプリンシパルとして承認する必要があります。VPC 内のコレクションに接続する必要がある場合は、そのネットワークポリシーを プライベート に設定し、OpenSearch アプリケーションとの AWS サービスプライベートアクセス を有効にする必要があります。 「 Save 」を選択して、データソースの関連付けを完了します。 これで、OpenSearch アプリケーションは接続されたデータへのアクセスが可能になり、準備が整いました。 OpenSearch アプリケーションの操作 OpenSearch アプリケーションにアクセスするには、アプリケーション URL を選択するか、アプリケーション詳細ページで「 Launch application 」を選択してください。IAM または IDC で正常にログインすると、アプリケーションのホームページに移動します。ここから、新しいワークスペースを作成するか、アクセス権限のある既存のワークスペースに移動できます。 新しいワークスペースを作成する ワークスペースは、ユースケースやチームコラボレーションに合わせた体験を提供します。ワークスペースには 5 つの種類（Observability、Security Analytics、Search、Essentials、Analytics）があります。それぞれのワークスペースタイプについて詳しく知りたい場合は、インフォメーションボタンをクリックしてください。既存のワークスペースはホームページに一覧表示されます。新しいワークスペースを作成するには、以下の手順を完了してください。 「 Create workspace 」を選択します。 ワークスペースの名前を入力します。 オプションとして、識別しやすいようにワークスペースアイコンの色を変更できます。 作成したいワークスペースの種類（ Observability、Security Analytics、Search、Essentials、Analytics ）を選択します。 このワークスペースに少なくとも 1 つのデータソースを追加します（事前にアプリケーションに関連付けたデータソースから選択します）。 以下の画像は、「MyWorkspace」という名前の Observability ワークスペースを作成し、 Amazon OpenSearch Serverless コレクション 1 つと Amazon OpenSearch Service マネージドクラスター 1 つを関連付けた例です。ワークスペースが作成された後でも、関連付けられたデータソースを常に管理できます。 コラボレーターを招待する 新しいワークスペースを作成した後、一緒に作業したいユーザーやグループをコラボレーターとして追加することができます。コラボレーターには、 管理者（admin） 、 読み取り/書き込み（read/write） 、 読み取り専用（read-only） の 3 つの権限レベルがあります。読み取り/書き込み権限を持つコラボレーターは、ワークスペース内のダッシュボード、ビジュアライゼーション、および保存されたクエリを作成、編集、および削除できます。一方、読み取り専用のコラボレーターは結果を閲覧するだけです。管理者レベルでは、読み取り/書き込み権限に加え、ワークスペースの設定を更新したり削除したりすることも可能です。 ワークスペースにコラボレーターを追加するには、以下の手順を完了してください。 ナビゲーションパネルで「 Collaborators 」を選択します。 「 Add collaborators 」を選択します。 コラボレーターとして追加したいユーザーの種類を選択します。IAM Amazon Resource Name (ARN) または IDC ユーザー名でコラボレーターを追加できます。 コラボレーターに付与する権限レベルを、 読み取り専用（Read only） 、 読み取り/書き込み（Read and write） 、 管理者（Admin） の 3 つのオプションから選択します。 追加したいコラボレーターの ARN がわからない場合は、ARN を確認するための指示に従ってください。 改善されたナビゲーション Workspaces の改善されたナビゲーションは、よりコンテキストに沿った目的別のインターフェースを提供し、各 Workspace にはそのユースケースに関連するツールや機能のみが含まれるようになっています。明確さが向上し、より整理された新しいナビゲーションシステムにより、必要な機能を素早く見つけることができるため、生産性が向上し、メニューを探し回る時間が最小限に抑えられます。 改良された Discover 体験 Discover は、使いやすさと効率性を向上させるために刷新されました。複数のデータソースへのアクセス、自然言語によるクエリ生成、新しいデータセレクター、最適化されたデータ密度を備えた洗練されたデザインにより、データのナビゲートと分析が簡単に行えます。 統一された言語セレクター： Discover では統一された言語セレクターが提供されており、SQL、PPL、Dashboards Query Language（DQL）、または Lucene から選択できるようになりました。これにより、お好みのクエリ言語を 1 つの場所で便利に使用できます。 自然言語によるクエリ生成： Discover では PPL 向けの自然言語によるクエリ作成がサポートされています。質問をプレーンテキストで入力すると、Discover がそれを PPL 構文に変換し、データ探索がより簡単でアクセスしやすくなります。この新機能により、異なるスキルレベルのユーザーがインサイトを得られるようになります。 強力なクエリ自動補完機能： 強化されたクエリバーには自動補完機能と自然言語によるクエリ生成サポートが含まれており、入力中に関連する提案を提供することでクエリ作成を簡素化します。これにより、複雑なクエリを書く時間が短縮され、効率が向上します。 新しいデータセレクター： 新しいデータセレクターは複数のデータソースへの接続を簡単にし、Amazon OpenSearch Service ドメインやサーバーレスコレクション、および Amazon S3 からのデータを統一ビューで表示できるようにします。 結論 この投稿では、次世代 OpenSearch UI の機能について説明しました。これらの改善により、データ分析が効率化され、コラボレーションが促進され、多様なユースケースにおいてインサイトをより効率的に引き出せるようになります。 現在、米国東部（北部バージニア）、米国西部（北カリフォルニア、オレゴン）、アジアパシフィック（ムンバイ、シンガポール、シドニー、東京）、南米（サンパウロ）、ヨーロッパ（フランクフルト、アイルランド、ロンドン、パリ）、およびカナダ（中央）リージョンで OpenSearch UI アプリケーションを作成することができます。 著者について Hang (Arthur) Zuo は、Amazon OpenSearch Service のシニアプロダクトマネージャーです。Arthur は、次世代 OpenSearch UI のコアエクスペリエンスと Amazon OpenSearch Service へのデータマイグレーションを担当しています。彼はクラウド技術に情熱を持ち、ユーザーやビジネスが実用的なインサイトを得て、運用の卓越性を達成できるようなデータ製品の構築に取り組んでいます。 Rushabh Vora は、Amazon Web Services の OpenSearch プロジェクトにおけるプリンシパルプロダクトマネージャーです。Rushabh は、データ探索、ダッシュボード、可視化、レポート、およびデータ管理におけるコアエクスペリエンスをリードし、組織が大規模にインサイトを引き出せるよう支援しています。彼はクラウド技術に情熱を持ち、ビジネスがデータ駆動型の意思決定を行い、運用の卓越性を達成できる製品の構築に取り組んでいます。 Sohaib Katariwala は、シカゴ（イリノイ州）を拠点とする Amazon OpenSearch Service 担当の AWS シニアスペシャリストソリューションアーキテクトです。彼はデータと分析全般に興味があり、特にお客様が AI をデータ戦略に活用して現代の課題を解決する手助けをすることが大好きです。 Arun Lakshmanan は、シカゴ（イリノイ州）を拠点とする Amazon OpenSearch Service の検索に関するスペシャリストです。彼はベクター検索、可観測性、セキュリティ分析などさまざまなユースケースで、お客様の OpenSearch 導入をサポートしています。 Xenia Tupitsyna は、OpenSearch の UX デザイナーです。彼女はセキュリティ分析ソリューション、不正検出、アラート、およびコアダッシュボード全般にわたるユーザー体験向上に取り組んでいます。

みなさん、こんにちは。事業開発統括本部、ソリューション事業開発本部、SaaS 領域の事業開発をしている三石です。 アマゾン ウェブ サービス ジャパン合同会社は、ソフトウェア企業への支援プログラム「 AWS SaaS 支援プログラム」の提供を開始します。ソフトウェア企業に限らず、エンタープライズ企業や地方企業が、SaaS 事業を開始、強化できる支援メニューを提供し、国内企業の SaaS ビジネス展開を強力に後押しします。 本ブログでは、2024年11月13日に開催した記者説明会の様子をご紹介します。 AWS からのプログラムご紹介 アマゾン ウェブ サービス ジャパン合同会社（以下、AWS）は、パッケージソフトウェアを SaaS モデルに変革する SaaSification を検討されているソフトウェア企業、事業会社に対して、AWS SaaS 支援プログラムを提供いたします。 プログラムへの相談、申し込みはこちらから＝＞ Link AWS SaaS 支援プログラムは、ビジネス面・技術面の双方から支援をします。 大きく３つのフェイズにわけ、フェイズごとに異なる課題を整理し、必要な支援プログラムをご用意しています。３つのフェイズは、「始める」「作る」「拡大する」です。まず一つ目は「SaaS をはじめる」、Migrate to AWS は、パッケージでの提供から、SaaS でのビジネスへの移行フェーズです。パッケージソフトウエアを保有し、SaaS 移行を検討している企業向けのプログラムです。これによって、SaaS を始めることができます。次に２つ目は「競争力のある SaaS をつくる」、Innovate with AWS です。すでにクラウドで構築している、自社の SaaS 製品の競争力を強化するプログラムです。最後に３つ目は「SaaS ビジネスを拡大する」、Scale with AWS では、SaaS販売のマーケットプレイスである AWS Marketplace を活用したり、海外進出を支援する AWS Global Passport のプログラムを提供します。 AWS SaaS 支援プログラムは、SaaS ジャーニーを一気通貫で支援、「はじめる」「つくる」「拡大する」を伴走いたします。 SaaS を企画し、クラウドへ移行するフェーズから、設計・構築、そして改善・強化、最終的には、スケーリングできる Go-to-Market 戦略まで、SaaS ビジネスを行う方々の課題解決に必要な支援を提供していきます。支援の中には、SaaS ビジネスを始める際に行う、システムの移行であったり、その後のモダナイゼーションにおいて発生するコストを支援する、クレジットプログラムもあります。また、コミュニティ活動の例としてはSaaS ビジネスに関わる、ビジネスとテクノロジーにかかる情報をまとめてインプットできる集合研修「SaaS Boot Camp」 、Chief Product Officer 向けの AWS CPO Forum などを開催します。 Migrate to AWS：SaaS 移行計画の策定支援 SaaSification（SaaS 化）ができていない企業は、ビジネス観点での検討が不十分であったり、経験者が少なく、移行計画が立案できない、ということがあります。 こうしたお悩みや、ニーズにお応えできるよう、移行計画の策定支援いたします。AWS は、数多くのパッケージ企業の SaaS への移行を支援してきたノウハウをまとめた　SaaS Journey Framework があります。このフレームワークを活用して SaaS 移行計画の立案を支援いたします。今では、生成 AI を取り込んだサービスを開発したいという課題もご支援して参ります。 Innovate with AWS：競争力のある SaaS をつくる AWS は、SaaS 企業のシステムのモダナイゼーションを支援します。例えば、生産性の向上として、コンテナ化により、1人あたり管理可能な、SaaS 提供インフラのコストを低減することができます。サーバレスアーキテクチャーの採用で、インフラコストをさらに39%を削減できる、などのメリットが報告されています。 Scale with AWS： SaaSビジネスを拡大 １つ目は、AWS Marketplace です。 AWS Marketplace は、 SaaS の販売プラットフォームとして注目されています。これまでは販売価格はドル建てになっていましたが、個別の見積もりを行うプライベートオファーを利用することで、日本円での取引が可能になりました。円建てでの見積・契約が可能になったことにより、日本企業の AWS Marketplace の利用が進んでいます。一方で、海外に販売することも可能な販路です。国内・海外、どちらの Go-To-Market 戦略にも、この AWS Marketplace への出品をご支援します。 ２つ目は、AWS Global Passport です。このプログラムによって、ソフトウェア企業の海外進出を支援します。具体的には、プログラムを通して、海外進出支援の専門コンサルティング企業と連携して戦略立案・実行を支援いたします。さらに、初めて利用する AWS の海外リージョン利用料に対して、クレジットを提供します。グローバルに販路をもつ、AWS が世界で推進しているプロジェクトです。ぜひ一緒に日本から世界に販売をしていきたいと思います。 プログラムへの相談、申し込みはこちらから＝＞ Link プログラムで支援しているお客様のご登壇 2024年11月13日に開催した発表会当日は、３社にご登壇いただきました。 株式会社Works Human Intelligence　最高戦略責任者（CSMO）兼 Partner Div.統括　髙橋 総一郎 様 主に、Migrate to AWS と Innovate with AWS のお客様事例としてご登壇いただきました。 膨大なソースコードを持つ大規模システムを2027年に全顧客を SaaS 移行する取り組みや、AWSとの連携事例、生成AIにおけるプロトタイピング支援など包括的な取り組みをご紹介 株式会社ソラコム　CTO 兼 CEO of Americas　安川 健太 様 Scale with AWS のお客様事例として海外展開の観点からご支援例をご紹介いただきました。 日本のみならず、海外でも AWS との営業連携をどのように推進しているか、AWS Global Passport 事例についてもご紹介いただきました。 株式会社デジタルキューブ　代表取締役社長　小賀 浩通 様 地方企業でありながら、Innovate with AWS とScale with AWS を通じて、AWS を利用して企業価値を高めている企業の例としてご登壇いただきました。 地方企業ながら AWS を利活用し地方企業の未来を支援してゆく、地方企業こそクラウドのテクノロジーを活用して地域発のイノベーションを実現したいとご紹介いただきました。 左から、アマゾン ウェブ サービス ジャパン合同会社 佐藤 有紀子、株式会社Works Human Intelligence 髙橋 総一郎 様、株式会社ソラコム 安川 健太 様、株式会社デジタルキューブ 小賀 浩通 様 ご登壇いただきました高橋様、安川様、小賀様ありがとうございました。 参加したメディア各社からも活発な質疑交換が行われ、日本における SaaS の重要性がますます高まり、期待が寄せられることを確認しました。 プログラムへの相談、申し込みはこちらから => Link

本ブログは、IQVIA サービシーズ ジャパン合同会社 と Amazon Web Services Japan が共同で執筆しました。 IQVIA は、データ・テクノロジー・高度な分析・ 専門性を駆使することにより、 ヘルスケアや人々の健康の進展に取り組むお客様をご支援するグローバルリーディングカンパニーです。 お客様とともに、 近代的なそして効果的かつ効率的なヘルスケアシステムの実現を重ねていくことによって、 ビジネスと患者さんの治療アウトカムを変革する画期的なソリューションを生み出しています。 抱えていた課題 IQVIA サービシーズ ジャパンでは、臨床試験や市販後調査（PMS）、医薬品関連文書の作成等の業務において、日本における医薬品の臨床試験の実施の基準に関する省令や治験業務を行う上での規制のように一般に公開されているドキュメントの内容を確認する必要がたびたび発生します。それらの症例や規制の内容について疑問がある場合にはガイドブックやウェブで公開されている情報を元に手作業で調査を行っていましたが、この調査に時間がかかることが課題になっていました。 また、実際の薬品の開発のプロセスで行われる臨床試験のプロジェクトの中でも情報の検索・調査が課題になっていました。 プロジェクトには、臨床試験が適切に実施されているかを監視する役割である臨床開発モニターが大規模なプロジェクトで数十人といった規模で参加します。そのプロジェクトの中で行われた質疑応答については、Q&A の形で社内に蓄積しておき、臨床開発モニターがその Q&A を調べることでプロジェクトに関する情報を確認することがあります。ただし、この Q&A は膨大な数になるため人手での調査には多くの時間を消費しており、平均して 月合計 204 時間を費やしていました。 上述のように多数の業務中の情報確認のための検索・調査に費やす時間が多大にかかっていることに加えて、人によって必要な情報にたどり着くまでのスキルに差異があり、慣れていないメンバーではかなりの時間をこの調査にかけてしまっている場合もありました。 ソリューション 調査効率の向上のために、IQVIA サービシーズ ジャパンでは Amazon Bedrock のナレッジベースを用いた RAG(Retrieval-Augmented Generation) ベースの AI チャットソリューションを構築しました。Amazon Bedrock のナレッジベースは、データソースへのカスタム統合を構築してデータフローを管理することなく、取り込みから取得、迅速な拡張まで、RAG ワークフロー全体を実装するのに役立つフルマネージド機能です。 IQVIA サービシーズ ジャパンでは、少人数でこの RAG チャットの開発・運用を行う必要がありそれらのコストを小さくしたいと考えていました。そのため、はじめは自前で RAG チャットの実装を試していましたが、ドキュメントのチャンキングとインデクシングといったデータの準備からベクトルデータベースと LLM との連携をマネージドに実現することができる Bedrock ナレッジベースを採用しました。ひとまとまりの Q&A 形式のファイルを Q&A 単位で分割し質問と回答が対応するかたちで入力すると言った簡易な加工はありつつも、フィルターなどの Bedrock ナレッジベースのネイティブ機能でほとんどの要件を達成しています。また、このソリューションは AWS Amplify や AWS Lambda、Amazon DynamoDB といった フルサーバレスな構成を採用しており、運用負荷をおさえたものになっています。 IQVIA サービシーズ ジャパンではこの RAG ソリューションの検証と構築を担当者 １ 名のみで実施し、約 2 ヶ月という期間で実現しました。 導入効果 この RAG チャットソリューションを IQVIA サービシーズ ジャパン 全体に広く導入し、約 2 ヶ月で社内ユーザー 321 人を達成しました。また月あたりの検索・調査に費やしていた時間を 93 % 削減することを実現されました。 その他にも調査の苦手なメンバーでも効率的に調査を実施することが可能になり、検索結果の品質向上や均質化した答えが得られることも導入効果として挙げられています。 社内からは今回導入された部署以外でも利用したいという要望が多数あげられており、ソリューションの拡大を検討されています。現在は各部署でデータの投入部分をはじめ運用の一部を担ってもらえるようなサービスの拡張に取り組んでいます。 開発担当者の上長からも、「作成物のイメージがあれば、柔軟性高く、迅速に開発が可能で、マネージドサービスのおかげで限られたリソースでも対応できたので満足しています。また、今回の RAG チャットの開発費用に関しても想像以上に安く抑えられました。」というフィードバックをいただいています。 まとめ Amazon Bedrock のナレッジベースを用いて開発・運用コストを最適化したRAG チャットソリューションを短期間で構築された IQVIA サービシーズ ジャパン 合同会社の取り組みについてご紹介しました。 同社では、この取り組み以外にも AWS の先進的なテクノロジーと 生成 AI を活用し、より広いユーザーへ向けた新たなサービスを展開されることを検討しています。ぜひ続報をお待ちください。

こんにちは！アマゾンウェブサービスジャパン合同会社で製造業のお客様を支援しているソリューションアーキテクトの村松、吉川、シニア事業開発マネージャーの和田です。 2024年10月3日に製造業向けオンラインセミナー「製品・サービスのスマート化 〜モノ / コトの壁とその解決手法 〜」を開催しました。セミナーの開催報告として、ご紹介した内容や、当日の資料・収録動画などを公開します。 製造業のお客様にとって、自社製品のスマート化や自社ソフトウェアの SaaS 化により、モノ売りからコト売りへ変革していくことが求められています。しかし、コト売りへの変革においては、システムだけでなく、組織、人材、開発プロセス、販売方法、KPIなど様々な変革の壁が存在します。 当セミナーでは、自社製品やソリューションのサービタイゼーションを検討 / 実施されているお客様に、実現するために課題となる部分のご説明や解決のための方法、お客様事例のご紹介を行いました。 どうぞ皆様の事業のご参考に、各講演者の録画/資料をご活用下さい。 サービタイゼーションの壁とその克服のヒント 登壇者：アマゾン ウェブ サービス ジャパン合同会社 シニア事業開発マネージャー 和田 健太郎 動画： 資料リンク コト売りにおいてはソリューションを素早く立ち上げ、かつ立ち上げたソリューションを継続的に改善することが重要です。しかし、コト売りへの変革において製造業のお客様は様々な課題に直面していらっしゃいます。Amazon ではイノベーションを起こすためには、組織、アーキテクチャ（システム）、メカニズム、企業文化の4つの要素が重要と捉えていますが、モノ売りとコト売りではこれらの4つの要素に大きな違いがあり、それらが「壁」としてコト売りへの変革を妨げています。 本セッションでは、これらの壁としてどのようなものがあるかをご紹介しつつ、製造業に求められる変革のヒントをご説明致しました。システム面でのクラウドの活用は前提として、組織/機能、KPI等の変革を合わせて進めて頂くことが重要です。 また、これらの変革に取り組まれているお客様の事例と、AWSのご支援内容をご紹介させて頂きました 製造業がデータビジネスはじめるってよ 登壇者：古野電気株式会社 IＴ部長 峯川 和久 様 動画： 資料リンク 古野電気様は魚群探知機や商船レーダーなど船舶電子機器で世界的に高いシェアをお持ちのグローバルメーカーです。本セッションでは IT部 峯川様から「製造業がデータビジネスをはじめる課題」について、自らが率いて古野電気様にデータビジネス基盤を立ち上げた理由、チャレンジ、ソリューションを語っていただきました。古野電気様は売上の７割を海の上のビジネスが占めます。マリンビジネスでの高いシェアを背景に、”Ocean 5.0”として「海との共存共栄」をテーマに新規ビジネスとして、漁業支援、養殖、自律航行、医療などの領域でのサブスク型のデータビジネスに取り組んでいます。 製造業がデータビジネスを推進する上で、３つの壁に直面します。（１）データビジネスの創出プロセスの違い：モノ売り（提供価値最大化）とデータビジネス（価値創造継続）では顧客との関わり方が全く異なリます。（２）マネジメント／人財戦略：メーカーの考えはトップダウン・リスク回避・スキル特化人財ですが、データビジネスではボトムアップ・チャレンジ重視・コミュ力多様性人財が重視されます。（３）採算管理／投資計画：メーカーは個別原価計算志向ですが、データビジネスでは一つのデータがさまざまなビジネスに利用されるためバスケット志向の損益管理が求められます。 これらの壁に対して峯川様は（１）創出プロセスのための「場」を作る。そのための「データ基盤」を整備する。（２）マネジメント／人財戦略としてサッカーフォーメーション型の組織運営。（３）採算管理／投資計画上「データ基盤」を１つに集約しそこでしっかり固定費管理をする。これらが重要と唱えられました。これを実現するために必要な「データプラットフォームの要件」を定義し、それを実現するデータ基盤「JuBuRaw（ジャブロー）」を AWS 上に構築されました。JuBuRaw はデータカタログ管理に Amazon DataZone を先進的に採用し、スピーディな開発のために AWS の Professional Service を活用されました。 高いデータビジネスのための壁を乗り越えるための古野電気様の取り組みはぜひ動画をご覧ください。 峯川様は日本のメーカーの維持とプライドと伝統を死守しつつデータプラットフォームを使いこなすことで企業成長を実現できると今後の抱負を語られました。 「お客様の声から学ぶ」製品・サービスの継続的改善と 生成 AI 活用の可能性 登壇者：横河電機株式会社 デジタル戦略本部 山下 純子 様 横河電機様は計測、制御、情報技術を基盤に多様な製品やソリューションを提供しています。安全で高品質な製品やサービスを提供することで、お客様の課題解決に貢献し、長期的なパートナーシップを築く取り組みを進めています。デジタル戦略本部山下様はコーポレート部門として社内の事業部メンバーと協業してデータ活用による社員生産性向上やお客様への価値向上に取り組んでいます。このセッションでは、製品に関わるデータの分析を行い製品・サービス改善を実現した事例や、組織横断的にデータを活用するまでに乗り越えた課題についてご紹介頂きました。また、生成AIを組み込むことで今後の更なる進化の可能性についても語って頂きました。 山下様の部門では、データ活用を推進していく上で、お客様に近いビジネス部門との協力を重要視しています。一方で、非 IT 人材におけるデータ・ドリブンマネジメントに対するスキルを持った人材育成・データ活用文化の強化を行なっていく必要があります。デジタル戦略本部では、BI ツールセミナーやデータリテラシートレーニングなどを全社に提供し、数百名から数千名規模の人材教育を行っています。更に、ただ受講するだけでなく、実践的なデータ活用まで踏み込んで改善の支援を進めています。結果として数億円規模のコスト効果を示すことができています。 また、生成 AI の活用にも言及されています。IT 部門として、Knowledge を蓄積するストレージ を用意できていても、それを活用するということができていないのが課題です。Knowledge データについて、特にコールセンターやアンケートのようなお客様の声を理解して活動するために、これまで NLP (自然言語処理) 技術を取り入れてデータ分析を進めてきました。しかし、大量のデータから意味のあるデータを抽出するためには、不要なデータを掻き分けていく前処理が必要になります。これに対して生成 AI によってお客様の声から重要なキーワードの抽出を行うことで、従来よりも容易に期待した精度が出せることが明らかになりました。また、PoC の際にご利用頂いた Amazon Bedrock について、安価で且つ手軽に使用でき、既存のデータ活用基盤からの拡張も容易に実現できた、といったご評価を頂いております。 「LOGINECT」で挑む、物流クライシスに向けたTOPPAN物流DXの取り組みのご紹介 登壇者：TOPPANデジタル株式会社 事業開発センター LOGINECT事業開発部 物流システム開発T 係長 武 孝 様 動画： 資料リンク TOPPAN デジタル様は DX 事業推進のコンセプトとして、Erhoeht-X を掲げられ、「製造・流通 DX」をはじめとした 5 つのカテゴリーを重点的に事業拡大を行っていらっしゃいます。各事業はサイクル型ビジネスモデルを軸に展開していて、導入だけにとどまらず、BPO、データ分析、コンサルティング領域を通して付加価値の実現を推進されています。 物流 DX においては、「LOGINECT」というソリューションを提供され、人的リソース不足の課題に対し、「倉庫 DX」と「配送 DX」の2つのサービス基軸で次世代の物流エコシステム構築を目指されています。 本講演では LOGINECT の中でも「LOGINECT 可視化・分析サービス」に関して、個社対応システムから SaaS 化への展開に際して、ぶつかった複数の壁とそれらをどのように乗り越えたかについてお話いただきました。 まず、個社対応システムにおいては、「リソースに限界があり、ビジネスの拡大が困難」という壁に対して、「共通ソリューションを SaaS 化する」という方法でビジネス拡大を目指されました。しかし、SaaS 化した後は、「手動デプロイによる横展開時のスピード感の遅れ」「お客様ごとに異なるデータ形式に合わせた加工作業が発生」という新たな壁に直面されます。これらに対しては、「インフラを AWS リソースで完結することで Terraform を活用」「AWS Glue の活用でデータ構造の違いを吸収」「社内クラウド専門部隊構築」などの施策で解決を試みられています。 また、LOGINECT は「可視化・分析サービス」以外にも様々なソリューションを提供されていますが、昨今では様々なソリューションのインテグレーションやグローバル展開にも挑まれていらっしゃいます。講演の後半ではこれらの取り組みを進めるチームの役割や、新規ソリューションの内容、チャンレンジについてもお話頂きました。 スマートプロダクトビジネスを最大化する生成 AI 活用アーキテクチャ 登壇者：アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 村松　謙 動画： 資料リンク イベント最後のセッションでは、AWS よりスマートプロダクトにおける生成AI活用で克服すべき課題や解決するためのアーキテクチャ・AWS サービスをご紹介しました。 スマートプロダクトにおいては、ユーザーの声に迅速に応えてタイムリーに継続的に製品をリリースする必要があります。さらに、生成 AI の普及によってユーザーの声の分析や活用がさらに民主化されていき、あらゆる側面で顧客の声が活用されるようになっていくことで、改善のスピードが高速化されていきます。スマートプロダクトは、あらゆるフェーズで生成 AI を活用するユースケースがありますが、その中でも今回は Voice of Customer の活用・改善による顧客価値の向上にフォーカスしてお伝えさせて頂きました。 顧客価値を向上させるため、スマートプロダクトビジネスにおける Voice of Customer データの種類や、活用者となるステークホルダーの実現したい内容・KPI をご紹介しました。下の図のように、生成AIの登場により、大規模言語モデルを通じてより人間に近い推論能力を実現し、かつ自然言語による指示・質問をすることで、言語処理を簡単に実現することができるようになりました。本セッションでは、営業・マーケティング部門と保守・カスタマーサポート部門における課題と生成 AI の具体的なケイパビリティ・お客様事例をご紹介しました。 後半では、Voice of Customer データの分析を行なっていくにあたっての 3 つの課題 (品質・データコラボレーション・検索性) と AWS サービスによる改善方法についてご紹介しました。 最後に、生成 AI の活用をこれから始めていくお客様や使い始めていくにあたって不安があるお客様に向けて、コストや後戻りを最小限にして徐々にデータ・生成 AI 活用を始めていくアプローチや、AWS からご提供させて頂く支援プログラムのご紹介をしました。 おわりに 本セミナーでは、製造業のお客様が自社製品のスマート化や自社ソフトウェアの SaaS 化により、モノ売りからコト売りへ変革していくために乗り越えるべき壁や、その克服のヒントをご紹介し、実際にサービタイゼーションを実現されたお客様の事例と体験談を共有いただきました。また、スマートプロダクトにおける生成 AI の活用方法についてもご紹介させて頂きました。 本ブログは、事業開発マネージャーの和田健太郎、ソリューションアーキテクトの村松謙、吉川晃平が執筆しました。

この記事は、 OpenSearch optimized instance (OR1) is game changing for indexing performance and cost を翻訳したものです。 Amazon OpenSearch Service は、アプリケーション監視、ログ分析、オブザーバビリティ、Web サイト検索などのユースケースで、ビジネスデータや運用データのリアルタイム検索、監視、分析を安全に実現にします。 この記事では、 2023 年 11 月 29 日に導入された 、OpenSearch 最適化インスタンスである OR1 について検討します。 OR1 は Amazon OpenSearch Service のインスタンスタイプで、大量のデータを保存するためのコスト効率の高い方法を提供します。OR1 インスタンスを使用するドメインでは、 Amazon Elastic Block Store (Amazon EBS) ボリュームをプライマリストレージとして使用し、データが書き込まれるとすぐに Amazon Simple Storage Service (Amazon S3) に同期的にコピーされます。OR1 インスタンスは、高い耐久性と共に、インデクシングのスループットも向上します。 OR1 の詳細については、 紹介ブログ記事 をご覧ください。 インデックスに対して書き込みを行っている間は、レプリカを 1 つ維持することをお勧めします。ただし、ロールオーバー後にインデックスに対する書き込みが行われなくなった後は、レプリカを 0 に切り替えることができます。 これは、データが Amazon S3 に永続化されているため、安全に行えます。 ノードの障害と交換が発生した場合、データは Amazon S3 から自動的に復元されますが、修復操作中は一部のデータアクセスができなくなるため、アクティブに書き込まれていないインデックスの検索に高可用性が必要な場合は、レプリカを 0 にしないでください。 ゴール このブログ記事では、OR1 が OpenSearch ワークロードのパフォーマンスにどのような影響を与えるかを探ります。 OR1 インスタンスは、セグメントレプリケーションを提供することで、プライマリシャードでのみインデックス作成を行うため、CPU サイクルを節約できます。これにより、ノードは同じ計算リソースで、より多くのデータをインデックス化できるか、インデックス作成に使用するリソースを減らし、検索やその他の操作に使えるリソースを増やすことができます。 この記事では、インデックス作成の負荷が高いワークロードを想定し、パフォーマンステストを行います。 従来、 Amazon Elastic Compute Cloud (Amazon EC2) の R6g インスタンスは、Amazon EBS ストレージに依存するインデックス作成の負荷が高いワークロードに適した高性能な選択肢でした。Im4gn インスタンスは、高スループットと低レイテンシーのディスク書き込みに向いた、ローカル NVMe SSD を提供します。 この記事の範囲では、インデクシングのパフォーマンスのみに焦点を当て、OR1 のインデクシング性能を、これら 2 つのインスタンスタイプと比較します。 設定 パフォーマンステストでは、次の図に示すように複数のコンポーネントを設定しました。 テストプロセスについては以下の通りです: AWS Step Functions は、環境のクリーンアップとインデックスマッピングのセットアップ、およびバッチテストの実行のための初期化ステップを調整します。 AWS Batch は、OpenTelemetry JSON 形式のログデータをインデックス化するための並列ジョブを実行します。 ジョブは、 OpenSearch Rust Client と AWS Identity and Access Management (IAM) 認証を使用して、ランダム化されたログを生成するカスタム Rust プログラムを実行します。 OpenSearch Service ドメインは、OpenSearch 2.11、2 つのアベイラビリティーゾーン、きめ細かいアクセス制御、 AWS Key Management Service (AWS KMS) による保存時の暗号化、TLS による転送時の暗号化で設定されています。 インデックスマッピングは、初期化ステップの一部で、次のようになります。 { "index_patterns": [ "logs-*" ], "data_stream": { "timestamp_field": { "name": "time" } }, "template": { "settings": { "number_of_shards": , "number_of_replicas": 1, "refresh_interval": "20s" }, "mappings": { "dynamic": false, "properties": { "traceId": { "type": "keyword" }, "spanId": { "type": "keyword" }, "severityText": { "type": "keyword" }, "flags": { "type": "long" }, "time": { "type": "date", "format": "date_time" }, "severityNumber": { "type": "long" }, "droppedAttributesCount": { "type": "long" }, "serviceName": { "type": "keyword" }, "body": { "type": "text" }, "observedTime": { "type": "date", "format": "date_time" }, "schemaUrl": { "type": "keyword" }, "resource": { "type": "flat_object" }, "instrumentationScope": { "type": "flat_object" } } } } } データストリーム を使用して、ロールオーバー構成を簡素化し、 ベストプラクティス に従って、プライマリシャードのサイズを 50 GiB 以下に抑えています。 不要なインデクシングアクティビティを回避し、 flat_object フィールドタイプを使用して フィールドマッピングの爆発 を回避するようにマッピングを最適化しました。 参考までに、使用した Index State Management (ISM) ポリシーは以下の通りです。 { "policy": { "default_state": "hot", "states": [ { "name": "hot", "actions": [ { "rollover": { "min_primary_shard_size": "50gb" } } ], "transitions": [] } ], "ism_template": [ { "index_patterns": [ "logs-*" ] } ] } } 平均ドキュメントサイズは 1.6 KiB で、バルクサイズは 1 バルクあたり 4,000 ドキュメントのため、1 バルクあたり約 6.26 MiB (非圧縮時) になります。 プロトコルのテスト プロトコルのパラメータは次のとおりです。 データノードの数: 6 または 12 ジョブの並列処理数: 75、40 プライマリシャード数: 12、48、96 (12 ノードの場合) レプリカの数: 1 (合計 2 コピー) インスタンスタイプ (それぞれ 16 vCPU): or1.4xlarge.search r6g.4xlarge.search im4gn.4xlarge.search Cluster Instance type vCPU RAM JVM size or1-target or1.4xlarge.search 16 128 32 im4gn-target im4gn.4xlarge.search 16 64 32 r6g-target r6g.4xlarge.search 16 128 32 im4gn クラスターのメモリ容量は他の 2 つの半分ですが、それでも各環境の JVM ヒープサイズはおよそ 32GiB で同じです。 パフォーマンステストの結果 パフォーマンステストでは、最初にクライアントごとに 75 の並列ジョブと 4,000 ドキュメントの 750 バッチ (合計 2 億 2,500 万ドキュメント) から始めました。その後、シャード数、データノード数、レプリカ数、ジョブ数を調整しました。 構成 1 : 6 データノード、12 プライマリシャード、1 レプリカ この構成では、データノードを 6 つ、プライマリシャードを 12 個、レプリカを 1 つ使用しました。そして、次のようなパフォーマンスを観測しました。 Cluster CPU 使用率 所要時間 インデックス作成速度 or1-target 65-80% 24 分 156 kdoc/s 243 MiB/s im4gn-target 89-97% 34 分 110 kdoc/s 172 MiB/s r6g-target 88-95% 34 分 110 kdoc/s 172 MiB/s この表で強調表示されているように、im4gn クラスターと r6g クラスターの CPU 使用率が非常に高く、 アドミッションコントロール がトリガーされ、ドキュメントが拒否されています。 OR1 は、CPU 使用率が 80% 未満で持続していることを示しており、これは非常に良いターゲットです。 注意すべき点 : 本番環境では、エクスポネンシャルバックオフを使ってインデクシングを再試行し、一時的な拒否によるドキュメント欠落が起きないようにしてください。 バルクインデクシング操作は 200 OK を返しますが、一部失敗する可能性があります。すべての文書が正常にインデックスされたことを確認するには、レスポンスの本文をチェックする必要があります。 並列ジョブの数を 75 から 40 に減らしながら、クライアントごとに 4,000 ドキュメントの 750 バッチ (合計 120M ドキュメント) を維持すると、次のようになります。 Cluster CPU 使用率 所要時間 インデックス作成速度 or1-target 25-60% 20 分 100 kdoc/秒 156 MiB/秒 im4gn-target 75-93% 19 分 105 kdoc/秒 164 MiB/秒 r6g-target 77-90% 20 分 100 kdoc/秒 156 MiB/秒 スループットと CPU 使用率は減少しましたが、Im4gn と R6g の CPU 使用率は高い状態が続いており、一方で OR1 には余剰の CPU 容量があることがわかります。 構成 2 : 6 データノード、48 プライマリシャード、1 レプリカ この構成では、プライマリシャードの数を 12 から 48 に増やしました。これにより、インデックス作成のための並列処理能力が向上します。 Cluster CPU 使用率 所要時間 インデックス作成速度 or1-target 60-80% 21 分 178 kdoc/s 278 MiB/s im4gn-target 67-95% 34 分 110 kdoc/s 172 MiB/s r6g-target 70-88% 37 分 101 kdoc/s 158 MiB/s OR1 のインデックス処理スループットは向上しましたが、Im4gn と R6g は CPU 使用率がまだ非常に高いため、改善は見られませんでした。 並列ジョブを 40 に減らし、プライマリシャードを 48 に保ったところ、OR1 の最小 CPU が 12 のプライマリシャードから増加し、やや負荷がかかることがわかります。一方で、R6g の CPU 使用率は大幅に改善されました。しかし Im4gn の CPU 使用率はまだ高い状態です。 Cluster CPU 使用率 所要時間 インデックス作成速度 or1-target 40-60% 16 分 125 kdoc/s 195 MiB/s im4gn-target 80-94% 18 分 111 kdoc/s 173 MiB/s r6g-target 70-80% 21 分 95 kdoc/s 148 MiB/s 構成 3 : 12 データノード、96 プライマリシャード、1 レプリカ この構成では、元の構成から始め、コンピューティング能力を増強しました。ノード数を 6 から 12 に増やし、プライマリシャード数を 96 に増やしました。 クラスター CPU 使用率 所要時間 インデックス作成速度 or1-target 40-60% 18 分 208 kdoc/s 325 MiB/s im4gn-target 74-90% 20 分 187 kdoc/s 293 MiB/s r6g-target 60-78% 24 分 156 kdoc/s 244 MiB/s OR1 と R6g は CPU 使用率が 80% 未満で良好なパフォーマンスを発揮しています。OR1 は R6g と比較して CPU 使用率が 30% 少なく、パフォーマンスが 33% 優れています。 Im4gn は CPU 使用率が 90% のままですが、パフォーマンスも非常に良好です。 並列ジョブの数を 75 から 40 に減らすと、次のようになります。 クラスター CPU 使用率 所要時間 インデックス作成速度 or1-target 40-60% 11 分 182 kdoc/s 284 MiB/s im4gn-target 70-90% 11 分 182 kdoc/s 284 MiB/s r6g-target 60-77% 12 分 167 kdoc/s 260 MiB/s 並列ジョブの数を 75 から 40 に減らすと、OR1 と Im4gn インスタンスが同等になり、R6g も非常に近くなりました。 解釈 OR1 インスタンスは、レプリカがセグメントのコピーによって生成されるため、プライマリシャードのみを書き込めばよいため、インデックス作成を高速化します。Img4n インスタンスや R6g インスタンスと比較して高性能にも関わらず、CPU 使用率も低いため、追加の負荷 (検索) やクラスターサイズの削減の余地があります。 6 ノードの OR1 クラスターで 48 個のプライマリシャードを持ち、秒あたり 178,000 ドキュメントをインデックス化するのと、12 ノードの Im4gn クラスターで 96 個のプライマリシャードを持ち、秒あたり 187,000 ドキュメントをインデックス化するのと、12 ノードの R6g クラスターで 96 個のプライマリシャードを持ち、秒あたり 156,000 ドキュメントをインデックス化するのを比較できます。 OR1 は、より大きな Im4gn クラスターとほぼ同等のパフォーマンスを発揮し、より大きな R6g クラスターよりも優れたパフォーマンスを示します。 OR1 インスタンスを使用する場合のサイズ設定方法 結果から分かるように、OR1 インスタンスはより高いスループット率でデータを処理できます。しかし、プライマリシャードの数を増やすと、リモートバックドストレージのためにパフォーマンスが低下します。 OR1 インスタンスタイプから最高のスループットを得るには、通常より大きなバッチサイズを使用し、Index State Management (ISM) ポリシーを使ってサイズに基づきインデックスをロールオーバーすることで、インデックスごとのプライマリシャードの数を効果的に制限できます。また、OR1 インスタンスタイプはより多くの並列処理を処理できるため、接続数を増やすこともできます。 検索に関しては、OR1 はパフォーマンスに直接影響しません。しかし、図から分かるように、OR1 インスタンスの CPU 使用率は Im4gn インスタンスや R6g インスタンスよりも低くなっています。これにより、より多くのアクティビティ (検索やインジェスト) を実行できるか、インスタンスのサイズやカウントを削減して、コストを削減できる可能性があります。 OR1 の結論と推奨事項 新しい OR1 インスタンスタイプは、他のインスタンスタイプよりも強力なインデックス作成機能を提供します。これは、日々バッチ処理でインデックス作成を行う場合や、高い持続的なスループットを必要とする場合など、インデックス作成の負荷が高いワークロードにとって重要です。 OR1 インスタンスタイプでは、既存のインスタンスタイプよりもパフォーマンスに対する価格が 30% 優れているため、コスト削減も可能です。複数のレプリカを追加する場合、OR1 インスタンスでは CPU 使用率への影響がほとんどないため、パフォーマンスあたりの価格が下がります。一方、他のインスタンスタイプでは、インデックス処理スループットが低下します。 この repost 記事 を参照して、インデックス作成のためのワークロードの最適化の完全な手順を確認してください。 著者について C é dric Pelvet は AWS プリンシパルソリューションアーキテクトです。リアルタイムデータと検索ワークロードに対するスケーラブルなソリューションの設計をお客様にご支援しています。プライベートでは、新しい言語を学んだり、バイオリンの練習をしています。

この記事は、 Reducing long-term logging expenses by 4,800% with Amazon OpenSearch Service を翻訳したものです。 サーバーログ、サービスログ、アプリケーションログ、クリックストリーム、イベントストリームなどの時間制限のあるデータに Amazon OpenSearch Service を使用する場合、ストレージコストはソリューション全体における主要なコストの 1 つです。昨年、OpenSearch Service では、ログデータを様々な階層に保存できる新機能がリリースされ、データの待機時間、耐久性、可用性のトレードオフが可能になりました。2023 年 10 月、 OpenSearch Service は最大 30TB の NVMe SSD ストレージを備えた im4gn データノードのサポートを発表しました 。2023 年 11 月、 OpenSearch Service は OpenSearch 最適化インスタンスファミリー or1 を導入し 、社内ベンチマークで既存インスタンスに比べ最大 30% のパフォーマンス価格比の改善を実現し、 Amazon Simple Storage Service (Amazon S3) を使用してイレブンナインの耐久性を提供しました。最後に、2024 年 5 月、OpenSearch Service は Amazon OpenSearch Service と Amazon S3 の zero-ETL 統合 の一般提供を発表しました。これらの新機能は、 既存の UltraWarm インスタンス (GB あたりのストレージコストを最大 90% 削減) と、 UltraWarm のコールドストレージ オプション (UltraWarm インデックスを分離し、アクセス頻度の低いデータを Amazon S3 に永続的に保存できる) に加わります。 このポストでは、コスト、レイテンシー、スループット、データの永続性と可用性、保持期間、データアクセスにおける選択肢のトレードオフを理解できるように、例を用いて説明します。これにより、データの価値を最大化し、コストを最小化するための適切なデプロイメントを選択できるようになります。 要件の検討 ロギングソリューションを設計する際は、適切なトレードオフを行う前提条件として、要件を明確に定義する必要があります。レイテンシー、耐久性、可用性、コストに関する要件を慎重に検討してください。さらに、OpenSearch Service に送信するデータ、データの保持期間、そのデータへのアクセス計画を検討する必要があります。 この議論の目的のために、OpenSearch インスタンスのストレージをエフェメラルストレージと Amazon S3 バックドストレージの 2 つのクラスに分けます。エフェメラルドストレージクラスには、Nonvolatile Memory Express SSDs (NVMe SSDs) と Amazon Elastic Block Store (Amazon EBS) ボリュームを使用する OpenSearch ノードが含まれます。Amazon S3 バックドストレージクラスには、UltraWarm ノード、UltraWarm コールドストレージ、or1 インスタンス、および Amazon S3 との Zero-ETL で利用できる Amazon S3 ストレージが含まれます。ロギングソリューションを設計する際は、次の点を考慮してください。 レイテンシ – ミリ秒単位で結果を必要とする場合は、エフェメラルストレージをバックエンドに使用する必要があります。秒または分単位の結果で許容できる場合は、Amazon S3 をバックエンドに使用することでコストを削減できます。 スループット – 一般的に、エフェメラルストレージをバックエンドに使用したインスタンスの方がスループットが高くなります。im4gn のように NVMe SSDs を搭載したインスタンスは通常最高のスループットを提供し、EBS ボリュームも良好なスループットを提供します。or1 インスタンスは、プライマリシャードに Amazon EBS ストレージを利用しながら、 Amazon S3 とセグメントレプリケーション を活用することで、レプリケーションのコンピューティングコストを削減し、NVMe ベースのインスタンスと同等またはそれ以上のインデックス作成スループットを提供します。 データ耐久性 – ホット層 (データノード) に格納されたデータは最も低いレイテンシーですが、耐久性も最も低くなります。OpenSearch Service は、レプリカを通じてホット層のデータの自動復旧を提供し、コストを伴いながら耐久性を確保します。OpenSearch が Amazon S3 (UltraWarm、UltraWarm コールドストレージ、Amazon S3 との zero-ETL、or1 インスタンス) に格納するデータは、Amazon S3 のイレブンナインの耐久性の恩恵を受けます。 データ可用性 – ベストプラクティス では、エフェメラルストレージのデータにレプリカを使用することを推奨しています。少なくとも 1 つのレプリカがあれば、ノードの障害が発生しても、すべてのデータにアクセスできます。ただし、各レプリカはコストの増加を伴います。一時的な利用不可を許容できる場合は、or1 インスタンスと Amazon S3 ストレージを使用することで、レプリカを削減できます。 保持期間 – すべてのストレージ層のデータにはコストがかかります。分析のためにデータを長期間保持するほど、そのデータの 1GB あたりの累積コストが高くなります。すべての価値が失われるまでにデータを保持しなければならない最長期間を特定してください。場合によっては、コンプライアンス要件によって保持期間が制限される可能性があります。 データアクセス – 一般に、Amazon S3 をバックエンドに使用したインスタンスは、コンピューティングに対するストレージの比率がはるかに高く、コスト削減につながりますが、大量のワークロードには十分なコンピューティング能力がありません。クエリ量が多い、またはクエリが大量のデータにまたがる場合は、エフェメラルストレージをバックエンドに使用するのが適切です。ダイレクトクエリ (Amazon S3 ストレージをバックエンドに使用) は、頻繁にクエリされないデータに対する大量のクエリに最適です。 これらの観点から要件を検討すると、その回答が実装の選択肢を導き出すことになります。トレードオフを判断するために、次のセクションで詳細な例を説明します。 OpenSearch Service のコストモデル OpenSearch Service のデプロイのコストを理解するには、コストの特徴を理解する必要があります。OpenSearch Service には、マネージドクラスターとサーバーレスの 2 つの異なるデプロイオプションがあります。この投稿ではマネージドクラスターのみを考慮します。 Amazon OpenSearch Serverless はすでにデータを階層化し、ストレージを管理してくれるためです。マネージドクラスターを使用する場合は、データノード、UltraWarm ノード、専用マスターノードを構成し、それぞれの機能に Amazon Elastic Compute Cloud (Amazon EC2) インスタンスタイプを選択します。OpenSearch Service はこれらのノードをデプロイ、管理し、REST エンドポイントを介して OpenSearch と OpenSearch Dashboards を提供します。Amazon EBS バックドインスタンスまたは NVMe SSD ドライブ付きインスタンスを選択できます。OpenSearch Service は、マネージドクラスターのインスタンスに対して時間単位の料金を請求します。Amazon EBS バックドインスタンスを選択した場合、サービスはプロビジョニングされたストレージと、構成した プロビジョニング IOPS に対して料金を請求します。or1 ノード、UltraWarm ノード、または UltraWarm コールドストレージを選択した場合、OpenSearch Service は Amazon S3 で消費されたストレージに対して料金を請求します。最後に、 転送されたデータに対するサービス料金 がかかります。 使用例 コストとパフォーマンスのトレードオフを検討するために、使用例を使用します。この例のコストとサイズは、ベストプラクティスに基づいており、方向性を示すものです。同様の節約効果が期待できますが、すべてのワークロードはユニークであり、実際のコストは本記事で示すものとは大きく異なる可能性があります。 架空の大手清涼飲料メーカー Fizzywig のユースケースを見ていきましょう。飲料の製造工場が多数あり、製造ラインからは膨大なログが出力されています。当初はすべてホットデプロイで 1 日 10 GB のログを生成していましたが、今日では 1 日 3 TB のログデータが発生し、経営陣はコスト削減を求めています。Fizzywig はログデータをイベントのデバッグと分析、および 1 年分のログデータの履歴分析に使用しています。OpenSearch Service でそのデータを保存し利用するコストを計算しましょう。 エフェメラルストレージの導入 Fizzywig の現在のデプロイメントは、エフェメラルストレージを備えた 189 個の r6g.12xlarge.search データノード (UltraWarm 層なし) です。OpenSearch Service でデータをインデックス化すると、OpenSearch はインデックスデータ構造を構築し、ソースデータよりも通常 10% 大きくなります。また、運用オーバーヘッドのために 25% の空き領域を残す必要があります。毎日 3TB のソースデータがある場合、オーバーヘッドを含めてプライマリ (最初のコピー) に 4.125TB のストレージが必要になります。Fizzywig は、最大のデータ耐久性と可用性を確保するため、 OpenSearch Service Multi-AZ with Standby オプションを使用して 2 つのレプリカコピーを作成するベストプラクティスに従っています。これにより、1 日あたりのストレージ需要は 12.375TB に増加します。1 年分のデータを保存するには、365 日を掛けて 4.5PB のストレージが必要になります。 このストレージ容量をプロビジョニングするには、im4gn.16xlarge.search インスタンスまたは or1.16.xlarge.search インスタンスを選択することもできます。次の表は、これらのインスタンスタイプごとに、データのコピー数に応じて必要なインスタンス数を示しています。 . ノードあたりの最大ストレージ (GB) Primary (1 Copy) Primary + Replica (2 Copies) Primary + 2 Replicas (3 Copies) im4gn.16xlarge.search 30,000 52 104 156 or1.16xlarge.search 36,000 42 84 126 r6g.12xlarge.search 24,000 63 126 189 前の表と次の説明は、ストレージニーズに厳密に基づいています。or1 インスタンスと im4gn インスタンスの両方とも、r6g インスタンスよりも高いスループットを提供するため、さらにコストを削減できます。計算の節約額は、ワークロードとインスタンスタイプによって 10 〜 40% 異なります。これらの節約は直接利益に反映されるわけではなく、インデックスとシャード戦略のスケーリングと変更を行って初めて実現できます。前の表と後続の計算では、これらのデプロイメントはコンピューティングリソースが過剰にプロビジョニングされており、ストレージに制限があると一般的に想定されています。コンピューティングリソースをさらに拡張する必要がある場合、r6g に比べて or1 と im4gn でより多くの節約が見込めます。 次の表は、指定された 3 つの異なるデータストレージサイズにわたる 3 つの異なるインスタンスタイプの合計クラスターコストを表しています。これらは オンデマンド米国東部 (バージニア北部) AWS リージョンのコスト に基づいており、インスタンス時間、or1 インスタンスの Amazon S3 コスト、および or1 インスタンスと r6g インスタンスの Amazon EBS ストレージコストが含まれています。 . Primary (1 Copy) Primary + Replica (2 Copies) Primary + 2 Replicas (3 Copies) im4gn.16xlarge.search $3,977,145 $7,954,290 $11,931,435 or1.16xlarge.search $4,691,952 $9,354,996 $14,018,041 r6g.12xlarge.search $4,420,585 $8,841,170 $13,261,755 この表は、4.5 PB のワークロードに対する 1 コピー、2 コピー、3 コピーのコスト (該当する場合は Amazon S3 と Amazon EBS のコストを含む) を示しています。この投稿では、「1 コピー」とは、レプリケーション数をゼロに設定した最初のデータコピーを指します。「2 コピー」にはデータのレプリカコピーが含まれ、「3 コピー」にはプライマリと 2 つのレプリカが含まれます。ご覧のとおり、各レプリカはソリューションのコストを倍増させます。もちろん、各レプリカはデータの可用性と耐久性を高めます。1 コピー (プライマリのみ) の場合、単一ノードの障害で (or1 インスタンスを除いて) データを失うことになります。1 つのレプリカがある場合、2 ノードの障害で一部またはすべてのデータを失う可能性があります。2 つのレプリカがある場合、3 ノードの障害でのみデータを失うことになります。 or1 インスタンスはこの規則の例外です。or1 インスタンスは、1 コピーのデプロイをサポートできます。これらのインスタンスは、Amazon S3 をバッキングストアとして使用し、すべてのインデックスデータを Amazon S3 に書き込み、レプリケーションと耐久性を実現します。確認された書き込みはすべて Amazon S3 に永続化されるため、ノードの停止時にデータの可用性を失うリスクはありますが、1 コピーで実行できます。データノードが利用できなくなった場合、通常10~20分程度の復旧時間が必要になり、その間はインデックスが利用できなくなります (ステータスが赤色表示になります)。システム (例: 取り込みパイプラインバッファ) だけでなく、顧客に対してもこの可用性の低下を許容できるかどうかを慎重に評価する必要があります。許容できる場合は、前の表に示されている 1 コピー (プライマリ) の列に基づいて、コストを 1,400 万ドルから 470 万ドルに削減できます。 リザーブドインスタンス OpenSearch Service では、1 年契約と 3 年契約の Reserved Instance (RI) がサポートされています。これには、前払い費用なし (NURI)、一部前払い (PURI)、全額前払い (AURI) があります。すべての RI 契約でコストが下がりますが、3 年契約の全額前払い RI が最も割引率が高くなります。Fizzywig のワークロードに 3 年契約の全額前払い RI の割引を適用した場合の年間コストは、次の表のようになります。 . Primary Primary + Replica Primary + 2 Replicas im4gn.16xlarge.search $1,909,076 $3,818,152 $5,727,228 or1.16xlarge.search $3,413,371 $6,826,742 $10,240,113 r6g.12xlarge.search $3,268,074 $6,536,148 $9,804,222 RI は、コードやアーキテクチャの変更を行うことなく、コストを削減する簡単な方法を提供します。この作業負荷に RI を採用すると、3 コピーの im4gn コストが 570 万ドルに、or1 インスタンスの 1 コピーコストが 320 万ドルになります。 Amazon S3 バックドストレージの導入 前述のデプロイメントはベースラインとの比較のために役立ちます。実際には、コストを管理可能な範囲に抑えるために、Amazon S3 バックドストレージオプションのいずれかを選択するでしょう。 OpenSearch Service の UltraWarm インスタンスは、すべてのデータを Amazon S3 に保存し、UltraWarm ノードをこの完全なデータセットの上の ホットキャッシュ として利用します。UltraWarm は、6 か月前の 1 日分のデータに対して複数のクエリを実行するなど、小さな時間範囲のデータに対する対話型クエリに最適です。アクセスパターンを慎重に評価し、UltraWarm のキャッシュのような動作があなたのニーズに合うかどうかを検討してください。UltraWarm の最初のクエリのレイテンシは、クエリする必要があるデータ量に応じて拡大します。 OpenSearch Service ドメインを UltraWarm 用に設計する際、ホット保持期間とウォーム保持期間を決める必要があります。ほとんどの OpenSearch Service のお客様は、ホット保持期間を 7 ～ 14 日間程度に設定し、ウォーム保持期間で全保持期間の残りを構成しています。Fizzywig のシナリオでは、ホット保持期間を 14 日間、UltraWarm 保持期間を 351 日間に設定しています。また、ホット層では、 2 コピー (プライマリと 1 つのレプリカ) のデプロイを使用しています。 14 日間に必要なホットストレージ (1 日の取り込み量 4.125 TB に基づく) は 115.5 TB です。3 種類のインスタンスタイプのいずれかを 6 つデプロイすれば、このインデクシングとストレージをサポートできます。UltraWarm は Amazon S3 に単一のレプリカを格納し、追加のストレージオーバーヘッドは必要ありません。そのため、351 日間のストレージニーズは 1.158 PiB となります。これは 58 台の UltraWarm1.large.search インスタンスでサポートできます。次の表は、ホット層に 3 年間の AURI を適用したこのデプロイメントの総コストを示しています。or1 インスタンスの Amazon S3 コストは S3 列に含まれています。 . Hot UltraWarm S3 Total im4gn.16xlarge.search $220,278 $1,361,654 $333,590 $1,915,523 or1.16xlarge.search $337,696 $1,361,654 $418,136 $2,117,487 r6g.12xlarge.search $270,410 $1,361,654 $333,590 $1,965,655 さらにコストを削減するには、データを UltraWarm コールドストレージに移行できます。コールドストレージは、データの可用性を下げることでコストを削減します。データを照会するには、対象のインデックスを UltraWarm 層に再アタッチするための API 呼び出しを発行する必要があります。1 年分のデータの典型的なパターンは、14 日間ホット、76 日間 UltraWarm、275 日間コールドストレージです。このパターンに従うと、6 つのホットノードと 13 の UltraWarm1.large.search ノードを使用します。次の表は、Fizzywig の 3TB の日次ワークロードを実行するコストを示しています。Amazon S3 の使用料金は、 UltraWarm ノード + S3 列に含まれています。 . Hot UltraWarm nodes + S3 Cold Total im4gn.16xlarge.search $220,278 $377,429 $261,360 $859,067 or1.16xlarge.search $337,696 $461,975 $261,360 $1,061,031 r6g.12xlarge.search $270,410 $377,429 $261,360 $909,199 Amazon S3 バックドのストレージオプションを利用することで、単一コピーまたは 1 デプロイで 33 万 7,000 ドル、1 インスタンスで最大年間 100 万ドルと、さらにコストを削減できます。 OpenSearch Service の Amazon S3 との zero-ETL 統合 OpenSearch Service zero-ETL for Amazon S3 を使用すると、すべての二次データと古いデータを Amazon S3 に保持できます。二次データとは、VPC フローログや WAF ログなど、直接検査する価値は低い大量のデータです。このようなデプロイメントでは、頻繁にクエリされないデータの大部分を Amazon S3 に保持し、最新のデータのみホット層に保持します。場合によっては、二次データの一部をサンプリングし、ホット層にも一定割合を保持します。Fizzywig は、すべてのデータの 7 日分をホット層に保持することにしました。残りのデータはダイレクトクエリ (DQ) でアクセスします。 ダイレクトクエリを使用する場合、データを JSON、Parquet、CSV 形式で保存できます。Parquet 形式はダイレクトクエリに最適で、データに対して約 75% の圧縮が行われます。Fizzywig は Amazon OpenSearch Ingestion を使用しており、これにより Parquet 形式のデータを直接 Amazon S3 に書き込むことができます。毎日 3 TB のソースデータが 750 GB の Parquet データに圧縮されます。OpenSearch Service はダイレクトクエリ用のコンピューティングユニットのプールを維持しています。これらの OpenSearch コンピューティングユニット (OCU) は時間単位で課金され、アクセスするデータ量に基づいてスケーリングされます。この会話では、Fizzywig がデバッグセッションを行い、1 日分のデータ (750 GB) に対して 50 件のクエリを実行すると想定しています。次の表は、毎日 3 TB のワークロードを 7 日間ホットで、358 日間 Amazon S3 に保存する場合の年間コストの概要を示しています。 . Hot DQ Cost OR1 S3 Raw Data S3 Total im4gn.16xlarge.search $220,278 $2,195 $0 $65,772 $288,245 or1.16xlarge.search $337,696 $2,195 $84,546 $65,772 $490,209 r6g.12xlarge.search $270,410 $2,195 $0 $65,772 $338,377 大変な旅路でした! Fizzywig 社のロギングコストは、年間最高 1,400 万ドルから、Amazon S3 からの zero-ETL によるダイレクトクエリを使用することで年間 28 万 8,000 ドルまで下がりました。これは 4,800% の節約です! サンプリングと圧縮 この投稿では、データサイズに焦点を当て、そのデータへのアクセス方法に応じてトレードオフを行うことができる 1 つのデータフットプリントを見てきました。OpenSearch には、保存するデータ量を削減することで、さらに経済性を変えることができる追加機能があります。 ログワークロードの場合、 OpenSearch Ingestion サンプリングを利用して、OpenSearch Service に送信するデータのサイズを削減 できます。サンプリングは、全体のデータが統計的特性を持ち、一部が全体を代表できる場合に適しています。たとえば、オブザーバビリティワークロードを実行している場合、システムでのリクエスト処理のトレースを代表するサンプリングを取得するために、データの 10% 程度を送信するだけで十分な場合があります。 ワークロードに応じて、 圧縮アルゴリズム を使用することもできます。OpenSearch Service では最近、デフォルトの最高圧縮に比べて、より高い圧縮率と低い伸張待ち時間を実現できる Zstandard (zstd) 圧縮のサポートがリリースされました。 結論 OpenSearch Service を使うことで、Fizzywig は、コスト、レイテンシー、スループット、耐久性と可用性、データ保持、そして好ましいアクセスパターンのバランスを取ることができました。彼らはロギングソリューションのコストを 4,800% 削減することができ、経営陣は大喜びでした。 全体的に見ると、im4gn インスタンスの絶対金額が最も低くなります。ただし、いくつか注意点があります。まず、or1 インスタンスは、特に書き込み集中型のワークロードで、より高いスループットを提供できます。これにより、コンピューティングの必要性が低減され、追加の節約につながる可能性があります。さらに、or1 の高い耐久性により、レプリケーションを減らして可用性と耐久性を維持できるため、コストが削減されます。もう 1 つの検討事項は RAM です。r6g インスタンスは追加の RAM を備えているため、クエリの待ち時間が短縮されます。UltraWarm と組み合わせ、ホット/ウォーム/コールドの比率を変えることで、r6g インスタンスも優れた選択肢となります。 大量のロギングワークロードがありますか? これらの方法の一部またはすべてから恩恵を受けましたか? ご意見をお聞かせください! 著者について Jon Handler は、カリフォルニア州パロアルトに拠点を置く Amazon Web Services のシニアプリンシパルソリューションアーキテクトです。Jon は OpenSearch と Amazon OpenSearch Service を担当し、ベクトル、検索、ログ分析のワークロードを AWS Cloud に移行したいさまざまな顧客に対して支援とガイダンスを提供しています。AWS に入社する前は、ソフトウェア開発者として 4 年間大規模な EC サイトの検索エンジンをコーディングしていました。Jon はペンシルベニア大学で文学士号を、ノースウェスタン大学でコンピューターサイエンスと人工知能の理学修士号と博士号を取得しています。