Technology Topics by Brains

ブレインズテクノロジーの研究開発機関「未来工場」で働くエンジニアが、先端オープン技術、機械学習×データ分析(異常検知、予兆検知)に関する取組みをご紹介します。

AWS re:Invent2019 Hands-on(Creating Models with Amazon SageMaker), Workshop(Machine Learning with Kubeflow on AWS) and Session(new SageMaker Ecosystem)

こんにちは、ブレインズテクノロジーの寺村です。

2019年12月にLas Vegasで開催されたAWS re:Invent2019に参加してきました。 今回がre:Invent初参加になります。今回は参加したSession等を中心に技術的な部分をまとめます。

Day 1 Mon.2 Hands-on Lab and Workshop

私は1日目の昼にHands-on LabとWorkshopに参加しました。

Hands-On Lab

Hands-On Labは、100以上のカタログの中から自分で好きなラボを選び、手順に従ってシナリオに沿って自分のペースで学習する形式です。

f:id:brains-tech:20200117130359j:plain
Hands-On Labの様子 01
f:id:brains-tech:20200117123236j:plain
Hands-On Labの様子 02

今回私は Amazon Sagemaker を用いてチャーン分析を行うためのモデルを作成するラボを選択しました。 Creating Models with Amazon SageMaker SageMakerでNotebookインスタンスを立ち上げ, 使用するデータから特徴量の選択、データの前処理、モデル作成までを2時間程度の時間で行うことができました。 データの取り込みからモデル作成までがSagemakerでほぼ完結するので(データはS3に配置)とても楽に機械学習のモデルを作ることができると実感しました。 また、手順がNotebook形式でうまくまとめられていて、トレーニング資料などの作成にとても参考になりました。実際にWeb上でCatalogを使ってみることができるので気になる方は是非使ってみてください!

qwiklab

Workshop

Workshopは、事前に用意されている課題を自分のPC上で解決するタイプのハンズオン形式のセッションです。 最初にWorkshopで使用するAWSサービスの概要と課題を進めるためのドキュメントを共有してもらいます。その後にドキュメントに書かれた手順に従って各自のPCで課題を進めます。質問等がある場合は周囲のAWSエンジニアに質問して進めていきます。およそ2,3時間でSessionは終了します。

f:id:brains-tech:20200117123656j:plain
Workshopの様子 01 OPN401-R - [REPEAT] Machine learning with Kubeflow on AWS
f:id:brains-tech:20200117130509j:plain
Workshopの様子 02 OPN401-R - [REPEAT] Machine learning with Kubeflow on AWS

今回私はAmazon EKS上でKubeflowを動かすWorkshopに参加しました(Machine learning with Kubeflow on AWS)。 KubeflowはGoogleが開発するオープンソースの機械学習プラットフォームです。Kubernetesのクラスター上で機械学習のワークフローを動かします。 Kubeflow Dashboardを立ち上げて、Jupyter notebookを起動します。

f:id:brains-tech:20200117124038p:plain
Kubeflow Dashboard上でJupyter notebookの起動

Jupyter notebook上でインタラクティブにモデルの作成やトレーニング、推論までを行うことができます。

今回はSample codeを使ってモデルのトレーニング、推論を行います。他にも Kubeflow fairing: Pythonを用いて機械学習モデルを構築、訓練、デプロイ Kubeflow Pipelines: Dockerコンテナ技術を用いて一連のML workflowをパッケージ化する などのKubeflow関連のツールを使いながら課題を進めました。

Kubernetesに関してほとんど触ったことはなかったですが、シナリオに沿って進めることができました。 このWorkshopの内容もweb上で確認することができます。

MACHINE LEARNING USING KUBEFLOW

Day 2-4 Mon. 3-Mon. 5 Keynotes and Sessions

私は2日目以降は朝にKeynotesを聞き、午後には今回のre:Inventで発表されたSageMaker関連のSessionを中心に回りました。

f:id:brains-tech:20200117124927j:plain
Keynotes 01
f:id:brains-tech:20200117125328j:plain
Keynotes 02
f:id:brains-tech:20200117125448j:plain
Keynotes 03

f:id:brains-tech:20200117130551j:plain
Session Amazon SageMaker Studio 01

