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

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

Azure App Service プランでアプリを最大アプリ数の推奨値を超えて乗せると落ちるから気を付けよう

Azure App Service のアプリ最大数の制限事項を超えてやらかした運用話について紹介します。

こちらの記事は私が 第42回 Tokyo Jazug Night で発表した「Azure App Service 運用体験談 ~コスト節約しようとしてダウンした App Service~」の内容を記事に起こして補足を追加したものになります。

Azure App Service 運用体験談 ~コスト節約しようとしてダウンした App Service~

第42回 Tokyo Jazug Night で発表したときのスライドはこちらです。


今回はクリスマス、年末にふさわしい?Azure App Service のやらかし運用体験談についてでした。
やはり運用話って面白いよね。

Azure App Service とは


今回のお話の主役 Azure App Service についてです。「Web アプリケーションをデプロイするサービスを提供する PaaS フルマネージド プラットフォーム」です。
参考URL

App Service と App Service Plan の関係性。こちらが今回の肝となる部分ですね。App Service Plan は複数のアプリを載せることができ、いくつアプリを乗っけても費用は App Service Plan のサイズ、数で決まるというもの。
App Service Plan の価格についての参考URL

Azure App Service のアンチパターンとなるコスト節約策「1つのプランにアプリをたくさん乗せ続ける」


上述した Azure App Service の価格体系を見て思いつく悪いアイデア「1つのApp Service Plan にすべてのアプリケーション乗っけたらお得じゃない?」説。

最初は数個単位で乗っけていたアプリケーション。アプリが増えるたびにテスト環境、ステージング環境、検証用環境、本番環境関係なく乗っけていきました。

気づいたら、自主規制レベルまでアプリを積んでいました。言い訳になるんですが、最初の頃は Azure で使える予算も少なく、なかなかプランをもう一個作れる環境ではなかったのでしょうがなくやっていたのです。

アプリを乗せ続けた結果、発生し始める不具合。最終的にダウンタイムが発生...


そのような状況で数年は運用できてましたが、あるときからこの構成が原因ゆえの不具合が増えてきます。

  • オートスケールでインスタンス数が最大値に張り付き続ける

    • CPUが高負荷のままに
  • テスト環境の負荷が本番環境に悪影響を与える

    • テスト環境が何かやらかすと本番の環境の動作も一緒に悪くなる
  • スケールアップ、インスタンス最大数を増やすことになり、増え続けるコスト

このときからアプリの数怪しいなとは思ってはいたのですが、プランのSKUをスケールアップしたり、オートスケールのインスタンス数増やしてるし大丈夫だろうと思っていた状況です。それだけアプリ使ってるんだから、コストアップもしょうがないと思っていました。

そしてとうとうプランに乗っかっているアプリケーション自体が動かなくなる現象が発生します。

スライドでは Azure 正常性アラートの通知画面を紹介していましたが、これは設定しておいて本当に良かったと思います。後日正常性アラートについても記事書こうかな。

ちなみに発表では紹介しませんでしたが、一回プラン全体が完全に落ちてます。アプリケーションがアクセス不能になり下記のようなエラーを吐いてました。
「Our services aren't available right now We're working to restore all services as soon as possible. Please check back soon.」

ここから解決編。原因は App Service Plan にアプリ載せすぎだった。


記事のタイトルでもネタバレしてますが、上記のような不調の原因は一つの App Service Plan に対してアプリを載せすぎたことが原因でした。上記の画像のようにApp Service Plan のSKUごとに最大アプリ数が設定されていてそれを超える場合、新規や既存のアプリにダウンタイムが発生する恐れがあるようです。

詳しい最大アプリ数は下記の Microsoft 公式ページをご参照ください。
App Service プラン - Azure App Service | Microsoft Learn 「アプリを新しいプランと既存のプランのどちらに入れる必要があるか」
というわけでこのような状態に陥った App Service Plan はアプリを適切に新しい App Service Plan に分離していく必要があります。

ちなみにプランに現在乗っかっているアプリ数を確認するには Azure Portal の App Service プランの概要ページより確認することができます。「アプリ/スロット」の部分から確認することができます。

この画像ですとアプリが25個、スロットが21個乗っかっています。

解決策「App Service Plan を環境ごとに分割する」


App Service Plan の分割を考える際にどのような点を考慮して分割していくのか。分割戦略を紹介しました。
スライドでは環境ごとに App Service Plan を分割した例を紹介しましたが、それ以外にもアプリケーションを完全に独立させたい場合、アプリを別のリージョンに配置したい場合は別のプランに分割する必要があります。

上記の分割案のようにプランの分割を行い、各プラン内で推奨のアプリ数内に抑えたところ、無事問題は解決されていきました。アプリケーション停止の問題だけでなく、インスタンス数やCPUの上限張り付きもなくなり、いかにアプリ数の超過がプランに影響を与えていたかがわかります。

App Service Plan の分割したことにより、問題が解決するだけでなく、様々な副次的な効果がありました。一番大きかったのはプランを増やしたにも関わらずコストが最大半分近くまで下がったことです。
コストが下がった要因としては下記の理由が挙げられます。

  • 必要なプランにだけ高いSKUのプランを用いることができたこと
  • 高いSKUのプランの負荷がさがったことで高いプランのインスタンス数が上がらなくなったこと
  • 普段パフォーマンスを必要としない環境のプランのSKUを低くできたこと

コストダウンしただけでなく、本番環境のプランを分割することができたので本番環境のリソースに必要最小限の権限を振ることができるようになったため、ガバナンスを効かせやすくなりセキュリティ運用面での課題を解決することもできました。

