この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
1 はじめに
CX事業本部の平内（SIN）です。
以前、Audioデータをクラウドに送信する処理の中で、Amazon Kinesis Data Streamsを挟んでリアルタイムなデータ処理を試してみました。
Amazon Kinesis Data Firehoseの前段に置かれたAmazon Kinesis Data Streamsからデータを取得する事で、リアルタイムに変化するAudioデータの音量をメータ表示している様子です。
https://www.youtube.com/watch?v=LX3hy-kNEGA&t=1s
今回は、このデータをAmazon ESにも送って、ニヤリアルタイムとなりますが、音量の変化をKibanaで表示してみました。
2 構成
作業したのは、赤い点線の部分のみです。
メータ表示用にメッセージブローカーに送られていたメッセージをルールエンジンで取り込み、Amazon ESに蓄積しています。
ルールエンジンでトリガーするのは、下記のように到着しているメッセージです。こちらは、Amazon Kinesis Data StreamsからトリガーされるLambdaが送っているものですが、Amazon Elasticsearch Serviceで扱いが簡単なように、タイムスタンプはUTCにしました。
3 Amazon Elasticsearch Service
audio-transmissionという名前で、ドメインを作成しました。
動作確認用という事で、デプロイタイプは、「開発およびテスト」とし、手元からアクセスして確認できるようにグローバルアドレスをAllowしています。
数分待って、ドメインのステータスがアクティブになると、利用可能です。
4 AWS IoT Rule
トピック topic/level_meterをトリガーして、アクションに、Amazon Elasticsearch Serviceを指定しています。
SELECT * FROM 'topic/level_meter'
Amazon Elasticsearch Serviceへのパラメータ設定は、以下の通りです。
IDは、ユニークなIDをuuidで設定、索引は、とりあえずlevel_meter（ここは、名前＋日付などとして、古いデータを扱いやすくするのが良いかも知れません）、タイプ（テーブル名）は、LevelMeterとしました。
- ID ${newuuid()}
- 索引 level_meter
- タイプ：LevelMeter
5 Kibana
index Patternsで、Ruleで指定した索引を指定（ワイルドカードでも使用可能）すると、データが到着している場合、索引level_meterを見つけることができます。
次のステップで、time filterに、 フォールド名timestapmを選択しています。
この時点で、取得したデータのプロパティ及び、型が認識されますが、音量であるLevelがnumberとして認識されていることが確認できます。
期間（過去15分）を指定して、到着しているデータを確認している様子です。
続いて、visualizationで、折れ線グラフを選択しています。
縦軸（Y）に、音量であるLebvelの最大値をとり、X軸に、時間を指定しています。
過去3分で表示すると、下記のような折れ線で音量（最大値）が確認できます。
6 最後に
今回は、「Audioデータをクラウドに送ってみました」の最終版として、簡単ですが、ニアリアルにグラフを表示してみました。
ここまで、ストーリームデータをクラウドに送信するというニーズをイメージして、「Audioデータ」を題材として、色々確認してみました。しかし、試せていないAWSのサービスも、まだまだ、あります。
求められる要件、データのサイズ、必要なリアルタイム性、許容できるコストなど、考慮するべきことは山ほど有るなというのが正直な印象です。しかし、AWSの多彩なサービスで、「対応・検討できるものも沢山ある」とも言えそうです。
全然、勉強がたりません・・・
全てのコードは下記に置きました
https://github.com/furuya02/AudioTransmission/tree/main/sample_7
14
