御成門プログラマーの技術日記

Microsoft AzureやAngularなどの技術情報を発信します

Azure Functions に紐づくストレージの Microsoft Defender 適用について調べてみた【コスト、除外設定】

ある日 Azure Functions で使用しているストレージ(Web Job Storage?)のMicrosoft Defender for Storage のコストが思った以上にかかっていることに気づき、Microsoft Defender For Storage のコストや課金体系、必要性などを調べる機会があったのでまとめます。

Azure Functions に紐づくストレージの Microsoft Defender のコストが想像よりかかっていた

ある日ふと Azure Functions が入っているリソースグループのコストを確認したときに、Microsoft Defender のコスト比率がリソースグループ全体のコストの5割近く発生していることに気づきました。ちなみにAzure Portalのコスト分析上はMicrosoft Defender のコストは 旧名の「Advanced Threat Protection」で表記されています。

気になったので「Advanced Threat Protection」のリソースごとのコストを調べてみたところ、上位4リソースがストレージアカウント、特に1番コストがかかっているリソースが Azure Functions で WebJobStorage に設定しているストレージであることがわかりました

実際にファイルを格納しているストレージに課金が発生しているのはわかるのですが、Azure Functions の裏で使われているStorageが思ったよりコストがかかっていたので今回はAzure Functions で WebJobStorage に設定しているストレージにフォーカスして調べていこうと思います。

Azure Functions に紐づくストレージの Microsoft Defender は除外していいのか問題

まず、そこでまず誰もが簡単に思いつくのが、該当のストレージを Defender の対象から除外からしてしまえばいいんじゃないかというアイデア。ただしセキュリティ的にありなのか気になったのでMicrosoftのAzureサポートに問い合わせてみました。

  • Q「Azure Functionsの裏で動いているStorageにもDefenderの適用はした方がよいか?」
  • A 「要件や環境によって変わるので判断しかねる。ご自身で判断する必要があります」

予想通りではありましたが公式の回答は「自己責任でOFF」にしてねという回答でした。そのため、Microsoft Defender をOFFにする場合はそのリスクや必要性をしっかり調べた上、ご自身の責任で設定を行いましょう。今回のパターンではAzure Functionに紐づくStorageが外部からの脅威にされた場合どのような被害を調べる必要がありそうです。

Microsoft Defender for Storage の保護対象から除外する方法

自己責任での実施になりますが、Microsoft Defender for Storage の保護対象から ストレージアカウントを除外する方法があります。下記の公式ドキュメントで説明されていますが、要約すると除外したいリソースのタグに{"AzDefenderPlanAutoEnable":"off"} を設定してMicrosoft Defender for Storageを一度無効にして再度有効にするとMicrosoft Defender for Storage の保護対象から除外できます
docs.microsoft.com

Microsoft Defender for Storage の課金形態について調べてみた

保護対象から外すのが難しいとなると今度はコストがどのくらいかかるのか見積もりたくなりますよね。そのためにまずMicrosoft Defender for Storageの課金体験を調べてみました。Microsoft Defender for Storage の課金体系はトランザクション数による課金となります。
価格 — Microsoft Defender | Microsoft Azure
一般的にはトランザクション数はデータ量が大きくなれば、トランザクション数も増加しますが、その他の様々な要因によって増減するため、トランザクション数を見積もることは大変難しいですね。

Microsoft Defender for Storage の料金を見積もるには Price Estimation Dashboard 使用する

Microsoft Defenerの料金を見積もる方法を調べていたところ、Microsoft Defender for Storageの料金を見積もる「Price Estimation Dashboard」が用意されていることがわかりました。
Microsoft Defender for Storage - 利点と機能 | Microsoft Docs
「Price Estimation Dashboard」を使用するには Microsoft Defender for Cloud のポータル画面から「ブック」→「価格見積もり」→「Defender for Storage」から確認することができるようです。
上記のような画面で実際の使用量に基づく Defender の推定料金を計算してくれます。詳しくは下記ページに書いてありますのでご参照ください。
Microsoft Defender for Cloud Price Estimation Dashboard - Microsoft Tech Community
このように実際に使うことわかるものなのであらかじめトランザクション数を予想してコストを見積もることは難しいことがわかりました。

結論「除外は可能だが適用の有無は自己判断で!!基本的には除外しない方が良い」

今回、「Azure Functions に紐づくストレージに Microsoft Defender for Storage を適用すべきか」、「そもそも Microsoft Defender for Storage の課金の仕組みはどうなっているのか」調べてみましたが、Microsoft Defender を切っていいと明言できる根拠はみつかりませんでした。現在のところはOFFにすることはできるが、自己責任で行う必要があるということだけわかりました。今回の件に関しては、そもそもAzure Functionsのストレージの中身の仕組みを理解するところからする行う必要があると実感したところで次回の課題にしようと思います。

参考ページ

docs.microsoft.com

azure.microsoft.com

docs.microsoft.com

techcommunity.microsoft.com

docs.microsoft.com

Azure Storage の現在の使用容量を Azure Portal から確認する方法

Azure Storage でコストの見積もりなどをしたいときに現在のAzure Storageの容量の使用量を知りたいときがあると思います。そんなときにAzure Portal からストレージ使用容量を確認する方法を紹介します。

Azure Storage の容量の確認は Azure Storage のメトリックから確認可能

Azure Portal の容量を確認したい Azure Storage のページに移動します。
左のブレードから「監視」欄にある「メトリック」をクリックします。

メトリックの設定を次のように設定します。

名称 設定値
スコープ <容量を確認するストレージのスコープ>
メトリック名前空間 アカウント
メトリック Used capacity
集計 平均

メトリックを上記のように設定するとストレージが使用している容量を確認することができます。

ちなみにメトリックの情報は規定では30日しか保持されないので注意です。

それ以上保持したい場合は Log Analytics などの使用を検討しましょう。

参考ページ

www.sukerou.com

Azure App Service で Reserved Instance を使用してリソースコストを節約しよう【Reservations・予約割引】

Azure の Reservations(予約割引) とは。

