Amazon Web Services ブログ
【開催報告】AWSで実践！Analytics Modernization ～事例祭り編～
2023 年 10 月 5 日に「AWS で実践！ Analytics Modernization ～事例祭り編～」を開催しました。今回の事例祭りでは新しく GA された Zero-ETL を活用したデモや Amazon OpenSearch Service を用いたベクトル検索、また AWS Clean Rooms と AWS の分析・予測サービスをつなげた一連のデモをご紹介しました。また AWS サービスを用いてビジネス価値を創出しているお客様事例としてパイオニア株式会社 様にご登壇いただきました。本ブログでは当日の各発表内容を紹介いたします。
Zero-ETL Integration を活用した業務データベースのニアリアルタイム分析
アマゾンウェブサービスジャパン合同会社 アナリティクススペシャリストソリューションアーキテクト 濱岡 洋太
AWS の濱岡からは 2022 年の re:Invent で発表された新機能である Zero-ETL Integration を使い、 Amazon Aurora に保管されているデータを Amazon Redshift へニアリアルタイムに連携・分析する方法についてご紹介しました。
業務系データベースには時事刻々と変化する最新のデータが保管されており、そのデータを分析することで新たなインサイトを生むことが期待されます。一方、分析のために業務データベースから分析データベースへデータを連携しようとするとデータ鮮度の低下や ETL 処理の構築・運用コストが課題として挙がります。業務データベースを分析する上ではデータ連携をいかに素早く、簡単に実現するかが重要となりますが、従来この 2 つを両立することは困難でした。
Zero-ETL 統合は ETL パイプラインなしで Aurora MySQL から Amazon Redshift へニアリアルタイムにデータを連携する機能です。Zero-ETL 統合を使用することで、これまで自前で組んでいた ETL 処理等のデータ連携の仕組みを代替し、かつデータ鮮度を簡単に向上することが可能です。Aurora 側での変更は 50 パーセンタイルが 15 秒以内に Redshift へ連携され、また更新はストレージレイヤーで行われるため Aurora 及び Redshift のコンピュートリソースへの影響は最小限に抑えられます。
デモでは、Webアプリケーションのバックエンドとして使用されている Amazon Aurora のデータを Zero-ETL 統合を使用して Amazon Redshift へ連携し、Amazon Managed Grafana を使用して可視化を行いました。
画面左側では Webアプリケーションを模した Amazon EC2 インスタンスから、 Amazon Aurora へ 1 秒ごとにデータを INSERT しています。INSERT されたデータは Zero-ETL 統合によって自動的に Amazon Redshift へ同期されます。画面右側の Amazon Managed Grafana から Amazon Redshift へクエリを行い、データがニアリアルタイムに連携されていることが確認できました。
Zero-ETL 統合を使って業務データベースを素早くかつ簡単に連携する方法についてご紹介しました。Zero-ETL 統合は本イベント実施時点ではプレビュー中でしたが、2023年11月7日より一般利用可能となっていますので是非ご活用ください。
車両走行データを活用した渋滞情報生成基盤のご紹介
パイオニア株式会社 Cross Technology Center サービス技術企画部 先行開発グループ 宮本 祥平 氏
1937 年に国産初ダイナミックスピーカーの開発を行い翌年創業しました。音をメインにしていたところから時代の変化とともに変革していき、近年ではカーエレクトロニクス事業を基幹事業としており、「より多くの人と、感動を」を理念に事業をしてます。市販事業の中で、音声だけで操作ができる対話するドライビングパートナーである NP1 の販売が開始されました。またドライバーの運転スタイルを学習し、パーソナライズされたデバイスへと進化をします。それ以外に、近年はデータソリューション事業にも力を入れています。モビリティデータやインテリジェントカメラの映像データ、位置情報などと連携しクラウドソリューションを提供しています。
パイオニアが保有するデータとして全国道路総延長 70 万 km のデータや、走行時の定点画像データ 2 億枚、それ以外にこちらに記載のデータを保有しており、今後データを活用したサービス提供していきたいと考えています。
渋滞情報生成基盤として、2006 年からスマートループ渋滞情報のサービスを提供しています。その後さまざまなデータがアップロードされ、データ量が増えてきた一方、各サービスがサイロ化されデータが連携できていなかったため、AWS 上にデータレイクを構築し、データの集約を行いました。そして今回、新規渋滞情報生成基盤の商用化に向け開発を行いました。
ポイントは 3 つあり、リアルタイムのストリーミング処理による走行データの渋滞情報への反映速度改善、複数データソース毎の仕様差分の吸収、データ流量に応じたスケールイン/アウトです。
いくつかの車載器から点列データが AWS Lambda を介しアップロードされます。Amazon EKS のコンテナにデータを渡し、点列データからマッチングデータへ変換を行います。その際道路情報は Amazon EBS に格納をしています。別経路からは道路情報が付与されているマッチングデータがアップロードされます。これはコンテナ 2 に直接アップロードできるようにしています。その後、Amazon Aurora と Amazon Kinesis Data Firehose にデータを渡しています。Firehose からは Amazon Glue を介し、Amazon S3 上に渋滞統計データを保存しています。
いくつか改善事例をご紹介します。まずは Amazon Kinesis と AWS Lambda の部分です。走行データの渋滞情報への反映速度の改善と各走行データソースのアップロードがバラバラであったという課題に対し、Amazon Kinesis Data Streams と AWS Lambda をそれぞれのサービスにデプロイしました。それにより、随時データ処理ができたこと、後段の共通処理をそれぞれの AWS Lambda で調整ができるようになったこと、また新規データの追加が共通パターンを利用できるようになったことが改善として挙げられます。
また Amazon EKS についてですが、開発当初は EKS にするか Lambda にするか検討していましたが、マップマッチング処理が必要であった点、またその処理が高負荷かつ処理時間が長い点、EKS の方が料金割引がある点で EKS を採用しました。
次はアーカイブデータ分析についてです。こちらではリアルタイムに処理されてきた個別所要時間データを保有しています。そのデータを分析するために、Amazon Athena を用いて分析を行っています。また AWS Glue job を用いて大量データ統計処理を行い、Amazon S3 に保存しています。データの品質チェックには自作のデータチェック用の AWS Glue job を用いています。また Amazon Sagemaker を利用してデータの分析や可視化を行い、品質改善を行っています。ただし課題として、データ分析自体は自動化できていなく、確認したいデータを都度 Amazon Sagemaker で確認しなければいけない点があります。
3点目はストレージの検討です。当初左の図の様な Amazon EFS の構成を検討していましたが、Amazon EBS に地図データを配置することとしました。その際 gp3 を採用することで無料枠を超えてもファイルアクセスをすることができ、Amazon EFS と比較しコスト削減ができました。
最後は Amazon Aurora のタイプについてです。今回のシステムでは Aurora standard で実装しましたが、I/O 数が多くなり、Amazon Aurora のインスタンス料金よりも I/O 料金の方が高くなってしまいました。そこで新しい Aurora I/O-Optimized に変更することで、30-50% のコスト削減に成功しました。
今後の展望は、Amazon SageMaker Notebook 上で可視化しているものをダッシュボード化したいと考えています。その際は Amazon QuickSight の利用を考えています。また手動でデータチェックをしている部分を AWS Glue Data Quality の利用を検討しています。
まとめです。大量データのリアルタイム処理には、処理速度や I/O 数に合わせ、運用費を意識してアーキテクチャを構築すること。データの品質を保ちつつ、生成したデータの分析がしやすいアーキテクチャを構築すること。やりたいことに対し、新しい AWS サービスが対応しているかはすぐに調べること。迷ったり悩んだりした場合は AWS に相談することで方針が決まったことが挙げられます。
OpenSearch を使用したベクトル検索
アマゾンウェブサービスジャパン合同会社 プロトタイプエンジニアリング本部 プロトタイピングエンジニア 後藤 駿介
AWS の後藤からは、近年注目を集めている技術の一つであるベクトル検索を OpenSearch で行う方法についてご紹介しました。セッションの中では、ベクトル検索の基本やベクトル検索のユースケースを説明した後、Amazon OpenSearch Service や Amazon OpenSearch Serverless が持つベクトル検索機能を紹介し、最後に OpenSearch Serverless でベクトル検索をするデモを実施しました。
ベクトル検索とは、音声・画像・テキストなどのメディアの情報を機械学習の技術などを用いて数列値 (ベクトル) に埋め込むことで検索を行う技術のことを指します。埋め込みに使用される機械学習モデルでは、メディア同士近い性質を持つものは互いに近い距離のベクトルとして埋め込まれるように学習されます。そのため、テキストの検索では、伝統的に使用されてきたキーワード検索よりも、単語や文章の意味を考慮した検索が可能になります。またテキストに限らず、画像や音声などのデータに対しても、それらのメディアの類似度による検索を行うことができます。
ベクトル検索の代表的なユースケースとして、レコメンド、画像検索、RAG などがあります。レコメンドでは、商品情報やユーザー情報をベクトル化して、ユーザーにおすすめのコンテンツを推薦します。画像検索では、画像を CNN などの機械学習モデルを使用してベクトル化して、類似画像を取得します。RAG では、クエリに関連したドキュメントを取得するためにベクトル検索が使用されることがあります。
k-NN 検索とは、入力のベクトルと類似したベクトルを k 個返す検索のことです。k-NN 検索を正確に実行しようとすると、データ量に対して比例して計算量が増大しています。数万くらいのデータ量であればそれでもパフォーマンスに問題は出ませんが、更に大きな量のデータに対して k-NN 検索を実行しようとするとパフォーマンスに大きな問題が生じる可能性があります。近似 k-NN 検索では、近似的に類似したベクトルを取得することで、データ量が増大しても高速に処理できるようになります。上述したようなユースケースのアプリケーションで大規模なデータを扱う場合は近似 k-NN の使用が欠かせません。OpenSearch では近似 k-NN にも対応しており、大規模なデータに対して高速に検索することが可能です。
OpenSearch が持つ k-NN 機能は、AWS のマネージドサービスである Amazon OpenSearch Service や Amazon OpenSearch Serverless からも利用可能です。OpenSearch Service では、非近似 k-NN だけでなく、近似 k-NN アルゴリズムとして、HNSW と IVF アルゴリズムが使用可能です。また、メモリの消費を抑える手法である PQ を使用することも可能となっています。こうした選択肢があることで、お客様の要件に合わせたベクトル検索が可能になります。
また、プレビューではありますが、OpenSearch Serverless でもベクトル検索が可能となっています。OpenSearch Serverless は OpenSearch Service とは異なり、クラスターのサイジングやシャーディング戦略を考える必要なく OpenSearch を利用することが可能になります。OpenSearch Serverless でのベクトル検索は、OpenSearch Service と同様の操作で行うことができます。動画の中では、OpenSearch Serverless を起動して、データを投入して検索する流れをデモンストレーションしておりますので、ぜひそちらをご確認ください。
AWS Clean Rooms と AWS の分析・予測サービスとの親和性
アマゾンウェブサービスジャパン合同会社 アナリティクススペシャリストソリューションアーキテクト 佐藤 祥多
AWS の佐藤からは2022年の re;Invent で発表された AWS Clean Rooms についてご紹介し、AWS Clean Rooms とノーコード予測分析サービスである Amazon SageMaker Canvas とデータ可視化ツールである Amazon QuickSight を組み合わせたデモを実施しました。
AWS Clean Rooms は AWS 上でデータを安全に共有するためのデータクリーンルームを作ることができるサービスです。データクリーンルームとは、プライバシーやセキュリティが保護された状態でデータを共有することができる場を指します。昨今、企業内や組織間だけのデータ共有ではなく、企業や組織の枠組みを超えてデータ共有を行い、新しいビジネスインサイトを得るための取り組みが活発化しています。そういったビジネスニーズを満たすため、AWS Clean Rooms は AWS を利用しているすべてのお客様に手軽にデータクリーンルームを作れる機能を提供します。
AWS Clean Rooms は Amazon Athena のような SQL による操作で、共有されたデータに対して単体で分析を行うことや自身が保有するデータと組み合わせて分析を行うことができます。AWS Clean Rooms は安全にデータ共有を行うためのいくつかの機能を有しています。
- コラボレーション：AWS Clean Rooms はデータ共有を行う場としてコラボレーションを作成できます。データを共有する AWS Account, データの分析を実行する AWS Account, データの分析結果を取得する AWS Account をコラボレーションに最大5つまで参加させることが可能です。データ分析の実行と結果取得は同じ AWS Account にすることも可能です。コラボレーションのオーナーはコラボレーションに参加させる AWS Account をコントロールすることで、誰が/誰に/何ができるのかを制御することができます。
- 生データを共有せずにデータ共有可能：AWS Clean Rooms では生データを共有せずに AWS Clean Rooms を利用するパートナーとデータ共有することが可能です。Amazon Simple Storage Service (S3) に保存され、AWS Glue Data Catalog に登録されたデータに AWS Clean Rooms は AWS Account を跨いでアクセスし、分析された結果だけをデータ共有先の Amazon S3 バケットに転送します。
- 分析ルールによる出力制限の設定：コラボレーションに参加しているデータ共有をする AWS Account は共有されたデータに対して特定のクエリしか許可しない分析ルールを設定することが可能です。この分析ルールを設定することで、SUM や AVG といった統計情報しか出力しない制御を実現することや、共有先が保持している ID に合致したものだけを共有先にデータ提供するといった制御を実現することが可能です。
AWS Clean Rooms で共有されたデータは S3 に保存されるため、AWS の分析サービスや機械学習サービスを利用してさらなる分析や予測を行うことが可能です。Amazon QuickSight はデータを可視化するためのマネージドな Business Intellijence (BI) ツールです。マネージドであるため BI ツールのインフラを管理しなくても良いという特徴や、様々なアプリケーションに埋め込みが可能な埋め込み機能などがあります。
Amazon SageMaker Canvas はノーコードで機械学習モデルを作成してモデルを適応できる AutoML のサービスです。こちらも AWS Clean Rooms による分析結果を活用できるサービスになっています。
このセッションでは、新規広告を打った場合の効果を予測するというデモシナリオを AWS Clean Rooms, Amazon SageMaker Canvas, Amazon QuickSight を組み合わせて実施しました。デモの詳細な中身については動画を閲覧いただけると幸いです。
まとめ
これまでの事例祭りに続き、Analytics 領域の先進的な事例が盛り沢山のセミナーとなりました。日本のお客様向けに AWS アナリティクスサービスの最新動向を発信しています。AWS サービスにご興味ある場合は無料で個別相談会を開催しておりますので、皆様からのお申込みをお待ちしております。お申込みリンク。
井形 健太郎・濱岡 洋太