Azureアーキテクチャガイドまとめ 3 【Webキューワーカー】

はじめに

Azureクラウドアプリケーションアーキテクチャガイドより、7つあるアーキテクチャスタイルの一つ、Webキューワーカーに関してまとめます。
※前回記事
Azureアーキテクチャガイドまとめ 1 【はじめに】
Azureアーキテクチャガイドまとめ 2【N層】

概要

このアーキテクチャスタイルのコアコンポーネントは以下の3点。
クライアント要求にこたえるWebフロントエンド
バッチジョブを実行するワーカー
もしくはCPUを集中的に使用するタスク
非同期メッセージキュー
これらに加えて、一般的に以下のコンポーネントが組み込まれます。
システムの要件にフィットする範囲で、特定の機能を分離し、各種マネージドサービスを組み合わせる、というイメージです。
1つまたは複数のデータベース
DB読み取り高速化のためのキャッシュ
静的コンテンツを提供するCDN
構成図は以下の通り。

以下のような特徴を持つアプリケーションに適しています。
比較的単純なドメインのアプリケーション
時間のかかるワークフローバッチ操作があるアプリケーション

利点

・理解しやすい比較的単純なアーキテクチャ
展開と管理の容易さ
・フロントエンドとワーカーは独立に拡張可
・懸念事項の明確な分離

課題

情報の入出力が多いコンポーネントでは、システムの要望に応じてコードが肥大化しやすい傾向があります。
・フロントエンドとワーカーが、複数の機能を持った単一のコンポーネントになりやすい (= モノリシックコンポーネント)
・フロントエンドとワーカーがデータスキーマやコードモジュールを共有している場合、隠れた依存関係が存在する可能性あり

ベストプラクティス

各マネージドサービスでベストプラクティスが用意されています。
・適切であれば、複数のストレージ技術を混在させる
・以下のベストプラクティス設計に準ずる
API 設計のベストプラクティス
自動スケールのベストプラクティス
キャッシングのベストプラクティス
CDN のベストプラクティス
ジョブに最適なデータストアの使用 データのパーティション分割のベストプラクティス

対応するAzureサービス

核となるサービスは、App Serviceです。
WebjobsApp Serviceのサービスの一つで、ワーカーの役割を果たします。これらをQueue StorageもしくはService Busでつなげる形です。
アイコンと概要をまとめます。

先ほどの構成図にあるアーキテクチャを組んだ場合、以下のような構成になります。
※ 図ではDocumentDBになっていますが、現在はCosmosDBとしてリニューアルされていますのでご注意を。

まとめ

Webキューワーカーの特徴と、使用されるサービスについて見ていきました。次回はCQRSについてまとめます。お楽しみに!

参考リンク

Azureアーキテクチャセンター
Azureクラウドアプリケーションアーキテクチャガイド ダウンロードページ


Azureアーキテクチャガイドまとめ 2【N層】

はじめに

Azureクラウドアプリケーションアーキテクチャガイドより、7つあるアーキテクチャスタイルの一つ、N層アーキテクチャに関してまとめます。
※前回記事
Azureアーキテクチャガイドまとめ 1 【はじめに】

概要

N層アーキテクチャと呼ばれるもの中で代表的なものが、以下の三層アーキテクチャです。
・プレゼンテーション層
・中間層
・データ層
下記の例では、中間層が二つ(Middle Tier 1 / Middle Tier 2)あり、別々の機能を持たせています。名称はとっつきにくいですが、よく見るような一般的な構成です。

以下のような特徴を持つアプリケーションに適したアーキテクチャスタイルです。
単純なWebアプリケーション
・オンプレアプリをAzureに最小限のリファクタリングで移行
・オンプレアプリとクラウドアプリの統一的開発

特徴は以下の通り。

一般的なIaaSアプリとしての実装
・レイヤー
-論理レイヤーと物理レイヤーに分断し、責任を分離し、依存関係を管理する
-上位レイヤーは下位レイヤーのサービスを利用可。逆は不可
・2種のアーキテクチャ
-クローズドレイヤー (直下のレイヤーのみを呼び出し可)
-オープンレイヤー (下のすべてのレイヤーを呼び出し可)

利点

・オンプレ/クラウド間の移植性が高い
・エンジニアにとって学習コストが低い
・異種混在環境(Windows/Linux)への適合性が高い

課題

・各機能の独立展開不可
管理コストが高い
・大規模システムのセキュリティ管理が難しい場合あり
・中間層が無意味に待ち時間を増やす場合あり

ベストプラクティス

スケーラビリティ、信頼性、セキュリティの各層の境界としてサブネットを活用し、以下のマネージドサービスを利用する
・キャッシング
・オートスケール
・ロードバランサ
・メッセージング
-各層の分離に非同期メッセージングを使用
・データストレージ
-アクセス制限のため、中間層からの要求だけ許可
-高可用性実現のため、可用性グループを使用

