(仮) ブログ

主にWeb Apps や、Azure PaaS サービス を使う際に役立ちそうなことを書こうと思っています。

Azure Resource Graph と、GraphToPolicy を使ってポリシーを作成してみた

こちらの記事は、Qiita に掲載した Microsoft Azure Tech Advent Calendar 2018 の企画に基づき、執筆した 内容となります。(4 日目)

qiita.com

目次

Azure Resource Graph とは ?

Azure Resource Graph は、管理グループやサブスクリプションを横断して、リソースをクエリしてくれるプラットフォームの機能です。 Azure Policy や、Azure Blueprint、管理グループとともに Azure Governance のコンポーネントとサービスの一つであり、クエリを利用してリソースの管理を行うことが可能です。

この動画を見て便利な機能だなと思い、まだ誰も書いていないだったので書こうと思いました。

www.youtube.com

これまで、各リソースの状態を取得する際に、ぽちぽちポータルを触るもしくはスクリプト作成が必要でしたが、その手間も省けるのではと感じてます。 特に大規模な環境で多数のサブスクリプションを管理している人にとっては便利な機能になるんではないでしょうか。

docs.microsoft.com

Azure Cloud Shell から利用してみる

早速、Azure ポータルから触ってみましょう。[すべてのサービス] -> [Resource Graph] を選択します。

f:id:yoshioblog:20181204222812p:plain

大きくプレビューと書いてあります。"Launch Cloud Shell" から Cloud Shell を起動します。ポータルに書かれているコマンドから有効化しましょう。

az extension add --name resource-graph

f:id:yoshioblog:20181204223203p:plain

まずは、ポータルに載っているコマンドを実行してみます。

az graph query -q "summarize count () by type"

f:id:yoshioblog:20181204223358p:plain

簡単にクエリできますね。そして早い。location ごとのカウントもこの通り。

f:id:yoshioblog:20181204223625p:plain

Location ごとかつ、サブスクリプションごとも別サブスクリプションがないのでわかりづらいですがこの通り。

az graph query -q "summarize count() by location, subscriptionId | order by count_" --output table

f:id:yoshioblog:20181204223957p:plain

Storage Account のプロパティを確認してみる

Resource Graph は、リソース タイプのカウントだけではなく、より細かい単位でクエリをすることが可能です。 例えば、上記の動画では Storage Account の FireWall のセッティングの値が 'Allow' である Storage Account をクエリしています。

where type == 'microsoft.storage/storageaccounts'
| where aliases['Microsoft.Storage/storageAccounts/networkAcls.defaultAction'] == 'Allow' 
| summarize count()

なんかファイル指定だとうまくいかなったけど、直接指定だとうまく行く模様。

f:id:yoshioblog:20181204225843p:plain

サブスクリプション配下にはこれだけ FireWall を設定していない Storage Account があるようです。

クエリを利用してポリシーを設定してみる

先ほど、2 つの Storage Account が FireWall を設定していないところまでわかりました。今度は、このプロパティをもとにポリシーを作ってみましょう。 まずは、Azure Resource Graph から Azure Policy を設定するツールをダウンロードして、その後ポリシーを作成するコマンドを実行します。

GitHub - robinchapas/ConvertToPolicy: Convert Azure resource graph queries into policies.

wget -O SetupGraphToPolicy.sh https://raw.githubusercontent.com/robinchapas/ConvertToPolicy/master/SetupGraphToPolicy.sh
graph2policy -q "where type == 'microsoft.storage/storageaccounts' | where aliases['Microsoft.Storage/storageAccounts/networkAcls.defaultAction'] == 'Allow' | summarize count()" -e "deny" --create mystoragepolicy

f:id:yoshioblog:20181204234950p:plain

おお!ちゃんとカスタムのポリシーが出来上がってますね。Resource Graph を利用することで自分が確認可能なリソース全体に対してプロパティのチェックができそうです。

まとめ

