ainaba's blog https://docs.microsoft.com/archive/blogs/ainaba-csa/feed.xml Azure CSA のお仕事の中で良くあるお問い合わせやはまりポイントなどをまとめています。掲載内容は個人の見解であり、所属する企業を代表するものではありません。 Fri, 02 Mar 2018 13:53:22 GMT ja hourly 1 Azure でメールを受信するには https://docs.microsoft.com/archive/blogs/ainaba-csa/how-to-receive-email-by-azure Fri, 02 Mar 2018 22:53:22 GMT https://blogs.msdn.microsoft.com/ainaba-csa/?p=905 はじめに アプリケーションの利用者との追加のコミュニケーションチャネルとしてメールを使用することが良くあると思います。Azure の標準機能ではメールの送受信のサービスを提供していませんので、Office 365 等の外部メールサービスを別途利用する必要があります。しかし本格的なメールサービスを利用するのは大げさすぎるということであれば、 SendGrid を使用することで簡易的に実現することが可能です。SendGrid はその名前からメール送信用のサービスに見えるのですが、実は受信することも可能になっています。

アーキテクチャ

まずはメールの受信やアプリケーションに使用される独自ドメインが必要になります。Azure DNS でホストしていただくのがもちろん理想ですが、一般的な DNS サービスであれば問題ありません。次に SendGrid では Domain White Label および Inbound Parse と呼ばれる機能が提供されていますのでそちらを有効にします。最後に DNS サービス側でメールを受信したいドメインの MX レコードを mx.sendgrid.net に向けてやります。SendGrid の詳細な構築手順はこちらなどをご参照ください。 ここで注意したいのは、SendGrid はメールを受信してくれますが、メールボックスを提供しているわけではないということです。このため POP3 や IMAP 等のプロトコルを用いて取得できるわけでもありません。独自ドメイン宛てに送信されたメールは、MX レコードの記述に従って SendGrid サービスにリレーされるのですが、SendGrid は受信したメール情報を Webhook として指定した URL に送信してくるので、それを受け付けるアプリケーションを用意しておく必要があります。

Webhook を Functions で受け付ける

SendGrid の Inbound Parse Webhook はメールデータを multipart/form-data として HTTP で POST してきますので、それを受け付けるアプリを用意する必要があります。これ自体は Web アプリが作れる方であれば比較的容易に作成できると思いますが、任意の POST リクエストを受け付ける URL を用意するのはとても不安な気持ちになりますので、何らかの認証機構を持たせたいところです。ただ Inbound Parse の設定は下図のようにいたってシンプルで、認証するパラメータとして設定できそうなのは URL に含まれるクエリ文字列くらいしかありません。 というわけで以下の理由から Azure Functions の出番です。
  • アプリとしての機能自体はとてもシンプル
  • URL に埋め込んだ API キーを使用した認証機構も持っている
  • 出力バインディングが豊富に用意されているので後続の処理につなげやすい
  • メール受信頻度に合わせてスケールするサーバーレスモデルが選択可能
  • PaaS なので運用が楽、可用性も安心

C# Script のサンプル

HTTP Trigger を使用したデフォルトのテンプレートを若干カスタマイズしただけではありますが、以下にサンプルコードを公開しておきました。

https://github.com/ayuina/sendgrid-inbound-parse-by-functions

ポイントは HttpRequestMessage から ReadAsMultipartAsync メソッドを使用して MultipartMemoryStreamProvider クラスのオブジェクトを取り出すところになります。この Provider クラスを利用するとリクエストボディに含まれる各パートを１つ１つ処理することが出来ます。 またサンプルでは単にログ出力しているだけですが、“text” パートから本文を取り出して AI で解析、その結果を ”from” パートの送信元アドレスに自動応答するとか、いろいろ応用が考えられます。実際にどんな構成のメッセージが送信されてくるかはこちらに記載されていましたので、あわせてご参照ください。

備考

本ブログでは SendGrid を使用する方法を解説していますが、Azure にこだわらなければ Office 365 を使用する等の別の方法も当然ありえます。 また、以前から Azure 仮想マシンから SMTP 送信をすることはサポートされていなかったのですが、現在では一部の条件に合致するお客様は SMTP によるメール送信が制限される場合がありますのでご注意ください。]]> Azure 関連ポータルのまとめ https://docs.microsoft.com/archive/blogs/ainaba-csa/azure-related-portal-summary Fri, 05 Jan 2018 23:39:42 GMT https://blogs.msdn.microsoft.com/ainaba-csa/?p=815 はじめに Azure にはポータルがいくつか用意されており、その用途を理解して使い分けていただく必要があります。ただ適切に使い分けるためには Azure における管理概念の知識も必要になりますので、そちらも併せてご紹介したいと思います。

Azure の管理概念

Azure には ASM（v1, クラシック) と ARM (v2) と呼ばれる 2 つの管理方式がありますが、現在主流となっている後者の ARM : Azure Resource Manager では以下のような管理単位が存在します。 Azure で提供される IaaS や PaaS は Web App、データベース、ストレージ、ネットワーク、仮想マシン、といったようなリソース（ないしはその複合体）として提供されます。またこれらのリソースを束ねて管理するためのリソースグループという管理単位も存在します。 Azure のご利用を EA : Enterprise Agreement でご契約いただいた場合には、前述の「アカウント」より上位の管理単位が追加されます。

ポータルの種類と使い分け

以降では各管理単位の概要と、それらを管理するための利用するポータルについて紹介していきます。

Azure サブスクリプションの管理

Azure を初めて利用する（サインアップ）したユーザーはアカウント管理者となり、アカウントポータルにアクセスすることが可能になります。このポータルでは （Azure を使用したシステムの構築や管理ではなく）新規サブスクリプションの作成や停止、名前の変更、利用状況の管理、支払い方法の変更、サブスクリプションの譲渡、サービス管理者や共同管理者の任命といった管理操作が可能です。サービス管理者や共同管理者はアカウントポータルにはアクセスできません。あくまでもアカウント管理者専用のポータルになります。

Azure リソースの管理

アカウント管理者から任命されたサービス管理者や共同管理者は Azure ポータルにアクセスすることが出来るようになり、実際にリソースやリソースグループの管理操作を行います。 サブスクリプションに設定されたクォータの増加、利用可能リージョンの拡大、各種お問い合わせ、といった Azure サポートとの連絡もこのポータルから行うことが可能です。また Microsoft からの通知、障害時のアラートの確認でもこのポータルを利用します。

エンタープライズ加入契約の場合

加入契約の際に指定した管理ユーザーであるエンタープライズ管理者は EA ポータルにアクセスして、同じくエンタープライズ管理者の追加、部門作成およびその管理者の指定、アカウント作成およびその管理者の指定などを行うことが出来ます。ここで指定されたその他の各管理者も EA ポータルにアクセスできるようになり、エンタープライズ管理者の設定に応じて料金の確認等ができるようになります。 なおEA 契約の場合はアカウント管理者は自らサインアップするのではなく、上位の管理者から指定されることでアカウントポータルにアクセスできるようになります。また料金の支払いや利用状況に関しては EA 契約全体で取りまとめることになり、アカウントポータルでは支払い方法の変更などはできなくなります。

Azure Active Directory ユーザやアプリの管理

以前の記事で紹介したように Azure AD 上でのユーザーやアプリの管理に対しても Azure ポータルを使用します。Azure ポータルにサインインすると画面右上にユーザーが ID とアイコンが表示されるのですが、そちらをクリックするとその ID が所属するディレクトリ、ないしはアクセス可能なディレクトリが表示されます。ここでディレクトリを選択することで管理対象とする Azure AD を切り替えることができますので、左側のメニューから Azure Active Directory を選択するとユーザーやアプリの管理操作が可能です。 ポータルを共有していて、しかもどちらも名前に Azure と付くためするため若干（というかかなり）ややこしいのですが、Azure Active Directory は Microsoft Azure で提供されているサービスの１つ、ではなく、本来的には独立したサービスになります。Microsoft Azure のサブスクリプションは、その認証基盤として Azure Active Directory に依存しており、そこで認証された ID を元に RBAC による権限制御を行います。

アプリケーション利用者のためのポータル

Azure を管理するためのポータルとは若干異なりますが、Azure AD に登録されたユーザーは MyApps ポータルにアクセスできるようになります。 ユーザー自身が利用可能なアプリにアクセスするためのメニューとして、あるいは当該アプリを始めて利用する際に同意したアクセス許可の確認と削除に利用することが可能です。また自分のプロフィールの確認、所属するグループの管理、パスワードの変更なども行うことができます。

クラシックポータル

2014 年に ARM が登場する以前は ASM : Azure Service Manager と呼ばれるデプロイメントモードが使われており、ポータルも（Azure ポータルではなく）クラシックポータルが利用されていました。ARM が登場して区別のために明示的に ASM やクラシックと呼ぶようになったわけで、当時からこの名前で呼ばれていたわけでは無いですが。なお現在は ASM ではなく ARM の利用が推奨されており、本記事執筆時点で数日後にクラシックポータルは廃止予定ですのでご参考まで。

まとめ

