Upgrade to Pro — share decks privately, control downloads, hide ads and more …

クラウドデザインパターンを使ってクールな設計をしよう/jazug12th

Noriyuki TAKEI
September 24, 2022

 クラウドデザインパターンを使ってクールな設計をしよう/jazug12th

Noriyuki TAKEI

September 24, 2022
Tweet

More Decks by Noriyuki TAKEI

Other Decks in Technology

Transcript

  1. Noriyuki TAKEI ෢Ҫ ٓߦ Information • サイオステクノロジー株式会社 • Microsoft MVP

    for Microsoft Azure Favorites • Azure • パデル • スキー • ライブ配信 • ⽢いもの • ⾛ること blog https://tech-lab.sios.jp/ core skill Azureによるクラウドネイティブな アプリ開発 Twitter @noriyukitakei
  2. Retryパターン Application Gateway API Management Azure Functions Cosmos DB Azure

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

    Blob Storage リモートコール リモートコール リモートコール リモートコール リモートコール ここの処理リトライする必要がある。 Teams
  4. Retryパターン ▪ Retryパターン アプリケーション リモートサービス HTTPリクエスト 500 HTTPリクエスト 500 HTTPリクエスト

    200 ① ② ③ 短期的なリモートサービスの障害には有効だが、障害が長期的に渡る場合は、Circuit Breakerパターンなど を検討する必要がある。
  5. Health Endpoint Monitoringパターン Application Gateway Cosmos DB Azure Blob Storage

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

    Teams /users /products ・・・アプリのエンドポイント /healthchek ヘルスチェック専⽤のエンドポイントを設けて、 全ての依存サービスをチェックする。
  7. Static Content Hostingパターン 課題 解決策 昨今はVue.jsなどのJava Scriptフレームワークから、APIを叩いてデータを取得し てHTMLページをレンダリングするSingle Page Applicationが主流です。Vue.jsな

    どの静的コンテンツを置くためだけに、ApacheやNGINXを搭載したPaaSを使うの は、管理も⼤変だし、何より料⾦が⾼額。。。 Static Content Hostingパターンで解決します。静的コンテンツを配置する専⽤ の安価で⾼速なサービスを使います。
  8. Static Content Hostingパターン 静的コンテンツ API データベース App Service Azure Functions

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

    Functions Cosmos DB Static Web Appsは静的コンテンツをホス トする専用のサービスであり、管理も楽 で安価に使える。
  10. Scheduler Agent Supervisorパターン ⼀連のワークフロー処理とは具体例をあげますと以下になります。 Office365のメールアドレスを変更する。 古いメールアドレスはエイリアスにする。 エイリアスを10⽇後に削除する旨の 警告メールを送信する。 エイリアスを削除する。 90⽇後

    10⽇後 例えば、この処理に失敗した場合は短期的 なリトライを実施し、短期的なリトライの 末に失敗した場合、障害が⻑期に渡ると⾒ 込まれるので、更に⼀定時間経過後更に短 期的なリトライ(つまり⻑期的なリトライ) を⾏い、⻑期的なリトライが成功するまで、 次のタスクを実施してはいけない。
  11. 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に処理をさせる) • タスクの失敗回数が規定回数を超えていたら、リトライによる復旧は不能 として、メールで通知し管理者が⼿動で修正、各サービスをロールバック するなど要件に応じて適切な処理を⾏う。
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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” }
  18. 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(失敗)として登録する。
  19. 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に処理を依頼します。 つまりリトライです。
  20. 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分 間リトライを繰り返してもタスクが 成功しなかったとします。
  21. 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時間後にもう⼀度リトライが始まる わけです。これが⻑期的なリトライ です。