【Azure Databricks 入門】第3.1弾 DBFS に Blob Storage をマウント

はじめに

Azure Databricks 第3.1弾として DBFS に Blob Storage をマウントする方法を解説します。

  • Azure Databricks に興味がある
  • 機械学習に興味がある
  • クラウド上でデータ分析をやってみたい

上記の項目に当てはまる方はぜひ読んでいただきたい内容となっています。

記事の概要

  • ストレージアカウントの作成から DBFS に Blob Storage をマウント方法を解説しています。
  • Blob Storage のアンマウント方法を解説しています。
  • ストレージアカウントキーなどの秘密情報を管理する Azure Key Vault を使用します。

前回記事

Azure Databricks: 1. リソースの作成
Azure Databricks: 2. Databricksの基本事項

既存の Blob Storage をマウントする場合の方法

※既存のBlob Storageをマウントする場合は以下の方法で作成してください。

  • 「DBFSにBlob Storageをマウント」から操作を実行
  • Azureポータルの「リソースの作成」をクリック
  • 一覧から「ストレージアカウント」を選択して作成を開始

ストレージアカウントの作成

画像1.png

作成に必要な情報を入力します。
設定内容は任意ですが、
「リソースグループ」と「場所」はAzure Databricksと同じものを指定します。
設定が出来たら「次: 詳細 >」をクリックします。

画像2.png

「詳細」設定に関しては、今回はデフォルトのままでいきます。
「確認および作成」をクリックします。

画像3.png

設定内容に誤りがないことを確認、
「作成」をクリックします。

画像4.png

しばらく待機し、作成が完了したら作成したリソースに移動します。
画像5.png

マウント時のパラメータとして
ストレージアカウントの「アクセスキー」が必要です。

メニューの「アクセスキー」を開きます。
「key1」または「key2」いずれかの「キー」をコピーして控えておきます。

画像6.png

Blobコンテナーの作成とファイルの配置

ストレージアカウントのメニューの「概要」に戻り、
「サービス」の「BLOB」をクリックします。

画像7.png
「+コンテナー」をクリック
「名前」を任意のコンテナ名、
「パブリックアクセスレベル」を「プライベート」
としてコンテナを作成します。

画像8.png
ファイルを配置するため作成したコンテナーをクリックします。
コンテナーを開きます。

画像9.png

「↑アップロード」をクリックします。
ファイルを選択して「アップロード」をクリックします。

画像10.png

アップロードが完了するとコンテナーにファイルのリストが表示されます。
画像11.png

DBFSにBlob Storageをマウント

Blobコンテナーのマウント

Blob Storageのマウントは下記のスクリプトを使用します。

※以下の項目は作成したリソースに合わせて変更してください。
- ストレージ情報
- マウント先の DBFS ディレクトリ

一度マウントすると、Clusterを停止・変更してもマウント状態が維持されます。
マウントされた状態で再度操作を実行するとエラーが発生します。
マウント状態をチェックするか、スクリプトをコメントアウトしてエラーの回避します。

[crayon-633f85889cf0f788788764/]

画像12.png

下記スクリプトでマウントされているディレクトリを確認します。
Blob Storage をマウントしたディレクトリがリストで確認できます。

[crayon-633f85889cf18513076701/]

画像13.png

マウントされたディレクトリの確認

下記スクリプトを使用してマウントしたディレクトリ内のファイルを表示します。

※ マウントしたディレクトリにファイルが存在しないとエラーが発生します。

[crayon-633f85889cf1b908504240/]

画像14.png

Blob コンテナーのアンマウント

ストレージのマウントを解除する場合は下記スクリプトを使用します。

[crayon-633f85889cf1d399628438/]

画像15.png

秘密情報の安全な管理

秘密情報をスクリプト上に記載することはセキュリティ上の懸念となります。

ストレージアカウントキーのような秘密情報を安全に管理するため、
Azure Key Vault の使用が推奨されます。

Azure Key Vault のキーコンテナー作成

Azure ポータルの「リソースの作成」で「Key Vault」を検索します。
検索候補の「Key Vault」をクリックして作成を開始します。

画像16.png

「キーコンテナーの作成」に必要な情報を入力します。

  • 「名前」: 任意の名称
  • 「リソースグループ」: Azure Databricksと同じものを指定
  • 「場所」: Azure Databricksと同じものを指定。

その他の設定はデフォルトのままとします。

画像17.png

作成が完了したらリソースに移動します。
画像18.png

キーの登録

