「クラウドアプリケーション 10の設計原則 「Azureアプリケーションアーキテクチャガイド」から学ぶ普遍的な原理原則」を読了した。楽しいとか、そういうものではなくて、クラウドアプリケーションのアーキテクチャの原則なので、読んで損することはなし。こういう設計や作りになっているとベターというものが書かれている。まぁ、そのように作られていないアプリケーションも多々あるのだけど、ベストプラクティスがこうなっているというフィット＆ギャップも悪くない。学ぶことは多いはず。
個人的には、本編よりもメモの部分の方が楽しかった。補足的なところがためになる。
やれること、やれないことはあるので、原則は原則と思ってよむといい。
Pythonとしての各バージョンとサポート期限は下記。概ね5年間のサポート。ただし、リリースされてからでないと、各種フレームワークなどが追随してこない。リリースされてから、開発等を始めるとすると、利用できる期間は4年間程度。開発会社によっては、常に最新のものを追いかけず、1つ前のバージョンをつかったりする可能性もあるので、もっと短くなる可能性もある。
Pythonのリリースとサポート期限の一覧
https://devguide.python.org/versions/
Azure App Serviceの場合、Python 3.11のバージョンは指定できるが、Python 3.11.xのようなパッチバージョンまでは指定できない。サポートポリシーによると、Azure側でアップデートが行われる。言語のサポートが終了してもすぐに使えなくなるわけではなく、Azureのポリシーとしては「特定の言語のコミュニティ サポートが終了しても、アプリケーションは変更することなく引き続き実行できます。」とのこと。
App Service 言語ランタイムのサポート ポリシー
https://learn.microsoft.com/ja-jp/azure/app-service/language-support-policy
Azure Functionsの場合は、ランタイムバージョン毎に、利用できる言語のバージョンが決まっている。そのため、利用したい言語のバージョンに合わせて、ランタイムバージョンを選択する必要がある。そして、言語側のサポートが終了すると、Azure Functionでも、サポートが終わる。
Azure Functions でサポートされている言語
https://learn.microsoft.com/ja-jp/azure/azure-functions/supported-languages
Azure FunctionでのPythonのサポート状況と、サポート終了のお知らせ。
https://azure.microsoft.com/ja-jp/updates/azure-functions-support-for-python-36-is-ending-on-30-september-2022/
Azure Active Directory（Azure AD）が名称変更を行うとのこと。新しい名前は、Microsoft Entra ID。わかりにくい。
製品群は変えてもよいと思うけれど、Azure ADのところまで変える必要はなかったような気がする。この先の読み替えとか、会話が混乱する気しかしない。それに、どこかに落とし穴とかありそうで怖い。結果的に、セキュリティ事故につながらなければいいのだけど。注意しないといけない。
急に.NET6（.NET 3.1～7も）のNpgsqlからAzure Database for PostgreSQLへの接続ができなくなった。
アプリケーション側からみると、Azure側のPostgreSQLに強制切断されているようにみえるログが出ている。
---> Npgsql.NpgsqlException (0x80004005): Exception while writing to stream
---> System.IO.IOException: Unable to write data to the transport connection: 既存の接続はリモート ホストに強制的に切断されました。.
---> System.Net.Sockets.SocketException (10054): 既存の接続はリモート ホストに強制的に切断されました。
at System.Net.Sockets.NetworkStream.Write(Byte[] buffer, Int32 offset, Int32 count)こうなると、通常考えるのは、AzureのPostgreSQLで、コネクション数があふれているとか、高負荷状態とか、DBaaSの制約（PostgreSQL設定の外側）が原因じゃないかということ。これを１つ１つ調べていくと、異常なし。Azure側には問題が見当たらず。DBのログをAzureの管理ページがダウンロードして確認してみると、下記のログがあり。
could not receive data from client: An existing connection was forcibly closed by the remote host.AzureのPostgreSQLからみると、クライアント側が切断しているとのこと。
調べてみると、「Azure Database for PostgreSQL Single server」は、ルート証明書が変更されていることがわかった。.NETで、Ngpsqlを使っている場合は、「Baltimore CyberTrust Root」と「DigiCert Global Root G2」が使うWindows（Windows Server含む）にインストールされている必要があるとのこと。ルート証明書の確認をすると、「DigiCert Global Root G2」が存在していなかった。これが原因なので、下記のマイクロソフトの内容に従い、確認して作業した。
Understanding the changes in the Root CA change for Azure Database for PostgreSQL Single server
https://learn.microsoft.com/en-us/azure/postgresql/single-server/concepts-certificate-rotation#what-do-i-need-to-do-to-maintain-connectivity
今回足りていなかったのは、「DigiCert Global Root G2」なので、Digicertのサイトからルート証明書をダウンロードした。
https://www.digicert.com/kb/digicert-root-certificates.htm#roots
（「Download DER/CRT」をクリックして、CRTファイルをダウンロード）
CRTファイルを、ルート証明書が足りていないサーバに持っていき、ダブルクリックして、ウィザードからルート証明書をインストールした。配置場所は自動選択させることでルートのところにインストールされた。
なお、ルート証明書のインストール後のOS再起動はしなくても、ルート証明書を使い始めた。
企業用のMicrosoft 365でログイン時に2段階認証を求められるようになったと、急に言われ始めた。もともとMFAのところは設定していないので、2段階認証が求められるはずはないはずだが。
念のため調べてみると、Microsoft 365の画面の「ホーム ＞ セットアップ ＞ 多要素認証 (MFA) の構成」で、「完了」のところに緑チェックマークがついている。
ここの管理をクリックすると、Azure ADの管理画面が開く。概要のプロパティのタブを開くと、「お客様の組織は、セキュリティの既定値群で保護されています。」に緑チェックマークがついている。セキュリティの規定値で、MFAが有効化されているので、M365のログイン時に、2段階認証のMicrosoft Authenticatorの登録が促されていた。MFAを無効化する場合は、ここの「セキュリティの既定値の管理」をクリックして、設定を変更する。
この規定値については、下記の「Japan Azure Identity Support Blog」にあるように、自動的に有効化されたため。
2022 年 6 月末から「セキュリティの既定値群」の有効化が促されます (対象 : 一部のテナント)
https://jpazureid.github.io/blog/azure-active-directory/security-default-2022/
今日の夕方くらいから、Microsoft Azureで大規模な障害が発生した。原因は、AzureのWANの設定変更によるものだそうだ。詳細は、今後、ニュースサイトで掲載されるであろう。
設定変更の確認を行っていないわけじゃないのだろうけど、巨大なパブリッククラウドのネットワークなので確認しきれなかった、ということなのだろう。ネットワーク系の障害はAWSもやっているし、そのほかのクラウドサービスもやっている。それにしても、Azureの上とそのネットワークでつながっているMicrosoft365系のサービスも一緒に止まったわけで、なかなか大きい障害だった。まぁ、復旧するまで見ているしかないわけだが。
忘れたころに発生するというよりも、忘れそうになる前に、どこかしらの大手のパブリッククラウドがやらかしている気がする。結局、コントロールしようと思うと、オンプレで環境をもっておくのがいいというわけだ。経済的かどうかは、規模や体制にもよるけれど。
1. Azureの管理コンソールにアクセスする。
2. すべてのサービスから、「サービス正常性」を開く。
3. サイドメニューから「計画メンテナンス」を選択する。通知がある場合には、サイドメニューの計画メンテナンスに、（1）のような件数表示がある。
4. メンテナンスの告知が表示されるので、選択して、内容を確認する。
5. 内容を保存する場合には、PDFで出力する。
AppServiceでも、個別のところにはなく、サービス正常性のところに通知がある。そして、複数のインスタンスがあるとき、どれの通知なのかわからない。
サービス停止を伴うものかどうかも、メンテナンスの内容を見てみないとわからない。（サービス停止を伴うもに出会っていないので、なんともいえないけれど）
海外のサイトで「Microsoft Azure: クラウド コンピューティング サービス」でのリソース不足から、新規の契約や新しいリソース割り当てを制限していると報じていた。（元ネタは、Twitterで見たツィート）
要約すると、
という状態とのこと。
クラウド環境の利用と供給が崩れてきており、クラウドサービスが需要を満たすことができなくなりつつあるようです。米国やアジアのリージョンでも需要と供給のバランスが崩れてきているようだ。
サーバもネットワーク機器も、軒並み伸びていて、モノの調達がとても不安定。ネットワーク機器は、深刻で納期が半年～2年とかになっている。サーバもパーツ不足から、納期が延びている。この状況は、一般の会社も、大手の会社も同じような状況。新規で購入しようとしても、買えないので、クラウドサービスの需要が増えている感じ。ただ、モノが買えないのは、クラウドベンダーも同じなので、需要に対して、クラウドサービスの設備増強が追いついていかない状況。規模をどんどん拡大させていくことにより、それをカバーしていたが、COVID-19とウクライナ戦争により、世界の物流に影響が出てしまったことにより、規模の拡大をやりたくても、やれない状況に。この先、１年か、数年か、は同じ傾向がつづくと思われる。
クラウドがダメならば、オンプレミス（自分でサーバなどを買ってきて構築）ということ考えられますが、サーバやネットワーク機器が買えないので、これも難しい。
他のクラウドサービスを利用するとしても、移行するのも大変だし、コストもかかるので、それもつらい。Azureで、リソース制限をしないといけない状況だとすると、AWSでも、Google Cloudでも、同じような状況になる可能性はあるわけだ。なので、サービスの乗り換えでなんとかなるとも思えない。
そのうち、クラウドは電気代などの高騰から、そのうちサービス料金の値上げになるのではないかと。値上げして利用が減ると、たくさん利用するところにクラウドのリソースを割り当てられるので、クラウド業者には、そんなにデメリットはない。むしろ今は、AWS、Google Cloud、Azureで価格競争していたので、安すぎるくらいだし。
結局、何が勝つか？というと、実はオンプレでシステムを維持しているところで、余剰リソースがあるところなんじゃないかと思う。世界では、クラウドからオンプレ回帰の潮流が数年前からあるので（これはクラウドだと要求される処理速度を出すことができないので、自前でやった方がいいとオンプレに戻るサービスが出てきている）。日本は、まだクラウドリフトが流行りだが、クラウドを利用しない方がいいんじゃないだろうか。
Azure VMware Solutionについてオンラインセミナーで聞いたので、そのメモ。価格は別にして、使い勝手はよさそう。
Google Cloud、VMware実行環境提供のCloudSimpleを買収https://www.itmedia.co.jp/news/articles/1911/19/news074.html
ネットワーク設計さえ、ちゃんとやればオンプレのVMwareの仮想マシンは、GCPでもAzureでも、AWS（は専用環境が用意されてる）でも、簡単にV2Vというか移動ができるようになると。意外と、VMware形式でVMを作っておけば、大手クラウド間を移動できる世界になりそうだな。VMwareの狙いは、そこなんだろうけど、実現しつつあるのが面白い。