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

登壇時の資料です。

Azure環境にわざと障害を発生させる Azure Chaos Studio を試してみた from Tomotaka Suzuki(御成門プログラマー)

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 と変わらず、とても簡単に構築できることがわかりました。

EA契約者が使用する画面「Azure EA Portal」の機能、画面を紹介します

Azure EA契約(Enterprise Agreement)をしているユーザーが使用することができるポータル画面「Azure EA Portal」の画面と機能を紹介します。

そもそもEA契約とは？

EA契約とはMicrosoft Azure を使用する契約形態の一つです。この話はとても難しい話ですので今回は割愛します。
一応参考になりそうなページのリンクを貼っておきます。
Azureの4つのライセンス形態と料金 ～Azure CSPを利用するメリット～｜Microsoft Azureコラム｜東京エレクトロンデバイス

Azure EA ポータルの画面、機能一覧

Azure EA ポータルでは下記のような画面があります。

• 「管理」→ 加入契約情報や管理者の確認、編集を行う画面
• 「レポート」→ リソースの使用状況や料金表などを確認、レポート出力できる画面
• 「通知」→　最新情報の通知欄
• 「ヘルプ」→　公式ページへのリンク

今回はそれぞれの画面の役割と機能について実際の画面を使用しながら一つずつ紹介していこうと思います。

「管理」→ 加入契約情報や管理者の確認、編集を行う画面

加入契約情報や登録している部門・アカウント・サブスクリプションの情報を確認、編集することができます。

加入契約

加入契約している情報と管理者の一覧を確認できます。ここでいう管理者とはEAポータルにアクセスできるユーザーのことで管理者の追加、削除や権限の変更もこの画面から行えます。
※表示されている情報は公開用に編集したものです。

右上のアクティブのチェックボックスが初期値でONになっていますが、OFFにすることで契約期間が終了したときの加入情報を確認することもできます。基本的にEA契約は契約期間が決まっているため、過去の加入契約に紐づくに情報やコストを確認するためにはこの画面で加入契約を切り替えないと確認ができないので注意が必要です。

カレントで選択されている契約番号は画面左上で確認できます。情報を表示するレポートのボタンが使えない場合は契約番号を複数持っていて、カレント契約が選択されていない場合があります。その場合は「管理→加入契約→加入契約のリスト」から表示したい契約を選択しましょう。

こちらで表示されている管理者がAzure EAポータルにアクセスできるユーザーです。この画面から管理者の追加、削除、編集が可能です。

管理者の追加画面。コストの通知頻度の設定や読み取り専用かどうかを設定可能。読み取り専用にするとEAポータル上で設定の追加、変更の操作はできなくなります。

部門

部署を追加することでAzureサービスの使用状況やコストについて、部門ごとに管理することができます。

部署追加画面

アカウント

アカウントの管理を行うことができます。上述したEAポータルにアクセスできるユーザーの「管理者」とは別物であることに注意が必要です。「アカウント」はコストに紐づくグループ分けみたいなもののようです。Microsoftの公式ドキュメントによると事業部、昨日チーム、地理的な場所単位で作られる例が挙げられていました。

アカウント追加画面

サブスクリプション

加入契約に紐づくサブスクリプションの表示、作成を行います。ここで表示されていて有効なサブスクリプションがMicrosoft Azure上でサブスクリプションとして利用可能です。
※サブスクリプション名やサブスクリプションのGUIDはランダムで取得したものに変更しています
自分には権限がなかったのでサブスクリプションの追加画面は載せられませんが恐らく、アカウント所有者として追加されたユーザーのみがサブスクリプションの作成を行えます。

「レポート」→ リソースの使用状況や料金表などを確認、レポート出力できる画面

レポートの画面ではコストの使用状況、サービスの使用量、使用状況のファイル出力、料金シートの表示、Power BIレポートでの出力を行うことができます。

使用状況の概要

使用状況の概況では支払いに関する概要情報が表示されます。

通常のAzureサブスクリプションの考え方と違い、EA契約ですと年払いで先に支払い、残高を超過した分は毎月請求される仕組みの方が多いと思います(パートナー企業によって違うかもしれませんが)。こちらの例ですと2017年8月の期首時点で1,000,000円の残高があり、8月に40,000円使ったので、8月の期末残高は960,000円という見方ができます。残高がなくなるとサービス超過分の金額の部分に反映されます。
画像下の「Azureサービス」の部分は選択された月にサービスごとにどれだけ使用して、単価がどれくらいで、どれだけ料金がかかったかが記されています。

サービス使用量レポート