Azure Resource Graph を利用することで、サブスクリプション内のリソースの状況がより簡易に確認できそうです。特に、多数のサブスクリプションを管理する人にとっては、スクリプトの作成の手間も省けて便利なのではないでしょうか。そもそも、Azure Governance とは?というのは違う記事で書こうと思います。

Azure Distributed Data Engineering Toolkit (AZTK) を使って、Azure Batch で Distributed Keras を動かして遊んでみた

こちらの記事は、Qiita に掲載した Microsoft Azure Tech Advent Calendar 2018 の企画に基づき、執筆した 内容となります。(1 日目)

qiita.com

Azure Distributed Data Engineering Toolkit (AZTK) ってご存知ですか? AZTK は、Azure Batch をベースとした、オンデマンドの Spark クラスタを提供する コマンドライン ツールです。AZTK を利用すると、簡単にSpark のクラスタを作成して計算を行うことができます。前から気になっていたのですが、なかなか触る機会が訪れず、今回の Advent Calendar を機に触ってみました。

目次

セットアップ

セットアップの方法や、基本的な使い方は GithubAzure Distributed Data Engineering Toolkit (AZTK) に記載されています。

AZTK は Python CLI アプリケーションとなり、コマンドを利用してクラスタの作成や削除、ジョブの実行やノードへの SSH などを実行します。 まずは、pip コマンドでインストールしてください。

pip install aztk

インストール後、初期化処理を行います。初期化処理を行うとカレント ディレクトリに .aztk というフォルダが作成され、中に yaml ファイルが配置されます。

aztk spark init
$ ls -l
total 56
-rw-r--r--  1 user  staff  2452 12  1 20:29 cluster.yaml
-rw-r--r--  1 user  staff  1553 12  1 16:42 core-site.xml
drwxr-xr-x  3 user  staff   102 12  1 16:44 jars/
-rw-r--r--  1 user  staff  2697 12  1 16:42 job.yaml
-rw-r--r--  1 user  staff  1321 12  1 17:23 secrets.yaml
-rw-r--r--  1 user  staff  2389 12  1 16:42 spark-defaults.conf
-rw-r--r--  1 user  staff  2592 12  1 16:42 spark-env.sh
-rw-r--r--  1 user  staff   702 12  1 16:42 ssh.yaml

そのあと、作成された yaml ファイルの中に、Azure AD アプリケーションの資格情報や、Azure Batch のアカウント、ストレージ アカウントなどを設定する必要がありますが、下記のコマンドを使うとそれらのリソースを作成してくれてなおかつ、yaml 形式で表示してくれます。

wget -q https://raw.githubusercontent.com/Azure/aztk/v0.10.1/account_setup.sh -O account_setup.sh &&
chmod 755 account_setup.sh &&
/bin/bash account_setup.sh
service_principal:
    batch_account_resource_id: /subscriptions/xxxxxxxxxxxxxxxx/resourceGroups/aztk/providers/Microsoft.Batch/batchAccounts/keyomuraaztkbatch
    client_id: yyyyyyyyyyyyyyyyyyyy
    credential: zzzzzzzzzzzzzzzzzzzzz
    storage_account_resource_id: /subscriptions/xxxxxxxxxxxxxxxx/resourceGroups/aztk/providers/Microsoft.Storage/storageAccounts/keyomuraaztkstorage
    tenant_id: wwwwwwwwwwwwwwwwwww

また、ノードに対して SSH で接続する場合は、この設定を .aztk/secrets.yaml に記載します。

ssh_pub_key: ~/.ssh/id_rsa.pub
ssh_priv_key: ~/.ssh/id_rsa

クラスタの作成

インストールもできたので、早速クラスタを作ってみましょう。

aztk spark cluster create --id my_cluster --vm-size standard_a2 --size 3

f:id:yoshioblog:20181201214804p:plain

見た目がいいです。クラスタの状態を見るには aztk spark cluster get コマンドを利用します。

aztk spark cluster get --id spark

f:id:yoshioblog:20181201230731p:plain

