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

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

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

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

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

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

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

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

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

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

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

Anthropic が Claude 3 をリリース してからまだ 3 か月ばかりです。Claude 3 は最先端の人工知能 (AI) モデルファミリーであり、ニーズに合ったインテリジェンス、速度、コストの適切な組み合わせを選択することを可能にします。 6月20日、Anthropic は、近日リリース予定の Claude 3.5 モデルファミリーの最初のリリースである Claude 3.5 Sonnet を発表しました。 Amazon Bedrock で Claude 3.5 Sonnet が利用可能になった ことをお知らせいたします。 Claude 3.5 Sonnet は、インテリジェンスに関する業界の水準を引き上げ、幅広い評価で他の生成 AI モデルを上回るパフォーマンスを発揮しています。これには、Anthropic のこれまで最もインテリジェントなモデルであった Claude 3 Opus が含まれます。Claude 3.5 Sonnet は、オリジナルの Claude 3 Sonnet モデルと同じ速度と コスト で利用できます。実際、Claude 3.5 Sonnet は Opus よりも 80% 低コストであるため、Claude 3 Opus よりも優れたインテリジェンスとスピードを 5 分の 1 の料金で利用できます。 Claude 3.5 Sonnet が示す最先端のインテリジェンスとコスト効率の高い料金により、このモデルは、コンテキストに応じたカスタマーサポート、複数ステップのワークフローのオーケストレーション、コード変換の合理化などの複雑なタスクに最適です。 Claude 3.5 Sonnet は、学部レベルの専門的な知識 (MMLU)、大学院レベルの専門的な推論 (GPQA)、コード (HumanEval) などの新しい業界ベンチマークを達成しています。次の表に示すように、Anthropic によると、Claude 3.5 Sonnet はほぼすべてのベンチマークで OpenAI の GPT-4o と Google の Gemini 1.5 Pro を上回るパフォーマンスを発揮します。 また、Claude 3.5 Sonnet は、Anthropic のこれまでで最も強力なビジョンモデルでもあり、ほとんどのビジョンベンチマークで Claude 3 Opus よりも平均 10% 優れたパフォーマンスを発揮します。さらに、Anthropic によると、Claude 3.5 Sonnet は、ほぼすべてのカテゴリで他の生成 AI モデルを上回るパフォーマンスを発揮します。 Anthropic の Claude 3.5 Sonnet の主な改善点 Claude 3.5 Sonnet のリリースにより、複数の領域で大幅な改善がもたらされ、ソフトウェアデベロッパーや企業は 生成 AI を活用した新しい機能を利用できます。この新しいモデルのいくつかの主な強みを次に示します。 視覚処理と理解 – Claude 3.5 Sonnet は、画像の処理、特にチャートとグラフの解釈において優れた機能を発揮します。不完全な画像からテキストを正確に書き起こします。これは、 小売 、物流、 金融サービス などの業界の中核的な機能であり、テキストのみの場合と比較して、グラフィックやイラストからより多くのインサイトを得られるようにします。Claude 3.5 Sonnet を使用すると、視覚データ処理タスクを自動化し、貴重な情報を抽出して、データ分析パイプラインを強化できます。 ライティングとコンテンツ生成 – Claude 3.5 Sonnet では、ニュアンスとユーモアを理解する能力が飛躍的に高まっています。このモデルは、より自然かつ人間味のあるトーンで、より本物らしく、親しみやすい、質の高い書面コンテンツを生成します。このモデルを使用すると、魅力的で説得力のあるコンテンツを生成し、ライティングワークフローを合理化して、ストーリーテリング機能を強化できます。 カスタマーサポートと自然言語処理 – コンテキストの理解度が高まり、ワークフローのマルチステップオーケストレーションが可能な Claude 3.5 Sonnet は、顧客からの複雑な問い合わせの処理に優れています。この機能により、24 時間体制のサポート、応答時間の短縮、より自然なやり取りが可能になり、最終的には顧客満足度を高めることができます。このモデルを使用すると、カスタマーサポートプロセスを自動化および強化し、エンドユーザーのためにシームレスなエクスペリエンスを提供できます。類似の実装の例については、Amazon Bedrock で Anthropic の Claude 3 モデルを使用して、 DoorDash が生成 AI によるセルフサービスコンタクトセンターソリューションを構築した方法 をご覧ください。 分析とインサイト – Claude 3.5 Sonnet は、非構造化データを簡単に操作し、複数のツールを使用してインサイトを生成することで、データサイエンスの領域における人間の専門知識を強化します。ビジネス戦略からリアルタイムの製品トレンドに至るまで、質の高い統計ビジュアライゼーションと実用的な予測を生成します。Claude 3.5 Sonnet を使用すると、データ分析ワークフローを簡素化し、有益なインサイトを明らかにして、データ駆動型の意思決定を推進できます。 コーディングとソフトウェア開発 – Claude 3.5 Sonnet は、関連ツールが提供されている場合、高度な推論機能とトラブルシューティング機能を使用して、コードを独自に記述、編集、実行できます。Claude 3.5 Sonnet を使用すると、デベロッパーのワークフローを合理化し、コーディングタスクを高速化するとともに、手作業を減らして、全体的な生産性を高めることができます。 Amazon Bedrock コンソールでの Anthropic の Claude 3.5 Sonnet の使用 これは新しいモデルなので、 Amazon Bedrock コンソール に移動し、ナビゲーションペインから [モデルアクセス] を選択して、Claude 3.5 Sonnet へのアクセスを有効にします。 モデルにアクセスできるようになったので、 Our World in Data ウェブサイトの 次の画像から情報を抽出するためにモデルを使用します。 ナビゲーションペインの [プレイグラウンド] セクションで [チャット] を選択し、モデルとして [Anthropic] と [Claude 3.5 Sonnet] を選択します。その後、 [画像] アップロードボタンを選択して前の画像をアップロードし、次のプロンプトを入力して、 [実行] を選択します。 Which countries consume more than 1000 TWh from hydropower? Think step by step and look at all regions.Output in JSON. 結果と、私が実行したことをまとめたアニメーション画像を次に示します。 To determine which countries consume more than 1,000 TWh from hydropower in 2022, I need to carefully examine the map and color-coding.The scale at the bottom shows that dark blue represents consumption between 1,000 TWh and 2,000 TWh. Let's look at each region systematically: 1.North America: Canada is dark blue, indicating it consumes between 1,000-2,000 TWh from hydropower. 2.South America: Brazil is dark blue, also consuming between 1,000-2,000 TWh. 3.Europe: No country is dark blue; all are light green or have no data. 4.Africa: No data available for any country. 5.Asia: China is dark blue, indicating consumption between 1,000-2,000 TWh. 6.Oceania: No country is dark blue; Australia is light green. In summary, there are three countries that consume more than 1,000 TWh from hydropower in 2022: 1.Canada (North America) 2.Brazil (South America) 3.China (Asia) Here's the response in JSON format: ```json { "countries_consuming_over_1000TWh_hydropower": [ { "name": "Canada", "region": "North America", "consumption_range": "1,000-2,000 TWh" }, { "name": "Brazil", "region": "South America", "consumption_range": "1,000-2,000 TWh" }, { "name": "China", "region": "Asia", "consumption_range": "1,000-2,000 TWh" } ] } ``` These three countries stand out as the highest consumers of hydropower energy, each using between 1,000 and 2,000 terawatt-hours in 2022. 画像などの非構造化データから情報を確実に抽出するこのモデルの機能は、新しい可能性の世界を切り開きます。 プレイグラウンドウィンドウの隅にある 3 つの小さなドットを選択し、 [API リクエストを表示] を選択して、 AWS コマンドラインインターフェイス (AWS CLI) および AWS SDK でモデルを使用したコード例を表示します。コード構文を詳しく見てみましょう。 AWS SDK での Claude 3.5 Sonnet の使用 新しい Amazon Bedrock Converse API または Anthropic Claude Messages API を使用して、任意の AWS SDK で Claude 3.5 Sonnet を使用できます。 既に Claude 3 モデルを使用しているコードを更新するために必要なのは、モデル ID を次のように置き換えることだけです。 anthropic.claude-3-5-sonnet-20240620-v1:0 Converse API で画像とテキストを使用する方法を示すために、以前と同じ画像を使用した AWS SDK for Python (Boto3) のサンプル実装を次に示します。 import boto3 from botocore.exceptions import ClientError MODEL_ID = "anthropic.claude-3-5-sonnet-20240620-v1:0" IMAGE_NAME = "primary-energy-hydro.png" bedrock_runtime = boto3.client("bedrock-runtime", region_name="us-east-1") with open(IMAGE_NAME, "rb") as f: image = f.read() user_message = "Which countries consume more than 1000 TWh from hydropower? Think step by step and look at all regions.Output in JSON." messages = [ { "role": "user", "content": [ {"image": {"format": "png", "source": {"bytes": image}}}, {"text": user_message}, ], } ] response = bedrock_runtime.converse( modelId=MODEL_ID, messages=messages, ) response_text = response["output"]["message"]["content"][0]["text"] print(response_text) 実行すると、コンソールにおけるのと類似の出力が表示されます。 Let's approach this step-by-step: 1.First, I'll examine the color scale at the bottom of the map.The darkest blue color represents consumption of 2,000 TWh or more. 2.Now, I'll scan the map region by region: North America: Canada is dark blue, indicating over 1,000 TWh. South America: Brazil is also dark blue, over 1,000 TWh. Europe: No country appears to be dark blue. Africa: No country appears to be dark blue. Asia: China stands out as dark blue, indicating over 1,000 TWh. Oceania: No country appears to be dark blue. 3.To be thorough, I'll double-check for any medium blue countries that might be close to or over 1,000 TWh, but I don't see any that appear to reach that threshold. 4.Based on this analysis, there are three countries that clearly consume more than 1,000 TWh from hydropower. Now, I'll format the answer in JSON: ```json { "countries_consuming_over_1000TWh_hydropower": [ "Canada", "Brazil", "China" ] } ``` This JSON output lists the three countries that visually appear to consume more than 1,000 TWh of primary energy from hydropower according to the 2022 data presented in the map. JSON 構文を指定しなかったため、2 つの回答は異なる形式を使用しています。アプリケーションでは、プロンプトで必要な JSON プロパティを記述するか、または出力で標準形式を取得するためのサンプルを提供できます。 その他の例については、 「Amazon Bedrock ユーザーガイド」のコードサンプル をご覧ください。より高度なユースケースについては、 生成 AI モデルをカスタムツールまたは API に接続する方法 を示す、完全に機能する ツール使用 デモをご覧ください。 AWS CLI での Claude 3.5 Sonnet の使用 コマンドラインが最も速い場合があります。新しいモデルで AWS CLI を使用する方法は次のとおりです。 aws bedrock-runtime converse \ --model-id anthropic.claude-3-5-sonnet-20240620-v1:0 \ --messages '{"role": "user", "content": [{"text": "Alice has N brothers and she also has M sisters.How many sisters does Alice’s brother have?"}]}' \ --region us-east-1 --query output.message.content 出力では、クエリオプションを使用して出力メッセージの内容のみを取得します。 [ { "text": "Let's approach this step-by-step:\n\n1.First, we need to understand the relationships:\n - Alice has N brothers\n - Alice has M sisters\n\n2.Now, let's consider Alice's brother:\n - He is one of Alice's N brothers\n - He has the same parents as Alice\n\n3.This means that Alice's brother has:\n - The same sisters as Alice\n - One sister more than Alice (because Alice herself is his sister)\n\n4.Therefore, the number of sisters Alice's brother has is:\n M + 1\n\n Where M is the number of sisters Alice has.\n\nSo, the answer is: Alice's brother has M + 1 sisters." } ] text を小さな Python プログラムにコピーして、複数行に出力されているのを確認します。 print("Let's approach this step-by-step:\n\n1.First, we need to understand the relationships:\n - Alice has N brothers\n - Alice has M sisters\n\n2.Now, let's consider Alice's brother:\n - He is one of Alice's N brothers\n - He has the same parents as Alice\n\n3.This means that Alice's brother has:\n - The same sisters as Alice\n - One sister more than Alice (because Alice herself is his sister)\n\n4.Therefore, the number of sisters Alice's brother has is:\n M + 1\n\n Where M is the number of sisters Alice has.\n\nSo, the answer is: Alice's brother has M + 1 sisters.") Let's approach this step-by-step: 1.First, we need to understand the relationships: - Alice has N brothers - Alice has M sisters 2.Now, let's consider Alice's brother: - He is one of Alice's N brothers - He has the same parents as Alice 3.This means that Alice's brother has: - The same sisters as Alice - One sister more than Alice (because Alice herself is his sister) 4.Therefore, the number of sisters Alice's brother has is: M + 1 Where M is the number of sisters Alice has. So, the answer is: Alice's brother has M + 1 sisters. これは非常に繊細な理解を要する質問でしたが、Claude 3.5 Sonnet はそれを正しく理解し、その推論をステップバイステップで説明しました。 知っておくべきこと Anthropic の Claude 3.5 Sonnet は、米国東部 (バージニア北部) AWS リージョン において、 Amazon Bedrock で本日からご利用いただけます。 リージョン別の Amazon Bedrock モデルのサポートの詳細については、ドキュメントをご覧ください 。  Amazon Bedrock の料金ページ では、特定のユースケースのコストをご確認いただけます。 Claude 3.5 Sonnet は、より高速かつ強力なモデルへのアクセスをより低コストで提供することで、次のような多くの業界で生成 AI をより簡単かつ効果的に使用できるようにします。 ヘルスケアとライフサイエンス – 医療分野では、Claude 3.5 Sonnet における画像分析の強化、患者のトリアージのための診断アシスタントとしての機能、最新の研究結果を簡単に理解できる形式で要約する機能に期待が寄せられています。 金融サービス – このモデルは、金融トレンドの特定や、クライアントの独自の状況に合わせてカスタマイズおよびパーソナライズされた債務返済計画の作成において、有益なサポートを提供できます。 法律 – 法律事務所は、このモデルを使用して、関連する裁判例や法令を迅速に表示することで、法律関連の調査を加速できます。さらに、このモデルは、契約分析を通じてパラリーガルの効率を高め、標準的な法律文書の草案作成をサポートできます。 メディアとエンターテインメント – このモデルは、ジャーナリストの調査を迅速化し、脚本執筆やキャラクターの確立といったクリエイティブなプロセスをサポートするとともに、有益なオーディエンス感情分析を提供できます。 テクノロジー – ソフトウェアデベロッパーにとって、Claude 3.5 Sonnet は、アプリケーションの迅速なプロトタイピング、レガシーコードの移行、革新的な機能の着想、ユーザーエクスペリエンスの最適化、およびフリクションポイントの特定における機会を提供します。 教育 – 教育機関は、このモデルを使用して助成金申請書の作成を効率化し、新しいトレンドを取り入れた包括的なカリキュラムを策定するとともに、データベースクエリとインサイトの生成を通じて研究支援を受けることができます。 今は生成 AI にとってエキサイティングな時期です。この新しいモデルの使用を開始するには、 「Amazon Bedrock ユーザーガイド」の Anthropic Claude モデルのセクション をご覧ください。また、 community.aws サイトにアクセスして、詳細な技術コンテンツを検索したり、ビルダーコミュニティが自らのソリューションで Amazon Bedrock をどのように利用しているかを学んだりすることもできます。これらの強化された機能で何を実行しているのか、ぜひお知らせください! – Danilo 原文は こちら です。