結論「制限事項はしっかり守る」、「下手なコスト節約は逆効果」です


今回学んだこととして無理なコスト節約は逆にコストがかかってしまうこと。公式ドキュメントに書いてあること、特に制約事項はしっかりと見ておく必要があると実感しました。このような陥りやすいパターンはアンチパターンとして紹介されている場合も多いのでアーキテクチャを構築する際には気をつけようと思いました。

Azure App Service 小ネタ集

App Service Plan の再起動方法


App Serive Plan の再起動についてはこちらの記事で別で紹介していますのでそちらをご参照ください。
onarimon.jp

App Service Plan の変更方法について


今回App Serive Plan の分割に使用したApp Serive Plan の変更についても別記事で紹介していますのでそちらをご参照ください。詳しい方法や制限事項等をまとめております。
onarimon.jp

プランの違うステージングスロットをスワップするとプランごと入れ替わる


プロダクション環境とステージング環境でプランが違う場合、それらをスワップするとどうなるかと気になりますね。私もやってみてわかったのですが、図のようにプランごと入れ替わってしまうので注意が必要です。そのことからステージング環境は本番環境と同じプラン上に乗っけておく必要がありそうです。

第42回 Tokyo Jazug Night 動画の紹介

2022/12/22(木)開催の 第42回 Tokyo Jazug Night は毎年年末恒例のLT大会でした。詳細は下記のConpass ページをご参照ください。
jazug.connpass.com

第42回 Tokyo Jazug Night の発表動画はこちらです
youtu.be
私の発表は21:30ぐらいから始まります(このリンクからすぐに飛べるよ)

サブスクリプションやリソースグループのタグを子リソースに継承するAzureコスト新機能「タグの継承」を試してみた

2022年11月の Microsoft Cost Management アップデートに出てきたサブスクリプションやリソースグループに設定したタグを子リソースに継承するAzureコスト新機能「タグの継承」を試してみたので紹介します。

タグの継承を使用してサブスクリプションとリソース グループのタグでグループ化する機能がプレビューに

Microsoft Cost Management の2022年11月アップデートで面白い新機能を見つけました。

タグ付けはコストをグループ化するための効果的なメカニズムですが、すべてのリソースにタグを付け、リソース プロバイダーに依存して、課金パイプラインでの使用に関するタグをサポートおよび出力する必要があります。これらの制限を克服し、コスト レポートにタグを簡単に使用できるようにするために、Cost Management タグ継承プレビューを使用して、コストの詳細でリソース グループとサブスクリプションのタグをリソース使用状況に自動的に適用できるようになりました。

Microsoft Cost Management updates—November 2022 | Azure のブログと更新プログラム | Microsoft Azure より引用したものを翻訳。

今までコスト詳細で出力される明細の単位はリソース単位でしたが、そのリソースに登録されたタグしか表示されていなかったため、グループ化するためにはすべてのリソースにタグ付けをする必要があり管理が大変でした。

今回の機能が出てきたことでサブスクリプションやリソースグループに設定されたタグがその子リソースに継承されるため、その設定の手間が省ける機能となります。それでは実際に動きを見てみましょう。

タグの継承(プレビュー)を実際に試してみた

タグの継承を有効にする方法

Microsoft の公式ドキュメントにも載っていましたが、タグの継承の有効にするには下記のアクセス許可が必要なようです。

  • サブスクリプションの場合:Cost Management 共同作成者
  • EA 課金アカウントの場合:エンタープライズ管理者
  • MCA 課金プロファイルの場合:課金プロファイルの共同作成者

この権限を持ったアカウントで Azure Portal から設定を変更できます。 「Cost Management」→「課金アカウントの管理」→「Tag inheritance (preview)の編集」をクリックします。
タグの継承の設定画面が出てきます。

「Automatically apply subscription and resource group tags to new usage data. (サブスクリプションとリソース グループのタグを新しい使用状況データに自動的に適用する)」のチェックを入れます。  
「When the resource has a tag with the same name:」でリソースが同じ名前のタグを持っているときにどうするか確認されます。
「Keep the resource tag」の場合は既存のリソースのタグがそのまま残り、「Use the subscription or resource group tag」の場合はサブスクリプションやリソースグループのタグの値が優先されリソースのタグの値が上書きされます。詳しい上書きのルールの説明については公式ページに書いてあるのでそちらをご参照ください。


あとは適用するだけです。ここにも書いてあるように適用されるまで最大24時間ほどかかるようです。

ちなみにタグが継承される範囲ですが、月の途中に設定を行った場合その月の1日からの使用状況レコードが設定した日に存在していたタグを使用して更新されるみたいです。また、タグの継承設定を無効にした場合は、継承されて作られたタグは削除されるようです。

継承されたタグを確認する・活用する

24時間後に実施に確認してみました。今回の継承ですが、あくまでコスト状況で使われるタグのようで実際のリソースにはタグは付与されていませんでした。影響はあくまでコストの範囲ということです。

続いてコストの使用状況詳細を確認します。 ダウンロードはこちらからできます。使用状況詳細をAzure Portal からダウンロードする方法については別の記事で紹介しておりますのでご参照ください。

CSVファイルをダウンロードしてみると、タグ (Tags)列にリソースには設定していないリソースグループのタグが入ってました。どうやらタグの継承は成功しているようです。
これは便利そうな機能だ。また、公式ページにも書いてありましたが、Cost Management の画面からタグの値でグループ化して表示することもできるのでコスト分析がさらに捗りそうです。グループ化の部分でタグを選択するだけです。