SSH 設定済みであれば、aztk spark cluster ssh --id spark でノードに接続することも可能です。

オプションに --host がついていると、ノード VM 自体への SSH、付いていないと Docker コンテナへの SSH と簡単に振り分けられます。

Batch Explorer で見ると、ノード上で Docker コンテナが動いていることがわかります。

f:id:yoshioblog:20181201232030p:plain

Batch Explorer って何?という方はこちらへ。

keyomura.hatenablog.com

ジョブの実行

クラスタの作成が終わり、ノードへの接続もできるようになったので実際のジョブを実行してみましょう。 今回は下記のブログを参考に Distributed-keras を利用して、Spark クラスタ上で MNIST の手書き文字識別を試してみました。

 aztk spark cluster submit --id spark --name mnist ./mnist.py

参考にしたブログはこちら

Distributed Deep Learning on AZTK and HDInsight Spark Clusters | Machine Learning Blog

ちなみに、Distributed-keras は、Spark 上で動作する Deep Learningフレームワークで、Jeffrey Dean 氏らが発表した Large Scale Distributed Deep Networks が基になっています。

ブログのサンプルを参考に、必要なパラメータを自分用に変換して動かします。SSH で接続していれば、localhost:8080 から実際の稼働状況がわかるそうです。 試しに接続してみましょう。

f:id:yoshioblog:20181201232818p:plain

おおー、動いている様子がわかりますね。WORKER の監視や、JOB がどれくらい続いているのかも確認できます。 Batch Explorer や、Azure Monitor のメトリックと組み合わせることで定期的な監視ができそうです。

まとめ

AZTK という、Spark クラスタを Azure Batch 上で作成し実行するためのツールを使って遊んでみました。AZTK のおかげで簡単にクラスタの展開や、SSH 、ジョブの実行ができ、Batch 特有の Job や、Pool などの概念にあまり振り回されずに済むので便利だなと感じました。 Batch AI は現在パブリック プレビューとなり、運用環境での利用はちょっと、、という人は AZTK を検討してみるのはいかがでしょうか。

Batch Explorer という便利ツールをもっと使って欲しい

Azure Batch では、Azure ポータル上で、Batch アカウントの操作をすることができますが、より簡単に Batch アカウントを操作するためにクライアント ツールが提供されています。それが Batch Explorer (旧 Batch Labs) です。

昔は、同じ Batch Explorer という名前のクライアント アプリケーションがあり、このツールは差別化のために Batch Labs と呼ばれていたのですが、新しく Batch Explorer という名前に変わりました。

この Batch Explorer で出来ることは、ポータルからも同じように出来ますが、Batch Explorer を使うともっと簡単に Batch Account の使用状況の確認や操作ができます。

実はあんまり知られていないツールなのか、記事も少ないので紹介していこうと思います。

目次

Batch Explorer をインストールする

Batch Explorerこのリンクからダウンロードすることができます。 インストールして実行すると、下記のような画面になります。現在のタスクの実行状況や各ノードの状態などがわかるようになってます。

f:id:yoshioblog:20181028180316p:plain

資格情報も表示できる

Azure Batch の実行に必要な資格情報もこのアプリケーションで出すことができます。

f:id:yoshioblog:20181028184734p:plain

更にコードのスニペットも表示することができます。

f:id:yoshioblog:20181028184959p:plain

ジョブを実行してみる

こちらのジョブを実行してみましょう。各タスクの内容は、ファイルの内容を出力するだけの簡単なものです。

docs.microsoft.com

実行して、しばらくたつとこんな感じでジョブ内の各タスクの実行結果が、表示されます。

f:id:yoshioblog:20181028191820p:plain

タスクを実行すると、更にノード内に保存されている標準出力のファイルにアクセスすることができます。

f:id:yoshioblog:20181028192002p:plain

ノードへの接続も簡単

ノードへの接続もポータルから指定するよりも簡単にできるようになっています。

f:id:yoshioblog:20181028192435p:plain

