はじめに お客様は 2008 年以来、AWS 上で SAP ワークロードを実行しており、これら SAP のお客様の多くは、ABAP を使用して SAP ビジネスプロセスを開発し強化してきました。多くのお客様のビジネスプロセスはカスタム ABAP コードに依存しており、社内またはパートナーを通じて ABAP 開発者のチームを持っています。しかし、ABAPと並行して機械学習や言語翻訳のような機能をAWSサービスで革新することは、従来は面倒でした。この摩擦を減らすために、我々は 2022年 11 月に AWS SDK for SAP ABAP のプレビューを発表しました。これにより、ABAP 開発者は、データフォーマットのマッピング、多くのポイント・ツー・ポイント接続の作成と維持、SAP と AWS のセキュリティモデルの統合を行うことなく、快適な ABAP プログラミング言語を使用して AWS サービスに接続することで、SAP ベースのビジネスプロセスを容易に近代化し、変換することができます。 このブログでは、AWS SDK for SAP ABAP をインストールして設定し、 Amazon Simple Storage Service (Amazon S3) のバケットに存在するオブジェクトをリストアップする ABAP プログラムの例を紹介します。 AWS SDK for SAP ABAP の使用方法に関する詳細については、 AWS SDK for SAP ABAP のコード例を参照してください。 アーキテクチャ SAP NetWeaver ベースの ABAP システムにインポートすると、AWS SDK for SAP ABAP は、ネイティブの ABAP コンストラクトを使用して AWS サービス API を簡単に利用するための一連の SAP ABAP クラスを提供します。開発者は、既存の SAP 機能を強化したり、新しいアプリケーションを開発するために、レポートやプログラムでこれらの ABAP ベースのクラスを使用することができます。例としては、請求書作成を自動化するためのインテリジェントなドキュメント処理、 AWS Translate を使用した言語翻訳、SAP とサードパーティアプリケーション間でファイルを交換するための Amazon S3 の使用などがあります。 前提条件 このウォークスルーを実施するには以下の前提条件が必要です： SAP NetWeaver ABAP 7.40 以上 AWS アカウント Amazon S3 バケットに保存されたファイル IAM セキュリティのベストプラクティス に従った IAM ロール SAP ABAP のための AWS SDK のための SAP 権限 ウォークスルー このブログでは以下のステップを説明します： AWS SDK for SAP ABAP のセットアップ AWS SDK for SAP ABAP の設定 サンプル ABAP プログラムの作成 1. AWS SDK for SAP ABAP のセットアップ このセクションでは、前提条件の確認、AWS SDK for SAP ABAP のダウンロード、NetWeaver ABAP システムへの必要な移送のインポートを行います。 SAP BASIS リリースと SAP Kernel には最低限必要なバージョンがあります。移送のインポートに進む前に、 前提条件 が完全に満たされていることを確認してください。AWS SDK for SAP NetWeaver ABAP は こちらからダウンロード できます。 AWS SDK for SAP ABAP は、200 を超える AWS サービス用の個別の ABAP 移送を含む圧縮アーカイブとして提供され、個別の移送ファイル（データと共同ファイル）が個別のサブディレクトリに格納されています。サブディレクトリには 3 文字の略称（TLA）があり、 ここ で確認できます。AWS SDK の移送はクライアントに依存しません。 コア移送は必須であり、SDK ランタイムコード、 AWS Security Token Service (AWS STS) 用モジュール、Amazon S3 用モジュールを含みます。残りの SDK モジュールはそれぞれ別の移送で提供されます。お客様のシステムで SDK のサイズを小さく保つために、各 SDK モジュールはオプションであり、お客様のビジネスアプリケーションに必要であればインストールすることができます。 AWS SDK for ABAP のインストールは、必要な移送をインポートすることで行われます。いつでも最新の移送をインポートすることで、SDK のパッチやアップグレードを簡単に行うことができます。必要なモジュールが特定されたら、コアモジュールとサービスモジュールのデータファイルと共同ファイルを DIR_TRANS の data サブディレクトリと co-file サブディレクトリにコピーします。トランザクションコード STMS を使用して、移送依頼をインポートキューに追加します。 以下のスクリーンショットでは、コアと AWS Translate に関連する移送がインポートキューに追加されています。 全ての移送を同時にインポートすることも可能ですが、移送を個別にインポートする場合は、最初にコア移送をインポートする必要があることに注意してください。Ignore Invalid Component Version オプションが選択されていることを確認してください。 移送のインポートには、選択したモジュールの数によって時間がかかる場合があります。移送が正常にインポートされると、STMS は緑または黄色のインジケータを表示します。 インストールに関するより詳細な情報は、 Installing the AWS SDK for SAP ABAP Developer Guide に記載されています。 AWS SDK for SAP ABAP のアンインストールは、アンインストール移送をインポートすること でも可能です。インストールプロセスと同様に、アンインストー ル移送はモジュールによってインポートされる必要があります。コアモジュールがアンインストールされると、インプリメンテーションガイド (IMG) を介して行われた以前のすべてのコンフィギュレーションも削除されることに注意する必要があります。 2. AWS SDK for SAP ABAP の設定 ABAP プログラムで AWS SDK for SAP ABAP を使用する前に、トランザクションコード /AWS1/IMG を使用して設定する必要があります。構成は、品質および生産 SAP システムに転送可能なカスタマイズ要求に保存されます。/AWS1/IMG トランザクションの実行に必要な権限については、 SAP オーソライゼーション を参照してください。コンフィグレーションは、大きく 4 つの一般的なカテゴリーに分類されます： 技術的前提条件 グローバル設定 アプリケーション設定 ランタイム設定 SAPGUI コマンドバーに /n/AWS1/IMG と入力し、Enter キーを押すと、AWS SDK for SAP ABAP のインプリメンテーションガイド(IMG)が表示されます。 AWS SDK for SAP ABAP Settings ノードを展開します。 2.1. 技術的前提条件 Technical Prerequisites ノードを展開します。プロファイルパラメータ icm/HTTPS/client_sni_enabled が TRUE に設定され、 AWS ルート CA 証明書 が SSL Client Standard PSE にインポートされているかどうかを IMG アクティビティ で確認します。 SAP システムが AWS 以外の場所で実行されている場合、SAP の Secure store and forward (SSF) メカニズムを使用して AWS Identity and Access Management ユーザーの資格情報（アクセスキー ID とシークレットアクセスキー）を暗号化するには、以下の追加設定が必要です。 Additional Settings for On-Premises systems を展開します。新しい GUI ウィンドウでトランザクションコード SE16 を実行して、SSF アプリケーションを定義します。テーブル名 SSFAPPLIC を入力します。以下のスクリーンショットのように新しいエントリを作成します。 IMGアクティビティ Set SSF Parameters を実行して、SSFアプリケーションの暗号化パラメータを設定します。 New Entries を選択します。前のステップで作成したSSFアプリケーションを選択し、 Save を選択します。 Hash Algorithm を SHA256 に、 Encryption Algorithm を AES256-CBC に変更します。その他の値はデフォルトのままにしておきます。 Save を選択します。 IMGアクティビティ Create PSE for SSF Application を実行します。 STRUST トランザクションコードに移動します。 SSF SSF Encryption for the AWS SDK for SAP ABAP を右クリックし、 Create を選択します。デフォルト設定を受け入れます。 IMG アクティビティ Assign an SSF application to the AWS SDK for SAP ABAP を実行します。新規エントリを作成し、SSFAPPLIC テーブルに作成した SSF Application ID を入力します。 2.2. グローバル設定 グローバル設定は、AWS SDK for SAP ABAP 全体の動作に影響します。 IMG ノード Global Settings を展開し、IMG アクティビティ Configure Scenarios を実行します。通常運用では、DEFAULT というシナリオを作成します。 DEFAULT シナリオとは異なる設定を行う災害復旧などのシナリオを追加できます。ほとんどのユースケースでは、DEFAULTシナリオで十分です。 作成した DEFAULT シナリオは、アクティブなシナリオとして設定する必要があります。IMG ノード Runtime Settings を展開し、IMG アクティビティ Active Scenario を実行します。DEFAULT シナリオを選択し、 Commit Scenario Change を選択します。 IMG ノード Global Settings を展開し、IMG アクティビティ Technical Settings を実行して、AWS SDK のグローバル構成を構成します。以下のスクリーンショットのように新規エントリを作成します。 2.3. アプリケーション構成 アプリケーション構成は、 SDK Profile と Logical Resource Resolver の作成で構成されます。 SDK Profile は、請求書や販売注文関連の機能拡張など、典型的なユースケースに必要なすべての設定をグループ化したものです。SDK Profile では、SAP システムのシステム ID（SID）やクライアント、ステップ 2.2 で設定したシナリオ、使用する AWS リージョン、認証方法などの SAP 設定を定義します。使用する認証方法は、SAP システムが AWS クラウドにあるか AWS 外部にあるかによって異なります。IMG アクティビティ SDK Profile を実行します。意味のある名前で新しい SDK Profile を作成します。この例では、 ZFINANCE という名前のプロファイルを作成します。左側のパネルから Authentication and Settings を選択します。新しいエントリを作成し、SAPシステムの詳細とAWSリージョンを入力します。この例ではus-east-1 AWSリージョンを使用します。認証方法は、以下のオプションのいずれかを選択します。 SAPシステムが Amazon Elastic Compute Cloud (Amazon EC2) 上で動作している場合、以下のスクリーンショットに示すように、認証方法として Instance Role via Metadata を選択します。 SAP システムがオンプレミスで稼働している場合は、認証方法として Credentials from SSF Storage を選択し、 Save を選択します。 Set Credentials を選択します。IAM ユーザーのアクセスキーとシークレットアクセスキーを入力します。 左側のパネルから IAM Role mapping を選択します。Logical IAM Role の名前を入力し、AWS IAM Administrator から提供された IAM ロールの Amazon Resource Name (ARN) を入力します。この IAM ロールは、必要な AWS サービスを呼び出す権限を持ちます。この例では、IAM ロールは S3 バケットに存在するオブジェクトをリストアップする権限を持っています。 Logical Resource Resolver は、ABAP プログラムでの AWS リソース名（S3 バケットなど）のハードコー ディングを防ぎ、DR（Disaster Recovery）のように AWS リソース名が DR AWS リージョンで異なる場合に役立ちます。IMG アクティビティ Logical Resource Resolver を実行します。意味のある名前で新しい論理リソースを作成します。この例では、 ZFINANCE_S3_RESOURCE という名前を使用します。左側のパネルから Physical Resource Mapping を選択し、ステップ2.2で設定したSAPシステム設定とScenarioに続いてAWSリソース名を入力します。この例では、ファイルを保存したS3バケット名を入力します。 次のスクリーンショットは、この例で使用する abap-sdk-demo という名前のS3バケットです。オブジェクトをS3バケットにアップロードするには、Upload.Amazon S3 Bucket uploaded with objectsを選択します。 2.4. ランタイムの設定 トラブルシューティングのためにトレースを有効にする必要がある場合は、IMG アクティビティ Log and Trace を実行し、必要なトレースレベルを選択することで実行できます。 3. サンプルABAPプログラムの作成 トランザクションコードを SE38 実行し、 zdemo_s3_listbuckets という名前のプログラムを作成します。内容を以下のABAPコードに置き換えます。このコードは、AWS SDK for SAP ABAP を使用して S3 バケットに存在するオブジェクトをリストします。正常に実行するためには、前のステップで SDK の設定を完了する必要があります。 REPORT zdemo_s3_listbuckets. START-OF-SELECTION. PARAMETERS pv_lres TYPE /aws1/rt_resource_logical DEFAULT 'ZFINANCE_S3_RESOURCE' OBLIGATORY. DATA(go_session) = /aws1/cl_rt_session_aws=>create( 'ZFINANCE' ). DATA(gv_bucket) = go_session->resolve_lresource( pv_lres ). DATA(go_s3) = /aws1/cl_s3_factory=>create( go_session ). TRY. DATA(lo_output) = go_s3->listobjectsv2( iv_bucket = CONV string( gv_bucket ) iv_maxkeys = 100 ). LOOP AT lo_output->get_contents( ) INTO DATA(lo_object). DATA lv_mdate TYPE datum. CONVERT TIME STAMP lo_object->get_lastmodified( ) TIME ZONE 'UTC' INTO DATE lv_mdate. WRITE: / CONV text30( lo_object->get_key( ) ), lv_mdate, lo_object->get_size( ). ENDLOOP. CATCH /aws1/cx_rt_generic INTO DATA(lo_ex). DATA(lv_msg) = lo_ex->if_message~get_text( ). MESSAGE lv_msg TYPE 'I'. ENDTRY. プログラムを実行すると、次の画像の例のような出力が表示されるはずです。出力には、S3バケットに存在するオブジェクトが一覧表示されます。 まとめ このウォークスルーでは、AWS SDK for SAP ABAP のインストールと設定方法、そしてわずか数行の ABAP コードで S3 バケットに存在するオブジェクトをリストアップする方法を紹介しました。AWS SDK for SAP ABAP を使用すると、SAP ABAP 開発者は、SAP ABAP 言語を使用してネイティブに AWS サービスのパワーを活用することにより、SAP ベースのビジネスプロセスを拡張し、変換することが容易になります。 詳細については、 AWS SDK for SAP ABAP のページ をご覧ください。 AWS SDK for SAP ABAP はこちらからダウンロード できます。 数千ものお客様が AWS for SAP を選択する理由については、 AWS for SAP のページ をご覧ください。 翻訳は Partner SA 松本が担当しました。原文は こちら です。

みなさん、こんにちは。ソリューションアーキテクトの杉山です。 今週も 週刊AWS をお届けします。 週刊AWSをご利用頂いているお客様より、次のような声をお伺いしました。チームで定期的に時間を取り、週刊AWSの記事を読む会を実施されているとのことです。とても嬉しく思うとともに、素敵なご利用方法だと思いました。 引き続きわかりやすい記事をお届け出来るように心がけていきます。ありがとうございます。 それでは、先週の主なアップデートについて振り返っていきましょう。 2023年9月4日週の主要なアップデート 9/4(月) 大きなアップデートはありませんでした。 9/5(火) Amazon Personalize simplifies implementation by extending column limits Amazon Personalize で、モデルをトレーニングする際のデータセットの列数上限を増やしました。Personalize では、独自のデータスキーマを利用してパーソナライゼーションモデルをトレーニングできます。独自のデータには、「 アイテムデータセット 」と「 ユーザーデータセット 」が含まれています。今回のアップデートで、アイテムデータセットの列数上限が、50 列から 100 列と 2 倍になりました。ユーザーデータセットでは、列数上限が 5 列から 25 列と 5 倍になりました。これにより、お客様はより多くのデータを Personalize に渡すことが出来、実験をより高速に実施しやすくなりました。 AWS SAM CLI announces local testing and debugging support on Terraform projects AWS SAM CLI を利用して、HashiCorp Terraform で定義された Lambda 関数と API Gateway を、ローカルでテスト、およびデバッグが出来るようになりました。これまでは、Terraform で実際に deploy して AWS 上で確認する方法がありました。今回のアップデートでローカルで作成したテンプレートファイル (.tf ファイル) を、ローカルのまま動作確認ができるようになり、より高速に確認と修正のサイクルを推進できるようになりました。Terraform のバージョン 1.1 以上でサポートされています。詳細は AWS Blog をご確認ください。 Amazon CloudWatch adds Amazon EKS control plane logs as Vended Logs Amazon EKS のコントロールプレーンログが、Amazon CloudWatch Logs における Vended Logs に分類されました。Vended Logs は、お客様に代わって AWS のサービスがネイティブに発行するログです。Vended Logs は利用料に応じて段階的に料金が割引になる仕組みがあります。例をあげると、CloudWatch Logs に格納する場合、初めの 10 TB は 1 GB あたり $0.76 です。10 TB を超えて、次の 20 TB を格納する場合、1 GB あたり $0.38 と安価になる仕組みがあります。詳細は 料金ページ をご確認ください。 9/6(水) Amazon CloudWatch Logs announces regular expression filter pattern syntax support Amazon CloudWatch Logs のフィルターパターン構文で正規表現がサポートされ、ログの検索やマッチングがより簡単になりました。ユースケースを一つ挙げると、ログ監視を行う際に、特定の文字列 (例 : statusCode=404) が出てきたとき、アラートとしてメールや Slack 通知などを行いたいことがあります。アップデート以前では、アラートの条件に正規表現が利用できなかったので、statusCode=404 や statusCode=405 といった複数の条件を指定しにくい場合がありました。今回のアップデートで正規表現を新たに利用できるようになったため { $.statusCode=%4[0-9]{2}% } といった柔軟な指定ができるようになりました。 Amazon SageMaker Inference now supports Multi Model Endpoints for PyTorch SageMaker Multi-Model Endpoint で、新たに PyTorch をサポートしました。SageMaker Multi-Model Endpoint は、1 つの SageMaker エンドポイントに複数モデルをデプロイすることで、コスト最適化のメリットがあるフルマネージド機能です。例えば、1000 個のPyTorch モデルを 1 つのエンドポイントにデプロイすることで、推論エンドポイントを共有でき、コストの最適化が図れます。 AWS Backup launches resource exclusion for AWS CloudFormation stack AWS Backup で AWS CloudFormation をバックアップする際に除外する機能が追加されました。AWS Backup に AWS CloudFormation で作成したスタックをバックアップ対象として指定できる機能があります。スタック単位でバックアップが出来るため、サポートしているコンポーネントを一括でバックアップする使い方が可能です。今回のアップデートで、スタックの中で特定のリソースをバックアップ対象から除外出来るようになりました。バックアップ対象をより柔軟に指定できるようになった形です。 9/7(木) Amazon Kendra releases Web Crawler for dynamic content support Amazon Kendra のウェブクローラーコネクタ v2.0 で動的なウェブサイトをサポートしました。ウェブクローラーコネクタでは、Web サイトの URL を指定しクローリングすることで、Kendra の検索対象に含めることができます。今回のアップデートにより、Angular、React、JavaScript などで動的にレンダリングされる Web サイトを、データ収集の対象としてサポートしました。 AWS Step Functions launches enhanced error handling AWS Step Functions でエラーハンドリングを行う際に、「動的なエラーメッセージの出力」や「リトライ間隔の調整」をしやすくなりました。「動的なエラーメッセージの出力」は、Step Functions で実行するなんらかの処理中にエラーが発生した際に、そのエラーメッセージを Fail アクションで動的に認識し、Step Functions 上のエラーメッセージとして出力できるようになりました。「リトライ間隔の調整」は 2 種類あります。1 種類目は、リトライを繰り返すエラーの際に最大遅延時間を指定できるようになりました。これにより、指数関数的なリトライを行う際に望ましい時間枠を指定できるようになりました。2 種類目は、リトライ間隔にジッタ―を追加できるようになりました。リトライを行う際にランダムな遅延を導入することで、同時リトライによる負荷の集中を回避しやすくなりました。 Amazon Detective adds Amazon EKS security investigations to AWS Workshop Studio 新機能のお知らせとは少々異なるのですが、過去リリースされた新機能を学習しやすくなったお知らせです。Amazon EKS で検出された脅威とセキュリティ調査結果に対して、Amazon Detective で効果的に調査する方法を Amazon Detective Workshop で学習しやすくなりました。Amazon Detective では EKS 監査ログを基に、操作履歴の可視化や、詳細な調査を支援する機能があります。例えば「セキュリティ侵害の兆候を示す Kubernetes ユーザーアカウントが呼び出した Kubernetes API メソッドは何か」といった内容を素早く確認できます。この機能の効果的な利用方法を学習するためのトピックが Workshop に追加されました。 9/8(金) Amazon SES email receiving service expands to 7 new regions Amazon SES でメールを受信する機能が、東京リージョンを含めた 7 つのリージョンで新たに利用できるようになりました。Amazon SES のメール受信機能は、Microsoft Outlook のような E メールクライアントを使って受信する方法とは異なります。ユースケース例をあげると、Amazon SES が受信したメールを自動的に保存したり、AWS Lambda や Amazon SNS を使ってなんらかの自動処理を行うことができます。例えば、お客様からの問い合わせのメールを Amazon SES で受信し、Lambda 関数を起動します。起動した Lambda 関数経由で問い合わせ内容を Slack 上に表示する、といったことが可能になります。 Amazon Route 53 now supports AWS-managed prefix lists for health checks Managed prefix lists で、新たに Route 53 のヘルスチェックをサポートしました。Managed prefix lists は、AWS で提供しているサービスに関連する IPv4 または IPv6 のアドレス範囲を定義したものです。ネットワークセキュリティを管理する上で便利な使い方が出来ます。使い方の例を挙げると、EC2 インスタンス上で Web サーバーを構成しているときに、Route 53 のヘルスチェックに限定してネットワーク通信を許可したい時があります。いままでは、セキュリティグループのインバウンドルールに、手動で Route 53 ヘルスチェックに関連する IP アドレスを設定することで実現できました。ただ、IP アドレス範囲が変更される可能性があり追従する手間がありました。今回のアップデートで Managed prefix lists で提供されているものを指定することで、Route 53 ヘルスチェックの最新の IP アドレス範囲を利用でき、通信許可を設定しやすくなりました。 AWS Backup announces support for Amazon Aurora continuous backup AWS Backup は、Amazon Aurora の 継続的バックアップ を新たにサポートしました。継続的バックアップを利用することで、1 秒以内の精度で選択した時間まで巻き戻してリストアができます。最大 35 日まで遡ることができます。継続的なバックアップは、最初にフルバックアップを作成し、トランザクションログを継続的にバックアップすることで実現しています。Amazon Aurora 側で、同様な機能の ポイントインタイムリカバリ がありましたが、AWS Backup 経由では管理ができませんでした。今回のアップデートで、AWS Backup を利用して Amazon Aurora の柔軟なバックアップリストアを管理しやすくなりました。 9 月 22 日 18:30 より、 AWS 秋の Observability 祭り が開催されます。Amazon CloudWatch を初めとした Observability 関連サービスの活用方法のご紹介や、NTTドコモ様、中外製薬株式会社様、株式会社デイトナ・インターナショナル様の事例発表があります。目黒オフィスで開催するリアルイベントとなっており、席に限りがある事前登録制です。この機会にぜひご登録ください。 それでは、また来週お会いしましょう！ ソリューションアーキテクト 杉山 卓 (twitter – @sugimount )

AWS Hybrid Cloud and Edge Computing サービスの導入は開発者に対してコンピューティングリソースおよびストレージへの低遅延なアクセスを提供し、AWSインフラストラクチャのグローバルな展開を急速に拡大しています。米国内だけでも、19個のAWS Wavelengthゾーンが一般提供されています。アプリケーションを展開する場所の選択肢が増えることにより、どの場所がアプリケーションリクエストにとって最適になるのかが新たな課題になっています。 エッジを意識したデプロイ: エッジディスカバリの原点は、効果的に地理分散したデプロイになります。カバレッジと低遅延アクセスを最適化したい開発者は、お客様の要件を満たすために複数のWavelengthゾーンにアプリケーションをデプロイする必要があります。自動的な決断メカニズムが大規模でエッジコンピューティング展開において極めて重要です。別の投稿では、この課題に対処するためのテクニック（例: Pod Topology Spread Constraints）について説明しました。 エッジディスカバリ: アプリケーションがデプロイされた後、特定のクライアントセッションに対する最適なアプリケーションエンドポイントを決定するための選択基準、方法論、またはアルゴリズムが必要です。これには通信遅延、利用可能なネットワーク帯域幅、ネットワークトポロジーなどが含まれて考慮する必要があります。 ドメインネームシステム（DNS）は、サーバーなどのリソースに到達するためのデファクトアプローチですが（例: myedgeapplication.com）、エッジコンピューティングに必要な精度と粒度が通信プロバイダ（CSP）ネットワーク内で常に提供されているわけではありません。たとえば、Amazon Route 53などのDNSサービスは、ロケーションベースのルーティングを提供しています。DNS名（例: myedgeapplication.com）は、ユーザーの地理的な位置に基づいてエンドポイントにルーティングすることができますが、基本的にはユーザーのDNSリゾルバのIPアドレスによって決定されます。 ただし、再帰的なDNSルックアップで使用されるIPアドレス（eDNSが有効でない限り）は、要求デバイスではなくそのDNSサーバーのIPアドレスになります。DNSサーバーの場所がクライアントがアタッチされているUPFの場所と一致しない場合、結果は不正確なマッピングになります。開発者には、リクエストを出すデバイスの場所をより詳細で正確な特定方法が必要です。 この課題を対処するために、この記事では、CSPが開発したエッジディスカバリサービス（EDS）APIを使用し、イベント駆動アーキテクチャと統合するリファレンスパターンを記載します。例として、この記事では、Verizon Edge Discovery Serviceを使用して、高度に分散したエッジコンピューティング環境でモバイルクライアント向けのダイナミックなワークフローを提供する方法を示します。 モバイルネットワークの基本 モバイルエッジ環境に接続する際、モバイルトラフィックはRadio Access Network（RAN）を介してルーティングされます。すなわち、LTE無線（eNB）または5G無線（gNB）およびパケットコアネットワークを介してルーティングされます。UEがモバイルネットワークにアタッチすると、LTEでは特定のPacket Gateway（PGW）、5GではUser-Plane Function（UPF）と呼ばれるノードとの接続が確立され、ユーザ端末（UE）のすべての入出力データトラフィックが処理されます。これにより、キャリアグレードのNAT（CG-NAT）が使用され、UEのトラフィックはプライベートモバイルネットワークからパブリックインターネットへと変換されます。 モバイルネットワークでは、UEはコアネットワーク内でアタッチされているLTE PGW（または5G UPF）との間で確立されたIPセッションを維持しながら、無線RANセル間でシームレスに移動し、ハンドオーバーすることができます。カバーエリアが失われた場合やUEが再起動した場合（デバイスをオンオフにした場合）、UEまたはネットワークは再アタッチをトリガーし、コアネットワークとのIPセッションを再確立します。したがって、モバイルハンドオーバーはWavelengthゾーンのネットワークトポロジー上の近さに影響を与えないケースがほとんどです。たとえクライアントが数百マイルを移動したとしても、地理的に最も近いWavelengthゾーンが変わったが、ネットワークトロポジー上最も近いWavelengthゾーンは変わりません。その結果、モバイルアプリケーションでは、現在接続しているエンドポイントが最適かどうかを定期的にチェックすることが推奨されています。 具体的な例を挙げましょう。ある朝、ニューヨーク市で電源を入れた4G/5Gデバイスがあると仮定します。このデバイスはニューヨーク市のPGWにアタッチされます。したがって、最も低遅延のWavelengthゾーンはニューヨーク市となります。このモバイルデバイスが2,000マイル西にあるデンバー市に移動したとしても、最も低遅延のWavelengthゾーンはニューヨーク市のままです。ネットワークに再アタッチしない限り、この状況は続きます。 デンバー市からは、クライアントはすべてのトラフィックをニューヨーク市のパケットコアを介して、キャリアのバックボーンを経由でデンバー市に戻ってきます。ジオロケーションベースのディスカバリはこの動きに影響を与えることはありません。これは、従来のCSPが設計した継続性と信頼性を重視する長寿命セッションの性質によるものです。ただし、5Gのネットワークでは、CSPはリアンカリングとセッションの継続性に対し、より大きな柔軟性が与えられています。したがって、この例で、今では最も近いWavelengthゾーンはデンバー市のになる可能性があります。 開発者を5Gネットワークの深い専門知識から解放するために、Edge Discovery API には使いやすいサービスメッシュが用意されています。これにより、5G ネットワークトポロジーに対応した方法を公開して、クライアントを最適なエッジコンピューティングゾーンにルーティングできます。Edge Discovery API は、ネットワークのパフォーマンス特性 (最大遅延、必要な帯域幅など) を考慮したユーザー定義のサービスプロファイルを使用して、トポロジー的に最適なモバイルエッジコンピュートノードを選択できます。この方法により、「最適な」エッジゾーンをどのように決定するかというロジックは、アプリケーション開発者から通信プロバイダにオフロードされます。 キャリア開発したEDSデザイン EDS は、データベース、キュー、マイクロサービス、その他のクラウドリソースなど、あらゆるアプリケーションリソースをカスタム名で登録できる API です。各カスタム名は ServiceEndpoints オブジェクトと呼ばれる一意の識別子で、通信事業者向けのアプリケーションサービスのエンドポイントメタデータで構成されます。各 ServiceEndpoint オブジェクトは、キャリアの IPv4 アドレス (AWS Wavelength では IPv6 は現在サポートされていません)、オプションとして FQDN 、ポート、およびその他のメタデータで構成されています。 モバイルクライアントが最適なエッジエンドポイントを特定しようとする場合、クライアントはまず、TURNサーバーやその他のツール（例: ifconfig.me）を使用してCG-NATパブリックIPを特定する必要があります。IPアドレスを特定した後、この値を必要なUEIdentity属性とともに指定されたserviceEndpoints識別子に渡すことで、最適なサービスエンドポイントを取得します。APIリファレンスについて詳しくは、「 5G Future Forum API specifications 」や「 5G EDS documentation 」を参照してください。 図1: EDSワークフロー EDSワークフロー 例として、VPC（10.0.0.0/24）に2つのサブネットがあり、各サブネットにはAmazon Elastic Compute Cloud（Amazon EC2）インスタンスが起動されています。各インスタンスにはキャリアIPアドレスがアタッチされています。 1) サンフランシスコWavelengthゾーン（us-west-2-wl1-sfo-wlz-1）CIDRレンジ10.0.0.0/26 キャリアIPアドレス: 155.146.21.144 2) ラスベガスWavelengthゾーン（us-west-2-wl1-las-wlz-1）CIDRレンジ10.0.0.64/26 キャリアIPアドレス: 155.146.118.11 図2: Amazon VPCアーキテクチャ EDSへのアクセス EDS を使用するには、まず API を認証してサービスプロファイルを作成する必要があります。このオブジェクトは、Edge アプリケーションに必要なリソースを記述し、EDS が応答する選定基準を定義します。注目すべきサービスプロファイルフィールドには、最小帯域幅、最大リクエストレート、最小可用性、最大遅延などがあります。 次に、ServiceEndpoints オブジェクトを一連のレコードとともにサービスプロファイルにアタッチします。ワークフロー全体の例として、サービスプロファイルとServiceEndpointsの関係を示した前の図を参考してください。 最後に、最適な Edge エンドポイントを特定したいモバイルクライアントの場合、API を認証して、選択した ServiceEndpointSid からエンドポイントを取得する必要があります。EDS から、サービスプロファイルで定義されている最適なエンドポイントのリストが回答されます。 EDSの拡張: 動的エンドポイントの更新 UEがEDS APIを呼び出す基本的な部分に加えて、開発者体験向上のための最適化ができます。例えば、EDS APIをAWSネイティブのワークフローと統合することで、エッジコンピュートサービスエンドポイントのマッピング管理を簡素化することができます。たとえば、図3は、3つ目のWavelengthゾーンが導入された場合に何が起こるかを示しています。手動で操作しなければ、Wavelengthゾーン3 に地理的に近い UE は適切にルーティングされません。これは、エンドポイントを登録するために EDS に対して新しいクエリを行わなければ、新しいロケーションがマッピングされないためです。 エンドポイントを動的に登録するソリューションを構築するために、次のAWSサービスを使用します。 Amazon EventBridge: AWSサービスからデータを取り込むサーバーレスのイベントバスを使用して、カスタムルールを設定して自動応答をトリガーできます。 AWS Lambda: AWS Wavelengthメタデータを抽出し、サードパーティのEDSを埋めるサーバーレス関数を作成できます。 AWS Systems Manager Parameter Store: EDSのAPI応答から、AWS Systems Manager Parameter Storeに必要な情報（例: serviceEndpointsIdおよび認証情報）をキャッシュすることができます。 Amazon EC2 Tag: 単一のアカウントから複数のエッジアプリケーションを管理できるようにするために、アプリケーションリソースに適切にタグを付け、Lambdaで選択される特定のタグを使用します。 図3: Amazon EC2を使用したエッジディスカバリアーキテクチャ 前述した動的なエッジディスカバリの手法は以下のワークフローに基づきます： デプロイ前に、アプリケーションリソースに使用する一連のAWSタグを事前に選択します。この例では、eds-data-plane-app-nameとcustomer-wavelength-appをそれぞれタグキーと値として選択しました。これらのタグは、EDS APIに自動的に登録されるリソースを一意に識別します。 次に、Amazon EC2ライフサイクルイベントに基づいた特定のルールを使用してEventBridgeを設定します。エッジ環境のすべての変更をキャプチャするために、最も確実な方法は、EC2インスタンスの実行・終了状態の変更を表すイベントを全てキャプチャすることです。イベントが検出されると、EventBridgeは関連するメタデータをキャプチャするためのLambda関数をトリガーします。 Lambda関数の第一部分では、現在実行中のEC2インスタンスで、タグ（ステップ1から）が一致するすべてのEC2インスタンスをAmazon EC2 APIから取得します。取得された各EC2インスタンスに対して、アタッチされたキャリアIPアドレスを抽出します。アタッチされたアドレスは、起動後にアタッチされる静的アドレス（Elastic IP）または起動時に割り当てられるエフェメラルIPアドレスとして表示される可能性があることに注意してください。 Lambda関数の第二部分では、EDS API に対して認証を行い、ServiceEndpoints オブジェクトに最新のエッジエンドポイントを設定します。これには、新しいレコードの作成や古いレコード (EC2 インスタンスの終了/停止など) の削除が含まれる場合があります。 EDSの現在の設計では、serviceEndpointsオブジェクトが更新されるたびに、新しいserviceEndpointsId識別子が返されます。AWS環境が最新のメタデータを持つことを確認するために、Lambda関数はAWS Systems Manager Parameter StoreにserviceEndpointsIdの最新値を書き込みます。 モバイルデバイスの観点からは、最も近いAWS Wavelengthゾーンのエンドポイントを特定するたびに、EDS APIを認証・クエリして、最適なエンドポイントを取得します。 EDSの応答に従い、モバイルクライアントはIPアドレスとポートまたはFQDNと直接接続できます。 EDSと自動スケーリング環境の統合 エッジアプリケーションのトラフィック量が多い場合、AWS Auto Scaling を使用してキャパシティを動的に調整し、スケーリングプロセスを管理できます。上記の例の環境が下記のように拡張されたと仮定します。 サンフランシスコWavelengthゾーン（us-west-2-wl1-sfo-wlz-1） インスタンス1：アタッチされたキャリアIPアドレス：155.146.21.144 インスタンス2：アタッチされたキャリアIPアドレス：155.146.21.135 インスタンス3：アタッチされたキャリアIPアドレス：155.146.21.128 ラスベガスWavelengthゾーン（us-west-2-wl1-las-wlz-1） インスタンス1：アタッチされたキャリアIPアドレス：155.146.118.41 インスタンス2：アタッチされたキャリアIPアドレス：155.146.118.32 インスタンス3：アタッチされたキャリアIPアドレス：155.146.118.2 図4：AWS Auto Scalingを使用したエッジディスカバリアーキテクチャ モバイルクライアントがEDS APIをクエリし、最適なエッジリソース名（ERN）がサンフランシスコWavelengthゾーン（us-west-2-wl1-sfo-wlz-1）である場合、APIレスポンスとしては3つのインスタンスIPアドレス（155.146.21.144、155.146.21.135、155.146.21.128）の間でロードバランシングしません。このシナリオでは、EDSは次の方法でDNSを併用すべきです： 高可用性を実現するために、各WavelengthゾーンにApplication Load Balancer（ALB）を作成し、各Wavelengthゾーンのインスタンスを対象グループとして設定します。例えば、サンフランシスコWavelengthゾーンにALBを構成し、上記の3つのEC2インスタンスを対象グループとして設定します。AWS Wavelengthでのロードバランスについて詳しくは、「 Enabling load-balancing of non-HTTP(S) traffic in AWS Wavelength. 」をご覧ください。 ドメイン（例：edgeapp.com）を取得した後、各Wavelengthゾーンのサブドメインを作成し、エイリアスレコードを使用してロードバランサーのFQDNを指定するようにします。例えば、sfo.edgeapp.comは、サンフランシスコWavelengthゾーンALBのFQDNに変換するようになります。 次に、EDS APIを設定します。servceProfileを作成した後、serviceEndpointsオブジェクトを作成し、エッジリソース名（ERN）ごとに単一のリソースレコードを設定します。この場合、2つのレコードがあります。サンフランシスコWavelengthゾーンERN（us-west-2-wl1-sfo-wlz-1）に対応するレコードと、ラスベガスWavelengthゾーンERN（us-west-2-wl1-las-wlz-1）に対応するレコードです。 前のシナリオでは、各リソースレコードに対してIPv4アドレスとポートが指定されますが、今回は、そのWavelengthゾーン内のALBの完全修飾ドメイン名が指定されます（上記ステップ4を参照）。UEからEDS APIをクエリする際、出力はALBのDNS名であり、IPアドレスではありません（ステップ7と8を参照）。 直接 vs. 間接的なエッジディスカバリ 現在、EDS API にはモバイルネットワーク内からだけではなく、パブリックインターネットからもアクセスできます。これにより、API の呼び出しが柔軟になり、特に EDS をモバイルクライアントから直接問い合わせるもしくは間接的に問い合わせるかを可能となります。 直接（クライアントサイド）： 特定のユースケースでは、開発者は簡素化を求め、各モバイルエンドポイントが直接EDSと対話するようにしたいのです。この例では、モバイルデバイスは上記のステップ6-7に従います。このアーキテクチャの「コスト」は 2 つあります。1 つは、数百 （もしくは数千）のデバイスが API キーのコピーを保持しなければならないセキュリティ上のリスクと、EDS への不必要に大量の呼び出しのことです。 間接（サーバーサイド）： 他の場合では、開発者はエッジディスカバリをAWSネイティブのエンティティに「オフロード」したい考えもあります。これはコンテナ化されたアプリケーションまたはLambda関数として存在し、モバイルデバイスはこのキャッシュ層との直接対話のみを行うようにします。このモデルの例については、MongoDB World 2022で紹介された「 real-time data architecture on Amazon EKS in AWS Wavelength .」をチェックしてください。この例では、ウェブアプリケーションにはJavaScriptを埋め込み、直接EDSと対話するサーバーレス関数を呼び出します。 結論 この記事では、エッジコンピューティング環境でEDSを使用して、地理的に分散した低遅延のアプリケーションに最適なエンドポイントを特定する方法を示しました。そして、AWSサーバーレスサービスがEDS APIを強化するアーキテクチャを紹介しました。さらに、EventBridgeとLambdaを介したサーバーレスワークフローが、Edge Discoveryアーキテクチャにエンドポイントを自動的に登録する方法も示しました。 エッジディスカバリは、エッジアプリケーションのウェルアーキテクチャーの重要なコンポーネントの1つです。詳しくは、 hands-on lab from re:Invent 2022 をチェックするか、re:Invent 2021の Verizon’s presentation on network intelligence セッションをご覧ください。 さあ、始めてみましょう。 Verizon EDS documentation または 5G Future Forum website をご覧いただき、Edge Specialist Sales Teamに質問してみてください。 著者について Robert Belson Robert は、AWS エッジコンピューティングを専門とする AWS ワールドワイドテレコムビジネスユニットのデベロッパーアドボケイトです。開発者コミュニティや大企業のお客様と協力して、自動化、ハイブリッドネットワーキング、エッジクラウドを使用してビジネス上の課題を解決することに重点を置いています。 本記事は、「 Deploying dynamic 5G Edge Discovery architectures with AWS Wavelength 」を翻訳したものです。 翻訳はソリューションアーキテクトの陳誠が担当しました。

