Recommended
More Related Content
What's hot
What's hot (20)
Similar to 弊社IoT事例とAlexaSkil開発レシピ
Similar to 弊社IoT事例とAlexaSkil開発レシピ (20)
Recently uploaded
Recently uploaded (14)
弊社IoT事例とAlexaSkil開発レシピ
- 2. Agenda 1. 自己紹介 2. 弊社IoT/サーバレス事例 IoT/サーバレス化ご相談数の遷移 事例1. IoT案件 水田水量等計測 事例2. バッチ処理の効率化 事例3. サーバレスでSPAのバックエンド/バッチ処理 まとめ 3. AlexaSkill開発レシピ Alexa登場までのAI史、米国でのAlexaの利用のされ方について AlexaSkill開発の流れ、開発・公開に辺り気をつける点 Alexaの今後の展開 まとめ 2
- 3. 自己紹介 株式会社スカイアーチネットワークス 開発部エキスパート 神津 崇士 (こうづ たかし） tktk19 http://kouzu.info 前職 ASPサービスの企画・開発・運用まで全てを担当 サービス提供企業数が年間100社程スケール → 負荷が増大する中でインフ ラ設計・保守業務の重要性や楽しさを経験 現在 2010年よりスカイアーチでは様々な角度から（Infrastructure as Code、 CI/CD等）お客様のサーバ構築・運用業務にまつわる自動化などを担当 最近は特にサーバレスなAWSインフラ設計・構築にも多く携わり お客様要求仕様(サーバレスアーキテクチャ・IoT等)のPoC、API開発に精力 的に取り組んでおります。 3 SA Pro 4/20失効
- 4. Agenda 1. 自己紹介 2. 弊社IoT/サーバレス事例 IoT/サーバレス化ご相談数の遷移 事例1. IoT案件 水田水量等計測 事例2. バッチ処理の効率化 事例3. サーバレスでSPAのバックエンド/バッチ処理 まとめ 3. AlexaSkill開発レシピ Alexa登場までのAI史、米国でのAlexaの利用のされ方について AlexaSkill開発の流れ、開発・公開に辺り気をつける点 Alexaの今後の展開 まとめ 4
- 5. クラウドでサービス構築 過去から現在 5 4年前 AWSをクラウド基盤として採用する企業が少しづつ出始める EC2（サーバ）のみで作成された物が大半 3年前 AWSをクラウド基盤として採用する企業が多く出始める ELB（ロードバランサ）、EC2、RDS（PaaSのDBサービス） で作成された物が大半 AWS顧客数の増加に伴いInfrastructure AS Codeを急ピッチで進める 2年前 AWSをクラウド基盤として採用する企業が90%程 S3でのイメージホスティングやAutoscale機能の活用 Elastic Beanstalk等 アプリケーションデプロイのみで インフラ自動構築・運用サービス利用が出て来る 2013 2014 2015 2016 2017 弊社お客様 - AWS利用 企業数
- 6. クラウドでサービス構築 過去から現在 6 1年前 IoTやBigDataをキーワードにRedshiftやDynamoDBの利用シーンが増える APIGatewayを利用した案件、及びAPI開発案件のお引き合いを頂く SQSやElasticacheの利用事例も増える 今年 サーバレスをキーワードにした開発案件のお引き合いを多数頂く EC2 Container Service（Docker）、サーバレス環境でのCI/CD環境構築についても お引き合いを多数頂く → これまでAWSをサーバ中心で利用していた方々が サーバレスを実践・採用し始めている！
- 7. 7 IoT/サーバレス案件状況の推移 IoT案件 = データ受信基盤構築→データ見える化を行いたい+αの案件 サーバレス案件 = 既存システムの（部分）サーバレス化、新規案件 2015年 2016年 2017年 2018年 ご提案段階まで進んだIoT/サーバレス案件ご相談数 1~4月迄ですが 既に前年より多くご相 談頂いております。
- 9. 9 事例1. IoT案件 ご相談頂いた内容 • 大量のGatewayから大量の CSVを同時にアップしDBに取 り込みたい • 1ヶ月程で取り急ぎ動くPoCを 実施したい • マルチテナント/共通プラット フォーム • 維持費を安くしたい • AWSノウハウが少ない • DynamoDBは利用した事無し • サンプルコードが欲しい • APIは自分たちで拡張したい 水位、水温、地温 センサ etc… ＋ゲートウェイ
- 10. 10 Gateway ① Login/GetToken ② Upload ③ S3 PutEvent Invokes Lambda ④ Import Data TTL 1week ⑤ DynamDBStreams → Kinesis ⑦ S3DataPut ⑧ RDSへデータをロード LOAD DATA FROM S3… ⑥ データ変換 Amazon RDS (Aurora) 事例1. IoT案件 全体構成図 利用者端末 データ取得 データ整形 簡易バッチ 通知 10分以内の最新Dummy データがRDSに存在するか？ 5分毎にDummyCSVをUp データのバッファリングを実施し まとめてRDSへインポート
- 11. 11 事例1. IoT案件 PoCフェイズでの性能テスト実施結果 負荷試験回数 アップロードCSV数 レコード数 取り込み成功率 1回目 10,800個 (6時間) 432,000個 100.0% 2回目 10,800個 (6時間) 431,985個 99.99% (15レコード欠損) 3回目 10,800個 (6時間) 432,000個 100.0% 4回目 10,800個 (6時間) 432,000個 100.0% Aurora t2.small 月額 50$程 本番では Up+MultiAZ DynamoDB WC = 100 月額 $55程 想定の十倍以上のデータ量でも安定して捌ける事を確認
- 12. 12 事例1. IoT案件 納品物等 Amazon Cognito (認証) サンプルコード for CSVUpload Node.jsにてCognitoアクセス → S3へCSVアップロードサンプルコード Amazon API Gateway サンプルコード for API AWS製Framework Chalice を利用し、RDSへのアクセス 任意のSQL実行結果をJsonで 返却するサンプルコード 負荷テスト 作成した構成への負荷テスト API系の場合はJMeter等 CSVUpload等はLambdaで 試験結果のレポート サンプルコード for Cognito JavaにてCognitoアクセス → Token取得の実施サンプルコード サンプルWebアプリ for Cognito S3WebHosting JavaScriptにてCognito アクセス → Token取得の実施Webアプリ提供 構成図 仕様書 初期構築手順 CloudFormation 運用手順 アラート バックアップ Lambda監視 サービス監視Lambdaコード CloudWatch + SNSで任意 メールアドレスへの通知 AWS Lambda ドキュメント
- 13. 13 事例1. IoT案件 振り返り 実現できた事 • 大量のGatewayから大量のCSVを同時にアップし DBに取り込みたい → サービス開始数年後の想定でも捌ける事を確認 • 1ヶ月程で取り急ぎ動くPoCを実施したい → 認証無しのPoC構成は2週間でお引渡し • マルチテナント/共通プラットフォーム → シンプルな構成のため、水田に限らず温度・湿度のみをロ ギングするようなサービスにも利用可能となった • 維持費を安くしたい → RDSを除くと捌いたデータ量に応じた従量課金で動くシス テムとなった、月額 数万円で稼働可能に 水位、水温、地温 センサ ＋ゲートウェイ
- 14. 14 事例2 バッチ処理の効率化
- 15. 15 バッチ処理の効率化案件 ご相談頂いた内容 • 処理に時間の掛かる バッチ実行環境の構築 c4.8xでも数時間かかる • コスト最適化のため サーバの常時稼働を 最小限に抑え、維持費を 安くしたい
- 16. 16 バッチ処理の効率化案件 Amazon S3 AMIより生成された バッチサーバ群 Web server With MySQL バッチサーバ AMI （イメージ） Job管理システムでJob実行命令 ①インスタンス生成 Userdata にてJobId 等引き渡し ②最新のスクリプト及び 処理データをS3より ダウンロード ④バッチ実行 ⑤S3へ結果・ログを アップロード ⑥自身をTerminate ③ JobIdに一致 するファイル取得 バッチ処理データ スクリプト instance_id job_id Instance_status job_status i-0ebf9373931c69312 20171030 Terminated Finished i-0ebf9373931c69312 20171031 Running Running 定期的に想定外の長期間起動インスタンスや、 teminate失敗インスタンスがないか確認 存在したらterminate • Webサーバにジョブ登録・ 管理システムが動作 • Jobが登録された時にバッチ サーバはOnDemandでバッ チJobの数だけ起動 • 処理データはS3から取得さ れ、結果がS3に保存される • ジョブ登録・管理システムに て結果をダウンロード ※頻繁なバッチ実行であればAWSBatch等、よ り適したプロダクトを検討
- 17. 17 バッチ処理の効率化案件 実現できた事 • 処理に時間の掛かるバッチ実行環境の構築 c4.8xでも数時間かかる → 並列でバッチリクエストが来ても捌けるようになった • コスト最適化のため サーバの常時稼働を最小限に抑え、維持費 を安くしたい → Webサーバを除き、バッチ実行時のみの従量課金で動作 するシステムを構築できました • 構築に掛かった時間 → 3週間程 既にS3上でファイルをやり取りする構成となっていたため、 変換エンジン・バッチ結合自体は短期間で完了したがマシン イメージの完成、AWS他サービス検討で時間が掛かった
- 19. 19 Single Page Application事例 ブラウザ APサーバ SPAならサーバレスでも！動かせます ページ表示 ページ生成 Logic & State Data これまでのWeb SinglePageApplication ページ生成 Logic & State Data API Integration EC2 ログイン認証
- 20. 20 サーバレスでSPAバックエンドの構築 API client 管理画面 一般ユーザ画面 mobile client Amazon CloudFront Amazon CloudFront AWS WAF AWS WAF アクセス元 IPアドレス制限 DoS攻撃等制限 Amazon Cognito ログイン認証 定期実行Lambda レスポンス確認 RDSでは扱いき れないデータ量 のため DynamoDBを 選択
- 21. ③ 三次元モデル表示（操作）サーバレスでSPAバックエンドの構築 データ取り込み・吐き出しバッチ client bucket-export bucket-import 定期実行 Lambda csv インポート処理 エクスポート処理 S3 PutEvent 並列実行抑制を行い 少しづつEMR立ち上げ EMR with Custom JAR エクスポートは CSVファイル生成 csv 完了通知 アップロード APIリクエスト ※簡略図 EMR (並列実行1) インポートは DynamoDBへ書き込み Job登録 Lambdaでは処理できない大きいサイズのCSV取り込み・エクスポート を（本来はFargate等で処理したい所ですが…）現状日本リージョンで出来 る選択肢として、EMRで実装しました。 21
- 23. 23 サーバレスまとめ ①美味い… マネージ不要、ミドルウェア等の脆弱性対応等々が不要 ②早い… トリガに応じて起動、自動スケーリング ③安い… 完全従量のため利用しなければ無課金 （※常時演算をするケースだとサーバ建てた方が安い） IaaS や PaaSといった言葉に当てこめ FaaS (Function as a Service) と呼ぶ事も
- 25. モバイルサービス Mobile Analytics, Cognito, SNS お客様のアプリケーション コンテンツ配信 CloudFront ネットワーク VPC, Route 53, Direct Connect 認証とログ IAM, Cloud Trail, Cloud HSM, Config モニタリング Cloud Watch, Trusted Advisor デプロイと自動化 Elastic Beanstalk, Cloud Formation, OpsWorks 管理インター フェイス Management Console, CLI ライブラリ & SDKs Java, PHP, .NET, Python, Ruby グローバルインフラ リージョン、アベイラビリティゾーン、エッジロケーションAZRegion コンピュート処理 EC2, Auto Scaling, Lambda Elastic Load Balancing, EC2 Container Service エンタープライズアプリケーション WorkSpaces, WorkDocs, WorkMail ストレージ EBS, S3, Glacier, Storage Gateway データベース RDS, DynamoDB, Redshift, ElastiCache 分析 Elastic MapReduce, Kinesis, Data Pipeline アプリケーションサービス AppStream, Cloud Search, SWF, SQS, SES, ディレクトリ Directory Service コード管理 CodeDeploy, CodeCommit, CodePipeline 90以上のAWSサービス群 従来の「インフラ」の定義部分はごく僅か 25
- 26. 2009 2010 2011 2012 2013 2014 2015 2016 2017 82 159 280 516 4824 722 1017 AWSの機能拡張・改善のスピード まだまだ増える・Updateされる 26 出典: https://aws.amazon.com/jp/choosing-a-cloud-platform/
- 29. 各PaaSについて 29 AWS Lambda • 呼び出し方法について • 気をつけるべき点 • 定期実行方法について • 制限 • パフォーマンスについて • このプロジェクトでの利用のされ方 • Lambda関数呼び出し設定 イベントとハンドラ • 環境変数の利用について
- 30. Lambda Lambdaで気をつけるべき点1 • 冪等性の担保 例) 許容できないケース • クリティカルなバッチ処理をCloudWatch Scheduled Events（後述）で毎日X時に実行する • S3へのFilePutEventでなんらかの処理を行っているが複数回処理されると結果に影響が出てしまう • APIGatewayにリクエストされた回数と後続先の処理回数を確実に同じにする必要がある → DynamoDB等を利用し、実施済みIDの管理や、フラグ管理を実施する 30 出典: https://www.slideshare.net/keisuke69/aws-lambda-amazon-api-gateway-deep-dive
- 32. 各PaaSについて 32 Amazon DynamoDB • どのような機能があるか • 気をつける点 • このプロジェクトでの利用のされ方
- 33. DynamoDB 33 条件付き書き込みで プログラムの簡略化＆必要なキャパシティの最適化 こちらのプロジェクトのCSV取り込みバッチ部分で当初は下記のような操作をおこなっておりま した。 DynamoDB上にPKeyとなる値が存在しないか確認 → DynamoDB上に書き込み DynamoDBには整合性を担保して書き込む事の出来る条件付き書き込みという機能があり こちらを利用することで上記を一度に実施する事が可能です。 書き込みオペレーションでは、書き込みキャパシティユニットのみが消費されます。 出典 : https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/WorkingWithItems.html
- 34. Agenda 1. 自己紹介 2. 弊社IoT/サーバレス事例 IoT/サーバレス化ご相談数の遷移 事例1. IoT案件 水田水量等計測 事例2. バッチ処理の効率化 事例3. サーバレスでSPAのバックエンド/バッチ処理 まとめ 3. AlexaSkill開発レシピ Alexa登場までのAI史、米国でのAlexaの利用のされ方について AlexaSkill開発の流れ、開発・公開に辺り気をつける点 Alexaの今後の展開 まとめ 34
- 36. 36 AIの歴史 第１次AIブーム（1956〜1960年代） 人工知能（Artificial Intelligence）という言葉が決まる 世界最初のコンピュータENIAC (1946)のわずか10年後 第２次AIブーム（1980年代） エキスパートシステム(専門家の知識をコンピュータに移植すること により現実の複雑な問題を人工知能に解かせる) 第３次AIブーム（2013年〜） ウェブとビッグデータの発展 計算機の能力の向上 データから学習する人工知能 物知りな人工知能 考えるのが早い人工知能 推論・検索の時代 知識の時代 機械学習・ディープラーニングの時代 ジェフリー・ヒントンらによりオートエンコーダおよびディープ・ビリーフ・ ネットワークが提案され、これが、ディープラーニングへと発展した。 ニューラルネットワーク冬の時代 Googlebrainが1,000サーバ 16,000コアで3日間学習を続け猫の画像に反応する ニューラルネットワークを構築 ILSVRC(画像認識の競技会)でディープラーニングを用いた劇的な認識率の向上 2012年 2006年 2007年 初代Tesla発売 1997年 IBM DeepBlueが チェスチャンピョ ンに勝利 汎用性が高く実用性が高まった
- 39. 39 音声認識システムの課題 従来の課題 具体例 課題改善の状況 音声認識システムの使い勝手 ・雑音がある環境下 ・会話のかぶり(機械側) ・動きながらの会話 AmazonEchoなどのスマート スピーカーなどの普及により 改善 音声認識や対話の基本性能 ・低認識率や応答遅延 ・方言や言葉のクセ認識 ・文脈や声質が不自然 ディープラーニングの発展に より大幅に改善 より人間らしい対話の実現 ・感情や間のとり方 ・音声の抑揚 ・対話者以外の状況把握 発展途上 Tacotron 2,DeepVoice3 等 各社がTTSエンジン開発中
- 51. AlexaSkillKit開発者コンソールにアクセス＆入力 51 コア部分はこれだけ！ PoCレベルならば短期間で開発可能！ 〜を開いて 〜歌って 〜読んで ※Alexa Skills SDK の公式対応はJava/Node.jsのみ
- 57. 一筋縄では行かないスキル申請 たったこれだけのスキルなのに、3回 弾かれました… orz しっかりとユーザビリティを考えた設計にする必要があるので注意が必要です！ • 迷子対策が必須 ユーザーがスキル内の「ヘルプ」をリクエストした際、スキルはユーザーにスキル のコア機能の操作方法を示すプロンプトを返す必要があります。 • 途中停止・再生が必須 音楽・音声再生は途中で一時停止する/再開する/次という呼びかけに対応出来る必 要あり • 再開処理が必須 再開する物が無い時は再開するものが無いため終了します等伝える 57
- 58. 大切なこと 1. ターゲットを決める・実施出来る事を絞る！ 2. VUIデザインが命！ 3. 人の話し方は様々なので、揺れの吸収が必要 58
- 61. 音声認識が作る未来 61 “VOICE UNLOCKS DIGITAL SYSTEM FOR EVERYONE” ワーナー・ヴォゲルスCTOのキーノートより
- 63. 顧客満足度の最大化 – マルチチャンネルでのサービス提供 63 家 – Alexa, 通勤中 – AmazonConnect(電話)、オフィスでは…
- 64. 顧客満足度の最大化 – マルチチャンネルでのサービス提供 64 オフィスではAmazon Lumberyardの RinさんがVirtual秘書！
- 66. 66 Agenda まとめ
- 68. 68 まだまだ日本には少ないAlexa公開スキル 「教育・レファレンス」スキルが日本ではまだ少ない 日本は多言語学習が主流だが、米国は歴史、聖書、ライフハック、宇宙情報 など多岐に渡ったスキルがある 米 国 スキル数:3万超 日 本 スキル数:600超 出典: https://robotstart.info/ 2018年3末時点の日本公開スキル数 https://www.voicebot.ai/ 2018年3末時点でアメリカ公開スキル数