2024 年 2 月と 3 月に公開された AWS Black Belt オンラインセミナーの資料及び動画についてご案内させて頂きます。 動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画は「 AWS サービス別資料集 」に一覧がございます。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご覧ください。 Amazon EMR EMR Serverless 編 Amazon EMR Serverless は Amazon EMR のサーバーレスオプションです。データアナリストやエンジニアが、クラスターやサーバーを設定、管理、スケーリングすることなく、オープンソースのビッグデータ分析フレームワークを簡単に実行できます。AWS Black Belt Online Seminar では Amazon EMR Serverless の概要や使いどころについて説明します。 資料（ PDF ） 対象者 Amazon EMR の利用を検討されている方、利用されている方。 Amazon EMR Serverless について学びたい方。 サーバーレスで簡単にビッグデータ分析フレームワークを実行したい方。 本 BlackBelt で学習できること Amazon EMR Serverless を利用する上で知っておくべきサービスの概要と使いどころ、利用料金やサービスを利用する上での考慮事項について学ぶことができます。 スピーカー 川村 誠 ソリューションアーキテクト Amazon EMR コスト最適化編 Amazon EMR は Apache Spark、Apache Hive、Presto などのオープンソースフレームワークを使用して、ペタバイトスケールのデータ処理、相互分析、機械学習を行なう業界をリードするクラウドビッグデータソリューションです。AWS Black Belt Online Seminar では Amazon EMR を利用する際のコスト最適化について説明します。 資料（ PDF ）  対象者 Amazon EMR の利用を検討されている方、利用されている方。 Amazon EMR について学びたい方。 コストを抑えてビッグデータを活用したソリューション開発を検討されている方 本 BlackBelt で学習できること Amazon EMR の利用コストを最適化するために必要な Amazon EMR が提供する機能について学ぶことができます。 スピーカー 川村 誠 ソリューションアーキテクト Amazon EventBridge Pipes Amazon EventBridge Pipes は、イベントプロデューサーとイベントコンシューマーをポイントツーポイントで統合する機能です。統合のためのコードを記述したり、インフラを準備する必要はなく、迅速なイベント駆動アプリケーションの開発を可能にします。この動画では、EventBridge Pipes の基本的な使い方やユースケースについて解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon EventBridge について深く学びたい方 イベント駆動型アプリケーションの開発に興味をお持ちの方 ノーコード/ローコードでのシステム間連携を実現したい方 本 BlackBelt で学習できること EventBridge Pipes を活用した効率的なイベント駆動アプリケーションの開発方法 スピーカー 櫻谷 広人 パートナーソリューションアーキテクト AWS SAW – セルフサービスなトラブルシューティングと運用の自動化 Amazon Elastic Compute Cloud (Amazon EC2) – Windows 編 AWS SAW (AWS Support Automation Workflows) は AWS サポートチームが作成した自動化ランブックのコレクションです。AWS SAW を活用することで AWS 環境の一般的な問題の解決やログの収集、分析などを自動的に実行することができます。本セッションでは Amazon Elastic Container Cloud(Amazon EC2) で利用可能な 3つの SAW について概要や利用ユースケースなどの詳細を解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon EC2 – Windows を利用した運用を実施されている方 Amazon EC2 – Windows のトラブルシューティングの効率化に興味のある方 本 BlackBelt で学習できること AWS Nitro System 上で動作するインスタンスタイプをご利用いただくことのメリット AWS SAW を活用して EC2 インスタンスのトラブルシューティングを行う方法 AWS SAW を活用して EC2 インスタンスを AWS Nitro System 上で動作するインスタンスタイプへの変更するプロセスを簡略化する方法 スピーカー 和田 智優 クラウドサポートエンジニア AWS SAW – 旧世代から最新世代 (AWS Nitro System 世代) への移行タスクの自動化 Amazon Elastic Compute Cloud (Amazon EC2) – Linux 編 AWS SAW (AWS Support Automation Workflows) は AWS サポートチームが作成した自動化ランブックのコレクションです。AWS SAW を活用することで AWS 環境の一般的な問題の解決やログの収集、分析などを自動的に実行することができます。本セッションでは、Amazon Elastic Compute Cloud (Amazon EC2) において、AWS Nitro System 上で動作するインスタンスタイプへの移行を簡略化する 2 つの SAW ランブックをご紹介します。AWS Nitro System を用いることのメリットとこれらのランブックを用いた具体的な移行方法などの詳細を解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 旧世代のインスタンスタイプで Amazon EC2 – Linux を運用されている方 Amazon EC2 – Linux 環境の最新世代のインスタンスタイプへの移行に興味のある方 本 BlackBelt で学習できること AWS Nitro System 上で動作するインスタンスタイプをご利用いただくことのメリット AWS SAW を活用して EC2 インスタンスを AWS Nitro System 上で動作するインスタンスタイプへの変更するプロセスを簡略化する方法 「AWSSupport-CheckXenToNitroMigrationRequirements」ランブックの設定方法と活用方法 「AWSSupport-MigrateXenToNitroLinux」ランブックの設定方法と活用方法 スピーカー 渡邉 亮藏 シニアクラウドサポートエンジニア AWS SAW – セルフサービスなトラブルシューティング Amazon Simple Storage Service (Amazon S3) + AWS Lambda 編 AWS SAW (AWS Support Automation Workflows) は AWS サポートチームが作成した自動化ランブックのコレクションです。AWS SAW を活用することで AWS 環境の一般的な問題の解決やログの収集、分析などを自動的に実行することができます。本セッションでは Amazon Simple Storage Service (Amazon S3) と AWS Lambda で利用可能な 4 つの SAW について概要や利用ユースケースなどの詳細を解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon S3 や AWS Lambda を利用した運用を実施されている方 Amazon S3 や AWS Lambda、Amazon S3 と AWS Lambda を組み合わせて使用する際のトラブルシューティングの効率化に興味のある方 本 BlackBelt で学習できること Amazon S3、AWS Lambda 向けに利用可能な4つの AWS Support Automation Workflows(SAW) について利用ユースケース及び概要を理解する スピーカー 石川 直哉 / 藤原 弘樹 クラウドサポートエンジニア AWS への大規模移行のための戦略とベストプラクティス 多くのお客様は、ビジネスへの影響を最小限に抑えながら、できるだけ早く AWS に移行したいと考えています。本セミナーでは、大規模移行の初期段階にあるお客様を支援するため、大規模移行のベストプラクティスについて説明し、様々なお客様の移行事例や、お客様が移行中に得た教訓を紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 これから AWS への移行を予定している組織のリーダー層の方 大規模移行を担当するプロジェクトマネージャーやプロジェクトリーダーの方 本 BlackBelt で学習できること 大規模移行のベストプラクティス お客様の移行事例や、お客様が移行中に得た教訓 スピーカー 大熊　正浩 カスタマーソリューションマネージャー AWS Key Management Service Part.1 基礎編 AWS Key Management Service (AWS KMS) は、暗号化操作に使用される暗号鍵を簡単に作成および管理できるマネージドサービスです。本セッションでは、データ保護のユースケースに焦点を当てつつ、AWS KMS を利用したデータ暗号化の仕組み、暗号化を支える鍵管理の仕組み、そして、AWS KMS での暗号鍵の保管や管理の信頼性についての仕組みを学んでいただけます。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS 環境における保管中データ暗号化に関心をお持ちの AWS Key Management Service をご利用予定の方 AWS Key Management Service について理解を深めたい方 本 BlackBelt で学習できること データ保護のユースケースに焦点を当てつつ、AWS KMS を利用したデータ暗号化の仕組み、暗号化を支える鍵管理の仕組み、そして、AWS KMS での暗号鍵の保管や管理の信頼性についての仕組みを学んでいただけます。 スピーカー 平賀 敬博 セキュリティソリューションアーキテクト Amazon Elastic File System クラウドネイティブなワークロードに最適なファイルストレージサービスである Amazon Elastic File System (EFS) について詳しく紹介します。Amazon EFS の概要、便利な機能、パフォーマンス向上のポイントについて学習することができます。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS のグローバルインフラストラクチャやマネージドサービスの概念と AWS IAM や Amazon VPC などの基盤となるサービスについての知識が必要です。 Amazon EFS の活用を考えている方と Amazon EFS に詳しくなりたい方を対象としております。 本 BlackBelt で学習できること Amazon EFS の概要とレプリケーション機能やストレージの階層化機能といった便利な機能について学習できます。 Amazon EFS を利用する際、パフォーマンスを向上できるポイントについても解説します。 スピーカー 佐藤 真也 ソリューションアーキテクト Amazon Connect 注目 Update 10 選 !! (2023 年1月～ 2024 年1月 ) Amazon Connect が東京リージョンでローンチされてから5年が経ちたくさんの新機能が追加されてきました。それらの中から 2023 年1月から 2024 年1月までに発表された特に注目の Top10 について振り返っていきます。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon Connect ご利用中のエンドユーザー/パートナーの方 Amazon Connect のご利用をご検討中の方 Amazon Connect のアップデートを知りたい方 本 BlackBelt で学習できること 2023 年1月から 2024 年までに発表された Amazon Connect の注目アップデートを振り返ることができます。 スピーカー 黒木 裕貴 ソリューションアーキテクト

