No content

Noriyuki TAKEI ෢Ҫ ٓߦ Information • サイオステクノロジー株式会社 • Microsoft MVP for Microsoft Azure Favorites • Azure • パデル • スキー • ライブ配信 • ⽢いもの • ⾛ること blog https://tech-lab.sios.jp/ core skill Azureによるクラウドネイティブな アプリ開発 Twitter @noriyukitakei

https://youtube.com/playlist?list=PLbTt_DSTMYgGLUtZ0ewuBwhTBSZnNE2-w

技術ブログ「SIOS Tech.Lab」 クラウドデザインパターンを実践してみたシリーズ 〜 Scheduler Agent Supervisorパターン〜 https://tech-lab.sios.jp/archives/11125

Ϋϥ΢υσβΠϯύλʔϯ ͱ͸ʁ

クラウドデザインパターンとは︖ AzureのみならずAWSなど 他のクラウドにも通⽤する汎⽤的なパターン 実装例が超豊富 マイクロソフトが提供している クラウド上でアプリケーションを作成するための ベストプラクティス

クラウドデザインパターンとは︖ 以下のURLで公開されています。 https://docs.microsoft.com/ja-jp/azure/architecture/patterns/ もしくは以下の書籍にも同じ内容が記載されています。

クラウドデザインパターンとは︖ 設計に限らずですが、より良いものを作ろうとした場合、 パクる先⼈の知恵をお借りするのが⼀番です。 なので クラウドデザインパターンを活⽤しよう︕︕

その1 リモートコールを多⽤する。 その2 数多くのサービスが連携しながら システム全体が動作する。 オンプレミスにはないクラウドならではの以下の特性により、クラウドデザイン パターンが必要になりました。 その3 ステートレスが基本である。

͍ΖΜͳ Ϋϥ΢υσβΠϯύλʔϯ

Retryパターン Health Endpoint Monitoringパターン Scheduler Agent Supervisorパターン クラウドデザインパターンは全部で24個あるのですが、その中でも私の推しは以 下になります。 Static Content Hostingパターン

3FUSZύλʔϯ

Retryパターン 課題 解決策 クラウドは複数のサービスが相互に連携しあってシステム全体が動作します。ある サービスから他のサービスの呼び出しは、基本IPネットワーク経由のリモートコー ルですので、ネットワークの輻輳その他様々な原因で失敗する可能性があります。 Retryパターンで解決します。Retryパターンはその名の通り、APIなどリモートコ ールの呼び出しが失敗しても規定間隔規定回数で成功するまでリトライします。

Retryパターン Application Gateway API Management Azure Functions Cosmos DB Azure Blob Storage リモートコール リモートコール リモートコール リモートコール リモートコール Teams

Retryパターン Application Gateway API Management Azure Functions Cosmos DB Azure Blob Storage リモートコール リモートコール リモートコール リモートコール リモートコール ここの処理リトライする必要がある。 Teams

Retryパターン ■ Retryパターン アプリケーション リモートサービス HTTPリクエスト 500 HTTPリクエスト 500 HTTPリクエスト 200 ① ② ③ 短期的なリモートサービスの障害には有効だが、障害が長期的に渡る場合は、Circuit Breakerパターンなど を検討する必要がある。

)FBMUI &OEQPJOU .POJUPSJOH ύλʔϯ

Health Endpoint Monitoringパターン 課題 解決策 クラウドは複数のサービスが相互に連携しあってシステム全体が動作します。よっ て、ヘルスチェックはその依存サービス全てをチェックしなければならず、全部チ ェックするのがしんどい。 Health Endpoint Monitoringパターンで解決します。ヘルスチェック専⽤のエ ンドポイントを⽤いて、そのエンドポイントを監視します。

Health Endpoint Monitoringパターン Application Gateway Cosmos DB Azure Blob Storage Teams これらの依存サービスも 全てチェックする必要がある。 /users /products ・・・アプリのエンドポイント

Health Endpoint Monitoringパターン Application Gateway Cosmos DB Azure Blob Storage Teams /users /products ・・・アプリのエンドポイント /healthchek ヘルスチェック専⽤のエンドポイントを設けて、 全ての依存サービスをチェックする。

4UBUJD$POUFOU )PTUJOH ύλʔϯ

Static Content Hostingパターン 課題 解決策 昨今はVue.jsなどのJava Scriptフレームワークから、APIを叩いてデータを取得し てHTMLページをレンダリングするSingle Page Applicationが主流です。Vue.jsな どの静的コンテンツを置くためだけに、ApacheやNGINXを搭載したPaaSを使うの は、管理も⼤変だし、何より料⾦が⾼額。。。 Static Content Hostingパターンで解決します。静的コンテンツを配置する専⽤ の安価で⾼速なサービスを使います。

