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

Transcript

1. View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

12. 3FUSZύλʔϯ
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

17. )FBMUI &OEQPJOU .POJUPSJOH
    ύλʔϯ
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

21. 4UBUJD$POUFOU )PTUJOH
    ύλʔϯ
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

25. 4DIFEVMFS "HFOU4VQFSWJTPS
    ύλʔϯ
    

    View Slide

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

    View Slide

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

    View Slide

28. 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に処理をさせる)
    • タスクの失敗回数が規定回数を超えていたら、リトライによる復旧は不能
    として、メールで通知し管理者が⼿動で修正、各サービスをロールバック
    するなど要件に応じて適切な処理を⾏う。
    

    View Slide

29. 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
    

    View Slide

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

    View Slide

31. Scheduler Agent Supervisorパターン
    Agent
    ResponseQueue
    RequestQueue
    pushRequest
    Message
    retrieveResponse
    Message
    Remote
    Service
    Scheduler
    task_id 1
    user_id ntakei@example.com
    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
    

    View Slide

32. Scheduler Agent Supervisorパターン
    Agent
    ResponseQueue
    RequestQueue
    pushRequest
    Message
    retrieveResponse
    Message
    Remote
    Service
    Scheduler
    task_id 1
    user_id ntakei@example.com
    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”: “ntakei@example.com”,
    “taskBody”: “{upn:ntakei・・・}”
    }
    retryTask
    Supervisor
    

    View Slide

33. Scheduler Agent Supervisorパターン
    Agent
    ResponseQueue
    RequestQueue
    pushRequest
    Message
    retrieveResponse
    Message
    Remote
    Service
    Scheduler
    task_id 1
    user_id ntakei@example.com
    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”: “ntakei@example.com”,
    “taskBody”: “{upn:ntakei・・・}”
    }
    Agentは、RequestQueueから取得した
    JSONに基づき、Remote
    Service(Office365)に処理を⾏います。
    retryTask
    Supervisor
    

    View Slide

34. Scheduler Agent Supervisorパターン
    Agent
    ResponseQueue
    RequestQueue
    pushRequest
    Message
    retrieveResponse
    Message
    Remote
    Service
    Scheduler
    task_id 1
    user_id ntakei@example.com
    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”: “ntakei@example.com”,
    “processState”: “03”
    }
    

    View Slide

35. retryTask
    Supervisor
    Scheduler Agent Supervisorパターン
    Agent
    ResponseQueue
    RequestQueue
    pushRequest
    Message
    retrieveResponse
    Message
    Remote
    Service
    Scheduler
    task_id 1
    user_id ntakei@example.com
    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”: “ntakei@example.com”,
    “processState”: “03”
    }
    retrieveResponseMessageは1分ご
    とにState Storeをチェックし、
    ResponseQueueからメッセージを
    取得して、JSON内のprocessState
    の値を、フィールドprocess_stateに
    03(失敗)として登録する。
    

    View Slide

36. retryTask
    Supervisor
    Scheduler Agent Supervisorパターン
    Agent
    ResponseQueue
    RequestQueue
    pushRequest
    Message
    retrieveResponse
    Message
    Remote
    Service
    Scheduler
    task_id 1
    user_id ntakei@example.com
    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に処理を依頼します。
    つまりリトライです。
    

    View Slide

37. retryTask
    Supervisor
    Scheduler Agent Supervisorパターン
    Agent
    ResponseQueue
    RequestQueue
    pushRequest
    Message
    retrieveResponse
    Message
    Remote
    Service
    Scheduler
    task_id 1
    user_id ntakei@example.com
    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分
    間リトライを繰り返してもタスクが
    成功しなかったとします。
    

    View Slide

38. retryTask
    Supervisor
    Scheduler Agent Supervisorパターン
    Agent
    ResponseQueue
    RequestQueue
    pushRequest
    Message
    retrieveResponse
    Message
    Remote
    Service
    Scheduler
    task_id 1
    user_id ntakei@example.com
    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時間後にもう⼀度リトライが始まる
    わけです。これが⻑期的なリトライ
    です。
    

    View Slide

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

    View Slide

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

    View Slide