サービス使用量レポートは検索期間の間に「サービス」の「測定単位ごとにどれだけ使用したか」を出力します。よくAzureの料金計算ツールで使用量を予測で入れて見積もったりすると思いますが、その使用量の実際の結果ですね。

使用状況のダウンロード

月ごとの「残高と料金」、「使用状況の詳細」、「Marketplace の料金」、「料金シート」をCSVファイルでダウンロードできます。私はこちらの機能を使うことが今のところ一番多いですね。料金などで細かい項目とかを知りたいときにExcelファイルに変換して集計して使用することが多いです。最近はAzure Portalのコストマネジメント機能もかなり充実してきたので使用することは減ってきましたが。ダウンロードできるファイルの詳細については後日別記事で紹介したいと思います。
こちらの「使用状況の詳細」画面からEAポータルのAPI「Azure Enterprise REST API」で情報を取ってくるのに必要なAPIキーを生成できます。EAポータルAPIを使用することで自信が作成したアプリケーションからEAポータルで表示される情報を取得することが可能になります(その話については後日別記事で紹介できたらと思います)。

料金シート

Azure EA契約では販売パートナーごとにAzureリソースの料金が定められているため公式ページで公開されている料金とは違う可能性があります。そのため、EA契約を行っている方は自身が使用する正確なリソース料金の単価はこちらの料金シートから確認します。

こちらの「料金シートの単価」 × 「サービス使用量」が「実際に課金されるコスト」ですね。

Power BI レポート

Azure Cost Management コネクタ を使用すると、Azureコストを Power BI でレポート表示できるようになります。

「通知」→　最新情報の通知欄

Azure EA契約、EAポータル、コスト関連の通知情報が表示されます。

「ヘルプ」→　公式ページへのリンク

ヘルプ画面のリンクです。下記MS公式ページにリンクされていました。
Azure エンタープライズ ポータルを使い始める | Microsoft Docs
ちなみにEAポータル関連のサポートリクエストはAzureポータルから行うことが可能です。

参考リンク

docs.microsoft.com

Microsoft認定資格の無料の更新評価試験を受けてみた【受験方法・勉強方法・試験方式】

Microsoft認定資格の更新方法が2020年12月15日に変更になりました。
docs.microsoft.com
新しくなった認定資格の更新について情報などまとめましたので是非、ご参考にどうぞ。

MS認定資格更新方法の変更点

変更点は下記の通りです。

• 変更前：2年間の更新期限切れ前に有料の更新対象資格を受験し、合格する
• 変更後：1年間の更新期限切れ前に無料の更新アセスメントテストを受験し、合格する

変更前は更新の試験でもテストセンターや厳しい条件での自宅受験が必要でしたが、新しい「更新アセスメント試験」は受験要件などの指定はなく、どこでも気軽に受けることができます。更新期限が1年になった代わりに無料の更新アセスメントで認定資格を更新できるようになったため、更新のハードルとしては下がったのではないでしょうか。ちなみに有効期限についてですが、2021年6月30日までに合格した資格については2年間、以降に合格した資格については1年間となるそうです。

更新アセスメントテストの受け方

認定ダッシュボードから更新対象の資格を確認することができます。 上記のように期限切れのアラートが表示されたり、MS Learnの認定資格一覧に更新ボタンが表示されます。 更新ボタンを押すと更新アセスメントの「更新評価準備画面」に移ります。
準備画面内の下記「更新評価を受ける」ボタンを押すといきなり試験が始まるので注意です。

試験の出題方式、出題方法について

私が今回受けた更新試験は「Microsoft Certified: Azure Administrator Associate」、「Microsoft Certified: Azure Developer Associate」の更新試験を受けてみみましたが、試験の出題方式に関しては大体同じで選択肢式の単一選択回答か、複数選択回答の問題でした。各問題は一度答えると前の問題には戻れないので注意が必要です。試験時間は45分で合格点は試験によって違うようでしたが、全体正解率が70%前後以上のスコアで合格でした。
最後の問題に答えると合格してる場合は合格画面が表示されます。

合格した場合も、不合格の場合も「全体の正答率」と「評価別」の正答率を確認することができます。

更新アセスメントの勉強方法

試験の対象スキルについては上述した「更新評価準備画面」に書かれていたり、更新試験向けのMicrosoft Learnのコレクションも準備画面の下に記述されています。更新試験の勉強方法は試験範囲のMSLearnコレクションをやったり、公式ドキュメントを読んだりしました。MSLearnのコレクションで勉強したことが結構出ていた印象です。