Azure の Reservations(予約割引) とは、Azureのリソースに対して1年もしくは3年分の利用を確約することで、その期間のコストの割引を受けることができる機能です。現在、Azure VMやSQL DatabaseにAzure Blob Storage などなど様々なリソースに予約割引が適用可能になっています。割引率はリソースや契約期間によって変わりますが、最大で80%引きの割引を受けることができるリソースもあります
予約で購入したインスタンスのことを Reserved Instance(リザーブドインスタンス) と呼ぶため、この機能自体を Reserved Instance と呼ぶこともありますね。予約割引についての詳細は下記Microsoft公式ページをご覧ください。
Reservations | Microsoft Azure
もちろんメリット、デメリットはありますが、予約対象のリソースでこれからも永続的に使用する予定のリソースがある場合はReservations(予約割引)を適用した方がお得です

Azure App Service の予約割引について

Azure App Service では特定のインスタンスのみ予約割引に対応しています(2022年6月6日現在だと「Premium v3」および「Isolated v2」のみ)。Azure App Service はスケールアウトができますが、インスタンス停止による課金停止やインスタンス数を0にすることができず確実に1つ以上のインスタンスが建つと思うので対象のインスタンスを継続的に使用している方は予約購入おすすめです。
Azure App Service の予約割引 | Microsoft Docs

Azure App Service の予約割引購入条件

上記でも述べたとおり、Azure App Serviceの予約購入は2022年5月23日現在 App Service Plan の SKUが「Premium v3」および「Isolated v2」インスタンスである必要があります。また、購入にあたり、下記のような条件があります。

Premium v3 予約インスタンスの購入には、次の要件が適用されます。
・少なくとも 1 つの EA サブスクリプションまたは従量課金制料金のサブスクリプションの所有者ロールである必要があります。
・EA サブスクリプションの場合、EA ポータルで [予約インスタンスを追加します] を有効にする必要があります。 または、その設定が無効になっている場合は、ユーザーはサブスクリプションの EA 管理者である必要があります。 ダイレクト EA のお客様は、Azure portal で予約インスタンスの設定を更新できるようになりました。 [ポリシー] メニューに移動して、設定を変更します。
・クラウド ソリューション プロバイダー (CSP) プログラムの場合、管理エージェントまたはセールス エージェントのみが予約購入できます。

予約容量を利用して Azure App Service のコストを節約する | Microsoft Docs より引用
今回の環境はダイレクト EA なのでAzure Portalから予約インスタンスの設定が行えました。逆に私の場合、EAポータルには予約インスタンスの設定を行う箇所は見つかりませんでした。

Azure App Service で予約割引を適用する方法/実際に試してみた

さて、実際に予約購入を行う手順を紹介していきます。まず、Azure Portal の画面から「すべてのサービス」に移動し、検索ウィンドウで「予約」と入力します。「予約」というそのままの項目が出てくるのでクリックしましょう。

予約のページでは既存に購入した予約の一覧が表示されています。今回は新規で購入するので「追加」をクリックします。

予約購入できるリソースの種類が表示されます。Azure App Service や Azure VM だけでなく、様々な種類のリソースが対応していることがわかりますね。今回は「App Service」を選択します。

App Serviceを選択したら、「購入する製品の選択」ページへと遷移します。ここで一つ重要な要素に「スコープ」があります。スコープは今回購入した製品を共有する範囲のことで、選択肢は下記4点があります

  • 共有 - 課金コンテキスト内にある有効なサブスクリプションの一致するリソースに予約割引が適用される
  • 管理グループ(プレビュー) - 管理グループと課金スコープの両方の一部であるサブスクリプションの一覧にある一致するリソースに予約割引を適用
  • 単一のサブスクリプション - 選択されたサブスクリプションの一致するリソースに予約割引を適用します
  • 1つのリソースグループ - 選択されたリソース グループ内の一致するリソースにのみ、予約割引を適用

スコープによって予約割引が適用されるリソースの範囲が変わります。スコープは予約の購入後にも変更可能とのことです。
下の画面でスコープと課金サブスクリプションを選択すると、「推奨」のタブでは現状の使用状況に応じた予約割引の製品候補が表示されます。私が使用している環境ではすでにP3V3 App Service Planが動いていますので候補に表示されるようです。1から予約割引を購入したい場合は「すべての製品」タブから選択も可能です。

上記の製品一覧は名前は同じですが、大事な設定箇所が3か所「製品名」、「契約期間」、「請求頻度」があります。 これらの設定はコストに関わる大事な部分なので設定値をよく確認しておきます。

  • 製品名 - 予約割引が適用されるSKUです。こちらで選択したSKU以外を使用しているプランには割引が適用されません
  • 契約期間 - 契約期間です。一度購入した場合、基本的に契約期間分のコストを払う必要があります。契約期間が長くなると割引率が高くなります。
  • 請求頻度 - 請求頻度の違いです。App Service Planの場合、購入時に全額支払う「前払い」、毎月支払う「毎月」払いがあります。

また、↑の画像「推奨される数量」を確認する列にある「1 - 詳細を確認する」をクリックすると、対象 App Service Plan の現状のインスタンス使用率とコストと比較した予約割引を購入した場合の節約額のシミュレーションを行うことができます。

「数量による節約」タブでは予約購入数量ごとによる予想節約額が表示されます。今回の環境ではインスタンス数が1から3の間でスケールしていて、インスタンス数1だと効率的に節約できますが、それ以上を購入すると、無駄な予約インスタンスが発生してしまうため、節約額が減っていくということがわかります。

購入する「製品」が決まったら該当の製品を選択して「レビューと購入」タブに移動します。「請求頻度」と「数量」を入力すると初回の請求金額である「本日の請求金額」と「総額」が計算されます。

「全額支払スケジュールの表示」ボタンを押すと、支払スケジュールを確認できます。今回は1年分の毎月払いなので毎月の支払金額が表示されていますね。

すべてを確認して購入します。「今すぐ購入」から確認画面で「はい」を押下。

ついに購入できました!!購入が完了すると購入処理がしばらくかかります。しばらくすると予約が完了します。

これでApp Service Plan の予約購入が完了です。 予約が完了すると、購入完了メールが届きます。ちなみにこちらのメールは購入者以外にもなんらかの強い権限(課金の系の権限かな?)を持っている方全員に飛んでいくようなのでご注意ください。

予約購入後にできること(予約使用率の確認、設定変更、払戻しと交換)