f:id:brains-tech:20200117130818j:plain
Session Amazon SageMaker Studio 02

機械学習モデルの構築やパラメータ設定がより簡単にできそうです!

f:id:brains-tech:20200117130653j:plain
Session Amazon SageMaker Debugger

f:id:brains-tech:20200117130725j:plain
Session Amazon SageMaker Debugger 02

まとめ

今年のre:InventではAWSが今後MLやAIの分野に力を入れていこうとしている意思を強く感じました。今後は、SageMaker上で機械学習プラットフォームの構築や運用がどのくらいできるのか試してみたいです。

re:Invent 2019, Day 2: Keynote by Andy Jassy

On the second day of the re:Invent, AWS CEO Andy Jassy announced severals new products, here is a summary and my thoughts on the products and how they are going to change the business:

f:id:brains-tech:20200114125606j:plain
Keynote

Instances

This year they focus heavily on advertising the Niro System, the underlying platform that powers EC2 and several other services. With this system they said they can deliver instances faster to the customers at lower costs.
They also introduce some new instance types, including Inf1, powered by their own Inferential chips to address Machine Learning use cases. To be honest, I was very amazed, the market for CPUs has been very lively these days, Intel and AMD trading blows on the x86 market, every phone manufacturer (Apple, Samsung, Huawei) has been trying to manufacture their own CPUs. And now, there is a very new market, CPUs that are made for specific use cases, like the Amazon Inferential, optimized for that use case only instead of general purposes computing. This should be a competition that is very entertaining to watch.

Containers

A very big announcement: Amazon EKS on AWS Fargate. With already a lot of customers deploying their Kubernetes instances on AWS, now AWS has decided to equip their Elastic Kubernetes Service with Fargate. Since Fargate is a way people can manage containers instances without worrying about provisioning or managing servers, I guess a lot of customers would be very happy to use the service.
But I wouldn’t want to see AWS going completely monopoly on the container scene, I really hope competitors can catch up soon.

Databases

Lots of enhancements have been made to AWS databases offerings: Amazon S3 Access Points, Data Lake Export Query, Amazon Redshift RA3 Instances with Managed Storage, Advanced Query Accelerator for Amazon Redshift, UltraWarm for ElasticSearch. But what catched my attention the most was Amazon Managed Apache Cassandra Service.
A lot of companies like ourselves have been using Cassandra for business since it offers a very fast insertion speed compared to the other databases. With no equivalent on AWS, we kind of have to use DynamoDB instead, which results in two different data modeling, a chore to maintain. We would be very happy to see this new service released and with a reasonable pricing too, so that we can reduce the time it takes to migrate our on premises software to the cloud.

Machine Learning

Machine learning is heavily focused on the event this year, and AWS didn’t fail to impress.
The first “wow” is the Amazon SageMaker Studio. It is a web-based IDE for a complete machine learning workflow. Build, train, and deploy machine learning models can now be done in a single interface. Along with that several other services like SageMaker Notebooks, Experiments, Debugger, Model Monitor, Autopilot.
And they managed to surprise me even further with Amazon CodeGuru, a service that review codes not only in the sense of linting, finding syntactic errors, but also finding logical errors, expensive operations, concurrency issues, etc. If the thing can be just half as good as they said it was, it definitely would become a game changer.

Others

One more interesting announcement is Kendra, an internal enterprise search engine. This sounds like the direct competitor to our business Neuron. This led me to thinking, AWS is not an infrastructure company anymore, just like their parent company Amazon, they participate in every market now. What I wonder is, their motives on this move. Is AWS going to offer very domain specific applications and destroy smaller competitors completely, or they are going to build an ecosystem, where smaller businesses will use their application as the core, and offers additional services to the customers to make a profit. One thing I know for sure, our business Neuron will have to improve, significantly so that we can keep on being one of the best offerings on the market.

My only complain is, they should let the rock band perform a little more, instead of just verses of songs. I felt very bad for the band.

-- Cuong Nguyen, Software developer @ Brains Technology, Inc.

re:Invent 2019, Day 1: Building ML practices & Advanced DynamoDB patterns

Building ML practices to address the top four use cases

