あいさつ

もうすぐ年末ですがAdventカレンダーの進捗はいかがでしょうか？

私は全くです(ノﾟДﾟ)八(ﾟДﾟ　)ノｲｴｰｲ

そしてここでお知らせがございます。

クリスマス中止のお知らせ

2017年12月24,25日に開催予定のクリスマスは、隣国の情勢の悪化に伴い中止となりました。

本決定により、クリスマスイブも中止になります。

中止、ならびに本告知が遅れたことにつきまして、楽しみにしておられた方々、及び関係者各位には謹んでお詫び申し上げます。

はじめに

みなさん、Azure Functionsは使ってますか？

ビバ！サーバーレス！！　素晴らしきかなサーバーレス！！　

サーバレスで作成すマイクロサービスアーキテクチャでAIを利用すればOK(∩´∀｀)∩

なんてことは全く思っているわけではないんですがFunctions自体は好んで使ったりしてます。

Functionsではキュートリガーであったりブロブトリガーなどはよく使うかと思います。

キュートリガー系の設計を設計して行った時に以下のような課題にぶつかったりする事があります。

トリガーで動作するFunctionの中で外部サービスへアクセスを行なっている。
外部サービスが障害により停止した時にもFunctionは実行されてしまう。
FunctionはExceptionが発生するのでキューはいずれポインズンキュー or 配信不能キューに移動する
失敗する事が確定しているのに無駄にリソースが消費されてしまう

この様なケースに対応するクラウドなサービスパターンはサーキットブレーカーパターンでしょう。

github.com

[Azure Deep Dive] クラウドデザインパターン～優れたシステム構築のためのガイダンス～ from Naoki (Neo) SATO

www.slideshare.net

Azure Functionsでサーキットブレークを行おうとすると、おそらく二つの方法が思いつきます。

Application Insights等でFunctionの実行状況を監視してエラーが閾値を超えた場合にFunction App自体を停止する。
そういう風な仕組みを持ったトリガーを自作する。

今回は前回の記事

tamafuyou.hatenablog.com

を応用して、サーキットブレークするトリガーの作成してみたいと思います。

なお、今回サーキットブレークを厳密に実装しているわけではなくなんちゃってサーキットブレーカーである事をはじめに宣言しておきます。

本題

今回の成果物

github.com

SErviceBus・・・・・

解説

実装検討

まず最初に検討した実装方法は「SIngletonAttribute的な感覚でCircutiBreakerパターンを行うことはできないだろうか」ということだったのですが、SingletonAttribute自体WebJobsのコアに食い込んで実装されているため同様な実装を行うためにはかなりのコストがかかってメンドくさいのでボツ。

じゃあトリガー系でよく使われるのはAzure Storage QueueのトリガーとServiceBusのキュートリガーなので「継承していい感じにできないかな」と考えたんですがほとんどの実装がinternalとなっているため無理(･ω･ノ)ノ！

どちらの方が再実装が楽かなぁとコードを見てみた結果、ServiceBusの方が実装シンプルだったので、今回はServiceBusのキュートリガーを作成してみることにしました。