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

ターゲットは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-61efafece43d3599114947/]

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

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

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

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

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

ストレージアカウント間のデータコピーはv8でも可能でしたが、v10ではコピー操作に「Put Block from URL」APIを使用することで操作の高速化が図られています。
このAPIは、ストレージアカウント間のデータコピーをクラウド上で完結させることで、クライアントのネットワーク帯域に依存せず高速にデータコピーができるようにしたもののようです。
ストレージアカウント間のデータコピーは「copy (cp)」コマンドを使用し、以下のコマンドで実行します。
[crayon-61efafece43df124349244/]
合計約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-61efafece43e2291110763/]

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

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

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

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

完了すると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-61efafece4ce9674106805/]

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

[crayon-61efafece4cef595813102/]

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

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

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

[crayon-61efafece4cf2804588156/]

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

[crayon-61efafece4cf4937873580/]

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

[crayon-61efafece4cf5791633881/]

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

[crayon-61efafece4cf8361562761/]

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

[crayon-61efafece4cfa898709849/]

以下の実行結果が表示され既定のブラウザでログイン画面へ遷移されれば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に最適化された機能が追加され、使いやすくなっていくことに期待したいです。


【Cognitive Service】触って覚えるAnomaly Detector API

はじめに

Anomaly Detector API の概要と、電力の「過去実績データ」を使った異常判定のチュートリアル紹介です。
検証データには、中部電力ホームページの「電力需給状況のお知らせ」にある「過去実績データ」を使います。

  • Anomaly Detector API に興味を持っている
  • Cognitive Service を勉強中である
  • 気軽に機械学習や、異常検知を試してみたい

上記のような方向けの記事です。
ご安心ください、機械学習の前提知識はいりません。

Anomaly Detector API の特徴

「異常検知」に特化したAPIで、時系列数値データに含まれる
異常な挙動の検出を、簡単なREST APIで利用できます。

  • 時系列データを監視し、その中の異常を検出
  • 機械学習の知識はなくてOK
  • アルゴリズムは、産業、シナリオ、データ量に関係なく、データに最適なモデルが自動的に特定され、適用されます。

各仕様について

APIメソッド

Anomaly Detector APIでは、以下2つのメソッドが使用できます。

  • Detect anomaly status of the latest point in time series.
  • Find anomalies for the entire series in batch.

違いは、
最終データポイントの判定結果を返すか
すべてのデータポイントの判定結果を返すか
というもので、リクエスト形式は同じものとなっています。

実利用においては、
「Find anomalies for the entire series in batch.」→パラメータ調整
「Detect anomaly status of the latest point in time series.」→リアルタイムでの異常検知
といった方法で使用するようです。

リクエスト形式

APIのリクエスト本文は、JSON形式でデータの粒度を示す「granularity」と時系列データ「series」が含まれる必要があります。

「granularity」

時系列の間隔を指定するパラメータ
「daily」、「minutely」、「hourly」、「weekly」、「monthly」、「yearly」の6パターンが指定できます。

「series」

「timestamp」と「value」をペアにした、オブジェクトの配列を指定。
データ数は最小で12、最大で8640とし、時系列でソートされている必要があります。
また、「timestamp」はISO 8601のUTCタイムスタンプ、
「value」は数値型とし、1つでも型の異なる値が入るとリクエストエラーとなります。

その他パラメータ

「sensitivity」、「period」、「maxAnomalyRatio」、「customInterval」が使用できるようです。
四半期ごとの時系列データを使用する場合は、以下のようなリクエスト本文を使ってみてください。

[crayon-61efafece559f614302694/]

データ欠損

時系列データセットでは、データポイントの欠落が生じることがあります。
データ欠損は期間全体の10%まで許容され
10%を超える欠損が含まれる場合は、リクエストエラーが発生します。

欠損は特に細分化されたデータ (数分ごとなどの短いサンプリング期間に、サンプリングされたデータなど) でよく見られます。

  • 前の期間のデータポイントとの置き換え
  • 線状補間、または移動平均など

その特徴に基づいて、データの不足部分を埋めることを検討します。

レスポンス

Anomaly Detector APIの成功時のレスポンスは、以下のようなJSON形式となります。

「expectedValues」

学習モデルから得られる予測値で、異常判定のマージン「upperMargins」、「lowerMargins」と組み合わせて閾値を求めることができます。
「isAnomaly」、「isNegativeAnomaly」、「isPositiveAnomaly」はそれぞれ異常判定の真偽値。
異常判定閾値から外れた場合は「true」となりますが、「isNegativeAnomaly」は下限閾値、「isPositiveAnomaly」は上限閾値から外れた場合のみの判定となっています。

「period」

データの周期性を示す値で、特定のパターンが何データポイントごとに現れるかの判定結果となります。

利用料金

Anomaly Detector では、多変量の異常検出がサポートされています。
この多変量機能は個別の API として提供され、プレビューでは無料で利用できます。

EAST ASIA リージョン価格
image.png

チュートリアルの開始

今回の検証には、電力需要データのうちの2018年4月~5月を使用します。
2018年データを可視化すると、電力データは気象条件に大きく影響を受け、夏季、冬季は特に冷暖房の使用等に伴って電力需要が増大することがわかります。
image.png