予約購入後にできることを紹介していきます。
予約が完了すると、予約の一覧に作った予約があるのでクリックすると予約の概要ページに移動します。こちらの予約の概要画面から予約の使用状況や設定変更、そして「払戻」や「交換」を行うことができます。

そして購入後しばらくすると概要欄に予約の使用率が表示されるようになります。予約購入したインスタンスがちゃんと使われているかを確認することができるため、かなり重要です。こちらの使用率が低い場合は購入した予約が無駄になっているため、一度適用される条件を確認した方がよいかと思います。ちなみに使用率の反映は毎日若干遅れるようなので、こちらの画面のように使用率が100%に達していないと表示される可能性もあるのでご注意ください。だいたい反映されるのに2日、3日かかるのかな?

「設定」→「構成」画面では購入後のスコープ変更が可能なようです。

「設定」→「更新」の画面からは予約購入の自動更新の設定を行うことが可能です。

予約購入後のAzureコスト管理やEAポータル上での反映のされ方について

予約購入後に Azure Cost Management や Azure EA Portal 上でどのようにコストが反映されるかを紹介していこうと思います。わかりづらいですが、具体的な金額は隠させていただきます。
まずこちらが全体的なコストです。6/2に予約1か月分の費用が発生しています。先ほど支払いスケジュールにもあったように今回は購入日が2日のため、これから毎月2日に一か月分のコストが計上されるようです。それに伴い、予約購入以降のコストからは1インスタンス分の費用が発生していません。この画面からですとどれだけお得になったのかはわかりづらいですね。
予約割引が適用された App Service Plan の属するリソースグループも同様に予約適用された1インスタンス分の費用が計上されなくなります。

どれだけお得になったかは予約の使用率から自分で計算するか、課金スコープの全体的なコストで比較するしかなさそうです。予約の使用率が100%ならば得はしているはずです。
そこで気になるのが、予約購入自体のコストはどちらにかかっているかということです。これは予想ですが、予約購入時に「課金サブスクリプション」は指定しているため、サブスクリプションには紐づいているが各リソースには紐づいていない課金になっていると思われます。サブスクリプションのコストを確認したところ、サービス名が「Azure App Service」、リソースグループが「Other Azure purchases」という名前で課金されていることからもリソースグループにも紐づいていないようです。
また、EAポータル側ですと使用状況の明細には予約購入の金額が反映されていませんでした(購入から1週間後の現在)。どちらにコストが発生しているかが不明な状態になっているので現在調べています。判明次第、こちらのブログに追記しようと思います。
(追記)どうやら予約購入した使用状況の明細はEAポータルには反映されないようです。この現象については下記記事で詳しく紹介しているのでそちらをご参照ください。
onarimon.jp

Azure App Service を予約割引を実際に購入してみた感想

ずっと気になっていた Reserved Instance ですが、予約購入自体はとても簡単で導入もお手軽にできると思います。予約割引のメリットを多く享受できるのは、実際にAzureにアプリケーションを載せて運用し続けているエンタープライズよりの方々かなと思いますそういった長く同じAzureリソースを使い続ける予定のある方におすすめのサービスだなと思います。私自身も仕事ではエンタープライズよりの仕事が多いので予約割引を使えるところはどんどん使っていきたいなと思います。前述しましたが、Azure App Service を確実に1年以上運用することが決まっている場合は1インスタンス分の予約購入はお得だと思います。ぜひ、ご検討ください。
以下は予約購入をするにあたり疑問に思った部分で調べたり、サポートの方に聞いた内容などをまとめた部分です。

よくある疑問点について

Q. Reserved Instance は前払いで購入する必要があるか?月額払いは可能か?

Azure App Service の 予約購入は初月に契約分の金額全額を支払う「前払い」と、総額を月数で割って毎月支払う「毎月払い」の2択で購入可能です。 さらっと確認してみましたが、App Service 以外のリソースも大体「毎月払い」はできそうでした。

Q. 月額払いは日割り計算されるのか?

月額の料金は契約金額の総額を月数で割ったもの(1年契約なら12か月)を月額として、日割り計算されずに請求されるそうです。そのため、契約初回や最後では月でフルに使っていなくても1か月分まるまる金額が課金されるようです。

Q. 新規に予約購入する際、既存の App Service Plan とは別に新規に App Service Plan を作る必要があるか?

App Service Planのリザーブドインスタンスは予約購入したスコープ内でSKUが一致しているApp Service Planがあれば自動でそのリソースに割引が適用されます。既存のリソースにそのまま予約を適用されるため、新規で作る必要はありません。

Q. Reserved Instance はApp Service Plan ごとに予約を購入する必要があるか?購入した予約インスタンスを共有で適用することができるのか?

上記でも説明したとおり、App Service Planのリザーブドインスタンスは予約購入したスコープ内でSKUが一致しているApp Service Planがあれば自動でそのリソースに割引が適用されます。例えば予約割引がかかっているApp Service Planが削除もしくはスケールインしてて予約購入した分のインスタンスが余っているのであれば同じ条件の別のApp Service Plan に割引が適用されるようです。

Q. Reserved Instance はどの範囲で共有できるのか。サブスクリプション単位?リソースグループ単位?

Reserved Instanceの共有範囲は「Azure App Service で予約割引を適用する方法」の項でも紹介したとおり、「共有」、「管理グループ」、「単一のサブスクリプション」、「1つのリソースグループ」のスコープを選択可能です。

Q. 予約の割引が適用されている App Service Plan をスケールアウトさせることは可能なのか?その場合、予約購入したインスタンス数を超えた場合どうなるのか?

予約割引が適用されている App Service Plan のインスタンス数を超えてスケールアウトすることも可能です。その場合、予約購入した分より超過している分だけ通常課金の価格が発生します。

Q. 予約の割引が適用されている App Service Plan をスケールアップさせることは可能なのか?予約したSKU以外に変更している間はコストがどうなるのか?

予約割引が適用されている App Service Plan のSKUをスケールアップすること自体は可能です。ただし、予約購入したSKU外になってしまうので予約割引は適用されません。予約購入した分はもし他に予約適用可能な App Service Plan がない場合は1時間単位で支払った金額が無駄になってしまいます。

Q. 予約購入したSKU以外のサイズ、バージョンに変更することは可能か?

直接購入した予約を変更することはできませんが、予約には「交換」と「払い戻し」という制度があり、それらを使うことで払い戻した料金を使用して違う予約を新規購入することができます。
Azure の予約のセルフサービスによる交換と払戻 | Microsoft Docs

