マルチアカウント環境で効果的なガバナンスを実現し AWS のベストプラクティスや一般的なコンプライアンスフレームワークと連携させる作業は、複雑になることがあります。多くのお客様、特に規制の厳しい業界で事業を営むお客様は、リスクを特定し、サービス間の関係や依存関係に対処するための独自の統制を開発するために、時間とリソースを投資する必要があるという課題に直面しています。このプロセスによって、新しいサービスを実装する際のタイム・トゥ・バリュー (TTV) が長くなることがあります。 AWS Control Tower は、コンプライアンスドメイン全体にわたる 包括的なコントロール をお客様に提供し、強固なコンプライアンスフレームワークの確立を促進します。AWS のベストプラクティスと業界標準に準拠しているため、コンプライアンスを確保しながら新しいサービスを迅速に確立できます。これらの統制を活用することで、組織はガバナンスプロセスを合理化し、AWS 環境で新しいサービスを採用する際の TTV を短縮できます。 このブログでは、社内標準や規制要件を遵守するのに役立つ、AWS Control Tower のコントロールを使用する際のベストプラクティスについて説明します。 ベストプラクティス 適切なコントロールを適用するために、ワークロードと OU を把握して評価する アカウント内で運用されているワークロードと、確立されたビジネス目標を達成するための対応する要件、およびアカウントを組織単位（OU）に整理する根底にある理論的根拠を詳細に理解することが不可欠です。この理解は、必要な統制の範囲を決めるための指針となり、ワークロードとそのセキュリティ要件に沿った一貫した構造を確保します。 コンプライアンスフレームワークとの連携を検討する AWS Control Tower を利用することで、AWS のサービス、統制目標、コンプライアンスフレームワーク ( NIST 800-53 、 CIS AWS Benchmark 、 PCI-DSS など) ごとに統制をグループ化し、規制対象の業界のお客様は特定のコンプライアンス目標を達成するコントロールを簡単に有効化できるようになります。 IT コンプライアンスフレームワークとの連携は、規制対象外の業界の組織にも大きなメリットをもたらします。明確なコンプライアンス義務はないかもしれませんが、そのようなフレームワークを採用することで、リスク管理の一貫性と再現性のある基盤を確立することができます。さらにこれらのフレームワークは、お客様の AWS 環境に合わせたセキュリティ設定のベストプラクティスを提供することで、すべてのお客様にメリットをもたらします。 AWS Control Tower のコントロールを有効にする前に、その動作とメカニズムを理解する AWS Control Tower は、コントロールが どのように実装されているか を完全に可視化するアーティファクトなどの、各コントロールに関する包括的な情報を提供します。 予防コントロール は、セキュリティポリシーの違反につながる可能性のあるアクションを 許可しません 。これは サービスコントロールポリシー (SCP) によって実装されています。 検出コントロール は、ポリシー違反などのアカウント内の非準拠のリソースを検出し、ダッシュボードを通じてアラートを表示します。検出コントロールのステータスは「クリア」、「違反」、「無効」のいずれかで、AWS Control Tower で管理対象とするリージョンに適用されます。これらは AWS Config Rules によって実装されています。 プロアクティブコントロール は、 プロビジョニングの前に AWS CloudFormation を介してデプロイされたリソースをスキャンして、そのコントロールに準拠していることを確認します。準拠していないリソースはプロビジョニングされません。プロアクティブコントロールは、 AWS CloudFormation Hooks と AWS CloudFormation Guard ルールを使用して実装されています。各プロアクティブコントロールでは、ポジティブテストケースとネガティブテストケースのリファレンスとして使用できるサンプルCloudFormationテンプレートアーティファクトが提供されています。プロアクティブコントロールのステータスは「PASS」「FAIL」または「SKIP」です。 予防コントロールを検討する前に、検出コントロールを適用する 検出コントロールを適用することで、アーキテクチャの弱点やあるべき姿とのギャップを特定して、セキュリティ態勢を評価・継続的に改善することができます。検出されるアラートの傾向の分析に基づいてターゲットを絞ったプロアクティブコントロールを適用すると、将来のコンプライアンス問題を防ぐこともできます。たとえば、S3 ブロックパブリックアクセス設定が有効になっているかどうかをチェックする検出コントロール「 [S3.1] S3 ブロックパブリックアクセス設定を有効にする必要があります 」を有効にしてから、AWS CloudFormation 経由で非準拠の S3 バケットが作成されないようにするプロアクティブコントロール「 [CT.S3.PR.1] Amazon S3 バケットには、パブリックアクセスをブロックする設定が必要です 」を有効にします。 non-production OU でコントロールをテストする サンドボックス環境と開発環境では、通常、本番環境よりも頻繁に変更や更新が行われます。このような環境で最初にコントロールを適用することで、潜在的なリスクや構成ミスを早期に特定して軽減し、これらの問題が本番環境に伝播する可能性を減らすことができます。 有効化されているコントロールを継続的に監視・テストする積極的なアプローチを採用する AWS CloudTrail のイベントログを監視して、統制違反を示す可能性のある異常を特定します。 AWS Audit Manager を使用して自動評価を実施し、一般的なセキュリティおよびコンプライアンスフレームワークと照らし合わせてリソース構成を評価します。これにより、監査管理プロセス全体を簡素化し、統制上のギャップに対処することに集中できます。 AWS Identity and Access Management (IAM) Access Analyzer を使用してアクセスパターンを確認し、IAM 固有の統制に加えてどの予防コントロールを導入すべきかについて、情報に基づいた決定を下すことができます。「設定したら後は何もする必要がない」ではなく、継続的に確認することで、統制目標を効果的に実現できるという自信を得ることができます。 Policy as Code 戦略を採用し、組織全体でピアレビューを実施する AWS CloudFormation Hook と AWS CloudFormation Guard ルールを組み合わせた AWS Control Tower のプロアクティブコントロールを使用してください。Policy as Code は、ポリシー適用へのさらに効率的なアプローチを提供し、一貫性と自動化を促進します。また、中央の IT チームと開発チーム間のコラボレーションを促進することで障害を取り除き、開発者やエンジニアに透明性をもたらします。 3 種類すべてのコントロールを組み合わせて有効化する多層防御アプローチをとる AWS Control Tower は、各コントロールの依存関係や関連性についての情報を提供します。関連するコントロールを評価し、環境に適用できるコントロールを有効化することで、多層的で回復力のあるコンプライアンス態勢を確立できます。セキュリティベースラインを保護するための予防コントロール、AWS CloudFormation を介して非準拠のリソースがデプロイされるリスクを軽減するプロアクティブコントロール、リソースの変化を継続的に監視して対応するための検出コントロールを組み合わせて使用します。 AWS Control Tower は AWS Security Hub と統合されており、AWS Control Tower から AWS Security Hub が用意した検出コントロールを有効化できます。有効化すると AWS Security Hub に サービスマネージド標準 (AWS Control Tower) のセキュリティ標準が作成され、コントロールの準拠状況を管理できます。AWS Security Hub の検出コントロールと AWS Control Tower の予防コントロールやプロアクティブコントロールを組み合わせ、それらをまとめて管理することが AWS Control Tower では可能です。 コンプライアンス違反リソースの検出と修復を自動化する セキュリティイベントの検出と修復を自動化することで、人的労力を削減し、エラーの可能性を最小限に抑えることができます。AWS Control Tower の検出コントロールと AWS Systems Manager Automation を組み合わせて活用してください。 AWS Systems Manager による自動化により、さまざまなメンテナンス、デプロイ、修復タスクが簡素化され、運用が合理化され、効率が向上します。 独自のコントロールを作成して機能を拡張する AWS Control Tower の管理するコントロールとは別に、追加のコントロールが必要な場合は、 AWS Organizations 内のサービスコントロールポリシー (SCP) やカスタム AWS Config ルールなどのリソースを活用して追加のポリシーを定義できます。これらのポリシーは、AWS CloudFormation テンプレートを使用して AWS Organizations の組織にデプロイできます。さらに、 AWS Config コンフォーマンスパック は、AWS 環境内のガバナンスと規制コンプライアンスを強化する汎用的なコンプライアンスフレームワークを提供します。コンフォーマンスパックは、コンプライアンスルールとそれに対応する修復アクションを 1 つのエンティティとしてまとめることで、ルールを大規模に展開する作業を効率化します。これにより、組織への独自コントロール導入プロセスが簡素化されます。 まとめ 管理者には、ガバナンスとアジリティのバランスを取るための包括的なアプローチを取り、AWS 環境を保護する際に適切なセキュリティ判断を下す責任があります。そのためには、セキュリティドメイン内で利用可能なツールやリソースを活用して、全体的なセキュリティ態勢を強化し、特定の要件や存在する可能性のある脆弱性に対処する必要があります。 言い換えると、多面的なアプローチを採用することで、管理者は包括的な保護を確保し、潜在的なリスクを効果的に軽減する必要があります。 AWS Control Tower のコントロールを適用するためのベストプラクティスに従うことで、ガバナンスプロセスを合理化し、AWS 環境で新しいサービスを導入する際の TTV を短縮できます。さらに、ビジネス目標とコンプライアンス目標を達成するために必要な統制の定義、マッピング、管理にかかる時間を短縮できます。 コントロールの有効化を開始するには、 AWS マネジメントコンソール の AWS Control Tower サービスのコントロールライブラリにアクセスしてください。また、 AWS Control Tower API を使用して、 AWS CloudFormation 、 AWS Command Line Interface (AWS CLI) 、 AWS SDK 、および AWS Cloud Development Kit (AWS CDK) を介してコントロールをプログラムで管理することもできます。各コントロールの固有のリソース識別子については、 コントロールメタデータテーブル を参照してください。 AWS Control Tower のコントロールを Infrastructure as Code (IaC) としてデプロイする場合のその他のガイダンスについては、 AWS Perspective Guidance カタログの「 AWS CDK と AWS CloudFormation を使用して AWS Control Tower コントロールをデプロイおよび管理する 」と「 Terraform を使用して AWS Control Tower コントロールをデプロイおよび管理する 」を参照してください。（訳註：日本のSAが公開しているセキュアなベースライン環境を展開するためのテンプレートである BLEA も理解において有用ですので是非ご参照ください） 本ブログの翻訳はソリューションアーキテクトの三厨が担当いたしました。原文は こちら 。 著者について Chezsal Kamaray Chezsal Kamaray は、アマゾンウェブサービスのハイテク分野のシニアソリューションアーキテクトです。この職務の範囲内で、エンタープライズ顧客と戦略的に連携し、AWS クラウドでのスケーラブルで安全で回復力のあるアーキテクチャの開発を促進しています。彼女は、オンプレミスとクラウドベースの両方のドメインにわたるさまざまなインフラストラクチャプロジェクトのテクニカルレビューのリーダーシップを含め、多面的なクロスファンクショナルシステムの複雑な設計とシームレスな統合において15年以上の経験を持っています。Chezsal は、ニュージャージー工科大学で電子通信工学の工学士号（BenG）と電気通信の理学修士号（MSc）を取得しています。余暇には、Chezsal は料理への好奇心にふけり、音楽を聴きながら新しいレシピを試しています。 Matthew Barbieri Matt Barbieri は、ニューヨークを拠点とする AWS のソリューションアーキテクトです。コンプライアンス、セキュリティ、オペレーションエクセレンスに重点を置いて、企業顧客が AWS でソリューションを構築できるよう支援しています。AWS の元顧客として 10 年近くの経験を持つ彼は、クラウドへの移行に着手する企業が直面する課題と機会を深く理解しています。

AWS Loft TokyoでDeveloper x NoSQL nightというイベントを2023年9月21日に実施します。 開催概要 Serverless Days Tokyo にて Keynote を務める DynamoDB Book の著者であり AWS Serverless Hero である Alex DeBrie様を今回はゲストに迎え、NoSQL とDeveloper /開発者の目線というテーマで、Amazon DynamoDB をメインにベストプラクティスや実際の試行錯誤についてスピーカーによるセッションを行います。 対象 ・RDBMSは知っているけど、NoSQLはまだあまり利用をしていない方 ・RedisはしっているけどDDBはまだ利用したことが無い方 ・DynamoDB/Keyspaces(Cassandra)などのKVS系NoSQLを既に使っている方 これから利用するか悩んでいる、今使っていて効果的に利用出来ているか不安だ、という方は是非お越しください。 参加登録はこちら イベントでは軽食・飲み物をご用意する予定です。もし足りなかったら「大人の常識の範囲内で」1F or 3Fのセブンイレブンで購入の上持ち込みOKなのでお越しください。 スピーカー紹介 まず、登壇者の一人であるAWS Solutions Architectの福井厚について紹介します。福井厚はシニアソリューションアーキテクト : Developer Specialist – DevAxとしてお客様のクラウドネイティブなモダンアプリケーション開発を支援しています。過去にはAWS Summit、AWS Innovate、AWS DevDay、AWS Developer Live Showなど多数登壇し多くのAWSサービスや技術情報を伝えてきました。 開発者としての経験から現在もDevloper として多くのカスタマーを支援し モダンアプリケーションにおける代表的な設計パターン   と言った資料の著者でもあります。 筆者が福井にスピーカーをお願いしたかったのは、開発者としての長年の経験というのと、RDBMSの開発経験も豊富なため良い意味でNoSQLについて慎重な見方をしてくれる所だと思っています。サービスの機能やベストプラクティスについて「実装に落とすなら結局どうするのか？」「他の手段を使った時と比べてどれだけの利点があるのか？」「開発者はそれで本当に嬉しいのか？」という事をいつも指摘してくれました。もちろんそこは明確にお答えしたりケースバイケースな部分もあるんですが、「現実的にどこまで何が嬉しいのか？」という壁打ち的なコメントをしてくれてとても勉強になりました。 今回、福井が改めて開発者としての視点でAmazon DynamoDBをどう扱うのか？というセッションをしてくれるのは筆者として非常に嬉しく思っています。 Alex DeBrie様について そして次のSpeakerである Alex DeBrie様 です。 彼はこのイベントのすぐ後にあるServerless Days Tokyo 2023にてKeynoteを務めるくらいDynamoDBだけではなくServerlessコミュニティにおいても重要な人物です。Serverless Days Tokyo 2023では本当に多くの素晴らしいセッションが予定されており、AWSメンバーもセッション登壇予定です。興味深いセッションが多いのでまだ登録出来そうであれば是非参加してみてください。 https://tokyo.serverlessdays.io/ 我々Solutions Architectの多くのメンバーも彼のDynamoDB Bookを買って読んだという経験が多く彼と同じイベントでDynamoDBについて話す機会を貰えるのは本当に光栄です。少し前のセッションでは2019年のre:InevntなどではData modelingをテーマとして というセッションで登壇されており、その後もre:Inventや他のイベント、AWS Database Blogへの寄稿（最近ではSingle table vs Multi Table designという非常に興味深いエントリを投稿されています） https://aws.amazon.com/jp/blogs/database/single-table-vs-multi-table-design-in-amazon-dynamodb/ そしてAmazon DynamoDB 10周年記念イベントでも登壇しdata modelingについてセッションをされています。 また最近ではDynamoDBのTransactionについてDynamoDB チームのシニアプリンシパルエンジニアであるAkshat Vig & Somu Perianayagamとのディスカッションも公開されました 今回Alex様には筆者からは「例えば自分はこういうスタイルで開発、モデリング、改善、テストをしていると言った開発者としての目線などが伺えるととても嬉しい」と言ったリクエストをさせて頂きました。今回は”Understanding & Using Amazon DynamoDB”というタイトルでの発表となり今から筆者自身が最も発表を楽しみにしています。 このブログ著者である成田は直近のDynamoDBの機能紹介であったりスループットコントロールやそのメカニズムなどについてお話出来ればと考えています。 Amazon DynamoDBに興味を持っている方、開発者として実際に使ってもっと実践的な情報を知りたいという方は是非イベントに参加ください 本ブログ著者 : 成田 俊は、Principal DynamoDB Solutions Architectです。Amazon DynamoDB を使用する多くの AWS のお客様にアーキテクチャのレビューや技術支援を行っています。

