11月30日、 Amazon SageMaker Studio のエクスペリエンスが改善されたことをお知らせします。 新しい SageMaker Studio の Web ベースのインターフェイスは読み込みが速くなり、IDE の種類に関係なく、お好みの統合開発環境 (IDE) や SageMaker リソースやツールに一貫してアクセスできます。JupyterLab と RStudio に加えて、SageMaker Studio には Code-OSS (Visual Studio コードオープンソース) をベースにしたフルマネージド型のコードエディターが含まれるようになりました。 コードエディターと JupyterLab はどちらも、柔軟なワークスペースを使用して起動できます。スペースを使用すると、IDE のコンピューティングとストレージを必要に応じてスケールアップまたはスケールダウンしたり、ランタイム環境をカスタマイズしたり、いつでもどこからでもコーディングを一時停止して再開したりできます。このようなスペースを複数スピンアップし、それぞれがコンピューティング、ストレージ、ランタイムの異なる組み合わせで構成できます。 また、SageMaker Studio には、個人ユーザーと企業管理者の両方が数分で使い始めることができるように、オンボーディングと管理機能が合理化されています。これらのハイライトのいくつかを簡単に紹介しましょう。 SageMaker Studio の新しいウェブベースのインターフェイス 新しい SageMaker Studio の Web ベースのインターフェイスは、お好みの IDE を起動したり、SageMaker ツールにアクセスしてモデルを構築、トレーニング、チューニング、デプロイしたりするためのコマンドセンターとして機能します。SageMaker Studio で SageMaker のトレーニングジョブとエンドポイントを表示したり、 SageMaker JumpStart を介して基盤モデル (FM) にアクセスしたりできるようになりました。また、SageMaker Studio を手動でアップグレードする必要もなくなりました。 Code-OSS (Visual Studio コードオープンソース) に基づく新しいコードエディター データサイエンティストまたは機械学習 (ML) の実践者は、SageMaker Studio にサインインして、ブラウザから直接コードエディターを起動できるようになりました。コードエディターを使用すると、 Open VSX レジストリから何千もの VS Code 互換の拡張機能にアクセスでき、AWS でアプリケーションを開発およびデプロイするための事前設定された AWS toolkit for Visual Studio Code にもアクセスできます。また、 Amazon CodeWhisperer と Amazon CodeGuru が提供する人工知能 (AI) 搭載のコーディングコンパニオンおよびセキュリティスキャンツールを使用することもできます。 コードエディターと JupyterLab を柔軟なワークスペースで起動 スペースを作成するユーザーのみがアクセスできるプライベートスペースを使用して、コードエディターと JupyterLab の両方を起動できます。この柔軟なワークスペースは、より高速で効率的なコーディング環境を提供するように設計されています。 スペースには、一般的な ML フレームワークと Python パッケージを含む SageMaker ディストリビューションがあらかじめ設定されています。AI 搭載のコーディングコンパニオンとセキュリティツールを使用すると、コードの生成、デバッグ、説明、リファクタリングをすばやく行うことができます。 さらに、SageMaker Studio ではコラボレーションエクスペリエンスが向上しています。ビルトインの Git 統合を使用してコードの共有とバージョン管理を行ったり、 Amazon EFS を使用して独自の共有ファイルストレージを持ち込んだりして、さまざまなユーザーやチーム間で共同ファイルシステムにアクセスできます。 ユーザーのオンボーディングと管理の効率化 再設計されたセットアップとオンボーディングのワークフローにより、SageMaker Studio ドメインを数分でセットアップできるようになりました。 個人ユーザーは、ドメインや AWS IAM ロールについて学ぶことなく、ワンクリックでデフォルトのプリセットを使用して SageMaker Studio を起動できるようになりました。 企業管理者は、手順を追って説明することで、適切な認証方法の選択、サードパーティの ID プロバイダーへの接続、ネットワークとセキュリティ構成の統合、きめ細かなアクセスポリシーの設定、SageMaker Studio で有効にする適切なアプリケーションの選択などに役立ちます。また、設定はいつでも更新できます。 はじめに、 SageMaker コンソールに移動し 、[ 単一ユーザー向けにセットアップ] または [ 組織向けにセットアップ ] を選択します。 シングルユーザーセットアップでは、デフォルトのプリセットを使用して SageMaker Studio ドメインのデプロイが開始され、数分以内に準備が整います。組織向けのセットアップでは、構成を段階的に説明します。ただし、従来の SageMaker Studio エクスペリエンスで作業を続けるか、新しいエクスペリエンスの探索を開始するかを選択できることに注意してください。 今すぐご利用いただけます Amazon SageMaker Studio の新しいエクスペリエンスは、SageMaker Studio が利用可能なすべての AWS リージョンで本日ご利用いただけます。本日より、新しい SageMaker Studio ドメインはデフォルトで新しい Web ベースのインターフェースになります。既存のセットアップがあり、新しいエクスペリエンスを使い始めたい場合は、SageMaker デベロッパーガイドで既存のドメインを移行する方法を確認してください。 ぜひお試しいただき、ご意見をお聞かせください。 フィードバックは、 AWS re:Post for Amazon SageMaker Studio にご送信いただくか、または通常の AWS の担当者を通じてお寄せください。 Amazon SageMaker Studio で、ML プロジェクトの構築を今すぐ始めましょう! –  Antje 原文は こちら です。

はじめに AWS IoT SiteWise アプリケーションをスケーリングして本番環境に移行する際には、開発環境と QA 環境を本番環境から分離する一般的な CI/CD を採用することを検討します。この分離により、デプロイパイプラインを通じてこれらのアプリケーションのデプロイを自動化できます。また、共通のアセットモデルや階層を持つ複数の事業部門や産業拠点があり、それらを組織全体で共有して再利用したい場合もあります。このような場合、顧客は通常、開発環境と本番環境間あるいは異なる事業部門間において、別々の環境に異なる AWS アカウントを持っています。次の図は、開発環境が QA 環境や本番環境から切り離されている例を示しています。 AWS IoT SiteWise のリソースを環境間で複製できるようにするために、 AWS IoT SiteWise ツール を作成しました。これは AWS IoT SiteWise のアセットモデル、アセット 、 AWS IoT SiteWise モニターダッシュボード を AWS CloudFormation テンプレート にエクスポートできるユーティリティセットです。エクスポートされたテンプレートを使用して、リソースを別の AWS 環境に再作成できます。このブログでは、AWS IoT SiteWise ツールを使用してモデルをエクスポートするサンプルの手順と、CI/CD パイプラインでエクスポートと複製のプロセスを自動化するためのサンプルアーキテクチャを紹介します。 アセットモデルエクスポートの概要 AWS IoT SiteWise ツールリポジトリのユーティリティは、特定のユースケースに必要なリソースのみを複製する柔軟性を提供します。 AWS IoT SiteWise アセットモデルのみをエクスポートするか、対応するアセットと AWS IoT SiteWise モニターダッシュボードもエクスポートするかを選択できます。 エクスポートツールは、コマンドラインから手動で使用できます (例: アセットモデルを別の環境に 1 回限りエクスポートする場合など) 。また、CI/CD デプロイシナリオの自動化パイプラインに統合することもできます。 このユーティリティは、同じアカウント内のマルチリージョンデプロイの AWS IoT SiteWise リソースをコピーするためにも使用できます。 AWS IoT SiteWise ツールリポジトリには、各ユーティリティの使用方法が詳細にドキュメント化されていますが、ツールの基本的なデモンストレーションとして、以下のように CNC マシン と 生産ライン の 2 つのアセットモデルを作成しました。 各モデルには、プロパティと 2 つのモデル間の階層関係が含まれています。 簡単にするために、モデルのみをエクスポートします。AWS IoT SiteWise エクスポートツールを使用して、オプションでエクスポートするリージョンを指定し、他のフラグを付けずにコマンドを実行します (アセットもモデルとともにエクスポートする場合は、単純に -a、—assets フラグを追加します)。 コマンドの出力は次のようになります。 コマンドが成功すると、CloudFormation テンプレートがローカルディレクトリ内の cfnexport というフォルダに保存されます。 例の場合、CloudFormation は次のようになります: { "AWSTemplateFormatVersion": "2010-09-09", "Description": "SiteWise Export", "Resources": { "CNCMachineResource": { "Type": "AWS::IoTSiteWise::AssetModel", "Properties": { "AssetModelName": "CNC Machine", "AssetModelProperties": [ { "Name": "SpindleSpeed", "DataType": "DOUBLE", "Unit": "RPM", "Type": { "TypeName": "Measurement" }, "LogicalId": "SpindleSpeed9f2e03dd" } ], "AssetModelHierarchies": [] } }, "ProductionLineResource": { "Type": "AWS::IoTSiteWise::AssetModel", "Properties": { "AssetModelName": "Production Line", "AssetModelProperties": [ { "Name": "Location", "DataType": "STRING", "Type": { "TypeName": "Attribute", "Attribute": {} }, "LogicalId": "Locationafc85231" } ], "AssetModelHierarchies": [ { "Name": "CNC Machines", "ChildAssetModelId": { "Ref": "CNCMachineResource" }, "LogicalId": "CNCMachines" } ] } } } } JSON この CloudFormation テンプレートを別のリージョンまたは別の AWS アカウントで展開して、上記で定義したのと同じアセットモデルを作成できます。 以上で、エクスポートユーティリティの仕組みを理解できました。次のセクションでは、ユーティリティを CI/CD パイプラインに統合するアーキテクチャの例を紹介します。 CI/CD アーキテクチャ例 このサンプルアーキテクチャでは、CloudFormation と AWS SDK を使用して AWS サービスをデプロイできる既存の CI/CD パイプラインがあることを前提としています。 ビルド アーキテクチャの構築段階では、CI/CD パイプラインがソース環境で Step Functions ワークフローを開始します。このワークフローでは、アセットモデル、アセット、ダッシュボードなどのリソースタイプごとに 1 つずつ、合計 3 つの Lambda 関数が実行されます。Lambda 関数を並行して実行し、エクスポートユーティリティを使用して AWS IoT SiteWise サービス API にクエリを実行し、複製するリソースに対応する CloudFormation テンプレートを生成できます。その後、Lambda 関数は生成されたファイルを Amazon S3 バケットに保存し、パイプラインのデプロイ段階で使用できるようにします。S3 バケットでは、すべての AWS 環境で共通の 共有バケット を使用するか、S3 レプリケーションを使用して 各環境ごとのバケット間 でファイルを自動的にコピーできます。 デプロイ デプロイ段階では、AWS IoT SiteWise リソースをターゲット環境で特定の順序 (アセットモデル、アセット、ダッシュボードの順) で作成または変更する必要があります。そのためには、 AWS Step Functions ワークフロー の状態をリソースタイプごとに定義し、適切な順序で実行するようにワークフローを設定します。各ワークフローのステートは、S3 内の対応する CloudFormation テンプレートを参照する Lambda 関数タスクを呼び出します。リソースはまず CI/CD パイプラインで作成する必要があるため、最初のワークフローデプロイタスクで CloudFormation スタックが作成されます。 スタックが作成されると、それ以降の CI/CD パイプラインからの更新では、ワークフローと AWS Step Functions を使用してそれらのスタックが更新され、AWS IoT SiteWise リソースが変更および更新されます。アセットとダッシュボードの状態は、前の状態が CloudFormation へのデプロイを完了するまで待ってから開始します。これは、リソースを作成する前にリソースが存在する必要があるためです。アーキテクチャ図は以下のようになります。 本番環境のワークロードでは、お客様はデプロイパイプラインで CloudFormation の 変更セット を使用し、CloudFormation の更新が行われる前に手動の承認ゲートをセットして確認ができます。ダッシュボードがプラインでのデプロイ対象である場合は、ターゲット環境内に AWS IoT SiteWise Monitor ポータルをあらかじめ作成しておく必要があります。 まとめ このブログ記事では、AWS IoT SiteWise リソースを AWS 環境間で複製するための AWS IoT SiteWise ツール を紹介し、それらをデプロイパイプラインに統合するアーキテクチャ例を示しました。IT インフラストラクチャとアプリケーションのデプロイに関しては、組織ごとに要件、手順、ツールが異なります。そのため、お客様の要件に合わせてアーキテクチャを柔軟に調整し、特定の自動化パイプラインに統合できるようにツールを設計しました。こちらのツールの改善や追加のために、お気軽に リポジトリ にプルリクエストを送信してください。 About the Authors Sebastian Salomon は、AWS のシニア IoT データアーキテクトです。IIoT、自動車、O&G、スマートホーム、スマートシティ、マイニング、データウェアハウス、ビッグデータプラットフォームなど、さまざまな分野の IoT アーキテクチャで 7 年以上の経験があります。最近では、スケーラブルな MLOps プラットフォームを通じて AI を IoT に取り込む活動に注力しています。AWS プロフェッショナルサービスのメンバーとして、さまざまな規模や業界のお客様と協力して、さまざまなエンドツーエンドの IoT ソリューションを設計および実装しています。 Ashok Padmanabhan は、製造分野におけるビッグデータ分析とインダストリー 4.0 ソリューションに焦点を当てた AWS プロフェッショナルサービスのシニア IoT データアーキテクトです。 Mihai Lucaciu は、16 年以上の経験を持つ AWS プロフェッショナルサービスのシニア IoT データアーキテクトとして、産業データ、エッジ分析、クラウドサービスに関するさまざまなプロジェクトのソリューションアーキテクチャ、設計、実装でお客様を支援しています。 Tim Wilson は、AWS の公共部門パートナー組織の IoT 支援スペシャリストです。AWS 公共部門のパートナーと協力して、彼らの AWS IoT サービスとソリューションの運用と活用をサポートしています。AWS の公共部門事業が比較的小規模だった 2012 年に、ソリューションアーキテクトとして AWS に入社しました。また、AWS で IoT プロトタイピングラボを管理したり、AWS エグゼクティブブリーフィングセンターでテクニカルプレゼンターを務めたこともあります。 この記事は Sebastian Salomon, Ashok Padmanabhan, Mihai Lucaciu, Tim Wilson によって書かれた How to replicate AWS IoT SiteWise resources across environments の日本語訳です。この記事は Solutions Architect の 西亀真之 が翻訳しました。

クリックストリームデータとは、ユーザーと Web サイトまたはモバイルアプリケーションとの間で発生するデジタルインタラクションを収集したものです。リアルタイムにユーザーデータを収集し有用なインサイトを作成することは困難な場合があります。アマゾン ウェブ サービス（AWS）のサーバーレスサービスは、クリックストリームデータをシームレスにキャプチャ、処理、視覚化し、分析基盤に取り込むためのスケーラブルなアーキテクチャを提供するために役立ちます。 ユーザーインタラクションには、リンクやボタンのクリック、さまざまなページの表示、特定のページの閲覧時間、フォームの送信、ファイルのダウンロード、その他デジタル環境で行われるさまざまなアクティビティなど、さまざまなアクションが含まれます。クリックストリームデータが組織にとって重要である理由については、「 クリックストリームデータによるビジネス成果の促進 」を参照してください。 本ブログでは、AWS のサービスによって、サーバーのプロビジョニングや管理を必要とせずにクリックストリームデータを簡単に収集して処理する方法について詳しく見ていきます。 アーキテクチャ このソリューションでは、 Amazon API Gateway 、 AWS Lambda 、 Amazon Kinesis データストリームを使用してクリックストリームデータを取り込んで処理し、Amazon Kinesis Data Firehose を使用して未加工データをアマゾンシンプルストレージサービス (Amazon S3) に保存し、次に Amazon Athena と Amazon QuickSight を使用してユーザーフレンドリーな方法でデータを分析および視覚化します。 サービス選定理由 クリックストリームデータは、ユーザーのトラフィックと行動に応じて非常に変動しやすく、大量のメッセージとして継続的にストリーミングされます。新しいアプリケーション機能、 Web サイトのレイアウト、またはマーケティングキャンペーンのパフォーマンスを評価する場合、迅速なアクションを可能にするためにそれらをリアルタイムで分析することが重要です。 このアーキテクチャ用に選択された AWS サービスは、クリックストリームデータを処理するための自動スケーリング機能と費用対効果の高いソリューションを提供します。これらのサービスは、入ってくるワークロードの変動に対応するようにリソースを動的にスケーリングし、ほぼリアルタイムの処理と分析を保証します。従量課金制の価格モデルでは、使用したリソースに対してのみ支払いが発生するため、過剰なインフラを用意しておく必要がなくなり、コストを最小限に抑えることができます。 Amazon API Gateway は、開発者があらゆる規模の API を簡単に作成、公開、保守、監視、保護できるようにする完全マネージド型サービスです。 AWS Lambda はサーバーレスのイベント駆動型コンピューティングサービスで、サーバーのプロビジョニングや管理を行わずに、事実上あらゆるタイプのアプリケーションやバックエンドサービスのコードを実行できます。Lambda は 200 以上の AWS サービスと Software-as-a-Service (SaaS) アプリケーションからトリガーできます。支払いは使用した分だけです。 Amazon Kinesis Data Streams は、あらゆる規模のデータストリームの収集、処理、保存を容易にするサーバーレスのストリーミングデータサービスです。 Amazon Kinesis Data Firehose は、ストリーミングデータを確実に収集、変換し、データレイク、データストア、分析サービスに配信する抽出、変換、ロード (ETL) サービスです。 Amazon S3 は、業界トップクラスのスケーラビリティ、データ可用性、セキュリティ、パフォーマンスを提供するオブジェクトストレージサービスです。あらゆる規模と業種のお客様が、データレイク、クラウドネイティブアプリケーション、モバイルアプリなど、ほぼすべてのユースケースで任意の量のデータを保存および保護できます。 Amazon Athena では、場所を問わずペタバイト単位のデータを簡単に柔軟に分析できます。Athena を使用すると、Amazon S3 データレイクとオンプレミスのデータソースや SQL や Python を使用する他のクラウドシステムを含む 30 のデータソース からデータを分析したり、アプリケーションを構築したりできます。 Amazon QuickSight は、ハイパースケールの統合ビジネスインテリジェンス (BI) により、データ駆動型の組織を強化します。QuickSight を使用すると、すべてのユーザーが、最新のインタラクティブなダッシュボード、ページ分割レポート、埋め込み分析、自然言語クエリを通じて、同じ情報源からさまざまな分析ニーズを満たすことができます。 アーキテクチャ図 図 1 はクリックストリームのデータフローアーキテクチャを示し、クリックストリームのレコードが一連のステップを経てどのように処理されるかを示しています。図中のカスタマー Web ポータルは、Web サイトやモバイルアプリケーションなどのデジタルプラットフォームとして機能し、ユーザーがシステムを操作できるようにします。ユーザーが Web ポータルを操作してさまざまなリンクをクリックすると、クリックストリームデータは次のように処理されます。 図 1 — アーキテクチャ クライアント (カスタマー Web ポータル) は、クリックストリームペイロード (レコード) を API Gateway に送信します。 API Gateway はレコードを Lambda に送信し、そこでデータが標準化されます。 Lambda はレコードを Kinesis Data Streams に送信して非同期処理を行います。 Kinesis Data Streams はリクエストを Kinesis Data Firehose に転送します。 Kinesis Data Firehose は、1 分ごとにレコードをバッファリングし、S3 バケットにアップロードします。 Athena は S3 バケットに保存されているデータのクエリと分析に使用されます。 QuickSight を使用してダッシュボードを作成し、データを視覚的に表示します。 前提条件 このソリューションを導入するには、次が必要です。 AWS アカウント AWS CloudFormation テンプレートを実行するための AWS Identity and Access Management (IAM) 権限 ステップ 1: ソリューションの実装 次のステップを実行して AWS リソースを作成し、アーキテクチャに記載したクリックストリームパイプラインを構築します。本ブログでは、AWS リージョン us-east-1 を使用します。 CloudFormation スタックを起動します。 「 Create stack 」ページで、「 Next 」 を選択します。 図 2 — CloudFormation を使用してスタックを作成する 「 Specify stack details 」ページで、「 Next 」をクリックします。 図 3 — スタックの詳細 「 Configure stack options 」ページで、デフォルトの選択のままにして「 Next 」をクリックします。 レビューページで、AWS CloudFormation が IAM リソースを作成する可能性があることを確認します。IAM の詳細については、 IAM の詳細 を確認してください。 「 Submit 」をクリックします。 図 4 — IAM リソースの確認 スタックが完全にデプロイされると、スタックのステータスが CREATE_COMPLETE に変わります。CloudFormation スタックによって作成されたリソースは 「 Resources 」 タブを確認できます。 図 5 — スタックの状態 図 6 — 作成されたリソース Athena でクエリを実行する前に、クエリ結果を保存する S3 バケットを選択する必要があります。ステップ 9 ～ 15 に従って S3 バケットパスを設定します。 Amazon Athena コンソールに移動し、「 Query your data 」 を選択します。 「 Launch query editor 」をクリックします。 図 7 — Amazon Athena コンソール Query editor ページで、「 Settings 」タブを選択します。 「 Query result and encryption settings 」セクションで、「 Manage 」をクリックします。 図 8 — クエリエディタの設定 「 Manage settings 」 ページで、「 Browse S3 」をクリックします。 「 Choose S3 data set 」ページで、clickstream-で始まる S3 バケットを選択し、「 Choose 」をクリックします。 図 9 — クエリ結果の場所 「 Manage settings 」ページで、「 Save 」をクリックします。 図 10 — 設定の確認 次に、ステップ 17 ～ 20 に従って、クリックストリームデータを保存するテーブルを Athena に作成します。 クエリーエディタで、「 Saved queries 」タブを選択します。 図 11 — Athena の保存したクエリ 名前フィールドで、「 ClickStreamAthenaNamedQuery- 」 で始まる名前を探し、その名前に関連付けられている ID リンクをクリックします。 図 12 のように、「 Editor 」タブにクエリが入力されていることを確認します。「 Run 」をクリックします。 図 12 — クエリの実行 クエリが実行されると、図 13 に示す必要な列を含む clickstream_data テーブルが作成されます。 図 13 — テーブル作成 ステップ 2: ソリューションのテスト 後続のデータポイントを出力する Lambda 関数を使用して、クリックストリームデータをシミュレートします。 customerid deviceid productid productcategory productsubcategory activitytype ステップ 2a: データを取り込む AWS Lambda コンソールに移動します。 「 ClickStream-IngestDataLambda 」で始まる Lambda 関数をクリックします。 図 14 — Lambdaを選択 「 Test 」タブを選択します。任意のイベント名を入力します (たとえば、「 ClickStreamTest 」)。「 Save 」 をクリックし、「 Test 」をクリックします。 図 15 — Lambda テスト設定 Lambda 関数は、図 1 のアーキテクチャ図のステップ 1 に示すように、ランダムなクリックストリームデータの生成を開始し、それらを API Gateway に渡します。 関数が実行されるまで 1 分ほどかかることがあります。Lambda 関数によって生成されたクリックストリームのデータを確認するには、「 Log Output 」セクションを確認してください。 図 16 — Lambda ログ ステップ 2b: データを検証する Lambda 関数が実行されてから、データが Amazon S3 に表示されるまでに数分かかる場合があります。Kinesis Data Firehose は、受信レコードを S3 バケットに配信する前にバッファリングします。クリックストリームデータを Amazon S3 にすばやくアップロードするために、バッファ間隔を Kinesis Data Firehose の最小許容値である 60 秒に設定しました。 Amazon S3 コンソールに移動します。 「 ClickStream-ClickStreams3Buket- 」で始まる S3 バケットをクリックし、下にあるフォルダ構造をナビゲートしてクリックストリームデータファイルを見つけます。Amazon Kinesis Data Firehose は、オブジェクトを Amazon S3 に配置する前に、 UTC 時間で YYYY/MM/DD/HH の形式でプレフィックスを追加します。プレフィックスは Amazon S3 フォルダ構造に変換され、スラッシュ (/) で区切られた各ラベルがサブフォルダになります。 図 17 — Amazon S3 パス オブジェクトリンクをクリックし、「 Open 」 をクリックして CSV ファイルを開きます。 図 18 — ファイルを開く データを確認してください。図19 に示すような表示になっているはずです。 図 19 — データを確認する ステップ 2c: データの分析 Amazon Athena コンソールのクエリエディタに移動します。 「 Data source 」 フィールドで 「 AWSDataCatalog 」 が選択されていることを確認します。 「 Database 」フィールドから「 clickstreamDb 」を選択します。 「 Tables 」の左側にある方向三角形をクリックして テーブル を展開します。 clickstream_data テーブルを見つけて、clickstream_data テーブル名の右端にある 縦の 3 つの点 をクリックします。ドロップダウンメニューから 「 Preview Table 」 を選択します。 図 20 — テーブルをプレビュー 図 21 に示すように、 ingestClickStream Lambda 関数を介して取り込まれたデータが表示されるはずです。 図 21 — データを確認する ステップ 3: Amazon QuickSight を使用してダッシュボードを作成する Amazon QuickSight コンソールに移動します。 a. 以前に QuickSight アカウントを作成したことがない場合は、手順 2 ～ 6 に従ってアカウントを作成します。QuickSight アカウントをすでにお持ちの場合は、ステップ 7 に進んでください。 「 Sign up for QuickSight 」 ボタンをクリックします。 「 Create your QuickSight account 」 ページで、既定の選択のままにして 「 Continue 」 をクリックします。 「 Get Paginated Report add-on 」で、「 No, Maybe Later 」をクリックします。 「 Create your QuickSight account 」ページで、 a. 「 Authentication method 」セクションで、「 IAM federated identities & QuickSight-managed users 」を選択します。 b. 米国東部 (バージニア北部) リージョンを選択します。 c.一意の QuickSight アカウント名を入力します。 d. 通知を受け取るメールアドレスを入力します。 e. IAM ロール で、「 QuickSight-managed role (default) 」 を選択します。 f. 「 Allow access and autodiscovery for these resources 」 で、 IAM 、 Amazon S3 、 Amazon Athena の各チェックボックスをオンにします。図 22 に示すように、他のすべてのボックスのチェックを外します。 g. チェックマークが付いたAmazon S3リソースの下で、「 Select S3 bucket 」リンクをクリックします。新しいポップアップウィンドウから、「 clickstream-clickstreams3bucket- 」で始まる S3 バケットを選択し、「 Finish 」 をクリックしてポップアップウィンドウを閉じます (図 23 を参照)。 「 Finish 」 をクリックして Amazon QuickSight アカウントの作成を完了します。 図 22 — QuickSight アカウントの作成 図 23 — S3 バケットの選択 「 Go to Amazon QuickSight 」をクリックします。これにより、QuickSightが開きます。 図 24 — アカウントが作成されました 左側のナビゲーションメニューで「 Analyses 」が選択されていることを確認します。 右上隅の 「 New analysi s 」 ボタンをクリックします。次のページで 「 New dataset 」 ボタンをクリックします。 図 25 — 新しい分析 「 Create a Dataset 」ページで、「 Athena 」を選択します。 「 New Athena data source 」ページで、お好みの データソース名 を入力し、「 Create data source 」 をクリックします。 図 26 — データソースの作成 「 Choose your table 」ページで、以下を選択します。 a. 「 Catalog: contain sets of databases 」の下の awsDataCatalog b. 「 Database: contain sets of tables 」の下の clickstream_db c. 「 Tables: contain the data you can visualize 」の下の clickstream_data 完了したら、「 Select 」 をクリックします。 図 27 — テーブルを選択 「 Finish dataset creation 」 ページで、デフォルトの選択のままにして 「 Visualize 」 をクリックします。 図 28 — データセット作成の完了 次のページで、「 Interactive Sheet 」が選択されていることを確認します。デフォルトの選択をそのまま使用して、「 Create 」をクリックします。 図 29 — データセット作成の完了 (続き) クリックされた製品カテゴリの数を分析するビジュアルを作成します。 左上隅の 「 Add 」 をクリックし、「 Add Visual 」 をクリックします。 「 Visual Types 」から円グラフアイコンを選択します。 図 30 に示すように、「 productcategory 」を「 Group/Color 」フィールドにドラッグアンドドロップします。これにより、「 productcategory 」別のレコード数を示す円グラフが生成されます。 図 30 — 製品カテゴリ もう 1 つのビジュアルを追加して、各カテゴリの下でクリックされたサブカテゴリの数を分析してみましょう。 左上隅の 「 Add 」 をクリックし、「 Add Visual 」 をクリックします。 「 Visual Types 」から 垂直積み上げ棒グラフ アイコンを選択します。 図31に示すように、 X 軸 フィールドに「 productcategory 」をドラッグし、「 Group/Colo r 」フィールドに「 productsubcategory 」をドラッグアンドドロップします。 図 31 — 製品カテゴリ/サブカテゴリ ステップ 4: クリーンアップ 今後課金されないようにするには、次の手順に従ってリソースを削除してください。 QuickSight アカウントを削除する。 a. 右上の「 プロファイルアイコン 」をクリックします。 b. 「 Account Settings 」 をクリックします。 c. 「 Manage 」ボタンをクリックします。 図 32 — QuickSight アカウント設定 d. アカウント終了保護機能をオフにするには、「 Account Termination toggle 」を左にスライドします。 e. このアカウントを削除するには、「 Type “confirm” to delete this account box 」に「 confirm 」と入力します。 f. 「 Delete Account 」をクリックします。 図 33 — QuickSight アカウントの解約 S3 バケットを空にします。 a.  Amazon S3 コンソールに移動します。 b.  clickstream-clickstreams3bucket で始まるバケットを選択し、「 Empty 」をクリックします。 c. 「 Empty bucket 」ページで、「削除の確認」フィールドに「 permanently delete 」と入力し、「 Empty 」をクリックします。 図 34 — S3 バケットの選択 図 35 — S3 バケットを空にする ソリューションを削除します。 a.  CloudFormation コンソールに移動し、このプロジェクトの一環として作成した clickstream スタックを選択します。スタックをクリックし、「 Delete 」 をクリックします。 図 36 — CloudFormation スタックの削除 まとめ AWS サーバーレスサービスを活用することで、クリックストリームデータを扱うための強力でスケーラブルなソリューションが得られます。 Amazon API Gateway 、AWS Lambda 、 Amazon Kinesis Data Streams 、 Amazon Kinesis Data Firehose 、 Amazon S3 、 Amazon Athena 、 Amazon QuickSight などのサービスを利用することで、組織はクリックストリームデータを切れ目なく収集し、処理、視覚化し、分析基盤に取り込むことができます。Kinesis Data Firehose は受信データを自動的にスケーリングしてバッファリングすることで取り込みプロセスを促進し、Lambda はデータ変換と加工のためのカスタムコードの実行を可能にします。 サーバーレスアーキテクチャにより、企業はさまざまなデータ量を効率的に処理し、オペレーションコストを削減し、迅速に反復処理を行い、デジタルコンテンツにおける顧客の行動の変化から学ぶことができます。また、クリックストリームデータから迅速にインサイトを抽出できるため、データ主導の意思決定と顧客体験の向上が可能になります。 AWS の担当者 にお問い合わせいただき、当社がお客様のビジネスをどのように促進できるかをご確認ください。 参考文献 Real-time Clickstream Anomaly Detection with Amazon Kinesis Analytics Amazon Personalize customer outreach on your ecommerce platform 著者について Pritam Bedse Pritam Bedse は、アマゾン ウェブ サービスのシニアソリューションアーキテクトで、エンタープライズ企業のお客様を支援しています。彼の関心と経験には、AI/ML 、分析、サーバーレステクノロジー、カスタマーエンゲージメントプラットフォームなどがあります。仕事以外にも、Pritam は屋外でのガーデニングやグリルを楽しみます。 Christin Carter Christin Carter は、アマゾン ウェブ サービスのプリンシパルアカウントマネージャーで、エンタープライズ企業のお客様を支援しています。彼女の関心と経験には、デジタルトランスフォーメーション、AI/ML 、分析、サーバーレステクノロジー、カスタマーエクスペリエンスソリューションなどがあります。仕事以外では、Christin が世界中を旅し、大小さまざまな新しい冒険を求めています。 Jared Warren Jared Warren は、アマゾン ウェブ サービスのプリンシパルソリューションアーキテクトであり、エンタープライズ企業のお客様と協力しています。仕事以外では、ボードゲームをしたり、裏庭でバーベキューをしたりしています。 翻訳はソリューションアーキテクトの小西が担当しました。原文は こちら です。

