Read “Continuous Delivery with Spinnaker”

I read Continuous Delivery with Spinnaker to catch up with Spinnaker and the bases. Recent my profession is mobile, but I have some experience/knowledge of distributed systems since I studied the Byzantine General Problems in my university. And I also has caught up with network/tools/fundamentals associated with it. (Especially testing and monitoring topics.) You can…

Read a part of “Practical Monitoring”

I was interested in the book for a long time. The O’Reilly has published a part of the book and I also read it to know the book. Practical Monitoring Just I read only one section. I couldn’t more monitoring stuff in this book, but I got some antipatterns. Anti-Pattern #1: Tool Obsession Anti-Pattern #2:…

Bugsnagを使ってみたが、良さそうだ

主にはモバイルアプリのクラッシュログなどのログ管理に関して、最近の流れを知りたいと思いいろいろ物色してみました。類似サービスとしてはCrashlyticsなんかがありますが、いろいろ使っていると機能的に柔軟性が足りなかったりして目的に沿った利用ができないことが増えてきて、他に手頃なサービスあるのかなと思ったことも要因です。 Crashlytics以外にもいくつか調べた中で、最終的に良さそうと思ったのはBugsnag。 Bugsnagは以前どこかで見たか聞いたことあったのですが、そのときはCrashlyticsのように整ったGUIがある方が使い勝手が良かったのでそこまで調べてませんでした。一方、最近ではGitHubとの連携など、サービス間の連携に対して価値を置くようになりました。そのため、ここでちょっとちゃんと使おうと思って使ってみることにしました。 Bugsnagが良かったところ 多くのプラットフォームに対応したログ収集サービス ログ収集サービスに特化していることもあり、多くの言語、プラットフォームをサポートしていました。 リファレンスが書いてあったものでRuby、Python、PHP、Laravel、WordPress、Android、Cocoa、Node.js、JavaScript、Unity、Java、EventMachine、Go、.NET。 私は今回はおもにAndroidのリファレンスを読んだだけなのですが、ログのフィルタリングやビルドの種類ごとにログに対してプレフィックスを変えるなど、よくできたSDKなように見えます。 ログを取得するときはBagsnag上で見ることもできますし、BagsnagからStreamとしてログを自分たち絵取得することもできるなど、APIの連携もちゃんと整っていました。参考になる。 Bugsnagの方々、ログ収集の知見、深そう。 豊富なAPI ドキュメントを眺めるとわかるのですが、ログを取得するためのAPIを豊富に提供しています。 例えばCrashlyticsのようなサービスだと、ある程度まとまった情報を1つの画面で見ることができますが、求める情報だけでフィルタリングするといった細かいところまでは手が届きません。そのため一時期はWebhookを使おうと思いましたが、WebhookにはCrshlyticsへのURLが含まれているだけなど、ログを取得するにはCrashlyticsのGUIを最終的に見るしかないし画面のカスタマイズがそこまで柔軟ではないので欲しい情報だけ絞って見ることが難しい状態でした。 なので、豊富なAPIは自分たちのみたい情報でフィルタリングするWebアプリを作ればそれらが見る事できるし、便利そう。 GitHubとのissue連携 GitHubとだけではないのですが、バグトラッキングシステムとの連携もちゃんとしていました。GitHubを例にとると、Bugsnagからissueの作成はサポートされているのは当然なのですが、ちゃんと連携しているissueが閉じられたらBugsnagのエラーも解決済みにマークされるのです。また、すでにGitHubにissueとして作られている場合、そのissueをBugsnagと別途連携させることができます。連携したら、やはり閉じられると閉じられる。 こういう流れができるわけですね。 クラッシュなどの不具合、特定のログが一定数発生 => issueを作成 => issueベースで作業 連携済みならBugsnagにマークがつくので、issueとして対応されているものかすぐ判断できます。また、issue作成時になんらかの形で再現性確認を自動化できればさらにハッピーになりそう。（モバイルアプリでは難しそうですが。。。） 以下、GUIと連携の例。 一覧。 エラーの詳細画面です。 GitHub issueとの連携箇所。 GHEとの連携もすでに用意されていることろがなかなかいけてますね。 こんな感じで投稿されます。 issueとの相互連携もできます。関連付けておくと、issueをCloseした時点で、Bugsnagのエラーも解決済みのマークがつきます。 よくなかったところ 良かったところ以外でいうと、GUIは他の類似サービスよりも劣ってるとみられる気がします。ただ、GUIを優先したいという要求は私にはないので、そこはさほどマイナスではないです。（むしろ、ログ収集ツールとして気軽に組み込める体裁を維持しているところがすごいと思いました） 他は、Android以外使ってないのでなんとも言えないです。。。なんかすみません。 締め Trialが14日間で、それが終われば制限化でFreeで利用することもできるようです。私自身の個人利用はFreeで大丈夫なので、今後も使っていきたい。 こういうログ収集システム、サービスの拡大につれて自社で作る状態に落ち着きそうですが、そこまでなる前の段階ではかなり良さそうなサービスに思えます。Crashlyticsなんかは、少数のアプリを監視すれば十分な状態ではほぼ満足いきますが、監視すべきアプリが増えたりしてくると物足りない。その中間がBugsnagで、そこからさらに拡大すると自社、という流れになるのかなと思ったりしました。 これで、私のAndroidアプリの開発環境は以下の形で落ち着きそう。 Circle CI + Bugsnag + Deploygate Bugsnagだ！