作成したキーコンテナーにストレージアカウントキーを登録します。
作成したリソースのメニューから「シークレット」を開きます。
「+生成/インポート」をクリックします。

画像19.png

  • 「アップロードオプション」:「手動」と選択
  • 「名前」:任意の名称を入力
  • 「値」:ストレージアカウントキーを入力

「作成」をクリックします。

画像20.png

Databricks に Azure Key Vault を登録

キーコンテナーのメニューから「プロパティ」を開きます。
「 DNS 名」と「リソース ID 」をコピーして控えておきます。

Databricks ワークスペースのホーム画面を開きます。
URL に「#secrets/createScope」を追加します。
「Create Secret Scope」のページを開きます。

  • 「Scope Name」に任意のスコープ名を入力
  • 「DNS Name」: 作成したキーコンテナーの「プロパティ」の「DNS名」を入力
  • 「Resource ID」: 作成したキーコンテナーの「プロパティ」の「リソースID」を入力

※ Databricks作成時にStandard Planを選択した場合、
「Manage Principal」は「All Users」のみ選択できます。

入力したスコープ名はキーの取得に必要となるため控えておきます。

画像21.png

Notebookを開き、下記のスクリプトでスコープのリストを確認します。
スコープが登録されていると、
登録したスコープがリストにあることが確認できます。

[crayon-633f85889cf22097128512/]

画像22.png
BlobコンテナーのマウントにKey Vaultのキーを使用する場合は、
Blob Storageの情報を下記のように書き換えます。

[crayon-633f85889cf53551307771/]

最後に

ストレージアカウントの作成から DBFS に Blob Storage をマウントする方法を解説していきました。
Azure Key Vault を使用した秘密鍵情報の管理を行うことで、データ分析業務に注力できる環境整備が行えそうですね。
Azure Databricks でデータ分析を行う際の参考になれば幸いです。

次回もお楽しみに!

参考

Databricks Documentation – Data Sources – Azure Blob Storage
クイックスタート:Azureポータルを使用してAzure Key Vaultから秘密を設定および取得する

Azure Databricksの導入ならナレコムにおまかせください。

弊社は、Databricksのソリューションパートナーとしてお客さまのデジタルトランスフォーメーションの推進に貢献致します。

導入から活用方法までサポートします。お気軽にご相談ください。

Azure Databricksソリューションページはこちら
Databricks ソリューションパートナーに関してはこちら


Azure Databricks: 2. Databricksの基本事項

前回記事

Azure Databricks: 1. リソースの作成

Databricks File System (DBFS)

Azure DatabricksのClusterには、Databricks File System (DBFS)という分散ファイルシステムがインストールされています。DBFSのファイルはAzure Blob Storageに永続化されるため、Clusterが終了してもデータが保持されるようになっています。
NotebookからDBFSにアクセスする場合には、Databricks Utilities(dbutils)、Spark API、open関数等のFileIOを使用しますが、OSとDBFSでルートディレクトリの扱いが異なるため、ファイルにアクセスする上で注意が必要になります。

Databricks Utilities(dbutils)

dbutilsでは、DBFSのルートディレクトリを基準にパスを参照します。
dbutilsで「/mnt/my_blob_container」を指定した場合は「dbfs:/mnt/my_blob_container」を参照することになります。
dbutilsでClusterのローカルストレージを参照する場合は「file:/home/ubuntu」のように、OSのローカルパスに「file:」を追加したものを使用します。

Spark API

Spark APIでファイルを読み込む場合、DBFSのルートディレクトリを基準にパスを参照します。
ただし、dbutilsとは異なり「file:/home/ubuntu」のような形でClusterのローカルストレージを参照することはできません。
そのため、Sparkでファイルの読み込みを行う場合はファイルをDBFS上に配置する必要があります。

FileIO (上記2つ以外のファイル操作)

Pythonのopen関数等のFileIOで読み込みを行う場合、OSのルートディレクトリを基準にパスを参照します。
DBFSルートディレクトリはOS「/dbfs」にマウントされているため、DBFSの「/mnt/my_blob_container」にアクセスする場合は、「/dbfs/mnt/my_blob_container」のように「/dbfs」を追加したパスを使用します。

マジックコマンド

Databricksでは、セルにマジックコマンドを指定することで、各種スクリプトの実行ができます。
マジックコマンドは1セルにつき1つだけ指定できます。

Markdown形式でのコメント挿入: %md

セルにMarkdownを記載してコメントとして挿入します。
[crayon-633f85889d3ff264840385/]

Databricks File System(DBFS)のファイル操作: %fs