更新アセスメント試験の再受験ポリシーについて

残念ながら不合格だった場合の再受験ポリシーですが、1回目と2回目の間はすぐに受験することができます。3回目以降は前回試験より24時間空けないと受験できないので注意が必要です。再受験ポリシーさえ守れば、認定の有効期間内であれば何度でも無料で受け直すことができるので再認定を取りやすい仕組みだと思います。

最後に

今までMSの認定資格は更新の際にお金を払って、再受験が必要であったため、期限付きの資格の受験のしやすさや、更新のハードルがやや高かったと思います。新しい方式での資格更新方法となり、手軽に何度も無料で更新することができるようになったため、さらにMicrosoft認定資格の敷居が下がったのではないでしょうか。反面、更新期限を1年とすることで技術がどんどん進化していくことに対する資格保有者の技術アップデートが頻繁に行えるようになったメリットもあると思います。今回の変更でMicrosoft認定資格の人気がさらに上がってくるのではないかという予想です。

参照ページ

docs.microsoft.com

【Azure Backup】MARSエージェントで「resource not provisioned in service stamp」エラーが発生した場合の解決方法

ある日、Microsoft Azure Recovery Services(MARS)エージェントを使ったバックアップが動かなくなった。
発生したエラーメッセージで検索しても情報がほとんどなかったので解決方法を共有します。

発生した現象

バックアップのジョブが一切発生していない状態

バックアップジョブはある日を境に一切動いていなかった。
失敗のジョブが発生しているわけではないのでAzure Backupの通知機能が動かないので注意。

バックアップを行っているサーバーでエージェントの画面を開くと下記のエラー

何も情報が表示されない...

resource not provisioned in service stamp

PowershellでMSOnlineBackupコマンドを実行しても同様のエラーになる

PS C:\Windows\system32> get-obpolicy
get-obpolicy : The current operation failed due to an internal service error "Resource not provisioned in service s
". Please retry the operation after some time. If the issue persists, please contact Microsoft support.
発生場所 行:1 文字:1
+ get-obpolicy
+ ~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Get-OBPolicy], DlsException
    + FullyQualifiedErrorId : ResourceNotYetProvisioned,Microsoft.Internal.CloudBackup.Commands.GetCBPolicyCommand

原因と解決方法

原因はバックアップ対象マシンのコンピューター名が変わったことが要因

Azure BackupのMARSエージェントは初回設定時からバックアップ対象マシンのコンピュータ名を変えてしまうとうまく動作しないらしく、「Resource not provisioned in service stamp」エラーはコンピュータ名を変えてしまったときに発生する事象のようです。

エラーが発生したマシンをしらべてみたところ、 うまく動作しなくなった日からコンピュータ名が変更されていることがわかったのでこれが原因だと断定しました。

解決方法

解決方法は2通りある。

1. コンピュータ名を戻す
2. 新しいコンピュータ名でAzure Backupに再登録する

私は再登録パターンで対応したところ、
うまく動きました。

Microsoft Ignite The Tour Tokyo 参加メモ【BRK30033 サーバーレスな Azure Event Grid の紹介】

BRK30033 サーバーレスな Azure Event Grid の紹介

CNCF

• クラウドネイティブを定義する団体
• CNCG-Serverless
  • そこに属するAzure Functions

Serverlessのプラットフォームとして

• Zero Server Ops

  • OSアップデートなどの準備、管理コストがかからないこと
  • 自動的なスケーリング

• No Compute Cost When Idle

  • アイドル時(処理を行っていない時)のコストは0

Azureのサーバーレスプラットフォーム(抜粋)

• Azure Functions
• Event Grid

Azure Functionsを使って単純にアプリを作ったら

• そういうことを実現しようとしたら一つのイベントで複数箇所に接続しないといけない
  • コードボリュームも大きくなり、可読性、保守性が落ちる
• もしくは複数のFunctionsに接続しないといけない
  • コードボリュームも大きくなり、可読性、保守性が落ちる
• 一つのFunctionsにコードが集中してしまう。

Azure Event Grid

• イベントを一元管理し、イベント処理側にルーティングする
  • イベントを受けて送った先を分岐できる
  • イベント受ける側は送るだけでいい
  • リアルタイム、スケーラビリティ、高可用性、重量課金
• Event Gridを使うと機能別のコードボリュームは小さくなり、可読性と保守性が向上、各機能のスケーラビリティも向上
• 機能別にマイクロサービス化ができるようになる

Event Gridの設計思想

