OTT の世界における QoS とその重要性について 今日のデジタル時代において、高速インターネットの普及とストリーミング・デバイスの多様化により、OTT（Over-the-Top）コンテンツは日常生活に欠かせないものとなっています。しかし、OTT コンテンツのサービス品質（QoS）を確保するための選択肢が豊富なため、コンテンツ・プロバイダーと消費者の双方にとって重要な課題となっています。国際電気通信連合（ITU）は、ネットワーク管理と保証に重点を置く QoS と、主観的なユーザー満足度を評価する QoE（Quality of Experience）を区別しています。優れた品質体験を実現するには、ネットワーク・パフォーマンスだけでなく、より広範な要素を考慮する必要があります。QoS と QoE を効果的に管理するために、事業者は、QoE についてはリバッファリングやビデオ再生の失敗、QoS については HTTP エラーコード、待ち時間、キャッシュヒットレートなど、業界レベルの主要なメトリクスを監視する必要があります。この継続的な取り組みは、 Amazon CloudFront を中心に、OTT 配信の可観測性を改善し、QoS の側面を強化することを目的としています。 以前の投稿では、 CMCD のソリューションによる QoE の可視性の向上 について説明しました。お客様への可観測性を向上させる取り組みを継続し、この投稿では CloudFront を使用した OTT 配信の QoS 側面について深く掘り下げます。 この投稿について この投稿では、大規模イベントや 24 時間 365 日のリニアストリームにおけるアセット配信の可観測性を向上させるリアルタイムダッシュボードの導入について説明します。CloudFront のリアルタイム・ロギング機能を使用して、このソリューションは配信パフォーマンス指標をほぼリアルタイムで可視化します。これを利用して、動画配信コンポーネントのさまざまな側面への可観測性を拡大することができます。 CloudFront 動画アセット配信ダッシュボードは、ストリーミング解像度と動画アセットに関連するメトリクスを取得します。このダッシュボードは、最も一般的に使用される動画解像度を考慮に入れています。各解像度のデータを分析することで、ダッシュボードは、パフォーマンスの傾向を特定し、視聴者のアセット配信の全体的な品質を向上させることができるデータ駆動型の意思決定を行うのに役立ちます。この情報により、お客様はストリーミング・インフラを最適化し、視聴者に最高の視聴体験を提供することができます。 また、これらのメトリクスをさらにマニフェストとセグメントに分割し、ワークフローに組み込まれたロジックが 2 つの一般的なビデオ・フォーマットである HLS と MPEG-DASH を考慮しています。 アーキテクチャー この画像に示すように、CloudFront 動画アセット配信ダッシュボードを構築するために必要なメトリクスを配信するために、以下のアーキテクチャーが使用されます： 図 1：ソリューション全体のアーキテクチャー 動画コンテンツをストリーミングしているお客様が動画アセットをユーザーに配信する CloudFront ディストリビューションをすでに持っているとします。このことを念頭に置いて、ダッシュボードを現在のメディア配信フローにプラグインし、メトリクスをダッシュボードに入力し始めることができます。ダッシュボードを構築するアーキテクチャーのコンポーネントを以下に示します： 1- CloudFront リアルタイムログ ： CloudFront が各リクエストの詳細をほぼリアルタイムで提供するために必要です。生成されるデータ量を減らし、コストとパフォーマンスを管理するために、この設定のフィールドは、ダッシュボードに入力するために必要な情報だけを提供するように特別に選択されています。トラブルシューティングやその他のユースケースのためにさらなる情報が必要な場合は、 CloudFront 標準ログ を活用することをお勧めします。さらに、リアルタイムログの設定にフィールドを追加する必要がある場合、 AWS Lambda 関数のコードをカスタマイズして追加のフィールドを処理する必要があります。現在使用されているフィールドは以下の通りです： timestamp sc-bytes sc-status cs-uri-stem time-taken x-edge-result-type asn 各フィールドがログに追加する情報の詳細については、CloudFront のドキュメントを参照してください。 2- Amazon Kinesis Data Streams ： これは CloudFront がログをプッシュする最初のサービスです。CloudFront 上のリアルタイムログの設定は、ダッシュボードの構築に必要なフィールドと Kinesis Data Streams を宛先として設定されています。 3- 変換用 Lambda ： データは Amazon Kinesis からバッチで受信され、この Lambda はリアルタイムログからデータを分解し、ダッシュボードに必要なメトリクスを作成するコードを実行します。 4- CloudWatch Logs/メトリクス ： より費用対効果を高めるために、このフローは CloudWatch Embedded Metric Format (EMF) を使ってメトリクスを公開します。EMF を使用することで、PutMetric API コールの実行を避けることができるため、節約になります。メトリクスが送信されるログ・グループは、最大 30 日間データを保持する必要があります。 5- メディア用 CloudWatch ダッシュボード ： メディア配信を監視するメディア配信管理者と運用チームは、ここでメディアアセット配信のメトリクスを分析およびレビューできます。 前提条件 以下の前提条件が必要となります。 このソリューションを使用するユーザーは、各アセットタイプ（HD/UHD/nonHD）ごとに一意の識別子を URL に統合する必要があります。ほとんどの場合、顧客はビデオ資産の解像度に基づいたファイル構造を作成します。さらに、HTTP URL にも同じ構造を適用します。たとえば、超高解像度（UHD）コンテンツをストリーミングする場合、URL の一部として「 soccer_match_uhd 」のような一意の識別子や「 3840×2160 」のような解像度そのものを使用することができます。このソリューションは URL パーサーに基づいており、Query String 内の識別子はこのソリューションでは機能しないことに注意してください。 このソリューションは、お客様の既存の動画ワークフローとシームレスに統合できるように設計されています。ユーザーは、動画ワークフローの一環として、CloudFront ディストリビューションを利用してアセットを配信する必要があります。 ソリューション・メトリクスの深掘り このセクションでは、利用可能なメトリクスとその意味について説明します。以下の画像は、ダッシュボードの動作イメージです。 図 2：ダッシュボードのメトリクスビュー 用語の理解： UHD: UHD は Ultra-High Definition の略で、標準的な高解像度（HD）よりも大幅に高いビデオ解像度を指す。UHD の解像度は通常 3840×2160 ピクセルです。 FHD/HD：HD は High Definition の略で、標準画質（SD）ビデオの解像度よりも大幅に高いビデオ解像度を指す。HD の解像度は通常 1280×720 ピクセル（720p）。FHD はフルハイビジョンの 1920×1080 ピクセル（1080p）を指し、現在の業界では、HD は両方の解像度を指すために使用されることがあります。そのため、ダッシュボードを簡潔にするために、これらの解像度をひとまとめにしました。 SD: SD は Standard Definition の略で、HD 規格よりも低いビデオ解像度を指します。一般的には 480p 以下の解像度を指します。 Segment/manifest delivery latency by Stream ： 視聴者に配信されるコンテンツの待ち時間データを提供します。このメトリックは、マニフェストおよびセグメントファイル別、ストリーム配信タイプ別に分類されます。こちらは、CloudFront がリクエストを受信してからコンテンツが視聴者に送り返されるまでのレイテンシの合計を示しています。 BytesDownloaded per Stream ： ストリーミングされているコンテンツが各ストリームのタイプ間でどのように分割されているかを管理者が理解するためのものです。そして、視聴者ベースの行動を理解するために使用することができます。また、異なる利用ベース間で全体的な配信品質を向上させるために、より多くの収益を提供するコンテンツ品質や、より多くの注意が必要なコンテンツ品質に関するインプットを提供します。 Latency by Autonomous System Number (ASN) ： この指標は、コンテンツがリクエストされ、CloudFront によって提供されるまでの時間を示しています。トップ 10 の ASN と解像度別に分類されています。このメトリクスは、特定の ASN に問題があるかどうかを特定するのに役立ち、ストリーミング配信内の待ち時間の問題を特定するのに役立ちます。これらの特定のメトリクスは、クエリを通じて提供され、過去 3 時間のデータのみが表示されます。 Cache Hit Ratio metrics ： マニフェストおよびセグメント・ファイルの配信に関するキャッシュ・ヒット率メトリクスです。これらは、監視チームがこれらのタイプのコンテンツのキャッシュについて改善の可能性を発見するのに役立つように設計されています。通常、コンテンツが可能な限りユーザーに近いところから配信されていることを確認するため、より高いキャッシュヒット率でセグメントを確認したいと考えます。これは、各解像度の配信ごとに分類されています。 4xx/5xx Error Rates per Stream ： ストリームタイプ別に分類されたエラーレートを示します。これは、ストリームごとのリクエストのエラー発生率を把握するのに役立ちます。レートが上昇した場合、ストリーム・タイプに基づいてトラブルシューティングを迅速に行うことができます。 デプロイ手順 このダッシュボードをデプロイするために、必要なリソースをすべてデプロイする CloudFormation テンプレートが用意されています。 ステップ1 ： CloudFormation コンソールにアクセスしてテンプレートをデプロイします。 ステップ2 ：このCloudFormation テンプレートは、ダッシュボードに必要なすべてのリソースをデプロイします。テンプレートをデプロイする際、いくつかの入力が必要になります： CloudFrontRealTimeLogsSamplingRate ： CloudFront が提供するリクエストがリアルタイムログパイプラインに送られるサンプルレートを定義します。パイプラインを流れるデータが多いほど、このソリューションのコストが高くなるため、これによりコストを制御できます。 UHDExists, FHDExists, HDExists ： これらのパラメータでは、このメディア配信フローに Ultra HD、Full HD、およびHD ストリーミングがあるかどうかを指定します。これらの解像度がメディア配信フローに含まれていない場合は、falseのままにします。 FHDStreamIdentifier ： これは、ユーザーが要求しているコンテンツの URI 内のFHD 解像度ストリームの一意の識別子です。 HDStreamIdentifier ： 前述の「FHDStreamIdentifier」と同様、HD ストリームの一意な識別子です。 UHDStreamIdentifier ： 前述の「FHDStreamIdentifier」と同様、Ultra HD ストリームの一意な識別子です。 図 3：CloudFormation のパラメーター ステップ 3. CloudFormation テンプレートが実行され、スタックの全コンポーネントがデプロイされたら、次のステップはCloudFront  リアルタイムログ設定をメディアコンテンツを提供する CloudFront ディストリビューションにアタッチすることです。これを行うには、以下のサブステップに従います： ステップ3.A. CloudFront コンソールを開き、 ログ > リアルタイム設定 を選択します。 ステップ3.B. CFMediaDashboardLogs 設定を開き、 “ディストリビューションにアタッチ” を選択します。 ステップ3.C. 次のページで、メディアコンテンツの配信に使用するディストリビューションとキャッシュビヘイビアを選択します。次に  “Attach”  を選択します。次の画像のように、メディアアセット（マニフェストとセグメント）を提供するすべてのビヘイビアを選択してください。 図 4：CloudFront のリアルタイムログ 図 5：ディストリビューションへのリアルタイム・ログのアタッチ 設定されたディストリビューションでライブトラフィックが実行されている場合、ダッシュボードにはメトリクスが入力されています。CloudWatch ダッシュボードを開くと、”CloudFrontVideoAssetDeliveryDashboard”という名前のダッシュボードを開くことができます。 ダッシュボードの使用とコストに関する考察 CloudFront 動画アセット配信ダッシュボードソリューションは、複数のシナリオで使用することができます。さらに、AWS のコストモデルに従い、このソリューションは従量課金です。オペレータは、必要性と使用状況に応じて、ワークフローからこのダッシュボードをいつでも開始/停止することができます。 このソリューションに関係する価格設定は、CloudWatch で処理されたデータ、Kinesis にデータが送信されるレートと各レコードのサイズ、CloudFront リアルタイムログリクエスト（生成されるログ行数に基づいて課金される）、Lambda の呼び出し数とその合計時間となります。これらのディメンションはすべて、CloudFront へのリクエストレートと、ソリューションのデプロイ時に選択したサンプリングレートの影響を受けます。 ログ構成が CloudFront ディストリビューションから切り離されるとすぐに、ログの入力が停止し、コストも停止することに注意してください。以下の画像で、どのように設定を切り離すかを確認できます。 図6：リアルタイム・ログの切り離し ダッシュボードのクリーンアップ インフラをクリーンアップするためには、リソースをデプロイした CloudFormation スタックを削除しなければいけません。 クリーンアップが適切に機能するように、2 つのステップを踏む必要があります。 1- CloudFront リアルタイムログを CloudFront ディストリビューションから切り離す必要があります。そのためには、リアルタイムログ設定を開いてディストリビューションから切り離します。 2- 次のステップは、他のすべてのリソースを作成した CloudFormation スタックを削除することになります。スタックの削除が完了すると、すべてのリソースが AWS アカウントから削除されます。 まとめ この投稿では、CloudFront を通じてストリーミング・コンテンツを配信する企業が、ストリーミング配信をより可視化し、OTT ストリーミングアセットの QoS を評価できるように設計された新しいソリューションを紹介しました。 このソリューションの導入により、お客様は動画配信コンポーネントをエンドツーエンドで把握することができます。CloudWatch を使用して CloudFront 動画アセット配信ダッシュボードを活用することで、企業は動画配信ワークフローのパフォーマンスをリアルタイムで可視化することができます。さらに、CMCD ツールを使用することで、顧客はクライアント側のテレメトリーに関する洞察も得ることができ、企業が動画配信戦略を回顧するための完全なデータセットを提供します。このようなエンドツーエンドのアプローチによる動画配信パフォーマンスのモニタリングと分析により、企業は十分な情報に基づいた意思決定と迅速な是正措置を取ることができ、一貫した QoS で高品質のストリーミングコンテンツを確実に提供することができます。 本記事は、「 QoS Observability for OTT Streaming using Amazon CloudFront 」と題された記事の翻訳となります。 翻訳は Solutions Architect の長谷川 純也が担当しました。

Amazon QuickSight は、共同作業の場所を問わず、わかりやすいインサイトを提供することができるクラウドネイティブのビジネスインテリジェンス (BI) サービスです。ユーザーはスケジュールされた方法、またはプログラムされた方法で、 SPICE (Super-fast, Parallel, In-memory Calculation Engine) にデータをインポートできます。 QuickSight データセットの更新を設定する場合、更新が失敗したときに所有者に電子メールを送信できますが、一時的なエラーが原因で更新が失敗する可能性があるため、ネイティブに再試行する方法はありません。 この投稿では、更新に失敗したデータセットの取り込みを自動的に再試行するために必要なすべてのリソースを AWS CloudFormation を使いデプロイする方法を示します。これにより、更新が正常に完了したかどうか、障害原因に関する詳細情報がデータセット所有者に提供されるため、ユーザーがデータを利用できるようになるまでの時間を短縮できます。 さらに、QuickSight のアセットは、 Amazon CloudWatch メトリクスを使用して モニタリング できます。 QuickSight の開発者と管理者は、これらのメトリクスを使用して、QuickSight エコシステムの可用性とパフォーマンスをほぼリアルタイムで観察し、対応することができます。 ソリューションの概要 CloudWatch メトリクスを使用して、QuickSight からほぼリアルタイムのイベントをキャプチャし、失敗したデータセット更新の新しい取り込みを開始する AWS Step Functions ステートマシンを対象とする CloudWatch メトリックアラームと、 Amazon EventBridge ルールを設定します。 次の図は、この投稿のアーキテクチャを示しています。Step Functions ステートマシンと関連する AWS Lambda 関数は、CloudFormation テンプレートを通じてデプロイされます。 次のセクションでは、モニタリングしたいデータセット ID を特定し、CloudFormation テンプレートをデプロイ、作成されたリソースを確認、ソリューションをテストし、不要な課金を回避するためにクリーンアップする方法を示します。 前提条件 このチュートリアルを実施するには、以下が必要です: AWS アカウント QuickSight Enterprise Edition のサブスクリプション CloudWatch メトリック、CloudWatch アラーム、EventBridge、QuickSight、Step Functions、Lambda へのアクセス権限を持つ AWS Identity and Access Management (IAM) ロール 使用するサービスと Python の基本的な知識 モニタリングしたいデータセットIDの特定 データセット ID を特定するには、次の手順を実行してください: QuickSight コンソールのナビゲーションペインで、 Datasets を選択します。 モニタリングしたいデータセットを選択します。 ブラウザの URL から、 data-sets/ と /view の間の部分をコピーします。次のような URL になります: https://us-west-2.quicksight.aws.amazon.com/sn/data-sets/4712aba2-6ecc-4521-b009-deb5b276a5f6/view テストに使用できるデータセットがない場合は、次の手順で Amazon Athena テーブルを作成し、データセットを作成できます。 このテーブルを使用して、SPICE にインポートする QuickSight データセットを作成します。更新の失敗をシミュレートするために、テーブルを削除してデータセットの更新を失敗させます。この失敗により、作成したステートマシンがトリガーされ、更新を自動的に再試行します。 Athena コンソールで、 テーブルを作成 します。この投稿では、Athena の CTAS を使用して、 foo_bar というシンプルなテーブルを作成します。 QuickSight コンソールで、ナビゲーションペインの Datasets を選択します。 New dataset を選択します。 Create dataset より、 Athena を選択します。 Data source name に名前を入力し、テーブルの作成に使用した Athena ワークグループを選択します。 Create data source を選択します。 Choose your table セクションで、カタログ、データベース、テーブルを指定します。 Edit/Preview を選択します。 Query mode で、 SPICE を選択します。 Save & Publish を選択し、 Cancel を選択してデータセットビューに戻ります。 このビューから名前を選択してデータセットを開きます。 Refresh タブで、データセットが作成されたときの更新ステータスを確認できます。ここでは Completed と表示されています。 ブラウザの URL から、先ほど説明したようにデータセット ID を取得します。 リソースのデプロイ この手順では、障害発生後の自動取り込みを管理するために、Step Functions ステートマシンと Lambda 関数を作成します。次の手順を実行してください: AWS CloudFormation コンソールを開きます。 コンソール上でテンプレートを開くために、 Launch Stack を選択します。 Next を選択します。 Parameters にある DataSetID へ前の手順で取得した QuickSight データセット ID を入力します。 Next を選択します。 次のページで、 Next を選択します。 最終ページで詳細を確認し、 I acknowledge that AWS CloudFormation might create IAM resources. を選択します。 Submit を選択します。 スタックの作成が完了するまでには約 2 分かかります。 リソースの確認 リソースを確認するには、次の手順を実行してください: AWS CloudFormation コンソールで、ナビゲーションペインの Stacks を選択します。 作成したスタックを選択します。スタック名を変更していない場合、 automate-failed-ingestion-blog という名前になります。 Resources タブを選択します。ここで、CloudFormation スタックによって作成されたすべてのリソースが表示されます。 Type が AWS::CloudWatch::Alarm の Physical ID を選択して、リソースを新しいタブで開きます。 CloudWatch アラームの詳細を確認します。 View EventBridge rule を展開すると、EventBridge ルールの基礎となるパターンが表示されます。 ブラウザで、CloudFormation コンソールが開いているタブに戻ります。 Type が AWS::Events::Rule の Physical ID を選択して、リソースを新しいタブで開きます。 Event pattern タブに、EventBridge ルールで説明されていたイベントと同様のイベントが記載されています。唯一の違いは、state に ALARM を追加したことで、ステータスが OK に変更されたときもターゲットがトリガーされないことです。 ブラウザで、CloudFormation コンソールが開いているタブに戻ります。 Type が AWS::StepFunctions::StateMachine の Physical ID を選択して、リソースを新しいタブで開きます。 Edit を選択して、Step Functions のステートマシン定義を開きます。 Lambda 関数を選択し、 View function を選択すると Lambda 関数を開くことができます。 Step Functions のステートマシンロジック ステートマシンが実行されると、Check Previous Ingestions ステートの最初の Lambda 関数が実行され、前回の取り込みのステータスがチェックされます。 最新のステータスが完了している場合、ステートマシンは COMPLETED のステータスを送信し、Success 状態を経由して終了します。 Lambda 関数による更新失敗が特定の回数 (デフォルトでは 6 回) を超えた場合、 TOO_MANY_FAILURES のステータスを送信し、Fail 状態を経由して終了します。リトライ回数は Lambda 関数で設定できます。 ステータスが COMPLETED でも TOO_MANY_FAILURES でもない場合、ステートマシンは Default の状態を経由して、Start New Ingestion 状態の次の Lambda 関数を実行します。その後、フローは 60 秒間待機した後、Get Ingestion Status 状態の Lambda 関数を実行して取り込みのステータスを確認します。この Lambda 関数がステータス COMPLETED を返した場合、ステートマシンは Success 状態を経由して終了します。ステータスが FAILED の場合は Fail 状態を経由して終了します。それ以外のステータスの場合は、再び 60 秒間待機した後、再確認します。 開始される更新の種類は、最後の更新と同じになります。データセットの編集中にエラーが発生する可能性があり、更新タイプ EDIT でエラーが発生します。自動更新プロセスが失敗していないため、この時点ではコードは取り込みを再試行しません。 ソリューションのテスト AWS CloudFormation コンソールで、ナビゲーションペインの Stacks を選択します。 作成したスタックを選択します。スタック名を変更していない場合、 automate-failed-ingestion-blog という名前になります。 Resources タブを選択します。ここで、CloudFormation スタックによって作成されたすべてのリソースが表示されます。 Logical ID が DataSourceIngestionFailed の Physical ID で指定されているリンクを選択します。 これにより、モニタリングしているデータセットに関連する CloudWatch アラームが開きます。 データセットのソースを更新できないようにするか、テストのために作成したデータセットを使用している場合は、作成したテーブルを削除してください。 QuickSight データセットから、 REFRESH NOW を選択し、 Full refresh を選択して、 CONTINUE を選択します。 データセットの更新は Failed と表示されます。 1 分待って、CloudWatch アラームのステータスをもう一度確認してください。 アラーム状態は In alarm になります。 CloudFormation スタックの Resources タブで、 Logical ID が QuickSightRestartIngestionStateMachine の Physical ID に指定されているリンクを選択します。 これにより、リトライロジックを実行する Step Functions ステートマシンが開きます。 Name の下にある ID を選択して、ステートマシンの最新の実行を表示してください。 この実行では、取り込みが再試行されましたが、失敗したため、ステータスが Fail に設定されています。 メールアラートを有効にするには、QuickSight コンソールに移動し、ナビゲーションペインの Datasets を選択します。 機能を有効にするデータセットを選択します。 Refresh タブで、 Email owners when a refresh fails を選択します。 このオプションをデータセットで選択した場合、所有者はEメールを通じてすべての失敗の通知を受け取ります。 クリーンアップ 今後の請求を避けるために、作成したリソースを削除してください: AWS CloudFormation コンソールで、ナビゲーションペインの Stacks を選択します。 作成したスタックを選択します。スタック名を変更していない場合、 automate-failed-ingestion-blog という名前になります。 Delete を選択します。 これにより、スタックによって作成されたすべてのリソースが削除されます。 まとめ このチュートリアルでは、QuickSight データソースの失敗した更新を自動的に再試行するために必要なすべてのリソースを作成しました。 これらのリソースが相互にどのように関連しているか、そしてこのソリューションがデータを自動的に更新することで QuickSight のユーザーエクスペリエンスを改善し、データセットの更新が失敗したときには、QuickSight オペレーターの手動作業を自動化することで、オペレーターエクスペリエンスを改善する方法を示しました。 詳細は、 Amazon QuickSight をご覧ください。 QuickSight コミュニティ に参加して、他のユーザーと質問したり、答えたり、学んだりすることができます。 翻訳はソリューションアーキテクトの松浦が担当しました。原文は こちら です。 著者について Andres Castro  は、グローバルファイナンシャルサービスのグローバルソリューションアーキテクトです。過去25年間、コンサルティングや金融セクターで DevOps エンジニア、ファイナンスデータソリューションアーキテクト、クラウドエンジニアとして働いていました。ビジネスインテリジェンス、データガバナンス、データアナリティクス、その他すべてのクラウドに情熱を注いでいます。