この記事はソリューションアーキテクトの遠藤宣嗣が翻訳しました。原文は こちら です。 AWS は 2008 年から .NET ワークロードをサポートしています。長年にわたり、.NET は柔軟性の低い Windows 専用のフレームワークから、モジュール型のクロスプラットフォームランタイムへと変化してきました。現在では、レガシーな .NET Framework アプリケーションを Windows 上で実行できるだけでなく、Linux 上でも最新の .NET アプリケーションを実行することができます。これらはすべて AWS で完全にサポートされています。従来の .NET Framework アプリケーションは AWS 上で実行できますが、.NET ワークロードを最新化することでコスト削減、コンテナとサーバーレスの活用、マイクロサービスとクラウドネイティブアーキテクチャへの移行が可能になります。 この記事では、.NET のモダナイゼーションのさまざまなアプローチを AWS の支援ツールやガイダンスとともに紹介します。この記事では、.NET Framework と明確に区別するために、クロスプラットフォームの .NET（以前は .NET Core と呼ばれていた）を「最新の .NET」と呼びます。 .NET アプリケーションをモダナイズする理由 まず「.NET モダナイゼーション」が何を意味するのか、そしてなぜ考慮すべきかについて説明しましょう。.NET モダナイゼーションには、1) アプリケーションコードを最新の .NET にアップグレードすること、2) クラウドとコンテナへの移行、3) ライセンス製品からオープンソースへの移行、4) 最新のアーキテクチャへの移行が含まれます。アプリケーションとともにデータも移行する必要があるため、データベースについても同様の考慮事項があります。 最初に、レガシーな.NET Framework から「最新の .NET」 へ移行することで、新しい機能を利用できるようになり、パフォーマンスが向上します。 .NET Framework 4.8 は Windows で引き続きサポートされていますが、このバージョンの活発な開発は行われていません。対照的に、 最新の .NET は定期的にアップデートされ、毎年、新機能とパフォーマンス改善が行われています。 2つ目に、スケールと従量課金の柔軟性があるクラウドに移行することができます。クラウドでは、デファクトスタンダードとなっているコンテナを使用することもできます。 コンテナを使用することで、アプリケーションの移植性が高まり、サーバーの使用効率が上がり、クラウドにおけるサービスの選択肢が広がります。AWS のコンテナ サービスの詳細は、 AWS でのコンテナ をご覧ください。 3つ目は、オープンソース製品に移行することでコストを削減できます。「最新の .NET」 コードは Linux 上で OS ライセンスの料金なしで実行できます。また、SQL Server やその他のプロプライエタリなリレーショナルデータベースからオープンソースのデータベースに移行することで、ライセンス料金を削減できます。AWS のリレーショナルデータベースや目的別のデータベースの詳細は、 AWS クラウドデータベース をご覧ください。 4つ目に、クラウドでアーキテクチャをモダナイズできます。 単一の大規模な「モノリシック」アプリケーションをマイクロサービスに変換することで、疎結合と複雑さの軽減による技術的・組織的なメリットが得られます。AWS でのマイクロサービスの詳細は、 マイクロサービス で学ぶことができます。さらに一歩進めて、完全にクラウドネイティブなアーキテクチャを採用し、クラウドのメリットを最大限に活用することもできます。マネージドサービス、サーバーレス、目的別のデータベース上に構築されたイベント駆動型のソリューションは、疎結合で俊敏性と効率性に優れ、監査可能なものです。これらの詳細は、 クラウドネイティブとは 、 イベント駆動型アーキテクチャとは 、 AWS でのサーバレス  で学ぶことができます。 このような選択肢がある中で、.NET アプリケーションのモダナイゼーションをどこから始めたらいいのか、どこを目指すのか迷うかもしれません。それぞれのアプローチのメリット、技術的な作業、必要な労力を理解することが役立ちます。 モダナイゼーションへのアプローチ AWS では、モダナイゼーションを旅路に例えることがありますが、それは誰にとっても同じものではありません。AWS で .NET アプリケーションをモダナイズするために複数のアプローチがあり、その中にはよりシンプルなものもあります。AWS の支援ツールを使ってマネージドサービスを利用する 4 つのアプローチを見ていきましょう。 アプローチ ツール メリット ポートフォリオを評価して、モダナイゼーション戦略を立案する Migration Hub Strategy Recommendations 複数のアプリケーションをモダナイズするための最適な戦略とアプローチを特定する Windows コンテナ上で .NET Framework をリプラットフォームする AWS App2Container コードを変更せずに最小限の労力で AWS に移行する。Windows ライセンス料を削減するためにサーバーを統合する Linux コンテナ上のモダンな .NET に .NET Framework をリファクタリングする AWS Toolkit for .NET Refactoring、または Porting Assistant for .NET OS のライセンス料なしで Linux 上で実行することによりコストを削減する モノリシックな .NET アプリケーションをマイクロサービスにリファクタリングする AWS Microservice Extractor for .NET スケーラビリティ、アジリティ、安定性の向上 アプリケーションポートフォリオの評価とモダナイゼーションの計画 どこから始めれば良いか分からない場合は、ここから始めてください。モダナイズするアプリケーションが複数ある場合は、個々のアプリケーションに焦点を当てる前に、アプリケーションポートフォリオの評価を行うことをおすすめします。そうすることで、モダナイゼーションの優先順位が明確になり、戦略の特定につながります。これは、旅行の前に計画を立てるのと同じように、モダナイゼーションを始めるのに理想的な出発点です。モダナイゼーションのスピードを上げることができる、繰り返し適用できるパターンが見つかるかもしれません。 AWS Migration Hub Strategy Recommendations (MHSR) は、オンプレミスまたは AWS で実行されているアプリケーションの移行とモダナイゼーションの戦略を構築するのに役立ちます。MHSR はサーバー、アプリケーションのソースコード、データベースを分析します。そして、大規模なモダナイゼーションを支援するのに役立つ最適な戦略とツールに関するガイダンスを提供します。 Windows コンテナ上の .NET Framework のリプラットフォーム .NET Framework の IIS Web アプリケーション を Windows　コンテナを使用して、通常はコードを変更せずに、最小限の労力で AWS に移行できます。アプリケーションをコンテナ化することで、サーバーを統合し、コンピューティングリソースをより効率的に使用できるため、Windows ライセンスコストを削減できます。コンテナ化されたアプリケーションは、最終的に Amazon Elastic Container Registry (ECR) の Windows コンテナイメージになります。Windows コンテナは、 Amazon Elastic Container Service (Amazon ECS) で で、あるいは、Kubernetes がお好みの場合は、 Amazon Elastic Kubernetes Service (Amazon EKS) でホストできます。Amazon ECS にデプロイする場合、 AWS Fargate を使用して、Windows コンテナをサーバーレスでホストするオプションもあります。 AWS App2Container (A2C) コマンドラインツールを使用すると、アプリケーションを分析し、Amazon ECS または Amazon EKS 向けの正しい依存関係、ネットワーク構成、デプロイ手順を含むコンテナイメージを自動生成できます。A2C は AWS へのデプロイも処理します。 A2C の仕組みは次の通りです。まず、A2C はサーバーをスキャンして Web アプリケーションのインベントリを作成します。次に、選択した .NET Framework IIS アプリケーション用の Windows コンテナ イメージが作成されます。3つ目に、デプロイメント アーティファクトを使用した CI/CD パイプラインが作成されます。最後に、Amazon ECS または Amazon EKS 上でサービスが作成されます。これで、.NET Framework アプリが AWS 上の Windows コンテナで実行されるようになります。このモダナイゼーションパスを完了するには、データベースを AWS に移行し、元の環境から他のアプリケーションの依存関係を移行する必要もあります。 .NET Framework から Linux コンテナ上の「最新の .NET」へのリファクタリング .NET Framework アプリケーションを「最新の .NET」 に移植し、Linux 上で実行することでライセンスコストを節約できます。移行が完了すると、 AWS App Runner 、 Amazon ECS 、または Amazon EKS で管理された Linuxコンテナ内でモダナイズされた dotnet アプリケーションを実行できます。AWS App Runner はよりシンプルな Web アプリケーションに最適であり、Amazon ECS と Amazon EKS は複数のコンテナサービスのオーケストレーションを処理できます。 AWS Toolkit for .NET Refactoring（英語） または Porting Assistant for .NET ツールを使用して、移行作業を迅速に開始しましょう。これらの支援ツールは、.NET Framework アプリケーションをスキャンして、「最新の .NET」 との互換性の問題を特定し、既知の置き換え候補を検索し、詳細な互換性評価を生成し、コードをLinux に対応するように変更します。おそらく手動での移行作業が必要になることもありますが、これらの支援ツールが大部分の作業を肩代わりしてくれます。互換性評価は、 レガシーな WCF アプリケーションを CoreWCF に移行する（英語） など、移植の問題を解決するための戦略とソリューションを提示してくれます。 どちらの移行ツールを使用すべきか検討する際、Porting Assistant for .NET はオープンソースであるのに対し、.NET Refactoring 用の Toolkit は AWS 環境でのテストなど追加機能を提供し、Visual Studio に統合されていることを考慮してください。 モノリスからマイクロサービスへのリファクタリング マイクロサービスは、ソフトウェア開発におけるアーキテクチャ上のアプローチであり、ソフトウェアを小さな独立したサービスで構成し、明確に定義された API を介して通信します。密結合のモノリシックなアプリケーションと比較して、マイクロサービスはアプリケーションのスケーラビリティを向上させ、開発速度を速めます。マイクロサービスは技術的な面だけでなく、組織的な面でも優れています。各サービスは最も適したチームが管理できるからです。AWS のマイクロサービスの詳細は、 マイクロサービス をご覧ください。 マイクロサービスへの移行は、 Strangler Fig（英語） パターンに従い、 AWS Microservice Extractor for .NET ツールを使用することで、徐々に進めることができます。このツールは、.NET Framework とモダン .NET アプリケーションの両方のリファクタリングを簡単にします。Microservice Extractor はアプリケーションを分析し、コンポーネントと依存関係を可視化します。機械学習に基づいてマイクロサービス化に適した候補を推奨したり、コンポーネントを手動でグループ化したりすることも可能です。ビジネスドメインを分離し依存関係を取り除くことでコードのリファクタリングを行い、ツールを使用してグループを個別のサービスプロジェクトに抽出します。Microservice Extractor は、Porting Assistant for .NET との統合を通じて、サービスを抽出しながら .NET Framework コードを最新の .NET に移植できます。AWS 上の .NET マイクロサービスへのリファクタリングの詳細は、テクニカルガイドの .NET アプリケーションのモノリスからマイクロサービスへの移行（英語） を参照してください。 まとめ この記事では、.NET のモダナイゼーションに向けたい幾つかのアプローチを紹介し、その過程で AWS が提供する支援ツールがどのようにガイドして作業負荷を軽減してくれるかについても触れました。.NET アプリケーションのモダナイゼーションを開始するには、 AWS で .NET ワークロードをモダナイズ をご覧ください。 そこでは、これらのアプローチに関するガイダンス、ツール、デモ、詳しい解説などの情報を参照できます。この投稿で説明したアプローチに加えて、 AWS で Windows ワークロードをモダナイズ 、 Microsoft ワークロードモダナイゼーションガイド（英語） 、 Microsoft ワークロード向け AWS モダナイゼーションツール リファレンスガイド（英語） で、追加のアプローチを確認できます。 投稿者について David Pallmann David Pallmann は AWS の EC2 チームのシニアプロダクトマネージャーです。彼のミッションは、AWS を .NET 開発者にとってワールドクラスのエクスペリエンスにすることです。David は以前、エンジニアリング、コンサルティング、プロダクト、テクニカルマネージャの役割を担っていました。彼は WCF に取り組み、後に最初の .NET ベースのエンタープライズサービスバスである Neuron ESB を開発しました。X では @davidpallmann でフォローしてください。 翻訳者について 遠藤 宣嗣 遠藤 宣嗣 は、AWS Japan のソリューションアーキテクト　(SA)として、日本市場において ISV ベンダーを中心にお客様の SaaS Journey とマイクロソフトワークロードのアプリケーション モダナイゼージョンを支援しています。