以上で紹介した５つのポータルをまとめると以下のようになります。
ポータル URL 主なユーザー 主な用途
EA ポータル https://ea.azure.com Enterprise 契約の管理、部門・組織レベルでの Azure 利用を管理する立場の方、アカウントオーナー 部門やアカウントの作成、およびその管理者の任命、全体の利用状況の管理など
アカウントポータル https://account.azure.com アカウントオーナー（サブスクリプションの所有者） サブスクリプションの作成、停止、サービス管理者の任命、課金や支払い方法の管理など
Azure ポータル https://potal.azure.com サービス管理者、共同管理者、RBAC によってアクセス権を与えられた開発者 Azure で提供される IaaS/PaaS を利用するシステム・サービスの構築、監視、運用など Azure AD 上のユーザーやアプリの管理操作など
クラシックポータル https://manage.windowsazure.com サービス管理者、共同管理者 （廃止予定）
MyApps ポータル https://myapps.microsoft.com Azure AD で認証を受ける全てのユーザー ユーザー自身のパスワード管理、利用可能なアプリケーションの管理

参考情報

]]> Azure Web App のユーザー認証を Azure AD B2C で行うために https://docs.microsoft.com/archive/blogs/ainaba-csa/azure-web-app-authn-by-aadb2c Fri, 05 Jan 2018 12:06:39 GMT https://blogs.msdn.microsoft.com/ainaba-csa/?p=786 はじめに 以前の記事では組織内で利用するアプリケーションを Web App でホストし、 Azure Active Directory で認証する方法を紹介しましたが、コンシューマーユーザーに対して Azure Active Directory B2C を使用して認証をさせることも可能です。通常の Azure AD と同じように B2C テナントにもローカルユーザーを登録することもできますし、Facebook ID、Microsoft Account、Google ID といったような代表的なソーシャル ID プロバイダーにユーザーを認証してもらうことも可能です。

構成手順の概要

Web App 側の構成方法は通常の Azure AD テナントの場合とほとんど同じですが、簡易モードではなく詳細モードを使用する必要があります。詳細モードで登録する情報は Azure AD B2C テナントでアプリケーション登録をして「アプリケーション ID」を取得、サインインポリシーを作成して認証用のエンドポイント URL を取得します。アプリケーション登録の際に Web App 側でトークンを受け取るためのコールバック用 URL を提供する必要がある点は同じです。

留意事項

上述のように Web App 側では認証プロバイダーが通常の Azure AD なのか Azure AD B2C なのかを意識することはほぼありません。ただ  B2C 用のテナントは通常の Azure AD テナントとは異なります。
  • 組織用の Azure AD テナントは別に B2C 用のテナントを作成する必要がある
  • 登録したアプリケーションごとに認証ポリシーを設定することができる
  • 各ポリシーごとに認証を委託する ID プロバイダーや収集するユーザー属性を指定することができる
  • Etc…
これらの設定変更は全て B2C 側の問題ですので、 Web App 側では考慮する必要がありませんが、属性情報等を利用するアプリケーションを開発する場合にはご注意ください。

参考情報

Active Directory B2C のドキュメント App Service Auth and Azure AD B2C]]> Azure AD で認証された Web App のアクセス制御 https://docs.microsoft.com/archive/blogs/ainaba-csa/access-control-for-webapp-secured-by-aad Fri, 05 Jan 2018 10:48:08 GMT https://blogs.msdn.microsoft.com/ainaba-csa/?p=725 はじめに こちらの記事では Azure Web App を利用するユーザーを Azure AD で認証するように構成しましたが、このままではテナントに登録されている全てのユーザーがアクセス可能な状態です。同一組織に所属する全てのユーザーが使えるシステムというのも無いわけではないですが、特に業務系のシステムでは「特定のユーザーのみに利用を制限する」、さらには「ユーザーの属性情報を元にアプリの挙動を変える」といった要件もあると思います。 本記事では前回書ききれなかった内容について紹介したいと思います。

特定のユーザーのみにアクセスを制限する

ユーザーに対するアクセス制限を行うためには、 Azure AD 側でアプリケーションに対して「ユーザーの割り当て」を設定します。この設定により、割り当てられた特定のユーザーに対してのみ当該アプリケーション向けのトークンが発行されるようになります。 既定ではAzure AD に登録されたアプリケーションはユーザーの割り当てが不要になっており、同じテナントに所属する全てのユーザーが利用可能な状態になっていますので、まずこの設定を変更します。以下のようにアプリケーションのプロパティ画面で「ユーザーの割り当てが必要ですか？」を「はい」に切り替え、次に当該アプリケーションに割り当てるユーザーを追加していきます。 この状態でアプリケーションにアクセスすると、割り当てられたユーザーでサインインすると正常にアクセスできますが、割り当てられていないユーザーでサインインした場合にはアクセスが拒否されることが確認できます。

アプリケーションでユーザー情報を利用する

Azure Web App に配置されたアプリケーションは、フロントエンドで認証されたユーザーのリクエストのみを受信します。この際フロントエンド側は「X-MS-*」というプレフィックスが付いたいくつかのカスタム HTTP ヘッダーを付与してくれますので、アプリケーション側ではこれを解析することで認証情報を利用することが可能です。

ヘッダー情報の確認

実際に送信されてくるヘッダー情報を確認するには、アプリケーション側で画面に表示させてしまうのが簡単でしょう。例えば以下のような aspx ないしは php ファイルを Web App に配置することで、アプリケーションが実際に受け取った HTTP ヘッダーを確認することが可能です。 
<!-- aspx file -->
<%@ Page Trace="true" %>

<!-- php file -->
<?php phpinfo(); ?>
あわせて Web ブラウザーのデバッガー機能を使用してネットワーク通信の内容も確認すると、ブラウザーからは X-MS-* という名前のヘッダーが送信されていないことが分かります。Azure AD から受け取ったトークン自体は Web App がセッション情報として管理しており、リクエストを受け取った際に X-MS-* ヘッダーに展開してアプリケーションに送信します。Web ブラウザーは Cookie を使用して認証セッションを維持していることになります。 X-MS-CLIENT-PRINCIPAL- から始まるヘッダー情報からユーザー ID が取得できますので、これをキーとしてユーザーのプロファイル DB を構築したり、条件分岐することで挙動を変えることが可能かと思います。

トークンの中身

ただヘッダーだけではやはり内容に乏しくイマイチ使い勝手が良くありません。では X-MS-TOKEN-AAD- から始まるヘッダー情報には何が入っているのでしょうか。以下のサイトで JSON Web Token のデバッガーが提供されていますので、こちらに「X-MS-TOKEN-AAD-ID-TOKEN」の値を入力すると中身を確認することができます。 https://jwt.io/ 多少はマシになりましたが、これだけでは「ようこそ XXX さん！」の表示くらいにしか使えなさそうですね・・・。これ以上の詳細なユーザー情報を取得するためには Graph API などを使用する必要がありますが、それはまた別途記事にしたいと思います。

参考情報

]]> 社内向け Web システムを Azure Web App でホストするためのユーザー認証 https://docs.microsoft.com/archive/blogs/ainaba-csa/user-authentication-for-internal-websystem-on-webapp Thu, 28 Dec 2017 12:00:54 GMT https://blogs.msdn.microsoft.com/ainaba-csa/?p=575 はじめに 現在社内で利用されている Web システムを Azure Web App に移行したい、というご相談を良くいただくのですが、多くの場合は以下の理由によるようです。
  • PaaS を利用することで保守・運用コストを抑えたい
  • ワークスタイル改善のためにモバイル対応したい
一般的に社内システムは営業日の業務時間中に使用されるため、全体の運用時間から考えるとリソースの利用率が低くなりがちです。このためスケールアウト／スケールインが容易でコスト効率の良い Web Apps は適切なソリューションであると考えます。また Web Apps は基本的にパブリックインターネットに公開された Web サイトですので、インフラという面でも既に整っているといえます。あとはアプリケーションやコンテンツがユーザーのモバイルデバイスに対応していれば良いだけです。 一方で二の足を踏まれるお客様も多く、その理由は多くの場合セキュリティです。Web Apps で考慮すべきセキュリティオプションは多岐にわたりますが、本記事では社内システム構築においては確実に必要となる、「ユーザーの認証と認可」についてご紹介したいと思います。

ID 管理とユーザー認証

多くの場合「社内向けのシステム」を利用するユーザーは同一組織に属し、そのユーザー ID は何らかの ID 管理システム上で管理・運用がなされていると思います。これは従来から Windows プラットフォームをご利用いただいていた場合には AD : Active Directory が該当します。イントラネットからの利用を想定した Web サーバーであればユーザー認証を AD に任せることで「社内向けシステム」としては必要な認証を行うことが出来るわけです。 ただ、ほとんどの組織・企業においてはインターネット環境で同様の方式を利用することができないと思います。このようなケースにではインターネットで利用できる ID 管理および認証サービスとして Azure Active Directory がご利用いただけます。Azure AD はそれ単独で利用することもできますが、社内に設置された AD と ID 情報を同期したり、認証をフェデレーションすることも可能です。社内 AD と連携した Azure AD に対して認証処理を委託することで、「社員しか利用できないインターネット Web システム」を構築することができるわけです。

Azure Active Directory を使用した認証

Azure AD を利用してユーザー認証を行うためには以下の 2 つの方法があります。
  • 任意の Web サーバー上で動作するアプリケーションから利用する
  • Web Apps 自体に搭載された認証機能（EasyAuth）を利用する
前者（図中右側）の場合、アプリケーション自体が Azure AD が対応する認証プロトコルを使用することで認証を実現します。この方式ではアプリケーション自体が動作するプラットフォームに非依存になりますが、各アプリケーション開発言語用の認証ミドルウェアや SDK を準備、設定し、コーディングするといった手間が発生します。 後者（図中左側）の場合は Web App や Azure AD の構成設定のみで、つまりノンコーディングで認証を有効にできますので非常に簡単です。ただしアプリケーションとしては Web Apps 上で動作するときだけ認証が効くことになりますので、開発中やテスト中に若干の工夫が必要になります。以降では簡単に構成可能な後者の方をご紹介します。

