ごきげんよう
この記事は
「するめごはんのVUI・スマートスピーカー Advent Calendar 2018」
の25日目の記事です。
さて、アドベントカレンダー最終日。
思いっきり、技術の話をしようと思います。
2018年4月末に会社をスパッと辞めて
「VUI・スマートスピーカーに専念するぜ！」
となってましたが、半年もしないで自分単独が発明者となって特許出願するとは思ってませんでした。
しかも、API Gatewayってなんですか？のレベルからAWSをガッツリ勉強・検証することにもなったわけです。
そんなシステムの話。
対外的に一番語っている資料はAlexaSalon
25分間、このシステムについて語っているのは
クラスメソッド社、清野さん（せーのさん）からご招待があった、AlexaSalonにて語っていて、すでにそこでスライドは共有済みです。
ご関心ある方はそちらをどうぞ。
■Alexa Salon SP @東京 〜秋のNLT（Not LT）大会〜 AlexaエバンジェリストにAlexa Championも！
https://classmethod.connpass.com/event/103739/
特許出願したSH Analytics（通称SHA）
上記の通り、SmartHacks社に納品したシステムです。
このシステムには以下のような目的があります。
平たく言えば、VUIのスキル・アクションの品質を高めるための仕組みです。
・VUIの各プラットフォームのログデータを一元管理して分析する
・自分および他社のスキル・アクションを様々な角度で比較してKPI等の具体的数値を出す補助をする
・人気のスキル・アクションが他の人からも見てわかる
・開発者と開発を依頼したい人のマッチングにつなげる
・スキル・アクションの利用頻度が落ちてきた場合等もグラフで一目でわかる
・音声サービスに対するレビューを音声で行う
・音声サービスに対するフィードバックコメントを音声で行う
などなど、色々な使い方を想定しています。
AWS構成図
動き出した時点の構成図は公開されているので、ここで語ることができます。
わかる人には、「ん？ここおかしくね？」というポイントがあると思いますが、そこらへんはこの後にある程度進化させているつもりです。
この構成にはいくつかのポイントがあります。
1.VUIのスキル、アクションとしてスキル・アクションそのもののユーザーに負担をかけない
Lambda等でHTTPSで本システムのAPI GatewayにPOSTで必要事項を送付すると、DynamoDBに、SHA登録済みであるか確認を行い、即時スキル側にHTTPのレスポンスを返しています。
基本的に200か、それ以外を返しますが、先日202を追加しました。
本来、Amazon Cognito等と使ってしっかり認証・認可をすべきですが、VUIの応答速度およびアカウントリンク等の負担を鑑みて、それはやらないことにしました。
2.データ収集はそれ用のLambdaをinvokeさせてバックで行う
1に関することですが、DynamoDBでSHAの正規ユーザーだとわかり、かつ、想定通りのJSON形式だと200を即時スキル側に返答しています。
その際に新しいLambdaをinvokeで起動させて、Amazon Kinesis Data Firehoseに投げています。
FirehoseからS3等にアウトプットする際にデータ形式を変更することが可能ですが、お金が若干かかるのと、データ格納先がRedShiftであるため、CSV形式にあらかじめ変換しています。
めっちゃバズったらAmazon Kinesis Data Streamsを間に挟んだ方が良いと考えています。
もともとは、AuroraかRDS PostgreSQLで行う予定でしたが、やはりLambdaと相性が悪すぎました。
CSV形式なのはそのなごりでもありますが、クライアントさんがエンジニアではないことも考慮するとCSV形式の方が読みやすいと判断しました。
ちなみに、新卒3年目くらいの時に、同じようなロジックをJavaのマルチスレッドで実装して怒られました。
「DBに格納されているか不透明なのにOKを返すことは何事か」
と。
そこは最低限、この図にない部分のS3にも格納しています。
3.Athenaを選ばずに初めからRedShift
VUIが流行るかどうかすら正直不透明であり、そんな中でいきなりRedShiftを選択します。
安価にシステムをまわすことを考慮するとS3に格納してAmazon AthenaでSQLライクに呼んだ方が良いと思われます。
が、今回の場合、僕はあくまでフリーランスでの単発受注だった点と、RedShiftはFirehoseから容易につなぐことができる点、そして後からRedShiftにいれるようにいじるのはかなりしんどいと判断して、クライアントのOKをもらってRedShiftにしました。
Athenaもそこそこいじりましたが、VUIのログデータがガンガン飛んでくるとログファイルもガンガン増えていくことになり、ファイルをまたがりまくるとAthenaの性能がつらぽよでした。
僕のAWS力が高ければうまいことやれたんだろうとは思います。
RedShiftでのテーブル分散もそれなりに考えています。
例えば、スキル・アクションに関するデータ（カテゴリとか）を管理するテーブルはデータ量が少ないがJOINする頻度が高いのでALL分散でJOINの負荷を下げたつもりです。
ログデータに関してはさすがにALL分散は選ばないようにしています。
4.分析画面はQuickSight
BIツールは他にも経験がありましたが、QuickSightに落ち着きました。
以下のような画面になっています。
Alexaのカスタムスキルの、スキル毎のユニークセッション数や、カテゴリごとの利用頻度、音声でのレビューの星の数やユーザーからの音声からのフィードバック等を表示しています。
提供しているダッシュボードは複数ありますが、開発中のスキルの場合は基本的に、SHAから割り振られた匿名の開発者名とスキル名が表示されます。
流行ってきたと思ったら、公開する旨をSHAの中の人に連絡すると、開発者名とスキル名を伏せずに公開しているダッシュボードにデータを公開することができます。
平たく言えばアピールできます。
※
スマートスピーカーを遊びたおす会で表示したスライドです。
一部、テスト用のスキルのデータも含みます
QuickSightに落ち着いた理由は主に以下です。
・サーバレス最高
・MetabaseとかのためにEC2やElastic Beanstalkを使うのは嫌だ
・料金プランが非常に良い
・E-mailで分析画面を送付できる
・登録して、閲覧するためのユーザーはメールアドレスをもらえばよい
QuickSightは操作に慣れれば非常に扱いやすく、また、分析画面のダッシュボードの閲覧権限を与えたユーザーが、どんなに使い倒しても1ユーザー（1アカウント）あたり月5ドルです。
使わなければ0ドルというか0円です。
なのでダッシュボードをばら撒くことがやりやすいので大変良いです。
QuickSightは機械学習対応をするらしく、グラフの傾向から今後のグラフがどうなるかまで分析してくれるみたいです。
となると、SHAに登録したスキル・アクションの今後の利用頻度が予想されることになります。
神か。
E-mailで分析画面のレポートを送付できるのも強いです。
分析画面をBIツールでいかにかっこよくしようとも、見られないのは意味がないです。
そこにE-mailで分析画面のキャプチャを送付できるのはPUSH型であり、かなり強いと考えています。
※
ただし、Oracle DBとはつなぐことができません。
たぶんライセンスがうんぬん・・
5.僕が作った「ノリノリのサンタ」へのフィードバック
「ノリノリのサンタ」というスキルを本システムに対応させています。
すると上記のようなユーザーからのコメントが寄せられていることがわかります。
・何やってるんですかね
・ノリノリの具合がすごい
等のユーザーからのコメントがもらえるのは開発者として非常に嬉しいことです。
6.検討したが辞めた技術類
1.Glue
バグを猛烈に踏みました。
そして、本システムにはお金かかりすぎだと判断しました。
2.AWS Batch
RDS PostgreSQLにデータを格納しようとして、AWS Batchでがんばろうとしましたが、断念しました。
Firehoseから直にRedShiftに入れた方がシステムが安定するのと、Batchに現実的にどれだけの時間がかかるのか未知数だったためです。
3.AWS Step Functions
Lambdaを組み合わせて、RDSとうまいこと連携できないかと模索しましたが辞めました。
CSVをRDSに格納する際に使用するこを検討しましたが、やりたいことに対して複雑すぎると踏んだからです。
そこまでして、RDSではないといけないのかということになりまして、クライアントと話した結果、
「firehoseから直にRedShiftに格納できるならそれでいいじゃん」
となった次第です。
もちろん間にS3を挟みますが、努力が減って、やりたいことが実現できるならその方が良いです。
4.RedShiftのクエリエディタ
■RedShiftのQuery editorの注意
https://qiita.com/surumegohan/items/d963795014493cc28442
意図していないタイミングでSQLが発行される可能性がありました。
怖すぎる。
結局これをつくるのにどれだけの時間がかかったか
本格的に着手してから2か月ちょいくらいです。
「API Gatewayってなんですか？」
の状態から、市販本を買いあさり、AWS Well-Architected フレームワークを読んで、AWS Loftに通ってエキスパートさんに随時質問して、QuickSight等のハンズオンに参加したらこうなりました。
VUIに関する知識と、今までのエンジニアとしての経験をフルフルに注ぎました。
このシステムを創って得たモノ
1.AWSの知識と経験
AWSの知識類は飛躍的に上昇しました。
re:Invent2018の内容をみて、「え、まじか。あれこうなったのか」とかがわかるようになりました。
2.AWSの中の人と仲良くなれた
AWSの中の人達と、結構仲良くなれました。
今ではほとんど顔見知りです。
AWS Loftを使って、VUIで特許出願システムが生まれたという事例はたぶん初だと思います。
AWS LoftやQuickSightの活用事例の話として、登壇お声がけになるかもです。
3.がっつりエンジニアリングした
VUIのスキルを創る際に利用するのはせいぜいLambda、DynamoDB、S3くらいです。
今回、他のサービス類をめっちゃ検討して、めっちゃ使って、エンジニアリングしたなーと思えてるのは、やはり大きな収穫です。
4.技術的に話せる機会が増えた
フリーランスなので、お仕事の依頼を受けることはちょくちょくあります。
僕の場合は基本的には「VUIの人」なのですが、「AIスピーカーを使ったシステムを創りたい」みたいな話が来た時に、同時にオンプレ環境をクラウド化したいという潜在課題がある場合もあります。
その際に、自分でその場でAWSへのマイグレーション案がだせるようになれたのは非常に大きいです。
もちろん、イベント類でも話すことができるようになりました。
あとは認定資格でもとって名刺に記載しようかな。
5.特許出願のやりかたを知った
めっちゃ大変でした。
想像以上でした。
大学の論文を書いてる感覚でした。
大学院時代を思い出しました。。。
弁理士さんと随時相談していくわけですが、そもそもIT業界のエンジニアだってVUIに詳しくない状態で、弁理士さんにVUIやスマートスピーカーを語り、クラウドの仕組みを語り、法的な文面に落としていくのがめっちゃ大変です。
アドベントカレンダーやりきった
25記事を書き続けてきたわけですが、当初の予定と大幅に変わりました。
「情報は水物」って本当ですね。
僕が1人で25記事（ADVENTARを含めると50記事）+他のアドベントカレンダーへの数記事を合わせると結構な量になります。あとMediumで英語ブログも始めました。
そもそも1人アドベントカレンダーを勧めてくれた人が何名かいましたし、VUIやってきた2018年で、仕事の時間をコントロールできる今年が25記事やりきるタイミングとしてBESTだと踏みました。
PostgreSQL界隈の積極的な方々が1人アドベントカレンダーをやっているのを目にしていましたし、やりきることで得るものはたしかにたくさんありました。
やってみて本当に良かったと思っている点は
何かをやるときに、どうアウトプットするかを考えながら行動できるようになってきたことです。
アウトプットを前提としてインプットすることができると、吸収量が半端なく上がります。
そして、50以上の「いいね」も頂けました。
みなさん、ありがとうございます。
来年も調子にのってやるかもしれないですが、もうちょい計画的にやりたいですね。。
以上です。