電力需要は1日、1週間単位で周期的なパターンを示しています。
人や業務機器が稼働する平日日中帯は電力需要が大きく、土日等の休日は相対的に電力需要が小さくなります。
image.png

4月~5月は冷暖房の使用が少なく電力需要は比較的安定しますが、期間にゴールデンウィークがあり、前後の週と比較して電力需要の落ち込みが発生します。
もちろんこれを「異常」とは言えませんが、「通常とは異なる」という点から異常検知のサンプルとして使ってみます。

image.png

1.Anomaly Detectorの作成

Azureポータルの「リソースの作成」から「Anomaly Detector」を選択して作成を開始します
image.png
必要な内容を入力して、作成を行います。
image.png
作成が完了したらAPIキーを取得します。
リソースに移動し、メニューの「キー」からAPIキーをコピーして控えておきます。
image.png

2.スクリプトの作成

今回は、Python で Anomaly Detector API にリクエストしています。
Anomaly Detector API は、 Face API といった Cognitive Services の API とリクエスト方法が変わらないため、簡単に利用できます。

[crayon-61efafece55a9976354350/]

3.実行結果を見る

スクリプトを実行して得られた結果を可視化しましょう。
ゴールデンウィーク期間の、平日の電力需要を「異常」として検知できていました。
image.png

レスポンスの「period」を見ると168 (= 7×24)となっており、電力需要のパターンが1週間単位で現れることを判定できていました。

[crayon-61efafece55af942295200/]

異常判定の調整

リクエスト本文に「sensitivity」オプションを付加すると、異常検知の感度調整をすることができます。
感度が高すぎると判定マージンが狭くなり、誤検知も増えるため、「sensitivity」で本当の異常値のみを検知するよう調整します。

とはいえ、今回のデータは「異常」があるわけではないので「sensitivity」の調整による閾値、異常判定の変化を確認します。
スクリプトでは、リクエスト本文の設定を以下のように変更します。

[crayon-61efafece55b2776524072/]

「sensitivity」を99、95、90、85と下げていくと、判定マージンが広がり、異常と判定されるポイントが減少していくことがわかります。
「sensitivity」が99の場合は、設定しない場合と結果が同じであり、「sensitivity」のデフォルト値は99となっているようです。
image.png

まとめ

Anomaly Detector APIは、非常に簡単なリクエストでデータの時系列パターンを判定し、異常を検知できることがわかりました。
決まったパターンを持つ時系列データに対しては、モデル作成といった面倒な作業無しに、異常検知の仕組みを導入できそうです。
実行のたびに過去データを送信する必要があるなど、やや使い勝手の悪い面もあります。
Face APIのように、カスタマイズができるように変更が加えられ、
より使いやすいAPIになっていくことに期待したいところです。


【会議でも活用】Visual Studio Code を便利に使う

はじめに

よく開発環境として Visual Studio Code (以下VSCode) を利用しています。
メモ書き等は Markdown で記述する場合が多く、 VSCode 上で記載したいと思いました。

※Markdown エディターは Boostnote 等が有名ですよね。

そんな矢先 VSNotes なる拡張機能があることを知り導入してみました。

  • 導入方法と OneDrive などのクラウド環境との、同期方法を紹介していきます
  • 非エンジニアの方にもおすすめです
  • メモを見やすく整理したい方にもおすすめ

どんな感じで管理するの?

タグとディレクトリでファイルを管理することが出来ます。
プレビューもコマンドを使用してすばやく行うことが可能です。
多機能ではないですがメモ書きには充分と思っています。
image.png

実行環境

Windows 10
Visual Studio Code – 1.33.1
VSNotes – 0.7.0

インストールと環境整備

拡張機能の検索窓から「VSNotes」を検索しインストールを実行
image.png
インストールが完了するとタブにアイコンが表示されます
image.png
F1キーを押し VSNotes の Run setup コマンドを実行する
image.png
右下にポップアップウィンドウが出現するので「Start」をクリックする
image.png
.mdファイルを保存するディレクトリを指定する ( OneDrive等クラウドだと幸せになれる )
image.png
あとは指定したディレクトリに.mdファイルを入れて運用していくことになります

使い方

Markdownファイルの生成
ファイル生成パターン1 : コマンドから新規のファイルを生成する
image.png
ファイル生成パターン2 : 対象ディレクトリにmdファイルを入れる

フォルダ構造で入れても大丈夫

更新ボタンを押すと表示されます
image.png
プレビュー機能
Markdown ファイルのプレビュー : F1からMarkdown : Open Previewを選択
image.png
プレビューウィンドウが表示される

image.png
他にも機能はありますが使う分にはこれで充分かと思ってます。

まとめ

VSCode で Markdown のメモを作成するのに、オススメな拡張機能「VSNotes」の紹介記事でした。
複数のPCやMacも併用して、業務を行う自分としては非常に助かっているツールになります。
VSCode ひとつでコードだけでなく、日常業務のツールとして使えるので
何個もツールウィンドウを開いたり、動作が重くなったりが軽減されるのも良い点です!


