本ブログは、鴻池運輸株式会社と Amazon Web Services Japan が共同で執筆しました。 鴻池運輸株式会社 (以下、鴻池運輸 )は、物流、製造、医療、空港業務など幅広いサービスを提供しています。グループ全体で約24,000名の従業員が所属し、国内外に多数の拠点を持っています。主な業務には製造業・サービス業の請負業務、国際・国内物流、定温物流、エンジニアリング業務などがあり、さらに最新技術の導入や労働負荷軽減の取り組みも積極的に行っています。 課題： 鴻池運輸では各拠点ごとに業種や業務内容が大きく異なっており、拠点別に課題解決のために用いた考え方や新しいソリューション、また自動化・省力化機器などの検証結果、費用対効果などの社内ナレッジが各拠点ごとに蓄積されていました。 2022年9月にそうした個別のナレッジを全社データベース化したものの、社内ナレッジは自然言語で記載された非構造化データとなっており、類似する業務に対する社内ナレッジへのアクセスが、通常の検索機能ではマッチングしづらく、ナレッジの共通知化がなかなか進まないという課題がありました。 具体的には、拠点ごとに得たい情報目的が少しずつ異なっていたり、同じ作業でも作業の名称や作業機器、作業場所の呼び方が違ったり、拠点名自体の表記ゆれが発生するいうこともありました。加えてナレッジデータは拠点の担当者ごとに記載するため、粒度やフォーマットがばらばらになってしまうという問題もありました 取り組み： このような課題を解決するため、鴻池運輸ではAWSのサービスを活用したRAGチャットアプリケーションを開発しました。アーキテクチャ図を以下に掲載します。 RAGアプリケーション アーキテクチャ図 主な処理は以下のようになります。 前処理： 社内ナレッジデータの記載粒度を整える 記載粒度を整えた社内ナレッジデータを Amazon Simple Storage Service (S3) にアップロード S3 に保存されたデータを Amazon Aurora (Aurora) に項目ごとに保管 検索処理： RAGチャットアプリケーションから検索を実行 Amazon Bedrock (Bedrock)を利用して検索クエリを補正 Amazon Kendra (Kendra) で対象ファイルを自然言語で検索 Kendra から返却された DocumentID を抽出 抽出された DocumentID を元に、Aurora から該当する DocumentID の全項目を返却 ( Kendra からの返却情報では粒度が不足するため、全項目を別途取得する ) フォーマット処理： Aurora から返却された情報をコンテキストに追加 Bedrock を利用して指定したフォーマット文章を返却 ( データソースのリンクを含む ) 検証方法と結果： 結果の検証については、手動で確認しました。比較内容としては出力表記とソースリンクを確認し、ソースと出力内容の内容が一致しているかを確認するという方法を用いました。比較対象としては、 「返却された文章」および「データソースのリンク」と「S3 内に保管された文章」の 3 点としました。 そして合格条件として、以下の 1. が90%以上の確率で返却されることとしました。 データソースが正しく、文章の記載内容も正しい データソースが正しいが、文章の記載内容に不備がある データソースが誤っているが、文章の記載内容が正しい どちらにも不備がある 検証結果として対象100件のうち、95件が合格。つまり「ハルシネーションが発生しない返答」という良好な結果を得られました。 その結果を踏まえてシステムの社内リリースを実施、直近 7 月のデータベースへの検索アクセス実績は従来の8倍近くに及んでいます。 数件のハルシネーションが発生したものの、ユーザー側の自然言語による検索の工夫でカバーてきていると考えており、利便性は大幅に向上したと考えています。 鴻池運輸の技術革新本部長である菅沼常務からは 「 今回のアップデートにより、アクセスし易さや検索機能が向上し、利用者の評価もアップしています 。また AWS 様のサービスを活用することでセキュリティも強化され、安心して利用できるシステムになりました。今後はグループ全体でこのシステムを利用してもらい、社内にある技術を活用して新たな価値を産み出せるような組織に変革していきたいと考えています。」 というコメントをいただきました。 今回の開発チームの構成として、WEB アプリケーションのフロントエンド / バックエンド開発者数名とプロンプトエンジニアリングを含む Bedrock の開発者 1 名になります 。少人数のチームではありましたが、エンジニアチームと現場ナレッジ側のデータ記載粒度の統一作業も並行してスムーズに実施できたため、着手から僅か4 か月で本番実装することができました。社内初となる生成 AI を用いたサービスを展開した結果、生成 AI そのものが社内でも広く認知されるようになり、また早くも別の生成AI アイデアが挙がってくるという副次的な効果も発生しています。 今後の展望： 目指す部分 : 今回の生成 AI を用いた RAG チャットアプリケーションの導入では多くの反応がありました。例えば別々の拠点間での導入サービス横展開の案件などです 。これらの対応を通じて社内ナレッジの活用を推進、課題解決のための効率化を図り、本業においてもより高品質なサービスをお客様へ提供してまいります。 具体的な対応 : そのための直近の展開としては、以下のような対応を予定しています。 ユーザーの入力内容 (ユーザープロンプト) の分析 :  ユーザープロンプトの内容からユーザーが抱える課題や要望を分析し、業務改善部門から該当拠点へのアプローチを容易にしていきます 。分析方法に関してはクラスタリング分析を想定しており、 Amazon SageMaker を利用することで効率的に実施できると考えています。 RAG アプリケーションの応用展開 :  今回の RAG チャットアプリケーションを他業務へ展開することによって業務効率向上を図ります 。対象としては「社内ヘルプデスク」や「各部門の FAQ」、「安全品質にかかわる社内周知」といった業務を検討しています。 まとめ： 今回の開発では、Amazon Bedrock と AWS Kendra を活用した RAG ソリューションによって社内情報の暗黙知を共通知化することができました。鴻池運輸では今後も AWS の先進的なテクノロジーを活用し、こうした活動を通じてより高品質なサービスをお客様に提供していく考えです。 ソリューションアーキテクト 伊藤 一成

2024 年 7 月 11 日（木）に、メディア業界のお客様向けに AWS 勉強会を開催いたしました。放送局のお客様にご登壇いただき、 AWS の活用事例についてご紹介いただきました。登壇者の所属部署および肩書きは登壇当時のものとなります。 AWS メディア業界向け勉強会 #5（2024 年 7 月 11 日開催） AWS Media Services を用いて クラウドマスターの現状・未来について検討してみた 朝日放送テレビ株式会社 技術局 放送技術センター 放送実施グループ 渡辺 雄介 氏　宮川 陸 氏 放送局には、放送番組及びＣＭ等を放送時間に合わせて順番どおりに誤りなく送信設備へ送出する「マスターシステム」と呼ばれるシステムが存在します。経営および BCP の観点から、クラウドを用いたマスターシステムの構築を検討する動きが一部の放送局で始まっていることを受け、朝日放送テレビ（ABCTV）でもクラウドに関する知見を高めるべく定期的に社内勉強会を実施しています。メディア/配信サービスが充実している AWS を用いて簡易的なマスターシステムを実装することで、クラウドで実現できることと課題、その双方の確認を行いました。 今回構築した検証環境では、  AWS Elemental MediaLive が持つスケジュール機能や AWS Lambda など用いて、マスターシステムの中枢機能である、 APS 機能を実現しました。例えば、APS データの投入と差し替え、Q テイク/カットイン制御、局ロゴや速報スーパーの重畳などの機能です。また、AWS 上で処理されたこれらの映像信号が、オンプレミス上の OFDM 変調器を通してテレビ受像機で再生できることも確認しました。その一方で、主に Web 配信で用いられる AWS Media Services でシステムを構築した場合には、エンコード遅延や伝送遅延の影響を受けること、映像信号同士の同期方法を検討する必要があること、実現したい機能によっては AWS Media Services だけを利用するのではなく、 Amazon EC2 上で動くソリューションの検討も必要であることなどが課題として浮き彫りになりました。 この勉強会では、複数の放送局で1つのマスターシステムを持つ場合の検討も行いました。1つのリージョンに映像信号を集約、送出バンクなども複数局で共用化することで、運用効率やコスト効率を上げられるのでないか、また複数のリージョンを併用することで可用性を担保し、DR 構成を実現できるのではないか、などの意見が勉強会の中で挙がりました。また、マスターシステムをより効率化するという当初の目的を達成するためには、今あるマスターシステムをそのままクラウドに移行するのではなく、必要な場合のみ必要なリソースを使用できるようにしたり、共通化できる設備や運用を極力共通化するなど、従来の考え方の大幅なアップデートが必要であるとの意見も挙がりました。 ABCTV では、今年度もこの勉強会を継続しています。 AWS Deadline Cloud でクラウドレンダリングしてみた 株式会社毎日放送 総合技術局 制作技術センター 村井 亨 氏 CG レンダリング とは、3DCG ソフトで作成した CG 素材を、計算によって 2D の映像に描画する作業です。CG 素材の作成や修正を素早く行うためには、複数のサーバで構成されたレンダリングファームを活用するなどして、レンダリングスピードを向上させることが重要です。毎日放送（MBS）では従来のオンプレミス環境に代わって、2022年から AWS Thinkbox Deadline を用いた レンダリング環境を構築 しています。AWS Thinkbox Deadline を用いることで、必要なときに必要な分だけコンピュートリソースを確保できるようになり、 スポットインスタンス を用いた使用料の削減、ハードウェア更新の負荷軽減などの効果がありました。一方で、オンプレミスの管理サーバが依然必要であったこと、レンダリングサーバの起動や終了が作業負荷として残るなどの課題もありました。 そこで MBS では、2024年4月に提供が始まった AWS Deadline Cloud を用いたレンダリング環境のオールクラウド化にいち早くチャレンジしています。AWS Deadline Cloud は、クリエイティブチームが数分でレンダーファームを簡単に設定し、より多くのプロジェクトを並行して実行できるようにスケールしながら、使用したリソースについての料金のみを支払うことを可能にする 新しいフルマネージドサービス で、レンダーファームの作成と管理、進行中のレンダーのプレビュー、レンダーログの表示と分析、およびこれらのコストの簡単な追跡を行う機能を備えたウェブベースのポータルを提供します。管理サーバが不要、かつレンダリングサーバの管理も不要となるため、現在使用している AWS Thinkbox Deadline よりもさらに運用負荷を軽減できるのではないかと MBS では期待をしています。 実際に AWS 上に検証環境を構築しテスト運用を実施したところ、CG デザイナーからは「レンダリングサーバの管理から解放された」「操作感に問題はない」「費用を可視化できるようになり嬉しい」との感想が寄せられました。またシステム管理者からは「簡単に環境が構築できるようになった」「ライセンスの購入が AWS に一元化されて支払いが楽になった」「ポート番号の管理が簡単になった」などの感想がありました。 現状の AWS Thinkbox Deadline を用いたレンダリング環境と比べて費用削減効果も期待できることから、MBS では AWS Deadline Cloud への移行を今後進めていく予定です。 中京テレビ版「データ基盤」の構築について 中京テレビ放送株式会社 技術DX 推進局 ICT 推進グループ 山本 卓也 氏 中京テレビ（CTV）では、社内の全ての人が、必要なときに、必要なデータにアクセスできる環境を実現するため、これまで個別管理されていた社内のデータを一元管理すべく、AWS 上にデータ基盤を構築しました。 このデータ基盤は様々なデータを扱いますが、「データソース」は Amazon RDS  など様々です。データ連携をすることが難しく、Web からダウンロードするしか手段が無いものや、PDF データなどは、RPA ツールやローコードツールを活用したり、名寄せ用の簡易アプリケーションを作成したりして、データ基盤にデータを取り込んでいます。例えば同じ番組であっても動画配信プラットフォームによって 番組 ID が異なるため、共通の ID を付与して名寄せを行う作業などが必要でした。 次に AWS に取り込まれたデータは、 AWS Glue 、 Amazon S3 、 AWS Step Functions  などを介して ETL 処理が行われます。Amazon S3 にデータがアップロードされた場合には、Amazon S3 イベント通知をトリガーに複数のサービスを経由して、Amazon RDS がデータソースであった場合には、 AWS Database Migration Service（AWS DMS） を経由して  Amazon Redshift  にデータが登録されます。 「マート化・可視化」においては、 Amazon Redshift の肥大化を防ぐために一部のデータを Amazon Athena を用いて直接クエリしたり、生データではなく AWS Glue で集計したあとのデータを Amazon Redshift に入れるなどの工夫を行い、 Amazon QuickSight でデータの可視化を行いました。 また「データ品質管理」では、各テーブルの監視周期を登録し、最新のデータが取り込まれているかその周期ごとに確認する仕組みを入れたり、 Amazon CloudWatch で当該のメトリクスを監視することで、データソース監視者がすぐに異常に気づける仕組みを構築しました。 このデータ分析基盤は複数名でチーム開発しているため、適切な権限付与やアクセス管理が重要でした。 Control Tower 導入時 に有効化した  IAM Identity Center を用いて、チームメンバーに対して適切な権限付与を行い、データソースとデータ基盤の AWS アカウントは分離しました。また Amazon QuickSight には社内の様々な部署の利用者がアクセスするため、複数作成したロールと共有フォルダとを紐づけて、必要なダッシュボードだけを利用者が見れるようにしました。 今後は Amazon QuickSight の社内利用の推進と Amazon Q in QuickSight の機能調査を行う予定です。  クラウド編集の取り組み 讀賣テレビ放送株式会社 技術局 技術開発部 西村 聡 氏 讀賣テレビ（ytv）では、場所に制限されずに作業が可能となるなどの利便性の向上、メンテナンス費や設備更新等に関するコストの削減、物理メディアの持ち運びをすることなく素材の受け渡しを実現するためなどの理由から、クラウド編集環境の構築に取り組んでいます。AWS が提供するコンピュートサービス内で任意の編集ソフトウェアを実行することでクラウド編集環境を実現することができ、ytv ではソフトウェアの実行環境として AWS のフルマネージド VDI サービスである Amazon Workspaces を採用しています。 従来のオンプレミス編集環境と AWS 上のクラウド編集環境との間は、ストレージサービスを介して常に素材の共有と同期が行われているため、オンプレミス上で行なった編集作業の続きを、例えばロケ先などから Amazon Workspaces に接続し、クラウド上で継続して行うことが可能です。ytv では実際に「鳥人間コンテスト2024」における VTR の準備や本編の編集でこのクラウド編集環境を活用しています。また Amazon Workspaces のスケジュールツールを自社で開発中で、社内の UI からクラウド編集環境を簡単に立ち上げられるだけでなく、将来的には社内の他のシステムと連動してクラウド編集環境の構築を自動化することも検討しています。 現在行なっているチャレンジはもう1つあります。AWS が提供するフルマネージド型のエンドユーザーコンピューティング (EUC) サービスである Amazon AppStream 2.0 を用いたクラウド編集環境の構築です。Amazon AppStream 2.0 は非永続的なストリーミングインスタンスであることから、ユーザが接続する度に新たな環境が立ち上がるという特徴があり、Amazon Workspaces で実現できていたライセンス認証などの処理に一工夫加える必要が生じます。その一方で Amazon Workspaces よりもインスタンスタイプが多く、かつ ytv の利用形態では料金が大幅（4分の1）に下がるというメリットもあります。現在、Amazon AppStream 2.0 上で EDIUS 9 が動作するところまでは実現できており、 EDIUS X 以降のバージョンについてもソフトウェアの対応状況を見ながらチャレンジしたいと考えています。 なお、クラウド編集環境を簡単にデプロイ可能な Edit in the Cloud on AWS と呼ばれるソリューションを AWS では提供しています。ぜひこちらもお試しください。  まとめ メディア業界向け勉強会の開催概要をご紹介させていただきました。引き続き業界の皆様に役立つ情報を、セミナーやブログで発信していきますので、どうぞよろしくお願い致します。 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWSのメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメールマガジンをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 この記事は SA 小南英司が担当しました。

2024 年 10 月 28 日より、新規のお客様は新しい Amazon FSx File Gateway (FSx File Gateway) を作成できなくなります。このサービスを利用したい場合は、2024 年 10 月 28 日までに FSx File Gateway を作成してください。FSx File Gateway の使用を開始するには、AWS マネジメントコンソールの Storage Gateway コンソールに移動してください。 この変更は既存のお客様には影響しません。AWS は FSx File Gateway のセキュリティと可用性に引き続き投資しています。FSx File Gateway のセキュリティアップデートは引き続きリリースしていきます。また、FSx File Gateway に関するご質問については、AWS サポートに引き続きご相談ください。 FSx File Gateway は AWS Storage Gateway の一種で、ローカルキャッシュはオンプレミスに配置するように設計されています。FSx File Gateway は、 Amazon FSx for Windows File Server (FSx for Windows File Server) のフルマネージドファイル共有へのオンプレミスアクセスを最適化します。SMB ファイル共有にファイルデータがあるお客様は、低レイテンシーの要件を満たすためにオンプレミスでのアクセスを必要とすることがあります。最近は、ネットワーク帯域幅コストの削減と帯域幅の可用性の向上に伴い、多くのお客様が、ゲートウェイやローカルキャッシュを必要とせずに、オンプレミスからクラウドの FSx for Windows File Server を使用できるようになりました。それでもなお、より高速なアクセスを必要とするローカルキャッシュのニーズのある利用者は、 Amazon FSx for NetApp ONTAP (FSx for ONTAP) とその キャッシュ技術 を利用することが検討できます。 この記事では、既存のお客様が SMB ファイル共有アクセスを FSx File Gateway から FSx for Windows File Server に切り替える方法について説明します。また、接続の問題が発生した場合に考慮すべきネットワーク構成や、FSx for Windows File Server の使用が選択肢に入らない場合の代替ソリューションについても説明します。FSx for Windows File Server に切り替えることで、FSx File Gateway のコストを削減し、ファイルがすでに FSx for Windows File Server に保存されているためデータ移行の必要がなくなり、アーキテクチャと運用上のオーバーヘッドを簡素化することができます。 FSx File Gateway 共有を FSx for Windows File Server 共有に切り替える 推奨されるアプローチは、FSx File Gateway をアーキテクチャから削除し、FSx for Windows File Server を直接使用し続けるというものです。クライアントを FSx for Windows File Server に直接接続をすると、ほとんどのワークロードのニーズを満たすことができます。SMB がクライアントマシンでローカルキャッシュを提供するためです。これを行うには、クライアントをローカル FSx File Gateway から切断し、それらのクライアントを FSx for Windows File Server のファイル共有にマッピングします。 現在のセットアップを理解する 移行プロセスに着手する前に、FSx File Gateway の典型的なセットアップを簡単に確認しておきましょう。 オンプレミスに展開された FSx File Gateway アプライアンスが、AWS のFSx for Windows File Serverファイルシステムに接続します。 すべての Windows クライアントは、ローカルの FSx File Gateway アプライアンスに接続します。 FSx File Gateway アプライアンスと FSx for Windows File Server ファイルシステムは同じ Active Directory ドメインに属し、両者の間はプライベートネットワーク接続 (例えば、 AWS Direct Connect または AWS VPN ) で接続されています。 クライアントからファイル共有へのネットワーク経路が必要です。 これについては、この記事の「ネットワークに関する考慮事項」のセクションで詳しく説明します。 FSx File Gateway を環境から削除し、クライアントを FSx for Windows File Server に接続する手順 FSx File Gateway からクライアントを切断 : まず、すべての Windows クライアントをローカルの&nbsp;FSx File Gateway アプライアンスから切断します。 ゲートウェイのキャッシュをフラッシュ :&nbsp; FSx File Gateway がローカルキャッシュのすべてのデータを FSx for Windows File Server ファイルシステムにアップロードするまで待ちます。キャッシュが完全にフラッシュされたことを確認するには、CachePercentDirty メトリックが 0.0% に達するまで監視します。 FSx for Windows File Server ファイルシステムを切り離す (オプション) :&nbsp; キャッシュがフラッシュされたら、Storage Gateway コンソールで FSx for Windows File Server ファイルシステムを切り離します。 オンプレミス環境の FSx File Gateway の電源を切る :&nbsp; ファイルシステムを切り離した後、オンプレミス環境の FSx File Gateway アプライアンスの電源を切ります。 Windows クライアントを FSx for Windows File Server ファイル共有に接続 :&nbsp; Windows クライアントを FSx for Windows File Server のファイル共有に直接接続するように設定します。この移行中、すべてのデータ、権限、その他の設定は保持されます。オンプレミス環境から FSx for Windows File Server データにアクセスする方法の詳細については、 FSx for Windows File Server ユーザーガイド を参照してください。 AWS Storage Gateway コンソールで FSx File Gateway を削除 (オプション) :&nbsp; Gateway の削除手順については、 FSx File Gateway ユーザーガイド の手順に従います。 ネットワークに関する考慮事項 多くの場合、ネットワークファイアウォールルールを変更する必要はありません。ただし、FSx File Gateway VM から FSx for Windows File Server への接続を SMB (445 番ポート) トラフィックのみに制限している場合は例外です。この場合、クライアントが存在するローカルサブネットが FSx for Windows File Server ファイル共有にアクセスできるように、ファイアウォールルールを調整する必要があります。 AWS へのネットワーク接続の種類によって、クライアントを FSx for Windows File Server ファイルシステムに直接接続できるかどうかを判断できます。FSx File Gateway のローカルキャッシュは通常、クラウドからのダウンロードデータ量を削減しますが、FSx File Gateway を削除すると、AWS から外部へのデータ転送コストが増加する可能性があることに注意してください。一方で、AWS から外部へのデータ転送コストは、FSx File Gateway を削除することによるコスト削減によって相殺されることが期待できます。 代替案 FSx for Windows File Server のファイル共有にクライアントを直接マッピングすることができない場合、帯域幅の不足やユーザーエクスペリエンスへの悪影響など、さまざまな理由が考えられます。そのような場合には、別の選択肢があります。 FSx for ONTAPは、NetApp ONTAP の一般的なデータアクセスと管理機能を備えた、AWS で完全に管理されたスケーラブルで高性能な共有ファイルストレージを提供します。FSx for ONTAP は、標準の Windows SMB サポートとデータ保護に加え、マルチプロトコルアクセス (NFS、SMB、iSCSI、NVMe-over-TCP プロトコル)、自動ストレージ拡張、階層化などの追加機能も提供します。 お客様は FSx for ONTAP を活用して、ローカルキャッシュソリューションを提供できます。このソリューションには、オンプレミスの NetApp の設置と、FSx for Windows File Server から FSx for ONTAP へのデータ移行が必要です。FSx for ONTAP への移行には、 AWS DataSync の使用をお勧めします。このアプローチでも、追加の構成、計画、実装の手順が必要です。 まとめ このブログでは、2024 年 10 月 28 日より、新規のお客様は新しい&nbsp; Amazon FSx File Gateway を作成できなくなることをお知らせしました。また、既存の FSx File Gateway のお客様が、SMBファイル共有アクセスを FSx File Gateway から FSx for Windows File Server に切り替える際の推奨アプローチについて概説しました。さらに、問題が発生した場合に考慮すべきネットワーク構成や、ローカルキャッシュが必要な場合の代替ソリューションについても説明しました。FSx for Windows File Server に切り替えることで、高可用性が実現し、FSx File Gateway のコストが不要になり、データ移行の必要がなくなり、アーキテクチャと運用上のオーバーヘッドが簡素化されます。また、既存のお客様は FSx for ONTAP の方がニーズに適していると感じるかもしれません。 さらにご質問がある場合は、Amazon FSx for Windows File Server の よくある質問 (FAQ) をご覧ください。 このブログは 2024 年 9 月 26 日に Ed Laura (Senior Product Solutions Architect) によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 <!-- '"` --> Ed Laura Ed Laura は、AWS Storage Gateway や AWS DataSync を含む AWS Edge Data Services を担当するシニア・プロダクト・ソリューション・アーキテクトです。 彼は、AWS を活用してハイブリッドストレージの課題を克服するお客様を支援することに情熱を注いでいます。 ヘルスケア、ライフサイエンス、金融サービス、メディアおよびエンターテイメント、製造など、さまざまな業界におけるインフラソリューションアーキテクチャの分野で15年以上の経験があります。 余暇には、ホッケー、アウトドアでの冒険、自転車、2匹の愛犬とのハイキングを楽しんでいます。

