AWSの話題を中心に、日々の業務やプログラミングの徒然を綴るエンジニアブログです。

HANDS LAB

HANDS LAB ENGINEERS BLOG

ハンズラボエンジニアブログ

カテゴリー: AWS

Alexaスキルアワード2018ハンズラボ賞まとめレポート

Pocket

こんにちは、エンジニアの松本です。

先日9/29(土)に開催されたAlexaスキルアワード2018のファイナルステージへ
スポンサー企業として参加してきました!

ファイナルステージでは365個ものたくさんの応募があった中から、24個のスキルが紹介され、
審査員たちの熱い審査会を経て、授賞式が行われました。
開発者の皆さん、お疲れ様でした!受賞者の方々、おめでとうございます!

各スキルについては各メディアで取り扱われている記事を後ほどご紹介させていただくとして、
今回は東京ハッカソン、大阪ハッカソン、そしてスキルアワードで!!
ハンズラボがスポンサー賞を差し上げたスキルについて、授賞に至ったポイントを
あげさせていただきたいと思います。

06.30-07.01 東京ハッカソン第1弾 「おえかきおねえさん」

まずは東京ハッカソンのハンズラボ賞「おえかきおねえさん」から!
当時のスキル名は「おねえさんとおえかき」でした。
ハッカソン当日はオーディエンス賞も同時受賞、スキルアワードでは富士通クラウドテクノロジーズ株式会社賞を受賞したツワモノです。

手軽に誰でも楽しめる絵描き歌にゲーム性をプラスして
何の絵になるか初めに教えずに、完成図が何になるか想像しながら描き、最後にAlexaホームカードで答え合わせができます。
複数人で同時に挑戦しても面白く、答えがあっていたときにはアハ効果のような爽快感があり、
オーディエンス賞納得のスキルでした。

  • 本来であれば見えているはずの絵描き歌の途中経過が、VUIになることで見せられないのを逆手にとり、ゲームにする発想のおもしろさ
  • ”おねえさん”の喋り口調、絵描き歌にはSSMLで工夫がこらされており、それによってスキルのキャラクターが立っていると感じる
  • 一つの意味合いのセリフに複数の文言パターンを用意するなどやりとりが機械的にならないように配慮が感じられる

 

以上をふまえてハンズラボ賞を授与させていただきました。
絵描き歌のバリエーションも増え続けているようなので今後も楽しみです。

07.29 東京ハッカソン第2弾 「VoiceQ&A」

台風で残念ながら2日間のうち後半1日のみの開催になってしまった東京ハッカソン第2弾・・・!
ハンズラボ賞に輝いたのは「VoiceQ&A」です!

こちらはホテルでの利用を想定した顧客満足度アンケートスキルです。
チェックアウトのタイミングでお客様に対し、ホテルについてアンケートをお願いします。
アンケート結果は、スタッフが掃除の合間に確認できるそうです。

  • 「ホテル」を「店舗」に置き換えて小売業界でも利用できそう
  • 「掃除の合間に」といった”ながら作業”で、利用できるシーンを模索している

 

ビジネス利用できそうなアイディア、今後も期待したいですね!

08.17-08.18 大阪ハッカソン 「魚魚リンガル」

続いては大阪ハッカソンのハンズラボ賞「魚魚リンガル」(ぎょぎょりんがる)!
かわいがっている魚たちとお話できる夢のスキルです。
こちらも当日のオーディエンス賞、kintone賞と同時受賞、さらにスキルアワード特別賞のスキルです。

こちらのチームはなんとデモ用の金魚鉢を東急ハンズで購入してくださったそうで、ありがとうございました!
今度東急ハンズへ買い出しの際は、ぜひ弊社社員をお連れください!荷物持ちなどなどなど・・・お役に立つはずきっと・・・!

  • VUIでのやり取りになることで普段の何気ないお世話がコミュニケーションになる
  • センサー、ライトとも組み合わせてつくられているなど技術的挑戦を感じる
  • 魚の種類にあったお世話の頻度・内容になる未来に期待!

 

ファイナルステージでのデモ動画ではさらにクオリティがあがって
お魚が関西弁でかわいらしくおしゃべりする様子が見られました。
今後お魚のキャラクターが選べたりするのもおもしろそうですね。