対応するAzureサービス

各層のコンピューティングにVirtual Machineを利用し、マネージドサービスを追加していく形です。アイコンと一緒に覚えてしまいましょう。

まとめ

N層アーキテクチャの特徴と、使用されるサービスについて見ていきました。次回はWebキューワーカーについてまとめます。お楽しみに!

参考リンク

Azureアーキテクチャセンター
Azureクラウドアプリケーションアーキテクチャガイド ダウンロードページ


Azureアーキテクチャガイドまとめ 1 【はじめに】

はじめに

Azureクラウドアプリケーションアーキテクチャガイド。皆さんご存知でしょうか?
いわば、Azure版のWell-Architectedフレームワークです。非常に示唆に富む内容なので、分からない用語や概念を調べつつ、まとめようと思います。
本稿では、「はじめに」から、第一章「アーキテクトスタイルの選択」の導入部までを扱います。

従来のオンプレ環境と最新のクラウド環境

ご存知の通り、クラウドまわりの技術は急速に進化しています。マイクロサービス、コンテナ、AI/MLなどなど。
流れが早すぎて潮流が読めないなと感じていた折、冒頭に従来のオンプレ環境と"最新の"クラウド環境の比較表を発見。図示します。

何かしら指針がないと沈没しそうです。
さて、本ガイドはどんな内容でしょうか?

"このガイドでは、スケーラブルで回復性と可用性が高いクラウド アプリケーションを設計するための構造化されたアプローチについて解説します。
(本文より抜粋)”

構造化されたアプローチ、いい言葉ですね。詳しく見ていきましょう。

ガイドの構成

ガイドは以下の5つステップで構成されています。
1. アーキテクチャスタイルの選択
2. コンピューティングおよびデータストア用テクノロジの選択
3. Azureアプリケーションの設計 10の原則
4. ソフトウェア品質 5つの柱
5. クラウド設計パターンの適用

ステップ1を行う前に、アーキテクチャの要件の明確化が必要になります。
というより、明確にしないと先に進めないようになっています。
設計後半で要件の見落しに気づいて大幅な手戻りが...なんて場面を回避できます。ついつい技術要素に目が向きがちなので、これはありがたい。

アーキテクチャスタイルの選択

要件の集合からテンプレートを選択というイメージです。合計7パターン。

各スタイルの概要は下記の通り。

用語は聞いたことあっても、具体的に何のことを言っているのかわからない、というのが正直な感想。

制約・課題・利点

それぞれのスタイルの説明に移る前に、なぜこの段階で型にはめる必要があるのかを整理します。
スタイルの選択は、制約をもたらす
各スタイルは、固有の課題を持っている
制約を満たす場合、利点が生まれる
制約、課題、利点の概要と関係性を図示します。

もっとも利点マイナス課題が大きくなるスタイルを見つけることで、最適なアーキテクチャに最短距離で近づくことが出来る、という格好です。

おわりに

次回以降は各アーキテクチャスタイルについて解説します。お楽しみに!

参考リンク

Azureアーキテクチャセンター
Azureクラウドアプリケーションアーキテクチャガイド ダウンロードページ


【AI入門】第4弾 Azure Databricks : Pyspakの基本操作をやってみた!

はじめに

これまでのAzure Databricks の操作紹介第4弾目の記事です。
【Azure Databricks: 3-2. DBFSにAzure Data Lake Storage Gen2をマウント】の続きになります。
これまでの記事は以下のから参照できます。
Azure Databricks: 1. リソースの作成
Azure Databricks: 2. Databricksの基本事項
Azure Databricks: 3-1. DBFSにBlob Storageをマウント
Azure Databricks: 3-2. DBFSにAzure Data Lake Storage Gen2をマウント

この記事の概要

この記事では、サンプルデータからAzure Databricks を利用した Spark の操作について紹介しています。
PySpark ・ SQL を使いながらデータ分析を行い最後はCSV形式で出力します。

こんな方に読んでもらいたい

  • Databricks に関して興味のある方
  • PySpark ・ Spark SQL を勉強している方
  • データ分析に興味のある方

サンプルデータセット

今回はkaggleのデータセット「Brazilian E-Commerce Public Dataset by Olist」をサンプルデータとして使います。
このデータはOlist StoreというブラジルのECサイトで行われた2016年から2018年までの約10万件の注文に関するデータが含まれています。
データ量としてはビッグデータというほどに多くありませんが、注文の商品明細やレビューなどが複数のCSVに分かれて保存され、それぞれがIDで紐づけられているため、PySparkやSpark SQLの練習に適しています。