今日の競争の激しい市場では、顧客を中心に考えることは不可欠です。顧客を中心に考えるためには、まず性別や年代といったユーザー属性（デモグラフィック）、嗜好やライフスタイルといったユーザーの心理的属性（サイコグラフィック）、取引、購入記録、サポートケース、製品の使用状況、買い物習慣、コンテンツの好みなどのデータが必要です。 ガートナーのレポート によると、消費者を 360 度把握している企業は 10% 未満です。彼らが努力しないからではなく、全体像を把握することはとても難しいのです。この課題は、データ収集と統合のプロセスに内在する複雑さに起因し、消費者の全体像を把握するうえで根強いハードルとなっています。 今日のビジネス環境は変化が速いため、タイムリーなビジネス意思決定では、新しいデータに何時間も何日もアクセスするのではなく、リアルタイムでアクセスする必要があります。競争力を維持し、現在の市場の状況に合わせて十分な情報に基づいた意思決定を行うためには、組織はリアルタイムの情報を自由に利用できなければなりません。 市場が急速に変動し、顧客の好みが変化すると、古くなったデータによって機会を逃したり、インサイトが古くなったりして、顧客体験が最適ではなくなる可能性があります。 企業は、自社のデータ（ファーストパーティデータ）の所有権を取り戻し、顧客や見込み客の情報の力を活用して競争力を高め、より顧客体験をもたらすべく取り組む必要があることを認識しています。ファーストパーティデータの例としては、企業が顧客の行動や好みについての理解を深めるための大きな可能性を秘めたクリックストリームデータがあります。 クリックストリームデータとは、ユーザーと Web サイトまたはモバイルアプリケーションとの間で発生するデジタルインタラクションを収集したものです。リアルタイムにユーザーデータを収集し有用なインサイトを作成することは困難な場合があります。アマゾン ウェブ サービス（AWS）のサーバーレスサービスは、クリックストリームデータをシームレスにキャプチャ、処理、視覚化し、分析基盤に取り込むためのスケーラブルなアーキテクチャを提供するために役立ちます。 ユーザーインタラクションには、リンクやボタンのクリック、さまざまなページの表示、特定のページの閲覧時間、フォームの送信、ファイルのダウンロード、その他デジタル環境で行われるさまざまなアクティビティなど、さまざまなアクションが含まれます。クリックストリームデータは、ユーザーの行動、好み、パターンに関する貴重なインサイトを提供します。これにより、組織は Web サイトやアプリを最適化し、顧客体験を向上させ、データ駆動型の意思決定を行って全体的なパフォーマンスを向上させることができます。 クリックストリームデータを活用することで企業が得ることができる利点をいくつか紹介します。 顧客インサイト: クリックストリームデータは、顧客の行動、好み、関心に関する貴重なインサイトを提供することができます。クリックストリームデータを分析することで、企業はユーザーが Web サイトやモバイルアプリをどのように操作しているか、どのページや機能が最も人気があるか、コンバージョン前にユーザーが取るアクションをよりよく理解できます。 パーソナライゼーション: クリックストリームデータを使用して、ユーザー体験をパーソナライズできます。ユーザーのクリックストリームデータを分析することで、企業はパーソナライズされたレコメンデーションを行い、ターゲットを絞ったコンテンツを表示し、関連性の高い広告を配信できます。 最適化: クリックストリームデータは、Web サイトやモバイルアプリの最適化に使用できます。クリックストリームデータを分析することで、企業は Web サイトやモバイルアプリの中で、ユーザー体験を損なっている領域やコンバージョンを妨げている領域を特定できます。その後、変更を加えてユーザー体験を向上させ、コンバージョンを増やすことができます。 マーケティング: クリックストリームデータは、マーケティングキャンペーンを最適化するために使用できます。クリックストリームデータを分析することで、企業はカスタマージャーニーをよりよく理解し、ターゲティング、メッセージング、チャネルセレクションについてより多くの情報に基づいた意思決定を行うことができます。 本ブログでは、サーバーのプロビジョニングや管理を必要とせずに、AWS サーバーレスサービスを使用してクリックストリームデータをほぼリアルタイムで収集するための高レベルのアーキテクチャについて説明します。 アーキテクチャ このソリューションでは、 Amazon API Gateway 、 AWS Lambda 、 Amazon Kinesis データストリームを使用してクリックストリームデータを取り込んで処理し、Amazon Kinesis Data Firehose を使用して未加工データをアマゾンシンプルストレージサービス (Amazon S3) に保存し、次に Amazon Athena と Amazon QuickSight を使用してユーザーフレンドリーな方法でデータを分析および視覚化します。 サービス選定理由 クリックストリームデータは、ユーザーのトラフィックと行動に応じて非常に変動しやすく、大量のメッセージとして継続的にストリーミングされます。新しいアプリケーション機能、 Web サイトのレイアウト、またはマーケティングキャンペーンのパフォーマンスを評価する場合、迅速なアクションを可能にするためにそれらをリアルタイムで分析することが重要です。 このアーキテクチャ用に選択された AWS サービスは、クリックストリームデータを処理するための自動スケーリング機能と費用対効果の高いソリューションを提供します。これらのサービスは、入ってくるワークロードの変動に対応するようにリソースを動的にスケーリングし、ほぼリアルタイムの処理と分析を保証します。従量課金制の価格モデルでは、使用したリソースに対してのみ支払いが発生するため、過剰なインフラを用意しておく必要がなくなり、コストを最小限に抑えることができます。 Amazon API Gateway は、開発者があらゆる規模の API を簡単に作成、公開、保守、監視、保護できるようにする完全マネージド型サービスです。 AWS Lambda はサーバーレスのイベント駆動型コンピューティングサービスで、サーバーのプロビジョニングや管理を行わずに、事実上あらゆるタイプのアプリケーションやバックエンドサービスのコードを実行できます。Lambda は 200 以上の AWS サービスと Software-as-a-Service (SaaS) アプリケーションからトリガーできます。支払いは使用した分だけです。 Amazon Kinesis Data Streams は、あらゆる規模のデータストリームの収集、処理、保存を容易にするサーバーレスのストリーミングデータサービスです。 Amazon Kinesis Data Firehose は、ストリーミングデータを確実に収集、変換し、データレイク、データストア、分析サービスに配信する抽出、変換、ロード (ETL) サービスです。 Amazon S3 は、業界トップクラスのスケーラビリティ、データ可用性、セキュリティ、パフォーマンスを提供するオブジェクトストレージサービスです。あらゆる規模と業種のお客様が、データレイク、クラウドネイティブアプリケーション、モバイルアプリなど、ほぼすべてのユースケースで任意の量のデータを保存および保護できます。 Amazon Athena では、場所を問わずペタバイト単位のデータを簡単に柔軟に分析できます。Athena を使用すると、Amazon S3 データレイクとオンプレミスのデータソースや SQL や Python を使用する他のクラウドシステムを含む 30 のデータソース からデータを分析したり、アプリケーションを構築したりできます。 Amazon QuickSight は、ハイパースケールの統合ビジネスインテリジェンス (BI) により、データ駆動型の組織を強化します。QuickSight を使用すると、すべてのユーザーが、最新のインタラクティブなダッシュボード、ページ分割レポート、埋め込み分析、自然言語クエリを通じて、同じ情報源からさまざまな分析ニーズを満たすことができます。 ニーマン・マーカスは、このソリューションを自社の e コマース Web サイトである BergdorfGoodman.com とNeimanMarcus.com に実装しました。オムニチャネルパーソナライゼーション担当ディレクターの Sravan Erukulla 氏は次のように語っています。「AWS は ニーマン・マーカス グループ と協力して、毎日数百万件のレコードを処理できるクリックストリームリポジトリを作成しました。わずか 3 週間で、2 つのチームが協力してソリューションを構築し、本番環境にデプロイしました。このクリックストリームデータにより、ニーマン・マーカスは、ユーザーの閲覧行動や放棄されたカートなどについて、ほぼリアルタイムでモデルのトレーニングと調整を行うことができます。」 アーキテクチャ図 図 1 はクリックストリームのデータフローアーキテクチャを示し、クリックストリームのレコードが一連のステップを経てどのように処理されるかを示しています。図中のカスタマー Web ポータルは、Web サイトやモバイルアプリケーションなどのデジタルプラットフォームとして機能し、ユーザーがシステムを操作できるようにします。ユーザーが Web ポータルを操作してさまざまなリンクをクリックすると、クリックストリームデータは次のように処理されます。 図 1 — アーキテクチャ クライアント (カスタマー Web ポータル) は、クリックストリームペイロード (レコード) を API Gateway に送信します。 API Gateway はレコードを Lambda に送信し、そこでデータが標準化されます。 Lambda はレコードを Kinesis Data Streams に送信して非同期処理を行います。 Kinesis Data Streams はリクエストを Kinesis Data Firehose に転送します。 Kinesis Data Firehose は、1 分ごとにレコードをバッファリングし、S3 バケットにアップロードします。 Athena は S3 バケットに保存されているデータのクエリと分析に使用されます。 QuickSight を使用してダッシュボードを作成し、データを視覚的に表示します。 クリックストリームのユースケースの例 クリックストリームデータは、 Amazon Personalize を使用してパーソナライズされたおすすめ商品を提供するための貴重な情報源となります。Amazon Personalize は、開発者がアプリケーション向けにパーソナライズされたレコメンデーションを作成できるようにする機械学習サービスです。Amazon Personalize はクリックストリームデータを使用してレコメンデーション機能を強化し、より適切でパーソナライズされた体験を顧客に提供できます。このブログで説明されているクリックストリームソリューションは、図 2 に示すように、クリックストリームデータを Amazon Personalize にフィードするように拡張できます。 図 2 — クリックストリームのユースケース Kinesis Data Streams はクリックストリームのレコードを Lambda に渡します。 Lambda はレコードをフォーマットして Amazon Personalize に送信します。 まとめ AWS サーバーレスサービスを活用することで、クリックストリームデータを扱うための強力でスケーラブルなソリューションが得られます。 Amazon API Gateway 、AWS Lambda 、 Amazon Kinesis Data Streams 、 Amazon Kinesis Data Firehose 、 Amazon S3 、 Amazon Athena 、 Amazon QuickSight などのサービスを利用することで、組織はクリックストリームデータを切れ目なく収集し、処理、視覚化し、分析基盤に取り込むことができます。Kinesis Data Firehose は受信データを自動的にスケーリングしてバッファリングすることで取り込みプロセスを促進し、Lambda はデータ変換と加工のためのカスタムコードの実行を可能にします。 サーバーレスアーキテクチャにより、企業はさまざまなデータ量を効率的に処理し、オペレーションコストを削減し、迅速に反復処理を行い、デジタルコンテンツにおける顧客の行動の変化から学ぶことができます。また、クリックストリームデータから迅速にインサイトを抽出できるため、データ主導の意思決定と顧客体験の向上が可能になります。 技術に焦点を当てたブログ「 AWS サーバーレスサービスを使用してクリックストリームデータをキャプチャする 」では、クリックストリームデータのキャプチャを開始する際に役立つように、このソリューションを導入する手順を段階的に説明します。 AWS の担当者 にお問い合わせいただき、当社がお客様のビジネスをどのように促進できるかをご確認ください。 参考文献 Real-time Clickstream Anomaly Detection with Amazon Kinesis Analytics Amazon Personalize customer outreach on your ecommerce platform 著者について Pritam Bedse Pritam Bedse は、アマゾン ウェブ サービスのシニアソリューションアーキテクトで、エンタープライズ企業のお客様を支援しています。彼の関心と経験には、AI/ML 、分析、サーバーレステクノロジー、カスタマーエンゲージメントプラットフォームなどがあります。仕事以外にも、Pritam は屋外でのガーデニングやグリルを楽しみます。 Christin Carter Christin Carter は、アマゾン ウェブ サービスのプリンシパルアカウントマネージャーで、エンタープライズ企業のお客様を支援しています。彼女の関心と経験には、デジタルトランスフォーメーション、AI/ML 、分析、サーバーレステクノロジー、カスタマーエクスペリエンスソリューションなどがあります。仕事以外では、Christin が世界中を旅し、大小さまざまな新しい冒険を求めています。 Jared Warren Jared Warren は、アマゾン ウェブ サービスのプリンシパルソリューションアーキテクトであり、エンタープライズ企業のお客様と協力しています。仕事以外では、ボードゲームをしたり、裏庭でバーベキューをしたりしています。 翻訳はソリューションアーキテクトの小西が担当しました。原文は こちら です。

