しばやん雑記

Azure とメイドさんが大好きなフリーランスのプログラマーのブログ

Hack Azure! #7 - 次世代 Serverless アプリケーションアーキテクチャ!フォローアップ

App Service / Azure Functions の Availability Zones 対応が GA となり、今後のアーキテクチャ設計への大きな変化となることは確信していたので、この辺り話したいな思っていたら話すことになったのが今回です。

要するに PaaS / Serverless で Availability Zones をフル活用したアーキテクチャについて話す会です。

基本は配信のアーカイブを見てもらえれば良いのですが、配信だとドキュメントや補足が難しいことも多いので出来る限りこのようなフォローアップを書くようにしています。

相変わらず長くなったので、以下から興味のある部分をピックアップしてもらえれば良いです。

Azure の Availability Zones は設定から有効化すれば、後はプラットフォーム側にお任せというパターンが多いのでゾーン冗長にするだけなら簡単ではありますが、意図せず SPOF を作らないためにはサービスの選択には注意が必要な印象です。特にストレージ周りは注意したいです。

Twitter まとめと YouTube アーカイブ

例によって Twitter のまとめと YouTube でのアーカイブがすでに公開されています。

特に今回は Twitter のコメントが盛り上がって自分としても凄く勉強になったので、一通りアーカイブを合わせて参照してもらうと良いかと思います。

AZ に対応した App Service Plan が Azure Portal で簡単に作れるようになるまでは、基本的に ARM Template か Terraform を使うことになると思います。

既存の App Service Plan を AZ 対応に変更する機能は永久に来ないと思うので、作成前に設定しましょう。

Azure Availability Zones について

これまで App Service や Azure Functions といった PaaS / Serverless なコンピューティングサービスを使っていると、ASE を除いては全く意識することがなかったのが Availability Zones です。

詳細は公式ドキュメントに任せますが、App Service / Azure Functions では完全に Availability Zones の存在を隠して利用できるようになっているので、これまでと使い方は全く変わらないのが特徴です。

AZ に対応したサービスの一覧を確認すると、素の VM 以外はほとんど対応している状況です。

個人的には App Service / Azure Functions は最後の 1 ピースだと思っていたので、今回のアップデートで盤石になったなという印象です。APIM は例外感ありますが、今後対応するでしょう。

App Service / Azure Functions の AZ 対応

既に App Service のゾーン冗長に関しては以下のエントリを書いているので、そちらを参照してください。Premium V2 / V3 と Functions Premium を選んでいる場合に利用可能です。

配信でも話しましたが、最低 3 インスタンスが必要なのでコスト面は考慮が必要です。

Functions Premium に関しては少し遅れて対応が行われたので、少し情報が不足気味ですが公式ドキュメントに必要最低限の設定についてまとまっています。

Consumption Plan に関しては元々 Stamp を超えてスケールアウトする謎設定が用意されていたので、実質的にはゾーン冗長になっていそうな気配もしています。

AZ 対応によって App Service を使った高可用性設計が大きく変わったので、以下のエントリはどこかでアップデート版を書かないといけないなと思っています。

今後のイベントで App Service / Azure Functions の AZ 対応については触れられそうな気がするので、その情報をキャッチアップしながら暇を見つけて対応しようかと思います。

Storage / Cosmos DB / SQL Database の AZ 対応

LRS と ZRS は同期レプリケーションが行われますが、GRS は非同期レプリケーションなので、LRS と ZRS 以外は Azure Functions 向けに使えないことは認識しておきましょう。あと GPv2 必須です。

ストレージをゾーン冗長にするには作成時に ZRS に設定するだけなので簡単です。ただし既存の LRS / GRS を ZRS に変更するのは簡単には行えないので注意が必要です

一応サポートにライブマイグレーションのリクエストを投げれば行ってもらえるようですが、完了までに時間がかかることもあるようなので、高可用性が必要な場合は最初から ZRS で設計した方が良いですね。

Azure におけるメインストレージとなる Cosmos DB と SQL Database は Serverless を選んでもゾーン冗長を有効化できるので、個人的にはかなり熱いと思いました。

SQL Database は一部の Tier はプレビュー扱いなので注意が必要ですが、アーキテクチャを見る限りは ZRS を利用したシンプルなものなので、そう遠くない未来に GA するのではと思います。

この辺りは GA したタイミングでムッシュが詳しくブログで説明してくれるはずです。

SQL Database Serverless のアップデートと同時に AZ 対応の GA も期待したいところです。

Key Vault Reference と Identity-based connection

Twitter でいくつか話題になった Key Vault Reference と Identity-based connection ですが、前者に関しては当たり前のように使っている方は多いのではないかと思います。

User Assigned Managed Identity も使えるようになったので、さらに管理しやすくなっています。

最近は安全に Azure リソースにアクセスするために、Managed Identity と RBAC を使ってシークレットレスを実現する例も増えてきていますが、少し前に Azure Functions のバックエンドで使われる Azure Storage 自体に対して、Managed Identity でアクセスできる機能がプレビューで公開されています。

Azure Functions の Identity-based connection は全体的にプレビューとなりますが、ARM Template や Terraform との相性が良いので GA のタイミングで全体的な移行を検討したいところです。

Stamp 単位でのアップデートと regression の回避

個人的には App Service の AZ 対応によって、マルチリージョンを選択する機会はほぼ無くなったかと思っていますが、河野さんから以下のツイートで 1 点ツッコミが入りました。

確かに Stamp 自体が AZ に跨ってデプロイされているので、アップグレードは AZ を考慮せずに行われます。当然ながらリグレッションがあれば AZ 関係なく影響を受けるでしょう。

そのあたりを考慮したとしても、自分の意見としては以下のようになります。

App Service のアップグレードは当然ながらテストしながら段階的に行われるのでほとんどのケースで安全ですが、特殊な使い方をしている場合には影響を受ける可能性も十分にあるので注意しましょう。

高可用性が必要な場合は Run From Package か Docker Image を利用して出来るだけ環境依存部分を減らしつつ、イミュータブルなデプロイを行うのが鉄則かと考えています。

Static Web Apps を活用した開発について

配信の最後の方で告知した Static Web Apps に関するくらでべの動画が先日公開されたので紹介します。

当初は 20 分ぐらいの予定でしたが、あまりにも喋りすぎたので倍近くになっています。とても長い。

Hack Azure #6 の内容と若干被ってはいますが、最新の情報でアップデートしているので是非ご覧ください。

それではまた次回の Hack Azure でお会いしましょう。