2023 年 8 月 4 日に「 Amazon QuickSight Roadshow 東京 ～ QuickSight におけるデータドリブン経営、SaaS 組み込み、そして生成系 AI ～ 」を開催しました。真夏日に沢山の方々にお越しいただき、物理開催ならではの盛り上がりを再認識しました。丸一日かけて Amazon QuickSight に特化したコンテンツをお届けしました。本ブログでは各発表内容を紹介します。 オープニング・ Amazon QuickSight の最新アップデートを総まとめ！ アマゾン ウェブ サービス ジャパン合同会社 QuickSightシニア事業開発マネージャー 伊東 大騎 資料ダウンロード データの重要性が増す一方で、多くの企業がデータドリブン経営の実現に悩まれています。Amazon QuickSight はこれからのデータ活用に不可欠な要素を取り入れたBIツールで、クラウド・従量課金・モダンなユーザビリティといった土台の上にビルトイン AI ・組み込みアナリティクス・定型レポート・インメモリエンジン・ガバナンスといった先進的な機能を兼ね備えています。Amazon QuickSight は猛スピードで進化しており、この 2 年で 150 以上の機能をリリースしています。本セッションではこの 2 年近くであったリリースを総まとめしました。 NTTドコモのネットワーク事業における社内 QuickSight コミュニティの取り組み事例 株式会社NTTドコモ 無線アクセスデザイン部 エリア品質企画担当 中山 広実 氏 資料ダウンロード 全社員でのデータ活用の実現には文化やコミュニティの醸成が欠かせません。本セッションでは、NTTドコモのネットワーク事業における社内コミュニティの取り組みを紹介いただきました。ネットワーク事業ではネットワークの安定運用や品質向上を目的に全国のネットワークデータを分析しており、データ規模はテラバイト単位になります。この大規模データを分析者の目的ごとに異なる粒度・切り口で分析していますが、従来は Excel での作業が多く非効率であったため、Amazon QuickSight を使ったデータ分析の DX を目指しました。BI ツールのダッシュボード機能を通じて分析手法のノウハウを社内で広める、複数の大規模データを組み合わせた分析を気軽に行える環境を提供する、といった点にも着目しました。Amazon QuickSight の料金体系は利用者に Author として気軽に分析をしてほしいという要望と合っており、フルマネージドサービスであることから運用管理の手間が省け、AWS のデータベースと簡単に接続できる点が良かったです。 BI ツールの活用方法として、担当者がダッシュボードを準備して利用者は閲覧のみで活用するパターンがよくありますが、本取り組みでは分析したい人が Author として自由に分析できる環境を目指しました。なぜかというとネットワークの分析は定型化できないものが多く、データの種類と分析単位が多岐にわたるためです。また、よりデータの内容に精通している現場のネットワーク作業者が分析することで、新しい分析手法の発見に繋がることも期待しています。2022 年 4 月に本取り組みを開始し、今では 300 以上の Author と 3500 以上の Reader 閲覧にまで発展しました。 速いスピードで利用が広まった 1 つの理由にコミュニティ活動があります。社内コミュニティを通じてAmazon QuickSight の利活用を促進し社内認知を広めたいと考えました。また、ユーザー同士で相談しあえる場を作ることで運営側の問い合わせ対応の負荷を軽減できると考えました。今では全国各地のネットワーク担当者がコミュニティに参加しています。目指す姿はコミュニティの自走です。ユーザー同士で意見交換をし、質問に回答し、自主的に勉強会を開催する、という状態です。 まずは Slack での専用チャネルを設けることで気軽にコミュニケーションできるようにしました。導入当初は運営が何かを周知することにしか使われていませんでしたが、質問者にチャネルへの投稿を促し続けることで徐々に利用が活性化し、今ではコミュニティメンバーが運営よりも早く質問に回答してくれています。次が定期的な勉強会・事例共有会の開催です。レベル別のコンテンツを提供し、開催後には Slack 上で難易度のフィードバックを得るようにしています。事例では利用者が実際にどのように Amazon QuickSight を活用しているかを利用者から発信してもらっています。最近では普段の会議の中でも Amazon QuickSight で行った分析が共有されるようになりました。更には、特定の支店で生み出された分析手法を全国向けの会議で発表したことをきっかけに他支店へも広がっていくという理想的なノウハウ展開もありました。最後がダッシュボード作成イベントです。これを機に Amazon QuickSight 初心者でも実用的なダッシュボードを作成でき大好評でした。まずは使うきっかけを作ってあげることが大切と感じました。以上の取り組みより、コミュニティの活性化には交流の場を設けるだけではなく、粘り強く運用して広めていくことの重要性を学びました。 〜スタートアップ事例から学ぶ〜 ビジネスをのばす QuickSight の賢い使い方 アマゾン ウェブ サービス ジャパン合同会社 スタートアップソリューションアーキテクト 岸田 晃季 資料ダウンロード Amazon QuickSight はスタートアップのお客様でも活発にご利用いただいております。スタートアップがビジネスを成長させるためには、プロダクトをマーケットにフィットさせるための戦略をたてることが必要となりますが、そのためには以下のようなプロダクトのフィードバックデータを回収し、機能を見直すというサイクルを高速化することが求められます。ですが、人的リソースが不足しがちなスタートアップにとっては、手が回りにくい領域です。 そのようなスタートアップにとって、有用な選択肢としてあがるのが Amazon QuickSight となります。以下のスライドは、スタートアップの成長フェーズにそったスタートアップの課題を Amazon QuickSight でのアプローチと照らし合わせて整理した図です。Amazon QuickSight は、スタートアップにおける各フェーズの課題に対して、柔軟に対応できる機能を備えています。 当日では、上記のフェーズに合わせて初期・中期・後期のビジネスフェーズのカスタマーの事例を紹介させていただきましたが、こちらのブログでは初期フェーズの事例を抜粋して紹介いたします。こちらのケースでは、まだ分析基盤が無くリリースしたてのプロダクトを運用するフェーズのお客様の例です。ユーザーの利用状況を蓄積している Amazon Aurora などの RDBMS から、Amazon QuickSight のコネクターを利用して直接データにアクセスしており、初期フェーズでも十分実装可能なシンプルな構成です。ここでは、Amazon Aurora 側のパフォーマンスへの影響が懸念されますが、Amazon QuickSight の SPICE というインメモリエンジンを利用することで、データを SPICE に取り込み Amazon Aurora 側への影響を軽減することができます。もし、画像を Amazon QuickSight 上で表示したい場合は、画像を Amazon S3 などでホスティングする形で、Amazon QuickSight のカスタムビジュアルコンテンツを利用して画像を参照することも可能です。 このように、Amazon QuickSight ではデータ分析基盤にリソースを割くことが難しいような初期フェーズのお客様でも手軽に構築できる機能が備わっております。加えて、Amazon QuickSight 自体はサーバーレスの構成、かつユーザーごとの従量課金制ですので、小さくはじめるスタートアップにとっても有用な選択肢となっております。他事例などの詳細は、別途公開されている資料をご参照ください。 QuickSight のコスト、管理していますか？新機能を用いたコスト管理のコツ アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 溝渕 匡 資料ダウンロード Amazon QuickSight の利用が進むと想定どおりに使用されているか、コスト観点で気になってくると思います。コストの詳細を見るという点では Cost Explorer や AWS 使用状況レポートでは十分とは言えず、コストと使用状況レポート ( CUR ) にて確認が必要になってきます。しかし、CUR に表示される Amazon QuickSight のコスト情報は、次のように十分とは言えない状況が続いていました。 こうした問題への対応として、CUR で取得できる Amazon QuickSight に関する情報が増えました。 このアップデートにより、ユーザーレベルのコスト情報を用いた利用の妥当性評価 (全員分析を掲げた時、実際に全員が分析しているかなど) やコスト予測、コスト効率 (作成者に関するコスト比率から、生成したレポートやダッシュボードの価値を見るなど)、またセッション別のコストなどコストを基点とした様々な分析が可能になりました。CUR は Amazon QuickSight に簡単に取り込むこともでき、そうした情報についてもお伝えしました。詳細は資料をご覧ください。 QuickSight のユーザーコミュニティ活動のご紹介 ディップ株式会社 DX事業本部 プロダクト開発部データストラテジー課 課長 豊田 晋也 氏 資料ダウンロード Amazon QuickSight にユーザーコミュニティがあるのをご存知でしたか？本セッションではユーザーコミュニティの運営メンバーより活動の背景と内容を紹介いただきました。Amazon QuickSight ユーザーとしてもっと発信したい、ユーザー目線での情報を収集したい、データをビジネス価値にするための工夫を知りたい、といったことを目的にユーザー主導で交流の場を設けています。記念すべき イベント第一回が 2023 年 7 月 14 日 に行われ 100 名近くにライブ視聴いただきました。今後も活動を展開していくにあたり、運営メンバーと登壇者を募集しています！気軽に参加いただける集まりです。 Dive Deep パート1：QuickSight におけるアセット管理 アマゾン ウェブ サービス ジャパン合同会社 QuickSightソリューションアーキテクト 坂下 和香奈 資料ダウンロード Amazon QuickSight で作成したアセット（データセットや分析、ダッシュボード）が増えてくると、アセットの管理が重要になります。開発環境から本番環境への移行、バックアップやリストア、SaaS 環境での各テナントへのダッシュボードへの提供など、簡単にスムーズに実施できることが求められます。坂下から、昨年末よりリリースされたアセット管理の API / CLI について、発表させていただきました。 昨年末までの Amazon QuickSight においては、アセット管理において、「簡単にダッシュボードの生成ができない」「テンプレートを使用したバックアップやインポート・エクスポートは効率的でない」といった課題がありました。 昨年の AWS re:Invent で発表された新しいAPI（ Assets as Code : AaC ) では、ダッシュボードや分析のビジュアル情報を JSON / YAML 形式で出力することができるようになりました。 これまで、分析やダッシュボードのバックアップ、移行に使用していた Template（テンプレート）について、まず確認しました。テンプレートでは、ビジュアル情報はスナップショットとして取得されますが、ビジュアルの内容変更はできません。テンプレートにはバージョン管理機能があり、使用するデータセットをプレースホルダとして切り替える機能をもっていますが、アカウント内での操作となるため、事業継続計画や災害復旧には利用できません。 ダッシュボードを、開発アカウント ( AWS Account A ) から本番アカウント ( AWS Account B ) に移行するフローになります。分析からテンプレートを作成し、それを移行し権限変更をした後、エイリアスを作成し、それをもとにダッシュボードを作成します。また、ダッシュボードを使用しているデータセットやデータソースなどのアセットも、各々定義を取得し、書き換えて、移行する必要があります。 Assets as Code ( AaC ) と呼ばれる新しい API になります。テンプレートとは異なり、テンプレートでできなかったことができるようになっています。 同じダッシュボードの移行を、Assets as Code ( AaC ) にて実施した場合のワークフローです。ダッシュボードからビジュアル情報を取り出し、それを利用して、本番アカウントでダッシュボードを作成します。ただし、データセットやデータソースなど依存アセットについては、テンプレートの時と手順は変わりません。 Assets as Bundle ( AaB ) と呼ばれる新しい API が今年 5 月に発表されています。この API は、Assets as Code ( AaC ) の機能拡張版であるため、できること・できないことは基本 AaC と同じですが、移行をよりスムーズにやれるよう、依存アセットも合わせて定義情報をエクスポート、インポートできるようになっています。 ダッシュボードの移行を、Assets as Bundle ( AaB ) にて実施した場合のワークフローです。 Template、Assets as Code ( AaC )、Assets as Bundle ( AaB )の比較になります。 シート対応とは、分析からダッシュボード公開時にシート選択が昨年末より可能になっており、分析とダッシュボードのシートが異なる場合の対応になります。また、Boto3 / CLI バージョンについては、移行元・移行先での API / CLI 利用時に、Boto3 / CLI バージョンを意識して利用する必要があるかどうかという比較項目になります。 用途や要件に応じて最適なものを選択すること、また、Assets as Code ( AaC )、Assets as Bundle ( AaB )はまだ新しい API で未完成な部分もあるので、今後の機能アップデートや拡張について敏感になることを、お伝えさせていただきました。 Dive Deep パート2：フォルダと API を活用したシングルアカウントでの複数環境運用 アマゾン ウェブ サービス ジャパン合同会社 シニアソリューションアーキテクト 宮﨑 太郎 資料ダウンロード Amazon QuickSight の利用が進むと開発のステージに対応した環境管理のニーズが発生します。本セッションでは、Amazon QuickSight を使用する場合の環境管理の選択肢についてお話しし、特にその中でも比較的簡単に始めることが可能なフォルダ機能を活用したシングルアカウントでの複数環境運用方法についてお話ししました。 ダッシュボード構築を進めると次第に関係者が増え、データセットや分析、ダッシュボードといったアセットへの変更で本番環境や業務運用への影響を出してしまうリスクが大きくなってきます。これを受け、活用が進んだ利用者様の多くでアセットの相互影響を少なくするための環境分離ニーズが発生しています。 Amazon QuickSight において環境分離を行う方法は大きく 3 種類となります。それぞれ、アカウントレベルで分離する方法、1アカウント内を名前空間で分離する方法、1アカウント内をフォルダで分離する方法です。 各パターンのメリットデメリットは様々ですが、今回は最もシンプルな分離方法であるフォルダ分離についてご紹介します。 フォルダを利用した分離に登場する権限管理要素間の関係はこちらの図のようになります。まず、アセットについてはそれぞれ開発・本番のフォルダに格納し、それらのフォルダに対し、操作が可能なグループとユーザを設定することでアクセス権を管理・制限します。 共有フォルダでの環境管理のイメージはこのような形となります。管理者・開発者・QA（品質保証）・ビジネスユーザー等のユーザーグループごとに開発・テスト・本番といった環境を表すフォルダへのアクセス権限を管理し、変更・検証が終わったアセットをフォルダ間で移動していくことによって簡易的な複数環境管理を実現します。 フォルダを利用した環境分離においては、フォルダ間でのリソース共有の可否を軸として大きく二つ × 利便性の観点で二つのかけ合わせにより 4 つの実装パターンを想定しています。 リソース共有パターンにおいては、データソース・データセットは環境間で共有し、最新のダッシュボードのみ環境間で共有していきます。こちらのパターンでは、環境間を移動する対象がダッシュボードに限定されるため管理がシンプルになるという利点がある一方、おおもとのデータソース・データセットを変更すると本番側にも影響が出てしまうという懸念もあります。 リソース分離パターンにおいては、リソース共有パターンの懸念となっていたポイントを解消し、データソース・データセットのレベルから環境を分離します。これにより、環境間で影響を与えることなく安全なアセット管理を行うことが可能です。一方で、リソース共有パターンと比較した場合にアセットを環境数分、ある種重複して管理する必要があったり、環境間リリースの際には手順が複雑化しがちであったりといった管理面での煩雑さがデメリットとなってきます。このような煩雑さについては、CLI / API の採用や手順の標準化等によりある程度軽減することも可能なため、規模が大きくなる場合にはプログラムによる管理も選択肢としてご検討ください。 ここまで実装パターンのご紹介をいたしましたが、大きくは「環境間でどこまでリソースを共有してよいか」を軸として考え、さらにその中で CLI / API での効率化の必要性をご判断頂くと選定の根拠が明確になるかと思われますので、参考にしていただければ幸いです。 最後にサマリとなります。Amazon QuickSight では必要とする要件・ユースケースに応じた複数の環境分離の選択肢があります。本セッションではその中でも手軽に分離が可能なフォルダ分離パターンについてご紹介しました。本パターンでは、主にデータの共有レベルが判断のキーポイントとなりますので、ご利用の形態に応じご検討ください。また、各操作については画面 ( GUI ) に加え、プログラム ( CLI / API ) での操作による運用自動化・効率化も可能となりますので、是非ご利用いただければと思います。 Dive Deepパート3：データセットパラメータでクエリーを最適化し、CloudWatch で測定 アマゾン ウェブ サービス ジャパン合同会社 QuickSightソリューションアーキテクト 坂下 和香奈 資料ダウンロード ダイレクトクエリーを使用して大規模なデータを、Amazon QuickSight 上で扱う場合パフォーマンスが危惧されます。Amazon QuickSight で大規模なデータを自由に利用させるより、データ管理者側でそれを制御できる機能「データセットパラメータ」が、今年 5 月に発表されました。坂下より、その機能紹介とデモ、さらにダッシュボードのロード時間を CloudWatch にて測定するデモを紹介させていただきました。 データセットパラメータは、データセット作成時に利用するパラメータで、主にカスタム SQL や計算フィールドで使用できます。作成されたパラメータは、分析のパラメータとマッピングすることにより、可視化時にその値を SQL 内に置き換えてくれます。 ユースケースとしては、主にクエリー作成の自由度が上がるため、データソース側の機能を引き出すようなより柔軟な処理が実現でき、パフォーマンスの改善につながります。それ以外にも、大規模データにてダッシュボードを作成する場合のデータセットとして汎用化させることができます。 デモでは、Amazon Athena 経由で Amazon S3 にある約 2000 万件のデータを、データセットパラメータを使用して航続距離上位フィルターしダッシュボードを作成するところをデモしました。 作成したデータセットパラメータ ( $top ) と、そのパラメータを利用したカスタム SQL 、さらにそのパラメータにリンクされた分析上のスライダーになります。 デモの中で、どのようなビジュアルクエリが Amazon Athena に送られていたかも確認しました。作成したカスタム SQL がサブクエリー化され、実行されていること、さらにデータセットパラメータ ( $top ) に、スライダーの値が入っていることが確認できます。 次に、公開されたダッシュボードがロードされた時間を、CloudWatch で確認するデモを実施しました。 データセットパラメータを利用すると、大規模データのダイレクトクエリ利用時にパフォーマンスを最適化できることが確認できましたが、現時点でいくつかの制限事項があります。その内容について、最後に確認させていただきました。 Amazon QuickSight を活用した大学 IR ダッシュボードサービス「 IRQuA 」サービス立ち上げ事例 ヴェルク株式会社 取締役 / アーキテクト 津久井 浩太郎 氏 社外向けソリューションで Amazon QuickSight を利用するユースケースもあります。ヴェルクでは IRQuA という大学向けデータ分析ソリューションを運営しています。大学 Institutional Research（ IR ）とは教育機関が自身の教育や研究の質、学生の成功、運営の効率性などの向上を目的にデータ活用することを示します。少子化による学生数の減少が進む一方で大学の数は増え定員割れが発生していることから、データを駆使した大学経営の効率化が喫緊の課題です。大学 IR におけるデータは変更頻度が高く分析しずらい形で保管されている傾向があり、かつ大学側にノウハウが不足していることから、従来のソリューションはワンオフ型で高額な傾向がりました。そこで、IRQuA はクラウド型かつ低コストで提供できる形とし、前提知識がなくても簡単に使いこなせ安価にデータ基盤を構築できることをコンセプトにしています。 既に IRQuA を導入した大学関係者から沢山の声が届いています。見やすい、直感的で簡単、専門家のノウハウが反映されている、価格が手頃、データをもとに議論が生まれるようになった、好きなときにデータを活用できるようになった、など。BI ツールの選定に関しては下記の理由で Amazon QuickSight を採用しました。評価段階ではお客様にも試していただきました。 下記はサンプルデータを使ったデモになります。志願倍率の経年推移、入学定員充足率、入学の歩留まり、など大学 IR にまつわるデータを使いやすい形に可視化して提供しています。大学によってはタブレットを使って執行部にダッシュボードを見せています。 当初は中小規模の大学を対象としていましたが、蓋を開けると大規模大学でもニーズがあることが分かりました。今後のビジョンとして大学の共通的なプラットフォームにしていきたいと考えています。IRQuA を通じて教職員同氏の横の繋がりを作ることで大学 IR をさらに広めていきたいと思います。 SaaS で QuickSight を活用するためのポイント 〜設計から運用まで〜 アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 高橋 佑里子 資料ダウンロード BI ツールである Amazon QuickSight を SaaS に埋め込むと、グラフのビジュアルなどの実装コストを省きながらエンドユーザーに SaaS 内のデータ活用機能を提供することができます。データ活用機能を提供することで、SaaS のエンドユーザーの満足度を高めることができると考えられます。本セッションでは、テナント間のアクセス制御が重要な SaaS で Amazon QuickSight を活用するポイントとして、SaaS に QuickSight を埋め込む場合のユースケース別のアクセス管理方法に重点を置いてお話しさせていただきました。 閲覧機能のみを提供するユースケースの場合、Amazon QuickSight 上でユーザーを作成して権限制御をする方法以外にも、Amazon QuickSight 上でユーザーを作成せずに匿名アクセスと行レベルセキュリティ機能を組み合わせることで閲覧者の権限制御を行うことができます。ユーザー管理が不要なので、簡単に始めることができるというのがポイントです。閲覧機能のみを提供したい場合には選択肢の 1 つにしていただけると幸いです。 生命保険会社の営業部門における予測分析のビジネス活用と得られた学び アクサ生命保険株式会社 営業戦略本部営業デジタル部パフォーマンスレポーティンググループ 寄主 奈美 氏 資料ダウンロード アクサ生命保険ではデータ基盤を全社で活用しており、標準 BI ツールである Amazon QuickSight のアクティブユーザー数も年々増加しています。パフォーマンスレポーティンググループでは全営業部門の成績データを用いて Amazon QuickSight 上にレポートを作成しています。このようにデータ分析の環境が整ってきたということもあり、次は予測分析を取り入れることにしました。 これまでも予測の作成は行っていましたが、Excel を使った手作業によるものであったため膨大な手間と工数が発生していたのと、担当者の経験と実績に頼り属人化していました。そこで、機械学習を駆使した予測作成に Amazon Forecast を使うことにしました。Amazon QuickSight にも ML Insight がありますが、今回は天気などの外部データも取り込むことで精度を高める狙いがありました。もちろん予測結果は Amazon QuickSight で可視化することで営業が活用しやすい形にしています。 データサイエンスや機械学習の知識・経験がない中でのチャレンジであったため試行錯誤の連続でした。まずは学習データを色々と試し、最初は思いつく限りのデータを投入しました。どうすれば精度を高められるか検証していく中で徐々に改善し、過去データの実績に対する予測値の評価で良い結果を得ることができました。次に、Amazon Forecast のローリングフォーキャスト機能を使うことで Predictor を再学習させることなく追加データから予測値を更新できるようにしました。これで予測を自動的に日時更新できるようになりました。 試行錯誤を経て Amazon QuickSight 上での Simulation Forecast が完成しました。従来は月末最終予測値にしか対応できていませんでしたが、Amazon Forecast で予測の自動化をすることで全期間の結果をタイムリーに Amazon QuickSight 上で分析できるようになりました。 この最新の予測レポートをより多くの営業に使ってもらうための工夫も検討しました。現状は Amazon QuickSight レポートへのリンクが複数ある、沢山ある中から関連するものを検索するのが大変、という課題がありました。そこで、社員全員が閲覧する社内イントラサイトにダッシュボードを組み込むことでストレスフリーなアクセスを実現しました。 本取り組みを通じて、まず予測作成の工数がゼロになりました。予測の精度は上がり、担当者の知見に依存することがなくなったため客観性も改善しました。そしてアクティブユーザー数も一気に増え、社員の2人に1人が利用しているという状況になりました。ダッシュボードが組み込まれたページ上に利用者アンケートを貼り付けることで満足度を調査できるようにし、ユーザーごとのアクセス状況を確認するダッシュボードから効果測定をしています。既により高精度な予測作成に取り組んでおり、Amazon SageMaker Canvas の検証も始めています。 ITでもデータサイエンスでもないビジネス部門が機械学習と予測分析にチャレンジしましたが、ビジネス部門で試行する良さが沢山ありました。慣れるのに時間はかかりますが、欲しいものをすぐに作れるというメリットがあり、現場業務に熟知しているのでより適確に投入データやアウトプットについて判断できます。そして別部門あるいは企業に依存することがなくなるのでより素早く進めることができます。 QuickSight のポテンシャルを引き上げる SageMaker Canvas 連携で実現するノーコード予測分析 アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 中島 佑樹 アマゾン ウェブ サービス ジャパン合同会社 アナリティクススペシャリストソリューションアーキテクト 佐藤 祥多 資料ダウンロード 中島と佐藤からは Amazon QuickSight に Amazon SageMaker Canvas で生成した機械学習（ ML ）モデルや予測結果を連携させる具体的な方法と得られるインサイトについて Demo (動画参照) を実施しました。 Amazon CEO Andy Jassy のこのメッセージは、機械学習の予測がもたらす価値を端的に表していると思います。予測という言葉は、機械学習のモデルが出力する、推論や分類や将来の数字など広い意味を含みます。昨今話題の生成系 AI が生成するテキストや画像もその結果です。機械学習はデータを収集学習するプロセスを自動化することにより顧客体験を半自動的に改善する仕組みを提供します。半自動と言っているのは、学習データを人手で付与することもあるからです。to B, to C に限らず IT システムがもたらす顧客体験の向上のために、従来の機械学習を使用しないシステムでは人手でアプリケーションを改修する必要がありました。この顧客体験の改善の半自動化によって、ビジネスにおける PDCA を素早く実施し、効果・価値を迅速に創出できるのです。 強力なビジネスインパクトを与える機械学習ですが、残念なことに、機械学習を実行できるデータサイエンスリソースは限られています。右の図は、機械学習におけるフライホイールです。顧客体験が向上されれば、より多くのユーザが利用します。ユーザが増えれば多くのデータ集まります。多くのデータが集まれば機械学習の予測はより精度が高く優れたものになるでしょう。そして、顧客体験が向上するのです。ここで、優れた機械学習アプリケーションを開発する人手が足りないことがボトルネックとなります。 この課題を解決するために Amazon SageMaker Canvas は生まれました。Amazon SageMaker Canvas を使用すると、Amazon QuickSight が対象とするビジネスアナリストやドメインエキスパートは、ML の経験がなくても、非常に正確な ML 予測を簡単に生成できます。Amazon SageMaker Canvasを使用すると、ビジネスアナリストはクラウドやオンプレミスのデータソースに簡単にアクセスしてデータをインポートし、特徴量エンジニアリング、モデル Selection、トレーニングを AWS の AutoML イノベーションにより実行します。Amazon SageMaker Canvas には重要な特徴が何かを分析する機能や What if 分析も含まれています。Amazon SageMaker Canvas には使用量ベースの価格設定があり、前払い料金やライセンスなしで、使用した分だけ支払うことができます。これにより、コード不要の ML ツールの総所有コストを大幅に削減可能です。 2023 年に入り、Amazon SageMaker Canvas の予測結果やモデルを Amazon QuickSight と共有する機能がサポートされました。従来は Amazon SageMaker Canvas の予測結果やモデルを Amazon QuickSight で分析するためには、予測結果を連携する仕組みを別途構築したり、システム管理者に手動でのファイル配置をお願いしたりする場合もありました。この機能より、ビジネスアナリストは Amazon SageMaker Canvas で生成された ML 予測やモデルを活用し、Amazon QuickSight のインタラクティブなダッシュボードで分析を充実させることができます。そして、このダッシュボードから得たインサイトを使用して、日々のデータドリブンな意思決定が加速します。 このセッションでは小売と広告のユースケースを用いて Live Demo を実施しました。詳細は動画をご覧いただけますと幸いです。 最後のまとめです。まず、本セッションではビジネスで予測することの価値を説明しました。未来を予測することでビジネス価値が創出される点を強調しました。また、ノーコード予測分析のソリューションとして Amazon SageMaker を説明しました。Amazon SageMaker Canvas を利用することでブロッカーだった専門的な人材の用意をすることなく機械学習のパワーを得られます。Amazon SageMaker Canvas と Amazon QuickSightを使ったデモとして小売データと広告データを使ったデモを実施しました。Amazon QuickSightを使うことで Amazon SageMaker Canvas で得られた予測を更に分析できることを説明しました。 キーノート：BI における生成 AI AWS, ASEAN AI/ML Specialist, Dr. Chomchana Trevai AWS, QuickSight Go-To-Market Lead for Asia Pacific & Japan, Michael Armentano 本セッションは非公開となりますが、関連する情報については こちらの Big Data Blog をご覧ください。 まとめ 本イベントでは Amazon QuickSight とデータ活用に関するトピックを満遍なくお届けしました。ユースケース別のセッションではデータドリブン文化を醸成するためのコミュニティ活動に関する事例や SaaS における BI ツールを駆使したデータサービスの価値についてご紹介しました。今後はますます AI の利活用が進んでいき、Amazon QuickSight と AWS の AI サービスを組み合わせることでビジネス部門が自発的に予測分析を取り入れることができます。更には、Amazon QuickSight における生成系 AI（ Generative BI ）の未来像もお見せしました。データ分析・可視化における全く新しい世界観がすぐそこまできています。今後も Amazon QuickSight の動向から目が離せません！ データ事業本部　事業開発　伊東 大騎