本稿は、2024年7月31日に AWS DevOps Blog で公開された “ Balance deployment speed and stability with DORA metrics ” を翻訳したものです。 開発チームは、ソフトウェア配信の速度と品質を高めるため、DevOps 実践を導入しています。 DevOps Research and Assessment (DORA) メトリクスは、その目的の進捗状況を測る一般的な方法です。4 つの主要なメトリクスを使って、シニアリーダーはチームの成熟度の現状を評価し、最適化する領域に取り組むことができます。 このブログ記事では、Amazon Web Services (AWS) 環境で DORA メトリクスを活用する方法を説明します。 AWS アカウントでメトリクス収集を自動的に開始できるサンプルソリューションを共有します。 DORA メトリクスを収集する利点 DORA メトリクスは、デプロイの速度と安定性の定性的側面を測定することで、開発チームのパフォーマンスと能力を把握するのに役立ちます。また、障害からの平均復旧時間を測定することで、チームの適応能力を示します。これにより、プロダクトオーナーは作業の優先順位を決定し、チームの成熟度を透明化し、現実的な作業負荷のスケジュールを立てることができます。メトリクスは経営陣とのコミュニケーションにも適しています。経営陣の支援を得て、チームの満足度とユーザーエクスペリエンスを阻害している根本的な問題を解決することができます。 ユースケース このソリューションが適用できるユースケース: 開発チームは、CI/CD ツールがホストされている ツールアカウントと、ログの集約および可視化のためのオペレーションアカウントを含む、マルチアカウントの AWS セットアップがあります。 開発者は GitHub のコードリポジトリと AWS CodePipeline を使用して、コード変更をアプリケーション環境アカウントに適用しています。 ツール、オペレーション、アプリケーション環境アカウントは、AWS Control Tower の メンバーアカウント または、 Landing Zone Accelerator on AWS ソリューションのワークロードアカウントです。 システム変更に起因するサービスの障害は、 AWS Systems Manager OpsCenter の OpsItem としてログに記録されます。 ソリューションの概要 DORA の 4 つの主要メトリクス 「4 つのキー」は、チームの実績と問題への対応力を測定します: “デプロイ頻度” はプロダクション環境で変更リリースが成功する頻度を示します。 “変更リードタイム” はコミットされたコードがプロダクション環境に到達するまでの平均時間を示します。 “変更失敗率” はプロダクション環境における変更がサービスインシデント/障害につながる頻度を示し、平均故障間隔時間の補完的な指標です。 “平均復旧時間” はサービス中断からフル復旧までの平均時間を示します。 最初の 2 つのメトリクスはデプロイの速度に焦点を当てていますが、他の 2 つはデプロイの安定性を示しています (図 1)。組織がサービスの重要性と顧客のニーズに基づいて独自の目標 (つまり DORA メトリクスのターゲット) を設定することをお勧めします。従来の DORA ベンチマークデータと、それが開発チームのパフォーマンスについて何を示しているかの議論については、 DORA メトリクスが性能を測定および改善する方法 を参照してください。 図 1. DORA メトリクスの概要 デプロイ速度と安定性のバランスを取るための DORA メトリクスの計算ロジックの詳細については、GitHub コードリポジトリ Balance deployment speed and stability with DORA metrics を参照してください。このロジックに変更を加える場合は、十分に注意して行ってください。 たとえば、変更障害率はプロダクション環境を損なう変更に焦点を当てています。プルリクエストのタグ (ホットフィックスなど) に計算を限定すると、ビルドプロセスに関連する問題が除外されます。実際にプロダクション環境で障害が発生するようなシステム変更記録を一致させることが重要です。デプロイパイプラインから失敗したデプロイの数に計算を限定すると、プロダクション環境に到達しなかったデプロイだけが考慮されます。変更関連の障害については、CI/CD ツールからのデータに依存するのではなく、AWS Systems Manager OpsCenter を記録システムとして使用しています。 同様に 平均復旧時間 は、プロダクション環境でのサービス障害が発生してからパイプラインが正常に実行されるまでの期間を測定します。パイプラインの障害が頻発する場合、ローカルでのテストが不十分であったり、パイプライン自体に問題がある可能性があるため、チームではパイプラインのステータスと復旧時間の両方を追跡することをお勧めします。 DORA イベントの収集 メトリクスの計算プロセスは 4 つのステップで実行されます: ツールアカウントでは、CodePipeline からイベントを Amazon EventBridge のデフォルトのイベントバスに送信します。 イベントはカスタムイベントバスに転送され、定義されたメトリクスと設定したフィルタに従って処理されます。 カスタムイベントバスは、 AWS Lambda 関数をコールし、メトリクスデータを Amazon CloudWatch に転送します。CloudWatch では、各メトリクスの集約ビューが表示されます。Amazon CloudWatch からは、 Amazon Managed Grafana などの指定したダッシュボードにメトリクスを送信できます。 データ収集の一環として、Lambda 関数はリードタイム変更メトリクスを計算するための関連コミットを GitHub から照会します。変更失敗率とリカバリ平均時間のメトリクスについては、AWS Systems Manager から OpsItem データを照会します。変更管理プロセスの一部として OpsItem を手動で作成するか、 CloudWatch アラームを設定 して OpsItem を自動的に作成できます。 図 2 は、これらのステップを視覚化したものです。この設定は、1 つまたは複数のチームのアカウントグループに複製できます。 図 2. AWS CodePipeline デプロイ用の DORA メトリクス設定 構築手順 次の手順に従って、ご利用の AWS アカウントにこのソリューションをデプロイしてください。 前提条件 この構築手順を実行するには、以下の前提条件を満たす必要があります。 ツール、オペレーション、アプリケーション環境用の AWS アカウント Python バージョン 3.9 以降をインストール AWS Cloud Development Kit (AWS CDK) v2 を インストール AWS CDK パイプラインを設定 AWS CodePipeline、AWS Systems Manager OpsCenter、GitHub へのアクセス権がある ソリューションのデプロイ GitHub のコードリポジトリ Balance deployment speed and stability with DORA metrics を Clone してください。 この codebase をデプロイしたり作業する前に、cdk/ ディレクトリにある constants.py ファイルで設定する必要がある項目がいくつかあります。IDE でこのファイルを開き、次の定数を更新してください: TOOLING_ACCOUNT_ID と TOOLING_ACCOUNT_REGION : これらは、AWS CodePipeline (ツール) の AWS アカウント ID と AWS リージョンを表します。 OPS_ACCOUNT_ID と OPS_ACCOUNT_REGION : これらはオペレーションアカウント用です (一元化されたログ集約とダッシュボードに使用されます)。 TOOLING_CROSS_ACCOUNT_LAMBDA_ROLE : クロスアカウントアクセスを許可し、ツールアカウントからオペレーションアカウント/Amazon CloudWatch ダッシュボードへのメトリクス投稿を可能にする AWS Lambda の IAM ロールです。 DEFAULT_MAIN_BRANCH : これは、プロダクション環境へのデプロイに使用されるコードリポジトリのデフォルトブランチです。デフォルトでは “main” に設定されています。これは、メインブランチで機能駆動型開発 (GitFlow) を想定しているためです。別の命名規則を使用する場合は、更新してください。 APP_PROD_STAGE_NAME : これは、プロダクション環境の名前で、デフォルトでは “DeployPROD” に設定されています。トランクベースの開発を行うチームのために予約されています。 環境の設定 macOS と Linux で環境をセットアップするには: 仮想環境を作成します: $ python3 -m venv .venv 仮想環境を有効にします: macOS と Linux の場合: $ source .venv/bin/activate 代替案として、Windows 上で環境をセットアップするには: 仮想環境を作成します: % .venv\Scripts\activate.bat 必要な Python パッケージをインストールします: $ pip install -r requirements.txt AWS コマンドライン インターフェイス (AWS CLI) を設定するには: AWS CLI ユーザーガイド の設定手順に従ってください。 $ aws configure sso ユーザープロファイル (オペレーションアカウントの場合は Ops、ツールアカウントの場合は Tooling など) を設定します。ユーザープロファイル名は認証情報ファイルで確認できます。 CloudFormation スタックのデプロイ ディレクトリを切り替えます $ cd cdk CDK を Bootstrap します $ cdk bootstrap –-profile Ops このプロジェクトの AWS CloudFormation テンプレートを合成します: $ cdk synth 特定のスタックをデプロイするには (概要は図 3 を参照)、次のコマンドでスタック名と AWS アカウント番号を指定してください: $ cdk deploy --profile { Tooling, Ops } ツールアカウントで DoraToolingEventBridgeStack スタックを起動するには: $ cdk deploy DoraToolingEventBridgeStack --profile Tooling Operations アカウントで他のスタック (DoraOpsGitHubLogsStack、DoraOpsDeploymentFrequencyStack、DoraOpsLeadTimeForChangeStack、DoraOpsChangeFailureRateStack、DoraOpsMeanTimeToRestoreStack、DoraOpsMetricsDashboardStack を含む) を起動するには: $ cdk deploy DoraOps * --profile Ops 次の図は、各 CloudFormation スタックで起動するリソースを示しています。これにはオペレーション アカウントの 6 つの AWS CloudFormation スタック が含まれます。最初のスタックは GitHub のコミット活動のログ統合をセットアップします。4 つのスタックには、DORA メトリクスの 1 つを作成する Lambda 関数が含まれています。6 番目のスタックは、Amazon CloudWatch で統合ダッシュボードを作成します。 図 3. このソリューションでプロビジョニングされるリソース デプロイのテスト 以下の手順でテストを実行してください: $ pytest 構築したものの確認 ツールアカウントへデプロイされたリソース DoraToolingEventBridgeStack には、オペレーションアカウントの中央イベントバスをターゲットとしている Amazon EventBridge ルールと、オペレーションアカウントにイベントをプッシュするためのクロスアカウントアクセスを持つ AWS IAM ロールが含まれています。EventBridge ルールを起動するためのイベントパターンは、AWS CodePipeline におけるデプロイの状態変化を監視します。 { &nbsp; "detail-type": ["CodePipeline Pipeline Execution State Change"], &nbsp; "source": ["aws.codepipeline"] } オペレーションアカウントへデプロイされたリソース プロダクション環境へのデプロイ頻度を追跡する Lambda 関数は、成功したデプロイの回数をカウントし、その指標データを Amazon CloudWatch に投稿します。Amazon CloudWatch では、リポジトリ名の dimension を追加することで、特定のリポジトリやチームでフィルタリングすることができます。 リードタイムメトリクスの Lambda 関数は、最初のコミットからプロダクション環境への成功したデプロイまでの期間を計算します。このメトリクスには、コードレビュー、ビルド、テスト、そして実際のデプロイなど、変更に関わるすべての要因が含まれています。 変更失敗率メトリクスの Lambda 関数は、プロダクション環境での成功したデプロイの回数と、システムの障害記録（OpsItems）の回数を追跡しています。この関数は、両方のメトリクスデータを Amazon CloudWatch に公開し、その比率を計算することで変更失敗率を算出しています。 平均復旧時間メトリクスの Lambda 関数は、プロダクション環境における SUCCEEDED ステータスのデプロイのうち、リポジトリのブランチ名にOpsItemのIDが含まれているものを追跡しています。該当するデプロイイベントごとに、この関数はOpsItemの作成時刻を取得し、OpsItem作成からの成功した再デプロイまでの期間をCloudWatchダッシュボードに公開しています。 すべての Lambda 関数は、 PutMetricData API を使用して、メトリクスデータを Amazon CloudWatch に発行します。4 つのキーの最終計算は、CloudWatch ダッシュボードで実行されます。このソリューションには、エンドツーエンドのデータフローを検証し、正常にデプロイされたことを確認できる簡単な CloudWatch ダッシュボードが含まれています。 クリーンアップ 不要になったサンプルで作成したリソースは、将来的なコスト発生を避けるために削除を忘れないでください。これは CDK CLI から行えます: $ cdk destroy --profile { Tooling, Ops } 別の方法として、各 AWS アカウントの CloudFormation コンソールに移動し、DORA 関連のスタックを選択して 削除 をクリックしてください。すべての DORA スタックのステータスが DELETE_COMPLETE になっていることを確認してください。 まとめ DORA メトリクスは、デプロイの速度と安定性を測定する一般的な方法です。このブログ記事のソリューションは、AWS アカウントでメトリクスの自動収集を開始するのに役立ちます。4 つのキーは、チームのパフォーマンスに関するコンセンサスを得るのに役立ち、改善案のデータポイントとなります。チームの満足度とユーザーエクスペリエンスを阻害する体系的な問題に対して、リーダーシップからの支援を得るためにこのソリューションを使用することをお勧めします。開発者の生産性に関する研究の詳細を学ぶには、 DevEx および SPACE などの代替フレームワークをご覧ください。 参考リソース この記事が気に入ったら、以下の記事も読んでみてください: AWS での DevOps 監視ダッシュボード AWS DevOps Monitoring Dashboard ソリューションを使用して CI/CD メトリクスのキャプチャと分析を自動化する方法 著者紹介 Rostislav Markov Rostislav is principal architect with AWS Professional Services. As technical leader in AWS Industries, he works with AWS customers and partners on their cloud transformation programs. Outside of work, he enjoys spending time with his family outdoors, playing tennis, and skiing. Ojesvi Kushwah Ojesvi works as a Cloud Infrastructure Architect with AWS Professional Services supporting global automotive customers. She is passionate about learning new technologies and building observability solutions. She likes to spend her free time with her family and animals.

みなさん、こんにちは。ソリューションアーキテクトの根本です。 今週も 週刊AWS をお届けします。 猛暑を抜けて徐々に秋を感じてきましたが、みなさまいかがお過ごしでしょうか？ 毎年夏が終わると re:Invent の近付きを感じます。今年は12月2日から6日に開催されるので、現地参加予定の方は申し込みお忘れ無く。 それでは、先週の主なアップデートについて振り返っていきましょう。 2024年9月23日週の主要なアップデート 9/23(月) Jamba 1.5 family of models by AI21 Labs is now available in Amazon Bedrock AI21 LabsのJamba 1.5モデルファミリーが新たにAmazon Bedrockで利用可能になりました。Jamba 1.5 Largeは複雑な推論タスクに優れておりインプットの長さを問わず高品質な出力を必要とするケースに最適です。一方Jamba 1.5 Miniは長いプロンプトの低レイテンシー処理に最適化されています。これらのモデルは米国東部（バージニア北部）で利用可能です。詳細については ブログ や ドキュメント をご確認ください。 Amazon EC2 Instance Connect now supports IPv6 Amazon EC2 Instance ConnectがIPv6をサポートしました。EC2 Instance ConnectはSSHベースのインスタンスアクセスを簡単に実行できる機能です。これまではIPv4経由の接続のみをサポートしていましたが、今回IPv6をサポートし、IPv4、IPv6双方を利用可能になりました。詳細については ドキュメント をご確認ください。 Amazon SageMaker Studio now supports automatic shutdown of idle applications Amazon SageMaker Studioが一定期間非アクティブなアプリケーションの自動シャットダウンをサポートしました。この機能はAmazon SageMaker Distribution image version 2.0以降を利用するJupyterLabとCodeEditor アプリケーションで、コンソールもしくはAPI経由で設定可能です。管理者はSageMakerドメインまたはユーザープロファイルレベルでシャットダウンまでのアイドル時間を設定可能です。詳細については ドキュメント をご確認ください。 9/24(火) Amazon Redshift data sharing governed through AWS Lake Formation is now available in 11 additional regions Amazon Redshift データ共有のアクセスと権限を AWS Lake Formation で一元管理する機能が大阪を含む11のリージョンで新たに利用可能になりました。この機能を使うと、Lake Formationのデータレイク管理者が Redshift データ共有で共有されるテーブルやビューへのテーブルレベル、列レベル、または行レベルのアクセスなど、きめ細かい権限を管理できるようになります。また、AWS Lake Formation タグベースのアクセス制御を Redshift データ共有に適用することもできます。これにより、複数の AWS サービスおよびアカウントにわたるデータアクセスの管理が簡単になります。詳細については、 ドキュメント や ブログ 、 デモ をご確認ください。 AWS Resilience Hub extends support for Amazon ElastiCache AWS Resilience HubがAmazon ElastiCacheを含むアプリケーションを評価できるように拡張されました。Resilience Hubは、アプリケーションのレジリエンスを定義、検証、監視することができるサービスで、ソフトウェア、インフラストラクチャ、またはオペレーションの中断による不必要なダウンタイムを回避するのに役立ちます。この拡張はResilience HubがサポートされているすべてのAWS リージョンで利用可能です。 9/25(水) Llama 3.2 generative AI models now available in Amazon Bedrock Meta社のLlama 3.2がAmazon Bedrockで利用可能になりました。Llama 3.2モデルは、高解像度画像や高度な推論に対応するま中規模なマルチモーダルモデルである90Bと11Bに加え、エッジデバイスに適したテキストのみ扱う軽量な3B, 1Bモデルまでさまざまなサイズが展開されています。MetaのLlama 3.2 90Bおよび11Bモデルは、米国西部（オレゴン）リージョンのBedrockで利用できるのに加え、米国東部（オハイオ、バージニア北部）リージョンではクロスリージョン推論によりご利用いただけます。Llama 3.2 3Bおよび1Bモデルは、米国西部 (オレゴン) およびヨーロッパ (フランクフルト) リージョンのBedrockで利用できるのに加え、米国東部 (オハイオ、バージニア北部) およびヨーロッパ (アイルランド、パリ) リージョンではクロスリージョン推論によりご利用いただけます。詳細については、 ローンチブログ 、および ドキュメント をご確認ください。 Llama 3.2 generative AI models now available in Amazon SageMaker JumpStart Amazon Bedrockと同時に、Amazon SageMaker JumpStartでもLlama 3.2が利用可能になりました。90B,11B, 3B,1Bに加え責任あるイノベーションとシステムレベルの安全をサポートするように設計されたLlama Guard 3 11B VisionもSageMaker JumpStartで簡単に利用を開始出来ます。現時点では米国東部 (オハイオ)リージョンでご利用いただけます。詳細については ローンチブログ と ドキュメント をご確認ください。 Amazon EC2 G6 instances now available in additional regions NVIDIA L4 GPUを搭載したAmazon EC2 G6インスタンスが新たに東京を含む5つのリージョンで利用できるようになりました。G6インスタンスはGPUあたり24GBのメモリを搭載した最大8つのNVIDIA L4 Tensor コア GPUと、第3世代 AMD EPYC プロセッサが搭載されており自然言語処理、言語翻訳、ビデオと画像の分析、音声認識などのユースケースでご活用いただけます。 Introducing Amazon EC2 C8g and M8g Instances Amazon EC2 C8gインスタンスとM8gインスタンスの一般提供が発表されました。これらのインスタンスはAWS Graviton4 プロセッサを搭載しており、Graviton3 ベースのインスタンスよりも最大30%高速かつより大きなCPU, メモリを兼ね備えています。C8gインスタンスは、HPCやビデオエンコーディング、広告配信など、計算量の多いワークロード、M8gインスタンスは、アプリケーションサーバー、ゲームサーバーなどの汎用ワークロードに向いています。現時点では米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、およびヨーロッパ (フランクフルト)の4つのリージョンでご利用いただけます。ワークロードのGraviton ベースのインスタンスへの移行に興味のある方は「 AWS Graviton Fast Start program 」「 Porting Advisor for Graviton 」もご確認ください。 Amazon Kinesis Data Streams announces support for Attribute-Based Access Control (ABAC) Amazon Kinesis Data Streamsがストリームタグを使用した属性ベースのアクセス制御 (ABAC) をサポートしました。Kinesis Data Streamsは、あらゆる規模のデータストリームをキャプチャ、処理、保存できるようにするサーバーレスのデータストリーミングサービスです。ABACサポートにより、ユーザーまたはプロジェクトの追加、削除、または更新時にポリシーを更新しなくてもきめ細やかなアクセス制御が可能になりました。この機能はAWS GovCloud (米国)リージョンを含むすべてのAWSリージョンで利用可能です。詳細に関しては ドキュメント や「 Attribute-Based Access Control (ABAC) for AWS 」をご確認ください。 AWS CloudTrail launches network activity events for VPC endpoints (preview) VPC エンドポイント向けの AWS CloudTrail ネットワークアクティビティがプレビューとして公開されました。この機能を利用するとネットワーク内のリソースにアクセスしているユーザーの詳細を表示できるため、データ境界での悪意のあるアクションや不正なアクションを特定して対応しやすくなります。プレビューではAmazon EC2、AWS KMS、AWS Secrets Manager、AWS CloudTrailの4つサービスで有効に出来ます。詳細は ドキュメント をご確認ください。 AWS announces general availability for Security Group Referencing on AWS Transit Gateway AWS Transit Gateway(TGW)で接続されたVPC間でのセキュリティグループ参照が一般提供されました。これまではTGW経由で接続されたVPC間のトラフィックを制御するためにセキュリティグループを利用することが出来ませんでした。セキュリティグループ参照ができるようになったことで、TGWの設計時にセキュリティグループを参照先として指定したり、インバウンドセキュリティルールの一致基準を指定してインスタンス間のトラフィックを許可したりできます。この機能はTransit Gatewayが利用可能なすべてのAWSリージョンで利用可能です。詳細については ドキュメント をご確認ください。 9/26(木) Amazon MWAA now supports Apache Airflow version 2.10 Amazon Managed Workflows for Apache Airflow(MWAA)でApache Airflow version 2.10がサポートされました。Apache Airflow 2.10にはダークモードへの対応のほか、リソース使用率の可視化、動的なデータセットスケジューリングなどの機能強化のほかセキュリティアップデートやバグ修正が含まれています。詳細なApache Airflow 2.10の変更点に関しては 変更ログ をご確認ください。 Amazon Aurora MySQL now supports RDS Data API Amazon Aurora MySQL 互換エディションで、Aurora Serverless v2および Aurora インスタンス向けに再設計されたData APIがサポートされました。Data APIはHTTP エンドポイントを介してAuroraクラスターにアクセスし、ドライバーなしでSQLを実行できるAPIです。これまでは1 秒あたり 1,000 リクエスト (RPS) のレート制限があるAurora Serverless v1クラスターのみサポートしていましたが、再設計によりスケーラビリティが向上し、Aurora Serverless v2および Aurora インスタンスではリクエストにレート制限は課されません。この機能は14のリージョンで、Aurora MySQL 3.07以降のバージョンで利用可能です。現在Aurora Serverless v1でData APIを利用するお客様は再設計のメリットを享受するために移行をお勧めします。 Amazon RDS Performance Insights now supports queries run through Data API Amazon RDS Performance InsightsがAurora PostgreSQLクラスターの RDS Data API経由のクエリのモニタリングをサポートしました。RDS Performance Insightsはデータベースのパフォーマンスを可視化し、チューニングを支援するモニタリング機能です。これまではData APIを介して実行されたクエリはサポートされませんでした。機能の詳細に関してはAmazon RDSの ユーザーガイド をご確認ください。 AWS ParallelCluster 3.11 now available with login node enhancements AWS ParallelCluster 3.11一般公開されました。AWS ParallelClusterは研究者や研究機関のIT管理者がAWSでHPCクラスターを運用できるようにするためのオープンソースのクラスター管理ツールで、科学、工学、機械学習 (ML/AI)などさまざまな目的の大規模ワークロードで活用されています。3.11ではログインノードでのNICE DCVサポートとカスタムアクションスクリプトが追加されています。リリースの詳細については、AWS ParallelCluster 3.11.0の リリースノート を参照してください。 9/27(金) AWS CodePipeline introduces pipeline variable check rule for stage level condition CodePipeline V2のステージ条件で変数チェックを行うことができるようになりました。CodePipeline V2ではステージの開始時、もしくは終了時に任意の条件で成功、失敗の判断条件を設定可能です。今回、変数をサポートしたことで、例えばCodeBuildアクションの出力結果が特定のあたいの時に成功/失敗を判断するなどより柔軟な条件設定が可能になります。詳細はこちらの ドキュメント もご確認ください。この機能はCodePipelineがサポートされているすべてのリージョンで利用できます。 最後に一つ。 11月1日に「AWS 秋の Observability 祭り ~明日使えるアセット祭り~」と題してAWS Startup Loft Tokyoでイベントが予定されています。Observabilityにお悩みの方がいらっしゃればぜひご活用ください！ – 2024年11月1日 19:00-21:00 @ AWS Startup Loft Tokyo AWS 秋の Observability 祭り ~明日使えるアセット祭り~ 申し込みは こちら それでは、また来週！ 著者について 根本 裕規(Yuki Nemoto) AWS Japan のソリューションアーキテクトとして、金融機関のお客様の AWS 活用や個別案件の技術支援を担当しています。過去には公共部門やモダナイゼーションのスペシャリストもしていました。好きなサービスは AWS CodeBuild です。週末はオフロードバイクのレースをしています！

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 今年の秋は生成AI のイベントが盛りだくさんです。10 月にかけて「 AWS Japan 生成 AI ハッカソン～生成 AI で日々の仕事はもっと楽しくなる 」が開催されます。ナビゲーター、および審査員として QuizKnock 伊沢氏、鶴崎氏に発表会に登場いただきます。応募締め切りは、10 月 2 日 (水) です。楽しみながら生成AI 活用のアイデアを形にしてみたい、という方は是非ご参加ください。 10 月 3 日 (木) には「 RAG だけじゃない！生成 AI の価値を引き出す自社データ活用とプロンプトによる LLM 調整術 」というイベントをオンラインで開催します。AWS のセッションに加え、Oisix 様から Amazon Bedrock を使ったメルマガ最適化に関する登壇をしていただきます。データ活用やマーケティングというワードにピンときた方はぜひご覧ください。 引き続き「 AWSジャパン生成AI実用化推進プログラム 」も募集中です。こちらの方もよろしくお願いいたします。 それでは、9 月 23 日週の生成AI with AWS 界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ: ケンブリッジ・テクノロジー・パートナーズ株式会社様、Amazon Bedrock を活用した社内研修のレコメンド機能により視聴数を 20% 向上 ケンブリッジ・テクノロジー・パートナーズ株式会社様は、コンサルティングファームとして質の高い業務改革を推進するために、 人材育成を重要視しています 。しかし、年間 250 以上提供されている社内研修の内容を各社員が把握し必要な研修を選択するのは困難であるといった課題を抱えていました。そこで、Amazon Bedrock を利用し、適切な社内研修を、受講すべき社員にレコメンドする仕組みを開発しました。 Bedrock により、研修概要の生成、受講をおすすめする社員の選定、レコメンド理由の生成などが行われ、研修動画の視聴を促す通知が送られます。こちらを導入した結果、従来よりも研修後の録画視聴数が約 20 %向上、そしてコンサルタント育成の精度向上を実現されました。研修概要とレコメンドの生成を分けて処理している工夫も参考になります。 AWS生成AI国内事例ブログ: 株式会社日立パワーソリューションズ、設備の保守知識の共有を目的としたRAGの構築を3ヶ月で実現 日立パワーソリューションズ様 は、風力発電設備から工場の生産ラインまで、多岐にわたる設備の保守を行う一方で、高齢化に伴ってベテラン保守作業員が減少しており、若手・中堅社員へ知識を継承することが重要課題になっています。そこで、報告書作成支援や、保守マニュアル検索などが可能な RAG サービス 「Power AI Ground（パワグラ）」を Amazon Bedrock や Amazon Kendra を活用して構築しました。報告書作成支援では、 帳票データを XML 形式に変換する工夫等を行い、回答精度を 40% から 90% に改善しました。ベテランエンジニアの知識共有という当初の課題についても解決できる見通しが得られたそうです。価格メリット、 サンプルコード 、技術支援の充実さ、がAWS採用のポイントだったと述べられています。 AWS生成AI国内事例ブログ: 株式会社 朝日新聞社、コンテンツ制作支援サービスの要約やキャプチャ生成に Amazon Bedrock を活用 株式会社 朝日新聞社様 は、 以前も取り組みを紹介 したコンテンツ制作支援サービス ALOFA を提供しています。ALOFA では、コンテンツ内容や重要な部分がすぐに把握できるように、要約やチャプターなどが生成される機能があり、こちらで Amazon Bedrock が活用されています。モデル選定の際は、単一の API を介すことで容易に複数のモデルを選択できる Amazon Bedrock の利点を活かして、複数の最新モデルの検証を行いました。また、複数リージョンの Bedrock エンドポイントを AWS Lambda から呼び出し、推論処理を分散するといった工夫を取り入れることで、安定した生成 AI の活用も実現されています。 ブログ記事「Amazon Q と Bedrock を使った SAP 生産性向上ユースケース」を公開 最近、 AWS と SAP は戦略的な協業を拡大 し、生成AI 領域の連携を深めています。このブログでは、まず SAP での生成AI 活用ユースケース例を 15 つ紹介しています。また、その中のいくつかのユースケースを実現するために、Amazon Q と Amazon Bedrock をどのように SAP と連携するかをアーキテクチャ図付きで解説しています。SAP ユーザーの方はぜひご一読を。 ブログ記事「【動画公開 &amp; 開催報告】AI 時代に技術を活かす！人材と組織、そして活用プロセス構築のポイントを解説！ ～進化し続ける技術を活用するために効果的な組織と人材育成のあり方、そしてそれらを導入する際の課題と対策について学ぶ～」を公開 2024 年 9 月 5 日に上記タイトルのイベントをオンラインで開催しました。このブログはそのイベントのレポートです。ビジネスを加速させる組織にこれから求められることや、実践力と経験値を磨く方法などを紹介しており、昨今注目されている AI CoE についても触れています。資料と動画が公開されていますので、是非ご覧ください。 サービスアップデート Amazon Bedrock で Meta Llama 3.2 が利用可能に Amazon Bedrock で Meta 社の Llama 3.2 をご利用頂けるようになりました。Llama 3.2 では4つのモデル (90B、11B、3B、1B) が用意されています。90B、11Bは、 Llama モデルで初めてマルチモーダルのユースケースをサポートし画像に対する推論タスクを行うことが可能です。3B、1Bは、エッジデバイスに適したテキストのみの軽量モデルです。詳細や対応リージョンは ブログ記事 をご参照ください。 Amazon Bedrock で AI21 Labs の Jamba 1.5 モデルファミリーが利用可能に Amazon Bedrock で AI21 Labs の Jamba 1.5 モデルファミリーが利用可能になりました。Jamba 1.5 モデルファミリーには、Jamba 1.5 Mini と Jamba 1.5 Large が含まれます。両モデルとも 256K トークンのコンテキストウィンドウを持っているのが特徴で、長い文書の要約や分析への活用が期待できます。現在バージニア北部のAmazon Bedrock で利用できます。詳細は ブログ記事 をどうぞ。 Amazon Titan Image Generator の Content Credentials機能を発表 Content Credentials とは、デジタルコンテンツの出所や真正性を証明するための技術標準です。 C2PA という業界横断組織が開発しており Amazon も参加しています。このリリースでは、Amazon Titan Image Generator で生成された画像に、C2PAメタデータがデフォルトで含まれるようになりました。これにより、生成された画像を Verify に upload することで、画像の発行元や利用モデル等が簡単に確認できるようになりました。 Amazon SageMaker JumpStart にて Meta Llama 3.2 が利用可能に 事前トレーニング済みのモデルを数回のクリックでデプロイできる Amazon SageMaker JumpStart でも Meta 社の Llama 3.2 をご利用頂けるようになりました。オハイオリージョンで利用可能です。 ブログ記事 はこちらです。 Amazon SageMaker with MLflow が AWS PrivateLink に対応 MLflow をフルマネージドな環境で利用できる Amazon SageMaker with MLflow が AWS PrivateLink に対応しました。これにより、VPC から MLflow トラッキングサーバーへの重要なデータをプライベートかつスケーラブルに転送できるようになりました。 Amazon SageMaker でモデルデプロイ時にソフトウェアとドライバーバージョンをカスタマイズ可能に SageMaker でモデルをデプロイする際、インスタンス上で使用するソフトウェアとドライバーのバージョンを選択できるようになりました。選択できるのは、例えば Nvidia ドライバーや CUDA バージョンなどです。これにより、ML アプリケーションのパフォーマンス、互換性、スケーラビリティ、運用要件に合ったホスティング環境を調整できます。 Amazon SageMaker Studio がアイドル状態のアプリケーションの自動シャットダウンに対応 Amazon SageMaker Studioが、一定期間非アクティブ状態のアプリケーションを、自動的にシャットダウンする機能に対応しました。アイドルシャットダウン時間を設定すると、SageMaker Studio はアプリケーションがアイドル状態になったことを自動的に検出し、指定された期間後にシャットダウンします。使用されていないインスタンスの料金発生を回避するのに役立ちます。 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は生成AI と毎日戯れており、特にコード生成に注目しています。好きなうどんは’もり’です。