まとめ

Batch Explorerを使うと、UI 上でいちいちページを移動する必要なくAzure Batch のアカウントの操作を行うことができます。 Azure Batch を使うのであれば、便利なことこの上ないので一度使ってみてはいかがでしょうか。

Batch ExplorerGithub レポジトリはこちらになります。

GitHub - Azure/BatchExplorer: A client tool to help create, debug and monitor Azure Batch Applications

新しい App Service 診断を触ってみた

Microsoft Ignite 2018 とともに発表された、新しい App Service Diagnostics ですが、ガラリと UI が変わりました。 以前こちらの記事で紹介したのですが、昔の UI なので改めてみていこうと思います。

keyomura.hatenablog.com

App Service Team のブログ記事はこちら

blogs.msdn.microsoft.com

目次

UI が変わった

まず、UI が大きく変わりました。昔の UI はこんな感じですが、、

f:id:yoshioblog:20180828235631p:plain

新しい UI はこんな感じになってます。おしゃれですね。

f:id:yoshioblog:20180930221536p:plain

カテゴリ別に分かれてる

新しい UI はカテゴリが分かれています。

f:id:yoshioblog:20180930225517p:plain

まずカテゴリを選んだ後 Web App Restarted や、Web App Downなど目的のツールを選ぶようです。

新しい機能が増えてる

以前からあったのかもしれないですが、SSL や、カスタムドメインに関しての機能も追加されていました。証明書の操作もここから追うことができるようです。

f:id:yoshioblog:20180930223425p:plain

直接検索できる

トラブルシューティングのツールを Search App Service Diagnostics から直接検索できるようになりました。ある程度わかっている人であれば UI をぽちぽちするより速いですね。

f:id:yoshioblog:20180930223748p:plain

まとめ

新しくなった UI で、簡単なトラブルであれば自分ですぐに調べて解決できそうだなと感じました。 Best Practice もあるようなので、自分の Web App の状態を見てみるのも面白そうです。

Azure Web Apps の Bring your own Storage を試してみた

Microsoft Ignite 2018 とともに発表された新機能の Bring your own Storage to App Service 、その名の通り Web Apps on Linux や、Web App for Containers に Blob Storage や File Storage をマウントすることができます。

FTP や Git から Web App にファイルをアップロードすることはできますが、大きい画像や動画ファイルを git add するのもレポジトリが肥大化して嫌ですし、ファイルを確認するために FTP や Kudu でいちいちアクセスするのも面倒です。この機能のおかげで大きいファイルは Storage に置いておくだけで済むので便利そうですね。

ちなみに、Azure Web Apps (Linux) は、Azure 側で提供しているランタイム スタックを使用して Linux ベースのアプリケーションのホストが可能なサービスで、Web App for Containers は、自分で作成した Docker コンテナを Web Apps の環境でホストが可能なサービスです。

細かい違いに関してはこちらに載ってます。

azure.microsoft.com

今回は、この機能を試したので紹介していこうと思います。

元のブログ記事はこちら

blogs.msdn.microsoft.com

目次

Web Apps on Linux を作成する

まずは、Web App (Linux) を作成しましょう。Azure ポータルからWeb Apps (Linux) を作成するときは下記のように選択します。 今回はランタイム スタックはなんでもいいと思うので好きなやつを選びましょう。

f:id:yoshioblog:20180926224714p:plain

Azure Cloud Shell からコマンドを実行する

Web App の作成が終わったら、Azure Cloud Shell から早速コマンドを試します。 右上から選択してコンソール画面を開きましょう。

f:id:yoshioblog:20180926225233p:plain

az webapp config storage-account コマンドが実行できることを確認します。できそうですね。

f:id:yoshioblog:20180926225538p:plain

マウントするには、az webapp config storage-account add を利用します。 今回は、Blob Storage をマウントしました。

az webapp config storage-account add 