Q. 予約の「交換」、「払戻」の払い戻し金額の計算方法について

「交換」、「払戻」したタイミングで契約期間の残日数から日割りで残額が計算され、払い戻しされるようです。ちなみに現状のところは予約の払戻に途中解約料は請求されないとのことですが、将来的には請求する可能性があるとのことなのでご注意ください。
Azure の予約のセルフサービスによる交換と払戻 | Microsoft Docs

参考ページ

Azure App Service の Reserved Instance を調べていて参考になったページのURLです。

docs.microsoft.com

docs.microsoft.com

docs.microsoft.com

docs.microsoft.com

docs.microsoft.com

azure.microsoft.com

Azure Cost Management のコスト割り当て(プレビュー)機能を試してみたら、Azureコストの案分がとても簡単に設定できるようになった。

最近 Azure Cost Management をいじることが多いのですが、ある日Azure Cost Management のコスト割り当て機能(プレビュー)を発見。

Azureコストの割り当てに関しては今まで公式の機能がなかったので自作でコストの案分プログラムを作ったりと結構大変だったのですが、これが使えるならば待望の機能だ!!ということで実際に使ってみました。

Azure Cost Management のコスト割り当て(プレビュー)機能を試してみた

Azure Cost Management のコスト割り当ては Azure Portal の Cost Management の画面から設定が可能です。 左のブレードの「設定」→「コスト割り当て(プレビュー)」→「追加」から設定が可能です。ちなみに設定が可能なユーザーは「EA契約のエンタープライズ管理者アカウント」もしくは「Microsoft 顧客契約の課金アカウントの所有者」です。

「コストの割り当てルールの作成」画面の手順1でコスト割り当ての設定を行います。コスト割り当ての名前を入力し、コストの割り当て元となる「ソース」とコストの割り当て先となる「ターゲット」を選択します。まずはソースを追加してみます。
↑のソースを追加ボタンをクリックすると、ソースを追加する画面に遷移します。ソースの種類は下記の3つから選べるようです。

  • サブスクリプション
  • リソースグループ
  • タグ

それらは選択するボックスは複数選択できるようになってます。

今回は「リソースグループ」を選択しました。今回「ソース」としてテストで使用しているリソースグループは「20211108○○」という名前で分かりづらいのですが、0.03円のコストがかかっています。この0.03円という数字を覚えておいてください。
続いて「ターゲット」を選択します。 出てくるコストの種類は「ソース」のときと同じで「サブスクリプション」、「リソースグループ」、「タグ」から選択します。

こちらに関しては今回コストが発生していなかったリソースグループ「20210805-○○」を選択しました。

リソースグループが選択されると選択した「ターゲット」が合計何円割り当てられるのかが表示されます。問題がなければ「次へ」をクリックします。

手順2のタブに移動します。こちらの画面では、画面の説明にも書かれていますが、コストをターゲット間で分割する方法を定義します。何%ずつ案分するのか手動で設定したり、自動で割り振るロジックが用意されているのでそちらから設定できます。

割合方法の設定は現在のところ下記6点です。

  • 均等に配分
  • 合計コストに比例
  • コンピューティングコストに比例
  • ストレージコストに比例
  • ネットワークコストに比例
  • カスタム(手動)

手動の場合は合計が100%になるよう自分で割合を決定します。

ここまで来て設定が完了したら「作成」のボタンを押下します。作成したデータがステータスが「処理中」で一覧に表示されます。

作成したデータの詳細を確認してみると、割合規則の処理には最大2時間ほどかかるそうです。気長に待ちます。

しばらくすると状態が変わっているので、「ターゲットのリソースグループ」を確認します。

先ほどまでコストがかかっていなかったリソースグループに0.03円のコストが割り当てられていました。「ソース」のコストが「ターゲット」に移動していることがわかりますね。
かなり簡単にコストの割り当てが設定できました。

ちなみに割り当てられたコストだけを確認したい場合はコスト分析の画面で「グループ化」を「Cost allocation」に設定すれば確認できるそうです。ここら辺の詳しい話はMSの公式ページに乗っていたので割愛します。

コスト割り当て機能の使用用途、利用シーンについて考える

今回コスト割り当て機能を使ってみて、どんな場面に使うと便利かなと利用シーンを考えてみました。まず第一に思い浮かぶのが部門間の共有リソースをコストで案分したいパターンでしょうか。App Service Plan やSQL Database Elastic Poolなど共有のアプリケーションで使用しているリソースなどのコストをどう割り振るかが今までは課題でしたが、コスト割り当て機能を使うことでサブスクリプションを跨いで、割り振ることがが可能なことがわかりました。これをシステムで実装するととても大変だったのでとても便利な機能ができたなという印象です。
他の利用シーンとしては、共有リソースを多く使ったところが、コストの配分を大きくする機能はかなり重宝すると思いました。正直かなり割り振りの方法は広いので実際に使ってみてどのようなパターンがあるか模索していきたいと思います。

EAポータル上での出方の変化、影響について

EAポータル上で反映されたら、追記予定です。

Azureコスト割り当てに関しての気づいたことやその他メモ書き

コストの割り当てはEA契約もしくはMicrosoft顧客契約の課金アカウントでのみ使用可能のようです。

スコープ内にあるリソースグループですが、ここの候補に出てこないリソースグループがある気がします。コストが発生していないリソースグループ?が出ていないのかな。CostManagementに認識されないと出てこないのかもしれない。割り当てターゲットとしては出てきてくれると嬉しいのですが。

意外と厳しいコスト割り当て名の命名規則。どこか別の出力などで出てくるから制限が強めなのだろうか。

参考ページ

docs.microsoft.com

サブスクリプションのコスト管理の異常検出(パブリックプレビュー)を試してみた【Azure Cost Mangement】

2022年2月22日にAzure更新情報で公開された「Public preview: Cost Management anomaly detection for subscriptions」について試してみました。
コスト管理の異常検出ということでどういった異常が検出されるのか、どのように確認できるのかなどを紹介していこうと思います。

「Public preview: Cost Management anomaly detection for subscriptions」について

