Event Grid Topicで手軽にイベントドリブンを手に入れるBy yuka abunoServerless meetup Tokyo #122019 / 05 / 27
View Slide
こんにちは、Azure地方から参りました。• 所属 : シグマコンサルティング株式会社• Twitter : @yu_ka1984• ブログ書いたりプログラム書いたり• Durable Functions Contributor• C#er(ただしUnityはやってない)• Microsoft MVP for Development Technology (Not Azure)• Webフロントエンド〜スマホ・デスクトップ〜バックエンド・クラウド
質問サーバレスアーキテクチャ利用してますか?
サーバレスアーキテクチャとかイベントドリブンな開発凄く好きなんだけど・・・・でも現実ではMVCフレームワークを使ってサービス立ち上げることが多いよねぇ
そんなMVCフレームワークWebアプリケーションでも「サーバレスアーキテクチャ」を使っていこう!!
こんな事よくありませんか?• その処理の時にユーザにメール投げて欲しいんだけど。• その処理の時にSlackに通知して欲しいんだけど。• その処理の時にカスタマーサービスと連携して欲しいんだけど。• その処理の時にバックエンド基幹と連携して欲しいんだけど。• その処理の時にPDFをStorageに作成してほしいんだけど。• その処理の時にetc• その処理の• その
そんなの全部実装していったら・・・・
じゃあ、どうする?
諦めて同期的に実装する?• 気がついたらなんか重いサービス• 1ロジック内に色々な処理を実行 -> 耐障害性の低下(冪等性、リトライ、etc
RDBのレコードにフラグを追加して定期バッチ処理で後から実行• バッチ実行頻度は?(リアルタイム性)• 1回のバッチ実行件数は?(バッチ突き抜け問題)• そもそも「その処理」がRDB更新処理ではなかったら?• 気がついたらフラグ沢山・・・・
メッセージングサービスを使って非同期処理• 「「これならいける!!」」のだけど・・・
メッセージングサービスを使って非同期処理• いつのまにか、メッセージングサービスが沢山に・・・
運用開始後のメンテナンスとして何かの処理の後に何かを追加するのはよくある事。
ならば始めからアプリケーション全体のアクティビティを1つのメッセージサービスに集約あとから自由にアクティビティを購読できると素敵なのでは?
メッセージングサービスに欲しい性能• 1つのメッセージングサービスにアプリケーション全体のアクティビティを集約• 1つのメッセージングサービスから欲しいアクティビティのみを購読• お手軽に安く。でもスケーラブルに。• Subscriberの自由度が欲しい。
Azure Event Grid \ \ \ Topic / / /
Azure Event Grid• イベント ベースのアーキテクチャを備えたアプリケーションを簡単に作成するためのサービス• Azureの様々なサービスをPublisherとして設定でき、必要なメッセージのみをフィルタリングして購読できる• 購読はWebHookで受け取れる。(Push型)• 従量課金なサーバレスメッセージングサービス
Azure Event Grid Topic• TopicエンドポイントにメッセージをHttp Postする事で独自イベントをPublishできる。• AzureのサービスでなくてもPublisherになれる• Pub/Subがプッシュ/プッシュ型• 通常のEvent Gridはクラウドインフラのレイヤーのイベントを取り扱うが、Custom Topicを使用する事でアプリケーションレイヤーのメッセージングサービスとして機能する
メッセージの中身{"eventType" : "OrderCreate","Subject" : "Order/Create/12345","Data": {"No": 12345,"Date": "2019/05/27","Customer": "1302834u"}}
購読時のフィルタリング• EventTypeでフィルター• EventTypeは複数指定可能(OR)• Subjectの StartWith / EndWith でフィルター可能• 高度なフィルタリングとして• EventType/Subject以外にもDataなどからフィルタリングが可能(And)
SLAと料金とリトライと• SLA : 99.95• 月に500万回Publishして500万回配信した場合• ¥ 665.280• MSさんはこのサービスで儲けようとはしていない?• リトライ : 最大1日 / 30回 までリトライする ( WebHook )• 1日以上はリトライできない / 30回以上はリトライできない• 最終的に失敗したら?• デッドレターとしてAzure Storage Blobにメッセージを保存できる• Storage Blobへの保存をトリガーにして色々組んでおけばOK
悲しい部分( *´Д⊂ グスン…• Custom TopicへのpublishにRate Limitがある(5000/sec)• POST時に429が返ってくるのでリトライする• アプリケーションの規模が大きくなってきた時にネックになる可能性がある。• アクティビティの種類、単位を絞る• より大規模に対応可能なメッセージサービスへの移行• Microsoftに文句を投げつける
開発者目線• アプリケーション全体の処理で同期/非同期を明確にする事でパフォーマンス面の考慮や障害時の復旧処理などの設計が楽に• メッセージサービスが沢山にならなくて管理が楽• Subscriberの選択幅が広い(FunctionsだけでなくLogic Apps(ノーコーディングワークフロー)などが使える)• コードを見るだけでは、どのアクティビティに対してどの処理が発生するかが分からなくなりやすい• ドキュメント類をちゃんと書けば特に問題ない
Event Grid Topicを使って気軽なイベントドリブンな開発をしましょう。