はじめに クラウド上でライブ動画の放送、ストリーミング、配信を行う場合、ワークフローの構築、テスト、セキュリティ対策に時間を費やしてきたことでしょう。Amazon Web Services (AWS) はこれらの作業を簡単にし、視聴者に高品質な体験を提供できます。しかし、ワークフローの継続的なモニタリングにどれだけ時間を割いてきましたか? モニタリングに取り組むと、各 AWS サービスに固有のアラートやダッシュボードがあることがわかります。しかし、メディアワークフロー全体のアラーム、メトリクス、リソースアラート、ヘルスを一覧で確認できるものはありません。リソース間の関係が明確でないと、問題が発生したときに時間のかかる手作業での切り分けや対処が必要になります。また、モニタリングに最適なメトリクスがわからず、複数のワークフローにアラームと通知ルールを展開・維持する事が必要になることもあります。 Workflow Monitor でライブ映像を検出し、可視化する これらの問題を解決するために、AWSは AWS Media Services と Amazon CloudFront をモニタリングできる Workflow Monitor を発表しました。この新機能はライブ映像のワークフローを検出、可視化、監視をするために設計されています。Workflow Monitor  はメディアワークロードのベストプラクティスモニタリングを展開・維持でき、 AWS マネジメントコンソール 、 AWS Elemental MediaLive API 、 AWS CDK からアクセスできます。 Workflow Monitor が検出可能なサービス。 わずか数クリックで、Workflow Monitor はメディアワークフローに関連するリソースを検出して可視化します。検出は対応するサービスから開始でき、リソースを選択すると Workflow Monitor はエンドツーエンドのグラフィカルなシグナルマップを作成します。シグナルマップにはワークフロー内のリソースを AWS Elemental MediaConnect 、 AWS Elemental MediaLive 、 AWS Elemental MediaPackage にわたって Amazon Simple Storage Service ( Amazon S3 )バケットと Amazon CloudFront ディストリビューションと共に表します。 シグナルマップ上では、一目で利用中のリソースとそれぞれのステータスを確認できます。このステータスは1秒ごとに更新されます。また、複数のコンソール画面を行き来することなく、各リソースがどのように接続されているかを確認できます。MediaLive チャネルや MediaPackage エンドポイントなどでは、利用可能な場合にライブ動画のサムネイル画像が動的に更新されます。 ライブ映像配信を示すシグナルマップ（画像をクリックすると拡大します）。 業界設計のベストプラクティスに基づいたモニタリングとアラートの適用とカスタマイズ シグナルマップを作成したら、 Workflow Monitor を使ってアラームと通知テンプレートを作成し、問題発生時にアラートを受け取れるようにします。モニタリングとアラートには Amzon CloudWatch アラームと Amazon EventBridge ルールを使用しますが、これらのリソース設定は Workflow Monitor コンソールで管理され、 Amazon CloudFormation を通じて展開されます。つまり、映像関連のエンジニアリングチームがこれらのサービスに精通する必要はありません。同様のワークロードのモニタリングを繰り返し行えるよう、 Workflow Monitor ではテンプレートとテンプレートグループの概念を採用しています。テンプレートは CloudWatch アラームまたは EventBridge ルールの設定を記述し、グループ化された階層オブジェクトを形成し、1つ以上のシグナルマップに関連付けられます。 テンプレートグループは、運用モデルに合わせて柔軟に分割できます。例えば、アラームテンプレートを重大度別、ワークフローの重要度に基づいて、または地域差に基づいてグループ化することができます。さらに、 Workflow Monitor では業界の専門家チームが作成したベストプラクティスの推奨事項をインポートして独自のアラームテンプレートグループに追加できます。インポート後はワークフローの要件に合わせてテンプレートを変更できます。例えば、映像フレームレートを 60fps から 50fps に変更したり、特定の許容範囲に基づいて継続時間のしきい値を調整したりすることができます。 1 つ以上のテンプレートグループをシグナルマップに関連付けると、 Workflow Monitor から素早くデプロイすることができます。バックグラウンドでは、CloudFormation Stack が作成され S3 に保存された後、展開されます。この Stack は後から参照したり、別の CloudFormation デプロイの一部として活用したりできます。展開完了後、ワークロードがモニタリング対象となります。 映像ワークフロー全体のステータスを一覧表示 Workflow Monitor の概要ページでは、すべてのシグナルマップのヘルスステータスを一目で確認できます。リストはさまざまな条件でフィルタリング可能です。例えば、ステータスでフィルタリングすれば、アラーム状態のシグナルマップのみを表示する「ペナルティボックス」を作成できます。この例外ベースのモニタリングは、シグナルマップが多数ある場合に、オペレーターの対応が必要なものだけを表示したいときに便利です。 概要ページには、各シグナルマップのステータスが表示されます（画像をクリックすると拡大します）。 モニタリング中のシグナルマップをクリックすると、アクティブなアラームがあるリソースを確認できます(リソースの背景が赤で示されます)。リソースを選択すると、そのリソースに適用されているアラームのみがシグナルマップのアラームリストに表示されるようフィルタリングできます。これにより、特定のワークフローで問題が発生している場所を素早く特定し、視覚的にデバッグできます。次に、組み込みリンクを使ってリソース自体、CloudWatch、CloudWatch Insights にすばやくアクセスし、ログをクエリできます。以前は、問題の切り分けと適切なコンソール画面への移動には、ワークフローに関する専門知識が必要でした。 モニタリングの一貫性を保つ Workflow Monitor は、ベストプラクティスモニタリングの作成と展開だけでなく、運用の一貫性の維持にも役立ちます。アラームテンプレートグループがシグナルマップに関連付けられると、アラームテンプレートはいつでも更新でき、新しい設定がシグナルマップに反映されます。例えば、アラームをノイズから守るためにしきい値を変更する必要がある場合、アラームが使用されているすべてのリソースでそのしきい値を個別に変更する代わりに、アラームテンプレートで 1 回変更してからモニタリングを再展開します。また、テンプレートグループによって、すべてのワークロードで効率的に変更を段階的に行い、適切なタイミングでデプロイすることができます。例えば、映像エンコーディングを AVC から HEVC に更新する際、特定のアラームのビットレート設定を調整する必要がある場合です。その際、個々のアラームを更新する代わりに、アラームテンプレート1か所ですべてを更新でき、準備ができたら展開します。 Workflow Monitor ユーザーガイド には、IAM ロールの提案も記載されています。アクセス許可境界により、オペレーターのために Workflow Monitor を安全に使用できるロールを作成できます。さらに、経験豊富なエンジニアがモニタリングを作成、更新、展開できるロールの提案もあります。これら 2 つのロールにより、 Workflow Monitor を安全に使用するための出発点が提供されます。 結論 AWS Media Services と Amazon CloudFront の Workflow Monitor は、ライブ動画のストリーム、放送、配信に関連するリソースを検出、可視化、監視します。リソース間の関係をグラフィカルなシグナルマップで表示するため、使用中のリソースとそれらの接続関係を確認できます。ベストプラクティスのモニタリングと通知テンプレートから始めるか、独自のテンプレートを作成し、問題発生時にアラートを受け取るよう映像をモニタリングすることができます。 詳しくは、 ユーザーガイド をお読みください。開始するには Workflow Monitor コンソール にアクセス下さい。 参考リンク AWS Media Services AWS Media & Entertainment Blog　(日本語) AWS Media & Entertainment Blog　(英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 翻訳は SA 金目、SA 石井が担当しました。原文は こちら をご覧ください。

様々な形式の大量の文書を分類し、その分析を行いたいと様々な業種の企業が考えています。これらの文書を手作業で処理して分類・情報抽出を行うことは、費用がかかり、ミスが生じやすく、スケーリングが難しい作業です。 生成 AI (generative artificial intelligence) 技術の発展により、文書の分類を自動化できる、インテリジェントドキュメント処理 (IDP) ソリューションが登場しました。こうしたソリューションは、非構造化された様々な企業文書に対して、低コストで効率的な分類機能を提供します。 文書を分類することは、IDP システムにおける重要な最初のステップです。文書を分類することで、種類に応じた次に取るべき一連のアクションを決定しやすくなります。例えば、請求審査プロセスでは、会計チームが請求書を受け取り、請求処理部門が契約書や文書を管理します。従来のルールエンジンや ML ベースの分類機能で文書を分類できますが、対応できる文書形式の種類に制限があり、新しい分類を都度追加する対応をすることがあります。詳細については、 こちらのブログ をご覧ください。 この投稿では、 Amazon Titan マルチモーダル埋め込みモデル を使用したドキュメント分類について説明します。このモデルを使えば、トレーニングを行うことなく、あらゆるタイプのドキュメントを分類することができます。 Amazon Titan マルチモーダル埋め込み Amazonは、 Amazon Bedrock で Amazon Titan マルチモーダル埋め込みモデル を導入しました。このモデルは画像とテキストの埋め込みベクトルを作成できるため、新たな文書分類ワークフローで使用する文書ベクトルの作成が可能になりました。 Amazon Titan マルチモーダル埋め込みモデルを使用することで、画像としてスキャンされた文書の最適化されたベクトル表現を生成します。画像とテキストの両方の意味を含む単一の数値ベクトルに変換することで、高速な索引、強力な文脈検索、正確な文書分類を可能にします。 ビジネスワークフローで新しい文書テンプレートや様式が現れた場合、 Amazon Bedrock API を呼び出すだけでそれらをベクトル化し、IDPシステムにおける文書分類を迅速に強化することができます。 ソリューションの概要 以下のドキュメント分類ソリューションを Amazon Titan マルチモーダル埋め込みモデルで検討しましょう。最適なパフォーマンスを得るには、自身の特定のユースケースや既存の IDP パイプラインの設定に対してソリューションをカスタマイズする必要があります。 このソリューションは、入力文書を既にインデックス化された文書と照合することで、埋め込みベクトルのセマンティック検索を使用して文書を分類します。分類には、以下の主要コンポーネントを使用します: 埋め込み – 埋め込み は、人間が複雑な情報を理解するように、単語、文章、画像などの情報を数値化して機械学習 (ML) や AI システムが理解するために用いる表現方式です。 ベクターデータベース – ベクターデータベース は、ベクトルを保存するために使われます。ベクターデータベースは、ベクトルを効率的にインデックス化し、整理することで、ユークリッド距離やコサイン類似度などの距離の尺度に基づいて類似したベクトル を高速に検索できるようにします。 セマンティック検索 – セマンティック検索は、入力クエリの文脈と意味、および検索されたコンテンツの関連性を考慮して動作します。ベクトル埋め込みは、テキストや画像の文脈上の意味を的確に捉え、保持するための効果的な方法です。このソリューションでは、アプリケーションがセマンティック検索を実行したい場合、まず検索文書をベクトルに変換します。次に、関連するコンテンツを含むベクターデータベースを照会して、最も類似したベクトルを見つけます。 ラベリングプロセスでは、請求書、銀行明細書、規定などのビジネス文書のサンプルが、Amazon Titan マルチモーダル埋め込みモデルを使用してベクトル化され、事前に定義されたラベルに対してベクトルデータベースに保存されます。Amazon Titan マルチモーダル埋め込みモデルはユークリッドの L2 アルゴリズムで学習されているため、良い結果を得るためには、ベクトルデータベースがこのアルゴリズムをサポートしている必要があります。 次の アーキテクチャ図は、 Amazon Simple Storage Service (Amazon S3) バケット内のドキュメントと Amazon Titan マルチモーダル埋め込みモデルを使って画像ギャラリーを作成する方法を表しています。 ワークフローは次のステップで構成されます: ユーザーまたはアプリケーションが、分類メタデータを付けたサンプル文書画像を文書画像ギャラリーにアップロードします。ギャラリー画像の分類には S3 プレフィックスまたは S3 オブジェクトメタデータが使用できます。 Amazon S3 オブジェクト通知イベントによって AWS Lambda 関数が呼び出されます。 Lambda 関数は、Amazon Bedrock を呼び出して Amazon Titan マルチモーダル埋め込みモデルを用いて、文書画像をベクトルに変換します。 文書の分類と共に、画像埋め込みがベクターデータベースに保存されます。 新しい文書を分類する必要がある場合、同じ埋め込みモデルを使用し、クエリ文書を埋め込みに変換します。その後、クエリの埋め込みを使ってベクトルデータベースに対してセマンティック類似検索が実行されます。 最も類似度が高い埋め込みに対応するラベルが、クエリ文書の分類ラベルとなります。 以下のアーキテクチャ図は、S3 バケット内のドキュメントに対して Amazon Titan マルチモーダル埋め込みモデルを使用し、画像分類を行う方法を示しています。 ワークフローは次のステップで構成されています: 分類が必要な文書を、入力用の S3 バケットにアップロードします。 Lambda 関数が Amazon S3 オブジェクト通知を受け取ります。 Lambda 関数が Amazon Bedrock API を呼び出して、画像をベクトルに変換します。 ベクターデータベースで、セマンティック検索を使用して一致する文書が検索されます。一致する文書の分類を使用して、入力文書を分類します。 入力文書を、ベクターデータベース検索から取得した分類を使用して、対象の S3 ディレクトリまたはプレフィックスに移動します。 自身の文書でこのソリューションをテストできるよう、Python の Jupyter ノートブックのサンプルを GitHub で公開しています。 前提条件 ノートブックを実行するには、 AWS アカウント が必要で、そのアカウントには Amazon Bedrock を使用するための適切な AWS Identity and Access Management (IAM) 権限が必要です。 また、Amazon Bedrock コンソールの Model access ページで、Amazon Titan マルチモーダル埋め込みモデルへのアクセスが許可されていることを確認してください。 実装 以下のステップでは、ユーザー入力を示すプレースホルダーを自身の情報に置き換えてください: ベクトルデータベースを作成します。このソリューションでは、インメモリ FAISS データベースを使用しますが、別のベクトルデータベースを使うこともできます。Amazon Titan のデフォルトの次元数は 1024 です。 index = faiss.IndexFlatL2(1024) indexIDMap = faiss.IndexIDMap(index) ベクターデータベースを作成した後は、サンプル文書を列挙し、それぞれの文書の埋め込みベクトルを生成して、ベクターデータベースに保存します。 文書を用いてテストしてください。次のコードのフォルダは、自身の文書を保存したフォルダに置き換えてください: DOC_CLASSES: list[str] = ["Closing Disclosure", "Invoices", "Social Security Card", "W4", "Bank Statement"] getDocumentsandIndex("sampleGallery/ClosingDisclosure", DOC_CLASSES.index("Closing Disclosure")) getDocumentsandIndex("sampleGallery/Invoices", DOC_CLASSES.index("Invoices")) getDocumentsandIndex("sampleGallery/SSCards", DOC_CLASSES.index("Social Security Card")) getDocumentsandIndex("sampleGallery/W4", DOC_CLASSES.index("W4")) getDocumentsandIndex("sampleGallery/BankStatements", DOC_CLASSES.index("Bank Statement")) Boto3 ライブラリを使用して、Amazon Bedrock を呼び出します。変数 inputImageB64 は自身の文書を表す base64 でエンコードされたバイト配列です。Amazon Bedrock からの応答には、埋め込みが含まれています。 bedrock = boto3.client( service_name ='bedrock-runtime', region_name ='Region' # AWS のリージョン名を指定 ) request_body = {} request_body["inputText"] = None # not using any text request_body["inputImage"] = inputImageB64 body = json.dumps(request_body) response = bedrock.invoke_model( body = body, modelId ="amazon.titan-embed-image-v1", accept ="application/json", contentType ="application/json") response_body = json.loads(response.get("body").read()) ドキュメントの種類を表すクラス ID を付与し、ベクターデータベースに埋め込みを追加します: indexIDMap.add_with_ids(embeddings, classID) ベクターデータベースに (ギャラリーを表す) 画像が格納されると、新しい文書との類似性を発見できます。たとえば、検索に使用される構文は次のとおりです。k = 1 は、FAISS から上位 1 件の結果を返すことを意味します。 indexIDMap.search(embeddings, k = 1) さらに、入力画像と検出された画像間のユークリッド L2 距離も返されます。画像が完全一致する場合、この値は 0 になります。この値が大きいほど、画像の類似度が低くなります。 追加の検討事項 このセクションでは、ソリューションを効果的に利用するための追加の考慮事項について説明します。データプライバシー、セキュリティ、既存システムとの統合、コスト見積もりなどが含まれます。 データプライバシーとセキュリティ AWS の 責任共有モデル は、Amazon Bedrock の データ保護 にも当てはまります。このモデルに従い、AWS は AWS Cloud の全てを実行するグローバルインフラストラクチャを保護する責任を負います。お客様はこのインフラストラクチャ上でホストされるコンテンツをコントロールする責任があります。あなたはお客様の1人として、利用する AWS サービスのセキュリティ設定とタスクを管理する責任があります。 Amazon Bedrock におけるデータ保護 Amazon Bedrock は、顧客のプロンプトを AWS モデルの学習や第三者との共有に使用することはありません。また、Amazon Bedrock は、サービスのログに顧客データを保存したり記録したりしません。加えて、モデルプロバイダーは、Amazon Bedrock のログや顧客のプロンプトにアクセス出来ません。その結果、Amazon Titan マルチモーダル埋め込みモデルを介して生成された埋め込みに使用される画像は、AWS モデルやサードパーティの学習に使用されたり、保存されたりすることはありません。さらに、タイムスタンプやログインしたアカウント ID などの他の使用データも、モデル学習から除外されます。 既存システムとの統合 Amazon Titan マルチモーダル埋め込みモデルは、ユークリッドの L2 アルゴリズムで学習しているので、使用するベクターデータベースはこのアルゴリズムと互換性がある必要があります。 コスト見積もり この投稿を書いている時点で、 Amazon Bedrock の価格 に基づき、Amazon Titan マルチモーダル埋め込みモデルをオンデマンド価格で使用した場合、このソリューションの推定コストは以下の通りです。 インデックス作成コスト – 画像ギャラリーに 1,000 枚の画像を想定すると、インデックス作成 1 回あたり $ 0.06 分類コスト – 毎月 10 万枚の入力画像に対して $ 6 クリーンアップ 利用しないときは、作成した Amazon SageMaker ノートブックインスタンス などのリソースを削除して、今後の課金を回避してください。 まとめ このポストでは、IDP ワークフローにおけるドキュメント分類について低コストなソリューションを構築するために、Amazon Titan マルチモーダル埋め込みモデルを使用する方法を説明しました。既存のドキュメントの画像ギャラリーを作成し、新しいドキュメントとの類似度検索を行って分類する手順を示しました。また、ドキュメント分類にマルチモーダル画像埋め込みを利用することで、様々な様式の文書に対応でき、スケーラブルで低レイテンシーという利点があることを説明しました。 ビジネスワークフローで新しいドキュメントテンプレートと様式が導入されると、開発者は Amazon Bedrock API を呼び出して動的にベクトル化し、IDP システムに追加して文書分類機能を迅速に強化できます。これにより、さまざまな構造化されていない企業の文書に対応できる、低コストで無限に拡張可能な分類が可能になります。 全体として、この記事は、Amazon Titan マルチモーダル埋め込みを使用して IDP ワークフローにおける文書分類のための低コストのソリューションを構築するための指針を提供しています。 次のステップとして、 Amazon Bedrock とは を確認し、サービスの利用を開始できます。また、 AWS Machine Learning Blog の Amazon Bedrock をフォローすると、Amazon Bedrock の新機能とユースケースの最新情報を入手できます。 本記事は、 Cost-effective document classification using the Amazon Titan Multimodal Embeddings Model を翻訳したものです。翻訳は Technical Account Manager の Hiroaki Hattori が担当しました。 著者について Sumit Bhati は、AWS のシニアカスタマーソリューションマネージャーです。企業顧客のクラウド移行を加速させることを専門としています。Sumit は、移行の加速からワークロードのモダナイゼーション、革新的な実践のファシリテーションまで、顧客のクラウド導入のあらゆる段階でお客様をサポートすることに尽力しています。 David Girling は 20 年以上の経験を持つシニア AI/ML ソリューションアーキテクトで、企業システムの設計、主導、開発に携わっています。David は、顧客がデータを活用しユースケースに合わせてこれらの高機能サービスを学び、革新し、利用することを支援する専門チームの一員です。 Ravi Avula は、エンタープライズアーキテクチャに重点を置く AWS のシニアソリューションアーキテクトです。Ravi は 20 年間にわたるソフトウェアエンジニアリングの経験があり、決済業界でソフトウェアエンジニアリングおよびソフトウェアアーキテクチャのリーダーシップを数多く担ってきました。 George Belsian は、AWS のシニアクラウドアプリケーションアーキテクトです。顧客のモダナイゼーションとクラウド導入を加速させることに注力しています。ジョージは顧客チームと協力して、革新的でスケーラブルなソリューションの戦略立案、アーキテクチャ設計、開発を行っています。

この記事は Building Developer Portals with Backstage and Amazon EKS Blueprints を翻訳したものです。 現代のソフトウェア開発環境の複雑さにより、近年、 内部開発者プラットフォーム （IDP）の作成と採用が進んでいます。IDP の目的は、仕事を遂行するために多数のツールや製品を使用する必要があるソフトウェア開発者の認知負荷を軽減することです。このような断片化は、時間のかかるコンテキストの切り替えを引き起こし、新規参加者の学習曲線を険しくします。IDP は、統一されたフロントエンドを提供することで、このような欠点に対処します。このフロントエンドでは、さまざまなツールや製品が1つのカタログにまとめられ、開発者が利用できるようになっています。 Backstage は Spotify で発足した、 2020年3月にオープンソース化された デベロッパーポータル（DP）です。DP は、IDP の機能を探索し、アクセスするためのユーザーインターフェースの役割を果たします。DP として、Backstage は企業内のさまざまな種類のエンティティを一元管理します： 例えば、API、リソース、ユーザー、チーム、ドキュメントなどです。また、例えば AWS の Proton プラグイン のように、追加のサードパーティコンポーネントを同じコンテキストでプラグインして利用できる拡張可能なアーキテクチャも特徴です。 Amazon EKS Blueprints for CDK （以後、Amazon EKS Blueprints と呼ぶ）は、Infrastructure as Code（IaC）モジュールのセットで、アカウントやリージョンをまたいで、完全な Amazon Elastic Kubernetes Service（Amazon EKS）クラスタを最小限のコードで迅速にブートストラップするのに役立ちます。当初はAWSで開発され、 2022年4月にオープンソース化 されました。アドオンは Amazon EKS Blueprint の構成要素で、クラスタのコンテキスト内で実行される Kubernetes アドオンの管理 を支援します。 このブログでは、Amazon EKS Blueprints Patterns の助けを借りて、Amazon EKS Blueprints 用の Backstage アドオンをインストールして設定する方法を紹介します。このアドオンを使用すると、新しくデプロイされた Amazon EKS クラスターに Backstage アプリケーションを効果的にインストールできます。Elastic Load Balancing（Amazon ELB）を介して Backstage にアクセスできるようになります。このブログでは、Amazon EKS Blueprints と Backstage の間の緊密な統合、例えば、環境、パイプラインのステータス、チームのオンボーディングなどを表示および制御することについては触れていません。 ソリューション概要 次の図は、このブログで説明する完全な解決策を示しています： Backstage のビルド済み Docker イメージが必要で、お好みのプラグインを追加するなどして、お好みの構成にしてください。このステップと次のステップを実行する方法に関する技術的な詳細については、この投稿の後の「Backstage のデプロイ」のセクションを参照してください。 Backstage のパターンはこのようになります： このイメージを新しい Amazon EKS クラスタにデプロイします。 Amazon EKS クラスタの VPC に、新しい Amazon Relational Database Service (Amazon RDS) for PostgreSQL インスタンスを作成します。 上記のデータベースの認証情報を AWS Secrets Manager でシークレットとして設定します。 データベースの認証情報を反映した External Secret を作成します。 External Secret から Kubernetes Secret を作成し、環境変数 $POSTGRES_USER と $POSTGRES_PASSWORD として Backstage に読み込ませます。 AWS Load Balancer Controller アドオン をインストールし、Backstage Helm チャートの Ingress に記載されているルールを実装して、 Application Load Balancer （ALB）をデプロイします。 ALB 用の証明書を作成します。 前提条件 この記事のステップを完了するには、以下のものが必要です： AWS アカウント aws-cli  、 aws-cli の設定 make Node.js npm Docker AWS Cloud Development Kit (CDK)、選択したアカウントとリージョンでの bootstrap また、ここに示す AWS マネジメントコンソールの画像と同様に、 Amazon Route 53 のパブリックホストゾーンの1つに保持されるドメイン名が必要です： Amazon EKS Blueprints Pattern をクローンする お気に入りのコマンドライン・インターフェース（CLI）を開き、EKS Blueprints Patterns GitHub リポジトリをクローンします： $ git clone https://github.com/aws-samples/cdk-eks-blueprints-patterns.git Backstage をデプロイする EKS Blueprints Patterns リポジトリの docs フォルダ にある Backstage ファイルの指示に従ってください。必要な手順は以下の通りです： Backstage アプリケーション を作成し、 Docker イメージをビルド します。 Amazon Elastic Container Registry （Amazon ECR）とリポジトリの作成します。 新しく作成したリポジトリに Docker イメージをアップロードします。 AWS CLI プロファイルの一部としてアカウントとリージョンを設定し、CDK コンテキストに必要なパラメータを入力します： 説明 パラメータ 説明 backstage.namespace.name Backstage をデプロイする Kubernetes 名前空間 – 例. “backstage” backstage.image.registry.name イメージレジストリ – 例. Amazon Elastic Container Registry (ECR)： “{account}.dkr.ecr.{region}.amazonaws.com” backstage.image.repository.name 上記のレジストリにあるリポジトリ – 例. “backstage” backstage.image.tag.name Backstageイメージのタグ – 例. “latest” backstage.parent.domain.name サブドメインと関連証明書が作成されるドメイン名 – 例. “example.com” backstage.subdomain.label Backstage に割り当てるサブドメインの作成に使用するラベル – 例. “example.com” この場合、最終的なサブドメインは例えば次のようになる – 例. “backstage.example.com” backstage.hosted.zone.id あなたのドメイン名を保持する Route 53 の Hosted Zone を表す20文字の文字列 backstage.certificate.resource.name 証明書リソースに割り当てられる名前 – 例. “backstage-certificate” backstage.database.resource.name データベースリソースに割り当てられる名前 – 例. “backstage-database“ backstage.database.instance.port 新しい Backstage データベースに割り当てるポート – 例. 5432 backstage.database.secret.resource.name Secret リソースに割り当てられる名前（CDK内での参照として使用されます – 例. “backstage-database-credentials” backstage.database.username データベースのユーザー名 – 例. “postgres” backstage.database.secret.target.name Kubernetes マニフェストで Secret に割り当てられる名前 – 例. “backstage-database-secret”   Amazon EKS Blueprints Patterns ドキュメントの説明に従ってデプロイします。 $ make deps $ npm i $ make build $ make pattern backstage deploy 最後に、ウェブブラウザで {"parent.domain.name"}.{"subdomain.label"} に移動します。Backstage アプリケーションの設定によっては、以下のような画面が表示されます： コード解析 実際の Backstage アドオンは Amazon EKS Blueprints リポジトリの下でホストされている一方で、アドオンを構成して必要なリソースをデプロイする方法を示す Backstage パターンは Amazon EKS Blueprints Patternsリポジトリ の下でホストされていることに注意することが重要です。 このアドオンは、 GitHubで公開されている Backstage Helmチャートに依存しています。 その値を通して、Helm チャートを以下のように設定する必要があります： Ingress パラメータを設定する Backstage アプリケーションの Docker イメージの場所を提供する Backstage アプリケーションに渡す： 割り当てるサブドメイン データベース・エンドポイントと環境変数（後にデータベース認証情報に設定される) 実際のデータベース認証情報を保持するシークレット名 Ingress の最も注目すべき構成は、Certificate の Amazon リソース名（ARN）です。 デフォルトのインメモリ SQLite データベースではなく、PostgreSQL を使用することで、 より優れたスケーラビリティ 、 並行性 、 集中化 、 制御 を実現しています（詳細については Backstage ガイド にアクセスしてください）。この認証情報は、Secret から取得した環境変数を介して Backstage アプリケーション Pod に注入されます。チャートは、Secret名に関する情報を backstage.extraEnvVarsSecrets 値から取得し、Kubernetes Deployment マニフェストのenvFromセクションに設定します： kind: Deployment … containers: … envFrom: {{- range .Values.backstage.extraEnvVarsSecrets }} … したがって、アドオンが期待するパラメータは以下の通りとなります： subdomain: string, certificateResourceName: string, imageRegistry: string, imageRepository: string, imageTag?: string, databaseResourceName: string, databaseSecretTargetName: string このパターンは、アドオンの依存関係を提供します。 Resource Provider ( DatabaseInstanceCredentialsProvider ) は、 AWS Secrets Manager (ASM)にデータベースの認証情報を作成し、保存します。 2番目のリソースプロバイダ( DatabaseInstanceProvider )は、クラスタVPC内にAmazon RDS for PostgreSQLデータベースインスタンスを作成し、コンテキストからASMのシークレット名を取得し、作成時にそれをデータベースに渡します。 External Secrets アドオン を活用するアドオン（ BackstageSecretAddOn ）は、 ASM を指す ClusterSecretStore オブジェクトと、ASM から認証情報を取得する ExternalSecret を作成し、 POSTGRES_USER と POSTGRES_PASSWORD をキーとする新しい Kubernetes Secret に注入します： … data: [ { secretKey: "POSTGRES_PASSWORD", remoteRef: { key: databaseInstanceCredentialsSecretName, property: "password" } }, { secretKey: "POSTGRES_USER", remoteRef: { key: databaseInstanceCredentialsSecretName, property: "username" } }, ], … 前回説明したように、Secret 内に保持されている認証情報は、環境変数 $POSTGRES_USER と $POSTGRES_PASSWORD としてポッドに渡されます。 3つ目のResource Provider( CreateCertificateProvider )は、Amazon Route 53 Hosted Zoneにサブドメインを作成し、AWS Certificate Manager(ACM)に関連証明書を作成します： blueprints.EksBlueprint.builder() … .resourceProvider(blueprints.GlobalResources.HostedZone, new blueprints.ImportHostedZoneProvider(props.hostedZoneId, props.parentDomain)) .resourceProvider(props.certificateResourceName, new blueprints.CreateCertificateProvider("elb-certificate", subdomain, blueprints.GlobalResources.HostedZone)) 証明書は、コンテキストからBackstageアドオンによって取得され、その ARN が抽出され… const annotations = { … "alb.ingress.kubernetes.io/certificate-arn": clusterInfo.getResource<ICertificate>(helmOptions.certificateResourceName)?.certificateArn }; … と Ingressに割り当てられます： setPath(values, "ingress.annotations", annotations); AWS マネジメントコンソール の Route 53 セクションに、このスクリーンショットのように新しいサブドメインレコードが表示されます： 証明書は AWS Certificate Manager セクションに表示されます： 今から何ができるでしょうか？ Backstage は、場所に関係なく組織のリソースを単一の画面で表示できるほか、開発ツールの導入や使用開始を簡単に行うことができます。また、バックエンドやフロントエンド・アプリケーションなどの新しいリソースを、ポータルから簡単に作成することもできます。 Developer Platform のセットアップが完了したら、その利点を活かして Software Catalog の作成から始めましょう。Software Catalog を使用すると、環境内のすべてのソフトウェア（サービス、Web サイト、ライブラリ、パイプラインなど）の所有権とメタデータを一元的に追跡できます。カタログは、ソース・コントロールに保存されたメタデータ YAML ファイルから作成され、Backstage にさまざまな方法で登録され、開発者に包括的なビューで表示されます。 検討したいもう 1 つの機能は、エンジニアリング チームがコンポーネントを構築し、チームのベスト プラクティスに合わせた新しいプロジェクトを迅速に作成できるようにする Software Templates です。これは、エンジニアリングチームがコンポーネントを構築し、チームのベストプラクティスに沿った新しいプロジェクトを迅速に作成することを可能にします。これにより、エンジニアリングチームは、車輪の再発明を避け、意思決定を少なくし、よりコアな活動に集中することができます。Software Templates は Golden Paths の概念の基礎であり、バックエンド サービス、Web アプリケーション、CI/CD パイプラインなどを構築するための Backstage としてのやり方であり、支持される方法です。Golden Paths を使えば、慣習や標準を法的に制定するのではなく、チームが新しいプロジェクトを適切な状態で簡単に始められるようにすることができます。 さらに、 TechDocs を使ってドキュメントを作ることもできる。これにより、関連するコードと同じ場所に保存されるMarkdown ファイルを書くことができます。これらのファイルは、Backstage でクリーンかつ明確に表示されます。 Backstage の詳細なドキュメントや機能、ユースケースについては、 Backstage のウェブサイト をご覧ください。 後片付け 今後の課金を避けるため、 make pattern backstage destroy コマンドを実行してください。 まとめ この投稿では、Amazon EKS Blueprints の Backstage アドオンと Amazon EKS Blueprints Patterns の Backstage パターンを使用して、ビルド済みで設定済みの Backstage アプリケーションをデプロイする方法を紹介しました。また、依存関係を含む Backstage を実行する完全なソリューションを実現するために、パターンの設定パラメーターと、パターンがリソースプロバイダーや他のアドオンをどのように結び付けるかについて説明しました。 Riccardo Freschi Riccardo Freschi は AWS のシニアソリューションアーキテクトで、アプリケーションモダナイゼーションにフォーカスしています。パートナーや顧客と密接に連携し、既存アプリケーションのリファクタリングやクラウドネイティブでの新規アプリケーションの構築を通じて、AWS クラウドへの移行における IT ランドスケープの変革を支援しています。 本記事は、Riccardo Freschi による “ Building Developer Portals with Backstage and Amazon EKS Blueprints ” を翻訳したものです。翻訳はソリューションアーキテクトの堀 竜慈が担当しました。

私たちは 生成人工知能 (AI) の時代、つまり、急速なイノベーションの時代に生きています。Anthropic が 3 月 4 日に Claude 3 基盤モデル (FM) を発表したとき、弊社は即日、スキルとスピードのバランスがとれたモデルである Claude 3 Sonnet を Amazon Bedrock で利用できるようにしました。3 月 13 日、弊社は Amazon Bedrock で Claude 3 Haiku モデル をリリースしました。これは、ほぼ瞬時の応答性を実現する、Claude 3 ファミリーの中で最も高速かつ最もコンパクトなモデルです。 4月16日、 Anthropic の Claude 3 Opus が Amazon Bedrock で 利用可能になったことをお知らせします。これは、非常に複雑なタスクで市場最高レベルのパフォーマンスを発揮する、最もインテリジェントな Claude 3 モデルです。オープンエンドのプロンプトや、これまでに経験のないシナリオに、驚くべき流暢さと人間のような理解力で対応でき、汎用知能のフロンティアをリードします。 Amazon Bedrock で Claude 3 Opus が利用できるようになったことで、企業は生成 AI アプリケーションを構築してタスクを自動化したり、ユーザー向けアプリケーションを通じて収益を生み出したりできるほか、複雑な財務予測を実行し、さまざまなセクターにわたる研究開発を加速することもできます。他の Claude 3 ファミリーと同様に、Opus は画像を処理してテキスト出力を返すことができます。 Claude 3 Opus では、難しいオープンエンドの質問に関して、Claude 2.1 に比べて推定 2 倍の精度の向上を実現しています。これにより、誤った応答の可能性が低減されます。企業のお客様は、ヘルスケア、金融、法律調査などのさまざまな業界で Claude を利用しているため、高い安全性とパフォーマンスを実現には精度の向上が不可欠です。 Claude 3 Opus のパフォーマンス Claude 3 Opus は、 学部レベルの専門知識 (MMLU)、 大学院レベルの専門的推論 (GPQA)、 基礎数学 (GSM8K) など、AI システムの一般的な評価ベンチマークのほとんどで競合製品を上回るパフォーマンスを発揮しています。複雑なタスクにおいて高いレベルの理解力と流暢さを示し、汎用知能のフロンティアをリードします。 出典: https://www.anthropic.com/news/claude-3-family Claude 3 Opus モデルでサポートされているユースケースをいくつかご紹介します。 タスクオートメーション : API、データベース、インタラクティブコーディングにわたる複雑なアクションの計画と実行 研究 : ブレーンストーミングと仮説の生成、研究レビュー、創薬 戦略 : チャートとグラフ、財務と市場動向、予測の高度な分析 Claude 3 Opus の特徴や機能の詳細については、 Bedrock での Anthropic の Claude ページと、Amazon Bedrock ドキュメントの「 Anthropic Claude models 」をご覧ください。 Claude 3 Opus の動作 Anthropic のモデルを初めて使用する場合は、 Amazon Bedrock コンソール にアクセスして、左下のペインで [モデルアクセス] を選択します。 Claude 3 Opus のためのアクセスを個別にリクエストします。 コンソールで Claude 3 Opus をテストするには、左側のメニューペインの [プレイグラウンド] で、 [テキスト] または [チャット] を選択します。その後、 [モデルを選択] を選択し、カテゴリとして [Anthropic] 、モデルとして [Claude 3 Opus] をそれぞれ選択します。 さらに多くの Claude プロンプトのサンプルをテストするには、 [サンプルをロード] を選択します。四半期レポートの分析、ウェブサイトの構築、横スクロールゲームの作成など、Claude 3 Opus に固有のサンプルを表示および実行できます。 また、 [API リクエストを表示] を選択すると、 AWS コマンドラインインターフェイス (AWS CLI) や AWS SDK でコードサンプルを使用してモデルにアクセスすることもできます。AWS CLI コマンドのサンプルを次に示します。 aws bedrock-runtime invoke-model \ --model-id anthropic.claude-3-opus-20240229-v1:0 \ --body "{\"messages\":[{\"role\":\"user\",\"content\":[{\"type\":\"text\",\"text\":\" Your task is to create a one-page website for an online learning platform.\\n\"}]}],\"anthropic_version\":\"bedrock-2023-05-31\",\"max_tokens\":2000,\"temperature\":1,\"top_k\":250,\"top_p\":0.999,\"stop_sequences\":[\"\\n\\nHuman:\"]}" \ --cli-binary-format raw-in-base64-out \ --region us-east-1 \ invoke-model-output.txt Claude 3 モデルのリリースに関する以前の記事で述べたように、画像処理などの一部の Claude 3 モデルの機能には、新しい Anthropic Claude Messages API 形式 を使用する必要があります。 Anthropic Claude Text Completions API を使用しており、Claude 3 モデルを使用したい場合は、 Text Completions API からアップグレード する必要があります。 私の同僚の Dennis Traub と Francois Bouteruche は、AWS SDK を使用して Amazon Bedrock 用のコードサンプル を作成しています。Amazon Bedrock で Claude 3 を呼び出して テキストを生成 したり、 画像分析用のマルチモーダルプロンプト を実行したりする方法については、Amazon Bedrock のドキュメントをご覧ください。 Messages API リクエストを送信してテキストを生成するサンプル JavaScript コードを次に示します。 // claude_opus.js - Messages API を使用して Anthropic Claude 3 Opus を呼び出します。 import { BedrockRuntimeClient, InvokeModelCommand } from "@aws-sdk/client-bedrock-runtime"; const modelId = "anthropic.claude-3-opus-20240229-v1:0"; const prompt = "Hello Claude, how are you today?"; // 新しい Bedrock Runtime クライアントインスタンスを作成します const client = new BedrockRuntimeClient({ region: "us-east-1" }); // モデルのためにペイロードを準備します const payload = { anthropic_version: "bedrock-2023-05-31", max_tokens: 1000, messages: [{ role: "user", content: [{ type: "text", text: prompt }] }] }; // ペイロードを使用して Claude を呼び出し、応答を待ちます const command = new InvokeModelCommand({ contentType: "application/json", body: JSON.stringify(payload), modelId }); const apiResponse = await client.send(command); // Claude の応答をデコードして出力します const decodedResponseBody = new TextDecoder().decode(apiResponse.body); const responseBody = JSON.parse(decodedResponseBody); const text = responseBody.content[0].text; console.log(`Response: ${text}`); これで、AWS SDK for JavaScript Runtime Client for Node.js をインストールし、 claude_opus.js を実行できるようになりました。 npm install @aws-sdk/client-bedrock-runtime node claude_opus.js さまざまなプログラミング言語の他の例については、 「Amazon Bedrock ユーザーガイド」のコードサンプルのセクション を確認し、Community.aws にて Anthropic Claude でシステムプロンプトを使用する 方法を学習してください。 今すぐご利用いただけます Claude 3 Opus は現在、米国西部 (オレゴン) リージョンでご利用いただけます。今後の更新については、 リージョンの詳細なリスト をご覧ください。 Amazon Bedrock コンソール で Claude 3 Opus を今すぐお試しいただき、 AWS re:Post for Amazon Bedrock に、または AWS サポートの通常の連絡先を通じて、フィードバックをぜひお寄せください。 – Channy 原文は こちら です。

コンテナはアプリケーション開発を加速し、環境間でのデプロイの一貫性を高めるため、組織のプロダクティビティとアジリティを向上させることができます。 Amazon Elastic Container Service (Amazon ECS) などの AWS コンテナサービスは、アプリケーションの管理を簡素化し、イノベーションとビジネスニーズに注力できるようサポートします。 顧客体験はすべての組織にとって、アプリケーションのパフォーマンスを測る上で最も重要な指標です。さまざまなリクエストのパターンに対して、エンドユーザーへの信頼性と一貫性のある体験を維持することは、すべての組織が直面する課題です。ベストプラクティスとして、Amazon ECS サービスでタスクの望ましい数を自動的に増やす (スケールアウトする) ことや、減らす (スケールインする) ことができます。これにより、トラフィックの急増に対して手動でリアルタイムに対応する必要がなくなります。オートスケーリングを活用し、実際に必要なリソースにのみ支払うことで AWS サービス利用時の使用量とコストを適切に制御することができます。 AWS では、Amazon ECS サービスをオートスケーリングするための複数の機能を利用できます。適切なオプションを選択することで、アプリケーション全体の信頼性が向上し、運用コストと複雑さが軽減され、エンドユーザエクスペリエンスが向上します。この投稿では、まず AWS Application Auto Scaling について学び、これを使って Amazon ECS サービスのオートスケーリングを設定する方法を説明します。次に、アプリケーションオートスケーリングに使用できる Amazon ECS Service Connect と AWS Distro for OpenTelemetry (ADOT) についても説明します。 アプリケーションのオートスケーリング サービスのオートスケーリングを使用すると、お使いの Amazon ECS サービス内のタスク数を自動的に増減できます。Amazon ECS はこの機能を提供するために、Application Auto Scaling サービスを利用しています。デフォルトでは、Amazon ECS は Amazon CloudWatch に CPU とメモリの使用状況を公開します。これらの CloudWatch メトリクスまたはその他のカスタムメトリクスを使って、サービスをスケーリングできます。Amazon ECS サービスのオートスケーリング機能では、以下のようなオートスケーリングの種類がサポートされています。 ターゲット追跡スケーリングポリシー – 特定のメトリクスのターゲット値に基づいて、サービスが実行するタスク数を増減できます。例えば、CPU 使用率が 75% を超えた場合はサービスにタスクを追加し、CPU 使用率がターゲット値の 75% を下回った場合はタスクを削除するというスケーリングポリシーを定義できます。時には、アプリケーション固有のメトリクス (リクエスト数など) や、他の AWS サービスが公開したメトリクスに基づいてスケーリングしたい場合もあるでしょう。その際は、算術演算や関数を用いて、ターゲット追跡ポリシーで使用するメトリクスをカスタマイズできます。カスタムメトリクスに基づくオートスケーリングの詳細については、 こちらの記事 を参照してください。次のスクリーンショットはターゲット追跡スケーリングポリシーの設定例を示しています。 ステップスケーリングポリシー – アラームの閾値超過の程度によって異なる一連のスケーリング調整を行うことをステップ調整と呼びます。これに基づいて、サービスが実行するタスク数を増減できます。ステップスケーリングでは、メトリクスのしきい値と、追加または削除するリソース量を選択できます。例えば、CPU 使用率が 50% から 75% の場合はタスクを 2 つ増やし、25% 未満の場合は 2 つ減らすというスケーリングポリシーを定義できます。次のスクリーンショットは、ステップスケーリングポリシーの設定例を示しています。 スケジュールされたスケーリング – サービスで実行されるタスクの数を、日付と時刻に基づいて増減させることができます。例えば、ピーク時にサービス中のタスク数を増加させ、オフピーク時にタスク数を減らすよう、スケジュールを設定できます。スケジュール設定に基づくスケーリングは、 AWS コマンドラインインターフェース (AWS CLI) で設定できます。スケジュール設定に基づくスケーリングとスケーリングポリシーを組み合わせて使うと、事前のスケーリングアプローチと事後のスケーリングアプローチの両方のメリットを得られます。スケジュールされたスケーリングアクションを実行した後、スケーリングポリシーが容量をさらにスケーリングする必要があるかどうかを判断します。これにより、アプリケーションの負荷に対応するのに十分な容量を確保できます。 サービスのオートスケーリングは Amazon ECS サービスを簡単にスケーリングできる仕組みで、 AWS マネジメントコンソール 、AWS CLI、AWS SDK を使ってスケーリングを設定できます。 スケーリングポリシーは、クールダウン期間をサポートしています。これは、スケーリングアクションが有効になるまでの待機秒数です。スケールアウト時にタスクは継続的に増加しますが、スケールイン時にはタスクが慎重に減少します。アプリケーションの可用性を守るために、クールダウン期間が終了するまでスケールイン活動はブロックされます。 次の図は、ターゲット追跡スケーリングポリシーの動作例を示しています。 Application Auto Scaling の料金 この機能を使用するための追加料金はかかりません。アプリケーションを保管および実行するために作成する AWS リソースの料金のみがかかります。利用したリソースに対してのみ課金され、最小利用料金はありません。 Amazon ECS Service Connect Amazon ECS Service Connect は、アプリケーションコードの変更なしに、シームレスなサービス間接続性と、リッチなトラフィックテレメトリを提供します。これは、Amazon ECS 内にサービスディスカバリとサービスメッシュの両方を構築することで実現されます。Service Connect 構成を使用すると、Amazon ECS は新しいタスクを起動するたびに、サイドカープロキシコンテナを各タスクに自動的に注入します。Amazon ECS はこの構成を自動的に管理します。 低レイテンシーが要件で、新規クライアント数、受信リクエスト数、エラー率、失敗した TLS 接続数などのメトリクスを監視する必要がある場合は、Amazon ECS Service Connect の設定をお勧めします。Amazon ECS Service Connect は、トラフィックのルーティングと管理のために、サービスメッシュの集中管理アーキテクチャを使用します。Amazon ECS Service Connect によって作成されるトラフィック監視のためのメトリクスは、Amazon ECS コンソールから直接確認でき、これらのメトリクスは CloudWatch にも送信されます。一度 CloudWatch でメトリクスを利用できるようになれば、それらを使って Amazon ECS サービスタスクのオートスケーリングを設定することができます。 以下は、Amazon ECS Service Connect を通じて提供され、最も一般的に使用されるメトリクスです。また、 完全なリストはこちら になります。 ActiveConnectionCount クライアントからのアクティブな同時接続の総数 NewConnectionCount クライアントから確立された新しい接続の総数 TargetResponseTime アプリケーションのリクエスト処理レイテンシ ClientTLSNegotiationErrorCount TLS 接続が失敗した総数 HTTPCode_Target_5XX_Count HTTP レスポンスコード 500 から 599 の数 Amazon ECS Service Connect を使用すると、 AWS Cloud Map が提供する名前空間を使って論理名でサービスを参照および接続でき、ロードバランサーをデプロイして構成することなく、Amazon ECS タスク間でトラフィックを自動的に分散できます。さらに、Amazon ECS コンソールには、運用の利便性向上と簡易なデバッグのための、リアルタイムのネットワークトラフィックメトリクスを表示できる便利なダッシュボードが用意されています。次の図では、Amazon ECS Service Connect でのリクエストの流れと、メトリクスが CloudWatch に公開される様子を示しています。 以下のスクリーンショットは、Service Connect によって測定されたトラフィックの状況を示すトラフィックヘルスビューを示しています。このビューには、Service Connect を経由するアクティブな接続数と、サービス内のすべてのタスクに対する応答の HTTP ステータスコードが表示されます。Amazon ECS Service Connect は、インフラストラクチャのプロビジョニング、コードのデプロイ、サービスの監視のために、 AWS CloudFormation 、 AWS Cloud Development Kit (AWS CDK) 、 AWS Copilot 、 AWS Proton で完全にサポートされています。 Amazon ECS Service Connect の料金 Amazon ECS Service Connect によるサービスディスカバリ、接続機能、トラフィックテレメトリについての追加料金はありません。 Amazon ECS Service Connect エージェント が消費するリソース分のみの料金がかかります。お勧めとしては、Service Connect コンテナに 256 CPU ユニットと 64 MB のメモリを追加することです。これは別途設定するものではありませんが、タスク割り当て時に考慮されます。アイドル時の消費は約 100 CPU ユニットと 40 MB のメモリです。 AWS Distro for OpenTelemetry (ADOT) OpenTelemetry (OTEL) コレクターには、CloudWatch などさまざまなデータソースにデータをエクスポートするコンポーネントが含まれています。OpenTelemetry は、オープンソースのテレメトリ収集プロジェクトで、様々なアプリケーションやインフラストラクチャからデータを収集して単一の出力形式で提供します。 AWS Distro for OpenTelemetry Collector (ADOT コレクター) は、AWS がサポートしている OpenTelemetry コレクターで、AWS から配布およびサポート提供されています。このコンポーネントにより、テレメトリデータを CloudWatch やその他のサポート対象な監視ソリューションに送信できます。 Amazon ECS で ADOT を利用してオブザーバビリティを有効にするには、以下の 2 つのステップが必要です。 一度の計装で関連ログ、メトリクス、トレースを 1 つ以上のモニタリングソリューションに送信できます。プログラミング言語用の エージェント を有効化すれば、コードを変更せずに自動計装を使用できます。 以下の 2 つの方法のうち、いずれかを使用して ADOT Collector をデプロイします。 サイドカーパターン（タスク内のアプリケーションコンテナとは別のコンテナに ADOT Collector をデプロイする方法） Amazon ECS サービスパターン（独立した Amazon ECS サービスとして ADOT Collector をデプロイする方法） ADOT コレクタは ECS メタデータエンドポイント をスクレイピングし、コンテナの CPU、メモリ、ネットワーク、ディスク使用量などのメトリクスを収集します。ADOT を CloudWatch と統合することで、これらのメトリクスを CloudWatch コンソールから直接収集、分析、可視化できます。次の図は、ADOT SDK を使用してアプリケーションを計装する方法、ADOT コレクタによるメトリクスのスクレイピング方法、および CloudWatch EMF エクスポーターによる メトリクス の CloudWatch への送信方法に関するハイレベルのフローを示しています。 ADOT コレクターには、メトリクスを収集するためのデフォルト設定が備わっています。このデフォルト設定により、メトリクスパイプラインで AWS EMF エクスポーター ( awsemfexporter ) が有効になります。これは OTEL メトリクスを CloudWatch が受け付ける形式のバッチログに変換してから CloudWatch に送信します。CloudWatch コンソールからは、ログをクエリできるほか、ダッシュボードで可視化したり、メトリクスアラームを作成することができます。 ECS で実行しているアプリケーションが CloudWatch に送信できるメトリクスのタイプを、カスタマイズすることもできます。例えば、以下のメトリクスを収集できます: ecs.task.memory.utilized (タスクのメモリ使用量)、ecs.task.memory.reserved (タスクの予約メモリ量)、ecs.task.cpu.utilized (タスクの CPU 使用量)、ecs.task.cpu.reserved (タスクの予約 CPU 量)、ecs.task.network.rate.rx (タスクのネットワーク受信量)、ecs.task.network.rate.tx (タスクのネットワーク送信量)、ecs.task.storage.read.bytes (タスクのディスク読み取りバイト数)、ecs.task.storage.write.bytes (タスクのディスク書き込みバイト数)。 これらのメトリクスが CloudWatch で利用できるようになると、Amazon ECS サービスタスクのオートスケーリング設定にこれらのメトリクスを使用することができます。 AWS Distro for OpenTelemetry の料金 AWS Distro for OpenTelemetry の利用には料金はかかりません。CloudWatch に送信されるトレース、ログ、メトリクスの料金のみが課金されます。CloudWatch は前払い料金やサービス最低料金がなく、利用分のみを支払えばよいサービスです。詳細は CloudWatch の 料金ページ をご確認ください。 まとめ この記事では、Amazon ECS サービスをスケールするために利用可能な、AWS ネイティブなスケーリングオプションについて学びました。さまざまな規模の企業が、高い信頼性で一貫した顧客体験を維持する戦略の一環として、この方法を採用し、 Amazon ECS サービスをスケールできます。適切なメカニズムは、デプロイの敏捷性、事前/事後/予測スケーリングや、料金などの観点から決まります。 詳細については、 AWS Well-Architected フレームワーク 、 Amazon ECS でアプリケーションを実行する際のベストプラクティス 、 Amazon Elastic Container Service のセキュリティ を参照してください。私たちにお手伝いできることがあれば、 AWS サポート および AWS アカウントチームにご連絡ください。 本記事は、 Scale your Amazon ECS using different AWS native services! (2024 年 3 月 8 日公開) を翻訳したものです。翻訳は、ソリューションアーキテクトの吉田が担当しました。

世界中の AWS コミュニティで AWS Community Day カンファレンスが絶賛開催中です。先週開催された AWS Community Day Poland には、600 人を超えるクラウド愛好家が参加しました。1 日を通じて、コミュニティスピーカーである Agnieszka Biernacka 氏や Krzysztof Kąkol 氏などが講演して観客を魅了し、これらをきっかけに活気のあるディスカッションが繰り広げられました。私のチームメイトである Wojtek Gawroński もイベントに参加し、来年また参加することを既に心待ちにしています! 4月８週のリリース 4月8日週のリリースの中から、私の目に留まったリリースをいくつかご紹介します。 Amazon CloudFront が Lambda 関数 URL オリジンに対するオリジンアクセスコントロール (OAC) のサポートを開始 – 指定された CloudFront ディストリビューションからのアクセスのみを許可する Amazon CloudFront のオリジンアクセスコントロール (OAC) を使用して、 AWS Lambda URL オリジンを保護できるようになりました。「 CloudFront デベロッパーガイド 」には、指定された CloudFront ディストリビューションからの Lambda 関数 URL へのアクセスを認証するために CloudFront OAC の使用を開始する方法が詳しく説明されています。 AWS Client VPN と AWS Verified Access の移行と相互運用性のパターン – 現在 AWS Client VPN 、または類似する VPN ベースのサードパーティーソリューションを使用してアプリケーションへのセキュアなアクセスを提供しているならば、嬉しいお知らせがあります。新規または既存のアプリケーションのために AWS Client VPN と AWS Verified Access の使用を組み合わせることが可能になりました。 Amazon Bedrock のナレッジベースに関する次の 2 つの発表が目に留まりました。 メタデータフィルタリングによる検索精度の向上 – メタデータフィルタリングでは、適用されたメタデータフィルターと関連付けられた値に基づいて、意味的関連性のあるチャンクだけでなく、これらの関連性のあるチャンクの明確に定義されたサブセットも取得できます。 RetrieveAndGenerate API 向けのカスタムプロンプトと最大取得結果数の設定 – これらは、検索タイプとともにクエリオプションとして選択できるようになった 2 つの新しい機能で、検索結果の制御を可能にします。結果はベクトルストアから取得され、回答の生成のために 基盤モデル に渡されます。 AWS からの発表の完全なリストについては、「 AWS の最新情報 」ページをご覧ください。 その他の AWS ニュース AWS のオープンソースに関するニュースと最新情報 – 私の同僚である Ricardo がこちらの Open Source Newsletter を毎週執筆して、AWS コミュニティからの新しいオープンソースプロジェクト、ツール、およびデモを紹介しています。 近日開催予定の AWS イベント AWS Summit – クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントです。お住まいの地域が南北アメリカ、アジア太平洋、日本、EMEA であるかにかかわらず、地域内で開催される 今後の AWS Summit イベントに関する情報については、こちらをご覧ください 。 AWS Community Day – この記事の冒頭で紹介したものと同じような AWS Community Day イベント で、地域のエキスパート AWS ユーザーや業界リーダーが主導するテクニカルディスカッション、ワークショップ、ハンズオンラボに参加しましょう。 ケニア 、または ネパール にお住まいの場合は、4月15日週末に地域で開催されるイベントがあります。 こちらで、 近日中に開催されるすべての対面およびバーチャルイベントを閲覧 することができます。 4月15日週のニュースは以上です。4月22日週の Weekly Roundup もお楽しみに! – Veliswa この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします。 原文は こちら です。

PartyRock Generative AI Hackathon は4月初めに終了しました。参加者は、 PartyRock を利用して、4 つのチャレンジカテゴリのいずれかに基づいた機能的なアプリケーションを構築するよう求められました。既存のアプリケーションをリミックスするオプションもありました。このハッカソンには 7,650 名の登録者が集まり、1,200 を超えるプロジェクトが提出され、250 を超えるプロジェクトのブログ記事が community.aws で公開されました。 私は審査員の一員として、審査を依頼された応募作品の創造性と洗練さに驚かされました。参加者は、プロンプトエンジニアリングを実践し、基盤モデルについて学ぶ機会を得て、可能なことの限界を押し広げました。 上位 3 位の受賞者を簡単に見てみましょう… 第 1 位 まず、総合第 1 位の 20,000 USD の AWS クレジットを獲得したのは、 Param Birje 氏 による Parable Rhythm – The Interactive Crime Thriller です。このプロジェクトでは、PartyRock の生成機能を使用して、魅力的かつインタラクティブで没入できるストーリーを提供します。信じられない質の高さです。 詳細については、 ハッカソンでの提出物 および ブログ記事 をご覧ください。 第 2 位 第 2 位の 10,000 USD のクレジットを獲得したのは、 Michael Oswell 氏 による Faith – Manga Creation Tools です。このクリエイティブアシスタントアプリケーションを使用すると、ボタンをクリックするだけで独自のマンガのコマを生成できます。とても多くの可能性が秘められています。 詳細については、 ハッカソンでの提出物 をご覧ください。 第 3 位 最後に、総合第 3 位は、 Arghhhh! Zombie ( Michael Eziamaka 氏 ) です。これは、AI を活用した非常に面白い生成ゾンビゲームで、審査員たちもハラハラさせられていました。Michael、すばらしい作品でした! 詳細については、 ハッカソンでの提出物 をご覧ください。 拍手喝采 各カテゴリの受賞者全員にも大きな拍手を送りたいと思います。 カテゴリ/順位 提出物 賞金 (USD) AWS クレジット 総合 第 1 位 Parable Rhythm – 20,000 USD 総合 第 2 位 Faith – Manga Creation Tools – 10,000 USD 総合 第 3 位 Arghhhh! Zombie – 5,000 USD クリエイティブアシスタント 第 1 位 Faith – Manga Creation Tools 4,000 USD 1,000 USD クリエイティブアシスタント 第 2 位 MovieCreator 1,500 USD 1,000 USD クリエイティブアシスタント 第 3 位 WingPal 500 USD 1,000 USD 実験的なエンターテインメント 第 1 位 Parable Rhythm 4,000 USD 1,000 USD 実験的なエンターテインメント 第 2 位 Arghhhh! Zombie 1,500 USD 1,000 USD 実験的なエンターテインメント 第 3 位 Find your inner potato 500 USD 1,000 USD インタラクティブラーニング 第 1 位 DeBeat Coach 4,000 USD 1,000 USD インタラクティブラーニング 第 2 位 Asteroid Mining Assistant 1,500 USD 1,000 USD インタラクティブラーニング 第 3 位 Unlock your pet’s language 500 USD 1,000 USD フリースタイル 第 1 位 MindMap Party 1,000 USD 1,000 USD フリースタイル 第 2 位 Angler Advisor 750 USD 1,000 USD フリースタイル 第 3 位 SafeScares 250 USD 1,000 USD ボーナス: Remix ChatRPG Inferno – 2,500 USD ボーナス: Remix ChatRPG Chat RPG Generator – 2,500 USD インタラクティブラーニングエクスペリエンスから実験的なエンターテインメントまで、発揮された創造性と技術的な実行力は並外れたものでした。 そしてもちろん、生成 AI で可能なことの限界を押し広げてくれた 7,650 名の参加者全員に心から感謝します。皆さんの参加は大変誇るべきことです。 パーティーに参加しよう 上記の画像のいずれかをクリックすると、アプリケーションをご自身でお試しいただけます。それらをリミックスしてカスタマイズしたり、独自のアプリケーションを構築したりすることもできます (開始方法については、私の記事「 Build AI apps with PartyRock and Amazon Bedrock 」をお読みください)。 以上となります。受賞者の皆様に改めて祝意を表したいと思います。また、PartyRock チームとすばらしいスポンサーの皆様に心から感謝します。皆さんが次に何を構築するのか楽しみです。それまで、構築と学習を継続し、楽しみ続けましょう! – Jeff ; 原文は こちら です。

組織は、ベストプラクティスに従ってアプリケーションを実行できるよう、クラウドインフラストラクチャに対してコンプライアンスルールを適用しています。 AWS Config を活用して、内部のガイドラインに従って構成された設定に対する、全体的なコンプライアンス状況を確認します。この確認は、AWS アカウントでクラウドリソースを作成した後で行なわれます。 この記事では、AWS アカウントでクラウドリソースを作成する前に、 AWS CDK Aspects を利用してベストプラクティスに従っているかどうかをチェックしたり、従うための調整を行なう方法を紹介します。 AWS Cloud Development Kit (AWS CDK) は、TypeScript、Python、Java、.NET などの馴染み深いプログラミング言語を使ってクラウドアプリケーションリソースを定義できるオープンソースのソフトウェア開発フレームワークです。インフラストラクチャを定義するためにプログラミング言語の表現力を活用することで開発プロセスを加速させ、開発者体験を向上させることができます。 AWS Config は、AWS リソースの構成を評価・監査できるサービスです。AWS リソースの構成を継続的に監視・記録し、記録された構成が望ましい状態かどうかの評価を自動化できます。非準拠リソースが見つかった場合は、そのリソースを自動または手動で望ましい状態に修正できます。 AWS Config は、お客様がコンプライアンスに準拠した状態で AWS 上でワークロードを実行できるように支援しますが、前もって非準拠リソースを検知し、コンプライアンスに準拠したリソースのみをプロビジョニングしたいと考えるお客様も存在します。リソースの構成にはお客様にとって非常に重要なものもあるため、最初からコンプライアンスに準拠していない限りリソースをプロビジョニングしないと考える場合があります。たとえば次のような構成です。 Amazon S3 バケットは、パブリックアクセスを許可せずに作成する必要がある Amazon S3 バケットの暗号化を有効にする必要がある データベース削除保護を有効にする必要がある CDK Aspects CDK Aspects は、特定のスコープ内のすべての construct に対して共通の操作を適用する方法です。Aspect は、construct の状態について何らかの検証 (すべてのバケットが暗号化されていることを保証する、など) を行なったり、タグを追加するなど construct に対する修正を行なうことができます。 Aspect は、以下に示す IAspect インターフェイスを実装するクラスです。Aspect は Visitor パターンを採用しているため、既存のオブジェクト構造を修正することなく新しい操作を追加できます。オブジェクト指向プログラミングやソフトウェア工学において、 Visitor デザインパターン とは、オブジェクト構造からその上で動作するアルゴリズムを分離する手法のことです。 interface IAspect { visit(node: IConstruct): void ; } cdk deploy を呼び出すと、AWS CDK アプリケーションは以下のようにライフサイクルフェーズが遷移します。これらのフェーズは下の図でも表現されています。CDK アプリケーションのライフサイクルについての詳細については、 こちら のページを参照してください。 Construction Preparation Validation Synthesis Deployment CDK Aspect は Preparation フェーズで関係してきます。この Preparation フェーズでは、construct の最終的な状態を設定するための最後の変更ラウンドが実行されます。Preparation フェーズは自動的に実行されます。すべての construct は、内部に Preparation フェーズ中に呼び出され適用される Aspect のリストを持っています。次のメソッドを呼び出すことで、指定したスコープにカスタム Aspect を追加できます。 Aspects.of(myConstruct).add(new SomeAspect(...)); 上記のメソッドを呼び出すと、construct は内部の Aspect リストに カスタム Aspect を追加します。CDK アプリケーションが Preparation フェーズを処理するとき、AWS CDK は 指定した construct およびその配下の construct について上位から下位の順で、Aspect オブジェクトの visit メソッドを呼び出します。 visit メソッドは、construct に対して任意の変更を適用できます。 CDK Aspects を利用してリソース構成のコンプライアンスをチェックする方法・準拠させる方法 次のセクションでは、クラウド リソースをプロビジョニングする際のいくつかの一般的なユースケースにおいて、CDK Aspects を実装する方法をご紹介します。CDK Aspects は拡張可能です。追加のルールを実装することで、ユースケースに合わせて拡張できます。 以下のコードでは、Aspects を利用してベストプラクティスに照らし合わせて検証するクラウドリソースを作成しています。 import * as cdk from 'aws-cdk-lib'; import * as ec2 from 'aws-cdk-lib/aws-ec2'; import * as rds from 'aws-cdk-lib/aws-rds'; import * as s3 from 'aws-cdk-lib/aws-s3'; import { Construct } from 'constructs'; export class AwsCdkAspectsStack extends cdk.Stack { constructor(scope: Construct, id: string, props ?: cdk.StackProps) { super(scope, id, props); //Create a VPC with 3 availability zones const vpc = new ec2.Vpc(this, 'MyVpc', { maxAzs: 3, }); //Create a security group const sg = new ec2.SecurityGroup(this, 'mySG', { vpc: vpc, allowAllOutbound: true }) //Add ingress rule for SSH from the public internet sg.addIngressRule(ec2.Peer.anyIpv4(), ec2.Port.tcp(22), 'SSH access from anywhere') //Launch an EC2 instance in private subnet const instance = new ec2.Instance(this, 'MyInstance', { vpc: vpc, machineImage: ec2.MachineImage.latestAmazonLinux2(), instanceType: new ec2.InstanceType('t3.small'), vpcSubnets: { subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS }, securityGroup: sg }) //Launch MySQL rds database instance in private subnet const database = new rds.DatabaseInstance(this, 'MyDatabase', { engine: rds.DatabaseInstanceEngine.mysql({ version: rds.MysqlEngineVersion.VER_8_0 }), vpc: vpc, vpcSubnets: { subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS }, deletionProtection: false }) //Create an s3 bucket const bucket = new s3.Bucket(this, 'MyBucket') } } このセクションでは、Aspects を利用して以下のベストプラクティスに照らし合わせてリソースを検証するユースケースとコードを示しています。 VPC の CIDR 範囲は特定の CIDR IP から始まる必要がある セキュリティグループには public ingress ルールを設定してはいけない EC2 インスタンスは許可されたインスタンスタイプのみが利用可能である S3 バケットの暗号化を有効にする必要がある S3 バケットのバージョン管理を有効にする必要がある RDS インスタンスでは削除保護を有効にする必要がある import * as cdk from 'aws-cdk-lib'; import * as ec2 from 'aws-cdk-lib/aws-ec2'; import * as rds from 'aws-cdk-lib/aws-rds'; import * as s3 from 'aws-cdk-lib/aws-s3'; import { Stack, IAspect, Annotations, Tokenization } from 'aws-cdk-lib'; import { IConstruct } from 'constructs'; //Verify VPC CIDR range export class VPCCIDRAspect implements IAspect { public visit(node: IConstruct) { if (node instanceof ec2.CfnVPC && node.cidrBlock) { if (! node.cidrBlock.startsWith('192.168.')) { Annotations.of(node).addError('VPC does not use standard CIDR range starting with "192.168."'); } } } } //Verify public ingress rule of security group export class SecurityGroupNoPublicIngressAspect implements IAspect { public visit(node: IConstruct) { if (node instanceof ec2.CfnSecurityGroup) { checkRules(Stack.of(node).resolve(node.securityGroupIngress)); } function checkRules (rules : Array<ec2.CfnSecurityGroup.IngressProperty>) { if(rules) { for (const rule of rules.values()) { if (! Tokenization.isResolvable(rule) && (rule.cidrIp == '0.0.0.0/0' || rule.cidrIp == '::/0')) { Annotations.of(node).addError('Security Group allows ingress from public internet.'); } } } } } } //Verify instance type of EC2 instance export class EC2ApprovedITAspect implements IAspect { public visit(node: IConstruct) { const its = ['x', 'z', 'p', 'g', 'i', 't'] if (node instanceof ec2.CfnInstance && node.instanceType) { const instanceType = node.instanceType ; if (its.some(its => instanceType.startsWith(its))) { Annotations.of(node).addError('EC2 Instance is not using approved instance type.'); } } } } //Verify that bucket versioning is enabled export class BucketVersioningAspect implements IAspect { public visit(node: IConstruct): void { if (node instanceof s3.CfnBucket) { if (! node.versioningConfiguration || (! Tokenization.isResolvable(node.versioningConfiguration) && node.versioningConfiguration.status !== 'Enabled')) { Annotations.of(node).addError('S3 bucket versioning is not enabled.'); } } } } //Verify that bucket has server-side encryption enabled export class BucketEncryptionAspect implements IAspect { public visit(node: IConstruct): void { if (node instanceof s3.CfnBucket) { if (! node.bucketEncryption) { Annotations.of(node).addError('S3 bucket encryption is not enabled.'); } } } } //Verify that DB instance deletion protection is enabled export class RDSDeletionProtectionAspect implements IAspect { public visit(node: IConstruct) { if (node instanceof rds.CfnDBInstance) { if (! node.deletionProtection) { Annotations.of(node).addError('RDS DB instance deletion protection is not enabled.'); } } } } Aspect を作成したら、特定のスコープにそれらを追加します。スコープとして App、Stack、Construct が指定できます。以下の例では、すべての Aspect を Stack のスコープに追加します。 import * as cdk from 'aws-cdk-lib'; import { Aspects } from 'aws-cdk-lib'; import { AwsCdkAspectsStack } from '../lib/cdk-aspect-stack'; import { BucketEncryptionAspect, BucketVersioningAspect, EC2ApprovedITAspect, RDSDeletionProtectionAspect, SecurityGroupNoPublicIngressAspect, VPCCIDRAspect } from '../lib/cdk-aspect-rules'; const app = new cdk.App(); const stack = new AwsCdkAspectsStack(app, 'MyApplicationStack'); Aspects.of(stack).add(new VPCCIDRAspect()); Aspects.of(stack).add(new SecurityGroupNoPublicIngressAspect()); Aspects.of(stack).add(new EC2ApprovedITAspect()); Aspects.of(stack).add(new RDSDeletionProtectionAspect()); Aspects.of(stack).add(new BucketEncryptionAspect()); Aspects.of(stack).add(new BucketVersioningAspect()); app.synth(); 上記のコードで Aspect が追加された状態で cdk deploy を呼び出すと、次のような内容が出力されます。エラーを解決しリソースをルールに準拠させないかぎり、デプロイは実行されません。 コンプライアンスチェックだけではなく、Aspects を利用してリソースに共通の変更を加えることもできます。たとえば、タグに対応したすべてのリソースに必須のタグを設定できます。こうした機能を実現するために CDK Aspects を実装している例として Tags があります。 以下のようなコードを実装することで、Construct のスコープ内のすべてのリソースとその配下のリソース (タグに対応したリソースのみ) に、タグを追加したり削除したりできます。 Tags.of(myConstruct).add('key', 'value'); Tags.of(myConstruct).remove('key'); 以下は、Stack のスコープ内で作成されたすべてのリソースに Department タグを追加する例です。 Tags.of(stack).add('Department', 'Finance'); 開発者の皆さんには、Aspect の利用してインフラストラクチャリソースに動的な変更を加えることは避けることをお勧めします。そのような実装をすると、Synthesis フェーズで Stack に意図しない変更が発生してしまう可能性があります。IaC としての決定性が弱まり、CDK コードが唯一の信頼できる情報源ではなくなってしまいます。 (翻訳者補足: 外部から取得したパラメータを設定値として利用するなどの動的な変更をリソースに加えることは可能なかぎり避けて、決定論的な記述を心がけましょう。これは IaC の一般的なベストプラクティスです。Aspects を利用してリソースに変更を加える場合は、万が一意図しない変更が発生してしまったときの影響範囲が大きくなってしまう可能性があるため、とくにこの点を注意しましょう。) 追加の推奨事項 CDK Aspects は、開発者が選択したプログラミング言語を使用して、インフラストラクチャの構成をベストプラクティスに従うようにしたり、チェックしたりするための方法です。AWS CloudFormation Guard ( cfn-guard ) は、コンプライアンス管理者がシンプルな policy-as-code 言語でポリシーを記述し、ベストプラクティスを強制できるようにします。Aspects は CloudFormation テンプレートの生成前の Preparation フェーズで適用されますが、cfn-guard は CloudFormation テンプレートの生成後、Deployment フェーズの前に適用されます。開発者は CI/CD パイプラインの一部として Aspects または cfn-guard、あるいはその両方を使って非準拠リソースのデプロイを停止できます。ただし、非準拠リソースのデプロイを防ぎコンプライアンスを「強制する」意図が強い場合は、 CloudFormation Guard が適していると言えるでしょう。 cdk-nag は、AWS CDK Aspects を利用して多くのルールを実装し、パッケージとして提供するオープンソースプロジェクトです。たとえば AWS Solutions、HIPPA、NIST 800-53 などのパッケージがあります。このプロジェクトを利用すると、すでにパッケージ化されているルールを使って、CDK アプリケーションがベストプラクティスに従っているかどうかをチェックできます。評価したくないルールがある場合は、パッケージの中の一部のルールの評価を抑制できます。 まとめ インフラストラクチャの構築に AWS CDK を利用している場合は、リソースが作成される前にベストプラクティスに従うように、Aspects を使い始めることができます。CloudFormation テンプレートでインフラストラクチャを管理している場合は、この ブログ を読めば、CloudFormation テンプレートを AWS CDK に移行する方法がわかります。移行した後は、CDK Aspects を利用して、リソースがベストプラクティスに従っているかを、リソースの作成前に評価できます。 (翻訳者補足: 2024 年 4 月現在では、IaC 管理外のリソースもしくはデプロイ済みの CloudFormation スタックを CDK アプリケーションに移行できる CDK Migrate コマンド が利用できます。) 著者について Om Prakash Jha Om Prakash Jhaは AWS の Solutions Architect です。彼は小売業界のお客様が well-architected なアプリケーションを構築できるように支援しています。彼はミッション クリティカルなアプリケーションの開発、設計、アーキテクティングにおいて 10 年以上の経験を持っており、DevOps や Application Modernization に情熱を持っています。仕事以外では本を読んだり、映画を見たり、家族と一緒に世界を旅したりすることが好きです。 本記事は 2021/10/07 に投稿された  Align with best practices while creating infrastructure using CDK Aspects を翻訳したものです。翻訳は Solutions Architect : 国兼 周平 (Shuhei Kunikane) が担当しました。

製造業のお客様は、しばしば人材の不足が組織の生産性に影響を与えていると話しています。このように感じているのは、あなただけではありません。製造業の事業者の興味関心事項を集めている業界団体の全米製造業協会 (U.S. National Association of Manufacturers) は、CEO に対して四半期ごとに主要な事業課題についてアンケートを実施しています。最新のアンケート( 2023年第4四半期製造業の概況 )では、71%を超える製造業の企業が「優秀な人材を惹きつけ、維持できない」という問題が、他のいかなる問題よりも事業に影響を与えていると回答しています。この問題は長年にわたって懸念事項のトップであり、「製造業のスキルギャップ」という独自のブランディングさえされています。簡単に言えば、30年の経験を持つ製造業の従業員が退職し、次世代が参入せず、現世代にはさまざまな考え方や期待があるため、製造現場では純粋に20%の従業員が減少している状況です。パンデミックによってこの状況はさらに悪化しています。 製造業の企業は、離職率が高い今の時代に生産性を維持するため、恒常的に新しい従業員をすばやく訓練する必要があります。また、革新の速度や必要なスキルセットの変化に対応するために、既存の従業員の能力向上や再訓練を行う必要があります。さらに、専門家の退職や離職によって既存の知識が失われるリスクを回避するため、できるだけ早期に既存の知識を収集し制度化しなければなりません( “the silver tsunami” と呼ばれることがあります)。多国籍企業にとっては、組織内の知識が一つの言語で入力されているが、別の言語で利用する必要があるなど、さらなる課題があります。 組織における隠れた知識を収集、統合し、これらを解放して簡単にアクセス可能にすることは、自然言語処理技術の最前線にある課題です。このブログでは、生成 AI の技術、特に非構造化・分散した情報を文脈化して洞察を抽出する能力が、どのように製造業の企業のスキルギャップ解消に向けた進歩に役立っているかを明らかにします。 生成AIとは 生成 AI とは、膨大な量の幅広い非構造化データセットで学習された、数十億のパラメーターを持つ機械学習 (ML) モデルの領域を指します。これらの生成 AI モデル、一般に基盤モデル (FM) または大規模言語モデル (LLM) と呼ばれるモデルは、情報の取得と要約、質問への回答、オリジナルコンテンツの生成など、幅広い文脈に適用できる複雑な要求を解釈する能力を持っています。FM には、テキストを生成する (Text-to-Text モデル)、画像を生成する (Text-to-Image)、マルチモーダル (Text-to-Image, Image-to-Text) などさまざまな種類のモデルがあります。例としては、Anthropic Claude、Meta Llama、 Amazon Titan などの基盤モデルがあります。 基盤モデルは、一般的な知識タスクにおいて、そのままでも良好な性能を発揮しますが、ドメイン固有の知識は限られています。従業員のスキルギャップを埋めるために、多くの場合に企業の専有情報や機密と見なされるドメイン固有の能力こそが、製造業の顧客が必要としているものです。 データサイエンティストは、一から高度に特化したモデルを開発するよりも、むしろ既存の汎用 FM を出発点として活用し、ドメイン固有の情報にアクセスできるようにしてモデルの応答を微調整するソリューションを設計しています。よく知られた費用対効果の高いアーキテクチャパターンとして、Retrieval Augmented Generation(RAG) があります。RAG では、ドメイン固有の機密性の高い情報にスマートな検索を実行し、最も関連性の高い情報を探し出します。検索した結果は基盤モデルに渡され、その複雑な情報を解釈する能力を活用して、検索結果から意味を抽出し、ドメイン固有の知識に基づいて要約、質問回答、オリジナルコンテンツの生成を行います。この手法により、製造業のような事実を重要視する業界で最も重要なことですが、回答が正確になり、同時に機密情報を保護することができます。RAG を使えば、基盤モデル、知識ストア、スマート検索サービスを柔軟に選択することで、パフォーマンスとコストを最適化することもできます。 企業は、文書ナレッジベース、ERP(Enterprise Resource Planning)、MES(Manufacturing Execution Systems) などの企業が専有するデータソースと基盤モデルを組み合わせ、ドメイン固有で高度にパーソナライズされた技術情報を扱える学習チャットボットなどのソリューションを提供できます。 生成AIがスキルギャップの解消にどのように役立つか RAG アーキテクチャが作業員を支援する情報をどう活用するかを理解するために、たとえばチャットボットが設備の修理技術者を支援し、問題の診断に費やす時間を短縮するケースを想像してみましょう。設備が停止すると、重要な製造ラインの稼働が妨げられる可能性があります。ラインを稼働させ続けることは、すべての製造事業者の主要な業績評価指標の要素(総合装置効率, OEE の一部である Uptime) であり、企業の収益に直接影響することがあります。診断時間の短縮は修理時間の短縮へとつながり、機器の可用性を高めます。 このチャットボットは、裏側で Retrieval Augmented Generation(RAG) を使って基盤モデルと診断マニュアル、サービスニュース、過去の原因分析、保守システムの情報などの追加情報源を組み合わせます。これらの情報は紙の書類の場合があります。紙の文書では、関連する情報をデジタルデータの形で抽出する処理が必要になります。また、スマート検索と生成 AI はコンテンツがデジタル化されていることを前提としており、特定のファイル形式を使えば、単語、概念、語意のセマンティクスや類似性を解釈する能力が高まります。そのため、デジタル化されているソースの文書でも変換が必要になる場合があります。 AWS Step Functions 、 Amazon Textract 、 AWS Lambda などの AWS のマネージドサービスを活用した自動コンテンツ処理パイプラインを構築することで、新しい情報が追加されるたびに抽出・変換が可能です。多国籍企業や多言語の従業員がいる企業では、パイプラインの中で Amazon Translate を使って、ソース言語から一つ以上のターゲット言語に翻訳する手順が加わります。 このコーパスは、基盤モデルがドメインに特化したデータソースを参照して正確な回答を行うためのものです。基盤モデルは文脈を把握しながら情報を要約して人間が理解しやすくし、既存の検索手法を超えた対話型の質問と回答を可能にします。 企業には何千件もの知識文書のコーパスがある場合があります。修理技術者がそれらをすべて読んでいるとは限らず、さらに重要なことに、重大な問題を診断する際に適切な情報を見つけるのは非常に難しいでしょう。 Amazon Kendra や Amazon OpenSearch Service などの AWS サービスを使ってスマートな検索を実現すれば、技術者は数千件の知識文書を現在の問題に最も関連性の高いごく一部に絞り込むことができます。これにより数千件から数十件と技術者の認知負荷は軽くなりますが、それでも負担があります。その数十件の文書を Amazon Bedrock で実行されるマネージドな基盤モデルに渡せば、RAG プロセスを完成させ、数千件の知識文書全体を1つの段落や絞った手順に要約できます。 数千件から数十件へ、そして最終的には、修理を行う技術者が重大な生産の問題を診断し、解決するまでの時間短縮に役立つ1つの簡潔な回答へとたどり着きます。 上記のソリューションは、生成 AI 対応のアーキテクチャを製造業の課題解決に適用できる例の一つに過ぎません。このアーキテクチャには AWS のマネージドサービスが含まれています。技術的なアーキテクチャと全体的なソリューションを確認し、個別の要件を満たすために拡張、機能強化、最適化することをお勧めします。 ソリューションの概要 それでは、修理技術者の診断時間を短縮するために、診断マニュアルなどの静的で構造化されたデータと、センサーのテレメトリデータや異常検知アラートなどの動的なデータの両方にアクセスする方法を主眼としたアーキテクチャ例を見てみましょう。 既存の静的なコンテンツから知識を抽出 診断マニュアルなどの知識源はあまり変更されることがなく、修理用チャットボットで継続的に再利用するために処理して保存することは理にかなっています。これらの文書には、フォームやチャートなど、前処理が必要なコンテンツが含まれることがよくあります。Amazon Textract などのサービスを使用して、この情報を抽出することができます。複数の言語を扱う場合は、必要に応じて Amazon Translate を使用して、異なる言語間で翻訳することもできます。文書から抽出され翻訳された情報は処理されたのち、Amazon Kendra (他の選択肢も可能)などのセマンティック検索が可能なコンテンツ知識リポジトリに追加されます。RAG ベースのチャットボットは、この情報を使用して、基盤モデルに渡す関連情報を見つけ出します。 図面、診断マニュアル、SOP などの組織の知識源が、 Amazon S3 に保存されています。 AWS Lambda 関数がトリガーとなり、S3 の変更イベントに応じて AWS Step Functions のオーケストレーションが開始されます。 Step Functions のワークフローは、Amazon Textract を使用してこれらのデータソースから情報を抽出し、文書の性質に応じてAmazon Translateを使用して翻訳するように構成されています。 処理された文書が最終的なコーパスとして Amazon S3 に保存されます。 Amazon Kendra は、多言語の文書コーパスが保存されている Amazon S3 バケットを参照し、検索用にインデックス化します。 エンタープライズアプリケーションと設備監視システムからの知識の抽出 産業設備は、ライン上の機器に接続されたセンサーからテレメトリーデータを生成します。このデータを分析し、予測アルゴリズムを使用して異常を検出します。異常が検出されると、アラートが発報されたり、技術者による問題解決のためにワークオーダーが自動的に作成されます。アーキテクチャの例では、 Amazon Monitron と Amazon Lookout for Equipment が異常を検知するサービスとして示されています。Amazon Kendra は、多くの AWS サービスや保全システムを含む業界で標準的なデータソースとネイティブで接続でき、カスタムコネクタを介して他のデータソースにもアクセスできます。 産業機器および製造工程からのテレメトリーデータは、さまざまなセンサーを通して収集されます。産業ゲートウェイがこれらのセンサーからデータを収集し、クラウドに送信します。 製造業のお客様は、 Amazon SageMaker などの機械学習やアナリティクスサービスを使用して、このテレメトリーデータを処理・分析できます。 この分析の結果に基づいて、なんらかの異常やイベントが AWS Lambda 関数をトリガーします。 AWS Lambda 関数は、設備管理システムで保守作業依頼を作成します。Amazon Kendra は、情報源として設備管理システムを使用します。 コンテンツやアプリケーションリポジトリと生成AIを結合する Amazon Kendra により、診断マニュアルなどの既存の静的で頻繁に更新されない知識ストアを、設備監視システムや EAM などの企業アプリケーションからのトランザクションデータと組み合わせることができます。 Amazon Bedrock は、Amazon Kendra などのデータソースを利用して、ドメイン固有の情報を検索し、コンテキスト化、要約、インタラクティブな質問と回答のためにさまざまな基盤モデルに渡します。Amazon Bedrock は API 駆動型であり、チャットボットアプリケーションや内部システム (既存のメンテナンスシステムなど) に機能を埋め込むことができます。Amazon Bedrock では、修理技術者のチャットボットを企業全体で広範囲に展開する際に重要な要素となる、正確な回答を適切なコストで提供するモデルを選択できます。 Amazon Kendra は、この例では静的コンテンツとトランザクションアプリケーションの知識ソースの両方を参照します。 Amazon Bedrock は、ドメイン固有の検索に Amazon Kendra を使用し、コンテキスト化、要約、インタラクティブな質問への回答のために基盤モデルを実行します。 エンドユーザーが Amazon Bedrock と接続されたチャットボットを使用します。 終わりに 数千から数十へ、最終的には従業員が使用できる 1 つの簡潔な回答へと、生成 AI と検索拡張生成 (RAG) アーキテクチャには、製造業の従業員を大いに力づけ、閉じ込められた知識を解放する可能性があります。基盤モデルと独自のデータソースを組み合わせることで、学習チャットボットなどのソリューションは、従業員のドメイン固有の質問に対して、関連性が高く理解しやすい回答を迅速に提供できます。これにより、作業員が情報検索に費やす時間が大幅に短縮され、機器の診断や修理などのプロセスが加速されます。最終的には、これが現場での生産性と効率性の向上につながります。 本ブログで紹介したソリューションはあくまで一例ですが、生成 AI によって従業員が組織内の情報へのアクセス方法を変革する可能性を示しています。アーキテクチャをカスタマイズして組織独自のデータソースを活用することで、この技術はあらゆる企業のニーズに適用できます。生成 AI が進化し続ける中で、これを活用してスキルギャップを解消し労働者を支援する絶好の機会が製造業のお客様に訪れています。 本ブログはAWS Blog の “ Closing the manufacturing skills gap with generative AI ” をソリューションアーキテクトの山本が翻訳しました。 Danny Smith Danny Smith は、自動車・製造業界のプリンシパル ML ストラテジストであり、顧客の戦略アドバイザーを務めています。彼は、役員室から製造現場に至るまで、主要な意思決定者がデータ、テクノロジー、数学を活用してより良い意思決定を行えるよう支援することに注力してきました。最近は、デジタルトランスフォーメーションの推進、データ主導型への移行、人工知能と機械学習の民主化戦略に関する話題がほとんどでした。彼は産業サプライチェーンの分野でキャリアをスタートし、今もなおこの分野を好み、特に鉄道が好きです。Danny は、ジョージア工科大学で産業管理の学士号を、ジョージア州立大学で意思決定科学の修士号を取得しています。 Garry Galinsky Garry Galinsky は、アマゾンウェブサービスのソリューションアーキテクチャを担当しています。電気通信、ローカル検索、インターネット、金融業界で 20 年以上にわたって進歩的なハイテクの経験を積んできました。Garry はキャリアの中で、北米、ヨーロッパ、中東、アジアの中小企業、大企業の顧客向けに、インターネット、Web 2.0、ローカル＆ソーシャル検索、モバイルソリューションの設計、開発、提供、普及に成功してきました。 Ravi Soni Ravi Soni は、製造システム、デジタルトランスフォーメーション、AI/ML、IoT、インダストリー 4.0、AWS クラウドなどに関する豊富な技術スキルを持つ製造ソリューションスペシャリストです。ダッソー、Google X、NuvaSiveで勤務した経験を持つ Ravi は、産業機械、プロセス製造、CPG、医療機器、航空宇宙産業にまたがる幅広い専門知識を持っています。

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週も 週刊AWS をお届けします。 最近暖かくなってきたと思ったら、最近はウォーキングで少し汗ばむぐらいになってきましたね。お昼のウォーキングも快適で、個人的には1年中これぐらいの気温だと良いのですが。 それでは、先週の主なアップデートについて振り返っていきましょう。 2024年4月8日週の主要なアップデート 4/8(月) Amazon OpenSearch Service now lets you update node count without blue/green Amazon OpenSearch Service で、専用のクラスター管理ノード（クラスターマネージャーノード）を持たないクラスターにおいて、Blue/Greenデプロイメント無しでデータノードの数を更新する機能が拡張されました（専用のクラスター管理ノードがある環境では以前より可能でした）。これにより、Blue/Greenデプロイメント実行中の一時的なノード数の増加をが不要になり、迅速にノード数変更が可能になりました。 Amazon CloudWatch RUM is generally available in 11 additional AWS Regions Amazon CloudWatch RUM を利用可能なリージョンが追加され、新たに大阪を含む11のリージョンで使えるようになりました。CloudWatch RUMはクライアント側からのリアルユーザーモニタリング (RUM)を支援するサービスです。追加されたリージョンは以下の通りです。Africa (Cape Town), Asia Pacific (Jakarta), Asia Pacific (Mumbai), Asia Pacific (Osaka), Asia Pacific (Seoul), Canada (Central), Europe (Milan), Europe (Paris), Middle East (Bahrain), South America (Sao Paulo), US West (N. California) 4/9(火) Amazon Route 53 adds support for 18 additional Top-Level Domains Amazon Route 53 は権威DNSサーバーの機能だけでなく、ドメインのレジストレーションサービスも提供しています。今回新たに18のトップレベルドメイン(TLD)が追加され、合計351のTLDが利用可能になりました。追加されたTLDは以下の通りです。.beer, .bid, .bio, .christmas, .contact, .design, .fan, .fun, .law, .llc, .ltd, .pw, .shopping, .ski, .software, .stream, .vote, .work Amazon RDS for MySQL supports rds_superuser_role for easier implementation of role based privileges Amazon RDS for MySQL v8.0.36 以降で rds_superuser_role というロールが追加されました。v8.0.36 以降で管理者ユーザーが直接DB内の表への変更を行うことが非推奨になり、新しいロールベース権限モデルに移行したのですが、これを支援するためのロールです。このロールは、DB内の表を操作する多くの権限を持っており、デフォルトの管理者に付与される形でこれまでとの互換性を維持しています。詳細は こちらのドキュメント をご覧ください。 Knowledge Bases for Amazon Bedrock now supports Claude 3 Haiku Amazon Bedrock の Knowledge Bases は、基盤モデル（FM）を社内のデータソースに安全に接続して検索拡張生成（RAG）を行い、より適切で正確な回答を提供することを支援する仕組みです。今回の改善で Anthropic の Claude 3 Haiku 基盤モデルをサポートしました（Claude 3 Sonnet はすでにサポート済です）。 AWS AppSync forwards application request headers to AWS Lambda custom authorizer functions AWS AppSync はサーバーレスで高性能な GraphQL サービスです。今回の改善で GraphQL リクエストを承認する際に、アプリケーションリクエストヘッダーを AWS Lambda カスタムオーソライザー関数に渡すことができるようになりました。カスタムオーソライザーでは認証ヘッダーの値に基づいて認証を実行できるようになります。 4/10(水) AWS Clean Rooms Differential Privacy is now generally available AWS Clean Rooms Differential Privacy (差分プライバシー) が一般提供開始（GA）になりました。Differential Privacyは、共有されたデータを分析する際に、統計的な影響を生まない範囲でのノイズ（エラー）を追加することでより匿名性を高めたり、プライバシーバジェット（予算）という仕組みの導入で、クエリの量のコントロールを実現する機能です。詳細はこちらの プレビュー時のブログ をご覧ください。 4/11(木) Amazon CloudWatch Container Insights announces observability for Windows containers on Amazon EKS Amazon CloudWatch Container Insights で、Amazon Elastic Kubernetes Service (EKS) で稼働する Windows コンテナに対応しました。CloudWatch Container Insights はコンテナ化されたアプリケーションやマイクロサービスからメトリクスとログを収集、集計、要約するオブザーバビリティのサービスです。 Introducing workflow monitor for AWS Media Services AWS Elemental MediaConnect, Elemental MediaLive, Elemental Media Packageといった、AWSのメディアサービスのワークフローを管理するためのworkflowmonitor for live videoが利用可能になりました。Elemental MediaLive console から利用可能です。 詳細はこちらのブログをご覧くださ い。 Amazon Braket adds experimental capabilities for QuEra device via Braket Direct フルマネージド量子コンピューティングサービスである Amazon Braket の Braket Direct で、QuEra の Aquila がサポートされました。 Braket Direct はリソースの予約といった機能に加えて、実験的な機能も利用可能にするものです。詳細は こちらのドキュメント をご覧ください。 Amazon CloudFront now supports Origin Access Control (OAC) for Lambda function URL origins Amazon CloudFront が Lambda Function URL をオリジンとする際にOrigin Access Control (OAC)でのアクセスを可能にしました。これによりLambda Functionを公開する際に、LambdaへのアクセスはCloudFrontからのリクエストに限るという設定が容易に可能になります。 4/12(金) AWS Step Functions Announces Optimized Integration for AWS Elemental MediaConvert AWS Step Functions で AWS Elemental MediaConvert との連携がより容易に行えるようになりました。例えば、MediaConvert CreateJob API 用の Run a Job (.sync) という統合パターンを利用すると、非同期の MediaConvert トランスコーディングジョブが完了するのを待ってから次のステップに進むといったワークフローを記載することが可能になるなど、より複雑なメディア処理のパイプラインが構築可能になります。 AWS KMS announces more flexible automatic key rotation AWS Key Management Service (AWS KMS) で、自動キーローテーションについて複数のアナウンスがありました。ローテーション期間の頻度が 90 日から 最大 7年 (2560 日) まで延ばすことが可能になり、過去のすべてのローテーションの履歴を確認できるようになりました。また、 価格についても変更があり、キーローテーションの最初の2回は1ドル/月の費用がかかりますが、3回目以降にはローテーションの費用がかからなくなりました。この変更は2024年5月の支払いサイクルから適用されます。詳細は こちらのホームぺージ をご覧ください。 それでは、また来週！ ソリューションアーキテクト 下佐粉 昭 (X/twitter – @simosako )

このブログは 2024 年 4 月 11 日に Kenneth Hui (シニアソリューションアーキテクト) によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 ランサムウェアの脅威により、データ保護はすべての企業にとって最優先事項となっています。 Sophos 社の「State of Ransomware Report 2023」 によると、2022 年には 66 % の組織が被害を受け、ランサムウェアによる支払い額の中央値は 40 万ドル (平均支払い額は 154 万ドル) でした。バックアップを使用した場合の復旧コストの中央値は身代金支払いの半分 (75 万ドルに対して 37 万ドル) であるため、信頼性の高いバックアップを用意することは贅沢ではなく、組織にとって不可欠です。 同時に、組織はクラウドデータ保護のコストなどのクラウドコストの最適化を検討しています。 Flexera 社の「2023 State of the Cloud Report」 によると、クラウドを利用しているすべての組織の 82% が、クラウド支出の管理を最優先事項としています。AWS ユーザーからは、包括的な多層防御戦略と費用対効果の高いデータ保護戦略とのバランスを取る必要があるというフィードバックが一貫して提供されています。 AWS Backup は、ハイブリッドリソースの大規模なデータ保護を簡素化する、費用対効果の高いフルマネージド型のポリシーベースのサービスをユーザーに提供するネイティブクラウドソリューションです。13 万人の AWS Backup のお客様 (2023 年 9 月現在) がデータ保護の支出を最適化できるように、何千人ものユーザーとの作業から集めた AWS Backup のコスト最適化のベストプラクティスを概説する一連の記事を公開しています。この記事では、コスト最適化の定義、コストを最適化するための AWS Backup の構築方法、およびバックアップコストを最適化する際に考慮すべき原則について概説します。 コスト最適化とは何ですか？ コスト最適化とは「賢く」支出することであり、必ずしも支出を減らすことではありません。ガートナー社は、 コスト最適化 を「ビジネス価値を最大化しながら、支出とコスト削減を促進するためのビジネスに焦点を当てた継続的な規律」と定義しています。同様に、AWS はコスト最適化を「システムを運用してビジネス価値を最も低いコストで提供する能力」と定義しています。AWS Backup などのマネージドクラウドサービスは、コストの削減、イノベーションとモダナイゼーションの促進、運用効率とビジネスの成長の促進、ビジネスリスクの軽減により、IT インフラストラクチャからより多くの価値を引き出すのに役立ちます。 AWS Backup がデータ保護コストを最適化する方法 AWS Backup は、データを保護しながら経済的および運用上のメリットを得るのに役立つ主な方法が 3 つあります。 AWS Backup は、バックアップと復旧のインフラストラクチャ全体の支出を削減するのに役立ちます。 バックアップサーバーやストレージをプロビジョニングして管理する必要はありません。リソースの増大に合わせて容量を手動でスケールアップする必要はありません。AWS Backup を使用しても、年間のソフトウェアライセンスコストはかかりません。資本的支出や運用上のオーバーヘッドなしで、AWS Backup にすぐにアクセスでき、使用した分だけ支払います。 AWS Backup はバックアップ操作を簡素化するので、バックアップ操作に費やす時間とサイクルを減らし、代わりにイノベーションとモダナイゼーションに焦点を当てることができます。 AWS Backup を使用すると、サポートされた AWS サービスを一元的に保護できます。ネイティブの AWS サービスのバックアップを管理するために、購入または構築した複数のソリューションを管理する必要はありません。AWS Backup はマネージドサービスであるため、リソースのプロビジョニングやソフトウェアのパッチ適用、キャパシティプランニングなど、区別できないタスクに時間とサイクルを費やす必要がなくなります。 AWS Backup は、組織全体のバックアップコストを監視および最適化するための管理ツールを提供しています。 コスト配分タグなどのツールを使用して、バックアップのコストを追跡できます。AWS Backup ポリシーエンジンを使用すると、バックアップデータの保持とサポートされたサービスのライフサイクルを制御して、必要な時に以降データが保持されないようにすることができます。 AWS Organizations と統合することで、これらのポリシーを複数の AWS アカウントに一元的に適用できます。 考慮すべきコスト最適化の原則 バックアップコストを最適化するための万能のソリューションはありません。代わりに、総合的なアプローチを取り、ビジネス目標を達成しながら効率的に支出する方法を検討する必要があります。以下のテーマについて詳しく説明します。 1. 現在のクラウドのバックアップコストを評価して理解する バックアップコストの計算には、ストレージの料金を知るだけでは不十分です。インフラストラクチャやソフトウェア、運用コストを含め、現在のソリューションにいくら支払っているか知っていれば、コストをより適切に比較して最適化できます。 総保有コスト (TCO) を理解します。 バックアップストレージのコストだけでなく、現在のバックアップソリューションの TCO も考慮することをお勧めします。TCO を評価するためには、ソフトウェアライセンス、コンピューティング、運用などの追加コストを考慮する必要があります。 支出を追跡します。 実際の支出を理解していなければ、コストを最適化することはできません。AWS Backup は、バックアップコストの追跡と最適化に役立つツールを提供しています。コスト配分タグを使用してバックアップのコストを追跡できます。 AWS Cost Explorer を使用してタグ付けされたリソースをフィルタリングすると、部門やプロジェクトなどのさまざまな基準でバックアップコストを表示できます。 2. コストの計算方法を理解する バックアップコストはサポートされたリソースによって異なり、 AWS Backup の料金ページ に記載されています。各リソースのコストモデルを理解し、それらのポリシーに基づいてバックアップポリシーを設定することで、コストを最適化できます。 永久増分バックアップのコストへの影響を理解します。 従来のバックアップソリューションでは、増分バックアップに加えて、定期的なフルバックアップも必要とする方式が使用されていました。AWS のバックアップは、フルスナップショットを 1 つだけ作成することを必要とする永久増分スナップショットに基づいています。例えば、100 GB の Amazon Elastic Block Store (Amazon EBS) ボリュームで、日次の変更率が 2 % の場合、30 日間の保持期間で 1 か月間の日次バックアップを行うと、最大 160 GB のスナップショットデータが蓄積されます。週次のフルバックアップを行う従来の方法では、同じボリュームに最大 600 GB のスナップショットデータが蓄積されます。 さまざまなリソースのバックアップ料金を理解します。 AWS Backup は、 Amazon Elastic Compute Cloud (Amazon EC2) 、 Amazon Relational Database Service (Amazon RDS) 、 Amazon Simple Storage Service (Amazon S3) 、VMware vSphere、 SAP HANA on Amazon EC2 など 20 のリソース・AWS サービスのバックアップ管理をサポートしています。サービスによってコストモデルは異なる場合があり、それらのコストモデルを理解しすることは、コストを予測および制御するのに役立ちます。例えば、Amazon RDS では AWS Backup を通じて継続的なバックアップを提供しています。これらのバックアップは最大 35 日間保存でき、その保持期間中に作成されたバックアップは無料で提供されます。 3. バックアップストレージにライフサイクル管理を使用する バックアッププランのバックアップ頻度やライフサイクル、リソース選択の粒度を制御できます。何をどのくらいの期間保護するかを選択できます。これらの設定はいつでも変更できます。 バックアップ頻度を制御します。 バックアップのコストは、データをバックアップする頻度に直接関係します。ワークロードごとの目標復旧時間と目標復旧時点に基づいて、ワークロードを分類し、バックアップ頻度を設定することをお勧めします。 保持ポリシーを決定します。 同様に、保持要件に従ってワークロードを分類することをお勧めします。例えば、日次バックアップは 1 か月だけ保持し、月次バックアップは 1 年間保持する要件がある場合があります。コストを制御するために、バックアップデータを必要以上に長く保持したくない場合があります。 長期間の保持のためにコールドストレージにバックアップを階層化します。 AWS Backup によって保護されている一部のリソースは、コールドストレージへの階層化をサポートしています。保持要件に従ってワークロードを分類し、必要に応じてコールドストレージに階層化することをお勧めします。 まとめ データが貴重で攻撃を受けている今、AWS Backup などのソリューションを使用してデータを保護することは不可欠です。しかし、その要件とコストの最適化の必要性とのバランスが取られる必要があります。AWS Backup には、最も低い料金でビジネス価値をもたらすシステムを運用できるだけでなく、バックアップの管理に役立つツールとベストプラクティスが用意されています。2024 年中に AWS Backup のコスト最適化に関する記事が他にもありますので、ぜひご覧ください。一方、AWS Backup の詳細については、 製品ページ をご覧ください。また、この Amazon ストレージブログの記事 を読んで、AWS Backup でコスト配分タグを使用する方法を学んでください。 この記事を読んでいただきありがとうございました。 翻訳はクラウドサポートエンジニアの黒川が担当しました。 Kenneth Hui Kenneth Hui は AWS 州政府と地方自治体チームのシニアソリューションアーキテクトです。エンタープライズテクノロジー分野で 20 年以上の経験があり、複数の移行プロジェクトを主導したり、参加したりしてきました。ケンはニューヨーク市に住んでおり、さまざまなレストランで食事をしたり、さまざまな料理を試したりすることを楽しんでいます。

世界中の研究機関では、 AWS を利用して大規模なシミュレーション、分析、モデリング、その他の分散型・計算集約型ワークロードを毎日実行しています。これらのジョブは、コンピューティングフリート全体でタスクを調整するオーケストレーションレイヤーに依存しています。 研究者やシステム管理者にとって、研究者向けのサービスを提供する際、ワークロードの種類によって選択肢が多岐にわたるため、どの AWS サービスやソリューションを使用するべきか判断することが難しい場合があります。 本記事では、代表的な研究ユースケースを取り上げ、それぞれのワークロードに最もフィットすると考えられる AWS ツールについて解説します。 ワークロードを理解する 各ツールの詳細に踏み込む前に、自身のワークロードの特性を把握することが大切です。 プロセスの密結合が求められるか、コンテナを利用するか、機械学習機能が必要か、クラウドデスクトップが不可欠かといった、様々な要因が意思決定プロセスにおいて重要な役割を果たします。 研究は一様ではないため、 AWS では工学シミュレーションや創薬、ゲノミクス、機械学習（ML）、金融リスク分析、社会科学など、 HPC（High Performance Computing, 高性能計算処理 )ベースの多岐にわたる研究をサポートしています。 また、選択するツールは排他的ではありません。お客様は同じアカウント内で、自身のニーズを満たすソリューションを組み合わせて利用できます。 AWSのコンピュートオーケストレーションツールの詳細 従来の HPC クラスターに適した AWS ParallelCluster AWS ParallelCluster は、AWS上でHPCクラスターを構築・管理するための柔軟なツールです。シミュレーションや分析など、従来型のHPCクラスターを必要とする密結合ワークロードに最適です。低レイテンシーと高スループットのインスタンス間通信のために、 Elastic Fabric Adapter （EFA）ネットワークをすぐに使えるようサポートしており、高性能ファイルシステム（Lustre – Amazon FSx for Lustre マネージドサービスを通じて利用可能）も備えています。 図1 – HPC ワークロードのための AWS ParallelCluster とその構成要素の概要を示しています。Slurm と Amazon EC2 との統合により、ジョブキューに基づいて計算ノード数が適切にサイジングされます。Amazon FSx for Lustre を使用すれば、高性能ファイルシステムにアクセスでき、同時に Amazon S3 オブジェクトストレージの利点も活用できます。これらすべてが Elastic Fabric Adapter (EFA) で接続されており、密結合ワークロードに対して極めて高い性能の接続とスケーリングを実現します。 コンテナベースのジョブに適した AWS Batch AWS Batch は、多くのコンテナ化されたジョブを同時に実行するような並列度の高い用途に適しており、これは密結合のワークロードも含みます。 Amazon Elastic Kubernetes Service (EKS)、 Amazon Elastic Container Service (ECS) などとシームレスに統合されたフルマネージドスケジューラで、研究者は既存のコンテナ化アプリケーションを活用できます。典型的なワークロードは、汎用的な計算の並列実行や、他の AWS サービスとの統合、MPI や NCCL を用いた密結合ジョブ等です。 図2 – コンテナベースのジョブ処理と AWS サービスとの統合を示す AWS Batch のワークフローです。Amazon EKS および ECS との互換性により、Compute Environment 層で柔軟性が確保されています。 機械学習プロジェクトに適した Amazon SageMaker Amazon SageMaker は、特に Jupyter Notebook で Machine Learning モデルを開発するワークロードに最適です。研究コンピューティングの基礎的な構成要素に特化しているわけではありませんが、代わりにデータ発見・探索からモデルトレーニング・デプロイまでの全工程をカバーする、マネージド型の ML ・データサイエンスツール群のエコシステムを提供しています。 SageMaker ノートブックは対話型の開発環境を提供し、研究者はモデルの開発・テストを容易に行えます。SageMaker には事前トレーニングされたモデルも含まれており、研究者は ML プロジェクトをジャンプスタートできます。また、マネージド型の推論エンドポイントも提供されており、モデルのデプロイと予測の提供が簡単になります。 図3 – データ準備からモデルデプロイまでのエンドツーエンドのプロセスを高レベルで示す Amazon SageMaker エコシステムです。ノートブックでのローカルファイルシステムとして Amazon EFS と統合されており、また、モデルトレーニングのために高度に最適化された AWS Deep Learning Containers とも統合されています。 基盤となる計算リソースについて 先程述べた3つのサービスは、Amazon EC2 の Spot インスタンス と AWS Fargate の両方を活用できます。Spot インスタンスは割引価格で提供される余剰の EC2 キャパシティですが、2 分前の通知の後に中断される場合があります SageMaker、Batch、ParallelCluster はいずれも、Spot インスタンスの経済的メリットを活用できます。Spot インスタンスを使う場合、ワークロードが回収によるキャパシティ中断に耐えられるか、またはサービスが代替リソースへ自動的に移行してプロセスの中断を回避できるかを確認する必要があります。 MemVerge などの AWS テクノロジーパートナーは、 OSレベルのメモリチェックポインティング を活用してこの問題を処理できます。 Fargate はサーバーレスコンピューティングエンジンで、Batch with ECS、ECS および EKS クラスターのネイティブワークロードで使用できます。サーバーやインフラパラメータ（インスタンスタイプなど）といった設定なしにコンテナを実行できます。ただし、ハードウェア仕様に関する注意事項がいくつかあり、 ドキュメント で確認する必要があります。一般的に、研究では Spot インスタンスや Fargate を AWS オーケストレーションツールと組み合わせて使うことをお勧めします。 個人用クラウドデスクトップのための Amazon Lightsail for Research Amazon Lightsail for Research は、価格の予想がしやすく、事前にセットアップ済みであるクラウドデスクトップを求める研究者向けのシンプル(かつ強力)なソリューションです。研究に最適化されたハードウェア仕様と、シームレスなユーザー体験を提供するよう、特に研究者向けにカスタマイズされています。Lightsail は、研究者のニーズに合わせてカスタマイズ可能な、さまざまな事前構成済みの仮想プライベートサーバーを提供し、Scilab、RStudio などの研究アプリケーションが付属しています。使いやすいインターフェイスと手頃な価格設定により、Lightsail for Research は研究者が AWS を使い始めるための、信頼性と効率性の高いソリューションとなっています。 図4 – 研究者が Amazon Lightsail for Research の簡素化された管理インターフェースとオプションを使って、Jupyter、RStudio、Scilab などの好みのアプリケーションをデプロイできることを示しています。 クラウドデスクトップを大規模に管理するための Research and Engineering Studio on AWS Research and Engineering Studio on AWS (RES)は、管理者が安全なクラウドベースの研究開発環境を作成・管理するためのオープンソースのWebベースポータルです。複数の研究環境の基盤をITチームが簡単に管理できるよう設計されており、研究機関に最適です。ワンクリックでの迅速なデプロイが可能ですが、組織の特定のニーズに合わせてカスタマイズも可能です。 図5 – 研究者と管理者の両方が RES を活用して、Amazon EC2 でバックアップされた Engineering Virtual Desktops (eVDI)を作成できることを示しています。ここに示されている RES Virtual Desktop の画面には、ユーザーが作成したすべての eVDI セッションとそれらを起動、シャットダウン、または稼働時間をスケジューリングするための制御機能が一覧表示されています。 バイオインフォマティクスのための AWS HealthOmics AWS HealthOmics は、バイオインフォマティクス研究のための包括的なソリューションです。生のゲノムデータの保存と処理を容易にし、研究者はゲノムデータを保存して解析できます。 WDL や Nextflow などの一般的なバイオインフォマティクスワークフロー定義言語をサポートしており、研究者は効率的にゲノムデータを処理・解析できます。 HealthOmics では、研究者が独自のワークフローを持ち込むか、事前に構築された Ready2Run ワークフローを使用するかを選択できます。 Ready2Run ワークフロー は、Sentieon 社や NVIDIA 社などの業界をリードする第三者ソフトウェア企業によって設計されており、タンパク質構造予測のための AlphaFold などの一般的なオープンソースパイプラインが含まれています。Ready2Run ワークフローを使えば、ソフトウェアツールやワークフロースクリプトを管理する必要がなく、研究者は大幅な時間を節約できます。 図6 – AWS HealthOmics プラットフォームの構造を示しており、ゲノムデータの処理と解析機能が強調されています。生の配列データと参照データは、Nextflow または WDL ワークフローを通して処理された後、 Amazon Athena などの AWS 分析サービスで解析できます。 次世代サーバーレス技術の活用 この10年間、AWS はサーバーレスコンピューティングの分野を先駆けてきました。サーバーレスコンピューティングとは、サーバーインフラストラクチャを管理することなく、アプリケーションを構築・デプロイできるモデルです。パッチや監視などのオーバーヘッドを伴う仮想マシンを起動する代わりに、実行するコードやプロセスに集中できます。 これは、イベントハンドリングや非同期タスクなどのユースケースに適していますが、研究者はサーバーレスコンピューティングを活用して、ML のハイパーパラメータ最適化、ゲノム検索、さらには MapReduce などの並列性の高いワークロードの高速化にも利用してきました。 AWS Lambda は、サーバーを管理することなくコードを実行するためのサーバーレスインターフェースです。疎結合ワークロードに適した設計になっており、データの変更(またはデータの到着)などのイベントに応じてコードを実行できます。Lambda は自動的にスケーリングするため、数千の並列実行が可能です。 さらに良いことに、Lambda は200以上の他の AWS サービスと統合されているため、複雑なワークフローを構築しやすくなっています。 AWS Step Functions との統合も提供されており、視覚的にワークフローを作成し、マルチステップの分散アプリケーションを構築できます。Lambda と Step Functions を組み合わせることで、異なる計算ステップ、データニーズを含むワークロード、さらには承認プロセスや人的な入力が必要なワークロードにも対応できるようになります。 図7 – サーバーレスコンピューティングアーキテクチャのサンプルを示しています。処理されるジョブのデータストリームが AWS Lambda によってピックアップされ、ダウンストリームの Amazon SQS キューに入れられます。AWS Step Functionsはこのキューから読み取り、Lambda ワーカー関数を使った分散コンピューティングのオーケストレーションの重い作業を処理します。Step Functions はまた、ワークロードの状態管理に Amazon DynamoDB 、イベントハンドリングに Amazon EventBridge 、処理後の結果の保存にAmazon S3を利用しています。 まとめ：適切な選択をするために 適切な AWS コンピュートオーケストレーションツールを選ぶには、万能のソリューションを見つけるのではなく、ツールの機能をワークロードの特定の要件に合わせて考えることが重要です。プロジェクトの細かい点、データの性質、計算ニーズに基づいて決定する必要があります。 プロジェクトとの互換性とスケーラビリティを測るために、小さなワークロードから始めましょう。 AWS は包括的なサービススイートを提供しており、お客様の研究の境界を押し広げるために必要なリソースと環境を確保し、研究ジャーニーのあらゆるステップをサポートする準備ができています。 また、 AWS パートナーもこれらのツールの実装をサポートします。 Ronin や Ansys などのパートナーは、 AWS 上での研究の時間を短縮するための貴重な専門知識を提供します。 プロジェクトに最適な意思決定を行うために、研究チームと AWS 営業担当との相談をお勧めします。研究が進化するにつれ、 AWS のスケーラブルで多様なコンピューティング環境は、計算ニーズを満たすために必要なツールとサポートを提供し続けます。この記事で触れたいくつかのツールの細かい点についてより深く掘り下げるために、 Choosing between AWS Batch or AWS ParallelCluster for HPC 、 why you should use Fargate with AWS Batch 、 save up to 90% using EC2 Spot についての過去の記事をチェックすることをお勧めします。 Patrick Guha Patrick Guhaは、テキサス州オースティンを拠点とするAWSのソリューションアーキテクトです。彼は、クラウド上でゲノミクス、ヘルスケア、高性能コンピューティングのワークロードに注力する非営利の研究顧客をサポートしています。Patrickは電気・コンピュータ工学の学士号を取得しており、現在はエンジニアリングマネジメントの修士号の取得に向けて取り組んでいます。 Matt Bollinger Matt Bollingerは、AWSのシニアソリューションアーキテクトであり、地球観測と地球科学に重点を置く非営利の研究組織と協力しています。彼は、顧客がクラウドネイティブの実践を活用して問題を効率的かつ持続可能な方法で解決できるよう指導しています。 翻訳はソリューションアーキテクト池田が担当しました。原文は こちら です。 HPC全般に関するお問い合わせ窓口： aws-jp-hpc@amazon.com

2023 年 6 月 30 日（金）および 2023 年 12 月 7 日（木）に、メディア業界のお客様向けに AWS 勉強会を開催いたしました。両日共に放送局のお客様にご登壇いただき、 AWS の活用事例についてご紹介いただきました。登壇者の所属部署および肩書きは登壇当時のものとなります。 AWS メディア業界向け勉強会 #3 （2023 年 6 月 30 日開催） AWS の基盤を活用したディープラーニング系ハンズオンの取り組み 朝日放送テレビ株式会社 技術局 技術戦略部 荒木 優 氏 朝日放送テレビでは、人材育成と機械学習の中でもディープラーニングに関する知見の蓄積を目的とした、若手および中堅エンジニアから構成される AI 研究会を立ち上げました。ハードウェアを購入しなくても必要な環境が用意できること、クラウドの知識も同時に習得できることから、 Amazon EC2 の GPU インスタンス（G4 インスタンス） 上で環境の構築を行い、今後の放送での利用も見据えて、ディープラーニングを使ったモデルによる物体認識や顔認識などの画像認識の実証実験を行なっています。また、 AWS Amplify 、 AWS Cloud9 、 AWS CodeCommit などを用いることで、これらの活動で得られた知見や手順、ソースコードの管理もクラウド上で実現しています。 資料のダウンロードは こちら 動画の視聴は こちら AWS でLIVE 配信をやってみた 株式会社静岡第一テレビ 技術プロデュース局 技術プロデュース部 システム室 泉地 裕史 氏 静岡第一テレビでは、COVID-19 下の無観客試合の中でも全国高等学校サッカー選手権大会（以下、高校サッカー）を多くの視聴者の方に楽しんでもらうために、2021年に自社サイト内でのインターネット配信を実施しました。高校サッカーは3ヶ月間に渡って開催されるため、より運用負荷の少ない体制や配信基盤を選定する必要があります。そこで、簡単にセットアップが可能で、低コスト、かつトラフィックに合わせてスケールが可能な Amazon Interactive Video Service（Amazon IVS） を選択し、わずか1週間でのセットアップを実現しました。Amazon IVS を使用することで大規模な自社配信設備の構築が不要となり、また広告を挿入することでインターネット配信のマネタイズも実現しています。 資料のダウンロードは こちら 動画の視聴は こちら AWS メディア業界向け勉強会 #4 （2023 年 12 月 7 日開催） 話題の衛星通信サービスでIVSに映像を上げてみた～AWS＋低軌道衛星 ＝ 災害時の最強タッグ～ 関⻄テレビ放送株式会社 技術推進本部 DX推進局 DX戦略部 専⾨部⻑ 栗⼭ 和久 氏 災害報道を行う際には、さまざまな手段を組み合わせていかに中継現場から本社までの映像伝送路を確保するか、という点が重要です。そこで関⻄テレビ放送では、衛星通信サービスやモバイル映像中継ソリューション、 Amazon Interactive Video Service（Amazon IVS） を組み合わせて映像を伝送する実験を行いました。その結果、設定するパラメータによって、伝送路の安定性や遅延量が大きく異なることが分かりました。安定した伝送路が確立されると、映像の伝送だけでなく避難所向けの情報配信や行政情報の共有などにも使える可能性があり、これらの知見の蓄積をすることは非常に重要です。例えば本実験では約4秒のレイテンシーが観測され、これは Amazon IVS が謳う5秒未満のレイテンシーの範囲内に収まっていることが分かります。Amazon が計画中の低軌道衛星を用いたブロードバンドサービス Project Kuiper についても期待の声をいただきました。 1日最大150球場超！大規模配信を支える バーチャル高校野球ライブ配信 技術 の舞台裏 朝⽇放送グループホールディングス株式会社 DX・メディアデザイン局 R＆Dチーム 村中 貴彦 氏 朝日放送テレビでは、朝日新聞社と共同で高校野球の総合情報サイト「バーチャル高校野球」を運営しています。年を追うごとに配信試合数が増加し、2023年には地方大会全3434試合、全国大会48試合を配信。配信担当者のスキルに依存しない仕組みを実現するために、AWS マネジメントコンソールから設定やステータスの確認が可能である AWS Elemental Link  を導入し、これによりエンコーダーの集中管理が可能となりました。また、年々増加する試合数に対応すべく、オンプレミスソリューションの AWS Elemental Live に加えて、わずか数分で新たなライブチャンネルをデプロイ可能な AWS Elemental MediaLive を導入しました。ワークロードの冗長性を担保するために、2 つのエンコーディングパイプラインを持つ標準チャンネルを採用しています。 また、担当者間で配信スケジュールの共有を行うために Amazon EC2 、 Amazon RDS 、 Amazon ElastiCache などを用いた試合ステータス情報の管理システム ACOMS（Asahi Communication System）を構築しました。このシステムを用いることで、試合スケジュールや運用ステータスの管理が可能となり、Web サイトの運営から配信対応まで、各担当者が連携して作業を行えるようになったことで、運用負荷（1 試合単位の運用対応人数が従来の 50％ と半減）とトラブルの軽減を実現しています。 導入事例「 朝日放送グループホールディングス、AWS を活用し『バーチャル高校野球』で 1 日最大 156 球場での試合を大規模配信 」に詳細の記載がございますので、ぜひこちらもご覧ください。 まとめ メディア業界向け勉強会の開催概要をご紹介させていただきました。内容について詳しく知りたい方は、記事上部より資料のダウンロード及び動画を視聴いただけますのでご確認ください。引き続き業界の皆様に役立つ情報を、セミナーやブログで発信していきますので、どうぞよろしくお願い致します。 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWSのメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメールマガジンをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 この記事は SA 小南英司が担当しました。

AWS Summit Sydney (4 月 10～11 日) 開催がいよいよ 2 日後となり、 AWS Summit Singapore (5 月 7 日) と AWS Summit Bangkok (5 月 30 日) を皮切りとする東南アジアの AWS Summit シーズンも開催まで残すところあと 1 か月になりました。この期間にシドニー、シンガポール、バンコクにおられる場合は、ぜひ AWS Summit にご参加ください。 4月1日週のリリース 4月1日週の Weekly Roundup をまだお読みになっていませんか? この Roundup では、 Channy がエイプリルフールのネタとして、 Jeff Barr からの新しいイニシアティブ、AWS Chips Taste Test について書きました。 4月1日週のリリースのうち、私の目に留まったものをいくつかご紹介します。 新しい Amazon EC2 G6 インスタンス – NVIDIA L4 Tensor Core GPU を搭載した Amazon EC2 G6 の一般提供が発表されました。G6 インスタンスは、ググラフィック集約型のユースケースや機械学習のユースケースに幅広く使用することができます。G6 インスタンスは、Amazon EC2 G4dn インスタンスと比較して、深層学習推論やグラフィックワークロードで 2 倍のパフォーマンスを発揮します。詳細については、 Amazon EC2 G6 インスタンスページ を参照してください。 Amazon Bedrock で Mistral Large が利用可能に  –  Veliswa が、Amazon Bedrock サービスの一環として Mistral Large 基盤モデルが利用可能になったことに関する記事を書いています。Mistral Large は、非常に優れた推論能力を必要とする複雑なタスクを処理するために使用できます。さらに、 Amazon Bedrock は、欧州パリ AWS リージョンでも利用可能になりました 。 Amazon Redshift との Amazon Aurora ゼロ ETL 統合がさらに多くのリージョンで利用可能に – ゼロ ETL 統合に関する発表は、昨年のローンチの中でも私のお気に入りでした。このゼロ ETL 統合は、2 つのサービス間でのデータ転送プロセスを簡素化するため、お客様は手動で抽出、変換、ロード (ETL) を実行する必要なく、 Amazon Aurora と Amazon Redshift の間でデータを移動させることができます。今回の発表に伴い、Amazon Aurora と Amazon Redshift 間でのゼロ ETL 統合が 11 の追加リージョンでサポートされるようになりました。 AWS Deadline Cloud の発表  – 映画、テレビ番組、コマーシャル、ゲーム、工業デザインの仕事に携わっていて、2D や 3D のビジュアルアセットを作成するチームのための複雑なレンダリング管理に対処しているならば、AWS Deadline Cloud にぜひご期待ください。この新しいマネージドサービスは、メディアおよびエンターテイメントワークロード向けのレンダーファームのデプロイと管理を簡素化します。 AWS Clean Rooms ML の一般提供開始 – 2023年、私は AWS Clean Rooms ML のプレビュー に関する記事を書きました。その記事では、お客様とパートナーが未処理データを互いにコピーしたり共有したりすることなく集合データに機械学習 (ML) モデルを適用できるようにする、 AWS Clean Rooms の新しい機能について詳しく説明しました。この AWS Clean Rooms ML を、皆さんに利用していただけるようになりました。 Amazon Bedrock のナレッジベースが OpenSearch Serverless のプライベートネットワークポリシーのサポートを開始 – Amazon Bedrock で構築する皆さんに嬉しいお知らせです。これからは、プライベートネットワークポリシーを備えた Amazon OpenSearch Serverless (OSS) コレクションを使用する Amazon Bedrock のナレッジベースで検索拡張生成 (RAG) を実装できるようになります。 Kubernetes バージョンに対する Amazon EKS 延長サポートの一般提供開始 – Kubernetes バージョン 1.21 以降を実行しているならば、この Kubernetes の延長サポートにより、 Amazon EKS で最新の Kubernetes 機能とセキュリティ改善を用いて最新状態を維持することができます。 AWS Lambda が Ruby 3.3 のサポートを追加  – Ruby でコーディングしていますか? AWS Lambda がそのランタイムとして Ruby 3.3 をサポートするようになりました。この更新により、Ruby 言語の最新の機能や改善を活用できるようになります。 Amazon EventBridge コンソールの機能強化  – Amazon EventBridge コンソールがの新しい機能と改善で更新され、より優れたユーザーエクスペリエンスによってイベント駆動型アプリケーションの管理がさらに簡単になりました。 商用リージョンでの AWS マネジメントコンソールへのプライベートアクセス  – 社内ネットワークからの個人 AWS アカウントへのアクセスを制限する必要がある場合は、AWS マネジメントコンソールプライベートアクセスを使用できます。このローンチにより、すべての商用 AWS リージョンで AWS マネジメントコンソールのプライベートアクセスを利用できるようになりました。 community.aws より   community.aws は、ビルダーである私たちが AWS での構築で学んだ事柄を共有する場です。以下は、私が選んだ先週のトップ 3 記事です。 14 LLMs fought 314 Street Fighter matches.Here’s who won ( Banjo Obayomi 著) Build an AI image catalogue! – Claude 3 Haiku ( Alan Blockley 著) Following the path of Architecture as Code ( Christian Bonzelet 著) AWS のその他のニュース   興味深いと思われる追加のニュース記事、オープンソースプロジェクト、Twitch 番組をいくつかご紹介します。 Build On Generative AI  – Tiffany そして Darko とともに、生成 AI をより詳しく学び、デモを見て、ゲストスピーカーと生成 AI のさまざまな側面について話し合いましょう。毎週月曜日、米国太平洋時間午前 9:00 に Twitch でストリーミング配信中です。 AWS オープンソースに関するニュースと最新情報  – AWS コミュニティからのさまざまなオープンソースプロジェクトやツールをお探しなら、私の同僚である Ricardo が担当する AWS オープンソースニュースレターをお読みください。 近日開催予定の AWS イベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 AWS Summits – クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントに参加しましょう。 アムステルダム (4 月 9 日)、 シドニー (4 月 10～11 日)、 ロンドン (4 月 24 日)、 シンガポール (5 月 7 日)、 ベルリン (5 月 15～16)、 ソウル (5 月 16～17西)、 香港 (5 月 22 日)、 ミラノ (5 月 23 日)、 ドバイ (5 月 29 日)、 タイ (5 月 30 日)、 ストックホルム (6 月 4 日)、および マドリッド (6 月 5 日) から、最寄りの都市でご登録ください。 AWS re:Inforce – 6 月 10～12 日に米国ペンシルバニア州で開催される、ビジネスイニシアティブの推進を支援するように設計された 2 日半の没入型クラウドセキュリティ学習のための AWS re:Inforce で、生成 AI 時代のクラウドセキュリティに関する知識を深めましょう。 AWS Community Days  – 世界中の エキスパート AWS ユーザーと業界リーダーによるテクニカルディスカッション、ワークショップ、ハンズオンラボが提供されるコミュニティ主導のカンファレンスに参加しましょう。カンファレンスは、 ポーランド (4 月 11 日)、 サンフランシスコ・ベイエリア (4 月 12 日)、 ケニア (4 月 20 日)、および トルコ (5 月 18 日) で開催されます。 近日開催されるすべての 対面イベント と 仮想イベント を閲覧することができます。 4月8日週のニュースは以上です。4月15日週の Weekly Roundup もお楽しみに! –  Donnie この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

(左から、AWS ジャパン ソリューションアーキテクト 木村 公哉、AWS ジャパン スタートアップ事業開発 福井 健吾、東大 IPC 長坂 英樹、AWSジャパン 事業開発 田村 圭) 日本政府は成長と分配の好循環を目指す「新しい資本主義」の実現に向けて、社会課題の解決に取り組むスタートアップがそのドライバーであると捉えスタートアップへの支援を強化し、持続可能な社会を目指しています。さらに、スタートアップ育成5か年計画の中では、グローバル市場での優位性という観点から非言語技術の創出を目指しDeepTech（研究開発型スタートアップ）への支援に関する予算が多く割り当てられており、その成長に期待が寄せられています。 アマゾン ウェブ サービス ジャパン合同会社 （以下、AWSジャパン）は、クラウドを始めとした新たなデジタルテクノロジーを社会実装するうえで欠かせないのがスタートアップであると考え、過去10年以上にわたり数千におよぶ日本のスタートアップを支援してきました。その中でもDeepTech（研究開発型スタートアップ）支援に関連して、AWSジャパンは2022年9月につくば市と研究開発型スタートアップの成長加速に向けた連携、2023年9月に慶應義塾大学と大学発スタートアップ創出支援に向けた連携を発表し支援するなど、より良い社会と市民生活の実現に貢献すべく、様々な関係団体との連携を図っています。 東大IPC は、2016年、東京大学が100％資本を持つ投資事業会社として設立されました。投資事業、起業支援、DeepTech Diveの３つの活動を通して東京大学のイノベーションエコシステム拡大を担う機関です。 起業支援においては、東大のみならず東工大、一橋大、筑波大、東京医科歯科大、北海道大学、名古屋大学、神戸大学など国内14の大学と連携した国内最大級の大学横断型起業支援プログラム、「 1stRound 」を年2回実施しています。 このような背景からAWSジャパンは、本日、東大IPCと研究者・スタートアップの支援について連携して取り組んでいくことを発表しました。既に提供していたAWS利用枠（クレジット）に加えてよりDeepTechに特化したワークショップ、個別技術相談会、ネットワーキングイベントなどをご提供し、お客様のビジネス成長を支援します。AWSジャパンは、東大IPCとともに、国内の産業活性化の支援のみならず、グローバルの社会課題解決の支援に向けて取り組んでいきます。 この連携は、「1stRound」に採択された、あるいは申請した起業を目指す研究者に対する多角的な支援体制の構築を特徴としており、具体的には、主にAWSジャパンが提供する以下の3つの支援から成り立っています。 計算リソース提供： AWS Activate *プログラムを活用し、東大IPC関連スタートアップに対して、最大25,000アメリカドル分のAWS利用バウチャーや他のAWSサービスのディスカウントを提供 技術支援： DeepTechに特化したワークショップ、個別技術相談会を実施 GTM（Go To Market）支援：　ネットワーキングイベントなどを提供 東京大学協創プラットフォーム開発株式会社 代表取締役社長 植田 浩輔氏のコメント 東大IPCは、「1stRound」の活動をはじめ、大学、企業、VC、政府など幅広いステークホルダーと連携した世界と伍するスタートアップ創出・育成、エコシステム構築を通じて、世界における日本の産業競争力の強化に資するべく活動を展開しています。 グローバル、業界をリードするクラウドテクノロジーの提供及び知見を持つAWSジャパンとの連携によって、大学の優れたシーズの早期事業化の支援をさらに強力なものにします。そして、日本のディープテックの可能性を最大限に引き出し、グローバルでの課題解決を目指すスタートアップ創出、そしてイノベーション・エコシステム構築を目指して参ります。 アマゾン ウェブ サービス ジャパン合同会社 執行役員 パブリックセクター 統括本部長 宇佐見 潮のコメント 東大IPCとAWSジャパンの連携は、起業を志す研究者等や、創業間もないスタートアップ起業に対し支援を提供することで、東京大学を中心としたスタートアップ支援を強化するものです。DeepTechのポテンシャルを解放するべく、この連携により大学の成果研究が素早く社会実装されるモデルを構築し、国内の産業活性化のみならず、グローバルの社会課題解決に貢献したいと考えます。東大IPCとAWSジャパンが日本のイノベーション創出に貢献することを期待しています。 アマゾン ウェブ サービス ジャパン合同会社 スタートアップ事業本部　事業開発部長 Will Leeのコメント 日本のみならずアジア全域においてディープテックへの期待が高まる中、数々の研究シーズを社会実装された東大IPCと連携することでAWSジャパンがより幅広いスタートアップを支援できることを非常に楽しみにしております。日本のみならずグローバルな支援へと拡大できることを期待しております。 *AWS Activate は、スタートアップ企業のジャーニーでのあらゆるステップを簡素化するために設計された無料のツール、リソース、およびコンテンツを、ふさわしいスタートアップ企業に提供するものです。メンバーは登録後すぐに、AWS が厳選した、ビジネスおよび技術的なニーズに関するエキスパートのヒント、トレーニングとサポート、事前構築済みのインフラストラクチャテンプレートなどの特典を受け取ることができます。

左：アマゾン ウェブサービス ジャパン デジタルサービス技術本部 ISV/SaaS ソリューション部 本部長 上原 誠 右：株式会社 Works Human Intelligence Product Div. Advanced Technology Dept. Dept長/VPoT 加藤 文章 氏 AWS には Prototyping Program というお客様のプロジェクトの加速を支援するプログラムがあります。このプログラムでは AWS の Prototyping Engineer が、お客様の課題に合わせたシステムのプロトタイプを開発します。株式会社 Works Human Intelligence (以下、WHI) ではこれまで Prototyping Program を複数回活用しており、プロトタイピングという活動自体に有用性を感じていただき、社内で同様のプロトタイピングチームの立ち上げに取り組まれました。 今回は、WHI へのサポートを行うアマゾン ウェブサービス ジャパン デジタルサービス技術本部 ISV/SaaS ソリューション部 本部長 上原 誠が WHI Product Div. Advanced Technology Dept. Dept長/VPoT 加藤 文章 氏にプロトタイピングチーム立ち上げについてお話を伺いました。 本対談のサマリ 会社の主力製品の改善と保守に専念する開発チームとは別に、新しい技術の導入や新製品の開発を担当するプロトタイピングチームを立ち上げた。このチームでは、新しい技術の検証や新製品のプロトタイプを作成し、製品化の可否を早期に判断することができる。また、若手エンジニアの育成にも役立っている。プロトタイピングチームの活動を通して、技術的負債の解消や新しいビジネスチャンスの獲得が期待できる。今後は各製品チームにもプロトタイピングチームを設置し、全社的に新しい取り組みを推進していく計画である。 プロトタイピングチーム立ち上げのきっかけ 上原：プロトタイピングチーム立ち上げの背景を伺うにあたって、まずは WHI の会社概要などを簡単に教えてください。 加藤：WHI では COMPANY という製品を約 25 年前から作っています。この COMPANY という製品は大手企業向け HR 製品で、人事給与・ワークフロー・勤怠・タレントマネジメント（タレマネ）などのサービスがあります。元々はパッケージ製品で、現在は SaaS 化を進めている状況です。 上原：約 25 年間というとかなり長い年月ですね。アプリケーションもかなり大規模かと思います。アプリケーションの開発状況や今回のプロトタイピングに取り組んだ背景を教えてもらえるでしょうか？ 加藤：COMPANY は製品としての歴史が長く幅広い人事領域業務を網羅する大きな製品のため、ソースコードの量も多くなっています。そのため、 開発メンバーはその機能改善や保守を続けていくことに⼤きな⼯数を割いています。特に⼈事給与の領域は法改正対応が毎年入るためそれもかなりの⼯数を取られてる状況です。 一方で、人的資本経営が推進されている中で、HR 製品に対するお客様のニーズが多様化しており、これに応えるために機能追加や改善をしていく必要があります。そこで、生成 AI やブロックチェーンなどの新しい技術をいかに早く取り入れていくかが重要ですが、先ほどお話しした通り、どうしても既存機能の改善や保守には多くの工数がかかってしまうため、機能改善や保守をしつつ新しい技術の導入速度を高めるための取り組みを強化する必要がありました。これに対し、製品の保守をしているチームの外側から、プロトタイピングチームが新技術をどのように製品に取り入れるかの検証を早いサイクルで回していけるため、プロトタイピングチームはこの課題に有効な組織になると考えています。 上原：いわゆるスタートアップのような俊敏性を組織として持つようなイメージですね。 先ほどの背景や課題がプロトタイピングチームの立ち上げを検討するに至った経緯になるかと思いますが、実際に組織立ち上げに踏み切ったきっかけなどはありましたか？ 加藤：2023 年はじめに新たな経営戦略とビジョンが発表され、それに対して何か新しいことに取り組むことができないか悩んでいたところ、 WHI と AWS で新しい取り組みをできないか議論する会を AWS の営業さんから設定いただき、その後の懇親会で、上原さんとお話しして、悩みや思いなどに共感いただいたのをきっかけにこの取り組みに繋がりました。 上原：ちょうど 1 年ほど前に目黒の中華屋さんで意気投合して盛り上がって、プロトタイピングをやろうとなりましたね (笑) トップからのダイレクションがあって、何かしら具現化しないといけないという場面で、そこに AWS が関われたのは有り難かったです。具体的なアクションを共に議論して、組織立ち上げに貢献できたことは AWS としてもエキサイティングで嬉しいことでした。 上原：これまでの話に出てきた部分もありますが、あらためてWHI でのプロトタイピングチームはどのようなものを想定していて、どのようなメリットを期待されていましたか？ 加藤：プロトタイピングチーム立ち上げのメリットとして大きく 2 点を考えていました。 まず 1 点目は、多くの開発メンバーは COMPANY の保守開発がメイン業務であり、新しい技術を活用した機能改善にあまり取り組めていないので、そこに対するアプローチとして期待していました。 2 点目はエンジニアの教育に対するメリットです。現状、若手のエンジニアはコードを書く量が少なく、機能追加や不具合修正に対して、どう実装するかの設計やどういう機能を追加していくかなどで既存コードを確認する作業が多くなっています。そこで早いサイクルでコードを書く機会を作っていきたいと考えました。 上原：既存コードの改修も非常に重要なタスクですよね。そのため、相対的に新しい技術に触れたり教育したりする機会が少なくなってしまうのは難しい課題ですね。 立ち上げに向けての取り組み 上原：組織としてプロトタイピングチームを立ち上げることは簡単ではなかったと思います。実際にはどのように実現していったのですか？ WHI 社内での交渉など含めて、どのように立ち上げてスタートに至ったのか詳しくお伺いしたいです。 加藤：時期としては構想開始が 2023 年 2 月で、実際にチームが立ち上がったのは 2023 年 7 月なので、約 5 ヶ月間です。 2023 年 1 月から Tech Lead Dept. という部門の部門長を私が引き継いでいたのですが、部門 (Dept.) とその配下のグループ (Grp.) の名称と業務内容やミッションをより合致させていきたいという思いがありました。そこで、7 月に組織を大きく変えることを計画していました。その中で、どのように変えていきたいか、どのようなミッションを持たせたいかを各マネージャーや私の上長と会話していました。加えて、このプロトタイピングの活動もフィットしそうだったため、7 月の組織改変のタイミングで取り込めるように進めていました。 上原：プロトタイピングという新しい取り組みのため、それを理解してもらうことやマインドセットを変えるというのは難しかったと思います。どのようにこの取り組みの理解やマインドセットを整えていったのですか？ 加藤：すぐ失敗して取り組むという Fail Fast の考えを持っている適任のマネージャーがおり、ちょうど 5 月からリソースを割ける状況だったため、その方にプロトタイピングチームのマネージャーを依頼しました。そして、Training & Prototyping Grp. というグループ名で設立しました。また、マネージャーに加えてメンバーも 2 名に入ってもらいましたが、両名とも新しいものを取り入れるマインドを持っていて、そういうのが好きなエンジニアで適性があったというのも大きいですね。 上原：なるほど、素養がある方をアサインしたのですね。適正のあるメンバーがいなければ考え方からインプットする必要があるので、そこがクリアできていたのは大きいですね。 今後は、メンバーの拡充などは考えているのですか？ 加藤：実は既に 1 名追加しています。中途で新しく入ってきたエンジニアが、適性があり相性が良かったのでこのチームに入ってもらいました。チームを徐々にストレッチさせているところですね。 上原：入社後にまずはプロトタイピングを 1 件こなすというオンボーディングプロセスの一環にしてみるのも面白い考えかもしれませんね。 加藤：そうすると Training & Prototyping Grp. というグループ名にもある通り、育成という目標も相性良く達成できそうです。 実施したプロトタイピングとそこでの反応 上原：具体的に実施されたプロトタイピングの内容を教えてください。 加藤：チーム立ち上げ後の 2023 年 7 月から 2024 年始めまでに完了したプロトタイピングは 2 件で、AWS のソリューションアーキテクト 松岡さんにも支援いただきました。 1 件目はタレントマネジメントシリーズの研修管理製品の連携機能に取り組みました。タレマネチームには若手のエンジニアがいたので、プロトタイピングチームと一緒になって素早く完了させました。7 月末から始まって、9 月には完了しています。タレマネチームに引き継ぎも完了して、Training の役割も果たせていると言えます。 上原：当初の目標であった Training の役割も果たせているのは素晴らしいですね。2 件目はどういったものだったのでしょうか？ 加藤：2 件目は職歴・学歴などの経歴情報の信頼性を担保する機能の検証です。結果的に、フレームワークが未成熟だったり、仕様が固まっていなかったりして、すぐに製品化は難しいという意味で失敗にはなりましたが、Fail Fast の考えですぐに失敗できたおかげで、時期を見て再開するという判断材料になりました。 上原：まさにプロトタイピングの考えに基づくものですね。新しい技術を取り入れる際に失敗は必ずあり得ることだと思います。その失敗についてはどう捉えていますか？ 加藤：早めに失敗できてよかったです。その技術の採用を決定してから失敗するのは影響が最も大きいので、早めに判断ができてよかったです。 上原：事業部がやると決定してから戻すのは難しいと思うので、プロトタイピングで判断出来たのは大きいですね。 加藤：元々 4 週間ほどで判断する予定だったのですが、実際やってみると多くの調査が必要で長期化してしまいました。 なんとか実現しようとメンバーが尽力してくれた結果、仕様の深い部分の調査などが発生して、そこまで深くやり始めると時間がいくらあっても足りないという状況になりました。実現できるように深い部分の調査をするのは非常に重要ですが、早期に可否の判断を下すこともプロトタイピングの目的であるので、なんらかの区切りを設けてその範囲内でできる限りのことをやるといった工夫が必要だなと感じました。 そういった点で、AWS のプロトタイピングでやられているように、期間を区切るというのはとても重要だと思いました。今後は適切に期間を区切って実施した上で、判断材料にできれば良いなと思っています。 上原：なんらかの区切りは必要ですよね。リソースを無限にかける訳にもいかないですし、どこかで成否を判断しなければいけないので。複数回のプロトタイピングを実施したからこその学びですね。 では、実際にプロトタイピングを実施したメンバーは、どのような反応や感想だったのでしょうか？ 加藤：今までこのような取り組みがなく手探りでの挑戦だったのですがメンバーからはポジティブな意見が多かったです。プロトタイピングの依頼を受けて実装し、引き継ぐためにドキュメントをまとめる、といった作業を期間を区切って実施することはメンバーにとって新しい経験で面白かったようです。 また、案件が完了するとその後すぐに別件が入ってくるという点に対して、「自分の特性に合っていて楽しい」というメンバーからの声も上がっています。ビジネスを形にしていくという重要な領域を担っている点にもやりがいを感じているようです。 上原：エンジニアにとって良い刺激にもなっているのは嬉しいです。 今回のプロトタイピングチーム立ち上げに対しての AWS からのご支援はいかがでしたか？ 加藤：とても良かったです。 AWS もリーダーシップ・プリンシプルの中で「Customer Obsession」を掲げており、お客様目線を持たれていると思いますが、今回の支援はまさにこちらの課題を聞いてもらって、一緒に解決に向けて伴走してくれていると感じました。 上原さんをはじめ、実際にプロトタイピングを実施した松岡さんと一緒にやれて良い経験になりました。 プロトタイピング実施とチーム立ち上げの成果 上原：プロトタイピングで当初想定していたような成果がありましたか？実際のアウトプットやメンバーの成長など加藤さんにとっての成果を教えてください。 加藤：2 件のプロトタイピングで新機能や新製品の開発の加速に寄与できました。お客様に早く良いものを提供できるようにすることがプロトタイピングで真に実現したい事なので、そこに貢献できたのは成果と言えます。 上原：AWS の Prototyping では Culture of Experimentation というマインドセットがあります。正にこれに通ずる考えだと思いました。AWS には Prototyping Program を提供するプロトタイピングチームがあり、私のチームにも同様のプロトタイピングチームを立ち上げていて、両方のチームで一貫しているのはこの Culture of Experimentation というマインドセットを大事にしている点です。これは、細かい試行を積み重ねることで、結果としてより良いサービスをより早く作ることに繋げるという考えです。 加藤：正に WHI でも重要視している点と同じですね。 上原：別の観点で、新しい技術を取り入れることは技術的負債に対しても重要な要素の1つかと思うのですが、プロトタイピングでの新しい取り組みは技術的負債の解消に繋がっていくものでしょうか？ 加藤：現在、プロトタイピングチームには新しい製品を早く作るという役割で動いてもらっていますが、今後は既存の各製品に対してプロトタイピングチームが連携することで、負債の解消に寄与できると思います。コードは書いた瞬間から負債と言われるので完全に解消するとは言いづらいですが、古くなってしまったものを新しく変えていく際にプロトタイピングチームが貢献できると考えています。 上原：既存のコードを置き換えていくのは大変な作業だと思うのですが、理想的には開発プロセスの中で負債がたまらないようにしていくのがベストだと思っています。そのプロセスの中にプロトタイピングをうまくはめ込めると良さそうに感じましたが、プロトタイピングを開発プロセスの中に入れ込めそうですか？ 加藤：入れ込めはするのですが、プロトタイピングとは別で技術的負債を解消するプロジェクトが動いており、それらはプロセスに組み込もうとしています。そのプロジェクトで実現が難しい場合にピンポイントでプロトタイピングチームが入って連携するという形の方が有効かなと思います。 上原：プロトタイピングを組織的に取り組んできたことで、様々な気づきや学びがあったことが分かりました。 今回の活動を経て、プロトタイピングがどのようなフェーズの組織にフィットしそうかという感触があれば教えてください。 加藤：WHI のように主力製品を持っていて、その主力製品の改修にリソースを多く割いているが、何か変えなければいけないという課題を抱えている会社にフィットするかなと思います。また、それに対して何かを変えることにトップが積極的な会社だとより良いと思います。 上原：仰る通りですね。トップから「プロトタイピングチームを組成することがメインプロダクトの開発リソースが減る」と見られると難しいですよね。トップも含めて Culture of Experimentation の考えを持っているかが大事そうですね。 WHI は会社の規模が大きく、エンジニアも多いかと思いますが、どのような規模感の組織にフィットしそうでしょうか？ 加藤：ある程度成熟したプロダクトを持っている企業が良いのではないかと思います。スタートアップなどの組織は通常の開発業務自体がプロトタイピングのような動きに当たるのでプロトタイピングチームは不要だと思います。 また、余力があることも重要ですね。主力製品で収益が出せているからこそ、プロトタイピングなどにリソースを割くことができると思います。 今後の展望 上原：プロトタイピングチームの今後のプランや展望などはありますか？既に人員増加など進んでいると思うのですが、ビジョンがあれば教えて下さい。 加藤：プロトタイピングチームの考えなどは COMPANY のエンジニアにはまだ広まっていませんが、この考えを全エンジニアに広げて、将来的には各部署にプロトタイピングチームを作って、それを教育機関としていきたいと思っています。 上原：集約ではなく各部門に配置するんですね？ 加藤：そうですね。製品群がいくつかある中で、集約して横断的に見る役割を持ったプロトタイピングチームも必要ですが、各製品のアーキテクチャや技術にフォーカスして革新していく際には各組織に閉じてプロトタイピングチームがある方がスピード感を持って早いサイクルで実施できると考えています。 上原：部門ごとの技術スタックや環境に合わせるために、教育機関として各部門に置くのは納得感がありますね。 既存の開発チームとの棲み分けはどのように考えられていますか？ 加藤：各製品を開発しているエンジニアは改修や不具合修正に多くの時間を割いており、新しい機能追加や改善をしたい思いはある一方で、そのチームにいるとそこに時間を割く余裕がないというのが実情です。なので、プロトタイピングを行うグループとして、既存コードの改修以外の機能追加など新しいことに取り組める組織を作るのは有効だと考えています。 上原：人気のグループになりそうですね。 加藤：そこに入りたくて頑張るという雰囲気を作れたら嬉しいですね。そして、プロトタイピングのメンバーを固定せず、ローテーションでみんなにやってもらいたいと思っています。 上原：エンジニアのモチベーションに繋がり、教育の役割も果たせると素晴らしいですね。進展ありましたら是非聞かせてください。 本日はお話を伺わせていただきありがとうございました。引き続きご支援・ご連携させてください。 —- 本ブログの執筆はソリューションアーキテクト 松岡勝也、撮影はソリューションアーキテクト 伊藤威・山崎宏紀が担当しました。

IoT (Internet of Things: モノのインターネット) デバイスの数が指数関数的に増加するにつれ、企業では、さまざまな地理的地域にわたる IoT フリートを管理するために、位置情報を活用できる高度なツールが必要になります。デバイスの位置を知ることは、資産管理や盗難検出のためだけでなく、デバイスが動作していない場合にタイムリーな改善措置を講じるためにも重要です。さらに、位置情報とデバイス状態のメタデータを組み合わせることで、位置固有の接続問題を検出したり、位置別の利用の傾向を理解するなど、IoT フリートについてより深い洞察を得ることができます。例えば、自動販売機や広告キオスクを運営している場合は、ユーザーの利用が多い地理的位置に基づいて、フリートの拡大、アップグレード、広告を優先的に行うことができます。 AWS IoT Device Management の位置インデックス化とジオクエリ機能により、デバイスの最後に報告された位置に基づいてデバイスを検索できます。また、位置情報を活用して、IoT フリートの管理と監視活動を強化することもできます。この位置インデックス化とジオクエリ機能により、特定の地理的領域内に位置するデバイスをリストアップしたり、基準位置に対する近接検索を行ったり、ターゲットを絞った Over-The-Air (OTA) でのアップデートを実装したり、位置に応じたデバイスのパフォーマンス分析を行ったり、望ましい地理的境界外にあるデバイスを特定したりできます。 このブログでは、位置情報データのインデックス作成とジオクエリの使い方を学び、日々の IoT フリート管理業務をサポートする方法を解説します。 フリートインデックスとジオクエリの概要 AWS IoT Device Management は、大規模な IoT デバイスをリモートで監視・管理するためのフルマネージドクラウドサービスです。フリートインデックス機能を使って、 AWS IoT レジストリ 、 AWS IoT Device Shadow 、 AWS IoT の接続性 、 AWS IoT Device Management ソフトウェアパッケージカタログ 、 AWS IoT Device Defender での違反 などの IoT データソースにまたがるメタデータに基づいてデバイスをインデックス化、検索、集約、グループ化できます。位置情報インデックスとジオクエリを使えば、特定の洞察や監視のために位置情報で絞り込めます。 図 1: AWS IoT Device Managementを使用して位置情報を収集、インデックス化、活用するためのリファレンスアーキテクチャ 図 1 は、AWS IoT サービスを使用して位置情報を取り込み、インデックスを作成し、活用するためのリファレンスアーキテクチャを示しています。検索で位置データを使用するには、デバイスの位置情報 (緯度と経度) を 従来のシャドウまたは名前付きシャドウ に保存し、AWS IoT Core Settings で 位置データのインデックス作成 を有効にする必要があります。位置情報は、4 つのサポートされている位置データフォーマットのいずれかに格納できます (詳細については、 サポートされているデータフォーマット を参照してください)。グローバル ポジショニング システム (GPS) が組み込まれていないデバイスの場合は、 AWS IoT Core の Device Location 機能を使用してデバイスの位置を解決できます。次に、 AWS IoT Rules Engine を使用して、デバイスの位置を従来のシャドウまたは名前付きシャドウに格納できます。位置データが IoT デバイス管理サービスによってインデックスされると、Amazon CloudWatch でデバイスフリートの全体的な状態を監視したり、Amazon API Gateway を使用して近くのデバイスを照会したり、デバイスフリートの位置情報に基づく分析と洞察を生成するなどの複数のダウンストリームアプリケーションで使用できるようになります。 ジオクエリでは、フリートインデックスの既存の検索と集約のための API が使用され、さらに入力パラメータ geodistance が追加されています。この geodistance のパラメータは、指定された緯度と経度の座標からの検索半径の境界を指定します。ジオクエリは フリートメトリクス と Amazon CloudWatch と組み合わせることで、時間の経過に伴うトレンドを分析し、事前に定義された閾値に基づいてフリートの状態を監視するためのアラームを作成できます。他の例としては、需要の高い場所で特定の時間に利用可能な電動バイクの数を見つけること、EV 充電器の可用性 KPI を監視すること、デバイスが設置場所から移動したときに警告を受け取ること、規制機関に決済端末の場所を報告すること、太陽電池のパフォーマンスに関する位置に敏感な洞察を生成すること、温度や湿度などの地理的要素によるデバイスの故障を診断することなどが挙げられます。 ジオクエリの概要 次のセクションでは、地理空間クエリ機能の一部を紹介します。この手順では、EV 公共充電インフラのグローバルプロバイダー向けのシステムを開発します。この例では、異なる種類のコネクター、定格電力、充電速度を持つ EV 充電器を提供します。地理空間クエリを使用すると、次のビジネス要件に対応できます。 付近のロケーションにある充電器をニアリアルタイムで発見できる機能。 特定の SLA を維持できるよう、利用可能な充電器の数を監視する。 日々の取引量が一定の基準を超えるチャージャータイプ (レベル 1、レベル 2、レベル 3 – 異なる充電速度を表す) の分布を特定する。 前提条件 以下の手順を完了する前に、次の準備をしておく必要があります。 AWS IoT Core と AWS IoT デバイス管理でアクションを実行するアクセス権と許可を持つ AWS アカウント。 AWS IoT Core でロールを作成および割り当てる IAM (AWS Identity and Access Management) の権限。 AWS CloudShell へのアクセス、および Linux と AWS コマンドラインインターフェイス (AWS CLI) の基本的な知識。 ウォークスルー 初期設定と構成 この節では、EV 充電器を表すための一連のモノを AWS IoT Core に作成します。スクリプトとコードは us-east-1 リージョンを使用します。スクリプトは、モノを作成し、充電器仕様に関連するメタデータを生成します。また、充電器の位置と使用状況に関するデータを含む chargerusage という名前つきシャドウを生成します。最初のセットアップと地理クエリを実行するには、 us-east-1 の CloudShell を使用してください。 AWS Management コンソールにログインし、 CloudShell を開いてください。 次のコマンドを実行して、スクリプトをダウンロードするため Git リポジトリをクローンします。 $ git clone https://github.com/aws-samples/aws-iot-device-management-geoquery.git createResources.sh スクリプトを実行して、EV 充電器のフリートを作成します。 以下のコマンドで指定されているパラメータを使用すると、AWS IoT Core に geoquery-test- という名前の 10 個のリソースができます。 このスクリプトは、後続のスクリプトで使用される一時ファイルもローカルディレクトリに生成します。 $ cd aws-iot-device-management-geoquery $ bash createResources.sh geoquery-test 10 注: 出力でエラーが表示された場合は無視してください。 An error occurred (ResourceAlreadyExistsException) when calling the CreatePolicy operation: Policy cannot be created - name already exists (name=blog_fi_geoquery_policy) updateShadows.sh スクリプトを実行して、モノのシャドウドキュメントを更新します。 $ bash updateShadows.sh フリートインデックスを設定する AWS マネジメントコンソールに移動し、AWS IoT Core を検索してください。 AWS IoT Core ( us-east-1 リージョン) で、左ペインの 設定 を選択します。 フリートのインデックス作成 セクションに移動し、 インデックス作成の管理 を選択します。 モノのインデックス作成 と モノの接続の追加 のチェックボックスを選択します。 画面の一番下に移動し、 更新 を選択します。 次のコマンドを実行して、インデックスの状況を確認します。 $ aws iot describe-index --index-name "AWS_Things" --region us-east-1 indexStatus が ACTIVE になるまで待ちます。 再度 インデックス作成の管理 を選択します。 名前付きシャドウの追加 のチェックボックスを選択します。 名前付きシャドウの選択 の下に chargerusage が表示されない場合は、 モノでシャドウ名を参照 を選択します。 前のセクションで作成された、いずれかのモノを選択します。 リストから chargerusage を選択し、 シャドウ名の追加 を選択します。 インデックスの位置データ に移動し、 新しいフィールドの追加 を選択します。 データパス に shadow.name.chargerusage.reported.config.location を追加します。 シーケンス ドロップダウンリストから Lat, long を選択します。 集計用のカスタムフィールド に移動し、 新しいフィールドの追加 を選択します。 フィールド名 に attributes.type を追加し、 フィールドタイプ ドロップダウンリストから String を選択します。 画面の一番下に移動し、 更新 を選択します。 図 2: フリートインデックスを有効化する AWS IoT Core の設定 ユースケース 1: 近接検索 この節では、 SearchIndex API を使用して、車両所有者が自身の EV に適した近くの充電スポットを見つける方法を実演します。この例では、次のことを前提としています。 このクルマはレベル 1 とレベル 2 の EV 充電器に対応しています。 このクルマは搭載の GPS モジュールにより、現在の緯度経度 (37.723028, -122.375811) を認識しています。 クルマの所有者は、クルマの現在位置から半径 15 マイル以内の適切な充電器を探したいと考えています。 前のステップで使用した CloudShell に移動します。 コマンドプロンプトで次のコマンドを実行します。 aws iot search-index \ --index-name "AWS_Things" \ --region us-east-1 \ --query-string "( \ attributes.type:Level_1 OR attributes.type:Level_2) AND shadow.name.chargerusage.reported.usage.isOnline:true AND shadow.name.chargerusage.reported.config.location:geo_distance,37.723028,-122.375811,15miles" JSON 形式の出力には、クエリ条件を満たす全ての充電器のリストが表示されます。参考のために、出力を一部省略して示します。出力の値は変わる可能性があります。 図 3: search-index クエリの出力 ユースケース 2: 位置情報に基づくフリート監視 このステップでは、フリートインデックス機能のフリートメトリクスを使用して、関心のある地理的領域内の稼働中の EV 充電器の数を監視します。 前のステップで使用した CloudShell に移動します。 以下のコマンドをコマンドプロンプトで実行して、フリートメトリクスをセットアップします。一度作成されると、このフリートメトリクスは 60 秒ごとにデータポイントを生成し、サンフランシスコ (37.723028,-122.375811) から半径 50 マイル以内で電源が切断されている充電器の数をカウントします。 aws iot create-fleet-metric \ --metric-name "OfflineChargers" \ --region us-east-1 \ --query-string " shadow.name.chargerusage.reported.usage.isOnline:false AND \ shadow.name.chargerusage.reported.config.location:geo_distance,37.723028,-122.375811,50miles" \ --aggregation-type "name = Statistics,values = count" \ --aggregation-field "registry.version" \ --period 60 フリートメトリクスをセットアップすると、 OfflineChargers メトリクス が毎分 CloudWatch に送信されるため、それを確認できます。 また、このメトリクスに対して CloudWatch アラームを設定できます。アラームの作成手順は CloudWatch でフリートメトリクスを表示する をご覧ください。 CloudWatch で設定したアラーム閾値を超えると、保守チームへの警告のために複数の通知とチケット作成アクションがトリガーされます。同じプロセスで、異なるクエリ基準を使用して追加のフリートメトリクスを作成できます。 ユースケース 3 : 位置情報に基づく集約情報/洞察 このセクションでは、 GetBucketsAggregation API を使用して、一日あたりのトランザクション閾値を超える充電器の分布を、充電器タイプ (Level_1、Level_2、Level_3) に基づいて確認します。 前のステップで使用した CloudShell に移動してください。 コマンドプロンプトで次のコマンドを実行します。このクエリは、サンフランシスコ (37.723028,-122.375811) の 50 マイル以内にあり、1 日に 25 件を超えるトランザクションがあった充電器を集計します。 aws iot get-buckets-aggregation \ --index-name AWS_Things \ --region us-east-1 \ --buckets-aggregation-type "termsAggregation={maxBuckets=5}" \ --query-string "shadow.name.chargerusage.reported.usage.dailySessions> 25 AND shadow.name.chargerusage.reported.config.location:geo_distance,37.723028,-122.375811,50miles" \ --aggregation-field "attributes.type" 出力は以下の図 4 のようになります。この図は、基準を満たす Level_1、Level_2、Level_3 の充電器の数を示しています。「数」は、デプロイ時によって異なる可能性があります。 図 4: GetBucketAggregation クエリの出力 クリーンアップ これらの演習を完了したら、追加コストの発生を避けるために以下を行ってください。 フリートインデックスを今後使用しない場合、機能をオフにします。 AWS IoT Core ( us-east-1 リージョン) で、左側のメニューから 設定 を選択します。 フリートインデックス作成 セクションに移動し、 インデックス作成の管理 を選択します。 モノのインデックス作成 のチェックボックスの選択を外します。 画面下部に移動し、 更新 を選択します。 cleanupResources.sh スクリプトを実行して、作成した AWS IoT モノを削除します。 $ bash cleanupResources.sh さいごに このポストでは、AWS IoT Device Management を使用してデバイスフリートの位置情報データを検索および監視する方法を学びました。フリートのインデックス作成を構成してデバイスの位置データをインデックス化する方法、インデックス化された位置情報データから洞察を導き出す方法、フリートメトリクスを利用してデバイスフリートを監視し、そのトレンドを表示する方法を学びました。このサンプルを拡張して、クローンした GitHub プロジェクトの aws-iot-device-management-geoquery ディレクトリにある ShadowClient.py を変更することで、充電器のシャドウ (位置、使用状況、可用性データ) を動的に更新したり、フリートデータに位置ベースの分析を実行して位置ベースの接続切断パターンを特定したり、指定された地理的範囲内のデバイスに対して OTA アップデートの対象とすることができます。さらに、AWS IoT Core Device Location の位置解決機能を活用して、GNSS/Wi-Fi/セルラーメタデータから位置情報を解決し、その後位置情報データをインデックス化してジオクエリを利用できます。詳細については、 AWS IoT Developer Guide の 位置情報データのインデックス化 を参照するか、 コンソールにログイン して利用を開始してください。 著者略歴 Reetesh Varshney Reetesh is an IoT Specialist at Amazon Web Services. He works with customers across industry verticals and supports their IoT-enabled business opportunities and the technology that drives their IoT solutions. He has helped customers to develop AWS IoT solutions for Smart Connected Products, Connected Vehicles, and Smart Factories Satej Sawant Satej Sawant is a Software Engineer at Amazon Web Services. He works on AWS IoT Device Management that helps customers remotely search, monitor, and manage their IoT devices at scale. Surabhi Talwar Surabhi Talwar is a Sr. Product Manager at Amazon Web Services. She focuses on AWS IoT Device Management that helps customers remotely search, monitor, and manage their IoT devices at scale. Prior to AWS, Surabhi worked in systems engineering and product strategy at Dish Network, Ericsson, and Meta, and in the telecommunications and media space. この記事は Use location data with AWS IoT Device Management to monitor and manage your IoT fleet の日本語訳です。エンタープライズ事業本部 ソリューションアーキテクトの中西 貴大が翻訳しました。

近年、医療分野でもクラウドサービスの活用が進んでいます。しかしながら、医療情報の取り扱いには細心の注意が必要です。そこで策定されたのが、厚生労働省より策定された「 医療情報システムの安全管理に関するガイドライン 」（以下厚労省ガイドライン）と経済産業省・総務省より策定された「 医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン 」（以下２省ガイドライン）です。これら 2 つを合わせた 2 つのガイドラインのことを通称３省２ガイドライン、もしくは医療情報ガイドラインと呼びます。 本ブログシリーズでは、ガイドラインの改定のポイントをまとめると共に AWS における医療情報システム構築における技術的なポイントについても取り上げていきます。第 3 弾となる本ブログでは、この医療情報ガイドラインをクラウド上での実践例を解説します。特に、システム事業者の立場から見たガイドライン対応のポイントを概要編と詳説編に分けて整理していきます。 概要編では対応方針の全体像を解説し、詳説編で各ステップごとの具体的な進め方について解説します。なお、本ブログのコンテンツは医療情報ガイドライン準拠を保証するものでは無く、ガイドライン準拠におけるヒントを提示することを主目的としています。 本ブログシリーズの各種リンクはこちら。 医療情報ガイドラインの改定から読み解くクラウド化 医療情報ガイドラインをクラウド上で実践する – ネットワーク編 Part 1 医療情報ガイドラインをクラウド上で実践する -概要編- 医療情報ガイドラインをクラウド上で実践する -詳説編- ガイドライン対応する上での課題 医療情報ガイドラインは、医療情報と呼ばれる患者情報を扱う情報システムの適切な管理・運用方法を定めたものです。具体的には、診療録や検査画像、看護記録など、患者に関する様々な医療情報を対象としています。医療情報ガイドラインについての概要については本ブログシリーズの第 1 弾 「医療情報ガイドラインの改定から読み解くクラウド化」 を参照ください。 この中でも特に、システム・サービス提供事業者向けに策定されているガイドラインが経済産業省・総務省より策定された「 医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン 」（以下 2 省ガイドライン）です。2 省ガイドラインでは、下記のように策定方針が定められており、過去のガイドラインと同等の安全管理水準は保ちつつも一律に要求事項を定めることはしないといった言及がされています。その達成する方針としてリスクマネジメントプロセスの定義がされています。 他の規格・ガイドラインとの整合性の確保に留意しながら、過去のガイドラインの要求事項と同等の安全管理水準が確保されるようにする 医療情報システム等の特性に応じた必要十分な対策を設計するために、一律に要求事項を定めることはせず、リスクベースアプローチに基づいたリスクマネジメントプロセスを定義する セキュリティ対策の妥当性と限界について、正しい共通理解と明示的な合意のもと医療情報システム等を運用するために、リスクコミュニケーションを実施できるようにする 医療情報システム等に関連する法令の求めに対して、セキュリティ対策の抜け漏れを防止するために、医療情報の取扱いにおいて留意すべき点や制度上の要求事項を明らかにする 医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン 1.1 版 （p.4) より抜粋 このように、一律の要求事項を定めないリスクベースアプローチによりクラウドやオンプレミスといった医療情報システムなどの特性に応じた柔軟なシステム設計が可能になりました。一方で、画一された要求事項が定まっていないことにより「どこまでやれば対応したと言えるのかが分からない」「リスクベースアプローチと言うが、具体的にどうやって対応を始めればいいのか分からない」と感じるサービス提供事業者もいらっしゃいます。我々ソリューションアーキテクトに対しても日々このような問い合わせをいただきます。 このあとの章では、医療情報ガイドラインの対応例について触れながら事業者としてのの対応方針に触れていきます。医療機関側から見た対応例については別ブログで取り上げる予定です。 サービス提供事業者が果たす責任 2 省ガイドラインによるとサービス提供事業者は、法律的観点から下記の義務を負います。 個人情報保護法に基づき、医療情報の善管注意義務・守秘義務・安全管理措置を講じる義務がある。 委託契約に基づき、医療機関等が患者に対する安全管理義務を履行するために必要な情報を適時適切に提供する義務がある。 情報セキュリティ事故発生時には、個人情報保護法に基づき危機対応義務と報告・通知する義務がある。 また、医療情報システム等の一連のプロセス（ガイドライン本文ではライフサイクルと表記）における義務と責任として、「対象事業者は説明義務を果たすために、医療機関等との間で「共通理解」と「明示的な合意」の形成を行う」必要があります（ 医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン 1.1 版 p.14-p.19）。 上記の義務を遂行する中で、医療機関等への情報提供と合意形成を行うことは必須です。この適切な合意形成をするにあたって、作成する資料の例として「サービス仕様適合開示書」や「サービスレベル合意書 (SLA)」等があります。これらの文書では、サービスの概要や性能、セキュリティ対策、障害時の対応等について詳細に記載する必要があり、合意形成を行う上で重要な書類となります。ガイドラインではこれらの文書に加えて共通理解を形成することの重要性を説いています。 さらに、厚労省ガイドラインにおいて事業者確認用の「 医療機関におけるサイバーセキュリティ対策チェックリスト 」や「 （事業者確認用）薬局におけるサイバーセキュリティ対策チェックリスト 」において医療情報セキュリティ開示書（MDS/SDS）の提出に関するチェック項目が盛り込まれています。 上記で言及された書類を作成していくフローの具体例に触れます。あくまで一例ですので、 冒頭の繰り返しになりますが絶対的な正解ではなく読者のみなさまがガイドライン対応を進める方針を策定する際の参考にしていただくことを目的 としています。 リスクマネジメントプロセスフローの概要 2 省ガイドライン本編では対象事業者が行うべきリスクマネジメントプロセスのステップとして「リスク特定」「リスク分析」「リスク評価」「リスク対応の選択肢の選定」「リスク対応策の設計・評価」「説明・合意形成」に言及してます。これらを大まかに分類して整理すると下図で示したフローになります。 医療情報システム向け AWS 利用リファレンス 概要資料と２省ガイドラインの中身をベースに作成 各種ステップをまとめて大きく「リスクアセスメント」「リスク対応「リスクコミュニケーション」と３つのフェーズに分けています。リスクアセスメントフェーズでは、医療情報システム等を提供する中でのリスクの特定・分析・評価を通じて対応すべきリスクについての洗い出しを行います。次のリスク対応フェーズでは、洗い出されたリスクに対しての具体的な対応方針を決め、それぞれのリスクに対する対応と残存リスク等に関しての文書化を目指します。最後のリスクコミュニケーションではリスクアセスメント・リスク対応で作成した文書化などを通じて、医療機関等との間での役割分担・受容したリスク内容等について必要な情報を説明した上で合意形成を行います。 まとめ 概要編となる本ブログでは医療情報ガイドラインの概要とサービス提供事業者の立場からの対応方針の概要について概説しました。次の 詳説編 では、リスクマネジメントプロセスの各段階の具体的な進め方ついて、リスクアセスメント、リスク対応、リスクコミュニケーションの各プロセスの実践的な進め方を解説します。 著者について 尾原 颯 (Ohara, Soh) は AWS Japan にて主にヘルスケア系スタートアップに対して技術支援をしています。好きなサービスは Amazon SageMaker と Amazon HealthLake です。 片山 洋平 (Yohei, Katayama) は AWS Japan のパブリックセクターのソリューションアーキテクトです。主に医療機関をはじめとしたヘルスケア業界のお客様のソリューション構築の支援を行なっています。週末は登山を嗜んでいます。

本ブログシリーズでは、厚生労働省より策定された「 医療情報システムの安全管理に関するガイドライン 」（以下厚労省ガイドライン）と経済産業省・総務省より策定された「 医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン 」（以下２省ガイドライン）を合わせた通称３省２ガイドライン（医療情報ガイドライン）の AWS における医療情報システム構築における技術的なポイントについても取り上げていきます。 第 3 弾となる本ブログでは、この医療情報ガイドラインをクラウド上でどのように実践していくかを解説します。 概要編 ではサービス提供事業者の対応方針について全体像を見ました。詳細編では 1 つ 1 つのステップについて細かく見ていきます。 本ブログシリーズの各種リンクはこちら。 医療情報ガイドラインの改定から読み解くクラウド化 医療情報ガイドラインをクラウド上で実践する – ネットワーク編 Part 1 医療情報ガイドラインをクラウド上で実践する -概要編- 医療情報ガイドラインをクラウド上で実践する -詳説編- リスクマネジメントプロセスのおさらい 概要編では対象事業者が行うべきリスクマネジメントプロセスのフェーズとして「リスクアセスメント」「リスク対応」「リスクコミュニケーション」に大きく大別できることを紹介しました。次の章からは各フェーズとその中のステップの中身についてより細かく見ていきます。 医療情報システム向け AWS 利用リファレンス 概要資料と２省ガイドラインの中身をベースに作成 さらに各ステップにおいて参考にできる資料とのマッピングを下図に示します。いくつか参考資料が出てくるため、このマッピングを念頭に置きながら読み進めていただくと整理しやすいでしょう。 各フェーズにおける対応方針 ここからはリスク対応フローの各フェーズにおける対応方針例を取り上げていきます。しかしながら、いきなり全てのステップを 1 から遂行しようとすると全体像が見えなくなることも多いです。どのような観点で対策を進めていくのかの全体像を把握するためにも、各フェーズに進む前に厚生労働省より公開されている「 医療機関におけるサイバーセキュリティ対策チェックリスト 」や「 （事業者確認用）薬局におけるサイバーセキュリティ対策チェックリスト 」に一通り目を通すことをお勧めします。例えばですが、「医療機関におけるサイバーセキュリティ対策チェックリスト」では、「事業者内に、医療情報システム等の提供に係る管理責任者を設置している。」「退職者や使用していないアカウント等、不要なアカウントを削除している。」といった項目が存在しています。 リスクアセスメント・リスク対応フェーズ 参考資料 リスクアセスメント・リスク対応フェーズでは、主に特定したリスクに対してどのように対応するかの方針を決めた上で、対応したリスク一覧を文書化するところまで行います。このフェーズにおいて対応工数を減らすために有用な資料を 2 つご紹介します。 1 つ目が 2 省ガイドラインで公開されている「 別紙2 統合前ガイドラインにおける対策項目一覧と医療情報安全管理ガイドライン6.0版の対応表 」（ EXCEL形式 ）（以下別紙 2）です。別紙 2 について 2 省ガイドライン本編では「従前の情報処理事業者ガイドライン及びクラウド事業者ガイドラインの要求事項を医療情報安全管理ガイドラインとの対応関係を踏まえ対策項目として整理・統合した別紙 2 を用い、その全ての対策項目について対応していることを確認をすることは、対象事業者による対策の設計や妥当性の判断、説明義務への対応において必須である。」と言及されており、従前のガイドラインの要求事項を厚労省ガイドラインとの対応関係を踏まえて整理・統合したとあります。さらに整理・統合された「対策項目により対策可能なリスクシナリオ例」についても言及されています。この表を参照することで、リスクシナリオごとの医療機関側の対応とサービス提供事業者側の対応とのマッピングを容易に実施できます。具体的には上図のように大きく３つのパートから成り立っています。 対策項目：対策項目例に関連する従前の情報処理事業者ガイドライン及びクラウド事業者ガイドラインの要求事項を、「人的・組織的」・「物理的」・「技術的」の３つの対策の観点毎に整理・統合した内容。主な実施主体として、対象事業者を想定する。 対策項目により対策可能なリスクシナリオ例：対策項目により対策可能となる、代表的なリスクシナリオを例示 関連する医療情報安全管理ガイドラインの要求事項：関連する厚労省ガイドラインの要求事項。主な実施主体として、医療機関等を想定する。 別紙 2 の概要  別紙2 統合前ガイドラインにおける対策項目一覧と医療情報安全管理ガイドライン6.0版の対応表 より抜粋     2 つ目が AWS パートナー各社様により作成されている「 医療情報システム向け AWS 利用リファレンス （以下 AWS 利用リファレンス）」です。特にその中でも今回は総務省・経済産業省版が参考になります。別紙 2 では AWS に特化した内容についての言及はされていないため、AWS 利用リファレンスを参考にすることで AWS の利用を加味した対応方針の策定に役立ちます。AWS 利用リファレンスは複数のシートから構成されています。 リスクアセスメント 1.1 リスクアセスメントシート: リスクアセスメントに使用するワークシート 1.2 リスク対応リファレンス: 特定したリスクに対する対策例 1.3 リスクシナリオ例: ガイドライン別紙2記載の最低限確認すべきシナリオ例 制度上の要求事項: ガイドライン6章「制度上の要求事項」の要求事項への対策例 AWS サービス関連情報: スク対策に活用できるAWSサービスを列挙・概要を解説 特に「リスク対応リファレンス」シートを利用することで、各リスクシナリオごとの対応策の具体的な方針のヒントが得られます。例えばですが「正当な利用者以外により、医療情報システム等上の情報が閲覧・操作される。」といったリスクシナリオに対して対策の概要として「アクセス記録の見直し・検査などによる不正アクセス有無の確認」が挙げられています。これに関連するサービスとして AWS CloudTrail や Amazon GuardDuty に触れている他、「情報システム・サービスの提供事業者の対応事項」や「医療機関等へ対応を求める事項」とに分かれて AWS に閉じない形での解説もあります。 医療情報システム向け AWS 利用リファレンス 1.2. リスク対応リファレンス より抜粋   参考資料を用いたリスクアセスメント・リスク対応 上記２つの資料を活用したリスクアセスメント・リスク対応フェーズの進め方の例として、AWS 利用リファレンスの 1.1 リスクアセスメントシートを軸に作成いただく方法が考えられます。 まずは、D、E 列の「特定したリスク」のところに別紙 2 で挙げられているリスクシナリオをベースにリスクの洗い出しを行います。ただし別紙 2 で言及されているリスクシナリオは 2 省ガイドライン本文で「ただし、当該リスクシナリオ例はあくまで参考例であり、関連するリスクと対策が他にも存在しないかを対策の設計を行う際に確認すること」と記載されているため、提供しているサービスの形態に応じて適宜加筆修正の必要があることには注意が必要です。そして洗い出されたリスクに対してリスク分析を実施します。リスク分析では影響度・顕在化率をベースにリスクレベルを算出します。リスクレベルについては、 2 省ガイドライン p.27 にある分類例の表などを参考にしながら算出します。算出したリスクレベルに応じて対応要否を判断します。 医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン1.1版 より 表 5-2 を抜粋 例えばですが、下記のような形での記載例が考えられます。 これらの特定したリスクに対して、リスク分析が完了したら、対応が必要なリスクに対しては別紙２の「対策項目」や AWS 利用リファレンスの「1.1 リスク対応リファレンス」を参考にします。この時、ブログシリーズの第２弾「 医療情報ガイドラインをクラウド上で実践する – ネットワーク編 Part 1 」でも言及されている 責任共有モデル を参考に各関係者ごとの責任分界を意識して、事業者・医療機関・AWS の実施する対策内容をそれぞれ項目を分けて記載していきます。各ステークホルダーごとに何をすべきなのかを明記することで、特に「1.1 リスク対応リファレンス」では「AWS が実施している対策」「情報システム・サービス提供事業者の対応事項」「医療機関等へ対応を求める事項」についての記載があるため、これらの項目を参考にしながらアセスメントシートの項目を埋めていきます。下図は参考資料がリスクアセスメントシートでどのように対応づけができるかを簡易的に示した図となります。 上記対応を進めることで、リスク対応を一覧化した文書を作ることができます。対応ができていないところについては対応を進めていきます。 リスクコミュニケーションフェーズ リスクコミュニケーションフェーズでは、リスクアセスメント・リスク対応フェーズで行ったことをベースに、医療機関等に対する説明義務を果たします。この際、医療機関側の関係者には必ずしもシステムの専門家ではない方々も含まれることの考慮が必要です。システムの運用業者と開発業者が異なる場合は、それぞれの立場の関係者全員を巻き込み、利用者の目線も取り入れながら説明を行うことが重要です。特に、意思決定者の関与は欠かせません。関係者全員が会議を通じて意識共有をすることを目指しましょう。また、リスク状況が変化することも伝え、継続的なリスクコミュニケーションが求められます。 提出すべき書類の作成・提供や説明する会議体などに決まりは存在しませんが、いくつか参考になる文書例があります。2 省ガイドラインでは情報提供を行う文書例として「 別紙1 ガイドラインに基づくサービス仕様適合開示書及びサービス・レベル合意書（SLA）参考例 」（ WORD形式 ）を示しています。また、一般社団法人日本画像医療システム工業会 （JIRA）および一般社団法人保健医療福祉情報システム工業会（JAHIS）による「 製造業者/サービス事業者による医療情報セキュリティ開示書チェックリスト 」 （以下、MDS/SDS）があり、「当該チェックリストが対象とする医療情報システム等を提供する対象事業者においては、当該チェックリストを参考とすることが有効である。 」としています。このチェックリストでは、チェックリスト本体だけでなく各項目に関する補足事項を記載する備考記載欄があり、解説が充実しています。 作成した資料を使って説明する際は、説明を行った証跡を残すことも意識します。万が一のインシデントの際の「言った、言わない」問題についても対処できます。 まとめ 本ブログでは、医療情報ガイドラインの概要とリスクベースのアプローチの背景を確認しました。その上で、サービス提供事業者としてガイドライン対応を進める際の方針やリスクアセスメントからリスクコミュニケーションまでの一連のフローを解説しました。ガイドライン対応においては、リスクの特定から対応策の検討、最終的な合意形成まで一貫したプロセスで臨むことが重要です。本ブログが、読者の皆様のガイドライン対応の一助となれば幸いです。 尾原 颯 (Ohara, Soh) は AWS Japan にて主にヘルスケア系スタートアップに対して技術支援をしています。好きなサービスは Amazon SageMaker と Amazon HealthLake です。 片山 洋平 (Yohei, Katayama) は AWS Japan のパブリックセクターのソリューションアーキテクトです。主に医療機関をはじめとしたヘルスケア業界のお客様のソリューション構築の支援を行なっています。週末は登山を嗜んでいます。