Databricksの分散ファイルシステムであるDBFSのリスト、コピーといったファイル操作をシェルコマンドライクに記述して実行します。
ディレクトリにあるファイルのリストを表示する場合は、下記コマンドを使用します。
[crayon-633f85889d405139538095/]

上記コマンドはPythonの下記スクリプト実行結果と同等となります。
[crayon-633f85889d407660162852/]

OS (Linux)のシェルコマンド実行: %sh

OSのシェルコマンドを実行する場合には「%sh」を使用します。
DBFSを%shで参照する場合は下記のとおりです。
[crayon-633f85889d409695758829/]

各言語のスクリプト実行: %python, %scala, %sql, %r

Notebookで指定した言語以外の言語を使用する場合は、対応言語のマジックコマンドを使用します。
[crayon-633f85889d40b535199256/]
[crayon-633f85889d40d538851147/]

言語間で変数は共有されないため、マジックコマンドの変数に値を引き渡す場合は一旦DBFSにファイル出力をする等で渡す必要があります。

他のNotebookの実行と読み込み: %run

他のNotebookを実行する場合は「%run」で対象Notebookを指定して実行します。
%runで実行すると、同じ言語であれば他のNotebookで定義された変数をそのままの変数名で参照することができます。
メンテナンス性を高めるために、スキーマ定義を別Notebookで記述しておくといったような使い方ができます。
[crayon-633f85889d40f099548381/]

参考

Using Notebooks

 

 

Azure Databricksの導入ならナレコムにおまかせください。

導入から活用方法までサポートします。お気軽にご相談ください。

Azure Databricksソリューションページはこちら

 

 


Azure Databricks: 1. リソースの作成

はじめに

Azure Databricksのリソース作成から、DatabricksワークスペースでのCluster、Notebookの作成までを行います。

ワークスペースの作成

Azureポータルの「リソースの作成」をクリックし、検索に「Databricks」を入力します。
候補に「Azure Databricks」が出てくるので、クリックして作成を開始します。

必要事項を入力して作成を実行します。

作成が完了するまでしばらく待機します。

ポータル右上の「通知」で作成が完了したら、「リソースに移動」で作成したリソースのページを開きます。

リソースのページの「Launch Workspace」をクリックして、Databricksワークスペースにログインします。

Clusterの作成

Databricksワークスペースのサイドバーにある「Clusters」をクリックします。

「+Create Cluster」をクリックしてClusterの作成を開始します。

必要事項を入力、設定していきます。
今回は、以下の設定値で作成します。


Clusterの「State」が「Running」になるまでしばらく待機します。

Notebookの作成

サイドバーの「Workspace」をクリックし、「Users」=>「{アカウント名}」とディレクトリを移動して、ユーザーディレクトリを表示します。

右上のドロップダウンリストから「Create」=>「Notebook」を選択します。

「Name」に任意のNotebook名を入力し、「Language」に「Python」、「Cluster」に先ほど作成したClusterを設定して「Create」をクリックします。

以上でNotebookの作成は完了です。

 

 

Azure Databricksの導入ならナレコムにおまかせください。

導入から活用方法までサポートします。お気軽にご相談ください。

Azure Databricksソリューションページはこちら

 

 


Azure LogAnalyticsでWindowsServerを監視してみた

こんにちは、ナレコムのDreamです。
本記事はAzure LogAnalytics を使用したAzure VM(WindowsServer)のリソース監視についてまとめていきます。

監視設定方法

ポータルから[ログの分析]を選択し設定していきます。
詳しくは、Azure LogAnalytics 概要についてまとめてみたを参照願います。
まずは、[仮想マシン]より対象となるVMが接続されていることを確認します。

[ログ]から取得するデータのクエリをなげていきます。

ComputerNameとCounterNameを調べる

CPUの使用率

[crayon-633f85889d646248501242/]

Memoryの使用率

[crayon-633f85889d64c175457362/]

Diskの空き容量

※デフォルトではトータルのディスク空き容量しか取得できません。
 CやDドライブのみデータを取得したい場合には[詳細設定]よりパフォーマンスカウントを追加します。


#sample query

[crayon-633f85889d64e552455298/]

Heartbeatの監視(死活監視)

[crayon-633f85889d650652665211/]

取得したデータ(CPU / メモリ / ディスク)のメトリック表示

[crayon-633f85889d652001683951/]

※データの保持期間がデフォルトで30日の為、30日以前のデータを取得したい場合、保持期間を変更する必要があります。

アラートの設定方法

上記のqueryを実行した後、[新しいアラートルール]を選択します。