AWS Amplify を使えば、あなたのニーズに応じて複数のバケットを構成および管理できます。開発者は、Amplify Storage を活用して、単一または複数のストレージバケットにわたってコンテンツを編成・管理でき、各バケット内の個々のパス単位で詳細なアクセス ルールを適用できます。 今年の初めに、 Amazon Simple Storage Service (Amazon S3) と統合し、クラウドベースのファイルストレージを管理するための直感的なアプローチを提供する、新しく改良された Amplify Storage をアナウンスしました (「 Amplify Storage: Amplify のフルスタック TypeScript 開発体験から利用できる Amazon S3 」)。これに加えて、バックエンド構成と JavaScript Storage API を使って、複数のストレージバケットを構成して接続できるようになったことをお知らせできて嬉しく思います。 複数のストレージバケットを持つ一般的なユースケースは、データ転送速度の向上などの最適化が必要なアプリケーションデータと長期のバックオフィスデータを分離することです。例えば、Amazon S3 Transfer Acceleration を使用してユーザー生成コンテント (写真、動画など) の高速アップロード/ダウンロード用に最適化されたバケットと、レポート、ログ、バックアップなどあまりアクセス頻度が高くない長期アーカイブデータを保存する別のバケットを設定できます。 Amplify Storage では、アップロード、ダウンロード、リスト などの API を以下に対して呼び出すことができます。 Amplify バックエンドで構成されたバケット: これらは Amplify プロジェクトのバックエンド構成で定義、管理されるバケットです。 amplify/storage/resource.ts ファイル内で、これらのバケットのバケット名やアクセスルールなどの設定を指定できます。 既存の S3 バケット: Amazon S3 コンソールで直接作成された Amazon S3 バケットとも連携できます。 Amplify バックエンドで構成されたストレージとアプリを接続する 1. Amplify プロジェクトの初期化 この例では、新しい Next.js プロジェクトを作成します。 npx create-next-app@latest multi-bucket-app 設定手順に従い、「Would you like to use TypeScript?」と尋ねられたら「Yes」を選んでください。 現在のフォルダに「multi-bucket-app」という名前のアプリがあります。この新しいアプリに移動し、AWS Amplify を初期化してください。 &gt;cd multi-bucket-app &gt;npm create amplify@latest このコマンドにより、プロジェクトに以下の構造を持つ「amplify」フォルダが作成されます。 2. Amplify バックエンドでストレージバケットの定義 まず、ユーザープロフィール写真のようなユーザー生成コンテンツを保存するバケットを作成します。認証済みのユーザーが assets/photos/* パスに読み書きできるようにしつつ、ゲストユーザーにはこのパスから読み取りのみできるようにします。 amplify/storage/ の下に新しい resource.ts ファイルを作成します。このファイルで最初のストレージバケットの設定を定義できます。 import { defineStorage } from '@aws-amplify/backend'; export const userDataBucket = defineStorage({ name: 'user-data-bucket' access: (allow) =&gt; ({ 'assets/photos/*': [ allow.guest.to(['read']), allow.authenticated.to(['read','write']), ] }) }); 次に、 amplify/backend.ts ファイルで Amplify バックエンド定義にストレージバケットの設定を追加してください。 import { defineBackend } from '@aws-amplify/backend'; import { auth } from './auth/resource'; import { userDataBucket } from './storage/resource'; defineBackend({ auth, userDataBucket }); この例では、アプリがユーザー生成コンテンツバケットに対して頻繁に呼び出しを行い、エンドユーザーに関連する写真を表示します。これらの写真をクライアントに素早く配信できるよう、このバケットで Amazon S3 Transfer Acceleration を有効化します。 注 : Amazon S3 Transfer Acceleration は、大きなオブジェクトの長距離転送時に、Amazon S3 への転送と Amazon S3 からの転送の両方を最大 50～500 % 高速化できます。詳細については、 S3 Transfer Acceleration を参照してください。 import { defineBackend } from '@aws-amplify/backend'; import { auth } from './auth/resource'; import { userDataBucket } from './storage/resource'; defineBackend({ auth, userDataBucket }); const { cfnBucket } = backend.userDataBucket.resources.cfnResources ; cfnBucket.accelerateConfiguration = { accelerationStatus: "Enabled" } npx ampx sandbox コマンドを実行すると、Amplify バックエンドのローカルサンドボックス環境が起動するので、アプリをローカルでテストできます。同様に、より多くのストレージバケットを定義する場合は、 amplify/storage/resource.ts ファイル内で同じ defineStorage メソッドを使用できます。 import { defineStorage } from '@aws-amplify/backend'; export const userDataBucket = defineStorage({ name: 'user-data-bucket', isDefault: true, access: (allow) =&gt; ({ 'assets/photos/*': [ allow.guest.to(['read']), allow.authenticated.to(['read','write']), ] }) }); export const reportingDataBucket = defineStorage({ name: 'reporting-data-bucket', access: (allow) =&gt; ({ 'reportingData/logs/*': [ allow.groups(['admins']).to(['read','write']), ], 'reportingData/performance/*': [ allow.groups(['admins']).to(['read','write']), ] }) }); 複数のストレージバケットを扱う場合は、1 つをデフォルトのバケットに指定する必要があります。そのためには、 amplify/storage/resource.ts ファイル内のストレージバケット定義の 1 つで、 isDefault プロパティを true に設定します。この指定したデフォルトのバケットは、特定のバケットが提供されていない場合に、Amplify Storage API によって自動的に使用されます。 新しいリソースを amplify/backend.ts にあるバックエンド構成にインポートしてください。 import { defineBackend } from '@aws-amplify/backend'; import { auth } from './auth/resource'; import { userDataBucket, reportingDataBucket } from './storage/resource'; defineBackend({ auth, userDataBucket, reportingDataBucket }); const { cfnBucket } = backend.userDataBucket.resources.cfnResources ; cfnBucket.accelerateConfiguration = { accelerationStatus: "Enabled" } 3. Amplify Storage ライブラリを使用して特定のバケットにファイルをアップロード ストレージバケットにアップロードするには、既存の Amplify Storage API を引き続き使用できます。 amplify/storage/resource.ts ファイルで定義されたバケット名を渡してください。バケット名が指定されていない場合は、同じ resource.ts ファイルで構成された既定のバケットにファイルがアップロードされます。 import { uploadData } from 'aws-amplify/storage'; //Set the file variable to the file you want to upload const file: File const { result } = await uploadData({ path: 'reportingData/logs/08222024.txt', data: file, options: { bucket: 'reporting-data-bucket' } }); 他の API のようにダウンロードデータ、リスト、コピーなどで使う S3 バケットも bucket オプションで指定できます。その他の Amplify Storage API については、 Amplify Storage のドキュメンテーション を参照してください。 既存の S3 バケットへのアプリケーションの接続 別の方法として、バケット名とリージョンを指定して、既存の Amazon S3 バケットに直接ファイルをアップロードすることもできます。この方法を使えば、Amplify バックエンド構成で定義されていない、カスタム S3 バケットと Amplify Storage ライブラリを併用できます。 既存の S3 バケットにファイルをアップロードするには、Amplify Storage API のオプションとして、実際のバケット名 (Amazon S3 コンソールで確認できるもの) と対応する AWS リージョンを渡してください。 Amplify Storage API でカスタム Amazon S3 バケットを使用する手順 をご参照ください。 import { uploadData } from 'aws-amplify/storage'; //Set the file variable to the file you want to upload const file: File const { result } = await uploadData({ path: 'reportingData/logs/08222024.txt', data: file, options: { bucket:{ bucketName: 'bucket-name-from-s3-console', region: 'us-east-2' } } }); まとめ AWS Amplify を使えば、複数のストレージバケットを設定・管理することで、アプリのコンテンツをより適切に整理し分離できるようになりました。ストレージバケットの設定方法の詳細については、 Amplify Storage ドキュメント を参照してください。Amplify はオープンソースプロジェクトであり、私たちは常にコミュニティからのフィードバックを求めています。私たちのいずれかのチャネルで皆様からご意見をお聞かせください。 Discord で議論に参加するか、 GitHub プロジェクト に機能リクエストや不具合報告をお寄せください。 本記事は「 Add multiple storage buckets to your app using AWS Amplify – NEW 」を翻訳したものです。 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を中心に技術支援を行っています。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

AWS Amplify は、Amplify Functions に関数の実行ログストリーミングと cron および自然言語によるスケジューリングサポートの 2 つの新機能を発表します。Amplify では、開発者が TypeScript でサーバーレス関数を作成し、数秒でビジネスロジックをデプロイできるため、すばやくイテレーションできます。Amplify Functions の詳細については、 AWS Amplify の Functions ドキュメント を参照してください。 ストリーミング関数ログ Amplify の開発者ごとのクラウドサンドボックス では、開発者がライブリソースを使ってアプリケーションのバックエンドを設計、構築、イテレーションできる開発環境を提供されます。さらにイテレーションサイクルを減らすために、Amplify は開発者が関数の実行ログをターミナルに直接ストリームできるようになり、ローカルの開発環境から離れることなく関数実行のインサイトが得られるようになりました。 開始するには、 --stream-function-logs オプションを指定して、すべての関数ログのストリーミングをオプトインしてください。 npx ampx sandbox --stream-function-logs たとえば、認証リソースに Amazon Cognito Lambda トリガー としてアタッチされた関数の集合がある場合、フロントエンドフレームワークの開発サーバーを起動し、認証フローを通って、各関数の呼び出しからログを検査できます。これらはすべて AWS マネジメントコンソールに移動することなく行えます。 例えば、多数の関数があり、バックエンド機能の一部のデバッグだけに興味がある場合、 --logs-filter を指定して関数名に基づいてログ出力をフィルタリングできます。 npx ampx sandbox --stream-function-logs --logs-filter auth ログフィルターでは、関数名でフィルタリングできます。上記のコマンド例を使用する場合、トリガーのリソース名の規則は次のようになります。 // amplify/auth/post-confirmation/resource.ts import { defineFunction } from "@aws-amplify/backend" export const postConfirmation = defineFunction({ name: "auth-post-confirmation", }) ただし、複雑なフィルターの場合、 --logs-filter オプションは正規表現を受け入れます。上記と同じ例を用いて、関数名が “auth” で 始まる ものだけのログをフィルターする場合は次のようになります。 npx ampx sandbox --stream-function-logs --logs-filter "^auth" sandbox プロセスは、対応する正規表現と一致する関数のログのみを出力します。 [Sandbox] Watching for file changes... File written: amplify_outputs.json [auth-pre-sign-up] 3:36:34 PM INIT_START Runtime Version: nodejs:18.v30 Runtime Version ARN: arn:aws:lambda:us-east-1::runtime:f89c264158db39a1cfcbb5f9b3741413df1cfce4d550c9a475a67d923e19e2f4 [auth-pre-sign-up] 3:36:34 PM START RequestId: 685be2bd-5df1-4dd5-9eb1-24f5f6337f91 Version: $ LATEST [auth-pre-sign-up] 3:36:34 PM END RequestId: 685be2bd-5df1-4dd5-9eb1-24f5f6337f91 [auth-pre-sign-up] 3:36:34 PM REPORT RequestId: 685be2bd-5df1-4dd5-9eb1-24f5f6337f91 Duration: 4.12 ms Billed Duration: 5 ms Memory Size: 512 MB Max Memory Used: 67 MB Init Duration: 173.67 ms [auth-post-confirmation] 3:38:40 PM INIT_START Runtime Version: nodejs:18.v30 Runtime Version ARN: arn:aws:lambda:us-east-1::runtime:f89c264158db39a1cfcbb5f9b3741413df1cfce4d550c9a475a67d923e19e2f4 [auth-post-confirmation] 3:38:40 PM START RequestId: fce69b9f-b257-4af8-8a6e-821f84a39ce7 Version: $ LATEST [auth-post-confirmation] 3:38:41 PM 2024-07-19T22:38:41.209Z fce69b9f-b257-4af8-8a6e-821f84a39ce7 INFO processed 412f8911-acfa-41c7-9605-fa0c40891ea9 [auth-post-confirmation] 3:38:41 PM END RequestId: fce69b9f-b257-4af8-8a6e-821f84a39ce7 [auth-post-confirmation] 3:38:41 PM REPORT RequestId: fce69b9f-b257-4af8-8a6e-821f84a39ce7 Duration: 264.38 ms Billed Duration: 265 ms Memory Size: 512 MB Max Memory Used: 93 MB Init Duration: 562.19 ms [auth-pre-authentication] 3:38:41 PM INIT_START Runtime Version: nodejs:18.v30 Runtime Version ARN: arn:aws:lambda:us-east-1::runtime:f89c264158db39a1cfcbb5f9b3741413df1cfce4d550c9a475a67d923e19e2f4 [auth-pre-authentication] 3:38:41 PM START RequestId: 9210ca3a-1351-4826-8544-123684765710 Version: $ LATEST [auth-pre-authentication] 3:38:41 PM END RequestId: 9210ca3a-1351-4826-8544-123684765710 [auth-pre-authentication] 3:38:41 PM REPORT RequestId: 9210ca3a-1351-4826-8544-123684765710 Duration: 3.47 ms Billed Duration: 4 ms Memory Size: 512 MB Max Memory Used: 67 MB Init Duration: 180.24 ms [auth-post-authentication] 3:38:42 PM INIT_START Runtime Version: nodejs:18.v30 Runtime Version ARN: arn:aws:lambda:us-east-1::runtime:f89c264158db39a1cfcbb5f9b3741413df1cfce4d550c9a475a67d923e19e2f4 [auth-post-authentication] 3:38:42 PM START RequestId: 60c1d680-ea24-4a8b-93de-02d085859140 Version: $ LATEST [auth-post-authentication] 3:38:42 PM END RequestId: 60c1d680-ea24-4a8b-93de-02d085859140 [auth-post-authentication] 3:38:42 PM REPORT RequestId: 60c1d680-ea24-4a8b-93de-02d085859140 Duration: 4.61 ms Billed Duration: 5 ms Memory Size: 512 MB Max Memory Used: 68 MB Init Duration: 172.66 ms Amplify ドキュメントを参照して、関数ログのストリーミングの詳細を確認してください 。 関数の予約実行 2 つ目の改善は、開発者が cron 式や自然言語を使って関数の実行間隔をスケジューリングできるようになったことです。開始するには、新しい schedule プロパティで間隔を指定します。 // amplify/jobs/drink-some-water/resource.ts import { defineFunction } from "@aws-amplify/backend" export const drinkSomeWater = defineFunction({ name: "drink-some-water", schedule: "every 1h", }) スケジュールは間隔として定義され、毎時間パフォーマンスの良い投稿の「トップページ」を生成したり、週次ダイジェストとしてパフォーマンスの良い投稿をまとめるなど、さまざまな用途に使用できます。新しい間隔を作成するには、自然言語を使用するだけです。 以下の例では、「 [リマインド ] 毎日水を飲む」関数のスケジューリングを定義しています。 // amplify/jobs/drink-some-water/resource.ts import { defineFunction } from "@ aws-amplify/backend" export const drinkSomeWater = defineFunction({ name: "drink-some-water", schedule: [ "every 5m", "every 1h", "every day", "every week", "every year", ], }) スケジューリングはさらに、強く型付けされたプロパティ値を提供することで簡素化されます。これにより、タブ補完が可能になり、スケジュールがシステムの期待に沿うことが保証されます。スケジュールは cron 式を使って複雑な要件を定義できます。たとえば、ゴミを出すリマインダーは、特定の時間に 2 日間だけ出る場合があります。 // amplify/jobs/remind-me-to-take-the-trash-out/resource.ts import { defineFunction } from "@aws-amplify/backend"; export const remindMe = defineFunction({ name: "remind-me-to-take-the-trash-out", schedule: [ // every tuesday at 9am "0 9 ? * 3 *", // every friday at 9am "0 9 ? * 6 *", ] }) 内部的には、スケジュールは Amazon EventBridge ルール によって実現されています。このルールは、EventBridge がイベントにどのように対応するかを記述する方法です。ここでは、これらのルールは関数が実行される間隔を示しています。 スケジューリング関数の詳細は、Amplify のドキュメントをご覧ください まとめ 2 つの新機能を Amplify Functions で体験していただけることを心よりお待ちしております。フィードバックがあれば、ぜひ GitHub リポジトリ までお寄せください。同じ志を持つ開発者コミュニティにご参加いただく場合は、 Discord コミュニティ にご参加ください。 本記事は「 New features for Amplify Functions: Scheduling and Log Streaming 」を翻訳したものです。 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を中心に技術支援を行っています。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

本ブログはケンブリッジ・テクノロジー・パートナーズ株式会社様と Amazon Web Services Japan が共同で執筆いたしました。 みなさん、こんにちは。AWS ソリューションアーキテクトの山澤です。 最近、 AI 技術がどんどん賢くなってきて、私たちの仕事や生活が今後どのように変わっていくのかを同僚と話す機会が増えた気がします。このように急激に変化している時代において、「これからどのようなスキルを磨くべきか悩む」という方も多いのではないでしょうか。特に、たくさんの研修プログラムを用意している会社では、社員が自分に合った研修を選ぶのに迷うことがあるかもしれません。 本記事では、ケンブリッジ・テクノロジー・パートナーズ株式会社様が、このような課題に対して Amazon Bedrock を活用し、生成 AI による社内研修の説明付きレコメンド機能を構築されましたので、その事例をご紹介します。 お客様の状況と検証に至る経緯 ケンブリッジ・テクノロジー・パートナーズ株式会社様は、コンサルティングファームとして質の高い業務改革を推進するため、人材育成を重要視しています。この人材育成を効果的に進めるために、LECO（ Learning ECO system ）という社内サービスを通じて、社内研修の「講師」と「受講者」を効果的にマッチングし、学習意欲のある社員に適切な研修機会を提供されています。 しかし、このような積極的な取り組みを行っているものの、人材育成の最適化には依然として以下のような課題を感じられていました。 コンサルタントの育成のために、年間 250 を超える社内研修を提供しているが、各研修で受講に適している社員に受講してもらえていない。 研修数が多いため、社員は各研修の内容を把握できておらず、自分に必要な研修を選択することが困難になっている。 そこで、基盤モデルの変更が容易な Amazon Bedrock を利用し、適切な社内研修を、受講すべき社員にレコメンドする仕組みを開発しました。 お客様が開発された生成 AI を活用した社内研修の説明付きレコメンド機能 ケンブリッジ・テクノロジー・パートナーズ株式会社様が開発された社内研修の説明付きレコメンド機能は、「アンケートコメント」、「社員一覧」、「職能別の期待値や評価基準」、「直近の研修受講履歴」など、多様な非定型データを活用しています。これらを Claude 3 Opus の入力データとして使用し、その出力結果を Slack に通知する仕組みを構築されました。 そして、実際に研修が実施された際に、研修の内容やレコメンドする社員を Slack にレポートとして通知しています。 こちらが Slack に通知されるレポートの例です。このレポートにより、研修を受講してほしい社員に対して、録画された研修の動画を視聴するように促しています。 また、Claude での処理は、図に示しているように、 2 回に分けて行われています。2 回に分けることで、ステップ 1 の出力結果をステップ 2 の入力として使用する工夫をされています。 ステップ 1 ：「研修情報」、「アンケート結果」の情報をもとに、「概要」、「参加者の感想」の要約を生成 ステップ 2：「ステップ 1 の要約結果」、「社員一覧」、「職能別の期待値や評価基準」、「直近の研修受講履歴」の情報をもとに、「研修受講をレコメンドする社員」「レコメンド理由」を生成 導入効果 社内研修の説明付きレコメンド機能を導入した結果、以下の効果が得られました。 従来よりも研修後の録画視聴数が約 20 %向上しました。 研修を受講してほしい社員に受講してもらえることで、本来狙っていたコンサルタントの育成の精度を上げることができました。 従来の AI によるレコメンドでは、予想結果は表示されるものの、その理由までは表示されないことが多かったが、今回のアプローチでは、生成 AI を用いて、レコメンド理由もあわせて表示されている点が特徴的です。この工夫によって、研修を受講するのに適している可能性のある社員の興味を惹くことができたと考えられています。 まとめ 今回は、ケンブリッジ・テクノロジー・パートナーズ株式会社様が開発された社内研修の説明付きレコメンド機能をご紹介いたしました。本検証を通じて、お客様から以下のコメントを頂いております。 「今回の取り組みを通じて、今まで活用しにくかった自然言語データが業務に利用可能になりました。その結果、様々な箇所でイノベーションの種があることが分かりました。」 最近、多くの企業が社内に蓄積されたデータの有効活用に高い関心を寄せているという話を耳にすることがあります。このような取り組みは、社内データを活用して、人材育成や組織の生産性向上を目指す企業にとって参考になるのではないでしょうか。 なお、ケンブリッジ・テクノロジー・パートナーズ株式会社様の人材育成に関する情報は、 こちら で公開されております。社員の成長が生命線であるコンサルティングファームが、育成の仕組みをどのように構築し運用しているか、ご興味のある方は是非ご確認ください。 ケンブリッジ・テクノロジー・パートナーズ株式会社様 : アソシエイトディレクター テクニカル・アーキテクト 広沢 元様（右端）、コンサルタント 吉村 勘太郎様（右から 2 番目） Amazon Web Services Japan : アカウントマネージャー 浜崎 佳子（左端）、ソリューションアーキテクト 山澤 良介（左から 2 番目） ソリューションアーキテクト 山澤 良介 (X – @ymzw230 )

本稿は、2024年5月21日に Networking &amp; Content Delivery で公開された “ Introducing mTLS for Application Load Balancer ” を翻訳したものです。 AWS は 2023年11月26日、 Application Load Balancer (ALB) で X509 証明書を使用したクライアントの相互認証機能をサポートすると発表しました。この記事では、この新機能を実装するためのオプションと、実装時に考慮すべき点について説明します。 ALB はアプリケーション層 ( OSI モデル の第7層) で動作し、バックエンドターゲットに着信する HTTP/HTTPS リクエストのロードバランシングを行います。ALB は一般的に、スケーラブルで安全な Web アプリケーションを作成するために使用され、ホスト名、完全パス、または HTTP ヘッダー条件に基づいてルーティングできる高度なルーティングルールをサポートしています。詳細については、 Application Load Balancer のドキュメント を参照してください。 セキュリティの観点から、ALB では HTTPS リスナーを作成できます。HTTPS リスナーを使用すると、ALB はクライアントとの TLS セッションを終端します。ALB には、AWS WAF とのネイティブ統合機能があり、Web アプリケーション用のルールを作成し、ALB の背後で実行されているアプリケーションを保護できます。 mTLS コンセプト 相互トランスポート層セキュリティ (mTLS) は、ネットワーク通信を保護するために使用される TLS プロトコルを拡張したものです。TLS は通常、インターネット上の安全な接続を確立するために使用され、認証、データの機密性、および整合性を確保します。ただし、従来の TLS では、認証は一方向であり、サーバーがクライアントに対して自身を認証しますが、クライアントの身元は検証されません。 これに対し、mTLS では、サーバーとクライアントの両方が相互に認証することが求められるため、「相互」または「双方向」TLS と呼ばれています。mTLS に関連する概念として以下のようなものがあります: 認証局 (CA): 企業にTLS証明書を提供する組織や団体のことです。認証局は、TLS 証明書を発行する前に、ドメイン名と所有者の詳細を確認します。 TLS 証明書: システム (Web クライアントなど) が別のシステム (Web サーバーなど) の身元を検証できるようにする、デジタルオブジェクトです。TLS 証明書に含まれる詳細情報により、クライアントはサーバーとの暗号化された接続を確立できます。 サーバー証明書: サーバーの身元を証明する TLS 証明書です。 クライアント証明書: クライアントの身元を証明する TLS 証明書です。 証明書 信頼チェーン: TLS 証明書の順序付きリストです。チェーンは (クライアント/サーバーの TLS 証明書である) リーフ証明書から始まり、ルート証明書で終わります。リーフ証明書とルート証明書の間の証明書は中間証明書と呼ばれます。チェーンの各証明書は、次の証明書で識別された組織/団体によって署名されています。これは図1に示されています。 図1 : 証明書信頼チェーン TLS ハンドシェイク: クライアントとサーバーが相互に TLS 証明書を使って認証を行い、暗号化の標準に合意し、データを安全に転送するための secure チャネルを作成するプロセスです。詳細については、 TLS のドキュメント を参照してください。クライアントは、TLS ハンドシェイク中に TLS 証明書をサーバーと共有します。これにより、サーバーはクライアントを認証できます。 証明書失効リスト (CRL): 信頼されるべきではないブロックリストに載せられた証明書のリストです。 mTLS プロセスは、スマートデバイス、API、マイクロサービス間の通信を保護したり、規制要件を満たすために相互の身元を確認する必要がある状況で一般的に使用されます。また、VPN (仮想プライベートネットワーク) や組織内部の通信を保護するためにも使用されています。 mTLS を実装するには、サーバーとクライアントの両方が信頼できる CA によって発行された電子証明書を持っている必要があります。これらの証明書は同じ CA または異なる CA によって生成することができ、ハンドシェイク過程で相手の信頼性を証明するために使用されます。 Application Load Balancerで mTLS クライアント認証を使用する Application Load Balancer は、クライアントの証明書チェーンの深さと大きさが一定の範囲内にある場合、mTLSをサポートしています。現在サポートされている最大サイズと深さについては、 Application Load Balancer のクォータ をご確認ください。ClientCertExceedsDepthLimit および ClientCertExceedsSizeLimit の各 Amazon CloudWatch メトリクスを使用すると、これらの制限を超えた要求を追跡できます。 Application Load Balancer は、mTLSで以下の2つの動作モードをサポートしています: mTLS 検証モード mTLS パススルーモード mTLS 検証モード Application Load Balancer で mTLS検証モードを使用するには、トラストストアを作成する必要があります。トラストストアには、クライアント証明書を検証するために使用される1つの CA 証明書バンドルがあります。自分の証明書を持参するか、 AWS Certificate Manager(ACM) を使用して証明書を生成できます。ALB の mTLS 検証モードには、AWS 管理の CA を使用できます。 AWS Private Certificate Authority は、高可用性の管理CA サービスで、組織がプライベート証明書を使用してアプリケーションとデバイスを保護するのに役立ちます。証明書の発行と管理の詳細については、 ACMのドキュメント を参照してください。 信頼しないクライアント証明書を指定するには、1つ以上の証明書失効リスト (CRL) をトラストストアに関連付けます。失効リストを S3 バケットにアップロードし、そのバケットをトラストストアで指定します。ALB は S3 から CRL をインポートし、CRL チェックは ALB によって行われるため、毎回 S3 から CRL をフェッチする必要がなくなります。これにより、ALB は CRL を使用したクライアント認証時に遅延を生じません。CRL 構成の詳細については、ドキュメントの「 Application Load BalancerでのTLSによる相互認証 」のページをご覧ください。 この検証モードでは、ALB がトラストストアを使用してクライアント証明書を検証します。これにより、有効な証明書で認証されたクライアントのみがバックエンドターゲットと通信できます。ALB は、認証されていないユーザーからのリクエストをブロックします。これにより、mTLS 認証に必要な計算負荷の大きな処理を ALB にオフロードし、バックエンドターゲットの処理リソースをアプリケーションサービスの提供に使用できます。図2は、検証モードのアーキテクチャを示しています。 ALB の mTLS 検証モードは以下のステップで検証されます。 [1] CA 証明書バンドルを Amazon S3 にアップロードし、必要に応じて CRL もアップロードします。 [2] トラストストアを作成し、CA 証明書バンドルの Amazon S3 パスを指定します。必要に応じて CRL の Amazon S3 パスも指定します。 [3] クライアントが ALB との TLS セッションを開始します。TLS ハンドシェイク中に、クライアントは TLS 証明書を提示します。 [4] TLS セッションが ALB で終了します。TLS ハンドシェイク中に、ALB はサーバー側の証明書を提示し、クライアントの証明書を受け取ります。 [5] ALB は トラストストアを参照し、証明書を検証します。信頼できない CA によって署名された証明書、証明書失効リスト (CRL) に記載された証明書、有効期限切れの証明書の場合、クライアント認証は失敗します。クライアント認証が失敗する可能性のあるシナリオの完全なリストについては、ドキュメントの「 Application Load BalancerでのTLSによる相互認証 」のページを参照してください。クライアント認証に失敗した場合、ALB は TLS 接続を拒否します。ただし、必要に応じて期限切れの証明書を許可するようALBを設定することができます。 [6] クライアントと ALB 間で TLS セッションが正常に確立されます。 [7] ALB はバックエンドのターゲットとは別のセッションを作成します。 ALB が TLS セッションを終端するため、バックエンドターゲットへのトラフィックの負荷分散には、 ALB のルーティングアルゴリズム を使用できます。例えば、重み付きラウンドロビンルールを使用して、Web アプリケーションのブルーグリーンデプロイメントを作成できます。 クライアント認証を実行するほか、ALB は次の証明書メタデータをバックエンドターゲットに送信します。 X-Amzn-Mtls-Clientcert-Serial-Number – リーフ証明書の16進数表記、クライアント証明書のシリアル番号。例: 0ABC1234。 X-Amzn-Mtls-Clientcert-Issuer – XN_FLAG_RFC2253 フラグを使って X509_NAME_print_ex で印刷された発行者の識別名(DN) X-Amzn-Mtls-Clientcert-Subject – XN_FLAG_RFC2253 フラグを使って X509_NAME_print_ex で印刷された件名 DN X-Amzn-Mtls-Clientcert-Validity – notBefore と notAfter 日付の ISO8601 形式、例: NotBefore=2023-09-21T01:50:17Z; NotAfter=2024-09-20T01:50:17Z X-Amzn-Mtls-Clientcert-Leaf – URLエンコーディングされたPEM形式のリーフ証明書 この情報を使用すると、バックエンドターゲットでこれらのメタデータフィールドに基づいてロジックを実装できます。例えば、X-Amzn-Mtls-Clientcert-Leaf フィールドを解析して証明書の有効期限を取得し、証明書の有効期限が近づいている場合にクライアントにカスタムメッセージを送信できます。 mTLS パススルーモード このモードでは、ALB はクライアント認証のために HTTP ヘッダー AMZN-MTLS-CLIENT-CERT でバックエンドターゲットに証明書チェーン全体を転送します。ALB は、リーフ証明書を含む証明書チェーン全体を、URL エンコーディングされた PEM 形式で、+、=、/ を安全な文字として挿入します。AMZN-MTLS-CLIENT-CERT ヘッダーの例を次に示します。 X-Amzn-Mtls-Clientcert: `-----BEGIN%20CERTIFICATE-----%0AMIID&amp;lt;...reduced&lt;br /&gt;...&amp;gt;do0g%3D%3D%0A-----END%20CERTIFICATE-----%0A-----BEGIN%20CERTIFICAT&lt;br /&gt;E-----%0AMIID1&amp;lt;...reduced...&amp;gt;3eZlyKA%3D%3D%0A-----END%20CERTIFICATE---&lt;br /&gt;--%0A` バックエンドのターゲットは、この HTTP ヘッダーを解析し、証明書を抽出して、クライアント認証を実行できる必要があります。クライアント認証プロセスを制御したい場合は、このモードを使用します。図3がパススルーモードのアーキテクチャです。 図3 : Application Load Balancer の mTLS パススルーモード ALB の mTLS パススルーモードは以下のステップで検証されます: [1] クライアントが ALB と TLS セッションを開始します。 TLS ハンドシェイク中に、クライアントは TLS 証明書を提示します。 [2] TLS セッションは ALB で終了します。 TLS ハンドシェイク中に、ALB はサーバー側の証明書を提示し、クライアントの証明書を受け取ります。 [3] ALB はバックエンドターゲットとの新しいセッションを作成します。このセッションは HTTP または HTTPS のいずれかになり、ユーザー構成に基づきます。 ALB は、AMZN-MTLS-CLIENT-CERT という HTTP ヘッダーに完全な証明書チェーンを含めます。 [4] バックエンドターゲットはクライアント証明書を受け取り、AMZN-MTLS-CLIENT-CERT HTTP ヘッダーからクライアント証明書チェーンを解析するロジックを実装する必要があります。また、ターゲットはクライアント認証を実行するロジックを実装する必要があります。 mTLS パススルーモードが有効な場合、クライアント証明書が存在しないと、ALB は HTTP ヘッダーを追加しません。バックエンドターゲットは、クライアント証明書のない要求を処理するロジックを実装する必要があります。 バックエンドターゲットでクライアント認証に失敗した場合、ターゲットは HTTP エラーコードを ALB に送り返す必要があります。ALB はこのエラーコードをクライアントに転送します。 HTTPS リスナーの場合、バックエンドターゲットはクライアントの証明書に基づいてクライアントを認証し、ALB はクライアントとの間の TLS 接続を終端し、ターゲットとの別の TLS セッションを開きます。ALB とバックエンドターゲットの間の TLS セッションは、 ターゲットにインストールした証明書を使って作成 されます。 ALB が TLS 接続を終端するため、バックエンドターゲットへのトラフィックの負荷分散には ALB のルーティングアルゴリズム を使用できます。 スマートカーが一時的にインターネット接続を失うなど、一部のスマートデバイスは長期間オフラインになる可能性があります。このような場合、バックエンドターゲットには期限切れの TLS 証明書を処理するロジックを実装する必要があります。 パススルーモードを実装するもう1つのユースケースは、アプリケーションベースのクッキー (Cookie) の実装です。この場合、バックエンドターゲットが認証済みクライアントにクッキーを発行し、クライアントはこのクッキーを通信に使用します。これにより、バックエンドターゲットが各要求の証明書チェーン全体を処理する必要がなくなります。オープンソースライブラリを使ってバックエンドターゲットにクッキーを実装し、クッキーに基づいてクライアントの認証ステータスを追跡するロジックを実装できます。 モニタリング ALB は、ロードバランサーに送信されたすべてのリクエストについて、接続ログを提供します。これらのログは Amazon Simple Storage Service(Amazon S3) バケットに送信され、クライアントの IP アドレス、TLS 暗号化の詳細、リクエストが拒否された場合のエラーコードなどの詳細が含まれます。詳細については、「 Application Load Balancer の接続ログ 」を参照してください。 ALB の mTLS サポートに関する CloudWatch メトリクスの完全なリストは、「 Application Load Balancer の CloudWatch メトリクス 」で確認できます。 ALB の mTLS モードと Network Load Balancer (NLB) の比較 HTTPS アプリケーションをお持ちの場合、アプリケーションレベルのルーティングを行いたい場合は、ALB の検討をお勧めします。例えば、HTTPS リクエストに対して重み付きラウンドロビンの負荷分散を実行することで、ブルー/グリーンのようなデプロイメントを作成できます。ALB を使用すると、TLS/mTLS 操作をオフロードすることもできます。ただし、ALB がクライアントの TLS セッションを終了するため、ALB 用の証明書をアップロードする必要があります。 一方、NLB はトランスポート層 (OSIモデルのレイヤー4) で動作し、TCP/UDP コネクションの低レイテンシー負荷分散を提供します。HTTPS アプリケーションの場合、特定のセキュリティコンプライアンスルールによりサーバーがクライアントのTLS 接続を終了する必要がある場合は、Network Load Balancer (NLB) の使用をお勧めします。 表1は、ALB と NLB のパススルーモードと検証モードのサポートを比較し、各オプションの考慮事項を示しています。 &nbsp; ALB + mTLS検証モード ALB + mTLS パススルーモード NLB クライアント認証 ALB で実行、AWS が管理 バックエンドターゲットで実行、お客様が管理 バックエンドターゲットで実行、お客様が管理 クライアントのSSL/TLSセッション終了 ALB で実行、AWS が管理 ALB で実行、AWS が管理 バックエンドターゲットで実行、お客様が管理 ルーティングルール機能 ALB のL7 ルーティングルール ALB のL7 ルーティングルール NLB のポートとプロトコルによるルーティングルール Conclusion この投稿では、Application Load Balancer (ALB) の mTLS 検証モードとパススルーモードについて説明し、各モードを使用する際の考慮事項を議論しました。クライアント認証に ALB を使用したい場合は、ALB で mTLS 検証モードを使用します。バックエンドターゲットでクライアント認証を制御したい場合は、mTLS パススルーモードが最適です。トラストストアを使用するには追加料金がかかり、mTLS を有効にする際には Application Load Balancer の価格を考慮する必要があります。詳細については、 Elastic Load Balancing の価格ページ をご覧ください。 この機能は 2023年11月26日にリリースされましたので、ぜひお試しいただき、ご質問やコメントがあれば、 AWS サポート までお問い合わせください。 本記事は、 Introducing mTLS for Application Load Balancer を翻訳したものです。翻訳は Solutions Architect の 中本 が担当しました。

本ブログは 2023 年 9 月 28 日に公開されたBlog ” How AWS threat intelligence deters threat actors ” を翻訳したものです。 Amazon Web Services (AWS) のクラウドインフラストラクチャ全体で、私たちは毎日、混乱や損害を引き起こす可能性のある何百ものサイバー攻撃を検知し、成功裏に阻止しています。これらの重要ではあるものの、ほとんど表に出ない成果は、グローバルなセンサーネットワークと、それに関連する一連の防御ツールによって達成されています。これらの機能を使用することで、私たちのネットワーク、インフラストラクチャ、そしてお客様に対するサイバー攻撃の実行をより困難かつコストも高くなるようにしています。さらに、他の責任ある事業者と協力して、彼らのインフラストラクチャ内で活動する脅威アクター(攻撃者)に対して行動を起こすことで、インターネット全体をより安全な場所にすることにも貢献しています。クローバル規模の脅威インテリジェンスを迅速な行動に変えることは、セキュリティを最優先事項とする私たちのコミットメントの一環として行っている多くのステップの 1 つに過ぎません。これは終わりのない取り組みであり、私たちの能力は常に向上していますが、私たちは今、お客様やその他の利害関係者に現在行っていることと将来の方向性について知っていただくべき時期に来たと考えています。 AWS クラウドを使用したグローバル規模の脅威インテリジェンス AWS は、クラウドプロバイダーの中で最大のパブリッククラウドのネットワーク規模を持ち、その規模により、インターネット上の特定の活動について比類のない洞察や知見を得ることができます。数年前、AWS のプリンシパルセキュリティエンジニアである Nima Sharifi Mehr は、その規模を活かし、脅威に対抗するための情報収集に新たな手法を模索し始めました。これを受けて、私たちのチームは MadPot と呼ばれる社内ツールスイートの構築を開始しました。その結果、Amazon のセキュリティ研究者たちは、お客様に悪影響を与える可能性のある何千ものサイバー脅威を発見し、研究し、阻止することに成功しました。 MadPot は 2 つの目的を達成するために構築されました。1 つ目は、脅威活動の発見と監視、2 つ目は、AWS のお客様やその他の人々を保護するために、可能な限り有害な活動を阻止することです。MadPot は、洗練された監視センサーシステムと自動対応機能に成長しました。これらのセンサーは、世界中で毎日 1 億件以上の潜在的な脅威の相互作用とプローブ(探査)を観察し、そのうち約 50 万件の観察された活動が悪意のあるものとして分類されるレベルに達します。この膨大な脅威インテリジェンスデータは取り込まれ、相関付けられ、分析されて、インターネット全体で発生している潜在的に有害な活動に関する実行可能な洞察を提供します。自動対応機能は、特定された脅威から AWS ネットワークを自動的に保護し、インフラストラクチャが悪意のある活動に使用されている他の企業に対して連絡用のコミュニケーションを開始します。 このような種類のシステムは ハニーポット として知られています。これは脅威アクターの行動を捕捉するための囮（おとり）システムであり、長年にわたって貴重な観察と脅威インテリジェンスのツールとして機能してきました。しかし、MadPot を通じて私たちが取るアプローチは、AWS のスケールとシステムの背後にある自動化によって、独自の洞察を得ることができます。脅威アクターを引き付け、その行動を観察して対処できるようにするため、私たちはこの膨大なシステムを正当で無害に見えるターゲットで構成されているように設計しました。管理された安全な環境で実システムを模倣することで得られる観察結果や洞察は、多くの場合即座に活用でき、有害な活動の阻止やお客様の保護に役立ちます。 もちろん、脅威アクターはこのようなシステムが存在することを知っているため、彼らは頻繁に戦術を変更します。そして、私たちも常に対策を更新しています。MadPot が常に動作を変化させ進化し続け、悪意のある行為者の戦術、技術、手順 (TTP) を明らかにする活動への可視性を維持できるよう、多大なリソースを投入しています。この情報を AWS Shield や AWS WAF などの AWS ツールで迅速に活用し、自動対応を開始することで、多くの脅威を早期に軽減しています。また、適切な場合には、 Amazon GuardDuty を通じて脅威データをお客様に提供し、お客様が独自のツールや自動化プロセスで対応できるようにしています。 攻撃の試みまで 3 分、無駄にする時間はない MadPot によるシミュレートされたワークロード内で新しいセンサーを起動してから約 90 秒以内に、インターネットをスキャンするプローブによってワークロードが発見されるのを観察できます。そこから平均してわずか 3 分で、侵入や攻撃の試みが行われます。これらのワークロードが公開されておらず、脅威アクターにとって目立つような他のシステムの一部でもないことを考えると、この時間の短さは驚くべきものです。これは、スキャンが行われている激しさと、脅威アクターが次のターゲットを見つけるために採用している高度な自動化を明確に示しています。 これらの試行が進行するにつれて、MadPot システムは脅威アクターの行動に関するテレメトリ、コード、試行されたネットワーク接続、その他の重要なデータポイントを分析します。脅威アクターの活動を集約して、利用可能なインテリジェンスのより完全な全体像を生成すると、この情報はさらに価値が高まります。 攻撃を阻止して業務の継続性を確保する MadPot では、詳細な脅威インテリジェンス分析も実施されます。システムは捕捉したマルウェアをサンドボックス環境で起動し、異なる手法から得られた情報を脅威パターンに結びつけます。収集されたシグナルから十分な確信が得られる場合、システムは可能な限り脅威を阻止するための行動を取ります。例えば、脅威アクターのリソースを AWS ネットワークから切断するなどの対応を取ります。あるいは、特定された脅威の阻止に協力してもらうため、コンピュータ緊急対応チーム (CERT)、インターネットサービスプロバイダー (ISP)、ドメインレジストラ、政府機関などのより広いコミュニティと共有する情報を準備することもあります。 インターネット業界の主要企業として、AWS は可能な限りセキュリティコミュニティを支援し、協力する責任を負っています。セキュリティコミュニティ内での情報共有は長年続く慣例であり、私たちは何年にもわたってこの取り組みに積極的に関与してきました。 2023 年第 1 四半期： ボットネット対策のセキュリティ活動において、インターネット脅威センサーから 55 億シグナル、アクティブネットワークプローブから 15 億シグナルを収集・使用しました。 130 万件以上のボットネットから発信された DDoS 攻撃を阻止しました。 約 1000 台のボットネット C2 ホストを含むセキュリティインテリジェンスの調査結果を、関連するホスティングプロバイダーやドメインレジストラと共有しました。 23 万件の L7/HTTP(S) DDoS 攻撃の発信源を追跡し、外部の関係者と協力してその解体に取り組みました。 MadPot の有効性を示す 3 つの例：ボットネット、Sandworm、Volt Typhoon 最近、MadPot は不審なシグナルを検出、収集、分析しました。その結果、 free.bigbots.[tld] (トップレベルドメインは省略) というドメインをコマンド＆コントロール (C2) ドメインとして使用する分散型サービス拒否 (DDoS) ボットネットを発見しました。ボットネットは、無関係な第三者に属する侵害されたシステム (コンピューター、ホームルーター、IoT デバイスなど) で構成されており、これらのシステムは既に侵害されており、ターゲットに大量のネットワークパケットを送信するコマンドを待機するマルウェアがインストールされています。この C2 ドメイン下のボットは、1 時間あたり 15 ～ 20 件の DDoS 攻撃を、約 8 億パケット/秒の速度で実行していました。 MadPot がこの脅威を追跡する中で、私たちのインテリジェンスにより、ボットからの非常に多数のリクエストに対応する C2 サーバーが使用する IP アドレスのリストが明らかになりました。私たちのシステムは、AWS ネットワークへのアクセスからそれらの IP アドレスをブロックし、AWS 上の侵害されたお客様のコンピューティングノードが攻撃に参加できないようにしました。その後、AWS の自動化は収集した情報を使用して、C2 システムをホストしていた企業と DNS 名を管理していたレジストラに連絡しました。C2 をホストしていたインフラを所有する企業は 48 時間以内にそれらをオフラインにし、ドメインレジストラは 72 時間以内に DNS 名を廃止しました。DNS レコードを制御する能力を失った脅威アクターは、C2 をネットワーク上の別の場所に移動させてネットワークを容易に復活させることができなくなりました。3 日も経たないうちに、この広く分散したマルウェアとその運用に必要な C2 インフラは機能停止に追い込まれました。その結果、インターネット全体のシステムに影響を与えていた DDoS 攻撃は停止しました。 MadPot は、クラウドインフラだけでなく、さまざまな種類のインフラを標的とする脅威アクターを検出し理解するのに効果的です。これには、マルウェア、ポート、使用される可能性のある手法も含まれます。そのため、MadPot を通じて、Sandworm と呼ばれる脅威グループを特定しました。これは、Cyclops Blink という、侵害されたルーターのボットネットを管理するために使用されるマルウェアに関連するクラスターです。Sandworm は、WatchGuard ネットワークセキュリティアプライアンスに影響を与える脆弱性を悪用しようとしていました。攻撃コード（ペイロード）を詳細に調査することで、IP アドレスだけでなく、AWS のお客様への侵害の試みに関与していた Sandworm の脅威に関連するその他のユニークな属性も特定しました。MadPot のさまざまなサービスを模倣し、詳細な相互作用を行う独自の能力により、脅威アクターが標的としているサービスや、このアクターによって開始された侵害後のコマンドなど、Sandworm キャンペーンに関する追加の詳細を捕捉することができました。この情報をお客様に通知し、お客様は迅速に脆弱性を緩和するための行動を取りました。この迅速な対応がなければ、このアクターはお客様のネットワークに足がかりを得て、お客様がサービスを提供している他の組織にアクセスできた可能性があります。 最後の例として、MadPot システムを使用して、政府のサイバーおよび法執行機関が Volt Typhoon を特定し、最終的に阻止することができました。Volt Typhoon は、重要インフラ組織に対するステルス的で標的型のサイバースパイ活動に重点を置いた、広く報道されている国家が支援する脅威アクターです。MadPot 内での調査を通じて、脅威アクターが提出したペイロードに固有のシグネチャが含まれていることを特定しました。これにより、一見無関係に見えていた Volt Typhoon の活動を識別し、特定することができました。MadPot でのやり取りの完全な履歴を保存するデータレイクを使用することで、何年分ものデータを非常に迅速に検索し、最終的にこの固有のシグネチャの他の例を特定することができました。このシグネチャは 2021 年 8 月にさかのぼってペイロードとして MadPot に送信されていました。以前のリクエストは一見無害な性質を持っていたため、偵察ツールに関連していると考えました。その後、脅威アクターが最近の数ヶ月間に使用していた他の IP アドレスを特定することができました。私たちは調査結果を政府当局と共有し、これらの通常は関連付けが困難な通信情報が、米国政府のサイバーセキュリティ・インフラセキュリティ庁 (CISA) の調査に役立ちました。私たちの作業と他の協力機関の作業により、2023 年 5 月の サイバーセキュリティアドバイザリー が発行されました。現在も、このアクターが米国のネットワークインフラストラクチャを探査し続けているのを観察しており、適切な政府のサイバーおよび法執行機関と詳細を共有し続けています。 AWS のお客様とより広範なユーザーを対象とした、グローバル規模の脅威インテリジェンスの活用 AWS では、セキュリティが最優先事項であり、セキュリティ問題がお客様のビジネスに混乱をもたらすことを防ぐために懸命に取り組んでいます。インフラストラクチャとお客様のデータを守るために、グローバル規模の洞察を活用し、大量のセキュリティインテリジェンスをリアルタイムで大規模に収集し、自動的にお客様を保護するのに役立てています。可能な限り、AWS Security とそのシステムは、最も効果的な場所で脅威を阻止します。多くの場合、この作業は主に舞台裏で行われています。先に説明したボットネットの事例で示したように、グローバル規模の脅威インテリジェンスを活用し、悪意のある活動の直接的な影響を受ける組織や関係者と協力して、脅威を無効化しています。我々は MadPot からの脅威検出結果を AWS セキュリティツールに組み込んでいます。これには、 AWS WAF 、 AWS Shield 、 AWS Network Firewall 、 Amazon Route 53 Resolver DNS Firewall などの予防サービスや、 Amazon GuardDuty 、 AWS Security Hub 、 Amazon Inspector などの検出・対応サービスが含まれます。適切な場合には、セキュリティインテリジェンスを直接お客様の手に届けることで、お客様が独自の対応手順や自動化を構築できるようにしています。 しかし、私たちの取り組みは、AWS 自体の境界をはるかに超えて、セキュリティ保護と改善を拡大しています。世界中のセキュリティコミュニティや協力企業と密接に連携し、脅威アクターの特定と排除に取り組んでいます。今年の上半期には、ボットネットの制御インフラを停止するため、関連するホスティングプロバイダーやドメインレジストラと、約 2,000 のボットネットの指令サーバーに関する情報を共有しました。また、約 230,000 件のレイヤー 7 DDoS 攻撃の発信源を追跡し、外部の関係者と協力して解体しました。私たちの防御戦略の有効性は、脅威インテリジェンスを迅速に捕捉、分析、行動に移す能力に大きく依存しています。これらの措置を講じることで、AWS は一般的な DDoS 防御を超え、保護の範囲を AWS の境界を越えて拡大しています。 MadPot とその現在の機能について情報を共有できることを嬉しく思います。詳細については、AWS re:Inforce 2023 でのプレゼンテーション「 How AWS threat intelligence becomes managed firewall rules 」や、2023 年 9月 28 日に公開され概要を説明した「 サイバー犯罪からお客様を守るために Amazon が使用する脅威インテリジェンスツール MadPot のご紹介 」をご覧ください。この記事には、MadPot の元々の開発者である AWS セキュリティエンジニアに関する有益な情報も含まれています。今後、脅威インテリジェンスと対応システムの開発・強化を進めるにつれて、私たちからさらに多くの情報を発信していく予定です。これにより、AWS とインターネット全体をより安全な場所にすることを目指しています。 この投稿に関するフィードバックがある場合は、以下の コメント セクションにコメントを投稿してください。この投稿に関する質問がある場合は、 AWS サポートにお問い合わせ ください。 AWS セキュリティに関するニュースをもっと知りたいですか？ X でフォローしてください。 Mark Ryland Mark はバージニア州を拠点とする Amazon のセキュリティ部門のディレクターです。テクノロジー業界で 30 年以上の経験を持ち、サイバーセキュリティ、ソフトウェアエンジニアリング、分散システム、技術標準化、公共政策の分野でリーダーシップを発揮してきました。AWS で 12 年以上のキャリアを持ち、最初は AWS ワールドワイドパブリックセクターチームのソリューションアーキテクチャおよびプロフェッショナルサービスのディレクターとして始め、最近では AWS CISO オフィスを設立してリードしています。 本ブログは Security Solutions Architect の中島 章博が翻訳しました。

本ブログは 2023 年 9 月 28 日に公開された Amazon News ” Meet MadPot, a threat intelligence tool Amazon uses to protect customers from cybercrime ” を翻訳したものです。 サイバー犯罪を阻止することは容易ではありませんが、Amazon は地道に自社の責務を果たし、優れた成果を上げています。 その秘密とは？ MadPot と呼ばれるあまり知られていないプロジェクトです。2010 年代後半に開始されたこの取り組みは、AWS の主要なクラウドサービスプロバイダーとしての規模を活用し、攻撃を企てる者を偽装されたデジタルターゲットに誘導して、彼らの手法を研究し、対策を講じるために役立てられています。 導入以来、この技術は Amazon の絶えず進化するサイバーセキュリティ戦略の重要な要素となり、企業、政府、そしてインターネットに多大な恩恵をもたらし続けています。 例えば 2022 年 5 月、 Volt Typhoon と呼ばれる国家が支援するハッカー集団が米国の重要インフラ全体にスパイウェアを仕掛けたとされた際、MadPot により、Amazon がこの脅威についてより詳しく分析し、どのような影響があるかの詳細情報を提供しました。これにより Amazon は、攻撃の影響を受けた顧客に警告を発し、犯罪者を調査する連邦機関に貴重な情報を提供することができました。 同様の活用例では、ロシアに関連するハッキンググループ Sandworm は、あるセキュリティアプライアンスへの脆弱性を悪用しようとしましたが、実際にはそれは MadPot でした。MadPot から得られた情報を活用して、Amazon はこのグループの IP アドレスやその他の特徴的なシグネチャに関する情報を捕捉し、ある顧客がハッキンググループの標的になっていることを発見しました。そして、被害を回避するのに間に合うよう、その顧客にこの脅威を警告することができました。 MadPot の仕組み MadPot は、ネットワークセンサーから収集した脅威インテリジェンスと、Amazon Web Services (AWS) のネットワーク制御および他のインターネット関連事業者との協力による脅威の阻止を活用して、これらすべてを行っています。 脅威インテリジェンス機能は、何万もの脅威センサーによって支えられており、これらのセンサーは一般に「 ハニーポット 」として知られる同社のデジタルおとりに対する 1 日 1 億回以上の接続試行を監視しています。これらの相互作用を通じて収集されたすべてのデータにより、Amazon は脅威状況に関する幅広い理解を深め、そのクラウドインフラストラクチャの強化に活用しています。 脅威阻止システムは、データ分析手法とインテリジェンス抽出技術（ネットワークプローブなど）を組み合わせて活用し、MadPot のデータを洞察に変換します。これらの洞察は、自動化システムや IT セキュリティ担当者 (人間の判断が必要な場合) が脅威を無効化するために使用できます。結果によっては、 Amazon GuardDuty 、 AWS Shield 、 AWS WAF などのセキュリティサービスの更新もします。また、 Amazon Inspector の Vulnerability intelligence (脆弱性インテリジェンス) にも情報を提供します。さらに、MadPot は悪意のある活動に関与していることが判明したユーザをブロックまたは取り除くように、インターネットサービスプロバイダーやホスティング事業者に自動的にリクエストを送信することも頻繁に行っています。 「このシステムを運用することで、実質的にインターネット全体をより安全にしています」と Amazon Security のディレクター、Mark Ryland は述べています。「MadPot の検出能力と防御能力により、お客様に潜在的な脅威を警告し、多くの場合サイバー犯罪者の動きを阻止するという強力な二段構えの対策が可能になります。」 インターネット全体を保護する MadPot は、 AWS のプリンシパルセキュリティエンジニアである Nima Sharifi Mehr の発案から生まれました。世界中でデータ侵害が急増する中、彼はサイバー脅威に対抗するための情報収集に新しいアプローチを探し始め、デジタルおとりのアイデアをテストし始めました。わずか数ヶ月で、Amazon のセキュリティ研究者たちは、顧客に影響を及ぼす可能性のあった何千ものサイバー脅威を発見し、研究し、阻止することに成功しました。 現在、MadPot は Amazon のサイバーセキュリティ戦略の柱となっており、社内の各チームがこれを活用して世界中のお客様やパートナーを保護すると同時に、グローバルなサイバーセキュリティの基準を引き上げています。 「PadPotは、Amazon 全体で脅威インテリジェンスとマルウェアの検体を収集するための主要な情報源となりました」と Sharifi Mehr は述べました。「Amazonの巨大なグローバルインフラストラクチャ全体にデプロイすることで、私たちのシステム、およびセキュリティ確保のために当社を信頼している何億人ものお客様を保護について、可能性の限界を押し広げることができます。」 詳細は、 AWS 脅威インテリジェンスによる脅威アクターの阻止 をご参照ください。 本ブログは Security Solutions Architect の 中島 章博が翻訳しました

2024 年 8 月 29 日にクリエイティブなコンテンツ制作に関わるお客様向けに、クラウドを活用してクリエイティビティと作業効率を最適化する最新のサービスと情報をご紹介するセミナーを行いました。 AWSが推進するフルクラウドの制作環境の最新情報に加え、2024年4月にローンチした最新のレンダーマネージメントツールであるAWS Deadline Cloudの実際の使用方法も含めたご紹介と実際の作業環境の構築をご紹介。 合わせて、Deadline Cloudのユーザー事例として株式会社毎日放送様をお招きして、使い勝手や構築におけるチャレンジなどをお話しいただきました。 また、ゲストスピーカーとして株式会社ワコム様をお迎えして、リモート接続環境におけるペンタブレットの描き味を改善する最新のソリューションであるWacom Bridgeをご紹介頂きました。 セミナーのアジェンダ: アマゾンウェブサービス (AWS) ジャパン : クラウド上でのコンテンツ制作環境の現状 アマゾンウェブサービス (AWS) ジャパン : Deadline Cloudのご紹介 株式会社毎日放送 様 : Deadline Cloudの本番運用に向けての検証 株式会社ワコム 様 : Wacom Bridgeのご紹介 クラウド上でのコンテンツ制作環境の現状 アマゾン ウェブ サービス ジャパン合同会社 WWSO Advanced Compute 事業本部 Visual Compute担当シニアスペシャリスト 　菊地 蓮 [ 資料 ] クラウド上でのコンテンツ制作環境におけるAWSのコミットメントと最新の事例についてご紹介します。 Deadline Cloudのご紹介 アマゾン ウェブ サービス ジャパン合同会社　WWSO Advanced Compute 事業本部 Visual Compute担当シニアソリューションズアーキテクト 　森 大樹 [ 資料 ] AWSのレンダーマネージメントサービスであるDeadline Cloudのご紹介と実際の構築の流れを解説します。 Deadline Cloudの本番運用に向けての検証 株式会社毎日放送 総合技術局 制作技術センター　村井 亨 様 [ 資料 ] 現在、毎日放送ではAWS Thinkbox Deadline 10 を運用していますがDeadline Cloud を利用することで、フルマネージドでより簡単に環境を構築できるようになりました。今年度中の本番運用を目指し、テストを開始しました。現時点での検証結果をご報告します。 Wacom Bridgeのご紹介 株式会社ワコム ブランドビジネス ポートフォリオマネジメント サービス マネージャー 　淺田 一 様 [ 資料 ] クラウドで動作するリモートマシン上でのペンタブレットの使い心地を飛躍的に向上させる新たなテクノロジーソリューションである、Wacom Bridgeをご紹介頂きます。また、ペンタブレットを現在業務に使用されているアーティストの方にWacom Bridgeを使って頂き、使用感についてインタビュー形式にて語って頂きます。 おわりに 本ブログでは、2024 年 8 月 29 日に開催されたコンテンツ制作を行われているお客様向けに開催したセミナーの内容について紹介させて頂きました。 今回セミナーに参加いただいた皆さま誠にありがとうございました。引き続き業界の皆様に役立つ情報を、セミナーやブログで発信していきます。どうぞよろしくお願い致します。 参考リンク AWS Media Services AWS Media &amp; Entertainment Blog　(日本語) AWS Media &amp; Entertainment Blog　(英語) AWSのメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 このブログは BD 菊地が担当いたしました。

この記事は Amazon DataZone introduces OpenLineage-compatible data lineage visualization in preview を翻訳したものです。 Amazon DataZone で OpenLineage 互換の API を使用したデータリネージ機能のプレビュー版 の提供を開始したことをお知らせできることを嬉しく思います。この機能により、 Amazon DataZone 上のデータアセットのリネージ (データの流れや変遷) のキャプチャ、保存、そして可視化が可能になります。 Amazon DataZone の OpenLineage 互換 API により、ドメイン管理者やデータプロデューサー (データ提供者) は、より広範囲のリネージイベントをキャプチャして保存できるようになりました。Amazon DataZone 内の情報に加え、 Amazon Simple Storage Service (Amazon S3)、 AWS Glue 、およびその他の AWS サービスで行った変換も含めることができます。これにより、Amazon DataZone を閲覧するデータコンシューマー (データ利用者) はデータアセットの出所を確認することができ、データプロデューサーはデータアセットの使用状況を把握することで変更の影響を評価できるようになります。 この記事では、Amazon DataZone のデータリネージの最新機能、OpenLineage との互換性、そして AWS Glue、 Amazon Redshift 、 Amazon Managed Workflows for Apache Airflow (Amazon MWAA) など、他のサービスから API を通じて Amazon DataZone にリネージを取り込む方法について説明します。 データリネージの重要性 データリネージによって、データアセットの全体像を把握し、オブジェクトの出所とその関連性の連鎖を確認できるようになります。データリネージがあれば時間の経過に伴うデータの変遷を追跡でき、データの出所、変更履歴、そしてデータパイプライン内での最終的な行き先を明確に理解できるようになります。データの出所が透明化されることで、データコンシューマーはそのデータが自分たちの用途に適しているかどうかを的確に判断できるようになります。データリネージはテーブル、カラム、ジョブなどの情報を含むため、影響分析やデータに関する問題への対処が可能になります。例えば、ある項目が下流のソースコードにどのような影響を与えるかを確認できます。このようにして、変更をコミットする前に十分な情報に基づいて判断を下し、下流で望ましくない変更が発生するのを回避できます。 Amazon DataZone のデータリネージは、 API として提供される OpenLineage 互換の機能です。これにより、OpenLineage 対応システムや API からリネージイベントをキャプチャし、可視化できます。さらに、データの出所や変換を追跡し、組織間におけるデータの利用状況を的確に把握できるようになります。Amazon DataZone のビジネスデータカタログ内のアクティビティは、リネージとして可視化されます。また、カタログ化されたアセットだけでなく、ビジネスデータカタログの外で発生したアクティビティも、API を使用してプログラム的にキャプチャします。これにより、データの流れと利用状況を包括的に理解できるようになります。 さらに、Amazon DataZone はイベントごとにリネージのバージョン管理を行い、いつでも必要なときにリネージを可視化したり、アセットやジョブの履歴全体で変遷を比較することができます。過去のリネージを確認することで、データがどのように進化してきたかを深く理解できるため、トラブルシューティング、監査、およびデータアセットの整合性の確保に欠かせない機能だといえます。 次のスクリーンショットは、Amazon DataZone のデータカタログで可視化されたリネージグラフの例を示しています。 OpenLineage 互換のデータリネージ機能の概要 さまざまなアナリティクスサービスにわたってデータリネージを一貫してキャプチャし、それらを統一されたオブジェクトモデルに組み込むことが、リネージ情報から洞察を得るための重要な要素となります。 OpenLineage は、リネージを収集および分析するためのフレームワークを提供するオープンソースプロジェクトです。また、メタデータを記録するためのオブジェクトモデルのリファレンス実装と、主要なデータアナリティクスツールとの統合機能も提供しています。 OpenLineage における主要な概念を以下に挙げます。 リネージイベント (Lineage event) – OpenLineage は一連のイベントを通してデータのリネージ情報をキャプチャします。 イベント とは、データパイプラインにおいてデータの取り込み、変換、利用などの特定の操作を表すものです。 リネージエンティティ (Lineage entity) – OpenLineage における エンティティ は、データセットやテーブルなど、リネージプロセスに関わるさまざまなデータオブジェクトを表します。 リネージ実行 (Lineage run) &nbsp;– リネージ実行 は、データパイプラインやジョブの実行を表す概念であり、複数のリネージイベントとエンティティから構成されます。 リネージ形式 (Lineage form type) – 形式または ファセット (データの分類や検索に用いる属性情報) は、リネージエンティティやイベントに関する追加のメタデータやコンテキスト情報を提供し、より豊かで記述的なリネージ情報を実現します。OpenLineage はラン、ジョブ、データセットのファセットを提供しており、カスタムファセットを構築することも可能です。 Amazon DataZone のデータリネージ API は OpenLineage 互換であり、OpenLineage の機能を拡張しています。具体的には、リネージ情報を柔軟に拡張可能なデータ構造 (オブジェクトモデル) に保存するためのエンドポイントを提供しています。 OpenLineage は特定のデータソースとの統合機能 も提供しています。Amazon DataZone はこれらのデータソースとの統合を簡単に行うことができます。Amazon DataZone のデータリネージ API がこれらのフォーマットを解釈し、リネージのデータモデルに変換するためです。 次の図は、Amazon DataZone のリネージデータモデルの例を示しています。 Amazon DataZone では、すべてのリネージノードが実際のリソースを表しています。つまり、リネージノードとテーブル、ビュー、アセットなどの論理的または物理的リソースとの間に 1 対 1 のマッピングがあるということです。ノードは特定のジョブの特定の実行を表すか、テーブルやアセットのノードやサブスクライブしたアセットのノードを表します。 ノードの各バージョンは、タイムスタンプで実際のリソースに何が起きたのかを管理しています。Amazon DataZone のリネージは、外部で発生したデータ移動の変遷を共有するだけでなく、Amazon DataZone 内でのアセット作成、キュレーション (メタデータの整備) 、公開、サブスクリプションなどのアクティビティによるリネージも表します。 Amazon DataZone でデータリネージのモデルを構築するには、2 種類のデータリネージを取得する必要があります。 Amazon DataZone 内のリネージアクティビティ – これには、カタログに追加され公開されたアセットが含まれ、その後サブスクリプションの詳細が自動的に取得されます。プロデューサープロジェクトの視点 (例えば、選択したプロジェクトがブラウジング中のアセットの所有プロジェクトであり、そのプロジェクトのメンバーである場合) では、データセットノードの 2 つの状態が表示されます。 インベントリアセットタイプのノードは、未公開の段階にあるカタログ内のアセットを定義します。他のプロジェクトのメンバーはインベントリアセットをサブスクライブできません。詳細については、 Amazon DataZone でのインベントリデータの作成とデータの公開 を参照してください。 公開済みアセットタイプのノードは、組織全体のデータユーザーが利用可能な実際のアセットを表します。これは、他のプロジェクトのメンバーがサブスクライブできるアセットタイプです。そのアセットのプロデューサープロジェクト以外のコンシューマーの視点では、公開済みアセットノードのみが表示されます。 Amazon DataZone の外部で発生したリネージアクティビティは、 PostLineageEvent を使用することでそのプログラムから取得できます。カタログ化されたアセットのデータ処理の前後でこれらのイベントを取得することで、データプロデューサーとデータコンシューマーはデータの移動を包括的に把握し、データの出所またはその消費を確認できます。この記事の後半で、リネージイベントを連携するための API の使用方法について説明します。 Amazon DataZone には 2 種類のリネージノードが用意されています: データセットノード (Dataset node) – Amazon DataZone では、リネージの可視化機能ではテーブルやビューを表すノードを表示します。プロジェクトの視点によって表示される内容は異なり、プロデューサーはインベントリと公開済みアセットの両方を表示できますが、コンシューマーは公開済みアセットしか表示できません。アセット詳細ページのリネージタブを最初に開くと、カタログ化されたデータセットノードがリネージグラフの上流または下流の探索の開始点になります。データセットノードには、Amazon DataZone から自動で生成されるリネージノードと、独自に作成するリネージノードがあります。 自動生成データセットノード (Automated dataset node) – これらのノードには、Amazon DataZone カタログに公開された AWS Glue または Amazon Redshift アセットに関する情報が含まれています。自動的に生成され、ノード内に対応する AWS Glue または Amazon Redshift のアイコンが含まれています。 カスタムデータセットノード (Custom dataset node) &nbsp;– これらのノードには、Amazon DataZone カタログに公開されていないアセットに関する情報が含まれています。ドメイン管理者 (プロデューサー) が手動で作成し、ノード内にはカスタムアセットアイコンが表示されます。これらは、OpenLineage イベント形式を使用して作成されたカスタムリネージノードです。 ジョブノード / ジョブ実行ノード (Job node / Job run node) &nbsp;– このノードは、特定のジョブの最新の実行とその実行の詳細を表すジョブの詳細をキャプチャします。このノードは、そのジョブの複数の実行もキャプチャでき、ノード詳細の History &nbsp;タブで表示できます。ノードの詳細はアイコンを選択すると表示されます。 Amazon DataZone でのデータリネージの可視化 Amazon DataZone は、データプロデューサーとデータコンシューマー向けに統合的な操作環境を提供します。アセット詳細ページではリネージの情報がグラフで表示されており、上流または下流のデータ間の関係を容易に把握できます。アセット詳細ページにはグラフをナビゲートするための次の機能があります。 カラムレベルのリネージ – データセットノードで利用可能な場合、カラムレベルのリネージを展開できます。これにより、データソースのカラム情報が利用可能であれば、上流または下流のデータセットノードとの関係が表示されます。 カラム検索 – データセットに 10 個以上のカラムがある場合、ノードには最初に表示されないカラムに移動するためのページ送りが表示されます。データセットノードには検索機能があり、この機能を使うと検索結果には該当するカラムだけが表示され、探したいカラムをすぐに見つけることができます。 データセットノードのみを表示 – ジョブノードを除外したい場合は、グラフビューアーの Open view control のアイコンを選択し、 Display dataset nodes only の設定を切り替えます。これにより、グラフからすべてのジョブノードが表示されなくなり、データセットノードのみを移動できるようになります。 詳細ペイン – 各リネージノードは次の詳細をキャプチャして表示します。 すべてのデータセットノードには、 Lineage info、Schema、 History の 3 つのタブがあります。 History タブには、そのノードでキャプチャされたリネージイベントのバージョンが一覧表示されます。 ジョブノードには、 Job info と History のタブを持つ詳細ペインがあり、ジョブの詳細が表示されます。詳細ペインにはジョブの一部として実行されたクエリや式もキャプチャされます。 バージョンタブ – Amazon DataZone データリネージのすべてのノードには、キャプチャされたリネージイベントに基づく履歴としてバージョン管理が行われます。選択したタイムスタンプでリネージを表示すると、リネージページに新しいタブが開き、異なるタイムスタンプ間で比較できます。 次のスクリーンショットはデータリネージの可視化の例を示しています。 Lineage タブで Preview を選択し、 Try sample lineage リンクを選択すると、サンプルデータでどのように可視化されるかを体験できます。新しいブラウザタブが開き、ガイドツアーを利用するかどうかに関わらず、サンプルデータを使ってこの機能をテストして使い方を学ぶことができます。次のスクリーンショットはサンプルデータのリネージを表示した例です。 ソリューションの概要 ここまでは Amazon DataZone の新しいデータリネージ機能を説明しました。次は AWS Glue のテーブルと ETL (抽出、変換、ロード) ジョブ、Amazon Redshift、そして Amazon MWAA からリネージ情報をキャプチャする方法を見ていきましょう。 スタートアップスクリプトは Amazon DataZone の新しい GitHub リポジトリ でも入手できます。 前提条件 このウォークスルーを行うには、以下の前提条件を満たしている必要があります: 1 つの AWS アカウント AWS Identity and Access Management (IAM) ユーザーで、以下のサービスへのアクセス権限があること: AWS Cloud9 AWS CloudFormation AWS CloudShell Amazon DataZone AWS Glue Amazon S3 1 つの Amazon DataZone ドメイン データレイクの環境が作成された 1 つの Amazon DataZone プロジェクト この記事の手順を実行する AWS アカウントで AWS Lake Formation を使用して AWS Glue Data Catalog の権限を管理している場合は、データベースとテーブルを作成する権限を持つユーザーとしてログインしてください。詳細については、 Lake Formation の暗黙的なアクセス許可 を参照してください。 CloudFormation スタックの起動 このユースケースのリソースを AWS CloudFormation で作成するには、以下の手順を実行してください: CloudFormation スタックを us-east-1 でデプロイします: Stack name には、スタックの名前を入力します。 Next を選択します。 I acknowledge that AWS CloudFormation might create IAM resources with custom を選択します 。 Create stack を選択します。 スタックの作成とリソースのプロビジョニングが完了するのを待ちます。 CREATE_COMPLETE ステータスが表示されれば次のステップに進めます。 AWS Glue テーブルからのデータリネージのキャプチャ この例では、AWS Glue テーブルからリネージメタデータを収集するために必要なコマンドを実行するため、ブラウザベースのシェルである CloudShell を使用します。以下の手順を実行してください。 AWS Glue コンソールで、ナビゲーションペインから Crawlers を選択します。 CloudFormation テンプレートによって作成されたクローラー AWSomeRetailCrawler を選択します。 Run を選択します。 クローラーの実行が完了すると、 Succeeded ステータスが表示されます。 では、CloudShell を使用してリネージのメタデータを収集しましょう。 extract_glue_crawler_lineage.py ファイルをダウンロードします。 Amazon DataZone コンソールで CloudShell を開きます。 Actions メニューから、 Update file を選択します。 extract_glue_crawler_lineage.py ファイルをアップロードします。 次のコマンドを実行します: sudo yum -y install python3 python3 -m venv env . env/bin/activate pip install boto3 次のような結果が得られるはずです。 すべてのライブラリと依存関係が構成されたら、次のコマンドを実行して inventory テーブルからリネージのメタデータを収集します。なお、 dzd_Your_domain は自身の DataZone ドメイン ID に置き換えます: python extract_glue_crawler_lineage.py -d awsome_retail_db -t inventory -r us-east-1 -i dzd_Your_domain スクリプトは設定情報の確認を求めてきます。 yes と入力します。 スクリプトが正常に実行されたことを示す通知が表示されるはずです。 Inventory テーブルからリネージ情報をキャプチャした後、データソースジョブを実行するには、以下の手順を行います。 Amazon DataZone データポータルで、 Sales を開きます。 ナビゲーションペインで Data &nbsp;タブを選択し、 Data sources を選択します。 データソースジョブを選択し、 Run を選択します。 この例では、 awsome_retail_db データベースを指すデータソースジョブ SalesDLDataSourceV2 がすでに作成されていました。データソースジョブの作成方法の詳細については、 AWS Glue Data Catalog の Amazon DataZone データソースを作成して実行する を参照してください。 ジョブが正常に実行されると、確認メッセージが表示されます。 Amazon DataZone によって生成されたリネージグラフを見てみましょう。 Data inventory タブで Inventory テーブルを選択します。 Inventory アセットページで新しく追加されている Lineage タブを選択します。 Lineage タブでは、Amazon DataZone が 3 つのノードを作成したことがわかります。 Job / Job run – アセットのテクニカルメタデータを収集するために使用される AWS Glue クローラーを表しています Dataset – このアセットに関連するデータを含む S3 オブジェクトを表しています Table – クローラーによって作成された AWS Glue テーブルを表しています Dataset ノードを選択すると、Amazon DataZone はアセットを作成するために使用された S3 オブジェクトに関する情報を提供します。 AWS Glue ETL ジョブからのデータリネージのキャプチャ 前のセクションでは、データアセットのデータリネージグラフを生成する方法について説明しました。次に、AWS Glue ジョブのデータリネージグラフを作成する方法を見ていきましょう。 先ほど起動した CloudFormation テンプレートは、 Inventory_Insights という名前の AWS Glue ジョブを作成しました。このジョブは Inventory テーブルからデータを取得し、すべての店舗で利用可能な製品の合計データを集計した新しい Inventory_Insights テーブルを作成します。 CloudFormation テンプレートは、この記事用に作成された S3 バケットに openlineage-spark_2.12-1.9.1.jar ファイルもコピーしています。このファイルは、AWS Glue ジョブからリネージメタデータを生成するために必要です。この OpenLineage Spark プラグインは、 AWS Glue 3.0 (この記事の AWS Glue ジョブ作成に使用したバージョン) と互換性のある 1.9.1 バージョンを使用しています。異なるバージョンの AWS Glue を使用している場合は、 OpenLineage Spark プラグインファイル の対応するバージョンをダウンロードする必要があります。 OpenLineage Spark プラグインは、AWS Glue DynamicFrames を使用する AWS Glue Spark ジョブからデータリネージを抽出することができません。代わりに Spark SQL DataFrames を使用してください。 extract_glue_spark_lineage.py ファイルをダウンロードします。 Amazon DataZone コンソールで CloudShell を開きます。 Actions メニューから Update file を選択します。 extract_glue_spark_lineage.py ファイルをアップロードします。 CloudShell コンソールで、次のコマンドを実行します (CloudShell セッションの有効期限が切れている場合は新しいセッションを開きます)。 python extract_glue_spark_lineage.py --region "us-east-1" --domain-identifier 'dzd_Your Domain' スクリプトによって表示される情報を確認し、 yes と入力して確定します。 次のメッセージが表示されます。これは、スクリプトを実行した後で AWS Glue ジョブのリネージメタデータをキャプチャする準備ができたことを意味します。 Cloud formation テンプレートで作成した AWS Glue ジョブを実行します。 AWS Glue コンソールで、ナビゲーションペインから ETL jobs &nbsp;を選択します。 Inventory_Insights ジョブを選択し、 Run job &nbsp;を選択します。 Job details タブを見ると、このジョブには次の構成があることがわかります: キー --conf には以下の値が設定されています spark.extraListeners=io.openlineage.spark.agent.OpenLineageSparkListener --conf spark.openlineage.transport.type=console --conf spark.openlineage.facets.custom_environment_variables=[AWS_DEFAULT_REGION ; GLUE_VERSION ; GLUE_COMMAND_CRITERIA ; GLUE_PYTHON_VERSION ; ] キー --user-jars-first &nbsp;の値には true &nbsp;が設定されています Dependent JARs path は S3 のパスである&nbsp; s3://{your bucket}/lib/openlineage-spark_2.12-1.9.1.jar &nbsp;が設定されています AWS Glue のバージョンは 3.0 に設定されています ジョブの実行中、CloudShell コンソールに次の出力が表示されます。 これは、スクリプトが AWS Glue ジョブからリネージメタデータを正常に収集できたことを意味します。 AWS Glue ジョブによって作成されたデータをもとに AWS Glue テーブルを作成します。この例では、AWS Glue クローラーを使用します。 AWS Glue コンソールで、ナビゲーションペインから Crawlers を選択します。 CloudFormation テンプレートによって作成されたクローラー&nbsp; AWSomeRetailCrawler を選択し、 Run を選択します。 クローラーの実行が完了すると、次のメッセージが表示されます。 クローラーの実行が完了したら、次のコマンドを実行して inventory_insight テーブルからリネージのメタデータを収集します。 dzd_Your_domain は自分の DataZone ドメイン ID に置き換えてください: python extract_glue_crawler_lineage.py -d awsome_retail_db -t inventory_insight -r us-east-1 -i dzd_Your_domain Amazon DataZone ポータルを開き、Amazon DataZone でどのような図が表示されるか確認します。 Amazon DataZone ポータルで、 Sales プロジェクトを選択します。 Data タブで、ナビゲーションペインから Inventory data を選択します。 データソースジョブを再実行し、 inventory insights アセットを選択します。 Lineage タブでは、Amazon DataZone によって作成された図を確認できます。この図には 3 つのノードが表示されています。 AWS Glue テーブルを作成するために使用された AWS Glue クローラー クローラーによって作成された AWS Glue テーブル Amazon DataZone にカタログ化されたアセット 作成した inventory_insights テーブルを生成するために実行した AWS Glue ジョブのリネージ情報を確認するには、図の左側にある矢印アイコンを選択します。 そうすると、 Inventory_insights テーブルの完全なリネージグラフを確認できます。 図の左側のインベントリノードにある青い矢印アイコンを選択します。 カラムの変遷と、それらに加えられた変換を確認できます。 図中のノードを選択すると、その詳細を確認できます。例えば、 inventory_insights ノードには次の情報が表示されます。 Amazon Redshift からのデータリネージのキャプチャ Amazon Redshift からリネージグラフを生成する方法を見ていきましょう。この例では、Redshift クラスターが存在する仮想プライベートクラウド (VPC) への接続を構成できるため、AWS Cloud9 を使用します。AWS Cloud9 の詳細については、 AWS Cloud9 ユーザーガイド を参照してください。 この記事に含まれる CloudFormation テンプレートには、Redshift クラスターの作成やこのセクションで使用するテーブルの作成は含まれていません。Redshift クラスターの作成方法の詳細については、 ステップ 1: サンプルの Amazon Redshift クラスターを作成する を参照してください。このセクションで必要なテーブルを作成するには、次のクエリを使用します。 Create SCHEMA market create table market.retail_sales ( id BIGINT primary key, name character varying not null ); create table market.online_sales ( id BIGINT primary key, name character varying not null ); /* Important to insert some data in the table */ INSERT INTO market.retail_sales VALUES (123, 'item1') INSERT INTO market.online_sales VALUES (234, 'item2') create table market.sales AS Select id, name from market.retail_sales Union ALL Select id, name from market.online_sales ; Redshift クラスターへのアクセスを許可するセキュリティグループに AWS Cloud9 環境の IP アドレスを追加するのを忘れないようにしてください。 requirements.txt と extract_redshift_lineage.py ファイルをダウンロードします。 File &nbsp;メニューから Upload Local Files &nbsp;を選択します。 requirements.txt と extract_redshift_lineage.py ファイルをアップロードします。 次のコマンドを実行します: # Python をインストール sudo yum -y install python3 # 依存関係のセットアップ python3 -m venv env . env/bin/activate pip install -r requirements.txt 次のメッセージが表示されるはずです。 AWS 認証情報を設定するには、次のコマンドを実行します: export AWS_ACCESS_KEY_ID= &lt;&lt;Your Access Key&gt;&gt; export AWS_SECRET_ACCESS_KEY= &lt;&lt;Your Secret Access Key&gt;&gt; export AWS_SESSION_TOKEN= &lt;&lt;Your Session Token&gt;&gt; extract_redshift_lineage.py スクリプトを実行し、リネージグラフを生成するために必要なメタデータを収集します: python extract_redshift_lineage.py \ -r region \ -i dzd_your_dz_domain_id \ -n your-redshift-cluster-endpoint \ -t your-rs-port \ -d your-database \ -s the-starting-date 次に、Amazon DataZone データベースに接続するためのユーザー名とパスワードを入力します。 確認メッセージが表示されたら yes と入力します。 設定が正しく行われた場合、次の確認メッセージが表示されます。 では、Amazon DataZone でこの図がどのように作成されたかを見ていきましょう。 Amazon DataZone データポータルで、 Sales プロジェクトを開きます。 Data タブで、 Data sources を選択します。 データソースジョブを実行します。 この記事では、Amazon DataZone プロジェクトに Redshift データソースを追加するために、 Sales_DW_Enviroment-default-datasource という名前のデータソースジョブを作成済みです。データソースジョブの作成方法については、 Amazon Redshift の Amazon DataZone データソースを作成して実行する を参照してください。 ジョブを実行すると、次の確認メッセージが表示されます。 Data タブで、ナビゲーションペインから Inventory data を選択します。 total_sales アセットを選択します。 Lineage タブを選択します。 Amazon DataZone は Total Sales テーブルの 3 つのノードで構成されるリネージグラフを作成します。任意のノードを選択して詳細を確認できます。 Job/ Job run ノードの横にある矢印アイコンを選択すると、より詳細なリネージグラフを表示できます。 Job / Job run を選択します Job Info セクションには、合計売上テーブルを作成するために使用されたクエリが表示されます。 Amazon MWAA からのデータリネージのキャプチャ Apache Airflow はバッチ処理型のワークフローを開発、スケジューリング、そして監視するためのオープンソースプラットフォームです。Amazon MWAA は、最新の Airflow プラットフォームを使ってワークフローを管理できる Airflow の管理サービスです。OpenLineage は openlineage-airflow パッケージを使って Airflow 2.6.3 との統合をサポートしており、同様の機能を Amazon MWAA でプラグインとして有効にできます。有効にすると、このプラグインは Airflow のメタデータを OpenLineage イベントに変換し、 DataZone.PostLineageEvent で取り込めるようになります。 次の図は、OpenLineage を使用してデータリネージをキャプチャし Amazon DataZone に登録するにあたって、Amazon MWAA で必要な構成を示しています。 このワークフローでは、Amazon MWAA DAG を使用してデータパイプラインを呼び出します。プロセスは次のとおりです。 openlineage-airflow プラグインは、Amazon MWAA で リネージを行うためのバックエンド機能 &nbsp;として設定されています。DAG 実行に関するメタデータがプラグインに渡され、OpenLineage 形式に変換されます。 収集されたリネージ情報は、Amazon MWAA の環境に応じた&nbsp; Amazon CloudWatch のロググループに書き込まれます。 ヘルパー関数がログファイルからリネージ情報をキャプチャし、 PostLineageEvent API を使用して Amazon DataZone に登録します。 この記事で使用している例では、Amazon MWAA のバージョン 2.6.3 、そして OpenLineage プラグインのバージョン 1.4.1 を使用しています。OpenLineage がサポートする他の Airflow バージョンについては、 サポートされている Airflow バージョン を参照してください。 OpenLineage プラグインの Amazon MWAA への設定とリネージのキャプチャ OpenLineage を使用してリネージを収集する際は、 Transport 構成を設定する必要があります。これは、OpenLineage がイベントを出力する場所 (コンソールや HTTP エンドポイントなど) を指定します。 ConsoleTransport を使用すると、OpenLineage イベントが Amazon MWAA タスクの CloudWatch ロググループに記録され、ヘルパー関数を使って Amazon DataZone に登録できます。 Amazon MWAA で設定された S3 バケットに追加された requirements.txt ファイルに以下の内容を設定します: openlineage-airflow==1.4.1 Airflow 環境の MWAA 設定の Airflow logging configuration セクションで、ログレベル INFO で Airflow タスクログを有効にします。次のスクリーンショットはサンプルの設定を示しています。 正しく設定すれば Airflow にプラグインが追加されます。プラグインが追加されたかどうかは Airflow UI の Admin メニューから Plugins を選択することで確認できます。 この記事では、サンプルの DAG を使用して Redshift テーブルにデータを取り込みます。次のスクリーンショットは、グラフビューの DAG を示しています。 DAG を実行し、実行が正常に完了したら、Airflow 環境 ( airflow-env_name-task ) の Amazon MWAA タスク CloudWatch ロググループを開き、 console.py という式でフィルタリングして、OpenLineage から出力されたイベントを選択します。次のスクリーンショットは、その結果を示しています。 Amazon DataZone へのデータリネージの登録 CloudWatch にリネージイベントを出力できました。次のステップは、Amazon DataZone にそれらを登録し、データアセットに関連付けてビジネスデータカタログ上で可視化することです。 ファイル requirements.txt と airflow_cw_parse_log.py をダウンロードし、AWS リージョン、Amazon MWAA 環境名、Amazon DataZone ドメイン ID などの環境詳細を収集します。 Amazon MWAA の環境名は Amazon MWAA コンソールから取得できます。 Amazon DataZone ドメイン ID は、Amazon DataZone サービスコンソールまたは Amazon DataZone ポータルから取得できます。 CloudShell に移動し、 Actions メニューから Upload files を選択し、 requirements.txt と extract_airflow_lineage.py をアップロードします。 ファイルがアップロードされたら、次のスクリプトを実行して Airflow タスクログからリネージイベントをフィルタリングし、Amazon DataZone に登録します。(訳註： your_domain_identifier &nbsp;は自身の DataZone ドメイン ID に、 your_airflow_environment_name は自身の Airflow 環境名に置き換えます) # 仮想環境をセットアップし、依存関係をインストールする python -m venv env pip install -r requirements.txt . env/bin/activate # スクリプトを実行する python extract_airflow_lineage.py \ --region us-east-1 \ --domain-identifier your_domain_identifier \ --airflow-environment-name your_airflow_environment_name extract_airflow_lineage.py 関数は、Amazon MWAA タスクのロググループからデータリネージイベントをフィルタリングし、Amazon DataZone 内の指定されたドメインにデータリネージを登録します。 Amazon DataZone でのデータリネージの可視化 DataZone にリネージが登録された後、DataZone プロジェクトを開き、 Data タブに移動して Amazon MWAA DAG がアクセスしたデータアセットを選択します。この記事ではサブスクライブされたアセットの例を示します。 Amazon DataZone に登録されたデータリネージを可視化するには Lineage タブに移動します。 ノードを選択して追加のリネージメタデータを確認します。次のスクリーンショットでは、リネージの生成元が airflow とマークされていることがわかります。 結論 この記事では、Amazon DataZone のデータリネージのプレビュー機能、その仕組み、AWS Glue、Amazon Redshift、Amazon MWAA からリネージイベントをキャプチャしてアセットのブラウジング体験の一部として可視化する方法について説明しました。 Amazon DataZone の詳細と開始方法については Getting started guide を参照してください。Amazon DataZone の最新のデモと利用可能な機能の簡単な説明については、 YouTube プレイリスト をご覧ください。 著者について Leonardo Gomez は AWS のプリンシパルアナリティクススペシャリストであり、10 年以上にわたるデータマネジメントの経験があります。データガバナンスを専門としており、データの可能性を最大限に活かしながらデータの民主化に取り組んでいる世界中の顧客を支援しています。 LinkedIn で彼とつながってください。 Priya Tiruthani は AWS の Amazon DataZone でシニアテクニカルプロダクトマネージャーを務めています。彼女はデータアナリティクスに必要なデータの発見とキュレーションの改善に注力しています。特にデータガバナンスとアナリティクスの分野で、顧客のエンドツーエンドのデータジャーニーを簡素化するための革新的な製品を作ることに情熱を注いでいます。仕事以外では、ハイキングやネイチャーフォトグラフィー、最近ではピックルボールというスポーツを楽しんでいます。 Ron Kyker は AWS の Amazon DataZone でプリンシパルエンジニアを務めており、チームのためにイノベーションの推進、複雑な問題の解決、エンジニアリングの優秀性の基準設定に尽力しています。仕事以外では、友人や家族とボードゲームを楽しんだり、映画鑑賞、ワインテイスティングなどを趣味としています。 Srinivasan Kuppusamy は AWS の ProServe でデータ分野のシニアクラウドアーキテクト を務めており、AWS のクラウドのテクノロジーを活用してお客様のビジネス課題を解決するのを支援しています。彼の関心分野はデータアナリティクス、データガバナンス、AI/ML です。 翻訳はパートナーソリューションアーキテクトの丸山 大輔が担当しました。原文は こちら です。