6月19日、 Amazon SageMaker でのフルマネージド型 MLflow 機能 の一般提供についてお知らせいたします。 MLflow は広く使用されているオープンソースツールであり、機械学習 (ML) チームが ML ライフサイクル全体を管理する上で重要な役割を果たします。今回の新リリースにより、わずか数ステップで MLflow Tracking Server を簡単にセットアップおよび管理できるようになり、お客様はプロセスの合理化と生産性の向上を実現できます。 MLflow を活用すると、データサイエンティストと ML デベロッパーはモデルトレーニングの複数回の試行を実験内のランとして追跡し、それらのランを視覚化と比較して、モデルを評価し、最適なモデルをモデルレジストリに登録することができます。Amazon SageMaker では、MLflow のセットアップと管理に必要とされる、競合他社との差別化にはつながらない手間のかかる作業が不要になります。また、ML 管理者は AWS で安全かつスケーラブルな MLflow 環境をすばやく効率的に構築できるようになります。 SageMaker でのマネージド MLflow の主要なコンポーネント SageMaker のフルマネージド型 MLflow 機能は、次の 3 つの主要なコンポーネントを中心に構築されています。 MLflow Tracking Server – SageMaker Studio UI を使用すると、わずか数ステップで MLflow Tracking Server を作成できます。このスタンドアロン HTTP サーバーは、ランと実験を追跡するための複数の REST API エンドポイントを提供するため、ML 実験のモニタリングを効率的に開始できます。セキュリティをさらに細かくカスタマイズするには、 AWS コマンドラインインターフェイス (AWS CLI) を使用することもできます。 MLflow バックエンドメタデータストア — メタデータストアは MLflow Tracking Server の重要な部分であり、実験、ラン、アーティファクトに関連するすべてのメタデータが保持されます。これには、テスト名、ラン ID、パラメーター値、メトリクス、タグ、アーティファクトの場所が含まれ、ML テストを包括的に追跡および管理できます。 MLflow アーティファクトストア – このコンポーネントは、トレーニング済みモデル、データセット、ログ、プロットなど、ML 実験中に生成されたすべてのアーティファクトの保存場所を提供します。 Amazon Simple Storage Service (Amazon S3) バケットを利用して、これらのアーティファクトを安全かつ効率的に保存するためのカスタマー管理型 AWS アカウントを提供します。 Amazon SageMaker with MLflow の利点 Amazon SageMaker と MLflow を組み合わせて使用すると、機械学習ワークフローを合理化および強化できます。 包括的な実験トラッキング: ローカル統合開発環境 (IDE)、SageMaker Studio のマネージド IDE、SageMaker トレーニングジョブ、SageMaker 処理ジョブ、SageMaker パイプライン全体にわたって MLflow の実験を追跡します。 MLflow の全機能: MLflow トラッキング、MLflow 評価、MLflow モデルレジストリなどのすべての MLflow 実験機能を使用して、トレーニング反復の結果を簡単に比較および評価できます。 統合モデルガバナンス: MLflow に登録したモデルは自動的に SageMaker モデルレジストリに表示され、統合モデルガバナンスエクスペリエンスが提供されるため、カスタムコンテナを構築することなく MLflow モデルを SageMaker 推論にデプロイできます。 効率的なサーバー管理: SageMaker API または SageMaker Studio UI を使用して、必要に応じて MLflow Tracking Server のプロビジョニング、削除、アップグレードを行います。SageMaker は、お客様が基盤となるインフラストラクチャを管理しなくても、Tracking Server のスケーリング、パッチ適用、継続的なメンテナンスを管理します。 セキュリティの強化: AWS Identity and Access Management (IAM) を使用して MLflow Tracking Server へのアクセスを保護します。特定の MLFlow API へのアクセスを許可または拒否する IAM ポリシーを記述して、ML 環境の強固なセキュリティを確保します。 効果的なモニタリングとガバナンス: Amazon EventBridge と AWS CloudTrail を使用して MLflow Tracking Server のアクティビティをモニタリングし、Tracking Server の効果的なガバナンスをサポートします。 MLflow Tracking Server の前提条件 (環境設定) SageMaker Studio ドメインの作成 新しい SageMaker Studio エクスペリエンス を使用して SageMaker Studio ドメインを作成できます。 IAM 実行ロールの設定 MLflow Tracking Server には、Amazon S3 へのアーティファクトの読み取りおよび書き込みを行ったり、モデルを SageMaker に登録したりするための IAM 実行ロールが必要です。Studio ドメイン実行ロールを Tracking Server 実行ロールとして使用することも、Tracking Server 実行ロール用に別のロールを作成することもできます。このために新しいロールを作成する場合は、IAM ロールの詳細について「 SageMaker デベロッパーガイド 」をご覧ください。Studio ドメイン実行ロールを更新する場合、ロールに必要な IAM ポリシーの詳細については、「SageMaker デベロッパーガイド」を参照してください。 MLflow Tracking Server の作成 このチュートリアルでは、Tracking Server の バージョン (2.13.2)、 サイズ (小)、 実行ロール (Studio ドメイン実行ロール) などのデフォルト設定を使用して、MLflow Tracking Server を作成します。Tracking Server のサイズによって、サポートできる使用量は異なります。25 ユーザー以下のチームには、Small Tracking Server を使用することをお勧めします。Tracking Server 設定の詳細については、「 SageMaker デベロッパーガイド 」を参照してください。 まず、先ほど説明した環境設定で作成した SageMaker Studio ドメインの [アプリケーション] で [MLflow] を選択し、[ 作成 ] を選択します。 次に、Tracking Server の 名前 と アーティファクトの保存場所 (S3 URI) を指定します。 MLflow Tracking Server の作成には最大 25 分かかる場合があります。 トレーニングランの追跡と比較 MLflow のメトリクス、パラメータ、アーティファクトのログ記録を開始するには、作成ステップで割り当てた Jupyter Notebook と Tracking Server ARN が必要です。MLflow SDK を使用してトレーニングランを追跡し、MLFlow UI を利用してそれらを比較できます。 MLFlow モデルレジストリから SageMaker モデルレジストリにモデルを登録するには、 AWS Signature V4 を使用して MLFlow SDK によって行われたすべての MLFlow API リクエストを認証するための sagemaker-mlflow プラグインが必要です。 MLFlow SDK と sagemaker-mlflow プラグインをインストールする まず、Notebook に MLFlow SDK と sagemaker-mlflow Python プラグインをインストールします。 pip install mlflow==2.13.2 sagemaker-mlflow==0.1.0 実験でランを追跡する 実験のランを追跡するには、次のコードを Jupyter Notebook にコピーします。 import mlflow import mlflow.sklearn from sklearn.ensemble import RandomForestClassifier from sklearn.datasets import load_iris from sklearn.model_selection import train_test_split from sklearn.metrics import accuracy_score, precision_score, recall_score, f1_score # Replace this with the ARN of the Tracking Server you just created arn = 'YOUR-TRACKING-SERVER-ARN' mlflow.set_tracking_uri(arn) # Load the Iris dataset iris = load_iris() X, y = iris.data, iris.target # Split the data into training and testing sets X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2, random_state=42) # Train a Random Forest classifier rf_model = RandomForestClassifier(n_estimators=100, random_state=42) rf_model.fit(X_train, y_train) # Make predictions on the test set y_pred = rf_model.predict(X_test) # Calculate evaluation metrics accuracy = accuracy_score(y_test, y_pred) precision = precision_score(y_test, y_pred, average='weighted') recall = recall_score(y_test, y_pred, average='weighted') f1 = f1_score(y_test, y_pred, average='weighted') # Start an MLflow run with mlflow.start_run(): # Log the model mlflow.sklearn.log_model(rf_model, "random_forest_model") # Log the evaluation metrics mlflow.log_metric("accuracy", accuracy) mlflow.log_metric("precision", precision) mlflow.log_metric("recall", recall) mlflow.log_metric("f1_score", f1) MLflow UI でランを表示する ステップ 2 で示した Notebook を実行すると、MLflow UI に新しいランが表示されます。 ランを比較する random_state を変更してトレーニングランごとに異なるメトリクス値を生成すると、この Notebook を複数回実行できます。 候補モデルを登録する ステップ 4 で説明したとおり、複数回のランを比較したら、要件に最も一致するメトリクスを備えたモデルを MLflow モデルレジストリに登録できます。モデルを登録すると、本番環境への導入への潜在的な適合性が示され、この適合性を検証するためのさらなるテストが行われます。MLflow に登録されたモデルは SageMaker モデルレジストリに自動的に表示され、統一されたモデルガバナンスエクスペリエンスとなり、MLFlow モデルを SageMaker 推論にデプロイできるようになります。これにより、主に MLflow を実験に使用するデータサイエンティストは、SageMaker Model Registry を使用してモデルの本番環境へのデプロイを管理する ML エンジニアにモデルを引き渡すことができます。 MLflow モデルレジストリに登録されているモデルは次のとおりです。 SageMaker モデルレジストリに登録されているモデルは次のとおりです。 クリーンアップ 一度作成した MLflow Tracking Server では、削除または停止するまでコストが発生します。Tracking Server の請求は、サーバーの稼働時間、選択したサイズ、Tracking Server に記録されたデータ量に基づきます。Tracking Server を使用していないときは停止してコストを節約したり、API や SageMaker Studio UI を使用して削除したりできます。価格設定の詳細については、 Amazon SageMaker の料金 を参照してください。 今すぐご利用いただけます SageMaker with MLflow は、中国と米国の GovCloud リージョンを除く、SageMaker Studio が利用可能なすべての AWS リージョンで 一般提供されています。この新機能をぜひ試して、機械学習プロジェクトの効率性と制御性の向上を体験してください。詳細については、SageMaker with MLflow 製品詳細ページ をご覧ください。 詳細については、「 SageMaker デベロッパーガイド 」をご覧ください。また、 AWS re:Post for SageMaker または通常の AWS サポートの連絡先を通じて、ぜひフィードバックをお寄せください。 – Veliswa 原文は こちら です。