本日は、AWS Cloud Development Kit (CDK) の新機能である CDK Migrate についてご紹介します。この機能を使用することで、ユーザーは以前にデプロイされた AWS CloudFormation テンプレートや CloudFormation スタック、 Infrastrcture as Code (IaC) の管理外で作成されたリソースを CDK アプリケーションに移行できます。この機能は、CloudFormation の管理外で作成されたリソースをテンプレートにインポートし、新しく生成された CloudFormation スタックに取り込むのに役立つ CloudFormation IaC ジェネレーター と同時に公開されています。IaC ジェネレーターの詳細は、 AWS CloudFormation にアプリケーション全体をインポート をご覧ください。 AWS でリソースを作成および管理する方法には、「クリック操作」(マネジメントコンソールでの作成および更新)、AWS API、Infractrcture as Code (IaC) を使用するなどの、さまざまな方法があります。IaC を使用してリソースのライフサイクルを管理することは推奨されるプラクティスですが、導入するためのプロセスが必要かもしれません。IaC の利用に慣れていない担当者は、コンソールを使用してリソースを作成し、更新する可能性が高いでしょう。これは小規模なユースケースや新しいサービスのテストには許容できるかもしれませんが、環境の複雑さが増すにつれて、維持管理はより困難になります。同じ構成を他のアカウント、環境、リージョンに再デプロイする必要がある場合、状況はさらに悪化します。構成を複製しようとすると人的ミスが非常に起こりやすくなります。IaC は、ユーザーが一度定義すればどこでも同じ構成をデプロイできるようにし、この問題を解決します。IaC への移行を遅らせてきた人にとって、IaC ジェネレーターと CDK Migrate を使用して IaC の世界へ飛び込む時が来ました。これらの機能によって移行を加速および簡素化できます。 はじめに AWS CDK へのリソースの移行の最初のステップは、ユーザーが IaC を利用するのに最適なメカニズムを理解することです。 IaC を宣言的に定義したい (YAML のような設定言語を介してリソースを管理したい) ユーザーの場合、CloudFormation テンプレートを生成したり、CloudFormation スタック内の既存リソースを管理したりできる IaCジェネレーター を検討することをおすすめします。 高級プログラミング言語を介して IaC を管理したり、それらのテンプレートの上に高度な抽象化と自動化を構築したいユーザーの場合、AWS Cloud Development Kit と CDK Migrate が優れたオプションとなります。 CDK CLI には、既存の CDK アプリケーションにリソースをインポートする機能もあります。CDK migrate を使用する場合と CDK import を使用する場合の使用例を確認しましょう。 CDK Migrate ユーザーは、1 つまたは複数のリソースを 新規の CDK アプリケーションに移行したいと考えています。 移行対象の AWS リージョン内の既存リソースの例: IaC 管理外で作成されたリソース デプロイ済みの CloudFormation スタック ユーザーは CloudFormation テンプレートから 新規の CDK アプリケーションに移行したいと考えています。 ユーザーは、既存のリソースおよび CloudFormation テンプレートから CDK コードを生成するための一貫した体験を求めています。 CDK Migrate 機能は AWS CDK の利用を加速させることを目的として設計されていますが、制限事項があることを理解することが重要です。 制限事項の詳細については、 ドキュメント をご確認ください。 CDK Import ユーザーは、CDK の外で作成された 1 つ以上のリソースをインポートしたい 既存の CDK アプリケーションを持っています。 AWS リージョン内の移行対象となる既存リソースの例: IaC 管理外で (クリック操作によって) 作成されたリソース デプロイ済みの CloudFormation スタック ユーザーは独自に CDK アプリ内でリソースを定義する必要があり、CDK コードで定義されたリソースがアカウント内の実際のリソースに直接マッピングされることを確認します。この機能を使用するには複数のステップのプロセスに従う必要があります。詳細は こちら を参照してください。 このブログでは、ローカルの CloudFormation テンプレートを取り込み、新しい CDK アプリケーションに変換する方法の例を紹介します。 利用手順 はじめに、CDK アプリケーションに変換される以下の CloudFormation テンプレートを利用します。このテンプレートは、AWS Lambda 関数、AWS Identity and Access Management (IAM) ロール、Amazon S3 バケットを、動的に値を指定するためのパラメータを使用して作成します。 以下がテンプレート全文です: AWSTemplateFormatVersion: "2010-09-09" Description: AWS CDK Migrate Demo Template Parameters: FunctionResponse: Description: Response message from the Lambda function Type: String Default: Hello World BucketTag: Description: The tag value of the S3 bucket Type: String Default: ChangeMe Resources: LambdaExecutionRole: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Version: "2012-10-17" Statement: - Effect: Allow Principal: Service: lambda.amazonaws.com Action: sts:AssumeRole ManagedPolicyArns: - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole HelloWorldFunction: Type: AWS::Lambda::Function Properties: Role: !GetAtt LambdaExecutionRole.Arn Code: ZipFile: | import os def lambda_handler(event, context): function_response = os.getenv('FUNCTION_RESPONSE') return { "statusCode": 200, "body": function_response } Handler: index.lambda_handler Runtime: python3.11 Environment: Variables: FUNCTION_RESPONSE: !Ref FunctionResponse S3Bucket: Type: AWS::S3::Bucket Properties: PublicAccessBlockConfiguration: BlockPublicAcls: true BlockPublicPolicy: true IgnorePublicAcls: true RestrictPublicBuckets: true BucketEncryption: ServerSideEncryptionConfiguration: - ServerSideEncryptionByDefault: SSEAlgorithm: AES256 Tags: - Key: Application Value: Git-Sync-Demo - Key: DynamicTag Value: !Ref BucketTag Outputs: S3BucketName: Description: The name of the S3 bucket Value: !Ref S3Bucket Export: Name: !Sub ${AWS::StackName}-S3BucketName これは、migrate コマンドを実行するときに使用するテンプレートです。 このデモは CloudFormation テンプレートを CDK アプリケーションに移行するものですが、以前にデプロイ済みのスタックや IaC で作成されていないリソースも移行できます。 Migrate CloudFormation テンプレートから CDK への移行は、単一のコマンド cdk migrate で実行できます。 ローカルの CloudFormation テンプレートファイル (ここでは demo-template.yaml とします) を指定するだけで、CLI がテンプレートを CDK アプリケーションに変換します。 このコマンドの出力と結果は、CDK コードと依存関係で構成されるディレクトリになりますが、スタックはデプロイされません。 cdk migrate --stack-name CDK-Local-Template-Migrate-Demo --language typescript --from-path ./demo-template.yaml 上記のコマンドでは、CDK CLI に --from-path パラメータを使用して CloudFormation テンプレートファイルを取り込み、CDK アプリケーションで利用する言語を選択するよう指示しています。CDK CLI はテンプレートを変換するとともに、CDK アプリケーションに必要な依存関係を備えたプロジェクトフォルダを作成します。 移行が完了すると、CDK アプリケーションはプロジェクト構造やファイルとともに使用準備が整いますが、まだデプロイされていません。以下は生成されたファイル構造です: 上記の出力は、デプロイの準備ができた CDK Typescript アプリケーションのディレクトリ構造を表しています。CDK コードは bin と lib の 2 つのディレクトリに格納されています。bin ディレクトリ内には、CDK アプリケーションを作成し、CDK Stack クラスを呼び出すコードがあります。ファイル名は、migrate コマンドの実行時に –stack-name パラメータに渡された入力と一致するので、この場合のファイル名は bin/cdk-local-template-migrate-demo.ts です。以下は生成されたコードです: CdkLocalTemplateMigrateDemoStack がインポートされ、インスタンス化されます。これは、既存の CloudFormation テンプレート (またはスタックやリソース) から変換されたコードが存在する場所です。 上記のファイル名の付け方と同様に、CDK スタックコードのファイル名と場所は lib/cdk-local-template-migrate-demo-stack.ts です。 変換されたコードを見てみましょう。 上記の自動生成されたコードをオリジナルの CloudFormation テンプレートと比較すると、リソースの定義が似ていることがわかります。これは、migrate コマンドが CloudFormation で利用可能なすべてのリソースを表現できる、L1 コンストラクトを使用して CDK コードを生成しているためです。 CDK コンストラクトとコンストラクトが提供するさまざまなレベルの抽象化について詳しくは、この ビデオ をチェックしてください。 CloudFormation のパラメータは、インターフェイス内に定義されたプロパティに変換され、Stack クラスに渡されます。Stack クラスのコード内では、元の CloudFormation パラメータで設定されたデフォルト値に基づいて、プロパティのデフォルト値が設定されます。それらのデフォルト値を指定した値で上書きしたい場合は、次のようにプロパティを CDK スタックに渡すことができます: 新しく作成した CDK アプリケーションで、AWS アカウントにデプロイする準備が整いました。 デプロイ このアカウントとリージョンで CDK を初めて使用する場合は、cdk bootstrap コマンドを実行してください。このコマンドは、CDK がリージョンとアカウントにリソースを適切にデプロイするために必要なアセットを作成します。 詳細は こちら をご覧ください。ブートストラッププロセスが完了すると、デプロイに進むことができます。 作成された CDK アプリケーションはデプロイの準備ができていますが、デプロイする前に cdk diff を実行してデプロイされる内容を確認することをおすすめします。diff コマンドを実行すると、 変更セット が作成され、提案されている変更 (この場合は新規のスタックとリソース) が表示されます。(訳註: 環境によって以下の GIF 画像が表示されない場合があります。 cdk diff の実行の様子が示されています。) 出力から、すべての新しいリソースが作成されようとしていることがわかります。cdk diff コマンドが、既存のリソースやスタックに対して実行された場合 (上記のプロパティの更新のように変更がないと仮定します)、diff は既存のリソースへの変更を示しません。 次に、 cdk deploy コマンドの実行によりスタックをデプロイします 。デプロイが完了したら、AWS コンソールに移動し、Lambda 関数を確認してください。Lambda 関数のテストを実行すると、レスポンスは “CDK Migrate Demo Blog” という functionResponse プロパティの更新内容と一致するはずです。(訳註: body が null となる場合、 lib/cdk-local-template-migrate-demo-stack.ts で CfnFunction の environment で functionResponse を FUNCTION_RESPONSE に変更してください。本事象に関連する issue #28997 #29027 が報告されています。) まとめ この投稿では、CDK migrate コマンドが、CloudFormation テンプレートからであれ、以前にデプロイされた CloudFormation スタックからであれ、CloudFormation IaC ジェネレータ機能を介してリソースをインポートする方法からであれ、リソースを CDK に移行してインフラストラクチャをコードとして管理できるようにするのにどのように役立つかについて説明しました。この機能をテストしてフィードバックや機能リクエストを GitHub の リポジトリ にぜひ投稿してください。さらに、CDK のご利用が初めての方のために、スタートアップの際に役立つリソースがいくつかあります。 AWS CDK Immersion Day ワークショップ CDK Live! (ライブストリームとチュートリアルの YouTube チャンネル) CDK ベストプラクティスガイド 本記事は、 Announcing CDK Migrate: A single command to migrate to the AWS CDK を翻訳したものです。翻訳はソリューションアーキテクトの山崎宏紀が担当しました。

炭素会計とは、組織の事業活動に関連する温室効果ガス (GHG) 排出量を、各種の排出源からのカーボンフットプリントを特定して、定量化、そして報告する方法を指します。 これらの排出源には、現場での活動からの直接排出 (スコープ 1)、購入したエネルギーからの間接排出 (スコープ 2)、サプライヤや顧客を含むバリューチェーンからの排出 (スコープ 3) が含まれます。 規制当局、投資家、消費者からの懸念が高まる中、組織は自社のカーボンフットプリントを報告および削減するプレッシャーにさらされています。チーフサステナビリティオフィサー (CSO) とそのチームは、正確なカーボンフットプリントの測定、会社全体での報告、サステナビリティ目標を達成するための脱炭素化について計画するために必要なデータを収集および分析する際に課題に直面することがよくあります。 データの収集、分析、報告に費される負担は、カーボンフットプリントの測定の正確性の低下や、脱炭素化のための実行可能な洞察の欠如につながる可能性があります。サステナビリティとテクノロジー両面で実績のある専門知識を備えた TensorIoT は、このような状況に変化をもたらします。 AWS スペシャライゼーションパートナー であり、北米地域の 2022 年 AWS サステナビリティパートナー・オブ・ザ・イヤー である TensorIoT は、サステナビリティソリューションをデジタル領域に統合する最前線にあります。同社の専門家チームは、炭素会計と脱炭素化に焦点を当てながら、ビジネスがサステナビリティの課題に取り組むのに役立つ最先端のツールを開発および実装することに特化しています。 TensorIoT は、 Guidance for Carbon Accounting on AWS を活用することで、組織が自動化されたカーボンフットプリント測定システムの構築を加速できるようにします。そうすることで報告までの時間を短縮し、データの正確性を向上させ、そしてサステナビリティを推進する組織にとって重要かつ実行可能な洞察を提供します。 Carbon Accounting Solutions on AWS の活用方法 Guidance for Carbon Accounting on AWS は、適切に設計されたカーボンプリントを測定するアプリケーションを構築するための技術的アクセラレータのセットを提供する、 Guidance for Sustainability Insights Framework on AWS をベースに構築されています。 このガイダンスは、次の利点を提供します: 適応性: 複数のソースからの排出係数を管理し、進化する方法や基準へ対応する排出量の計算を確立または適応する柔軟性を提供します。 透明性と監査能力: すべてのデータソースをバージョン管理し、計算の入出力を記録することで、トレーサビリティと再現性をサポートします。 データセキュリティと整合性: 最小限の権限、データ暗号化、セキュアな鍵管理など、セキュリティのベストプラクティスに準拠しています。 効率性と正確性: データ収集と計算を自動化することで、手動データ処理の負担を軽減し、人為的なエラーのリスクを低減します。 スコープ 2 排出量のカーボンフットプリントを測定するアプリケーション TensorIoT は、Guidance for Carbon Accounting on AWS を活用して、電力消費によるスコープ 2 排出に焦点を当てたカーボンフットプリント測定アプリケーションを作成しました。サステナビリティ管理者や施設の管理者向けに設計されたこのアプリケーションにより、ユーザーは米国の施設ポートフォリオ全体での電力消費によるスコープ 2 排出を追跡および比較できます。 ユーザーは施設の郵便番号と電力消費量 (kWh 単位) または施設の床面積を入力し、アプリケーションはその地域の電力グリッドミックスに基づいて、施設ごとのスコープ 2 排出量を計算します。 この例の概要では、排出係数と建物の消費データは、米国環境保護庁 (EPA) の排出量・発電資源統合データベース (eGRID) と米国エネルギー情報局 (EIA) の商業ビルエネルギー消費調査から取得しています。 次のセクションでは、TensorIoT の専門家がどのようにお客様独自の炭素会計ソリューションを AWS 上に構築することを支援できるかを示すために、ソリューションのデプロイとセットアッププロセスの技術的なウォークスルーを紹介します。 技術的なウォークスルー 以下の手順を使用すると、施設の電力消費からスコープ 2 のカーボンフットプリントを計算するのに役立つ、AWS の Guidance for Carbon Accounting on AWS を活用した React ベースのアプリケーションをデプロイできます。 ソリューションは、 AWS Cloud Development Kit (AWS CDK)を使用して、シングルテナントかつシングル環境へのデプロイメントによって展開されます。 ソリューションのビルドとデプロイには複数のビルドステップとツールの要件に対応するため、ソリューションは AWS CodeBuild プロジェクトを作成します。 デプロイメントの手順に従うことで、ソリューションを手動でデプロイすることもできます。 前提条件 AWS アカウント AWS CDK の知識 AWS サービスと AWS 上のサステナビリティインサイトフレームワークのガイダンスの理解 CDK bootstrap と CDK deploy を実行するための管理者権限 環境のセットアップ Node をインストールします。 AWS Command Line Interface (CLI) をインストールします。 AWS CDK をインストールします。 正しいアカウント情報で AWS プロファイル を設定します。 リポジトリ をクローンします。 リポジトリのルートフォルダで ターミナル を開きます。 config.ts.template を元に config.ts というファイル名で設定ファイルを作成し、環境を設定します: Account – AWS のアカウント番号 Region – AWS のデプロイリージョン TenantID – Sustainability Insights Framework のテナント ID として使用する文字列 adminEmail – 管理者ユーザーのメールアドレスとパスワードの送信先 environmentName – デプロイ環境の名前 npm install を実行します。 npm run build を実行します。 frontend フォルダに移動します。 npm install を実行します。 npm run build を実行します リポジトリのルートフォルダに移動します。 cdk bootstrap aws://アカウント番号/リージョン を実行します。 “SifBuildDeploy” という名前の CodeBuild プロジェクトを作成する  cdk deploy SifCodebuildStack [--profile="PROFILE_NAME"] を実行してください。これはソリューションフレームワークのビルドとデプロイのために一度だけ実行する必要があります。 ビルドプロジェクトを実行するために aws codebuild start-build --project-name SifBuildDeploy  を実行します。 管理パスワードがメールで届きます。アプリケーションへのアクセスとソリューションのデプロイの設定の際に必要になります。 ソリューションフレームワークがデプロイされたら、初期設定を行うスクリプトを実行してください。 cdk deploy CarbonAccountingPortalStackPipeline [--profile="PROFILE_NAME"] を実行してください。 ステップ 19 で実行されるスクリプトは、ソリューションフレームワーク内に参照テーブル、計算ロジック、パイプラインを設定するために使用されます。検索テーブル、計算、React アプリから実行されるパイプラインを作成します。 方法論 このウォークスルーでは、特定の地理的境界と期間の平均的な排出データによって決定される、ロケーションベースのスコープ 2 排出量を計算するために、 GHG プロトコルのスコープ 2 ガイダンス を使用します。正確な活動データは、MWh または kWh 単位で測定された電力消費量の計測値、または料金請求書から得られます。そのようなデータがない場合は、特定の施設タイプの平均データに基づいて電力消費を推定できます。正しい排出係数を割り当てるには、施設の郵便番号を収集する必要があります。 このユースケースをサポートするために、参照データセットと排出係数を特定します。 EIA 商業ビルエネルギー消費調査 2018 から特定された参照データセットは、平方フィートあたりの年間推定電力消費量 (キロワット時 / 平方フィート・年) を提供します。 この参照データセット (図 1 を参照) は「BuildingToConsumption」として保存されており、セットアップスクリプトから次の呼び出しを使用してインポートされました。 { "name": "BuildingToConsumption", "description": "Lookup table for building type to consumption", "datasetHeaders": [ "BuildingActivity", "BuildingConsumptionKwhPerSqFtPerYear" ], "data": "BuildingActivity,BuildingConsumptionKwhPerSqFtPerYear\nEducation,9.1\nFood service,40.575\nHealth care,23.375\nInpatient,28.1\nOutpatient,17.5\nLodging,14.225\nMercantile,16.375\nRetail (other than mall),13.075\nEnclosed and strip malls,19.275\nOffice,13.425\nPublic assembly,11.425\nReligious worship,4.725\nService,7.4\nWarehouse and storage,5.8\nOther,31.55" } 図 1 – 「BuildingToConsumption」参照データセットのスナップショット。 計算に必要な追加の参照データセットをインポートするためにも、同様のステップが適用されます。全体の JSON ファイルは、 GitHub リポジトリ で確認できます。 ユーザーが平方フィート (sqft) または平方メートル (sqm) のいずれかで床面積を入力できるようにするために、「BuildingUnitConversion」という名前の参照データセットを作成する必要があります。 図 2 – 「BuildingUnitConversion」参照データセットのスナップショット。 同様に、ユーザーは消費電力をキロワット時、メガワット時、またはメガジュール (MJ) で提供する可能性があるため、単位変換を可能にする参照データセットを作成する必要があります。この参照データセットは「ElectricityUnitConversion」として保存されます。 図 3 – 「ElectricityUnitConversion」参照データセットのスナップショット。 米国の電力グリッドの排出係数は、eGRID サブリージョンとして知られる地域に分けられています。 割り当てるべき正しい eGRID サブリージョンは、 EPA Emissions & Generation Resource Integrated Database 2023 が提供する施設の米国の郵便番号に基づいています。 この参照データセットは「ZipCodeToEfactor」として保存されています。 図 4 – 「ZipCodeToEfactor」参照データセットのスナップショット。 前述の参照データセットに加えて、EPA の eGRID データベースから EPA 2023 総発電量排出係数 の排出係数を取り込む必要があります。これを実現するために、このソリューションでは排出係数をインポートするために、以下のようなリクエストコールを使用して排出係数ごとに指定する列ヘッダで補完されたデータを 1 行ずつ生成します。 各要因について、以下が送信されます: { "name": "InsertName", "description": "Insert Description", "impacts": { "CO2eq": { "name": "KG C02 eq per MWh", "attributes": { "outUnit": "KG C02 eq per MWh" }, "components": { "co2": { "key": "co2", "value": 1000, "type": "pollutant" }, "ch4": { "key": "ch4", "value": 1000, "type": "pollutant" }, "no2": { "key": "no2", "value": 1000, "type": "pollutant" } } } } } ここで、 Impact_Factor_Name は排出係数の名前です。この場合は eGRID サブリージョンの頭文字です。 Impact_unit は排出係数の単位で、 Ref_unit はこの場合は電力消費量である活動データの参照単位を表します。 最後に、 Total Co2e 、 co2_co2e 、 ch4_co2e 、 n2o_co2e は、総排出係数、ならびに二酸化炭素、メタン、亜酸化窒素成分 (二酸化炭素換算で表記) ごとの排出係数を示しています。 計算 計算には 2 つのユースケースがあります: 電力消費量が提供されている場合: 電力消費量と施設の郵便番号を使用して、対応する炭素排出量を計算します。 電力消費量が提供されていない場合: 施設の種類と床面積から電力消費量を推定します。推定したら、施設の郵便番号を使用して推定された炭素排出量を計算します。 図 5 – 施設レベルの電力データ収集のためのユーザー入力フォーム。 まず、次の式を使用して建物の面積を計算します。 LOOKUP(:BuildingUnit,'BuildingUnitConversion','BuildingAreaUnit','BuildingAreaConversionToSqFt',group='/')*:building_area この LOOKUP 関数は、「BuildingAreaConversionToSqFt」から換算係数を取り出した値を「building_area」に乗じます。 次に、1 平方フィート当たりのエネルギー消費量を以下の式で求めます。 LOOKUP(:BuildingActivity,'BuildingToConsumption','BuildingActivity','BuildingConsumptionKwhPerSqFtPerYear',group='/')*:square_footage この関数は、ユーザーの入力に基づいてエネルギー消費量を取得し、床面積と乗算して総エネルギー消費量を算出します。 次の式を使用して、このエネルギー消費量を MWh に変換します。 LOOKUP(:ElectricityUnit,'ElectricityUnitConversion','ElectricityUnit','ElectricityConversionToMwh',group='/')*:electrictity_value ここでは、LOOKUP 関数が「electricity_value」に変換係数を乗じることで、電力単位を MWh に変換しています。 最後に、総電力消費量からの排出量を計算します。 IMPACT(LOOKUP(:zipCode,'ZipCodeToEfactor','ZipCode','EgridSubRegion',group='/'),'KG C02 eq per MWh',:impactType)*:electricityMwh この式は正しい eGRID リージョンを特定し、IMPACT 関数を使用して特定の排出係数を返します。この排出係数は、総電力消費量と乗算されて、排出量が計算されます。 パイプライン このパイプラインでは、電力使用量に基づくロケーションベースのスコープ 2 排出量の推定を含む、建物の活動データからの炭素排出量を計算します。 「if」句は、建物の面積から電力消費を計算するか、ユーザが提供する電力使用データを使用するかを選択します。全体のパイプラインは、 GitHub リポジトリ からアクセスできます。 結果 ユーザーは最大 5 つの施設について一度に排出量を計算できます。「Calculate」を選択した後、結果は月次比較のために個別または複数の施設全体の合計の両方で表示されます。 図 6 – 月別および施設別の排出量 (kg CO2e)の表示。 ユーザーは結果を .csv ファイルでダウンロードすることもできます。 図 7 – .csv 形式のサンプル出力 結論 この投稿では、施設のスコープ 2 のカーボンフットプリントを計算するために、AWS の Guidance for Carbon Accounting on AWS を使用した React ベースの Web アプリケーションのデプロイしながら、ステップバイステップで技術的なソリューションを紹介しました。 TensorIoT は、AWS のサービスを利用することで、複雑な計算を自動化し、組織のユニークな要件に合わせた炭素会計アプリケーションを AWS 上で提供することに成功しました。 サステナビリティ目標を達成へ向けてAWS を活用したい場合、TensorIoT はあらゆる規模の企業と協力して、ユニークな課題と野心に対処するカスタマイズされたサステナビリティソリューションを計画および確立します。持続可能な未来に向けて一歩ずつ進む旅の中で、TensorIoT にご相談ください。 TensorIoT の詳細は、 AWS Marketplace で確認できます。 TensorIoT – AWS パートナー スポットライト TensorIoT は、IoT、AI/ML、データとアナリティクス、アプリのモダナイゼーションを通じて、お客様のデジタルトランスフォーメーションと持続可能性の向上を可能にする AWS スペシャライゼーションパートナー です。 TensorIoT にコンタクト | パートナー概要 | AWS Marketplace | ケーススタディ この記事は 2024 年 1 月 26 日に Nicholas Burden, Wan Ping Chua, Adom Taylor, Herman Liu, Aditi Suresh, and Edmund Chute によって投稿された「 Building Carbon Accounting Solutions with TensorIoT on AWS 」をソリューションアーキテクト佐藤が翻訳したものです。 ※本稿は英語版ブログの翻訳となります。翻訳版にご不明な点がある場合は英語版ブログの内容を正としてください。

AWS re:invent 2023 では、生成 AI に関する多数の発表 があったため、私はこのテクノロジーを詳しく掘り下げて、できる限り多くのことを学ぼうと決心しました。皆さんも同じ決心をしたならば、AWS コミュニティには利用可能なリソースに加えて 生成 AI ツールやガイドにアクセスできるスペース があるので、ぜひご利用ください。 1月29日週のリリース 1月29日週のリリースの中から、私の目に留まったリリースをいくつかご紹介します。 AWS Glue の Amazon Q データ統合 (プレビュー) – 自然言語を使用して、Amazon Q にジョブのオーサリングや問題のトラブルシューティングの実行をリクエストしたり、AWS Glue とデータ統合に関する質問に答えてもらったりすることができるようになりました。AWS re:invent 2023 でプレビュー版がリリースされた Amazon Q は、問題の解決、コンテンツの生成、およびアクションの実行を支援する生成 AI 駆動のアシスタントです。 CDK Migrate の一般提供開始 – CDK Migrate は、 AWS CloudFormation テンプレート、以前にデプロイされた CloudFormation スタック、または Infrastructure as Code (IaC) 外で作成されたリソースの CDK アプリケーションへの移行を可能にする AWS Cloud Development Kit (CDK) のコンポーネントです。この機能は、リソースとその関係性に基づいて IaC 設定を作成することを可能にするエンドツーエンドエクスペリエンスを提供するために、CloudFormation の IaC ジェネレーター と同時にローンチされました。IaC ジェネレーターは、これまでの 一般的なユースケース に大きな影響を及ぼすことが期待されます。 AWS からの発表の完全なリストについては、「AWS の最新情報」ページをご覧ください。 AWS のその他のニュース 皆さんの好奇心をくすぐると思われるその他のプロジェクト、プログラム、ニュースをいくつかご紹介します。 2023 年、 Amazon API Gateway は 100 兆件を超える API リクエストを処理しました。これは、API 駆動型アプリケーションに対する需要が高まっていることを示しています。API Gateway はフルマネージド型の API 管理サービスです。あらゆる業種のお客様から、さまざまな理由で API Gateway を導入しているとの声が寄せられています。1 つ目は、トラフィック量が最も多いアプリケーションの要求にも対応できるようにスケールする API Gateway の能力です。2 つ目は、フルマネージド型のサーバーレスアーキテクチャです。このアーキテクチャは、インフラストラクチャを管理する必要性をなくして、お客様がコアビジネスニーズに集中できるようにします。 AWS 主催の PartyRock Generative AI Hackathon に参加しましょう。これは、生成 AI 駆動のアプリを実際に構築するというチャレンジで、生成 AI を用いて機能的なアプリを構築するためのプロンプトエンジニアリングと基盤モデル (FM) について学ぶ高速かつ楽しい手段として、 Amazon Bedrock Playground である Amazon PartyRock を使用します。 AWS のオープンソースに関するニュースと最新情報 – 私の同僚である Ricardo が、AWS コミュニティの新しいオープンソースプロジェクト、ツール、およびデモに焦点を当てた、こちらの Open Source Newsletter を毎週執筆しています。 近日開催される AWS イベント お住まいの地域が南北アメリカ、アジア太平洋、日本、または EMEA 地域であるかにかかわらず、 皆さんのタイムゾーンにぴったりの AWS Innovate Online イベント が予定されています。Innovate Online イベントは無料のオンラインイベントで、AWS に関するインスピレーションを得て、知識を深めてもらうことを目的としています。 AWS Summit は、クラウドコンピューティングコミュニティが一堂に集まって交流し、コラボレートして、AWS について学ぶことができる無料のオンラインおよび対面イベントです。これらのイベントは、AWS の製品とサービスについて学び、インフラストラクチャとアプリケーションを構築、デプロイ、および運用するために必要なスキルを身に付けることができるように設計されています。 お近くの AWS Summit を検索 して登録するか、関心のある AWS Summit の登録受付開始時に通知を受ける設定を行ってください。 AWS コミュニティ re:Invent re:Cap – 世界中の AWS ユーザーグループと AWS クラウドクラブのボランティアが主催する コミュニティ re:Cap イベント に参加して、AWS re:Invent からの最新の発表について学びましょう。 近日開催されるすべての対面イベントと仮想イベントを閲覧することができます 。 2月5日週のニュースは以上です。2月12日週の次回 Weekly Roundup もお楽しみに! – Veliswa この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

2023 年 12 月 4 日、AWS は、2023 Magic Quadrant for Strategic Cloud Platform Services (SCPS) でリーダーに選出されました。Gartner が 13 年連続でリーダーとして選出している AWS は、最も長期にわたる Magic Quadrant のリーダーの地位を確立しています。AWS は「実行能力」の軸で最上位に位置付けられています。 以前は Magic Quadrant for Cloud Infrastructure and Platform Services (CIPS) として知られていた SCPS は、「インフラストラクチャサービス (コンピューティング、ネットワーク、ストレージなど)、プラットフォームサービス (マネージドアプリケーションおよびデータサービス)、および変換サービス (顧客がクラウド指向 IT 配信モデルを導入するのに役立つプログラム/リソース) を統合する標準化された自動パブリッククラウドサービス」と定義されています。 仕事柄、多くのお客様と毎週のように話す機会があります。AWS を選んだ主な理由をお客様に尋ねると、いつも以下のような回答が返ってきます。 幅と深さ 。AWS は、コンピューティング、ストレージ、データベース、機械学習 (ML)、データ分析、モノのインターネット (IoT) を始めとする クラウドサービスおよび機能を他のプロバイダーよりも多く提供 しています。そのため、既存のアプリのクラウド移行と新しいアプリの構築をよりすばやく、より簡単に、より安価に行うことができます。AWS のサービスには、コストとパフォーマンスが最適化された広範な目的別データベースなど、深度の高い機能が含まれています。 速いペースのイノベーション 。 AWS は最新のテクノロジーを介したより迅速な実験とイノベーションを可能にします 。AWS は、ビジネストランスフォーメーションを実現する新しいテクノロジーを発明するために、イノベーションのペースを継続的に加速させています。例えば、2014 年には、サーバーレスコンピューティングサービスである AWS Lambda を ローンチ し、開発者によるサーバーのプロビジョニングと管理を排除しました。2017 年には、専用ハードウェアと軽量ハイパーバイザーを組み合わせた AWS Nitro System をローンチし、Amazon EC2 インスタンスのパフォーマンス向上、セキュリティ強化、コスト削減を実現しました。re:Invent 2018 では、 Amazon Elastic Compute Cloud (Amazon EC2) で実行するクラウドワークロードに最も優れたコストパフォーマンスを提供するために設計されたプロセッサファミリである AWS Graviton が 発表 されました。そして、今日、 Amazon Q などの生成人工知能 (AI) サービス、そして開発者の統合開発環境 (IDE) およびコマンドライン (CLI) で使用可能なコーディング生産性ツールである Amazon CodeWhisperer などを活用したイノベーションを継続しています。 お客様とパートナーの大規模なコミュニティ 。AWS は、世界中に数百万のお客様と数万のパートナーがいる大規模で活発なコミュニティを擁しています。ほとんどの業界のさまざまな規模のお客様がさまざまな用途で AWS を使用しています。 AWS パートナーネットワーク には、AWS に特化した数千のシステムインテグレーターと自社テクノロジーを AWS に適応させる何万もの独立系ソフトウェアベンダー (ISV) が含まれています。 また、ワークロードのデプロイとデータの保存を行うことのできる 33 のリージョン を始めとする グローバル AWS インフラストラクチャ を活用することもできます。以前に、マレーシア、ニュージーランド、タイ、および AWS European Sovereign Cloud で開設予定の 4 つのリージョンについてお知らせしました。 AWS リージョンは、複数のアベイラビリティーゾーンが存在する世界中の物理的な場所です。アベイラビリティーゾーンは 1 つ以上の個別のデータセンターで構成されており、それぞれが冗長性を目的として別の施設に設置された電源、ネットワーキング、および接続を備えています。リージョンを単一のデータセンターとして定義することが多い他のクラウドプロバイダーとは異なり、複数のアベイラビリティーゾーンを利用することで、単一のデータセンターと比較して、可用性、耐障害性、スケーラビリティにより優れた本番アプリケーションおよびデータベースを運用できます。 AWS には、17 年以上にわたってグローバルインフラストラクチャを構築してきた経験があります。そして、 Amazon CTO の Werner Vogels が繰り返し述べているように、特にスケール、セキュリティ、パフォーマンスに関しては、「経験に勝るもの」はありません。 2023 Magic Quadrant for Strategic Cloud Platform Services をグラフ化した図を以下に示します。 レビューされた機能と要因の詳細については、 完全な Gartner レポート を参照してください。このレポートでは、使用された方法論と結果が説明されています。このレポートは、顧客に代わってイノベーションを支援するクラウドプロバイダーを選ぶ際の指針となります。 — seb Gartner、 2023 Magic Quadrant for Strategic Cloud Platform Services 、2023 年 12 月 4 日、David Wright、Dennis Smit 共著 Gartner は、研究出版物に記載されているベンダー、製品、サービスを推薦するものではなく、テクノロジーユーザーに最高の評価や他に指名されたベンダーのみを選択するように助言するものでもありません。Gartner の調査出版物は、Gartner の調査組織による見解で書かれたものであり、事実を表明するものではありません。Gartner は、商品性または特定目的適合性に関するいかなる保証も含め、この調査に関する明示黙示の如何を問わず、あらゆる保証の適用を排除します。 GARTNER は、Gartner の登録商標およびサービスマークです。Magic Quadrant は、米国およびその他の国における Gartner および/またはその関連会社の登録商標であり、許可を得て使用しています。All rights reserved. グラフィックは、Gartner が発行した大規模な調査文書の一部であり、文書全体の文脈で評価されるべきものです。Gartner のドキュメントは、 AWS からのリクエストに応じて入手可能です 。 原文は こちら です。

この記事は、 Amazon OpenSearch Service’s vector database capabilities explained を翻訳したものです。 OpenSearch は、Apache 2.0 ライセンスのもとで提供される、検索、分析、セキュリティ監視、可観測性アプリケーションのためのスケーラブルで柔軟かつ拡張性のあるオープンソースソフトウェアスイートです。OpenSearch には、低レイテンシーの検索と集計を実現する検索エンジン OpenSearch、可視化とダッシュボードツールの OpenSearch Dashboards、アラート、きめ細かいアクセスコントロール、可観測性、セキュリティ監視、ベクトルの処理・格納などの高度な機能を提供するプラグイン群が含まれます。 Amazon OpenSearch Service は、OpenSearch を AWS クラウドで簡単にデプロイ、スケール、運用できるようにする、フルマネージドサービスです。 エンドユーザーとして、OpenSearch の検索機能を利用する際、通常、達成したい目的が頭にあります。その目的を達成するために、OpenSearch を利用して情報を集めます (場合によっては、情報そのものが目的であることもあります)。私たちは「検索ボックス」というインターフェースにすっかり慣れており、単語を入力すると、単語と単語のマッチングに基づいて検索エンジンが結果を返してくれます。例えば、家族と暖炉の前でぬくぬく過ごすためにソファーを購入したいとします。Amazon.com にアクセスし、「暖炉のそばに座れる居心地の良い場所」と入力します。残念ながら、Amazon.com でその検索を実行すると、暖炉、ヒーター、インテリア雑貨などが表示されますが、それらは意図したものではありません。問題は、ソファー製造業者が「居心地の良い」「場所」「座る」「暖炉」という単語を製品タイトルや説明に使用していないことです。 近年、検索を強化するために機械学習 (ML) の技術がますます一般的になっています。その中には、埋め込みモデルの使用があります。これは、大量のデータを n 次元の空間にエンコードできるモデルで、各エンティティがベクトル (その空間内のデータポイント) にエンコードされ、類似したエンティティが近くにまとめられるように編成されます。例えば、埋め込みモデルはコーパスの意味をエンコードできます。エンコードされたドキュメントに最も近いベクトルを検索すること、つまり k 最近傍 (k-NN) 検索 により、最も意味的に類似したドキュメントを見つけることができます。高度な埋め込みモデルは、複数のモダリティをサポートできます。たとえば、製品カタログの画像とテキストの両方をエンコードし、両方のモダリティで類似性マッチングを可能にします。 ベクトルデータベースは、k-NN インデックスのような専用インデックスを提供することで、効率的なベクトル類似性検索を実現します。また、ベクトルデータと他のデータ型の管理、ワークロード管理、アクセス制御など、その他のデータベース機能も提供します。 OpenSearch の k-NN プラグインは、OpenSearch のコアとなるベクトルデータベース機能を提供します 。したがって、お客様がカタログで「暖炉のそばに座れる居心地の良い場所」と検索したときに、そのクエリをエンコードして OpenSearch で近傍検索を実行し、暖炉の前にデザイナーが配置した写真のある 8 フィートの青いソファを表示させることができます。 OpenSearch Service をベクトルデータベースとして利用する OpenSearch Service のベクトルデータベース機能を使用すると、セマンティック検索、LLM を用いた検索拡張生成 (RAG)、レコメンドエンジン、リッチメディアの検索などを実装できます。 セマンティック検索 セマンティック検索を使用すると、検索ドキュメントに言語ベースの埋め込みを適用することで、検索結果の関連性を向上させます。検索ユーザーは「暖炉のそばに座れる居心地の良い場所」といった自然言語クエリを使って、8 フィートの青いソファを見つけることができます。詳細は、 Building a semantic search engine in OpenSearch を参照してください。ここでは、キーワード検索と比較して、 nDCG (normalized Discounted Cumulative Gain) メトリクスで測定したときに、セマンティックサーチが 15% の関連性向上を実現できることを学ぶことができます。具体例として、 Semantic and Vector Search with Amazon OpenSearch Service ワークショップでは、 BERT (Bidirectional Encoder Representations from Transformers) モデルに基づいて、キーワード検索とセマンティック検索の違いを探っています。このモデルは Amazon SageMaker でホストされ、ベクトルを生成し OpenSearch に保存します。このワークショップでは、製品の Q&A を例に使って、キーワード/フレーズのクエリを使用したキーワード検索がいくつかの不適切な結果につながることを示しています。一方、セマンティック検索は、クエリのコンテキストと意味をマッチングすることで、より適切なドキュメントを検索することができます。次の図は、ベクトルデータベースとして OpenSearch Service を使用したセマンティック検索アプリケーションのアーキテクチャ例を示しています。 LLM による検索拡張生成 (RAG) RAGは、OpenAI、ChatGPT、 Amazon Titan Text などの LLM を使用して 生成 AI チャットボットを構築する手法です。生成 LLM の台頭に伴い、アプリケーション開発者はこの革新的なテクノロジーを活用する方法を探しています。一つの人気のあるユースケースは、知的エージェントを通じて会話体験を提供することです。あなたは、製品情報、カスタマーセルフサービス、税務報告ルールや疾患と治療に関する医療情報などの業界ドメイン知識のナレッジベースを持つソフトウェアプロバイダーかもしれません。会話型の検索体験は、ユーザーが対話や Q&A を通じて情報をふるい分けるための直感的なインターフェースを提供します。生成 LLM 自体は、モデルが事実とは異なるが真実味のある応答を生成する ハルシネーション に陥りやすいです。RAG は、LLM を外部ナレッジベースで補完することにより、この問題を緩和します。このナレッジベースは、通常、ベクトルエンコードされた知識記事で埋め尽くされたベクトルデータベースを用いて構築されます。 以下の図に示されているように、クエリのワークフローは、エンコードされ、ベクトルデータベースから関連する知識記事を検索するために使用される質問から始まります。その結果は生成 LLM に送信されます。生成 LLM の役割は通常、会話型のレスポンスとして結果を要約することによって、それらの結果を拡張することです。生成モデルにナレッジベースを組み合わせることで、RAG はモデルを事実に基づくようにして、ハルシネーションを最小限に抑えます。 セマンティックサーチワークショップの RAG モジュール では、RAG ソリューションの構築方法の詳細をご覧いただけます。 レコメンドエンジン レコメンドは、特に EC サイトでは検索体験において一般的なコンポーネントです。「こんな商品はいかが」や「この商品を買った人はこんな商品も買っています」といったユーザーエクスペリエンスを追加することで、ユーザーの欲しいものを提供して更なる収益を得ることができます。検索アーキテクトは、 Two-tower ニューラルネットモデル 、 YoutubeDNN などの ディープニューラルネットワーク (DNN) ベースの推薦アルゴリズムを含む様々な技術とテクノロジーを採用してレコメンドシステムを構築しています。例えば、学習済みの埋め込みモデルは、一緒に購入されることが多い商品を類似度が高いとしてエンコードすることで、埋め込み空間内でより近いデータポイントとして表現します。もう一つの可能性は、商品の埋め込みが購買活動ではなく、評価の類似性に基づいている場合です。この親和性データを利用するには、特定のユーザーの埋め込みとデータベース内のベクトル間のベクトル類似度を計算し、推奨アイテムを返します。次の図は、OpenSearch をベクトルストアとして使用してレコメンドエンジンを構築するアーキテクチャ例を示しています。 メディア検索 メディア検索を使用すると、ユーザーは画像、音声、動画などのリッチメディアを使用して検索エンジンにクエリできます。その実装はセマンティック検索と同様です。検索ドキュメントの埋め込みベクトルを作成し、ベクトルを使用して OpenSearch Service にクエリします。違いは、 ResNet のようなコンピュータビジョン深層学習モデル (例えば 畳み込みニューラルネットワーク (CNN) ) を使用して、画像をベクトルに変換することです。次の図は、ベクトルストアとして OpenSearch を使用した画像検索のアーキテクチャ例を示しています。 技術を理解する OpenSearch は、k-NN 検索を実現するために、 NMSLIB 、 FAISS 、 Lucene ライブラリから近似最近傍探索 (ANN) アルゴリズムを使用しています。これらの検索手法は、大規模なデータセットの検索レイテンシを改善するために ANN を採用しています。k-NN プラグインが提供する 3 つの検索手法の中で、この手法は大規模なデータセットに対して最もスケーラブルな検索を実現します。エンジンの詳細は次のとおりです。 Non-Metric Space Library (NMSLIB) – NMSLIB は HNSW ANN アルゴリズムを実装しています Facebook AI Similarity Search (FAISS) – FAISS は HNSW と IVF ANN アルゴリズムの両方を実装しています Lucene – Lucene は HNSW アルゴリズムを実装しています 近似 k-NN 検索に使用される 3 つのエンジンは、それぞれがある状況下で他のエンジンよりも適している独自の属性を持っています。このセクションの一般情報に従うことで、要件を最も満たすエンジンを判断する助けとなるでしょう。 概して、大規模なユースケースには NMSLIB と FAISS を選択する必要があります。Lucene は小規模なデプロイメントに適していますが、状況に応じて最適なフィルタリング戦略 (事前フィルタリング、事後フィルタリング、Exact k-NN) が自動的に適用されるなどの利点があります。次の表は、各オプションの違いを要約しています。 . NMSLIB-HNSW FAISS-HNSW FAISS-IVF Lucene-HNSW 最大次元数 16,000 16,000 16,000 1,024 フィルタ Post filter Filter while search (OpenSearch 2.9 以降) Filter while search (OpenSearch 2.10 以降) Filter while search (OpenSearch 2.4 以降) トレーニングの必要性 不要 不要 必要 不要 類似度指標 l2, innerproduct, cosinesimil, l1, linf l2, innerproduct l2, innerproduct l2, cosinesimil ベクトル容量 数十億 数十億 数十億 1,000万未満 インデクシングのレイテンシ 低 低 最低 低 クエリのレイテンシと品質 低レイテンシ、高品質 低レイテンシ、高品質 低レイテンシ、低品質 高レイテンシ、高品質 ベクトル圧縮 Flat Flat, Product Quantization (PQ) Flat, Product Quantization (PQ) Flat メモリ消費量 高 高, PQ使用時は低 中, PQ使用時は低 高 近似最近傍検索 (Approximate k-NN) と最近傍検索 (Exact k-NN) OpenSearch Service の k-NN プラグインは、ベクトルのインデックスから k 最近傍を得るための 3 つの異なるメソッドをサポートしています。それは、近似 k-NN、スコアスクリプト (Exact k-NN)、Painless 拡張 (Exact k-NN) です。 近似 k-NN 最初の方法は、近似最近傍検索のアプローチです。これは、いくつかのアルゴリズムの 1 つを使用して、クエリベクトルに対して k 個のおおよその最近傍ベクトルを返します。通常、これらのアルゴリズムは、インデクシング速度や検索精度を犠牲にする代わりに、レイテンシの低減、メモリフットプリントの縮小、スケーラブルな検索などのパフォーマンス上のメリットを得ます。近似 k-NN は、低レイテンシを必要とする大規模なインデックス (つまり、数十万ベクトル以上) に対する検索に最適です。k-NN 検索の前にインデックスにフィルタを適用して検索対象のベクトル数を大幅に減らす場合は、近似 k-NN を使用しないでください。この場合は、スコアスクリプトまたは Painless 拡張を使用する必要があります。 スコアスクリプト 2 つ目の方法は、 OpenSearch Service のスコアスクリプト機能を拡張 して、 knn_vector フィールドやバイナリオブジェクトを表すことができるフィールドに対して、Exact k-NN 検索を総当たりで実行することです。このアプローチでは、インデックス内のベクトルのサブセットに対して k-NN 検索を実行できます (時に pre-filter 検索 と呼ばれます)。このアプローチは、ドキュメントの一部に対する検索や pre-filter が必要な場合に推奨されます。大規模なインデックスでこのアプローチを使用すると、高いレイテンシが発生する可能性があります。 Painless 拡張 3 つ目の方法は、より複雑な組み合わせで使用できる Painless 拡張として距離関数を追加するというものです。k-NN スコアスクリプトと同様に、この方法を使用すると、インデックス全体で Exact k-NN 検索を総当たりで実行できます。これは pre-filter もサポートしています。このアプローチは、k-NN スコアスクリプトと比較すると、クエリパフォーマンスがわずかに低下します。最終スコアについてより高度なカスタマイズが必要な場合は、スコアスクリプト k-NN よりもこのアプローチを使用する必要があります。 ベクトル検索アルゴリズム 類似ベクトルを見つける簡単な方法は、 k-最近傍 (k-NN) アルゴリズムを使用することです。これは、クエリベクトルとベクトルデータベース内の他のベクトル間の距離を計算します。先ほど説明したとおり、スコアスクリプト k-NN と Painless 拡張の検索方法は、内部的に Exact k-NN アルゴリズムを使用しています。ただし、次元数が高く極めて大規模なデータセットの場合、これは検索効率を低下させるスケーリングの問題を生じます。近似最近傍 (ANN) 検索は、インデックスをより効率的に再構築し、検索可能なベクトルの次元数を削減するツールを採用することで、これを克服できます。ANN 検索アルゴリズムにはさまざまな種類があります。例えば、局所性鋭敏型ハッシュ、ツリーベース、クラスターベース、グラフベースなどがあります。OpenSearch は、HNSW (Hierarchical Navigable Small Worlds) と IVF (Inverted File System) の 2 つの ANN アルゴリズムを実装しています。OpenSearch で HNSW アルゴリズムと IVF アルゴリズムがどのように機能するかのより詳細な説明については、ブログ記事「 OpenSearch における 10 億規模のユースケースに適した k-NN アルゴリズムの選定 」をご覧ください。 HNSW HNSW アルゴリズムは、ANN 検索のための最も一般的なアルゴリズムの 1 つです。このアルゴリズムの核となるアイデアは、互いに近いインデックスベクトルを結ぶエッジでグラフを構築することです。そして、検索時にこのグラフを部分的に探索して、クエリベクトルのおおよその最近傍を見つけます。クエリの最近傍に向けて探索を誘導するために、アルゴリズムは常にクエリベクトルに最も近い候補を次に探索します。 IVF IVF アルゴリズムは、インデックスベクトルをバケットのセットに分割します。そして、検索時間を短縮するために、それらのバケットのサブセットだけを検索します。しかし、もしこのアルゴリズムがベクトルをランダムに異なるバケットに分割し、その一部だけを検索するのでは、劣った近似になってしまいます。IVF アルゴリズムは、よりエレガントなアプローチを用います。まず、インデクシングをする前に、各バケットに代表ベクトルを割り当てます。ベクトルがインデックス付けされると、最も近い代表ベクトルを持つバケットに追加されます。このようにすることで、互いに近いベクトルはおおよそ同じまたは近いバケットに配置されます。 ベクトルの類似度指標 すべての検索エンジンは、類似度指標を使用して結果をランク付けおよびソートし、最も関連性の高い結果を上位に表示します。プレーンテキストのクエリを使用する場合、類似度指標は TF-IDF と呼ばれ、クエリ内の用語の重要性を測定し、テキストの一致数に基づいてスコアを生成します。クエリにベクトルが含まれている場合、類似度指標は空間的な性質を持ち、ベクトル空間内の近接性を利用します。OpenSearch は、いくつかの類似度または距離尺度をサポートしています。 ユークリッド距離 – 点間の直線距離です。 L1 (マンハッタン) 距離 – すべてのベクトル成分の差分の和です。L1 距離は、例えて言うと点 A から点 B へ移動するのに必要な直交する市街地のブロック数を測定します。 L-∞ (チェス盤・チェビシェフ) 距離 – 例えると、n 次元のチェス盤上をキングが移動する手数です。対角線上ではユークリッド距離とは異なります。つまり、2 次元のチェス盤での対角ステップは、ユークリッド距離で 1.41 単位離れていますが、L-∞ 距離では 2 単位離れています。 内積 – 2 つのベクトルの大きさとその間の角度のコサインの積です。通常、自然言語処理 (NLP) のベクトル類似度に使用されます。 コサイン類似度 – ベクトル空間内の 2 つのベクトル間の角度のコサインです。 ハミング距離 – 2 進符号化されたベクトルについて、2 つのベクトル間で異なるビットの数です。 OpenSearch をベクトルデータベースとして利用するメリット OpenSearch Service をベクトルデータベースとして使用する場合、使いやすさ、スケーラビリティ、可用性、相互運用性、セキュリティなどのサービス機能を活用できます。より重要なことに、OpenSearch の検索機能を利用して検索エクスペリエンスを向上させることができます。たとえば、OpenSearch の Learning to Rank 機能を使用して、ユーザーのクリックスルー動作のデータを検索アプリケーションに統合し、関連性を向上させることができます。また、OpenSearch のテキスト検索とベクトル検索の機能を組み合わせて、キーワードとセマンティックな類似性に基づいてドキュメントを検索することもできます。インデックスの他のフィールドを使用してドキュメントをフィルタリングし、関連性を向上させることもできます。上級者向けには、ハイブリッドスコアリングモデルを使用して、 Okapi BM25 関数によって計算される OpenSearch のテキストベースの関連度スコア とベクトル検索スコアを組み合わせ、検索結果のランキングを改善することができます。 スケールと制限 OpenSearch はベクトルデータベースとして、数十億のベクトルレコードをサポートします。クラスタのサイズを決定する際には、ベクトルの数と次元に関する以下の計算を念頭に置いてください。 ベクトルの数 OpenSearch VectorDB は OpenSearch のシャーディング機能を活用し、ベクトルをシャード化し水平方向にノードを追加することで、1 桁ミリ秒のレイテンシで数十億個のベクトルまでスケールできます。1 台のマシンに収まるベクトル数は、そのマシンのオフヒープメモリの可用量の関数で決まります。必要なノード数は、ノードごとにアルゴリズムで使用できるメモリ量と、アルゴリズムが必要とするメモリの総量に依存します。ノードが多いほど、メモリが増え、パフォーマンスが向上します。ノードごとに利用可能なメモリ量は、 memory_available = ( node_memory – jvm_size ) * circuit_breaker_limit として計算されます。パラメータの説明は以下の通りです。 node_memory – インスタンスの全メモリ容量。 jvm_size – OpenSearch の JVM ヒープサイズ。これはインスタンス RAM の半分に設定され、約 32 GB で上限が設定されます。 circuit_breaker_limit – サーキットブレーカーのネイティブメモリ使用量のしきい値。これは 0.5 に設定されます。 クラスター全体のメモリ見積もりは、ベクトルレコード数とアルゴリズムに依存します。HNSW と IVF には異なるメモリ要件があります。詳細については、 Memory Estimation を参照してください。 次元数 OpenSearch のベクトルフィールド knn_vector に対する現在の次元制限は 16,000 次元です。各次元は 32 ビットの浮動小数点数で表されます。次元数が多いほど、インデクシングと検索に必要なメモリが多くなります。次元数は通常、エンティティをベクトルに変換する埋め込みモデルによって決定されます。 knn_vector フィールドを構築する際に選択できるオプションはたくさんあります。正しいメソッドとパラメータを選択するには、 Choosing the right method を参照してください。 お客様のストーリー Amazon Music Amazon Music は、ユーザーにユニークでパーソナライズされた体験を提供するために、常にイノベーションを行っています。Amazon Music の音楽レコメンドのアプローチの 1 つは、クラシックな Amazon のイノベーションである アイテム間の協調フィルタリング とベクトルデータベースのリミックスです。ユーザーのリスニング行動に基づいて集計されたデータを使用し、Amazon Music は、類似したトラックを類似したベクトルとして表現するベクトル空間に、音楽トラックと顧客表現をエンコードする埋め込みモデルを作成しました。10 億曲の楽曲がベクトルにエンコードされ、OpenSearch にインデックスされ、複数の地域に配信されて、リアルタイムのレコメンドを実現しています。OpenSearch は現在、10 億 5,000 万のベクトルを管理しており、Amazon Music のレコメンドを支えるために、ピーク時には 1 秒あたり 7,100 ベクトルクエリを処理しています アイテム間の協調フィルターは、大規模な顧客基盤と製品カタログへのスケーリングに効果的であることから、オンライン製品レコメンドに最も人気のある方法の 1 つです。OpenSearch はスケールアウトするインフラストラクチャ、トラック数に応じて線形に成長する k-NN インデックス、対数時間での類似性検索を提供することで、レコメンダーの運用とスケーラビリティの向上を容易にしています。次の図は、ベクトル埋め込みによって作成された高次元空間を可視化したものです。 Amazon におけるブランド保護 Amazon は、お客様に本物の商品を最大限幅広く選択していただけるよう努め、世界で最も信頼できるショッピング体験を提供することを目指しています。お客様からの信頼を獲得し維持するために、偽造品の販売を厳しく禁止するとともに、本物の商品のみがお客様のもとに届くことを保証するイノベーションに対して引き続き投資しています。Amazon のブランド保護プログラムは、ブランドを正確に表現し、完全に保護することでブランドとの信頼関係を築いています。私たちが提供する信頼できる体験が世間の認識と一致するよう努めています。当社のブランド保護戦略は、次の 4 つの柱に焦点を当てています。(1)予防管理、(2)ブランドを保護するための強力なツール、(3)不正行為者の責任追及、(4)お客様の保護と教育です。Amazon OpenSearch Service は、Amazon の予防管理の重要な一部を担っています。 2022 年、Amazon の自動化テクノロジーは、商品の詳細ページで潜在的な悪用の兆候を探すために、毎日 80 億件以上の変更の試みをスキャンしました。当社のプロアクティブコントロールは、ブランドがそれを見つけて報告する前に、ブロックまたは削除されたリスティングの 99 %以上を発見しました。これらのリスティングは、詐欺、侵害、偽造、またはその他の形態の悪用のリスクがあると疑われました。これらのスキャンを実行するために、Amazon は、世界中の Amazon の店舗におけるリスティングの知的財産権侵害の検出を自動化するための高度な機械学習モデルの使用など、高度で革新的なテクニックを使用するツールを作成しました。このような自動システムを実装する上での主な技術的課題は、膨大な数十億ベクトルコーパス内で保護された知的財産を、高速かつスケーラブルでコスト効率の良い方法で検索できる能力です。ブランドと自動システムが、高可用かつ高速 (秒以下) の検索 API を介してリアルタイムでの侵害検出を実行できるように、Amazon OpenSearch Service のスケーラブルベクトルデータベース機能と分散アーキテクチャを活用して、合計 680 億の 128 次元および 1024 次元ベクトルを OpenSearch Service にインデックスする取り込みパイプラインを開発しました。 結論 生成 AI ソリューションを構築したり、リッチメディアやオーディオを検索したり、既存の検索ベースのアプリケーションによりセマンティックな検索を加えたりするには、OpenSearch は有能なベクトルデータベースです。OpenSearch は様々なエンジン、アルゴリズム、距離尺度をサポートしており、適切なソリューションを構築することができます。OpenSearch は、低レイテンシで数十億のベクトルに対応できる、スケーラブルなエンジンを提供します。OpenSearch とそのベクトル DB 機能により、ユーザーは簡単に 8 フィートの青いソファを見つけ、暖かい火のそばでリラックスできます。

この記事は、 Fine-tune and deploy Llama 2 models cost-effectively in Amazon SageMaker JumpStart with AWS Inferentia and AWS Trainium  を翻訳したものです。 本日、 Amazon SageMaker JumpStart における AWS Trainium および AWS Inferentia インスタンスを使用した Llama 2 推論とファインチューニングのサポートの提供を発表できることを大変嬉しく思います。SageMaker を通じて AWS Trainium および AWS Inferentia ベースのインスタンスを使用することで、ファインチューニングのコストを最大50%、トークンあたりのレイテンシを低減しながら、デプロイメントコストを 4.7 倍低減できます。Llama 2 は、最適化された Transformer アーキテクチャーを使用した自己回帰型のテキスト生成モデルです。一般に利用可能なモデルとして、Llama 2 は、テキスト分類、感情分析、言語翻訳、言語モデリング、テキスト生成、対話システムなど、多くの 自然言語処理（NLP）タスクに向けて設計されています。Llama 2 のような大規模言語モデル（LLM）のファインチューニングやデプロイは、コストがかさんだり、顧客体験を向上させるためのリアルタイム性能を満たすことが困難になることがあります。AWS Trainium および AWS Inferentia は、 AWS Neuron ソフトウェア開発キット(SDK)によって利用可能となっており、Llama 2 モデルのトレーニングと推論において、高性能かつコスト効果の高いオプションを提供します。 この投稿では、SageMaker JumpStart において AWS Trainium と AWS Inferentia インスタンスで Llama 2 をデプロイおよびファインチューニングを行う方法を示します。 ソリューションの概要 このブログでは、以下のシナリオについて説明します。 Amazon SageMaker Studio UI でのワンクリックでのデプロイ、または SageMaker Python SDK を利用して、 AWS Inferentia インスタンスに Llama 2 のデプロイを行います。 SageMaker Studio UI および SageMaker Python SDK の両方で AWS Trainium インスタンス上で Llama 2 のファインチューニングを行います。 ファインチューニングされた Llama 2 モデルのパフォーマンスを、事前学習されたモデルと比較し、ファインチューニングの有効性を示します。 実際に動かす際は、 GitHub のサンプルノートブック をご覧ください。 SageMaker Studio UI と Python SDK を使った、AWS Inferentia への Llama 2 のデプロイ このセクションでは、SageMaker Studio UI を使用しワンクリックのデプロイ操作とPython SDK で、Llama 2 を AWS Inferentia インスタンスにデプロイする方法を示します。 SageMaker Studio UI で Llama 2 モデルを探す SageMaker JumpStart は、一般に公開されているものとプロプライエタリな 基盤モデル の両方へのアクセスを提供します。基盤モデルは、サードパーティおよびプロプライエタリなプロバイダーから提供およびメンテナンスされます。そのため、これらはモデルのソースによって指定された異なるライセンスの下でリリースされています。使用する基本モデルのライセンスを必ず確認してください。ダウンロードやコンテンツの使用を行う前に、適用されるライセンス条項を確認し、使用ケースに適していることを確認する責任があります。 SageMaker JumpStart を通じて、SageMaker Studio UI および SageMaker Python SDK で Llama 2 基盤モデルにアクセスできます。このセクションでは、SageMaker Studio でモデルを検出する方法について説明します。 SageMaker Studio は、統合開発環境（IDE）であり、すべての機械学習（ML）開発ステップを実行するための特定用途向けツールにアクセスできる単一の Web ベースのビジュアルインターフェースを提供します。SageMaker Studio の開始とセットアップ方法の詳細については、 こちら を参照してください。 SageMaker Studio に入ると、SageMaker JumpStart にアクセスできます。ここでは、 Prebuilt and automated solutions の項目から、事前学習されたモデル、ノートブック、および事前構築されたソリューションが閲覧できます。プロプライエタリモデルにアクセスする詳細情報については、 Use proprietary foundation models from Amazon SageMaker JumpStart in Amazon SageMaker Studio を参照してください。 SageMaker JumpStart のランディングページからは、ソリューション、モデル、ノートブック、およびその他のリソースを閲覧できます。 Llama 2 モデルが表示されない場合は、SageMaker Studioをシャットダウンして再起動してバージョンを更新してください。バージョンの更新に関する詳細は、 Shut down and Update Studio Classic Apps を参照してください。 Explore All Text Generation Models を選択するか、検索ボックスに 、 llama または neuron と入力することで、他のモデルバリエーションも見つけることができます。 SageMaker Jumpstart による Llama-2-13b モデルのデプロイ モデルカードを選択して、ライセンス、トレーニングに使用されたデータ、および使用方法などモデルの詳細を表示できます。また、このノーコードの例を使用してモデルを利用するための Deploy ボタンと Open notebook ボタンも見つけることができます。 どちらかのボタンを選択すると、ポップアップが表示され、エンドユーザーライセンス契約書および利用規約（AUP）が表示されます。これらに同意するかどうかを確認できます。 ポリシーに承認すると、モデルのエンドポイントをデプロイすることが可能になり、次のセクションで示すように使うことができます。 Python SDK による Llama 2 Neuron モデルのデプロイ Deploy を選択してポリシーに同意すると、モデルのデプロイが開始されます。また、 Open notebook  を選択して例となるノートブックを使用することもできます。ノートブックには、モデルのデプロイから推論の実施、リソースのクリーンアップまでの一連のガイダンスが記述されています。 AWS Trainium または AWS Inferentia インスタンス上でモデルをデプロイまたはファインチューニングするには、まず PyTorch Neuron（ torch-neuronx ）を呼び出して、モデルを Neuron 固有のグラフにコンパイルする必要があります。これにより、Inferentia の NeuronCore に最適化されます。ユーザーは、アプリケーションの目的に応じて、最小のレイテンシまたは最大のスループットを最適化するようにコンパイラに指示できます。JumpStart では、様々な構成に対して Neuron グラフを事前にコンパイルしており、ユーザーがコンパイル手順を省略し、迅速にモデルをファインチューニングおよびデプロイできるようにしています。 Neuron の事前コンパイルされたグラフは、特定の Neuron Compiler バージョンに基づいて作成されていることに注意してください。 AWS Inferentia ベースのインスタンスで LIama 2 をデプロイする方法は 2 つあります。一つ目の方法は、事前に構築された構成を使用し、わずか 2 行のコードでモデルをデプロイできるようにします。二つ目の方法では構成に対してより細かい制御が可能です。まず、一つ目の方法である事前構築の構成を使用し、例として事前学習されたLlama 2 13B Neuronモデルを使用してLlama 13Bをわずか2行でデプロイする方法を以下に示します。 from sagemaker.jumpstart.model import JumpStartModel model_id = "meta-textgenerationneuron-llama-2-13b model = JumpStartModel(model_id=model_id) pretrained_predictor = model.deploy(accept_eula=False) ## To set 'accept_eula' to be True to deploy これらのモデルで推論を実行するには、 model.deploy() の呼び出しの一部として、 accept_eula 引数を True に指定する必要があります。この引数を True に設定すると、モデルの EULA に同意したことになります。EULA はモデルカードの説明または Meta のウェブサイト から入手できます。 Llama 2 13Bのデフォルトのインスタンスタイプは ml.inf2.8xlarge  です。他のサポートされているモデルも試すことができます。 meta-textgenerationneuron-llama-2-7b meta-textgenerationneuron-llama-2-7b-f （チャットモデル） meta-textgenerationneuron-llama-2-13b-f （チャットモデル） また、デプロイの構成をより細かく制御したい場合、コンテキストの長さ、テンソル並列度、最大ローリングバッチサイズなどを環境変数を介して変更することができます。デプロイに使用する Deep Learning Container (DLC) は Large Model Inference (LMI) NeuronX DLC です。環境変数は以下の通りです。 OPTION_N_POSITIONS – 入力および出力トークンの最大数。例えば、 OPTION_N_POSITIONS を 512 でモデルをコンパイルした場合、入力トークンは 128（入力プロンプトサイズ）、最大出力トークンは 384（入力および出力トークンの合計が 512 になるように）を使用できます。最大出力トークンについては、384 以下の値なら問題ありませんが、それを超えてはいけません（例: 入力 256 および出力 512）。 OPTION_TENSOR_PARALLEL_DEGREE  – AWS Inferentia インスタンスでモデルをロードする NeuronCore の数。 OPTION_MAX_ROLLING_BATCH_SIZE  – 同時リクエストの最大バッチサイズ。 OPTION_DTYPE  – モデルをロードするデータタイプ。 Neuron グラフのコンパイルは、コンテキストの長さ ( OPTION_N_POSITIONS )、テンソル並列度 ( OPTION_TENSOR_PARALLEL_DEGREE )、最大バッチサイズ ( OPTION_MAX_ROLLING_BATCH_SIZE )、およびデータタイプ ( OPTION_DTYPE ) に依存します。SageMaker JumpStart では、これらのパラメータのためのさまざまな構成の Neuron グラフを事前にコンパイルしており、ランタイムのコンパイルを回避するための設定が表に記載されています。環境変数が以下のカテゴリのいずれかに該当する場合、Neuron グラフのコンパイルはスキップされます。 LIama-2 7B and LIama-2 7B Chat Instance type OPTION_N_POSITIONS OPTION_MAX_ROLLING_BATCH_SIZE OPTION_TENSOR_PARALLEL_DEGREE OPTION_DTYPE ml.inf2.xlarge 1024 1 2 fp16 ml.inf2.8xlarge 2048 1 2 fp16 ml.inf2.24xlarge 4096 4 4 fp16 ml.inf2.24xlarge 4096 4 8 fp16 ml.inf2.24xlarge 4096 4 12 fp16 ml.inf2.48xlarge 4096 4 4 fp16 ml.inf2.48xlarge 4096 4 8 fp16 ml.inf2.48xlarge 4096 4 12 fp16 ml.inf2.48xlarge 4096 4 24 fp16 LIama-2 13B and LIama-2 13B Chat ml.inf2.8xlarge 1024 1 2 fp16 ml.inf2.24xlarge 2048 4 4 fp16 ml.inf2.24xlarge 4096 4 8 fp16 ml.inf2.24xlarge 4096 4 12 fp16 ml.inf2.48xlarge 2048 4 4 fp16 ml.inf2.48xlarge 4096 4 8 fp16 ml.inf2.48xlarge 4096 4 12 fp16 ml.inf2.48xlarge 4096 4 24 fp16 以下は、Llama 2 13B のデプロイと設定の例になります。 from sagemaker.jumpstart.model import JumpStartModel model_id = "meta-textgenerationneuron-llama-2-13b-f" model = JumpStartModel( model_id=model_id, env={ "OPTION_DTYPE": "fp16", "OPTION_N_POSITIONS": "4096", "OPTION_TENSOR_PARALLEL_DEGREE": "12", "OPTION_MAX_ROLLING_BATCH_SIZE": "4", }, instance_type="ml.inf2.24xlarge" ) pretrained_predictor = model.deploy(accept_eula=False) ## To set 'accept_eula' to be True to deploy これで Llama-2-13b モデルをデプロイしたので、エンドポイントを呼び出すことで推論を実行できます。以下では、サポートされている推論時の設定パラメータを示しています。 max_length – 出力の長さ（入力のコンテキスト長を含む）が max_length に達するまでモデルはテキストを生成します。指定された場合、正の整数である必要があります。 max_new_tokens – 出力の長さ（入力のコンテキスト長を除く）が max_new_tokens に達するまでモデルはテキストを生成します。指定された場合、正の整数である必要があります。 num_beams – 貪欲法で使用されるビームの数を示します。指定された場合、 num_return_sequences  以上の整数である必要があります。 no_repeat_ngram_size – 出力シーケンスで no_repeat_ngram_size の単語の並びが繰り返されないようにモデルが保証します。指定された場合、正の整数で 1 より大きい必要があります。 temperature – 出力のランダム性を制御します。高い温度では低確率の単語の出力シーケンスが生成され、低い温度では高確率の単語の出力シーケンスが生成されます。 temperature が 0 の場合、貪欲なデコーディングが行われます。指定された場合、正の浮動小数点数である必要があります。 early_stopping – True の場合、すべてのビームの仮説が文の終端トークンに到達した時点でテキスト生成が終了します。指定された場合、 Boolean である必要があります。 do_sample – True の場合、モデルは次の単語を尤度に従ってサンプリングします。指定された場合、 Boolean である必要があります。 top_k – テキスト生成の各ステップで、モデルは top_k で最も尤もらしい単語からサンプリングします。指定された場合、正の整数である必要があります。 top_p – テキスト生成の各ステップで、モデルは top_p の累積確率で最小の可能な単語のセットからサンプリングします。指定された場合、0 から 1 の浮動小数点数である必要があります。 stop – 指定された場合、文字列のリストである必要があります。指定された文字列のいずれかが生成された場合、テキスト生成は停止します。 以下は推論コードの例を示しています。 payload = { "inputs": "I believe the meaning of life is", "parameters": { "max_new_tokens": 64, "top_p": 0.9, "temperature": 0.6, }, } response = pretrained_predictor.predict(payload) 出力は以下になります。 I believe the meaning of life is > to be happy. I believe that happiness is a choice. I believe that happiness is a state of mind. I believe that happiness is a state of being. I believe that happiness is a state of being. I believe that happiness is a state of being. I believe that happiness is a state of being. I believe パラメータに関する詳細な情報については、 こちら を参照してください。 SageMaker Studio UI と SageMaker Python SDK を使用した、Trainium インスタンスでの Llama 2 モデルのファインチューニング 生成 AI の基盤モデルは、機械学習（ML）および人工知能（AI）の主要な焦点となっていますが、さまざまな領域における汎化は、ヘルスケアや金融サービスなど特定の領域で独自のデータが関与する場合には不十分な場合があります。このことは、生成 AI モデルを特定の領域においてパフォーマンスを向上させるために、ドメイン固有のデータでファインチューニングが必要であることを強調しています。 事前学習済みの Llama 2 モデルをデプロイしましたが、このモデルをドメイン固有のデータでファインチューニングし、正確性を向上させ、プロンプトの補完を改善し、モデルを特定のビジネスユースケースとデータに適応させる方法を見てみましょう。モデルのファインチューニングは、SageMaker Studio UI またはSageMaker Python SDK のいずれかを使用して行うことができます。このセクションでは、両方の方法について説明します。 SageMaker Studioを使用した Llama-2-13b Neuron モデルのファインチューニング SageMaker Studio に入り、Llama-2-13b Neuron モデルに移動します。 Deploy タブで、ファインチューニングのためのトレーニングおよび検証データセットが含まれる Amazon Simple Storage Service (Amazon S3) バケットを指定できます。さらに、ファインチューニングのためのデプロイ設定、ハイパーパラメータ、およびセキュリティ設定を構成することができます。その後、SageMaker ML インスタンス上でトレーニングジョブを開始するために Train  を選択します。 Llama 2 モデルを使用するには、EULA および AUP に同意する必要があります。 Train を選択するとそれらが表示されます。ファインチューニングジョブを開始するためには、 I have read and accept EULA and AUP  を選択してください。 ファインチューニングされたモデルのトレーニングジョブのステータスは、SageMaker コンソールのナビゲーションペインで Training jobs  を選択することで確認できます。 このノーコードの例を使用してLlama 2 Neuron モデルをファインチューニングするか、次のセクションで示すように Python SDK を使用してファインチューニングすることができます。 SageMaker Python SDK を使用した Llama-2-13b Neuron モデルをファインチューニング ドメイン適応の形式または 命令ベースのファインチューニング形式 のデータセットでファインチューニングすることができます。以下は、ファインチューニングを行う前にトレーニングデータをどのようにフォーマットするかの手順です。 Input – JSON lines (.jsonl) またはテキスト (.txt) 形式のファイルが含まれている train ディレクトリです。 JSON lines (.jsonl) ファイルの場合、各行は個別の JSON オブジェクトです。各 JSON オブジェクトは、キーが text であり、値が 1 つのトレーニング例の内容であるキーと値のペアに構造化される必要があります。 train ディレクトリ内のファイル数は 1 と等しくする必要があります。 Output  – 推論にデプロイできるトレーニングされたモデルです。 この例では、命令ベースのファインチューニング形式で Dolly データセット のサブセットを使用しています。Dolly データセットには、質問応答、要約、情報抽出などのさまざまなカテゴリの約 15,000 の命令に従ったレコードが含まれています。これはApache 2.0ライセンスのもとで利用可能です。ファインチューニングには information_extraction  の例を使用しています。 Dolly データセットをロードし、 train （ファインチューニング用）と test （評価用）に分割します。 from datasets import load_dataset dolly_dataset = load_dataset("databricks/databricks-dolly-15k", split="train") task = "information_extraction" To train for summarization/closed question and answering, you can replace the assertion in next line to example["category"] == "sumarization"/"closed_qa". summarization_dataset = dolly_dataset.filter(lambda example: example["category"] == task) summarization_dataset = summarization_dataset.remove_columns("category") We split the dataset into two where test data is used to evaluate at the end. train_and_test_dataset = summarization_dataset.train_test_split(test_size=0.1) Dumping the training data to a local file to be used for training. train_and_test_dataset["train"].to_json("train.jsonl") 2. トレーニングジョブのためのインストラクション形式のデータの前処理には、プロンプトのテンプレートを使用します。 prompt = ("""Below is an instruction that describes a task, paired with an input that provides further context. Write a response that appropriately completes the request.\n\n### Instruction:\n{instruction}\n\n### Input:\n{context}### Response:\n{response}\n\n<s>""") ハイパーパラメーターを検証し、ユースケースに応じて上書きを行います。 from sagemaker import hyperparameters model_id = "meta-textgenerationneuron-llama-2-13b" model_version = "1.*" my_hyperparameters = hyperparameters.retrieve_default( model_id=model_id, model_version=model_version ) my_hyperparameters["max_input_length"] = "4096" ## you can increase it up to 4096 for sequence length. my_hyperparameters["max_steps"] = "25" my_hyperparameters["learning_rate"] = "0.0001" print(my_hyperparameters) hyperparameters.validate(model_id=model_id, model_version=model_version, hyperparameters=my_hyperparameters) 4. モデルをファインチューニングし、SageMaker トレーニングジョブを開始します。ファインチューニングスクリプトは、 neuronx-nemo-megatron リポジトリに基づいており、これは Neuron および EC2 Trn1 インスタンスでの使用に適応された NeMo と Apex パッケージのバージョンです。neuronx-nemo-megatron リポジトリには、LLM をスケールしてファインチューニングするための 3D（データ、テンソル、およびパイプライン）並列処理が備わっています。サポートされている Trainium インスタンスは ml.trn1.32xlarge および ml.trn1n.32xlarge です。 from sagemaker.jumpstart.estimator import JumpStartEstimator estimator = JumpStartEstimator( model_id=model_id, model_version=model_version, hyperparameters=my_hyperparameters, environment={"accept_eula": "false"}, # please change `accept_eula` to be `true` to accept EULA. #instance_type="ml.trn1n.32xlarge", if not specified, default `ml.trn1.32xlarge` will be used. ) estimator.fit({"train": train_data_location}) 5. 最後に、ファインチューニングされたモデルを SageMaker エンドポイントへデプロイします。 finetuned_predictor = estimator.deploy() 事前学習済みとファインチューニングされた Llama 2 Neuron モデルのレスポンスの比較 Llama-2-13b の事前学習済みモデルとファインチューニングされたモデルのプロンプト補完の性能比較を以下の表に示します。また、SEC Filing データセットを. txt 形式で使用して Llama 2 をファインチューニングする例も提供しています。詳細については、GitHubのサンプル ノートブック を参照してください。 Item Inputs Ground truth Response from non-finetuned model Response from fine-tuned model 1 Below is an instruction that describes a task, paired with an input that provides further context. Write a response that appropriately completes the request.\n\n### Instruction:\nExtract universities Moret studied at and his year of graduation for each, and put them in a bulleted list.\n\n### Input:\nMoret was born in 1953 in Vevey Switzerland, and did his undergraduate studies at the École Polytechnique Fédérale de Lausanne (EPFL), graduating in 1975. He went on to graduate studies at the University of Tennessee, earning a Ph.D. in 1980. He then joined the faculty of the University of New Mexico, where he remained until 2006, when he moved to EPFL. He retired from EPFL in December 2016.\n\nIn 1996, Moret founded the ACM Journal of Experimental Algorithmics, and he remained editor in chief of the journal until 2003. In 2001, Moret founded the Workshop in Algorithms for Bioinformatics (WABI) and remains on the Steering Committee for the conference.\n\nIn 2018, Moret was elected as a Fellow of the International Society for Computational Biology, for his outstanding contributions to the fields of computational biology and bioinformatics.\n\n### Response:\n * École Polytechnique Fédérale de Lausanne (EPFL) (graduated 1975)\n* University of Tennessee (graduated 1980) Moret studied at the École Polytechnique Fédérale de Lausanne (EPFL) and the University of Tennessee, graduating in1975 and1980, respectively.\n\n### Hint:\n\n- Use the `split` function to split the input into a list of sentences.\n- Use the `split` function to split each sentence into a list of words.\n- Use the `split` function to split – École Polytechnique Fédérale de Lausanne (EPFL),1975\n- University of Tennessee,1980\n- University of New Mexico\n- École Polytechnique Fédérale de Lausanne (EPFL),2006\n\n<s> Below is an instruction that describes a task, paired with an input that provides further context. Write a response that appropriately completes the request.\n 2 Below is an instruction that describes a task, paired with an input that provides further context. Write a response that appropriately completes the request.\n\n### Instruction:\nFrom the passage identify the attributes of Dionysus. Display the results in a comma separated format.\n\n### Input:\nDionysus (Διόνυσος, Diónusos)/Bacchus (Βάκχος, Bákkhos)\n\nGod of wine, fruitfulness, parties, festivals, madness, chaos, drunkenness, vegetation, ecstasy, and the theater. He is the twice-born son of Zeus and Semele, in that Zeus snatched him from his mother’s womb and stitched Dionysus into his own thigh and carried him until he was ready to be born. In art he is depicted as either an older bearded god (particularly before 430 BC) or an effeminate, long-haired youth (particularly after 430 BC). His attributes include the thyrsus, a drinking cup, the grape vine, and a crown of ivy. He is often in the company of his thiasos, a group of attendants including satyrs, maenads, and his old tutor Silenus. The consort of Dionysus was Ariadne. It was once held that Dionysius was a later addition to the Greek pantheon, but the discovery of Linear B tablets confirm his status as a deity from an early period. Bacchus was another name for him in Greek, and came into common usage among the Romans. His sacred animals include dolphins, serpents, tigers, and donkeys.\n\n### Response:\n the thyrsus, a drinking cup, the grape vine, a crown of ivy Dionysus (Διόνυσος, Diónusos)\n\nGod of wine, fruitfulness, parties, festivals, madness, chaos, drunkenness, vegetation, ecstasy, and the theater. He is the twice-born son of Zeus and Semele, in that Zeus snatched him from his mother’s womb and stitched Dionysus into his own thigh thyrsus, a drinking cup, the grape vine, a crown of ivy\n\n<s> Below is an instruction that describes a task, paired with an input that provides further context. Write a response that appropriately completes the request.\n\n### Instruction:\nWhat is the difference between Parthian and Arsacid Empire?\n\n### Input:\nThe Parthian Empire, also known as the Arsacid Empire was a 3 Below is an instruction that describes a task, paired with an input that provides further context. Write a response that appropriately completes the request.\n\n### Instruction:\nWhy does the capital of Uzbekistan contain the biggest Greek community?\n\n### Input:\nThe Greeks in Uzbekistan number approximately 9,000. The community is made up of Greeks from Russia who were deported by force from that country to Uzbekistan in the 1940s, and political refugees from Greece. About 30,000 Greeks lived in the country before World War II and a further 11,000 arrived after the Greek Civil War and the defeat of Democratic Army of Greece. Their numbers have dwindled from a high of some 40,000 in the 1960s. The main reason is emigration to Greece after the end of the Cold War when laws allowed the return of all ethnic Greeks who had been exiled for political reasons after the Greek Civil War. The biggest Greek community in the country is in the capital city of Tashkent where most of the Greek political refugees were relocated by the Soviet authorities. In ancient times the south of the country was part of the Hellenistic Seleucid Kingdom but the few Greek communities there have since assimilated. The most important organization representing ethnic Greeks is the Greek Cultural Association of Tashkent. The activities of this organization include Greek language instruction (19 classes with a total of 571 students, classes for adults) and the teaching of Greek dances and music.\n\n### Response:\n Most of the Greek political refugees in Uzbekistan were relocated by the Soviet authorities to the capital city of Tashkent. \n“`\nThe capital of Uzbekistan contains the biggest Greek community because the Greeks in Uzbekistan number approximately9,000. The community is made up of Greeks from Russia who were deported by force from that country to Uzbekistan in the1940s, and political refugees from Greece. About30,000 Greeks lived in the country before World War II and a further11,00 The capital of Uzbekistan contains the biggest Greek community because that is where most of the Greek political refugees were relocated by the Soviet authorities after being deported from Greece.\n\n<s> Below is an instruction that describes a task, paired with an input that provides further context. Write a response that appropriately completes the request.\n\n### Instruction:\nWhat is the difference between Parthian and Arsacid Empire?\n\n### Input:\n ファインチューニングモデルからの応答は、事前学習済みモデルと比較して精度、関連性、明確さで著しい改善を示しています。いくつかのケースでは、ユースケースに対して事前学習済みモデルを使用するだけでは十分でない場合があり、このテクニックを使用してファインチューニングすることで、解決策をデータセットによりパーソナライズが可能となります。 クリーンアップ トレーニングジョブが完了し、既存のリソースをもう使用しない場合は、以下のコードを使用してリソースを削除できます。 # Delete resources # Delete the fine-tuned model finetuned_predictor.delete_model() # Delete the fine-tuned model endpoint finetuned_predictor.delete_endpoint() 結論 Llama 2 Neuron モデルの SageMaker 上でのデプロイおよびファインチューニングは、大規模な生成AIモデルの管理と最適化において著しい進歩を示しています。Llama-2-7b や Llama-2-13b などのバリエーションを含んだモデルは、Neuron を使用してAWS Inferentia および AWS Trainium ベースのインスタンスで効率的なトレーニングと推論を行い、パフォーマンスと拡張性を向上させています。 これらのモデルは SageMaker JumpStart UI および Python SDK を通して柔軟かつ簡便にデプロイすることができます。Neuron SDK は、一般的なMLフレームワークのサポートと高性能な機能を備えており、これらの大規模なモデルを効率的に処理できるようにしています。 これらのモデルを特定のドメインに特化したデータでファインチューニングすることは、専門分野において関連性と精度を向上させるために重要です。このプロセスは、SageMaker Studio UI や Python SDK を使用して実行でき、特定のニーズに合わせてカスタマイズが可能であり、プロンプトの補完と応答の品質の向上につながります。 これらのモデルの事前学習済みバージョンは強力ですが、一般的または繰り返しの応答を提供する可能性があります。ファインチューニングはモデルを特定の文脈に合わせ、より正確で関連性があり、多様な応答をもたらします。このカスタマイズは特に、事前学習済みとファインチューニングしたモデルの応答を比較する際に顕著であり、後者は出力の品質と専門性において明らかな改善を示しています。結論として、SageMaker 上での Neuron Llama 2 モデルのデプロイとファインチューニングは、先進的な AI モデルの管理に対する堅牢なフレームワークを表し、特に特定のドメインやタスクに合わせて調整された場合には、性能と適用範囲で著しい改善を提供しています。 サンプル ノートブック を参照してぜひ始めてみましょう。 GPU ベースのインスタンスで事前学習済み Llama 2 モデルをデプロイおよびファインチューニングする詳細については、 Fine-tune Llama 2 for text generation on Amazon SageMaker JumpStart および Llama 2 foundation models from Meta are now available in Amazon SageMaker JumpStart を参照してください。

パブリッシャーや放送局は、TikTok などのプラットフォームのショートフォームコンテンツが大好きな若い視聴者の注目を集める手法として、ショート動画が効果的であると認識しています。従来の M&E 業界の企業が、オリジナルコンテンツからショート動画を効率的に生成し、Facebook、Instagram、Snap、TikTok などのさまざまなソーシャルメディアプラットフォームで配信できるようになれば、より多くの視聴者を自社のサービスに引き寄せることができる可能性があります。 複雑なコンテンツの理解、一貫性の維持、多種多様な動画、大量の動画を扱うためのスケーラビリティの欠如などの課題があるため、要約動画の作成は手作業による時間のかかるプロセスです。人工知能（AI）と機械学習（ML）を活用した自動化を導入することで、自動コンテンツ分析、リアルタイム処理、文脈適応、カスタマイズ、および AI/ML システムの継続的な改善が実現し、動画要約プロセスをより実行可能でスケーラブルなものにすることができます。この結果、より多くの視聴者をひきつけられるようになることに加え、コンテンツ制作サプライチェーンの効率が向上し、最終的には収益の増加につながるというビジネスへの影響が期待できます。 本ブログ記事では、このビジネス上の問題を解決するためのエンドツーエンドのワークロードを構築する方法をご紹介します。ユーザーは AWS の AI/ML サービスである Amazon Transcribe 、 Amazon SageMaker JumpStart 、 Amazon Polly を活用することで、動画をアップロード、処理し、音声ナレーション付きのショート動画に要約することができます。 Amazon Transcribe は、ML を使用して動画の音声をテキストや字幕に自動的に変換するフルマネージドサービスであり、ドメイン固有の語彙を理解するカスタムモデルもサポートしています。 Amazon SageMaker JumpStart は、ワンクリックでデプロイできる ML のハブとして、 Hugging Face 、 AI21 、 Stability AI などのオープンソースの基盤モデル、組み込みアルゴリズム、事前構築済みの ML ソリューションを提供し、テキストの要約などさまざまなタイプのタスクを実行できます。これらのモデルは、SageMaker の API を介して安全かつ簡単にデプロイできるようにパッケージ化されています。 Amazon Polly は、深層学習技術を使用してテキストを人間の声のような音声に変換するサービスです。本ソリューションでは、Amazon Polly を使用して要約動画のナレーション音声を作成します。 ソリューションの概要 動画要約ワークロードのエンドツーエンドソリューションは、1）ユーザーエクスペリエンス、2）リクエスト管理、3）AWS の AI/ML サービスを利用した AWS Step Functions のワークフローオーケストレーション、4）メディアとメタデータのストレージ、5）イベント駆動型サービスとモニタリングの5つの主要コンポーネントで構成されています。 こちらは、動画要約ワークロードのパイプラインの図です。 ユーザーエクスペリエンス ：このアーキテクチャには、 Amazon Simple Storage Service (Amazon S3) でホストされるシンプルな静的ウェブアプリケーションが含まれています。ここでは、Amazon S3 でホストされている静的ウェブサイトを提供するために、 Amazon CloudFront ディストリビューションをデプロイし、オリジンアクセスコントロール（OAC）を使用して S3 オリジンへのアクセスを制限します。 Amazon Cognito を使用すると、認証されていないユーザーからウェブアプリケーションを保護できます。 リクエスト管理 ： Amazon API Gateway は、ワークフローの生成、読み取り、更新、削除（CRUD）、または実行のリクエストが開始される動画要約ワークロードのフロントエンドとバックエンド間のすべてのリアルタイム通信のエントリポイントとして使用されます。API リクエストは、動画要約タスクを Amazon Simple Queue Service (Amazon SQS) キューに入れて、前処理されたリクエストを AWS Step Functions に送信する前にワークロードの信頼性とスケーリングをサポートする AWS Lambda 関数を呼び出します。 AWS の AI/ML サービスを利用した AWS Step Functions のワークフローオーケストレーション ：要約動画の作成プロセスは、 Amazon Transcribe を使用して自動音声認識を行い、動画の音声を出力される字幕ファイルのタイムスタンプなどの関連するメタデータ情報を含むテキストに変換することから始まります。次に、 Amazon SageMaker JumpStart の事前トレーニング済みの基盤モデルを活用して、元の動画のストーリー（プロット）を保持しつつ、テキストを短く要約します。続いて、SageMaker JumpStart にデプロイしたテキストエンベディングモデルを使用して、要約されたコンテンツ内の各文を元の字幕ファイル内の対応する文に自動的に組み合わせます。このプロセスによって、最も関連性の高い動画のセグメントを正確に選択し、そのタイムスタンプを決定することができます。音声ナレーションの作成には Amazon Polly を、最終的な動画出力には AWS Elemental MediaConvert を使用します。 メディアとメタデータのストレージ ：このソリューションでは、アップロードされた動画と出力された動画を Amazon S3 に保存します。Amazon S3 は、耐久性、可用性、およびスケーラビリティに優れたデータストレージサービスを低コストで提供しています。メディア、プロファイリング、タスクのメタデータはすべてすべてNoSQL データベースサービスである Amazon DynamoDB に保存されます。これにより、タスクのステータスやその他の関連情報の追跡などが可能になります。 イベント駆動型サービスとモニタリング ： Amazon CloudWatch と Amazon EventBridge を活用して、すべてのコンポーネントをリアルタイムでモニタリングし、Step Functions のワークフローで対応するアクションを実行します。 ウォークスルー このブログ記事では、AWS の AI/ML サービスを利用して要約されたコンテンツの生成と最も関連性の高いビデオフレームシーケンスの選択を行う、Step Functions のワークフローを重点的にご紹介します。 まずは、 Amazon Transcribe StartTranscriptionJob API を使って Amazon S3 に保存されている元の動画を文字に起こします。API のリクエストパラメータを追加すると、フルテキストとその他のメタデータの両方を JSON および SRT（字幕）形式で取得することができます。 以下は、ワークロードの Amazon Transcribe による JSON 形式の出力例です。 { "jobName": "203b2cad-ed24-4670-8ba6-b9c836d7c48b", "accountId": "6393590*****", "results": { "transcripts": [{ "transcript": "AWS is the world's most comprehensive and broadly adopted cloud platform..."}], "items": [{ "start_time": "2.369","end_time": "2.95", "alternatives": [{ "confidence": "0.902","content": "AWS"}], "type": "pronunciation" }, ... ] }, "status": "COMPLETED" } 以下は、Amazon Transcribe による SRT（字幕）形式の別の出力例です。 0 00:00:02,369 --> 00:00:06,780 AWS is the world's most comprehensive and broadly adopted cloud platform. 1 00:00:07,519 --> 00:00:12,369 Millions of customers trust AWS to power their infrastructure and applications. 2 00:00:13,699 --> 00:00:17,920 Organizations of every type and size are using AWS to lower costs 3 00:00:18,309 --> 00:00:21,129 become more agile and innovate faster. ワークフローの次のステップでは、事前トレーニング済みの 大規模言語モデル（LLM） を Amazon SageMaker JumpStart にデプロイします。大規模言語モデル（LLM）は、数億から 1 兆を超えるパラメータを持つニューラルネットワークベースの言語モデルです。LLM の生成機能は、テキスト生成、要約、翻訳、感情分析、会話型チャットボットなどさまざまなタスクに利用されています。このワークロードでは、事前トレーニング・微調整済みの Llama 2 生成モデルを使って原文を要約します。テキストの要約には、 Hugging Face Distilbart-CN-12-6、Hugging Face BART Large CNN などの他の LLM も使用できます。これらの LLM は、ワンクリックで簡単に Amazon SageMaker JumpStart にデプロイできます。 以下の Python コードに示されているように、Amazon SageMaker に Llama 2 をデプロイした後は、 InvokeEndpoint API を簡単に呼び出して、SageMaker のエンドポイントでホストされているLlama 2 モデルから簡単に推論を取得できます。 sagemaker = boto3.client(service_name='sagemaker-runtime') endpoint_name = os.environ["sagemaker_endpoint"] payload = { "inputs": [[{"role": "system", "content": "Provide a concise summary of the input. Do not include any additional information or context."},{"role": "user", "content": original_text}]], "parameters": {"max_new_tokens": 1024, "top_p": 0.9, "temperature": 0.25} } response = sagemaker.invoke_endpoint(EndpointName=endpoint_name, ContentType='application/json', Body=json.dumps(payload), CustomAttributes="accept_eula=true") result = json.loads(response['Body'].read().decode()) ペイロードに定義されているさまざまなパラメータを使用してエンドポイントを呼び出し、テキストの要約に影響を与えることができます。重要なパラメータは top_p と temperature の 2 つです。 top_p はモデルによって考慮されるトークンの範囲をトークンの累積確率に基づいて制御するのに使用され、 temperature は出力の多様性を制御します。すべてのユースケースに適応できる top_p と temperature の組み合わせはありませんが、前の例では、 top_p の値が高く、 temperature の値が低いサンプル値を示しています。このような値にすると、クリエイティブなバリエーションをある程度取り入れた興味深い出力でありながら、原文から逸脱することなく、重要な情報を汲み取った要約につながります。 次のステップでは、初めに Amazon Polly を使って、要約されたテキストを音声に変換します。Polly は、MP3 ファイルと 音声合成マークアップ言語（SSML ）でマークアップされたドキュメントの2つの形式で合成音声を提供します。この SSML ファイルには、特定の Polly の音声が個々の文を読み上げるのにかかる時間を記述した重要なメタデータがカプセル化されています。動画セグメントの長さは、この音声の再生時間の情報を使用して定義できます。今回の例では、1 対 1 の直接対応を使用しています。 {"time":3092,"type":"sentence","start":27,"end":165,"value":"AWS (Amazon Web Services) is the world's most comprehensive and broadly adopted cloud platform, trusted by millions of customers globally."} {"time":11822,"type":"sentence","start":166,"end":310,"value":"AWS provides on-demand delivery of technology services via the internet, with pay-as-you-go pricing and no upfront costs or ongoing commitments."} ... Step Functions のワークフローの最後のステップでは、要約されたコンテンツのすべての文と一致する、最も関連性の高い動画フレームシーケンスを選択する必要があります。そこで、 テキストエンベディング を用いて、2 つの文がどの程度類似しているかを判定する 文の類似度 の算出タスクを実行します。文の類似度モデルは、入力されたテキストを意味的な情報を含むベクトル（エンベディング）に変換し、それらの間の近接度または類似度を計算します。 Amazon SageMaker では、 BlazingText などのテキストエンベディングを生成するための組み込みアルゴリズムや、テキスト文字列を入力として受け取り、384 次元のエンベディングベクトルを生成する Hugging Face all-minILM-L6-v2 などのオープンソースのトランスフォーマーベースのモデルを使用することができます。このワークロードでは、事前トレーニング済みの all-MiniLM-L6-v2 モデルを Amazon SageMaker にデプロイしています。 次のコードは、Amazon SageMaker のエンドポイントを使用してテキストエンベディングを行う一例です。 response = sagemaker.invoke_endpoint(EndpointName=endpoint_name, ContentType='application/x-text', Body=json.dumps(original_sentences).encode('utf-8')) result = json.loads(response['Body'].read()) original_embedding = np.array(result['embedding']) response = sagemaker.invoke_endpoint(EndpointName=endpoint_name, ContentType='application/x-text', Body=json.dumps(summarized_sentences).encode('utf-8')) result = json.loads(response['Body'].read()) summarized_embedding = np.array(result['embedding']) similarity_matrix = cosine_similarity(summarized_embedding, original_embedding) このコードは、以下の similarity_matrix マトリックスを返します。 [… [0.87043057 0.7364477 0.68395391 0.73774264 0.25494342 0.16451413 0.74744067] [0.73210674 0.6532341 0.77794674 0.84328448 0.41453468 0.22100691 0.79868826] …] ここでは コサイン類似度 を用いて 2 つのベクトル間の類似度を測定します。たとえば、前述の結果は次のように解釈できます。マトリックスの 1 行目は要約されたコンテンツの最初の文に対応し、すべての列に原文内の文との類似度スコアが表示されています。類似度の値は通常、-1 から 1 の間の範囲内であり、1 はベクトルが同一または非常に類似している、0 はベクトルが直交している（無相関）および類似性がない、-1 はベクトルが正反対または非常に異なることを示します。 類似度マトリックスから、要約されたコンテンツ内の各文の類似度スコアについて上位 k 件のスコアを特定し、原文内の最も類似している文と対応させます。原文の各文には対応するタイムスタンプ（ startTime 、 endTime など）があり、これらは元の SRT 形式の字幕ファイルに格納されています。次のステップでは、これらのタイムスタンプを利用して元の動画を複数のクリップに分割します。要約された各文の Polly の音声の長さと、元の字幕ファイルのタイムスタンプの両方を取り込むことで、要約された各文に対応する最も関連性の高いフレームのタイムスタンプシーケンスを選択することができます。一つの要約文について選択された各動画セグメントの長さはナレーション音声の長さに合わせて調整されます。タイムスタンプの出力の例は次のとおりです。 # startTime, endTime 00:00:00:00,00:00:02:36 00:00:02:36,00:00:12:71 00:00:13:29,00:00:27:07 00:01:15:24,00:01:26:26 00:02:00:97,00:02:12:55 00:02:50:03,00:02:59:02 00:02:59:02,00:03:06:27 次に、タイムスタンプのシーケンスをパラメータとして用いて、基本的な入力ファイルのクリッピングを実行する AWS Elemental MediaConvert の アセンブリワークフロー を作成します。Amazon Polly が生成した MP3 の音声データと組み合わせたり、好みの BGM を取り入れたりすることで、最終的な要約動画の出力を実現することができます。 以下の画像は、シンプルで使いやすい動画要約 Web アプリケーションのユーザーインターフェイスです。フロントエンドは、クラウド用のオープンソースのデザインシステムである Cloudscape 上に構築されています。 結論 今回のブログ記事では、ユーザーが動画の取り込み・処理・要約を行い、音声ナレーション付きのショート動画を生成することができる、AI によるメディアサプライチェーン向けの動画要約ワークロードをご紹介しました。また、ユーザーが Amazon Cognito のユーザープールを使用してログインする必要があるフロントエンドから、さまざまな AWS の AI/ML サービスを使用したバックエンドの AWS Step Functions のロジックまで、エンドツーエンドのソリューションを構築し、最終的には AWS Elemental MediaConvert を使用して要約されたビデオ出力を生成する方法について説明しました。この動画要約ワークロードは、音声付きの動画に対応しており、本ブログ記事は、動画に音声や台詞が含まれていない場合については対象外としておりますのでご注意ください。 このソリューションは、Amazon S3、Amazon CloudFront、Amazon API Gateway、AWS Lambda、Amazon Cognito、AWS Step Functions、および Amazon Transcribe、Amazon SageMaker、Amazon Polly などの AWS の AI/ML サービスを使用しています。 AWS のサービスについて詳しくは、こちらの リンク を参照してください。 参考リンク AWS Media Services AWS Media & Entertainment Blog　(日本語) AWS Media & Entertainment Blog　(英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 翻訳は BD 山口、SA 金目が担当しました。原文は こちら をご覧ください。

Amazon OpenSearch Service は、ワークロード固有の要件を満たすための複数のドメイン 設定 を提供しています。標準的なサービス運用の一環として、これらの設定を定期的に更新する必要がある場合があります。最近、Amazon OpenSearch Service は設定変更をより効果的に追跡できるようにする 視認性の改善 を行いました。詳細でより説明的な設定ステータスを導入することで、アラームの設定と自動化の利用を可能にし、手動での監視を最小限に抑えることが可能になりました。 こうした視認性の改善を、アプリケーションでご活用いただくことをお勧めします。 新機能は後方互換性があります。既存の自動化された処理が従来の processing パラメータに依存して構成変更のステータスを判断している場合は、影響なく動作し続けるはずです。 複数の未処理の構成変更リクエストを簡単に追跡できるように、Amazon OpenSearch Service は ドメイン処理ステータス がアクティブであるときにのみ構成リクエストを許可します。 詳細は「構成変更は一度に 1 つだけ」のセクションを参照してください。 ソリューションの概要 従来、設定変更のステータスは OpenSearch Service API (Application Programming Interface) の processing パラメータや、OpenSearch Service コンソールのドメインステータスフィールドを通じて確認できました。Amazon OpenSearch Service では設定更新のエクスペリエンスを改善するために、次の変更を導入しました。 API レスポンスに、 DomainProcessingStatus と ConfigChangeStatus の 2 つの新しいパラメータを導入しました。 同様に、コンソールに ドメイン処理ステータス と 設定変更ステータス フィールドを追加しました。 これらの変更により、直観的な複数のステータスから高い可視性が得られるようになりました。従来のステータスは、 Active と Processing の 2 つの値に限定されていました。 現在のアクティブな設定と、変更適用中の設定を簡単に比較できるようになりました。 以前は、複数のステップが必要でした。 今回、Amazon OpenSearch Service は、一度に 1 つの構成変更リクエストのみを許可するアプローチを採用しました。 単一のリクエストにまとめられるドメイン設定変更の項目数に制限はありません。 ただし、次の設定リクエストを送信できるのは、以前のリクエストが完了し、ドメインの処理ステータスがアクティブになった後です。 この改善により、設定の更新が合理化され、以前のような、実行中の複数の設定変更リクエストを追跡する課題が解消されました。 検証に失敗した場合、変更リクエストをキャンセルできるようになりました。 以前は、インスタンスが使用できない場合、ドメインは processing 状態のままでした。 現在は、 検証に失敗 すると、変更リクエストをキャンセルしてから時間を置いて再試行が可能です。 シャードの移動を含むすべてのバックグラウンドアクティビティが完了した後にのみ、ドメインの処理ステータスが Active になります。 これは、データ移動などのすべての内部プロセスが完了したかどうかを推測する必要がなく、自動化スクリプトで新しく導入されたステータスを自身をもって使用できることを意味します。 設定更新ステータスを追跡するための、詳細情報の取得方法 最近の改善の一環として、Amazon OpenSearch Service は API に DomainProcessingStatus と ConfigChangeStatus パラメータを、コンソールにそれぞれ対応する ドメイン処理ステータス フィールドと 設定変更ステータス フィールドを導入しました。これらのステータスを利用することで、設定変更において Blue/Green デプロイを伴う場合、または Blue/Green デプロイを伴わない場合、構成変更がオペレーターによってトリガーされる場合や、OpenSearch サービスによってトリガーされる場合など、さまざまな構成変更シナリオで正確で一貫した情報を取得できます。これらの強化された視認性のエクスペリエンスを見ていきましょう。 ドメイン処理ステータスの視認性: ドメインレベルの構成変更のステータスは、コンソールの ドメイン処理ステータス フィールドで追跡できます。同様に、API レスポンスには DomainProcessingStatus パラメータが含まれます。値と簡単な説明は次の詳細で提供されています: アクティブ: 構成変更は進行中ではありません。新しい構成変更リクエストを送信できます。 作成中: 新しいドメインの作成が進行中です。 変更中: このステータスは、新しいデータノードの追加、Amazon Elastic Block Store ( Amazon EBS ) GP3 ストレージのプロビジョニング、KMS キーの設定など、1つ以上の構成変更が進行中であることを示しています。したがって、 UpdateDomainConfig API を介して変更が行われた場合、ステータスは「変更中」にセットされます。「変更中」ステータスには、構成変更を完了するためにシャードの移動が必要なドメインも含まれます。注意: 後方互換性のために、API レスポンスでは processing パラメータの動作を変更していません。 processing パラメータは、シャード移動の完了を待たず、コアとなる設定変更が完了した時点で false にセットされます。 エンジンバージョンのアップグレード中: Elasticsearch バージョン 7.9 から OpenSearch バージョン 1.0 へのアップグレードなど、エンジンバージョンアップグレードが進行中です。 サービスソフトウェアの更新中: このステータスは、サービスソフトウェア更新に関連する構成変更を指します。 削除中: ドメインの削除が進行中です。 隔離: このステータスは、アカウント関連の課金問題や重要なセキュリティパッチ更新に準拠していないなどの、さまざまな理由で中断されているドメインを表しています。 設定変更ステータスの視認性: 設定変更は、ユーザーによって開始されることがあります(新しいデータノードの追加、インスタンスタイプの変更など)。または、サービスによって開始されることがあります(AutoTune や必須のサービスソフトウェア更新など)。最新のステータスの詳細は、コンソールの 構成変更ステータス フィールドと、API レスポンスの ConfigChangeStatus パラメータを通じて確認できます。以下は、値と簡単な説明です。 保留中: 構成変更リクエストが送信されたことを示しています。 初期化中: サービスが構成変更リクエストを初期化しています。 検証中: サービスがリクエストされた変更と必要なリソースを検証しています。 検証に失敗しました: リクエストされた変更が検証に失敗しました。この時点では、構成変更は適用されていません。起こりうる検証失敗の例としては、ドメイン内の red インデックスの存在、選択したインスタンスタイプが使用できない、ディスク容量の不足などがあります。 こちら に潜在的な検証失敗のリストがあります。検証失敗イベント中は、構成変更をキャンセル、再試行、編集できます。 ユーザー入力待ち: ユーザーが無効な KMS キーなどの検証エラーを修正できるシナリオです。このステータスでは、ユーザーは構成変更を編集できます。 変更の適用中: サービスがリクエストされた構成変更を適用しています。 キャンセル済み: 検証失敗ステータス中に、コンソールの キャンセル ボタンをクリックするか、 CancelDomainConfigChange API を呼び出すことができます。変更リクエストの一部であったすべての適用された変更がロールバックされます。 完了: リクエストされた構成変更が正常に完了しました。 コンソールの改善 Amazon OpenSearch Service コンソールでは、構成変更の進捗状況を追跡するための視認性が向上しました。以下のスクリーンショットで、改善点の概要を確認できます。 Amazon OpenSearch Service コンソールは、 ドメイン処理ステータス 、 設定変更ステータス 、 変更 ID フィールドを提供します。注意: 変更 ID に関連付けられた変更の詳細を知るには、 DescribeDomainChangeProgress API を使用できます。 設定変更の概要 。アクティブな設定と要求された変更の横並びの比較を見るには、ドメインの詳細ページでクラスター設定タブに移動し、設定変更の概要セクションまでスクロールダウンします。 保留中の変更 フィールドには、その時点での保留中のプロパティのステータスが表示され、適用された変更は含まれません。 DescribeDomain および DescribeDomainConfig API の ModifyingProperties パラメータを介して、同様の詳細も取得できます。 検証失敗時のキャンセル。 以下のスクリーンショットでは、構成変更リクエストの検証に失敗したときに変更リクエストをキャンセルする新しいオプションが確認できます。 たとえば、 SubnetNotFound エラーが発生した場合、 リクエストのキャンセル ボタンを使用して以前のアクティブな構成にロールバックし、問題を修正してから構成の更新を再試行できます。 構成変更は一度に 1 つだけ 以前は、複数の変更リクエストをしたときに、個々の変更リクエストの成功と失敗を追跡することは簡単ではありませんでした。 シンプルなエクスペリエンスを提供するために、現在の OpenSearch Service は、変更リクエストは一度に 1 つのみと制限を設けています。 1 つの構成変更リクエストに、複数の変更をまとめることができます。 コンソールもしくは UpdateDomainConfig API を介して次の構成変更をリクエストする前に、送信された構成変更リクエストが完了する必要があります。 この簡素化されたエクスペリエンスにより、リクエストされた変更とその最新のステータスを追跡することが容易になります。 自動化処理が設定変更 API を複数回呼び出すように記述されている場合は、単一の更新呼び出しに複数の構成変更をまとめるか、次の設定変更を送信する前に、個々の更新処理が完了するのを待つ必要があります。 ドメインの処理ステータスがアクティブになったときに、ドメイン設定の更新が可能です。 Blue/Green デプロイメントが必要な変更のリストについては、 こちら をご覧ください。 以下のスクリーンショットは、「クラスター設定の編集」ページの例で、ユーザーに対して、別の変更や更新が進行中であることを通知するアラートを示しています。OpenSearch Service では、新しい構成更新リクエストを送信できなくなり、進行中の変更が完了するまで「変更の適用」ボタンが無効になります。 API の変更 DescribeDomain 、 DescribeDomainChangeProgress 、 DescribeDomainConfig API を使用して、詳細な構成更新ステータスを取得できます。 さらに、検証失敗が発生した場合は、 CancelDomainConfigChange を使用して変更リクエストをキャンセルできます。 Amazon OpenSearch Service API ドキュメントは こちら からご参照ください。 まとめ 本投稿では、設定の更新リクエストに関する詳細な情報の取得方法について説明いたしました。 新規に導入された改善により、設定変更リクエストの進捗状況の可視性が向上し、適用された変更と保留中の変更を簡単に区別できるようになりました。 設定変更リクエストを送信する前に、 DomainProcessingStatus 処理ステータス値が Active であることを確認する必要があります。 検証の失敗が発生した場合に変更をキャンセルできる機能により、ドメインを処理状態から自助的に回復する制御が向上します。 詳細は、製品の ドキュメント をご覧ください。 著者について Siddhant Gupta は、インドのハイデラバードに拠点を置くAmazon Web Services のシニアテクニカルプロダクトマネージャーです。 Siddhant は Amazon で6年以上働いており、現在OpenSearch Service チームと協力して新しいリージョンのローンチ、価格戦略、EC2 と EBS のイノベーションを OpenSearch Service のお客様に提供しています。彼はアナリティクスと機械学習に情熱を注いでいます。余暇では、旅行、フィットネス、家族との時間、ノンフィクション本の読書を楽しんでいます。 Deniz Ercelebi は、Amazon OpenSearch Service の Sr. UX デザイナーです。 彼女の役割は、複雑な問題のデザインソリューションの作成、実装、および成功した提供に貢献することです。 個人的な動機は、ユーザーエクスペリエンスへの情熱、顧客中心のソリューションへの献身、そして協調的イノベーションへの確固たる信念によって推進されています。 Shashank Gupta は、Amazon OpenSearch Service の Sr. ソフトウェア開発者で、プラットフォームのマネージドサービスの側面の強化を専門としています。 主な焦点は、コンソールから API やリソースプロビジョニングに至るまで、マネージドエクスペリエンスを効率的な方法で最適化することです。 イノベーションへの献身的なコミットメントがあり、サービス内で革新的なソリューションを導入することによって、全体的な顧客体験を高めることを目指しています。 翻訳はソリューションアーキテクトの榎本が担当いたしました。原文の投稿は Track Amazon OpenSearch Service configuration changes more easily with new visibility improvements  よりご確認ください。

このブログでは、さまざまな 生成 AI を活用したビジネスユースケースをデモンストレーションしている Generative AI Use Cases JP をカスタマイズする方法についてご紹介します。Amazon Bedrock、Amazon Kendra などを利用して、Generative AI Use Cases JP はさまざまなビジネスユースケースを公開しています。 その Generative AI Use Cases JP の Web UI を利用することで簡単に新しいユースケースを追加することが可能です。 このデモンストレーションでは、SQL を記述する工数を削減したいデータアナリストをターゲットに、Amazon Bedrock の 基盤モデル を用いてSQL を生成するユースケースを作成してみます。 今回作成するユースケースで用いる 基盤モデル は Claude v2 を利用します。 ユースケースを作成し始める前に、基盤モデル で SQL を生成可能かチャットで確認する ユースケースを作成する前に、そもそも 基盤モデル を利用して SQL 生成が可能かどうかをチェックします。 具体的には、チャットで意図した SQL が生成できるかを検証してみます。 ここでは、人間が記述するのが面倒な、長い Case 文を自然言語で簡単に出力できるか確認してみます。 SQL 生成のために 基盤モデル に入力すべき情報 有用な SQL を出力するために入力すべき必要な情報を整理してみます。 テーブル定義 基盤モデルは社内データベースのスキーマ情報を知りません。 基盤モデルにテーブル定義を渡すと各カラムの type や range、コメント などを参照して正確な SQL の出力を期待できます。 出力したい SQL を説明する自然言語 普段使用している自然言語で出力させたい SQL を説明します。 チャットに入力 チャットに入力すべき情報 1, 2 を Claude v2 に入力していきます。 まずは基盤モデルに役割とタスクを与えるため、システムコンテキストに以下を入力します。システムコンテキストとは、Claude に質問したりタスクを与える前に特定の目標や役割を指定するなど、Claude にコンテキストと指示を提供する方法です。詳細については Anthoropic 社の システムプロンプトの使用方法 を参照してください。 システムコンテキスト Claude2 に役割とタスクを与える 役割: ユーザーの指示をよく理解する熟練のデータベーススペシャリスト タスク: を守って、可読性の高い SQL だけを出力してください Claude2として利用する Claude が理解しやすい XML タグを用いて記述する。XML タグは自由に定義してよい。 RDB のスキーマ情報: <schemas></schemas> Claude v2 の出力例: <examples></examples> 以下はユーザーと AI のやりとりです。 ユーザーは AI に <schemas></schemas> の xml タグで囲って RDB のスキーマ情報を渡します。 さらに、<input></input> の xml タグで囲って AI に記述して欲しい SQL の説明を渡します。 AI は、ユーザーの指示をよく理解する熟練のデータベーススペシャリストなので、以下の <rules></rules> を守って、可読性の高い SQL だけを出力してください。 <rules> * <schemas> と <input> の情報を頼りに、ユーザーが求める SQL を ANSI SQL に準拠して出力してください。 * join する場合はテーブル名に別名をつけた上で、列名は必ず `別名.列名` と表記してください。 * GROUP BY や ORDER BY 句には、必ず `列名` あるいは `別名.列名`を使用することを遵守してください。列番号の使用は修正が難しくなるので禁止です。 </rules> 出力は <output>```sql {SQL} ```</output> の形式を遵守してください。 SQL のコード以外を出力してはいけません。解説なども出力してはいけません。 出力例を <examples></examples> で与えます。 <examples> <output>```sql SELECT * FROM v_schedule; ```</output> <output>```sql SELECT e.id AS employee_id, e.name AS employee_name, c.id AS company_id, c.name AS company_name FROM employees e JOIN companies c ON c.id = e.company_id ; ```</output> <output>```sql SELECT id, COUNT(price), SUM(price), MIN(price), MAX(price) FROM transaction t GROUP BY t.id ; ```</output> </examples> 上記の通り、ユーザーは <schemas> と <input> を与えれば Claude v2が SQL を出力してくれるはずです。ここでは Amazon Athena を前提とした DDL と、作成したい SQL の内容をチャットに入力します。 <schemas> CREATE TABLE users ( id SERIAL PRIMARY KEY, name VARCHAR(50) NOT NULL, gender VARCHAR(10) NOT NULL, age SMALLINT NOT NULL, CONSTRAINT users_pk PRIMARY KEY (id) ); COMMENT ON COLUMN users.id IS 'ユーザーID'; COMMENT ON COLUMN users.name IS 'フルネーム'; COMMENT ON COLUMN users.gender IS 'Male, Female, Other のいずれかが格納'; COMMENT ON COLUMN users.age IS '年齢'; CREATE TABLE user_logs ( request_id BIGSERIAL PRIMARY KEY, request_time TIMESTAMP NOT NULL, url TEXT NOT NULL, id SERIAL NOT NULL REFERENCES users(id) ); COMMENT ON COLUMN user_logs.request_id IS 'ログレコードのユニークID'; COMMENT ON COLUMN user_logs.request_time IS 'リクエストした時刻'; COMMENT ON COLUMN user_logs.url IS 'リクエストしたURL'; COMMENT ON COLUMN user_logs.user_id IS 'ユーザーID'; </schemas> <input> 年齢と性別で層分けした属性情報で、年月毎のリクエスト回数の合計を集計してください。 年齢は20歳未満、20-29、30-39、…、70-79, 80以上で分けてください。 性別は、Male, Female, Other で分けてください。 </input> チャット UI 上ではこのように表示されます。 このプロンプトを利用してSQL 生成ユースケースを作成します。 SQL 生成ユースケースの開発 ブランチを作成する アプリ開発をする上でバージョン管理は大切です。 SQL 生成のユースケースを作成するためにブランチを作成します。 以下のコマンドを使用してください。 以下のコマンドは feat/generate-sql ブランチを作成し、このブログ執筆時の最新のコミットを指定しています(Commit ID: 37b29d2 )。 ※注意) ブログ執筆時は上記コードが動きましたがメンテナンスされませんのでご注意ください。この成果物は後述の通り main ブランチを追従しない、かつ main ブランチにもマージされません。お試しや開発のヒントとしてお使いください。 git checkout -b feat/generate-sql git reset --soft `37b29d2` ローカル開発環境を立ち上げる フロントエンドの開発をするにあたり、開発環境を整えます。 Generative AI Use Cases JP をデプロイしていない場合、こちらの リンク を参考にしてまずはデプロイしてください。 今回は開発体験も考慮して、ローカル開発用サーバーを立て、ローカル環境でSQL生成ユースケースを確認できるようにします。 Unix 系コマンドが使えるPC であれば (Linux や MacOS 等)、以下のコマンドでローカル環境が立ち上げられます。 npm run web:devw http://localhost:5173 にアクセスすればローカルで開発したフロントエンドをすぐに確認することができます。 コマンドの設定については /package.json を参照してください。 メニューに追加 まずは、専用のユースケースのリンクを作成します。 packages/web/src/App.tsx でユースケースリンク一覧を作成しているので、追記することで SQL 生成のリンクを追加することができます。 カスタマイズ方法として、本ブログの Diff と書かれた内容の中で、行頭に + があればその行を追加し、行頭に - があればその行を削除して下さい。 packages/web/src/App.tsx …(前略)… PiX, + PiTerminal, } from 'react-icons/pi'; …(中略)… { label: '画像生成', to: '/image', icon: <PiImages />, display: 'usecase' as const, }, + { + label: 'SQL 生成', + to: '/generate-sql', + icon: <PiTerminal />, + display: 'usecase' as const, + }, { label: '音声認識', to: '/transcribe', icon: <PiSpeakerHighBold />, display: 'tool' as const, }, …(後略)… リンク先を用意する 作成したリンクは当然存在しないので 404 が表示されます。 まずはリンク先を用意しましょう。 packages/web/src/main.tsx でリンク先を設定します。 packages/web/src/main.tsx …前略… import GenerateImagePage from './pages/GenerateImagePage'; + import GenerateSqlPage from './pages/GenerateSqlPage'; import TranscribePage from './pages/TranscribePage'; …中略… path: '/image', element: <GenerateImagePage />, }, + { + path: '/generate-sql', + element: <GenerateSqlPage />, + }, { path: '/transcribe', element: <TranscribePage />, …後略… 以上で、 「 /generate-sql をクリックしたときは GenerateSqlPage.tsx を参照する」という設定が出来上がりました。 ただし、 GenerateSqlPage.tsx が無いため、画面側で以下のようなエラーが発生しているはずです。 [plugin:vite:import-analysis] Failed to resolve import "./pages/GenerateSqlPage" from "src/main.tsx". Does the file exist? …後略… ページを作成する ここから SQL 生成ユースケースのページを作成していきます。 SQL 生成の場合は、「テーブルを定義する DDL」を入力するフォームと、「そのテーブルからクエリを生成するための指示」を入力するフォームの二つが必要となります。すでに文書生成ユースケースで同様の UI が作成されているため、こちらのページの UI をそのまま利用して作成していきます。 以下コマンドで、文書生成のページを複製します。 # プロジェクトのルートディレクトリで実行 cp packages/web/src/pages/GenerateTextPage.tsx packages/web/src/pages/GenerateSqlPage.tsx 複製した、 packages/web/src/pages/GenerateSqlPage.tsx を編集していきます。 packages/web/src/pages/GenerateSqlPage.tsx …前略… import { create } from 'zustand'; + import { generateSqlPrompt } from '../prompts'; + import { GenerateSqlPageLocationState } from '../@types/navigate'; - import { generateTextPrompt } from '../prompts'; - import { GenerateTextPageLocationState } from '../@types/navigate'; import { SelectField } from '@aws-amplify/ui-react'; …中略… clear; () => void; }; + const useGenerateSqlPageState = create<StateType>((set) => { - const useGenerateTextPageState = create<StateType>((set) => { const INIT_STATE = { …中略… }; }); + const GenerateSqlPage: React.FC = () => { - const GenerateTextPage: React.FC = () => { const { modelId, …中略… setText, clear, + } = useGenerateSqlPageState(); - } = useGenerateTextPageState(); const { state, pathname } = + useLocation() as Location<GenerateSqlPageLocationState>; - useLocation() as Location<GenerateTextPageLocationState>; const { loading, messages, postChat, clear: clearChat } = useChat(pathname); const { setTypingTextInput, typingTextOutput } = useTyping(loading); …中略… useEffect(() => { if (state !== null) { + setInformation(state.schemas); + setContext(state.instruction); - setInformation(state.information); - setContext(state.context); } }, [state, setInformation, setContext]); …中略… } }, [modelId, availableModels, setModelId]); + const getGeneratedSql = ( - const getGeneratedText = ( modelId: string, + schemas: string, + instruction: string - information: string, - context: string ) => { postChat( + generateSqlPrompt.generatePrompt({ + schemas, + instruction, - generateTextPrompt.generatePrompt({ - information, - context, }), true, textModels.find((m) => m.modelId === modelId) …中略… const onClickExec = useCallback(() => { if (loading) return; + getGeneratedSql(modelId, information, context); - getGeneratedText(modelId, information, context); }, [modelId, information, context, loading]); …中略… <div className="grid grid-cols-12"> <div className="invisible col-span-12 my-0 flex h-0 items-center justify-center text-xl font-semibold print:visible print:my-5 print:h-min lg:visible lg:my-5 lg:h-min"> + SQL 生成 - 文章生成 </div> <div className="col-span-12 col-start-1 mx-2 lg:col-span-10 lg:col-start-2 xl:col-span-10 xl:col-start-2"> …中略… <Textarea + placeholder="SQL 生成に必要なテーブル情報 (create table DDL) を入力してください" - placeholder="入力してください" value={information} …中略… <Textarea + placeholder="生成する SQL の説明を入力してください。" - placeholder="文章の形式を指示してください。(マークダウン、ブログ、ビジネスメールなど)" value={context} …中略… + export default GenerateSqlPage; - export default GenerateTextPage; ここでは以下 2 点の修正を主にしています。 画面で表示されている文書生成用の説明文字列を SQL 生成用に修正しています。 内部で利用している変数名を文書生成から SQL 生成用に修正しています。この変更は、実際に運用していくにあたり可読性や保守性を上げると言う観点で修正しています。 ただし、変数名を変更することによって、他に変数を定義・利用している部分で TypeScript のエラーが以下のように発生しています。 [{ "resource": "generative-ai-use-cases-jp/packages/web/src/pages/GenerateSqlPage.tsx", "owner": "typescript", "code": "2305", "severity": 8, "message": "モジュール '\"../prompts\"' にエクスポートされたメンバー 'generateSqlPrompt' がありません。", "source": "ts", "startLineNumber": 11, "startColumn": 10, "endLineNumber": 11, "endColumn": 27 },{ "resource": "generative-ai-use-cases-jp/packages/web/src/pages/GenerateSqlPage.tsx", "owner": "typescript", "code": "2724", "severity": 8, "message": "'GenerateSqlPageLocationState' という名前のエクスポートされたメンバーが '\"../@types/navigate\"' に含まれていません。候補: 'GenerateTextPageLocationState'", "source": "ts", "startLineNumber": 12, "startColumn": 10, "endLineNumber": 12, "endColumn": 38 }] 変数定義の修正 packages/web/src/pages/GenerateSqlPage.tsx で使用している、 schemas 変数と instruction 変数の定義を行います。 これは、より型安全にするために ReactRouter の useLocation に型定義を行っています。 packages/web/src/@types/navigate.d.ts context: string; }; + export type GenerateSqlPageLocationState = { + schemas: string; + instruction: string; + }; export type RagPageLocationState = { content: string; システムコンテキストとユーザープロンプトの埋め込み 最後に用意したプロンプトを SQL 生成ユースケースのページにも適用させます。 prompt は、 packages/web/src/prompts/index.ts で制御しています。 このファイルは各ページのコンテキストを定義しています。このファイルに先ほど作成したシステムコンテキストを定義し、ユーザの入力を受け取り、Claude v2 に入力するためのプロンプトを作成するための処理を追加します。 packages/web/src/prompts/index.ts …前略… '/generate': 'あなたは指示に従って文章を作成するライターです。', + '/generate-sql': `以下はユーザーと AI のやりとりです。 + ユーザーは AI に <schemas></schemas> の xml タグで囲って RDB のスキーマ情報を渡します。 + さらに、<input></input> の xml タグで囲って AI に記述して欲しい SQL の説明を渡します。 + AI は、ユーザーの指示をよく理解する熟練のデータベーススペシャリストなので、以下の <rules></rules> を守って、SQL だけを出力してください。 + <rules> + * <schemas> と <input> の情報を頼りに、ユーザーが求める SQL を ANSI SQL に準拠して出力してください。 + * join する場合はテーブル名に別名をつけた上で、列名は必ず \`別名.列名\` と表記してください。 + * GROUP BY や ORDER BY 句には、必ず \`列名\` あるいは \`別名.列名\`を使用することを遵守してください。列番号の使用は修正が難しくなるので禁止です。 + </rules> + 出力は + <output>```sql + {SQL} + ```</output> + の形式を遵守してください。 + SQL のコード以外を出力してはいけません。解説なども出力してはいけません。 + 出力例を <examples></examples> で与えます。 + + <examples> + <output>```sql + SELECT * FROM v_schedule; + ```</output> + <output>```sql + SELECT + e.id AS employee_id, + e.name AS employee_name, + c.id AS company_id, + c.name AS company_name + FROM + employees e + JOIN + companies c ON c.id = e.company_id + ; + ```</output> + <output>```sql + SELECT + id, + COUNT(price), + SUM(price), + MIN(price), + MAX(price) + FROM + transaction + GROUP BY + id + ; + ```</output> + </examples> + `, '/translate': 'あなたは文章の意図を汲み取り適切な翻訳を行う翻訳者です。', …中略… + export type GenerateSqlParams = { + schemas: string; + instruction: string; + }; + export const generateSqlPrompt = { + generatePrompt: (params: GenerateSqlParams) => { + return `<schemas> + ${params.schemas} + </schemas> + <input> + ${params.instruction} + </input>`; + }, + }; <EOF> このコードで行っていることは以下の 2 つです。 先程作成した prompt を変数に格納 入力されたテキストを受け取って、 <schemas> や <input> タグに埋め込む 動作確認 最後に、動作確認をします。 本ブログ上部で入力した DDL ( <schemas> タグの内側のテキスト )と、定義した テーブルで生成したい SQL ( <input> タグの内側のテキスト) を入力します。 実行ボタンをクリックすると、次のような SQL が生成されます。 このように既存の API を利用して簡単に ユースケース を追加することができました。 API をいじるようなケースはまた別途開発が必要ですが、既存の UI を流用して ユースケースを追加するだけであればこのように簡単に作成することができます。 まとめ 本記事では、Generative AI Use Cases JP の既存の UI 、API を利用して、ユースケースを追加する方法についてご紹介しました。文書生成ページを流用して、SQL 生成ページを作成しました。ページ追加の方法や、システムコンテキストの変更方法などを併せて紹介しました。SQL 生成ユースケースとして、実際にはテーブル定義を毎回書くのは大変です。そのため、例えば前回書いたテーブル定義をlocalStorage 等に保存できるようにし、次回利用時には自動で入力された状態の方が便利かもしれません。さらに発展し、DB やテーブル一覧を API で取得しテーブル定義を自動でインポートできるようになると、利便性が格段に向上します。このように、今回の SQL 生成ユースケース一つをとっても、まだまだ拡張の余地があります。 今回のカスタマイズの方法をもとにして、独自のユースケースを作成してみましょう。 この記事のコードサンプルについては、 GitHub リポジトリをご覧ください。 著者プロフィール 呉 和仁 (Go Kazuhito) は AWS Japan の機械学習ソリューションアーキテクト。 IoT の DWH 開発、データサイエンティスト兼業務コンサルタントを経て現職。プログラマの三大美徳である怠惰だけを極めてしまい、モデル構築を怠けられる AWS の AI サービスをこよなく愛す。     鈴木 大樹 (Daiki Suzuki) はAWS Japan のソリューションアーキテクト。データベース領域を得意としており、機械学習領域と絡めたソリューションの作成を行なっています。

