こんにちは，ブレインズテクノロジー / 未来ラボの奥山です．
先週の7/19に，AWSの東京ユーザーグループ（#jawsug_tokyo）で，Amazon re:MARSの参加報告をする機会をいただきました．
re:MARSは，去る6/4-7にLas Vegasで開催されたAmazon.com主催のイベントで，機械学習・ロボットから宇宙まで幅広いトピックに触れられる会議です． 弊社でも，わたしを含む4名が参加し，いろいろな学びを得て帰って来ました．
個人的には，Amazon CEOのJeff Bezos氏やCourseraでお世話になったAndrew Ng先生（それからアイアンマンことRobert Downy Jr.氏も）の講演を生で聞くことが出来て，感動ひとしおでした．
さて今回のユーザーグループでのrecapは，学んだことを整理するとても良い機会になりました． 特に心に残った講演者のキーメッセージを引用させていただきつつ，振り返りを記事にまとめました．
こんにちは、ブレインズテクノロジーの岩城です。
2018年11月末に開催されたAWS re:Invent2018で、AWS Greengrass IoTをDockerコンテナ上で起動できるようになったことが発表されました。
この機能を生かしたデータ活用手法について、先日公開した「Dockerコンテナ上で起動したGreengrassとWindowsとの連携で広がる新たなデータ活用の選択肢」という記事でご紹介しました。
本記事では少し技術的な内容に踏み込み、GreengrassをDocker for Windows上で使用するための準備の手順と、チュートリアルを拡張して実施したGreengrassからWindows上のファイル読み込みトライアルをご紹介します。
技術ではなく応用例に関心がある場合は、下記の記事をご参照ください。 blog.brains-tech.co.jp
使用する環境としては、前回の記事でも紹介した三菱電機製の産業用PC MELIPC1002-Wを使用します。MELIPCは生産設備などから集めたデータを集約・加工する機能と、集めてきたデータを活用するためのインターフェースを備えた産業用途のPCです。MELIPCについての詳細は前回の記事やこちらの製品ページなどご参照ください。 http://www.mitsubishielectric.co.jp/fa/products/edge/melipc/items/mi1000/index.html
今回の取り組みでは、MELIPC上のWindows10にDocker for Windowsをインストールし、このDocker環境でGreengrassを動作させます。
使用したWindowsのスペックについては下記の画像をご覧ください。
読み込みの対象とするcsvファイルはこちらで準備したダミーのファイル (sample_data1.csv, sample_data2.csv)を使用しています。
今回実施した内容は、Docker for Windows上でGreengrassを実行し、ローカル環境にあるcsvファイルを読み込ませてクラウドに送信させるというものです。
基本的な流れはAWSが提供している下記のリンクのチュートリアル通りですが、先々の応用を考え、一部変更を加えています。
大きな変更点は、下記の3点です。
今回は出荷状態のMELIPCを使用したので、Dockerのインストールやコマンドのインストールなども一から実施しています。
ユーザーを作成する部分などはさすがに割愛しますが、Greengrassを動かす前の事前準備から一通り行った作業を記載していきます。
まずは、Dockerコンテナ上でGreengrassを使用できるように環境を整えていきます。
今回の一連のトライアル実施のため、まずはチュートリアルの指示通り、下記のソフトウェアをインストールしました(括弧内はバージョン)。
その他、さらに前提として、AWSのアカウントを所有している必要があるので、持っていない場合は事前に作成しておきましょう。
まずはDockerをインストールします。
チュートリアルの中のDockerへのリンクを開き、Docker Community Edition (CE)をダウンロードします。
今回はWindowsなので、スクロールしてDocker Desktop for Windows (Microsoft Windows 10)のリンクに飛びます。
(参考)
https://docs.docker.com/docker-for-windows/install/
Install Docker Desktop for Windows desktop appの中からDocker Desktop Installer.exeをダウンロードし、実行した後は、ウィザードに従ってインストールを進めていきます。
途中でDocker ToolboxかDocker for Windowsを選択する箇所があります。今回の用途ではDocker for Windowsを選択します。
但し、Docker for Windowsを使用する場合はVirtualBoxが起動できなくなるので注意してください(後述)。
インストール後は一度再起動し、Docker for Windowsのdesktop appを開きます。
この際、有効化が必要等のメッセージが出た場合は、メッセージを読み、問題なさそうであればOKを押して進めていきます。
以上でDockerのインストールは完了…と思ったのですが改めて起動したところ、“Not enough memory to start Docker Desktop”というメッセージが出ました。
これはDocker DesktopのsettingsからMemoryの値を下げることで解決できました。
(参考)
https://qiita.com/chakimar/items/868298096ebf9186d690
最終的な設定はこちらの画像のようになります。
再起動などをした時などにDockerがどのような状態になっているかは、右下のステータスバーから確認できます。
ここの白い鯨のアイコンが上記の画像の状態で停止していれば起動している状態です。
なお、一つ前に記載した設定画面は、このアイコンを右クリックしてsettingsを選んだ画面から開きます。
完全に起動ができたら、最後に、コマンドプロンプトで
docker version
などのコマンドを実行すると正しくdockerがインストールできているかの確認ができます。
インストールページに記載されているように、Docker Desktop for Windowsインストールの際は下記の点に注意が必要です。
(1)Docker ToolboxとDocker Machineユーザー向けの注意点
Docker Desktop for Windowsでは、Microsoft Hyper-Vを使用します。
そのため、Hyper-Vが使用可能になっている必要があるのですが、Hyper-Vが使用可能な状態の場合は、VirtualBoxが使用できなくなります。
Hyper-VとVirtualBoxを並行して利用することができないので、注意しましょう。
なお、Hyper-Vの設定変更はインストーラーの方で行なってくれます。
(2)システム要件
こちらもインストールページに記載がある通りです。本記事の執筆時点では、下記のような条件があります。
今回使用したMELPICに搭載されているWindowsOSは、
となっていたので、この辺りの条件はクリアできていたようです。
参考までに、今回使用したMELIPC M1002-W上のWindows上のスペックを再掲します。
次に、Pythonの公式サイトからWindows用のPython3.6以上のインストールを行います。
https://www.python.org/downloads/windows/
種類がいくつもありますが、今回はx86-64 executable installerを選択しました。
簡単に補足すると、x86-64は64ビット版 (x86は32ビット版)、
executable installerはインストールに必要な要素を全てまとめてexeファイル内で保持しているようなインストールファイルです。
(参考)
https://stackoverflow.com/questions/38651672/difference-between-web-based-and-executable-installers-for-python-3-on-windows
https://python-forum.io/Thread-Python-3-x86-vs-x64-Inquiry
pipは上記インストールに標準で入っていました。
updateが必要なので、下記のコマンドプロンプトで下記のコマンドを実行しました。
python -m pip install —-upgrade pip
ここは少々記憶が怪しいのですが、確か普通にpip install —upgrade pipを行うと上手くいかなかったように思います。 エラーメッセージでこのコマンドを提示してくれたかもしれないので、一度試してみて、駄目そうなら使ってみてください。
(参考)
https://qiita.com/icoxfog417/items/278ea9e217ac6fb7f10b
AWS CLIのインストールは下記のコマンドです。
pip install awscli --upgrade —user
(参考)
https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html
また、AWS CLIがコマンドプロンプトから実行できるようにパスの追記などを行う必要があります。 この辺りは下記のリンクを参照してください。
ここまででようやく下準備が終わりました。
次に、GreengrassをDocker for Windows上で起動し、テストを行います。
改めて、チュートリアルへのリンクを掲載しておきます。
作業としては、
という流れになります。
AWSでAWS IoT Greengrassの依存関係などの設定が完了済みのイメージが提供されているので、今回はそれを利用します。
チュートリアル通り、下記のコマンドを順に実行していきます。
(1)ログインコマンドの取得 まずは下記のコマンドを実行します。このコマンドを使うことで、出力としてDockerクライアントの認証に必要なログインコマンドを取得することができます。
aws ecr get-login --registry-ids 216483018798 --no-include-email --region us-west-2
configurationの設定ができていない場合はここでCredential Errorが発生することがあるので、その際は下記のリンクなどを参考に解決してください。
https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-configure-envvars.html
(2) (1)で出力されたコマンドをそのままコピーして実行します。
(3)下記コマンドでコンテナイメージを取得します。
docker pull 216483018798.dkr.ecr.us-west-2.amazonaws.com/aws-greengrass-docker/amazonlinux:latest
あるいは、FAQの方でイメージを直接ダウンロードできるリンクが掲載されていたので、こちらをダウンロードして、docker loadコマンドでimageを取り込む形も取れるでしょうか。
https://aws.amazon.com/jp/greengrass/faqs/
興味のある方は上記リンク内で、 “Docker コンテナで AWS IoT Greengrass を実行できますか？”という文言で検索してみてください。
まずは通常のGreengrassのグループおよびコアを作成する作業を行います。
これについては、基本的なGreengrassのチュートリアル通りに進める流れになります。
AWS IoT の AWS IoT Greengrass の設定
この作業が初めての方は、一旦ここは後回しにして、通常のGreengrassのチュートリアルを行うところから始めるのが良いかと思います。
作業の途中でダウンロードする証明書情報と設定ファイルは後ほど使用するので保存しておきます。
また、チュートリアルにも記載がありますが、AWS IoT Greengrassコアソフトウェアは今回使用しているイメージに準備されているので、ダウンロードする必要はありません。
次に、Lambda関数の準備もここで実施しておきます。
今回使用したLambda関数のコードはこちらです。
import greengrasssdk import platform import os client = greengrasssdk.client('iot-data') my_platform = platform.platform() TARGET_TOPIC = os.getenv("TARGET_TOPIC", "hello/world") RETURN_MESSAGE = os.getenv("RETURN_MESSAGE", "Hello world! Sent from Greengrass Core.") TARGET_DIR_PATH = os.getenv("TARGET_DIR_PATH", "/tmp") def greengrass_hello_world_run(): if not my_platform: client.publish(topic=TARGET_TOPIC, payload=RETURN_MESSAGE) else: client.publish(topic=TARGET_TOPIC, payload= RETURN_MESSAGE + ' Running on platform: {}'.format(my_platform)) if os.path.isdir(TARGET_DIR_PATH): file_list = [os.path.join(TARGET_DIR_PATH, item) for item in os.listdir(TARGET_DIR_PATH) if (item.endswith(".csv")) and (item.startswith(".") == False)] file_list.sort() if len(file_list) > 0: for use_file in file_list: with open(use_file, "r") as f: first_row = f.readline() first_row = str(first_row) main_filename = use_file.split("/")[-1] client.publish(topic=TARGET_TOPIC, payload="File name is {}".format(main_filename)) client.publish(topic=TARGET_TOPIC, payload="First row of this file: {}".format(first_row)) else: client.publish(topic=TARGET_TOPIC, payload="There is no csv file") else: client.publish(topic=TARGET_TOPIC, payload="The TARGET_DIR_PATH dose not exist.") def function_handler(event, context): greengrass_hello_world_run() return
この関数では、環境変数としてファイルの読み込み先のパスやトピックの発行先、ベースになるメッセージの内容を指定できるようにしています。
関数の中でgreengrasssdkなどを使っているので、ライブラリも忘れずにアップロードしてください。 チュートリアルで提供されているHelloWorld.pyを改修すると早いかもしれません。
handlerの設定などについては、下記の画像を参考にしてください。
これを通常のLambda関数のアップロードの手順に従い、AWS上にアップロードしておきます。
また、latestの状態ではGreengrassにデプロイできないので、バージョン発行と、必要であればエイリアス発行も実施しておきます。
Lambda関数の準備周りの手順はこちらをご参照ください。
Lambda 関数の作成とパッケージ化
まずは先ほどダウンロードしてきた証明書情報などを所定のフォルダに準備しておきます。 最後のdocker runだけは少しコマンドを追加しますが、基本的にはチュートリアル通りに実施すれば問題ありません。
改めてリンクを再掲します。 Docker コンテナでの AWS IoT Greengrass の実行
なお、証明書と設定フォルダが入ったgzファイルを解凍する作業では、Windowsだけで行う場合はWinZipや7-Zipなど、解凍のためのツールが必要になります。 面倒な場合は別のところで解凍しておいたほうが楽かもしれません。
証明書と設定フォルダ、ルートCA証明書の準備ができたら、はじめにダウンロードしてきたイメージをdocker runで起動します。
ここでは、今回の目的であるcsvファイルの読み込みのため、ローカルのcsvファイルへのマウント情報を追加しています。 (-v c:/Users/%USERNAME%/Downloads/gg_data_root:/tmp/gg_data_root のところ)
お手本のコードにマウントに必要なコマンドが記載されているので、書き方はそこを参照すると良いかと思います。
docker run --rm --init -it --name aws-greengrass-docker --entrypoint /greengrass-entrypoint.sh -v c:/Users/%USERNAME%/Downloads/certs:/greengrass/certs -v c:/Users/%USERNAME%/Downloads/config:/greengrass/config -v c:/Users/%USERNAME%/Downloads/gg_data_root:/tmp/gg_data_root -p 8883:8883 216483018798.dkr.ecr.us-west-2.amazonaws.com/aws-greengrass-docker/amazonlinux:latest
無事Greengrassが起動できると、コマンドプロンプトは下記のような状態になります。
この状態であれば、Greengrassが正しく起動しています。
次はいよいよクラウド上でGreengrassの設定を行い、エッジ側に情報を配信 (デプロイ)します。
ここでは、コンソール上のAWS IoT Greengrassのページから、2番目の項目で作成したGreengrassのグループに、各種設定をつけていきます。
今回設定を行うのはLambda関数とサブスクリプションの設定の2つだけです。 ローカルリソースアクセスやコネクタ、ML推論などの機能は、コンテナなしの設定では使用できません。
更なる応用を見越した場合、ロールの割り当てやCloudWatchにログをあげる設定などを適宜行うことになりますが、 このトライアルではそれらの設定は不要です。
まずは関数の設定を3箇所実施します。
下記の画像のように、
という設定にします。
次に、Lamba関数で使用する環境変数も設定しておきます。
ここで使用するトピックはサブスクリプションとテストで使用します。
また、データへのパスは、先ほどdocker runさせた時にマウントさせたパスにします。
今回は、/tmp/gg_data_root_data_dir/sample_dataの直下にcsvが入るようにマウントさせていることに注意してください。
HelloWorld関数のチュートリアルを元に、相互にやり取りできるように設定します。 今回は下記のような設定にしました。
もともとのGreengrassではLambda関数の起動のたびにコンテナを立てていたのですが、この設定により、Lambda関数をOSプロセスとして実施できるようになり、 Docker上で動作できるようになった、という話のようです。
一方、「コンテナなし」の設定にすることで、ローカルリソースアクセスやコネクタ、Greengrass ML Inferenceなどの機能が使えなくなるといデメリットがあります。 ローカルリソースアクセスについては、この記事で紹介しているように直接アクセスの設定をすることで回避できますが、 他の機能を使っている場合は何か対策を行う必要が出てきます。
ちなみに、Greengrass ML InferenceはAmazon SageMakerやS3にあるモデルソースを使ってMLワークフローをシンプルに行うためのサービスで、 Lambda上で動かすなどの一般の機械学習とは特に関係ありません。そちらはコンテナなしでも普通に使うことができます。(ライブラリの準備等は必要です)
無事グループの設定が完了したら、Greengrassをデプロイします。 Greengrassが正しく起動した状態で、設定が適切になされていれば、グループの情報がエッジ側に配信されます。
配信後、左上の表示が正常に完了したことを示したら、テストを実施します。
最後にテストを行います。ここではGreengrass自体のチュートリアルのHelloWorld関数のテストと同様の設定を行います。 AWS IoTのコンソールのテストのページで下記のようにトピックのサブスクライブを行い、起動側のトピックを発行します。
すると、次の画像のように、デプロイしたLambda関数が動作し、csvファイルのファイル名と、1行目を読み込んだ結果をAWS IoT側に送信してきます。
今回はダミーのデータを入れたsample1.csv, sample2.csvという二つのファイルを準備していたので、 それらのファイル名と1行目の内容を送信してきてくれています。
これで、ファイルの読み込みが正しくできたことが確認できました。
以上、Dockerコンテナ上で起動したGreengrassを用いてのWindows上のファイル読み込みの簡単なトライアルを行いました。
ファイルの読み込みができたので、今後は本格的なデータ活用に進めていくことになるかと思います。
今回はAWSが提供したイメージをそのまま使用しましたが、既存ライブラリの活用とLambda関数の容量制限等を踏まえると、 ソフトウェアとして継続的に使用していくためにイメージの拡張が必要になってきそうです。
以上で今回の記事は終了です。
長くなってしまいましたが、これでようやく本格的なGreengrassの活用に向けてのスタートラインに辿り着きました。 このステップは前提として、次にどのようにデータを活用していくか、あるいはアプリケーションをどのように構成していくかといった 本格的な取り組みに進んでいくことになると思います。
この技術を生かしてより一層データ活用が進んで行くことを期待しています。
ブレインズテクノロジーでは「共に成長できる仲間」を募集中です。
採用ページはこちら
こんにちは、ブレインズテクノロジーの岩城です。
2018年11月末に開催されたAWS re:Invent2018で、AWS Greengrass IoTをDockerコンテナ上で起動できるようになったことが発表されました。これにより、GreengrassをWindows上で活用する際のハードルが下がり、データ活用を検討する際の選択肢がこれまで以上に広がっています。
今回の記事ではエッジコンピューティングに関する最近のトピックとして、GreengrassをWindowsと連携することで可能になった新しいデータ活用のイメージを紹介します。
より技術的なことに焦点を当てた記事も後日公開予定なので、実際にGreengrassをWIndows上で動かすことに興味がある方はこちらもご参照ください。
[2019年2月4日追記]
GreengrassをDocker for Windowsで使用するまでの準備と、今回テストとして実施した内容をまとめた記事を公開しました。
従来は、GreengrassのソフトウェアはLinux系のパッケージのみで提供されており、かつDockerコンテナ上で動かすことはできませんでした。
しかし、AWS re:Invent2018で発表があったように、現在はGreengrassをDockerコンテナ上で起動することができるようになっています。
Linuxだけでなく、WindowsやmacOS上からでもコンテナ経由でGreengrassをより容易に使えるようになった結果、 データを収集するところからの他のデバイスとの連携という点を含め、これまではなかった効率的なデータ活用の選択肢が生まれています。
実際にどのように可能性が広がったかより明確にするため、この技術の活用イメージとして生産現場からGreengrassまでのデータの流れの一例を紹介します。
補足として、AWS IoT Greengrassについても簡単に紹介しておきます。
AWS IoT Greengrass (以下Greengrass)はクラウドのAWSの機能の一部をローカルデバイスでも実行できるようにすることができるソフトウェアです。 例えば、弊社の場合はクラウドで提供している異常検知機能をローカルのコンピュータ (エッジコンピュータ)で実行するために使用しています。
ざっくりとした説明ですが、Greengrassを使用することで、クラウド環境で動作している一部のアプリケーションをローカル（エッジ側）のPCでも動作させることができ、 連携対象の設定などもまとめて行うことができると認識いただければ良いかと思います。
クラウドで使用している機能やデバイス間の設定をインターネット経由でエッジ側に配信するので、 ソフトウェアのアップデートやシステムの設定を少ない労力で実施できるほか、スケールさせやすいなどのメリットがあります。
AWS IoT Greengrassについては、こちらの資料も分かりやすかったのであわせてご参照ください。
そもそものエッジコンピューティングのメリットとしては、データを取得したその場で実施したい処理を行うことができるため、少ない遅延で結果を得られることや クラウドに送るデータをエッジ側で加工することで、データの送信量を削減できることなどがありました。
他にもいくつかメリットがあるので、エッジコンピューティングそのものに興味がある方は弊社CTO中澤も登壇したAWS re:Invent:2018: Machine Learning at the OkO Edge (IOT214)(英語)、弊社林の過去の登壇資料、AWS summit 2018の資料などをご参照ください。
re:Invent2018の映像はAWS Senior ManagerのDavid Nunnerleyによるご講演から始まり、18:12頃からアイシン・エィ・ダブリュ株式会社の佐藤雅則様のご講演、27:55頃から弊社中澤の講演という構成になっています。
www.slideshare.net
https://d1.awsstatic.com/events/jp/2018/summit/tokyo/aws/12.pdf
生産現場などのデータを活用するためには、まずはデータを集約し、使える形にする必要があります。
このような役割を果たす仕組みや設備は数多くあるかと思いますが、今回は三菱電機の産業用PC MELIPC1002-Wを使用した場合の例を紹介します。
MELIPC MI1002-Wは、下記の画像に示したような、およそ15cm x 20cmのほどの産業用PCです。
MELIPCはWindowsを搭載しており、主にデータを集約・加工する役割と、次のデータ活用のインターフェイスとしての役割を持ちます。
また、データの集約・加工という観点では、MELIPCは「Edgecross」という、データの収集・加工のためのソフトウェアを標準でインストールしています。
このソフトウェアを使用することで、各種機器からデータを集約し、 設定に応じて加工を施した後にcsvファイルやデータベース(PostgresSQL)に保存することなどを行うことができます。
技術的な検討を実施するにあたり、今回MELIPCの実機をお借りすることができたので、そちらで行った設定や検証については別記事でご紹介します。
MELIPCおよびEdgecrossの詳細については下記の製品ページや紹介ページをご参照ください。
http://www.mitsubishielectric.co.jp/fa/products/edge/melipc/items/mi1000/index.html
https://www.edgecross.org/ja/edgecross/
MELIPCによって収集・加工されたデータはWindows上などに保存されます。このデータをDocker for Windows経由でWindows上で動作しているGreengrassが読み出し、より高度なデータ活用を行います。 ここでのデータ活用としては、例えば弊社の場合のGreengrassを用いたエッジ環境上での異常検知が分かりやすいと思います。
ここまで紹介した例でのデータの流れを一旦整理すると下記のようになります。
あくまでも一例ですが、このような流れで得られたデータを使うことができます。
Greengrassで目的の用途で使用された後の結果やデータなどは、次の目的に応じ、クラウドにアップロードすることができます。 クラウドへのアップロードには通常のネットワークを使用する他、SORACOMさんが提供しているIoT向けの安価なワイヤレス通信を利用する選択肢があります。
データをアップロードする場合は、例えば新規に得られたデータを使って異常検知モデルを更新したり、他の分析に使用することができます。
もちろん、データのアップロードは行わず、異常検知結果や実施した記録だけをクラウドに記録すしたり、あるいは全く何もしないという選択肢もあります。この辺りはどのようにデータを使いたいか、という方針に従って決めていくことになります。
以上を踏まえ、MELIPCによるデータ収集、SORACOMのサービスを利用したクラウドとの連携、弊社の異常検知サービスImpulseをGreengrass上で使用した場合のデータ活用例の全体像をまとめたものが下記の図です。
データ収集技術や通信技術などの従来から実現していた仕組みに加え、今回可能になったGreengrassとWindowsの連携により、これまで以上にデータ活用の選択肢が広がっていることを感じていただけますと幸いです。
GreengrassがDocker上で起動できるようになったことをきっかけに広がった選択肢や活用イメージ例について、MELIPCやSORACOMなどの既存サービスとの連携も含めて紹介しました。
今回の技術的進歩がもたらした大きなメリットは、使いたいデバイスやソフトウェアがある場合や、既に導入している機器をベースに新しい取り組みを行いたい場合などに可能な選択肢が増えたことにあるのではないでしょうか。
用途やアプローチは数多くあるかと思いますが、この技術で広がった選択肢により、世の中のデータ活用が更に進むことを期待しています。
ブレインズテクノロジーでは「共に成長できる仲間」を募集中です。
採用ページはこちら
こんにちは、ブレインズテクノロジーの佐々木です。現在AWSのイベントであるre:invent 2018に参加しています。
こちらの時間で11月28日(水)の午前中にCEOのAndy Jassyによる基調講演が行われました。 基調講演は例年新しいサービス・機能が発表される場であるため、毎年非常に注目されています。
今年もたくさんの新サービスが発表されましたので、簡単に紹介したいと思います。
なお、この記事は速報のため、内容に誤りがある場合がございます。ご了承ください。
こんにちは、ブレインズテクノロジーの佐々木です。４月に新卒で入社しました。学生時代は熱帯林を這いつくばって植物と戯れていました。
CSVからデータを読み取って、ちょっとした分析をしたい！というシーンはよくありますよね。そうした手軽なデータ操作のツールとしては、PythonのpandasやRのdplyrなどが機能も充実していて使いやすいため、人気があるようです。また、大量のデータを製品環境で扱うような場面では、hadoopやsparkなどの分散処理基盤を活用することも多いようです。ただ、これらの選択肢が便利すぎるがゆえに、フロントエンドでデータ操作に迫られたときにストレスを感じる人も多いのではないでしょうか。
ということで、今回は、ブラウザ上でも便利にデータ操作ができるJavaScriptライブラリ、dataframe-jsに入門します。
といいつつ実際にブラウザで動かすのは面倒なので、今回はnode上で動かします。基本的にはブラウザでも同様に動く（と信じて）います。またもっと手軽に試したい方はJupyter notebookにIJavaScriptカーネルを入れると良いかもしれません（ここまでやると、pandas使えよ！ってツッコミが入りそうなのでやめました）。
npm install dataframe-jsでインストールできます。
前提として、以下のようなディレクトリ構成で作業しています。
. ├── iris.js ├── main.js ├── package.json
csvからデータを読み込む場合、データそのものではなくてPromiseが返ってきます。今回は以下のようなIrisクラスにメソッドを書き加えて、main.jsから呼び出す形で作業を進めて行きます。
const DataFrame = require('dataframe-js').DataFrame; module.exports = class Iris { constructor(params) { this.url = params.url; this.dfPromise = DataFrame.fromCSV(this.url); } showDF() { this.dfPromise.then(df => { df.show(); }); } }
const Iris = require('./dataframe'); const iris = new Iris({ url: 'https://raw.githubusercontent.com/uiuc-cse/data-fa14/gh-pages/data/iris.csv' }); iris.showDF();
node main.jsで実行します。
それでは本題に入ります。この記事のゴールは、iris（アヤメ）データセットを用いて種ごとに花弁(petal)と萼片(sepal)のサイズの関係を調べ（て、I. versicolor, I. virginica, I. setosa各種の形態的特性とその適応的意義について考察す）ることとします。
USDA Forest Serviceによると、この三種はいずれも湖畔沿などの湿地に生息しsetosa（アラスカ）, versicolor（五大湖付近）, virginica（ニューヨークからフロリダまで）の順に寒冷地に分布しています。一般に寒い方が大気飽差が小さく（相対湿度が大きく）蒸散で水を失いにくいことが知られています。また、組織が幅広だと乾燥重量あたりの蒸散量が増えるので、virginica, versicolor, setosa の順に花弁および萼片が細長であるという仮説をたてました。
この仮説を検証するために、各３種ごとに花弁と萼片の縦横の比の平均と標準偏差を計算し、比較します。
http://suruchifialoke.com/2016-10-13-machine-learning-tutorial-iris-classification/
まずはデータの基本的な整形をしてみます。行のフィルターにはfilter, 列の選択にはselectが使えます。使い方はpandasというよりも、Rのdplyrやsparkのデータフレームに似ています。
filterAndSelectDF() { this.dfPromise.then(df => { df .filter(row => row.get("species") === "versicolor") .select("sepal_length", "sepal_width", "species") .show(3); }); }
| sepal_length | sepal_width | species |
|---|---|---|
| 7 | 3.2 | versicolor |
| 6.4 | 3.2 | versicolor |
| 6.9 | 3.1 | versicolor |
次に、花弁縦横比（縦/幅）を計算してみます。
mutateWLratio() { this.dfPromise.then(df => { df .map(row => row.set('sepal_wlratio', row.get('sepal_length') / row.get('sepal_width'))) .map(row => row.set('petal_wlratio', row.get('petal_length') / row.get('petal_width'))) .select("sepal_wlratio", "petal_wlratio", "species") .show(3); }); }
| sepal_wlratio | petal_wlratio | species |
|---|---|---|
| 1.4571 | 6.9999 | setosa |
| 1.6333 | 6.9999 | setosa |
| 1.46875 | 6.5 | setosa |
最後に、種ごとにグループ演算をして各種の形質の平均・標準偏差を求めます。groupByで指定した列に対しGroupedDataFrameオブジェクトが返されます。GroupedDataFrameオブジェクトはaggregateメソッドをもち、グループ（種）ごとに関数を適用できます。
今回は花弁・萼片それぞれに平均と分散を種ごとに計算し、一つのデータフレームにまとめています。
calcSppStats() { this.dfPromise.then(df => { const groupedDF = df .chain( row => row.set('sepal_wlratio', row.get('sepal_length') / row.get('sepal_width')), row => row.set('petal_wlratio', row.get('petal_length') / row.get('petal_width')) ) .select('sepal_wlratio', 'petal_wlratio', 'species') .groupBy('species'); groupedDF .aggregate(group => group.stat.mean('sepal_wlratio')) .rename('aggregation', 'sepal_wlratio_sp_mean') .join( groupedDF .aggregate(group => group.stat.sd('sepal_wlratio')) .rename('aggregation', 'sepal_wlratio_sp_sd') , 'species', 'inner') .join( groupedDF .aggregate(group => group.stat.mean('petal_wlratio')) .rename('aggregation', 'petal_wlratio_sp_mean') , 'species', 'inner') .join( groupedDF .aggregate(group => group.stat.sd('petal_wlratio')) .rename('aggregation', 'petal_wlratio_sp_sd') , 'species', 'inner') .show(3); }); }
| species | sepal_wlratio_sp_mean | sepal_wlratio_sp_sd | petal_wlratio_sp_mean | petal_wlratio_sp_sd |
|---|---|---|---|---|
| setosa | 1.4745 | 0.1186 | 7.0779 | 3.1237 |
| versic | 2.1604 | 0.2286 | 3.2428 | 0.3124 |
| virginica | 2.2304 | 0.2469 | 2.7806 | 0.4073 |
また、group.stat.statsというメソッドを使うと各種統計量がまとめて計算できます。
以上の結果をテーブルにまとめました。
| species | 花弁縦横比（縦/幅）・平均 ± 標準偏差 | 萼片縦横比（縦/幅）・平均 ± 標準偏差 |
|---|---|---|
| setosa | 1.48 ± 0.12 | 7.10 ± 3.12 |
| versicolor | 2.16 ± 0.23 | 3.24 ± 0.31 |
| virginica | 2.23 ± 0.25 | 2.78 ± 0.41 |
花弁は仮説の通り、virginica, versicolor, setosa の順に細長でした。しかし、萼片については反対にsetosa, versicolor, virginicaの順に細長でした。考察として、花弁や萼片の形状（縦横比）だけでなく面積そのものや生理学的特性も考慮する必要があると考えられます。
流石にpandasには劣りますが、基本的なデータ操作はストレスなくできた気がします。クライアント側でデータ操作がスムーズにできることで、plotly.jsなどと組み合わせて（df.toCollection()とすると簡単にオブジェクトに変換できます）1. リッチな可視化が比較的簡単に実装できるようになる、2. pandasなどを使ってデータ処理をするためだけにサーバーサイドに処理を投げる必要がなくなりデータフローがすっきりさせられる、などのメリットがあるのではないでしょうか。
はてなブログでJavaScriptが実行できることを知ったので、一応試しておきました。表示ボタンを押すとhttps://raw.githubusercontent.com/uiuc-cse/data-fa14/gh-pages/data/iris.csv のデータがロードされ、一連のこれでブラウザでも同様に動く（と信じて）ことも確認できました。
結果はここに出ます。
<script src="https://cdn.rawgit.com/Gmousse/dataframe-js/master/dist/dataframe-min.js"></script> <script src="https://ajax.googleapis.com/ajax/libs/jquery/3.3.1/jquery.min.js"></script> <input id='show_button' type=button value='表示'> <script type="text/javascript"> $(function() { $('#show_button').click(function() { const DataFrame = dfjs.DataFrame; DataFrame.fromCSV('https://raw.githubusercontent.com/uiuc-cse/data-fa14/gh-pages/data/iris.csv') .then(df => { const groupedDF = df .chain( row => row.set('sepal_wlratio', row.get('sepal_length') / row.get('sepal_width')), row => row.set('petal_wlratio', row.get('petal_length') / row.get('petal_width')) ) .select('sepal_wlratio', 'petal_wlratio', 'species') .groupBy('species'); const resDF = groupedDF .aggregate(group => group.stat.mean('sepal_wlratio')) .rename('aggregation', 'sepal_wlratio_sp_mean') .join( groupedDF .aggregate(group => group.stat.sd('sepal_wlratio')) .rename('aggregation', 'sepal_wlratio_sp_sd') , 'species', 'inner') .join( groupedDF .aggregate(group => group.stat.mean('petal_wlratio')) .rename('aggregation', 'petal_wlratio_sp_mean') , 'species', 'inner') .join( groupedDF .aggregate(group => group.stat.sd('petal_wlratio')) .rename('aggregation', 'petal_wlratio_sp_sd') , 'species', 'inner'); const resJSON = JSON.stringify(resDF.toCollection(), null, 2); $('#result').text(resJSON); }) }); }); </script>
ブレインズテクノロジーでは「共に成長できる仲間」を募集中です。
採用ページはこちら
こんにちは、ブレインズテクノロジーの桑原です。
ブレインズテクノロジーは、ImpulseやNeuronといった、企業の生産性を劇的に向上させるサービス開発に従事していますが、私達自身の生産性も向上させるため、利用するシステムの探求と刷新を繰り返しています。
最近では、アマゾンウェブサービスが提供する機械学習サービスのAmazon Lexを利用して、営業記録やスケジュールの登録を簡素化できないかと模索をしていましたが、Amazon Lexとの会話は全て英語でした。
この度、Amazon Translateが日本語に対応したことを記念して、Amazon Lexとの英会話をリアルタイムに日本語に翻訳するBotを作ってみたいと思います。
Slackでスケジュールを登録したいと呟くと、Amazon Lexが何の予定なのかや日時を聞いてくれるBotです。本記事ではAmazon Lexと会話するところまでを解説しますが、これをGoogle Calendar等のカレンダーと連携させて実際に予定を入れることもできたりします。
なお、ZapierがなくてもSlackとAWS Lambdaをつなぐことは出来ますが、今回は極力プログラムを書かないことを目指すためZapierを採用しています。
深層学習モデルを使用して、従来の統計ベースやルールベースの翻訳アルゴリズムよりも正確で自然な翻訳を提供するニューラル機械翻訳サービスです。
2018年4月にサービスが提供され、当初は下記6言語が英語間翻訳に対応していましたが、
AWS Summit 2018 New Yorkにて、2018年7月から日本語を含めた下記6言語にも対応することが発表されました。
Amazon Translateの詳細はこちら
音声やテキストを使用して、任意のアプリケーションに対話型インターフェイスを構築するサービスです。
Amazon Alexaと同様、音声のテキスト変換には自動音声認識 (ASR)、テキストの意図認識には自然言語理解 (NLU) という高度な深層学習機能が使われているため、チャットBotのようなアプリケーションでリアルな会話を実現することができます。しかし、残念ながら現時点の対応言語は英語のみとなっており、日本語には対応していません (2018年8月時点) 。
Amazon Lexの詳細はこちら
それでは、Slack Botを作っていきます。AWS Lambdaのところで簡単なプログラムを書きますが、後はポチポチするだけで構築完了です。大きくハマることがなければ1〜2時間程度で終わるはずです。
構築ステップ
Amazon LexとSlackの融合
公式サイトのマニュアルに詳しい手順が記載されているので、これを参考にしながら設定をしていきます。本記事では、少しややこしい連携設定を補足します。
Amazon TranslateとSlackの融合
Amazon LexがSlackに返答した英語をZapierがひろってAWS Lambdaに投げる仕組みです。こちらもGUIを使ってお手軽に設定をしていきます。
AWSマネージドコンソールからAmazon Lexを選択します。いくつかサンプルが準備されていますので、今回はその中から[ScheduleAppointment]を選択します。後は、好きなようにサンプルをいじり、[Build]と[Publish]まで実行します。
なお、[Build]が完了すると画面右側の[Test Chatbot]でテストチャットを行うことができます。こちらが入力する言葉を変えても、それに応じた返答をし、アポイントを予約するところまで導いてくれることが確認できます。
既存のSlackチームを使いたい場合は、このステップをとばしてOKです。
Slack APIコンソールを開き、[Start Buildings]を押下してアプリを作成します。 [Bot Users]と[Interactive Components]の設定をした後、 [Basic Information]のClient ID、Client Secret、Verification Tokenをメモしておきます。
AWSマネージドコンソールからAmazon Lexを選択します。先ほど作成したAmazon Lexボットを選択し、[Channels]タブからSlackとの連携設定をします。Client ID、Client Secret、Verification Tokenにはステップ 3のSlack APIコンソールでメモしておいた値を入力します。
[Activate]が完了するとPostback URLとOAuth URLが表示されるので、こちらをメモしておきます。
Slack APIコンソールを開き、[OAuth & Permissions]で権限設定をしたあと、Redirect URLsにステップ 4のAWSマネージドコンソールでメモしておいたOAuth URLを入力します。
[Interactive Components]と[Event Subscriptions]のRequest URLに、ステップ 4のAWSマネージドコンソールでメモしておいたPostback URLを入力します。
これで、連携設定は完了です！
Slackにログインし、テストをしたいチャンネルにSlack APIで作ったBotユーザを招待します。 ここでは、realbot子さんが#test-channelにlexbot子さんを招待しています。
少し分かりづらいのですが、realbot子さんがこちらが入力したメッセージ。lexbot子さんがAmazon Lexが返してくれているメッセージです。
このように、lexbot子さんは英語しか話せないので、次のステップ以降でAmazon TranslateとSlackを融合させて、日本語を話してもらうようにします。
Slack App ディレクトリを開き、着信 Webフックを追加します。
# lexbot子さんの着信 Webフックを利用してもOKですが、今回は表示名を変えたかったため、別の着信 Webフックを追加しています。
名前やアイコンを指定したあと、Webhook URLをメモしておきます。
AWSマネージドコンソールからIAMを選択します。[ロール]->[ロールの作成]を押下し、AWSサービスのLambdaを選択します。
TranslateReadOnlyポリシーを選択します。
任意のロール名を入力しロールを作成します。
AWSマネージドコンソールからAWS Lambdaを選択します。[関数の作成]を選択して、関数を一から作成します。
Zapierを利用する場合、関数の名前は必ずzapier_evalとしてください。ステップ 8で作成したロールを選択して関数を作成します。
関数コードを入れて保存します。
import json import boto3 import unicodedata from urllib.parse import parse_qs import urllib.request def chk_lang(string): for char in string: name = unicodedata.name(char) if 'CJK UNIFIED' in name or 'HIRAGANA' in name or 'KATAKANA' in name: return True return False def lambda_handler(event, context): plain_text = event['plain'] lang = chk_lang(plain_text) if lang: return {'statusCode': 101} translate = boto3.client(service_name = 'translate', region_name = 'us-east-1', use_ssl = True) response = translate.translate_text(Text = plain_text, SourceLanguageCode = 'en', TargetLanguageCode = 'ja') translated_text = response['TranslatedText'] hook = 'https://hooks.slack.com/services/xxxxx/xxxxx' #ステップ 7で確認したWebhook URLを入力 headers = {'Content-Type' : 'application/json'} method = 'POST' json_data = {'text' : '`(ja) ' + translated_text + '`'} json_data = json.dumps(json_data).encode('utf-8') request = urllib.request.Request(hook, data = json_data, method = method, headers=headers) urllib.request.urlopen(request) return translated_text
Zapier Exploreを開き、[Make a Zap!]を選択します。
# Zapierは様々なサービスを無料で連携させることができますが、AWS Lambdaを連携させる場合は有償となります。
Triggerは、SlackにNew Message Posted to Channelがあった場合とします。
Channelを指定し、Trigger for Bot Messages?をnoからyesに変更します。
今回は、Invoke Functionを選択します。返り値を受け取ってあれこれしたい場合はRun Codeがいいでしょう。
Functionにはステップ 9で作成したzapier_evalを選択、Argumentsでeventオブジェクトに渡すデータとしてSlackのTextを指定します。
ZapのステータスをONにしたら、全ての設定が終了です。ふぅ
Slackにログインし、realbot子さんがlexbot子さんに話しかけます。すると、tranbot子さんが英語を日本語に翻訳してくれました！
トリガーとなる英語を適切に入力しないとAmazon Lexは反応してくれませんが、Hi (やあ) やHello (こんにちは) といった簡単な言葉をトリガーにしておけば、
から
とすることもできそうです。
それが実現できると、InputとOutputの言語はAmazon Translateが対応する12言語を自由に組み合わせることができるようになります。 Amazon Lexが英語にしか対応していなくても、多言語コミュニケーションが可能になる訳ですね。
無茶なキーワードを入れたら返ってきた返答です。普段は敬語のtranbot子さんですが、たまに不機嫌になるのでご注意を (笑)
ブレインズテクノロジーでは「共に成長できる仲間」を募集中です。
採用ページはこちら
Neuron開発チームの木村です。
Neuronは、ほとんどの場合Windowsにインストールされるため、テスト環境をWindows上に構築しています。 このテスト環境構築を効率化するため、docker上でのWindows利用を模索しています。
前回に引き続き、 Windows上のdockerでイメージをビルドする際・コンテナを動かす際に慣れないことを紹介します。
前回検討した導入方法から、dockerは「Hyper-Vコンテナ + LCOW」の形態で利用しています。 （そのため、Docker for Windowsを利用する場合とは異なる状況であることに注意ください。）
Windowsのバージョンは、
Windows 10 Pro バージョン 1803 (Version 10.0.17134.165)、
dockerのバージョンは、
Client: Version: master-dockerproject-2018-07-18 API version: 1.38 Go version: go1.10.3 Git commit: 48fbb12b Built: Wed Jul 18 23:51:23 2018 OS/Arch: windows/amd64 Experimental: false Server: Engine: Version: master-dockerproject-2018-07-18 API version: 1.38 (minimum version 1.24) Go version: go1.10.3 Git commit: 7f91801 Built: Thu Jul 19 00:00:43 2018 OS/Arch: windows/amd64 Experimental: true
LCOWのバージョンは、4.14.29-0aea33bcです。
以下、OSがWindowsであるコンテナを「WindowsOSコンテナ」、OSがLinuxであるコンテナを「LinuxOSコンテナ」と呼びます。
目次
COPYできないmulti-stage buildsでイメージビルドする際、名前に半角スペースを含むファイル（または、それを含むディレクトリ）を、WindowsのイメージにCOPYしようとすると、ビルドが以下のエラーで止まります。
COPY failed: file does not exist
よくある半角スペースの問題と考え、"で括るために
COPY --from=builder ["src/sample file", "."]のJSON形式で指定しても、今度は別のエラーで止まります。
COPY failed: Forbidden path outside the build context
昔からあるファイル・ディレクトリ名の半角スペース問題に、久しぶりに遭遇しました。（厳密には別の問題のようですが…）
RUN/CMDで使われるシェルを意識するRUN/CMDにシェル形式でコマンドを指定する際、コマンド実行に使われるシェルがcmd(コマンドプロンプト)なのかpowershellなのかを意識することが重要です。powershell特有のコマンドを使う際は自然と意識すると思いますが、このふたつは環境変数の取得方法がだいぶ異なるため、javaのような自分でパスを通すコマンドを使う時に注意が必要です。
cmd |
powershell |
|
|---|---|---|
環境変数VARの取得方法 |
%VAR% |
$env:VAR |
存在しない環境変数NONEから取得される値 |
%NONE%という文字列 |
空文字列 |
シェル形式で書かれたRUN/CMDのコマンド実行に使われるシェルは、デフォルトがcmd(cmd /S /C)ですが、SHELLで変更することができます。
使用するイメージのDockerfileを読むか、docker inspectでイメージのCmdプロパティからシェルを特定するとよいでしょう。たとえば、openjdk:8u171-jdk-nanoserverはpowershellをシェルに指定しています。
LinuxOSコンテナに対して、docker run時に--memoryオプションから割当メモリを指定しても無視され、
以下のように、約1GBのメモリが割り当てられます。
PS C:\> docker run --rm --memory 2g alpine:3.8 cat /proc/meminfo MemTotal: 985568 kB MemFree: 870932 kB MemAvailable: 805808 kB ...
WindowsOSコンテナに対しては、以下のように、指定通り約2GBのメモリが割当たります。
PS C:\> docker run --rm --memory 2g microsoft/windowsservercore:1803 systeminfo ... Total Physical Memory: 2,559 MB Available Physical Memory: 2,194 MB ...
mobyのissueを読む感じでは、 LCOWを使用しているために起きる問題のようです…
LinuxOSコンテナに対して、docker run時に--userオプションを指定しても無視され、
以下のように、rootユーザで実行されます。
PS C:\> docker run --rm --user guest alpine:3.8 whoami root
LCOW使用時の既知のバグのようです。
イメージビルド時のUSER指定も効かないため、LinuxOSコンテナは常にrootで動くことになります。
そして、この影響なのか、コンテナ内のディレクトリ・ファイルの所有者とグループが大体root:rootになってしまいます。
chmod/chownが効かない「イメージビルド時のVOLUME」や「docker run時の--volumeオプション」でvolumeに指定されたディレクトリ以下に対して、chmod/chownが効きません。
以下の例のように、chmodを行っても、終了コードが0であるにも関わらずパーミッションが変更されません（例ではjenkins/jenkins:2.134イメージを使用）。
root@fcdd7ae24179:/var/jenkins_home# ls -la total 0 -r-xr-xr-x 1 root root 102 Jul 30 05:02 copy_reference_file.log drwxrwxrwx 1 root root 4096 Jul 30 05:02 init.groovy.d root@fcdd7ae24179:/var/jenkins_home# chmod 755 copy_reference_file.log root@fcdd7ae24179:/var/jenkins_home# echo $? 0 root@fcdd7ae24179:/var/jenkins_home# ls -la total 0 -r-xr-xr-x 1 root root 102 Jul 30 05:02 copy_reference_file.log drwxrwxrwx 1 root root 4096 Jul 30 05:02 init.groovy.d
既知の問題ではあるようですが、回避策は特にない状況です。
このことが起因する問題には色々当たりましたが、大きかったのはjenkinsでリポジトリをダウンロードする際にエラーが起きることでした。
volume指定を使わないことでエラーを回避しましたが、docker cpでjenkins設定の永続化を行うことになってしまいました…
docker cpできない稼働中のコンテナに対してdocker cpを実行すると、以下のエラーが発生してコピーができません。
PS C:\Users\user\Documents> docker cp 7961ee45d606:/var . Error response from daemon: filesystem operations against a running Hyper-V container are not supported
なお、停止中のコンテナに対しては正常にコピーできます。
Windows上のdockerにて、イメージビルドやコンテナ実行の際に慣れないことを紹介しました。 LinuxOSコンテナについて、「volume周りの問題」と「メモリが最大1GB」がかなり厄介な問題です。
上記の他にも以下のようなことがありました。
openjdk:8u171-jdk-nanoserveropenjdk:8u171-jdk-windowsservercore はコンテナ実行可能:ではなく;、などやはり、experimentalなLCOWを使ってLinuxOSコンテナを扱うのは、まだ早いのでしょうか。 WindowsOSコンテナのみに絞ればよいかもしれませんが、そうするとLCOWを使う理由もないですし…
docker上でのWindows利用について、LCOWは引き続き試してゆきますが、 現状では、Docker for Windowsが可能な範囲で模索してゆくほうがよさそうです。
ブレインズテクノロジーではエンジニアを募集中です
採用ページはこちら