現在のミクロおよびマクロ経済の状況は、顧客の需要パターンの変化と相まって、サプライチェーンネットワークに持続的な圧力をかけています。 組織は、顧客の需要を満たすために、効率性と俊敏性の向上と、サプライチェーン機能を積極的に改善することを追求することが必須です。 サプライチェーン管理システムには、リソースとビジネスプロセスを調整するさまざまな機能が含まれています。 中でも需要計画機能は、効果的なサプライチェーン管理において重要な役割を果たし、タイムリーな在庫補充、生産能力管理の強化、最適な売上と収益を確保します。 以前、 AWS Supply Chain が サプライチェーンの可視性 を向上させてレジリエンスを高める方法について説明しました。 このブログ記事では、AWS Supply Chain の Demand Planning 機能について説明します。これは、変化する需要パターンやユーザー入力から継続的に学習することで正確な需要予測を可能にし、市場の状況に対応し、計画の正確性を高めるために開発された需要計画モジュールです。 需要計画プロセス 正確な需要予測は不可欠なものです。 予測が不正確だと、在庫の不安定化につながり、過剰在庫や在庫切れ、コストの増加、販売機会の逸失、顧客満足度の低下につながる可能性があります。 たとえば、過剰な予測を行うと余剰在庫が発生し、利用可能なキャッシュフローが減少し、保管コストが増加します。 過小な予測は在庫切れにつながり、顧客体験、顧客満足度、顧客損失に影響を及ぼします。 需要計画は組織の成功にとって極めて重要です。リソースをいつ、どこに、どのように割り当てるかが決まるため、リソースを過剰に増やすことなく顧客の要求を満たすことができます。 体系的な評価、予測、コラボレーション、定期的な見直しを通じて、サプライチェーン戦略と運用効率を形作ります。 一般的な需要計画プロセスには、次のカテゴリに要約できる一連のステップが含まれます。 データ統合：これは需要計画の基礎です。 これには、過去の売上データ、現在の注文データ、在庫レベル、およびその他の関連指標の収集が含まれます。 データソースには、エンタープライズリソースプランニング ( ERP ) システム、カスタマーリレーションシップマネジメント ( CRM ) ツール、外部の市場調査レポートなどがあります。 需要要因を総合的に把握するには、多様なデータストリームを統合することが重要です。 予測：データを収集して統合した後、統計モデルとアルゴリズムを適用して将来の需要を予測します。 予測は現在、経験的データと業界の知識を組み合わせていますが、機械学習（ ML ）が最大の改善の可能性を秘めている分野です。 コラボレーション：需要計画には、営業、マーケティング、財務、運営などの部門間のコミュニケーションとコラボレーションが含まれます。 さまざまなチームからのインサイトを集めることで、企業は統計的予測をマーケットインテリジェンス、プロモーション計画、戦略的イニシアチブと照合することができます。 この協調的なアプローチにより、予測が多くの意見を反映していることが保証され、予測の正確性と受容性が高まります。 継続的な見直しと調整：需要計画は反復的なプロセスです。 実際の売上データが入力されると、予測と比較されて差異が特定されます。 これらの不一致は、予測モデルを改善し、将来の予測を調整するために分析されます。 需要計画を定期的に見直し、調整することで、最新の市況と社内戦略を反映した適切なものに保つことができます。 4つのカテゴリーはそれぞれ他のカテゴリーに依存しています。正確なデータがなければ予測には欠陥が生じ、コラボレーションがなければ予測には深みがなく、継続的な見直しがなければ、最良の予測でさえ時代遅れになります。 このような相互接続性により、市場の現実とビジネスの願望の両方を反映して、プロセスが動的、正確、かつ関連性のあるものであり続けることが保証されます。 AWS Supply Chain には、次のような従来の需要計画を超えるメリットがあります。 自動化：Demand Planning 機能は、データ入力、計算、調整など、付加価値のない多数の手動タスクを排除します。 これにより、需要予測の作成時間を短縮し、手作業によるエラーを減らすことができます。 ML の力を活用：ML は過去の売上とリアルタイムデータ ( 未処理注文など ) を分析して予測を作成し、モデルを調整して精度を向上させます。 これにより、予測の精度が向上し、在庫が少なすぎる（ 在庫切れ ）または在庫が多すぎる（ 過剰在庫 ）リスクが軽減されます。 また、AWS Supply Chain では ML を使用して リードタイムの変動を検出 し、供給計画の精度を向上させています。 効率的なコラボレーション：他のチームメンバーとの合意を促進するアプリケーション内コラボレーション機能。 これにより、調整が改善され、より迅速な意思決定が可能になり、リスクが軽減されます。 次のセクションでは、需要計画プロセスの説明を基に、AWS Supply Chain がどのようにこのプロセスをサポートするかを説明します。 このセクションでは、プロセスの最初の 3 つの重要なフェーズ ( データ統合、予測、コラボレーション ) に焦点を当て、新規ユーザー向けのステップバイステップガイドを提供します。 これらのステップでは、AWS Supply Chain をシームレスにセットアップし、その高度な機能を活用し、お客様の需要計画アプローチを変革する方法を詳しく説明しています。 今後のブログでは、第 4 のカテゴリーである継続的な見直しと調整について詳しく説明し、業界のベストプラクティスに基づいて AWS Supply Chain との統合について詳しく説明します。 AWS Supply Chain の Demand Planning 機能の前提条件 AWS アカウントが必要です。 AWS アカウントをお持ちでない場合は、「 新しい AWS アカウントを作成してアクティブ化する方法を教えてください 」のアカウント作成手順に従ってください。 また、AWS Supply Chain のアカウントも必要です。 現在お客様でない場合は、 AWS Supply Chain のウェブサイトにアクセスして詳細を確認し、利用を開始してください。 Demand Planning の設定 最初のステップは、AWS Supply Chain データレイクへのデータ取り込みです。 データレイクは ML モデルを使用して異種で互換性のないデータを理解、抽出、統合データモデルに変換します。 管理者として、Demand Planning 機能に必要なデータエンティティを AWS Supply Chain データレイクに供給して、予測を生成してください。 AWS Supply Chain ユーザーガイド の AWS Supply Chain アプリケーションに必要なデータフィールド には、予測を生成するために必要なフィールドの完全なリストが記載されています。 より正確な予測を行うには、データセット内の追加項目の入力を確認する必要があることに注意してください。 これらのフィールドは、 AWS Supply Chain アプリケーションのオプションデータフィールド で説明されています。 データを取り込んだら、ユーザー権限を確認する必要があります。 管理者は、必要な数のユーザーを Demand Planningに追加し、必要なユーザー権限を管理するように指定できます。 新しいユーザーの招待は、権限が設定された後に送信されます。 画面の下部で、管理者は4つの権限レベル（ Admin、Data Analyst、Inventory Manager、Planner ）のいずれかを選択できます。 [ Permissions Role ] を選択したら、左側のナビゲーションペインで [ AWS Supply Chain ] を選択し、[ Get Started ] を選択して Demand Planning モジュールを起動します。 次のスクリーンショットは、予測生成の時間枠 ( 計画期間と呼ばれる ) を指定するステップを示しています。 予測間隔と、アプリケーションで予測計画を作成させたい間隔の長さを入力します。 今後 6 か月間の月次予測に関心がある場合は、[ Time Intervals ] として Monthly を選択し、[ Time Horizon ] に 6 を入力します。 次のステップでは、好みや予測のニーズに応じて予測の粒度を設定できます。 この画面では、サイト、チャネル、顧客の各属性を階層構造に基づいて選択し、予測するレベルを決定します。 前のステップが完了し、予測範囲を設定したら、AWS Supply Chain が予測を生成できるようにデータを準備します。 データセット内のマイナスの値を処理する方法を選択して、データセットを構成する必要があります。 最後のステップは、需要計画を出力する Amazon Simple Storage Service (Amazon S3) バケットを選択することです。 場所を選択したら、次のスクリーンショットに示すように、[ Continue ] を選択して予測を生成します。 これにより、需要計画プロセスが開始され、次のスクリーンショットに示す出力が生成されます。 ステップ 5 で選択した予測間隔を使用して、予測需要がグラフと表の両方の形式で表示されます。 グラフには、前年の需要を表す破線と現在のデータを表す実線が含まれています。 現在の需要明細には、過去の需要データと、ステップ 5 で選択した期間内の残りの月の予測が含まれます。 過去の需要と前年の需要データを組み合わせることで、ML が推奨する予測を調整して最終決定し、供給計画を含む下流システムで使用できる合意された需要計画を策定するのに役立ちます。 この画面から表示したい商品を変更することもできます。 結論 サプライチェーンネットワークは、変動する市況や顧客の需要によって常にテストされており、組織に対し積極的かつ機敏な対応を求めています。 AWS Supply Chain Demand Planning は、これらの課題に対処し、組織がサプライチェーン戦略において対応力だけでなく予測力をもって行動できるよう支援します。 AWS Supply Chain の需要計画プロセスは、ビジネスの過去、現在、未来をつなぐ架け橋となります。 最適なリソース配分と顧客満足度を確保するため、このプロセスにはデータ統合から継続的な調整までの体系的なステップが必要です。 これにより、このプロセスが反復的な性質を持っていることと、精度の向上、在庫の不均衡の低減、最適な在庫レベルの提供が重要であることが浮き彫りになります。 従来の需要計画に加えて、AWS Supply Chain は自動化をもたらし、データ入力、計算、調整などの面倒な手動作業をなくします。 機械学習を活用することで、予測精度を向上させ、リアルタイムの状況に適応することで、在庫状況と効率的なキャッシュフローのバランスを取ります。 また、AWS Supply Chain では、部門間のコラボレーションを重視し、さまざまなビジネスユニットを共通の需要予測に向けて調整するためのコンセンサス主導型のアプローチを促進しています。 この共同作業は、サプライチェーン管理における部門間の協調の重要性を浮き彫りにしています。 AWS Supply Chain は、高度なテクノロジーとシンプルさを兼ね備え、需要計画を革新的にアップグレードします。 この強化されたシステムは、予測精度の向上、業務効率を向上させることによって、積極的なサプライチェーン管理を実現します。また積極的なサプライチェーン管理は、現代のビジネスにとって不可欠な戦略であると位置づけています。 AAWS Supply Chain は、事前のライセンス料や長期契約なしで利用できます。 ニーズに合わせて拡張できるスケーラブルなソリューションを提供し、Demand Planning 機能は AWS Supply Chain のすべてのお客様が利用できます。 AWS Supply Chain にアクセスして詳細を確認し、始めましょう。 また、 AWS Workshop Studio にアクセスして、 ご自分のペースでインスタンスの作成、データの取り込み、ユーザーインターフェイスの操作、インサイトの作成、在庫リスクの軽減、他のユーザーとのコラボレーション、需要計画の生成についての概要を確認することもできます。 本ブログはソリューションアーキテクトの水野 貴博が翻訳しました。原文は こちら 。 著者について Harold Abell は、AWS サプライチェーンのシニアプロダクトマネージャーです。 Harold は AWS Supply Chain のプロダクトマネージャーの 1 人で、アプリケーションのコンセプトと設計に携わっています。 Harold は、ゼネラル・エレクトリック ( GE ) とアマゾンウェブサービス ( AWS ) の両方でサプライチェーンとソフトウェア開発において 10 年以上の業界経験があります。 Harold はブリガム・ヤング大学で製造工学の学士号と修士号を、デューク大学フュークア・スクール・オブ・ビジネスで経営学修士号を取得しています。 Harold は余暇には、妻と3人の女の子と一緒にスノースキーやボートを漕ぐなど、アウトドアが大好きです。 Vikram Balasubramanian は、サプライチェーンのシニア・ソリューション・アーキテクトです。Vikram は、サプライチェーンの経営幹部と緊密に連携して、彼らの目標や問題点を理解し、解決策の観点からベストプラクティスと連携させています。Vikram は17年以上にわたり、サプライチェーン分野のさまざまな業種のフォーチュン500企業で働いてきました。Vikram は、パデュー大学でインダストリアルエンジニアリングの修士号を取得しています。ヴィクラムはノースダラス地域を拠点としています。 <!-- '"` -->

Amazon Timestream はインフラストラクチャの可観測性、ユーザの行動分析、IoT のワークロード等に適したフルマネージドでスケーラブルな時系列データベースです。1 日に何兆ものイベントを処理可能で、ニーズに合わせて水平方向に拡張できるように設計されています。Timestream は マルチメジャーレコードやスケジュールドクエリ 等の機能を持ち合わせており、時系列データの分析を通じて、価値のある洞察ををコスト効率よく得る事が出来ます。 例えば、多数のパフォーマンス指標を追跡したり、顧客の行動をリアルタイムで分析するような場合等、様々なニーズに Timestream は対応出来ます。今回、顧客定義のパーティションキーを設定する事が可能になり、特定のニーズに合わせてクエリの最適化が行われる事により、以前よりもより高速に時系列データにアクセスできるようになりました。 顧客定義のパーティションキーの必要性 多くのお客様や我々の内部の開発チーム (Alexa Voice Service : AVS) では、拡張性の高い取り込みと低レイテンシーでのクエリ実行が必要となるようなユースケースで Timesream を利用しています。AVS チームの経験として、Timestream では時間の経過とともにデータが増大したとしても、既存のパーティショニング方法で拡張は可能ですが、ユースケースによっては特定のクエリに最適化されるような柔軟なオプションを提供する必要がある事が分かりました。 そういった点を念頭においた上で、Timestream の新機能である顧客定義のパーティションキーがリリースを発表できる事を嬉しく思います。この機能はクエリを高速化し、特定の時系列関連のニーズに基づいて、より効率的に洞察を得る為に必要な柔軟性を提供します。パーティショニングは複数の物理ストレージユニットにデータを分散する為に利用される技術で、より高速かつ効率的なデータ取得を可能にします。顧客定義のパーティションキー機能を利用すると、クエリパターンやユースケースに合わせたパーティションスキーマを作成する事が出来ます。 Timestream ではレコードは時系列内の単一のデータポイントです。各レコードには以下の 3 つの要素が含まれます。 タイムスタンプ ：通常、与えられたデータがいつ生成されたのかを示す ディメンジョン ：エンティティを一意に示すメタデータ メジャー ：時系列で追跡される実際の値 Timestream の主要な概念の詳細については、 ドキュメント を参照して下さい。 データを分割する特定のディメンジョンを選択する事で、Timestream はクエリ実行でスキャンされるデータ量を削減し、パーティショニングスキーマに一致するアクセスパターンを持つクエリのレイテンシーを改善します。例えば、顧客 ID, デバイス ID, 場所によるフィルタリングは多くのお客様が使用するアクセスパターンですが、そういったディメンジョンの一つをパーティションに設定する事で、クエリを最適化し、時系列データを最大限に活用できます。 パーティショニングキーを柔軟に設定出来るようになった事で、お客様の特定のワークロードにより適用できるようになり、データからより多くの価値を引き出す事ができるようになります。以下の例で確認していきましょう。 顧客定義のパーティションキーの仕組み 新しいテーブルを作成する際、一般的なアクセスパターンに基づいて特定のパーティションキーを選択しますが、通常は顧客 ID や、デバイス ID 等のクエリのフィルタリング条件によく利用されるものを使います。適切なディメンジョンをパーティションキーに選択する事で、最良のパフォーマンスを得る事が出来ます。 また、オプションでパーティションキーを示す項目に対して Null 値を許容しないように Timestream のテーブルを設定する事も出来ます。そうする事で、パーティション分割がさらに最適化され、最良のパフォーマンスが得られます。 パーティションキーを選択する際、独自のディメンジョンを設定したい場合は必ず Dimension を選んで下さい。もしも Measure name を選択した場合には、Timestream はデフォルトのパーティショニングスキーマを採用する為、特定メジャーの時間の経過に伴うフリート全体の変動を分析するのに適しています。 一般的なアクセスパターンについて話す時は、時系列データに対してクエリ実行する際のフィルターや述語の種類を指します。これらのフィルターには、特定の顧客 ID, デバイス ID, 又はお客様のビジネスに取って重要な高いカーディナリティのディメンジョン等が含まれる場合があります。パーティショニングキーが DeviceModel である仮定の使用例では次のようなコードとなります。 Select DeviceModel, segment, Event_name, count(event_name) as occurrences from events where event_type = ‘voice chrome latency’ and DeviceModel in (‘xxx-xxx-xx’ , ‘yyy-yyy-yy’, ‘zzz-zzz-zz’, ‘%-012’) and time &gt;= ago(1h) group by 1, 2,3 order by occurrences 例えば、Timestream にスマートデバイスや IoT アプリケーションからのデータを保存している場合には、デバイスモデルに基づいてデータを分割したいかも知れません。デバイスモデルをパーティショニングキーに設定する事で、テーブル内の全てのデータをスキャンする事無く、特定のデバイスセットの値を迅速に取得する事が出来ます。同じように、例えば顧客とのやり取りに関するデータを保存している場合は、顧客 ID にパーティションキーを設定する事で、特定の顧客の全てのやり取りを迅速に取る事を検討すべきでしょう。そうする事で、顧客に関連するすべてのデバイスの可視性も提供される事になります。 同じデータから派生する複数の異なるアクセスパターンがあるような場合には、異なるユースケースに最適化された別のパーティションキーを使った スケジュールドクエリー を利用する事も出来ます。例えば、一つはデバイスモデルの動作を理解する為のもの、もう一つは特定の顧客に関連する問題の原因分析と言った具合です。 最も一般的なアクセスパターンを把握する事で、パーティションキーに最もふさわしいディメンジョンを選択出来ます。これにより、Timestream は特定のアクセスパターンに対するクエリパフォーマンスを最適化し、時系列データ分析をより高速かつ効率的に実施する事が出来ます。 顧客定義によるパーティションキーを作成すると、Timestream は取り込まれたデータを自動的にパーティショニングし、クエリのパフォーマンスが最適化される事になります。テーブルが一旦パーティション化されると変更出来ない為、クエリパターンを慎重に検討し、パーティションキーとして最適なディメンジョンを選択する事が重要です。 データの正確性を確保し、クエリ効率を最大限高める為、スキーマ強制という新機能についてもリリースされています。この機能を使う事で、パーティションキーとして利用されているディメンジョンを含まない書き込みを拒否する事が出来ます。これにより、データが適切にパーティショニングされ、クエリパフォーマンスが高まり、より迅速に洞察を得る事が出来ます。パーティショニングの利点を最大限に活用できるように、強制レベルを REQUIRED とする事を推奨します。但し、少量のデータには対象となるディメンジョン値が存在しないようなユースケースもある事は理解しており、その場合は、強制レベルを OPTIONAL とすると対象ディメンジョンが無くとも書き込みを行う事が可能であり、全て同じ場所に格納される形となります。尚、強制レベルについては、テーブル作成後でも変更する事が可能です。 顧客定義のパーティションキーのケーススタディ それでは、社内の AVS 監視チームが顧客定義のパーティションキーを利用して、数百万ものデバイスのパフォーマンスを監視した例を見てみましょう。AVS 監視チームはデバイスメトリクス、システム健全性メトリクス、クラウドメトリクス等、接続されている数百万のデバイスからデータを毎日取り込んでいます。目標は全てのデバイスでの顧客体験の改善ですが、大量のデータが存在する為、エンティティレベルでデータを効率的に分析する方法が重要となります。この特定のユースケースでは、エンティティは個別デバイスか、特定のセグメントにまとまったすべてのデバイスとなります。デバイス監視システムは、デバイスとクラウド側のメトリクスをほぼリアルタイムで分析を行い、異常を検出し、問題を軽減して顧客体験の改善につなげる必要があります。 次の図は上記のユースケース用に実装されたアーキテクチャを示しています。 考えられるデータモデルの一つは地域、デバイスタイプ、ヘルスメトリクス等のデータを含んでいると考えられます。例えば、 device_type にパーティションキーを設定すると、デバイスタイプを条件に含むクエリのスキャン量が削減される事でレイテンシーが改善され、この特定の属性に基づいた問題の検知や、その原因分析がやりやすくなります。 データモデルの例を見てみましょう。 Column Name Data Type Column Type app_name varchar dimension date_time_emitted timestamp time date_time_received timestamp measure time_spent double measure event_id varchar dimension event_type varchar dimension device_type varchar dimension device_model varchar dimension segment varchar dimension domain varchar dimension metric_name varchar dimension Metric_value double measure このデータモデルでは、カーディナリティが数百万に達するディメンジョンはあまり含まれていませんが、デバイスモニタリングチームはその中から device_type を顧客定義のパーティションキーとして選びました。データが app_name , device_type , device_model によってパーティション化されている場合にパフォーマンスが向上する例をいくつか見てみましょう (尚、Timestream はテーブル毎に複数のパーティションキーを割り当てる事が出来ません) 。このスキーマを使って次のような非常に貴重な洞察を得る事が出来ます。 特定のアプリケーションで使用されている全てのデバイスを使用時間でランク付する必要がある場合、理想的なパーティションキーは app_name です。 特定のセグメントのイベントの成功／失敗を全て検索し、平均レイテンシーやデバイスタイプ毎の結果を計算する必要がある場合、理想的なパーティションキーは segment です。 全てのドメインでの成功したイベントのレイテンシーを確認する必要がある場合、理想的なパーティションキーは domain です。 失敗したイベントの中から最も問題のあるデバイスタイプを示すダッシュボードを作成する事が目標の場合、理想的なパーティションキーは device_type となります。 顧客定義のパーティションキー機能を、スケジュールドクエリ等の他の機能と併せて利用する事で、よりクエリパフォーマンスが改善し、コストが最適化される事を確認しました。スケジュールドクエリの詳細については ドキュメント を参照して下さい。 あなたのクエリを最適化しましょう！ 顧客定義のパーティションキー機能は、エンティティレベルの分析でクエリのパフォーマンスを最適化する為の強力なツールとなります。最も一般的なアクセスパターンを理解し、ほとんどのデータアクセスニーズに合致する高いカーディナリティのディメンジョンを選択する事で、クエリパフォーマンスの改善につなげる事が出来ます。デバイス監視の上述の例では、特定のディメンジョンレベルの分析用にクエリを最適化する事で、デバイスのパフォーマンスをより深く理解し、サービス改善につなげる事が出来ました。また、スキーマ強制の機能により、パーティションキーとして利用されるディメンジョンを含まない書き込みリクエストを拒否する事も出来ます。30 日間のトライアルを利用して Amazon Timestream を無料でご 利用開始 して頂き、お客様の時系列ワークロードの探索を始めては如何でしょう？ 翻訳はテクニカルアカウントマネージャーの西原が担当しました。原文は こちら をご覧下さい。

2023 年 6 月 (v0.6.0) — このリリースでは、完了した通話の概要を提供する生成系 AI によるトランスクリプト（文字起こし）要約が導入されました。Amazon Sagemaker で実行される組み込みの要約モデルや、Anthropic の Claude 大規模言語モデル (LLM) API (Amazon Bedrock に搭載予定) を使用するか、他のカスタム言語モデルや API を試してみてください。このリリースでは、UI も更新されています。 「新機能」 を参照してください。 コンタクトセンターはビジネスをコミュニティにつなげ、顧客が製品を注文したり、電話をかけてきた人がサポートをリクエストしたり、クライアントが面会の予約をしたりできるようにします。発信者との各会話は、その発信者のニーズと、通話中にそれらのニーズがどの程度うまく対処されたかを知る機会です。これらの会話から、スクリプトコンプライアンスを管理し、顧客を満足させる新しい機会を見つけるのに役立つ洞察を引き出すことができます。たとえば、報告されたギャップに対処するようにサービスを拡大したり、報告された問題領域の品質を向上させたり、コンタクトセンターのエージェントが提供するカスタマーエクスペリエンスを向上させたりすることができます。 Contact Lens for Amazon Connect では、このようなインサイトが得られる豊富な分析機能を備えた通話の文字起こしが可能ですが、現在 Amazon Connect を使用していない場合は、既存のコンタクトセンターの通話録音と連携するソリューションが必要です。 Amazon Transcribe Call Analytics や Amazon Comprehend などの Amazon 機械学習 (ML) サービスには、コンタクトセンターの音声録音からインサイトを大規模に転記したり抽出したりできる機能豊富な API が用意されています。これらのサービスを使用して独自のカスタム通話分析ソリューションを構築することもできますが、それには時間とリソースが必要です。この投稿では、通話後の分析のためのサンプルソリューションについて説明します。 ソリューションの概要 サンプルソリューションである Post Call Analytics（PCA）は、既存のコンタクトセンターからの通話録音を処理できるエンドツーエンドのソリューションを提供することに伴う面倒な作業のほとんどを行います。PCAは、新しいトレンドを見極め、エージェントのコーチング機会を特定し、電話に対する一般的な感情を評価するための実用的な洞察を提供します。 通話録音を提供していただくと、PCA は Amazon Transcribe Call Analytics やその他の AWS サービスを使用して自動的に処理し、顧客やエージェントのセンチメント、電話をかけた理由、話し合ったエンティティ、会話の特徴（非通話時間、中断、音量、通話速度など）などの貴重な情報を抽出します。Amazon Transcribe Call Analytics は、何千時間もの会話を使ってトレーニングされたビルトインの ML モデルを使用して問題を検出します。自動通話分類機能を使用すると、キーワードやフレーズ、センチメント、非通話時間に基づいて会話にタグを付けることもできます。また、名前、住所、クレジットカード番号、社会保障番号などの機密顧客データを記録ファイルと音声ファイルの両方から任意でマスキングすることができます。 (New!) PCA (v0.4.0 以降) では、新しい Amazon Transcribe Call Analytics サービスからの通話後の出力ファイルを直接処理することもできます。通話が終了したら、Amazon Transcribe Call Analytics ストリーミングセッションからの通話後の出力ファイル（JSON トランスクリプト、オーディオ録音）を提供してください。PCA は、オーディオ録音を再度書き起こすことなく、それらを自動的に処理します。両方の長所を活かすことができます！付属のライブ通話分析とエージェントアシスト (LCA) の最新バージョン (v0.6.0) は Amazon Transcribe Real-time Call Analytics をサポートしており、PCA との統合も簡単です。以下の「ライブ通話分析とエージェントアシスト:関連ソリューション」セクションを参照してください。 PCAのWebユーザーインターフェイスには、次のスクリーンショットに示すように、すべての通話を表示するホームページがあります。 レコードを選択すると、音声特性など、通話の詳細を確認できます。 下にスクロールすると、その他の通話情報や注釈付きの通話の詳細を確認することもできます。 日付、エンティティ、またはセンチメント特性に基づいて通話を検索できます。 通話の文字起こしを検索することもできます。 最後に、ビジネスインテリジェンス (BI) ツールから詳細な通話分析データをクエリできます。 PCA は現在、以下の機能をサポートしています。 トランスクリプション（文字起こし） Amazon Transcribe カスタム語彙 に対応したターンバイターンのバッチトランスクリプションにより、ドメイン固有の用語の正確性を実現 トランスクリプトやオーディオファイルからの 個人識別情報（PII）の編集 、カスタム単語やフレーズのマスキングのための 語彙フィルタリング 複数の言語と自動言語検出 標準オーディオファイル形式 チャネル識別 または 話者ダイアライゼーション を使用した発信者およびエージェントのスピーカーラベル 分析 発信者とエージェントのセンチメントの詳細と傾向 発信者とエージェントの両方の通話時間と非通話時間 キーワードやフレーズの有無、センチメント、非通話時間に基づいて設定可能な Amazon Transcribe Call Analytics カテゴリ Amazon Transcribe Call Analytics に組み込まれた通話要約 (ML) モデルを使用して、発信者の主な問題、アクションアイテム、結果を検出 Amazon Comprehend の標準またはカスタムエンティティ検出モデル、または設定可能な単純な文字列マッチングを使用して、呼び出しで参照されるエンティティを検出 発信者とエージェントが互いに割り込み合ったことを検出 スピーカーの音量 生成系 AI トランスクリプトの要約 (New!) 完了した各通話のトランスクリプトを生成系 AI を用いて要約 検索 時間範囲、センチメント、エンティティなどの通話属性で検索 文字起こしを検索する Amazon QuickSight の分析パイプラインとダッシュボード オプションで、Amazon QuickSight による通話後分析 (PCA) ソリューション用の高度なレポートと分析をデプロイ可能 その他 通話GUID、エージェント名、通話日時などのオーディオファイル名からメタデータを検出 さまざまな通話量に対応できるよう自動的にスケーリング 新しい記録が到着したときに処理する容量を維持しながら、古い記録の大規模なアーカイブを一括読み込み PCA をすぐに試せるサンプル録画 単一の AWS CloudFormation テンプレートを使用して簡単にインストール可能 これはほんの始まりに過ぎません！皆様からのフィードバックをもとに、今後さらに多くのエキサイティングな機能を追加していく予定です。 CloudFormationスタックをデプロイする まず、AWS CloudFormation を使用してサンプル記録をロードした状態でソリューションをデプロイし、PCA 体験を始めましょう。 次の Launch Stack ボタンを使用して、us-east-1 (バージニア北部) の AWS リージョンに PCA ソリューションをデプロイします。 ソースコードは GitHub リポジトリ で入手できます。 README の指示に従って、 Amazon Transcribe がサポートするその他のリージョン に PCA をデプロイしてください。 Stack name には、デフォルト値の PostCallAnalytics を使用してください。 AdminUsername には、デフォルト値の admin を使用してください。 AdminEmail には、有効なメールアドレスを使用してください。仮パスワードは、導入時にこのアドレスにEメールで送信されます。 loadSampleAudioFiles の値を true に変更します。 EnableTranscriptKendraSearch の値を Yes, create new Kendra Index (Developer Edition) に変更します。以前に Amazon Kendra 無料利用枠を使用したことがある場合は、このインデックスに 1 時間あたりのコストが発生します (コストの詳細については、この記事の後半で説明します)。Amazon Kendra のトランスクリプト検索はオプション機能なので、必要ない、またはコストが気になる場合は、デフォルト値の No を使用してください。 CallSummarization では、 SAGEMAKER を選択してビルトインモデル (約 1000 語に制限) をデプロイします。API キーを持つ Anthropic アカウントをお持ちの場合は ANTHROPIC を、その他のカスタム LLM または API を使用する場合は LAMBDA を選択します。詳細については、 Transcript Summarization を参照してください。 EnablePcaDashboards の値を yes に変更して、オプションの分析パイプラインと Amazon QuickSight 分析とダッシュボードをインストールします。 注:デプロイする前に、アカウントで Amazon Quicksight を有効にする必要があります。 別のブラウザタブで、AWS コンソールから QuickSight サービスに移動します。 Sign up for QuickSight を選択します。 エディションを選択します。 アカウント名と通知メールアドレスを入力します。 他のすべてのパラメータには、デフォルト値を使用してください。 カスタム語彙を適用して精度を向上させたり、エンティティ検出をカスタマイズしたりするなど、後で設定をカスタマイズする場合は、スタックを更新してこれらのパラメータを設定できます。 2 つの確認ボックスを選択し、 Create stack を選択します。 メインの CloudFormation スタックは、ネストされたスタックを使用して AWS アカウントに以下のリソースを作成します。 ビルドアーティファクトと通話録音を格納する Amazon Simple Storage Service (Amazon S3)&nbsp; バケット 設定を保存するための AWS Systems Manager Parameter Store 設定 録音ファイルの処理をオーケストレーションするための AWS Step Functions ワークフロー 音声ファイルの処理、およびターンバイターンの文字起こしと分析を行う AWS Lambda 関数 通話メタデータを保存するための Amazon DynamoDB テーブル 通話記録の概要を生成する Amazon SageMaker エンドポイント (選択した場合)。 S3 バケット、 Amazon CloudFront ディストリビューション、 Amazon Cognito ユーザープールを含むウェブサイトコンポーネント AWS Identity and Access Management (IAM) のロールとポリシー (最小権限のベストプラクティスを使用)、 Amazon Simple Queue Service (Amazon SQS) メッセージキュー、 Amazon CloudWatch ロググループなど、その他のサポートリソース。 オプションで、Amazon Kendra インデックスと AWS Amplify 検索アプリケーションを使用すれば、インテリジェントな通話履歴検索が可能です。 スタックのデプロイには約 20 分かかります。すべてがデプロイされると、メインスタックのステータスは CREATE_COMPLETE と表示されます。 パスワードの設定 スタックをデプロイしたら、PCA Web ユーザーインターフェイスを開き、パスワードを設定する必要があります。 AWS CloudFormation コンソールで、メインスタックの PostCallAnalytics を選択し、 Outputs タブを選択します。 ウェブブラウザを開いて、出力に WebAppURL と表示されている URL にアクセスします。ログインページにリダイレクトされます。 指定した E メールアドレス宛に届いた&nbsp; “Welcome to the Amazon Transcribe Post Call Analytics (PCA) Solution!” という件名の E メールを開きます。このメールには、（ユーザー管理者として）ログインして独自のパスワードを作成するために使用できる生成された一時パスワードが含まれています。 新しいパスワードを設定します。 新しいパスワードは 8 文字以上で、大文字、小文字、数字、特殊文字を含む必要があります。 これで PCA にログインできました。 loadSampleAudioFiles を true に設定したので、PCA デプロイメントには 3 つのサンプル通話がプリロードされ、確認できるようになりました。 オプション:トランスクリプト検索 Web UI を開いて、パスワードを再設定する 以下の追加手順に従って、付属のトランスクリプト検索 Web アプリにログインします。このウェブアプリは、スタックの起動時に EnableTranscriptKendraSearch を設定した場合にのみデプロイされます。 AWS CloudFormation コンソールで、メインスタックの PostCallAnalytics を選択し、 Outputs タブを選択します。 ウェブブラウザを開いて、出力に TranscriptionMediaSearchFinderURL として表示されている URL を開きます。 ログインページにリダイレクトされます 指定した E メールアドレス宛に届いた&nbsp; “Welcome to Finder Web App.” という件名の E メールを開きます。このメールには、（ユーザー管理者として）ログインするために使用できる生成された一時パスワードが含まれています。 PCA Web アプリケーションの場合と同じように、独自のパスワードを作成します。 PCA Web アプリケーションと同様に、新しいパスワードの長さは8文字以上で、大文字と小文字、数字と特殊文字が含まれている必要があります。 これで、トランスクリプト検索 Web アプリケーションにログインできました。サンプルオーディオファイルはすでにインデックス化されており、検索できる状態になっています。 オプション:Amazon QuickSight ダッシュボードを有効にするための追加のデプロイ手順 以下の追加ステップに従って Amazon QuickSight ダッシュボードを有効にします。このダッシュボードは、スタックの起動時に EnablePcaDashboards を設定した場合にのみデプロイされます。 QuickSight コンソールで、ユーザーアイコン (右上) を選択してメニューを開き、 QuickSight を管理 を選択します。 管理ページで &nbsp; セキュリティとアクセス権限 を選択し、デプロイされたスタックの出力タブで参照されている Amazon S3 OutputBucket へのアクセスを追加します。 管理ページで アセットの管理 を選択し、 ダッシュボード を選択します。 -PCA-Dashboard を選択し、 共有 を選択します。QuickSight ユーザーまたはグループを入力し、再度 Share を選択します。 オプションで、ダッシュボードをさらにカスタマイズするには、analyses のアセットタイプで -PCA-Analysis を共有し、データセット で -PCA-* を共有します。QuickSight ユーザーまたはグループを入力し、再度 Share を選択します。 PCA の高度な分析とダッシュボードソリューションの詳細については、関連ブログ記事「 Amazon QuickSight によるコール後分析 (PCA) ソリューションの高度なレポートと分析（英語） 」を参照してください。 通話分析機能を見る これで PCA が正常にインストールされたので、通話分析機能を試す準備ができました。 ホームページ ホームページを調べるには、メインスタックの出力に WebAppURL と表示されている URL を使用して PCA Web UI を開きます (この URL をブックマークしておくと便利です)。 ホームページにはすでに 6 件の通話が一覧表示されており、時間の降順（最新のものが最初）にソートされています。これらはサンプルオーディオファイルです。 通話には以下の重要な情報があります。 Job Name – 録音されたオーディオファイル名から割り当てられ、この通話の固有のジョブ名として機能します Timestamp – 可能な場合はオーディオファイル名から解析されます。それ以外の場合は、録音がPCAによって処理される時間が割り当てられます Customer Sentiment and Customer Sentiment Trend — 全体的な発信者のセンチメントと、発信者が通話開始時よりも終了時の方が好意的だったかどうかを示します Language Code — 指定された言語、または自動的に検出された通話の主要言語を表示します 通話詳細 最近受信した通話を選択して、通話詳細ページを開いて調べてください。通話情報と、センチメント、通話時間、中断、音量などの分析を確認できます。 下にスクロールすると、以下の詳細が表示されます。 エンティティタイプ別にグループ化されたエンティティ。エンティティは Amazon Comprehend とサンプルエンティティ認識文字列マップによって検出されます。 Amazon Transcribe 通話分析によって検出されたカテゴリ。デフォルトでは、カテゴリはありません。詳細については、 通話後分析 &nbsp;を参照してください。 GenAI Transcript Summary タブには、通話の簡単な概要が表示されます (有効な場合)。詳細については、 生成系 AI による通話の要約 を参照してください。 Call Analytics Summary タブには、問題、アクションアイテム、結果など、エージェントとカスタマーの通話における重要な要素の簡潔な概要が表示されます。詳細については、「 Amazon Transcribe による通話後の要約 （2023/9/7現在 日本語非対応）」を参照してください。 さらにスクロールすると、話者、タイムマーカー、センチメント、中断、問題、エンティティなどの注釈を含む、通話のターンごとの文字起こしが表示されます。 組み込みのメディアプレーヤーを使用して、会話のどの時点からでも通話音声を再生できます。トランスクリプトのタイムマーカーアノテーションを選択するか、プレーヤーのタイムコントロールを使用して位置を設定します。ページを下にスクロールしても、オーディオプレーヤーは表示されたままになります。 PII はトランスクリプトとオーディオの両方から編集されます。編集は CloudFormation スタックパラメーターを使用して有効化されます。 通話属性に基づく検索 PCA の組み込み検索を試すには、画面上部の Search を選択します。顧客のセンチメントが平均的にネガティブな通話を検索するためには、 Sentiment &nbsp; において、 Average 、 Customer 、 Negative を選択します。 Clear を選択して別のフィルターを試してください。 Entity に Hyundai と入力し、 Search を選択します。検索結果から通話を選択し、トランスクリプトから顧客が実際にヒュンダイについて電話をかけていたことを確認します。 通話トランスクリプトを検索する トランスクリプト検索は、Amazon Kendra が提供する試験的なオプションのアドオン機能です。 メインスタックの出力に TranscriptionMediaSearchFinderURL として表示されている URL を使用して、トランスクリプト検索 Web UI を開きます。最近の電話を検索するには、 customer hit the wall という検索クエリを入力します。 結果には、関連する通話からのトランスクリプションの抜粋が表示されます。内蔵オーディオプレーヤーを使用して、通話録音の関連セクションを再生します。 Filter search results を展開すると、追加のフィルターを使用して検索結果を絞り込むことができます。 Open Call Analytics &nbsp;を選択して、この通話の PCA 通話詳細ページを開きます。 SQL を使用したクエリ通話分析 Amazon Athena SQL クエリを使用して、PCA 通話分析データを Amazon QuickSight などのレポートツールまたは BI ツールに統合できます。試してみるには、Athena クエリエディタを開きます。 Database には pca &nbsp;を選択します。 parsedresults テーブルの解析結果を確認してください。この表には、ネスト構造を使用して、各通話のターンバイターンの文字起こしと分析がすべて含まれています。 また、レポートや分析アプリケーションに簡単に統合できるフラット化された結果セットを確認することもできます。クエリエディターを使用してデータをプレビューします。 処理フローの概要 PCAは通話録音をどのように書き起こし、分析したのでしょうか？ では、その仕組みを簡単に見てみましょう。 次の図は、主要なデータ処理コンポーネントと、それらがどのように組み合わされているかを大まかに示しています。 通話録音オーディオファイルは S3 バケットとフォルダーにアップロードされ、メインスタック出力ではそれぞれ InputBucket と InputBucketPrefix として識別されます。PCA をデプロイしたときに loadSampleAudioFiles パラメーターを true に設定したため、サンプル通話録音は自動的にアップロードされます。 各記録ファイルが Input バケットに追加されると、S3 イベント通知が Lambda 関数をトリガーし、Step Functions でワークフローを開始してファイルを処理します。ワークフローは、Amazon Transcribe バッチジョブを開始し、エンティティ検出と通話分析結果の追加準備を行うことで結果を処理するステップを調整します。処理された結果は JSON ファイルとして別の S3 バケットとフォルダに保存され、メインスタックの出力では OutputBucket と OutputBucketPrefix として識別されます。 Step Functions ワークフローが出力バケットに各 JSON 結果ファイルを作成すると、S3 イベント通知が Lambda 関数をトリガーし、選択した呼び出しメタデータを DynamoDB テーブルへロードします。 PCA UI ウェブアプリは DynamoDB テーブルをクエリして、処理された呼び出しのリストを取得してホームページに表示します。通話詳細ページには、選択した通話の JSON 結果ファイルから追加の詳細な文字起こしと分析が読み込まれます。 Amazon S3 ライフサイクルポリシーは、デプロイパラメータ RetentionDays で定義された設定可能な保存期間が経過すると、Input バケットと Output バケットの両方から記録と JSON ファイルを削除します。S3 イベント通知と Lambda 関数は、ファイルの作成時と削除時の両方で DynamoDB テーブルとの同期を維持します。 EnableTranscriptKendraSearch パラメータが true の場合、Step Functions ワークフローはタイムマーカーとメタデータ属性もトランスクリプションに追加し、Amazon Kendra インデックスに読み込まれます。トランスクリプション検索ウェブアプリケーションを使用して、通話のトランスクリプションを検索します。この仕組みの詳細については、「 Amazon Transcribe と Amazon Kendra を使って、音声ファイルや動画ファイルを検索可能にする 」を参照してください。 モニタリングとトラブルシューティング AWS CloudFormation は、スタックの Events タブでデプロイの失敗と原因を報告します。一般的なデプロイの問題については、「 CloudFormation のトラブルシューティング 」を参照してください。 PCA は CloudWatch を使用して各コンポーネントのランタイムモニタリングとログを提供します。 Step Functions ワークフロー — Step Functions コンソールで、ワークフロー PostCallAnalyticsWorkflow を開きます。 Executions タブには、各ワークフロー実行のステータスが表示されます。任意の実行を選択すると詳細が表示されます。 Execution event history から CloudWatch Logs &nbsp;を選択し、ワークフローによって呼び出された Lambda 関数のログを調べます。 PCA サーバーと UI Lambda 関数 — Lambda コンソールで、 PostCallAnalytics でフィルタリングすると、PCA 関連のすべての Lambda 関数が表示されます。関数を選択し、 Monitor タブを選択すると、関数メトリックが表示されます。 View CloudWatch Logs を選択して、関数ログを調べます。 コスト評価 PCA が使用する主なサービスの料金情報については、以下を参照してください。 Amazon CloudFront の料金 Amazon CloudWatch の料金 Amazon Cognito の料金 Amazon Comprehend の料金 Amazon DynamoDB の料金 Amazon API Gateway の料金 Amazon Kendra の料金 (オプションの文字起こし検索機能用) AWS Lambda の料金 Amazon Transcribe の料金 Amazon S3 の料金 AWS Step Functions の料金 Amazon SageMaker サーバーレス推論 の料金 トランスクリプション検索を有効にすると、Amazon Kendra インデックスには 1 時間あたりのコストがかかります。開発者版は 1 時間あたり 1.125 USD (最初の 750 時間は無料)、エンタープライズ版は 1 時間あたり 1.40 USD (本番環境のワークロードに推奨) です。 Amazon SageMaker を使用してトランスクリプト要約を有効にすると、要約 SageMaker エンドポイントの初期インスタンス数に入力した値に応じて、SageMaker エンドポイントに追加料金が発生します (デフォルトはプロビジョニングされた 1 ノード ml.m5.xlarge エンドポイント)。「0」を入力して SageMaker サーバーレス推論 を選択した場合は、使用量に対してのみ課金されます。関連する費用と無料利用枠の利用資格に関する情報については、 Amazon SageMaker の料金表 をご覧ください。代わりに ANTHROPIC または LAMBDA オプションを使用して要約することを選択した場合、LLM 関連の個別の料金はすべてお客様の負担となります。 その他の PCA 費用はすべて使用量に基づいて発生し、無料利用枠の対象となります。無料利用枠を使い切ると、5 分間の通話録音の使用コストは合計で約 0.15 USD になります。 PCA コストを自分で調べるには、 AWS Cost Explorer を使用するか、 AWS&nbsp; Billing Dashboard の Bill Details を選択して、サービス別の今月の支出を確認してください。 コンタクトセンターとの統合 通話レコーディングを有効にするようにコンタクトセンターを設定できます。可能であれば、2 つのチャネル（ステレオ）の録音を設定し、一方のチャネル（たとえば、チャネル 0）に顧客の音声、もう一方のチャネル（チャネル 1）にエージェントの音声を設定します。 AWS コマンドラインインターフェイス (AWS CLI) または SDK を使用して、コンタクトセンターのレコーディングファイルを PCA 入力バケットフォルダにコピーします。このフォルダは、メインスタック出力で InputBucket と InputBucketPrefix として識別されます。または、通話記録をすでに Amazon S3 に保存している場合は、デプロイパラメータ InputBucketName と InputBucketRawAudio を使用して、既存の S3 バケットとプレフィックスを使用するように PCA を設定します。これにより、ファイルを再度コピーする必要がなくなります。 (New!)また、コンタクトセンターからのストリーミングオーディオのリアルタイム分析には、最新バージョン（v0.6.0）のライブ通話分析とエージェントアシスト（LCA）を使用し、LCAをPCAと統合して両方の長所を活用することもできます。以下の「コンタクトセンターのライブ通話分析とエージェントアシスト:関連ソリューション」セクションを参照してください。 デプロイメントをカスタマイズする スタックを作成または更新するときは、次の CloudFormation テンプレートパラメータを使用して PCA デプロイをカスタマイズします。 オプションの (実験的な) 文字起こし検索機能を有効または無効にするには、 EnableTranscriptKendraSearch を使用してください。 既存の S3 バケットを着信通話の録音に使用するには、 InputBucket と InputBucketPrefix を使用してください。 自動プロビジョニングされた S3 入出力バケットを使用する際の録音および通話分析データの自動削除を設定するには、 RetentionDays を使用します。 録音ファイル名から通話タイムスタンプ、エージェント名、または通話識別子 (GUID) を検出するには、 FilenameDatetimeRegex 、 FilenameDatetimeFieldMap 、 FilenameGUIDRegex 、および FilenameAgentRegex を使用します。 デフォルトの Amazon Transcribe Call Analytics API の代わりに標準の Amazon Transcribe API を使用するには、 TranscribeApiMode を使用してください。Call Analytics API と互換性のないオーディオ録音（モノラルチャンネル録音など）は、PCA が自動的に標準 API を使用します。標準 API を使用する場合、一部の通話分析、問題検出、スピーカーの音量などの指標は利用できません。 サポートされているオーディオ言語のリストを設定するには、 TranscribeLanguages を使用してください。 不要な単語をマスクするには、 VocabFilterMode を使用して、 VocabFilterName を Amazon Transcribe ですでに作成しているカスタム語彙フィルタの名前に設定します。詳細については、 語彙フィルタリング を参照してください。 専門用語やドメイン固有の頭字語や専門用語の文字起こしの精度を向上させるには、 VocabularyName を Amazon Transcribe ですでに作成したカスタム語彙の名前に設定するか (「 カスタム語彙 」を参照)、 CustomLangModelName を Amazon Transcribe ですでに作成しているカスタム言語モデルの名前に設定します (「 カスタム言語モデル 」を参照)。 デフォルトでシングルチャンネルオーディオを使用するように PCA を設定し、チャンネル識別ではなく スピーカーダイアライゼーション を使用してスピーカーを識別するようにPCAを構成するには、 SpeakerSeparationType と MaxSpeakers を使用します。デフォルトでは、Amazon Transcribe Call Analytics API を使用してステレオファイルによるチャンネル識別を行い、最も豊富な分析と最も正確なスピーカーラベルを生成します。 文字起こしや音声から PII を編集するには、 CallRedactionTranscript または CallRedactionAudio を true に設定します。詳細については、「 リダクション （2023年9月7日現在 日本語非対応）」を参照してください。 Amazon Comprehend を使用してエンティティ検出をカスタマイズしたり、エンティティを定義する独自の CSV ファイルを提供したりするには、 Entity detection&nbsp; パラメータを使用します。 PCA の設定オプションと操作の詳細については、 GitHub の README を参照してください。 PCA はオープンソースプロジェクトです。 PCA GitHub リポジトリ をフォークしてコードを拡張し、プルリクエストを送信していただければ、改善点を組み込んで共有できます。 既存の PCA スタックの更新 既存の PCA スタックを最新リリースに簡単に更新できます。「 既存のスタックの更新 」を参照してください。 クリーンアップ このソリューションの実験が終了したら、AWS CloudFormation コンソールを開き、デプロイした PostCallAnalytics スタックを削除してリソースをクリーンアップします。これにより、ソリューションをデプロイして作成したリソースが削除されます。データが削除されないように、オーディオ録音と分析を含む S3 バケット、および CloudWatch ロググループは、スタックが削除された後も保持されます。 コンタクトセンターのライブ通話分析とエージェントアシスト:関連ソリューション 関連ソリューションであるライブ通話分析とエージェントアシスト (LCA) は、Amazon Transcribe リアルタイム API を使用してリアルタイムの文字起こしと分析機能を提供します。通話終了後に録音された音声を書き起こして分析する PCA とは異なり、LCA は通話中に文字起こしと分析を行い、スーパーバイザーやエージェントにリアルタイムで最新情報を提供します。新しい Amazon Transcribe リアルタイム通話分析サービスは、通話が終了してからわずか数分後に、ストリーミングセッションからの通話後の分析出力を提供します。LCA（v0.6.0以降）では、この通話後の分析データをPCAに送信して、音声をもう一度文字起こしすることなく、完了した通話の分析を視覚化できるようになりました。LCA（v0.6.0以降）をPCA（v0.4.0以降）と統合するように設定し、2つのソリューションを一緒に使用して両方の利点を最大限に活用します。詳細については、「 Amazon言語系AIサービスによるコンタクトセンターのライブ通話分析とエージェントアシスト 」を参照してください。 まとめ Post Call Analyticsソリューションは、スケーラブルで費用対効果の高いアプローチを提供し、通話分析に発信者のエクスペリエンスを向上させるのに役立つ機能を提供します。Amazon Transcribe Call Analytics や Amazon Comprehend などの Amazon ML サービスを使用して、顧客との会話を書き起こし、そこから豊富なインサイトを抽出します。 サンプル PCA アプリケーションはオープンソースとして提供されています。独自のソリューションの出発点として使用してください。また、GitHub のプルリクエストを通じてバックフィックスや機能を提供することで、改善に役立ててください。専門家のサポートについては、 AWS プロフェッショナルサービス やその他の AWS パートナー がお手伝いします。 フィードバックは、 PCA GitHub リポジトリ の issue フォーラムをご利用ください。 執筆者について Dr. Andrew Kane ロンドンを拠点とする AWS プリンシパル WW テックリード (AI 言語サービス) です。彼は AWS Language and Vision AI サービスに重点を置いており、お客様が複数の AI サービスを単一のユースケース主導型ソリューションに構築できるよう支援しています。2015 年の初めに AWS に入社する前、Andrew は 20 年間、信号処理、ファイナンス決済システム、武器追跡、編集および出版システムの分野で働いていました。彼は熱心な空手愛好家（ブラックベルトからたった一帯だけ）であり、自動醸造ハードウェアやその他の IoT センサーを使用する熱心な自家醸造家でもあります。 Bob Strahan AWS Language AI Servicesチームのプリンシパルソリューションアーキテクトです。 Connor Kirkpatrick コナー・カークパトリックは、英国を拠点とする AWS ソリューションエンジニアです。Connor は AWS ソリューションアーキテクトと協力して、標準化されたツール、コードサンプル、デモンストレーション、クイックスタートを作成しています。彼は熱心なボートの漕ぎ手、wobbly なサイクリスト、そして時折パン職人でもあります。 Franco Rezabek は、英国ロンドンを拠点とする AWS ソリューションエンジニアです。Franco は AWS ソリューションアーキテクトと協力して、標準化されたツール、コードサンプル、デモンストレーション、クイックスタートを作成しています。 Steve Engledow はソリューションエンジニアで、社内外の AWS のお客様と協力して、一般的な問題に対する再利用可能なソリューションを構築しています。 Christopher Lott は、AWS Language AI サービスチームのシニアソリューションアーキテクトです。彼は20年のエンタープライズソフトウェア開発経験があります。クリスはカリフォルニア州サクラメントに住んでおり、ガーデニング、航空宇宙、そして世界中を旅することを楽しんでいます。 翻訳はソリューションアーキテクトの小川翔が担当しました。原文は こちら です。