Web App が Azure AD で認証する際の挙動

Web App が Azure AD の認証を使用した際の挙動は以下のようになります。従来から良く利用されていた Cookie ベースのフォーム認証画面が外部サイトになったもの、と考えるとわかりやすいと思います（技術的には異なります）。
  1. ユーザー（ブラウザー）が Web App にアクセス
  2. ユーザーが認証されてないので Azure AD の認証画面へリダイレクト
  3. ユーザーが ID とパスワード等を入力し、認証に成功したら再度 Web App にリダイレクト
  4. 今度はユーザーが認証済みであるため、Web App はアプリケーションにリクエストを通す

Web App の Azure AD 認証を構成する

前述のような挙動を行わせるためには Azure AD と Web App の双方で設定情報の交換を行います。実際に設定を行う際には Web App と Azure AD 双方の設定画面を行ったり来たりする必要があり、若干混乱しやすいのでご注意ください。
  • Azure AD 側で必要な情報
    • 認証の委託を受ける Web App の登録
    • 認証が成功した後にその結果を渡す宛先
  • Web App 側で必要な情報
    • 認証を委託する先となる Azure ADの テナント
    • Azure AD に登録された Web Apps を表す ID

[Step 1] Web App を作成する

まず Azure Web App を作成します。この段階ではまだ認証を設定していないので、URL にアクセスすると既定のページが表示されることが確認できます。この URL は Azure AD 側でアプリケーション登録する際に使用するので控えておきます。

[Step 2] Azure AD 側 でユーザー認証を行う Web App を登録する

次に Azure ポータルの右上の方で認証したいユーザーが登録されている Azure AD テナントを選択し、左側のメニューから「Azure Active Directory」を選択し、プロパティ画面にて「ディレクトリ ID」を控えます。 そして「アプリの登録」からアプリケーション情報の登録を行います。「名前」は Azure AD テナントへの登録名ですので、一意でかつ分かりやすい名前を付けてください。「サインオン URL」には先ほど作成した Web App の URL を入力します。 登録が終わると「アプリの登録」画面に表示されますので、そこをクリックして「アプリケーション ID」を控えておきます。また登録されたアプリのプロパティとして「ホームページURL」として Web App の URL を入力しておいてください。「応答 URL」には Web App の URL がそのまま入力されているので、プロトコルを HTTPS に変更し、パスに「 /.auth/login/aad/callback 」を追加します。

[Step3] Web App 側でユーザー認証をAzure AD に委託する

始めに作成しておいた Web App を表示し、「認証/承認」を選択します。App Service 認証を「オン」に設定し、未認証状態のリクエストに対して「Azure Active Directory でのログイン」を要求するように指定します。認証プロバイダーとして「Azure Active Directory」を選択、設定情報として先ほどアプリケーション登録を行った際の内容を入力します。
  • 「管理モード」は「詳細」を選択
  • 「クライアントID」には Azure AD で発行された「アプリケーション ID 」を入力
  • 「発行者の URL」には「https://login.microsoftonline.com/ディレクトリID」を入力

Azure AD テナントを表す「ディレクトリ ID」と、そこに登録されたアプリケーションを表す「アプリケーション ID」を指定することで、Web App 側から認証を委託する先を一意に決めることが出来るわけです。この情報を元に未認証のユーザーに対しては「アクセスする前に指定のディレクトリでアプリに対してアクセス許可を持っていることを証明するトークンを持ってこい」と言って門前払いリダイレクトすることになるわけです。つまり本来はユーザー認証ではなく「認可」というのが正確な表現なのでしょうが、この記事では通りの良い（？）認証と表現しています。

[Step 4] ユーザー認証が動作していることを確認する

ここまで設定した状態で作成した Web App にアクセスすると、未認証状態では自動的に Azure AD のログイン画面にリダイレクトされることが確認できます。Azure ポータルを操作していたものと同じ Web ブラウザを使用すると認証情報のキャッシュによって自動的にログインしてしまうことがあり、挙動が分かりにくいことがありますので、InPrivate ブラウズ機能や別の Web ブラウザを使用することをお勧めします。

簡易モード vs 詳細モード

Step 3 にて管理モードとして「詳細」を選択しましたが、実はここで「簡易」を選択すると Step 2 に相当する設定を自動的に行ってくれますので、その場合 Step 2 の作業は不要です。ただ簡易モードでの設定を行うためには以下の 2 つが前提条件となるため、環境によっては利用できないケースもあります。
  • Azure Web App が認証に使用している Azure AD テナントと、ユーザー認証に使用する Azure AD テナントが同一であること
  • Azure AD テナントの設定として「ユーザーはアプリケーションを登録できる」ように設定されていること

異なる AAD テナントを使用したユーザー認証

例えば Web アプリの開発側と利用者が別の組織に所属しているようなケースでは、開発者の ID 管理とアプリ利用者の ID 管理が独立しているケースが考えられます。また同一の組織に所属している場合でも、開発者と利用者の ID を管理するテナントをAzure のサブスクリプション管理に利用せず、異なるテナントないしはマイクロソフトアカウントを利用しているケースも多くあります。簡易モードではユーザー認証に使用するテナントを選択することができないため、このようなケースでは Azure AD 側の設定と Web App 側の設定を独立して実施せざるを得ず、詳細モードが必要になります。

ユーザー認証のためにアプリ登録を代行する

比較的大きな組織では Azure 上でアプリケーション開発するチームと、組織ユーザーの ID を管理チームが独立していることが多いと思います。このようなケースでは Azure AD の管理権限を持って保守・運用を行うのはID 管理チームになり、アプリ開発者はたとえ「Azure の管理者」であってとしても「Azure AD 上では一般のユーザー」でしかないことになります。 組織のセキュリティポリシーによっては 、一般ユーザーに対してアプリケーション登録権限が解放されていないことがあり、その場合には ID 管理チームに Azure AD に対するアプリケーション登録を代行してもらわざるを得ません。その際には開発側からは Step 2 で設定したような Web App の情報を引き渡し、Step 3 で使用するテナント ID やアプリケーション ID を教えてもらう必要があります。よってこのようなケースでも詳細モードによる設定が必要になってきます。 なおユーザーがアプリケーション登録の権限を持っていない状態で簡易モードでの構成を行うと、以下のようなエラーが発生して構成に失敗します。。

代行って面倒ですよね

Azure AD のデフォルト設定では「ユーザーはアプリケーションを登録できる」ようになっています。逆に言えばこれが出来ないということは、組織側のセキュリティポリシー等に抵触するためあえて設定が変更されている可能性があります。一方でアプリケーションにとっては組織が運営する正規の Azure AD テナントでユーザー認証ができないと、ID 管理や認証の基盤が別途必要になってしまうことになり、これはこれでセキュリティやガバナンスの観点から問題と言えます。となると前述の「登録代行」のような申請ワークフローが組織的に必要になってくると思いますが、これはこれで手間も時間もかかりますので、既定の設定である「ユーザーはアプリケーションを登録できる」ようにしていただくことをお勧めします。

まとめ

簡易モードでも詳細モードでも Azure Web App に Azure AD 認証を組み込むのはそれほど難しくはないのですが、開発者はある程度 Azure AD 側での設定も理解しておいた方がいろいろと応用が利きますので、本記事ではあえて比較的「面倒な」手順でもある詳細モードを中心に紹介してみました。

参考情報

Azure Active Directory ログインを使用するよう App Service アプリを構成する]]> 利用中の Azure 仮想ネットワークを変更する https://docs.microsoft.com/archive/blogs/ainaba-csa/change-azure-vnet-configuration Fri, 16 Jun 2017 17:44:05 GMT https://blogs.msdn.microsoft.com/ainaba-csa/?p=436 はじめに Azure 上で IaaS ベースのシステムを構築・運用されているお客様から「既に仮想マシンが配置されている仮想ネットワークのアドレスを変更したいんだけどどうすればいいの？」というご質問をたまにいただきます。そのご質問の背景として代表的なものは以下のようなものが挙げられます。
  • 仮想ネットワークを小さく（あるいはサブネットを大きく）作りすぎて、新しいサブネットが追加できなくなった
  • サブネットを小さく作りすぎて、内部に配置されている仮想マシンがスケールアウト出来なくなった
  • 接続したい別のネットワーク（オンプレミスや別の仮想ネットワーク）とアドレスレンジが衝突してしまった
仮想ネットワークのアドレス計画は慎重に、といった注意喚起をすることが本ブログの趣旨ではありません。もちろん計画的であるにこしたことはありませんが、構築段階でうっかりこのような状況に陥ってしまうことは私の実体験としても良くあります。以降ではある程度構築が進んでしまったシステムのネットワーク構成変更における TIPS をご紹介したいと思います。

出来ること出来ないこと

Azure 仮想ネットワークは SDN らしく構成に柔軟性がありますが、仮想マシンが配置されていると変更にいろいろと制約が出てきます。その最たるものがこちらの FAQ にあるように “仮想マシンが配置されているサブネットは変更・削除が出来ない” になります。しかし裏を返せば以下の変更は可能であるということになります。
  • 仮想マシンが配置されていないサブネットであれば、他のサブネットと重複しない限り、アドレス範囲の変更や削除が可能
  • 仮想ネットワーク全体に対しては、既存のサブネットのアドレス範囲を含んでいる限り、アドレス空間の拡張や追加が可能
  • 仮想ネットワーク内に空いているアドレス空間があれば、新規のサブネットを追加することが可能
