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クラウドアプリケーションアーキテクチャガイド ダウンロードページ
Azure Databricks: 4. PySpark基本操作
前回記事
Azure Databricks: 1. リソースの作成
Azure Databricks: 2. Databricksの基本事項
Azure Databricks: 3-1. DBFSにBlob Storageをマウント
Azure Databricks: 3-2. DBFSにAzure Data Lake Storage Gen2をマウント
サンプルデータセット
今回はkaggleのデータセット「Brazilian E-Commerce Public Dataset by Olist」をサンプルとして、Azure Databricksを使ったSparkの操作を行っていきます。
このデータは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-601275c6af451490370013/]
スキーマを指定して読み込み
スキーマを指定して読み込みを行う場合は下記のようにします。
※指定できる型はSparkドキュメントも参照
カラムのデータ型指定にinferSchemaを使用した場合、型推定のため1回余計に読み込むことになり、読み込みのパフォーマンスが低下します。
データのスキーマがわかっている場合は、スキーマを指定して読み込むことを推奨します。
[crayon-601275c6af459584202413/]
データ型の確認
[crayon-601275c6af45b164047649/]
PySparkでのDataFrameの基本操作
読み込んだCSVでPySparkの基本操作を実行します。
指定行数抽出して表示
[crayon-601275c6af45c239896719/]
全レコード数のカウント
[crayon-601275c6af461072243982/]
計算列の追加
[crayon-601275c6af463557933008/]
カラムを指定して抽出
[crayon-601275c6af464951358233/]
条件でレコード抽出
[crayon-601275c6af465704165536/]
レコードのカウント
[crayon-601275c6af466526932054/]
レコードの集計
[crayon-601275c6af467574837480/]
Spark SQLを使用した操作
DataFrameをTemp Tableに登録することでSpark SQLを使用した集計が可能になります。
Temp Tableの登録
[crayon-601275c6af468593723779/]
Spark SQLによるカラム抽出
[crayon-601275c6af469224252967/]
%sqlマジックコマンドを使用する場合
[crayon-601275c6af46a739797387/]
DataFrameの結合
データセットに含まれる他のCSVファイルと組み合わせて商品カテゴリごとの売り上げを集計してみます。
各商品の詳細情報「olist_products_dataset.csv」をDataFrameに読み込みます。
[crayon-601275c6af46b123571384/]
[crayon-601275c6af46e169942572/]
2018年1月の商品カテゴリごとの売り上げ金額を集計します。
「sum(price)」をソートすると「relogios_presentes」の売り上げが最も高いことがわかりますが、ポルトガル語なので何の商品カテゴリかわかりません。
[crayon-601275c6af470996386805/]
データセットにカテゴリを英語翻訳したCSVファイルがあるため、これも読み込みます。
[crayon-601275c6af471326253489/]
結合して翻訳します。
[crayon-601275c6af472357963809/]
Databricksではデータの可視化も簡単にできます。
売り上げが最も高いのは「watches_gifts」であることがわかりました。
CSVの書き出し
DataFrameを書き出す場合は下記コマンドを使用します。
[crayon-601275c6af474363124733/]
CSVは指定したパスに直接書き出されるのではなく、指定パスのディレクトリが作成され、直下に分割されたCSVファイルとして出力されます。
[crayon-601275c6af475972251936/]
ファイルを1つのCSVとして出力する場合は、HadoopのFileUtil.copyMergeを使用し、上記で出力したファイルをマージして1ファイルにまとめます。
[crayon-601275c6af476433820741/]
[crayon-601275c6af479779845027/]
Clusterのメモリ量に余裕がある場合は、下記スクリプトで1ファイルにデータを書き出すことができます。
この場合でも「output.csv/part-00000-xxxxxxxxx.csv」のような名称でファイルが出力されるため、出力後必要に応じてファイルの移動を行います。
[crayon-601275c6af47a306420137/]
[crayon-601275c6af47b777769847/]
Azure Databricksの導入ならナレコムにおまかせください。
導入から活用方法までサポートします。お気軽にご相談ください。
Azure 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-601275c6b03bb925931703/]
参考
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: 1. リソースの作成
Azure Databricks: 2. Databricksの基本事項
ストレージアカウントの作成
※既存のBlob Storageをマウントする場合は「DBFSにBlob Storageをマウント」から操作を実行します
Azureポータルの「リソースの作成」をクリックし、一覧から「ストレージアカウント」を選択して作成を開始します。
作成に必要な情報を入力します。設定内容は任意ですが、「リソースグループ」と「場所」はAzure Databricksと同じものを指定します。設定が出来たら「次: 詳細 >」をクリックします。
「詳細」設定に関してはデフォルトのままで、「確認および作成」をクリックします。
設定内容に誤りがないことを確認して、「作成」をクリックします。
しばらく待機し、作成が完了したら作成したリソースに移動します。
マウント時のパラメータとしてストレージアカウントの「アクセスキー」必要となるため、メニューの「アクセスキー」を開いて、「key1」、「key2」いずれかの「キー」をコピーして控えておきます。
Blobコンテナーの作成とファイルの配置
ストレージアカウントのメニューの「概要」に戻り、「サービス」の「BLOB」をクリックします。
「+コンテナー」をクリックして、「名前」を任意のコンテナ名、「パブリックアクセスレベル」を「プライベート」としてコンテナを作成します。
ファイルを配置するため作成したコンテナーをクリックし、コンテナーを開きます。
「↑アップロード」をクリックして、ファイルを選択し、「アップロード」をクリックします。
アップロードが完了するとコンテナーにファイルのリストが表示されます。
DBFSにBlob Storageをマウント
Blobコンテナーのマウント
Blob Storageのマウントは下記のスクリプトを使用します。(ストレージ情報、マウント先DBFSディレクトリは作成したリソースに合わせて変更してください。)
一度マウントすると、Clusterを停止、変更してもマウント状態が維持されます。
マウントされた状態で再度操作を実行するとエラーが発生するため、マウント状態をチェックするか、スクリプトをコメントアウトしてエラーの回避します。
[crayon-601275c6b0f1d354906445/]
下記スクリプトでマウントされているディレクトリを確認します。
Blob Storageをマウントしたディレクトリがリストで確認できます。
[crayon-601275c6b0f23195385102/]
マウントされたディレクトリの確認
下記スクリプトを使用してマウントしたディレクトリ内のファイルを表示します。
※ マウントしたディレクトリにファイルが存在しないとエラーが発生します。
[crayon-601275c6b0f24795289201/]
Blobコンテナーのアンマウント
ストレージのマウントを解除する場合は下記スクリプトを使用します。
[crayon-601275c6b0f25105687394/]
秘密情報の安全な管理
秘密情報をスクリプト上に記載することはセキュリティ上の懸念となります。
ストレージアカウントキーのような秘密情報を安全に管理するため、Azure Key Vaultの使用が推奨されます。
Azure Key Vaultのキーコンテナー作成
Azureポータルの「リソースの作成」で「Key Vault」を検索し、検索候補の「Key Vault」をクリックして作成を開始します。
「キーコンテナーの作成」に必要な情報を入力します。「名前」は任意の名称、「リソースグループ」、「場所」Azure Databricksと同じものを指定します。その他の設定はデフォルトのままとします。
作成が完了したらリソースに移動します。
キーの登録
作成したキーコンテナーにストレージアカウントキーを登録します。
作成したリソースのメニューから「シークレット」を開いて「+生成/インポート」をクリックします。
「アップロードオプション」を「手動」として、「名前」、「値」に任意の名称とストレージアカウントキーを入力し、「作成」をクリックします。
DatabricksにAzure Key Vaultを登録
キーコンテナーのメニューから「プロパティ」を開き、「DNS名」と「リソースID」をコピーして控えておきます。
Databricksワークスペースのホーム画面を開き、URLに「#secrets/createScope」を追加して「Create Secret Scope」のページを開きます。
「Scope Name」に任意のスコープ名を入力し、「DNS Name」、「Resource ID」に作成したキーコンテナーの「プロパティ」で取得した「DNS名」、「リソースID」を入力します。
Databricks作成時にStandard Planを選択した場合、「Manage Principal」は「All Users」のみ選択できます。
入力したスコープ名はキーの取得に必要となるため控えておきます。
Notebookを開き、下記のスクリプトでスコープのリストを確認します。
スコープが登録されていると、登録したスコープがリストにあることが確認できます。
[crayon-601275c6b0f28936242512/]
BlobコンテナーのマウントにKey Vaultのキーを使用する場合は、Blob Storageの情報を下記のように書き換えます。
[crayon-601275c6b0f31647229487/]
参考
Databricks Documentation - Data Sources - Azure Blob Storage
クイックスタート:Azureポータルを使用してAzure Key Vaultから秘密を設定および取得する
Azure Databricksの導入ならナレコムにおまかせください。
導入から活用方法までサポートします。お気軽にご相談ください。
Azure Databricksソリューションページはこちら
Azure Databricks: 2. Databricksの基本事項
前回記事
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-601275c6b1aa3192910554/]
Databricks File System(DBFS)のファイル操作: %fs
Databricksの分散ファイルシステムであるDBFSのリスト、コピーといったファイル操作をシェルコマンドライクに記述して実行します。
ディレクトリにあるファイルのリストを表示する場合は、下記コマンドを使用します。
[crayon-601275c6b1aa7252487364/]
上記コマンドはPythonの下記スクリプト実行結果と同等となります。
[crayon-601275c6b1aa9659683568/]
OS (Linux)のシェルコマンド実行: %sh
OSのシェルコマンドを実行する場合には「%sh」を使用します。
DBFSを%shで参照する場合は下記のとおりです。
[crayon-601275c6b1aaa755547013/]
各言語のスクリプト実行: %python, %scala, %sql, %r
Notebookで指定した言語以外の言語を使用する場合は、対応言語のマジックコマンドを使用します。
[crayon-601275c6b1aab648168320/]
[crayon-601275c6b1aac635818312/]
言語間で変数は共有されないため、マジックコマンドの変数に値を引き渡す場合は一旦DBFSにファイル出力をする等で渡す必要があります。
他のNotebookの実行と読み込み: %run
他のNotebookを実行する場合は「%run」で対象Notebookを指定して実行します。
%runで実行すると、同じ言語であれば他のNotebookで定義された変数をそのままの変数名で参照することができます。
メンテナンス性を高めるために、スキーマ定義を別Notebookで記述しておくといったような使い方ができます。
[crayon-601275c6b1aad309833267/]
参考
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-601275c6b2660301739561/]
Memoryの使用率
[crayon-601275c6b2664484911543/]
Diskの空き容量
※デフォルトではトータルのディスク空き容量しか取得できません。
CやDドライブのみデータを取得したい場合には[詳細設定]よりパフォーマンスカウントを追加します。
#sample query
[crayon-601275c6b2666017122474/]
Heartbeatの監視(死活監視)
[crayon-601275c6b2668594921492/]
取得したデータ(CPU / メモリ / ディスク)のメトリック表示
[crayon-601275c6b2669505345641/]
※データの保持期間がデフォルトで30日の為、30日以前のデータを取得したい場合、保持期間を変更する必要があります。
アラートの設定方法
上記のqueryを実行した後、[新しいアラートルール]を選択します。
[条件]からアラートの閾値を設定
[アクション]から通知先を設定
[アラートの詳細]で通知アラートの件名/説明を記入
まとめ
上記以外にも様々なデータを取得することが可能です。
本記事で紹介したリソースの監視以外にもLogAnalyticsではログの監視なども可能です。
リソース監視以外の部分については別記事でご紹介できればと考えています。
Azure LogAnalytics 概要についてまとめてみた
こんにちは、ナレコムのDreamです。
Azure LogAnalyticsに触れる機会があったので、まとめていきたいと思います。
Azure LogAnalyticsとは
そもそもAzure LogAnalyticsとはどんなサービスで何ができるのかを簡単にまとめます。
・Azureサービス/Azure VMはもちろんのこと、オンプレミス/他クラウドサービスのWindowsやLinuxのログを収集し分析するためのサービスです。
・対象サーバにエージェントをインストールするだけで、簡単に使用することができます。
・収集したデータに閾値を設定し、アラートを発報することができる。
・収集したデータをダッシュボードに集約し、可視化が可能。
[補足]
最近Azure Monitor ログという名称に変更がありました。
これは、Azure Monitor に大きな変更が加えられ、Azure のお客様が監視を簡単に行えるようにするためにさまざまなサービスが統合された為です。
※本記事では、Azure LogAnalyticsで統一します。
[参考URL:https://www.slideshare.net/ssuser147cbc/azure-log-analytics-107802877]
収集できるデータ
[1]Windowsイベントログ
Windowsイベントログのイベントのみを収集(Azure Monitor での Windows イベント ログのデータ ソース)
[2]Windowsパフォーマンスカウンター
Windowsのハードウェアコンポーネント、オペレーティングシステム、およびアプリケーションのパフォーマンスに関する情報の収集(Azure Monitor での Windows および Linux のパフォーマンス データ ソース)
[3]Linuxパフォーマンスカウンター
Linuxのハードウェアコンポーネント、オペレーティングシステム、およびアプリケーションのパフォーマンスに関する情報の収集(Azure Monitor での Windows および Linux のパフォーマンス データ ソース)
[4]IISログ
W3C形式で格納されたIISログファイルのみを収集(Azure Monitor での IIS ログを収集する)
[5]カスタムログ
WindowsとLinuxの両方のテキストファイルからイベントを収集(Azure Monitor のカスタム ログ)
[6]Syslog
Linuxのrsyslogまたはsyslog-ngによって送信されたメッセージの収集(Azure Monitor の Syslog データ ソース)
価格
LogAnalyticsでは、サービスに取り込まれたデータがギガバイト(GB)単位で課金されます。
※デフォルトの設定ではデータ保持期間が30日に設定されています。
[1]データインジェスト
¥374.08/GB8 (含まれている無料ユニット:顧客あたり5GB/月)
[2]データ保持
1GBあたり¥16.80/月 (含まれている無料ユニット:31日)
Azure Monitorの価格
使用方法
AzurePortalへログインし、[LogAnalyticsワークスペース]を選択
LogAnalyticsワークスペースを新規作成
ワークスペース名/サブスクリプション/リソースグループ/場所/価格レベルを選択
※LogAnalyticsワークスペースを作成するリソースグループは運用条件によって、LogAnalytics専用のグループを作成するか監視対象リソースと同じグループを使用するかを決める
ワークスペースのデータソースより[仮想マシン]を選択
対象の仮想マシンを選択し接続(接続に時間を要する場合があります)
※本記事ではAzure VM(WindowsServer)を対象にしてます。
LogAnalyticsワークスペースの[詳細設定]から収集するデータを選択
Dataから収集したいデータを選択し保存
※Azure VM(Windows)のパフォーマンスカウンターを取得したい場合は、別途Azure VMの[診断設定]-[ゲストレベルの監視を有効にする]をONにする必要があります。
LogAnalyticsワークスペースの[ログ]から収集したデータの検索やアラートの設定が可能
ここではKustoクエリを使用します。(kustoクエリ 概要)
Kustoクエリ
英語のみとなりますが、ウェビナーもあります。(Kusto Query Language (KQL) from Scratch)
以下にAzure LogAnalyticsでよく使用するクエリをまとめます。
クエリの基本構文は テーブル名|コマンド1|コマンド2... となります。
[1]Syslog
LinuxのSyslogの取得
[2]Event
Windowsイベントログの取得
[3]Perf
パフォーマンスカウンターからリソース使用率を取得可能(Perfのみで実行すると接続しているコンピュータ名が確認可能)
[4]Heartbeat
死活監視等に使用します。
※Azure Monitor ログ クエリの例
グラフ
LogAnalyticsワークスペースから[ビューデザイナー]を選択
一部プレビューの機能もあります。
表示したいグラフを選択し、表示メトリックのクエリ等を設定する
さいごに
便利な機能が多いので、すべてを書ききれてはいませんが、Azure LgAnalyticsについてまとめました。
次の記事では、Azure VM(WindowsServer)を対象に、Azure LogAnalyticsを使用してのリソース監視についてまとめたいと思います。
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-601275c6b3168160762340/]
ターゲットはRelease/X86に変更します。
学習させた.onnxモデルをAssetフォルダ内にインポートします。
「ビルドアクション」はコンテンツ、「出力ディレクトリにコピー」は常にコピーするを選択します。
プロジェクトからNuget管理を開き、System.ValueTuple ライブラリをインポートします。
インポート後、実機にデプロイし、動作を確認します。
実行結果
まとめ
HoloLensでオフライン検出を行うことができました。推論には時間が掛かりますが、
入力-ONNXモデル-出力 のフローを作ることができれば、多くの分野で活用できそうです。
参考
HoloLensでAzure Custom Vision Service - ObjectDetectionをWindows MLを使ってオフライン推論してみた。
https://qiita.com/miyaura/items/1b9210b5c5f75d8722a3