09.29 スキルアワード 「読み上げエキスパート」

ラストはスキルアワードにてハンズラボ スポンサーテーマ賞「Generation賞」のスキルです!

Generation賞とは(以下スキルアワード公式ホームページより抜粋)

「若年層向けや高齢者向けなど、世代を超えて愛される作品に送ります。高齢者社会、少子化、介護や保育など、さまざまな課題がある中で、Alexaにこれから触れる方、Echoをこれから使う方にとって大きなインパクトを与えらえるHackが生まれることを楽しみにしています。」

受賞したのは「読み上げエキスパート」です!

こちらは「そろばん」の読上暗算を題材にしたスキルです。
そろばんは日本の伝統技能ですが、近年は少子化で習う子供が減少しており、さらにそれに伴って教えてくれる先生や塾も減少しています。
このスキルでは、一人ではできない読み上げ暗算を手軽に練習ができるように、Alexaに読み上げてもらうことができます。

  • 「読み上げ」という役割上、VUIに任せたとき自然
  • 会話フローがわかりやすく、お年寄りや子供でも一度使えばすぐ慣れることができる
  • 難易度が30段階にわかれており、脳トレとして個人にあったレベルにできる
  • 問題は大阪珠算協会に所属されている先生がデータベースに入力しており、3000題以上
  • デバイスの所在地からユーザー情報を取得することで問題回答状況などデータベース管理

 

スキルの運用でネックとなりがちな問題の登録についても行き届いており、
所在地から教室が必要な場所も参考にできそうなデータベース情報が用意されていることなどからも非常に実用的な設計がされていると思いました。

また、企業部門最優秀賞となったクイックちゃんでも感じたことですが、一人では出来ないことをAlexaを介することで可能にするというところに未来を感じました。
まさに子供から大人まで世代を超えて愛される作品であるとして「Generation賞」とさせていただきました。

まとめ

以上、4スキルの授賞ポイントをご紹介しました!
ハンズラボは、APIスポンサーというわけでもなく、もちろんAmazonさんともまたちがった立場から見ることになるため
こうして改めて選考ポイントをあげてみると少し特殊な感じがありますね。

スキルアワード全体の選考ポイントとしてはインタラクションであるかどうかが重視されていたようです。
今後はさらにU/Iとして活用できているスキルが評価されていくのではないかと思います。

また、スキルアワードファイナルステージは急遽弊社の荒木が審査員をさせていただきました。
急なことでしたが、貴重な機会をいただき、ありがとうございました。
今後ともハンズラボをよろしくお願いいたします!

参考

Alexaスキルアワード2018のファイナルステージ
おえかきおねえさん
魚魚リンガル
読み上げエキスパート提供:一般社団法人 大阪珠算協会様
関連タグ:#alexaスキルアワード

Pocket

AWS Single Sign-On環境の構築を検討してみる

Pocket

こんにちは。クラウドチームの北野です。

現在、AWSアカウントの管理やらAWSインフラのお世話をしたりしています。

ハンズラボではシステムインフラにAmazon Web Service(AWS)を積極的に採用していて、
サーバはほぼ全てAWS上で稼働しています。

何百台というサーバが常時稼働しているので、当然一つのAWSアカウントに収まるわけも無く、何十個ものAWSアカウントが存在しています。

ここまでAWSアカウントが増えてくると、AWSアカウントの管理自体が煩雑になってきます。

AWSヘビーユーザーだと似たような悩みを抱えることが多いと思いますが、
そんな時に参照するのが、AWS公式が公開しているAWS Answersです。

AWSにおけるアプリケーションの設計、構築のベストプラクティスが公開されています。

AWS Answersでは、マルチアカウント戦略のベストプラクティスであるAWS Landing Zoneが公開されています。

今回はマルチアカウント戦略のベストプラクティスの一部分である、AWSログインを一元化するAWS SSO環境の構築を検討してみます。

構成

構成図はこんな感じです。
AWS SSOがバージニア(us-east-1)にしか対応していなので、全てバージニアリージョンで構築しています。

AWS SSOではユーザー管理にActiveDirectoryを使用します。