Static Content Hostingパターン 静的コンテンツ API データベース App Service Azure Functions Cosmos DB 静的コンテンツをホストするだけなの にApp Serviceは管理大変だし、何より も料金たかい。。。

Static Content Hostingパターン 静的コンテンツ API データベース Static Web Apps Azure Functions Cosmos DB Static Web Appsは静的コンテンツをホス トする専用のサービスであり、管理も楽 で安価に使える。

4DIFEVMFS "HFOU4VQFSWJTPS ύλʔϯ

Scheduler Agent Supervisorパターン 課題 解決策 ⼀連のワークフロー処理を確実に実施するためには、Retryパターンによる再試⾏ が必要だけど、障害が⻑引くような場合には、ワークフローを⼀時的に停⽌ (もし くはロールバック)して、障害復旧後にもう⼀度リトライする必要がある、、、のだ けど、その処理はとっても複雑。。。。 Scheduler Agent Supervisorパターンで解決します。短期的なリトライのみな らず⻑期的なリトライも実施、あらゆる障害に対しても⾃律的に復旧し、確実にワ ークフローを実⾏します。

Scheduler Agent Supervisorパターン ⼀連のワークフロー処理とは具体例をあげますと以下になります。 Office365のメールアドレスを変更する。 古いメールアドレスはエイリアスにする。 エイリアスを10⽇後に削除する旨の 警告メールを送信する。 エイリアスを削除する。 90⽇後 10⽇後 例えば、この処理に失敗した場合は短期的 なリトライを実施し、短期的なリトライの 末に失敗した場合、障害が⻑期に渡ると⾒ 込まれるので、更に⼀定時間経過後更に短 期的なリトライ(つまり⻑期的なリトライ) を⾏い、⻑期的なリトライが成功するまで、 次のタスクを実施してはいけない。

Scheduler Agent Supervisorパターン Scheduler State Store Agent Remote Service Supervisor ① タスクの情報がState Storeに書き込 まれる。タスクの実⾏状態(未処理、処 理中、成功、失敗)、タスクの完了予定 時間、タスクの失敗回数が登録される。 ② Schedulerは、定期的にState Storeをチェックし、実⾏状態が 未処理のタスクを抽出し、Agent にタスクの実⾏を依頼する。 ③ Agentは、Remote Service に対して、処理を実施する。 ④ Agentは、Remote Serviceに対する処理の結果を Schedulerに返す。 ⑤ Schedulerは、Agentか らの実⾏結果を受けて、 State Storeに実⾏状態を 登録する。 ⑥ Supervisorは、定期的にState Storeをチェックし、以下の処理を⾏う。 • タスクの失敗回数が規定回数以内で、タスクの実⾏状態が失敗、もしくは、 タスクの予定完了時間を過ぎていたら、タスクの実⾏状態を未処理にする。 (つまり再びAgentに処理をさせる) • タスクの失敗回数が規定回数を超えていたら、リトライによる復旧は不能 として、メールで通知し管理者が⼿動で修正、各サービスをロールバック するなど要件に応じて適切な処理を⾏う。

Scheduler Agent Supervisorパターン Agent ResponseQueue RequestQueue pushRequest Message retrieveResponse Message Remote Service State Store Scheduler ・・・Azure Functions ・・・Azure Queue Storage ・・・Azure App Service WebJobs ・・・Azure Database for MySQL ・・・Office365 retryTask Supervisor

Scheduler Agent Supervisorパターン Agent ResponseQueue RequestQueue pushRequest Message retrieveResponse Message Remote Service Scheduler task_id 1 user_id [email protected] task_body {upn:ntakei・・・} locked_by NULL complete_by NULL process_state 00 failuer_count 0 State Store 外部システムがState Storeに以下のような タスクを登録します。 retryTask Supervisor

Scheduler Agent Supervisorパターン Agent ResponseQueue RequestQueue pushRequest Message retrieveResponse Message Remote Service Scheduler task_id 1 user_id [email protected] task_body {upn:ntakei・・・} locked_by NULL complete_by NULL process_state 00 failuer_count 0 State Store Schedulerとして機能するAzure Functionsの関数 pushRequestMessageが、フィール ドprocess_stateが00(未処理)、か つlocked_byがNULLのタスクを取得 します。 retryTask Supervisor