[条件]からアラートの閾値を設定
[アクション]から通知先を設定
[アラートの詳細]で通知アラートの件名/説明を記入

まとめ

上記以外にも様々なデータを取得することが可能です。
本記事で紹介したリソースの監視以外にもLogAnalyticsではログの監視なども可能です。
リソース監視以外の部分については別記事でご紹介できればと考えています。


5分で学ぶAzure LogAnalytics【中級者向け】

はじめに

ウェブサイトやAPIなど、ユーザーに提供するサービスをしっかりと監視していく必要があります。
そういった時に、便利に使えて必須とも言えるサービス、Azure LogAnalytics についてご紹介していきます。
さくっと概要を知りたい中級者向けの内容になっています。

  • ログを収集し分析するのは、エラーが出た時に原因を早急に突き止めるのに使えます
  • しきい値でアラートを発砲してくれるので問題にすぐ気付ける
  • ダッシュボードでひと目で可視化したデータを確認できるので、管理コストがかかりません
  • 次の開発に集中して作業ができる

    Azure LogAnalyticsとは

    image.png

  • Azureサービス/Azure VM、オンプレミス/他クラウドサービスのWindowsやLinuxのログを収集し分析するためのサービス
  • 対象サーバにエージェントをインストールするだけで、簡単に使用することができる
  • 収集したデータに閾値を設定し、アラートを発報できる。
  • 収集したデータをダッシュボードに集約し、可視化が可能。

Azure Monitor ログが利用可能です。
Azure のお客様が監視を簡単に行えるようにするために統合されたサービスです。

※本記事では、Azure LogAnalyticsで統一します。

参考URL

LogAnalytics が収集できるデータ