AWS Config は、AWS アカウント内のリソースの構成と関係性を評価、監査、検証します。このサービスをコスト最適化に使用したい理由は何でしょうか。たとえば、特定の Amazon Relational Database Service ( Amazon RDS ) インスタンスがアカウントにデプロイされた場合にアラートを受信できるシナリオを考えてみましょう。必要以上に大きいインスタンスタイプが使用されている場合、予期しないコストが発生する可能性があります。 このブログ記事では、AWS Config でカスタムルールを実装する方法を示します。カスタムルールによりデータベースのインスタンスを監視することで、コストの最適化を図ります。複数のアカウントを使用するシナリオでは、お客様は高コストなデータベースインスタンスの使用を制限し、違反が発生した場合に通知を受け取りたいと考えることがあります。たとえば、テストアカウントでは必ずしもアプリケーション構築にプロダクションサイズのインスタンスを利用する必要はありません。AWS Config カスタムルールは、実行中のデータベースインスタンスのタイプをチェックします。そして、意図しないデータベースインスタンスタイプの場合、AWS Config が非準拠として検出します。 ソリューションの概要 次の図は、ソリューションアーキテクチャを示しています 図 1: ソリューションの概要 図 1 の左上にある AWS Config のカスタムルールは、Amazon RDS データベースインスタンスのプロビジョニングが事前定義したコスト管理の基準に違反していないかを検出する AWS Lambda 関数を呼び出します。 この関数の呼び出しは、アカウント内で新しい Amazon RDS データベースインスタンスが検出されるたびに発生します。 AWS Lambda 関数は、インスタンスタイプが承認されたインスタンスタイプに準拠していることを確認します。 リソースが準拠と評価された場合は、何も起こりません。 リソースが非準拠と評価された場合、AWS Lambda 関数は Amazon Simple Notification Service ( Amazon SNS ) トピックを介して管理チームにアラートを送信し、アカウント管理者が修正措置を取ることができるようにします。 手順の説明 このチュートリアルでは、上記のソリューション図で提示されている全体的な手順をデモするために、次のステップで説明します。 注意 : ここで提供されるすべてのコードは、本番環境以外の環境で検証ならびに評価してください。 AWS CloudFormation テンプレートを使用して必要なリソースを作成する Amazon SNS トピックのサブスクリプションを確認する AWS Config カスタムルールが機能していることを確認するために Amazon RDS インスタンスを作成する このチュートリアルの前提条件は次のとおりです。 AWS アカウントに管理者権限でログインできること。 このチュートリアルで使用するリージョンで、AWS Config サービスの設定が完了していること。完了していない場合は、 AWS Config の ワンクリックセットアップ のドキュメントに従ってください。 図 2: AWS Config の設定 ステップ 1: AWS CloudFormation テンプレートを使用したリソースの作成 この AWS CloudFormation テンプレート をダウンロードして起動すると、AWS Lambda 関数、AWS Config カスタムルール、Amazon SNS トピックなどの関連リソースがデプロイされます。 注意 : デプロイされたリソースはコストが発生します。以下の「クリーンアップ」セクションの説明に従ってリソースをクリーンアップするように覚えておいてください。 AWS CloudFormation テンプレートを使用してリソースを作成するには、次のステップを完了します: AWS マネジメントコンソールにサインインします 「 AWS CloudFormation コンソール 」>「 スタックの作成 」>「 新しいリソースを使用 (標準) 」の順に移動します YAML テンプレートファイルをアップロードし、 次へ を選択します 「 スタック名 」を指定し、「 NotificationEmail 」パラメータにメールアドレスを入力した後、 次へ を選択します 「スタックオプションの設定」はデフォルト値のままにして、 次へ を選択します 「レビュー」で設定の詳細を確認し、「 機能 」の「AWS CloudFormation によって IAM リソースが作成される場合があることを承認します。」のボックスにチェックを入れます 送信 を選択します   図 3: スタック作成の確認 注意 : スタックの作成が送信された後、 AWS CloudFormation > スタック > スタック名 > イベント タブの下でその進捗状況を確認できます。 スタックが正常に作成されると、AWS アカウントにいくつかのリソースがデプロイされていることがわかります。具体的には、 AWS Config ルール 、 AWS Lambda 関数 、 Amazon SNS トピック 、および対応する AWS Identity and Access Management (IAM) ロール です。 ステップ 2: Amazon SNS トピックのサブスクリプションの確認 ステップ 1 の完了後、ステップ 1 で設定したメールアドレスに、「AWS Notification – Subscription Confirmation」というタイトルのメールが「sns.amazonaws.com」から届きます。メールの内容は、下図のようになります。 図 4: サブスクリプション確認メール このメールアドレスで登録された Amazon SNS トピックのサブスクリプションを確認するには、メール内の「Confirm Subscription」リンクをクリックしてください。 注意 : サブスクリプションのステータスは、以下のように Amazon SNS > トピック > aws-config-demo-topic > サブスクリプション タブで確認できます。 図 5: サブスクリプションの確認 ステップ 3: Amazon RDS インスタンスの作成 このステップでは、MySQL の Amazon RDS インスタンスを作成します。これにより、AWS Config のルールがトリガーされ、アカウント管理者にアラートが必要かどうかを判断するために、インスタンスのサイズをチェックします。この例では、作成されるインスタンスのサイズは「 db.r6g.large 」です。 この Amazon RDS インスタンスを作成するには、次のステップを完了します: AWS マネジメントコンソールにサインインします 「 Amazon RDS コンソール 」>「 データベース 」>「 データベースの作成 」の順に移動します 「 簡単に作成 」オプションを選択し、エンジンのタイプとして「 MySQL 」を選択します 図 6: Amazon RDS エンジンのタイプ DB インスタンスのサイズとして「開発 / テスト」を選択し、「パスワードの自動生成」オプションにチェックを入れます。チュートリアル後、今回作成した Amazon RDS インスタンスは削除するので、パスワードを保持する必要はありません。 図 7: Amazon RDS インスタンスサイズ 他のオプションはデフォルト値のままにして、「データベースの作成」を選択します。デフォルトでは、このデータベースはデフォルトの VPC、またはデフォルトの VPC が存在しない場合は新しい VPC 内に作成されます。このセットアップがシナリオに適合しない場合は、「標準作成」を選択して設定を変更できます。 図 8: データベースの作成 この Amazon RDS インスタンスが作成された後、数分以内にメールボックスに通知メールが届くはずです。 AWS Config のカスタムルールによって呼び出される AWS Lambda 関数は、Amazon RDS インスタンスが「 db.t3.micro 」のサイズで作成されているかどうかをチェックしています。したがって、この Amazon RDS インスタンスは AWS Config で非準拠と評価され、アラートメールが送信されます。以下は、RDS インスタンスリソースを評価するために AWS Lambda 関数で使用されるコードスニペットです。 def is_compliant(configurationItem):    logger.info(f"Resource to be evaluated->{configurationItem}") if configurationItem['configuration']['dBInstanceClass'] == 'db.t3.micro':       return True     else:         return False AWS Lambda 関数の完全なコードは、 Lambda > 関数 > aws-config-demo-lambda > コード タブから参照できます。 クリーンアップ チュートリアルでデプロイしたリソースを以下のステップで削除してください。 Amazon RDS インスタンスの削除 AWS CloudFormation スタックの削除 まとめ このブログ記事では、AWS アカウントのコストを管理するために AWS Config カスタムルールを実装する方法について紹介しました。また、Amazon RDS インスタンスタイプを検証するための具体的なユースケースを踏まえて説明しました。 AWS Config のカスタムルールの詳細については、 OS CIS コンプライアンス をチェックするAWS Config カスタムルールの設定をご覧ください。 著者紹介 Neville Lewis Neville Lewis は AWS の Cloud Application Architect で、アプリケーションアーキテクチャデザインの経験が豊富です。 James Hu James Hu は AWS の Sr. Cloud Application Architect で、マイクロサービスアーキテクチャや AWS CloudFormation/CDK、高可用性の構成について造形が深いです。 Desta Pickering Desta Pickering は AWS の Cloud Application Architect で、彼女はお客様のユニークな課題を解決することが大好きです。 Drishti Arora Drishti Arora は AWS Professional Services の Cloud Application Architect で、お客様とパートナーのクラウドジャーニーを支援しています。 翻訳は SA 桂井が行いました。原文は こちら です。