また再起動を伴いますが、仮想マシンを現在のサブネットから別のサブネットへ移動することが可能です。これらの操作を組み合わせることで理想的なネットワーク構成に修正していくことが出来るわけです。

サブネットを追加・削除する

まず簡単なところから行くと、仮想ネットワークのアドレス空間に空きがあれば、新規のサブネットを追加することは可能です。またサブネットに仮想マシンが配置されていなければ、サブネットのアドレス範囲の変更や、サブネット自体の削除も可能です。 Azure ポータルでサブネットの追加、削除、アドレス範囲の変更を行うためには、仮想ネットワークのサブネットブレードを使用します。ここでは割愛しますが PowerShell や CLI、ARM テンプレートから同様の操作を行う事も可能です。

仮想ネットワークのアドレス空間を拡張する

前述のような操作は仮想ネットワークのアドレス空間に余裕がある場合に可能ですが、もし足りないならば広げてしまえばよいわけです。アドレス空間が広がれば新規にサブネットを作成できるようになります。例えば下図はセキュリティ上やっぱり Web Application Firewall が必要になった、あるいは運用上 VPN 経由でのメンテナンスが必要になった、ということでサブネットを追加したイメージです。 Azure ポータルでアドレス空間を拡大するためには、仮想ネットワークのアドレス空間ブレードを使用します。ここでは割愛しますが PowerShell や CLI、ARM テンプレートから同様の操作を行う事も可能です。 あとは先ほどのようにサブネットを追加していけばよいわけです。

仮想ネットワークのアドレス空間を追加する

これはあまり知られていないかもしれませんが、仮想ネットワークは複数のアドレス空間を持つことが可能です。単にアドレス空間を広げてしまうと、接続先の他のネットワークと重複してしまうようなケースに有効です。こちらもアドレス空間が連続していないだけで考え方としては前述のものと同様です。

仮想マシンを別のサブネットに移動

他のネットワークと接続する必要が後から発覚したが、初期の構築段階では予定が無かったためアドレス空間が重複してしまっていた、ということもありました。どちらか一方のアドレス空間およびサブネットを重複しないものに切り替えてやる必要があるわけですが、各サブネットは仮想マシンがデプロイされているため変更ができません。またそのサブネットを含む仮想ネットワークのアドレス空間も変えることができません。このような場合には以下のステップで変更していきます。
  • 既存と同じ広さを持つ新規のアドレス空間およびサブネットを追加する
  • 仮想マシンを新しいサブネットに移動する
  • 従来から使っていたサブネットとアドレス空間を削除する
仮想ネットワークやサブネットの修正方法は既に紹介していますので、ここで必要なのは仮想マシンを別のサブネットに移動する方法です。仮想マシンが接続されているネットワークインターフェイスの IP 構成ブレードを開くことで、接続先のサブネットを切り替えることが可能です。 ドロップダウンからサブネットを選択して保存ボタンを押した際に仮想マシンが起動していると、自動的にシャットダウンされサブネットが変更されたのちに再起動が行われます。改めて DHCP によって異なる IP アドレスが割り当てられることになりますので、名前ではなく IP アドレスで通信しているシステムではご注意ください。

スクリプトで移動する

サブネット内に大量の仮想マシンがデプロイされている場合には 1 つずつ作業を行うのも大変ですので、スクリプト化して実行することをお勧めします。例えば Azure CLI を使用する場合には以下のような手順になります。 まず移動対象の仮想マシンの情報を取得し、 networkProfile セクションに記載されたネットワークインターフェイスの名前を確認します。 
$ az vm show --resource-group rgName --name vmName
次にネットワークインターフェイスに設定された IP 構成の名前を取得します。 
$ az network nic ip-config list --resource-group rgName --nic-name nicName
最後にネットワークインターフェイスの接続先サブネットを変更します。 
$ az network nic ip-config update --resource-group rgName --nic-name –name ipconfig1 --vnet-name vnetName --subnet NextSubnet
最後のコマンド実行時に仮想マシンが起動状態だと再起動が発生します。再起動にはそれなりに時間がかかりますので、多数の仮想マシンを移動するときには事前に全てシャットダウンしておくことをお勧めします。

サブネットを拡大・縮小する

こちらに関しては前述のように仮想マシンを別のサブネットに移動した後で、元のサブネットを拡大・縮小し、再度元のサブネットに移動すればよいわけです。仮想マシンが起動状態で行うと 2 回再起動が発生して時間がもったいないので、事前にシャットダウンしておくことをお勧めします。

まとめ

  • 仮想マシンが配置されているサブネットは変更ができませんが、仮想ネットワーク自体や仮想マシンが配置されてないサブネットの変更は柔軟です。
  • 仮想マシンのサブネット間移動と組み合わせることで、作ってしまった後からでもネットワーク構成の変更は可能です。
  • ネットワーク構成は計画的に、でも、やり直しはできますのでご安心ください。
]]> Azure 仮想マシンにおける可用性の考え方 https://docs.microsoft.com/archive/blogs/ainaba-csa/availability-of-azure-virtual-machines Wed, 31 May 2017 14:39:36 GMT https://blogs.msdn.microsoft.com/ainaba-csa/?p=335 はじめに 若干今更な感じもするタイトルではありますが、やはり Azure に初めて取り組む方にはわかりにくく、かつ重要視される部分でもありますので、改めてまとめてみたいと思います。「考え方」というタイトルの通り、本記事では技術的にはあまり深入りしないように、なるべく簡潔に記載していきたいと思います。さらに深く追求したい方向けは随所にリンクを貼っておきますので、そちらをご参照いただければと思います。 
2017-10-22 追記
本記事の執筆後にも Azure は進化を続けており、可用性ゾーンや計画メンテナンスにおけるセルフサービスといった機能追加や更新が行われました。このため本記事の内容は若干古くなっておりますが、現時点でも通用する内容だと思いますし、可用性に関して選択肢が増えた状況と考えます。特に可用性ゾーンのプレビューが取れある程度知見が得られた段階で本記事を修正するか、別記事を記載しようと思います。

仮想マシン単体レベルの可用性

まず初めに基礎として、1 台だけの仮想マシンで見た場合の可用性についてです。Azure 仮想マシンの可用性を考えるうえでは以下の 3 つの要素が重要です。
  • Compute　CPU やメモリが利用できる
  • Storage 　ディスクの読み書きができる
  • Network 　当該仮想マシンと通信することができる

ちなみにこの 3 つは仮想マシンの課金要素でもありますので、下記もご参照ください。 仮想マシンの課金の仕組み