この記事はソリューションアーキテクトの遠藤宣嗣が翻訳しました。原文は こちら です。 2024 年 6 月 20 日更新： 当初、このアナウンスでは .NET Framework の最小バージョンは 4.6.2 に変更される予定でした。 しかし、この作業の開発中に、SDK の長期的な方向性を考えると、 4.7.2 がより適切な最小ターゲットフレームワーク であると判断しました。 4.7.2 を使用することで、SDK は将来必要となるより多くの暗号アルゴリズムを利用できるようになります。また、このバージョンには特殊文字使用時のエンコードや署名の不一致に影響する System.Uri クラスの修正も含まれています。 2024 年 8 月 15 日から、.NET 用 AWS SDK は .NET Framework 3.5 のサポートを終了し、最小の .NET Framework バージョンを 4.7.2 に変更します。 変更の背景 .NET Framework 3.5 は、AWS のサービスがまだ少数しかなかった 2007 年にリリースされました。それ以来、クラウドアプリケーションの複雑さと言語ランタイムの要件は成長してきました。.NET 自体も、.NET での非同期プログラミングの記述方法を含め、.NET Framework 3.5 以降劇的に変化しています。これらの理由から、AWS SDK for .NET は .NET Framework 3.5 のサポートを終了します。 加えて、AWS SDK for .NET は現在 .NET Framework 4.5 を対象としていますが、これは 2016 年 1 月 にサポート終了となりました。.NET Framework 4.X プラットフォームに対する AWS SDK for .NET のサポートは、最小で 4.7.2 に引き上げられます。.NET Framework 4.7.2 は Windows Server 2019 のデフォルトインストールであり、Windows Server 2008 R2 SP1 や Windows 7 など過去のバージョンでも使用できます。 AWS SDK で .NET Framework 4.7.2 を使用する変更を行うことで、チームは SDK のモダナイズを開始し、より高パフォーマンスな SDK を提供できるようになります。 この SDK は、AWS SDK for .NET のすべての .NET ターゲットにわたって、.NET Standard 2.0 ライブラリと API を使用できるようになります。 これにより、SDK は JSON パースに System.Text.Json を使用し、Span や ArrayPool のようなメモリ効率の高い API を使用できるようになります。これらの変更により、アロケーションとガベージコレクションが削減されるため、.NET SDK を使用するアプリケーションのパフォーマンスが向上し、メモリフットプリントが小さくなります。 SDK のモダナイズは継続的な作業であり、最小限の .NET Framework ターゲットを更新することから始まります。 まとめ アップグレードできないアプリケーションを実行している場合は、現在のバージョンの AWS SDK for .NET を引き続き使用できます。ただし、2024 年 8 月 15 日以降、AWS SDK for .NET の新しいバージョンは、これらの古いバージョンの .NET Framework をサポートしなくなります。SDK のソースコードは、 GitHub で公開されています。.NET Framework 3.5 のサポートが終了すると、.NET Framework 3.5 をサポートしていた SDK の最後のバージョンが、別の Git ブランチにアーカイブされます。 フィードバック AWS SDK for .NET の変更は、 GitHub リポジトリで行われます。Issue や Discussion を開くことで、リポジトリ上の変更に対するフィードバックを提供できます。 投稿者について Norm Johanson Norm Johanson は、20年以上ソフトウェア開発者としてあらゆる種類のアプリケーションを開発してきました。2010年以来、彼はAWS で .NET 開発者のエクスペリエンスにフォーカスして働いています。X @ socketnorm と GitHub @ normj で見つけることができます。 翻訳者について 遠藤 宣嗣 遠藤 宣嗣 は、AWS Japan のソリューションアーキテクト　(SA)として、日本市場において ISV ベンダーを中心にお客様の SaaS Journey とマイクロソフトワークロードのアプリケーション モダナイゼージョンを支援しています。

AWS では、信頼性とは許容できる範囲内で大規模な中断に耐え、許容できる期間内に回復できる能力であると考えています。サービスの信頼性は、その目標を達成するために、可用性やパフォーマンスのような従来の基準を超えるものです。システムまたはアプリケーションのコンポーネントは、時間の経過とともにやがて故障します。当社の CTO である Werner Vogels が言うように、「Everything fails, all the time（故障しないものは無い）」のです。問題は、エンドユーザーに影響を与えずにシステムまたはアプリケーションがどのように障害に耐えられるか、そしてシステムが障害に対してどの程度回復力があるかということです。私たちのお客様はインシデントによる被害範囲を縮小し、ビジネスが必要とする信頼性、パフォーマンス、スケーラビリティの期待に応えるための支援を常に求めています。 このブログでは、インシデント発生時の迅速な対応のために、パフォーマンスを客観的に測定し、信頼性を正確に報告することでチームの成功を後押しする信頼性に関するベストプラクティスについて説明します。また、 サービスレベル目標 (SLOs) を、Amazon CloudWatch Application Signals を使ってすべての Amazon CloudWatch メトリクスから設定、監視し、アラートする方法についても説明します。 サービスレベル管理 (SLM) サービスレベル管理 (SLM) は、お客様に提供する IT サービスとサービスレベルを定義、交渉、管理するためのフレームワークやプロセスを提供します。このフレームワークには、サービスの可用性、品質、データセキュリティ、スループットといった、いくつかの重要な要素が含まれます。これは、お客様の目的と、サービスプロバイダである自社の両方の目的を守ることを目指しています。初めに、お客様に対する保証を表す用語と、サービスの健全性を示す追跡可能な指標について理解しましょう。 SLI (Service Level Indicator) は、提供されるサービスレベルのある側面を慎重に定義した定量的な指標です。 SLO (Service Level Objective) は、SLI によって一定期間測定されたサービスレベルの目標値または値の範囲です。 SLA (Service Level Agreement) は、お客様に約束するサービスレベルを概説した、お客様との合意です。また、要件を満たせない場合の対応策 (追加サポートや価格割引など) も詳細に規定されています。 エラーバジェット は、SLO を満たせなかった割合です。これは 100 % の信頼性と SLO 目標値の差に相当します。つまり、エラーバジェットとは、他の SLO を満たすための SLO です。 次の図は、SLA、SLO、SLI がどのように相互作用するかを表しています。お客様 (サービス利用者) はサービスを所有するチームの外部にいます。サービスチーム内には、ビジネスオーナーやカスタマーサクセスエンジニアなどのセールス機能があり、プロダクトオーナー (ロードマップを所有) と、サービスの開発と運用を行うエンジニアリングチームがいます。エンジニアリングチームは、サービスを測定する SLI を所有し、SLO を推進します。通常、プロダクトとエンジニアリングは SLA に情報を与える SLO を共同で所有しています。お客様は SLA を確認でき、サービスの状況を把握できますが、通常、SLO と SLI はサービスチームの境界を超えて共有されません。 実効的な SLO SLO は性能基準が満たされることを保証し、主要業績評価指標 (KPI) を達成するための実績データとして機能します。そのため、SLO は SMART (具体的、測定可能、達成可能、関連性がある、期限付き) である必要があります。SLO は、達成すべき目標を明確に定義し、進捗状況を測定する方法を提供し、現在のリソースと能力を考慮して現実的に目標を達成できることを保証し、ビジネス目標と一致し、目標達成のための期限を設定する必要があります。効果的な SLO の主な利点は、効果的な意思決定を可能にする可視性の向上と、事業の中断を効果的に防止するサービス品質の向上の２つです。これらは、カスタマーエクスペリエンスの評価に役立つ効果的な SLO のほんの一例です。 一般的な課題 SLO は、エンドユーザーとビジネスにとって何が最も重要かを効果的に優先順位付けするのに役立つ強力なツールです。しかし、導入には課題もあります。以下は、お客様の間でよく見られる課題の一部です。 SLI に適切なメトリクスをキャプチャする : 効果的な SLO の出発点は適切なメトリクスです。ただし、使用する適切なメトリクスを特定し、ビジネスに影響を与えるメトリクスを正しく計測できるようにサービスが実装されているかを確認することは難しい場合があります。 違反にいつ、どのように対応すべきかを知る : 適切なサービス、メトリクス、目標を特定したら、次の課題はエラーバジェットの計算方法と、バーンレートに基づく適切なレベルのアラートを作成する方法を知ることです。 SLO を診断ツールに接続する : SLO 違反に対して運用アラームに対応する予定がある場合、SLO の監視ツールとアプリケーションパフォーマンスのデバッグに使用するツールが連携していないと、SLO を満たしていない理由を特定するのが難しくなります。エクスペリエンスの繋がりが深いほど、より多くの洞察が得られ、SLO のパフォーマンスを向上させるために何に焦点を当てるべきかをより早く特定できます。 ベストプラクティス 組織におけるサービスレベル目標の導入を成功させるには、チーム間のコラボレーションが最も重要です。SLA を満たすための SLO を作成する際は、次のベストプラクティスを検討することをお勧めします。 全てのステークホルダーの目標を一致させる ：効果的な SLO を設定する際、プロダクト、エンジニアリング、オペレーションの全てで目標を合わせることが重要です。この目標の統一により、信頼性を検査し改善する SLO の実践を強化できます。 100 % を達成するのは現実的ではない ：好ましくないかもしれませんが、故障しないものはありません。そのため、100% の信頼性という目標を設定することは失敗の元になります。代わりに、達成すべき現実的な目標は何か、エンドユーザーはサービスに何を期待するかを考えてください。また、サービスは失敗したリクエストを再試行するように設計する必要があることを覚えておいてください。 対応計画を立てる（自動診断） ： SLO 違反に対して、警告をいつ、どのように受け取るかを慎重に検討することが重要です。一部の運用イベントは、他のイベントよりも速くバーンレートを消費するため、より重大なアラートを必要とする場合があります。可能な限り、SLO に影響を及ぼすアプリケーションの問題を自動検知し、改善するための自動化を利用しましょう。 文書化し、共有し、オープンスタンダードを活用する ：組織全体で SLO の採用を進める際は、チームが一貫したパターンを使用できるように、SLO の文書化と共有のための共通のフレームワークを用意しておくとよいでしょう。日次または週次の運用会議に SLO のレビューをどのように組み込むかを検討してください。 繰り返す （フィードバックループ、目標の再評価）： 厳格なSLAとは異なり、SLO はより柔軟で、サービスの信頼性を向上させることを目的としています。SLO の目標を達成できているかを継続的に評価し、ビジネスとお客様にとって適切な信頼性のバランスを実現できるように繰り返すことが重要です。 Amazon CloudWatch でネイティブ の SLO を作成する方法 Amazon CloudWatch Application Signals の導入により、AWS ネイティブで SLO を作成および監視できるようになりました。これらの SLO と Application Signals を使って、手動でのインストルメンテーション、メトリクス計算、観測された問題と根本原因の相関付けなどの作業なしに、重要なビジネス目標に対するアプリケーションのパフォーマンスを追跡できるようになります。CloudWatch Application Signals は、SLO を APM エクスペリエンスに接続できる包括的なアプリケーションパフォーマンス監視ソリューションを提供します。現在 CloudWatch で利用可能なメトリクスを使って SLO を開始できるため、簡単に使い始めることができます。 たとえば、ユーザーがログインしてワークアウトを確認したり、主要なフィットネスアクティビティを確認できるアプリケーションを提供するフィットネス会社で働いているとしましょう。このアプリケーションは、 Application Load Balancer (ALB) の背後にある EC2 インスタンス フリートで実行されます。ある日、サポートチームから、アプリにログインしてもワークアウトが表示されないという苦情がユーザーから寄せられているという緊急の通知が届きました。この問題を解決した後、同じようにエンドユーザー体験が低下させるような大規模な問題が発生したときに的確に把握できるように、可用性を監視する SLO を設定する必要があります。 CloudWatch に既にある ALB メトリクス を使用して可用性をモニタリングするための SLO を作成する方法を見てみましょう。この例では、1 分間のメトリクス期間においてリクエストの 95% が 28 日間にわたって99% 正常に処理されるという目標を設定します。これにより、毎分 95% を超えるリクエストの成功という期待どおりの結果が得られない場合に迅速に通知を受けることができます。また、すぐに対処する必要はないが、最終的には SLO 違反につながるような小さな問題を特定することもできます。 まず、左側のナビゲーションの Application Signals > サービスレベル目標 (SLO) を選択し、CloudWatch コンソールの SLO ダッシュボードに移動します。 次に SLO を作成 をクリックし、 SLI と SLO を定義します。 SLO のフォームから、 サービスレベル目標 (SLO) 名を設定 フィールドに名前 「My Availability SLO」を入力し、SLI に CloudWatch メトリクス を選択します。 次に、評価するメトリクスを選択します。このケースでは、アプリケーションが利用可能かどうかを評価したいとします。 CloudWatch メトリクス の Metric Math を使用して、1 分以内に 5xx エラーにならなかったリクエストの割合を計算します。 CloudWatch メトリクスを選択 ボタンをクリックし、 メトリクスの選択 ウィジェットを表示します。最初に 名前空間 ApplicationELB を選択し、次に AppELB 別 メトリクス を選択して ALB のメトリクスを検索します。次に、 RequestCount と HTTPCode_ELB_5XX_Count の 2 つのメトリクスを選択します。これら 2 つのメトリクスを使用して、5xx エラーを返さなかったリクエストの割合を計算し、アプリケーションの可用性を測定します。  RequestCount メトリクスと HTTPCode_ELB_5XX_Count メトリクスを選択したら、グラフ化したメトリクス タブを選択し、5xx エラーを返さなかったリクエストの割合を計算する数式を作成します。まず、両方のメトリクスの 統計 を サンプル数 に変更し、 期間 を 1 分 に変更します。 RequestCount の ID を 「totalrequests」 に変更し、 HTTPCode_ELB_5XX_Countm の ID を 「failedrequests」 に変更します。次に、 数式を追加 を選択し、 空の式で始まる を選択します。 数式の編集 で次の式を追加して成功したリクエストの割合を計算します。 ((totalrequests-failedrequests)/totalrequests)*100 。最後に、CloudWatch メトリクスのウィンドウで選択される唯一のメトリクスが数式になるように元のメトリクスの選択を解除し、 メトリクスの選択 をクリックします。 SLI に使用するメトリクスを定義したら、サービスがその目標を達成しているかどうかを示す条件を設定します。今回は 95 以下 をしきい値として設定します。つまり、リクエストの成功率が 95% 以下だった時間は不適格な時間と判定されるということです。 次に、SLO の目標とその目標をどのくらいの期間で測定するかを設定する必要があります。CloudWatch Application Signals では、SLO の時間間隔を選択する際に、 ローリング日 (連続日)と カレンダーか月 の 2 つのオプションが用意されています。最長の期間は12 か月です。この例では、「28 ローリング」日を選択し、達成目標を 99% に設定します。また、 警告のしきい値 を設定を登録することで、SLO を警告状態として指定するタイミングを選択できます。 オプションで、SLI がしきい値を満たさないとき (SLI 状態アラーム) 、 SLO 目標に違反したとき（SLO 達成目標アラーム）、警告のしきい値を超えたとき（SLO 警告アラーム）に通知する 3 つのアラームを自動的に作成することができます。次に、 SLOを作成 を選択します。 SLO を作成すると、数分以内に SLO ページに、達成度やエラーバジェットなどの SLO メトリクスが表示されます。また、 Application Signals は、より高度なアラームやダッシュボードのユースケースに使用できる達成度(AttainmentRate)とSLI 違反回数(BreachedCount) のメトリクスを公開しています。 次のステップ Application Signalsを使用すると、ビジネスへの影響が大きいメトリクスに焦点を当てた サービスレベル目標 (SLO ) を作成できます。これにより、重大な問題に優先順位を付け、ビジネス KPI との相関性を高めるために SLO を継続的に微調整できます。根本原因の特定を迅速化するために、Application Signals は CloudWatch Synthetics と連携して重要な API とユーザー操作を監視し、 CloudWatch RUM と連携して実際のユーザーパフォーマンスを監視することで、アプリケーションのパフォーマンスを包括的に監視できます。 CloudWatch Application Signalsを使用すると、アプリケーションを手動でインストルメントしなくても、AWS上のアプリケーションのパフォーマンスを簡単に確認できます。利用方法については、この ブログ を参照してください。 re:Invent 2023 の動画では、JP モルガン・チェースが Amazon CloudWatch Application Signals を使用してビジネス目標に対するパフォーマンスをトラックした方法をご覧頂けます。 Amazon CloudWatch Application Signals を使用したアプリケーションモニタリングの詳細については、この YouTube 動画 を確認してください。 この新機能を実際に体験するには、 ハンズオンワークショップ をご利用ください。ここでは、Amazon EC2 上で実行している Amazon EKS ワークロードをモニタリングするためにApplication Signals を使う方法を学べます。 結論 このブログでは、パフォーマンスを客観的に測定し、信頼性を正確に報告し、アラートによる混乱の軽減とインシデント発生時の迅速な対応を可能にすることで、チームを成功へと導く効果的な SLO のベストプラクティスについて説明しました。SLO の継続的な改善と定期的な見直しは、SLO が現実的であり続け、システムの機能とビジネス目標の両方と一致していることを確認するために不可欠です。また、パフォーマンスに影響する可能性のあるシステムへの変更は、関連する SLO の見直しのきっかけとなるはずです。もし、サポートが必要な場合は、AWS サポートや AWS アカウントチームにお問い合わせください。 著者について Andreas Bloomquist Andreas Bloomquist は Amazon CloudWatch の Sr. Product Managerです。彼はアプリケーションのオブザーバビリティに重点を置き、お客様がアプリケーションの状態を監視および評価し、問題が発生したときにその根本原因に迅速にたどり着けるよう支援しています。 Michael Hausenblas Michael は AWS オープンソースオブザーバビリティサービスチームで Technical Product Manager を務め、 AWS Distro for OpenTelemetry (ADOT) を担当しています。 Arun Chandapillai Arun Chandapillai は、ダイバーシティ＆インクルージョンの推進者である Senior Infrastructure Architect です。彼は、ビジネスファーストのクラウド運用戦略を通じてお客様が IT の近代化を加速し、クラウドでアプリケーションとインフラストラクチャを上手に構築、デプロイ、管理できるよう支援することに情熱を注いでいます。アルンは自動車愛好家であり、熱心な講演者であり、慈善家であり、「you get (back) what you give（善因善果）」と信じています。LinkedIn: /arunchandapillai 本記事は、 Improve application reliability with effective SLOs を翻訳したものです。翻訳はテクニカルアカウントマネージャーの日平が担当しました。