AzureCostManagement(Microsoft Cost Management) 周りは以前は機能も少なく自分で管理用にシステムを構築しないと不便な部分もありましたが、Azure Portal で完結できるようになる時代が近づいている気がしますね。

参考ページ

Azure で発生した SLA返金や調整額の明細を知る方法

Azure で SLAが発生した場合の内訳や返金理由を調べる方法の備忘録です。

調整金額が発生しているか確認する方法

Azure Portal の「コスト管理と請求」→請求先を選択→課金欄の「クレジット + コミットメント」を選択すると月ごとのクレジットコミットメント状況を確認できます。

その中の「調整」という列にある金額が気になります。

リンクをクリックすると Service Level Agreement Credit や Usage Emission Credit と書いてありますが、何が起きて発生した調整金額なのかは全くわかりません。

実際に運用しているとあるかなと思うのですが、会社の上の人や経理の人からこの調整額ってなんなのって説明求められることありますよね。そんなときに調整額の内訳や発生理由を調べる方法ないかなーと疑問に思いました。

結論「現状はAzure課金サポートやパートナーに聞くしか方法はない」

調べてみたのですが、現状ですと発生した調整金額と↑で出てきた Service Level Agreement Credit や Usage Emission Credit レベルの情報ぐらいしか出てきませんでした。

そのため、調整額の詳細や内訳を確認するにはAzure課金サポート(Azure Enterprise Agreement サポート)や各社で契約しているパートナーに確認するしか方法はなさそうです。ちなみにパートナー経由で契約している場合で返金の内訳を知りたい場合はAzure課金サポートではなく、パートナーの担当者に聞いた方が良いみたいです。

問い合わせの際は 「請求先アカウントID」、「EA加入契約番号」、「発生した調整額の名称」、「発生した月」、「発生した金額」、「サブスクリプションID」など一緒に載せてあげると回答しやすいと思います。

発生した調整金額の扱いについて

余談ですが、発生した調整金額はその月の発生したリソースのコストから差し引かれるのではなく、クレジットに調整金額分追加されて次回クレジット使用時に使用されます。

Microsoft 「OpenHack DevOps」参加レポート

今回は Microsoft の主催する OpenHack に参加してきましたので参加レポートを書いてみました。意外と調べてみても情報はまだ少なかったのでこれから参加する方の参考になったら幸いです。

OpenHack とは

Microsoft Open Hack 概要

公式ページの説明を引用します。

Microsoft OpenHackは、開発チーム(Open)と専門家を結び、対面またはオンライン(Virtual)で実践的な実験(Hack)を通じて一連の実世界の課題に取り組む、開発者に焦点を当てた取り組みです。
OpenHackは、マイクロソフトの社員、顧客、パートナーに、ユニークで楽しいスキルアップの機会を提供します。参加者はチームで協力しながら、複雑さを増す課題をクリアしていきます。積極的に参加し、深いコラボレーションを必要としながら、共に学びます。

openhack.microsoft.com より引用
説明からもわかるとおり、ハンズオンとは違い手順書や答えがない状態でチームで協力しながら課題を解き進めていくイベントですね。

Microsoft Open Hack のトピックについて

Microsoft Open Hack には現在のところ、8種類のジャンルがあるようです。

  • AI-Powered Knowledge Mining
  • App Modernization with NoSQL
  • Containers
  • DevOps
  • Migrating Microsoft workloads to Azure
  • Serverless
  • Modern Data Warehousing
  • Security, Compliance, and Identity

それぞれのトピックの詳しい説明については公式ページをご参照ください。私は今回 DevOps に参加しました。

OpenHackの参加方法について

現在Webページ上では参加ページは公開されていないようです。私の場合、所属している会社の Microsoft の担当者の方から勧めていただき、参加しました。参加を検討している方は Microsoft の担当者の方に聞いてみた方が良さそうです。

ある達成点まで達することができたらとディジタルバッジがもらえる※


Open Hack では課題が与えられ、チームでそれを解いていくのですが、ある達成点までいくことができたらデジタルバッジをもらうことができます。
www.credly.com

OpenHack DevOps 参加レポート

OpenHack の流れ、進み方

今回の OpenHack は3日間で9:00~16:30(最終日は15:30まで)というスケジュールでした。

基本的な流れとしては課題が10問用意されていて、各チームでそれを解き進めていきます。チームには Microsoft のコーチの方がいて、悩んだ時にアドバイスをもらえます(直接的な答えはされないようです)。小休憩やお昼の休憩などは各チームで適宜取る形式です。

OpenHack 中はひたすら問題と向き合い続けます。

OpenHack DevOps の内容・難易度について

具体的な問題の内容は公開しないようにとのことなので控え、公開されている情報を元に OpenHack DevOps の内容を紹介します。

公式ページによると概要は下記のように書かれています。

DevOps OpenHackは、DevOpsの基本的なスキルアップと開発を可能にします。 ゼロダウンタイム・デプロイメント戦略は、本番環境での摩擦を減らし、システムのダウンタイムなしに新機能をより頻繁に、安全にデプロイできるようにします。

技術としては下記のような技術が挙げられていました。

GitHub or Azure DevOps (team choice), Azure App Service, Log Analytics, Application Insights, Azure Monitor, Azure SQL Database, Azure Container Registry, Key Vault, Bicep, Terraform

https://openhack.microsoft.com/ より引用