本ブログは、株式会社日立パワーソリューションズと Amazon Web Services Japan 合同会社が共同で執筆しました。 株式会社日立パワーソリューションズ は、風力や太陽光など再生可能エネルギー、火力・水力プラント、工場の電気設備、生産設備など社会インフラを中心に幅広い分野で保守サービス事業を展開しています。本ブログでは、同社が AWS の生成 AI 技術を活用して、社会インフラにおける保守業務の効率化と知識共有に取り組んだ事例をご紹介します。 課題：多岐にわたる保守業務の技術伝承 日立パワーソリューションズは、風力発電設備から工場の生産ラインまで、多岐にわたる設備の保守を行っています。また、日立グループの製品のみならず他社製品も対象とすることから、保守を行う上では幅広い機器に関する知識を習得することが重要となっています。しかし現在、シニア層が保守作業員の約 10 %を占めるなど高齢化が進んでおり、そういったベテランの退職による知識喪失の深刻化への危機意識があります。そのため、ベテラン保守作業員の知識を若手・中堅社員へ確実かつ効率的に継承し、サービス品質を維持・向上させるための仕組みを構築することが重要な課題となっていました。 ソリューション：AWS を活用した生成 AI 環境の構築 これらの課題に対し、同社は AWS のサービスを活用した、社内で活用するための生成 AI 環境「Power AI Ground（パワグラ）」を構築しました。パワグラは現場の保守員を支援することを目的としており、従来から推進しているナレッジマネジメントと組み合わせることにより、保守知識の定型化・高度活用を狙っています。フィールド作業支援、保守マニュアルや指示書からの必要な情報の検索・集約、保守作業員の教材作成というユースケースを想定し、実作業への適用に向けて保守現場とのコミュニケーションを重ねています。 図1 パワグラの想定ユースケース システムアーキテクチャは以下の通りです： 図2. システムアーキテクチャ &nbsp; パワグラでは、自然言語検索サービスである Amazon Kendra を社内ナレッジベースとして活用し、生成 AI 基盤サービスである Amazon Bedrock を組み合わせることで、RAG（Retrieval-Augmented Generation）を実現しました。これにより、一般的なチャットボットと比較し、ハルシネーション(生成 AI による事実と異なる文章の生成) を抑制しつつ、自社の業務に必要なマニュアルデータや過去の作業指示書、作業報告書などを効果的に活用した高品質な回答を生成できるようになりました。また、他社の類似サービスを用いて構築した場合と比較しても、価格メリットがあり、サンプルコードで構築が容易かつ、技術支援が充実しているといった点から AWS を採用するに至りました。 経営戦略本部 湯田晋也担当本部長は「AWS の各種サービスや支援を活用することで、当初は 6 ヶ月かかると思っていた、生成 AI ソリューションの構築・効果検証を 3 ヶ月で終えることができました。また、RAG の仕組みにより、社内にある専門性の高い保守知識に関しても高い回答精度を実現することができました。」と述べています。 導入プロセスと工夫 システムの開発にあたっては、AWS や生成 AI の知識を持った人財が不足しているという課題がありました。そこで、まずは AWS の RAG 構築ワークショップへ参加することで、迅速に検証環境を構築しました。 ワークショップでは&nbsp; GitHub 上にある RAG 構築のサンプルコード をもとに、実際のデータと連携してソリューションを構築する手順を学ぶことができただけでなく、様々な技術的な質問も行うことができ、その後の検証をスムーズに進めることができました。 次に、RAG の効果を測定するべく、過去の作業報告書や設備マニュアルのデータをもとに報告書作成を支援するユースケースに絞り、回答精度を検証しました。 開発当初は 40% ほどしか精度が出ませんでしたが、原因を調査したところ、特に Excel で記述された帳票データをもとにした回答精度が悪いことが判明しました。そこで、&nbsp; Anthropic 社のユーザガイド を参考に、Claude モデルに合わせ、多様なフォーマットの報告帳票文書のうちテキスト部分を AWS Lambda で XML 形式に変換した上で、Kendra に取り込むといった工夫をしました。これにより、帳票データであっても回答精度を 40% から 90% へと大幅に向上させることができました。 図3. 帳票データを XML 変換するための仕組み 導入効果 今回の検証では回答精度 90% という良好な結果が得られたことから、今後の開発によって、保守手順文書を作成する際に設備マニュアルから引用するための工数を削減し、文書作成に要する時間を削減可能な見込みとなっています。また、同じ部品が違う呼び名で書類に記載されている場合など、従来の文書検索では類似語辞書を用意しなければ対応できないようなケースでも対応できるようになり、より柔軟性の高い回答が得られることが確認できています。 これらの結果を踏まえ、ベテランエンジニアの知識共有という当初の課題についても解決できそうだとの見通しが得られました。 今後の展望 日立パワーソリューションズでは、生成AI環境を独自に構成することで、生成 AI を活用するためのノウハウを習得することにも繋がりました。今後に向けて、自社の業務内容に合わせた生成 AI 環境「Power AI Ground（パワグラ）」をより発展させ、実運用で役立てていく予定となっています。社内で培った経験をもとに、社外向けのソリューション展開も検討しています。 まとめ 本事例は、AWS の生成 AI 技術が、多岐にわたる事業領域を持つ企業の技術伝承と業務効率化に大きく貢献できることを示しています。特に、Amazon Kendra と Amazon Bedrock の組み合わせによる RAG の実現は、専門性の高い多様な知識を効果的に活用する上で重要な役割を果たしました。さらに、サンプルコードを活用することで、3 ヶ月という期間で迅速に実装でき、より自社の業務課題に合わせた形でカスタマイズを行うことができました。 本件に関してご質問がございましたら、 株式会社日立パワーソリューションズ Web ページ よりお問い合わせください。 AWS は今後も、お客様のビジネス課題解決に向けて、最先端の生成 AI 技術と柔軟なクラウドインフラ、そして活用のご支援を提供してまいります。生成 AI に関してご興味のある方は、ぜひ AWS にお問い合わせください。