「Public preview: Cost Management anomaly detection for subscriptions」ということで日本語にすると「サブスクリプションのコスト管理の異常検出がパブリックプレビュー」ということになります。このタイトル普段からコストの急上昇などを気にしている方にとってもはとても気になるタイトルですね。やはり意図しないコストの上昇などは防ぎたいものです。 下記がAzure更新情報の公式ページのリンクですが、書いてある内容の日本語訳です。
azure.microsoft.com

コスト管理の異常検出は、コスト分析プレビューのサブスクリプションで使用できるようになりました。サブスクリプションのコストの異常を確認するには、コスト分析プレビューで任意のビューを開き、[分析情報の表示] リンクをクリックしてすべての分析情報と詳細を表示します。
コスト分析プレビューを初めて使用する場合は、異常検出用にセットアップされたことを確認する "明日、コストの異常分析情報を確認してください" というメッセージが表示されます。既にセットアップしている場合は、「異常なし」というメッセージが表示されるか、表示している日付範囲内で検出された異常の一覧が表示されます。異常に関する詳細を取得するには、分析情報リンクをクリックして、評価された日付範囲の 1 日のコストを表示します。

Azureサブスクリプションのコスト管理の異常検出(パブリックプレビュー)を試してみた

では実際にサブスクリプションのコスト異常検出機能を試してみようと思います。
まずは異常検出を行いたいサブスクリプションに移動して「コスト管理」のゾーンにある「コスト分析」をクリックします。

現状はプレビューの機能のため、こちらのコスト分析画面からは異常検出情報を確認できません。確認するためには「コスト分析(プレビュー)」の画面に遷移する必要があります。

上記の画面にある「リソースごとのコスト」から「〇〇(プレビュー)」と書いてあるボタンを押下することで「コスト分析(プレビュー)」の画面に飛ぶことができます。今回は「リソースグループ(プレビュー)」のリンクをクリックしました。

「コスト分析プレビュー」の画面に移動すると、Azure更新情報の説明文にもかかれていたとおり、「明日、コストの異常に関する分析情報をご確認ください」の文字と「分析情報を表示」のリンクが表示されていますね。「明日、コストの異常に関する分析情報をご確認ください」の文字が出ている場合はサブスクリプションで異常検出のセットアップが有効になっていないようです。セットアップを行う場合は「分析情報を表示」リンクをクリックしましょう。

リンクをクリックすると「分析情報のウィンドウ」が表示され、セットアップされましたとの文字が出てきます。これで次の日から異常を識別する分析情報がこちらに表示されるようです。

1日待つのも面倒なので、とりあえず別のサブスクリプションでどうなるのかをお見せします。
「コスト分析(プレビュー)」の画面でセットアップ前に出ていたメッセージと異なり、「5月21日 の 1 日あたりの実行率 ↓13%」という文言に変わっていました。
「分析情報を表示」リンクをクリックしてみると、過去60日間の1日あたりの平均コスト使用量と比較して下落率が大幅に大きい日にちがピックアップされています。つまり、コストが平均値からはずれた異常の日を分析してくれています。

この日付ごとの各分析情報のリンクのリンクをクリックするとその日を起点とした1日ごとのリンクコスト使用量のグラフが表示されます。この例ですと、確かに5/14と5/21が下落していますね。

今回の分析結果では発生しましせんでしたが、おそらく急上昇も異常検知されると思うので、無駄に突発的に発生しているコストの異常を分析するのに役に立つと思います。
現状プレビューのため、下記の点が改善されるとより使いやすくなると思いました。

  • 異常検知されたときにアラートを通知する機能があった方が気づきやすい
  • 異常検知の閾値を設定することができない
  • 分析情報のリンクがわかりづらい

スコープを「請求スコープ」や「管理グループ」にすると表示されないので注意が必要

異常検出機能を試していてつまずいた点として「コスト分析(プレビュー)」の画面で下記の画像のように「分析情報を表示する」ボタンが表示されなくて困る現象が発生しました。

結論としてボタンが表示されなかった理由はスコープの設定を「請求スコープ」単位や「管理グループ」単位にしていると異常検出の「分析情報を表示する」ボタンは表示されないことがわかりました。たしかに"サブスクリプションの"異常検出機能って書いてあるので出ないですよね...。他のみなさんがひっかからないようにメモ書きしておきます。

コストのアラート欄にある「異常アラートの追加」との関係性は?

今回の機能を試していて気になった別の機能にコストアラート機能の中にある「異常アラートの追加」機能があります。これはサブスクリプションの異常検出機能とは別なのでしょうか?
一応どんなアラートが通知されるのか試してみました。サブスクリプションやリソースグループの「コストのアラート」から「追加」→「異常アラートの追加」を選択します。

「メール受信登録画面」の設定を行います。特に特別な項目もなく、「アラートの名前」、「メールの件名」、「受信者のメールアドレス」、「メッセージ」を入力します。登録作業はこれだけです。

登録した内容は「コストのアラート」から「管理」→「異常アラートの管理」をクリックすると登録した異常アラートが表示されます。

登録したアラートの一覧が表示されます。ちなみに登録して1週間ぐらい待機中ですが、いまのところ、何も通知が来ていないためどのような条件でアラートが通知されるのが判明しておりません。ただこちらの異常アラート機能はサブスクリプションだけでなく、リソースグループにも設定できることから、サブスクリプションの異常検知機能とは別物ではないかと考えております。

「今すぐ送信」をクリックしても何も起こらず。
今回の紹介したコストの異常検知機能とは別の異常検知ロジックなのか同じなのか判明次第、追記していこうと思います。
(2022年8月2日追記)
コストアラートが登録したメールアドレス宛に届きました。メールの文面を見たところ、自動的に集計期間の中で1日ごとのコストの増減の異常値を感知してメール送信してくれるみたいです。

ちなみに今回のパターンは金曜日から土曜日で負荷が下がったことによるコスト減が大きなコスト減少として感知されたようでした。

参考ページ

azure.microsoft.com

docs.microsoft.com

Service Connectorを使用してAzure App Serviceから他のリソースへの接続を簡単に構成する

Microsoft Build 2022 のアップデートでサービスコネクター(Service Connector)という機能がGAされたようです。AzureサービスからAzureサービスへの接続設定を簡単に構築してくれるサービスのようで実際に試してみたので紹介していきます。

Azureサービスの接続を簡単にできる機能 Service Connector が一般提供開始