11月29日は、 Amazon DocumentDB (MongoDB 互換) のベクトル検索 の一般提供についてお知らせします。この製品は、ドキュメントデータベース内でミリ秒の応答時間で何百万ものベクトルを保存、索引付け、検索できる新しい組み込み機能です。 ベクトル検索は、 機械学習 (ML) で使用される新しい手法で、距離または類似度メトリックを使用してベクトル表現を比較することにより、特定のデータに類似したデータポイントを検索します。ベクトルは、Amazon Bedrock、Amazon SageMaker、およびその他のオープンソースまたは独自の ML サービスでホストされている大規模言語モデル (LLM) から作成された非構造化データを数値で表したものです。このアプローチは、 検索拡張生成 (RAG) モデルアプローチを使用して、直感的な検索、製品推奨、パーソナライゼーション、チャットボットなどの 生成型人工知能 (AI) アプリケーションを作成するのに役立ちます。たとえば、データセットに映画の個別のドキュメントが含まれている場合、単にキーワードを照合するのではなく、「ボート」、「悲劇」、「実話に基づいた映画」などの共有コンテキストに基づいて、 タイタニック に似た映画をセマンティックに検索できます。 Amazon DocumentDB のベクトル検索を使用すると、個別のベクトルデータベースインフラストラクチャを管理する時間とコストをかけることなく、微妙な意味とコンテキストに基づいてデータベースを効果的に検索できます。また、Amazon DocumentDB が提供する、完全に管理された、スケーラブルで、安全で、可用性が高い JSON ベースのドキュメントデータベースも利用できます。 Amazon DocumentDB でベクトル検索を開始する ベクトル検索機能は、Amazon DocumentDB 5.0 インスタンスベースのクラスターで利用できます。ベクトル検索アプリケーションを実装するには、ドキュメント内のフィールドに埋め込みモデルを使用してベクトルを生成し、ソースデータを Amazon DocumentDB 内に並べて保存します。 次に、ベクトルフィールドにベクトルインデックスを作成します。これにより、類似のベクトルを取得しやすくなり、セマンティック検索を使用して Amazon DocumentDB データベースを検索できます。最後に、ユーザーが送信したクエリは、同じ埋め込みモデルを使用してベクトルに変換され、意味的に類似したドキュメントを取得してクライアントに返します。 Amazon DocumentDB でベクトル検索を使用して簡単なセマンティック検索アプリケーションを実装する方法を見てみましょう。 ステップ 1.Amazon Titan 埋め込みモデルを使用してベクトル埋め込みを作成する Amazon Titan 埋め込みモデルを使用して埋め込みベクトルを作成してみましょう 。Amazon Titan Embeddings モデルは、サーバーレスの生成系 AI サービスである Amazon Bedrock で利用できます。インフラストラクチャを管理することなく、単一の API を使用して簡単にアクセスできます。 prompt = "I love dog and cat." response = bedrock_runtime.invoke_model( body= json.dumps({"inputText": prompt}), modelId='amazon.titan-embed-text-v1', accept='application/json', contentType='application/json' ) response_body = json.loads(response['body'].read()) embedding = response_body.get('embedding') 返されるベクトル埋め込みは次のようになります。 [0.82421875, -0.6953125, -0.115722656, 0.87890625, 0.05883789, -0.020385742, 0.32421875, -0.00078201294, -0.40234375, 0.44140625, ...] ステップ 2.ベクトル埋め込みを挿入してベクトルインデックスを作成する insertMany( [{},...,{}] ) オペレーションを使用して、Amazon DocumentDB のコレクションに追加したいドキュメントのリストを使用して、生成されたベクトル埋め込みを追加できます。 db.collection.insertMany([ {sentence: "I love a dog and cat.", vectorField: [0.82421875, -0.6953125,...]}, {sentence: "My dog is very cute.", vectorField: [0.05883789, -0.020385742,...]}, {sentence: "I write with a pen.", vectorField: [-0.020385742, 0.32421875,...]}, ... ]); createIndex コマンドを使用してベクトルインデックスを作成できます。Amazon DocumentDB は、フラット圧縮 (IVFFLAT) ベクトルインデックスを使用した転置ファイルを使用して、近似最近傍検索 (ANN) を実行します。この機能は、ユークリッド、コサイン、内積の 3 つの距離計量をサポートします。ここでは、空間の 2 点間の直線距離の尺度であるユークリッド距離を使用します。ユークリッド距離が小さいほど、ベクトルは互いに近づきます。 db.collection.createIndex ( { vectorField: "vector" }, { "name": "index name", "vectorOptions": { "dimensions": 100, // the number of vector data dimensions "similarity": "euclidean", // Or cosine and dotProduct "lists": 100 } } ); ステップ 3. Amazon DocumentDB からベクトル埋め込みを検索する $search 内の新しい集計パイプライン演算子を使用して、ドキュメント内の類似のベクトルを検索できるようになりました。「 ペットが好き 」を検索するサンプルコードは次のとおりです。 db.collection.aggregate ({ $search: { "vectorSearch": { "vector": [0.82421875, -0.6953125,...], // Search for ‘I like pets’ "path": vectorField, "k": 5, "similarity": "euclidean", // Or cosine and dotProduct "probes": 1 // the number of clusters for vector search } } }); これにより、「 犬と猫が大好き 」などの検索結果が返されます。意味的には似ています。 詳細については、Amazon DocumentDB のドキュメントを参照してください。Amazon DocumentDB によるセマンティックムービー検索など、より実用的な例については、 GitHub リポジトリ にある Python のソースコードとデータセットをご覧ください。 今すぐご利用いただけます Amazon DocumentDB のベクトル検索は、 Amazon DocumentDB が利用可能な すべての AWS リージョンで Amazon DocumentDB 5.0 インスタンスベースのクラスターを使用しているすべてのお客様に追加費用なしで利用できるようになりました。Amazon DocumentDB への埋め込みの保存、インデックス作成、および検索ベクトルには、標準のコンピューティング、I/O、ストレージ、およびバックアップ料金が適用されます。 詳細については、 Amazon DocumentDB のドキュメント を参照してください。フィードバックは、 AWS re:Post for Amazon DocumentDB または通常の AWS サポート連絡先から送信してください。 – Channy 原文は こちら です。

アマゾン ウェブ サービス (AWS) の スマートストアソリューション の出現は、小売業者に新たな可能性を示しました。これらのソリューションを最大限に活用するには、小売業者はネットワークインフラストラクチャを最適化する必要があります。小売業者が業務のデジタル化を進め、より多くのサービスをクラウドに移行するにつれて、セキュリティとネットワークインフラストラクチャが主要な論点となっています。何千ものエンドポイントの管理、セキュリティコンプライアンスの確保、すべての店舗からの迅速かつ安全なクラウドアクセスの提供は、小売業者が直面する課題のほんの一部にすぎません。これらの課題は、世界中に大規模な店舗ネットワークを持つ小売業者にとって特に困難な場合があります。 幸いなことに、これらの課題に対する解決策があります。それは、AWS を使用してネットワークとセキュリティインフラストラクチャを統合し、一元管理することです。グローバルまたは全国規模のネットワークバックボーンを構築し、店舗やビジネスセンターにリーフノードを接続し、すべて AWS が管理することで、小売業者は AWS Cloud WAN を使用して世界中の何千もの店舗を AWS に接続できます。このアプローチは、低レイテンシーで安全な接続を提供するだけでなく、セキュリティの管理と監視を一元化し、すべての店舗で一貫したセキュリティポリシーを実現します。一元管理システムを導入することで、小売業者は各店舗に常駐する IT スタッフを必要とせずに、ネットワークインフラストラクチャを一元的に管理することで、セキュリティ規制の遵守、業務の合理化、コストの削減を実現できます。 ネットワークインフラストラクチャを最適化し、AWS スマートストアソリューションを活用することで、小売業者は収益を向上させながら顧客の店内体験を向上させることができます。たとえば、リアルタイムのデータ分析を使用してショッピング体験をパーソナライズしたり、オンラインとオフラインのチャネルを統合して新しい収益源を創出したり、サプライチェーン業務を最適化したりすることができます。さらに、小売業者は AWS の機械学習機能を活用して、在庫管理を自動化し、店舗のレイアウトと人員配置を最適化し、さらには盗難の検出と防止を行うことができます。 可能性は無限ですが、すべては強固なネットワークインフラストラクチャと信頼できるクラウドプロバイダーがあることが前提です。 店舗側に必要な要件 ほとんどの小売店には、IT チームがリモートから管理する IT 環境があります。これには以下が含まれます。 小売店向け IT ハードウェア: このカテゴリには、サーバー、従業員用 PC 、 Point-of-Sale (POS) コンポーネント、デジタルサイネージ、カメラなどのセキュリティデバイスなど、店舗でよく見かけるデバイスが含まれます。 小売店向け IT ソフトウェア: このカテゴリには、サーバーと PC のオペレーティングシステム、プロダクティビティソフトウェア、ERP ソフトウェア、コミュニケーションアプリケーション、ロイヤルティアプリケーション、e コマース、ビジネスアプリケーション、注文管理ソフトウェアが含まれます。 小売店向け IT サービス: このカテゴリには、サポートサービス、ハードウェアおよびソフトウェア管理、インストール/変更管理、ディザスタリカバリ、カスタムソフトウェア統合/開発が含まれます。 米国全土の 500 を超える店舗の平均を調べたところと、上記のすべてに店舗ごとの費用がかかります。世界中に数千の店舗を展開するような一部の小売業者では、IT 支出は大幅に増加します。 IT コンポーネント 500 を超える店舗の平均 PC 5% ファイアウォール/ルーター/スイッチ 2% 電話システム 6% 社内電話回線 7% サーバー (Windows DC 、SQL) 4% アプリケーションメンテナンス /POS 、スケジューリング、在庫管理、電子メール、その他アプリケーションのアップグレード 20% ブロードバンド接続 3% IT メンテナンスサポート (40 時間/月) 52% データストレージ / バックアップ 1% 合計 一部の小売業者では約 8,000 万ドルになります 表 1 — 小売店舗の IT コスト (ハードウェア、ソフトウェア、サービス) ほとんどの小売業者の IT 支出は年々増加し続けているため、これらのサービスの多くを AWS に統合してコストを削減し、顧客体験への投資を増やすことができます。このようなインフラストラクチャの管理は、特にさまざまな地域にまたがる多数の店舗を扱う場合には困難な場合があります。すべてのハードウェアとソフトウェアが最新で、安全で、正しく機能していることを確認することは、IT チームにとって大変な作業です。 小売業者は、IT インフラストラクチャの管理という課題に加えて、店舗ネットワークの信頼性と安全性を確保し、クラウドベースのサービスに対する需要の高まりに対応できるようにする必要もあります。e コマースの台頭により、顧客はすべてのチャネルでシームレスな体験を期待しており、小売業者はこの体験を実店舗でも提供できなければなりません。そのためには、リアルタイムの在庫管理、顧客分析、パーソナライズされたマーケティングなど、複数のアプリケーションとサービスを支えることのできる堅牢でスケーラブルなネットワークインフラストラクチャが必要です。AWS を使用して ネットワークとセキュリティインフラストラクチャ を統合して一元管理することで、小売業者はこれらの課題を克服し、シームレスでパーソナライズされたショッピング体験を顧客に提供できます。 実店舗のサービスを AWS に移行すると、コスト削減とともに以下のメリットが得られます。 一元化されたセキュリティ 侵入ポイントを減らす一元化されたインターネットアクセス 電話システム/電話回線などの資産を減価償却するための共有リソース 仮想デスクトップインフラストラクチャ (VDI) ソリューションによる安全なデスクトップアプライアンス (最小限の店舗の端末) すべての店舗にまたがるディザスターリカバリソリューション 店舗を横断した在庫管理 IT 人件費の削減 店舗ソリューションの導入 ソリューション概要 スマートストアネットワーキングおよびインフラストラクチャソリューションは、パートナーとの Direct Connect または SD-WAN （Software Defined-Wide Area Network）を使用して、すべての店舗を AWS に接続します。冗長性を確保するため、各店舗には AWS への接続が少なくとも 2 つ必要です。商品のスキャン、支払い処理、領収書の印刷、および店舗の端末用のハードウェアコンポーネントは、プライベート接続を介して AWS サービスに接続できます。 すべての店舗ソフトウェアは、オペレーションサポートのために最も近い AWS リージョンにデプロイする必要があります。これにより、サーバーや店舗ごとのメンテナンスが不要になります。支払い機能のためには、 AWS 仮想デスクトップインフラストラクチャソリューション に接続するゼロクライアントモニターが設置され、店舗アプリケーションがクラウド ERP および POS システムと通信できるようになり、より高い回復力とディザスターリカバリ機能が提供されます。電話交換機 (PBX) サービスは、Asterisk や Sipxcom などのオープンソースソリューションを使用して米国の 2 つのリージョンに統合し、 Amazon Connect と統合することでシームレスな顧客体験を実現できます。 AWS ネットワークインフラストラクチャ AWS ネットワークインフラストラクチャは AWS Cloud WAN を使用して構築され、クラウドネットワークエンジン (CNE) が米国の 4 つのリージョン (us-east-1、us-east2、us-west1、us-west2) のそれぞれにデプロイされます。これにより、4 つのリージョンに関連付けられた Direct Connect ロケーションが、AWS リージョン全体の Amazon Virtual Private Clouds (Amazon VPC) にトラフィックをルーティングできるようになります。 AWS Cloud WAN 内では、セグメントを作成して、各地域の店舗とそれに関連付けられた Amazon VPC ワークロードのトラフィックルールをグループ化できます。これにより、インターネットトラフィックと冗長ワークロードの管理が簡素化され、通信トラフィック用の VOIP セグメント、アプリケーションの開発とテスト用の開発セグメント、ビジネスアプリケーションの本番セグメントなど、アプリケーションとビジネス要件に基づいてネットワークトラフィックをセグメント化できます。このように店舗を地理的セグメントにグループ化することで、地域固有のニーズに基づいてさまざまなサービスを提供することもできます。 セキュリティアーキテクチャについては、すべての店舗のインターネット入出力トラフィックを処理するために、出口用のAmazon VPC が各リージョンに設定されます。出口用の Amazon VPC では、冗長構成でデプロイされたファイアウォールを使用してトラフィックを検査し、ネットワークインフラストラクチャの高度なセキュリティを確保します。 図 1: リファレンスネットワークアーキテクチャ 店舗から AWS への接続 小売業者のネットワーク上の各店舗には、近接性とネットワークプロバイダーのサービスに基づいて選択された 2 つの異なる AWS Direct Connect (Direct Connect) ロケーションへのファイバー接続が 2 つ以上必要です。仮想プライベートネットワーク (VPN) を使用した AWS Cloud WAN への 3 次バックアップ接続は、5G または BB を使用して設定できます。0.0.0.0/0 のルートが Direct Connect または VPN 経由で AWS を指定しているため、店舗からインターネットに直接アクセスすることはできません。AWS Direct Connect サービスプロバイダーに接続するには、各店舗にローカルルーターまたはスイッチが必要です。2 つの Direct Connect 接続は、異なるポイントオブプレゼンス (POP) で接続することをお勧めします。 複数の Direct Connect 接続と VPN バックアップのルート優先順位を管理するには、AWS のベストプラクティスに従って、ローカルルーターでボーダーゲートウェイプロトコル (BGP) を使用する必要があります。各 Direct Connect 接続は、店舗から Direct Connect ロケーションまで 1G で、AWS への Direct Connect ロケーションの帯域幅は、必要な店舗数と帯域幅に応じて 10G です。パケットのスループットを確保するには、帯域幅をオーバープロビジョニングすることをお勧めします。AWS Direct Connect はパケットの優先順位とサービス品質 (QoS) を管理しないため、すべてのパケットには差分サービスコードポイント (DSCP) のマークを付け、送信元で優先順位を付ける必要があります。DSCP マーキングは宛先に渡されます。帯域幅とクラスレスドメイン間ルーティング（CIDR）の計画が実施されている場合、店舗は Direct Connect 接続を追加する前に、まず SD-WAN を使用して AWS に接続できます。 ハイブリッド接続モデル すべての店舗が同じ接続モデルを必要とするわけではありません。店舗は大都市圏、郊外、地方に分類できます。これらのカテゴリではそれぞれ、接続オプションと帯域幅のニーズが異なる場合があります。 店舗から AWS に接続するには、SD-WAN を使用して店舗のローカル Direct Connect ロケーションにある顧客管理のスイッチ/ルーターへのラストマイルを行うハイブリッドアプローチがあります。この方法では、短距離でのパフォーマンスが向上し、レイテンシーが減少します。Direct Connect ロケーションでは、SD-WAN 接続を集約して AWS Cloud WAN に直接接続できます。 ブロードバンド回線を使用する郊外地域の店舗では、店舗接続の集約をローカルゾーンで行うこともできます。仮想 SD-WAN アプライアンスをローカルゾーンにデプロイして、SD-WAN ネットワークをローカル AWS ロケーションに拡張して AWS Cloud WAN に接続できます。全体として、このハイブリッドアプローチにより、店舗から AWS への効率的な接続が可能になります。 各接続モデルは、パフォーマンスと遅延の要件に基づいて最適かどうかをテストする必要があります。 図 2: ハイブリッド接続 店舗のインターネットアクセス 一部の店舗では、インターネットに直接アクセスできない場合があります。インターネット宛のトラフィックはすべて、Direct Connect 経由でインターネット出口用の Amazon VPC に送信されます。ファイアウォールポリシーは、設定されたルールに基づいて、下りの Amazon VPC のインターネットトラフィックに適用されます。インターネット出口用の Amazon VPC は各 AWS リージョンで設定され、トラフィックは各セグメントのルートテーブルを使用してインターネット出口用の Amazon VPC に送られます。 このモデルを利用すると、管理が必要なファイアウォールの数を合計 4 セットに減らすことができます。インターネット出口用の Amazon VPC は AWS Cloud WAN 内の共有サービスセグメントに接続されます。 図 3: ストア接続 マルチクラウド相互接続 Azure 、 GCP 、 SAP などの他のクラウドプロバイダーにデプロイされているワークロードの場合、小売業者はそのクラウドプロバイダーが存在するトランジットポイントへの Direct Connect 接続が必要になります。マルチクラウド接続をサポートする Direct Connect ロケーションを使用することをお勧めします。 これを設定するには、小売業者には次の 2 つの選択肢があります。 AWS Direct Connect 接続と他のクラウド接続を相互接続し、ルーティングを管理するルーターを備えたコロケーションラックを Direct Connect ロケーションにセットアップします。 マルチクラウドをサポートする Direct Connect パートナー と連携します。 どちらのオプションでも、IPv4 CIDR ブロック範囲が重複しないようにする必要があります。また、AWS Cloud WAN のルーティングルールは、トラフィックをマルチクラウドの Direct Connect ロケーションに転送するように適切に設定する必要があります。 マルチクラウドの Direct Connect 接続が設定されている各リージョンでは、マルチクラウド接続との間のすべての経路について、ファイアウォール検査付きのトランジット Amazon VPC を作成することをお勧めします。このファイアウォールはインターネット出口用のファイアウォールとは別のものです。 注:他のクラウドプロバイダーのパートナーサポートによっては、必要に応じて複数の Direct Connect ロケーションを使用して他のクラウドプロバイダーに接続できます。 エッジファイアウォールの設計 このアーキテクチャには以下のファイアウォールが推奨されます。 AWS Network Firewall – AWS Network Firewallは、AWS 内で開始されるすべてのアウトバウンドトラフィックに対して、出口用の Amazon VPC にデプロイされます。アウトバウンドトラフィックとレスポンストラフィックは、設定されたポリシーに基づいて検査されます。AWS Cloud WAN は、すべての Amazon VPC トラフィックを出口用の Amazon VPC 経由で転送するように設定できます。 Multi-Cloud Amazon VPC firewall – このファイアウォールは、AWS を経由して他のクラウドプロバイダー接続に向かうすべてのトラフィックに使用されます。各リージョンでアクティブ/スタンバイの 1 組が設定されます。 AWS WAF with AWS Shield – このファイアウォールは、Web アプリケーションの小売用 Web サーバーに送信されるすべての Web トラフィックに使用されます。これには、外部サポートを必要とするサードパーティーの Software-as-a-Service (SaaS) アプリケーションも含まれます。 一元管理されたファイアウォールマネージャーを使用することをおすすめします。高可用性と障害復旧のためには、複数のリージョンに展開する必要があります。 ローカルゾーン接続 ローカルゾーンは、必要に応じてワークロード用のミリ秒未満のレイテンシーをサポートできます。ローカルゾーンを使用すると、その店舗のリージョンの Amazon VPC は、コンピューティングリソースとストレージリソースをローカルゾーンに拡張できます。今後、サポートされるサービスが増えるにつれて、それらのサービスをローカルゾーンで利用できるようになります。Direct Connect を使用すると、リージョンへルーティングを戻さなくても、店舗のネットワークルーティングをローカルゾーンに直接拡張できます。 各ワークロードを分析して、ローカルゾーンが最適な選択肢かどうかを確認する必要があります。 スマートストアアプリケーション スマートストアアプリケーションには、相互に連携する必要のある店舗内コンポーネントとクラウドベースのコンポーネントの両方があります。たとえば、インタラクティブな統計情報を生成するためのカメラビジョンと人工知能と機械学習（AI/ML）処理の場合、ハードウェアを備えた AI コンポーネントは店舗にあり、データ分析とプレゼンテーションはクラウドで行われる場合があります。そうは言っても、店舗はかさばるハードウェアやサーバーを店舗内に置かず、商品を販売するためのスペースを空けたいと考えています。このような低レイテンシーの重要なソフトウェアの多くは、店舗がある場所の近くのローカルゾーンに導入できます。本ブログで説明されているネットワークアーキテクチャを利用することで、店舗はこの作業の負担を軽減できます。ローカルゾーンからは、店舗の貴重な帯域幅を使用することなく、AWS リージョンでデータを処理できます。 店舗とローカルゾーン間の通信のセキュリティは、プライベートネットワークを使用してローカルゾーンに直接接続するか、ローカルゾーンの仮想アプライアンスへの安全なトンネルを作成する店舗内の SD-WAN ベースのアプライアンスを使用してトラフィックを暗号化することで実現できます。もう 1 つの考慮は、トラフィックの優先順位です。コンピュータビジョン、RFID、スマートキオスク、ロボティクス、VOIP などの複数のスマートストアソリューションをサポートする場合、サービス品質が重要なニーズになります。店舗の帯域幅のニーズがブロードバンドアップリンク容量を超える時が来るでしょう。SD-WAN とDirect Connect のオーバーレイを使用すると、ネットワークエンジニアはビジネスニーズに基づいてトラフィックに優先順位を付けるポリシーを追加できます。このアーキテクチャは、スマートストア機能の有効化をサポートします。 まとめ 結論として、小売店向けの AWS ネットワークインフラストラクチャと接続オプションは、クラウドへの高性能で信頼性の高い接続を提供するように綿密に設計されています。 AWS Direct Connect 、SD-WAN 、ハイブリッドアプローチなど、さまざまな接続オプションがあるため、小売店は自分に最適なオプションを選択できます。さらに、AWS のサービスとベストプラクティスを活用することで、店舗はセキュリティと回復力を向上させながら、オンプレミスのハードウェアとメンテナンスの必要性を減らすことができます。 全体として、このネットワークインフラストラクチャと接続ソリューションは、小売店がクラウドに接続して事業運営をサポートするためのスケーラブルで柔軟かつ効率的な方法を提供します。 AWS の担当者 にお問い合わせいただき、当社がお客様のビジネスをどのように促進できるかをご確認ください。 参考文献 AWS Cloud WAN and AWS Transit Gateway migration and interoperability patterns Extending your VPC to Local Zones Smart Stores 著者について Ameel Kamboh Ameel Kamboh は AWS のシニアソリューションアーキテクトで、緊急通報ネットワークをグローバルに構築した経歴があります。ネットワークと複雑なアプリケーションの構築で 28 年以上の経験を持つ Ameel は、高可用性とスケーラビリティに重点を置いて設計してきました。AWS では、Ameel は小売企業部門での活動範囲を広げ、可能性を秘めた芸術をもたらす革新的なソリューションを顧客に提供してきました。 Chris Sereno Chris は AWS のソリューションアーキテクトで、ネットワーク分析のバックグラウンドを持っています。彼は、お客様がパフォーマンスと信頼性の高いアプリケーションを提供できるよう支援することに情熱を注いでいます。予定がないときには、キーボードを使って音楽を作るのを楽しんでいます。 Justin Swagler Justin Swagler は、AWS のフィジカル Retail のワールドワイド・ヘッドであり、フィジカル・リテールのグローバル戦略とソートリーダーシップを率いています。Justin は、イノベーション戦略、小売事業、製品開発、経営幹部など、消費者向けパッケージ商品、小売、戦略において 15 年以上にわたる経験があります。彼は、消費者体験を戦略的に革新し、再発明するよう組織を導くことに情熱を注いでいます。イリノイ大学アーバナ・シャンペーン校で学士号を、ケロッグ・スクール・オブ・マネジメントで経営学修士号を取得しています。 Rahul Nammireddy Rahul は AWS のシニアソリューションアーキテクトであり、デジタルネイティブのお客様をクラウドネイティブの変革に導くことに重点を置いています。彼は AI/ML テクノロジーに情熱を傾け、小売や通信などの業界の顧客と協力して、お客様の急速なイノベーションを支援しています。Rahul は 23 年以上にわたるキャリアを通じて、スタートアップ企業から上場企業まで、さまざまな企業で主要な技術指導的役割を果たしてきました。ビルダーとしての専門知識を披露し、イノベーションを推進してきました。 翻訳はソリューションアーキテクトの小西が担当しました。原文は こちら です。

11月29日は、新機能を備えた Amazon OpenSearch Serverless 用ベクトルエンジン が一般公開されたことをお知らせします。2023 年 7 月に、Amazon OpenSearch Serverless 用ベクトルエンジンの プレビューリリースを発表 しました。これは、シンプルでスケーラブルで高性能な類似検索機能です。ベクトルエンジンを使用すると、基盤となるベクトルデータベースインフラストラクチャを管理することなく、最新の機械学習 (ML) 拡張検索エクスペリエンスや生成型人工知能 (生成系 AI) アプリケーションを簡単に構築できます。 数千次元の何十億ものベクトル埋め込みをミリ秒単位で保存、更新、検索できるようになりました。ベクトルエンジンの高性能な類似検索機能により、AI を活用した生成型アプリケーションでは、ミリ秒単位の応答時間で、正確で信頼性の高い結果を得ることができます。 また、ベクトルエンジンでは、ベクトル検索と全文検索を同じクエリで組み合わせることで、ハイブリッド検索で結果を最適化および調整できるため、個別のデータストアや複雑なアプリケーションスタックを管理および保守する必要がなくなります。ベクトルエンジンは、安全で信頼性が高く、スケーラブルでエンタープライズ対応のプラットフォームを提供し、プロトタイピングアプリケーションをコスト効率よく構築し、本番環境にシームレスに拡張できます。 専用のベクトルエンジンベースのコレクションを作成することで、ベクトルエンジンをすぐに使い始めることができます。コレクションとは、埋め込みを論理的にグループ化したもので、連携してワークロードをサポートします。 ベクトルエンジンは、 OpenSearch Compute Units (OCU)、つまりコンピュートキャパシティユニットを使用して、類似検索クエリを取り込んで実行します。1 つの OCU は、99 パーセントのリコール率で、128 次元の最大 200 万のベクトル、768 次元の 500,000 のベクトルを処理できます。 OpenSearch サーバーレス上に構築されたベクトルエンジンは、デフォルトでは可用性の高いサービスです。アカウントの最初の収集には、少なくとも 4 つの OCU (プライマリとスタンバイを含む取り込み用に 2 つの OCU、アベイラビリティーゾーン全体に 2 つのアクティブなレプリカがある検索用に 2 つの OCU) が必要です。同じ AWS Key Management Service (AWS KMS) キーを使用する以降のすべてのコレクションは、それらの OCU を共有できます。 GA での新機能とは? プレビュー以降、Amazon OpenSearch Serverless 用ベクトルエンジンは、検索拡張生成 (RAG) コンセプトを使用して生成系 AI アプリケーションを構築するための Amazon Bedrock のナレッジベース のベクトルデータベースオプションの 1 つになりました。 今回の GA リリースの新機能または改善された機能は次のとおりです。 冗長レプリカ (開発とテストに重点を置く) オプションを無効にする プレビューブログ記事 でお知らせしたように、この機能により、可用性のためだけに別のアベイラビリティーゾーンに冗長な OCU を用意する必要がなくなります。コレクションには 2 つの OCU (1 つはインデックス用、もう 1 つは検索用) を使用してデプロイできます。これにより、冗長レプリカを使用するデフォルトのデプロイと比較して、コストが半分に削減されます。コスト削減のため、この構成は開発およびテストワークロードに適しており、経済的です。 このオプションでも、ベクトルエンジンが Amazon S3 のすべてのデータを保持するため、耐久性は保証されますが、シングル AZ に障害が発生すると、可用性に影響が及びます。 冗長レプリカを無効にする場合は、新しいベクトル検索コレクションを作成するときに [冗長性を有効にする] のチェックを外してください。 開発とテストに重点を置いたオプション用のフラクショナルOCU 開発とテストに重点を置いたワークロードに対して OCU の部分課金をサポートする (つまり、冗長レプリカオプションがない) ため、ベクトル検索コレクションの最低価格が下がります。ベクトルエンジンは、最初は小さい 0.5 OCU を導入しながら、同じ機能を低スケールで提供し、ワークロードの需要に合わせてフル OCU 以上までスケールアップします。このオプションを使用すると、ベクトルエンジンを試す際の月額コストをさらに削減できます。 10 億スケールの自動スケーリング ベクトルエンジンのシームレスな自動スケーリングにより、スケーリングのためにインデックスを再作成する必要がなくなります。プレビューでは、約 2,000 万のベクトル埋め込みをサポートしていました。ベクトルエンジンが一般公開されたことで、10 億のベクトルスケールをサポートできるよう制限を引き上げました。 今すぐご利用いただけます Amazon OpenSearch Serverless 用ベクトルエンジン は、Amazon OpenSearch Serverless が利用可能なすべての AWS リージョンで利用できるようになりました。 はじめに、次のリソースを参照してください。 Amazon OpenSearch Serverless 用ベクトルエンジンのご紹介 (現在プレビュー中) Amazon OpenSearch Service のベクトルエンジンでセマンティック検索を試してみる Amazon OpenSearch Service のベクトルデータベース機能の説明 OpenSearch をベクトルデータベースとして使う Amazon OpenSearch Serverless 入門ドキュメント デモビデオ: ベクトル検索用の Amazon OpenSearch Service デモビデオ: 検索機能の強化: OpenSearch と一括ベクトル検索 お試しいただき、 AWS re:Post for Amazon OpenSearch Service 、または通常の AWS サポート窓口までフィードバックをお送りください。 – Channy 原文は こちら です。

11月29日は、 Amazon SageMaker HyperPod を紹介します。この製品は、大規模な分散トレーニング専用のインフラストラクチャを提供することで、基盤モデル (FM) のトレーニング時間を短縮するのに役立ちます。SageMaker がクラスターの状態をアクティブに監視し、障害のあるノードを交換してチェックポイントからモデルトレーニングを再開することで、ノードとジョブの回復を自動化しながら、SageMaker HyperPod を使用して FM を数週間から数か月間トレーニングできるようになりました。 クラスターには、SageMaker の分散トレーニングライブラリがあらかじめ設定されています。これにより、トレーニングデータとモデルをすべてのノードに分割して並列処理し、クラスタのコンピューティングとネットワークインフラストラクチャを最大限に活用できます。追加のフレームワーク、デバッグツール、最適化ライブラリをインストールすることで、トレーニング環境をさらにカスタマイズできます。 SageMaker HyperPod を使い始める方法を紹介します。次のデモでは、SageMaker HyperPod を作成し、 AWS ML トレーニングリファレンスアーキテクチャ GitHub リポジトリで共有されている例を使用して Llama 2 7B モデルをトレーニングする方法を示します。 クラスターの作成と管理 SageMaker HyperPod 管理者は、 AWS マネジメントコンソール または AWS コマンドラインインターフェイス (AWS CLI) を使用してクラスターを作成および管理できます。  コンソールで 、 Amazon SageMaker に移動し、左側のメニューの [HyperPod クラスター] で [クラスター管理] を選択し、その後 [クラスターの作成] を選択します。 以下のセットアップでは、クラスター名を指定し、選択したインスタンスタイプと各インスタンスグループに割り当てるインスタンスの数でインスタンスグループを設定します。 また、クラスターの作成時に各インスタンスグループで実行するライフサイクルスクリプトを 1 つ以上準備して Amazon Simple Storage Service (Amazon S3) バケットにアップロードする必要があります。ライフサイクルスクリプトを使用すると、クラスター環境をカスタマイズし、必要なライブラリとパッケージをインストールできます。SageMaker HyperPod のライフサイクルスクリプトの例は、GitHub リポジトリにあります。 AWS CLI を使用する AWS CLI を使用してクラスターを作成および管理することもできます。このデモでは、JSON ファイルでクラスター構成を指定します。2 つのインスタンスグループを作成することにしました。1 つは「controller-group」と呼ばれるクラスターコントローラーノード用で、もう 1 つは「worker-group」と呼ばれるクラスターワーカーノード用です。 モデルトレーニングを行うワーカーノードには、 AWS Trainium チップを搭載した Amazon EC2 Trn1 インスタンスを指定します。 // demo-cluster.json { "InstanceGroups":[ { "InstanceGroupName": "controller-group", "InstanceType": "ml.m5.xlarge", "InstanceCount": 1, "lifecycleConfig": { "SourceS3Uri": "s3://<your-s3-bucket>/<lifecycle-script-directory>/", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::111122223333:role/my-role-for-cluster", "ThreadsPerCore": 1 }, { "InstanceGroupName": "worker-group", "InstanceType": "trn1.32xlarge", "InstanceCount": 4, "lifecycleConfig": { "SourceS3Uri": "s3://<your-s3-bucket>/<lifecycle-script-directory>/", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::111122223333:role/my-role-for-cluster", "ThreadsPerCore": 1 } ] } クラスターを作成するには、次の AWS CLI コマンドを実行します。 aws sagemaker create-cluster \ --cluster-name antje-demo-cluster \ --instance-groups file://demo-cluster.json 作成時に、 aws sagemaker 記述クラスター と aws sagemaker リストクラスターノード を使用して、クラスターとノードの詳細を表示できます。コントローラーノードのクラスター ID とインスタンス ID を書き留めます。クラスターに接続するには、その情報が必要です。 また、 Amazon FSx for Lustre などの共有ファイルシステムをアタッチすることもできます。FSx for Lustre を使用するには、 Amazon Virtual Private Cloud (Amazon VPC) 設定を使用してクラスターをセットアップする必要があります。これは SageMaker VPC を作成する方法と Lustre に FSx をデプロイ する方法を示す AWS CloudFormation テンプレートです。 クラスターに接続するには、 クラスターユーザーは、クラスター管理者によってプロビジョニングされたクラスターにアクセスできる必要があります。アクセス権限を設定したら、SSH を使用してクラスターに接続し、ジョブをスケジュールして実行できます。プリインストールされている AWS Systems Manager 用の AWS CLI プラグイン を使用して、クラスターのコントローラノードに接続できます。 デモでは、コントロールノードのクラスター ID とインスタンス ID をターゲットとして指定して、次のコマンドを実行します。 aws ssm start-session \ --target sagemaker-cluster:ntg44z9os8pn_i-05a854e0d4358b59c \ --region us-west-2 Slurm を使用してクラスターでジョブをスケジュールして実行する 発売時には、SageMaker HyperPod は Slurm によるワークロードオーケストレーションをサポートしています。Slurm は人気のあるオープンソースのクラスター管理およびジョブスケジューリングシステムです。クラスター作成の一環として、ライフサイクルスクリプトを使用して Slurm をインストールして設定できます。ライフサイクルスクリプトの例はその方法を示しています。次に、標準の Slurm コマンドを使用してジョブをスケジュールし、起動できます。アーキテクチャの詳細と役立つコマンドについては、 Slurm クイックスタートユーザーガイド をご覧ください。 このデモでは、 AWS ML トレーニングリファレンスアーキテクチャ GitHub リポジトリにあるこの例 を使用して、Trn1 インスタンスを使用して Slurm で Llama 2 7B をトレーニングする方法を示しています。私のクラスターはすでに Slurm でセットアップされており、Lustre ファイルシステムの FSx がマウントされています。 注意 Llama 2 モデルは Meta によって管理されています。 Meta リクエストアクセスページ からアクセスをリクエストできます。 クラスター環境のセットアップ SageMaker HyperPod は、 Conda 、 venv 、 Docker 、 enroot など、さまざまな環境でのトレーニングをサポートしています。 README の指示に従って、仮想環境 aws_neuron_venv_pytorch を構築し、Trn1 インスタンスでモデルをトレーニングするための torch_neuronx と neuronx-nemo-megatron ライブラリをセットアップしました。 モデル、トークナイザー、データセットの準備 指示に従って Llama 2 モデルとトークナイザーをダウンロードし、モデルを Hugging Face 形式に変換します。次に、 RedPajama データセット をダウンロードしてトークン化します。最後の準備ステップとして、モデルトレーニングをスピードアップするために、事前 (AOT) コンパイルを使用して Llama 2 モデルをプリコンパイルします。 クラスターでジョブを起動する これで、 sbatch コマンドを使用してモデルトレーニングジョブを開始する準備ができました。 sbatch --nodes 4 --auto-resume=1 run.slurm ./llama_7b.sh squeue コマンドを使用してジョブキューを表示できます。トレーニングジョブが実行されると、SageMaker HyperPod の復元機能が自動的に有効になります。SageMaker HyperPod は、前述のコマンドに示すように、ハードウェア障害を自動的に検出し、必要に応じてノードを交換し、 自動再開 パラメーターが設定されている場合はチェックポイントからトレーニングを再開します。 モデルトレーニングジョブの出力は、次のファイルで確認できます。 tail -f slurm-run.slurm-<JOB_ID>.out モデルトレーニングが開始されたことを示すサンプル出力は、次のようになります。 Epoch 0: 22%|██▏ | 4499/20101 [22:26:14<77:48:37, 17.95s/it, loss=2.43, v_num=5563, reduced_train_loss=2.470, gradient_norm=0.121, parameter_norm=1864.0, global_step=4512.0, consumed_samples=1.16e+6, iteration_time=16.40] Epoch 0: 22%|██▏ | 4500/20101 [22:26:32<77:48:18, 17.95s/it, loss=2.43, v_num=5563, reduced_train_loss=2.470, gradient_norm=0.121, parameter_norm=1864.0, global_step=4512.0, consumed_samples=1.16e+6, iteration_time=16.40] Epoch 0: 22%|██▏ | 4500/20101 [22:26:32<77:48:18, 17.95s/it, loss=2.44, v_num=5563, reduced_train_loss=2.450, gradient_norm=0.120, parameter_norm=1864.0, global_step=4512.0, consumed_samples=1.16e+6, iteration_time=16.50] モデルトレーニングジョブをさらに監視してプロファイリングするには、 SageMaker がホストする TensorBoard やその他の任意のツールを使用できます。 今すぐご利用いただけます SageMaker HyperPod は、本日より AWS リージョンの米国東部 (オハイオ州)、米国東部 (バージニア州北部)、米国西部 (オレゴン州)、アジアパシフィック地域 (シンガポール)、アジア太平洋地域 (シドニー)、アジアパシフィック地域 (東京)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ストックホルム) でご利用いただけます。 詳細はこちら。 価格情報とサポートされているクラスターインスタンスタイプのリストについては、 Amazon SageMaker HyperPod を参照してください デベロッパーガイド をご覧ください AWS マネジメントコンソールにアクセスして、SageMaker HyperPod で FM のトレーニングを開始してください –  Antje PS: AWS でブログ記事を書くのは、投稿タイトルの下に名前が 1 つしかない場合でも、常にチームの努力が必要です。今回は、 Brad Doran 、 Justin Pirtle 、 Ben Snyder 、 Pierre-Yves Aquilanti 、 Keita Watanabe 、 Verdi March の各氏に、サンプルコードの提供や、大規模モデル学習インフラ、Slurm、SageMaker HyperPod の管理に関する専門知識の共有など、惜しみない協力をいただきました。 原文は こちら です。

11月29日、 アンソロピックのクロード2.1 ファンデーションモデル (FM) が Amazon Bedrock で発売されたことをお知らせします。先週、Anthropic は最新モデルである クロード 2.1 を発表しました。これは、業界をリードする200,000トークンのコンテキストウィンドウ (クロード 2.0の2倍)、幻覚発生率の低減、長い文書の精度の向上、システムプロンプト、関数呼び出しとワークフローオーケストレーションのためのベータツール使用機能など、企業向けの主要な機能を提供します。 Amazon Bedrock でクロード 2.1が利用可能になったことで、Anthropic のより正直で信頼性の高い AI システムを使用して、 エンタープライズ対応のジェネレーティブ人工知能 (AI) アプリケーションを構築できます。Anthropic が提供する クロード 2.1 モデルを Amazon Bedrock コンソール で使用できるようになりました。 Amazon Bedrock の新しいクロード2.1モデルに関する主なハイライトは次のとおりです。 200,000トークンのコンテキストウィンドウ — エンタープライズアプリケーションでは、製品ガイド、技術文書、財務諸表、法的声明などの長い文書を扱う場合、より大きなコンテキストウィンドウとより正確な出力が必要になります。クロード 2.1は20万トークンをサポートしています。これは約15万語、つまり500ページを超える文書に相当します。豊富な情報をクロードにアップロードすると、要約、質疑応答、傾向の予測、複数の文書の比較対照が可能になり、事業計画の立案や複雑な契約の分析が可能になります。 精度の大幅な向上 — クロード 2.1 では、クロード 2.0 と比較して、幻覚発生率が2倍低下し、自由形式の会話やドキュメント Q&A での幻覚が 50％ 減少し、不正回答が 30％ 減少し、文書が特定の主張を裏付けていると誤って結論付ける割合が 3〜4 倍減少するなど、誠実さも大幅に向上しました。クロードは自分が知らないことを知るようになり、幻覚を起こすよりも反論する可能性が高くなります。この精度の向上により、顧客や従業員向けに、より信頼性の高いミッションクリティカルなアプリケーションを構築できます。 システムプロンプト — クロード 2.1では、システムプロンプトがサポートされるようになりました。これは、ロールプレイングシナリオ、特に長時間の会話でのキャラクターの深みと役割の順守の向上、ガイドライン、ルール、指示の厳守など、さまざまな方法で Claude のパフォーマンスを向上させる新機能です。これは構造的な変化を表していますが、クロードの以前の促し方からの内容の変化ではありません。 関数呼び出しとワークフローオーケストレーションのためのツールの使用 — ベータ機能として提供される クロード 2.1 は、既存の社内プロセス、製品、API と統合して、生成的な AI アプリケーションを構築できるようになりました。クロード 2.1は、追加のナレッジソースからデータを正確に取得して処理するだけでなく、特定のタスクの関数を呼び出します。 クロード 2.1 では、プライベート API や ウェブ 検索 API を使用してデータベースを検索して質問に答えたり、自然言語のリクエストを構造化された API 呼び出しに変換したり、製品データセットに接続してレコメンデーションを行ったり、顧客の購入を支援したりすることができます。この機能へのアクセスは現在、一部の早期アクセスパートナーに限定されており、近い将来にオープンアクセスが予定されています。早期アクセスに興味がある場合は、AWS アカウントチームにお問い合わせください。 クロード2.1の特徴と機能の詳細については、 Amazon Bedrock の Anthropic クロードと Amazon Bedrock のドキュメント をご覧ください。 クロード2.1のアクション Amazon Bedrock で クロード 2.1 を使い始めるには、 Amazon Bedrock コンソールにアクセスしてください 。左下のペインで モデルアクセス を選択し、右上の モデルアクセスの管理 を選択し、ユースケースを送信して、Anthropic クロード モデルへのモデルアクセスをリクエストします。モデルにアクセスするには数分かかる場合があります。既にクロード モデルにアクセスできる場合は、クロード 2.1 へのアクセスを別途リクエストする必要はありません。 チャットモードで クロード 2.1 をテストするには、左側のメニューペインの プレイグラウンド で テキスト または チャット を選択します。次に Anthropic を選択し、次に クロード v2.1を選択します 。 API リクエストを表示 を選択すると、 AWS コマンドラインインターフェイス (AWS CLI) と AWS SDK のコード例を使用してモデルにアクセスすることもできます。AWS CLI コマンドのサンプルは次のとおりです。 $ aws 岩盤ランタイム呼び出しモデル\       --model-id anthropic.claude-v2:1 \       --body "{\"prompt\":\"Human: \\n\\nHuman: Tell me funny joke about outer space!\n\nAssistant:", "max_tokens_to_sample": 50}' \       --cli-binary-format raw-in-base64-out \       invoke-model-output.txt Claude 2.1 モデルで提供されるシステムプロンプトエンジニアリング手法を使用できます。この手法では、その内容を参照または利用する質問の前に、入力やドキュメントを配置します。入力には、自然言語テキスト、構造化文書、 <document> 、 <papers> 、 <books> 、または タグを使用したコードスニペットなどがあります。チャット履歴などの会話テキストや、チャンク化されたドキュメントなどの検索拡張生成 (RAG) 結果を使用することもできます。 これは、サポートエージェントが企業文書に基づいて顧客の質問に回答するためのシステムプロンプトの例です。 タスクで参照できるドキュメントは次のとおりです。 <documents>  <document index="1">   <document_content>   (文書のテキストコンテンツ-一節、ウェブページ、記事などが考えられます)    </document_content> <document index="2">   <source>https://mycompany.repository/userguide/what-is-it.html</source> </document> <document index="3">   <source>https://mycompany.repository/docs/techspec.pdf</source>  </document> ... </documents> あなたはラリーで、会社の製品について深い知識を持つカスタマーアドバイザーです。ラリーは、顧客がナンセンスなことを言ったり、皮肉っぽいことを言ったりしても、顧客に対して非常に忍耐強いです。ラリーの答えは丁寧ですが、時には面白いこともあります。しかし、彼は会社の製品に関する質問に答えるだけで、他の質問についてはあまり知りません。提供されているドキュメントを使用して、ユーザーの質問に答えてください。 人間: 私が操作すると、あなたの製品は奇妙なスタッター音を出しています。何が問題なの? Amazon Bedrock のプロンプトエンジニアリングの詳細については、Amazon Bedrock のドキュメントに含まれている プロンプトエンジニアリングガイドライン を参照してください。クロードを含む Amazon Bedrock テキストモデルの一般的なプロンプトテクニック、テンプレート、例を学ぶことができます。 今すぐご利用いただけます クロード 2.1 は現在、米国東部 (バージニア北部) リージョンと米国西部 (オレゴン) リージョンでご利用いただけます。 支払いは実際に使用した分のみで、オンデマンドモードでは時間ベースの契約は不要です。テキスト生成モデルでは、処理された入力トークンと生成されたすべての出力トークンに対して課金されます。または、時間ベースの契約と引き換えに、アプリケーションのパフォーマンス要件を満たすのに 十分なスループット をプロビジョニングすることもできます。詳細については、「 Amazon Bedrock 価格設定 」を参照してください。 Anthropic Claude 2.1 を今すぐ Amazon Bedrock コンソールで試して、Amazon Bedrock の AWS re にフィードバックを投稿するか、通常の AWS サポートの連絡先を通じて投稿してください。 — チャニー 原文は こちら です。

本稿では  カヤバ株式会社 （以下、カヤバ）において、データとデジタル技術を活用できるデジタル人財の育成を目指し、AI ハッカソンなどを活用して教育の体系化・内製化を推し進めた取り組みについてご紹介します。 この取り組みについてより詳しくご覧になりたい方は カヤバ技報 第66号 デジタル人財育成の取組み  もご覧ください。（カヤバでは社員は会社の「財産」との認識があり、「人材」を「人財」と称しています） また本活動と並行して実施した、内製化によるシステムモダナイゼーションの取り組みについては こちら でご紹介しています。 デジタル人財育成の必要性 カヤバは、四輪車や二輪車のショックアブソーバー、建設機械用油圧シリンダー、コンクリートミキサー車などの技術や製品を提供しています。これまでに予知保全システムでのクラウド利用をきっかけとして 2017 年より AWS 上で クラウドネイティブな IoT プラットフォーム を構築し、社員が場所や時間の制約を受けることなく柔軟にデータを活用できる、コスト効率に優れた基盤を提供してきました。 カヤバでは 2019 年に設立された DX 推進部（現、デジタル変革推進本部）が旗振り役となり、ロードマップとして独自に6段階からなるデータ活用のステップを定義し、デジタルトランスフォーメーションを加速を目指しています。 図: データ活用ステップ 個人に依存したデータ活用から、あらゆる社員がデータを利用できる民主化、データ主導の意思決定を経て、ビジネスモデルの変革に至るこのステップを滞りなく進めるためには、システムの整備だけではなく、それを活用できる人財の育成が必要不可欠です。カヤバでは目指すべきデジタル人財を「デジタル技術を扱うテクノロジースキルとビジネス変革スキルを兼ね備えた人財」と定義し、特に重点的な育成が必要な分野と位置付けた AI (Artificial Intelligence) および BI (Business Intelligence) について、社員一人一人が次に目指すべきレベルを明確化するためにスキル別の階級策定表を策定し、また成長を支援するための教育計画を策定し、年間を通じて教育プログラムを提供しています。   図: デジタル人財 スキル別の階級策定表 図: デジタル人財育成の教育計画 AI 人財育成の取組み カヤバでは上記教育計画に基づいて、AI および BI の人財育成に重点的に取り組んでいますが、ここではそのうち AI に関する取り組みについてご紹介します。 AI人財育成では「AI教育カリキュラム」および「AIコミュニティ」の 2 つが活動の主たる柱となっています。 AI教育カリキュラム AI教育カリキュラムは知識や技術の習得を目的として、基礎理論からサービス化を視野に入れた実践的な内容までを網羅的にカバーしています。データサイエンティストやデータエンジニア、機械学習エンジニアが相互に円滑なコミュニケーションをとりながら技術的に連携できるよう、すべての受講生に対して MLOps を考慮した教育カリキュラムの提供を目指しており、2022年はAI基礎、プログラミング基礎、AWS基礎、AI実践の4種類の講座と、AIハッカソンプログラムを展開しました。AIハッカソンについては後述します。 AIコミュニティ AIコミュニティは、製品開発や生産技術など様々な領域から集まった人財がAI/MLに関する知識や技術について意見を交換しています。チャットツール上で社員がオープンに交流する場を提供し、またグループワークとして日頃の開発業務で抱えている具体的な課題を募集し、メンバが協力して解決を試みるなどの試みを行なっています。 AI ハッカソン 通年の教育カリキュラムで習得した知識や技術をチーム単位でアウトプットするイベントとして、2022 年より AWS の支援を得て AI ハッカソンを開催しています。 ハッカソンでは DX 推進部が運営主体となり、参加者は4人毎のチームを組んで運営から提供された仮想の課題に対して協力して機械学習によるソリューションの開発を行います。この活動では、単に機械学習モデルを実装するだけでなく、機械学習モデルの運用の仕組みや、AWS が提唱する Well-Architectedフレームワークへの適合なども課題として採用しました。2022年度は DX 推進部を含む 5 部署から計 16 名の社員が AI ハッカソンに参加し、3 ヶ月の活動期間中は週次のオフィスアワーとして AWS のソリューションアーキテクトへ自由に相談できる場を用意することで、チームが検討している設計や機械学習に関する実装上の不明点の解決をサポートしました。 ハッカソンの最後に実施した成果発表会では、カヤバの経営層や AWS 社が参加し、チーム毎に機械学習モデルの実装結果や機械学習システムの設計に関する工夫点を発表しました。 図: 成果発表会資料 2023年には、2022年のAIハッカソン受講生が担当する開発テーマの中から 2 つがプロジェクト化され、実証実験 (PoC: Proof of Concept) が開始されました。生産領域から製造ラインの外観検査におけるMLOps基盤の開発を、製品領域からCAEとAIを融合させたサロゲートモデルの活用基盤の開発に着手し、2024年から順次、運用を見込んでいます。 図：製造ラインの外観検査におけるMLOps基盤 図：サロゲートモデルの活用基盤 まとめ・今後について 本稿では，カヤバにおけるデジタル人財育成の取組みをご紹介しました。カヤバでは教育の目的は、社員が習得した知識や技術を日頃の開発業務に応用し、ビジネスに貢献することで初めて達成されると考えています。カヤバは今後も社内のデータ活用事例を増やし、DXの実現に向けて世の中のトレンドを意識しながら，必要な教育カリキュラムを展開・拡大していく予定です。   本稿はソリューションアーキテクト 内田、石井が担当し、カヤバ株式会社 デジタル変革推進本部 宮内 悠樹との共同執筆です。デジタル人材育成に取り組む方の参考となれば幸いです。 カスタマープロフィール: カヤバ株式会社 (KYB Corporation) 1919 年創業、設立1948 年。従業員数: 13,920名（2023年度・連結）四輪車や二輪車のショックアブソーバー、建設機械用油圧シリンダー、コンクリートミキサー車などの技術や製品を提供しています。

本稿では  カヤバ株式会社 （以下、カヤバ）のデジタル変革推進本部が中心となり、オンプレミスに存在したシステム群を内製化によってクラウドネイティブなアーキテクチャへと移行した、モダナイゼーションの取り組みについてご紹介します。 また本活動と並行して教育の体系化・内製化を推し進めた取り組みについては こちら でご紹介しています。 移行の背景と課題 カヤバは、四輪車や二輪車のショックアブソーバー、建設機械用油圧シリンダー、コンクリートミキサー車などの技術や製品を提供しています。これまでに予知保全システムでのクラウド利用をきっかけとして 2017 年より AWS 上で クラウドネイティブな IoT プラットフォーム を構築し、社員が場所や時間の制約を受けることなく柔軟にデータを活用できる、コスト効率に優れた基盤を提供してきました。 カヤバでは社内のデジタルトランスフォーメーションを加速することを目的として 2019 年に DX推進部（現在のデジタル変革推進本部）を設立し、その活動の一環として古くから長期稼働しているシステムの次世代化を推進してきました。この活動の一環として、2021 年下期に品質データ管理システムが内製化の対象に選ばれ、検討が始まりました。品質データ管理システムは、製品のトレーサビリティを実現するものであり、工場設備や試験機から収集された製品の加工条件や試験計測値などの品質情報を保存しています。旧来のシステムはオンプレミスで運用されており、主に3つの課題に直面していました。 課題1. メンテナンスコスト 20年以上稼働する当該システムは必ずしも正しく文書化されておらず、機能の修正や追加をする際にソースコードを直接確認しなければならないケースが頻発していました。また、Oracle Database をはじめとする商用ソフトウェアのサポートサービス費用がメンテナンスコスト最適化の足枷せとなっていました。 課題2. 可用性とセキュリティ 旧来のシステムは冗長化されていないサーバーコンポーネントが存在したことでシステムダウンを招くことがあり、また DR (Disaster Recovery: 災害復旧 ) 対策の不完全さによって広域災害時に業務が停止するリスクを抱えていました。また 2018 年には従業員によるコンプライアンス上の問題が露見し、改ざんをはじめとするデータベースの不正操作を検知する仕組みの導入も急務となっていました。 課題3. パフォーマンス 品質データ管理システムで使用しているデータベースは 20 年前の設計時と比較して取り扱うデータ量が拡大しており、最低限の正規化しか行われていない大福帳型のスキーマ構造では周辺システムとのデータ連携を行う際に十分なパフォーマンスを提供することができませんでした。 以下のアーキテクチャ図は、旧来のオンプレミスシステムの主要なコンポーネントを表したものです。 図: オンプレミスシステムのアーキテクチャ 前述の課題を解決するため、次のようなソリューションを検討し、適用しました。 1. サーバーレスサービスの活用 メンテナンスコストの課題への対策として、AWS の各種サーバーレスサービスの活用を推進しました。従来、ファイルサーバー上から別のサーバーへファイルを転送して処理していたアーキテクチャを、Amazon S3 や AWS Lambda を活用するアーキテクチャに変更することで、個々のサーバーに対するパッチ適用など運用工数を削減することができました。またサービスが提供するAWSリージョン内での冗長性やリージョン間のデータ連携機能等を活用することで広域災害への対応を強化することができました。リアーキテクチャにあたっては改修工数が発生しましたが、改修に要した期間はオンプレミスを前提とした予測よりも短期で完了することができました。 2. Amazon Quantum Ledger Database (Amazon QLDB) の導入 データの改ざん防止に適したフルマネージド型の台帳データベースである Amazon QLDB を導入しました。Amazon QLDB に品質データを保存することによって、完全かつ検証可能な変更履歴を長期に渡って保持し、管理者を含むあらゆる権限でのデータの変更を確実に追跡することが可能となりました。Amazon QLDB  に品質データのマスタを格納することに加え、社内ユーザーのニーズに応えるために複数の AWS サービスとの組み合わせでソリューションを提供しました。例えば、オンプレミス環境での SQL 検索の需要に応えるために、Amazon QLDB から Amazon Aurora PostgreSQL へデータを同期し、SQL 検索が可能になるようにしました。さらに、可視化の要望に応えて Tableau でダッシュボードを構築しました。SQL 検索機能に関しては、Amazon QLDB とのデータ連携に Amazon Kinesis Data Streams を使用し、データの順序保証には AWS Step Functions と AWS Lambda を利用した実装を行いました。 3. Amazon Aurora PostgreSQL の導入 周辺システムとの連携でパフォーマンスの課題が発生していたデータベースを、Amazon Aurora PostgreSQL に移行されました。また Amazon Aurora Global Database によってデータベースをリージョン間にレプリケーションすることで、今後の予定されている世界中の拠点からの利用拡大に際しても、アプリケーションからネットワーク上の距離が近い場所からデータを提供することが可能になりました。移行に際してはスキーマの正規化やコード体系の見直しも合わせて実施したことで、複数のシステム間でのデータ連携もスムーズに行うことができるようになりました。 これらの対策を取り入れ、新たに構築したシステムのアーキテクチャは以下の通りです。 図: クラウド上に新たに構築したアーキテクチャ 導入効果と今後の展望 前述の三つの課題（メンテナンスコストの増加、可用性とセキュリティ、パフォーマンス）を解決し、コストの最適化、システムの信頼性の向上、パフォーマンスの向上を実現しました。2023 年 9 月からは一部の工場での本格稼働を開始し、国内外での展開を計画中です。導入効果として、コスト面では従来のオンプレミス環境と比較して 5 年間で約 80% の削減が見込まれており、この削減には Oracle Database から Amazon Aurora PostgreSQL への変更、そしてアーキテクチャのサーバーレス化が寄与しています。 次の図はオンプレミスからクラウドへの移行パターンを示しています。今回の移行では、紫色の線で表されたリファクタの戦略を採用しました。単なるリホスト（Lift and Shift、オレンジ色の線）と比べると、リファクタには多くの工程を要することに気づかれるかもしれません。特に再設計が必要な箇所は高度な知識を要し、既存の設計と実装に加えて AWS の仕様に精通していることも求められました。このプロジェクトを実質約 1 年で内製化し成功させた実績は、品質データ管理システムに留まらず、他のシステムへも応用可能であると信じており、将来的にはサーバーコストを大きく削減できると考えています。 図: AWS への移行戦略 本稿はソリューションアーキテクト 内田、石井が担当し、カヤバ株式会社 デジタル変革推進本部 古川 輝との共同執筆です。Amazon QLDB をはじめとするAWSのマネージドサービスを活用したモダナイゼーションに取り組む方の参考となれば幸いです。 カスタマープロフィール: カヤバ株式会社 (KYB Corporation) 1919 年創業、設立1948 年。従業員数: 13,920名（2023年度・連結）四輪車や二輪車のショックアブソーバー、建設機械用油圧シリンダー、コンクリートミキサー車などの技術や製品を提供しています。

コンビニエンスストアという名前からもわかるように、コンビニエンスストアは速く便利なことを目的としています。 平均的な消費者が店内で過ごす時間は 3~4 分です 。ほとんどの消費者が店に入るときには、すでに何を買うか決めてます。 しかし、その利便性は、消費者が長いレジの行列を見たときに台無しになることがあります。残念ながら、消費者の「長い」という認識は必ずしも寛容ではありません。ある 調査 では、消費者の 15% が 1 分以上待たされると、必需品でないものの購入を諦めることがわかりました。彼らの半数は、わずか 30 秒待っただけで店を出て行くと言いました。 しかし、テクノロジーによって 30 秒の待ち時間を解消することができます。Amazon の Just Walk Out テクノロジー は、この便利さを実現した例です。 Just Walk Out テクノロジーが実装された店舗では、消費者は必要なものを手に取り、ただ出ていくだけでいいのです – レジに並ぶ必要は全くありません。Amazon は、自社のコンビニエンスストアである Amazon Go だけでなく、旅行小売、スポーツスタジアム、ライブイベント会場などのサードパーティーが運営するコンビニエンスストアおよび、コンビニ企業向けにこのテクノロジーを実装しました。 Amazon の Just Walk Out テクノロジー担当バイスプレジデントである Jon Jenkins は、「 Just Walk Out テクノロジーは、コンビニエンスストア運営者がコンシューマージャーニーのビジョンを設定できるようにすると同時に、迅速で便利なショッピング体験という目的を達成するのに役立つ」と説明しました。「コンビニエンスストアには、エンドツーエンドの店舗ジャーニーを柔軟に設計してもらいたいと考えています。コンビニエンスストアは、入退店体験、購入後の消費者体験、商品価格設定、支払い方法など、取り入れたい機能を定義できます」と彼は言います。 テクノロジーを活用したアクション Just Walk Out テクノロジーを採用した店舗に入るには、消費者はクレジットカードを挿入またはタップしたり、アプリやデジタルウォレットを使用したり、 Amazon One デバイスの上に手のひらをかざしたりすることで入店できます。 Amazon One は、消費者が支払いから入店まで、さまざまな体験を簡単にする手のひらを使った ID ソリューションです。Amazon One を初めて利用する消費者は、数秒で登録できます。一度登録すれば、Amazon One を導入している場所ならどこでも、手のひらを使って入店し支払いができます。 「いったん店に入ると、消費者はいつものように買い物をすればよいだけです。」と Jenkins は言います。「消費者が棚から取り出したものはすべて自動的に仮想ショッピングカートに追加され、棚に戻したものはすべて仮想ショッピングカートから削除されます。たとえば、棚からソーダを取り出すと、そのソーダは仮想ショッピングカートに入れられ、買い物が終わって店を出たときに請求されます。」 チェックアウトの手間を省く 店舗での買い物をより速くするため、多くのコンビニエンスストアはセルフレジを導入しています。セルフレジを導入することでレジ担当者の数を減らし、消費者に支払いオプションを増やすことができますが、その反面、消費者の利便性を低下させる結果となります。 セルフレジでは、消費者は商品のバーコードを見つけて、スキャンするか手動で入力しなければなりません。そして POS 機器から支払いデバイスに切り替えて購入しなければなりません。セルフレジのプロセスには多くの間違いが起こりやすく、実際に頻繁に起こっています。消費者が速やかな買い物を期待している時に、レジのプロセスに問題が発生したり、前の人が問題に直面していて列が停滞すると、イライラと苛立ちを感じることになります。 これとは対照的に、Just Walk Out テクノロジーはチェックアウトの手間を省き、コンビニエンスストアのオペレーションとスタッフの効率化を支援します。Jenkins は次のように語っています。「レジなしの店舗では、消費者は自分のペースで入店し、買い物を楽しみ、帰宅できるため、消費者の不満は最小限に抑えられます。」 運用の最適化とパフォーマンスの向上 Just Walk Out テクノロジーは、コンビニエンスストア事業者に複数のメリットをもたらします。レジの行列をなくすことで、スタッフはより良い体験を提供することに注力できます。「スタッフは、消費者への対応、質問への回答、商品の探し方の手伝い、必要に応じての陳列棚の補充などに、より多くの時間を費やすことができ、レジ操作や支払い処理などに時間を取られなくて済みます。この技術は、コンビニエンスストアが従業員を支払い処理のような反復的な機能から、よりエンゲージメントの高い消費者中心の機能へとシフトするのに役立ちます。」 Just Walk Out テクノロジーは、コンビニエンスストアがスペースの生産性を最大化するのにも役立ちます。コンビニエンスストアは伝統的に小規模な店舗です。従来の POS システム専用のスペース（通常は視認性の高いエリア）をなくすことで、コンビニエンスストアはそのスペースを再割り当てして、より多くのより良い製品配置やプロモーションを行うことができます。 さらに、コンビニエンスストア事業者はは、Just Walk Out アナリティクスを利用することで、自社の Just Walk Out テクノロジー対応店舗における商品の検討、受け取り、棚への返品、購入方法に関するインサイトを得ることができます。 e コマースサイトについて考えてみてください。小売業者は、最初にクリックされた商品、よく一緒に閲覧された商品、最終的に購入された商品を確認できます。Just Walk Out アナリティクスは、コンビニエンスストアのリーダーに実店舗についてもこれと同レベルの洞察を提供します。Just Walk Out アナリティクスを使うと、コンビニエンスストアのリーダーは、店舗全体および棚別、備品別、製品カテゴリ別の商品インタラクションをスケーラブルでデータ主導型のビューで把握できます。この洞察は、コンビニエンスストアのリーダーが商品の品揃えや配置を改善し、オペレーション効率を高め、消費者の店舗体験を向上させるのに役立ちます。 消費者とコンビニエンスストア事業者は同じような目標を共有しています。どちらも、買い物を簡単にする店舗体験を求めています。「 Just Walk Out テクノロジーは双方にメリットをもたらします」と Jenkins は言います。「レジの列に並ぶ必要がなくなるため、消費者は忙しい生活の中でも簡単に店舗に入って必要なものを購入することができます。それがこのテクノロジーによって可能になることであり、この体験をより多くのお客様に提供できることを楽しみにしています。」 Amazon の Just Walk Out テクノロジーとコンビニエンスストア向け Amazon One の 詳細 をご覧ください。 翻訳はソリューションアーキテクトの小西が担当しました。原文は こちら です。

本記事は How to: Create a VR application with user insights using AWS Amplify and WebXR を翻訳したものです。 このブログでは、 AWS Amplify と Babylon.js の WebXR 実装 を使用して、ユーザーのインサイトを活用したバーチャルリアリティ体験を作成する方法について学びます。この組み合わせによって、最初のバーチャルリアリティ（VR）アプリケーションを立ち上げる際のハードルを下げることができるでしょう。 このハウツーでは、AWS Amplify を使用してフルスタックアプリケーションをホストし、Babylon.js の WebXR 実装で VR シーンと機能を提供し、 Amazon DynamoDB を使用してユーザーイベントを保存し報告する、シンプルな VR 対応アプリケーションを作成する手順をカバーします。アプリケーションは Amplify と Babylon.js を使用して設定され、デプロイされます。コントローラーの入力データは WebXR を使用して有効にされ、ユーザーの入力イベントは DynamoDB、 Amazon Athena 、および Amazon Quicksight を使用して保存および報告されます。アプリケーションで使用される 3D モデルは、 Amazon Simple Storage Service（Amazon S3） を使用して保存されます。Amplify は AWS CodeCommit を使用して継続的なデプロイメントを行います。 最終的には 3D モデルを使用した VR アプリケーションが作成され、ユーザーの入力が記録・可視化されるため、お客様はユーザーエクスペリエンスの改善方法についてのインサイトをダッシュボードで確認できます。 この Amplify アプリケーションでは、たとえばプレイヤーは VR コントローラーで Color GUI から青色を選択します。色の変更イベントは、データベースに色の値を送信します。 DynamoDB テーブルには、各イベントの色の値が記録されます。 Quicksight ダッシュボードは DynamoDB からのデータを表示するために使用されます。 アーキテクチャ ユーザーは、VR 対応デバイスを使用して AWS Amplify のウェブサイトに接続します。テクスチャやオブジェクトは Amazon S3 からアプリケーションに読み込まれます。オブジェクトは AWS Amplify の外で Amazon S3 において管理します。ユーザーは XR シーンで利用可能なオブジェクトやコントロールと対話し、クリック、色の選択、テクスチャの選択などの各ユーザーイベントは DynamoDB に送信されます。Amazon Athena は Quicksight がユーザーのインサイトを提供するためのデータを利用可能にします。AWS Amplify の管理者は、ホストされたサイトにユーザーのインサイトに基づいた変更をデプロイすることができます。 前提条件 AWS Amplify 、 Amazon DynamoDB 、 Amazon S3 、 Amazon Athena 、および Amazon Quicksight への完全な権限を持つ既存の Amazon Web Services (AWS) アカウント JavaScript と Linux コマンドラインに慣れている Node.js v14.x 以降 npm v6.14.4 以降 git v2.14.1 以降 最新の Amplify CLI ；バージョン 10.6.2 以上 手順の概要 サンプルアプリケーションをデプロイして実行するには、次の手順を実行します。 ステップ 1: React アプリケーションのセットアップ Getting started – React – AWS Amplify Docs を使用して React アプリケーションを作成し、create-react-app を使用してディレクトリ構造を作成し、ローカルシステムで開始できることを確認します。 ステップ 2: AWS Amplify と Babylon.js のインストール Getting Set Up | Babylon.js Documentation を使用して AWS Amplify CLI 、Babylon.js、および Babylon.js モジュールをインストールします。AWS Amplify は、フロントエンドの Web およびモバイル開発者が AWS 上でフルスタックアプリケーションを迅速かつ容易に構築できるようにするための目的に特化したツールおよび機能のセットです。 ステップ 3: Amplify でバックエンドを初期化 このプロジェクトでは、Amplify の AWS AppSync 、Amazon S3、 Amazon Cognito との統合を活用します。アプリケーションの構築とデプロイ、必要な AWS リソースのプロビジョニングについては Complete guide to full-stack CI/CD workflows with AWS Amplify も参照してください。まずは Amplify CLI を使用して Amplify 環境を初期化し、編集します。 ステップ 4: Amplify でバックエンドリソースを作成 Storage – Overview – AWS Amplify Docs を使用して Amplify バックエンドリソースを作成しプッシュし、 Tutorial – Add authentication – React – AWS Amplify Docs を使用して認証を行い、 Tutorial – Connect API and database to the app – React – AWS Amplify Docs を使用してデータを同期および DynamoDB に保存します。 ステップ 5: Amazon S3 にテクスチャをアップロード AWS 管理コンソール に移動し、作成されたリソースを表示します。Amazon S3 コンソールに移動し、ステップ 4 で作成したバケットを探します。トップディレクトリで「public」というフォルダを作成し、そのフォルダに入ります。このフォルダ内で「アップロード」をクリックし、バケットにテクスチャをアップロードします。これでコードからアクセス可能になります。 ステップ 6: アプリケーションシーンの作成 Babylon.js は JavaScript ベースの人気のある 3D エンジンで、Web 用の 3D アプリケーションやゲームを開発するためのオープンソースフレームワークです。これは、リアルな動きやオブジェクト間の相互作用を容易に作成できる高度な機能を提供し、VR アプリケーションの作成に不可欠です。Babylon.js のドキュメントから Starter HTML Template を使用して index.html ファイルを作成します。ローカルシステムでコードをコピーし、 README.md の src/index.js、src/App.js、および src/Scene.js に貼り付けます。 ステップ 7: git ベースの CI/CD デプロイメント用の CodeCommit を作成 アプリケーションをホストするために、AWS Amplify Hosting サービスと AWS CodeCommit を使用します。Amplify Hosting は完全に管理された CI/CD およびホスティングサービスであり、AWS CodeCommit は完全に管理されたソースコントロールサービスであり、 Setting up Amplify access to GitHub repositories のドキュメントを使用して git ベースの CI/CD デプロイメントを可能にします。 ステップ 8: 継続的なデプロイメントのために Amplify を CodeCommit に接続 AWS 管理コンソールから Amplify コンソールを開き、継続的なデプロイメントを有効にするために CodeCommit リポジトリに接続します。 ステップ 9: Amazon Athena と DynamoDB コネクタを作成 Amazon Athena DynamoDB コネクタ により、Amazon Athena は DynamoDB と通信できるようになり、SQL を使用してテーブルをクエリできます。これにより、シーン内のユーザーアクションから取り込まれたイベントデータを視覚化するために QuickSight を使用できます。 ステップ 10: QuickSight ダッシュボードを作成 DynamoDB に保存されたイベントデータから洞察を得るために QuickSight ダッシュボード を作成します。Amazon QuickSight は、簡単に理解できる洞察を提供するために使用できるクラウドスケールのビジネスインテリジェンス（BI）サービスです。 ステップ 11: VR アプリケーションの表示と使用 新しい CodeCommit プッシュコマンドが実行されるたびに、Amplify は新しいビルドとデプロイプロセスを実行します。デプロイプロセスが完了すると、最新バージョンはアプリホスティング環境にある同じプロダクションブランチの URL に残ります。 ステップ 12: QuickSight ダッシュボードの表示 QuickSight は、172 回の VR コントローラーのクリックと、各クリックの色の RGB 値を示しています。 ステップ 13: 公開アクセスの制限またはクリーンアップ 意図しないアクセスによるコスト上昇を防ぐためには、 Restricting access to branches の指示に従って Amplify URL をパスワード保護するか、作成されたすべてのリソースを削除します。 終わりに Amplify、Babylon.js、および Babylon.js の WebXR スタックを使用する方法を示すこのブログは、WebXR を始めるための多くの方法のうちの一つにすぎません。Amplify を使用すると、XR のアイデアを反復するための継続的なデプロイメント環境が提供されます。Bablyon.js で次に試すべきことのインスピレーションを得るためには、 The Playground を訪れてください。このブログの例は、追加のオブジェクト、テクスチャ、およびコントロールでより多くのイベントデータを収集すること、より包括的なダッシュボードを作成すること、または AI/ML を追加してユーザーの洞察を拡大することでさらに拡張することができます。 次のステップ このブログで概説されているセットアップを再現するために使用された具体的な技術コマンドを含む完全なステップバイステップの解説は、 Create a VR application with user insights using aws amplify and the webxr stack で見つけることができます。 著者について Brian M. Slater Brian M. Slater は、Amazon Web Services の Independent Software Vendors (ISV) の Principal Solutions Architect です。Brian は、政府、スタートアップ、および金融サービスにおいて多年の経験を持っています。現在は、IoT および空間コンピューティングソリューションの構築において顧客を支援しています。 Sam Burton Sam Burton は Amazon Web Services のエンタープライズソリューションアーキテクトであり、業界のベストプラクティスに従って AWS 上でソリューションを構築、反復、およびスケールするお客様を支援しています。エンタープライズ顧客との作業以外に、Sam は AWS Amplify などのフロントエンドの Web およびモバイルサービスでの構築を行っています。 Sneha Panchadhara Sneha Panchadhara は Amazon Web Services のソリューションアーキテクトで、お客様がビジネス目標を達成し、AWS サービスの採用を加速するのを支援することを楽しんでいます。仕事以外の時間は、家族や友人と過ごすのが好きです。 翻訳はソリューションアーキテクトの阿南が担当しました。原文は こちら です

本記事は Exploring the Spatial Computing Spectrum: The Next Frontier of Immersive Technologies を翻訳したものです。 新しい技術進歩の時代に入るにつれ、次なるイノベーションのフロンティアは空間コンピューティングによって動かされることが明らかになってきました。ゲーム、映画とメディア、シミュレーション、あるいはメタバースなどの分野において、さまざまな業界の企業が空間コンピューティングの能力開発を競っています。特に、3D コンテンツ作成、ゲーム、シミュレーション、地理空間の4つの空間コンピューティングセグメントがイノベーションを推進する立場にあります。これらの各領域のためのより良いツールとクラウドサービスを開発することで、空間コンピューティングは人々の働き方、遊び方、生活の仕方を革新する新しい可能性の扉を開くでしょう。 Amazon Web Services(AWS) のチームは、すでに空間コンピューティングの基盤を構築するために懸命に取り組んでいます。このブログ記事では、空間コンピューティングとは何かを探り、3D コンテンツ作成、ゲーム、シミュレーション、地理空間を通じて、AWS がこの革新的なテクノロジーの未来を形作る支援をしていることを紹介します。 空間コンピューティングとは 空間コンピューティングは、仮想世界と物理世界の組み合わせです。物理世界を仮想化し、仮想情報を物理世界に重ね合わせることで、ユーザーがデジタルコンテンツと自然かつ直感的に対話できるようになります。この組み合わせにより、物理的あるいは仮想的な場所におけるデータの可視化、シミュレーション、操作が強化されます。ブログ “The Best way to Predict the Future is to Simulate it”  で、Amazon のテクノロジー担当 VP Bill Vass は、「空間コンピューティングは、協調型エクスペリエンスを実現する原動力です」と述べています。 空間コンピューティングは、業種や業界の垣根を越えています。ユースケースは、リアルタイムメトリクスを表示するデジタルツインから、大規模多人数同時オンライン (MMO) ビデオゲーム、都市全体のレーザースキャンで訓練された AI/ML モデルなど、幅広い範囲に及びます。これらのユースケースは業界の垣根を越えていますが、同様のコアテクノロジー、仕様、ワークフロー、課題を共有しています。 アート作品の制作 3D デジタルコンテンツ制作は、空間コンピューティングのバックボーンです。AWS を利用することで、顧客は画期的なアート作品の創作により多くの時間を費やし、ハードウェアやレンダーファームの管理に費やす時間を短縮できます。ブログ “Avatar: The Way of Water” のような最新のコンピュータグラフィックス (CG) ショットをレンダリングする場合でも、プロダクションをクラウドに移行することで世界中から最高の人材を集める場合でも、AWSのソリューションとサービスはクリエイターが観客を楽しませる力を発揮してきました。 AWS のメディアサービス は、顧客がハリウッドの大作映画のデジタルコンテンツを作成し、ライブおよびオンデマンドのビデオワークフローを構築するのに利用されてきました。 AWS Thinkbox Deadline は、スケーラブルかつ柔軟なコンピュートレンダリング管理の業界標準です。Deadline により、顧客はオンプレミスのレンダーファームからクラウドに移行でき、アーティストはより迅速に反復処理を行い、ショットの納期を従来の日数から時間単位に短縮することが可能になりました。 ここ数年で、顧客は中央集中型のチームから世界中に分散したチームへと移行してきました。これにより、スタジオはタイムゾーンを越えて世界中から最高のクリエイターを集めることができるようになりました。 AWS Studio in the Cloud ソリューションは、スタジオの分散型グローバルチームへの移行を支える基盤として機能してきました。こうした移行からの学びを踏まえ、AWS のツールとサービスは 3D コンテンツ制作のためのクラウド利用をより簡単にするよう進化を遂げています。AWS は、顧客がワークフローを加速し、次世代の 3D コンテンツをより効率的に制作できるよう、コアとなるクラウドインフラとリソースの提供に注力しています。 AWSは次なる一手を予測するため、先を見据えています。世界中のスタジオがクラウドを利用して、日数ではなく時間単位で映像作品を制作してきました。顧客とのこうした取り組みから得た教訓をさらに推し進めることで、新しい形の映画製作、インタラクティブ体験、ビデオゲームのためのより大規模なスケーラビリティ、可用性、クラウドコンピューティングパワーを実現していきます。 あらゆる規模でのゲーム この 5 年間でビデオゲームは驚異的な成長を遂げており、AWS は規模の大小を問わずゲーム開発者をサポートしてきました。インディーゲームスタジオの Blinkmoon Games から、 Epic Games のような業界最大手スタジオまで、AWS に全面的にコミットしている開発者に対し、AWS はグローバルな規模でゲームを提供するために必要なツールとリソースを提供しています。 今日、Epic Games が開発した Fortnite は、ほぼ完全に AWS 上で動作しています。 AWS Graviton processors を搭載した Amazon EC2 インスタンスを何万台も使用し、Epic Games は毎日世界中の何百万人ものプレイヤーをサポートしています。今年、Epic Games は AWS と協力し、 AWS Local Zones を通じてより多くの Fortnite プレイヤーをサポートしました （英語）。現在 AWS Local Zones 上で動作しているため、中部アメリカとメキシコのプレイヤーは、新しい北米中央 Fortnite リージョンで低レイテンシーのゲームプレイを体験できます。AWS では、ゲームプレイの機能とクラウドサービスが拡張していくにつれ、Fortnite のプレイヤーがどのようなことを実現するのか楽しみにしています。 チームの規模に関わらず、 Amazon GameLift を利用することで、セッションベースのマルチプレイヤーゲームのための専用のリアルタイムサーバーを提供できます。 開発者がサーバーの完全な制御とカスタマイズを必要とする場合でも、面倒なカスタムゲームサーバーのデプロイプロセスを省くことができる使いやすいゲームサーバーを必要とする場合でも、どちらでもAmazon GameLift はゲームのマーケットへのリリースを支援することができます。 リアルタイム 3D エクスペリエンスのユースケースがゲームから他のビジネス分野に広がるにつれ、 AWS for Games のソリューションを求める顧客が増えています。 当社のパートナーである Surreal Events は、AWS を利用してメタバースソリューションを拡張・スケーリングし、世界中の顧客に提供しています。 AWS を利用することで、あらゆる種類のリアルタイム 3D エクスペリエンスを構築する開発者は、仮想世界を拡大していくにつれて、エンドユーザーに大規模なコラボレーションをもたらすことができます。 未来のシミュレーション 近年、ほぼすべてのビジネス分野で、何らかの形でのシミュレーションが採用されるようになりました。ライフサイエンス、金融サービス、石油・ガス、設計、エンジニアリング、気候科学、自動運転などです。 システムがますます複雑になるにつれ、空間シミュレーションは、物理世界への洞察を提供する鍵となります。 過去には、空間シミュレーションは1つのハードウェアに制約されており、開発者にとってはほぼ不可能な課題でした。 このため、AWS は昨年、新しいシミュレーション専用サービスである AWS SimSpace Weaver を発表しました。 この新サービスにより、AWSの開発者は都市規模の 3D シミュレーションから洞察を得ることができます。 SimSpace Weaver は、コンピューティングインフラストラクチャー全体でシミュレーションを管理することで、クラウドで大規模な空間シミュレーションを簡単に実行できるようにします。 これにより、開発者はクラウドインフラストラクチャーのプロビジョニングとメンテナンスではなく、シミュレーションとアプリケーションの構築に集中できます。 さらに、SimSpace Weaver は、人気のあるリアルタイム 3D エンジンとの統合を提供するため、開発者は没入型でインタラクティブな体験を作り出すことができ、チームは実世界のシナリオをより良く理解することができます。 大規模な群衆シミュレーションのエキスパートである uCrowds 社との提携により、私たちは何百万ものシミュレートされた人間がネバダ州ラスベガスの通りを歩く実世界のシミュレーションの拡大、実行、可視化の可能性を示しました。この規模でシミュレーションを行うことで、私たちのチームは人口の急増が物理的な都市インフラに与える影響についてより良い理解を得ることができました。 AWS re:Invent 2022でのAmazonのCTO、Werner Vogelsの言葉 を言い換えると、私たちは物理的なものと仮想的なものとの境界線が曖昧になる中で、シミュレーションが重要であると考えており、開発者たちがあらゆるもののシミュレーションを始めることを願っています。 地理空間データを至る所で活用する 歴史を通じて、地図は新しいフロンティアを定義する上で重要な役割を果たしてきましたが、空間コンピューティングの強化により、これからもその役割を続けるでしょう。相互接続された私たちの世界では、地図は商品やサービスのルート、場所、フェンスを定義します。ビジネスが都市をナビゲートし、荷物を追跡し、車両やラストワンマイルを配送する自動運転ロボットのルートを設定する際、地図が提供する地理空間データはますます重要になっています。 2021 年、AWS は Amazon Location Service を発表しました。これは、地図、興味のあるポイント、ジオコーディング、ルーティング、トラッキング、ジオフェンシングをアプリケーションに簡単かつ安全に追加できる完全に管理されたサービスで、データのセキュリティ、ユーザーのプライバシー、またはコストを妥協することなく提供します。Amazon Location には、地図ベースの可視化、リソースの追跡、配送、ジオマーケティングによる場所を意識したユーザーのエンゲージメントなど、様々なユースケースのための位置機能が追加されました。 AWSは地図にとどまりません。アプリケーションに高い理解、洞察、および文脈に応じた情報をもたらすために、AWSは Amazon SageMaker も拡張し、開発者が地理空間データを使用して、機械学習モデルをより速く構築、トレーニング、デプロイできるようにしました。 AWS の Open Data Program と組み合わせることで、テラバイト単位のオープンソースの LiDAR ポイントクラウドデータを使用して、新しい地理空間ワークロードのための AI/ML モデルをトレーニングすることができます。自動運転車のフリート、配送ロボットのトレーニング、または物理世界からの洞察を得たい場合であっても、 Amazon SageMaker での地理空間ML は、開発チームが地理空間データを分析し、インタラクティブな地図を使用して 3D で強化されたグラフィックでモデル予測を探索することを可能にします。 空間コンピューティングにより、次世代のアプリケーションは私たちの周囲の物理的世界に対して、より深い洞察と文脈データをもたらすでしょう。Amazon Location や SageMaker などの AWS サービスは、すでに開発者によって使用されており、私たちの仮想世界を物理的な世界にオーバーレイしています。 更なるイノベーションへ 空間の革命はすでに進行中で、AWS のお客様によって、あらゆる規模やビジネスラインで主導されています。3D の文脈データと AWS クラウドのパワーとスケールにより、私たちの仮想世界と物理世界はシームレスに組み合わされ、働き方、生活、遊び方の変革を促進しています。AI/ML がよりアクセスしやすくなるにつれて、 AWS 上の生成 AI サービス を使えば、誰もがクリエイターになり、3D 仮想コンテンツで物理世界を拡張することができるでしょう。 3D コンテンツ作成、ゲーム、シミュレーション、地理空間という 4 つのテクノロジーセグメントを通じて、AWS は開発者と協力して未来を形作っています。AWS チームが未来を見据える中で、私たちは新しいツールやクラウドサービスを開拓し、技術革新の次のフロンティアに挑戦し、世界中の開発者が未来を構築することを支援することを目指しています。 著者について Chris Lee Chris Lee は AWS の没入型テクノロジー部門のディレクターでありGMです。彼は、AWS 上で大規模な空間コンピューティング体験を構築するために、レンダリング、VFX、ゲーム、シミュレーション、地理空間サービスの構築に注力しています。この役割に就く前、Chris は 20 年以上にわたりゲーム業界で複数の AAA ゲームを構築してきました。 翻訳はソリューションアーキテクトの阿南が担当しました。原文は こちら です。

AWS Resilience Hub  は、アプリケーションにおけるレジリエンスの定義、追跡、管理を支援するために設計された AWS サービスです。このサービスでは、 AWS Well-Architected  のベストプラクティスを使用してワークロードのレジリエンスを理解し、改善するのに役立ちます。また、レジリエンスと運用上の推奨事項の両方を提供することで、お客様は目標復旧時点 (RPO) と目標復旧時間 (RTO) に関する組織およびワークロード毎の要件を一貫して満たすことができます。 このブログ記事では、レジリエンスのための責任共有モデルと、それが AWS Resilience Hub サービスを使用する際の考慮事項にどのように影響するかを見ていきます。 責任共有モデル レジリエンスのための責任共有モデル について詳しく知りたい場合は、ホワイトペーパー「 AWS におけるワークロードのディザスタリカバリ : クラウドにおける復旧 」を読むことをお勧めします。以下の図は、お客様と AWS が共有する責任を示しています。AWS はクラウドのレジリエンスに責任を負い、お客様はクラウドにおけるレジリエンスに責任を負います。 図 1 – レジリエンスは AWS とお客様が分担する責任 このモデルでは、お客様が AWS Resilience Hub サービスを使用する際に配慮すべき、レジリエンスの推奨事項と運用上の推奨事項、という点を表しています。以下では、 Resilience Hub ワークショップ で用いられているアーキテクチャから具体例を取り上げて、これらのさまざまな側面について説明します。アーキテクチャや AWS Resilience Hub の使用方法に関する詳細情報や自習用の手順については、ワークショップのガイドに従ってください。 図 2 – AWS Resilience Hubワークショップのアーキテクチャ例 ここで使用されているアーキテクチャは、Application Load Balancer、EC2 Auto Scaling グループ内の EC2 インスタンス群、および RDS データベースで構成される 3 層アーキテクチャです。EC2 インスタンスは NAT ゲートウェイ経由のアウトバウンド接続が可能で、アプリケーションの静的コンテンツは S3 バケットに保存されます。 レジリエンスの推奨事項 AWS Resilience Hub でアプリケーションを評価した後、このサービスでは、設定した RTO/RPO の目標を達成するために、アーキテクチャ内のさまざまなワークロードコンポーネントにわたってレジリエンスの推奨事項を多数提示してくれます。すべてのRTO/RPOポリシーを実現するには、すべてのコンポーネントに関する推奨事項に取り組む必要があります。AWS Resilience Hub サービス内で管理できる潜在的な障害タイプの全リストは、 レジリエンスポリシーの管理 ドキュメントに記載されています。本ブログ記事では、ワークロードのデータベースに関するオプションの 2 つの推奨事項に焦点を当てます。オプション 1 は最小限の変更とコストの両方を最適化し、オプション 2 はアベイラビリティーゾーン障害時における最短の RTO/RPO を実現するように最適化します。お客様は、組織とワークロードの RTO/RPO のニーズを満たすために、どのオプションを採用するかについて、アーキテクチャ上の決定を下す必要があります。どちらのオプションも、AWS Resilience Hub で定義されているアプリケーションの設定されたポリシーを満たします。 図 3 – データベースのレジリエンスに関する推奨事項 この例では、オプション 1 を実装することを決定しました。ご覧のとおり、データベースはすでに RTO と RPO のレジリエンスポリシーを満たしていますが、新しい評価では、アベイラビリティーゾーン障害時における RTO/RPO をさらに最適化することが推奨されています。つまり、必要に応じてさらに最適化した RTO/RPO を実現できるということです。 図 4 – 推奨事項を実装した後のデータベースのレジリエンスに関する推奨事項 運用上の推奨事項 アラーム ここでは、運用上の推奨事項に含まれるアラームセクションにおける、2 つのお客様の責任部分を見ていきます。 推奨アラームに必要な追加設定 推奨エンジンでカバーされないアラーム条件 推奨アラームに必要な追加設定 AWS Resilience Hub が推奨する推奨アラームの中には、追加の設定が必要なものがあります。以下の例では、対象の Amazon CloudWatch アラーム  には CloudWatch Synthetics が必要であることがわかります。CloudWatch Synthetics を使用して、スケジュールに従って実行される設定可能なスクリプトであるカナリアを作成し、エンドポイントと API をモニタリングできます。正確な要件の詳細は、以下に示すように「前提条件」セクションに記載されています。 推奨エンジンではカバーされないアラーム条件 レジリエンス評価を実行する場合、AWS Resilience Hub はアプリケーションのレジリエンスをモニタリングするために Amazon CloudWatch アラームを設定することを推奨しています。これらのアラームは完全ではないため、アプリケーションの監視ニーズを十分に検討して、アプリケーションを完全に監視できるようにする必要があります。ベストプラクティスを満たすためのガイドとして、AWS Well-Architected フレームワーク ( REL 6 : ワークロードリソースをどのように監視していますか？ ) を使用できます。 図 5 – アラームの前提条件 標準操作手順 (SOP) SOPは、障害やアラームが発生した場合にアプリケーションを効率的に復旧するために設計された規範的な一連の手順です。AWS Resilience Hub は、アプリケーションコンポーネントに基づいて、準備すべき SOP を推奨します。 アプリケーションごとに要件が異なるため、AWS Resilience Hub が提供するデフォルトの AWS Systems Manager (SSM) ドキュメントのリストでは、すべてのニーズに対応できるわけではありません。ただし、デフォルトの SSM ドキュメントをコピーして、それをベースとして使用して、アプリケーションに合わせた独自のカスタムドキュメントを作成することはできます。 ドキュメントをコードベースに直接追加し、そこですべての変更を加えることで、最新のSOPをインフラストラクチャとともに確実にデプロイできます。 AWS Fault Injection Service (FIS)  の実験と SSM ドキュメントを組み合わせ、CI/CD パイプラインで実行することで、SOP がワークロードに対して継続的にテストされていることがわかります。 運用準備状況レビュー (ORR) の一環として SOP レビューし、アプリケーションのニーズに合った最新の手順が整っていることを確認する必要があります。ORR のホワイトペーパーを確認して、その内容の詳細な概要を確認してください。 ORR カスタムレンズに関するブログ で説明されているように、 AWS Well-Architected ツール を使用して ORR カスタムレンズを使用することもできます。これがどのように Well-Architected フレームワークと適合するかについては、運用上の優秀性の柱に含まれる OPS07-BP02 運用準備状況の一貫したレビュー を参照してください。 Fault Injection Service (FIS) を用いた実験 ここでは、運用上の推奨事項に含まれる FIS セクションを見る際に、3 つのお客様の責任部分を見ていきます。 推奨される FIS 実験に必要な追加設定 推奨エンジンでカバーされていない FIS 要件 依存システムの網羅 推奨される FIS 実験に必要な追加設定 AWS Fault Injection Service (FIS) は、アプリケーションのパフォーマンス、可観測性、レジリエンスを向上させるための障害注入実験を実行する完全マネージド型のサービスです。障害注入実験を実行して、AWS リソースのレジリエンスと、アプリケーション、インフラストラクチャ、アベイラビリティーゾーン、および AWS リージョンの障害からの回復にかかる時間を測定できます。レジリエンスを測定するために、これらの障害注入実験では AWS リソースの中断をシミュレートします。中断の例としては、ネットワークが使用できないエラー、フェイルオーバー、EC2 Auto Scaling グループでのプロセスの停止、Amazon RDS でのブートリカバリ、アベイラビリティーゾーンの問題などがあります。障害注入実験が終了したら、アプリケーションがレジリエンスポリシーの RTO ターゲットに定義されている割り込みタイプから回復できるかどうかを判断できます。 AWS Resilience Hub が推奨する FIS 実験の中には、追加の設定が必要なものもあります。以下の例では、この FIS を用いた実験 には既存の CloudWatch アラーム が必要であることがわかります。正確な要件の詳細は、AWS Resilience Hub からの通知に記載されています。 図 6 – 追加の FIS 設定 推奨エンジンでカバーされていない FIS 要件 AWS Resilience Hub でリストされている実験はすべてを網羅しているわけではありません。利用可能な実験をワークロード要件と照らし合わせて評価する必要があります。この例では、S3、Auto Scaling グループ、RDS の実験の推奨事項と、ロードバランサーに対するネットワーク実験があります。他に実行したい実験があるかもしれません。たとえば、アプリケーションが EBS の一時的な I/O 停止 をどのように処理するかを確認したい場合があります。 図7 – FISの実験 依存関係の網羅 最後に、ワークロードは組織内の他の依存関係に依存している可能性があります。レジリエントなシステムを構築するためにどのような実験が必要かについて、依存するチーム間で交渉する必要があります。AWS Resilience Hub は、関連する個々のワークロードに関する実験を推奨できますが、実験の依存関係の側面については、お客様が適切に評価して実装する必要があります。その良い例が、Well-Architected の運用上の優秀性の柱である OPS04 にあります。 オペレーショナル・インテグレーション 上で説明した考慮事項に加えて、その他の考慮事項がいくつかあります。 その他の運用要件 前のセクションで説明したように、AWS Resilience Hub の運用上の推奨事項はすべてを網羅しているわけではありません。追加のアラーム、SOP、FIS 実験が必要な場合、AWS Resilience Hub の外部でこれらを作成して維持するのはお客様の責任です。 テンプレートを使用して個別ではなくワークロード単位に統合する AWS Resilience Hub による運用上の推奨事項はアプリケーション単位に統合される必要があります。ハードコーディングされたリソースは、顧客チームにより動的なものに置き換えることができます。AWS Resilience Hubのドキュメントには、その方法を概説した CloudFormation の例が掲載されています ( AWS CloudFormation を使用して運用上の推奨事項をアプリケーションに統合する ) 。 標準化されたレジリエンス戦略の出発点としてテンプレートを使用する レジリエンス導入の第一歩として AWS Resilience Hub を使用している場合は、プラクティスを標準化することが重要です。アラーム、SOP、FIS 実験は、個々のチームだけでなく組織全体のレジリエンス戦略の一部となるはずです。既存の ORR または開発中の ORR に AWS Resilience Hub を含めると、レジリエンスの戦略を定義するのに役立ちます。 新しい推奨事項を継続的に確認する レジリエンスと運用の両方に関する新しい推奨事項は、サービスが拡大し、追加の AWS サービスのサポートが追加されるにつれて、定期的に AWS Resilience Hub に追加されます。定期的な ORR の一環として、ワークロードの要件を継続的に評価して見直すことは、お客様の責任です。これには、AWS Resilience Hub の追加機能が含まれます。AWS Resilience Hub のアプリケーション耐性スコアを追跡することで、アラーム、SOP、FIS 実験が定期的にテストされているかどうかもわかります。詳細については、このブログ記事「 AWS Resilience Hub スコアの使用方法 」を参照してください。 結論 AWS Resilience Hub を使用すると、レジリエンスの取り組みのさまざまな段階にいるお客様が、ワークロードとアプリケーションのレジリエンスを定義、追跡、管理できるようになります。お客様は、組織とワークロードの期待に応えるだけでなく、クラウドにおけるレジリエンスに対する責任もカバーするために、AWS Resilience Hub の推奨事項に加えて、どのような追加要件やリソースを実装する必要があるかを定義する必要があります。 Jamie Ibbs Jamie Ibbs は AWS のスペシャリスト テクニカルアカウントマネージャです。彼は、特に管理やガバナンス、レジリエンシーに興味を持ち、お客様が大規模に運用できるよう支援しています。 翻訳はソリューションアーキテクトの松本が担当しました。原文は こちら です。

このブログは Sam Mokhtari, Dr. Ali Khoshkbar, Sandipan Bhaumik によって執筆された内容を翻訳したものです。原文は こちら を参照して下さい。 このブログシリーズの第一部「 持続可能性の為のモダンデータアーキテクチャ最適化 : 第一部 – データ取り込みとデータレイク 」では、 モダンデータアーキテクチャ における 1) データ取り込み、2) データレイクの柱に焦点を当てました。このブログ記事では、3) 統合データガバナンス、4) データ移動、5) 目的別分析の柱に含まれるコンポーネントを最適化するためのガイダンスとベストプラクティスを紹介します。 図 1 は、モダンデータアーキテクチャのさまざまな柱を示しています。これには、データ取り込み、データレイク、統合データガバナンス、データ移動、および目的別分析の柱が含まれます。 図 1. AWS のモダンデータ分析リファレンスアーキテクチャ 3. 統合データガバナンス 一元化されたデータカタログは、ストレージレイヤーのデータセットに関するビジネスのメタデータとテクニカルメタデータを保存する役割を担います。管理者はこのレイヤーに権限を適用し、セキュリティ監査のイベントを追跡します。 データディスカバリー データ共有を増やし、データの移動や重複を減らすには、様々なユーザーペルソナに対してデータ検出と明確なアクセス制御を可能にする必要があります。これにより、重複するデータ処理のアクティビティが減ります。組織内の各チームが、この一元化されたカタログを利用することができます。ファーストパーティデータ (売上データなど) またはサードパーティデータ (株価、気候変動のデータセットなど) を提供します。ソースから繰り返しデータを取得する必要はなく、データへのアクセスは 1 回だけで済みます。 AWS Glue データカタログでは、メタデータの追加と検索のプロセスを簡素化できます。AWS Glue クローラーを使用して既存のスキーマを更新し、新しいデータセットを発見します。スケジュールを慎重に計画して、不要なクロールを減らしてください。 データ共有 AWS Lake Formation などのサービスを使用して、様々なデータコンシューマー向けに明確に定義されたアクセス制御メカニズムを確立します。これにより、きめ細かなアクセス制御で組織単位の間でデータセットを共有できるようになり、重複するコピーや移動が減ります。 Amazon Redshift データ共有 を使用すると、データウェアハウス間でデータをコピーする必要がなくなります。 明確に定義されたデータセット 明確に定義されたデータセットと関連するメタデータを作成して、不必要なデータ処理や操作を回避します。これにより、追加のデータ操作に起因するリソース使用量を削減できます。 4. データ移動 AWS Glue は、サーバーレスで 従量課金制 のデータ移動機能を提供します。サーバーやクラスターを立ち上げて管理する必要はありません。数十テラバイトのデータを処理できる ETL パイプラインを設定します。 パフォーマンスを犠牲にすることなくアイドル状態のリソースを最小限に抑えるには、 AWS Glue の Auto Scaling を使用してください。 ユースケース ごと に AWS Glue ワークフローを作成するのではなく、 AWS Glue ブループリント を使用することで、同様のユースケースの AWS Glue ワークフローを作成して共有できます。 AWS Glue ジョブブックマーク は、以前に処理されたデータを追跡できます。 本番前のジョブ、テスト、1 回限りのデータロードなど、緊急性が低い、または時間に左右されないデータ統合ワークロードには、 Glue Flex ジョブ の使用を検討してください。Flex では、AWS Glue ジョブは専用のハードウェアではなく、予備のコンピューティング能力で実行されます。 複数のデータフレーム間の結合は、Spark ジョブでは一般的な操作です。ノード間のデータのシャッフルを減らすには、マージされたデータフレームの 1 つが実行中のすべてのノードで複製できるほど小さい場合、 broadcast joins を使用します。 最新の AWS Glue バージョン では、ワークロードにさらに多くの新しい効率的な機能が提供されています。 5. 目的に合わせた分析 データ処理モード リアルタイムデータ処理オプションには、継続的にコンピューティングリソースを使い、より多くのエネルギー消費が必要です。持続可能性を最大限に高めるには、トレードオフを評価し、最適なバッチデータ処理のオプションを選択してください。 バッチおよびインタラクティブなワークロードの要件を特定し、 Amazon EMR で 一時的なクラスター を設計します。スポットインスタンスを使用し、 インスタンスフリート を設定することで、使用率を最大化できます。 エネルギー効率を向上させるために、 Amazon EMR Serverless を使用すると、データ処理のジョブにリソースを過剰にプロビジョニングしたり、プロビジョニングが不十分になったりすることを回避できます。Amazon EMR Serverless は、アプリケーションが必要とするリソースを自動的に判断し、これらのリソースを収集してジョブを処理し、ジョブが終了するとリソースを解放します。 Amazon Redshift RA3 ノード はコンピューティング効率を向上させることができます。RA3 ノードでは、ストレージを拡張せずにコンピューティングをスケールアップまたはスケールダウンできます。 Amazon Redshift Serverless を選択すると、データウェアハウスの容量をインテリジェントにスケーリングできます。これにより、最も要求が厳しく予測不可能なワークロードでも、より高速なパフォーマンスを実現できます。 エネルギー効率の高い変換とデータモデル設計 データ処理とデータモデリングのベストプラクティスは、組織の環境への影響を軽減できます。 Amazon Redshift クラスター内のノード間での不必要なデータ移動を避けるため、 テーブル設計のベストプラクティス に従ってください。 Amazon Redshift の 自動テーブル最適化 (ATO) を使用して、使用パターンに基づいてテーブルを自動調整することもできます。 Amazon Athena または Amazon Redshift の EXPLAIN 機能を使用して、クエリを調整および最適化します。 Amazon Redshift Advisor は、パフォーマンス統計と運用データに基づいてデータウェアハウスを最適化するための具体的でカスタマイズされた推奨事項を提供します。 Amazon EMR または Amazon OpenSearch Service を、 AWS Graviton などの電力効率の高いプロセッサに移行することを検討してください。 AWS Graviton 3 は、他の CPU と比較して 2.5 ～ 3 倍のパフォーマンスを実現しています。Graviton 3 ベースのインスタンスは、同等の EC2 インスタンスと同じパフォーマンスで消費電力が最大 60% 少なくなります。 アイドルリソースを最小化 EMR クラスター の auto scaling を使用するか、 Amazon Kinesis Data Streams On-Demand を採用して、パフォーマンスを犠牲にすることなくアイドル状態のリソースを最小限に抑えます。 AWS Trusted Advisor は、十分に活用されていない Amazon Redshift クラスター を特定するのに役立ちます。使用していないときは Amazon Redshift クラスターを一時停止し、必要に応じて再開します。 エネルギー効率の高い消費パターン データを Amazon Redshift にコピーするのではなく、Amazon Athena または Amazon Redshift Spectrum を使用してその場でデータをクエリして 1 回限りの分析を行うことを検討してください。 必要に応じて、 頻繁にクエリを実行できるようにキャッシュレイヤー を有効にします。これは、Amazon Redshift などのサービスに組み込まれている result caching に追加されるものです。また、ソースデータが頻繁に変更されないすべてのクエリには、 Amazon Athena Query Result Reuse を使用してください。 Amazon Redshift または Amazon Aurora PostgreSQL で利用できる マテリアライズドビュー機能 を使用して、不必要な計算を回避してください。 Amazon Athena フェデレーテッドクエリ または Amazon Redshift フェデレーテッドクエリ を利用し、データストア全体でフェデレーテッドクエリを使用すると、データ移動を減らすことができます。個別の Amazon Redshift クラスター間でクエリを実行する場合は、これらのクラスター間のデータ移動を減らす Amazon Redshift データ共有 機能の使用を検討してください。 環境の持続可能性の為の改善追跡と評価 持続可能性に向けたワークロード最適化の成功を評価する最適な方法は、 プロキシメトリクスと作業単位の KPI を使用することです。これは、ストレージの場合は 1 トランザクションあたりの GB 数、コンピューティングの場合は 1 トランザクションあたりの vCPU 分です。 表 1 には、改善の度合いを測るメトリクスとして、分析サービスで収集できる特定のメトリクスが示されています。これらは、この記事で取り上げた最新のデータアーキテクチャの各柱に該当します。 柱 メトリクス 統合データガバナンス CloudTrail events – for monitoring crawler runs and job runs データ移動 DPU-hour for AWS Glue jobs 目的別分析 Redshift cluster performance data – CPUUtilization, percentage disk space used, read throughput, write throughput, query duration, query throughput Redshift query history (optimize queries) – query runtime, CPUUtilization, storage capacity used Amazon Redshift Spectrum queries – System views: SVL_S3QUERY, SVL_S3QUERY_SUMMARY CloudWatch metrics for Amazon EMR – IsIdle, HDFSUtilization, S3BytesRead, S3BytesWritten CloudWatch metrics for Amazon OpenSearch (Cluster metrics) – CPUUtilization, FreeStorageSpace, ClusterUsedSpace, JVMMemoryPressure, DiskThroughputThrottle CloudWatch metrics for Amazon Athena – ProcessedBytes, QueryQueueTime, TotalExecutionTime CloudWatch metrics for Amazon SageMaker – CPUUtilization, GPUUtilization, GPUMemoryUtilization, MemoryUtilization, and DiskUtilization Kinesis Data Analytics application metrics – CPUUtilization, containerCPUUtilization, containerDiskUtilization, idleTimeMsPerSecond テーブル 1. モダンデータアーキテクチャの柱となるメトリクス まとめ このブログ記事では、モダンアーキテクチャの統合データガバナンス、データ移動、目的別分析の柱の下でプロセスを最適化するためのベストプラクティスを紹介しました。 詳細を知りたい場合は、 AWS Well-Architected Framework の持続可能性の柱 や、 持続可能性のためのアーキテクチャ に関するその他のブログ投稿をご覧ください。 アーキテクチャに関するその他のコンテンツをお探しの場合は、 AWS アーキテクチャセンター を参照して、リファレンスアーキテクチャ図、精査されたアーキテクチャソリューション、 Well-Architected のベストプラクティス、パターン、アイコンなどを確認してください。 Sam Mokhtari Sam Mokhtari 博士は、AWS Well-Architected Framework の持続可能性の柱を主導しています。彼の主な専門分野はデータと分析であり、この分野で 30 以上の影響力のある記事を発表しています。 Dr. Ali Khoshkbar Ali Khoshkbar 博士は、アマゾンウェブサービス (AWS) プロフェッショナルサービスのシニアクラウドアーキテクトです。彼は、顧客がクラウド上でスケーラブルで高性能なデータ分析ソリューションを構築できるよう支援することに情熱を注いでいます。 Sandipan Bhaumik Sandipan Bhaumik は、ロンドンを拠点とするシニア分析スペシャリストソリューションアーキテクトです。彼は、クラウド内に最新のデータアーキテクチャを構築して大規模な分析を実行することで、顧客が従来のデータプラットフォームを最新化できるよう支援しています。 このブログは、ソリューションアーキテクトの福田哲也が翻訳しました。