はじめに みなさん、生成AIサービス、活用していますか？ もっと生成AIを活用して、もっと多くの人がその恩恵を受けられるきっかけを提供したい！そんな想いから、AWSは、生成AIを使って日々の仕事を楽に、そして楽しくするサービスを開発するハッカソン「 AWS Japan 生成AI ハッカソン 」を開催することしました。 このハッカソンでは、企業における生成AI活用促進にフォーカスし、社員の方々が日々の仕事をもっと便利に、楽に、楽しくすることができるアプリを見出そうとしています。また同時に生成AIがもたらす高度な機能を組み込むだけでなく、開発する過程においても生成AIを駆使し、効率的に開発できることを皆さまと体験していけたらと考えています。 ハッカソンでご利用いただくのは「Amazon Bedrock」。Amazon Bedrock は単一のAPIを介してAI21 Labs、Anthropic、Cohere、Meta、Mistral AI、Stability AI、および Amazon といった大手 AI 企業からの高性能な基盤モデル (FM) を選択できるフルマネージドサービスです。Amazon Bedrockによってイノベーティブなサービスの開発が作りやすい環境が整ったといえるでしょう。 ご存じのとおり、ハッカソンではビジネス課題からユースケースを作成し、アーキテクチャーを定義して動くサービスとして実装し、プレゼンテーションまでを行います。この一連の流れを「生成AI」というキー・テクノロジーをベースに競い合い、楽しみながら経験できるのは非常に貴重な機会といえるでしょう。 以下に、ハッカソン参加の応募要領、評価基準などについてご紹介します。ぜひ皆さん奮ってご応募ください。 ハッカソンのテーマ テーマは 「生成AIを活用したアプリで社員がもっと楽しく、楽に仕事をすることが出来る仕組みを作ろう」です！ 生成AIが世に広く知られるようになって数年が経ちますが、企業に所属する社員の皆さんの中には日々の仕事においてその恩恵を十分に得られていない方も多いのではないでしょうか。生成AIの力を活用すればもっと仕事は楽に、楽しくできるはず。例えば、煩雑な作業を低減したり、創造性をかきたてたり、コミュニケーションを円滑化したり、抜け漏れを防止してくれたり・・・などなど、アイデアは無限に広がっていくでしょう。ぜひ、この機会にみなさんのアイデアを形にしてみませんか？ 審査について 審査ポイント 成果物に対する審査は、特に以下のポイントを重視します。 有用性 ユースケースの明確さ（対応する機会） アプリケーションの品質 生成AIの適用度 創造性 使うのが楽しくなるアプリケーションかどうか / 頻繁に使いたくなるアプリケーションかどうか 審査員の得点の合計および参加者相互の投票により、受賞候補者が決定され、総合得点が最も高い受賞候補者が受賞者となります。&nbsp; 審査員は QuizKnock 伊沢氏、鶴崎氏をはじめとする 豪華な顔ぶれが勢ぞろい! 審査にあたっては、多様な観点を網羅し、その価値を正しく審査できるよう各領域に通じた方々に審査員をお願いすることとしています。QuizKnock 伊沢 拓司氏は審査だけでなく、決勝戦ではナビゲーターとしても登場。決勝戦の舞台をよりエキサイティングに彩ります。そして、現役の AWSユーザーとしてアプリを実際に開発されている QuizKnock 鶴崎 修功氏や、データサイエンティストとしてのバックグラウンドを持ち、ライオン株式会社のDX戦略をリードされている 中林 紀彦氏など、まさに今イノベーションをリードする識者の方々による審査が行われます。さらに、アマゾン ウェブ サービス ジャパン合同会社でプロトタイピング &amp; クラウドエンジニアリング チームを率いる 中田 光昭がAWS 開発のエキスパートとして審査に参加します。 &nbsp; &nbsp; 参加要領 / ハッカソンの流れ このハッカソンは、チーム（最大４名）での参加をお願いしています。また、アイデアソン、ハッカソンはオンラインにて実施します。 希望者にはビジネスメンタリング、テクニカルメンタリングをそれぞれ実施します。 AWS Japan 生成 AI ハッカソンの流れ &nbsp; 応募要領/参加規約 参加条件 企業に所属する方でチームを組むことが出来る方 20歳以上の方 ハッカソンの各イベント（アイデアソン（イベントへの参加）、ハッカソン（ハッカソン期間中に開発を実施できること）、発表会（対面イベントへの参加））に参加可能であること 期日までに成果物を提出することができること チームでAWSアカウントを使用することができること AWSを使用してアプリケーションの開発と稼働を行うこと（※ハッカソン用としてAWS クレジットクーポン 25$を各チームに進呈します） Amazon Bedrockを使用すること 参加規約に同意できること チームメンバーの役割（例） ビジネスアイデアを出す アプリを設計する プログラミングを含む、実装を行う UIデザインをする プレゼンテーションを作成する 必要となる成果物 アプリケーションプログラム（デプロイされていること） ユースケースの説明スライド アプリケーションのアーキテクチャーの説明スライド アプリケーションのデモ動画 2.－4.を網羅したプレゼンテーション 参加までの流れ 当ページの登録フォームよりエントリー（代表者の方が必要事項を記入し、登録してください。10月2日締め切り） 本選への参加可否を確認する（10月４日までに代表者のメールアドレス宛にメールにてご連絡します） 本選参加確定の場合、代表者以外の各メンバーの方も全て別途ご案内する登録ページから登録する スケジュール 10月7日（月）17:00 ～18:00　説明会（オンライン） 10月11日（金）13:00- 17:00 アイデアソン（オンライン） 10月14日～25日　ハッカソン（オンライン：ただし、10月18日にオンラインにてメンタリングイベントを開催） 10月31日　14:00～18:00　発表会（対面：ザ・プリンス パークタワー東京（東京都港区）にて開催 ※ プレゼンテーションは10月25日までにいったん提出していただきます 賞品 優勝チーム：MacBook Pro もしくは25万円相当の物品、AWS クレジットクーポン USD500、優勝トロフィー 準優勝チーム：iPad Air もしくは10万円相当の物品、AWSクレジットクーポン USD 300、準優勝トロフィー ３位チーム：3万円相当の副賞、AWS クレジットクーポン USD 200、3位トロフィー なお、最終審査の結果、該当チームなしの場合もございます。&nbsp; 副賞・記念品の内容は現在検討中のため、変更となる場合がございます。 ハッカソン参加のメリット AWS Japan 生成AIハッカソンへ参加することのメリットをまとめました。ぜひ今一度ご覧ください。 生成AIアプリ開発を一通り体験できる：生成AIを組み込んだアプリ開発を、構想～設計～実装～発表までの一連の流れを体験することができます チームで協力しながら開発できる：チームでの参加なので、メンバーの得意分野を生かし協力しながら一つのものを作り上げることができます（参加希望多数の場合は選考の上参加チームを決定します） AWS BedRockが詳しくわかる：今回はAWS Bedrockを使って開発していただくことになりますので、AWS BedRockを詳しく知ることができます（参加チームにはもれなく25$ のAWS クレジットクーポンを進呈します） メンタリングを受けられる：アイデアソン、ハッカソン期間中にビジネスメンタリング、テクニカルメンタリングを受けることができます（希望者のみ） 大規模イベントの中で発表できるプレゼンテーションは 10 月 31日開催の AWS の生成AIをテーマとしたカンファレンス「AI Day」にて行い、上位 3 チームは 多くのオーディエンスを前にプレゼンテーションを行うことができます。また、AWSが発行するWebマガジン「builders.flash」にてレポート記事が掲載されます。 著名な審査員による審査：審査員には、QuizKnock 伊沢氏、鶴崎氏をはじめ、生成AIやアプリケーション開発、ビジネス開発に通じた著名な方々を想定しています。 総額200万円を超える副賞：みごと上位入賞された皆さまにはチーム単位でなく、メンバーそれぞれに賞品を贈呈いたします 最後に 生成AIサービスを作ってみたい、でもなかなかきっかけがない、という方はぜひチャレンジしてみてください。従来の開発とは異なる生成AIサービス開発ならではの気づきがあるでしょう。企業が今一番注目している生成AIの活用を皆さんがリードするチャンスです！ ぜひ こちらから ご応募ください