はじめに みなさんこんにちは。ソリューションアーキテクトの眞壽田（ますた）です。2024年6月20日、21日に幕張メッセにて AWS Summit Japan イベントが開催されました。今年の AWS Summit は、Online 含め述べ 52,323 人という多くの方に参加頂きました。自動車業界のお客様を支援する私達 AWS for Automotive チームは、 AWS Industry エリアに、4つのデモンストレーションブースを構えて皆様に AWS for Automotive のソリューションを紹介致しました。デモブースで皆様とお話させて頂き、詳細な資料が欲しいというご要望を頂きましたので、本ブログでは、その４つのデモンストレーションをダウンロード頂いた資料よりも詳しく紹介していきます。 1. AWSクラウドによる自動車ソフトウエア開発の高速化 自動車業界では、CASE への対応でソフトウエアの開発量が増大しています。一方で車載のソフトウエア開発は組み込み開発であるが故に、ソフトウエア開発には評価ボードやハードウエアが必要となります。今後の自動車業界は、増え続けるソフトウエア開発を如何に効率化していくかという点が課題の１つとなっています。AWS では、自動車業界のお客様に、ハードウエアに依存せずに可能な限りAWS クラウド上でソフトウエア開発を行うお手伝いをしています。 デモ１の構成 こちらのデモンストレーションでは、EV 向けバッテリー制御を行うECU ソフトウエアの動作シミュレーションをAWS クラウド上で行っています。 Amazon EC2 インスタンス上で、The MathWorks, Inc.の MATLAB/Simulink で制御ソフトをモデリングし、シミュレーションを行います。 1で作成した Simulink モデルから AUTOSAR Classic スタック上で動作するコードを生成し、CI/CD パイプラインでビルドします。 Amazon EC2 インスタンス上で、Synopsys Silver シミュレーターを動作させ、Elektrobit Automotive GmbH のミドルウエアで、AUTOSAR Classic 準拠の仮装ECU に、ビルドしたバイナリをデプロイします。 Amazon EC2 インスタンス上で、Elektrobit Automotive GmbH のミドルウエア上で、AUTOSAR Adaptive の ECU ソフトウエアを動作させます。 Amazon EC2 インスタンス上で動作する Android OS ベースの UI アプリケーションと ECU ソフトウエアが SOME/IP で通信を行います。 UI アプリケーション上でスポーツモードの切り替えを行うと、Synopsis Silver 上の電力出力量のグラフが変化します。 AWS では、可能な限り車載ハードウエアに近い環境を AWS クラウド上に構築し、仮想的に ECU ソフトウエアを動作させることで、ハードウエア群を準備しなくて済むソフトウエア開発環境を構築し、全体での試作回数を減らすと共に、時間がかかる開発PCの調達や保守、開発ツールのインストール作業から開発者を解放し、開発者が ECU ソフトウエアの開発に専念できるよう支援します。もちろん、CI/CD パイプラインを構築することで、ビルドや静的解析、ユニットテスト、デプロイなどの作業を自動化することも可能です。 デモ２の構成 こちらのデモンストレーションでは、コックピットの ECU ソフトウエアの UI 開発を AWS クラウド上で行っています。 Rightwareの Kanzi One（UI開発用IDEツール）を AWS Gravition EC2 インスタンス上で動作させ、Nice DCV プロトコルでデモブースの Laptop PC のブラウザに表示します。 パナソニック オートモーティブシステムズ株式会社の vSkipGen を使用し、 AWS Gravition EC2 上で、メータークラスターの仮想ECUを AGL（ Automotive Grade Linux ）上で動作させる。また、同時にインフォテインメントの仮想ECUを Android OS 上で動作させます。 Kanzi One のターゲットECU として、それらの仮想ECUを指定し、Kanzi One での UI 変更をニアリアルタイムに仮想ECUに反映させることで、開発者は画面で確認しながら視認性ならびにデザイン性の高い動く UI を開発します。 コックピットの仮想ECUが動作する VPC とは別のVPC上で AUTOSAR Adaptive の仮想ECUも動作しており、 SOME/IP 通信によりコックピットの仮想ECUと通信し、車両データ（例えば車速やエンジン回転数）をコックピット仮想ECUと連携します。異なるVPC上にある仮想ECU同士を SOME/IP で通信させるためには、それぞれの仮想ECUが同一サブネット上に存在する必要があるという条件に基づき、 AWS Transit Gateway を用いて、同一ネットワーク環境を構成しています。将来、仮想ECUを連携させる時の構成の一例として提案させていただいております。 2. クラウドからエッジへ 自動運転開発サイクルを高速化するオープンソース環境 AWS は、SOAFEE , eSync Alliance , Autoware foundation といったオープンソースコミュニティとも連携し、業界全体の開発生産性向上を目指しています。本デモでは、自動運転ソフトウエアスタックの開発、シミュレーション、OTA アップデート実行時に、実機と同じネイティブコードで動くクラウド上のバーチャル車両に対してテスト・検証をしています。 今回のデモで想定しているシナリオは、自動運転 Level4 相当の自動運転車両が、路肩に停車している他の車両を認識して安全に回避するようなシナリオになります。まず、現行のバージョンのソフトウェアではうまく回避できずに、安全確保のために衝突する前に停止し続けてしまう状態から、パスプランニング修正済みのソフトウェアを AWS 上で検証し、そのソフトウエアで OTA で車両にデプロイする、という内容です。このように様々な状況を実車検証の前に AWS 上で検証できることで、多くのリアルなユースケースにおける挙動の確認ができるのではないか、と言う提案にもなっています。 デモの構成と流れ Level 4 相当の自動運転仮想車両にオープンソースソフトウェア（OSS）の自動運転ソフトウェアスタックである Autoware で実装されており、開発ツールに株式会社ティアフォーの Web.Auto を利用します。 AWS 上で、Web.Auto を使って Autoware のシナリオを修正し、新たなソースコードをビルドし、シミュレーションにより、アップデートされているかを検証します。 検証して品質が保証されたソフトウエアを、eSync Alliance の OTA のコンソーシアムが提供しているツールを使い、OTA のキャンペーンを作成し、実車の ECU に検証済みのソフトウエアをデプロイします。 AWS では、本デモのように、ソフトウエアの開発における計画、実装、シミュレーションテスト、リリース、デプロイ（OTA）という実車検証のサイクルを、可能な限り AWS クラウド上でサイクリックに実現し、車載ソフトウエア開発の効率化を支援します。クリックに実現し、車載ソフトウエア開発の効率化を支援 3. 生成AIなどを活用したAWS上での自動運転機能開発の加速 このデモでは ADAS/自動運転の開発におけるワークフローを AWS クラウド上で大規模に実現しており、特にシミュレーションや機械学習といったタスクのためのデータを準備するために利用可能なコンポーネントについて、具体的に動作するところを皆様にご覧いただきました。 デモについて 生成 AI のモデルを利用して、ラベルがない画像データに対して、自然言語で検索をして、関連する画像を抽出することができます。 下の図では、検索ボックスに、「 pedestrian crossing an intersection 」と入力し、「Search」ボタンを押下します。 すると検索結果に下の図の様に、 交差点を通行する歩行者 の画像が表示されます。 従来は、事前にラベル付されていないような画像やシーン・シナリオについては手軽に検索できませんでしたが、生成 AI を用いた手法を活用することで、ラベル付されていないデータから自然言語による検索を行って、求めるシーン・シナリオに関するデータを抽出することができます。 4. コネクテッドビークル AI解析による運転体験の最適化 このデモでは、車が路面状況を理解して、車側でその状況に応じて最適なドライビングアシスタント機能を使えるようにする機能開発を目的として、 AWS IoT FleetWise を利用し、車載カメラと CAN 情報をクラウドに収集、道路コンディションを推定するAIモデルを作成し、継続的に推論結果を活用して車載ソフトウェア改善を行うプロセスをお見せしました。 デモの流れ 車両側 AWS IoT FleetWise の新機能 Vision System Data を利用し、車載カメラから画像を収集し、その画像を元に車載側のAI 推論で検出した道路状況と CAN データから収集した道路状況が一致しない場合、車載側のAI推論のモデルを再度トレーニングするための教師データとして、車載カメラの画像データを AWS クラウドで収集します。 AWS 側では、受信データを教師データとして利用し、車載側のAI推論を再トレーニングします。 下の図は、収集したデータを Amazon QuickSight で可視化し、AI 推論の結果とカメラの画像を確認できます。これによりAI 推論を誤ってしまったカメラ画像を改めて学習することで、AI 推論の認識率を上げていくことにAWSが貢献しています。 このデモで中心となるAWSサービスが AWS IoT FleetWise になります。 AWS IoT FleetWise は新しい機能として、 Vision System Data (カメラ、レーダー、LiDAR など)を収集する仕組みを2023年の re:Invent で発表しました。これにより、CAN に流れているシグナルのデータだけではなく、カメラなどで取得した画像などのデータを収集し、活用することができるようになりました。 おわりに 今回の AWS Summit Japan では、私たち AWS for Automotive のチームが、今の自動車業界のトレンドを軸にデモンストレーションを選定しました。今まで自動車業界のお客様には、 Connected Vehicle や自動運転のための物体検知の AI 推論などで AWS を活用頂いてきましたが、自動車業界が100年に一度の変革期を迎える中、昨年から車載のソフトウエア開発環境のクラウド化を支援させて頂くことが増えてきました。その背景から、今回の Automotiveブース では、車載ソフトウエア開発のデモンストレーションの割合を増やし、ハードウエアに依存しない車載ソフトウエア開発のソリューションを多くのお客様に紹介させて頂きました。このブログをご覧になってもう少し内容を詳しく聞きたいというお客様がいらっしゃいましたら、AWSアカウントチームまでご連絡頂ければと思います。 著者 眞壽田 英輝 (Masuta, Hideki) アマゾン ウェブ サービス ジャパン 合同会社 Mobility領域のお客様を支援するソリューションアーキテクト。好きなAWSサービスはAmazon Managed Streaming for Apache Kafka (MSK)です。