Vercel は、Amazon EventBridge スケジューラを利用して Cron Jobs を実装し、顧客がスケジュールされたタスクを大規模に作成、管理、実行できるようにしました。この機能の導入は急速に進み、リリースから数か月以内に毎週 700 万回を超える cron 呼び出しが行われるようになりました。この記事では、同社がどのようにそれを実現したのか、そして同社が経験している大規模なスケールにどのように対処したかを示します。 Vercel は、エンジニアがフロントエンドアプリケーションのデプロイと実行をより容易に行えるようにするフロントエンドクラウドを構築しています。 過去 2 年間で Vercel でのデプロイは 1 億件を超えています 。Vercel は、サーバーレステクノロジーを大規模に利用することで、ユーザーが設定することなく、クラス最高の AWS インフラストラクチャを活用できるようサポートしています。Vercel は、デベロッパーがフロントエンドアプリケーションをホストするのに役立つ機能を多数提供しています。しかし、今年の初めまで、同社はまだ Cron Jobs を構築していませんでした。 cron ジョブは、あらかじめ決められた間隔または固定時刻における特定のコマンドまたはスクリプトの実行を自動化するスケジュールされたタスクです。これにより、ユーザーは、バックアップ、顧客への通知メールの送信、サブスクリプションの更新が必要な場合の支払い処理など、定期的かつ反復的なアクションを設定できます。cron ジョブは、効率を向上させ、日常業務を自動化するためにコンピューティング環境で広く利用されており、Vercel の顧客からは、この機能を求める声が多く寄せられていました。 2022 年 12 月、Vercel はイノベーションを促進するために社内ハッカソンを主催しました。ここで、 Vincent Voyer 氏と Andreas Schneider 氏が協力して、Vercel プラットフォーム用の cron ジョブ機能のプロトタイプを構築しました。Voyer 氏と Schneider 氏は 5 人からなるチームを結成し、1 週間かけてこの機能に取り組みました。チームは、cron ジョブを表示するユーザーインターフェイスの構築から、機能のバックエンド実装の作成まで、さまざまなタスクをこなしました。 Amazon EventBridge スケジューラ ハッカソンチームが cron ジョブの問題の解決について考え始めたとき、最初のアイデアは、 スケジュールに従って実行される Amazon EventBridge ルール を利用することでした。しかし、この機能には AWS リージョンごとにアカウントあたり 300 個のルールという制限があり、これでは意図した用途には十分ではないことがすぐにわかりました。幸運にも、チームメンバーの 1 人が AWS コンピューティングブログで Amazon EventBridge スケジューラの発表 について読んでおり、チームはこれが自分たちの問題を解決するのに最適なツールであると考えました。 EventBridge スケジューラ を利用すると、基盤となるインフラストラクチャをプロビジョニングまたは管理することなく、270 を超える AWS サービスにわたって数百万のタスクを 1 回限り、または繰り返し実行するようにスケジュールできます。 Vercel で新しい cron ジョブを作成するには、顧客はこのタスクを実行する頻度と呼び出す API を定義する必要があります。Vercel はバックエンドで EventBridge スケジューラを利用し、新しい cron ジョブが作成されるときに新しいスケジュールを作成します。 エンドポイントを呼び出すために、チームは、入力パラメータとして呼び出す必要があるパスを受け取る AWS Lambda 関数を利用しました。 cron ジョブの実行時刻になると、EventBridge スケジューラは関数を呼び出し、設定されている顧客のウェブサイトのエンドポイントを呼び出します。 週末までに、Voyer 氏とチームは cron ジョブ機能の実用的なプロトタイプバージョンを完成させ、ハッカソンで賞を勝ち取りました。 Vercel Cron Jobs の構築 12 月のある 1 週間にわたってこのプロトタイプに取り組んだ後、ハッカソンは終了し、Voyer 氏とチームは通常業務に戻りました。2023 年 1 月初旬、Voyer 氏と Vercel のチームは、このプロジェクトを発展させて、実際の製品を実現することを決定しました。 ハッカソン中にチームは機能の基本的な部分を構築しましたが、本番環境に対応できるよう、いくつかの細かい点を磨き上げる必要がありました。Voyer 氏と Schneider 氏はこの機能に取り組み、2 か月も経たない 2023 年 2 月 22 日に Vercel Cron Jobs を一般向けに発表しました。 発表のツイート は 40 万回を超えるビューを獲得し、コミュニティはこのリリースを高く評価しました。 この機能の導入は非常に迅速でした。Cron Jobs のリリースから数か月以内に、Vercel は 1 週間あたり 700 万回を超える cron 呼び出しに達し、採用は今後も増加すると予想しています。 Vercel Cron Jobs がスケールを処理する方法 これほどのペースで導入が進んでいることを踏まえると、Vercel にとってこの機能をスケールすることは非常に重要です。このペースで cron 呼び出しの量をスケールするには、ビジネスおよびアーキテクチャの観点でいくつかの決定を下す必要がありました。 ビジネスの観点からは、同社は無料利用枠の顧客についての制限を定めました。無料利用枠の顧客は、自らのアカウントで最大 2 個の cron ジョブを作成できますが、設定できるスケジュールは時間単位のみです。つまり、無料利用の顧客は 30 分ごとに cron ジョブを実行することはできず、最大でも 1 時間ごとに実行できるのみとなります。Vercel の有料階層の顧客のみが、タスクのスケジュール設定に EventBridge スケジューラの分単位の粒度 を利用できます。 また、無料利用の顧客の場合、分単位の精度は保証されません。これを実現するために、Voyer 氏は EventBridge スケジューラの時間枠設定を利用しました。 柔軟な時間枠 設定を利用することで、時間枠内でスケジュールを開始できます。これは、ダウンストリームサービスに対する複数のリクエストの影響を軽減するために、スケジュールされたタスクが時間枠全体に分散されることを意味します。これは、例えば、多くの顧客が深夜にジョブを実行したい場合に非常に便利です。柔軟な時間枠を利用すると、設定された時間枠全体で負荷を分散できます。 アーキテクチャの観点からは、Vercel は API をホストし、cron ジョブが呼び出す関数を所有することの利点を活用しました。 これは、Lambda 関数が EventBridge スケジューラによって開始されると、関数は API からの応答を待たずに実行を終了することを意味します。その後、Vercel は、オブザーバビリティメカニズムから API と Vercel 関数が正しく実行されたかどうかをチェックすることで、cron ジョブが実行されたかどうかを検証します。この方法を用いることで、関数の実行時間は 400 ミリ秒未満と非常に短くなります。これにより、Vercel は同時実行の制限に影響を及ぼすことなく、1 秒あたりに多くの関数を実行できます。 影響 Vercel による Cron Jobs の実装は、サーバーレステクノロジーがどのようなことを実現できるのかを示す優れた例です。2 か月間にわたって 2 人がフルタイムで働くことで、コミュニティが必要としていた機能をリリースすることができ、その機能は広く導入されました。この機能は Vercel のプラットフォームの完全性を示すものであり、有料アカウントに移行するよう顧客を説得するための重要な機能となっています。 EventBridge スケジューラの利用を開始するには、 EventBridge スケジューラの Serverless Land のパターン を参照してください。ここでは、役立つ幅広い例を見つけることができます。 –&nbsp; Marcia 原文は こちら です。