生成 AI の概要 生成人工知能 (生成 AI) は、会話、ストリー、画像、動画、音楽など新しいコンテンツやアイデアを生成できる AI の一種です。AI 技術は、画像認識、自然言語処理 (NLP)、翻訳などの従来とは異なるコンピューティングタスクで、人間の知能をまねようとしています。 生成 AI では、巨大なデータで事前に学習された大規模な機械学習 (ML) モデルがサポートされています。生成 AI では、次の 2 種類のモデルを認識する必要があります。 基盤モデル (FMs) は、一般化されたラベル無しのデータでトレーディングされ、パターンと関係性を学習させ、次の系列の項目を予測する ML モデルです。 大規模言語モデル (LLMs) は、FM のサブクラスの 1 つで、系列の次に来る単語を予測するようにトレーディングされています。 マッキンゼーの調査 では、63 のユースケースで生成 AI が年間 2.6 兆から 4.4 兆米ドルの付加価値を生み出す可能性があると推定されています。これは、英国の GDP 3.1 兆米ドルと比べても非常に大きな数字です。 多くの SAP のお客様は、この新しい技術からどのようにビジネスの成果を向上できるかを尋ねています。いくつかの質問例は次のとおりです。 SAP お客様向けに利用可能な生成 AI 活用ユースケースは何ですか ? 生成 AI は SAP お客様にどのようなビジネス価値を提供できますか ? 生成 AI を活用して SAP 環境をモダナイズするために何を提供していますか ? 生成 AI 活用はどこから始めるべきですか ? お客様の生成 AI 活用は、誰が支援できますか ? SAP のビジネスプロセスに生成 AI の導入をどのように成功させますか？ 最近、AWS と SAP は戦略的な協業を拡大し 、クラウド ERP (Enterprise Resource Planning) を変革し、企業が生成 AI の活用を支援しています。この協業アナウンスには以下の取り組みが含まれています。 SAP AI Core の Generative AI Hub は、Amazon Bedrock の生成 AI モデルと連携できます。これにより、SAP お客様が高パフォーマンスの大規模言語モデルと基盤モデルにアクセスして、カスタマイズされた AI アプリケーションを構築できるようになります。 SAP は、将来の SAP Business AI オファリングの学習と構築に AWS Trainium と Inferentia チップを使用する予定です。これにより、AI モデル開発プロセスを加速できます。実際の検証では、SAP エンジニアが同等の Amazon EC2 インスタンスで 23 日かかるところを、2 日で生成 AI LLMs の学習とファインチューニングを行いました。 このブログは、SAP お客様の質問に答え、AWS での生成 AI 活用のジャーニーを始めることを支援し、SAP への投資からより多くの価値を引き出すことを目的に書いています。 生成 AI はどう SAP お客様を支援するのか AWS チームは、多くの SAP お客様との会話から、お客様が検証や実装を行っている一般的な生成 AI の活用ユースケースを特定しました。以下のリストは網羅的なものではありませんので、他にビジネス課題を解決するためのユースケースを検討したい場合はご連絡ください。 No ペルソナ ユースケース ビジネスベネフィット 関連 AWS サービス ビジネスユースケース 1 販売在庫分析者 倉庫の在庫状況のリアルタイムインサイトを収集し、在庫切れと過剰在庫の状況を回避 製品の入手可能性や価格の安定性に関するお客様の信頼向上 Amazon Bedrock 2 Order-to-Cashの分析者 生成 BI 機能を使用してセルフサービスレポートを作成 Order-to-Cash プロセスを最適化し、処理時間とプロセスのボトルネックを削減し、意思決定を向上 Amazon Q in QuickSight 3 セールスアカウントマネージャー 販売ドキュメントを要約および分析することで顧客インサイトを獲得 顧客の注文とニーズを 360 度ビューで把握し、アップセリングの機会を創出 Amazon Q Business または Amazon Bedrock 4 調達管理者 RFP (提案依頼書) で記載した要件に対する複数の回答と見積もりを確認 RFP 回答の分析における生産性を向上させ、調達の意思決定を迅速化 Amazon Q Business 5 マスターデータ管理者 生成 AI を使用して、複数の言語での製品説明と画像を生成 SAP におけるマスターデータの生産性と正確性を向上させ、グローバル運用での非効率を回避 Amazon Q Business または Amazon Bedrock 6 エグゼクティブ (VP、SVP など) SAP レポートからリアルタイムインサイトを取得し、C レベル向けの電子メールを生成 CxO レベルと取締役会レベルでの意思決定を加速 Amazon Bedrock 7 財務監査管理者 SAP に集められた様々な財務取引に基づき、会社の方針に従ってリルタイム監査インサイトと異常を収集 監査コンプライアンスを迅速に処理し、異常に対する不要なエスカレーションを回避 Amazon Bedrock 8 支払債務管理者 調達から支払いまでのプロセスにおけるリアルタイムインサイトから、請求書の照合と異常の検出を実施 支払いを迅速に処理し、ベンダーとの関係を改善し、異常に迅速に対処 Amazon Bedrock 9 法務担当者 保険の補償範囲を理解するために保険ポリシー文書を要約 請求プロセスの完全性を確保し、長期的には顧客とベンダーとの関係を改善 Amazon Q Business または Amazon Bedrock 10 従業員 調達プロセスに関する会社の方針を理解 コンプライアンスを確保し、サービスと設備の調達を加速 Amazon Q Business 11 従業員 従業員福利厚生、補償範囲、請求プロセスに関する会社の方針を理解 従業員の生産性と福利厚生に対する満足度を向上 Amazon Q Business 技術的なユースケース 12 SAP ABAP 開発者 Eclipse IDE で ABAP プログラムを生成することで SAP プロジェクトを加速 開発者の生産性を最大 70% 向上 Amazon Bedrock 13 SAP ABAP 開発者 グローバル展開のための多言語印刷フォームを生成 印刷フォームを 1 回作成し、翻訳が優れた LLM により固定テキストと SAP の長いテキストを処理して、グローバルに展開 Amazon Bedrock 14 SAP ABAP 開発者 適切なドキュメントが不足の場合でも、プログラムから技術仕様とテストスクリプトを作成 SAP コンサルタントと開発者の仕様とテストスクリプトの正確性を向上 Amazon Q Business 15 SAP システム管理者 システム管理のタスクを迅速に完了 SAP システムの保守における生産性の向上とミスの削減 Amazon Q Developer AWS の生成 AI サービス AWS は、SAP お客様向けに、事前パッケージ化された生成 AI アプリケーション、独自の生成 AI アプリケーションの構築、独自の大規模言語モデル (LLMs) の開発など、生成 AI サービスを提供しています。 生成 AI スタック AWS サービス その他のサービス SAP コンテキスト 独自の大規模言語モデル開発 AWS Trainium は、AWS が 1000 億パラメータ以上のモデルの深層学習トレーニングに特化して開発した第 2 世代の機械学習アクセラレータです。一方、 AWS Inferentia アクセラレータは、AWS が Amazon EC2 上の深層学習と生成 AI の推論アプリケーションに低コストで高性能を実現するよう設計したものです。 GPU、SageMaker、Ultra Cluster、EFA、EC2 Capacity Blocks、Neuron この最も高度なシナリオでは、SAP のお客様は社内の AI/ML 機能に大きな投資を伴います。事前トレーニングされた LLM がビジネスドメインに適合しないため、独自の LLM を構築するシナリオです。 独自の生成 AI アプリケーション構築 Amazon Bedrock は、FM を使用して生成 AI アプリケーションを構築およびスケーリングするための環境を提供します。これは、主要な AI 企業から高性能の FM を選択できる、完全マネージドサービスです。セキュリティ、プライバシー、責任ある AI に関する幅広い機能も提供されます。また、ファインチューニング、検索拡張生成 (RAG)、タスクを実行するエージェントの構築もサポートしています。 Guardrails, Agents, Fine-Tuning, Retrieval Augmented generation このコンテキストでは、SAP のお客様は Bedrock で利用可能な Anthropic Claude、Amazon Titans、Stability AI などの事前トレーニングされた LLM を活用したいシナリオです。提供される LLM は、プロンプトエンジニアリング、検索拡張生成、ファインチューニングなどの一般的な手法を使用することで、十分にユースケースを満たすことができます。 パッケージ化された生成 AI アプリケーション Amazon Q は、ビジネスに合わせてカスタマイズできる、作業向けの生成 AI アシスタントです。会社のデータ、情報、システムに接続することができます。 Amazon Q in QuickSight は、自然言語プロンプトを使用してビジネスデータからインサイトを簡単に作成・活用できる生成 BI アシスタントです。これにより、ダッシュボードやストーリーの作成が加速し、ビジネスプロセスでの意思決定が迅速化されます。 Amazon Q in AWS Supply Chain は、サプライチェーンプロセスの最適化を支援する生成 AI アシスタントです。 Amazon Q in Connect は、顧客の質問に対する応答とアクションを提案し、迅速な問題解決と顧客満足度の向上を実現します。エージェントは、リアルタイムの会話中に、さまざまなリポジトリからのナレッジ記事、Wiki、FAQ にアクセスできます。 Amazon Q Developer SAP のお客様の大半は、おそらくこのカテゴリに該当し、事前構築された生成 AI サービスを活用してイノベーションを始めるでしょう。 数ステップの設定作業を実行することで、従業員の生産性を向上させるための独自の生成 AI アシスタントを構築できます。また、企業の意思決定を加速するために、ビジネスユーザがセルフサービスでレポートを作成できるように独自の生成 BI 機能を構築できます。 Amazon Q Developer は、ソフトウェア開発ライフサイクルの加速に役立ちます。 SAP ユースケースにおける Amazon Q と Amazon Bedrock の比較 Amazon Q と Bedrock の提供内容について詳しく見ていきましょう。これらは、事前構築されたサービスと生成 AI 機能を揃っているサービスにより、SAP のユースケースの大半をカバーし、生成 AI の採用を加速します。 Amazon Q Business は、エンタープライズデータに基づいて質問への答え、文書の要約、コンテンツ生成、タスク実行ができるように構成できる、マネージドサービスの生成 AI アシスタントです。AWS クラウドサービス内のさまざまなサービスに組み込まれています。ここでは 2 つの提供内容について説明します。 Amazon Q Business は、社内ポータル、SharePoint、Amazon S3 バケットなどの企業データソースと連携することで、独自の生成 AI アシスタントを作成するのに最適なオプションです。これらのナレッジベースを活用して質問に答えられる機能により、企業がメリットを得るための最も手軽な方法となります。 Amazon Q in QuickSight は、ユーザーにセルフサービスのレポーティングプラットフォームを提供することで、生成 BI の利活用が始められます。ユーザーは、SQL 文、結合メカニズム、その他の技術要素を理解しなくても、自然言語で独自のビジュアルダッシュボードやストーリーを作成できます。 AWS Supply Chain と Amazon Connect は、特定のビジネスシナリオ向けに構築されたマネージドサービスです。これらのサービスを使用すると、Amazon Q がデフォルトで組み込まれることで、重要なビジネスプロセスの生産性が向上します。 一方、Amazon Bedrock は、開発者に完全マネージド型の機械学習サービスを提供し、カスタム AI モデルとアプリケーションの構築、デプロイ、スケーリングを可能にします。さまざまな大規模言語モデルを評価、選択、調整する機能を備えています。モデル開発とトレーニング、モデルホスティングとデプロイ、監視とオブザベーション、セキュリティとコンプライアンス、スケーラビリティとコスト効率、さらに幅広い AWS エコシステムとの統合のための管理環境を提供します。Amazon Bedrock は、インフラストラクチャとオペレーションをマネージドで実施しているため、AI アプリケーションの開発プロセスを簡素化し、開発者がモデル開発とアプリケーションロジックに集中できるようにします。 Amazon Q と Bedrock がサポートするセキュリティ標準 Amazon Q Business では、ユーザーのアクセス許可に基づいて適切なコンテンツにアクセスできるようデータのアクセス制御をサポートしています。Okta、Azure AD、Ping Identity などの外部 SAML 2.0 対応の ID プロバイダーと Amazon Q Business の Web エクスペリエンスを統合することで、ユーザー認証と認可を管理できます。 Amazon Bedrock は、お客様のプロンプトを AWS モデルの学習やサードパーティへの配布に使用することはありません。各モデルプロバイダーは、自身のモデルをアップロードするためのエスクローアカウントを持っています。Amazon Bedrock の推論アカウントにはこれらのモデルを呼び出す権限がありますが、エスクローアカウント自体には Amazon Bedrock アカウントへの送信権限はありません。さらに、モデルプロバイダーは Amazon Bedrock のログやお客様のプロンプトにアクセスできません。 Amazon Bedrock は、お客様の学習データを基盤モデルの学習やサードパーティへの配布に使用することはありません。使用タイムスタンプ、ログインしたアカウント ID、サービスによってログに記録されたその他の情報など、その他の使用データもモデルの学習に使用されることはありません。 Amazon Q と Bedrock を SAP に連携する方法 前述の考慮事項を踏まえ、Amazon Q と Bedrock を活用して SAP 環境で生成 AI 機能を有効にする方法について、いくつかのアーキテクチャガイダンスを説明します。これらは SAP での生成 AI の使用事例を網羅したリストではありません。アーキテクチャガイダンスは、ランドスケープと要件によって異なる可能性があります。 SAP ユースケースでは、まずSAP BTP の Generative AI Hub を検討 ブログ AWS と SAP の生成 AI サービスを活用しセキュアでスケーラブルなビジネス環境に では、SAP AI Core サービスが大規模言語モデルなどの AI アセットをお客様に公開し、SAP BTP エコシステム上で実行される SAP アプリケーション向けの統一インターフェースを提供しています。 このジョイントリファレンスアーキテクチャ (JRA) では、SAP AI Core の Generative AI Hub を Amazon Bedrock へのアクセスとライフサイクル管理レイヤーとして使用し、アプリケーションが基盤モデルを利用できるエンドポイントを提示しています。 Generative AI Hubを通じて、SAP は SAP エコシステム全体でコンテンツフィルタリング、SAP 固有のリスク軽減、セーフティガードレールを一元的に適用し、潜在的なビジネスおよび法的リスクに対する規制準拠のアプローチを提供しています。 図 0. SAP AI Core を通じて Amazon Bedrock 呼出し SAP インサイトの参考構成 (例：ユースケース 1 ) 下の画像は、カスタムレポートの作成がなくても、セールスマネージャーが SAP Fiori Launchpad から直接在庫状況を問い合わせることができる機能を説明しています。これにより、従来のカスタム開発するための約 14 人日の ABAP 開発とテスト工数を削減できる可能性があります。 ユースケースの流れ: 英語でのクエリ: “Product highest inventory value at Chennai Warehouse” “The product with highest inventory value at Chennai Warehouse is Infrared Camera with total value of $1700” 図 1. SAP インサイト SAP Datasphere と SAP S/4HANA との統合機能を備えた SAP HANA Cloud を活用しています。このシナリオでは、SAP Build Apps でユーザからの自然言語でのクエリを受け、API Gateway が提供する REST API をトリガーできます。この REST API 自体が Lambda 関数をトリガーし、Amazon Bedrock で提供される Retrieval Augmented Generation (RAG) をトリガーします。これは SAP HANA Cloud からのデータと連携できます。この構成は、AI Core 上の SAP Generative AI Hub を使用して、レイテンシを最小化しパフォーマンスを向上させるように変更することも可能です。 図 2. SAP インサイトアーキテクチャ図 ビジネスユーザー向けのセルフサービスレポーティングの参考構成 (例：ユースケース 2) Amazon Q in QuickSight が、ビジュアル作成とストーリーを通じて、ビジネスユーザーが自身でセルフサービスレポートを作成できる方法を、以下の画像で説明します。これにより、専門のデベロッパーやアナリティクスチームを関与しなくても、さまざまなレポートの作成に要する時間を数日から数時間に短縮できる可能性があります。 ユースケースの流れ: ターゲットオブジェクト に沿ったストーリーを作成するために英語のプロンプトを入力します ストーリーを作成するために含める必要なダッシュボードのビジュアルを選択します ビルドをクリックします タイトルは Amazon Q によって自動的に生成されます セクションは Amazon Q によってストーリーの流れで作成されます 最後に結論が生成され、推奨事項生成で完成になります 図 3. Amazon Q in QuickSight によるセルフサービスレポーティング SAP Datasphere と SAP S/4HANA との統合機能を備えた SAP HANA Cloud を活用しています。Athena は、データフェデレーション機能を使って SAP HANA Cloud からデータ参照するように構成できます。ビジネスユーザーは、Athena を通してデータを取得し、Amazon Q in QuickSight で自然言語プロンプトを使ってビジュアルダッシュボードやストーリーを作成できます。 SAP のデータソースウィザードは、この構成を実現するための関連 Lambda 関数を作成します。 図 4. セルフサービスレポーティングの参考構成 SAP 向け生成 AI アシスタントの参考構成 (例: ユースケース 2、3) 下の画像は、Amazon Q が SAP Work Order アプリケーションの作業手順書とチャットすることで、保守エンジニアを支援する方法を説明しています。これにより、数百ページの印刷や、特定の情報を探すための各ページの確認が不要になり、プラント保守の生産性、正確性、作業品質が向上します。 ユースケースの流れ: メンテナンスオーダーには、バルブの修理方法を説明した作業手順 PDF を添付しました SAP にアップロードされたら、その PDF は Amazon Q Business でクロールされ検索可能になります。ユーザーは「How to repair the control valve if it has leakages ?」のように、ドキュメントを問い合わせることができます 図 5. SAP 向けの生成 AI アシスタント SAP ERP または S/4HANA には、トランザクションデータ (構造化データ) と文書 (非構造化データ) の両方が含まれています。 トランザクションデータは Amazon AppFlow を使用して Amazon S3 バケットに抽出できます。これを Redshift にロードするか、または Athena で直接読み取ることができます。Amazon Q in QuickSight は、Redshift または Athena のいずれかをデータソースとして使用し、自然言語プロンプトを使用したセルフサービスレポーティングの生成的 BI 機能を可能にします。これにより、SQL やプログラミングの知識がなくてもビジネスユーザーが独自のダッシュボードやストーリーを作成できます。ポイント 1、4、6 を参照してください。 SAP トランザクションに添付された請求書、契約書、見積書等の文書は、 AWS SDK for SAP ABAP または SAP Content Server を使用して S3 バケットに抽出できます。これらの非構造化データは、Amazon Q Business でクロールされインデックス付けされ、AWS IAM Identity Center によってエンドユーザーのアクセスが制御できます。 図 6. SAP 向け生成 AI アシスタントの構成図 上の図のステップの説明: AWS SDK for SAP ABAP を通じて、SAP レポート、添付ファイル、アーカイブデータを Amazon S3 バケットに抽出します Amazon Q は、Amazon S3 バケットに抽出されたデータ (購買発注書、請求書、マテリアルマスター、品目マスター、保守発注書、作業指示書など) をクロールします Amazon Q は、プロジェクト情報、作業ログ、現場写真、現場安全観察、日次調査などを含む他のデータソース (SharePoint、Jira、Zendesk など) からもクロールします S3 からの構造化データとレポートは、Athena 経由又は Redshift にロードでき、その後 Amazon Q と QuickSight を使用して、S3 に保存できるストーリーボードやレポートを作成できます AWS IAM Identity Center を統合して、Active Directory、Okta、その他のアイデンティティプロバイダーでユーザー認証ができます ユーザーは Web ブラウザから Amazon Q と QuickSight にアクセスでき、Fiori などの SAP フロントエンドに埋め込むこともできます ABAP Assistant for SAP の参考構成 (例：ユースケース 12) 下の画像は、Bedrock の機能を Eclipse 開発ツールに統合することで、ABAP コードとドキュメントを生成する方法を説明しています。この機能により、ABAP プログラミングを高速化し、ABAP ドキュメントの作成を支援することで、SAP での Clean Core 実装を加速できると考えられ、開発者の生産性が 70% 向上すると期待できます。 SAP ABAP Assistant プラグイン を使えば、SAP 開発者は Eclipse IDE から ABAP コードと ABAP ドキュメントを生成できます。ABAP Assistant Eclipse プラグインは Eclipse IDE にインストールされ、開発者の個人パソコンで動きます。 ユースケースの流れ: ビジネス要件に基づいて ABAP プログラムを作成するためのプロンプトを書き、Amazon Bedrock を呼び出します プロンプトから ABAP プログラムが自動生成されます 図 7. SAP 向け ABAP アシスタント 図 8. SAP 向け ABAP アシスタントの構成図 上の図のステップの説明: ABAP 開発者は、コマンドラインインターフェース (AWS CLI) を使用して AWS IAM Identity Center で認証を行い、プラグインで使用される認証情報を取得します。 ABAP 開発者は、SAP システムを Eclipse の ABAP プロジェクトとして追加します。 ABAP 開発者が ABAP Assistant プラグインを呼び出すと、設定された AWS Identity and Access Management (IAM) ロールを引き受け、Amazon Bedrock を呼び出すために必要な認証情報を生成するために AWS Security Token Service (STS) が呼び出されます。 ABAP Assistant プラグインは、Amazon Bedrock サービスを呼び出して ABAP コードとドキュメントを生成し、結果を Eclipse に返します。 まとめ 私たちは、さまざまな生成 AI の SAP ユースケースとその潜在的なビジネス価値について説明しました。また、SAP 環境での変革を始め、加速させるのに役立つ AWS のサービスオファリングについても説明しました。 これから、お客様の SAP 環境のために生成 AI の力を解き放つことが可能になりました。Amazon Q と Bedrock を使えば、これまでにないほど簡単に始められます。 Amazon Q のドキュメント と ブログ をご確認し、Amazon Q 搭載の生成 AI アシスタントの設定方法を学んでください。ステップバイステップのガイド、サンプル構成、ベストプラクティスがあり、SAP に添付されたドキュメントの要約から、意思決定を加速するための推奨事項の生成まで、あらゆることをサポートできる Q モデルをすばやく展開できます。 Amazon Q in QuickSight を使って、ビジネスユーザー向けのセルフサービスレポーティングを始め、生成 BI アシスタントとして、ビジュアルダッシュボードやストーリーを簡単に作成することで、意思決定スピードを向上させます。 Amazon Bedrock のドキュメント と ブログ もご確認ください。Bedrock は、大規模言語モデルを構築し、本番規模で展開するための包括的な基盤を提供します。Bedrock を使えば、事前学習済みモデルを調整し、安全にホストし、SAP アプリケーションに統合できます。 AWS Generative AI for SAP ワークショップ を試して、Bedrock、Amazon Q、QuickSight の機能を体験してください。このワークショップは現在、SAP AI Core の Generative AI Hub を含めるように改訂中です。 PartyRock も忘れずに探索して、Bedrock 搭載のプレイグラウンドで AI 生成アプリの構築を体験してください。 最後に、 Amazon Bedrock の生成 AI モデルを統合する SAP AI Core の Generative AI Hub を検索してみましょう。これにより、SAP お客様は高性能な大規模言語モデルと基盤モデルにアクセスして、AI アプリケーションを構築できるようになります。 AWS for SAP ブログ を確認し、SAP への投資からより多くの価値を得る方法について情報を収集してください。今日から Amazon Q と Amazon Bedrock を使い始め、ビジネスに生成 AI の力を解き放ちましょう! SAP on AWS ディスカッションへの参加 お客様のアカウントチームと AWS サポートチャネルに加えて、最近 re:Post – AWS コミュニティ向けの質問と回答のサイトをローンチしました。AWS for SAP ソリューションアーキテクトチームは、AWS for SAP のトピックを定期的に監視し、お客様やパートナーの皆様をサポートできる議論や質問に回答しています。質問がサポート関連でない場合は、re:Post に参加してコミュニティのナレッジベースに貢献することをご検討ください。 クレジット このブログへの貢献に感謝したいチームメンバー: Gyan Mishra, Adren D Souza, Derek Ewell, Beth Sharp, Spencer Martenson。 翻訳は Specialist SA トゥアンが担当しました。原文は こちら です。