I woke up very early in the morning (as early as 2pm) so I came very early to the venue too. The room of the session is shared with other sessions, so there’s no loud speaker, just some headphones set up for people who couldn’t hear the speaker directly. This session is kind of an introductory to the ML stack offerings from AWS, though it didn’t provide much detail about how to implement things, the speakers did give you a brief idea of steps you need to take to address your machine learning problems (4 of which mentioned in this session: Recommendation engines, Forecasting, Computer vision, and Natural language processing).

f:id:brains-tech:20200114115851p:plain
AWS ML Stack
What I learned from this session is: as an AWS user, you should first take advantage of their very convenient offerings like Personalize, Forecast, Rekonition, Textract, etc. to address your problem. These options are very convenient because you don’t really need the data initially to create your first models. It’s better to have a mediocre model than nothing, so if your system is just at an initial state, those are very helpful. And then when you have your own data, you can either input them to the “easy buttons” solutions, or you can customize the process further using SageMaker, there will be lower level options for you to choose from: several algorithms which you can tweak to your liking. And there is a marketplace for pre built models for different use cases that you can browse and buy them to use if it satisfies you. And if every pre built solutions cannot satisfy your needs, you can go deep down to the programming levels, which you can use frameworks like Tensorflow, Pytorch, and interfaces like Keras, or Amazon’s Gluon to program your ML pipeline yourself.
Full event can be found here.
(Update, at the Keynote one day later, AWS just announced some services that can make the process much more convenient including a cloud based IDE for SageMaker, with multiple SageMaker related goodies)

Advanced Design Patterns for DynamoDB

This is a repeated session from 2018, but there were still a lot of them being held repeatedly this year, and with a lot of people attending those sessions too. I can understand the reason behind that. Everybody is using NoSQL for their workloads, but not very many of them (myself included) truly understand what it is and how to utilize the technology.
Speaker Rick Houlihan started the presentation by addressing the reason why NoSQL is taking over RDBMS: data gets bigger, storage gets cheaper and CPUs are still expensive, it is more appropriate to store unnormalized that is ready for fast querying than to store normalized data that needs heavy computing for queries.
NoSQL is a very different beast than traditional relational databases. Using NoSQL the same way as relational databases is wrong, and if you use the same data model it’s wrong. In this session, Mr. Houlihan introduced briefly about the data model of DynamoDB, and then some advanced design patterns such as:

  • Choosing partition key to optimize partitioning performance
  • Range queries using sort key
  • Heterogeneous collections of items
  • Indexing and access patterns

f:id:brains-tech:20200114115403p:plain
Advanced design patterns for DynamoDB

Full event can be found here

-- Cuong Nguyen, Software Developer @ Brains Technology, Inc.

AWS re:Invent 2019 Session - Building machine-learning infrastructure on Amazon EKS with Kubeflow

Impulseの開発をしている樋口です。

今回は表題のセッションについて少しまとめます。

モチベーション

セッションはEKSで機械学習基盤を構築するという題目でしたが、AWSにはAmazon SageMakerというEnd to Endの機械学習サービスがあります。 aws.amazon.com

なぜSageMakerを使わずにEKSを利用して個別に機械学習のインフラを作り上げるのか(しかも今回のre:Inventで相当のアップデートが発表されました)、理由は以下が紹介されていました。

  • Portability
  • Composability
  • Scalability

以下そのうち2つを詳しく書いておきます。(ScalabilityはSageMakerでも,,,というところはあるので)

Portability

オンプレミス環境でもプロダクトを動作させる事が求められる場合、クラウドサービスにロックインした形で実装を進めてしまうと、クラウドサービスが担っていてくれた部分を一部自分で実現しなくてはならなく、 同じロジックを違う手段で実装し直すということが発生する。 クラウド・オンプレミス両方で同じ手段を使い動作する事で最小限の手間でプロダクトをポータブルにすることができる。

Composability

現在Kubernetes界隈にはたくさんのOSSがあり、それらを組み合わせることにより様々な機能を実現することができる。コンテナ基盤として使えるので、追加の個別の要件にも対応しやすい。

機械学習基盤

機械学習基盤として、満たすべき要件は

  • Authentication/Authorizationのサポート
  • Notebookを使ったデータ分析者による分析
  • パイプラインの実行
  • 並列分散処理によるモデル構築
  • スケーラブルな推論
  • メトリクスの可視化
  • インフラレイヤーの抽象化

