Cloud Solution Architect チームブログ https://docs.microsoft.com/archive/blogs/azure-sa-members/feed.xml 日本マイクロソフトに所属するCloud Solution Architect チームのブログです Wed, 17 Apr 2019 03:27:22 GMT en-US hourly 1 Azure 管理ポータルの IP フィルタリング https://docs.microsoft.com/archive/blogs/azure-sa-members/azureportal-ipfiltering Mon, 05 Jun 2017 17:34:42 GMT https://blogs.technet.microsoft.com/azure-sa-members/?p=1685 1) はじめに 企業ユーザーの場合、セキュリティの考慮のため、Azure 管理ポータルのアクセス制御の考慮は必須です。Azure の各リソースは、RBAC（Role Based Access Control）での権限制御が可能なため、権限のないユーザーは、リソースがそもそも参照できないようにすることや、各リソース毎に設定されているロールの従って、例えば、仮想マシンのバックアップの作業のみを行うことができるように構成が可能です。通常はこの RBAC の機能で各リソースのアクセス制御を行うことができます。

2) Azure サブスクリプションと Azure Active Directory

ですが、以前から、どの場所でも Azure 管理ポータルが利用できる利便性ではなく、管理の観点から、社内等、特定の IP アドレスからしかアクセスさせたくないという要望がありました。もちろん、Azure 管理ポータル自身は、インターネット アクセス必須の機能ですから、全て制限することはできませんが、契約しているサブスクリプションに関連付けられている Azure Active Directory（以下、Azure AD）の認証を制限することができれば、権限を与えられている Azure AD ユーザーの利用を制限することは可能です。 少しわかり難いので、Azure AD と Azure サブスクリプションへの関連付けについては以下を参照して下さい。 Azure サブスクリプションを Azure Active Directory に関連付ける方法

3) IP フィルタリングの方法

Azure AD の認証で IP フィルタリングする場合、これまでは、Azure AD がオンプレミスの Active Directory と Active Directory Federation Service（以下、ADFS）で連携している環境であれば、ADFS のクレームルールで IP フィルタリングを行うことができました。ですが、Azure AD の条件付きアクセスの機能が Azure 管理ポータルもサポートしたため、ADFS 等とは関係なく、IP フィルタリングすることができます。 以下に設定手順が記載されていますので、参考にして下さい。なお、現時点（2017年6月5日）では、プレビュー機能のため、一部機能（例：”名前付きの場所” 等）はまだ動作しないので注意して下さい。 ※設定を誤るとアクセスできなくなるので、十分に注意してテストして下さい。 ※Azure AD の条件付きアクセスは、Azure Active Directory Premium の機能です。ポリシーが適用されたアプリケーションへアクセスするユーザーは、Azure AD Premium のライセンスが必要になります。
Azure Active Directory の条件付きアクセス - プレビュー 以下の設定例では、ポリシーを割り当てられたユーザーは、特定の IP アドレスからしか Azure 管理ポータルにサインインできないようになります。なお、ポリシー設定は、Azure 管理ポータルの、[Azure Active Directory]-[エンタープライズ アプリケーション]-[条件付きアクセス]-[ポリシー] から新しいポリシーを追加して設定しています。 ■割り当て ○ユーザーとグループ 任意のユーザー ※設定を誤るとアクセスできなくなるので、最初は1名でテストすることをお勧めします。
○クラウド アプリ Microsoft Azure Management ○条件 場所：構成=”はい” 対象外：”すべての信頼できる IP” をチェック すべての信頼できる場所の構成で、IP アドレスのレンジを設定 ■アクセス制御 ○許可 アクセスのブロックを選択 ■ポリシーに有効化 オンに設定 上記設定後、すべての信頼できる場所の構成で設定した IP アドレス以外からアクセスすると、以下のエラーでサインインすることはできません。

4) 今後について

今後、”名前付きの場所” がサポートされることで、複数のポリシーで別々の IP アドレスのレンジを設定することができるようになり、よりきめ細かくアクセス制御ができるようになります。]]> Azure App Service のオンプレミス接続 https://docs.microsoft.com/archive/blogs/azure-sa-members/azure-app-service-connect-onpremise Mon, 24 Apr 2017 12:42:52 GMT https://blogs.technet.microsoft.com/azure-sa-members/?p=1565 1) 接続の選択肢 Azure App Service からオンプレミスのシステムと連携するには、以下の3つの方法のいずれかを利用します。 ※どの方法も Azure App Service → オンプレミス の接続で、オンプレミス → Azure App Service ではない点は注意して下さい。

① ハイブリッド接続

オンプレミス側の Windows 環境に、”ハイブリッド接続マネージャ” と呼ばれるエージェントをセットアップし、このエージェントを介して接続します。VPN 等のネットワーク設定が不要で容易に環境構築ができ、ファイアウォールの中にあるサーバーに対しても接続が可能です。接続先が複数（200まで可能）のオンプレミス環境になる場合等に便利です。 ※現段階では、利用前にクラシック ポータルにて、BizTalk サービスのハイブリッド接続を作成しておく必要があります。 appfig1

② VNET 統合

仮想ネットワークを介して VPN によりオンプレミスに接続します。これを利用するには、Azure App Service から “VNET統合” のポイント対サイト接続（SSL VPN）機能で仮想ネットワークに接続し、その仮想ネットワークのサイト対サイト接続機能を利用して、オンプレミスのシステムと接続することができます。また、オンプレミス側で Azure Web Apps へのルーティング設定をする必要があります。なお、ExpressRouteを利用することはできません。 ※VNET 統合には、Standard プラン以上が必要です appfig2

③ App Service Environment

①、② とは異なり、Azure App Service 自身を仮想ネットワーク内に配置し、仮想マシン同様、VPN もしくは ExpressRoute によりオンプレミスと接続することができます。こちらは、専用環境となるため、セキュリティ上、分離した環境が必要な場合や、高いスケーラビリティが要求される場合に向いています。 ※App Service Environment には、Premium プランが必要です appfig3 どの方式を選択するかは要件に依存しますが、オンプレミスのみではなく仮想ネットワークに接続するという意味でも利用される ② VNET 統合でのオンプレミス接続手順を解説します。なお、VPN デバイスのところはデバイス毎に設定方法が異なるため、ここでは、実際のデバイスを利用するのではなく、以下のように仮想ネットワークを別途作成し、その仮想ネットワーク内にあるサーバーにアクセスできる環境を Azure ポータルで構築する手順を解説します。 appfig4

2) Azure App Service VNET 統合での仮想ネットワーク接続

Web Apps から VNET 統合機能を利用して、仮想ネットワークに接続します。

2.1) 仮想ネットワーク作成

VNET 統合で接続する仮想ネットワークを以下のように作成します。各指定項目は必要に応じて変更して問題ありません。 【仮想ネットワーク1】
  • 名前：AzureVnet1
  • アドレス空間：10.0.0.0/24
  • サブネット名：subnet1
  • ゲートウェイ サブネット：10.0.0.240/28 ※仮想ネットワーク後にサブネット メニューから作成します
  • サブネット アドレス範囲：10.0.0.0/26
仮想ネットワーク作成後、以下のように仮想ネットワーク ゲートウェイを作成します。 【仮想ネットワーク ゲートウェイ】
  • 名前：AzureVnet1GW
  • ゲートウェイの種類：VPN
  • VPN の種類：ルートベース
  • SKU：Standard
  • 仮想ネットワーク：AzureVnet1
  • パブリック IP アドレス：新規作成
上記作成後、AzureVnet1GW のメニューから “ポイント対サイトの構成” を選択し、以下の設定を行います。 【AzureVnet1GW】
  • アドレスプール：172.16.0.0/24

2.2) Azure App Service の VNET 統合

Web Apps を以下のように作成します。 【Web App】
  • アプリ名：fumioswebvpn
  • App Service プラン：Standard: 1S ※VPN 統合には Standard 以上が必要です
作成後、fumioswebvpn のメニューから “ネットワーク” を選択し、”VNET 統合” の “セットアップ” を選択します。セットアップを選択すると、仮想ネットワークの一覧が表示され、仮想ネットワーク ゲートウェイで ”ポイント対サイトの構成” がされている仮想ネットワークのみ選択が可能になっています。2.1 で作成した “AzureVnet1” が選択可能になっているはずなので、”AzureVnet1” を選択します。 appfig5 構成終了後、”VNET 統合” の “構成するにはここをクリック” をクリックすると、以下のように接続状況が表示されます。 appfig6 AzureVnet1GW のメニューから “ポイント対サイトの構成” を選択します。正常にポイント対サイト接続が完了していると、以下のように “割り当て済み IP アドレス” に、Web Apps に設定された IP アドレスが表示されます。 appfig7 この段階で Azure の仮想ネットワークに接続されているため、仮想ネットワーク1 AzureVnet1 に配置されている仮想マシンにアクセスが可能になります。TCP と UDP をサポートしていますが、共有ディスクのマウントはできません。この制約は、プロトコル上の制約になるため、仮想ネットワークとは関係ないですが、SMB プロトコルを利用する Azure File の利用もできないので注意して下さい。

3) 追加した仮想ネットワークの接続

次に、オンプレミスと仮定した仮想ネットワーク2を作成し、仮想ネットワーク1と作成するとともに、ポイント対サイトで接続された Web Apps と仮想ネットワーク2へアクセス可能なようにルーティングを構成します。