CSVの読み込み

注文ごとの商品の明細情報「olist_order_items_dataset.csv」を使ってデータの読み込みとPySparkの操作を行っていきます。

DataFrameに読み込み

下記スクリプトでCSVをSpark DataFrameとして読み込みます。
読み込むCSVはカラム名を示す行が先頭にあるため、読み込みオプションとして「header=”true”」、またカラムのデータ型を自動推定するため「inferSchema=”true”」として読み込んでいます。
(※CSV読み込みオプションの詳細はDatabricksドキュメントも参照してください)

[crayon-61efa3bd821b7772220787/]

画像1.png

スキーマを指定して読み込み

スキーマを指定して読み込みを行う場合は下記のようにします。

※指定できる型はSparkドキュメントも参照
カラムのデータ型指定にinferSchemaを使用した場合、型推定のため1回余計に読み込むことになり、読み込みのパフォーマンスが低下します。
データのスキーマがわかっている場合は、スキーマを指定して読み込むことを推奨します。

[crayon-61efa3bd821c0502254647/]

画像2.png

データ型の確認

[crayon-61efa3bd821c3502984272/]

画像3.png

PySparkでのDataFrameの基本操作

読み込んだCSVでPySparkの基本操作を実行します。
指定行数抽出して表示

[crayon-61efa3bd821c5951963508/]

画像4.png

全レコード数のカウント

[crayon-61efa3bd821c7605959981/]

画像6.png

計算列の追加

[crayon-61efa3bd821c9129550108/]

画像7.png

カラムを指定して抽出

[crayon-61efa3bd821cc724333336/]

画像8.png

条件でレコード抽出

[crayon-61efa3bd821ce231300387/]

画像9.png

レコードのカウント

[crayon-61efa3bd821d0510122288/]

画像10.png

レコードの集計

[crayon-61efa3bd821d2012931169/]

画像11.png

Spark SQLを使用した操作

DataFrameをTemp Tableに登録することでSpark SQLを使用した集計が可能になります。
Temp Tableの登録

[crayon-61efa3bd821d5756308837/]

画像12.png

Spark SQLによるカラム抽出

[crayon-61efa3bd821d7624189402/]

画像13.png

%sqlマジックコマンドを使用する場合

[crayon-61efa3bd821d9819300299/]

画像13.png

DataFrameの結合

データセットに含まれる他のCSVファイルと組み合わせて商品カテゴリごとの売り上げを集計してみます。
各商品の詳細情報「olist_products_dataset.csv」をDataFrameに読み込みます。

[crayon-61efa3bd821db386667577/]

画像15.png

[crayon-61efa3bd821dd203726105/]

画像16.png

2018年1月の商品カテゴリごとの売り上げ金額を集計します。
「sum(price)」をソートすると「relogios_presentes」の売り上げが最も高いことがわかりますが、ポルトガル語なので何の商品カテゴリかわかりません。

[crayon-61efa3bd821e0494979750/]

画像17.png

データセットにカテゴリを英語翻訳したCSVファイルがあるため、これも読み込みます。

[crayon-61efa3bd821e2063331183/]

画像18.png

結合して翻訳します。

[crayon-61efa3bd821e4154838352/]

画像19.png

Databricksではデータの可視化も簡単にできます。
売り上げが最も高いのは「watches_gifts」であることがわかりました。
画像20.png

CSVの書き出し

DataFrameを書き出す場合は下記コマンドを使用します。

[crayon-61efa3bd821e7227304672/]

画像21.png

CSVは指定したパスに直接書き出されるのではなく、指定パスのディレクトリが作成され、直下に分割されたCSVファイルとして出力されます。

[crayon-61efa3bd821e9321332181/]

画像22.png

ファイルを1つのCSVとして出力する場合は、HadoopのFileUtil.copyMergeを使用し、上記で出力したファイルをマージして1ファイルにまとめます。

[crayon-61efa3bd821ec293745547/]

画像23.png

[crayon-61efa3bd821ee093749443/]

画像24.png

Clusterのメモリ量に余裕がある場合は、下記スクリプトで1ファイルにデータを書き出すことができます。
この場合でも「output.csv/part-00000-xxxxxxxxx.csv」のような名称でファイルが出力されるため、出力後必要に応じてファイルの移動を行います。

[crayon-61efa3bd821f0884853953/]

画像25.png

[crayon-61efa3bd821f2466754459/]

画像26.png

最後に

Azure Databricks 上で Spark を操作していきました。
データを元に特定の課題解決に向けて Azure Databricks を活用する1つの方法として知っていただけたと思います。
今後も様々なデータを Azure Databricks 上で分析していきたいです。

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

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

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

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


