EventGridTopicで手軽にイベントドリブンを手に入れる

Transcript

1. Event Grid Topicで手軽にイ ベントドリブンを手に入れる By yuka abuno Serverless meetup Tokyo

   #12 2019 / 05 / 27

2. こんにちは、Azure地方から参りました。 • 所属 : シグマコンサルティング株式会社 • Twitter : @yu_ka1984 •

   ブログ書いたりプログラム書いたり • Durable Functions Contributor • C#er(ただしUnityはやってない) • Microsoft MVP for Development Technology (Not Azure) • Webフロントエンド〜スマホ・デスクトップ〜バックエンド・クラウ ド

3. 質問 サーバレスアーキテクチャ利用してますか？

4. サーバレスアーキテクチャとかイベントドリブンな開 発凄く好きなんだけど・・・・ でも現実ではMVCフレームワークを使ってサービス 立ち上げることが多いよねぇ

5. そんなMVCフレームワークWebアプリケーションで も「サーバレスアーキテクチャ」を使っていこう！！

6. こんな事よくありませんか？ • その処理の時にユーザにメール投げて欲しいんだけど。 • その処理の時にSlackに通知して欲しいんだけど。 • その処理の時にカスタマーサービスと連携して欲しいんだけど。 • その処理の時にバックエンド基幹と連携して欲しいんだけど。 •

   その処理の時にPDFをStorageに作成してほしいんだけど。 • その処理の時にetc • その処理の • その

7. そんなの全部実装していったら・・・・

8. じゃあ、どうする？

9. 諦めて同期的に実装する？ • 気がついたらなんか重いサービス • １ロジック内に色々な処理を実行 -> 耐障害性の低下(冪等性、リ トライ、etc

10. RDBのレコードにフラグを追加して定期バッチ処理で後から実行 • バッチ実行頻度は？(リアルタイム性) • １回のバッチ実行件数は？(バッチ突き抜け問題) • そもそも「その処理」がRDB更新処理ではなかったら？ • 気がついたらフラグ沢山・・・・

11. メッセージングサービスを使って非同期処理 • 「「これならいける！！」」のだけど・・・

12. メッセージングサービスを使って非同期処理 • いつのまにか、メッセージングサービスが沢山に・・・

13. 運用開始後のメンテナンスとして 何かの処理の後に何かを追加するのはよくある事。

14. ならば 始めからアプリケーション全体のアクティビティを1 つのメッセージサービスに集約 あとから自由にアクティビティを購読できると素敵な のでは？

15. None

16. メッセージングサービスに欲しい性能 • １つのメッセージングサービスにアプリケーション全体のアク ティビティを集約 • １つのメッセージングサービスから欲しいアクティビティのみを 購読 • お手軽に安く。でもスケーラブルに。 •

    Subscriberの自由度が欲しい。

17. Azure Event Grid ＼ ＼ ＼ Topic ／ ／ ／

18. Azure Event Grid • イベント ベースのアーキテクチャを備えたアプリケーションを 簡単に作成するためのサービス • Azureの様々なサービスをPublisherとして設定でき、必要なメッ セージのみをフィルタリングして購読できる

    • 購読はWebHookで受け取れる。(Push型) • 従量課金なサーバレスメッセージングサービス
19. None

20. Azure Event Grid Topic • TopicエンドポイントにメッセージをHttp Postする事で独自イベ ントをPublishできる。 • AzureのサービスでなくてもPublisherになれる

    • Pub/Subがプッシュ/プッシュ型 • 通常のEvent Gridはクラウドインフラのレイヤーのイベントを取 り扱うが、Custom Topicを使用する事でアプリケーションレイ ヤーのメッセージングサービスとして機能する

21. メッセージの中身 { "eventType" : "OrderCreate", "Subject" : "Order/Create/12345", "Data": {

    "No": 12345, "Date": "2019/05/27", "Customer": "1302834u" } }

22. 購読時のフィルタリング • EventTypeでフィルター • EventTypeは複数指定可能(OR) • Subjectの StartWith / EndWith

    でフィルター可能 • 高度なフィルタリングとして • EventType/Subject以外にもDataなどからフィルタリングが可 能(And)

23. SLAと料金とリトライと • SLA : 99.95 • 月に500万回Publishして500万回配信した場合 • ¥ 665.280

    • MSさんはこのサービスで儲けようとはしていない？ • リトライ : 最大１日 / 30回 までリトライする ( WebHook ) • １日以上はリトライできない / 30回以上はリトライできない • 最終的に失敗したら？ • デッドレターとしてAzure Storage Blobにメッセージを保存できる • Storage Blobへの保存をトリガーにして色々組んでおけばOK

24. 悲しい部分( *´Д⊂ ｸﾞｽﾝ… • Custom TopicへのpublishにRate Limitがある(5000/sec) • POST時に429が返ってくるのでリトライする •

    アプリケーションの規模が大きくなってきた時にネックにな る可能性がある。 • アクティビティの種類、単位を絞る • より大規模に対応可能なメッセージサービスへの移行 • Microsoftに文句を投げつける

25. 開発者目線 • アプリケーション全体の処理で同期/非同期を明確にする事でパ フォーマンス面の考慮や障害時の復旧処理などの設計が楽に • メッセージサービスが沢山にならなくて管理が楽 • Subscriberの選択幅が広い(FunctionsだけでなくLogic Apps(ノー コーディングワークフロー)などが使える)

    • コードを見るだけでは、どのアクティビティに対してどの処理が 発生するかが分からなくなりやすい • ドキュメント類をちゃんと書けば特に問題ない

26. Event Grid Topicを使って気軽なイベントドリブンな 開発をしましょう。