fukasawah.github.io

MCP資格のAZ-204に合格しました

Cloud Skill Challenge 2022 Mayのバウチャーをもらったので9月に受けてきました。AZ-305を請けるつもりでしたが、対象外だった。間が空いたのはちょっと理由があり後述。

結果は821点で合格でした。セクションごとの成績を見てみましょう。

受験結果のスコア。80%切ってるものが多い。
受験結果のスコア。80%切ってるものが多い。

特に「Azureサービスおよびサードパーティ製サービスの接続と使用」が悲惨です。ロクに実技をしてないことがよくわかりますね。

今回も部屋が汚いので試験センターで受けてきました。試験の流れとかは前回を参照。

やったこと

特に大したことはなく、実務でやっていたことが多かったので受かったという感じがする。

やっておいたほうがいいこと

まず821点ごときの凡々な成績者の言う事なんで話半分に・・・(予防線)

AZ-104を抑えておくとセキュリティ・認証周りはすんなり理解できるはず。

勉強法は、教材を買ってひたすら解いてわからないところを復習、というありきたりな方法はまだ通用すると思います。しかし、今回の試験を受けた感じ、Azureはこういうのを認めていない気がしている。 (もちろん、Udemyなどで教材を売る方は合格に繋がらない教材は買ってもらえなくなるので、そのうちキャッチアップして対応していくだろう)

なので、それ以外にやっておいたほうが良いことはありそうだったので書いてみる。どちらかというと、Azureを使う上でやっておいた方が良いことのほうが近くて、これが試験の役に立つと思ってます。

試験範囲ではないからやらない、のではなく、普段からアップデート情報をキャッチアップしていくのは必要だと思う。Azure Static WebAppsとか大きいものもあれば、MAnaged DiskのZRSサポートといった小さい話とか。(当たり前かもしれないが)

サービスの制限とかを抑えておくと細かい点数を拾えるのでよいでしょう。Azureはサービスの一貫性みたいなのがなく、プランで出来ることが違ったり、なぜできないのかわからない制限、実運用していくと辛くなる制限も多いです。最近こんなもんをサービスの数だけ覚えないといけないのはなんか違うのでは、という気はしています。

あとは時代の流れ(?)というものがあると思っていて、ゾーン冗長、Azure AD認証(マネージドIDなど)、プライベートエンドポイント接続あたりを推していると感じています。

ゾーン冗長はもちろん可用性のためであり、ゾーン冗長のサポート無しのサービスをゾーンレベルの可用性を取るように複数台構成を運用するのはシンドイ。

Azure AD認証はシークレットレスな運用を推し進めることでセキュアにしていく狙いがありそうで、リソース毎に払い出されるアカウントキーとかは今後使わないのが普通になっていくのではないか。チュートリアルでは当たり前のように使っているが、正直アカウントキーをどう管理するかを踏まえて説明するか、警告だしてあげるとかしてあげてほしさがある(過剰すぎ?)

プライベートエンドポイント接続は、通信をVNET内に閉じさせたいという 厳しい お客様は未だに数多くいて、プライベートエンドポイント接続のサポート状況で採用できるサービスやプランが変わる事も多いです。

バウチャーがすぐもらえなかった

割引を受けるには、受験をスケジュールするときにCloud Skill Challengeを受けた際のメールアドレスを入力すると、バウチャー(割引)を適用されるので、以降はスケジュールを組む、という流れ。しかしなぜか Cloud Skill Challengeを受けた際のメールアドレスを入力しても、適用されなかった。反映が遅れてるとか思っていたが、6月でも解消していない状態でした。

しばらく忘れていて、思い出す都度試してもやっぱり適用されなかったので、9月にCloud Skill Challenge 2022 Mayに関する問い合わせを日本語でしたら、その日のうちに「メールアドレス、受けたCloud Skill ChallengeのURL、進捗が分かる画面のスクリーンキャプチャをくれ」と英語で返されました。多分、定型文なんでしょう。

そのメールに返信して3日ぐらいでメールで直接バウチャーのコードが送られてきた。期限は12月までだったような気がする。今回はそれで受けてきました。

最近のAzureとお仕事の感想

あまり愚痴を書ける機会がないし、自分のblog何だから好きに書く。

ちょこちょこAzureの構成案を見ることがあったが、いつもコストとサービスの組み合わせの難しさを思う。

インスタンスを立てる系のリソースは、PaaS,SaaSを選ぶとIaaSの2倍弱になるし、可用性を取りに行くと2倍はあっという間に超える。データ冗長性も2倍程度かかるが、データの規模が少ないならよっては許容できることが多い。このあたりのせいで最低構成と理想構成みたいな松竹梅でプランを分けて見積もりを取ってほしいという事を言われがちになっている。

これは別にAzureが暴利を取っているとかではなく、妥当かむしろ安いぐらいだと思っている。

どちらかというと、顧客が求めているレベルが上がりすぎている。

データを失うな、絶対にサービスを落とすな、サービスは速く安定して動くようにしろ、というのは気持ちはわかるし、なんなら当たり前になっていると思う。そしてコストを安くしろという。要求はもっともではあるが、どれもコストが掛かる。

「データを失うな」は個人的には最低限ではあると思っているのでバックアップぐらいは組み込むが、可用性に関してはかなり懐疑的。実際「もし10分止まったらどれぐらい機会損失を生みますか?金額にすると?」と聞くと具体的な金額が出てくることはほとんどない。あなたのサービスの価値はいくらですか?

また今年、1度だけAzure Functionのデプロイの仕組みを支えるサービスが死んだらしく3時間ほど東日本リージョンのAzure Functionが機能しないことがあった。サポートに問い合わせたらゾーン冗長をしていても防げなかった類ときいており、ゾーン冗長とは何かを考えさせられた。リージョン・ゾーン・ラックとかそういう物理単位は横に並べることはできるが、サービスは横に並べられず、もしやるならマルチクラウドをやるようなものとなり現実的ではないと思う。

その結果、通信がネックになっても処理はできるようにリージョン冗長し、TrafficManagerで1分以内に切り替えできるよう設定しつつ、DBのメインは東日本におきつつ、プライベートエンドポイントを通して西日本からアクセスできるようなホットスタンバイ構成を組んだりした。ただ、DB死んだらサービス止まる構成なので、さほど良い構成ではないと思う。そういうレベルで考えていくのは何か違う気がしている。本当求められているのか?

いつもいい答えが出ないままスケジュールに追われて「しゃーない、これでやるか」と妥協する日々。答えを教えておくれ。