収集データ 概要
Windowsイベントログ Windowsイベントログのイベントのみを収集(Azure Monitor での Windows イベントログのデータソース
Windowsパフォーマンスカウンター Windowsのハードウェアコンポーネント、オペレーティングシステム、およびアプリケーションのパフォーマンスに関する情報の収集 (Azure Monitor での Windows および Linux のパフォーマンス データ ソース)
Linuxパフォーマンスカウンター Linuxのハードウェアコンポーネント、オペレーティングシステム、およびアプリケーションのパフォーマンスに関する情報の収集(Azure Monitor での Windows および Linux のパフォーマンス データ ソース)
IISログ W3C形式で格納されたIISログファイルのみを収集(Azure Monitor での IIS ログを収集する)
カスタムログ WindowsとLinuxの両方のテキストファイルからイベントを収集(Azure Monitor のカスタム ログ)
Syslog Linuxのrsyslogまたはsyslog-ngによって送信されたメッセージの収集(Azure Monitor の Syslog データ ソース)

価格

LogAnalyticsでは、サービスに取り込まれたデータがギガバイト(GB)単位で課金されます。
※デフォルトの設定ではデータ保持期間が30日に設定されています。

機能 含まれている無料ユニット 料金
データインジェスト 顧客あたり5GB/月 ¥374.08/GB
データ保持 31日 1GBあたり ¥16.80/月

Azure Monitorの価格

使用方法

AzurePortalへログインし、[LogAnalyticsワークスペース]を選択
image.png
LogAnalyticsワークスペースを新規作成
ワークスペース名/サブスクリプション/リソースグループ/場所/価格レベルを選択
※LogAnalyticsワークスペースを作成するリソースグループは運用条件によって、LogAnalytics専用のグループを作成するか監視対象リソースと同じグループを使用するかを決める
image.png
ワークスペースのデータソースより[仮想マシン]を選択
対象の仮想マシンを選択し接続(接続に時間を要する場合があります)
※本記事ではAzure VM(WindowsServer)を対象にしてます。
image.png
image.png
LogAnalyticsワークスペースの[詳細設定]から収集するデータを選択
Dataから収集したいデータを選択し保存
※Azure VM(Windows)のパフォーマンスカウンターを取得したい場合は、別途Azure VMの[診断設定]-[ゲストレベルの監視を有効にする]をONにする必要があります。
image.png
LogAnalyticsワークスペースの[ログ]から収集したデータの検索やアラートの設定が可能
ここではKustoクエリを使用します。(kustoクエリ 概要)
image.png

Kustoクエリ

英語のみとなりますが、ウェビナーもあります。
(Kusto Query Language (KQL) from Scratch)
以下にAzure LogAnalyticsでよく使用するクエリをまとめます。
クエリの基本構文は テーブル名|コマンド1|コマンド2... となります。

テーブル名 説明
Syslog LinuxのSyslogの取得
Event Windowsイベントログの取得
Perf パフォーマンスカウンターからリソース使用率を取得可能(Perfのみで実行すると接続しているコンピュータ名が確認可能)
Heartbeat 死活監視等に使用

※Azure Monitor ログ クエリの例

グラフ

LogAnalyticsワークスペースから[ビューデザイナー]を選択。
一部プレビューの機能もあります。

image.png

表示したいグラフを選択し、表示メトリックのクエリ等を設定する

image.png

ユースケース

  • サーバーなどを監視する仕組みを利用したい
  • 監視もazure環境内で完結したい
  • ランニングコストの予算内にとどめたい

HoloLensで物体のオフライン検出(環境構築から実行まで)

HoloLensでオフライン検出

HoloLensで物体のオフライン検出を行います。
作成にあたっては@miyauraさんの記事を参考にさせていただきました。(URLは一番下に記載)

環境構築

Windows 10 1809 (17763) 以上
HoloLens OS 1809
Visual Studio 2017
Unity 2017.4.17f1

Custom Visionでのモデル作成(ONNX)

Azureポータルへアクセス
https://portal.azure.com
Cognitive Services リソースの作成

名前、サブスクリプション、場所、価格レベル、リソースグループをお好みで指定します。

作成後、すべてのリソースで「名前」、「名前_Prediction」リソースが作成されている事を確認します。
Azure Custom Visionにアクセス
https://www.customvision.ai
「NEW PROJECT」から新しいプロジェクトを作成します。

「Project Types」はObject Detection
「Domains」はGeneral(Compact)
「Export Capabilities」はBasic platformsに設定します。

プロジェクト作成後は画像をアップロードし、学習を進めていきます。
1タグにつき、少なくとも15枚以上の画像が必要になります。

「Export」をクリックし、ONNX1.2を指定した上でzipファイルをダウンロードします。

ダウンロード後、zipファイルを解凍し、ファイル内の「model.onnx」を「LearningModel.onnx」に書き換えます。
この.onnxファイルが学習させたデータになっており、プロジェクトにインポートする事で利用可能になります。

プロジェクトのダウンロード

こちらのURLからプロジェクトをダウンロードします。
https://github.com/namiwavess/ObjDetectionSamplesUsingONNX
ダウンロード後、Unity 2017.4.17f1を起動しプロジェクトを開きます。

Unityでの作業

プロジェクト設定をHoloLens向けに設定します。
PlatformをUWPに変更します。
Unity C# Projectsにチェックを入れます。

Scripting Backendは.NETにします。

ビルドを行い成功すれば、Unityでの作業は完了です。

Visual Studioでの作業

学習させたデータに合わせてタグの変更を行います。今回の記事では
{"curry","gyoza","meat","pizza","sushi"}になっていますが、学習させた内容に合わせて適宜変更してください。

[crayon-633f85889d853754555377/]

ターゲットはRelease/X86に変更します。

学習させた.onnxモデルをAssetフォルダ内にインポートします。
「ビルドアクション」はコンテンツ、「出力ディレクトリにコピー」は常にコピーするを選択します。

プロジェクトからNuget管理を開き、System.ValueTuple ライブラリをインポートします。

インポート後、実機にデプロイし、動作を確認します。

実行結果

まとめ

HoloLensでオフライン検出を行うことができました。推論には時間が掛かりますが、
入力-ONNXモデル-出力 のフローを作ることができれば、多くの分野で活用できそうです。

参考

HoloLensでAzure Custom Vision Service - ObjectDetectionをWindows MLを使ってオフライン推論してみた。
https://qiita.com/miyaura/items/1b9210b5c5f75d8722a3


Azure Storage: AzCopy v10を試す

はじめに

2019/04/26、AzCopy v10がGAとなりました。
https://azure.microsoft.com/ja-jp/updates/azcopy-v10-is-now-generally-available/

AzCopy v10 の新機能に関してはドキュメントが詳しいですが、主だったところとしては以下のものが挙げられます。

  • ローカル - Blob Storage間の同期操作
  • Azure Data Lake Storage Gen2 のサポート
  • ストレージアカウント間での高速データコピー (Blob Storageのみ)
  • Amazon S3からのデータのコピー

今回は、Blob Storageの操作に関する新機能についてAzCopy v10の操作を検証していきます。

インストール

AzCopy v10はAzCopy v8までとは異なり、インストールが不要になりました。
ダウンロードページから使用するOSの実行ファイルをダウンロードし、適当なディレクトリに展開すれば使用することができます。
お好みでパスを通しておくと使いやすくなります。

認証

Azure Storageの操作の認証には以下の2つのオプションが使用できます。

  • Azure Active Directory (Azure AD)
  • Shared Access Signature (SAS)トークン

これらの認証オプションはサポートされるサービスが異なり、Azure ADはBlob StorageとData Lake Storage Gen2、SASトークンはBlob StorageとAzure Filesをサポートします。
Blob Storageはいずれの認証でも使用でき、今回の検証ではSASトークンによる認証で使用します。

ローカル - Blob Storage間の同期操作

AzCpoy v10から使用可能になった「sync」コマンドで、ローカルからBlobコンテナへの同期操作を試してみます。

まず、Azure Storage Explorerで同期先のBlobコンテナのSAS URLを生成します。
同期操作では、書き込みだけでなく、Blobのリスト操作が発生するため、「Write」、「List」のパーミッション設定が必須となります。また、設定によっては読み込み、削除も発生するため「Read」、「Delete」のパーミッションも適宜設定が必要になります。
今回は、いろいろな操作を試すので全パーミッション許可で作成します。

PowerShellでAzCopy v10のディレクトリを開き、下記コマンドで同期を開始します。サブディレクトリを含めて同期する場合は「--recursive=true」のオプションを設定します。
[crayon-633f85889da26891822470/]

実行すると同期先コンテナにローカルのファイルがコピーされていることが確認できました。Blob Storageの仕様上、空ディレクトリは作成できないため、ディレクトリ構造を完全にコピーすることはできません。

「New-Item」コマンドレットで同期元の「content」ディレクトリに新しいファイルを追加して、再度同期を実行してみます。
実行ログからBlobコンテナに1ファイルだけ転送されていることがわかり、差分ファイルのみ同期されていることがわかりました。
[crayon-633f85889da2c767795657/]

syncコマンドに「--delete-destination」オプションを設定すると同期元でのファイル削除を同期先に反映できます。
上で作成したファイルを削除して、「--delete-destination=prompt」を追加して同期を実行します。
削除が発生する場合は確認操作が入るため、「Y」または「A」で削除を許可します。(「--delete-destination=ture」の場合は確認がありません。)
[crayon-633f85889da2e260141573/]

コンテナを確認すると、同期元と同様にファイルが削除されていました。

ストレージアカウント間でのデータコピー

ストレージアカウント間のデータコピーはv8でも可能でしたが、v10ではコピー操作に「Put Block from URL」APIを使用することで操作の高速化が図られています。
このAPIは、ストレージアカウント間のデータコピーをクラウド上で完結させることで、クライアントのネットワーク帯域に依存せず高速にデータコピーができるようにしたもののようです。
ストレージアカウント間のデータコピーは「copy (cp)」コマンドを使用し、以下のコマンドで実行します。
[crayon-633f85889da31946503101/]
合計約300 MBの4つのBlobについてAzCopy v8.1とv10でコピー結果を比較すると、AzCopy v8.1は44秒かかったコピーが、v10ではわずか4秒 (0.0667分)と大幅に高速化されていることがわかりました。

Amazon S3からのデータコピー

Amazon S3からのデータコピーにも「copy (cp)」コマンドを使用します。ただし、実行するにはAWSのアカウントキーとシークレットアカウントキーが必要になります。

まずは、AWSコンソールでAzCopy用のIAMユーザーを作成しておきます。コピー操作なのでとりあえず「AmazonS3ReadOlnlyAccess」をつけて作成します。

作成が完了したら、csvをダウンロードしてアカウントキーとシークレットアカウントキーを保存します。

PowerShellでAzCopyのディレクトリを開き、下記コマンドで環境変数を設定します。「.\azcopy.exe env」コマンドを実行すると設定した環境変数が確認できます。
[crayon-633f85889da36298248981/]

コピー先のBlobコンテナのSAS URLを取得します。
Azure Storage Explorerでコピー先コンテナを右クリックして「Get Shared Access Signiture...」を選択します。

S3からの書き込みになるため「Write」のパーミッションを設定してSAS URLを生成します。

S3のバケットにコピーするファイルを配置します。

下記コマンドでS3の内容をBlobコンテナにコピーします。バケットやディレクトリのコピーを実行する場合は「--recursive=true」のオプションを設定しないとエラーが発生します。
[crayon-633f85889da39130251472/]

完了するとS3のファイルがBlobコンテナに反映されていることが確認できます。当然ながら、S3のディレクトリ構造までは反映されません。

まとめ

AzCopy v10は従来のAzCopyから大幅に仕様変更が行われており、syncコマンドなどの新機能により使い勝手もよくなっています。
v8以前を使用している場合にはコマンドの変更に伴う改修が必要になりますが、インストールが不要なことや、コピーの高速化、クライアントの負荷軽減といった機能改善も行われており、アップグレードによるメリットも大きいのではないでしょうか。


Windows Subsystem for Linuxを導入してWindows上のLinuxからAzure CLIを叩く

はじめに

Windows環境のBashからAzure CLIを叩くまでの導入手順を紹介していきます。
※Build 2019でWSL2のアナウンスがされていますが社内共有用の手順として作成しています。

WSLのインストール

機能の有効化
手元のデバイス側で Linux Subsystem の有効化を行います。
スタートアップボタンを右クリック時に表示される項目の「アプリと機能」を選択します。

そこから右側の「プログラムと機能」を選択します。

左側の一覧から「Windows機能の有効化または無効化」を選択します。

Windows Subsystem for Linux にチェックを入れます。

チェックを入れるとインストールが開始され、完了後に再起動を行います。

ストアからOSをインストール
Microsoft Store から Ubuntu を検索

以下の画面から今回は「Ubuntu 18.04LTS」を導入します。

入手を押すとインストール作業が開始します。

スタートもしくはストア画面からUbuntuを起動してインストールの完了を待ちます。
インストールが完了するとユーザ名とパスワードの設定を行います。

初期設定

リポジトリの変更
初期設定は海外サーバへリポジトリを取りに行く仕様となっています。
以下のコマンドから日本のサーバに切り替えを行います。

[crayon-633f85889dc77038337115/]

パッケージの更新
Linuxのアップデートはこまめにアップデートしましょう。

[crayon-633f85889dc7d297970868/]

Azure CLIのインストール (Ubuntu)

基本はこちらの公式ドキュメントに沿った内容になります。

パッケージの取得
インストールプロセス実行に必要なパッケージを取得します。

[crayon-633f85889dc7f050017138/]

署名キーのダウンロード及びインストール
Microsoftの署名キーをダウンロードしてインストールします。

[crayon-633f85889dc81677529256/]

Azure CLIソフトウェアリポジトリの追加

[crayon-633f85889dc83270925472/]

azure-cliのインストール
リポジトリ情報の更新とパッケージのインストールをします。

[crayon-633f85889dc85137525385/]

動作確認
Azure CLIのコマンドを利用して動作確認を行います。

[crayon-633f85889dc87096542807/]

以下の実行結果が表示され既定のブラウザでログイン画面へ遷移されればOKです。

参考記事

Windows Subsystem for Linuxをインストールしてみよう!
apt での Azure CLI のインストール


【python初学者向け】さくっとMicrosoft Azure Notebooks上でpython書いてみた

はじめに

Microsoft Azure Notebooks上でのJupyter Notebookの起動が、想像以上に簡単だったので手順をメモしておきます。

対象者

・python初学者
-オンラインで学習中
-Anacondaより簡単に環境設定を済ませたい
-環境設定で挫折した
・初学者にpythonの学習環境を用意しようとしている人
・Microsoft Azure Notebookって何?という人

ゴール

Azure Notebookを立ち上げ、コードセルに足し算を記述、実行できる。

Microsoft Azure Notebooksとは?

Microsoftが提供しているクラウドサービスであるAzure上でpythonを実行できる、Jupyter Notebookライクなサービスです。
Azure Notebooks

実行環境

・Windows 10
・Microsoftアカウント サインイン済
※アカウント未作成の方は、まずこちらから設定を。

手順

1.検索サービスでAzure Notebooksで検索、Microsoft Azure Notebooksをクリック

2.日本語の案内に従った後、下記画面でSign Inをクリック

3.create one now?をクリック

4.Project Nameを入力、Createをクリック

5.左上の+Newタブから、Notebookをクリック

6.Notebook Nameを入力、Pythonのバージョンを選択、Createをクリック

7.作成したNotebookをクリック

1.完成!

2.足し算できる!

まとめ

Microsoftアカウントの設定が済んでいれば、たったこれだけのステップで環境が立ち上がります。
簡単なのでぜひお試しを!


Azure Machine Learning service - Visual interfaceを試す

はじめに

Microsoft Build 2019にてAzure Machine Learning service (ML service)の新機能「Visual interface」が発表されました。
これまでコーディングが必要だったML serviceにおいてMachine Learning Studio (ML Studio)のようなDrag & DropのGUI操作が可能になるというもので、ML serviceがより使いやすくなることが期待できます。
今回はML serviceに追加された「Visual interface」を試してみます。

ワークスペースの作成

「+リソースの作成」で「Machine Learning service workspace」を検索し、ワークスペースの作成を開始します。

必要な内容を入力して作成を実行します。

Visual interfaceの利用

作成したワークスペースのリソースに移動し、メニューの「Studioワークスペースを起動」で「ワークスペースを起動」をクリックするとVisual interfaceが開きます。(タイトルが「Machine Learning Studio」なので少し戸惑います。)

Visual interfaceのUIは、ただのスタイル違いといっていいほどML StudioのUIと同じつくりになっています。

試しに、サンプルの実験「Sample 1 - Regression: Automobile Price Prediction (Basic)」で実験を作成してみます。
実験の新規作成、モジュールの操作はML Studioと同じで、ML Studioを使い慣れたユーザーであれば特に追加知識なく使うことができそうです。
ただし、プレビュー段階のためか、ML Studioと比較すると使用できるモジュールの種類は少ないため、まだ完全にML Studioを置き換えられるものではない印象です。


Visual interface とML Studioで異なるのは、実験の実行に「Compute Target」を指定する点です。
実験の内容によってスペックを変更できるのはML Studioにはなかったものです。

実験を実行してみます。今回は試しなので、Visual interfaceから作成できるスペック(Standard D2 v2 / 0~2ノード)でCompute Targetを作成して実行します。
プリセット以外のスペックを使用する場合は、あらかじめAzureポータルでCompute Targetを作成しておく必要があります。

Compute Targetの作成が入るため、初回の学習は約13分がかかりました。

Evaluate Modelで精度を見るとML Studioより若干精度は低いものの、概ね同等の精度となっていることがわかります。

実行結果に関しては、Azure ポータルでも確認できるようになっています。
今のところEvaluate Modelの内容は反映されず、試行ごとの精度を横並びで比較することまではできないようです。

Web Serviceのデプロイ

作成したモデルをWeb Serviceとしてデプロイします。
モデルのデプロイも「Compute Target」を指定する以外はML Studioと大きく変わりません。
実行が完了した実験のメニューから「Create Predictive Experiment」をクリックします。

ML Studioと同様に作成されたモデルが1つのモジュールに変化し、「Predictive Experiment」が新たに作成されます。
これを再度実行して、実験を完了させます。

この段階で、Azure ポータル側の「モデル」を確認しても学習済みモデルは表示されませんでした。

実験が完了するとグレーアウトしていた「Deploy Web Service」がクリックできるようになります。

「Deploy Web Service」をクリックするとCompute Targetの選択ウィンドウが表示されます。
まだWeb Service用Compute Targetがないため、「Create New」を選択するとCompute Targetの作成手順が表示されます。
Azureポータルで作成する必要があるようなので、一度Azureポータルに戻って作成を行います。

ワークスペースの「コンピューティング」で「+コンピューティングの追加」をクリックします。

作成手順に沿って「Kubernetes Service」のCompute Targetを作成します。
Kubernetes ServiceのCompute Target は12 コア以上でないと作成できないため、「インスタンスのコア数×ノード数」が12以上となるように設定して作成を行います。
12 コアの環境はちょっとした検証にはなかなかヘビーなので、Azure Container Instancesで簡単に検証できるオプションも欲しいところです。

作成に成功するとVisual interfaceのCompute Targetの選択ウィンドウでもリソースが表示され、デプロイできるようになります。

デプロイを行うと、Visual interface上の学習済みモデルからイメージが作成され、Web Serviceが作成されます。

この段階でAzure ポータル側の「モデル」を確認すると、学習済みモデルが登録されていることが確認できました。

Web Serviceのエンドポイント、APIリファレンスもVisual interfaceから確認できます。

テスト画面で予測を実行してみます。
実価格$13495の自動車について価格を予測してみると「Scored Label」が13903.18とそれらしい値が出てきており、Web Serviceが正常に稼働していることがわかりました。

まとめ

思っていた以上にML StudioそのままのUIで、ML Studioは使ってきた身としては何不自由なく扱うことができました。
コーディングが必要でML serviceに手を出し辛かったユーザーにとっては、ML serviceに手を出す良いきっかけになりそうです。
まだプレビューが公開されたばかりで、モジュールが少なかったり、Web Serviceのデプロイが少し面倒だったりと洗練されていない部分はありますが、ML serviceに最適化された機能が追加され、使いやすくなっていくことに期待したいです。