AWSのDirectoryServiceで連携する必要があるため、マネージドサービスであるMicrosoftADを利用するか、既存のADサーバに対してAD Connectorを利用して連携します。
今回はAD Connector + SimpleADで構築しました。

認証はユーザーID/パスワードで行いますが、多要素認証も無いとセキュリティ的に不安です。
AWS SSOでは自前でRemote Authentication Dial In User Service(RADIUS)サーバを用意することで、多要素認証に対応できます。
今回はEC2インスタンスを建てFreeRADIUSを使って、RADIUSサーバを構築して多要素認証を実現しました。

今後の課題

多要素認証のためにRADIUSサーバを自前で構築してみましたが、本番導入するには運用が辛そうです。

EC2単体で立ててしまうとRADIUSサーバが単一障害点になってしまうため、冗長構成にしなければいけません。
そのために、ADサーバとのユーザ同期、多要素認証用のユーザ情報の分離…と考えだすと大変なので外部サービスを利用したいです。

先人の知恵をお借りすると、DuoやOneLoginといった外部サービスを利用して多要素認証を実現しているようなので、このあたりの利用を検討しています。

AWSには是非AWS SSOの東京リージョン対応とマネージドサービスでの多要素認証に対応していただけたらなーとお祈りしています🙏

Pocket

CodeStar使ってみた

Pocket

こんにちは。2018年1月にハンズラボにジョインした北野です。

今回Node.jsで動かすAWS LambdaのCI環境構築を担当することになりました。

せっかくなので東京リージョンで利用できるようになった
CodeStarを使ってLambda(Node.js)で動くWebアプリケーションのCI環境を作ってみたので紹介します!

構成イメージ

システム構成イメージ

下図のようなシステムを開発するためのCI環境があっさり構築できます。

CI環境イメージ

CodeStarダッシュボード

CodeCommit&CodeBuild&CodePipeline

準備

CodeStarプロジェクトを作る前にちょっとだけ準備が必要です。

CodeStar関連

CodeStarの機能を使えるようにIAMユーザーの設定をします。

  • IAMユーザーでCodeStarフルアクセスを許可します。

  • IAMユーザーでAWSマネジメントコンソールへのアクセスを許可します。

CodeCommit関連

CodeCommitのGitリポジトリにsshでアクセスするための設定をします。
すでにCodeCommitへssh経由で接続できている方は不要です。

  • ローカルマシンでssh keysを生成します。

  • IAMユーザーの認証情報にSSH公開キーをアップロードします。

  • ローカルマシンの.ssh/configファイルにCodeCommit用のHostを追記します。

やってみた

まずはCodeStarのプロジェクトを開始します。

CodeStarで最初にプロジェクトを作成した時にサービスロールの作成を求められます。
「はい、ロールを作成します」を選択します。
(※このサービスロール作成にはIAM管理ユーザーまたはルートアカウントとしてサインインする必要がありますので注意してください。)

CodeStarを最初に利用したときに追加情報の入力を求められます。
ユーザ名とE-mailを入力して「次へ」を選択します。

(参考)入力した情報はプロジェクト作成後にプロジェクトチームのメンバー表示で使用されます。

開発環境に合わせてテンプレートを選択します。今回はNode.jsとLambdaでウェブアプリケーションを作成するテンプレートを使用します。

プロジェクト名の設定とリポジトリを選択します。今回はCodeCommitを使用します。

「AWS CodeStarが、お客様に代わって…」をチェックして、プロジェクトを作成します。

数分でプロジェクトが作成できます。

デプロイまで完了した後にアプリケーションのエンドポイントにアクセスするとサンプルページが表示されます!

ソースの変更とデプロイ

ソースの変更が自動でデプロイされるところもやってみます。

コードの編集手順はCodeStarのダッシュボードから参照することができます。

今回はコマンドラインツールで「git clone」します。

ページの文言をちょっとだけ変更しました。

これをcommitしてpushします。

pushするとCodePipelineが動きだし、Source->Build->Deployの順番で動作していきます。

デプロイが完了した後にエンドポイントにアクセスすると変更が反映されました!

感想