この記事は、 Generative AI Infrastructure at AWS を翻訳したものです。 生成 AI モデルの構築やトレーニング、そして正確で洞察に満ちた出力の予測と提供には、大規模なインフラストラクチャを必要とします。 大規模言語モデル（LLM）や基礎モデル（FM）が生成する高品質の合成テキスト、画像、その他のメディアの出力には、大量のデータが必要です。 まず、モデルのトレーニングに使用されるデータセットには、一般的に 10 億個ほどの変数（パラメータ）が含まれています。 このペタバイト単位のような膨大なデータを処理するには、何百ものハードウェアアクセラレーター（ML 専用シリコンまたは GPU が組み込まれている）が必要になります。 効果的な LLM に必要なデータ量を考えると、これらのモデルのデータに GPU/ML シリコンが処理するのと同じ速さでアクセスできなければ、コストがかかり非効率になります。 生成 AI ワークロード用のインフラストラクチャを選択することは、コスト、パフォーマンス、持続可能性の目標、使いやすさに至るまで、あらゆることに影響します。 FM のトレーニングと推論を成功させるには、組織は以下の要素が必要です。 大規模な生成 AI ワークロードを支えるためのコストパフォーマンスに優れたアクセラレーテッド・コンピューティング（最新の GPU や専用 ML シリコン） アクセラレーターの利用率を高く維持できるように構築された高性能かつ低レイテンシーのクラウドストレージ 生成 AI ワークロードのインフラストラクチャをサポートする、高性能で最先端のテクノロジー、ネットワーキング、システム 生成 AI アプリケーション、ツール、インフラストラクチャ全体でシームレスな統合を提供可能なクラウドサービスを利用した構築能力 生成 AI のためのコンピューティング、ストレージ、ネットワーキングの概要 Amazon Elastic Compute Cloud (Amazon EC2) のアクセラレーテッド・コンピューティング・ポートフォリオ（ GPU や専用の ML シリコンで動作するインスタンス ）は、生成 AI ワークロードを強化するための幅広いアクセラレーターの選択肢を提供します。 アクセラレーターの高い利用率を維持するためには、処理のためのデータへの定常的なアクセスが必要です。AWS は Amazon FSx for Lustre と Amazon S3 により、ストレージからの高速なデータ転送（最大数百 GB/TB のデータスループット）を提供します。 AWS Nitro System 、最大 3,200 Gbps の Elastic Fabric Adapter (EFA) ネットワーキング、 Amazon EC2 UltraClusters によるエクサスケールコンピューティングのような AWS テクノロジーが組み込まれた高速コンピューティングインスタンスは、生成 AI ワークロードのための最もパフォーマンスの高いインフラストラクチャを提供するのに役立ちます。 これらのインスタンスは、 Amazon SageMaker HyperPod や Amazon Elastic Kubernetes Service (Amazon EKS) などのマネージドサービスと組み合わせることで、生成 AI アプリケーションの構築とデプロイのための業界最高峰のプラットフォームを開発者に提供します。 このブログ記事では、生成 AI を中心とした Amazon EC2 インスタンス、ストレージ、ネットワーキング関連のアナウンスに焦点を当てます。 生成 AI ワークロードのための AWS コンピュートの進化 大規模な FM のトレーニングには膨大なコンピュートリソースが必要です。また、あらゆる規模の組織がより速く反復的に、多くのモデルをトレーニングし、精度を高めるためには、プロジェクト毎に幅広いオプションセットを必要とします。2023 年には、AWS のコンピュート分野全体で、生成 AI のトレーニングと推論の両方のワークロードをサポートする多くのリリースがありました。 そのうちの 1 つ、 Amazon EC2 Trn1n インスタンス （AWS 自身が ML ワークロード、特に ML トレーニング向けに開発した第二世代の ML 専用チップ AWS Trainium を搭載したインスタンス）は、Trn1 インスタンスと比較して Elastic Fabric Adapter (EFA) のネットワーク帯域幅を 2 倍の 1,600 Gbps に拡張しました。この帯域幅の向上により、LLM や mixture of experts (MoE) などのネットワーク負荷の高い生成 AI モデルのトレーニングが Trn1 と比較して最大 20% 高速化されました。 「 株式会社わたしは 」様は革新的でインタラクティブな AI チャットボットサービス「大喜利 AI」を提供しており、LLM を使用してユーモアを取り入れ、顧客により適切で会話しやすい体験を与えています。株式会社わたしはの小橋洋平 CTO は「モデルの開発では、モデルの事前学習とファインチューンを頻繁に行う必要がありました。我々はテンソルとデータの並列性を活用して、GPT ベースの日本語モデルを EC2 の Trn1.32xlarge インスタンスで事前学習しました。トレーニングは 28 日以内に完了し、以前の GPU ベースのインフラストラクチャと比較して 33% のコスト削減を実現しました。当社のモデルは急速に複雑さを増し続けるので、より大規模なモデルのトレーニングを高速化するために、Trn1 の 2 倍のネットワーク帯域幅を備えた Trn1n インスタンスに期待しています。」と述べています。 AWS は生成 AI ワークロードのためのインフラストラクチャを進化させ続けており、最近 Trainium2 アクセラレーター も近々登場すると発表しました。これらのアクセラレーターは、第 1 世代の Trainium チップよりも最大 4 倍高速な学習を実現するように設計されており、最大 100,000 チップの EC2 UltraCluster にデプロイできるようになり、エネルギー効率を最大 2 倍改善しながら、FM や LLM を短い時間で学習できるようになります。 AWS は、これまでにも GPU インフラへ長年投資を続けてきました。現在までに、NVIDIA は Ampere GPU 世代と Grace Hopper GPU 世代にわたり、AWS 上に 200 万基の GPU を展開しています。これは 3 ゼタフロップス、つまり 3,000 台のエクサスケールのスーパーコンピュータに相当します。最近では、AWS は NVIDIA H100 Tensor Core GPU で動作する Amazon EC2 P5 インスタンス を発表しました。これは、NVIDIA CUDA または CuDNN を使用した時間重視の大規模トレーニングワークロード向けに設計されたものです。P5 インスタンスは、旧世代の GPU ベースの EC2 インスタンスと比較して、ソリューション解決の速度を最大 4 倍に高速化し、ML モデルのトレーニングコストを最大 40% 削減します。P5 インスタンスは、より速いペースでソリューションを反復処理し、迅速に市場に投入するのに役立ちます。 また AWS は、高需要な GPU コンピューティング容量への簡単かつ予測可能なアクセスを提供するために、 Amazon EC2 Capacity Blocks for ML をローンチしました。これは、主要なクラウドプロバイダーとしては初めての消費モデルで、GPU を将来の使用のために予約して短時間の ML ワークロードを実行できます（EC2 UltraClusters で最大 500 基までデプロイ可能）。 AWSはまた、 Amazon SageMaker HyperPod によってトレーニングを簡素化し、大規模かつ耐障害性の高い分散トレーニングに必要なプロセス（例えば、分散トレーニングライブラリの構成、数千のアクセラレーターにわたるトレーニングワークロードのスケーリング、異常なインスタンスの検出と修復など）の多くを自動化することで、トレーニングを最大 40% 高速化します。Perplexity AI のような顧客は、SageMaker HyperPod を使用することで、 数百の GPU を超えて柔軟にスケーリングし、ダウンタイムを最小限に抑えています 。 ディープラーニングの推論は、 AWS Inferentia2 によって提供される低コストで高性能な Amazon EC2 Inf2 インスタンス など、AWS がクラウドインフラストラクチャの革新を続けているもう一つの例です。これらのインスタンスは、高性能なディープラーニングの推論アプリケーションをグローバル規模で実行するために設計されています。これらは、生成 AI における最新のイノベーションを展開するためには、Amazon EC2 における最もコスト効率とエネルギー効率の高いオプションです。 別の例として、 Amazon SageMaker を使用すると、同じインスタンスに 複数のモデルをデプロイ することができるため、コンピュートリソースを共有し、推論コストを 50% 削減することができます。SageMaker はまた、推論リクエストを処理しているインスタンスをアクティブに監視し、利用可能なインスタンスに基づいてインテリジェントにリクエストをルーティングします。これにより、平均して 20% 低い推論レイテンシーを実現します。 AWS は、生成 AI ワークロードのためのツールにも多額の投資を行っています。AWS ML シリコンについては、AWS は Trainium と Inferentia から顧客が最大限のパフォーマンスを得るためのソフトウェア開発キット（SDK）である AWS Neuron に注力しています。Neuron は、Meta の Llama 2、Databricks の MPT、mistral.ai の Mistral、Stability AI の Stable Diffusion を含む、人気のある一般公開モデルをサポートし、モデルリポジトリである Hugging Face のトップ 100 モデルのうち 93 モデルをサポートしています。PyTorch や TensorFlow のような ML フレームワークにプラグインでき、JAX のサポートは 2024 年初頭に予定されています。AWS の顧客が、既存のモデルトレーニングや推論パイプラインを、わずか数行のコードで Trainium や Inferentia に簡単に切り替えられるように設計されています。 生成 AI のための AWS クラウドストレージの進化 AWS がトレーニングと推論のパイプラインを加速させているもう 1 つの方法は、ストレージパフォーマンスの改善です。これは、最も一般的な ML タスク（大規模な GPU やアクセラレーターのクラスターへのトレーニングデータのロードなど）を考えるときだけでなく、チェックポイントや推論リクエストの処理にとっても重要です。AWSは、ストレージリクエストの速度を加速し、コンピュートリソースのアイドル時間を短縮するためのいくつかの改善を発表しました。これにより、生成 AI ワークロードをより速く、効率的に実行できます。 より正確な予測を得るために、生成 AI ワークロードは大規模なデータセットを使用しており、膨大なデータ量を処理するために高性能なストレージが必要です。 Amazon S3 Express One Zone は、組織で最も頻繁にアクセスされるデータのために設計された高性能かつ低レイテンシーのオブジェクトストレージの新しいストレージクラスです。これは、ML のトレーニングや推論のようなリクエスト集中型の処理に最適です。Amazon S3 Express One Zone は、AWS リージョン内のどのアベイラビリティゾーンからでも、Amazon S3 標準クラスよりもデータアクセス速度が最大 10 倍速く、リクエストコストが最大 50 %低い、低レイテンシーのクラウドオブジェクトストレージです。 AWS は ML フレームワークのためのデータアクセス速度も継続的に最適化しています。最近、 Amazon S3 Connector for PyTorch がローンチされ、Amazon S3 への既存の PyTorch コネクタよりも最大 40% 速くトレーニングデータをロードできるようになりました。ほとんどの顧客は、 Mountpoint for Amazon S3 や Amazon S3 Connector for PyTorch を使用してトレーニングや推論の要件を満たすことができますが、一部の顧客は独自のカスタムデータローダーを構築して管理しています。Amazon S3 と Amazon EC2 Trn1、P4d、P5 インスタンス間で最速のデータ転送速度を実現するために、AWS は最近、 AWS Command Line Interface (AWS CLI) と Python SDK で Amazon S3 のデータ転送を自動的に高速化する機能 を発表しました。トレーニングジョブは Amazon S3 からトレーニングデータを最大 3 倍高速にダウンロードし、Scenario のような顧客は、コードを 1 行も書くことなくモデルのダウンロード時間を 5 倍スループット向上させるなど、すでに大きな成果を得ています。 生成 AI ワークロードのトレーニングで要求されるパフォーマンス要件の変化に対応するため、Amazon FSx for Lustre は スループットのオンデマンドスケーリング を発表しました。これは、俊敏かつ低コストで要件を満たすようにファイルシステムのスループット階層を調整できるため、モデルトレーニングに特に有用です。 生成 AI のための AWS ネットワークの進化 昨年、AWS は EC2 UltraCluster 2.0 を発表しました。これは、P5 インスタンスと将来の ML アクセラレーター専用に最適化された、フラットで広いネットワークファブリックです。これにより、レイテンシーを 16% 削減し、最大 20,000 基の GPU をサポートし、全体の帯域幅を最大 10 倍にすることができます。従来のクラスター構成では、一般的にクラスターが物理的に大きくなるとレイテンシーも大きくなる一方で、UltraCluster 2.0 では、AWS はクラスターのサイズを拡大しながらレイテンシーを短縮します。 AWS は、ネットワークの効率化も支援し続けています。例えば、最近発表された Amazon EC2 Instance Topology API はインスタンス間の近接度を内部的に確認できるので、ジョブを戦略的に配置できます。最適化されたジョブスケジューリングにより、分散ワークロードの処理を高速化します。最も頻繁にデータをやり取りするジョブをクラスタ内の同じ物理的な場所に移動させることで、データパス内の複数のホップを排除できます。モデルが限界を押し広げる中、このようなソフトウェアの革新は、ハードウェアを最大限に活用するための鍵となります。 AWSは Amazon Q （AWS の生成 AI 搭載アシスタント）に加え、 Amazon Q networking troubleshooting (preview) も開始しました。 現在の AWS アカウントで、ネットワークの設定ミスに起因するネットワーク接続の問題のトラブルシューティングを Amazon Q にサポートしてもらうことができます。この機能では、 Amazon QはAmazon VPC Reachability Analyzer と連携して接続をチェックし、潜在的な問題を特定するためにネットワーク構成を検査します。Amazon Q network troubleshooting では、ネットワークに関する質問を会話形式で行うことができます。例えば、「Why can’t I SSH to my server?」や「Why is my website not accessible?」（2023/02 時点、日本語未対応）と尋ねることができます。 まとめ AWS は、価格性能、持続可能性、使いやすさに重点を置いたオプションを含め、お客様のインフラストラクチャにさらに多くの選択肢を提供します。昨年このスタック全体にわたる AWS の機能は、お客様のニーズに応えること、および「生成 AI をあらゆる規模や技術力のお客様が利用できるようにすることで、実現できることの革新や変革をサポートする」という目標に向けた取り組みを強化しました。 その他のリソース AWS 生成 AI インフラストラクチャの詳細は、 AWS Machine Learning インフラストラクチャ のページをご覧ください。 AWS がどのようにアプリケーション、ツール、インフラストラクチャに渡って生成 AI をクラウドで構築しているかの詳細は、ブログ「 Welcome to a New Era of Building in the Cloud with Generative AI on AWS 」をご覧ください。