概要、必要技術から見てわかるとおり、GitHub もしくは Azure DevOps を中心に使った開発でした。大体、概要に書かれているイメージと相違ない内容だったと思います。

難易度としては公式ページの前提条件に書かれていたように Microsoft 独自の難易度指標でレベル300 のため、全くの初心者には難しい内容だったと思います。私の場合ですが、仕事で普段触っている部分はトライ&エラーで少しずつ良い感じに進められ、疎い分野のときは結構悩みながらも進められるような難易度だったと感じました。

最初にも書きましたが、全くの初心者の方には難しいと思うので、他の Microsoft が主催しているハンズオンセミナーに参加してみてからの方が良いかもしれません。

OpenHack に参加した感想

参加前はWeb上であまり詳細な情報を得られず、どんな感じなんだろうと思いながら参加したOpenHack でしたが、結果としては学びや発見があり、なにより楽しく開発をできたと思います。受講中に「このやり方は実際の仕事の方にも持ち帰ることができる技術だな」と思える学びも多く、大変勉強になりました。

今回は普段仕事をしているチームメンバーと一緒に参加したため、チームとしてワイワイガヤガヤしながらのモブプログラミングも盛り上がりましたね。チームとしてのレクリエーション的要素としても良かったなと思います。

他のトピックの Open Hack にも挑戦していきたいなと思っております。この記事を読んだ方も興味がございましたら是非、参加してみてください!!

参考ページ

openhack.microsoft.com

Azure Web App を別のリソースグループにある App Service Plan に移動する方法

Azure Web App が乗っかっている App Service Plan を変更する際に 別リソースグループにある App Service プランに移動する方法を紹介します。

解決方法は簡単

「App Service Plan のリソースグループの移動を使用する」 だけです。

詳細について下記で解説していきます。

Azure App Service アプリの移動についての制限事項

通常 Azure Apps Service のアプリを別の App Service Plan に移動させる場合、下記のような制限があります。

別の App Service プランへのアプリの移動は、移動元プランと移動先プランが "同じリソース グループおよび同じ地理的リージョン" に存在している場合に限り可能です。
App Service プランの管理 - Azure App Service | Microsoft Learn より引用

今回フォーカスしたいのはこの同じリソースグループ内に存在しているプラン間でのみ移動可能という点です。例えば同じプラン内に開発用環境のアプリと本番用のアプリを作っていたが、規模が大きくなったり、セキュリティ上の観点からリソースグループを分けたいという需要があると思います。
この場合、現状の同一リソースグループ間のみの制限があると App Service Plan は同一のリソースグループにしか置けなくなりますね。

アプリの移動後にプランを別のリソースグループを移動してしまえば別のリソースグループのプランを移動可能

簡単なことだったのですが、App Service Plan は比較的簡単に影響が少ない状態でリソースグループの移動が可能です。そのため、下記のような手順でApp Service のアプリを別のリソースグループにあるプランに移動可能です。

  1. 移動元のプランと同じリソースグループに移動先のプランを作成もしくは移動する
  2. アプリを移動先のプランに移動する
  3. 移動先のプランを別のリソースグループに移動する

こうすることで別のリソースグループにあるプランでもアプリを移動することが可能でした。
是非、皆さんもお試しください!!

Azure SignalR Service の価格形態を調べてみた【コスト見積・最適化】

Azure SignalR Service の課金形態や価格要素を調べてみました。

Azure SignalR Service とは

Azure SignalR Service の基本的な機能や使い方についての説明については別の記事で紹介しています。ぜひこちらをご参照ください。
onarimon.jp

Azure SignalR Service の価格形態について


Azure SignalR Service の課金形態について調べてみました。課金要素としては「価格レベル」、「ユニット数」、「メッセージ数」がキーになります。

まず「価格レベル」ですが、現在のところ Free, Standard (標準), Premium の3種類のレベルがあるようです。 価格レベルによって同時接続数(コンカレント接続数)やメッセージ数の制限、SLA、 最大ユニット数などが変わってきます。

続いて「ユニット数」ですが、Azure SignalR Service におけるインスタンス数みたいなものです。1ユニットごとに同時接続数や1日にやり取りできるメッセージ数が変わります。

最後に「メッセージ数」ですが、Standardレベル、Premiumレベルでは1ユニットごとに日単位で100万メッセージまでは費用がかかりません。1日でそれ以上のメッセージが必要な場合は使用した分追加で課金が発生します。

これらの課金要素により Azure SignalR Service の課金が決定します。自分は最初勘違いしていたのですが、接続数は間接的にはコストに影響しますが、直接接続した数での課金は発生しません。詳しくは下記の Microsoft 公式ドキュメントをご参照ください。
azure.microsoft.com

Azure SignalR Service の価格レベルを選定する方法

価格レベルを選定する方法についてです。ちょこっと試すなどテスト用の環境であればFreeレベルで大丈夫です。

本番の環境であれば StandardレベルかPremiumレベルを選択しましょう。 Standard と Premium の大きな違いはSLAと「可用性ゾーン」、「ユニットの自動スケーリング」、「カスタムドメイン」が使えるかの違いです。特に影響が大きいのが「ユニットの自動スケーリング」だと思います。自動スケーリングがないとボトルネックになるのが同時接続数ですね。使用するアーキテクチャで同時接続数が最大値を超える可能性があるなら Premium プランにして自動スケーリングを設定した方がよいと思います。

最後に