• パブリッシャーとサブスクライバーのパターン
• 再試行パターン
  • 再試行ポリシーだけでは足らない場合
  • 失敗した情報をBlobに突っ込んで失敗時の処理を受け取り、再試行する
  • サブスクライバーごとの設定で再試行のポリシーを設定できる。エラー時ストレージにデータを送る設定ができる

• クライアントフェールオーバー

  • サービスは絶対落ちるときがある
  • 日常生活から対策することにより問題なくなる
  • 東日本と西日本のEvent Gridを用意しておく

• Cache戦略やイベントソーシングの実装に

  • どんなにスケールしてもDBの読み書きが遅いことがネックになる
  • 変更した状態を保持することでスループットを向上させる

CloudEvents

• 言語、ベンダー固有ではなく、汎用的なメッセージ規格
• Azureでもサポートしている
• 10/24 1.0リリース
• 外部の互換性のあるメッセージに飛ばすことができる

Azure Event Grid How To

• Code SampleからEventGridを検索すると出てくる
  • イベントを可視化してDebugを便利にする Azure Event Grid Viewer
  • SignalRを使った完全非同期ができるようになる

イベントサブスクリプション

• イベントにサブスクライブするには証明が必要。詳しくは公式ページ

Microsoft Ignite The Tour Tokyo 参加メモ【AFUN70 Azureのコストを削減する】

AFUN70 Azureのコストを削減する

• セッション資料 aka.ms/afun70

オンプレミスでコストを見積もるとき

• ハードウェア
• ラックスペース
• ソフトウェア
• その他の隠されたコストがかかる
  • 電力
  • メンテナンス
  • リカバリー
  • バックアップコスト
  • 部品股間
  • 保険

Azure仮想マシンでコストを見積とき

• 性能によって値段が変わる
• クラウドにもその他のコスト要因がある
• これを理解する必要がある

3 今回のセッションの内容

• コストの見積
• コストガードレールの設定
• 実際のコストを確認

料金計算ツール

• Azureの価格のページの中に料金計算ツールがある
• アカウントをサインインして使うのがおすすめ
  • 見積を保存できる
• 参照実装のシナリオがあるのでそこから見積もできる

仮想マシンのリザーブドインスタンス

• 仮想マシンの場合、長期間使用が決まっている場合リザーブドインスタンスがコスト削減におすすめ

仮想マシンのハイブリッド特典

• オンプレのライセンスを持っていると仮想マシンを安く使える

クラウドコストの担当者はだれが見るべきか

• サービスにかかわるすべての社員がかかわるべき
  • 開発者
  • 財務担当者
  • マネージャーなど

クラウドのコストにアーキテクチャが重要になる

• 例カレーをスパイス一から作ってくるのがIaaS、レトルトを食べるのがPaaS

• コストに影響する設計上の決定

  • 管理対象ディスク
  • ストレージ階層
  • レプリケーション
  • 地域

application migrate service

• オンプレミスからクラウドマイグレーションする際のコストを見積もってくれる

Azure TCO計算ツール

• クラウドに移行してコストが変わるかを確認できる。
• Azure価格からTCO計算ツール
• 環境に合わせて情報を入力すると、オンプレミスとクラウドの費用感を比較するレポートが出力される

ロールベースアクセス制御

• owner権限は何でもできてしまう。
• コストを見るだけのロールを作って、その人に割り当てるのが重要

リソースタグ

• 細かい仕分けができる
• Azureのリソースが何に使われているのか。本番、dev環境なのか
• どの部署が使っているか

Azureポリシー

• タグの制限
• 高価なSKUの制限

Azure Badgets

• Azure portalのコストマネジメント→badgets
• 現在のAzureサブスクリプションで動いている。バジェットでしているリソースの状況を確認できる
• タグでフィルタリング
• 設定値に月額で達したときにアラートをすることができる

Azureコスト分析

• 実際にかかったコストを確認するときに使う
• コストマネジメント→コスト分析
• リソース、ロケーション、リソースタイプをグルーピングして確認できる

AzureAdvisor

• Azureを使う上でのベストプラクティスを提供してくれる
• コストに関するプラクティスも教えてくれる

Azure PowerBI コンテンツパック

• Azureと連携して情報を確認できる

API

• 課金APIを使うことで自作アプリと連携

AWSのコストをAzureコストマネジメントで確認できる

コスト削減のヒント

• Azureの購入オプションを見極める
  • トレーニング用のサブスクリプション
  • Dev/Testサブスクリプション
  • Azure開発/ラボ
  • 優先順位の低い仮想マシンを確認する
  • Azure Hybrid特典を使えたら使う
  • リザーブドインスタンス