-g Web App のリソースグループ名
-n Web App 名
-i マッピングの設定名
-t AzureBlob
--account-name ストレージ アカウント名
--share-name ストレージ コンテナ名
-k ストレージ アカウントのキー
--mount-path マウントするパス

実際に実行するとこんな感じ

f:id:yoshioblog:20180926230659p:plain

az webapp config storage-account add -h で各コマンドのより細かい情報が出てきます。オプションがわからなくなったらこれを使いましょう。

f:id:yoshioblog:20180926230905p:plain

SSH でログインして確認する

マウントに成功したようなので、ポータルから SSH をして確認します。事前にファイルをあげるのを忘れずに。

f:id:yoshioblog:20180926233225p:plain

SSH をして確認した結果がこちらです。しっかりマウントできてますね。いらなくなったら、az webapp config storage-account delete で削除しましょう。

f:id:yoshioblog:20180926231217p:plain

まとめ

Bring your own Storage の機能を使うことで、これまで Web Apps にアップロードしていたファイルを減らすことができそう。

特に動画ファイルや画像ファイルの参照が多いアプリに関しては、この機能を使うようにした方が容量も多いし手間も省けそうですね。

現在はプレビューの段階で Web Apps on Linux や、Web App for Containers でしか利用できませんが、そのうち Windows コンテナや普通の Web App (Windows) で使えるようになれば、さらに面白くなりそうです。

Azure Web Apps の再起動を調べる

Azure Web Apps を利用していると、HTTP 5xx エラーが発生していた、もしくはある時から HTTP 5xx エラーが発生し始めたなんてことがあるかと思います。 その場合、よく疑われるのがメンテナンスによるアプリの再起動などです。今回は Web Apps の再起動の確認方法を紹介していきます。

UI が変わったので、その紹介をこちらでしています。

keyomura.hatenablog.com

目次

再起動の確認方法

Azure ポータルの [問題の診断と解決] から、"Web App Restarted" を選択することで、そのアプリが再起動していたか確認することができます。


f:id:yoshioblog:20180819105859p:plain

再起動の理由も

選択すると、Web App の再起動があった時点で棒グラフが出てきます。ここでは、アプリケーション設定を変更したから再起動したと書いてあります。


f:id:yoshioblog:20180819110037p:plain

メンテナンスがあったかどうかも書かれていた気がするので、ちょっとした調査であればこれだけで済みそうです。

ちなみに、メンテナンス Web App や Function App のメンテナンスの仕組みに関してはブログで公開されています。

blogs.msdn.microsoft.com

Auto Heal に関して

他にも、グラフの項目には、Auto Heal Events というものが表示されています。

Auto Heal は HTTP 500 エラーの数やリクエスト数など、あらかじめ設定したメトリックが閾値を超えた場合に自動でアプリを再起動する機能です。便利ですね。

Web.config から設定する方法や、Kudu サイトから設定する方法があります。

Web.config による設定方法

Web.config による設定方法はこちらに書いてあります。

Auto-Healing Windows Azure Web Sites | ブログ | Microsoft Azure

Kudu サイトからの設定方法

Kudu サイトからの設定方法はこちらになります。

Auto Heal your Azure Web App – Microsoft Azure App Service

Proactive Auto Heal について

Auto Heal は自分で設定しない限り有効にはなりませんが、Proactive Auto Heal に関しては既定で有効になっています。

Proactive Auto Heal とは、メモリが枯渇しそうな場合や、レスポンスが極端に遅くなっている場合に Web App を再起動する機能で、あらかじめ有効になっています。

blogs.msdn.microsoft.com

具体的には、下記の条件で再起動が発生します。

  • Percent Memory Rule: Web App のプロセスのメモリ使用率 90 % 以上の状態が 30 秒以上続いた時
  • Percent Request Rule: 処理に 200 秒以上かかったリクエストが80 % 以上になった時 (2 分間で 5 リクエスト以上来ている Web App が対象)

WEBSITE_PROACTIVE_AUTOHEAL_ENABLED を False にすることで無効にできます。

まとめ