便利に使える負荷分散サービス!Azure Application Gateway入門【初心者向け】

はじめに

今回はAzure Application Gateway のご紹介です。
HTTP/HTTPSのトラフィックを柔軟に負荷分散することができます。

image.png

Azure Application Gatewayの概要

アプリケーション層 (OSIネットワーク参照モデルの第7層)で動作する負荷分散機能です。
Azure Load Balancer でも負荷分散はできますが、Application Gatewayではより柔軟に、パスベースの振り分け等の機能も提供されます。

Application Gatewayの機能

Application Gatewayを作成すると、エンドポイントがAzure Load Balancerによって提供されます。
Azure Load BalancerはトラフィックをApplication Gatewayインスタンスに分散し、インスタンス上で各種の処理が行われます。

image.png

引用元

Application GatewayはSmall、Medium、Largeの3つのサイズが選べます。
上のサイズになるほど以下の表のようにスループットが向上します。

Application Gatewayの詳細なサービス範囲

Application Gatewayは、サブスクリプションごとに最大50個まで作成できます。
各Application Gatewayには最大10個のインスタンス(L7の仮想負荷分散装置)を割り当てることができます。
また、Application Gatewayには20個のHTTPリスナーを作成できます。

image.png

引用元

トラフィックの分散

Application Gatewayへのトラフィックはラウンドロビン方式で、バックエンドのサーバに分散されます。

SSL終端とオフロード

Application GatewayがSSL終端となってHTTPSとHTTPへの変換を行います。
復号・暗号化をApplication Gateway上で行うことでバックエンドのCPU負荷を削減します。

エンド・ツー・エンドSSL

  • HTTPS通信をHTTPに変換、URLパスベースのルーティング、CookieベースのセッションアフィニティなどのApplication Gateway上での処理を行います。
  • 再びHTTPからHTTPSに変換して、バックエンドにトラフィックを流します。
  • Application Gatewayとバックエンド間のエンド・ツー・エンドのHTTPS通信を維持しながら、各種機能も利用することが可能になります。

Cookieベースのセッションアフィニティ

Cookieを利用して、ユーザセッションを特定のバックエンドに送ることができます。
ユーザのセッション情報をバックエンドで保存したり管理したりする場合に役に立ちます。

URLパスベースのルーティング

事前に設定したURLパスベースのルールに則って、特定のバックエンドにトラフィックを振り分けることができます。
例えば、
http://contoso.com/video* に対する要求はVideoServerPoolに
http://contoso.com/images* に対する要求は ImageServerPool にそれぞれルーティングできます。

image.png

複数サイトのホスト

最大で20のWebサイトを1つのApplication Gatewayで処理、バックエンドに転送することができます。
例えば、1つのApplication Gatewayを使って、www.hogehoge.com と www.foobar.com のような2つのドメインへのトラフィックをコントロールできます。

リダイレクト

Application Gateway上でリダイレクトも可能です。
HTTPからHTTPSへのリダイレクト、パスに基づくリダイレクト、外部サイトへのリダイレクトが可能です。
サーバを立てなくてもいろんなパターンのリダイレクトを行えるのは便利です。

Webアプリケーションファイアウォール(WAF)

  • Application Gatewayで提供され、脆弱性や攻撃からWebアプリケーションを保護できます。
  • SQLインジェクション、クロス・サイト・スクリプティングなどからの保護が提供
  • WAFには、検出モードと防止モードがある
  • 検出モードの場合は、許可されない通信が発生すると、ログに記録されます。
  • 防止モードは検知と同時にさらに通信がブロックされ、アクセスしたユーザには「403 不正アクセス」が表示されセッションが終了します。

監視

Application Gatewayにつながるバックエンドの死活監視を行い、異常なインスタンスへの振り分けを停止することもできます。
「既定の正常性プローブ」はルートパスに対するHTTP応答確認により死活を監視できます。
「カスタムの正常性プローブ」では、さらに柔軟にURLパスや監視のパラメータを個別に設定できます。

その他

  • Application Gateway は、インターネット接続ゲートウェイ、または内部的にのみ使用されるゲートウェイのいずれかとして構成できる
  • Application Gatewayの属するサブネット上にネットワークセキュリティグループ(NSG)がある場合、65503~65534のポート範囲をインバウンドトラフィック用に開いておく必要がある。
  • WebSocket通信のサポートがある
  • WAFはサイズMediumとLargeで利用可能。

料金

Application Gatewayを構成して利用した時間と、Application Gatewayによって処理されたデータ量(GB単位)に対して課金されます。

Azureデータセンター外へ出ていくデータの転送量ももちろん課金されます。

最後に

このサービスを利用することで、ネットワーク機器、HTTPサーバのレイヤなど、複数の機器、ソフトにまたがって行っていた設定を、
Application Gateway上で一括して管理することができ、猥雑な作業を短縮できるので開発に注力できるようになります。

スループットレベルやインスタンス数を自分である程度コントロールできるようになります。
事前に想定した負荷に備えることができるので、コストの想定やトラブルを最小限に抑えられるようになりますので、活用していきたいですね!