CodeStarを使用することでとても簡単にCI環境を作ることができました!
Node.jsとLambdaの知識をほとんど使わずに手軽にCI環境が構築できます。

自動テストをどうやって実行するのかとか課題があり、これだけでデプロイ環境が完璧にできるというものではありませんが、CI環境の足場を作るのにとても便利なので活用していきたいと思います。

Pocket

【Alexa】非エンジニアにもできる!Alexaスキル開発 〜「StoryLine」編〜

Pocket

追記(2018/4/11)

Storylineが大幅にリニューアルし、日本語にも対応するようになっていました!すごい!
コーディングなしでサクッとAlexaスキルを作成できるサービス「Storyline」を試してみた

下記の当時投稿した情報は古くなってしまっていますのでご注意ください。

2017/12/17時点の情報

こんにちは、9月に入社したAWSチームの松本です。
AmazonEchoが発売して1ヶ月が経ちましたね。
招待メール、届いた方どのくらいいらっしゃいますでしょうか?

Echoに搭載されているAlexaの強みは、なんといってもスキルの数の多さ!
現在登録されているスキルの数は2万を超えており、
その数は今後もどんどん増えていくと思われます。
ハンズラボでもAlexaスキルを開発しました。 → 東急ハンズスキル

・・・

さて、Alexaスキルを開発する際、
そのユーザー体験を向上させるのに重要なポイント、それは…
「会話フロー」 です。

音声による情報のやりとりは、ちょっとした言い回しを変えるだけで
会話としてのスムーズさが劇的に向上することがあります。
そしてそういった言い回しの細やかな設計を行うには、繰り返しの微調整や
エンジニア以外の方の意見をいただくことが重要になるのではないでしょうか。

そんなとき、誰でも簡単に文言の修正ができるツールがあったら素敵!
ということで、先日 ハンズラボ Advent Calendar 2017 の12日目の記事で、
プログラム言語を用いずにAlexaスキルが開発できるツール
「StoryLine」をご紹介させていただきました。(※ただし英語・ドイツ語スキルの開発のみ)

紹介といってもスキル作成までの流れを淡々と書いた形になったのですが、
せっかく非エンジニアの方にも気軽にお使いいただける、直感的に操作ができるツールなので
もう少しマインドマップ部分の操作方法にも触れて、改めてご紹介したいと思います。

Storyline

https://thestoryline.io/

会話のスタート地点からマインドマップ形式で会話フローを作成していくと
Alexaスキルが出来上がります!

こちら、残念ながら今のところ対応言語が英語とドイツ語しかないですが、
英語は苦手…という方も安心!スマホの読み上げ機能を使って動かしてみることが可能でした!