お客さまから、 Amazon Relational Database Service (Amazon RDS) と Amazon Aurora データベースでのワークロードパフォーマンスの可視性と監視性、および予定されたイベントと予定外のイベントの可視性と監視性を改善する方法についてよく聞かれます。この記事では、計測機能をプロアクティブに有効化して設定し、すべての詳細をキャプチャし分析できるようにする方法について説明しています。 私は 8 年間、AWS のお客さまが Amazon RDS と Aurora でデータベースを使用するという目標を達成できるよう支援してきました。その間、top や vmstat コマンドが自己管理型データベースで提供する、より詳細なオペレーティングシステムのメトリクスに関心を持つシステム管理者の皆さんや、Amazon RDS Multi-AZ インスタンスがスタンバイアベイラビリティーゾーンにフェイルオーバーした理由を知りたがっている DBA の皆さんと仕事をしてきました。この記事では、上記の情報などを提供するさまざまな監視ツールの概要を説明し、各ツールに関する追加のヒントを示し、各ツールの仕組みについてより深く説明したい場合に利用できるリソースを紹介します。 この話題に関する動画を見たい場合は、 Amazon RDS と Aurora によるパフォーマンスモニタリングに関するこの AWS re:Invent 2022 セッション が最適です。 Amazon RDS と Aurora のツール まず、Amazon RDS と Aurora に固有のツールから始めましょう。この記事の後半では、RDS と Aurora の使用状況に関する具体的なインサイトを提供する、他の AWS サービスについても説明します。 Performance Insights Amazon RDS Performance Insights は、軽量な方法を使用してデータベースセッションとクエリのパフォーマンスメタデータをキャプチャし、それをインスタンスの CloudWatch メトリクスと組み合わせて、事前設定されカスタマイズ可能なダッシュボードに統合されたビューを提供します。特に気に入っているのは、どのクエリが最も長く、最も頻繁に実行されているかを、1秒単位まで掘り下げて確認できることです。このパフォーマンスに関するメタデータは、Performance Insights がお客さまのワークロードに与える影響を最小限に抑えるため、データベースインスタンスの外部に保存されます。データベースパフォーマンスの履歴を把握し、特定のクエリが以前と比較して現在どのように実行されているかを確認できるように、すべての本番インスタンスで常に有効にし続けておくことをお勧めします。詳細については、「 Amazon RDS での Performance Insights を使用したDB 負荷のモニタリング 」を参照するか、 パフォーマンスインサイトを使用してクエリパフォーマンスをトラブルシューティングする簡単な例 をご覧ください。 Cool fact: Performance Insightsを有効にしたり、保存期間を変更したりしても、データベースのダウンタイムや中断は発生しません。さらに、デフォルトの7日間のデータ保持には追加費用はかかりません。 推奨: パフォーマンス問題のトラブルシューティングを行う場合は、Performance Insights のデータ保持期間を一時的に延長して、原因と解決策が見つかるまでパフォーマンスデータ (問題発生前と問題発生中のもの) を保存することをお勧めします。 Amazon Aurora MySQL 互換エディション 、 Amazon Aurora PostgreSQL 互換エディション 、および Amazon RDS for PostgreSQL インスタンス使用時のボーナス: これらのデータベースエンジンでは、 Amazon DevOps Guru for RDS を使用してパフォーマンスインサイトを拡張できます。これは、データベース関連のパフォーマンスの問題 (リソースの使いすぎや特定の SQL クエリの不適切な動作など) を検出し、すぐに通知し、診断情報を提供する、機械学習 (ML) 搭載の機能です。問題の解決に役立つ推奨事項が表示されます。 このビデオでは、Amazon DevOps Guru for RDS のデモを紹介しています 。 拡張モニタリング 2015 年 12 月に Amazon RDS 拡張モニタリング機能の開始が発表 されたとき、私がどれほど興奮していたかを今でも覚えています。それ以前は、Linux プロンプト上で top、vmstat、iostat を実行した場合のような、RDS インスタンスのパフォーマンスに関するより詳細な情報を求められることがよくありました。拡張モニタリング にはそれだけでなく、50 種類を超えるさまざまなメトリクスが収集されているエンジンもあります。私が特に気に入っている拡張モニタリングの機能は、次の 2 つです。: 抽出されたメタデータは Amazon CloudWatch Logs に書き込まれ、そこで生のメトリクス値にインタラクティブかつプログラム的にアクセスできるため、メタデータを分析する独創的な方法が可能になります。たとえば、サードパーティのモニタリングツールを使用してデータを取得し、アプリケーションのパフォーマンスと関連付けることができます。また、メトリクスは RDS や Aurora インスタンス自体には書き込まれないため、拡張モニタリングを有効にしてもデータベースへのオーバーヘッドは最小限に抑えられます。さらに、 拡張モニタリング自体には別途料金はかかりませんが、CloudWatch Logs では拡張モニタリングのデータ転送とストレージに対して通常の料金が請求される 点にも注意してください。大事なことを言い忘れましたが、拡張モニタリングのメタデータにおけるデフォルトの保持期間は 30 日ですが、CloudWatch Logs 自体で ロググループの保持設定 を変更できます。 拡張モニタリングが使用するデータ収集間隔は、1、5、10、15、30、または 60 秒に設定できます (60 がデフォルト、1 が最も詳細です)。2 つの理由から、特に 1 秒間隔が気に入っています。1 つは、1 秒間隔はPerformance Insights がデータベースメタデータの収集に使用する間隔と一致していること、もう 1 つは、クエリの待ち時間の増加につながる非常に短時間の過負荷 (通常は CPU、I/O、またはネットワーク) を示すために最適な間隔だからです。 cool fact: 拡張モニタリングを有効にしたり、収集間隔を変更したりしても、データベースのダウンタイムや中断は発生しません。 推奨: パフォーマンス問題のトラブルシューティングを行う場合は、データベースにアクセスするワークロードのパフォーマンスプロファイルが明らかになるまで、拡張モニタリングのデータ収集間隔を一時的に1秒に設定することをお勧めします。これは、各ユーザーのアクションがデータベース内のデータへのクエリや変更を直接トリガーできる、インターネットベースのアプリケーションを提供するデータベースにとって特に重要です。1分毎のメトリクスではCPU使用率が 100% に遠く及ばないように見えるのに、拡張モニタリングの間隔を1秒に設定すると、ユーザの波が押し寄せた為に数秒だけ過負荷が発生することがわかった、ということを数多く経験しています。 拡張モニタリングについてもっと知りたいですか？詳細については、ブログ記事「 拡張モニタリングを使用した柔軟な解像度の Amazon RDS OS メトリクスのリアルタイムモニタリング 」を参照してください。 DBエンジンの主要なログファイル データベース管理者の同僚によると、データベースのエンジンアクティビティの主要なログファイルは、次の 2 種類のイベントに関する、主要な情報源の 1 つです。 チェックポイント、REDO ロギング、データブロックのディスクへのフラッシュなど、データベース内部の処理過程が疑われる場合 (ログを「checkpoint」「redo」「flash」などのキーワードで検索できます) 。 クラッシュ、フェイルオーバー、シャットダウン、または起動が発生した場合 (一般的なキーワードは、「start」「shut」「crash」または「ready」です) 。 Amazon RDS と Aurora では、これらのログファイルをデフォルトでお客さまが利用できるようになっているため、インスタンスから ログファイルを表示またはダウンロード できます。各エンジン毎に独自の命名規則があり、MySQL、MariaDB、SQL Serverはそれらを error logs と呼び、オラクルはそれらを alert logs と呼び、PostgreSQLはそれらを postgresql logs と呼びます。 Tip: エンジンログに関しては「ニュースがないのは良いニュースだ」ということわざが確かに当てはまります。特定の時間間隔でログがない場合は、エンジンが問題を警告する必要がないと判断したことを意味します。その間、シャットダウン、起動、クラッシュ、またはフェイルオーバーは発生しませんでした。 Cool fact: Amazon RDS と Aurora は自動的にログローテーションとログの保持を管理します。 推奨: 各エンジンには、記録される情報量を増やすために設定できるパラメーターがあります。これらの詳細については、エンジンのドキュメントを参照することをお勧めします。 追加のデータベースアクティビティ監査 一部のデータベースインスタンスでは、ワークロードの重要度によって、データベースで発生したすべてのことを記録しておきたい場合があります。誰が、どの IP アドレスから、何時にログインしたのか？先週の土曜日にテーブルがドロップされた時の正確なタイムスタンプはいつで、特定の時点への復元を正確に開始できるか？アプリケーションの設定でテーブルを更新したのは誰で、いつ更新したのか？データベース監査は、これらの質問に答えます。しかし、オーバーヘッドがあり、すべての顧客がそれを必要としているわけではないため、監査はインスタンスに対して有効にする必要があります。さらに、監査機能はデータベースエンジンによって提供されるため、それぞれに異なる有効化手順があります。Amazon RDS と Aurora の各データベースエンジンの監査を有効にする方法の詳細については、以下のリソースを参照してください。 RDS for MySQL、RDS for MariaDB、および Amazon Aurora MySQL 互換エディションでのデータベースアクティビティをキャプチャするように監査ログを設定する PostgreSQL を実行している Amazon RDS DB インスタンスを pgaudit 拡張機能を使用して監査するにはどうすればよいですか? データベースアクティビティストリームと pgAudit を使用して Aurora PostgreSQL データベースを監査する Amazon RDS for Oracle でのセキュリティ監査 Amazon RDS for SQL Server の DB インスタンスの監査 推奨: 非常にアクティブなインスタンスは大量のログを生成します。ワークロードにこのような特徴がある場合は、次のトピックを確認してください。 CloudWatch Logs によるログのクエリと保存 エンジンによっては、各エンジンの主要なログファイルや監査ログファイル以外にも便利なロギング形式があります。たとえば、MySQL や MySQL 互換のエンジンでは、定義した秒数以上かかるクエリを スロークエリログ に記録できます。これらのさまざまな形式のロギングを行う間に、ログファイルの数とサイズが大きくなる可能性があります。その一方、データベースインスタンスは、これらのログファイルを保存したりアクセスしたりするのに最適な場所ではありません。このため、Amazon RDS と Aurora には、 データベースログを CloudWatch ログに発行できる機能 があります。データベースログを CloudWatch Logs にエクスポートすることが良い理由は次のとおりです。 ディスク容量を節約するために、Amazon RDS と Aurora は定期的にログをローテーションし、インスタンスから削除しています。一方、CloudWatch Logs の ログの保存期間はユーザーが定義でき、期限切れにならないように設定することもできます。 大きなファイルまたは大量のファイルをデータベースインスタンスから直接ダウンロードすると、インスタンスの I/O リソースを大幅に消費する可能性があります。しかし、ログをCloudWatch Logs から読み取っても、データベースインスタンスのパフォーマンスには、ほとんど、またはまったく影響しません。 CloudWatch Logs には非常に優れた 検索機能とフィルタリング機能 があり、必要なログをすばやく簡単に特定してアクセスできます。 CloudWatch Logs では、 ログに特定のキーワードが見つかったときに通知を設定できます 。 Aurora インスタンスは、インスタンスにアタッチされた一時ディスクにログを保存します。このため、インスタンスに障害が発生して交換された場合、ログが失われる可能性があります。しかし、ログをCloudWatch Logsに発行することで、最新のわずかな部分を除いてすべてが保存されます。 注意事項: ほとんどのログはお客さまにて有効化される必要があるため、もしもログが生成されていない場合は、CloudWatch Logs にログをエクスポートするようにインスタンスを設定するだけでは不十分です。 推奨: CloudWatch Logs と、AWS Lambda、Amazon SNS、その他の AWS ソリューションを組み合わせて使用することで、プロアクティブで自動化された RDS ログ分析およびアラート機能を構築できます。 RDS イベント RDS イベントは、Amazon RDS のあまり知られておらず、活用されていない機能の 1 つであると同時に、非常に便利な機能でもあります。エラーログファイルを監視してデータベース内で何が起こっているかを知ることが重要であるのと同じように、 RDS イベントを監視 して、データベースを支えている RDS 基盤で何が起こっているかを知ることも同様に重要です。 Cool fact 1: イベント「Recovery of the DB instance has started. Recovery time will vary with the amount of data to be recovered. (DB インスタンスの復旧がスタートされました。復旧時間は、復旧するデータの量に応じて変わります。) 」これは、インスタンスのハードウェアが復旧中であることを意味します。Amazon RDS の復旧は、新しい Amazon Elastic Compute Cloud (Amazon EC2) ホストに移行して、ハードウェアを交換することによって行われます。リカバリにかかる時間は場合によって異なりますが、以下の 2 つの理由によります。まず、新しいホストのプロビジョニングには時間がかかります。次に、新しいホストが作成され、データベースプロセスが起動すると、プロセスがクラッシュリカバリを開始します。クラッシュリカバリは、リカバリ前の状況に応じて、短時間で完了する場合もあれば、時間がかかる場合もあります。エンジンはそれぞれ異なっており、クラッシュリカバリに関するデータベースエンジンのマニュアルを確認することをお勧めします。 Cool fact 2: イベント「The RDS Multi-AZ primary instance is busy and unresponsive (RDS Multi-AZ プライマリインスタンスはビジーで応答しません) 」このイベントは、数少ない RDS Multi- AZ フェイルオーバーの原因のうちの 1 つであり、すぐに通知を受けることができます。このイベントが発生した場合は、この記事で紹介した他の監視ツールをさらに活用する必要があります。そうすることで、インスタンスがなぜ応答不能になるほどビジー状態となったのかを突き止めることができます。 Amazon RDS はとりわけ、インスタンスとクラスターのイベントを生成します。過去 24 時間は Amazon RDS コンソールでアクセスでき、過去 14 日間は、 AWS コマンドラインインターフェイス (AWS CLI) や SDK などを使用してプログラム的にアクセスできます。しかし、私が本当にお勧めするのは、 イベント通知サブスクリプション を有効にすることです。これにより、送信先とデータ保持を定義できます。 推奨: すべてのクラスターとインスタンスのすべてのイベントに、イベント通知サブスクリプションを設定し (個別に挙げる必要はなく、この設定であれば後から作成したリソースにも適用されます)、専用のメールアドレス、または、Amazon RDS での 14 日間の保存期間が経過した後でも検索や読み取りが可能なその他の長期保存ストレージに配信するように設定します。 Amazon RDS CloudWatch メトリクス RDS と Aurora の各インスタンスは、追加費用なし、設定なしですぐに使える、 1 分間隔の、 数十の CloudWatch メトリクス を収集し公開します。Amazon RDS コンソールには、インスタンスの現在のステータスを一目で確認できる便利なインターフェイスがありますが、メトリクスの分析と相関付けを行うため、CloudWatch のより強力なメトリクス管理専用インターフェイスの方が私は好きです。 Cool fact: RDS メトリクスは 15 か月間保存されますが、解像度の高いメトリクスは CloudWatch によって定期的に集計されます 。たとえば、15 日が経過すると、1 分毎のデータは表示されなくなりますが、5 分毎のデータは引き続き表示されます。また、各期間の 5 つのデータポイントは集計されたため、最小値、平均値、最大値を確認できます。 Tip: Amazon RDS は、インスタンスの名前を使用してメトリクスを CloudWatch に保存します。これには 2 つの影響があります。まず、インスタンスの名前が変更されると、メトリクスが消去されたように見える場合がありますが、実際にはメトリクスは古い名前に関連付けられており、CloudWatch コンソールからアクセスできます。次に、インスタンスが削除され、同じ名前で別のインスタンスが作成 (または復元) された場合、新しいインスタンスには以前のインスタンスのメトリクスも表示されるため、作成前のメトリクスがあるように見えます。 Aurora使用時のボーナス: Aurora は、インスタンスのメトリクスの公開に加えて、同じメトリクス値をクラスター名にも公開します。インスタンスがライターかリーダーかによって、WRITER ロールまたは READER ロールにも公開されます。次の点に注意してください。 クラスターメトリクスは、インスタンスのCPU使用率が 90% を超えた場合にアラームを設定するなど、インスタンスの削除や追加に関係なく機能するクラスター全体のアラームを設定する場合に非常に役立ちます。また、ある時点でクラスターにどれだけの正常なインスタンスがあったかを知るのにも役立ちます。また、SampleCount 統計値を使用して、1 分毎にメトリクスを報告したインスタンスの数を知ることができます。 クラスターの WRITER ロールに関するメトリクスは、フェイルオーバーによって異なる時点でクラスターのライターが 2 つ以上のインスタンスになった場合でも、クラスターの過去のライターパフォーマンスを一貫して確認できる優れた方法です。いちどにただ1つのインスタンスが、このロールに対してレポートします。 クラスターの READER ロールのメトリクスは、 Application Auto Scaling が必要に応じてクラスターにリーダーを追加または削除するような場合に使用するメトリクスです。ただし、これらのメトリクスは、クラスター上の少なくとも 1 つのインスタンスがリーダーである場合にのみ表示されます。このため、Auto Scaling が有効なクラスターには常にライターとリーダーが必要です。 さらに、これらのメトリクスで CloudWatch アラームを作成 することもできます。ただし、おそらく使用するエンジン毎に異なる、重要なものに対してのみ作成したいと思うでしょう。たとえば、PostgreSQLの場合、 トランザクション ID のラップアラウンドを防ぐための アラームを設定したいと思うかもしれません。 Pro tip: 特定のメトリクス (またはインスタンスのすべてのメトリクス) のデータが欠落していることは、メトリクスの高い値が意味していることと同じくらい重要です。データベースインスタンス内の RDS エージェントがメトリクスの値を CloudWatch にプッシュするため、インスタンスのすべてのメトリクスが欠落しているということは、インスタンスに過負荷または障害が発生している可能性があることを示しています。同様に、一部のメトリクスは表示されているが他のメトリクスは表示されない場合、それが何かを意味している可能性があります。 たとえば、CPU利用率 (およびその他のOSベースのメトリクス) の値は見えるが、レプリカの遅延 (またはその他のデータベースベースのメトリクス) は見えない場合、私はそれを不審に思い、他の点では正常なホストでデータベースプロセス自体に障害が発生していないかどうかを確認する他の手段を探すことになります。 AWSサービス このセクションでは、他の AWS サービスが、Amazon RDS や Aurora のインサイトを補完する具体的なインサイトをどのように提供するかについて説明します。 AWS CloudTrail データベースの監査によって、データベース接続を通じてデータベースに送信されたコマンドを記録して知ることができるのと同様に、 AWS CloudTrail では、Amazon RDS や Aurora などを含めたAWS サービスに対して、さまざまな手段 (CloudTrail コンソール、AWS CLI、CDK、サードパーティツール、エンドポイントへの直接の API 呼び出しなど) を通じて AWS アカウントに送信されたすべての API 呼び出しを、ログに記録 して知ることができます。 Cool fact: CloudTrail には、過去 90 日間の API 呼び出しを保存するイベント履歴がデフォルトで用意されています。このイベント履歴を保存するために何かを有効にしたり設定したりする必要はありません。 推奨: オプションの 証跡 を有効にすると、 Amazon Simple Storage Service (Amazon S3) バケットにイベントが配信されて保存され、必要に応じて保持期間を設定できます。 AWS Health AWS Health は、AWS サービスのパフォーマンスと可用性、およびこれらがアカウントに与える影響について、AWS がお客さまに知らせる方法です。これは、2 つの部分からなります。1 つは、公開情報でありアクセスに認証を必要としない サービスの状態 (Service Health) ページ で、もう 1 つはアカウントのリソースに固有の情報を提供する アカウントの状態 (Account Health) ページ です。 推奨 1: RDS と Aurora のインスタンスとクラスターの アカウントの状態 ページには、想定どおりに動作しない状況に関する情報に加えて、今後のメンテナンスや必要なアップグレードに関する通知も表示されます。 アカウントの状態ページ の [その他の通知] タブを確認することを忘れないでください。 推奨 2: AWS アカウントに関連付けられているメールアドレスには、Health イベントに関するメールも送信されます。これらは、検索できるフォルダに長期間保存することをお勧めします。 Amazon VPC Amazon Virtual Private Cloud (Amazon VPC) には、接続問題のトラブルシューティングに役立ついくつかの機能があります。 VPC フローログ VPC フローログ は、VPC 上のネットワークインターフェイスに出入りする IP トラフィック (および TCP 接続) に関する情報を提供します。 推奨: 接続がどこから、どのボリュームまたはレートで接続されているかを把握するために、必要に応じて使用してください。これは、新しい接続ストームやスパイクが疑われる場合に非常に役立ちます。 VPC トラフィックミラーリング お客さまからよく聞かれるもう 1 つの質問は、「RDS または Aurora インスタンスでパケットキャプチャを実行できますか?」というものです。その答えは「はい、思っているよりも簡単に出来ます」です。RDS や Aurora インスタンスに触れることなく、お客さま自身で実行できるからです。 VPC トラフィックミラーリング には、 (VPC 内の他の ENI と同じように) RDS または Aurora ENI からのトラフィックを、パケットキャプチャユーティリティ (pcap や Wireshark など) が実行されている EC2 インスタンスにミラーリングする機能があります。ネットワークや接続の問題が疑われる場合のトラブルシューティングとして、この方法をお勧めします。 Cool fact: 複数のクライアントからのトラフィックを一度にキャプチャするため、複数のクライアント上でそれを実施するよりもセットアップがはるかに簡単です。また、AWS サポートを利用しているかどうかに関係なくセットアップできるため、より迅速です。 推奨: ミラーリングされるすべてのパケットを受信できる能力を確保するために、ターゲットの EC2 インスタンスを、 RDS または Aurora インスタンスと少なくとも同じサイズに設定することを忘れないでください。 アプリケーションもしくはデータベースクライアント AWS、Amazon RDS、およびデータベースインスタンス自体から取得できる前述のすべての情報に加えて、クライアントマシン、つまりデータベースに接続しているマシンでのみ取得できる重要な情報があります。接続の問題など、セッション固有のエラーや警告は、データベース接続自体を通じてのみ報告されるため、接続をオープンするクライアントソフトウェアは、その情報をログに記録する必要があります。そうしないと、情報が失われます。 同様に、お客さまはしばしばデータベースのパフォーマンス上の問題を疑いますが、実際のパフォーマンス問題の原因が結局クライアントマシンだったと判明することがあります。 推奨 1: クライアントマシン上で、アプリケーションが接続固有のエラーを記録して保持するようにしてください。 推奨 2: データベース呼び出しやその他の操作を開始タイムスタンプと終了タイムスタンプと共に記録するような、デバッグモードを有効にするスイッチまたはオプションがアプリケーションにあるかどうかを確認します。 まとめ Amazon RDS、 Aurora のお客さまには、データベースのワークロードを監視するために使用できる、さまざまなツールがあります。 この記事では、どのような状況でどのツールを使用すべきかを説明し、各ツールが提供するものについて説明し、各ツールの詳細情報を参照するためのリンクを提供しました。 フィードバックや質問がある場合は、コメントセクションにコメントを残してください。 著者について Valter Rehn は AWS サポートの Principal Engineer です。彼はAmazon RDSとAmazon Auroraに焦点を当てており、2015年7月に Aurora バージョン1.0がリリースされて以来、Auroraの最適な使用方法についてお客さまにガイドしてきました。 翻訳はクラウドサポートエンジニアの立野が担当しました。原文は こちら です。