Scheduler Agent Supervisorパターン Agent ResponseQueue RequestQueue pushRequest Message retrieveResponse Message Remote Service Scheduler task_id 1 user_id [email protected] task_body {upn:ntakei・・・} locked_by 01 complete_by 2022-07-21 17:10:00 process_state 00 failuer_count 0 State Store タスク情報を取得したら、 pushRequestMessageが、フィール ドprocess_stateを01(処理中)、 フィールドlocked_byを01、 complete_byを現在時刻の10分後に します。そして、RequestQueueに JSONをpushします。 { ”taskId”: ”1”, ”userId”: “[email protected]”, “taskBody”: “{upn:ntakei・・・}” } retryTask Supervisor

Scheduler Agent Supervisorパターン Agent ResponseQueue RequestQueue pushRequest Message retrieveResponse Message Remote Service Scheduler task_id 1 user_id [email protected] task_body {upn:ntakei・・・} locked_by 01 complete_by 2022-07-21 17:10:00 process_state 00 failuer_count 0 State Store { ”taskId”: ”1”, ”userId”: “[email protected]”, “taskBody”: “{upn:ntakei・・・}” } Agentは、RequestQueueから取得した JSONに基づき、Remote Service(Office365)に処理を⾏います。 retryTask Supervisor

Scheduler Agent Supervisorパターン Agent ResponseQueue RequestQueue pushRequest Message retrieveResponse Message Remote Service Scheduler task_id 1 user_id [email protected] task_body {upn:ntakei・・・} locked_by 01 complete_by 2022-07-21 17:10:00 process_state 00 failuer_count 0 State Store Agentは、ResponseQueueに実⾏結果 を表したJSONを登録します。ここでは、 成功したらSupervisorの出番がないの で、Office365への登録が失敗したと仮 定して、processStateを03にしていま す。 retryTask Supervisor { ”taskId”: ”1”, ”userId”: “[email protected]”, “processState”: “03” }

retryTask Supervisor Scheduler Agent Supervisorパターン Agent ResponseQueue RequestQueue pushRequest Message retrieveResponse Message Remote Service Scheduler task_id 1 user_id [email protected] task_body {upn:ntakei・・・} locked_by 01 complete_by 2022-07-21 17:10:00 process_state 03 failuer_count 0 State Store { ”taskId”: ”1”, ”userId”: “[email protected]”, “processState”: “03” } retrieveResponseMessageは1分ご とにState Storeをチェックし、 ResponseQueueからメッセージを 取得して、JSON内のprocessState の値を、フィールドprocess_stateに 03(失敗)として登録する。

retryTask Supervisor Scheduler Agent Supervisorパターン Agent ResponseQueue RequestQueue pushRequest Message retrieveResponse Message Remote Service Scheduler task_id 1 user_id [email protected] task_body {upn:ntakei・・・} locked_by NULL complete_by 2022-07-21 17:10:00 process_state 00 failuer_count 1 State Store retryTaskは1分ごとにState Storeを チェックし、以下の条件に合致するとき、 • process_state = 03(失敗) • complete_by > 現在時刻 テーブルの各フィールドを以下のように 更新します。 • locked_by = NULL • process_state = 00 すると、その変更をSchedulerが抽出し て、もう⼀度Agentに処理を依頼します。 つまりリトライです。

retryTask Supervisor Scheduler Agent Supervisorパターン Agent ResponseQueue RequestQueue pushRequest Message retrieveResponse Message Remote Service Scheduler task_id 1 user_id [email protected] task_body {upn:ntakei・・・} locked_by 01 complete_by 2022-07-21 17:10:00 process_state 03 failuer_count 10 State Store complete_byに指定した時間までリ トライを繰り返しても、つまり10分 間リトライを繰り返してもタスクが 成功しなかったとします。

retryTask Supervisor Scheduler Agent Supervisorパターン Agent ResponseQueue RequestQueue pushRequest Message retrieveResponse Message Remote Service Scheduler task_id 1 user_id [email protected] task_body {upn:ntakei・・・} locked_by NULL complete_by 2022-07-21 18:20:00 process_state 00 failuer_count 10 State Store retryTaskは、1時間後、つまり 2022-07-21 18:10:00になったら、 complete_byを現在時刻の10分後 (2022-07-21 18:20:00)に更新し、 process_stateが00(未処理)、 lodked_byをNULLにします。つまり 1時間後にもう⼀度リトライが始まる わけです。これが⻑期的なリトライ です。

第20回:Azureの課金を節約する方法をわかりみ深く解説 Connpassで募集中 https://tech-lab.connpass.com/event/260626/

࠷ޙ·Ͱ͝ਗ਼ௌ௖͖ ͋Γ͕ͱ͏͍͟͝·ͨ͠ʂʂ