6月10日週、私が以前勤務していた Standard Bank Group (SBG) がソフトウェアエンジニアリングカンファレンスを主催し、基調講演者の 1 人として私を招待してくださいました。SBG はアフリカ全土に拠点を置いており、このハイブリッドカンファレンスにはアフリカ大陸全体からほぼ 2,000 人のエンジニアが参加しました。長年の友人やかつての同僚と再会し、新しい友達ができたこのカンファレンスは、実にすばらしい経験でした。 6月10日週のリリース 6月10日週のリリースの中から、私の目に留まったリリースをいくつかご紹介します。 ルートユーザーと IAM ユーザーのためのパスキー多要素認証 (MFA) – 利便性を提供し、容易な復旧を実現するため、ルートユーザーと AWS Identity and Access Management (IAM) ユーザー向けのサポート対象 多要素認証 (MFA) のリストにパスキーを追加しました。パスキーは、サービスまたはウェブサイトへの登録時にクライアントデバイス上で生成される暗号化キーのペアです。パスキーはパスワードの代わりに使用できますが、今回の初回リリースでは、パスワードに追加される 2 番目の認証要素としてパスキーを使用することにしました。 Amazon GuardDuty Malware Protection for Amazon S3 – 今週開催された AWS re:Inforce 2024 で、Amazon GuardDuty Malware Protection for Amazon Simple Storage Service (Amazon S3) の一般提供開始が発表されました。これは、GuardDuty Malware Protection の拡張機能であり、選択した S3 バケットへの悪意のあるファイルのアップロードを検出するためのものです。これには、コンピューティングインフラストラクチャを管理することなくマルウェア検出を完全に管理する能力や、組織内にあるすべての保護対象バケットのカバレッジ概要など、さまざまなメリットがあります。詳細については、 Amazon GuardDuty Malware Protection for Amazon S3 を詳しく説明する先週掲載の記事 をお読みください。 IAM Access Analyzer アップデート – 先週の AWS re:Inforce 2024 からもうひとつのすばらしいお知らせです! IAM Access Analyzer アップデートが発表されました。これは、カスタムポリシーチェックの拡張を可能にするとともに、ガイド付き失効機能も含まれています。この機能は、開発者と共有できるガイダンスを提供して、開発者が不要な許可を失効できるようにします。 私の同僚の Jeff Barr が、こちらの記事でこの機能をさらに詳しく説明しています 。 AWS のその他のニュース AWS のオープンソースに関するニュースと最新情報 – 私の同僚である Ricardo が こちらの Open Source Newsletter を毎週執筆して、AWS コミュニティからの新しいオープンソースプロジェクト、ツール、およびデモを紹介しています。 .NET 開発者コミュニティは、AWS にとって大切なコミュニティであり続けています。私の同僚である Brandon Minnick と Francois Bouteruche は、私のインスピレーションでもあります。このコミュニティをサポートする彼らは、楽しい .NET 開発者エクスペリエンスを生み出すために AWS と Azure のエンジニアリングチームが連携するという結果をもたらしました 。世界各国で開催されている NDC Conferences の一環として最近行われた NDC Oslo では、VP of Azure Developer Experience である Scott Hunter 氏が、その基調講演でこのコラボレーションについて話しました。 NDC Conferences YouTube チャンネル で公開され次第、この基調講演をぜひご覧ください。 今後の AWS イベント AWS Summit – クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントです。お住まいの地域が南北アメリカ、アジア太平洋、日本、EMEA であるかにかかわらず、地域内で開催される 今後の AWS Summit イベントに関する情報については、こちらをご覧ください 。 AWS Community Day – この記事の冒頭で紹介したものと同様の AWS Community Day イベント で、地域のエキスパート AWS ユーザーや業界リーダーが主導するテクニカルディスカッション、ワークショップ、ハンズオンラボに参加しましょう。 スリランカにお住まいの場合は、来週この地域で開催されるイベント があります。 こちらで、 近日中に開催されるすべての対面およびバーチャルイベントを閲覧 することができます。 6月17日週のニュースは以上です。6月24日週の Weekly Roundup もお楽しみに! – Veliswa この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします。 原文は こちら です。