最近、多くのお客様は大規模言語モデル (Large Language Model: LLM) に高い期待を示しており、生成系 AI がビジネスをどのように変革できるか考えています。しかし、そのようなソリューションやモデルをビジネスの日常業務に持ち込むことは簡単な作業ではありません。この投稿では、MLOps の原則を利用して生成系 AI アプリケーションを運用化する方法について説明します。これにより、基盤モデル運用 (FMOps) の基盤が築かれます。さらに、Text to Text のアプリケーションや LLM 運用 (LLMOps) について深掘りします。LLMOps は FMOps のサブセットです。以下の図は、議論するトピックを示しています。 具体的には、MLOps の原則を簡単に紹介し、FMOps および LLMOps との主な違いに焦点を当てます。これは、プロセス、人材、モデル選択と評価、データプライバシー、モデルのデプロイメントなどに関連します。そのまま利用する場合、スクラッチから基盤モデルを作成する場合、ファインチューニングする場合の全てに当てはまります。本アプローチは、オープンソースとプロプライエタリモデルの両方に同様に適用できます。 機械学習の運用サマリー Amazon SageMaker を利用したエンタープライズのための MLOps 基盤ロードマップ で定義されているように、機械学習と運用 (MLOps) は、機械学習 (ML) ソリューションを効率的に実運用するために、人材、プロセス、テクノロジーを組み合わせたものです。これを達成するには、以下に示すチームとペルソナが協力する必要があります。 これらのチームは以下の通りです。 アドバンスド・アナリティクス・チーム(データレイクとデータメッシュ) – データエンジニアは、複数のソースからデータを準備および取り込み、ETL (抽出、変換、ロード) パイプラインを構築してデータを策定およびカタログ化し、ML ユースケースに必要な履歴データを準備する責任があります。これらのデータ所有者は、複数のビジネスユニットまたはチームへのデータアクセスの提供に焦点を当てています。 データサイエンティスト・チーム – データサイエンティストは、予め定義された主要業績評価指標 (KPI) に基づいて、ノートブックでベストモデルを作成することに集中する必要があります。研究フェーズの完了後、データサイエンティストは ML エンジニアと協力して、CI/CD パイプラインを使用してモデルのビルド (ML パイプライン) と実稼働環境へのモデルのデプロイメントの自動化を作成する必要があります。 ビジネスチーム – プロダクトオーナーは、ビジネスケース、要件、およびモデルパフォーマンスを評価するために使用される KPI を定義する責任があります。ML コンシューマーは、意思決定を左右するために推論結果 (予測) を利用するその他のビジネスステークホルダーです。 プラットフォームチーム – アーキテクトは、ビジネスの全体的なクラウドアーキテクチャと、異なるサービスがどのように接続されているかの責任があります。セキュリティ SME は、ビジネスのセキュリティポリシーとニーズに基づいてアーキテクチャをレビューします。MLOps エンジニアは、データサイエンティストと ML エンジニアが ML ユースケースを実運用化できるように、安全な環境を提供する責任があります。具体的には、ビジネスとセキュリティの要件に基づいて、CI/CD パイプライン、ユーザーとサービスの役割とコンテナの作成、モデル利用、テスト、およびデプロイメントの方法論を標準化する責任があります。 リスクとコンプライアンス・チーム – より制限的な環境の場合、監査人はデータ、コード、モデルアーティファクトを評価し、ビジネスが規制 (データプライバシーなど) に準拠していることを確認する責任があります。 ビジネスのスケーリングと MLOps の成熟度に応じて複数のペルソナを同一人物が担当する場合があることに注意してください。 これらのペルソナは、以下の図に示すように、さまざまなプロセスを実行するための専用の環境を必要とします。 環境は以下の通りです。 プラットフォーム管理 – プラットフォームチームが AWS アカウントを作成し、適切なユーザーとデータをリンクできるプラットフォーム管理環境です。 データ – データレイヤーは、データエンジニアまたは所有者とビジネスステークホルダーがデータを準備、操作、および可視化するために使用するデータレイクまたはデータメッシュと呼ばれる環境です。 実験 – データサイエンティストは、概念実証 (Proof of Concept: PoC) がビジネスの問題を解決できることを証明するために、新しいライブラリと機械学習技術をテストするためのサンドボックスまたは実験環境を使用します。 モデル構築、モデルテスト、モデルデプロイメント – モデルの構築、テスト、およびデプロイメント環境は、研究を実運用に移行するためにデータサイエンティストと ML エンジニアが協力して研究を自動化する MLOps のレイヤーです。 ML ガバナンス – パズルの最後のピースは、モデルとコードの成果物が保存、レビュー、および対応するペルソナによる監査対象となる ML ガバナンス環境です。 以下の図は、 Amazon SageMaker を利用したエンタープライズのための MLOps 基盤ロードマップ で既に説明されているリファレンスアーキテクチャを示しています。 各ビジネスユニットには、ML ユースケースを実運用化するための独自セットの Dev (自動化されたモデルトレーニングとビルド)、Pre Prod (自動テスト)、Prod (モデルのデプロイとサービング) アカウントがあります。これらは、中心化されたデータレイクまたは分散データメッシュからデータを取得します。生成されたすべてのモデルとコードの自動化は、モデルレジストリの機能を使用して Tooling アカウントに集約されます。これらすべてのアカウントのインフラストラクチャコードは、プラットフォームチームが抽象化、テンプレート化、保守、および各新規チームの MLOps プラットフォームへのオンボーディングで再利用できる共有サービスアカウント (advanced analytics governance account) でバージョン管理されます。 生成系 AI の定義と MLOps との違い クラシックな機械学習では、人材、プロセス、テクノロジーの前述の組み合わせにより、ML ユースケースを製品化できます。ただし、生成系 AI では、ユースケースの性質により、これらの機能の拡張または新機能が必要になります。これらの新しい概念の 1 つは、基盤モデル (Foundation Model: FM) です。これらは以下の図に示すように、広範囲の他の AI モデルを作成するために使用できるため、そのように呼ばれています。 FM はテラバイト単位のデータでトレーニングされており、3 つの主なカテゴリの生成系 AI ユースケースにおいて、最良の回答を予測するための数百億のパラメータを持っています。 Text to Text – FM (LLM) は、ラベルなしデータ(フリーテキストなど)でトレーニングされており、次の最適な単語または一連の単語 (段落または長文) を予測できます。主なユースケースは、人間らしいチャットボット、要約、プログラミングコードなど、その他のコンテンツ作成などです。 Text to Image – &lt;テキスト、画像&gt; のペアなどのラベル付きデータを使用して、最適なピクセルの組み合わせを予測できる FM をトレーニングすることができます。使用例としては、服のデザイン生成や想像上のパーソナライズされた画像があります。 Text-to-Audio or Video – トレーニングされた FM のために、ラベル付きデータとラベルなしデータの両方を使用できます。主な生成系 AI のユースケースの例は音楽の作曲です。 これらの生成系AIユースケースを実運用化するには、MLOps ドメインを借用および拡張して、以下を含める必要があります。 FM 運用 (FMOps) – これにより、使用例のタイプを問わず、生成系 AI ソリューションを実運用化できます。 LLM 運用 (LLMOps) – これは FMOps のサブセットであり、LLM ベースのソリューション (Text to Text など)の実運用化に焦点を当てています。 以下の図は、これらのユースケースの重複を示しています。 従来の機械学習や MLOps と比較すると、FMOps と LLMOps は、以下の 4 つの主なカテゴリーに基づいて異なります。これらは、以下のセクションで取り上げます: プロセス、人材、FM の選択と適応、FM の評価と監視、データプライバシーとモデルのデプロイメント、技術ニーズ。監視については、別の投稿で取り上げます。 生成系 AI ユーザータイプごとの運用化の旅 プロセスの説明を簡単にするために、以下の図に示すように主な生成系 AI ユーザータイプを分類する必要があります。 ユーザータイプは以下の通りです。 プロバイダー – スクラッチから FM を構築し、製品として他のユーザー (ファインチューナーとコンシューマー) に提供するユーザー。彼らはエンドツーエンドの ML と自然言語処理 (NLP) の専門知識、および膨大なデータラベラーとエディタのチームを持っています。 ファインチューナー – プロバイダーから FM を再トレーニング (ファインチューニング) して、カスタム要件に合わせるユーザー。彼らはモデルのサービスとしてのデプロイをオーケストレーションします。これは、コンシューマーが使用するためのものです。これらのユーザーは、エンドツーエンドの ML とデータサイエンスの専門知識、モデルのデプロイと推論の知識が必要です。チューニングのためのプロンプトエンジニアリングを含むドメイン知識も必要です。 コンシューマー – テキストのプロンプトまたはビジュアルインターフェースによって、プロバイダーまたはファインチューナーの生成系 AI サービスと対話し、所望のアクションを完了するユーザー。ML の専門知識は必要ありませんが、主にアプリケーション開発者またはエンドユーザーで、サービスの機能についての理解が必要です。良い結果のために必要なのはプロンプトエンジニアリングのみです。 定義と必要な ML の専門知識に従って、MLOps は主にプロバイダーとファインチューナーに必要です。一方、コンシューマーは DevOps や AppDev の原則を使用して、生成系 AI アプリケーションを作成できます。さらに、次のようなユーザータイプの変遷が観察されています。プロバイダーは、垂直セクター (金融セクターなど) に基づくユースケースをサポートするためにファインチューナーになる可能性があります。または、コンシューマーは、より正確な結果を得るためにファインチューナーになる可能性があります。しかしながら、以降ではユーザータイプごとの主要なプロセスを観察しましょう。 コンシューマーの旅 以下の図は、コンシューマーの旅を示しています。 前述のとおり、コンシューマーは、特定の入力、つまりプロンプトを提供することによって、FM を選択、テスト、使用する必要があります。プロンプトとは、コンピュータプログラミングや AI のコンテキストで、モデルまたはシステムに対して与えられる入力を指します。これは、テキスト、コマンド、質問の形式をとることができ、システムはこれを使用して出力を処理および生成します。FM によって生成された出力は、エンドユーザーが使用できます。エンドユーザーは、これらの出力を評価して、モデルの将来の応答を強化する必要があります。 これらの基本プロセスに加えて、ファインチューナーが提供する機能を活用してモデルをファインチューニングすることをコンシューマーが望んでいることに私たちは気づきました。たとえば、画像を生成する Web サイトを考えてみましょう。ここでは、エンドユーザーはプライベートアカウントを設定し、個人写真をアップロードし、その後、それらの画像に関連するコンテンツを生成できます (たとえば、バイクに乗って剣を振り回しているエンドユーザー、またはエキゾチックな場所にいるエンドユーザーを描いた画像)。このシナリオでは、コンシューマーが設計した生成系 AI アプリケーションは、API を介してファインチューナーのバックエンドと対話して、この機能をエンドユーザーに提供する必要があります。 しかし、その前に以下の図に示すような、モデルの選択、テスト、使用、入力と出力の対話、および評価のプロセスに注力しましょう。 * 利用可能な15,000のFMリファレンス ステップ1. トップ FM 機能を理解する 基盤モデルを選択する際には、ユースケース、利用可能なデータ、規制などに応じて、考慮すべき多くの観点があります。包括的ではないが、次のような優良チェックリストが考えられます。 プロプライエタリまたはオープンソースの FM – プロプライエタリモデルは金銭的コストがかかりますが、通常、生成されたテキストまたは画像の品質の点で優れたパフォーマンスを発揮します。これは、最適なパフォーマンスと信頼性を確保する専任のモデルプロバイダーチームによって開発・維持管理されることが多いためです。一方、オープンソースモデルの採用も増加しており、無料である以外に、アクセスしやすく柔軟性があるという追加のメリットがあります (例えば、すべてのオープンソースモデルはファインチューニング可能です)。プロプライエタリモデルの例として Anthropic の Claude モデルが、高性能なオープンソースモデルの例として 2023 年 7 月時点の Falcon-40B があります。 商用ライセンス – FM を決定する際、ライセンスの考慮事項が重要です。一部のモデルはオープンソースですが、ライセンスの制限または条件により、商業目的で使用できないことに注意することが重要です。違いは微妙な場合があります。たとえば、新しくリリースされた xgen-7b-8k-base モデルはオープンソースで商用可能 (Apache-2.0ライセンス) ですが、Instruction Fine-Tuning バージョンのモデル xgen-7b-8k-inst は研究目的でのみリリースされています。商用アプリケーションの FM を選択する場合、ライセンス契約を確認し、その制限を理解し、プロジェクトの意図された使用目的と整合していることを確認することが重要です。 パラメータ – パラメータの数は、ニューラルネットワークの重みとバイアスで構成されます。これはもう 1 つの重要な要因です。パラメータが多いほど、モデルはより複雑で可能性のある強力なモデルになります。これは、データ内のより精妙なパターンと相関関係を捉えることができるためです。ただし、トレードオフはより多くのコンピューティングリソースが必要になり、実行コストが高くなることです。また、オープンソースでは小規模モデル (70 億 ~ 400 億のパラメータ)のファインチューニング時に良好なパフォーマンスを発揮する傾向が特に見られます。 速度 – モデルの速度は、そのサイズの影響を受けます。大規模モデルは、計算の複雑さが増すため、データ処理が遅くなりがちです (レイテンシが高くなる)。したがって、高い予測力を持つモデル (多くの場合、大規模モデル) の必要性と、特にチャットボットなどのリアルタイムまたはニアリアルタイム応答を必要とするアプリケーションの速度に関する実際の要件のバランスを取ることが重要です。 コンテキストウィンドウサイズ (トークン数) – プロンプトごとに入力または出力できる最大トークン数によって定義されるコンテキストウィンドウは、モデルが一度に考慮できるコンテキスト量を決定するのに重要です (トークンは英語では約 0.75 語に相当します)。コンテキストウィンドウが大きいモデルは、長い会話やドキュメントに関わるタスクに役立つ、より長いテキストシーケンスを理解および生成できます。 トレーニングデータセット – FM がどのような種類のデータでトレーニングされたかを理解することも重要です。一部のモデルは、インターネットデータ、コーディングスクリプト、インストラクション、人間のフィードバックなど、さまざまなテキストデータセットでトレーニングされている場合があります。テキストと画像データの組み合わせなど、マルチモーダルデータセットでトレーニングされている場合もあります。これは、異なるタスクに対するモデルの適合性に影響を与える可能性があります。また、組織にはモデルが正確にどのソースでトレーニングされたかに応じて、著作権の問題が発生する可能性があるため、トレーニングデータセットを注意深く検証することが必須です。 品質 – FM の品質は、そのタイプ (プロプライエタリかオープンソース)、サイズ、トレーニング内容に基づいて異なる場合があります。品質はコンテキスト依存であり、あるアプリケーションで高品質と見なされるものが、別のアプリケーションではそうでない可能性があります。たとえば、インターネットデータでトレーニングされたモデルは、会話型テキストの生成には高品質だと考えられる可能性がありますが、技術的または専門的なタスクにはそうでない可能性があります。 ファインチューニング可能 – モデルの重みやレイヤーを調整することによって FM をファインチューニングできる機能は、重要な要因となり得ます。ファインチューニングにより、モデルをアプリケーションの具体的なコンテキストにより適合させ、特定のタスクでのパフォーマンスを向上させることができます。ただし、ファインチューニングには追加のコンピューティングリソースと技術専門知識が必要であり、すべてのモデルがこの機能をサポートしているわけではありません。オープンソースモデルは、モデルアーティファクトをダウンロードでき、ユーザーはそれらを自由に拡張および使用できるため、(一般に) 常にファインチューニングが可能です。プロプライエタリモデルの場合、ファインチューニングのオプションを提供していることがあります。 顧客または開発チームの既存スキル – FM の選択は、顧客または開発チームのスキルと習熟度の影響も受けます。組織のチームに AI/ML の専門家がいない場合、API サービスの方が適している可能性があります。また、チームが特定の FM に広範な経験を持っている場合、新しいものを学習および適応するために時間とリソースを投資するよりも、それを使用し続ける方が効率的な場合があります。 プロプライエタリモデルとオープンソースモデルの 2 つの短いリストの例を以下に示します。ニーズに基づいて同様の表を作成し、利用可能なオプションの概要を迅速に把握できます。これらのモデルのパフォーマンスとパラメータは急速に変化し、本ブログを読まれているタイミングでは古い情報になっている可能性がある一方で、サポート言語など、特定の顧客にとって重要な他の機能があることに注意してください。 以下は、AWS で利用可能な注目すべきプロプライエタリ FM の例です (2023 年 7 月時点)。 以下は、AWS で利用可能な注目すべきオープンソース FM の例です (2023 年 7 月時点)。 10 – 20 の潜在的な候補モデルの概要を作成した後、この短いリストをさらに絞り込む必要があります。このセクションでは、次のラウンドの候補として実行可能な 2、3 の最終モデルを迅速に生成するメカニズムを提案します。 次の図は、初期の短いリスト作成プロセスを示しています。 通常、高品質なプロンプトを作成して AI モデルがユーザー入力を理解および処理できるようにする専門家であるプロンプトエンジニアは、要約など同じタスクをモデルで実行するさまざまな方法を試します。これらのプロンプトはその場で作成されるのではなく、プロンプトカタログから体系的に抽出されることをお勧めします。プロンプトカタログは、プロンプトの複製を避け、バージョン管理を可能にし、次のセクションで紹介するさまざまな開発段階の異なるプロンプトテスター間の一貫性を確保するためにプロンプトをチーム内で共有するための中心的な場所です。このプロンプトカタログは、特徴量ストアの Git リポジトリに似ています。潜在的にはプロンプトエンジニアと同じ人物である可能性のある生成系 AI 開発者は、開発を目指している生成系 AI アプリケーションに適しているかどうかを判断するために、出力を評価する必要があります。 ステップ2. トップ FM をテストおよび評価する 短いリストが約 3 つの FM に絞り込まれた後、ユースケースに対する FM の機能と適合性をさらにテストするための評価ステップを推奨します。評価データの可用性と性質に応じて、以下の図に示すように、異なる方法を提案します。 最初に使用する方法は、ラベル付きのテストデータがあるかどうかによって異なります。 ラベル付きデータがある場合は、従来の ML モデルと同様に、モデル評価を実行できます (一部のサンプルを入力し、出力をラベルと比較します)。テストデータに離散ラベル (肯定的、否定的、中立的な感情分析など) があるか、非構造化テキスト (要約など) であるかによって、評価のための異なる方法を提案します。 精度指標 – 離散出力 (感情分析など) の場合は、精度、再現率、F1 スコアなどの標準的な精度指標を使用できます。 類似性指標 – 出力が非構造化(要約など)の場合は、ROUGE やコサイン類似度などの類似性指標を提案します。 一部のユースケースは、唯一の正解を持たない場合があります (例:「5 歳の娘のための短い子供向けの物語を作成する」)。このような場合、ラベル付きのテストデータがないため、モデルを評価することがより困難になります。モデルの自動評価と人のレビューの重要性に応じて、次の 2 つのアプローチを提案します。 Human-in-the-Loop (HIL) – この場合、プロンプトテスターのチームがモデルからの応答をレビューします。アプリケーションの重要性に応じて、プロンプトテスターはモデル出力の 100 % をレビューするか、サンプルのみをレビューする可能性があります。 LLM 駆動型評価 – このシナリオでは、プロンプトテスターは、テスト対象のものよりも強力な (おそらく遅く、コストもかかる) LLM に置き換えられます。LLM は、モデルが生成する全ての応答をレビューしてスコア付けします。この方法では品質が低下する可能性がありますが、モデルパフォーマンスの初期の目安を提供できる、より安価で高速な評価オプションです。 たとえば、入力クエリ、LLM 応答、インストラクションが含まれる次のサンプルプロンプトを LLM に使用できます: 「上記に表示されているユーザーの質問に対する AI アシスタントのパフォーマンスについてフィードバックをお願いします。助手の応答の有用性、関連性、正確性、詳細のレベルを評価してください。アシスタントは、高いスコアほど全体的なパフォーマンスが向上する 1-10 の尺度で全体的なスコアを受け取る必要があります。」 このプロンプトは、別の LLM (EvalLLM) に送信されて評価されます。次は、Falcon-40B モデルの応答が EvalLLM (このケースでは Claude) によって評価された例です。「スエズ運河が建設されなければどうなっていたか」という質問を使用します。応答は次のとおりです。 質問: スエズ運河が建設されなければどうなっていたか? falcon-40b-instruct スエズ運河が建設されなければ、船は地中海と紅海の間を航行するためにアフリカを迂回しなければなりませんでした。 これにより、航海時間と距離が大幅に増加し、効率性が低下し、コストがかかるようになります。 また、スエズ運河がなければ、中東と北アフリカの多くの国々は世界の他の地域との接続が非常に薄れ、経済発展と文化発展が阻害されていたでしょう。 レビュー(スコア: 9/10) アシスタントの応答は非常に適切で、正確で、詳細です。 これは、スエズ運河の非存在に関するユーザーの仮想の質問に対して優れた回答を提供しています。 アシスタントは、海上交通と中東・北アフリカの経済的・文化的影響について的確に指摘しています。 ただし、地政学的含意や世界的な貿易パターンへの影響についてさらに詳述すれば、より包括的な回答になったでしょう。 次の図は、エンドツーエンドの評価プロセスの例を示しています。 この例に基づき、評価を実行するには、プロンプトカタログに格納されているサンプルプロンプトと、特定のアプリケーションに基づくラベル付けされたまたはラベルなしの評価データセットを提供する必要があります。 たとえば、ラベル付きの評価データセットであれば、「2023年の英国首相の氏名を教えてください」というプロンプト(入力とクエリ)や「Rishi Sunak」といった出力と回答を提供できます。 ラベルなしのデータセットの場合は、「小売りウェブサイトのソースコードを生成する」などの質問や指示のみを提供します。 プロンプトカタログと評価データセットの組み合わせを、 評価プロンプトカタログ と呼びます。 プロンプトカタログと評価プロンプトカタログを区別する理由は、後者は特定のユースケースを対象としているのに対し、プロンプトカタログには質問応答などの汎用のプロンプトとインストラクションが含まれるためです。 この評価プロンプトカタログを使用すると、次のステップは、トップ FM に評価プロンプトを入力することです。 結果は、プロンプト、各 FM の出力、スコアとともにラベル付き出力が含まれる評価結果データセットになります(存在する場合)。 ラベルなしの評価プロンプトカタログの場合、結果をレビューしてスコアやフィードバックを提供する HIL または LLM の追加ステップがあります(前述)。 最終的な結果は、すべての出力のスコアを結合した集計結果(平均精度や人間の評価を計算)で、ユーザーはモデルの品質をベンチマークできます。 評価結果が収集されたら、いくつかの次元に基づいてモデルを選択することを提案します。 これらは通常、精度、速度、コストなどの要因に関係します。 次の図は、例を示しています。 各モデルは、これらの次元に沿って強みと特定のトレードオフを持っています。 ユースケースに応じて、これらの次元に異なる優先順位を割り当てる必要があります。 前の例では、最も重要な要因としてコストを優先し、次に精度、そしてスピードとしました。 FM1 ほど効率的ではなく、遅いものの、十分に効果的で、ホスティングコストも大幅に安価です。 したがって、FM2 をトップ選択として選択する可能性があります。 ステップ3. 生成系 AI アプリケーションのバックエンドとフロントエンドを開発する この時点で、生成系 AI 開発者は、プロンプトエンジニアとテスターの助けを借りて、特定のアプリケーションに適した正しい FM を選択しました。 次のステップは、生成系 AI アプリケーションの開発を開始することです。 生成系 AI アプリケーションの開発をバックエンドとフロントエンドの2つのレイヤーに分けています。以下の図の通りです。 バックエンドでは、生成系 AI 開発者は、選択した FM をソリューションに組み込み、プロンプトエンジニアと協力して、エンドユーザーの入力を適切な FM プロンプトに変換するための自動化を作成します。 プロンプトテスターは、自動または手動 (HIL または LLM) のテストのために、プロンプトカタログに必要なエントリを作成します。 次に、生成系 AI 開発者は、最終出力を提供するためのプロンプトチェーンとアプリケーションメカニズムを作成します。 このコンテキストでは、プロンプトチェーンは、より動的でコンテキスト認識のある LLM アプリケーションを作成するテクニックです。 これは、複雑なタスクを一連の小さな、管理可能なサブタスクに分解することによって機能します。 たとえば、LLM に「イギリスの首相はどこで生まれ、その場所はロンドンからどのくらい離れているか」と尋ねた場合、タスクは、「イギリスの首相は誰ですか」、「出生地はどこですか」、「その場所はロンドンからどのくらい離れていますか」などの個々のプロンプトに分解できます。以前のプロンプトの評価に基づいてプロンプトが構築される場合があります。 一定の入力と出力の品質を確保するために、生成系 AI 開発者は、エンドユーザーの入力とアプリケーション出力を監視およびフィルタリングするメカニズムも作成する必要があります。 たとえば、LLM アプリケーションが有害なリクエストと応答を回避することを目的としている場合、入力と出力の両方に有害性検出を適用し、それらを除外できます。 最後に、良好例と悪例で評価プロンプトカタログを拡張するのに役立つ、評価メカニズムを提供する必要があります。 これらのメカニズムのより詳細な表現は、今後の投稿で提示されます。 この機能を生成系 AI エンドユーザーに提供するには、バックエンドと対話するフロントエンドウェブサイトの開発が必要です。 したがって、DevOps および AppDevs (クラウド上のアプリケーション開発者)のペルソナは、入力/出力および評価の機能を実装するために、ベストプラクティスに従う必要があります。 この基本的な機能に加えて、フロントエンドとバックエンドには、パーソナルユーザーアカウントの作成、データのアップロード、ブラックボックスとしてのファインチューニングの開始、基本 FM の代わりにパーソナライズされたモデルの使用などの機能を組み込む必要があります。 生成系 AI アプリケーションのプロダクション化は、通常のアプリケーションと同様です。 次の図は、サンプルアーキテクチャを示しています。 このアーキテクチャでは、生成系 AI 開発者、プロンプトエンジニア、DevOps または AppDev がアプリケーションを手動で作成およびテストし、専用のコードリポジトリを介して CI/CD 経由で開発環境(前の図の GenAI App Dev) にデプロイし、dev ブランチとマージします。 この段階で、生成系 AI 開発者は、FM プロバイダーによって提供された API を呼び出すことにより、対応する FM を使用します。 次に、アプリケーションを広範にテストするには、コードをテストブランチにプロモートする必要があります。これにより、CI/CD を介してプリプロダクション環境 (GenAI App Pre Prod) へのデプロイがトリガーされます。 この環境で、プロンプトテスターは大量のプロンプトの組み合わせを試し、結果を確認する必要があります。 プロンプト、出力、レビューの組み合わせは、評価プロンプトカタログに移動し、今後のテストプロセスを自動化する必要があります。 この広範なテストの後、最後のステップは、メインブランチとのマージにより、生成系 AI アプリケーションを CI/CD 経由で本番にプロモートすることです (GenAI App Prod)。 プロンプトカタログ、評価データと結果、エンドユーザーデータとメタデータ、ファインチューニングされたモデルのメタデータなど、すべてのデータをデータレイクまたはデータメッシュレイヤに格納する必要があることに注意してください。 CI/CD パイプラインとリポジトリは、別のツールアカウント( MLOps に記載のものと同様)に格納する必要があります。 プロバイダーの旅 FM プロバイダーは、ディープラーニングモデルなどの FM をトレーニングする必要があります。 彼らにとって、エンドツーエンドの MLOps ライフサイクルとインフラストラクチャが必要です。 履歴データの準備、モデル評価、および監視に追加が必要です。 以下の図は、そのプロセスを示しています。 従来の ML では、真値を ETL パイプライン経由でフィードすることにより、履歴データが作成されます。 例えば、顧客離反予測のユースケースでは、自動化によりデータベーステーブルが顧客の離反/非離反ステータスに基づいて自動的に更新されます。 FM の場合、ラベル付きまたはラベルなしのデータポイントの10億~100億が必要です。 テキスト対画像のユースケースでは、データラベラーチームが手動で&lt;テキスト、画像&gt;のペアにラベルを付ける必要があります。 これは、多くの人的リソースを必要とする高価な作業です。 Amazon SageMaker Ground Truth Plus は、このアクティビティを実行するためのラベラーチームを提供できます。 LLM の場合などのラベルなしデータのユースケースの場合、データはラベルが付いていません。 ただし、既存の未ラベルの履歴データのフォーマットに従う必要があるため、データエディターが必要なデータ準備を行い、一貫性を確保する必要があります。 履歴データの準備が整ったら、次のステップはモデルのトレーニングと運用化です。 消費者のシナリオに記載されているのと同じ評価手法を使用できることに注意してください。 ファインチューナーの旅 ファインチューナーの目的は、既存の FM を特定のコンテキストに適合させることです。 たとえば、FM モデルは一般目的のテキストを要約できますが、金融報告書を正確に要約できないかもしれません。または、一般的ではないプログラミング言語のソースコードを生成できない可能性があります。 このような場合、ファインチューナーはデータにラベルを付け、トレーニングジョブを実行してモデルをファインチューニングし、モデルをデプロイし、コンシューマーのプロセスに基づいてモデルをテストし、モデルを監視する必要があります。 次の図は、このプロセスを示しています。 現時点では、ファインチューニングのメカニズムが2つあります。 ファインチューニング – FM とラベル付きデータを使用することにより、トレーニングジョブはディープラーニングモデルのレイヤの重みとバイアスを再計算します。 このプロセスは計算資源を大量に必要とする可能性があり、代表的な量のデータが必要ですが、正確な結果を生成できます。 パラメータ効率的ファインチューニング (PEFT) – すべての重みとバイアスを再計算する代わりに、研究者はディープラーニングモデルに追加の小さなレイヤーを追加することにより、満足のいく結果を達成できることを示してきました ( LoRA など)。 PEFT は、ディープファインチューニングよりも計算リソースが少なくて済み、トレーニングジョブに必要な入力データが少なくて済みます。 欠点は、精度が低下する可能性があることです。 次の図は、これらのメカニズムを示しています。 2つの主要なファインチューニング方法を定義したので、次のステップは、オープンソースおよびプロプライエタリの FM をどのようにデプロイおよび使用するかを決定することです。 オープンソースの FM の場合、ファインチューナーはウェブからモデルアーティファクトとソースコードをダウンロードできます。たとえば、 Hugging Face Model Hub を使用できます。 これにより、モデルを深くファインチューニングし、ローカルのモデルレジストリに格納し、 Amazon SageMaker エンドポイントにデプロイする柔軟性が得られます。 このプロセスにはインターネット接続が必要です。 よりセキュアな環境(金融セクターの顧客など)をサポートするには、モデルをオンプレミスでダウンロードし、すべての必要なセキュリティチェックを実行し、AWS アカウントのローカルバケットにアップロードできます。 次に、ファインチューナーは、インターネット接続なしでローカルバケットから FM を使用できます。 これにより、データプライバシーが確保され、データがインターネット経由で移動しないようになります。 次の図は、この方法を示しています。 プロプライエタリ FM の場合、ファインチューナーがモデルアーティファクトやソースコードにアクセスできないため、デプロイプロセスは異なります。 モデルは、プロプライエタリ FM プロバイダーの AWS アカウントとモデルレジストリに格納されています。 SageMaker エンドポイントにこのようなモデルをデプロイするには、ファインチューナーは直接エンドポイントにデプロイされるモデルパッケージのみをリクエストできます。 このプロセスでは、プロプライエタリ FM プロバイダーのアカウントで顧客データを使用してファインチューニングを実行する必要があるため、リモートアカウントで顧客機密データが使用されてファインチューニングが実行されることや、複数の顧客間で共有されるモデルレジストリでモデルがホストされることに関する疑問が生じます。 これにより、プロプライエタリ FM プロバイダーがこれらのモデルを提供する必要がある場合、マルチテナントの問題がより困難になります。 ファインチューナーが Amazon Bedrock を使用する場合、これらの課題が解決されます。データはインターネット経由では移動せず、FM プロバイダーはファインチューナーのデータにアクセスできません。 前述の例で説明したように、ウェブサイトが数千人の顧客がパーソナライズされた画像をアップロードすることを可能にする場合と同じ課題が、オープンソースモデルにもあります。 ただし、これらのシナリオは、ファインチューナーのみが関与しているため、制御可能であると見なすことができます。 次の図は、この方法を示しています。 技術的な観点から、ファインチューナーがサポートする必要のあるアーキテクチャは、MLOps と同様です(次の図を参照)。 ファインチューニングは、 Amazon SageMaker Pipelines などを使用した ML パイプラインを作成することにより、開発で行う必要があります。前処理、ファインチューニング(トレーニングジョブ)、および後処理を実行し、ファインチューニングされたモデルをオープンソース FM の場合はローカルのモデルレジストリに送信し(そうでない場合、新しいモデルはプロプライエタリ FM プロバイダー環境に格納されます)。 次に、本番前にモデルをテストする必要があります。最後に、モデルがサービスとして提供され、監視されます。 現在(ファインチューニングされた) FM には、GPU インスタンスエンドポイントが必要です。 各ファインチューニングモデルを個別のエンドポイントにデプロイする必要がある場合、数百ものモデルがあるとコストが増加する可能性があります。 したがって、マルチモデルエンドポイントを使用し、マルチテナンシーの課題を解決する必要があります。 ファインチューナーは、特定のコンテキストに基づいて FM モデルを適合させ、ビジネス目的で使用します。 つまり、ファインチューナーはほとんどの場合、前のセクションで説明したすべてのレイヤーをサポートするコンシューマーでも必要です。これには、生成系AIアプリケーションの開発、データレイクとデータメッシュ、MLOps が含まれます。 以下の図は、生成系 AI エンドユーザーに提供するための完全な FM ファインチューニングライフサイクルを示しています。 次の図は、重要なステップを示しています。 主なステップは以下のとおりです。 エンドユーザーがパーソナルアカウントを作成し、プライベートデータをアップロードします。 データはデータレイクに格納され、FM が期待するフォーマットに前処理されます。 これにより、モデルをモデルレジストリに追加するファインチューニング ML パイプラインがトリガーされます。 そこから、モデルは最小限のテストで本番にデプロイされるか、手動の承認ゲートを備えた広範なテストを経てプッシュされます。 ファインチューニングされたモデルは、エンドユーザーが利用できるようになります。 このインフラストラクチャはエンタープライズ顧客以外には複雑なため、AWS はこのようなアーキテクチャの作成の労力を軽減し、ファインチューニングされた FM をより製品に近づけるために Amazon Bedrock をリリースしました。 FMOps および LLMOps のペルソナとプロセスの差別化点 前述のユーザータイプ(コンシューマー、プロデューサー、ファインチューナー)のジャーニーに基づいて、特定のスキルを持つ新しいペルソナが必要です。以下の図に示されています。 新しいペルソナは以下の通りです。 データラベラーとエディター – これらのユーザーは、&lt;テキスト、画像&gt;のペアなどのデータにラベルを付けたり、フリーテキストなどのラベルなしデータを準備したりして、アドバンスドアナリティクスチームとデータレイク環境を拡張します。 ファインチューナー – これらのユーザーは FM に関する深い知識を持ち、それらを調整する方法を知っており、クラシック ML に焦点を当てるデータサイエンティストチームを拡張します。 生成系 AI 開発者 – FM の選択、プロンプトチェーン、アプリケーション、入力と出力のフィルタリングに関する深い知識を持っています。 彼らは新しいチームである生成系 AI アプリケーションチームに属します。 プロンプトエンジニア – これらのユーザーは、コンテキストにソリューションを適合させ、テストし、プロンプトカタログの初期バージョンを作成する入力と出力のプロンプトを設計します。 彼らのチームは生成系 AI アプリケーションチームです。 プロンプトテスター – これらのユーザーは生成系 AI ソリューション(バックエンドとフロントエンド)を大規模にテストし、結果をプロンプトカタログと評価データセットの拡張にフィードします。 彼らのチームは生成系 AI アプリケーションチームです。 AppDev と DevOps – これらのユーザーは、生成系 AI アプリケーションのフロントエンド(ウェブサイトなど)を開発します。 彼らのチームは生成系 AI アプリケーションチームです。 生成系 AI エンドユーザー – これらのユーザーは、ブラックボックスとしての生成系 AI アプリケーションを消費し、データを共有し、出力の品質を評価します。 生成系 AI を組み込むために MLOps プロセスマップの拡張バージョンは、次の図のように示すことができます。 新しいアプリケーションレイヤーは、生成系 AI 開発者、プロンプトエンジニア、テスター、AppDev が生成系 AI アプリケーションのバックエンドとフロントエンドを作成する環境です。 生成系 AI エンドユーザーは、インターネット (Web UI など)を介して生成系 AI アプリケーションのフロントエンドと対話します。 一方、データラベラーとエディターは、バックエンドにアクセスすることなくデータを前処理する必要があります。 したがって、データと安全に対話するためのエディター付きの Web UI (Web サイト)が必要です。 SageMaker Ground Truth はこれらの機能をすぐに利用できるように提供します。 まとめ MLOps は、ML モデルを効率的に本番化するのに役立ちます。 ただし、生成系 AI アプリケーションを運用化するには、追加のスキル、プロセス、テクノロジーが必要で、FMOps と LLMOps につながります。 この投稿では、FMOps と LLMOps の主な概念を定義し、人材、プロセス、テクノロジーの観点から MLOps 機能との主な違いについて説明しました。 FM モデルの選択と評価、および生成系 AI アプリケーションの開発ライフサイクルについて説明しました。 今後、議論したドメインごとのソリューションの提供に焦点を当て、FM 監視(有害性、バイアス、幻覚など)やサードパーティまたはプライベートデータソースアーキテクチャパターン(検索拡張生成など) の FMOps/LLMOps への統合に関する詳細を提供する予定です。 詳細については、 Amazon SageMakerを利用したエンタープライズのためのMLOps基盤ロードマップ を参照し、 Amazon SageMaker JumpStart 事前トレーニングモデルでの MLOps プラクティスの実装 でエンドツーエンドのソリューションを試してください。 ご意見やご質問があれば、 コメント欄 にお寄せください。 著者について Dr. Sokratis Kartakis は、Amazon Web Services のシニア機械学習および運用専門ソリューションアーキテクトです。 Sokratis は、AWS サービスを活用し、運用モデル、つまり MLOps の基盤と変革ロードマップを形作ることにより、エンタープライズ顧客が機械学習 (ML) ソリューションを産業化するのを支援に集中しています。 彼は、エネルギー、小売、ヘルスケア、ファイナンス/銀行、モータースポーツなどの領域で、革新的なエンドツーエンドの ML および IoT ソリューションの発明、設計、リーダーシップ、実装に15年以上携わってきました。 Sokratis は、家族や友人と過ごしたり、バイクに乗ったりすることで余暇を過ごすのが好きです。 Heiko Hotz は、自然言語処理、大規模言語モデル、生成系 AI に特化した AI および機械学習のシニアソリューションアーキテクトです。 この役割に就く前は、Amazon の欧州顧客サービスのデータサイエンス部門の責任者を務めていました。 Heiko は、AWS で AI/ML の旅を成功させるお客様を支援しており、保険、金融サービス、メディア&amp;エンターテイメント、ヘルスケア、ユーティリティ、製造など、多くの業界の組織と協力してきました。 Heiko は、できる限り旅行するのが趣味です。 <!-- '"` --> 翻訳はソリューションアーキテクトの中島佑樹、伊藤芳幸が担当しました。原文は こちら です。

8月28日週は、AWS のテックリーダーが執筆した Amazon Elastic Compute Cloud (Amazon EC2) と Amazon Elastic Block Store (Amazon EBS) に関するすばらしい記事がいくつかありました。 Werner Vogels 博士は、クラウドコンピューティングとして今日知られているサービスの幕を開けたオリジナルバージョンの 17 年間にわたる忠実な機能を称える「 Farewell EC2-Classic, it’s been swell 」を著述しました。バックグラウンドで実行されているスタックは非常に複雑でしたが、このサービスによってコンピューティングリソースの取得プロセスがいかに簡単になったかが紹介されています。 2006 年以来、私たちは長い道のりを歩んできましたが、お客様のためのイノベーションに終わりはありません。今年の AWS Storage Day で祝われたように、Amazon EBS は 15 年前の今月にローンチされました。Amazon の SVP の職にある優れたエンジニアの James Hamilton は、「 Amazon EBS at 15 Years 」の中で、このサービスが 1 日 100 兆の I/O オペレーションを処理し、毎日 13 エクサバイトのデータを送信するまでに進化した過程を紹介しています。 Werner 博士が記事に書いているように、「進化可能なシステムを構築することは戦略であり、オープンな視点からアーキテクチャを再検討することが必須」です。 お客様からのフィードバックを原動力とするイノベーションの取り組みは今日も続いています。今週も例外ではありません。 8月28日週のリリース 私が注目したリリースを以下に記載しました。 Amazon Kinesis Data Analytics から Amazon Managed Service for Apache Flink への名称変更 – Apache Flink を使ってリアルタイムのストリーミングアプリケーションを構築および実行するためのフルマネージドのサーバーレスサービスである Amazon Managed Service for Apache Flink を使用できるようになりました。Kinesis Data Analytics で実行中の既存のアプリケーションはすべてそのまま動作します。変更を加える必要はありません。詳細については、 私のブログ記事 を参照してください。 Amazon Aurora と Amazon RDS の延長サーポート – MySQL 5.7、PostgreSQL 11、および上位のメジャーバージョンを実行する Amazon Aurora と Amazon RDS データベースインスタンスのサポートが最大 3 年延長されます。これにより、これらのバージョンのサポートがコミュニティで終了した後でも、時間の余裕をもって新しいメジャーバージョンへのアップグレードを行ってビジネス要件を満たすことができます。 AWS Step Functions Workflow Studio のスターターテンプレートの強化 – スターターテンプレートを使用して、ワークフローの作成とプロトタイプ作成のプロセスを迅速に合理化できるようになりました。さらに、新しいコードモードを使用すると、デザインビューとコード構築ビューを簡単に切り替えることができます。Workflow Studio の構築エクスペリエンスが向上した結果、ドラッグアンドドロップのビジュアルビルダーエクスペリエンスと新しいコードエディターをシームレスに切り替えて、好みのツールを選択して開発を加速することができます。 詳細については、「 構築作業を効率化する新機能による Workflow Studio の強化 」を参照してください。 Amazon SES のすべての E メールの E メール配信履歴 – 個々の E メール配信問題のトラブルシューティング、重要なメッセージの配信確認、エンゲージメントに関与する受信者のきめ細かい個々の E メール単位での識別が可能になりました。E メールの送信者は、 Amazon SES Virtual Deliverability Manager を使用して、配信パフォーマンスの傾向を調査し、送信済みの各 E メールの配信およびエンゲージメントステータスを確認できます。 Amazon SageMaker のリアルタイムインターフェイスを介したレスポンスストリーミング – インターフェイスレスポンスをクライアントに継続的にストリーミングして、チャットボット、仮想アシスタント、音楽ジェネレーターなど、さまざまな生成系 AI アプリケーションのインタラクティブエクスペリエンスを構築できるようになりました。 レスポンスストリーミングの使用方法の詳細と使用例については、AWS ドキュメントの「 インターフェイスレスポンスのストリーミングを開始する 」と「 コンテナがリクエストを提供する方法 」、および AWS Machine Learning ブログの「 Elevating the generative AI experience: Introducing streaming support in Amazon SageMaker hosting 」を参照してください。 AWS のお知らせの詳細なリストについては、「AWS の最新情報」ページを定期的にご確認ください。 AWS のその他のニュース 皆さんが見逃した可能性があるその他の更新情報とニュースを紹介します。 AI &amp; Sports: AWS と NFL がゲームにもたらす変革 – 過去 5 年にわたって、AWS は NFL (National Football League) のパートナーとして、ファンが試合をよりよく理解すること、放送局がよりよいストーリーを伝えること、そしてチームがデータを使用してオペレーションとプレーヤーの安全を改善することを支援してきました。AWS CEO の Adam Selipsky、NFL オールプロを獲得した Larry Fitzgerald 選手、NFL ネットワークの Cynthia Frelund 氏がスポーツにおける AI と機械学習の可能性について語り合うライブストリームの録画をご覧ください。 Amazon Science の Amazon Bedrock ストーリー – これは、 Amazon Bedrock を使用して、有害なコンテンツを避ける責任ある AI にフォーカスした Amazon Titan の FM を始めとする主要な基盤モデルで生成系 AI アプリケーションを構築およびスケールするメリットを紹介する優れた記事です。 Amazon EC2 の柔軟性スコア – これは、Auto Scaling グループ (ASG) を介したインスタンスのローンチに使用する設定を推奨の EC2 ベストプラクティスに即して評価するために AWS が開発したオープンソースツールです。このツールを使用すると、ベストプラクティスの適用状況を基に、構成の識別、改善、モニタリングに使用できる「柔軟性スコア」を取得できます。 オープンソースのニュースと最新情報については、私の同僚である Ricardo &nbsp;が厳選した最新のオープンソースプロジェクト、記事、イベントなどをお届けする このニュースレター をご覧ください。 AWS の今後のイベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 AWS re:Invent – re:Invent の計画はお済みですか。 今すぐ セッションカタログ を確認してください。ぜひご参加ください。AWS の最新情報を聞き、専門家から学び、グローバルなクラウドコミュニティとつながりましょう。 AWS グローバルサミット – 最後の対面式 AWS Summit が 9 月 26 日に ヨハネスブルグ で開催されます。 AWS Community Day &nbsp; – AWS ユーザーグループが主催し、お住まいの地域のコミュニティが主導するカンファレンスにご参加ください。 ニュージーランド &nbsp;(9 月 6 日)、 レバノン &nbsp;(9 月 9 日)、 ミュンヘン &nbsp;(9 月 14 日)、 アルゼンチン (9 月 16 日)、 スペイン (9 月 23 日)、 チリ (9 月 30 日) で開催されます。ランディングページにアクセスして、今後開催されるすべての AWS Community Day をチェックしてください。 CDK Day – CDK と関連プロジェクトに関するコミュニティ主導の完全バーチャルのイベントが 9 月 29 日に開催されます (英語とスペイン語)。 詳細については、ウェブサイトを参照してください 。 今後予定されている AWS 主導の対面イベント、仮想イベント や AWS DevDay などの デベロッパー向けイベント をすべて閲覧できます。 — Channy この記事は、 Weekly Roundup シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