3.1) 仮想ネットワークの作成

2.1 と同様に、仮想ネットワーク2 を作成します。 【仮想ネットワーク2】
  • 名前：Onpremise
  • アドレス空間：10.0.1.0/24
  • サブネット名：subnet1
  • ゲートウェイ サブネット：10.0.1.240/28 ※仮想ネットワーク後にサブネット メニューから作成します
  • サブネット アドレス範囲：10.0.1.0/26
仮想ネットワーク作成後、以下のように仮想ネットワーク ゲートウェイを作成します。 【仮想ネットワーク ゲートウェイ】
  • 名前：OnpremiseGW
  • ゲートウェイの種類：VPN
  • VPN の種類：ルートベース
  • SKU：Standard
  • 仮想ネットワーク：AzureVnet1
  • パブリック IP アドレス：新規作成

3.2) ローカル ネットワーク ゲートウェイの作成

通常、仮想ネットワーク間の接続であれば、接続設定をすることでルーティングが行われるため、その他の設定は不要ですが、オンプレミスと接続する際には、適正にパケットをオンプレミス側にルーティングするために、ローカル ネットワーク ゲートウェイの作成が必要になります（クラシック デプロイ モデルでは、ローカル サイトとして存在していました）。今回は仮想ネットワーク以外のポイント対サイトで利用されるアドレス空間のルーティングが必要になるため、仮想ネットワーク間の接続でもこのローカル ネットワーク ゲートウェイを利用します。 以下、２つのローカル ネットワーク ゲートウェイを作成します。 【ローカル ネットワーク ゲートウェイ (オンプレミス)】
  • 名前：OnpremiseNetwork
  • IP アドレス：仮想ネットワーク ゲートウェイ OnpremiseGW のパブリック IP アドレス
  • アドレス空間：仮想ネットワーク Onpremise のアドレス空間（10.0.1.0/24）
【ローカル ネットワーク ゲートウェイ (Azure)】
  • 名前：AzureNetwork
  • IP アドレス：仮想ネットワーク ゲートウェイ AzureVnet1GW のパブリック IP アドレス
  • アドレス空間：仮想ネットワーク AzureVnet1 のアドレス空間（10.0.0.0/24）
  • アドレス空間：仮想ネットワーク ゲートウェイ AzureVnet1GW のポイント対サイトのアドレス空間（172.16.0.0/24）

3.3) 仮想ネットワークの接続設定

双方の仮想ネットワーク ゲートウェイにて、接続設定を行います。接続設定を行うには、仮想ネットワーク ゲートウェイの “接続” メニューを開き、追加を行います。設定は以下の通りです。 【AzureVnet1GW の接続】
  • 名前：ToOnpremise
  • 接続の種類：サイト対サイト（IPSec）
  • 仮想ネットワーク ゲートウェイ：AzureVnet1GW
  • ローカル ネットワーク ゲートウェイ：OnpremiseNetwork
  • 共有キー：任意
【OnpremiseGW の接続】
  • 名前：ToAzure
  • 接続の種類：サイト対サイト（IPSec）
  • 仮想ネットワーク ゲートウェイ：OnpremiseGW
  • ローカル ネットワーク ゲートウェイ：AzureNetwork
  • 共有キー：任意
設定完了後、以下のように状態が “接続済み” になれば作業は終了です。 appfig8 appfig9

4) 接続確認

接続を確認するために、Onpremise 仮想ネットワーク内に以下のサーバーを立てます。 【接続先サーバー】
  • OS：Windows Server 2016
  • 役割：Web サーバー（IIS）
サーバーが立ち上がったら、上記仮想マシンの “ネットワーク インタフェース” メニューからローカル IP アドレスを確認します（例：10.0.1.4） 続いて、Web Apps の “コンソール” メニューを選択し、以下のコマンドを入力します。 【入力コマンド】
  • >tcpping 10.0.1.4:80
※:80 は省略可能です 以下のように "Connected to 10.0.1.4:80.." が表示されたら接続 OK です。もちろん、Web Apps 上のアプリケーションからも同様に接続可能なので、オンプレミス上のデータベース等への接続も可能です。 appfig10]]> Virtual Machines https://docs.microsoft.com/archive/blogs/azure-sa-members/virtual-machines Sat, 18 Mar 2017 22:38:16 GMT https://blogs.technet.microsoft.com/azure-sa-members/?p=1445 Azure Virtual Machinesの特長

豊富なサイズ（スペック）

Azureでは仮想マシンのスペックが選択できますが、CPUやメモリ、その他のシステム仕様を事前に定義したものを「サイズ」と呼んでいます サイズは特徴によってA、D、F、Gなどのアルファベットで始まるシリーズで分類されており、さらにそのシリーズ内でスペックの違いがあります 例えばAシリーズではA0 ～ A11まで、GシリーズはG1～G5まで準備されているというイメージで、数字が大きくなると性能や拡張性（接続できるディスクの数やネットワークインタフェースカードの数など）が上がります サイズは負荷が高まってきたときなど必要な時に、ポータルやコマンドを使って柔軟に変更することができます（スケールアップ、スケールダウン） b116e06c2e73d8c36cfce0c36dc263a3 ※AシリーズもA8以上はHPC向けの高性能モデルとなります ※利用できるサイズはリージョンによって異なります サイズやシリーズの最新の一覧はドキュメントをご確認ください Linux仮想マシンのサイズ Windows仮想マシンのサイズ なお、課金は分単位で計算されますので、負荷がない時は細目にサイズを小さく変更したり、停止（deallocate）して課金自体を停止しておけば節約が可能です（注意点）

高いCPU性能

Virtual Machines のサイズには、上記の通り割り当てられているCPUコア数が明記されていますが、現在発表されているサイズではHyper  Threadingを無効化しており、物理コアを割り当てています そのため他社仮想マシンの同等表記のスペックと比較しても、高いCPU性能を出せる可能性があります またAzureの中でも多くのサイズがラインナップされており、CPUの性能値が比較しづらいので、AzureではACU（Azure Compute Unit）の概念を用意しており、サイズのCPU性能比較をしやすくしています

リソースマネージャー（Azure Resource Manager）による構成

リソースマネージャーは、Azureの基盤となっている重要な要素の1つであり、Virtual Machinesやその他のAzureのコンポーネントを再利用したり、細やかな権限管理を実現するために欠かせない技術です Virtual Machinesなどクラウドのコンポーネントの構成要素をリソースとしてとらえ、それぞれ独立して管理することができます AzureのVirtual Machinesは、本体の仮想マシンに加え、ディスク、ネットワークインターフェース、パブリックIPアドレス、ファイアウォール（NSG）等それぞれ独立した複数のリソースが組み合わされて1つのVirtual Machinesを構成しています 61fdbd57d4f0278ca1c736f4ff83f965 Virtual Machines作成時の構成リソースイメージ

コマンドやAPIによる管理

ポータルだけでなく、コマンドやWeb APIによる操作も可能です Virtual Machinesの起動、停止、作成の他、ロードバランサ等の操作など基本的な操作に加え、ポータルではできない細やかな設定もできます 現在はPowerShellに加え、クロスプラットフォームで動作するAzure CLIも利用可能です 2017年2月末にはAzure CLI 2.0が正式リリースされました

その他

その他にも
  • Red Hat LinuxやWindows等有償OSの仮想マシンがライセンス込みの料金（分単位）で利用可能
  • Azureマーケットプレイス からすでにアプリケーションが構成済みのVirtual Machines（例:WordPressがセットアップ済みのサーバ）が利用可能
など迅速にさまざまなサーバの利用を開始するための仕組みが用意されています    

便利な機能

Virtual Machines は標準で多彩な機能を備えていますが、独断で便利な機能をピックアップしてご紹介します

バックアップ

Virtual Machines に対して、オンラインでの定期バックアップを設定できます 増分バックアップができるため、保存されるストレージのデータ量（料金）を節約しながら、 いざ戻したいときには、簡単な手順で別のVirtual Machines として復旧することができます 28e4a2ff778fef2e82caa5045ab071fc

自動シャットダウン

例えばVirtual Machines を勤務時間だけしか使わず、それ以外は停止しておきたい等の要望に対してスケジュールされた自動シャットダウンの機能を提供します 業務用のサーバやPC等の用途に適しており、シャットダウン忘れによる意図しない課金を防ぐことができます 6da87b5d4b6fa8208a86b1350ae2bdcf  

Azure Virtual Machines を使うときのFAQ

Q. ポータルでVirtual Machines のほかに、仮想マシン（クラシック）というメニューがありますが、これはなんですか？

A. 仮想マシン（クラシック）は第1世代の仮想マシンのことで、ASM 仮想マシンと記載されることもあります 本稿で説明している Virtual Machines は第2世代であり、仮想マシン バージョン2、ARM 仮想マシンと呼ばれたりします

それぞれ仮想マシンを構築できますが、内部構造は異なっており、仮想マシン（クラシック）はリソースマネージャーをベースとしていません 予想される通り第2世代であるVirtual Machines の方が機能が豊富であり、リソースマネージャーによる管理（再利用など）が可能ですので、新しく仮想マシンを作られる際は Virtual Machines から作られることをお奨めします ※なお本記事では、Virtual Machines バージョン2について記載しています 仮想マシン（クラシック）の場合は仕様が違う場合がありますので、ご注意ください  