Azure 仮想マシンは Windows Hyper-V をベースとした仮想化基盤上で動作します。Azure ポータルや PowerShell / CLI 等を利用して仮想マシンを作成すると、指定した Azure リージョンのどこかの仮想化基盤上に Compute と Storage リソースが確保され、仮想マシンとしての動作を開始します。この仮想マシンに対してネットワーク接続が可能であることによって、Azure の利用者はサービスを提供することができるわけです。 この仮想化基盤とその上で動作する仮想マシンはデータセンターのオペレーションチームによって監視・運用されています。例えばホストとなる物理サーバーに異常が検知された場合、その内容によっては再起動、あるいは他の健全な物理サーバーへの再デプロイが自動的に行われます。この仕組みは Service Healing と呼ばれ、これは全ての Azure 仮想マシンにおいて標準の機能になります。 サービスの復旧:仮想マシンの自動復旧のしくみ この際、仮想マシンとしても強制的に再起動が発生してしまいますので、一時的にサービスは中断されることになります。つまり Service Healing によるモニタリング間隔＋仮想マシンの起動＋α 程度のダウンタイムが発生します。ただし再起動先でも同一のOSディスクやデータディスクに接続されるため、そこに格納されたデータが失われることはありません。またネットワーク的にも同条件で再構成されるため、一定時間後には接続可能になりますので、利用を再開することができます。 これは言い換えれば、Azure 仮想マシンは“Active-Standby” 構成になっているかのように扱えることを意味します。また上の図では物理サーバーを2台しか記載していませんが、実際には Azure のデータセンターには仮想マシンをホストするための物理サーバーが多数配備されています。つまり 1 台の仮想マシンを作成するだけで、大量の待機系（占有ではありません）が準備されていることを意味します。以下に示される仮想マシンの利用料金には待機系を準備するコストも含まれていることになります。 Windows Virtual Machines の料金 Linux Virtual Machines の料金 なおディスクも内部的には多重化されており、仮想マシンからのすべての書き込みは３つの物理領域に書き込みが完了して初めて成功となります。これによってストレージユニットが物理的に破損した場合にも残りの 2 つからデータが復旧することが可能です。つまり最低でも 3 多重の RAID-1の構成になり、これを Azure では LRS ( Locally Redundant Storage ）と呼びます。 Azure Storage のレプリケーション ちなみに仮想マシンに接続されている全てのディスクが Premium Storage を使用している場合には、その可用性が Microsoft によって保証されています。 Virtual Machines の SLA

お約束とお願い

このように Service Healing と LRS という仕組みによって、単体構成であっても「それなりの」可用性が得られることが分かります。ここまでが Microsoft が 「Azure 仮想マシンの可用性」として提供している範囲になりますが、「サービスとしての可用性」を考えた場合には利用者側でも考慮が必要です。端的に言えば「OS 以上のソフトウェアスタック」が全て正常に動作していることは利用者側で保証する必要がある、ということになります。 このように利用者が構築するサービスは「Azure 仮想マシン」に対して直接的・間接的な依存性を持ちます。つまり利用者は Azure 仮想マシンの特性を理解し、それを考慮してOperating System、Middleware、Application を構成する必要があるわけです。すべての特性をここに列挙することは難しいのですが、代表的なものを以下にご紹介します。

意図しない再起動に備える

まず前述の通り、Azure 仮想マシンのホストで障害が発生する可能性はゼロではありません。その場合 Azure データセンターの運用としてはホストの再起動や切り離しが行われる可能性があります。そしてそれに伴う仮想マシンの強制的な再起動ないしは再デプロイが発生する可能性があります。この運用は高度に自動化されているため、たとえデータセンターの運用チームであってもイレギュラーな対応はできません。このためサービスとしての可用性を一定水準以上に維持するためには、仮想マシンが再起動後にアプリケーションが自動復旧して正常な運用状態に戻れるように設計・実装することを強くお勧めします。 再起動に強いシステムを構築することのメリットや考え方については下記が詳しいので是非ご一読ください 確実な再起動からはじめる クラウドネイティブオペレーション

大事なデータは永続化する

各仮想マシンには OS やデータ用のディスクとは別に、ホストとなるサーバーのストレージ上に配置された一時ディスクが１つ接続されています。つまり障害復旧のために仮想マシンが別のホストに再デプロイされてしまった場合には、ここに保存したデータは消えてしまうことになります。例えばアプリケーションなどがこの「一時ディスクに保存したデータ」に依存する作りになっていると、再デプロイ後に正常に稼働を再開することができないため、きわめて障害に弱いサービスになってしまいます。前述の通りストレージサービスに格納されるデータディスクは耐障害性が高いとともに永続性もありますので、重要なデータは必ずデータディスクに保存するようにしてください。 特に注意いただきたいのは既存のオンプレミス環境で動作していた Windows ベースのソフトウェアを Azure 仮想マシン上で動作させるケースです。Azure Marketplace の Windows ベースの 仮想マシンイメージはこの一時ディスクを D ドライブとして接続します。つまりソフトウェアが D ドライブへのファイル I/O に依存した作りになっていると、インストールすると動作はするが障害発生後に動かなくなる、という可能性が高くなります。たまに「I/O 先のパスがハードコードされていて設定変更できないソフトウェア」というものも存在しますので、ご注意ください。 ちなみに（ストレージではなく）仮想マシンの価格表に記載されている「ディスクサイズ」とはこの「揮発性のある一時ディスクのサイズ」を意味します。この一時ディスクは I/O 性能が高く、 VM 料金に含まれる（＝追加コストが発生しない）ため、つい使いたくなりますが上記の特性を鑑みてご利用ください。

大事なデータはバックアップを取る

前述の通りディスクは内部的にはレプリカがとられていますが、これとは別にバックアップは取るようにしてください。LRS はあくまでも物理障害に備えて Azure のインフラストラクチャとして耐障害性を持たせるためにレプリカが構成されるだけで、利用者が任意のタイミングで自由にアクセスできるレプリカではありません。利用者のオペレーションミス等によってデータを誤って更新や削除（いわゆる論理破壊）をしてしまった場合、それは物理的には正常なとして更新や削除として 3 箇所に永続化されます。このため「過去のレプリカからデータを復旧する」といったオペレーションは不可能ですので、サービスの品質や運用にかかわるような重要なデータは必ずバックアップを取るようにしてください。

複数台の仮想マシンで高可用性クラスタを構成する

単体レベルの可用性が「それなり」と記載しましたが、システムの要件によってはそれで十分である場合も、不十分である場合もあります。仮想マシン単体だけで考えた場合には、可用性を向上させるアプローチとしては Premium Storage 程度しか選択肢がありません。さらに高い可用性を追求する場合には、利用者自ら仮想マシンを並列化して１つの「クラスタ」を構成する必要があります。 可用性が a である仮想マシンを N 台用意してクラスタを構成した場合の、クラスタ全体で見た可用性の計算式は 1 – ( 1-a )^N となります。この計算式を基にいくつかのパターンで可用性を算出し、月間の想定ダウンタイム（分）で表したものが以下の表になります。これは1日24時間の稼働、1か月を30日として計算しています。

単一障害点の排除

シングルノード SLA に定義されている可用性（a=99.9%）では月間の想定ダウンタイムは 43.2 分です。仮に単体の可用性を低めに見積もって a = 95% とした場合、 1 台構成では月間で 2160 分（=36時間=1.5日）程度の非常に大きなダウンタイムを想定する必要があります。しかしこの仮想マシンでクラスタを構成した場合、2 ノードクラスタでは108分（＝1時間48分）、3ノードクラスタでは5.4分となり、シングルノード SLA を上回る可用性となります。このようにノード数を増やす効果は極めて高く、高可用性が求められるサービスでは、仮想マシン単体で考えるのではなく、クラスタ化を考慮してください。 前述の計算式が成り立つのは、各仮想マシン単体の可用性が独立している場合ですので、以下の 2 つが成り立つ必要があります。
  • 相互に依存性がない
  • 単一障害点を持たない
例えばサーバーAとBの2台があったとして、A が正常に稼働していないと B が正常に稼働できない場合、B は A に依存します。この場合の可用性の計算式は a^2 となり、 a < 1 ですから a^2 < a が成り立ち、2台並べることで可用性はむしろ劣化します。Azure の仮想マシンを 2 つ作成した場合、それだけで依存性を持つことはありませんので、この観点での考慮は不要です。 ネットワークや電源といった障害点をサーバ A と B が共有している場合、これらで障害が発生した場合 A と B は同時にダウンします。この場合の可用性は a となってしまいますので、可用性は全く向上していません。Azure 上で単純に複数の仮想マシンを作成すると、適宜空いている物理サーバーを探してデプロイが行われます。この時 Azure のインフラストラクチャはこれらの仮想マシンが「単一障害点を持つと問題があるか否か」を判断することができませんので、利用者側から明示的に指示してあげる必要があるわけです。 Azure インフラストラクチャに対して「これらの仮想サーバーは別々のラックにデプロイして、単一障害点を持たないようにしてね」と教えてあげるためのオプションを「可用性セット」と呼びます。可用性セットの詳細については下記等をご参照ください。 Windows VM 用の Azure 可用性セットのガイドライン Linux VM 用の Azure 可用性セットのガイドライン 可用性セットは障害に備えるだけではなく、通常運用におけるメンテナンスにおいても考慮されます。頻度は低いですが一部のメンテナンスは仮想マシンの再起動を伴う場合があります。クラスタを構成する複数の仮想マシンがメンテナンスによって同時に再起動が行われることが無いようにするためにも、可用性セットは重要になってきます。 Windows 仮想マシンの計画的なメンテナンス Linux 仮想マシンの計画的メンテナンス なお同一の可用性セットに複数台の仮想マシンを構成した場合には、それらの仮想マシンに対して SLA が適用されます。この場合には仮想マシンに接続されているディスクは必ずしも Premium Storage である必要はありません。 Virtual Machines の SLA

クラスタを意識したソフトウェア構成

ここまでが Microsoft が 「クラスタ構成における可用性」として提供している範囲になります。しかしこれは、可用性セットに複数の仮想マシンを含んでおけば最低 でも1 台以上が利用可能であるように管理・運用される、というものになります。クラスタレベルで「サービスとしての可用性」を考える場合にはこれだけでは十分ではなく、利用者側でもクラスタ化された仮想マシン上に配備されることを意識したソフトウェア構成を考慮する必要があります。

Web サーバーの場合

仮想マシンが Web アプリケーションや Web API を処理する Web サーバーの場合には、その上で動作するアプリケーションをステートレスに実装し、全てのサーバーに同じものを配置するのが一般的です。直接のリクエストは前段に配置した負荷分散装置で受け付け、処理を後段の Web サーバー群に振り分けます。負荷分散装置は Web サーバー群の正常性監視も行うことで、異常を検知した場合には処理を振り分けないようにすることでクラスタから切り離します。 Azure では Layer 4 の負荷分散としては Load Balancer を、あるいは Layer 7 の負荷分散として Application Gateway を利用することが出来ます。 Azure Load Balancer の概要 Application Gateway の概要

DB サーバーの場合

仮想マシンの役割が DB サーバーの場合には、多くの場合 DB ソフトウェアに対応したミドルウェアが必要となります。 例えば SQL Server で高可用性構成を構築する場合には、SQL Server Always On Availability Group を使用しますが、これは Windows Server の Failover Cluster 機能も併せて構成する必要があります。これらにより複数の DB サーバー間でデータ同期を取りつつ、主系および待機系の管理を行います。この場合も接続元となるクライアントからは前段に配置した Azure Load Balancer に対して接続し、その NAT 機能を利用してその時点での主系への透過的な接続を実現します。 Azure Virtual Machines での SQL Server Always On 可用性グループの概要

その他のクラスタ化オプション

Azure 仮想マシンによるクラスタを構築する場合には、前述のようなマニュアルにおる構成に以外にもいくつかの選択肢が存在します。いずれの場合も可用性セットやロードバランサーによるクラスタ構成が行われますが、利用者はその特性に合わせたアプリケーションを配置する必要があります。 Azure VM ScaleSets Azure Container Service Azure Service Fabric

面倒なら PaaS という選択肢

すべての PaaS サービスは既定で可用性が考慮された構成になっています。可用性以外も様々な非機能要件が組み込み済みのため、構築のコストやスピードという面では大きなメリットがあります。利用者に特有の要件が実装できないケースもありますので、単純に可用性の観点だけで選択することは難しいかもしれませんが、是非一度検討いただくことをお勧めします。 Azure PaaS Overview なお以下のような一部の PaaS サービスでは仮想マシンと同様に仮想ネットワーク上にデプロイするオプションも提供していますので、前述のクラスタと同様に扱うことが可能になっています。 App Service Environment Azure Batch Azure HDInsight

まとめ

  • Azure 仮想マシンは単体構成でも「それなり」の可用性は提供されています。
  • それ以上の可用性が必要な場合には複数の仮想マシンを利用したクラスタを構成してください。
  • いずれの場合にも仮想マシン上で動作するアプリケーション側での対応も重要になります。
 ]]> Azure App Service の自動スケールと負荷テスト https://docs.microsoft.com/archive/blogs/ainaba-csa/azure-app-service-auto-scale-and-load-test Mon, 03 Apr 2017 18:56:50 GMT https://blogs.msdn.microsoft.com/ainaba-csa/?p=216 はじめに クラウドの代表的なメリットの１つは、オンデマンドにリソースを確保することができ、その柔軟なスケーラビリティによって、ビジネスの状況に応じて必要かつ十分な処理能力を得られること、それによって単純なコスト削減だけではなく、コストが最適化できることであると考えます。私の日々のお仕事の中で Azure に関してお客様からご相談を頂くときは、Azure といえば PaaS、PaaS といえば Web Apps （App Service）、という話になることが大変多いです。これは App Service が最初に挙げた“クラウドのメリット” を最もわかりやすく体現しているからであると思いますし、非常にうれしい気持ちになります。本記事では App Service のスケーラビリティとその内部的な仕組みを概説し、負荷の増減に応じて自動的にスケールさせる方法、およびその挙動を検証する方法（ロードテスト）についてご紹介したいと思います。