本記事は、『 AWS SAM support for HashiCorp Terraform now generally available 』の翻訳です。 2022 年 11 月、AWS は HashiCorp Terraform の AWS Serverless Application Model (AWS SAM) サポートのパブリックプレビューを 発表 しました。パブリックプレビューでは、Terraform ユーザーがサーバーレスアプリケーションをローカルでテストするのに役立つ機能のサブセットを取り入れました。本日 (2023 年 9 月 5 日)、AWS は AWS SAM における Terraform サポートの一般提供を開始します。この GA リリースでは、サーバーレスアプリケーションのローカル開発を強化するために AWS SAM の機能セットを拡張しています。 Terraform と AWS SAM はどちらも、開発者がインフラをコードとして定義する (IaC) ことを可能にするオープンソースのフレームワークです。開発者は、コードと同じように、インフラの定義をバージョン管理および共有することができます。しかし、AWS SAM はサーバーレスに特化して設計されているため、サーバーレス開発のために設計されたコマンドラインインターフェース (CLI) が含まれています。この CLI によって、開発者はビルドツールやデプロイツールとともに、ローカルエミュレータを使用してサーバーレスアプリケーションを作成、デバッグ、デプロイすることができます。今回のリリースで、AWS SAM はこれらのツールのサブセットを作成し、Terraform ユーザーにも提供します。 Terraform サポート パブリックプレビューのブログ では、最初の Terraform サポートを紹介しました。このブログでは、ローカル開発のための AWS SAM の拡張された機能セットを紹介します。また、このブログでは ネイティブの Terraform リソース ではなく、 AWS Lambda 関数および Lambda レイヤー用の Serverless.tf モジュール を使用することで、実装を簡素化しています。 モジュールは Lambda 関数とレイヤーのデプロイメントアーティファクトを構築できます。さらに、モジュールは Terraform リソースとのインタフェースとして AWS SAM が必要とするメタデータを自動的に生成します。ネイティブの Terraform リソースを使用する場合のメタデータの設定については、 プレビューのブログ をご覧ください。 コードのダウンロード AWS SAM の Terraform サポートを試してみるために、 aws-sam-terraform-examples リポジトリにアクセスしてください。リポジトリをクローンし、ga ディレクトリに移動して始めましょう: git clone https://github.com/aws-samples/aws-sam-terraform-examples cd aws-sam-terraform-examples/ga このディレクトリには、2 つのデモアプリケーションが含まれています。api_gateway_v1 は Amazon API Gateway REST API (v1) を、api_gateway_v2 は Amazon API Gateway HTTP API (v2) を使用していること以外は、どちらも同じアプリケーションです。どちらかを選択し、そのディレクトリの tf-resources フォルダに移動します。 cd api_gateway_v1/tf-resources 特に断りのない限り、このブログでは api_gateway_v1 アプリケーションを参照します。 コードの構成 コードの構成図 Terraform では、IaC を複数のファイルに分割することができます。このため、開発者はすべての Terraform ファイルを 1 つのディレクトリに集約し、リソースファイルを別の場所に保管することがよくあります。サンプルアプリケーションも、このように構成されています。 Terraform や AWS SAM のコマンドは、 main.tf ファイルの場所、今回は tf-resources ディレクトリから実行する必要があります。AWS SAM コマンドは一般的にプロジェクトルートから実行されるため、AWS SAM にはネスト構造をサポートするコマンドがあります。ネストされたフォルダから sam build コマンドを実行する場合は、 terraform-project-root-path フラグにプロジェクトのルートへの相対パスまたは絶対パスを渡します。 ローカルでの Lambda 関数の呼び出し (local invoke) Terraform のプレビュー版では、ローカル呼び出しをサポートしていましたが、今回 Serverless.tf に対応したことで体験がシンプルになりました。デモアプリケーションには 2 つの関数があります。responder 関数は API Gateway エンドポイントのバックエンド統合で、Auth 関数はカスタムオーソライザーです。両方のモジュール定義は functions.tf ファイルで見つけられます。 responder 関数 module "lambda_function_responder" { source = "terraform-aws-modules/lambda/aws" version = "~&gt; 6.0" timeout = 300 source_path = "${path.module}/src/responder/" function_name = "responder" handler = "app.open_handler" runtime = "python3.9" create_sam_metadata = true publish = true allowed_triggers = { APIGatewayAny = { service = "apigateway" source_arn = "${aws_api_gateway_rest_api.api.execution_arn}/*/*" } } } ここで、重要なパラメーターが 2 つあります: source_path : これはローカルのフォルダを指します。これは zip ファイルではないので、Serverless.tf は必要に応じて成果物をビルドします。 create_sam_data : AWS SAM が必要なファイルとモジュールを見つけるために必要なメタデータを生成します。 この関数をローカルで呼び出すには、以下のコマンドを実行します: build を実行して、ビルドスクリプトを起動します (訳註: 変数未定義のエラーが出る場合は、 export TF_VAR_aws_region=us-west-2 などを実行して設定してください)。 sam build --hook-name terraform --terraform-project-root-path ../ local invoke を実行して、任意の Lambda 関数を呼び出します。 sam local invoke --hook-name terraform 'module.lambda_function_responder.aws_lambda_function.this[0]' Terraform プロジェクトなので、AWS SAM にどのように処理を進めるかを知らせるために、 hook-name パラメータに terraform という値を指定する必要があります。関数名は、モジュール名とリソースタイプの組み合わせです。名前がわからない場合は、名前なしでコマンドを実行してください: sam local invoke --hook-name terraform AWS SAM がテンプレートを評価します。関数が 1 つしかない場合は、AWS SAM はその関数を呼び出します。今回のように複数ある場合、AWS SAM はどの関数を呼び出すか選択肢のリストを表示します。 エラー文の例 Auth 関数 オーソライザー関数は、モックイベントとしていくつかの入力データを必要とします。api_gateway_v1 プロジェクトのモックイベントを生成するには、以下のコマンドを実行します: sam local generate-event apigateway authorizer api_gateway_v2 プロジェクトでは以下を使用してください。 sam local generate-event apigateway request-authorizer API Gateway の REST と HTTP API ではカスタムオーソライザーの扱いが異なるため、結果として出力されるイベントも異なります。今回の例では、REST は標準的な トークンオーソライザー を使用して適切な AWS Identity and Access Management (IAM) ロールを返します。HTTP API の例では、 シンプルな pass または fail オプションを使用しています。 それぞれのサンプルでは、 events/auth.json にテスト用の適切な形式のイベントがすでに含まれています。Auth 関数を呼び出すには、以下を実行します: sam local invoke --hook-name terraform 'module.lambda_function_auth.aws_lambda_function.this[0]' -e ../events/auth.json アプリケーションは変更していないので、再度 sam build コマンドを実行する必要はありません。 ローカルでの API の実行 (local start-api) 一般利用可能のリリースで、API Gateway のローカルバージョンのエミュレートができるようになりました。これらのサンプルにはそれぞれ 2 つのエンドポイントが含まれています。片方は公開エンドポイントで、もう一方はカスタムオーソライザーによって保護されています。どちらも同じレスポンスを返します: { “message”: “Hello TF World”, “location”: “ip address” } 以下のコマンドを実行して、ローカルエミュレーターを起動します: sam local start-api --hook-name terraform AWS SAM がエミュレータを起動し、ローカルテストのために 2 つのエンドポイントを公開します。 公開エンドポイント curl を使って、公開エンドポイントをテストしてみましょう: curl --location http://localhost:3000/open ローカルエミュレーターがリクエストを処理し、ターミナルウィンドウにレスポンスを表示します。エミュレーターには、Lambda 関数からのログも含まれます。 公開エンドポイントの出力例 認証エンドポイント 追加の必要なヘッダー ( myheader ) を渡して、保護されているエンドポイントをテストしてみましょう: curl -v --location http://localhost:3000/secure --header 'myheader: 123456789' エンドポイントは、”Hello TF World” というメッセージで、認可済みの応答を返します。無効なヘッダー値でもエンドポイントを試してみてください: curl --location http://localhost:3000/secure --header 'myheader: IamInvalid' エンドポイントは、Unauthorized の応答を返します。 認可されていないレスポンス パラメーター Terraform と AWS SAM を一緒に使う場合、いくつかのオプションがあります: Hook-name: Terraform を使う際にすべてのコマンドで必要になります。プロジェクトが Terraform アプリケーションであることを AWS SAM に知らせます。 Skip-prepare-infra: AWS SAM は、terraform plan コマンドを使って必要なすべての成果物の特定と処理を行います。ただし、新しいリソースが追加または変更されたときのみ実行する必要があります。このオプションは、AWS SAM が terraform plan コマンドを実行しないようにします。このフラグが渡されていても、プランが存在しない場合は、AWS SAM はフラグを無視して terraform plan コマンドを実行します。 Prepare-infra: AWS SAM に terraform plan コマンドを強制実行させます。 Terraform-project-root-path: 現在のディレクトリをプロジェクトのルートとして上書きします。絶対パス ( /path/to/project/root ) または相対パス ( ../または../../ ) を使用できます。 Terraform-plan-file: 開発者が特定の Terraform プランファイルを指定できるようにします。このコマンドは、Terraform ユーザーがローカルコマンドを使うことも可能にします。 これらのオプションを組み合わせて、長いコマンドを作成することもできます: sam build --hook-name terraform --terraform-project-root-path ../ または sam local invoke –hook-name terraform –skip-prepare-infra 'module.lambda_function_responder.aws_lambda_function.this[0]' samconfig ファイル を使ってデフォルト値を設定すると、コマンドを短縮し、 開発プロセスを最適化 することができます。新しい samconfig YAML サポートを使うと、ファイルは次のようになります: version: 0.1 default: global: parameters: hook_name: terraform skip_prepare_infra: true build: parameters: terraform_project_root_path: ../ これらのデフォルト値を設定すると、コマンドは次のように短くなります: sam local invoke 'module.lambda_function_responder.aws_lambda_function.this[0]' AWS SAM は Terraform プロジェクトであることを認識し、Terraform プランが見つからない限り準備タスクをスキップするようになりました。プランの更新が必要な場合は、-prepare-infra フラグを追加してデフォルトの設定を上書きします。 デプロイとリモートデバッグ これらのプロジェクトのアプリケーションは、通常の Terraform アプリケーションです。他の Terraform プロジェクトと同じようにデプロイしてください。 terraform plan terraform apply 現在、AWS SAM accelerate は Terraform プロジェクトをサポートしていません。しかし、Terraformは API メソッドを使用してデプロイするので、サーバーレスアプリケーションは素早くデプロイされます。サードパーティの監視と terraform apply -auto-approve コマンドを利用することで、同様の体験に近づけることができます。 ロギングについては、 sam logs コマンドを活用しましょう。1 つまたは全てのリソースのログを出力する例として、プロジェクトのデプロイ出力を参照してください。 HashiCorp Cloud Platform HashiCorp Cloud Platform は、開発者がセキュリティと状態を維持するために一元化された場所を使用して、デプロイを実行できるようにします。開発者がクラウド上でビルドを実行する場合、AWS SAM がローカルのプランファイルをローカルのテストやデバッグで使用することはできません。しかし、開発者はクラウドでプランを生成し、ローカルで開発に使用することができます。この手順については、 ドキュメント を参照してください。 まとめ HashiCorp Terraform は、AWS クラウドでアプリケーションを構築するための人気の IaC フレームワークです。AWS SAM は IaC フレームワークであり、CLI は特に開発者がサーバーレスアプリケーションを構築するのを支援するように設計されています。 このブログでは、Terraform の新しい AWS SAM サポートと、開発者が開発体験を最大化するためにこれらを一緒に使う方法について説明してきました。ローカルで単一の関数を呼び出す方法や、ローカルで API Gateway エンドポイントをエミュレートする方法、デプロイする前にローカルで Lambda オーソライザーをテストする方法などを紹介しました。最後に、アプリケーションをデプロイし、AWS SAM を使ってデプロイされたリソースを監視しました。 サーバーレスについてさらに詳しく学びたい方は、 Serverless Land もご覧ください。 翻訳は、Partner Solutions Architect の櫻谷が担当しました。

こんにちは！ アマゾン ウェブ サービス (AWS) で事業開発を担当しております、吉田です。 私は AWS の先進的なサービスが、日本の公共のお客様にどのような価値を提供できるのか、海外の事例なども参考にしながら、日本の状況や課題に合せて分かりやすくお届けするサポートをさせて頂いております。 今回は、最近利用者が増加傾向にあり、賑わいが戻っている『空港』に着目しました。新型コロナウイルス感染症の５類感染症移行後初めての夏休みということで、久しぶりに飛行機で国内や海外への旅行に出かけられた方も沢山いらっしゃるのではないでしょうか。多くの人にとって、快適な空の旅の実現には、目的地に辿り着くまでの待ち時間が少ないことが欠かせないというのは世界共通です。空港がそのような乗客体験を実現するには、データの利活用が不可欠なのです。 そこで、空港におけるデータ利活用について興味深い AWS のブログを見つけましたのでご紹介したいと思います。 合わせて、「 空港におけるクラウド活用のベストプラクティス 」を資料にまとめましたので、ダウンロードリンクより是非ご確認ください。 空港と航空会社は、データの有効活用を望んでいる 一般にはあまり知られていませんが、空港は、他空港や航空会社、グランドハンドリングエージェント（空港内でチェックイン、手荷物運搬、配車などのサービスを多くの航空会社に提供する会社）とデータを共有し、業務プロセスを改善することにおいて大いに成功しています。例えば、A-CDM（Airport Collaborative Decision Making）では、空港の遅延を10％、CO2排出量を7.7％削減するなど、このコラボレーションは効率化に大きな影響を及ぼしています。 空港はこれをさらに進めたいと考えています。大韓航空やライアンエアーなどの航空会社が、AWS を使って予防整備や機内食の予測を行うなど、データがいかに産業を変革しているかを目の当たりにしているのです（その好例が Ryanair のパニーニ予測）。正確な予測、パーソナライズ、すべての関係者間での簡単なデータ共有によって空港運営と乗客体験が向上することは、彼らには察しがついています。最近、国際空港評議会（ACI）が、”空港のデータ共有とコラボレーションは、乗客の満足度を向上させる鍵である “と述べたことは、驚くことではありません。 空港はデータプラットフォームを構築している フランスの Nice Côte d’Azur をはじめ、多くの空港が最近 AWS 上にデータプラットフォームを構築しています。データプラットフォームは、一般的に複雑なビジネスルールを持ち、高度に構造化されたデータベースである空港運用データベース（AODB）とは異なり、空港のシステム全体、航空会社、第三者からさまざまな種類の情報を吸収、理解、視覚化、予測、共有するための柔軟なデータベースなのです。 シンシナティ空港では、データを予測分析とプロアクティブな通知に利用しており、これを Enterprise Awareness &amp; Situational Exceptions（EASE）と呼んでいます。EASE は、マネージドサービスの集合体である Amazon Relational Database Service（Amazon RDS）や、サーバーレスでイベント駆動型の計算サービスである AWS Lambda などの AWS サービスを利用して、企業のあらゆる部分から構造化および非構造化データを収集します。これにより、最も異質なデータセットであっても、動的な意思決定を改善することができます。シンシナティ空港は、空港プロセスにおける職員数を改善するだけでなく、ソーシャルメディア上の感情をモニターしています。例えば乗客がオイル流出事故に関するツイートを送信した場合、ほぼリアルタイムで対応することができます。また、空港は天候や現地の交通状況もモニターしており、運航計画の調整、および乗客への注意喚起の両方を行うことができます。 シンガポールのチャンギ空港は、DIVAイノベーションラボの基盤としてデータプラットフォームを構築し、新しいコンシェルジュアプリによって乗客への情報提供を向上させ、スタッフ向けの Where-To-Clean アプリによって、空港内で最近利用者が多いエリアを優先的に清掃するなどの取り組みを行っています。 空港の手荷物搬送システムで世界をリードするも Siemens Logistics、空港のあらゆる業務データを取り込み、分析し、可視化するための航空データハブを AWS 上に構築しました。例えば、同社の Baggage360 システムは、複数の情報源を利用して手荷物データを分析し、手荷物の流れを予測します。Siemens Logistics の航空データソリューション担当ディレクター、 Stephan Poser 氏は、「手荷物の流れを監視し、手荷物の処理時間を予測し、リスクのある接続を特定し、手荷物が重要な処理工程に入る時間を予測することができます」と述べています。「私たちは、手荷物受取りのベルト上で乗客にバッグが見えるようになるタイミングまで予測することができます。」 データプラットフォームを構内に持つ空港の中には、ニーズが高まるにつれ、拡張性や新サービスの追加に限界があることを発見しているところもあります。例えば、AWS パートナーの Wipro は最近、 Toronto Pearson 国際空港のデータプラットフォームをオンプレミスシステムから AWS に移行し、スケールと俊敏性を活用し、人工知能（AI）、機械学習（ML）、ほぼリアルタイムのデータインジェストなどの新機能を追加しました。 Wipro Canada のジェネラル・マネージャーである Anudeep Kambhampati 氏は、「AWS 上の新しい Databricks Lakehouse Platform は、さまざまなソースからほぼリアルタイムのビジネスインサイトを導き出し、継続的なイノベーションを促進するのに役立ちます」と述べています。 私は、なぜ空港が最近になってデータプラットフォームの構築に乗り出したのかに興味を持ちました。この技術は以前から存在していたのに、なぜ今になって？その答えとして、欧州の 30 以上の空港で、データによる業務改善を支援している Azinq のマネージングディレクター、 Chris Taylor 氏に話を伺いました。「AWS が提供するインフラやデータサービスを活用するため、当社の顧客はクラウドベースのデータプラットフォームに急速に移行しています。空港は、旅客とステークホルダーとの関わりを理解し、改善する上でのデータの価値を長い間認識してきましたが、これまではコストや技術面での障壁のため、データプラットフォームを構築することが困難でした。AWS 上の Airport Hive プラットフォームにより、空港は運営に関する洞察を容易に得ることができ、また小さな変化が財政的にも旅客体験的にも大きな影響を与え得るということも可視化されます。AWS のスケーラビリティと弾力性は、お客様がオンプレミスの導入にかかるコストや煩わしさを回避し、長期的な成長余地を確保することに役立ちます。“ データプラットフォームは、非常に特殊な問題を解決するのに役立ちます。例えば、米国のある主要空港では、短期駐車場でタクシーが待機しているという問題がありました。これはつまり、乗客が駐車するスペースが少なくなり、空港の収益が減少することを意味します。この問題を解決するために、空港は AWS パートナーの Slalom に依頼し、過去のフライト、天候、タクシー利用者のデータを利用したデータ予測モデルを構築し、事前にタクシーの需要を予測、必要な時だけタクシーを要請するようにしました。これにより駐車場のスペースが解放され、乗客の利便性が向上、空港は運営改善により約 500 万ドルの収益を回収することができました。 データ共有の課題を克服する 空港の課題のひとつは、必要なデータへのアクセスです。空港は、空港で活動するすべての航空会社や企業から必要なデータを入手することが困難であると述べています。AWS とパートナーは、空港がこの障害を克服するのを支援しています。 AWS は、空港と航空会社との連携、データ共有を支援してきました。私たちは、乗客体験の共有にこだわることで、空港と航空会社が協力関係を築ける可能性があると見ています。例えば AWS は空港と共に、乗客の明確なペインポイントを理解した上で、それを解決するのに必要となるデータの特定を支援し、そのデータをパートナーの航空会社と共有するため、実践的なアプローチをとっています。 サードパーティ企業は、空港のオペレーションを改善するために特別にデータフィードを提供しています。例えば Passur は、AWS 上に構築された API を通じて、フライトポジション、フライト予測、フライトイベントデータなどのほぼリアルタイムのデータフィードを空港に提供しています。Passur の CEO である Brian Cook 氏は、「空港は、資産管理、キャパシティプランニング、航空会社とのコラボレーションを改善するために当社のデータを使用しています」と述べています。「当社のデータフィードは、空港に遅延を事前に通知するため、空港は混乱に対処するための業務調整を事前に行うことができます。」また、サードパーティーのデータを1つのデータカタログで簡単に見つけることができる AWS Data Exchange には、気象やフライトデータなど数千ものデータセットがあります。 いかがでしたでしょうか？ 今後空港でのデータ利活用が進み、皆様の空の旅がますます快適になることを願うばかりです。 わたしは心配性なので、「何時までにチェックインしないといけないんだっけ？」「ラウンジはあったっけ？」「この荷物は機内に持ち込めるかな」「帰りのバスはちょうどいい時間にあるのか」などなどいろいろ気にしてしまうのですが 、データの利活用が進んで空の旅がますます快適になれば嬉しいと思います。そのために AWS もお役に立てればなお嬉しいですね。 関連情報 サイト、問い合わせ お問い合わせ マイクロサイト : 公共機関における AWS 導入のためのお役立ちサイト 資料 空港におけるクラウド活用のベストプラクティス この記事を書いた人 吉田　尚子 アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター 事業開発マネージャー “AWSのサービスが、公共のお客様にどのような価値を提供できるのか、海外の事例を取り入れなが分かりやすくお届けいたします”

はじめに Amazon Web Services (AWS)上で稼働する SAP HANA ワークロードは、多くの場合、企業の中核であり、財務、調達、給与計算などの重要なビジネスプロセスを担っています。これらのシステム内のデータが確実に保護され、ディザスタリカバリを実行する必要があるシナリオのためのリカバリオプションがあることを保証するには、信頼性の高いバックアップとリストアのアプローチが不可欠です。バックアップ管理プロセスの自動化と簡素化は、一貫性のある効率的なバックアップ運用のための重要な側面です。 2012 年に AWS 上に SAP HANA データベースを初めてデプロイして以来、私たちはお客様のバックアップエクスペリエンスを向上させる方法を模索してきました。最初のステップは、 AWS Backint Agent for SAP HANA のリリースでした。これにより、お客様は Amazon Simple Storage Service（ Amazon S3 ）に直接バックアップできるようになり、”2 ステップ “アプローチの要件がなくなり、バックアップパフォーマンスが最適化されました。2023 年 5 月に、私たちはさらに一歩進んで、 Amazon Elastic Compute Cloud（Amazon EC2）上で SAP HANA 用の AWS Backup の一般提供 を発表しました。 AWS Backup for SAP HANA は、一元化されたコンソールベースのバックアップ管理を提供し、サポートされるすべての AWS リソースで一貫したエクスペリエンスを提供します。特徴としては、IAM ポリシーを使用したセキュリティの向上、専用のバックアップ保管庫、標準化された AWS モニタリングとレポート機能へのアクセス、ポイントインタイム・リストアのための継続的バックアップを最適化するインテリジェンスなどがあります。また、将来の運用活動のプラットフォームとして SAP HANA データベースの検出と登録を可能にする AWS Systems Manager for SAP を利用する最初のユースケースでもあります。 AWS Backup について AWS Backup は、様々な AWS リソースの大規模なデータ保護を簡素化する、費用対効果が高く、完全に管理されたポリシーベースのサービスです。以下は、SAP HANA にとって関心のある AWS Backup の機能です： バックアップの一元管理： データベースのバックアップスケジュール、継続的なバックアップとポイントインタイムリストア（PITR）の有効化、リカバリなどのバックアップ操作を一元管理できます。AWS Backup コンソールから他の AWS リソースとともに SAP HANA データベースリソースを管理できるため、IT ユーザーに一貫したエクスペリエンスを提供できます。 複数の AWS サービスとの統合： AWS Backup コンソールは、複数の AWS モニタリングサービスと統合されているため、バックアップステータスに基づいた監視やアクションを簡単に実行できます。 Amazon CloudWatch を使用して、AWS Backup は完了または失敗したバックアップ、コピー、およびリストアジョブのメトリクスを提供します。AWS CloudTrail は、AWS バックアップ API コールを監視するために使用できます。 AWS CloudTrail は、AWS Backup のすべての API コールをイベントとしてキャプチャする。 Amazon Simple Notification Service (Amazon SNS) を使用することで、バックアップが成功した時やリストアがトリガー/完了した時などのバックアップステータスに基づいた通知を構成できます。また、 Amazon EventBridge を使用して AWS Backup イベントを監視できます。AWS バックアップは、ベストエフォートベースのポリシーで 5 分ごとに EventBridge にイベントをトリガーします。 AWS PrivateLink を使用した VP C エンドポイントのインターフェース： AWS Backup は AWS PrivateLink をサポートしています。 AWS PrivateLink では、インターフェース VPC エンドポイントを作成することで、Amazon Virtual Private Cloud（VPC）と AWS Backup エンドポイント間のプライベート接続を確立できます。AWS Backup for SAP HANA と AWS PrivateLink により、すべてのネットワークトラフィックを AWS グローバルネットワーク内に維持しながら、安全でスケーラブルな方法で AWS Backup for SAP HANA オペレーションにプライベートアクセスできます。 バックアップボールトの暗号化：AWS Backup では、バックアップ Vault はバックアップを保存して整理するコンテナです。SAP HANA データベースのバックアップは、AWS Key Management Services（AWS KMS）を使用して暗号化された バックアップボールト に保存されます。 AWS BackupVault Lock： AWS Backup Vault Lock は、バックアップのライフサイクルの変更を防止し、バックアップの手動削除を防止する機能で、コンプライアンス要件を満たすのに役立ちます。AWS Backup Vault Lock は、Write-Once-Read-Many（WORM）モデルを使用してバックアップを保存していることを確認するセーフガードを実装しています。 AWS Backup for SAP HANA の利用をはじめるには： AWS BackupでSAP HANA のバックアップのスケジューリングを開始する前に、いくつかの前提条件があります。これらは、 AWS Backup for SAP HANA on EC2 のドキュメントで詳細に説明されており、Amazon EC2 インスタンス用の Amazon IAM ポリシーの設定、AWS Systems Manager for SAP への SAP HANA データベースの登録、AWS Backint Agent のインストールと設定、およびオプションとしてインターフェース VPC エンドポイントの設定が含まれます。これらの作業はすべて一度だけ実行すればよく、自動化も可能です。 図-1 SAP HANA バックアップの前提条件 バックアッププランとリソース割り当て： バックアップ計画は、リソースのコレクションに対するバックアップのスケジュール、頻度、保持を定義するために使用されます。これらのリソースには、Amazon EC2 上の SAP HANA が含まれ、データベースと非データベースリソースのバックアップに対する一貫したアプローチを可能にするために、重要な Amazon EC2 リソースと組み合わせることもできます。 継続的バックアップは、AWS バックアップで選択されたリソースに使用される。SAP HANA リソースが割り当てられたバックアッププランで、連続バックアップとポイントインタイムリストア（PITR）を有効にできます。このアクションは、SAP HANA のリストアに必要なフルバックアップ、差分バックアップ、ログバックアップの管理を AWS Backup に指示します。AWS バックアップは、最後のフルバックアップの日付と変更率に基づいたリカバリ時間を考慮しながら、適切であれば差分バックアップを使用し、費用対効果の高い方法でこれを行います。 図 – 2. リソースの割り当て AWS Backup の価格 AWS Backup for SAP HANA on Amazon EC2 の価格は、従量課金モデルです。例として、US-EAST-1（N.Virginia）リージョンでは、SAP HANA Backup は 1GB-Month あたり 0.06 ドル、コールドストレージに移行したバックアップは 1GB-Month あたり 0.01 ドルです。価格の詳細については、 価格ドキュメント のページを参照してください。 制限事項 現在サポートされていない機能のリストを確認するには、 リリースノート を参照してください。 推奨される実装方法 バックアップ戦略の実装または変更には、慎重な計画とテストが必要です。本番ワークロード用に設定する前に、サンドボックスや開発環境で AWS Backup に慣れることをお勧めします。信頼性と運用の柱は、SAP データを保護するためにバックアップを使用するための良い一般的なガイダンスを提供します。特に以下を参照してください。 ベストプラクティス 10.3 – 重要な SAP データの可用性を確保するためのアプローチを定義する 設計原則 12 – データ回復の計画 結論 AWS Backup for SAP HANA は、AWS 上の SAP HANA データベースのバックアップとリストア操作を簡単に実行できるようにします。AWS のお客様は、バックアップ、リストア、システムコピーなどのデータ保護アクティビティを一元管理し、自動化できるようになりました。お客様は、複数の AWS リソースとアカウントにまたがって管理を簡素化するために拡張できる、ネイティブな AWS エクスペリエンスから恩恵を受けることができます。まず、以下のドキュメントとブログをご覧ください。 Amazon EC2 インスタンス上の SAP HANA データベースのバックアップ Centrally Manage SAP HANA Database Backup Through the AWS Backup Console（英語） 何千ものお客様が AWS を信頼して SAP ワークロードの移行、近代化、革新を行っている理由については、 SAP on AWS のページをご覧ください。 クレジット 専門知識、サポート、ご指導をいただいた以下のメンバーに感謝いたします。 Sabari Radhakrishnan、Balaji Krishna、Adam Hill、Nerys Olver、Parisudh Marupurolu、Marcos Perez Seoane、Spencer Martenson. 翻訳は Partner SA 松本が担当しました。原文は こちら です。

多くのお客様はビジネスの価値や競争力を高めるために、 Amazon Web Services (AWS) にシステムをマイグレーションしています。クラウドマイグレーションによって得られるメリットの最大化を目的としたマイグレーションの実施だけではなく、アプリケーションのモダナイゼーションへの取り組みもマイグレーションと合わせて実施される傾向があります。この組み合わせにより、アプリケーションの俊敏性、拡張性、耐障害性が向上します。AWS を使用してワークロードのポートフォリオをモダナイズすることは、コンテナ、サーバーレス、目的別データストア、ソフトウェアの自動化を活用したワークロードのリプラットフォーム、リファクタリングやリプレースが可能であることを意味しています。これらの機能により、AWS の俊敏性と総コストの最適化(Total Cost Optimization, TCO)というメリットを最大限に享受いただく事が可能です。 今回の Let’s Architect！ では、ハンズオンや、お客様事例、ヒントや秘訣を共有します。そしてお客様のアプリケーションを AWS へマイグレーション・モダナイゼーションしていく際の参考にしてください。 Migrating to the cloud: What is the cost of doing nothing? クラウドマイグレーションの実現は、大企業よりも中小企業の方が早いと思っていませんか？実際は、クラウドマイグレーションのスピードは必ずしも企業規模に左右されません！企業規模はマイグレーションやモダナイゼーションの成功の明確な指標にはなりません。しかしながら、企業を進化させるためには文化と考え方の変革が不可欠です。 マイグレーションに関して言えば、何もしないことの代償は金銭的なものだけではありません。企業はイノベーションペースの低下や、セキュリティの負担増が予想されます。この動画では、マイグレーションを行うことによる財務的なメリットを分析し、AWS へのクラウドマイグレーションに取り組んでいくためのメンタルモデルを共有します。また、 マリオット のチームメンバーはどのようにマイグレーションを計画したのかということや、マイグレーションの過程で学んだ教訓を説明します。 re:Invent 2022 動画はこちら 早期にマイグレーションするメリット – re:invent 2022 の登壇資料を元にした参考訳 AWS でのレガシー .NET Framework モノリシック アプリケーションのモダナイゼーションへの道すじ 　( 原文 ) 企業等の組織の目的として、お客様のニーズに則した最高の技術的なソリューションを提供することがあります。クラウドを導入するどの段階においても、モノリシックなアプリケーションの管理と構築に終始する企業は数多く存在します。ここでは、モノリシックな .NET Framework アプリケーションから AWS 上のモダンな マイクロサービスへとマイグレーションしていく道筋を探り、モノリスアプリケーションをマイクロサービスに分割し、モノリスアプリケーションをコンテナ化する AWS のツールについて説明します。 コスト最適化もワークロードをモダナイズするための重要な要素です。この課題を解決していくには Linux ベースのシステムへの移行やオープンソースのデータベースエンジンの使用をする事などが含まれます。 Migrate and Modernize enterprise workloads with AWS という動画では、AWS を使用したエンタープライズワークロードのマイグレーションとモダナイゼーションの過程について説明します。 詳細については こちらのブログ ( 原文 )も参照ください。 マイクロサービスを用いたモダナイズ・リアーキテクチャ Implementing a serverless-first strategy in an enterprise あらゆる規模の組織が、AWS 上のサーバーレスアーキテクチャの活用で獲得可能な俊敏性、コスト削減、開発者エクスペリエンスといった恩恵を所望しています。費用対効果 (Return On Investment , ROI)は大企業にとって非常に大きなものになり得ます。しかし、セキュリティのベストプラクティスとガバナンスを確保しながら現状のアーキテクチャを克服していくことは、多くの企業が苦戦するハードルです。このライトニングトークでは、これらのハードルを克服するためにサーバーレスファースト戦略を導入していく方法を学びます。 デルタ航空 は、AWS 活用に向けた道のりの一環としてサーバーレスファーストを実現しており、その事例を共有します。 動画を視聴 サーバーレスの利点 Application Migration with AWS このワークショップは架空のアプリケーションを AWS へマイグレーションし、モダナイズする方法を紹介します: データベース移行の実施 多様な移行戦略(モノリスアプリケーションをコンテナに分解など)を使用した Web サーバーのマイグレーションとモダナイゼーション &nbsp;AWS Well-Architected Framework の運用上の優秀性、セキュリティ、パフォーマンス効率、コスト最適化といった柱に従い、デプロイしたアーキテクチャを改善する方法の解説 ワークショップにアクセス Web サーバーの様々なマイグレーション戦略 See you next time! アーキテクチャツールやリソースを参照いただきありがとうございます！ 次回はコンテナによる分散システムについて解説します。 このシリーズの他の投稿は、 AWS Architecture Blog の Let’s Architect! ページを参照ください。 本記事はアマゾンウェブサービスジャパンの畠泰三が翻訳を担当しました。原文は こちら

2023年8月、 Amazon Web Services（AWS） は VMware Explore US 2023 にグローバル・ダイヤモンド・スポンサーとして参加しました。この4日間のイベントはラスベガスで開催され、エキサイティングな発表、インサイトに満ちたセッション、ネットワーキングの機会で溢れていました。 このイベントは、 AWS のパートナーである VMware と共に、お客様のデジタルトランスフォーメーションジャーニーを支援するという我々のコミットメントが強調されました。 AWS ブースからスポンサーセッションに至るまで、 VMware Explore における当社のプレゼンスは、 VMware Cloud on AWS によって、お客様がいかに迅速かつ安全で、コスト効率の高いクラウド・ジャーニーを実現できるかを紹介しました。 本記事では、 VMware Explore US 2023 の主なハイライトについてまとめています。エキサイティングな発表内容や、 VMware Cloud on AWS のセッションにオンデマンドでアクセスできます。 クラウド変革を加速する最新の機能強化 VMware との戦略的協業は今年で6年目を迎えました。 VMware Cloud on AWS の一般提供開始以来、世界中の多くのお客様のクラウドへの迅速な移行を支援してきました。このソリューションにより、お客様は既存のインフラストラクチャとスキルセットを最大限利用しながら、クラウドの力を活用できるようになりました。 VMware Cloud on AWS の詳細については、 このビデオ をご覧ください。 今年の VMware Explore ではいくつかの重要な発表があり、以下のリストでは VMware Cloud on AWS に関する機能強化の概要を紹介します： VMware Cloud on AWS: Advanced Subscription Tier VMware Cloud on AWS Advanced subscription tier をご紹介します。この新しいサブスクリプションは、従来のサブスクリプションに代わるもので、お客様により高度なエクスペリエンスを提供します。 VMware Cloud on AWS の共同設計によるコンピュート、ネットワーク、およびストレージ機能による既存のメリットを享受しながら、クラウド管理およびセキュリティサービスにアクセスし、クラウド移行を加速することができます。 この新しいサブスクリプションでは、 VMware Aria Automation、Aria Operations、Aria Operations for Logs、Aria Migration の30日間無料トライアル、コンテキストを考慮したマイクロセグメンテーション（ L7 DFW AppID ）、分散FQDN 許可リスト、ユーザーID ベースのファイアウォール（ IDFW ）、 NSX+ Policy Management などの高度なセキュリティ機能など、 VMware の包括的なサービススイートを利用できます。 これらのサービスはすべて、 VMware Cloud on AWS ソリューションにシームレスに統合されており、すぐに使用できます。詳細については、 AWS の担当者にお問い合わせください。 ネットワーキングの強化 VMware NSX+ は、 NSX のフルマネージド SaaS （ Software-as-a-Service ） です。これにより、ネットワーク、セキュリティを提供し、運用チームが、プライベートクラウド、ハイブリッドクラウド、パブリッククラウドで、単一のクラウドコンソールから NSX サービスを利用し運用できます。 ストレージの強化 VMware Cloud on AWS は、ストレージを最適化して容量あたりのコストを削減しながら、エンタープライズグレードのパフォーマンスをトレードオフなく実現する vSAN Express Storage Architecture を発表しました。今回の発表により、 VMware Cloud on AWS は、業界初のシングルティアハイパーコンバージドインフラストラクチャ（ HCI ）ストレージソリューションを提供し、最適化されたパフォーマンス、効率性、高い回復力、次世代ストレージデバイスによる俊敏な運用を実現します。 また、 VMware Exploreでは、 Virtual Private Cloud （ VPC ） peering を通じて、お客様の Software-Defined Data Center （ SDDC ）と Amazon FSx for NetApp ONTAP の VPC を peering 可能になると発表されました。今回の発表により、2つの VPC 間のネットワーク接続により、プライベート IPv4 アドレスまたは IPv6 アドレスを使用して、 VPC 間でトラフィックをルーティングできるようになります。どちらの VPC 内のインスタンスも、あたかも同じネットワーク内にあるかのように相互に通信することができます。詳細については AWS のブログポスト をご覧ください。 災害対策およびランサムウェア リカバリの強化 VMware Ransomware Recovery は、組織が自信を持って機敏にランサムウェア攻撃から回復できるようにする、専用のランサムウェア Recovery-as-a-Service ソリューションを提供します。今回の機能強化により、お客様は最大50台の仮想マシン（ VM ）を同時に検査、管理、およびリカバリできるようになり、迅速なリカバリとダウンタイムの最小化が可能になります。 リージョン拡大 AWS は、お客様からのご要望が多い世界中のリージョンへのサービス拡大を続けています。チューリッヒとメルボルンが新たに加わり、 VMware Cloud on AWS は25リージョンでご利用可能になりました。 発表内容のより包括的なリストについては、　VMware の　 What’s New on VMware Cloud on AWS ブログポストを参照してください。 VMware Cloud on AWSセッションのオンデマンド視聴 AWS チームは、ブレイクアウト、チュートリアル、カスタマーパネル、および ask-me-anything ラウンドテーブルで構成される9つのスポンサーセッションを開催しました。以下の録画セッションをクリックしてオンデマンドでご覧ください。 AWS Keynote: Accelerate Transformation with VMware Cloud on AWS 組織を変革する準備を整えましょう。この基調講演では、シームレスなハイブリッドクラウドソリューションを実現する VMware Cloud on AWS の活用について、AWS と VMware のリーダーから話を伺います。このセッションでは、コラボレーションの最新情報、お客様の事例、ビジネス変革を推進するための思慮深いインサイトをご紹介します。 Deep Dive Tutorial: Accelerate Migration and Modernization このチュートリアルでは、移行とモダナイゼーションの専門知識を強化します。効果的な移行戦略とネットワークアーキテクチャを学ぶとともに、 VMware Cloud のシームレスな移行とワークロード最適化のための AWS サービスを習得します。 Panel: Successful Transformations with VMware Cloud on AWS このパネルセッションでは、AWS のお客様とパートナーによる実際のクラウド移行の成功事例をご紹介します。移行を加速し、デジタル変革を推進する上で VMware Cloud on AWS が果たす役割について焦点を当てています。 Are You Well Architected? Transform VMware Workload Migration with AWS このセッションでは、堅牢でスケーラブル、かつコスト効率の高い移行を実現するための実践的なインサイトを得ることができます。 AWS Well-Architected Framework を使用して VMware のワークロードを評価し、クラウド移行を設計する方法を学びます。 Using AWS AND VMware Synergy for Developer and DevOps Success AWS と VMware ソリューションの連携により、アプリケーション開発とデプロイを最適化する方法について理解を深めてください。このセッションでは、 VMware ソリューションで Amazon Elastic Kubernetes Service （ Amazon EKS ） の機能を強化する方法と、クラウド管理を合理化する方法について、エキスパートが解説します。 AWS クラウドで VMware Aria Cost を使用して、クラウドの財務と総所有コスト（ TCO ）をシームレスに管理する方法をご紹介します。 Building Advanced Storage and Network Architectures 弾力性のあるクラウド インフラストラクチャを構築する方法を学び、 vSAN、 Amazon FSx for NetApp ONTAP を使用した最適なストレージに関するインサイトを得ます。また、 AWS Direct Connect、 AWS Transit Gateway、 VMware Transit Connect を使用した効率的なネットワーキングについても学びます。 VMware Cloud on AWS を使用して、セキュリティ、マルチテナント、およびスケーリングに関する高度なテクニックを習得します。 Accelerate Data Center Exit with VMware Cloud on AWS for Public Sector 公共部門向けにカスタマイズされた VMware Cloud on AWS は、FedRAMP および米国国防総省の Impact Level 5 （ IL5 ） 認可を満たしながら、政府機関のワークロードの移行、モダナイゼーション、およびインフラストラクチャサービスを加速する方法についてご説明します。他の期間と共同で大規模なプロジェクトを完了したエキスパートから、データセンターの退避とクラウド移行に関するインサイトを得ることができます。 AWS と VMware ：6年にわたる共同イノベーションとその成果 AWS と VMware は、シームレスで統合されたハイブリッドクラウドソリューションをお求めのお客様に、両社の長所を提供することに専念しています。 VMware Explore US 2023 の AWS ブースにお越しいただいた皆様、スポンサーセッションにご参加いただいた皆様に感謝申し上げます。 最新のイノベーションをより深く知りたい方は、 VMware の What’s New on VMware Cloud on AWS ブログポストをご覧ください。 VMware Cloud on AWS に関するその他のセッション（ VMware 主催のセッションを含む）については、 VMware Video Library でご覧いただけます。 VMware Cloud on AWS がクラウドへの移行をより早く、安全で、かつ費用対効果の高いものにするために、どのように役立つかについての詳細は、 VMware の Web サイトをご覧ください： VMware Cloud on AWS website (AWS) VMware Cloud on AWS website (VMware) @vmwarecloudonaws (X/Twitter) 翻訳はソリューションアーキテクト　澤が担当しました。原文は こちら です。

