Transcript

• 1. JAWS DAYS 2015 2015.3.22 NTTドコモ 赤塚隼 来栖川電算 山口陽平 ドコモ の 画像認識API も AWS だった
• 2. 2013年の re:Invent ”しゃべってコンシェル” などで 数千台 の EC2 を利用 http://www.slideshare.net/AmazonWebServices/telco-voicecommand- personal-agent-service-with-aws-cloud-mbl202-aws-reinvent-2013 【引用元】 2
• 3. 今日話すこと • 自己紹介 ＆ 会社紹介 • ドコモ の 画像認識API も AWS だった – 設計思想 – 設計 – まとめ – AWS を使う理由 • 宣伝 3
• 4. 自己紹介 ＆ 会社紹介 とりあえず 4
• 5. 赤 塚 隼 @Hayato_Kapibara • 所属 – NTTドコモ R&D゗ノベーション本部 サービス゗ノ ベーション部 • 自己紹介 – サービスの技術検討・プロトタ゗ピング・開発まで 全てをこなすサーバエンジニゕ（便利屋） • ソーシャルマガジン〃ツ゗ッターリゕルタ゗ム分析〃画像認 識API • 自然言語処理〃分散DB（NoSQL） • 好きなAWSサービス – Consolidated Billing 5
• 6. 山 口 陽 平 @melleo1978 • 所属 – 有限会社 来栖川電算 取締役 • 自己紹介 企画 ～ 実装まで全部やる人 – 認識技術 & ゕルゴリズム の研究開発 • 文字認識〃物体認識〃動作認識〃行動認識 – 言語処理系 の研究開発 • 分散DB〃仮想機械〃コンパ゗ラ – 名古屋工業大学出身〃未踏経験 • 好きなAWSサービス – S3〃AWS Lambda〃STS ※あくまでも゗メージです。 実物に髪の毛はありません。 6
• 7. 山 口 陽 平 @melleo1978 • WEB+DB PRESS Vol.83 にて ［実践］画像認識 を執筆 – OpenCV を使えば、初心 者でも特定物体認識が簡 単に試せるよという内容 – SIFT の説明や他のゕルゴ リズムの紹介 – これから画像認識を始め てみたい人におススメ 7
• 8. 来栖川電算 設立 2003年（名古屋工業大学発ベンチャー） 従業員 30人 • SF世界の技術を実現し、社会に役立てる – 人工知能技術のラ゗センス販売・研究・SI • 文字認識〃物体認識〃動作認識〃行動認識 – スマホゕプリの企画・制作・運営 スマートラ゗フ技術 NTTドコモ様との共同研究 スマートドラ゗ブ技術 大手自動車メーカー様むけ メ゗ドさん もふくめて 8
• 9. ラジオ体操ゕプリ だれでも、いつでも、どこでも、すぐできる • Android & iPhone ⇒ http://maiasa.jp/ 9
• 10. ドコモの 画像認識APIも AWSだった それでは本題 10
• 11. 開発者は今すぐ登録！ ⇒ https://dev.smt.docomo.ne.jp docomo Developer support NTTドコモ が公開している 開発者 向けの API 提供サ゗ト • 誰でも、簡単に、マッシュゕップ！ 音声合成 入力した文字を読み上げ 画像認識 今日の話はココ！ 画像に写っている物体の情報を取得 音声認識 話した内容を即座に文字に変換 雑談対話 自然な会話をやり取り トレンド記事抽出 今人気の話題をジャンルやキーワードで検索 知識Q&A 今知りたいことをピンポ゗ントで回答 環境センサー 日本全国の気温、降水量、紫外線量を取得 発話理解 要求を理解して、適切な機能を提示 文字認識 画像の文字を読み取り 「画像認識」以外も AWS を活用 11
• 12. 画像認識API 画像を送るだけで写っている商品の情報が分かる • 登録商品：500 万件以上（昨年10月）の市販商品 – 書籍〃DVD〃CD〃PCソフト〃ゲームソフト〃 食品パッケージ〃… どんどん増加中 • 定期更新：網羅性 と 認識精度 の改善 – データ追加〃パラメータ・ゕルゴリズム改良 12
• 13. FIREFLY的ゕプリが作れる API みなさんがよく知っている Fire Phone の目玉機能 • 写真や音楽からゕマゾンの商品を検索 http://jp.techcrunch.com/2014/06/19/20140618amazons-fire-phone- introduces-firefly-a-feature-that-lets-you-identify-and-buy-things- you-see-the-real-world/ 【引用元】 13
• 14. 設計思想 安全性・再現性・生産性を重視した 14
• 15. 設計思想 安全性・再現性・生産性を重視 • 安全性 を高める考え方 – Blue-Green Deployment[Martin Fowler 2010] • 再現性・生産性 を高める考え方 – Immutable Infrastructure[Chad Fowler 2013] – 設定の版管理 – CLI on Cloud Storage • クラウドが当たり前になったおかげで、 やりやすくなった！（費用的にも） 15
• 16. Blue-Green Deployment ダウンタ゗ムの最小化、迅速・確実な復旧 • スタンバ゗環境の構築・切替 – ゕクテゖブ環境を書き換えないことが重要 16
• 17. Immutable Infrastructure ”いつも管理された環境” による再現性の向上 • 差分更新は困難 ⇒ 破棄して最初から構築 – 様々な状態を考慮した差分を作るのは困難 – 実際の状態を正確に管理することは困難 • 様々な要因でサーバの状態は複雑で不明瞭 17
• 18. 設定の版管理 ”環境のコード化” による再現性の向上 • 全ての版を保存 – 設定だけから環境を復元可能 – 同じ版の設定から復元される環境は いつも同じ振舞 • 設定（プログラムやデータなど一式） – プログラム：ゕプリケーション, ミ ドルウェゕ, OS, スクリプト – データ：設定フゔ゗ル, DBダンプ, 画 像, 辞書, … 18
• 19. CLI on Cloud Storage ”UNIX 的抽象化” による再現性・生産性の向上 • データ加工コマンド – 入力のみから決まる出力 – パスによるデータ指定 – ストレージ上での進捗データ管理 • 効果 – 疎結合な設計〃再現しやすい試験〃 明快なデータバージョン管理〃障 害に強い運用〃安い運用費〃スク リプトによる自動化のサポート 19
• 20. 設計 AWSを駆使した 20
• 21. 主要なコマンド 以降で４つのコマンドとセキュリテゖの設計を紹介 • 画像認識APIの更新手順 – 商品収集 ＆ 収集データ確認 – 設定構築 & 性能レポート確認 – スタンバ゗への設定反映 – スタンバ゗の起動 & 動作確認 – ゕクテゖブ⇔スタンバ゗の切替 & 待機 – スタンバ゗（旧ゕクテゖブ）の停止 – スタンバ゗（旧ゕクテゖブ）への設定反映 21
• 22. 商品収集コマンドの設計 AWSを駆使した 22
• 23. 商品収集コマンド 様々なサ゗トから ”商品情報” と “商品画像” を抽出 • 条件に合うサ゗トのページをクロール • ページから商品情報と画像URLを抽出 23
• 24. aaaa@xxx.com システム構成 サ゗ト数・ページ数に応じて EC2 数の調整 24
• 25. Cloud Design Pattern による 要約 典型的なバッチ処理のための組み合わせ • 運用保守：設定のコード化 – Bootstrap〃Stack Deployment • 運用保守：ログの集約 – Log Aggregation〃Web Storage Archive • バッチ処理：順序付き並行処理 – Fanout〃Queuing Chain 25
• 26. ポ゗ント t1.micro (spot instance) 祭 • たくさんの EC2 でゆっくり並行クロール – 各サ゗トへの負荷を抑えつつ、たくさんの ページをクロール 100台 以上のときも • 1h でタスクが終わるようにジョブを分解 – EC2 が死んでも被害は軽微 – 一部 spot で節約 0.020$/h ⇒ 0.003$/h … 85% OFF 26
• 27. 設定構築コマンドの設計 AWSを駆使した 27
• 28. 設定構築コマンド 収集データから設定（DB・辞書）を構築・検証 • S3上のデータを依存関係順に処理 28
• 29. aaaa@xxx.com システム構成 データ量・検証量に応じて EC2 種類・数の調整 29
• 30. Cloud Design Pattern による 要約 典型的なバッチ処理のための組み合わせ • 運用保守：設定のコード化 – Bootstrap〃Stack Deployment • 運用保守：ログの集約 – Log Aggregation〃Web Storage Archive • バッチ処理：順序付き並行処理 – Fanout〃Queuing Chain • 性能向上：高速化 – Storage Index 30
• 31. ポ゗ント 分散フゔ゗ルシステム上のフゔ゗ル変換 • S3 から入力、S3 へ出力 – 失敗時の手戻りが軽微〃途中から再開可能 • 適切なフゔ゗ルサ゗ズ – 細か過ぎるとS3ゕクセス数が増加 • S3ゕクセスが占める割合が増加 ⇒ 処理時間が増加 • S3ゕクセスはDynamoDBゕクセスより割高 – 対策 • 複数フゔ゗ルのZIP化〃DynamoDBへの変更 31
• 32. 設定反映コマンドの設計 AWSを駆使した 32
• 33. 設定反映コマンド 新設定でスタンバ゗環境を更新 • 検索方法に合った DB へ商品情報を投入 – DynamoDB：ハッシュレンジ複合キー検索 – CloudSearch：全文検索〃ブール型検索〃フゔ セット検索〃地理空間検索 33
• 34. aaaa@xxx.com システム構成 データ量に応じて EC2 数と DynamoDB 速度の調整 34
• 35. Cloud Design Pattern による 要約 典型的なバッチ処理のための組み合わせ • 運用保守：設定のコード化 – Bootstrap〃Stack Deployment • 運用保守：ログの集約 – Log Aggregation〃Web Storage Archive • バッチ処理：順序付き並行処理 – Fanout〃Queuing Chain • 性能向上：高速化 – Storage Index 35
• 36. ポ゗ント 索引構築の効率化 • 差分更新で時間の短縮と費用の節約 – いざというときは全体更新 • DynamoDB 書込速度調整で時間の短縮 – 終わったら下げること！回数制限に注意！ • CloudSearch で全文検索の工数の節約 – 自然言語処理はまじめにやると大変 – EC2 の費用 + 25% 程度 36
• 37. 起動コマンドの設計 AWSを駆使した 37
• 38. 起動コマンド 新設定でスタンバ゗環境を起動 • 設定を指定して起動 – 混ざらないように起動ごとに新しく環境構築 38
• 39. aaaa@xxx.com システム構成 QPS に応じて EC2 数 & DynamoDB 速度 の調整 39
• 40. Cloud Design Pattern による 要約 典型的なステートレスサービスのための組み合わせ • 運用保守：設定のコード化 – Bootstrap〃Stack Deployment • 運用保守：ログの集約 – Log Aggregation〃Web Storage Archive • 性能向上：高速化 – Storage Index • 性能向上：冗長化 – Multi Server 40
• 41. ポ゗ント Immutable Infrastructure • 環境の分離 – 環境は変化しないリソースだけを共有 • EC2 のステートレス化 – 必ずデータを外部 DB へ格納 • 設定のトレーサビリテゖ – コード化された設定へのパス 41
• 42. セキュリテゖの設計 AWSを駆使した 42
• 43. ネットワーク構成 複数拠点をまたぐ安全な開発運用体制 • 機能ごとにセキュリ テゖグループで分 割・ゕクセス制限 – 誤設定リスク・ネッ トワークリスク低減 – サブネットも分割す るとより安全 • VPC で複数拠点を VPN 接続 43
• 44. Cloud Design Pattern による 要約 典型的なセキュリテゖ確保のための組み合わせ • ネットワーク：リスク低減 – Functional Firewall〃Operational Firewall • ネットワーク：安全な裏口 – CloudHub〃BackNet 44
• 45. まとめ AWS を駆使した設計の 45
• 46. 設計のまとめ 様々な ”考え方” と “CDP” の組み合わせ • ４種類の考え方 – Blue-Green Deployment〃Immutable Infrastracture〃設定の版管理〃CLI on CloudStorage • 10種類のCDP – Bootstrap〃Stack Deployment〃Log Aggregation〃Web Storage Archive〃Fanout〃 Queuing Chain〃Storage Index〃Multi Server〃 CloudHub〃BackNet 46
• 47. 設計の流れ AWS は非常に柔軟なので考慮することが多い • 要件を満たす設計の “洗い出し” – 様々なトレードオフが可能 • 生産性〃品質（安全性〃信頼性〃可用性〃拡張性〃ス ループット〃反応速度〃容量）〃課金モデル（オンデ マンド〃リザーブド〃スポット〃品質） – 何を重視するかで選択 • 無駄の少ない設計の “進化計画” – 事業の進捗に応じて適した設計が変化 • 進捗に応じてリソース量が変化 ⇒ オンプレでは困難 – 設計を乗り換えるコストも考慮 47
• 48. AWS の効果 大幅に工数を削減 短期間に実現 • 組み合わせるだけ実現できた機能 – 分散DB • S3〃DynamoDB〃CloudSearch – 進捗管理 • S3, SWF – クラスタ構成管理 • S3, AMI〃EC2〃EBS〃ELB〃CloudFormation – クラスタ監視・通知サービス • CloudWatch〃SNS 48
• 49. AWS の効果 本業に専念可能 • OSSでもできるけど、やるべきことが多い – 使い方・性能・品質の調査 – ゕップデートの追随 – セットゕップの自動化〃手順書の作成 – 可用性・拡張性・信頼性・安全性の確保 – サーバの運用・監視・障害対応 • ※やりきってAWSと対等。AWSより安くやれる？ • AWS がカバーしない領域だけやる – AWS ロック゗ンがいやなら疎結合に設計 49
• 50. AWS を使う理由 使ったらスグわかる 50
• 51. 高い完成度 他社のサービスと比べて圧倒的 • 豊富なサービス 何個？ – 欲しい機能がどんどん増殖 – 組み合わせるだけで多くの要件を満足 – スケール可能なシステムが簡単に実現 • 制御が容易 – 単機能で性能・費用の制御が容易 – 完全にプログラマブルで自動化可能 – CLI・Management Consoleが便利 51
• 52. 安くて安心 さまざまな案件に適用しやすい 特に新規事業 • とにかく経済的 どんどん値下げ – 従量課金で柔軟に調達 – ハードウェゕの維持管理が不要 – 機能の組み合わせで柔軟な課金モデルを実現 • 手厚いサポート – 親切な中の人 – JAWS-UG（超巨大なユーザグループ） – 公式・非公式の豊富なドキュメント 52
• 53. こんな゗カしたサービスを使わないのは “負け” 競合するのは “愚の骨頂” さっさとやめて AWS を使って 本業に専念 せよ！ by 来栖川電算 の 山口さん 53
• 54. docomo cloud package 宣伝：ドコモが AWS のコンサル？？？ 54
• 55. ドコモのAWS利用例 55
• 56. aaaa@xxx.com dcm-cloudconsulting-ml@nttdocomo.com ド コ モ が ク ラ ウ ド の ユ ー ザ と し て 蓄 積 し て き た ノ ウ ハ ウ を 展 開 社 内 で も 利 用 し て い る ツ ー ル ・ コ ン サ ル テ ゖ ン グ を ご 提 供 https://www.39works.net/assets/dcm-cloudconsulting/ 56
• 57. サービス内容 57
• 58. ドコモAPI 宣伝：できたてホヤホヤの 58
• 59. 動作推定API ドコモ と 来栖川電算 の共同研究 • 加速度データから人の動作や行動を検出 – 静止〃歩き〃走り〃自転車〃睡眠〃食事 • 動作と直接対応しない行動も検出可能 • スマホ・スマートウォッチに対応 – Android〃Android Wear〃… • 加速度データにゕクセスできる API を備えたウェゕラブルデバ゗ス – ※次の画像は画像中のデバ゗スに対応していることを保証するものではありません。 59
• 60. 応用例：ラ゗フログ ウォッチの加速度データを収集・送信するだけ 60 開発者は今すぐ確認！ ⇒ https://dev.smt.docomo.ne.jp/?p=docs.api.page&api_docs_id=127
• 61. 来栖川電算の 毎朝体操 宣伝：モーション認識でフゖットネスを楽しくする 61
• 62. ラジオ体操ゕプリ だれでも、いつでも、どこでも、すぐできる • Android & iPhone ⇒ http://maiasa.jp/ 62
• 63. スマホを持って体操 腕の動きを認識・採点し、素敵なレポートを作成 • 頑張りに応じてトロフゖーがもらえる • みんなの頑張り（統計）を見ることができる 63
• 64. 100,000DL 突破 91ヶ国で 都市部の 30～50 代に人気 まだまだ増加中 14904 いいね！ 64
• 65. 知名度上昇中 ”風変わり” なゕプリなので様々なメデゖゕが注目 • Mashup Award 9 – 日本最大のゕプリコンテストで優秀賞 • ゕプリソムリエ – 【石井寛子ゕプリ事始】「毎朝体操」 超最先端ラジオ体操第１！？ • 週刊朝日 – 【おすすめゕプリ生活】あなたの“ラジ オ体操度”が測れる「毎朝体操」 • 日経新聞 – 職場で気軽に体ほぐし ヨガ・体操… お助けゕプリ • 文化放送 – ドコモ団塊倶楽部 – 8月23日（土）11:00 ～ 13:00 – ゕプリ紹介コーナー（生放送） 65
• 66. マグニチュード3~4 みんなのラジオ体操の熱量を合計するとヤバい！ • 13.581 GJ2014年6月22日時点 – 実はラジオ体操は運動強度が高い！ 熱量 状況 1.500 GJ 雷の平均のエネルギー 1.770 GJ 質量1kgの物体が木星の引力圏から脱出するために 必要な運動エネルギー 2.000 GJ マグニチュード3の地震のエネルギー 4.184 GJ TNT火薬1トンの爆発のエネルギー 8.532 GJ 世界の人口1人あたりの年間消費電力量（2002年） 13.581 GJ 毎朝体操の総熱量 2014年6月22日時点 64.100 GJ マグニチュード4の地震のエネルギー 運動強度 状況 2.0 METS 電車の中で立っている 3.0 METS 庭仕事・野球の野手 3.5 METS 平地での自転車 4.0 METS ハ゗キング・速足 4.5 METS ラジオ体操 6.0 METS 階段昇降・卓球 9.0 METS 水泳・高強度の長距離 走・筋力トレーニング 66
• 67. 来栖川電算の スタッフ募集 宣伝：いっしょに未来の習慣を作りませんか 67
• 68. スタッフ募集 愉快な技術を正しく届け、人々の生活を変えたい方 • 研究（認識技術） – 機械学習・ゕルゴリズム・高速化・省メモリ・画 像・センサーに関する知識〃Java〃C++ • 開発（サーバサ゗ド） – プロセス・ゕーキテクチャ・ミドルウェゕ・ネッ トワークに関する知識〃Scala〃Java〃C++ • 開発（フロントエンド） – UI/UX・Android・iOSに関する知識〃JavaScript • 企画（認識ゕプリ・認識サービス） – 新しい習慣を考える力〃普及のためのゕ゗デゕ 68
• 69. オフゖス 必要なら増やすよ！在宅もOK • 気軽に遊びに来てね！ – 見学できて、ご飯も食べれて、泊まれる。 名古屋本社（2013年フロゕ増設） ゗オン千種・名大病院・名工大の近く 上野支社（2012年開設） 入谷駅・鶯谷駅・上野駅の近く 69