ラベル Azure の投稿を表示しています。 すべての投稿を表示
ラベル Azure の投稿を表示しています。 すべての投稿を表示

AzureにデータサイエンスVMなるものが増えていた (Azure ML blogメモ)

2016年3月22日火曜日

Azureでササッと立ち上げられるVMとしてデータサイエンス向けのものが増えていたという話です。
TechnetのMachine Learning blog内のhttps://blogs.technet.microsoft.com/machinelearning/2015/11/23/announcing-the-availability-of-the-microsoft-data-science-virtual-machine/という記事(Gopi Kumar氏によるもの)を読んだメモです。
2015年の暮れに公開されていたのですが、全然気付いていませんでした。

データサイエンスVM、なにそれ

AzureのMarketplace(公式やサードパーティのさまざまなVMイメージを探して利用できる仕組み)で作れる、Windowsベースのデータサイエンティスト向けのもろもろ入りVMイメージです。めっちゃすごいもの、というわけではないのですが、環境構築の手間を減らしてくれるえらいやつです。

入っているもの

リストは前述のblogからほぼそのまま抜粋し、コメントをそれぞれにつけていきます。
ここまでは「え、それ普通にUbuntuベースのDockerイメージあたりでよくね?」という感じですが、ここからがWindowsベースのイメージであるうれしみを感じるところです。
  • Visual Studio Community Edition
  • Power BI Desktop
    • 比較的手軽なビジュアライズではやはり強いですしね
  • SQL Server Express Edition
    • これは正直なところいまひとつピンと来ませんでした。本当に規模の小さなデータを扱うとか、お試し利用というタイミング以外はおそらくリモートのSQL Serverインスタンスを利用するだろうなーと思うので
    • まあしかしローカル実行(クラウド上ですが)というのはどの環境でもあるに越したことはないので、全部入りパックに入れておくのは妥当とも思います
  • Azure SDK
    • データを読み込んでくるにも、加工して書き出すにも、何かと使いますからね。大事ですね
しかしカジュアルにVS Community版を入れてくるのは、ライセンス的に企業内利用は微妙なところがありますね。21世紀は個人の時代だ!万歳!!(なんか違う)。
実際に使う際の注意はhttps://azure.microsoft.com/en-us/documentation/articles/machine-learning-data-science-provision-vm/に事細かく書かれているので読んでスタートするのがよさそうです。

about

このエントリは、Azure ML(Machine Learning)のblogから面白そうなエントリを掘り出してポイントをまとめるシリーズです。
前回: Visual StudioのRサポートで出来ること (Azure ML blogメモ)
次回: Project Oxfordに話者識別APIが追加されていた (Technet ML blogメモ)

みんな知らない凄いヤツ はじめようProject Oxford

2015年12月14日月曜日

この記事はMS技術Advent Calendarの14日目のものです。

Project Oxfordとは何か