このブログ記事は、Epic Games の Senior Product Specialist である Michael Muir 氏と共同執筆したものです。 図 01: Epic Games の Unreal Engine は、リアルタイムのコンテンツ生成、操作、レンダリングを提供します。 はじめに Epic Games の Unreal Engine は、リアルタイム 3D コンテンツの作成と操作に革命をもたらしました。Unreal Engine 5 の Lumen や Nanite などの技術的進歩により、没入感の高い忠実度とリアルなインタラクティブエクスペリエンスが飛躍的に向上し、テレビや映画からゲーム、建築、エンジニアリング、建設 (AEC) に至るまで、さまざまな業界で活用されています。 Unreal Engine の主な利点の 1 つは、アーティストがリアルタイムで最終クオリティ、またはそれに近いクオリティで作業できることです。しかしながら、このリアルタイムワークフローの利点は、アーティストがショットのレンダリングやその他のパイプラインプロセスが完了するのを待たなければならないとなると、途端にに失われてしまいます。Windows、Linux、macOS ベースのレンダーファーム向けのハイブリッド型の業務管理およびコンピュートマネジメントソフトウェアである AWS Thinkbox Deadline は、この問題の解決に役立ちます。レンダリングなどのプロセスをコンピュートファームにオフロード可能になるため、クリエイティブチームはその分、アーティスティックな課題に集中できるようになります。 この度、AWS Thinkbox は Epic Games と共同で、新しいさまざまな機能を網羅したプラグインのセットを発表しました。この新しいプラグインを使うと、レンダリングなどの一般的なタスクを Unreal Engine 内から直接 Deadline にサブミットすることができます。サブミット内容に関する固有の情報は、新しい Deadline Job Preset Asset タイプによりプロジェクト内に保持されます。Unreal Engine の Movie Render Queue のリモートレンダーを Deadline がサポートしたことによって、ユーザーはキューをすぐにサブミットし、ローカル、リモート、またはクラウドベースの Workers 上でレンダリングできます。また、新しい API セットにより、制作やワークフローのニーズに合わせて、より幅広いカスタムパイプライン処理機能がサポートされるようになりました。 “新しい Deadline プラグインで、 Unreal Engine 内からアーティストフレンドリーな方法で GPU レンダーファームにサブミットできるようになったことをうれしく思います” – Peter Nofz, VFX Supervisor, Rodeo FX 図 02: Deadline へのサブミットは Unreal Engine 内から直接行うことができます。 “ Deadline for UE5 プラグインは、エキサイティングな（そして必要とされていた）レンダーパイプラインを効率化するための次のステップです! ” – Aythan Maconachie, Tech Lead, Glitch Productions Deadline のセットアップ プラグインを使用して Deadline を Unreal Engine 環境に統合するには、以下の要件が必要です。 Deadline Repository の 10.3.0 またはそれ以降のバージョンのインストール。Deadline のインストール手順については、 こちら をご覧ください。 コンテンツを生成し、サブミットするための Unreal Engine のアーティストワークステーション（Unrealのバージョン 5.2.0 以降であること）。Unreal の新しいバージョンでプラグインをリビルドする必要がある場合は、Visual Studio Code 2022 などの開発環境も必要になります。Unreal Engine を開発用にセットアップする方法については、 こちら をご覧ください。 Unreal Engine のアーティストワークステーションに Deadline Client ソフトウェアがインストールおよび 設定済み であること。本ガイドでは、Deadline Client によるサブミット方法を使用しています。 ステップ 1: プラグインのインストール Unreal Engine のプラグインは Deadline Repository 内で提供されます。これらは Unreal Engine のプロジェクトにコピーする必要があり、今後作成する新規のプロジェクトごとにこの手順を繰り返す必要があります。 Unreal Project のフォルダー内に「 Plugins 」のサブフォルダーを作成します。 Deadline Repository のインストール画面に移動し、 &lt;Deadline Repository&gt;\plugins\UnrealEngine5\UnrealEnginePlugins にある Unreal Engine のプラグインフォルダーに移動します。 &nbsp; UnrealDeadlineService と MoviePipelineDeadline プラグインフォルダーを各プロジェクトの「 Plugins 」フォルダーにコピーします。 図 03: Unreal Engine プロジェクトに両方のプラグインを提供します ステップ 2: プラグインの有効化 プロジェクトのファイル構造内にあるファイルの保存先にプラグインがコピーされた状態で- Unreal Engine を起動し、対象のプロジェクトをロードします。 Unreal Deadline Service プラグインと Movie Pipeline Deadline プラグインの両方が Unreal Engine Editor にロードされていることを確認してください。 図 04: Unreal Engine 内の Deadline プラグインの設定 メインメニューからプラグインブラウザを開きます。 [Edit] &gt; [Plugins] 検索ダイアログで「 Deadline 」を検索します。 Unreal Deadline Service プラグインと Movie Pipeline Deadline プラグインの両方を有効にして、Editor を再起動します。 プラグインのビルドに使用されたバージョンよりも新しいバージョンの Unreal Engine を使用する場合は、その特定のバージョンと一致するようプラグインをリビルドする必要があります。確認を求められた場合は「 Yes 」と返してください。 図 05: Unreal Engine のバージョンと一致するプラグインのビルドを要求する確認画面 注： このプロセスが失敗した場合、よくある原因としては、開発環境の不備、つまり Visual Studio 2022 が整備されていない可能性があります。この リンク の詳細が示す Unreal Engine の要件に従って開発環境をアップデートする必要があります。このような問題の原因分析に役立つ詳細ログは、「 &lt;Unreal_Project &gt;/Saved/Logs 」フォルダーより確認できます。 ステップ 3: Unreal 内の Deadline Service プラグインの設定 Deadline Service プラグインは、Unreal Engine と Deadline 間の通信環境を設定するために使用されます。 Deadline Serviceを設定するには: [ Edit ] &gt; [ Project Settings ] に移動します。 ブラウザで「 Deadline 」を検索し、「 Plugins – Deadline Service 」を表示させます。 図 06: Deadline Service のオプション Deadline Command の有効化オプションは、Deadline とへサブミットする際にプラグインが使う通信のデフォルトの（推奨された）方法です。もう1つの方法は、ホストアドレスを利用して Deadline Web Service 経由で通信する方法ですが、このブログでは取り上げていません。 Deadline Service プラグインの基本設定が完了したら、さらに Unreal Engine 内のスクリプトに対して指定ディレクトリパスを設定することもできます。 &nbsp;[ Script Category Mapping s ] を追加します。 実行時に Deadline Data Asset によって解決されるディレクトリを示す key-value ペアを入力します。 ステップ 4: Data Asset ノードを使った Deadline ジョブの Preset Preset は Deadline のジョブサブミットの基礎となるもので、ジョブやタスクをサブミットする前に必ず Preset を作成する必要があります。Deadline ジョブの設定は、新しい「 DeadlineJobPresetLibrary 」クラスを使用して、Data Asset として Unreal Engine プロジェクト内に保存されます。Data Asset ノードを使うと、Deadline ジョブのサブミット用として、このプロジェクト内で再利用できる Preset を定義することができます。これらの詳細には、ジョブ名、コメント、ジョブの処理が可能な Workers の Group および Pool 、フレームレンジ、およびその他の追加情報が含まれます。 Deadline の Data Asset を作成するには: Content Browser を右クリックして、[ Miscellaneous ] &gt; [ Data Asset ] を作成します。 「 DeadlineJobPresetLibrary 」クラスを検索します。 新しい Data Asset には、「BasicDeadlineExport」など、目的を表す名前を付けます。 Job Options を展開し、Deadline ジョブの詳細を入力します。 新しい Preset 要素に、「Sequence export from Movie Render Queue」などの説明を付けます。 図 07: Deadline Data Asset は、Deadline ジョブ設定の Preset を指定するために使用されます ［ Job Info ］を展開して、Deadline ジョブの詳細を入力します。 ［ Batch Name ］はサブミットされるジョブの総称です。 ［ Group ］とは、ジョブにアサインされる UE リソースのグループのことです。 ［ Pool ］とは、ジョブにアサインされる UE リソースのプールのことです。 Plugin Info Preset を使って、後にプログラムで使用できるように追加の key-value ペアの入力が可能になります。以下は必須エントリ 2 つと推奨エントリ 1 つです。 Executable : タスクを処理させたいアプリケーションへのパス。&lt;Unreal_Install_Folder&gt;\Engine\Binaries\Win64\UnrealEditor-Cmd.exe など ProjectFile : 処理するプロジェクトファイルへのパス。&lt;Unreal_Project&gt;\ProjectFile.uproject など CommandLineArguments は任意ですが、非常に便利です。Unreal Engineの全コマンドライン引数については、 こちら をご覧ください。 Data Asset を保存します。 さらに、ジョブ Preset 内の各 Deadline オプションについては表示/非表示フラグを設定できます。これによりチームリーダーは、特定のオプションを、ジョブサブミット時にユーザーに対して表示または非表示にすることができます。表示/公開されているオプションは、ユーザーがジョブをサブミットする際に、Submitter 内で編集可能です。詳細については、「ステップ 5a: Movie Render Queueによるリモート実行」のセクションを参照してください。 注: 値データをクオートで囲む記述はサポートされていません。 ステップ5: Movie Render Queue によるレンダリング Movie Pipeline Deadline プラグインをインストールすると、Unreal Engine からショットやシーケンスの Movie Render Queue パイプラインを外部にサブミットして、Deadline 経由でレンダリングできます。Movie Render Queue内でのレンダリングには Warm Up Frames のような機能があるため、Unreal Engine はキューアイテムに合わせて同等に Deadline タスクを作成します。他の 3D・2D アプリケーションでは通常、フレーム単位でタスクを扱いますが、ここでは大抵ショット全体を 1 つのタスクとして扱います。 Deadline を Movie Render Queue の処理に対応できるように設定するには: Project Settings画面を開きます。[ Edit ] &gt; [ Project Settings ] 「 Movie Render Pipeline 」で検索し、[ Plugins] &gt; [ Movie Render Pipeline ]を表示させます。 &nbsp; [ Default Remote Executor ] の項目で「 MoviePipelineDeadlineRemoteExecutor 」を選択し、リモートレンダリングを実行するデフォルトの方法として Deadline を有効にします。 &nbsp; [ Default Executor Job ] の項目で「 MoviePipelineDeadlineExecutorJob 」を選択し、Deadline プラグインが Movie Render Queue UI 内で設定を表示できるようにします。 図 08: Deadline よりリモート実行できるように設定された Movie Render Queue シーケンスまたはショットを Deadline にサブミットするには、次の 2 つの方法があります。 ステップ 5a. Movie Render Queue によるリモート実行 Movie Render Queue を使用して、Deadline レンダリング向けにショットやシーケンスをサブミットすることができます。 図 09: Deadline でリモートレンダリングを実行するように設定された Movie Render Queue Movie Render Queue を使用してレンダリングするよう設定するには Movie Render Queue を開きます。 [ Windows ] &gt; [ Cinematics ] &gt; [ Movie Render Queue ] [ +Render ] ボタンをクリックしてシーケンスまたはショットをジョブキューに追加する、あるいは既存のショットの MoviePipelineQueue をロードします。 右側の Deadline ウィンドウからジョブの Batch Name を設定します。 同じく右側の Deadline ウィンドウ内で、レンダリング設定の制御に使用する Preset Library を選択します。 任意で、新しいアウトプットディレクトリとファイル名を指定します。 Preset Overrides のセクションでは、Deadline Data Asset のプリセットを変更することなく、現行レンダリングの Deadline Job Preset で表示されているパラメータを変更することができます。 Preset Overrides セクションでオーバーライドを作成するには: オーバーライドするパラメータの横にあるチェックボックスを選択します。 編集可能なフィールドに必要な変更を加えます。 上の例では、ユーザーは Submitter 内の 2 つのオプション（ジョブの［ Comment ］および［ Department ］の情報）を上書きしています。 レンダリングを Deadline にサブミットするには、[ Render (Remote) ] を選択して Unreal Engine に Deadline ジョブの作成を指示します。ここでは、ジョブが Deadline にサブミットされる間、コマンドラインコンソールが数秒間表示されます。 ステップ 5b. Queue Asset Submitter によるリモート実行 レンダリングジョブを Deadline にサブミットするもう 1 つの方法は Queue Asset Submitter を使用する方法です。Deadline プラグインを有効にした後に Unreal Engine メニューバーの Deadline メニューの下に表示されます。 図 10: Deadline でレンダリングをリモートで実行するように設定された Queue Asset Submitter Queue Asset Submitter を使用してレンダリングをリモートで実行するには： Queue Asset Submitter を開きます。［Deadline］ &gt; ［Submit Movie Render Queue Asset］ ジョブの［Batch Name］を設定します。 上記ステップ 4 にて Data Asset ノードを使ってジョブ情報を定義した Deadline ジョブの Preset に、［Submission Preset Name］と［Remote Preset Name］を設定します。 ［Queues］セクションで 「+」を選択し、Movie Render Queue のショット/シーケンスと関連情報をカプセル化した MoviePipelineQueue アセットを追加します。 [Submit] を選択して、ジョブを Deadlineに サブミットします Deadline のジョブと Workers Deadline Monitor アプリケーションを開くと、レンダリング待ちキューに自身のジョブと、他のユーザーがサブミットしたファーム内の他のジョブが確認できます。 図 11 : バッチ、ジョブ、タスクを表示した Deadline のモニター。Batch Name の「Meerkat」の下にネストされたジョブの「Main_SEQ」と、Movie Render Queue のエンティティごとに作成されたタスクが表示されています。 Deadlineに接続しているすべての Worker に Unreal Engine のタスクを割り当てることは可能ですが、Unreal Engine のタスクを扱う能力のある Worker にだけその作業が割り当てられるように、Worker の Pool と Group を正しく設定する必要があります。 Worker には以下の要件が必要です。 GPU など、目的とするタスクに適したハードウェア。 Deadline Data Asset &nbsp;が定義した場所に Unreal Engine&nbsp; (および関連要件) がインストールされていること。 Deadline Data Asset が定義した Unreal Engine のプロジェクトへのアクセス。 ジョブに関連する適切な Deadline の Group と Pool に 所属していること。 クラウドレンダリング Deadline では、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを追加の Worker としてプロビジョニングすることで、レンダリングをクラウドに自動的かつ柔軟に拡張することができます。これらのクラウド Worker は必要に応じて立ち上げてタスクを実行させ、アイドル状態になると自動的にシャットダウンさせることができます。このコンピューティングには従量課金モデルが採用されます。 AWS の伸縮性のあるレンダリングを利用することには多くの利点があります。 変動コスト型の「オンデマンド」モデルでは、レンダーファームの固定費に対する多額な先行投資や、電力、冷却、スペース、セキュリティ面での継続的な所有コストが不要になり、ファームのコストを簡素化できます。 &nbsp;新しい GPU インスタンスを含む最新の AWS インスタンスを使用するよう、即時にレンダーファームを切り替えることができます。これにより、Unreal Engine などの製品にとって肝要な GPU や CPU 技術の進歩のペースより通常はるかに長い、ハードウェアの更新サイクルが不要になります。 レンダーファームのインフラストラクチャは、デザインチームの規模や絶えず変化する制作のニーズに応じて瞬時に動的スケーリングすることができます。これにより、制作のピークに備えてマシーンを事前に予測・管理・購入する必要がなくなります。 AWS は、32 のグローバルリージョンにわたって、レンダリング用のコンピューティングを含む 200 を超えるフル機能のサービスを提供しており（執筆時点現在）、それぞれがデータとサービスの冗長性と可用性を確保するために複数のアベイラビリティゾーンを提供しています。AWS Site-to-Site VPN、または AWS Direct Connect（AWS への専用ネットワーク接続）を利用することで、Unreal Engine のプロジェクトデータを処理前にレンダリングの Workers に同期し、完了時に結果の画像やアーティファクトを元に戻すことができます。 図 12: ストレージソリューションとして Perforce を利用したバーストレンダリングシナリオのアーキテクチャ例 今後のブログ記事で Unreal Engine のクラウド Worker へのデータ展開方法を説明する予定ですのでご期待ください。 まとめ 本記事では、チームが Unreal Engine を使用して、レンダリングなどの処理をアーティスト端末から Deadline ベースのレンダーファームにオフロードする方法について詳しく説明しました。Unreal Engine のタスクを、他の 3D や 2D のパイプラインのプロセス全体とともに 1 つのジョブの流れに統合し、その Group 内の優先順位に従ってスケジューリングできるようになりました。アーティスト端末などのオンプレミスリソースをより大きなコンピューティングリソースプールに統合することで、Unreal Engine やその他のアプリケーションが利用可能なコンピューティング能力を最大化することができます。Deadline との新たなインテグレーションにより、Unreal Engine は AWS クラウドを活用することで、プロジェクトの必要に応じて即座にスケーリングが可能になりました。 AWS Thinkbox Deadline の Unreal Engine Plugin に関して、潜在的な問題を報告、または、機能追加の提案をしたい場合は、Thinkbox Support 宛てに E メールで連絡してください : support@awsthinkbox.zendesk.com . 参考資料 Unreal Engineに関する情報は、以下からご覧いただけます。 https://www.unrealengine.com/ Deadlineに関する詳細なドキュメントは、以下からご覧いただけます。 https://www.awsthinkbox.com/deadline ワークステーションとレンダリングマシンの両方の GPU 稼働率を把握することで、効率が評価しやすくなります。以下のブログでは、AWS での分析に役立つ GPU データのログをセットアップしてキャプチャする方法について詳しく説明しています。 https://aws.amazon.com/blogs/machine-learning/monitoring-gpu-utilization-with-amazon-cloudwatch/ Unreal Engine について Epic Games の Unreal Engine は、世界で最もオープンで先進的なリアルタイム 3D ツールです。ゲーム、映画、テレビから放送やライブイベント、そして建築、自動車、シミュレーション、その他業界に至るまで、クリエイターたちは、最先端のコンテンツ、インタラクティブなエクスペリエンス、没入感のある仮想世界を提供するために Unreal を選んでいます。 @UnrealEngine をフォローし、unrealengine.com から Unreal を無料でダウンロードしてください。 Rodeo FX について Rodeo FX は、Montreal’s Top Employers に何度も選ばれ、2022 年の Mercuriades Awards では Employer of the Year に選ばれた、視覚効果・広告・アニメーション・体験型のサービスを提供するハイエンドのクリエイティブ企業です。昨年、「ストレンジャー・シングス 未知の世界」シーズン 4、「ウィッチャー」シーズン 2、および「ファウンデーション」シーズン1のシリーズ作品で 3 つのエミー賞にノミネートされ、最近では「ロード・オブ・ザ・リング：力の指輪」の第 1 シーズンでもノミネートされました。アカデミー賞を受賞した独立系企業である同社では、モントリオール、ケベックシティ、トロント、ロサンゼルスやパリのスタジオで 800 人近くのアーティストが制作にあたっています。Rodeo FX は、Netflix、HBO、Disney、Marvel、Amazon Studios、Warner Bros. やソニーなどの世界最高のストーリーテラーのクリエイティブパートナーであり、また YouTube、NBC、Apple の広告でもコラボレーションしてきました。現在取り組んでいる作品には、「ブルービートル」や「ファウンデーション」シーズン 2などがあります。最近リリースされた作品としては、「ウィッチャー」シーズン 3、「ジョン・ウィック：コンセクエンス」、「リトル・マーメイド」、「ガーディアンズ・オブ・ギャラクシー：VOLUME3」、そして同社が 2023 年の VES 賞を受賞した「ラブ、デス &amp; ロボット」Vol. 3 があります。 Glitch Productions について Glitch Productions は、シドニーを拠点とする独立系アニメーションスタジオで、世界中の何百万人ものファンに視聴されているオンラインコンテンツを制作しています。わずかな予算と時間で素晴らしいビジュアルの作成を可能にする Unreal Engine とリアルタイムレンダリングは、同社の成功に大きく貢献しています。Glitch Productions の現在の人気シリーズ「Murder Drones」は、同社の YouTube チャンネル で無料公開されています。 参考リンク AWS Media Services AWS Media &amp; Entertainment Blog　(日本語) AWS Media &amp; Entertainment Blog　(英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 翻訳は BD 山口、SA 森が担当しました。原文は こちら をご覧ください。