事前準備

  1. Googleアカウントの用意
  2. Amazonアカウントの用意
  3. AWS開発者アカウントの用意(ASKを始めるところまで設定しておく

手順

Storylineの使い方について公式動画もあります(英語)

「+Create new」から新しい会話フローを作成します。
2.png

「Connect Coggle Mindmap」をクリック。
これで別サービスのCoggleというマインドマップ作成ツールと連携させます。
画面上はStorylineだけで完結しているのでCoggleとStoryLineを行き来する必要はありません。
3.png

「YES, ALLOW ACCESS」をクリック。
4.png

「Fact App」「Quiz Game App」・・・簡単なテンプレートが自動生成されます
「Create from Scratch」・・・自分で一から会話フローを作成します
今回は「Create from Scratch」を選択します。
5.png

AppName(会話フロー名)を決めます。後でApp一覧から名前を変更することも可能です。
7.png

この会話フローの言語を選択します。「英語(US)」「英語(UK)」「英語(インド)」「ドイツ語」から選択可能です。
8.png

そうすると自由に会話フローを生成できる画面になります。
グレーの部分にカーソルを合わせるとプラスボタンが表示されるのでクリックします。
9.png

そうするとブランチが出てきます。
英語スキルなので、適当に英語のセリフを入れてみます。
このとき、記号、図、フォントの太字斜体指定などができますが、Alexaの読み上げに効果をつけられるわけではないのでここでは使用しません。
10.png

入力規則などはこの「Cheatsheet」を見るとだいたいわかります。
例えば行頭を「//」で始めるとユーザーの発話の指定になります。
行頭が「==」で始めるセリフを複数行入力しておくと、Alexaがその中からランダムに1行選択し、セリフを話します。
11.png

ブランチをクリックするとクリックするとブランチのスタイルを選択できます。
ただし、無料プランでできるのは内側の円の中から色を選択するのみで、
外側の円からの色選択、ブランチの太さの指定などは有料プランになります。
ブランチの色を変更するとそのブランチより先の枝の方の色が一斉に変更されます。

ブランチを右クリックするとブランチの追加・削除・コピー・移動、コメント追加ができます。

ここからブラウザテストもできます。
12.png

「Start playing」で会話フローの「Start」の位置から自動再生、
プルダウンから会話フローの開始地点を指定することもできます。
ユーザーの音声入力シーンになるとマイク許可を求められるので承認します。
13.png

会話フローが完成したらAlexaスキルとして展開してみましょう。
「Deproy」をクリックするとAmazonアカウントとAWS開発者アカウントの登録画面になります。このとき、ASKを始めるところまで進めていないとデプロイが実行されないようなので注意してください。
14.png

「Deploy」ボタンの横に緑のチェックマークが表示されたらAlexaスキル作成完了です。
アマゾンアプリ開発者ポータルにスキルが作成されていると思います。
「テスト」を有効にするように促されるので、その他にも一通りスキルの設定をしましょう。

設定のポイントは呼び出し名を下記のように単語で区切った状態で指定することです。
造語だとなかなかうまく反応しません。
複数の言葉を組み合わせたものがいいと思います。

ここでの設定内容は「Deploy」ボタンを押すたびに元に戻るのでどう設定したかメモした方がいいかもしれません。
呼び出し名の調整以外は、設定しなくても実機テストは可能です。

英語版のスキルなので、実機でテストするには「alexa.amazon.com」に登録されているAlexa対応端末が必要です。
この一覧に先ほど作成されたスキルが表示されると思うので有効にします。
※同じ端末を英語スキルを扱う「alexa.amazon.com」と日本語スキルを扱う「alexa.amazon.co.jp」の両方に登録することはできないようです。
登録先を切り替えるとWifi設定からスタートすることにになりますが、有効にしたスキル情報などは切り替え後も保持されます。

StoryLineは、画面右下の「Conversations」から気軽に問い合わせできる点もよかったです。
アカウントを自分で削除することができないため、ここから依頼したのですが、
対応してくれたスタッフは非常に気さくで対応も結構スムーズでした。

以上です。
今回は英語版スキルの開発ツールでしたが、日本語対応のスキル作成ツールも使ってみたいですね!

参考

音声アプリ戦国時代の救世主?プログラミング無しでAlexa Skillが作れる「Storyline」
【祝Alexa日本上陸】とりあえず日本語でスキルを作ってみる
開発中のAlexaスキルを実機テストする方法

Pocket

Standard Queue から FIFO Queue へ移行した話

Pocket

この記事は ハンズラボ Advent Calendar 2017 13日目の記事です。
こんにちは、最近、社会人1年目が過ぎた村上です。

今回システム的な問題を解決すべく、ECサイトハンズネットの裏側で動いているSQS(Simple Queue Service)のスタンダードキューの一部をFIFOキューへ移行した話を書きたいと思います。
Tokyoリージョンは2017年上旬予定と聞いたのですが、AWSコンソールを見てみると2017/12/15現在、未だリリースされていないようです。オレゴン、オハイオ、バージニア北部、EU(Ireland) のリージョンは利用できます。
細かい説明はAWS公式に任せて、スタンダードキューとFIFOキューの主な違い、移行の経緯やFIFO特有の設定についてお話しできればと思います。

 

スタンダードキューとFIFOキューの主な違い

 
まずは簡単にスタンダードキューとFIFOキューの違いについて触れます。

上記表にあるように順番についてはスタンダードはベストエフォートとあり、まれに順番を守れない事があります。「大量の画像データをある形式に従って変換する」といった処理の順番を気にしない用途には向いていると思います。しかし、今回の改修対象についてですが、順番を誤ってはいけない場所で使われています。詳しくは次節で。

また、メッセージの配信回数なのですが、スタンダードキューはまれに同じメッセージが複数回配信されることがあるので注意が必要です。

 

なぜFIFOに移行したのか

 

ユーザからの不具合報告

一般的なECサイト同様、ハンズネットで注文した後に、注文済みの商品の数量変更やキャンセルができます。それらの操作が注文履歴画面に反映されないという不具合がユーザから報告される事が定期的にあったため調査しました。その結果、SQSのスタンダードキューを使ったデータ連携が怪しく、部分的にFIFOキューへ移行することにしました。

スダンダードキューは順番を守れないことがある

このシステムの注文データの反映方法は2通りあります(なぜ、二通りあるのかは一口では語れないです 汗)。

(1) 注文後、リアルタイムでDynamoDBを更新
(2) テキスト形式のデータが、SQSのスタンダードキューを通ってDynamoDBへ反映(非同期)

[改修後イメージ、スタンダード、FIFOが共存]

 

(2)についてですが、スタンダードキュー内で注文データの順序が守られていないのではないかという懸念がありました。このDynamoDBの注文レコードは上書きされる仕様となっていたため、順序を誤ると古いデータが最新の状態として画面に表示されることになっていました。
以前は注文データは画像上部のスタンダードキューを通っていましたが、今回画像下部のFIFOキューを追加し、問題のあった注文データのみFIFOキューを通るように変更しました。FIFOであれば、キューへ送った順に取り出されるので注文データが順番を誤まる心配がなくなるというわけです。

次節以降ではFIFO特有の設定とについて少し書きます。

【補足】 ハンズネットがユニケージ開発手法で開発され、そこから移行しようとしている(Bash→PHP, ファイル→DB)という特殊な事情もあり、少し複雑なシステムとなっています。いずれは上記の(2)のテキスト形式レコードをDynamoへ反映する処理は無くしたいと考えています。

 

FIFO特有の設定

 
FIFO Queueの作成自体は設定を気にしなければ数秒で終わりますが、導入する際は最低でもメッセージ重複排除IDと、メッセージグループIDについては少し考慮した方が良さそうです。

メッセージ重複排除ID

適宜、公式より説明を拝借します。

メッセージ重複排除ID: 送信されたメッセージの重複排除に使用するトークン。特定のメッセージ重複排除 ID を持つメッセージが正常に送信された場合、同じメッセージ重複排除 ID を持つ送信メッセージは正常に受け付けられますが、5 分間の重複排除間隔の間は配信されません。

 
とAWS公式に書いてありますが、この説明は私にはわかりづらく、もう少し読むと

スタンダード キューとは異なり、FIFO キューでは重複メッセージがありません。FIFO キューを使用すると、重複をキューに送信することを防止できます。5 分間の重複排除間隔内に SendMessage アクションを再試行しても、Amazon SQS ではキューに重複を挿入しません

 
とのことです。要するに、「同一の重複排除IDが設定されたメッセージをキューへ送っても5分間の間は受付けられない」ということのようです。

ちなみに、重複排除IDの設定についてですが、二通り方法があります。
(1) FIFO作成時に設定
(2) sendMessage時にDeduplicateIdを指定

(1)の方が楽だったので、以下のようにFIFO作成時に設定しました。

メッセージグループID

AWS公式より

メッセージグループID: 特定のメッセージグループに属するメッセージを指定するタグ。同じメッセージグループに属するメッセージは、メッセージグループに相対的な厳密な順序で、常に 1 つずつ処理されます (ただし、別のメッセージグループに属するメッセージは、入れ替わって処理される場合があります)。

 
との事です。こちらも少し分かりづらいですが、「グループ内の順序は厳密に守られるが、他のグループのメッセージとは順番が前後する場合がある」と理解しました。
今回はキューに入れた順に取り出されれば良かったので、特にグループは気にせず、以下のようにMessageGroupIdには定値を入れました。

移行後談

 
移行後、半年ほど経ち、その間ハンズメッセというセールも経験しましたが、問題報告はありません。あとは、TokyoリージョンにFIFOがリリースされれば、そちらに移ろうかという所です。

明日は14日目のsho-hitomiさんです。

Pocket