本ブログは、株式会社 朝日新聞社 と Amazon Web Services Japan が共同で執筆しました。 株式会社 朝日新聞社 は 140 年以上と国内有数の歴史を持つメディア企業であり、紙からデジタルまで幅広い媒体で情報を提供しています。本ブログでは朝日新聞社が開発したコンテンツ制作支援サービス 「ALOFA」 の概要とそのなかでどのように Amazon Bedrock が活用されているかを紹介します。 コンテンツ制作における課題 コンテンツ制作の現場では、取材の音声データの文字起こしに膨大な時間と手間がかかる、使いたい音声・動画ファイル、シーンを見つけるのが大変、大量の取材データが PC のストレージを圧迫してしまう、大量のデータをうまく活用できないなどの課題に直面する場合があります。朝日新聞社ではそのような課題を解決するために、コンテンツ制作支援サービスを開発しました。現在このツールは朝日新聞社の記者に提供され、記者の記事制作における効率化に貢献しています。このコンテンツ制作支援サービスは現在社内向けに公開されていますが、社外への展開も検討しています。 ソリューションの概要 本コンテンツ制作支援サービス ALOFA では独自の音声認識モデルを活用し高品質な文字起こし体験を提供します(業務効率化の取り組みにご興味がある方は「 株式会社朝日新聞社での文字起こしシステムにおけるサーバーレスの活用 – 処理時間を短縮し業務貢献しながらクラウド費用も削減した話 」をご覧ください)。以下の図 1 は ALOFA の画面イメージになります。 図 1 ALOFAの画面イメージ ALOFA のエディタを使って音声を聴きながら書き起こし文を細かく修正することができます。独自の話者分離モデルによる話者の識別に加え、話し言葉特有の冗長表現を検知・削除できる機能を搭載しています。また、ハイライト機能や要約、チャプター生成機能によってファイルの内容や重要な部分がすぐに把握できます。 ALOFA は AWS 上で稼働しておりサーバーレスのサービスを活用して実現しています。生成 AI は要約やチャプターの生成などに利用しており、生成 AI のプラットフォームとして Amazon Bedrock を利用しています。 Amazon Bedrock は 単一の API を介して 複数のモデルを選択することができるため、特定のタスクの解決するためにどのモデルが最適なのかを容易に検証することができます。朝日新聞社では用途に応じて最新の複数のモデルを検証し、それぞれの用途に最も適したモデルを採用しました。また Amazon Bedrock は AWS の他のサービスから容易に呼び出せるため、既存のワークロードに生成 AI を容易に導入できます。以下の図 2 がアーキテクチャーの概要になります。 図 2 コンテンツ制作支援サービスのシステム構成 本システムでは並列処理の中で Amazon Bedrock を呼び出すユースケースがあり、 Amazon Bedrock へのリクエストが多くなってしまう場合があります。急激なリクエストの増加に対応するため以下の図 3 の様に AWS Lambda から複数リージョンのエンドポイントを呼び出すアーキテクチャーを採用しています。推論処理を複数のリージョンに分散することにより安定的に生成 AI を活用することができています。 図 3 Amazon Bedrock のマルチリージョンアーキテクチャーイメージ まとめ 本ブログでは 朝日新聞社で開発されたコンテンツ制作支援サービスの紹介とその中で Amazon Bedrock がどのように活用されているかを紹介しました。 Amazon Bedrock を利用することによってみなさまの AWS 上のワークロードに生成 AI を活用した機能を容易に組み込めます。本ブログが生成 AI を活用されている皆様の参考になりましたら幸いです。 本ブログは、株式会社朝日新聞社メディア事業本部メディア研究開発センター 山野氏、嘉田氏、杉野氏とソリューションアーキテクトの紙谷が共同で執筆いたしました。 株式会社朝日新聞社　メディア事業本部メディア研究開発センター PdM 兼機械学習エンジニア　山野 陽祐 文字起こしサービスの開発全般と機械学習のモデル構築に従事しています。 株式会社朝日新聞社　メディア事業本部メディア研究開発センター 機械学習エンジニア兼バックエンドエンジニア　嘉田　紗世 主に文字起こしサービスの開発や画像分野の研究に従事しています。 株式会社朝日新聞社　メディア事業本部メディア研究開発センター 機械学習エンジニア　杉野　かおり 文字起こしサービスに関する研究や、データ作成基盤運用に従事しています。