Project OxfordはMicrosoftの自然データ解釈技術をアプリやサービスへと簡単に取り込めるようにするプロジェクト(Microsoft Project Oxford)です。
2015年4月のMicrosoft主催のデベロッパーカンファレンス(//build 2015)で発表されました。
このカンファレンス時には多少話題になったのですが、実際のSDK提供までにしばらくのタイムラグがあったためあまり最近話題になっていないのが現状です。つまり、ほとんど知られていないので紹介していきますよという話です!
使える機能群には自然言語処理や画像認識など、事前にガンガンとトレーニングをかけた機械学習の権化のようなものがいっぱいあります。MSの技術というよりもMSR(Microsoft Research)の成果を一般転用したものという印象です。

アイドルCortanaさん

Project Oxfordで提供される仕組みを使った実世界のサービスの代表格がWindowsアイドル、Cortanaさんです。iOS界のスーパーアイドルSiriと競い合う感じで日々前へ出ようとしていますね。
コル、コル、タナーーー! みなさん一緒に、「「「コル、コル、タナーーー! 」」」

なぜProject Oxfordが嬉しいのか

みなさんご存知のhttps://how-old.net/、平和の極みみたいなサービスですよね。特に誰も傷つけることなく*1写真からの顔認識とその年齢推定を楽しさへと変えてくれるサービスです。
その昔、face.comというオンラインの顔認識サービスがありました。残念ながらFacebookが買収してサービスをシャットダウンしたので、私は安価/無料で比較的自由に利用できるオンラインの顔認識サービスがなくて厄介だなぁと思っていました。
Project Oxfordでは顔認識サービスも公開されています。顔認識と共に感情の推定もおこなってくれる、なかなかすごいやつです。
私はどちらかというと機械学習したいマンではなくて機械学習結果を使いたいマンなので、ひとまずProject Oxfordのあれこれを触ってみようという次第です*2
[*1] 勝手に他人の画像をアップロードして不快感を生むなどはさすがに例外とさせてください。
[*2] 同じ方面ではGoogleが2015年12月にCloud Vision APIという仕組みの限定プレビュー版を開始したようですね。https://cloud.google.com/vision/

提供されている機能の概要

Project Oxfordで提供する機能は多岐にわたります。ここでは本家サイトの構成に準ずる形で一覧を紹介します。
興味をもった項目はぜひリンクを辿って詳しく調べてみてください。
  • Vision
    • Computer Vision APIs
      • 画像分析、サムネイル生成、OCR(文字認識)
    • Face APIs
      • 顔認識、顔認証、類似顔検索、顔分類、顔識別
    • Emotion APIs
      • 感情認識
    • Video APIs
      • 未公開(実際にはProject Oxfordポータル側では映像の安定化(stabilize)、動き検出、顔認識とトラッキングを制限つきで提供するとあります)
  • Speech
    • Speech APIs
      • 音声認識、音声意図認識、音声合成(TTS)
    • Speaker Recognition APIs
      • 未公開(音声データを突っ込むと話者を識別して返してくれるものになるはず)
    • Custom Recognition Intelligent Service
      • 未公開(IBMのワトソンみたいな、とまではいかないまでも、アプリケーションを音声入力でサクサク使えるようにする仕組みのはず)
  • Language
    • Spell Check APIs
      • スペルチェッカとしての高度な機能(単語区切り位置の間違い訂正、スラング込みの認識、ありがちな名前のスペルミス訂正、文脈中での間違い訂正、最近のブランド名サポート)
    • Language Understanding Intelligent Service(LUIS)
      • 自然言語を使ってアプリケーションを操作する仕組みを簡単に実現する仕組み
一覧の最新版はわりとhttps://github.com/Microsoft/ProjectOxford-ClientSDKにまとまっています。

サポートするプラットフォーム

音声認識系APIが最も対応範囲の広いもので、Windows/iOS/Androidをサポートします。顔認識とCVはWindows/AndroidのSDKを提供しています。スペルチェックと感情認識はWindowsのSDKのみを提供しています。
音声認識など一部の機能はWindows 10に組み込まれているもので、Windows版SDKの内部でそのOS組み込み機能を呼んでいるようです。Windows 10 Mobileでの挙動についてはまだ実機で確認していないので把握できていません*3
[*3] MADOSMAのOTA更新がなかなか来ないのでそろそろマウスショップへ持ち込もうかなと思い始めた昨今です。

利用制限

利用制限はそれぞれのAPIごとに異なります。たとえば音声認識APIでは月間のAPI呼び出し可能回数が5,000回に制限されています。
詳しくはドキュメントを読む必要があります。

音声認識APIことはじめ

まずはこのデモをごらんください。
https://www.projectoxford.ai/demo/speech#recognition
これは、Project Oxfordの本家サイトでホストされている音声認識と音声合成のデモです。PC向けのモダンなWebブラウザで開くと、一切のプラグインを要求することなく音声認識を実現できることがわかるでしょう。
ちなみに音声認識についてはAndroid向けのクイックスタートガイドがあります。Android勢はこちらを参照してください。
そしてProject Oxfordの真骨頂ともいえるRESTのAPIはこのような構成です。もちろんRESTのAPIよりも事前に構成されたC# SDKのほうが使いやすいケースもあるでしょう。そのような場合にはお馴染みのドキュメントを出発点としてAPIを掘り下げられます。

私がやっていること

私は目下、Project Oxfordが提供する音声認識エンジンを使ってWebアプリを作っています。ここでは、この中で中核を担う音声認識部分のコード断片を紹介します。
まずは音声認識クライアントを生成してAPIキーを設定、そして送信する音声のフォーマット指定をおこないます。
  var speechClient = SpeechRecognitionServiceFactory.CreateDataClient(SpeechRecognitionMode.LongDictation, "en-us", API_KEY);
  speechClient.SendAudioFormat(SpeechAudioFormat.create16BitPCMFormat(8000));
SpeechRecognitionModeには短時間版と長時間(最大2分)版の二種類を設定できます。ここでは長時間版(LongDictation)を設定しました。
Project Oxfordが提供する音声認識エンジンで認識できる言語はいくつかあります。具体的にはこのページへ記載されているとおり「英語(US)、英語(英国)、ドイツ語、スペイン語、フランス語、イタリア語、中国語」です。ここでは英語(US)を指定しました。
APIキーは2015年11月まではMicrosoft Azureの管理画面から発行したものを利用していました。この手順はごく最近(2015年12月上旬?)に変わり、https://www.projectoxford.ai/Subscription/Indexへとアクセスして必要なAPIキーを発行するようになりました(図1)。
図1 保持しているProject Oxfordライセンスの一覧
このサイト上から残り利用可能なAPI呼び出し回数なども確認できるようになりました。
さて、コードに戻ります。
音声認識クライアントの初期化を完了したら、続いていくつかコールバックを仕込みます。
音声認識においては
  • 部分結果(認識途中の候補データ)
  • 最終結果(認識完了時の結果データ)
が大切です。最終結果だけを使うケースもありますが、今回は「音声認識実行中であり、何かしらの中間結果が得られている」ことを呼び出し側で判断したかったので次のように両方を利用しています。
  speechClient.OnPartialResponseReceived += async (sender, e) =>
  {
      await SendCommandToClient(new JsonCmd { Command = "partial-result", Parameters = e.PartialResult });
  };
  speechClient.OnResponseReceived += async (sender, e) =>
  {
      var result = e.PhraseResponse.Results.FirstOrDefault();
      if (result == null)
      {
          return;
      }
      var resultObj = new { text = result.MaskedInverseTextNormalizationResult };
      // ...
  };
OnPartialResponseReceivedで得られるのが途中結果、OnResponseReceivedで得られるのが最終結果です。
ここでは最終結果で渡される結果オブジェクト内のMaskedInverseTextNormalizationResultを読み出しています。これは、不適切なワード(いわゆる4-letter wordsなど)を****とマスクした状態で格納したものです。InverseTextNormalizationResultには認識結果がそのまま格納されます。
基本的に音声認識に関わるコードはこれだけです。これに加えて実際にはWebSocket経由でオーディオストリームを受け取って右から左へ流す仕組みや、不要の際に流れてきたデータを一時的に音声認識サーバへ流さず捨てる「ミュート」機能などを持ちますが、根っこの部分はこれだけです。

クロスプラットフォームでの音声認識API利用

音声認識APIは前述のようにWeb版(REST版)のみならずWindows版Android版、iOS版も提供しています。個人的にはWeb版(Rest版)ですべてのプラットフォームをカバーできるならばそれでよかったのですが、この場合に大きな壁となるのがiOSです。
iOSでは残念ながらiOS(Mobile Safari)のWebRTCサポートは弱く、音声キャプチャの機能がいまだに(iOS 9.2時点)存在しません*4
iOS側のサポート状況が改善するのを待つよりは普通にネイティブアプリで組んだほうが良い結果となりそうなので、目下Xamarinを通じてWindows Phone(Windows 10 Mobile)、iOS、Androidで共通利用できるラッパーライブラリを書いているところです。
こういうところでXamarinの楽しさが活きますね!
[*4] BowserというiOS向けのWebRTC機能組み込みWebブラウザを使えばゴリ押し利用できるのですが、いかんせん実験的なWebブラウザで出来がイマイチなので常用に耐えるものではありません。iOS版Firefoxでの音声キャプチャサポートはよ

ASP.NETに関わる部分

今回は音声認識結果をもとに遊ぶ簡単なゲームを作り、そのなかではVS 2015上でASP.NET 5のテンプレを使ってコードを書いてみました。
データの保存にはEF7(Entity Framework 7)を試しに使っているのですけれど、インデックスを張るためのAttributeを探したところなくなったようで難儀しました。結局、EF7では基本的にデータベースの細かな部分をすべてプログラム側コード(EF7の場合はC#)で完結するのではなく、適宜DDLを自前で書くのが良いという思想だと解釈して自分でインデックスをぽちぽちと張るようにしました。
ASP.NET 5系のロードマップ上でEF7自体に大きな手が入る場面はこの先なさそう&これはこれで良いと感じているのですが、EF7としてのプラクティス集(DOs and DON'Ts)が欲しいなと感じたりもしましたとさ。
あっ、Microsoft Azure Web Apps+ASP.NET系の環境でWebSocketを利用する場合には、AzureのPortal上からWebSocket利用オプションを有効にするのを忘れないようにしましょう。私はこれで割とハマりました。

まとめ

Project Oxfordすごいぞい楽しいぞいという話でした。
メインで紹介した音声認識系以外にも楽しい技術がいっぱいなので順次さわっていきたいところです。
明日のMS技術Advent Calendar担当はredwarriorさんです。

Azure App Service上のC#バッチからNode.jsベースのコマンドをさらっと叩く方法(おいしいnpmモジュールの淹れ方)

2015年10月21日水曜日

Azure App ServiceのAzure Web Apps(WebJobs)、なかなかいいです。
AWSのLambdaと似たいわゆるサーバレスなアプリケーションコードホスティングの仕組みですが、特性は割と違います。
  • AWS Lambdaは基本パッケージを50MBに抑えたプログラムを頻繁にデプロイ・破棄する構造
    • さもなくばプログラムの起動後にS3などから別途データを拾ってきて展開する(そしてtmp容量は512MBに制限されている)
    • 利用できるメモリ容量をプライマリとしてそれにCPUリソース量も紐付いた料金体系
  • Azure App Serviceは原則的にリソース予約版がメインで、共有リソース版(Lambdaのような動的アプリ展開版)はおまけ扱い
    • 共有リソース版でも最大1GBという比較的大きなアセンブリ群をホストして比較的低頻度デプロイをする想定
    • Lambdaのようにms単位でのコード実行とは謳わない
    • (個人的にはもっと共有リソース版のプラン種類を増やしてほしい)
実行ノードからアプリがアンロードされた状態からのデータロードと処理実行は、きちんと計測していませんがLambdaのほうが体感速いです。
このように実行モデルが異なるので直接比較はできませんが、Azure Web Serviceは小規模・リソース共有版なら1日あたり60分のCPU利用まで無料で使えます。こまごましたバッチを試作するのにうってつけです。

Azure上でC#とNode.jsのいいとこ取りをしたい

Node.jsというかnpm上には豊富なパッケージが存在します。
なかにはNuGetに同等のものがあるものも存在しますが、Node.js界隈に特有のものやNuGetを探すのが面倒なものも多くあります。
最近はAzure Web AppsのWebJobs(指定URLのキックによる逐次処理、定期バッチ処理、継続実行処理のデプロイモデルを選べる)を使ってバッチを書いているんですが、その中でnpm配布されているコマンドを使いたい場面がありました。餅は餅屋というわけで、Node.js方面でコマンド提供されているものを簡単にC#(.NET)から呼び出していいとこ取りをしようというのが今回の話です。

Azure Web AppsでのNode.jsサポート概要

そもそもAzureでNode.jsをまともに使えるのかという話から始まりますが、しっかり使えます。
Node.jsのバージョンはデフォルトで「アプリケーション設定」内にある設定(この場合は0.10.32)が使われますが、かなり多くのバージョンをサポートしています。
このあたりはAzure アプリケーションでの Node.js のバージョンの指定で詳しく書かれています。
今後もきちんと増えていく雰囲気です。
あっ、Azure Web Appsで実際にNode.jsが実行される環境はWindowsマシン上です。それがどうしても許せない人は諦めてください。

Node.jsベースのコマンドをインストールする

ここでは、JSONファイル同士のdiffをいい感じに出力してくれるjson-diffモジュールをインストールしてみます。
Azure Web Appsの提供するSCMへアクセスし、「Debug Console」を開きます*1
デバッグターミナルが表示されるので、npm install json-diffを実行します。
図1という具合で文字出力が一部化けて残念な感じになっていますがインストール処理は完了します。
図1 npmでのモジュールインストール
ここでnpmモジュールをインストールしたD:\home\node_modules以下のデータは、該当する処理を実行しているVMのローカルストレージではなくAzure Web Apps構成データとして保存されます。このため、割り当てられたVMが変わったりアプリのプランを変更した場合でも再度npm installをおこなう必要はありません。
[*1] https://(アプリ名).scm.azurewebsites.net/DebugConsole でアクセスできます。

C#コードからnode.jsベースのコマンドを呼び出す

試しに適当なJSONファイルとしてD:\home\node_modules\json-diff\package.jsonD:\home\node_modules\json-diff\node_modules\cli-color\package.jsonの差分を出力してみましょう。全く違うnpmパッケージのpackage.json同士なので、大量のdiffがあるはずです。
C#からの外部プロセス作成は通常通りSystem.Diagnostics.Processを利用します。
  var proc = new Process
  {
    StartInfo = new ProcessStartInfo
    {
      FileName = @"D:\home\node_modules\.bin\json-diff.cmd",
      Arguments = @"""D:\home\node_modules\json-diff\package.json"" ""D:\home\node_modules\json-diff\node_modules\cli-color\package.json""",
      RedirectStandardOutput = true,
      UseShellExecute = false,
      CreateNoWindow = true
    }
  };
完全なコードはこちら: https://gist.github.com/muojp/bb677aea6021e2a7cfaf
これを実行すると、
...
[10/20/2015 12:43:33 > 123c4b: INFO] -  _id: "[email protected]"
[10/20/2015 12:43:33 > 123c4b: INFO] +  _id: "[email protected]"
[10/20/2015 12:43:33 > 123c4b: INFO]    dist: {
[10/20/2015 12:43:33 > 123c4b: INFO] -    shasum: "6dbc3ae2d25e075a7fd71bcd9874458666fb681b"
[10/20/2015 12:43:33 > 123c4b: INFO] +    shasum: "adc3200fa471cc211b0da7f566b71e98b9d67347"
[10/20/2015 12:43:33 > 123c4b: INFO] -    tarball: "http://registry.npmjs.org/json-diff/-/json-diff-0.3.1.tgz"
[10/20/2015 12:43:33 > 123c4b: INFO] +    tarball: "http://registry.npmjs.org/cli-color/-/cli-color-0.1.7.tgz"
[10/20/2015 12:43:33 > 123c4b: INFO]    }
...
という感じでJSONファイル同士のdiffが出力されます。
正しいアプリベースディレクトリの取得方法がわからなかったのでD:\home\node_modulesを決め打ちしています。
このパスが変わることはひとまず無いはずですが、https://(アプリ名).scm.azurewebsites.net/api/vfs/ へアクセスして出力されるディレクトリ一覧からnode_modulesを探してくるのが正攻法な気もします。
正しい指定方法をご存知の方いらっしゃいましたら教えて下さい。

まとめ

Azure Web Apps上でnpmからNode.jsベースのコマンドを拾ってきてC#(.NET)から呼び出すのは結構簡単なので、手軽に使えそう。