Azure Databricks: 3-2. DBFSにAzure Data Lake Storage Gen2をマウント

前回記事

Azure Databricks: 1. リソースの作成
Azure Databricks: 2. Databricksの基本事項
Azure Databricks: 3-1. DBFSにBlob Storageをマウント

サービスプリンシパルの作成

Azure DatabricksのDBFSにAzure Data Lake Storage Gen2 (ADLS Gen2)をマウントするには、サービスプリンシパルの設定が必要になるため,あらかじめ作成しておきます。
(サービスプリンシパルはアプリケーションに対して割り当てるユーザーIDのようなものです。)
「すべてのサービス」の「ID」カテゴリから「Azure Active Directory」を開きます。

メニューの「App registrations」を開き、「+新規作成」をクリックします。

「名前」に任意の名称を入力し、「リダイレクトURI」にAzure DatabricksのURL( https://japaneast.azuredatabricks.net/ )を入力して「登録」をクリックします。

登録後に表示される「アプリケーション(クライアント)ID」と「ディレクトリ(テナント)ID」はマウント時のパラメータとして必要になるため、コピーして控えておきます。

続いて、サービスプリンシパルのクライアントシークレットを作成します。
メニューの「証明書とシークレット」を開き、「+新しいクライアントシークレット」をクリックします。
「説明」と「有効期限」を設定して「追加」をクリックします。

作成されるとクライアントシークレットの文字列が表示されます。この文字列は作成後最初の1回しか表示されないため、コピーして控えておきます。
クライアントシークレットもマウント時の必要パラメータとなります。
(秘密情報の管理にAzure Key Vaultを使用する場合はクライアントシークレットをキーコンテナーに登録しておきます。)

Azure Data Lake Storage Gen2 (ADLS Gen2)とファイルシステムの作成

ADLS Gen2はAzure Storageのオプション扱いであるため、作成はストレージアカウントの作成の手順に準じます。
作成の変更点は、作成の「詳細」設定で「階層構造の名前空間」を有効化することです。
(ADLS Gen2は後から有効化できないため、使用する場合は新規でストレージアカウント作成が必要です。)

作成が完了したら、作成したリソースを開きます。
「階層構造の名前空間」を有効化していると、概要の「サービス」が「Blob」から「Data Lake Gen2ファイルシステム」に変化しています。

ファイルシステムの作成

ADLS Gen2にファイルシステムを作成します。
「Data Lake Gen2ファイルシステム」をクリックしてADLS Gen2メニューを開きます。

「+ファイルシステム」をクリックし、「名前」に任意の名称を入力して作成を行います。

ADLS Gen2へのアクセス権限の付与

サービスプリンシパルに対するADLS Gen2のアクセス権限の付与します。
作成したファイルシステムを開きます。

メニューから「アクセス制御(IAM)」を開いて「ロールの割り当てを追加する」をクリックします。

「役割」を「ストレージBLOBデータ共同作成者」に変更し、「選択」で作成したサービスプリンシパルを選択して「保存」をクリックします。

「ロールの割り当て」タブをクリックするとサービスプリンシパルに割り当てられた権限が確認できます。

ADLS Gen2をDBFSにマウント

DBFSにADLS Gen2をマウントするには、下記のスクリプトを使用します。
(ストレージ、サービスプリンシパル情報、マウント先DBFSディレクトリは作成したリソースに合わせて変更してください。)
[crayon-61efa3bd82e77626275096/]

参考

3分でわかるAzureでのService Principal
ナレコムAzureレシピ - Azure Databricksを使ってみた
Databricks Documentation - Data Sources - Azure Data Lake Storage Gen2
チュートリアル:Spark を使用して Azure Databricks で Data Lake Storage Gen2 のデータにアクセスする

 

 

 

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

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

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

 

 


【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-61efa3bd83703667261286/]

画像12.png

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

[crayon-61efa3bd8370b172538399/]

画像13.png

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

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

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

[crayon-61efa3bd8370d414460148/]

画像14.png

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

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

[crayon-61efa3bd83710360111102/]

画像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-61efa3bd83715115163638/]

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

[crayon-61efa3bd8371d542144977/]

最後に

ストレージアカウントの作成から 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-61efa3bd83ff6833638390/]

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

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

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

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

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

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

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

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

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

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

参考

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-61efa3bd84861754836509/]

Memoryの使用率

[crayon-61efa3bd84867151797226/]

Diskの空き容量

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


#sample query

[crayon-61efa3bd84869722811361/]

Heartbeatの監視(死活監視)

[crayon-61efa3bd8486b315695677/]

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

[crayon-61efa3bd8486d579090232/]

※データの保持期間がデフォルトで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環境内で完結したい
  • ランニングコストの予算内にとどめたい