AWS 上で Infrastructure as Code (IaC) を利用することで、インフラストラクチャがスケールするように管理、モデリング、プロビジョニングできます。 AWS CloudFormation を使えば YAML や JSON でコードとしてインフラストラクチャを宣言できます。一般的なプログラミング言語を使って AWS Cloud Development Kit (CDK) を利用することもできます。 Application Composer で視覚的に管理することもできます。IaC 化されたリソースは、選択したバージョン管理システムで監査およびバージョン管理ができます。また、AWS CloudFormation を使ってデプロイすることで、 変更セット を使ったデプロイプレビュー、自動ロールバック、 Hooks を使ったリソースコンプライアンスのプロアクティブな適用などが可能になります。非常に多くのお客様が、AWS 上で IaC による安全性と信頼性の恩恵を受けています。 すべてのリソースが IaC で作成されるわけではありません。お客様はさまざまな理由で IaC 管理外のリソースを作成しています。IaC を知らなかったり、CLI や マネジメントコンソール で作業することを好む場合もあります。2019 年に、既存のリソースを CloudFormation に インポート する機能を発表しました。この機能は個々のリソースを IaC に取り込むうえでもはや必要不可欠ですが、デプロイ済みのリソースに合わせて手動でテンプレートを作成するプロセスは理想的ではありませんでした。お客様はリソースのドキュメントを調べ、パラメーターを手動でコピーする必要がありました。また、お客様はこれまで関連するリソースのグループとしてアプリケーションを扱っており、個々のリソースを扱うことはその経験と合致しないとのフィードバックもいただいています。そこで、リソースと関連するリソースをより包括的に管理する仕組みの作成に取り組むことにしました。 先日、リソースと関連するリソースに対して IaC のテンプレートを作成し、一貫した体験を実現する IaC ジェネレーター と CDK Migrate を発表しました。 これは、AWS アカウントをスキャンし、 CloudFormation リソースタイプスキーマ を使用してリソース間の関連情報を見つけることで機能します。 テンプレートが作成されると、既存のスタックにそれらのリソースをインポートするか、ゼロから完全に新しいスタックを作成するかのどちらかを選択できます。 リソースを再作成する必要はなく、アプリケーション全体を CloudFormation スタックで管理できるようになりました！ このブログでは、IaC ジェネレーター が解決する一般的なユースケースを紹介します。IaC ツールの外で作成された既存のネットワークアーキテクチャを CloudFormation で管理します。 IaC ジェネレーターの活用 次のシナリオを考えてみましょう: クラウド活用のプロセスを始めたばかりの組織に新入社員として入社し、チームの共有 Amazon Virtual Private Cloud (VPC) リソースの開発を継続するタスクが課せられました。 これらのリソースは現在、開発チームによってアクティブに使用されています。 調べてみると、これらのリソースは IaC を利用せずに作成されたことがわかりました。 ドキュメントはなく、セットアップした人はもうチームにいません。 問題をより複雑にしているのは、 サブネット 、 ルートテーブル 、 インターネットゲートウェイ などの関連リソースを含む複数の VPC があることです。 あなたは IaC のメリットである再現性、信頼性、監査可能性、安全性を理解しています。 これらのリソースを CloudFormation の管理下に置くことで、既存のリソースにもこれらのメリットが適用されます。 以前にもリソースを CloudFormation にインポートしたことがあるので、テンプレートを作成するために、関連するすべてのリソースを手動で見つける作業に取りかかります。しかし、すぐにこれは簡単な作業ではないことがわかりました。 VPC には他のリソースとの関連情報は保存されていません。その代わりに、関係性は逆になっています。リソースは自身が紐付く VPC を知っていますが、VPC は自身に紐付いているリソースを知りません。 VPC に関連するすべてのリソースを見つけるには、VPC 関連のすべてのリソースを手動で確認し、それらが属している vpc-id をスキャンする必要があります。 存在を認識していなかったり、異なるサービスのリソースであったりするためにリソースを見落としやすいので、注意深く確認する必要があります。 たとえば、 Elastic Network Interface (ENI) を使用して VPC にアタッチするリソースもあります。 Amazon Relational Database Service インスタンスなどがそうです。 しかし、あなたは最近 IaC ジェネレーターのことを知りました。 このジェネレーターは、アカウントのスキャンを実行してリソースの最新のインベントリを作成することで機能します。 CloudFormation は、リソースタイプスキーマを利用して、リソース間の関係性を見つけます。 たとえば、サブネットは vpc-id プロパティ経由で VPC との関係があると判断できます。 これらの関係性が決定されると、テンプレートを生成したいトップレベルのリソースを選択できます。 最後に、ウィザードを利用して、この既存のテンプレートからスタックを作成できます。 マネジメントコンソールの IaC ジェネレーターページに移動し、アカウントでスキャンを開始できます。スキャンは 30 日間有効で、1 つのアカウントで 1 日に 3 回スキャンを実行できます。 スキャンが完了すると、 テンプレートを作成 ボタンを選択してテンプレートを作成します。 新しいテンプレートから開始 を選択した後、 テンプレート名 やスタックポリシーなど、スタックに関する詳細を入力します。ここでは、 Retain (保持) のままにします。 次のページでは、スキャンされたすべてのリソースが表示されます。タグなどのフィルタをリソースに追加して、スキャンされたリソースのサブセットを表示できます。この例では、 Resource type prefix フィルタのみを使用します。フィルタの詳細については、 こちら をご覧ください。VPC を見つけたら、リストから選択できます。 次のページでは、CloudFormation がこの VPC とリンクしていると判断したリソースのリストが表示されます。 これには、さまざまなネットワーク関連リソースが含まれていることがわかります。 これらすべてのリソースを選択した状態でテンプレートを作成します。 この時点で、 テンプレートを作成 を選択すると、CloudFormation が既存のリソースからテンプレートを生成します。 これらのリソースをインポートする既存のスタックがないため、新しいスタックを作成する必要があります。 ここでこのテンプレートを選択し、 スタックにインポート ボタンを選択します。 スタック名 を入力した後、テンプレートが必要とする パラメータ を入力できます。 CloudFormation は、新しいスタックの変更セットを作成します。変更セットを使用すると、CloudFormation がスタックに適用する変更を確認できます。この例では、すべてのリソースが Import ステータスになります。CloudFormation が見つけたリソースが表示され、スタックを作成できます。 この時点で、スタックの作成操作は通常通り進み、各リソースをインポートしてスタックに取り込んでいきます。ネットワークスタック全体を正常にインポートできたことをチームに報告できます！次のステップとして、このテンプレートをバージョン管理システムでソース管理する必要があります。 私たちは先日、 CloudFormation テンプレートを一般的なバージョン管理システムと同期 できる新機能を発表しました。 最後に、 ドリフト を避けるために、CloudFormation を通じて変更を行うことを確認してください。 この例は主に CloudFormation ベースでしたが、CDK を利用されている方は CDK Migrate を使用して、この構成を CDK アプリケーションにインポートできます。 すぐにご利用いただけます！ IaC ジェネレーターは、CloudFormation がサポートされているすべてのリージョンで現在利用可能です。コンソール、CLI、SDK を使用して IaC ジェネレーターにアクセスできます。 おわりに このブログでは、CloudFormation の新しい IaC ジェネレーター機能を紹介しました。以前に存在していたリソースを管理する必要があるシナリオを辿り、IaC ジェネレーターの提供する手順に従って CloudFormation テンプレートを生成しました。次に、そのテンプレートを使用してスタックを作成し、これらのリソースを管理しました。 これらのリソースは、IaC が提供する安全性と反復可能性の恩恵を受けることができるようになりました。これはひとつの例に過ぎませんが、コンソールファーストの開発体験を可能にするなど、この機能の他のユースケースを想定しています。この機能についてのご意見をお聞かせいただけることを楽しみにしています。 ぜひ感想をお聞かせください！ 本記事は、Dan Blanco による Import entire applications into AWS CloudFormation を翻訳したものです。翻訳はソリューションアーキテクトの山崎宏紀が担当しました。