Azure SignalR Service の課金形態を紹介しましたが、シンプルでわかりやすい課金形態だったと思います。ぜひ、Azure SignalR Service をどんどん使ってみてもらえると幸いです。ご拝読ありがとうございました。

Microsoft認定DP-420試験で Azure Cosmos DB Developer Specialty を取得した話【勉強方法・試験範囲・出題形式】

Azure Cosmos DB 特化の Microsoft 認定試験「DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB」とその試験に合格と認定される資格「Azure Cosmos DB Developer Specialty」について受験して無事合格することができたので受験体験記を残そうと思います。

DP-420 試験を受験した私のスキルセット、技術背景について

普段は Microsoft Azure をベースにしたWebアプリケーション開発を行っているエンジニアです。データベースに関してはRDB(Relational Database)での開発をメインで行ってきたため、今回の Azure Cosmos DB のような NoSQL のデータベースの知識はあったものの開発経験はあまりありませんでした。

Microsoft Azure に関しては自主的に情報を集めたり、勉強会に参加したりしていてMicrosoft 認定資格の受験も積極的に行っています。 下記が私の Microsoft 認定資格の取得状況です。
www.credly.com

試験概要 DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB

それではDP-420試験の概要ですが、どんな試験なのかを紹介します。Microsoft Learn 公式ページより引用します。
この試験の受験者には、データを格納して管理するクラウドネイティブ アプリケーションを設計、実装、監視するための専門領域知識が求められます。

このロールの責任には、データ モデルとデータ分散の設計および実装、Azure Cosmos DB データベースへのデータの読み込み、ソリューションの最適化と維持が含まれます。 これらのプロフェッショナルは、ソリューションを他の Azure サービスと統合します。 また、セキュリティ、可用性、回復性、パフォーマンスの要件を考慮したソリューションを設計し、実装し、監視します。

この試験の受験者には、Azure 向けアプリの開発と Azure Cosmos DB データベース テクノロジの使用に関する確かな知識と経験が求められます。 Azure Cosmos DB .NET SDK for SQL API を使用するアプリケーションの開発に習熟している必要があります。 効率的な Azure Cosmos DB SQL クエリを記述し、適切なインデックス ポリシーを作成できる必要があります。 JavaScript でサーバー側オブジェクトを作成した経験が必要です。 さらに、Azure でのリソースのプロビジョニングと管理に精通している必要があります。 JSON を解釈できること、C# または Java コードを読めること、PowerShell を使用できることが求められます。

試験 DP-420: Microsoft Azure Cosmos DB を使用したクラウドネイティブ アプリケーションの設計と実装 - Certifications | Microsoft Learn より引用

試験名のとおり、Azure Cosmos DB に特化した試験となっています。特にAzure Cosmos DBの設計や構築方法、Azure Cosmos DB を使用したアプリケーションの開発スキルや管理方法が求められています。実際に試験を受けた印象もこの概要と同じような印象を受けます。

Azure Cosmos DB Developer Specialty 認定について


DP-420 試験に合格すると Azure Cosmos DB Developer Specialty 認証資格を取得することができます。

現在、Microsoft 認定資格は基本レベルの Fundamentals 、中級レベルの Associate 、上級レベルの Expert 、専門的なスキルに特化した Specialty の4レベルに分けてカテゴライズされています。
Azure Cosmos DB Developer Specialty は名前のとおり Specialty のカテゴリーになります。この認定資格の受験者に求められるのは Azure Cosmos DB に関するあらゆる専門知識ということです。シンプルですね。

出題形式

他の Microsoft 認定資格の試験と変わらない出題形式で出てきました。最近のMicrosoft 認定資格の出題方式は大きな変更はないと見てよさそうです。

  • 選択問題:択一式、多肢選択式
  • 並べ替え問題:操作の手順やコマンドの実行順などを問う問題
  • 2択問題:一度回答したら戻ることができない一度でもMSの試験を受けたことがある方はわかるあの問題です
  • ケーススタディ。→要件の文章を読み解いて解答する問題
  • (ラボ問題はありませんでした)

試験範囲

  • データ モデルの設計と実装 (35–40%)
  • データ分散の設計と実装 (5-10%)
  • Azure Cosmos DB ソリューションを統合する (5-10%)
  • Azure Cosmos DB ソリューションを最適化する (15-20%)
  • Azure Cosmos DB ソリューションを維持する (25-30%)

試験範囲としては CosmosDB のデータモデル設計の部分の割合がかなり大きいですね。実際に受けてみてもその印象が強かったです。

試験範囲や出題割合は変更される可能性があります。最新の情報はMicrosoftの公式ページをご覧ください。 されに詳しい出題内容は上記の公式ページリンクの中にあるヒントのDP-420 学習ガイドが参考になると思います(英語ですが)。

おすすめの学習方法

  • Microsoft Learn での勉強
    MCP試験では定番の勉強方法ですが、Microsoft公式Learn がDP-420試験向けにもかなり充実しています。下記のDP-420のコレクションのラーニングパスをすべてこなすだけでも上記で紹介した試験範囲の内容の多くに触れることができたという実感です。
    またMicrosoft Learn の内容も進化していてラボが Virtual Machine の開発環境が立ち上がって実際に CosmosDB の操作や VSCode を使ったSDKのコーディングをできるようになったため、かなり便利になっていました。自分の勉強においても Microsoft Learn の影響がかなり大きかったと思います。
    コース DP-420T00: Microsoft Azure Cosmos DB を使用したクラウドネイティブ アプリケーションの設計と実装 learn.microsoft.com

  • 勉強会の動画を見ての勉強
    これは自分が受験後に参加した勉強会で聞いたセッションでDP-420試験の内容に良さそうなものがあったので共有しておきます。JAZUG(Japan Azure User Group)12周年イベントのマイクロソフト畠山 さんの「俺の Azure Cosmos DB - 本番アプリを作る上で知っておきたいこと -」というセッションになります。
    58:20~ぐらいから始まるセッションです。時間に余裕があれば他のセッションもご覧ください、LTで私も登壇しております。
    youtu.be こちらの動画ではCosmos DB でモデリングの話が多く紹介されているため、先ほど紹介したDP-420試験範囲にも重なる部分が多かったと思います。何よりわかりやすかったので一度見ていただけると理解が深まると思いました。