Q. Virtual Machines を消したのに、そのVirtual Machines で使っていたパブリックIPアドレスやネットワークインタフェースなどが消えません

A. Virtual Machinesの削除の仕方によっては、関連リソースが消えない場合があります

上記で説明した通り、仮想マシンは複数のリソース（パブリックIPアドレスやネットワークインタフェースやディスクまたはストレージアカウント等）が組み合わさって構成されています ポータルでVirtual Machinesのブレード（メニュー）で削除しても、いわゆる構成リソースの1つである仮想マシンだけ消され、その他のリソースは消えませんので手動で消す必要があります この面倒な作業をなくすコツとしては、Virtual Machinesを作成する際に構成するリソースは標準では同じリソースグループに入るため、そのリソースグループを丸ごと削除するのが簡単で確実に消す方法の1つです ただし、他のVirtual Machinesやその他のリソースが利用しているリソース（仮想ネットワークなど）を削除しないように注意してください 可用性セットを使っている場合は同じリソースグループに複数のVirtual Machinesのリソースが属しているので、特に注意しましょう db32976269542a86d4ea65e0999b9132 リソースグループの削除ボタン  

Q. Virtual Machines を停止したのですが、課金が続いているようです

A. Virtual Machines の課金を停止するには、deallocate（割り当て解放）状態にする必要があります

Virtual Machines の停止状態には、stop（動作停止）、deallocate（リソース割り当て解放、課金を停止）があります ポータルで「停止」ボタンを使って停止すると、deallocate 状態になります しかし、Azure CLIで仮想マシンを停止して課金を止めたい場合は、stopではなく、deallocate を使ってください（わかりにくいですね・・・） 
$ az vm deallocate -g ubuntushkawan -n ubuntushkawan
{
"endTime": "2017-03-14T06:24:52.964365+00:00",
"error": null,
"name": "c1ece408-2f99-4b1c-9918-56c4ae58e98c",
"startTime": "2017-03-14T06:22:51.759683+00:00",
"status": "Succeeded"
}
リソース解放状態にしても、データを保持しているストレージ（Storage Account）や静的パブリックIPアドレスなどは課金される場合がありますのでご注意ください

Q. ポータルで停止、Azure CLIでdeallocate の後、起動するとパブリックIPアドレスが変更されています

A. 標準ではパブリックIPアドレスは動的割り当てとなります

固定したい場合はパブリックIPアドレスの設定で、事前に静的（固定）割り当ての設定が必要です 静的パブリックIPアドレスはリージョン内で最初の5個まで無料（Load Balancer等で使ってもカウントされます）ですがそれ以上は課金対象となりますので、パブリックIPアドレスを静的に割り当てたシェルホストを踏み台にしたり、ロードバランサでアドレス変換（ポート転送）でVirtual Machines にアクセスする等、上手に節約してください 40bb567931f284e09a63d7d8e279df49     以上です 今回は他社の仮想マシンを使ったことがある方への入門編ということで、いくつか特長と注意点をピックアップしてみました]]> OMS - Microsoft Operations Management Suite - https://docs.microsoft.com/archive/blogs/azure-sa-members/oms-microsoft-operations-management-suite Fri, 27 Jan 2017 11:10:20 GMT https://blogs.technet.microsoft.com/azure-sa-members/?p=1365 Azure OMS Microsoft が提供するIT管理ソリューションであるOMSについての解説を致します。 OMSにも様々な機能があるため、今回は主にLog Analyticsについての解説をし、機能に触れながらどのような時に使えるのかという論点をまとめていきたいと思います。 概要についてはこちらの記事で述べさせていただいておりますので、こちらも合わせてご覧ください。 「クラウド時代には、なぜ「ログ分析」が重要になるのか――高度なログ分析機能を、すぐに、簡単に使えるMicrosoft Operations Management Suite」  

Azure OMSとは

Microsoft Operations Management Suite (OMS) は、Microsoft のクラウドベースの IT 管理ソリューションです。OMS を使用して、オンプレミスとクラウドのインフラストラクチャを管理し、保護することができます。 OMS はクラウドベースのサービスとして実装されるため、インフラストラクチャ サービスに最小限の投資をするだけで、すぐに稼働させることができます。 新しい機能は自動的に配信されるため、継続的なメンテナンスやアップグレードのコストが節約されます。 OMS は、価値のある独自のサービスに加え、System Center Operations Manager などの System Center のコンポーネントと統合して、管理のための既存の投資をクラウドに拡張できます。 System Center と OMS を連携させることで、本格的なハイブリッド管理を実現できます。 （参照：Operations Management Suite (OMS) とは）
image.png

OMSのLog Analyticsをログ分析のために用いる論点

「ログ分析ってなんのためにやるの？」という質問の答えは以下が多いでしょう。

  • 障害発生時の原因究明
  • システムの傾向分析（クラウドの課金）
  • セキュリティ監査
それではなんでログ分析をOMSで行うのかを考えていきましょう。

ログがクラウドにある

原因究明のためのログが全部クラウドにあるということはセキュリティの観点でメリットです。 まず悪意のあるハッカーがやることは以下です。
  1. 準備として不審な動きをする(特定のポートに秒間何回もアクセスがあったり)
  2. 侵入する
  3. 悪さをする
  4. 悪さをした痕跡を消す
ログがオンプレ上にあった場合、多くの場合サーバーへの侵入とともに痕跡は消されてしまうでしょう。しかしログがクラウドにあった場合、悪意のあるハッカーは痕跡を消すことが出来ません。 マイクロソフトはペンタゴンの次に悪意のあるハッカーから攻撃されているデータセンターを持っています。もしもハッカーがマイクロソフトのデータセンターに侵入して攻撃の痕跡を消すためにはマイクロソフトのセキュアなデータセンターの壁を乗り越える必要があるのです。 またOMSで扱えるログデータにアクセスする場合は、AzureのAPIではReadはできてもWriteがそもそもできません。 ログがクラウドで管理される問ことはセキュリティの観点でかなりのメリットになります。

コンピューティングリソースを圧迫しない

OMSは今まで管理者が考える必要があったストレージリソースと、演算のリソースを開放します。 ログを多面的に分析したい場合、様々なログを取得することになりますが、その時にログ関連の処理はコンピュータのリソースを圧迫する可能性があります。 OMSの分析をする際にはその必要はありません。必要な時だけ分析エンジンを利用することができます。そしてサーバー運用管理の際に頭を悩ませる一つの要因として、無限にたまっていくように思われるログのデータ容量があります。しかしOMSは既存のストレージの容量を圧迫することがありません。 OMSでは独自のクエリを使ってAzure及びオンプレミスのマシンを含むハイブリット環境のログを検索することができます。 その検索も非常に高速で、潤沢なマイクロソフトのデータセンターのコンピュートリソースを使い、すぐにログ検索の結果を出力することができるのです。 capture20170126165535551 今回のコードは各マシンのプロセッサのパフォーマンスの平均値を取得しています。 また、下のスクリーンショットでは検索窓にアスタリスク(*)を入力し、取得できるすべてのログ集めています。下記環境では１週間で７億９２００万件のログがヒットしていますが、こちらも数秒で取得することができます。
capture20170126165002242 OMSの場合は、ログ分析のためのインフラを考える必要はなくなるでしょう。  

ハイブリッド環境にも使えて、WindowsもLinuxも対応

OMSはオンプレミスの環境にも使うことが出来る、ハイブリッド環境対応の管理サービスです。 もちろん、SoftlayerやAWSといった様々なクラウドのサービスとも連携させることが出来ます。 OMSでは対象のマシンにエージェントをインストールすることで、そのVMがAzureと通信可能な状況にあれば簡単に利用を開始できます。 そして、一つのダッシュボードで統合管理をすることが出来ます。
またOMSで管理できるのはWindowsだけではありません。Linuxベースの多くのOSにも対応しています。
それぞれのOSで作成されるログの形式はバラバラですが、OMSはその差を吸収します。
capture20170126184411682 OMSでは、Windows環境もLinux環境も分析します。例えばアップデートマネジメントの画面では、どのマシンをアップデートすべきか、あてるべきセキュリティパッチはあるのか、といったことを知ることができます。そうした設定もWindowsとLinuxで別の設定をするのではなく、Agentさえ入れればOMSが勝手にやってくれることになります。

見えないものが見える

今までのログ管理では、「ためる」「見る」にフォーカスしがちで、主な目的は死活監視や障害対応でした。 そのため、多くのソフトウェアは「ダウンしていないか」ということにフォーカスしたデザインになっていました。 しかしそうした管理方法ではログから何か知見を得ようとするのが難しいです。 OMSの強みは、システムを俯瞰的に解析し、改善のためのアドバイスができるということです。 「人間が何か特定の事を考え、それを検証するために何かのコマンドを打って結果を見る」という繰り返しが今までの主な管理方法でしたが、 OMSでは、「この設定のほうが良い」「全体のVMのうち何台がアップデートされずに放置されているため、アップデートしたほうが良い」 といったことを、人間が管理していなくても教えてくれます。またOSのアップデートなど、分かってはいても無視されている問題も浮き彫りになります。
また、これはセキュリティの観点で、システム管理者のプロアクティブな活動の一助になります。 capture20170126164604798 OMSはログを見て判断するためだけの環境ではありません。OMSでは解析結果から示唆を得ることができます。