このブログは 2021 年 11 月 2 日に Ahmed ElHaw (シニアソリューションアーキテクト) によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 クラウドファースト戦略を採用する多くのお客様は、俊敏性の向上とコストの最適化のために、自動拡張、ビルトインされた高可用性、使用量に応じた課金モデルを提供するサーバーレス技術やクラウドファイルストレージを優先的に採用しています。お客様がサーバーレスアーキテクチャを採用する際、永続的なストレージ層におけるデータアクセスの共有が必要になる場合があります。AWS Lambda には、お客様のコード用に 512MB の一時ファイルシステムが含まれていますが、これは耐久性のあるストレージを意図したものではなく、一時的なリソースとなります。この記事で紹介する Lambda 関数の SMB 統合により、関数の呼び出しにまたがるデータの共有、大きな参照データファイルの読み込み、関数の出力の永続的な共有ストアへの書き込みが可能になります。 この記事では、 AWS Lambda と Amazon FSx for Windows File Server を統合することに焦点を当てます。また、 Amazon FSx for NetApp ONTAP を含む SMB 互換のファイルシステムならどれでも、ご紹介するソリューションを使用することができます。このソリューションでは、Amazon FSx for Windows File Server、Amazon FSx for NetApp ONTAP、オンプレミスの Windows ファイルサーバーで動作する SMB 互換のデータストア、または Amazon EC2 の Windows ファイルサーバーでホストされているファイル共有にて、ファイルやフォルダーの一覧、保存、取得、削除などのファイルおよびディレクトリ操作を実行することができます。 ユースケース コンテンツ管理やウェブサーバー、ホームディレクトリ、ビジネスクリティカルなワークロードなどの分散型アプリケーションは、共有ファイルストレージの恩恵を受けることができます。以下に、一般的なサーバーレスのユースケースを紹介します。 Windows のホームディレクトリや部門内での共有 のような環境において、 Lambda 関数を使用してユーザーのホームディレクトリや部門共有にレポートファイルを書き込むことができます。 Amazon FSx for Windows File Server またはAmazon FSx for NetApp ONTAP は、ホームディレクトリ、部門共有、コンテンツ管理、高可用性 Microsoft SQL Server のデプロイなど、さまざまな用途で使用することができます。 Amazon FSx でコンテンツをホスティングし、ファイル変更イベントに応じた自動化されたサーバーレスアクションを実行します。 Amazon FSx for Windows File Server の ファイルアクセス監査 を使用して、ファイル変更イベントが発生するたびに Amazon CloudWatch にイベントログを生成することができます。また、このような CloudWatch Logs のエントリーが生成された時点で Lambda 関数をトリガーし、変更されたファイルに対して操作を実行することができます。 (例えば、変更されたファイルを最新の内容を反映する必要がある別のデータソースにコピーすることができます) 公開用 SFTP サーバーを通じて組織内でファイルを共有します。 Amazon S3 に保存されたデータと&nbsp; AWS Transfer for SFTP &nbsp;を活用し、外部ファイルを SMB ファイル共有にダウンロードすることが可能です。このサーバーレス統合を通して、Lambda 関数は自動的に S3 からファイルをダウンロードし、共有ファイルシステムに保存することができます。 Amazon Athena &nbsp;を使用して、Amazon S3 に保存されているデータにクエリを実行します。 クエリ結果はカンマ区切り形式 (.csv) で保存され、SMB 互換のファイル共有に結果をコピーしたい場合に有効です。Lambda 関数を使用した Athena クエリのスケジューリングは一般的なユースケースであり、クエリ結果を Windows ファイル共有にコピーするよう拡張した Lambda 関数で、プロセスを自動化することができます。 ソリューションの概要 AWS Lambda は ランタイム を利用することで複数の言語をサポートしています。Python、.NET、Java、Node.js など、一般的なプログラミング言語で SMB を実装したライブラリがいくつかあります。ここでは、異なるランタイムを使用した二つの Lambda 関数を紹介します。一つ目の関数は Python ランタイムを使用し、SMBv2 および SMBv3 プロトコルを実装するオープンソースの Python ライブラリである smbprotocol をインポートします。二つ目の関数 (.NET に慣れている方向け) は、 SMBLibrary &nbsp;(オープンソースの C# SMB 1.0/CIFS, SMB 2.0, SMB 2.1, SMB 3.0 サーバとクライアントの実装) をインポートしています。 これからご紹介する Lambda 関数のコードでは、既存の Amazon FSx for Windows File Server 共有に対して二つの操作 (ファイルの保存と共有の一覧表示) を実装しています。それぞれのライブラリのドキュメントを参照することで、ニーズに合わせて操作を拡張することができます。また、 AWS Secrets Manager を使ったセキュリティ面やクレデンシャル管理についても詳しく説明しています。 手順 Amazon FSx for Windows File Server、Amazon EC2 上の Windows File Server、またはオンプレミス環境で動作する SMB ファイル共有と Lambda 関数の統合を説明します。 図 1: Amazon FSx、EC2、またはオンプレミス環境で動作する SMB ファイル共有と統合する Lambda 関数 ダミーのペイロード (“test”) を持つテストイベントを作成し、Lambda 関数を呼び出します。 AWS Lambda は、他の AWS サービスと統合 して関数を呼び出すことができます。 . 注：Amazon S3 は、Lambda 関数をトリガーできるサービスの例として示されており、Lambda 関数は AWS SDK を使用して Amazon S3 から読み取りと書き込みが可能です。 Lambda 関数が Secrets Manager からファイルサーバーの保存されたクレデンシャル (ユーザー名、パスワード、ホスト、共有名など) を取得します。 Lambda 関数がテストファイルを作成し、ファイル共有に保存します。 AWS Serverless Application Model (SAM) を用いた手順紹介 ソースコードを表示 サンプルのアプリケーションをデプロイするには、以下の前提条件が必要です。 前提条件 リソースを作成するために必要な権限を保持している AWS クレデンシャル。この例では、管理者権限を持つクレデンシャルを使用しています。 利用可能な Amazon FSx ファイル共有、または有効な資格情報と VPC へのルートを持つ SMB 互換のファイル共有。Amazon FSx for Windows File Server をセットアップするには、 Amazon FSx の開始方法 を参照してください。Amazon FSx for NetApp ONTAP の場合は こちらのガイド をご参照ください。 Lambda .NET core ランタイムを使用するテンプレートをデプロイする場合は、 .NET SDK がインストールされていること。 この記事の執筆時点での AWS SAM CLI のバージョン 1.29.0 です。 GitHub のリポジトリ をクローンします。 デプロイ方法 クローンしたリポジトリのディレクトリに移動するか、 sam init &nbsp;を実行して Custom Template Location を選択し、リポジトリの URL を貼り付けます。 &lt;templateName&gt; を Python または .NET テンプレートに置き換え、AWS SAM アプリケーションをビルドします。 sam build -t &lt;templateName&gt; 3. AWS SAM アプリケーションをデプロイします。 sam deploy --guided 図 2:ガイド付き AWS SAM デプロイメントの入力値の例 AWS SAM は以下のステップを実行します。 Secrets Manager にダミー値を格納し、シークレットを作成します。 選択した VPC に Secrets Manager の VPC エンドポイントを作成します。これは、VPC に接続された Lambda 関数に必要です。 CIDR (Classless Inter-Domain Routing) ブロックの管理と参照を容易にするために、 プレフィックスリスト を作成します。 選択したテンプレートに応じて、AWS SAM はいずれかのアクションを実行します。 Python ランタイムで Lambda 関数をビルドしてデプロイし、依存関係を持つライブラリの Lambda レイヤーをビルドして Lambda 関数に関連付けします。 または .NET Core とその依存関係で Lambda 関数をビルドします。 テスト 統合をテストするために、Python の Lambda 関数の内容を説明していきます。 1. Secrets Manager で作成したシークレットのダミー値を、ファイル共有の IP アドレスまたは解決可能なホスト名、サーバー名、ユーザー名、パスワードに置き換えます。 注： 変更を加えるには、まずリソースポリシーを削除する必要があります。AWS マネジメントコンソールから、ルートユーザーとして Secrets Manager にアクセスし、リソースポリシーをメモ帳にコピーしてください。秘密鍵ペアの値を置き換えたら、再びリソースポリシーを復活させます。 注： Amazon FSx for Windows File Server の場合、シークレットのホスト値は、コンソールで見つかった「優先ファイルサーバー IP アドレス」で構成します。Amazon FSx for NetApp ONTAP の場合、シークレットのホスト値は、コンソールで見つかった「管理エンドポイント -IP アドレス」で構成します。 2. Lambda コンソールで関数を選択し、リポジトリにある json ファイル (testevent.json) からペイロードを指定してテストイベントを作成します。 図 3: Lambda 関数のテストイベント成功 3. ファイル共有にファイルが作成されることを確認します。 図 4:ファイル共有にテストファイルが作成されていることを確認 モニタリングとトラブルシューティング ファイル共有アクセスやファイルアクセスを確認するには、Amazon FSx for Windows File Server を使用している場合、 ファイルアクセス監査 を有効にし、CloudWatch でログを確認することができます。Windows ファイルサーバーが EC2 やオンプレミスで稼働している場合は、Windows イベントログを確認します。 セキュリティと接続性 AWS Well-Architected Framework の セキュリティの柱 に従って、すべてのレイヤーでセキュリティを確保します。すべてのレイヤー (ネットワークのエッジ、VPC、ロードバランシング、すべてのインスタンスとコンピューティングサービス、オペレーティングシステム、アプリケーション、コード) に複数のセキュリティコントロールを用い、多層的な防御アプローチを適用します。 注：このソリューションは、サーバーレスワークロードの SMB アクセスを実現する方法についての概念実証です。お客様は自社のソリューションの開発時に、自社のセキュリティ要件を念頭に置く必要があります。 このソリューションでは、いくつかのセキュリティ設定が必要です。 VPC とサブネット このデモソリューションでは、レジリエンシーのため Lambda 関数を VPC と二つのプライベートサブネットで構成しています。この設定により、Lambda 関数から AWS のプライベートリソースへの到達性の確保が可能になります。実際の環境では、ニーズに応じて Lambda 関数のサブネットから適切なルーティングを構成してください。 オンプレミスのファイルサーバーの場合、SMB トラフィックを Amazon VPC に通過させるルーティングルールを持つ Amazon VPN または AWS Direct Connect が必要です。 セキュリティグループ このデモソリューションの Lambda 関数のセキュリティグループには、二つのアウトバウンドルールを設定し、インバウンドルールは設定しません。 シークレットの取得のために、Secrets Manager VPC エンドポイントのセキュリティグループ (宛先) への HTTPS (ポート443) アクセスを許可するアウトバウンドルールを設定します。 SMB トラフィックのために、ファイルサーバーの CIDR ブロック (宛先) への SMB (ポート 445) アクセスを許可するアウトバウンドルールを設定します。 注: 作成したマネージド プレフィックスリスト をオンプレミスネットワークの CIDR ブロックに設定します。 図 5: Lambda 関数のセキュリティグループのアウトバウンドルール Secrets Manager の VPC エンドポイントのセキュリティグループには、インバウンドルールが一つ設定されています。 シークレット取得のため、Lambda 関数のセキュリティグループ (送信元) からのHTTPS (443番ポート) 通信を許可するインバウンドルールを設定します。 図 6: Secrets Manager VPC のエンドポイントセキュリティグループのルールで Lambda 関数のセキュリティグループからのインバウンド HTTPS を許可する 最後に、ファイル共有サーバーのセキュリティグループ (またはオンプレミスのファイアウォールアプライアンス) が、Lambda 関数のセキュリティグループからのインバウンドアクセス (ポート445) を許可していることを確認します。 クレデンシャルの管理 Lambda 関数は、SMB ファイル共有で認証する必要があります。クレデンシャルをハードコーディングしたり、ファイルや環境変数に保存したりすることを避けることが重要です。そのため、今回紹介するソリューションでは Lambda 関数を Secrets Manager と統合して、ファイルサーバーのクレデンシャルとパラメータを保存および取得できるようにしています。Secrets Manager は、次のスクリーンショットのように、キー・バリューのペアの形式でシークレットを保存しています。シークレットに設定する Value をカスタマイズし、Admin のクレデンシャルではなく、必要最低限の権限を持った専用のクレデンシャルを使用することをお勧めします。 図 7: Secrets Manager で認証情報とパラメータが設定されたシークレット Secrets Manager は、アプリケーションでシークレットを取得する方法を説明するコードの例を提供しています。それらを表示するには、 AWS マネジメントコンソール &gt;AWS Secrets Manager&gt;シークレット&gt;シークレットの名前 にアクセスします。 転送中と格納中のデータの暗号化 Amazon FSx for Windows File Server は、ファイルシステムの暗号化において、格納中のデータの暗号化と転送中のデータの暗号化の二つの形式をサポートしています。Amazon FSx ファイルシステムを作成する際に、格納中のデータの暗号化は自動的に有効になります。転送中のデータの暗号化は、SMB プロトコル 3.0 以降をサポートするコンピューティングインスタンスにマッピングされたファイル共有でサポートされています。Amazon FSx は、お客様がアプリケーションを修正しなくとも、ファイルシステムにアクセスする際に、SMB 暗号化を使用して転送中のデータを自動的に暗号化します。 次のスクリーンショットでは、Amazon EC2 で動作する Windows ファイルサーバーと Lambda 関数のトラフィックをスニッフィングしています。Amazon FSx for Windows File Server でも同様の動作が期待できます。ファイルサーバーと Lambda 関数の間で、SMB 3.1.1 ダイアレクトにネゴシエートされたプロトコルを見ることができます。 図 8: Lambda 関数が Amazon EC2 上の Windows 2019 ファイルサーバーに送信する「Negotiate Protocol Request」 プロトコルネゴシエーションが完了すると、以下のスクリーンショットのような Lambda 関数とファイルサーバー間の暗号化されたトラフィックを確認することができます。 図 9: Lambda 関数と Amazon EC2 上の Windows 2019 ファイルサーバー間のトランジットにおける暗号化を示すパケットトレース Amazon FSx ファイルシステム管理のベストプラクティスドキュメント に記述されているように、Amazon FSx for Windows File Server で SMB 3.x をサポートしていないクライアントに対し、転送中の暗号化を強制することによって、暗号化されていないアクセスを制限することができます。 注：この設定では、SMB 3.x をサポートしていないファイルシステムに接続されたクライアント (Lambda関数以外) はすべて接続に失敗します。 図 10: SMB 2 クライアントからの暗号化されていないアクセスを拒否する Amazon FSx for Windows File Server IAMポリシー Lambda 関数と Secrets Manager の VPC エンドポイントからシークレットにアクセスするために、それらのインラインポリシーを次のように設定します。 GetSecretValue アクションは、リソースフィールドで定義されたファイルサーバーのシークレットのみに制限されます。 Version: "2012-10-17" Statement: - Effect: Allow Principal: '*' Action: - 'secretsmanager:GetSecretValue' Resource: !Sub ${MySecret} リソースポリシー さらに、Secrets Manager&nbsp;に格納されているシークレットに対してリソースポリシーを設定しています。Secrets Manager に対して、定義されたソース VPC エンドポイントからのリクエストでない限り、すべてのリクエストを明示的に拒否するようにします。 注：今回の AWS SAM テンプレートでは、次のようなポリシーが作成されます。 Version: "2012-10-17" Statement: - Sid: EnableSecretsManagerpermissions Effect: "Allow" Principal: AWS: !Sub "${AWS::AccountId}" Action: "secretsmanager:*" Resource: "*" - Sid: RestrictGetSecretValueoperation Effect: "Deny" Principal: '*' Action: "secretsmanager:GetSecretValue" Resource: "*" Condition: StringNotEquals: 'aws:sourceVpce': !Sub '${SecretsManagerVPCEndpoint}' リソースの削除 環境を削除するには CloudFormation スタックを削除するか、ターミナルから sam delete を実行します。 まとめ この記事では、Python と .NET 用のオープンソースライブラリを使用して、Lambda 関数と Amazon FSx for Windows File Server または Amazon FSx for NetApp ONTAP または SMB 互換ファイル共有を統合する方法を紹介しました。このデモソリューションはサーバーレスで、AWS SAM を使って簡単にデプロイすることができます。また、ソリューションのすべてのレイヤーのセキュリティについても説明しています。この統合により、Lambda 関数は SMB 互換の永続データストアでファイル操作を実行できるようになります。 AWS Lambda を Amazon FSx ファイル共有と統合することで、関数呼び出し間でデータを共有できるようになり、Windows ホームディレクトリへのファイルの自動保存したり、ファイル変更イベント時にプログラムによるアクションを実行したり、関数呼び出しのための大規模かつ永続的なデータストアが必要なユースケースなど、Lambda を新たなユースケースで利用できます。 また、他の Lambda ランタイムや、Java や Node.js などのオープンソースの SMB ライブラリも、ご希望に応じてお試しください。すべてのソリューションの成果物は GitHub リポジトリ で公開されており、必要に応じて拡張することができます。 当記事をお読みいただきありがとうございました。 翻訳はネットアップ合同会社の岩井氏、監修はソリューションアーキテクトの松本が担当しました。 <!-- '"` --> Ahmed ElHaw Ahmed ElHaw は、テレコム、ウェブ開発とデザイン、空間コンピューティング、AWS サーバーレスコンピューティングのバックグラウンドを持つ AWS のシニアソリューションアーキテクトです。彼は顧客に技術的なガイダンスを提供し、AWS を最大限に活用するソリューションの構築とその支援を楽しんでいます。仕事以外では、子供たちと過ごしたり、コーディングしたり、ビデオゲームをしたりするのが好きです。

昨今、生成系 AI をビジネスに利用する動きが活発化しています。AWS はお客さまがこの新しいテクノロジーの価値をフルに活かせるように、生成系 AI の専門家からなるチームを設置するとともに、柔軟性と費用対効果に優れた生成系 AI サービスを企業に提供しています。あらゆる組織が AI を活用できるように支援するという目標を掲げているのです。 その一環としてアマゾン ウェブ サービス ジャパンは 2023 年 7 月 3 日に、日本独自の施策として国内に法人または拠点を持つ企業・団体の大規模言語モデルの開発を支援する「 AWS LLM 開発支援プログラム 」を開始しました。本プログラムでは、LLM 開発を行うための計算機リソース確保に関するガイダンスや AWS 上での LLM 事前学習に関わる技術的なメンタリング、LLM 事前学習用クレジット、ビジネス支援などのサポートを提供します。 そしてこのたび、本プログラムで支援する企業・団体が正式に決定しました。本格的な LLM 開発支援が始まり、今後は 2023 年 12 月以降の成果発表会へと進むことになります。2023 年 9 月 4 日には「AWS LLM 開発支援プログラム」の採択企業が集い、Kick off party が開催されました。今回はこのイベントのレポートをお届けします。 代表執行役員社長 長崎 忠雄によるご挨拶 イベントの冒頭では、アマゾン ウェブ サービス ジャパン 代表執行役員社長の長崎 忠雄が、「AWS LLM 開発支援プログラム」推進にあたってのご挨拶をしました。アマゾン ウェブ サービス ジャパンは「日本の LLM 開発者や LLM 技術の発展に貢献したい」という思いから、このプログラムを開始。告知後は 60 社弱の企業から応募があったことに長崎は触れ、「ご応募いただいたみなさまに、この場を借りてお礼を申し上げます」と感謝の言葉を述べました。 アマゾン ウェブ サービス ジャパン 代表執行役員社長 長崎 忠雄 AWS は 2006 年に創業し、「テクノロジーを民主化する」という思いのもとクラウドコンピューティングを提供してきました。AI や機械学習などの領域においても、同様に民主化のための取り組みを続けています。 2023 年 6 月 22 日（米国時間）には、AWS は生成系 AI ソリューションの構築と展開を支援する新プログラム「AWS 生成系 AI イノベーションセンター」を稼働開始。「あらゆる技術領域の民主化を、私たちはお客さまとともに実現します」と長崎は解説しました。 こうした各種の取り組みは、Amazon がミッションステートメントとして掲げる Working Backwards（お客さまを起点に考える）という価値観に基づいています。「AWS LLM 開発支援プログラム」も、日本における LLM の開発・普及を加速させ、各社の事業の成長を目指しているのです。 「たくさんのご応募があったなかから、今回は 17 社を採択いたしました。みなさまとともに日本の技術発展に貢献し、各社のプロダクトが世界に羽ばたくような未来を見据えて、ご支援させてください」と結びました。 執行役員 技術統括本部長 巨勢 泰宏によるご挨拶 続いてはアマゾン ウェブ サービス ジャパン 執行役員 技術統括本部長の巨勢 泰宏からご挨拶をしました。「AWS LLM 開発支援プログラム」にご応募いただいたのは優れた技術や事業を持つ企業ばかりであったこと、選考においても多くの時間がかかったことなどを巨勢は語ります。 アマゾン ウェブ サービス ジャパン 執行役員 技術統括本部長 巨勢 泰宏 AWS は AI・機械学習の領域において、お客さまに長らくサービスの提供や技術的な支援をしてきました。その結果、数多くの成果が生まれています。生成系 AI の領域においても、2022 年 4 月に Amazon Bedrock を発表しただけではなく、たくさんのお客さまを対象として技術的な支援を行ってきました。「生成系 AI を活用してプロダクトを改善したい」「生成系 AI で新たなビジネスを創出したい」という企業・団体のニーズは高まり続けています。そうした声に応えるため、「AWS LLM 開発支援プログラム」をスタートしました。 「このプログラムを通じて、採択企業には新しい化学反応を起こす機会を作っていただきたい。そして、AWS はクラウドという基盤や各種のプログラム、メンタリングなどを提供し、みなさまをご支援していきます」と巨勢は思いを述べました。 「AWS LLM 開発支援プログラム」の詳細を解説 ここからは「AWS LLM 開発支援プログラム」の企画・運営に携わるアマゾン ウェブ サービス ジャパン 機械学習ソリューションアーキテクトの宇都宮 聖子が、本プログラムの概要や採択企業、AWS のサポート体制についてご紹介しました。 アマゾン ウェブ サービス ジャパン 機械学習ソリューションアーキテクト 宇都宮 聖子 本プログラムでは、LLM の開発に必要な 4 つの支援を AWS が提供しています。1 つ目は「計算機リソース選定と確保のガイダンス」です。利用するモデルや深層学習フレームワークなど、参加企業ごとの技術要件に応じた適切なインスタンスの種類の選定や、その計算機リソースを AWS 上で確保するためのガイダンスを実施しています。 2 つ目は「技術相談やハンズオン支援」です。AWS 上での分散学習やクラスタリング時のネットワーク性能最適化、マネージドサービスの活用、 AWS Trainium / AWS Inferentia の利用などについて、AWS の技術エキスパートによるサポートを行います。 3 つ目は「LLM 事前学習用の AWS クレジット」です。総額で 600 万 US ドル規模のクレジットを投資し、事前学習用のワークロードに必要な計算機リソースなどの費用を一部支援します。 4 つ目は「ビジネスプランおよびユースケースに関する支援」です。開発した LLM をビジネスに活用する方法や AWS Marketplace などを活用した LLM の公開・販路拡大支援、 Amazon SageMaker JumpStart の活用、ビジネスクライアント候補やベンチャーキャピタルとのコミュニケーションなどを実施します。 プログラムは以下のような流れで進行します。 参加対象は「LLM 開発を行う国内の企業・団体」「数十億〜一千億パラメータ以上の規模の LLM の事前学習をしている企業・団体」「今年の 11 月末までに開発成果（例: 本番環境でのローンチなど）を出すことを目指している」「クラウドを活用し、より効率的な方法で LLM を開発したい」などの条件を満たす企業・団体です。そして、技術的観点や研究開発的観点、ビジネス的観点といった総合的な要素を鑑みて選考を実施しました。 応募状況としては、前述の長崎の説明でもあったように 60 社弱の応募があり、そのなかから 17 社を採択しました。スタートアップ企業から大企業まで幅広く、多様な LLM モデルの開発を進める企業・団体が含まれています。以下が「AWS LLM 開発支援プログラム」採択企業の一覧です（公開可能な企業および団体）。 会社・団体名（社名五十音順・敬称略） ・カラクリ株式会社 ・株式会社サイバーエージェント ・ストックマーク株式会社 ・Sparticle株式会社 ・Turing株式会社 ・株式会社Preferred Networks ・株式会社Poetics ・株式会社松尾研究所 ・株式会社マネーフォワード ・株式会社ユビタス ・株式会社Lightblue ・株式会社リクルート ・株式会社リコー ・rinna株式会社 ・株式会社ロゼッタ ・株式会社わたしは AWS と上記の企業・団体はすでに以下の取り組みを実施しています。 ・プログラム期間中のスケジューリング ・計算機リソースの確保のガイダンス ・技術とビジネスの両面でのプランニング ・2023 年 8 月 30 日、2023 年 9 月 4 日に Prototyping Camp を実施 宇都宮は AWS のサポート体制についても解説しました。「AWS LLM 開発支援プログラム」では、AWS の国内外のスペシャリスト・スポンサーによって技術・ビジネスの両面から企業・団体のサポートを行います。 スピーチの終盤では、機械学習向け Amazon EC2 インスタンスそれぞれの特徴や、採択企業向けの Prototyping Camp にて各種インスタンスを参加者にお試しいただいたことなども、宇都宮は解説しました。 イベント参加の採択企業によるご挨拶 次に、イベントに参加していた採択企業より「AWS LLM 開発支援プログラム」参加にあたっての意気込みを語っていただきました。 サイバーエージェント社は「マルチモーダルな LLM や次世代アーキテクチャ構築などにチャレンジしたい」と宣言。 リコー社は「採択企業はライバルではなく、ともに LLM 技術の発展を目指す同志だと考えています」と、会場の方々に語りかけます。 ストックマーク社は「さまざまなビジネスのユースケースに活用できる LLM を作りたい」と大きなビジョンを述べ、 Sparticle 社も「LLM 技術の隆盛は歴史的なチャンスだと思っているため、各社とともに頑張りたい」と前向きな気持ちを語りました。 わたしは社は自社プロダクトの大喜利 AI について触れ「これまでも私たちは言語モデルの開発に取り組んできましたが、より一層この技術に力を入れたい」と言及。 完全自動運転 EV の開発を行う Turing 社も「開発した LLM 関連技術を自動運転の改善に活かしたい」と志を述べました。 リクルート社は自社が多種多様な事業を展開していることを述べたうえで、「それらの事業で蓄積したデータやドメイン知識などを活用し、良い LLM を生み出したい」と前向きに解説しました。 アマゾン ウェブ サービス ジャパン スタートアップ事業本部 技術統括部 本部長 塚田 朗弘（写真左） ここで採択企業によるご挨拶の前半パートが終了。「AWS LLM 開発支援プログラム」の企画・運営・立ち上げに携わっているアマゾン ウェブ サービス ジャパン スタートアップ事業本部 技術統括部 本部長の塚田 朗弘が、機械学習やコンピューティングのスペシャリストで支援体制を構築していることを述べ、会場にいる AWS のメンバーから一言ずつコメントをもらいます。そして「乾杯！」の言葉の後に会場の参加者が飲み物を口にし、採択企業によるご挨拶の後半パートに移ります。 ロゼッタ社は自社の歴史・沿革について述べたうえで「AWS 社や他の採択企業とも協力しながら、最良のものを世の中に出していきたい」と提言。 カラクリ社は提供している事業内容にちなみ、「カスタマーサポートの業務を LLM の技術によって改善していきたい」と目標を掲げます。 AI キャラクター「りんな」を提供する rinna 社は「採択企業のみなさまと一緒に AI の民主化を推進したい」と説明。 自然言語処理や画像解析の AI 開発に強みを持つ Lightblue 社は、ユーモアを交えつつ開発のビジョンを語りました。 「音声のコミュニケーションデータと LLM とを組み合わせて新たな可能性を探りたい」と話したのは、音声認識や音から人の感情を解析する AI、自然言語処理などを扱う Poetics 社。 ユビタス社は GPU 仮想化技術やクラウドストリーミング・プラットフォームに強みを持つ自社の事業について解説。 最後に、東京大学松尾研究室の技術の社会実装を目指す松尾研究所社が意気込みを述べ、採択企業によるご挨拶が終了しました。 閉会のご挨拶 イベント最終盤には「AWS LLM 開発支援プログラム」の企画・運営に携わるアマゾン ウェブ サービス ジャパン スタートアップ事業本部 アカウントマネジメント部 部長の岡田 大志が閉会のご挨拶をしました。 「日本を代表する AI・機械学習の専門家のみなさまとこのプログラムをご一緒できることを、非常にうれしく思っています。プログラムにご参加くださった各社には、公募への申し込みやヒアリング、プランニングセッション、Prototyping Camp など多大なるご協力をいただきました」と岡田は感謝の言葉を述べました。 アマゾン ウェブ サービス ジャパン スタートアップ事業本部 アカウントマネジメント部 部長 岡田 大志 ここから本格的な LLM 開発支援が始まり、2023 年 12 月以降の成果発表会を目指して採択企業各社 と AWS はプロジェクトを進めていきます。みなさまの LLM に関する取り組みの成功確率を上げられるように、そして最終的には各社のビジネスにも良い影響を与えられるように、AWS は最大限の支援を行います。 「LLM のトッププレイヤーが一堂に会する機会は、非常に貴重だと思います。今後も AWS はこうした交流会を開催してまいりますので、ぜひみなさま奮ってご参加いただき、情報交換やネットワーク構築にお役立てください」と岡田はイベントを総括しました。

本記事は、「 How to establish private connectivity for ECS Anywhere 」（2023 年 5 月 26 日公開）を翻訳したものです。 はじめに 2014 年、AWS は Amazon Elastic Container Service (Amazon ECS) を発表しました。これは、コンテナ化されたアプリケーションのオーケストレーション、デプロイ、スケーリングを支援するフルマネージド型サービスです。Amazon ECS は、さまざまな業界業種のお客様にご利用いただいていますが、アプリケーションをローカルで実行する必要がある場合もあります。特に規制の厳しい業界ではよくある要件になります。この課題を解決するためにAWSは Amazon ECS を拡張し、2020 年に Amazon ECS Anywhere (Amazon ECS-A)を発表しました。これは、お客様が Amazon ECS のシンプルさと機能性を利用して、コンテナベースのアプリケーションを AWS リージョン以外で、お客様のオンプレミス環境で実行できるオプションです。仮想マシン (VM)、ベアメタルサーバー、またはお客様が管理するその他のインフラストラクチャを使用することが可能となります。 ECS-A コントロールプレーンは AWS 上で動作し、Amazon ECS と同じ API ですが、コンテナベースのアプリケーションは任意のセルフマネージドのハードウェアでホストすることが可能です。このようにコントロールプレーンとデータプレーンを分離するためには、企業のデータセンターと Amazon ECS エンドポイント間の通信パスが必要であり、多くの場合、プライベート通信チャネルが必要になります。 この記事では、AWS リージョン外でホストされている Amazon ECS Anywhere 管理のコンテナベースのアプリケーションと、Amazon ECS コントロールプレーン API との間で、AWS サイト間 VPN (S2S VPN) または AWS Direct Connect (DX) を使用して、安全かつプライベートな方法でプライベート通信チャネルを確立する方法について説明します。 ECS-A ソリューションアーキテクチャ Amazon ECS Anywhere を使用すると、お客様は独自のインフラストラクチャと Amazon ECS を合わせて活用することが可能となり、コンテナワークロードを大規模にスケジュールし、実行することが可能となります。独自のインフラストラクチャを使用するためには、VM を Amazon ECS マネージドインスタンスとして登録する必要があり、お客様の施設と AWS リージョン間の接続が必要です。この接続は、インターネット経由で公開することも、AWS Direct Connect または仮想プライベートネットワーク (VPN) を使用してプライベートに確立することもできます。 コンフィグの一部として、オンプレミス環境には AWS Systems Manager (SSM) エージェントと Amazon ECS エージェントの両方が必要です。 SSM エージェントは AWS Systems Manager のコンポーネントで、AWS Systems Manager のオンホスト機能を実行します。インスタンスから AWS API を実行できるようにするために、インスタンス登録プロセスで、AWS Systems Manager がアクティベーションキーとインスタンスロール認証情報を生成して SSM エージェントに送信します。もう 1 つのコンポーネントは Amazon ECS エージェントで、これは AWS リージョンの Amazon ECS コントロールプレーンと通信し、サーバーまたは VM をマネージドインスタンスとして登録し、コンテナ設定やタスクスケジューリングなどの指示を受信して実行します。図 1 はこのアーキテクチャを示しています。 図1 ソリューション概要 ECS-A プライベート通信アーキテクチャ Amazon ECS Anywhere は接続切断や信頼性の低い接続に耐えられますが、AWS リージョンとお客様の施設間のプライベート接続により、より高いレベルのセキュリティ、信頼性、およびパフォーマンスが保証されます。図 2 は、Amazon ECS エージェントと SSM エージェントがコントロールプレーン API を使用してプライベートかつ安全に通信できるアーキテクチャを示しています。ECS Anywhere コントロールプレーン API 宛のプライベート VPC エンドポイントを作成し、DNS クエリを Route 53 インバウンドリゾルバーエンドポイントに転送し、プライベート IP アドレスで応答することで、エージェントはプライベート通信チャネル (DX やサイト間 VPN など) を介して AWS サービスと通信します。 図2 前提条件 このソリューションの前提条件は以下となります。 AWS アカウント Amazon ECS Anywhere クラスタ AWS Direct Connect や サイト間 VPN によるVPC とオンプレミス環境間のプライベート接続 プライベート通信チャネル この記事では、オンプレミス環境と AWS VPC の間にプライベート通信チャネルを設定する方法については詳しく説明しません。ただし、(1) AWS Direct Connect と (2) サイト間 VPN の 2 つのオプションがあります。 どちらを選択しても、この通信チャネルが設置されていれば、AWS とオンプレミス環境との間にプライベート IP アドレスを使用して双方向接続が可能になります。 ウォークスルー 以下のコンポーネントは任意の順序でデプロイできます。 Amazon VPC 内で Amazon ECS と AWS Systems Manager のインターフェース VPC エンドポイント( AWS PrivateLink ) Amazon VPC 内での Route 53 リゾルバーのインバウンドエンドポイント オンプレミス環境での DNS 条件付き転送ルール 最後に、オンプレミス環境の Amazon ECS-A エージェントが AWS とプライベートに通信するように設定します。 AWS PrivateLink AWS PrivateLink は、トラフィックをインターネットに公開することなく、VPC、AWS サービス、オンプレミスネットワーク間のプライベート接続を提供します。AWS PrivateLink を使用するには、 インターフェイス VPC エンドポイントを作成 します。VPC エンドポイントを作成すると、指定したサブネットにネットワークインターフェイスが作成され、サブネットのアドレス空間からのプライベート IP がそのインターフェイスに割り当てられます。このアーキテクチャでは、6 つのエンドポイントを作成する必要があります。 com.amazonaws.&lt;region&gt;.ecs-agent com.amazonaws.&lt;region&gt;.ecs-telemetry com.amazonaws.&lt;region&gt;.ecs com.amazonaws.&lt;region&gt;.ssm com.amazonaws.&lt;region&gt;.ssmmessages com.amazonaws.&lt;region&gt;.ec2messages 図3 オプションとしてAmazon Elastic Container Registry ( Amazon ECR ) を使用してコンテナイメージを保存する場合は、 以下のエンドポイント が追加で必要になります。 com.amazonaws.&lt;region&gt;.ecr.dkr com.amazonaws.&lt;region&gt;.ecr.api com.amazonaws.&lt;region&gt;.s3 また、 Amazon CloudWatch Logs でログを受信したい場合は、以下のエンドポイントも必要になります。 com.amazonaws.&lt;region&gt;.logs Route 53 インバウンドリゾルバー オンプレミスリソースが VPC エンドポイントの DNS 名をプライベート IP アドレスに解決する必要があります。このステップを省略した場合、ドメイン名がパブリック IP アドレスに解決されます。 1 つの選択肢は、VPC エンドポイントの A レコードをオンプレミスの DNS サーバーに設定することです。ただし、エンドポイントを再作成したり、サブネットを変更したりする場合は、これらの A レコードを手動で変更する必要があります。言い換えると、これらのレコードが最新の状態に保たれるようにする責任をユーザーが持つ必要があります。 それに対して、推奨される解決策は、Amazon Route 53 リゾルバー用のインバウンドエンドポイントを作成することです。インバウンドエンドポイントを使用すると、外部ネットワークからの VPC に対する DNS クエリを解決できます。そして、オンプレミス DNS サーバーが特定のドメインのクエリを Route 53 リゾルバーに転送するように、条件付き転送ルールを設定します。これにより、VPC 内のリソースの DNS レコードの管理について心配する必要がなくなります。 「 インバウンド転送の設定 」セクションの手順に従って設定してください。図 4 は、2 つの IP アドレスを持つ構成済みのインバウンドエンドポイントの例を示しています。 図4 オンプレミスの DNS 解決 最後のステップは、前述の 6 つのサービスのクエリを転送するようにオンプレミス DNS サーバーを構成することです。&lt;region&gt;.amazonaws.com ドメインを Route 53 リゾルバーのインバウンドエンドポイントの IP アドレスに送信します。これは DNS サーバーソフトウェアに大きく依存します。図 3 の 6 つのエンドポイントに対して、次の DNS 転送を構成する必要があります。 ecs-a*.us-east-2.amazonaws.com ecs-t*.us-east-2.amazonaws.com ecs.us-east-2.amazonaws.com ssm.us-east-2.amazonaws.com ssmmessages.us-east-2.amazonaws.com ec2messages.us-east-2.amazonaws.com これらの設定の後、オンプレミスエージェント (Amazon ECS と SSM) が AWS エンドポイントに到達しようとする際に、ターゲットドメイン名を解決すると、オンプレミス DNS サーバーは DNS クエリを Route 53 インバウンドリゾルバーに転送し、対応する VPC エンドポイントのプライベート IP が応答されます。エージェントは、事前に確立されたプライベート通信チャネル (DX や S2S VPN など) を使用して VPC エンドポイントのプライベート IP と通信します。 ハイブリッド DNS アーキテクチャの詳細については、 Hybrid Cloud DNS Options for Amazon VPC のホワイトペーパーをご覧ください。 DNS 設定およびオンプレミス環境から Route 53 Resolver エンドポイントの IP へのアクセスを確認するには、dig、nslookup、またはその他任意の DNS ルックアップコマンドを使用できます。 $ nslookup api.ecr.us-east-2.amazonaws.com Server: 10.0.0.32 Address: 10.0.0.32#53 Non-authoritative answer: api.ecr.us-east-2.amazonaws.com canonical name = ecr.us-east-2.amazonaws.com. Name: ecr.us-east-2.amazonaws.com Address: 10.0.0.45 結果には、インターフェイス VPC エンドポイントのプライベート IP（前の例では 10.0.0.45）が出力されるはずです。 設定の詳細とトラブルシューティングのヒントについて、「 How do I configure a Route 53 Resolver inbound endpoint to resolve DNS records in my private hosted zone from my remote network 」の記事には Route 53 Resolver インバウンドエンドポイントの詳細な設定手順が記載されています。 SSM エージェントと ECS-A エージェント ここまできて、Amazon ECS-A をセットアップすることができます。クラスターのアクティベーションキーを取得し、両方のエージェントをインストールして、インスタンスを登録します。 詳細な手順については、「 クラスターへの外部インスタンスの登録 」のドキュメントページを参照してください。 クリーンアップ 追加の検証コストの発生を防ぐために、作成したすべての VPC エンドポイントとインバウンドエンドポイントを削除してください。 VPC エンドポイントの削除 VPC コンソール を開きます。 [仮想プライベートクラウド] の [エンドポイント] に移動します。 作成したエンドポイントを選択し、[アクション] → [VPC エンドポイントの削除] をクリックします。 インバウンドエンドポイントの削除 Route 53 コンソール を開きます。 [リゾルバー] セクションの [インバウンドエンドポイント] に移動します。 インバウンドエンドポイントを選択します。 [削除] を選択します。 結論 この記事では、AWS サイト間 VPN または AWS Direct Connect のプライベート接続を使用して、Amazon ECS Anywhere の高いレベルのセキュリティと信頼性を実現する方法を紹介しました。 AWS 側で必要な設定手順 (インターフェイスエンドポイントとリゾルバーエンドポイント) と、オンプレミスの DNS 転送の設定手順の概要について説明しました。 自身の環境でこのソリューションを試して、プライベート通信チャネルを活用してください。Amazon Simple Storage Service ( Amazon S3 ) や Amazon CloudWatch など他のサービスにも同様のトラフィックフローを適用することができます。詳細については、「 Hybrid Networking using VPC Endpoints (AWS PrivateLink) and Amazon CloudWatch for Financial Services 」と「 Secure hybrid access to Amazon S3 using AWS PrivateLink 」の記事をご覧ください。 著者について Ivo Pinto Ivo は AWS のシニアソリューションアーキテクトです。Ivo は、ネットワークを専門とし、オンプレミスとクラウドの両方で世界規模のインフラストラクチャを構築した経歴があります。3 つの CCIE を持ち、Cisco Press の「Network Automation Made Easy」という本を執筆しています。 Diogo Minhava Lopes Diogo は AWS のシニアソリューションアーキテクトです。ソフトウェア開発の経歴があり、共同設立したスタートアップ企業を含め、異なる規模の企業にクラウドテクノロジーを活用する 8 年間の経験を持ちます。 Pedro Santos Pedro は、リスボンを拠点とする AWS のシニアソリューションアーキテクトです。データエンジニアリングとクラウドアーキテクチャを専攻し、過去 8 年間クラウドテクノロジーに携わってきました。 翻訳はソリューションアーキテクトの陳誠が担当しました。

この記事は Improving operational visibility with AWS Fargate task retirement notifications (記事公開日 : 2023 年 9 月 6 日) の翻訳です。 導入 AWS Fargate は、コンテナワークロードのためのサーバーレスコンピューティングエンジンであり、基盤となるインフラストラクチャの保護やパッチ適用といった、ビジネスに付加価値をもたらさない作業から解放してくれます。この記事では、AWS がインフラストラクチャを安全かつ最新の状態に保つための仕組みの 1 つである Fargate タスクのリタイア通知 について深掘りします。 AWS は、Fargate タスクのリタイアプロセスに関する最近のアップデートにおいて、お客様が受け取る リタイアに関する通知 を統合し、 リタイア通知を受け取ってから実際にタスクがリタイアするまでの時間 を制御する仕組みを導入しました。この記事では、これらの変更点を詳しく確認し、リタイア通知を使用して オペレーショナルエクセレンス を実現する例を紹介します。 背景 AWS Fargate 上に Amazon Elastic Container Service (Amazon ECS) タスクをデプロイする際、スタンドアロンタスクを実行する API コール または ECS サービス において、 プラットフォームバージョン を指定します。プラットフォームバージョンは、カーネルとコンテナランタイムの組み合わせで構成される、ホスト OS のランタイム環境を指します。また、プラットフォームバージョンには、内部的に複数のプラットフォームバージョンリビジョンが存在します。プラットフォームバージョンリビジョンはイミュータブルであり、例えばカーネルのバグ修正やセキュリティアップデートなど、環境の変化に追従してリリースされます。新しいタスクが AWS Fargate にスケジューリングされると、指定されたプラットフォームバージョンの最新リビジョンでタスクが起動します。 AWS は、時間の経過とともに「タスクを実行中の既存のプラットフォームバージョンリビジョンをリタイアさせる必要がある」と判断することがあります。リビジョンがリタイアすると、AWS Fargate はそのリビジョンで実行中のすべてのタスクを終了します。リビジョンをリタイアさせる理由には、セキュリティの脆弱性やパフォーマンスの改善などがあります。AWS Fargate では、これまで月に 1、2 個のプラットフォームバージョンリビジョンをリタイアさせてきましたが、プラットフォームバージョンリビジョンには特に決まったサポート期間は存在しません。プラットフォームバージョンリビジョンのライフサイクルを考慮すると、短命のワークロードを実行している場合には、数週間にわたって実行されるタスクを実行している場合に比べて、リビジョンのリタイアに伴いタスクが終了する可能性は小さくなります。 上図は、AWS Fargate プラットフォームバージョンリビジョンのライフサイクル全体を示します。新しいプラットフォームバージョンリビジョンが利用開始されると、すべての新しいタスクは新しいリビジョンに配置されるようになります。すでに配置され、実行中の既存のタスクは、タスクのライフサイクル全体において最初に配置されたリビジョンに留まり、新しいリビジョンに移行することはありません。 ECS サービスの更新 や Fargate タスクのリタイアなどの理由でタスクが置き換えられる場合、新しいタスクは、起動時に利用可能な最新のプラットフォームバージョンリビジョンに配置されます。 タスクのリタイア 下図に、Fargate タスクのリタイアプロセスの全体像を示します。 特定のプラットフォームバージョンリビジョンをリタイアさせる必要がある場合、すべての AWS リージョンにおいて、AWS はそのプラットフォームバージョンリビジョンで実行中のすべてのタスクを特定します。その後、リージョンごと、アカウントごとに 1 つの通知を送信し、影響を受けるタスクやサービス、実際にリタイアプロセスが開始する日時を案内します。通知は、AWS アカウントのプライマリメールアドレスおよび AWS Health Dashboard に送信されます。AWS Health Dashboard に送信された通知は、 Amazon EventBridge を通じて AWS サービスやサードパーティツール に転送できます。 リタイア通知が送信されてから AWS Fargate が自動的にタスクのリタイアプロセスを開始するまでの正確なタイミングを制御したい場合、タスクのリタイア待機時間と呼ばれる値を設定し、対応するための時間を指定できます。タスクが ECS サービスとして実行されている場合、AWS Fargate は ECS サービスの minimumHealthyPercent を考慮しつつタスクを置き換えます。 スタンドアロンタスク の場合、実行中のタスクの状態を監視し、タスクを置き換えるのはお客様の責任です。 Fargate タスクのリタイアの影響を最小化するために、 Amazon ECS ベストプラクティス に従ってワークロードをデプロイするべきです。例えば、ウェブサーバーや API サーバーなどのステートレスなアプリケーションを ECS サービスとしてデプロイする場合、タスクの複数のレプリカをデプロイし、 minimumHealthyPercent を 100% に設定します。これにより、AWS Fargate がタスクのリタイアを開始した際に、Amazon ECS はまず新しいタスクをスケジューリングし、 実行 されるのを待ってから、古いタスクを終了します。 タスクのリタイアプロセスの詳細については、 AWS Fargate ドキュメント を参照してください。 タスクのリタイア待機時間 タスクのリタイア待機時間の値は、 Amazon ECS アカウント設定 内の fargateTaskRetirementWaitPeriod で制御できるようになりました。例えば、特定のウィンドウでのみ停止可能なワークロードを実行している場合、タスクのリタイア待機時間を使用して、独自のスケジュールでタスクを終了するように設定できます。 タスクのリタイア待機時間には、以下の表のいずれかの値を設定できます。新しいプラットフォームバージョンリビジョンをより早く適用するために、できる限り待機時間を短く設定することをおすすめします。 日数 アクション 0 通知を送信してすぐに、影響を受けるタスクのリタイアを開始します。 7 通知を送信してから 7 日後に、影響を受けるタスクのリタイアを開始します。 14 通知を送信してから 14 日後に、影響を受けるタスクのリタイアを開始します。 稀に重大なセキュリティアップデートがある場合、AWS Fargate は設定したタスクのリタイア待機時間を上書きし、待機時間無しで対象のタスクをリタイアさせることがあります。この場合、 fargateTaskRetirementWaitPeriod を 0 に設定した場合と同じ挙動となります。 現在の fargateTaskRetirementWaitPeriod の値は、 aws ecs list-account-settings コマンドで確認できます。 $ aws ecs list-account-settings \ --name fargateTaskRetirementWaitPeriod \ --effective-settings { "settings": [ { "name": " fargateTaskRetirementWaitPeriod", "value": "14", "principalArn": "arn:aws:iam::123456789012:root" } ] } fargateTaskRetirementWaitPeriod を変更したい場合は、 aws ecs put-account-setting-default コマンドを使用します。 $ aws ecs put-account-setting-default \ --name fargateTaskRetirementWaitPeriod \ --value 14 タスクのリタイア待機時間の詳細については、 Amazon ECS ドキュメント と Amazon ECS 開発者ガイド を参照してください。 ソリューション概要 : タスクのリタイア通知を捕捉する タスクのリタイアが予定されている場合、AWS は AWS Health Dashboard と AWS アカウントのプライマリメールアドレスに タスクのリタイア通知 を送信します。AWS Health Dashboard は、 Amazon EventBridge を含む多くの AWS サービス と統合されています。Amazon EventBridge を利用することで、ChatOps ツールに通知を転送してリタイアの可視性を高めたり、タスクのリタイア通知への対応を自動化することもできます。 AWS Health Aware は、AWS Health Dashboard のパワーと通知を組織全体に配布する方法を紹介する素晴らしいリソースです。このプロジェクトを参考に、タスクのリタイア通知をチャットアプリケーションである Slack に転送する例を紹介します。このソリューションでは、タスクのリタイア通知は EventBridge ルールによって捕捉され、Event Detail Type が AWS Health Event かつ Event Detail Code が AWS_ECS_TASK_PATCHING_RETIREMENT であるイベントがフィルタリングされます。ルールが通知を捕捉すると、 AWS Lambda 関数をトリガーし、影響を受けるリソースのイベントを解析、 Slack Incoming Webhook に転送します。 下図に、このソリューションのアーキテクチャを示します。 前提条件 ソリューションのウォークスルーを実施するには、以下の前提条件を満たす必要があります。 Incoming Webhook Slack アプリケーション がインストール、有効化された既存の Slack ワークスペース Amazon EventBridge ルールと AWS Lambda 関数をデプロイするための権限を持つ AWS アカウント AWS SAM CLI がインストールされたローカル開発環境 ウォークスルー このウォークスルーのサンプルコードは GitHub リポジトリ で確認できます。まず最初のステップとして、リポジトリをローカル開発環境にクローンします。 $ git clone https://github.com/aws-samples/capturing-aws-fargate-task-retirement-notifications.git $ cd capturing-aws-fargate-task-retirement-notifications 次に、AWS SAM テンプレート ( cloudformation.yaml ) で定義した Lambda 関数と EventBridge ルールをビルド、デプロイします。デプロイウィザードでは、Slack ワークスペース URL や Slack チャンネルなどのパラメータを入力する必要があります。 $ sam build --template cloudformation.yaml $ sam deploy --guided Configuring SAM deploy ====================== Looking for config file [samconfig.toml] : Not found Setting default arguments for 'sam deploy' ========================================= Stack Name [sam-app]: FargateTaskRetirementNotifications AWS Region [eu-west-1]: eu-west-1 Parameter SlackWorkspaceURL []: https://hooks.slack.com/services/workspace/app/token Parameter SlackChannel []: platform-eng #Shows you resources changes to be deployed and require a 'Y' to initiate deploy Confirm changes before deploy [y/N]: y #SAM needs permission to be able to create roles to connect to the resources in your template Allow SAM CLI IAM role creation [Y/n]: #Preserves the state of previously provisioned resources when an operation fails Disable rollback [y/N]: Save arguments to configuration file [Y/n]: SAM configuration file [samconfig.toml]: SAM configuration environment [default]: それでは、テストしましょう！ ここでは、Amazon EventBridge に 2 つのサンプルイベントを送信し、期待通りに動作することを確認します。AWS Health の通知を再現することはできないので、代わりに EventBridge ルールにマッチする EventBridge イベントを作成して、ワークフローをトリガーします。サンプルリポジトリには、ECS サービスとしてデプロイされたタスク用と、スタンドアロンタスク用の 2 つのイベントが用意されています。 $ aws events put-events --entries file://sample_service_event.json $ aws events put-events --entries file://sample_task_event.json Slack ワークスペースにて、テストイベントごとに 1 つ、合わせて 2 つの Slack 通知を確認できるはずです。 後片付け ウォークスルーで作成したリソースを削除するには、 sam delete コマンドで CloudFormation スタックを削除します。 まとめ この記事では、Fargate タスクのリタイアプロセスについて深堀りし、リタイア通知からタスクのリタイアまでの時間を制御したい場合に、タスクのリタイア待機時間を変更する方法を紹介しました。その後、Amazon EventBridge と AWS Lambda を使用してタスクのリタイア通知を捕捉する方法を紹介しました。Fargate タスクのリタイアの詳細については、 AWS Fargate ドキュメント を参照してください。

本ブログ記事は、KDDI株式会社 ソリューション事業本部 DX推進本部 スマートシティ推進室 PFデザイングループリーダー 中嶋優氏と、アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 新谷 が共同で執筆しました。本実証実験に関する詳細なレポートは こちら をご覧ください。 はじめに 住民に安心安全な暮らしを提供し、まちの持続的な価値向上に繋げるために、民間主導によるまちの賑わい創出、維持管理、防災などの実装を通じたエリアマネジメントが活発化しています。高度なまちづくり実現のために AWS クラウドを始めとしたテクノロジーを導入し、スマートシティの取り組みを加速する動きも国内外で行われています。一方で、エリアマネジメントに関わるステークホルダーは多く、安定的な財源確保も課題となりやすいことから、合意形成に時間を要することもあります。 KDDI株式会社（以下、KDDI）含む実施事業者（他：東日本旅客鉄道株式会社（以下、JR東日本）、東急不動産株式会社、株式会社日建設計）は、3D 都市モデルを活用した大規模誘導・避難シミュレーションによって防災計画の計画検証や合意形成をサポートする実証実験を行いました。その中で、KDDI は、国土交通省が主導する 3D 都市モデルの整備・活用・オープンデータ化プロジェクトである PLATEAU のデータを活用し、Amazon Elastic Compute Cloud (Amazon EC2) G4dn インスタンス上の Unreal Engine 4 で 1 万人を超える避難シミュレーションを実現しています。 また、Amazon QuickSight・Amazon AppStream 2.0 等のマネージドサービスを駆使して、関係者が簡単にシミュレーション結果を参照するための仕組みも構築しました。結果として、関係者との討議の中で、まちづくりや防災業務、議論の可視化に対して有用性を確認する事ができています。 本ブログでは、KDDI の寄稿により「防災エリアマネジメントDX」の取り組みを技術的な観点からご紹介します。 KDDI の防災エリアマネジメントDX の取り組み KDDI は、JR東日本が手掛ける「TAKANAWA GATEWAY CITY」の都市計画・まちづくりに参画し、「防災」を切り口にしたエリアマネジメント DX の実証実験を行いました。防災は潜在リスクが把握されにくいことから、重要性が認識される一方で、合意形成が困難かつ成果を実感しづらいという理由から取組が停滞しやすいといえます。そのため、 3D 都市モデルを活用した大規模誘導・避難シミュレーション環境を整備し、災害時の潜在リスクや避難誘導計画を 3 次元的に可視化することによって、防災計画の計画検証や合意形成をサポートすることを目標としました。 アーキテクチャ 本実証実験では 1 万人を超える大規模な人流シミュレーションを行う環境を構築しました。シミュレーション実行環境として、NVIDIA T4 GPU を搭載した Amazon EC2 の g4dn.4xlarge インスタンス上に Unreal Engine 4 を構築し、セキュアで高性能なリモートデスクトップ環境を NICE DCV で実現しています。AWS を活用することで、事前の厳密なサイジングをすることなくインスタンスタイプを変更しながら試行錯誤し、最適化できることが利点の一つでした。 また、多くの都市計画策定関係者と協議するために、シミュレーション結果を共有する仕組みが必要でした。本実証実験では、シミュレーション結果のログを QuickSight で可視化するとともに、AppStream 2.0 を活用してリプレイシステムを整備し、関係者が容易に結果を参照できる仕組みを構築しています。以下では、技術的なポイントをいくつかご紹介します。 大規模人流シミュレーションのための最適化 本実証実験では、3D 都市モデルを Unreal Engine に取り込み、シナリオ要件に合わせて属性毎に異なる歩行速度とサイズを設定したキャラクターを、1 万人規模でシミュレーションする必要がありました。しかし、当初はキャラクターの移動処理において、Unreal Engine のデフォルト実装では GameThread の処理がボトルネックとなりパフォーマンスが出ない状況にありました。そのため、Visual Studio を利用できる Microsoft Visual Studio AMI を採用し、Unreal Engine 自体の実装に一部手を入れています。 具体的には、移動処理を TaskGraphThread で実行しマルチスレッド化することで、タスク待ち状態で活用されていなかった CPU リソースを有効活用する追加実装を行いました。これによって、GameThread のボトルネックを解消し、フレームレートを改善することに成功しました。また、キャラクターもアニメーション処理を削減し軽量化することで更に負荷を軽減する対応も行っています。なお、Visual Studio は後述するリプレイ操作や、ログ・リプレイファイルの Amazon Simple Storage Service (Amazon S3) へのアップロードと AWS Glue ジョブ実行など Blueprint だけで実現できなかった部分の実装にも活用しました。 シミュレーション結果の分析と可視化 避難に要する時間を可視化し、また人の密集度から移動に時間がかかった要因を抽出できるように、シミュレーション結果の分析環境を整備しました。分析フローとして、まずキャラクターの毎秒の座標・移動開始時間・移動完了時間・属性情報などのログを Unreal Engine から Amazon S3 にアップロードします。そして、Amazon Athena で移動完了時間の集計を行うとともに、計測エリアの面積とキャラクター面積・到達人数に基づき、AWS Glue によって密集度を計算しています。これらの計算結果は、QuickSight によって、時系列に沿った密集度の推移グラフや、移動完了時間毎のゴールした人数グラフとして可視化しています。実証実験では、密集度と移動完了時間の閾値を超過した場合にリプレイ動画を確認し、移動時間が長くなった原因の考察や危険な場所の有無を確認するという検証を行っていましたが、このような分析環境も AWS のマネージドサービスを活用することで容易に構築し、開発工数を削減することができています。 移動経路上の密集度 ゴールエリアの密集度 移動完了時間の分布 Amazon AppStream 2.0 によるシミュレーションリプレイ環境の提供 各社の都市計画策定関係者が、シミュレーション結果を参照しながら協議できるようにする必要がありました。そのため、シミュレーション完了時に出力できる Unreal Engine のリプレイファイルを、Amazon S3 経由で AppStream 2.0 から再生して再現可能な環境を構築しています。グラフィックスを多用するシミュレーションのリプレイ環境も、AppStream 2.0 の グラフィック G4dn インスタンスによるクラウドレンダリングとストリーミングを駆使することで、容易に関係者が参照できるようになっています。Unreal Engine のクラウドレンダリングの仕組みである Pixel Streaming を活用するのに比べて、環境構成がシンプルになり構築の労力が小さいことと、ストリーミング配信用のインスタンス管理・運用面においても、AppStream 2.0 が容易だったため採用しました。 AppStream 2.0 上のリプレイ画面 今後に向けて 今回の実証実験を通じて、3D 都市モデルを活用した大規模人流シミュレーションが防災業務活用や議論の底上げに繋がるという一定の効果を観測することができました。KDDI は、今後も技術的改善を重ねてより大規模にシミュレーションを実現可能にしていきたいと考えており、 AWS SimSpace Weaver の活用も検討しています。また、防災以外にもユースケースを創出することでビジネス拡大に繋げていくことが今後の目標です。 まとめ 本ブログでは、KDDI株式会社による AWS を活用した大規模人流シミュレーション事例をご紹介しました。ご紹介した主要なサービスは以下のとおりです。 Amazon EC2 G4 インスタンス : 画像分類、オブジェクト検出、音声認識などの機械学習モデルをデプロイしたり、リモートグラフィックワークステーション、ゲームストリーミング、グラフィックレンダリングなど、グラフィックを多用するアプリケーション向けの、業界で最も費用対効果が高く用途の広い GPU インスタンスです。G4 インスタンスは、NVIDIA GPU (G4dn) または AMD GPU (G4ad) を選択して使用できます。 Amazon QuickSight : 非常に高速で使いやすいクラウド対応のビジネス分析サービスで、組織内のすべての従業員が可視化の構築、アドホック分析の実行、およびデータからいつでも、どのデバイス上でもビジネスインサイトを迅速に得ることを容易にします。 Amazon AppStream 2.0 : 安全性、信頼性、拡張性に優れたアプリケーションストリーミング、SaaS 変換、および仮想デスクトップのサービスです。Graphics Design、Graphics Pro、Graphics G4、Graphics G5 というインスタンスファミリーを活用することで、ユーザは GPU 負荷の高いアプリケーションに任意のコンピュータからいつでもアクセスすることができます。 著者 中嶋 優 KDDI株式会社 ソリューション事業本部 DX推進本部 スマートシティ推進室 PFデザイングループリーダー 新谷 歩生 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 エンタープライズ技術本部 通信・メディアグループ 通信ソリューション第三部 シニアソリューションアーキテクト

はじめに Amazon Elastic Container Service (Amazon ECS) &nbsp;でコンテナワークロードを簡単かつ素早くビルド可能にする、 ECS Blueprints &nbsp;for&nbsp; AWS Cloud Development Kit (AWS CDK) &nbsp;をご紹介いたします。ECS Blueprints は、Amazon ECS クラスター上でコンテナワークロードを設定しデプロイするのに役立つ、Infrastructure as Code (IaC) のオープンソースモジュールの集まりです。ECS Blueprints は、お客様が Amazon ECS への移行を開始する際だけでなく、既存のクラスターに Application Load Balancer&nbsp;(ALB) によるフロントエンドサービスなど特定のワークロードを構築する際にも使用できます。また、ECS Blueprints&nbsp;は各シナリオのベストプラクティスを示し、リファレンスアーキテクチャとソリューションパターンを提供します。ECS Blueprints&nbsp;は、特定シナリオのエンドツーエンドの要件に対応しているため、お客様は Amazon ECS ワークロードの構築をスピードアップすることができます。さらに、ECS Blueprints テンプレートをユースケースに合わせて簡単にカスタマイズすることも可能です。これについてはこの記事で詳しく説明します。 AWS CDK は、使い慣れたプログラミング言語を使用してクラウドインフラストラクチャをモデル化およびプロビジョニングするオープンソースのソフトウェア開発フレームワークです。そのため、開発者は TypeScript、Python、Java などの使い慣れた言語を使用して、インフラストラクチャのプロビジョニングとビジネスロジックの構築を同時に行うことができます。さらに、AWS CDK の組み込みコンポーネントは 1 つ以上の AWS リソースで構成される高レベルの抽象化であるため、お客様は AWS CDK コンストラクトによって定義されたパラメータのカスタム値を使用して、複数の環境を素早く設定しデプロイできます。 この記事では AWS CDK を使用した ECS Blueprints に焦点を当てていますが、Terraform を使用した ECS Blueprints も同じリポジトリにあり、Terraform でも同様の概念を実装しています。 モチベーション コンテナは、アプリケーションのパッケージングとデプロイのデファクトスタンダードです。コンテナにはアプリケーションの依存関係がすべて含まれており、開発者のラップトップから本番環境まで、あらゆるマシンで一貫して起動します。コンテナの移植性により、お客様はエンドツーエンドの自動化されたソフトウェアデリバリーパイプラインを構築でき、ソフトウェアを頻繁かつ迅速にリリースできます。しかし、多くの新規顧客にとって、これらのメリットを得るために必要な学習曲線とスキルは非常に厳しい場合があります。コンテナイメージの構築方法を学び、Amazon ECS などのコンテナオーケストレーションを理解し、デプロイアーティファクトを作成し、オブザーバビリティとセキュリティのための仕組みを作成し、継続的インテグレーション (CI) と継続的デプロイ (CD) パイプラインを設定する必要があります。Amazon ECS や AWS Fargate &nbsp;によって手間のかかる作業を大幅に省くことができますが、それでも新規ユーザーが高めるべきスキルは、かなり多岐にわたります。 ECS Blueprints によって、新規ユーザーがコンテナベースのモダナイゼーションによって得られるメリットを、数か月ではなく数時間で実現できるようにしたいと考えています。ブループリントは、新規ユーザーがすぐに始めることができ、実践を通じて学習できるようにすることを目的としています。ECS Blueprints では、ベストプラクティスと適切に設計されたアーキテクチャパターンを体系化し、CI/CD、オブザーバビリティ、セキュリティ、コスト効率に対応するエンドツーエンドのソリューションを提供することを目指しています。この投稿では、コンピューティングとしてサーバーレスコンテナエンジンである AWS Fargate を使用し、Infrastructure as Code として AWS CDK を使用する ECS Blueprints について詳しく説明します。 ECS Blueprints の構造理解 AWS CDK 開発のベストプラクティスの 1 つは、「コンストラクトによるモデリングとスタックによるデプロイ」です。つまり、複数の AWS リソースからアプリケーションの上位論理ユニットのコンストラクトを構築します。このベストプラクティスガイドラインに従い、 コンポーネントディレクトリ を複数のシナリオで再利用できるようにカスタムコンストラクトで構成しました。この記事の執筆時点では、 コンポーネントディレクトリ にはコアインフラストラクチャと CI/CD パイプラインの 2 つのコンストラクトがあります。 コアインフラストラクチャのコンストラクト は、Amazon VPC (Amazon Virtual Private Cloud)、Amazon ECS クラスター、プライベート DNS 名前空間などで構成されています。Amazon ECS への移行を開始するために必要な、基本的な AWS リソースの集まりです。 CI/CD&nbsp;のコンストラクト は、 AWS CodeBuild 、 Amazon Elastic Container Registry (Amazon ECR) 、 AWS CodePipeline 、および関連する AWS IAM ロールからなります。この 2 つのコンストラクトを各 ECS Blueprints&nbsp;テンプレートに埋め込む代わりに、カスタムコンストラクトにしました。この設計の利点は、お客様が繰り返し使用するソースコードを減らせることです。お客様はこのコンストラクトをプログラミング言語の関数として、複数の ECS Blueprints テンプレートに簡単に挿入できます。 図 1. AWS CDK のための ECS Blueprints の一部 コンポーネントディレクトリ と同じ階層の各ディレクトリには、Amazon ECS ワークロードの名前が付けられています。そして、そのディレクトリ配下の各テンプレートは、以下に示したものと同じ階層構造に従います。 └── &lt;workload name&gt; ├── lib │ ├── __init__.py │ ├── &lt;workload name&gt;_stack.py │ ├── &lt;workload name&gt;_stack_props.py ├── README.md ├── __init__.py ├── app.py ├── cdk.json ├── sample.env lib/&lt;workload name&gt;_stack.py – このブループリントアプリケーションのメインスタックのコンストラクトが定義されているファイル。 lib/&lt;workload name&gt;_stack_props.py – アプリケーションのメインスタックに必要な変数で構成されているファイル。 README.md –&nbsp;この ECS Blueprints&nbsp;の使用方法を説明するファイル。 __init__.py –&nbsp;ディレクトリを Python パッケージとして扱うために使用されるファイル。 app.py – この Amazon ECS アプリケーションを実行するためのエントリーポイント。 cdk.json –&nbsp;CDK コンストラクトツリーを生成するために、実行する必要がある実行可能な CDK を定義している AWS CDK の設定ファイル。 sample.env – この ECS&nbsp;Blueprints テンプレートの実行に必要な、変数のサンプルコレクション。 AWS CDK スタックはデプロイの単位であるため、スタックのスコープ内で定義されるすべての AWS リソースのライフサイクルは同じです。この特性に基づいて、各機能を異なるテンプレートに分割しました。 ウォークスルー このウォークスルーでは、ECS Blueprints テンプレートを使用して Amazon ECS クラスターに簡単なウェブアプリケーションをデプロイします。最も一般的なワークロードであるこのアプリケーションでは、エンドユーザーが アプリケーションロードバランサー のエンドポイント経由でサービスにアクセスできます。ALB を経由するトラフィックはフロントエンドサービスによって処理され、フロントエンドサービスはサービスディスカバリーを通じてバックエンドサービスと通信します。 図 2. AWS CDK を通じてデプロイされたフルスタックアプリケーションのアーキテクチャ 前提条件 ECS Blueprints&nbsp;で Amazon ECS ワークロードを簡単に設定できることを示すために、フルスタックアプリケーションのプロビジョニングに 2 つの ECS Blueprints テンプレートを使用します。このウォークスルーには、以下の準備が必要です。 AWS Command Line Interface (AWS CLI) version 2 AWS CDK Toolkit Python での AWS CDK の使用 Python ≥ 3.6+ Git ウォークスルーする場所で AWS 認証情報を設定します。始めに、 ECS Blueprints Github リポジトリ をクローンします。 git clone https://github.com/aws-ia/ecs-blueprints.git Step 1:&nbsp;コアインフラストラクチャとバックエンドサービスをデプロイ バックエンドサービスのブループリントは、次のステップでデプロイするフロントエンドアプリケーションのトラフィックを処理する Node.js バックエンド API をデプロイします。このバックエンドサービスには、 AWS Cloud Map &nbsp;に登録されたサービスディスカバリー名を持っています。この Amazon ECS クラスターで実行されている他のサービスは、バックエンドサービスのディスカバリー名を使用してバックエンドサービスにアクセスできます。 cd ecs-blueprints/cdk/examples/backend_service/ ご自身の環境に合わせて AWS アカウントと AWS リージョンの環境変数を設定します。この投稿では、例としてオレゴンリージョン (us-west-2) を使用します。次に、AWS CDK テンプレートで使用する .env ファイルを生成します。バックエンドサービスのデプロイ時に、.env&nbsp;ファイル内の変数が取得されます。 export AWS_ACCOUNT=$(aws sts get-caller-identity --query 'Account'&nbsp;--output text) export AWS_REGION=${AWS_REGION:=us-west-2} sed -e "s/&lt;ACCOUNT_NUMBER&gt;/$AWS_ACCOUNT/g"&nbsp;\ &nbsp;&nbsp;-e "s/&lt;REGION&gt;/$AWS_REGION/g"&nbsp;sample.env &gt; .env Python の仮想環境を作成して、Python のインストールと関連する pip パッケージをローカル環境から分離します。その後、必要なパッケージをインストールします。 # manually create a virtual environment: python3 -m venv .venv # activate your virtual environment: source .venv/bin/activate # install the required dependencies: python -m pip install -r ../../requirements.txt .env ファイル の各値を詳しく見てみましょう。 deploy_core_stack – VPC や Amazon ECS クラスターなどのコアインフラストラクチャを事前にプロビジョニングしていないため、コアインフラストラクチャとバックエンドサービスの両方をデプロイしました。そのため、この値を True に設定しています。 Essential Props – これには、AWS CDK スタックのデプロイ時に不可欠な要素である AWS アカウント ID&nbsp;と AWS リージョンが含まれます。 Core Stack Props – コアインフラストラクチャを構成するコンポーネントの名前を指定します。 Backend Service Props&nbsp;– コンテナイメージ URI、コンテナ名、コンテナポート、Amazon ECS タスクに割り当てられるリソース量など、バックエンドサービスの詳細情報を設定します。 ECS cluster Props と Service discovery Props&nbsp;– コアインフラストラクチャのプロビジョニング中にこれらの値は自動的に出力されるため、両方の prop 値をデフォルト設定のままにします。 初めて CDK を使用してインフラストラクチャを作成する場合は、CDK をブートストラップします。 cdk bootstrap aws://${AWS_ACCOUNT}/${AWS_REGION} バックエンドサービスのスタックをデプロイする前に、次の AWS CDK コマンドを使用してこのアプリケーションの AWS CDK スタックを調べてください。CoreInfraStack と BackendService という名前の 2 つのスタックが表示されます。 cdk ls 下記のコマンドを使用して AWS CDK スタックをデプロイします。 cdk deploy --all --require-approval never --outputs-file output.json Step 2:&nbsp;ロードバランサーとフロントエンドサービスをデプロイする フロントエンドサービスのテンプレートに移動します。このブループリントは、ウェブ向けの負荷分散された Amazon ECS サービスを作成します。 cd ../lb_service 再び、ご使用の環境に合わせて AWS アカウントと AWS リージョンの環境変数を設定します。AWS CDK テンプレートで使用する .env ファイル を生成します。フロントエンドサービスのデプロイ中に .env&nbsp;ファイル内の変数が取得されます。 export AWS_ACCOUNT=$(aws sts get-caller-identity --query 'Account'&nbsp;--output text) export AWS_REGION=us-west-2 sed -e "s/&lt;ACCOUNT_NUMBER&gt;/$AWS_ACCOUNT/g"&nbsp;\ &nbsp;&nbsp;-e "s/&lt;REGION&gt;/$AWS_REGION/g"&nbsp;sample.env &gt; .env ただし、バックエンドサービスをデプロイする場合とは異なり、一部の値は調整が必要です。まず、コアインフラストラクチャはすでにプロビジョニングされているため、その Amazon ECS クラスターをフロントエンドサービスに使用します。 deploy_core_stack の値を False に変更してください。次に、前のステップでプロビジョニングしたコアインフラストラクチャ情報を参照して、ECS タスク実行ロール ARN と名前空間の値を指定します。必要な情報は、バックエンドサービスのディレクトリ内の&nbsp; output.json &nbsp;ファイルから取得できます。 訳注：下記の {ECS_TASK_EXECUTION_ROLE_ARN} と {NAMESPACE_ARN} , {NAMESPACE_ID} &nbsp;を置き換えてください。 deploy_core_stack="False" # Essential Props account_number="${AWS_ACCOUNT}" aws_region="${AWS_REGION}" # Core Stack Props vpc_cidr="10.0.0.0/16" ecs_cluster_name="ecs-blueprint-infra" namespaces="default" enable_nat_gw="True" az_count="3" # Frontend Service Props backend_svc_endpoint="http://ecsdemo-backend.default.ecs-blueprint-infra.local:3000" container_image="public.ecr.aws/aws-containers/ecsdemo-frontend" container_name="ecsdemo-frontend" container_port="3000" task_cpu="256" task_memory="512" desired_count="3" service_name="ecsdemo-frontend" ## Enter the values below by referring to the backend_service/output.json # ECS cluster Props ecs_task_execution_role_arn="{ECS_TASK_EXECUTION_ROLE_ARN}" vpc_name="ecs-blueprint-infra-vpc" # Service discovery Props namespace_name="default.ecs-blueprint-infra.local" namespace_arn="{NAMESPACE_ARN}" namespace_id="{NAMESPACE_ID}" 下記のコマンドを使用して AWS CDK スタックをデプロイします。 cdk deploy FrontendService --require-approval never 2 つの ECS Blueprints&nbsp;テンプレートを使用して Amazon ECS クラスターを構築し、その上にフロントエンドサービスとバックエンドサービスをプロビジョニングしました。デプロイを確認するには、AWS CDK 出力情報の最後の部分に記載されているロードバランサーエンドポイントをウェブブラウザにコピーしてアクセスします。次のような画像が表示されます。 図 3. バックエンドとフロントエンドの CDK スタックをデプロイした結果 ECS Blueprints を好みに合わせてカスタマイズ 図 4. 1 つのワークロードディレクトリ内のファイル間の相関関係 ECS Blueprints が目的のワークロードに合わない可能性もあります。その場合は、ECS Blueprints&nbsp;をカスタマイズして、お客様のワークロードに合わせたテンプレートに簡単に変換できます。ブループリントテンプレートをカスタマイズするには、提供されている AWS CDK コードをより深く理解する必要があります。 前述のとおり、各 Amazon ECS ワークロードの設定ロジックは stack.py ファイルにあります。また、 stack_props.py ファイルに列挙されている変数は、 stack.py ファイル内の各リソースを設定する際のパラメータとして使用されます。つまり、このファイルはスタックのプロパティを定義するために使用されるインターフェースです。さらに、お客様はこれらのプロパティの値を .env ファイルで指定できます。そのため、お客様は必要なパラメータを変数に変換することで、1 つのテンプレートからパラメータの異なる複数のサービスを生成できます。たとえば、お客様が Amazon ECS サービスの自動スケーリングの設定にタスクの最大値と最小値を直接指定したい場合、それらを環境変数および状態変数として stack_props.py ファイルに抽出できます。最後のステップとして、これらの値を stack.py ファイルの環境変数に置き換えます。 加えて、各 Amazon ECS ワークロードシナリオはそれぞれ異なるディレクトリに配置され、独自のデプロイライフサイクルを有しています。お客様は、既存のディレクトリ構造を使用して、Amazon ECS ワークロードのロジックを含む ECS Blueprints テンプレートを簡単に作成できます。任意でお客様がテンプレートのロジックに少し変更を加えることで、同じ目標を達成できます。 クリーンアップ AWS CloudFormation コンソールか、フロントエンドサービスのテンプレートの場所で AWS CDK コマンドを使用することでスタックを削除できます。 cdk destroy フロントエンドサービスを削除したら、バックエンドサービスのテンプレートに移動し、AWS CDK コマンドをもう一度使用してください。これで、バックエンドサービスとコアインフラストラクチャが削除されます。 cd ../backend_service cdk destroy --all --force まとめ この投稿では、ECS Blueprints とは何か、そしてどのように使用するか、どのようにカスタマイズできるかを紹介しました。ECS Blueprints をお客様のワークロードに使用する方法を学んだばかりなので、今すぐ ECS Blueprints を始められます！ECS Blueprints の詳細については、 ECS Blueprints ワークショップ と 公式 GitHub リポジトリ をご覧ください。ECS Blueprints は無料で使用でき、お支払いいただくのはデプロイしたリソースの分だけです。 ECS Blueprints は、一般的な Amazon ECS ワークロードシナリオをカバーすることを目的としています。そのため、ECS Blueprints をどのように発展できるかについてのフィードバックをお待ちしています。フィードバックにご興味がおありでしたら、ECS Blueprints リポジトリへ&nbsp; GitHub Issue をオープン してください。 本記事は&nbsp; Accelerate Amazon ECS-based workloads with ECS Blueprints &nbsp;(2023 年 7 月 24 日公開) を翻訳したものです。翻訳は、ソリューションアーキテクトの吉田が担当しました。

この記事は 「 AWS Lambda for the containers developer 」（記事公開日： 2023 年 5 月 9 日）の翻訳記事です。 はじめに AWS 上でアプリケーションを構築する際、お客様が直面する一般的な決定事項の 1 つは、 AWS Lambda で構築するのか、あるいは Amazon Elastic Container Service ( Amazon ECS ) や Amazon Elastic Kubernetes Service ( Amazon EKS ) といったようなコンテナサービスで構築するのかということがあります。 この決定を下すには、コスト、スケーリング特性、開発者がハードウェアオプションをどの程度制御できるかなど、考慮すべき多くの要素があります。ファンクションモデルもサービスベースのモデルも、客観的にどちらが優れているということはありません。むしろ、アプリケーションや基盤となるプロダクトとの相性の問題です。しかし、この選択でわかりにくい側面の 1 つは、プログラミングモデルが AWS Lambda の関数中心のパラダイムと、Amazon ECS や Amazon EKS の従来のサービスベースのパラダイムとの違いです。 AWS Lambda と Amazon ECS または Amazon EKS のプログラミングモデルの違いについては、よく議論されます。しかし、プログラミングモデルとはどういう意味でしょうか？ プロダクトのプログラミングモデルには 2 つの側面があります。1 つ目は、呼び出し側がアプリケーションに対してリクエストを出す方法です。もう 1 つは、アプリケーション内のコードがサービスからリクエストを受け取り、対応するレスポンスを返す方法です。この記事では、前者について説明しますが、後者にも焦点を当てます。AWS Lambda アプリケーションの内部を確認し、AWS Lambda で実行されているアプリケーションが AWS Lambda サービスと相互作用してリクエストを受け取り、それにレスポンスする内部の仕組みを理解することを目指しています。 この記事の目的は 2 つあります。まず、AWS Lambda のプログラミングモデルを紐解き、「 Lambda マジック」が実際にはアプリケーションとサービスの間の単純なやりとりであることを示します。次に、従来のコンテナのバックグラウンドを持つユーザーにとって、AWS Lambda もそれほど変わらないことを示します。すべてのコンピュートプロダクトは、アプリケーションコードとサービスの間で何らかのやりとりをします。コンピュートプロダクト間でアプリケーションを移動させることは、実際には、プロダクトのプログラミングモデルに準拠するようにアプリケーションを（できれば小さく）変更することです。 ウォークスルー それでは、始めましょう！ ご存知のとおり、AWS Lambda はサーバー上で実行されます、また、ZIP パッケージまたは Open Container Initiative ( OCI ) パッケージのいずれかでアプリケーションコードを設定します。ZIP パッケージを使用して同じことを行うこともできますが (これについては最後に詳しく説明します)、この記事ではコンテナイメージを使用して AWS Lambda を設定します。ワークロードに関しては、最もシンプルなプログラミング言語の 1 つである bash スクリプトを使用してビルドします。コンテナで実行されているコードと AWS Lambda サービスのプログラミングモデルとの相互作用を実証するために、これらのサーバーにできるだけ近づきたいと考えています。 まず、次の簡単な Dockerfile を使用します。 FROM public.ecr.aws/amazonlinux/amazonlinux:2023 RUN yum install -y jq tar gzip git unzip RUN curl -Ls "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip" \ &amp;&amp; unzip awscliv2.zip \ &amp;&amp; ./aws/install ADD startup.sh /startup.sh ADD businesscode.sh /businesscode.sh ENTRYPOINT /startup.sh AWS Lambda を難解なものだと思ったことがあるなら、もう一度考えてみてください。これは標準の Dockerfile で、Amazon Linux 2023 イメージを指定した FROM で開始し、そこに一連のツール （ AWS Command Line Interface [ AWS CLI ]、tar、git など）をインストールします。AWS Lambda は、ラップトップ（または AWS Fargate ）で実行できるのと同じように、このコンテナイメージと startup.sh スクリプトを実行します。 AWS Lambda 上でコンテナを特別なものにする 3 つの側面があります。 コンテナの制約 コンテナを起動するもの startup.sh スクリプト （および businesscode.sh スクリプト）で実行する内容 これらを個別にみていきましょう。 コンテナの制約 コンテナが動くマシンまたは仮想マシンによって制約が決まります。ラップトップでコンテナを起動しても、自由に使える Graphics Processing Unit（GPU）はないでしょう。AWS Fargate を使用してコンテナを起動すると、特権を持つコンテナを実行できません。すべての実行環境には制約があります。 AWS Lambda 実行環境にも独自の制約があります。 実行期間は（意図的に）制限されています サイズはメモリパラメータで設定され、CPU容量は比例して割り当てられます コンテナは読み取り専用のルートファイルシステムで実行されます（ /tmp は書き込み可能な唯一のパスです） 特権を持つコンテナは実行できません コンテナで GPU は使用できません これらの制約の多くは、従来のコンテナ管理サービスやローカル実行に共通しています。実行期間の制約と読み取り専用ファイルシステムの制約は、この記事で最も関連性が高くなっており、また後で説明します。 コンテナを起動するもの このセクションでは、サービスのプログラミングモデルの最初の側面、つまり呼び出し側がアプリケーションを呼び出す方法について説明します。すべての環境には、コンテナの起動をオーケストレーションする独自の方法があります。ラップトップでコンテナを起動したい場合は、おそらく docker run か finch run を使用するでしょう。AWS Fargate でコンテナを起動したい場合は、おそらく runTask や createService などの Amazon ECS API を使用するでしょう。AWS Lambda でコアとなるのはイベント駆動型システムであり、すべて（上記のコンテナの起動を含む）はイベントによって行われます。AWS Lambda は、さまざまな AWS サービスの何百もの異なるイベントをサポートしています。典型的なイベントは、非同期アプリケーションの一部である Amazon SQS キュー内のメッセージです。ただし、イベントは、インタラクティブなウェブアプリケーションの一部としての AWS API Gateway （または AWS Elastic Load Balancing ） HTTP 呼び出しでもかまいません。いずれにせよ、イベントは AWS Lambda で処理できるようになります (このメカニズムについては後で詳しく説明します）。1 つの AWS Lambda コンテナは、一度に最大で 1 つのイベントを処理します。ただし、コンテナの存続期間中は多数のイベントを順番に処理する場合があります。 AWS Lambda のコンテナのオーケストレーションは、受信イベントに応答して大まかに次のフローに従います。 コンテナの初期化がされており、イベント実行するためにアイドル状態のコンテナがある場合、AWS Lambda はそのコンテナにイベントを割り当て、そのコンテナ上で実行します。 コンテナの初期化がされておらず、イベント実行するためのアイドル状態のコンテナがない場合、AWS Lambda は新しいコンテナを起動します。 AWS Lambda は、将来のイベントで新しいコンテナを起動する必要がないように、このコンテナを 1 回の実行で停止せずに、長くキープすることを選択するかもしれません。 複数のイベントが同時に発生した場合、AWS Lambda は、設定された関数またはアカウントの同時実行数とバースト制限まで、それぞれコンテナを並行して起動します。 startup.sh スクリプトで実行する内容 これまで、AWS Lambda コンテナの実行環境 （制約） と、この実行環境のライフサイクル （オーケストレーション） について説明してきました。次に、コンテナ内で実行されているコードが実際に何をするか （プログラミングモデル）について考えてみましょう。 皆さんは Lambda runtime APIs について聞いたことがあるかもしれません。これらの API について考える最も簡単な方法は、イベントを取得してイベントにレスポンスする方法をアプリケーションに提供するというものです。コンテナは、処理するイベントがあるかどうかを繰り返しチェックし、存在する場合は何らかを実行して、その作業の結果を AWS Lambda に通知する、長時間実行されるプロセスと考えてください。 この高レベルのメンタルモデルを念頭に置いて、上記のフローを実装する startup.sh スクリプトを作成します。この例でのビジネスニーズは AWS Lambda が Hugo で作成したウェブサイトの GitHub リポジトリをクローンし、それを JavaScript アーティファクトのセットに組み込み、その結果を Amazon Simple Storage Service ( Amazon S3 ) バケットにコピーすることです。整理しやすいように、ビジネスロジックは businesscode.sh というスクリプトに取り込んでいます。startup.sh スクリプトは businesscode.sh を呼び出し、AWS Lambda プログラミングモデルとビジネスロジックの間の架け橋として機能します。ビジネスロジックは AWS Lambda について何も知る必要はありません。 重要: このユースケース自体は重要ではありません。実際のコマンドやその機能よりも、フローとコードの実行方法に注目してください。 startup.sh は次のとおりです。 #!/bin/sh set -euo pipefail ############################################################### # The container initializes before processing the invocations # ############################################################### echo Installing the latest version of Hugo... cd /tmp export LATESTHUGOBINARYURL=$(curl -s https://api.github.com/repos/gohugoio/hugo/releases/latest | jq -r '.assets[].browser_download_url' | grep Linux-64bit.tar.gz | grep extended) export LATESTHUGOBINARYARTIFACT=${LATESTHUGOBINARYURL##*/} curl -LO $LATESTHUGOBINARYURL tar -zxvf $LATESTHUGOBINARYARTIFACT ./hugo version ############################################### # Processing the invocations in the container # ############################################### while true do # Create a temporary file HEADERS="$(mktemp)" # Get an event. The HTTP request will block until one is received EVENT_DATA=$(curl -sS -LD "$HEADERS" -X GET "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next") # Extract request ID by scraping response headers received above REQUEST_ID=$(grep -Fi Lambda-Runtime-Aws-Request-Id "$HEADERS" | tr -d '[:space:]' | cut -d: -f2) ############################ # Run my arbitrary program # ############################ /businesscode.sh ############################ # Send the response curl -X POST "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response" -d '{"statusCode": 200}' done businesscode.sh は次のとおりです。 #!/bin/sh set -euo pipefail rm -rf hugo-sample-site git clone https://github.com/${AWS_LAMBDA_FOR_THE_CONTAINERS_DEVELOPER_BLOG_GITHUB_USERNAME}/aws-lambda-for-the-containers-developer-blog cd aws-lambda-for-the-containers-developer-blog/hugo_web_site /tmp/hugo aws s3 cp ./public/ s3://${AWS_LAMBDA_FOR_THE_CONTAINERS_DEVELOPER_BLOG_BUCKET}/ --recursive startup.sh スクリプトは、コンテナの起動時にのみ実行されるセクションから始まります。スクリプトのこの部分 (init) が、AWS Lambda コンテナのコールドスタートを決定します。この例では、実行時に Hugo バイナリの最新バージョンをダウンロードします。このバイナリのセットアップを前述の Dockerfile に追加することもできますが、それではファイルの最新バージョンが必要になるたびにイメージを再構築する必要があります。ここでは、AWS Lambda がコンテナを起動するたびに初期化コードを実行するという利点を生かして、最新バージョンの Hugo を動的に導入しています。特定のユースケースによって、コードの一部を Dockerfile に配置するか、初期化フェーズ、またはビジネスロジックに含めるかが決まります。 /tmp フォルダーは Lambda コンテナ内の唯一の書き込み可能なフォルダーであるため、このフォルダー内で操作する必要があることに注意してください。このため、Dockerfile でいくつかのツールをインストールする方が簡単でした。 スクリプトの次のセクション（「Processing the invocations in the container」ラベル）では、コードが無限ループに入り、コンテナが存続している間、続きます。このコードは、処理するイベントがあるかどうかを常に（ローカルの AWS Lambda runtime API endpoint に対して curl を使用して）チェックします。そして、これこそが AWS Lambda のマジックです。各実行環境内でランタイム API エンドポイントを公開し、管理します。ポーリングされたエンドポイントの受信時にイベントを返し、待機中のイベントがない場合、AWS Lambda はイベントが到着するまで実行環境を一時停止します。各イベントを受信すると、コードはそのイベントを取得し、そのイベントでスクリプトの次の部分（「 Run my arbitrary program 」ラベル）を実行し続けます。これはスクリプトの AWS Lambda に依存しない部分であり、ここでビジネスロジック（businesscode.sh スクリプト）を実行します。この部分は AWS Lambda 実行タイムアウト（最大 15 分まで設定可能）の影響を受けます。つまり、「 Run my arbitrary program 」セクションの一部として実行されるコードは、設定されたタイムアウトを超えて実行することはできません。 ビジネスロジックが完了すると、スクリプトは HTTP POST を介して同じエンドポイントにメッセージを返し、イベント処理が完了したことを AWS Lambda サービスに通知します。コードが何かを返していれば、AWS Lambda は何を返しているかは気にしないことに注意してください。このスクリプトでは {“statusCode”: 200} を返します。これは、API ゲートウェイを使用してこの関数をトリガーしており、 API Gateway はそのコードが返されることを期待している ためです。代わりに 「hey I am done」 のようなテキストを返すこともできますし、AWS Lambda はそれで問題ありませんでした（ API Gateway ほどではありません）。 コンテナの存続期間を AWS Lambda タイムアウトと混同しないでください。前者は、コンテナが起動後もループを実行し続ける時間を定義します。この存続期間は AWS Lambda の「契約」には含まれていないため、開発者はコンテナがシャットダウンされるまでの存続するのか想定すべきではありません。AWS Lambda タイムアウトは確かに契約の一部であり、この記事の執筆時点（ 2023 年 5 月 9 日時点）では最大 15 分まで設定可能です。 ランタイム API からイベントを受信したときに、コンテナのコードがそのレスポンスをポストするまでに設定されたタイムアウトよりも長くかかった場合、リクエストはタイムアウトとして呼び出し元に返され、コンテナは再起動されます。 このスクリプトで注目すべきもう 1 つの点は、実際のイベント情報を格納するイベントのペイロードを無視していることです。つまり、関心があるのはイベントトリガーだけで、トリガーがもたらすものには関心がありません。 HEADERS を解析し、リクエスト ID を抽出し、ループの最後でそのリクエスト ID をイベントを処理した AWS Lambda サービスに通知します。より古典的なイベント駆動型アーキテクチャでは、ペイロードを解析し、それを使用してビジネスロジックがリクエストに対して何をするかを制御していたでしょう。 この図は、上記のコードのセクションを視覚的に表現したものです。 これまでの内容をまとめましょう 次は、この AWS Lambda をデプロイおよび実行したときに内部で何が起こるかを大まかに説明します。 上記の Dockerfile からコンテナイメージを構築し、そのイメージを使用して AWS Lambda 関数を作成します。次に、この AWS Lambda に API Gateway エンドポイントと Amazon SQS キューの 2 つのトリガーを設定します。この段階では、何も実行されておらず、コンテナも起動されていません。 では、ターミナルからのリクエスト (curl &lt;api gateway endpoint&gt;) で API Gateway エンドポイントにアクセスしましょう。API Gateway はその HTTP リクエストを AWS Lambda イベントに変換し、イベントに応答してコンテナを起動します。コンテナは初期化フェーズ（この例では Hugo バイナリを取得） を経ます。次に、イベントループに入り、AWS Lambda が保持しているイベントを取得し、コンテナが空くのを待ちます。コンテナは数秒かけてリポジトリをクローンし、サイトを構築し、そのコンテンツを Amazon S3 にコピーします。完了すると、コンテナは HTTP POST を介してコードの実行が終了したことを AWS Lambda ランタイムに通知します。AWS Lambda は API Gateway に同期的に通知し、ターミナルにはプロンプトが返されます（スクリプト内の HTTP POST のメッセージでは本文を返さないため、レスポンスはありません）。 このユースケースでは、Lambda を何かしらのビルドシステムとして使用しているため、このプロセスには約 30 秒かかることに注意してください。これは、従来の同期リクエスト / レスポンスのパターンでの AWS Lambda の使用方法とは異なる場合があります。もしそうなら、「ビジネスロジック」はおそらくもっと無駄になるでしょう。ミリ秒単位でレスポンスするウェブサービスを考えてみてください。繰り返しになりますが、このユースケースは、Lambda の仕組みの内部で何が起こるかを説明するためにのみ使用します。 この時点で、コンテナは次のイベントのためにランタイム API にコールバックし、ランタイムのレスポンスを待っています。これで、コンテナは別のイベントが発生するまで一時停止され、その間は料金を支払う必要はありません。ここでメッセージをキューに送信すると、AWS Lambda はアクティブでアイドル状態の実行環境があることを認識し、コンテナの一時停止を解除してイベントをそのコンテナにルーティングします。コンテナは、ランタイム API の呼び出しに対するレスポンスとしてイベントを受け取り、ビジネスロジックを実行して結果を返すという同じプロセスを経ます。 この場合、イベントのペイロードは API Gateway によって生成されたイベントとは異なりますが、このユースケースでは、コンテナに渡されたイベントを読み取ることすらしないため、気にしません。トリガーだけを気にし、イベントのコンテンツそのものは気にしません。 しばらくして、リクエストが受信されなくなると、AWS Lambda は上記のコンテナをシャットダウンし、関数の裏で実行されているコンテナはなくなります。この時点で、API Gateway エンドポイントに 100 件の同時リクエストを送信します。AWS Lambda は 100 個のリクエストを受信し、100 個のコンテナを同時起動し、それらのリクエストを処理します (つまり、すべて初期化を行います「コールドスタート」)。リクエストが処理され、サイトが 100 回構築およびコピーされると、100 個のコンテナは不特定の期間で実行され続け、実行中のループを介してより多くのイベントを取得できるようになります（ AWS Lambda が再び停止することを決定するまで）。 Lambda の外部でのコンテナイメージの実行 これを読んでいる方なら、この記事で使用してきた Dockerfile が実際に見られる従来の Dockerfile と何ら変わりないことにお気づきかもしれません。最大の特徴は、startup.sh スクリプトがコンテナを初期化する方法と、AWS Lambda API とのやり取りにあります （ループ内でのイベント取得と結果送信の両方）。この部分は、AWS Lambda プログラミングモデルの非常に特有なものです。とは言うものの、ビジネスロジック (businesscode.sh) がプログラミングモデル (startup.sh) から分離されるようにこれらのスクリプトを作成しました。このため、AWS Lambda の仕様をバイパスしてビジネスロジックを直接起動することで、同じコンテナイメージを使用して別の場所で実行するのが簡単になります。これを実現する簡単な方法は、次の Docker コマンドを使用してローカルで実行することです。 docker run -v /tmp:/tmp --rm --entrypoint /businesscode.sh &lt;container_image:tag&gt; エントリーポイントを微調整して businesscode.sh スクリプトを指定するだけで済みました。 勘のいい方であれば、ローカルフォルダをコンテナの /tmp フォルダにマッピングしていることに気づき、なぜなのか疑問に思っているかもしれません。初期化フェーズをバイパスしたため、コンテナイメージは起動時に Hugo バイナリをインストールしません。代わりに、ラップトップの /tmp にある既存のバイナリから動的に渡しています。実際のシナリオでは、Hugo バイナリをコンテナイメージにビルドするか、ダウンロードコードを startup.sh から分割して AWS Lambda コンテキスト外で実行できるようにすることができます。繰り返しますが、この例はデモンストレーションを目的としており、実際の世界への適用するかどうかはユースケースによって異なります。 ちょっと待ってください。これは私たちが知っていて愛用している AWS Lambda ではありません！ その通りです。約束どおり、今回は実行モデルとプログラミングモデルを組み合わせた AWS Lambda の低レベルの仕組みを紹介するツアーでした。AWS Lambda を知っている、またはすでに使用したことがある場合は、これらの詳細からは抽象化されているかと思います。興味深いのは、AWS Lambda がリリース時にこれらの抽象化の最高峰からスタートし、このブログ記事で説明したことを完全に可視化するための徐々にサポートを導入した経緯です。ここで説明した内容を、皆さんが知っていたり聞いたりする高レベルの抽象化とどのように一致させるのでしょうか。 この記事で説明した内容から、ご存知の AWS Lambda まで発展させていきましょう。 ほとんどの開発者は、ビジネスコードを書いている間、ループや HTTP の GET や POST を扱うことを望んでいません。ここで、Lambda でよく見かける抽象化や規則、つまり AWS Lambda Runtime Interface Client (RIC) の出番です。RIC はイベントをインターセプトするループを実装するユーティリティ（バイナリまたはライブラリ）で、特定のプログラミング言語向けに AWS が提供しています。これらのイベントをコードに渡す方法は、プログラム関数に渡されるオブジェクトを介して行われます。RIC は上記の HEADERS と BODY を取得します。イベントの内容と実行環境のコンテキストを解析し、それらをオブジェクトとして関数に渡します。つまり、コンテナは RIC をメインプログラムとして起動し、イベントごとに RIC はイベント情報を使って関数を呼び出します。この規則に従うと、開発者はエンドポイントを呼び出したり、HEADERS や BODY を解析したりしなくても、関数内で直接イベントを検索できます。 RIC が実装するロジックの一部である bash スクリプト（startup.sh）を効果的に組み込んでいます。この例では「関数」の規則を真似したくないことに注意してください。なぜなら、「これは bash で RIC を再実装する方法です」という側面よりも、「これは何らかの特徴を持つ通常のコンテナです」という側面を増やしたかったからです。これについては、 Lambda ドキュメントにあるチュートリアル （この記事のきっかけとなった） がまさにそのためのもので 、メインスクリプトにインポートする bash 関数を構築する方法を示しています！ AWS Lambda は Function as a Service (FaaS) ですが、AWS Lambda のコンテキストにおける関数の概念全体は、開発者がすっきりと使えるように抽象化したコンテナ内の ループと 2 つの curl 操作の上に構築した規約にすぎません。 RIC の話題に戻りますが、独自のコンテナイメージを構築したい場合は RIC スタンドアロン （選択された言語用）と、構築に使用できる AWS Lambda マネージドのベースイメージ （RIC などを含む）の両方を用意しています。何を選択するかにかかわらず、コンテナイメージを使用するときは、そのメンテナンスを行う必要があります。つまり、ファンクション用の最新のイメージをデプロイする必要があります。 別のメカニズムとして、より高いレベルの抽象化は、カスタムランタイムとビジネスロジックを ZIP ファイルとしてパッケージ化し、関数が実行されるオペレーティングシステムを AWS に管理させることです。 究極の抽象化とマネージドエクスペリエンスを実現するには、ビジネスロジックのみを ZIP ファイルとしてパッケージ化し、お客様に代わって AWS にランタイム全体の整理と管理を任せることができます。前に説明したように、これが AWS Lambda のスタート地点であり、スタックの柔軟性と制御性を高めるためには長いプロセスがありました。レイヤーのサポートを追加し始め、最終的にはコンテナイメージのサポートを追加しました。 長年にわたって、Lambda コミュニティは上記の Lambda プログラミングモデルをさらに抽象化してきました。そのような抽象化の 1 つが、顧客が従来のウェブアプリケーション Lambda を実行できるようにする Lambda Web Adapter です。この Web Adapter は、Lambda プログラミングモデルと、ポートでリッスンする従来のウェブアプリケーションフレームワークとの間のインターフェースとなるカスタムランタイムと捉えることができます。このモデルを使用することで、Lambda のイベント駆動型の性質が抽象化され、インフラストラクチャがプログラミングモデルから事実上切り離されます。 このプロトタイプをご自身でテストしてみてください 実際に試したいと思われる好奇心旺盛な人のために、このプロトタイプを再作成するのに必要なすべてのコードとセットアップ手順を含む GitHub リポジトリを作成しました。自分で試したい場合は、 このリンク にアクセスしてください。 まとめ この記事では、AWS Lambda をいつもとは異なる観点から説明しました。これまで使用した具体的な例とユースケースは従来のものではなく、実際の AWS Lambda シナリオに対応していない可能性もありますが、この記事が、お客様がサービスの内部動作について理解を深めるのに役立つことを願っています。また、AWS Lambda と従来のコンテナシステムの違いをさらに明確にしていただければ幸いです。違いを理解すると、最初に感じていたほど風変わりなものではありません。 翻訳はソリューションアーキテクトの多田が担当しました。原文は こちら です。

この投稿は、「 Application integration in utility smart metering using AWS 」を翻訳したものです。 はじめに 配電事業者は、情報および運用技術（IT/OT）アプリケーションを実装して、配電の商業活動と送配電網の運用・管理を行なっています。これらの IT/OT アプリケーションには、請求、カスタマーケア、スマートメータリング、高度配電管理システム（ADMS）、監視制御およびデータ収集（SCADA）、および停電管理システム（OMS）が含まれます。停電の特定と復旧、請求精算、顧客の加入・解約、メーターの交換、配電提供地域の需要予測などのビジネスプロセスを問題なく実行するには、電力会社はこれらのアプリケーション間でデータを統合する必要があります。その中でも、スマートメータリングシステムは、これらのプロセスに欠かせない主要なデータソースとなります。電力会社は、本格的なエンタープライズサービスバスを導入する代わりに、クラウドベースの統合サービスを活用できるようになりました。 このブログ記事では、スマートメーターシステムに関連するアプリケーション統合のユースケースとスマートメーターシステム（Advanced Metering Infrastructure、または単に AMI とも言います）とユーティリティ系のシステムを統合する場合に使用できる AWS サービスの概要を説明します。 このブログの想定読者は、従来のスマートメータリングソリューション (AMI 1.0) を導入していて、今後の選択肢のひとつとして AWS のクラウド基盤上で動作するスマートメータリングソリューションを検討、評価している配電事業者、または AWS にすでにシステムを実装しており、他のユーティリティシステムとの統合ポイントを拡張中の配電事業者を主として想定しています。さらにこの記事では、AWS のサーバーレスサービスと IoT サービスを活用する AMI 2.0 次世代スマートメータリングシステムに使用できるアーキテクチャについても説明します。 統合対象となるユーティリティのメータリング関連アプリケーション スマートメータリングの導入と管理を成功させるには、電力会社はメーターデバイス本体、メーターデータ収集ネットワーク、ヘッドエンドシステム（HES）を含むスマートメータリングの中核となる「エコシステム」を実装する必要があります。また、いくつかの既存のユーティリティアプリケーションと統合する必要があります。 Meter-to-Cash (検針から入金まで）プロセスの主な統合: メーターデータ管理システム（MDMS）— スマートメーターデータを処理できる既存のシステムでも、スマートメータリングエコシステムの一部としてインストールされた新しいシステムでもかまいません 託送収益管理（検針、請求、集金、接続管理）と顧客関係管理（CRM）を担う請求およびカスタマーケアシステム（託送CIS/CRM） その他のコア AMI システムとは異なるタイプの HES（実装されている場合） その他の統合対象: スマートメーターの大量導入と継続的なメンテナンスを管理するための作業指示（ワークオーダー）管理と現地作業従業員（モバイルフィールドフォース）管理アプリケーション 位置情報システム（ GIS ） ビジネスインテリジェンス（ BI ）ダッシュボード レガシー AMI 導入のメータリング関連の統合ユースケース スマートメータリングとユーティリティアプリケーションの統合に必要な AWS サービスを特定するには、以下のユースケースを参考にしてください。ユースケースは他にもあるかもしれませんが、最も一般的で適用可能な統合方法についての知見を得るには、まずはこれらで十分と考えます。 メーターデータ統合の主な利用例： 定期請求処理のための日次メーターデータ： MDMS との統合の主な使用例としては、スマートメーターの計量値を使用して消費者に請求するための「請求およびカスタマーケアシステム」との統合があげられます。MDMS は、消費者の請求日の設定に基づいて、該当日に請求が予定されているすべての消費者に対する API リクエストを送信します。MDMS は、リクエストを受けたすべての消費者に対する当該請求額決定の構成要素を請求およびカスタマーケアシステムに連携します。 請求およびカスタマーケアシステムは、Amazon API Gateway で設定された REST API の API リクエストを送信します。リクエストには、請求決定要素に紐づく消費者固有の識別番号またはメーター番号が含まれます（消費者は、毎月または隔月のサイクルに従って特定の日に請求されるものとします）。 Amazon API Gateway の API は、インテグレーションタイプが HTTP で MDMS API のエンドポイントとして設定されます。Amazon API Gateway には API のスロットリングレートを設定することもできます。これにより、請求およびカスタマーケアシステムから MDMS に送信される API リクエストの負荷をAmazon API Gateway で調整できます。 請求およびカスタマーケアからリクエストされた消費者リストから、MDMS は MDMS データベースから請求料金計算に必要な要素を抽出し、Amazon API Gateway に設定された API Gateway への API コールとして連携されます。Amazon API Gateway の API は、インテグレーションタイプが HTTP、エンドポイントが請求およびカスタマーケアシステム API として連携されます。MDMS は、Amazon API Gateway を介して請求料金計算に必要な要素を複数のバッチで請求およびカスタマーケアシステムに送信します。請求決定要素が複数のバッチで送信される理由は2つあります。(1) MDMSと請求およびカスタマーケアシステムへの負荷を最適化するために多数の消費者分を複数のバッチに分割すること、(2) MDMS データベースに最新の計量値がない場合、欠測している計量値は再試行によってMDMSによって取得され、この再試行により受信した計量値は請求およびカスタマーケアシステムに複数のバッチとして送信されます。 別の連携手法として、請求バッチ処理のユースケースの統合は、セキュアファイル転送プロトコル（SFTP）を介して交換されるファイルを介して行われることもあります。 SFTP を使用する AWS Transfer Family は、セキュリティポリシーに従って MDMS 用のユーザー認証情報を使用してサーバーを作成するように設定できます。MDMS は、SFTP を使用して AWS Transfer Family の指定されたディレクトリに、あらかじめ定義された命名規則に従って複数のファイル (各ファイルには複数のメーターの請求要素を含む) を送信できます。送信したファイルは Amazon Simple Storage Service (Amazon S3) または Amazon Elastic File System (Amazon EFS) に保存できます。請求システムは、指定された場所からファイルを読み取り、その読み取りを処理して請求を行うことができます。 図１：メーターデータの代表的な利用例。オンプレミスとAWSのハイブリッドシナリオが示されていますが、すべてのシステムをAWSベースにすることも可能 メーターデータからデータレイクへ： キロワット（KW）、キロボルトアンペアリアクティブ（KVAR：キロバール）、電圧などのさまざまなタイプの計量値と同様に、複数のパラメータ、イベント/アラームを含んだメーターデータを分析すると、電力会社が顧客と電力網の両方の運用に関して洞察を得るのに役立ちます。このメーターデータは、さまざまな種類の計量をさまざまな頻度で収集し、数か月または数年にわたって蓄積すると、ペタバイト単位のデータになります。このデータを効率的に分析するために、電力会社はこれらのデータをデータレイクに蓄積します。データレイクでは、機械学習のユースケースを含む高度な分析を迅速に実行できます。 詳細については、 Meter Data Analytics （MDA）に関するブログと、MDA ソリューションの迅速な構築と導入に役立つ MDA Reference Architecture と Quick Start を参照してください。 メーターデータ統合のその他の使用事例 オフサイクルトランザクションのオンデマンド計量： 新しい場所への転居などのオフサイクルトランザクションに対しては、請求およびカスタマーケアシステムはその処理をオンデマンド計量で対応します。消費者の入居済み申請が請求およびカスタマーケアシステムに記録されると、請求およびカスタマーケアシステムから MDMS に API リクエストが送信され、MDMS から HES へのAPIリクエストが開始され、スマートメーターからの計量が行われます。処理の応答は再び HES から MDMS へと戻り、さらに請求およびカスタマーケアシステムに戻ります。 請求およびカスタマーケアシステムは、 Amazon API Gateway で設定された REST API の API リクエストを送信します。Amazon API Gateway は、開発者があらゆる規模で API を簡単に作成、公開、保守、監視、保護できるようにする完全マネージド型サービスです。 Amazon API Gateway では、API はインテグレーションタイプが HTTP、エンドポイントが MDMS API として設定されています。Amazon API Gateway には API のスロットリングレートを設定することもできます。これにより、請求およびカスタマーケアシステムから MDMS に送信される API リクエストの負荷を Amazon API Gateway で調整できます。 MDMS はリクエストを HES に送信してオンデマンド計量を要求し、HES からの応答は MDMS に送り返され、次に請求およびカスタマーケアシステムに送られます。 図2: その他のメーターデータ統合の使用事例。オンプレミスと AWS のハイブリッドシナリオが示されていますが、すべてのシステムを AWS ベースにすることも可能 停電および復旧アラーム： スマートメーターからの停電および復旧アラームは、電力会社による停電箇所特定プロセスに役立ちます。停電および復旧アラームは、スマートメーターによって HES に送信され、次に HES から MDMS に送信されます。MDMS はこれらを OMS（停電管理システム：Outage Management System） に送信し、OMS はアラームをグリッドレベルで停電と結び付けて、停電している消費者を特定します。 スマートメーターがメーター番号とアラーム日時とともに停電アラームを HES に送信すると、HES はこれを MDMS に送信します。HES と MDMS のアラームの統合方法は、アプリケーションによって異なります。 MDMS はこの停止アラームを Amazon Simple Queue Service (Amazon SQS) に送信できます。Amazon SQS は、何百万ものメッセージを処理できるサーバーレスのキューイングサービスであり、負荷を処理するために独自にスケールアップおよびスケールダウンできます。 OMS は Amazon SQS キューからメッセージを取得し、電気が失われている消費者を特定するなどの発生イベントに合わせてメッセージを処理します。 上記ユースケースに記載されている統合方法は一例ですが、実際の統合方法は設計段階で最終決定します。HES が複数あったり、請求システムとカスタマーケアシステムが連携する可能性もあるため、システム同士のポイントツーポイント（一対一）統合の代わりに統合レイヤアプローチという手法により統合にかかる労力を最小限に抑えることが重要です。特に統合レイヤが AWS のフルマネージド・サービスを採用している場合、運用とメンテナンスに必要な労力も削減できます。導入時には、複数の送信元システムと送信先システムでサポートできる共通のデータフォーマット（必須パラメータとオプションパラメータを含む）を定義することも重要です。統合アーキテクチャを定義する際に考慮すべきベストプラクティスには、次のようなものがあります。 疎結合サービス ：疎結合は、コンポーネントの動作をそれに依存する他のコンポーネントから分離するのに役立ち、回復性（レジリエンシ）と俊敏性を高めます。キューイングシステム、ストリーミングシステム、ワークフロー、ロードバランサーなどの統合サービスは疎結合であり、要件に基づいて実装することができます。これらの統合サービスをすべて必要とするアーキテクチャもあれば、これらのサービスを 1 つか 2 つ必要とするアーキテクチャもあります。設計方針として、例えば、この例のように実装時には2 つの統合サービスのみに限定することで、実装にかかる全体的な労力と時間を削減することが可能です。 イベント駆動型アーキテクチャ（Event-driven architecture） ：イベント駆動型アーキテクチャは、イベントを使用して分離されたサービスを起動し、サービス間の通信を行います。これは、マイクロサービスで構築されたモダンアプリケーションでは一般的なアーキテクチャです。イベント駆動型アーキテクチャでは、イベントのポーリング、フィルタリング、ルーティングを行うコードを記述する必要はありません。代わりに、これらはイベントルーターによって処理され、イベントを自動的にフィルタリングしてプッシュします。 AWS Well-Architected Framework は、クラウドベースの実装のベストプラクティスを網羅しており、お客様と AWS パートナーがアーキテクチャを評価し、時間の経過とともに拡張可能な設計を実装するための一貫したアプローチを提供します。 AMI 2.0 向けの AWS ベースのサービス アドバンスト・メータリング・インフラストラクチャ（AMI）またはスマート・メータリングは、エッジデバイス、クラウド、通信、業務における領域で技術の進歩とともに、過去 20 年間で進化してきました。 AMI 2.0 と呼ばれる次世代のスマートメータリングシステムは、これらの進歩をベースにしています。新しいスマートメータリングを導入する際、アーキテクチャ上で検討、決定すべき重要な事項は、(1) ソリューションは回復性があり、数百万のエンドポイントまで自動的に拡張可能であること、(2) メータリングソリューションの保守と運用のオーバーヘッドが最小限に抑えられること、(3) メータリングおよびエネルギー関連の複数のアプリケーションをエッジ (メーター内またはメーターデバイスの後段) で管理および実行できるソリューションであることです。これにより、スマートメータリングソリューションを実行するために必要なインフラストラクチャの管理にかかる運用上のオーバーヘッドが削減され、メータリングの信頼性が向上し、エッジでの付加価値のあるメータリングサービスの実現が可能になります。これは、AWS のサーバーレスサービスと IoT サービスを使用することで実現できます。たとえば、AWS のサーバーレスサービスは自動的にスケールアップおよびスケールダウンされ、顧客によるインフラストラクチャのプロビジョニングは不要です。一方、AWS IoT サービスでは、自動診断、セキュリティパッチ、無線によるソフトウェア配布などの機能により、メータリング群の管理が大幅に簡単になります。 次の図は、AMI 2.0 アプリケーションとアプリケーション統合をサポートできる AWS サービスの概要を示しています。これをさらに強化して、顧客固有の要件に基づく他のユースケースにも対応できます。 図 3: AMI 2.0 向けの AWS サービス スマートメーターは、メーターデータ (メーターの定期計量、深夜のメーター計量、アラーム、イベント) を MQTT、HTTPS、WSS 経由の MQTT、LoRaWAN 経由で AWS IoT Core に送信できます。 AWS IoT Greengrass をスマートメーター (またはコンセントレータ) 上で利用して、異常検出やその他のアプリケーションなどを動作させて、エッジデバイスにインテリジェンスをもたらすことができます。 スマートメーターによって送信されたメーターデータは、AWS IoT Core によって受信されます。AWS IoT Core はサーバーレスサービスで、負荷に応じて自動的にスケールアップとスケールダウンが可能で、耐障害性があります。 AWS IoT Device Defender は、AWS IoT Core に接続されたデバイスを監査および監視するためのセキュリティレイヤをもたらします。IoT デバイス群のクラウド構成を評価し、ルールベースおよび ML ベースの検出機能によってデバイスのアクティビティを継続的に監視し、監査違反または異常な動作が特定されるとアラームを発動し、ビルトインされた緩和アクションで問題に迅速に対処できるようにします。 データが AWS IoT Core で受信されると、ルールとアクションを定義してデータをさらに処理できます。ルールとアクションは、上記のアーキテクチャに示されているように 1 つ以上でもかまいません。このアーキテクチャでカバーされているユースケースは次のとおりです。 AWS IoT Core で受信したメッセージはすべて Amazon S3 バケットに送信され、保存され、分析とレポート用のデータレイクが構築されます。 受信したメーターデータがアラーム (停電、低電圧など) の場合、ルールを適用してメッセージを Amazon SQS に送信できます。 AWS IoT Core で受信したすべてのメッセージは AWS Lambda に送信されます AWS IoT Core で受信したすべてのメッセージは AWS Lambda 関数に送信され、この関数は必要に応じてデータ加工処理を実行し (KWh 指示値に乗率を適用するなど)、加工されたデータを Amazon DynamoDB に保存します。最新のメーターデータは Amazon DynamoDB に短期間保存されるため、その他のユーティリティアプリケーションがこの最新データに迅速にアクセスすることができます。Amazon DynamoDB は、あらゆる規模で高性能アプリケーションを実行できるように設計された、フルマネージド型のサーバーレスのキーバリュー型 NoSQL データベースです。Amazon DynamoDB には、組み込みセキュリティ、継続的バックアップ、自動マルチリージョンレプリケーション、インメモリキャッシュ、データエクスポートツールが備わっています。 スマートメーターの警告アラームを含む準リアルタイムのメッセージを Amazon SQS に送信できます。連携するアプリケーションが異なる場合があるため、アラームの種類ごとに異なるキューを定義する可能性があります。あるいは、連携するアプリケーションに基づいてメッセージキューを１つに統合することもできます。たとえば、OMS が使用するすべてのアラーム（停止/ Last Gasp、復旧、L1 障害、L2 障害など）をすべて１つのキューに送信できます。 AWS IoT Core で受信したすべてのメッセージは、オブジェクトの形式で Amazon S3 バケットに送信されます。メーターデータは、データのタイプに基づいて別々のバケットに保存できます。たとえば、あるバケットにはすべての定期計量値が、別のバケットにはすべての深夜計量値が保存されます。Amazon S3 は、分析を生成するためのソースとなるデータレイクの基盤となります。 Amazon Athena を使用してデータレイク内のデータをクエリできます。データレイクは Amazon QuickSight のダッシュボードのデータソースになります。このデータレイクは、将来、AI/ML を使用した高度な分析を実行するためにさらに使用することができます。 スマートメーターから受信して永続レイヤに保存されたデータは、外部アプリケーションがさまざまな目的で必要とします。このデータを外部アプリケーションに提供する方法の 1 つは、REST API を使用することです。REST API は Amazon API Gateway で利用できるようになります。Amazon API Gateway には、インテグレーションタイプとして AWS Lambda 関数が指定できます。AWS Lambda 関数は Amazon DynamoDB（および必要に応じて Amazon S3）から適切なデータセットを取得し、その応答を Amazon API Gateway に返してさらに処理します。 まとめ スマートメータリングのクラウドベースの実装を検討している配電事業者は、スマートメータリングソリューションと他のユーティリティシステム間のデータ連携に AWS Application Integration サービスを選択できます。AWS Application Integration サービスには、公益事業者がプロビジョニングや管理を行う必要がなく、負荷に応じて自動的にスケールアップやスケールダウンを行うサーバーレスサービスが含まれます。サーバーレスサービスには耐障害性が組み込まれているため、特にスマートメータリングに関連する重要なユースケースでは、統合サービスの実行に必要な信頼性レベルが得られます。サーバーレスサービスは使用量に基づいて請求され、アイドル状態のリソースについては請求されないため、多くの場合、配電事業者はコストを節約できます。 AMI 2.0 の観点から見ると、配電事業者は、AWS IoT、Amazon S3、Amazon Athena、Amazon QuickSight などのサービスを使用してスマートメータリングソリューションを開発、強化、実装する時間を短縮できるというメリットがあります。エッジレイヤとアップストリームレイヤの両方で、AWS IoT サービスで利用できるビルトインの統合機能により、開発とテストに必要な時間を大幅に短縮できます。 ルールが呼び出されたときに何をすべきかを指定する AWS IoT rule actions には、Amazon DynamoDB、AWS Lambda、Amazon SQS などの他の AWS サービスのほか、抽出、変換、ロードサービスである Amazon Kinesis Data Firehose 、フルマネージドのメッセージングサービスである Amazon Simple Notification Service (Amazon SNS)、膨大な量の IoT データに対して高度な分析の実施、運用を簡単にできる完全マネージド型サービスである AWS IoT Analytics といったその他の AWS サービスとの事前構築済みの統合が含まれています。これらのサービスは、ユースケースに基づいて設定できます。さらに、AWS のサービスによって、スマートメータリングデータセットの上に負荷予測や高度な ML などの新しいユースケースを俊敏に実装できます。エッジ面では、AWS IoT Greengrass の使用はデバイスメーカー（スマートメーターまたはコンセントレーターメーカー） にとっても検討に値します。これは、AWS IoT Greengrass では、クラウドで作成、トレーニング、最適化されたモデルを使用して、デバイス上でローカルで ML 推論を簡単に実行できるためです。 スマートメータリング統合に関する AWS サポートの詳細については、この re: Invent セッション を視聴するか、 AWS Power &amp; Utilities のウェブサイト をご覧ください。 本ブログは、ソリューションアーキテクトの丹羽が翻訳しました。原文は こちら です。 AWS for Energyについて詳細は こちら をご覧ください。 タグ: AMI , AWS AMI , AWS IoT , MDMS Integration , OMS integration , smart meters , utilities &nbsp; Sainath Bandhakavi Sainath Bandhakavi は、アマゾンウェブサービスインディアの電力・公益事業および持続可能性担当主任ソリューションアーキテクトです。電力、公益事業、サステナビリティ分野の顧客、新興企業、AWS パートナーと協力して、クラウドの力を利用して AWS で業界ソリューションを構築し、最新化できるよう支援しています。Sainath は、ソリューションアーキテクト、戦略およびプロセスコンサルタントなど、さまざまな役割でこれらの分野のお客様と20年以上働いてきました。彼の最近の業務は、スマートメータリング、公共料金の請求とカスタマーケア、スマートシティソリューション、高度分析などでした。 Greg Thompson Greg Thompson は、電力・ユーティリティ業界の AWS IoT ワールドワイドビジネス開発リーダーです。電力・ユーティリティ業界セグメント向けのグローバル AWS IoT 戦略の策定と、グローバルセールスチームおよびパートナーとの共働を担当しています。Greg は、AWS やシュナイダーエレクトリック (Schneider Electric) などの企業で 20 年以上にわたり、公益事業、データセンター、スマートビルディング、自動車、その他の業界向けの SaaS、IoT、エンタープライズソリューションを開発およびリードしてきました。 Joseph Beer Joseph (Joe) Beer は、電力・ユーティリティ業界の AWS ワールドワイド・テクノロジー・リーダーであり、AWS における再利用可能な IT、OT、カスタマエンゲージメント、データ、資産管理ソリューションアーキテクチャの開発を指導しています。Joe は、AWS クラウドがお客様のデジタルトランスフォーメーション戦略を実現し、ビジネス目標の達成にどのように役立つかについて、お客様やパートナーにアドバイスしています。Joe は業界のベテランであり、国内外の複数の業界にわたるIT管理、ソリューションアーキテクチャと提供、コンサルティングの分野で30年以上のリーダーシップ経験があります。Joe は、Puget Sound Energy から AWS に入社しました。Puget Sound Energy では CTO 兼チーフアーキテクトを務め、従来の IT と 制御機器に対する OT の両方の戦略、アーキテクチャ、設計業務の指揮を担当していました。

9 月 13 日 (水) に開催される参加料無料のオンラインイベントである AWS End User Computing Innovation Day 2023 にぜひご参加ください。AWS は、 LinkedIn Live 、 Twitter 、 YouTube 、 Twitch を含む複数のプラットフォームでこのイベントを同時にストリーミングします。 オフィスへの復帰義務、自社運営のデータセンターから脱却して移行することを求める圧力、増大するセキュリティ上の懸念、社内の IT 専門知識の不足、経費管理に関する絶え間ない注意などによって形作られた複雑な状況に適応することは、従業員が仕事をするために必要なツールを提供する責任を負う IT チームに多くの課題をもたらします。 AWS End User Computing Innovation Day 2023 は、まさにこれらの課題を詳しく分析することを目的とした 1 日間の無料仮想イベントです。この変革の時代を乗り切るために、 AWS End User Computing (EUC) サービスをどのように活用できるかを詳しく掘り下げていきますので、ぜひご参加ください。リモートおよびハイブリッドのワークフォースの当面および将来の要件をサポートするための、驚くほどアジャイルかつ安全な基盤を構築する方法をご覧ください。 このイベントでは、AWS のシニアリーダーから直接話を聞くことができます。このイベントで予定されているハイライトをいくつかご紹介します。 基調講演 – AWS の End User Computing 部門 General Manager である Muneer Mirza による基調講演セッションから始まります。Muneer は、俊敏性を最大化し、変化へのシームレスな適応を促進するための一連の戦略的アプローチを検討します。 ブラウザベースのワークロードセキュリティ – Amazon WorkSpaces Web の General Manager である Brett Taylor が、セキュリティおよびコンプライアンス体制を強化できるように、Amazon WorkSpaces Web を利用してウェブベースのアプリケーションを保護する方法について説明します。 イベントページ で登録すると、カレンダーにイベントリマインダーを追加できます。 当日お会いできるのを楽しみにしています。 – Irshad 原文は こちら です。

2023 年 8 月に公開された AWS Black Belt オンラインセミナーの資料及び動画についてご案内させて頂きます。 動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画は「 AWS サービス別資料集 」に一覧がございます。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご覧ください。 Amazon CloudFront の レポート / モニタリング / ロギング編 Amazon CloudFront の レポート / モニタリング / ロギング編です。 Content Delivery Network (CDN) サービスである Amazon CloudFront の運用時に役に立つ レポート / モニタリング / ロギング機能をご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 基本的な AWS サービスについて理解されている⽅ Amazon CloudFront の概要を理解されている方 Amazon CloudFront を現在運用中の方 Amazon CloudFront の監視やロギングの仕組みについてご興味のある方 本 BlackBelt で学習できること 本セミナーを受講することで、Amazon CloudFront のレポート / モニタリング / ロギング機能を利用し、様々な種類のデータやメトリクス、ログを確認できることを学習できます。 スピーカー 長谷川純也 ソリューションアーキテクト Virtual Andon on AWS カスタマイズ可能でスケーラブルなウェブインターフェイス Andon システムを提供し、製造現場での異常イベントをモニタリングすることができる AWS ソリューション・ Virtual Andon on AWS について、AWS Black Belt Online Seminar で解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 製造現場での異常イベントのモニタリングに取り組まれている方 Virtual Andon on AWS をこれからご利用予定の方 Virtual Andon on AWS をすでにご利用の方で、より理解を深めたい技術者の方 本 BlackBelt で学習できること 製造現場での異常イベントをクラウド上でモニタリングする方法やシステム構成を学習することができます。 スピーカー 山田航司 ソリューションアーキテクト Amazon Connect と Amazon Pinpoint による効果的なマルチチャネルコミュニケーション Amazon Connect と Amazon Pinpoint を活用する事でアウトバウンド業務が抱える様々な課題を解決しつつ、顧客との効果的なマルチチャネルコミュニケーションを実現する事が可能です。 本セッションでは、このようなマルチチャネルコミュニケーションを実装するための技術的なポイントを具体的な設定方法、実装方法を交えながら詳しくご説明します。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon Connect の基本的な知識や操作経験をお持ちの技術者 Amazon Pinpoint の基本的な知識や操作経験をお持ちの技術者 電話やメールなど複数のチャネルを使い効果的な顧客アプローチを検討されている方 すでに電話やメールなどでアウトバウンド業務を行なっており、効率的な運用を検討したい方 本 BlackBelt で学習できること Amazon Connect と Amazon Pinpoint の連携方法 アウトバウンドの仕組みをサーバーレスに構築する方法 スピーカー 梅田裕義 Amazon Connect スペシャリスト ソリューションアーキテクト AWS Control Tower 基礎編 統制の効いたマルチアカウント環境を構築する際に AWS Control Tower は有力な選択肢です。AWS Black Belt Online Seminar AWS Control Tower 基礎編では、AWS Control Tower でどんなことが実現できるのか紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 マルチアカウント管理について興味のある方 AWS Control Tower に関心のある方 AWS Control Tower をご利用予定の方 本 BlackBelt で学習できること AWS Control Tower の概要 AWS Control Tower の主要機能 スピーカー 桂井俊朗 ソリューションアーキテクト AWS Control Tower 手順編 AWS Control Tower の有効化 AWS のベストプラクティスに沿ったマルチアカウント環境 (ランディングゾーン) を構築できる AWS Control Tower をセットアップする手順を解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 複数の AWS アカウントを管理されている方 AWS Control Tower を導入予定・検討中の方 AWS Control Tower におけるアカウントの登録手順を整理したい方 本 BlackBelt で学習できること AWS Control Tower ランディングゾーンがセットアップする内容 AWS Control Tower のスムーズな有効化手順 AWS Control Tower にメンバーアカウントを登録する手順 スピーカー 大西朔 クラウドサポートエンジニア AWS CDK の基本的なコンポーネントと機能 (Basic #2) AWS Cloud Development Kit (AWS CDK) の App や Construct, Context などの基本的なコンポーネントを紹介します。また CDK アプリの合成とデプロイの仕組みや、リソースの参照、AWS アカウント上のリソースのインポート、AWS CloudFormation テンプレートの活用についても解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 インフラ構築の手間や作業ミスにお悩みの方 インフラを含めたアプリ全体を素早くデプロイしたいエンジニア 言語を問わず、プログラミングの経験がある方 AWS CDK の仕組みを理解して、よりよいコードを書きたい方 本 BlackBelt で学習できること AWS CDK の仕組みや各コンポーネントの役割を理解して、よりよい CDK アプリのコードを記述することができるようになります。 スピーカー 高野賢司 ソリューションアーキテクト AWS CDK の開発を効率化する機能 (Basic #3) AWS Cloud Development Kit (AWS CDK) を使用してアプリを一緒にデプロイする方法や、複雑な設定を抽象化する方法、デプロイ中に任意の処理を実行する方法など、アプリ全体をコードで定義するのに必要なテクニックを紹介します。また、CDK におけるテストとバリデーション、CDK Pipelines、npm に関する tips も解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 インフラ構築の手間や作業ミスにお悩みの方 インフラを含めたアプリ全体を素早くデプロイしたいエンジニア 言語を問わず、プログラミングの経験がある方 AWS CDK の仕組みを理解して、よりよいコードを書きたい方 本 BlackBelt で学習できること AWS CDK でアプリ全体をコードで定義し、すばやくデプロイするために活用できるテクニックを理解できます。 スピーカー 高野賢司 ソリューションアーキテクト モダナイゼーションプロジェクト立ち上げに向けたポイント ここ数年でモダナイゼーションという言葉が浸透し、実際に取り組まれている事例が増えています。一方で、抽象的なために全容が把握しずらい、検討したが関係者の共通認識がはかれないまま進めた結果頓挫してしまった、どこから手をつければいいか分からない、といった声も聞くようになってきました。本セッションでは、モダナイゼーションプロジェクトの立ち上げに向けて、事前に検討・考慮すべきポイントについてお話します。 資料（ PDF ） | 動画（ YouTube ） 対象者 モダナイゼーションに取り組むうえで、企画フェーズでの検討内容に関心があるリーダー、責任者の方 システムのモダナイゼーションに取り組もうとしているが、その対象選定や方針策定のポイントを確認したい方 本 BlackBelt で学習できること 企画フェーズでの検討内容や、モダナイゼーションに取り組む上での対象選定や方針策定のポイント スピーカー 平岩梨果 ソリューションアーキテクト 今後の Black Belt オンラインセミナー また、現時点で予定されている今後の Black Belt オンラインセミナーについては以下の通りです。 公開月 タイトル 登壇予定者 2023-09 AWS Batch HPC スペシャリストソリューションアーキテクト 小林広志 2023-09 Amazon Managed Grafana ソリューションアーキテクト 大井友三 2023-09 Amazon Kinesis Video Streams 基礎編 ソリューションアーキテクト 宇佐美雅紀 2023-09 Amazon Kinesis Video Streams 応用編 IoT スペシャリストソリューションアーキテクト 三平悠磨 2023-09 AWS SimSpace Weaver コンセプト編 ソリューションアーキテクト 阿南麻里子 2023-09 Virtual Andon on AWS ソリューションアーキテクト 山田航司 2023-09 AWS Key Management Service セキュリティソリューションアーキテクト 平賀敬博 2023-09 AWS Secrets Manager ソリューションアーキテクト 押川令 2023-09 Amazon GameLift FleetIQ ソリューションアーキテクト 安藤怜央 2023-09 AWS Control Tower 機能紹介編 ソリューションアーキテクト 桂井俊朗 2023-10 AWS SAW – セルフサービスなトラブルシューティングと運用の自動化 入門編 クラウドサポートエンジニア 高橋尚久 2023-10 AWS SAW – セルフサービスなトラブルシューティングと運用の自動化 Amazon Elastic Container Service(Amazon ECS) 編 クラウドサポートエンジニア 古野俊広 2023-10 AWS FreeRTOS Kernel 編 ソリューションアーキテクト 山岡卓紀夫 2023-10 Amazon EC2 Auto Scaling スケーリングポリシー編 シニアソリューションアーキテクト EC2 フレキシブルコンピュートスペシャリスト 滝口開資 2023-10 アクセラレータ搭載インスタンスの選択肢 シニアソリューションアーキテクト 赤澤智信 2023-10 AWS ML アクセラレータ入門 Annapurna Labs 常世大史 2023-10 AWS Application Discovery Service の概要（AWS 移行準備シリーズ） マイグレーションパートナーソリューションアーキテクト 鈴木槙将 2023-10 Amazon CodeCatalyst Overview 編 ソリューションアーキテクト 三尾泰士 2023-10 AWS Budgets シニアテクニカルアカウントマネージャー 岡本迅人 2023-10 AWS Cost and Usage Reports シニアテクニカルアカウントマネージャー 石王　愛 &nbsp;

はじめに Amazon Simple Storage Service ( Amazon S3 )&nbsp; は、ライブ動画ストリーミングワークフローのベーシックなオリジンとして必要なスケーラビリティ、データの可用性、セキュリティ、パフォーマンス、整合性を提供するオプジェクトストレージサービスです。この記事では、 AWS Elemental Live と AWS Elemental MediaLive を使用して Amazon S3 で HLS 出力グループを生成する際の、設定および耐障害性に関するベストプラクティスを紹介します。Amazon S3 は、ライブ動画向けの低コストでベーシックなオリジンとして、 AWS Elemental MediaStore の代わりに利用できるようになりました。動画コンテンツを準備、保護、配信するうえで包括的な機能を必要とするライブストリーミングのワークフローについては、 AWS Elemental MediaPackage を参照してください。 ライブオリジンのアーキテクチャ 冗長なライブストリーミングアーキテクチャは、同一出力を持つ2つのメディア処理パイプラインを提供します。こちらの例では、 MediaLive Standard チャンネル が Redundant HLS manifests 機能を使用して、2 つの異なる Amazon S3 バケットのパスに HLS 出力を生成します。一方、MediaLive の Single Pipeline クラスでは、出力先が 1 つしかないため、中断が入ると視聴体験に影響が生じます。 どちらのアーキテクチャでも、マニフェストやセグメントの更新に失敗すると、ライブストリームが「古い」状態になり、プレーヤーはオリジンから 200 HTTP のコードレスポンスを受信しますが、通常は動画/音声の最後の数セグメントを再生し、その後停止します。この記事では、このような古いバリアントマニフェストを検出して無効にする方法について紹介します。- 404 HTTP エラーコードを下流の Amazon CloudFront コンテンツデリバリーネットワーク （CDN） とビデオプレーヤーに強制的に送信することで、HL S仕様に記述されている通り、冗長フェイルオーバーがトリガーされます。 Amazon S3 をオリジンストレージとして選択し、上の図が示すように下流の CDN とプレーヤーが冗長マニフェストを処理できるようにするためには、次の基準を考慮する必要があります。 パフォーマンス オーバーザトップ（OTT）ストリーミングに使用されるアダプティブビットレート （ABR） メディアは、通常、動画/音声メディアを含む連続的に命名された一連のファイルセグメントをベースとしています。 Amazon S3 のパフォーマンス最適化 に関するベストプラクティスでは、Amazon S3 が高いリクエストレートに自動的にスケールされ、パーティション化された プレフィックス ごとに少なくとも毎秒 3,500 回以上の PUT/COPY/POST/DELETE リクエストまたは 5,500 回以上の GET/HEAD リクエストを達成する方法を概説しています。 ABR ワークフローでは、各ライブチャンネル形式および関連する品質バリアントの区切り文字としてスラッシュ (/) を使用することで、このプレフィックスが付与されます。MediaLiveの出力パスの構文は、このプレフィックスを提供する ドキュメント に概説されています。 プレイリストやメディアセグメントサイズのオブジェクトに対する PUT/GET リクエストのレイテンシー測定結果の p99.9 で、Amazon S3 のパフォーマンスは AWS Elemental MediaStore のパフォーマンスと比べて機能的に全く同じです。 整合性 Amazon S3 は、すべての AWS リージョンの Amazon S3 バケットのオブジェクトの PUT/DELETE リクエストに対して、強力な書き込み後の読み取り整合性を提供します。この動作は、新しいオブジェクトの書き込みだけでなく、既存のオブジェクトを上書きする PUT リクエスト、そして DELETE リクエストにも適用されます。詳細については、 Amazon S3 data consistency model を参照してください。 新しいオブジェクトの書き込みまたは既存オブジェクトの上書きが成功すると、それ以降の読み取りリクエストには直ちに最新バージョンのオブジェクトが提供されます。また、Amazon S3 はリスト操作でも強力な整合性を提供するため、書き込み後すぐに、すべての変更が反映された状態でバケット内のオブジェクトの一覧を取得できます。マニフェストやセグメントをポストするエンコーダーの書き込みが失敗した場合、使用可能なセグメントが中断されないように再試行の実施を設定する必要があります。 耐障害性 冗長なライブエンコーディングパイプラインの出力は、異なるプレフィックスを使って 1 つの Amazon S3 バケットに、あるいは 2 つの個別の Amazon S3 バケットに送ることが可能です。冗長マニフェスト機能が有効になっている場合、各パイプラインのメインプレイリストは、自身の子マニフェストともう一方のパイプラインの子マニフェストの両方を参照します。パイプラインに問題があると、そのパイプラインの子マニフェストにも問題が生じます。その場合、下流のプレーヤーはメインマニフェストを再度参照して、もう一方のパイプラインの子マニフェストを見つけることができます。 セキュリティ Amazon S3 を使うとお客様は、暗号化機能とアクセス管理ツールを活用して、データを保存し、不正アクセスから保護することができます。Amazon S3 は、PCI-DSS、HIPAA/HITECH、FedRAMP、EU Data Protection Directive、FISMA などに対応するコンプライアンスプログラムを整備しており、お客様が規制要件を満たすお手伝いをします。AWS では更に、Amazon S3 リソースへのアクセス要求を監視するための多数の監査機能もサポートしています。 メディア配信コンテンツのセキュリティは、ライブエンコーダーでの暗号化、および エッジでの安全なメディア配信を AWS で実現するソリューション を使用したアクセスのトークン化により提供されます。ただし、完全な デジタル著作権管理 (DRM) を行うには、AWS Elemental MediaPackage などの他サービスを使用する必要があります。 古いマニフェストの無効化 エンコーダーがメディアプレイリストへの更新内容のアップロードに失敗したとき、プレイリストが古いと見なされた時点でこのオブジェクトに 404 エラーを返させることが望ましい場合がよくあります。古いプレイリストには、ライブエッジよりも過去のセグメントしか含まれていないため、別のバリアントプレイリストへの再生切り替えが必要になる場合があります。404 エラーが返されることでクライアントの再生デバイスは、古いプレイリストのまま行き詰まるのではなく、再生を続行すべく切り替えの判断を下すことができます。 このリファレンス SAM は、デプロイされると、指定された Amazon S3 バケットにアップロードされたプレイリストファイルをすべて監視し、古いプレイリストが検出された場合は削除します ( https://github.com/aws-samples/amazon-cloudfront-s3-hls-invalidator )。 チェックする必要があるのは、エンドリスト、つまり HLS の #EXT-X-ENDLIST タグがないバリアントプレイリストのみです。マスターのマルチバリアントプレイリストは通常、配信開始時にライブエンコーダーからポストされるだけで、その後は更新されないため、Amazon S3 バケットに残しておく必要があります。 ライブエンコーダーでは、チャンネルが再起動した場合にセグメントが互いをオーバーライドするのを防ぐのと、CloudFront に異なるキャッシュキーを割り当てるために、セグメント名にはタイムスタンプを追加することが推奨されます。MediaLive の使用については Identifiers for variable data （変数データの識別子）を使用した segmentModifier の設計 を参照してください。 料金 ほとんどの AWS サービスと同様に、 Amazon S3 や AWS Lambda には最低料金の設定はありません。実際に使用した分だけお支払いいただきます。ライブストリーミングのアプリケーションで考慮すべきコストの要素は、ストレージ、リクエスト、データ転送、Lambda 実行時間です。Amazon S3 の料金については こちら 、AWS Lambda については こちら より詳細を確認してください。 まとめ Amazon S3 を使用した AWS 上でのライブストリーミング をセットアップするために利用できるリファレンスアーキテクチャが利用可能です。そしてこの記事では、古いマニフェストを無効化することで、耐障害性を最適化するためのベストプラクティスをいくつか紹介しています。更なる背景情報については、 AWS re:Invent 2022 – Deep dive on Amazon S3 を参照してください。 参考リンク AWS Media Services AWS Media &amp; Entertainment Blog　(日本語) AWS Media &amp; Entertainment Blog　(英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 翻訳は BD 山口、SA 石井が担当しました。原文は こちら をご覧ください。

はじめに お客様は 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=&gt;create( 'ZFINANCE' ). DATA(gv_bucket) = go_session-&gt;resolve_lresource( pv_lres ). DATA(go_s3) = /aws1/cl_s3_factory=&gt;create( go_session ). TRY. DATA(lo_output) = go_s3-&gt;listobjectsv2( iv_bucket = CONV string( gv_bucket ) iv_maxkeys = 100 ). LOOP AT lo_output-&gt;get_contents( ) INTO DATA(lo_object). DATA lv_mdate TYPE datum. CONVERT TIME STAMP lo_object-&gt;get_lastmodified( ) TIME ZONE 'UTC' INTO DATE lv_mdate. WRITE: / CONV text30( lo_object-&gt;get_key( ) ), lv_mdate, lo_object-&gt;get_size( ). ENDLOOP. CATCH /aws1/cx_rt_generic INTO DATA(lo_ex). DATA(lv_msg) = lo_ex-&gt;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 &amp; 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年のエンタープライズソフトウェア開発経験があります。クリスはカリフォルニア州サクラメントに住んでおり、ガーデニング、航空宇宙、そして世界中を旅することを楽しんでいます。 翻訳はソリューションアーキテクトの小川翔が担当しました。原文は こちら です。