受験結果・受験した感想

受験した結果1回目はギリギリで不合格、リベンジマッチの2回目で合格することができました。
試験概要や試験範囲に出てきたとおり、Azure Cosmos DB の問題特化です。Microsoft Learnで出てきたようなソースコード自体の内容や意味を問う問題から、Azure Cosmos DB というよりも NoSQL のデータベースの設計や効率化などを考えさせられるような問題が多かった印象です。Azure 系の Microsoft 認定資格の試験では管理系の質問が多くアプリケーション開発者としては聞きなじみの少ない問題も多かったのですが、DP-420試験に関しては解きやすい印象がありました。 先ほども述べたとおり、Microsoft Learn のDP-420のラーニングパスが充実しているのでそれだけでも試験に望めそうな印象です。

この試験を受験したことにより、RDB脳だった私に革命が起きた気がします。全く違う考え方のDB設計や考え方となるため、驚きや発見が多く、資格勉強がとても為になったと実感しています。これを機会にCosmos DB を使ったアプリケーションを何か構築してみたくなりました。

この記事を見て DP-420、そしてAzure Cosmos DB に興味を持ってくださる方がいれば幸いです。ご拝読ありがとうございました。

参照ページ一覧

learn.microsoft.com

learn.microsoft.com

learn.microsoft.com

youtu.be

Microsoft認定 AZ-700「Designing and Implementing Microsoft Azure Networking Solutions」合格体験記【勉強方法・試験範囲・出題形式】

Microsoft Azure の認定資格「AZ-700: Designing and Implementing Microsoft Azure Networking Solutions」認定試験に合格したので受験記録を残そうと思います。
※秘密保持ルールに抵触しない範囲の内容となりますご了承ください。
※こちらの記事の内容は2022年7月12日時点での情報です。試験範囲や試験名などの情報は変わる可能性がありますのでご注意ください。

受験者の私のスキルセット、背景について

私自身はAzureを用いたアプリケーション開発をメインに行っており、ネットワークエンジニアとしての知識はあまりないです。
ただし、開発においてAzureアーキテクチャを構築することが多いため、Azure PaaSリソースのネットワーク周りをいじることは多々ありました。今回はAzure開発をしていてAzureネットワーク周りの知識を身に着けるいい機会だなと思い、今回AZ-700試験の受験を決めました。

AZ-700: Designing and Implementing Microsoft Azure Networking Solutions 試験概要

Microsoftの公式ページによるとAZ-700試験の受験者に求められている知識は下記のような内容です。

この試験の受験者は、ハイブリッド ネットワーク、接続、ルーティング、セキュリティ、Azure サービスへのプライベート アクセスなどの分野にわたり、Azure ネットワーク ソリューションの計画、実装、保守に関する専門知識を持っている必要があります。 また、この試験の受験者は、Azure 管理のエキスパート レベルのスキルを持ち、ネットワーク、ハイブリッド接続、ネットワーク セキュリティについての広範な経験と知識を持っていることが必要です。

試験 AZ-700: Microsoft Azure ネットワーク ソリューションの設計と実装 - Learn | Microsoft Docs より引用
試験名でもわかるとおり、Azure ネットワーキング周りの知識が求められています。実際に試験を受けてもイメージどおりの内容だったと思います。

「Microsoft Certified: Azure Network Engineer Associate」認定

AZ-700試験に合格することでMicrosoft認定資格「Microsoft Certified: Azure Network Engineer Associate」の認定資格を得ることができます。認定資格に求められる知識などはAZ-700試験とほとんど一緒ですね。職務としてはネットワークエンジニア向けと書かれていますが、Azureを構築する上でAzureネットワークの周りの知識は必要になってくるので、Azureのアーキテクチャを構築する者であれば、必要な知識セットを得ることができる資格だと思います。

Azure Network Engineer Associate 認定資格の受験者は、ハイブリッド ネットワーク、接続、ルーティング、セキュリティ、Azure サービスへのプライベート アクセスなどの分野にわたり、Azure ネットワーク ソリューションの計画、実装、保守に関する専門知識を持っている必要があります。
このロールには、Azure ネットワーク ソリューションの推奨、計画、実装などの責任があります。 このロールを担うプロフェッショナルは、パフォーマンス、回復性、スケーリング、セキュリティに関するソリューションを管理します。 Azure portal に加え、PowerShell、Azure コマンド ライン インターフェイス (CLI)、Azure Resource Manager テンプレート (ARM テンプレート) などのその他の方法を使用して、ネットワーク ソリューションをデプロイします。
Azure ネットワーク エンジニアは、ソリューション アーキテクト、クラウド管理者、セキュリティ エンジニア、アプリケーション開発者、DevOps エンジニアと連携して、Azure ソリューションを提供します。
この認定資格の受験者は、Azure 管理のエキスパート レベルのスキルを持ち、ネットワーク、ハイブリッド接続、ネットワーク セキュリティに関する幅広い経験と知識を持っていることが必要です。

