Azure Copilot Resiliency Agent (preview)

Azure Copilot Resiliency Agent (preview)
すきやねん Azure!! #43
https://sukiyanenazure.connpass.com/event/406646/

Transcript

1. Azure Copilot Resiliency Agent (preview) すきやねん Azure!! #43 FutureOne株式会社 草場 友光
2. • ドラクエ大好き ドラクエ10のプレイ時間→ 1キャラ目：2718時間 2キャラ目：920時間 3キャラ目：803時間 4キャラ目：190時間(配信用) 自己紹介 • 2022/08-2027 Microsoft MVP (Microsoft Azure, Developer Technologies) • tomo_kusaba 第001462号
3. 注意 • 個人の見解・解釈が多分に入っています。 • 見解の相違・事実誤認などありましたらご指摘ください。
4. 今日の目的 • Azure Copilot Resiliency AgentがPublic Previewにな りました。 • そもそも、回復性とはなにか • このエージェントでできることとその限界点を考察していきます。
5. 回復性とは？ • アプリケーション層のリトライとサーキットブレーカー →クラウド上での一時的なネットワーク遮断、サービスの一時的 な利用不可、タイムアウトなどを適切な遅延のあとに再試行する • コンピューティング・ワークロードの冗長性とロードバランサー →実行しているインスタンスの冗長性 • ストレージ・データベースの冗長性と地理的分散 →データーの保護。ゾーン冗長、リージョン冗長。
6. リトライ • 時間をおけば成功する可能性のある失敗 →リトライを実行する (429, 500, 503など) • 時間をおいても成功する可能性のない失敗 →リトライを実行しない （401, 404, 405など）
7. 重複実行とべき等 • リトライで注意しなければならないのがサーバー側で処理が成功 しているのにクライアントが応答を受け取れずに同じ操作をもう 一度送ってしまうケース
8. サーキットブレーカー • 失敗が閾値に達したあと、呼び出し先に回復時間を与えてリソー ス消費を抑えるための自己防衛 →失敗したからと言ってリトライし続けると負荷が負荷を呼び回 復できなくなる可能性 • リトライ処理とセットで設計して一時的な失敗によって傷口を広げ ないようにするための処置
9. コンピューティングリソースの冗長構成 • コード上でどれだけリトライを書いても実行しているインスタンス が1台のみなら、1台の障害でサービス停止 • 基本はインスタンスを増やして、ロードバランサーで正常なインス タンスに要求を振り分ける • このためにステートレスにするか、セッションの外だしが必要
10. App Serviceのゾーン冗長設定例 • Premium v3、 v4のApp Service Planを使用 • ゾーン冗長を有効にする • 2インタンス以上にする • ヘルスチェック用のエンドポイントを用意する • アプリケーションはステートレスにする • セッション状態はInmemoryではなく外部のManaged Radis など外部サービスに保存
11. App ServiceのBlazor Serverのゾー ン冗長の場合追加設定 • WebSocketsを有効化 • ARR Affinityを有効化 • SingletonでDIされたオブジェクトについては読み取りのみに する • さらにスケールアウトする際にはSignalR Serviceの使用を検 討
12. Container Appsを可用性ゾーンに分 散する • Container Apps envirnmentの作成時にゾーン冗長を有効 化 • 最小レプリカ数を少なくとも2にする • Ingressを有効化 • コンテナーをステートレスにする
13. ストレージの冗長構成 • 複数のコピーを持つ • 地理的分散をする
14. Azure Storageの冗長オプション 方式 複製範囲 主な保護対象 LRS 1リージョン内の単一データセン ター×3 ハードウェア障害、ディスク障害 ZRS 複数可用性ゾーン×3 ゾーン障害 GRS 両リージョンでLRS各3コピー （ゾーン分散なし） リージョン障害 RA-GRS GRS + セカンダリへの読み取り リージョン障害とセカンダリ読み 取り GZRS プライマリ側はZRS、別リージョ ンへGRS ゾーン障害 + リージョン障害 RA-GZRS GZRS + セカンダリへの読み取 り 高い可用性と読み取り継続
15. Container Appsのリトライ 機能 対象 目的 Ingressの振り分け レプリカへの受信トラフィック Readiness失敗のレプリカを振 り分け対象から外す プラットフォームの自動復旧 コンテナ・レプリカ 異常なコンテナーを再起動・置換 する Service discovery resiliency Container Apps間の HTTP/TCP通信 タイムアウト・リトライ・サーキット ブレーカー Container Apps Jobsのリト ライ Jobのレプリカ実行 失敗したJobレプリカを再実行す る アプリケーションのリトライ DB、Storage、外部APIなど Container Appsの外部依存 先の一時障害に対応する
16. Ingressによる自動的な障害対応 • HTTP Ingressを有効にしたContainer Appでは、組み込み のIngressコントローラーが正常なレプリカへトラフィックを分散 します。 • レプリカがヘルスチェックに失敗すると、Container Appsはそ のレプリカをロードバランシング対象から外し、必要に応じてコン テナを再起動したり、置き換えレプリカを作成したりします。 • これは主にプラットフォームがレプリカを回復する処理です。アプ リケーションが呼び出すAzure SQLやBlob Storageの操作を、 任意の条件で安全に再実行する機能ではありません。
17. ヘルスプローブによる再起動とトラフィッ ク切り離し プローブ 目的 Startup probe アプリケーションの起動完了を確 認 Readiness probe トラフィックを受け取れる状態か 確認 Liveness probe プロセスが動作し続けているか確 Liveness probeに失敗した場 認 合、コンテナの再起動につながり ます。 Readiness probeに失敗した 場合、通常はそのレプリカをトラ フィックから外します
18. Container Apps間通信のリトライ (Preview) 機能 説明 HTTPタイムアウト Timeout Policyは、接続や応答を一定時間待ったあと、処理をタイムア ウトとして終了させる機能です。 HTTPリトライ HTTP Retry Policyは、指定した条件に該当するHTTP要求を再試行し ます。 TCP接続リトライ TCP Retry Policyは、TCP接続の確立に失敗した場合の再接続回数を 定義します。 サーキットブレーカー Circuit Breakerは、異常なレプリカへ要求を送り続けないための機能 です。 HTTP接続プール HTTP Connection Poolは、Container Apps間で確立済みの HTTP接続を再利用するための機能です。 TCP接続プール TCP Connection Poolは、Container Apps間で確立済みのTCP接 続を再利用するための機能です。
19. 回復性といってもPGとインフラがある • これまで見てきたように、一口に回復性と言っても、コード側でや る対策と、インフラ側での対策がある。 • ここでのResiliency AgentはAzure Portalでの機能ですの でインフラ側での対策がスコープになる。
20. ところでこれ！ 回復性エージェン トさん！
21. Resiliency Agentの機能(Public Preview) • 新規ワークロードの構成を説明すると、回復性を評価し、推奨構成 とBicepテンプレートを生成 • 既存リソースのゾーン冗長性を確認し、問題点・前提条件・改善方 法を提示 • その場で変更できるリソースは直接有効化し、再デプロイが必要 なリソースは手順やスクリプトを提示
22. Resiliency Agentの現時点の制約 • 主な対象はゾーン回復性です。リージョン回復性などは今後拡張 予定とされています。 • すべてのリソースをその場で変更できるわけではありません。 • VMなど再デプロイが必要なリソースでは、手順やスクリプトの提 示にとどまる場合があります。 • Azure Backup、Site Recovery、Storageのレプリケーショ ンなどを置き換える機能ではなく、それらの利用判断や構成改善 を支援する機能です。
23. インフラ側で行う限界点 • Azureリソースの冗長性やゾーン構成、設定前前提条件を確認し て改善案やIaCを作ることは有効 • ただし、アプリケーションコードの実行時の挙動まで検証・修正す るものではない • プロセス内のSingleton • インメモリーキャッシュ • ローカルディスク上のロックファイル • 特定インスタンスだけが持つバックグラウンド処理状態
24. PG側での処理と競合するかも？？ • Container AppsのService discovery resiliencyでは、タ イムアウト、HTTP/TCPリトライ、サーキットブレーカー、接続プー ルを構成できます。 • しかしこれは、コンテナー間の通信についてコード上でのリトライ 処理・サーキットブレーカーとのつじつまを合わせる必要がありま す。
25. つかってみた
26. 頑張っている様子
27. 情報足りない様子
28. お任せした
29. ContainerApps知らないらしい
30. ずっと聞いてくる
31. まだ聞く
32. まとめ • Azure Copilot Resiliency Agentは次の領域には向いてる • ゾーン冗長の確認 • リリース構成の評価 • コード側では以下を確認する必要あり • 状態の外部化 • リトライのべき等性 • DB再接続 • Blazor回線の再接続と状態復元
33. 宣伝
34. アクセシビリティカンファレンス福岡 2026(11/21)
35. Microsoft MVPとMicrosoft Ignite の日に徹夜するバー（11/17）
36. 【大阪出張編】.NETラボ 勉強会 2026年 11月(11/28)
37. .NETラボ@HackBar心斎橋（11/29）
38. PyCon mini Tokyo with PythonAsia conference 日本とアジアのPythonコミュニティが交流する1日 2026/12/12（土） 10:00〜19:00 会場 日本語・英語の2トラック GMO Yours・フクラス 渋谷フクラス16階 基調講演 Seth Larson / Mike Fiedler （Python Software Foundation） 一般 1,500円 学生 500円 パトロン 10,000円 参加登録はconnpassへ（事前決済） pyconjp.connpass.com/event/404336/
39. 開催日のお知らせ PyCon mini Shizuoka 2027 2027/2/27（土） 会場 B-nest & 静岡市コクリ 前回と同じ会場です。ぜひ予定の確保をお願いします！ #pyconshizu 2027でお会いしましょう！ 参加・プロポーザル・スポンサーの募集は追って告知します。 pycon-shizu.connpass.com/event/409477/ 詳細はconnpassへ
40. 開催日・会場のお知らせ PyCon JP 2027 Pythonユーザーが集い、情報交換・交流するカンファレンス 2027/9/24（金）〜26（日） 会場 沼津プラサヴェルデ 参加チケット・プロポーザル・スポンサー募集は近日案内 最新情報は公式サイトへ 2027.pycon.jp 静岡県沼津市
41. おしまい