ポータル上のメトリックなどで HTTP 5xx を確認した際は、まず再起動があったかを確認し、再起動ではなかった場合は、アプリケーションのログを見ていく必要があると思います。

アプリに依存しますが、メンテナンスによる再起動後、エラーがで続けてしまうアプリにおいて、とりあえず問題を一時的に回避する場合は、HTTP 5xx ステータスでAuto Heal を設定するのがオススメです。

アプリケーション ログの確認方法はこちらで紹介しているので、参考になれば幸いです。

keyomura.hatenablog.com

Web Apps (Windows) でアプリケーションのログを確認する

Web Apps (Windows) でアプリケーションがうまく動かなかった時によく見るのはアプリケーションのログですが、今回はそれぞれの言語に関してどこにログがあるのか紹介していきます。 Web Apps on Linux のログの確認方法に関しては、以前の記事で紹介していますのでこちらを参照してください。

keyomura.hatenablog.com

目次

アプリケーション ログの設定

Web Apps では、[診断ログ] というブレードからログの設定を行うことができます。

f:id:yoshioblog:20180820072018p:plain

ASP.NET アプリケーションの場合、System.Diagnostics.Trace クラスを使用することで記録することができます。

一方、ASP.NET 以外のアプリケーション (Node.js、JavaPHPPython など) の場合それぞれ違う形でログが出力されます。 ※ カスタムのランタイムを利用している場合は、ログの出力は自分で設定してください。

Node.js、JavaPHPPython などのログを Blob へ転送したい場合、[診断ログ] からは設定することができないので、自分で実装する必要があります。

アプリケーションのログ以外の Web サーバー ログの設定などに関してはこちらのドキュメントに詳しく書かれています。

docs.microsoft.com

アプリケーション ログの場所をそれぞれ確認する

ログを確認するためには、Kudu サイトへアクセスしてコンソールから目的のファイルがある場所まで移動します。

Kudu サイトは、Web Apps の管理サイト的な位置付けのサイトとなります。Azure ポータルで、Web Apps を選択したあと [高度なツール] から移動可能です。

画面上部の [Debug console] から CMD へ移動するとこのような画面になります。LogFiles フォルダ以下に各言語のログが出力されます。

f:id:yoshioblog:20180819094912p:plain

PHP

  • D:\home\LogFiles\php_errors.log

Java (Tomcat)

  • D:\home\LogFiles\Application\catalina.InstanceID.yyyy-mm-dd.log

  • D:\home\LogFiles\Application\host-manager.InstanceID.yyyy-mm-dd.log

  • D:\home\LogFiles\Application\ localhost.InstanceID.yyyy-mm-dd.log

  • D:\home\LogFiles\Application\ manager.InstanceID.yyyy-mm-dd.log

Node.js

  • D:\home\LogFiles\Application\logging-errors.txt

Python

  • Web.config に自分で設定します。

Azure App Service Web Apps による Python の構成 | Microsoft Docs

.Net Core

  • Web.config に自分で設定します。

ASP.NET Core モジュール構成リファレンス | Microsoft Docs

※ Instance ID とは、Web Application が動作するインスタンス (仮想 VM) の ID となります。Kudu の [Envrionment] から確認可能です。例えば 2 台にスケール アウトしている場合は、それぞれ別のインスタンス ID が割り当てられます。

Web Apps のインスタンス構成に関してはこちらで詳しく紹介しています。

keyomura.hatenablog.com

Application Insights を使う

Application Insights を使うと、メトリックも含めより詳細に Web Apps の状態を確認することができますが、利用するためにはあらかじめ実装に組み込んでおく必要があります

docs.microsoft.com

なお、ASP.NET の場合は、後からでも設定することが可能です。

docs.microsoft.com

まとめ

アプリケーションでエラーが出た場合、その詳細はアプリケーション内部のログに書かれていることがほとんどです。 大規模なアプリケーションの場合は、Application Insights を利用した方がより詳細にメトリックを確認することができると思います。