はじめに コンタクトセンターのエージェントは、複雑なワークフローを伴うトピックでもお客様をサポートしています。 Amazon Connect エージェントワークスペース 内のステップバイステップガイドは、特定のユースケースを処理する方法をエージェントに明確な手順として示します。ステップバイステップガイドはエージェント向けのワークフローで、エージェントの選択に基づいて分岐したり、外部システムとデータを送受信したりできます。ステップバイステップガイドはエージェントの生産性を高め、トレーニング時間を短縮し、一貫したカスタマーエクスペリエンスの提供を支援します。このようにステップバイステップガイドを操作する際、エージェントは機密データや極秘データを収集・入力することも頻繁にあります。そのようなデータは、通話ログや画面録画に記録されるべきではありません。 このブログ記事では、特定のステップバイステップガイドが呼び出されたときに自動的に録画を一時停止し、ワークフローが完了したら録画を再開するソリューションについて詳しく説明します。このソリューションでは、ワークフロー区間中の記録を自動的に停止する方法についても説明しています。 ソリューションの概要 このソリューションでは、 AWS CloudFormation テンプレート を使用して、必要なコンタクトフローと AWS Lambda 関数 を作成します。Amazon Connect コンタクトフローの ログ記録動作の設定 ブロックは、機密情報を収集する ステップバイステップガイドビューを呼び出す前にコンタクトフローのログ記録を無効にします。ビューが完了すると、コンタクトフローの ログ記録動作の設定 がコンタクトフローのログ記録を再開します。 SuspendContactRecording API は、コンタクトメディアとエージェントの画面の録画を一時停止します。コンタクトフローでは、Lambda 関数がビューを表示ブロックの前に SuspendContactRecording API を呼び出します。完了すると、別の Lambda 関数がコンタクトフローで ResumeContactRecording API を呼び出して、録画を再開します。 必要なアセットがデプロイされた後、ユーザーは次の手順で作成されたコンタクトフローに Amazon Connect の電話番号を指定する必要があります。テスト時に通話の発信者は 1 を押して新しい銀行口座を開設の希望を選び、ステップバイステップガイドを利用するエージェントに接続します。 このソリューションのアーキテクチャ図は以下の通りです。 ステップバイステップガイド内のビューに入力されたデータはすべてチャットとして記録されることに注意してください。ガイドの記録を削除して、意図しないデータ漏えいを防ぐため、このデータは適切に保護または消去する必要があります。 デプロイ手順 前提条件 このブログ投稿の手順を実施するには、以下の通り、サービスの使用方法の理解、サービスの権限の用意が必要です。 管理者アクセス権限を持ち、マネジメントコンソールにアクセス可能な AWS アカウント ロールとポリシーを作成するための AWS IAM へのアクセス権限 電話番号が割り当てられ、通話録音と画面録画が有効になっている Amazon Connect インスタンス スタックを実行するための AWS CloudFormation ステップ 1: Amazon Connect インスタンスの詳細を取得します AWS マネジメントコンソール にサインインし、Amazon Connect インスタンスと同じリージョンを選択します このスタックを展開する対象の Amazon Connect インスタンスの ARN を特定してメモします。「 Amazon Connect インスタンスの ID/ARN を検索する 」を参照してください Amazon Connect ダッシュボードのキューセクションに移動します BasicQueue を検索します。検索結果からキュー名をクリックします 追加のキュー情報を表示 という名前のセクションを展開します。ARN をメモします 左の画像をクリックし、AWS CloudFormation テンプレートを起動します 一意のスタック名を入力します。この例では、 SBS-pause-recording を使用しています このスタックを展開する Amazon Connect インスタンスの ARN と、Contact Flow を関連付ける Amazon Connect キューの ARN を入力します IAM リソースの作成に同意します スタックの作成 を選択して、必要なアセットをプロビジョニングします。これには 10 分かかります このスタックの状態が CREATE_COMPLETE になるまで待ちます Amazon Connect インスタンスに移動し、電話番号にフロー SBS-pause-recording-SBSPauseResumeDemoHandler を関連付けます ソリューションのテスト URL https:// （Amazon Connect インスタンスエイリアス名） .my.connect.aws/agent-app-v2 を使用して、エージェントワークスペースにログインします。Connect インスタンスエイリアス名は、 このリンク から確認できます フロー SBS-pause-recording-SBSPauseResumeDemoHandler に関連付けられた電話番号に架電します 通話が接続され、番号の入力を求められたら、 1 を押して新しい銀行口座開設の手続きを選びます エージェントがエージェントワークスペースで着信を受け入れると、ステップバイステップガイドが自動的にロードされます 「新しい口座を開く (Open a new account) 」ボタンをクリックします 「新しいリクエストを開始 (Start a new request) 」をクリックします 新しい口座フォームに顧客情報を入力します 「 送信 (submit) 」をクリックします フォームに入力された情報に不足がなければ、以下の画面に推移します この時点で、通話を切断し、コンタクトを閉じることができます &nbsp;(エージェントワークスペースで通話を切断し、コンタクトを閉じることが必要です。コンタクトを閉じることにより、録音が完了し、すべての必要なログの生成が開始されます。) AWS マネジメントコンソールで CloudWatch に移動します 左側の ログ を展開します。 ログ の下の ロググループ をクリックします ロググループ内で、Amazon Connect インスタンスのロググループをクリックします。ここで、行われたテスト通話のログを検索できます 通話の詳細が表示されます。この ページ で LoggingBehavior を検索すると、通話の接続後、最初にログが有効になった箇所が表示されます。2 回目の LoggingBehavior のログは、ログ記録が再度有効になった箇所を示します。2 回目の LoggingBehavior が有効になったログメッセージと、その前のログメッセージの時間差に注目してください。ログ記録が一時停止された時間差が確認できます Contact Lens で通話録音と画面録画が有効になっている場合、録音と録画を確認でき、エージェントが機密情報を記録している間、録音と録画が一時停止されていることがわかります。 クリーンアップ 今後の課金を避けるため、作成されたすべてのアセットを削除してください。以下のスクリーンショットのように CloudFormation でスタックを削除することで、アセットを削除できます。 訳注: 電話番号とコンタクトフローの紐づけを解除してから削除を行う必要があります 結論 このブログ記事では、ステップバイステップガイドを使用してエージェントが機密情報を扱う際に、セキュリティコンプライアンスを維持する方法を示しました。このソリューションを使用すると、機密データの収集中に録音と録画を一時停止できます。他の詳細については、 Amazon Connect のドキュメント にアクセスするか、AWS の担当者にお問い合わせください。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

この記事は Migrating from AWS App Mesh to Amazon ECS Service Connect (記事公開日: 2024 年 9 月 24 日) を翻訳したものです。 慎重に検討した結果、2026 年 9 月 30 日をもって AWS App Mesh のサポートを終了することを決定しました。この日まで、既存の AWS App Mesh のお客様は、AWS CLI や AWS CloudFormation による新しいリソースの作成や新しいアカウントのオンボーディングなど、通常通りにサービスを利用できます。また、AWS はこの期間中も、AWS App Mesh にセキュリティと可用性に関する重要な更新を引き続き提供します。新規のお客様は、2024 年 9 月 24 日以降、AWS App Mesh にオンボーディングできなくなります。 re:Invent 2022 で、AWS は Amazon ECS Service Connect をリリースしました。これは、 Amazon Elastic Container Service (Amazon ECS) 内のマイクロサービスを接続する新しい方法です。本投稿では、Service Connect の詳細と、 AWS App Mesh から Service Connect への移行戦略について説明します。Service Connect は、外れ値検出やリトライによって、コンテナ化されたマイクロサービスの信頼性を向上させます。また、アプリケーションレベルのネットワーキングメトリクスを Amazon CloudWatch に送信することで、オブザーバビリティも向上させます。Service Connect では、マネージドなネットワーキングデータプレーンを利用することで、サイドカープロキシの管理に伴う差別化につながらない重労働が不要になります。 App Mesh と Service Connect の比較 サービスメッシュは抽象化レイヤーを通じて、ルーティングルールを実装し、セキュリティレイヤーを追加し、オブザーバビリティを提供します。App Mesh から Service Connect への移行をはじめる前に、Service Connect の抽象化レイヤーを理解し、App Mesh の抽象化レイヤーと比較することが重要です。このセクションでは、Amazon ECS にデプロイされた多層アプリケーションを使用して、これらの抽象化を説明します。 次の図 1 は、サービスメッシュを実装する前のサンプルアプリケーションを示しています。フロントエンドサービスと、ユーザー、ストックという 2 つのバックエンドサービス API で構成されています。3 つのサービスは、長時間稼働する サービス として Amazon ECS にデプロイされており、1 つ以上のタスクが実行されています。Application Load Balancer や Network Load Balancer といったロードバランサーは、耐障害性を提供し、アーキテクチャ内の各サービスのタスク全体にトラフィックを分散します。 図 1: サービス間のルーティングをロードバランサーで提供するサンプルアプリケーション このアーキテクチャで App Mesh を利用する場合、抽象化によってルーティングルールとセキュリティ境界を実装します。各マイクロサービスは、 App Mesh の Virtual Service にカプセル化されます。Virtual Service には、 App Mesh の Virtual Node と呼ばれる複数のバージョンのアプリケーションがあり、 App Mesh の Virtual Router が Virtual Node 間のルーティングルールを実装している場合があります。 次の図 2 は、App Mesh を利用するサンプルアプリケーションを示しています。3 つの Amazon ECS サービスの各タスクに対して、セルフマネージドの Envoy プロキシ をサイドカーコンテナとしてデプロイします。このプロキシは、App Mesh のルーティング、信頼性、オブザーバビリティといった機能を実装しています。また、サービス間のクライアント側のルーティングも提供されるため、必要なロードバランサーの数を減らすことができます。 AWS Cloud Map の名前空間 はサービスディスカバリに利用され、各リソースは App Mesh リソースの論理的な境界である App Mesh の Mesh にアタッチされます。 図 2: App Mesh を利用するサンプルアプリケーション Service Connect はこれらの抽象化を効率化し、サイドカーコンテナの Envoy プロキシは Service Connect プロキシ として AWS がフルマネージドに管理します。Service Connect の抽象化には「クライアント」と「サーバー」サービスが含まれます。「サーバー」サービスは、別のマイクロサービスと通信する場合、「クライアント」としても機能します。この場合、 「クライアント / サーバー」サービス と呼ばれます。AWS Cloud Map の名前空間は、サービスを検出し、リソースの論理的な境界を定義します。 次の図 3 は、Service Connect を利用するサンプルアプリケーションのアーキテクチャを示しています。フロントエンドアプリケーションは「クライアント」サービスになり、AWS Cloud Map 名前空間の一部になりますが、エンドポイントは公開されません。ユーザー API とストック API は、どちらも名前空間にアタッチされた「サーバー」サービスであり、「クライアント」が接続するためのエンドポイントを公開しています。 図 3: Service Connect を利用するサンプルアプリケーション App Mesh から Service Connect への移行 Amazon ECS サービスを、App Mesh の Mesh と Service Connect の名前空間の両方に同時に含めることはできません。したがって、移行を実行するには、Amazon ECS サービスを再作成する必要があります。このプロセス中のダウンタイムを回避するために、 Blue/Green 移行戦略 を実装できます。このアプローチでは、各 Amazon ECS サービスのコピーを作成し、2 つの環境間でトラフィックを徐々に移行します。Blue/Green 移行戦略でトラフィックをきめ細かく移行するには、 Amazon Route 53 加重ルーティング 、 Amazon CloudFront の継続的デプロイ 、 Application Load Balancer の加重ターゲットグループ など、いくつかの方法があります。 次の図 4 は、App Mesh から Service Connect へのアプリケーションの移行を示しています。エンドユーザーは Amazon Route 53 加重ルーティングを通じて、App Mesh 環境から Service Connect 環境へ徐々に移行されます。Service Connect は、アプリケーションレベルのネットワーキングメトリクスを無料の CloudWatch メトリクスとして提供します。この移行プロセスでは、Service Connect 環境に送信されるトラフィックの量を、 加重レコードの重みを調整 することで徐々に増加できます。Service Connect が提供するメトリクスを利用して、管理者は負荷の増加をモニタリングして設定の誤りを検出できます。 図 4: App Mesh を利用するアプリケーションから Service Connect を利用するアプリケーションへのトラフィック移行 各サービスメッシュの環境には個別のサービスディスカバリ実装があるため、サービスメッシュ環境をまたぐネットワーク通信はありません。エンドユーザーからの接続は、それぞれのサービスメッシュ内に残ります。たとえば、トラフィックが App Mesh を利用するフロントエンドに送信された場合、アクセスされるバックエンド API は App Mesh の Mesh に含まれるバックエンド API になります。App Mesh を利用するフロントエンドは、Service Connect 環境のバックエンドサービスとは通信できません。 機能の比較 Service Connect を利用すると、プロキシ管理や複数の抽象化レイヤーが不要になり、サービスメッシュの管理に伴うオーバーヘッドがなくなります。AWS は Service Connect に多くの投資を行っており、強力なロードマップを策定していますが、現時点では、すべての Envoy プロキシ機能が Service Connect で利用できるわけではありません。このセクションでは、Service Connect と App Mesh の機能の違いについて説明します。 ネットワークの信頼性の向上 : App Mesh と Service Connect はどちらも、Envoy の 外れ値検出 や リトライ を利用して、サービス間の信頼性を高めています。App Mesh ではこれらの設定を変更できますが、Service Connect では独自のデフォルトがあります。タイムアウトに関しては、Service Connect でも設定の変更が可能です。 高度なトラフィックルーティング : App Mesh では、仮想的なルーティングメカニズムを利用して、Virtual Router により複数の Virtual Node 間、すなわち複数のマイクロサービスのバージョン間でトラフィックをきめ細かくルーティングできます。Service Connect では、高度なトラフィックルーティングは利用できません。 オブザーバビリティ : App Mesh では、 トラフィックメトリクス を取得してモニタリングサービスに送信し、オブザーバビリティダッシュボードを構築する必要があります。Service Connect では、 アプリケーションレベルのネットワーキングメトリクス を無料の CloudWatch メトリクスとして提供します。これらのメトリクスは、 CloudWatch コンソール と Amazon ECS コンソール に表示されます。 セキュリティ : App Mesh と Service Connect はどちらも、サービス間の通信を暗号化するための TLS をサポートしています。App Mesh では、 AWS プライベート CA (AWS PCA) の GENERAL_PURPOSE モード の証明書を活用できます。一方で Service Connect では、簡単な設定で低コストな AWS PCA の SHORT_LIVED_CERTIFICATE モード の証明書を活用できます。また、App Mesh では 相互 TLS 認証 を実装できますが、Service Connect では相互 TLS 認証を利用することはできません。 リソースの共有 : AWS Resource Access Manager (AWS RAM) では、App Mesh の Mesh を複数の AWS アカウントで共有できます。これにより、Mesh という同じ論理的な境界に属しながら、アプリケーションを複数のアカウントに分散できます。Service Connect では、AWS Cloud Map 名前空間を複数の AWS アカウントで共有することはできません。そのため、現時点では、サービスメッシュに含まれる全てのアプリケーションを、同じ AWS アカウントにデプロイする必要があります。 まとめ 本投稿では、App Mesh から Amazon ECS Service Connect への移行について説明し、2 つのサービスの主な違いを説明しました。Service Connect が提供する効率的な抽象化とマネージドなネットワーキングデータプレーン、およびトラフィックルーティング、オブザーバビリティ、セキュリティ、リソース共有に関する考慮事項について説明しました。 App Mesh を利用しており、Service Connect への移行を検討している場合は、本投稿で紹介している Blue/Green 移行戦略をご検討ください。Service Connect の詳細については、 Amazon ECS ドキュメント と、 Amazon ECS Immersion Day ワークショップ をご確認ください。このワークショップでは、サンプルの 小売アプリケーション をデプロイして、サービスを実際に体験できます。 App Mesh を利用する Amazon Elastic Kubernetes Service (Amazon EKS) のお客様向けの移行ガイダンスについては、今後の AWS ブログをお待ちください。 翻訳はソリューションアーキテクトの落水が担当しました。原文は こちら です。