など多々ありますが、これらを満たすために手段としてkubeflowが紹介されていました。 f:id:mhigu:20191204123205j:plain www.kubeflow.org kubeflowの各機能詳細については、公式ドキュメントを参照してもらうとして確かにこれだけでも機械学習基盤として必要な要件は最低限満たせるかもしれません。

kubeflowのパイプラインではTensorFlow, scikit-learn, PyTorchのいずれの処理でもパイプラインの一つの要素として定義することができます。 f:id:mhigu:20191205022107j:plain

一つのライブラリに依存せず基盤を準備できるのは便利( ゚∀゚)・∵. グハッ!!

まぁ、kubeflowの裏ではargoというもっと抽象的なworkflow engineが動いているので、何でも実行できるのは不思議では無いですね。 github.com

また、kubeflowと一緒にhorovodというライブラリが紹介されていました。 github.com 一応スピーカいわく現在一番洗練された分散学習のフレームワークの一つらしいです。

事例

実際にEKSをベースにして、この様な基盤を組んだ企業の事例紹介がありました。

基本的には上記で紹介したkubeflowをベースに以下の様な構成で、 f:id:mhigu:20191204125352j:plain

追加でPrometheus/Grafanaを導入して以下項目の可視化も行っていたとのことでした。

  • cpu
  • memory
  • cluster state
  • job metrics
  • cost f:id:mhigu:20191204130206j:plain コストが見えてるのいいですね。

また、この企業ではEKSベースの機械学習基盤をグローバルに展開しており、それをどこからでも利用できるようにするために複数の機械学習基盤をまとめるREST APIを作ってユーザーにはREST API経由で実際のジョブの実行をさせる様にしていました。

f:id:mhigu:20191204130439j:plain