Microsoft Certified: Azure Network Engineer Associate - Learn | Microsoft Docs より引用

出題形式について

他のMicrosoft認定資格と変わらない出題形式で出てくると思います。

  • 選択問題(択一式、多肢選択式)
  • 並べ替え問題
  • 一度回答したら戻ることができない2択問題(一度でもMSの試験を受けたことがある方はわかるあの問題です)
  • ケーススタディ

最近の流れの通り、ラボ問題はありません。

試験範囲について

公式ページで公開されている試験のスキル範囲アウトラインの情報をまとめてみました。

  • ハイブリッド ネットワーク接続の設計、実装、管理 (10-15%)
    S2SVPN、P2SVPN、ExpressRoute
  • コア ネットワーク インフラストラクチャの設計および実装 (20-25%)
    Vnet、Private Endpoint、Azure Firewall、Application Gateway、Vnet Integration、Route Table、DNS Zone、Vnet peering、Azure Virtual WAN、NVA
  • ルーティングの設計と実装 (25-30%)
    ユーザー定義ルート、Azure Load Balaner、Azure Application Gateway、Azure Front Door、Azure Traffic Manager profile、Azure Virtual NAT
  • ネットワークのセキュリティ保護と監視 (15-20%)
    Azure Firewall、NSG、WAF、Azure Monitor
  • Azure サービスへのプライベート アクセスの設計と実装 (10-15%)
    Azure Private Link、Azure Private Endpoint、Service Endpoint、Vnet Integration

アウトラインの中で出てきているAzureサービスを集めてみましたが、やはりAzureネットワーク周りのリソースが多く挙げられていることがわかります。 さらに詳細の試験範囲については公式ページの試験スキルのアウトラインをダウンロードしてご確認ください。

学習方法について

AZ-700試験の勉強方法ですが、Microsoft認定資格定番の勉強方法である MS Learn にある AZ-700 試験のラーニングパスをやるのが一番だなと思います。
docs.microsoft.com
基本的に試験範囲に合わせて作られているので、試験に出てくるリソースを学んで触ることができると思います。一部リソースを作るのにサンドボックス環境がなく、自分の環境にリソースを作る必要があるモジュールがあったので注意が必要でした。あとはMS公式のドキュメントを読みあさって試験に挑みました。

受験結果・受験した感想

受験結果ですが、なんとかぎりぎり合格できました。


Twitterでも呟きましたが、合格点ぎりぎりすぎたので復習していかないといけないなと実感です。AZ-700試験の内容ですが、管理系の問題が多い「Microsoft Certified: Azure Administrator Associate」や「Microsoft Certified: Azure Solutions Architect Expert」などに比べると、技術よりの問題がかなり多いので技術者や開発者にとって受けやすい試験でした。
技術的なスキルを問われることもあり、下記のような点を意識して勉強するとより効果的だなと思います。

  • Azureリソースを作ることができる。正しく設定できる。
  • リソースの設定内容を理解し動作を予測することができる。
  • 要件に合わせて、Azureネットワークのリソースを使ったアーキテクチャを作り上げることができる。

このブログを読んで頂いた方に一人でも多く、AZ-700試験に興味を持っていただき、「Microsoft Certified: Azure Network Engineer Associate」認定が取得できれば幸いです。

学習時参考にさせていただいたページ・受験体験記

AZ-700試験は2021年7月に開始して1年ほどなので日本語のページはほとんどありませんでした。
www.fxfrog.com

参照ページ一覧

docs.microsoft.com

docs.microsoft.com

Azure予約購入コストはEAポータルの使用状況の詳細データには出てこないので Azure Portal から確認できます【Reservations・Reserved Instances】

Azureのインスタンスを予約購入することで割引価格でリソースを利用できる「Azure Reservations(予約購入・Reserved Instances)」ですが、EAポータル から使用状況詳細データに出力されないようです。今回のEAポータルの仕様について調べたことをまとめとこうと思います。

予約の購入金額はEAポータルの使用状況詳細には含まれない

以前EAポータル画面の機能紹介の記事でも紹介しましたが、EAポータルにある「レポート」→「使用状況のダウンロード」から各月ごとの使用状況の詳細をダウンロードすることができます。
onarimon.jp

このEAポータルからダウンロードした使用状況の明細にはAzureで予約購入した分のデータは出てきません。ちなみにAzureEAポータルの「使用状況の概要」で出ている請求料金の合計には予約購入した金額はちゃんと計算されているようです。そのため、明細の合計と請求金額に差異が発生します。EAポータルのAPI(Azure Enterprise REST API)を利用して取得したデータも同じく予約購入金額の明細は取得できないようです。

この現象ですが、Microsoft Supportの方に確認したところ、EAポータルの仕様のようなのでEAポータルの使用状況で予約購入のコスト明細を確認する方法は現在のところなさそうです。回避策ですが、これから紹介する方法なら明細を確認できそうです。

予約購入を含めた使用状況明細が欲しい場合は Azure Portal のコスト管理画面から出力できる

今年になってAzure Portal の 「コスト管理 + 請求(Cost Management and Billing)」からEAポータルで取得できる情報と同等のデータを取得したり管理できるようになりました。
azure.microsoft.com

Azure Portal の「コスト管理 + 請求」であれば予約購入の明細が出力されるみたいですね。