スケーラビリティ

あらためてシステムにおけるスケーラビリティとは、簡単に言えば「利用量や仕事量の変化に対して適応できる能力」のことを意味し、多くの場合以下の 2 つの手法によって実現されます。
  • スケールアウト／スケールイン（水平スケーリング）
  • スケールアップ／スケールダウン（垂直スケーリング）
スケールアウト／スケールインとはサーバー台数を増やす（減らす）ことを意味します。スケールアップ／スケールダウンとはサーバーのスペックを大きくする（小さくする）ことを意味します。これによってシステム全体のキャパシティを調整することで状況の変化に対応するわけです。 scale-out-in-up-down 私はインフラエンジニアの経験がないのであくまでも想像ではありますが、物理サーバーであればその台数を増減させることは、設置場所、ネットワーク、調達等の関係からなかなか容易でないことは想像に難くありません。またマザーボードが保持する CPU やメモリのソケット数、ディスクを接続するインタフェース数の制限等から、スペックアップも限度がありそうです。もちろん仮想化技術が導入されている場合には柔軟性は高まりますが、やはり最終的には仮想マシンホスト、およびそのクラスタ全体のキャパシティに制約されます。 すなわちこういったスケール調整を実施するために、最初からそれを見越して余裕のある設計をするか、状況が変わったらそこから時間をかけて行う必要があるわけです。前者は余剰のコストが発生するリスクを、後者はビジネス機会の損失が発生するリスクをはらんでいることになります。

Azure App Service のアーキテクチャ

App Service の利用形態を非常に乱暴に説明すると、複数の利用者がフロントエンドのロードバランサを共有し、その背後で動作する Web サーバーのプールのなかから数台を占有する形になっています。 app-service-architecture 占有した Web サーバーに対してアプリケーションを配置しておくと、割り当てられた URL へのリクエストがあった際に、ロードバランサーがそのリクエストを各 Web サーバーに振り分けてくれます。この確保した Web サーバーのスペックと台数を表すリソースが、App Service プラン、そこにデプロイするアプリケーションの容れ物が Web Apps（ないしは API Apps、Mobile Apps 等）と呼ばれます webapps-on-app-service-plan Web Apps はそれが配置される App Service プランで確保される全ての Web サーバー上で同じように動作するように構成されています。このため App Service プランの設定を変更するだけで利用者が配置したアプリケーションのスケールアップ／ダウンや、スケールアウト／インを実現することが出来るわけです。

手動スケール

Azure ポータルで手動スケール操作は非常に簡単で、下記にあるように必要なサイズを選択するか、トラックバーでつまみをドラッグするだけです。 manual-scaling 前述の操作の結果、 Azure データセンターで事前に多数配備された空きノードのなかから割り当て（あるいは返却）が行われ、Web Apps の配置、およびロードバランサーの振り分け設定の変更が行われます。つまり前述の「余裕を持った設計とそれに伴う余剰のコスト」というリスクに関しては Azure がカバーしていることを意味します。より正確には利用者が支払う料金の中にそのリスクの担保が含まれていることになるわけですが、多数の利用者が共有して使用するマルチテナント方式のサービスであるため、1 利用者あたりの担保分を低く抑えることが出来る、と言えます。

留意事項

ただしスケーリングが容易とは言っても無制限に拡張できるわけではありませんのでご注意ください。スケールアウトの場合は Basic 、Standard、Premium といったプランに応じて、Web サーバーは最大 20 インスタンスまでという制限があります。ただしこれは複数の App Service プランを構築して、Traffic Manager 等でさらに上位レベルから負荷分散するという拡張策が可能ですので、それほど大きな制限にはならないかと考えます。一方スケールアップの場合には、最大でも CPU 4 コア と 7 GB RAM というのが各 Web サーバーの最大スペックになります。このため単一リクエストの中で大量のスレッドを消費する、メモリフットプリントが非常に大きい、といった特性を持つアプリケーションの場合には注意が必要です。 このように App Service はスケールアウト／イン方式の方が柔軟性が高いので、新規開発ないしは修正が可能なアプリケーションの場合には、この点を考慮したアーキテクチャを設計するように心がけていただくことをお勧めします。 ※ ここでは割愛していますが App Service Environment という形態をご利用いただくと最大スペックや最大インスタンス数は大きくなりますが、上限があるという意味では同じです。

コストを最適化するには

App Service の基本的な料金はユーザーアクセスの有無に関わらず App Service プランで選択したサイズの単価、インスタンスの台数、稼働時間で決まります。このためアクセスが無く暇な時に大きなインスタンスを大量に並べておけば無駄な料金が発生することになります。逆にアクセスが多く忙しい時にスペックや台数が不足すれば（安くはなりますが）過負荷状態に陥り、レスポンスタイムの長期化、スループットの低下、予期せぬエラーの発生といった問題が発生します。 状況の変動具合にもよりますが場合によっては「手動スケール」アプローチでは、設定変更が間に合わない可能性もありますし、そもそもそのオペレーションにかかる人的コストも馬鹿になりません。つまりコストを最適化するためには、状況の変化に応じて「自動スケール」する方式が望ましいといえます。

ここまでのまとめ

  • App Service はスケールアウト／イン方式によるスケーリングに対してより柔軟性が高い
  • コスト最適化のためにはスケーリングを自動化することが望ましい

自動スケール

前述のようなスケーリング操作を自動化するには大きく分けて 3 つの要素が必要になります。
  • キャパシティ不足ないしは余剰を検知するためのメトリック収集と監視
  • 上記のメトリクスに基づいた App Service プランの増強（縮小）方針
  • 実際のスケーリング作業
monitoring-and-scaling この中で最も重要かつ難しいのは「適切なメトリックの特定すること」であると考えます。これによってボトルネックの発生を検知し、またスケールアウトによってそれを緩和してやる必要があります。

ボトルネック発生を検知するには

本記事の執筆時点では、App Service は以下のメトリックに基づいた自動スケールアウト／スケールインを設定することが可能です。Web システムにおいてボトルネックを検知する上では代表的な指標値が提示されていると思いますが、これらのうち「どれが最も適切か？」はシステム特性によって大きく異なるという点にご留意ください。
  • App Service Plan のメトリック
    • CPU Percentage、Memory Percentage、Disk Queue Length、Http Queue Length、Data In、Data Out
  • ストレージキュー
    • Message Count
  • Service Bus キュー
    • Message Count
  • その他のリソース
    • 各種
例えば画像を取り扱うなどの I/O ヘビーなアプリケーションにおいては、高負荷状態になると I/O の待ちによってスループットやレスポンスタイムの悪化が発生することが予想されますが、そのような状況では CPU の使用率は低いままだったりします。当然ながらこういった特性を持つシステムでは App Service Plan の CPU Percentage というメトリックは「スケールアウトが必要な高負荷状態であること」や「スケールインが必要な余剰が発生している状態であること」を検知するためには全く役に立ちません。これを自動スケールの基準となるルールに設定すると、自動スケール機能が全く意味を為さないことになってしまうわけです。 ※ ここでは紹介していませんが時刻に応じたスケジュールベースでのスケールも可能です

システム特性の把握と自動スケールの検証