NetflixのHystrixにも使われるCircuit Breaker patternを調べてみた

Testing Strategies In A Microservice Architectureを読んだを読んでいる途中に出てきた、Circuit Breakerと呼ばれる機構を調べてみました。Martin Fowler氏がこの記事で言及しているものでした。 このCircuit Breaker patternは、Release It! 本番用ソフトウェア製品の設計とデプロイのためにで描かれているような、本番環境化において発生する、複数システムが関係するからこそ発生する障害を抑えることも目的としたデザインパターンのようです。「複数システムが関係するからこそ発生する障害」とは、一部システムの負荷が高まりタイムアウトするといったことを含みます。 内容自体は、 障害検出のための共有のオブジェクト(Circuit Breacker)を用意して、監視・検出できるようにする ということらしいです。NetflixのHystrixがその実装としてこのパターンを含んでいます。ちなみに、RubyだとここなんかがOSSの実装例として上がっていました。 Circuit Breacker Pattern Circuit Breaker patternの考え方は単純で、以下の図のようにClientとSupplierの間にCircuit Breakder Objectを配置し、そのオブジェクトが障害のモニタリングを行いエラーを制御する、というものです。以下の図では、Circuit Breadker Objectが、Supplierのエラーを複数回検出すると、以降は復帰するまで必要以上にリクエストしないように制御します。 サンプルプログラムも置いていています。それを見ると、@failure_countのインスタンス変数にエラーの回数を足していき、一定数超えるとCircuit Openな状態にする。意図的にリセットされるとそのインスタンス変数がゼロになる、という処理で単純に書けますね。 Circuitの状態遷移は以下と定義されています。以下ではClose/Openの2値からさらにHalf Openというものも加え、Openな状態からresetされた後の復帰確認の状態を作っています。 この実装には、並列プログラムのデザインパターンであるFutures and promisesが良い知見を持っているそう。 Circuit Breakersのオブジェクトを設置することは、失敗するであろうオペレーションを抑制することができるところに価値があります。例えば、HTTPリクエストが30秒タイムアウトを繰り返す間、関連するサービスはそれを待たないといけないですが、そもそもCircuit Openな状態が既知であれば失敗することがわかっている処理に30秒も待つ必要がなくなるわけです。 締め Breacker自体が障害になることもあるので、ClientはCircuit openな状態含めて適切な処理を実施する必要があります。一方で、Microservicesのような複数システムが連携する場合、監視・検出はシステムの品質を高めるために非常に重要な役割を担います。その仕組みを共通化してライブラリとして用意しておくことは価値が高そうです。

Spring Cloud Netflixを読んだ

Springが、Netflixが公開している彼らのOSS群を説明している記事を読みました。ちょっと、記憶に止めておきたい内容を探っているのでそのメモがてら。 記事: http://cloud.spring.io/spring-cloud-netflix/spring-cloud-netflix.html これは、Netflixのmicroservicesを構成するツール群を説明していました。 Service Discovery Eureka Clients Circuit Breaker Hystrix Intelligent Routing Zuul Client Side Load Balancing Ribbon Service Discovery: Eureka Clients Service Discoveryはmicsoservicesベースのアーキテクチャとして大事な要素 Circuit Breaker Hystrix Clients Netflixは、CircuitBreakerを実装したもの。Microservicesでは、複数のサービスコールのレイヤを持っている。 低レベルのサービス障害が発生すると、障害がユーザまで伝っていくので、障害のあったサービスをフォールバックすることで障害の伝搬を抑制することが目的 ↑の状態になるサービスは、例えば /health の応答として “CIRCUIT_OPEN”というstatusを返す Dashboard circuitがOpenかCloseかを知ったり、応答速度を監視するためのダッシュボードですね Turbin すべての /hystrix.stream エンドポイントを、Dashboardの /turbin.streadm エンドポイントに統合するアプリケーション。アプリのインスタンスはEurekaにある。 Declarative REST Client Feign Feignは、Web serviceクライアント この記事では、Spring frameworkとして使える方法も紹介してました。 Client Side Load Balancer…