Azure Portal から使用状況詳細をダウンロードする方法

「コストの管理と請求」→「課金スコープ」のページに移動し、今回詳細をダウンロードしたい課金スコープに移動します。

「使用量 + 請求金額」に移動し、データを取得したい月のダウンロードリンクをクリックします。

「使用量と請求金額をダウンロードする」から使用状況詳細、 Marketplace ストアの請求料金、価格シート、残高と概要などのデータをダウンロードできます。各項目の「ドキュメントの準備」をクリックするとデータの準備処理が始まり、データをダウンロードする準備が完了すると「ドキュメントの準備」ボタンが「CSVのダウンロード」ボタンに変わります。

ダウンロードしたデータの明細には予約購入したコストのデータがあることが確認できます。
今までAzureコストの分析をEAポータルのAPIを使って独自に構築していましたが、今後はAzure Portal側のAPI(Azure Billing REST API)を使っていくことになりそうかなと思っています。

Azure Reservations(予約購入・Reserved Instances) の関連記事

Azure Reservations を購入・導入したときの話。
onarimon.jp

Azure Reservations の使用率が100%適用されなかったときの話です。
onarimon.jp

参考ページ

azure.microsoft.com

docs.microsoft.com

Azure Resevationsで条件を満たしているのに使用率が100%にならない現象に遭遇した【Reserved Instance・予約割引】

Azureの予約割引(Azure Resevations・Reserved Instance)で条件をみたしているはずなのに使用率が100%にならない現象が確認できたのでトラブルシューティングや解決方法を紹介します。

AzureのResevations の購入方法について

AzureのResevations の購入方法については以前、本ブログで紹介した記事をご覧ください。
onarimon.jp

予約使用率が100%でない日が発生した

以前、購入した予約を導入して数週間、毎日予約の使用率100%を維持していたのですが、ある日突然使用率が100%になっていない日を発見(6/11)
(画像一番右の最新日に関しては、情報の更新が遅れているだけなので問題ありません。)

購入した予約はApp Service Plan に適用しており、対象リソースは24時間インスタンス1以上で動かしていたので使用率100%を下回ることのは想定外であったため、調査を開始しました。

予約使用率が0%になる・使用率が一致しない場合のトラブルシューティングを確認

まずはMicrosoft 公式ドキュメントから「 Azure 予約の使用率がゼロ (0) と表示されたり、使用率が一致しない件」のトラブルシューティングが公開されていたため、そちらを参照しました。
Azure 予約使用率のトラブルシューティング | Microsoft Docs
↑のページに書かれている一般的なトラブルのシナリオはまとめると下記のようなパターンがあるようです。

  • 使用率の値が一致しない場合は使用状況データの到着が遅れている可能性があり、最低でも2日以上待つ必要がある
  • 予約適用中のリソースを停止して、別のリソースの実行を開始した場合は購入した予約には適用されない可能性があるので予約を交換する必要がある
  • リソースを移行したため、予約対象スコープからはずれた
  • 予約適用中リソースを停止したため適用が停止された
  • 予約のスコープを変更したため、リソースがスコープからはずれた
  • 約の対象となったサブスクリプションが削除された

今回のパターンではリソースや予約のスコープは一切変更しておらず、公式のトラブルシューティングのシナリオには当てはまっていませんでした。この時点で原因がわからなかったため、 Microsoft Azure 課金サポートに問い合わせてみることにしました。

Azure Resevationsについてサポートの方に問い合わせるときに必要な情報について

今回の現象についてサポートに問い合わせた際に下記のような情報が含まれたスクショが必要となりました。問い合わせの最初からこちらの情報を提供するとスムーズにサポートが進みそうです。

  • 英語表記で、アドレスバーおよびアカウント情報、選択しているディレクトリの確認が可能な全画面
    小さくて見にくいですが、具体的には下記のような画像を添付して送るとよさそうです。該当の予約の概要から確認できる画面です。

原因はAzure側で予約が適用されなくなる事象が発生したことによるものだった

サポートの方に調べていただき今回の現象はAzure 側で発生している事象であることがわかりました該当の事象が発生している間の従量課金についてはすでに返金プログラムが進んでいるとのことで今回の現象については解決しました。

Azure側の要因で予約の適用がうまく行われない事象についての補足

一応、今回の現象についてサポートの方に追加で質問を何点か行ったため、参考までに追記しておきます。

Q. 今回のような現象はたまに発生するのか

今後も発生する可能性はあるとのことです。利用者としてはその事象を補則する機能などあると嬉しいですがいまのところはないようなので使用率を監視するなにかを実装する必要があるかなと考えています。

Q. 今回の現象は自分の環境でのみ発生したのか?Azure全体で発生したものか?

Azure 全体で発生していたようです。

Q. 今回のような現象が発生した場合、本来自動で返金されるか?

今回のように大規模な事象の場合は自動で返金されるみたいです。ただし、発生する事象の規模によっては問い合わせによって発覚するケースもあるみたいなので前述したとおりなにかしらの使用率を監視する仕組みは欲しいところです。

Q. 今回のような事象が発生したことを通知などで受け取る。もしくはAzure Portal上で確認できるか?

今回のような事象を通知する仕組みはないみたいです。何かあった場合は問い合わせする必要があるとのこと。

Q. 今回のような事象で使用率が100%でなくなったが、返金処理後に使用率は修正されるか?

返金実施後も予約の適用率は100%にならないみたいです。

参考リンク

Azure 予約使用率のトラブルシューティング | Microsoft Docs