ソリューションを提供

OMSには29のソリューションがあります。
ログを分析できるツールを導入した際に、まず最初に躓く点がダッシュボードの作成だと思います。 ログというデータはあるものの、実際にそれをひと目見ただけではよくわかりづらいですし、セキュリティならセキュリティ、障害対応なら障害対応の切り口で複数のダッシュボードをくみ上げなければなりません。 つ まり、導入してもすぐに使い始めることができないのです。一方でOMSの場合は、もう完成されたものが用意されています。例えば、セキュリティ監査の観 点、Azureマシンのアップデート状況、バックアップの状況、Active DirectoryやO365の状況など、様々な切り口で導入後すぐに分析を開始できます。
capture20170126185701216

ログ分析

OMSはSaaSとして提供される管理環境で、ログ分析を誰でも簡単に始めることができます。 しかし、必ずしも「なんでも」できるわけではありません。もちろん、自分でログを収集するツール、ログを分析するツール、結果を可視化するツールを手組で組んだものに比べればできることの範囲は小さくなります。 ただし、それらのシステムを構築する時間や、それぞれのシステムが配置されるマシンにかかる費用を考えたときに、どちらを選択するほうが良いでしょうか？ 昔からSIEMというかたちでログ分析の基盤は提供されていました。しかしそれはシステム的にも価格的にも導入難易度が高いものがあり、一度導入したらそれを使い続けることになります。 一方でOMSはサブスクリプション型の課金モデルで使うことができ、ダッシュボードも簡単に作成可能です。 ログ分析をすぐ始めたい時の入り口として、まずOMSはを使ってみるというのも良いのではないでしょうか。  
]]> Data Catalog https://docs.microsoft.com/archive/blogs/azure-sa-members/data-catalog Fri, 20 Jan 2017 17:38:21 GMT https://blogs.technet.microsoft.com/azure-sa-members/?p=1245 はじめに ビジネスにおいてデータの重要性は従来より認識されていましたが、機械学習、深層学習、ビッグデータ活用といったデータを中心とした技術が成長している今日ではさらに重要度が増しています。しかし、データ資産を企業全体に対して把握することは困難であったため、必要なデータがどこにあるか分からない、もしくはそもそも存在しているかどうかが分からない、といったことが多かったかと思います。 Azure Data Catalogは構造化・非構造化、オンプレミス・クラウド問わずデータソースを一元管理できるため、必要なデータの有無や場所をすばやく把握することができ、データ資産からの価値創出に役立てることができます。

Azure Data Catalogでできること

Azure Data Catalogでは、以下の機能を活用してデータ資産の管理及びデータ資産からの価値創出をサポートします。

データソースの登録

メタデータをデータソースから抽出して、Azure Data Catalogに登録します。メタデータに加えて、データのサンプルを抽出して登録することも可能です。
SQL Data Warehouseからの抽出例：
register データソースの登録は、登録ツール、API、手動にて行うことができます。サポートされているデータソースと登録方法については、以下のリンクを参照してください。 Azure Data Catalog でサポートされるデータ ソース

データソースの検出

検索とフィルタ機能により、Azure Data Catalogに登録されているデータソースを検出することができます。 検索では、通常のキーワード検索に加えて検索構文による検索も可能です。例えば、「name」プロパティに「CRMOL」というワード、「tags」プロパティに「Crossover」というワードが含まれているデータソースを検索する場合は、 name:CRMOL AND tags:Crossover という検索構文を使用できます。
検索構文による検索例：
search_result

データソースの注釈付け

データソースを分かりやすくするために、データソースから抽出されたメタデータを補完する説明用のメタデータ(説明やタグ)を追加することができます。

データソースの文書化

データの用途や業務シナリオといった、よりユーザーに役立つ情報を管理する方法として、ドキュメント作成のためのリッチテキストエディタを提供しています。このエディタでは他のドキュメントへのリンクも追加できるため、ニーズに応じた粒度でのドキュメント作成が可能です。

データの参照

Azure Data Catalogはデータソースへのサンプルデータを保持してるため、データソースにアクセスせずにサンプルデータを参照することができます。クライアントツールを用いて、データ資産への接続及びデータの参照も行うことができます。サポートされているクライアントツールは以下になります。
  • Excel (Excel 2010以降)
  • Power Query (Excel 2016、Power Query for Excel アドインがインストールされている Excel 2010 または Excel 2013)
  • Power BI Desktop
  • SQL Server Data Tools (SQL Server ツールがインストールされている Visual Studio 2013 Update 4 以降)
  • レポートマネージャー (SQL Server Reporting Services のブラウザーの要件を参照してください)
また、Azure Data Catalogではデータソースに対する接続情報もメタデータとして管理できるため、こちらを使用してデータ資産に接続することも可能です。
サンプルデータの参照とクライアントツールの呼び出し例：
preview

データソースのプロファイリング

データをより理解するためには、データそのものに加えてデータの統計や情報も助けになります。Azure Data Catalogはデータソースのメタデータに加えて、データの統計や定義といったプロファイル情報も抽出することができます。 例えばデータソースがデータベース表の場合、以下のプロファイル情報が抽出されます。
  • 行数
  • 表のサイズ
  • 最後に更新された日付
  • 列のデータ型
  • 個別の値の数
  • NULL 値を含んだ行の数
  • 列の値の最小、最大、平均、標準偏差
データのプロファイル例：
data_profile

データ資産の所有権の管理

Azure Data Catalogで管理しているデータ資産の所有権を指定し、必要なユーザーのみがデータ資産にアクセスできるように制御することができます。

関連リンク集

]]> HDInsight https://docs.microsoft.com/archive/blogs/azure-sa-members/hdinsight-2 Wed, 28 Dec 2016 19:23:56 GMT https://blogs.technet.microsoft.com/azure-sa-members/?p=475 HDInsight のスクリプトアクションとは？ Spark や Hadoop を動かす場合、実行環境の OS やアプリの動作環境の設定が必要になることがよくあります。 たとえば、
  • Spark ジョブの実行時に必要となる OS の設定を事前に行っておきたい
  • 自作ライブラリを ワーカーノード内のどこかのディレクトリに格納しておきたい
  • ワーカーノードに設定ファイルを作成し、実行時のための設定情報を保存しておきたい
などです。 もちろんシェルなどをどうにか駆使して、上記のような設定を行うことも可能ですが、クラスタの初期構築後に手動で設定を行ったり、伸縮するワーカーノードに適切に設定を施したりするのは手間になることがあります。マネージドサービスである HDInsight には、あらかじめそういった環境構築用の便利な機能が組み込まれており、簡単に設定スクリプトをクラスタに適用することができるようになっています。 HDInsight にはスクリプトアクションという機能があり、それを使うことによりクラスタの新規作成時や、ワーカーノードを増やす場合に環境設定用のスクリプトを仕込んでおくことができます。 スクリプトアクションを使うことにより、Spark や Hadoop が動作するときに必要となる環境設定をスクリプトを使って自動化することができるようになります。 ちなみに Windows 版のクラスタの場合は、PowerShell や .NET SDK などによるスクリプトを組み込むことができ、 Linux 版 では、bash のスクリプトを組み込むことができるようになっています。 試しに、Linux 版で bash のスクリプトアクションを動かす手順について見てみましょう。

サンプル

今回は例として、 Linux 版 ODBC ドライバ（Azure SQL DB, Azure SQL Dataware House, SQL サーバ用）をワーカノードに自動インストールするための、スクリプトアクションについて説明します。 なお今回使用する HDInsight の環境は、 HDInsight Spark 2.0（ HDI 3.5.1） / Ubuntu 16.04 LTS を使います。 1. Bash シェルを下記のように作ります。 なおシェルの中身はこちらのリンク（ODBC Driver 13.0 for Linux Released） を参考にしています。 改行コードは LF になるように気を付けてください。またシェルはルート権限で実行されますので、sudo を付ける必要はありません。 2. 上記シェルをファイルに保存し、ファイルを Blob ストレージ に保存します。 実際のスクリプトアクション実行時は、ここで保存した ファイルを実行時に読み出すことになります。なお注意点として、Blob のアクセス権は、「完全なパブリック読み取りアクセス」 に設定しておいてください。 3. HDInsight Spark を新規作成します。 Azure ポータルから Linux ベースの Spark クラスタを作成します。 Azure ポータルを使用した HDInsight の Linux ベースのクラスター作成の「クラスターの作成」を参考に、クラスタを作成していきます。 なお今回必要となる設定は、[詳細な構成]となりますので、 [クラスター名]、[資格情報]、 [データソース]、[価格]、[リソースグループ] については任意に設定してください。 また[クラスターの構成] は、HDInsight Spark 2.0 (Linux) を設定してください。 4. [詳細な構成] - [スクリプト操作] で、Bash シェルを登録します。 下記のスクリーンショットを参考に [スクリプト操作] メニューにて、以下を入力します。 - 名前：　シェルの任意の名前を設定します。 - ハッシュスクリプト URI：　上記手順２の、Blob に保存されたシェルファイルの URI を指定してください。 - [ワーカー] のみにチェックを入れます。 ODBCドライバが必要となるのは、ワーカーノードのみなので。 - [パラメーター] は必要に応じて指定可能です。今回は不要なので空白のままとします。 5. 上記の構成ができましたら、[作成] ボタンを押しクラスタの構築を開始します。状況によりますが約15 - 20分 ほどかかります。 o1 6. 基本的には、これで設定は終わりで、クラスタ構築後はめでたくODBCドライバがインストールされているはずです。またクラスタの新規構築時に設定するシェルは、ワーカーノードを追加する場合も自動的に、新しいノードに対して適用されます。 Azure ポータルからは、あとでシェルを追加することも可能ですし、登録済みのシェルをアドホックに再起動させることも可能です。