前述の通り自動スケールを有効に活用するには高負荷状態におけるシステム特性の把握が必須です。またその際に自動スケール設定が適切に機能するか否かを検証する必要があるでしょう。具体的にはスケールアウト時にレスポンスタイムやスループットといった性能の改善が見られ、かつスケールの基準として選択したメトリックも軽減されていることを確認する必要があります。最大限までスケールアウトした場合にどこまでの性能が出せるのか、すなわちシステムの限界値を見極めておく必要もあるでしょう。またスケールインした際には性能劣化等が無く、またエラーなどが発生しないことも重要になってきます。 このためには具体的に Web Apps に対して大量のリクエストを発生することで高負荷状態を意図的に発生させる、いわゆるロードテスト、ストレステスト、パフォーマンステストと呼ばれるようなテストを行います。伝統的には人海戦術による F5 連打という手法もありますが、Web Apps を高負荷状態に追い込むにはなかなか難しいでしょう。現実的には Web リクエストを機械的に大量生成するためのアプリケーションと、それを大規模に行うための大量のクライアントマシンが必要になります。 manual-load-test

Visual Studio Team Service によるロードテスト

負荷発生スクリプトを開発してマルチスレッドで駆動し、多数のクライアント PC や仮想マシンを準備して大規模な負荷を発生させる・・・、というアプローチもなかなかエンジニア魂をそそるものがありますが、ここもやはりクラウドサービスに頼っていただくことをお勧めします。Visual Studio Team Services （以下 VSTS）ではロードテストという機能が提供されており、以下のようなフレームワークが提供されています。
  • テストスクリプトの生成
  • 多数の負荷生成エージェントのセットアップと協調動作
  • テスト対象システムのメトリックの収集
loadtest-and-webapps

簡易的なロードテスト

ロードテストのセットアップは Azure ポータルから行うことが可能です。これによって実際には VSTS にロードテストの定義が作成されテストが実施されます。 load-test-from-azure-portal テスト定義に設定された負荷の大きさに応じて VSTS が自動的に多数の負荷生成マシン（Hosted Agent ）を用意し、それらを協調動作させることで大規模な負荷を生成させることができます。また作成されたテスト定義は再実行することが可能ですので、Web Apps やアプリケーションをチューニングして再テスト、といった一連の作業を行う上でも非常に便利です。

高度なロードテスト

Azure ポータルでロードテストを定義する際には以下のような簡易的なオプションしか設定できません。
  • 特定 URL への GET リクエストの生成、あるいは、Visual Studio Web テストに定義されたリクエスト群の生成
  • 特定ロケーション（米国東、米国西、北ヨーロッパ、東南アジア、東アジア、etc...）からのアクセス
  • 固定数の仮想ユーザーによる一定時間の負荷生成
ただし VSTS の画面でロードテストの定義を作成ないしは編集することで、以下のようなより高度なロードテストが可能です。
  • （Visual Studioを使用しない）Web テストの編集
  • 段階的に仮想ユーザー数を増加させるステップロード機能
  • 複数ブラウザーミックスによるアクセス
  • より多くのロケーションからのアクセス
  • 独自のマシンを使用したエージェント郡による負荷生成
例えば以下はステップロード機能を使用して段階的に Web Apps への負荷を増大させたロードテストの結果の画面になります。このテストによってシステムのボトルネック傾向、パフォーマンス上限値、また自動スケール時の挙動を確認することが可能です。 load-test-results ここまでの紹介した内容は Visual Studio Team Services というクラウドサービスを使用していますが、統合開発環境としての Visual Studio は必須ではありません。Web ブラウザーだけでもかなりの負荷テストを行うことができます。しかし Visual Studio が使用できるのであれば、単体テスト機能やロードテスト機能を組み合わせることで、カスタムのロジックを組み込んだ高度な負荷生成スクリプトを作成し、VSTS によって管理されるエージェントで実行させることも可能です。あるいはテスト結果をエクスポートして詳細な分析を Visual Studio IDE で実施することも可能です。ロードテスト機能を最大限に活かすのであれば、是非クラウドサービスと合わせて IDE の方もご利用いただければと思います。

ロードテストによる自動スケールの検証結果

自動スケールを定義する際にスケールアクションの通知として電子メールを設定しておくと、実際にスケールアウト／スケールインが行われた際に下記左図のようなメールが送信されます。 また VSTS からエクスポートしたテスト結果データ（右図）からも、Web Apps がスケールアウトしたタイミングでレスポンスタイムが改善し、スループットが増加していることがわかります。（この図は Visual Studio を使用してテストデータを CSV としてエクスポートし、Excel を使用して集計・加工しています） autoscale-notification-mail

まとめ

  • Azure App Service は水平スケーリング（スケールアウト／イン）が柔軟に行える
  • コスト最適化を追求するためには自動スケーリングが必須
  • 高負荷時のシステム特性を見極め、適切なメトリックを設定するためには負荷テストが必要
  • 大規模な負荷を生成させるためには Visual Studio Team Services のロードテスト機能が有効

参考情報

]]> Azure 仮想マシンで送受信するネットワークパケットをキャプチャする https://docs.microsoft.com/archive/blogs/ainaba-csa/capture-network-packet-from-to-azure-virtual-machine Mon, 06 Mar 2017 22:08:12 GMT https://blogs.msdn.microsoft.com/ainaba-csa/?p=175 はじめに Microsoft Azure の IaaS（というか 仮想マシン）を使用したシステムを構築する際に、最も頭を悩ませるのがネットワーク周りの設計です（個人の主観です）。ところが先日 Azure Network Watcher の Public Preview が開始されました。こちらを利用することでネットワークパケットキャプチャを取得し、仮想マシンが実際にどんな通信を行っているのか具体的に把握することが出来るようになります。というわけで本記事ではその利用イメージを紹介していきたいと思います。

取得編

パケットキャプチャを取得するために必要な作業は大まかに以下の4つですが、より詳細な手順に関してはこちらのドキュメントをご参照ください。なお 本記事の 執筆時点では Network Watcher が利用できるリージョンが限られているため、お試しいただく際には仮想マシンや仮想ネットワークを当該リージョンに指定する必要がありますのでご注意ください。
  1. Microsoft.Network リソースプロバイダーの Azure Network Watcher 機能を有効化する
  2. Azure Network Watcher を利用するサブスクリプションおよびリージョンを選択する
  3. キャプチャを取得したい仮想マシンに拡張機能「Network Watcher Agent for Windows/Linux」をインストールする
  4. Network Watcher に上記の仮想マシンをターゲットとするパケットキャプチャを追加する
追加したパケットキャプチャが「実行中」となっている間、当該仮想マシンで発生した送受信のログが拡張機能によって取得され、上記の手順４で指定した仮想マシンのローカルファイルとして、あるいはストレージアカウント上のBlobとして保存されます。 capture

解析編

確認したい通信が完了した頃合いを見計らってキャプチャを停止し、ストレージアカウント等に保存されたファイルを解析用の端末のダウンロードします。このファイルは拡張子 .cap のファイルになっており、Microsoft Message Analyzer や Wireshark 等で内容を確認することができます。下記は Microsoft Message Analyzerで実際にキャプチャファイルを読み込んだ画面です。 mma 中段左側に仮想マシン(10.0.0.4)と通信した相手先毎にグループ化されていますので、それらをドリルダウンしていくことで通信内容を確認することが出来ます。このあたりの解析作業などはオンプレミス環境で実際にネットワークに携わっていた方ならお手の物かと思います。 ちなみに上記は仮想マシンを作成しただけでほぼほったらかしの状態で取得したキャプチャなのですが、それでもいろいろと通信が行われていることがわかります。気持ち悪いですね。このうちのいくつかは Azure 仮想マシンを利用するうえで知っておかないと混乱の元になるものですので、いくつかご紹介したいと思います。

操作端末との通信

前述の図でフォーカスされている一番上のグループになるのですが、これは仮想マシンに SSH でログオンしている私の端末です。仮想マシンから見て通信相手の IP アドレスは私のオフィスからインターネットに出ていく際に通過するどこかのルーターアドレスになっていると思われます。当然この IP アドレスは環境次第で異なってくるわけですので、念のため自分の IP アドレスと突き合わせて確認します。方法はいろいろあると思いますが、私はこちらのサイトなどをよく利用します。

インフラストラクチャとの通信（168.63.129.16）

パケットキャプチャを見るとこちらのアドレスを用いて仮想マシンとインバウンド／アウトバウンド共に通信を行っているのがわかります。気持ち悪いですね。しかしこちらは仮想マシンが動作する上で絶対に必要な、Azure のインフラストラクチャとの通信になります。詳細は下記の Blog 等をご参照ください。 この IP アドレスは全リージョンで共通のものですので、どこに配置した仮想マシンでも同じような通信が発見されるはずです。このアドレスと通信をしていても問題はないですし、このアドレスとの通信は絶対に阻害しないようにお願いします。

メタデータサービスとの通信（169.254.169.254）