一般的な SaaS におけるテナント分離戦略や実装例は、AWS ホワイトペーパー SaaS アーキテクチャの基礎 や builders.flash の記事「 SaaS on AWS を成功に導くためのポイントとは ? 」や AWS Well-Architected フレームワーク SaaS レンズ において紹介されています。 最近では、地方公共団体や医療等の高いセキュリティレベルが求められる業界にクラウドが普及してきたこともあり、閉域でのマルチテナント設計のニーズも増えてきています。例えば、自治体の基幹システムの実装では総務省が示す「地方公共団体における情報セキュリティポリシーに関するガイドライン」及びデジタル庁が示す「地方公共団体情報システム非機能要件の標準」に準拠したセキュリティ対策を施す必要があります。 また、政府共通のクラウドサービスの利用環境である ガバメントクラウド では、複数の地方公共団体の環境を1つのベンダで管理する、共同利用方式が推奨されています。さらに、共同利用方式において、団体 (テナント) 間の環境分離方式についてはアカウント分離、ネットワーク分離、アプリケーション分離等による分離手法の検証が行われています。その中でもアプリケーション分離はコスト効率が良いテナント間の分離手法と言われています。 一方、閉域網でのアプリケーション分離による、いわゆる SaaS の実装例やサンプル情報はまだ少ないのが実情です。 そのため、今回パブリックセクターのソリューションアーキテクトが、 閉域網でのマルチテナントアプリケーションのサンプルテンプレート を公開しました。本テンプレートは前述の AWS Well-Architected フレームワーク SaaS レンズ で定義されている、 ブリッジモデル を採用しています。 技術要素としては、 AWS PrivateLink や Nuxt 、 Keycloak を採用しているため、閉域での SaaS の実装を検討している方をはじめ、ガバメントクラウドにおいてアプリケーション分離を検討されている方、Keycloak on AWSに関心がある方にご参考いただけます。 ソリューション概要 テナント分離の詳細は SaaS ビジネスの成否を分けるテナント分離戦略 に記載がありますが、大きく分けると以下の3パターンです。 サイロ分離 プール分離 ブリッジモデル 本テンプレートではブリッジモデルを採用した以下のアーキテクチャとなっており、Multi-tenancy環境とConsumer環境を各々の Amazon VPC にデプロイすることが可能です。 Consumer VPCとMulti-tenancy VPC間の通信は、 Amazon Route53 とAWS PrivateLinkを利用して閉域接続しており、WebアプリケーションはNuxtで実装しています。認証に関しては、Keycloakを利用して各Consumer VPCにあるActive directoryに対してLDAP認証させ、後述するサブドメイン情報で各Consumerのページにルーティングしています。 通信の整理 本テンプレートでは、下図のように VPC 間で 3 つの経路による通信が必要となります。 ①端末からアプリケーションサーバへの通信、②端末から認証認可サーバへの通信、③認証認可サーバから Active Directory への通信 です。 団体間の環境をアカウント分離方式・ネットワーク分離方式で分離する場合、団体ごとに CIDR を設計できるため、各団体のネットワーク環境の CIDR と重複できないような設計ができ、 AWS Transit Gateway によるシステム間通信を行うことができます。 一方、アプリケーション分離方式を採用する場合、同じ VPC に複数の団体からアクセスされるため、CIDR 重複が起こり、Transit Gateway では正しく通信が行えなくなります。 そのため、今回は各団体の環境 (Consumer VPC) とアプリケーション環境 (Multi-tenancy Environment VPC) で双方向に Private Link を利用することで、CIDR 重複が起きていてもシステム間連携を行えるような実装にしています。 PrivateLink の詳細については AWS PrivateLink の概要 をご参照ください。 アプリケーションの設計 本構成におけるロードバランサー・アプリケーションコンテナのテナント分離について説明します。 本構成では、 Elastic Load Balancer(ELB) に Network Load Balancer を採用しています。 Application Load Balancer(ALB) はPrivateLink のターゲットに対応しておらず、機能的にも NLB で充足するためです。 一般的なブリッジモデルでは、NLB は団体間で共用するケースが多く見られます。自治体の要件として他自治体のアプリケーション画面が見えてはならないケースが想定されるため、本構成ではNLBを共用する構成(Shared NLB)の他、NLB を団体ごとに分離し、Endpoint によって制限をかけ、他自治体のアプリケーション画面に到達できないような構成 (Dedicated NLB)も選択できるようになっています。 テナントごとにアプリケーション画面を出し分ける方法として、テナントごとにパスを分ける ( https://domain/a-corp/ ) 設計や、ホスト名を分ける ( https://a-corp.domain/ ) 設計が考えられますが、今回は他自治体の他自治体のアプリケーション画面に到達できないようにするため、テナントごとにサブドメイン・ NLB を分け、コンテンツもサブドメインを元に出し分けています。具体的には、アプリケーションコンテナでは、アクセス元のサブドメインを元に、表示するコンテンツ・認証認可サーバの URL を使い分けています。一方で、アプリケーションコンテナに関しては複数のテナントで共用しており、コスト効率がよい設計となっています。 a-corp.xxxx.xxxx でアクセスした時のページ b-corp.xxxx.xxxx でアクセスした時のページ DB設計 本構成におけるデータベースのテナント分離について説明します。 本テンプレートでは自治体の基幹システムで採用されることが多いため、データベースエンジンとして PostgreSQL を、AWS のサービスとして Amazon Aurora Serverless を選定しています。 団体間の分離方式として、テナントごとにそれぞれ RDS インスタンスを用意し、それぞれのインスタンス内にテナント固有のデータベースを作成するサイロモデルを採用しています。理由としては、団体ごとに利用する暗号鍵を分けられるため暗号鍵消去が容易なことや、自治体によっては他団体とデータベースのインスタンスを分けるようなセキュリティポリシーを定めている場合があることから、サイロモデルを選定しました。 他にも様々なデータベースの分離方式があり、 SaaS におけるデータパーティショニング設計の勘所 で詳しく解説を行っています。 上記で挙げた観点以外でも、個別の専用環境を用意するコストはどれくらいか、団体間でリソース共有 (インスタンス共有) する場合はノイジーネイバーにどういう対策を行うかなど、多方面から検討を行う必要があります。 また、テンプレートの実装では RDS Proxy を採用していますが、アプリケーションが利用するコネクション数が多くない場合は RDS Proxy を利用せず、直接データベースへ接続する実装も考えられます(RDS Proxyを利用しない場合は、 config.ts のenableProxyをfalseに設定)。 認証 本構成における認証認可サーバの実装について説明します。 本テンプレートでは、認証認可サーバに Keycloak を採用しています。自治体の基幹システムの認証認可サーバでは、一般的な認証認可サーバが兼ね備えている機能の他、いくつかの追加の要件を満たすことが重要となります。 まず、「地方公共団体における情報セキュリティポリシーに関するガイドライン」に則るため、閉域でのアクセスに対応できることが必要となります。加えて、自治体の基幹システムにおいては認証認可サーバはユーザ認証機能だけでなく、システム間連携で利用される API の認証認可でも利用される可能性があります。その際「地方公共団体情報システム共通機能標準仕様書」に記載のある要件を満たす認証認可サーバを用意する必要がありますが、その要件も Keycloak で満たすことができるため、本テンプレートでは Keycloak を採用しました。 また、シングルサインオン (SSO) の実現には Open ID Connect (OIDC) を使用しています。OIDC は、安全かつ効率的な認証方法を提供し、ユーザー体験を向上させます。これにより、ユーザーは一度のログインで複数のサービスやアプリケーションにアクセスでき、作業効率が向上します。 既存 ID 管理システムの連携としては、自治体では既に ID 管理システムとして Active Directory を用いていることが多いため、LDAP を介して Active Directory と連携する実装としています。この連携により、既存の ID 管理システムをそのまま利用し、新しい認証システムへの移行をスムーズに行うことができます。 Keycloak は複数のテナントで共用し、 realm をテナントごとに分離する構成としています。 Webアプリケーション WebアプリケーションはNuxt( v3.8.2 )で実装し、コンテナ実行環境である AWS Fargate で稼働させ、 Amazon ECS でコンテナ環境を管理しています。アプリケーションのAPIは server/api で定義し、 useFetch でDatabaseへのデータ取得/登録を行なっています。今回は単純処理のためAPIのロジックをNuxtのserver/api側で全て実装しましたが、 AWS Lambda Function URLs や別のコンテナ環境で実装したWeb APIのエンドポイントを useFetch で利用することも可能です。Nuxtのデータフェッチに関しては こちら を参照ください。また、ルーティングに関しては、まずサブドメインを元に適切なKeycloakのrealmにルーティングし、 router options を利用しており各Pageへのルーティングを実現させています。 まとめ 本ブログでは、閉域網でのマルチテナントアプリケーションについて、テナント分離や実装内容について説明いたしました。本テンプレートはKeycloakでの認証方式を採用しているため、閉域網での実装に関心のある方だけではなく、Amazon ECS + AWS Fargateを利用したKeycloakのコンテナ実装に関心のある方にも参考になれば幸いです。 テンプレートのコードは aws-samples に公開しております。 著者について 松本 侑也 (Yuya Matsumoto) は、Public Sector 自治体担当のソリューションアーキテクトです。最近ではガバメントクラウドへの基幹システムの移行や、生成系AIの活用支援を中心に活動しています。       小泉 秀徳(Hidenori Koizumi) は、パブリックセクターのプロトタイピングソリューションアーキテクトです。最近のプロジェクトでは、生成系AIを活用したWebアプリケーション開発を行なっており、Next.jsやWebAssemblyに関心があります。

Protocol Buffers の概要 Protocol Buffers （Protobuf）は、構造化データをシリアル化するためのプラットフォームに依存しないアプローチを提供します。Protobuf は JSON に似ていますが、軽量で処理が速く、お好みのプログラミング言語でバインディングを自動的に生成できる点が異なります。 AWS IoT Core は、何十億もの IoT デバイスを接続し、何兆ものメッセージを AWS サービスにルーティングできるマネージドサービスです。これにより、アプリケーションを何百万ものデバイスにシームレスにスケーリングできます。AWS IoT Core と Protobuf の統合により、Protobuf の無駄のないデータシリアル化プロトコルと自動コードバインディング生成のメリットも得られます。 Protobuf コード生成による IoT のアジリティとセキュリティ Protobuf を利用する主な利点は、Protobuf によるコード生成を使用したソフトウェア開発の容易さと安全性です。アプリケーションのコンポーネント間で交換されるメッセージのスキーマの記述ができます。 protoc などのコード生成コンパイラが記述されたスキーマを解釈し、選択したプログラミング言語でのエンコードとデコード機能を実装します。Protobuf によるコード生成はメンテナンスが行き届いていて広く使用されているため、堅牢で実地試験済みのコードになっています。 自動コード生成により、開発者はエンコード関数やデコード関数を記述する必要がなくなり、プログラミング言語間の互換性が保証されます。 AWS IoT Core のルールエンジンによる Protocol Buffer メッセージング形式のサポートが新たに開始 されたことに伴い、C 言語 で記述されたプロデューサーアプリケーションをデバイス上で実行し、AWS Lambda 関数コンシューマーを Python で作成できるようになりました。これらはすべて生成されたバインディングを使用します。 AWS IoT Core で JSON よりも Protocol Buffers を使用するその他の利点は次のとおりです スキーマと検証: スキーマは送信者と受信者の両方によって適用され、適切な統合が確実に実現されます。メッセージは自動生成コードによってエンコードおよびデコードされるため、バグは排除されます。 適応性: スキーマは変更可能で、後方互換性と上位互換性を維持しながらメッセージコンテンツを変更できます。 帯域幅の最適化: 同じコンテンツでも、Protobuf を使用すると、ヘッダーではなくデータのみを送信するため、メッセージの長さが短くなります。時間が経つにつれて、デバイスの自律性が向上し、帯域幅の使用量が少なくなります。 メッセージングプロトコルとシリアル化形式に関する最近の調査 では、Protobuf 形式のメッセージは、同等の JSON 形式のメッセージよりも最大 10 倍小さいことが明らかになりました。つまり、同じコンテンツを伝送するためにネットワークを経由するバイト数が少なくなるということです。 効率的なデコード: Protobuf メッセージのデコードは JSON のデコードよりも効率的です。つまり、受信関数の実行時間が短くなります。 Auth0 が実施したベンチマーク では、Protobuf は同等のメッセージペイロードで JSON よりも最大 6 倍もパフォーマンスが高いことが明らかになりました。 このブログ記事では、Protobuf 形式を使用して AWS IoT Core にメッセージを公開するサンプルアプリケーションをデプロイする方法について説明します。その後、メッセージは AWS IoT Core ルールエンジンのルールによって選択的にフィルタリングされます。 Protobuf の基本をおさらいしてみましょう。 Protocol Buffers の概要 メッセージスキーマは Protobuf の重要な要素です。スキーマは次のようになります。 syntax = "proto3" ; import "google/protobuf/timestamp.proto" ; message Telemetry { enum MsgType { MSGTYPE_NORMAL = 0 ; MSGTYPE_ALERT = 1 ; } MsgType msgType = 1 ; string instrumentTag = 2 ; google . protobuf . Timestamp timestamp = 3 ; double value = 4 ; } C-like スキーマの最初の行は、使用している Protocol Buffers のバージョンを定義します。この記事では proto3 バージョンの構文を使用しますが、 proto2 もサポートされています。 次の行は、 Telemetry という新しいメッセージ定義が記述されることを示しています。 特にこのメッセージには、次の 4 つの異なるフィールドがあります。 msgType フィールド: MsgType 型で、「 MSGTYPE_NORMAL 」または「 MSGTYPE_ALERT 」の列挙子のみを指定可能 instrumentTag フィールド: string 型で、テレメトリデータを送信する計測器を識別 timestamp フィールド: google.protobuf.Timestamp 型で測定の時刻を示す value フィールド: double 型で計測値を示す 有効なすべてのデータ型と構文に関する追加情報については、 こちらのドキュメント を参照してください。 JSON 形式で記載された Telemetry メッセージは次のようになります。 { "msgType": "MSGTYPE_ALERT", "instrumentTag": "Temperature-001", "timestamp": 1676059669, "value": 72.5 } JSON Protocol Buffers (表示用に base64 でエンコード) を使用した同じメッセージは、次のようになります。 0801120F54656D70657261747572652D3030311A060895C89A9F06210000000000205240 メッセージの JSON 表現は 115 バイトであるのに対し、Protobuf では 36 バイトしかないことに注意してください。 スキーマが定義されると、 protoc を使用して次のことができます。 お好みのプログラミング言語でのバインディングの作成 AWS IoT Core が受信したメッセージをデコードするために使用する FileDescriptorSet の作成 AWS IoT Core での Protocol Buffers の利用 Protobuf は AWS IoT Core でさまざまな方法で使用できます。最も簡単な方法は、メッセージを バイナリペイロード として公開し、受信側のアプリケーションにデコードさせることです。これは AWS IoT Core ルールエンジンですでにサポートされており、Protobuf だけでなく、あらゆるバイナリペイロードで機能します。 ただし、Protobuf メッセージをデコードしてフィルタリングや転送を行う場合は、最大のメリットが得られます。フィルターされたメッセージは Protobuf として転送することも、JSON 形式しか認識しないアプリケーションとの互換性のために JSON にデコードすることもできます。 AWS IoT Core ルールエンジンが Protocol Buffers メッセージング形式をサポート したため、マネージドな機能を利用することでこれを実現できます。これより先のセクションでは、サンプルアプリケーションのデプロイと実行について説明します。 前提条件 こちらのサンプルアプリケーションを実行するには、次の条件を満たす必要があります。 protoc がインストールされたコンピュータ。 公式インストール手順 を参照してください。 AWS CLI のインストール。インストール手順は こちら を参照してください。 AWS アカウントと、Amazon S3、AWS IAM、AWS IoT Core、AWS CloudFormation に対するフルアクセス権限を持つ有効な認証情報 Python 3.7 以降のバージョン サンプルアプリケーション：Protobuf メッセージを JSON としてフィルタリングして転送 サンプルアプリケーションをデプロイして実行するには、次の 7 つの簡単なステップを実行します。 サンプルコードをダウンロードして Python の必要なパッケージをインストール IOT_ENDPOINT と AWS_REGION の環境変数を設定 protoc を使用して Python バインディングとメッセージ記述子を生成 Python と Protobuf で生成されたコードバインディングを使用してシミュレートされたデバイスを実行 AWS CloudFormation を使用して AWS リソースを作成し、Protobuf 記述子ファイルをアップロード Protobuf メッセージを照合、フィルタリング、JSON として再公開する AWS IoT ルールを確認 変換されたメッセージが再公開されていることを確認 Step 1：サンプルコードのダウンロードと Python の必要なパッケージのインストール サンプルアプリケーションを実行するには、コードをダウンロードして、その依存関係をインストールする必要があります。 まず、AWS github リポジトリからサンプルアプリケーションをダウンロードして抽出します https://github.com/aws-samples/aws-iotcore-protobuf-sample ZIP ファイルとしてダウンロードした場合は、解凍してください 必要な Python の依存関係をインストールするには、抽出したサンプルアプリケーションのフォルダー内で以下のコマンドを実行します。 pip install -r requirements.txt Bash 上記のコマンドを実行すると、 boto3 (Python 用 AWS SDK) と protobuf という 2 つの必要な Python 依存関係がインストールされます。 Step 2： IOT_ENDPOINT と AWS_REGION の環境変数の設定 シミュレートされた IoT デバイスは AWS IoT Core エンドポイントに接続して Protobuf 形式のメッセージを送信します。 Linux または Mac を実行している場合は、次のコマンドを実行します。 を必ず選択した AWS リージョンに置き換えてください。 export AWS_REGION = < AWS_REGION > export IOT_ENDPOINT = $( aws iot describe-endpoint --endpoint-type iot:Data-ATS --query endpointAddress --region $AWS_REGION --output text ) Bash Step 3： protoc を使用して Python バインディングとメッセージ記述子を生成 抽出されたサンプルアプリケーションには、前に示したスキーマの例に似た msg.proto という名前のファイルが含まれています。 以下のコマンドを実行して、シミュレートされたデバイスが記述子ファイルの生成に使用するコードバインディングを生成します。 protoc --python_out = . msg.proto protoc --include_imports -o filedescriptor.desc msg.proto Bash これらのコマンドを実施すると、次の2つのファイルが確認できます。 filedescriptor.desc msg_pb2.py Step 4：Python と Protobuf で生成されたコードバインディングを使用して、シミュレートされたデバイスを実行 抽出されたサンプルアプリケーションには、 simulate_device.py という名前のファイルが含まれています。 シミュレートされたデバイスを起動するには、以下のコマンドを実行します。 python3 simulate_device.py Bash AWS コンソールの MQTT テストクライアントを使用して、メッセージが AWS IoT Core に送信されていることを確認します。 AWS IoT Core サービスコンソール ( https://console.aws.amazon.com/iot ) にアクセスします。正しい AWS リージョンにいることを確認してください。 [テスト] で、[MQTT テストクライアント] を選択します。 トピックのフィルターに「 test/telemetry_all 」と入力します。 [追加設定] セクションを展開し、[MQTT ペイロード表示] で [未加工のペイロードを表示 (バイナリデータを 16 進値として表示)] を選択します。 [サブスクライブ] をクリックして、Protobuf 形式のメッセージが AWS IoT Core MQTT ブローカーに届くのを確認します。   Step 5：AWS CloudFormation を使用して AWS リソースを作成し、Protobuf 記述子ファイルをアップロード 抽出されたサンプルアプリケーションには、 support-infrastructure-template.yaml という名前の AWS CloudFormation テンプレートが含まれています。 このテンプレートは、Amazon S3 バケット、AWS IAM ロール、および AWS IoT ルールを定義します。 次のコマンドを実行して、CloudFormation テンプレートを AWS アカウントにデプロイします。必ず、 <YOUR_BUCKET_NAME> と <AWS_REGION> を S3 バケットと選択した AWS リージョンの名前に置き換えてください。 aws cloudformation create-stack --stack-name IotBlogPostSample \ --template-body file://support-infrastructure-template.yaml \ --capabilities CAPABILITY_NAMED_IAM \ --parameters ParameterKey = FileDescriptorBucketName,ParameterValue = < YOUR_BUCKET_NAME > \ --region = < AWS_REGION > Bash AWS IoT Core が Protobuf 形式のメッセージをサポートするには、protoc で生成した記述子ファイルが必要です。使用できるようにするために、作成した S3 バケットにアップロードします。以下のコマンドを実行して、記述子ファイルをアップロードします。 <YOUR_BUCKET_NAME> の値を CloudFormation テンプレートをデプロイするときに選択したのと同じ名前に置き換えてください。 aws s3 cp filedescriptor.desc s3://`<YOUR_BUCKET_NAME>`/msg/filedescriptor.desc Step 6: Protobuf メッセージを照合、フィルタリング、JSON として再公開する AWS IoT ルールを確認 こちらのBlogでは、危険な操作条件がある可能性があることを示している MSGTYPE_ALERT の msgType を持つメッセージをフィルタリングすることを考えます。CloudFormation テンプレートは、仮想デバイスが AWS IoT Core に送信している Protobuf 形式のメッセージをデコードする AWS IoT ルールを作成します。次に、アラートとなるメッセージを選択し、別の MQTT トピックとしてサブスクライブできるように JSON 形式で再公開 (再度パブリッシュ) する AWS IoT ルールを作成します。AWS IoT ルールを確認するには、次の手順を実行します。 AWS IoT Core サービスコンソールにアクセスする： https://console.aws.amazon.com/iot 左側のメニューの [メッセージのルーティング] で、[ルール] をクリックします。 ルールのリストには ProtobufAlertRule という名前の AWS IoT ルールが含まれています。クリックすると詳細が表示されます。 SQL ステートメントの下にある、下記 SQL ステートメントの記述を確認してください。各要素の意味については後ほど説明します。 [アクション] に AWS IoT トピックに再公開するアクションが一つあることを確認してください。 SELECT VALUE decode ( encode ( * , 'base64' ) , "proto" , "<YOUR_BUCKET_NAME>" , "msg/filedescriptor.desc" , "msg" , "Telemetry" ) FROM 'test/telemetry_all' WHERE decode ( encode ( * , 'base64' ) , "proto" , "<YOUR_BUCKET_NAME>" , "msg/filedescriptor.desc" , "msg" , "Telemetry" ) . msgType = 'MSGTYPE_ALERT' SQL   この SQL ステートメントは次の処理を行います。 SELECT VALUE decode(...) は、デコードされた Protobuf ペイロード全体が JSON ペイロードとして送信先の AWS IoT トピックに再公開されることを示します。メッセージを Protobuf 形式のまま転送したい場合は、これを単純な SELECT * に置き換えることができます WHERE decode(...).msgType = 'MSGTYPE_ALERT' は受信した Protobuf フォーマットのメッセージをデコードし、 msgType の値が MSGTYPE_ALERT となっているメッセージのみを転送します Step 7：変換されたメッセージが再公開されていることを確認 この AWS IoT ルールにあるアクションをクリックすると、メッセージが topic/telemetry_alerts トピックに再公開されることがわかります。  再公開先のトピックである test/telemetry_alerts は、サンプルアプリケーションの AWS CloudFormation テンプレート宣言されている AWS IoT ルールアクションの定義の一部です。 トピックをサブスクライブして JSON 形式のメッセージが再発行されるかどうかを確認するには、次の手順に従います。 AWS IoT Core サービスコンソールにアクセスする： https://console.aws.amazon.com/iot [テスト] で、[MQTT テストクライアント] を選択します。 トピックフィルターに test/telemetry_alert と入力します [追加設定] セクションを展開し、[MQTT ペイロード表示] で [JSON ペイロードを自動フォーマット (読みやすさが向上)] オプションが選択されていることを確認します。 [サブスクライブ] をクリックして、 msgType MSGTYPE_ALERT という JSON 形式に変換されたメッセージが届くことを確認してください 仮想デバイスで稼働するコードを調べると、メッセージの約 20% が MSGTYPE_ALERT タイプで、メッセージは 5 秒ごとに送信されていることがわかります。警告メッセージが届くまで待つ場合があります。 クリーンアップ このサンプルを実行した後にクリーンアップするには、以下のコマンドを実行します。 # delete the file descriptor object from the Amazon S3 Bucket aws s3 rm s3:// < YOUR_BUCKET_NAME > /msg/filedescriptor.desc # detach all policies from the IoT service role aws iam detach-role-policy --role-name IoTCoreServiceSampleRole \ --policy-arn $( aws iam list-attached-role-policies --role-name IoTCoreServiceSampleRole --query 'AttachedPolicies[0].PolicyArn' --output text ) # delete the AWS CloudFormation Stack aws cloudformation delete-stack --stack-name IotBlogPostSample Bash まとめ 今回の Blog でご紹介したように、AWS IoT Core で Protobuf を操作するのは、SQL ステートメントを書くのと同じくらい簡単です。Protobuf メッセージは、コスト削減 (帯域幅使用量の削減、デバイスの自律性の向上) と、 protoc がサポートするプログラミング言語での開発のしやすさという点の両方において JSON よりも優れています。 AWS IoT Core ルールエンジンを使用して Protobuf 形式のメッセージをデコードする方法の詳細については、 AWS IoT Core のドキュメント を参照してください。 サンプルコードは github リポジトリ https://github.com/aws-samples/aws-iotcore-protobuf-sample にあります。 decode 関数は、Amazon Kinesis Data Firehose にデータを転送する場合に特に便利です。デコードを実行するための AWS Lambda 関数を記述しなくても JSON 入力を受け付けることができるからです。 AWS IoT ルールアクションで利用できるサービス統合の詳細については、 AWS IoT ルールアクションのドキュメント を参照してください。 著者紹介 José Gardiazabal José Gardiazabal は、AWS のプロトタイピングおよびクラウドエンジニアリングチームのプロトタイピングアーキテクトです。プロトタイピングにより AWS 上での可能性を示すことにより、お客様が構築したいシステムの実現ができるようサポートしています。彼は電子工学の学士号とコンピュータサイエンスの博士号を持っています。以前は医療機器とソフトウェアの開発に従事していました。 Donato Azevedo Donato Azevedo は、AWS のプロトタイピングおよびクラウドエンジニアリングチームのプロトタイピングアーキテクトです。AWS 上での可能性を示すことで、お客様の真のポテンシャルを引き出す支援をしています。制御工学の学士号を持ち、以前は石油・ガスおよび金属・鉱業企業の産業オートメーションに従事していました。 この記事はJosé GardiazabalとDonato Azevedoによって書かれた How to build smart applications using Protocol Buffers with AWS IoT Core の日本語訳です。Solutions Architect の 西亀真之 が翻訳しました。

新型コロナウイルスのパンデミックが世界中を席巻する中、大くの組織は世界最大の「在宅勤務」の実験を余儀なくされました。現在に至ってみると、従来のオフィス環境はもはや存在せず、これからはハイブリッドワークやリモートワークが主流になることは明らかです。 フォーブスの国境を越えた従業員調査 によると、10 人に 8 人近くの労働者が、自宅、オフィス、好きな場所など、働く場所の柔軟性を好んでいることが明らかになりました。優秀な人材を確保し、魅力的な企業であるためには、企業が適応しなければならない新しい「規範」が存在することは明らかです。さらに、 リモートワーカーやナレッジワーカーの 75% が、フレキシブルな働き方への期待が高まっていると回答しており、 10 人中 4 人は オフィスに戻ることを求められたら仕事を辞めるかもしれないと回答しています。 ハイブリッドワークやリモートワークのモデルは今後も続くと予想されますが、一部の中小企業はリモートワークの対応に 苦労しています 。セキュリティ、リモート IT サポート、信頼性の低いネットワークはリモートワーカーを管理するうえで重要な技術的課題となっています。特にリモート IT サポートは 中小企業の 46% にとって 深刻な阻害要因となっています。その結果、 ハイブリッド・ファーストのマインドセットを持っているのはわずか 11% で 、37% は成熟したリモートワークを実践していると考えています。 パンデミックからの脱却に伴い、中小企業はハイブリッドワークプレイスをサポートするクラウドに目を向けています。ビデオ会議テクノロジーの利用の伸びが、中小企業がクラウドソリューションを採用する兆候として考えられます。しかし、クラウドには仮想会議ソリューション以上の魅力があります。クラウドサービスを利用することで、遠隔地にいる社員がどこからでも企業のリソースに安全にアクセスできるようになり、 企業のコンテンツの安全性が確保され 、組織内外のドキュメントをリモートで共有したり、コラボレーションするためのツールが提供されています。 リモートワークは、従業員に柔軟性をもたらすだけではないと考える企業が増えています。特定のビジネスツールやプロセスを見直すことで、ビジネスの基本的な進め方を改善するチャンスがあるのです。 このブログでは、先進的な中小企業がアマゾンウェブサービスを活用して、リモートワークの一般的な課題を克服し、従業員の生産性を変革している3つの方法について詳しく説明します。 1. 敏捷性（アジリティ）：リモートワークのスイッチを入れる 次の世界的大流行がいつ起こるかを正確に予測できる人は誰もいません。しかし、適切なインフラストラクチャスタックがあれば、企業は進化するビジネスニーズに俊敏に対応できます。 テクノロジー主導の創薬を専門とする日本の製薬会社、 協和キリン を例にあげてみましょう。何年にもわたってテクノロジーインフラストラクチャを徐々にクラウドに移行してきたため、この製薬会社は、新型コロナウイルスによるロックダウンが始まったとき、わずか1週間で 300～400 台の仮想デスクトップを追加できました。これにより、リモートワークにアクセスできる在宅勤務の従業員の総数は、米国と日本で 1,600 人に達しました。 その結果、協和キリンはビジネスと生産性への混乱を減らすことができました。さらに重要なのは、パンデミック発生前にオンプレミスの仮想デスクトップインフラストラクチャを Amazon WorkSpaces に移行することを決定したことです。 Amazon WorkSpaces は、リモートの従業員にインターネット接続されたあらゆるデバイスから、高速で応答性の高いデスクトップエクスペリエンスを提供する仮想デスクトップソリューションで、 30% のコスト削減につながりました 。 協和キリンの ICT ソリューション部門の責任者である楠本貴幸氏は、「新型コロナウイルスのパンデミックにより、Amazon WorkSpaces の価値を認識しました。ユーザーは、大きな混乱を招くことなく、自宅や仕事からデスクトップ環境を使い続けることができました。」 現在、協和キリンは、未知の将来のシナリオを正確に予測し、それに対処するために、多額の設備投資や時間のかかる計画をたてる必要がなくなっています。AWS への移行により、リモートワークの拡大に必要な俊敏性と費用対効果をが得ることができました。 2. サイバーセキュリティ：デバイスの増加、セキュリティの必要性 リモートワークがもたらす柔軟性と事業継続性とは裏腹に、まだいくつかのリスクがあります。その1つがサイバーセキュリティです。リモートで仕事をする人が増えるにつれて、保護すべきデバイスの数が増えます。この急増は、社内にITスタッフがいるかどうかにかかわらず、中小企業が直面するセキュリティ上の問題という独自の課題をもたらします。従業員が地理的に分散しているため、セキュリティ製品をリモートでインストール、管理、サポートできるようにしなければなりません。 インドに拠点を置き、金融サービス部門に価値の高いリサーチ、分析、ビジネスインテリジェンスを提供する Acuity Knowledge Partners 社 では、最近のリモートワークへの移行時に、データセキュリティの管理が重大なリスクとなりました。同社のアナリストは、これまで包括的なセキュリティ管理がなされていなかったため、社外で仕事をすることができませんでした。 Acuityの最高技術責任者である Sridhar Damala 氏は、次のように語っています。「新型コロナウイルスのパンデミックにより、当社の事業運営方法がすべて変わりました。リモートワークの許可を得るためには、情報をどのように保護するかについて、特定のデータセキュリティ対策を講じて、各クライアントのところに行かなければなりませんでした。WorkSpaces にはその答えがありました。」 WorkSpaces はこれらの「答え」を現実のものにしました。Acuity は、3 週間以内に、 世界中の 1,100 人の従業員を安全かつコンプライアンスに準拠した方法で仮想デスクトップに移行することができました 。 デジタル化が初めての方、中小企業にクラウド機能を追加したい方。AWS Smart Buisness で業種別、メリット別、ユースケース別などのソリューションをご覧ください。 3. スケーラビリティとコラボレーションの促進 リモートワーク環境やハイブリッドワーク環境に移行する中小企業にとって、サイバーセキュリティは必要不可欠ですが、ビジネスが最適に機能するためには、クラウドコンピューティングソリューションに伴う スケーラビリティ 、 信頼性 、 パフォーマンスの向上も必要です。 そのような企業の1つが、オーストラリアの多文化研究およびコミュニケーション機関である The LOTE Agency （LOTE）です。同社の業務には、ビデオ編集やマーケティングアーティファクトの作成などがあり、どちらもコンピューティングとストレージを大量に消費します。LOTE は、従来のオンプレミスシステムを AWS に移行することで、安全で高性能で回復力に優れ、効率的なインフラストラクチャを手に入れました。このインフラストラクチャは、従業員が拠点を置く場所に関係なく、 政府機関の厳しいワークロードの要求に対しても簡単に拡張できます 。 LOTE のゼネラルマネージャーである David Bartlett 氏は、同社が AWS に移行したことでコラボレーションの流動性がどのように向上したかについて語ります。Bartlett 氏は次のように語っています。「ある晩、私はスタッフにオフィスに来ないように言ったのですが、翌朝スタッフはオフィスにいないのにもかかわらず 100% 仕事をすることができました。驚くにはあたりません、それを可能にしたのは、AWS を導入していたからです。」 彼は続けます。「ドバイの多文化分野の専門家は、オーストラリアのデータセンターにあるデータを安全に扱うことができます。AWS 環境内で作業している場合、彼女はファイルをローカルに保存する必要はありません。この柔軟性が、当社の事業拡大と成長を支えています。」 言うまでもなく、AWS クラウドアーキテクチャを基盤としているため、LOTE は新型コロナウイルスによるロックダウン中でも従業員がシステムに安全にアクセスできるようにするうえでほとんど問題に直面しませんでした。さらに、同社はセキュリティ体制の改善により、オーストラリア政府からワクチン展開を支援する大規模な契約を獲得するに至りました。 リモートワーク向けの AWS ソリューション 上記の例では、企業がAWSクラウドインフラストラクチャをいかに簡単に拡張して、変動するリモートワークやハイブリッドワークの形態に対応できるかがお判りいただけたかと思います。AWS クラウドは、運用コストを抑えながら、中小企業 (SMB) に俊敏性、 セキュリティ 、 スケーラビリティ 、 信頼性 を提供します。 AWS を使用することで、従業員、コンタクトセンターのエージェント、クリエイティブプロフェッショナルは、事実上どこからでも生産的に働くことができます。詳しくは、 中小企業向けリモートワーク eBook をご覧いただくか、 AWS のエキスパート にお問い合わせください。 翻訳はソリューションアーキテクトの山﨑 博昭が担当しました。原文は こちら です。

約 30,000 のグローバル価格表から情報を収集し、カタログ化、更新することは、非常に困難な作業です。24 時間 365 日、いつでも利用可能なサービスを提供するには、スケーラブルで信頼性の高いインフラストラクチャが必要です。しかし、それでも中小企業（SMB）はeコマースで成功を目指すことをやめません。ニュージーランドのオークランドに拠点を置く Wine-Searcher は、わずか 85 人のチームでサポートされる世界最大のグローバルワイン検索エンジンを提供しています。Amazon Web Services を利用することで、Wine-Searcher は巨大なチームや無限のリソースを持つことなく、 IT レジリエンスを実現し 、データをより適切に管理できるようになりました。クラウド IT ソリューションによって Wine-Searcher がどのようにグローバルサービスを提供し、新しい機能を追加するために規模を拡大し続けることができるのか、CEO の Jules Perry 氏に話を聞きました。 クラウドによるビジネス課題の解決 Q. Jules, Wine-Searcher はソムリエがたくさんいる会社のようにみえますが、あなたのビジネスの見方は違いますか？どのような会社なのでしょうか？ A. Wine-Searcher は、ワイン、スピリッツ、ビールの世界最大のグローバル検索エンジンおよび価格比較エンジンです。世界中で毎月約 500 万人のユーザーにサービスを提供しています。Wine-Searcher は少し変わっています。名前にはワインが入っていますが、実際はIT組織です。私たちはインターネットビジネスで、世界中からデータを収集し、必要に応じて消費者に提供し、ワインやスピリッツ業界をサポートしています。 Q. Wine-Searcher は、以前は独自のデータセンターを社内に所有していました。どのようにニーズが変化したのですか？ A. 何年もの間、ホスティングビジネスを行う上で最も柔軟で反応性の高い方法は、実際に自分たちで行うことだとわかっていました。だからこそ、コロケーションサービスを運営することにしたのです。私たちは 22 年間、独自のウェブサービスをホストしてきました。よりモダンな環境、拡張性の高い環境、より優れたパフォーマンスと耐障害性を備えた環境に移行する必要があることがわかりました。オンプレミスまたはコロケーションサービスを独自に実行することは、今日の世界ではうまくいきません。 時間の経過とともに、クラウドから利用できるサービスは非常に優れたものになり、自社でできること、そして自社で運用し続けることを凌駕しています。また、ハードウェアから独立しているということは、トレーニングを受けたエンジニアが真夜中に稼働する必要がないということです。クリスマスの日に呼び出しがあったこともありました。そういった苦労から解放され、ハードウェアから解放されるのです。 クラウドセキュリティから始めて、サービスを拡大する Q. AWSと契約された当初は、主にセキュリティに重点を置かれていましたが、そこから急速に拡大していきました。その経験について教えてください。 A. AWS を使用した最初の試みは、オンプレミスとコロケーションサービスに 災害対策ソリューション を提供することでした。つまり、私たちは AWS で何ができるかのか、試していただけだったのです。私たちの経験と、システムがしっかりと機能すること、信頼性が高いこと、使いやすいことという確信に基づいて、すべてのサービスを移行するための計画を立て、実行に移行することができました。 AWS は導入が簡単です。サービスを利用することも、試してみることも、自分で検証することもできます。大きなコミットメントも必要ありません。必要な時に必要なだけ利用する。これは本当に魅力的な提案です。使用した分だけ料金を払い、独自のペースで進めることができます。 クラウド移行のカスタマイズ Q. 多くの中小企業は、データ移行に必要となる労力を懸念しています。経験談をお聞かせください A. AWS に移行する際の課題の 1 つは、どのサービスを採用し、どのような新しいテクノロジーを採用するかを検討することでした。また、既存のものをどのように移行するのかも検討する必要がありました。リフトアンドシフトが当初の移行方法でしたが、これは本当にうまくいきました。私たちが知っていて、理解し、長年にわたってチューニングしてきたすべてのテクノロジーがそのまま残っており、それらが私たちのために機能していたからです、リスクのない移行のようなものでした。 全体として、ウェブベースのサービスの移行を計画し、実行するのには 1 年はかかったと思います。当然ですが、最初に開発環境を移行しました。私たちはLinux、Apache、Oracle、Solr PHP のような非常に典型的な環境を運営しています。私たちはパフォーマンスやスケール、システムの動作、開発者とシステムをつなぐなどの事柄について、ある程度の経験を積むことができました。 デジタル化が初めての方、中小企業にクラウド機能を追加したい方。AWS Smart Buisnessで業種別、メリット別、ユースケース別などのソリューションをご覧ください。 イノベーションと俊敏性の向上 Q. クラウドへの移行によって、当初の予想を上回るビジネス上のメリットを得ることはできましたか? A. 今ではスタッフ全員が、自宅からでも、オフィスからでも、どこにいても、必要な場所で、完全に Amazon WorkSpaces を利用しています。スタッフが どこからでも安全に仕事をするために 、ラップトップ以外の IT 機器は必要ありません。これは本当に驚きです。このソリューションは私たちに信じられないほどの柔軟性を与えてくれます。そして、新型コロナウイルスのパンデミックにより非常に多くの企業が業務を中断せざるを得ませんでしたが、私たちは業務を継続することができました。 クラウドを利用し、独自のテクノロジーをコントロールできるということは、イノベーションを思い通りに自由に実行できるということでもあります。速く動きたければ、速く動く。より慎重に進めたいのであれば、それも可能です。AWS には、新しい分野での実験を可能にする一連のサービスがあります。 Q. Wine-Searcher の将来はどうなるのでしょうか？ A. クラウドを利用することで、新しいことに挑戦する自由がうまれました、挑戦に対処するためのインフラストラクチャを手に入れたからです。また、ダウンタイムやサービスの可用性を心配する必要がないため、より多くのリスクをとることができます。AWS のインフラストラクチャがあることで、更に野心的なチャレンジができるようになりました。AWS のインフラストラクチャがあることで、将来に向けてより大胆になることもできます。さらに、ビジネスの方向性について、より大胆な決断をくだすこともできます。AWS のインフラストラクチャ、リソース、そしてキャパシティがあるからこそ、以前なら考えもしなかったような決断を下すことができるのです。 Next steps クラウドへの移行によは、機敏性を保ち、優れたカスタマーエクスペリエンスを提供したいと考える中小企業は、IT レジリエンスを実現できるようになります。Wine-Searcher は、しっかりとサポートされた移行によって信頼性を向上させ、最終的には将来のイノベーションのためのプラットフォームを提供することができました。クラウドへの移行が、中小規模の eコマースビジネス の確実な拡大にどのように役立つのか、詳細をご覧ください。中小企業のビジネスの専門家と話す準備はできましたか？ 今すぐお問い合わせください 。 翻訳はソリューションアーキテクトの山﨑 博昭が担当しました。原文は こちら です。