スクリプトアクションのログ

スクリプトアクションの動作ログは、HDInsight に付属している Ambari  から確認することができます。 以下手順となります。 1. ブラウザで、https://<クラスタ名>.azurehdinsight.net/ にアクセスします。（Ambari についての説明はこちらを参考にしてください） 2. ページ上部のバーの、[ops] エントリをクリックします。 3. 一覧から、「run_customscriptaction  (複数存在する可能性があります)」 をクリックすると、以下の画面が現れ STDERR と STDOUT の出力を確認することができます。 odbc0  

結果の確認 (ODBCドライバの動作確認)

これは必須ではないのですが、最後に、クラスタの構築が完了したらODBCドライバが正常にインストールされているかを確認できます。 SSH でワーカーノードにログインし、 （SSH についてはこちらのドキュメントを参考にしてください） 、 ODBC Driver 13.0 for Linux Released の「Try our Sample」の個所を参考に簡単に確認することが可能です。ワーカーノードに SSH でログインし、以下のコマンドを実行します。 >wget "https://raw.githubusercontent.com/Microsoft/sql-server-samples/master/samples/tutorials/c/linux/sample_c_linux.c" ここで、ダウンロードしたサンプルコードの、61 行目の ODBC 接続文字列をご自身の環境に合わせて編集してください。` >gcc sample_c_linux.c -o sampleapp -lodbc -w            # sampleapp という C のアプリがカレントディレクトリに生成されます >./sampleapp 上記を実行すると、下記のようなメッセージが表示されます。  この例では、Azure SQL DB に接続しているのですが、下記のメッセージが正常表示されているので、ODBC ドライバのインストールが成功していると言えます。 Result is: Microsoft SQL Azure (RTM) - 12.0.2000.8 Dec 5 2016 21:15:30 Copyright (C) 2016 Microsoft Corporation. All rights reserved.  

参考リンク

https://docs.microsoft.com/ja-jp/azure/hdinsight/hdinsight-hadoop-script-actions-linux https://docs.microsoft.com/ja-jp/azure/hdinsight/hdinsight-hadoop-customize-cluster-linux#troubleshooting  ]]> Azure PaaS Overview https://docs.microsoft.com/archive/blogs/azure-sa-members/azure-paas-overview Mon, 12 Dec 2016 21:58:00 GMT https://blogs.technet.microsoft.com/azure-sa-members/?p=1125 はじめに 非常に変化の速いクラウドの世界ですが、その中でも Microsoft Azure において PaaS : Platform as a Service に位置づけられるサービス群はバリエーションが豊富で、情報をキャッチアップしていくことは困難です。ともすれば情報の量と変化の多さに辟易して敬遠してしまいがちです。このため本記事では Azure における個々のサービスの紹介は省き、一般論としての PaaS の意義と価値を改めて整理し、読者の方が評価や導入されるにあたって基本として押さえておいて頂きたい考え方についてご紹介したいと思います。
  •  Microsoft Azure における PaaS
  • PaaS の意義と価値
  • 開発標準とプラットフォーム

Microsoft Azure における PaaS

Microsoft Azure にはたくさんのサービスがありますが、以下の図中の赤枠の中のサービス群が PaaS として分類されます。どれが PaaS でどれが PaaS ではないのかといった分類上の議論にあまり意味は無いと思いますが、そもそも何故こんなにたくさんのあるのでしょうか？ この中から適切なものだけを選択して組み合わせてアーキテクチャを構築するというのは考えるだけでも頭の痛い作業です。そんな大変な思いをしてまで PaaS を利用する必要があるのでしょうか。 paas-of-azure しかし Azure のドキュメント「PaaS とは」において、主に開発生産性の向上がその利点として掲げられています。また Forester 社の調査「Microsoft Azure PaaS の経済的な影響全般」においても費用削減等のビジネス上の便益が語られています。本記事においても改めて PaaS とはどういうものなのか、それを利用するメリットとは何なのか、利用する上での考慮事項等についてご紹介したいと思います。

PaaS の意義と価値

さて NIST の定義では、、、というのは置いておいて、IaaS や SaaS、オンプレミス との対比として、システムの構成要素をユーザー様とマイクロソフトの責任領域で分類した図がよく用いられます。物理的なネットワーク、ストレージ、サーバー、仮想化のレイヤが提供されるという意味では IaaS と同等です。それに加えてクラウドベンダーは一般的に求められる各種のアプリケーション特性を加味し、OS、ミドルウェア、ランタイム までをセットで提供することでユーザー様からの需要に答えていきます。この需要が多種多様であるため、先ほどのように数えるのも嫌になるほど多くのサービスがラインナップされることになってしまうわけです。 service-stack-and-responsibility この区分は、非常に大まかに言ってしまえば機能要件と非機能要件を司るレイヤであるとも言えます。非機能要件領域に対して各サービスは基本的な機能に加え、ユーザー様が”設定”することのできるいくつかのオプション機能も提供します。これらの機能やその組み合わせはマイクロソフトが責任を持ってテスト済みのものになります。社内でのテストだけではなく、プレビュー期間から多数のユーザー様にお試しいただくことで実績を積み、品質を向上したうえで一般公開されるわけですから、比較的新しい機能であっても実績があることになります。このことを根拠としてユーザー様はインフラストラクチャに対する設計・構築・テストのコストを削減することができることになります。そしてアプリケーションの本質的な目的である機能要件、すなわちビジネス価値の実現に注力できるわけです。

組み込み済みの品質

非機能要件は XXXability と呼ばれるような品質特性に対して定義されることが一般的であると思います。各サービスにおいてはこれらの品質特性に対する一定のソリューションが用意されていますので、ユーザー様はサービスを利用するだけでこれらの特性を（全てでは無いにしても）活用できることになります。以下では Azure における PaaS の代表格とも言える Web Apps を例として、各品質特性の観点から見てどのようなソリューションが提供されているかを見ていきたいと思います。

拡張性 : Scalability

Web Apps においてアプリケーションは App Service Plan と呼ばれるサーバーファーム上で動作します。App Service Plan に対してサーバースペック（コア数、メモリ量等）やその台数を調節することで、スケールアップ／スケールアウトを柔軟に行うことが可能です。

安全性 : Security

Web Apps にアクセスするユーザーの認証および承認に対しては、Azure Active Directory を使用したオンプレミス ID を使用することもできますし、 Microsoft アカウント、Google、Facebook、Twitter といったソーシャル ID を使用することもできます。また既定で付与されるドメイン名 *.azurewebsite.net では HTTPS が有効になっており暗号化通信が可能ですし、カスタムドメイン名に対する証明書を購入あるいは持ち込んで HTTPS を有効にすることも可能です。App Service 環境を使用した場合には Web Apps を IaaS 仮想マシンと同様に Azure 仮想ネットワーク上に配置することが可能です。これによりパブリックインターネットからのアクセス経路を排除する、あるいは、Web アプリケーションファイウォールを設置するといったような、より高度なセキュリティオプションを組み焦ることも可能になります。

耐障害性 : Fault Tolerance

アプリケーションやコンテンツは各 Web サーバーのローカルストレージではなく、App Service Plan で共有されるストレージに配置されます。この共有ストレージは他のストレージサービスと同様に多重化されていますので、もし Web Apps をホストするサーバーが破損したとしても、そのデータが失われる可能性が極めて低くなるように構成されています。

可用性 : Availability

ユーザーからのリクエストは Azure の Load Balancer から負荷分散されて Web サーバーに転送されるように構成されています。各 Web サーバーは Azure によって常にその正常性が監視されておりますので、何か異常があれば別の Web サーバーが自動的にアサインされ、負荷分散が切り替わることで可用性を実現しています。またアプリの複製機能を用いて別のリージョンに同じアプリを配置し、Traffic Manager サービスを組み合わせることで、広域災害にも耐えうる高可用性を手に入れることもできます。

運用容易性 : Operability

Azure の診断機能を使用することで、Web サーバーの各種ログやアプリケーションログを取得することができます。ログはファイルシステムに出力した場合は FTP で、Blob や Table ストレージに出力した場合は REST API で取得することが可能です。また Application Insight を組み合わせて使用することで性能や稼働状況といった各種のテレメトリを収集・分析し、何か問題があればアラートを上げるといった自動化も可能です。

保守容易性 : Maintainability

Web Apps にアプリを配置するには、伝統的な FTP(S)、OneDrive や Dropbox との同期、Visual Studio Team Services、GitHub、BitBucket からの継続的デプロイ、ローカル Git からの Push といった様々なオプションが提供されているため、容易に動作環境を構築し、テストを行うことが可能です。またステージング環境を作成してアプリを配置しておき、最終的な品質確認が完了した後に運用環境とスワップすることで、ダウンタイムなしで最新のアプリへアップデートすることが可能です。

移植性 : Portability

Web Apps の Web サーバーは Azure 特有の実行環境ではなく、 Windows IIS の ARR モジュールと、その背後で動く ASP.NET 、Node.js、PHP、Tomcat、Jetty といったアプリケーションサーバーで構成されています。これらのコンポーネントは入手が容易ですので、他社クラウドやオンプレミス環境上に同等の動作環境を構築することは技術的に可能です。つまり Web Apps 向けに開発したアプリは Azure に囲い込まれるリスクがありません。また現在開発中の Azure Stack がリリースされれば、Web Apps に限らず Azure そのものの互換環境を構築することも将来的には可能になってくるでしょう。

相互運用容易性 : Interoperability

Web Apps は既定でインターネット上の各種サービスと HTTP(S) を使用した連携が可能ですので、Web API を利用する、あるいは提供することができる環境になっています。独自に実装せずとも Logic Apps で提供されたコネクタを利用することで、コーディングレスで外部システムと連携することも可能です。またハイブリット接続、VNET統合、App Service 環境といった、 Azure IaaS 上の仮想マシンやオンプレミス環境でホストされたサーバーと連携するためのオプションも提供されています。

低コスト・高品質を迅速に実現

上記から Web Apps が単なる「IIS が有効になった Windows サーバーを並べただけのモノ」ではなく、これだけの品質を実現するために内部的には様々なものがセットアップされており、その料金に含まれる形で提供されていることがご理解いただけるかと思います。これ以外の PaaS でも、必ずしも全てでは無いにしても、一定の品質が標準機能として提供されています。これらは既定で有効になっているか、Azure ポータル、PowerShell、ARM テンプレートによって“構成”するだけで有効にすることができます。 一方オンプレミス環境や IaaS であれば前述のような品質は独自に作り込む必要があります。サーバー、ストレージ、ネットワーク、OS、ミドルウェア、ランタイムを選択し、組み合わせ、製品固有の設定方法を駆使してカスタマイズし、期待した品質レベルに到達しているかをテストによって検証していく必要があるわけです。 PaaS の価値を最大限に生かすための知識はもちろん必要になりますが、その構築に必要となる工数と時間は、システム全体に要するそれに対して非常に小さな範囲で収まるのではないでしょうか。

開発標準とプラットフォーム

この考え方やアプローチ自体は決して新しいものではありません。従来からも成果物品質の底上げや開発生産性の向上という課題に対して、標準化、フレームワーク、共通部品、アーキテクチャといった形でアプリケーション開発やプラットフォームに一定の制約とルールを定義する、というソリューションは一般的だったかと思います。Microsoft Azure における PaaS とは、マイクロソフト社がアプリケーション開発における一般的な課題に対して、自社のノウハウを元に編み出したソリューションである、と言うことができるかと思います。 paas-category PaaS を使いこなすうえでは、どのサービスがどういった需要に答え、どのような品質特性をそなえているものなのかを理解し、適切に取捨選択することが必要です。当然ながらクラウドベンダー視点で全体最適化されたソリューションが、開発者の皆さんが実現すべき個々の“要件”に対して必ずしも適切であるとは限りません。というよりも完全に一致する方が稀でしょう。となれば選択肢は 3 つです。
  • IaaS を利用してフルカスタマイズで構築する
  • 問題となる部分だけ IaaS を組み合わせて構成する
  • 既存の PaaS で妥協する
どれも間違った選択ではありません。ただ PaaS ではなく IaaS を部分的に、あるいは全体的に利用するということは、設計や構築における自由度を得る代わりに、PaaS が提供する価値を捨てることでもあります。逆に言えば既存の PaaS で“妥協”することできれば、これまで紹介してきた価値は即座に、そして多くの場合はより安価に手に入るものであると考えます。

おわりに

PaaS の価値を明確にしようとするあまり、若干 IaaS を貶めるような論調の記事になってしまいましたが、IaaS は IaaS でその価値は大きなものです。PaaS における生産性と IaaS における自由度の問題はあくまでもトレードオフの関係であることを忘れないでください。ただ Azure の導入をご検討いただいているお客様とお話をしていると、従来と同じであることに固執するあまり、本来の“要件”を見失ってしまっているケースが散見されます。今後クラウドアプリケーションを構築される際には、従来からの“方法”ではなく、本質的な“要件”を見定め、PaaS で楽をすることが出来ないか、IaaS の自由度が本当に必要なのか、是非ご一考いたけだければ幸いです。]]> Microsoft Cognitive Services https://docs.microsoft.com/archive/blogs/azure-sa-members/cognitive-services Fri, 25 Nov 2016 16:20:30 GMT https://blogs.technet.microsoft.com/azure-sa-members/?p=675 はじめに 日本マイクロソフトの大内山です。このページでは、マイクロソフトの人工知能サービスの一つであるMicrosoft Cognitive Servicesをご紹介します。といっても、いわゆる製品紹介だけではなく、その背景にある昨今の"人工知能ブーム"、および、"マイクロソフトの人工知能に対する方針"なども併せてご説明します。

人工知能ブーム

本ブログを執筆している2016年11月現在、人工知能は第3次ブームの最中であると言われています。このブームは、ビッグデータブームからの機械学習ブーム、そして2012年ごろから急速に注目されたディープラーニングブーム、そういった複数のムーヴメントに支えられながら徐々に形成されていったものと考えられています。そして現在では人工知能の研究成果や企業の人工知能ビジネスなどに関するニュースが連日伝えられるくらいにまで拡大し、かつ、世の中に浸透してきました。 さて、「ブーム」というとその終焉が気になるのは私だけでしょうか。第1次ブームも第2次ブームもその後必ず冬の時代が到来しており、それまでの盛り上がりが嘘だったように沈静化しています。第3次ブームにも同様の事象が起こり得るのでしょうか。少しネガティブな話題ですが、人工知能の利用を検討するうえでは意識しても良い情報でしょう。 この問いに対しては、人工知能学会が出版している「人工知能学会誌 2016/5 Vol.31 No.5」内の記事においてヒントとなる記述がありますので抜粋かつ要約した内容をご紹介します。

”人工知能の第2次ブームはルールベース技術を中心に盛り上がったが、技術を生み出す側がそれを利用する側よりも盛り上がってしまったことがブームの終焉を引き起こしたと考えられる。

一方、第3次ブームも機械学習やディープラーニングといった技術が先行しているように見えるが、それらを容易に利用するための基盤（H/W、S/W）が充実してきている。したがって、技術を生み出す側よりも利用する側の方が盛り上がっている状態とも言え、今後ブームがシュリンクするというよりは、偏在化していくのではないかと考えられる。”

この記事からは、少なくともブームがシュリンクし消失するようなことにはならないことが期待できます。"偏在化"という言葉が出てきておりますが、どの領域において人工知能が生き残れるのか？、それを見極めるための試行錯誤が現在あらゆる分野で行われている最中です。そしてこの試行錯誤が続く限り、ブームの熱が冷めることはないものと言えるかもしれません。

マイクロソフトが考える人工知能

さて、マイクロソフトは人工知能をどのように考えているのでしょうか。その答えは2016年9月26～30日にアトランタにて開催されたMicrosoft Igniteにて提示されました。（Microsoft Igniteの各セッションは下記サイトにてオンデマンド動画が公開されております。） Igniteでは、CEOのSatya Nadellaから“Democratizing AI” (AI の民主化) という表現でその方針が示されました。これが意味することは、人工知能 がもっと一般的に利用され、身の回りのあらゆるITサービスで使われる状況になることです。つまり、より利用者視点に立って、かつ、より利用者に寄り添うような人工知能サービスを世に展開していくことを意味しています。前セクションにて、人工知能第3次ブーム継続の要として、"技術を生み出す側よりも利用する側が盛り上がること"、という内容をご紹介しましたが、“Democratizing AI”もまさに同様に利用者ファーストなコンセプトだと言えます。 技術的な側面に着目すると、この“Democratizing AI”は4つのテクノロジーグループによって支えられています。
  1. Agent・・・ユーザーとのUI部分
  2. Application・・・情報を活用、洞察を得る、次の一手を提示する部分
  3. Services・・・いわゆる頭脳に相当し、情報の分析や解析を行う部分
  4. Infrastracture・・・アプリケーションやサービスを支えるプラットフォームとしてのクラウド
ここで特に注目したいのは「3. Services」です。このグループには、具体的には、Azure Machine Learning、Bot FrameworkなどAIアプリケーションを開発するための重要なサービス群が属しており、このページでご紹介するMicrosoft Cognitive Servicesも同グループに属しております。 それでは、（前振りが長くなってしまいましたが）Microsoft Cognitive Servicesを次のセクションよりご紹介します。

Microsoft Cognitive Servicesとは

Microsoft Cognitive Services（旧称：Project Oxford）は人間の認知機能をモデル化し、そのモデルをAPIとして提供しているサービス群の総称です。（認知機能とは、視覚や聴覚といった外部のモノを判別するための能力を指します。）本サービスは、主にディープラーニング技術による既に完成されたモデルをAPIとして提供していることからSaaS型のサービスとも言えます。つまりユーザーは、ディープラーニングエンジンを用意したり、アルゴリズムを実装したり、膨大なデータを与えて学習させたり、、、といった従来の構築作業を省略し、利用すること（つまりアプリケーション部分）に注力できます。 本サービスの特徴は大きく下記の3点です。
  • 容易性
    • サービスはすべてREST APIとして提供されています。したがって、サービスの呼び出しも簡単ですし、既存のシステムへの統合もシンプルに達成できます。
  • フレキシブル
    • 前述したようにREST APIであるが故、HTTPリクエストを投げられ、HTTPレスポンスを受けられる言語であれば何でも使用できます。
  • 実績
    • マイクロソフトの各分野（リサーチ部門、Bing、Azure Machine Learningなど）のエキスパート達により開発されています。充実したドキュメントやサンプルも提供しており、コミュニティサポートも行っています。
中でも特筆すべきは「実績」です。Microsoft Cognitive Servicesの多くのAPIで使用されているディープラーニング技術について、マイクロソフトはImageNetが開催するコンペILSVRC2015にて、エントリーした5分野すべてで1位を獲得しました。こうした、研究実績に裏打ちされた世界最高峰の技術をお手軽に利用できることこそがMicrosoft Cognitive Servicesの意義であります。

Microsoft Cognitive Services API一覧

Microsoft Cognitive Servicesは複数のサービス群の総称であると書きました。ここでは、どういったサービスが含まれているかを一挙にご紹介します。 まずサービスは大きく5つのカテゴリに分類されます。
  • Vision・・・画像や動画に含まれる情報の抽出、顔認識、表情分析
  • Speech・・・音声入力/出力、話し手の識別、翻訳
  • Language・・・言語識別、文章解析からのニーズ推測
  • Knowledge・・・知識DB (Web、学術情報、内部データなど) を使った分析～予測
  • Search・・・Webにあるページ/画像/動画/ニュース などの情報を収集 (Bing)
では、各カテゴリごとにどういったサービスの内容を見ていきましょう。

Vision

  • Computer Vision
    • Analyze Image：画像または動画の内容をタグや記述形式で返してくれます。アダルトコンテンツ判定なども行えます。
    • OCR：画像の中の文字列を読み取り、テキストとして返してくれます。日本語対応。
    • Thumbnail：画像の内容に応じて数パターンのサムネイル画像を自動生成してくれます。
  • Content Moderator
    • コンテキストに応じて独自のルールやポリシーのセットを適用し、問題を含む可能性のある画像やテキストのコンテンツを自動的に検出できます。
  • Emotion
    • 画像または動画の中の人物の顔の表情から、感情（喜び/驚き/悲しみ/怒り/恐れ/嫌悪/軽蔑/中立）を読み取ります。
  • Face
    • Face Detection：画像または動画の中の人物の顔を識別し、そこから年齢や性別などを予測して返してくれます。
    • Face Verification：二つの人物が移った画像を比較し、それが同一人物であるか否かを検証します。
    • Face Identity：複数の顔画像の中から特定の顔にマッチする画像を検索します。
  • Video
    • Stabilizer：動画の揺れを自動補正します。
    • Detect Motion：動画中の動くものを検知します。（監視カメラなどでの利用が考えられます。）

Speech

Language

  • Bing Spell Check
    • スペルチェック、および、是正をしてくれます。また、ちょっとした文字の欠損やスラングなども正しいものに変換してくれます。（注：2016年11月現在　日本語未対応）
  • Language Understanding Intelligent Service (LUIS)
    • 自然言語認識により、文章から文意やキーワードを抽出します。日本語対応。
    • 専用サイトが用意されています。
  • Linguistic Analysis
    • 自然言語解析により、文章の構造を解析してくれます。（注：2016年11月現在　日本語未対応）
  • Text Analytics
    • 言語判定：文章がどの言語かを判定してくれます。日本語対応。
    • キーフレーズ抽出：文章から主要ポイントとなるフレーズを抽出します。日本語対応。
    • トピック抽出：複数の文章から共通的に話題となっているフレーズを抽出します。
    • ポジネガ分析：文章の内容がポジティブなのかネガティブなのかを検証します。（注：2016年11月現在　日本語未対応）
  • Translator
  • Web Language Model
    • 文章から関連性の高いキーワードを抽出します。
    • ある単語に続く言葉を推測して返してくれます。
    • 単語間を適切にスペースで切ってくれます。

Knowledge

  • Academic Knowledge
  • Entity Linking
    • 文章中の文脈に応じて同一のキーワードであっても異なるエンティティにリンクをします。（注：2016年11月現在　日本語未対応）
  • Knowledge Exploration
    • 構造化データに対して自然言語でのインタラクティブな検索をできるよう支援します。
    • 別途、Knowledge Exploration Service SDKをダウンロードする必要有。
  • Recommendations
    • ユーザーの商品に対する評価データ、および、商品マスタをアップロードして、モデルを構築することでお手軽に商品レコメンデーションの機能を構築できます。

Search

  • Bing Autosuggest
    • 検索キーワード入力時の入力支援、または、関連ワードの推定をします。
  • Bing Image Search
    • 様々な検索パラメータを使用して、画像の検索を行えます。
  • Bing News Search
    • ニュース記事を検索します。
  • Bing Video Search
    • 様々な検索パラメータを使用して、動画の検索を行えます。
  • Bing Web Search
    • Web検索を行えます。

Microsoft Cognitive Servicesの始め方

下記サイトにて、使用したいAPIの無料版（Try for Free）、または、有料版（Buy on Azure）のボタンを押下し、手続きを行ってください。（有料版の使用にはAzureのサブスクリプションが必要です。）

https://www.microsoft.com/cognitive-services/en-us/pricing

Microsoft Cognitive Servicesを利用するプログラムサンプル

Microsoft Cognitive Servicesには豊富なSDKやサンプルコードが用意されています。下記サイトをご覧ください。

Microsoft Cognitive Services - SDKs & samples, https://www.microsoft.com/cognitive-services/en-us/SDK-Sample

また、最近は特にFaceなどのVision系サービスやLUISなどのLanguage系サービスをMicrosoft Bot Frameworkと連携して使用するのをよく見かけます。こちらについても下記サイトにサンプルコードがありますので、ぜひご覧ください。

Microsoft Tech Summit 2016 ~ Bot Framework と Cognitive Services による AI の民主化, https://blogs.msdn.microsoft.com/bluesky/2016/11/10/tech-summit-2016-bot-framework-cognitive-services-ai/

Tips

このセクションでは、Microsoft Cognitive ServicesのTipsを紹介します。SaaS型サービスであるが故、サービス自体の内部構造は意識せずにすみますが、使用するうちに細々とした疑問点が出てくるのではないでしょうか。そのような疑問点に少しでも応えることが目的です。 （注：本セクションは随時追加・更新します。）
  • Microsoft Cognitive Servicesはどこのデータセンターで動いているのか？
  • Face APIやCompute Vision APIなど、画像解析系のサービスに画像を入力（アップロード）すると、それらの画像はサーバ上にどの程度保管されるのか？
    • 通常、画像データはサーバ上に24時間残存した後、自動的に削除されます。ただし、例えばFace APIのFaceListなどアップロードされた画像を永続保管する機能もあります。なお、FaceListに関しては、登録画像の削除処理を実行すると、即座に画像は削除されます。
  • Face APIのVerificationについて、横顔の画像などはサポートされるのか？
    • Face Verificationのアルゴリズムは基本的に正面を向いた顔を前提とします。ただし、正面から30度ほど傾いた状態も検知可能です。従って、"横顔"の定義にもよりますが、いわゆる真横を向いた状態では顔として認識しない場合もあります。
  • Face APIのVerificationについて、同一人物の"真顔"とそれ以外の表情（例えば"力んだ顔"など）は正常にマッチングされるか？
    • 現在のアルゴリズムではそういったシナリオが確実に成功するか保証できないというのが実情です。こちらはユーザーサイドでサンプル画像等を用いて様々なパターンを試行されること推奨します。
  • Compute Vision APIのOCRはどういったところに記載された文字が前提となっているのか？
    • OCRは基本的に文書や書類に印字された文字を読むことを前提としています。これ以外の媒体に記載された文字に関しては読み込むことを保証できません。手書き文字に関しても保証はできません。

参考リンク

]]> Azure Backup https://docs.microsoft.com/archive/blogs/azure-sa-members/azure-backup Fri, 25 Nov 2016 13:29:07 GMT https://blogs.technet.microsoft.com/azure-sa-members/?p=875 Azure Backup の概要 Azure Backupとは、以下の対象データを、Azure ストレージにバックアップし、必要に応じて復元(リストア)することができるサービスです。
  • オンプレミスにある Windows Server や Windows クライアント 上のフォルダー・ファイル (※1)
    • サポート対象となるOSバージョンとエディションについては、Azure Backup FAQ をご参照ください。
  • オンプレミスにある Hyper-V / VMware上の仮想マシン
    • Hyper-V: Windows Server / Linux の仮想マシン
    • VMware 5.5 と 6.0 がサポート対象、Windows Server 仮想マシンのフォルダー・ファイル単位でのバックアップおよびリストアが可能
  • SharePoint / SQL Server / Exchange Server などの Microsoft アプリケーションのワークロード (※2)
  • System Center Data Protection Manager (DPM) を使用したワークロード
  • Azure 仮想マシン (Windows Server / Linux)
    • Windows Server が稼働する仮想マシンの場合、VSS での完全イメージバックアップが実行されます。
    • Linux 系サーバーが稼働する仮想マシンの場合、ファイル整合バックアップ(イメージバックアップ)のみの対応となります。
    • フォルダー・ファイル単位や特定アプリケーションの一部のリストア (プレビュー)
hybrid_azure-backup  

主な特徴と機能

■ ストレージ管理の自動化 オンプレミスのストレージ デバイスに対する設備投資は必要ありません。 Azure Backup は、保護対象のインスタンスの台数とデータ容量およびバックアップ容量に応じた従量制課金モデルとなり、バックアップ ストレージを自動的に割り当てて管理します。 ■ 無制限のスケーリング 保守と監視のオーバーヘッドなしに高可用性が保証されます。 Azure Backup は、基盤となる Azure クラウドの機能とスケールを使用して、非侵入型の自動スケール機能を提供します。 ■ 複数のストレージ オプション 必要に応じてバックアップ ストレージを選択できます。 ・ローカル冗長ストレージ(LRS) ブロック BLOB は、コスト意識の高いお客様に最適です。ローカル ハードウェアの障害からデータを保護するうえでも役立ちます。 ・geo レプリケーション ストレージ(GRS) ブロック BLOB は、ペアリングされているデータセンターに、さらに 3 つのコピーを提供します。この追加のコピーによって、Azure サイトレベルの障害が発生した場合でも、バックアップ データの高可用性を確保することができます。 ■ 無制限のデータ転送 転送する受信データまたは送信データのデータ量に制限はありません。また、Backup コンテナーからの復元操作時の出力 (送信) データ転送は無料です。 ただし、Azure Import/Exportサービスを使用して、大量のデータをインポートする場合は、受信データに対してコストが掛かりります。 ■ データの暗号化 AES256を使用したデータの暗号化によって、パブリック クラウドでの顧客データをHTTPS リンク経由で安全に送信および保存できます。 暗号化パスフレーズはソースに保存されます。転送されたり Azure に保存されたりすることはありません。 データを復元するには暗号化キーが必要です。お客様のみがサービス内のデータにフル アクセスできます。 ■ アプリケーションの整合性のバックアップ Windows でのアプリケーション整合性バックアップの場合、復元時に修正は不要であり、目標復旧時間が短縮されます。 ユーザーは迅速に実行状態に戻ることができます。 ■ 最大99年間の長期保存が可能 Azure にバックアップすると、ユーザーは、オフサイトのテープ バックアップ ソリューションに代価を払うよりも、低コストでテープの代替で短期および長期のデータ保存が可能となります。  

使用イメージ

オンプレミスのWindows Server / Windows クライアントに、Recovery Services エージェントをインストールして、フォルダー・ファイル単位のバックアップを簡単に取得することができます。バックアップは、即時実行することもできますし、バックアップスケジュールを設定することも可能です。 mab01 データの回復(復元)については、特定のフォルダー・ファイル単位で指定して、復元することが可能です。 mab02   また、Azure 仮想マシンのバックアップについては、Azure ポータルのVM管理ブレードからバックアップが実行できるようになりました。VM管理ブレードの[設定]から[バックアップ]をクリックして、資格情報コンテナーとバックアップポリシーを選択もしくは新規作成して、選択対象の仮想マシンのバックアップを有効化することができます。   バックアップポリシーについては、取得頻度・実行時間やデータ保持期間を細かく指定することができます。ちなみに、デフォルトのポリシー(DailyPolicy)設定では、180日間データを保持することになります。 ab_portal01  

ご参考

]]> Azure Security Center https://docs.microsoft.com/archive/blogs/azure-sa-members/azure-security-center Fri, 18 Nov 2016 11:20:07 GMT https://blogs.technet.microsoft.com/azure-sa-members/?p=665 Azure Security Centerはサブスクリプションやリソースグループ毎にセキュリティポリシー（防御ポリシー）の設定が可能です。 sec2 概要の画面では各リソースのセキュリティ状態を視覚的に把握して、脆弱性を素早く把握することができます。 sec3 セキュリティ対策推奨の優先事項があるので、優先度が高いものから先に対策することで素早くセキュリティを確保できます。 推奨事項のリスト https://azure.microsoft.com/ja-jp/documentation/articles/security-center-recommendations/ sec4 Azure Security Centerから各インスタンス（仮想マシン）にEndpoint Protectionなどをインストールも可能です。 sec5 パートナーとの連携も可能でセキュリティ対策の推奨から簡単にパートナーソリューションを展開しログも自動的に統合します。 sec6 F5のWAFのログも統合され、セキュリティセンター上で確認できます。 ◆検知と対策 Azure Security Centerではシグネチャベースのセキュリティ対策ではなく、ビッグデータ解析や機械学習を活用した高度な分析を採用しています。 アラートによって現在の攻撃を阻止し、将来の攻撃を防止する方法をが提示されます。 パートナーソリューションを含む様々なソースからデータを自動的に収集して、攻撃元や影響を受けたリソースを分析しながら 優先順位付きのセキュリティ インシデントやアラートを提供します。 こうした高度な検知には以下の３つの特徴（脅威インテリジェンス、行動分析、異常検出）があります。   ●脅威インテリジェンス グローバルな脅威インテリジェンスを活用して、既知の有害因子を探します。情報源としては、Microsoft の製品とサービス、Microsoft デジタル犯罪対策ユニット (DCU: Digital Crimes Unit)、Microsoft セキュリティ レスポンス センター (MSRC)、および外部フィードがあります。 脅威インテリジェンスのドキュメント例 ●行動分析 シグネチャベースではなく、ビックデータを利用した機械学習アルゴリズムでパターンを決定します、既知のパターンを適用することによって悪質な行動を検出します。 例：怪しいプロセスの検出など ●異常検出 統計プロファイルを使用して、過去の基準を構築します。確立された基準からの逸脱し、攻撃が疑われる場合、警告が生成されます。ユーザの固有の環境に依存します。 sec7 例：RDPによるブルートフォース攻撃 フュージョン キルチェーン全体にわたる各段階での攻撃をとらえて一つのインシデントとしてアラートを提示します。 関連リンク 検出機能 https://azure.microsoft.com/ja-jp/documentation/articles/security-center-detection-capabilities/ セキュリティアラートの種類 https://azure.microsoft.com/ja-jp/documentation/articles/security-center-alerts-type/   ◆連携・統合と可視化 AzureLogIntegrationを経由することでSIEMからほぼリアルタイムで、セキュリティデータにアクセスできます。 またAzure Security CenterをPowerBIと連携することでより視覚的にセキュリティ状態を把握することもできます。 sec8 PowerBIによる可視化の例 ■FAQ Q：Azure Security Centerが収集して使うデータは？ A：ネットワーク トラフィック、パートナー ソリューションのログ、仮想マシン、Azure SQL、Azure サービス Q：インスタンスのデータ収集はどうやって行っているのか A：Windows、Linuxともにそれぞれの監視エージェントがインスタンスにインストールされます。 https://azure.microsoft.com/ja-jp/documentation/articles/security-center-troubleshooting-guide/ Q：価格は？ A：こちらをご覧ください https://azure.microsoft.com/ja-jp/pricing/details/security-center/   ■最近のAzure Security Center のアップデート • 統合された脆弱性評価のプレビュー開始:  Qualys などのパートナーからの脆弱性評価ソリューションをデプロイできるようになりました • 拡張された Web アプリケーション ファイアウォール (WAF) 機能のプレビュー開始: パートナー WAF ソリューションの簡素化されたデプロイ、監視、およびアラートが、App Service Environments を使用する Azure App Service の Web Apps 機能で利用できるようになりました。 • Azure Storage セキュリティ評価のプレビュー予定: Security Center で、お客様が内蔵の暗号化をほんの数クリックで Storage アカウント用に有効化できるようになる予定です。 • 新しい検出の一般提供開始: 継続的なセキュリティ調査の結果として、行動分析によって部内者による脅威や侵害されたシステム内に留まろうとする試みを検出するための新しい分析が設計されました。また、Security Center でアウトバウンド DDoS 攻撃の有無がチェックされるようになったほか、総当たり攻撃の検出機能が強化されました。 • セキュリティ のプレビュー開始: インシデントはキル チェーン パターンに適合するアラートを組み合わせたものであり、複数の仮想マシンにまたがる攻撃キャンペーンに対する知見を得るのに役立ちます。ある仮想マシンで検出された悪意のあるアクティビティを 2 番目の仮想マシンでの類似したアクティビティと相関させることができるため、お客様は攻撃者が行った操作や影響を受けたリソースをすばやく見ることができます。 • 脅威インテリジェンス レポートのプレビュー開始: 脅威レポートが Security Center アラートに組み込まれたため、お客様は脆弱性の情報を脅威がアクティブな期間中に入手できるようになりました。攻撃者に関するインテリジェンス (戦術や目的を含む) は、お客様がインシデントへの対応と調査の目標を定めるのに役立ちます。   クラウドを守る、クラウドで守る： クラウドのセキュリティ対策に新たな選択肢――Azureリソースを監視し、不適切な構成を「見える化」して対応を促すMicrosoft Azureセキュリティセンター https://www.atmarkit.co.jp/ait/articles/1611/14/news006.html]]>