以下公式発表の引用です。

本日、Azure でのサービス コネクタの一般提供を発表しました。Service Connector のシングルクリックまたはシングルコマンドのエクスペリエンスを使用して、Azure App Service、Azure Container Apps、Azure Spring Apps をデータベース、ストレージ、リアルタイム メッセージング サービスにシームレスに接続できます。また、各接続のさまざまな側面の接続正常性状態も取得します。 Service Connector を使用すると、サービスの配線と接続管理の複雑さが解消されるため、ビジネス ロジックの構築に集中し、Azure にサービス間の構成を任せることができます。 Connecting services has never been so easy with Service Connector – now Generally Available - Microsoft Tech Community より引用 
App Service などのアプリケーションから他のサービスへの接続をAzurePortalのGUIから簡単にできるよって機能のようですね。

サービスコネクタを試してみた(Azure App Service → Azure Blob Storage)

早速 Azure App Service からサービスコネクタを試してみようと思います。
接続する App Service の画面まで移動し「設定」→「サービス コネクタ」を選択します。

「+Create」のボタンを押下すると、下記のような「Create connection」画面が表示されます。
Service typeが接続先のサービスですね。Azure App Serviceからよく接続する SQL Database、Cosmosを始めとするDatabase、Storage や Azure Key Vault になど様々なリソースが対応してますね。
今回はサービスコネクターを使用してAzure App Service から Azure Blob Storage へのアクセスを構成してみようと思います。「Basics」タブの設定は下記の画像のように行います。

続いて「Authentication」タブの設定では認証をどのように設定するかが聞かれます。今回は接続文字列を使用した認証の接続を構成しようと思うので「Connection String」を選択します。このとき、接続文字列をAzure Key Vault に格納するよう「Store Secret In Key Vault」のチェックをオンにしました。そうするとAzure App Service から Azure Key Vault へのサービスコネクタが必要になりますが、こちらも同じように作成してあげましょう(手順は省略します)。

続いて「Virtual Network」のタブでは接続先のサービスに接続するためのネットワーク接続方法が聞かれます。今回は「Configure firewall rules to enable to target service.」を選択します。こちらを選択すると接続の作成時に自動的にファイアウォールルールを設定してくれるみたいです。

最後に検証が行われて「Create」を押せば設定は終了です。設定作業はかなり簡単に終わった印象です。

どう変わったか見ていきましょう。
Azure Key Vault に移動してみるとシークレットができていて中を見ると先ほど指定したBlob Storageの接続文字列が自動的に格納されているようです。

Key Vault のアクセスポリシーを見てみると自動的に接続元の App Service がアクセスできるようにアプリケーションが追加されています。接続元の App Service を確認してみたらManaged Idも自動的にONになっていましたね。この設定がされたことで対象のApp Service から接続先のAzure Blob Storage への接続文字列の取得ができるように設定されていることがわかります。

最後に App Service のアプリケーション設定を見てみるとこちらも自動的にBlob Storageの接続文字列が格納されているKey Vaultの接続が構成されていますね。
あとは普段通りコード側でこちらの環境変数を使用して Key Vault の接続文字列の値を取得する処理をかいてあげるだけですね。ここまでの設定を一瞬でやってくれるとは便利ですね。
App Serviceのサービスコネクターのページを開いてみると、作成した接続が一覧に表示されています。このリンクをクリックするとアクセス権のないディレクトリに飛ばされてエラーになるのですがここだけよくわかりませんでした。

公式ページに接続正常性状態も確認できるよって書いてあったと思うのですが、本当だったらここをクリックすると確認できるとかなのでしょうか...

サービスコネクタを使ってみた感想

ご紹介したとおり、かなり簡単にサービスを構成できましたね。機能としてはなくても大丈夫な機能でしたが、サービスの接続に関して設定めんどくさいなと思っていた部分がかなり簡略化された印象です。サービスコネクタを使うメリットとしては開発者が時間をかけずにサービスを構成できることはもちろん、手動で設定を行うことで外部からアクセス可能になるなどの設定をしてしまうリスクなども低減できそうですね。セキュリティ面でのメリットもありそうです。まさに痒い所に手が届く機能だと思いました。

参考ページ

techcommunity.microsoft.com

docs.microsoft.com

Azure App Service の App Service Plan を Azure Portal から簡単に再起動する方法

Azure App Service を使っていて App Service Plan のCPUやメモリが100%に張り付いてしまい、スケールアウトもインスタンス数が最大に張り付いたままになってしまい、リソースコストも予想よりかかってしまっている。そんな状況で一度App Service Plan の再起動を行いたいなと思うことはありませんでしょうか。今回はそんなときに簡単に Azure Portal から App Service Plan を再起動させる方法を紹介します。

Azure Portal の App Service プランの画面には再起動のボタンがない


Azure Portal の画面上から App Service Plan を再起動しようと思ったら誰もが App Service Plan の画面を確認しますよね。そしてApp Service Planの画面には再起動のボタンがないことを知ります。

App Service Plan 上の各App Service には再起動ボタンがついていますが、ここを再起動しても App Service Plan は再起動されません。

App Service Plan のスケールアップを行うとApp Service Plan が再起動される


実は App Service Plan を再起動させるのは簡単で App Service Plan の価格レベル(SKU)を変更した際に再起動するのでそれを利用します。

一度違う価格レベル(SKU)に変更して、変更が完了したら元の価格レベル(SKU)にすぐに戻すだけです。App Service Plan の100%に張り付いていたCPUなどもとりあえず解消されるのではないでしょうか?

App Service Plan 再起動の注意事項

今回 App Service Pan 再起動方法を紹介しましたが、App Service Plan を再起動することにより、プランに乗っかっているすべてのアプリケーションにがダウンタイムや再起動による影響が発生する可能性があることにご注意ください。そもそもCPUやメモリが100%に張り付いている時点でApp Service Plan のスペックが足りていないか、アプリケーション側で何かしらの異常が発生している可能性もあるため、根本的な解決は別に行う必要があります。とりあえず再起動しても大丈夫な環境で試してみたい場合にお試しください。

Azure Rest API からも再起動できる!?

私は使用したことがないのですが、Azure App Service Plan のRest API で Reboot Worker というApp Service Plan のワーカーマシンを再起動するAPIが用意されているようです。
docs.microsoft.com