この記事は、software as a service (SaaS) のためのリレーショナルデータベースのスケーリングに関するシリーズの続編です。SaaS プロバイダーは、 Amazon Relational Database Service (Amazon RDS) や Amazon Aurora などのリレーショナルデータベースを一般的にソリューションで利用しています。 Part 1 では、リレーショナルデータベースアーキテクチャをスケーリングまたは最適化する一般的な方法をいくつか紹介しました。これらの方法は、 垂直スケーリング や リードレプリカによる水平スケーリング など、制限のある物理リソースのセットをスケーリングすることに焦点を当てていました。SaaS プロバイダーとしては、これらの限界を超えて成長する必要がある場合があり、そのような場合に データベースシャーディング がスケーリングメカニズムとして有効な選択肢となります。 データベースのシャーディングは複雑さを増し、一度実装すると後戻りできなくなることが多くあります。これは、シャーディングがデータモデルに明示的に組み込まれ、アプリケーションもそれに合わせて変更する必要があるためです。したがって、SaaS 運用に影響を与えるような判断をする前に、データベースをシャーディングすることの意味を理解しておく必要があります。さらに、データベースアーキテクチャが複雑になるにつれ、テナントのリクエストを正しいデータベースにルーティングする課題に直面する可能性があります。 この記事では、データベースのシャーディングと、アプリケーションがテナントのリクエストを正しいデータベースにルーティングする課題への対処方法について説明します。 更なるスケーリング 垂直スケーリングは読み取りと書き込みのパフォーマンスを向上させますが、データベースインスタンスを拡張または最適化できるサイズには上限があります。同様に、リードレプリカを使った水平スケーリングでは読み取り負荷に対してスケールアウトできますが、データベースソリューションでサポートされるリードレプリカの数に制限があります。これらの制限に近づいたり到達したりした場合、アプリケーションを拡大し続けるにはどうすればよいでしょうか。 プールやブリッジモデル では、一部のテナントがリソースを他のテナントよりも多く消費している場合、サイロストレージにテナントを移行するという選択肢があります。選択されるテナントは通常、パフォーマンス要件が最も高いテナントです。その後、既存のテナントを新しい環境に移行するメカニズムを導入する必要があります。 AWS Database Migration Service (AWS DMS) などのツールを使用すると、 この移行を自動化 できます。また、テナントとストレージを対応付ける必要があり、ソリューションとオペレーションにさらなる複雑さが加わります。 別の選択肢は、データベースのシャーディングを利用することです。これにより、パーティショニングモデルを維持しながら、顧客層の拡大に伴ってデータセットをスケールアップできます。 SaaS ソリューションにおけるデータベースのシャーディング データベースのシャーディングについては、 データベースのシャーディングとは? と Amazon Relational Database Service でのシャーディング で詳しく説明されています。この概念に詳しくない場合は、これらの参考資料を確認することをお勧めします。この記事では、SaaS 固有の側面に焦点を当てています。 データベースのシャーディングアーキテクチャを設計する際、シャードキーの選択は重要です。SaaS プロバイダーは、テナントのデータを単一のデータシャードに紐付けできるため、 tenant_id をシャードキーとして使用することが多くあります。次の図は、リレーショナルデータベースの Order テーブルを tenant_id をシャードキーとしてシャーディングする例です。 テナントのすべてのトランザクションを単一のデータシャードに紐付けると、テナントごとのパフォーマンスを改善できます。例えば、テナントのデータベースクエリでは、すべてのデータベースのすべての行を検索する必要がある場合があります。テナントを単一のデータベースに限定すると、検索される行数が減り、パフォーマンスが向上します。また、テナントに対して外部キーと JOIN を使用できるようになります。次の図は、 tenant_id をシャードキーとして使用し、複数のデータベーステーブルにわたってシャーディングされている様子を示しています。 データシャードは固有のデータベースであるため、単一のデータベース インスタンスまたはクラスターに複数のシャードを持つことができます。シャードのサイズとインスタンスあたりのシャード数は、使用事例によって異なります。たとえば、多数のシャードを管理する運用オーバーヘッドを減らすために、インスタンスごとに 1 つの大きなシャードを選択することができます。あるいは、データベースのサイズが原因で、レプリケーションやバックアップの遅延、 vacuuming などのデータベースのメンテナンスタスクの実行に問題が発生している場合は、インスタンスあたり複数の小さなシャードを選択することができます。 シャーディングのメリット シャーディングを使用すると、単一のデータベースのパフォーマンスを超えてアプリケーションをスケールアウトできます。既存のシャードのサイズ変更や、パフォーマンス問題への対応、または新規テナントのプロビジョニングに応じて、リアルタイムで新しいシャードを追加できるように、SaaS アプリケーションをアーキテクチャ設計できます。単一のテナントが単一のデータベースで提供できるパフォーマンスを超える必要がある場合、シャーディングは 1 つの解決策となります。 大規模なテナントを扱う場合、シャーディングを使ったプールモデルの方が、サイロモデルよりも運用効率が高くなります。データベースの管理数が少なくなり、新しいテナントを追加する際に新しいデータベースをプロビジョニングする必要がないため、テナントのオンボーディングが簡素化されます。 tenant_id をシャードキーとして使用することで、他の運用上の効率化も得られます。テナント分離アプローチと相性が良く、パフォーマンス問題に対処するためにテナントを新しいノードに簡単に再配置できます。これは、すべてのデータを単一のデータシャードに格納するためです。同様に、 テナント単位のバックアップと復元 では、複数のデータシャードにまたがる整合性を確保する必要がありません。 テナント ID をシャードキーとして使用する場合、シャーディングと他のデータベーススケーリングアプローチを組み合わせると、テナントのパフォーマンスがさらに向上しますが、複雑さが増します。たとえば、 テーブルパーティショニング を tenant_id に基づいて実装し、個々のテナントのパフォーマンスを対象にしたり、 データベースキャッシング を導入してシャードのパフォーマンスを改善したりできます。 シャーディングは、 cellular architecture パターンも提供します。これにより、インフラストラクチャの障害からの影響範囲が限定され、単一のテナントが他のパフォーマンスに与える影響が軽減されます。次の図は、各データベースインスタンスに最大 2 つのテナントを含む 3 つのシャードが含まれる (各シャードが個別のデータベース) アーキテクチャを示しています。この図には高可用性は示されていませんが、Aurora または Amazon RDS ではネイティブに実装されています。これらのオプションの詳細については、 高可用性と耐久性 および Amazon RDS Multi-AZ を参照してください。 シャッフルシャーディング を利用すれば、1 つの問題のあるテナントが他に与える影響をさらに軽減できます。ただし、シャードレプリケーションを管理するソリューションを導入する必要があるため、複雑さが増します。 シャーディングの課題 シャーディングは SaaS アプリケーションを非常に複雑にします。アプリケーションはすべてのシャードにわたるデータのマッピングとルーティングを処理する必要があります。ヘルパーサービスを導入することで、この複雑さを開発者から隠すことができます。この概念については、後ほど投稿内で説明します。 複数のシャードからデータを必要とするクエリでは、アプリケーションレベルでの追加エンジニアリングが必要になります。これは通常、単一のシャードを使用するクエリよりも高いレイテンシーを引き起こします。オンライン分析処理 (OLAP) のようなワークロードは、通常、全データセットに対してデータ分析を行うため、シャーディングには適していません。このような場合、両方の機能を持つために、データセットのコピーを OLAP データベースに作成することが一般的な方法です。 シャーディングを導入すると、いくつかの運用上の課題が生じます。データセットの領域が複雑になるため、サポートが難しくなる可能性があります。シャーディングされたデータセットは分散しているため監視が難しくなり、テナントを認識したコンテキスト、ログ記録、メータリングが必要になります。テナントの移行は簡単ではなく、データ保持に関する検討が必要になる可能性があります。 シャーディングされたデータセットは、時間の経過とともに偏りが生じ、データベースのホットスポットを引き起こす可能性があります。シャード間でのパフォーマンスの違いは、顧客のパフォーマンスにばらつきを生む原因となります。データを均等に分散せるためには、長期にわたってデータセット全体でテナントを継続的に再調整する必要があります。そのため、コアアーキテクチャの一部としてテナントを移行する機能が必要です。 シャード化されたアーキテクチャにオブザーバビリティを持たせる事は不可欠です。 Amazon RDS Performance Insights 、 Enhanced Monitoring 、 Amazon DevOps Guru for RDS などのツールを使用すると、データベースのパフォーマンスを可視化し、ソリューションに影響を与える可能性のある問題を特定できます。 最後に、シャード化されたアーキテクチャからシャード化されていないアーキテクチャに戻すことは難しく、相当な技術的専門知識、エンジニアリングリソース、プログラム管理が必要になります。シャード化の決定は一方通行だと考えるべきです。 これらの課題の多くは、 Amazon Aurora Limitless Database (現在 Limited Preview 中) によって解決されます。Aurora Limitless Database は、単一インスタンスの制限を超えてスケーリングできる Aurora のサーバーレスデプロイです。アプリケーションレベルのシャーディングを自分で実装する必要はありません。Aurora Limitless Database は単一のインターフェースを提示するため、アプリケーションはシングルデータベースを使用する場合とほぼ同じ方法で使用できます。Aurora Limitless Database では、アプリケーションがテナントのルーティングを処理したり、クラスターのトポロジを認識する必要はありません。Aurora Limitless Database はスキーマとキーレンジの配置を認識しており、クエリを正しいデータアクセスシャードにルーティングし、アプリケーションに返す前に結果を集約します。 シャーディングのタイミングとシャーディングへのアプローチ シャーディングの主な利点は、単一の物理データベースを超えてスケーリングできることです。現代のデータベースはリソースが増え続けているため、一般的にはその他のスケーリングアプローチが機能しなくなった場合にのみシャーディングを検討します。1 つのユースケースとして、データベースの物理的な限界に達したサイロモデルのテナントで、他の方法でスケーリングできない場合が考えられます。あるいは、データベースエンジンのパフォーマンスが限界に達しても、既存のパーティショニングモデルを維持したい場合もあるでしょう。SaaS アプリケーションのリレーショナルデータベースのパフォーマンスを改善する他の方法については、このシリーズの Part 1 をお読みください。 別のシャーディングのユースケースは、大規模環境での運用効率化です。多くのテナントが存在する場合、サイロモデルでこれらのテナントを管理することは、プールモデルほどのコスト効率性は得られませんが、シャーディングされたプールモデルと同じくらい運用が複雑になる可能性があります。たとえば、16 の データベースシャードにまたがる 400 のテナントを管理する方が、400 の個別のデータベースを管理するよりも簡単かもしれません。 レジリエンシーのためにシャーディングを検討することもできます。データベースアーキテクチャは多くのテナントをサポートできる可能性があります。しかし、データベース障害の影響が事業リスクとして大きすぎる場合があります。シャードの物理的な分離により、データベース障害の影響範囲が小さくなります。また、レプリケーションにより、障害発生時にセカンダリシャードからデータを利用できるようになります。 データセットをシャーディングすることを決めた場合は、どのようにシャーディングするか、何をシャーディングするかを評価する必要があります。データセットを複数のセットに分割し、シャーディングが必要な部分のみをシャーディングすることができるかもしれません。SaaS アプリケーションの機能とテナントの使用パターンを評価し、データセットのどの部分をシャーディングするのが適切かを判断してください。その上で、データセットの一部を分割し、シャーディングしてください。 複雑なデータセットにおけるデータベースリクエストのルーティング 独自のシャーディングソリューションを実装する場合、アプリケーションはデータベースへのリクエストをどこにルーティングするかを知る必要があります。データセットを複数のデータベースシャードやパーティショニングモデル (プレミアム層のサイロモデルと標準層のプールモデルなど) に分散させると、これが難しくなります。 アプリケーションには、テナントデータがどこにあるかを追跡するために、各テナントをデータベースインスタンスにマッピングするインデックスが必要です。新しいテナントをオンボーディングしたり、既存のテナントをシャードやパーティションモデル間で移行する際には、このインデックスを更新する必要があります。また、新しいテナントをどのシャードに配置するかを決定するメカニズムが必要になる可能性があります。 このインデックスの管理とクエリを行うヘルパーサービスとして、データアクセスマネージャーを実装できます。これにより、開発者からデータセットの複雑さを隠蔽し、アプリケーションを変更することなく将来的にデータセットのアーキテクチャを変更できます。リレーショナルデータベースの管理に限定されず、アプリケーション用のすべてのデータセットをインデックス化およびマッピングできます。 次の図は、データアクセスマネージャーのアーキテクチャ例を示しています。 この例では: JSON Web トークン ( JWT ) が SaaS アプリケーションを通して渡され、 テナントコンテキスト が含まれています。 JWT をデータアクセスマネージャーに渡し、JWT マネージャーを呼び出します。 JWT マネージャーは JWT を検査し、 tenant_id フィールドを返します。 データアクセスマネージャーは、 Amazon DynamoDB テーブルに格納されたマッピングを使用して、 tenant_id を正しいデータベースインスタンスにマッピングします。 データベースの詳細がアプリケーションに返却されます。 アプリケーションは、正しいデータベースインスタンスに接続します。 マッピングテーブルには DynamoDB を使用しています。これは、マッピングデータを格納するための経済的でスケーラブルなソリューションを提供するためです。このマッピングデータはアプリケーション内のすべてのサービスやマイクロサービスで使用される可能性があるため、パフォーマンスのボトルネックにならないことが重要です。DynamoDB は、クエリごとに単一のアイテムのみが返されるこのようなキーバリュー型のアクセスパターンに適しています。複数のサービスが、バックエンドにある異なるデータベースを使用しながらこのシャーディングモデルを利用する場合は、 service_id 属性を追加し、 複合プライマリキー を作成することで、この例のアーキテクチャを拡張できます。さらに、このデータはかなり静的であると予想されるため、 キャッシング層 を導入して DynamoDB への呼び出し回数を減らすこともできます。 Aurora Limitless Database を使用すると、このようなルーティングの複雑さは解消されます。Aurora Limitless Database には、選択したシャードキー (例: tenant_id ) に基づいて、クエリを正しいデータアクセスシャードにルーティングするルーターインスタンス群が含まれています。そのため、アプリケーションは、クエリの一部として tenant_id を指定し、単一のシャードグループエンドポイントにアクセスするだけで済みます。Aurora Limitless Database の詳細については、 Join the preview of Amazon Aurora Limitless Database をご覧ください。次の図は、Aurora Limitless Database のアーキテクチャを示しています。 結論 この投稿では、SaaS アプリケーション内のリレーショナルデータベースをスケーリングする選択肢としてのシャーディングと、データルーティングを処理するためのデータアクセスマネージャーの概念について説明しました。 リレーショナルデータベースをシャーディングすると、SaaS アプリケーションにアーキテクチャ上および運用上の複雑さが生じます。シャーディングされたアーキテクチャを実装することのトレードオフを検討し、それが自分のユースケースに最適なものであることを確認する必要があります。シャーディングが提供するパフォーマンス上の利点は、別のスケーリング戦略でも得られる可能性があります。 複数のスケーリング戦略を組み合わせ、シャーディングを選択することもできます。SaaS 導入における正しい判断は、チームの既存の知識を活かしてソリューションを運用し続けることかもしれません。既存のテクノロジースタックを維持することで、将来的によりスケーラブルなテクノロジーに移行する前に、他の成長分野に注力できます。 シャーディングを実装することにした場合は、アプリケーションのルーティングの複雑さを軽減し、スケーリングとメンテナンス作業を簡素化するために、Aurora Limitless Database などのマネージドなシャーディングソリューションを検討する必要があります。 スケーリング戦略を本番環境に導入する前に、十分にテストすることが重要です。スケーリングアプローチを設計する際は、スケーリングメカニズムのパフォーマンスを可視化し、期待したスケーリング目標に達しているかを検証するための運用メトリクスを実装する必要があります。 AWS SaaS ファクトリーについて AWS SaaS Factory は、SaaS ジャーニーのあらゆる段階にある組織を支援します。新製品の構築、既存アプリケーションの移行、または AWS 上での SaaS ソリューションの最適化を検討している場合でも、お手伝いできます。 AWS SaaS Factory Insights Hub にアクセスして、さらに多くの技術的およびビジネス的なコンテンツとベストプラクティスを見つけてください。 SaaS ビルダーは、アカウント担当者に連絡して、エンゲージメントモデルについて問い合わせ、AWS SaaS Factory チームと協力することを推奨します。 著者について aaaaaaaaa Dave Roberts は、シニアソリューションアーキテクトであり、AWS SaaS Factory チームのメンバーです。AWS 上で SaaS 製品を構築する AWS パートナーを支援しています。SaaS について話していないときは、ギターエフェクトペダルを作ったり、家族と森で時間を過ごすことを楽しんでいます。 Josh Hart は、Amazon Web Services のプリンシパルソリューションアーキテクトです。彼は英国の ISV 顧客と協力し、AWS 上で SaaS アプリケーションを構築およびモダナイズするのを支援しています。 翻訳はソリューションアーキテクトの「藤川 貞信」が担当しました。 原文 はこちらです。