ハイブリッドクラウド戦略は、お客様に管理とガバナンスの課題をもたらします。これらの課題には、ハイブリッドな VMware Cloud on AWS (VMC) 環境とクラウド環境全体で一貫したクラウドセキュリティとコンプライアンスポリシーを維持すること、オペレーションデータを視覚化して処理するための単一画面の提供、複数のクラウド環境にわたるクラウドインフラストラクチャの導入の自動化と制御の提供が含まれます。 VMware Cloud on AWS を使用すると、VMware ワークロードを AWS で実行されている VMware が管理する Software-Defined Data Center (SDDC) に迅速に移行し、アプリケーションのリプラットフォーム (Replatform) やリファクタリングを行わずにオンプレミスのデータセンターを拡張できます。これにより、お客様は VMware の SDDC をデプロイし、AWS のグローバルインフラストラクチャ上の vSphere ワークロードをマネージドサービスとして使用できます。SDDC の仮想マシン (VM) から AWS のネイティブサービスを使用すると、ワークロードの俊敏性とスケーラビリティを高めながら、オペレーションオーバーヘッドを削減し、総所有コスト (TCO) を削減できます。 AWS Systems Manager (SSM) は、AWS、ハイブリッド、またはマルチクラウド環境向けの安全なエンドツーエンドの管理ソリューションです。このソリューションでは、Systems Manager のノード管理機能を使用して、ハイブリッド VMware Cloud on AWS 環境でコンピューティングリソースをリモート管理する方法を示します。 このソリューションでは、インベントリの収集や安全なセッションの開始など、Systems Manager による一元的なノード管理を行う方法を示します。 Amazon EC2 のパッチ自動化が VMware Cloud on AWS でシームレスに機能する方法と、一元化されたインターフェイスから VMware Cloud on AWS VM へのサードパーティパッケージのインストールとその後のプロビジョニングの両方を自動化する方法を紹介します。 インストール &nbsp; VMware Cloud on AWS 環境のセットアップ VMware Cloud on AWS の設定には、2 つのアカウントが必要です。1 つ目は VMware Cloud SDDC アカウントです。これは SDDC または VMware Cloud on AWS リソースを実行する AWS アカウントで、VMware が所有および運用しています。2 つ目に必要なアカウントは、お客様所有の AWS アカウントです。このアカウントを SDDC に正常にアタッチするには、そのアカウント内に少なくとも 1 つの Amazon Virtual Private Cloud (Amazon VPC) が必要です。この VPC を Connected VPC と呼びます。VMware Cloud SDDC のデプロイで説明されている 手順 に従って VMware Cloud SDDC アカウントをプロビジョニングすると、この VPC 内の AWS サービスに高帯域幅で低レイテンシーでアクセスできるように、Connected VPC に AWS Elastic Network Interfaces (ENI) が設定されます。 このソリューションでは、まず VMware Cloud SDDC アカウントと、Connected VPC アカウントの設定から始めます。Connected VPC アカウントで VPC を設定し、 AWS Resource Access Manager (AWS RAM) を使用して、共有されている AWS Transit Gateway に AWS Transit Gateway アタッチメント 経由でこの VPC を接続します。次に、この Transit Gateway は、VMware が提供する Transit Gateway である VMware Transit Connect とピアリングされ、このピアリングによって、Connected VPC アカウント内の VPC は VMware Cloud SDDC に接続されます。 Systems Manager エージェントを VMware Cloud SDDC 内の VMware Cloud on AWS 仮想マシン にデプロイし、お客様のワークロードアカウントで実行されている Systems Manager サービスに接続します。この設定により、Systems Manager のノード管理機能を使用してハイブリッド VMware Cloud on AWS 環境のコンピューティングをリモート管理し、ノードの一元管理と運用管理機能の両方を実現できます。 Systems Manager のセットアップ ハイブリッド環境用の Systems Manager の設定 — 他のクラウド環境の VM を含むハイブリッド環境の運用と管理を一元化するように Systems Manager を設定するには、次の 手順 に従います。 Systems Manager 用の VMware Cloud on AWS 仮想マシン の設定が完了すると、ハイブリッドマネージドノード (つまり VMware Cloud on AWS 仮想マシン) の ID は、プレフィックス「mi-」が付いた Amazon Elastic Compute Cloud (Amazon EC2) インスタンスと区別されます。Amazon EC2 インスタンス ID にはプレフィックス「i-」を使用します。 次の図は、このセットアップのソリューションアーキテクチャを示しています。 図1: Systems Manager による集中型運用管理のアーキテクチャ フリート管理 Systems Manager の機能の 1 つである Fleet Manager を使用すると、個々のノード (サービス、デバイス、またはその他のリソース) にドリルダウンして、ディスクやファイルの探索、ログ管理、コンソールからのユーザー管理などの一般的なシステム管理タスクを実行できます。 Systems Manager コンソール に移動し、左側のパネルで Fleet Manager を選択します。メインコンソールの Managed nodes パネルで、プレフィックス「mi-」の付いた VMware Cloud on AWS 仮想マシン を選択します。管理対象ノードをドリルダウンすると、仮想マシンに接続されているボリュームに保存されているフォルダとファイルデータに関する情報を表示できます。これには、インスタンスに関するリアルタイムのパフォーマンスデータや、 仮想マシン上のオペレーティングシステム (OS) ユーザーアカウントの管理などの情報が含まれます。 図 2: Systems Manager Fleet Manager を使用した管理対象ノードとしての VMware Cloud on AWS 仮想マシン 図 3: Systems Manager を使用した VMware Cloud on AWS 仮想マシン ノードの詳細 パッチ管理 Systems Manager の機能の 1 つである Patch Manager は、管理対象ノードにセキュリティ関連の更新とその他の種類の更新プログラムを適用するプロセスを自動化します。 Systems Manager コンソール に移動し、左側のパネルで [ Fleet Manager ] を選択します。メインコンソールの [ Managed node ] パネルで、プレフィックス「mi-」の付いた VMware Cloud on AWS 仮想マシン を選択し、次の手順を実行します。 ステップ 1: 下部のパネルから [ Tags ] を選択し、VMware Cloud on AWS 仮想マシン にタグキーと値を追加します。 ステップ 2: こちらの 手順 に従い、タグを使用して管理対象ノードをパッチグループに追加し、ステップ 1 と同じタグキーを PatchGroup タグキーのタグ値として使用するようにします。 AWS CloudFormation コンソールに移動し、 aws-patch-manager-v1.yaml CloudFormation テンプレートを 起動します 。パラメータには、上記のステップ 1 のタグキーを VmcTagKey パラメータの値として指定します。 このテンプレートは、毎週実行される Systems Manager State Manager アソシエーションを作成し、「AWS-RunPatchBaseline」自動化ドキュメントを使用して、タグ付けされた VMware Cloud on AWS 仮想マシン に対しパッチグループに関連付けられたパッチベースラインを適用します。テンプレートが正常にデプロイされたら、State Manager コンソールに移動し、右側のパネルで「PatchVmsWeekly」というサフィックスが付いた名前のアソシエーションを選択して、VMware Cloud on AWS 仮想マシン のパッチ適用をテストできます。[ Apply Association now ] ボタンを選択すると、VMware Cloud on AWS 仮想マシン のオンデマンドパッチ適用が開始されます。 以下の図は、VMware Cloud on AWS 仮想マシン のパッチ適用ステータスが非準拠から成功ステータスへと変わる様子を示しています。 図 4: パッチベースラインが適用される前の非準拠のパッチ適用ステータスを示す VMware Cloud on AWS 仮想マシン 図 5: Systems Manager Patch Manager によるパッチ適用中の VMware Cloud on AWS 仮想マシン 図 6: Systems Manager Patch Manager によるパッチの適用が成功したことを示す VMware Cloud on AWS 仮想マシン 図 7: Systems Manager Patch Manager のコンプライアンスレポートによるパッチの適用が成功したことを示す VMware Cloud on AWS 仮想マシン パッケージの配布 お客様は、CrowdStrike、TrendMicro、Tenable などのサードパーティのエージェントベースのパッケージや脆弱性管理ツールを日常的に活用して AWS 環境を保護しています。AWS は、 AWS Systems Manager Distributor (Distributor) によるサードパーティエージェントの配布をサポートしています。Distributor では、独自のソフトウェアをパッケージ化したり、Amazon CloudWatchAgent などの AWS 提供のエージェントソフトウェアパッケージを見つけて、お客様の VMware Cloud on AWS 環境を含む AWS Systems Manager マネージドインスタンスにインストールすることができます。 以下の手順に従って、サードパーティソフトウェア用のパッケージを作成し、Amazon S3 にアップロードします。このブログ記事では、s3-examplepackage-[ accountid ]-[ region ] という名前の Amazon S3 バケットを使用しています。サンプルパッケージフォルダの S3 バケットにアップロードされたステップワイズインストラクションのサンプルパッケージを使用して、ソリューションをデモンストレーションします。 サンプルパッケージ には、完成した JSON マニフェストと 3 つの.zip ファイルが含まれています。次の図は、S3 にアップロードされたカスタムパッケージを示しています。 図 8: VMware Cloud on AWS 仮想マシン にインストールするカスタムパッケージを含む S3 バケット AWS CloudFormation コンソール に移動し、こちらの 指示 に従って aws-centralizedssmdistributor-v1 CloudFormation テンプレートを使用して CloudFormation スタックを起動します。このテンプレートを使用すると、カスタムパッケージを、AWS Organizations の各メンバーアカウントの Distributor コンソールの Owned by me タブから Systems Manager Automation ドキュメントとして利用できるようになります。次に、各メンバーアカウントに State Managerーアソシエーションをプロビジョニングし、アソシエーションで指定されたスケジュールとタグに従ってそのアカウントにパッケージをインストールします。テンプレートは以下のパラメータを取ります。 PackageName: パッケージの名前 s3PackageBucket: パッケージコンテンツがアップロードされる S3 バケットの名前 (例: s3-examplepackage-[ accountid ]-[ region ]) s3PackageBucketFolder: マニフェストがアップロードされる S3 バケットフォルダーの名前 (例:SimplePackage2) s3PackageUrl: パッケージの内容がアップロードされるプレフィックスを含むバケットの HTTPS URL (例: https://s3-examplepackage-[ accountid ]-[ region ].s3 [ region ]. amazonaws.com/examplepackage) Version: マニフェストファイルの正確なバージョン名を指定します (例:1.0.2) AssociationName: アソシエーションの名前 Action: パッケージをインストールするかアンインストールするかを指定します。(例:In-place update) InstallationType: インストールの種類を指定します (例:Install または Uninstall) Outputs3Prefix: AWS Systems Manager の実行コマンド出力に使用される S3 キープレフィックス (“Default”) ScheduleExpression: AWS Systems Manager アソシエーションのスケジュール式。(例:「料金 (30 分)」) TargetResourceTagKey: ターゲットの AWS Systems Manager タグキー (パッケージを VMware Cloud on AWS 仮想マシン にのみインストールしたい場合は VmcTagKey を指定します) TargetResourceTagValue: ターゲットの AWS Systems Manager タグ値 (パッケージを VMware Cloud on AWS 仮想マシン にのみインストールしたい場合は、VmcTagKey の値を入力します) テンプレートが正常にデプロイされたら、AWS Systems Manager コンソールに移動し、左側のパネルから [ Distributor ] を選択します。「Owned by me」タブを選択し、サンプルパッケージがそこにあることを確認します。パッケージ (SimplePackage2) を選択し、詳細セクションからバージョンを検証します。追加情報セクションの添付ファイル情報に、カスタムパッケージ (examplepackage) のマニフェストファイルとまったく同じように zip ファイルとハッシュが含まれていることを確認します。Distributor で利用可能になったカスタムパッケージ（SimplePackage2）は次のとおりです。 図 9: Distributor の各メンバーアカウントの「Owned by me」タブでカスタムパッケージを利用できるようにする セッション管理 Systems Manager の機能の 1 つである Session Manager を使用すると、受信ポートを開いたり、拠点ホストを管理したり、SSH キーを管理したりすることなく、安全で監査可能なノード管理が可能になります。管理者は、1 つの場所から VMware Cloud on AWS 仮想マシン へのアクセスを許可および取り消すことができます。また、マルチクラウド環境の Linux、macOS、Windows Server の管理対象ノードのユーザーに 1 つのソリューションを提供できます。ユーザーは、SSH キーを提供しなくても、ブラウザまたは AWS コマンドラインインターフェイス（AWS CLI）からワンクリックで、クラウド上のマネージドノード（VMware Cloud on AWS 仮想マシンなど）に接続できます。 図 10: Windows VMware Cloud on AWS 仮想マシンによる安全なセッションアクセス インベントリー管理 Systems Manager の機能の 1 つである Inventory は、オンプレミスでも他のクラウドでも、AWS で実行されている管理対象ノードからメタデータを収集します。メタデータには、アプリケーション (アプリケーション名、発行者、バージョン)、ファイル (名前、サイズ、バージョン、インストール日、変更、最終アクセス日時)、ネットワーク構成 (IP アドレス、MAC アドレス、DNS、ゲートウェイ、サブネットマスク) などが含まれます。Systems Manager Inventory によって収集されるメタデータタイプの全リストには、 こちら からアクセスできます。 Systems Manager コンソール に移動し、ナビゲーションペインで [ Inventory ] を選択します。Inventory ページの Systems Manager コンソールのデータには、データのクエリに役立ついくつかの定義済みカードが含まれています。 図 11: AWS Systems Manager Inventory に VMware Cloud on AWS 仮想マシン のインベントリメタデータのクエリに役立つ定義済みのカードが表示される クリーンアップ 繰り返しの課金を防ぎ、この記事で説明されていソリューションを試した後にアカウントをクリーンアップするには、次の手順を実行してください。 1.VMware Cloud on AWS 仮想マシン から Systems Manager エージェントをアンインストールするには、次の 手順 に従います。 2. aws-centralizedssmdistrubutor-v1 テンプレートの CloudFormation スタックを 削除 します。 3.このソリューション用に作成された s3-examplepackage-[ accountid ]-[ region ] Amazon S3 バケットを 削除 します。 まとめ クラウド運用サービスを使うと、統一された運用ビューと最適化された IT インフラストラクチャによって、クラウド全体にわたる管理、オーケストレーション、ポータビリティの課題を軽減できます。Systems Manager はクラウド運用サービスであり、ハイブリッド環境のコンピューティングをリモート管理するために使用できるノード管理機能を提供します。この投稿では、Systems Manager を使用して VMware Cloud on AWS で実行されているコンピューティングのインベントリの収集、安全なセッションの開始、パッチ管理とパッケージ配布の一元化と自動化を行う方法を示しました。 この投稿の翻訳は Solutions Architect の有岡が担当させていただきました。原文記事は こちら です。

昨年、 VMware Cloud on AWS と Amazon FSx for NetApp ONTAP の統合 を発表しました。この統合が利用できるようになってから、注目が高まり、採用が増えてきています。 VMware Cloud on AWS により、オンプレミスのデータセンターを拡張し、マシンイメージ形式の変換やリプラットフォームを行うことなく、ワークロードを簡単に移行することができます。 Amazon FSx for NetApp ONTAP は、NetApp ONTAP ファイルシステムをクラウド上で利用できるフルマネージドのストレージサービスです。 また昨年に、 単一のアベイラビリティーゾーン (AZ) での展開 のサポートも開始しました。 AWS Transit Gateway (TGW) がソリューションの要件となっていましたが、ファイルシステムを VMware Cloud on AWS の Software-Defined Data Center (SDDC) に柔軟に接続できるようになりました。 そしてこの度、 Amazon VPC Cloud (VPC) ピアリング のサポートが開始されます。そのため、ソリューションの要件として AWS Transit Gateway が不要になります。 この記事では、VPC ピアリングによる接続の利点と、接続手順および考慮事項について説明します。 メリット VPC ピアリングは、2 つ以上の VPC ネットワーク間をプライベートに接続し、セキュリティを向上させます。トラフィックをパブリックインターネットから隔離すると、トラフィックが Amazon Web Services (AWS) クラウドネットワークから出ることがないため、スタックからのあらゆるリスクを軽減することができます。 ピアリングされた VPC と SDDC 間でピアリングが設定されますが、トラフィックは管理サブネットに制限され、NFS トラフィックのみが許可されます。 VPC ピアリングを使用すると、ネットワーク転送コストを節約でき、ネットワークレイテンシが改善します。ピアリングトラフィックは AWS ネットワークから出ないため、パブリック IP のレイテンシが小さくなります。VPC ピアリングは VPC 間にラインレートの接続を確立することで、ピアリングされた VPC において Elastic Network Interface (ENI) 間の通信が、ミリ秒以下のレイテンシで可能になります。 VPC ピアリングを使用する他の理由は、インスタンスがパブリック IP アドレスを必要としない場合や、パブリックインターネットへのネットワークアドレス変換 (NAT) を必要としない場合です。 ソリューションの概要 同一または異なる AWS アカウントやリージョンにある 2 つの VPC 間で、VPC ピアリング接続を作成することができます。VPC ピアリング接続では、プライベート IPv4 または IPV6 アドレスを使用してホスト間で通信できます。 Network File System (NFS) データストア接続は、NSX をバイパスし、ESXi ホストと FSx for ONTAP ベースの NFS ストレージの間で確立されるため、ルーティングされた接続を経由する必要なく、2 つの VPC 間で直接接続が確立されます。 図 1 – VPC ピアリング 接続プロセス 接続には、SDDC がデプロイされている VMware が管理する AWS アカウントと、Amazon FSx for ONTAP ファイルシステムがデプロイされているお客様の AWS アカウントが必要です。 VMware 管理の AWS アカウントと、お客様の AWS アカウント間で、VPC ピアリングをセットアップするために必要な大まかな手順を説明します。 お客様は VMware のカスタマーサクセス担当者またはアカウント担当者に連絡し、VCP ピアリングを依頼します。 リクエスト側 VPC の所有者 (VMware) が、受け入れ側 VPC の所有者 (お客様) に、VPC ピアリング接続を作成するためのリクエストを送信します。 VPC ピアリング接続を有効にするために、受け入れ側 VPC の所有者 (お客様) が、VPC ピアリング接続のリクエストを受け入れる必要があります。 お客様が VMware に連絡し、リクエストを受け入れ、VPC ピアリング接続を完了できることを伝えます。 VMware が、ピアリング接続を使用するようにネットワークルートを更新します。 お客様が、お客様の VPC で同じことを行い、NFS トラフィックを許可するようにセキュリティグループルールを設定します。 考慮事項 Amazon FSx for NetApp ONTAP の VPC ピアリングは、NFS データストアのトラフィック専用です。その他のトラフィックはブロックされています。 VPC ピアリングは、SDDC のバージョンが v1.20 以降であり、シングルアベイラビリティーゾーンの構成である必要があります。マルチアベイラビリティーゾーンの構成で FSx for NetApp を利用する場合は、AWS Transit Gateway を使用するアーキテクチャが必要で、SDDC への接続には引続き SDDC グループを使用する必要があります。SDDC が v1.20 より前のバージョンを実行しており、VPC ピアリングを利用したい場合は、VMware に SDDC のアップグレードをリクエストしてください。 VMware はストレッチクラスタのデータストアとして外部ストレージをサポートしていません。VMware のロードマップで将来的に対応予定となっています。 料金 VPC ピアリング接続の作成は無料です。また、同一アベイラビリティーゾーン内で VPC ピアリング接続を介して転送されるデータは無料です。ストレージと SDDC が異なるアベイラビリティーゾーンに配置されている場合には、アベイラビリティーゾーンをまたいだ VPC ピアリング接続間でのデータ転送料金が適用されます。 まとめ この VPC ピアリングの提供開始により、AWS Transit Gateway でのデータ処理料金のコストを追加で発生させることなく、Amazon FSx for NetApp ONTAP で VMware Cloud on AWS を最大限に活用することができます。これにより、VMware Cloud on AWS 内で運用する際の総所有コスト (TCO) をさらに削減し、機能を向上させることができます。 この導入オプションの詳細については、 VMware Cloud on AWS のページ 、 FSx for NetApp ONTAP の製品ページ 、 AWS News Blog のアナウンス をご覧ください。 翻訳をソリューションアーキテクトの Furuya が担当しました。原文は こちら です。

このブログは 2023 年 4 月 19 日に Bowen Wang によって執筆された内容を日本語化したものです。原文は こちら を参照して下さい。 プリンシパルプロダクトマネージャである Dennis Newberry とサステナビリティプロダクトマネージャの Kurt Yeager がブログに寄稿しました。 Customer Carbon Footprint Tool は CSV ダウンロードオプションをサポートするようになりました。これにより、カーボンフットプリントデータを詳細に確認し、そのデータを他のレポートシステムに取り込み、さらなる分析や情報共有を行うことができます。 背景 AWS のビジネス価値は、総所有コストの削減だけではありません。AWS の規模の経済性、高可用性、俊敏性は、スタッフの生産性の向上、ビジネスリスクの軽減、持続可能性の向上に役立ちます。AWS で得られるメリットの 詳細 をご覧ください。 近年、より効率的で持続可能な方法で事業を運営することに注力し、エネルギー効率の目標を設定する企業が増えています。AWS は 2022 年 3 月に Customer Carbon Footprint Tool (CCFT) をリリースしました。これにより、AWS サービスの使用による二酸化炭素排出量と、再生可能エネルギーで運用される AWS のインフラストラクチャを活用することによる現在および予測される排出削減量を追跡できます。 ダウンロード可能な CSV ファイルによる二酸化炭素排出量データの可視性向上 以前は、CCFT のサマリーレポートは PDF 形式でダウンロードできました。しかし、企業のニーズに基づいてより包括的なサステナビリティレポートにデータを取り込むことができるように、カーボンフットプリントレポートを CSV 形式でダウンロードしたいという声が多くのユーザーから寄せられています。ダウンロード可能なレポート形式の変更に伴ってAWS はレポート内のデータの細分化も強化しました。 炭素報告基準の引き下げ : AWS は炭素報告基準を小数点以下 1 桁から小数点以下 3 桁に引き下げました。つまり、炭素排出量データは、以前の 0.X 二酸化炭素換算トンから 0.00X 二酸化炭素換算トンで入手できるようになりました。この変更によって、環境が小さく二酸化炭素排出量が 0.1 二酸化炭素換算トン未満のお客様も二酸化炭素排出量を確認できるようになります。目に見える二酸化炭素排出量の閾値を 1 kg に引き下げることで、より多くのAWSのお客様が二酸化炭素排出量の報告を開始できるようになります。 カーボンの粒度の向上 ：CCFTのユーザーインターフェースと以前にダウンロードした PDF では、地域別またはサービス別の月次サマリーデータが表示されていました。新しい CSV ダウンロードにより、炭素データを月、サービス、地域別に多次元レベルで分析できるようになりました。たとえば、北米での Amazon EC2 使用量の二酸化炭素排出量を確認できるようになりました。これにより、二酸化炭素排出量の主な発生源をより正確に特定できます。 仕組み AWS 請求コンソールにログインし、「コストと使用状況レポート」を選択します。 画像 1 : 請求コンソールでのコストと使用状況レポート 下にスクロールすると、炭素排出量の概要、お客様の排出量の削減、地域別やサービス別の排出量の分布を含む概要レポートが表示されます。「ダウンロード」ボタンがあり、クリックすると詳細データを CSV ファイルとしてダウンロードできます。 画像 2 : Customer Carbon Footprint Tool のグラフや表、「ダウンロード」ボタン CSV レポートを作成すると、AWS アカウント ID、トン単位の炭素排出量データ、AWS サービス、地域の詳細が表示されます。これにより、選択したディメンション別にデータを表示するのが簡単になります。たとえば、地域、サービスごとのクイックピボット、または BI システムにデータを取り込むことができます。 図 1 : CSV 形式のサンプルの CCFT レポート 図 2 : CCFT データを含むピボットレポートの例 結論 炭素排出量レポートの可視性と柔軟性が向上したことで、持続可能性イニシアチブの進捗をより細かく管理および最適化できるようになります。Customer Carbon Footprint Tool の詳細については、この ユーザーガイドを ご覧ください。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。 TAGS: Customer Carbon Footprint Tool Bowen Wang Bowen は、AWS 請求およびコスト管理サービスのプリンシパルプロダクトマーケティングマネージャーです。彼女は財務リーダーとビジネスリーダーがクラウドの価値とクラウドの財務管理を最適化する方法をよりよく理解できるようにすることに重点を置いています。前職ではあるテック系スタートアップ企業がビジネスオートメーション製品を中国市場に投入し、現地のカスタマーサービスコールセンターの設立を支援していました。

深層学習モデルを大規模にデプロイする際には、パフォーマンスとコストのメリットを最大化するために、基盤となるハードウェアを効果的に活用することが重要です。高スループットかつ低レイテンシであることが必要となる本番ワークロードの場合、 Amazon Elastic Compute Cloud (EC2) インスタンス、モデルサービングのスタック、デプロイアーキテクチャの選択が非常に重要です。非効率的なアーキテクチャはアクセラレーターの最適化がなされていないことから、不必要に高い本番コストにつながる可能性があります。 この記事では、AWS Inferentia アクセラレータ（Amazon EC2 Inf1 およびAmazon EC2 Inf2 &nbsp;インスタンスに搭載されています）に&nbsp;FastAPI モデルサーバーをデプロイする流れを説明します。また、ハードウェア効率の最大化を実現するために、すべてのNeuronCore に並列にデプロイされたサンプルモデルのホスティングも示します。 ソリューションの概要 FastAPI は、Flask や Django などの従来のフレームワークよりもはるかに高速な、Python アプリケーションをホストするためのオープンソースの Web フレームワークです。これらは広く使用されている Web Server Gateway Interface (WSGI) ではなく、 Asynchronous Server Gateway Interface (ASGI) を活用することで実現しています。ASGI は、WSGI がリクエストを順次処理するのとは異なり、非同期に処理します。このことから、FastAPI は低レイテンシが要求されるリクエストを処理するのに最適な選択肢となっています。FastAPI を使用することで、指定されたポートを介してクライアントからのリクエストを受け取るサーバーを Inferentia (Inf1/Inf2) インスタンスに デプロイできます。 私たちの目標は、ハードウェアを最大限に活用することで、最低コストで最高のパフォーマンスを達成することです。これにより、より少ないアクセラレーターでより多くの推論要求を処理できます。各 AWS Inferentia1 デバイスには 4 つの NeuronCore-v1 が含まれ、各 AWS Inferentia2 デバイスには 2 つの NeuronCore-v2 が含まれます。 AWS Neuron SDK を使用すると、各 NeuronCore を並列に使用できるため、スループットを犠牲にすることなく、4 つかそれ 以上のモデルを並列にロードおよび推論する際の制御が可能となります。 FastAPI を使用する際には、Python の Web サーバー&nbsp;( Gunicorn 、 Uvicorn 、 Hypercorn 、 Daphne ) の選択肢があります。これらの Web サーバーは、基盤となる機械学習 (ML)&nbsp; モデルの上に抽象化レイヤーを提供します。要求元クライアントは、ホストされたモデルを認識する必要がありません。クライアントは、サーバー下でデプロイされたモデルの名前やバージョンを知る必要はありません。すなわち、エンドポイント名はモデルをロードして実行する関数へのプロキシになります。対照的に、フレームワーク固有のサービングツール、たとえば TensorFlow Serving では、モデルの名前とバージョンがエンドポイント名の一部となります。サーバー側でモデルが変更された場合、クライアントは API 呼び出しを新しいエンドポイントに変更する必要があります。したがって、A/B テストなどの状況でモデルのバージョンを継続的に改善させている場合、FastAPI を備えた汎用 Python Web サーバーを使用すると、エンドポイント名が静的であるため、モデル提供時には便利な方法であるといえます。 ASGI サーバーの役割は、指定された数のワーカーを生成してクライアントからのリクエストを受信し、推論コードを実行することです。サーバーの重要な機能は、要求された数のワーカーが使用可能かつアクティブであることを確認することです。ワーカーが停止された場合、サーバーは新しいワーカーを起動する必要があります。この状況においては、サーバーおよびワーカーは Unix のプロセス ID (PID) によって識別される場合があります。このブログでは、Python Web サーバーとして人気のある Hypercorn サーバを使用します。 このブログでは、AWS Inferentia NeuronCore 上で FastAPI を使用し、深層学習モデルをデプロイするためのベストプラクティスを共有します。ここでは、複数のモデルを個別の NeuronCore にデプロイして、同時に呼び出すことができることを示します。このセットアップにおいては、複数のモデルが同時に推論できるため、スループットが向上し、NeuronCore の使用率が完全に最適化されます。コードは&nbsp; GitHub &nbsp;リポジトリに公開されています 。次の図は、EC2 Inf2 インスタンスに今回のソリューションを構築したアーキテクチャを示しています。 EC2 Inf1 インスタンスタイプでも同じアーキテクチャが適用されますが、4 つのコアがあります。そのためアーキテクチャ図が少し変更されます。 AWS Inferentia NeuronCore NeuronCore を使用するための AWS Neuron が提供するツールについて詳しく見てみましょう。次の表は、各 Inf1 および Inf2 インスタンスタイプに搭載されている NeuronCore の数を示しています。ホスト vCPU とシステムメモリは、すべての利用可能な NeuronCore で共有されます。 Instance Size # Inferentia Accelerators # NeuronCores-v1 vCPUs Memory (GiB) Inf1.xlarge 1 4 4 8 Inf1.2xlarge 1 4 8 16 Inf1.6xlarge 4 16 24 48 Inf1.24xlarge 16 64 96 192 Instance Size # Inferentia Accelerators # NeuronCores-v2 vCPUs Memory (GiB) Inf2.xlarge 1 2 4 32 Inf2.8xlarge 1 2 32 32 Inf2.24xlarge 6 12 96 192 Inf2.48xlarge 12 24 192 384 Inf2 インスタンスは、Inf1 インスタンスの NeuronCore-v1 に比べて新しい NeuronCores-v2 を含んでいます。コアの数は少ないですが、Inf1 インスタンスよりも4倍大きいスループットと10倍小さいレイテンシを提供することができます。Inf2インスタンスは、Generative AI や OPT/GPT 系統の大規模言語モデル、Stable Diffusion や vision transformers などの深層学のワークロードに最適な選択肢となります。 Neuron Runtimeは、Neuron デバイス上でモデルを実行する役割を担っています。Neuron Runtime は、どの NeuronCore がどのモデルをどのように実行するか を 決定します。Neuron Runtime の設定は、プロセスレベルで 環境変数 を使用して制御されます。デフォルトでは、Neuron フレームワーク拡張機能がユーザーの代わりに Neuron Runtime の設定を行います。ただし、より最適化された動作を実現するために、明示的な設定も可能です。 よく使われる環境変数は NEURON_RT_NUM_CORES &nbsp;と NEURON_RT_VISIBLE_CORES &nbsp;です。これらの環境変数を使用すると、Python プロセスを NeuronCore に関連付けることができます。 NEURON_RT_NUM_CORES &nbsp;では、指定された数のコアをプロセスに予約することができ、 NEURON_RT_VISIBLE_CORES &nbsp;では、NeuronCore の範囲を予約することができます。例えば、 NEURON_RT_NUM_CORES=2 myapp.py &nbsp;とすると、 myapp.py &nbsp;に2つのコアが予約され、 NEURON_RT_VISIBLE_CORES='0-2' myapp.py &nbsp;とすると、 myapp.py &nbsp;に0、1、2の3つのコアが予約されます。NeuronCore はデバイス（AWS Inferentia チップ）間でも予約することができます。したがって、 NEURON_RT_VISIBLE_CORES='0-5' myapp.py &nbsp;とすると、EC2 Inf1 インスタンスタイプの device1 の最初の4つのコアと device2 &nbsp;の1つのコアが予約されます。同様に、EC2 Inf2インスタンスタイプでは、この設定により&nbsp; device1 &nbsp;と device2 &nbsp;の2つのコアが予約され、 device3 &nbsp;に1つのコアが予約されます。以下の表はこれらの変数の設定をまとめたものです。 Name Description Type Expected Values Default Value RT Version NEURON_RT_VISIBLE_CORES Range of specific NeuronCores needed by the process Integer range (like 1-3) Any value or range between 0 to Max NeuronCore in the system None 2.0+ NEURON_RT_NUM_CORES Number of NeuronCores required by the process Integer A value from 1 to Max NeuronCore in the system 0, which is interpreted as “all” 2.0+ すべての環境変数の一覧については、 Neuron Runtime Configuration &nbsp; を参照してください。 デフォルトでは、モデルをロードする際に、モデルは明示的に上記の環境変数で指定されていない限り、NeuronCore 0にロードされ、次に NeuronCore 1 にロードされます。先述したように、NeuronCore は利用可能なホスト vCPU とシステムメモリを共有します。したがって、各 NeuronCore に展開されたモデルは利用可能なリソースを競合します。モデルが NeuronCore を大幅に利用している場合は、これは問題になりません。しかし、モデルが NeuronCore の一部をのみ使用し、残りをホスト vCPU で実行している場合は、NeuronCore ごとのCPUの利用可能性を考慮することが重要になります。これはインスタンスの選択にも影響を与えます。 次の表は、各 NeuronCore に 1 つのモデルを展開した場合のホスト vCPU とシステムメモリの数を示しています。アプリケーションの NeuronCore の使用状況、vCPU の使用状況、およびメモリの使用状況に応じて、どの設定がアプリケーションにとって最もパフォーマンスが高いかを確認するためにテストを実行することが推奨されています。 Neuron Top ツール を使用すると、コアの利用状況やデバイスおよびホストメモリの利用状況を視覚化するのに役立ちます。これらのメトリックに基づいて適切な判断を行うことができます。このブログの最後で Neuron Top の使用方法を示します。 Instance Size # Inferentia Accelerators # Models vCPUs/Model Memory/Model (GiB) Inf1.xlarge 1 4 1 2 Inf1.2xlarge 1 4 2 4 Inf1.6xlarge 4 16 1.5 3 Inf1.24xlarge 16 64 1.5 3 Instance Size # Inferentia Accelerators # Models vCPUs/Model Memory/Model (GiB) Inf2.xlarge 1 2 2 8 Inf2.8xlarge 1 2 16 64 Inf2.24xlarge 6 12 8 32 Inf2.48xlarge 12 24 8 32 自分で Neuron SDK の機能をテストしてみるには、最新の PyTorch 向け Neuron 機能 をチェックしてください。 システムセットアップ このソリューションで使用されたシステムのセットアップは以下になります。 インスタンスサイズ – Inf1.6xlarge（Inf1 の場合）、Inf2.xlarge（Inf2 の場合）&nbsp; インスタンス用のイメージ – Deep Learning AMI Neuron PyTorch 1.11.0（Ubuntu 20.04）20230125&nbsp; モデル –&nbsp; https://huggingface.co/twmkn9/bert-base-uncased-squad2 フレームワーク – PyTorch ソリューションのセットアップ ソリューションをセットアップするために必要な手順がいくつかあります。まず、 Amazon Elastic Container Registry &nbsp; からの push と pull を許可する IAM ロールを作成して、EC2 インスタンスがそれを担えるようにします。 ステップ1：IAMロールのセットアップ コンソールにログインして、IAM &gt; ロール &gt; ロールを作成 にアクセスします。 信頼されたエンティティタイプとして AWS のサービス を選択します。 ユースケースとして EC2 をサービスとして選択します。 次へ をクリックすると、利用可能なすべてのポリシーが表示されます。 このソリューションでは、EC2 インスタンスに ECR へのフルアクセスを許可します。 AmazonEC2ContainerRegistryFullAccess をフィルタリングして選択します。 次を押してロールの名前を inf-ecr-access &nbsp;とします。 注意 ：このポリシーのアタッチ&nbsp; EC2 インスタンスは Amazon ECR へのフルアクセスが可能になります。本番環境のワークロードに対しては、 最小特権の原則 に従うことを強く推奨します。 ステップ2：AWS CLI のセットアップ 上記で指定された Deep Learning AMI を使用している場合、AWS CLI がインストールされています。別のAMI（Amazon Linux 2023, Base Ubuntuなど）を使用している場合は、 このガイド に従って CLI ツールをインストールしてください。 CLI ツールがインストールされたら、&nbsp; aws configure &nbsp;コマンドを使用して CLI を設定します。アクセスキーがある場合はここに追加できますが、AWS サービスとのやり取りには必ずしも必要ありません。今回の工程には IAM ロールを使用しています。 注意 ：default プロファイルを作成するために少なくとも1つの値（default region または default format）を入力する必要があります。この例では、region に us-east-2 を、default format に json を設定します。 GitHubリポジトリをクローンする GitHub リポジトリ には、FastAPI を使用して AWS Inferentia インスタンスの NeuronCore 上にモデルを展開するために必要なスクリプトが提供されています。この例では、再利用可能なソリューションを作成するために Docker コンテナを使用しており、ユーザーが入力を提供するための config.properties &nbsp;ファイルが含まれています。 # Docker Image and Container Name docker_image_name_prefix=&lt;Docker image name&gt; docker_container_name_prefix=&lt;Docker container name&gt; # Deployment Setup path_to_traced_models=&lt;Path to traced model&gt; compiled_model=&lt;Compiled model file name&gt; num_cores=&lt;Number of NeuronCores to Deploy a Model Server&gt; num_models_per_server=&lt;Number of Models to Be Loaded Per Server&gt; 設定ファイルには、Docker イメージ と Docker コンテナのためのユーザーが定義するプレフィックスが必要です。 fastapi フォルダと trace-model &nbsp;フォルダの build.sh &nbsp;スクリプトでは、これを使用して Docker イメージを作成します。 AWS Inferentia に向けたモデルコンパイル モデルをトレースして、PyTorch Torchscript の .pt 形式ファイルを生成することから始めます。まず、 trace-model &nbsp;ディレクトリにアクセスして、 .env &nbsp;ファイルを変更します。選択したインスタンスのタイプに応じて、 .env &nbsp;ファイル内の CHIP_TYPE を変更します。例として、Inf2 を選択しますが、同じ手順は Inf1 のデプロイプロセスでも適用されます。 次に、同じファイル内で default region を設定します。この region は ECR リポジトリの作成に使用され、Docker イメージがこのリポジトリにプッシュされます。また、このフォルダには、AWS Inferentia 上で bert-base-uncased &nbsp;モデルをトレースするために必要なすべてのスクリプトが含まれています。このスクリプトは、 Hugging Face で利用可能なほとんどのモデルに使用できます。 Dockerfile には、Neuron でモデルを実行するためのすべての依存関係が含まれており、 trace-model.py&nbsp; コードがエントリーポイントとして実行されます。 Neuron コンパイルについて Neuron SDK の API は、PyTorch の Python API に非常に近いです。PyTorch の torch.jit.trace() &nbsp;は、モデルとサンプルとなる入力テンソルを引数として取ります。サンプル入力はモデルに引き渡され、モデルのレイヤーを通過する際に呼び出される操作が TorchScript として記録されます。PyTorch における JIT トレースについての詳細は、以下の ドキュメント を参照してください。 torch.jit.trace() &nbsp;と同様に、Inf1 の場合は以下のコードを使用して AWS Inferentia 上でモデルをコンパイルできるかどうかを確認できます。 import torch_neuron model_traced = torch.neuron.trace(model, example_inputs, compiler_args = [‘--fast-math’, ‘fp32-cast-matmul’, ‘--neuron-core-pipeline-cores’,’1’], optimizations=[torch_neuron.Optimization.FLOAT32_TO_FLOAT16]) Inf2 の場合、ライブラリは torch_neuronx と呼ばれます。以下は、モデルのコンパイルを Inf2 インスタンスにおいて確認する方法です。 import torch import torch_neuronx model_traced = torch.neuronx.trace(model, example_inputs, compiler_args = [‘--fast-math’, ‘fp32-cast-matmul’, ‘--neuron-core-pipeline-cores’,’1’], optimizations=[torch_neuronx.Optimization.FLOAT32_TO_FLOAT16]) モデルのトレースを行うと、次のようにしてサンプル入力となるテンソルを入力することができます。 answer_logits = model_traced(*example_inputs) 最後に生成された TorchScript をローカルディスクに保存します。 model_traced.save('./compiled-model-bs-{batch_size}.pt') 前述のコードに示されているように、 compiler_args &nbsp;と optimizations &nbsp;を使用しデプロイを最適化することができます。 torch.neuron.trace API の引数の詳細なリストについては、 PyTorch-Neuron trace python API &nbsp;を参照してください。 また、次の重要なポイントに注意して下さい。 Neuron SDK&nbsp;は、この執筆時点では動的なテンソル形状をサポートしていません。したがって、モデルは異なる入力形状に対して別々にコンパイルする必要があります。バケッティングを使用した可変入力形状での推論の実行についての詳細は、 Running inference on variable input shapes with bucketing &nbsp;を参照してください。 モデルをコンパイルする際にメモリ不足の問題に直面した場合、より多くの vCPU やメモリを搭載した AWS Inferentia インスタンスでモデルをコンパイルするか、コンパイルには CPU のみが使用されるため、さらに大きな c6i や r6i インスタンスも使用可能です。一度コンパイルされれば、トレースされたモデルはより小さなサイズの AWS Inferentia インスタンスでも実行できるはずです。 ビルドプロセス build.sh &nbsp;を実行することでコンテナをビルドします。ビルドスクリプトは、ベースとなる Deep Learning Container Image を取得し、HuggingFace の transformers &nbsp;パッケージをインストールし Docker イメージを作成する処理を行います。 .env &nbsp;ファイルで指定された CHIP_TYPE &nbsp;に基づいて、 docker.properties &nbsp;ファイルが適切な BASE_IMAGE &nbsp;を決定します。この BASE_IMAGE は、AWSが提供する Neuron Runtime 用の Deep Learning Container Image を指します。 これらの処理はプライベートな ECR リポジトリを利用します。そのため、イメージを取得する前にログインを行い、一時的なAWSクレデンシャルを取得する必要があります。 aws ecr get-login-password --region &lt;region&gt; | docker login --username AWS --password-stdin 763104351884.dkr.ecr.&lt;region&gt;.amazonaws.com 注意 ： &lt;region&gt; &nbsp;フラグで指定されたコマンドおよびリポジトリ URI 内のリージョンは、 .env &nbsp;ファイルに記載されたリージョンで置き換える必要があります。 このプロセスを簡易に実行するために、 fetch-credentials.sh &nbsp;ファイルを使用することができます。リージョンは自動的に .env &nbsp;ファイルから取得されます。 次に、 push.sh &nbsp;スクリプトを使用してイメージをプッシュします。このスクリプトは Amazon ECR にリポジトリを作成し、コンテナイメージをプッシュします。 最後に、イメージがビルドされてプッシュされたら、 run.sh を実行してコンテナとして実行し、 logs.sh &nbsp;を使用して実行中のログを表示できます。コンパイラのログ（以下のスクリーンショットを参照）では、Neuron でコンパイルされた算術演算子の割合と、モデルサブグラフの割合が表示されます。スクリーンショットは、 bert-base-uncased-squad2 &nbsp;モデルのログを示しています。ログによれば、算術演算子の 95.64% がコンパイルされ、Neuron でコンパイルされた演算子とサポートされていない演算子のリストも示されています。 最新の PyTorch Neuron パッケージでサポートされているすべての演算子のリストは こちら にあります。同様に、最新のPyTorch Neuronx パッケージでサポートされているすべての演算子のリストも こちら です。 FastAPI を使用してモデルをデプロイする モデルがコンパイルされた後、トレースされたモデルは trace-model &nbsp;フォルダに保存されます。この例では、バッチサイズ&nbsp;1&nbsp;としてトレースモデルを配置しています。ここでは、より大きいバッチサイズが実現不可能または必要ないユースケースを考えており、バッチサイズ&nbsp;1&nbsp;を使用しています。より大きいバッチサイズが必要なユースケースでは、 torch.neuron.DataParallel (Inf1 の場合) または torch.neuronx.DataParallel (Inf2 の場合) APIが役立つ場合があります。 fast-api フォルダには、FastAPI を使用してモデルをデプロイするためのすべての必要なスクリプトが含まれています。変更なしでモデルをデプロイするには、単に deploy.sh &nbsp;スクリプトを実行するだけで、FastAPI コンテナイメージがビルド、指定されたコア数でコンテナが実行され、各 FastAPI モデルサーバーで指定された数のモデルがデプロイされます。このフォルダには .env &nbsp;ファイルも含まれており、これを変更して正しい CHIP_TYPE &nbsp;と AWS_DEFAULT_REGION を反映させることができます。 注意 ：FastAPI スクリプトは、イメージのビルド、プッシュ、コンテナとしての実行に使用されるものと同じ環境変数に依存しています。FastAPI デプロイメントスクリプトは、これらの変数からの最後に知られている値を使用します。したがって、もし最後にトレースしたモデルが Inf1 インスタンスタイプの場合、そのモデルがこれらのスクリプトを介してデプロイされます。 fastapi-server.py ファイルは、サーバーのホスティングとモデルへのリクエストの送信を担当しており、以下のことを行います。 プロパティファイルからサーバーごとのモデル数とコンパイルされたモデルの場所を読み取ります。 Docker コンテナに対して利用可能な NeuronCore を環境変数として設定し、どの NeuronCore を使用するかを指定する環境変数を読み取ります。 bert-base-uncased-squad2 &nbsp;モデルの推論 API を提供します。 jit.load() &nbsp;を使用して、設定で指定されたサーバーごとに必要なモデルの数を読み込み、モデルと必要なトークナイザーをグローバルな辞書に格納します。 このセットアップでは、各 NeuronCore に格納されているモデルとその数を一覧表示するAPIを簡単に設定することができます。同様に、特定の NeuronCore からモデルを削除するための API も作成できます。 FastAPI コンテナをビルドするため Dockerfile は、モデルのトレース用にビルドした Docker イメージをベースにして構築されています。これが、 docker.properties &nbsp;ファイルがモデルのトレース用の Docker イメージの ECR パスを指定している理由です。今回のセットアップでは、すべての NeuronCore 上の Docker コンテナは同種のものであり、1つのイメージをビルドし、それから複数のコンテナを実行できます。エントリーポイントのエラーを回避するために、 Dockerfile で ENTRYPOINT&nbsp;["/usr/bin/env"] &nbsp;を指定してから、 hypercorn fastapi-server:app -b 0.0.0.0:8080 &nbsp;というスタートアップシェルスクリプトを実行します。このスタートアップスクリプトはすべてのコンテナで同じです。モデルのトレース用と同じベースイメージを使用している場合、build.sh スクリプトを実行するだけでこのコンテナをビルドできます。 push.sh &nbsp;スクリプトは、モデルのトレース用と同じままです。変更された&nbsp;Docker&nbsp;イメージとコンテナ名は、 docker.properties ファイルで提供されます。 run.sh ファイルは以下の操作を行います。 プロパティファイル から Docker イメージとコンテナ名を読み取ります。このプロパティファイルは、 config.properties &nbsp;ファイルを読み取ります。 config.properties &nbsp;ファイルには num_cores &nbsp;というユーザー設定が含まれています。 0 から num_cores &nbsp;までのループを開始し、各コアごとに以下を実行します。 &nbsp;ポート番号とデバイス番号を設定します。 NEURON_RT_VISIBLE_CORES &nbsp;を設定します。 ボリュームマウントを指定します。 Docker コンテナを実行します。 NeuronCore 0 で Inf1 用に展開するための Docker 実行コマンドは次のようになります。 docker run -t -d \ --name $ bert-inf-fastapi-nc-0 \ --env NEURON_RT_VISIBLE_CORES="0-0" \ --env CHIP_TYPE="inf1" \ -p ${port_num}:8080 --device=/dev/neuron0 ${registry}/ bert-inf-fastapi NeuronCore 5 で展開するための実行コマンドは次のようになります。 docker run -t -d \ --name $ bert-inf-fastapi-nc-5 \ --env NEURON_RT_VISIBLE_CORES="5-5" \ --env CHIP_TYPE="inf1" \ -p ${port_num}:8080 --device=/dev/neuron0 ${registry}/ bert-inf-fastapi コンテナが展開された後、 run_apis.py スクリプトを使用して、API を並列スレッドで呼び出します。コードは、各 NeuronCore に1つずつ展開された6つのモデルを呼び出すように設定されていますが、簡単に異なる設定に変更できます。クライアント側から API を呼び出す方法は以下の通りです。 import requests url_template = http://localhost:%i/predictions_neuron_core_%i/model_%i # NeuronCore 0 response = requests.get(url_template % (8081,0,0)) # NeuronCore 5 response = requests.get(url_template % (8086,5,0)) NeuronCore の監視 モデルサーバーが展開された後、NeuronCore の利用状況を監視するために、 neuron-top を使用して各 NeuronCore の利用率をリアルタイムで観測することができます。 neuron-top は、Neuron SDK 内の CLI ツールで、NeuronCore、vCPU、メモリの利用状況などの情報を提供します。別のターミナルで、次のコマンドを入力します。 neuron-top このコマンドによって、下の画像のような出力が得られます。このシナリオでは、Inf2.xlarge インスタンスでサーバーごとに2つの NeuronCore と 2 つのモデルを使用するように指定しています。以下のスクリーンショットでは、2 つのサイズが 287.8 MB のモデルが 2 つの NeuronCore にロードされていることが表示されています。合計 4 つのモデルがロードされているため、使用されているデバイスメモリは 1.3 GB です。矢印キーを使用して異なるデバイスの NeuronCore 間を移動できます。 同様に、Inf1.6xlarge インスタンスタイプでは、合計 12 のモデル（ 1 つのコアあたり 2 つのモデル、6 つのコア合計）がロードされていることが表示されます。合計 2.1 GB のメモリが消費され、各モデルのサイズは 177.2 MB です。 run_apis.py スクリプトを実行した後、各 NeuronCore の利用率の割合を確認できます（以下のスクリーンショットを参照）。また、システムの vCPU 使用率とランタイムの vCPU 使用率も確認できます。 以下のスクリーンショットは、Inf2 インスタンスのコア使用率の割合を示しています。 同様に、このスクリーンショットは、Inf1.6xlarge インスタンスタイプにおけるコアの利用率を示しています。 クリーンアップ 作成したすべての Docker コンテナをクリーンアップするために、すべての実行中および停止したコンテナを削除する cleanup.sh &nbsp;スクリプトを提供しています。このスクリプトはすべてのコンテナを削除しますので、実行中の一部のコンテナを保持したい場合には使用しないでください。 結論 プロダクションのワークロードはしばしば高いスループット、低レイテンシ、コストの要件を持っています。アクセラレータを最適でない方法で使用する非効率なアーキテクチャでは、不必要に高いコストにつながる可能性があります。この記事では、 FastAPI と NeuronCore を最適に活用し、スループットを最大化しながら最小のレイテンシで動作すること方法を示しました。詳しくは&nbsp; GitHubのリポジトリ に手順を公開しています。このソリューションを使用すると、各 NeuronCore に複数のモデルを展開し、異なる NeuronCore 上で複数のモデルを並列に運用することができ、パフォーマンスを損なうことなく行えます。 Amazon Elastic Kubernetes Service （Amazon EKS）などのサービスを使用してモデルをスケールで展開する方法については、「 AWS Inferentiaを使用して Amazon EKS で 3,000種類のディープラーニングモデルを 1 時間あたり 50 USD 以下で提供 」の記事を参照してください。 翻訳はソリューションアーキテクトの松崎が担当しました。原文は こちら です。