Azure SQL Database Elastic Pool 上のDBがプール上から外れ別課金になる問題の原因と解決方法

Azure SQL Database Elastic Pool は Azure SQL Database Single Database とは違い、リソースをDBごとに持たず、1つ1つのDBが一つの大きなリソースを共有することでピーク時の性能に合わせた過剰な性能やチューニングを防ぐことができるAzureのPaaS Databaseです。今回はそんなAzure SQL Database Elastic Pool上に乗っかっているはずのDBがプール上から外れてしまい、無駄なコストがかかってしまう原因と対処方法を紹介しようと思います。

SQL Databaseの使用料金が思ったよりかかっていた。原因はPoolから外れている野良DBが発生していたからだった。

ある日、SQL Database Elastic Pool で運用しているリソースの費用が想定よりかかっていることが判明。調べてみるとあるDBが Elastic Pool 上に乗っていないようでした。

上の画像の「sqldb-onrarimon-demo2」DBの価格レベルが「汎用目的:Gen5、2仮想コア」と Single Database の価格レベルになっていました。そのため、Elastic Pool の課金に加えてSingle Database 1本分のコストが余計にかかっているようでした。本来、Elastic Pool 上に乗ってるリソースは「sqldb-onarimon-demo1」のような表記になっているはずです。
今回「sqldb-onrarimon-demo2」DBがElastic Pool 上から外れてしまった理由ですが、SSMSから直接データベースを作成するとそのようにプロビジョニングされるようです。
問題のデータベースですが、SSMS の「Database」を右クリックして出てくる「New Database」から作られていました。

Databaseを追加する場合は下記のようにAzure PortalのSQLエラスティックプールやSQLサーバーのGUI上から作成するか、Azure CLIなどを使って作成するようにしましょう。

原因はわかったので次は解決方法を紹介します。

プールから外れたデータベースをElastic Poolに追加する方法

それではそのような状況になった場合の修正手順を紹介していきます。手順はとても簡単です。

SQLエラスティックのリソースに移動します(SQL ServerやSQL データベースのリソースではない)。 「構成」→「データベース」→「データベースの追加」と進んでいきます。

「適用」を押したら元の画面で忘れずに「保存」をクリックします。

野良データベースはElatic Poolのプール内に追加されました。これでコストは当初の想定のとおりSQLエラスティックプール内での課金となります。めでたしめでたし。

参考URL

docs.microsoft.com

Azure Chaos Studio でAzure Key Vault に意図的に障害を発生させてみた

Azure Chaos Studio(Preview)にAzure Key Vaultが対応していたので実際に試してみました。

Azure Chaos Studio で Azure Key Vault の障害が起こせるように(Public Preview)

2022年3月9日のAzure更新通知に下記のような情報が上がっていました。
パブリック プレビュー:Azure Chaos Studio Key Vault と Classic Cloud Services のフォールト | Azure の更新情報 | Microsoft Azure

Azure Chaos Studio に、Azure Key Vault と Classic Cloud Services 用のフォールトが追加されました。Key Vault Deny Access フォールトは、Key Vault のネットワーク ルールを一時的に変更することで、Key Vault へのすべてのネットワーク アクセスをブロックします。これにより、Key Vault に依存するアプリケーションがシークレット、キー、証明書 (またはそのすべて) にアクセスできないようにすることができます。Classic Cloud Services Shutdown フォールトは、サービス障害をシミュレートして、デプロイを停止します。フォールトの詳細は、フォールト ライブラリで入手できます。また、これらのフォールトは、Azure Resource Manager テンプレートまたは REST API を介して作成された実験で使用することができます。今後数週間のうちに、Azure portal の実験デザイナーを使用してこれらのフォールトを実験に追加できるようになる予定です。

Azure Chaos Studio の障害ライブラリにも追加されていますね。内部的にはKey Vaultのネットワークルールを変更して Key Vaultへのネットワークアクセスをすべて拒否させることで障害を再現してるみたいです。
Chaos Studio の障害およびアクション ライブラリ | Microsoft Docs
今回はそんな Azure Chaos Studio の Azure Key Vault 障害を実際に試してみようと思います。

実際にAzure Chaos Studio で Azure Key Vault の障害を起こしてみた

KeyVault 障害実験 セットアップ編

Azure Chaos Studio の使い方を説明しつつ、セットアップを行っていきます。

Azure Portal で Azure Chaos Studio を選択し、左のブレードで「対象」を選択するとAzure Chaos Studio で障害の対象にすることができるリソースの一覧が表示されます。まずはこちらの画面で対象リソースのターゲットを有効にする必要があります。
対象のリソース(今回は○○-KVと書いてあるkeyvaultのリソース)のチェックボックスをONにして、左上のターゲットを有効にするの中にある「サービス直接ターゲット(すべてのリソース)を有効にする」を選択します。
ちなみに「サービス直接」と「エージェントベース」の2種類がありますが、「サービス直接」はPaaSリソースなどを Azure Chaos Studio から直接操作して障害を起こす方法で、「エージェントベース」はサービスを直接操作するのではなく、VMなどにエージェントを入れて障害を起こす方法です。そのため、Azure Key Vault の場合はサービス直接の方法で障害を起こしますので「サービス直接」が選択されます。
対象のリソースが有効になると上記赤枠の部分が「有効」に変わります。私がためしたときは有効になるまで少し時間がかかり、もう一回有効にする操作をしたら有効に変わりましたが、ただ反映が遅かっただけかもしれません。
リソースが有効になりましたら、続いて左のブレードで「実験」を選択し、「カオス実験(Experiments)」の作成を行います。「作成ボタン」を押すと。「実験作成」画面が開きます。
「基本」タブでは実行するサブスクリプション、リソースグループ、実験の名前、リージョンを入力します。このときリソースグループやリージョンは実験を行うリソースと違う場所にあっても問題ありません。
続いて「実験デザイナー」タブの入力です。こちらでは実際に起こす障害を設定することができます。また、障害は単一で起こすだけではなく、ステップやブランチなどを使ってストーリーベースに設定できます。「アクションの追加」で障害(フォールト)を追加できます。
「フォールト」の欄で発生させたい障害を選択します。今回は「Key Vault Deny Access」です。現状、Azure KeyVaultではこちらの障害のみ対応となりますが、リソースの種類によっては様々な障害の種類を選択できます。パラメーターは障害ごとに異なりますが、今回は「Duration」ということで障害を発生させ続ける時間を入力します。
「ターゲットリソース」には先ほど有効にしたリソースの中で今回選択した障害「Key Vault Deny Access」に対応しているリソースの一覧が表示されます。今回対象にしたいリソースを選択しましょう。
先ほど追加した「Key Vault Deny Access」が反映されてますね。ステップやブランチの設定もできますが、今回は単純に障害を起こしたいだけなのでそのままで作成します。
ここまできたら「確認および作成」に移動し、「作成」をクリックします。これで実験の作成は完了です。続いて作成した「実験」に対象サービスのロールを付与する必要があります。このロールを付与しないと「実験」が各サービスを操作できないため障害を起こすことができません。リソースごとにどの権限を割り振る必要があるかは下記ページに書かれているので確認しましょう。
Chaos Studio でサポートされているリソースの種類とロールの割り当て | Microsoft Docs
Key Vaultの場合は「Key Vault Contributor」の権限が必要そうです。