ビジネスが成長するにつれて、SaaS (Software as a Service) プロバイダーが直面する課題の 1 つは、 テナント のエクスペリエンスをどのように維持するかです。これには、テナントベースが拡大するにつれて、許容できるパフォーマンスとレスポンスタイムを確保することが含まれます。 Amazon Relational Database Service (Amazon RDS) や Amazon Aurora などのリレーショナルデータベースは、一般的に SaaS プロバイダーによって使用されています。ビジネスが成長するにつれて、データベースのスケーリング方法も決定する必要があります。 SaaS ビルダーとしての課題は、 SaaS ジャーニー の段階に応じて、どのスケーリングメカニズムが適切かを決定することです。アプリケーションが成長するにつれて、既存のソリューションがニーズを満たさなくなった場合、データベースアーキテクチャを変更する必要が生じる可能性があります。新しいテクノロジーやアーキテクチャパターンを実装すると、成長の推進やコア事業への投資から注力が逸れてしまうことがあります。新しいテクノロジーやアーキテクチャに移行するよりも、チームの知識を維持するために既存のアーキテクチャを最適化する方が有益な場合もあります。 このシリーズでは、既存のリレーショナルデータベースを持つ SaaS プロバイダーに対し、効果的にスケーリングする方法のガイダンスを提供します。Part 1 では、SaaS の観点から一般的なリレーショナルデータベースのスケーリングパターンの利点を探り、SaaS ソリューションに適したスケーリングアプローチを選択し、さらなる検討の出発点とするための情報を提供します。 Part 2 では、シャーディングとテナントルーティングについて説明します。 データベーススケーリングと SaaS パーティショニングモデル データベースのスケーリングの説明に入る前に、SaaS の データ分割 モデルを理解することが重要です。利用できる 3 つの高レベルな SaaS 分割モデル は、 サイロ 、 ブリッジ 、 プール です。 サイロモデル – 各テナントが物理リソース (テナントごとのデータベースインスタンスなど) を個別に持っています ブリッジモデル – テナントは物理リソースを共有しますが、論理的に分離されています (テナントごとのテーブルやスキーマなど) プールモデル – テナントは物理リソースと論理リソースを共有します。たとえば、シングルな共有テーブルです SaaS ソリューションは多くのテナントとそのユーザーのデータをサポートし、ビジネスが成長するにつれてデータも拡張する必要があります。シングルデータベースは最終的にパフォーマンスのボトルネックになる可能性があるため、どのようなスケーリングオプションがあるかを理解しておく必要があります。 リレーショナルデータベースのスケーリングは、大まかに次の 3 つのカテゴリに分類できます。 物理リソース – まず、リードレプリカやシャーディング (このシリーズの Part 2 で解説) によってスケールアウトすることで、データセットの物理リソースを増やすことができます。 データベース操作 – 次に、より適切なインデックス作成やデータモデルの変更などの手法で、データベース操作を最適化できます。 データベースアーキテクチャ – 最後に、データセット全体または一部のデータベースアーキテクチャを変更することができます。これには、 purpose-built データベース の利用、 キャッシングメカニズム の追加、または非同期プロセスの作成や Command Query Responsibility Separation (CQRS) パターン の実装などの大規模なアーキテクチャ変更が含まれます。このアプローチについては、「 Modernize legacy databases using event sourcing and CQRS with AWS DMS 」でより詳しく説明されています。 スケーリングメカニズムを組み合わせることで、最良の結果が得られることが多く、特定のパーティション分割モデルや使用パターンに適したスケーリングパターンがあります。このシリーズを通して、これらの違いを検討していきます。 物理リソースの追加による既存アーキテクチャのスケーリング SaaS プロバイダーがリレーショナルデータベースをスケーリングする際の最初のアプローチは、通常、物理リソースを増やすことです。物理リソースをどこまで拡張できるかには上限がありますが、それまでは、インフラストラクチャのコストが高くなる一方で、コアビジネス目標からリソースを奪うようなアーキテクチャの変更を行わずに、データベースを拡張する効果的な方法です。 垂直スケーリング SaaS プロバイダーは、最初のスケーリングアプローチとして一般的に 垂直スケーリング を選択します。より多くの物理リソース (CPU、メモリ、ネットワーク) を提供することで、より多くの同時接続をサポートできるようになります。既存のパーティション分割モデルを維持したまま、接続設定を変更せずにデータベースをインプレースでスケーリングできます。Amazon RDS では、新しいインスタンスタイプを選択することで、利用可能なあらゆるインスタンスサイズにリソースを垂直にスケーリングできます。これによりインスタンスが再起動され、わずかなダウンタイムが発生しますが、 Amazon Aurora Serverless v2 では、サービス中断なしで スケールアップとスケールダウン ができるため、可変のデータベースワークロードを持つ SaaS プロバイダーに適しています。 サイロモデルでは、SaaS 以外のアプリケーションのスケーリングと比べて、SaaS 固有の違いはありません。ただし、ブリッジモデルとプールモデルでは、スケーリングの要因を評価し、潜在的なリスクを検討する必要があります。より多くのテナントを追加するためにスケーリングすると、 ノイジーネイバー やインフラストラクチャの障害など、パフォーマンスに影響を与えるイベントの影響範囲が広がります。同様に、シングルテナントが他のテナントの可用性に影響を与えるためにスケーリングが必要な場合は、テナントのパフォーマンスをスロットリングするか、そのようなテナントをサイロデータベースに移行することで、サービスと運用体験が向上するかどうかを検討してください。 リードレプリカによる水平スケーリング 読み取りの負荷問題を解決する必要がある場合、 リードレプリカ を使用することで、データ分割モデルを変更することなく、パフォーマンスを向上させることができます。これには他の利点もあります。例えば、RDS リードレプリカを スタンドアロンインスタンスに昇格 したり、 Aurora ストレージボリュームを新しいクラスターにクローン したりすることで、可用性を高めたり、データベースのシャーディングを容易にしたりできます。Aurora クラスターには、ボタンをクリックするだけで 最大 15 のリードレプリカ を設定できます。さらに、Aurora リードレプリカはストレージ層のレプリケーションを使用するため、従来のレプリケーションアプローチと比べて、プライマリへのパフォーマンス影響が少なくなります。 目的に応じて複数のリードレプリカを作成することができます。プライマリインスタンスを使用するサービスに影響を与えることなく、読み取り操作に基づく追加のサービス機能を SaaS 製品に導入できます。これらのアクティビティを様々なインスタンスタイプで実行することで、運用コストを削減できる可能性があります。 リードレプリカの追加や削除は、ダウンタイムを必要としません。Aurora で Aurora レプリカでの Auto Scaling を有効にすれば、リードレプリカのスケーリングを自動的に管理できるため、運用の複雑さを軽減できます。 既存アーキテクチャの最適化 データベースのパフォーマンスを拡張する別の方法は、パーティショニングモデルを変更せずに、既存アーキテクチャを最適化してデータベース効率を改善することです。これにより、スケーリングの必要性を遅らせたり、パフォーマンスの向上によりテナントのサービス体験を改善できます。各最適化アプローチは特定のユースケースに対応しているため、製品にどのアプローチが適用できるかを理解することが重要です。 マイクロバッチ処理 データベースリクエストには、それぞれパフォーマンスのオーバーヘッドが伴います。多くのユーザーが頻繁にリクエストを行う SaaS アプリケーションの場合、同時に多数のリクエストを処理するオーバーヘッドの累積によって、データベースのパフォーマンスが低下する可能性があります。類似のリクエストを マイクロバッチ と呼ばれるパターンでまとめることで、このインパクトを軽減できます。 この手法は、多くのユーザーが頻繁に小さなリクエストを行う場合、すべてのパーティション分割モデルで効果的です。特にプールモデルでは、データベースインスタンスあたりのテナントをさらに多く収容できるため、運用効率がさらに向上します。 運用の複雑さが高まるマイクロバッチ処理を扱うソリューションを作成する必要がある場合があります。次の例では、アプリケーションがデータベースに直接書き込むのではなく、 Amazon Simple Queue Service (Amazon SQS) キューに書き込みます。その後、 AWS Lambda 関数がこの SQS キューをポーリングし、メッセージバッチを消費して、結果整合性というコストを払って、データベースに原子的に書き込みます。 データベーステーブルのパーティショニング ほとんどのリレーショナルデータベースでは、論理的に大きなデータベーステーブルを小さな物理的なパーティションに分割するテーブルパーティショニングがサポートされています。パーティション内のデータにアクセスする際、探しているデータを見つけるために親テーブル全体を検索する必要はありません。これは、SaaS アプリケーションが大規模なマルチテナントデータセットを使用するプールモデルにおいて有益です。 テーブルパーティショニング は、日付やテナント ID などのパーティションキーを使ってテーブルを分割します。データベースエンジンによって、パーティションキーに対するレンジ、指定されたキーのリスト、ハッシュ値を使ってテーブルパーティショニングを行えます。ルートテーブルはそのままアクセス可能で、テーブルパーティショニングを活用するためにクエリを再設計する必要はありません。 tenant_id をプールモデルのパーティションキーとして使用することで、アプリケーションコードを再設計することなく、テナント固有のクエリのパフォーマンスを向上させることができます。実装例を次の図に示します。 テーブルのパーティショニングを tenant_id でシングルな物理リソースを超えてスケールさせるには、 データベースシャーディング の概念を拡張する必要があります。このシリーズの Part 2 でこの点を詳しく説明します。 データベーステーブルのパーティショニングでは、シングルパーティションがパフォーマンスのボトルネックになり、再調整が必要になるホットスポットが発生する可能性があります。また、パーティションを管理するための運用オーバーヘッドも発生します。 Amazon RDS for PostgreSQL または Amazon Aurora PostgreSQL-Compatible Edition を使用している場合は、PostgreSQL の pg_partman 拡張機能を使用して テーブルパーティションの作成と管理を自動化 できます。選択したデータベースエンジンのパーティション制限と、メンテナンス操作を実行する際のロック動作を考慮する必要があります。なぜなら、多くのテナントが同じデータベースを共有している場合に適さない可能性があるからです。環境に変更を加える場合と同様に、期待した結果が得られていることを監視し、変化に応じて適宜調整してください。 データの集約 SaaS プロバイダーは、多くの場合、テナントに分析的な洞察を提供するために、データセット上でユーザーごとまたはテナントごとの集計を行います。メトリクスやメータリングのため、またはデータセットのマルチテナントパフォーマンスを向上させるために、テナントごとまたはテナント間の集計を行うことができます。これにより、データベースが OLTP (オンライン トランザクション処理) と OLAP (オンライン分析処理) の両方のクエリに対応する必要が生じる可能性があります。 データセット全体で集計を行う読み取りクエリを実行すると、コストがかかり、テナントに影響を与える可能性があります。このアクティビティが予測できない場合、テナントのパフォーマンスを一定レベルに維持することが難しくなり、サービス体験が低下する可能性があります。この影響は、ブリッジモデルとプールモデルの方が大きく、複数のテナントが同じ物理データベースリソースを共有し、集計アクティビティの競合が発生する可能性があります。 サービス提供に、これらの集計アクティビティからのリアルタイムデータが不要な場合は、結果を事前に計算しておくことができます。たとえば、テナントデータの生成と分析を、オンデマンドで計算するのではなく 3 時間ごとに行うことができます。これにより、データベースのパフォーマンスが均一になり、結果が即座に利用できるようになるため、テナントのサービス体験が向上します。 RDS for PostgreSQL または Aurora PostgreSQL データベース上で pg_cron を使用 して、このアクティビティを自動化することもできます。これらの結果を配信するためにリードレプリカを使用すれば、さらにパフォーマンスが向上します。 さらに、 Amazon Redshift などのデータウェアハウスに分析クエリをオフロードすることができます。 Aurora と Amazon Redshift 間のZero-ETL integration により、トランザクションデータベースと分析データベース間でデータをニアリアルタイムに自動的に同期できるため、複雑なデータパイプラインを開発する必要がありません。 ユースケースを評価して、計算前のプロセスを維持することによるオーバーヘッドに見合う価値があるかどうかを検証する必要があります。データアクセスパターンがそのような集計を実行することがほとんどない場合、作業に見合う恩恵は得られない可能性が高いです。 データベース接続のスケーリング データベースには、利用可能な同時接続数に制限があり、テナントの数に応じて接続数が増加するため、ブリッジまたはプールのデプロイメントモデルを使用すると、この制限に達する可能性があります。これにより、タイムアウトやパフォーマンスの不安定化が発生する可能性があります。 Amazon RDS Proxy などのデータベースプロキシを実装すると、データベース接続をプールして共有できるため、データベースをさらにスケーリングできます。RDS Proxy のパフォーマンス特性の詳細については、 Build and load test a multi-tenant SaaS database proxy solution with Amazon RDS Proxy を参照してください。または、 RDS Data API のようなデータベースへの接続レスインターフェイスを検討してください。 Purpose-built データベース の導入 成長に合わせてデータベースのパフォーマンスを維持するには、特定のユースケースに最適化するためにデータベース アーキテクチャを変更する必要がある場合があります。この課題に対処する 1 つの方法は、同じデータベース内に個別の論理スキーマを使用し、それぞれを別のユースケースに最適化することです。 SaaS アプリケーションの機能が発展するにつれて、1 つのデータセットを複数に分割することが有益な場合があります。個々のアクセスパターンを分離し、purpose-built データベース に移行できます。複数の異なるアクセスパターンを最適化しようとして、最小公倍数に落ち着くのではなく、代わりにアクセスパターンをデータベース技術に合わせ、そのアクセスパターン専用に最適化することで、 適切な作業に適したツールを選択 するのです。 例えば、高スループットのトランザクションデータ用に対してや、テナント管理用のキーバリューストアとして Amazon DynamoDB のような NoSQL データベースを使用します。集計アクティビティで使用されるデータを分離するために Amazon Redshift のようなデータウェアハウスを使用し、より高いパフォーマンスレベルが必要なテナントに新しいサービス層を導入できます。既存のリレーショナルデータベースでは実装が難しい、 Amazon Neptune を使った 不正検知 などの新機能を導入し、既存の SaaS 製品に新しい市場を獲得することもできます。 Purpose-built データベースを導入すると、テナント分離の実装方法が変わり、パーティション分割モデルを再評価する必要が生じる可能性があります。パーティション分割モデルを維持できる場合でも、テナント分離の実装方法は異なる可能性があります。新しいデータベース技術を評価する際は、この点を考慮する必要があります。 詳細については、 AWS Well-Architected フレームワーク 、特にパフォーマンスの柱における データベースアーキテクチャの選択 、および データ分析レンズ の指針に従うことをお勧めします。 データベーススケーリングアプローチの検証 スケーリングアプローチがあなたの期待に沿っているかどうかを十分にテストおよび検証する必要があります。 メトリクス は、これらの判断のためのデータを提供する上で重要な役割を果たします。たとえば、 Amazon RDS Performance Insights を使用して、簡単で自動化された方法でデータベースのパフォーマンスメトリクスを監視したり、 Enhanced Monitoring を有効にして、Amazon RDS コンソールから RDS データベースインスタンスのすべてのシステムメトリクスを表示することができます。スケーリングが期待どおりに機能していないときや、新しいスケーリングメカニズムが必要なときを特定するために、運用管理タスクにパフォーマンスメトリクスを実装することを目指してください。 結論 SaaS アプリケーションの成長に伴い、データベースアーキテクチャも進化していきます。SaaS ジャーニーの中で、既存のアーキテクチャを拡張するか、要件の増大に合わせてアーキテクチャを変更するかを決める必要があります。判断の根拠にはメトリクスを用い、スケーリングアプローチが効果的であることを検証し、さらなるスケーリング手法が必要になったタイミングを把握できるようにしてください。 この投稿では、リレーショナルデータベースのスケーリングアプローチをいくつか取り上げ、SaaS アプリケーションとの関係を説明しました。これにより、リレーショナルデータベースのスケーリング方法を適切に判断できるようになります。 Part 2 では、データベースのシャーディングと、テナントをそれぞれのデータセットにルーティングする方法について調査します。 AWS SaaS ファクトリーについて AWS SaaS Factory は、SaaS ジャーニーのあらゆる段階にある組織を支援します。新製品の構築、既存アプリケーションの移行、または AWS 上での SaaS ソリューションの最適化を検討している場合でも、お手伝いできます。 AWS SaaS Factory Insights Hub にアクセスして、さらに多くの技術的およびビジネス的なコンテンツとベストプラクティスを見つけてください。 AWS SaaS Factory チームと協力し、エンゲージメントモデルについてお問い合わせいただくよう、アカウント担当者にご連絡いただくことをお勧めします。 著者について aaaaaaaaaaaaaa Dave Roberts は、シニアソリューションアーキテクトであり、AWS SaaS Factory チームのメンバーです。AWS 上で SaaS 製品を構築する AWS パートナーを支援しています。SaaS について話していないときは、ギターエフェクトペダルを作ったり、家族と森で時間を過ごすことを楽しんでいます。 Josh Hart は、Amazon Web Services のプリンシパルソリューションアーキテクトです。彼は英国の ISV 顧客と協力し、AWS 上で SaaS アプリケーションを構築およびモダナイズするのを支援しています。 翻訳はソリューションアーキテクトの「藤川 貞信」が担当しました。原文は こちら です。