はじめに Amazon Elastic Container Service (ECS)  は、コンテナ化されたタスクを AWS インフラストラクチャにデプロイし、管理します。Amazon ECS を使用して、サーバーレスである AWS Fargate キャパシティにタスクをデプロイすることで、お客様はコンピューティングインスタンスを保守する必要がなくなります。しかし、Amazon Elastic Compute Cloud (Amazon EC2) をキャパシティとして Amazon ECS を使用することを好むお客様もいます。EC2 インスタンスをコンテナ実行のキャパシティとして使用すると、基盤となるコンピューティングインフラストラクチャをより細かく制御できますが、これにはメンテナンスのオーバーヘッドが増えるという欠点があります。従来、クラスターオペレーターは EC2 インスタンスで実行されているコンテナワークロードが予期せず中断されないように、EC2 インスタンスのメンテナンス用のカスタムツールを構築する必要がありました。Amazon ECS には、EC2 インスタンスで実行中のタスクをドレインし、それらのタスクを別のインスタンスに移動する機能が組み込まれています。これにより、元のインスタンスを置き換えたり終了したりすることができます。ただし、このドレイン機能を利用するには、 コンテナインスタンスをドレイン状態に設定し、すべてのタスクがドレインされるまでの間コンテナインスタンスをドレイン状態にする、Auto Scaling ライフサイクルフックを利用したカスタムソリューションを、お客様自身で実装する必要がありました。 Amazon ECS では、Amazon ECS キャパシティプロバイダーの組み込み機能としてマネージドインスタンスドレインが提供されるようになりました。この新機能により、Amazon ECS は Amazon ECS キャパシティプロバイダーに関連付けられた Amazon EC2 Auto Scaling グループの一部である EC2 インスタンスから、タスクを安全かつ自動的にドレインできるようになりました。この簡素化により多くの Amazon ECS のお客様は、これまで EC2 インスタンスのドレインに使用していたカスタムライフサイクルフックが不要になります。お客様は、Auto Scaling グループインスタンスの更新をシームレスに利用することで、ワークロードを中断させずに ECS エージェントの新しいバージョンのロールアウトのようなインフラストラクチャの更新を実行できるようになりました。 インスタンスの更新とドレインについて EC2 Auto Scaling グループは、EC2 インスタンス群をスケールアウトするための主要なメカニズムです。Auto Scaling グループに属する EC2 インスタンスは、インスタンスタイプと EC2 インスタンスのベースとなる Amazon マシンイメージ (AMI) を定義する起動テンプレートを使用して設定します。Amazon ECS の場合は、 ECS に最適化された AMI をベースにした EC2 インスタンスを起動できます。この特別な AMI には、インスタンスを Amazon ECS クラスターに接続し、ホストでコンテナワークロードを起動するために必要なものがすべて付属しています。Amazon ECS の新機能や、基盤となるホスト OS のバグやセキュリティ脆弱性に対するパッチを提供するために、ECS に最適化された AMI の新しいバージョンが定期的にリリースされています。 Auto Scaling グループインスタンスの更新 は、クラスター内の EC2 インスタンスを稼働させている AMI を更新するための 1 つのソリューションです。Amazon ECS に最適化された AMI の最新バージョンを参照する新しい起動テンプレートは、Auto Scaling グループの EC2 インスタンスの再起動に役立ちます。 EC2 Auto Scaling グループの AMI アップデートをトリガーするには様々な方法があります。EventBridge Scheduler と Lambda 関数を使用して定期的にインスタンスの更新をトリガーすることで、インスタンスの更新を自動化したい場合があります。AWS CloudFormation または AWS Cloud Development Kit (AWS CDK) を使用したい場合は、 UpdatePolicy 設定 を使用して、EC2 インスタンスのコード駆動型ローリング更新としてインフラストラクチャを設定することもできます。 EC2 インスタンスをどのように更新しても、Auto Scaling グループの一部である EC2 インスタンスは置き換えられます。タスクの実行中に EC2 インスタンスを停止して交換すると、それらのタスクも停止します。Amazon ECS は、Amazon ECS サービスの一部のタスクが失われたことを検出します。サービスの希望するタスク数を維持するために、Amazon ECS はクラスター内の別の EC2 インスタンスで代替タスクを起動します。しかし、これは事後対応型のフェイルセーフであり、コンテナがすでに停止していて、サービスの実行中タスク数がすでに希望タスク数を下回った後にのみ発生します。 マネージドインスタンスドレインは、事後対応型ではなく事前対応型です。EC2 インスタンスが Auto Scaling グループによって終了するように設定されるたびに、Amazon ECS はインスタンスの終了を一時的に遅らせ、インスタンスを自動的にドレインモードにします。このドレインモードでは、インスタンスでこれ以上タスクが起動されなくなり、インスタンスで実行中のサービス起動タスクはすべて積極的に新しいホストに置き換えられます。タスク置換では、ドレイン中の EC2 インスタンスで現在実行中の既存のタスクを停止する前に、新しい置換タスクを起動しようとします。ドレイン動作の詳細については、Amazon ECS の公式ドキュメント コンテナインスタンスドレイン をご覧ください。 新しいマネージドインスタンスドレインは、ワークロードの実行と可用性を維持するために設計された次の Amazon ECS 機能と相互作用します。 マネージド終了保護 Auto Scaling グループにアタッチされた Amazon ECS キャパシティプロバイダーを設定する場合、Amazon ECS で利用できるオプションの 1 つにマネージド終了保護があります。これにより、Amazon ECS タスクを実行している EC2 インスタンスをスケールインから保護できます。有効にすると、Auto Scaling グループのスケールイン中は、1 つ以上のタスクを実行している EC2 インスタンスを停止できなくなります。マネージド終了保護は、あらゆる形態の EC2 インスタンスの終了を防ぐわけではありませんが、EC2 インスタンスをドレインする必要がある状況の多くを防ぐことができます。しかし、それでもなお、マネージド終了保護とマネージドインスタンスドレインの両方を有効にすることは良いことです。両方の機能を有効にすると、本番環境のワークロードの中断から最大限の保護を受けることができます。マネージド終了保護により、さまざまなタイプの破壊的な EC2 インスタンス停止を防ぐことができます。また、マネージドインスタンスドレインにより、EC2 インスタンスを終了する必要が生じた場合でも、実行中のワークロードが適切に処理されます。 停止タイムアウト Amazon ECS タスクを定義するときに、タスクの停止タイムアウトを指定できます。指定しない場合、この停止タイムアウトはデフォルトで 30 秒になります。Amazon ECS は EC2 インスタンスをドレインしているときに停止が必要な各タスクコンテナに SIGTERM 停止信号を送り、停止タイムアウトの時間を待ってコンテナが正常に終了するかどうかを確認します。停止タイムアウトが経過してもコンテナが正常に終了しない場合、Amazon ECS はコンテナのプロセスを強制停止するために  SIGKILL  信号を送ります。すぐには完了できないような重い作業がタスクで行われている場合は、タスクの停止タイムアウトを長く設定できます。マネージドインスタンスドレインでは、タスクが自動的に正常終了するか、停止タイムアウト期間を超えて Amazon ECS がタスクを強制停止するまで、EC2 インスタンスをドレイン状態のままにします。ただし、Amazon ECS のタスクの停止タイムアウトは、希望すれば何年も待機するように設定できますが、EC2 のドレイン期間は 48 時間を超えることはできません。したがって、タスク停止タイムアウトを 48 時間以上に設定することはお勧めできません。 タスク保護 Amazon ECS では、実行中のタスク自体を保護対象としてマークすることができます。この機能は、タスクが重要な作業を行っている最中であり、そのタスクを停止してはいけないことを Amazon ECS に伝えます。マネージド終了保護を使用している場合、保護されたタスクを実行しているインスタンスは、Auto Scaling グループのスケールインの一環として停止されないようにすでに部分的に保護されています。ただし、マネージド終了保護が無効になっている場合、Amazon EC2 Auto Scaling グループは EC2 インスタンスに保護されたタスクがあるかどうかを確認しません。さらに、Amazon ECS のマネージド終了保護によってスケールインから保護されている場合でも、EC2 インスタンスの更新によるインスタンスの置き換えができるように設定できます。Auto Scaling グループは引き続き、保護されたタスクをホストしている EC2 インスタンスを終了することを選択できます。これにより EC2 インスタンスはドレイン状態になり、インスタンスで実行中のタスクはタスク保護の状態に関係なく、すぐに SIGTERM   停止信号を送ります。タスクで停止タイムアウトを使用してタスクフォースの終了を遅らせ、EC2 インスタンスを最大 48 時間ドレイン状態に保つことができます。 一般的に、タスク保護機能を使用する予定のタスクには停止タイムアウトを設定するのがベストプラクティスと考えられています。さらに、EC2 でホストされるミッションクリティカルなタスクであれば、 Amazon ECS メタデータエンドポイント を使用してタスクをホストしているインスタンスの ID を検出し、 Amazon EC2 ModifyInstanceAttribute API を使用して、タスクをホストする EC2 インスタンスに disableApiStop 属性または disableAPItermination 属性を設定すると良い場合があります。これにより、EC2 インスタンスの自動停止アクションに対する保護が強化されます。 RunTask API で起動されたスタンドアロンタスク サービスが起動したタスクはレプリカセットの一部であり、サービスはいつでも他の EC2 インスタンスで追加のタスクを起動できるため、EC2 インスタンスから安全に削除できます。ただし Amazon ECS では、RunTask API で起動されたスタンドアロンタスクをドレインしません 。むしろ、Amazon ECS はこれらのタスクが自動的に終了するのを待ちます。これらのタスクが実行されている限り、Amazon EC2 インスタンスはドレイン状態のままになります。Amazon EC2 インスタンスは、最大 48 時間までドレイン状態のままでいることができます。それ以降は、 RunTask  によって起動されたか CreateService  によって起動されたかにかかわらず、インスタンス上のすべてのタスクが強制停止されます。 まとめ 新しい Amazon ECS マネージドインスタンスドレイン機能は、公開コンテナロードマップの機能リクエストから生まれました。 オープンソースの RFC には、Github で 300 件以上のリアクションが寄せられました。Amazon ECS の将来への継続的な関心と関与に感謝するとともに、AWS にコンテナを大規模にデプロイしやすくする強力な機能を引き続き提供できることを嬉しく思います。独自の機能リクエストがある場合は、公開ロードマップに問題を提起するか、既存の機能リクエストに賛成票を投じて関心を示してください。 マネージドインスタンスドレインを開始するには、Amazon ECS ドキュメントを参照して、キャパシティプロバイダーと Auto Scaling グループに マネージドインスタンスドレインを有効にする方法の詳細 を確認してください。 本記事は Amazon ECS enables easier EC2 capacity management, with managed instance draining  (2024 年 1 月 19 日公開) を翻訳したものです。翻訳は、ソリューションアーキテクトの吉田が担当しました。

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 2月になりました。私は東京在住なのですが、人によってはそろそろ花粉の兆しを感じる、といっている方も出始めてきましたね。私もスギ花粉症があるので、そろそろ薬を飲み始めようかなと思っています。私は3年前に舌下免疫療法という、スギ花粉を定期的に摂取してアレルギー反応を弱める治療を始めたのですが、幾分か症状が軽くなったような気がします。でも、スギ花粉の量にもよるでしょうし、なんとも判断しづらい感じですね……。 さて、2月22日には AWS Innovate が開催されます。今回はAI/ML and Data editionというテーマでお送りします。昨年からのホットなトピックである生成AIが主軸ですが、お客様と会話をしていると「どうやれば実務を良くするために利用できるか」というポイントに興味の軸足が移ってきているように感じます。今回のAWS Innovateでは既存のモデルを利用したい方、モデル開発にチャレンジしたい方、ビジネスへの応用を考えている方、それぞれに興味を持っていただけるコンテンツを用意しましたので、ぜひご参加ください。 それでは、1 月 29 日週のアップデートを振り返ってみましょう。 2024 年 1 月 29 日週の主要なアップデート 1/29(月) Amazon EC2の属性ベースのインスタンス選択利用時に評価される価格保護ルールを追加 Amazon EC2 AutoScalingやEC2 FleetではvCPUやメモリなどインスタンスの属性に基づいて、スケーリングを実行することが可能です。今回のアップデートで、スポットインスタンス利用時の価格に基づいた制御を行うことが可能になり、コスト効果を最大化するためのルールを定義しやすくなりました。 Amazon RDS for Db2で照合順序としてEBCDICに対応 Amazon RDS for Db2がEBCDICによる照合順序をサポートしました。EBCDICによる照合順序を利用することが多いz/OS上のDb2からAmazon RDS for Db2に移行する場合に便利な機能です。従来の照合順序を維持することができるので、アプリケーション改修量の削減が期待できます。 1/30(火) AWS GlueのAmazon Q data intergration機能をプレビュー開始 自然言語を利用してデータ統合ジョブを構築できるようにすることでジョブ構築を容易にする新機能、Amazon Q data integrationのプレビューを開始しました。この機能は生成AIの技術に基づいており、自然言語でワークロードを説明すると、Glueのスクリプトが生成されます。詳細については ブログ もぜひ。 1/31(水) Amazon Aurora PostgreSQLがPostgreSQL 16.1をサポート PostgreSQL互換のAmazon Auroraで、PostgreSQLの バージョン16.1 がサポートされました。Auroraの リリースノート もご確認ください。 2/1(木) Amazon EC2の無料利用枠に750時間/月のIPv4アドレス利用を追加 2023年7月に発表したパブリックIPv4アドレスに対する新しい料金体系 が、2月1日より適用になりました。これと関係して、Amazon EC2のAWS無料利用枠に月間750時間のIPv4アドレス利用料が含まれるようになりました。 Amazon Monitronを静的IPアドレスベースで利用可能に Amazon Monitronは、センサーからのデータをゲートウェイデバイスを経由してAWSクラウドに安全に転送します。従来、ゲートウェイデバイスから”amazonaws.com”のサブドメイン全体に対して接続性が必要で、ファイアウォールの設定が難しいというフィードバックをいただいていました。今回、接続先が リージョン毎に異なる固定IPアドレス になり、ファイアウォールの設定が容易になりました。 Amazon Rekognitionでコンテンツモデレーションの新モデルを利用開始 Amazon Rekognitionでは不適切なコンテンツを検出する、コンテンツモデレーション機能を提供しています。今回、新しい機械学習モデルが導入され、精度向上とともにモデレーション結果として付与されるラベルが詳細化されました。また、アニメーションやイラストのモデレーションにも対応しました。 Amazon CognitoでフェデレーションにSAMLを利用するケースに向けた3つの新機能 シングルサインオンの実装にSAML標準によるフェデレーションを利用している場合に便利な3つの機能を発表しました。新たに、Amazon Cognito User Poolを利用して署名付きSAML認証リクエストを送信すること、SAMLのIDプロバイダに対して暗号化された応答を要求すること、IdP Initiated SSOへの対応、が可能になりました。 FinchがWindowsプラットフォームをサポート Finch はオープンソースのコマンドラインツールで、Linuxコンテナを構築・実行・公開するためものです。今回、macOSに加えてWindowsプラットフォームがサポートされました。開発者が複雑な環境を管理する手間をかけずに、コンテナをローカル環境で構築・管理できるようになります。 Amazon EC2 Capacity Block for MLがP4dインスタンスに対応 機械学習ワークロードを実行するためにEC2のキャパシティを予約できるAmazon EC2 Capacity Block for MLが、オハイオとオレゴンのリージョンにおけるP4dインスタンスの予約に対応しました。EC2 Capacity Block for MLでは、バージニア北部リージョンのP5インスタンスの予約にもご利用いただけます。 2/2(金) 大きなアップデートはありませんでした。 ソリューションアーキテクト 小林 正人 (twitter – @maccho_j )