障害を起こす対象リソースのロールの割り当て画面に移動し、「Key Vault Contributor」を追加します。
メンバーの選択肢に先ほど作成した実験の名前を入力すると、候補に出てくるので追加します。 これで実行の準備は完了です。

KeyVault 障害実験 実行編

「実験」を作成し、ロールの割り振りが完了したら、後は実行するだけです。 まずは Chaos Studio のページから作成した「実験」を選択します。

実行する実験のページを開いたら、左上にある「開始」ボタンをクリックします。
履歴に新しい行が増え実験が動き出します。
ターゲットのAzure Key Vaultのページに向かってみるとシークレットの一覧が表示されなくなっていることが確認できます。

Azure Key Vault のネットワーク設定を見てみると一時的にすべてのネットワークアクセスが無効にされているようです。この間は停止している Azure Key Vault を使ったアプリケーションが動かなくなるため、Azure Key Vaultの障害を疑似的に再現できます。Azure Key Vault はApp Serviceでのアプリケーション設定と連携した接続文字列の格納や、シークレットを格納したり証明書を保存したりと核となる部分ですのでそういったときにどういった影響がでるのかをシミュレーションできますね。

実行が終わるとターゲットとなったAzureリソースは元通りアクセスできるようになってました。お見せした通り、 Azure Chaos Studio は実際にAzureリソースに疑似的な障害を簡単に起こせるので実際にAzure環境でためして、アプリケーションの回復性を向上させていきましょう。

Azure Chaos Studio を使用してみて

Azure Chaos Studio を使わないで障害を再現しようとした場合、全く別のツールを使用したり、購入したりする必要があるため、導入費用や学習コストが発生します。そういった意味でも Azure PaaS リソースを使う身としてはできる限り、マネージドレベルの高い Azure Chaos Studio は求めていた機能が来たなという実感があります。ぜひ、AppServiceやSQL DatabaseなどのPaaSサービスの対応拡充を楽しみにしてます。懸念事項としては現状プレビュー版で無料で使用できるため、費用感が気になるところではありますが、継続的に実行するCIなどにも組み込めたら面白いと思います。

Azure Chaos Studio を実際に動かしてみたデモ動画

以前私が Jazug Night でLT登壇した際に Azure Chaos Studio について紹介した動画です。よろしければこちらもご覧ください。Azure Chaos Studio を使用して Azure VM に障害を起こしてAzure Traffic Manager によるルート変更が行われるかを試しています。

www.youtube.com

登壇時の資料です。

www.slideshare.net

参考URL

docs.microsoft.com

docs.microsoft.com

Azure Static Web Apps に Azure DevOps 対応がPublic Preview。試してみたら Azure DevOps のPipelineに一瞬で CI/CD が構築されました

今回のお題目はこちら

Azure Static Web Apps のデプロイソースに Azure DevOps が追加(Public Preview)

Azure DevOps 使い待望の Azure Static Web Apps の Azure DevOps 対応がPublic Previewしたそうです。 azure.microsoft.com 上記 Microsoft Azure更新履歴ページから引用。

Azure Static Web Apps now supports seamless CI/CD integration with Azure DevOps via Microsoft Azure Portal. You can now opt for DevOps as your deployment source and link your DevOps account to populate the repository details with a single click. To learn more, visit: https://aka.ms/static-web-apps-publish-devops

日本語訳

Azure Static Web Apps は、Microsoft Azure Portal を介した Azure DevOps とのシームレスな CI/CD 統合をサポートするようになりました。デプロイ ソースとして DevOps を選択し、DevOps アカウントをリンクして、ワンクリックでリポジトリの詳細を入力できるようになりました。詳細については、次のサイトを参照してください: https://aka.ms/static-web-apps-publish-devops

ということで早速試してみました。

Azure Static Web Apps でAzure DevOpsをデプロイソースに選択してAngularのコードをデプロイするところまで試してみた

まずは今まで通り、マーケットプレースからStatic Web Apps(日本語だと「静的Webアプリ」)を検索して作成します。

名前やプランの種類はなんでも大丈夫です。注目すべきは「デプロイの詳細→ソース」の欄に Azure DevOps が追加されています。
Azure DevOps を追加すると Azure DevOps内の既存の組織、プロジェクト、リポジトリ、分岐(ブランチ)を聞かれるので入力しておきます。レポジトリにはあらかじめ Angular のソースコード(新規作成しただけのやつ)を置いてあります。
今回の話とは関係ないところですがAngularのコードを利用するので下記のように Angular のビルドの詳細設定して「確認及び作成」、確認が終わったら「作成」をクリックします。

設定はこれで完了です。↑の画像のように Static Web Apps のアプリができてます。
Azure DevOps側を覗いてみると先ほど設定したレポジトリのパイプラインにCI/CDが自動で作られてもう動いてます。

CI/CDが完了したのち、先ほど作成した Static Web Apps のURLを確認するとアプリケーションのデプロイが完了し、Angularで作ったWebPageが立ち上がっています。一瞬でアプリケーションのデプロイ環境が構築できてしまいましたね!!

Azure Static Web Apps で Azure DevOps を使ってアプリケーションのデプロイを行ってみました。内容はほとんど Github と変わらず、とても簡単に構築できることがわかりました。