このアドレスはそのレンジからわかるように APIPA ( Automatic Private IP Addressing）によって割り当てられる IP アドレスのはずです。Azure の仮想マシンは 配置された仮想ネットワークから DHCP によってアドレスを割り当てられるはずなのに・・・、気持ち悪いですね。しかしこれはメタデータサービスとの通信のようです。これを利用することで仮想マシンは自分自身に関する情報を取得することができるんですね。 というわけでこのアドレスも問題なさそうです。実際にキャプチャを見ても全て仮想マシンから見たアウトバウンド通信で、そもそもこのアドレスはルーティングできないわけですから。

ストレージアカウントとの通信（blob.*.store.core.windows.net）

一部の相手先がいかにも Blob っぽい、しかしドキュメント等で記載されているアドレスフォーマット（accountname.blob.core.windows.net）と微妙に異なるものが表示されています。気持ち悪いですねえ。Azure 仮想マシンのディスクは Blob に保存されている VHD ファイルなのですが、これは仮想マシン内部からの通信ではないので、そのディスク I/O は仮想ネットワークを利用しません。しかしディスク以外の用途にも実はストレージアカウントが使用されています。
  • 仮想マシン内で動作するエージェントが仮想マシンの状態を記録
    • ディスク（.vhd）と一緒のストレージアカウントに 、JSON 形式のステータス（.status）ファイルが定期的に保存される
  • 各種の拡張機能が出力する情報
    • 仮想マシンの診断機能の構成時に指定したストレージアカウントに、イベントログ、IISログ、 パフォーマンスログ等の指定したログ情報が保存される
    • それ以外の拡張機能もストレージアカウントにデータを出力するケースが多い（今回のテーマである Network Watcher もその１つ）
ここで仮想マシンや拡張機能の構成時に指定したストレージアカウントの FQDN 名を nslookup で調べてみると、以下のような結果が返ってきます。ストレージアカウント作成時に指定した方の名前（accountname.blob.core.windows.net）はあくまでも CNAME レコードで指定されたエイリアスであり、ネットワークキャプチャで取得した名前が A レコードとして登録された実際の名前（blob.???????.store.core.windows.net）であることがわかります。 storage 仮想マシンや拡張機能の構成時に指定したストレージアカウント（意図した名前を持つ）の A レコードが、キャプチャで出てきた Blob っぽい奇妙な名前と一致するのが確認できれば、問題ないと言えるでしょう。

]]> EA 契約における Azure 使用状況と料金をタイムリーに把握しよう https://docs.microsoft.com/archive/blogs/ainaba-csa/azure-consumption-and-billing-on-enterprise-agreement Thu, 21 Jul 2016 23:54:09 GMT https://blogs.msdn.microsoft.com/ainaba-csa/?p=25 コンサルタントからクラウド・ソリューション・アーキテクト（CSA）と言うよくわからない職種にジョブチェンジして早8か月、 ちょっと Blog とかも書いてみようかと思い立ちました。というわけでここ最近よくご相談いただいた「EA 契約のサブスクリプションだと  Azure  ポータルから料金が見えないんだけど？！」というお話です。それほど目新しい話でも無いのですが、まとまった情報が少ないようなので簡単にまとめてみました。

はじめに

一般的な従量課金の場合には Azure ポータルから以下のように料金が把握できますし、Azure Resource Usage API および RateCard API を使用することで各リソースの詳細なデータを取得することができます。ただこの API 、困ったことに EA 契約の場合は使用量は取れるんですが料金が取れません。このため「今月使いすぎてるからちょっと抑えよう！」とかいう運用が難しいんですね。

[caption id="attachment_37" align="aligncenter" width="320"]payg 従量課金プランでは Azure ポータルで確認[/caption]

個人的にそこは気にせずジャブジャブ使っていただきたいとは思いますが、せっかく Azure を使ってくださっているユーザー様に無駄遣いさせるわけにもいきません。何らかの形で「タイムリーに料金を把握する」方法は必要なわけです。

方法は３つ

EA 契約において Azure 利用料および請求金額を把握する方法は大きく分けて以下の３つです。概要と参考情報を以下に紹介しておりますので、用途に合わせて使い分けていただければと思います。

  • EA ポータル
  • Power BI
  • レポート API

EA ポータルを使用する

EA 契約の場合には各契約ごとに必ず「エンタープライズ管理者」という役割の方がおり、この方は請求金額を把握することができます。エンタープライズ管理者が EA ポータル にログオンすると、以下のように EA 契約に含まれる各部署、各アカウント、各サブスクリプションの使用状況を料金とともに把握することが可能です。

[caption id="attachment_45" align="aligncenter" width="480"] EA ポータルで請求金額を確認[/caption]

しかしポータルで金額が確認できるのはエンタープライズ管理者だけです。このため「現在の自分の使用料が知りたい！」という一般ピープルはどうすればいいのでしょうか？まさか皆がエンタープライズ管理者になってしまうわけにもいきませんし。となると一般ピープルはエンタープライズ管理者を探し出し、EA ポータルにアクセスしてもらって、上記のページを印刷するかデータをダウンロードしてもらうことになります。エンタープライズ管理者は全てのサブスクリプションに対してこの作業を実施しなければいけないのでしょうか？しかも当初の目的からすれば”毎日”です。やってられませんね。

やはり EA ポータルの目的は「全体を俯瞰する立場の人」が総体の把握や今後の予測といった用途に使用するのが適切でしょう。
  • どの部門でどれだけ Azure が利用されているのか？
  • 前払いした残高はあとどれくらい残っているのか？
  • 今月はどのくらいの請求が来るのか？
  • 前払いのクレジットを追加購入する必要があるのか？

Microsoft Azure Enterprise content pack for Power BI を使用する

Power BI は様々なサービスが提供するデータを「コンテンツパック」と呼ばれる形式で取り揃えています。EA 契約における Azure の利用状況を可視化するためのコンテンツパックも用意されており、こちらを利用することでさらに高度な分析をグラフィカルに行うことが可能です。これは便利。

[caption id="attachment_55" align="aligncenter" width="480"]Power BI コンテンツパックで可視化 Power BI コンテンツパックで可視化[/caption]

利用方法の詳細に関してはこちらをごらんいただければと思いますが、大まかにいえば以下の ３ ステップです。

  1. 自身の ID でPower BI にログインする（これは Azure や EA と全く関係ない ID で大丈夫です）
  2. 「Microsoft Azure Enterprise」という名前のコンテンツパックを接続する
  3. 接続時に当該 EA 契約の情報に対する「アクセスキー」を入力する
このアクセスキーは EA ポータルで取得することができます。ですのでエンタープライズ管理者にこのキーを教えてもらう必要があります。これなら最初に 1 回連絡するだけですみますね。 [caption id="attachment_75" align="aligncenter" width="480"]get api access key EA ポータルで API アクセスキーを取得[/caption] ところでこのキーを入手した人は全ての部門、全てのアカウント、全てのサブスクリプションの状況を把握することが可能です。この「見えてしまう」こと自体が問題になるか否かは企業や組織のポリシーにもよるわけですが、怖いのはスコープの広さと、それによる漏えい時のインパクトの大きさです。というわけで アクセスキーの配布と Power BI を利用した分析も、以下のような用途で特定少数のユーザーに限るのが現実的ではないでしょうか。
  • 利用頻度の高いサービスを把握し、ノウハウの収集や技術トレーニングを重点的に行う
  • 請求金額の大きいサブスクリプションを把握し、コストダウン施策を立案する
  • リソースが多く配置されているリージョンに対して、接続性が良くなるようにネットワークを増強する

レポート API を利用する

レポート API を使用することで、前述の２つの方法で表示されていた「生のデータ」を機械的に取得することが可能です。実際に API を使用してある月の使用料を CSV 形式でダウンロードしたものを、みんな大好き Eｘcel で表示したものが下図になります。これをフィルターしたりピボットテーブルで集計したりは自由自在です。また CSV だけではなく JSON 形式でも取得可能ですので、ファイル出力前にアプリケーションで加工したいようなケースではそちらが便利かもしれません。

[caption id="attachment_65" align="aligncenter" width="480"]billing detail API でダウンロードした CSV データ[/caption]

レポート API を使用する方法はこちらが参考になるかと思います。 REST API なので比較的最近のプログラム言語であれば実装はそれほど難しくないでしょう。また実際に活用する上では詳細な API リファレンスが必要になりますが、そちらは EA ポータルの「ヘルプ」からもダウンロードすることが可能です。

[caption id="attachment_85" align="aligncenter" width="480"]get api reference API リファレンスの入手[/caption]

レポート API を呼び出す際には Power BI の場合と同様に「アクセスキー」を使用しますので、本質的には同じ問題をはらんでいます。しかし Power BI と異なるのは、以下のようなカスタマイズが容易なことです。

  • API なので機械的に実行することができる
  • ユーザーの目に触れる前に適切な状態に加工する
  • 適切なユーザーのみに必要最小限のデータを提示する
  • etc...
非常に簡単な例でいえば、以下のような機能を持つスクリプトを実装し、タスクスケジューラ等で定期的に実行してやればよいわけです。
  • レポート API を呼び出し CSV をダウンロード
  • 各レコードをサブスクリプション単位の別ファイルに分ける
  • アカウントオーナー ID （メールアドレス）宛てにメール送信する
または Web アプリとして実装するというのも良いでしょう。アカウントオーナーがログオンすると自身のアカウント配下のサブスクリプション情報だけが表示されるようにすればいいですね。アカウントオーナー ID は Microsoft アカウントか組織のアカウント（Azure AD）ですから、ログイン処理を作るのはそれほど難しくありませんし。そして Azure App Services 上で動かしていただければと思います。

まとめ

レポート API 以外には若干否定的なニュアンスが入ってしまいましたが、EA ポータルも Power BI も適切な使い方をすれば便利なツールであることは間違いありません。適材適所で使っていただければと思います。ただ私は元アプリ開発者だったせいか、API があれば叩いてみたくなる性でして、応用が効くものは大好物なんですね。というわけでこれ以降のブログもこのレポート API を使っていろいろ実験してみたいなーと思っていたりします。

]]>