Amazon SageMaker Canvas は、様々な機能を備えたコーディング不要の機械学習 (ML) と生成 AI ワークスペースです。見やすい画面とコーディング不要のインターフェースにより、世界中のお客様が ML テクノロジーをより簡単に採用し、いろいろな課題を解決できるようになりました。 これは、SageMaker Canvas が ML のワークフロー全体をカバーできていることに起因します。データの前処理やAutoMLの強力な機能、管理されたエンドポイントのデプロイ、簡略化された MLOps 機能、AWS AIサービスと生成 AI を活用したすぐに使えるモデルを利用者が探しているかどうかに関わらず、 SageMaker Canvas は目標達成を支援できます。 あらゆる規模の企業が SageMaker Canvas を採用するにつれ、お客様はコストの最適化の方法を求めてきました。 AWS Well-Architected Framework で定義されているように、コスト最適化されたワークロードは、すべてのリソースをフルに使用し、お客様の機能要件を満たし、可能な限り低い価格で成果を達成します。 この投稿では SageMaker Canvas アプリケーションのコストをより最適化する新しい方法を紹介します。 SageMaker Canvas は現在、アプリの使用状況とアイドル時間に関するインサイトを提供する Amazon CloudWatch Metrics を収集しています。 お客様はこの情報を使用して、意図しないコストの発生を避けるために自動的にアイドル状態の SageMaker Canvas アプリケーションをシャットダウンできます。 この投稿では、シンプルなサーバーレスアーキテクチャを使用して、アイドル状態のSageMaker Canvasアプリをシャットダウンしてコストを制御する方法を示します。 この投稿で使用されるテンプレートは こちらの GitHub で入手できます。 SageMaker Canvas のコストについて理解する オンプレミスまたはクラウドのどちらのワークロードでも、コストを理解し制御するためには、コストについて学ぶことから始まります。まずは SageMaker Canvas の課金モデル を確認することから始めましょう。 簡単に言うと、SageMaker Canvasには次の２つの側面に基づいた従量課金モデルがあります。 Workspace instance : 以前はセッション時間と呼ばれていたもので、SageMaker Canvas アプリの実行に関連するコスト。  AWSサービス料金 : モデルのトレーニング、エンドポイントのデプロイ、推論の生成といった SageMaker Canvas を起動するためのリソースに関連するコスト。 お客様は、SageMaker Canvasによって起動されるリソースを常に完全に制御することができ、AWS Billing and Cost Management Service を使用して、SageMaker Canvasアプリに関連するコストを追跡できます。 詳細については、「 SageMaker Canvasの課金とコストの管理 」を参照してください。 Workspace instance に関連するコストを制限するためのベストプラクティスとして、ブラウザタブは閉じずにログアウトをする方法があります。ログアウトするには、SageMaker Canvas アプリの左パネルにある ログアウトボタン を選択します。 自動で SageMaker Canvas アプリケーションをシャットダウンする SageMaker Canvasアプリケーションを自動的にシャットダウンしてコストを抑えたいIT管理者は、次の2つのアプローチをとることができます。 スケジュールに従ったアプリケーションのシャットダウン（毎日 19:00 または毎週金曜日 19:00） アイドル状態のアプリケーションの自動シャットダウン（アプリケーションが 2 時間使用されていない場合） スケジュールに従ったアプリケーションのシャットダウン スケジュールに従った SageMaker Canvas アプリケーションのシャットダウンは、Amazon SageMaker API である DeleteApp を呼び出すコンピューティングコンポーネント (AWS Lambda 関数) である cron 式 (Amazon EventBridge Cron ルールを使用) を使用することで、ほとんど手間をかけずに実行できます。このアプローチについては、「 AWS CDKとAWS Service Catalogを使用したAmazon SageMaker Canvasの機械学習環境のプロビジョニングと管理 」の記事で説明されており、こちらの  GitHub リポジトリ で実装が公開されています。 上記のアーキテクチャの利点の 1 つは、SageMaker Canvas アプリケーションの定期的な作成をとても簡単に複製できることにあります。定期的な作成と削除を組み合わせることで、ユーザーが業務を開始する時間帯（例 : 営業日の AM9:00）にSageMaker Canvas アプリケーションを立ち上げ、ユーザーが業務を終了する時間帯（例 : 営業日の PM7:00、週末は常にシャットダウン）に自動で SageMaker Canvas アプリケーションを削除することを確実にしておくことができます。必要なことは、 DeleteApp API を呼び出すコード行を CreateApp に変更することと、アプリ作成時間を反映するように cron 式を更新することだけです。 このアプローチは実装とテストが非常に簡単ですが、欠点としてアプリケーションが使用されているかどうかを考慮せず、アクティビティステータスに関係なくアプリケーションをシャットダウンしてしまうことです。セッションが突然終了するかもしれないため、アクティブユーザーと軋轢が生じてしまう可能性があります。 このアーキテクチャに関連するテンプレートは、 次の GitHub リポジトリ から取得できます。   アイドル状態のアプリケーションの自動シャットダウン 2023/11/24 から新たに、Amazon SageMaker Canvas はアプリケーションの使用状況とアイドル状態に関するインサイトを提供する CloudWatch Metrics を出力するようになりました。これにより、管理者はアイドル状態メトリクスを読み取り、しきい値と比較して自動シャットダウンの特定のロジックを定義するソリューションを定義できます。SageMaker Canvas によって出力されるアイドル状態メトリクスのより詳細な概要を次の段落に示します。 アイドル状態メトリクスに基づく SageMaker Canvas アプリケーションの自動シャットダウンを実現するために、AWS CloudFormation テンプレートを提供しています。このテンプレートは、次の 3 つの主要コンポーネントで構成されています。   Amazon CloudWatch Alarm はクエリを実行して TimesInceLastActive メトリクスの最大値をチェックします。この値が CloudFormation テンプレートの入力で指定されたしきい値より大きい場合、以下の残りの工程が自動で実行されます。このクエリは、単一のユーザープロファイル、単一のドメイン、またはすべてのドメインのどれでも実行できます。希望する制御レベルに応じて、以下を使用できます。 all-domains-all-users テンプレート。テンプレートがデプロイされているリージョン内のすべてのユーザーとすべてのドメインをチェックします。 one-domain-all-users テンプレート。テンプレートがデプロイされているリージョン内の 1 つのドメインのすべてのユーザーを対象にチェックします。 one-domain-one-user テンプレート。テンプレートがデプロイされているリージョンの 1 つのドメイン内の 1 つのユーザープロファイルについてチェックします。 アラーム状態が変更されると、Amazon EventBridge のデフォルトイベントバスにイベントが作成されます。このイベントバスには、AWS Lambda 関数をトリガーするように設定された Amazon EventBridge ルールがあります。 AWS Lambda 関数は、指定されたしきい値を超えてアイドル状態で稼働している SageMaker Canvas アプリケーションを特定し、 DeleteApp API を使用してそのアプリケーションを削除します。 このアーキテクチャに関連付けられた AWS CloudFormation テンプレートは、 次の GitHub リポジトリ から取得できます。 SageMaker Canvas のアイドル状態メトリックの仕組み SageMaker Canvas は /aws/SageMaker/Canvas/AppActivity 名前空間で TimeSinceLastActive メトリクスを出力します。このメトリックは、ユーザーが何の操作もしていないアプリケーションがアイドル状態であった秒数を示します。この新しいメトリックを使用して、SageMaker Canvas アプリケーションが一定期間アイドル状態になると、SageMaker Canvas アプリの自動シャットダウンをトリガーできます。SageMaker Canvas は、次のスキーマを使用して TimeSinceLastActive を公開します。 { "Namespace": "/aws/sagemaker/Canvas/AppActivity", "Dimensions": [ [ "DomainId", "UserProfileName" ] ], "Metrics": [ { "Name": "TimeSinceLastActive", "Unit": "Seconds", "Value": 12345 } ] } このメトリックの主要なコンポーネントは次の通りです。 Dimensions , 特に DomainId と UserProfileName  は全てのドメインとユーザーでアイドル状態になっているアプリケーションを特定することができる Value は SageMaker Canvas アプリケーションの中で最後のアクティビティからの秒数を示す。SgaeMaker Canvas は以下の操作をアクティビティがあったとみなす SageMaker Canvas アプリケーション内で行った全ての動作（例：ボタンを押下する、データセットを変換する、アプリ内で推論を行う、モデルをデプロイするなど） ready-to-use model を使用する、もしくはチャット画面を使って生成 AI モデルとやり取りをする 特定の時間にバッチ推論を実行するようにスケジューリングする（詳細については を参照） このメトリックは、 get_metric_data などの Amazon CloudWatch API を介して読み取ることができます。たとえば、Python 用 AWS SDK ( boto3 ) を使用する場合は以下となります。 import boto3, datetime cw = boto3.client('cloudwatch') metric_data_results = cw.get_metric_data( MetricDataQueries=[ { "Id": "q1", "Expression": 'SELECT MAX(TimeSinceLastActive) FROM "/aws/sagemaker/Canvas/AppActivity" GROUP BY DomainId, UserProfileName', "Period": 900 } ], StartTime=datetime.datetime(2023, 1, 1), EndTime=datetime.datetime.now(), ScanBy='TimestampAscending' )   Python クエリは DomainID と UserProfileName でグループ化した後、SageMaker Canvas に関連付けられた名前空間から TimeSinceLastActive  の MAX 値を抽出します。   自動シャットダウンソリューションをデプロイして試してみる 自動シャットダウンスタックをデプロイするには、以下を実行します。 上記の GitHub リポジトリから、実装したいソリューションを実装している AWS CloudFormation テンプレート をダウンロードしてください。ソリューションをすべての SageMaker Domainか、単一の SageMaker Domainか、単一ユーザー向けに適用するかを選択します。 以下のテンプレートパラメータの更新してください。 アイドルタイムアウト(idle timeout) — SageMaker Canvas アプリがシャットダウンされる前にアイドル状態でいられる時間 (秒単位)。デフォルト値は 2 時間です。 アラーム期間(alarm period) — CloudWatch Alarm がアイドルタイムアウトを計算するために使用する集計時間 (秒単位)。デフォルト値は 20 分です。 (Option) SageMaker Domain ID と ユーザープロファイル名 クラウドフォーメーションスタックをデプロイしてリソースを作成します。 クラウドフォーメーションスタックをデプロイしてリソースを作成します。 デプロイが完了すると (2 分もかかりません)、AWS Lambda 関数と Amazon CloudWatch アラームは、アイドル状態のときに Canvas アプリケーションを自動的にシャットダウンするように設定されます。自動シャットダウンスクリプトをテストするには、次の操作を行います。 SageMaker Canvas アプリが適切なドメイン内で適切なユーザープロファイル (設定されている場合) で実行されていることを確認してください。 SageMaker Canvas アプリの使用を停止し、アイドルタイムアウト期間 (デフォルトは 2 時間) を待ちます。 CloudWatch アラームがトリガーされ、自動化をトリガーした後に通常の状態に戻ったことを確認して、しきい値時間アイドル状態になった後にアプリが停止したことを確認します。 このテストでは、アイドルタイムアウト期間を 2 時間 (7200 秒) に設定しました。Amazon CloudWatch Metrics によってプロットされた次のグラフでは、アラームがトリガーされたしきい値 (1) に達するまで、SageMaker Canvas アプリが TimeSinceLastActive メトリクスを出力していたことがわかります。アラームがトリガーされると、AWS Lambda 関数が実行され、アプリケーションが削除され、メトリクスがしきい値 (2) を下回りました。     結論 この投稿では、AWS Lambda と CloudWatch Alarm と SageMaker Canvas から新たに出力されるようになったアイドル状態のメトリックスを使用して、アイドル状態の SageMaker Canvas アプリケーションの自動シャットダウンソリューションを実装しました。このソリューションにより、顧客は機械学習ワークロードのコストを最適化できるだけでなく、SageMaker Domainで実行されていたことを忘れてしまったアプリケーションへの意図しない請求を回避できます。 このソリューションによってお客様が安心して解決できる新しいユースケースやワークロードを楽しみにしています。SageMaker Canvasがビジネス目標の達成にどのように役立つかについてのその他の例については、以下の記事を参照してください。 Predict customer churn with no-code machine learning using Amazon SageMaker Canvas Amazon SageMaker Canvas の ML 予測を使用して Amazon QuickSight に予測ダッシュボードをパブリッシュ ノーコード機械学習のAmazon SageMaker Canvas を使用して、画像から製造品質欠陥の検出を誰でも簡単に行う方法 Use no-code machine learning to derive insights from product reviews using Amazon SageMaker Canvas sentiment analysis and text analysis models Empower your business users to extract insights from company documents using Amazon SageMaker Canvas Generative AI Amazon SageMaker Canvas を使用してプロダクションレベルのワークロードを実行する方法については、以下の投稿を参照してください。 ビルド、共有、デプロイ : ビジネスアナリストとデータサイエンティストが、ノーコード機械学習と Amazon SageMaker Canvas を使用して市場投入までの時間を短縮する方法 Retrain ML models and automate batch predictions in Amazon SageMaker Canvas using updated datasets Operationalize ML models built in Amazon SageMaker Canvas to production using the Amazon SageMaker Model Registry AWS CDKとAWS Service Catalogを使用したAmazon SageMaker Canvasの機械学習環境のプロビジョニングと管理 （訳者注：上記のブログ記事は、日本語に翻訳済のものは日本語の翻訳記事のリンクを掲載しています。原文を読みたい場合は、日本語の記事からのリンクを参照下さい。）   著者について Davide Gallitelliは、AI/MLのシニアスペシャリストソリューションアーキテクトです。彼はブリュッセルに拠点を置き、ローコード/ノーコードの機械学習テクノロジーとジェネレーティブAIの採用を検討している世界中の顧客と緊密に連携しています。彼は幼い頃から開発者として活躍し、7歳でコーディングを始めました。彼は大学でAI/MLを学び始め、それ以来ずっとAI/MLに夢中になっています。     Huong Nguyen は AWS のシニアプロダクトマネージャーです。彼女はSageMakerのデータエコシステム統合を主導しており、企業と消費者の両方の分野で顧客中心およびデータ主導型の製品を構築してきた14年の経験があります。     Gunjan Garg は AWS の Amazon SageMaker チームのプリンシパルエンジニアで、この製品の技術的リーダーシップを発揮しています。彼女は過去 5 年間、AI/ML 組織でいくつかの役職を歴任し、現在は Amazon SageMaker Canvas に焦点を当てています。     Ziyao Huang は Amazon SageMaker Data Wrangler のソフトウェア開発エンジニアです。彼は、お客様が ML を簡単に利用できるようにする優れた製品の開発に情熱を注いでいます。仕事以外では読書をしたり、友達と遊んだりするのが好きです。     本ブログはソリューションアーキテクトの辻浩季が翻訳しました。原文は こちら です。      

この記事は How to build a scalable, multi-tenant IoT SaaS platform on AWS using a multi-account strategy の日本語訳です。IoT Specialist Solutions Architect の新澤雅治 が翻訳しました。 IoT デバイスとサービスの相互作用を決定する IoT SaaS プラットフォームの構築を自分ではなく顧客が行う場合、単一のクラウドアーキテクチャをすべてのシナリオに最適化できないということがすぐにわかります。このブログ記事では、実際の顧客体験に基づいてマルチテナントの IoT SaaS プラットフォームを構築するための実装戦略と、オペレーションプロファイルの異なるデバイス群を 1 つの AWS アカウントに混在させることで生じる問題について紹介します。IoT SaaS プラットフォームのすべての顧客に共通のエクスペリエンスを提供しながら、AWS インフラストラクチャの境界と自動化機能を使用して顧客とそのデバイス群のセグメント化を可能にする手段を説明します。 はじめに モノのインターネット (IoT) の普及に伴い、多くのソリューション提供者は、既存のサービスとして Software-as-a-Service　(SaaS) と統合する IoT アプリケーションの構築と管理を望んでいます。 IoT デバイス群を含む SaaS サービスを検討する場合、そのアーキテクチャはテナント管理だけでなく、フリートの関連付けと隔離も考慮に入れる必要があります。このブログでは、 AWS Control Tower をマルチアカウント戦略とともに使用して、マルチテナントの IoT SaaS プラットフォームを実装するリファレンスアーキテクチャについて説明します。 アーキテクチャの設計には、さまざまなデプロイメントモデルを用いる方法がいくつかあります単一の Amazon Web Services (AWS) アカウントにデプロイすることも、 AWS アカウントの制限、テナントの隔離、リージョン固有のデプロイメント制限、またはその他のアーキテクチャ上の考慮事項のために、複数の AWS アカウントにまたがってデプロイすることもできます。 AWS でマルチアカウント戦略 を確立することは、新しいアプリケーションバージョンの迅速なテストとデプロイを可能とし、環境を安全に管理するのに役立ちます。マルチアカウントデプロイメントモデルは、特にクラウドワークロードがデバイスフリートの動作と一致する必要がある IoT ワークロードの技術的課題を解決します。これについては、次のセクションで詳しく説明します。 マルチテナント型 IoT SaaS プラットフォームの課題への対応 顧客がデバイスを作成して展開するマルチテナントの IoT SaaS プラットフォームサービスを構築する際には、実装を成功させるために解決しなければならない次のような課題があります。 データ分離n – マルチテナント構造では、 SaaS プロバイダーは、規制や顧客の要件に基づいてデータ分離境界をどのように設定するかを考慮する必要があります。IoT ワークロードの場合、多くのデバイスとゲートウェイがさまざまなデータタイプをさまざまなスキーマで接続して送信します。 AWS アカウントごとに境界を定義しておくと、さまざまなアカウントレベルのポリシーを設定できるため、クォータや個々の顧客フリートのニーズを管理しやすくなります。 データプライバシー – IoT は世界中で多くの業界で使用されています。さらに、データプライバシー規制は業界や地域によって異なります。テナントごとに要件に基づいて個別の IoT エンドポイントを用意することで、グローバル SaaS プラットフォームとして柔軟に運用できます。 デバイスプロビジョニングとオンボーディング – 現場で複数のセンサを束ねるルートデバイスの ID を変更することなく、デバイスを複数のテナント・エンドポイントにオンボーディングする戦略が必要です。 IoT セキュリティのベストプラクティス では、各 IoT エンドポイントで認証される固有の暗号化 ID を使用してデバイスをプロビジョニングすることを推奨しています。デバイスのルート ID のプログラミングと確立は、通常、製造時などのコントロールされた顧客環境で行われます。デバイスがグローバルサプライチェーンを経て現場に設置されるまでに数か月から数年かかる場合があります。製造時にデバイスの ID をテナントアカウントの IoT エンドポイントに緊密に結合してしまうと、柔軟性に欠けるサプライチェーンとなってしまいます。また、メーカーにとって SKU の断片化の原因にもなります。IoT エンドポイントへのデバイス ID のオンボーディングは、デバイスのライフサイクルの後半で行われる可能性があることを考慮する必要があります。 このブログのリファレンスアーキテクチャは、上記の課題に対処し、導入と運用を簡素化し、データガバナンスを強化します。 以下では、アーキテクチャの重要なポイントについて説明します (図 1)。 プラットフォーム作成の自動化 – 新しいテナントをオンボーディングすると、このアーキテクチャでは新しい AWS アカウントを作成し、テナント専用およびリージョン固有の AWS IoT Core エンドポイントを確立します。その後、新しいアカウントごとに、他の関連する AWS サービスとアプリケーションをデプロイします。この自動化されたプロセスは、データの分離、プライバシー、クォータ管理の課題の一部を解決するのに役立ちます。 デバイスのプロビジョニングとオンボーディング – 一元化されたオンボーディングサービスを使用して、IoT デバイスを要求し、指定されたテナント IoT エンドポイントにルーティングします。これにより、製造時のテナント固有のデバイスプロビジョニングの課題やテナントバインディングの遅延を解決できます。 図 1 — AWS アカウントレベル別の IoT マルチアカウントアーキテクチャの概要 AWS Control TowerとAWS Service Catalog を使ったテナント環境構築の自動化 自動化とスピードは、より良いカスタマーエクスペリエンスの鍵となります。特に、テナントのオンボーディングの際には、 AWS Control Tower と AWS Service Catalog を使用して、 AWS アカウント作成を含むテナントオンボーディングプロセスを自動化しましょう。これらのサービスは、顧客のプロセスを改善し、製品の市場投入までの時間を短縮します。 AWS Control Tower を有効にすると、Control Tower – Master という ランディングゾーン がリージョンにデプロイされます。AWS Control Tower は、監査アカウントとログアーカイブアカウントも作成します（図2）。AWS Control Tower は、セキュリティとコンプライアンスのリスクをスキャンするための設定、またはシステムコントロールを提供します。これらのコントロールは policy-as-a-code として管理し、新しく作成された AWS アカウントに適用することができます。 図2 – AWS Control Tower サービスコンソールの組織ビュー AWS Control Tower が有効になると、AWS Control Tower Account Factory を使用して新しい AWS アカウントを作成し、 IoT アプリケーション（エンドポイント）をデプロイできるようになります。 Account Factory は、新しい AWS アカウントの作成プロセスを自動化し、セキュリティとコンプライアンスのベストプラクティスのコントロールを適用します。また、アカウント作成プロセス中に AWS IoT Core を使用するテナントアプリケーションインフラをデプロイします。 AWS Control Tower コンソールを見ながら、主要な設定ポイントを理解していきましょう。 AWS Control Tower コンソールで、ナビゲーションペインの Account Factory を選択します。 Create Account ボタンを選択すると、Create account ページが表示されます。 このページで、アカウントマスターのメールアドレス、 AWS IAM Identity Center の識別情報、組織情報などのアカウントの詳細を指定します(図 3)。 図 3 – AWS Control Tower Account Factory でのアカウント作成 ページを下にスクロールして、 Account factory customization (AFC) セクションを見つけます。(図 4) このセクションでは、AWS アカウント作成後にデプロイする製品またはアプリケーションを指定します。 注：ドロップダウンリストに表示するには、すべての製品を Service Catalog 製品として登録する必要があります。Service Catalog 製品は自分でテンプレートを開発するか、構成済みのライブラリを使用して作成できます。詳細については「 Getting Started Library 」を参照してください。図のシナリオでは、製品は「テナント用 IoT アプリケーション」と名付けられ、製品として事前登録されているため、AFC はアカウント作成プロセス中にデプロイをトリガーできます。詳細については、「 Account Factory Customization （AFC）によるアカウントのカスタマイズ 」を参照してください。. 最後に、製品を配置する場所を選択します。Account Factoryは、ホームリージョン (AWS Control Tower を有効にしたリージョン） 、または ” All Governed Regions “にデプロイします。このシナリオでは、 ホームリージョン であるバージニア北部にデプロイします。 図 4 – AWS Control Tower の Account Factory Customization での設定 アカウント作成後、AWS Control Tower に登録・管理されているアカウントが表示されます。 図 5 — AWS Control Tower によってデプロイおよび管理される AWS アカウントのリスト、組織構造、およびアカウント作成に使用されたブループリント (テンプレート) テナントアカウントへの IoT デバイスのプロビジョニングとオンボーディング IoT アプリケーションがデプロイされた AWS アカウントが用意できたので、次にデバイスのプロビジョニングとオンボーディングに移りましょう。製造中のデバイスプロビジョニングを個々のテナントアカウントから切り離すために、AWS Control Tower を使用して、専用の AWS アカウント内に集中化されたデバイスオンボーディングサービスを作成します。このシナリオでは、QR コードを使用して IoT デバイスを AWS IoT Core にオンボードする方法を提供する 「Device Lobby」 リファレンスアーキテクチャを使用します。 図 6 – AWS Device Lobby アーキテクチャ ビルやキャンパスの物理的なロビーが訪問者のための公開エントランスポイントを提供するのと同様に、 IoT Device Lobby は、バインドされていない IoT デバイスのための AWS へのエントリーポイントを確立します。このアプローチにより、テナントデバイスの柔軟なオンボーディングが可能になり、クレーム処理を通じてユニークなデバイス識別子をテナントの IoT コアエンドポイントに関連付けます。サービスがデバイスをクレームすると、 Device Lobby サービスアカウントは、定義された MQTT トピックを介してテナントの AWS IoT Core エンドポイントにデバイスを送信するルーティング層として機能します (図 7) 。 このアーキテクチャは、デバイスのライフサイクル中のいつでも、テナントによって製造されたデバイスがそのエンドポイントにルーティングされることをサポートします。また、IoT Device Lobby アーキテクチャーは、デバイスを再プロビジョニングすることなく、あるリージョンやアカウントから別のリージョンまたはアカウントに移行することもサポートします。この状況では、サービスは Device Lobby サービスをホストする中央エンドポイントと、製造時にプラットフォームまたはテナントの公開鍵基盤（PKI）に基づく固有の認証情報でデバイスをプロビジョニングします。 詳細については、 IoT Device Lobby Architecture を参照してください。 図7 – Device Lobby アーキテクチャによる IoT デバイスのルーティングとテナントアカウントへの登録 Device Lobby アーキテクチャをデプロイするには、サービスをホストする専用の AWS アカウントを作成します。Device Lobby サービスのインスタンスは1つしか必要ないので、デプロイガイドに従って直接専用アカウントにデプロイできます。必要に応じ、AWS Service Catalog から製品を作成することにより、開発、テスト、ステージングアカウント全ての環境で同じ構成を実行できます。詳細については、 Device Lobby Configuration を参照してください。 図8 – サービスカタログに追加された Device Lobby サービス製品 IoT SaaS プラットフォームの Device Lobby サービスアカウントを確立したら、テナント IoT アプリケーションのアカウント設計図には、クロスアカウント信頼ポリシーを含める必要があります。このポリシーにより Device Lobby サービスがデバイスを登録し、テナントアカウントの IoT エンドポイントに接続できるようになります。 Device Lobby を使用することで、IoT SaaS プラットフォームは任意のテナントアカウントやリージョンにデバイスをオンボードする際の柔軟性が大幅に向上し、デバイスを特定の単一テナントアカウント用にプロビジョニングする必要がなくなります。デバイスの構築と現場への配備には時間がかかるため、このアプローチでは既存のデバイス SKU を再利用できるため、顧客の IoT 導入を大幅に加速できます。また、このソリューションは、デバイスのサプライチェーンにおける規模の経済性を高めることにもつながります。 まとめ この投稿では、IoT SaaS プラットフォームが、複数の顧客の IoT デバイス群をホスティングする際に、データの分離、プライバシー、サービスクォータ管理の課題にどのように対処できるかについて説明しました。AWS Control Tower は、 SaaS プラットフォームを構成する可能性のある複数のアカウントを管理するための手作業や潜在的にエラーを起こしやすいプロセスを取り除くのに役立ちます。テナントの IoT ワークロードをホストする複数の AWS アカウントへのデバイスオンボーディングを、Device Lobby アーキテクチャのような一元化されたサービスで管理できます。さらに、マルチアカウント戦略を採用することで、IoT SaaS サービスを構成する各テナントの AWS アカウントで、個別のさまざまな顧客デバイスフリートをホスティングすることができます。これにより、テナント・フリート間の分離が向上し、テナントごとに異なるサービスのクォータとポリシーの管理が容易になり、 AWS 上でより堅牢でスケーラブルな IoT SaaS プラットフォームを実現します。 AWS Control Tower の詳細については 、AWS Control Tower Workshop をご覧ください。 AWS IoT サービスを始めるには、 AWS IoT Immersion Day Workshop をご覧ください。 著者について Tomo Sakatoku シアトルの Amazon Web Services のプリンシパル・エンタープライズ・アーキテクトです。顧客と協力して困難な問題を解決することに情熱を注いでいます。また、趣味はテニスと家族旅行です。 Ben Cooke テキサス州オースティンの Amazon Web Services のシニア IoT ソリューションアーキテクトです。IoT システムアーキテクチャに注力しています。趣味は、家族とのアドベンチャーやガレージでの物づくりです。 <!-- '"` --> この記事は Ben Cooke と Tomo Sakatoku によって書かれた How to build a scalable, multi-tenant IoT SaaS platform on AWS using a multi-account strategy の日本語訳です。この記事は ソリューションアーキテクト の新澤雅治が翻訳しました。

クラウドのマイグレーションとモダナイゼーションは、時間がかかり複雑で、常に進化し続けるプロセスです。それにもかかわらず、マッキンゼーの調査では、お客様はクラウドにかける予算と移行を計画しているアプリケーションの数を増やしていることが示されています。マイグレーションおよびモダナイゼーション プロジェクトが複雑になる理由は3つあり、第１に、不揃いかつその場限りのソリューションに依存するため、関係者とのコラボレーションが煩雑になる可能性があることです。第 2 に、お客様には絶えず変化する最新技術に追従することに慣れていない場合があります。最後に、お客様は移行プロセス全体の管理を怠って、個別のタスクに気を取られてしまう場合があり、移行プロセス全体のタスクパイプラインの管理を無視することがあります。これらの課題の影響は、以下の図1に示すように、440人を超える経営幹部を対象にマッキンゼーが行った調査のデータから明らかになっています。 このブログ記事では、 AWS Migration Hub Journeys を紹介し、コラボレーション、計画、実行など、複雑なマイグレーションとモダナイゼーションに関連する課題にどのように対処するかを紹介します。 図 1: マッキンゼーの調査チャート AWS Migration Hub Journeys の紹介 今日、お客様はマイグレーションとモダナイゼーションに向けたタスクを実行するため、最新かつ信頼できるガイダンスを探すのに多大な時間を費やしており、移行タスク管理が非効率性と不確実性につながっています。 AWS Migration Hub Journeys は、AWS への移行を成功させるための手順とガイダンスを提供することで、移行タスクの実行と追跡を容易にします。Migration Hub Journeys は、移行フェーズごとにすべてのタスクを階層化し、簡単に実行できるようにそれらをサブタスクに分割しています。また、サブタスクごとに段階的な実行手順書が提供されるため、プロジェクト計画に必要な時間が短縮され、クラウド エキスパートへの依存が軽減されます。ユーザーは必要に応じてタスクを柔軟に編集または追加できます。AWS Migration Hub Journeysは、特に移行に関する自動化作業と手動作業に関するコラボレーションを容易にします。 ユーザーは、個々のタスクの結果として作成された成果物を、一元的に保存して、後で参照することができます。大規模な移行を追跡する際、AWS Migration Hub Journeys は、追跡および警告システムを通じて問題が発生した場合に適切な AWS エキスパートに警告を発し、支援を求めます。AWS Migration Hub のMigration Hub Journeysを利用することで、AWS への移行にかかるコストと時間を全体的に削減できます。 以下の図 2 は、AWS Migration Hub Journeys が移行を開始するにあたりどのように役立つかの概要を示しています。 図 2 : AWS Migration Hub Journeys マイグレーション・ジャーニー AWS Migration Hub Journeys では、マイグレーション・ジャーニーの概念を導入しています。これらのジャーニーは、エキスパート、プロセス、ツールを集めて移行作業を効率化するためのプラットフォームです。これにより、構造化と体系化されたタスクパイプラインによって、移行の見通しを一変させます。下の図 3 は、AWS Migration Hub コンソール内のジャーニーの簡単な概要を示しています。これについては、本ブログで詳しく説明します。 図 3 : マイグレーション・ジャーニーの概念 Migration Hub には、マイグレーション・ジャーニーの作成に使用できるテンプレートが用意されています。これらのテンプレートは一般的な移行シナリオを表しており、ベストプラクティスに従っています。テンプレートからジャーニーを作成すると、フェーズ、モジュール、タスク、サブタスクがあらかじめ定義されているジャーニーを作成できます。 マイグレーション テンプレート マイグレーション テンプレートは、「典型的な」マイグレーション・ジャーニーのタイプ（例：DB2データを移行するジャーニーや、Windows OSアプリケーションを移行するジャーニー）を説明する構造化された文書です。これらには、移行プロセスを完了するために必要な一連のタスクがすべて含まれています。お客様は、自分のニーズに最も近いテンプレートを選択し、テンプレートの内容を新しいジャーニーにコピーしてから、自分の要件に合わせてジャーニーを更新することで、独自の移行プロセスを計画します。AWS Migration Hub には、リリース時に AWS のエキスパートとパートナーによって開発された多数のテンプレートが含まれています。また、お客様は独自のカスタムテンプレートを作成して、特定のニーズに合わせて繰り返し実行できる移行プロセスを確立することもできます。AWS Migration Hub Journeys から現在入手可能なテンプレートについては、下の図4を参照してください。 使い方 — Migration Hub Journey コンソールで、左側のメニューから[ Migration journey templates ]を選択します。 図4: マイグレーション・ジャーニー テンプレート 各テンプレートには、 AWS 移行方法 に沿ったフェーズが設定されており、各フェーズ内には、図 5 に示すように、移行手順をガイドするモジュール、タスク、サブタスクがあります。 使い方 — Migration Hub Journey コンソールで、左側のメニューから [ Migration journey templates ] を選択します。リストから任意のテンプレートを選択すると、その特定のテンプレートに対応する詳細情報が表示されます。 図 5: 一般的なマイグレーション テンプレート — 概要 マイグレーション・ジャーニー – フェーズ テンプレートからジャーニーを作成すると、各フェーズが利用可能になり、それらのフェーズの管理をジャーニー内で開始できます。図 6 は、選択したジャーニーを構成するフェーズを示しています。 使い方 — Migration Hub Journey コンソールから、Journey を選択します。ジャーニー内から、「 phases 」タブを選択します。 図 6: マイグレーション・ジャーニー — フェーズ マイグレーション・ジャーニー – タスク 以下の図 7 のタスクには、必要な手順とガイダンスが記載されています。場合によっては、タスクを完了するのに役立つ、またはタスクを完了するために必要となるツールに関する指示も記載されています。タスクを特定のタスク所有者に割り当てたり、完了タイムラインを指定したり、推定作業レベルと実際の作業レベルを把握したりできます。 使い方 — Migration Hub Journey コンソールから、Journey を選択します。ジャーニー内から、[ tasks ]タブを選択します。任意のタスクを選択すると、タスク内の詳細と編集可能な設定が表示されます。 図 7: マイグレーション・ジャーニー — タスクの詳細 マイグレーション・ジャーニー – サブタスク タスクを正常に完了するために、タスクの下位にサブタスクが集約されます (下の図 8) 。タスク(と複数のサブタスク）でコメントやファイルを共有することができるため、別のチームメンバーに割り当てて共同作業を行うことができます。依存関係は、タスクの完了を妨げるブロッカーとともにタスク内にリストされます。 使い方 — Migration Hub Journey コンソールから、Journey を選択します。ジャーニー内から「 tasks 」タブを選択し、編集するタスクを選択します。タスク内から、[ Subtasks ]を選択します。 図 8: マイグレーション・ジャーニー — タスク — サブタスク チームメンバーは、タスクおよびサブタスクにファイルを添付できます (図 9)。たとえば、タスクの完了に役立つ分析レポートを添付します。タスクの結果を含むファイルを添付することもできます。 使い方 — Migration Hub Journey コンソールから 、Journey を選択します。ジャーニー内から、[ Tasks ] タブを選択し、編集するタスクを選択します。タスク内から、[ Attached files ] を選択します。 図 9: マイグレーション・ジャーニー — タスク — 添付ファイル マイグレーション・ジャーニー – モジュール タスクはモジュールに割り当てられて編成されます (図 10)。モジュールは、特定の結果を達成するようフェーズ内のタスクを整理するために使用する論理的なコンテナです。 使い方 — Migration Hub Journey コンソールから、Journey を選択します。ジャーニー内から [ Modules ] タブを選択します。 図 10: マイグレーション・ジャーニー — モジュール マイグレーション・ジャーニー — 個人とチーム マイグレーション・ジャーニーには、移行プロセスのコントリビュータまたは管理者である個人とチーム（図11）を定義する機能も含まれています。ジャーニーの作成者は、自動的にそのジャーニーの管理者になります。 個人またはチームをコントリビュータまたは管理者としてスペースまたはジャーニーに追加するには、招待状を送信します。追加されるには、招待を受け入れる必要があります。また、招待を断ることもできます。 使い方 — Migration Hub Journey コンソールから、Journey を選択します。ジャーニー内から、[ Individuals and teams ]タブを選択します。 図 11: マイグレーション・ジャーニー — 個人とチーム AWS Migration Hub Journeys へのアクセス AWS を初めて使用し、クラウド移行の計画段階の初期段階にある場合は、AWSアカウント無しで AWS Migration Hub Journeys に直接アクセスするオプションがあります。AWS Migration Hub Journeys に直接アクセスするプロセスは、 AWS ビルダー ID を利用することで簡略化されます。 クリーンアップ マイグレーション・ジャーニーをクリーンアップする手順は、AWS Migration Hub Journeys コンソールからマイグレーション・ジャーニーが削除できます。下の図 12 に示すように、AWS Migration Hub Journeys の [ Migration journeys ] セクションから、ジャーニーの横にあるラジオボタンを選択し、右上の [ Actions ] ドロップダウンをクリックして [ Delete journey ] を選択します。お客様が確認し、追加の書面による同意を提供すると、そのジャーニーは完全に削除されます。 図 12: マイグレーション・ジャーニーの削除 まとめ AWS Migration Hub Journeys は、リアルタイムのガイダンスと効率的なコラボレーションによってマイグレーションとモダナイゼーションの両方のプロセスを合理化し、複雑な移行を総合的な移行プロセスにおける管理可能なタスクに変換します。お客様は、AWS Migration Hub Journeys の機能と利点を調べて、お客様やパートナーのプロジェクトに実装することを検討することをお勧めします。今すぐ AWS Migration Hub Journeys の能力を活用して、マイグレーションとモダナイゼーションのジャーニーを最適化し、よりスムーズで効率的なAWS移行を実現してください。AWS Migration Hub Journeys を採用することで、組織はマイグレーションとモダナイゼーションの複雑さを自信を持って乗り切ることができ、AWS での体験をより効率的かつ成功させることができます。 著者について Kalyan Vennelakanty Kalyan Vennelakanty は AWS のテクニカルプログラムマネージャーで、クラウドアプリケーションのデリバリーに豊富な経験があります。彼は新しいクラウドテクノロジーに取り組み、お客様の移行ニーズを満たすのを支援することに情熱を注いでいます。 Steven Koufoudakis Steven Koufoudakis は AWS のパートナーソリューションアーキテクトです。彼は新しいテクノロジーを扱うことに喜びを感じています。また、適切なテクノロジーを組み合わせてお客様のビジネスニーズを満たすお手伝いをしています。パートナーやお客様の AWS でのワークロードのマイグレーション、モダナイゼーション、最適化を支援することに情熱を注いでいます。 Steven Koufoudakis Mohan CV は、バージニア州北部に拠点を置く AWS の主任ソリューションアーキテクトです。大企業のマイグレーションとモダナイゼーションの分野で豊富な経験を持ち、データ＆アナリティクスを専門としています。Mohanは新しいテクノロジーの活用に情熱を注いでおり、お客様が独自のビジネスニーズに合わせてこれらのイノベーションをカスタマイズできるよう支援することに喜びを感じています。 この記事の翻訳はソリューションアーキテクトの須山健吾が担当しました。原文は こちら です。