こうすることで複数の基盤をまとめる事ができたのに加えて、ユーザーが指定しなければならない項目をシンプルにできたとも言っていました。 (kubernetesの利用障壁に煩雑なyamlを書く作業があるが、REST APIにすることでその部分を隠蔽できる。wall of YAML 突破か,,,(ヾノ・∀・`)ムリムリ)

所感

このセッションを通じて話されていた事は弊社のプロダクトにも共通の部分が多くあり、実際に同じようなものを動かしている人の話を聞くとやる気が上がりますね。 見聞きした事は、今後またImpulseの開発に生かしていきます。

AWS re:Invent 2019 に行く

AWS re:Invent 2019

Impulseの開発をしている樋口です。

12/2(月) - 12/6(金)の間で開催されているAWS re:Inventに参加しています。 セッションでの興味深かった内容はまた別途書くとして、まずは雰囲気をお伝えします。

Las Vegas

こんな感じのホテルがあちこちに。 f:id:mhigu:20191203093453j:plain

とにかく中がひろいでかい豪華。 f:id:mhigu:20191203093542j:plain

自分たちの泊まったホテルはFlamingo Las Vegasというホテルですが、 goo.gl その中庭にはフラミンゴが。 f:id:mhigu:20191203093505j:plain

あと、写真は撮れないので無いですが、そこら中にカジノがあり自分はベガス到着から2日で$300ブラックジャックで失いました。。。 安いApple Watchが買える値段。ご利用は計画的に_| ̄|○ il||li

AWS re:Invent

会場

セッション前日から会場は人で賑わっていて、各々壁に落書きしたりビリヤードしたりとくつろいでいます。 f:id:mhigu:20191203100527j:plain サインアップを済ませるとSWAGがもらえます。今回もパーカーとウォーターボトル。 f:id:mhigu:20191203094751j:plain f:id:mhigu:20191203095209j:plain 他にもノベルティが至るところでもらえるようなので、お土産としてたくさん確保していきます。

セッション

因みにセッションの確保競争は年々盛り上がっているようで、殆どのセッションが予約開始日から埋まります。 写真の青いのが興味のあるセッションですが、全て埋まっていて取れません。 f:id:mhigu:20191203094755p:plain 一応当日枠もあるので、泥臭く並んで空いてたら入ろうと思います。

まとめ

  • まずはアメリカの規模を実感する
  • カジノは適度に楽しみましょう
  • セッション確保は仁義なき戦い

以上です。

JAWS-UGでAmazon re:MARSの参加報告をして来ました

こんにちは,ブレインズテクノロジー / 未来ラボの奥山です.

先週の7/19に,AWSの東京ユーザーグループ(#jawsug_tokyo)で,Amazon re:MARSの参加報告をする機会をいただきました.

re:MARSは,去る6/4-7にLas Vegasで開催されたAmazon.com主催のイベントで,機械学習・ロボットから宇宙まで幅広いトピックに触れられる会議です. 弊社でも,わたしを含む4名が参加し,いろいろな学びを得て帰って来ました.

f:id:brains-tech:20190724150438j:plain

f:id:brains-tech:20190723130508j:plain
re:MARS会場のAria Resort

個人的には,Amazon CEOのJeff Bezos氏やCourseraでお世話になったAndrew Ng先生(それからアイアンマンことRobert Downy Jr.氏も)の講演を生で聞くことが出来て,感動ひとしおでした.

さて今回のユーザーグループでのrecapは,学んだことを整理するとても良い機会になりました. 特に心に残った講演者のキーメッセージを引用させていただきつつ,振り返りを記事にまとめました.

f:id:brains-tech:20190723110107j:plain
JAWSUGでの発表の様子(写真はtwitterから拝借しました).みなさん本当にプレゼン上手ですね…精進します.

続きを読む

GreengrassをDocker for Windows上で使用する準備とファイル読み出しテストの手順

こんにちは、ブレインズテクノロジーの岩城です。

2018年11月末に開催されたAWS re:Invent2018で、AWS Greengrass IoTをDockerコンテナ上で起動できるようになったことが発表されました。

aws.amazon.com

この機能を生かしたデータ活用手法について、先日公開した「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のスペックについては下記の画像をご覧ください。

f:id:brains_iwaki:20190124184333p:plain

読み込みの対象とするcsvファイルはこちらで準備したダミーのファイル (sample_data1.csv, sample_data2.csv)を使用しています。

実施概要

今回実施した内容は、Docker for Windows上でGreengrassを実行し、ローカル環境にあるcsvファイルを読み込ませてクラウドに送信させるというものです。

基本的な流れはAWSが提供している下記のリンクのチュートリアル通りですが、先々の応用を考え、一部変更を加えています。

docs.aws.amazon.com

大きな変更点は、下記の3点です。

  1. Hello Worldの代わりに、ローカル環境にあるcsvファイルを読みとるLambda関数を用意する。
  2. ローカル環境にcsvファイルを準備しておく。
  3. Dockerコンテナを起動する際に、マウントするホストの情報をコマンドに追加しておく。

今回は出荷状態のMELIPCを使用したので、Dockerのインストールやコマンドのインストールなども一から実施しています。
ユーザーを作成する部分などはさすがに割愛しますが、Greengrassを動かす前の事前準備から一通り行った作業を記載していきます。

Dockerコンテナ上でGreengrassを使用するための下準備

まずは、Dockerコンテナ上でGreengrassを使用できるように環境を整えていきます。

事前準備の概要

今回の一連のトライアル実施のため、まずはチュートリアルの指示通り、下記のソフトウェアをインストールしました(括弧内はバージョン)。

  • Docker (18.09)
  • Python (3.7) (※3.6以上ならOK)
  • pip (18.1)
  • AWS CLI (1.16)

その他、さらに前提として、AWSのアカウントを所有している必要があるので、持っていない場合は事前に作成しておきましょう。

Dockerのインストール

まずはDockerをインストールします。

チュートリアルの中のDockerへのリンクを開き、Docker Community Edition (CE)をダウンロードします。

docs.docker.com

今回はWindowsなので、スクロールしてDocker Desktop for Windows (Microsoft Windows 10)のリンクに飛びます。

(参考)
https://docs.docker.com/docker-for-windows/install/

f:id:brains_iwaki:20190124183815p:plain
Docker for WIndowsのインストールページ

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

最終的な設定はこちらの画像のようになります。

f:id:brains_iwaki:20190124183933p:plain
最終的なDockerのsettingsの内容

再起動などをした時などにDockerがどのような状態になっているかは、右下のステータスバーから確認できます。

f:id:brains_iwaki:20190124184041p:plain

ここの白い鯨のアイコンが上記の画像の状態で停止していれば起動している状態です。

なお、一つ前に記載した設定画面は、このアイコンを右クリックしてsettingsを選んだ画面から開きます。

完全に起動ができたら、最後に、コマンドプロンプトで

docker version

などのコマンドを実行すると正しくdockerがインストールできているかの確認ができます。

Docker Desktop for Windowsのインストールにおける注意点

インストールページに記載されているように、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)システム要件

こちらもインストールページに記載がある通りです。本記事の執筆時点では、下記のような条件があります。

  • Windows 10 64bit: Pro, Enterprise or Education
  • BIOSのVirtualizationがenableになっていること ( Hyper-Vとは別の話。基本的にenableらしい)
  • CPUがSLAT-capableであること
  • 最低4GBのRAM

今回使用したMELPICに搭載されているWindowsOSは、

  • Windows 10 Enterprise
  • 実装RAM: 4GB
  • システムの種類: 64ビット オペレーティングシステム、x64ベースプロセッサ

となっていたので、この辺りの条件はクリアできていたようです。

参考までに、今回使用したMELIPC M1002-W上のWindows上のスペックを再掲します。 f:id:brains_iwaki:20190124184333p:plain

Pythonのインストール

次に、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のインストール

pipは上記インストールに標準で入っていました。

updateが必要なので、下記のコマンドプロンプトで下記のコマンドを実行しました。

python -m pip install —-upgrade pip

ここは少々記憶が怪しいのですが、確か普通にpip install —upgrade pipを行うと上手くいかなかったように思います。 エラーメッセージでこのコマンドを提示してくれたかもしれないので、一度試してみて、駄目そうなら使ってみてください。

(参考)
https://qiita.com/icoxfog417/items/278ea9e217ac6fb7f10b

AWS CLIのインストール

AWS CLIのインストールは下記のコマンドです。

pip install awscli --upgrade —user

(参考)
https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html

また、AWS CLIがコマンドプロンプトから実行できるようにパスの追記などを行う必要があります。 この辺りは下記のリンクを参照してください。

https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/install-windows.html#awscli-install-windows-path

Greengrass in Docker Containerの実行とファイル読み込みテスト

ここまででようやく下準備が終わりました。 次に、GreengrassをDocker for Windows上で起動し、テストを行います。
改めて、チュートリアルへのリンクを掲載しておきます。

docs.aws.amazon.com

作業としては、

  1. Greengrassを動作させるコンテナのイメージの取得
  2. Greengrassコアとグループの準備 (+Lambda関数の準備)
  3. AWS IoT Greengrassをローカルで起動 (コンテナを立ち上げる)
  4. Greengrassコア側の設定
  5. デプロイ
  6. AWS IoTを使用してのテスト

という流れになります。

1. コンテナイメージのプル

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 を実行できますか?”という文言で検索してみてください。

2. Greengrassのグループとコアを作成 + Lambda関数の準備

まずは通常の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の設定などについては、下記の画像を参考にしてください。

f:id:brains_iwaki:20190124191402p:plain

これを通常のLambda関数のアップロードの手順に従い、AWS上にアップロードしておきます。
また、latestの状態ではGreengrassにデプロイできないので、バージョン発行と、必要であればエイリアス発行も実施しておきます。

Lambda関数の準備周りの手順はこちらをご参照ください。
Lambda 関数の作成とパッケージ化

3. AWS IoT Greengrassをローカルで実行

まずは先ほどダウンロードしてきた証明書情報などを所定のフォルダに準備しておきます。 最後の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が起動できると、コマンドプロンプトは下記のような状態になります。

f:id:brains_iwaki:20190124185247p:plain

この状態であれば、Greengrassが正しく起動しています。

4. Greengrassグループの設定

次はいよいよクラウド上でGreengrassの設定を行い、エッジ側に情報を配信 (デプロイ)します。

ここでは、コンソール上のAWS IoT Greengrassのページから、2番目の項目で作成したGreengrassのグループに、各種設定をつけていきます。

今回設定を行うのはLambda関数とサブスクリプションの設定の2つだけです。 ローカルリソースアクセスやコネクタ、ML推論などの機能は、コンテナなしの設定では使用できません。

更なる応用を見越した場合、ロールの割り当てやCloudWatchにログをあげる設定などを適宜行うことになりますが、 このトライアルではそれらの設定は不要です。

Lambda関数

まずは関数の設定を3箇所実施します。

下記の画像のように、

  • コンテナ化: コンテナなし
  • タイムアウト: 30秒
  • Lambdaのライフサイクル: 存続時間が長く無制限に稼働する関数にする

という設定にします。

f:id:brains_iwaki:20190124185702p:plain

次に、Lamba関数で使用する環境変数も設定しておきます。

f:id:brains_iwaki:20190124185347p:plain

ここで使用するトピックはサブスクリプションとテストで使用します。

また、データへのパスは、先ほどdocker runさせた時にマウントさせたパスにします。
今回は、/tmp/gg_data_root_data_dir/sample_dataの直下にcsvが入るようにマウントさせていることに注意してください。

サブスクリプション

HelloWorld関数のチュートリアルを元に、相互にやり取りできるように設定します。 今回は下記のような設定にしました。

f:id:brains_iwaki:20190124185802p:plain

解説

もともとのGreengrassではLambda関数の起動のたびにコンテナを立てていたのですが、この設定により、Lambda関数をOSプロセスとして実施できるようになり、 Docker上で動作できるようになった、という話のようです。

一方、「コンテナなし」の設定にすることで、ローカルリソースアクセスやコネクタ、Greengrass ML Inferenceなどの機能が使えなくなるといデメリットがあります。 ローカルリソースアクセスについては、この記事で紹介しているように直接アクセスの設定をすることで回避できますが、 他の機能を使っている場合は何か対策を行う必要が出てきます。

ちなみに、Greengrass ML InferenceはAmazon SageMakerやS3にあるモデルソースを使ってMLワークフローをシンプルに行うためのサービスで、 Lambda上で動かすなどの一般の機械学習とは特に関係ありません。そちらはコンテナなしでも普通に使うことができます。(ライブラリの準備等は必要です)

5. デプロイ実施

無事グループの設定が完了したら、Greengrassをデプロイします。 Greengrassが正しく起動した状態で、設定が適切になされていれば、グループの情報がエッジ側に配信されます。

f:id:brains_iwaki:20190124185927p:plain

配信後、左上の表示が正常に完了したことを示したら、テストを実施します。

6. テスト

最後にテストを行います。ここではGreengrass自体のチュートリアルのHelloWorld関数のテストと同様の設定を行います。 AWS IoTのコンソールのテストのページで下記のようにトピックのサブスクライブを行い、起動側のトピックを発行します。

f:id:brains_iwaki:20190124190050p:plain

すると、次の画像のように、デプロイしたLambda関数が動作し、csvファイルのファイル名と、1行目を読み込んだ結果をAWS IoT側に送信してきます。

f:id:brains_iwaki:20190124190104p:plain

今回はダミーのデータを入れたsample1.csv, sample2.csvという二つのファイルを準備していたので、 それらのファイル名と1行目の内容を送信してきてくれています。

これで、ファイルの読み込みが正しくできたことが確認できました。

今後の応用

以上、Dockerコンテナ上で起動したGreengrassを用いてのWindows上のファイル読み込みの簡単なトライアルを行いました。

ファイルの読み込みができたので、今後は本格的なデータ活用に進めていくことになるかと思います。

今回はAWSが提供したイメージをそのまま使用しましたが、既存ライブラリの活用とLambda関数の容量制限等を踏まえると、 ソフトウェアとして継続的に使用していくためにイメージの拡張が必要になってきそうです。

まとめ

以上で今回の記事は終了です。

長くなってしまいましたが、これでようやく本格的なGreengrassの活用に向けてのスタートラインに辿り着きました。 このステップは前提として、次にどのようにデータを活用していくか、あるいはアプリケーションをどのように構成していくかといった 本格的な取り組みに進んでいくことになると思います。

この技術を生かしてより一層データ活用が進んで行くことを期待しています。


ブレインズテクノロジーでは「共に成長できる仲間」を募集中です。
採用ページはこちら

参考資料